October 2018 - Pharo-users - lists.pharo.org

ring deprecation in pharo 7

by Tudor Girba

Hi, Ring seems to be deprecated in Pharo 7. Is there something else it will be replaced with? In particular, I am looking for the correct class that should correspond to RGMethodDefinition. Cheers, Doru -- www.feenk.com "Value is always contextual."

Oct. 19, 2018

Re: [Pharo-users] library to chain select:/collect:/ ... via cascade

by Steffen MÃ¤rcker

Another important difference is that no intermediate collections are built. In contrast, chaining x enumeration statements #select:, #collect:, etc. iterates x times over the collection elements and builds x-1 intermediate collections. Am .10.2018, 11:59 Uhr, schrieb Steffen MÃ¤rcker <merkste(a)web.de>: > Hi, > > indeed, transducers provided a way to achieve this, e.g. > > #(12 7 'a' nil #(0)) pipe > filter: #notNil; > filter: #isNumber; > map: #squared; > filter: #even; > into: OrderedCollection. > > But this feature is deprecated, as it was not that useful. The preferred > way to do this is either: > > #(12 7 'a' nil #(0)) > transduce: #notNil filter * #isNumber filter * squared map * #even > filter > reduce: Set accumulate. > > or: > > Set <~ #even filter > <~ #squared map > <~ #isNumber filter > <~ #notNil filter > <~ #(12 7 'a' nil #(0)). > > The advantage of the transducer approach is that it decouples > filtering/mapping/etc. from iteration and aggregation. This facilitates > reuse and makes it trivial to provide all operations to new custom data > types. > > However, I didn't have time to finish the Pharo port of Transducers, > yet. Hence, the a current version is available in Cincom's Public Store > or (most current) directly from me only. But if you are interested and > have a nice use case, I'd be happy to help out. > > Best, Steffen > > > Am .10.2018, 08:45 Uhr, schrieb Julien <julien.delplanque(a)inria.fr>: > >> I think this was the idea of Transducers as well. >> >> Julien >> >> --- >> Julien Delplanque >> Doctorant Ã lâUniversitÃ© de Lille >> http://juliendelplanque.be/phd.html >> Equipe Rmod, Inria >> BÃ¢timent B 40, Avenue Halley 59650 Villeneuve d'Ascq >> NumÃ©ro de tÃ©lÃ©phone: +333 59 35 86 40 >> <---Schnitt---> >

Oct. 19, 2018

Re: [Pharo-users] library to chain select:/collect:/ ... via cascade

by Steffen MÃ¤rcker

Hi, indeed, transducers provided a way to achieve this, e.g. #(12 7 'a' nil #(0)) pipe filter: #notNil; filter: #isNumber; map: #squared; filter: #even; into: OrderedCollection. But this feature is deprecated, as it was not that useful. The preferred way to do this is either: #(12 7 'a' nil #(0)) transduce: #notNil filter * #isNumber filter * squared map * #even filter reduce: Set accumulate. or: Set <~ #even filter <~ #squared map <~ #isNumber filter <~ #notNil filter <~ #(12 7 'a' nil #(0)). The advantage of the transducer approach is that it decouples filtering/mapping/etc. from iteration and aggregation. This facilitates reuse and makes it trivial to provide all operations to new custom data types. However, I didn't have time to finish the Pharo port of Transducers, yet. Hence, the a current version is available in Cincom's Public Store or (most current) directly from me only. But if you are interested and have a nice use case, I'd be happy to help out. Best, Steffen Am .10.2018, 08:45 Uhr, schrieb Julien <julien.delplanque(a)inria.fr>: > I think this was the idea of Transducers as well. > > Julien > > --- > Julien Delplanque > Doctorant Ã lâUniversitÃ© de Lille > http://juliendelplanque.be/phd.html > Equipe Rmod, Inria > BÃ¢timent B 40, Avenue Halley 59650 Villeneuve d'Ascq > NumÃ©ro de tÃ©lÃ©phone: +333 59 35 86 40 > >> Le 17 oct. 2018 Ã 09:13, Peter Uhnak <i.uhnak(a)gmail.com> a Ã©crit : >> >> Hi, >> >> is there some library that will allow me to chain select:/collect:/... >> via cascade? >> >> E.g. >> >> #(12 7 'a' nil #(0)) query reject: #isNil; select: #isNumber; collect: >> #squared; select: #even? >> >> The point is to not have to write billion parentheses when building a >> more complex query. >> >> I imagine this would be pretty easy to write, but figured I ask first. >> >> Thanks, >> Peter

Oct. 19, 2018

Re: [Pharo-users] Pharo2VW (Was:[vwnc] Parsing in Smalltalk)

by Steffen MÃ¤rcker

