[drakma-devel] CLISP problem with READ-SEQUENCE; patch
Hello. When using HTTP-REQUEST for non text content types, we have following error in CLISP: SYSTEM::STORE: #\< does not fit into #(0 0 0 0 0 0 0 0 0 0 ...), bad type Backtrace: 0: INVOKE-DEBUGGER 1: SYSTEM::STORE 2: EXT:READ-CHAR-SEQUENCE 3: READ-SEQUENCE 4: DRAKMA::READ-BODY 5: DRAKMA::HTTP-REQUEST-FINISH-REQUEST 6: unwind-protect frame 7: compiled block frame for HTTP-REQUEST 8: HTTP-REQUEST This is because CLISP doesn't support READ-SEQUENCE on a stream having STREAM-ELEMENT-TYPE == 'CHARACTER. The patch attached fixes this problem by explicit change of stream element type in the DRAKMA::READ-BODY function. Test URLs: http://www.google.com/calendar/feeds/pm55j8kg30dnm54ib2if9fuocc@group.calend... http://www.lisperati.com/lisplogo_alien_128.png Best regards, -- Anton
On Sat, 22 Mar 2008 00:12:26 +0200, Anton Vodonosov <avodonosov@yandex.ru> wrote:
This is because CLISP doesn't support READ-SEQUENCE on a stream having STREAM-ELEMENT-TYPE == 'CHARACTER.
Isn't that a bug which should be reported to the CLISP maintainers?
The patch attached fixes this problem by explicit change of stream element type in the DRAKMA::READ-BODY function.
Thanks. Applied.
On Sat, 22 Mar 2008 0:42:37 Edi Weitz wrote:
On Sat, 22 Mar 2008 00:12:26 +0200, Anton Vodonosov <avodonosov@yandex.ru> wrote:
This is because CLISP doesn't support READ-SEQUENCE on a stream having STREAM-ELEMENT-TYPE == 'CHARACTER.
Isn't that a bug which should be reported to the CLISP maintainers?
From my personal point of view it would be better to just implement generic STREAM-READ-SEQUENCE in CLISP, as it is done in most of other CL implementations; I event suggested a patch (which is
Strictly speaking it's not a bug. CLHS even says that READ-SEQUENCE "Might signal an error of type type-error if an element read from the stream is not a member of the element type of the sequence." For WRITE-STREAM event worse, it explicitly mention stream element type: "Might signal an error of type type-error if an element of the bounded sequence is not a member of the stream element type of the stream." Drakma relies on FLEXI-STREAMS in hope that FLEXI-STREAMS:STREAM-READ-SEQUENCE will handle it gracefully, but the problem is that it is not called at all. Function STREAM-READ-SEQUENCE is not included into Gray streams proposal (I guess because READ-SEQUENCE itself wasn't part of the standard draft at the time when the proposal was made, at least it's absent in CLTL2). trivial-gray-streams tries to emulate STREAM-READ-SEQUENCE based on more limited CLISP's STREAM-READ-BYTE-SEQUENCE, but this doesn't work in all situations. trivial). But CLISP maintainers weren't too enthusiastic about that. Maybe I must pressurize them, to the coming generations good. Regards, -- Anton
On Sat, 22 Mar 2008 01:31:55 +0200, Anton Vodonosov <avodonosov@yandex.ru> wrote:
From my personal point of view it would be better to just implement generic STREAM-READ-SEQUENCE in CLISP, as it is done in most of other CL implementations;
Right, I agree.
I event suggested a patch (which is trivial). But CLISP maintainers weren't too enthusiastic about that.
Hmmm...
"Anton Vodonosov" <avodonosov@yandex.ru> wrote in message news:1778416840.20080322001226@yandex.ru...
Hello.
When using HTTP-REQUEST for non text content types, we have following error in CLISP:
SYSTEM::STORE: #\< does not fit into #(0 0 0 0 0 0 0 0 0 0 ...), bad type
[snipped Backtrace]
This is because CLISP doesn't support READ-SEQUENCE on a stream having STREAM-ELEMENT-TYPE == 'CHARACTER.
The patch attached fixes this problem by explicit change of stream element type in the DRAKMA::READ-BODY function.
That's odd, I've been using clisp + drakma for months on streams which are a mixture of ASCII and binary without problems. /me checks something. Aha! I took a somewhat longer approach and mucked around with system::read-sequence and system::write-sequence to prefer byte-sequences over character-sequences (see attached). Never made a patch to CLISP because I figured it wasn't the right solution so much as something that happens to work for my particular application. I like your way better! :) begin 666 clisp-fix.lisp M.SL@26X@8VQI<W L(')E860M<V5Q=65N8V4@86YD('=R:71E+7-E<75E;F-E M('=I;&P@=')Y('1O(')E860@;W(@=W)I=&4*.SL@8VAA<F%C=&5R<R!E=F5N M('=H96X@>6]U(')E86QL>2!W86YT(&EN=&5G97)S+B!";&5H(2!&:7@@=&AI M<R!B>2!S=V%P<&EN9PH[.R!S;VUE(&-O;F1I=&EO;G,@87)O=6YD+B!%<W-E M;G1I86QL>2P@<F5V97)S92!T:&4@8G5G('1O('!R969E<B!I;G1E9V5R<PH[ M.R!O=F5R(&-H87)A8W1E<G,L('-I;F-E('1H870G<R!P<F]B86)L>2!W:&%T M('=E('=A;G1E9"!A;GEW87DN"CL[("A!(&QI='1L92!A<'!L:6-A=&EO;BUS M<&5C:69I8R!K;F]W;&5D9V4@9V]E<R!A(&QO;F<@=V%Y+BD*"BAI;BUP86-K M86=E(#IS>7-T96TI"@HH97AT.G=I=&AO=70M<&%C:V%G92UL;V-K("@I"B @ M*&1E9G5N('-Y<W1E;3HZ<F5A9"US97%U96YC92 H<V5Q=65N8V4@<W1R96%M M("9R97-T(')E<W0@)FME>2 H<W1A<G0@,"D@*&5N9"!N:6PI*0H@(" @*&1E M8VQA<F4@*&EG;F]R92!S=&%R="!E;F0I*0H@(" @*&QE=" H*'-E;'1Y<&4@ M*'-T<F5A;2UI;G!U="UE;&5M96YT+71Y<&4@<W1R96%M*2D*(" @(" @(" @ M("AV96QT>7!E("AI9B H=F5C=&]R<"!S97%U96YC92D@*&%R<F%Y+65L96UE M;G0M='EP92!S97%U96YC92D@="DI*0H@(" @(" H8V]N9" H*&]R("AS=6)T M>7!E<"!S96QT>7!E("=)3E1%1T52*2 H<W5B='EP97 @=F5L='EP92 G24Y4 M14=%4BDI"B @(" @(" @(" @(" H87!P;'D@(R=R96%D+6)Y=&4M<V5Q=65N M8V4@<V5Q=65N8V4@<W1R96%M(')E<W0I*0H@(" @(" @(" @(" H*&]R("AE M<2!S96QT>7!E("=.24PI("AE<2!S96QT>7!E("=#2$%204-415(I"B @(" @ M(" @(" @(" @(" @*&5Q('9E;'1Y<&4@)T-(05)!0U1%4BDI"B @(" @(" @ M(" @(" H87!P;'D@(R=R96%D+6-H87(M<V5Q=65N8V4@<V5Q=65N8V4@<W1R M96%M(')E<W0I*0H@(" @(" @(" @(" H= H@(" @(" @(" @(" @*&5R<F]R M("A415A4(")^4SH@96QE;65N="!T>7!E<R!O9B!^4R!A;F0@?E,@87)E(&%M M8FEG=6]U<RX@4&QE87-E('5S92!^4R!O<B!^4RXB*0H@(" @(" @(" @(" @ M(" @(" @("=R96%D+7-E<75E;F-E('-E<75E;F-E('-T<F5A;0H@(" @(" @ M(" @(" @(" @(" @("=R96%D+6-H87(M<V5Q=65N8V4@)W)E860M8GET92US M97%U96YC92DI*2DI"B H9&5F=6X@<WES=&5M.CIW<FET92US97%U96YC92 H M<V5Q=65N8V4@<W1R96%M("9R97-T(')E<W0@)FME>2 H<W1A<G0@,"D@*&5N M9"!N:6PI*0H@(" H9&5C;&%R92 H:6=N;W)E('-T87)T(&5N9"DI"B @("AL M970@*"AS96QT>7!E("AS>7-T96TZ.G-T<F5A;2UO=71P=70M96QE;65N="UT M>7!E('-T<F5A;2DI"B @(" @(" @("AV96QT>7!E("AI9B H=F5C=&]R<"!S M97%U96YC92D@*&%R<F%Y+65L96UE;G0M='EP92!S97%U96YC92D@="DI*0H@ M(" @("AC;VYD("@H;W(@*'-U8G1Y<&5P('-E;'1Y<&4@)TE.5$5'15(I("AS M=6)T>7!E<"!V96QT>7!E("=)3E1%1T52*2D*(" @(" @(" @(" @.SL@8'=R M:71E+6)Y=&4M<V5Q=65N8V4G(&%C8V5P=',@.DY/+4A!3D<@86YD(')E='5R M;G,@86X@97AT<F$@=F%L=64*(" @(" @(" @(" @.SL@<VEN8V4@;6%K:6YG M(&!W<FET92UC:&%R+7-E<75E;F-E)R!D;R!T:&4@<V%M92!W;W5L9"!B92!H M86ER>2P*(" @(" @(" @(" @.SL@=V4@:6=N;W)E('1H:7,@<V5C;VYD(')E M='5R;B!V86QU92!F;W(@=&AE('-A:V4@;V8@04Y320H@(" @(" @(" @(" H M=F%L=65S("AA<'!L>2 C)W-Y<W1E;3HZ=W)I=&4M8GET92US97%U96YC92!S M97%U96YC92!S=')E86T@<F5S="DI*0H@(" @(" @(" @("@H;W(@*&5Q('-E M;'1Y<&4@)TY)3"D@*&5Q('-E;'1Y<&4@)T-(05)!0U1%4BD*(" @(" @(" @ M(" @(" @("AE<2!V96QT>7!E("=#2$%204-415(I*0H@(" @(" @(" @(" H M87!P;'D@(R=S>7-T96TZ.G=R:71E+6-H87(M<V5Q=65N8V4@<V5Q=65N8V4@ M<W1R96%M(')E<W0I*0H@(" @(" @(" @("AT"B @(" @(" @(" @("AE<G)O M<B H5$585" B?E,Z(&5L96UE;G0@='EP97,@;V8@?E,@86YD('Y3(&%R92!A M;6)I9W5O=7,N(%!L96%S92!U<V4@?E,@;W(@?E,N(BD*(" @(" @(" @(" @ M(" @(" @("=W<FET92US97%U96YC92!S97%U96YC92!S=')E86T*(" @(" @ M(" @(" @(" @(" @("=W<FET92UC:&%R+7-E<75E;F-E("=W<FET92UB>71E 0+7-E<75E;F-E*2DI*2DI"@`` ` end
Pixel wrote:
Aha! I took a somewhat longer approach and mucked around with system::read-sequence and system::write-sequence to prefer byte-sequences over character-sequences (see attached).
Good idea. I wasn't aware that it is possible to redefine system functions. At first sight this way it may be possible to fix trivial-gray-stream so that trivial-gray-streams:stream-read-sequence will always be called by cl:read-sequence and therefore eliminate all #+clisp in all trivial-gray-streams depended libraries.
Hello. Good news, CLISP CVS now has GRAY:STREAM-READ-SEQUENCE and GRAY:STREAM-WRITE-SEQUENCE. http://sourceforge.net/mailarchive/forum.php?thread_name=47E6C701.6030004%40gnu.org&forum_name=clisp-devel Only small update of trivial-gray-streams remains to be done. -Anton
participants (3)
-
Anton Vodonosov -
Edi Weitz -
Pixel // pinterface