- flexi-streams-devel@lists.common-lisp.net

[flexi-streams-devel] New release 0.15.3
by Edi Weitz 23 May '08

23 May '08

ChangeLog: Version 0.15.3 2008-05-23 Avoid CHANGE-CLASS on LispWorks if possible This change should not affect Lisps other than LW. Edi.

1 0

[flexi-streams-devel] New release 0.15.2
by Edi Weitz 22 May '08

22 May '08

ChangeLog: Version 0.15.2 2008-05-22 Remove debugging remnants. D'oh! Download: http://weitz.de/files/flexi-streams.tar.gz Sorry for the noise, Edi.

1 0

[flexi-streams-devel] New release 0.15.0
by Edi Weitz 21 May '08

21 May '08

Too much changes to mention them individually. This started out as making the string functions faster and ended in a major redesign. The new release also fixes some bugs, adds a few new features, is slightly incompatible with previous versions, and likely breaks a few things. Check it out for yourself (and keep a copy of the latest release just in case). Thanks to Hans Hübner for his work on FLEXI-STREAM's performance.

1 2

[flexi-streams-devel] New release 0.14.0
by Edi Weitz 29 Dec '07

29 Dec '07

ChangeLog: Version 0.14.0 2007-12-30 Some fixes for LispWorks (when the underlying stream is a character stream) Optimized methods for UNREAD-CHAR% in case of 8-bit encodings More tests Download: http://weitz.de/files/flexi-streams.tar.gz

1 0

[flexi-streams-devel] New release 0.11.1
by Edi Weitz 10 Nov '07

10 Nov '07

ChangeLog: Version 0.11.1 2007-03-22 More ugliness for a bit of output performance in special cases Download: http://weitz.de/files/flexi-streams.tar.gz Cheers, Edi.

3 9

[flexi-streams-devel] Re: [cl-xmpp-devel] Problem with TLS connection on Franz/ACL8.1
by Jason S. Cornez 25 Oct '07

25 Oct '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Many thanks. Here is a patch which works for me to get past this particular problem. =================== - --- streams.lisp 2007-07-07 18:47:57.000000000 +0200 +++ /home/jcornez/Library/world/site/cl+ssl-2007-07-07/streams.lisp 2007-10-25 19:05:27.000000000 +0200 @@ -156,6 +156,25 @@ ;;; interface functions ;;; +#+allegro +(defun make-ssl-client-stream + (socket &key certificate key (method 'ssl-v23-method) external-format + close-callback) + (declare (ignore external-format close-callback)) + (let ((acl-method (case method + ((ssl-v23-method + ssl-v3-method + ssl-v2-client-method + ssl-v23-client-method + ssl-v3-client-method) :sslv23) + ((ssl-TLSv1-method + ssl-TLSv1-client-method) :tlsv1)))) + (socket:make-ssl-client-stream socket + :certificate certificate + :key key + :method acl-method))) + +#-allegro (defun make-ssl-client-stream (socket &key certificate key (method 'ssl-v23-method) external-format close-callback) =================== - -Jason David Lichteblau wrote: > CL+SSL is known to be broken on Allegro with a failure mode like this. > I can only guess why, but since Allegro already includes SSL support, > perhaps there is some kind of conflict between the two FFI uses. > > I think the workaround Edi used in his libraries was to do > #+allegro (excl:make-ssl-client-stream ...) > #-allegro (cl+ssl:make-ssl-client-stream ...) > but if the problem stays unsolved, it would be better to move this kind > of hack into CL+SSL itself, so that it wraps the built-in streams on > Allegro instead of doing things itself. > > Unfortunately I don't really have the time for CL+SSL development at the > moment, but patches are always welcome, of course. > > > d. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHINENQlm6HDTMLyMRAiSTAJ46LaVUnJDueUxa3E6DtoI+TsKIaQCgvAtq cGkrHllMGVHCWONoJBg1pFA= =/0Nx -----END PGP SIGNATURE-----

1 0

[flexi-streams-devel] [Fwd: Problem with TLS connection on Franz/ACL8.1]
by Jason S. Cornez 25 Oct '07

