SocketStream>>atEnd

Hello guys,

today, by examining closely the #atEnd implementation , i came to
conclision that is can be made as simple as:

atEnd
  ^ self isDataAvailable not


Because, take a close look at old implementation:
atEnd
        self isInBufferEmpty ifFalse: [^false].   ----***---
        ^self isConnected not
                and: [self isDataAvailable not]

and:
isDataAvailable

        self isInBufferEmpty ifFalse: [^true].  ---***---
        ^socket dataAvailable
                ifFalse: [false]
                ifTrue: [self receiveDataIfAvailable; isDataAvailable]


a Socket>>dataAvailable answers false on closed or invalid socket. You
can check it quite simply:

(SocketStream openConnectionToHostNamed:  'google.com' port: 80)
socket closeAndDestroy dataAvailable
(SocketStream openConnectionToHostNamed:  'google.com' port: 80) close
socket dataAvailable
Socket new dataAvailable
=> all 3 answer false

Therefore, a complex logic in #atEnd, could be simplified.

Please, try to find a flaw in my conclusions. I think there's not. But
2 (or more) heads always better than 1.

--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

It appears that im wrong. sorry for disturbing :)

2010/1/15 Igor Stasenko <[hidden email]>:


--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Igor Stasenko wrote:
> It appears that im wrong. sorry for disturbing :)

...but thanks for digging in the SocketStream code! It was quite a while
since I wrote it :)

While we are at it we should improve the primitive for searching in
String/ByteArrays to include at stopAt: argument. This would increase
speed and simplify the horribly tricky logic in the upTo: family of
methods in SocketStream.

The reason for the trickiness is the fact that the search primitive
always searches to the very end of the buffer (there is no stopAt:
parameter) AND the buffer can of course include old data after the
current end marker in which we may find "false hits".

I remember the pain in writing that code...

regards, Göran


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project