[xuriella-devel] Xuriella vs Lispworks

[Raymond Wiker]

On Feb 22, 2012, at 22:03 , David Lichteblau wrote:
> Quoting Raymond Wiker (rwiker at gmail.com):
>> On Sep 5, 2011, at 21:22 , Raymond Wiker wrote:
> [...]
>>> is non-conformant; the correct order should be something like 
>>> 
>>> (loop
>>> for base-uri being each hash-key
>>> in base-uris
>>> using (hash-value id)
> [...]
>> It turns out that there was also a bug in Lispworks <= 6.0, where
>> literal strings in compiled code would be treated as strings of
>> 'base-char, regardless of whatever
>> lw:*default-character-element-encoding* had been set to. In Lispworks
>> 6.1 this has been corrected, so the only thing that is required to
>> compile and use Xuriella on Lispworks now is to change the order of
>> two lines in report-samples. Any chance that this can be fixed?
> 
> Thanks.
> Commit pushed to repo.or.cz (other mirrors should update soon); please test.
> 
> Sorry for the delay; LispWorks and its character types have always been
> a source of confusion with cxml, and I wasn't confident regarding that
> change.
> 
> I'm surprised though that you find Xuriella useful as-is on LispWorks:
> 
> While Xuriella itself is meant to be portable code, doesn't Plexippus
> XPath need a trapless IEEE 754 implementation on LispWorks first?  My
> recollection is that the only way to avoid traps and work with NaNs
> and infinities is to use FFI calls...
> 
> Or maybe for real-world code that's not actually required.  However,
> before a Lisp impl can be declared fully supported by Xuriella, we'd
> have to run the test suite, which depends on many floating point corner
> cases IIRC.
> 
Thanks!

I'm using both plexippus-xpath and xuriella  in production code with Lispworks, and haven't noticed any particular issues. I'd be happy to do some work on testing with Lispworks, if that would help.