Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #32985
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Newsgroups | comp.lang.forth |
| Subject | Re: does VFX have the same bug as Gforth? |
| Date | 2014-08-21 00:26 +0200 |
| Organization | 1&1 Internet AG |
| Message-ID | <lt37a0$tnf$1@online.de> (permalink) |
| References | (5 earlier) <lsvkvr$400$1@dont-email.me> <lsvlqi$bcb$1@online.de> <2014Aug19.173925@mips.complang.tuwien.ac.at> <lt0cd2$uu$1@online.de> <2014Aug20.094606@mips.complang.tuwien.ac.at> |
Anton Ertl wrote: > 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. Hm, if I understand the test correctly, 4 out of 5 systems had a consent on what ['] EXIT COMPILE, means, and the only dissenting oppinion is Anton Ertl's. Which does not really break consent. > Concerning [COMP'], given that there we have NAME>COMPILE in Forth > 200x, the most difficult step in standardizing it has already been > taken. Yes. > 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. It has already been changed in several Forth systems, and apparently not caused user complaints. While not being able to ' EXIT has caused people to complain, several times. This is just one case. Do you take bug reports like that serious or do you close them with Ulrich Drepper "invalid, as the standard allows me to be a dick, and break your program" reason? This behavior is obviously different from the user expectation, and as the standard says it's an ambiguous condition, you can as well just make the user to be right. That's the way we want it from the GCC team. We should live by our standards. > In > no existing Forth system COMPILE, works the way you want it to; It works that way in three Forth systems. > In contrast, ['] EXIT does not work on all Forth systems, and behaves > differently in different Forth systems where it does not produce an > error. Well, let's see: > 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. As EXIT has no interpretation semantics, it is quite easy to see why executing the returning xt does not lead to something useful. > 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 +)). Yes, that's what a user would expect from EXIT - it has no interpretation semantics, so it can't be EXECUTEd, but it has compilation semantics, so COMPILE, maybe can do something with it. It still might be immediate, but apparently, 4 out of 5 Forth systems found a way to have a non-immediate EXIT. In Gforth git head, you can define it easily: :noname drop postpone exit ; : exit -14 throw ; set-compiler And then suddenly, gforth also outputs "b". > 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. Yes, this means that the standard does not allow the user to define a reasonably derived version of EXIT. That's because the standard has poor tools for defining such words. IMMEDIATE is a pretty crappy solution. > 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. But COMPILE, did work 4 out of 5 cases, and the case it didn't work is the one which is implemented following your oppinion, and it can easily be fixed. So if you exclude the one dissenting voice, there's a consent. >>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. That's certainly a nonsense argument, because the dissenting COMPILE, is already in VFX, in Gforth git head, and in Win32Forth (in the STC version). > 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. The consent already dissolved (3 implementers in the small world of Forth is a big chunk that matters). And the straw mens you are errecting to prove that this COMPILE, is going to cause problems are not conclusive. Your point is that this COMPILE, is going to break code like Mini-OOF if you define a new word with special compilation semantics (with SET-COMPILER), and assign it to a method. Yes, this is going to break Mini-OOF. However, as SET-COMPILER is new, it's not going to break legacy Mini-OOF programs, because they simply can't do that (there wasn't a SET-COMPILER when they had been written, and words like EXIT weren't tickable). And the old words with special compilation semantics like S" still use the dual-xt approach (in the git head Gforth, not in VFX), which doesn't cause this problem. To illustrate what kind of problem we are talking about, I've done this in VFX: variable foo ok : [foo] foo @ execute ; ok : foo, foo @ compile, ; ok ' s" foo ! ok [foo] bla" type bla ok : test [ foo, bla" ] type ; ok test bla ok And that's how you are supposed to use this in Gforth: variable foo ok : [foo] foo @ execute ; ok : foo, foo @ compile, ; ok ' s" foo ! ok [foo] bla" type bla ok : test [ foo, ] type ; ok test bla" bla ok Certainly, this is not portable *now*. I can't imagine that Stephen will change VFX, this COMPILE, is a central feature, and convincing him to use the ugly FIND will be difficult. > 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. Yes. But Stephen actually started convincing others to do so, and he succeeded. The idea that it's my proposal is silly; I jumped late on this smart COMPILE, bandwagon. Win32Forth STC already had it, you made a posting proposing that, and Stephen gave a talk at a EuroForth, and then I was convinced. This is nothing new, this has been in VFX for ages (and with "ages" I mean really right from start). This is known to work with the 1 million lines of CCS, and it also works with the 500 lines of guru code in BerndOOF. There's very little which survives both tests, and BerndOOF is actually of the class *you* think would fail (it doesn't, because to fail, it would have to use SET-COMPILER in inappropriate places). > 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, That has been implemented with recognizers in Gforth git head. This however means that you have to remove several words from the standard... that's not going to happen too quickly. We might get an RFD for recognizes soon, though. >>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. Yes, but the ugly FIND is an "Anton Ertl's oppinion", nobody else in the set of the 5 Forths you tested has implemented the ugly FIND. They all have a FIND which doesn't depend on STATE. It's still ugly, because it takes a counted string, but that can be fixed easily. > No from me for the change to COMPILE,. The change already happened in several popular Forth systems. I'm just describing reality. You can continue to ignore reality (apparently you are doing that, because you say that this new COMPILE, is my oppinion only, instead of researching how many systems actually do it that way). But a standard usually codifies existing practice, and this practice already exists. If your system doesn't have a SET-COMPILER, the COMPILE, behaves as it used to be. If it has, it behaves differently - on words where SET- COMPILER has been used. The words with problems like TO, IS, S" have so many problems that ticking them certainly results in something outside the scope of the standard, so they don't matter. You just can't use ' S" COMPILE, portably, because it doesn't work *now*, and that's 20 years after ANS Forth has codified something where it is pretty clear how that should work - and at that time, it didn't work in any Forth system, including Gforth. That sort of standardization is not going to work. Standardize the things people already do is much more likely to succeed. The big difference between changing NOT and changing COMPILE, as discussed here is that changing NOT instantly broke a lot of code. The change of COMPILE, apparently went much better. I don't remember any code been broken by this in Gforth git head. We can ask Stephen, how much code breakage he has observed. This change on the other hand fixes something in Forth, which is really ugly: state smart words. It doesn't fix them in the way you want to, but your solution just moves the uglyness to FIND, and therefore, none of the other impementers of popular systems wants to follow you. And the new COMPILE, solution doesn't have the drawbacks. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
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