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 1 of 22 [1] 2 3 … 22 Next page →
| From | Jason Damisch <jasondamisch@yahoo.com> |
|---|---|
| Date | 2014-04-04 10:26 -0700 |
| Subject | Epic Fail |
| Message-ID | <f357fc56-c996-4d72-a53d-194a13e276ec@googlegroups.com> |
Why did Forth fail so badly? 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. 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. 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. 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. It's not like Java is the idea language for everything. It is C++ on top of a virtual machine. I probably would not recommend it for resource constrained embedded systems. But just like nobody every go fired for buying IBM, nobody ever go fired for using Java. 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. How did we lose so badly? 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? Jason
[toc] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-04-04 12:42 -0500 |
| Message-ID | <V7qdnS4kyI6LcqPOnZ2dnUVZ8jadnZ2d@supernews.com> |
| In reply to | #29282 |
Jason Damisch <jasondamisch@yahoo.com> wrote: > Why did Forth fail so badly? > > 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. > > It goes like this. If you program in Java, you can't fail. If you > program in Forth, you can't win. Why would you compare these two? They have way different goals. > It's not like Java is the idea language for everything. It is C++ > on top of a virtual machine. I probably would not recommend it for > resource constrained embedded systems. But just like nobody every > go fired for buying IBM, nobody ever go fired for using Java. 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. I promise I'd fire you. And to some extent I'm one of the people responisible for Java. :-) Forth doesn't do what Java does. Java doesn't do what Forth does. This seems like a very odd conversation to have, much too purist for my taste. From time to time I come cross Forthers; some use Forth in their jobs, some don't, but it has a profound effect on the way that they think. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | forthisit@gmail.com |
|---|---|
| Date | 2014-04-04 11:09 -0700 |
| Message-ID | <1f916281-6181-4aa2-9e1f-4de26e717f40@googlegroups.com> |
| In reply to | #29282 |
On Friday, April 4, 2014 12:26:04 PM UTC-5, Jason Damisch wrote: > Why did Forth fail so badly? > > 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. > > 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. 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. > > 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. > > It's not like Java is the idea language for everything. It is C++ on top of a virtual machine. I probably would not recommend it for resource constrained embedded systems. But just like nobody every go fired for buying IBM, nobody ever go fired for using Java. 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. > > How did we lose so badly? > > 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? > > Jason I think part of it is that we like to be contrarian. It wouldn't be nearly as much fun if Forth were immensely popular, would it?
[toc] | [prev] | [next] | [standalone]
| From | Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> |
|---|---|
| Date | 2014-04-04 22:09 +0100 |
| Message-ID | <kh5uj9tkvaf009shh1p5edrc7te06gof3j@4ax.com> |
| In reply to | #29282 |
On Fri, 4 Apr 2014 10:26:04 -0700 (PDT), Jason Damisch <jasondamisch@yahoo.com> wrote: >Why did Forth fail so badly? > >I mean the win of Java VS the fail of Forth is so absolute as to be mind boggling. > >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. > I've felt this way as well and, as you say, it is disappointing since I do think Forth is a real gem -- which I'd come across it twenty years ago. I've chalked its performance relative to other hegemonic languages like C, Java, etc. up to four things: (1) being perceived as a 'giant-killer' through solving a massive problem or enabling a killer app (preferably both) (2) having organisational champions that are hegemonic, prestigious, and influential about its use, (3) having widespread acceptance / appeal among academics, and (4) being able to scale the language both to the best talent and also accomodate lesser talents --- often through the use of standard libraries. I think Forth has (1) but has struggled with (2), (3), and (4) as compared to the hegemonic languages which have at least 3 of the 4 if not all four. Some examples: C -- after initial birthing difficulties, it subsequently had the backing and prestige of Bell Labs. And it very quickly found a massive audience because it solved the very real problem of a 'portable assembly' with which to write operating systems that could be readily ported to almost any machine. UNIX then became the vehicle through which companies and educational institutions far and wide were exposed to C. So C has (1), (2), (3) through UNIX. And its approach to standard libraries and being itself standardised without too much controversy helped give it (4). Fortran had the backing of scientists because it solved the very real problem of getting away from hand-coding numerical work using assembly. So it had (3) and (1), and then was picked up very quickly among the large national laboratories in the U.S. (Lawrence Livermore, Argonne, Sandia), as well as defense / aerospace (Boeing, Lockheed, NASA). [In fact, when I worked at Boeing in early 2000, their software libraries while all in C had many routines that were wrappers of Fortran codes]. This gives it (2). C++ --- again Bell Labs, and following on from C. Then Microsoft picked it up, along with Booch diagrams and all manner of object orientatation fever that raced through business development circles (Yourdon, and others). So it had (1) through object orientation, (2), (3). I think it has always struggled with (4) -- hence easing the way for Java. Java --- had the backing of Sun, and solved three very real problems: i) write once, run anywhere, ii) garbage collection, iii) web applets. Its lack of pointers made it *easy* to teach. Hence it had (4) definitely, was enjoyed by (3) in introductory CS classes, had (2) and (1). Ruby --- Rails is the killer app... Perl in its day -- Regular expressions, text processing, & scripting were the killer apps. Go now has the backing of Google and is positioning itself as the successor in the C line of programming languages. That alone will probably guarantee that it rises quickly and has a long lifetime. .Net --- certainly has (2) and (4). Lisp -- it had early on the AI community and academics. So it was taught to every budding CS major. So it had (1) and (3). Never quite had (2) and certainly isn't (4). So though I don't see it as a hegemonic language, it is in the background of most university trained computer scientists and is therefore hegemonic in mindshare. When I look at Forth along these lines: it was embraced by astronomical observatories the world over. It was embraced by embedded developers. But it was usually small shops, bright individuals, dedicated craftsmen. For a while in the 70s and 80s, I think Forth was quite prominent, popular, and fast-growing. But AFAIK its never really had the backing of a large number of academics (Julian and a few others seemed more like exceptions). Nor did it have the unqualified support of very large companies in software / computing. Again, NASA seems more a mission oriented customer like the observatories for which Forth was a brilliant screw-driver. Where So I think Forth has (1) -- embedded apps --- and it is successfully in the boot-loaders of many computers and devices. Indeed, Chuck Moore's patent portfolio is still bringing in substantial revenue through licensing fees. But I think it's had difficulty with (2), (3) and (4). -- it's not in with academia, so doesn't get exposure with the young smart minds entering industry. -- it's not in with large players in industry, so it doesn't get baked the kinds of activities which would ensure its continuing spread -- and as others have said, Forth is a language that amplifies talent as well as lack of it. That doesn't scale well. Apologies for the essay ;) --- it's something that's been bothering me too. And I'd welcome feedback on the above as I'm relatively new to Forth so have not had a long history with it. - Assad
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-04-04 21:44 -1000 |
| Message-ID | <n92dndUrFeTvKaLOnZ2dnUVZ_rCdnZ2d@supernews.com> |
| In reply to | #29285 |
On 4/4/14 11:09 AM, Assad Ebrahim wrote: > On Fri, 4 Apr 2014 10:26:04 -0700 (PDT), Jason Damisch > <jasondamisch@yahoo.com> wrote: > >> Why did Forth fail so badly? >> >> I mean the win of Java VS the fail of Forth is so absolute as to be mind boggling. ... > > I've felt this way as well and, as you say, it is disappointing since > I do think Forth is a real gem -- which I'd come across it twenty > years ago. > > I've chalked its performance relative to other hegemonic languages > like C, Java, etc. up to four things: > > (1) being perceived as a 'giant-killer' through solving a massive > problem or enabling a killer app (preferably both) > > (2) having organisational champions that are hegemonic, prestigious, > and influential about its use, > > (3) having widespread acceptance / appeal among academics, and > > (4) being able to scale the language both to the best talent and also > accomodate lesser talents --- often through the use of standard > libraries. > > > I think Forth has (1) but has struggled with (2), (3), and (4) as > compared to the hegemonic languages which have at least 3 of the 4 if > not all four. I agree entirely. Forth failed in the early years for lack of strong support from well-known, well-funded backers. I think your analysis is accurate. Also, as I have described before, many of the early magazine articles in thei 1980's suffered from the fact that code samples were presented not as text, but as graphics. Art directors "fixed" the samples submitted to them by deleting "extraneous" spaces before and after "punctuation" such as : ; . , etc., and fixed what they perceived as spelling mistakes, thus rendering good Forth code literally unreadable even to Forthers! Several times I got proofs of articles I had submitted, and complained bitterly to the editors, only to be told that I only controlled the "text" not the "graphics", which the art dept. could "fix" as they saw fit. So, in addition to the RPN issue, Forth was rendered "unreadable" to anyone who didn't already know it! It never recovered. ... > When I look at Forth along these lines: it was embraced by > astronomical observatories the world over. It was embraced by > embedded developers. But it was usually small shops, bright > individuals, dedicated craftsmen. For a while in the 70s and 80s, I > think Forth was quite prominent, popular, and fast-growing. But AFAIK > its never really had the backing of a large number of academics > (Julian and a few others seemed more like exceptions). Nor did it > have the unqualified support of very large companies in software / > computing. Again, NASA seems more a mission oriented customer like > the observatories for which Forth was a brilliant screw-driver. Where > So I think Forth has (1) -- embedded apps --- and it is successfully > in the boot-loaders of many computers and devices. Indeed, Chuck > Moore's patent portfolio is still bringing in substantial revenue > through licensing fees. But I think it's had difficulty with (2), (3) > and (4). > -- it's not in with academia, so doesn't get exposure with the young > smart minds entering industry. > -- it's not in with large players in industry, so it doesn't get baked > the kinds of activities which would ensure its continuing spread > -- and as others have said, Forth is a language that amplifies talent > as well as lack of it. That doesn't scale well. > > Apologies for the essay ;) --- it's something that's been bothering me > too. It's an excellent analysis. Thank you! 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 | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-04-05 09:42 -0700 |
| Message-ID | <59821196-a483-4026-98ea-d0b3f09f3055@googlegroups.com> |
| In reply to | #29293 |
On Saturday, April 5, 2014 12:44:50 AM UTC-7, Elizabeth D. Rather wrote: > Forth failed in the early years for lack of strong > support from well-known, well-funded backers. Only a salesperson would say this --- and you suppose that Forth (the language) would have succeeded if Forth Inc. (your company) had been given "strong support from well-known, well-funded backers" --- no, Forth Inc. is the cause of Forth's failure, so the more support that Forth Inc. gets, the more "epic" the failure. I remember in the 1980s that Forth was a serious contender against C for the micro-computer and micro-controller markets. At that time, C was closely tied to Unix, and nobody expected Unix to run on personal computers any time soon if ever, so C seemed like an unlikely candidate for the personal computer. As for micro-controllers, C seemed beyond unlikely, with Forth a much more realistic possibility --- in those days, micro-controllers were severely memory limited, so assembly-language was the only realistic choice --- but if any HLL had any chance at all, it would have been Forth. I wrote a program for the Apple-IIe that could do symbolic calculus (derivatives, but not integrals); I had to write my own Forth 65c02 cross-compiler to do this, but it did work --- although C was available for the Apple-IIe, a program like this would have been impossible in C due to C's gross code-bloat. I wrote my cross-compiler in UR/Forth because PolyForth was obviously incapable of such a large program. The cause of Forth's failure was a series of gross technical failures by Forth Inc., and this gave Forth (the language) a bad reputation (because Forth Inc. owns the name "Forth" and most people conflated Forth Inc. with Forth the language). Specifically, PolyForth was an epic fail. The major problem was that it was limited to 64K (application program, compiler, editor, everything!). This was on MS-DOS, which allows up to 640K. It was abundantly obvious that nobody at Forth Inc. understood how the 8088 segment-registers worked --- PolyForth was a straight port of an old 8-bit Forth system (presumably written by Chuck Moore) that was limited to 64K by the hardware. At the same time, C (I used Turbo C from Borland, but there were several others) all supported the six memory models. The Small model was the most popular as the programmer could avoid using far-pointers for efficiency, but could yet get 64K for code and 64K for data (this was for the application program only, the compiler, editor, etc. did not share memory with the application program). Even the Tiny model was better than PolyForth because there was 64K for the application program code and data --- but the compiler, editor, etc., did not share memory with the application program. Actually, even QBasic was better than PolyForth in that the application program was 64K and the compiler, editor, etc., did not share memory with the application program. Within this context, especially as MS-DOS computers started getting sold with 512K routinely, PolyForth became ridiculous --- PolyForth ruined the reputation for the entire Forth community. There were some good Forth systems available. I used UR/Forth which had a memory model roughly comparable to C's Small model, and (according to my bench-marking) was roughly comparable to Turbo C in regard to speed. Unfortunately, it was too late --- Forth Inc. had largely killed Forth's reputation, and most programmers wouldn't touch Forth with a 10-foot pole --- it was impossible to talk about Forth without getting flamed as a member of Elizabeth Rather's cult, the retarded army. The ANS-Forth standard really nailed the coffin shut! It was abundantly obvious that ANS-Forth was just SwiftForth. The standards document was full of wishy-washy "may or may not" statements. So what exactly was standardized? The reason why it was so wishy-washy is that the #1 rule of the ANS-Forth committee was that SwiftForth had to be standard without any modification. All of these statements effectively say "such-and-such may be SwiftForth or it may make sense." For example, we have 3.2.3.2.: "The control-flow stack may, but need not, physically exist in an implementation. If it does exist, it may be, but need not be, implemented using the data stack. The format of the control-flow stack is implementation defined. Since the control-flow stack may be implemented using the data stack, items placed on the data stack are unavailable to a program after items are placed on the control-flow stack and remain unavailable until the control-flow stack items are removed." In this case, SwiftForth puts the control-flow data on the data stack, which gets in the way of accessing any data that the user has put on the data stack. It was well known that the control-flow data had to have its own stack, and many Forth implementations did this, so this was said to be standard too. But the Forth application-programmer can't take advantage of this good design, but he has to assume the worst-case scenario so that his code will be portable --- and the worst-case scenario is always SwiftForth, so SwiftForth effectively became the standard. The world is full of idiot-salespeople, and I just ignore them. Elizabeth Rather can't be ignored however, because she standardized her incompetence as ANS-Forth, and now she is doing the same to Forth-200x. Forth (the language) will never succeed until Elizabeth Rather is defeated --- I am doing everything that I can to defeat her --- because I love programming in Forth.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-04-05 10:47 -0700 |
| Message-ID | <3fa5a113-cb5b-4618-a48b-a11db7d7f28a@googlegroups.com> |
| In reply to | #29300 |
On Saturday, April 5, 2014 9:42:53 AM UTC-7, hughag...@yahoo.com wrote: > I wrote a program for the Apple-IIe that could do symbolic calculus (derivatives, but not integrals); I had to write my own Forth 65c02 cross-compiler to do this, but it did work --- although C was available for the Apple-IIe, a program like this would have been impossible in C due to C's gross code-bloat. That was a typo --- I meant the Apple-IIc --- the Apple-IIe wouldn't have been capable of supporting such a large program. Actually, I used a Laser-128 --- a clone of the Apple-IIc.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-04-05 15:25 -0400 |
| Message-ID | <op.xduyw8gf6zenlw@localhost> |
| In reply to | #29300 |
On Sat, 05 Apr 2014 12:42:53 -0400, <hughaguilar96@yahoo.com> wrote: > I remember in the 1980s that Forth was a serious contender against C for > the micro-computer and micro-controller markets. I really don't remember that. I read every issue of Byte magazine from the early 1980's through early 1990's, both articles and advertisements. The Byte issue on Forth was the first time I recollect seeing anything about Forth. I'm not saying it wasn't there, but I don't recall it today. I read numerous other PC and electronic magazines also, but not as thoroughly or completely. I don't recall seeing Forth in those either. > I wrote a program for the Apple-IIe that could do symbolic calculus > (derivatives, but not integrals); Resurrect that. Fix it up. Make it a small smartphone app. Compile it. Sell it. Earn money from advanced high school students and university students too lazy to do their calculus. Laplace transforms will simplify the program, if you didn't use them originally. > [...] > program like this would have been impossible in C due to C's gross > code-bloat. ... > Specifically, PolyForth was an epic fail. The major problem was that it > was limited to 64K (application program, compiler, editor, everything!). > This was on MS-DOS, which allows up to 640K. It was abundantly obvious > that nobody at Forth Inc.[...] understood how the 8088 segment-registers > worked [...] Segmented memory models are a problem for most high-level languagess, C included. Most programming expect a linear or flat address space or memory pool, with contiguous addressing of data items. Most of the older languages use (single) pointers, i.e., not multi-part or split. > The ANS-Forth standard really nailed the coffin shut! It was abundantly > obvious that ANS-Forth was just SwiftForth. The standards document was > full of wishy-washy "may or may not" statements. So what exactly was > standardized? The reason why it was so wishy-washy is that the #1 rule > of the ANS-Forth committee was that SwiftForth had to be standard > without any modification. All of these statements effectively say > "such-and-such may be SwiftForth or it may make sense." The early C standard has much the same problem. It was standardized from microprocessors which had a similar architecture but also from mainframes with a bunch of non-standard architectures. So, officially, there is lots of "undefined behavior" or "environment specific" in C, which is actually common, widely implement, and working in C today because microprocessors have it. Much of the differences are in how pointers are handled. So, you can't fully escape history. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-04-07 17:29 +0000 |
| Message-ID | <2014Apr7.192923@mips.complang.tuwien.ac.at> |
| In reply to | #29285 |
Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> writes:
>C -- after initial birthing difficulties, it subsequently had the
>backing and prestige of Bell Labs. And it very quickly found a
>massive audience because it solved the very real problem of a
>'portable assembly' with which to write operating systems that could
>be readily ported to almost any machine.
Unfortunately, the current bunch of C compiler maintainmers don't want
C to be a portable assembly language.
> UNIX then became the vehicle
>through which companies and educational institutions far and wide were
>exposed to C. So C has (1), (2), (3) through UNIX. And its approach
>to standard libraries and being itself standardised without too much
>controversy helped give it (4).
I think one should not underestimate the value of Microsoft choosing C
as the standard language for Windows.
>Java --- had the backing of Sun, and solved three very real problems:
>i) write once, run anywhere, ii) garbage collection, iii) web
>applets.
Web applets? Really?
> Its lack of pointers made it *easy* to teach.
It's the reason why I teach Forth first in my introductory programming
course. Java comes later for pragmatic reasons (interaction with
other courses), but I think it's a bad choice for an introductory
course; and that's because it's not easy to teach.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2013: http://www.euroforth.org/ef13/
[toc] | [prev] | [next] | [standalone]
| From | Assad Ebrahim <assadebrahim2000@gmail.com> |
|---|---|
| Date | 2014-04-07 12:35 -0700 |
| Message-ID | <19597f37-fa23-478f-9a5f-b2aa66e89ae4@googlegroups.com> |
| In reply to | #29387 |
On Monday, April 7, 2014 6:29:23 PM UTC+1, Anton Ertl wrote: > Assad Ebrahim writes: > > >C -- after initial birthing difficulties, it subsequently had the > >backing and prestige of Bell Labs. And it very quickly found a > >massive audience because it solved the very real problem of a > >'portable assembly' with which to write operating systems that could > >be readily ported to almost any machine. > > Unfortunately, the current bunch of C compiler maintainmers don't want > C to be a portable assembly language. > Could you elaborate a bit on this? Is it just the C standard you're referring to (which I understand is in revision) or GCC with its notoriously (?) complex back-end --- or perhaps both? > > UNIX then became the vehicle > >through which companies and educational institutions far and wide were > >exposed to C. So C has (1), (2), (3) through UNIX. And its approach > >to standard libraries and being itself standardised without too much > >controversy helped give it (4). > > I think one should not underestimate the value of Microsoft choosing C > as the standard language for Windows. Good point -- I'd forgotten about that. Yes, Win32API was all C based before MFC went to C++. > >Java --- had the backing of Sun, and solved three very real problems: > >i) write once, run anywhere, ii) garbage collection, iii) web > >applets. > > Web applets? Really? Ok, perhaps should have forsaken the rhetorically appealing third item, although I seem to remember that "the internet" was part of at least the PR side of the Java rise to prominence. > > Its lack of pointers made it *easy* to teach. > It's the reason why I teach Forth first in my introductory programming > course. So how do you find your students respond to being taught Forth? Do they 'get' it? Do they like it? Do they start using it / keep using it through their studies and later? > Java comes later for pragmatic reasons (interaction with > other courses), but I think it's a bad choice for an introductory > course; and that's because it's not easy to teach. > > > - anton
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-04-08 15:54 +0000 |
| Message-ID | <2014Apr8.175427@mips.complang.tuwien.ac.at> |
| In reply to | #29398 |
Assad Ebrahim <assadebrahim2000@gmail.com> writes:
>On Monday, April 7, 2014 6:29:23 PM UTC+1, Anton Ertl wrote:
>> Assad Ebrahim writes:
>>
>> >C -- after initial birthing difficulties, it subsequently had the
>> >backing and prestige of Bell Labs. And it very quickly found a
>> >massive audience because it solved the very real problem of a
>> >'portable assembly' with which to write operating systems that could
>> >be readily ported to almost any machine.
>>
>> Unfortunately, the current bunch of C compiler maintainmers don't want
>> C to be a portable assembly language.
>>
>
>Could you elaborate a bit on this?
It's something Andrew Haley (who is a GCC maintainer) wrote (or at
least how I understood what he wrote; often he writes something, and
when I present my understanding of what he wrote, he denies writing
that). Also, judging from
<07qdndj_37WIDp7OnZ2dnUVZ_tmdnZ2d@supernews.com>, "that's what the
hardware does" seems to be an insult in GCC circles, which is totally
contrary to a portable assembler.
>Is it just the C standard you're referring to
>(which I understand is in revision) or GCC with
>its notoriously (?) complex back-end --- or perhaps both?
It's the attitude that C compiler maintainers (GCC and LLVM, and
probably others as well) have wrt the standard and the intended
meaning of programs. They don't consider the C standard a minimal set
of requirements, but exhaustive (exception: if SPEC uses stuff beyond
the C standard, they do not miscompile it), and any non-standard usage
a good reason for miscompiling the program (except if it's a SPEC
program).
>> >Java --- had the backing of Sun, and solved three very real problems:
>> >i) write once, run anywhere, ii) garbage collection, iii) web
>> >applets.
>>
>> Web applets? Really?
>
>Ok, perhaps should have forsaken the rhetorically appealing
>third item, although I seem to remember that "the internet" was
>part of at least the PR side of the Java rise to prominence.
Yes, applets were certainly prominent in the hype, but I would not
cont them under "solved a very real problem".
>> > Its lack of pointers made it *easy* to teach.
>> It's the reason why I teach Forth first in my introductory programming
>> course.
>
>
>So how do you find your students respond to being taught Forth?
>Do they 'get' it? Do they like it? Do they start using it
>/ keep using it through their studies and later?
I just started a month ago, too early to tell.
- 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 | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-04-08 12:43 -0500 |
| Message-ID | <yJydnchgnJeyqNnOnZ2dnUVZ8smdnZ2d@supernews.com> |
| In reply to | #29449 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Assad Ebrahim <assadebrahim2000@gmail.com> writes: >>On Monday, April 7, 2014 6:29:23 PM UTC+1, Anton Ertl wrote: >>> Assad Ebrahim writes: >>> >>> >C -- after initial birthing difficulties, it subsequently had the >>> >backing and prestige of Bell Labs. And it very quickly found a >>> >massive audience because it solved the very real problem of a >>> >'portable assembly' with which to write operating systems that could >>> >be readily ported to almost any machine. >>> >>> Unfortunately, the current bunch of C compiler maintainmers don't want >>> C to be a portable assembly language. >> >>Could you elaborate a bit on this? > > It's something Andrew Haley (who is a GCC maintainer) wrote (or at > least how I understood what he wrote; often he writes something, and > when I present my understanding of what he wrote, he denies writing > that). Because you always make such an awful job of paraphrasing what I say. However, this time you've got my position more or less right. Did I ever actually say what I want C to be, rather than what C is? I suppose that I might have done, but it's more likely IIRC that I was talking about what C *is* rather than what I want. I don't think I've thought very much about what I want it to be. However, I think that you're right about C compiler maintainers: I can't remember any suggesting that C should be a portable assembly language and wanting to turn it back into one, as C was in 1977. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-04-09 16:16 +0000 |
| Message-ID | <2014Apr9.181655@mips.complang.tuwien.ac.at> |
| In reply to | #29454 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Assad Ebrahim <assadebrahim2000@gmail.com> writes:
>>>On Monday, April 7, 2014 6:29:23 PM UTC+1, Anton Ertl wrote:
>>>> Assad Ebrahim writes:
>>>>
>>>> >C -- after initial birthing difficulties, it subsequently had the
>>>> >backing and prestige of Bell Labs. And it very quickly found a
>>>> >massive audience because it solved the very real problem of a
>>>> >'portable assembly' with which to write operating systems that could
>>>> >be readily ported to almost any machine.
>>>>
>>>> Unfortunately, the current bunch of C compiler maintainmers don't want
>>>> C to be a portable assembly language.
>>>
>>>Could you elaborate a bit on this?
>>
>> It's something Andrew Haley (who is a GCC maintainer) wrote (or at
>> least how I understood what he wrote; often he writes something, and
>> when I present my understanding of what he wrote, he denies writing
>> that).
>
>Because you always make such an awful job of paraphrasing what I say.
Maybe you are doing an awful job of writing what you mean; or maybe
such a good job at writing in a misleading way. Made-up example:
Andrew: It's the average of 1 and 2.
Early Anton (not much Andrew experience yet) thinks: He probably means
the arithmetic mean.
Early Anton writes: Andrew said that it's 1.5.
Andrew: That's not what I wrote. You are doing an awful job of
paraphrasing me.
Early Anton thinks: Hmm, he wrote "the average". Does he mean the
geometric mean or the harmonic mean, or something else?
Early Anton writes: What did you mean with "the average of 1 and 2"?
Andrew gives an answer that clarifies nothing.
Early Anton turns into Later Anton an learns that Andrew is apparently
not interested in a productive discussion, so Anton does not reply.
Andrew had the last word. He has "won"!
Later on it's shorter:
Andrew: It's the average of 1 and 2.
Later Anton (with more Andrew experience) thinks: Hold on, there is
something imprecise here. Andrew is probably playing his tricks
again. No point in replying to that.
>Did I ever actually say what I want C to be, rather than what C is? I
>suppose that I might have done, but it's more likely IIRC that I was
>talking about what C *is* rather than what I want. I don't think I've
>thought very much about what I want it to be.
The compilers and the programs define what C is, so if you are a
compiler maintainer, you should be thinking about what it should be.
And I think that should be more about what the programmers want than
what you want.
>However, I think that you're right about C compiler maintainers: I
>can't remember any suggesting that C should be a portable assembly
>language and wanting to turn it back into one, as C was in 1977.
C was a portable assembly language for a long time after 1977. We
selected GNU C for Gforth in 1992 because it was a portable assembly
language then, and Linus Torvalds selected GNU C for Linux in 1991
because of that. I am pretty sure that that's also what Richard
Stallman intended.
The attitude change came later (maybe with egcs, maybe around
gcc-3.x), and the effects of that change are now trickling piecemeal
into the compiler, and causing one problem after another.
If you had announced at some point that GNU C will no longer be a
portable assembly language, and that you will "optimize" code that has
some overflow somewhere into an infinite loop, we would have started
thinking about getting rid of C much earlier, and maybe other
projects, too. Or we might see a C compiler project that is intended
to provide C as a portable assembly language.
- 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 | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-04-09 13:00 -0500 |
| Message-ID | <bcCdnZdRTslUF9jOnZ2dnUVZ8k-dnZ2d@supernews.com> |
| In reply to | #29494 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> Assad Ebrahim <assadebrahim2000@gmail.com> writes: >>>>On Monday, April 7, 2014 6:29:23 PM UTC+1, Anton Ertl wrote: >>>>> Assad Ebrahim writes: >>>>> >>>>> >C -- after initial birthing difficulties, it subsequently had the >>>>> >backing and prestige of Bell Labs. And it very quickly found a >>>>> >massive audience because it solved the very real problem of a >>>>> >'portable assembly' with which to write operating systems that could >>>>> >be readily ported to almost any machine. >>>>> >>>>> Unfortunately, the current bunch of C compiler maintainmers don't want >>>>> C to be a portable assembly language. >>>> >>>>Could you elaborate a bit on this? >>> >>> It's something Andrew Haley (who is a GCC maintainer) wrote (or at >>> least how I understood what he wrote; often he writes something, and >>> when I present my understanding of what he wrote, he denies writing >>> that). >> >>Because you always make such an awful job of paraphrasing what I say. > > Maybe you are doing an awful job of writing what you mean; or maybe > such a good job at writing in a misleading way. I don't doubt that from time to time I write badly and/or confusingly, but I don't think it's common. I hope it's not. > Made-up example: > > Andrew: It's the average of 1 and 2. > > Early Anton (not much Andrew experience yet) thinks: He probably means > the arithmetic mean. > Early Anton writes: Andrew said that it's 1.5. > > Andrew: That's not what I wrote. You are doing an awful job of > paraphrasing me. > > Early Anton thinks: Hmm, he wrote "the average". Does he mean the > geometric mean or the harmonic mean, or something else? > Early Anton writes: What did you mean with "the average of 1 and 2"? > > Andrew gives an answer that clarifies nothing. > > Early Anton turns into Later Anton an learns that Andrew is apparently > not interested in a productive discussion, so Anton does not reply. > > Andrew had the last word. He has "won"! > > > Later on it's shorter: > > Andrew: It's the average of 1 and 2. > > Later Anton (with more Andrew experience) thinks: Hold on, there is > something imprecise here. Andrew is probably playing his tricks > again. No point in replying to that. What can I say about this bizarre misrepresentation? Of course I sometimes make mistakes, and I sometimes change my mind, and I somtimes write confusingly, but I'm not trying to play any tricks. The really strange thing from my point of view is that you repeatedly insist on paraphrasing what I say, removing all nuance and turning an apparently (apparently to me, anyway) justifiable statement into either nonsense or a truism, and then attacking the paraphrase. I then have to point out that I didn't mean exactly that. It's such a tremendous waste of time when you could just quote instead. >>Did I ever actually say what I want C to be, rather than what C is? >>I suppose that I might have done, but it's more likely IIRC that I >>was talking about what C *is* rather than what I want. I don't >>think I've thought very much about what I want it to be. > > The compilers and the programs define what C is, I disagree. > so if you are a compiler maintainer, you should be thinking about > what it should be. I think you're confusing the roles of language designer and compiler maintainer. > And I think that should be more about what the programmers want than > what you want. I agree. >>However, I think that you're right about C compiler maintainers: I >>can't remember any suggesting that C should be a portable assembly >>language and wanting to turn it back into one, as C was in 1977. > > 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. > We selected GNU C for Gforth in 1992 because it was a portable > assembly language then, and Linus Torvalds selected GNU C for Linux > in 1991 because of that. I am pretty sure that that's also what > Richard Stallman intended. > > The attitude change came later (maybe with egcs, maybe around > gcc-3.x), and the effects of that change are now trickling piecemeal > into the compiler, and causing one problem after another. > > If you had announced at some point that GNU C will no longer be a > portable assembly language, and that you will "optimize" code that has > some overflow somewhere into an infinite loop, we would have started > thinking about getting rid of C much earlier, and maybe other > projects, too. Or we might see a C compiler project that is intended > to provide C as a portable assembly language. That's not a bad idea at all. It would be useful for some niche application areas, but I suspect that most users given the choice would choose aggressive optimizing compilers. There's no way to know without trying. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-04-09 21:08 +0200 |
| Message-ID | <li45r3$t04$1@online.de> |
| In reply to | #29495 |
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/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-04-09 15:17 -0500 |
| Message-ID | <64idnem648RzN9jOnZ2dnUVZ8iWdnZ2d@supernews.com> |
| In reply to | #29496 |
Bernd Paysan <bernd.paysan@gmx.de> wrote: > I'd say that on typical workstation processors, which use two's > complement on integers, and don't trap on overflow, -fwrapv would be > the "program execution in a documented manner characteristic of the > environment". Whether you produce an unpredictable result or choose > to document what you do and produce a predictable result, is up to > you as compiler maintainer. Thus it's a quality of implementation > issue. It is, and there is more than one way to measure quality: some people prefer to write well-defined code rather than depend on any nonportable assumptions, and allow the compiler to optimize as much as possible. It's an area in which GCC really shines: in this case the user gets to choose (with -fwrapv) which they prefer. > 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. There's more than one axis of quality: some people prefer to have their well-defined code execute as fast as possible, and have a reasonable expectation that it will be portable to other compilers. > 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. I don't understand why you say this. My immediate reaction when I find that my code is undefined is to blame myself rather than the compiler writers, and this is true regardless of the compiler and the programming language. But I'm sorry you feel that way. There is a GCC project in progress that's designed to detect many areas of undefined behaviour, and it's in 4.9. Mind you, AIUI people will still have to fix their code rather than depend on a particular compiler: the idea is to warn people when UB occurs. I hope this will help you. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-04-10 00:17 +0200 |
| Message-ID | <li4gul$k8t$1@online.de> |
| In reply to | #29497 |
Andrew Haley wrote: > Bernd Paysan <bernd.paysan@gmx.de> wrote: > >> I'd say that on typical workstation processors, which use two's >> complement on integers, and don't trap on overflow, -fwrapv would be >> the "program execution in a documented manner characteristic of the >> environment". Whether you produce an unpredictable result or choose >> to document what you do and produce a predictable result, is up to >> you as compiler maintainer. Thus it's a quality of implementation >> issue. > > It is, and there is more than one way to measure quality: some people > prefer to write well-defined code rather than depend on any > nonportable assumptions, and allow the compiler to optimize as much as > possible. It's an area in which GCC really shines: in this case the > user gets to choose (with -fwrapv) which they prefer. Come on, every year we add another workaround against GCC pessimizations that had been added in the newest GCC versions (and when they go away, the result is still worse than before). Code that was fine and fast before. This is a straw man: If GCC really would generate faster code, your argument would have some substance, but in fact, it gets slower and slower, and more difficult to get GCC to compile optimal code. Get real: GCC is not shining. >> 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. > > There's more than one axis of quality: some people prefer to have > their well-defined code execute as fast as possible, and have a > reasonable expectation that it will be portable to other compilers. I still don't get it: If you have well-defined code in your application, there *is no* undefined code. It doesn't matter how bad GCC compiles undefined code, because a well-defined program will not contain any. It will not overflow integers. It will not ask for silly undefined things like "if(n>n+1)". >> 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. > > I don't understand why you say this. My immediate reaction when I > find that my code is undefined is to blame myself rather than the > compiler writers, and this is true regardless of the compiler and the > programming language. I understand why you don't understand what I say. It is because you don't listen (we have that again and again - you simply don't listen and then you say you don't understand. Please listen!). Let's get back to two's complement numbers: A program using two's complement signed numbers and relies on -fwrapv behavior is "undefined" in the terms of the C standard. It is certainly *not* undefined in terms of the environment (the machine) it runs on, when that machine is actually two's complement and not trapping on overflows. I don't see any problem in writing programs with environmental dependencies, especially with a dependency that only ignores the 3 remaining non-two's complement machines that are still functional in the supercomputer museum - but which don't have a C90 compiler or a GCC backend, anyways. > But I'm sorry you feel that way. There is a GCC project in progress > that's designed to detect many areas of undefined behaviour, and it's > in 4.9. Mind you, AIUI people will still have to fix their code > rather than depend on a particular compiler: the idea is to warn > people when UB occurs. I hope this will help you. I certainly prefer warnings to silent miscompilation (the if(n>n+1) is silent, because GCC no longer can warn about dead code removal, a really silly omission, because dead code removal is a class-1 thing you absolutely must warn about! Dead code is a bug, and you must have a "maybe_unused" pragma for dead code which is intentionally there). But you still don't get it: A compiler which forces people to rewrite code every year is a load of crap, no excuses - we don't do that sort of stuff here. And a language standard which undefines behavior for the sake of some really exotic hardware is not much better: If the hardware is exotic, make this an environmental dependency/restriction, not an undefined behavior. According to the C standard, even something like (-1 >> 31) & 1 is undefined. Can we agree that it is silly to write code which must be portable across three different integer representation formats? Nobody does that, and nobody needs that, because there is only one integer representation that matters: two's complement. If I remove all the undefined stuff in the C standard that comes from different integer representations, it's a lot less; the most important remaining undefined thing is null pointer dereferencing. And that's also not undefined on real hardware: It simply accesses addresses 0 and following (when there's an offset), because the null pointer is the address 0 (that's even defined!). In any case: The reason why we use GCC to compile Gforth is because we need a portable assembler. The same is true for a lot of other FOSS projects. If it's not giving us that feature, it is the wrong compiler to use, and we either have to search for something better (apparently the LLVM people aren't doing it, eithr), or we have to do it ourselves. The thing is: If you stop treating this "undefined" weasel words in the standard as something which is "magically undefined", but as a consequence of environmental dependencies (i.e. for reasons which are easy to understand, and don't actually mean that the code is bad quality), a lot of these things suddenly have logical definitions given the targets you actually compile for. It's not undefined for GCC what happens when you do (-1 >> 31) & 1. If you add these warnings about UB, please add a switch to define an environmental dependency, and not warn about behavior which is well-defined in this environment. I'm certainly *not* going to make my code work on one's complement and signed magnitude. -- 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-09 22:42 -0700 |
| Message-ID | <ad05b58a-84ad-4544-8fc3-b62b299f67e3@googlegroups.com> |
| In reply to | #29498 |
On Wednesday, April 9, 2014 3:17:57 PM UTC-7, Bernd Paysan wrote:
> Andrew Haley wrote:
>
> > Bernd Paysan <bernd.paysan@gmx.de> wrote:
>
> >> I'd say that on typical workstation processors, which use two's
> >> complement on integers, and don't trap on overflow, -fwrapv would be
> >> the "program execution in a documented manner characteristic of the
> >> environment". Whether you produce an unpredictable result or choose
> >> to document what you do and produce a predictable result, is up to
> >> you as compiler maintainer. Thus it's a quality of implementation
> >> issue.
>
> > It is, and there is more than one way to measure quality: some people
> > prefer to write well-defined code rather than depend on any
> > nonportable assumptions, and allow the compiler to optimize as much as
> > possible. It's an area in which GCC really shines: in this case the
> > user gets to choose (with -fwrapv) which they prefer.
>
> Come on, every year we add another workaround against GCC pessimizations
> that had been added in the newest GCC versions (and when they go away, the
> result is still worse than before). Code that was fine and fast before.
> This is a straw man: If GCC really would generate faster code, your argument
> would have some substance, but in fact, it gets slower and slower, and more
> difficult to get GCC to compile optimal code.
>
> Get real: GCC is not shining.
>
> >> 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.
>
> > There's more than one axis of quality: some people prefer to have
> > their well-defined code execute as fast as possible, and have a
> > reasonable expectation that it will be portable to other compilers.
>
> I still don't get it: If you have well-defined code in your application,
> there *is no* undefined code. It doesn't matter how bad GCC compiles
> undefined code, because a well-defined program will not contain any. It
> will not overflow integers. It will not ask for silly undefined things like
> "if(n>n+1)".
> >> 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.
>
> > I don't understand why you say this. My immediate reaction when I
> > find that my code is undefined is to blame myself rather than the
> > compiler writers, and this is true regardless of the compiler and the
> > programming language.
>
> I understand why you don't understand what I say. It is because you don't
> listen (we have that again and again - you simply don't listen and then you
> say you don't understand. Please listen!). Let's get back to two's
> complement numbers: A program using two's complement signed numbers and
> relies on -fwrapv behavior is "undefined" in the terms of the C standard.
> It is certainly *not* undefined in terms of the environment (the machine) it
> runs on, when that machine is actually two's complement and not trapping on
> overflows. I don't see any problem in writing programs with environmental
> dependencies, especially with a dependency that only ignores the 3 remaining
> non-two's complement machines that are still functional in the supercomputer
> museum - but which don't have a C90 compiler or a GCC backend, anyways.
>
> > But I'm sorry you feel that way. There is a GCC project in progress
> > that's designed to detect many areas of undefined behaviour, and it's
> > in 4.9. Mind you, AIUI people will still have to fix their code
> > rather than depend on a particular compiler: the idea is to warn
> > people when UB occurs. I hope this will help you.
> I certainly prefer warnings to silent miscompilation (the if(n>n+1) is
> silent, because GCC no longer can warn about dead code removal, a really
> silly omission, because dead code removal is a class-1 thing you absolutely
> must warn about! Dead code is a bug, and you must have a "maybe_unused"
> pragma for dead code which is intentionally there). But you still don't get
> it: A compiler which forces people to rewrite code every year is a load of
> crap, no excuses - we don't do that sort of stuff here. And a language
> standard which undefines behavior for the sake of some really exotic
> hardware is not much better: If the hardware is exotic, make this an
> environmental dependency/restriction, not an undefined behavior.
>
> According to the C standard, even something like
>
> (-1 >> 31) & 1
>
> is undefined. Can we agree that it is silly to write code which must be
> portable across three different integer representation formats? Nobody does
> that, and nobody needs that, because there is only one integer
> representation that matters: two's complement. If I remove all the
> undefined stuff in the C standard that comes from different integer
> representations, it's a lot less; the most important remaining undefined
> thing is null pointer dereferencing. And that's also not undefined on real
> hardware: It simply accesses addresses 0 and following (when there's an
> offset), because the null pointer is the address 0 (that's even defined!).
>
> In any case: The reason why we use GCC to compile Gforth is because we need
> a portable assembler. The same is true for a lot of other FOSS projects.
> If it's not giving us that feature, it is the wrong compiler to use, and we
> either have to search for something better (apparently the LLVM people
> aren't doing it, eithr), or we have to do it ourselves.
>
> The thing is: If you stop treating this "undefined" weasel words in the
> standard as something which is "magically undefined", but as a consequence
> of environmental dependencies (i.e. for reasons which are easy to
> understand, and don't actually mean that the code is bad quality), a lot of
> these things suddenly have logical definitions given the targets you
> actually compile for. It's not undefined for GCC what happens when you do
> (-1 >> 31) & 1.
>
> If you add these warnings about UB, please add a switch to define an
> environmental dependency, and not warn about behavior which is well-defined
> in this environment. I'm certainly *not* going to make my code work on
> one's complement and signed magnitude.
The if(n>n+1) issue in C has really been beaten to death (412 posts!) in this thread:
https://groups.google.com/forum/#!topic/comp.lang.forth/sXcSd_5F6bs%5B1-25-false%5D
Apparently, whenever anybody criticizes ANS-Forth (for example, by calling it an "epic fail"), you respond by launching into a long-winded criticism of C in regard to the dreaded if(n>n+1) issue. This is all just a lot of hand-waving distraction --- ANS-Forth is an epic fail by any criteria --- Forth really collapsed in 1994 when ANS-Forth came out.
I bought a copy of SwiftForth-v2 in the late 1990s. At that time SwiftForth had a bug in it: any use of (LOCAL) would crash the system. This was several years after the ANS-Forth standard came out. This means that, when Elizabeth Rather was chair-person of the ANS-Forth standards committee, and essentially making SwiftForth the standard, she and the entire Forth Inc. team were unable to implement (LOCAL) so that it didn't crash the system! Apparently nobody else on comp.lang.forth is bothered by the idea of Elizabeth Rather putting (LOCAL) in the standard when she is unable to implement it. How do you even get to version-2 with a bug in a fundamental aspect of the compiler that crashes the system? Apparently nobody at Forth Inc. ever uses local variables, so they just didn't notice year after year. Elizabeth Rather doesn't do any programming --- she is just making this stuff up! --- but this doesn't stop her from writing the ANS-Forth standard and telling everybody else how to program.
And how about the issue of LOCALS| having the names backwards? That is a real WTF?-inducing moment for the reader of the ANS-Forth document. I fixed this problem in the novice package with {. It was not difficult. To do this, it is necessary to reverse the order of the names that are pulled out of the input stream. I did this by pushing the strings onto the return stack and then popping them off again. Apparently none of the geniuses at Forth Inc. could figure this out though, which is why they just generated the locals in the order that the names came out of the input stream, which is backwards. It is gross problems like this that caused ANS-Forth to be an epic fail --- even the most novice programmer should be able to figure out how to reverse the order of data --- standardizing a failure such as this is just not impressive!
Well, enough of my "spittle flecked rant" --- ignore the epic fail of ANS-Forth and go back to discussing the if(n>n+1) issue in C --- when you get past 400 posts Elizabeth Rather will paste a tin-foil star on your foreheads as a reward for your loyalty!
[toc] | [prev] | [next] | [standalone]
| From | Stefan Mauerhofer <smauerhofer@androsoft.ch> |
|---|---|
| Date | 2014-04-10 00:06 -0700 |
| Message-ID | <aa3c8cdd-a142-4a7f-b8a7-8268b578a575@googlegroups.com> |
| In reply to | #29501 |
Am Donnerstag, 10. April 2014 07:42:09 UTC+2 schrieb hughag...@yahoo.com:
> And how about the issue of LOCALS| having the names backwards? That is a real WTF?-inducing moment for the reader of the ANS-Forth document. I fixed this problem in the novice package with {. It was not difficult. To do this, it is necessary to reverse the order of the names that are pulled out of the input stream. I did this by pushing the strings onto the return stack and then popping them off again. Apparently none of the geniuses at Forth Inc. could figure this out though, which is why they just generated the locals in the order that the names came out of the input stream, which is backwards. It is gross problems like this that caused ANS-Forth to be an epic fail --- even the most novice programmer should be able to figure out how to reverse the order of data --- standardizing a failure such as this is just not impressive!
>
It is not even necessary to reverse the order of names. In my implementation of "{" each variable is enumerated in the order of appearance, so "{ a b c }" gives a=0, b=1 and c=2. All you have to know is the total number of locals (#l). If you access a local variable then you can simply subtract the local number from the total numbers to get the index into the local stack, e.g. b position is calculated as #l(3) - b(1) = 2, so b is the second local.
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2014-04-10 16:00 +0100 |
| Message-ID | <li6blf$hru$1@dont-email.me> |
| In reply to | #29501 |
on 10/04/2014 06:42:11, the spittle flecked ranter wrote: > Apparently nobody else on > comp.lang.forth is bothered by the idea of Elizabeth Rather putting > (LOCAL) in the standard when she is unable to implement it. Is this general lack of interest in what you think about Elizabeth Rather's abilities a recent Damascene moment for you? Or have there been years of fermentation that led to this insightful brain fart? Honestly Hugh, you're like a plastic bag caught high in a tree; no-one knows how you got up there, and no-one can be bothered to get you down.
[toc] | [prev] | [next] | [standalone]
Page 1 of 22 [1] 2 3 … 22 Next page →
Back to top | Article view | comp.lang.forth
csiph-web