March 2020 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Pharo #sum vs #sumNumbers and the consequence of #average

by Richard O'Keefe

Yes, #(0 0 0) is the additive identity in *that* case. But in #((1 2) (3 4) (5 6)) sum it is #(0 0). And in #(((1 2 3) (4 5 6)) ((9 8 7) (6 5 4))) sum ==> #(#(10 10 10) #(10 10 10)) it is #((0 0 0) (0 0 0)). I suppose you could have SequenceableCollection>>zero ^self collect: [:each | each zero] The point is that it cannot in general be based on the *class* of some element of the receiver but depends on the *value*. But then we run into the amusing cases like { 1 hour. DateAndTime now} sum where an additive identity for Durations makes sense but an additive identity for DateAndTimes does not, and similarly {Date today. 1} sum In my case, an additional problem is that I have Object Enumerable (#sum and #product go here) Collection where Enumerable holds everything that can be defined just using #do: without assuming that you can do it more than once, so it was necessary to come up with a streaming definition for #sum that examines each element once and only once. When you do that, you discover that you don't *need* a zero except when the collection is empty, and in that case you can't *tell* what sort of zero would be appropriate. On Thu, 26 Mar 2020 at 01:00, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > #(0 0 0) is the additive identity in that case > > > On 25 Mar 2020, at 12:38, Richard O'Keefe <raoknz(a)gmail.com> wrote: > > > > There are situations where #+ and #sum make sense but there is no additive > > identity. Here is an example: > > #((1 2 3) (4 5 6) (7 8 9)) sum > > > > On Tue, 24 Mar 2020 at 02:46, James Foster <Smalltalk(a)jgfoster.net> wrote: > >> > >> > >>> On Mar 23, 2020, at 6:06 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >>> > >>> What you found out now is that the clever trick used to avoid picking an additive identity (picking an element, counting it twice and then subtracting it) leads to a loss of precision when floating point numbers are involved. This is an important issue. > >> > >> If this approach is to be preserved, then each class should have an additive identity so instead of adding and subtracting an object, we let the object tell us its zero. > >> > >> James > > > >

March 25, 2020

Re: [Pharo-users] Do we have a simple markdown parser?

by Richard O'Keefe

Much depends on what you mean by "Markdown". The current version of the CommonMark spec https://spec.commonmark.org/0.29/ comes to 124 printed pages. Mind you, some of that is background, some of it is advice about how to parse Markdown, and a lot of it is 500 examples. If I wanted to process Markdown in Smalltalk, I'd probably use the CommonMark reference implementation in C (cmark) to convert Markdown to XML and parse the XML. Alternatively, call libcmark through the foreign function interface. On Wed, 25 Mar 2020 at 06:52, Tim Mackinnon <tim(a)testit.works> wrote: > > Hi guys - do we have a simple markdown parser that is reasonably up to date? I did a quick GitHub scan and a few popped out, but I wasnât convinced I had found one the âeveryoneâ uses (albeit, everyone might be a small sample). > > Ideally I donât want to get sucked into writing another one (a project for a future time). > > Tim

March 25, 2020

Re: [Pharo-users] Pharo #sum vs #sumNumbers and the consequence of #average

by Sven Van Caekenberghe

#(0 0 0) is the additive identity in that case > On 25 Mar 2020, at 12:38, Richard O'Keefe <raoknz(a)gmail.com> wrote: > > There are situations where #+ and #sum make sense but there is no additive > identity. Here is an example: > #((1 2 3) (4 5 6) (7 8 9)) sum > > On Tue, 24 Mar 2020 at 02:46, James Foster <Smalltalk(a)jgfoster.net> wrote: >> >> >>> On Mar 23, 2020, at 6:06 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>> What you found out now is that the clever trick used to avoid picking an additive identity (picking an element, counting it twice and then subtracting it) leads to a loss of precision when floating point numbers are involved. This is an important issue. >> >> If this approach is to be preserved, then each class should have an additive identity so instead of adding and subtracting an object, we let the object tell us its zero. >> >> James >

March 25, 2020

Re: [Pharo-users] Pharo #sum vs #sumNumbers and the consequence of #average

by Richard O'Keefe

There are situations where #+ and #sum make sense but there is no additive identity. Here is an example: #((1 2 3) (4 5 6) (7 8 9)) sum On Tue, 24 Mar 2020 at 02:46, James Foster <Smalltalk(a)jgfoster.net> wrote: > > > > On Mar 23, 2020, at 6:06 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > What you found out now is that the clever trick used to avoid picking an additive identity (picking an element, counting it twice and then subtracting it) leads to a loss of precision when floating point numbers are involved. This is an important issue. > > If this approach is to be preserved, then each class should have an additive identity so instead of adding and subtracting an object, we let the object tell us its zero. > > James

March 25, 2020

Re: [Pharo-users] Pharo #sum vs #sumNumbers and the consequence of #average

by Richard O'Keefe

