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 17 of 22 — ← Prev page 1 … 15 16 [17] 18 19 … 22 Next page →
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-04-07 09:37 +0000 |
| Message-ID | <534271ec$0$24914$e4fe514c@dreader36.news.xs4all.nl> |
| In reply to | #29330 |
In article <7x7g72w93a.fsf@ruckus.brouhaha.com>, Paul Rubin <no.email@nospam.invalid> wrote: >Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> writes: >> However, when a pair of courses are offered (e.g. CS 101 and 102), C >> was often the language of the first course, and then C++ was >> introduced in the second to set the scene for object oriented design. > >I'm terrified to learn that C or C++ was ever used in academia except >maybe in some context like embedded development. The MIT SICP >(Scheme-based) curriculum was popular in the 1980's-1990's and now MIT >is using Python while CMU is using ML. The ML approach sounded >like it was working well: > >https://existentialtype.wordpress.com/2011/03/15/teaching-fp-to-freshmen/ > >"Object-oriented programming is eliminated from the introductory >curriculum, because it is both anti-modular and anti-parallel by its >very nature, and hence unsuitable for our purposes. A proposed new >course on object-oriented design methodology will be offered at the >sophomore level for those students who wish to study this topic." When working with the transputers I investigated the combination of processes and objects. (There is even a paper about it in 1994 Eurosim conference "Massively Parallel Processing".) If you map an object to a process, and work with real messages that are sent over channels, and realize that classes don't really exist, only objects exist, you can get pretty far. I'd say it would be pretty suitable for an embedded application too. This goes back to the original paradigm of objects: independant parts of a program with minimal interaction. That Java c.s has gone the opposite direction is another story. So while the decision may be correct, I'm not happy with the wording of it. Groetjes Albert -- 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 | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-04-06 08:43 -0700 |
| Message-ID | <856803cc-625b-4d2d-bcfc-f9b372e21dd1@googlegroups.com> |
| In reply to | #29318 |
On Sunday, April 6, 2014 2:46:49 AM UTC-7, Assad Ebrahim wrote: > On Sat, 5 Apr 2014 19:22:09 -0700 (PDT), hughaguilar96@yahoo.com > wrote: > >On Saturday, April 5, 2014 4:01:08 PM UTC-7, Paul Rubin wrote: > > >I think that the reason why Java replaced Pascal as the standard language taught in college, was because of its much-touted security features --- buggy or malicious programs can't wreak havoc outside of the sandbox. > > I don't think Java was competing with Pascal for airtime in > introductory courses. > > Java was competing with C. > > For a while C was the standard language being taught in Computer > Science 101. > > But C has those pesky pointers. ... I think that academia really wants a "clean" language, that doesn't have pointers or any other real-world complications --- so programming can be taught as an abstract pseudo-mathematical "science." Pascal was originally like this, which is why it was embraced by academia. Over time however, the students complained too much that learning Pascal was a waste of time, and industry complained too much that the college graduates were unprepared for real-world programming. Because of this, C was taught in college for a while, to appease the complainers. This was only a temporary solution however, because the professors hated C and wanted a clean language. It was at this time that Java was introduced. Java was a big step up from Pascal because it can be used in the real-world, while yet being a clean (and sandboxed) language that the college professors could embrace. This doesn't at all imply that Java is a good language for real-world programming --- it is a compromise between the real-world and academia. I don't have a college degree though, so I don't give a rat's elbow what academia wants!
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-04-07 12:53 +0000 |
| Message-ID | <53429fdf$0$24922$e4fe514c@dreader36.news.xs4all.nl> |
| In reply to | #29309 |
In article <228fb0b6-f8af-4fd5-800d-b84a91d8aaa7@googlegroups.com>, <hughaguilar96@yahoo.com> wrote: > >In the old days, Pascal was the standard language taught in college. A >problem with Pascal however, is that each programmer on a multi-user >computer doesn't get his own "sandbox." This is a big problem because >the students tend to write buggy programs that can bring the whole >system down. Also, the smarter ones tend to write programs that snoop >into other users' space --- definitely a problem if the teacher has his >stuff (like the homework answers, or the upcoming exam) on the same >computer that the students are using. I was there in the old days. The idea that the one supercomputer the university owned could be brought down by a faulty Pascal program is ludicrous in the extreme. FORTRAN programs might end in a crash, (*not* bringing the system down!) and I got a dump (at the time fully incomprehensible to me) with register values in hexadecimal. Pascal, algol xx and Simula programs all ended with messages in a style like we see now in Python: array index out of bounds at line 137 in procedure aaax, called from line 13 in procedure bbbbx ... called from line 3 in procedure main. Groetjes Albert -- 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 | mhx@iae.nl |
|---|---|
| Date | 2014-04-06 00:09 -0700 |
| Message-ID | <917ac327-53fc-4a88-9966-89677c338f12@googlegroups.com> |
| In reply to | #29305 |
Paul Rubin <no.email@nospam.invalid> writes Re: Epic Fail [..] > People want two things from a language: > 1) Given a blank screen and a problem to solve, they want to be able to > bang out a solution quickly. > 2) Given a large existing program and a bug report (that might be an > enhancement request), they again want to be able to bang out a solution > quickly, WITHOUT requiring having the existing codebase in their head > before they start. > Most Forth success stories I've heard are about desire #1. Those kinds > of successes are of course perfectly great. It seems to me that Forth > was designed for #1 but has various aspects (lack of a type system, > roll-your-own everything) that aren't so great for #2. Can you elaborate on #2, *why* you think Forth is not great there (but Java is)? I am currently looking into the SPICE 3f5 codebase, and I certainly wish it would have been written in Forth (by competent programmers). In its present state it is nearly unmaintainable and cannot be improved (without extreme effort). What seems to happen is that contributors "patch on" small enhancements, and, for fear that something else will break, write all their own routines by copy-and-paste with tiny undocumented modifications. Reading this type of code *really* shows one why factoring is such a great concept. -marcel
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-04-06 13:12 +0000 |
| Message-ID | <534152b7$0$25039$e4fe514c@dreader37.news.xs4all.nl> |
| In reply to | #29317 |
In article <917ac327-53fc-4a88-9966-89677c338f12@googlegroups.com>, <mhx@iae.nl> wrote: >Paul Rubin <no.email@nospam.invalid> writes Re: Epic Fail >[..] >> People want two things from a language: > >> 1) Given a blank screen and a problem to solve, they want to be able to >> bang out a solution quickly. > >> 2) Given a large existing program and a bug report (that might be an >> enhancement request), they again want to be able to bang out a solution >> quickly, WITHOUT requiring having the existing codebase in their head >> before they start. > >> Most Forth success stories I've heard are about desire #1. Those kinds >> of successes are of course perfectly great. It seems to me that Forth >> was designed for #1 but has various aspects (lack of a type system, >> roll-your-own everything) that aren't so great for #2. I must thank you, Paul, for yet another insightful comment. > >Can you elaborate on #2, *why* you think Forth is not great there >(but Java is)? > >I am currently looking into the SPICE 3f5 codebase, and I certainly >wish it would have been written in Forth (by competent programmers). >In its present state it is nearly unmaintainable and cannot be improved >(without extreme effort). What seems to happen is that contributors >"patch on" small enhancements, and, for fear that something else will >break, write all their own routines by copy-and-paste with tiny >undocumented modifications. >Reading this type of code *really* shows one why factoring is such >a great concept. I can elaborate on 2. Surely you will admit that manx was written by a competent programmer. I'm one of those that are in the camp of joel http://www.joelonsoftware.com/articles/fog0000000069.html Things you never should do: "rewrite a working software package from scratch". Still I gave up on manx. I couldn't transform it in a program that had proper instrument drivers, and would handle multiple instruments on the same parallel port. This was after at least a month effort. Then I started a rewrite. After about a week I had a program that wasn't perfect but had the proper isolation of timings and instruments and that I could understand better. I've done a lot of perfective maintenance in my time. In those non-Forth project I've never been in a situation that I wasn't able to totally transform a lousy program to a maintainable state. Or for that matter, address a problem and solve it without jeopardizing the architecture. Another example is the colorforth development system of GA144. Leon and I had the parallel prime counting program (parpi) running on the old development kit Seaforth. We had to make some small modifications to the tools, regards routing i.a. With the new version of the development system, we had such a hard time retrofitting our modifications, that we all but have given up on it. Even after we forced the development system into source control (which was no small feat), we didn't manage. It blends with the remarks about Chuck's Moore style. Experiment until you have the design in your head. Then write the whole program anew and in one go. This relates to those who saw him work: "He didn't (need) spend time on debugging". The interesting thing is of course that now I'm of the opinion that it is pretty easy to do type 2 things to the manx2 program. For example I've added an organ instrument that requires a permanent relay current. Shortly I will modify that to use an initial long pulse and then PWM modulated hold current, without having to disturb the architecture of manx2. (This will save us a couple of dozen 2500 uF condensers.) > >-marcel Groetjes Albert -- 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 | mhx@iae.nl |
|---|---|
| Date | 2014-04-06 07:55 -0700 |
| Message-ID | <4342ab89-37af-422b-a119-af4fe9c6136b@googlegroups.com> |
| In reply to | #29320 |
albert@spenarnc.xs4all.nl (Albert van der Horst) writes Re: Epic Fail [..] >>Can you elaborate on #2, *why* you think Forth is not great there >>(but Java is)? [..] > I can elaborate on 2. Surely you will admit that manx was written by a > competent programmer. I'm one of those that are in the camp of joel > http://www.joelonsoftware.com/articles/fog0000000069.html > Things you never should do: > "rewrite a working software package from scratch". A single programmer can't rewrite SPICE. Life is too short. It would be possible to forge SPICE into something useful to do just what I need. But I already have/did that, and need SPICE to cater for those other people in the world that want to do what I can do, but on top of regular SPICE. > Still I gave up on manx. I couldn't transform it in a program that > had proper instrument drivers, and would handle multiple instruments > on the same parallel port. This was after at least a month effort. Funny you should say that. I wrote manx to hide as much of the internal details as possible (because it was in vogue to think like that, and I wanted to see if it would work). My conclusion was that I would *never* structure my programs like that anymore, and that they should always be introspective. [..] > The interesting thing is of course that now I'm of the opinion > that it is pretty easy to do type 2 things to the manx2 program. Yes, because you rewrote it yourself from scratch. I probably wouldn't be able to understand a word of the code as it is now :-) But that is surely not true in general, and I am interested in the opinion Paul has formed on this (and especially: how). -marcel
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-04-07 10:18 +0000 |
| Message-ID | <53427b64$0$24914$e4fe514c@dreader36.news.xs4all.nl> |
| In reply to | #29323 |
In article <4342ab89-37af-422b-a119-af4fe9c6136b@googlegroups.com>, <mhx@iae.nl> wrote: >albert@spenarnc.xs4all.nl (Albert van der Horst) writes Re: Epic Fail >[..] >>>Can you elaborate on #2, *why* you think Forth is not great there >>>(but Java is)? >[..] >> I can elaborate on 2. Surely you will admit that manx was written by a >> competent programmer. I'm one of those that are in the camp of joel >> http://www.joelonsoftware.com/articles/fog0000000069.html >> Things you never should do: >> "rewrite a working software package from scratch". > >A single programmer can't rewrite SPICE. Life is too short. >It would be possible to forge SPICE into something useful to do >just what I need. But I already have/did that, and need SPICE to cater >for those other people in the world that want to do what I can >do, but on top of regular SPICE. > >> Still I gave up on manx. I couldn't transform it in a program that >> had proper instrument drivers, and would handle multiple instruments >> on the same parallel port. This was after at least a month effort. > >Funny you should say that. I wrote manx to hide as much of the internal >details as possible (because it was in vogue to think like that, and I >wanted to see if it would work). My conclusion was that I would *never* >structure my programs like that anymore, and that they should always be >introspective. You consider it a failed experiment then. That make is all the more interesting to see what you think of manx as it is now. It leans on midi, as there are two parts, generating midi and executing midi, and the only connection is midi. (I could make two Forth programs working through a pipe, and then replace one program with the midi sound system of Linux.) So data hiding is an important design goal. midi is an excellent abstraction, and of course it is invented by people who where experts in the field of music. > >[..] > >> The interesting thing is of course that now I'm of the opinion >> that it is pretty easy to do type 2 things to the manx2 program. > >Yes, because you rewrote it yourself from scratch. I probably wouldn't >be able to understand a word of the code as it is now :-) You (and everybody) can get a crack at that. The source are available at manx.html at the site below. > >But that is surely not true in general, and I am interested in the >opinion Paul has formed on this (and especially: how). > >-marcel -- 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 | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-04-06 08:21 -0700 |
| Message-ID | <7x38hqmqjz.fsf@ruckus.brouhaha.com> |
| In reply to | #29317 |
mhx@iae.nl writes: > Can you elaborate on #2, *why* you think Forth is not great there > (but Java is)? I don't know that Java is so great at #2 either, but it made serious efforts that were considered credible in the 1990's, though in retrospect were not 100% successful. The most obvious things: 1) memory safety makes testing more effective and debugging much simpler 2) static type system immediately catches lots of errors caused by incomplete understanding of how the program is organized. It also aids refactoring by letting compiler globally find errors introduced by locally changing something's type signature. 3) data encapsulation and interfaces further refine the above 4) garbage collection localizes most concerns about object lifetimes. You don't have to worry about what distant parts of the program do with an object after you have made it. 5) library ecosystem puts several layers of the program into common knowledge (shared across programs and part of the programmer's skillset). Forth programs do everything from scratch, differently in every program > I am currently looking into the SPICE 3f5 codebase, That is written in C, which has most of the same problems as Forth.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-04-06 08:30 -0700 |
| Message-ID | <d5c7fb0c-5e3b-4ca9-adc9-a53f79724195@googlegroups.com> |
| In reply to | #29325 |
On Sunday, April 6, 2014 8:21:52 AM UTC-7, Paul Rubin wrote: > 5) library ecosystem puts several layers of the program into common > knowledge (shared across programs and part of the programmer's > skillset). Forth programs do everything from scratch, differently > in every program This is not a failure of Forth (the language), this is a failure of ANS-Forth (which is really just SwiftForth). I really see no reason why Forth can't have quotations (I mean real quotations that have access to the creator function's local variables, not Payson-faked quotations that are just :NONAME with some syntactic sugar). If Forth had quotations, then it would be possible to have libraries of "containers" and the programmer could apply a quotation to every node (or some subset of the nodes) in the container. It is grossly wrong to say: "Forth programs do everything from scratch, differently in every program" --- this is Elizabeth Rather's philosophy --- nobody with any common sense should ever say such a thing!
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-04-06 22:12 +0200 |
| Message-ID | <lhscft$url$1@online.de> |
| In reply to | #29325 |
Paul Rubin wrote: > 5) library ecosystem puts several layers of the program into common > knowledge (shared across programs and part of the programmer's > skillset). Forth programs do everything from scratch, differently > in every program That's vastly overstating it. Forth programmers usually have a toolbox they carry around with them, but different Forth programmers have different toolboxes, because they can't agree on the tools. The problem with reusable components has been illustrated by Fred Books, with his "9 times the effort" conclusion. Most programs end up at the "works for me" quality level, which is much easier to achieve. However, that's true for Java software, as well. Example: When I started Gforth on Android, I used the NativeActivity. This is a Java class (plus C++ code), which loads a library and allows you to write native code. The quality of the NativeActivity is clearly in the "works for me" region, as there are many bugs (like e.g. the keyboard is limited to ASCII), and despite it is constantly changing from one Android version to the next, the number of bugs is not even going down (sometimes even going up). Resulting decision: Throw it away and do it myself. Took a few days, and the result fixed all the bugs the NativeActivity had, *and* was much less source-code. And it works from Android 2.3 to 4.4 without a single version- dependent change. The result is also way more maintainable - for me. So why didn't Google do it my way? One possibility is that they are stupid (and the fact that they don't get NativeActivity bug-free supports that assertion). However: my solution is a "works for me" solution. Certainly, my constraints are quite different, e.g. "works for me" means I can input non-ASCII characters; let them be German or Chinese. However, the original idea of NativeActivity is that you don't need any Java. My approach requires that you use JNI to call Java even for simple things like to extract the characters from a keyboard message (yes, that fixes the bug). Fortunately, in Forth, it is possible to create a JNI interface that integrates well - in C, this is way more difficult to achieve (that's due to Forth's extensibility). However, when you think about maintainability: The biggest Forth program, CCS, is a million lines of code. It is developed by a team, not by a single person. It has been growing for over a decade or two. I.e. it's in constant maintenance. It has its own OOP system, and I don't know what else it has; for sure, it has all the infrastructure it needs (which is a lot). There's a rule for most parts of its code-base and that is "no guru code allowed". That means I wouldn't like what I see when I would look at it. It is highly competitive; you would think that this kind of business planning/financial application would best be done in Java, because most people do this kind of stuff in Java - and not in Forth, which is usually used for embedded stuff. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-04-06 12:08 -1000 |
| Message-ID | <7tOdnYTX6eabSdzOnZ2dnUVZ_hudnZ2d@supernews.com> |
| In reply to | #29331 |
On 4/6/2014 10:12 AM, Bernd Paysan wrote: > Paul Rubin wrote: >> 5) library ecosystem puts several layers of the program into common >> knowledge (shared across programs and part of the programmer's >> skillset). Forth programs do everything from scratch, differently >> in every program > > That's vastly overstating it. Forth programmers usually have a toolbox they > carry around with them, but different Forth programmers have different > toolboxes, because they can't agree on the tools. I think the problem isn't so much a lack of agreement as differing needs. Programmers build toolboxes in response to needs they encounter in the applications they work on. Teams working on an application generally agree on a team toolbox. It's part of seeing Forth as an "application-oriented language". > The problem with reusable components has been illustrated by Fred Books, > with his "9 times the effort" conclusion. Most programs end up at the "works > for me" quality level, which is much easier to achieve. However, that's > true for Java software, as well. It's also often true that once a facility has been generalized enough to be used in a lot of situations it's bloated and less appropriate for each one. ... > > However, when you think about maintainability: The biggest Forth program, > CCS, is a million lines of code. It is developed by a team, not by a single > person. It has been growing for over a decade or two. I.e. it's in > constant maintenance. It has its own OOP system, and I don't know what else > it has; for sure, it has all the infrastructure it needs (which is a lot). > There's a rule for most parts of its code-base and that is "no guru code > allowed". That means I wouldn't like what I see when I would look at it. > It is highly competitive; you would think that this kind of business > planning/financial application would best be done in Java, because most > people do this kind of stuff in Java - and not in Forth, which is usually > used for embedded stuff. We have numerous customers who have maintained Forth applications over many years, many generations of the products or systems they control, and even generations of programmers doing the maintaining. The oldest I am aware of has been operating since the late 70's. It is quite possible to write maintainable Forth code, at least as possible as with any other language I know. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-04-06 16:44 -0700 |
| Message-ID | <7x8urixbtj.fsf@ruckus.brouhaha.com> |
| In reply to | #29331 |
Bernd Paysan <bernd.paysan@gmx.de> writes: > That's vastly overstating it. Forth programmers usually have a > toolbox they carry around with them, but different Forth programmers > have different toolboxes, because they can't agree on the tools. Even very simple things have to be done at a low level in Forth. Like if I want to print an array in Python, Lisp, Haskell, Ruby, or even C++ (I don't know about Java), I just print it in one operation. I don't have to write a loop to print it element by element. > Example: When I started Gforth on Android, I used the NativeActivity. Yeah, I've so far avoided having anything to do with Android, maybe because of issues like this. > However, when you think about maintainability: The biggest Forth > program, CCS, is a million lines of code.... It is highly competitive; > you would think that this kind of business planning/financial > application would best be done in Java I've heard of that program and I have always wondered what level of effort it takes to maintain it, compared with something similar written in Java or whatever. I'm certainly no fan of Java. Around here there was a company whose main business was processing mobile phone billing records, another Java-ish area, but their code was written in OCaml. Their recruiting ads asked for Python programmers because they figured directly mentioning OCaml might scare people too much, but someone good at Python could pick up OCaml. Then word got out that they were actually using OCaml, and suddenly they were flooded with nerds wanting to work there. So I wonder whether OCaml might also be a good choice for CCS-like applications.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-04-06 22:03 -0700 |
| Message-ID | <62b7de26-fa85-4e49-8e99-3a2deb9293f1@googlegroups.com> |
| In reply to | #29346 |
On Sunday, April 6, 2014 4:44:40 PM UTC-7, Paul Rubin wrote: > Even very simple things have to be done at a low level in Forth. Like > if I want to print an array in Python, Lisp, Haskell, Ruby, or even C++ > (I don't know about Java), I just print it in one operation. I don't > have to write a loop to print it element by element. If you have quotations, then this is trivial. You just write a quotation that prints a node according to whatever data is in the node, and you give the quotation to EACH. Actually, this is an example of a quotation that doesn't need any communication with the creator function, so Payson-faked quotations will work, or my "touchers" in the novice package --- I have examples of printing everything in a data structure in both LIST.4TH and ASSOCIATION.4TH. You know, Paul, you really should learn more about Forth before you make these pronouncements about Forth. Earlier you stated that all Forth programs have to be written from scratch. Now you state that to print every element in a data-structure you "have to write a loop to print it element by element." You are just accepting Elizabeth Rather's style of Forth programming as an inherent limitation of the Forth language. This is really Elizabeth Rather's worst crime --- that she teaches novices such as yourself that Forth is limited, and then you go out and tell the whole world that Forth is limited --- you will never get beyond the "Starting Forth" level of Forth so long as you continue to listen to Elizabeth Rather!
[toc] | [prev] | [next] | [standalone]
| From | Stefan Mauerhofer <smauerhofer@androsoft.ch> |
|---|---|
| Date | 2014-04-07 01:29 -0700 |
| Message-ID | <85e15f4e-96de-4467-8e02-969cc4023399@googlegroups.com> |
| In reply to | #29356 |
>
>
>
> If you have quotations, then this is trivial. You just write a quotation that prints a node according to whatever data is in the node, and you give the quotation to EACH. Actually, this is an example of a quotation that doesn't need any communication with the creator function, so Payson-faked quotations will work, or my "touchers" in the novice package --- I have examples of printing everything in a data structure in both LIST.4TH and ASSOCIATION.4TH.
>
>
Your discussion with Bernd interested me, so I've implemented locals in my Forth and made a simple test.
The Forth code looks like:
: test { a b c }
a . cr b . cr c . cr
4
[: { d }
d . cr
a . cr b . cr c . cr
." Hello World"
;]
execute
;
1 2 3 test
which gives the following output:
1
2
3
4
1
2
3
Hello World
The block has access to the outer word locals.
The curled bracket define locals, which are stored in a separate local stack. So a simple solution to the locals-problem might be to add a third stack. Chuck's genius divided the normal stack into 2 separate stacks. This decoupled control flow from data processing. Adding a third local stack decouples the parameter processing from local variables. The solution is simple and straightforward. Construct like "each" now can easily be implemented, although this is not a powerful as closures.
(BTW: The curled bracket definition assumes the last word to be the top of stack. This is similar to Forth's standard stack comments).
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-04-07 16:57 +0000 |
| Subject | locals in nested definitions (was: Epic Fail) |
| Message-ID | <2014Apr7.185716@mips.complang.tuwien.ac.at> |
| In reply to | #29361 |
Stefan Mauerhofer <smauerhofer@androsoft.ch> writes:
>Your discussion with Bernd interested me, so I've implemented locals in my =
>Forth and made a simple test.
>
>The Forth code looks like:
>
>: test { a b c }
> a . cr b . cr c . cr
> 4
> [: { d }
> d . cr=20
> a . cr b . cr c . cr
> ." Hello World"
> ;]
> execute
>;
>1 2 3 test
>
> which gives the following output:
>
>1
>2
>3
>4
>1
>2
>3
>Hello World
>
>The block has access to the outer word locals.
>
>The curled bracket define locals, which are stored in a separate local stac=
>k. So a simple solution to the locals-problem might be to add a third stack=
>. Chuck's genius divided the normal stack into 2 separate stacks. This deco=
>upled control flow from data processing. Adding a third local stack decoupl=
>es the parameter processing from local variables. The solution is simple an=
>d straightforward. Construct like "each" now can easily be implemented, alt=
>hough this is not a powerful as closures.
Well, EXECUTEing the quotation right away is an easy case. But it
gets harder if you pass the xt to another word that has its own
locals; and consider what happens if it is recursive. This can all be
solved with well-known techniques (static link chains or displays);
did you do this?
And as long as the xt never leaves the definitions whose locals it
references, you can memory-manage them on a stack. But then the
benefit of outer locals is also quite small.
- 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 | mhx@iae.nl |
|---|---|
| Date | 2014-04-07 11:48 -0700 |
| Message-ID | <6e7d7199-86f0-4fb2-af2c-4958ecfec32a@googlegroups.com> |
| In reply to | #29361 |
On Monday, April 7, 2014 10:29:22 AM UTC+2, Stefan Mauerhofer wrote:
> The curled bracket define locals, which are stored in a separate
> local stack. So a simple solution to the locals-problem might be
> to add a third stack. Chuck's genius divided the normal stack into
> 2 separate stacks. This decoupled control flow from data processing.
> Adding a third local stack decouples the parameter processing from
> local variables. The solution is simple and straightforward.
> Construct like "each" now can easily be implemented, although this
> is not a powerful as closures.
You know this of course, but the controversy is over what happens
when you export the xt of the local word:
:noname LOCALS| c b a | ( -- xt )
a . b . c .
4
[: LOCAL d
d . a . b . c .
." Hello World"
;] ; constant test2-xt
1 2 3 test2-xt execute execute
You will get 1 2 3 4 0 0 0 Hello World \ most probably
If you get 1 2 3 instead of 0 0 0 (repeatedly), I want
to know how you did it :-)
-marcel
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-04-07 22:54 +0200 |
| Message-ID | <lhv3a2$b0f$2@online.de> |
| In reply to | #29361 |
Stefan Mauerhofer wrote:
>>
>>
>>
>> If you have quotations, then this is trivial. You just write a quotation
>> that prints a node according to whatever data is in the node, and you
>> give the quotation to EACH. Actually, this is an example of a quotation
>> that doesn't need any communication with the creator function, so
>> Payson-faked quotations will work, or my "touchers" in the novice package
>> --- I have examples of printing everything in a data structure in both
>> LIST.4TH and ASSOCIATION.4TH.
>>
>>
>
> Your discussion with Bernd interested me, so I've implemented locals in my
> Forth and made a simple test.
>
> The Forth code looks like:
>
> : test { a b c }
> a . cr b . cr c . cr
> 4
> [: { d }
> d . cr
> a . cr b . cr c . cr
> ." Hello World"
> ;]
> execute
> ;
> 1 2 3 test
>
> which gives the following output:
>
> 1
> 2
> 3
> 4
> 1
> 2
> 3
> Hello World
>
> The block has access to the outer word locals.
Yes, but only as long as you don't have anything in between. E.g. if you
replace EXECUTE with
: test-exec { xt } xt execute ;
it will fail.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-04-08 00:04 -0700 |
| Message-ID | <f4b36b90-ca8f-48d9-a276-115ed160b27b@googlegroups.com> |
| In reply to | #29361 |
On Monday, April 7, 2014 1:29:22 AM UTC-7, Stefan Mauerhofer wrote:
> > If you have quotations, then this is trivial. You just write a quotation that prints a node according to whatever data is in the node, and you give the quotation to EACH. Actually, this is an example of a quotation that doesn't need any communication with the creator function, so Payson-faked quotations will work, or my "touchers" in the novice package --- I have examples of printing everything in a data structure in both LIST.4TH and ASSOCIATION.4TH.
> Your discussion with Bernd interested me, so I've implemented locals in my Forth and made a simple test.
>
> The Forth code looks like:
>
> : test { a b c }
> a . cr b . cr c . cr
> 4
> [: { d }
> d . cr
> a . cr b . cr c . cr
> ." Hello World"
> ;]
> execute
> ;
>
> 1 2 3 test
>
> which gives the following output:
>
> 1
> 2
> 3
> 4
> 1
> 2
> 3
>
> Hello World
>
> The block has access to the outer word locals.
>
> The curled bracket define locals, which are stored in a separate local stack. So a simple solution to the locals-problem might be to add a third stack. Chuck's genius divided the normal stack into 2 separate stacks. This decoupled control flow from data processing. Adding a third local stack decouples the parameter processing from local variables. The solution is simple and straightforward. Construct like "each" now can easily be implemented, although this is not a powerful as closures.
>
> (BTW: The curled bracket definition assumes the last word to be the top of stack. This is similar to Forth's standard stack comments).
This is intriguing! I'm pleased to see that somebody is making an effort along these lines.
You need a chain of display-pointers at run-time . I don't understand how your "third stack" provides this. Can you elaborate?
Is your Forth publicly available? Can I examine what you have?
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-04-07 14:12 +0200 |
| Message-ID | <lhu4ne$hod$1@online.de> |
| In reply to | #29346 |
Paul Rubin wrote: > Bernd Paysan <bernd.paysan@gmx.de> writes: >> That's vastly overstating it. Forth programmers usually have a >> toolbox they carry around with them, but different Forth programmers >> have different toolboxes, because they can't agree on the tools. > > Even very simple things have to be done at a low level in Forth. Like > if I want to print an array in Python, Lisp, Haskell, Ruby, or even C++ > (I don't know about Java), I just print it in one operation. I don't > have to write a loop to print it element by element. Print a string array in Gforth with Gforth's string library (in the current git head): $[]. ( addr -- ) One operation. Of course there is a loop somewhere inside $[]., what would you think how Python does it? Magic? The way to program Forth is to build the abstractions you need yourself. Different people have different needs (which is why Forthers usually don't agree on a single library), but there *are* libraries out there, e.g. the Forth Foundation Library. You want to print a cell array (car.fs) in FFL? car-dump ( car -- ) One operation. Of course there is a loop somewhere inside it. Actually, both libraries use the same approach: There's a higher order function walking the entire array. >> Example: When I started Gforth on Android, I used the NativeActivity. > > Yeah, I've so far avoided having anything to do with Android, maybe > because of issues like this. I think this is a general problem with the use run-of-the-mill employees and tools: Too much incompetence. >> However, when you think about maintainability: The biggest Forth >> program, CCS, is a million lines of code.... It is highly competitive; >> you would think that this kind of business planning/financial >> application would best be done in Java > > I've heard of that program and I have always wondered what level of > effort it takes to maintain it, compared with something similar written > in Java or whatever. They are very competitive and have no problem to stay in business. It's not a big company. If i would be way more difficult than what the competition does, they would certainly be out of business by now. > I'm certainly no fan of Java. Around here there was a company whose > main business was processing mobile phone billing records, another > Java-ish area, but their code was written in OCaml. Their recruiting > ads asked for Python programmers because they figured directly > mentioning OCaml might scare people too much, but someone good at Python > could pick up OCaml. Then word got out that they were actually using > OCaml, and suddenly they were flooded with nerds wanting to work there. > So I wonder whether OCaml might also be a good choice for CCS-like > applications. Maybe. The main problem is that programmers have a large difference in performance, even using the same tools (Brooks reports a factor 20). But good programmers usually know more than just one programming language, and by doing so, they have found the programming language that fits their way of thinking, and then they are even more productive than with average tools. If you want good work, you need self-selected, dedicated people who drive it forward. You get much further with that approach than with the run-of-the- mill approach. Quite often, run-of-the-mill managers are scared by people who do their stuff in Forth, and then try to replace their work with run-of-the-mill people and tools. The typical outcome is a complete failure - many software projects are failures, anyways, and using average people with average tools is a recipie for disaster, especially when they are competing with good people and tools that are right for the job. -- 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 21:23 -0700 |
| Message-ID | <7xwqf04ffx.fsf@ruckus.brouhaha.com> |
| In reply to | #29373 |
Bernd Paysan <bernd.paysan@gmx.de> writes: > Print a string array in Gforth with Gforth's string library (in the current > git head): > $[]. ( addr -- ) Good to know, though I'm still on 0.7.0. > One operation. Of course there is a loop somewhere inside $[]., what would > you think how Python does it? Magic? Of course there's a loop, but the items inside the array also know how to represent themselves as strings so they can be printed. Doing the same thing with a Forth OOP system is perfectly doable but again, it's a roll-your-own operation. > The way to program Forth is to build the abstractions you need yourself. > Different people have different needs Yes, that's the whole point, other languages have taken the experience of past decades on board, that certain abstractions like arrays and dictionaries are useful enough that it's worth supplying them pre-built. Then they become part of the language background rather than the program, eliminating some layers of abstraction from the program. >>> The biggest Forth program, CCS, is a million lines of code.... > They are very competitive and have no problem to stay in business. > It's not a big company. If i would be way more difficult than what > the competition does, they would certainly be out of business by now. I don't know what competition in that industry involves. Those types of programs tend to not evolve very fast: I've done some work with payment and POS terminals recently and it was like stepping back to the 1980's. Competition may be mostly about landing deals and supporting customers rather than advancing technology. The restaurant business is also highly competitive, and one area of competition is developing new recipes and dishes, but not THAT much of their effort goes into that area. It's more about doing a good job with the existing recipes and keeping the venue attractive and the service level high. Maybe it's similar with the CCS company and its software base. > Quite often, run-of-the-mill managers are scared by people who do > their stuff in Forth, and then try to replace their work with > run-of-the-mill people and tools. The typical outcome is a complete > failure - many software projects are failures, anyways I wonder if the failure rate for Forth projects is any different. There's an old Yosefk post that may explain some of what goes on with Forth: http://www.yosefk.com/blog/low-level-is-easy.html It says (among other things) low level approaches can be more tedious, but have fewer dependencies and are more robust against going wrong because somebody else's stuff broke, and tends to be more solid because everyone else's stuff will break if the low level stuff fails.
[toc] | [prev] | [next] | [standalone]
Page 17 of 22 — ← Prev page 1 … 15 16 [17] 18 19 … 22 Next page →
Back to top | Article view | comp.lang.forth
csiph-web