March 2019 - Pharo-dev - lists.pharo.org

[ANN] Lan.d.s Alpha: All Along the Language Tower

by Nick Papoylias

*Dear friends ! * I am quite excited to announce the availability of an alpha version of my latest work around *Parsing and Programming Languages* at: https://npapoylias.gitlab.io/lands-project/ Accompanied by ~ *30 min of transcribed eye-candy:* https://www.youtube.com/playlist?list=PLIjPQnRzAKVHABG1-oTvwWc3Gj1Z4C91B Backed by *a crowdfunding campaign* ! To get the *book and stable release * successfully out of the door: https://www.patreon.com/lands_project https://npapoylias.gitlab.io/lands-project/Support/ *Click, download, watch, enjoy !* If you like what you see, support the project ! Tiers start *from 5 and 10 euros per chapter for individuals.* Companies supporting the project can get *6 to 12 days of consultancy, on-site workshops and other perks.* ================= *What is all about ??* *Lan.d.s is a new solution for language design.* From *general purpose * *languages* like *Lise* (short for (list (embedding)) to *Domain-Specific * *Languages using the MOODs framework*, and everything else in between. Lan.d.s is build around the formalism of *Multi-Ordered Grammars, * *which are a possible alternative to CFGs and PEGs in wider use today. * Multi-ordered grammars (or simply MOGs) aim for a better exploration of ambiguity, recursion, ordering and associativity during language design. They can be *parsed using the * *Gray Algorithm.* After parsing in order to ease the production of executable code Lan.d.s introduces the* Abstract Syntax Language (ASL),* which is an OO solution for compile-time meta-programming. Finally in order to promote language extension and re-use, Lan.d.s employs *GrammarTraits, as units of * *composition for both MOG rules and ASL actions.* ================= Some random highlights for the impatient: ** Object subclass: #Prediction uses: Future syntax* ** Languages are everywhere, they are all around you, even now in this very sentence.* ** Study SICP with a Xerox flavor, while re-inventing some Bell-labs utilities.* ** TOC-Board, the TOC for your next talk ;)* Enjoy !

March 17, 2019

[Pharo 8.0] Build #144: 2753-betterFileVersionExtraction

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

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

March 17, 2019

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

by Alistair Grant

Hi Sven, On Sat, 16 Mar 2019 at 20:28, Sven Van Caekenberghe <sven(a)stfx.eu> 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 <akgrant0710(a)gmail.com> wrote: > > > > 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 17, 2019

ZnMimePart

by Alistair Grant

Hi Sven, I'm trying to parse maildir emails using ZnMimePart and have a few questions: 1. The standard indicates that text lines should be terminated with CRLF, however in practice many maildir format emails (as saved by offlineimap and successfully handled by mutt) use LF. Are you open to modifying the parser to be a bit more forgiving, and allow CRLF, LF or CR? I could then completely deprecate MIMEDocument from the image and make MailMessage a bit more useful. 2. ZnStringEntity and ZnByteArrayEntity both appear to answer their contents without decoding the data based on the Content-Transfer-Encoding, e.g. if I have: Date: Sat, 16 Mar 2019 12:00:21 +0100 MIME-Version: 1.0 Content-Type: image/jpeg; name="00585-capture.jpg" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="00585-capture.jpg" base64dataincludedhere... and send: aZmMimePart contents I'll get back the the result of evaluating: 'base64dataincludedhere...' asByteArray instead of the decoded data. Is this intended? I'd expect the decoded data (with charset decoding as well, in the case of text). 3. What do you think of adding a few convenience test methods, e.g. isImage, isApplication, isText, etc.? Thanks, Alistair

March 17, 2019

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

by Sven Van Caekenberghe

Here please, https://github.com/svenvc/zodiac > On 16 Mar 2019, at 20:23, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > 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 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