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 20 of 22 — ← Prev page 1 … 18 19 [20] 21 22 Next page →
| From | Laurent Laborde <kerdezixe@gmail.com> |
|---|---|
| Date | 2014-05-01 04:04 -0700 |
| Message-ID | <7e959357-0e56-40bc-8947-33550a1c828f@googlegroups.com> |
| In reply to | #30024 |
On Thursday, May 1, 2014 3:33:41 AM UTC+2, Bernd Paysan wrote: > Laurent Laborde wrote: > > We had this discussion over and over again. When Perl was the hot language > of the year, we had people here who told us that Forth would be better off > if it was more like Perl. With regexps and with a Perl-like library server > full of ready-made stuff. Fortunately, today, Perl is pretty much a > phenomenon of the past. And they were right, isn't it fun ? ruby -> gem python -> pip scala -> sbt java -> maven nodejs -> npm linux -> apt-get / yum / rpm / aptitude / ... clojure -> Leiningen haskell -> Cabal And so on.... You're full of anger and i try to keep it friendly. The IT is evolving faster than you, me, everyone. It mean that : most of our knowledge become a waste over time. You get 1TFlops (yes, tera) of pure awesomeness in a 200$ gfx card. You have a 700Mhz SOC with 256MB RAM on a $30 Raspberry Pi. Yes, it's sad that my knowledge of internal CPU architecture is useless. But i'd better be depressed about it than vengeful against random internet stranger. -- Ker2x
[toc] | [prev] | [next] | [standalone]
| From | Laurent Laborde <kerdezixe@gmail.com> |
|---|---|
| Date | 2014-04-30 16:53 -0700 |
| Message-ID | <a2b7c8fb-87e0-4c7f-b348-7f7011751b80@googlegroups.com> |
| In reply to | #30018 |
On Wednesday, April 30, 2014 11:30:17 PM UTC+2, Bernd Paysan wrote: > > Yes, you can now buy a cheap > multi-core multi-GHz CPU with gigabytes of memory, and then run a program > that runs about as good and fast as 20 years ago a program ran on a MHz CPU > with a few hundred kilobytes of memory. Yeah, you couldn't write the code > back then... 20 years ago ? Hummm, my Atari ST was already old but i really loved it and asm 68k was fun :) there was already high level language. Let's say 30 years ago, that's when i learned code, on an Oric Atmos 48k :D -- Ker2x
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-05-01 03:56 -0500 |
| Message-ID | <Dd-dnbrMs5vekf_OnZ2dnUVZ_sOdnZ2d@supernews.com> |
| In reply to | #30018 |
Bernd Paysan <bernd.paysan@gmx.de> wrote: > Laurent Laborde wrote: > >> On Tuesday, April 29, 2014 11:13:30 PM UTC+2, Bernd Paysan wrote: >>> Laurent Laborde wrote: >>> >>>> The average programmer/manager/CTO : yes. >>> >>> The average guy wants the hype of the day. You need a big marketing >>> budget to make them happy. >> >> Check this TelTalk : https://www.youtube.com/watch?v=qp0HIF3SfI4 >> >> Here is the thing : "People buy why you do it not what you do" >> If you don't understand this, you're screwed. > > I know why I'm doing Forth: I want to use a system that is *simple > enough* to be understandable by me in total, and at the same time > *not* restricting me in any way, so I can solve new problems in a > creative way. I don't want to use the new COBOL for uninspired > programmers who solve old problems by writing wrappers around > already bloated libraries; I call this "onion programming", and it > makes me shed tears. Heh. COBOL is tiny by modern standards. :-) Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-04-30 03:08 -0500 |
| Message-ID | <ruadnZal-bPyMv3OnZ2dnUVZ_qqdnZ2d@supernews.com> |
| In reply to | #29974 |
Bernd Paysan <bernd.paysan@gmx.de> wrote: > kerdezixe@gmail.com wrote: >> I spent ~3h looking for a "Forth on JVM", even experimental code on github >> would do the trick. Couldn't find any. > > This is because JVM is a stack-based machine, but *not* a Forth VM. The > main difference is that Forth has a separate return stack, while JVM has > just one single stack. No, it doesn't: there are two. There is the expression stack, much like Forth's parameter stack, and a stack of method contexts which also contains return addresses. > The other thing is that a JVM compiler is a batch compiler. No, that's the Java compiler not the JVM compiler, and it can be invoked at runtime, and there are lots of ways of dynamically generating JVM code. > Therefore, it is not possible to do a Forth directly on JVM. You > can write a Forth compiler in Java, but it won't directly generate > JVM byte code. Therefore, the only thing you'll find on JVM are > Forth interpreters: > > c2.com/cgi/wiki?OtherLanguagesForTheJavaVm I'm sure that an interactive Forth generating Java bytecode could be done, but it would be tricky. The main problem is the requrement that the expression stack be of a fixed size and be balanced across branches. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Laurent Laborde <kerdezixe@gmail.com> |
|---|---|
| Date | 2014-04-30 02:30 -0700 |
| Message-ID | <a6f36d39-7243-40d4-9bac-a0fee92b59b5@googlegroups.com> |
| In reply to | #29997 |
On Wednesday, April 30, 2014 10:08:15 AM UTC+2, Andrew Haley wrote: > Bernd Paysan <bernd.paysan@gmx.de> wrote: > > > kerdezixe@gmail.com wrote: > > >> I spent ~3h looking for a "Forth on JVM", even experimental code on github > >> would do the trick. Couldn't find any. > > > This is because JVM is a stack-based machine, but *not* a Forth VM. The > > main difference is that Forth has a separate return stack, while JVM has > > just one single stack. > > No, it doesn't: there are two. There is the expression stack, much > like Forth's parameter stack, and a stack of method contexts which > also contains return addresses. > > > The other thing is that a JVM compiler is a batch compiler. > > No, that's the Java compiler not the JVM compiler, and it can be > invoked at runtime, and there are lots of ways of dynamically > generating JVM code. > > > Therefore, it is not possible to do a Forth directly on JVM. You > > can write a Forth compiler in Java, but it won't directly generate > > JVM byte code. Therefore, the only thing you'll find on JVM are > > Forth interpreters: > > > c2.com/cgi/wiki?OtherLanguagesForTheJavaVm > > I'm sure that an interactive Forth generating Java bytecode could be > done, but it would be tricky. The main problem is the requrement that > the expression stack be of a fixed size and be balanced across > branches. a nice paper : http://www.csc.kth.se/utbildning/kth/kurser/DD143X/dkand12/Group2Mads/report/AntonKindestam.pdf A Lisp compiler for the JVM or How to implement dynamic programming languages on top of the JVM or Lack of JVM TCO considered annoying I don't understand why you're so focused on the JVM stack. Can't use it directly, then don't. It's stupid simple to have a static method (in the jvm sense) returning a http://docs.oracle.com/javase/7/docs/api/java/util/Stack.html That's the magic of the jvm, it come with an impressive rt.jar and every single stuff in it can be called with an 8bit jvm opcode. The jvm internal operand stack is a software emulation anyway. So, who care ? About the operand stack, to be exact : The maximum depth of the operand stack of a frame is determined at compile time and is supplied along with the code for the method associated with the frame Emphasis on *maximum depth*.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-04-30 06:45 -0500 |
| Message-ID | <V_2dnS8BnI_2f_3OnZ2dnUVZ_gednZ2d@supernews.com> |
| In reply to | #30000 |
Laurent Laborde <kerdezixe@gmail.com> wrote:
> On Wednesday, April 30, 2014 10:08:15 AM UTC+2, Andrew Haley wrote:
>> Bernd Paysan <bernd.paysan@gmx.de> wrote:
>>
>> > kerdezixe@gmail.com wrote:
>>
>> >> I spent ~3h looking for a "Forth on JVM", even experimental code on github
>> >> would do the trick. Couldn't find any.
>>
>> > This is because JVM is a stack-based machine, but *not* a Forth VM. The
>> > main difference is that Forth has a separate return stack, while JVM has
>> > just one single stack.
>>
>> No, it doesn't: there are two. There is the expression stack, much
>> like Forth's parameter stack, and a stack of method contexts which
>> also contains return addresses.
>>
>> > The other thing is that a JVM compiler is a batch compiler.
>>
>> No, that's the Java compiler not the JVM compiler, and it can be
>> invoked at runtime, and there are lots of ways of dynamically
>> generating JVM code.
>>
>> > Therefore, it is not possible to do a Forth directly on JVM. You
>> > can write a Forth compiler in Java, but it won't directly generate
>> > JVM byte code. Therefore, the only thing you'll find on JVM are
>> > Forth interpreters:
>>
>> > c2.com/cgi/wiki?OtherLanguagesForTheJavaVm
>>
>> I'm sure that an interactive Forth generating Java bytecode could be
>> done, but it would be tricky. The main problem is the requrement that
>> the expression stack be of a fixed size and be balanced across
>> branches.
>
> a nice paper :
> http://www.csc.kth.se/utbildning/kth/kurser/DD143X/dkand12/Group2Mads/report/AntonKindestam.pdf
>
> A Lisp compiler for the JVM
> or
> How to implement dynamic programming languages on top of the JVM
> or
> Lack of JVM TCO considered annoying
>
> I don't understand why you're so focused on the JVM stack.
> Can't use it directly, then don't.
Right, but the resulting code would be dire.
> It's stupid simple to have a static method (in the jvm sense)
> returning a http://docs.oracle.com/javase/7/docs/api/java/util/Stack.html
> That's the magic of the jvm, it come with an impressive rt.jar and
> every single stuff in it can be called with an 8bit jvm opcode.
>
> The jvm internal operand stack is a software emulation anyway.
> So, who care ?
Because it's a really, really good emulation.
> About the operand stack, to be exact :
> The maximum depth of the operand stack of a frame is determined
> at compile time and is supplied along with the code for the method
> associated with the frame
>
> Emphasis on *maximum depth*.
We need to talk about real examples. The problem is that if you have
a Forth word like, say:
: foo 9 * ;
you could implement this in the JVM as a method:
public static long bar(long n) {
return n * 9;
}
static long foo(long);
Code:
0: lload_0
1: ldc2_w #2 // long 9l
4: lmul
5: lreturn
a call to which which could generate, say:
0x00007fffed1af3d0: mov %r9,%rdi
0x00007fffed1af3d3: shl $0x3,%rdi
0x00007fffed1af3d7: add %r9,%rdi
but in Forth we have a stack that is accessed by every word, and can
be left unbalanced, so we have to expose it as a real array:
public static int foo(long[] stack, int sp) {
stack[sp] *= 9;
return sp;
}
public static int foo(long[], int);
Code:
0: aload_0
1: iload_1
2: dup2
3: laload
4: ldc2_w #2 // long 9l
7: lmul
8: lastore
9: iload_1
10: ireturn
and the resulting code would be:
0x00007fffed1aef42: cmp %r10d,%ebp
0x00007fffed1aef45: jae 0x00007fffed1af019
0x00007fffed1aef4b: mov 0x18(%r8,%rbp,8),%r10 ;*laload
; - org.sample.Forth::foo@3 (line 53)
; - org.sample.Forth::bench1@6 (line 63)
; - org.sample.generated.Forth::bench1_Throughput_measurementLoop@17 (line 96)
0x00007fffed1aef50: mov %r10,%r11
0x00007fffed1aef53: shl $0x3,%r11
0x00007fffed1aef57: add %r10,%r11
0x00007fffed1aef5a: mov %r11,0x18(%r8,%rbp,8) ;*lastore
; - org.sample.Forth::foo@8 (line 53)
; - org.sample.Forth::bench1@6 (line 63)
; - org.sample.generated.Forth::bench1_Throughput_measurementLoop@17 (line 96)
Some of the checking of the stack pointer to make sure the stack
access does not go outside the array will be eliminated, but the
memory accesses to the array that is the stack can't be.
This isn't terrible, but it's a lot of overhead for a single
operation.
Andrew.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-04-30 22:02 -0400 |
| Message-ID | <op.xe5rxxrh6zenlw@localhost> |
| In reply to | #30007 |
On Wed, 30 Apr 2014 07:45:47 -0400, Andrew Haley
<andrew29@littlepinkcloud.invalid> wrote:
> We need to talk about real examples.
>
> The problem is that if you have a Forth word like, say:
>
> : foo 9 * ;
>
> you could implement this in the JVM as a method:
>
> public static long bar(long n) {
> return n * 9;
> }
>
> [snip IR and assembly]
>
> but in Forth we have a stack that is accessed by every word,
> and can be left unbalanced, so we have to expose it as a
> real array:
>
> public static int foo(long[] stack, int sp) {
> stack[sp] *= 9;
> return sp;
> }
>
> [snip IR and assembly]
>
Is there any reason to return 'sp'? You didn't modify it...
Why didn't you do something like this?:
public static int foo(long[] stack, int sp)
{
long n;
n=stack[sp];
n*=9;
stack[sp]=n;
return n;
}
I.e., wouldn't the local variable 'n' _allow_ the compiler
to use a register thereby possibly reducing the code somewhat?
Try it...
I.e., in C, you might've chosen to pass a pointer to 'sp'
in the parameter list instead. That would eliminate the
following line in the main code, replacing it with the next:
sp=foo(stack,sp); /* eliminated */
foo(stack,&sp); /* replacement */
Also, can you make 'stack' and 'sp' have file scope, be global,
so you don't need to pass them? That's probably adding a small
amount of parameter passing code. I.e., 'void' parameters,
at least in C, eliminates some passing overhead:
public static void foo(void)
{
long n;
n=stack[sp];
n*=9;
stack[sp]=n;
}
Boundary checks on the stack pointer for underflow and overflow
probably adds some extra code too. I haven't figured out a
clean or safe way to eliminate that from my interpreter, yet.
That would be nice if I could.
I don't see stack boundary checks in the code, but it looked
like some was in the assembly. I'm assuming this is for C++
and some object-oriented feature was in play which inserted
the checks.
Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-05-01 04:04 -0500 |
| Message-ID | <MbednUKRytSak__OnZ2dnUVZ_jWdnZ2d@supernews.com> |
| In reply to | #30025 |
Rod Pemberton <dont_use_email@xnothavet.cqm> wrote:
> On Wed, 30 Apr 2014 07:45:47 -0400, Andrew Haley
> <andrew29@littlepinkcloud.invalid> wrote:
>
>> We need to talk about real examples.
>>
>> The problem is that if you have a Forth word like, say:
>>
>> : foo 9 * ;
>>
>> you could implement this in the JVM as a method:
>>
>> public static long bar(long n) {
>> return n * 9;
>> }
>>
>> [snip IR and assembly]
>>
>> but in Forth we have a stack that is accessed by every word,
>> and can be left unbalanced, so we have to expose it as a
>> real array:
>>
>> public static int foo(long[] stack, int sp) {
>> stack[sp] *= 9;
>> return sp;
>> }
>>
>> [snip IR and assembly]
>>
>
> Is there any reason to return 'sp'? You didn't modify it...
Sure, but the caller can't know that.
> Why didn't you do something like this?:
>
> public static int foo(long[] stack, int sp)
> {
> long n;
> n=stack[sp];
> n*=9;
> stack[sp]=n;
> return n;
> }
>
> I.e., wouldn't the local variable 'n' _allow_ the compiler
> to use a register thereby possibly reducing the code somewhat?
It's using a register.
> Try it...
>
> I.e., in C, you might've chosen to pass a pointer to 'sp'
> in the parameter list instead. That would eliminate the
> following line in the main code, replacing it with the next:
>
> sp=foo(stack,sp); /* eliminated */
> foo(stack,&sp); /* replacement */
In general this would be less efficient, because SP is not passed in a
register. A good optimization could remove a lot of the memory traffic.
> Also, can you make 'stack' and 'sp' have file scope, be global,
> so you don't need to pass them?
No, because you'd have to write sp back to global memory after every
operation rather than keeping it in a register.
> That's probably adding a small
> amount of parameter passing code. I.e., 'void' parameters,
> at least in C, eliminates some passing overhead:
>
> public static void foo(void)
> {
> long n;
> n=stack[sp];
> n*=9;
> stack[sp]=n;
> }
How does this help? Surely there is just as much overhead for
accessing a global variable as passing a parameter in a register.
> I don't see stack boundary checks in the code, but it looked
> like some was in the assembly. I'm assuming this is for C++
> and some object-oriented feature was in play which inserted
> the checks.
This is the Java VM.
Andrew.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-05-01 16:08 -0400 |
| Message-ID | <op.xe657zu06zenlw@localhost> |
| In reply to | #30030 |
On Thu, 01 May 2014 05:04:07 -0400, Andrew Haley
<andrew29@littlepinkcloud.invalid> wrote:
> Rod Pemberton <dont_use_email@xnothavet.cqm> wrote:
>> On Wed, 30 Apr 2014 07:45:47 -0400, Andrew Haley
>> <andrew29@littlepinkcloud.invalid> wrote:
>>> We need to talk about real examples.
>>>
>>> The problem is that if you have a Forth word like, say:
>>>
>>> : foo 9 * ;
>>>
>>> you could implement this in the JVM as a method:
>>>
>>> public static long bar(long n) {
>>> return n * 9;
>>> }
>>>
>>> [snip IR and assembly]
>>>
>>> but in Forth we have a stack that is accessed by every word,
>>> and can be left unbalanced, so we have to expose it as a
>>> real array:
>>>
>>> public static int foo(long[] stack, int sp) {
>>> stack[sp] *= 9;
>>> return sp;
>>> }
>>>
>>> [snip IR and assembly]
>>>
>>
>> Is there any reason to return 'sp'? You didn't modify it...
>
> Sure, but the caller can't know that.
The point was the function should be smaller if SP doesn't
need to be returned. There is code generated for the return
if it's not returned.
Also, returning SP seems to have no purpose here. So, why
would someone set SP to the return value of this function?
Can they read the code for this function and see passing SP
does nothing?
>> Why didn't you do something like this?:
>>
>> public static int foo(long[] stack, int sp)
>> {
>> long n;
>> n=stack[sp];
>> n*=9;
>> stack[sp]=n;
>> return n;
>> }
>>
>> I.e., wouldn't the local variable 'n' _allow_ the compiler
>> to use a register thereby possibly reducing the code somewhat?
>
> It's using a register.
"It's" refers to what exactly?
1) my locally declared 'long n' in this example
2) your 'long n' parameter in your first example
3) something else
#1 would be a confirmation of what I said.
#2 would indicate the Java "compiler" passes parameters in registers
>> I.e., in C, you might've chosen to pass a pointer to 'sp'
>> in the parameter list instead. That would eliminate the
>> following line in the main code, replacing it with the next:
>>
>> sp=foo(stack,sp); /* eliminated */
>> foo(stack,&sp); /* replacement */
Also, you could've just passed a single pointer instead of
a pointer and offset, e.g.,
foo(&stack[sp]); /* only a pointer */
>> [replacement suggestion above]
>
> In general this would be less efficient,
In C, or in the Java "compiler" and/or Java VM?
(Don't say C.)
For the replacement in C, the pointer is passed in
for C. Nothing is passed out for SP.
For the original in C, a value for SP is passed in
on the stack, and a return value is passed out
in register thats stored in SP in memory. (*)
(*) conditional to constraints discussed below.
> because SP is not passed in a register.
If SP is passed *in* by register by the Java "compiler"
for the SP passed as a parameter in your example,
that's excellent! It would also be very surprising...
Obviously, the return value as SP is passed *out* by
register. I.e., I think you need to clarify which SP
you were discussing for your example when you said:
"SP is not passed in a register". In? Out? Both?
C compilers almost always pass parameters on a stack.
There are numerous important reasons for this. Of
course, some C compilers do allow you to pass parameters
in registers, if there won't be a register starvation
issue.
Some of the reasons C uses a stack for parameter passing:
-improve the locality of reference for data
-index data off of a single pointer to the stack frame
-provide memory addesses for data, i.e.,
for the & address-of operator
-prevent register starvation issues which can occur if
parameters are passed in registers
>> Also, can you make 'stack' and 'sp' have file scope,
>> be global, so you don't need to pass them?
>
> No, because you'd have to write sp back to global
> memory after every operation rather than keeping
> it in a register.
Could you explain how the Java VM keeps SP in a register?
If Java VM works like C, you're reading SP from memory to
pass it to a procedure. When it's passed to a procedure,
it's saved on a stack. When SP is updated, it's written
back to memory.
Does Java "compiler" have a "register" keyword? If not,
is this placement of SP into a register some automatic
optimization? Or, is it only for the return value? I
readily accept that returns in C are passed back in a
register. If SP is a variable, I'd expect SP to be
stored in memory somewhere. So, a memory fetch and store
will be needed somewhere to use and update it.
>> That's probably adding a small
>> amount of parameter passing code. I.e., 'void' parameters,
>> at least in C, eliminates some passing overhead:
>>
>> public static void foo(void)
>> {
>> long n;
>> n=stack[sp];
>> n*=9;
>> stack[sp]=n;
>> }
>
> How does this help? Surely there is just as much overhead for
> accessing a global variable as passing a parameter in a register.
If the Java "compiler" for that code works differently from C,
I don't know if it helps any.
If the Java "compiler" works the same as or similar to a C compiler,
then the two voids eliminate most or all of the function's epilog
and prolog. The 'long n' being an 'auto' - a procedure local
variable - should be optimized by the C compiler to use a register,
or a 'register' keyword in C will do that. The local eliminates
complicated instructions against memory locations which would be
generated if multiplying stack[sp] (in memory) by nine directly.
Instead, simpler register multiply is generated. At least, that's
how C for a variety of C compilers, including GNU C, typically work
on x86.
Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-05-02 08:12 -0500 |
| Message-ID | <c7udnRUro44hBP7OnZ2dnUVZ_qKdnZ2d@supernews.com> |
| In reply to | #30044 |
Rod Pemberton <dont_use_email@xnothavet.cqm> wrote:
> On Thu, 01 May 2014 05:04:07 -0400, Andrew Haley
> <andrew29@littlepinkcloud.invalid> wrote:
>> Rod Pemberton <dont_use_email@xnothavet.cqm> wrote:
>>> On Wed, 30 Apr 2014 07:45:47 -0400, Andrew Haley
>>> <andrew29@littlepinkcloud.invalid> wrote:
>
>>>> We need to talk about real examples.
>>>>
>>>> The problem is that if you have a Forth word like, say:
>>>>
>>>> : foo 9 * ;
>>>>
>>>> you could implement this in the JVM as a method:
>>>>
>>>> public static long bar(long n) {
>>>> return n * 9;
>>>> }
>>>>
>>>> [snip IR and assembly]
>>>>
>>>> but in Forth we have a stack that is accessed by every word,
>>>> and can be left unbalanced, so we have to expose it as a
>>>> real array:
>>>>
>>>> public static int foo(long[] stack, int sp) {
>>>> stack[sp] *= 9;
>>>> return sp;
>>>> }
>>>>
>>>> [snip IR and assembly]
>>>>
>>>
>>> Is there any reason to return 'sp'? You didn't modify it...
>>
>> Sure, but the caller can't know that.
>
> The point was the function should be smaller if SP doesn't need to
> be returned. There is code generated for the return if it's not
> returned.
But the SP has to be returned, because the caller needs to know what
its new value is. If the word gets inlined from another word, and it'
quite likely that it will, all the passing of SP will be elided in the
generated code.
> Also, returning SP seems to have no purpose here. So, why would
> someone set SP to the return value of this function? Can they read
> the code for this function and see passing SP does nothing?
It's a word. Every word must be passed the stack and the stack
pointer. In this case, the stack itself is passed by reference in a
register, and the stack pointer in a register. The stack pointer is
returned in a register. I think this is better than passing the stack
pointer in memory.
>>> Why didn't you do something like this?:
>>>
>>> public static int foo(long[] stack, int sp)
>>> {
>>> long n;
>>> n=stack[sp];
>>> n*=9;
>>> stack[sp]=n;
>>> return n;
>>> }
This word might get called by the interpreter. The interpreter needs
to know about the stack adjustment.
>>> I.e., wouldn't the local variable 'n' _allow_ the compiler
>>> to use a register thereby possibly reducing the code somewhat?
>>
>> It's using a register.
>
> "It's" refers to what exactly?
The generated code. I even supplied a disassembly.
> 1) my locally declared 'long n' in this example
> 2) your 'long n' parameter in your first example
> 3) something else
>
> #1 would be a confirmation of what I said.
> #2 would indicate the Java "compiler" passes parameters in registers
It does.
>>> I.e., in C, you might've chosen to pass a pointer to 'sp'
>>> in the parameter list instead. That would eliminate the
>>> following line in the main code, replacing it with the next:
>>>
>>> sp=foo(stack,sp); /* eliminated */
>>> foo(stack,&sp); /* replacement */
>
> Also, you could've just passed a single pointer instead of
> a pointer and offset, e.g.,
>
> foo(&stack[sp]); /* only a pointer */
How? The caller (the Forth interpreter, maybe) doesn't know that the
word in question does not adjust SP and only accesses the top stack
item. It just calls a word, passing the stack, and gets the (maybe
adjusted) stack back.
>>> [replacement suggestion above]
>>
>> In general this would be less efficient,
>
> In C, or in the Java "compiler" and/or Java VM?
>
> (Don't say C.)
>
> For the replacement in C, the pointer is passed in for C. Nothing
> is passed out for SP.
>
> For the original in C, a value for SP is passed in on the stack, and
> a return value is passed out in register thats stored in SP in
> memory. (*) (*) conditional to constraints discussed below.
What does "Passed out in register thats stored in SP in memory?" mean?
>> because SP is not passed in a register.
>
> If SP is passed *in* by register by the Java "compiler" for the SP
> passed as a parameter in your example, that's excellent! It would
> also be very surprising...
That is what happens.
> Obviously, the return value as SP is passed *out* by register.
> I.e., I think you need to clarify which SP you were discussing for
> your example when you said: "SP is not passed in a register". In?
> Out? Both?
Both.
> C compilers almost always pass parameters on a stack. There are
> numerous important reasons for this. Of course, some C compilers do
> allow you to pass parameters in registers, if there won't be a
> register starvation issue.
C compilers pass arguments on the stack or in registers, and this
depends on the ABI. Every machine I use passes the first few
arguments in registers.
>>> Also, can you make 'stack' and 'sp' have file scope,
>>> be global, so you don't need to pass them?
>>
>> No, because you'd have to write sp back to global
>> memory after every operation rather than keeping
>> it in a register.
>
> Could you explain how the Java VM keeps SP in a register?
It depends on the VM, but I'll talk about HotSpot. The first N (8,
say) arguments are passed in registers. One argument is returned in a
register. If you arrange for every word to return SP then it'll
always be in a register.
> If Java VM works like C, you're reading SP from memory to pass it to
> a procedure.
That would be bad.
> Does Java "compiler" have a "register" keyword?
No.
> If not, is this placement of SP into a register some automatic
> optimization?
HotSpot always uses registers for locals and arguments if can.
> Or, is it only for the return value?
That as well.
>>> That's probably adding a small
>>> amount of parameter passing code. I.e., 'void' parameters,
>>> at least in C, eliminates some passing overhead:
>>>
>>> public static void foo(void)
>>> {
>>> long n;
>>> n=stack[sp];
>>> n*=9;
>>> stack[sp]=n;
>>> }
>>
>> How does this help? Surely there is just as much overhead for
>> accessing a global variable as passing a parameter in a register.
>
> If the Java "compiler" for that code works differently from C,
> I don't know if it helps any.
>
> If the Java "compiler" works the same as or similar to a C compiler,
> then the two voids eliminate most or all of the function's epilog
> and prolog. The 'long n' being an 'auto' - a procedure local
> variable - should be optimized by the C compiler to use a register,
> or a 'register' keyword in C will do that. The local eliminates
> complicated instructions against memory locations which would be
> generated if multiplying stack[sp] (in memory) by nine directly.
> Instead, simpler register multiply is generated. At least, that's
> how C for a variety of C compilers, including GNU C, typically work
> on x86.
No, you're missing the point. Accessing SP from a global variable
requires a read or a write from memory; better keep SP in a register
and pass it to every word that needs it. (Which, in practice, is
every word.) Besides, there are mutiple threads, each with its own
SP, so you can't just put SP at a fixed address.
Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-05-02 22:33 +0200 |
| Message-ID | <lk0vf3$saf$1@online.de> |
| In reply to | #30061 |
Andrew Haley wrote: > No, you're missing the point. Accessing SP from a global variable > requires a read or a write from memory; better keep SP in a register > and pass it to every word that needs it. (Which, in practice, is > every word.) Besides, there are mutiple threads, each with its own > SP, so you can't just put SP at a fixed address. You are clearly doing it wrong. That's not the Java way. First of all, you need a stack factory class, which can create stack classes with different types (you know, data stacks, floating point stacks, string stacks, object stacks...). Then you need an interpretar factory, which can create interpreters that are combined with stacks. And finally, you need a an adapter framework factory, which creates adapters for Java functions so that they take their arguments from the stacks and return their return values there. To combine the primitives you have create that way, you add a concatenator, which uses the reflection API to create concatenate functions, which you then adapt to use the stacks... The resulting system is now flexible enough to implement Forth, Brainfuck, Piet, and Postscript. And it is so slow that you get the "right" feeling ;-). -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2014-05-02 15:19 -0700 |
| Message-ID | <a9a699b3-f469-45b4-be0f-e957831fe51b@googlegroups.com> |
| In reply to | #30063 |
On Friday, 2 May 2014 21:33:32 UTC+1, Bernd Paysan wrote: [ funny poke at java snipped ] So funny, so true!
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-05-03 04:30 -0500 |
| Message-ID | <6JWdnZaxlfiBKvnOnZ2dnUVZ_hadnZ2d@supernews.com> |
| In reply to | #30063 |
Bernd Paysan <bernd.paysan@gmx.de> wrote: > Andrew Haley wrote: > >> No, you're missing the point. Accessing SP from a global variable >> requires a read or a write from memory; better keep SP in a register >> and pass it to every word that needs it. (Which, in practice, is >> every word.) Besides, there are mutiple threads, each with its own >> SP, so you can't just put SP at a fixed address. > > You are clearly doing it wrong. That's not the Java way. :-) Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-04-30 09:53 +0000 |
| Message-ID | <2014Apr30.115351@mips.complang.tuwien.ac.at> |
| In reply to | #29997 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Bernd Paysan <bernd.paysan@gmx.de> wrote:
>> kerdezixe@gmail.com wrote:
>>> I spent ~3h looking for a "Forth on JVM", even experimental code on github
>>> would do the trick. Couldn't find any.
>>
>> This is because JVM is a stack-based machine, but *not* a Forth VM. The
>> main difference is that Forth has a separate return stack, while JVM has
>> just one single stack.
>
>No, it doesn't: there are two. There is the expression stack, much
>like Forth's parameter stack, and a stack of method contexts which
>also contains return addresses.
The JVM is designed such that only one stack pointer is needed to
implement it. And that's relatively straightforward, much more so
than for PAF. Sure, it has additional restrictions that make a
different organization possible, but that does not make compiling
Forth to JVM any easier.
- 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 | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-04-30 09:24 +0000 |
| Subject | Forth on JVM (was: Epic Fail) |
| Message-ID | <2014Apr30.112412@mips.complang.tuwien.ac.at> |
| In reply to | #29974 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>kerdezixe@gmail.com wrote:
>> I spent ~3h looking for a "Forth on JVM", even experimental code on github
>> would do the trick. Couldn't find any.
>
>This is because JVM is a stack-based machine, but *not* a Forth VM.
Yes. That used to be a Forth FAQ (when the JVM was new and shiny),
and there is an answer in
http://www.complang.tuwien.ac.at/forth/faq/faq-general-5.html#ss5.6
> The
>main difference is that Forth has a separate return stack, while JVM has
>just one single stack.
The JVM stack depth also needs to be statically known, like in PAF.
It's possible to emulate a Forth stack with that, as sketched in the
PAF paper, but it's an extra complication.
>The other thing is that a JVM compiler is a batch
>compiler.
I guess you could do an interactive Forth that uses reflection to
generate more JVM code dynamically, but it's another complication.
The most problematic thing, though, is that the JVM does not have
addresses and address arithmetic and does not deal with uninterpreted
bytes and cells (machine words). One can think about emulating this
through an array of ints (with 1 cells=1 chars=1 au=1 long) or maybe
longs, or maybe an array of bytes (with 1 chars=1 au=1 byte, and maybe
1 cells = 4 bytes), but these options are inefficient in many ways,
and certainly far from the spirit of Forth.
Overall, the JVM is a bad fit for Forth.
What would be more like it would be a Forth/Factor-like language that
is designed for the JVM: It would use a stack with statically know
stack depth and statically known types for stack items (somewhat
strongForth-like), would not have addresses, but provide objects and
arrays and various other JVM features. That would essentially be a
layer of dictionary and interactivity on top of the JVM.
In any case, while there have been some attempts at implementing Forth
on top of the JVM, they have not become popular AFAIK, so apparently
this concept is not as attractive as some in this thread think.
- 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 | jacko <jackokring@gmail.com> |
|---|---|
| Date | 2014-04-30 17:14 -0700 |
| Subject | Re: Forth on JVM (was: Epic Fail) |
| Message-ID | <9cc40efd-6391-4f88-9ecf-dc4f88c9d477@googlegroups.com> |
| In reply to | #30001 |
> and there is an answer in > > http://www.complang.tuwien.ac.at/forth/faq/faq-general-5.html#ss5.6 > > > > > The "However, to achieve this the virtual machine design has local variable support." - This in an incorrect fact. "To achieve this the virtual machine design can have global vocabulary contexted named-stack definitions. In effect allowing nesting for local effect by stack name."
[toc] | [prev] | [next] | [standalone]
| From | jacko <jackokring@gmail.com> |
|---|---|
| Date | 2014-04-30 17:27 -0700 |
| Subject | Re: Forth on JVM (was: Epic Fail) |
| Message-ID | <99037e3f-7cc9-4b9b-8c71-b286c3690952@googlegroups.com> |
| In reply to | #30022 |
It does look like I will return to the Jarvar SL project after github rub. Which is in Pascal by the way. Looks like I'll use the excellent FreeVision TurboVision clone as IO for SL when rewritten in Pascal later on. Luckily SL is not forth, but closely related, in fact type optimized to provide a secure stack execution environment. To this end it is likely a (hash)table class will extend stack, and book will extend table.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-05-01 15:25 +0000 |
| Subject | Re: Forth on JVM (was: Epic Fail) |
| Message-ID | <2014May1.172551@mips.complang.tuwien.ac.at> |
| In reply to | #30022 |
jacko <jackokring@gmail.com> writes:
>
>> and there is an answer in
>>
>> http://www.complang.tuwien.ac.at/forth/faq/faq-general-5.html#ss5.6
>>
>>
>>
>> > The
>
>"However, to achieve this the virtual machine design has local variable support." - This in an incorrect fact.
>
>"To achieve this the virtual machine design can have global vocabulary contexted named-stack definitions. In effect allowing nesting for local effect by stack name."
That's in the part
<http://www.complang.tuwien.ac.at/forth/faq/faq-general-5.html#ss5.1>
"5.1 Where can I find a C-to-Forth compiler?", and it's about MPE's
C-to-stack-machine compiler. It would surprise me if you know better
about this compiler than Stephen Pelc, but you can certainly discuss
it with him here.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | "Peter Knaggs" <pjk@bcs.org.uk> |
|---|---|
| Date | 2014-05-03 08:28 +0100 |
| Subject | Re: Forth on JVM (was: Epic Fail) |
| Message-ID | <op.xe9wdnw9su5d0p@david> |
| In reply to | #30037 |
On Thu, 01 May 2014 16:25:51 +0100, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > jacko <jackokring@gmail.com> writes: >> >>> and there is an answer in >>> >>> http://www.complang.tuwien.ac.at/forth/faq/faq-general-5.html#ss5.6 >>> >>> >>> >>> > The >> >> "However, to achieve this the virtual machine design has local variable >> support." - This in an incorrect fact. >> >> "To achieve this the virtual machine design can have global vocabulary >> contexted named-stack definitions. In effect allowing nesting for local >> effect by stack name." > > That's in the part > <http://www.complang.tuwien.ac.at/forth/faq/faq-general-5.html#ss5.1> > "5.1 Where can I find a C-to-Forth compiler?", and it's about MPE's > C-to-stack-machine compiler. It would surprise me if you know better > about this compiler than Stephen Pelc, but you can certainly discuss > it with him here. You can download the MPE C-to-Forth compiler from: http://www.mpeforth.com/arena.htm Its at the bottom of the page. The download includes the source code, which is based on the LCC compiler described in the book "A retargetable C Compiler Design and Implementation" by Fraser and Hanson. -- Peter Knaggs
[toc] | [prev] | [next] | [standalone]
| From | "Peter Knaggs" <pjk@bcs.org.uk> |
|---|---|
| Date | 2014-05-01 07:52 +0100 |
| Subject | Re: Forth on JVM (was: Epic Fail) |
| Message-ID | <op.xe55c7dxsu5d0p@david> |
| In reply to | #30001 |
On Wed, 30 Apr 2014 10:24:12 +0100, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > > I guess you could do an interactive Forth that uses reflection to > generate more JVM code dynamically, but it's another complication. That is exactly what my JavaForth system does. > The most problematic thing, though, is that the JVM does not have > addresses and address arithmetic and does not deal with uninterpreted > bytes and cells (machine words). One can think about emulating this > through an array of ints (with 1 cells=1 chars=1 au=1 long) or maybe > longs, or maybe an array of bytes (with 1 chars=1 au=1 byte, and maybe > 1 cells = 4 bytes), but these options are inefficient in many ways, > and certainly far from the spirit of Forth. I used an array of objects, 1 cell = 2 chars = 4 au. > What would be more like it would be a Forth/Factor-like language that > is designed for the JVM: It would use a stack with statically know > stack depth and statically known types for stack items (somewhat > strongForth-like), would not have addresses, but provide objects and > arrays and various other JVM features. That would essentially be a > layer of dictionary and interactivity on top of the JVM. There is a Holon Forth system that compiles directly to JVM in this way. -- Peter Knaggs
[toc] | [prev] | [next] | [standalone]
Page 20 of 22 — ← Prev page 1 … 18 19 [20] 21 22 Next page →
Back to top | Article view | comp.lang.forth
csiph-web