ZdcAbstractSocketStream>>peekFor:?

> Regards.
>
> El sáb., 16 de mar. de 2019 12:23, Alistair Grant <[hidden email]> escribió:
>>
>> Hi Sven,
>>
>> Unlike most streams that support #peek, ZdcAbstractSocketStream
>> doesn't support #peekFor:.
>>
>> Is this intentional, or an oversight?
>>
>> Thanks,
>> Alistair
>>

> On 16 Mar 2019, at 19:44, Alistair Grant <[hidden email]> wrote:
>
> Hi Esteban,
> On Sat, 16 Mar 2019 at 19:37, Esteban Maringolo <[hidden email]> wrote:
>>
>> I don't know the answer but how could you peek for data that has yet not come through the socket? In the buffer? Should it block?
>
> From memory: It depends on the mode of the stream:
>
> If synchronous: peeking will block until data is available.
> If asynchronous: if data is available, the next byte / character is
> returned.  If no data is available, nil is returned.  If nil is
> returned, you need to check if the socked is #atEnd to determine
> whether it is the end of the stream or just nothing available now.
>
> Cheers,
> Alistair
>
>
>
>> Regards.
>>
>> El sáb., 16 de mar. de 2019 12:23, Alistair Grant <[hidden email]> escribió:
>>>
>>> Hi Sven,
>>>
>>> Unlike most streams that support #peek, ZdcAbstractSocketStream
>>> doesn't support #peekFor:.
>>>
>>> Is this intentional, or an oversight?
>>>
>>> Thanks,
>>> Alistair
>>>
>

>
> Since there is #peek there is no reason not to add #peekFor: as
>
> peekFor: object
>   "Answer false and do not move over the next element if it is not equal to object, or if the receiver is at the end.
>    Answer true and move over the next element when it is equal to object."
>
>   ^ self peek = object
>       ifTrue: [
>         self next.
>         true ]
>       ifFalse: [ false ]

> But note that the Zdc socket streams do not make a difference between synchronous / asynchronous - IIRC I would say they block (they are also always binary and flush when their buffer is full).
>
> Peeking in the context of a socket / network stream will block, just like reading.
>
> > On 16 Mar 2019, at 19:44, Alistair Grant <[hidden email]> wrote:
> >
> > Hi Esteban,
> > On Sat, 16 Mar 2019 at 19:37, Esteban Maringolo <[hidden email]> wrote:
> >>
> >> I don't know the answer but how could you peek for data that has yet not come through the socket? In the buffer? Should it block?
> >
> > From memory: It depends on the mode of the stream:
> >
> > If synchronous: peeking will block until data is available.
> > If asynchronous: if data is available, the next byte / character is
> > returned.  If no data is available, nil is returned.  If nil is
> > returned, you need to check if the socked is #atEnd to determine
> > whether it is the end of the stream or just nothing available now.
> >
> > Cheers,
> > Alistair
> >
> >
> >
> >> Regards.
> >>
> >> El sáb., 16 de mar. de 2019 12:23, Alistair Grant <[hidden email]> escribió:
> >>>
> >>> Hi Sven,
> >>>
> >>> Unlike most streams that support #peek, ZdcAbstractSocketStream
> >>> doesn't support #peekFor:.
> >>>
> >>> Is this intentional, or an oversight?
> >>>
> >>> Thanks,
> >>> Alistair
> >>>
> >
>
>