Nevermind, I figured it out easily. Must been blind before. Many thanks to the Iceberg team, the tool works like a charm in 6.1! Am .10.2018, 10:58 Uhr, schrieb Steffen MÃ¤rcker <merkste(a)web.de>: > Hi, > > I tried the tool yesterday and found some hickups. After opening issues > on GitHub, I wonder how I can easily contribute a PR there. I imagine > there is a straight-forward way with Iceberg now, isn't it? I a sorry if > I miss the obvious but I am still not familiar with Pharos comprehensive > tool set. > > Best, Steffen > > > Am .10.2018, 18:06 Uhr, schrieb milton mamani <akevalion(a)gmail.com>: > >> Hi you can use >> >> https://github.com/ObjectProfile/Pharo2VW >> >> Cheers, Milton >> >> El sÃ¡b., 13 oct. 2018 a las 12:38, Steffen MÃ¤rcker (<merkste(a)web.de>) >> escribiÃ³: >> >>> Hi, >>> >>> I gave PetitParser 2 a try and I am pretty impressed by the results, >>> please see the updated table below. =) Again, that's pure parsing and >>> Array-based AST-building. Moving to PP2 was indeed as easy as sending >>> #asPParser and working around character ranges ($a - $z). Is there a >>> preferred way to do the latter? >>> >>> Jan mentioned that there might be an automated tool to port stuff to >>> VisualWorks. Do you have a name? And again the old question: what is >>> the >>> preferred workflow to exchange code between the two dialects? Till now >>> I >>> stick to FileOut30. >>> >>> input Prism Storm Xtreams.PEG PP PP2 >>> size parse check check parse cache parse parse optim >>> 230kB 0.1s 10s 6s 9s 3s 2s 4s 0.2s >>> 544kB 0.2s 90s 20s 20s 7s 5s 9s 0.5s >>> 1.1MB 0.4s 392s 46s 34s 13s 8s 15s 1.0s >>> 1.4MB 0.8s 1091s 85s 47s 20s 12s 20s 1.3s >>> 2.2MB 63s 30s 16s 27s 1.9s >>> 2.9MB 81s 44s 20s 34s 2.5s >>> 3.8MB 107s 61s 25s 45s 3.1s >>> 4.4MB 123s 76s 30s 56s 3.7s >>> >>> Best, Steffen >>> >>> >>> Am .10.2018, 05:22 Uhr, schrieb Tudor Girba <tudor(a)tudorgirba.com>: >>> >>> > Hi, >>> > >>> > Interesting experiment. Thanks for sharing! >>> > >>> > I assume that you tried the original PetitParser. PetitParser2 offers >>> > the possibility to optimize the parser (kind of a compilation), and >>> this >>> > provides a significant speedup: >>> > https://github.com/kursjan/petitparser2 >>> > >>> > Would you be interested in trying this out? >>> > >>> > Cheers, >>> > Doru >>> > >>> > >>> > >>> >> On Oct 4, 2018, at 10:46 PM, Steffen MÃ¤rcker <MerkSte(a)web.de> wrote: >>> >> >>> >> I gave Xtreams-Parsing and PetitParser a shot and like to share my >>> >> findings.[*] >>> >> >>> >> The task was to parse the modelling language of the probabilistic >>> model >>> >> checker PRISM. I've written a grammer of about 130 definitions in >>> the >>> >> Xtreams DSL, which is close to Bryan Fords syntax. To avoid doing it >>> >> all again with PetitParser, I wrote a PetitParserGenerator that >>> takes >>> >> the DSL and builds a PetitParser. >>> >> >>> >> The numbers below are just parsing times, no further actions >>> involved. >>> >> For reference I show the times from PRISM (which uses JavaCC), too >>> -- >>> >> although they involve additional verification and normalization >>> steps >>> >> on the AST. >>> >> >>> >> input Prism XP PP >>> >> 230kB 14s 9s 2s >>> >> 544kB 121s 20s 5s >>> >> 1.1MB 421s 34s 8s >>> >> 1.4MB 1091s 47s 12s >>> >> 2.2MB 63s 16s >>> >> 2.9MB 81s 20s >>> >> 3.8MB 107s 25s >>> >> 4.4MB 123s 30s >>> >> >>> >> Please note that these times are not representative at all. It's >>> just >>> a >>> >> single example and I put zero effort in optimization. However, I am >>> >> quite satisfied with the results. >>> >> >>> >> [*] I was already familiar with the DSL of Xtreams-Parsing, which I >>> >> like very much. I did not consider SmaCC, as I find PEGs easier to >>> use. >>> >> >>> >> Best, Steffen >>> >> >>> >> >>> >> >>> >> Am .10.2018, 20:14 Uhr, schrieb Steffen MÃ¤rcker <merkste(a)web.de>: >>> >> >>> >>> Dear all, >>> >>> >>> >>> I have two questions regarding parsing frameworks. >>> >>> >>> >>> 1) Do you have any insights on the performance of SmaCC VS Xtreams >>> >>> Parsing VS PetitParser? >>> >>> 2) Has anybody started to port PetitParser 2 from Pharo to VW? Is >>> it >>> >>> worth the effort? >>> >>> >>> >>> Sorry for cross-posting, I thought this might interest both >>> >>> communities. >>> >>> >>> >>> Cheers, Steffen >>> > >>> > -- >>> > www.feenk.com >>> > >>> > "No matter how many recipes we know, we still value a chef." >>> > >>> > >>> > >>> > >>> > >>> > >>> >

