Mirko, It looks like there is a bug there in CLISP; symbol-macrolet is a part of the standard and it should work. I have given up on testing in CLISP because I encounter so many errors that seem to be a problem on their side. If you can get a useful answer out of CLISP, that's great, but you should switch to SBCL or CCL if you can because I do test on these. As to whether it should be a symbol-macro or a function call I think it is a style issue. I'm not terribly happy with the macro as it is, I think it requires rethinking anyway, I just hacked through it to get something out that would get rid of the with-c-double. I'll return to it at some point but I have other things I'm working on first. Liam On Sat, Jan 31, 2009 at 7:06 PM, Mirko Vukovic <mirko.vukovic@gmail.com> wrote:

Liam,

The file `ode-example.lisp' could not compile on clisp+cygwin+windows. The error occurred in `integrate-vanderpol', which uses the `with-ode-integration' macro.

I traced the problem to the symbol-macrolet generated macro `make-next-step'. It looks like the loop body cannot digest symbols created with symbol-macrolet (again clisp only, not sbcl).

I was able to fix the problem by changing make-next-step into a function via labels.

I am attaching a file that illustrates the problem, fix and verification. It has has several items: 1) illustration with a simple code on where clisp fails when loop uses a symbol-macrolet based symbol 2) the modified with-ode-integration macro 3) a version of integrate-vanderpol based on the modified macro 4) an example of a test-suite where I compared the outputs of your macro with the modified macro, using your examples of integrating vanderpol.

This issue is not a major show-stopper for me, since I have a working version now. I can see why make-next-step should be defined as a symbol-macro -- it is so simple. On the other hand, strictly visually, its appearance as a symbol in the body of the loop between two forms is a bit jarring. Also, make-next-step is an `internal' symbol to the with-ode-integration macro, and maybe should not be visible to the user.

But all of the above are really, minor, minor points, because the user is free to write their own version of `with-ode-integration' :-) The major point is really that sooner or later someone else will try to compile on clisp and hit the same problem.

Mirko

_______________________________________________ Gsll-devel mailing list Gsll-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel