Adriaan van Os wrote:
Frank Heckenbach wrote:
Backtraces are at the bottom of this messages. It seems that Mac OS X doesn't like Mr. "R" ....
The read tests are quite heavy on stack usage. If you can increase the system limit (ulimit etc.), you might want try that. But I'm changing them now to reduce stack usage, so in the next GPC version, they might work (unless it's actually another bug).
Increasing the stacksize eliminates most test failures, including the gpc internal errors !!
BTW, was it a soft or hard limit? GPC contains code that should eliminate the former, but of course, it's helpless against the latter. Anyway, a certain amount of stack usage for large programs probably just has to be accepted (note that the respective tests are actually quite large programs, despite their apparent file sizes, due to heavy use of macros etc.).
[G4:~/gnu/testgpc/test] adriaan% limit stacksize 2048 [G4:~/gnu/testgpc/test] adriaan% make
[results included as attachement]
# of GPC tests 2856 # of GPC tests passed 2828 # of GPC tests skipped 18 # of GPC tests failed 10
This surpasses all my expectations. We are near to opening up a bottle of champagne !
Leaves the nonlocal goto bug ...
9 out of 10 failed tests, if I am right - fjf558m.pas, fjf558n.pas, fproc.pas, goto4.pas, goto5.pas, math.pas, nlgpp.pas, nlgpp2.pas and nonlocgoto.pas.
Yes. It's a single issue, fortunately, but nevertheless an essential one for some applications.
This reminds me of UCSD Pascal for the Apple II. It had a "Goto statements options" (G+,G-) aimed at students "to keep novice programmers from using the GOTO statement ..." Shouldn't we keep Macintosh programmers out of it also ?
I'm not sure what you mean. I could add a warning (optional, of course) for every use of `goto'.
But, while I agree that `goto' should be avoided whenever possible, and I think it's always possible with local `goto's, some nonlocal `goto's can't be easily avoided, unless one resorts to C mechanisms like `longjmp' (see the `Trap' unit for an example).
The remaining failed test is systemtest.pas: Error in HeapError #2
I didn't study GetMem in detail, but why not allocate 2147483391 bytes of virtual memory ?
You're right. The test was meant to check the behaviour of some routine in an out-of-memory situation, but the way to reproduce this situation was poor.
Frank