Issue with SBCL 1.0.51 on MacOS and Lispworks on MacOS

[kraison]

I am getting this error when trying to load unicly on MacOS with the latest SBCL;

decoding error on stream

<SB-SYS:FD-STREAM

for "file /Users/raison/work/unicly/unicly-class.lisp" {1002ADAA81}> (:EXTERNAL-FORMAT :ASCII): the octet sequence (226) cannot be decoded. [Condition of type SB-INT:STREAM-DECODING-ERROR]

And in Lispworks, I get:

*++++ Error in (SUBFUNCTION (DEFCLASS UNICLY::UUID-SLOT-UNBOUND-ERROR) (DEFINE-CONDITION UNICLY::UUID-SLOT-UNBOUND-ERROR)): bad slot specification (:NAME :UUID-SLOT-UNBOUND-NAME :READERS (UUID-SLOT-UNBOUND-NAME) :INITARGS (:UUID-SLOT-UNBOUND-NAME)) ; ** 1 error detected, no fasl file produced.

How is your environment setup? Is there something in your .sbclrc file that will help SBCL with the UTF-8 formatted .lisp files?

Thanks, Kevin

[kraison]

FYI: sbcl 1.0.51 on Linux does not suffer from this issue.

[mon-key]

Sorry about the delay in responding. I will look further into this. It may be that w/ SBCL I need to add a reader conditional which tests for sb-unicode.

Also, yes I have the following in my ~/.sbclrc

#+sbcl (unless (eq sb-impl::default-external-format :UTF-8) (setf sb-impl::default-external-format :UTF-8))

I recall that danlentz may have encountered similar issues this past Spring when building an earlier version of Unicly. I believe he was working on a Mac as well. Maybe I should include some additional tests/conditionals w/r/t cl:features.

Thank you for trying Unicly w/ Lispworks! I have not yet made an effort to test Unicly on Lispworks. It may be that Lispworks treatment of conditions is different than SBCL's. IIRC the spec w/r/t internal implementation of conditions was left fairly open.
Maybe the locus is somewhere around this:

,---- From the dpans3r of the ANSI spec: | Whether a user-defined condition type has slots that are accessible by | with-slots is implementation-dependent. Furthermore, even in an | implementation in which user-defined condition types would have slots, | it is implementation-dependent whether any condition types defined in | this document have such slots or, if they do, what their names might be; | only the reader functions documented by this specification may be relied | upon by portable code. `----

I can confirm that on a Linux systems current Unicly will build with both SBCL 1.47+ (assuming a UTF-8 aware SBCL) and Clisp 2.49. (as of this past Friday 2011-09-09)

In the hopes that others might find this issue relevant I will post follow-ups here first. Thanks in advance for using the github interface for reporting this issue.

Likely I should instantiate a common-lisp.net project for Unicly -- I will let you know if/when I am able to do so.

[mon-key]

Also, it may be worth noting that SBCL (at least on Linux) takes its defaults for procedures which accept an :EXTERNAL-FORMAT keyword from the LOCALE and/or LC_CTYPE environment variable.... I'm not sure how applicable this may be for Macs.

In any event, I commented on a recent SBCL want request: "wanted: sb-ext:default-external-format" https://bugs.launchpad.net/sbcl/+bug/727622

Personally, I'm not particularly comfortable/fond of the whole set "LC_CTYPE=foo" thing b/c I don't believe this to be a sane solution for SBCLs operating in a strongly networked environment. Regardless, SBCL guru jsnell was pretty adamant that frobbing LC_CTYPE is in fact the sane solution and one not likely to change anytime soon :{

FWIW following URL will return a list of similar bugs/wanted items related to SBCL's :EXTERNAL-FORMAT:

https://bugs.launchpad.net/sbcl/+bugs?field.searchtext=external-format&orderby=-datecreated&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_package=

[mon-key]

So, AFAICT the SB-INT:STREAM-DECODING-ERROR on MacOS with the latest SBCL has to do with my use of the three UTF-8 character sequence at the end of each "▶▶▶" e.g.:

SBCL> (code-char #x25B6) => #\BLACK_RIGHT-POINTING_TRIANGLE

The first of these occur in the docstring of the generic `uuid-print-bit-vector' in unicly/unicly.class

When the compiler hits the first "▶" it bails.

I'm able to reproduce the error that you got by:

(setf sb-impl::default-external-format :ASCII)

Please can you verify if this is the problem by doing:

(setf sb-impl::default-external-format :ASCII)

(defun will-not-compile () #.(format nil "Compiling this form should fail when EXTERNAL-FORMAT is not :UTF-8.~%▶▶▶"))

(setf sb-impl::default-external-format :UTF-8)

(defun will-not-compile () #.(format nil "Compiling this form should succeed as EXTERNAL-FORMAT :UTF-8.~%▶▶▶"))

In the interim, I've removed the offending "▶▶▶" but I'm not sure this will fix the underlying problem, e.g. when the underlying lisp implementation defaults its default-external-format to something which will violate the protocol that the Unicly library establishes around uuid-string-to-sha1-byte-array' and uuid-string-to-md5-byte-array'.

[mon-key]

I've fixed the error you were getting on Lispworks. Unfortunately Unicly still won't build on Lispworks for various other reasons. Patches welcome :)

[mon-key]

As of tag sbcl1.47+lw6-clisp2.49 I'm now able to build Unicly on LispWorks 6 Personal Edition on x86-32 Linux. With no guarantees as to whether everything is 100% Kosher :)

[kraison]

I will put it on my todo list to test out Lispworks Pro on the Mac. Thanks for working on it!

-K

On 09/13/2011 03:53 PM, mon-key wrote:

As of tag sbcl1.47+lw6-clisp2.49 I'm now able to build Unicly on LispWorks 6 Personal Edition on x86-32 Linux. With no guarantees as to whether everything is 100% Kosher :)