[flexi-streams-devel] Flexi-streams test suite failing on OpenMCL
Hi-- The flexi-streams test suite is failing on OpenMCL "Version 1.0 (DarwinPPC32)" on Test "hebrew_utf8_lf.txt" (:UTF-8 :EOL-STYLE :LF) [INPUT] --> (:UTF-8 :EOL-STYLE :LF) [OUTPUT]. I think this is also preventing Hunchentoot from working on recent OpenMCL versions Backtrace: 0: (#<STANDARD-METHOD STREAM-READ-CHAR (FLEXI-STREAMS::FLEXI-UTF-8-INPUT-STREAM)> #<FLEXI-STREAMS::FLEXI-UTF-8-INPUT-STREAM #x8800FAE>) 1: (READ-CHAR #<FLEXI-STREAMS::FLEXI-UTF-8-INPUT-STREAM #x8800FAE>) 2: (CCL::GENERIC-READ-LINE #<FLEXI-STREAMS::FLEXI-UTF-8-INPUT-STREAM #x8800FAE>) 3: (READ-LINE #<FLEXI-STREAMS::FLEXI-UTF-8-INPUT-STREAM #x8800FAE>) 4: (FLEXI-STREAMS-TEST::COPY-STREAM #<FILE-BINARY-INPUT-STREAM ("home:src;site;flexi-streams-0.11.2;test;hebrew_utf8_lf.txt"/14) #x8801956> #<EXTERNAL-FORMAT (:UTF-8 :EOL-STYLE :LF) #x86F703E> #<FILE-BINARY-OUTPUT-STREAM ("/tmp/flexi-streams-test/hebrew_utf8_lf.txt"/17) #x8801296> #<EXTERNAL-FORMAT (:UTF-8 :EOL-STYLE :LF) #x86F703E>) 5: (FLEXI-STREAMS-TEST::COPY-FILE #P"home:src;site;flexi-streams-0.11.2;test;hebrew_utf8_lf.txt" #<EXTERNAL-FORMAT (:UTF-8 :EOL-STYLE :LF) #x86F703E> #P"/tmp/flexi-streams-test/hebrew_utf8_lf.txt" #<EXTERNAL-FORMAT (:UTF-8 :EOL-STYLE :LF) #x86F703E> ':OUTPUT ':INPUT) 6: (FLEXI-STREAMS-TEST::COMPARE-FILES "hebrew_utf8_lf.txt" "hebrew_utf8_lf.txt" '((#1="hebrew_utf8_lf.txt" #2=#<EXTERNAL-FORMAT (:UTF-8 :EOL-STYLE :LF) #x86F703E> "hebrew_utf8_cr.txt" #<EXTERNAL-FORMAT (:UTF-8 :EOL-STYLE :CR) #x86F6FFE>) (#1# #2# "hebrew_utf8_crlf.txt" #<EXTERNAL-FORMAT (:UTF-8 :EOL-STYLE :CRLF) #x86F6FBE>) (#1# #2# "hebrew_latin8_lf.txt" #<EXTERNAL-FORMAT (:ISO-8859-8 :EOL-STYLE :LF) #x86F6F7E>) (#1# #2# "hebrew_latin8_cr.txt" #<EXTERNAL-FORMAT (:ISO-8859-8 :EOL-STYLE :CR) #x86F6F3E>) ..))) '(#1="hebrew_utf8_lf.txt" ..) 7: (FLEXI-STREAMS-TEST::RUN-TESTS) 8: (CCL::%%BEFORE-AND-AFTER-COMBINED-METHOD-DCODE '(NIL #<STANDARD-METHOD ASDF:PERFORM (ASDF:TEST-OP (EQL #<SYSTEM "flexi-streams" #x84933B6>))> . 5339982)) 9: (CCL::%%STANDARD-COMBINED-METHOD-DCODE '(#<RESTART ASDF:RETRY #x14EFA36> #<RESTART ASDF:ACCEPT #x14EFA5E>) #<RESTART ASDF:RETRY #x14EFA36>) 10: (ASDF:OPERATE 'ASDF:TEST-OP ':FLEXI-STREAMS) 11: (CCL::CALL-CHECK-REGS 'ASDF:OOS) 12: (SWANK::EVAL-REGION "(asdf:oos 'asdf:test-op :flexi-streams) " 'T) 13: (#<Anonymous Function #x845173E> "(asdf:oos 'asdf:test-op :flexi-streams) ") 14: (SWANK::CALL-WITH-BUFFER-SYNTAX #<COMPILED-LEXICAL-CLOSURE #x86F1C26>) 15: (SWANK:LISTENER-EVAL "(asdf:oos 'asdf:test-op :flexi-streams) ") 16: (CCL::CALL-CHECK-REGS 'SWANK:LISTENER-EVAL) 17: (#<Anonymous Function #x843A05E> '(SWANK:LISTENER-EVAL "(asdf:oos 'asdf:test-op :flexi-streams) ") 16 "COMMON-LISP-USER") 18: (#<Anonymous Function #x83C9086> #<Compiled-function SWANK:SWANK-DEBUGGER-HOOK #x845050E> #<COMPILED-LEXICAL-CLOSURE #x86F1C46>) 19: (FUNCALL 'SWANK::EVAL-FOR-EMACS) 20: (#<Anonymous Function #x841943E>) 21: (#<Anonymous Function #x83C9086> #<Compiled-function SWANK:SWANK-DEBUGGER-HOOK #x845050E> #<Anonymous Function #x841943E>) 22: (SWANK::CALL-WITH-REDIRECTED-IO #<COMPILED-LEXICAL-CLOSURE #x86F1C66> #<CONNECTION #x848243E>) 23: (SWANK::CALL-WITH-CONNECTION #<CONNECTION #x848243E> #<Anonymous Function #x841943E>) 24: (SWANK::HANDLE-REQUEST #<CONNECTION #x848243E>) 25: (SWANK::REPL-LOOP 'NIL) 26: (SWANK::CALL-WITH-BINDINGS 'NIL #<COMPILED-LEXICAL-CLOSURE #x8484A3E>) 27: (CCL::RUN-PROCESS-INITIAL-FORM '(#<COMPILED-LEXICAL-CLOSURE #x847DB86>) #<PROCESS repl-thread(5) [Active] #x847DBBE>) 28: (#<Anonymous Function #x80DB61E> '(#<COMPILED-LEXICAL-CLOSURE #x847DB86>) 0) 29: (#<Anonymous Function #x80CE806> 788576 #<LISP-THREAD repl-thread [tcr @ #x302180] #x847DCAE>)
On Mon, 21 May 2007 21:32:45 +0100, "Tiarnan O'Corrain" <ocorrain@gmail.com> wrote:
The flexi-streams test suite is failing on OpenMCL "Version 1.0 (DarwinPPC32)" on
Test "hebrew_utf8_lf.txt" (:UTF-8 :EOL-STYLE :LF) [INPUT] --> (:UTF-8 :EOL-STYLE :LF) [OUTPUT].
Unfortunately, I don't have a Mac to investigate this, so we'll have to look if someone else wants to try their luck. Do you have at least an error message?
I think this is also preventing Hunchentoot from working on recent OpenMCL versions
Yes, I think so.
Hi Edi-- the error message is value 1509 is not of the expected type (UNSIGNED-BYTE 8). [Condition of type TYPE-ERROR] If you'd like me to try anything, or could point to an area of investigation, let me know regards Tiarnán On 5/21/07, Edi Weitz <edi@agharta.de> wrote:
On Mon, 21 May 2007 21:32:45 +0100, "Tiarnan O'Corrain" <ocorrain@gmail.com> wrote:
The flexi-streams test suite is failing on OpenMCL "Version 1.0 (DarwinPPC32)" on
Test "hebrew_utf8_lf.txt" (:UTF-8 :EOL-STYLE :LF) [INPUT] --> (:UTF-8 :EOL-STYLE :LF) [OUTPUT].
Unfortunately, I don't have a Mac to investigate this, so we'll have to look if someone else wants to try their luck. Do you have at least an error message?
I think this is also preventing Hunchentoot from working on recent OpenMCL versions
Yes, I think so. _______________________________________________ flexi-streams-devel mailing list flexi-streams-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/flexi-streams-devel
On Mon, 21 May 2007 22:40:56 +0100, "Tiarnan O'Corrain" <ocorrain@gmail.com> wrote:
the error message is
value 1509 is not of the expected type (UNSIGNED-BYTE 8). [Condition of type TYPE-ERROR]
If you'd like me to try anything, or could point to an area of investigation, let me know
Hmm, and this happens in the STREAM-READ-CHAR method? Could you try to figure out what part of the program generates the 1509?
Hi Edi-- the SLIME inspector gives me this for the flexi-stream, and 1509=0x05e5 which is "HEBREW LETTER FINAL TSADI". It looks like OpenMCL is attempting to read unicode rather than raw bytes. Hmm... An object. [type: FLEXI-STREAMS::FLEXI-UTF-8-INPUT-STREAM] -------------------- Class: #<STANDARD-CLASS FLEXI-STREAMS::FLEXI-UTF-8-INPUT-STREAM> -------------------- All Slots: CLOSED = NIL [set value] [make unbound] DIRECTION = :INPUT [set value] [make unbound] ELEMENT-TYPE = CHARACTER [set value] [make unbound] EXTERNAL-FORMAT = #<EXTERNAL-FORMAT (:UTF-8 :EOL-STYLE :LF) #x8522FFE> [set value] [make unbound] LAST-CHAR-CODE = 1509 [set value] [make unbound] LAST-OCTET = NIL [set value] [make unbound] OCTET-STACK = NIL [set value] [make unbound] POSITION = 3 [set value] [make unbound] SHARED-RESOURCE = NIL [set value] [make unbound] STREAM = #<FILE-BINARY-INPUT-STREAM ("home:src;site;flexi-streams-0.11.2;test;hebrew_utf8_lf.txt"/8) #x856FC86> [set value] [make unbound] regards Tiarnán
On Tue, 22 May 2007 19:13:10 +0100, "Tiarnan O'Corrain" <ocorrain@gmail.com> wrote:
the SLIME inspector gives me this for the flexi-stream, and 1509=0x05e5 which is "HEBREW LETTER FINAL TSADI". It looks like OpenMCL is attempting to read unicode rather than raw bytes. Hmm...
An object. [type: FLEXI-STREAMS::FLEXI-UTF-8-INPUT-STREAM] -------------------- Class: #<STANDARD-CLASS FLEXI-STREAMS::FLEXI-UTF-8-INPUT-STREAM> -------------------- All Slots: CLOSED = NIL [set value] [make unbound] DIRECTION = :INPUT [set value] [make unbound] ELEMENT-TYPE = CHARACTER [set value] [make unbound] EXTERNAL-FORMAT = #<EXTERNAL-FORMAT (:UTF-8 :EOL-STYLE :LF) #x8522FFE> [set value] [make unbound] LAST-CHAR-CODE = 1509 [set value] [make unbound] LAST-OCTET = NIL [set value] [make unbound] OCTET-STACK = NIL [set value] [make unbound] POSITION = 3 [set value] [make unbound] SHARED-RESOURCE = NIL [set value] [make unbound] STREAM = #<FILE-BINARY-INPUT-STREAM ("home:src;site;flexi-streams-0.11.2;test;hebrew_utf8_lf.txt"/8) #x856FC86> [set value] [make unbound]
Very strange. Could you confirm in the inspector that the underlying stream is really a binary stream with element type (UNSIGNED-BYTE 8)? And (using the debugger - I think, IIRC, you press v on the top frame) could you try to find the exact place where the error occurs? Thanks, Edi.
Hi--
Very strange. Could you confirm in the inspector that the underlying stream is really a binary stream with element type (UNSIGNED-BYTE 8)?
Here's the description of the underlying stream from the slime inspector -- I can't inspect this stream itself in slime... #<FILE-BINARY-INPUT-STREAM ("home:src;site;flexi-streams-0.11.2;test;hebrew_utf8_lf.txt"/10) #x8557786> Class: #<STANDARD-CLASS CCL::FILE-BINARY-INPUT-STREAM> Wrapper: #<CCL::CLASS-WRAPPER CCL::FILE-BINARY-INPUT-STREAM #x810DDF6> Instance slots CCL::DIRECTION: :INPUT CCL::CLOSED: NIL CCL::SHARED-RESOURCE: NIL CCL::IOBLOCK: #S(CCL::FILE-IOBLOCK :STREAM #<FILE-BINARY-INPUT-STREAM ("home:src;site;flexi-streams-0.11.2;test;hebrew_utf8_lf.txt"/10) #x8557786> :UNTYI-CHAR NIL :INBUF #<IO-BUFFER (UNSIGNED-BYTE 8) 3/2048/2048 #x85576F6> :OUTBUF NIL :ELEMENT-TYPE (INTEGER 0 255) :ELEMENT-SHIFT 0 :CHARPOS 0 :DEVICE 10 :ADVANCE-FUNCTION CCL::INPUT-FILE-IOBLOCK-ADVANCE ..) CCL::ELEMENT-TYPE: (INTEGER 0 255) CCL::FILENAME: "home:src;site;flexi-streams-0.11.2;test;hebrew_utf8_lf.txt" CCL::ACTUAL-FILENAME: NIL CCL::EXTERNAL-FORMAT: :BINARY
And (using the debugger - I think, IIRC, you press v on the top frame) could you try to find the exact place where the error occurs?
the error is occurring in input.lisp, when stream-read-char is called from compare-files in test.lisp. regards Tiarnán
On Tue, 22 May 2007 22:22:13 +0100, "Tiarnan O'Corrain" <ocorrain@gmail.com> wrote:
Here's the description of the underlying stream from the slime inspector -- I can't inspect this stream itself in slime...
That looks correct.
And (using the debugger - I think, IIRC, you press v on the top frame) could you try to find the exact place where the error occurs?
the error is occurring in input.lisp, when stream-read-char is called from compare-files in test.lisp.
No, I meant where /in/ STREAM-READ-CHAR. Doesn't SLIME locate a particular form in the function's definition? (Maybe it can't due to the macrology, dunno.) Thanks, Edi.
On Mon, 21 May 2007 21:32:45 +0100, "Tiarnan O'Corrain" <ocorrain@gmail.com> wrote:
The flexi-streams test suite is failing on OpenMCL "Version 1.0 (DarwinPPC32)" on
Test "hebrew_utf8_lf.txt" (:UTF-8 :EOL-STYLE :LF) [INPUT] --> (:UTF-8 :EOL-STYLE :LF) [OUTPUT].
FWIW, I just borrowed my wife's iBook (PPC, OS X 10.3) for a couple of minutes and tried with OpenMCL Version 1.1 Prerelease 070512 (PPC-32). The test suite ran without problems for me. Could you check if it works for you as well?
I think this is also preventing Hunchentoot from working on recent OpenMCL versions
In the meantime, I've come to think this is another issue. I also had the problems others reported and the error message was something about some stream being "private" to some process. But I don't have enough time to dig into this, so if nobody steps up to resolve the issues with OpenMCL, I'll remove OpenMCL support from Hunchentoot for now.
Hi Edi--
I don't have enough time to dig into this, so if nobody steps up to resolve the issues with OpenMCL, I'll remove OpenMCL support from Hunchentoot for now.
The nuclear option? I recall hunchentoot working on OpenMCL a few months ago -- I was using it for some development (deployment to be on FreeBSD/cmucl), without any problems. Then the Mac got sick for a while, and when I got it back, hunchentoot was broken. The unfortunate upshot of this (for me, at least), is that hunchentoot will no longer be deployable on a free Mac lisp, as SBCL/Mac doesn't have threading, and CMUCL/Mac is missing the multiprocessing package. I'll try it out on the version you suggested later on today -- I'm using Mac OS X 10.4, so perhaps that has something to do with it. Another possibility would be to ask Gary Byers on the OpenMCL mailing list -- I'll do that when I get a chance to look at the problem in more detail. Thanks, Tiarnán
On Wed, 23 May 2007 11:12:36 +0100, "Tiarnan O'Corrain" <ocorrain@gmail.com> wrote:
The nuclear option?
Yes. I don't necessarily /want/ to do that, but I can't test and maintain an OpenMCL version, so we either need someone who takes care of that or we'd better be honest and don't purport to support OpenMCL.
I recall hunchentoot working on OpenMCL a few months ago -- I was using it for some development (deployment to be on FreeBSD/cmucl), without any problems. Then the Mac got sick for a while, and when I got it back, hunchentoot was broken.
Are you still using the same OpenMCL version you used at that time?
I'll try it out on the version you suggested later on today -- I'm using Mac OS X 10.4, so perhaps that has something to do with it. Another possibility would be to ask Gary Byers on the OpenMCL mailing list -- I'll do that when I get a chance to look at the problem in more detail.
OK, I'll wait for that.
participants (2)
-
Edi Weitz -
Tiarnan O'Corrain