What's wrong with this definition? sum "(1) This used to use #runsDo:, which can lead to big savings on bags and runarrays, but we almost never use this method on them, so it didn't pay off. (2) The obvious initialisation to 0 doesn't work with a collection of Money, Quantities, Durations, and so on. (3) Since the receiver is almost always a collection of numbers, it would be very bad if #() sum did not answer 0. So we should not use #anyOne. (4) Using #anyOne to select between algorithms required being able to traverse the Enumerable twice, but Enumerable is for things you can only traverse once. Oops. Good thing we want to avoid #anyOne anyway. (5) nil does not and should not respondTo: #+ so we can use a single variable. Watch out for this in other summaries." |s| s := nil. self do: [:each | s := s ifNil: [each] ifNotNil: [each + s]]. ^s ifNil: [0] ifNotNil: [s] On Tue, 24 Mar 2020 at 02:46, James Foster <Smalltalk(a)jgfoster.net> wrote: > > > > On Mar 23, 2020, at 6:06 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > What you found out now is that the clever trick used to avoid picking an additive identity (picking an element, counting it twice and then subtracting it) leads to a loss of precision when floating point numbers are involved. This is an important issue. > > If this approach is to be preserved, then each class should have an additive identity so instead of adding and subtracting an object, we let the object tell us its zero. > > James

March 25, 2020

Re: [Pharo-users] Do we have a simple markdown parser?

by Kasper Osterbye

I have a github-markdown which translates into pillar - and from pillar you can get many things. It is lacking several aspects, as I personally was most interested in rendering it inside pharo. The major thing missing (because I could not figure out how to render them) is tables. But take a look at: https://github.com/kasperosterbye/PillarRichTextRender But perhaps it is better than nothing - your usage scenario is not quite clear to me. Best, Kasper On Tue, Mar 24, 2020 at 10:12 PM Tim Mackinnon <tim(a)testit.works> wrote: > Hmm I hadnât even thought of Xstreamsâ¦ I always thought it sounded cool, > perhaps its a place to start - but as you mention, Iâm not sure it really > gained traction in the Pharo world. My use case is quite simple as the > markdown files are simple configuration (and maybe donât even need a parser > - e.g. > https://github.com/servirtium/demo-java-climate-tck/blob/master/src/test/mo…) > I was hoping there might be something simple I could run with to help > explore how best to use the config in those files. > > Lets see if anyone else mentions something thatâs a no-brainer. > > Tim > > On 24 Mar 2020, at 18:40, gettimothy via Pharo-users < > pharo-users(a)lists.pharo.org> wrote: > > > *From: *gettimothy <gettimothy(a)zoho.com> > *Subject: **Re: [Pharo-users] Do we have a simple markdown parser?* > *Date: *24 March 2020 at 18:40:42 GMT > *To: *"Any question about pharo is welcome" <pharo-users(a)lists.pharo.org> > *Cc: *"Pharo Users Newsgroup" <pharo-users(a)lists.pharo.org> > > > I do not know if it works on Pharo, but XTreams has a XTreams-Parsing > section that I am currently working with. The existing Wikitext grammar was > my starting point . > > > https://github.com/squeak-smalltalk/squeak-ci/blob/master/package-load-scri… > > the existing Grammar is under: > > XTreams-Parsing -> PEGParser > grammars->grammarWiki > > > Use case is: > > > | wikiGrammar wikiParser output| > Transcript clear. > wikiGrammar := PEGParser grammarWiki reading positioning. > wikiParser := PEGParser parserPEG parse: 'Grammar' stream: wikiGrammar > actor: PEGParserParser new. > input := (your string input goes here) > output := wikiParser parse: 'Page' stream: input actor: PEGWikiGenerator > new. > output inspect. > > > hth > > ---- On Tue, 24 Mar 2020 13:51:31 -0400 *Tim Mackinnon <tim(a)testit.works > <tim(a)testit.works>>* wrote ---- > > Hi guys - do we have a simple markdown parser that is reasonably up to > date? I did a quick GitHub scan and a few popped out, but I wasnât > convinced I had found one the âeveryoneâ uses (albeit, everyone might be a > small sample). > > Ideally I donât want to get sucked into writing another one (a project for > a future time). > > Tim > > > > > > >

March 24, 2020

Re: [Pharo-users] Do we have a simple markdown parser?

by Tim Mackinnon

