From rwiker at gmail.com Wed Feb 22 20:51:56 2012 From: rwiker at gmail.com (Raymond Wiker) Date: Wed, 22 Feb 2012 21:51:56 +0100 Subject: [xuriella-devel] Xuriella vs Lispworks In-Reply-To: <25EC9751-97A1-425B-82E0-00E59A4F30E2@gmail.com> References: <25EC9751-97A1-425B-82E0-00E59A4F30E2@gmail.com> Message-ID: <03C7BB4B-B746-4E3B-9181-4DECACFFD9C8@gmail.com> On Sep 5, 2011, at 21:22 , Raymond Wiker wrote: > I'm mainly using Lispworks, and I've had a few problems getting Xuriella running. Looking at the xuriella-devel archives, I see that Frank Schorr reported this back in November 2009. > > I have been able to get Xuriella to work by changing the order of clauses in the loop in xuriella::report-samples (as suggested by Frank), as well as a little bit of magic[1] that I haven't tried to figure out until now. > > First of all: the loop clause in report-samples. My interpretation of the Hyperspec indicates that the order of clauses used in report-samples > > (loop > for base-uri being each hash-key > using (hash-value id) > in base-uris ? > > 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) > > --- just like Frank suggested. > > The two other issues that Frank reported are *probably* because he was running with lw:*default-character-element-type* set to 'base-char. Doing something like > > (lw:set-default-character-element-type 'character) ;; or lw:simple-char > > before trying to use xuriella (or cxml-stp) appears to do the necessary magic. > > Footnotes: > [1] Possibly just sufficiently advanced technology. 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? Regards, Raymond Wiker From david at lichteblau.com Wed Feb 22 21:03:10 2012 From: david at lichteblau.com (David Lichteblau) Date: Wed, 22 Feb 2012 22:03:10 +0100 Subject: [xuriella-devel] Xuriella vs Lispworks In-Reply-To: <03C7BB4B-B746-4E3B-9181-4DECACFFD9C8@gmail.com> References: <25EC9751-97A1-425B-82E0-00E59A4F30E2@gmail.com> <03C7BB4B-B746-4E3B-9181-4DECACFFD9C8@gmail.com> Message-ID: <20120222210310.GC31394@radon> 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. d. From rwiker at gmail.com Wed Feb 22 21:30:57 2012 From: rwiker at gmail.com (Raymond Wiker) Date: Wed, 22 Feb 2012 22:30:57 +0100 Subject: [xuriella-devel] Xuriella vs Lispworks In-Reply-To: <20120222210310.GC31394@radon> References: <25EC9751-97A1-425B-82E0-00E59A4F30E2@gmail.com> <03C7BB4B-B746-4E3B-9181-4DECACFFD9C8@gmail.com> <20120222210310.GC31394@radon> Message-ID: 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.