Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #29282 > unrolled thread
| Started by | Jason Damisch <jasondamisch@yahoo.com> |
|---|---|
| First post | 2014-04-04 10:26 -0700 |
| Last post | 2014-04-29 22:52 -0700 |
| Articles | 20 on this page of 374 — 32 participants |
Back to article view | Back to comp.lang.forth
Epic Fail Jason Damisch <jasondamisch@yahoo.com> - 2014-04-04 10:26 -0700
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-04 12:42 -0500
Re: Epic Fail forthisit@gmail.com - 2014-04-04 11:09 -0700
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-04 22:09 +0100
Re: Epic Fail "Elizabeth D. Rather" <erather@forth.com> - 2014-04-04 21:44 -1000
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-05 09:42 -0700
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-05 10:47 -0700
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-05 15:25 -0400
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-07 17:29 +0000
Re: Epic Fail Assad Ebrahim <assadebrahim2000@gmail.com> - 2014-04-07 12:35 -0700
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-08 15:54 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-08 12:43 -0500
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-09 16:16 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-09 13:00 -0500
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-09 21:08 +0200
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-09 15:17 -0500
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-10 00:17 +0200
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-09 22:42 -0700
Re: Epic Fail Stefan Mauerhofer <smauerhofer@androsoft.ch> - 2014-04-10 00:06 -0700
Re: Epic Fail "Alex McDonald" <blog@rivadpm.com> - 2014-04-10 16:00 +0100
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-10 22:35 +0200
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-10 17:51 -0700
Re: Epic Fail Stefan Mauerhofer <smauerhofer@androsoft.ch> - 2014-04-10 21:44 -0700
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-11 23:10 -0700
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-12 06:18 -0400
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-12 06:23 -0400
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-12 10:52 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.invalid> - 2014-04-12 20:14 +0200
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-12 19:21 -0400
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-13 12:25 -0500
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-13 20:33 -0400
Re: Epic Fail stephenXXX@mpeforth.com (Stephen Pelc) - 2014-04-12 16:12 +0000
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-12 09:48 -0700
Re: Epic Fail Stefan Mauerhofer <smauerhofer@androsoft.ch> - 2014-04-12 10:23 -0700
Re: Epic Fail stephenXXX@mpeforth.com (Stephen Pelc) - 2014-04-12 19:51 +0000
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-12 13:00 -0700
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-12 10:29 -0700
Re: Epic Fail stephenXXX@mpeforth.com (Stephen Pelc) - 2014-04-12 19:56 +0000
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-13 00:25 -0700
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-13 10:50 +0100
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-13 16:53 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.invalid> - 2014-04-14 02:32 +0200
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-13 17:59 -0700
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-14 02:00 +0100
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-13 18:30 -0700
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-13 14:21 +0000
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-13 21:12 -0700
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-23 12:49 +0000
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-28 21:02 -0700
Automatic scoping of locals (was: Epic Fail) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-29 14:49 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-10 03:04 -0500
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-11 17:23 +0000
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-11 21:42 +0200
Re: Epic Fail Spam@ControlQ.com - 2014-04-11 16:13 -0400
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-11 22:15 +0200
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-13 16:10 +0000
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-13 18:42 +0100
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-13 23:44 +0200
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-13 20:33 -0400
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-14 04:05 -0500
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-14 09:57 +0000
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-14 11:56 +0100
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-14 14:53 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-14 07:26 -0700
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-14 21:21 +0200
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-15 04:07 -0500
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-14 09:55 -0700
Re: Epic Fail Alexander Skobelev <al.skobelev@gmail.com> - 2014-04-14 22:04 -0700
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-15 04:10 -0400
Re: Epic Fail Alexander Skobelev <al.skobelev@gmail.com> - 2014-04-15 02:40 -0700
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-15 06:41 -0400
Re: Epic Fail Alexander Skobelev <al.skobelev@gmail.com> - 2014-04-15 06:20 -0700
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-15 12:21 +0000
Re: Epic Fail Alexander Skobelev <al.skobelev@gmail.com> - 2014-04-15 06:30 -0700
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-15 20:04 -0700
Re: Epic Fail Alexander Skobelev <al.skobelev@gmail.com> - 2014-04-15 23:50 -0700
Re: Epic Fail "Elizabeth D. Rather" <erather@forth.com> - 2014-04-15 21:31 -1000
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-16 05:55 -0700
Re: Epic Fail "Alex McDonald" <blog@rivadpm.com> - 2014-04-16 14:50 +0100
Re: Epic Fail Alexander Skobelev <al.skobelev@gmail.com> - 2014-04-16 06:06 -0700
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-19 17:44 -0700
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-20 11:35 -0700
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-16 00:19 -0700
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-16 05:29 -0700
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-16 22:45 -0400
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-14 09:49 +0000
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-23 13:07 +0000
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-23 20:16 -0400
Re: Epic Fail "Elizabeth D. Rather" <erather@forth.com> - 2014-04-23 14:41 -1000
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-24 17:10 +0000
Re: Epic Fail Spam@ControlQ.com - 2014-04-24 15:14 -0400
@ and optimization (was: Epic Fail) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-25 08:40 +0000
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-25 06:13 -0500
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-25 15:26 +0000
Re: @ and optimization Paul Rubin <no.email@nospam.invalid> - 2014-04-25 09:03 -0700
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-25 17:45 +0000
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-25 11:15 -0500
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-25 17:22 +0000
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-26 04:38 -0500
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-26 11:38 +0000
Re: @ and optimization Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-26 14:35 +0200
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-26 09:59 -0500
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-26 10:14 -0500
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-26 15:30 +0000
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-26 12:05 -0500
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-26 17:27 +0000
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-26 12:39 -0500
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-26 18:07 +0000
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-27 03:24 -0500
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-27 13:00 +0000
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-27 11:18 -0500
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-28 15:12 +0000
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-29 03:52 -0500
Re: @ and optimization Mark Wills <markwills1970@gmail.com> - 2014-04-29 03:09 -0700
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-29 09:24 -0500
Re: @ and optimization "Elizabeth D. Rather" <erather@forth.com> - 2014-04-29 08:36 -1000
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-29 14:38 +0000
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-29 10:21 -0500
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-29 15:41 +0000
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-29 12:26 -0500
Re: @ and optimization Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-29 20:17 +0200
Re: @ and optimization stephenXXX@mpeforth.com (Stephen Pelc) - 2014-04-29 19:21 +0000
Re: @ and optimization Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-29 23:20 +0200
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-30 03:02 -0500
Re: @ and optimization Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-26 20:55 +0200
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-27 03:28 -0500
Re: @ and optimization albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-27 13:31 +0000
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-28 15:27 +0000
Re: @ and optimization albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-27 13:23 +0000
Re: @ and optimization hughaguilar96@yahoo.com - 2014-04-28 21:32 -0700
Re: @ and optimization "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-26 08:50 -0400
Re: @ and optimization "Alex McDonald" <blog@rivadpm.com> - 2014-04-26 22:52 +0100
Re: @ and optimization "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-26 20:33 -0400
Re: @ and optimization "Alex McDonald" <blog@rivadpm.com> - 2014-04-27 11:53 +0100
Re: @ and optimization "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-28 01:05 -0400
Re: @ and optimization Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-25 21:34 +0100
Re: @ and optimization Paul Rubin <no.email@nospam.invalid> - 2014-04-25 13:37 -0700
Re: @ and optimization Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-25 22:03 +0100
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-26 15:38 +0000
Re: @ and optimization Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-26 17:24 +0100
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-26 04:48 -0500
Re: @ and optimization Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-26 11:09 +0100
Re: @ and optimization (was: Epic Fail) hughaguilar96@yahoo.com - 2014-04-28 21:24 -0700
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-24 19:17 +0000
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-25 08:27 +0000
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-25 23:44 +0200
Re: Epic Fail stephenXXX@mpeforth.com (Stephen Pelc) - 2014-04-26 14:37 +0000
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-13 15:04 -0700
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-26 09:58 +0100
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-26 10:16 +0100
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-26 05:06 -0500
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-26 11:16 +0100
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-26 03:43 -0700
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-26 14:24 +0000
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-26 23:58 -0400
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-27 12:46 +0000
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-28 00:41 -0400
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-28 21:54 -0700
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-26 17:17 +0100
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-26 10:08 -0500
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-26 13:44 +0200
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-26 09:11 -0400
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-26 10:12 -0500
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-26 17:00 +0100
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-26 12:08 -0500
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-26 23:41 -0400
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-26 17:06 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-26 12:45 -0500
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-26 17:52 +0000
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-26 21:52 +0200
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-27 03:31 -0500
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-27 13:48 +0200
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-27 12:02 +0000
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-26 22:19 +0100
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-14 10:28 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-14 22:02 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-14 18:57 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-15 05:05 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-14 22:53 -0700
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-13 12:34 -0500
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-14 13:22 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-14 10:08 -0500
Re: Epic Fail Spam@ControlQ.com - 2014-04-14 11:59 -0400
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-17 16:56 +0000
Re: Epic Fail Spam@ControlQ.com - 2014-04-17 15:16 -0400
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-17 23:59 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-18 04:38 -0700
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-18 09:17 -0400
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-18 11:44 -0500
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-18 17:06 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-18 11:41 -0500
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-18 16:55 +0000
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-18 19:20 +0200
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-20 14:52 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-18 12:21 -0500
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-20 14:36 +0000
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-20 08:17 -0700
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-20 11:35 -0500
Re: Epic Fail "Alex McDonald" <blog@rivadpm.com> - 2014-04-21 10:51 -0700
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-21 19:54 +0200
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-22 17:40 +0000
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-22 20:47 +0200
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-19 11:34 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-19 16:05 -0500
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-20 12:38 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-20 11:42 -0500
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-20 12:11 -0500
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-20 17:23 +0000
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-20 11:58 -0700
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-21 10:21 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-22 04:58 -0500
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-22 17:05 +0000
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-20 17:12 +0000
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-20 19:47 -0400
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-22 05:03 -0500
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-22 11:51 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-22 08:28 -0500
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-22 15:02 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-22 13:23 -0500
Re: Epic Fail Melzzzzz <mel@zzzzz.invalid> - 2014-04-22 19:19 +0200
Re: Epic Fail Todd Hughes <noemail@dontemailme.org> - 2014-04-10 11:24 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-10 06:55 -0500
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-10 15:50 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-10 11:02 -0500
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-10 22:31 +0200
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-11 03:55 -0500
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-10 19:08 -0400
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-10 19:03 -0400
Re: Epic Fail "Alex McDonald" <blog@rivadpm.com> - 2014-04-11 17:45 +0100
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-11 17:16 +0000
Re: Epic Fail "Alex McDonald" <blog@rivadpm.com> - 2014-04-11 18:59 +0100
Re: Epic Fail "Alex McDonald" <blog@rivadpm.com> - 2014-04-11 19:11 +0100
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-11 12:05 -0700
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-11 22:03 -0400
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-11 20:18 +0200
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-11 21:44 -0400
Re: Epic Fail visualforth@rocketmail.com - 2014-04-11 14:00 -0700
Re: Epic Fail Matthias Trute <matthias.trute@gmail.com> - 2014-04-12 01:04 -0700
Re: Epic Fail the_gavino_himself <visphatesjava@gmail.com> - 2014-04-09 16:12 -0700
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-04 23:20 +0200
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-07 17:40 +0000
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-08 00:52 +0200
Re: Epic Fail Assad Ebrahim <assadebrahim2000@gmail.com> - 2014-04-07 16:13 -0700
Re: Epic Fail Ron Aaron <rambamist@gmail.com> - 2014-04-08 06:37 +0300
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-09 01:12 +0200
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-08 10:16 +0000
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-04 17:41 -0400
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-05 02:49 +0200
Re: Epic Fail Hannu Vuolasaho <vuokkosetae@gmail.com> - 2014-04-04 17:46 -0700
Re: Epic Fail "Elizabeth D. Rather" <erather@forth.com> - 2014-04-04 21:59 -1000
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-05 08:51 +0000
Re: Epic Fail "Alex McDonald" <blog@rivadpm.com> - 2014-04-05 14:45 +0100
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-05 16:01 -0700
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-05 19:22 -0700
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-06 10:46 +0100
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-06 13:20 +0200
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-06 19:58 +0100
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-06 12:28 -0700
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-06 16:40 -0400
Re: Epic Fail "Alex McDonald" <blog@rivadpm.com> - 2014-04-06 22:04 +0100
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-06 23:25 +0200
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-06 23:48 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-06 15:17 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-07 00:08 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-06 15:34 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-07 00:29 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-06 16:01 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-07 00:58 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-06 16:29 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-07 01:33 +0200
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-07 01:58 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-06 19:33 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-07 04:40 +0200
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-07 04:25 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-06 20:19 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-07 11:23 +0200
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-07 03:24 -0500
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-07 11:18 +0200
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-07 05:20 -0500
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-07 14:49 +0200
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-07 08:43 -0500
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-07 20:27 +0200
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-07 02:57 -0500
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-07 10:00 +0000
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-07 16:10 +0200
Re: Epic Fail m.a.m.hendrix@tue.nl - 2014-04-07 07:54 -0700
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-07 22:59 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-07 15:07 -0700
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-07 15:13 -0700
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-08 00:40 +0200
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-07 01:02 +0100
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-08 10:49 -0700
Re: Epic Fail "Alex McDonald" <blog@rivadpm.com> - 2014-04-08 19:01 +0100
Re: Epic Fail "Elizabeth D. Rather" <erather@forth.com> - 2014-04-08 08:13 -1000
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-08 20:34 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-08 12:04 -0700
[OT] Haskell code Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-09 00:42 +0200
Re: [OT] Haskell code Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-08 18:14 -0700
Re: [OT] Haskell code Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-08 18:15 -0700
Re: [OT] Haskell code Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-09 03:10 +0200
Re: [OT] Haskell code Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-08 18:35 -0700
Re: [OT] Haskell code Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-09 03:17 +0200
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-06 16:48 -0500
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-06 15:30 -0700
Re: Epic Fail Lars Brinkhoff <lars.spam@nocrew.org> - 2014-04-07 11:26 +0200
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-07 05:21 -0500
Re: Epic Fail "Alex McDonald" <blog@rivadpm.com> - 2014-04-07 17:54 +0100
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-07 12:14 -0500
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-07 16:49 +0000
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-07 09:37 +0000
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-06 08:43 -0700
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-07 12:53 +0000
Re: Epic Fail mhx@iae.nl - 2014-04-06 00:09 -0700
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-06 13:12 +0000
Re: Epic Fail mhx@iae.nl - 2014-04-06 07:55 -0700
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-07 10:18 +0000
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-06 08:21 -0700
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-06 08:30 -0700
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-06 22:12 +0200
Re: Epic Fail "Elizabeth D. Rather" <erather@forth.com> - 2014-04-06 12:08 -1000
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-06 16:44 -0700
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-06 22:03 -0700
Re: Epic Fail Stefan Mauerhofer <smauerhofer@androsoft.ch> - 2014-04-07 01:29 -0700
locals in nested definitions (was: Epic Fail) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-07 16:57 +0000
Re: Epic Fail mhx@iae.nl - 2014-04-07 11:48 -0700
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-07 22:54 +0200
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-08 00:04 -0700
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-07 14:12 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-07 21:23 -0700
Re: Epic Fail "Elizabeth D. Rather" <erather@forth.com> - 2014-04-07 19:33 -1000
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-07 23:52 -0700
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-08 09:07 +0100
Re: Epic Fail "Alex McDonald" <blog@rivadpm.com> - 2014-04-08 12:35 +0100
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-08 16:21 +0000
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-08 16:33 -0400
Re: Epic Fail "Alex McDonald" <blog@rivadpm.com> - 2014-04-08 23:41 +0100
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-08 22:47 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-08 10:43 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-08 07:22 -0700
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-08 10:12 -0500
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-08 08:58 -0700
Re: Epic Fail "Elizabeth D. Rather" <erather@forth.com> - 2014-04-08 08:02 -1000
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-08 23:07 -0700
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-08 10:21 +0000
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-08 15:32 +0200
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-08 17:46 -0400
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-09 01:06 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-08 18:06 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-09 02:56 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-08 18:17 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-09 03:24 +0200
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-09 02:22 -0400
Re: Epic Fail Ron Aaron <rambamist@gmail.com> - 2014-04-09 17:07 +0300
Re: Epic Fail the_gavino_himself <visphatesjava@gmail.com> - 2014-04-09 03:48 -0700
Re: Epic Fail Ron Aaron <rambamist@gmail.com> - 2014-04-07 07:17 +0300
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-07 22:52 +0200
Re: Epic Fail Mark Wills <markwills1970@gmail.com> - 2014-04-07 03:53 -0700
Re: Epic Fail the_gavino_himself <visphatesjava@gmail.com> - 2014-04-08 16:24 -0700
Re: Epic Fail the_gavino_himself <visphatesjava@gmail.com> - 2014-04-08 16:45 -0700
Re: Epic Fail kerdezixe@gmail.com - 2014-04-29 11:15 -0700
Re: Epic Fail Laurent Laborde <kerdezixe@gmail.com> - 2014-04-29 11:21 -0700
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-29 20:46 +0200
Re: Epic Fail Laurent Laborde <kerdezixe@gmail.com> - 2014-04-29 12:27 -0700
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-29 23:13 +0200
Re: Epic Fail Laurent Laborde <kerdezixe@gmail.com> - 2014-04-30 00:04 -0700
Re: Epic Fail Mark Wills <markwills1970@gmail.com> - 2014-04-30 00:54 -0700
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-30 03:08 -0500
Re: Epic Fail Laurent Laborde <kerdezixe@gmail.com> - 2014-04-30 02:30 -0700
Re: Epic Fail AKK <akk@nospam.org> - 2014-04-29 20:48 +0200
Re: Epic Fail stephenXXX@mpeforth.com (Stephen Pelc) - 2014-04-29 19:09 +0000
Re: Epic Fail "Elizabeth D. Rather" <erather@forth.com> - 2014-04-29 09:23 -1000
Re: Epic Fail Laurent Laborde <kerdezixe@gmail.com> - 2014-04-29 12:43 -0700
Re: Epic Fail "Elizabeth D. Rather" <erather@forth.com> - 2014-04-29 11:23 -1000
Re: Epic Fail Laurent Laborde <kerdezixe@gmail.com> - 2014-04-29 22:52 -0700
Page 14 of 19 — ← Prev page 1 … 12 13 [14] 15 16 … 19 Next page →
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-04-06 23:25 +0200 |
| Message-ID | <lhsgo3$q70$1@online.de> |
| In reply to | #29333 |
Alex McDonald wrote:
> CS, academia or otherwise, have got one thing right for educating
> students for a useful career; modularity & paralellism are becoming
> (actually, have been for some time) major issues in large scale software
> development. C is no longer fit for purpose.
There's another important thing: A "language of the decade" lasts a decade.
Usually the next decade has another language of the decade. If you burn out
programmers quickly and let them drive taxi for the rest of their life,
teaching them the current language of the decade is sufficient. If you
think of teaching as long-term investment, teach them concepts, and a number
of very different languages so that they know that they don't know it all.
What quite a lot of professors dodge in the 101 course is the "understanding
the machine" part. One thing I hate about Java code (not Java itself) is
that the programmers don't understand the machine, and therefore write silly
code ("onion programming" - layers of layers of abstraction, needed to hide
the details they don't actually understand). Java itself has been created
by someone who certainly has a deep understanding of what the machine does,
and how it works, and this also explains why the early Java projects did run
on pretty weak hardware. The bloatware current Java programs are is not a
failure of the language, but a failure of teaching.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2014-04-06 23:48 +0200 |
| Message-ID | <lhsi3e$uj$1@news.albasani.net> |
| In reply to | #29334 |
On Sun, 06 Apr 2014 23:25:23 +0200
Bernd Paysan <bernd.paysan@gmx.de> wrote:
> Alex McDonald wrote:
> > CS, academia or otherwise, have got one thing right for educating
> > students for a useful career; modularity & paralellism are becoming
> > (actually, have been for some time) major issues in large scale
> > software development. C is no longer fit for purpose.
>
> There's another important thing: A "language of the decade" lasts a
> decade. Usually the next decade has another language of the decade.
> If you burn out programmers quickly and let them drive taxi for the
> rest of their life, teaching them the current language of the decade
> is sufficient. If you think of teaching as long-term investment,
> teach them concepts, and a number of very different languages so that
> they know that they don't know it all.
It is very good thing to solve same problem in several languages.
It really widens perspective of how problems are solved in most
natural way on each particular language.
>
> What quite a lot of professors dodge in the 101 course is the
> "understanding the machine" part.
Every programmer should try at least one assembler, I think.
With knowledge of assembler, knowing many other things
in order to solve real world problems is much easier
to understand.
Eg I first learned z80 assembler and when I first saw
C and Forth it was very easy to understand.
One thing I hate about Java code
> (not Java itself) is that the programmers don't understand the
> machine, and therefore write silly code ("onion programming" - layers
> of layers of abstraction, needed to hide the details they don't
> actually understand).
I don't agree here. It is actually OO that forces onion programming.
Layers of abstractions are there in design patterns:
wrapper, decorator, facade ... ;)
Java itself has been created by someone who
> certainly has a deep understanding of what the machine does, and how
> it works, and this also explains why the early Java projects did run
> on pretty weak hardware.
One thing that is needed in functional world, that is GC (lot of
closures and recursion), is not needed at all in OO world.
Languages that don't force GC (or minimize it's
use) will always perform better than languages that force usage of GC.
The bloatware current Java programs are is
> not a failure of the language, but a failure of teaching.
Well executing "hello world" in java maps several gigabytes of memory...
but implementation of Java is very good
--
Click OK to continue...
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-04-06 15:17 -0700 |
| Message-ID | <7xa9byp0gx.fsf@ruckus.brouhaha.com> |
| In reply to | #29335 |
Melzzzzz <mel@zzzzz.com> writes: > One thing that is needed in functional world, that is GC (lot of > closures and recursion), is not needed at all in OO world. Eh? Java, Python, Ruby, and even Forth aren't particularly "functional", but benefit from GC. > Languages that don't force GC (or minimize it's use) will always > perform better than languages that force usage of GC. GC done properly seems to cause a fairly minor speed hit, and a more substantial memory footprint hit. That basically means you trade software development expenses for hardware resource expenses (you need a bigger computer to run the program). With today's hardware, the tradeoff generally looks good for GC. In the 1970's it may have been the other way around.
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2014-04-07 00:08 +0200 |
| Message-ID | <lhsj8j$uj$2@news.albasani.net> |
| In reply to | #29337 |
On Sun, 06 Apr 2014 15:17:02 -0700 Paul Rubin <no.email@nospam.invalid> wrote: > Melzzzzz <mel@zzzzz.com> writes: > > One thing that is needed in functional world, that is GC (lot of > > closures and recursion), is not needed at all in OO world. > > Eh? Java, Python, Ruby, and even Forth aren't particularly > "functional", but benefit from GC. You don;t have to write free(p) but you have to write close(fd) ;) I didn't knew forth has GC? Started to learn about it after I first saw it in 1987 ;) > > > Languages that don't force GC (or minimize it's use) will always > > perform better than languages that force usage of GC. > > GC done properly seems to cause a fairly minor speed hit, and a more > substantial memory footprint hit. When allocations are small there is not much of a speed hit. Hit comes when programs allocate more memory as GC have to scan much wider area. That introduces unnecessary swapping and slowdowns and prevents scalability as nothing can run during scan period. When there is enough memory not big problem, but imagine half of program is swapped on disk and GC has to scan disk ;) That basically means you trade > software development expenses for hardware resource expenses (you > need a bigger computer to run the program). With today's hardware, > the tradeoff generally looks good for GC. In the 1970's it may have > been the other way around. Agreed. Todays hardware is very powerful that's why such things can exist in a first place ;) Hack my daughter's tablet is 2GB of ram 4 core CPU! -- Click OK to continue...
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-04-06 15:34 -0700 |
| Message-ID | <7x1txaoznp.fsf@ruckus.brouhaha.com> |
| In reply to | #29338 |
Melzzzzz <mel@zzzzz.com> writes: > I didn't knew forth has GC? Started to learn about > it after I first saw it in 1987 ;) http://www.complang.tuwien.ac.at/forth/garbage-collection.zip > Hit comes when programs allocate more memory as GC have to scan much > wider area.... nothing can run during scan period. It is not done that way any more in high performance systems.
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2014-04-07 00:29 +0200 |
| Message-ID | <lhskgu$uj$3@news.albasani.net> |
| In reply to | #29340 |
On Sun, 06 Apr 2014 15:34:34 -0700 Paul Rubin <no.email@nospam.invalid> wrote: > Melzzzzz <mel@zzzzz.com> writes: > > I didn't knew forth has GC? Started to learn about > > it after I first saw it in 1987 ;) > > http://www.complang.tuwien.ac.at/forth/garbage-collection.zip > > > Hit comes when programs allocate more memory as GC have to scan much > > wider area.... nothing can run during scan period. > > It is not done that way any more in high performance systems. How it is done, than? It surely cannot be done without another performance hit in this or other way. -- Click OK to continue...
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-04-06 16:01 -0700 |
| Message-ID | <7xob0edpv2.fsf@ruckus.brouhaha.com> |
| In reply to | #29342 |
Melzzzzz <mel@zzzzz.com> writes:
>> > wider area.... nothing can run during scan period.
> How it is done, than? It surely cannot be done without another
> performance hit in this or other way.
1. Serious GC's usually work by copying live data to a new heap and then
switching, so there's no sweep phase that touches all the garbage.
2. The copy operation is done in fairly small chunks rather frequently,
and bigger chunks less often ("generational GC"). The small collections
are very fast and the bigger ones generally aren't noticible enough to
be a problem in non-realtime systems.
3. GC can be multithreaded so some parts of it run concurrently with the
application, again decreasing visible pauses.
4. Applications are usually multithreaded and it's sometimes possible to
let some application threads keep running while others are being GC'd.
That means the application never stops doing work for the user.
5. Computers today have enough memory that swapping is a sign of serious
breakage rather than normal operation.
Yes GC has overhead, but it can be spread across the program execution
enough that the 1980s complaint of long GC pauses is a non-issue for
most applications today.
Keep in mind also that the usual alternative to GC is copying the data
around much more in the application, instead of just passing pointers.
That is also overhead.
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2014-04-07 00:58 +0200 |
| Message-ID | <lhsm5v$uj$4@news.albasani.net> |
| In reply to | #29343 |
On Sun, 06 Apr 2014 16:01:37 -0700
Paul Rubin <no.email@nospam.invalid> wrote:
> Melzzzzz <mel@zzzzz.com> writes:
> >> > wider area.... nothing can run during scan period.
> > How it is done, than? It surely cannot be done without another
> > performance hit in this or other way.
>
> 1. Serious GC's usually work by copying live data to a new heap and
> then switching, so there's no sweep phase that touches all the
> garbage.
>
> 2. The copy operation is done in fairly small chunks rather
> frequently, and bigger chunks less often ("generational GC"). The
> small collections are very fast and the bigger ones generally aren't
> noticible enough to be a problem in non-realtime systems.
>
> 3. GC can be multithreaded so some parts of it run concurrently with
> the application, again decreasing visible pauses.
I think you don't know how exactly GC works. Sweep faze can
be done in parallel with program, no question, but scanning
part cannot. Problem is not sweep but scan.
>
> 4. Applications are usually multithreaded and it's sometimes possible
> to let some application threads keep running while others are being
> GC'd. That means the application never stops doing work for the user.
Impossible without knowing exactly what application does.
It also does not knows if memory is swapped or not.
During scan faze it cannot run in parallel with program.
Parallel GC is just multithreaded GC and that does not means
parallel with application.
>
> 5. Computers today have enough memory that swapping is a sign of
> serious breakage rather than normal operation.
That is dependent on programers. Who knows what is running
on particular server. Say there are plenty of VM's
under host OS. It is easy to imagine performance breakage
in such situation.
>
> Yes GC has overhead, but it can be spread across the program execution
> enough that the 1980s complaint of long GC pauses is a non-issue for
> most applications today.
>
> Keep in mind also that the usual alternative to GC is copying the data
> around much more in the application, instead of just passing pointers.
True, but it is negligible. Imagine what compacting GC has to do:
Scan for used references than copy whole heap than update
all references in program...
--
Click OK to continue...
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-04-06 16:29 -0700 |
| Message-ID | <7xzjjy5956.fsf@ruckus.brouhaha.com> |
| In reply to | #29344 |
Melzzzzz <mel@zzzzz.com> writes: > I think you don't know how exactly GC works. Sweep faze can > be done in parallel with program, no question, but scanning > part cannot. Problem is not sweep but scan. Oh ok, by scanning you mean what is called the mark phase in mark-sweep style collectors. Yes, both parts can be done concurrently with the application, e.g. "treadmill" GC. >> some application threads keep running while others are being GC'd. > Impossible without knowing exactly what application does. All that's needed is for the objects to not interfere, which is doable if the language is set up for that. Erlang works that way (user threads are completely isolated from each other, so there can be a separate GC for each thread), for example. > It also does not knows if memory is swapped or not. During scan faze > it cannot run in parallel with program. Parallel GC is just > multithreaded GC and that does not means parallel with application. Cheng's 2001 dissertation is pretty readable and the technology has improved since then too: http://reports-archive.adm.cs.cmu.edu/anon/2001/CMU-CS-01-174.pdf > That is dependent on programers. Who knows what is running > on particular server. Say there are plenty of VM's > under host OS. It is easy to imagine performance breakage > in such situation. Normally you wouldn't run a high-memory application in that sort of environment. Smaller gc'd apps in Python, Ruby, etc. run on those things just fine. And sure, servers can be underprovisioned, but that's just broken as stated. > True, but it is negligible. Imagine what compacting GC has to do: Scan > for used references than copy whole heap than update all references in > program... That's usually done incrementally as mentioned. I think it might be efficient for you to study the literature a bit before making further pronouncements.
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2014-04-07 01:33 +0200 |
| Message-ID | <lhso87$uj$5@news.albasani.net> |
| In reply to | #29345 |
On Sun, 06 Apr 2014 16:29:57 -0700 Paul Rubin <no.email@nospam.invalid> wrote: > Melzzzzz <mel@zzzzz.com> writes: > > I think you don't know how exactly GC works. Sweep faze can > > be done in parallel with program, no question, but scanning > > part cannot. Problem is not sweep but scan. > > Oh ok, by scanning you mean what is called the mark phase in > mark-sweep style collectors. Yes, both parts can be done > concurrently with the application, e.g. "treadmill" GC. treadmill is not about that as I read it. Still > > >> some application threads keep running while others are being GC'd. > > Impossible without knowing exactly what application does. > > All that's needed is for the objects to not interfere, which is doable > if the language is set up for that. Erlang works that way (user > threads are completely isolated from each other, so there can be a > separate GC for each thread), for example. Problem is that user thread allocates all the time and accesses it's memory. GC is just another thread it cannot access application memory without locking or blocking. Locking would be highly impractical and what remains is blocking other thread while scanning memory. > > > It also does not knows if memory is swapped or not. During scan > > faze it cannot run in parallel with program. Parallel GC is just > > multithreaded GC and that does not means parallel with application. > > Cheng's 2001 dissertation is pretty readable and the technology > has improved since then too: > > http://reports-archive.adm.cs.cmu.edu/anon/2001/CMU-CS-01-174.pdf I'll look into it, but things with GC are quite simple: GC cannot access same memory region in parallel with other thread without race condition. Simple as that. > > True, but it is negligible. Imagine what compacting GC has to do: > > Scan for used references than copy whole heap than update all > > references in program... > > That's usually done incrementally as mentioned. treadmill GC does not copy. That is point of it as I read it. Incremental collection means less work for sweeping faze not for scanning faze. That also means problems if program rapidly allocates as if sweeping is delayed can cause other problems. But compacting operation requires copying of whole application heap. But seems that treadmill GC avoids that. > > I think it might be efficient for you to study the literature a bit > before making further pronouncements. I have studied GC's some years ago and made lot of thought about it. https://confluence.atlassian.com/display/DOC/Garbage+Collector+Performance+Issues -- Click OK to continue...
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2014-04-07 01:58 +0200 |
| Message-ID | <lhspmu$h8b$1@news.albasani.net> |
| In reply to | #29347 |
On Mon, 7 Apr 2014 01:33:27 +0200 Melzzzzz <mel@zzzzz.com> wrote: > On Sun, 06 Apr 2014 16:29:57 -0700 > Paul Rubin <no.email@nospam.invalid> wrote: > > > > I think it might be efficient for you to study the literature a bit > > before making further pronouncements. > > I have studied GC's some years ago and made lot of thought > about it. > https://confluence.atlassian.com/display/DOC/Garbage+Collector+Performance+Issues In this article following is inaccurate: " If you run Confluence on a VM, check that is it not using the swap file. If it does, when the JVM garbage collects it has to load the objects from the swap file into memory to clean them, and this can cause significantly longer GC pauses. Instead of using swapping, ballooning and bursting, allocate adequate memory to the VM. " It is not sweeping faze that is problem with swap as just updating internal collector data is necessary. Collector does not needs to know anything about objects except if object has finalizer. But then again swap is just memory it does not have to load anything - that does OS. Problem is actually in scanning. -- Click OK to continue...
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-04-06 19:33 -0700 |
| Message-ID | <7xlhvhuavx.fsf@ruckus.brouhaha.com> |
| In reply to | #29347 |
Melzzzzz <mel@zzzzz.com> writes: >> Erlang works that way (user threads are completely isolated from each >> other, so there can be a separate GC for each thread), > > Problem is that user thread allocates all the time and accesses > it's memory. GC is just another thread it cannot access application > memory without locking or blocking. Yes, Erlang threads (called processes in Erlang terminology) block for GC. The point is they are isolated from each other, so it is not necessary for the GC to block processes that are not being GC'd. While one process GC's, others can keep running. You're right that Baker treadmill is an in-place GC rather than copying.
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2014-04-07 04:40 +0200 |
| Message-ID | <lht36m$2fu$2@news.albasani.net> |
| In reply to | #29351 |
On Sun, 06 Apr 2014 19:33:06 -0700 Paul Rubin <no.email@nospam.invalid> wrote: > Melzzzzz <mel@zzzzz.com> writes: > >> Erlang works that way (user threads are completely isolated from > >> each other, so there can be a separate GC for each thread), > > > > Problem is that user thread allocates all the time and accesses > > it's memory. GC is just another thread it cannot access application > > memory without locking or blocking. > > Yes, Erlang threads (called processes in Erlang terminology) block for > GC. The point is they are isolated from each other, so it is not > necessary for the GC to block processes that are not being GC'd. > While one process GC's, others can keep running. Only if each thread has separate heap. That would increase price of starting threads and also means another memory manager for those heaps. But it is doable, agreed. -- Click OK to continue...
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2014-04-07 04:25 +0200 |
| Message-ID | <lht2ah$2fu$1@news.albasani.net> |
| In reply to | #29347 |
On Mon, 7 Apr 2014 01:33:27 +0200 Melzzzzz <mel@zzzzz.com> wrote: > On Sun, 06 Apr 2014 16:29:57 -0700 > Paul Rubin <no.email@nospam.invalid> wrote: > > > Melzzzzz <mel@zzzzz.com> writes: > > >> some application threads keep running while others are being > > >> GC'd. > > > Impossible without knowing exactly what application does. > > > > All that's needed is for the objects to not interfere, which is > > doable if the language is set up for that. Erlang works that way > > (user threads are completely isolated from each other, so there can > > be a separate GC for each thread), for example. > > Problem is that user thread allocates all the time and accesses > it's memory. GC is just another thread it cannot access application > memory without locking or blocking. Locking would be highly > impractical and what remains is blocking other thread > while scanning memory. Only way to implement this is to have separate heap per thread, and guarantee that thread cannot access anything besides it's own heap. But than again functional languages tend to have thousands of lightweight threads that map to single OS thread and having thousands of heaps in this case seems impractical. It is far simpler to just fork separate processes in this case. Actually threads and GC does not go well together at all. Processes and GC tend to do better in parallelism. So our functional language has to implement same thing that OS does. That is make threads into processes.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-04-06 20:19 -0700 |
| Message-ID | <7xd2gtsu5w.fsf@ruckus.brouhaha.com> |
| In reply to | #29352 |
Melzzzzz <mel@zzzzz.com> writes: > Only way to implement this is to have separate heap per thread, and > guarantee that thread cannot access anything besides it's own > heap. But than again functional languages tend to have thousands of > lightweight threads that map to single OS thread and having thousands > of heaps in this case seems impractical. That is exactly how Erlang works and it is completely practical. Any sharing between processes is an implementation optimization invisible to the user.
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2014-04-07 11:23 +0200 |
| Message-ID | <lhtqps$a1g$2@news.albasani.net> |
| In reply to | #29354 |
On Sun, 06 Apr 2014 20:19:39 -0700 Paul Rubin <no.email@nospam.invalid> wrote: > Melzzzzz <mel@zzzzz.com> writes: > > Only way to implement this is to have separate heap per thread, and > > guarantee that thread cannot access anything besides it's own > > heap. But than again functional languages tend to have thousands of > > lightweight threads that map to single OS thread and having > > thousands of heaps in this case seems impractical. > > That is exactly how Erlang works and it is completely practical. Any > sharing between processes is an implementation optimization invisible > to the user. Yes, shared memory regions could not contain any heap references so it does not have to be scanned. -- Click OK to continue...
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-04-07 03:24 -0500 |
| Message-ID | <ibOdnT8OEqEp_d_OnZ2dnUVZ8mednZ2d@supernews.com> |
| In reply to | #29347 |
Melzzzzz <mel@zzzzz.com> wrote: > On Sun, 06 Apr 2014 16:29:57 -0700 > Paul Rubin <no.email@nospam.invalid> wrote: > >> Melzzzzz <mel@zzzzz.com> writes: >> > I think you don't know how exactly GC works. Sweep faze can >> > be done in parallel with program, no question, but scanning >> > part cannot. Problem is not sweep but scan. >> >> Oh ok, by scanning you mean what is called the mark phase in >> mark-sweep style collectors. Yes, both parts can be done >> concurrently with the application, e.g. "treadmill" GC. > > treadmill is not about that as I read it. Still > >> >> some application threads keep running while others are being GC'd. >> > Impossible without knowing exactly what application does. >> >> All that's needed is for the objects to not interfere, which is doable >> if the language is set up for that. Erlang works that way (user >> threads are completely isolated from each other, so there can be a >> separate GC for each thread), for example. > > Problem is that user thread allocates all the time and accesses > it's memory. GC is just another thread it cannot access application > memory without locking or blocking. Whyever not? > I'll look into it, but things with GC are quite simple: > GC cannot access same memory region in parallel with other thread > without race condition. Simple as that. Again, why not? What stops this from working? Threads can access the same memory in parallel and do so all the time with lock-free algorithms. Of course those lock-free algorithms can be used for GC. Thes, you have to be very careful, but you always have to be very careful when writing a garbage collector. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2014-04-07 11:18 +0200 |
| Message-ID | <lhtqgr$a1g$1@news.albasani.net> |
| In reply to | #29360 |
On Mon, 07 Apr 2014 03:24:20 -0500 Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: > Melzzzzz <mel@zzzzz.com> wrote: > > On Sun, 06 Apr 2014 16:29:57 -0700 > > Paul Rubin <no.email@nospam.invalid> wrote: > > > >> Melzzzzz <mel@zzzzz.com> writes: > >> > I think you don't know how exactly GC works. Sweep faze can > >> > be done in parallel with program, no question, but scanning > >> > part cannot. Problem is not sweep but scan. > >> > >> Oh ok, by scanning you mean what is called the mark phase in > >> mark-sweep style collectors. Yes, both parts can be done > >> concurrently with the application, e.g. "treadmill" GC. > > > > treadmill is not about that as I read it. Still > > > >> >> some application threads keep running while others are being > >> >> GC'd. > >> > Impossible without knowing exactly what application does. > >> > >> All that's needed is for the objects to not interfere, which is > >> doable if the language is set up for that. Erlang works that way > >> (user threads are completely isolated from each other, so there > >> can be a separate GC for each thread), for example. > > > > Problem is that user thread allocates all the time and accesses > > it's memory. GC is just another thread it cannot access application > > memory without locking or blocking. > > Whyever not? Because memory picture must not change during scanning. When scanning for references to memory blocks, memory has to be freezed, references to memory blocks and new memory blocks must not be updated or created. Besides that every access to reference from application has to be locked! > > > I'll look into it, but things with GC are quite simple: > > GC cannot access same memory region in parallel with other thread > > without race condition. Simple as that. > > Again, why not? What stops this from working? Threads can access the > same memory in parallel and do so all the time with lock-free > algorithms. > Of course those lock-free algorithms can be used for GC. Lock free algorithms means cooperation from all threads. It is not synchronization free,and you can't have lock free algorithm in user thread. That would be even more ridiculous than simple locking on every reference access, which is also ridiculous. > Thes, you have to be very careful, but you always have to be very > careful when writing a garbage collector. Here problem is that you must be sure that picture of memory does not change during scanning. It is basically traversal of tree and you can't traverse tree while it's structure is dynamically changed. That means any access to object reference has to be synchronized which is ridiculous. -- Click OK to continue...
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-04-07 05:20 -0500 |
| Message-ID | <o-mdnUy4H5OY4d_OnZ2dnUVZ_o6dnZ2d@supernews.com> |
| In reply to | #29362 |
Melzzzzz <mel@zzzzz.com> wrote: > On Mon, 07 Apr 2014 03:24:20 -0500 > Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: > >> Melzzzzz <mel@zzzzz.com> wrote: >> > On Sun, 06 Apr 2014 16:29:57 -0700 >> > Paul Rubin <no.email@nospam.invalid> wrote: >> > >> >> Melzzzzz <mel@zzzzz.com> writes: >> >> > I think you don't know how exactly GC works. Sweep faze can >> >> > be done in parallel with program, no question, but scanning >> >> > part cannot. Problem is not sweep but scan. >> >> >> >> Oh ok, by scanning you mean what is called the mark phase in >> >> mark-sweep style collectors. Yes, both parts can be done >> >> concurrently with the application, e.g. "treadmill" GC. >> > >> > treadmill is not about that as I read it. Still >> > >> >> >> some application threads keep running while others are being >> >> >> GC'd. >> >> > Impossible without knowing exactly what application does. >> >> >> >> All that's needed is for the objects to not interfere, which is >> >> doable if the language is set up for that. Erlang works that way >> >> (user threads are completely isolated from each other, so there >> >> can be a separate GC for each thread), for example. >> > >> > Problem is that user thread allocates all the time and accesses >> > it's memory. GC is just another thread it cannot access application >> > memory without locking or blocking. >> >> Whyever not? > > Because memory picture must not change during scanning. > When scanning for references to memory blocks, memory has to be freezed, > references to memory blocks and new memory blocks must not be updated or > created. Besides that every access to reference from application has to > be locked! As long as the application accesses memory correctly and follows the GC rules it will be fine. Any compiler generating code for a garbage-collected system has to know that things will be moved under its feet. >> > I'll look into it, but things with GC are quite simple: >> > GC cannot access same memory region in parallel with other thread >> > without race condition. Simple as that. >> >> Again, why not? What stops this from working? > Threads can access the >> same memory in parallel and do so all the time with lock-free >> algorithms. >> Of course those lock-free algorithms can be used for GC. > > Lock free algorithms means cooperation from all threads. It is not > synchronization free, and you can't have lock free algorithm in user > thread. Whyever not? > That would be even more ridiculous than simple locking on every > reference access, which is also ridiculous. > >> Thes, you have to be very careful, but you always have to be very >> careful when writing a garbage collector. > > Here problem is that you must be sure that picture of memory does not > change during scanning. No. Of course mutator and collector threads can run concurrently, and they do. Sure, you are marking data that is changing, so you will miss some objects that become unreferenced. But that doesn't matter because you will get them next time. Also, mutator treads can help out by doing some of the copying. > It is basically traversal of tree and you can't traverse tree while > it's structure is dynamically changed. Of course you can, and people have been doing it for years. > That means any access to object reference has to be synchronized > which is ridiculous. Not necessarily, but you might have to go via a forwarding pointer or use some bits in the header to indicate to a mutator thread that an object has been copied. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2014-04-07 14:49 +0200 |
| Message-ID | <lhu6tl$a1g$3@news.albasani.net> |
| In reply to | #29369 |
On Mon, 07 Apr 2014 05:20:53 -0500 Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: > Melzzzzz <mel@zzzzz.com> wrote: > > On Mon, 07 Apr 2014 03:24:20 -0500 > > Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: > > > >> Melzzzzz <mel@zzzzz.com> wrote: > >> > On Sun, 06 Apr 2014 16:29:57 -0700 > >> > Paul Rubin <no.email@nospam.invalid> wrote: > >> > > >> >> Melzzzzz <mel@zzzzz.com> writes: > >> >> > I think you don't know how exactly GC works. Sweep faze can > >> >> > be done in parallel with program, no question, but scanning > >> >> > part cannot. Problem is not sweep but scan. > >> >> > >> >> Oh ok, by scanning you mean what is called the mark phase in > >> >> mark-sweep style collectors. Yes, both parts can be done > >> >> concurrently with the application, e.g. "treadmill" GC. > >> > > >> > treadmill is not about that as I read it. Still > >> > > >> >> >> some application threads keep running while others are being > >> >> >> GC'd. > >> >> > Impossible without knowing exactly what application does. > >> >> > >> >> All that's needed is for the objects to not interfere, which is > >> >> doable if the language is set up for that. Erlang works that > >> >> way (user threads are completely isolated from each other, so > >> >> there can be a separate GC for each thread), for example. > >> > > >> > Problem is that user thread allocates all the time and accesses > >> > it's memory. GC is just another thread it cannot access > >> > application memory without locking or blocking. > >> > >> Whyever not? > > > > Because memory picture must not change during scanning. > > When scanning for references to memory blocks, memory has to be > > freezed, references to memory blocks and new memory blocks must not > > be updated or created. Besides that every access to reference from > > application has to be locked! > > As long as the application accesses memory correctly and follows the > GC rules it will be fine. How this can be done? What you mean by this? Any compiler generating code for a > garbage-collected system has to know that things will be moved under > its feet. Only if application uses raw pointers. GC updates all references after move operation normally. Especially in this case GC has to stop application. -- Click OK to continue...
[toc] | [prev] | [next] | [standalone]
Page 14 of 19 — ← Prev page 1 … 12 13 [14] 15 16 … 19 Next page →
Back to top | Article view | comp.lang.forth
csiph-web