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 6 of 22 — ← Prev page 1 … 4 5 [6] 7 8 … 22 Next page →
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-04-26 11:38 +0000 |
| Subject | Re: @ and optimization |
| Message-ID | <2014Apr26.133848@mips.complang.tuwien.ac.at> |
| In reply to | #29851 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>Do we agree that Forth, as defined, uses "as if" semantics? I think
>we must, because no-one is suggesting that the stack really has to be
>implemented as a stack
You mean, as a memory-area plus stack pointer (as on most hardware)?
As a hardware stack (as on Chuck Moore's chips)?
>all stack accesses may be converted to a
>series of register moves.
Not in general.
>So, "as if" semantics apply, and merging
>memory accesses is arguably a legitimate thing for a compiler to do.
>You can only reasonably describe this as "miscompiling" if you define
>your memory model.
That's not necessary. If it produces a different behaviour than the
original code, it's not a legitimate thing for a compiler to do. That
follows directly from the as-if rule. No need for me to define a
memory model; that has been done by the hardware maker.
Your suggestion that an "optimization barrier" would be needed is an
admission that the as-if rule does not hold for the "optimization".
>That is hard because it forces you to confront the
>reality of today's hardware.
I don't find it particularly hard, and side effects on reading from an
I/O device have existed for over 30 years.
>>>>>So, your "foo @ foo @" could be "foo @ read-barrier foo @" in the
>>>>>rare case where you actually must read from foo twice, and this is
>>>>>guaranteed to do so even on machines with relaxed memory ordering.
>>>>
>>>> "Relaxed memory ordering" does not have anything to do with it.
>>>
>>>Huh? In this case it does.
>>>
>>>> Even the most broken machine will not do the second "foo @" before
>>>> the first "foo @".
>>>
>>>Actually, I'm not sure about Alpha, but everything else won't AFAIK.
>>
>> So you cannot name a single machine where relaxed memory ordering has
>> anything to do with it.
>
>Huh? You've lost me.
Read again, and (if necessary) ask concrete questions!
>>>and b) even if they don't the hardware may replace two fetches from
>>>the same address with a single one. And this is not "weird"
>>>hardware, but almost every modern (32 bits and up) design. Even the
>>>venerable x86 needs a StoreLoad barrier if you want sequential
>>>consistency.
>>
>> Memory ordering/sequential consistency has nothing to do with this, as
>> established above. And sure, if you have two loads from the same
>> addresses in cached memory, the second one will be served from the
>> cache.
>
>How is that different in effect from converting "foo @ foo @" into
>"foo @ dup" ?
The difference is that the compiler doesn't know that FOO points to
cached memory.
>> But devices that have a side effect on reading are not in cached
>> memory, and two loads will result in two accesses (and two times the
>> side effect).
>
>I agree. Memory-mapped I/O is inherently non-portable and cannot be
>discussed outside the context of a particular physical system.
Sure it can. We are doing so. And while programs doing memory-mapped
I/O may not be portable to platforms that don't have the device, they
can be portable across machines that have the device, and across
different Forth implementations on these machines.
- 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 14:35 +0200 |
| Subject | Re: @ and optimization |
| Message-ID | <ljg969$lli$1@online.de> |
| In reply to | #29859 |
Anton Ertl wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>I agree. Memory-mapped I/O is inherently non-portable and cannot be >>discussed outside the context of a particular physical system. > > Sure it can. We are doing so. And while programs doing memory-mapped > I/O may not be portable to platforms that don't have the device, they > can be portable across machines that have the device, and across > different Forth implementations on these machines. If this "inherently non-portable" nature would be true, OpenFirmware wouldn't make sense (or work at all). However, it does make sense and it works. -- 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-26 09:59 -0500 |
| Subject | Re: @ and optimization |
| Message-ID | <4dOdncefNIFGVMbOnZ2dnUVZ_s2dnZ2d@supernews.com> |
| In reply to | #29859 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>Do we agree that Forth, as defined, uses "as if" semantics? I think >>we must, because no-one is suggesting that the stack really has to be >>implemented as a stack > > You mean, as a memory-area plus stack pointer (as on most hardware)? > As a hardware stack (as on Chuck Moore's chips)? > >>all stack accesses may be converted to a >>series of register moves. > > Not in general. Point taken. >>So, "as if" semantics apply, and merging >>memory accesses is arguably a legitimate thing for a compiler to do. >>You can only reasonably describe this as "miscompiling" if you define >>your memory model. > > That's not necessary. If it produces a different behaviour than the > original code, it's not a legitimate thing for a compiler to do. > That follows directly from the as-if rule. No need for me to define > a memory model; that has been done by the hardware maker. > > Your suggestion that an "optimization barrier" would be needed is an > admission that the as-if rule does not hold for the "optimization". The "as if" rule says that no standard program can tell the difference between an optimized and an unoptimized program. If any standard program can tell the difference, then the optimizer is broken. But no standard program can tell the difference between "foo @ foo @" and "foo @ dup", except perhaps by measuring speed. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-04-26 10:14 -0500 |
| Subject | Re: @ and optimization |
| Message-ID | <HLCdnR60JvLsUMbOnZ2dnUVZ_o6dnZ2d@supernews.com> |
| In reply to | #29866 |
Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: > Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > >> Your suggestion that an "optimization barrier" would be needed is an >> admission that the as-if rule does not hold for the "optimization". > > The "as if" rule says that no standard program can tell the difference > between an optimized and an unoptimized program. If any standard > program can tell the difference, then the optimizer is broken. But no > standard program can tell the difference between "foo @ foo @" and > "foo @ dup", except perhaps by measuring speed. Err, assuming that foo has no side-effects. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-04-26 15:30 +0000 |
| Subject | Re: @ and optimization |
| Message-ID | <2014Apr26.173025@mips.complang.tuwien.ac.at> |
| In reply to | #29866 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>The "as if" rule says that no standard program can tell the difference
>between an optimized and an unoptimized program.
There are no real-world standard programs in C nor in Forth, so this
form of the as-if rule is totally useless. If would allow
"optimizing" every real-world program into a noop.
> If any standard
>program can tell the difference, then the optimizer is broken. But no
>standard program can tell the difference between "foo @ foo @" and
>"foo @ dup", except perhaps by measuring speed.
If FOO points to an I/O register with a side effect on reading, there
is a difference. And if a Forth compiler wants to be useful in the
real world and not just for benchmarks, it has to preserve this
difference.
- 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:05 -0500 |
| Subject | Re: @ and optimization |
| Message-ID | <jsydnVZAf6j8esbOnZ2dnUVZ_tadnZ2d@supernews.com> |
| In reply to | #29871 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>The "as if" rule says that no standard program can tell the difference >>between an optimized and an unoptimized program. > > There are no real-world standard programs in C nor in Forth, so this > form of the as-if rule is totally useless. If would allow > "optimizing" every real-world program into a noop. I take that point, but it does not change the definition of the "as if" rule. >>If any standard program can tell the difference, then the optimizer >>is broken. But no standard program can tell the difference between >>"foo @ foo @" and "foo @ dup", except perhaps by measuring speed. > > If FOO points to an I/O register ... then what @ does is not defined by the language, but by the hardware; or rather a combination of the hardware and the language implementation. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-04-26 17:27 +0000 |
| Subject | Re: @ and optimization |
| Message-ID | <2014Apr26.192747@mips.complang.tuwien.ac.at> |
| In reply to | #29876 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>The "as if" rule says that no standard program can tell the difference
>>>between an optimized and an unoptimized program.
>>
>> There are no real-world standard programs in C nor in Forth, so this
>> form of the as-if rule is totally useless. If would allow
>> "optimizing" every real-world program into a noop.
>
>I take that point, but it does not change the definition of the "as
>if" rule.
In that case, my answer on using your definition of "as-if" semantics
for Forth is "no". Your definition of "as-if" semantics is useless,
because the specification of Forth in the standard is incomplete, and
therefore cannot be used as a basis for judging transformations.
- 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:39 -0500 |
| Subject | Re: @ and optimization |
| Message-ID | <37-dnQJBQ_rycsbOnZ2dnUVZ_qydnZ2d@supernews.com> |
| In reply to | #29879 |
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: >>>>The "as if" rule says that no standard program can tell the difference >>>>between an optimized and an unoptimized program. >>> >>> There are no real-world standard programs in C nor in Forth, so this >>> form of the as-if rule is totally useless. If would allow >>> "optimizing" every real-world program into a noop. >> >>I take that point, but it does not change the definition of the "as >>if" rule. > > In that case, my answer on using your definition of "as-if" semantics > for Forth is "no". Your definition of "as-if" semantics is useless, > because the specification of Forth in the standard is incomplete, and > therefore cannot be used as a basis for judging transformations. I don't think it's my definition of the "as if" rule. As far as I'm aware it's the only definition of the rule that is logically possible. You can only define program equivalence in terms of well-defined programs. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-04-26 18:07 +0000 |
| Subject | Re: @ and optimization |
| Message-ID | <2014Apr26.200704@mips.complang.tuwien.ac.at> |
| In reply to | #29880 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>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:
>>>>>The "as if" rule says that no standard program can tell the difference
>>>>>between an optimized and an unoptimized program.
>>>>
>>>> There are no real-world standard programs in C nor in Forth, so this
>>>> form of the as-if rule is totally useless. If would allow
>>>> "optimizing" every real-world program into a noop.
>>>
>>>I take that point, but it does not change the definition of the "as
>>>if" rule.
>>
>> In that case, my answer on using your definition of "as-if" semantics
>> for Forth is "no". Your definition of "as-if" semantics is useless,
>> because the specification of Forth in the standard is incomplete, and
>> therefore cannot be used as a basis for judging transformations.
>
>I don't think it's my definition of the "as if" rule. As far as I'm
>aware it's the only definition of the rule that is logically possible.
>You can only define program equivalence in terms of well-defined
>programs.
I define program equivalence through actual behaviour, and for
languages like Forth and C that have no well-defined programs (at
least not in the real world), that's the only definition that makes
sense.
- 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-27 03:24 -0500 |
| Subject | Re: @ and optimization |
| Message-ID | <_5adnXJ9XLFLI8HOnZ2dnUVZ_u2dnZ2d@supernews.com> |
| In reply to | #29883 |
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: >>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>>>>>The "as if" rule says that no standard program can tell the difference >>>>>>between an optimized and an unoptimized program. >>>>> >>>>> There are no real-world standard programs in C nor in Forth, so this >>>>> form of the as-if rule is totally useless. If would allow >>>>> "optimizing" every real-world program into a noop. >>>> >>>>I take that point, but it does not change the definition of the "as >>>>if" rule. >>> >>> In that case, my answer on using your definition of "as-if" semantics >>> for Forth is "no". Your definition of "as-if" semantics is useless, >>> because the specification of Forth in the standard is incomplete, and >>> therefore cannot be used as a basis for judging transformations. >> >>I don't think it's my definition of the "as if" rule. As far as I'm >>aware it's the only definition of the rule that is logically possible. >>You can only define program equivalence in terms of well-defined >>programs. > > I define program equivalence through actual behaviour, OK, but how do you know how a program is supposed to be behave? Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-04-27 13:00 +0000 |
| Subject | Re: @ and optimization |
| Message-ID | <2014Apr27.150017@mips.complang.tuwien.ac.at> |
| In reply to | #29905 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>> I define program equivalence through actual behaviour,
>
>OK, but how do you know how a program is supposed to be behave?
Sure when I write my first compiler for such a language, I may have
this problem (but see below). But that's not the issue for gcc. You
have the behaviour of earlier versions of gcc as reference; in
addition, gcc without optimization mostly behaves right.
As for the first-compiler issue, I remember that people who wanted to
implement Forth asked questions about what various things specified in
the standard should do, and a frequent answer was that they should not
look in the standard to understand the language, but instead learn to
program in Forth, and then these questions should be clear.
- 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-27 11:18 -0500 |
| Subject | Re: @ and optimization |
| Message-ID | <56udnRBwU_h1sMDOnZ2dnUVZ_oSdnZ2d@supernews.com> |
| In reply to | #29916 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>> I define program equivalence through actual behaviour, >> >>OK, but how do you know how a program is supposed to be behave? > > Sure when I write my first compiler for such a language, I may have > this problem (but see below). But that's not the issue for gcc. AFAIK we weren't talking about GCC, we were talking about Forth. I suppose some of the same issues arise, but it's not the same thing. > As for the first-compiler issue, I remember that people who wanted > to implement Forth asked questions about what various things > specified in the standard should do, and a frequent answer was that > they should not look in the standard to understand the language, but > instead learn to program in Forth, and then these questions should > be clear. I don't believe it. We're talking about edge cases here, and it's not at all clear that experienced Forth programmers will agree. I suppose everyone could agree to use the "ask the Oracle" standard, but there may be some holdouts against that idea. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-04-28 15:12 +0000 |
| Subject | Re: @ and optimization |
| Message-ID | <2014Apr28.171232@mips.complang.tuwien.ac.at> |
| In reply to | #29919 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>> I define program equivalence through actual behaviour,
>>>
>>>OK, but how do you know how a program is supposed to be behave?
>>
>> Sure when I write my first compiler for such a language, I may have
>> this problem (but see below). But that's not the issue for gcc.
>
>AFAIK we weren't talking about GCC, we were talking about Forth.
I was writing about Forth and C. But ok, let's stick with the issue
of what "FOO @" means if FOO is the address of a memory-mapped I/O
register.
>> As for the first-compiler issue, I remember that people who wanted
>> to implement Forth asked questions about what various things
>> specified in the standard should do, and a frequent answer was that
>> they should not look in the standard to understand the language, but
>> instead learn to program in Forth, and then these questions should
>> be clear.
>
>I don't believe it. We're talking about edge cases here, and it's not
>at all clear that experienced Forth programmers will agree.
While people here disagree about lots of things (including things that
are explicitly written in the standard), I have never seen anyone
suggest that if FOO is the address of a memory-mapped I/O register,
"FOO @" should do anything other than a machine-level load from that
address. I am sure that there no program that does that where the
programmer expects anything else. Edge case? Not in the least. Just
not standardized.
> I suppose
>everyone could agree to use the "ask the Oracle" standard, but there
>may be some holdouts against that idea.
I don't know what standard that is, but your phrasing indicates that
it is a straw-man argument.
- 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-29 03:52 -0500 |
| Subject | Re: @ and optimization |
| Message-ID | <j_OdnQY5H8mq9cLOnZ2dnUVZ_uGdnZ2d@supernews.com> |
| In reply to | #29937 |
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: >>>>> I define program equivalence through actual behaviour, >>>> >>>>OK, but how do you know how a program is supposed to be behave? >>> >>> Sure when I write my first compiler for such a language, I may have >>> this problem (but see below). But that's not the issue for gcc. >> >>AFAIK we weren't talking about GCC, we were talking about Forth. > > I was writing about Forth and C. But ok, let's stick with the issue > of what "FOO @" means if FOO is the address of a memory-mapped I/O > register. OK. My take on it is much like Elizabeth's: if you're doing something outside the scope of the standard, you might have to disable an optimizer or in some way tell it what you're doing. >>> As for the first-compiler issue, I remember that people who wanted >>> to implement Forth asked questions about what various things >>> specified in the standard should do, and a frequent answer was that >>> they should not look in the standard to understand the language, but >>> instead learn to program in Forth, and then these questions should >>> be clear. >> >>I don't believe it. We're talking about edge cases here, and it's not >>at all clear that experienced Forth programmers will agree. > > While people here disagree about lots of things (including things > that are explicitly written in the standard), I have never seen > anyone suggest that if FOO is the address of a memory-mapped I/O > register, "FOO @" should do anything other than a machine-level load > from that address. I am sure that there no program that does that > where the programmer expects anything else. Edge case? Not in the > least. Just not standardized. But that doesn't help address the more general point. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2014-04-29 03:09 -0700 |
| Subject | Re: @ and optimization |
| Message-ID | <7082eaa8-b68a-46c8-be0b-2e9540be033e@googlegroups.com> |
| In reply to | #29955 |
On Tuesday, 29 April 2014 09:52:07 UTC+1, Andrew Haley wrote: > > I was writing about Forth and C. But ok, let's stick with the issue > > of what "FOO @" means if FOO is the address of a memory-mapped I/O > > register. > > > OK. My take on it is much like Elizabeth's: if you're doing something > outside the scope of the standard, you might have to disable an > optimizer or in some way tell it what you're doing. In what respect is FOO @ "outside the scope of the standard"? FOO places an address on the stack. @ reads from it.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-04-29 09:24 -0500 |
| Subject | Re: @ and optimization |
| Message-ID | <K8SdnQhRzLWnK8LOnZ2dnUVZ_v-dnZ2d@supernews.com> |
| In reply to | #29956 |
Mark Wills <markwills1970@gmail.com> wrote: > On Tuesday, 29 April 2014 09:52:07 UTC+1, Andrew Haley wrote: >> > I was writing about Forth and C. But ok, let's stick with the issue >> > of what "FOO @" means if FOO is the address of a memory-mapped I/O >> > register. >> >> >> OK. My take on it is much like Elizabeth's: if you're doing something >> outside the scope of the standard, you might have to disable an >> optimizer or in some way tell it what you're doing. > > In what respect is FOO @ "outside the scope of the standard"? > > FOO places an address on the stack. @ reads from it. So, it depends on what FOO does. @ is only defined in terms of data space: anything else is outside the scope of the standard. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-04-29 08:36 -1000 |
| Subject | Re: @ and optimization |
| Message-ID | <K82dnUAO_eSibMLOnZ2dnUVZ_vCdnZ2d@supernews.com> |
| In reply to | #29956 |
On 4/29/14 12:09 AM, Mark Wills wrote: > On Tuesday, 29 April 2014 09:52:07 UTC+1, Andrew Haley wrote: >>> I was writing about Forth and C. But ok, let's stick with the issue >>> of what "FOO @" means if FOO is the address of a memory-mapped I/O >>> register. >> >> >> OK. My take on it is much like Elizabeth's: if you're doing something >> outside the scope of the standard, you might have to disable an >> optimizer or in some way tell it what you're doing. > > In what respect is FOO @ "outside the scope of the standard"? > > FOO places an address on the stack. @ reads from it. > If the address is a memory-mapped I/O register, its behavior is determined by the device on the other end. The device's characteristics need to be documented in order for a @ to be really useful. Therefore, that case should be appropriately described as "implementation-defined". In most cases like that I've seen, @ would return the value input from the device in the low-order part of the cell, but there may be more to it than that: you might need to know under what circumstances the value will change or be valid, for example. There's no way a language standard can fully prescribe the behavior in this case, although it may be appropriate to put in a 1-sentence caveat in Section 3 regarding memory-mapped devices. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-04-30 10:18 +0000 |
| Subject | Re: @ and optimization |
| Message-ID | <2014Apr30.121857@mips.complang.tuwien.ac.at> |
| In reply to | #29973 |
"Elizabeth D. Rather" <erather@forth.com> writes:
>If the address is a memory-mapped I/O register, its behavior is
>determined by the device on the other end. The device's characteristics
>need to be documented in order for a @ to be really useful. Therefore,
>that case should be appropriately described as "implementation-defined".
>In most cases like that I've seen, @ would return the value input from
>the device in the low-order part of the cell, but there may be more to
>it than that: you might need to know under what circumstances the value
>will change or be valid, for example. There's no way a language standard
>can fully prescribe the behavior in this case, although it may be
>appropriate to put in a 1-sentence caveat in Section 3 regarding
>memory-mapped devices.
Sure, the complete behaviour depends on the device. The questions
are:
1) If a programmer writes FOO @ FOO @ and FOO is such a memory-mapped
I/O register, what does the programmer intend? It's clear that they
intend two machine-level loads.
2) Do we need to specify this in the standard? Or is it enough to
have this as a de-facto standard?
3) If we want to specify it in the standard, how do we do it?
There is a similar issue wrt calling functions from an external
library. "There's no way a language standard can fully prescribe the
behavior in this case", nevertheless even gcc compiles such calls as
intended.
- 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 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-04-29 14:38 +0000 |
| Subject | Re: @ and optimization |
| Message-ID | <2014Apr29.163806@mips.complang.tuwien.ac.at> |
| In reply to | #29955 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>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:
>>>>>> I define program equivalence through actual behaviour,
>>>>>
>>>>>OK, but how do you know how a program is supposed to be behave?
...
>OK. My take on it is much like Elizabeth's: if you're doing something
>outside the scope of the standard, you might have to disable an
>optimizer or in some way tell it what you're doing.
So how the program is supposed to behave is not in question. You know
it and you implement it correctly when you don't optimize it.
Concerning your appeal to Elizabeth Rather's authority: citation
needed.
>>>I don't believe it. We're talking about edge cases here, and it's not
>>>at all clear that experienced Forth programmers will agree.
>>
>> While people here disagree about lots of things (including things
>> that are explicitly written in the standard), I have never seen
>> anyone suggest that if FOO is the address of a memory-mapped I/O
>> register, "FOO @" should do anything other than a machine-level load
>> from that address. I am sure that there no program that does that
>> where the programmer expects anything else. Edge case? Not in the
>> least. Just not standardized.
>
>But that doesn't help address the more general point.
For other cases it's the same. You know what behaviour programmers
expect, and you implement it in the non-optimizing case.
- 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-29 10:21 -0500 |
| Subject | Re: @ and optimization |
| Message-ID | <wuadnTOgBLTvXsLOnZ2dnUVZ_ridnZ2d@supernews.com> |
| In reply to | #29963 |
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: >>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>>>>>> I define program equivalence through actual behaviour, >>>>>> >>>>>>OK, but how do you know how a program is supposed to be behave? > ... >>OK. My take on it is much like Elizabeth's: if you're doing something >>outside the scope of the standard, you might have to disable an >>optimizer or in some way tell it what you're doing. > > So how the program is supposed to behave is not in question. You know > it and you implement it correctly when you don't optimize it. Well, that's your contention. > Concerning your appeal to Elizabeth Rather's authority: citation > needed. I did not appeal to anyone's authority. I agreed with Elizabeth when she said >On 4/23/14 2:16 PM, Rod Pemberton wrote: >> On Wed, 23 Apr 2014 09:07:47 -0400, Anton Ertl >> <anton@mips.complang.tuwien.ac.at> wrote: >> >> [volatile issues in Forth] >> >>> In any case, if the programmer wants to write "foo @ dup", they can do >>> so, so there is little reason to "optimize" "foo @ foo @" into "foo @ >>> dup", and if there are any reasons not to do it, we should refrain >>> from it. >> >> How do you tell a Forth optimizer to selectively not optimize >> "foo @ foo @" into "foo @ dup"? Forth has no keyword like >> "volatile" in C to say: "Do not optimize this code." > >All the optimizing Forths I know have ways to turn the optimizer off and >on. It's pretty much essential, for many reasons. >>>>I don't believe it. We're talking about edge cases here, and it's not >>>>at all clear that experienced Forth programmers will agree. >>> >>> While people here disagree about lots of things (including things >>> that are explicitly written in the standard), I have never seen >>> anyone suggest that if FOO is the address of a memory-mapped I/O >>> register, "FOO @" should do anything other than a machine-level load >>> from that address. I am sure that there no program that does that >>> where the programmer expects anything else. Edge case? Not in the >>> least. Just not standardized. >> >>But that doesn't help address the more general point. > > For other cases it's the same. You know what behaviour programmers > expect, and you implement it in the non-optimizing case. Well, this is in effect to forbid optimization. While this may be your personal preference, that is all it is. Forth is, IMO, far more fexible than that, and Forth users can cope with optimizing compilers and occasionally switch them off. Andrew.
[toc] | [prev] | [next] | [standalone]
Page 6 of 22 — ← Prev page 1 … 4 5 [6] 7 8 … 22 Next page →
Back to top | Article view | comp.lang.forth
csiph-web