With this change, it works well :)
Thanks!

Florian

goran at krampe.se wrote:
> Hi!
> 
> Since this smelled like an FastSocketStream issue I looked into it - and
> found the issue:
> 
> Jecel Assumpcao Jr <jecel at merlintec.com> wrote:
> 
>>Marcus Denker wrote on Wed, 7 Sep 2005 17:31:40 +0200
>>
>>>  -> FastSocketStream replaced SocketStream... you could file in
>>>       the SocketStream from 3.8 to see if this makes a difference.
>>
>>I started having problems in Celeste so decided to load FastSocketStream
>>into the 3.8 image I am typing this in, but things stopped working
>>entirely (probably the ConnectionTimedOut: error, but I am not sure). I
> 
> 
> In fact, first I thought this could have to do with the fact that FSS
> (if you read the class comment) signals ConnectionClosed and
> ConnectionTimedOut exceptions, which can affect old client code (which
> should be fixed IMHO).
> 
> A "hack" to get the old and faulty behavior - send "shouldSignal: false"
> to the stream.
> 
> But... nah, then I started looking at the complex looking upToAll:
> method (we need a new prim btw to make it better!) but eventually found
> the much simpler cause in #sendCommand:. It doesn't flush. Oops.
> 
> So change it to:
> 
> sendCommand: aString
> 	self nextPutAllFlush: aString, String crlf
> 
> After that it seems to work (you can test using a filelist, click at
> UIUC on the bottom).
> 
> 
>>On the other hand, I loaded FastSocketStream into a 3.8 image with
>>Seaside and it was a huge improvement there and has worked perfectly for
>>a couple of months now.
> 
> 
> Yeah, I actually have debugged it pretty thoroughly and use it myself.
> But evidently sendCommand: is only used by client code - not server
> code. :)
> 
> 
>>-- Jecel
> 
> 
> regards, Göran
> 
> 
>