> On 16 Mar 2019, at 20:23, Alistair Grant <[hidden email]> wrote:
>
> Hi Sven,
>
> On Sat, 16 Mar 2019 at 20:16, Sven Van Caekenberghe <[hidden email]> wrote:
>>
>> Since there is #peek there is no reason not to add #peekFor: as
>>
>> peekFor: object
>>  "Answer false and do not move over the next element if it is not equal to object, or if the receiver is at the end.
>>   Answer true and move over the next element when it is equal to object."
>>
>>  ^ self peek = object
>>      ifTrue: [
>>        self next.
>>        true ]
>>      ifFalse: [ false ]
>
> Great, thanks.
>
> I'm happy to submit a PR, but vaguely remember that submitting it to
> pharo-project/pharo creates more work for you.  Where should this be
> submitted (and in general for Zinc submissions)?
>
> Thanks again,
> Alistair
>
>
>
>> But note that the Zdc socket streams do not make a difference between synchronous / asynchronous - IIRC I would say they block (they are also always binary and flush when their buffer is full).
>>
>> Peeking in the context of a socket / network stream will block, just like reading.
>>
>>> On 16 Mar 2019, at 19:44, Alistair Grant <[hidden email]> wrote:
>>>
>>> Hi Esteban,
>>> On Sat, 16 Mar 2019 at 19:37, Esteban Maringolo <[hidden email]> wrote:
>>>>
>>>> I don't know the answer but how could you peek for data that has yet not come through the socket? In the buffer? Should it block?
>>>
>>> From memory: It depends on the mode of the stream:
>>>
>>> If synchronous: peeking will block until data is available.
>>> If asynchronous: if data is available, the next byte / character is
>>> returned.  If no data is available, nil is returned.  If nil is
>>> returned, you need to check if the socked is #atEnd to determine
>>> whether it is the end of the stream or just nothing available now.
>>>
>>> Cheers,
>>> Alistair
>>>
>>>
>>>
>>>> Regards.
>>>>
>>>> El sáb., 16 de mar. de 2019 12:23, Alistair Grant <[hidden email]> escribió:
>>>>>
>>>>> Hi Sven,
>>>>>
>>>>> Unlike most streams that support #peek, ZdcAbstractSocketStream
>>>>> doesn't support #peekFor:.
>>>>>
>>>>> Is this intentional, or an oversight?
>>>>>
>>>>> Thanks,
>>>>> Alistair

> > On 16 Mar 2019, at 20:23, Alistair Grant <[hidden email]> wrote:
> >
> > Hi Sven,
> >
> > On Sat, 16 Mar 2019 at 20:16, Sven Van Caekenberghe <[hidden email]> wrote:
> >>
> >> Since there is #peek there is no reason not to add #peekFor: as
> >>
> >> peekFor: object
> >>  "Answer false and do not move over the next element if it is not equal to object, or if the receiver is at the end.
> >>   Answer true and move over the next element when it is equal to object."
> >>
> >>  ^ self peek = object
> >>      ifTrue: [
> >>        self next.
> >>        true ]
> >>      ifFalse: [ false ]
> >
> > Great, thanks.
> >
> > I'm happy to submit a PR, but vaguely remember that submitting it to
> > pharo-project/pharo creates more work for you.  Where should this be
> > submitted (and in general for Zinc submissions)?
> >
> > Thanks again,
> > Alistair
> >
> >
> >
> >> But note that the Zdc socket streams do not make a difference between synchronous / asynchronous - IIRC I would say they block (they are also always binary and flush when their buffer is full).
> >>
> >> Peeking in the context of a socket / network stream will block, just like reading.
> >>
> >>> On 16 Mar 2019, at 19:44, Alistair Grant <[hidden email]> wrote:
> >>>
> >>> Hi Esteban,
> >>> On Sat, 16 Mar 2019 at 19:37, Esteban Maringolo <[hidden email]> wrote:
> >>>>
> >>>> I don't know the answer but how could you peek for data that has yet not come through the socket? In the buffer? Should it block?
> >>>
> >>> From memory: It depends on the mode of the stream:
> >>>
> >>> If synchronous: peeking will block until data is available.
> >>> If asynchronous: if data is available, the next byte / character is
> >>> returned.  If no data is available, nil is returned.  If nil is
> >>> returned, you need to check if the socked is #atEnd to determine
> >>> whether it is the end of the stream or just nothing available now.
> >>>
> >>> Cheers,
> >>> Alistair
> >>>
> >>>
> >>>
> >>>> Regards.
> >>>>
> >>>> El sáb., 16 de mar. de 2019 12:23, Alistair Grant <[hidden email]> escribió:
> >>>>>
> >>>>> Hi Sven,
> >>>>>
> >>>>> Unlike most streams that support #peek, ZdcAbstractSocketStream
> >>>>> doesn't support #peekFor:.
> >>>>>
> >>>>> Is this intentional, or an oversight?
> >>>>>
> >>>>> Thanks,
> >>>>> Alistair
>
>

