[Pharo-users] ring deprecation in pharo 7
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."
Re: [Pharo-users] library to chain select:/collect:/ ... via cascade
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 : 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 : 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--->
Re: [Pharo-users] library to chain select:/collect:/ ... via cascade
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 : 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 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
Re: [Pharo-users] Pharo2VW (Was:[vwnc] Parsing in Smalltalk)
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 : 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 : Hi you can use https://github.com/ObjectProfile/Pharo2VW Cheers, Milton El sáb., 13 oct. 2018 a las 12:38, Steffen Märcker () 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 PrismStorm Xtreams.PEG PP PP2 size parse check check parse cache parse parse optim 230kB 0.1s 10s 6s 9s3s 2s 4s 0.2s 544kB 0.2s 90s20s20s7s 5s 9s 0.5s 1.1MB 0.4s 392s46s34s 13s 8s15s 1.0s 1.4MB 0.8s 1091s85s47s 20s12s20s 1.3s 2.2MB63s 30s16s27s 1.9s 2.9MB81s 44s20s34s 2.5s 3.8MB 107s 61s25s45s 3.1s 4.4MB 123s 76s30s56s 3.7s Best, Steffen Am .10.2018, 05:22 Uhr, schrieb Tudor Girba : > 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 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 PrismXP PP >> 230kB14s9s 2s >> 544kB121s 20s 5s >> 1.1MB421s 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 : >> >>> 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." > > > > > > >
[Pharo-users] Pharo2VW (Was:[vwnc] Parsing in Smalltalk)
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 : Hi you can use https://github.com/ObjectProfile/Pharo2VW Cheers, Milton El sáb., 13 oct. 2018 a las 12:38, Steffen Märcker () 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 PrismStorm Xtreams.PEG PP PP2 size parse check check parse cache parse parse optim 230kB 0.1s 10s 6s 9s3s 2s 4s 0.2s 544kB 0.2s 90s20s20s7s 5s 9s 0.5s 1.1MB 0.4s 392s46s34s 13s 8s15s 1.0s 1.4MB 0.8s 1091s85s47s 20s12s20s 1.3s 2.2MB63s 30s16s27s 1.9s 2.9MB81s 44s20s34s 2.5s 3.8MB 107s 61s25s45s 3.1s 4.4MB 123s 76s30s56s 3.7s Best, Steffen Am .10.2018, 05:22 Uhr, schrieb Tudor Girba : > 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 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 PrismXP PP >> 230kB14s9s 2s >> 544kB121s 20s 5s >> 1.1MB421s 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 : >> >>> 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." > > > > > > >
Re: [Pharo-users] Installing SmaCC
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 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 > >
