Hello Camm, you wrote:
si::newline is a funtion which currently appears unused in the debugging code.
OK, thanks for the info. I resolved the Maxima problem (I believe) by not calling si::newline (and calling a local version instead, as with other Lisp implementations).
The large number segfault issue has also been resolved in 2.6.8pre, though the division takes essentially forever. In 2.7.0, we use gmp's gcd for bignums, so your example finishes in seconds. Given the time 2.7.0 is taking, perhaps it is worth migrating this one feature back into 2.6.8. Comments most welcome.
Well, operations with numbers like 255^(2^22) are fairly rare, so I don't think it is worth the trouble to backport the patch from 2.7.0.
Regarding the windows gazonk files issue, as I do not have access to such a machine, could one please check the variable compiler::*keep-gaz*? These files are supposed to be deleted automatically unless this is set.
In Maxima 5.9.3.99rc2 / GCL 2.6.7 on Linux, I find compiler::*keep-gaz* is nil. So I guess that's OK. I don't have a Windows box at hand, maybe someone else can check that. I notice the GCL version in the bug report is 2.6.5. Was *keep-gaz* introduced after that?
The *read-base* error I've just fixed in 2.6.8pre by backporting a function from cvs head.
Terrific!
Are these all of our issues outstanding?
Well, the one other Maxima-related issue that I can see (after scanning the GCL bug list) is bug #14367, dribble file has newlines in wrong places. Thanks a lot for all your hard work! Robert Dodier _______________________________________________ Gcl-devel mailing list Gcl-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gcl-devel