[Ecls-list] ECL HEAD + Slime HEAD

[Matthew Mondor]

On Wed, 17 Feb 2010 09:10:02 +0100
Juan Jose Garcia-Ripoll <juanjose.garciaripoll at googlemail.com> wrote:

> This is not true. The proper way of closing a socket is with
> socket-close which will close the components of the bidirectional
> stream!

Sorry for the misinformed comment.  After upgrading to revision 1.58 of
sockets.lisp which had the additional two-way-stream closing fix you
commited, I initially saw no difference trying with close and
socket-close, but the test was done in slime (a non-current slime,
also) which hid that there were errors occuring.  Within the ECL REPL,
after reading this I immediately had to retest it :)

Unfortunately there was an error:
The function SB-BSD-SOCKETS::TWO-WAY-STREAM-INPUT is undefined.

And when tested using socket-close on the stream rather than the underlaying socket (we never know, I told myself), gave the expected error:
No applicable method for SB-BSD-SOCKETS:SOCKET-CLOSE with arguments of types
 TWO-WAY-STREAM

Although if socket-close had to be used (and close on the stream
couldn't close the underlaying socket and its fd), this would be a
second incompatibility with sbcl that I know (the first being that
socket streams default to fully buffered, while ECL ones are
non-buffered by default)...

Slight behaviour differences might not matter much if they're
documented as such however, I guess.  But I'll CVS update again
tomorrow and retest the socket-close function, in case there was a very
recent fix on the issue (I last updated and rebuilt yesterday).

BTW, just so it's clear, the previous post about the syscalls layer in
writing is not a reaction to this bidirectional sockets change,
however; I was partly satisfied with iolib's syscall layer on SBCL
(even if it wasn't meant to be an exported API) but since I'm
recently using ECL a lot (generally with as few external dependencies
as possible) and its FFI allows great interaction with C, I became
convinced that it wasn't a waste of time to finally write it.

SBCL threading support not being implemented on most OSs (including
NetBSD), and the number of dependencies needed to maintain and update
to use the CFFI based layers I used, were the main reasons for me to try
alternatives.  And since there's so much C legacy and current code in
use on my systems, ECL makes a lot of sense.

Thanks,
-- 
Matt