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 3 of 22 — ← Prev page 1 2 [3] 4 5 … 22 Next page →
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-04-13 16:53 -0700 |
| Message-ID | <79b89b0a-750a-40fc-a966-167cf04d8648@googlegroups.com> |
| In reply to | #29606 |
On Sunday, April 13, 2014 2:50:24 AM UTC-7, Assad Ebrahim wrote: > I did not find your package easy. It would have > required that I invest quite a bit of time learning your data > structures and your way of thinking of data organisation It takes "quite a bit of time" to learn my data-structures??? I thought that stuff was super-easy. Also, I didn't know that my "way of thinking of data organisation" was any different from anybody else's (I mean, in the real world --- not comp.lang.forth where everybody seems to be oblivious of basic ideas such as lambda functions). > As a novice, the best thing that I could do was to bite the bullet and > learn to use Forth properly myself. The pay-off was that within a > short while I got the hang of it and so didn't need the Novice > package. If you were a novice, how could you be so sure of what "use Forth properly" means? I've been programming in Forth since 1984, and I've worked as a Forth programmer professionally --- I don't think I'm using Forth improperly. Believe me: if you are working professionally and have deadlines, you really can't spend time implementing an LLRB tree --- the boss is going to fire you and switch over to another language where the programmers don't spend company time dinking around with code that isn't directly related to the application program. Nowadays I work in construction. Theoretically, it is possible to build a house using only an axe, and this was done routinely up through most of the 19th century. That is not the way that we build houses in the modern era though. > Learning to use your novice package felt, for me, against the spirit > of Forth. If I wanted to use pre-built libraries for everything why > bother to learn Forth at all? why not stick with library languages? The "spirit of Forth" apparently is related to how to "use Forth properly" --- I think that you are over-impressed by Forth Inc. books such as "Starting Forth," and by listening to Elizabeth Rather tirelessly say that all Forth programs must be written from scratch so "you can define data objects to behave *exactly* the way you want them to, to solve the problem at hand." If this is the "spirit of Forth," this might have something to do with why we are discussing the subject in a thread titled: "Epic Fail." I've never heard the term "library language" before. I think you are referring to scripting languages such as Python or Perl. I have no interest in programming in those languages. They are mostly for "script kiddies" who make a career out of gluing together OPC (other people's code) that they typically don't understand, and then taking credit for the whole thing. I'm not trying to turn Forth into a scripting language --- for one thing, Forth isn't dynamic OOP, which is pretty much de-riguer for scripting languages. There is somewhat of a spectrum here. I think my novice package is in the middle. I'm just providing basic stuff that every program needs. I use linked lists a lot, so they really should be packaged rather than written from scratch every time. I use binary trees a lot too (in the past anyway, not really in any of my novice package example programs), so that went in there too. I think everybody uses arrays a lot. This is really basic stuff --- I can't imagine writing this kind of code from scratch over and over again. > Of course, others' mileage may vary, but given that you're quite > passionate about your novice package, I thought it would be useful to > post some feedback from a recent novice (under 40) who not only liked > Forth enough to learn it, but who likes it enough to be using it more > often. I'm not all that passionate about my novice package, although it does bother me when people say that it "sucks" (thanks for not being vulgar; that is why I'm responding to your post) or when Elizabeth Rather straight out lies about it: "Does '*every* application' you write use exactly the same kind of data arranged in the same way? If so, having written it once you can reuse it often. If not, you either have to rearrange your data to make it work or modify your 'general-purpose structure." I've given up on ANS-Forth and Forth-200x, so my "passion" has definitely chilled. I don't think I'm a bad Forth programmer or using Forth improperly though --- if somebody paid me to program in Forth, I would (not SwiftForth though) --- but I'm focusing on my own language in my free time now, as I have no more desire to support ANS-Forth or Forth-200x. The Forth-200x committee has made it very clear that kissing their butts is the only contribution that I (actually anybody) can ever make to Forth. Well, I'm glad that you "got the hang of Forth" in a "short while." Have you yet written any non-trivial program? Can you show it publicly, or is it proprietary?
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.invalid> |
|---|---|
| Date | 2014-04-14 02:32 +0200 |
| Message-ID | <lifab9$nf9$5@solani.org> |
| In reply to | #29620 |
On Sun, 13 Apr 2014 16:53:25 -0700 (PDT) hughaguilar96@yahoo.com wrote: You contradict yourself: > Believe me: if you are working professionally and have deadlines, you > really can't spend time implementing an LLRB tree --- the boss is > going to fire you and switch over to another language where the > programmers don't spend company time dinking around with code that > isn't directly related to the application program. > contradicts this: > > I've never heard the term "library language" before. I think you are > referring to scripting languages such as Python or Perl. I have no > interest in programming in those languages. They are mostly for > "script kiddies" who make a career out of gluing together OPC (other > people's code) that they typically don't understand, and then taking > credit for the whole thing. I'm not trying to turn Forth into a > scripting language --- for one thing, Forth isn't dynamic OOP, which > is pretty much de-riguer for scripting languages. > -- Click OK to continue...
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-04-13 17:59 -0700 |
| Message-ID | <75c6ee6f-5ef8-4f6c-bd5d-b17e18520945@googlegroups.com> |
| In reply to | #29623 |
On Sunday, April 13, 2014 5:32:41 PM UTC-7, Melzzzzz wrote: > On Sun, 13 Apr 2014 16:53:25 -0700 (PDT) > You contradict yourself: I said that there was a spectrum, and my novice package was in the middle. On one end of the spectrum, programs are written entirely from scratch every time. On the other end of the spectrum we have scripting languages such as Python that are mostly just glue for C code, with a lot of "script kiddies" gluing together code that they don't understand. My novice package is in the middle --- I provide basic stuff such as containers that are needed in essentially all programs --- but you still have to be a programmer to use it, and script kiddies will fail with it if they expect to have their program's guts already written for them. Only on comp.lang.forth is this idea difficult to understand or controversial --- most languages have myriad libraries and myriad productive programmers, but on the one hand no successful script kiddies, and on the other hand no salesperson for a commercial compiler who attacks people who write libraries of code and gets taken seriously --- I'm not trying to make Forth into a scripting language, but I do want it to usable for application programming.
[toc] | [prev] | [next] | [standalone]
| From | Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> |
|---|---|
| Date | 2014-04-14 02:00 +0100 |
| Message-ID | <klamk9h63k6c9q5ds7ssc1mttfu4i1melu@4ax.com> |
| In reply to | #29620 |
On Sun, 13 Apr 2014 16:53:25 -0700 (PDT), hughaguilar96@yahoo.com wrote: >On Sunday, April 13, 2014 2:50:24 AM UTC-7, Assad Ebrahim wrote: >> I did not find your package easy. It would have >> required that I invest quite a bit of time learning your data >> structures and your way of thinking of data organisation > >It takes "quite a bit of time" to learn my data-structures??? I thought that stuff was super-easy. > Also, I didn't know that my "way of thinking of data organisation" was any different from anybody else's Learning anyone's code takes time. Yours is no different. No aspersion to your code. Same goes with learning a library. >> As a novice, the best thing that I could do was to bite the bullet and >> learn to use Forth properly myself. The pay-off was that within a >> short while I got the hang of it and so didn't need the Novice >> package. > >If you were a novice, how could you be so sure of what "use Forth properly" means? > I've been programming in Forth since 1984, and I've worked as a Forth programmer professionally > --- I don't think I'm using Forth improperly. Novice to Forth, though not to programming itself. The notion of 'properly' is the same that anyone has of how close they are to feeling comfortable in a new language or skill. It's the basic compass of self-directed learning. Am making no claims about your use of Forth -- in any case I'm not in a position to judge that. > >There is somewhat of a spectrum here. I think my novice package is in the middle. I'm just providing basic stuff that every program needs. >I use linked lists a lot, so they really should be packaged rather than written from scratch every time. I use binary trees a lot too > (in the past anyway, not really in any of my novice package example programs), so that went in there too. I think everybody uses arrays a lot. > Yes. Middle seems about right. Now that I'm more familiar with Forth, I can look through your package and understand what's there. >> Of course, others' mileage may vary, but given that you're quite >> passionate about your novice package, I thought it would be useful to >> post some feedback from a recent novice (under 40) who not only liked >> Forth enough to learn it, but who likes it enough to be using it more >> often. > > Have you yet written any non-trivial program? Mostly exploratory. What's non-trivial for some may well be trivial for another. > Can you show it publicly, or is it proprietary? Thanks, yes I will when it's ready for critical review. - Assad
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-04-13 18:30 -0700 |
| Message-ID | <459761fe-6131-44a7-bbff-c6bff5efe033@googlegroups.com> |
| In reply to | #29626 |
On Sunday, April 13, 2014 6:00:03 PM UTC-7, Assad Ebrahim wrote: > On Sun, 13 Apr 2014 16:53:25 -0700 (PDT), hughaguilar96@yahoo.com > wrote: > > Have you yet written any non-trivial program? > > Mostly exploratory. What's non-trivial for some may well be trivial > for another. Paul Rubin described my slide-rule program as: "a lot of tedious code that anybody could write." That is actually a pretty good description of most programs, as it is rare that any particularly clever algorithms or techniques are needed. Once I got rolling, that program was pretty trivial, but this was only true because I had the novice package available --- it would be much more difficult without the novice package. I would like to see somebody who "has got the hang of Forth" do it without the novice package in the Elizabeth Rather style of programming --- all of the arithmetic stuff has already been figured out in my program, so porting it would just be a matter of changing the style of the Forth programming --- for that matter, I would like to see somebody port it into C (C style programming is actually very similar to Elizabeth Rather style Forth programming, although I think her background is COBOL and Fortran, not C). In languages such as Factor or Lisp, that program would be trivial, but execution speed would be a problem due to the inherent inefficiency of dynamic-OOP.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-04-13 14:21 +0000 |
| Message-ID | <2014Apr13.162105@mips.complang.tuwien.ac.at> |
| In reply to | #29571 |
stephenXXX@mpeforth.com (Stephen Pelc) writes:
>On Fri, 11 Apr 2014 23:10:50 -0700 (PDT), hughaguilar96@yahoo.com
>wrote:
>>By far however, the biggest blunder that Anton Ertl made in his {: was to m=
>>ake the initial values of the locals "undefined." WTF??? This is an incredi=
>>bly bad idea.
>
>Actually it's an incredibly good idea. Initialised data can be
>specified as inputs, and uninitialised locals are faster to set up.
>In addition, common practice was for locals between '|' and -- to
>be uninitialised. MPE's locals in ProForth and VFX Forth have worked
>that way for over 20 years.
And if you look at John Hayes' article on implementing { with (LOCAL)
(from 1992), it mentions that stuff already (but leaves it as an
exercise to the user).
@Article{hayes92,
author = "John R. Hayes",
title = "User-Defined Local Variable Syntax with {ANS Forth}",
journal = sigforth,
year = "1992",
volume = "4",
number = "2",
OPTpages = "19, 20, 26",
annote = "Shows how to define a nice locals syntax using the ANS
Forth locals wordset."
}
I think that the uninitialized locals are a bad idea that is
practically never needed in a system with a sufficiently capable
locals implementation; that is an implementation where you can define
a local everywhere in a definition, such that you define the local
where you have the right value for the initialization. Example:
: foo { a b -- e f }
.... ( x1 ) { c }
.... ( x2 ) { d }
.... ;
A less capable implementation of locals allows only one locals
definition that has to contain all locals, even if we don't have an
initialization value for them yet. On such an implemenation
uninitialized locals may look like a good idea (but only wrt speed).
Example:
: foo { a b | c d -- e f }
.... ( x1 ) to c
.... ( x2 ) to d
.... ;
>I am a fan of "crash early and crash often" for debugging.
Accessing an uninitialized local won't crash on VFX:
: foo { | x } x ; ok
foo . 134554408 ok
And I don't know a cheap way to implement a guaranteed crash on
accessing uninitialized locals. In any case, it's much better to
avoid the bug in the first place (through a sufficiently capable
locals implementation) than to debug it through "crash early", even if
that was available.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2013: http://www.euroforth.org/ef13/
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-04-13 21:12 -0700 |
| Message-ID | <aec948cf-34d4-4dfd-aee4-1d43999a838a@googlegroups.com> |
| In reply to | #29611 |
On Sunday, April 13, 2014 7:21:05 AM UTC-7, Anton Ertl wrote:
> I think that the uninitialized locals are a bad idea that is
> practically never needed in a system with a sufficiently capable
> locals implementation; that is an implementation where you can define
> a local everywhere in a definition, such that you define the local
> where you have the right value for the initialization. Example:
>
> : foo { a b -- e f }
> .... ( x1 ) { c }
> .... ( x2 ) { d }
> .... ;
This is what C does, although explicitly initializing the local is option (but almost always done) and the local will be set to whatever is in memory if it is not explicitly initialized (which I consider to be a bad idea).
Doing this in Forth is very difficult however. In C, it is possible to have local definitions inside of {} blocks of statements, in which case the local only exists inside of that lexical block. Forth doesn't have lexical blocks though --- so I don't really see this ever being done in Forth.
> A less capable implementation of locals allows only one locals
> definition that has to contain all locals, even if we don't have an
> initialization value for them yet. On such an implemenation
> uninitialized locals may look like a good idea (but only wrt speed).
> Example:
>
> : foo { a b | c d -- e f }
> .... ( x1 ) to c
> .... ( x2 ) to d
> .... ;
All that I'm saying is that the locals after the | should have a default initialization value (zero is the obvious choice). This way, if the programmer forgets to initialize them explicitly, the program is deterministic (I was misspelling this as "determinite" previously).
I don't understand why this is controversial. This is basic defensive-design.
An optimizing compiler should be able to see that the local has been initialized prior to being referenced, and get rid of the automatic initialization to zero, which should help the speed slightly (although that automatic initialization to zero is such a tiny piece of code that it is hardly worthwhile to bother with removing it).
This seems like a reasonable solution. The only unreasonable solution was what you did --- define the local value as being "undefined" --- that is why I described it as a "blunder."
I don't really use locals very much. Mostly I use locals as a work-around for the problem in ANS-Forth that allows the control-flow stack to be the data stack (this was done to allow SwiftForth to be ANS-Forth compliant without any modification). An example of this is 1ARRAY, 2ARRAY, etc..
My whole novice package is just a big mess of work-arounds for bugs in Forth implementations and/or bugs in the ANS-Forth standard. Most likely the reason why Elizabeth Rather hates my novice package so much, is because all of these work-arounds tend to shine a spotlight on the problems that they are working around.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-04-23 12:49 +0000 |
| Message-ID | <2014Apr23.144913@mips.complang.tuwien.ac.at> |
| In reply to | #29628 |
hughaguilar96@yahoo.com writes:
>On Sunday, April 13, 2014 7:21:05 AM UTC-7, Anton Ertl wrote:
>> I think that the uninitialized locals are a bad idea that is
>> practically never needed in a system with a sufficiently capable
>> locals implementation; that is an implementation where you can define
>> a local everywhere in a definition, such that you define the local
>> where you have the right value for the initialization. Example:
>>=20
>> : foo { a b -- e f }
>> .... ( x1 ) { c }
>> .... ( x2 ) { d }
>> .... ;
>
>This is what C does, although explicitly initializing the local is option (=
>but almost always done) and the local will be set to whatever is in memory =
>if it is not explicitly initialized (which I consider to be a bad idea).
>
>Doing this in Forth is very difficult however. In C, it is possible to have=
> local definitions inside of {} blocks of statements, in which case the loc=
>al only exists inside of that lexical block. Forth doesn't have lexical blo=
>cks though --- so I don't really see this ever being done in Forth.
This has been in Gforth for 20 years [ertl94l]. We use
domination-based scoping: A local is visible in all places that can
*only* be reached through the definition of the local. In most cases
block-based scoping is a conservative approximation of
domination-based scoping, and where it isn't, it is a bug waiting to
happen. E.g., consider
if (f) goto l;
{
int v=5;
l: printf("%d", v);
}
v is not be visible after "l:" with domination-based scoping. With
block-based scoping it is, but produces an access to an uninitialized
variable, even though the variable definition includes an initializer.
And here is an example where domination-based scoping extends the
scope beyond block-based scoping:
begin { v }
... while
... repeat
v
Interestingly, some C descendents have implemented a restricted
version of that with
for (int i=...; ...; ...) {
...
}
printf("%d", i);
@InProceedings{ertl94l,
author = "M. Anton Ertl",
title = "Automatic Scoping of Local Variables",
booktitle = "EuroForth~'94 Conference Proceedings",
year = "1994",
address = "Winchester, UK",
pages = "31--37",
url = "http://www.complang.tuwien.ac.at/papers/ertl94l.ps.gz",
abstract = "In the process of lifting the restrictions on using
locals in Forth, an interesting problem poses
itself: What does it mean if a local is defined in a
control structure? Where is the local visible? Since
the user can create every possible control structure
in ANS Forth, the answer is not as simple as it may
seem. Ideally, the local is visible at a place if
the control flow {\em must} pass through the
definition of the local to reach this place. This
paper discusses locals in general, the visibility
problem, its solution, the consequences and the
implementation as well as related programming style
questions."
}
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2013: http://www.euroforth.org/ef13/
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-04-28 21:02 -0700 |
| Message-ID | <d32dc22b-b096-4cd6-af37-e19c3bef79d9@googlegroups.com> |
| In reply to | #29794 |
On Wednesday, April 23, 2014 5:49:13 AM UTC-7, Anton Ertl wrote:
> hughaguilar96@yahoo.com writes:
> abstract = "In the process of lifting the restrictions on using
> locals in Forth, an interesting problem poses
> itself: What does it mean if a local is defined in a
> control structure? Where is the local visible? Since
> the user can create every possible control structure
> in ANS Forth, the answer is not as simple as it may
> seem. Ideally, the local is visible at a place if
> the control flow {\em must} pass through the
> definition of the local to reach this place. This
> paper discusses locals in general, the visibility
> problem, its solution, the consequences and the
> implementation as well as related programming style
> questions."
> }
You seem to be saying that a local with the same name as an already-existing local will "dominate" --- but this doesn't tell me at all how a local will go out of scope and the pre-existing local come back into scope.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-04-29 14:49 +0000 |
| Subject | Automatic scoping of locals (was: Epic Fail) |
| Message-ID | <2014Apr29.164955@mips.complang.tuwien.ac.at> |
| In reply to | #29948 |
hughaguilar96@yahoo.com writes:
>On Wednesday, April 23, 2014 5:49:13 AM UTC-7, Anton Ertl wrote:
>> hughaguilar96@yahoo.com writes:
>> abstract = "In the process of lifting the restrictions on using
>> locals in Forth, an interesting problem poses
>> itself: What does it mean if a local is defined in a
>> control structure? Where is the local visible? Since
>> the user can create every possible control structure
>> in ANS Forth, the answer is not as simple as it may
>> seem. Ideally, the local is visible at a place if
>> the control flow {\em must} pass through the
>> definition of the local to reach this place. This
>> paper discusses locals in general, the visibility
>> problem, its solution, the consequences and the
>> implementation as well as related programming style
>> questions."
>> }
>
>You seem to be saying that a local with the same name as an already-existing local will "dominate" --- but this doesn't tell me at all how a local will go out of scope and the pre-existing local come back into scope.
From the abstract above:
|the local is visible at a place if the control flow {\em must} pass
|through the definition of the local to reach this place
This is dominance, BTW
<http://en.wikipedia.org/wiki/Dominator_(graph_theory)>; it does not
matter whether a same-named local is visible at the place of the
definition.
A local goes out of scope if the control flow joins a control flow
that did not go through the definition of the local. E.g.:
if { l } ... ( l visible ) else ( l not visible ) then ( l not visible )
if { l } ... ( l visible ) then ( l not visible )
begin { l1 } ( l1 visible ) while { l2 } ( l1 l2 visible ) repeat ( l1 visible )
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2013: http://www.euroforth.org/ef13/
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-05-02 22:28 -0700 |
| Subject | Re: Automatic scoping of locals (was: Epic Fail) |
| Message-ID | <952d6a97-78a7-4089-a083-dbdfa9b24d64@googlegroups.com> |
| In reply to | #29964 |
On Tuesday, April 29, 2014 7:49:55 AM UTC-7, Anton Ertl wrote:
> |the local is visible at a place if the control flow {\em must} pass
> |through the definition of the local to reach this place
>
> This is dominance, BTW
> <http://en.wikipedia.org/wiki/Dominator_(graph_theory)>; it does not
> matter whether a same-named local is visible at the place of the
> definition.
>
> A local goes out of scope if the control flow joins a control flow
> that did not go through the definition of the local. E.g.:
>
> if { l } ... ( l visible ) else ( l not visible ) then ( l not visible )
> if { l } ... ( l visible ) then ( l not visible )
> begin { l1 } ( l1 visible ) while { l2 } ( l1 l2 visible ) repeat ( l1 visible )
Well, I had never heard of this before.
I don't think that I will have any thing like this in my language. I'll just require that all of the locals for the function be declared and initialized at the beginning of the function, and some of them may not ever get used if they are only referenced inside of some control-flow path that doesn't execute.
I don't see that your system could result in any advantage in either readability of the source-code or efficiency of the generated code.
Actually, I don't think this is going to work with my quotations --- I need to have just one stack-frame pointer to stuff inside of the fat-xt of the quotation --- I definitely can't remove locals from the stack while the function is still executing, because there might be a quotation still live that references those locals. I could make locals go out of scope, in the sense that they can't be referenced anymore, but as I said I don't see any advantage in readability in doing this --- the only result will be that the user will try to reference a local that is out of scope and be confused as to why he is getting an abort with an error message, a source of confusion that can easily be avoided by never having any local go out of scope (until the ; of course, when all the locals go out of scope).
If it is possible to implement what you are describing and also have quotations, it would be very complicated --- thinking about this stuff makes my head hurt, so I'm going to ignore it --- like I said, there is no advantage to it anyway, so it is just unnecessary complication, and that clashes hard with my keep-it-simple philosophy.
If it is impossible (as I suspect) to have your system and also have quotations, then you are shooting yourself in the foot by having your system, because quotations have practical value and your system doesn't. Have you already put your system into the Forth-200x standard?
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-04-10 03:04 -0500 |
| Message-ID | <wICdnd4kQsI3zdvOnZ2dnUVZ_uqdnZ2d@supernews.com> |
| In reply to | #29498 |
Bernd Paysan <bernd.paysan@gmx.de> wrote: > Andrew Haley wrote: > >> Bernd Paysan <bernd.paysan@gmx.de> wrote: >> >>> I'd say that on typical workstation processors, which use two's >>> complement on integers, and don't trap on overflow, -fwrapv would >>> be the "program execution in a documented manner characteristic of >>> the environment". Whether you produce an unpredictable result or >>> choose to document what you do and produce a predictable result, >>> is up to you as compiler maintainer. Thus it's a quality of >>> implementation issue. >> >> It is, and there is more than one way to measure quality: some people >> prefer to write well-defined code rather than depend on any >> nonportable assumptions, and allow the compiler to optimize as much as >> possible. It's an area in which GCC really shines: in this case the >> user gets to choose (with -fwrapv) which they prefer. > > Come on, every year we add another workaround against GCC > pessimizations that had been added in the newest GCC versions (and > when they go away, the result is still worse than before). Code > that was fine and fast before. This is a straw man: If GCC really > would generate faster code, your argument would have some substance, > but in fact, it gets slower and slower, and more difficult to get > GCC to compile optimal code. I don't believe that this is generally true: AIUI code quality is measured regularly and is not decreasing. > In any case: The reason why we use GCC to compile Gforth is because > we need a portable assembler. The same is true for a lot of other > FOSS projects. If it's not giving us that feature, it is the wrong > compiler to use, and we either have to search for something better > (apparently the LLVM people aren't doing it, eithr), or we have to > do it ourselves. Exactly. If you are so sure you are right, do the experiment. The sources of GCC and other compilers are there for you to use. Start with that, disable out the optimizations you don't like, and we shall see if the world falls on the result with grateful thanks. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-04-11 17:23 +0000 |
| Message-ID | <2014Apr11.192347@mips.complang.tuwien.ac.at> |
| In reply to | #29504 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Bernd Paysan <bernd.paysan@gmx.de> wrote:
>> Come on, every year we add another workaround against GCC
>> pessimizations that had been added in the newest GCC versions (and
>> when they go away, the result is still worse than before). Code
>> that was fine and fast before. This is a straw man: If GCC really
>> would generate faster code, your argument would have some substance,
>> but in fact, it gets slower and slower, and more difficult to get
>> GCC to compile optimal code.
>
>I don't believe that this is generally true: AIUI code quality is
>measured regularly and is not decreasing.
Looking at Figure 7 and 8 of
http://www.complang.tuwien.ac.at/anton/euroforth/ef09/papers/ertl.pdf
you can see that Gforth 0.6.2 is much slower on newer gccs than on
older ones. For 0.7.0 we worked around the reasons for these
slowdowns (but did not always succeed), so it does ok on most newer
gcc versions (but not all), but that's not GCC's merit. And yet, even
for 0.7.0 gcc-2.95 is the fastest gcc version on the IA-32 Xeon 5450.
How do you measure code quality?
>> In any case: The reason why we use GCC to compile Gforth is because
>> we need a portable assembler. The same is true for a lot of other
>> FOSS projects. If it's not giving us that feature, it is the wrong
>> compiler to use, and we either have to search for something better
>> (apparently the LLVM people aren't doing it, eithr), or we have to
>> do it ourselves.
>
>Exactly. If you are so sure you are right, do the experiment. The
>sources of GCC and other compilers are there for you to use. Start
>with that, disable out the optimizations you don't like, and we shall
>see if the world falls on the result with grateful thanks.
Yes, I have thought about that.
If it was just as simple as disabling some "optimizations", sure, why
not. But I suspect it's not so simple, and that the spirit of
miscompilation is deeply embedded in gcc these days, and it would be a
lot of work to root it out.
Anyway, the reason why we used gcc is because it was a good way to
combine our goals of portability and efficiency, and to avoid having
to get involved with native-code compilers and their retargeting
issues. If I get involved with writing a native-code compilers, I
will do one for Forth; this is probably much less work than cleaning
up gcc, and it will result in a faster Forth system.
Linux might be a better project for your suggestion. For them
switching languages is probably out of the question, and they probably
have the manpower to write a proper C compiler, and the bitkeeper-git
story shows that they are willing to do their own tools if necessary.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2013: http://www.euroforth.org/ef13/
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-04-11 21:42 +0200 |
| Message-ID | <li9gid$pvu$1@online.de> |
| In reply to | #29530 |
Anton Ertl wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Bernd Paysan <bernd.paysan@gmx.de> wrote: >>> Come on, every year we add another workaround against GCC >>> pessimizations that had been added in the newest GCC versions (and >>> when they go away, the result is still worse than before). Code >>> that was fine and fast before. This is a straw man: If GCC really >>> would generate faster code, your argument would have some substance, >>> but in fact, it gets slower and slower, and more difficult to get >>> GCC to compile optimal code. >> >>I don't believe that this is generally true: AIUI code quality is >>measured regularly and is not decreasing. > > Looking at Figure 7 and 8 of > > http://www.complang.tuwien.ac.at/anton/euroforth/ef09/papers/ertl.pdf > > you can see that Gforth 0.6.2 is much slower on newer gccs than on > older ones. For 0.7.0 we worked around the reasons for these > slowdowns (but did not always succeed), so it does ok on most newer > gcc versions (but not all), but that's not GCC's merit. And yet, even > for 0.7.0 gcc-2.95 is the fastest gcc version on the IA-32 Xeon 5450. In the meantime, we have even more fixes, which severely affect speed on various platforms. When I look at my ARM results, the speedup from starting with Gforth on Android to today is a factor of 4 (same processor). Note that many of these problems aren't visible on x86, because we deal only with things we notice. We have this nice see-code <word> to display how Gforth's actually executed code looks like. This gives a lot of insight, and we did that sort of stuff right from the beginning. Fortunately, Forth primitives are rather small and therefore, you can judge if the compiler did a good job. I strongly recommend the GCC team simply uses Gforth as test case and looks at the code they produce. It's really silly simple code which is easy to compile in the best possible way (early GCC 2.x already did a very good job). It is far more complicated to fix things if you have a performance regression in Keccak or Ed25519: These compile to a lot of code, and it's no longer obvious what's going wrong. But Keccak especially for 32 bits is simply 2 times slower on GCC 4.8 than on GCC 4.7. Obviously, the author did optimize it for the then-current GCC when the competiton still was ongoing, but we users are lost now (or we generate a .S file once and use that). -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Spam@ControlQ.com |
|---|---|
| Date | 2014-04-11 16:13 -0400 |
| Message-ID | <alpine.BSF.2.00.1404111611490.3876@yoko.controlq.com> |
| In reply to | #29539 |
On Fri, 11 Apr 2014, Bernd Paysan wrote: > Anton Ertl wrote: > >> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>> Bernd Paysan <bernd.paysan@gmx.de> wrote: >>>> Come on, every year we add another workaround against GCC >>>> pessimizations that had been added in the newest GCC versions (and >>>> when they go away, the result is still worse than before). Code >>>> that was fine and fast before. This is a straw man: If GCC really >>>> would generate faster code, your argument would have some substance, >>>> but in fact, it gets slower and slower, and more difficult to get >>>> GCC to compile optimal code. >>> >>> I don't believe that this is generally true: AIUI code quality is >>> measured regularly and is not decreasing. >> >> Looking at Figure 7 and 8 of >> >> http://www.complang.tuwien.ac.at/anton/euroforth/ef09/papers/ertl.pdf >> >> you can see that Gforth 0.6.2 is much slower on newer gccs than on >> older ones. For 0.7.0 we worked around the reasons for these >> slowdowns (but did not always succeed), so it does ok on most newer >> gcc versions (but not all), but that's not GCC's merit. And yet, even >> for 0.7.0 gcc-2.95 is the fastest gcc version on the IA-32 Xeon 5450. > > In the meantime, we have even more fixes, which severely affect speed on > various platforms. When I look at my ARM results, the speedup from starting > with Gforth on Android to today is a factor of 4 (same processor). Note > that many of these problems aren't visible on x86, because we deal only with > things we notice. > > We have this nice see-code <word> to display how Gforth's actually executed > code looks like. This gives a lot of insight, and we did that sort of stuff > right from the beginning. Fortunately, Forth primitives are rather small > and therefore, you can judge if the compiler did a good job. > > I strongly recommend the GCC team simply uses Gforth as test case and looks > at the code they produce. It's really silly simple code which is easy to > compile in the best possible way (early GCC 2.x already did a very good > job). > > It is far more complicated to fix things if you have a performance > regression in Keccak or Ed25519: These compile to a lot of code, and it's no > longer obvious what's going wrong. But Keccak especially for 32 bits is > simply 2 times slower on GCC 4.8 than on GCC 4.7. Obviously, the author did > optimize it for the then-current GCC when the competiton still was ongoing, > but we users are lost now (or we generate a .S file once and use that). > > Of course, this brings up the inevitable question, will Gforth compile with CLANG/LLVM, and if not, what features unique to GCC are being used?? Just wondering. Cheers, Rob.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-04-11 22:15 +0200 |
| Message-ID | <li9igi$v2i$1@online.de> |
| In reply to | #29540 |
Spam@ControlQ.com wrote: > Of course, this brings up the inevitable question, will Gforth compile > with CLANG/LLVM, and if not, what features unique to GCC are being used?? It does, the result is even worse than GCC. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-04-13 16:10 +0000 |
| Message-ID | <2014Apr13.181030@mips.complang.tuwien.ac.at> |
| In reply to | #29540 |
Spam@ControlQ.com writes:
>Of course, this brings up the inevitable question, will Gforth compile
>with CLANG/LLVM, and if not, what features unique to GCC are being used??
I tried it with llvm-gcc (i.e., pre-Clang), and there was some minor
stuff that needed changes. The result was incredibly slow (factor of
6 or so), and apparently that version of llvm-gcc implemented
labels-as-values as integers and the corresponding goto * as switch
over direct gotos. There probably were other inefficiencies.
I also tried out Intel's C compiler many years ago. It crashed (the
compiler; it did not get around to producing code).
I also tried tcc. It required a few changes, like llvm-gcc, and
produced slow code, but the latter was to be expected.
Anyway, these are not alternatives. The LLVM maintainers are under
the same evil spell as the gcc maintainers
<http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html>.
The Intel compiler is proprietary.
As for tcc, gforth needs register allocation and copy propagation, and
tcc does not do that. What's worse, Fabrice Bellard is no longer
working on it, and while there seem to be people working on it, the
future prospects are unclear.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2013: http://www.euroforth.org/ef13/
[toc] | [prev] | [next] | [standalone]
| From | Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> |
|---|---|
| Date | 2014-04-13 18:42 +0100 |
| Message-ID | <27ilk9dvau3o08tmi9ccedohs8j8oujac2@4ax.com> |
| In reply to | #29613 |
On Sun, 13 Apr 2014 16:10:30 GMT, anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: > >Anyway, these are not alternatives. The LLVM maintainers are under >the same evil spell as the gcc maintainers ><http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html>. >The Intel compiler is proprietary. > Thanks for the interesting article reference. Is the below a fair representation of your and Bernd's point of view? (A1) we want some of the optimisations that optimising compilers produce (A2) but we don't want them to do so at the expense of taking too many liberties with the code (A3) we'd rather agree that if we want to improve code beyond what a non-libertine compiler could legitimately do, then we must take on that further improvement ourselves using profilers and targeted improvements ourselves. And would this be a reasonable representation of a ' modern compiler maintainer's point of view? (B1) We are willing to sacrifice the (quaint) notion that C is a portable assembler to a 'higher' mission (see B2 and B3). If C were a portable assembler, we would not be able to treat it as an abstract language with a fixed specification and therefore we would not be able to run machine independent optimisations, which would cut out a large part of modern compiler optimisation theory. (B2) We're actually not all that interested in C anyway --- what we would really like is to be able to take *any* language, transform it to a machine independent intermediate language, and then write out 'optimised' code to any given target machine. So what we're after is a universal middle-language, with reasonably sound translators from C, Fortran, C++, Objective-C, even Java, maybe even Python, into it, and then reasonably sound translators from this middle language into any of a vast number of machine languages. (B3) The only way to do the above is to be free to bend C into a reasonably conformant language so that the unlimited flexibility that C gives a programmer is restrained. Unlimited flexibility cannot be guaranteed to automaticaly convert correctly. Our mission is the automation of programming to allow a comprehensive abstraction layer to be able to sit between high level languages and the machine. - Assad
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-04-13 23:44 +0200 |
| Message-ID | <lif0fc$rk$1@online.de> |
| In reply to | #29616 |
Assad Ebrahim wrote:
> Thanks for the interesting article reference.
>
> Is the below a fair representation of your and Bernd's point of view?
>
> (A1) we want some of the optimisations that optimising compilers
> produce
>
> (A2) but we don't want them to do so at the expense of taking too
> many liberties with the code
Let's rephrase it: I want Forth's primitives to be tightly specified, i.e.
there is not much place for "is undefined". Numbers are either unsigned or
two's complement, and wrap around (Forth's dual use of + and - really makes
only sense in two's complement). Addresses are either in memory, or they
produce a -9 THROW on access. If the compiler does an optimization, there
must be a proof that the resulting behavior is equivalent to the unoptimized
code.
There are some corner cases, which Stephen called "the volatile issue": Is
foo @ foo @
identical to
foo @ dup
? Actually, it isn't. foo @ dup shall result in two times the same result,
no matter if there is a race condition with another process, while foo @ foo
@ *should* have different results in that case. AFAIK, some earlier
versions of VFX did not distinguish between both options, and thereby
miscompiled Andrew's multithreaded program. I'm deliberately saying
"miscompiled", because Andrew was surprised by the result, and he complained
to Stephen, who gave the bug a name ("the volatile issue").
The problem is still there, this is apparently difficult for VFX to fix.
The code looks a bit different:
variable foo
: wait ( -- result ) foo @ begin foo @ tuck <> until ;
The loop compiles to
( 080BF350 3B1D40240A08 ) CMP EBX, [080A2440]
( 080BF356 8B1D40240A08 ) MOV EBX, [080A2440]
( 080BF35C 74F2 ) JZ/E 080BF350
which accesses foo twice, and therefore you might have a race condition.
> (A3) we'd rather agree that if we want to improve code beyond what a
> non-libertine compiler could legitimately do, then we must take on
> that further improvement ourselves using profilers and targeted
> improvements ourselves.
Compilers can't do "do what I mean", they can only do "do what I say". To
get work done, you need to apply Confucius Lunyu 13.3, "to rectify the
names" (yes, it goes back far beyond the invention of the computer).
http://wengu.tartarie.com/wg/wengu.php?l=Lunyu&no=320
In terms of a computer language, 《必也正名乎》 "to rectify the names" means that
the operations (in Forth: words) have a well-specified meaning. If you have
such a well-specified meaning of a Forth word, you, as programmer, can write
what you want to achieve, and the compiler is able to optimize what you have
written without changing its meaning.
That is one of the fundamental part of Confucianism (that's why he says it's
the first thing you need to do), and he's absolutely right!
> And would this be a reasonable representation of a ' modern compiler
> maintainer's point of view?
>
> (B1) We are willing to sacrifice the (quaint) notion that C is a
> portable assembler to a 'higher' mission (see B2 and B3). If C were a
> portable assembler, we would not be able to treat it as an abstract
> language with a fixed specification and therefore we would not be able
> to run machine independent optimisations, which would cut out a large
> part of modern compiler optimisation theory.
No, this C as portable assembler would just require to fix the specification
(follow Lunyu 13.3), i.e. define what's left undefined by the standard. The
really bad thing with GCC is that Andrew Haley tells us that Gforth is not
written in GCC, but GCC actually is a moving target, and therefore, he can't
tell us what we need to change. Gforth was originally written in GCC 2.4,
but certainly is not in GCC 4.9, because the GCC maintainer decide to change
the meaning of things for every subrelease. If they had documented it at
all; but even documentation is useless - they change it. I don't like
arguing with Humpty Dumpty (as in "Through the Looking Glass"), because he
has his own, weird definitions of terms. That's clearly breaking Lunyu
13.3, and in fact, in Wonderland, you can't get things done (and if you want
to stay in the same place, you have to run as fast as you can, just as you
have if you write C programs and want them to continue to run with changing
GCC versions ;-).
> (B2) We're actually not all that interested in C anyway --- what we
> would really like is to be able to take *any* language, transform it
> to a machine independent intermediate language, and then write out
> 'optimised' code to any given target machine. So what we're after is
> a universal middle-language, with reasonably sound translators from C,
> Fortran, C++, Objective-C, even Java, maybe even Python, into it, and
> then reasonably sound translators from this middle language into any
> of a vast number of machine languages.
That part is a good goal for a compiler suite; however, this absolutely
requires that it is a well-specified portable assembler. C might be sloppy
about one's and two's complement, but Java e.g. isn't. In Java, bytes are 8
bit bytes (yes, it has a data type called byte, which is a very sensible
thing to have!), integers are two's complement, with 32 bit size (longs 64),
and so on; if you want to compile Java, you must convert it to a much better
specified intermediate language, anyways.
> (B3) The only way to do the above is to be free to bend C into a
> reasonably conformant language so that the unlimited flexibility that
> C gives a programmer is restrained. Unlimited flexibility cannot be
> guaranteed to automaticaly convert correctly. Our mission is the
> automation of programming to allow a comprehensive abstraction layer
> to be able to sit between high level languages and the machine.
Actually, you are free to do so. Wherever the C standard says "is
undefined", it's up to the implementor to specify what his compiler does.
He can say something, like "signed integers are two's complement, and they
wrap around on overflow". As a compiler should not intentionally break
existing programs, this also means that you don't have to write it down in
the spec: If it was that way in the past, you are not allowed to change it.
I think we have to bite the bullet and at least write backends for popular
CPUs like amd64 and ARM (starting with v5). Of course this will be a Forth
compiler. For bootstrapping, our idea is to write a compiler for images,
i.e. you can turn an image into an engine, compiling only the things you
need. That means we will have everything every other compiler user will
need: an incremental compiler for JITs, and a batch compiler for images
(which would be the intermediate language).
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-04-13 20:33 -0400 |
| Message-ID | <op.xd96hqwy6zenlw@localhost> |
| In reply to | #29617 |
On Sun, 13 Apr 2014 17:44:11 -0400, Bernd Paysan <bernd.paysan@gmx.de> wrote: > There are some corner cases, which Stephen called "the volatile issue": That's a lovely, lovely, lovely example. So, you guys do learn stuff from C! > Is > > foo @ foo @ > > identical to > > foo @ dup > > ? Actually, it isn't. foo @ dup shall result in two times the same > result, no matter if there is a race condition with another process, > while foo @ foo @ *should* have different results in that case. Exactly. In C, you'd use the "volatile" keyword to prevent the compiler from generating code that would optimize away the second fetch of a C variable or multiple dereferences of a pointer etc., i.e., the conversion of the second "foo @" to "dup" in Forth is an optimization. This is only for things which are modified outside the scope of C, i.e., beyond C's control. The same thing applies here for Forth, e.g., if the address is to memory mapped device which updates the value at foo repeatedly, then the Forth context doesn't have any way to determine the "foo @" is not simply a "dup" and shouldn't be optimized. Someone must tell the Forth context that the second "foo @" shouldn't be optimized, when a Forth optimizer is involved. The other option is no optimization. That would seem more plausible since Forth likely doesn't have any syntax to clarify the issue. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
Page 3 of 22 — ← Prev page 1 2 [3] 4 5 … 22 Next page →
Back to top | Article view | comp.lang.forth
csiph-web