Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #58987 > unrolled thread
| Started by | lehs <skydda.barnen@gmail.com> |
|---|---|
| First post | 2017-05-10 08:21 -0700 |
| Last post | 2017-05-15 11:23 +0000 |
| Articles | 20 on this page of 215 — 25 participants |
Back to article view | Back to comp.lang.forth
Would ?EXIT work in all ANS-Forth systems? lehs <skydda.barnen@gmail.com> - 2017-05-10 08:21 -0700
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-10 16:39 +0100
Re: Would ?EXIT work in all ANS-Forth systems? lehs <skydda.barnen@gmail.com> - 2017-05-10 08:46 -0700
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-10 16:04 +0000
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-11 04:22 -0500
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-11 10:35 +0100
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-11 05:08 -0500
Re: Would ?EXIT work in all ANS-Forth systems? Julian Fondren <julian.fondren@gmail.com> - 2017-05-11 03:51 -0700
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-11 07:02 -0500
Re: Would ?EXIT work in all ANS-Forth systems? rickman <gnuarm@gmail.com> - 2017-05-13 11:55 -0400
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-15 09:32 -0500
Re: Would ?EXIT work in all ANS-Forth systems? Cecil Bayona <cbayona@cbayona.com> - 2017-05-15 11:56 -0500
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-15 12:20 -0500
Re: Would ?EXIT work in all ANS-Forth systems? Cecil Bayona <cbayona@cbayona.com> - 2017-05-15 12:31 -0500
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-15 15:50 -0500
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-10 16:49 +0000
Re: Would ?EXIT work in all ANS-Forth systems? lehs <skydda.barnen@gmail.com> - 2017-05-10 12:04 -0700
Re: Would ?EXIT work in all ANS-Forth systems? humptydumpty <ouatubi@gmail.com> - 2017-05-11 01:08 -0700
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-11 09:13 +0100
Re: Would ?EXIT work in all ANS-Forth systems? humptydumpty <ouatubi@gmail.com> - 2017-05-11 01:48 -0700
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-11 09:59 +0100
Re: Would ?EXIT work in all ANS-Forth systems? "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-12 14:20 +0000
Re: Would ?EXIT work in all ANS-Forth systems? lehs <skydda.barnen@gmail.com> - 2017-05-12 17:01 -0700
Re: Would ?EXIT work in all ANS-Forth systems? humptydumpty <ouatubi@gmail.com> - 2017-05-12 22:18 -0700
Re: Would ?EXIT work in all ANS-Forth systems? lehs <skydda.barnen@gmail.com> - 2017-05-13 03:09 -0700
Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-05-13 21:07 +1000
Re: Would ?EXIT work in all ANS-Forth systems? "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-13 14:20 +0000
Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-05-14 11:59 +1000
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-14 09:21 -0500
Re: Would ?EXIT work in all ANS-Forth systems? humptydumpty <ouatubi@gmail.com> - 2017-05-14 10:43 -0700
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-14 18:35 -0500
Re: Would ?EXIT work in all ANS-Forth systems? Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-15 07:11 +0200
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-15 04:35 -0500
Re: Would ?EXIT work in all ANS-Forth systems? Julian Fondren <julian.fondren@gmail.com> - 2017-05-15 03:54 -0700
Re: Would ?EXIT work in all ANS-Forth systems? mhx@iae.nl - 2017-05-15 04:07 -0700
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-15 06:23 -0500
Re: Would ?EXIT work in all ANS-Forth systems? Julian Fondren <julian.fondren@gmail.com> - 2017-05-15 06:53 -0700
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-15 09:18 -0500
Re: Would ?EXIT work in all ANS-Forth systems? humptydumpty <ouatubi@gmail.com> - 2017-05-14 22:44 -0700
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-15 04:16 -0500
Re: Would ?EXIT work in all ANS-Forth systems? humptydumpty <ouatubi@gmail.com> - 2017-05-16 02:00 -0700
Re: Would ?EXIT work in all ANS-Forth systems? humptydumpty <ouatubi@gmail.com> - 2017-05-16 02:43 -0700
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-16 05:08 -0500
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-16 12:11 +0000
Re: Would ?EXIT work in all ANS-Forth systems? NN <november.nihal@gmail.com> - 2017-05-17 05:24 -0700
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-17 07:35 -0500
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-17 14:59 +0100
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-17 13:30 +0000
Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-05-15 11:09 +1000
Re: Would ?EXIT work in all ANS-Forth systems? Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-14 21:17 -0700
Re: Would ?EXIT work in all ANS-Forth systems? Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-15 07:13 +0200
Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-05-16 10:24 +1000
Re: Would ?EXIT work in all ANS-Forth systems? humptydumpty <ouatubi@gmail.com> - 2017-05-16 01:13 -0700
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-16 12:26 +0000
Re: Would ?EXIT work in all ANS-Forth systems? humptydumpty <ouatubi@gmail.com> - 2017-05-17 01:58 -0700
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-17 16:45 +0000
Re: Would ?EXIT work in all ANS-Forth systems? obi65537@gmail.com - 2017-05-25 12:04 -0700
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-26 10:02 +0000
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-26 07:46 -0500
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-26 13:53 +0000
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-26 10:14 -0500
Re: Would ?EXIT work in all ANS-Forth systems? Cecil Bayona <cbayona@cbayona.com> - 2017-05-26 10:16 -0500
Re: Would ?EXIT work in all ANS-Forth systems? Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-26 08:59 -0700
Re: Would ?EXIT work in all ANS-Forth systems? Cecil Bayona <cbayona@cbayona.com> - 2017-05-26 11:27 -0500
Re: Would ?EXIT work in all ANS-Forth systems? Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-26 10:19 -0700
Re: Would ?EXIT work in all ANS-Forth systems? Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-26 20:20 +0200
Re: Would ?EXIT work in all ANS-Forth systems? Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-26 21:38 -0700
Re: Would ?EXIT work in all ANS-Forth systems? Cecil Bayona <cbayona@cbayona.com> - 2017-05-26 14:06 -0500
Re: Would ?EXIT work in all ANS-Forth systems? Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-26 22:00 -0700
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-26 17:06 +0000
Re: Would ?EXIT work in all ANS-Forth systems? hum9 <obi65537@gmail.com> - 2017-05-27 01:15 -0700
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-28 14:17 +0000
Re: Would ?EXIT work in all ANS-Forth systems? obi65537@gmail.com - 2017-05-29 20:30 -0700
Re: Would ?EXIT work in all ANS-Forth systems? hum9 <obi65537@gmail.com> - 2017-05-29 21:08 -0700
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-30 04:12 -0500
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-30 12:44 +0100
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-30 08:09 -0500
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-30 14:35 +0000
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-30 16:27 +0100
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-31 12:16 -0500
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-01 05:34 +0000
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-01 02:14 -0500
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-01 08:40 +0000
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-01 06:14 -0500
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-06-01 13:16 +0100
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-01 07:43 -0500
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-06-01 14:15 +0100
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-06-02 11:49 +0100
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-01 16:42 +0000
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-02 03:19 -0500
Re: Would ?EXIT work in all ANS-Forth systems? hughaguilar96@gmail.com - 2017-06-01 14:07 -0700
Re: Would ?EXIT work in all ANS-Forth systems? Matthias Trute <matthias.trute@gmail.com> - 2017-06-02 12:26 -0700
Re: Would ?EXIT work in all ANS-Forth systems? minforth@arcor.de - 2017-06-02 13:16 -0700
Re: Would ?EXIT work in all ANS-Forth systems? Matthias Trute <matthias.trute@gmail.com> - 2017-06-03 01:34 -0700
Re: Would ?EXIT work in all ANS-Forth systems? minforth@arcor.de - 2017-06-03 02:54 -0700
Re: Would ?EXIT work in all ANS-Forth systems? hughaguilar96@gmail.com - 2017-06-01 13:53 -0700
Re: Would ?EXIT work in all ANS-Forth systems? hughaguilar96@gmail.com - 2017-06-01 13:48 -0700
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-06-01 22:31 +0100
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-02 08:03 -0500
Re: Would ?EXIT work in all ANS-Forth systems? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-06-02 15:16 +0200
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-06-02 14:30 +0100
Re: Would ?EXIT work in all ANS-Forth systems? hughaguilar96@gmail.com - 2017-06-02 07:32 -0700
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-06-02 18:23 +0100
Re: Would ?EXIT work in all ANS-Forth systems? Julian Fondren <julian.fondren@gmail.com> - 2017-06-01 14:49 -0700
Re: Would ?EXIT work in all ANS-Forth systems? minforth@arcor.de - 2017-06-01 16:05 -0700
Re: Would ?EXIT work in all ANS-Forth systems? hughaguilar96@gmail.com - 2017-06-01 17:48 -0700
Re: Would ?EXIT work in all ANS-Forth systems? Julian Fondren <julian.fondren@gmail.com> - 2017-06-01 18:44 -0700
Re: Would ?EXIT work in all ANS-Forth systems? hughaguilar96@gmail.com - 2017-06-01 19:14 -0700
Re: Would ?EXIT work in all ANS-Forth systems? Julian Fondren <julian.fondren@gmail.com> - 2017-06-01 19:54 -0700
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-27 17:40 +0000
WRAP...END-WRAP (was: Would ?EXIT work ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-30 15:28 +0000
Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-05-24 15:46 +1000
Re: Would ?EXIT work in all ANS-Forth systems? humptydumpty <obi65537@gmail.com> - 2017-05-25 11:51 -0700
Re: Would ?EXIT work in all ANS-Forth systems? humptydumpty <obi65537@gmail.com> - 2017-05-25 20:38 -0700
Re: Would ?EXIT work in all ANS-Forth systems? obi65537@gmail.com - 2017-05-25 22:03 -0700
Re: Would ?EXIT work in all ANS-Forth systems? obi65537@gmail.com - 2017-05-25 22:09 -0700
Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-05-26 21:56 +1000
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-26 13:30 +0100
Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-05-27 15:04 +1000
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-27 17:33 +0100
Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-05-29 12:17 +1000
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-29 08:42 +0100
Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-05-30 11:14 +1000
Re: Would ?EXIT work in all ANS-Forth systems? obi65537@gmail.com - 2017-05-29 20:32 -0700
Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-05-30 14:40 +1000
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-30 12:55 +0100
Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-05-31 12:17 +1000
Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-06-01 12:01 +1000
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-01 02:17 -0500
Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-06-01 22:09 +1000
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-01 07:51 -0500
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-06-01 14:20 +0100
Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-06-02 13:09 +1000
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-06-02 08:44 +0100
Re: Would ?EXIT work in all ANS-Forth systems? obi65537@gmail.com - 2017-06-02 11:05 -0700
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-06-02 19:34 +0100
Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-06-03 14:29 +1000
Re: Would ?EXIT work in all ANS-Forth systems? Julian Fondren <julian.fondren@gmail.com> - 2017-06-02 21:54 -0700
Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-06-04 22:52 +1000
Re: Would ?EXIT work in all ANS-Forth systems? Julian Fondren <julian.fondren@gmail.com> - 2017-06-02 22:24 -0700
Re: Would ?EXIT work in all ANS-Forth systems? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-06-03 07:34 +0100
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-03 08:39 +0000
Re: Would ?EXIT work in all ANS-Forth systems? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-06-03 13:47 +0100
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-03 14:36 +0000
Re: Would ?EXIT work in all ANS-Forth systems? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-06-04 17:29 +0100
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-06-04 10:28 +0100
Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-06-05 15:09 +1000
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-06-05 09:36 +0100
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-05 09:35 +0000
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-06-05 10:57 +0100
Re: Would ?EXIT work in all ANS-Forth systems? JennyB <jennybrien@googlemail.com> - 2017-06-05 13:07 -0700
Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-06-07 12:42 +1000
Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-06-05 20:07 +1000
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-06-04 10:45 +0100
Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-06-05 19:21 +1000
Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-06-03 14:19 +1000
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-02 03:32 -0500
Re: Would ?EXIT work in all ANS-Forth systems? hughaguilar96@gmail.com - 2017-06-02 06:50 -0700
Re: Would ?EXIT work in all ANS-Forth systems? hum9 <obi65537@gmail.com> - 2017-05-27 00:33 -0700
Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-05-27 14:53 +1000
READ-FILE over-specified? "HAA" <someone@microsoft.com> - 2017-05-27 21:28 +1000
Re: READ-FILE over-specified? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-27 13:11 +0000
Re: READ-FILE over-specified? "HAA" <someone@microsoft.com> - 2017-05-29 13:47 +1000
Re: READ-FILE over-specified? hughaguilar96@gmail.com - 2017-05-28 21:58 -0700
Re: READ-FILE over-specified? "HAA" <someone@microsoft.com> - 2017-05-30 11:06 +1000
Re: READ-FILE over-specified? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-28 09:44 +0200
Re: READ-FILE over-specified? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-28 13:41 +0000
Re: READ-FILE over-specified? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-28 19:59 +0200
Re: READ-FILE over-specified? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-29 05:20 +0000
Re: READ-FILE over-specified? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-29 10:29 +0200
Re: READ-FILE over-specified? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-29 09:34 +0000
Re: Would ?EXIT work in all ANS-Forth systems? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-05-16 09:42 +0100
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-16 09:53 +0100
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-16 04:53 -0500
Re: Would ?EXIT work in all ANS-Forth systems? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-16 12:32 +0200
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-16 12:35 +0100
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-16 10:48 -0500
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-16 18:23 +0100
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-17 04:33 -0500
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-17 12:29 +0100
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-16 10:28 +0000
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-16 10:43 -0500
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-16 16:34 +0000
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-16 12:41 -0500
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-17 16:14 +0000
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-18 03:05 -0500
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-18 16:33 +0000
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-18 12:43 -0500
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-18 04:01 -0500
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-18 15:41 +0000
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-18 11:58 -0500
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-18 22:57 +0100
Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-05-17 00:32 +1000
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-16 15:53 +0100
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-15 05:29 +0000
Re: Would ?EXIT work in all ANS-Forth systems? humptydumpty <ouatubi@gmail.com> - 2017-05-14 23:00 -0700
Re: Would ?EXIT work in all ANS-Forth systems? rickman <gnuarm@gmail.com> - 2017-05-17 12:27 -0400
Re: Would ?EXIT work in all ANS-Forth systems? "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-15 09:16 +0000
Re: Would ?EXIT work in all ANS-Forth systems? "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-15 09:55 +0000
Re: Would ?EXIT work in all ANS-Forth systems? "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-13 14:25 +0000
Re: Would ?EXIT work in all ANS-Forth systems? Julian Fondren <julian.fondren@gmail.com> - 2017-05-13 07:49 -0700
Re: Would ?EXIT work in all ANS-Forth systems? "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-15 09:59 +0000
Re: Would ?EXIT work in all ANS-Forth systems? "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-15 12:22 +0000
Re: Would ?EXIT work in all ANS-Forth systems? "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-13 14:19 +0000
Re: Would ?EXIT work in all ANS-Forth systems? lehs <skydda.barnen@gmail.com> - 2017-05-14 23:23 -0700
Re: Would ?EXIT work in all ANS-Forth systems? Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-15 00:10 -0700
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-15 09:35 +0000
Re: Would ?EXIT work in all ANS-Forth systems? lehs <skydda.barnen@gmail.com> - 2017-05-15 00:54 -0700
Return-address manipulation (was: Would ?EXIT ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-15 08:47 +0000
Re: Return-address manipulation (was: Would ?EXIT ...) stephen@mpeforth.com (Stephen Pelc) - 2017-05-15 11:53 +0000
Re: Return-address manipulation (was: Would ?EXIT ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-16 13:03 +0000
Re: Return-address manipulation (was: Would ?EXIT ...) Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-16 07:06 -0700
Re: Return-address manipulation (was: Would ?EXIT ...) Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-16 07:14 -0700
Re: Would ?EXIT work in all ANS-Forth systems? "Elizabeth D. Rather" <erather@forth.com> - 2017-05-14 21:58 -1000
Re: Would ?EXIT work in all ANS-Forth systems? stephen@mpeforth.com (Stephen Pelc) - 2017-05-15 11:23 +0000
Page 9 of 11 — ← Prev page 1 … 7 8 [9] 10 11 Next page →
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2017-05-27 21:28 +1000 |
| Subject | READ-FILE over-specified? |
| Message-ID | <ogbns8$1dm$1@gioia.aioe.org> |
| In reply to | #59890 |
HAA wrote:
> ...
> I discover u2 is supposed to be meaningful when ior <> 0, so
>
> : rdini ( a u fid -- a u | 0 ior )
> 1 setfh ?dup if ( err) 0 swap 2nip >ior unnest then ;
Perhaps I was too hasty in implementing that "fix".
The ANS stipulation in question is here:
11.6.1.2080 READ-FILE
...
If an exception occurs, ior is the implementation-defined I/O result code, and
u2 is the number of characters transferred to c-addr without an exception.
In practice an implementer will have no control over this since it is the OS
that determines what is returned when an exception occurs. The 'common
practice' for OS appears to be to return a flag or code in case of error. As to
the validity of the accompanying count (assuming it is returned at all) they
are typically silent.
Given this, I can only wonder what prompted ANS to include a 'feature' few
systems could accommodate in practice. The majority of implementers
will simply return u2=0 when ior <>0 because it's the best they can do.
I'll finish with these two questions for discussion:
1. What did ANS imagine 'standard programs' would do with u2 in case of error?
2. What other languages stipulate a valid count be returned when their 'read'
function encounters an error?
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-05-27 13:11 +0000 |
| Subject | Re: READ-FILE over-specified? |
| Message-ID | <2017May27.151106@mips.complang.tuwien.ac.at> |
| In reply to | #59914 |
"HAA" <someone@microsoft.com> writes:
>The ANS stipulation in question is here:
>
> 11.6.1.2080 READ-FILE
> ...
> If an exception occurs, ior is the implementation-defined I/O result code, and
> u2 is the number of characters transferred to c-addr without an exception.
>
>In practice an implementer will have no control over this since it is the OS
>that determines what is returned when an exception occurs. The 'common
>practice' for OS appears to be to return a flag or code in case of error. As to
>the validity of the accompanying count (assuming it is returned at all) they
>are typically silent.
POSIX says
<http://pubs.opengroup.org/onlinepubs/009695399/functions/read.html>:
|If a read() is interrupted by a signal after it has successfully read
|some data, it shall return the number of bytes read.
However, in that case read() does not indicate an error (because it
indicates an error by returning -1).
And for the ANSI C fread()
<http://pubs.opengroup.org/onlinepubs/009695399/functions/fread.html>:
|Upon successful completion, fread() shall return the number of
|elements successfully read which is less than nitems only if a read
|error or end-of-file is encountered. If size or nitems is 0, fread()
|shall return 0 and the contents of the array and the state of the
|stream remain unchanged. Otherwise, if a read error occurs, the error
|indicator for the stream shall be set, [CX] [Option Start] and errno
|shall be set to indicate the error. [Option End]
>Given this, I can only wonder what prompted ANS to include a 'feature' few
>systems could accommodate in practice. The majority of implementers
>will simply return u2=0 when ior <>0 because it's the best they can do.
>I'll finish with these two questions for discussion:
>
>1. What did ANS imagine 'standard programs' would do with u2 in case of error?
Process it? That is, unless they just THROW the ior as most programs
do. Given that widespread practice, it would probably be better to
report the error only on the next invocation of READ-FILE. A
straightforward implementation based on ANSI C fread() or POSIX read()
will behave that way anyway.
If you think it's a problem, will you make a proposal for fixing it?
- 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 2017: http://www.euroforth.org/ef17/
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2017-05-29 13:47 +1000 |
| Subject | Re: READ-FILE over-specified? |
| Message-ID | <ogg5jp$juv$1@gioia.aioe.org> |
| In reply to | #59919 |
Anton Ertl wrote:
> ...
> If you think it's a problem, will you make a proposal for fixing it?
>
> - anton
It's not a problem in the sense every implementation could comply with ANS
by ensuring read-file <>0 returns u2=0. If common practice however is to
just implement whatever the OS provides (Win32F and SwiftForth to name
just two) then perhaps that's what the standard ought to reflect e.g.
If an exception occurs, ior is the implementation-defined I/O result code,
and u2 is undefined.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-05-28 21:58 -0700 |
| Subject | Re: READ-FILE over-specified? |
| Message-ID | <0147628a-d84d-4044-8fa7-0f656d9095cc@googlegroups.com> |
| In reply to | #60000 |
On Sunday, May 28, 2017 at 8:47:07 PM UTC-7, HAA wrote: > Anton Ertl wrote: > > ... > > If you think it's a problem, will you make a proposal for fixing it? > > > > - anton > > It's not a problem in the sense every implementation could comply with ANS > by ensuring read-file <>0 returns u2=0. If common practice however is to > just implement whatever the OS provides (Win32F and SwiftForth to name > just two) then perhaps that's what the standard ought to reflect e.g. > > If an exception occurs, ior is the implementation-defined I/O result code, > and u2 is undefined. Most of HAA's posts are intelligent and insightful --- this wasn't one of them. The purpose of a standard is allow programs to be portable. If you standardize ambiguity, then you have accomplished nothing --- this is just a hand-waving exercise --- make the standard-document writer appear intelligent when he is actually a fool. I haven't been paying much attention to this thread. Didn't this thread start out by discussing return-address manipulation, such as I do in my rquotations? Why are we discussing READ-FILE now? There is certainly a lot of thread-drift on comp.lang.forth! I just want my rquotations to be standard --- the Forth-200x committee will never allow this --- so forget about Forth-200x!
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2017-05-30 11:06 +1000 |
| Subject | Re: READ-FILE over-specified? |
| Message-ID | <ogih17$dof$1@gioia.aioe.org> |
| In reply to | #60003 |
hughaguilar96@gmail.com wrote: > On Sunday, May 28, 2017 at 8:47:07 PM UTC-7, HAA wrote: > > Anton Ertl wrote: > > > ... > > > If you think it's a problem, will you make a proposal for fixing it? > > > > > > - anton > > > > It's not a problem in the sense every implementation could comply with ANS > > by ensuring read-file <>0 returns u2=0. If common practice however is to > > just implement whatever the OS provides (Win32F and SwiftForth to name > > just two) then perhaps that's what the standard ought to reflect e.g. > > > > If an exception occurs, ior is the implementation-defined I/O result code, > > and u2 is undefined. > > Most of HAA's posts are intelligent and insightful --- this wasn't one of them. > > The purpose of a standard is allow programs to be portable. If you standardize > ambiguity, then you have accomplished nothing --- this is just a hand-waving exercise > --- make the standard-document writer appear intelligent when he is actually a fool. > ... If read-file fails i.e. it returns an exception, then u2 is irrelevant. How is that ambiguous? It's the same approach that was used in open/create-file where fid was undefined in the event of an exception.
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-05-28 09:44 +0200 |
| Subject | Re: READ-FILE over-specified? |
| Message-ID | <ogdv4h$lff$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #59914 |
In article <ogbns8$1dm$1@gioia.aioe.org>, HAA <someone@microsoft.com> wrote: >HAA wrote: >> ... >> I discover u2 is supposed to be meaningful when ior <> 0, so >> >> : rdini ( a u fid -- a u | 0 ior ) >> 1 setfh ?dup if ( err) 0 swap 2nip >ior unnest then ; > >Perhaps I was too hasty in implementing that "fix". > >The ANS stipulation in question is here: > > 11.6.1.2080 READ-FILE > ... > If an exception occurs, ior is the implementation-defined I/O result code, and > u2 is the number of characters transferred to c-addr without an exception. > >In practice an implementer will have no control over this since it is the OS >that determines what is returned when an exception occurs. The 'common >practice' for OS appears to be to return a flag or code in case of error. As to >the validity of the accompanying count (assuming it is returned at all) they >are typically silent. > >Given this, I can only wonder what prompted ANS to include a 'feature' few >systems could accommodate in practice. The majority of implementers >will simply return u2=0 when ior <>0 because it's the best they can do. >I'll finish with these two questions for discussion: > >1. What did ANS imagine 'standard programs' would do with u2 in case of error? >2. What other languages stipulate a valid count be returned when their 'read' > function encounters an error? It is not the task of read to specify what meaning can still be attached to the number of bytes. You got an exception. The exception must specify what happened. E.g. in case of a memory fault you should run for your money. In case of an interrupted system call, the number of bytes read are valid. Groetjes Albert > > > -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-05-28 13:41 +0000 |
| Subject | Re: READ-FILE over-specified? |
| Message-ID | <2017May28.154130@mips.complang.tuwien.ac.at> |
| In reply to | #59963 |
albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>In case of an interrupted system call, the number of bytes read
>are valid.
That's the Unix solution to the PC-lusering problem. It's the main
example of the famous "worse-is-better" part in an essay by Richard
Gabriel. Basically, Unix (i.e., Ken Thompson) took the easy way out
and just returned enough info to allow continuing the system call,
shifting the problem to user mode.
That is not necessarily a problem, but what happened then is a
problem: This behaviour of the system call was exported to many other
places.
Ideally, for a blocking read(), you would have a system-call wrapper
that performs the user-level part of this design, i.e., puts a loop
around the system call, and then every user of the wrapper will see a
decent interface; and given that Unix works with system call wrappers
anyway (because the system call interface does not follow the C
calling convention), that would have been the logical place to deal
with the issue.
Unfortunately, Unix also supports non-blocking reads, and uses the
same system call, and, alas, the same wrapper for it. So you don't
want to loop in the wrapper. A better design would have been to have
two wrappers: one for the blocking read, and one for the non-blocking
read.
But it does not stop there: Standard C does not support non-blocking
I/O in the fopen()/fread()/etc. family of functions, yet the glibc
implementation of fread() also exports this behaviour of the Unix
read() system call; it does not make any sense there.
Finally, Gforth up to 0.7 (but not the current development version)
exports this behaviour: When I do
pad 50 stdin read-file
type "ab" and then change the window size, the READ-FILE returns (with
2 -37 as result, so there actually are Forth systems that return an
error for non-zero length) instead of continuing to wait for more
input. We fixed this in the current development version, and now
READ-FILE behaves as is appropriate for a blocking interface.
I would recommend the same to any Forth implementor.
- 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 2017: http://www.euroforth.org/ef17/
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-05-28 19:59 +0200 |
| Subject | Re: READ-FILE over-specified? |
| Message-ID | <ogf364$q13$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #59970 |
In article <2017May28.154130@mips.complang.tuwien.ac.at>, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes: >>In case of an interrupted system call, the number of bytes read >>are valid. > >That's the Unix solution to the PC-lusering problem. It's the main >example of the famous "worse-is-better" part in an essay by Richard >Gabriel. Basically, Unix (i.e., Ken Thompson) took the easy way out >and just returned enough info to allow continuing the system call, >shifting the problem to user mode. > >That is not necessarily a problem, but what happened then is a >problem: This behaviour of the system call was exported to many other >places. > >Ideally, for a blocking read(), you would have a system-call wrapper >that performs the user-level part of this design, i.e., puts a loop >around the system call, and then every user of the wrapper will see a >decent interface; and given that Unix works with system call wrappers >anyway (because the system call interface does not follow the C >calling convention), that would have been the logical place to deal >with the issue. > >Unfortunately, Unix also supports non-blocking reads, and uses the >same system call, and, alas, the same wrapper for it. So you don't >want to loop in the wrapper. A better design would have been to have >two wrappers: one for the blocking read, and one for the non-blocking >read. > >But it does not stop there: Standard C does not support non-blocking >I/O in the fopen()/fread()/etc. family of functions, yet the glibc >implementation of fread() also exports this behaviour of the Unix >read() system call; it does not make any sense there. Good to know, but it doesn't change the bottomline. If you get an exception you got to inspect the system information about what the exception means. > >Finally, Gforth up to 0.7 (but not the current development version) >exports this behaviour: When I do > >pad 50 stdin read-file > >type "ab" and then change the window size, the READ-FILE returns (with >2 -37 as result, so there actually are Forth systems that return an >error for non-zero length) instead of continuing to wait for more >input. We fixed this in the current development version, and now >READ-FILE behaves as is appropriate for a blocking interface. Is that on Windows? gforth 0.7.0 on Debian Wheezy doesn't behave that way. > >I would recommend the same to any Forth implementor. Inspected this potential problem for ciforth (lina/Linux and wina/wine). Nothing much interesting happened. > >- anton Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-05-29 05:20 +0000 |
| Subject | Re: READ-FILE over-specified? |
| Message-ID | <2017May29.072049@mips.complang.tuwien.ac.at> |
| In reply to | #59981 |
albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>In article <2017May28.154130@mips.complang.tuwien.ac.at>,
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
[...]
>Good to know, but it doesn't change the bottomline. If you
>get an exception you got to inspect the system information about
>what the exception means.
Not in READ-FILE. The signal handler deals with what the signal
means. If it returns after doing its thing, execution should just
continue just as in any other word (and when you are not in a system
call, there is no indication that a signal happened). That Unix
design chose to leave restarting the system call to user mode is just
an implementation choice.
>>Finally, Gforth up to 0.7 (but not the current development version)
>>exports this behaviour: When I do
>>
>>pad 50 stdin read-file
>>
>>type "ab" and then change the window size, the READ-FILE returns (with
>>2 -37 as result, so there actually are Forth systems that return an
>>error for non-zero length) instead of continuing to wait for more
>>input. We fixed this in the current development version, and now
>>READ-FILE behaves as is appropriate for a blocking interface.
>
>Is that on Windows? gforth 0.7.0 on Debian Wheezy doesn't behave that
>way.
That's on Debian 8, but also on Debian 5, so I am sure it also occurs
on Debian 7 (Wheezy). Maybe you are using a terminal emulator that
does not produce SIGWINCH when you change the window size. Try:
form . .
pad 50 stdin read-file \ now change the window size
form . .
If the FORM size does not change, then SIGWINCH is not delivered
>>I would recommend the same to any Forth implementor.
>
>Inspected this potential problem for ciforth (lina/Linux and wina/wine).
>Nothing much interesting happened.
If you do not catch signals with a signal handler that returns (as
Gforth does for SIGWINCH), you won't notice anything.
- 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 2017: http://www.euroforth.org/ef17/
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-05-29 10:29 +0200 |
| Subject | Re: READ-FILE over-specified? |
| Message-ID | <oggm5i$tq$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #60005 |
In article <2017May29.072049@mips.complang.tuwien.ac.at>, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes: >>In article <2017May28.154130@mips.complang.tuwien.ac.at>, >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >[...] >>Good to know, but it doesn't change the bottomline. If you >>get an exception you got to inspect the system information about >>what the exception means. > >Not in READ-FILE. The signal handler deals with what the signal >means. If it returns after doing its thing, execution should just >continue just as in any other word (and when you are not in a system >call, there is no indication that a signal happened). That Unix >design chose to leave restarting the system call to user mode is just >an implementation choice. You're right. READ-FILE is not a system call but a Forth word. It must behave true to the standard description. > >>>Finally, Gforth up to 0.7 (but not the current development version) >>>exports this behaviour: When I do >>> >>>pad 50 stdin read-file >>> >>>type "ab" and then change the window size, the READ-FILE returns (with >>>2 -37 as result, so there actually are Forth systems that return an >>>error for non-zero length) instead of continuing to wait for more >>>input. We fixed this in the current development version, and now >>>READ-FILE behaves as is appropriate for a blocking interface. >> >>Is that on Windows? gforth 0.7.0 on Debian Wheezy doesn't behave that >>way. > >That's on Debian 8, but also on Debian 5, so I am sure it also occurs >on Debian 7 (Wheezy). Maybe you are using a terminal emulator that >does not produce SIGWINCH when you change the window size. Try: <SNIP> It worked as you said. I was confused because the characters are not reflected as I typed them in. > >>>I would recommend the same to any Forth implementor. >> >>Inspected this potential problem for ciforth (lina/Linux and wina/wine). >>Nothing much interesting happened. > >If you do not catch signals with a signal handler that returns (as >Gforth does for SIGWINCH), you won't notice anything. So a simple Forth sacrifices the possibility to do forms. > >- anton -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-05-29 09:34 +0000 |
| Subject | Re: READ-FILE over-specified? |
| Message-ID | <2017May29.113434@mips.complang.tuwien.ac.at> |
| In reply to | #60014 |
albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>So a simple Forth sacrifices the possibility to do forms.
Not in the meaning that most people give to "forms". What FORM does
is return the terminal window size (I don't know what the inventor or
FORM was thinking when he though up this name, we just adopted it from
some other Forth). If you write an editor, and maybe also for a form
entry program, that's a useful information to have.
When the window size changes, our signal handler ensures that the
result of FORM also changes. If you don't have a signal handler for
SIGWINCH, your FORM has to query the terminal for its size every time
FORM is called.
So what a Forth system without a SIGWINCH handler sacrifices is FORM
speed. Probably not a big loss for most applications.
- 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 2017: http://www.euroforth.org/ef17/
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2017-05-16 09:42 +0100 |
| Message-ID | <ofedqi$a3s$1@dont-email.me> |
| In reply to | #59339 |
On 16/05/2017 01:24, HAA wrote: > Lars Brinkhoff wrote: >> HAA wrote: >>> It expresses a functionality which at the time was implemented through >>> R> DROP. For all I know ANS TC simply forgot to consider this use in its >>> R> deliberations. >> >> Isn't it the case that the 1994 ANS explicitly spells out that return >> addresses may not be accessible at all by R>? > > Exactly. So they didn't forget about it, they chose to make it non-standard. -- Gerry
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-16 09:53 +0100 |
| Message-ID | <ofeegl$c7g$1@dont-email.me> |
| In reply to | #59353 |
On 5/16/2017 09:42, Gerry Jackson wrote: > On 16/05/2017 01:24, HAA wrote: >> Lars Brinkhoff wrote: >>> HAA wrote: >>>> It expresses a functionality which at the time was implemented through >>>> R> DROP. For all I know ANS TC simply forgot to consider this use >>>> in its >>>> R> deliberations. >>> >>> Isn't it the case that the 1994 ANS explicitly spells out that return >>> addresses may not be accessible at all by R>? >> >> Exactly. > > So they didn't forget about it, they chose to make it non-standard. > And gave us CATCH and THROW, a much better & portable solution that allows you to mark a place and return to it without any return stack dependencies. Why more don't use it is a little mystifying. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-05-16 04:53 -0500 |
| Message-ID | <d5GdnW8mjMeYUYfEnZ2dnUU7-c3NnZ2d@supernews.com> |
| In reply to | #59355 |
Alex <alex@rivadpm.com> wrote: > On 5/16/2017 09:42, Gerry Jackson wrote: >> >> So they didn't forget about [return stack trickery], they chose to >> make it non-standard. > > And gave us CATCH and THROW, a much better & portable solution that > allows you to mark a place and return to it without any return stack > dependencies. Why more don't use it is a little mystifying. Forth's CATCH/THROW is the lightest-weight exception-handling mechanism that I've seen, but it's still heavier than EXIT, which is (almost) the lightest-weight subroutine return mechanism I've ever seen. Having siad that, it's difficult for an analytical Forth compiler to optimize CATCH and THROW: I don't know if any of them attempt it. Also, there is a philosophical objection to using THROW in anything other than exceptional circumstances. In many languages this leads to throwing an exception being very slow. (That's a property of the implementation, but it's also the product of an attitude.) And exceptions can be very hard to debug. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-05-16 12:32 +0200 |
| Message-ID | <ofekfh$emr$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #59360 |
In article <d5GdnW8mjMeYUYfEnZ2dnUU7-c3NnZ2d@supernews.com>, Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: <SNIP> > >Also, there is a philosophical objection to using THROW in anything >other than exceptional circumstances. In many languages this leads to >throwing an exception being very slow. (That's a property of the >implementation, but it's also the product of an attitude.) And >exceptions can be very hard to debug. Probably it is the other way around. In many languages an exception is made too complicated and slow. Then a rationalisation is given in order to make that less apparent. The usual way to abuse political correctness. I don't mind a database search that ends in FOUND exception. Abandon it all ! I've found it ! > >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 | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-16 12:35 +0100 |
| Message-ID | <ofeo0k$c56$1@dont-email.me> |
| In reply to | #59360 |
On 5/16/2017 10:53, Andrew Haley wrote:
> Alex <alex@rivadpm.com> wrote:
>> On 5/16/2017 09:42, Gerry Jackson wrote:
>>>
>>> So they didn't forget about [return stack trickery], they chose to
>>> make it non-standard.
>>
>> And gave us CATCH and THROW, a much better & portable solution that
>> allows you to mark a place and return to it without any return stack
>> dependencies. Why more don't use it is a little mystifying.
>
> Forth's CATCH/THROW is the lightest-weight exception-handling
> mechanism that I've seen, but it's still heavier than EXIT, which is
The lightest weight AFAIK uses quite a different formulation to
CATCH/THROW.
Saving the stack pointers with CATCH has an overhead, and it's a good
bit slower than a straightforward EXECUTE. If you are continually
CATCHing and not THROWing, then the overhead might get to be significant.
The alternative is to map out error handlers by address range and have a
TRY section. There's no CATCH overhead, as the code covered by the TRY
range is mapped at compile time. Just EXECUTE inside your CATCH range
and be damned; and if you are damned and THROW, then have the THROW code
take the hit searching through the call stack into the pre-built address
range table to find the appropriate TRY handler. (That search presumes
some sort of order to the stack; either all return addresses or stack
frames, which is very un-Forthish. Good for C though. Windows 64 bit
uses a variation of this technique.)
But as a dynamic mechanism. CATCH/THROW takes some beating. Here's an
STC x86 based MARK and UNWIND, which is even lighter weight than CATCH
and THROW. (EAX is top of stack, the data stack is EBP.) Setup & exit on
CATCH is 3 extra instructions (PUSH MOV POP ) (even EXECUTE has to drop
the XT) and a THROW is 2 (MOV POP).
variable handler
code mark ( xt -- )
mov ecx eax ( save xt )
mov eax { ebp } ( drop xt )
add ebp cell
push { handler } \ handler @ >r
mov { handler } esp \ rp @ handler !
call ecx \ execute
pop { handler } \ r> handler !
ret
end-code
code unwind ( -- )
mov esp { handler } \ handler @ rp!
pop { handler } \ r> handler !
ret
end-code
> (almost) the lightest-weight subroutine return mechanism I've ever > seen. Having siad that, it's difficult for an analytical Forth
> compiler to optimize CATCH and THROW: I don't know if any of them
> attempt it.
For a handful of instructions, the considerable compile-time effort
isn't probably worth it. Just don't do it inside a loop.
--
Alex
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-05-16 10:48 -0500 |
| Message-ID | <W6mdnQa9aanTgobEnZ2dnUU7-UmdnZ2d@supernews.com> |
| In reply to | #59365 |
Alex <alex@rivadpm.com> wrote: > On 5/16/2017 10:53, Andrew Haley wrote: >> Alex <alex@rivadpm.com> wrote: >>> On 5/16/2017 09:42, Gerry Jackson wrote: >>>> >>>> So they didn't forget about [return stack trickery], they chose to >>>> make it non-standard. >>> >>> And gave us CATCH and THROW, a much better & portable solution that >>> allows you to mark a place and return to it without any return stack >>> dependencies. Why more don't use it is a little mystifying. >> >> Forth's CATCH/THROW is the lightest-weight exception-handling >> mechanism that I've seen, but it's still heavier than EXIT, which is > > The lightest weight AFAIK uses quite a different formulation to > CATCH/THROW. > > Saving the stack pointers with CATCH has an overhead, and it's a > good bit slower than a straightforward EXECUTE. If you are > continually CATCHing and not THROWing, then the overhead might get > to be significant. > > The alternative is to map out error handlers by address range and > have a TRY section. There's no CATCH overhead, as the code covered > by the TRY range is mapped at compile time. Just EXECUTE inside your > CATCH range and be damned; and if you are damned and THROW, then > have the THROW code take the hit searching through the call stack > into the pre-built address range table to find the appropriate TRY > handler. Yeah, exactly. That's the heavyweight approaqch generally used by GCC, Java, etc. It highly opitimizes the CATCH at the cost of a much more expensive THROW. > But as a dynamic mechanism. CATCH/THROW takes some beating. Here's an > STC x86 based MARK and UNWIND, which is even lighter weight than CATCH > and THROW. (EAX is top of stack, the data stack is EBP.) Setup & exit on > CATCH is 3 extra instructions (PUSH MOV POP ) (even EXECUTE has to drop > the XT) and a THROW is 2 (MOV POP). It's much the same, except that it doesn't return a code and restore SP, I guess? Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-16 18:23 +0100 |
| Message-ID | <offcc9$mfu$1@dont-email.me> |
| In reply to | #59378 |
On 5/16/2017 16:48, Andrew Haley wrote: > > It's much the same, except that it doesn't return a code and restore > SP, I guess? > Yes, the data stack pointer is simply returned asis. You have to be absolutely certain as to what stack depth you expect on an UNWINDing super-return, so it's of limited use for deep unwinds. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-05-17 04:33 -0500 |
| Message-ID | <AMGdncGpbuJphYHEnZ2dnUU7-cudnZ2d@supernews.com> |
| In reply to | #59385 |
Alex <alex@rivadpm.com> wrote: > On 5/16/2017 16:48, Andrew Haley wrote: > >> It's much the same, except that it doesn't return a code and restore >> SP, I guess? > > Yes, the data stack pointer is simply returned asis. You have to be > absolutely certain as to what stack depth you expect on an UNWINDing > super-return, so it's of limited use for deep unwinds. I'm not sure what to think, really. In a way I like it, but I'm not quite sure. It's certianly an interesting idea. AFAICS it does everything that fiddling with the return stack can usefully do, but in a structured way. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-17 12:29 +0100 |
| Message-ID | <ofhc0v$vcv$1@dont-email.me> |
| In reply to | #59421 |
On 5/17/2017 10:33, Andrew Haley wrote: > Alex <alex@rivadpm.com> wrote: >> On 5/16/2017 16:48, Andrew Haley wrote: >> >>> It's much the same, except that it doesn't return a code and restore >>> SP, I guess? >> >> Yes, the data stack pointer is simply returned asis. You have to be >> absolutely certain as to what stack depth you expect on an UNWINDing >> super-return, so it's of limited use for deep unwinds. > > I'm not sure what to think, really. In a way I like it, but I'm not > quite sure. It's certianly an interesting idea. AFAICS it does > everything that fiddling with the return stack can usefully do, but in > a structured way. > > Andrew. > It's much like INTERCAL's COMEFROM; it might* be useful in implementing continuations. But I suspect it will only encourage a style sometimes called "wherethefuckarewe" programming by those tasked with maintenance. The advantage of CATCH/THROW is that at least we know where we are in terms of both stacks rather than one. And we know how we got to the statement after the CATCH; either a THROW or the normal return mechanism. *probably won't -- Alex
[toc] | [prev] | [next] | [standalone]
Page 9 of 11 — ← Prev page 1 … 7 8 [9] 10 11 Next page →
Back to top | Article view | comp.lang.forth
csiph-web