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 9 of 22 — ← Prev page 1 … 7 8 [9] 10 11 … 22 Next page →
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-04-26 05:06 -0500 |
| Message-ID | <GIqdnRdJS-OsGMbOnZ2dnUVZ_qadnZ2d@supernews.com> |
| In reply to | #29848 |
Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> wrote: > On Sun, 13 Apr 2014 15:04:47 -0700 (PDT), hughaguilar96@yahoo.com > wrote: > >>On Sunday, April 13, 2014 10:42:54 AM UTC-7, Assad Ebrahim wrote: >>> (B2) We're actually not all that interested in C anyway --- what we >>> would really like is to be able to take *any* language, transform it >>> to a machine independent intermediate language, and then write out >>> 'optimised' code to any given target machine. So what we're after is >>> a universal middle-language, with reasonably sound translators from C, >>> Fortran, C++, Objective-C, even Java, maybe even Python, into it, and >>> then reasonably sound translators from this middle language into any >>> of a vast number of machine languages. >> >>This is what C-- was designed to do. I'm on the mailing list, which >>is dead now. The designers are not supporting C-- anymore because >>they lost their funding --- you may be interested in picking up the >>baton. >> >>In regard to Forth-like languages, there is Cat --- this was also >>designed more to be an intermediate language such as you are >>describing, rather than something that people would write manually. > > Actually, I wrote (B1) and (B2) as simple statements of what I see as > two diametrically opposed points of view. > > B1 expresses a position that is closer to Bernd and Anton's point of > view. > > B2 is closer to Andrew's and the current GCC's point of view. Actually, that's not really my position. I am arguing for a literalist interpretation of language semantics. That is to say, believe that the specification means what it says: when it says something is undefined, it really is undefined. And if you invoke undefined behaviour and something bad happens, it really is your fault. I have no objection to tightening up areas of undefined behaviour, and in many cases it would improve programming languages to do so, even if it meant fewer optimization opportunities. From what I can see this view is becoming more widespread. > My point of view is, incidentally, closer to B1 ---- I would rather > have C return to its former heritage of a portable assembler, with a > relatively stable C compiler that does some non-hazardous code > optimisations, but views its mission as portable assembly, not fancy > universal language compiler. I don't have any objection to that, but it requires some work on the language's specification. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> |
|---|---|
| Date | 2014-04-26 11:16 +0100 |
| Message-ID | <gh1nl9leejr0pp6m3mstt60l0r27imjmi9@4ax.com> |
| In reply to | #29854 |
On Sat, 26 Apr 2014 05:06:41 -0500, Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: >Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> wrote: >> On Sun, 13 Apr 2014 15:04:47 -0700 (PDT), hughaguilar96@yahoo.com >> wrote: >> >>>On Sunday, April 13, 2014 10:42:54 AM UTC-7, Assad Ebrahim wrote: >>>> (B2) We're actually not all that interested in C anyway --- what we >>>> would really like is to be able to take *any* language, transform it >>>> to a machine independent intermediate language, and then write out >>>> 'optimised' code to any given target machine. So what we're after is >>>> a universal middle-language, with reasonably sound translators from C, >>>> Fortran, C++, Objective-C, even Java, maybe even Python, into it, and >>>> then reasonably sound translators from this middle language into any >>>> of a vast number of machine languages. >>> >> >> B2 is closer to Andrew's and the current GCC's point of view. > >Actually, that's not really my position. I am arguing for a >literalist interpretation of language semantics. That is to say, >believe that the specification means what it says: when it says >something is undefined, it really is undefined. And if you invoke >undefined behaviour and something bad happens, it really is your >fault. Fair enough. But in life, law, and technical specifications, isn't it the case the *nothing* can every be completely specified to cover every possible case now and also every possible case in the future. Areas will always be discovered that are undefined in the latest spec. I think the issue is what the fallback position of a compiler writer is in these cases. IMO, this should be guided be the *spirit* or *intent* of the language. That's why reference to "C as a portable assembler" is so important -- it defines a *spirit* which should be used to guide what is done when an undefined case is found. What do you think? > >I have no objection to tightening up areas of undefined behaviour, and >in many cases it would improve programming languages to do so, even if >it meant fewer optimization opportunities. From what I can see this >view is becoming more widespread. > >> My point of view is, incidentally, closer to B1 ---- I would rather >> have C return to its former heritage of a portable assembler, with a >> relatively stable C compiler that does some non-hazardous code >> optimisations, but views its mission as portable assembly, not fancy >> universal language compiler. > >I don't have any objection to that, but it requires some work on the >language's specification. > >Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-04-26 03:43 -0700 |
| Message-ID | <7x4n1g9xr0.fsf@ruckus.brouhaha.com> |
| In reply to | #29856 |
Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> writes: >>believe that the specification means what it says: when it says >>something is undefined, it really is undefined... > Fair enough. But in life, law, and technical specifications, isn't it > the case the *nothing* can every be completely specified to cover > every possible case now and also every possible case in the future. > Areas will always be discovered that are undefined in the latest spec. 1) I don't think most of the disagreement over undefined behavior has been about weird combinations that the specification overlooked. They've been about situations where section XYZ of the specification explicitly says "the result of doing X is undefined". And "undefined" in turn is explicitly different from "implementation defined". The standard does in fact say some other things are implementation defined, which means the compiler writer gets to choose the behaviour (from some set of sensible alternatives) and is supposed to implement it in some consistent way. "Undefined" means "this program state has no meaning and the user program should never enter it and expect any sane outcome, don't expect consistency: here be dragons." 2) Language specifications that try to cover every possible case are, in fact, reasonably successful at doing so. Examples: Algol-60, Scheme, Java, Ada, ML. The C specification leaves various constructs undefined on purpose, not by incompleteness or informality, but in order to present more optimization opportunities to the compiler writer. That is a philosophical choice that the C designers made and that C users presumptively embrace when they choose to use C. Evidence is mounting that it's a BAD philosophical choice, but the solution is fix the specification or choose another language. The Forth specification seems to be in a related situation, leaving a lot unspecified though maybe not explicitly undefined like C does. The result is there are grey areas where it's not clear what to do.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-04-26 14:24 +0000 |
| Message-ID | <2014Apr26.162421@mips.complang.tuwien.ac.at> |
| In reply to | #29857 |
Paul Rubin <no.email@nospam.invalid> writes:
>2) Language specifications that try to cover every possible case are, in
>fact, reasonably successful at doing so. Examples: Algol-60, Scheme,
Matthias Felleisen writes
<http://blog.regehr.org/archives/213#comment-703>:
|What's really sad is that some so-called high-level languages like
|Scheme intentionally include undefined behavior, too.
If one example is wrong, what about the others?
>Java, Ada, ML. The C specification leaves various constructs undefined
>on purpose, not by incompleteness or informality, but in order to
>present more optimization opportunities to the compiler writer.
That's what Andrew Haley is claiming, but I find that claim very
doubtful, especially because it is ahistorical; at the time of C89,
GCC 1.x was a leader in the performance of the generated code, and it
did not use "undefined behaviour" for "optimization" opportunities.
So who would have pushed for that in the C89 committee, and how would
they have convinced all the others?
I also doubt it when looking at the way we work in Forth
standardization. We do not define various things, and explicitly
undefine some ("ambiguous condition"). Especially in explicit
undefinition, the reason has never been "optimization opportunities".
Reasons were:
*) Several implementation variants exist, and we could not agree on
one (or did not even try).
*) Several implementation variants are imaginable, but the proposer
and/or the committee did not see a good reason to nail it down.
*) Differences in environment/platform. E.g., the Xchars proposal
does not define that Forth uses UTF-8, because there are other
encodings in use (notably 8-bit, but also others).
>That is
>a philosophical choice that the C designers made and that C users
>presumptively embrace when they choose to use C.
We certainly did not embrace it when we chose to use C; in fact we were
unaware of that supposed philisophical choice, and the issue did not
come up until over 10 years later.
I also doubt that the C designer made that choice. But since he is
dead, he cannot deny it.
>The Forth specification seems
>to be in a related situation, leaving a lot unspecified though maybe not
>explicitly undefined like C does. The result is there are grey areas
>where it's not clear what to do.
The Forth standard would certainly benefit from tightening, but
fortunately the mental disease that befell the C compiler writers has
not spread to Forth compiler writers yet.
- 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 | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-04-26 23:58 -0400 |
| Message-ID | <op.xeyiocof6zenlw@localhost> |
| In reply to | #29870 |
On Sat, 26 Apr 2014 10:24:21 -0400, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > [...] GCC 1.x was a leader in the performance of the generated code, > [...] So, you're actually claiming that GCC - at some point in time - actually outperformed Watcom, or now OpenWatcom, in terms of generated code? You're aware that one religion asks people to believe in a female, invisible, pink unicorn too? Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-04-27 12:46 +0000 |
| Message-ID | <2014Apr27.144619@mips.complang.tuwien.ac.at> |
| In reply to | #29896 |
"Rod Pemberton" <dont_use_email@xnothavet.cqm> writes:
>On Sat, 26 Apr 2014 10:24:21 -0400, Anton Ertl
><anton@mips.complang.tuwien.ac.at> wrote:
>
>> [...] GCC 1.x was a leader in the performance of the generated code,
>> [...]
>
>So, you're actually claiming that GCC - at some point in time - actually
>outperformed Watcom, or now OpenWatcom, in terms of generated code?
Sure. E.g., Watcom did not produce code for HP9000/300 (68k-based)
machines. The only game in town was HP's compiler (which was probably
derived from PCC), and GCC (maybe also Green Hills). So GCC
definitely outperformed Watcom on these machines. And when it was
released, the code it produced was significantly faster than that of
HP's compiler; the HP people then worked on it for a year and managed
to get close to the performance of GCC.
- 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 | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-04-28 00:41 -0400 |
| Message-ID | <op.xe0fb0pp6zenlw@localhost> |
| In reply to | #29915 |
On Sun, 27 Apr 2014 08:46:19 -0400, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > "Rod Pemberton" <dont_use_email@xnothavet.cqm> writes: >> On Sat, 26 Apr 2014 10:24:21 -0400, Anton Ertl >> <anton@mips.complang.tuwien.ac.at> wrote: >>> [...] GCC 1.x was a leader in the performance of the generated code, >>> [...] >> >> So, you're actually claiming that GCC - at some point in time - actually >> outperformed Watcom, or now OpenWatcom, in terms of generated code? > > Sure. E.g., Watcom did not produce code for HP9000/300 (68k-based) > machines. The only game in town was HP's compiler (which was probably > derived from PCC), and GCC (maybe also Green Hills). So GCC > definitely outperformed Watcom on these machines. And when it was > released, the code it produced was significantly faster than that of > HP's compiler; the HP people then worked on it for a year and managed > to get close to the performance of GCC. > Of course, that clarifies your earlier statement which made no constraints as to which platforms GCC was a performance leader. Obviously, if we take x86 into account, GCC was *never* a performance leader. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-04-28 21:54 -0700 |
| Message-ID | <ca8aed1b-e3e8-4800-a1c6-ce94c26aad93@googlegroups.com> |
| In reply to | #29870 |
On Saturday, April 26, 2014 7:24:21 AM UTC-7, Anton Ertl wrote:
> >Java, Ada, ML. The C specification leaves various constructs undefined
> >on purpose, not by incompleteness or informality, but in order to
> >present more optimization opportunities to the compiler writer.
> ...
> I also doubt it when looking at the way we work in Forth
> standardization. We do not define various things, and explicitly
> undefine some ("ambiguous condition"). Especially in explicit
> undefinition, the reason has never been "optimization opportunities".
> Reasons were:
>
> *) Several implementation variants exist, and we could not agree on
> one (or did not even try).
>
> *) Several implementation variants are imaginable, but the proposer
> and/or the committee did not see a good reason to nail it down.
>
> *) Differences in environment/platform. E.g., the Xchars proposal
> does not define that Forth uses UTF-8, because there are other
> encodings in use (notably 8-bit, but also others).
Now we are finally getting back to the OP's question of why Forth was an "epic fail" --- lack of ability of the ANS-Forth committee to agree on important issues, which resulted in a lot of wishy-washy "may or may not" nonsense in the ANS-Forth document. There were two causes for this:
1.) None of the committee members had the authority to over-ride Forth Inc.. They knew that there was an intelligent way to do something (for example: to make the control-stack distinct from the data-stack), but SwiftForth did this in an unintelligent manner (used the data-stack for control-flow data in order to make the compiler-writer's job slightly easier), so the result was to have the standard say that *either* the intelligent way or the SwiftForth way was standard. The result is that the application programmer has to choose the most restrictive way in order for his code to work on every ANS-Forth compiler, and so SwiftForth effectively becomes the standard. He has to assume that the control-flow stuff is on the data stack in his way, for example, so that his code will run under SwiftForth, even if he is using a Forth system that implements this in the intelligent way (with the control-stack being separate from the data-stack).
2.) The committee members were just too dumb to understand the issue being discussed, so they didn't make any decision at all --- they essentially said: "Well, um, whatever anybody does will be considered to be standard."
Because the title of this thread is "Epic Fail," section 3.2.3.2. begs to be quoted:
"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."
[toc] | [prev] | [next] | [standalone]
| From | Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> |
|---|---|
| Date | 2014-04-26 17:17 +0100 |
| Message-ID | <temnl9ten13pfrcs06n2q8v4ue68kacg82@4ax.com> |
| In reply to | #29857 |
On Sat, 26 Apr 2014 03:43:47 -0700, Paul Rubin <no.email@nospam.invalid> wrote: >2) Language specifications that try to cover every possible case are, in >fact, reasonably successful at doing so. Examples: Algol-60, Scheme, >Java, Ada, ML. The C specification leaves various constructs undefined >on purpose, not by incompleteness or informality, but in order to >present more optimization opportunities to the compiler writer. That is >a philosophical choice that the C designers made and that C users >presumptively embrace when they choose to use C. Evidence is mounting >that it's a BAD philosophical choice, but the solution is fix the >specification or choose another language. Perhaps that's why Dennis Ritchie and Rob Pike started the Go language --- displeasure with the state of affairs in what C is becoming. If so, then we have a new pun on the name: an oblique reference to the fact that the direction of the new C is likely to be a "No Go"... Assad
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-04-26 10:08 -0500 |
| Message-ID | <HLCdnRy0JvJuVsbOnZ2dnUVZ_o6dnZ2d@supernews.com> |
| In reply to | #29856 |
Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> wrote: > On Sat, 26 Apr 2014 05:06:41 -0500, Andrew Haley > <andrew29@littlepinkcloud.invalid> wrote: > >>Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> wrote: >>> On Sun, 13 Apr 2014 15:04:47 -0700 (PDT), hughaguilar96@yahoo.com >>> wrote: >>> >>>>On Sunday, April 13, 2014 10:42:54 AM UTC-7, Assad Ebrahim wrote: >>>>> (B2) We're actually not all that interested in C anyway --- what we >>>>> would really like is to be able to take *any* language, transform it >>>>> to a machine independent intermediate language, and then write out >>>>> 'optimised' code to any given target machine. So what we're after is >>>>> a universal middle-language, with reasonably sound translators from C, >>>>> Fortran, C++, Objective-C, even Java, maybe even Python, into it, and >>>>> then reasonably sound translators from this middle language into any >>>>> of a vast number of machine languages. >>>> >>> >>> B2 is closer to Andrew's and the current GCC's point of view. >> >>Actually, that's not really my position. I am arguing for a >>literalist interpretation of language semantics. That is to say, >>believe that the specification means what it says: when it says >>something is undefined, it really is undefined. And if you invoke >>undefined behaviour and something bad happens, it really is your >>fault. > > Fair enough. But in life, law, and technical specifications, isn't it > the case the *nothing* can every be completely specified to cover > every possible case now and also every possible case in the future. > Areas will always be discovered that are undefined in the latest spec. Exactly so: from time to time unexpected questions arise, and have to be answered by specification revisions. This can be done either by revising the language specification itself or adding clarifying local documentation to an implementation. > I think the issue is what the fallback position of a compiler writer > is in these cases. Not quite. It's what you do about cases that have deliberately been left undefined. > IMO, this should be guided be the *spirit* or *intent* of the > language. > > That's why reference to "C as a portable assembler" is so important -- > it defines a *spirit* which should be used to guide what is done when > an undefined case is found. > > What do you think? That such a thing is so hopelessly vague as to be impossible to implement; it would make a compiler writer's job impossible and it would make it very difficult to move code between implementations because their implementors disagreed about the spirit of the language. Leave all this talk about intent and spirit to lawyers and witchdoctors: we need proper specifications. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-04-26 13:44 +0200 |
| Message-ID | <ljg67f$8sh$1@online.de> |
| In reply to | #29854 |
Andrew Haley wrote: > Actually, that's not really my position. I am arguing for a > literalist interpretation of language semantics. That is to say, > believe that the specification means what it says: when it says > something is undefined, it really is undefined. And if you invoke > undefined behaviour and something bad happens, it really is your > fault. However, that's not the way standards are created. There's almost always a reason why something is defined "undefined", and it's usually because there are different systems where things differ. The C standard is worded in the direction as you argue, the Forth standard e.g. isn't. We have this notation of an environmental dependency (or an environmental restriction, when you can't implement optional parts of the standard), which make clear that some behavior is well-defined in a particular environment. > I have no objection to tightening up areas of undefined behaviour, and > in many cases it would improve programming languages to do so, even if > it meant fewer optimization opportunities. From what I can see this > view is becoming more widespread. Hopefully. But there were voices a long time ago that had that view, and one of them was Richard Stallman. The section is rather small, and uses GCC as example: https://www.gnu.org/prep/standards/html_node/Non_002dGNU-Standards.html#Non_002dGNU-Standards The key sentence for you and your fellow GCC maintainers is: "In developing a GNU program, you should implement an outside standard’s specifications when that makes the GNU system better overall in an objective sense." "outside standard's specification" obviously included reasonable extensions to the standard. And the --pedantic switch is there "not because there is any reason to actually use it." There's also a hint what to do with behavior you had in the past, but wasn't actually blessed standard C behavior: "In particular, don’t reject a new feature, or remove an old one, merely because a standard says it is “forbidden” or “deprecated”." I think that short section clearly explains why Stallman's GCC was working for us, and why current GCC is causing problems. This sort of thinking is not new. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-04-26 09:11 -0400 |
| Message-ID | <op.xexdkpek6zenlw@localhost> |
| In reply to | #29854 |
On Sat, 26 Apr 2014 06:06:41 -0400, Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: > I am arguing for a literalist interpretation of language semantics. > That is to say, believe that the specification means what it says: > when it says something is undefined, it really is undefined. Oh, c'mon! You know full well that's *NOT* remotely how C works. Stop being inciteful and spreading B.S. or F.U.D. C has a historical model of implementation that started with C 1974 and K&R C. All C compilers support this set of undocumented and historical behaviors. Then, C was standardized with ANSI C. That captured some of the required behaviors, but not enough. Some standard behavior couldn't be standardized due to different computing architectures. C was then tweaked slightly to comply with the major changes of the ANSI C standard, but the stuff that was already working for the existing C compilers wasn't changed to match the specifications. C was then tweaked again for the important fixes in the various TCs. A handful of C compilers were tweaked again when ISO C99 came about, but not all. If you don't implement those historical and undocumented behaviors of K&R C and C 1974, C code will not work. If you don't implement the requirements of the C Rationale, C won't work correctly. If you rely exclusively on the current C specifications, you're going to implement a botched up version of C. You need to understand the C Rationale and the historic behaviors of C. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-04-26 10:12 -0500 |
| Message-ID | <HLCdnR-0JvJ4UcbOnZ2dnUVZ_o6dnZ2d@supernews.com> |
| In reply to | #29862 |
Rod Pemberton <dont_use_email@xnothavet.cqm> wrote: > On Sat, 26 Apr 2014 06:06:41 -0400, Andrew Haley > <andrew29@littlepinkcloud.invalid> wrote: > >> I am arguing for a literalist interpretation of language semantics. >> That is to say, believe that the specification means what it says: >> when it says something is undefined, it really is undefined. > > Oh, c'mon! You know full well that's *NOT* remotely how C works. > Stop being inciteful and spreading B.S. or F.U.D. I know that is exactly how C works. So there. > C has a historical model of implementation that started with C 1974 > and K&R C. All C compilers support this set of undocumented and > historical behaviors. Then, C was standardized with ANSI C. That > captured some of the required behaviors, but not enough. Some > standard behavior couldn't be standardized due to different > computing architectures. C was then tweaked slightly to comply with > the major changes of the ANSI C standard, but the stuff that was > already working for the existing C compilers wasn't changed to match > the specifications. C was then tweaked again for the important > fixes in the various TCs. A handful of C compilers were tweaked > again when ISO C99 came about, but not all. If you don't implement > those historical and undocumented behaviors of K&R C and C 1974, C > code will not work. If you don't implement the requirements of the > C Rationale, C won't work correctly. If you rely exclusively on the > current C specifications, you're going to implement a botched up > version of C. You need to understand the C Rationale and the > historic behaviors of C. Where have you been for the last decade? Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> |
|---|---|
| Date | 2014-04-26 17:00 +0100 |
| Message-ID | <4jlnl91n4lntq33u344dghllanpn548iv4@4ax.com> |
| In reply to | #29868 |
On Sat, 26 Apr 2014 10:12:37 -0500, Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: >Rod Pemberton <dont_use_email@xnothavet.cqm> wrote: > >> C has a historical model of implementation that started with C 1974 >> and K&R C. All C compilers support this set of undocumented and >> historical behaviors. Then, C was standardized with ANSI C. That >> captured some of the required behaviors, but not enough. Some >> standard behavior couldn't be standardized due to different >> computing architectures. C was then tweaked slightly to comply with >> the major changes of the ANSI C standard, but the stuff that was >> already working for the existing C compilers wasn't changed to match >> the specifications. C was then tweaked again for the important >> fixes in the various TCs. A handful of C compilers were tweaked >> again when ISO C99 came about, but not all. If you don't implement >> those historical and undocumented behaviors of K&R C and C 1974, C >> code will not work. If you don't implement the requirements of the >> C Rationale, C won't work correctly. If you rely exclusively on the >> current C specifications, you're going to implement a botched up >> version of C. You need to understand the C Rationale and the >> historic behaviors of C. > >Where have you been for the last decade? > That's precisely the point that is being made --- it is the new C under the new committee that has changed its direction --- we've all been exactly where we were with the opinion that as C was designed by its creators to be a portable assembler and was living a vigorous and productive life as a portable assembler that it would be preserved as a portable assembler. These new so-called improvements have all happened roughly over the last decade. Assad
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-04-26 12:08 -0500 |
| Message-ID | <jsydnVFAf6hnesbOnZ2dnUVZ_tadnZ2d@supernews.com> |
| In reply to | #29873 |
Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> wrote: > On Sat, 26 Apr 2014 10:12:37 -0500, Andrew Haley > <andrew29@littlepinkcloud.invalid> wrote: > >>Rod Pemberton <dont_use_email@xnothavet.cqm> wrote: >> >>> C has a historical model of implementation that started with C 1974 >>> and K&R C. All C compilers support this set of undocumented and >>> historical behaviors. Then, C was standardized with ANSI C. That >>> captured some of the required behaviors, but not enough. Some >>> standard behavior couldn't be standardized due to different >>> computing architectures. C was then tweaked slightly to comply with >>> the major changes of the ANSI C standard, but the stuff that was >>> already working for the existing C compilers wasn't changed to match >>> the specifications. C was then tweaked again for the important >>> fixes in the various TCs. A handful of C compilers were tweaked >>> again when ISO C99 came about, but not all. If you don't implement >>> those historical and undocumented behaviors of K&R C and C 1974, C >>> code will not work. If you don't implement the requirements of the >>> C Rationale, C won't work correctly. If you rely exclusively on the >>> current C specifications, you're going to implement a botched up >>> version of C. You need to understand the C Rationale and the >>> historic behaviors of C. >> >>Where have you been for the last decade? > > That's precisely the point that is being made --- it is the new C > under the new committee that has changed its direction --- we've all > been exactly where we were with the opinion that as C was designed by > its creators to be a portable assembler and was living a vigorous and > productive life as a portable assembler that it would be preserved as > a portable assembler. Indeed so, and that is a perfectly reasonable position to take. > These new so-called improvements have all happened roughly over the > last decade. The last couple of decades, I think. But yes. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-04-26 23:41 -0400 |
| Message-ID | <op.xeyhusje6zenlw@localhost> |
| In reply to | #29868 |
On Sat, 26 Apr 2014 11:12:37 -0400, Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: > Rod Pemberton <dont_use_email@xnothavet.cqm> wrote: >> C has a historical model of implementation that started with C >> 1974 and K&R C. [...] > > Where have you been for the last decade? > Mostly? In comp.lang.forth ... Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-04-26 17:06 +0000 |
| Message-ID | <2014Apr26.190624@mips.complang.tuwien.ac.at> |
| In reply to | #29616 |
Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> writes:
>On Sun, 13 Apr 2014 16:10:30 GMT, anton@mips.complang.tuwien.ac.at
>(Anton Ertl) wrote:
>>
>>Anyway, these are not alternatives. The LLVM maintainers are under
>>the same evil spell as the gcc maintainers
>><http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html>.
>>The Intel compiler is proprietary.
>>
>
>Thanks for the interesting article reference.
>
>Is the below a fair representation of your and Bernd's point of view?
>
>(A1) we want some of the optimisations that optimising compilers
>produce
>
>(A2) but we don't want them to do so at the expense of taking too
>many liberties with the code
>
>(A3) we'd rather agree that if we want to improve code beyond what a
>non-libertine compiler could legitimately do, then we must take on
>that further improvement ourselves using profilers and targeted
>improvements ourselves.
Yes, although A1 and A2 are not very precise. More precisely, I want
the optimizations that the Stallman-maintained gcc-2.x did.
>And would this be a reasonable representation of a ' modern compiler
>maintainer's point of view?
...
>(B2) We're actually not all that interested in C anyway --- what we
>would really like is to be able to take *any* language, transform it
>to a machine independent intermediate language, and then write out
>'optimised' code to any given target machine. So what we're after is
>a universal middle-language, with reasonably sound translators from C,
>Fortran, C++, Objective-C, even Java, maybe even Python, into it, and
>then reasonably sound translators from this middle language into any
>of a vast number of machine languages.
I would not expect that to have much to do with it. The "undefined
behaviour" in standard C is specific to this standard (with maybe some
crossover with C++). I certainly would not use an IR full of
"undefined behaviour" as a common IR, but would deal with "undefined
behaviour" at a higher level, but then I would not do the things with
"undefined behavuour" that the GCC maintainers are doing.
However, there is evidence for your idea: 1) Andrew Haley wrote that
-fwrapv came from doing Java. 2) Some older discussions I read
mentioned C++ as justification for miscompiling C; I actually got the
idea that this whole attitude problem is coming from the C++ side.
- 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-26 12:45 -0500 |
| Message-ID | <LpSdnV-T4oEjbcbOnZ2dnUVZ_qednZ2d@supernews.com> |
| In reply to | #29878 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > > Yes, although A1 and A2 are not very precise. More precisely, I want > the optimizations that the Stallman-maintained gcc-2.x did. Do you have any justification for the opinion that Stallman was mainaining gcc 2.x? I was around from the mid-90s onwards, and I don't remember that. I think that Richard Kenner was the maintainer by then. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-04-26 17:52 +0000 |
| Message-ID | <2014Apr26.195209@mips.complang.tuwien.ac.at> |
| In reply to | #29881 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>
>> Yes, although A1 and A2 are not very precise. More precisely, I want
>> the optimizations that the Stallman-maintained gcc-2.x did.
>
>Do you have any justification for the opinion that Stallman was
>mainaining gcc 2.x?
Sure, I have an email from him for a bug report I wrote.
>I was around from the mid-90s onwards, and I
>don't remember that. I think that Richard Kenner was the maintainer
>by then.
Richard Kenner was the maintainer of 2.8.x, maybe also 2.7.x, but before
that it was Richard Stallman.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2013: http://www.euroforth.org/ef13/
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-04-26 21:52 +0200 |
| Message-ID | <ljh2p3$vbg$1@online.de> |
| In reply to | #29882 |
Anton Ertl wrote: > Richard Kenner was the maintainer of 2.8.x, maybe also 2.7.x, but before > that it was Richard Stallman. Kenner was maintainer for GCC 2.5 to GCC 2.8, and then, because the "everything has to go through the maintainer" bottleneck became a too obvious problem, the EGCS experiment started (stalling GCC for about 2 years during the transition). http://linuxfinances.info/info/c.html IMHO the shoes of RMS were simply too big for Kenner. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
Page 9 of 22 — ← Prev page 1 … 7 8 [9] 10 11 … 22 Next page →
Back to top | Article view | comp.lang.forth
csiph-web