On 2008-02-28 07:17:39 -0700, Josh Grams <josh@[EMAIL PROTECTED]
> said:
> On Feb 27, 2:18 pm, Dennis Ruffer wrote:
>> On 2008-02-26 19:46:51 -0700, Josh Grams <josh@[EMAIL PROTECTED]
>said:
>>
>>> Any suggestions for how to improve this are welcome (I think).
>>> Though...I did just ask for (and received) code and then went
>>> and reinvented the wheel anyway, so... :)
>>
>> Yep, you made a new wheel. Not sure why, or what you want to
>> hear. There are many ways to skin a cat. If you can't explain
>> why your method is "better" other than the typical NIH syndrome,
>> then why should we spend the time to make suggestions that you
>> will ignore?
>
> That's a fair question. The advantage that I want (over a
> straight stack display) is the ability to have custom checking and
> display code, to sup****t better failure messages when working with
> data structures or whatever. This is somewhat possible with
> Anton's ttester, but the comparison words are more complicated
> than I'd like, and you have to either define your own test closing
> words or specify the tests in reverse order.
It is hard to get around the RPN nature of Forth.
>
> And even if I'm willing to settle for a straight stack display,
> all of the alternatives still require work on my part. The code
> you posted here uses several non-standard words, and doesn't
> handle floats. The patch for ttester.fs that you posted to the
> gforth mailing list came through on my machine with whitespace
> that doesn't match the CVS version, so it took a bunch of fiddling
> to get it to apply. Also it has broken the initial depth handling
> and possibly FTESTER.
I'd like to hear about anything my changes have broken. I have tested
what I could and haven't found any problems yet. If you look closely,
the initial depth handling is simply refactored into the stack array.
If you have a test case that I have broken, please tell me so I can fix
it.
>
> I mainly posted my prototype in case someone was curious, had time
> to waste, and might have interesting ideas. It got a bit more
> complex than I like, and I'm hoping there's a way to simplify
> things a bit, or at least factor out the complexity so that the
> basic structure of the code is clear.
As Krishna said, having a common test harness is a good thing.
>
>>> But how do I test the combined float/data stack case? Anybody
>>> have a Forth that does things that way? (x86 or PPC Linux,
>>> preferably).
>>
>> While adding my stack recall display to Anton's ttester.fs I
>> noticed that he did have a way to deal with the floating point
>> stack issues, and it sounds like it has even been used on the FSL
>> code. So that might be a place to look.
>
> I have looked at ttester.fs, of course. The problem isn't how to
> "deal with the floating point stack issues", it's how to test
> whether FP code works on a system which keeps floats on the data
> stack. I don't see any way to do that without having such a
> system. Krishna pointed out PFE, which worked. Its fpnostack
> module doesn't implement the environment queries quite right, but
> that's easy to work around. I tried kforth too, but it doesn't
> have >IN, which would require a larger reworking of the code.
>
> --Josh
You might also try SwiftForth. It has a configuration option to use
the hardware stack or the data stack and I have used it with the Hayes
suite many times in the past. I think all of this is available on
their evaluation version. I use OSX, so it is hard for me to check it,
and that might explain why you had problems with my patches to
ttester.fs.
DaR
|
