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 12 of 22 — ← Prev page 1 … 10 11 [12] 13 14 … 22 Next page →
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-04-22 04:58 -0500 |
| Message-ID | <lPKdnXz2p_CyoMvOnZ2dnUVZ_smdnZ2d@supernews.com> |
| In reply to | #29747 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>>>But the question of whether you have to >>>>leave the Forth environment to change Forth really is important, IMO. >>>>I've done it both ways, and Forth-in-Forth is better if you want to >>>>make experimental changes. >>> >>> That's not at all clear to me. What kind of changes do you refer to, >>> and how is Forth-in-Forth better there? >> >>Any kind of change to the kernel: e.g change of threading, adding >>hooks to do profiling and tracing, etc, etc. Things that it should be >>possible to code in a few minutes and compile in a couple of seconds. > > 1) Change of threading: In Gforth that is in the engine, and it > requires changing C code to do it. That's relatively easy, and we > have done so a lot over the years Sure, once you know how to do it, and are familiar with the toolset, etc, etc. > If Gforth was implemented in the classical Forth-in-Forth way > (assembler in Forth, NEXT written in assembly language), this would > all have been much more work to write and to test, because we would > have to implement the new threading separately for each platform. > We probably would not have all the stuff mentioned above. Sure, but I'm not talking about ease of porting; I have no doubt that the approach you took made it easier to port. I'm talking about one user on one system wanting to make such a change, not the original author of a hightly-portable system. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-04-22 17:05 +0000 |
| Message-ID | <2014Apr22.190548@mips.complang.tuwien.ac.at> |
| In reply to | #29766 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> 1) Change of threading: In Gforth that is in the engine, and it
>> requires changing C code to do it. That's relatively easy, and we
>> have done so a lot over the years
>
>Sure, once you know how to do it, and are familiar with the toolset,
>etc, etc.
Sure, but the same is true for Forth-in-Forth.
>> If Gforth was implemented in the classical Forth-in-Forth way
>> (assembler in Forth, NEXT written in assembly language), this would
>> all have been much more work to write and to test, because we would
>> have to implement the new threading separately for each platform.
>> We probably would not have all the stuff mentioned above.
>
>Sure, but I'm not talking about ease of porting; I have no doubt that
>the approach you took made it easier to port. I'm talking about one
>user on one system wanting to make such a change, not the original
>author of a hightly-portable system.
The user may be interested in portability, too. If they are not, and
want to do this kind of thing, there are a number of Forth-in-Forth
systems that they could use.
Overall compared to our approach your approach would make such changes
harder for both us and for users interested in portability, and it
would not provide anything that other systems do not provide already.
Therefore it makes no sense to me that Gforth "should have been in the
first place" a Forth-in-Forth.
- 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 | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-04-20 17:12 +0000 |
| Message-ID | <53540000$0$24957$e4fe514c@dreader36.news.xs4all.nl> |
| In reply to | #29721 |
In article <s5GdnbdIpfqdeM_OnZ2dnUVZ_smdnZ2d@supernews.com>,
Andrew Haley <andrew29@littlepinkcloud.invalid> wrote:
>Albert van der Horst <albert@spenarnc.xs4all.nl> wrote:
>> In article <vs-dnSmUiZsvyMzOnZ2dnUVZ8uadnZ2d@supernews.com>,
>> Andrew Haley <andrew29@littlepinkcloud.invalid> wrote:
>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>>>A Forth system written in Forth.
>>>>
>>>> Why do you think that Gforth should have been that in the first place?
>>>
>>>It's my personal preference, I suppose. IME Forth written in Forth is
>>>easier to explore, easier to understand, and easier to change.
>>>Because of this Forth is a great tool for learning how to bootstrap
>>>systems. If you depend on non-Forth you lose all of these advantages.
>>
>> The alternative to Gforth is what I do in ciforth, define all low level
>> words in assembler by hand, define the threading mechanism in assembler,
>> define the looping mechanism in assembler.
>> By saying defined in Forth, you muddy the waters. I'd say defined in
>> assembler, this way like Gforth ciforth admits to using external tools
>> to get the executables right, either a c-compiler plus linker or an
>> assembler plus linker.
>
>Sure, that's OK until you get the Forth bootstrap going.
There you are. This illustrates why jonesforth is popular.
The idea that you make a Forth only to use it as a scaffolding is
a couple of DAN-grades (belts) away from the average starting
programmer in Forth or aspirate compiler-builder.
This is also the reason that if you want to modify ciforth there
are 4 different levels where you can jump in. The highest level
challenges an experienced meta-Forther, while the easiest level is
familiar to a moderately skilled embedded programmer.
Even so. You probably haven't studied jonesforth a bit, or you would
realize that the later versions have part in assembler, and the
remainder is in Forth. So it is not the diametrically opposed approach
you make it out to be.
>> If you really do everything in Forth, then you have to write an ELF
>> as well as a COFF toolkit in Forth, an awesome and unfruitful
>> undertaking, and it still restricted to linux and window.
>
>That's no big deal, really: you only need a skeleton subset of ELF.
>You can always write a simple bootstrap loader in a few lines of
>assembly if you really care. But the question of whether you have to
>leave the Forth environment to change Forth really is important, IMO.
>I've done it both ways, and Forth-in-Forth is better if you want to
>make experimental changes.
Been there. Simple changes to ELF headers, such as fully allowed by
the ELF documents will make ELF-tools balk on your executables.
So the simple question, dump my header such that I can see what I'm
doing, may fail. If you use strip (a gcc tool) on an executable
that is not generated by a gcc tool, you risk ending with an
empty file. Good luck getting a bug report accepted for that.
So there is much more to it, than just generating a valid header.
Understanding ELF itself is a bear. You only need one A4 worth of
information extracted from ELF, but it takes more time to extract that
than I needed to port ciforth to 64 bits using my generic tools and
fasm.
fasm takes care of ELF 64 for me by the incantation:
FORMAT ELF64
( O o _ o O )
Instead of criticizing jonesforth I've worked on a better alternative
called yourforth.
A couple of lines from yourforth:
; To build:
; wget http://flatassembler.net/fasm-1.70.03.tgz; tar xfz fasm-1.70.03.tgz; fasm/fasm yourforth.fas
; That is right. Not only did you brew coffee, you've been to Columbia, picked the beans,
; and roasted them as well! Next time you only need "fasm/fasm yourforth.fas".
; If you're new at Forth you may want to read the Chapter "gentle introduction"
; of yourforth.pdf.
That's right. It is one line to get the assembler package, install it
*and* build a yourforth executable. And an even simpler command -- that one just
might remember by heart -- to repeat the action, once installed.
Now that is the kind of effort people might be lured to expend to get
started with their own compiler. Learning ELF. Cheese! There is no need
for a yourforther to have a clue about ELF. There is sooooo much else
to learn, that has actually a relation to Forth.
>
>Andrew.
Groetjes Albert
(yourforth is in the Cloud. Just google for it.)
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-04-20 19:47 -0400 |
| Message-ID | <op.xem21ngt6zenlw@localhost> |
| In reply to | #29738 |
On Sun, 20 Apr 2014 13:12:32 -0400, Albert van der Horst <albert@spenarnc.xs4all.nl> wrote: > In article <s5GdnbdIpfqdeM_OnZ2dnUVZ_smdnZ2d@supernews.com>, > Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: >> Albert van der Horst <albert@spenarnc.xs4all.nl> wrote: >>> The alternative to Gforth is what I do in ciforth, define all low level >>> words in assembler by hand, define the threading mechanism in >>> assembler, >>> define the looping mechanism in assembler. By saying defined in Forth, >>> you muddy the waters. I'd say defined in assembler, this way like >>> Gforth >>> ciforth admits to using external tools to get the executables right, >>> either a c-compiler plus linker or an assembler plus linker. >> >> Sure, that's OK until you get the Forth bootstrap going. > > There you are. This illustrates why jonesforth is popular. > The idea that you make a Forth only to use it as a scaffolding is > a couple of DAN-grades (belts) away from the average starting > programmer in Forth or aspirate compiler-builder. > Exactly, in addition to the "primitives" (low-level) words, you need a handful of high-level Forth definitions, pre-compiled, to bootstrap Forth, such as FIND : ; as well as the inner and outer interpreters. A novice is nowhere near ready to implement the more difficult components. Of course, Andrew knows this, or he should, having done so ... The real advantage of a Forth like Jonesforth is that it's coded in assembly for a widely available x86 assembler, which means it can be compiled for a variety of different operating systems, or it can be fixed easily. The hard work of implementing the low-level stuff is finished. I.e., it's a throw-back to the fig-Forths in assembly of yesteryear. It's easy for a novice to get working. Assemble and go. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-04-22 05:03 -0500 |
| Message-ID | <WtGdnStmxf37o8vOnZ2dnUVZ_uadnZ2d@supernews.com> |
| In reply to | #29738 |
Albert van der Horst <albert@spenarnc.xs4all.nl> wrote: > > Even so. You probably haven't studied jonesforth a bit, or you would > realize that the later versions have part in assembler, and the > remainder is in Forth. So it is not the diametrically opposed approach > you make it out to be. I don't think I've said that it is a diametrically opposed approach. I have said that the kernel is written in assembler, and for that reason it is a PITA to work on. >>> If you really do everything in Forth, then you have to write an ELF >>> as well as a COFF toolkit in Forth, an awesome and unfruitful >>> undertaking, and it still restricted to linux and window. >> >>That's no big deal, really: you only need a skeleton subset of ELF. >>You can always write a simple bootstrap loader in a few lines of >>assembly if you really care. But the question of whether you have to >>leave the Forth environment to change Forth really is important, IMO. >>I've done it both ways, and Forth-in-Forth is better if you want to >>make experimental changes. > > Been there. Simple changes to ELF headers, such as fully allowed by > the ELF documents will make ELF-tools balk on your executables. So > the simple question, dump my header such that I can see what I'm > doing, may fail. If you use strip (a gcc tool) No it isn't. > on an executable that > is not generated by a gcc tool, you risk ending with an empty file. a. No GCC tool generates executables, and b. So don't do that, then. > Good luck getting a bug report accepted for that. I'd just fix the bug. > Now that is the kind of effort people might be lured to expend to get > started with their own compiler. Learning ELF. Cheese! What has any of this to do with people writing their own Forth? Are we supposed to be encouraging people to write yet more Forths? Why? Andrew.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-04-22 11:51 +0000 |
| Message-ID | <535657da$0$27157$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #29768 |
In article <WtGdnStmxf37o8vOnZ2dnUVZ_uadnZ2d@supernews.com>, Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: >Albert van der Horst <albert@spenarnc.xs4all.nl> wrote: >> >> Even so. You probably haven't studied jonesforth a bit, or you would >> realize that the later versions have part in assembler, and the >> remainder is in Forth. So it is not the diametrically opposed approach >> you make it out to be. > >I don't think I've said that it is a diametrically opposed approach. >I have said that the kernel is written in assembler, and for that >reason it is a PITA to work on. > >>>> If you really do everything in Forth, then you have to write an ELF >>>> as well as a COFF toolkit in Forth, an awesome and unfruitful >>>> undertaking, and it still restricted to linux and window. >>> >>>That's no big deal, really: you only need a skeleton subset of ELF. >>>You can always write a simple bootstrap loader in a few lines of >>>assembly if you really care. But the question of whether you have to >>>leave the Forth environment to change Forth really is important, IMO. >>>I've done it both ways, and Forth-in-Forth is better if you want to >>>make experimental changes. >> > >> Been there. Simple changes to ELF headers, such as fully allowed by >> the ELF documents will make ELF-tools balk on your executables. So >> the simple question, dump my header such that I can see what I'm >> doing, may fail. If you use strip (a gcc tool) > >No it isn't. > >> on an executable that >> is not generated by a gcc tool, you risk ending with an empty file. > >a. No GCC tool generates executables, and >b. So don't do that, then. > >> Good luck getting a bug report accepted for that. > >I'd just fix the bug. Really, fixing bugs in GNU tools? Mere mortals can't pull that off. (I could though.) Let's make it more concrete. I've this yourforth which is supposedly the simplest forth in assembler. One segment. It assembles in under a millisecond: " albert@cherry:~/PROJECT/yourforth$ time fasm yourforth.fas flat assembler version 1.70.03 (16384 kilobytes memory) 2 passes, 15197 bytes. real 0m0.008s user 0m0.000s sys 0m0.008s albert@cherry:~/PROJECT/yourforth$ file yourforth yourforth: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), \ statically linked, stripped " Are you with me? So far so good. (This Forth passes a regression test, and even Hayes suite, after loading a lot of extensions.) " albert@cherry:~/PROJECT/yourforth$ strip yourforth albert@cherry:~/PROJECT/yourforth$ ls -l yourforth -rwxr-xr-x 1 albert albert 176 Apr 22 13:14 yourforth albert@cherry:~/PROJECT/yourforth$ yourforth Segmentation fault " So the gnu tool `` strip '' fails a simple test on the simplest of Forths. It just has to conclude that there are no symbols and leave. Instead it trims it to an unbelievable 176 bytes. I'm not inspired to fix this bug. If the writers of the program cannot come up with the idea to test it on a program that is as simple as this, I'm pretty sure I'll end up with rewriting the tool myself. (All this on Debian stable 64-bit, same result on a stone age Suse.) > >> Now that is the kind of effort people might be lured to expend to get >> started with their own compiler. Learning ELF. Cheese! > >What has any of this to do with people writing their own Forth? Are >we supposed to be encouraging people to write yet more Forths? Why? Okay let's deter people from writing their own Forths by requiring ELF expertise. ;-) The curriculums surely should have assignments to write a simple compiler. Enough Eclipse already! > >Andrew. -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-04-22 08:28 -0500 |
| Message-ID | <3Zmdndi2EdYO88vOnZ2dnUVZ_sSdnZ2d@supernews.com> |
| In reply to | #29771 |
In comp.lang.forth Albert van der Horst <albert@spenarnc.xs4all.nl> wrote: > In article <WtGdnStmxf37o8vOnZ2dnUVZ_uadnZ2d@supernews.com>, > > I've this yourforth which is supposedly the simplest forth in > assembler. One segment. It assembles in under a millisecond: > > " > albert@cherry:~/PROJECT/yourforth$ time fasm yourforth.fas > flat assembler version 1.70.03 (16384 kilobytes memory) > 2 passes, 15197 bytes. > > real 0m0.008s > user 0m0.000s > sys 0m0.008s Looks like 8 milliseconds to me, but OK. :-) > albert@cherry:~/PROJECT/yourforth$ file yourforth > yourforth: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), \ > statically linked, stripped > " > > Are you with me? So far so good. (This Forth passes a regression test, > and even Hayes suite, after loading a lot of extensions.) > " > albert@cherry:~/PROJECT/yourforth$ strip yourforth > albert@cherry:~/PROJECT/yourforth$ ls -l yourforth > -rwxr-xr-x 1 albert albert 176 Apr 22 13:14 yourforth > albert@cherry:~/PROJECT/yourforth$ yourforth > Segmentation fault > " > > So the gnu tool `` strip '' fails a simple test on the simplest of Forths. > It just has to conclude that there are no symbols and leave. Instead it > trims it to an unbelievable 176 bytes. > > I'm not inspired to fix this bug. If the writers of the program cannot > come up with the idea to test it on a program that is as simple as > this, I'm pretty sure I'll end up with rewriting the tool myself. There are two possibilities: yourforth isn't a real ELF file, or strip has a bug, or both. But why do you want to strip it? > (All this on Debian stable 64-bit, same result on a stone age Suse.) > >>> Now that is the kind of effort people might be lured to expend to get >>> started with their own compiler. Learning ELF. Cheese! >> >>What has any of this to do with people writing their own Forth? Are >>we supposed to be encouraging people to write yet more Forths? Why? > > Okay let's deter people from writing their own Forths by requiring > ELF expertise. ;-) > > The curriculums surely should have assignments to write a simple > compiler. Enough Eclipse already! We seem to be talking completely at cross purposes. If you want a Forth that's super-easy to write, then write it in assembler. Or in C. Or in Python, even. But I'm not talking about a Forth that's super-easy to write: I'm talking about how to get the best result, IMO. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-04-22 15:02 +0000 |
| Message-ID | <5356847d$0$25058$e4fe514c@dreader37.news.xs4all.nl> |
| In reply to | #29773 |
In article <3Zmdndi2EdYO88vOnZ2dnUVZ_sSdnZ2d@supernews.com>, Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: >In comp.lang.forth Albert van der Horst <albert@spenarnc.xs4all.nl> wrote: >> In article <WtGdnStmxf37o8vOnZ2dnUVZ_uadnZ2d@supernews.com>, >> >> I've this yourforth which is supposedly the simplest forth in >> assembler. One segment. It assembles in under a millisecond: >> >> " >> albert@cherry:~/PROJECT/yourforth$ time fasm yourforth.fas >> flat assembler version 1.70.03 (16384 kilobytes memory) >> 2 passes, 15197 bytes. >> >> real 0m0.008s >> user 0m0.000s >> sys 0m0.008s > >Looks like 8 milliseconds to me, but OK. :-) > >> albert@cherry:~/PROJECT/yourforth$ file yourforth >> yourforth: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), \ >> statically linked, stripped >> " >> >> Are you with me? So far so good. (This Forth passes a regression test, >> and even Hayes suite, after loading a lot of extensions.) >> " >> albert@cherry:~/PROJECT/yourforth$ strip yourforth >> albert@cherry:~/PROJECT/yourforth$ ls -l yourforth >> -rwxr-xr-x 1 albert albert 176 Apr 22 13:14 yourforth >> albert@cherry:~/PROJECT/yourforth$ yourforth >> Segmentation fault >> " >> >> So the gnu tool `` strip '' fails a simple test on the simplest of Forths. >> It just has to conclude that there are no symbols and leave. Instead it >> trims it to an unbelievable 176 bytes. >> >> I'm not inspired to fix this bug. If the writers of the program cannot >> come up with the idea to test it on a program that is as simple as >> this, I'm pretty sure I'll end up with rewriting the tool myself. > >There are two possibilities: yourforth isn't a real ELF file, or strip >has a bug, or both. But why do you want to strip it? To reveal a bug. Is that sufficient reason? >Andrew. Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-04-22 13:23 -0500 |
| Message-ID | <QNWdnaVFOeUhLsvOnZ2dnUVZ_q-dnZ2d@supernews.com> |
| In reply to | #29775 |
Albert van der Horst <albert@spenarnc.xs4all.nl> wrote: > In article <3Zmdndi2EdYO88vOnZ2dnUVZ_sSdnZ2d@supernews.com>, > Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: >>In comp.lang.forth Albert van der Horst <albert@spenarnc.xs4all.nl> wrote: >>> I'm not inspired to fix this bug. If the writers of the program cannot >>> come up with the idea to test it on a program that is as simple as >>> this, I'm pretty sure I'll end up with rewriting the tool myself. >> >>There are two possibilities: yourforth isn't a real ELF file, or strip >>has a bug, or both. But why do you want to strip it? > > To reveal a bug. Is that sufficient reason? I rather imagined that there was some purpose to all this, and that strip not working on the Forth executable was some sort of impediment to getting work done. But the fact that strip breaks on some very simple ELF files isn't evidence of anything except a bug in strip that no-one has come across before. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.invalid> |
|---|---|
| Date | 2014-04-22 19:19 +0200 |
| Message-ID | <lj68ag$g1g$1@solani.org> |
| In reply to | #29773 |
On Tue, 22 Apr 2014 08:28:51 -0500 Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: > In comp.lang.forth Albert van der Horst <albert@spenarnc.xs4all.nl> > > > albert@cherry:~/PROJECT/yourforth$ file yourforth > > yourforth: ELF 32-bit LSB executable, Intel 80386, version 1 > > (SYSV), \ statically linked, stripped > > " > > > > Are you with me? So far so good. (This Forth passes a regression > > test, and even Hayes suite, after loading a lot of extensions.) > > " > > albert@cherry:~/PROJECT/yourforth$ strip yourforth > > albert@cherry:~/PROJECT/yourforth$ ls -l yourforth > > -rwxr-xr-x 1 albert albert 176 Apr 22 13:14 yourforth > > albert@cherry:~/PROJECT/yourforth$ yourforth > > Segmentation fault > > " > > > > So the gnu tool `` strip '' fails a simple test on the simplest of > > Forths. It just has to conclude that there are no symbols and > > leave. Instead it trims it to an unbelievable 176 bytes. > > > > I'm not inspired to fix this bug. If the writers of the program > > cannot come up with the idea to test it on a program that is as > > simple as this, I'm pretty sure I'll end up with rewriting the tool > > myself. > > There are two possibilities: yourforth isn't a real ELF file, or strip > has a bug, or both. But why do you want to strip it? file utility recognize fasm generated elfs as already stripped. readelf also displays file contents correctly. strip has a problem with them and I guess not only with them. eg bmaxa@maxa:~/examples/assembler$ fasm hello.asm flat assembler version 1.71.17 (16384 kilobytes memory) 3 passes, 266 bytes. bmaxa@maxa:~/examples/assembler$ ls -l hello -rwxr-xr-x 1 bmaxa bmaxa 266 Apr 22 19:17 hello bmaxa@maxa:~/examples/assembler$ file hello hello: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, stripped bmaxa@maxa:~/examples/assembler$ strip hello bmaxa@maxa:~/examples/assembler$ file hello hello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, stripped bmaxa@maxa:~/examples/assembler$ ls -l hello -rwxr-xr-x 1 bmaxa bmaxa 320 Apr 22 19:17 hello bmaxa@maxa:~/examples/assembler$ ./hello Segmentation fault strip definitely corrupts file... -- Click OK to continue...
[toc] | [prev] | [next] | [standalone]
| From | Todd Hughes <noemail@dontemailme.org> |
|---|---|
| Date | 2014-04-10 11:24 +0000 |
| Message-ID | <li5v1u$3ed$1@speranza.aioe.org> |
| In reply to | #29498 |
It's remarkable that most posters in c.l.f seem to understand what most posters in c.l.c don't: C is more of a worldview and possibly a VM than it is a language. It is no longer helpful to understand the hardware if you want to use C. Actually, it's probably harmful. C has its own abstract view of the hardware and to use C you have to share that view, and of course be aware of all the broken beer bottles, banana peels and oil slicks left on the road by C. Especially gcc. Forget whatever else you know and put aside any expectations you may have. You will be ASSimilated. I have never understood the reason why people who are so insistent on compiling only conforming code and work so hard at miscompiling non-conforming code scream at the idea that lint should be built into every C compiler. Empirically we see we can't have it both ways. The only safe and reasonable default is warning about anything that isn't conforming. It's not safe to miscompile something and say nothing about it. We shouldn't have to specify 180 characters of warning options to get gcc to tell us what it knows. Just say it. The only remotely portable assembler is gas... Todd
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-04-10 06:55 -0500 |
| Message-ID | <wPydnRZ83aUKG9vOnZ2dnUVZ_qadnZ2d@supernews.com> |
| In reply to | #29506 |
Todd Hughes <noemail@dontemailme.org> wrote: > The only safe and reasonable default is warning about anything that > isn't conforming. It's not safe to miscompile something and say > nothing about it. There is no general way to know at compile time if a program is conforming or not. The best you can do is warn about problems that you see, and many compilers do so. Also, many warnings have a significant false positive rate, and IMHO no warning that generates false positives should be on by default. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-04-10 15:50 +0000 |
| Message-ID | <5346bdd1$0$25039$e4fe514c@dreader37.news.xs4all.nl> |
| In reply to | #29507 |
In article <wPydnRZ83aUKG9vOnZ2dnUVZ_qadnZ2d@supernews.com>, Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: >Todd Hughes <noemail@dontemailme.org> wrote: > >> The only safe and reasonable default is warning about anything that >> isn't conforming. It's not safe to miscompile something and say >> nothing about it. > >There is no general way to know at compile time if a program is >conforming or not. The best you can do is warn about problems that >you see, and many compilers do so. Also, many warnings have a >significant false positive rate, and IMHO no warning that generates >false positives should be on by default. On the contrary. Deciding whether a program conforms to a language specification is the only thing a compiler can do. E.g. a Pascal program can factorize infinite precision numbers. How much precision a number can have doesn't belong to the Pascal language specification and need not stick out anywhere in the Pascal program. A particular Pascal program has to give up on some integers, because they are too large. This has nothing to do with the program itself. Remember, the Pascal program can be valid or not without ever being compiled into a running program. Since 1980 it can handle more numbers, since Turbo Pascal is replaced by a 32 bit, then a 64 bit compiler. Comes C. They make a programmer aware that some numbers are 16 bits, and that you need double precision numbers to specify length for disk files. This kind of practicality makes C into a portable assembler. It also makes C a not-so-high level language. You're confused by the undecidability of whether a program ever stops, or ever divides by zero. The Pascal snippet x:=0 ; y := 1/x; is perfectly conforming, but will/should end in a run time error. Using Ulam sequence you can also construct more interesting examples where it is unsure, or even undecidable whether there will ever be an array out of bounds error. (Which translated into c-jargon is a "segmentation fault"). > >Andrew. Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-04-10 11:02 -0500 |
| Message-ID | <ENKdnXp0wN0FXdvOnZ2dnUVZ_q-dnZ2d@supernews.com> |
| In reply to | #29509 |
Albert van der Horst <albert@spenarnc.xs4all.nl> wrote: > In article <wPydnRZ83aUKG9vOnZ2dnUVZ_qadnZ2d@supernews.com>, > Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: >>Todd Hughes <noemail@dontemailme.org> wrote: >> >>> The only safe and reasonable default is warning about anything that >>> isn't conforming. It's not safe to miscompile something and say >>> nothing about it. >> >>There is no general way to know at compile time if a program is >>conforming or not. The best you can do is warn about problems that >>you see, and many compilers do so. Also, many warnings have a >>significant false positive rate, and IMHO no warning that generates >>false positives should be on by default. > > On the contrary. > Deciding whether a program conforms to a language specification is the only > thing a compiler can do. Is this post supposed to mean anything? A compiler can determine if a program is syntactically correct, but that's a very different thing. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-04-10 22:31 +0200 |
| Message-ID | <li6v2l$hp3$1@online.de> |
| In reply to | #29507 |
Andrew Haley wrote: > Todd Hughes <noemail@dontemailme.org> wrote: > >> The only safe and reasonable default is warning about anything that >> isn't conforming. It's not safe to miscompile something and say >> nothing about it. > > There is no general way to know at compile time if a program is > conforming or not. In general, yes. However, with this particular if(n>n+1) stuff, the compiler maintainer decided that it is non-conforming, and after a while decided to drop the warning message for removing the code after the if. That were two unrelated decisions: the dead code warning was in GCC for ages, but it worked only with optimization, because without, the analysis for dead code wasn't even performed (fair enough - in this case, the code is there, and executes as expected, because it isn't dead). However, the GCC maintainers decided to remove this warning completely, because it is not "reliable", i.e. you need to turn optimization on to see it. -- 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-11 03:55 -0500 |
| Message-ID | <39Cdnb_qnJGIM9rOnZ2dnUVZ_rOdnZ2d@supernews.com> |
| In reply to | #29512 |
Bernd Paysan <bernd.paysan@gmx.de> wrote: > Andrew Haley wrote: > >> Todd Hughes <noemail@dontemailme.org> wrote: >> >>> The only safe and reasonable default is warning about anything that >>> isn't conforming. It's not safe to miscompile something and say >>> nothing about it. >> >> There is no general way to know at compile time if a program is >> conforming or not. > > In general, yes. However, with this particular if(n>n+1) stuff, the > compiler maintainer decided that it is non-conforming, and after a while > decided to drop the warning message for removing the code after the if. It worked for me today: t.cc:38:13: warning: assuming signed overflow does not occur when assuming that (X + c) < X is always false [-Wstrict-overflow] if (n > n+1) Andrew.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-04-10 19:08 -0400 |
| Message-ID | <op.xd4ikyyo6zenlw@localhost> |
| In reply to | #29507 |
On Thu, 10 Apr 2014 07:55:03 -0400, Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: > [...] IMHO no warning that generates false positives should > be on by default. Then, there would likely be no warnings at all. If the first warning is actually a problem, then you are have to fix it before proceeding, or it will create additional warnings and errors. You should never attempt to fix later warnings or errors until the prior ones are fixed, sequentially, from the start. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-04-10 19:03 -0400 |
| Message-ID | <op.xd4ibdjg6zenlw@localhost> |
| In reply to | #29506 |
On Thu, 10 Apr 2014 07:24:46 -0400, Todd Hughes <noemail@dontemailme.org> wrote: > It's remarkable that most posters in c.l.f seem to understand what most > posters in c.l.c don't: C is more of a worldview and possibly a VM than > it is a language. That's a strange perspective, but an acceptable one. > It is no longer helpful to understand the hardware if you want to use C. Did anyone ever need to understand the hardware to use C? ... > C has its own abstract view of the hardware and to use C you have to > share that view, [...] C works best on the microprocessor model of computing hardware. Memory is contiguous, bytes are 8-bits, all pointers have a single size, integers and pointers are an integer multiple of the size of a byte, two's complement arithmetic, etc. Of course, C was implemented on a variety of hardware that didn't conform to that model, e.g., 16-bit bytes but 9-bit characters, differently sized pointers, no ability to access small integers as needed for characters, etc. These "other", mostly obsolete, mainframe/corporate platforms like Crays, DECs, Burroughs, IBMs, etc is what creates all the "undefined" behavior for C. C is superb for microprocessors where the useful behaviors are usually implemented. > The only safe and reasonable default is warning about anything that isn't > conforming. Everything of value in C is non-conforming. C was standardized for multiple different computing platforms with different architectures. Only 30% of C's code is truly portable, in the sense that the code performs exactly the same way on all hardware. Another 30% or so appears to be portable, because the same result can be implemented on most hardware, albeit differently. The rest is simply not portable. It has to be adjusted for different platforms. While the C language is almost entirely independent of the host, the C libraries aren't. Minimal C libraries need about twenty host specific functions. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2014-04-11 17:45 +0100 |
| Message-ID | <li9678$u25$1@dont-email.me> |
| In reply to | #29514 |
on 11/04/2014 00:03:01, "Rod Pemberton" wrote: > > C works best on the microprocessor model of computing hardware. Proof please. > Memory is contiguous, bytes are 8-bits, all pointers have a single > size, integers and pointers are an integer multiple of the size of a > byte, two's complement arithmetic, etc. Of course, C was implemented > on a variety of hardware that didn't conform to that model, e.g., C started life on a system that didn't conform to your ideal model for C. > 16-bit bytes but 9-bit characters, differently sized pointers, no > ability to access small integers as needed for characters, etc. These > "other", mostly obsolete, > mainframe/corporate platforms like Crays, DECs, Burroughs, IBMs, etc > is what creates all the "undefined" behavior for C. As opposed to the undefined behaviour on 8bit byte, pointers single size, 2s complement etc? > C is superb for > microprocessors where the useful behaviors are usually implemented. The above is a "let's rewrite history" or (as we call it in my business) rubbish.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-04-11 17:16 +0000 |
| Message-ID | <2014Apr11.191612@mips.complang.tuwien.ac.at> |
| In reply to | #29526 |
"Alex McDonald" <blog@rivadpm.com> writes:
>on 11/04/2014 00:03:01, "Rod Pemberton" wrote:
>> Memory is contiguous, bytes are 8-bits, all pointers have a single
>> size, integers and pointers are an integer multiple of the size of a
>> byte, two's complement arithmetic, etc. Of course, C was implemented
>> on a variety of hardware that didn't conform to that model, e.g.,
>
>C started life on a system that didn't conform to your ideal model for C.
C started life on the PDP-11, and it has all the properties given
above.
- anton
--
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]
Page 12 of 22 — ← Prev page 1 … 10 11 [12] 13 14 … 22 Next page →
Back to top | Article view | comp.lang.forth
csiph-web