Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #37787 > unrolled thread
| Started by | hughaguilar96@gmail.com |
|---|---|
| First post | 2015-03-31 15:13 -0700 |
| Last post | 2015-07-06 12:47 -0400 |
| Articles | 20 on this page of 509 — 42 participants |
Back to article view | Back to comp.lang.forth
bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-03-31 15:13 -0700
Re: bug in VFX --- IF does't work jfong@ms4.hinet.net - 2015-03-31 20:55 -0700
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-04-01 11:26 +0000
Re: bug in VFX --- IF does't work Jason Damisch <jasondamisch@yahoo.com> - 2015-04-01 08:39 -0700
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-04-01 17:35 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-06-12 15:18 -0700
Re: bug in VFX --- IF does't work Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> - 2015-04-02 10:35 +0100
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-02 10:08 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-01 12:33 -0700
Re: bug in VFX --- IF does't work "Rod Pemberton" <bork@lllljunkqwer.cpm> - 2015-04-01 22:16 -0400
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-01 13:40 -0700
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-04-02 17:07 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-02 19:18 -0700
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-04-03 06:43 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-03 10:49 -0700
Re: bug in VFX --- IF does't work beeflo <beeflobill@gmail.com> - 2015-04-03 11:17 -0700
Re: bug in VFX --- IF does't work rickman <gnuarm@gmail.com> - 2015-04-03 14:35 -0400
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-04-03 19:42 +0100
Re: bug in VFX --- IF does't work jkn_gg@nicorp.f9.co.uk - 2015-04-03 14:34 -0700
Re: bug in VFX --- IF does't work rickman <gnuarm@gmail.com> - 2015-04-03 20:52 -0400
Re: bug in VFX --- IF does't work jkn_gg@nicorp.f9.co.uk - 2015-04-04 03:47 -0700
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-04 14:07 -0700
Re: bug in VFX --- IF does't work rickman <gnuarm@gmail.com> - 2015-04-05 00:11 -0400
Re: bug in VFX --- IF does't work jkn_gg@nicorp.f9.co.uk - 2015-04-05 08:11 -0700
Re: bug in VFX --- IF does't work albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-03 23:50 +0000
Re: bug in VFX --- IF does't work Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2015-04-04 05:44 +0200
Re: bug in VFX --- IF does't work Paul Rubin <no.email@nospam.invalid> - 2015-04-03 21:32 -0700
Re: bug in VFX --- IF does't work Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2015-04-04 17:03 +0200
Re: bug in VFX --- IF does't work Paul Rubin <no.email@nospam.invalid> - 2015-04-04 21:56 -0700
Re: bug in VFX --- IF does't work Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2015-04-05 18:11 +0200
Re: bug in VFX --- IF does't work Paul Rubin <no.email@nospam.invalid> - 2015-04-05 10:13 -0700
Re: bug in VFX --- IF does't work Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2015-04-06 14:03 +0200
Re: bug in VFX --- IF does't work albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-06 14:44 +0000
Re: bug in VFX --- IF does't work Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2015-04-07 11:02 +0200
Re: bug in VFX --- IF does't work Paul Rubin <no.email@nospam.invalid> - 2015-04-07 17:21 -0700
Re: bug in VFX --- IF does't work "WJ" <w_a_x_man@yahoo.com> - 2015-04-07 16:02 +0000
Re: bug in VFX --- IF does't work Paul Rubin <no.email@nospam.invalid> - 2015-04-07 11:06 -0700
Re: bug in VFX --- IF does't work Elizabeth D Rather <erather@forth.com> - 2015-04-03 18:52 -1000
Re: bug in VFX --- IF does't work "WJ" <w_a_x_man@yahoo.com> - 2015-04-05 03:54 +0000
Re: bug in VFX --- IF does't work Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2015-04-05 18:21 +0200
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-05 21:47 -0700
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-06-12 14:41 -0700
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-06-12 23:20 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-06-12 18:40 -0700
Re: bug in VFX --- IF does't work "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-06-13 04:36 -0400
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-06-13 23:12 -0700
Re: bug in VFX --- IF does't work "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-06-14 09:53 -0400
Re: bug in VFX --- IF does't work Michael Barry <barrym95838@yahoo.com> - 2015-06-14 18:38 -0700
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-06-15 21:03 +0100
Re: bug in VFX --- IF does't work Michael Barry <barrym95838@yahoo.com> - 2015-06-15 19:38 -0700
Re: bug in VFX --- IF does't work rickman <gnuarm@gmail.com> - 2015-06-15 22:54 -0400
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-06-16 10:01 +0100
Re: bug in VFX --- IF does't work Michael Barry <barrym95838@yahoo.com> - 2015-06-16 18:25 -0700
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-06-17 10:11 +0100
Re: bug in VFX --- IF does't work rickman <gnuarm@gmail.com> - 2015-06-15 22:49 -0400
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-06-15 21:56 -0700
Re: bug in VFX --- IF does't work Mark Wills <markwills1970@gmail.com> - 2015-06-16 00:11 -0700
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-16 07:21 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-06-16 19:45 -0700
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-17 10:34 +0000
Re: bug in VFX --- IF does't work Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-17 08:49 -0700
Re: bug in VFX --- IF does't work mhx@iae.nl - 2015-06-17 13:50 -0700
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-06-17 18:36 -0700
Re: bug in VFX --- IF does't work Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-17 23:44 -0700
Re: bug in VFX --- IF does't work "Elizabeth D. Rather" <erather@forth.com> - 2015-06-17 21:14 -1000
Re: bug in VFX --- IF does't work Mark Wills <markwills1970@gmail.com> - 2015-06-18 00:15 -0700
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-06-18 09:27 +0100
Re: bug in VFX --- IF does't work Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-18 02:04 -0700
Re: bug in VFX --- IF does't work Mark Wills <markwills1970@gmail.com> - 2015-06-18 03:32 -0700
Re: bug in VFX --- IF does't work Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-18 04:19 -0700
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-06-18 12:31 +0000
Re: bug in VFX --- IF does't work Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-18 05:57 -0700
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-06-18 12:21 +0000
Re: bug in VFX --- IF does't work "Elizabeth D. Rather" <erather@forth.com> - 2015-06-18 08:01 -1000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-06-18 12:11 -0700
Re: bug in VFX --- IF does't work Walter Banks <walter@bytecraft.com> - 2015-06-18 17:25 -0400
Re: bug in VFX --- IF does't work Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-18 22:56 +0200
Re: bug in VFX --- IF does't work coos <chforth@hccnet.nl> - 2015-06-18 18:54 +0200
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-06-18 10:53 -0700
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-06-18 21:31 +0100
Re: bug in VFX --- IF does't work Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-18 23:58 -0700
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-06-19 08:23 +0100
Re: bug in VFX --- IF does't work Mark Wills <markwills1970@gmail.com> - 2015-06-19 01:01 -0700
Re: bug in VFX --- IF does't work Thomas Östreicher <thomas.oestreicher@gmail.com> - 2015-06-19 01:07 -0700
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-06-19 09:38 +0000
Re: bug in VFX --- IF does't work Mark Wills <markwills1970@gmail.com> - 2015-06-19 02:51 -0700
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-20 16:35 +0000
Re: bug in VFX --- IF does't work Mark Wills <markwills1970@gmail.com> - 2015-06-20 21:28 -0700
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-06-20 21:33 -0700
Re: bug in VFX --- IF does't work Mark Wills <markwills1970@gmail.com> - 2015-06-20 21:49 -0700
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-21 14:01 +0000
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-06-21 14:19 +0000
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-22 13:16 +0000
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-06-22 16:53 +0000
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-23 15:39 +0000
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-06-23 18:11 +0000
Re: bug in VFX --- IF does't work Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-23 22:16 +0200
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-06-23 23:26 +0000
Re: bug in VFX --- IF does't work Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-24 03:23 +0200
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-24 08:04 +0000
Re: bug in VFX --- IF does't work Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-24 14:46 +0200
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-06-24 13:03 +0000
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-06-24 15:05 +0100
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-06-24 14:32 +0000
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-24 14:20 +0000
Re: bug in VFX --- IF does't work Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-24 20:04 +0200
Re: bug in VFX --- IF does't work Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-24 16:08 +0200
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-06-26 08:07 +0100
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-06-26 08:55 +0000
Re: bug in VFX --- IF does't work Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-27 00:56 +0200
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-06-26 18:06 +0100
Re: bug in VFX --- IF does't work Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-27 01:00 +0200
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-06-27 11:07 +0100
Re: bug in VFX --- IF does't work Matthias Trute <matthias.trute@gmail.com> - 2015-06-27 12:04 -0700
Re: bug in VFX --- IF does't work Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-27 21:14 +0200
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-20 16:26 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-06-20 21:55 -0700
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-21 14:26 +0000
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-06-22 00:29 +0100
Re: bug in VFX --- IF does't work Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-22 03:24 +0200
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-22 07:49 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-06-21 21:16 -0700
Re: bug in VFX --- IF does't work Mark Wills <markwills1970@gmail.com> - 2015-06-22 02:09 -0700
Re: bug in VFX --- IF does't work "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-06-22 05:57 -0400
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-06-21 14:27 +0000
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-22 11:58 +0000
Re: bug in VFX --- IF does't work Mark Wills <markwills1970@gmail.com> - 2015-06-19 01:04 -0700
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-20 16:17 +0000
Re: bug in VFX --- IF does't work Mark Wills <markwills1970@gmail.com> - 2015-06-19 00:55 -0700
Re: bug in VFX --- IF does't work Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-19 02:42 -0700
Re: bug in VFX --- IF does't work rickman <gnuarm@gmail.com> - 2015-06-19 03:56 -0400
Re: bug in VFX --- IF does't work Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-19 02:47 -0700
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-06-19 11:37 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-06-19 19:56 -0700
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-06-21 21:23 +0100
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-22 08:39 +0000
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-06-22 11:27 +0100
Re: bug in VFX --- IF does't work "WJ" <w_a_x_man@yahoo.com> - 2015-06-22 16:07 +0000
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-21 14:56 +0000
Re: bug in VFX --- IF does't work Mark Wills <markwills1970@gmail.com> - 2015-06-19 00:40 -0700
Re: bug in VFX --- IF does't work Ron Aaron <rambamist@gmail.com> - 2015-06-19 10:55 +0300
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-21 14:43 +0000
Re: bug in VFX --- IF does't work Mark Wills <markwills1970@gmail.com> - 2015-06-22 02:05 -0700
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-22 16:41 +0000
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-19 12:55 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-06-18 10:00 -0700
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-06-18 20:56 +0100
Re: bug in VFX --- IF does't work Hannu Vuolasaho <vuokkosetae@gmail.com> - 2015-06-19 03:13 +0300
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-06-19 08:37 +0100
WAS: bug in VFX... IS: More rants from Rantman of Rantland rickman <gnuarm@gmail.com> - 2015-06-18 16:33 -0400
Re: WAS: bug in VFX... IS: More rants from Rantman of Rantland "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-06-19 05:19 -0400
Re: WAS: bug in VFX... IS: More rants from Rantman of Rantland Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-06-19 13:38 +0100
Re: WAS: bug in VFX... IS: More rants from Rantman of Rantland rickman <gnuarm@gmail.com> - 2015-06-19 12:29 -0400
Re: WAS: bug in VFX... IS: More rants from Rantman of Rantland "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-06-19 17:53 -0400
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-19 12:07 +0000
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-06-19 12:55 +0000
The meaning of xt in Forth-94 (was: bug in VFX --- IF does't work) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-20 15:36 +0000
Re: The meaning of xt in Forth-94 (was: bug in VFX --- IF does't work) "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-06-20 14:01 -0400
Re: The meaning of xt in Forth-94 "Elizabeth D. Rather" <erather@forth.com> - 2015-06-20 08:33 -1000
Re: The meaning of xt in Forth-94 hughaguilar96@gmail.com - 2015-06-20 21:18 -0700
Re: The meaning of xt in Forth-94 (was: bug in VFX --- IF does't work) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-21 13:09 +0000
Re: The meaning of xt in Forth-94 (was: bug in VFX --- IF does't work) stephen@mpeforth.com (Stephen Pelc) - 2015-06-21 14:50 +0000
Re: The meaning of xt in Forth-94 (was: bug in VFX --- IF does't work) Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-21 23:58 +0200
Re: The meaning of xt in Forth-94 (was: bug in VFX --- IF does't work) stephen@mpeforth.com (Stephen Pelc) - 2015-06-22 10:54 +0000
Re: The meaning of xt in Forth-94 (was: bug in VFX --- IF does't work) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-22 15:52 +0000
Re: The meaning of xt in Forth-94 (was: bug in VFX --- IF does't work) stephen@mpeforth.com (Stephen Pelc) - 2015-06-22 17:08 +0000
Re: The meaning of xt in Forth-94 (was: bug in VFX --- IF does't work) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-23 16:43 +0000
Re: The meaning of xt in Forth-94 (was: bug in VFX --- IF does't work) Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-22 20:19 +0200
Re: The meaning of xt in Forth-94 (was: bug in VFX --- IF does't work) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-22 08:47 +0000
Re: The meaning of xt in Forth-94 (was: bug in VFX --- IF does't work) stephen@mpeforth.com (Stephen Pelc) - 2015-06-22 13:58 +0000
Re: The meaning of xt in Forth-94 (was: bug in VFX --- IF does't work) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-22 15:37 +0000
Re: The meaning of xt in Forth-94 (was: bug in VFX --- IF does't work) stephen@mpeforth.com (Stephen Pelc) - 2015-06-22 17:02 +0000
Re: The meaning of xt in Forth-94 (was: bug in VFX --- IF does't work) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-23 16:29 +0000
Re: The meaning of xt in Forth-94 (was: bug in VFX --- IF does't work) stephen@mpeforth.com (Stephen Pelc) - 2015-06-23 18:18 +0000
Re: The meaning of xt in Forth-94 (was: bug in VFX --- IF does't work) Mark Wills <markwills1970@gmail.com> - 2015-06-23 00:42 -0700
Re: The meaning of xt in Forth-94 "Elizabeth D. Rather" <erather@forth.com> - 2015-06-22 21:47 -1000
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-23 02:42 -0700
Re: The meaning of xt in Forth-94 Mark Wills <markwills1970@gmail.com> - 2015-06-23 03:38 -0700
Re: The meaning of xt in Forth-94 stephen@mpeforth.com (Stephen Pelc) - 2015-06-23 12:55 +0000
Re: The meaning of xt in Forth-94 Mark Wills <markwills1970@gmail.com> - 2015-06-23 06:55 -0700
Re: The meaning of xt in Forth-94 peter.m.falth@gmail.com - 2015-06-23 08:29 -0700
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-23 16:47 +0000
Re: The meaning of xt in Forth-94 stephen@mpeforth.com (Stephen Pelc) - 2015-06-23 22:48 +0000
Re: The meaning of xt in Forth-94 hughaguilar96@gmail.com - 2015-06-24 18:13 -0700
Re: The meaning of xt in Forth-94 "Alex McDonald" <blog@rivadpm.com> - 2015-06-25 13:40 +0100
Re: The meaning of xt in Forth-94 Mark Wills <markwills1970@gmail.com> - 2015-06-25 06:29 -0700
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-25 08:13 -0700
Re: The meaning of xt in Forth-94 stephen@mpeforth.com (Stephen Pelc) - 2015-06-25 16:33 +0000
Re: The meaning of xt in Forth-94 hughaguilar96@gmail.com - 2015-06-25 13:45 -0700
Re: The meaning of xt in Forth-94 stephen@mpeforth.com (Stephen Pelc) - 2015-06-26 05:54 +0000
Re: The meaning of xt in Forth-94 hughaguilar96@gmail.com - 2015-06-27 21:08 -0700
Re: The meaning of xt in Forth-94 Mark Wills <markwills1970@gmail.com> - 2015-06-26 03:44 -0700
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-26 03:52 -0700
Re: The meaning of xt in Forth-94 franck.bensusan@gmail.com - 2015-06-26 08:54 -0700
Re: The meaning of xt in Forth-94 Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-27 01:09 +0200
Re: The meaning of xt in Forth-94 "Alex McDonald" <blog@rivadpm.com> - 2015-06-27 11:00 +0100
Re: The meaning of xt in Forth-94 Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-27 15:23 +0200
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-27 16:31 +0000
Re: The meaning of xt in Forth-94 Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-27 21:11 +0200
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-28 13:41 +0000
Re: The meaning of xt in Forth-94 Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-29 03:09 +0200
Re: The meaning of xt in Forth-94 mhx@iae.nl - 2015-06-27 06:42 -0700
Re: The meaning of xt in Forth-94 "Alex McDonald" <blog@rivadpm.com> - 2015-06-28 13:21 +0100
Re: The meaning of xt in Forth-94 "Alex McDonald" <blog@rivadpm.com> - 2015-06-26 12:20 +0100
Re: The meaning of xt in Forth-94 hughaguilar96@gmail.com - 2015-07-12 19:43 -0700
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-28 14:09 +0000
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-28 10:21 -0700
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-28 14:26 +0000
Re: The meaning of xt in Forth-94 Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-29 03:21 +0200
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-30 07:14 +0000
Re: The meaning of xt in Forth-94 Bernd Paysan <bernd.paysan@gmx.de> - 2015-07-01 00:33 +0200
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-04 13:58 +0000
Re: The meaning of xt in Forth-94 Bernd Paysan <bernd.paysan@gmx.de> - 2015-07-05 00:18 +0200
Re: The meaning of xt in Forth-94 "Alex McDonald" <blog@rivadpm.com> - 2015-07-05 07:33 +0100
Re: The meaning of xt in Forth-94 "Alex McDonald" <blog@rivadpm.com> - 2015-07-05 08:28 +0100
Re: The meaning of xt in Forth-94 stephen@mpeforth.com (Stephen Pelc) - 2015-07-05 12:22 +0000
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-06 16:03 +0000
Re: The meaning of xt in Forth-94 "Alex McDonald" <blog@rivadpm.com> - 2015-07-06 18:40 +0100
Re: The meaning of xt in Forth-94 stephen@mpeforth.com (Stephen Pelc) - 2015-07-06 20:36 +0000
Re: The meaning of xt in Forth-94 "Alex McDonald" <blog@rivadpm.com> - 2015-07-07 07:18 +0100
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-07 07:17 +0000
Re: The meaning of xt in Forth-94 Paul Rubin <no.email@nospam.invalid> - 2015-06-28 19:32 -0700
Re: The meaning of xt in Forth-94 "Elizabeth D. Rather" <erather@forth.com> - 2015-06-28 19:32 -1000
Re: The meaning of xt in Forth-94 Paul Rubin <no.email@nospam.invalid> - 2015-06-29 15:06 -0700
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-30 07:48 +0000
Re: The meaning of xt in Forth-94 franck.bensusan@gmail.com - 2015-06-30 03:38 -0700
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-30 04:44 -0700
Re: The meaning of xt in Forth-94 franck.bensusan@gmail.com - 2015-07-01 02:49 -0700
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-01 04:43 -0700
Re: The meaning of xt in Forth-94 rickman <gnuarm@gmail.com> - 2015-07-02 02:16 -0400
Re: The meaning of xt in Forth-94 Paul Rubin <no.email@nospam.invalid> - 2015-07-01 23:24 -0700
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-02 00:10 -0700
Re: The meaning of xt in Forth-94 Paul Rubin <no.email@nospam.invalid> - 2015-07-02 01:51 -0700
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-02 12:49 +0000
Re: The meaning of xt in Forth-94 "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-02 18:02 -0400
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-04 14:31 +0000
Re: The meaning of xt in Forth-94 Mark Wills <markwills1970@gmail.com> - 2015-06-30 01:55 -0700
Re: The meaning of xt in Forth-94 hughaguilar96@gmail.com - 2015-07-01 20:32 -0700
Re: The meaning of xt in Forth-94 Mark Wills <markwills1970@gmail.com> - 2015-07-02 02:40 -0700
Re: The meaning of xt in Forth-94 hughaguilar96@gmail.com - 2015-07-02 22:40 -0700
Re: The meaning of xt in Forth-94 "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-03 04:32 -0400
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-03 03:03 -0700
Re: The meaning of xt in Forth-94 Mark Wills <markwills1970@gmail.com> - 2015-07-03 03:16 -0700
Re: The meaning of xt in Forth-94 "Alex McDonald" <blog@rivadpm.com> - 2015-07-03 22:06 +0100
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-03 22:39 -0700
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-04 14:45 +0000
Re: The meaning of xt in Forth-94 hughaguilar96@gmail.com - 2015-07-04 11:39 -0700
Re: The meaning of xt in Forth-94 "Alex McDonald" <blog@rivadpm.com> - 2015-07-04 19:55 +0100
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-04 20:54 -0700
Re: The meaning of xt in Forth-94 "Alex McDonald" <blog@rivadpm.com> - 2015-07-05 07:18 +0100
Re: The meaning of xt in Forth-94 "Elizabeth D. Rather" <erather@forth.com> - 2015-07-04 21:47 -1000
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-05 01:49 -0700
Re: The meaning of xt in Forth-94 "Alex McDonald" <blog@rivadpm.com> - 2015-07-05 10:30 +0100
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-05 03:09 -0700
Re: The meaning of xt in Forth-94 "Alex McDonald" <blog@rivadpm.com> - 2015-07-05 16:29 +0100
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-05 09:49 -0700
Re: The meaning of xt in Forth-94 "Alex McDonald" <blog@rivadpm.com> - 2015-07-05 22:10 +0100
Re: The meaning of xt in Forth-94 Paul Rubin <no.email@nospam.invalid> - 2015-07-05 14:54 -0700
Re: The meaning of xt in Forth-94 "Elizabeth D. Rather" <erather@forth.com> - 2015-07-05 12:41 -1000
Re: The meaning of xt in Forth-94 Paul Rubin <no.email@nospam.invalid> - 2015-07-05 15:47 -0700
Re: The meaning of xt in Forth-94 Bernd Paysan <bernd.paysan@gmx.de> - 2015-07-06 00:57 +0200
Re: The meaning of xt in Forth-94 Paul Rubin <no.email@nospam.invalid> - 2015-07-05 16:08 -0700
Re: The meaning of xt in Forth-94 Bernd Paysan <bernd.paysan@gmx.de> - 2015-07-06 01:36 +0200
Re: The meaning of xt in Forth-94 Paul Rubin <no.email@nospam.invalid> - 2015-07-05 17:25 -0700
Re: The meaning of xt in Forth-94 "Elizabeth D. Rather" <erather@forth.com> - 2015-07-05 13:15 -1000
Re: The meaning of xt in Forth-94 Mark Wills <markwills1970@gmail.com> - 2015-07-06 02:05 -0700
Re: The meaning of xt in Forth-94 hughaguilar96@gmail.com - 2015-07-05 19:46 -0700
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-06 07:57 +0000
Re: The meaning of xt in Forth-94 Paul Rubin <no.email@nospam.invalid> - 2015-07-06 18:53 -0700
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-07 07:37 +0000
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-08 05:18 +0000
Re: The meaning of xt in Forth-94 Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-07-08 07:59 +0100
Re: The meaning of xt in Forth-94 Paul Rubin <no.email@nospam.invalid> - 2015-07-08 12:06 -0700
Re: The meaning of xt in Forth-94 hughaguilar96@gmail.com - 2015-07-08 20:08 -0700
Re: The meaning of xt in Forth-94 Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-07-09 08:31 +0100
Re: The meaning of xt in Forth-94 "Alex McDonald" <blog@rivadpm.com> - 2015-07-09 14:06 +0100
Re: The meaning of xt in Forth-94 "Alex McDonald" <blog@rivadpm.com> - 2015-07-09 14:09 +0100
Re: The meaning of xt in Forth-94 Paul Rubin <no.email@nospam.invalid> - 2015-07-09 13:34 -0700
Re: The meaning of xt in Forth-94 Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-07-10 20:27 +0100
Re: The meaning of xt in Forth-94 Paul Rubin <no.email@nospam.invalid> - 2015-07-10 12:46 -0700
Re: The meaning of xt in Forth-94 Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-07-10 21:48 +0100
Re: The meaning of xt in Forth-94 Bernd Paysan <bernd.paysan@gmx.de> - 2015-07-08 17:02 +0200
Re: The meaning of xt in Forth-94 "Alex McDonald" <blog@rivadpm.com> - 2015-07-08 17:48 +0100
Re: The meaning of xt in Forth-94 Bernd Paysan <bernd.paysan@gmx.de> - 2015-07-08 20:58 +0200
Re: The meaning of xt in Forth-94 "Alex McDonald" <blog@rivadpm.com> - 2015-07-08 20:19 +0100
Re: The meaning of xt in Forth-94 Bernd Paysan <bernd.paysan@gmx.de> - 2015-07-08 21:48 +0200
Re: The meaning of xt in Forth-94 "Alex McDonald" <blog@rivadpm.com> - 2015-07-09 00:47 +0100
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-09 04:56 +0000
Re: The meaning of xt in Forth-94 hughaguilar96@gmail.com - 2015-07-11 14:34 -0700
Re: The meaning of xt in Forth-94 Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-07-07 08:09 +0100
Re: The meaning of xt in Forth-94 Bernd Paysan <bernd.paysan@gmx.de> - 2015-07-07 16:32 +0200
Re: The meaning of xt in Forth-94 coos <chforth@hccnet.nl> - 2015-07-07 16:43 +0200
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-07 15:16 +0000
Re: The meaning of xt in Forth-94 Bernd Paysan <bernd.paysan@gmx.de> - 2015-07-07 22:14 +0200
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-08 02:06 +0000
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-07 14:57 +0000
Re: The meaning of xt in Forth-94 Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-07-07 22:51 +0100
Re: The meaning of xt in Forth-94 "Elizabeth D. Rather" <erather@forth.com> - 2015-07-07 13:11 -1000
Re: The meaning of xt in Forth-94 hughaguilar96@gmail.com - 2015-07-07 19:34 -0700
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-06 20:47 -0700
Re: The meaning of xt in Forth-94 hughaguilar96@gmail.com - 2015-07-06 21:55 -0700
Re: The meaning of xt in Forth-94 "Elizabeth D. Rather" <erather@forth.com> - 2015-07-05 08:53 -1000
Re: The meaning of xt in Forth-94 Mark Wills <markwills1970@gmail.com> - 2015-07-06 01:56 -0700
Re: The meaning of xt in Forth-94 "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-06-23 18:13 -0400
Re: The meaning of xt in Forth-94 Mark Wills <markwills1970@gmail.com> - 2015-06-24 01:44 -0700
Re: The meaning of xt in Forth-94 "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-06-24 20:07 -0400
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-25 17:05 +0000
Re: The meaning of xt in Forth-94 Mark Wills <markwills1970@gmail.com> - 2015-06-24 02:08 -0700
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-24 04:53 -0700
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-24 04:57 -0700
Re: The meaning of xt in Forth-94 Mark Wills <markwills1970@gmail.com> - 2015-06-24 05:46 -0700
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-24 07:05 -0700
Re: The meaning of xt in Forth-94 stephen@mpeforth.com (Stephen Pelc) - 2015-06-24 14:40 +0000
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-24 10:12 -0700
Re: The meaning of xt in Forth-94 stephen@mpeforth.com (Stephen Pelc) - 2015-06-24 20:35 +0000
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-24 15:01 +0000
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-24 08:58 -0700
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-24 09:54 -0700
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-28 16:40 +0000
Re: The meaning of xt in Forth-94 "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-06-28 15:10 -0400
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-28 23:32 -0700
Re: The meaning of xt in Forth-94 "Elizabeth D. Rather" <erather@forth.com> - 2015-06-28 21:37 -1000
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-29 01:38 -0700
Re: The meaning of xt in Forth-94 Mark Wills <markwills1970@gmail.com> - 2015-06-24 08:53 -0700
Re: The meaning of xt in Forth-94 "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-06-24 20:08 -0400
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-23 10:30 +0000
Re: The meaning of xt in Forth-94 Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-23 22:58 +0200
Re: The meaning of xt in Forth-94 Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-23 23:49 +0200
Re: bug in VFX --- IF does't work Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-19 15:07 +0200
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-20 16:09 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-06-22 16:24 -0700
Re: bug in VFX --- IF does't work "WJ" <w_a_x_man@yahoo.com> - 2015-06-15 17:41 +0000
Re: bug in VFX --- IF does't work "WJ" <w_a_x_man@yahoo.com> - 2015-06-15 16:54 +0000
Re: bug in VFX --- IF does't work rickman <gnuarm@gmail.com> - 2015-06-15 22:57 -0400
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-06-13 10:51 +0000
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-06-13 12:57 +0100
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-06-13 21:53 -0700
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-06-13 22:41 -0700
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-06-14 11:42 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-06-14 09:26 -0700
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-06-14 23:15 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-06-14 16:39 -0700
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-06-14 15:21 -0700
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-06-14 23:20 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-06-14 16:48 -0700
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-06-14 17:52 -0700
Re: bug in VFX --- IF does't work Doug Hoffman <glidedog@gmail.com> - 2015-06-14 21:13 -0400
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-06-14 20:09 -0700
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-03 10:25 -0700
Re: bug in VFX --- IF does't work rickman <gnuarm@gmail.com> - 2015-04-03 14:43 -0400
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-04-03 20:14 +0100
Re: bug in VFX --- IF does't work jfong@ms4.hinet.net - 2015-04-03 23:16 -0700
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-04-03 20:02 +0100
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-03 20:46 +0000
Re: bug in VFX --- IF does't work krishna.myneni@ccreweb.org - 2015-04-04 06:43 -0700
Re: bug in VFX --- IF does't work albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-04 17:31 +0000
Re: bug in VFX --- IF does't work krishna.myneni@ccreweb.org - 2015-04-04 15:54 -0700
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-04 21:01 -0700
Re: bug in VFX --- IF does't work "WJ" <w_a_x_man@yahoo.com> - 2015-04-06 04:48 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-04 13:57 -0700
Re: bug in VFX --- IF does't work rickman <gnuarm@gmail.com> - 2015-04-05 00:16 -0400
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-05 10:11 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-05 14:37 -0700
Re: bug in VFX --- IF does't work "WJ" <w_a_x_man@yahoo.com> - 2015-04-06 04:52 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-05 21:58 -0700
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-06 13:56 +0000
Re: bug in VFX --- IF does't work Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-06 22:22 +0200
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-06 18:09 -0700
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-07 14:30 +0000
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-04-07 15:43 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-10 19:55 -0700
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-04-11 15:51 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-11 16:25 -0700
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-04-12 10:22 +0000
Re: bug in VFX --- IF does't work albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-12 10:48 +0000
Re: bug in VFX --- IF does't work albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-12 10:53 +0000
Re: bug in VFX --- IF does't work Coos Haak <chforth@hccnet.nl> - 2015-04-12 14:18 +0200
Re: bug in VFX --- IF does't work Coos Haak <chforth@hccnet.nl> - 2015-04-12 14:35 +0200
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-13 12:36 +0000
Re: bug in VFX --- IF does't work Mark Wills <markwills1970@gmail.com> - 2015-04-13 06:00 -0700
Re: bug in VFX --- IF does't work Coos Haak <chforth@hccnet.nl> - 2015-04-13 21:02 +0200
Re: bug in VFX --- IF does't work Mark Wills <markwills1970@gmail.com> - 2015-04-13 13:32 -0700
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-12 09:40 -0700
Re: bug in VFX --- IF does't work rickman <gnuarm@gmail.com> - 2015-04-12 13:38 -0400
Re: bug in VFX --- IF does't work albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-12 18:55 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-13 00:07 -0700
Re: bug in VFX --- IF does't work albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-13 08:07 +0000
Re: bug in VFX --- IF does't work "WJ" <w_a_x_man@yahoo.com> - 2015-05-12 23:09 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-05-12 20:35 -0700
Re: bug in VFX --- IF does't work albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-13 10:10 +0000
Re: bug in VFX --- IF does't work rickman <gnuarm@gmail.com> - 2015-05-13 15:58 -0400
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-05-13 13:13 -0700
Re: bug in VFX --- IF does't work albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-14 11:40 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-05-14 18:48 -0700
Re: bug in VFX --- IF does't work rickman <gnuarm@gmail.com> - 2015-06-12 21:51 -0400
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-04-13 00:13 +0100
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-12 20:43 -0700
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-04-13 09:53 +0100
Re: bug in VFX --- IF does't work albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-14 09:46 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-14 10:01 -0700
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-04-14 18:24 +0100
Re: bug in VFX --- IF does't work "Rod Pemberton" <bork@lllljunkqwer.cpm> - 2015-04-14 17:17 -0400
Re: bug in VFX --- IF does't work Ron Aaron <rambamist@gmail.com> - 2015-04-13 18:08 +0300
Re: bug in VFX --- IF does't work "Rod Pemberton" <bork@lllljunkqwer.cpm> - 2015-04-06 22:07 -0400
Re: bug in VFX --- IF does't work "Elizabeth D. Rather" <erather@forth.com> - 2015-04-06 16:44 -1000
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-04-07 11:09 +0000
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-07 14:49 +0000
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-04-08 01:58 +0100
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-20 23:21 -0700
Re: bug in VFX --- IF does't work Mark Wills <markwills1970@gmail.com> - 2015-04-21 02:10 -0700
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-04-21 10:41 +0000
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-04-21 13:31 +0100
Re: bug in VFX --- IF does't work Mark Wills <markwills1970@gmail.com> - 2015-04-21 06:00 -0700
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-04-21 14:09 +0100
Re: bug in VFX --- IF does't work Lars Brinkhoff <lars.spam@nocrew.org> - 2015-04-22 10:59 +0200
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-04-22 11:41 +0000
Re: bug in VFX --- IF does't work Lars Brinkhoff <lars.spam@nocrew.org> - 2015-04-22 14:13 +0200
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-22 14:06 +0000
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-04-22 15:42 +0000
Re: bug in VFX --- IF does't work albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-22 15:57 +0000
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-22 16:43 +0000
Re: bug in VFX --- IF does't work Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-24 05:35 +0200
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-24 11:22 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-24 11:18 -0700
Re: bug in VFX --- IF does't work Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-25 01:21 +0200
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-25 16:49 +0000
Re: bug in VFX --- IF does't work Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-05-03 21:07 +0100
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-05-03 23:25 +0100
Re: bug in VFX --- IF does't work gwj.nexus@gmail.com - 2015-05-05 10:53 -0700
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-05-05 19:10 +0100
Re: bug in VFX --- IF does't work Gerry <gerry@jackson9000.fsnet.co.uk> - 2015-05-06 21:41 +0100
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-05-07 11:05 +0100
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-08 11:35 +0000
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-06 14:09 +0000
Re: bug in VFX --- IF does't work Bernd Paysan <bernd.paysan@gmx.de> - 2015-05-04 03:08 +0200
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-05-04 09:23 +0100
Re: bug in VFX --- IF does't work Bernd Paysan <bernd.paysan@gmx.de> - 2015-05-04 20:32 +0200
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-06 13:26 +0000
Re: bug in VFX --- IF does't work Bernd Paysan <bernd.paysan@gmx.de> - 2015-05-06 20:00 +0200
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-05-06 13:24 -0700
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-08 12:07 +0000
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-05-08 18:26 +0100
Re: bug in VFX --- IF does't work Bernd Paysan <bernd.paysan@gmx.de> - 2015-05-09 01:10 +0200
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-12 16:13 +0000
Re: bug in VFX --- IF does't work Bernd Paysan <bernd.paysan@gmx.de> - 2015-05-13 00:11 +0200
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-04 16:58 +0000
Re: bug in VFX --- IF does't work gwj.nexus@gmail.com - 2015-05-05 11:24 -0700
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-06 13:13 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-24 13:11 -0700
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-25 21:05 -0700
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-04-21 14:06 +0100
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-22 20:05 -0700
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-23 05:57 +0000
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-04-23 10:50 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-24 11:59 -0700
Re: bug in VFX --- IF does't work "WJ" <w_a_x_man@yahoo.com> - 2015-05-12 23:18 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-05-12 20:24 -0700
Re: bug in VFX --- IF does't work "Elizabeth D. Rather" <erather@forth.com> - 2015-04-24 08:56 -1000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-24 12:09 -0700
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-04-24 22:29 +0100
Re: bug in VFX --- IF does't work "WJ" <w_a_x_man@yahoo.com> - 2015-06-15 17:54 +0000
Re: bug in VFX --- IF does't work Jason Damisch <jasondamisch@yahoo.com> - 2015-04-02 09:04 -0700
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-02 21:04 -0700
Re: bug in VFX --- IF does't work albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-03 10:48 +0000
Re: bug in VFX --- IF does't work Hans Bezemer <the.beez.speaks@gmail.com> - 2015-04-10 17:52 +0200
Re: bug in VFX --- IF does't work albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-10 16:13 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-11 16:56 -0700
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-12 09:28 -0700
Re: bug in VFX --- IF does't work Jason Damisch <jasondamisch@yahoo.com> - 2015-04-03 10:26 -0700
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-05 21:54 -0700
Re: bug in VFX --- IF does't work Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-26 01:20 +0200
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-26 15:09 +0000
Re: bug in VFX --- IF does't work Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-27 03:13 +0200
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-01 14:59 +0000
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-05-01 19:38 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-05-01 16:59 -0700
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-02 15:56 +0000
Re: bug in VFX --- IF does't work Bernd Paysan <bernd.paysan@gmx.de> - 2015-05-01 22:45 +0200
Re: bug in VFX --- IF does't work JennyB <jennybrien@googlemail.com> - 2015-05-02 02:58 -0700
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-05-02 11:51 +0000
Re: bug in VFX --- IF does't work albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-02 12:25 +0000
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-02 16:45 +0000
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-05-02 19:12 +0100
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-03 16:23 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-05-03 15:47 -0700
Re: bug in VFX --- IF does't work Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> - 2015-05-04 10:11 +0100
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-05-04 09:16 -0700
Re: bug in VFX --- IF does't work roman.pavlyuk.0@gmail.com - 2015-05-04 10:15 -0700
Re: bug in VFX --- IF does't work "WJ" <w_a_x_man@yahoo.com> - 2015-06-15 23:35 +0000
Re: bug in VFX --- IF does't work Ching-Tang Tseng <ilikeforth@gmail.com> - 2015-07-02 02:31 -0700
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-07-02 17:20 +0000
Re: bug in VFX --- IF does't work Ching-Tang Tseng <ilikeforth@gmail.com> - 2015-07-02 15:40 -0700
Re: bug in VFX --- IF does't work rickman <gnuarm@gmail.com> - 2015-07-02 19:55 -0400
Re: bug in VFX --- IF does't work Ching-Tang Tseng <ilikeforth@gmail.com> - 2015-07-02 19:43 -0700
Re: bug in VFX --- IF does't work rickman <gnuarm@gmail.com> - 2015-07-02 23:08 -0400
Re: bug in VFX --- IF does't work Ching-Tang Tseng <ilikeforth@gmail.com> - 2015-07-02 21:56 -0700
Re: bug in VFX --- IF does't work rickman <gnuarm@gmail.com> - 2015-07-03 01:25 -0400
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-07-02 23:00 -0700
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-07-03 22:25 +0100
Re: bug in VFX --- IF does't work Ching-Tang Tseng <ilikeforth@gmail.com> - 2015-07-03 00:50 -0700
Re: bug in VFX --- IF does't work Ching-Tang Tseng <ilikeforth@gmail.com> - 2015-07-03 18:21 -0700
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-07-04 13:09 +0100
Re: bug in VFX --- IF does't work Ching-Tang Tseng <ilikeforth@gmail.com> - 2015-07-04 15:01 -0700
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-07-05 08:49 +0100
Re: bug in VFX --- IF does't work Bernd Paysan <bernd.paysan@gmx.de> - 2015-07-05 15:23 +0200
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-07-05 15:56 +0100
Re: bug in VFX --- IF does't work rickman <gnuarm@gmail.com> - 2015-07-05 12:21 -0400
Re: bug in VFX --- IF does't work Mark Wills <markwills1970@gmail.com> - 2015-07-06 01:45 -0700
Re: bug in VFX --- IF does't work rickman <gnuarm@gmail.com> - 2015-07-06 12:47 -0400
Page 13 of 26 — ← Prev page 1 … 11 12 [13] 14 15 … 26 Next page →
| From | "Rod Pemberton" <boo@fasdfrewar.cdm> |
|---|---|
| Date | 2015-07-03 04:32 -0400 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <op.x06vckqwyfako5@localhost> |
| In reply to | #40266 |
On Fri, 03 Jul 2015 01:40:40 -0400, <hughaguilar96@gmail.com> wrote: > My first-ever ANS-Forth program was the LowDraw.4th program, and it > worked without problem. ... > My second ANS-Forth program was the LC53 encryption-cracking program, > and it was problematic --- I ticked semicolon (gasp!) and the house of > cards collapsed --- [...] It would seem, from your own description, that the problematic issue had something to do with you, not necessarily ANS. If you can't do that in ANS, i.e., ' (tick) semicolon, how can you even claim your program is ANS? This seems to be an issue of perception on your part. I.e., you're correct, and the standard is wrong. Others have been saying this to you already. Does repeating your perspective to a crowd which doesn't accept your perspective change anything for you? Unless you have some hidden agenda, this seems to be a fruitless pursuit, i.e., like anyone replying to you. Rod Pemberton -- Tolerance and socialism attracts intolerance and terrorism. See: France, United Kingdom, Germany, Denmark, Belgium, Netherlands, ...
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2015-07-03 03:03 -0700 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <c39fba13-6eca-4eae-b2b9-4e57558e097b@googlegroups.com> |
| In reply to | #40269 |
vineri, 3 iulie 2015, 11:32:21 UTC+3, Rod Pemberton a scris: > On Fri, 03 Jul 2015 01:40:40 -0400, <hughaguilar96@gmail.com> wrote: > > > My first-ever ANS-Forth program was the LowDraw.4th program, and it > > worked without problem. > ... > > > My second ANS-Forth program was the LC53 encryption-cracking program, > > and it was problematic --- I ticked semicolon (gasp!) and the house of > > cards collapsed --- [...] > > It would seem, from your own description, that the problematic > issue had something to do with you, not necessarily ANS. If you > can't do that in ANS, i.e., ' (tick) semicolon, how can you even > claim your program is ANS? This seems to be an issue of perception > on your part. I.e., you're correct, and the standard is wrong. > Others have been saying this to you already. Does repeating your > perspective to a crowd which doesn't accept your perspective change > anything for you? Unless you have some hidden agenda, this seems > to be a fruitless pursuit, i.e., like anyone replying to you. > > > Rod Pemberton > > -- > Tolerance and socialism attracts intolerance and terrorism. See: > France, United Kingdom, Germany, Denmark, Belgium, Netherlands, ... Rod, I don't want to take the Hugh's part here, it is a common-sense issue. Hugh ticked semicolon and got some abort I suppose. Then he ticked the semicolon in another standard forth and it worked. Both forths are standard. Is Hugh to blame? Tick has to provide an xt, but I don't want to start the discussion again. If you (anybody) will use only one forth for some time, you will encounter some of these problems. You will read the standard and find that they are allowed. So you are to blame, ok. You will work around the problem in some way because you should have the job done. But after some time (maybe a long time) you suddenly need to compile your application with another (standard) forth2. And it crash. You scratch your head to see why it crashed, go to the standard again and find that this is also allowed. You have nobody to blame, all guys are standard! You end up with two versions of your app (app_forth1, app_forth2) or you find a third way to write your app that will work on both forths. Then after some time you need to use forth3...
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2015-07-03 03:16 -0700 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <53b59d49-e221-4613-b7b3-96174452032c@googlegroups.com> |
| In reply to | #40270 |
On Friday, 3 July 2015 11:03:37 UTC+1, Raimond Dragomir wrote: > vineri, 3 iulie 2015, 11:32:21 UTC+3, Rod Pemberton a scris: > > On Fri, 03 Jul 2015 01:40:40 -0400, <hughaguilar96@gmail.com> wrote: > > > > > My first-ever ANS-Forth program was the LowDraw.4th program, and it > > > worked without problem. > > ... > > > > > My second ANS-Forth program was the LC53 encryption-cracking program, > > > and it was problematic --- I ticked semicolon (gasp!) and the house of > > > cards collapsed --- [...] > > > > It would seem, from your own description, that the problematic > > issue had something to do with you, not necessarily ANS. If you > > can't do that in ANS, i.e., ' (tick) semicolon, how can you even > > claim your program is ANS? This seems to be an issue of perception > > on your part. I.e., you're correct, and the standard is wrong. > > Others have been saying this to you already. Does repeating your > > perspective to a crowd which doesn't accept your perspective change > > anything for you? Unless you have some hidden agenda, this seems > > to be a fruitless pursuit, i.e., like anyone replying to you. > > > > > > Rod Pemberton > > > > -- > > Tolerance and socialism attracts intolerance and terrorism. See: > > France, United Kingdom, Germany, Denmark, Belgium, Netherlands, ... > > Rod, > I don't want to take the Hugh's part here, it is a common-sense issue. > Hugh ticked semicolon and got some abort I suppose. Then he ticked > the semicolon in another standard forth and it worked. Both forths > are standard. Is Hugh to blame? Tick has to provide an xt, but I don't > want to start the discussion again. > > If you (anybody) will use only one forth for some time, you will encounter > some of these problems. You will read the standard and find that they are > allowed. So you are to blame, ok. You will work around the problem in some > way because you should have the job done. But after some time (maybe a long > time) you suddenly need to compile your application with another (standard) > forth2. And it crash. You scratch your head to see why it crashed, go to > the standard again and find that this is also allowed. You have nobody to > blame, all guys are standard! You end up with two versions of your app > (app_forth1, app_forth2) or you find a third way to write your app that > will work on both forths. Then after some time you need to use forth3... 100% correct.
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-07-03 22:06 +0100 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <mn6te6$6di$1@dont-email.me> |
| In reply to | #40271 |
on 03/07/2015 11:16:39, Mark Wills wrote: > On Friday, 3 July 2015 11:03:37 UTC+1, Raimond Dragomir wrote: >> vineri, 3 iulie 2015, 11:32:21 UTC+3, Rod Pemberton a scris: >> > On Fri, 03 Jul 2015 01:40:40 -0400, <hughaguilar96@gmail.com> wrote: >> > >> > > My first-ever ANS-Forth program was the LowDraw.4th program, and it >> > > worked without problem. >> > ... >> > >> > > My second ANS-Forth program was the LC53 encryption-cracking program, >> > > and it was problematic --- I ticked semicolon (gasp!) and the house of >> > > cards collapsed --- [...] >> > >> > It would seem, from your own description, that the problematic >> > issue had something to do with you, not necessarily ANS. If you >> > can't do that in ANS, i.e., ' (tick) semicolon, how can you even >> > claim your program is ANS? This seems to be an issue of perception >> > on your part. I.e., you're correct, and the standard is wrong. >> > Others have been saying this to you already. Does repeating your >> > perspective to a crowd which doesn't accept your perspective change >> > anything for you? Unless you have some hidden agenda, this seems >> > to be a fruitless pursuit, i.e., like anyone replying to you. >> > >> > >> > Rod Pemberton >> > >> > -- >> > Tolerance and socialism attracts intolerance and terrorism. See: >> > France, United Kingdom, Germany, Denmark, Belgium, Netherlands, ... >> >> Rod, >> I don't want to take the Hugh's part here, it is a common-sense issue. >> Hugh ticked semicolon and got some abort I suppose. Then he ticked >> the semicolon in another standard forth and it worked. Both forths >> are standard. Is Hugh to blame? Tick has to provide an xt, but I don't >> want to start the discussion again. >> >> If you (anybody) will use only one forth for some time, you will encounter >> some of these problems. You will read the standard and find that they are >> allowed. So you are to blame, ok. You will work around the problem in some >> way because you should have the job done. But after some time (maybe a long >> time) you suddenly need to compile your application with another (standard) >> forth2. And it crash. You scratch your head to see why it crashed, go to >> the standard again and find that this is also allowed. You have nobody to >> blame, all guys are standard! You end up with two versions of your app >> (app_forth1, app_forth2) or you find a third way to write your app that >> will work on both forths. Then after some time you need to use forth3... > > 100% correct. > To all of you excepting Rod I would say; *WRITE A PROPOSAL FOR DISCUSSION THAT CHANGES THE SPECIFICATION*. Stop whining. Just do it.
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2015-07-03 22:39 -0700 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <b51f125b-b41e-45d1-afab-148f53ccac69@googlegroups.com> |
| In reply to | #40273 |
sâmbătă, 4 iulie 2015, 00:06:35 UTC+3, Alex McDonald a scris: > on 03/07/2015 11:16:39, Mark Wills wrote: > > On Friday, 3 July 2015 11:03:37 UTC+1, Raimond Dragomir wrote: > >> vineri, 3 iulie 2015, 11:32:21 UTC+3, Rod Pemberton a scris: > >> > On Fri, 03 Jul 2015 01:40:40 -0400, <hughaguilar96@gmail.com> wrote: > >> > > >> > > My first-ever ANS-Forth program was the LowDraw.4th program, and it > >> > > worked without problem. > >> > ... > >> > > >> > > My second ANS-Forth program was the LC53 encryption-cracking program, > >> > > and it was problematic --- I ticked semicolon (gasp!) and the house of > >> > > cards collapsed --- [...] > >> > > >> > It would seem, from your own description, that the problematic > >> > issue had something to do with you, not necessarily ANS. If you > >> > can't do that in ANS, i.e., ' (tick) semicolon, how can you even > >> > claim your program is ANS? This seems to be an issue of perception > >> > on your part. I.e., you're correct, and the standard is wrong. > >> > Others have been saying this to you already. Does repeating your > >> > perspective to a crowd which doesn't accept your perspective change > >> > anything for you? Unless you have some hidden agenda, this seems > >> > to be a fruitless pursuit, i.e., like anyone replying to you. > >> > > >> > > >> > Rod Pemberton > >> > > >> > -- > >> > Tolerance and socialism attracts intolerance and terrorism. See: > >> > France, United Kingdom, Germany, Denmark, Belgium, Netherlands, ... > >> > >> Rod, > >> I don't want to take the Hugh's part here, it is a common-sense issue. > >> Hugh ticked semicolon and got some abort I suppose. Then he ticked > >> the semicolon in another standard forth and it worked. Both forths > >> are standard. Is Hugh to blame? Tick has to provide an xt, but I don't > >> want to start the discussion again. > >> > >> If you (anybody) will use only one forth for some time, you will encounter > >> some of these problems. You will read the standard and find that they are > >> allowed. So you are to blame, ok. You will work around the problem in some > >> way because you should have the job done. But after some time (maybe a long > >> time) you suddenly need to compile your application with another (standard) > >> forth2. And it crash. You scratch your head to see why it crashed, go to > >> the standard again and find that this is also allowed. You have nobody to > >> blame, all guys are standard! You end up with two versions of your app > >> (app_forth1, app_forth2) or you find a third way to write your app that > >> will work on both forths. Then after some time you need to use forth3... > > > > 100% correct. > > > > To all of you excepting Rod I would say; *WRITE A PROPOSAL FOR DISCUSSION > THAT CHANGES THE SPECIFICATION*. Stop whining. Just do it. whine, whining. I'm learning new english words here. That's good.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-07-04 14:45 +0000 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <2015Jul4.164545@mips.complang.tuwien.ac.at> |
| In reply to | #40270 |
Raimond Dragomir <raimond.dragomir@gmail.com> writes:
>I don't want to take the Hugh's part here, it is a common-sense issue.
>Hugh ticked semicolon and got some abort I suppose. Then he ticked
>the semicolon in another standard forth and it worked. Both forths
>are standard. Is Hugh to blame? Tick has to provide an xt, but I don't
>want to start the discussion again.
>
>If you (anybody) will use only one forth for some time, you will encounter
>some of these problems. You will read the standard and find that they are
>allowed. So you are to blame, ok. You will work around the problem in some
>way because you should have the job done. But after some time (maybe a long
>time) you suddenly need to compile your application with another (standard)
>forth2. And it crash. You scratch your head to see why it crashed, go to
>the standard again and find that this is also allowed. You have nobody to
>blame, all guys are standard!
In theory you have yourself to blame, because you wrote a non-standard
program. In practice, with testing being the dominating way to
approximate to correctness, you can have a hard time finding out if
your program is standard-compliant, or not, and if not, where.
But as long as we have a standard that specifies an interface instead
of nailing everything down like Java does, that's the way things are.
If you want something nailed-down, choose one version and one port of
one particular Forth system, and you should get what you want. Your
code does not port to another Forth system? True, but why would you
consider that to be a problem?
One example of non-standardness: You develop on, say, VFX, and use "12
+" instead of "3 cells +", and then you port it to a 64-bit Gforth,
and your program does not work as intended (because on that system
there is a difference between 12 and "3 cells" (wich costs 24 bytes
there). How could we avoid that? Nail down the cell size? If so, to
what? Have some kind of checker ("lint") that notices some of these
usages and warns about them? Or simply test on 32-bit an 64-bit
systems? Interestingly, I have had very few problems (many fewer than
in C) with this kind of mistake.
> You end up with two versions of your app
>(app_forth1, app_forth2) or you find a third way to write your app that
>will work on both forths. Then after some time you need to use forth3...
Despite the fundamental problems, there are a few Forth programs of
significant size that work across several systems, e.g., those in
<http://www.complang.tuwien.ac.at/forth/appbench.zip>.
- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-07-04 11:39 -0700 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <b3d5d96d-1be6-4619-aceb-b313ab70607f@googlegroups.com> |
| In reply to | #40282 |
On Saturday, July 4, 2015 at 8:06:48 AM UTC-7, Anton Ertl wrote:
> Raimond Dragomir <raimond.dragomir@gmail.com> writes:
> >I don't want to take the Hugh's part here, it is a common-sense issue.
> >Hugh ticked semicolon and got some abort I suppose. Then he ticked
> >the semicolon in another standard forth and it worked. Both forths
> >are standard. Is Hugh to blame? Tick has to provide an xt, but I don't
> >want to start the discussion again.
> >
> >If you (anybody) will use only one forth for some time, you will encounter
> >some of these problems. You will read the standard and find that they are
> >allowed. So you are to blame, ok. You will work around the problem in some
> >way because you should have the job done. But after some time (maybe a long
> >time) you suddenly need to compile your application with another (standard)
> >forth2. And it crash. You scratch your head to see why it crashed, go to
> >the standard again and find that this is also allowed. You have nobody to
> >blame, all guys are standard!
>
> In theory you have yourself to blame, because you wrote a non-standard
> program. In practice, with testing being the dominating way to
> approximate to correctness, you can have a hard time finding out if
> your program is standard-compliant, or not, and if not, where.
My experience with ANS-Forth, beginning with my second ANS-Forth program (the LC53 encryption cracking program) is that the self-proclaimed leadership are not focused on helping people to write programs that work and are portable --- you are primarily focused on telling Forth programmers that they are wrong, that they are stupid, and that they are to blame for everything that goes wrong (including global warming).
> But as long as we have a standard that specifies an interface instead
> of nailing everything down like Java does, that's the way things are.
The ANS-Forth committee failed to understand that the standard should define behavior rather than implementation. A good example is 3.2.3.2: "The control-flow stack may, but need not, physically exist in an implementation. If it does exist, it may be, but need not be, implemented using the data stack."
This seems to indicate that it could be either the same as the data-stack or distinct --- but the behavior is completely different! --- the programmer has to figure out which is the worst-case scenario (that they are the same) and assume that this is the standard.
> If you want something nailed-down, choose one version and one port of
> one particular Forth system, and you should get what you want. Your
> code does not port to another Forth system? True, but why would you
> consider that to be a problem?
It is a problem because the purpose of a language standard is to allow programs to be portable between standard-compliant systems.
In regard to section 3.2.3.2, Elizabeth Rather the chair-person of the ANS-Forth committee said: "if you really want to be able to pass values into a colon definition, declare a dependency on being able to do that and forge ahead."
Forth Inc. appointed you to be the chair-person of the Forth-200x committee because of your loyalty --- not because you understand what the purpose of a language standard is --- just declare a dependency and forge ahead!
> One example of non-standardness: You develop on, say, VFX, and use "12
> +" instead of "3 cells +", and then you port it to a 64-bit Gforth,
> and your program does not work as intended (because on that system
> there is a difference between 12 and "3 cells" (wich costs 24 bytes
> there). How could we avoid that? Nail down the cell size? If so, to
> what? Have some kind of checker ("lint") that notices some of these
> usages and warns about them? Or simply test on 32-bit an 64-bit
> systems? Interestingly, I have had very few problems (many fewer than
> in C) with this kind of mistake.
When I wrote MFX in Forth-83, I used constants, such as W for the cell size (2 on a 16-bit system or 4 on a 32-bit system). This technique was well known among Forth-83 programmers. MFX worked on either a 16-bit or 32-bit system (for a while, then it got too big for the 16-bit system and so I had to require a 32-bit system).
This is an easy problem to solve, and everybody solved it in the late 1980s or early 1990s --- the Forth Inc. books failed to mention this obvious solution --- but anybody who gave a moment's thought to the subject figured out the solution.
> > You end up with two versions of your app
> >(app_forth1, app_forth2) or you find a third way to write your app that
> >will work on both forths. Then after some time you need to use forth3...
>
> Despite the fundamental problems, there are a few Forth programs of
> significant size that work across several systems, e.g., those in
> <http://www.complang.tuwien.ac.at/forth/appbench.zip>.
My novice package works on SwiftForth, Win32Forth, gForth and VFX --- but, you say that I'm not an ANS-Forth programmer (because Elizabeth Rather told you to say this).
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-07-04 19:55 +0100 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <mn9a4g$3bj$1@dont-email.me> |
| In reply to | #40283 |
on 04/07/2015 19:39:12, huge wrote: > >> But as long as we have a standard that specifies an interface instead >> of nailing everything down like Java does, that's the way things are. > > The ANS-Forth committee failed to understand that the standard should > defin e behavior rather than implementation. A good example is > 3.2.3.2: "The cont rol-flow stack may, but need not, physically exist > in an implementation. If it does exist, it may be, but need not be, > implemented using the data stac k." > > This seems to indicate that it could be either the same as the > data-stack o r distinct --- but the behavior is completely different! > --- the programmer has to figure out which is the worst-case scenario > (that they are the same ) and assume that this is the standard. Well done. How long did it take you to work this out? The standard has done *exactly* what you wanted and keep asking for. It has described behaviour and not implementation. Yet you insist that it does the opposite, and that having the control flow stack as a separate stack does not describe implementation. You can't have it both ways. Which is it? Stephen Pelc is on the money here. It simply doesn't do what you want it to do. Hence the temper tantrum.
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2015-07-04 20:54 -0700 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <d9177e65-8a1f-4d42-a86d-560e8f5eb40f@googlegroups.com> |
| In reply to | #40284 |
sâmbătă, 4 iulie 2015, 21:55:33 UTC+3, Alex McDonald a scris:
> on 04/07/2015 19:39:12, huge wrote:
>
> >
> >> But as long as we have a standard that specifies an interface instead
> >> of nailing everything down like Java does, that's the way things are.
> >
> > The ANS-Forth committee failed to understand that the standard should
> > defin e behavior rather than implementation. A good example is
> > 3.2.3.2: "The cont rol-flow stack may, but need not, physically exist
> > in an implementation. If it does exist, it may be, but need not be,
> > implemented using the data stac k."
> >
> > This seems to indicate that it could be either the same as the
> > data-stack o r distinct --- but the behavior is completely different!
> > --- the programmer has to figure out which is the worst-case scenario
> > (that they are the same ) and assume that this is the standard.
>
> Well done. How long did it take you to work this out?
>
> The standard has done *exactly* what you wanted and keep asking for. It
> has described behaviour and not implementation. Yet you insist that it
> does the opposite, and that having the control flow stack as a separate
> stack does not describe implementation.
>
> You can't have it both ways. Which is it?
>
> Stephen Pelc is on the money here. It simply doesn't do what you want it
> to do. Hence the temper tantrum.
Behaviour:
IF ( C: -- orig )
Implementation:
"The control-flow stack may, but need not, physically exist
in an implementation. If it does exist, it may be, but need not be,
implemented using the data stack."
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-07-05 07:18 +0100 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <mnai4k$3bn$1@dont-email.me> |
| In reply to | #40290 |
on 05/07/2015 04:54:11, Raimond Dragomir wrote: > sâmbata, 4 iulie 2015, 21:55:33 UTC+3, Alex McDonald a scris >: >> on 04/07/2015 19:39:12, huge wrote: >> >> > >> >> But as long as we have a standard that specifies an interface instead >> >> of nailing everything down like Java does, that's the way things are. >> > >> > The ANS-Forth committee failed to understand that the standard should >> > defin e behavior rather than implementation. A good example is >> > 3.2.3.2: "The cont rol-flow stack may, but need not, physically exist >> > in an implementation. If it does exist, it may be, but need not be, >> > implemented using the data stac k." >> > >> > This seems to indicate that it could be either the same as the >> > data-stack o r distinct --- but the behavior is completely different! >> > --- the programmer has to figure out which is the worst-case scenario >> > (that they are the same ) and assume that this is the standard. >> >> Well done. How long did it take you to work this out? >> >> The standard has done *exactly* what you wanted and keep asking for. It >> has described behaviour and not implementation. Yet you insist that it >> does the opposite, and that having the control flow stack as a separate >> stack does not describe implementation. >> >> You can't have it both ways. Which is it? >> >> Stephen Pelc is on the money here. It simply doesn't do what you want it >> to do. Hence the temper tantrum. > > Behaviour: > > IF ( C: -- orig ) > > Implementation: > > "The control-flow stack may, but need not, physically exist > in an implementation. If it does exist, it may be, but need not be, > implemented using the data stack." > Exactly so. The specification describes behaviour and not the implementation of that behaviour.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-07-04 21:47 -1000 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <idOdnQt9pKu8fAXInZ2dnUU7-RGdnZ2d@supernews.com> |
| In reply to | #40292 |
On 7/4/15 8:18 PM, Alex McDonald wrote: > on 05/07/2015 04:54:11, Raimond Dragomir wrote: >> sâmbata, 4 iulie 2015, 21:55:33 UTC+3, Alex McDonald a scris >> : >>> on 04/07/2015 19:39:12, huge wrote: >>> >>>> >>>>> But as long as we have a standard that specifies an interface instead >>>>> of nailing everything down like Java does, that's the way things are. >>>> >>>> The ANS-Forth committee failed to understand that the standard should >>>> defin e behavior rather than implementation. A good example is >>>> 3.2.3.2: "The cont rol-flow stack may, but need not, physically exist >>>> in an implementation. If it does exist, it may be, but need not be, >>>> implemented using the data stac k." >>>> >>>> This seems to indicate that it could be either the same as the >>>> data-stack o r distinct --- but the behavior is completely different! >>>> --- the programmer has to figure out which is the worst-case scenario >>>> (that they are the same ) and assume that this is the standard. >>> >>> Well done. How long did it take you to work this out? >>> >>> The standard has done *exactly* what you wanted and keep asking for. It >>> has described behaviour and not implementation. Yet you insist that it >>> does the opposite, and that having the control flow stack as a separate >>> stack does not describe implementation. >>> >>> You can't have it both ways. Which is it? >>> >>> Stephen Pelc is on the money here. It simply doesn't do what you want it >>> to do. Hence the temper tantrum. >> >> Behaviour: >> >> IF ( C: -- orig ) >> >> Implementation: >> >> "The control-flow stack may, but need not, physically exist >> in an implementation. If it does exist, it may be, but need not be, >> implemented using the data stack." >> > > Exactly so. The specification describes behaviour and not the > implementation of that behaviour. What the note *does* do is post an advisory notice to users that *some* implementations may use the data stack, and therefore it's inadvisable to assume you have free use of the data stack between IF and THEN. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2015-07-05 01:49 -0700 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <c261baff-d8c6-48f9-9dd8-bd9ecb5bf343@googlegroups.com> |
| In reply to | #40292 |
> > > > Behaviour: > > > > IF ( C: -- orig ) > > > > Implementation: > > > > "The control-flow stack may, but need not, physically exist > > in an implementation. If it does exist, it may be, but need not be, > > implemented using the data stack." > > > > Exactly so. The specification describes behaviour and not the > implementation of that behaviour. So the behaviour is IF ( C: -- orig ) but C (control stack) may not exist ?? Forth language is special in its explicit stacks. Data stack being most important of course, but return stack is quite explicit also. Every behaviour in the forth language is described by the stack effect. If return stack is not given, it is not altered. If the data stack is not given, it is -- . For some cases there are complicated effects given as i*x j*x or the like. How about IF, or other control structures? I WANT TO KNOW THE "DATA STACK" EFFECT OF THE WORD "IF". Maybe I even don't care about "other" stacks effect. If I read the standard, it is -- (no effect). Is it? My main concern is the "data stack". All words in the Forth standard (not C standard or any other standard) - FORTH standard - must give me the data stack effect, because it's explicit. I don't care about the control stack, I care about data stack. You seem to not understand this simple issue.
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-07-05 10:30 +0100 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <mnatcj$34h$1@dont-email.me> |
| In reply to | #40299 |
on 05/07/2015 09:48:57, Raimond Dragomir wrote: >> > >> > Behaviour: >> > >> > IF ( C: -- orig ) >> > >> > Implementation: >> > >> > "The control-flow stack may, but need not, physically exist >> > in an implementation. If it does exist, it may be, but need not be, >> > implemented using the data stack." >> > >> >> Exactly so. The specification describes behaviour and not the >> implementation of that behaviour. > > So the behaviour is IF ( C: -- orig ) but C (control stack) may not > exist ?? > Yes; as you wrote above, this is the /behaviour/ of IF, not its implementation. > Forth language is special in its explicit stacks. Data stack being > most important of course, but return stack is quite explicit also. > > Every behaviour in the forth language is described by the stack > effect. If return stack is not given, it is not altered. If the data > stack is not given, it is -- . For some cases there are complicated > effects given as i*x j*x or the like. > > How about IF, or other control structures? I WANT TO KNOW THE "DATA > STACK" EFFECT OF THE WORD "IF". Maybe I even don't care about "other" > stacks effect. If I read the standard, it is -- (no effect). Is it? > > My main concern is the "data stack". All words in the Forth standard > (not C standard or any other standard) - FORTH standard - must give me > the data stack effect, because it's explicit. > > I don't care about the control stack, I care about data stack. You > seem to not understand this simple issue. For the sake of argument, let's say we defined the control stack as the data stack. Then IF ( -- orig ) at compile time. Or we could mandate a separate control flow stack. Then IF ( -- c: orig ) at compile time. Which would you prefer?
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2015-07-05 03:09 -0700 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <5e7c6781-960a-400c-8554-67baf68bd8a8@googlegroups.com> |
| In reply to | #40301 |
> > So the behaviour is IF ( C: -- orig ) but C (control stack) may not > > exist ?? > > > > Yes; as you wrote above, this is the /behaviour/ of IF, not its > implementation. > I really don't get it. IF is specified to put something on a stack which may not exist... > > Forth language is special in its explicit stacks. Data stack being > > most important of course, but return stack is quite explicit also. > > > > Every behaviour in the forth language is described by the stack > > effect. If return stack is not given, it is not altered. If the data > > stack is not given, it is -- . For some cases there are complicated > > effects given as i*x j*x or the like. > > > > How about IF, or other control structures? I WANT TO KNOW THE "DATA > > STACK" EFFECT OF THE WORD "IF". Maybe I even don't care about "other" > > stacks effect. If I read the standard, it is -- (no effect). Is it? > > > > My main concern is the "data stack". All words in the Forth standard > > (not C standard or any other standard) - FORTH standard - must give me > > the data stack effect, because it's explicit. > > > > I don't care about the control stack, I care about data stack. You > > seem to not understand this simple issue. > > For the sake of argument, let's say we defined the control stack as the > data stack. Then IF ( -- orig ) at compile time. Or we could mandate a > separate control flow stack. Then IF ( -- c: orig ) at compile time. > > Which would you prefer? I prefer IF ( C: -- orig ) exactly like in standrad. Or if you prefer: IF ( -- R: -- C: -- orig ) But it's not about which I prefer. It's about that the standard IF has really undefined behaviour, regarding any stack at all. Because you can have any situation. The bad thing is that it is not specified against data stack and return stack. If you really like to not have a control stack standardized, maybe: IF ( -- R: -- ) should be a solution. Then you are allowed to do anything you want to compile IF. The control stack may be or may not be, you can do whatever you want, yet this IF is very clearly specified. And for the behaviour you can write a literature about what IF is all about, like in C or any other language.
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-07-05 16:29 +0100 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <mnbidj$c1o$1@dont-email.me> |
| In reply to | #40303 |
on 05/07/2015 11:09:27, Raimond Dragomir wrote: >> > So the behaviour is IF ( C: -- orig ) but C (control stack) may not >> > exist ?? >> > >> >> Yes; as you wrote above, this is the /behaviour/ of IF, not its >> implementation. >> > > > I really don't get it. IF is specified to put something on a stack > which may not exist... No: IF puts something on a thing called a control stack. How the control stack is implemented is entirely up to the compiler writer but it a. may exist as a separate stack b. may exist on the data stack c. may be a list, an array, a matrix d. may be marks on a notepad if the compiler is a human. It's a state. How that state is recorded isn't specified. (Although, since the data stack is mentioned explicitly as a possible control stack, keeping the information on the float or return stack would seem to be excluded.) > > >> > Forth language is special in its explicit stacks. Data stack being >> > most important of course, but return stack is quite explicit also. >> > >> > Every behaviour in the forth language is described by the stack >> > effect. If return stack is not given, it is not altered. If the data >> > stack is not given, it is -- . For some cases there are complicated >> > effects given as i*x j*x or the like. >> > >> > How about IF, or other control structures? I WANT TO KNOW THE "DATA >> > STACK" EFFECT OF THE WORD "IF". Maybe I even don't care about "other" >> > stacks effect. If I read the standard, it is -- (no effect). Is it? >> > >> > My main concern is the "data stack". All words in the Forth standard >> > (not C standard or any other standard) - FORTH standard - must give me >> > the data stack effect, because it's explicit. >> > >> > I don't care about the control stack, I care about data stack. You >> > seem to not understand this simple issue. >> >> For the sake of argument, let's say we defined the control stack as the >> data stack. Then IF ( -- orig ) at compile time. Or we could mandate a >> separate control flow stack. Then IF ( -- c: orig ) at compile time. >> >> Which would you prefer? > > I prefer IF ( C: -- orig ) exactly like in standrad. Or if you prefer: > IF ( -- R: -- C: -- orig ) > > But it's not about which I prefer. It's about that the standard IF has > really undefined behaviour, regarding any stack at all. Because you > can have any situation. The bad thing is that it is not specified > against data stack and return stack. > > If you really like to not have a control stack standardized, maybe: > IF ( -- R: -- ) should be a solution. Then you are allowed to do > anything you want to compile IF. The control stack may be or may not > be, you can do whatever you want, yet this IF is very clearly > specified. And for the behaviour you can write a literature about what > IF is all about, like in C or any other language. > > You haven't said how you want this stack to be instantiated. Forget for the moment the stack diagrams; should the control stack be a separate stack, or should it be the data stack?
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2015-07-05 09:49 -0700 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <ca6e2bb8-b443-467a-8f8b-569028e1a0b5@googlegroups.com> |
| In reply to | #40318 |
> > I prefer IF ( C: -- orig ) exactly like in standrad. Or if you prefer: > > IF ( -- R: -- C: -- orig ) > > > > You haven't said how you want this stack to be instantiated. Forget for > the moment the stack diagrams; should the control stack be a separate > stack, or should it be the data stack? IF ( -- R: -- C: -- orig ) Data stack ( -- ) Return stack ( -- ) Control stack ( C: -- orig ) This means that control stack is different from data stack and return stack. A third stack. However, I also said that: Data stack ( -- ) Return stack ( -- ) is ok with me too, and the control stack may be, yes, any structure you can imagine, list, array, a drawing on a paper, anything.
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-07-05 22:10 +0100 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <mnc6df$om0$1@dont-email.me> |
| In reply to | #40321 |
on 05/07/2015 17:49:20, Raimond Dragomir wrote: >> > I prefer IF ( C: -- orig ) exactly like in standrad. Or if you prefer: >> > IF ( -- R: -- C: -- orig ) >> > >> >> You haven't said how you want this stack to be instantiated. Forget for >> the moment the stack diagrams; should the control stack be a separate >> stack, or should it be the data stack? > > IF ( -- R: -- C: -- orig ) > Data stack ( -- ) > Return stack ( -- ) > Control stack ( C: -- orig ) > This means that control stack is different from data stack and return > stack. A third stack. > > However, I also said that: > Data stack ( -- ) > Return stack ( -- ) > is ok with me too, and the control stack may be, yes, any structure > you can imagine, list, array, a drawing on a paper, anything. > OK, so we now have a separate control stack or somesuch. The implementor of a Forth system now has to provide a new stack (or structures or whatever), with enough entries for some number of ORIG or DEST type control flow entries (which may be more than 1 cell) and words for managing this over and above CS-PICK and CS-ROLL. This stack (or whatever) is only used during compilation. This may take up several 10s to 100s of bytes in stack and dictionary space. In memory constrained systems, this may be very costly to implement. (Even in a big fat system like Win32Forth, I think you'd meet resistance to adding unneeded words.) Can you justify this additional compilation time cost?
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-07-05 14:54 -0700 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <871tgmp8xs.fsf@nightsong.com> |
| In reply to | #40325 |
"Alex McDonald" <blog@rivadpm.com> writes: > OK, so we now have a separate control stack or somesuch.... This stack > (or whatever) is only used during compilation. This may take up > several 10s to 100s of bytes in stack and dictionary space. In memory > constrained systems, this may be very costly to implement. (Even in a > big fat system like Win32Forth, I think you'd meet resistance to > adding unneeded words.) Can you justify this additional compilation > time cost? I'd say there are pros and cons: * The separate control stack gives the compiler more flexibility to use the data stack during compilation, e.g. for on-the-fly peephole optimization. * OTOH on a memory constrained host, you probably want the simplest possible compiler, which won't have much use for that flexibility. So it can use the data stack. The Forth standard word set was to some extent designed for that minimalistic compiler implementation. * The control stack will normally need just one cell for each level of nested IF's/loops/etc permissible. So tens rather than 100s of bytes of stack space is probably enough in a memory constrained system that won't have very deeply nested words (sign of poor factoring anyway). Such a system is likely to be an MCU, where dictionary space (flash) is less precious than ram, so ram consumption is the main issue. * These days for memory constrained targets, cross-compilation will usually make more sense than a resident interpreter. So compile time resources will be plentiful. In a big system, the separate control stack (or even a combination of locals and recursion) means there's less to bother your head about in the compiler implementation.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-07-05 12:41 -1000 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <Z56dnYEoJO43LwTInZ2dnUU7-IGdnZ2d@supernews.com> |
| In reply to | #40328 |
On 7/5/15 11:54 AM, Paul Rubin wrote: > "Alex McDonald" <blog@rivadpm.com> writes: >> OK, so we now have a separate control stack or somesuch.... This stack >> (or whatever) is only used during compilation. This may take up >> several 10s to 100s of bytes in stack and dictionary space. In memory >> constrained systems, this may be very costly to implement. (Even in a >> big fat system like Win32Forth, I think you'd meet resistance to >> adding unneeded words.) Can you justify this additional compilation >> time cost? > > I'd say there are pros and cons: > > * The separate control stack gives the compiler more flexibility to use > the data stack during compilation, e.g. for on-the-fly peephole > optimization. > > * OTOH on a memory constrained host, you probably want the simplest > possible compiler, which won't have much use for that flexibility. So > it can use the data stack. The Forth standard word set was to some > extent designed for that minimalistic compiler implementation. > > * The control stack will normally need just one cell for each level of > nested IF's/loops/etc permissible. So tens rather than 100s of bytes of > stack space is probably enough in a memory constrained system that won't > have very deeply nested words (sign of poor factoring anyway). Such a > system is likely to be an MCU, where dictionary space (flash) is less > precious than ram, so ram consumption is the main issue. > > * These days for memory constrained targets, cross-compilation will > usually make more sense than a resident interpreter. So compile time > resources will be plentiful. In a big system, the separate control > stack (or even a combination of locals and recursion) means there's less > to bother your head about in the compiler implementation. > A reasonable list, and a good summary of the reasons why the Forth94 TC wanted to *enable* implementers to have a separate control flow stack without requiring it. Basically, it's not possible to write portable application code that manipulates the various control flow parameters, not just because you don't know where they are, but more particularly that you don't know *what* they are, how big they are, or anything else about them. To constrain all these components would place an unacceptable burden on implementers. The best we can do is post warnings, in the form of origs and dests, that cautions people attempting to write portable applications that they cannot use the data stack freely during compilation inside control flow structures. Fortunately, there are extremely few situations in normal application programming when one needs or wishes to do that. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-07-05 15:47 -0700 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <87wpyenrvv.fsf@nightsong.com> |
| In reply to | #40329 |
"Elizabeth D. Rather" <erather@forth.com> writes: > that cautions people attempting to write portable > applications that they cannot use the data stack freely during > compilation inside control flow structures. Certainly in ... IF ... x ... y ... THEN ... the THEN better see the same stuff on the stack that the IF left there. Does the standard go further, and say x...y can't use the stack at all, even if it's cleaned up by the time of THEN ?
[toc] | [prev] | [next] | [standalone]
Page 13 of 26 — ← Prev page 1 … 11 12 [13] 14 15 … 26 Next page →
Back to top | Article view | comp.lang.forth
csiph-web