Oct. 19, 2018

Pharo2VW (Was:[vwnc] Parsing in Smalltalk)

by Steffen MÃ¤rcker

Hi, I tried the tool yesterday and found some hickups. After opening issues on GitHub, I wonder how I can easily contribute a PR there. I imagine there is a straight-forward way with Iceberg now, isn't it? I a sorry if I miss the obvious but I am still not familiar with Pharos comprehensive tool set. Best, Steffen Am .10.2018, 18:06 Uhr, schrieb milton mamani <akevalion(a)gmail.com>: > Hi you can use > > https://github.com/ObjectProfile/Pharo2VW > > Cheers, Milton > > El sÃ¡b., 13 oct. 2018 a las 12:38, Steffen MÃ¤rcker (<merkste(a)web.de>) > escribiÃ³: > >> Hi, >> >> I gave PetitParser 2 a try and I am pretty impressed by the results, >> please see the updated table below. =) Again, that's pure parsing and >> Array-based AST-building. Moving to PP2 was indeed as easy as sending >> #asPParser and working around character ranges ($a - $z). Is there a >> preferred way to do the latter? >> >> Jan mentioned that there might be an automated tool to port stuff to >> VisualWorks. Do you have a name? And again the old question: what is the >> preferred workflow to exchange code between the two dialects? Till now I >> stick to FileOut30. >> >> input Prism Storm Xtreams.PEG PP PP2 >> size parse check check parse cache parse parse optim >> 230kB 0.1s 10s 6s 9s 3s 2s 4s 0.2s >> 544kB 0.2s 90s 20s 20s 7s 5s 9s 0.5s >> 1.1MB 0.4s 392s 46s 34s 13s 8s 15s 1.0s >> 1.4MB 0.8s 1091s 85s 47s 20s 12s 20s 1.3s >> 2.2MB 63s 30s 16s 27s 1.9s >> 2.9MB 81s 44s 20s 34s 2.5s >> 3.8MB 107s 61s 25s 45s 3.1s >> 4.4MB 123s 76s 30s 56s 3.7s >> >> Best, Steffen >> >> >> Am .10.2018, 05:22 Uhr, schrieb Tudor Girba <tudor(a)tudorgirba.com>: >> >> > Hi, >> > >> > Interesting experiment. Thanks for sharing! >> > >> > I assume that you tried the original PetitParser. PetitParser2 offers >> > the possibility to optimize the parser (kind of a compilation), and >> this >> > provides a significant speedup: >> > https://github.com/kursjan/petitparser2 >> > >> > Would you be interested in trying this out? >> > >> > Cheers, >> > Doru >> > >> > >> > >> >> On Oct 4, 2018, at 10:46 PM, Steffen MÃ¤rcker <MerkSte(a)web.de> wrote: >> >> >> >> I gave Xtreams-Parsing and PetitParser a shot and like to share my >> >> findings.[*] >> >> >> >> The task was to parse the modelling language of the probabilistic >> model >> >> checker PRISM. I've written a grammer of about 130 definitions in the >> >> Xtreams DSL, which is close to Bryan Fords syntax. To avoid doing it >> >> all again with PetitParser, I wrote a PetitParserGenerator that takes >> >> the DSL and builds a PetitParser. >> >> >> >> The numbers below are just parsing times, no further actions >> involved. >> >> For reference I show the times from PRISM (which uses JavaCC), too -- >> >> although they involve additional verification and normalization steps >> >> on the AST. >> >> >> >> input Prism XP PP >> >> 230kB 14s 9s 2s >> >> 544kB 121s 20s 5s >> >> 1.1MB 421s 34s 8s >> >> 1.4MB 1091s 47s 12s >> >> 2.2MB 63s 16s >> >> 2.9MB 81s 20s >> >> 3.8MB 107s 25s >> >> 4.4MB 123s 30s >> >> >> >> Please note that these times are not representative at all. It's just >> a >> >> single example and I put zero effort in optimization. However, I am >> >> quite satisfied with the results. >> >> >> >> [*] I was already familiar with the DSL of Xtreams-Parsing, which I >> >> like very much. I did not consider SmaCC, as I find PEGs easier to >> use. >> >> >> >> Best, Steffen >> >> >> >> >> >> >> >> Am .10.2018, 20:14 Uhr, schrieb Steffen MÃ¤rcker <merkste(a)web.de>: >> >> >> >>> Dear all, >> >>> >> >>> I have two questions regarding parsing frameworks. >> >>> >> >>> 1) Do you have any insights on the performance of SmaCC VS Xtreams >> >>> Parsing VS PetitParser? >> >>> 2) Has anybody started to port PetitParser 2 from Pharo to VW? Is it >> >>> worth the effort? >> >>> >> >>> Sorry for cross-posting, I thought this might interest both >> >>> communities. >> >>> >> >>> Cheers, Steffen >> > >> > -- >> > www.feenk.com >> > >> > "No matter how many recipes we know, we still value a chef." >> > >> > >> > >> > >> > >> > >> >

