Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #32977
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Newsgroups | comp.lang.forth |
| Subject | Re: does VFX have the same bug as Gforth? |
| Date | 2014-08-20 07:46 +0000 |
| Organization | Institut fuer Computersprachen, Technische Universitaet Wien |
| Message-ID | <2014Aug20.094606@mips.complang.tuwien.ac.at> (permalink) |
| References | (4 earlier) <lsvj4l$543$1@online.de> <lsvkvr$400$1@dont-email.me> <lsvlqi$bcb$1@online.de> <2014Aug19.173925@mips.complang.tuwien.ac.at> <lt0cd2$uu$1@online.de> |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>
>> Bernd Paysan <bernd.paysan@gmx.de> writes:
>>>Alex McDonald wrote:
>>>> I would like to see that explained, since setting a single behaviour for
>>>> IMMEDIATE words in my Forth has not caused any problems for me; and I
>>>> struggle to see what code this might break. Can you give a concrete
>>>> example?
>>>
>>>Ok, simple example:
>>>
>>>: cond, ( xt -- ) >r postpone IF r> compile, postpone THEN ;
>>>: ?exit ( -- ) ['] exit cond, ; immediate
>>>
>>>Works fine when EXIT is not immediate - that's my assumption for now that
>>>EXIT is non-immediate.
>>
>> Just write it as
>>
>> : cond, ( ct -- ) 2>r postpone IF 2r> execute postpone THEN ;
>> : ?exit ( -- ) [comp'] exit cond, ; immediate
>>
>> and it will work whether EXIT is immediate or not. You may argue that
>> [COMP'] is not standard, but neither is "['] exit".
>
>They are non-standard on a different level. ['] EXIT is an ambiguous
>condition (i.e. non-standard, because there's no consent between different
>implementers), [COMP'] is non-standard, because it's using a Gforth
>extension, not even proposed for inclusion into a future standard, and
>probably facing difficulties to get in.
Given that there is no consent between implementors on what ['] EXIT
should mean, it's unlikely to get in, and there is no proposal for
including ['] EXIT in a future standard, either.
Concerning [COMP'], given that there we have NAME>COMPILE in Forth
200x, the most difficult step in standardizing it has already been
taken. But true, there is no proposal on [COMP']. The main
difficulty I would expect now is that "application programmers don't
need it", i.e., the objection would be that too few people write words
like COND, and ?EXIT to make [COMP'] worth standardizing, and that
would also be a counterargument to proposals for changing ['] or
COMPILE,.
Anyway, to make your code above work, you would also need to change
COMPILE, in an incompatible way, and we have learned from bad
experiences in the past (e.g., NOT) that this is a very bad idea. In
no existing Forth system COMPILE, works the way you want it to; I see
no chance that a proposal for such a change to COMPILE, would come
through.
>It's non-portable just like + with overflow is non-portable, because
>different machines could behave different on overflow.
An overflow on + is non-standard, but portable: Every Forth system
performs wraparound and uses 2s-complement representation for signed
integers.
In contrast, ['] EXIT does not work on all Forth systems, and behaves
differently in different Forth systems where it does not produce an
error.
>so it's very likely that the code out there
>that actually does use ['] EXIT wants an xt as result. Something to
>COMPILE,, to be precise, because that's the only use of that xt which makes
>sense.
As your example shows, what makes sense (if you can tick EXIT) depends
on the way that EXIT is implemented. If it is implemented as
IMMEDIATE word, then it makes sense to EXECUTE the xt in COND,.
I tried the following code on iforth-2.1, vfxlin 4.60,
SwiftForth 3.4.4, Gforth 0.7.0, and bigFORTH 2.3.1:
: bla ['] exit execute ." x" ; bla
iForth outputs nothing.
vfxlin produces an error -14 when BLA executes.
sf outputs "x".
gforth produces an error -14 when ['] executes.
bigforth outputs "x".
Not very much portability here.
Next test:
: x ['] exit compile, ; immediate : a x ." a" ; immediate : b a ." b" ; b
iforth outputs "b".
sf outputs "b".
vfxlin outputs "b".
gforth produces an error -14 when ['] executes.
bigforth outputs "b".
Four of these systems make "['] exit compile," behave like POSTPONE
EXIT (e.g., by implementing EXIT as a word with default compilation
semantics (something like +)).
Now a way to get a guaranteed tickable EXIT is to redefine it (all
words defined by the user in standard Forth have interpretation
semantics and are therefore tickable):
: exit postpone exit ; immediate
But as you point out, this changes what "['] exit compile," does:
: exit postpone exit ; immediate : x ['] exit compile, ; immediate : a x ." a" ; immediate : b a ." b" ; b
iforth outputs "a".
sf outputs "a".
vfxlin outputs "a".
gforth outputs "a".
bigforth outputs "a".
Let's try the EXECUTE variant with that EXIT again:
: exit postpone exit ; immediate : x ['] exit execute ; immediate : a x ." a" ; immediate : b a ." b" ; b
iforth outputs "b".
sf outputs "b".
vfxlin outputs "b".
gforth outputs "b".
bigforth outputs "b".
So the definition
: exit postpone exit ; immediate
makes ['] EXIT portable, but changes it on all systems. Maybe your
next argument is that this redefinition of EXIT is wrong, and we
should either not use it (but what else?) or change it's meaning along
with the meaning of "COMPILE,", but my conclusion is that ['] EXIT is
just a bad idea. As for "the only thing that makes sense", thinging
about these examples I did not get the feeling that COMPILE, makes
more or less sense than EXECUTE for ['] EXIT.
>The way a standard process works means that we probably need to change the
>definition of COMPILE, because it no longer reflects a consent within the
>Forth community.
The definition of "consent" is not "Bernd Paysan's opinion". Also, a
single dissenting opinion does not dissolve consent.
> There's simply an ambiguous condition if you COMPILE, a
>word with "special compilation semantics". This would be the first
>transition step. After this is done, Anton still can say "I want COMPILE,
>to be equivalent to POSTPONE LITERAL POSTPONE EXECUTE", and has his say in
>the compiler he maintains, but it's no longer something standard.
Taking away standard guarantees to programs (and in this case there
really are programs out there the rely on this guarantee) is a bad
idea. Even if you find consent on such a change (which is a long way
from dissolution of the consent on the current definition), the way to
do it would be to declare COMPILE, obsolescent, and define another
word that has the behaviour you want, whatever that may be.
>And the fact that it is no longer standard is a consequence of the
>"normative Kraft des Faktischen" as a German philosopher put it (the
>normative force of the factual - that is the main driving force of roughly
>consent-based standards) - there *are* popular systems out there where this
>relation doesn't hold, and funny enough, the Forth system Anton and I
>maintain, is among them - but so far, only if you actually use the non-
>standard extension SET-COMPILER or COMP: to break this assumption (which
>means there is no standard way to write a program that exhibits this non-
>standard behavior of COMPILE,).
Sure, you can make any system behave in non-standard ways by writing
non-standard programs (e.g., you might patch the implementation of
COMPILE,). That's nothing spectacular, and no justification for
changing the meaning of COMPILE, for standard programs.
>If we make this extension standard (optional wordset, of course), then there
>is a standard way to break the original COMPILE, assumption, and that would
>be phase 2 of the long transition.
I don't see enough value in standardizing this "feature" to sacrifice
the COMPILE,-EXECUTE relation for it. Also, even if I was not in
play, I have my doubts that you will get consent among implementors.
After all, this requires standardizing things about the implementation
that they have been very reluctant to standardize.
>The first thing I want to do with COMPILE, however is to remove this stupid
>COMPILE, is compile-only restriction. I can't find a Forth where this is
>really the case, all compile
>
>: test [ ' + compile, ] ;
That's certainly a good idea, but it has nothing to do with the rest
of your ideas about COMPILE,.
>Anton's proposal how to resolve the backward compatibility solution is to
>invent a new name for this new COMPILE, so e.g. XT, might do better (which
>would be defined as "append the compilation semantics of the xt"), and
>define COMPILE, so that it indeed does the equivalent of POSTPONE LITERAL
>POSTPONE EXECUTE, maybe optimizing the common case (default compilation
>semantics).
No, my idea is to use COMP' and [COMP']. "XT," or whatever it is
called would just be a way to integrate your idea of how COMPILE,
should behave in a backwards-compatible way.
My other idea is to get rid of words that have both interpretation
semantics and non-default non-immediate compilation semantics (S", TO,
IS ...). Then we really just have one xt per word,
>But that approach breaks the "user-implemented text
>interpreter", which was the motivation of Mitch Bradley to introduce
>COMPILE, at all.
It does not. The user-defined text interpreter works fine with the
currently-standard COMPILE,. Ok, it needs an ugly FIND, but that
uglyness is a bastard of words like S" and FIND; trying to make FIND
less ugly by breaking COMPILE, is a bad idea.
>The change to COMPILE, I probably would suggest would be, in the proporsal
>with SET-COMPILER:
>
>SET-COMPILER ( comp-xt -- )
>modifies the compilation semantics of the last definition to execute comp-xt
>on compilation
>
>comp-xt: ( i*x xt -- j*y )
>performs the compilation semantics of xt.
>
>COMPILE, ( xt -- )
>If xt has a special compilation semantics set by SET-COMPILER, perform this
>special compilation semantics, otherwise append the execution semantics of
>xt (default compilation semantics).
>
>That way it is clearly extending the current COMPILE, in a way that now xts
>can carry non-default compilation semantics - and it's non-ambiguous by
>itself (i.e. still well-defined). And of course we need to say that the
>system has to document which words with special compilation semantics are
>actually implemented that way.
No from me for the change to COMPILE,.
- 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/
Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
does VFX have the same bug as Gforth? hughaguilar96@yahoo.com - 2014-08-17 21:09 -0700
Re: does VFX have the same bug as Gforth? Bee <forth@calcentral.com> - 2014-08-17 23:06 -0700
Re: does VFX have the same bug as Gforth? hughaguilar96@yahoo.com - 2014-08-18 17:03 -0700
Re: does VFX have the same bug as Gforth? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-08-18 22:19 -0400
Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-19 09:14 +0000
Re: does VFX have the same bug as Gforth? Bernd Paysan <bernd.paysan@gmx.de> - 2014-08-19 15:23 +0200
Re: does VFX have the same bug as Gforth? "Alex McDonald" <blog@rivadpm.com> - 2014-08-19 14:54 +0100
Re: does VFX have the same bug as Gforth? Bernd Paysan <bernd.paysan@gmx.de> - 2014-08-19 16:09 +0200
Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-19 15:39 +0000
Re: does VFX have the same bug as Gforth? Bernd Paysan <bernd.paysan@gmx.de> - 2014-08-19 22:34 +0200
Re: does VFX have the same bug as Gforth? "Alex McDonald" <blog@rivadpm.com> - 2014-08-19 23:29 +0100
Re: does VFX have the same bug as Gforth? Bernd Paysan <bernd.paysan@gmx.de> - 2014-08-20 23:06 +0200
Re: does VFX have the same bug as Gforth? "Alex McDonald" <blog@rivadpm.com> - 2014-08-20 22:21 +0100
Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-20 07:46 +0000
Re: does VFX have the same bug as Gforth? Bernd Paysan <bernd.paysan@gmx.de> - 2014-08-21 00:26 +0200
Re: does VFX have the same bug as Gforth? hughaguilar96@yahoo.com - 2014-08-20 22:42 -0700
Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-21 10:23 +0000
Re: does VFX have the same bug as Gforth? hughaguilar96@yahoo.com - 2014-08-21 23:29 -0700
Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-22 12:54 +0000
Re: does VFX have the same bug as Gforth? hughaguilar96@yahoo.com - 2014-08-22 17:54 -0700
Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-23 10:46 +0000
Re: does VFX have the same bug as Gforth? hughaguilar96@yahoo.com - 2014-08-23 11:15 -0700
Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-24 13:32 +0000
Re: does VFX have the same bug as Gforth? hughaguilar96@yahoo.com - 2014-08-24 10:40 -0700
Re: does VFX have the same bug as Gforth? Bee <forth@calcentral.com> - 2014-08-24 22:03 -0700
Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-25 08:31 +0000
Re: does VFX have the same bug as Gforth? hughaguilar96@yahoo.com - 2014-08-25 22:55 -0700
Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-21 12:45 +0000
Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-22 15:13 +0000
Re: does VFX have the same bug as Gforth? Bernd Paysan <bernd.paysan@gmx.de> - 2014-08-22 18:47 +0200
Re: does VFX have the same bug as Gforth? hughaguilar96@yahoo.com - 2014-08-22 18:28 -0700
Re: does VFX have the same bug as Gforth? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-08-23 04:44 -0400
Re: does VFX have the same bug as Gforth? Coos Haak <chforth@hccnet.nl> - 2014-08-23 16:15 +0200
Re: does VFX have the same bug as Gforth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-08-23 11:50 -0500
Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-23 07:15 +0000
Re: does VFX have the same bug as Gforth? Bernd Paysan <bernd.paysan@gmx.de> - 2014-08-23 22:12 +0200
Re: does VFX have the same bug as Gforth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-08-24 03:51 -0500
Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-24 13:36 +0000
Re: does VFX have the same bug as Gforth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-08-25 04:16 -0500
Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-25 09:44 +0000
Re: does VFX have the same bug as Gforth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-08-25 11:53 -0500
Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-26 06:34 +0000
Re: does VFX have the same bug as Gforth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-08-26 03:55 -0500
Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-26 12:37 +0000
Re: does VFX have the same bug as Gforth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-08-26 08:24 -0500
Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-26 13:55 +0000
Re: does VFX have the same bug as Gforth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-08-26 10:42 -0500
Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-26 16:05 +0000
Re: does VFX have the same bug as Gforth? Bernd Paysan <bernd.paysan@gmx.de> - 2014-09-23 17:20 +0200
Re: does VFX have the same bug as Gforth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-09-23 11:29 -0500
Re: does VFX have the same bug as Gforth? Bernd Paysan <bernd.paysan@gmx.de> - 2014-09-23 23:01 +0200
Re: does VFX have the same bug as Gforth? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-08-25 15:59 +0000
Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-26 06:23 +0000
Re: does VFX have the same bug as Gforth? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-08-26 09:15 +0000
Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-26 13:23 +0000
Re: does VFX have the same bug as Gforth? Mark Wills <markwills1970@gmail.com> - 2014-08-26 01:41 -0700
Re: does VFX have the same bug as Gforth? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-08-26 09:32 +0000
Re: does VFX have the same bug as Gforth? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-08-26 09:43 +0000
Re: does VFX have the same bug as Gforth? Mark Wills <markwills1970@gmail.com> - 2014-08-26 02:48 -0700
Re: does VFX have the same bug as Gforth? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-08-26 11:58 +0000
Re: does VFX have the same bug as Gforth? Mark Wills <markwills1970@gmail.com> - 2014-08-26 05:20 -0700
Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-26 12:30 +0000
Re: does VFX have the same bug as Gforth? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-08-25 14:15 +0000
Re: does VFX have the same bug as Gforth? Mark Wills <markwills1970@gmail.com> - 2014-08-25 07:44 -0700
Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-25 14:37 +0000
Re: does VFX have the same bug as Gforth? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-08-25 15:14 +0000
Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-25 15:33 +0000
Re: does VFX have the same bug as Gforth? Mark Wills <markwills1970@gmail.com> - 2014-08-26 01:56 -0700
Re: does VFX have the same bug as Gforth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-08-26 04:16 -0500
Re: does VFX have the same bug as Gforth? Mark Wills <markwills1970@gmail.com> - 2014-08-26 02:24 -0700
Re: does VFX have the same bug as Gforth? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-08-26 09:36 +0000
Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-26 13:40 +0000
Re: does VFX have the same bug as Gforth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-08-26 08:57 -0500
Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-26 12:52 +0000
Re: does VFX have the same bug as Gforth? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-08-26 14:14 +0000
Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-26 14:36 +0000
Re: does VFX have the same bug as Gforth? Bernd Paysan <bernd.paysan@gmx.de> - 2014-09-23 17:40 +0200
Re: does VFX have the same bug as Gforth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-08-26 10:53 -0500
Re: does VFX have the same bug as Gforth? Bernd Paysan <bernd.paysan@gmx.de> - 2014-09-23 17:36 +0200
Re: does VFX have the same bug as Gforth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-08-25 12:02 -0500
Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-26 06:42 +0000
Re: does VFX have the same bug as Gforth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-08-26 04:08 -0500
Re: does VFX have the same bug as Gforth? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-08-26 10:37 +0000
Re: does VFX have the same bug as Gforth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-08-26 08:30 -0500
Re: does VFX have the same bug as Gforth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-08-28 08:47 -0500
Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-29 13:03 +0000
Re: does VFX have the same bug as Gforth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-08-29 09:16 -0500
Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-26 13:06 +0000
Re: does VFX have the same bug as Gforth? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-08-26 07:36 -0400
Re: does VFX have the same bug as Gforth? Bernd Paysan <bernd.paysan@gmx.de> - 2014-09-23 17:28 +0200
Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-24 09:48 +0000
Re: does VFX have the same bug as Gforth? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-08-24 15:55 -0400
Re: does VFX have the same bug as Gforth? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-08-24 15:55 -0400
Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-25 08:26 +0000
Re: does VFX have the same bug as Gforth? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-08-26 07:36 -0400
Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-26 12:12 +0000
Re: does VFX have the same bug as Gforth? Bernd Paysan <bernd.paysan@gmx.de> - 2014-09-23 17:45 +0200
Re: does VFX have the same bug as Gforth? Mark Wills <markwills1970@gmail.com> - 2014-08-21 03:25 -0700
Re: does VFX have the same bug as Gforth? hughaguilar96@yahoo.com - 2014-08-21 23:14 -0700
Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-19 14:16 +0000
Re: does VFX have the same bug as Gforth? Bee <forth@calcentral.com> - 2014-08-17 23:16 -0700
Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-19 09:40 +0000
Re: does VFX have the same bug as Gforth? Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2014-08-18 09:16 +0100
Re: does VFX have the same bug as Gforth? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-08-18 09:32 +0100
Re: does VFX have the same bug as Gforth? "Alex McDonald" <blog@rivadpm.com> - 2014-08-18 13:09 +0100
Re: does VFX have the same bug as Gforth? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-08-18 12:29 +0000
Re: does VFX have the same bug as Gforth? hughaguilar96@yahoo.com - 2014-08-18 17:10 -0700
Re: does VFX have the same bug as Gforth? Bee <forth@calcentral.com> - 2014-08-18 17:48 -0700
Re: does VFX have the same bug as Gforth? hughaguilar96@yahoo.com - 2014-08-18 18:23 -0700
Re: does VFX have the same bug as Gforth? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-08-19 13:55 +0100
csiph-web