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 13 of 22 — ← Prev page 1 … 11 12 [13] 14 15 … 22 Next page →
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2014-04-11 18:59 +0100 |
| Message-ID | <li9aho$vrd$1@dont-email.me> |
| In reply to | #29527 |
on 11/04/2014 18:16:07, wrote: > "Alex McDonald" <blog@rivadpm.com> writes: >>on 11/04/2014 00:03:01, "Rod Pemberton" wrote: >>> Memory is contiguous, bytes are 8-bits, all pointers have a single >>> size, integers and pointers are an integer multiple of the size of a >>> byte, two's complement arithmetic, etc. Of course, C was implemented >>> on a variety of hardware that didn't conform to that model, e.g., >> >>C started life on a system that didn't conform to your ideal model for C. > > C started life on the PDP-11, and it has all the properties given > above. > > - anton My bad, I spat out a reply in haste. The rest of my complaint stands, including the spurious claim that the list below "creates all the "undefined" behavior for C" Crays (supercomputer vector machines which were never programmed in C). DECs (included "Pemberton model" PDP-11, VAXen etc for which there were C compilers). Burroughs (large systems ran Algol-based languages that predated C, and there were no C compilers -- or assemblers). In other words, "undefined" C behavior has nothing to do with these platforms. Where there is a C compiler, they are "Pemberton model".
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2014-04-11 19:11 +0100 |
| Message-ID | <li9b8h$613$1@dont-email.me> |
| In reply to | #29531 |
on 11/04/2014 18:59:19, "Alex McDonald" wrote: > on 11/04/2014 18:16:07, wrote: >> "Alex McDonald" <blog@rivadpm.com> writes: >>>on 11/04/2014 00:03:01, "Rod Pemberton" wrote: >>>> Memory is contiguous, bytes are 8-bits, all pointers have a single >>>> size, integers and pointers are an integer multiple of the size of a >>>> byte, two's complement arithmetic, etc. Of course, C was implemented >>>> on a variety of hardware that didn't conform to that model, e.g., >>> >>>C started life on a system that didn't conform to your ideal model for C. >> >> C started life on the PDP-11, and it has all the properties given >> above. >> >> - anton > > My bad, I spat out a reply in haste. > > The rest of my complaint stands, including the spurious claim that the > list below "creates all the "undefined" behavior for C" > > Crays (supercomputer vector machines which were never programmed in > C). > > DECs (included "Pemberton model" PDP-11, VAXen etc for which there > were C compilers). > > Burroughs (large systems ran Algol-based languages that predated C, > and there were no C compilers -- or assemblers). > > In other words, "undefined" C behavior has nothing to do with these > platforms. Where there is a C compiler, they are "Pemberton model". > For some reason, the IBM mainframe entry got chopped. It is a "Pemberton model" and might be considered the poster child for how we got to where we are today; 8 bit byte, 32 bit (4 byte) address, contiguous memory, two's complement arithmetic and so on. These machines had early C compilers too.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-04-11 12:05 -0700 |
| Message-ID | <7xob07g00j.fsf@ruckus.brouhaha.com> |
| In reply to | #29531 |
"Alex McDonald" <blog@rivadpm.com> writes: > Crays (supercomputer vector machines which were never programmed in C). https://en.wikipedia.org/wiki/UNICOS
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-04-11 22:03 -0400 |
| Message-ID | <op.xd6lbvvy6zenlw@localhost> |
| In reply to | #29531 |
On Fri, 11 Apr 2014 13:59:19 -0400, Alex McDonald <blog@rivadpm.com> wrote:
> The rest of my complaint stands, including the spurious claim that the
> list below "creates all the "undefined" behavior for C"
No, it doesn't.
> Crays (supercomputer vector machines which were never programmed in C).
>
> DECs (included "Pemberton model" PDP-11, VAXen etc for which there were C
> compilers).
>
> Burroughs (large systems ran Algol-based languages that predated C, and
> there were no C compilers -- or assemblers).
>
> In other words, "undefined" C behavior has nothing to do with these
> platforms. Where there is a C compiler, they are "Pemberton model".
>
> [inserted]
> For some reason, the IBM mainframe entry got chopped. It is a "Pemberton
> model" and might be considered the poster child for how we got to where
> we are today; 8 bit byte, 32 bit (4 byte) address, contiguous memory,
> two's complement arithmetic and so on. These machines had early C
> compilers too.
You clearly don't know what you're talking about.
You previously stated things like ... There was no such language as PL/1.
Yet, that's exactly what Stratus names their early standard PL/I language
to differentiate it from IBM's PL/I.
There are two aspects of this:
1) the machines where C was implemented, and
2) the machine architecture.
This is going to get really long.
Part 1)
Let's start with the early machines where C was ported:
PDP-11 (DMR,J&R)
Honeywell 635 (DMR)
IBM 360/370 (DMR,J&R)
Interdata 8/32 (DMR,J&R)
DEC VAX 11/780 (DMR,J&R)
Honeywell 6000 (J&R)
SEL86 (J&R)
Data General Nova (J&R)
Eclipse (J&R)
Cray X-MP/24 (DM2)
AT&T 3B20S minicomputer (BHKRS)
AT&T 3B5 minicomputer (BHKRS)
UNIVAC 1100 series (BHKRS)
DMR - "The Development of the C Language", Dennis M. Ritchie
J&R - "Portability of C Programs and the UNIX System, S.C. Johnson & D.M.
Ritchie
DM2 - "Experience with Unicos on the Cray X-MP", Dennis Ritchie
BHKRS - "UNIX Operating System Porting Experiences", D.E. Bodenstab, T.F.
Houghton, K.A. Kelleman, G. Ronkin, E.P. Schan
As you can see, there are the Crays, DECs, IBMs, which I mentioned.
What did you say about Cray never having been programmed in C?
E.g., DM2 says:
"Cray's C compiler, which is an instance of Johnson's PCC [1]."
As for the Burroughs, it used linked activation records to create
a stack, did have ALGOL implemented, but some have issues with
creating pointers. This would be a difficult machine to put C
onto. Supposedly, Steve Bartels implemented a C compiler for
Burroughs. I don't know what generation of machine that's for
or when that was done. He apparently worked on 6800/7800 series
machines at least at one point in time. Supposedly, his Burroughs
C compiler added an extra word to all malloc'd memory causing a
NULL deference if accessed via a pointer scan. The Burroughs
machines and their linked activation records are also rumored
to be the reason that C doesn't explictly require a stack for
procedures. I don't have anything that is "authoritative."
Part 2)
Let's cover the machine architecture issues of C:
"The machines on which we first used BCPL and then B were
word-addressed, and these languages' single data type, the
`cell,' comfortably equated with the hardware machine word.
The advent of the PDP-11 exposed several inadequacies of B's
semantic model. First, its character-handling mechanisms,
inherited with few changes from BCPL, were clumsy: [...]"
-"The Development of the C Language", Dennis M. Ritchie
"A major problem will occur when the computer's natural word
size is not a multiple of its natural byte size."
-"C: A Reference Manual", Harbison and Steele, 3rd Ed., pg 153.
"Computers that were able to deal just with numbers evolved into
computers with byte-addressable memory, flat address spaces, and
pointers. This was a natural evolution reflecting the growing set
of problems that people were solving. C, reflecting the genius of
Dennis Ritchie, provided a minimal model of the computer that had
evolved over 30 years. C was not a quick hack. As computers evolved
to handle all kinds of problems, C, being the minimal model of such
a computer, became a very powerful language to solve all kinds of
problems in different domains very effectively. This is the secret
of C's portability: it is the best representation of an abstract
computer that we have. Of course, the abstraction is done over the
set of real computers, not some imaginary computational devices."
-"Al Stevens Interviews Alex Stepanov",
by Al Stevens, Dr. Dobb's Journal
- Alex Stepanov is the C++ STL creator
So, the C machine model will fail for a variety of reasons:
1) for a machine "word size not a multiple of byte size" (H&S)
2) for "integer of any kind" that is not "divisible evenly into bytes"
(J&R)
3) for a word size being an odd multiple of char size (J&R)
4) for a "word-addressed machine that lacks any natural
representation of a character pointer" (J&R)
5) when an object can't "be walked using a byte pointer derived from
any kind of pointer into the object." (DAG)
6) when an object isn't represented as required by the C model of
"[suitably] aligned byte arrays with additional properties
(such as value interpretation) impressed upon them by the
type system." (DAG)
7) when a char is less than 8-bits per byte (J&R)
8) when a short is less than 16-bits or a long is less than 32-bits (J&R)
The C model fails in part on numerous early machines:
1) Cray's (H&S) (early were 16-bit word aligned)
2) unnamed 36-bit word, 7-bit char (e.g., IBM-705, PDP-10) (H&S)
3) PDP-11 due to 16-bit word alignment (R)
4) PDP-10 36-bit word using 7-bit char instead of 9-bit char (J&R)
Sources:
H&S "C: A Reference Manual", Harbison and Steele, 3rd, 1991
J&R "Portability of C Programs and the UNIX System" Johnson, Ritchie,
1978
DAG various usenet posts by Douglas A. Gwyn
R "C Reference Manual" Dennis Ritchie, 1975
It appears that the PDP-7 would fail due to architecture too, since
it has a 16-bit word and 6-bit char. Also, C requires 8-bits or more
for a char. Albeit, that's an arbitrary constraint.
Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-04-11 20:18 +0200 |
| Message-ID | <li9bll$6ah$1@online.de> |
| In reply to | #29527 |
Anton Ertl wrote: > "Alex McDonald" <blog@rivadpm.com> writes: >>on 11/04/2014 00:03:01, "Rod Pemberton" wrote: >>> Memory is contiguous, bytes are 8-bits, all pointers have a single >>> size, integers and pointers are an integer multiple of the size of a >>> byte, two's complement arithmetic, etc. Of course, C was implemented >>> on a variety of hardware that didn't conform to that model, e.g., >> >>C started life on a system that didn't conform to your ideal model for C. > > C started life on the PDP-11, and it has all the properties given > above. There were also "IBMs" mentioned, but *the* architecture which made 8-bit- bytes and characters, power-of-two bytes integers, single, non-segmented address space, two's complement, and so on popular, was the IBM /360. The only two things that didn't last were EBCDIC, and big endian (today, little endian is way more often used). -- 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-11 21:44 -0400 |
| Message-ID | <op.xd6kgcct6zenlw@localhost> |
| In reply to | #29526 |
On Fri, 11 Apr 2014 12:45:26 -0400, Alex McDonald <blog@rivadpm.com> wrote: > on 11/04/2014 00:03:01, "Rod Pemberton" wrote: >> C works best on the microprocessor model of computing hardware. > > Proof please. > History. >> Memory is contiguous, bytes are 8-bits, all pointers have a single >> size, integers and pointers are an integer multiple of the size of a >> byte, two's complement arithmetic, etc. Of course, C was implemented >> on a variety of hardware that didn't conform to that model, e.g., > > C started life on a system that didn't conform to your ideal model for C. > True. It also failed to work on most other platforms until it was heavily reworked to fit them. You can read Johnson's, Kernighan's, and Ritchie's early papers yourself where they describe the problems they ran into. >> 16-bit bytes but 9-bit characters, differently sized pointers, no >> ability to access small integers as needed for characters, etc. These >> "other", mostly obsolete, mainframe/corporate platforms like Crays, >> DECs, Burroughs, IBMs, etc is what creates all the "undefined" >> behavior for C. > > As opposed to the undefined behaviour on 8bit byte, pointers single size, > 2s complement etc? > Is this a blatant failure to read? "These 'other', mostly obsolete, mainframe/corporate platforms like Crays, DECs, Burroughs, IBMs, etc is what creates all the 'undefined' behavior for C." and I said, "Of course, C was implemented on a variety of hardware that didn't conform to that model, [...]" Let me explain that since you didn't comprehend. If only the microprocessor model was used, there wouldn't be undefined behavior in C. I.e., the need for compatibility with multiple architectures are what created undefined behavior. I should additionally clarify that for you. I'm referring to microprocessors 1974 or later which standardized on such a model. It took a few years for such a model to become standard. And, I never said some of those characteristics weren't present in mainframes. They are. Most mainframes didn't have all of those features though, but a couple did. You can look at the Wikpedia computer word page to see them: http://en.wikipedia.org/wiki/Word_(computer_architecture) >> C is superb for microprocessors where the useful behaviors are usually >> implemented. > > The above is a "let's rewrite history" or (as we call it in my business) > rubbish. > The above is accurate. Your comments are ignorant. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | visualforth@rocketmail.com |
|---|---|
| Date | 2014-04-11 14:00 -0700 |
| Message-ID | <f2c167fa-14da-42a8-a715-d567a6200284@googlegroups.com> |
| In reply to | #29514 |
On Thursday, April 10, 2014 7:03:03 PM UTC-4, Rod Pemberton wrote: > > C was standardized for multiple > different computing platforms with different architectures. Only 30% > of C's code is truly portable, in the sense that the code performs exactly > the same way on all hardware. Another 30% or so appears to be portable, > because the same result can be implemented on most hardware, albeit > differently. > The rest is simply not portable. It has to be adjusted for different > platforms. > > While the C language is almost entirely independent of the host, the C > libraries > aren't. Minimal C libraries need about twenty host specific functions. Isn't Forth inherently much better? It should be possible to have a Forth for different microprocessor architectures which should allow to run the same programs, because a microprocessor Forth could have words like ADC@ or PWM! or the like to make programs compatible with different I/O. There may be a diversity of additional words like ADC8@, ADC10@, ADC12@ if this is needed. This is a great advantage of Forth. Of course each of these Forth compilations have to be made for each of these specific microprocessor, but it will be possible to run the same Forth user program on each of these specific microprocessors.
[toc] | [prev] | [next] | [standalone]
| From | Matthias Trute <matthias.trute@gmail.com> |
|---|---|
| Date | 2014-04-12 01:04 -0700 |
| Message-ID | <4e4e16ad-8e59-4f64-b1b7-09e554dff384@googlegroups.com> |
| In reply to | #29543 |
> Isn't Forth inherently much better? It could be, but it isn't IMHO. > It should be possible to have a Forth for different microprocessor > architectures which should allow to run the same programs, because a > microprocessor Forth could have words like ADC@ or PWM! or the like to make > programs compatible with different I/O. There may be a diversity of > additional words like ADC8@, ADC10@, ADC12@ if this is needed. This is a > great advantage of Forth. There is/was a forth 200x proposal at http://www.forth200x.org/memory-2010-06-26.txt which could be used: <size-information><@/!><address-segment> In amforth I use this pattern (to some degree): c@spi (gets a single byte via SPI) or n!spi (sends a memory block via SPI) Something like c@adc or w!pwm could simplify the use of forth code across different controllers (and different forth's). They all do this kind of stuff and all do it subtly different ways. Bonding the users to their system (or family of forth's from the same vendor). I'd go as far as e.g. b!1wire as well (send a single bit to a 1-wire bus). Lowlevel code for it exist for all controllers. That would allow a portable 1-wire lib in forth. Matthias
[toc] | [prev] | [next] | [standalone]
| From | the_gavino_himself <visphatesjava@gmail.com> |
|---|---|
| Date | 2014-11-30 01:47 -0800 |
| Message-ID | <fab5b785-45bd-498d-99ec-22fa0b33de56@googlegroups.com> |
| In reply to | #29506 |
On Thursday, April 10, 2014 7:24:46 AM UTC-4, Todd Hughes wrote: > It's remarkable that most posters in c.l.f seem to understand what most > posters in c.l.c don't: C is more of a worldview and possibly a VM than it > is a language. It is no longer helpful to understand the hardware if you > want to use C. Actually, it's probably harmful. C has its own abstract view > of the hardware and to use C you have to share that view, and of course be > aware of all the broken beer bottles, banana peels and oil slicks left on > the road by C. Especially gcc. Forget whatever else you know and put > aside any expectations you may have. You will be ASSimilated. > > I have never understood the reason why people who are so insistent on > compiling only conforming code and work so hard at miscompiling > non-conforming code scream at the idea that lint should be built into > every C compiler. Empirically we see we can't have it both ways. > > The only safe and reasonable default is warning about anything that isn't > conforming. It's not safe to miscompile something and say nothing about > it. We shouldn't have to specify 180 characters of warning options to get > gcc to tell us what it knows. Just say it. > > The only remotely portable assembler is gas... > > Todd gas?
[toc] | [prev] | [next] | [standalone]
| From | the_gavino_himself <visphatesjava@gmail.com> |
|---|---|
| Date | 2014-04-09 16:12 -0700 |
| Message-ID | <bc273e5a-20a7-4680-b984-3a4e194b0dc8@googlegroups.com> |
| In reply to | #29496 |
On Wednesday, April 9, 2014 12:08:18 PM UTC-7, Bernd Paysan wrote: > Andrew Haley wrote: > > > > >> C was a portable assembly language for a long time after 1977. > > > > > > C was, I suppose, more or less infix PDP-11 assembly language until > > > C90. At that point C acquired an abstract definition and the simple > > > mapping from C to instructions was gone. Simple C compilers which > > > maintained that pre-C90 mapping continued to exist for a while, but > > > over time it has gone. > > > > Fortunately, an ASCII version of the C90 standard is online: > > > > flash-gordon.me.uk/ansi.c.txt > > > > and you can see if that's true. What's true is that, like Forth-94, C90 > > takes a lot of different implementation into account. There are 127 search > > results for "implementation-defined". For example, like in Forth-94, > > division can be floored or symmetric: > > > > "When integers are divided and the division is inexact, if both > > operands are positive the result of the / operator is the largest > > integer less than the algebraic quotient and the result of the % > > operator is positive. If either operand is negative, whether the > > result of the / operator is the largest integer less than the > > algebraic quotient or the smallest integer greater than the algebraic > > quotient is implementation-defined, as is the sign of the result of > > the % operator. If the quotient a/b is representable, the expression > > (a/b)*b + a%b shall equal a ." > > > > All these "implementation-defined" places have exactly the same message: > > Here, the language designer (the standard committee) shifts the > > responsibility to the compiler maintainer. Therefore, as compiler > > maintainer, you, as stated in 1.7, are obliged to "An implementation shall > > be accompanied by a document that defines all implementation-defined > > characteristics and all extensions." This is a "shall", i.e. it is > > nominative. > > > > When reading through the standard, it becomes obvious that a number of these > > "implementation-defined" things arise from different signed number > > representations: C90 ints can be either one's or two's complement, or signed > > magnitude. This affects shifts, additions and conversions to unsigned. > > This does not mean that by the standard this stuff is "undefined": It is > > "implementation-defined", you as compiler maintainer have the duty to define > > it. > > > > Of course, the C90 standard has also "undefined" behavior. E.g. integer > > overflow. There, you are not obliged to document what you do, but you are > > allowed to: > > > > "* Undefined behavior --- behavior, upon use of a nonportable or > > erroneous program construct, of erroneous data, or of > > indeterminately-valued objects, for which the Standard imposes no > > requirements. Permissible undefined behavior ranges from ignoring the > > situation completely with unpredictable results, to behaving during > > translation or program execution in a documented manner characteristic > > of the environment (with or without the issuance of a diagnostic > > message), to terminating a translation or execution (with the issuance > > of a diagnostic message)." > > > > 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. You can always argue that you > > don't care about the quality of your work, but if you say so in public, it > > means that everybody who cares about the quality of the compiler should look > > for another maintainer. > > > > I see lots of things in common with C90 and Forth-94: Both are no longer > > specifying an implementation, but are more abstract, and therefore giving > > the implementers more responsibility - both reflect the diversity which was > > caused by implementing C/Forth on many different machines; especially the > > weird pre-90s machines. However, the big difference between the C90 > > community and the Forth-94 community is that the latter IMHO used that > > responsibility better. E.g. return stack manipulation beyond what the > > program has put on the return stack. Yes, it's non-standard, yes, it's non- > > portable, and yes, maybe it's evil, but a lot of systems still support it. > > Even systems like VFX, where it actually is work to support it. This is a > > deliberate decision of the maintainers of VFX, in order to not break their > > customer's programs. > > > > Not breaking existing programs is considered a "high quality of > > implementation" feature in the Forth community. We always take that into > > account when adding new features, and not breaking existing programs is > > always a valid argument e.g. to rename a introduced word. > > > > So as maintainer of a compiler, you have the three duties to achieve a > > quality implementation: > > > > a) to specify the implementation-defined behavior > > b) to choose wisely what to do for undefined behavior > > c) not to break existing programs > > > > I don't see GCC as a "quality implementation" any longer, because especially > > the attitude at b+c (and sometimes even a) is clearly unprofessional. > > > > -- > > Bernd Paysan > > "If you want it done right, you have to do it yourself" > > http://bernd-paysan.de/ tcc? tcc does 64 bit now
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-04-04 23:20 +0200 |
| Message-ID | <lhn7mi$r6h$1@online.de> |
| In reply to | #29282 |
Jason Damisch wrote: > How bad did we fail? Well, out of the Billions and Billions of > cellphones which have ever been produced, not a single one has been > programmed in Forth or uses Forth as an operating system! 99.99% of them > are programmed in Java? Why? I mean I had a $15 cell phone. The > hardware is probably more powerful than my old Atari ST. It has a faster > processor and more RAM. There are only about 5 games for it, and they are > all programmed in Java. Truth be known, these games are so slow as to be > nearly unplayable. It would be undoable to put Llamatron on the thing, > not because of the small screen size, but because it just couldn't use a > Java library to push around a sufficient number of sprites very well. I > know that all of you I.T. people in here are just going to say buy a more > expensive phone, but that's not my point. MPE did some games for cheap cellphones, in Forth of course. I don't know how fast they were, but AFAIK they got the job, because the Java games were too slow ;-). So why does Java win so many developers? There are several things, and the first one is marketing. Java was and is hyped a lot. What's interesting is that Sun, at the time Java was invented, had two success stories for Forth-like languages: One was Display Postscript, the other was OpenFirmware. Given Sun's marketing power, even OpenFirmware can be considered quite a success: IBM did choose it for its POWER processors, so it even endet up as Apple's BIOS. Intel had its huge NIH syndrome, and ignored OpenFirmware, giving us UEFI (and the vendors nightmares). However, with Algol-like languages in the mainstream, creating a better version of C++ was filling a demand, and Sun could just do that. There were two other companies who could do that: Borland (with Delphi), and Microsoft (with VisualBasic; later hiring the key developer from Borland, and creating C#). The mainstream programming world is moving slowly. If we had all the money and PR to create 9 million Forth programmers, how would we do it? We would have to teach them all; that requires a lot of teachers. I.e. we have to teach the teachers. Teaching a teacher is difficult: They already know everything. And even the teachers who know Forth: Can they teach it? Anton Ertl uses Forth in his compiler course. There's one student who actually picked up Forth. Anton is now trying to teach Forth to beginners, because they have some known deficits, they don't understand recursion and memory (which also means "bits and bytes" and number representation). Forth can be a tool to make them understand it. The most difficult part in Forth is the stack. There are two approaches at it, and IMHO, the vertical approach with stack comments all over a definition is going to fail. Computer languages are strange and follow an alien logic, so programmers excessively comment their programs, in plain text, and the reader then reads the comments, not the program - because that's easier. Don't. Read the language. Then your brain will find a way how to quickly extract stack effects. However, this takes time. Our grammar engine is flexible enough to build rules for computer language grammars, and it is powerful enough to track stacks (up to a certain depth). Long interwinded German sentences prove that fact. But our grammar engine needs a lot of training: it is not conscient, it picks up things when repeated often enough. However, all the other mainstream languages have a different grammar, one already taught at school. Yes, it was hard to learn (mathematical infix notation), but it is taught to prepub children. They take that kind of stuff five times faster. It takes them years to learn. It is probably way harder than the stack and postfix. But it is done early, and then it sticks. Note that Gosling wrote NeWS before he started Java. NeWS is using PostScript with a lot of other Forth-like features like cooperative multi- tasking (and object oriented stuff, which is not very Forth-like), and was a way more sophisticated way to drive a display than X10/X11. Despite it has been technically way ahead of the competition, it lost. And Gosling wrote a mainstream language. Which had about the same feature set, with the exception of not being able to send code around (NeWS could, Java can't). I think that's rather telling. The success of a programming system is not about capabilities, it is about acceptance. -- 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-07 17:40 +0000 |
| Message-ID | <2014Apr7.194040@mips.complang.tuwien.ac.at> |
| In reply to | #29286 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl uses Forth in his compiler course.
The compiler course uses C because it works with C-based tools. I
have been wondering whether we should switch to something else.
I have an elective course on stack-based languages where I teach Forth
and Postscript.
>Anton is now trying to teach Forth to beginners,
Trying? :-)
- 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-08 00:52 +0200 |
| Message-ID | <lhva76$h7h$1@online.de> |
| In reply to | #29388 |
Anton Ertl wrote: >>Anton is now trying to teach Forth to beginners, > > Trying? :-) According to my stats, the Austria users for Gforth on Android jumped from 8 to 58 in the last month. So we can say, the beginners are trying, too ;-). -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Assad Ebrahim <assadebrahim2000@gmail.com> |
|---|---|
| Date | 2014-04-07 16:13 -0700 |
| Message-ID | <4ffa1dfd-1a64-4cc8-98d1-9ac680534c7f@googlegroups.com> |
| In reply to | #29412 |
On Monday, April 7, 2014 11:52:22 PM UTC+1, Bernd Paysan wrote: > > According to my stats, the Austria users for Gforth on Android jumped from 8 > to 58 in the last month. So we can say, the beginners are trying, too ;-). > Does Android run GForth in a protected space, or is the entire system able to be clobbered by an errant command? (How many bricks may be the result of the enthusiasm? ;)
[toc] | [prev] | [next] | [standalone]
| From | Ron Aaron <rambamist@gmail.com> |
|---|---|
| Date | 2014-04-08 06:37 +0300 |
| Message-ID | <lhvqt7$lid$1@dont-email.me> |
| In reply to | #29413 |
I don't think there's cause to worry; unless gforth runs as "root", it can't do much damage. On 04/08/2014 02:13 AM, Assad Ebrahim wrote: > > Does Android run GForth in a protected space, or is the entire > system able to be clobbered by an errant command? > > (How many bricks may be the result of the enthusiasm? ;) >
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-04-09 01:12 +0200 |
| Message-ID | <li1voj$c08$1@online.de> |
| In reply to | #29413 |
Assad Ebrahim wrote: > Does Android run GForth in a protected space, or is the entire > system able to be clobbered by an errant command? It's a normal app, it can read and write the SD card. If that breaks your phone, almost every app could do that. > (How many bricks may be the result of the enthusiasm? ;) Yours is still the only case I know, and you said it was a hardware damage, unrelated to Gforth. For some serious security related stuff (like net2o), I'll change the storage of the sources on the sdcard to the app's private hierarchy. But for development, that's the ideal place, because you can access it with a file browser and you don't have to root the phone. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-04-08 10:16 +0000 |
| Message-ID | <5343cc8d$0$24945$e4fe514c@dreader36.news.xs4all.nl> |
| In reply to | #29412 |
In article <lhva76$h7h$1@online.de>, Bernd Paysan <bernd.paysan@gmx.de> wrote: >Anton Ertl wrote: >>>Anton is now trying to teach Forth to beginners, >> >> Trying? :-) > >According to my stats, the Austria users for Gforth on Android jumped from 8 >to 58 in the last month. So we can say, the beginners are trying, too ;-). Looking around I see a lot of long time Forthers trying out Android gForth. > >-- >Bernd Paysan >"If you want it done right, you have to do it yourself" >http://bernd-paysan.de/ > -- 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 | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-04-04 17:41 -0400 |
| Message-ID | <op.xdtaiqy96zenlw@localhost> |
| In reply to | #29282 |
On Fri, 04 Apr 2014 13:26:04 -0400, Jason Damisch <jasondamisch@yahoo.com> wrote: > Why did Forth fail so badly? > I don't know all the historical aspects of it. I can tell you that Forth had a few failures which received extremely negative press. I can tell you that Forth became known as being "write once" language, meaning it was too cryptic for anyone to figure out once coded. Yes, that's even in the context of the IOCCC contest for obfuscated C. Ironic? I can tell you that C is far more powerful and flexible in many ways, IMO obviously. Forth is very rudimentary by comparison. I can also tell you what I think are weaknesses in the language. Usually, these issues are dismissed by the experts here as trivial or unimportant. Unfortunately, that doesn't change people's perception. People complain for a reason. Only fixing the language issues as perceived by others changes people's perception. That's something the Forth community is unwilling to do. This alienates those who would consider using Forth. I.e., someone who likes their steak well done and not burnt, is not going to eat a steak seared on the outside and cooked rare on the inside even if the expertly trained classical chef believes that's the best method of preparation. They want their steak fixed the way they like it. > I mean the win of Java VS the fail of Forth is so absolute as to be mind > boggling. I'd like to hear a real answer, and not that "Forth Sucks" > because I think that Forth is a darn good mousetrap. It is still quite > usable and is *extremely* flexible. I don't think it's mind boggling. Sun was a hugely successful software company, worth billions of dollars, that produced Java at their expense, rapidly updated and fixed issues with the language, maintained and produced it for decades, and gave to the general public for free. It's much the same thing FSF does, except they aren't wealthy, and are dependent on a flawed ideology, and license which perpetuates robbery. It's also much the same thing that Microsoft does. MS first sells you an OS, then they provide rapid updates and fixes, maintain and produce the OS for decades, for free - after the initial expense. Other projects, like ANDF (Tendra C compiler), tend to come out of university settings where they turn the project over the public. However, no one is familiar or skilled enough with the code, or frequently lack the resources or time to use the code, so the project in reality was actually abandoned. The original creators, university students and professors move on to other projects. So, there is no expert human support to take the project forward. You can see this with most MIT or BSD licensed code. I.e., it would be best called dump-ware, software dumped into the public without any support. > It goes like this. If you program in Java, you can't fail. If you > program in Forth, you can't win. It does not matter how good or bad > you are. Would you consider the position of Greg or Chuck at this > point in time a win or a fail? > > The Wikipedia article on Java states that in 2014 Java is the most > popular programming language with 9 million developers. No. Quote: "... is one of the most popular ..." One, not *IS*. The first source they cite show it's the second most popular. The other source they cite is the well know TIOBE index. It shows Java is in a constant battle with C for first place, with Java taking the lead for some years with C for others. Of course, Java is derived from C. > How many developers do you think actually make money programming in > Forth? Probably about 9! > > I'm not trying to Flame or Troll. I'd just like to hear a really > good explanation of this. It makes me upset. The problem with the Forth community is that they have their heads buried in the sand, or hand over their ears or eyes or mouths, like those metaphorical monkeys. They typically take offense when I say that, but I'll explain it yet again. I wasn't and am not currently flaming or trolling then either, even though my responses have been taken that way and will likely be yet again. Many brilliant ideas simply fail. Period. End-of-story. It doesn't matter that they were or still are brilliant ideas. They failed for various reasons: too early, too late, failure to adapt, negative public perception, infighting, too much standardization, too little standardization, too open, too closed, lack of funding, lack of profit, no purpose, etc. Once an idea has failed, there is almost no coming back, no chance at a recovery. The world has moved on. However, the Forth community is like a cult. It keeps on insisting that Forth must succeed because Forth is great! So, Forth must be rewarded for it's greatness! Even you did this by saying Forth is so flexible and you're upset that it's not well used. It's like reading about a failed cult that just won't give up on their savior coming no matter how many times the predictions were wrong. Yet, if you don't see the Forth community as a cult, you should still realize that it is. The Forth community has a savior: Chuck Moore. Any time the Forth community is "wishing" or "praying" for something new, they begin by discussing Charles Moore and what he is or isn't doing today. Savior... Sometimes it's a disciple or missionary who spreads the gospel, e.g., Jeff Fox, Julian Noble, Ms. Rather, etc. See it yet? No? Brainwashed. > How bad did we fail? Well, out of the Billions and Billions of > cellphones which have ever been produced, not a single one has been > programmed in Forth or uses Forth as an operating system! 99.99% of > them are programmed in Java? Why? Free. Widely available. Permanence or long-lasting. Financially supported by a major corporation(s). Based off of C language so skilled programmers are readily available. Etc. > I mean I had a $15 cell phone. The > hardware is probably more powerful than my old Atari ST. It has a > faster processor and more RAM. There are only about 5 games for it, and > they are all programmed in Java. Truth be known, these games are so > slow as to be nearly unplayable. It would be undoable to put Llamatron > on the thing, not because of the small screen size, but because it just > couldn't use a Java library to push around a sufficient number of > sprites very well. I know that all of you I.T. people in here are just > going to say buy a more expensive phone, but that's not my point. > > It's not like Java is the [ideal] language for everything. FYI, idea -> ideal. Aren't all general-purpose languages ideal for everything? That's what makes them general purpose after all ... Some would say general purpose means they're weak in certain areas, but I would disagree with that. Remember, C and Forth are general purpose languages. Others argue that domain specific languages are the way to go. Of course, you must have that domain specific language available to use it. "Therein lies the rub." > It is C++ on top of a virtual machine. I think it's C not C++. > I probably would not recommend it for resource constrained embedded > systems. That's a common complaint of those who look at the memory footprint of a language like C versus Forth or other languages, instead of looking at the language functionality. You forgo so much functionality and available software by using a non-C derived language or not using C/C++. > But just like nobody every go fired for buying IBM, nobody ever go fired > for using Java. The internet is driving the distribution of online or cloud applications that execute just-in-time. Is Forth well suited for that? I don't think so. C isn't suited for that either. You have to compile it. Most users don't want to be bothered with compiling applications. They just want apps to work correctly. Even programmers just want applications to work correctly. I'm not about to spend my time without pay to fix Opera or Mozilla Firefox. If I've got a problem with them, it gets downgraded to an earlier version with pre-compiled binaries. I'm not building it from scratch to end up with it not compiling because GLIBC, or a half-dozen other libraries are incompatible versions. This happens *ALL* the time with Linux software packages distributed as source. I recently attempted to update one software package and had to download about fifteen different libraries and install them. Fortunately, they were pre-compiled with binaries. Even so, it still took almost and hour. > I mean even if I started a project trying to write an embedded system > on a resources constrained device, and I chose to do it in Java, no > matter what kind of train wreck I produced, I would probably not be > fired, but would be hired for the next job, even possibly to reproduce > the same results. At this point, most rational people would conclude that Forth is so far behind or rarely used that it's a bad choice, even if it truly was the correct choice from a technical perspective. I.e., most managers would fire or strongly consider firing you for using/chosing Forth over C, Java, etc. "What *is* he thinking? ... drinking?" They simply can't find anyone who want to kill their resume by programming in Forth. > How did we lose so badly? Hopefully, I've provided some non-cult insight to that above. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2014-04-05 02:49 +0200 |
| Message-ID | <lhnjvc$5ha$1@news.albasani.net> |
| In reply to | #29287 |
On Fri, 04 Apr 2014 17:41:04 -0400 "Rod Pemberton" <dont_use_email@xnothavet.cqm> wrote: > On Fri, 04 Apr 2014 13:26:04 -0400, Jason Damisch > <jasondamisch@yahoo.com> wrote: > > > It is C++ on top of a virtual machine. > > I think it's C not C++. I actually looked at source code. JIT is written in C++, JNI bindings in C and everything else in Java. -- Click OK to continue...
[toc] | [prev] | [next] | [standalone]
| From | Hannu Vuolasaho <vuokkosetae@gmail.com> |
|---|---|
| Date | 2014-04-04 17:46 -0700 |
| Message-ID | <b1050ef1-5dc3-4bee-9948-913984da0d58@googlegroups.com> |
| In reply to | #29282 |
On Friday, April 4, 2014 8:26:04 PM UTC+3, Jason Damisch wrote: > I mean the win of Java VS the fail of Forth is so absolute as to be mind > boggling. I'd like to hear a real answer, and not that "Forth Sucks" > because I think that Forth is a darn good mousetrap. It is still quite > usable and is *extremely* flexible. I have read that there are two hard things in programming. Cache invalidation and naming things. In Forth you name a lot of things and in collabrative development it is nightmare. To understand your coworkers code when only hint might be the name of the word. It is not very productive. One counter sympton is to have rather long i_module_some_job_parameters functions in C. Also the flexibility is another issue. When better and good developer work and better makes interesting, not easily understandable word it takes time to use, refactor or copy it. How about adding junior to this kind of development? A lot of time is used to even tell what words are used, what they mean and how project should be developed. In C there are usually some kind of documentation but in forth there is the code to read. > What is more religious? Using Forth or trying to slam the square peg of > the most popular single stack everything is a function everything is an > object programming language into the round hole of every computer problem > in creation with a jack hammer? Religion has nothing to do it as long as you use Emacs to write the code :) People want to use familiar things. If in one project provided some experience of jack hammer tool, then we know our jack hammer and then we use it, even normal screwdriver would do the job. With Forth it is always a bit of unknown territory in the beginning of new project even there are some libs to support development. That is unknown factor in management. No matter how good your designs are, the implementation goes different direction than planned and takes more time. One thing is how Forth reacts bugs. It crashes hard while Javascript says can't set property of undefined and continues like everything is working. Now marketing can sell something and there is money coming from broken webapp. So is Forth is different and that's why it sucks on the desks of those who make decisions. Best regards, Hannu Vuolasaho
[toc] | [prev] | [next] | [standalone]
Page 13 of 22 — ← Prev page 1 … 11 12 [13] 14 15 … 22 Next page →
Back to top | Article view | comp.lang.forth
csiph-web