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-04-29 22:52 -0700 |
| Articles | 20 on this page of 374 — 32 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: 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-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 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-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 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 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
Page 4 of 19 — ← Prev page 1 2 3 [4] 5 6 … 19 Next page →
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-04-14 09:57 +0000 |
| Message-ID | <534bb0f8$0$27133$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #29629 |
In article <je6dnSkiYfdqOdbOnZ2dnUVZ_gudnZ2d@supernews.com>,
Andrew Haley <andrew29@littlepinkcloud.invalid> wrote:
>Bernd Paysan <bernd.paysan@gmx.de> wrote:
>> Assad Ebrahim wrote:
>>> Thanks for the interesting article reference.
>>>
>>> Is the below a fair representation of your and Bernd's point of view?
>>>
>>> (A1) we want some of the optimisations that optimising compilers
>>> produce
>>>
>>> (A2) but we don't want them to do so at the expense of taking too
>>> many liberties with the code
>>
>> Let's rephrase it: I want Forth's primitives to be tightly
>> specified, i.e. there is not much place for "is undefined".
>> Numbers are either unsigned or two's complement, and wrap around
>> (Forth's dual use of + and - really makes only sense in two's
>> complement). Addresses are either in memory, or they produce a -9
>> THROW on access. If the compiler does an optimization, there must
>> be a proof that the resulting behavior is equivalent to the
>> unoptimized code.
>>
>> There are some corner cases, which Stephen called "the volatile
>> issue": Is
>>
>> foo @ foo @
>>
>> identical to
>>
>> foo @ dup
>>
>> ? Actually, it isn't. foo @ dup shall result in two times the same
>> result, no matter if there is a race condition with another process,
>> while foo @ foo @ *should* have different results in that case.
>> AFAIK, some earlier versions of VFX did not distinguish between both
>> options, and thereby miscompiled Andrew's multithreaded program.
>> I'm deliberately saying "miscompiled", because Andrew was surprised
>> by the result, and he complained to Stephen, who gave the bug a name
>> ("the volatile issue").
>
>The trouble with this line of thinking is that it doesn't help you
>with weakly ordered systems. The hardware itself might turn
>
> foo @ foo @
>
>into
>
> foo @ dup
>
>unless you insert memory barriers into the code. I don't think it's
>reasonable to allow hardware to do this but forbid compilers from
>doing the exact same thing. I suppose you could insis on sequential
>consistency everywhere and insert memory barriers everywhere.
I agree with that an optimiser should be allowed to do that.
The Forth way is to explicitly command optimisation where you want it.
' sql-interpreter optimise
A hardware access thing would be a separate word and it would
have the DON'T-OPTIMISE bit in its flag field. So the optimiser would
know not to inline that part and mashing it into a one big
strange intel instruction with the surroundings.
Come on boys and girls. To the compiler it may look the same to have
hundreds of accesses to the array length or polling an address until
the byte has arrived, but we know better.
>
>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 | Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> |
|---|---|
| Date | 2014-04-14 11:56 +0100 |
| Message-ID | <snenk912jm9i17c44n7ogbmmdbl64frqkc@4ax.com> |
| In reply to | #29633 |
On 14 Apr 2014 09:57:12 GMT, albert@spenarnc.xs4all.nl (Albert van der
Horst) wrote:
>In article <je6dnSkiYfdqOdbOnZ2dnUVZ_gudnZ2d@supernews.com>,
>Andrew Haley <andrew29@littlepinkcloud.invalid> wrote:
>>Bernd Paysan <bernd.paysan@gmx.de> wrote:
>>> Assad Ebrahim wrote:
>>>> Is the below a fair representation of your and Bernd's point of view?
>>>>
>>>> (A1) we want some of the optimisations that optimising compilers
>>>> produce
>>>>
>>>> (A2) but we don't want them to do so at the expense of taking too
>>>> many liberties with the code
>>>
>>> Let's rephrase it: I want Forth's primitives to be tightly
>>> specified, i.e. there is not much place for "is undefined".
>>> Numbers are either unsigned or two's complement, and wrap around
>>> (Forth's dual use of + and - really makes only sense in two's
>>> complement). Addresses are either in memory, or they produce a -9
>>> THROW on access. If the compiler does an optimization, there must
>>> be a proof that the resulting behavior is equivalent to the
>>> unoptimized code.
>>>
>>> There are some corner cases, which Stephen called "the volatile
>>> issue": Is
>>>
>>> foo @ foo @
>>>
>>> identical to
>>>
>>> foo @ dup
>>>
>>> ? Actually, it isn't. foo @ dup shall result in two times the same
>>> result, no matter if there is a race condition with another process,
>>> while foo @ foo @ *should* have different results in that case.
>>> AFAIK, some earlier versions of VFX did not distinguish between both
>>> options, and thereby miscompiled Andrew's multithreaded program.
>>> I'm deliberately saying "miscompiled", because Andrew was surprised
>>> by the result, and he complained to Stephen, who gave the bug a name
>>> ("the volatile issue").
>>
>>The trouble with this line of thinking is that it doesn't help you
>>with weakly ordered systems. The hardware itself might turn
>>
>> foo @ foo @
>>
>>into
>>
>> foo @ dup
>>
>>unless you insert memory barriers into the code. I don't think it's
>>reasonable to allow hardware to do this but forbid compilers from
>>doing the exact same thing. I suppose you could insis on sequential
>>consistency everywhere and insert memory barriers everywhere.
>
>I agree with that an optimiser should be allowed to do that.
>
>The Forth way is to explicitly command optimisation where you want it.
>
>' sql-interpreter optimise
>
>A hardware access thing would be a separate word and it would
>have the DON'T-OPTIMISE bit in its flag field. So the optimiser would
>know not to inline that part and mashing it into a one big
>strange intel instruction with the surroundings.
>
>Come on boys and girls. To the compiler it may look the same to have
>hundreds of accesses to the array length or polling an address until
>the byte has arrived, but we know better.
>
>>
>>Andrew.
>
>Groetjes Albert
Seems that the source of trouble is in a "probabilistic" notion of
"correctness", as explained below:
Since context and intent are difficult to model, an optimising
compiler makes a number of assumptions, which necessarily limit the
types of contexts / intents it understands and/or respects.
If an optimising compiler were to work on exact equivalence in all
possible contexts, there would likely be many fewer optimisations it
could legitimately make.
But by relaxing the quality measure of exact equivalence, what is
left? The best one could say is that modern optimising compilers
appear to be working on a probabilistic notion of correctness. For
example: the following transformation is "probably the right thing to
do" because "it's right in most cases".
Similarly, the fact that many of the optimisations are not actually
improvements in *all* cases, would also be considered "acceptable" in
this new probabilistic notion of quality. "better" is not better
*always* but better "in many cases along at least one measure", speed,
size, ...
But going down that road seems like a source of endless difficulties
since by definition edge cases will "probably" never be right.
If the above is true, raises questions about whether reliability will
ever be achievable when using an optimising compiler.
And what have we gained and what have we lost in exchange?
The fact that an average programmer can produce code that is almost
always adequate, but almost never correct?
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-04-14 14:53 +0200 |
| Message-ID | <liglom$4hq$1@online.de> |
| In reply to | #29629 |
Andrew Haley wrote: > The trouble with this line of thinking is that it doesn't help you > with weakly ordered systems. The hardware itself might turn > > foo @ foo @ > > into > > foo @ dup > > unless you insert memory barriers into the code. Yes, indeed. Different hardware has very different memory consistency models, so depending on the hardware, you have to jump through hoops to get your multithreaded program to actually work. This is clearly stuff that is still in development, and no consensus has emerged. > I don't think it's > reasonable to allow hardware to do this but forbid compilers from > doing the exact same thing. I suppose you could insis on sequential > consistency everywhere and insert memory barriers everywhere. The interesting thing here is that e.g. Intel always had a strong consistency model, but ARM has a weak consistency model. They have decided to go stronger in ARMv8 (adding sequentially consistent loads and stores and have aquire/release instructions for transactional memory), so there at least is a tendency towards strong consistency, because that's what programmers need to get their multithreaded programs right. Thus this field is still a field where there is active debate how to get things right (and IMHO transactional memory is the solution), so this discussion will end up with a vocabulary so that we can write multi-threaded programs that don't get miscompiled - by telling the compiler which operations need to be performed as transactions. So far, we are still struggling with this stuff, so for now, it is difficult to write correct multithreaded programs. Gforth git head provides BARRIER, !@ (atomic swap), and +!@ (atomic increment and swap), and we are discussing if we add some prefix to !@ and +!@ to make clear they are atomic (maybe provide some non-atomic faster versions). -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-04-14 07:26 -0700 |
| Message-ID | <7x7g6sf0mh.fsf@ruckus.brouhaha.com> |
| In reply to | #29636 |
Bernd Paysan <bernd.paysan@gmx.de> writes: > Thus this field is still a field where there is active debate how to get > things right (and IMHO transactional memory is the solution), ... > Gforth git head provides BARRIER, !@ (atomic swap), and +!@ (atomic > increment and swap), and we are discussing if we add some prefix to !@ and > +!@ to make clear they are atomic (maybe provide some non-atomic faster > versions). Transactional memory is traditionally done with compare-and-swap (CAS). Is increment-and-swap implemented in terms of that? Do you not also want to expose CAS directly? You might like: The Transactional Memory / Garbage Collection Analogy by Dan Grossman https://homes.cs.washington.edu/~djg/papers/analogy_oopsla07.pdf
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-04-14 21:21 +0200 |
| Message-ID | <lihcf2$12b$1@online.de> |
| In reply to | #29639 |
Paul Rubin wrote: > Transactional memory is traditionally done with compare-and-swap (CAS). > Is increment-and-swap implemented in terms of that? Do you not also > want to expose CAS directly? I forgot that, of course we have CAS, too, called ?!@. Not having CAS would indeed be stupid ;-). -- 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-15 04:07 -0500 |
| Message-ID | <h_adnTeMje1_a9HOnZ2dnUVZ_jWdnZ2d@supernews.com> |
| In reply to | #29646 |
Bernd Paysan <bernd.paysan@gmx.de> wrote: > Paul Rubin wrote: >> Transactional memory is traditionally done with compare-and-swap (CAS). >> Is increment-and-swap implemented in terms of that? Do you not also >> want to expose CAS directly? > > I forgot that, of course we have CAS, too, called ?!@. Excellent! All Forth words should be indistinguishable from line noise. ;-) Andrew.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-04-14 09:55 -0700 |
| Message-ID | <994b70e1-c803-4f87-9e91-7c9d3575c456@googlegroups.com> |
| In reply to | #29636 |
On Monday, April 14, 2014 5:53:41 AM UTC-7, Bernd Paysan wrote: > Thus this field is still a field where there is active debate how to get > things right (and IMHO transactional memory is the solution), so this > discussion will end up with a vocabulary so that we can write multi-threaded > programs that don't get miscompiled - by telling the compiler which > operations need to be performed as transactions. So far, we are still > struggling with this stuff, so for now, it is difficult to write correct > multithreaded programs. The topic of this thread is: "Epic Fail" --- what does any of this speculation on how to write multi-threaded programs have to do with that? ANS-Forth was an epic fail because Elizabeth Rather declared that SwiftForth would be crowned as the new standard without fixing any of its problems, and the rest of the sheep on the ANS-Forth technical committee meekly followed. Forth-200x will be an epic fail also, and for the same reason. Why ponder the concept of multi-threaded programs if nobody is writing single-threaded programs in Forth now? So far, ANS-Forth has primarily been a leader in the field of zero-threaded programs. All of this pseudo-intellectual hand-waving about "transactional memory" etc., isn't changing the fact that ANS-Forth is an EPIC FAIL! EPIC FAIL! EPIC FAIL! EPIC FAIL! EPIC FAIL! What part of the term "epic fail" are you not grasping? You Forth-200x committee members will continue to be failures until you come to grips with the fact that ANS-Forth is an epic fail, and that there were reasons why this happened --- it wasn't just bad luck --- it was bad management.
[toc] | [prev] | [next] | [standalone]
| From | Alexander Skobelev <al.skobelev@gmail.com> |
|---|---|
| Date | 2014-04-14 22:04 -0700 |
| Message-ID | <40be0d3c-35ee-4cf1-b6e8-c65b91e5ce4f@googlegroups.com> |
| In reply to | #29642 |
On Monday, April 14, 2014 8:55:55 PM UTC+4, hughag...@yahoo.com wrote: > > ANS-Forth was an epic fail because Elizabeth Rather declared that > SwiftForth would be crowned as the new standard without fixing any of > its problems, and the rest of the sheep on the ANS-Forth technical > committee meekly followed. > Forth-200x will be an epic fail also, and for the same reason. Why > ponder the concept of multi-threaded programs if nobody is writing > single-threaded programs in Forth now? So far, ANS-Forth has primarily > been a leader in the field of zero-threaded programs. All of this > pseudo-intellectual hand-waving about "transactional memory" etc., > isn't changing the fact that ANS-Forth is an > EPIC FAIL! EPIC FAIL! EPIC FAIL! EPIC FAIL! EPIC FAIL! > What part of the term "epic fail" are you not grasping? You Forth-200x > committee members will continue to be failures until you come to grips > with the fact that ANS-Forth is an epic fail, and that there were > reasons why this happened --- it wasn't just bad luck --- it was bad > management. Hugh, wouldn't it be more productive if you published a fixed version of ANS-Forth than just claiming that the committee blindly follows directions of Elizabeth Rather? Then, you, at least, would have a basis for constructive critique of Forth-200x pointing out to you version that does the right thing. Moreover, if you had enough resources you could create a reference implementation for your Forth standard to give people a chance to taste it. Please don't take this as an attempt to taunt you. I've written what I think, even if I admit that I perhaps don't understand something well and this can be a silly idea for some reason.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-04-15 04:10 -0400 |
| Message-ID | <op.xecmbpgk6zenlw@localhost> |
| In reply to | #29655 |
On Tue, 15 Apr 2014 01:04:44 -0400, Alexander Skobelev <al.skobelev@gmail.com> wrote: > On Monday, April 14, 2014 8:55:55 PM UTC+4, hughag...@yahoo.com wrote: >> [ : Hrant Hugh rant ; Hrant Hrant Hrant ] > > Hugh, wouldn't it be more productive if you published a fixed version of > ANS-Forth than just [being antagonistic and insulting]. If he "fixes" ANS-Forth, then it's not compliant with the ANS Forth standard, and therefore not ANS-Forth ... So, obviously, ANS-Forth is unfixable. While that's true logically, at least to a warped pedant, it's also part of Hugh's self-reinforcing Forth perspective/delusion in regards to ANS being broken/biased/tainted/commercialized etc. I.e., the only thing one can do now in regards to ANS Forth clearly being so utterly broken is to complain so loudly to the Forth standard committee members that no will dare "destroy" the next version. Get it? Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Alexander Skobelev <al.skobelev@gmail.com> |
|---|---|
| Date | 2014-04-15 02:40 -0700 |
| Message-ID | <857e05b2-1c42-4d45-8e8b-0abe45139747@googlegroups.com> |
| In reply to | #29658 |
On Tuesday, April 15, 2014 12:10:27 PM UTC+4, Rod Pemberton wrote: > On Tue, 15 Apr 2014 01:04:44 -0400, Alexander Skobelev > <al..v@gmail.com> wrote: > > On Monday, April 14, 2014 8:55:55 PM UTC+4, hughag...@yahoo.com wrote: > > >> [ : Hrant Hugh rant ; Hrant Hrant Hrant ] > > > > Hugh, wouldn't it be more productive if you published a fixed > > version of ANS-Forth than just [being antagonistic and insulting]. > > If he "fixes" ANS-Forth, then it's not compliant with the ANS Forth > standard, and therefore not ANS-Forth ... So, obviously, ANS-Forth is > unfixable. While that's true logically, at least to a warped pedant, > it's also part of Hugh's self-reinforcing Forth perspective/delusion > in regards to ANS being broken/biased/tainted/commercialized etc. > I.e., the only thing one can do now in regards to ANS Forth clearly > being so utterly broken is to complain so loudly to the Forth standard > committee members that no will dare "destroy" the next version. > > Get it? Well, almost. The question is following yet. If ANS-Forth has been already broken how can it help it, if it is not be "destroyed" in the next version? It is going to remain broken in any case, isn't it? And the only way to make it "good" is to change something in it, i.e. apply some positive activity to fix its flaws. I don't believe that Hugh is able to force any member of the comittee to start working on changes he wants just constantly complaining about the standard's flaws and blaming Forth Inc.. At least, while reading c.l.f. I've got an impression that the most of the members have already a sort of immunity against his complains either ignoring him at all or just commenting with something like "That is Hugh. Don't take him seriously." So, while his posts can be interesting to novices like me, they seems to not have any value for the c.l.f. old-timers.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-04-15 06:41 -0400 |
| Message-ID | <op.xectazy46zenlw@localhost> |
| In reply to | #29661 |
On Tue, 15 Apr 2014 05:40:34 -0400, Alexander Skobelev <al.skobelev@gmail.com> wrote: > On Tuesday, April 15, 2014 12:10:27 PM UTC+4, Rod Pemberton wrote: >> On Tue, 15 Apr 2014 01:04:44 -0400, Alexander Skobelev >> <al..v@gmail.com> wrote: >> > On Monday, April 14, 2014 8:55:55 PM UTC+4, hughag...@yahoo.com wrote: >> >> [ : Hrant Hugh rant ; Hrant Hrant Hrant ] >> > >> > Hugh, wouldn't it be more productive if you published a fixed >> > version of ANS-Forth than just [being antagonistic and insulting]. >> >> If he "fixes" ANS-Forth, then it's not compliant with the ANS Forth >> standard, and therefore not ANS-Forth ... So, obviously, ANS-Forth is >> unfixable. While that's true logically, at least to a warped pedant, >> it's also part of Hugh's self-reinforcing Forth perspective/delusion >> in regards to ANS being broken/biased/tainted/commercialized etc. >> I.e., the only thing one can do now in regards to ANS Forth clearly >> being so utterly broken is to complain so loudly to the Forth standard >> committee members that no [one] will dare "destroy" the next version. >> >> Get it? > > Well, almost. > > The question is following yet. If ANS-Forth has been already broken how > can it help it, if it is not be "destroyed" in the next version? If they do nothing, it won't get worse (or better). If they do something, they might break it even more. If they do something, they definately won't fix it. I.e., pessimistic, futile, defeatist, and fear, uncertainty, doubt. He believes the ANS committee won't do the correct thing which he believes is to fix Forth. He believes they won't do that since that would break all backwards compatibility. They've gone to great lengths to preserve compatibility. So, again, this is true. > It is going to remain broken in any case, isn't it? Most likely. > And the only way to make it "good" is to change something in it, i.e. > apply some positive activity to fix its flaws. Yes. However, that breaks compatibility. > I don't believe that Hugh is able to force any member of the comittee > to start working on changes he wants just constantly complaining about > the standard's flaws and blaming Forth Inc.. True, but he already knows they won't fix Forth. He knows that they'll only patch it up, and leave many "trivial" and "historic" defects in place. I.e., you can't have a fixed Forth and have backwards compatibility. Are you beginning to see the circle? All of this is part of the self-reinforcing perspective/delusion. It's a circular logic delusion based upon a couple truths. You argue for/against one aspect, he moves to the next aspect, but all aspects are on a circle. So, the argument with him never reaches a conclusion. It continously progresses and eventually repeats. He's on the mental merry-go-round and can't, or more likely, won't get off. BTW, he's not the only one here who does this. There are a some others. Each of them has a different "wheel in the sky" topic that "keeps on turning". Fortunately, they've been "on their medications" lately. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Alexander Skobelev <al.skobelev@gmail.com> |
|---|---|
| Date | 2014-04-15 06:20 -0700 |
| Message-ID | <61a9c930-89e7-4f00-b311-315d0549f5ae@googlegroups.com> |
| In reply to | #29662 |
On Tuesday, April 15, 2014 2:41:13 PM UTC+4, Rod Pemberton wrote: > On Tue, 15 Apr 2014 05:40:34 -0400, Alexander Skobelev > <al.sk...@gmail.com> wrote: [ ... ] > > > > The question is following yet. If ANS-Forth has been already broken how > > can it help it, if it is not be "destroyed" in the next version? > > If they do nothing, it won't get worse (or better). If they do something, > they might break it even more. If they do something, they definately won't > fix it. I.e., pessimistic, futile, defeatist, and fear, uncertainty, > doubt. > > He believes the ANS committee won't do the correct thing which he believes > is to fix Forth. He believes they won't do that since that would break > all backwards compatibility. They've gone to great lengths to preserve > compatibility. So, again, this is true. > > > It is going to remain broken in any case, isn't it? > > Most likely. > > > And the only way to make it "good" is to change something in it, i.e. > > apply some positive activity to fix its flaws. > > Yes. However, that breaks compatibility. > > > I don't believe that Hugh is able to force any member of the comittee > > to start working on changes he wants just constantly complaining about > > the standard's flaws and blaming Forth Inc.. > > True, but he already knows they won't fix Forth. He knows that they'll > only patch it up, and leave many "trivial" and "historic" defects in place. > I.e., you can't have a fixed Forth and have backwards compatibility. > Are you beginning to see the circle? With the all written above the only solution to get out from the circle is seem to break compatibility and do it by yourself.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-04-15 12:21 +0000 |
| Message-ID | <2014Apr15.142133@mips.complang.tuwien.ac.at> |
| In reply to | #29655 |
Alexander Skobelev <al.skobelev@gmail.com> writes:
>Hugh, wouldn't it be more productive if you published a fixed version of
>ANS-Forth
He has announced that he will do his own standard that will correct
all the bad decisions of Forth-94 and Forth 200x, and standardize
features that these standards don't standardize. He started with
these announcements several years ago. Until now I have seen the name
("Straight Forth"), and announcements of some features and changes
from Forth-94/200x, but no specification, nor an implementation.
- 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 | Alexander Skobelev <al.skobelev@gmail.com> |
|---|---|
| Date | 2014-04-15 06:30 -0700 |
| Message-ID | <a32a972a-53c8-4836-88ac-a1cfe8879931@googlegroups.com> |
| In reply to | #29664 |
On Tuesday, April 15, 2014 4:21:33 PM UTC+4, Anton Ertl wrote:
> Alexander Skobelev writes:
> >Hugh, wouldn't it be more productive if you published a fixed version of
> >ANS-Forth
>
> He has announced that he will do his own standard that will correct
> all the bad decisions of Forth-94 and Forth 200x, and standardize
> features that these standards don't standardize. He started with
> these announcements several years ago. Until now I have seen the name
> ("Straight Forth"), and announcements of some features and changes
> from Forth-94/200x, but no specification, nor an implementation.
Not sure, but, perhaps, he still works on it, given that I've seen some posts
from him in which he has mentioned "his language". But better to wait for
comments from Hugh himself.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-04-15 20:04 -0700 |
| Message-ID | <dabdde94-daaf-4225-80f8-4264a842ce4a@googlegroups.com> |
| In reply to | #29664 |
On Tuesday, April 15, 2014 5:21:33 AM UTC-7, Anton Ertl wrote:
> Alexander Skobelev <al.skobelev@gmail.com> writes:
> >Hugh, wouldn't it be more productive if you published a fixed version of
> >ANS-Forth
>
> He has announced that he will do his own standard that will correct
> all the bad decisions of Forth-94 and Forth 200x, and standardize
> features that these standards don't standardize. He started with
> these announcements several years ago. Until now I have seen the name
> ("Straight Forth"), and announcements of some features and changes
> from Forth-94/200x, but no specification, nor an implementation.
It is not necessary for the new standard to be backwards compatible with ANS-Forth. ANS-Forth won't disappear in a puff of smoke if a new standard comes out that is incompatible. There will be a period of time in which both standards will be in use. Forthers can support both standards simultaneously and vendors will have compilers for both (not Forth Inc., of course, because their only goal is to make SwiftForth the standard and they won't accept any input from anybody else). ANS-Forth will be deprecated however, and new projects will be done in the new standard. I can't imagine any new standard being worse than ANS-Forth, which was an "epic fail" --- it is pretty much guaranteed that ANS-Forth will be left behind eventually.
The new standard would have to follow the "Asok Principle" --- it would have to be similar enough to ANS-Forth that "Asok the Intern" (from the Dilbert cartoon) could port legacy ANS-Forth code over to the new standard --- I described the Asok Principle back in 2009 when I first joined the Forth-200x mailing list, but nobody listened to me.
I really wanted Forth-200x to be the new standard, but it is just a continuation of ANS-Forth. It is totally compatible with ANS-Forth, providing only a handful of dinky incremental improvements. I lost interest in Forth-200x when you rejected my ALLOCATION and commenced to discuss N>R and NR> --- my impression of this was that Leon Wagner allows outsiders to introduce stuff like N>R and NR> for the purpose of allowing them to feel like winners, and perpetuating the charade of the standard being something other than SwiftForth wearing a crown --- but he only does this so long as their proposed code can be implemented in under 5 minutes and introduces no new thinking whatsoever.
I'm working on the compiler for my language, but I have very little time available for this because of my full-time and physically exhausting job. I'll get there eventually though. Considering that Forth-200x is moving at glacial speed, and as much backward as forward, there is no real deadline for me. I don't want to release a standards document without a working compiler completed --- I don't want to be like Forth Inc. that wrote the ANS-Forth standard for (LOCAL) at a time when they were selling a commercial compiler that crashed every time that (LOCAL) was used. I'm very much opposed to just making stuff up --- the internet has too much of that already.
On the other hand though, I would release a preliminary standards document if I thought that anybody would contribute positively to it --- it is a really big project for one guy to do alone. I often read discussions by people about issues that I hadn't considered --- an example being:
https://groups.google.com/forum/#!topic/comp.lang.forth/SaC_e4frlxs
Somebody named Lauri Alanko had the idea of compatibility between various devices (OPEN-FILE etc. would work with the keyboard and the serial line as well as files). There was something like that in UR/Forth, but I had forgotten about it. Writing a standards document is difficult because I have to think of stuff like this that I hadn't necessarily thought about before. C.L.F. is not really the best place to discuss Forth though (Marcel suggested that she read Wikipedia, and Elizabeth gave her the usual sales-pitch for over-priced and largely useless Forth Inc. books). Her point was pretty minor, but it is just an example of the myriad issues that have to be considered when designing a language. Ultimately, I suppose that I will just have to figure everything out myself.
[toc] | [prev] | [next] | [standalone]
| From | Alexander Skobelev <al.skobelev@gmail.com> |
|---|---|
| Date | 2014-04-15 23:50 -0700 |
| Message-ID | <027731fa-eac6-46b1-bd25-c9c4bab5e4f1@googlegroups.com> |
| In reply to | #29673 |
On Wednesday, April 16, 2014 7:04:00 AM UTC+4, hughag...@yahoo.com wrote:
> On Tuesday, April 15, 2014 5:21:33 AM UTC-7, Anton Ertl wrote:
> > Alexander Skobelev writes:
> > >Hugh, wouldn't it be more productive if you published a fixed version of
> > >ANS-Forth
> >
> > He has announced that he will do his own standard that will correct
> > all the bad decisions of Forth-94 and Forth 200x, and standardize
> > features that these standards don't standardize. He started with
> > these announcements several years ago. Until now I have seen the name
> > ("Straight Forth"), and announcements of some features and changes
> > from Forth-94/200x, but no specification, nor an implementation.
>
[ ... ]
> I'm working on the compiler for my language, but I have very little
> time available for this because of my full-time and physically
> exhausting job. I'll get there eventually though. Considering that
> Forth-200x is moving at glacial speed, and as much backward as
> forward, there is no real deadline for me. I don't want to release a
> standards document without a working compiler completed --- I don't
> want to be like Forth Inc. that wrote the ANS-Forth standard for
> (LOCAL) at a time when they were selling a commercial compiler that
> crashed every time that (LOCAL) was used. I'm very much opposed to
> just making stuff up --- the internet has too much of that already.
>
> On the other hand though, I would release a preliminary standards
> document if I thought that anybody would contribute positively to it
> --- it is a really big project for one guy to do alone. I often read
> discussions by people about issues that I hadn't considered --- an
> example being:
>
> https://groups.google.com/forum/#!topic/comp.lang.forth/SaC_e4frlxs
>
> Somebody named Lauri Alanko had the idea of compatibility between
> various devices (OPEN-FILE etc. would work with the keyboard and the
> serial line as well as files). There was something like that in
> UR/Forth, but I had forgotten about it. Writing a standards document
> is difficult because I have to think of stuff like this that I hadn't
> necessarily thought about before. C.L.F. is not really the best place
> to discuss Forth though (Marcel suggested that she read Wikipedia, and
> Elizabeth gave her the usual sales-pitch for over-priced and largely
> useless Forth Inc. books). Her point was pretty minor, but it is just
> an example of the myriad issues that have to be considered when
> designing a language. Ultimately, I suppose that I will just have to
> figure everything out myself.
I sincerely wish you success in this undertaking.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-04-15 21:31 -1000 |
| Message-ID | <P56dnehz0vROrNPOnZ2dnUVZ_vidnZ2d@supernews.com> |
| In reply to | #29676 |
On 4/15/14 8:50 PM, Alexander Skobelev wrote: > On Wednesday, April 16, 2014 7:04:00 AM UTC+4, hughag...@yahoo.com wrote: ... >> I don't >> want to be like Forth Inc. that wrote the ANS-Forth standard for >> (LOCAL) at a time when they were selling a commercial compiler that >> crashed every time that (LOCAL) was used. I'm very much opposed to >> just making stuff up --- the internet has too much of that already. I am thoroughly sick of Hugh's flat-out lies. (LOCAL) was proposed by Don Colburn, of Creative Solutions. His MacForth systems were the first to implement any form of locals, in the 1980's, and when his proposal was presented there were over 50,000 copies of his system in use. The TC opted to support this existing, successful implementation in preference to inventing a new one. FORTH, Inc. didn't implement any form of locals until several years after Forth94 was adopted. > I sincerely wish you success in this undertaking. Don't hold your breadh. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-04-16 05:55 -0700 |
| Message-ID | <2fcba47f-25f2-43a0-9926-2f4c36e05e5d@googlegroups.com> |
| In reply to | #29678 |
On Wednesday, April 16, 2014 12:31:29 AM UTC-7, Elizabeth D. Rather wrote: > On 4/15/14 8:50 PM, Alexander Skobelev wrote: > > > On Wednesday, April 16, 2014 7:04:00 AM UTC+4, hughag...@yahoo.com wrote: > ... > >> I don't > >> want to be like Forth Inc. that wrote the ANS-Forth standard for > >> (LOCAL) at a time when they were selling a commercial compiler that > >> crashed every time that (LOCAL) was used. I'm very much opposed to > >> just making stuff up --- the internet has too much of that already. > I am thoroughly sick of Hugh's flat-out lies. (LOCAL) was proposed by > Don Colburn, of Creative Solutions. His MacForth systems were the first > to implement any form of locals, in the 1980's, and when his proposal > was presented there were over 50,000 copies of his system in use. The TC > opted to support this existing, successful implementation in preference > to inventing a new one. FORTH, Inc. didn't implement any form of locals > until several years after Forth94 was adopted. SwiftForth version-2, which I paid almost $500 for in the late 1990s, crashes whenever (LOCAL) is used. You are quite correct that, "FORTH, Inc. didn't implement any form of locals until several years after Forth94 was adopted," and you were unable to succeed at this. You were the chairperson of the ANS-Forth committee --- so you standardized (LOCAL) at a time when you were unable to implement it. It is irrelevant who proposed (LOCAL) --- you were responsible as the chairperson for the ANS-Forth committee to understand the standard --- but your commercial compiler several years later crashed when (LOCAL) was used. Apparently you didn't implement locals for several years after your standard was adopted because you don't use local variables --- and you didn't notice that SwiftForth crashed when (LOCAL) was used, because you never tested the use of locals even once. I'm not the liar here --- you are --- I remember Jeff Fox telling me in private correspondence that you are a deeply dishonest person, and that is what you are. This is not the first time that I've seen you rewrite history. I said that PolyForth for the 16-bit x86 MS-DOS was limited to 64K --- not just the application program and the application data, but the compiler, dictionary, editor, etc. --- and that this implies a failure of Forth Inc. to understand the 8086 segment registers. You have repeatedly said that PolyForth for the 80386 supported more than 64K --- but that ignores the many many years when the 8088 and 80286 were in use --- by the time that the 80386 came out, Forth had such a bad reputation as to be effectively dead, and you are personally to blame! > > I sincerely wish you success in this undertaking. > > Don't hold your breadh. This cross-compiler that I'm describing is just MFX that I wrote for Testra. I used UR/Forth has the host Forth at that time, and this time I will write my own HostForth that will be 64-bit --- but the basic cross-compiler was completed almost 20 years ago, so I know what I'm doing. > Cheers, > > Elizabeth Aloha! What is the Hawaiian word for "lying bitch?"
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2014-04-16 14:50 +0100 |
| Message-ID | <lim1qi$urn$1@dont-email.me> |
| In reply to | #29682 |
on 16/04/2014 13:55:29, Mr Ranty wrote: > > What is the Hawaiian word for "lying bitch?" > Aguilar.
[toc] | [prev] | [next] | [standalone]
| From | Alexander Skobelev <al.skobelev@gmail.com> |
|---|---|
| Date | 2014-04-16 06:06 -0700 |
| Message-ID | <938394d1-2a62-40ea-9c4f-e97042ca6c3a@googlegroups.com> |
| In reply to | #29678 |
On Wednesday, April 16, 2014 11:31:29 AM UTC+4, Elizabeth D. Rather wrote: > On 4/15/14 8:50 PM, Alexander Skobelev wrote: > > > On Wednesday, April 16, 2014 7:04:00 AM UTC+4, hughag...@yahoo.com wrote: > ... > > I sincerely wish you success in this undertaking. > > Don't hold your breadh. In no case. I just would be glad, if Hugh succeed. If he fails... well, sometimes I think that construction is more valuable than programming. :)
[toc] | [prev] | [next] | [standalone]
Page 4 of 19 — ← Prev page 1 2 3 [4] 5 6 … 19 Next page →
Back to top | Article view | comp.lang.forth
csiph-web