Hi,
Quoting Sunil Mishra (smishra@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.