Thanks for the detailed report. I made some changes.
* The exported symbols come from the EXT package. They are
character-coding-error
character-coding-error-external-format
character-decoding-error
character-decoding-error-octets
character-encoding-error
character-encoding-error-code
On Fri, Feb 11, 2011 at 11:22 PM, Matthew Mondor
mm_li...@pulsar-zone.netwrote:
The SF CVS services have finally been restored
Commits just uploaded.
Junjo
--
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com
http://cdr.eurolisp.org/document/6/index.html
Variable is EXT:*INSPECTOR-HOOK*
--
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com
--
The ultimate
On Fri, Feb 11, 2011 at 12:34 PM, Matthew Mondor
mm_li...@pulsar-zone.netwrote:
I noticed in an application that I would find spurious error messages
in my stdout stream (which was redirected to a log file).
There was an extra printf() statement, probably left from some debugging
phase. I
On Fri, Feb 11, 2011 at 12:04 PM, Willem Broekema metaw...@gmail.comwrote:
Yes, but an older version that won't work in ECL. I'll try to get the
version in quicklisp updated and let you know when that is done.
I have added cl-python to the list of tested libraries. I suppose things
will
On Sat, 12 Feb 2011 19:07:43 +0100
Juan Jose Garcia-Ripoll juanjose.garciarip...@googlemail.com wrote:
Thanks for the detailed report. I made some changes.
* The exported symbols come from the EXT package. They are
Indeed, SI and EXT appear to be aliases; however when a condition type
is
2011/2/12 Matthew Mondor mm_li...@pulsar-zone.net
a character is still getting lost after the CONTINUE restart, even if I
consume all bytes from the invalid octets supplied. New test code
attached.
I did not realize that from your previous email. This is fixed now (trivial
typo in
On Sat, 12 Feb 2011 23:49:14 +0100
Juan Jose Garcia-Ripoll juanjose.garciarip...@googlemail.com wrote:
I did not realize that from your previous email. This is fixed now (trivial
typo in utf_8_decoder)
I tested and it works fine for invalid UTF-8 bytes to LATIN-1
conversion.
I also did a test
