Hi,
I had problems compiling Xuriella (a current clone from the git repository) with LispWorks. There were a few problems regarding the order of the definitions. Common Lisp is quite sensitive to the order of definitions if macros or structures are used. You have to define a structure before you use it (this also entails accesses using structure-slot-accessors). You also have to define a macro before compiling a function using that macro. I've fixed those issues locally here and Xuriella runs now withing my LispWorks setup. If you're interested in what I've done; how should I make my changes available?
ciao, Jochen
-- Jochen Schmidt CRISPYLOGICS Julienstr. 1, 90419 Nuremberg
Fon +49 (0)911 517 999 82 Fax +49 (0)911 517 999 83
mailto:info@crispylogics.com http://www.crispylogics.com
Quoting Jochen Schmidt (jsc@crispylogics.com): ...
I've fixed those issues locally here and Xuriella runs now withing my LispWorks setup. If you're interested in what I've done; how should I make my changes available?
I'm definitely interested, since I don't test on LispWorks myself.
Any ordinary patch using a unified diff would be fine, although git-format-patch or simply a copy of your repository that I can pull from using HTTP are also good (and have the advantage that you're listed as the committer).
Did you also have to make changes to plexippus? Right now, plexippus has correct IEEE float handing only on SBCL, so some work in that area would have to be done. An easy route might be to implement everything from xnum.lisp using FFI calls to libc functions. Without these changes, some tests from the XSLT test suite are bound to fail.
In case you have the chance, it would be interesting to see test suite results with your changes. Since there's a preprocessing step involved, which parses the test suite descriptions, you'd want to use the following tarball with a preprocessed test suite, rather than the upstream XSLT testsuite tarball:
http://common-lisp.net/project/xuriella/xuriella-XSLT-testsuite-04.tar.bz2
But please send in your patch either way -- as long as it improves the LispWorks situation at all, it's very welcome, even if it's not perfect yet.
Thanks, d.