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-12-02 04:54 +0100 |
| Articles | 20 on this page of 432 — 42 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: Automatic scoping of locals (was: Epic Fail) hughaguilar96@yahoo.com - 2014-05-02 22:28 -0700
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-30 10:18 +0000
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 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-30 10:44 +0000
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-30 09:18 -0500
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-30 17:48 +0000
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-01 03:55 -0500
Re: @ and optimization Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-01 14:21 +0200
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-01 10:11 -0500
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-01 14:20 +0000
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-01 12:38 -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-11-30 01:47 -0800
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 Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-30 23:30 +0200
Re: Epic Fail Laurent Laborde <kerdezixe@gmail.com> - 2014-04-30 16:48 -0700
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-01 03:33 +0200
Re: Epic Fail Laurent Laborde <kerdezixe@gmail.com> - 2014-05-01 04:04 -0700
Re: Epic Fail Laurent Laborde <kerdezixe@gmail.com> - 2014-04-30 16:53 -0700
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-01 03:56 -0500
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 Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-30 06:45 -0500
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-30 22:02 -0400
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-01 04:04 -0500
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-01 16:08 -0400
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-02 08:12 -0500
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-02 22:33 +0200
Re: Epic Fail Mark Wills <markwills1970@gmail.com> - 2014-05-02 15:19 -0700
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-03 04:30 -0500
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-30 09:53 +0000
Forth on JVM (was: Epic Fail) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-30 09:24 +0000
Re: Forth on JVM (was: Epic Fail) jacko <jackokring@gmail.com> - 2014-04-30 17:14 -0700
Re: Forth on JVM (was: Epic Fail) jacko <jackokring@gmail.com> - 2014-04-30 17:27 -0700
Re: Forth on JVM (was: Epic Fail) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-01 15:25 +0000
Re: Forth on JVM (was: Epic Fail) "Peter Knaggs" <pjk@bcs.org.uk> - 2014-05-03 08:28 +0100
Re: Forth on JVM (was: Epic Fail) "Peter Knaggs" <pjk@bcs.org.uk> - 2014-05-01 07:52 +0100
Re: Forth on JVM Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-01 04:06 -0500
Re: Forth on JVM Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2014-05-01 14:28 +0200
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
Re: Epic failure (was Epic Fail) "WJ" <w_a_x_man@yahoo.com> - 2014-11-29 20:13 +0000
Re: Epic failure (was Epic Fail) C G Montgomery <cgm@physics.utoledo.edu> - 2014-11-29 17:15 -0500
Re: Epic failure (was Epic Fail) Pablo Hugo Reda <pabloreda@gmail.com> - 2014-11-29 14:20 -0800
Re: Epic failure awegel@arcor.de (Alexander Wegel) - 2014-11-29 23:35 +0100
Re: Epic failure (was Epic Fail) Bernd Paysan <bernd.paysan@gmx.de> - 2014-11-30 00:31 +0100
Re: Epic failure (was Epic Fail) Julian Fondren <julian.fondren@gmail.com> - 2014-11-29 17:41 -0800
Re: Epic failure (was Epic Fail) mhx@iae.nl - 2014-11-30 00:04 -0800
Re: Epic failure (was Epic Fail) mhx@iae.nl - 2014-11-30 00:09 -0800
Re: Epic failure (was Epic Fail) Bernd Paysan <bernd.paysan@gmx.de> - 2014-11-30 17:22 +0100
Re: Epic failure (was Epic Fail) "WJ" <w_a_x_man@yahoo.com> - 2014-11-30 02:13 +0000
Re: Epic failure (was Epic Fail) Julian Fondren <julian.fondren@gmail.com> - 2014-11-29 18:55 -0800
Re: Epic failure (was Epic Fail) albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-11-30 16:50 +0000
Re: Epic failure (was Epic Fail) Bernd Paysan <bernd.paysan@gmx.de> - 2014-12-01 01:22 +0100
Re: Epic failure (was Epic Fail) Melzzzzz <mel@zzzzz.com> - 2014-12-02 06:00 +0100
Re: Epic failure (was Epic Fail) Melzzzzz <mel@zzzzz.com> - 2014-12-02 06:37 +0100
Re: Epic failure (was Epic Fail) albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-12-02 12:28 +0000
Re: Epic failure Paul Rubin <no.email@nospam.invalid> - 2014-12-02 18:03 -0800
Re: Epic failure (was Epic Fail) the_gavino_himself <visphatesjava@gmail.com> - 2014-12-05 10:10 -0800
Re: Epic failure (was Epic Fail) rickman <gnuarm@gmail.com> - 2014-12-05 16:23 -0500
Re: Epic failure (was Epic Fail) Jason Damisch <jasondamisch@yahoo.com> - 2014-12-05 13:46 -0800
Re: Epic failure (was Epic Fail) "WJ" <w_a_x_man@yahoo.com> - 2014-12-01 07:54 +0000
Re: Epic failure awegel@arcor.de (Alexander Wegel) - 2014-12-01 14:02 +0100
Re: Epic failure hughaguilar96@gmail.com - 2014-12-01 15:04 -0800
Re: Epic failure awegel@arcor.de (Alexander Wegel) - 2014-12-02 04:54 +0100
Page 15 of 22 — ← Prev page 1 … 13 14 [15] 16 17 … 22 Next page →
| 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]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-04-07 08:43 -0500 |
| Message-ID | <DqidnTAe0dYZNt_OnZ2dnUVZ8sGdnZ2d@supernews.com> |
| In reply to | #29374 |
Melzzzzz <mel@zzzzz.com> wrote: > 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? I mean that the compiler has to be aware of the fact that the GC can move things and not hang on to interior pointers, for example. The compiler might have to add read barriers or write barriers. >> 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. No, it does not have to stop the application. Do I need to explain all this? You could just look it up: see researcher.ibm.com/files/us-groved/rc24504.pdf for just one example. Look at its list of references. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2014-04-07 20:27 +0200 |
| Message-ID | <lhuqls$h52$2@news.albasani.net> |
| In reply to | #29376 |
On Mon, 07 Apr 2014 08:43:32 -0500 Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: > Melzzzzz <mel@zzzzz.com> wrote: > > 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? > > I mean that the compiler has to be aware of the fact that the GC can > move things and not hang on to interior pointers, for example. The > compiler might have to add read barriers or write barriers. > > >> 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. > > No, it does not have to stop the application. Do I need to explain > all this? You could just look it up: see > researcher.ibm.com/files/us-groved/rc24504.pdf for just one example. > Look at its list of references. Heh, I didn't believe someone would venture in actually implementing this ;) Cost of pointer/reference access is pretty high in this case I guess. Unfortunately I can't find experiences with this collector as it is only implementation I found that does this. -- Click OK to continue...
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-04-07 02:57 -0500 |
| Message-ID | <hYqdndu7jd4bx9_OnZ2dnUVZ7sadnZ2d@supernews.com> |
| In reply to | #29337 |
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. > >> 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. I think that's right. If you can get away with statically- or stack-allocated memory allocation you'll get better performance than using GC, but if you're using dynamically-allocated memory GC may well be a good idea. In practice, the performance of a well-tuned collector competes well with ad hoc memory allocation schemes. In particular, a compacting collector has a super-fast allocation path: simply decrementing a pointer. As long as there's plenty of memory, collection can be done out of the critical path. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-04-07 10:00 +0000 |
| Message-ID | <53427755$0$24914$e4fe514c@dreader36.news.xs4all.nl> |
| In reply to | #29359 |
In article <hYqdndu7jd4bx9_OnZ2dnUVZ7sadnZ2d@supernews.com>, Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: >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. >> >>> 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. > >I think that's right. If you can get away with statically- or >stack-allocated memory allocation you'll get better performance than >using GC, but if you're using dynamically-allocated memory GC may well >be a good idea. In practice, the performance of a well-tuned >collector competes well with ad hoc memory allocation schemes. In >particular, a compacting collector has a super-fast allocation path: >simply decrementing a pointer. As long as there's plenty of memory, >collection can be done out of the critical path. There is of course an other way we can use todays huge memories. Just never compact and never move, but unpage memory that is freed. If you ever wrap around the Zbyte memory space, repage as needed. I can imagine this works perfectly with a page size of 5K and a collection of images of about a Megabyte. "hardware assisted garbage collection". (Oops. I miss another patent opportunity.) > >Andrew. -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-04-07 16:10 +0200 |
| Message-ID | <lhubk8$g5c$1@online.de> |
| In reply to | #29359 |
Andrew Haley wrote: > I think that's right. If you can get away with statically- or > stack-allocated memory allocation you'll get better performance than > using GC, but if you're using dynamically-allocated memory GC may well > be a good idea. In practice, the performance of a well-tuned > collector competes well with ad hoc memory allocation schemes. In > particular, a compacting collector has a super-fast allocation path: > simply decrementing a pointer. As long as there's plenty of memory, > collection can be done out of the critical path. Actually, you can use that sort of super-fast allocater even when you don't use a GC to free things, but use explicit freeing/compacting. E.g. take region-based allocation: You allocate a region at the start of a process/function that is going to use some unknown amount of memory, and when you are done, you copy the result (explicitely) into a more presistent region, and free the temporary region. Super-fast (just increment the pointer), zero memory overhead allocation (no need to remember how big the memory space was), low-overhead freeing of regions you no longer need. And as each process has its own region, there are no conflicts in multithreading environments. Anton proposed this region based allocation some time ago; I think we should add that stuff into Gforth. It's really a more Forth-like way to do these things than GC. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | m.a.m.hendrix@tue.nl |
|---|---|
| Date | 2014-04-07 07:54 -0700 |
| Message-ID | <713f2e66-c299-462c-85a3-0097a59a1ff3@googlegroups.com> |
| In reply to | #29377 |
On Monday, April 7, 2014 4:10:16 PM UTC+2, Bernd Paysan wrote: > Andrew Haley wrote: [..] > Actually, you can use that sort of super-fast allocater even when you don't > use a GC to free things, but use explicit freeing/compacting. E.g. take > region-based allocation: You allocate a region at the start of a > process/function that is going to use some unknown amount of memory, and > when you are done, you copy the result (explicitely) into a more presistent > region, and free the temporary region. Super-fast (just increment the > pointer), zero memory overhead allocation (no need to remember how big the > memory space was), low-overhead freeing of regions you no longer need. And > as each process has its own region, there are no conflicts in multithreading > environments. You mean, like ALLOT works for tasks (or the terminal) :-) -marcel
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-04-07 22:59 +0200 |
| Message-ID | <lhv3kg$b0f$3@online.de> |
| In reply to | #29378 |
m.a.m.hendrix@tue.nl wrote: > On Monday, April 7, 2014 4:10:16 PM UTC+2, Bernd Paysan wrote: >> Andrew Haley wrote: > [..] >> Actually, you can use that sort of super-fast allocater even when you >> don't >> use a GC to free things, but use explicit freeing/compacting. E.g. take >> region-based allocation: You allocate a region at the start of a >> process/function that is going to use some unknown amount of memory, and >> when you are done, you copy the result (explicitely) into a more >> presistent >> region, and free the temporary region. Super-fast (just increment the >> pointer), zero memory overhead allocation (no need to remember how big >> the >> memory space was), low-overhead freeing of regions you no longer need. >> And as each process has its own region, there are no conflicts in >> multithreading environments. > > You mean, like ALLOT works for tasks (or the terminal) :-) Yes. With the difference that you can throw away a bunch of ALLOTed things in one go. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-04-07 15:07 -0700 |
| Message-ID | <7xzjjwoktf.fsf@ruckus.brouhaha.com> |
| In reply to | #29377 |
Bernd Paysan <bernd.paysan@gmx.de> writes: > You allocate a region at the start of a process/function that is going > to use some unknown amount of memory, and when you are done, you copy > the result (explicitely) into a more presistent region You mean the application has to do this copying and adjust any pointers into the old region that exist anywhere in the system? Does the application also have to remember where the live objects are, in order to know what to copy? I'm not sure how this is different from traditional manual allocate/free.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-04-07 15:13 -0700 |
| Message-ID | <7xvbukokix.fsf@ruckus.brouhaha.com> |
| In reply to | #29409 |
Paul Rubin <no.email@nospam.invalid> writes: >> you copy the result (explicitely) into a more persistent region > You mean the application has to do this copying and adjust any pointers Well, ok, maybe I expected a little too much. As long as the result is a single object that doesn't contain any pointers that you're not willing to manually patch up, and the objects aren't shared/copied to too many places, and you rigorously follow the strategy through the whole program, then I guess it is workable.
[toc] | [prev] | [next] | [standalone]
Page 15 of 22 — ← Prev page 1 … 13 14 [15] 16 17 … 22 Next page →
Back to top | Article view | comp.lang.forth
csiph-web