[Ecls-list] About sockets - maybe last iteration?

[Matthew Mondor]

On Wed, 17 Feb 2010 20:34:57 +0100
"Tobias C. Rittweiler" <tcr at freebits.de> wrote:

> How did this assumption manifest itself?

I had the change in my local tree for sockets to use buffering mode by
default since a while back, and slime would initially get stuck at
startup.  After checking the ecl-swank code I noticed that it did not
specify the buffering type (and indeed without the buffering change
single bytes were read in and out at a time as shown via ktrace), and
that if adding :buffering :none to swank-ecl it worked again.  Note
that this is not a current slime.

In the archives, you'll also see my earlier proposal to make socket
streams buffered by default.  I also posted on slime-devel proposing
the addition of :buffering :none which made slime work again with my
ECL tree which did have the :full by default changes.

Some MsgID references:
<200908160144.n7G1ilek018526 at ginseng.xisop>
<200908160227.n7G2RPUi002970 at ginseng.xisop>
<c159f9ab0908160150n5ddc003dk6ac9258814ae38a3 at mail.gmail.com>

An earlier diff:
http://sourceforge.net/tracker/index.php?func=detail&atid=398053&aid=2838358&group_id=30035
(was mostly applied then except for the buffering full changes, with
fear that it might break other ECL-specific software assuming
unbuffered socket streams by default.  But with a recent commit socket
streams are really buffered by default in the official tree).

The fix I had to do to swank-ecl back then here so slime continued to
work:

(defun make-socket-io-stream (socket)
  (sb-bsd-sockets:socket-make-stream socket
                                     :output t
                                     :input t
+                                    :buffering :none
                                     :element-type 'base-char))

Considering there were a number of swank-ecl changes lately, I'm about
to soon try a more recent slime.

Thanks,
-- 
Matt