gmane.lisp.flexi-streams.devel

Votre Convention collective

Michel Deloncle — 2013-04-11T20:31:28

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

Label Only Déstockage — 2013-04-11T09:42:39

LabelOnly01
Si vous ne visualisez pas ce message correctement, 
accédez à la version en ligne
Pour se désabonner, 
suivez ce lien


Pour vous desabonner et ne plus recevoir nos messages, 
recopiez le lien ci-dessous dans barre adresse de votre
navigateur.
http://www.a904-losangeles.fr/prsom/?Y2FtcD1uZXctY2ZhZC1MQUJFTC0xJmRlc3RpZD05NzU1MjE2OCZkZXN0PWZsZXhpLXN0cmVhbXMtZGV2ZWxAY29tbW9uLWxpc3AubmV0JmNsaWVudD0yJnVybD1kZXNhYm8=

Re: substitution-char does not suppressexternal-format-encoding-error

Anton Vodonosov — 2012-02-09T22:25:17

[Sorry, accidentially hit Enter and sent unfinished letter.
 So, once again: ]

To make these two aspects - length calculation and error recovery - consistent,
the following approach may be good:

Length calculation never signals encoding error. Instead, it takes into
account that wrong byte sequences may be replaced by a character,
provided via *substitution-char* or use-value restart. I.e. every wrong
byte sequence is counted as one character.

In decoding process which follows the length calculation two cases
are possible:
1. some error is not recovered (no *substitution-char* provided
   or use-value invoked). The decoding fails completely and it 
   doesn't matter what length was calculated.
2. All the wrong sequences were substituted. In this case
   the length where all the wrong sequences are counted as
   one character exactly matches the need of decoding process.

Unfortunately I can not work on patch for this now and in the near future.

Best regards,
- Anton

10.02.2012, 01:21, "Edi Weitz" <edi< at >a

Re: substitution-char does not suppressexternal-format-encoding-error

Anton Vodonosov — 2012-02-09T22:19:43

To make these two aspects - length calculation and error recovery - consistent,
the following approach may be good:

Length calculation never signals encoding error. Instead, it takes into
account that wrong byte sequences may be replaced by a character,
provided via *substitution-char* or use-value restart. I.e. every wrong
byte sequence is counted as one character.