Oct. 19, 2018

Re: [Pharo-users] Installing SmaCC

by Dimitris Chloupis

nice , good to know that is already a feature in another smalltalk implementation. I decided finally to go against the idea of new sytax or the heavy usage of Array symbols. Instead I will be using standard 100% Pharo syntax. Fortunately Smalltalk syntax is so minimal that allows me to do this without hitting my head against a wall. I have already a prototype working for simple variable declarations with static types and slowly but steadily moving forward to the rest of the C syntax. Looks like the ship has left the port :D On Fri, Oct 19, 2018 at 4:09 AM Pierce Ng <pierce(a)samadhiweb.com> wrote: > On Wed, Oct 17, 2018 at 01:38:36PM +0300, Dimitris Chloupis wrote: > > About your last part on platforms, I will be providing a way to inline C > > code so one can you use C macros to detect the platform and generate code > > accordingly. > > Smalltalk/X allows inline C. Not sure about macros though, as I don't > know whether Smalltalk/X runs the C code through the C preprocessor or > does its own compilationn magic. > > Pierce > >

Oct. 19, 2018

Re: [Pharo-users] Installing SmaCC

by Pierce Ng

On Wed, Oct 17, 2018 at 01:38:36PM +0300, Dimitris Chloupis wrote: > About your last part on platforms, I will be providing a way to inline C > code so one can you use C macros to detect the platform and generate code > accordingly. Smalltalk/X allows inline C. Not sure about macros though, as I don't know whether Smalltalk/X runs the C code through the C preprocessor or does its own compilationn magic. Pierce

Oct. 19, 2018

Re: [Pharo-users] compiling libraries for Pharo on macOS

by Sean P. DeNigris

Michel Onoff wrote > In the end the problem wasâ¦ but the locations that Pharo searches for > libraries. Putting the library there or using a full path solved the > problem for my 64 ibt Pharo 6.1/macOS Mojave installation. Great! Thanks for posting the solution :) ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Oct. 18, 2018

Re: [Pharo-users] library to chain select:/collect:/ ... via cascade

by Julien

I think this was the idea of Transducers as well. Julien --- Julien Delplanque Doctorant Ã lâUniversitÃ© de Lille http://juliendelplanque.be/phd.html Equipe Rmod, Inria BÃ¢timent B 40, Avenue Halley 59650 Villeneuve d'Ascq NumÃ©ro de tÃ©lÃ©phone: +333 59 35 86 40 > Le 17 oct. 2018 Ã 09:13, Peter Uhnak <i.uhnak(a)gmail.com> a Ã©crit : > > Hi, > > is there some library that will allow me to chain select:/collect:/... via cascade? > > E.g. > > #(12 7 'a' nil #(0)) query reject: #isNil; select: #isNumber; collect: #squared; select: #even? > > The point is to not have to write billion parentheses when building a more complex query. > > I imagine this would be pretty easy to write, but figured I ask first. > > Thanks, > Peter

Oct. 18, 2018

Re: [Pharo-users] compiling libraries for Pharo on macOS

by Michel Onoff

On 2018-10-18 05:31, Pierce Ng wrote: > On Wed, Oct 17, 2018 at 10:08:58AM +0200, Michel Onoff wrote: >> Specifically, I'm trying to build on all supported platforms, namely macOS, >> Windows and Linux. Currently I've got Linux and Windows under control, but I >> cannot find a systematic way to build on macOS. > > When I last tried either on Yosemite or El Capitan, I found that the > Pharo at that time could not load 32/64-bit universal libraries. > Building a 32-bit library for 32-bit Pharo fixed it for me. You might > want to try it. > > Pierce > > In the end the problem was not building, which is rather simple even using clang directly, but the locations that Pharo searches for libraries. Putting the library there or using a full path solved the problem for my 64 ibt Pharo 6.1/macOS Mojave installation. Thanks MO

Oct. 18, 2018