Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #29282 > unrolled thread
| Started by | Jason Damisch <jasondamisch@yahoo.com> |
|---|---|
| First post | 2014-04-04 10:26 -0700 |
| Last post | 2014-04-29 22:52 -0700 |
| Articles | 20 on this page of 374 — 32 participants |
Back to article view | Back to comp.lang.forth
Epic Fail Jason Damisch <jasondamisch@yahoo.com> - 2014-04-04 10:26 -0700
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-04 12:42 -0500
Re: Epic Fail forthisit@gmail.com - 2014-04-04 11:09 -0700
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-04 22:09 +0100
Re: Epic Fail "Elizabeth D. Rather" <erather@forth.com> - 2014-04-04 21:44 -1000
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-05 09:42 -0700
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-05 10:47 -0700
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-05 15:25 -0400
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-07 17:29 +0000
Re: Epic Fail Assad Ebrahim <assadebrahim2000@gmail.com> - 2014-04-07 12:35 -0700
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-08 15:54 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-08 12:43 -0500
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-09 16:16 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-09 13:00 -0500
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-09 21:08 +0200
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-09 15:17 -0500
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-10 00:17 +0200
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-09 22:42 -0700
Re: Epic Fail Stefan Mauerhofer <smauerhofer@androsoft.ch> - 2014-04-10 00:06 -0700
Re: Epic Fail "Alex McDonald" <blog@rivadpm.com> - 2014-04-10 16:00 +0100
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-10 22:35 +0200
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-10 17:51 -0700
Re: Epic Fail Stefan Mauerhofer <smauerhofer@androsoft.ch> - 2014-04-10 21:44 -0700
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-11 23:10 -0700
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-12 06:18 -0400
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-12 06:23 -0400
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-12 10:52 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.invalid> - 2014-04-12 20:14 +0200
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-12 19:21 -0400
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-13 12:25 -0500
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-13 20:33 -0400
Re: Epic Fail stephenXXX@mpeforth.com (Stephen Pelc) - 2014-04-12 16:12 +0000
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-12 09:48 -0700
Re: Epic Fail Stefan Mauerhofer <smauerhofer@androsoft.ch> - 2014-04-12 10:23 -0700
Re: Epic Fail stephenXXX@mpeforth.com (Stephen Pelc) - 2014-04-12 19:51 +0000
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-12 13:00 -0700
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-12 10:29 -0700
Re: Epic Fail stephenXXX@mpeforth.com (Stephen Pelc) - 2014-04-12 19:56 +0000
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-13 00:25 -0700
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-13 10:50 +0100
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-13 16:53 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.invalid> - 2014-04-14 02:32 +0200
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-13 17:59 -0700
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-14 02:00 +0100
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-13 18:30 -0700
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-13 14:21 +0000
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-13 21:12 -0700
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-23 12:49 +0000
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-28 21:02 -0700
Automatic scoping of locals (was: Epic Fail) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-29 14:49 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-10 03:04 -0500
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-11 17:23 +0000
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-11 21:42 +0200
Re: Epic Fail Spam@ControlQ.com - 2014-04-11 16:13 -0400
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-11 22:15 +0200
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-13 16:10 +0000
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-13 18:42 +0100
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-13 23:44 +0200
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-13 20:33 -0400
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-14 04:05 -0500
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-14 09:57 +0000
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-14 11:56 +0100
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-14 14:53 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-14 07:26 -0700
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-14 21:21 +0200
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-15 04:07 -0500
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-14 09:55 -0700
Re: Epic Fail Alexander Skobelev <al.skobelev@gmail.com> - 2014-04-14 22:04 -0700
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-15 04:10 -0400
Re: Epic Fail Alexander Skobelev <al.skobelev@gmail.com> - 2014-04-15 02:40 -0700
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-15 06:41 -0400
Re: Epic Fail Alexander Skobelev <al.skobelev@gmail.com> - 2014-04-15 06:20 -0700
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-15 12:21 +0000
Re: Epic Fail Alexander Skobelev <al.skobelev@gmail.com> - 2014-04-15 06:30 -0700
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-15 20:04 -0700
Re: Epic Fail Alexander Skobelev <al.skobelev@gmail.com> - 2014-04-15 23:50 -0700
Re: Epic Fail "Elizabeth D. Rather" <erather@forth.com> - 2014-04-15 21:31 -1000
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-16 05:55 -0700
Re: Epic Fail "Alex McDonald" <blog@rivadpm.com> - 2014-04-16 14:50 +0100
Re: Epic Fail Alexander Skobelev <al.skobelev@gmail.com> - 2014-04-16 06:06 -0700
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-19 17:44 -0700
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-20 11:35 -0700
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-16 00:19 -0700
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-16 05:29 -0700
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-16 22:45 -0400
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-14 09:49 +0000
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-23 13:07 +0000
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-23 20:16 -0400
Re: Epic Fail "Elizabeth D. Rather" <erather@forth.com> - 2014-04-23 14:41 -1000
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-24 17:10 +0000
Re: Epic Fail Spam@ControlQ.com - 2014-04-24 15:14 -0400
@ and optimization (was: Epic Fail) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-25 08:40 +0000
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-25 06:13 -0500
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-25 15:26 +0000
Re: @ and optimization Paul Rubin <no.email@nospam.invalid> - 2014-04-25 09:03 -0700
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-25 17:45 +0000
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-25 11:15 -0500
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-25 17:22 +0000
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-26 04:38 -0500
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-26 11:38 +0000
Re: @ and optimization Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-26 14:35 +0200
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-26 09:59 -0500
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-26 10:14 -0500
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-26 15:30 +0000
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-26 12:05 -0500
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-26 17:27 +0000
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-26 12:39 -0500
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-26 18:07 +0000
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-27 03:24 -0500
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-27 13:00 +0000
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-27 11:18 -0500
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-28 15:12 +0000
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-29 03:52 -0500
Re: @ and optimization Mark Wills <markwills1970@gmail.com> - 2014-04-29 03:09 -0700
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-29 09:24 -0500
Re: @ and optimization "Elizabeth D. Rather" <erather@forth.com> - 2014-04-29 08:36 -1000
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-29 14:38 +0000
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-29 10:21 -0500
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-29 15:41 +0000
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-29 12:26 -0500
Re: @ and optimization Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-29 20:17 +0200
Re: @ and optimization stephenXXX@mpeforth.com (Stephen Pelc) - 2014-04-29 19:21 +0000
Re: @ and optimization Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-29 23:20 +0200
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-30 03:02 -0500
Re: @ and optimization Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-26 20:55 +0200
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-27 03:28 -0500
Re: @ and optimization albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-27 13:31 +0000
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-28 15:27 +0000
Re: @ and optimization albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-27 13:23 +0000
Re: @ and optimization hughaguilar96@yahoo.com - 2014-04-28 21:32 -0700
Re: @ and optimization "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-26 08:50 -0400
Re: @ and optimization "Alex McDonald" <blog@rivadpm.com> - 2014-04-26 22:52 +0100
Re: @ and optimization "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-26 20:33 -0400
Re: @ and optimization "Alex McDonald" <blog@rivadpm.com> - 2014-04-27 11:53 +0100
Re: @ and optimization "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-28 01:05 -0400
Re: @ and optimization Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-25 21:34 +0100
Re: @ and optimization Paul Rubin <no.email@nospam.invalid> - 2014-04-25 13:37 -0700
Re: @ and optimization Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-25 22:03 +0100
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-26 15:38 +0000
Re: @ and optimization Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-26 17:24 +0100
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-26 04:48 -0500
Re: @ and optimization Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-26 11:09 +0100
Re: @ and optimization (was: Epic Fail) hughaguilar96@yahoo.com - 2014-04-28 21:24 -0700
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-24 19:17 +0000
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-25 08:27 +0000
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-25 23:44 +0200
Re: Epic Fail stephenXXX@mpeforth.com (Stephen Pelc) - 2014-04-26 14:37 +0000
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-13 15:04 -0700
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-26 09:58 +0100
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-26 10:16 +0100
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-26 05:06 -0500
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-26 11:16 +0100
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-26 03:43 -0700
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-26 14:24 +0000
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-26 23:58 -0400
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-27 12:46 +0000
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-28 00:41 -0400
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-28 21:54 -0700
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-26 17:17 +0100
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-26 10:08 -0500
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-26 13:44 +0200
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-26 09:11 -0400
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-26 10:12 -0500
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-26 17:00 +0100
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-26 12:08 -0500
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-26 23:41 -0400
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-26 17:06 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-26 12:45 -0500
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-26 17:52 +0000
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-26 21:52 +0200
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-27 03:31 -0500
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-27 13:48 +0200
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-27 12:02 +0000
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-26 22:19 +0100
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-14 10:28 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-14 22:02 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-14 18:57 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-15 05:05 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-14 22:53 -0700
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-13 12:34 -0500
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-14 13:22 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-14 10:08 -0500
Re: Epic Fail Spam@ControlQ.com - 2014-04-14 11:59 -0400
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-17 16:56 +0000
Re: Epic Fail Spam@ControlQ.com - 2014-04-17 15:16 -0400
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-17 23:59 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-18 04:38 -0700
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-18 09:17 -0400
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-18 11:44 -0500
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-18 17:06 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-18 11:41 -0500
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-18 16:55 +0000
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-18 19:20 +0200
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-20 14:52 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-18 12:21 -0500
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-20 14:36 +0000
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-20 08:17 -0700
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-20 11:35 -0500
Re: Epic Fail "Alex McDonald" <blog@rivadpm.com> - 2014-04-21 10:51 -0700
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-21 19:54 +0200
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-22 17:40 +0000
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-22 20:47 +0200
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-19 11:34 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-19 16:05 -0500
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-20 12:38 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-20 11:42 -0500
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-20 12:11 -0500
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-20 17:23 +0000
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-20 11:58 -0700
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-21 10:21 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-22 04:58 -0500
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-22 17:05 +0000
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-20 17:12 +0000
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-20 19:47 -0400
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-22 05:03 -0500
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-22 11:51 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-22 08:28 -0500
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-22 15:02 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-22 13:23 -0500
Re: Epic Fail Melzzzzz <mel@zzzzz.invalid> - 2014-04-22 19:19 +0200
Re: Epic Fail Todd Hughes <noemail@dontemailme.org> - 2014-04-10 11:24 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-10 06:55 -0500
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-10 15:50 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-10 11:02 -0500
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-10 22:31 +0200
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-11 03:55 -0500
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-10 19:08 -0400
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-10 19:03 -0400
Re: Epic Fail "Alex McDonald" <blog@rivadpm.com> - 2014-04-11 17:45 +0100
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-11 17:16 +0000
Re: Epic Fail "Alex McDonald" <blog@rivadpm.com> - 2014-04-11 18:59 +0100
Re: Epic Fail "Alex McDonald" <blog@rivadpm.com> - 2014-04-11 19:11 +0100
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-11 12:05 -0700
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-11 22:03 -0400
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-11 20:18 +0200
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-11 21:44 -0400
Re: Epic Fail visualforth@rocketmail.com - 2014-04-11 14:00 -0700
Re: Epic Fail Matthias Trute <matthias.trute@gmail.com> - 2014-04-12 01:04 -0700
Re: Epic Fail the_gavino_himself <visphatesjava@gmail.com> - 2014-04-09 16:12 -0700
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-04 23:20 +0200
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-07 17:40 +0000
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-08 00:52 +0200
Re: Epic Fail Assad Ebrahim <assadebrahim2000@gmail.com> - 2014-04-07 16:13 -0700
Re: Epic Fail Ron Aaron <rambamist@gmail.com> - 2014-04-08 06:37 +0300
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-09 01:12 +0200
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-08 10:16 +0000
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-04 17:41 -0400
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-05 02:49 +0200
Re: Epic Fail Hannu Vuolasaho <vuokkosetae@gmail.com> - 2014-04-04 17:46 -0700
Re: Epic Fail "Elizabeth D. Rather" <erather@forth.com> - 2014-04-04 21:59 -1000
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-05 08:51 +0000
Re: Epic Fail "Alex McDonald" <blog@rivadpm.com> - 2014-04-05 14:45 +0100
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-05 16:01 -0700
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-05 19:22 -0700
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-06 10:46 +0100
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-06 13:20 +0200
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-06 19:58 +0100
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-06 12:28 -0700
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-06 16:40 -0400
Re: Epic Fail "Alex McDonald" <blog@rivadpm.com> - 2014-04-06 22:04 +0100
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-06 23:25 +0200
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-06 23:48 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-06 15:17 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-07 00:08 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-06 15:34 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-07 00:29 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-06 16:01 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-07 00:58 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-06 16:29 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-07 01:33 +0200
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-07 01:58 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-06 19:33 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-07 04:40 +0200
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-07 04:25 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-06 20:19 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-07 11:23 +0200
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-07 03:24 -0500
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-07 11:18 +0200
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-07 05:20 -0500
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-07 14:49 +0200
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-07 08:43 -0500
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-07 20:27 +0200
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-07 02:57 -0500
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-07 10:00 +0000
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-07 16:10 +0200
Re: Epic Fail m.a.m.hendrix@tue.nl - 2014-04-07 07:54 -0700
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-07 22:59 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-07 15:07 -0700
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-07 15:13 -0700
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-08 00:40 +0200
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-07 01:02 +0100
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-08 10:49 -0700
Re: Epic Fail "Alex McDonald" <blog@rivadpm.com> - 2014-04-08 19:01 +0100
Re: Epic Fail "Elizabeth D. Rather" <erather@forth.com> - 2014-04-08 08:13 -1000
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-08 20:34 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-08 12:04 -0700
[OT] Haskell code Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-09 00:42 +0200
Re: [OT] Haskell code Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-08 18:14 -0700
Re: [OT] Haskell code Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-08 18:15 -0700
Re: [OT] Haskell code Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-09 03:10 +0200
Re: [OT] Haskell code Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-08 18:35 -0700
Re: [OT] Haskell code Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-09 03:17 +0200
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-06 16:48 -0500
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-06 15:30 -0700
Re: Epic Fail Lars Brinkhoff <lars.spam@nocrew.org> - 2014-04-07 11:26 +0200
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-07 05:21 -0500
Re: Epic Fail "Alex McDonald" <blog@rivadpm.com> - 2014-04-07 17:54 +0100
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-07 12:14 -0500
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-07 16:49 +0000
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-07 09:37 +0000
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-06 08:43 -0700
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-07 12:53 +0000
Re: Epic Fail mhx@iae.nl - 2014-04-06 00:09 -0700
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-06 13:12 +0000
Re: Epic Fail mhx@iae.nl - 2014-04-06 07:55 -0700
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-07 10:18 +0000
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-06 08:21 -0700
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-06 08:30 -0700
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-06 22:12 +0200
Re: Epic Fail "Elizabeth D. Rather" <erather@forth.com> - 2014-04-06 12:08 -1000
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-06 16:44 -0700
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-06 22:03 -0700
Re: Epic Fail Stefan Mauerhofer <smauerhofer@androsoft.ch> - 2014-04-07 01:29 -0700
locals in nested definitions (was: Epic Fail) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-07 16:57 +0000
Re: Epic Fail mhx@iae.nl - 2014-04-07 11:48 -0700
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-07 22:54 +0200
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-08 00:04 -0700
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-07 14:12 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-07 21:23 -0700
Re: Epic Fail "Elizabeth D. Rather" <erather@forth.com> - 2014-04-07 19:33 -1000
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-07 23:52 -0700
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-08 09:07 +0100
Re: Epic Fail "Alex McDonald" <blog@rivadpm.com> - 2014-04-08 12:35 +0100
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-08 16:21 +0000
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-08 16:33 -0400
Re: Epic Fail "Alex McDonald" <blog@rivadpm.com> - 2014-04-08 23:41 +0100
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-08 22:47 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-08 10:43 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-08 07:22 -0700
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-08 10:12 -0500
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-08 08:58 -0700
Re: Epic Fail "Elizabeth D. Rather" <erather@forth.com> - 2014-04-08 08:02 -1000
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-08 23:07 -0700
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-08 10:21 +0000
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-08 15:32 +0200
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-08 17:46 -0400
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-09 01:06 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-08 18:06 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-09 02:56 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-08 18:17 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-09 03:24 +0200
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-09 02:22 -0400
Re: Epic Fail Ron Aaron <rambamist@gmail.com> - 2014-04-09 17:07 +0300
Re: Epic Fail the_gavino_himself <visphatesjava@gmail.com> - 2014-04-09 03:48 -0700
Re: Epic Fail Ron Aaron <rambamist@gmail.com> - 2014-04-07 07:17 +0300
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-07 22:52 +0200
Re: Epic Fail Mark Wills <markwills1970@gmail.com> - 2014-04-07 03:53 -0700
Re: Epic Fail the_gavino_himself <visphatesjava@gmail.com> - 2014-04-08 16:24 -0700
Re: Epic Fail the_gavino_himself <visphatesjava@gmail.com> - 2014-04-08 16:45 -0700
Re: Epic Fail kerdezixe@gmail.com - 2014-04-29 11:15 -0700
Re: Epic Fail Laurent Laborde <kerdezixe@gmail.com> - 2014-04-29 11:21 -0700
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-29 20:46 +0200
Re: Epic Fail Laurent Laborde <kerdezixe@gmail.com> - 2014-04-29 12:27 -0700
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-29 23:13 +0200
Re: Epic Fail Laurent Laborde <kerdezixe@gmail.com> - 2014-04-30 00:04 -0700
Re: Epic Fail Mark Wills <markwills1970@gmail.com> - 2014-04-30 00:54 -0700
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-30 03:08 -0500
Re: Epic Fail Laurent Laborde <kerdezixe@gmail.com> - 2014-04-30 02:30 -0700
Re: Epic Fail AKK <akk@nospam.org> - 2014-04-29 20:48 +0200
Re: Epic Fail stephenXXX@mpeforth.com (Stephen Pelc) - 2014-04-29 19:09 +0000
Re: Epic Fail "Elizabeth D. Rather" <erather@forth.com> - 2014-04-29 09:23 -1000
Re: Epic Fail Laurent Laborde <kerdezixe@gmail.com> - 2014-04-29 12:43 -0700
Re: Epic Fail "Elizabeth D. Rather" <erather@forth.com> - 2014-04-29 11:23 -1000
Re: Epic Fail Laurent Laborde <kerdezixe@gmail.com> - 2014-04-29 22:52 -0700
Page 11 of 19 — ← Prev page 1 … 9 10 [11] 12 13 … 19 Next page →
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-04-22 17:40 +0000 |
| Message-ID | <2014Apr22.194051@mips.complang.tuwien.ac.at> |
| In reply to | #29751 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>
>> But of course you are free to show the superiority of this approach.
>> E.g., you could start with the current Gforth and replace all the
>> non-Forth parts with Forth parts. It will be interesting to see how
>> you replace various parts, e.g. libltdl.
>
>libltdl is just onion programming of the GNU project around direct access to
>shared libraries like dlopen and dlsym (of course you need to link your
>executable with libdl.so first to be able to use these functions ;-).
Sure, the task includes replacing libdl (which is also not written in
Forth) on those platforms where libltdl calls libdl functions, and
that's probably much harder than just replacing the outer layer of the
onion.
>On
>reasonable OSes, where these calls work as they should, there is no reason
>for libltdl, and the unreasonable OSes aren't that important anymore.
But since we are not Microsoft and not just interested in the 95%
solution, we also want to support the unreasonable systems if the
effort is reasonable, and thanks to libltdl it is reasonable.
- 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-22 20:47 +0200 |
| Message-ID | <lj6dg4$7rd$1@online.de> |
| In reply to | #29778 |
Anton Ertl wrote: > Bernd Paysan <bernd.paysan@gmx.de> writes: >>On >>reasonable OSes, where these calls work as they should, there is no reason >>for libltdl, and the unreasonable OSes aren't that important anymore. > > But since we are not Microsoft and not just interested in the 95% > solution, we also want to support the unreasonable systems if the > effort is reasonable, and thanks to libltdl it is reasonable. Well, POSIX has dlopen. It also works on Darwin, even though they have another Darwin-specific mechanism, which libltdl uses. HP-UX uses shl_load instead, but I would consider HP-UX as mostly history now, and I certainly won't write a backend for Itanic, either (it certainly wasn't history when we started Gforth). BeOS is another OS that doesn't have dlopen, and there's of course Windows, but on Windows, we use Cygwin as POSIX wrapper, which again gives us dlopen. The good thing about waiting long enough is that some compatibility problems go away, because the incompatible systems die out. In any case, I consider libltdl a problematic approach, because instead of providing a standardized interface (dlopen/dlsym) on systems that don't have it, they added another interface. Which is doing exactly the same thing, but under a different name. And even libltdl is not readily available everywhere (e.g. I don't use it on Android, because it would cause too much trouble...), so we ended up at wrapping libltdl, libdl and the Win32 calls into another support function of our own (called gforth_dlopen/gforth_dlsym, which take Forth strings instead of C strings, and therefore has a different API than all the other ones ;-). -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-04-19 11:34 +0000 |
| Message-ID | <53525f40$0$27137$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #29704 |
In article <vs-dnSmUiZsvyMzOnZ2dnUVZ8uadnZ2d@supernews.com>, Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: >Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>>>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>>>>>>I don't believe that this is generally true: AIUI code quality is >>>>>>>measured regularly and is not decreasing. >>>>>> >>>>>> Looking at Figure 7 and 8 of >>>>>> >>>>>> http://www.complang.tuwien.ac.at/anton/euroforth/ef09/papers/ertl.pdf >>>>>> >>>>>> you can see that Gforth 0.6.2 is much slower on newer gccs than on >>>>>> older ones. >>>>> >>>>>Well, yes, but that's GForth, which as discussed is written neither in >>>>>Standard C or GNU C. >>>> ... >>>>>> How do you measure code quality? >>>>> >>>>>There's a bunch of industry-standard benchmarks. AFAIK SPECint is the >>>>>best general-purpose one. >>>> >>>> And SPECint is not written in Standard C, either, as was widely >>>> publicized. As for "GNU C", has the non-standard compliant behaviour >>>> of SPECint been documented as a GNU C feature? >>> >>>IIRC it turned out that the optimization which broke SPECint wasn't >>>really a useful optimization at all, so there was no point keeping it. >> >> As evalutated with SPECint, which was broken by the optimization? > >No. > >>>>>Probably. And it might even make GForth into what it should have >>>>>been in the first place. >>>> >>>> What is that, IYO? >>> >>>A Forth system written in Forth. >> >> Why do you think that Gforth should have been that in the first place? > >It's my personal preference, I suppose. IME Forth written in Forth is >easier to explore, easier to understand, and easier to change. >Because of this Forth is a great tool for learning how to bootstrap >systems. If you depend on non-Forth you lose all of these advantages. The alternative to Gforth is what I do in ciforth, define all low level words in assembler by hand, define the threading mechanism in assembler, define the looping mechanism in assembler. By saying defined in Forth, you muddy the waters. I'd say defined in assembler, this way like Gforth ciforth admits to using external tools to get the executables right, either a c-compiler plus linker or an assembler plus linker. If you really do everything in Forth, then you have to write an ELF as well as a COFF toolkit in Forth, an awesome and unfruitful undertaking, and it still restricted to linux and window. Whether that is called "written in Forth" or "written in assembler" is immaterial. I can see the advantages of that, but I can surely see the advantages of the Gforth approach, and for their stated purpose it certainly was the right choice, even if there is doubt now. I'd say that ciforth is easier on the accounts you mention, but most -- if not all -- is caused by being simpler. I think that is the great advantage of using c as a portable assembler, the same reason all other languages build on c, having one place to handle all object file, executable and linking stuff, beside the backend code generation. > >Andrew. Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-04-19 16:05 -0500 |
| Message-ID | <s5GdnbdIpfqdeM_OnZ2dnUVZ_smdnZ2d@supernews.com> |
| In reply to | #29719 |
Albert van der Horst <albert@spenarnc.xs4all.nl> wrote: > In article <vs-dnSmUiZsvyMzOnZ2dnUVZ8uadnZ2d@supernews.com>, > Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>>>A Forth system written in Forth. >>> >>> Why do you think that Gforth should have been that in the first place? >> >>It's my personal preference, I suppose. IME Forth written in Forth is >>easier to explore, easier to understand, and easier to change. >>Because of this Forth is a great tool for learning how to bootstrap >>systems. If you depend on non-Forth you lose all of these advantages. > > The alternative to Gforth is what I do in ciforth, define all low level > words in assembler by hand, define the threading mechanism in assembler, > define the looping mechanism in assembler. > By saying defined in Forth, you muddy the waters. I'd say defined in > assembler, this way like Gforth ciforth admits to using external tools > to get the executables right, either a c-compiler plus linker or an > assembler plus linker. Sure, that's OK until you get the Forth bootstrap going. > If you really do everything in Forth, then you have to write an ELF > as well as a COFF toolkit in Forth, an awesome and unfruitful > undertaking, and it still restricted to linux and window. That's no big deal, really: you only need a skeleton subset of ELF. You can always write a simple bootstrap loader in a few lines of assembly if you really care. But the question of whether you have to leave the Forth environment to change Forth really is important, IMO. I've done it both ways, and Forth-in-Forth is better if you want to make experimental changes. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-04-20 12:38 +0000 |
| Message-ID | <2014Apr20.143830@mips.complang.tuwien.ac.at> |
| In reply to | #29721 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>But the question of whether you have to
>leave the Forth environment to change Forth really is important, IMO.
>I've done it both ways, and Forth-in-Forth is better if you want to
>make experimental changes.
That's not at all clear to me. What kind of changes do you refer to,
and how is Forth-in-Forth better there? And what do you mean with
"having to leave the Forth environment"; is using my favourite editor
a sin?
When changing Gforth, I found the harshest environment to be the
cross-compiler (written in Forth, compiling something Forth-like).
That's because nearly all of the things I usually use in Forth are not
available there: it takes an extra compile step, does not support
interactive testing, etc.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2013: http://www.euroforth.org/ef13/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-04-20 11:42 -0500 |
| Message-ID | <3o6dnS3TxfJjZc7OnZ2dnUVZ_qmdnZ2d@supernews.com> |
| In reply to | #29731 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>But the question of whether you have to >>leave the Forth environment to change Forth really is important, IMO. >>I've done it both ways, and Forth-in-Forth is better if you want to >>make experimental changes. > > That's not at all clear to me. What kind of changes do you refer to, > and how is Forth-in-Forth better there? Any kind of change to the kernel: e.g change of threading, adding hooks to do profiling and tracing, etc, etc. Things that it should be possible to code in a few minutes and compile in a couple of seconds. > And what do you mean with "having to leave the Forth environment"; > is using my favourite editor a sin? No. I'm talking about the bag of tools and languages: compilers, linkers, makefiles, and so on. > When changing Gforth, I found the harshest environment to be the > cross-compiler (written in Forth, compiling something Forth-like). > That's because nearly all of the things I usually use in Forth are not > available there: it takes an extra compile step, does not support > interactive testing, etc. Hmm, interesting. And rather surprising. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-04-20 12:11 -0500 |
| Message-ID | <SKKdnYSG7elGYs7OnZ2dnUVZ_oidnZ2d@supernews.com> |
| In reply to | #29736 |
Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: > Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>>But the question of whether you have to >>>leave the Forth environment to change Forth really is important, IMO. >>>I've done it both ways, and Forth-in-Forth is better if you want to >>>make experimental changes. >> >> That's not at all clear to me. What kind of changes do you refer to, >> and how is Forth-in-Forth better there? > > Any kind of change to the kernel: e.g change of threading, adding > hooks to do profiling and tracing, etc, etc. Things that it should be > possible to code in a few minutes Well, hours in the case of a change in threading. :-) > and compile in a couple of seconds. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-04-20 17:23 +0000 |
| Message-ID | <53540277$0$24957$e4fe514c@dreader36.news.xs4all.nl> |
| In reply to | #29737 |
In article <SKKdnYSG7elGYs7OnZ2dnUVZ_oidnZ2d@supernews.com>, Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: >Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: >> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>>>But the question of whether you have to >>>>leave the Forth environment to change Forth really is important, IMO. >>>>I've done it both ways, and Forth-in-Forth is better if you want to >>>>make experimental changes. >>> >>> That's not at all clear to me. What kind of changes do you refer to, >>> and how is Forth-in-Forth better there? >> >> Any kind of change to the kernel: e.g change of threading, adding >> hooks to do profiling and tracing, etc, etc. Things that it should be >> possible to code in a few minutes > >Well, hours in the case of a change in threading. :-) Cranking out a direct threaded ciforth in three hours? I take that challenge on a good day (I'm a heart patient). This includes pdf html info documentation and the regression test. You severely underestimate for how much familiarity with the tools count. > >> and compile in a couple of seconds. Easily, even on my 90 Mhz Pentium development machine. > >Andrew. -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-04-20 11:58 -0700 |
| Message-ID | <18254d9a-e8e0-44ac-86a0-3f0aaa21b521@googlegroups.com> |
| In reply to | #29736 |
On Sunday, April 20, 2014 9:42:38 AM UTC-7, Andrew Haley wrote: > Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > > When changing Gforth, I found the harshest environment to be the > > cross-compiler (written in Forth, compiling something Forth-like). > > That's because nearly all of the things I usually use in Forth are not > > available there: it takes an extra compile step, does not support > > interactive testing, etc. > > Hmm, interesting. And rather surprising. I find that surprising too. In my experience, writing a cross-compiler is difficult as it is pretty complicated, but all of the complication is buried out of sight for the user --- programming in a cross-compiler is easier than programming in a stand-alone Forth (primarily for the reason I described earlier: that it is easy to distinguish between compile-time and run-time words by their xt). I haven't the slightest idea what Anton means by there being an "extra compile step." Interactive testing is an admitted problem. I didn't have that in MFX. I did have a simulator for the MiniForth processor, but it was like a single-step source-level debugger used in C, rather than a typical outer-interpreter used in Forth. After I left Testra, they wrote a stand-alone Forth in MFX that could be used for more traditional interactive Forth development. MFX would still be needed for writing code words though. I don't think the interactive-testing problem is insurmountable. I would do this by writing a stand-alone Forth system with a umbilical cord to the desktop computer so the dictionary can reside there to save memory on the micro-controller. The stand-alone Forth doesn't have to do any optimization (this also saves memory on the micro-controller) --- it is just for testing --- production code would be generated by the cross-compiler. I remember that Jeff Fox asked me if I had read the Forth-200x document on cross-compiling. I said no. He said to not bother, as it was grossly over-complicated. He said that people who don't understand a subject will tend to make it much more complicated than it needs to be. That seems to be a chronic problem with the Forth-200x committee --- everything they do is over-complicated and hard-to-explain --- it is no wonder that novices give up on learning Forth (I would too, if I were 18YO now, rather than 18YO in 1984 before Gforth existed and all Forths were still in assembly-language).
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-04-21 10:21 +0000 |
| Message-ID | <2014Apr21.122143@mips.complang.tuwien.ac.at> |
| In reply to | #29736 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>But the question of whether you have to
>>>leave the Forth environment to change Forth really is important, IMO.
>>>I've done it both ways, and Forth-in-Forth is better if you want to
>>>make experimental changes.
>>
>> That's not at all clear to me. What kind of changes do you refer to,
>> and how is Forth-in-Forth better there?
>
>Any kind of change to the kernel: e.g change of threading, adding
>hooks to do profiling and tracing, etc, etc. Things that it should be
>possible to code in a few minutes and compile in a couple of seconds.
1) Change of threading: In Gforth that is in the engine, and it
requires changing C code to do it. That's relatively easy, and we
have done so a lot over the years, probably more than any other Forth
system: First we just had indirect threading, but we added direct
threading quite soon (with platform-specific support). Then we needed
relocatable images, and added double-indirect threading for creating
them. Switching to primitive-centric hybrid direct/indirect threaded
code eliminated the platform dependence of direct-threaded code as
well as getting rid of I-cache consistency slowdowns on IA-32 CPUs
with separate I-cache
<http://www.complang.tuwien.ac.at/papers/ertl02.ps.gz>. It also
paved the way to dynamic superinstructions, which might be seen as
another threading change; we also added static superinstructions and
static stack caching, but that's beyond what I would normally consider
threading.
If Gforth was implemented in the classical Forth-in-Forth way
(assembler in Forth, NEXT written in assembly language), this would
all have been much more work to write and to test, because we would
have to implement the new threading separately for each platform. We
probably would not have all the stuff mentioned above.
OTOH, this stuff is also contributing to the complexity that makes
Gforth harder to understand; there are additional abstractions in the
code, and conditional compilation for the various threading models.
2) Adding hooks to do profiling and tracing. I have done such things
both at the engine level (in the vmgen and C part), for specific
purposes, and at a higher level (in the Forth part). The engine-level
stuff was pretty easy, and was done quickly. I have not finished the
Forth profiler yet. Collecting some data is easy, presenting it in a
useful form is more work (for the specific purpose that the engine
stuff was used for the standards on that were lower).
There is also a stepping debugger that was done on the Forth level;
again, the stepping is easy, the majority of the work is in presenting
the steps to the user.
3) Concerning compilation speed: Typically Gforth takes a minute to
build including the engine, several seconds if source code in the
(cross-compiled) kernel changes, and a second or so if source code in
the non-cross-compiled part of the system changes. Interestingly,
this has not changed much in the last 20 years; the complexity of the
task grew and the tools became slower as computers became faster.
Anyway, yes, the prospect of waiting another minute for a change in
the engine sometimes had a restricting effect on me, but such moments
were rare; the engine was stable most of the time.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2013: http://www.euroforth.org/ef13/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-04-22 04:58 -0500 |
| Message-ID | <lPKdnXz2p_CyoMvOnZ2dnUVZ_smdnZ2d@supernews.com> |
| In reply to | #29747 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>>>But the question of whether you have to >>>>leave the Forth environment to change Forth really is important, IMO. >>>>I've done it both ways, and Forth-in-Forth is better if you want to >>>>make experimental changes. >>> >>> That's not at all clear to me. What kind of changes do you refer to, >>> and how is Forth-in-Forth better there? >> >>Any kind of change to the kernel: e.g change of threading, adding >>hooks to do profiling and tracing, etc, etc. Things that it should be >>possible to code in a few minutes and compile in a couple of seconds. > > 1) Change of threading: In Gforth that is in the engine, and it > requires changing C code to do it. That's relatively easy, and we > have done so a lot over the years Sure, once you know how to do it, and are familiar with the toolset, etc, etc. > If Gforth was implemented in the classical Forth-in-Forth way > (assembler in Forth, NEXT written in assembly language), this would > all have been much more work to write and to test, because we would > have to implement the new threading separately for each platform. > We probably would not have all the stuff mentioned above. Sure, but I'm not talking about ease of porting; I have no doubt that the approach you took made it easier to port. I'm talking about one user on one system wanting to make such a change, not the original author of a hightly-portable system. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-04-22 17:05 +0000 |
| Message-ID | <2014Apr22.190548@mips.complang.tuwien.ac.at> |
| In reply to | #29766 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> 1) Change of threading: In Gforth that is in the engine, and it
>> requires changing C code to do it. That's relatively easy, and we
>> have done so a lot over the years
>
>Sure, once you know how to do it, and are familiar with the toolset,
>etc, etc.
Sure, but the same is true for Forth-in-Forth.
>> If Gforth was implemented in the classical Forth-in-Forth way
>> (assembler in Forth, NEXT written in assembly language), this would
>> all have been much more work to write and to test, because we would
>> have to implement the new threading separately for each platform.
>> We probably would not have all the stuff mentioned above.
>
>Sure, but I'm not talking about ease of porting; I have no doubt that
>the approach you took made it easier to port. I'm talking about one
>user on one system wanting to make such a change, not the original
>author of a hightly-portable system.
The user may be interested in portability, too. If they are not, and
want to do this kind of thing, there are a number of Forth-in-Forth
systems that they could use.
Overall compared to our approach your approach would make such changes
harder for both us and for users interested in portability, and it
would not provide anything that other systems do not provide already.
Therefore it makes no sense to me that Gforth "should have been in the
first place" a Forth-in-Forth.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2013: http://www.euroforth.org/ef13/
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-04-20 17:12 +0000 |
| Message-ID | <53540000$0$24957$e4fe514c@dreader36.news.xs4all.nl> |
| In reply to | #29721 |
In article <s5GdnbdIpfqdeM_OnZ2dnUVZ_smdnZ2d@supernews.com>,
Andrew Haley <andrew29@littlepinkcloud.invalid> wrote:
>Albert van der Horst <albert@spenarnc.xs4all.nl> wrote:
>> In article <vs-dnSmUiZsvyMzOnZ2dnUVZ8uadnZ2d@supernews.com>,
>> Andrew Haley <andrew29@littlepinkcloud.invalid> wrote:
>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>>>A Forth system written in Forth.
>>>>
>>>> Why do you think that Gforth should have been that in the first place?
>>>
>>>It's my personal preference, I suppose. IME Forth written in Forth is
>>>easier to explore, easier to understand, and easier to change.
>>>Because of this Forth is a great tool for learning how to bootstrap
>>>systems. If you depend on non-Forth you lose all of these advantages.
>>
>> The alternative to Gforth is what I do in ciforth, define all low level
>> words in assembler by hand, define the threading mechanism in assembler,
>> define the looping mechanism in assembler.
>> By saying defined in Forth, you muddy the waters. I'd say defined in
>> assembler, this way like Gforth ciforth admits to using external tools
>> to get the executables right, either a c-compiler plus linker or an
>> assembler plus linker.
>
>Sure, that's OK until you get the Forth bootstrap going.
There you are. This illustrates why jonesforth is popular.
The idea that you make a Forth only to use it as a scaffolding is
a couple of DAN-grades (belts) away from the average starting
programmer in Forth or aspirate compiler-builder.
This is also the reason that if you want to modify ciforth there
are 4 different levels where you can jump in. The highest level
challenges an experienced meta-Forther, while the easiest level is
familiar to a moderately skilled embedded programmer.
Even so. You probably haven't studied jonesforth a bit, or you would
realize that the later versions have part in assembler, and the
remainder is in Forth. So it is not the diametrically opposed approach
you make it out to be.
>> If you really do everything in Forth, then you have to write an ELF
>> as well as a COFF toolkit in Forth, an awesome and unfruitful
>> undertaking, and it still restricted to linux and window.
>
>That's no big deal, really: you only need a skeleton subset of ELF.
>You can always write a simple bootstrap loader in a few lines of
>assembly if you really care. But the question of whether you have to
>leave the Forth environment to change Forth really is important, IMO.
>I've done it both ways, and Forth-in-Forth is better if you want to
>make experimental changes.
Been there. Simple changes to ELF headers, such as fully allowed by
the ELF documents will make ELF-tools balk on your executables.
So the simple question, dump my header such that I can see what I'm
doing, may fail. If you use strip (a gcc tool) on an executable
that is not generated by a gcc tool, you risk ending with an
empty file. Good luck getting a bug report accepted for that.
So there is much more to it, than just generating a valid header.
Understanding ELF itself is a bear. You only need one A4 worth of
information extracted from ELF, but it takes more time to extract that
than I needed to port ciforth to 64 bits using my generic tools and
fasm.
fasm takes care of ELF 64 for me by the incantation:
FORMAT ELF64
( O o _ o O )
Instead of criticizing jonesforth I've worked on a better alternative
called yourforth.
A couple of lines from yourforth:
; To build:
; wget http://flatassembler.net/fasm-1.70.03.tgz; tar xfz fasm-1.70.03.tgz; fasm/fasm yourforth.fas
; That is right. Not only did you brew coffee, you've been to Columbia, picked the beans,
; and roasted them as well! Next time you only need "fasm/fasm yourforth.fas".
; If you're new at Forth you may want to read the Chapter "gentle introduction"
; of yourforth.pdf.
That's right. It is one line to get the assembler package, install it
*and* build a yourforth executable. And an even simpler command -- that one just
might remember by heart -- to repeat the action, once installed.
Now that is the kind of effort people might be lured to expend to get
started with their own compiler. Learning ELF. Cheese! There is no need
for a yourforther to have a clue about ELF. There is sooooo much else
to learn, that has actually a relation to Forth.
>
>Andrew.
Groetjes Albert
(yourforth is in the Cloud. Just google for it.)
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-04-20 19:47 -0400 |
| Message-ID | <op.xem21ngt6zenlw@localhost> |
| In reply to | #29738 |
On Sun, 20 Apr 2014 13:12:32 -0400, Albert van der Horst <albert@spenarnc.xs4all.nl> wrote: > In article <s5GdnbdIpfqdeM_OnZ2dnUVZ_smdnZ2d@supernews.com>, > Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: >> Albert van der Horst <albert@spenarnc.xs4all.nl> wrote: >>> The alternative to Gforth is what I do in ciforth, define all low level >>> words in assembler by hand, define the threading mechanism in >>> assembler, >>> define the looping mechanism in assembler. By saying defined in Forth, >>> you muddy the waters. I'd say defined in assembler, this way like >>> Gforth >>> ciforth admits to using external tools to get the executables right, >>> either a c-compiler plus linker or an assembler plus linker. >> >> Sure, that's OK until you get the Forth bootstrap going. > > There you are. This illustrates why jonesforth is popular. > The idea that you make a Forth only to use it as a scaffolding is > a couple of DAN-grades (belts) away from the average starting > programmer in Forth or aspirate compiler-builder. > Exactly, in addition to the "primitives" (low-level) words, you need a handful of high-level Forth definitions, pre-compiled, to bootstrap Forth, such as FIND : ; as well as the inner and outer interpreters. A novice is nowhere near ready to implement the more difficult components. Of course, Andrew knows this, or he should, having done so ... The real advantage of a Forth like Jonesforth is that it's coded in assembly for a widely available x86 assembler, which means it can be compiled for a variety of different operating systems, or it can be fixed easily. The hard work of implementing the low-level stuff is finished. I.e., it's a throw-back to the fig-Forths in assembly of yesteryear. It's easy for a novice to get working. Assemble and go. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-04-22 05:03 -0500 |
| Message-ID | <WtGdnStmxf37o8vOnZ2dnUVZ_uadnZ2d@supernews.com> |
| In reply to | #29738 |
Albert van der Horst <albert@spenarnc.xs4all.nl> wrote: > > Even so. You probably haven't studied jonesforth a bit, or you would > realize that the later versions have part in assembler, and the > remainder is in Forth. So it is not the diametrically opposed approach > you make it out to be. I don't think I've said that it is a diametrically opposed approach. I have said that the kernel is written in assembler, and for that reason it is a PITA to work on. >>> If you really do everything in Forth, then you have to write an ELF >>> as well as a COFF toolkit in Forth, an awesome and unfruitful >>> undertaking, and it still restricted to linux and window. >> >>That's no big deal, really: you only need a skeleton subset of ELF. >>You can always write a simple bootstrap loader in a few lines of >>assembly if you really care. But the question of whether you have to >>leave the Forth environment to change Forth really is important, IMO. >>I've done it both ways, and Forth-in-Forth is better if you want to >>make experimental changes. > > Been there. Simple changes to ELF headers, such as fully allowed by > the ELF documents will make ELF-tools balk on your executables. So > the simple question, dump my header such that I can see what I'm > doing, may fail. If you use strip (a gcc tool) No it isn't. > on an executable that > is not generated by a gcc tool, you risk ending with an empty file. a. No GCC tool generates executables, and b. So don't do that, then. > Good luck getting a bug report accepted for that. I'd just fix the bug. > Now that is the kind of effort people might be lured to expend to get > started with their own compiler. Learning ELF. Cheese! What has any of this to do with people writing their own Forth? Are we supposed to be encouraging people to write yet more Forths? Why? Andrew.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-04-22 11:51 +0000 |
| Message-ID | <535657da$0$27157$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #29768 |
In article <WtGdnStmxf37o8vOnZ2dnUVZ_uadnZ2d@supernews.com>, Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: >Albert van der Horst <albert@spenarnc.xs4all.nl> wrote: >> >> Even so. You probably haven't studied jonesforth a bit, or you would >> realize that the later versions have part in assembler, and the >> remainder is in Forth. So it is not the diametrically opposed approach >> you make it out to be. > >I don't think I've said that it is a diametrically opposed approach. >I have said that the kernel is written in assembler, and for that >reason it is a PITA to work on. > >>>> If you really do everything in Forth, then you have to write an ELF >>>> as well as a COFF toolkit in Forth, an awesome and unfruitful >>>> undertaking, and it still restricted to linux and window. >>> >>>That's no big deal, really: you only need a skeleton subset of ELF. >>>You can always write a simple bootstrap loader in a few lines of >>>assembly if you really care. But the question of whether you have to >>>leave the Forth environment to change Forth really is important, IMO. >>>I've done it both ways, and Forth-in-Forth is better if you want to >>>make experimental changes. >> > >> Been there. Simple changes to ELF headers, such as fully allowed by >> the ELF documents will make ELF-tools balk on your executables. So >> the simple question, dump my header such that I can see what I'm >> doing, may fail. If you use strip (a gcc tool) > >No it isn't. > >> on an executable that >> is not generated by a gcc tool, you risk ending with an empty file. > >a. No GCC tool generates executables, and >b. So don't do that, then. > >> Good luck getting a bug report accepted for that. > >I'd just fix the bug. Really, fixing bugs in GNU tools? Mere mortals can't pull that off. (I could though.) Let's make it more concrete. I've this yourforth which is supposedly the simplest forth in assembler. One segment. It assembles in under a millisecond: " albert@cherry:~/PROJECT/yourforth$ time fasm yourforth.fas flat assembler version 1.70.03 (16384 kilobytes memory) 2 passes, 15197 bytes. real 0m0.008s user 0m0.000s sys 0m0.008s albert@cherry:~/PROJECT/yourforth$ file yourforth yourforth: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), \ statically linked, stripped " Are you with me? So far so good. (This Forth passes a regression test, and even Hayes suite, after loading a lot of extensions.) " albert@cherry:~/PROJECT/yourforth$ strip yourforth albert@cherry:~/PROJECT/yourforth$ ls -l yourforth -rwxr-xr-x 1 albert albert 176 Apr 22 13:14 yourforth albert@cherry:~/PROJECT/yourforth$ yourforth Segmentation fault " So the gnu tool `` strip '' fails a simple test on the simplest of Forths. It just has to conclude that there are no symbols and leave. Instead it trims it to an unbelievable 176 bytes. I'm not inspired to fix this bug. If the writers of the program cannot come up with the idea to test it on a program that is as simple as this, I'm pretty sure I'll end up with rewriting the tool myself. (All this on Debian stable 64-bit, same result on a stone age Suse.) > >> Now that is the kind of effort people might be lured to expend to get >> started with their own compiler. Learning ELF. Cheese! > >What has any of this to do with people writing their own Forth? Are >we supposed to be encouraging people to write yet more Forths? Why? Okay let's deter people from writing their own Forths by requiring ELF expertise. ;-) The curriculums surely should have assignments to write a simple compiler. Enough Eclipse already! > >Andrew. -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-04-22 08:28 -0500 |
| Message-ID | <3Zmdndi2EdYO88vOnZ2dnUVZ_sSdnZ2d@supernews.com> |
| In reply to | #29771 |
In comp.lang.forth Albert van der Horst <albert@spenarnc.xs4all.nl> wrote: > In article <WtGdnStmxf37o8vOnZ2dnUVZ_uadnZ2d@supernews.com>, > > I've this yourforth which is supposedly the simplest forth in > assembler. One segment. It assembles in under a millisecond: > > " > albert@cherry:~/PROJECT/yourforth$ time fasm yourforth.fas > flat assembler version 1.70.03 (16384 kilobytes memory) > 2 passes, 15197 bytes. > > real 0m0.008s > user 0m0.000s > sys 0m0.008s Looks like 8 milliseconds to me, but OK. :-) > albert@cherry:~/PROJECT/yourforth$ file yourforth > yourforth: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), \ > statically linked, stripped > " > > Are you with me? So far so good. (This Forth passes a regression test, > and even Hayes suite, after loading a lot of extensions.) > " > albert@cherry:~/PROJECT/yourforth$ strip yourforth > albert@cherry:~/PROJECT/yourforth$ ls -l yourforth > -rwxr-xr-x 1 albert albert 176 Apr 22 13:14 yourforth > albert@cherry:~/PROJECT/yourforth$ yourforth > Segmentation fault > " > > So the gnu tool `` strip '' fails a simple test on the simplest of Forths. > It just has to conclude that there are no symbols and leave. Instead it > trims it to an unbelievable 176 bytes. > > I'm not inspired to fix this bug. If the writers of the program cannot > come up with the idea to test it on a program that is as simple as > this, I'm pretty sure I'll end up with rewriting the tool myself. There are two possibilities: yourforth isn't a real ELF file, or strip has a bug, or both. But why do you want to strip it? > (All this on Debian stable 64-bit, same result on a stone age Suse.) > >>> Now that is the kind of effort people might be lured to expend to get >>> started with their own compiler. Learning ELF. Cheese! >> >>What has any of this to do with people writing their own Forth? Are >>we supposed to be encouraging people to write yet more Forths? Why? > > Okay let's deter people from writing their own Forths by requiring > ELF expertise. ;-) > > The curriculums surely should have assignments to write a simple > compiler. Enough Eclipse already! We seem to be talking completely at cross purposes. If you want a Forth that's super-easy to write, then write it in assembler. Or in C. Or in Python, even. But I'm not talking about a Forth that's super-easy to write: I'm talking about how to get the best result, IMO. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-04-22 15:02 +0000 |
| Message-ID | <5356847d$0$25058$e4fe514c@dreader37.news.xs4all.nl> |
| In reply to | #29773 |
In article <3Zmdndi2EdYO88vOnZ2dnUVZ_sSdnZ2d@supernews.com>, Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: >In comp.lang.forth Albert van der Horst <albert@spenarnc.xs4all.nl> wrote: >> In article <WtGdnStmxf37o8vOnZ2dnUVZ_uadnZ2d@supernews.com>, >> >> I've this yourforth which is supposedly the simplest forth in >> assembler. One segment. It assembles in under a millisecond: >> >> " >> albert@cherry:~/PROJECT/yourforth$ time fasm yourforth.fas >> flat assembler version 1.70.03 (16384 kilobytes memory) >> 2 passes, 15197 bytes. >> >> real 0m0.008s >> user 0m0.000s >> sys 0m0.008s > >Looks like 8 milliseconds to me, but OK. :-) > >> albert@cherry:~/PROJECT/yourforth$ file yourforth >> yourforth: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), \ >> statically linked, stripped >> " >> >> Are you with me? So far so good. (This Forth passes a regression test, >> and even Hayes suite, after loading a lot of extensions.) >> " >> albert@cherry:~/PROJECT/yourforth$ strip yourforth >> albert@cherry:~/PROJECT/yourforth$ ls -l yourforth >> -rwxr-xr-x 1 albert albert 176 Apr 22 13:14 yourforth >> albert@cherry:~/PROJECT/yourforth$ yourforth >> Segmentation fault >> " >> >> So the gnu tool `` strip '' fails a simple test on the simplest of Forths. >> It just has to conclude that there are no symbols and leave. Instead it >> trims it to an unbelievable 176 bytes. >> >> I'm not inspired to fix this bug. If the writers of the program cannot >> come up with the idea to test it on a program that is as simple as >> this, I'm pretty sure I'll end up with rewriting the tool myself. > >There are two possibilities: yourforth isn't a real ELF file, or strip >has a bug, or both. But why do you want to strip it? To reveal a bug. Is that sufficient reason? >Andrew. Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-04-22 13:23 -0500 |
| Message-ID | <QNWdnaVFOeUhLsvOnZ2dnUVZ_q-dnZ2d@supernews.com> |
| In reply to | #29775 |
Albert van der Horst <albert@spenarnc.xs4all.nl> wrote: > In article <3Zmdndi2EdYO88vOnZ2dnUVZ_sSdnZ2d@supernews.com>, > Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: >>In comp.lang.forth Albert van der Horst <albert@spenarnc.xs4all.nl> wrote: >>> I'm not inspired to fix this bug. If the writers of the program cannot >>> come up with the idea to test it on a program that is as simple as >>> this, I'm pretty sure I'll end up with rewriting the tool myself. >> >>There are two possibilities: yourforth isn't a real ELF file, or strip >>has a bug, or both. But why do you want to strip it? > > To reveal a bug. Is that sufficient reason? I rather imagined that there was some purpose to all this, and that strip not working on the Forth executable was some sort of impediment to getting work done. But the fact that strip breaks on some very simple ELF files isn't evidence of anything except a bug in strip that no-one has come across before. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.invalid> |
|---|---|
| Date | 2014-04-22 19:19 +0200 |
| Message-ID | <lj68ag$g1g$1@solani.org> |
| In reply to | #29773 |
On Tue, 22 Apr 2014 08:28:51 -0500 Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: > In comp.lang.forth Albert van der Horst <albert@spenarnc.xs4all.nl> > > > albert@cherry:~/PROJECT/yourforth$ file yourforth > > yourforth: ELF 32-bit LSB executable, Intel 80386, version 1 > > (SYSV), \ statically linked, stripped > > " > > > > Are you with me? So far so good. (This Forth passes a regression > > test, and even Hayes suite, after loading a lot of extensions.) > > " > > albert@cherry:~/PROJECT/yourforth$ strip yourforth > > albert@cherry:~/PROJECT/yourforth$ ls -l yourforth > > -rwxr-xr-x 1 albert albert 176 Apr 22 13:14 yourforth > > albert@cherry:~/PROJECT/yourforth$ yourforth > > Segmentation fault > > " > > > > So the gnu tool `` strip '' fails a simple test on the simplest of > > Forths. It just has to conclude that there are no symbols and > > leave. Instead it trims it to an unbelievable 176 bytes. > > > > I'm not inspired to fix this bug. If the writers of the program > > cannot come up with the idea to test it on a program that is as > > simple as this, I'm pretty sure I'll end up with rewriting the tool > > myself. > > There are two possibilities: yourforth isn't a real ELF file, or strip > has a bug, or both. But why do you want to strip it? file utility recognize fasm generated elfs as already stripped. readelf also displays file contents correctly. strip has a problem with them and I guess not only with them. eg bmaxa@maxa:~/examples/assembler$ fasm hello.asm flat assembler version 1.71.17 (16384 kilobytes memory) 3 passes, 266 bytes. bmaxa@maxa:~/examples/assembler$ ls -l hello -rwxr-xr-x 1 bmaxa bmaxa 266 Apr 22 19:17 hello bmaxa@maxa:~/examples/assembler$ file hello hello: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, stripped bmaxa@maxa:~/examples/assembler$ strip hello bmaxa@maxa:~/examples/assembler$ file hello hello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, stripped bmaxa@maxa:~/examples/assembler$ ls -l hello -rwxr-xr-x 1 bmaxa bmaxa 320 Apr 22 19:17 hello bmaxa@maxa:~/examples/assembler$ ./hello Segmentation fault strip definitely corrupts file... -- Click OK to continue...
[toc] | [prev] | [next] | [standalone]
Page 11 of 19 — ← Prev page 1 … 9 10 [11] 12 13 … 19 Next page →
Back to top | Article view | comp.lang.forth
csiph-web