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 8 of 22 — ← Prev page 1 … 6 7 [8] 9 10 … 22 Next page →
| From | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-04-26 08:50 -0400 |
| Subject | Re: @ and optimization |
| Message-ID | <op.xexcmiim6zenlw@localhost> |
| In reply to | #29832 |
On Fri, 25 Apr 2014 13:22:30 -0400, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >> 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. 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). Coherency means what is in the cache matches what is in memory. With two reads to the same address, if memory hasn't changed any, then both "foo @" will be from the cache and have the same value. With two reads to the same address, if memory has changed between reads, e.g., perhaps via memory mapped hardware, then the first and second "foo @" will have the different values. The first will be loaded from the cache. The second may be loaded from the memory or loaded from an invalidated and re-loaded cache, depending on the design of the coherency logic. If what's in the cache doesn't match memory for the second read, then the microprocessor's coherency logic is *broken*. Excluding the improved memory speed of caching, the caching operation should function as if there was no cache present, i.e., as if the read or write was directly to memory without buffering, without memory read optimization, etc. If the memory changes between reads, the processor can update the cache at various points in time depending on the design. E.g., at the hardware write to memory, at the next read, etc. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2014-04-26 22:52 +0100 |
| Subject | Re: @ and optimization |
| Message-ID | <ljh9rb$1j8$1@dont-email.me> |
| In reply to | #29861 |
on 26/04/2014 13:50:35, "Rod Pemberton" wrote: > On Fri, 25 Apr 2014 13:22:30 -0400, Anton Ertl > <anton@mips.complang.tuwien.ac.at> wrote: >> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: > >>> 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. 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). > > Coherency means what is in the cache matches what is in memory. Coherency says nothing about what value is in memory. Coherency ensures that the value of an item retrieved from non-disjoint locations by a coupled processor is the most up-to-date value. [snip]
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-04-26 20:33 -0400 |
| Subject | Re: @ and optimization |
| Message-ID | <op.xex86wef6zenlw@localhost> |
| In reply to | #29889 |
On Sat, 26 Apr 2014 17:52:43 -0400, Alex McDonald <blog@rivadpm.com> wrote: > on 26/04/2014 13:50:35, "Rod Pemberton" wrote: >> On Fri, 25 Apr 2014 13:22:30 -0400, Anton Ertl >> <anton@mips.complang.tuwien.ac.at> wrote: >>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>>> 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. 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). >> >> Coherency means what is in the cache matches what is in memory. > > Coherency says nothing about what value is in memory. Coherency ensures > that the value of an item retrieved from non-disjoint locations by a > coupled processor is the most up-to-date value. > http://en.wikipedia.org/wiki/Cache_coherency RP
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2014-04-27 11:53 +0100 |
| Subject | Re: @ and optimization |
| Message-ID | <ljinja$g3g$1@dont-email.me> |
| In reply to | #29892 |
on 27/04/2014 01:34:01, "Rod Pemberton" wrote: > On Sat, 26 Apr 2014 17:52:43 -0400, Alex McDonald <blog@rivadpm.com> > > wrote: >> on 26/04/2014 13:50:35, "Rod Pemberton" wrote: > > wrote: >>> On Fri, 25 Apr 2014 13:22:30 -0400, Anton Ertl > > wrote: >>> <anton@mips.complang.tuwien.ac.at> wrote: > > wrote: >>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: > wrote: > >>>>> 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. 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). >>> >>> Coherency means what is in the cache matches what is in memory. >> >> Coherency says nothing about what value is in memory. Coherency ensures >> that the value of an item retrieved from non-disjoint locations by a >> coupled processor is the most up-to-date value. >> > > http://en.wikipedia.org/wiki/Cache_coherency > > > RP > (On the presumption that you believe the wiki supports your incorrect assertion.) If you're interested then any decent set of articles on MESI MOESI or MESIF protocols will help. You could also read up about memory snooping and write back cahces. There you would find how processor caches work, and how your description of their operation is wrong.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-04-28 01:05 -0400 |
| Subject | Re: @ and optimization |
| Message-ID | <op.xe0ge1gx6zenlw@localhost> |
| In reply to | #29911 |
On Sun, 27 Apr 2014 06:53:30 -0400, Alex McDonald <blog@rivadpm.com> wrote: > on 27/04/2014 01:34:01, "Rod Pemberton" wrote: >> On Sat, 26 Apr 2014 17:52:43 -0400, Alex McDonald <blog@rivadpm.com >> wrote: >>> on 26/04/2014 13:50:35, "Rod Pemberton" wrote: >>>> Coherency means what is in the cache matches what is in memory. >>> >>> Coherency says nothing about what value is in memory. Coherency ensures >>> that the value of an item retrieved from non-disjoint locations by a >>> coupled processor is the most up-to-date value. >>> >> >> http://en.wikipedia.org/wiki/Cache_coherency >> > > (On the presumption that you believe the wiki supports your incorrect > assertion.) The wiki stated what I stated. It would be a contradiction for only one to be correct. > If you're interested then any decent set of articles on MESI MOESI or > MESIF protocols will help. You could also read up about memory snooping > and write back cahces. There you would find how processor caches work, > and how your description of their operation is wrong. I know how processor caches work from the software level all the way down to the integrated circuit level, although perhaps not every design, or more recent ones. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> |
|---|---|
| Date | 2014-04-25 21:34 +0100 |
| Subject | Re: @ and optimization |
| Message-ID | <bofll9p0bnb8mlf6nfb216g1t3mv7i5jln@4ax.com> |
| In reply to | #29822 |
On Fri, 25 Apr 2014 06:13:56 -0500, Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: > >IMO, the Right Way to do it is to have explicit read and write >barriers. These would insert barrier instructions on machines that >need them and an optimization barrier on machines that don't. 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. > This IMO introduces what appears an extra layer of unnecessary complexity. Yes, a programmer needs to know their hardware. Yes, they need to know their language of choice. But what you're suggesting would require that they also know intimately about the inner workings of their optimiser. Not sure I agree with this. IMO an optimiser should be limited to doing transformations that have *guaranteed* no side-effects, i.e. equivalent transformations. If that means doing fewer optimisations automatically, fine. Where there MAY be are further opportunities for optimisation, but "at your own risk" because they involve non-equivalent code transformations, why not adopt the philosophy that the optimiser be given an 'advisory mode' that can be switched on if the programmer wants further recommendations made. This would be akin to various levels of warning modes. Ba compiler, IMO, should not be permitted to automatically change code in a way that is not an equivalent transformation. What I cannot understand is, if given a choice, who want to use something more complicated and potentially unreliable over a simpler, predictable and reliable optimiser, even if the simpler optimiser did less? Most casual users are risk averse and would not. And most advanced users would rather have the recommendations made and then use their experience to go forward. Adopting the other approach --- optimise anything even at the risk of breaking stuff, and require the programmer to have to code even more defensively against yet another source of uncertainty --- seems to me to run counter to all of the cautionary quotes around code optimisation: "More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason — including blind stupidity." — W.A. Wulf "Bottlenecks occur in surprising places, so don't try to second guess and put in a speed hack until you have proven that's where the bottleneck is." — Rob Pike (part of the UNIX / C team at Bell Labs) "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only after that code has been identified" — Donald Knuth, Structured Programming with Goto Statements. Computing Surveys 6:4 (1974), 261–301 And again from Knuth: "Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered." (Knuth, same paper as above) - Assad
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-04-25 13:37 -0700 |
| Subject | Re: @ and optimization |
| Message-ID | <7xvbtxf8m9.fsf@ruckus.brouhaha.com> |
| In reply to | #29835 |
Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> writes: > IMO an optimiser should be limited to doing transformations that have > *guaranteed* no side-effects, i.e. equivalent transformations. Interesting suggestion. Can you list any transformations that are *guaranteed* no side-effects? I'm having a hard time thinking of any, given the lack of specification here of what a side effect is.
[toc] | [prev] | [next] | [standalone]
| From | Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> |
|---|---|
| Date | 2014-04-25 22:03 +0100 |
| Subject | Re: @ and optimization |
| Message-ID | <tfill9dj4dbvdkvmc9rsc4oeint4r39fhv@4ax.com> |
| In reply to | #29836 |
On Fri, 25 Apr 2014 13:37:50 -0700, Paul Rubin <no.email@nospam.invalid> wrote: >Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> writes: >> IMO an optimiser should be limited to doing transformations that have >> *guaranteed* no side-effects, i.e. equivalent transformations. > >Interesting suggestion. Can you list any transformations that are >*guaranteed* no side-effects? I'm having a hard time thinking of >any, given the lack of specification here of what a side effect is. Sure. Here are three. * Dead code elimination (by definition). * Address Optimisation (since you're just changing the location of global variables in memory) * Constant Folding (evaluate an expression at compile time instead of run-time) What criteria? By side-effect, I mean something that fails in an edge-case. By equivalent transformation of the code, I mean that an optimisation should be rejected (or marked for recommendation but not automatic implementation ) if there is a situation in which doing that transformation would alter the behaviour of the untransformed code and thereby produce a different result. AFAIK this is part of the definition: "Compiler optimization is the process of improving the quality of object code without changing the results it produces." http://en.wikipedia.org/wiki/History_of_compiler_construction#Optimizing_compilers - Assad
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-04-26 15:38 +0000 |
| Subject | Re: @ and optimization |
| Message-ID | <2014Apr26.173859@mips.complang.tuwien.ac.at> |
| In reply to | #29836 |
Paul Rubin <no.email@nospam.invalid> writes:
>Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> writes:
>> IMO an optimiser should be limited to doing transformations that have
>> *guaranteed* no side-effects, i.e. equivalent transformations.
>
>Interesting suggestion. Can you list any transformations that are
>*guaranteed* no side-effects?
Using the commutative law. Using the associative and distributive
laws with modulo arithmetics (not with FP, saturating, or
trap-on-overflow arithmetics). Or equivalent stack manipulations.
E.g.:
SWAP + => +
1+ 2 + => 3 +
SWAP DROP => NIP
>I'm having a hard time thinking of
>any, given the lack of specification here of what a side effect is.
My guess is that he meant cases where there are no circumstances under
which the transformation causes an observable 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 | Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> |
|---|---|
| Date | 2014-04-26 17:24 +0100 |
| Subject | Re: @ and optimization |
| Message-ID | <14mnl9dbrfs3q5poo2jp4klm89clfkb103@4ax.com> |
| In reply to | #29872 |
On Sat, 26 Apr 2014 15:38:59 GMT, anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: > >My guess is that he meant cases where there are no circumstances under >which the transformation causes an observable difference. > Same criteria as you and Bernd are expressing. Bernd calls it semantical equivalence | In any case, to perform an optimization, you need a proof of semantical | equivalence. Anton refers to different behaviour | If it produces a different behaviour than the | original code, it's not a legitimate thing for a compiler to do. I wrote in my reply to Paul. >> By side-effect, I mean something that fails in an >> edge-case. By equivalent transformation of the code, I mean that an >> optimisation should be rejected (or marked for recommendation but not >> automatic implementation ) if there is a situation in which doing that >> transformation would alter the behaviour of the untransformed code and >> thereby produce a different result. >> >> AFAIK this is part of the definition: >> "Compiler optimization is the process of improving the quality of >> object code without changing the results it produces." >> http://en.wikipedia.org/wiki/History_of_compiler_construction#Optimizing_compilers - Assad
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-04-26 04:48 -0500 |
| Subject | Re: @ and optimization |
| Message-ID | <AJadnYBfbbJDHcbOnZ2dnUVZ_sqdnZ2d@supernews.com> |
| In reply to | #29835 |
Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> wrote: > On Fri, 25 Apr 2014 06:13:56 -0500, Andrew Haley > <andrew29@littlepinkcloud.invalid> wrote: > >>IMO, the Right Way to do it is to have explicit read and write >>barriers. These would insert barrier instructions on machines that >>need them and an optimization barrier on machines that don't. 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. > > This IMO introduces what appears an extra layer of unnecessary > complexity. > > Yes, a programmer needs to know their hardware. Yes, they need to > know their language of choice. But what you're suggesting would > require that they also know intimately about the inner workings of > their optimiser. Not sure I agree with this. That's not my intention. I'm suggesting a way that programs can be made portable. My suggestion is a simple way to do that and achieve equivalent behaviour on different hardware. > IMO an optimiser should be limited to doing transformations that > have *guaranteed* no side-effects, i.e. equivalent transformations. > If that means doing fewer optimisations automatically, fine. It's worse than that. If you want all memory operations to be visible to alll theads in the order they were written, i.e. sequential consistency, you're going to have to emit barriers at possibly every fetch and store, with increased bus traffic and power consumption. Consider a system with loosely-coupled shared memory and many cores. Probably only a few memory accesses in your program need to be synchronized, but you'd be forcing synchronization across the whole system for every fetch and store. That would make Forth useless for programming such a system. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> |
|---|---|
| Date | 2014-04-26 11:09 +0100 |
| Subject | Re: @ and optimization |
| Message-ID | <821nl91fgct02l7pr4rq3tkdm2n6gd1ro8@4ax.com> |
| In reply to | #29852 |
On Sat, 26 Apr 2014 04:48:14 -0500, Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: >Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> wrote: >> On Fri, 25 Apr 2014 06:13:56 -0500, Andrew Haley >> <andrew29@littlepinkcloud.invalid> wrote: >> >>>IMO, the Right Way to do it is to have explicit read and write >>>barriers. These would insert barrier instructions on machines that >>>need them and an optimization barrier on machines that don't. 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. >> >> This IMO introduces what appears an extra layer of unnecessary >> complexity. >> >> Yes, a programmer needs to know their hardware. Yes, they need to >> know their language of choice. But what you're suggesting would >> require that they also know intimately about the inner workings of >> their optimiser. Not sure I agree with this. > >That's not my intention. I'm suggesting a way that programs can be >made portable. My suggestion is a simple way to do that and achieve >equivalent behaviour on different hardware. Ok, but then wouldn't Anton's suggestion then be equivalent but better: I believe he is suggesting that the compiler should not turn foo @ foo @ into foo @ dup unless explicitly permitted to do so by the programmer. This is better because a person who is unaware of the issue has a slight penalty, but has his code preserved exactly as he wrote it -- so there can be no quibble about non-equivalent transformations. And if he is aware of the issue, then he has the choice to code it himself properly or tell the compiler to do it for him. Throughout, it is the programmer that retains the control. - Assad
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-04-28 21:24 -0700 |
| Subject | Re: @ and optimization (was: Epic Fail) |
| Message-ID | <c6e9b4eb-5c37-4e2e-a15e-93ada3f2d2c8@googlegroups.com> |
| In reply to | #29821 |
On Friday, April 25, 2014 1:40:47 AM UTC-7, Anton Ertl wrote: > In particular, optimizing @ has come up a number of times over the > years. One idea I had was @CONST, which would be applicable if we > knew that the data at the address will never change, e.g.: > > : constant ( n -- ) > create , > does> > @const ; > > Another idea (from Stephen Pelc) is to declare certain memory areas as > read-only, e.g.: > > : constant ( n -- ) > create here swap , 1 cells read-only > does> > @ ; > > That is good for data that is in memory permanently. I avoid this whole problem in my novice package (which is ANS-Forth) by using :NAME and compiling literal data with LIT, --- how easy is that? --- by comparison, in VFX, Pelc abandons ANS-Forth compatibility with his compile-time directive to indicate which data is constant, just so that he can stick with CREATE DOES> (and why he wants to stick with CREATE DOES> I don't know, as it has other problems as well). I pointed out this inefficiency of CREATE DOES> fetching constant data at run-time way back in 2009 or 2010 when I first wrote the novice package, and everybody just said that my code "sucks" and that I don't know how CREATE DOES> works --- now in 2014 you are still speculating on how to solve the problem that I solved many years ago.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-04-24 19:17 +0000 |
| Message-ID | <53596331$0$27134$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #29807 |
In article <2014Apr24.191024@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>"Rod Pemberton" <dont_use_email@xnothavet.cqm> writes:
>>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"?
>
>Selectively?
>
>As a programmer, I just write "foo @ foo @" if I want two loads from
>memory, and "foo @ dup" if I want one. As a compiler writer, I just
>mark @ as one of the words where common subexpression elimination (if
>I implement it; seems questionable in Forth) is not applicable.
Seems a fat looser to me. Just today I wrote:
"
VARIABLE P
\ Find the power of `` P '' occurring in the M th binomial index.
: #power >R N @ P @ #f N @ R@ - P @ #f - R> P @ #f - check ;
"
Putting P in a register seems indicated. Moreover, if #power is inlined,
the register must remain valid. A big win.
Instead I would have
: poke-hardware foo @ ; OPTIMIZED
OPTIMIZED to the optimiser means that it is optimised as good as
possible, and that it should leave poke-hardware alone.
(Or call it FORBID-INLINE , whatever).
>
>>1) disable all pointer based optimizations to prevent compiler
>>optimization errors. (Didn't you just have a large rant on
>>erroneous optimizations in C? ...)
>
>Not sure what "pointer"-based optimizations you have in mind, but yes,
>I would not "optimize" a @ away.
Pointer based optimisation must be done only if there is a no-aliasing
guarantee. This guarantee can be had by code analysis, or (like in
FORTRAN) it can be given by the user. Leaving out pointer optimisation
seems a fat looser.
>
>>2) implement a minimal type system in the optimizer so that when
>>it recognizes "dup" in "foo @ dup" it can determine that the stack
>>value is a pointer and do the opposite of optimizing, by converting
>>"dup" into "foo @".
>
>What would be the point of that? If the programmer writes "foo @
>dup", the compiler should produce only one memory load.
And if you go that way, you end up with a 1Gbyte optimiser.
>
>- anton
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 | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-04-25 08:27 +0000 |
| Message-ID | <2014Apr25.102739@mips.complang.tuwien.ac.at> |
| In reply to | #29810 |
albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
>In article <2014Apr24.191024@mips.complang.tuwien.ac.at>,
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>As a programmer, I just write "foo @ foo @" if I want two loads from
>>memory, and "foo @ dup" if I want one. As a compiler writer, I just
>>mark @ as one of the words where common subexpression elimination (if
>>I implement it; seems questionable in Forth) is not applicable.
>
>Seems a fat looser to me. Just today I wrote:
>"
> VARIABLE P
> \ Find the power of `` P '' occurring in the M th binomial index.
> : #power >R N @ P @ #f N @ R@ - P @ #f - R> P @ #f - check ;
>"
>
>Putting P in a register seems indicated.
Then do it. Forth gives you various features that can be mapped to
registers easily, e.g., stack items and locals and (without
multi-threading) VALUEs (or with multi-threading, a thread-local
variant of VALUEs). VARIABLEs are not one of them. E.g., you could
fetch P once and put the result in a local:
: #power P @ { p } >R N @ p #f N @ R@ - p #f - R> p #f - check ;
My recommendation would be to pass parameters on the stack though,
instead of through variables. Then that works, too:
> Moreover, if #power is inlined,
>the register must remain valid. A big win.
If you write bubble-sort tomorrow, don't expect the optimizer to
change it into quicksort. Forth allows you to write quicksort. You
don't need the optimizer for that.
>>What would be the point of that? If the programmer writes "foo @
>>dup", the compiler should produce only one memory load.
>
>And if you go that way, you end up with a 1Gbyte optimiser.
What's that supposed to mean?
- 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-25 23:44 +0200 |
| Message-ID | <ljekv2$ttb$1@online.de> |
| In reply to | #29820 |
Anton Ertl wrote: >>>What would be the point of that? If the programmer writes "foo @ >>>dup", the compiler should produce only one memory load. >> >>And if you go that way, you end up with a 1Gbyte optimiser. > > What's that supposed to mean? I'm not sure what he means, but the "volatile problem" (as Stephen had named it) is that @ is not a predictable operation in general. I.e. it does not have the referential transparency property it needs to have if you want to replace it by its value (this is something you do on CSE). In any case, to perform an optimization, you need a proof of semantical equivalence. foo @ foo @ is semantically equivalent to foo @ dup if and only if foo is referentially transparent. This is only the case when it is a) real memory (as opposed to e.g. a memory mapped register of some hardware) and b) only accessed by a single thread. If you can prove that, go ahead and optimize. If the task creation is actually part of the language, you could in fact prove that some memory regions are only used by a single thread, and then optimize those. This part might create a bigger optimizer, the "@ results are irreproducible" stuff isn't making the optimizer large. If you want to help the optimizer, add a way to mark memory regions or passed pointers as "constant". When fetching from such a region, @ is allowed to treat the result as referentially transparent, i.e. arbitrary reordering is allowed, it doesn't matter if there is aliasing, and so on. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | stephenXXX@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2014-04-26 14:37 +0000 |
| Message-ID | <535bac58.251218659@news.demon.co.uk> |
| In reply to | #29617 |
On Sun, 13 Apr 2014 23:44:11 +0200, Bernd Paysan <bernd.paysan@gmx.de> wrote: >There are some corner cases, which Stephen called "the volatile issue": Is > >foo @ foo @ > >identical to > >foo @ dup I'm amazed that this discussion has lasted so long. In order to give it a bit of context, the original problem was noted by Andrew and occurred because earlier versions of x86 VFX converted foo @ dup into foo @ foo @ This occurs because the x86 has a limited number of registers *and* has a memory to register architecture. For example, you can add from memory to to a register. By defining a memory fetch as a data resource on the stack, DUP in the compiler just duplicates the fetch. Hence, foo @ dup becomes foo @ foo @ >The problem is still there, this is apparently difficult for VFX to fix. >The code looks a bit different: > >variable foo >: wait ( -- result ) foo @ begin foo @ tuck <> until ; > >The loop compiles to > >( 080BF350 3B1D40240A08 ) CMP EBX, [080A2440] >( 080BF356 8B1D40240A08 ) MOV EBX, [080A2440] >( 080BF35C 74F2 ) JZ/E 080BF350 In the current development version, the loop compiles to: ( 004CA780 8B151C244600 ) MOV EDX, [0046241C] ( 004CA786 3BDA ) CMP EBX, EDX ( 004CA788 8BDA ) MOV EBX, EDX ( 004CA78A 74F4 ) JZ/E 004CA780 One more instruction, but only one memory reference and two bytes shorter. On a related topic, it would be sensible to have an I/O operation that cannot be optimised away and cannot be reordered. Many Forth systems used PC@, PW@ and P@ to refer to x86 I/O ports. Perhaps MMC@, MMW@ ... for memory mapped I/O. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-04-13 15:04 -0700 |
| Message-ID | <5cb167bf-1408-42d5-b3e9-4b5084b211d2@googlegroups.com> |
| In reply to | #29616 |
On Sunday, April 13, 2014 10:42:54 AM UTC-7, Assad Ebrahim wrote: > (B2) We're actually not all that interested in C anyway --- what we > would really like is to be able to take *any* language, transform it > to a machine independent intermediate language, and then write out > 'optimised' code to any given target machine. So what we're after is > a universal middle-language, with reasonably sound translators from C, > Fortran, C++, Objective-C, even Java, maybe even Python, into it, and > then reasonably sound translators from this middle language into any > of a vast number of machine languages. This is what C-- was designed to do. I'm on the mailing list, which is dead now. The designers are not supporting C-- anymore because they lost their funding --- you may be interested in picking up the baton. In regard to Forth-like languages, there is Cat --- this was also designed more to be an intermediate language such as you are describing, rather than something that people would write manually.
[toc] | [prev] | [next] | [standalone]
| From | Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> |
|---|---|
| Date | 2014-04-26 09:58 +0100 |
| Message-ID | <9ssml9phf0dqnh6drjve8igb4jsqkitmuj@4ax.com> |
| In reply to | #29618 |
On Sun, 13 Apr 2014 15:04:47 -0700 (PDT), hughaguilar96@yahoo.com wrote: >On Sunday, April 13, 2014 10:42:54 AM UTC-7, Assad Ebrahim wrote: >> (B2) We're actually not all that interested in C anyway --- what we >> would really like is to be able to take *any* language, transform it >> to a machine independent intermediate language, and then write out >> 'optimised' code to any given target machine. So what we're after is >> a universal middle-language, with reasonably sound translators from C, >> Fortran, C++, Objective-C, even Java, maybe even Python, into it, and >> then reasonably sound translators from this middle language into any >> of a vast number of machine languages. > >This is what C-- was designed to do. I'm on the mailing list, which is dead now. The designers are not supporting C-- anymore because they lost their funding --- you may be interested in picking up the baton. > >In regard to Forth-like languages, there is Cat --- this was also designed more to be an intermediate language such as you are describing, rather than something that people would write manually. Actually, I wrote (B1) and (B2) as simple statements of what I see as two diametrically opposed points of view. B1 expresses a position that is closer to Bernd and Anton's point of view. B2 is closer to Andrew's and the current GCC's point of view. My point of view is, incidentally, closer to B1 ---- I would rather have C return to its former heritage of a portable assembler, with a relatively stable C compiler that does some non-hazardous code optimisations, but views its mission as portable assembly, not fancy universal language compiler. So while it's interesting to read your take on C-- and Cat, I would be more likely to participate in a move to return C back to its original heritage. - Assad
[toc] | [prev] | [next] | [standalone]
| From | Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> |
|---|---|
| Date | 2014-04-26 10:16 +0100 |
| Message-ID | <s0uml955qbtk3tu9guvkktnecejcgfcfvh@4ax.com> |
| In reply to | #29848 |
On Sat, 26 Apr 2014 09:58:11 +0100, Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> wrote: Apologies -- I didn't quote myself properly (!)... corrected now below. > >Actually, I wrote (A1-A3) and (B1-B3) > as simple statements of what I see as >two diametrically opposed points of view. See A1-A3 below from the original post: >> On Sun, 13 Apr 2014 18:42 GMT, 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 >>> >>> (A3) we'd rather agree that if we want to improve code beyond what a >>> non-libertine compiler could legitimately do, then we must take on >>> that further improvement ourselves using profilers and targeted >>> improvements ourselves. >>> So now: A1-A3... > > expresses a position that is closer to Bernd and Anton's point of >view. > B1-B3... > is closer to Andrew's and the current GCC's point of view. > >My point of view is, incidentally, closer to A1-A3, i.e. >I would rather have C return to its former heritage of a portable assembler, with a >relatively stable C compiler that does some non-hazardous code >optimisations, but views its mission as portable assembly, not fancy >universal language compiler. > >So while it's interesting to read your take on C-- and Cat, I would be >more likely to participate in a move to return C back to its original >heritage. > >- Assad
[toc] | [prev] | [next] | [standalone]
Page 8 of 22 — ← Prev page 1 … 6 7 [8] 9 10 … 22 Next page →
Back to top | Article view | comp.lang.forth
csiph-web