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-06-15 23:35 +0000 |
| Articles | 20 on this page of 325 — 39 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 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 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-23 10:30 +0000
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
Page 10 of 17 — ← Prev page 1 … 8 9 [10] 11 12 … 17 Next page →
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-06-14 16:48 -0700 |
| Message-ID | <66402122-7383-431b-b1b7-9d05c5bb43c7@googlegroups.com> |
| In reply to | #39751 |
On Sunday, June 14, 2015 at 4:20:31 PM UTC-7, Stephen Pelc wrote: > On Sun, 14 Jun 2015 15:21:11 -0700 (PDT), hughaguilar96@gmail.com > wrote: > > rant, rant, rant > > >What do you say Stephen Pelc? Can you make LITERAL a vectored word in your = > >next VFX release? Help the cross-compiler writers of the world --- and, how= > > about making LITERAL vectored in Forth-200x while you are at it. > > If you had made the slightest effort, e.g. by disassembling LITERAL > and what it contains, or by reading the manual, you would find that > LITERAL is already effectively DEFERred. So is NUMBER? > > Stephen I RTFM'd and found that NUMBER? is deferred. The manual says: defer NUMBER? \ addr -- d/n/- 2/1/0 I looked up LITERAL and found that it is not deferred. The manual says: : LITERAL \ Comp: x -- ; Run: -- x It doesn't actually matter anyway though because I want my cross-compiler to run under ANS-Forth --- even if you have deferred LITERAL in some more recent release of VFX, I still can't use it without suffering vendor lock-in. Will you make LITERAL deferred in Forth-200x? You are on the committee, so you theoretically have the authority to do so (more realistically, you have the authority to ask Leon Wagner for permission, and to do what he tells you to do). You supposedly know how to write a cross-compiler --- you should know all this stuff already --- why do I have to tell you what is necessary on comp.lang.forth?
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-06-14 17:52 -0700 |
| Message-ID | <a81c40c3-e6b0-4c34-8fda-e6d22ceb9afc@googlegroups.com> |
| In reply to | #39753 |
On Sunday, June 14, 2015 at 4:48:26 PM UTC-7, hughag...@gmail.com wrote: > On Sunday, June 14, 2015 at 4:20:31 PM UTC-7, Stephen Pelc wrote: > > On Sun, 14 Jun 2015 15:21:11 -0700 (PDT), hughaguilar96@gmail.com > > wrote: > > > > rant, rant, rant > > > > >What do you say Stephen Pelc? Can you make LITERAL a vectored word in your = > > >next VFX release? Help the cross-compiler writers of the world --- and, how= > > > about making LITERAL vectored in Forth-200x while you are at it. > > > > If you had made the slightest effort, e.g. by disassembling LITERAL > > and what it contains, or by reading the manual, you would find that > > LITERAL is already effectively DEFERred. So is NUMBER? > > > > Stephen > > I RTFM'd and found that NUMBER? is deferred. The manual says: > > defer NUMBER? \ addr -- d/n/- 2/1/0 > > I looked up LITERAL and found that it is not deferred. The manual says: > > : LITERAL \ Comp: x -- ; Run: -- x > > It doesn't actually matter anyway though because I want my cross-compiler to run under ANS-Forth --- even if you have deferred LITERAL in some more recent release of VFX, I still can't use it without suffering vendor lock-in. > > Will you make LITERAL deferred in Forth-200x? You are on the committee, so you theoretically have the authority to do so (more realistically, you have the authority to ask Leon Wagner for permission, and to do what he tells you to do). > > You supposedly know how to write a cross-compiler --- you should know all this stuff already --- why do I have to tell you what is necessary on comp.lang.forth? This ambiguity issue was originally discussed here: https://groups.google.com/forum/#!searchin/comp.lang.forth/LC53%7Csort:relevance/comp.lang.forth/wP5nw1ClzsM/E-TV9v2y9RoJ This thread is essential reading for anybody who is interested in disambiguification --- the problem was really laid out here --- it took me 6 years to figure out the solution however. Here is the last post of the thread: On Saturday, October 18, 2014 at 5:48:31 PM UTC-7, hughag...@yahoo.com wrote: > On Tuesday, December 8, 2009 3:18:13 PM UTC-7, Stephen Pelc wrote: > > On Tue, 8 Dec 2009 14:32:02 -0500, Jonah Thomas <jethomas5@gmail.com> > > wrote: > > >Suppose you extended the cross-compiler so that the TARGET could be the > > >HOST . Then you'd have a clear distinction between COMPILER words and > > >regular words, but the distinction between HOST and TARGET would have > > >disappeared. > > > > There are three types of compilation involved > > 1) Host compilation > > 2) Clone compilation (target CPU same as host and memory matches) > > 3) Cross compilation (target CPU is not host CPU) > > > > In the third case you have to simulate *everything* when dealing > > with both the definition and execution of defining words. It's not > > easy. You also have to extend the normal Forth compiler by at least > > two time frames. Forth cross compilers are much more complicated > > and much more subtle than they appear to be. > > This statement (#3) seems to indicate that Pelc's cross-compiler is simulating the target CPU on the host CPU. For example, for the ARM cross-compiler, Pelc would have written a simulator for the ARM processor, and his "cross-compiler" is actually a stand-alone ARM Forth running under the simulator. > > This explains why Pelc went for 30 years without fixing the bug in VFX that I discovered on my first week of using VFX to write a cross-compiler --- specifically, that colon words with local variables would put a LOCALVARS word-list on top of the search-order, getting in the way of any immediate words used in the colon word that expect the search-order to be the way that it is supposed to be. See this thread: > https://groups.google.com/forum/#!topic/comp.lang.forth/olO-VHXJa1Q%5B76-100-false%5D > In here, Pelc says, regarding fixing this bug: > On Thursday, October 9, 2014 6:52:18 PM UTC-7, Stephen Pelc wrote: > > What a waste of effort. Yours was the first request that included a > > usage case. However, since you just ranted, it had to wait until I got > > back from holiday and EuroForth. We have now done some testing on the > > fix, compiled and tested the big app with 1.1 million lines of source > > code, and rebuilt two cross compilers and four versions of VFX. > > > > Note that our cross compilers have been running for 30+ years and > > don't need your particular tricks. > > Pelc considers the use of word-lists in a cross-compiler to be a "trick." This implies that his own cross-compiler doesn't use word-lists at all. The only explanation I can see for this, is that Pelc's "cross-compiler" for the ARM is actually just a stand-alone ARM Forth system running under an ARM simulation. Most stand-alone Forth systems don't use word-lists at all (except possibly for the assembler), which would explain why Pelc has never previously felt inspired to fix the bug in VFX's word-list implementation. > > This is not the way that my cross-compiler works --- I don't simulate the target CPU on the host CPU at compile-time --- that is not necessary. I don't think Stephen Pelc knows how to write a cross-compiler. If he did, he would have discovered that bug in his word-list code. Also, he would have deferred LITERAL. Most likely, what Stephen Pelc's cross-compilers are doing is simulating the target-computer at compile-time and then running a traditional Forth system under simulation.
[toc] | [prev] | [next] | [standalone]
| From | Doug Hoffman <glidedog@gmail.com> |
|---|---|
| Date | 2015-06-14 21:13 -0400 |
| Message-ID | <557e26bc$0$304$14726298@news.sunsite.dk> |
| In reply to | #39753 |
On 6/14/15 7:48 PM, hughaguilar96@gmail.com wrote: > On Sunday, June 14, 2015 at 4:20:31 PM UTC-7, Stephen Pelc wrote: >> If you had made the slightest effort, e.g. by disassembling LITERAL >> and what it contains, or by reading the manual, you would find that >> LITERAL is already effectively DEFERred. > I looked up LITERAL and found that it is not deferred. The manual says: [snip] Hugh, Stephen also suggested disassembling LITERAL. Try it. -Doug
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-06-14 20:09 -0700 |
| Message-ID | <2950bacb-3718-4f51-b130-c0ce25ba8563@googlegroups.com> |
| In reply to | #39756 |
On Sunday, June 14, 2015 at 6:13:33 PM UTC-7, Doug Hoffman wrote: > On 6/14/15 7:48 PM, hughaguilar96@gmail.com wrote: > > On Sunday, June 14, 2015 at 4:20:31 PM UTC-7, Stephen Pelc wrote: > > >> If you had made the slightest effort, e.g. by disassembling LITERAL > >> and what it contains, or by reading the manual, you would find that > >> LITERAL is already effectively DEFERred. > > > I looked up LITERAL and found that it is not deferred. The manual says: [snip] > > Hugh, > > Stephen also suggested disassembling LITERAL. Try it. > > -Doug Okay, here it is: LITERAL (is IMMEDIATE) ( 00411474 E8F35DFFFF ) CALL 0040726C CLIT, ( 00411479 C3 ) NEXT, ( 6 bytes, 2 instructions ) ok ok see clit, CLIT, is DEFERred. Action is C_LIT C_LIT ( 0043B548 8D6DFC ) LEA EBP, [EBP+-04] ( 0043B54B 895D00 ) MOV [EBP], EBX ( 0043B54E E8BDB90000 ) CALL 00446F10 GENLITTOKEN ( 0043B553 8D6DFC ) LEA EBP, [EBP+-04] ( 0043B556 895D00 ) MOV [EBP], EBX ( 0043B559 BB05000000 ) MOV EBX, 00000005 ( 0043B55E E80969FFFF ) CALL 00431E6C OPT? ( 0043B563 85DB ) TEST EBX, EBX ( 0043B565 8B5D00 ) MOV EBX, [EBP] ( 0043B568 8D6D04 ) LEA EBP, [EBP+04] ( 0043B56B 7434 ) JZ/E 0043B5A1 ( 0043B56D 8D6DFC ) LEA EBP, [EBP+-04] ( 0043B570 895D00 ) MOV [EBP], EBX ( 0043B573 BB06000000 ) MOV EBX, 00000006 ( 0043B578 E89F61FFFF ) CALL 0043171C SEQID ( 0043B57D 8B5500 ) MOV EDX, [EBP] ( 0043B580 8913 ) MOV 0 [EBX], EDX ( 0043B582 8B5D04 ) MOV EBX, [EBP+04] ( 0043B585 8D6D08 ) LEA EBP, [EBP+08] ( 0043B588 E8BB61FFFF ) CALL 00431748 SEQFLAGS ( 0043B58D 8B1B ) MOV EBX, 0 [EBX] ( 0043B58F E80C62FFFF ) CALL 004317A0 SEQPREV ( 0043B594 8B5500 ) MOV EDX, [EBP] ( 0043B597 8913 ) MOV 0 [EBX], EDX ( 0043B599 8B5D04 ) MOV EBX, [EBP+04] ( 0043B59C 8D6D08 ) LEA EBP, [EBP+08] ( 0043B59F EB05 ) JMP 0043B5A6 ( 0043B5A1 E80668FFFF ) CALL 00431DAC RESET-OPT ( 0043B5A6 E80DBCFFFF ) CALL 004371B8 GETLITRES ( 0043B5AB 8BD3 ) MOV EDX, EBX ( 0043B5AD 8B4D00 ) MOV ECX, [EBP] ( 0043B5B0 894B08 ) MOV [EBX+08], ECX ( 0043B5B3 8BDA ) MOV EBX, EDX ( 0043B5B5 8D6D04 ) LEA EBP, [EBP+04] ( 0043B5B8 E8B3C5FFFF ) CALL 00437B70 PUSH(WS) ( 0043B5BD C3 ) NEXT, ( 118 bytes, 36 instructions ) ok ok locate clit, Definition found in /Kernel/Common/kernel.fth at line 724. ok Okay then --- CLIT, is deferred. These names are confusing to me. Traditionally in ITC systems, LIT pushed a word-literal and CLIT pushed a character-literal at run-time. I would think that CLIT, would compile a character-literal at compile-time. It seems to compile a word-literal at compile-time however. Anyway, I don't want to disassemble VFX. I did disassemble UR/Forth in the early 1990s, but that was different --- in those days, UR/Forth was the only professional Forth system available, so learning it was worthwhile to anybody wanting a job as a Forth programmer. It was a different world back then. Another good point, is that UR/Forth had settled and there weren't new versions coming out frequently --- VFX could change in the next version --- I don't want my cross-compiler to depend on carnal knowledge of VFX --- VFX could change then my cross-compiler will stop working, and everybody will say that I'm no good at programming and that I'm distributing non-working code (Stephen Pelc will say: "I don't have time to debug Hugh's programs for him! People should just buy MPE's cross-compiler!"). The solution is for the Forth-200x standard to say that LITERAL is vectored --- but that requires Leon Wagner's permission, and he won't give it.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-04-03 10:25 -0700 |
| Message-ID | <4ea0700e-ea27-4bbd-bff4-9f58695736fd@googlegroups.com> |
| In reply to | #37804 |
On Wednesday, April 1, 2015 at 4:26:52 AM UTC-7, Stephen Pelc wrote: > On Tue, 31 Mar 2015 15:13:12 -0700 (PDT), hughaguilar96@gmail.com > wrote: > > >: my-if [ ' if ] literal execute ; immediate ok > >: ttt ( flag -- ) my-if ." true " else ." false " then ;=20 > >Err# -14 ERR: Attempt to interpret a compile only definition. > > -> : ttt ( flag -- ) my-if ." true " else ." false " then ; > > ^ > >see my-if=20 > >MY-IF (is IMMEDIATE)=20 > >( 004C7A80 E89B23F4FF ) CALL 00409E20 IF > >( 004C7A85 C3 ) NEXT, > >( 6 bytes, 2 instructions ) > > ok > > It works fine. You compiled MY-IF to use the interpretation > behaviour of IF. VFX compiled the interpretation behaviour > of IF. You ran MY-IF and got the interpretation behaviour of > IF. What are you complaining about? Interpretation semantics are what a word does when STATE is 1 (interpreting). IF doesn't have any interpretation semantics (it can't be used in the REPL or inside of [ ] brackets), which is why the ANS-Forth document says that this is undefined. I ran MY-IF inside of a colon-word definition, so STATE was -1 (compiling). What I'm complaining about is that this should have worked. I should have gotten the compilations semantics for IF when I executed the xt of IF. I don't think that my "initial assumption" is wrong --- I think you are blowing smoke to cover up the bug in VFX. This is not just about writing SYNONYM --- this is about writing any meta-compiling word that generates an immediate word --- this has been a common practice for decades (I relied on this heavily in MFX), but now it doesn't work under VFX?
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-04-03 14:43 -0400 |
| Message-ID | <mfmmus$9uf$1@dont-email.me> |
| In reply to | #37887 |
On 4/3/2015 1:25 PM, hughaguilar96@gmail.com wrote: > On Wednesday, April 1, 2015 at 4:26:52 AM UTC-7, Stephen Pelc wrote: >> On Tue, 31 Mar 2015 15:13:12 -0700 (PDT), hughaguilar96@gmail.com >> wrote: >> >>> : my-if [ ' if ] literal execute ; immediate ok >>> : ttt ( flag -- ) my-if ." true " else ." false " then ;=20 >>> Err# -14 ERR: Attempt to interpret a compile only definition. >>> -> : ttt ( flag -- ) my-if ." true " else ." false " then ; >>> ^ >>> see my-if=20 >>> MY-IF (is IMMEDIATE)=20 >>> ( 004C7A80 E89B23F4FF ) CALL 00409E20 IF >>> ( 004C7A85 C3 ) NEXT, >>> ( 6 bytes, 2 instructions ) >>> ok >> >> It works fine. You compiled MY-IF to use the interpretation >> behaviour of IF. VFX compiled the interpretation behaviour >> of IF. You ran MY-IF and got the interpretation behaviour of >> IF. What are you complaining about? > > Interpretation semantics are what a word does when STATE is 1 (interpreting). IF doesn't have any interpretation semantics (it can't be used in the REPL or inside of [ ] brackets), which is why the ANS-Forth document says that this is undefined. From the Forth 2012 spec which I assume is substantially the same as the previous spec: 4.1.2 Ambiguous conditions A system shall document the system action taken upon each of the general or specific ambiguous conditions identified in this standard. See 3.4.4 Possible actions on an ambiguous condition. The following general ambiguous conditions could occur because of a combination of factors: ... – attempting to obtain the execution token, (e.g., with 6.1.0070 ’, 6.1.1550 FIND, etc. of a definition with undefined interpretation semantics; It sure looks to me like this is what you are doing. So I think it is YOU who are wrong here. And you had to receive the word from me... a lowly hack. > I ran MY-IF inside of a colon-word definition, so STATE was -1 (compiling). What I'm complaining about is that this should have worked. I should have gotten the compilations semantics for IF when I executed the xt of IF. What happens to State when you execute '['? I thought it changed the value of state??? > I don't think that my "initial assumption" is wrong --- I think you are blowing smoke to cover up the bug in VFX. > > This is not just about writing SYNONYM --- this is about writing any meta-compiling word that generates an immediate word --- this has been a common practice for decades (I relied on this heavily in MFX), but now it doesn't work under VFX? If this is a VFX problem, which Forths does your code work under? Gforth? Win32Forth? Swift Forth? -- Rick
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-04-03 20:14 +0100 |
| Message-ID | <mfmoop$gpo$1@dont-email.me> |
| In reply to | #37893 |
on 03/04/2015 19:43:32, rickman wrote:
> On 4/3/2015 1:25 PM, hughaguilar96@gmail.com wrote:
>> On Wednesday, April 1, 2015 at 4:26:52 AM UTC-7, Stephen Pelc wrote:
>>> On Tue, 31 Mar 2015 15:13:12 -0700 (PDT), hughaguilar96@gmail.com
>>> wrote:
>>>
>>>> : my-if [ ' if ] literal execute ; immediate ok
>>>> : ttt ( flag -- ) my-if ." true " else ." false " then ;
>>>> Err# -14 ERR: Attempt to interpret a compile only definition.
>>>> -> : ttt ( flag -- ) my-if ." true " else ." false " then ;
>>>> ^
>>>> see my-if
>>>> MY-IF (is IMMEDIATE)
>>>> ( 004C7A80 E89B23F4FF ) CALL 00409E20 IF
>>>> ( 004C7A85 C3 ) NEXT,
>>>> ( 6 bytes, 2 instructions )
>>>> ok
>>>
[snip]
>
> If this is a VFX problem, which Forths does your code work under?
> Gforth? Win32Forth? Swift Forth?
>
Gforth 0.7.9_20150221, Copyright (C) 1995-2014 Free Software Foundation,
Inc. Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `bye' to exit
: my-if [ ' if ] literal execute ; immediate
:1: error: Interpreting a compile-only word
: my-if [ ' >>>if<<< ] literal execute ; immediate
Backtrace:
$6FFFF80A598 throw
$6FFFF80ABE0 execute
$6FFFF80BA68 name?int
Win32Forth: a 32 Bit Forth for Windows 95/98/ME/NT4/W2K/XP/VISTA/W7 and
W8 Version: 6.15.03 Build: 1
: my-if [ ' if ] literal execute ; immediate ok
: x my-if 1+ . else 1 - then ; ok
7 1 x 8 ok
STC Experimental 32bit: 0.06.07 Build: 188
: my-if [ ' if ] literal execute ; immediate ok
: x my-if 1- else 1 + then ;
^^^^^
Error -14 my-if is compilation only in (console)
[toc] | [prev] | [next] | [standalone]
| From | jfong@ms4.hinet.net |
|---|---|
| Date | 2015-04-03 23:16 -0700 |
| Message-ID | <01b174af-ced9-4ca6-9192-3388c71eb0e9@googlegroups.com> |
| In reply to | #37893 |
rickman 4/4/2015 2:43AM wrote： > If this is a VFX problem, which Forths does your code work under? > Gforth? Win32Forth? Swift Forth? Everyone is doing this so how can it be wrong. I'd better to follow it. --Jach
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-04-03 20:02 +0100 |
| Message-ID | <mfmo1v$e4c$1@dont-email.me> |
| In reply to | #37887 |
on 03/04/2015 18:25:37, wrote: > On Wednesday, April 1, 2015 at 4:26:52 AM UTC-7, Stephen Pelc wrote: >> On Tue, 31 Mar 2015 15:13:12 -0700 (PDT), hughaguilar96@gmail.com >> wrote: >> >> >: my-if [ ' if ] literal execute ; immediate ok >> >: ttt ( flag -- ) my-if ." true " else ." false " then ;=20 >> >Err# -14 ERR: Attempt to interpret a compile only definition. >> > -> : ttt ( flag -- ) my-if ." true " else ." false " then ; >> > ^ >> >see my-if=20 >> >MY-IF (is IMMEDIATE)=20 >> >( 004C7A80 E89B23F4FF ) CALL 00409E20 IF >> >( 004C7A85 C3 ) NEXT, >> >( 6 bytes, 2 instructions ) >> > ok >> >> It works fine. You compiled MY-IF to use the interpretation >> behaviour of IF. VFX compiled the interpretation behaviour >> of IF. You ran MY-IF and got the interpretation behaviour of >> IF. What are you complaining about? > > Interpretation semantics are what a word does when STATE is 1 Zero. > (interpreting). IF doesn't have any interpretation semantics (it can't > be used in the REPL or inside of [ ] brackets), which is why the > ANS-Forth document says that this is undefined. > > I ran MY-IF inside of a colon-word definition, so STATE was -1 > (compiling). What I'm complaining about is that this should have > worked. I should have gotten the compilations semantics for IF when I > executed the xt of IF. Which xt you got from ' in interpret state, not compile state. If you'd said : my-if postpone if ; immediate then it would have worked just fine, since that's what POSTPONE is for; getting the compilation semantics. Read www.complang.tuwien.ac.at/anton/tmp/state.ps.gz for why state smartness is causing you problems. (By the way, as an ANS Forth expert, you should have realized this.)
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-04-03 20:46 +0000 |
| Message-ID | <2015Apr3.224609@mips.complang.tuwien.ac.at> |
| In reply to | #37887 |
hughaguilar96@gmail.com writes:
>On Wednesday, April 1, 2015 at 4:26:52 AM UTC-7, Stephen Pelc wrote:
>> On Tue, 31 Mar 2015 15:13:12 -0700 (PDT), hughaguilar96@gmail.com
>> wrote:
>>
>> >: my-if [ ' if ] literal execute ; immediate ok
>> >: ttt ( flag -- ) my-if ." true " else ." false " then ;=20
>> >Err# -14 ERR: Attempt to interpret a compile only definition.
>> > -> : ttt ( flag -- ) my-if ." true " else ." false " then ;
>> > ^
>> >see my-if=20
>> >MY-IF (is IMMEDIATE)=20
>> >( 004C7A80 E89B23F4FF ) CALL 00409E20 IF
>> >( 004C7A85 C3 ) NEXT,
>> >( 6 bytes, 2 instructions )
>> > ok
>>
>> It works fine. You compiled MY-IF to use the interpretation
>> behaviour of IF. VFX compiled the interpretation behaviour
>> of IF. You ran MY-IF and got the interpretation behaviour of
>> IF. What are you complaining about?
>
>Interpretation semantics are what a word does when STATE is 1 (interpreting).
|2.1 Definitions of terms
|
|interpretation semantics:
|
|The behavior of a Forth definition when its name is encountered *by the
|text interpreter* in interpretation state.
Emphasis mine.
>I ran MY-IF inside of a colon-word definition, so STATE was -1 (compiling). What I'm complaining about is that this should have worked. I should have gotten the compilations semantics for IF when I executed the xt of IF.
You ticked IF, so it was not the text interpreter that encountered
it's name, but '. So let's look up the definition of ':
|6.1.0070 ' tick CORE
|
|( "<spaces>name" -- xt )
|
|Skip leading space delimiters. Parse name delimited by a space. Find
|name and return xt, the execution token for name. An ambiguous
|condition exists if name is not found. *When interpreting, ' xyz
|EXECUTE is equivalent to xyz.*
Emphasis mine. I have an informal answer from a Forth-94 TC member
that the empasised sentence implies that a standard program cannot
tick words without interpretation semantics. So when you ' IF, the
system can do whatever it likes, e.g., report an error, give you the
xt of a word that produces an error on execution, give you the xt of a
word that represents the compilation semantics of IF, or something
else.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | krishna.myneni@ccreweb.org |
|---|---|
| Date | 2015-04-04 06:43 -0700 |
| Message-ID | <4c2b7860-7b0d-4d35-ad33-14b47ba99bb6@googlegroups.com> |
| In reply to | #37898 |
On Friday, April 3, 2015 at 3:58:49 PM UTC-5, Anton Ertl wrote: > hughaguilar96@gmail.com writes: > >On Wednesday, April 1, 2015 at 4:26:52 AM UTC-7, Stephen Pelc wrote: ... > >> > >> It works fine. You compiled MY-IF to use the interpretation > >> behaviour of IF. VFX compiled the interpretation behaviour > >> of IF. You ran MY-IF and got the interpretation behaviour of > >> IF. What are you complaining about? > > Stephen is certainly correct. As others have noted, interpretation semantics for "IF" are undefined in ANS Forth. The interpreter is allowed to do whatever it wants but can't claim it to be standard behavior. Just to muddy the waters a bit, I do allow "interpretation semantics" for IF and other flow control words in kForth (my Forth implementation), but it certainly isn't standard behavior per DPANS94. I chose to do this based on my personal preference of being able to write and to test fragments of Forth code at the interpreter, without having to defining a word. Another reason was to be able to respond to a code failure quickly, e.g. when a word that is collecting data crashes in the middle of execution, I find it handy to be able to dump the data to a file using a DO loop at the interpreter. Krishna
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2015-04-04 17:31 +0000 |
| Message-ID | <55201fdf$0$21278$e4fe514c@dreader37.news.xs4all.nl> |
| In reply to | #37926 |
In article <4c2b7860-7b0d-4d35-ad33-14b47ba99bb6@googlegroups.com>,
<krishna.myneni@ccreweb.org> wrote:
>On Friday, April 3, 2015 at 3:58:49 PM UTC-5, Anton Ertl wrote:
>> hughaguilar96@gmail.com writes:
>> >On Wednesday, April 1, 2015 at 4:26:52 AM UTC-7, Stephen Pelc wrote:
>...
>> >>
>> >> It works fine. You compiled MY-IF to use the interpretation
>> >> behaviour of IF. VFX compiled the interpretation behaviour
>> >> of IF. You ran MY-IF and got the interpretation behaviour of
>> >> IF. What are you complaining about?
>> >
>
>Stephen is certainly correct. As others have noted, interpretation semantics for "IF" are undefined in ANS Forth. The interpreter is
>allowed to do whatever it wants but can't claim it to be standard behavior.
>
>Just to muddy the waters a bit, I do allow "interpretation semantics" for IF and other flow control words in kForth (my Forth
>implementation), but it certainly isn't standard behavior per DPANS94. I chose to do this based on my personal preference of being able to
>write and to test fragments of Forth code at the interpreter, without having to defining a word. Another reason was to be able to respond
>to a code failure quickly, e.g. when a word that is collecting data crashes in the middle of execution, I find it handy to be able to dump
>the data to a file using a DO loop at the interpreter.
Same here. It turned out rather simple.
Testing with
10 0 DO I . I my-word . CR LOOP
has become second nature.
One of those things where you wondered how you went so
long without it.
I needed just FAR-DP SWAP-DP T] T[ apart from the redefined
IF's WHILE's and THEN's.
Having an alternative buffer to compile to
serves double duty in my class implementation.
>
>Krishna
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | krishna.myneni@ccreweb.org |
|---|---|
| Date | 2015-04-04 15:54 -0700 |
| Message-ID | <9fc642cd-83b7-4f4e-95d5-954edecd7081@googlegroups.com> |
| In reply to | #37935 |
On Saturday, April 4, 2015 at 12:31:12 PM UTC-5, Albert van der Horst wrote: > In article <4c2b7860-7b0d-4d35-ad33-14b47ba99bb6@googlegroups.com>, > <krishna.myneni@ccreweb.org> wrote: ... > >Just to muddy the waters a bit, I do allow "interpretation semantics" for IF and other flow control words in kForth (my Forth > >implementation), but it certainly isn't standard behavior per DPANS94. I chose to do this based on my personal preference of being able to > >write and to test fragments of Forth code at the interpreter, without having to defining a word. Another reason was to be able to respond > >to a code failure quickly, e.g. when a word that is collecting data crashes in the middle of execution, I find it handy to be able to dump > >the data to a file using a DO loop at the interpreter. > > Same here. It turned out rather simple. > Testing with > 10 0 DO I . I my-word . CR LOOP > has become second nature. > One of those things where you wondered how you went so > long without it. > Exactly! Krishna
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-04-04 21:01 -0700 |
| Message-ID | <333fb086-c1a1-4ba0-b1be-1d4ca8905b46@googlegroups.com> |
| In reply to | #37948 |
On Saturday, April 4, 2015 at 3:54:34 PM UTC-7, krishna...@ccreweb.org wrote: > On Saturday, April 4, 2015 at 12:31:12 PM UTC-5, Albert van der Horst wrote: > > In article <4c2b7860-7b0d-4d35-ad33-14b47ba99bb6@googlegroups.com>, > > <krishna.myneni@ccreweb.org> wrote: > ... > > >Just to muddy the waters a bit, I do allow "interpretation semantics" for IF and other flow control words in kForth (my Forth > > >implementation), but it certainly isn't standard behavior per DPANS94. I chose to do this based on my personal preference of being able to > > >write and to test fragments of Forth code at the interpreter, without having to defining a word. Another reason was to be able to respond > > >to a code failure quickly, e.g. when a word that is collecting data crashes in the middle of execution, I find it handy to be able to dump > > >the data to a file using a DO loop at the interpreter. > > > > Same here. It turned out rather simple. > > Testing with > > 10 0 DO I . I my-word . CR LOOP > > has become second nature. > > One of those things where you wondered how you went so > > long without it. > > > > Exactly! > > Krishna This is not what we are talking about at all. I never said that I wanted to execute immediate words in the outer-interpreter. This was my example: On Tuesday, March 31, 2015 at 3:13:14 PM UTC-7, hughag...@gmail.com wrote: > : my-if [ ' if ] literal execute ; immediate ok > : ttt ( flag -- ) my-if ." true " else ." false " then ; > Err# -14 ERR: Attempt to interpret a compile only definition. > -> : ttt ( flag -- ) my-if ." true " else ." false " then ; > ^ > see my-if > MY-IF (is IMMEDIATE) > ( 004C7A80 E89B23F4FF ) CALL 00409E20 IF > ( 004C7A85 C3 ) NEXT, > ( 6 bytes, 2 instructions ) > ok I'm using MY-IF inside of a colon definition. MY-IF is immediate, so it executes. STATE at this time is TRUE (compilation state), so when the xt of IF is EXECUTEd, it should work --- IF is supposed to have compilation semantics (works when STATE is TRUE). Anton Ertl is saying that my xt was for the interpretation semantics of IF, but there is no such thing. This is why I say that cross-compilation is much simpler. In my cross-compiler, the TARG words all have two versions --- one version in TARG and one version in HOST that is immediate and compiles the TARG version --- the two versions are in different vocabularies and have different xt values. Immediate words in HOST (such as IF) do not have a TARG version. Using a cross-compiler is super-simple --- there is no confusion as to whether a word has compilation-semantics or interpretation-semantics, because these are clearly distinct. Also, I have a way to examine an xt and determine what vocabulary the word was defined in --- so if you can't remember whether you ticked a word in HOST or TARG, you can find out --- also, the cross-compiler does automatic error-checking to abort if an xt is executed in the wrong place (this is a common bug). ANS-Forth is a totally broken language-standard. This whole business of ticking IF and getting the interpretation semantics of IF, which don't exist, rather than the compilation semantics which do exist, is utter foolishness. WTF??? Why does anybody take ANS-Forth seriously? This idiotic marketing tactic from Forth Inc. (trying to make themselves appear to set the standard for everybody) should have died in 1994 --- actually, the real world stopped taking Forth seriously in 1994 because of this --- but ANS-Forth persists 20 years later, and it still doesn't make any sense. Why does anybody outside of Forth Inc. care about ANS-Forth? Most likely, Stephen Pelc cares because Forth Inc. is giving him a paycheck. Elizabeth Rather has stated on comp.lang.forth that Forth Inc. and MPE have done major joint projects together. I think what is happening here, is that Forth Inc. is good at marketing (because they own the name Forth), but they aren't good at programming, so they have to out-source their programming work to MPE. Stephen Pelc can program in Forth, but he is terrible at marketing (he has that bozo Juergen Pintaske selling a book called "Forth Lite Tutorial" for $4.24, but nobody buys it despite the low price because it is obviously just an overgrown sales pamphlet, and besides that nobody wants a "lite" language anyway).
[toc] | [prev] | [next] | [standalone]
| From | "WJ" <w_a_x_man@yahoo.com> |
|---|---|
| Date | 2015-04-06 04:48 +0000 |
| Message-ID | <mft37n$ab9$1@dont-email.me> |
| In reply to | #37954 |
hughaguilar96@gmail.com wrote: > actually, the real world stopped taking Forth seriously in 1994 because of this True.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-04-04 13:57 -0700 |
| Message-ID | <d2ccb217-babc-4a88-a4b4-da1f79653c38@googlegroups.com> |
| In reply to | #37898 |
On Friday, April 3, 2015 at 1:58:49 PM UTC-7, Anton Ertl wrote: > hughaguilar96@gmail.com writes: > |6.1.0070 ' tick CORE > | > |( "<spaces>name" -- xt ) > | > |Skip leading space delimiters. Parse name delimited by a space. Find > |name and return xt, the execution token for name. An ambiguous > |condition exists if name is not found. *When interpreting, ' xyz > |EXECUTE is equivalent to xyz.* > > Emphasis mine. I have an informal answer from a Forth-94 TC member > that the empasised sentence implies that a standard program cannot > tick words without interpretation semantics. So when you ' IF, the > system can do whatever it likes, e.g., report an error, give you the > xt of a word that produces an error on execution, give you the xt of a > word that represents the compilation semantics of IF, or something > else. At the very beginning of this thread, I said: "This is the same bug that I previously discovered in Gforth when writing MACRO: (the ; doesn't have an xt). Now in VFX I find that IF has an xt, but it doesn't work." This is essentially what you are saying now. If you tick or FIND an immediate word, you may get an abort (what happened when I ticked ; in Gforth), you may get an xt of a word that aborts on execution (what happened when I ticked IF in VFX), or you may get mushrooms growing on your ass --- pretty much anything is ANS-Forth compliant except for the possibility that the xt when executed does what the word does when executed. You are the chairperson of the Forth-200x committee, but you are totally focused on telling me what I can't do, and telling me that the xt of an immediate word became meaningless and that I should have known this. I still say that this is a bug. My example code posted at the beginning of the thread should have worked. BTW: Who was the "Forth-94 TC member" who interpreted this sentence, "When interpreting, ' xyz EXECUTE is equivalent to xyz." to mean that it is impossible in ANS-Forth to obtain a working xt of an immediate word? This seems like a bit of a stretch to interpret this one sentence in such a way as to make meaningless the xt of every immediate word (why does FIND return an xt for an immediate word if it is meaningless, and why doesn't the documentation for FIND mention that it is returning an unusable xt?) --- I think you're just making this stuff up! --- an xt (executable token) than can't be executed??? I'm reminded of how the Evangelists interpret the Book of Revelation to mean that the world is ending within a few years, and there is going to be a Rapture of the saved, and people like me will be "left behind" to get myriad tribulations, etc. --- I read it, and that wasn't my interpretation --- I'm like Simon in "The Lord of the Flies" who said, there is no Beast.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-04-05 00:16 -0400 |
| Message-ID | <mfqctn$rat$2@dont-email.me> |
| In reply to | #37943 |
On 4/4/2015 4:57 PM, hughaguilar96@gmail.com wrote: > On Friday, April 3, 2015 at 1:58:49 PM UTC-7, Anton Ertl wrote: >> hughaguilar96@gmail.com writes: >> |6.1.0070 ' tick CORE >> | >> |( "<spaces>name" -- xt ) >> | >> |Skip leading space delimiters. Parse name delimited by a space. Find >> |name and return xt, the execution token for name. An ambiguous >> |condition exists if name is not found. *When interpreting, ' xyz >> |EXECUTE is equivalent to xyz.* >> >> Emphasis mine. I have an informal answer from a Forth-94 TC member >> that the empasised sentence implies that a standard program cannot >> tick words without interpretation semantics. So when you ' IF, the >> system can do whatever it likes, e.g., report an error, give you the >> xt of a word that produces an error on execution, give you the xt of a >> word that represents the compilation semantics of IF, or something >> else. > > At the very beginning of this thread, I said: > "This is the same bug that I previously discovered in Gforth when writing MACRO: (the ; doesn't have an xt). Now in VFX I find that IF has an xt, but it doesn't work." > > This is essentially what you are saying now. If you tick or FIND an immediate word, you may get an abort (what happened when I ticked ; in Gforth), you may get an xt of a word that aborts on execution (what happened when I ticked IF in VFX), or you may get mushrooms growing on your ass --- pretty much anything is ANS-Forth compliant except for the possibility that the xt when executed does what the word does when executed. You are the chairperson of the Forth-200x committee, but you are totally focused on telling me what I can't do, and telling me that the xt of an immediate word became meaningless and that I should have known this. > > I still say that this is a bug. My example code posted at the beginning of the thread should have worked. I still say you need to read the ANS Forth spec... Here it is again, you ignored my prior post. From the Forth 2012 spec which I assume is substantially the same as the previous spec: 4.1.2 Ambiguous conditions A system shall document the system action taken upon each of the general or specific ambiguous conditions identified in this standard. See 3.4.4 Possible actions on an ambiguous condition. The following general ambiguous conditions could occur because of a combination of factors: .... – attempting to obtain the execution token, (e.g., with 6.1.0070 ’, 6.1.1550 FIND, etc. of a definition with undefined interpretation semantics; Clearly you are doing just what they tell you will give an undefined result. So no matter what the system does with your code, it is not broken. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-04-05 10:11 +0000 |
| Message-ID | <2015Apr5.121144@mips.complang.tuwien.ac.at> |
| In reply to | #37943 |
hughaguilar96@gmail.com writes:
>On Friday, April 3, 2015 at 1:58:49 PM UTC-7, Anton Ertl wrote:
>> hughaguilar96@gmail.com writes:
>> |6.1.0070 ' tick CORE
>> |=20
>> |( "<spaces>name" -- xt )
>> |
>> |Skip leading space delimiters. Parse name delimited by a space. Find
>> |name and return xt, the execution token for name. An ambiguous
>> |condition exists if name is not found. *When interpreting, ' xyz
>> |EXECUTE is equivalent to xyz.*
>>=20
>> Emphasis mine. I have an informal answer from a Forth-94 TC member
>> that the empasised sentence implies that a standard program cannot
>> tick words without interpretation semantics. So when you ' IF, the
>> system can do whatever it likes, e.g., report an error, give you the
>> xt of a word that produces an error on execution, give you the xt of a
>> word that represents the compilation semantics of IF, or something
>> else.
>
>At the very beginning of this thread, I said:
>"This is the same bug that I previously discovered in Gforth when writing M=
>ACRO: (the ; doesn't have an xt). Now in VFX I find that IF has an xt, but =
>it doesn't work."
>
>This is essentially what you are saying now. If you tick or FIND an immedia=
>te word, you may get an abort (what happened when I ticked ; in Gforth), yo=
>u may get an xt of a word that aborts on execution (what happened when I ti=
>cked IF in VFX), or you may get mushrooms growing on your ass --- pretty mu=
>ch anything is ANS-Forth compliant except for the possibility that the xt w=
>hen executed does what the word does when executed. You are the chairperson=
> of the Forth-200x committee, but you are totally focused on telling me wha=
>t I can't do, and telling me that the xt of an immediate word became meanin=
>gless and that I should have known this.
Immediacy is not the issue, the lack of defined interpretation
semantics is. You can tick immediate words with intepretation
semantics like ( and \ or user-defined immediate words all day long,
and the result is defined by the standard.
>BTW: Who was the "Forth-94 TC member" who interpreted this sentence, "When =
>interpreting, ' xyz EXECUTE is equivalent to xyz." to mean that it is impos=
>sible in ANS-Forth to obtain a working xt of an immediate word? This seems =
>like a bit of a stretch to interpret this one sentence in such a way as to =
>make meaningless the xt of every immediate word (why does FIND return an xt=
> for an immediate word if it is meaningless, and why doesn't the documentat=
>ion for FIND mention that it is returning an unusable xt?)
The TC member was Loring Craymer. But looking at the old mails, the
TC also pointed me to:
|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;
And interpreting that to mean that a standard program cannot get the
xt of a word without interpretation semantics is not at all a stretch.
Concerning FIND, returning the not-found result when FINDing a word
without interpretation semantcs in interpretation state would also be
an option; that's what cmForth did, and supporting such systems was
certainly the intent of the Forth-94 TC.
I guess you would not be any happier if ' IF reported "undefined word"
and if C" IF" FIND in interpretation state gave you the not-found
result.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-04-05 14:37 -0700 |
| Message-ID | <86deaa85-739d-4c11-91cc-152fe625cbb8@googlegroups.com> |
| In reply to | #37960 |
On Sunday, April 5, 2015 at 3:50:03 AM UTC-7, Anton Ertl wrote:
> hughaguilar96@gmail.com writes:
> >At the very beginning of this thread, I said:
> >"This is the same bug that I previously discovered in Gforth when writing M=
> >ACRO: (the ; doesn't have an xt). Now in VFX I find that IF has an xt, but =
> >it doesn't work."
> >
> >This is essentially what you are saying now. If you tick or FIND an immedia=
> >te word, you may get an abort (what happened when I ticked ; in Gforth), yo=
> >u may get an xt of a word that aborts on execution (what happened when I ti=
> >cked IF in VFX), or you may get mushrooms growing on your ass --- pretty mu=
> >ch anything is ANS-Forth compliant except for the possibility that the xt w=
> >hen executed does what the word does when executed. You are the chairperson=
> > of the Forth-200x committee, but you are totally focused on telling me wha=
> >t I can't do, and telling me that the xt of an immediate word became meanin=
> >gless and that I should have known this.
>
> Immediacy is not the issue, the lack of defined interpretation
> semantics is. You can tick immediate words with intepretation
> semantics like ( and \ or user-defined immediate words all day long,
> and the result is defined by the standard.
So, what attribute does IF have other than immediacy? You said that immediacy is not the issue --- so what is the issue?
Why this bothers me is that IF seems to have some kind of exulted status that ordinary immediate words lack. Typically, in the header is a flags cell that has various flags ("smudged," "immediate," etc.) that indicate attributes of the word --- is there an "exulted" flag that I don't know about? Effectively, ANS-Forth now has syntax --- IF and ; etc. are part of the syntax of ANS-Forth, as they have this exulted status --- but immediate words that I write are not part of the syntax of ANS-Forth.
Earlier, we had this comment:
On Friday, April 3, 2015 at 10:26:32 AM UTC-7, Jason Damisch wrote:
> But, if you want my opinion, you should make up your
> own mind as to what Forth is and what it isn't. If you can write you
> own Forth, and it would be recognizable to the people who implemented
> Forths back in the 1970's and 1980's then I would call it a Forth.
This is a very egalitarian viewpoint! There is only one problem however --- ANS-Forth would not "be recognizable to the people who implemented Forths back in the 1970's and 1980's." I remember the 1980s well (not the 1970s though, as I was still in grade school). One of the distinguishing features of Forth in those days, as compared to C or Pascal etc., is that Forth didn't have a syntax. So, if we could bring those earlier implementers of Forth back from the grave, they would likely say that ANS-Forth does not deserve to be called "Forth" due to the fact that ANS-Forth now has syntax --- Charles Moore is one of them --- C.M. is not actually in the grave, but for all practical purposes he is, as he has become an old fool puttering around with his GA144 (nobody, including himself, knows what the thing is for).
Lets try an experiment:
: if postpone if ; immediate \ meet the new IF same as the old IF
IF is redefined ok
: my-if [ ' if ] literal execute ; immediate ok
: ttt my-if ." true" else ." false" then ; ok
1 ttt true ok
0 ttt false ok
see my-if
MY-IF (is IMMEDIATE)
( 004C7AB0 E8CBFFFFFF ) CALL 004C7A80 IF
( 004C7AB5 C3 ) NEXT,
( 6 bytes, 2 instructions )
ok
Now we have a new version of IF that is immediate and does the same thing that the old version of IF does, but which lacks the exulted status of IF of being a part of ANS-Forth syntax. So, tell me Mr. Chairman, if the new IF is effectively the same as the old IF, then what exactly was the purpose of the old IF having exulted status of being a part of ANS-Forth syntax? What not just flush this exulted-status idea altogether, as it isn't doing anything for us?
Can you give me a list of all the words in ANS-Forth that have the exulted status of being a part of ANS-Forth syntax? I'll just make new versions of all of them in my novice-package, similar to the new version of IF that I wrote in the above example --- so long as people use my novice-package, they will be back to the good old days of Forth not having syntax, just like in the 1970s and 1980s that Jason is nostalgic about --- also, I will be able to write SYNONYM in ANS-Forth, and we can flush Stephen Pelc's non-standard SYNONYM that comes at too high of a price (vendor lock-in).
My novice-package is already a litany of work-arounds for the myriad bugs in the ANS-Forth standard, and this will be yet one more --- Elizabeth Rather will be defeated again! --- her idiotic restrictions that she wrote in stone as the ANS-Forth standard will be worked-around in my novice-package. :-D
P.S. I don't know who Loring Craymer is --- but he can go fuck himself too! --- he is not signing my paychecks, so he is not my boss who tells me what to do (and, more importantly, what I can't do). Whoever he was, he must have just been one of Elizabeth Rather's brown-nosers, as she allowed him to be on the ANS-Forth committee. I blame Elizabeth Rather entirely for ANS-Forth --- I don't care about the other committee members --- she was the chairperson of the committee, so she has to take 100% of the blame.
[toc] | [prev] | [next] | [standalone]
| From | "WJ" <w_a_x_man@yahoo.com> |
|---|---|
| Date | 2015-04-06 04:52 +0000 |
| Message-ID | <mft3f8$aqs$1@dont-email.me> |
| In reply to | #37982 |
hughaguilar96@gmail.com wrote: > Why this bothers me is that IF seems to have some kind of exulted status I believe that the word that you want is "exalted".
[toc] | [prev] | [next] | [standalone]
Page 10 of 17 — ← Prev page 1 … 8 9 [10] 11 12 … 17 Next page →
Back to top | Article view | comp.lang.forth
csiph-web