> On 17 Mar 2019, at 08:45, Alistair Grant <[hidden email]> wrote:
>
> Hi Sven,
>
>
> On Sat, 16 Mar 2019 at 20:28, Sven Van Caekenberghe <[hidden email]> wrote:
>>
>> Here please, https://github.com/svenvc/zodiac
>
> Done.   The changes were made in Pharo 8 and it's added lots of
> methodProperties.json files.  I assume this is because you haven't had
> to make changes since Iceberg was updated.  Let me know if it is a
> problem.
>
> Thanks,
> Alistair
>
>
>>> On 16 Mar 2019, at 20:23, Alistair Grant <[hidden email]> wrote:
>>>
>>> Hi Sven,
>>>
>>> On Sat, 16 Mar 2019 at 20:16, Sven Van Caekenberghe <[hidden email]> wrote:
>>>>
>>>> Since there is #peek there is no reason not to add #peekFor: as
>>>>
>>>> peekFor: object
>>>> "Answer false and do not move over the next element if it is not equal to object, or if the receiver is at the end.
>>>>  Answer true and move over the next element when it is equal to object."
>>>>
>>>> ^ self peek = object
>>>>     ifTrue: [
>>>>       self next.
>>>>       true ]
>>>>     ifFalse: [ false ]
>>>
>>> Great, thanks.
>>>
>>> I'm happy to submit a PR, but vaguely remember that submitting it to
>>> pharo-project/pharo creates more work for you.  Where should this be
>>> submitted (and in general for Zinc submissions)?
>>>
>>> Thanks again,
>>> Alistair
>>>
>>>
>>>
>>>> But note that the Zdc socket streams do not make a difference between synchronous / asynchronous - IIRC I would say they block (they are also always binary and flush when their buffer is full).
>>>>
>>>> Peeking in the context of a socket / network stream will block, just like reading.
>>>>
>>>>> On 16 Mar 2019, at 19:44, Alistair Grant <[hidden email]> wrote:
>>>>>
>>>>> Hi Esteban,
>>>>> On Sat, 16 Mar 2019 at 19:37, Esteban Maringolo <[hidden email]> wrote:
>>>>>>
>>>>>> I don't know the answer but how could you peek for data that has yet not come through the socket? In the buffer? Should it block?
>>>>>
>>>>> From memory: It depends on the mode of the stream:
>>>>>
>>>>> If synchronous: peeking will block until data is available.
>>>>> If asynchronous: if data is available, the next byte / character is
>>>>> returned.  If no data is available, nil is returned.  If nil is
>>>>> returned, you need to check if the socked is #atEnd to determine
>>>>> whether it is the end of the stream or just nothing available now.
>>>>>
>>>>> Cheers,
>>>>> Alistair
>>>>>
>>>>>
>>>>>
>>>>>> Regards.
>>>>>>
>>>>>> El sáb., 16 de mar. de 2019 12:23, Alistair Grant <[hidden email]> escribió:
>>>>>>>
>>>>>>> Hi Sven,
>>>>>>>
>>>>>>> Unlike most streams that support #peek, ZdcAbstractSocketStream
>>>>>>> doesn't support #peekFor:.
>>>>>>>
>>>>>>> Is this intentional, or an oversight?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Alistair
>>
>>
>