Generators on Streams on Generators on Collections on ...

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Generators on Streams on Generators on Collections on ...

Eliot Miranda-2


> On Apr 12, 2016, at 12:33 PM, marcel.taeumel <[hidden email]> wrote:
>
> Hi Nicolas,
>
> if you construct something like:
>
> | someStream |
> someStream := mySocketStream select: [:ea | ... ] thenCollect: [:ea | ... ].
> ...
> someStream next.
> ...
> someStream next: 5.
> ...
>
> You can only use someStream as long as there is data available while it is
> connected. Now, it can happen that socket streams are temporarily "at end"
> while no data is waiting in the buffer. Then, you would have to reconstruct
> someStream to continue. And know about it.

That's changing the definition of "at end".  A socket stream is at end when it is closed.  In thus circumstance a few stream implementations use basicAtEnd to answer if at the end of the current buffer's worth.  But atEnd meaning "at the end of what's available so far" doesn't make sense, at least to me.

>
> Best,
> Marcel
>
>
>
> --
> View this message in context: http://forum.world.st/Generators-on-Streams-on-Generators-on-Collections-on-tp4889389p4889623.html
> Sent from the Squeak - Dev mailing list archive at Nabble.com.
>

Reply | Threaded
Open this post in threaded view
|

Re: Generators on Streams on Generators on Collections on ...

Eliot Miranda-2
In reply to this post by Bert Freudenberg


> On Apr 12, 2016, at 1:19 PM, Bert Freudenberg <[hidden email]> wrote:
>
>> On 12.04.2016, at 21:33, marcel.taeumel <[hidden email]> wrote:
>>
>> Hi Nicolas,
>>
>> if you construct something like:
>>
>> | someStream |
>> someStream := mySocketStream select: [:ea | ... ] thenCollect: [:ea | ... ].
>> ...
>> someStream next.
>> ...
>> someStream next: 5.
>> ...
>>
>> You can only use someStream as long as there is data available while it is
>> connected. Now, it can happen that socket streams are temporarily "at end"
>> while no data is waiting in the buffer. Then, you would have to reconstruct
>> someStream to continue. And know about it.
>
> AFAIK, “at end” means there will not be any more data:
>
> SocketStream>>atEnd
>    "There is nothing more to read when
>    there is no more data in our inBuffer, the socket
>    is disconnected and there is none available on the socket.
>    Note that we need to check isConnected before isDataAvailable,
>    otherwise data may sneak in in the meantime. But we check the
>    buffer first, because it is faster.”
>
>    self isInBufferEmpty ifFalse: [^false].
>    ^self isConnected not
>        and: [self isDataAvailable not]
>
>
> - Bert -

+1
Reply | Threaded
Open this post in threaded view
|

Re: Generators on Streams on Generators on Collections on ...

Eliot Miranda-2
In reply to this post by David T. Lewis


> On Apr 12, 2016, at 1:47 PM, David T. Lewis <[hidden email]> wrote:
>
> FWIW, In OSProcess I used #upToEnd to mean "all of the data that is
> currently available in the stream" and #upToEndOfFile to mean "all of that
> data that will ever be available". Separately, the steam may be in
> blocking or non-blocking mode, where blocking means that #upToEndOfFile
> will block until EOF is detected.
>
> Dave