In decoding process which follows the length calculation two cases
are possible:
1. some error is not recovered (no *substitution-char* provided
or use-value 
    restait doesn't matter what length was calculated
2.



10.02.2012, 01:21, "Edi Weitz" <edi< at >agharta.de>:

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

Re: substitution-char does not suppressexternal-format-encoding-error

Edi Weitz — 2012-02-09T21:21:07

Sorry for the delay.  I think this is more or less "on purpose."
(It's been a while since I wrote that stuff...)

The recover-from-encoding-error helper function is used when during
decoding we encounter something which "looks like" a character (so to
say) but isn't one - in which case we can e.g. replace it with the
substitution character.

I think the error you mention happens earlier - when the length is checked.

Of course, one could argue that one could just as well use the same
restart here.  Maybe you can just submit a patch (including
documentation if needed and ideally with new tests) and convince Hans
to make a new release?

Thanks,
Edi.


On Sat, Jan 21, 2012 at 1:06 PM, Dmitriy Ivanov <divanov11< at >gmail.com> wrote:

substitution-char does not suppressexternal-format-encoding-error

Dmitriy Ivanov — 2012-01-21T12:06:17

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

Anton Vodonosov — 2011-10-29T14:27:30

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

My open source libraries (aka "ediware")

Edi Weitz — 2011-08-31T15:11:30

[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
implemen

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

Edi Weitz — 2011-03-03T08:02:25

Sorry for the long delay.  I finally found the time to look at the
patch.  Unfortunately, it doesn't work for me.  If I run the tests, I
get an error.  I'm attaching a backtrace.

Thanks,
Edi.



Condition: No character which corresponds to octet #xAFE4.

Call to ERROR (offset 67)
  SYSTEM::ESTRING : FLEXI-STREAMS:EXTERNAL-FORMAT-ENCODING-ERROR
  SYSTEM::EARGS   : (:FORMAT-CONTROL "No character which corresponds
to octet #x~X." :FORMAT-ARGUMENTS (45028) :EXTERNAL-FORMAT
#<FLEXI-STREAMS::FLEXI-GBK-FORMAT (:GBK :EOL-STYLE :LF :LITTLE-ENDIAN
T) 229B8E57>)

Catch frame: (FLEXI-STREAMS::RECOVER-FROM-ENCODING-ERROR . RESTART-CASE)

Catch frame: (FLEXI-STREAMS::RECOVER-FROM-ENCODING-ERROR . 1)

Call to FLEXI-STREAMS::RECOVER-FROM-ENCODING-ERROR (offset 382)
  FLEXI-STREAMS::EXTERNAL-FORMAT            :
#<FLEXI-STREAMS::FLEXI-GBK-FORMAT (:GBK :EOL-STYLE :LF :LITTLE-ENDIAN
T) 229B8E57>
  FLEXI-STREAMS::FORMAT-CONTROL             : "No character which
corresponds to octet #x~X."
  FLEXI-STREAMS::FORMAT-ARGS

Re: Flexi Streams fails to compile and install on MacPorts ECL

Edi Weitz — 2011-03-03T07:25:29

Maybe Xu Jingtao was right and that was the patch you needed.  In that
case, could you please confirm that this patch is needed for ECL as
well and if the tests pass?  Otherwise, please send a full backtrace.

Thanks,
Edi.


On Tue, Mar 1, 2011 at 11:12 PM, Andrew Pennebaker
<andrew.pennebaker< at >gmail.com> wrote:

Re: Flexi Streams fails to compile and install onMacPorts ECL

Edi Weitz — 2011-03-03T07:23:41

Thanks, I've applied this patch to the BKNR repository.  Does CMUCL
pass all tests after this change?

(I don't think this is the OP's problem, though.)

Re: Flexi Streams fails to compile and install onMacPorts ECL

Xu Jingtao — 2011-03-02T01:40:23

I redefined the type char-code-integer in mapping.lisp under cmucl.
this idea is from here: http://comments.gmane.org/gmane.lisp.cmucl.general/6316
=============================================================================
(deftype char-code-integer ()
  "The subtype of integers which can be returned by the function CHAR-CODE."
  #-:cmu '(integer 0 #.(1- char-code-limit))
  #+:cmu '(integer 0 65533))
=============================================================================
Maybe you could try to redefine it under ecl.

>

Flexi Streams fails to compile and install onMacPorts ECL

Andrew Pennebaker — 2011-03-01T22:12:50

Specs:

flexi-streams 1.0.7
Quicklisp 2010121400
ECL 11.1.1
MacPorts 1.9.2
Mac OS X 10.6.6
MacBook Pro 5,1

Trace:


...

;;;   Invoking external command:
;;;   /usr/bin/gcc-4.2 -o
/Users/andrew/.cache/common-lisp/ecl-11.1.1-macosx-x86/Users/andrew/quicklisp/dists/quicklisp/software/flexi-streams-1.0.7/mapping.fas
-L/Users/andrew/macports/lib/
/private/var/folders/N-/N-IxaaKuFae5ik1WKxV6wE+++TI/-Tmp-/eclinit87rR0W.o
/Users/andrew/.cache/common-lisp/ecl-11.1.1-macosx-x86/Users/andrew/quicklisp/dists/quicklisp/software/flexi-streams-1.0.7/mapping.o
-bundle -L/Users/andrew/macports/lib -arch x86_64
-L/Users/andrew/macports/lib -arch x86_64 -lecl -lm
In function COERCE, the value of variable is
        65533
which is not of expected type (INTEGER -128 127)

Available restarts:

1. (ABORT) ABORT
2. (TRY-RECOMPILING) Try recompiling ascii
3. (RETRY) Retry compiling component ("flexi-streams" "ascii").
4. (ACCEPT) Continue, treating compiling component ("flexi-streams" "ascii")
as having been successful.
5. (ABORT)

gbk patch of flexi-streams.

jingtao xu — 2011-02-21T11:31:04

hi all

i have published my gbk(cp936,gb2312) encoding support for flexi-streams.
this patch passed all tests and use the best fit mapping table.
flexi-streams-devel< at >common-lisp.net

the git reposity url: https://github.com/jingtaozf/flexi-streams

Could weitz apply this patch to his official site?

With Best Regards.

jingtao.
_______________________________________________
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.

Xu Jingtao — 2011-02-21T10:33:13

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

Re: UNREAD-BYTE and PEEK-BYTE onIN-MEMORY-INPUT-STREAM

Edi Weitz — 2010-12-12T01:16:47

Hi Daniel,

As the documentation says, you can use in-memory streams as the
underlying streams for flexi streams.  If you do that, you'll have the
operations you wanted.

HTH,
Edi.


On Sat, Dec 11, 2010 at 7:48 PM, Daniel Oliveira <psykon< at >gmail.com> wrote:

UNREAD-BYTE and PEEK-BYTE onIN-MEMORY-INPUT-STREAM

Daniel Oliveira — 2010-12-11T18:48:39

Hello, i'm using FLEXI-STREAMS and i have a problem, UNREAD-BYTE and
PEEK-BYTE aren't defined for IN-MEMORY-INPUT-STREAM's, is there a reason why
they can't be or why it doesn't make sense for them to be?
_______________________________________________
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.

Edi Weitz — 2010-02-05T15:58:03

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:

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

Re: Flexi-streams problem with SBCL 1.0.34

Edi Weitz — 2010-01-07T23:17:00

Yeah, flexi-streams might returned vectors with fill pointers.  But it
doesn't claim otherwise.  Looks like this is a bug on the side of the
caller.

Cheers,
Edi.

On Thu, Jan 7, 2010 at 11:42 PM, Fred Gibson <fred< at >streamfocus.com> wrote:

Re: Flexi-streams problem with SBCL 1.0.34

Fred Gibson — 2010-01-07T22:42:44

It looks like the problem is with the resultant data type although the
printed representation is identical in both results:

ZS3> (flexi-streams:STRING-TO-OCTETS "XXiXWAxW93c" :EXTERNAL-FORMAT :UTF-8)
#(88 88 105 88 87 65 120 87 57 51 99)
ZS3> (describe *)
#(88 88 105 88 87 65 120 87 57 51 99)
  [specialized vector]

Element-type: (UNSIGNED-BYTE 8)
Fill-pointer: 11
Size: 15
Adjustable: yes
Displaced-to: NIL
Displaced-offset: 0
Storage vector: #<(SIMPLE-ARRAY (UNSIGNED-BYTE 8) (15)) {D0760BF}>
; No value
ZS3> (acl-compat.excl:string-to-octets "XXiXWAxW93c" :EXTERNAL-FORMAT :UTF-8)
  0: (SB-EXT:STRING-TO-OCTETS "XXiXWAxW93c" :EXTERNAL-FORMAT :UTF-8)
  0: SB-EXT:STRING-TO-OCTETS returned #(88 88 105 88 87 65 120 87 57 51 99)
#(88 88 105 88 87 65 120 87 57 51 99)
ZS3> (describe *)
#(88 88 105 88 87 65 120 87 57 51 99)
  [simple specialized vector]

Element-type: (UNSIGNED-BYTE 8)
Length: 11
; No value

I'm not sure which type is right, only that the acl-compat type is
what's needed for ironclad and zs3 to run.

Re: Flexi-streams problem with SBCL 1.0.34

Edi Weitz — 2010-01-07T21:28:44

I'm not familiar with ironclad or zs3.  Could you maybe send a full
backtrace and a simple way to reproduce the problem?

Thanks,
Edi.


On Thu, Jan 7, 2010 at 9:29 PM, Fred Gibson <fred< at >streamfocus.com> wrote:

gmane.lisp.flexi-streams.devel

Votre Convention collective

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

Re: *substitution-char* does not suppressexternal-format-encoding-error

Re: *substitution-char* does not suppressexternal-format-encoding-error

Re: *substitution-char* does not suppressexternal-format-encoding-error

*substitution-char* does not suppressexternal-format-encoding-error

unit test failure on sbcl

My open source libraries (aka "ediware")

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

Re: Flexi Streams fails to compile and install on MacPorts ECL

Re: Flexi Streams fails to compile and install onMacPorts ECL

Re: Flexi Streams fails to compile and install onMacPorts ECL

Flexi Streams fails to compile and install onMacPorts ECL

gbk patch of flexi-streams.

gbk patch to flexi-streams.

Re: UNREAD-BYTE and PEEK-BYTE onIN-MEMORY-INPUT-STREAM

UNREAD-BYTE and PEEK-BYTE onIN-MEMORY-INPUT-STREAM

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

Re: Flexi-streams problem with SBCL 1.0.34

Re: Flexi-streams problem with SBCL 1.0.34

Re: Flexi-streams problem with SBCL 1.0.34

Re: substitution-char does not suppressexternal-format-encoding-error

Re: substitution-char does not suppressexternal-format-encoding-error

Re: substitution-char does not suppressexternal-format-encoding-error

substitution-char does not suppressexternal-format-encoding-error