[cxml-devel] ASD files for cxml don't work for openmcl

David Lichteblau david at lichteblau.com
Thu Jul 5 18:38:05 UTC 2007


Hi,

Quoting Sunil Mishra (smishra at sfmishras.com):
> I've recently updated to the latest cxml, to the CVS HEAD, and am having
> trouble with openmcl64. All in all, it looks like rune-is-integer has
> been poorly tested. I've had trouble with the asd files, compiling the
> tester, and with parsing XML. I've included lots of detail below. I am
> happy to help debug cxml, but I don't understand the system and will
> need guidance.

thank you for the report.  Obviously I broke cxml on non-unicode Lisps
completely when I split up cxml.asd and runes.asd before making the last
release.  I will look into those issues and make a new release as soon
as possible.

I am not sure where to find an OpenMCL without Unicode support for
AMD 64 though.  (But I have previously tested rune-is-integer using
CMUCL, and OpenMCL support using the Linux/AMD64 snapshots with Unicode
support, so probably those two combinations will be good enough to
reproduce the issues you are seeing.)

> I think what's happening here is that the feature rune-is-integer is not
> yet defined when cxml.asd is loaded. So the system definition cxml-dom
> is defined incorrectly. Only *after* cxml.asd is loaded, we load
> rune.asd, which is where rune-is-integer is defined. When I touch
> cxml.asd, it is reloaded and things work fine as rune-is-integer is now
> correctly defined. Splitting rune.asd and cxml.asd is currently clearly
> not working.

Right.  I'll either go back to one common .asd file or hack an explicit
call to (asdf:find-system :runes) at the top of cxml.asd.  Not sure what
the latter method means for packaging tools that want to parse .asd
files though.


d.



More information about the cxml-devel mailing list