Votre Convention collective

soldes jusqu’à -80 % sur UGg, Nike, adidas

*substitution-char* does not suppress external-format-encoding-error

Hello folks,

I have bumped into the following error while playing with Hunchentoot.
(It is originated from url-decoding GET parameters with
 *hunchentoot-default-external-format*.)

(let ((flex:*substitution-char* #\?))
  (flex:octets-to-string #(#xC1 #xC2 #xC3 #xC4) :external-format :utf-8))
=> "??"

(let ((flex:*substitution-char* #\?))
  (flex:octets-to-string #(#xC0 #xC1 #xC2 #xC3 #xC4) :external-format
:utf-8))
-> signals: This sequence can't be decoded using UTF-8 as it is too short.
1
octet missing at then end.

The reason is rather "simple": the decoder invokes the following chain of calls:
  compute-number-of-chars -> check-end -> signal-encoding-error

This contrasts to the most of decoder code, which directly calls
   recover-from-encoding-error
instead of
  signal-encoding-error.
--
Sincerely,
Dmitriy Ivanov
lisp.ystok.ru

unit test failure on sbcl

Hello.

When running asdf:test-op on the flexi-streams 1.0.7 with SBCL some failures occur.

The error message is 

Test (STRING=
      (FLEXI-STREAMS-TEST::OLD-OCTETS-TO-STRING
       FLEXI-STREAMS-TEST::OCTETS-VECTOR :EXTERNAL-FORMAT
       FLEXI-STREAMS-TEST::EXTERNAL-FORMAT)
      STRING) failed signalling error of type TYPE-ERROR: The value 0
                                                          is not of type
                                                            (MEMBER NIL T).

If I comment lines 341, 342 in test.lisp, the error does not occur.

I googled for that error and found a code snippet 
(http://paste.lisp.org/display/73334) which reproduces the
error:

(with-input-from-string (in "123456")
  (let ((stream (flex:make-flexi-stream in))                                                   
        (buffer (make-sequence 'string 3)))
    (read-sequence buffer stream)))

The code is not correct because it creates flexi-stream on top of character but not binary
stream. But the error message is the same, probably it might help you identify the 
reason why the tests fail.

Best regards,
- Anton

My open source libraries (aka "ediware")

[My apologies if you receive multiple copies of this email.]

Hi everybody!

As some of you will know, I'll start on a new job tomorrow.  This new
job won't involve much hacking, if at all, and thus it doesn't look
like I'll have a lot of time to maintain my open source libraries in
the near future.  I have no plans to suddenly disappear from the CL
world, but don't expect new releases of any of my libs any time soon.
(At least none published by me or on my server.)

Luckily, Hans Hübner - who already did most of the maintenance and
development work for Hunchentoot in the last two years or so - offered
to coordinate further development via github.  See his full
announcement at
<http://netzhansa.blogspot.com/2011/08/ediware-moving-to-github.html>.

I'll continue to read the mailing lists for my libs and I'm still
interested in fixing bugs you might find in the release tarballs
available on my web server.  However, I will likely not bother to
discuss or work on new features or compatibility code for
implementations other than LispWorks (which happens to be the one I'm
using).

Lastly, I hope to see a lot of you in Amsterdam
<http://weitz.de/eclm2011/> in October.  The number of registrations
so far has been pretty disappointing, but you still have three weeks
left to change your mind... :)

Take care,
Edi.

Flexi Streams fails to compile and install on MacPorts ECL

_______________________________________________
flexi-streams-devel mailing list
flexi-streams-devel <at> common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/flexi-streams-devel

gbk patch of flexi-streams.

_______________________________________________
flexi-streams-devel mailing list
flexi-streams-devel <at> common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/flexi-streams-devel

gbk patch to flexi-streams.

hi all:
I have put one patch of flexi-streams to github:
This patch has passed all tests and use the new encoding map table.
https://github.com/jingtaozf/flexi-streams

UNREAD-BYTE and PEEK-BYTE on IN-MEMORY-INPUT-STREAM

_______________________________________________
flexi-streams-devel mailing list
flexi-streams-devel <at> common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/flexi-streams-devel

Re: a patch for chineses's cp936(gbk) encoding support.

Thanks, I'll take a look at this when I'm less busy than now.

Again, please use the mailing list for patches and questions - see Cc.

Thanks,
Edi.

On Fri, Feb 5, 2010 at 11:31 AM, jingtaozf <jingtaozf <at> gmail.com> wrote:
> Hi Edi;
>   I have modifed the code to fit your request.and the encode name changed from cp936 to gbk.
>   The following is the response.
>
> 1. There are several new functions and macros which don't have a
> documentation string.
> ==> i have add document to function get-multibyte-mapper,others are referenced with your codes.
> 2. There are tabs in the files and sometimes the indentation seems wrong.
> ==> i have removed tabs.
> 3. There are parts of the code which are commented out.  If they
> aren't used, they shouldn't be in there.
> ==> yes,i deleted them.
> 4. There's at least one file (seems like a variant of the ASDF system
> definition) which shouldn't be in there at all.
> ==>sorry,but i don't know what you mean?
> 5. The link in the HTML documentation is wrong.
> ==>i fixed the url link to gbk.
> 6. Isn't get-multibyte-mapper the wrong name?  You don't get the mapper, do you?
> ==>yes,this function is borrowed from sbcl's source code,and i have pointed out this in the comment.
> 7. And the function itself looks like Scheme to me.  I think it'd be
> easier to understand using normal iteration.
> ==>i have re-write the decode and encode part.but i am not familiar with scheme. :(
> 8. I don't understand why the encoding factor is 1.5.  Is the comment
> correct or just copied?
> ==>i don't know how to set the encoding factor,gbk(cp936) has one or two octets.i set it to 1.5 with my estimate.
> 9. I'm not familiar with CP936.  Is it correct that there's only a
> big-endian version?
> ==>gbk(cp936) has no endian problem, i borrowed code from your utf16's implemention,now i have fixed it.
> 10. One of the new files contains DOS line endings.
> ==> some your source files has DOS line endings(such as ascii.lisp),some use unix line endings.
>      i don't know why and maybe i modified it un-expectly.
>
>
> Fothermore,this patch file is encoded use utf-8,because my test file contains file which is encoded by
gbk format.
> I also put the test files(with gbk format) to the attatchment,because i am not sure the patch will generate
them correctly.
>
> 2010-02-04
>
>
>
> jingtaozf
>
>
>
> 发件人： Edi Weitz
> 发送时间： 2009-10-29  23:08:38
> 收件人： jingtao xu
> 抄送： General interest list about flexi-streams
> 主题： Re: a patch for chineses's cp936(gbk) encoding support.
>
> On Thu, Oct 29, 2009 at 3:17 PM, jingtao xu <jingtaozf <at> gmail.com> wrote:
>> hi,Edi Weitz:
>>    Because i want to use drakma as my web development tool,but it use
>> flexi-streams and could not decode chinese's cp936 characters,so i make  a
>> patch to flexi-streams.
>>
>>    The sbcl has supported cp936(by files supported by beinghe,which cvs path
>> is:sbcl/src/code/external-formats/enc-cn.lisp,enc-cn-tbl.lisp). i use file
>> enc-cn-tbl.lisp here.
>>
>>   The patches is make by following commands:
>>      diff -urN ~/.sbcl/site/flexi-streams-1.0.7/ ~/Downloads/flexi-streams/
>>>flexi-streams-cp936.patch
>>
>>   I send you both the patch files and the patched codes.
>>  The test codes is added and passed.
>>  The documention is updated.
> [I've put the mailing list on Cc where I think we should continue this.]
> First of all, I'd be happy to include this into the flexi-streams
> distribution.  There are a couple of issues with the patch, though.
> What I saw from briefly looking at it:
> 1. There are several new functions and macros which don't have a
> documentation string.
> 2. There are tabs in the files and sometimes the indentation seems wrong.
> 3. There are parts of the code which are commented out.  If they
> aren't used, they shouldn't be in there.
> 4. There's at least one file (seems like a variant of the ASDF system
> definition) which shouldn't be in there at all.
> 5. The link in the HTML documentation is wrong.
> 6. Isn't get-multibyte-mapper the wrong name?  You don't get the mapper, do you?
> 7. And the function itself looks like Scheme to me.  I think it'd be
> easier to understand using normal iteration.
> 8. I don't understand why the encoding factor is 1.5.  Is the comment
> correct or just copied?
> 9. I'm not familiar with CP936.  Is it correct that there's only a
> big-endian version?
> 10. One of the new files contains DOS line endings.
> There's probably more.
> If you could go over these and send a cleaned-up version of the patch,
> I'll review it.  FWIW, here are some guidelines:
>  http://weitz.de/patches.html
> Thanks,
> Edi.
>

_______________________________________________
flexi-streams-devel mailing list
flexi-streams-devel <at> common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/flexi-streams-devel

Flexi-streams problem with SBCL 1.0.34

I found a problem with the flexi-streams:string-to-octets function.  I
was getting the following back-trace when using it:

(ironclad:make-hmac (string-octets key) :sha1)  from zs3:make-digester gives:

The value #(55 98 50 52 104 75 97 65 50 54 ...)
is not of type
 (SIMPLE-ARRAY (UNSIGNED-BYTE 8) (*)).
 [Condition of type TYPE-ERROR]

Restarts:
 0: [DEFAULT-DEBUGGER] Use default debugger.
 1: [ABORT] Return to SLIME's top level.
 2: [TERMINATE-THREAD] Terminate this thread (#<THREAD "repl-thread"
RUNNING {ACA40D1}>)

Backtrace:
 0: ((SB-PCL::FAST-METHOD SHARED-INITIALIZE :AFTER (IRONCLAD::HMAC
T)) #<unavailable argument> #<unavail..
    Locals:
      SB-DEBUG::ARG-0 = 10
      SB-DEBUG::ARG-1 = :<NOT-AVAILABLE>
      SB-DEBUG::ARG-2 = :<NOT-AVAILABLE>
      SB-DEBUG::ARG-3 = #<HMAC(SHA1) {F0DD561}>
      SB-DEBUG::ARG-4 = :<NOT-AVAILABLE>
 1: ((LAMBDA (SB-PCL::|.P0.| SB-PCL::|.P1.| SB-PCL::|.P2.|))
#<unavailable argument> #<unavailable argum..
    Locals:
      SB-DEBUG::ARG-0 = :<NOT-AVAILABLE>
      SB-DEBUG::ARG-1 = :<NOT-AVAILABLE>
      SB-DEBUG::ARG-2 = :<NOT-AVAILABLE>

zs3's string-octets uses flexi-streams:string-to-octets

The workaround I'm using for now is instead going to acl-compat's
string-to-octets function from acl-excl.lisp:

(defun string-to-octets (string &key (null-terminate t) (start 0)
                       end mb-vector make-mb-vector?
                       (external-format :default))
 "This function returns a lisp-usb8-vector and the number of bytes copied."
 (declare (ignore external-format))
 ;; The end parameter is different in ACL's lambda list, but this
 ;; variant lets us give an argument :end nil explicitly, and the
 ;; right thing will happen
 (unless end (setf end (length string)))
 (let* ((number-of-octets (if null-terminate (1+ (- end start))
                             (- end start)))
       (mb-vector (cond
                    ((and mb-vector (>= (length mb-vector) number-of-octets))
                     mb-vector)
                    ((or (not mb-vector) make-mb-vector?)
                     (make-array (list number-of-octets)
                                 :element-type '(unsigned-byte 8)
                                 :initial-element 0))
                    (t (error "Was given a vector of length ~A, ~
                               but needed at least length ~A."
                              (length mb-vector) number-of-octets)))))
  (declare (type (simple-array (unsigned-byte 8) (*)) mb-vector))
  (loop for from-index from start below end
     for to-index upfrom 0
     do (progn
          (setf (aref mb-vector to-index)
                (char-code (aref string from-index)))))
  (when null-terminate
    (setf (aref mb-vector (1- number-of-octets)) 0))
  (values mb-vector number-of-octets)))

which seems to work fine.

My best,

Fred Gibson

Founder / Software Developer
http://www.streamfocus.com

(c)2010 Organon Technologies LLC