- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] ZnBufferedReadStream and #upToAll:

by Eric Gade

Thanks Stef, I imagine that sven did not add it because on infinite stream it does not > make sense. > Just to clarify my earlier email, I got here was by calling `'/path/to/some/file' asFileReference binaryReadStream` which responds with the ZnBufferedReadStream. I expected to be able to use something like #upToAll: to find binary-formatted headers etc within some encoding structure. It's entirely possible that this was the wrong expectation! On Sun, Mar 17, 2019 at 10:38 AM ducasse <stepharo(a)netcourrier.com> wrote: > Hi eric > > > Hi all, > > > > Was there a conscious decision not to include the #upToAll: method > onZnBufferedReadStream?. This method is really useful for parsing files -- > finding sub-patterns of bytes, etc. Perhaps #upToAll: is not the idiomatic > way to do this, but I found it very useful to use in the plain old > ReadStream classes. > > I imagine that sven did not add it because on infinite stream it does not > make sense. > Now it would be good to see how we can have useful extensions. But I let > this to sven. > > > > Sub-question: if I wanted to implement something like this and make a > PR, would I be submitting to the Pharo dev repository or the Zinc > repository? > > Right now to sven repo. In the future we want to have better tools to sync > back from a project to its components. > > Stef > > > > -- > > Eric > > > > -- Eric

March 17, 2019

Re: [Pharo-dev] ZnBufferedReadStream and #upToAll:

by ducasse

Hi eric > Hi all, > > Was there a conscious decision not to include the #upToAll: method onZnBufferedReadStream?. This method is really useful for parsing files -- finding sub-patterns of bytes, etc. Perhaps #upToAll: is not the idiomatic way to do this, but I found it very useful to use in the plain old ReadStream classes. I imagine that sven did not add it because on infinite stream it does not make sense. Now it would be good to see how we can have useful extensions. But I let this to sven. > > Sub-question: if I wanted to implement something like this and make a PR, would I be submitting to the Pharo dev repository or the Zinc repository? Right now to sven repo. In the future we want to have better tools to sync back from a project to its components. Stef > > -- > Eric

March 17, 2019

ZnBufferedReadStream and #upToAll:

by Eric Gade

Hi all, Was there a conscious decision not to include the #upToAll: method onZnBufferedReadStream?. This method is really useful for parsing files -- finding sub-patterns of bytes, etc. Perhaps #upToAll: is not the idiomatic way to do this, but I found it very useful to use in the plain old ReadStream classes. Sub-question: if I wanted to implement something like this and make a PR, would I be submitting to the Pharo dev repository or the Zinc repository? -- Eric

March 17, 2019

is haltOnce working in P8?

by StÃ©phane Ducasse

Because I have experiences showing me that haltOnce is executed multiple times. Stef -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr http://www.synectique.eu / http://www.pharo.org 03 59 35 87 52 Assistant: Julie Jonas FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

March 17, 2019

Re: [Pharo-dev] [Pharo-users] [ANN] Lan.d.s Alpha: All Along the Language Tower

by StÃ©phane Ducasse

Hi nick I wanted to support your chapters via paypal but it asked me about my visa and I would like to pay via my paypal account. Do you know if this is possible? Else can you send me your pp account? Stef > On 17 Mar 2019, at 10:21, Nick Papoylias <npapoylias(a)gmail.com> wrote: > > 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/ <https://npapoylias.gitlab.io/lands-project/> > > Accompanied by ~ 30 min of transcribed eye-candy: > > https://www.youtube.com/playlist?list=PLIjPQnRzAKVHABG1-oTvwWc3Gj1Z4C91B <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://www.patreon.com/lands_project> > https://npapoylias.gitlab.io/lands-project/Support/ <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 ! > <Theory-and-Applications-Of-Multi-Ordered-Grammars.pdf><Lands-Alpha-All-Along-The-Language-Tower.png> -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr http://www.synectique.eu / http://www.pharo.org 03 59 35 87 52 Assistant: Julie Jonas FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

March 17, 2019

[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