Hmm I hadnât even thought of Xstreamsâ¦ I always thought it sounded cool, perhaps its a place to start - but as you mention, Iâm not sure it really gained traction in the Pharo world. My use case is quite simple as the markdown files are simple configuration (and maybe donât even need a parser - e.g. https://github.com/servirtium/demo-java-climate-tck/blob/master/src/test/mo… <https://github.com/servirtium/demo-java-climate-tck/blob/master/src/test/mo…>). I was hoping there might be something simple I could run with to help explore how best to use the config in those files. Lets see if anyone else mentions something thatâs a no-brainer. Tim > On 24 Mar 2020, at 18:40, gettimothy via Pharo-users <pharo-users(a)lists.pharo.org <mailto:pharo-users@lists.pharo.org>> wrote: > > > From: gettimothy <gettimothy(a)zoho.com <mailto:gettimothy@zoho.com>> > Subject: Re: [Pharo-users] Do we have a simple markdown parser? > Date: 24 March 2020 at 18:40:42 GMT > To: "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org <mailto:pharo-users@lists.pharo.org>> > Cc: "Pharo Users Newsgroup" <pharo-users(a)lists.pharo.org <mailto:pharo-users@lists.pharo.org>> > > > I do not know if it works on Pharo, but XTreams has a XTreams-Parsing section that I am currently working with. The existing Wikitext grammar was my starting point . > > https://github.com/squeak-smalltalk/squeak-ci/blob/master/package-load-scri… <https://github.com/squeak-smalltalk/squeak-ci/blob/master/package-load-scri…> > > the existing Grammar is under: > > XTreams-Parsing -> PEGParser > grammars->grammarWiki > > > Use case is: > > > | wikiGrammar wikiParser output| > Transcript clear. > wikiGrammar := PEGParser grammarWiki reading positioning. > wikiParser := PEGParser parserPEG parse: 'Grammar' stream: wikiGrammar actor: PEGParserParser new. > input := (your string input goes here) > output := wikiParser parse: 'Page' stream: input actor: PEGWikiGenerator new. > output inspect. > > hth > > ---- On Tue, 24 Mar 2020 13:51:31 -0400 Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>> wrote ---- > > Hi guys - do we have a simple markdown parser that is reasonably up to date? I did a quick GitHub scan and a few popped out, but I wasnât convinced I had found one the âeveryoneâ uses (albeit, everyone might be a small sample). > > Ideally I donât want to get sucked into writing another one (a project for a future time). > > Tim > > > >

March 24, 2020

Re: [Pharo-users] Do we have a simple markdown parser?

by Tim Mackinnon

Thanks Eric - I did have a peek at Phoedown (as I did recall that announcement) but as my use case is for a generic library for testing (that I could potentially share with the wider community), I wasnât convince that needing a separate dependency would fly (for an own standalone project it did seem like a good bet and very comprehensive). > On 24 Mar 2020, at 17:56, Eric Gade <eric.gade(a)gmail.com> wrote: > > Hi Tim, > > I was looking into this the other day (along with the potential native implementation) and remembered this was posted in Discord: > https://github.com/PierceNg/Phoedown <https://github.com/PierceNg/Phoedown> > > It uses an existing C based markdown parsing library via FFI. > > Evidently, it is quite difficult to make a Markdown parser because there can be a lot of ambiguity. Would be cool to have a full Smalltalk implementation though. > > On Tue, Mar 24, 2020 at 1:52 PM Tim Mackinnon <tim(a)testit.works> wrote: > Hi guys - do we have a simple markdown parser that is reasonably up to date? I did a quick GitHub scan and a few popped out, but I wasnât convinced I had found one the âeveryoneâ uses (albeit, everyone might be a small sample). > > Ideally I donât want to get sucked into writing another one (a project for a future time). > > Tim > > > -- > Eric

March 24, 2020

Re: [Pharo-users] Do we have a simple markdown parser?

by gettimothy

I do not know if it works on Pharo, but XTreams has a XTreams-Parsing section that I am currently working with. The existing Wikitext grammar was my starting point . https://github.com/squeak-smalltalk/squeak-ci/blob/master/package-load-scri… the existing Grammar is under: XTreams-Parsing -> PEGParser > grammars->grammarWiki Use case is: | wikiGrammar wikiParser output| Transcript clear. wikiGrammar := PEGParser grammarWiki reading positioning. wikiParser := PEGParser parserPEG parse: 'Grammar' stream: wikiGrammar actor: PEGParserParser new. input := (your string input goes here) output := wikiParser parse: 'Page' stream: input actor: PEGWikiGenerator new. output inspect. hth ---- On Tue, 24 Mar 2020 13:51:31 -0400 Tim Mackinnon <mailto:tim@testit.works> wrote ---- Hi guys - do we have a simple markdown parser that is reasonably up to date? I did a quick GitHub scan and a few popped out, but I wasnât convinced I had found one the âeveryoneâ uses (albeit, everyone might be a small sample). Ideally I donât want to get sucked into writing another one (a project for a future time). Tim

March 24, 2020

Re: [Pharo-users] Do we have a simple markdown parser?

by Eric Gade

Hi Tim, I was looking into this the other day (along with the potential native implementation) and remembered this was posted in Discord: https://github.com/PierceNg/Phoedown It uses an existing C based markdown parsing library via FFI. Evidently, it is quite difficult to make a Markdown parser because there can be a lot of ambiguity. Would be cool to have a full Smalltalk implementation though. On Tue, Mar 24, 2020 at 1:52 PM Tim Mackinnon <tim(a)testit.works> wrote: > Hi guys - do we have a simple markdown parser that is reasonably up to > date? I did a quick GitHub scan and a few popped out, but I wasnât > convinced I had found one the âeveryoneâ uses (albeit, everyone might be a > small sample). > > Ideally I donât want to get sucked into writing another one (a project for > a future time). > > Tim > -- Eric

March 24, 2020