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 6 of 26 — ← Prev page 1 … 4 5 [6] 7 8 … 26 Next page →
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-06-24 14:46 +0200 |
| Message-ID | <mme8oj$p33$1@dont-email.me> |
| In reply to | #40010 |
Anton Ertl wrote: > Bernd Paysan <bernd.paysan@gmx.de> writes: >>Stephen Pelc wrote: >>>>On the other hand, the restrictions we have for a standard program now >>>>make both your system and Gforth standard; without adding restrictions >>>>like "you can't tike S"", Gforth would be standard, VFX wouldn't. >>> >>> Where do we actually say that you can't tick S" ? >> >>I can't find it... TO, IS, and ACTION-OF all contain the necessary >>ambiguous conditions, and I'm pretty sure we discussed and voted to add >>that wording to S" and S\", too. > > Yes, I also have this memory. However, I don't find any trace of it > in my notes nor in the minutes. Maybe we have said so often that it > needs to be done that, at some point we though we had done it:-). Could be possible. We should put it on the agenda of the next meeting. I don't think a consensus will emerge that early, so we need it as a stop-gap until the consensus emerged. >>While one of the RFIs clarified that you can't tick compile-only words, we >>have not written that into the document, either. It's still implicit, and >>that's not a good idea. > > It's already in Forth-94, but not in the place where I (or apparently > you) normally look: > > |4.1.2 Ambiguous conditions > | > |attempting to obtain the execution token, (e.g., with 6.1.0070 ', > |6.1.1550 FIND, etc. of a definition with undefined interpretation > |semantics; Should be at least mentioned in FIND and ', too. Maybe, similar to IS, TO, and ACTION-OF, in each word without interpretation semantics. >>No, that's the wrong hook. The recognizer stack completely replaces the >>outer interpreter, it's not just for undefined stuff. > > That's certainly one way to do it (more powerful and conceptually > simpler, no special case for the search order search), but I guess > there will be some discussions of whether we want this or less > powerful (and therefore more conservative) approach of just having the > recognizer stack replace the undefined-word stuff. To implement things like a dot-parser hook which is done first (before doing the normal search), as the hook in VFX does it now, this is necessary. -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2015-06-24 13:03 +0000 |
| Message-ID | <558aa012.508980796@news.eternal-september.org> |
| In reply to | #40010 |
On Wed, 24 Jun 2015 08:04:49 GMT, anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: >It's already in Forth-94, but not in the place where I (or apparently >you) normally look: > >|4.1.2 Ambiguous conditions >| >|attempting to obtain the execution token, (e.g., with 6.1.0070 ', >|6.1.1550 FIND, etc. of a definition with undefined interpretation >|semantics; Thanks for that. However, that's just another post-it note to add and to reduce clarity in the document. And, of course, S" in the file word set, 11.6.1.2165, does have interpretation semantics. At least for desktop systems, S" is tickable. That's another roadmap objective - increase clarity. >That's certainly one way to do it (more powerful and conceptually >simpler, no special case for the search order search), but I guess >there will be some discussions of whether we want this or less >powerful (and therefore more conservative) approach of just having the >recognizer stack replace the undefined-word stuff. What we should also consider is the migration path. The most probable route that I see is: 1) Add recognisers to the UNDEFINED hook(s). Retest major apps. 2) Replace interpreter as a whole. Retest major apps. For example, if recognisers break the CCS app, then adoption will take a very long time. If/when Bernd delivers a recogniser for VFX, I will certainly test it hard. If it's done before EuroForth 2015, Willem will be able to comment. We can then also look at recognisers for Willem's dot parser - see VFX's Lib/oop/ClassVFX directory. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-06-24 15:05 +0100 |
| Message-ID | <mmedc5$b75$1@dont-email.me> |
| In reply to | #40018 |
on 24/06/2015 14:03:33, wrote:
> On Wed, 24 Jun 2015 08:04:49 GMT, anton@mips.complang.tuwien.ac.at
> (Anton Ertl) wrote:
>
>>It's already in Forth-94, but not in the place where I (or apparently
>>you) normally look:
>>
>>|4.1.2 Ambiguous conditions
>>|
>>|attempting to obtain the execution token, (e.g., with 6.1.0070 ',
>>|6.1.1550 FIND, etc. of a definition with undefined interpretation
>>|semantics;
>
> Thanks for that. However, that's just another post-it note to add
> and to reduce clarity in the document. And, of course, S" in the file
> word set, 11.6.1.2165, does have interpretation semantics. At least
> for desktop systems, S" is tickable.
>
> That's another roadmap objective - increase clarity.
>
+1
>>That's certainly one way to do it (more powerful and conceptually
>>simpler, no special case for the search order search), but I guess
>>there will be some discussions of whether we want this or less
>>powerful (and therefore more conservative) approach of just having the
>>recognizer stack replace the undefined-word stuff.
>
> What we should also consider is the migration path. The most
> probable route that I see is:
> 1) Add recognisers to the UNDEFINED hook(s). Retest major apps.
> 2) Replace interpreter as a whole. Retest major apps.
This is how I am doing it. (1) is split into 2 steps
1a. Support numbers thorugh recognisers
1b. Add support for Windows calls
>
> For example, if recognisers break the CCS app, then adoption
> will take a very long time. If/when Bernd delivers a recogniser
> for VFX, I will certainly test it hard. If it's done before
> EuroForth 2015, Willem will be able to comment. We can then
> also look at recognisers for Willem's dot parser - see VFX's
> Lib/oop/ClassVFX directory.
It would be helpful to publish some guidelines (I hesitate to use a
stronger word) as to what special characteristics these recognisers might
commonly use.
There's " for strings; we've already formalised ' # $ and %.
There seems to be some standard use of dotted notation a.b for objects
and there are others; a:b a::b and so on. What of longer sequences such
as a.b.c? The possibility of indexed notations such as a[b] a(b) a<b>
a{b} ? Any others?
On an experimental object system based on Ian Piumarta's work I have used
object ::method for late binding (this doesn't require a recogniser) and
would like to use an object::method syntax (early bound, which does need
a recogniser).
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2015-06-24 14:32 +0000 |
| Message-ID | <558abe5e.516736510@news.eternal-september.org> |
| In reply to | #40019 |
On Wed, 24 Jun 2015 15:05:12 +0100, "Alex McDonald" <blog@rivadpm.com> wrote: >There seems to be some standard use of dotted notation a.b for objects >and there are others; a:b a::b and so on. What of longer sequences such >as a.b.c? a.b.c.d is supported by ClassVFX and the last item may be a method. The code is not pretty ... Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-06-24 14:20 +0000 |
| Message-ID | <2015Jun24.162030@mips.complang.tuwien.ac.at> |
| In reply to | #40019 |
"Alex McDonald" <blog@rivadpm.com> writes:
>It would be helpful to publish some guidelines (I hesitate to use a
>stronger word) as to what special characteristics these recognisers might
>commonly use.
Anything where you are otherwise tempted to use a (state-smart or
interpret/compile: or somesuch) parsing word.
>There's " for strings; we've already formalised ' # $ and %.
>
>There seems to be some standard use of dotted notation a.b for objects
>and there are others; a:b a::b and so on. What of longer sequences such
>as a.b.c? The possibility of indexed notations such as a[b] a(b) a<b>
>a{b} ? Any others?
->NAME to replace TO and IS. I also gave some examples in my PAF
paper
<http://www.complang.tuwien.ac.at/anton/euroforth/ef13/papers/ertl-paf.pdf>:
abi:xx- printmax \ a version of : that includes stack effect information
abi.printf.xxxx- \ a call that includes stack effect information
abi'name \ a token for an ABI function
abi-exec.xxxx- \ a call of an ABI function token
'name:tag \ tagged xt
exec.tag \ call the xt on TOS, which must have the same tag
jump.tag \ tail-call the xt on TOS, which must have the same tag
L:name \ label
goto:name \ jump
'name/tag \ address of label name
goto/tag \ indirect jump to TOS label (which must have the same tag)
Maybe I went a little overboard when I thought these up, but you should
get an idea what they could be used for.
Concerning indexed notation: One often wants the result of some
expression as index (maybe also as a base); also, I don't see that
this is a place where recognizers provide anything that's hard in
classical Forth (and where I would be tempted to use a parsing word),
so I would not use recognizers for that.
Concerning a.b.c: In principle that's possible, but one has to draw a
line at some point. I would not try to cover the C expression
a[3*b->c].d[e*f].g in one recognized thing. It the lane before or
after a.b.c? I think it could be on either line.
- 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 | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-06-24 20:04 +0200 |
| Message-ID | <mmerc0$58h$1@dont-email.me> |
| In reply to | #40019 |
Alex McDonald wrote:
> There's " for strings; we've already formalised ' # $ and %.
>
> There seems to be some standard use of dotted notation a.b for objects
> and there are others; a:b a::b and so on. What of longer sequences such
> as a.b.c? The possibility of indexed notations such as a[b] a(b) a<b>
> a{b} ? Any others?
I've a scope recognizer, <voc>:<word>, i.e. word is search-wordlist in voc.
Typical use
a) forth:someword if the current scope hides the Forth word
b) appvoc:appword if in the normal Forth context.
Matthias Trute also has a hook in HEADER, so that : appvoc:appword will
define appword in appvoc.
Mini-OOF2 has a very simple dot-parser, which converts
.method -> >o method o>
can also be used for an istance variable, e.g.
( object ) .parent @ .next @ .dosomething
Then we have the ->name replacement for TO name and IS name.
There's also some stuff to use Forth as Unix scripting language, where just
any unknown word will be executed as shell command. This has no particular
syntax.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-06-24 16:08 +0200 |
| Message-ID | <mmediu$c5t$1@dont-email.me> |
| In reply to | #40009 |
Bernd Paysan wrote:
>> Any volunteers to contribute one for VFX ? One could use the
>> CUNDEFINED hook that is not documented ...
Ok, here's a recognizer implementation for VFX, using the typical internals
of VFX for the standard interpreter. Postpone mode is almost for free.
Line Gforth, you can now use >R and R> (matched within a line) in the text
interpreter, something that doesn't work in VFX with the normal text
interpreter.
Recognizers for other things like real string literals and TO replacement
will follow.
----------------------recognizer.fth----------------------
\ recognizer for VFX
\ postpone mode
: ]] -2 state ! ; immediate
: [[ ; immediate comp: drop -1 state ! discard-sinline ;
\ word recognizer
: recognizer: ( xtint xtcomp xtpost "name" -- )
Create rot , swap , , ;
' undefined dup dup recognizer: r:fail
: post, ( xt -- ) clit, postpone compile, ;
' execute ' compile, ' post, recognizer: r:word
' execute ' execute ' compile, recognizer: r:immediate
: rec:word ( addr u -- xt r:word | r:fail )
\ Searches a word in the wordlist stack
here place here find dup 0= IF 2drop r:fail
ELSE 0< IF r:word ELSE r:immediate THEN THEN ;
\ num recognizer
: xlit, ( x1 .. xn n -- ) dup 0< IF c#fliteral ELSE c#literal THEN ;
' drop ' xlit, :noname dup >r xlit, r> clit, postpone xlit, ;
recognizer: r:num
: rec:num ( addr u -- n 1 r:num | d 2 r:num | r: -2 r:num | r:fail )
pad place pad donumber? dup IF r:num ELSE drop r:fail THEN ;
\ generic stack get/set
$10 Constant max-stack#
: get-stack ( rec-addr -- xt1 .. xtn n )
dup @ 0= IF @ EXIT THEN
dup swap @ dup >r cells bounds 1 cells - swap DO
I @
cell negate +LOOP r> ;
: set-stack ( xt1 .. xtn n rec-addr -- )
over max-stack# u>= abort" Too many items"
2dup ! cell+ swap cells bounds ?DO
I !
cell +LOOP ;
\ recognizer stack
max-stack# 1+ cells buffer: forth-recognizer
: get-recognizers ( -- xt1 .. xtn n )
\ push the content on the recognizer stack
forth-recognizer get-stack ;
: set-recognizers ( xt1 .. xtn n )
\ set the recognizer stack from content on the stack
forth-recognizer set-stack ;
' rec:num ' rec:word 2 set-recognizers
\ recognizer loop
: map-recognizer ( addr u rec-addr -- tokens table )
\ apply a recognizer stack to a string, delivering a token
dup cell+ swap @ cells bounds ?DO
2dup I -rot 2>r
@ execute dup r:fail <> IF
2r> 2drop UNLOOP EXIT
THEN drop 2r>
cell +LOOP
2drop r:fail ;
: do-recognizer ( addr u -- tokens xt )
\ process the string @var{addr u} in the recognizer stack
forth-recognizer map-recognizer ;
\ toplevel
: parser ( addr u -- .. xt )
do-recognizer state @ negate cells + @ ;
: (interpret)
BEGIN ?stack parse-name dup
WHILE parser execute
REPEAT 2drop ;
' (interpret) is interpret
----------------------recognizer.fth----------------------
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-06-26 08:07 +0100 |
| Message-ID | <mmitlk$j1c$1@dont-email.me> |
| In reply to | #40021 |
on 24/06/2015 15:08:47, Bernd Paysan wrote:
> Bernd Paysan wrote:
>>> Any volunteers to contribute one for VFX ? One could use the
>>> CUNDEFINED hook that is not documented ...
>
> Ok, here's a recognizer implementation for VFX, using the typical
> internals of VFX for the standard interpreter. Postpone mode is almost
> for free. Line Gforth, you can now use >R and R> (matched within a
> line) in the text interpreter, something that doesn't work in VFX with
> the normal text interpreter.
>
> Recognizers for other things like real string literals and TO
> replacement will follow.
>
> ----------------------recognizer.fth----------------------
> \ recognizer for VFX
>
> \ postpone mode
>
>: ]] -2 state ! ; immediate
>: [[ ; immediate comp: drop -1 state ! discard-sinline ;
>
> \ word recognizer
>
>: recognizer: ( xtint xtcomp xtpost "name" -- )
> Create rot , swap , , ;
>
> ' undefined dup dup recognizer: r:fail
>
>: post, ( xt -- ) clit, postpone compile, ;
>
> ' execute ' compile, ' post, recognizer: r:word
> ' execute ' execute ' compile, recognizer: r:immediate
>
>: rec:word ( addr u -- xt r:word | r:fail )
> \ Searches a word in the wordlist stack
> here place here find dup 0= IF 2drop r:fail
> ELSE 0< IF r:word ELSE r:immediate THEN THEN ;
>
> \ num recognizer
>
>: xlit, ( x1 .. xn n -- ) dup 0< IF c#fliteral ELSE c#literal THEN ;
>
> ' drop ' xlit, :noname dup >r xlit, r> clit, postpone xlit, ;
> recognizer: r:num
>
>: rec:num ( addr u -- n 1 r:num | d 2 r:num | r: -2 r:num | r:fail )
> pad place pad donumber? dup IF r:num ELSE drop r:fail THEN ;
>
> \ generic stack get/set
>
> $10 Constant max-stack#
>
>: get-stack ( rec-addr -- xt1 .. xtn n )
> dup @ 0= IF @ EXIT THEN
> dup swap @ dup >r cells bounds 1 cells - swap DO
> I @
> cell negate +LOOP r> ;
>
>: set-stack ( xt1 .. xtn n rec-addr -- )
> over max-stack# u>= abort" Too many items"
> 2dup ! cell+ swap cells bounds ?DO
> I !
> cell +LOOP ;
>
> \ recognizer stack
>
> max-stack# 1+ cells buffer: forth-recognizer
>
>: get-recognizers ( -- xt1 .. xtn n )
> \ push the content on the recognizer stack
> forth-recognizer get-stack ;
>: set-recognizers ( xt1 .. xtn n )
> \ set the recognizer stack from content on the stack
> forth-recognizer set-stack ;
>
> ' rec:num ' rec:word 2 set-recognizers
>
> \ recognizer loop
>
>: map-recognizer ( addr u rec-addr -- tokens table )
> \ apply a recognizer stack to a string, delivering a token
> dup cell+ swap @ cells bounds ?DO
> 2dup I -rot 2>r
> @ execute dup r:fail <> IF
> 2r> 2drop UNLOOP EXIT
> THEN drop 2r>
> cell +LOOP
> 2drop r:fail ;
>
>: do-recognizer ( addr u -- tokens xt )
> \ process the string @var{addr u} in the recognizer stack
> forth-recognizer map-recognizer ;
>
> \ toplevel
>
>: parser ( addr u -- .. xt )
> do-recognizer state @ negate cells + @ ;
>
>: (interpret)
> BEGIN ?stack parse-name dup
> WHILE parser execute
> REPEAT 2drop ;
>
> ' (interpret) is interpret
> ----------------------recognizer.fth----------------------
>
This is really cool. A couple of implementation questions for you or
Stephen;
DISCARD-SINLINE I presume this is to provoke the "inline generator" to
disgorge its work without having seen any code to generate? I have a
similiar SYNC-CODE word.
CLIT, is : clit, literal postpone literal ; immediate
I presume you're happy to share this under some kind of copyleft?
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2015-06-26 08:55 +0000 |
| Message-ID | <558d1278.669338560@news.eternal-september.org> |
| In reply to | #40059 |
On Fri, 26 Jun 2015 08:07:50 +0100, "Alex McDonald" <blog@rivadpm.com> wrote: >This is really cool. A couple of implementation questions for you or >Stephen; > >DISCARD-SINLINE I presume this is to provoke the "inline generator" to >disgorge its work without having seen any code to generate? I have a >similiar SYNC-CODE word. DISCARD-SINLINE discards the current token stream so that the word being compiled cannot be tokenised. >CLIT, is : clit, literal postpone literal ; immediate CLIT, ( x -- ) just compiles a literal - it's the non-immediate primitive for LITERAL. >I presume you're happy to share this under some kind of copyleft? It's Bernd's code, so it is his decision. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-06-27 00:56 +0200 |
| Message-ID | <mmkl7q$72j$1@dont-email.me> |
| In reply to | #40059 |
Alex McDonald wrote: > This is really cool. A couple of implementation questions for you or > Stephen; > > DISCARD-SINLINE I presume this is to provoke the "inline generator" to > disgorge its work without having seen any code to generate? When I tested that thing it turned out that the inliner didn't quite understand what I'm doing, so I told the inliner that I'm right and he's wrong. > I have a similiar SYNC-CODE word. Whether you need to tell your optimizer something or it just works is up to some experiments. > CLIT, is : clit, literal postpone literal ; immediate Not immediate. > I presume you're happy to share this under some kind of copyleft? It's for VFX, and may serve as inspiration for everybody else, so it's under a non-copyleft liberal license. -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-06-26 18:06 +0100 |
| Message-ID | <mmk0o1$j8p$1@dont-email.me> |
| In reply to | #40021 |
on 24/06/2015 15:08:47, Bernd Paysan wrote:
> Bernd Paysan wrote:
>>> Any volunteers to contribute one for VFX ? One could use the
>>> CUNDEFINED hook that is not documented ...
>
> Ok, here's a recognizer implementation for VFX, using the typical
> internals of VFX for the standard interpreter. Postpone mode is almost
> for free. Line Gforth, you can now use >R and R> (matched within a
> line) in the text interpreter, something that doesn't work in VFX with
> the normal text interpreter.
>
> Recognizers for other things like real string literals and TO
> replacement will follow.
>
> ----------------------recognizer.fth----------------------
> \ recognizer for VFX
>
> \ postpone mode
>
>: ]] -2 state ! ; immediate
>: [[ ; immediate comp: drop -1 state ! discard-sinline ;
>
> \ word recognizer
>
>: recognizer: ( xtint xtcomp xtpost "name" -- )
> Create rot , swap , , ;
>
> ' undefined dup dup recognizer: r:fail
>
>: post, ( xt -- ) clit, postpone compile, ;
>
> ' execute ' compile, ' post, recognizer: r:word
> ' execute ' execute ' compile, recognizer: r:immediate
>
>: rec:word ( addr u -- xt r:word | r:fail )
> \ Searches a word in the wordlist stack
> here place here find dup 0= IF 2drop r:fail
> ELSE 0< IF r:word ELSE r:immediate THEN THEN ;
>
> \ num recognizer
>
>: xlit, ( x1 .. xn n -- ) dup 0< IF c#fliteral ELSE c#literal THEN ;
>
> ' drop ' xlit, :noname dup >r xlit, r> clit, postpone xlit, ;
> recognizer: r:num
>
>: rec:num ( addr u -- n 1 r:num | d 2 r:num | r: -2 r:num | r:fail )
> pad place pad donumber? dup IF r:num ELSE drop r:fail THEN ;
>
> \ generic stack get/set
>
> $10 Constant max-stack#
>
>: get-stack ( rec-addr -- xt1 .. xtn n )
> dup @ 0= IF @ EXIT THEN
> dup swap @ dup >r cells bounds 1 cells - swap DO
> I @
> cell negate +LOOP r> ;
>
>: set-stack ( xt1 .. xtn n rec-addr -- )
> over max-stack# u>= abort" Too many items"
> 2dup ! cell+ swap cells bounds ?DO
> I !
> cell +LOOP ;
>
> \ recognizer stack
>
> max-stack# 1+ cells buffer: forth-recognizer
>
>: get-recognizers ( -- xt1 .. xtn n )
> \ push the content on the recognizer stack
> forth-recognizer get-stack ;
>: set-recognizers ( xt1 .. xtn n )
> \ set the recognizer stack from content on the stack
> forth-recognizer set-stack ;
>
> ' rec:num ' rec:word 2 set-recognizers
>
> \ recognizer loop
>
>: map-recognizer ( addr u rec-addr -- tokens table )
> \ apply a recognizer stack to a string, delivering a token
> dup cell+ swap @ cells bounds ?DO
> 2dup I -rot 2>r
> @ execute dup r:fail <> IF
> 2r> 2drop UNLOOP EXIT
> THEN drop 2r>
> cell +LOOP
> 2drop r:fail ;
>
>: do-recognizer ( addr u -- tokens xt )
> \ process the string @var{addr u} in the recognizer stack
> forth-recognizer map-recognizer ;
>
> \ toplevel
>
>: parser ( addr u -- .. xt )
> do-recognizer state @ negate cells + @ ;
>
>: (interpret)
> BEGIN ?stack parse-name dup
> WHILE parser execute
> REPEAT 2drop ;
>
> ' (interpret) is interpret
> ----------------------recognizer.fth----------------------
>
For smart-compile and avoiding FIND and immediacy we can have with
FIND-NAME (ala gforth);
:noname name>interpret execute ;
:noname name>compile execute ;
:noname name>compile swap postpone literal compile, ;
recognizer: r:word
: rec:word ( addr u -- xt r:word | r:fail )
find-name ?dup if r:word else r:fail then ;
This removes R:IMMEDIATE. I've now got this working for parts of my
compiler. It really is quite simple and effective; I'm going to extend it
to the whole compiler this weekend. My only concern is the unbalanced
stack returns; <n items> R:something vs R:FAIL. qv REC:WORD.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-06-27 01:00 +0200 |
| Message-ID | <mmklf2$7rf$1@dont-email.me> |
| In reply to | #40074 |
Alex McDonald wrote: > This removes R:IMMEDIATE. I've now got this working for parts of my > compiler. It really is quite simple and effective; I'm going to extend it > to the whole compiler this weekend. My only concern is the unbalanced > stack returns; <n items> R:something vs R:FAIL. qv REC:WORD. It's just that each recognizer parses its data, and the amount of stack used to keep that is vastly different. A floating point number will reside on the FP stack, a word is an xt, a double number is two cells, and so on. -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-06-27 11:07 +0100 |
| Message-ID | <mmlshj$f9m$1@dont-email.me> |
| In reply to | #40080 |
on 27/06/2015, Bernd Paysan wrote: > Alex McDonald wrote: >> This removes R:IMMEDIATE. I've now got this working for parts of my >> compiler. It really is quite simple and effective; I'm going to extend it >> to the whole compiler this weekend. My only concern is the unbalanced >> stack returns; <n items> R:something vs R:FAIL. qv REC:WORD. > > It's just that each recognizer parses its data, and the amount of > stack used to keep that is vastly different. A floating point number > will reside on the FP stack, a word is an xt, a double number is two > cells, and so on. > I was thinking of a return of ( -- a b r:something ) where a b could be a double (r:double), a single (r:number does a D>S), a size (single, double, 10 bytes etc with r:fshort r:float r:10byte) & pointer to a float in a buffer and so on. My optimiser cries a bit and gives up every time it sees an EXECUTE or a word with variable stack effects.
[toc] | [prev] | [next] | [standalone]
| From | Matthias Trute <matthias.trute@gmail.com> |
|---|---|
| Date | 2015-06-27 12:04 -0700 |
| Message-ID | <3ca7f52c-f821-4cac-9438-f7f19ba7175b@googlegroups.com> |
| In reply to | #40085 |
Am Samstag, 27. Juni 2015 12:07:02 UTC+2 schrieb Alex McDonald: > on 27/06/2015, Bernd Paysan wrote: > > Alex McDonald wrote: > >> This removes R:IMMEDIATE. I've now got this working for parts of my > >> compiler. It really is quite simple and effective; I'm going to extend it > >> to the whole compiler this weekend. My only concern is the unbalanced > >> stack returns; <n items> R:something vs R:FAIL. qv REC:WORD. > > > > It's just that each recognizer parses its data, and the amount of > > stack used to keep that is vastly different. A floating point number > > will reside on the FP stack, a word is an xt, a double number is two > > cells, and so on. > > > > I was thinking of a return of ( -- a b r:something ) where a b could be a > double (r:double), a single (r:number does a D>S), a size (single, > double, 10 bytes etc with r:fshort r:float r:10byte) & pointer to a float > in a buffer and so on. My optimiser cries a bit and gives up every time > it sees an EXECUTE or a word with variable stack effects. It could check the XT beeing executed (the R:* action). Most of them have a well defined and constant stack effect. Placing the results in a (maybe dynamically allocated or thread local) buffer is not what I'd recommend as part of the standard.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-06-27 21:14 +0200 |
| Message-ID | <mmmskr$4hc$2@dont-email.me> |
| In reply to | #40092 |
Matthias Trute wrote: > Am Samstag, 27. Juni 2015 12:07:02 UTC+2 schrieb Alex McDonald: >> on 27/06/2015, Bernd Paysan wrote: >> > Alex McDonald wrote: >> >> This removes R:IMMEDIATE. I've now got this working for parts of my >> >> compiler. It really is quite simple and effective; I'm going to extend >> >> it to the whole compiler this weekend. My only concern is the >> >> unbalanced stack returns; <n items> R:something vs R:FAIL. qv >> >> REC:WORD. >> > >> > It's just that each recognizer parses its data, and the amount of >> > stack used to keep that is vastly different. A floating point number >> > will reside on the FP stack, a word is an xt, a double number is two >> > cells, and so on. >> > >> >> I was thinking of a return of ( -- a b r:something ) where a b could be a >> double (r:double), a single (r:number does a D>S), a size (single, >> double, 10 bytes etc with r:fshort r:float r:10byte) & pointer to a float >> in a buffer and so on. My optimiser cries a bit and gives up every time >> it sees an EXECUTE or a word with variable stack effects. > > It could check the XT beeing executed (the R:* action). Most of them have > a well defined and constant stack effect. Placing the results in a (maybe > dynamically allocated or thread local) buffer is not what I'd recommend as > part of the standard. There are two places where EXECUTE happens with a variable stack effect in my recognizer implementation: MAP-RECOGNIZER, where you walk trough the recognizer stack, and call words with ( addr u -- something r:success | r:fail ), which is variable, and INTERPRET itself, where you execute the R:* action. In interpreter mode, this actually just executes the xt given, so there's another EXECUTE with a variable stack effect. -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-06-20 16:26 +0000 |
| Message-ID | <2015Jun20.182607@mips.complang.tuwien.ac.at> |
| In reply to | #39856 |
Mark Wills <markwills1970@gmail.com> writes:
>On Friday, 19 June 2015 08:23:30 UTC+1, Alex McDonald wrote:
>The point is, ' doesn't know what I want to do with that XT. How
>dare it presume that I want to execute it, and that executing it
>in a particular state is illegal.
Ticking IF is non-standard. You cannot get an xt of IF with '.
Whether you want to execute it is irrelevant, and state is also
irrelevant. If you get an xt for the compilation semantics of IF in
Gforth, you can EXECUTE it, and STATE does not matter:
: foo [ comp' if drop execute ] ." hello" then ;
true foo \ prints "hello"
false foo \ prints nothing
SEE FOO shows:
: foo
IF .\" hello"
THEN ; ok
> Perhaps I don't want to execute
>it at all. Perhaps I want to do this, as I can in my system:
>
>' IF >LINK 10 DUMP
So this code is specific for your system anyway. In what way would
standardizing "' IF" help?
- 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-06-20 21:55 -0700 |
| Message-ID | <b054e81e-fff0-438c-b487-73b490925edd@googlegroups.com> |
| In reply to | #39892 |
On Saturday, June 20, 2015 at 9:34:56 AM UTC-7, Anton Ertl wrote: > Ticking IF is non-standard. You cannot get an xt of IF with '. > Whether you want to execute it is irrelevant, and state is also > irrelevant. My disambiguifiers refute Anton Ertl's assertion that ticking IF is non-standard. It is in fact possible to get an xt of IF with ' that can be given to EXECUTE (when STATE is set, otherwise you get an error-message) and that can be given to COMPILE, (presumably when meta-compiling an immediate word). Here the bug is fixed by a disambiguifier: : if state @ 0= abort" *** no interpretation semantics for: IF ***" postpone if ; immediate : my-if [ ' if ] literal execute ; immediate : ttt ( flag -- ) my-if ." true" else ." false" then ; 1 ttt true 0 ttt false Note that executing IF in interpretation mode results in IF aborting with an error-message: if *** no interpretation semantics for: IF *** -> if IF should abort in the programmer's face when it is used in interpretation mode --- the programmer has a bug and needs to be told. IF should not abort when used in compilation mode (inside of the TTT definition) --- this is, in fact, the context in which IF is supposed to be executed. This thread has run for over 200 posts now, and Anton Ertl has yet to say: "Thanks for explaining to me how it is possible to tick IF in standard ANS-Forth to obtain a valid xt. I'll put your disambiguifiers in my next gForth release." I've previously said that I feel like Sisyphus pushing the stone up the hill, only to have it roll back down again --- I have told you guys about the disambiguifiers dozens of times now, but you just continue playing dumb as if you just don't understand --- you are obviously hoping that I will eventually give up, and you will never have to face up to the fact that ANS-Forth was sabotaged to prevent the users from writing custom outer-interpreters. Once again, here is the sabotage: (4.1.2) Ambiguous Conditions: "attempting to obtain the execution token, (e.g., with 6.1.0070 ', 6.1.1550 FIND, etc.) of a definition with undefined interpretation semantics." Is there any way that I could make this more clear? If people can't see this, then that is purposeful blindness --- it is as clear as clear can be!
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-06-21 14:26 +0000 |
| Message-ID | <2015Jun21.162640@mips.complang.tuwien.ac.at> |
| In reply to | #39918 |
hughaguilar96@gmail.com writes:
>On Saturday, June 20, 2015 at 9:34:56 AM UTC-7, Anton Ertl wrote:
>> Ticking IF is non-standard. You cannot get an xt of IF with '.
>> Whether you want to execute it is irrelevant, and state is also
>> irrelevant. =20
>
>My disambiguifiers refute Anton Ertl's assertion that ticking IF is non-sta=
>ndard. It is in fact possible to get an xt of IF with ' that can be given t=
>o EXECUTE (when STATE is set, otherwise you get an error-message) and that =
>can be given to COMPILE, (presumably when meta-compiling an immediate word)=
>.
>
>Here the bug is fixed by a disambiguifier:=20
>
>: if state @ 0=3D abort" *** no interpretation semantics for: IF ***" pos=
>tpone if ; immediate=20
Ouch. A state-smart IF. Better read
<http://www.complang.tuwien.ac.at/papers/ertl98.ps.gz>.
A better implementation is:
: if postpone if ; immediate
This IF is not compile-only in any way, but that's certainly better
than a state-smart IF.
>Note that executing IF in interpretation mode results in IF aborting with a=
>n error-message:=20
>
>if *** no interpretation semantics for: IF ***=20
> -> if=20
>
>IF should abort in the programmer's face when it is used in interpretation =
>mode --- the programmer has a bug and needs to be told.=20
Performing the compilation semantics of IF in interpretation state is
not a bug. Typical example
: foo [ 5 gen-some-code 6 gen-more-code ] ;
where gen-some-code contains POSTPONE IF.
- 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 | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-06-22 00:29 +0100 |
| Message-ID | <mm7h9c$pl1$1@dont-email.me> |
| In reply to | #39933 |
on 21/06/2015 15:26:38, wrote: >>My disambiguifiers refute Anton Ertl's assertion that ticking IF is non-sta= >>ndard. It is in fact possible to get an xt of IF with ' that can be given t= >>o EXECUTE (when STATE is set, otherwise you get an error-message) and that = >>can be given to COMPILE, (presumably when meta-compiling an immediate word)= >>. >> >>Here the bug is fixed by a disambiguifier:=20 >> >>: if state @ 0=3D abort" *** no interpretation semantics for: IF ***" pos= >>tpone if ; immediate=20 > > Ouch. A state-smart IF. Better read > <http://www.complang.tuwien.ac.at/papers/ertl98.ps.gz>. > > A better implementation is: > >: if postpone if ; immediate > > This IF is not compile-only in any way, but that's certainly better > than a state-smart IF. Hugh claims not read other people's work. He was already advised by me to read your paper and use an immediate POSTPONE IF on 3 April; https://groups.google.com/forum/#! original/comp.lang.forth/oXXQAGDKP7w/JTzQ5b9luQ4J
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-06-22 03:24 +0200 |
| Message-ID | <mm7o13$a27$1@dont-email.me> |
| In reply to | #39933 |
Anton Ertl wrote: > Performing the compilation semantics of IF in interpretation state is > not a bug. Typical example > > : foo [ 5 gen-some-code 6 gen-more-code ] ; > > where gen-some-code contains POSTPONE IF. IMHO a bug in the Forth-94 standard, which ignored to warn about the then- common STATE-smart implementation of words like S". Let's assume that "gen- some-code" uses POSTPONE S", and S" is actually implemented STATE-smart (very likely in 1994): Then this will for sure not work. This sort of code was actually the start of Anton's complaints about STATE-smart. What if he had been warned? I told him something like "you can't do this, compilation has to happen in compilation state", but the standard didn't say that - it should have, because in typical 1994 implementation style, that's the case. Back at a time, when STATE-smart was the dominant way to implement words like S" or TO, it was obvious that interpretation and compilation were actually *states*. The Forth-94 standard said they were "semantics", and due to the rules, ' S" EXECUTE would always give the interpretation semantics (though the equivalence is stated as "when interpreting, ' FOO EXECUTE is equal to FOO" - so this means you EXECUTE in interpretation state), while POSTPONE S" would always give the compilation semantics. That's doable with dual-xt, it's also doable with smart COMPILE, (however, ' S" COMPILE, would then result in a spec-contradicting behavior), it's not doable with common 1994 practice (smart COMPILE, wasn't invented, and dual- xt was cmForth only). Therefore: if you find something in a standard that contradicts common practice, assume that it is a bug in the standard, because the purpose of the standard is to codify common practice. Standards have bugs, just like every code and documentation we write. A standard is usually not directly executable (with our reference implementations, we get a bit closer to that goal - but the reference implementation is not normative), so it didn't receive a good testing, either. All it did recieve was review, and if I look at the things that slowly turn up in Forth-2012, and was there since 1994, review is something that clearly doesn't work as well as a good beating of code in a test harness. -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
Page 6 of 26 — ← Prev page 1 … 4 5 [6] 7 8 … 26 Next page →
Back to top | Article view | comp.lang.forth
csiph-web