- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] ZdcAbstractSocketStream>>peekFor:?

by Alistair Grant

Hi Sven, On Sat, 16 Mar 2019 at 20:16, Sven Van Caekenberghe <sven(a)stfx.eu> 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 <akgrant0710(a)gmail.com> wrote: > > > > Hi Esteban, > > On Sat, 16 Mar 2019 at 19:37, Esteban Maringolo <emaringolo(a)gmail.com> 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 <akgrant0710(a)gmail.com> escribiÃ³: > >>> > >>> Hi Sven, > >>> > >>> Unlike most streams that support #peek, ZdcAbstractSocketStream > >>> doesn't support #peekFor:. > >>> > >>> Is this intentional, or an oversight? > >>> > >>> Thanks, > >>> Alistair > >>> > > > >

March 16, 2019

Re: [Pharo-dev] ZdcAbstractSocketStream>>peekFor:?

by Sven Van Caekenberghe

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 <akgrant0710(a)gmail.com> wrote: > > Hi Esteban, > On Sat, 16 Mar 2019 at 19:37, Esteban Maringolo <emaringolo(a)gmail.com> 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 <akgrant0710(a)gmail.com> escribiÃ³: >>> >>> Hi Sven, >>> >>> Unlike most streams that support #peek, ZdcAbstractSocketStream >>> doesn't support #peekFor:. >>> >>> Is this intentional, or an oversight? >>> >>> Thanks, >>> Alistair >>> >

March 16, 2019

Re: [Pharo-dev] ZdcAbstractSocketStream>>peekFor:?

by Alistair Grant

Hi Esteban, On Sat, 16 Mar 2019 at 19:37, Esteban Maringolo <emaringolo(a)gmail.com> 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 <akgrant0710(a)gmail.com> escribiÃ³: >> >> Hi Sven, >> >> Unlike most streams that support #peek, ZdcAbstractSocketStream >> doesn't support #peekFor:. >> >> Is this intentional, or an oversight? >> >> Thanks, >> Alistair >>

March 16, 2019

Re: [Pharo-dev] ZdcAbstractSocketStream>>peekFor:?

by Esteban Maringolo

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? Regards. El sÃ¡b., 16 de mar. de 2019 12:23, Alistair Grant <akgrant0710(a)gmail.com> escribiÃ³: > Hi Sven, > > Unlike most streams that support #peek, ZdcAbstractSocketStream > doesn't support #peekFor:. > > Is this intentional, or an oversight? > > Thanks, > Alistair > >

March 16, 2019

Re: [Pharo-dev] OSProcess for Pharo 7

by Sean P. DeNigris

ducasse wrote > Our main problem is that > - if more people would review PR > - send PRs Thank you for the reminder of that bottleneck. I will try to do that more now that we have moved to GH. The old process seemed too cumbersome to be able to effectively utilize a few free moments here and there, but I suspect that no longer to be the case. ducasse wrote > this is not because we do not care of Pharo that we will fix it > immediately. Yes of course, just want to keep it on the radar (and maybe Mariano will read he he) ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

March 16, 2019

ZdcAbstractSocketStream>>peekFor:?

by Alistair Grant

Hi Sven, Unlike most streams that support #peek, ZdcAbstractSocketStream doesn't support #peekFor:. Is this intentional, or an oversight? Thanks, Alistair

March 16, 2019

[Pharo 8.0] Build #143: 2839-Clean-AthensTest

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #143 was: SUCCESS. The Pull Request #2840 was integrated: "2839-Clean-AthensTest" Pull request url: https://github.com/pharo-project/pharo/pull/2840 Issue Url: https://pharo.fogbugz.com/f/cases/2839 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 16, 2019

Who is using NodeNavigation?

by ducasse

Hi May be this is too early for my brain to fully work. But I cannot find users of NodeNavigation except the deprecated PluggableTextMorph since it is unused I propose to deprecate it. Any thoughts? Stef

March 16, 2019

[Pharo 8.0] Build #142: 2824-unify-and-cleanup-compactAll-OrderedCollection

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #142 was: SUCCESS. The Pull Request #2825 was integrated: "2824-unify-and-cleanup-compactAll-OrderedCollection" Pull request url: https://github.com/pharo-project/pharo/pull/2825 Issue Url: https://pharo.fogbugz.com/f/cases/2824 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 15, 2019

Re: [Pharo-dev] OSProcess for Pharo 7

by ducasse

Hi sean You see we are terribly busy working on a lot of cleaning in Spec. This is massive and this is super important for our roadmap. Guille and Pablo produce 600 tests. We are fixing duplication with Alain. Our main problem is that - if more people would review PR - send PRs Then we could free some times for other less urgent issues. For example, this is three years that Iâm waiting to remove duplicated code (PluggableTextMorph, PluggableTextInputField, TextEditor,â¦. Now we have to do it and this for many other points. So this is good that you mention it, but this is not because we do not care of Pharo that we will fix it immediately. Stef > On 15 Mar 2019, at 19:42, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Max Leske wrote >>> I was talking about OSSubProcess >> Well, I'm not working with that at the moment ;) > > [OT] Just want to bump the problem that OSProcess and OSSubProcess can't > currently be used in the same image. This is an important problem because > users can't control which library dependencies use. Mariano hinted at a > solution. It didn't seem like a ton of work, but it's beyond my > understanding. > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

March 15, 2019