yuck :-(

>
>>> On 12.04.2016, at 21:33, marcel.taeumel <[hidden email]> wrote:
>>>
>>> Hi Nicolas,
>>>
>>> if you construct something like:
>>>
>>> | someStream |
>>> someStream := mySocketStream select: [:ea | ... ] thenCollect: [:ea |
>>> ... ].
>>> ...
>>> someStream next.
>>> ...
>>> someStream next: 5.
>>> ...
>>>
>>> You can only use someStream as long as there is data available while it
>>> is
>>> connected. Now, it can happen that socket streams are temporarily "at
>>> end"
>>> while no data is waiting in the buffer. Then, you would have to
>>> reconstruct
>>> someStream to continue. And know about it.
>>
>> AFAIK, “at end” means there will not be any more data:
>>
>> SocketStream>>atEnd
>>    "There is nothing more to read when
>>    there is no more data in our inBuffer, the socket
>>    is disconnected and there is none available on the socket.
>>    Note that we need to check isConnected before isDataAvailable,
>>    otherwise data may sneak in in the meantime. But we check the
>>    buffer first, because it is faster.”
>>
>>    self isInBufferEmpty ifFalse: [^false].
>>    ^self isConnected not
>>        and: [self isDataAvailable not]
>>
>>
>> - Bert -
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Generators on Streams on Generators on Collections on ...

Eliot Miranda-2
In reply to this post by David T. Lewis
Dave,



> On Apr 12, 2016, at 1:47 PM, David T. Lewis <[hidden email]> wrote:
>
> FWIW, In OSProcess I used #upToEnd to mean "all of the data that is
> currently available in the stream" and #upToEndOfFile to mean "all of that
> data that will ever be available". Separately, the steam may be in
> blocking or non-blocking mode, where blocking means that #upToEndOfFile
> will block until EOF is detected.

I think this is a mistake and I hope you'll reconsider.  #atEnd is well-defined, as Bert's example for SocketStream showed.  If you choose to change the meaning in this one example you sow the seeds of confusion, and force people trying to use standard stream facilities (such as xstreams of generators) to implement exceptions to adapt to your alternative.  That way leads to brittle and hard-to-understand code.  Please change this.

>
> Dave
>
>>> On 12.04.2016, at 21:33, marcel.taeumel <[hidden email]> wrote:
>>>
>>> Hi Nicolas,
>>>
>>> if you construct something like:
>>>
>>> | someStream |
>>> someStream := mySocketStream select: [:ea | ... ] thenCollect: [:ea |
>>> ... ].
>>> ...
>>> someStream next.
>>> ...
>>> someStream next: 5.
>>> ...
>>>
>>> You can only use someStream as long as there is data available while it
>>> is
>>> connected. Now, it can happen that socket streams are temporarily "at
>>> end"
>>> while no data is waiting in the buffer. Then, you would have to
>>> reconstruct
>>> someStream to continue. And know about it.
>>
>> AFAIK, “at end” means there will not be any more data:
>>
>> SocketStream>>atEnd
>>    "There is nothing more to read when
>>    there is no more data in our inBuffer, the socket
>>    is disconnected and there is none available on the socket.
>>    Note that we need to check isConnected before isDataAvailable,
>>    otherwise data may sneak in in the meantime. But we check the
>>    buffer first, because it is faster.”
>>
>>    self isInBufferEmpty ifFalse: [^false].
>>    ^self isConnected not
>>        and: [self isDataAvailable not]
>>
>>
>> - Bert -
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Generators on Streams on Generators on Collections on ...

Eliot Miranda-2
In reply to this post by David T. Lewis


> On Apr 12, 2016, at 1:47 PM, David T. Lewis <[hidden email]> wrote:
>
> FWIW, In OSProcess I used #upToEnd to mean "all of the data that is
> currently available in the stream" and #upToEndOfFile to mean "all of that
> data that will ever be available". Separately, the steam may be in
> blocking or non-blocking mode, where blocking means that #upToEndOfFile
> will block until EOF is detected.

You could use e.g. upToAvailable and upToEnd.

>
> Dave
>
>>> On 12.04.2016, at 21:33, marcel.taeumel <[hidden email]> wrote:
>>>
>>> Hi Nicolas,
>>>
>>> if you construct something like:
>>>
>>> | someStream |
>>> someStream := mySocketStream select: [:ea | ... ] thenCollect: [:ea |
>>> ... ].
>>> ...
>>> someStream next.
>>> ...
>>> someStream next: 5.
>>> ...
>>>
>>> You can only use someStream as long as there is data available while it
>>> is
>>> connected. Now, it can happen that socket streams are temporarily "at
>>> end"
>>> while no data is waiting in the buffer. Then, you would have to
>>> reconstruct
>>> someStream to continue. And know about it.
>>
>> AFAIK, “at end” means there will not be any more data:
>>
>> SocketStream>>atEnd
>>    "There is nothing more to read when
>>    there is no more data in our inBuffer, the socket
>>    is disconnected and there is none available on the socket.
>>    Note that we need to check isConnected before isDataAvailable,
>>    otherwise data may sneak in in the meantime. But we check the
>>    buffer first, because it is faster.”
>>
>>    self isInBufferEmpty ifFalse: [^false].
>>    ^self isConnected not
>>        and: [self isDataAvailable not]
>>
>>
>> - Bert -
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Generators on Streams on Generators on Collections on ...

Ben Coman
On Wed, Apr 13, 2016 at 9:42 PM, Eliot Miranda <[hidden email]> wrote:

>
>
>> On Apr 12, 2016, at 1:47 PM, David T. Lewis <[hidden email]> wrote:
>>
>> FWIW, In OSProcess I used #upToEnd to mean "all of the data that is
>> currently available in the stream" and #upToEndOfFile to mean "all of that
>> data that will ever be available". Separately, the steam may be in
>> blocking or non-blocking mode, where blocking means that #upToEndOfFile
>> will block until EOF is detected.
>
> You could use e.g. upToAvailable and upToEnd.

upToBufferEnd ?

cheers -ben

>
>>
>> Dave
>>
>>>> On 12.04.2016, at 21:33, marcel.taeumel <[hidden email]> wrote:
>>>>
>>>> Hi Nicolas,
>>>>
>>>> if you construct something like:
>>>>
>>>> | someStream |
>>>> someStream := mySocketStream select: [:ea | ... ] thenCollect: [:ea |
>>>> ... ].
>>>> ...
>>>> someStream next.
>>>> ...
>>>> someStream next: 5.
>>>> ...
>>>>
>>>> You can only use someStream as long as there is data available while it
>>>> is
>>>> connected. Now, it can happen that socket streams are temporarily "at
>>>> end"
>>>> while no data is waiting in the buffer. Then, you would have to
>>>> reconstruct
>>>> someStream to continue. And know about it.
>>>
>>> AFAIK, “at end” means there will not be any more data:
>>>
>>> SocketStream>>atEnd
>>>    "There is nothing more to read when
>>>    there is no more data in our inBuffer, the socket
>>>    is disconnected and there is none available on the socket.
>>>    Note that we need to check isConnected before isDataAvailable,
>>>    otherwise data may sneak in in the meantime. But we check the
>>>    buffer first, because it is faster.”
>>>
>>>    self isInBufferEmpty ifFalse: [^false].
>>>    ^self isConnected not
>>>        and: [self isDataAvailable not]
>>>
>>>
>>> - Bert -
>>
>>
>>
>

cbc
Reply | Threaded
Open this post in threaded view
|

Re: Generators on Streams on Generators on Collections on ...

cbc


Sent from my iPhone

> On Apr 13, 2016, at 4:20 PM, Ben Coman <[hidden email]> wrote:
>
>> On Wed, Apr 13, 2016 at 9:42 PM, Eliot Miranda <[hidden email]> wrote:
>>
>>
>>> On Apr 12, 2016, at 1:47 PM, David T. Lewis <[hidden email]> wrote:
>>>
>>> FWIW, In OSProcess I used #upToEnd to mean "all of the data that is
>>> currently available in the stream" and #upToEndOfFile to mean "all of that
>>> data that will ever be available". Separately, the steam may be in
>>> blocking or non-blocking mode, where blocking means that #upToEndOfFile
>>> will block until EOF is detected.
>>
>> You could use e.g. upToAvailable and upToEnd.
>
> upToBufferEnd ?
>
allAvailable ?

> cheers -ben
>
>>
>>>
>>> Dave
>>>
>>>>> On 12.04.2016, at 21:33, marcel.taeumel <[hidden email]> wrote:
>>>>>
>>>>> Hi Nicolas,
>>>>>
>>>>> if you construct something like:
>>>>>
>>>>> | someStream |
>>>>> someStream := mySocketStream select: [:ea | ... ] thenCollect: [:ea |
>>>>> ... ].
>>>>> ...
>>>>> someStream next.
>>>>> ...
>>>>> someStream next: 5.
>>>>> ...
>>>>>
>>>>> You can only use someStream as long as there is data available while it
>>>>> is
>>>>> connected. Now, it can happen that socket streams are temporarily "at
>>>>> end"
>>>>> while no data is waiting in the buffer. Then, you would have to
>>>>> reconstruct
>>>>> someStream to continue. And know about it.
>>>>
>>>> AFAIK, “at end” means there will not be any more data:
>>>>
>>>> SocketStream>>atEnd
>>>>   "There is nothing more to read when
>>>>   there is no more data in our inBuffer, the socket
>>>>   is disconnected and there is none available on the socket.
>>>>   Note that we need to check isConnected before isDataAvailable,
>>>>   otherwise data may sneak in in the meantime. But we check the
>>>>   buffer first, because it is faster.”
>>>>
>>>>   self isInBufferEmpty ifFalse: [^false].
>>>>   ^self isConnected not
>>>>       and: [self isDataAvailable not]
>>>>
>>>>
>>>> - Bert -
>

cbc
Reply | Threaded
Open this post in threaded view
|

Re: Generators on Streams on Generators on Collections on ...

cbc


Sent from my iPhone

> On Apr 13, 2016, at 4:30 PM, Chris <[hidden email]> wrote:
>
>
>
> Sent from my iPhone
>
>>> On Apr 13, 2016, at 4:20 PM, Ben Coman <[hidden email]> wrote:
>>>
>>> On Wed, Apr 13, 2016 at 9:42 PM, Eliot Miranda <[hidden email]> wrote:
>>>
>>>
>>>> On Apr 12, 2016, at 1:47 PM, David T. Lewis <[hidden email]> wrote:
>>>>
>>>> FWIW, In OSProcess I used #upToEnd to mean "all of the data that is
>>>> currently available in the stream" and #upToEndOfFile to mean "all of that
>>>> data that will ever be available". Separately, the steam may be in
>>>> blocking or non-blocking mode, where blocking means that #upToEndOfFile
>>>> will block until EOF is detected.
>>>
>>> You could use e.g. upToAvailable and upToEnd.
>>
>> upToBufferEnd ?
> allAvailable ?
Or
remainingAvailable

-cbc

>> cheers -ben
>>
>>>
>>>>
>>>> Dave
>>>>
>>>>>> On 12.04.2016, at 21:33, marcel.taeumel <[hidden email]> wrote:
>>>>>>
>>>>>> Hi Nicolas,
>>>>>>
>>>>>> if you construct something like:
>>>>>>
>>>>>> | someStream |
>>>>>> someStream := mySocketStream select: [:ea | ... ] thenCollect: [:ea |
>>>>>> ... ].
>>>>>> ...
>>>>>> someStream next.
>>>>>> ...
>>>>>> someStream next: 5.
>>>>>> ...
>>>>>>
>>>>>> You can only use someStream as long as there is data available while it
>>>>>> is
>>>>>> connected. Now, it can happen that socket streams are temporarily "at
>>>>>> end"
>>>>>> while no data is waiting in the buffer. Then, you would have to
>>>>>> reconstruct
>>>>>> someStream to continue. And know about it.
>>>>>
>>>>> AFAIK, “at end” means there will not be any more data:
>>>>>
>>>>> SocketStream>>atEnd
>>>>>  "There is nothing more to read when
>>>>>  there is no more data in our inBuffer, the socket
>>>>>  is disconnected and there is none available on the socket.
>>>>>  Note that we need to check isConnected before isDataAvailable,
>>>>>  otherwise data may sneak in in the meantime. But we check the
>>>>>  buffer first, because it is faster.”
>>>>>
>>>>>  self isInBufferEmpty ifFalse: [^false].
>>>>>  ^self isConnected not
>>>>>      and: [self isDataAvailable not]
>>>>>
>>>>>
>>>>> - Bert -
>>

12