25 Oct '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This is a report I also sent to cl-xmpp-devel as that is where I discovered it. It does however seem to be more related to Flexi-Streams on ACL8.1. Thanks in advance for any ideas you might have about how to resolve this issue. Best, - -Jason - -------- Original Message -------- Subject: [cl-xmpp-devel] Problem with TLS connection on Franz/ACL8.1 Date: Thu, 25 Oct 2007 18:16:29 +0200 From: Jason S. Cornez <jcornez(a)alum.mit.edu> To: cl-xmpp-devel(a)common-lisp.net Hi I know this is a small list and that this problem is likely not to do specifically with CL-XMPP code, but with one of the libraries it uses. So if you can help by even suggesting where better I might ask this, it would be appreciated. Thank you. What follows is run using the latest cl-xmpp and cxml/closure-commons from CVS along with other libraries from asdf-install tarballs. I use ACL8.1 on linux-x86.32. The net result is that the lisp crashes and dies with a segmentation violation. Obviously that in itself is a Franz issue, but this happens because (figure-encoding...) calls (read-byte ...) on a flexi-stream. And I figure this doesn't make much sense. I've traced figure-encoding to see that this is clear. Perhaps there should be a specialized method of figure-encoding for flexi-streams? Again, if you can help me to direct this query to a better place, please let me know. Best, - -Jason CL-USER(6): (trace runes::figure-encoding) (RUNES::FIGURE-ENCODING) CL-USER(7): (xmpp:connect-tls :hostname "localhost") <?xml version='1.0' ?><stream:stream to='localhost' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' version='1.0'> 0[2]: (RUNES::FIGURE-ENCODING #<MULTIVALENT stream socket connected from localhost/56698 to localhost/5222 @ #x72766952>) 0* #<STANDARD-METHOD RUNES::FIGURE-ENCODING (STREAM)> 0[2]: returned :UTF-8 (60 115) <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/> <?xml version='1.0' ?><stream:stream to='localhost' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' version='1.0'> 0[2]: (RUNES::FIGURE-ENCODING #<FLEX::FLEXI-LATIN-1-IO-STREAM @ #x722197ca>) 0* #<STANDARD-METHOD RUNES::FIGURE-ENCODING (STREAM)> _______________________________________________ cl-xmpp-devel mailing list cl-xmpp-devel(a)common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cl-xmpp-devel -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHIMSBQlm6HDTMLyMRAulqAJ9k3pDbNKbvwFYc/6ZAuywkze2IyACgmr2t qgpe65voZq71z9OqocyY4eg= =e96r -----END PGP SIGNATURE-----

2 2

[flexi-streams-devel] New release 0.13.1
by Edi Weitz 11 Oct '07

11 Oct '07

ChangeLog: Version 0.13.1 2007-10-11 Small fix for AllegroCL's "modern" mode Download: http://weitz.de/files/flexi-streams.tar.gz

1 0

[flexi-streams-devel] New release 0.12.0
by Edi Weitz 06 Sep '07

06 Sep '07

ChangeLog: Version 0.12.0 2007-09-07 Added "bound" for flexi input streams Download: http://weitz.de/files/flexi-streams.tar.gz

1 0

[flexi-streams-devel] Re: [hunchentoot-devel] write-sequence to *hunchentoot-stream* on x86_64
by Jeff Caldwell 22 Aug '07

22 Aug '07

Hi Edi, Thanks for pointing me in a good direction. I hope this ends up in the same thread as your cc from hunchentoot-devel, but here is a summary in case it doesn't: 32-bit LWLPro 4.3.7 ran OK on 32-bit Linux but on x86_64. Hunchentoot returned the headers OK, followed by a block of seemingly-random binary data, followed by the content, which was OK. I found a workaround, using write-string instead of write-sequence to write the content. >Edi wrote: > >Looks like a possible bug in flexi-streams (/or/ in LWL 4) to me and >should probably be discussed on the corresponding mailing list - see >Cc. Could you check if the test suite of flexi-streams runs through >on your x86_64 machine? Are you using the newest version of >flexi-streams? Could you check if you get the same problems with LWL >5.0.x, maybe using the Personal Edition? Unfortunately, I don't have >a 64-bit machine yet to check this myself. > >Thanks, >Edi. The flexi-streams test suite ran with all tests passed (3313 of them, if I recall correctly). LWL 5.0.x Personal Edition does not exhibit the problem. I'm using flexi-streams-0.11.2. I suppose the limitation of my workaround (write-string vs write-sequence) is the charset, no UTF? Anything else to be aware of? Maybe I can leverage this app into a nice new 5.0 license, courtesy of my employer. If not, do you have a quick thought regarding where else I might look to change the behavior in 4.3.7? Thanks, Jeff Caldwell ____________________________________________________________________________________Ready for the edge of your seat? Check out tonight's top picks on Yahoo! TV. http://tv.yahoo.com/

2 1