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

Re: [Pharo-users] [vwnc] Parsing in Smalltalk

by Steffen MÃ¤rcker

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. 13, 2018

Re: [Pharo-users] Persistant Taskbar Previews

by Steffen MÃ¤rcker

Thanks both of you. It turned out to be not a second UI process but simply some orphan morphs. I got rid of them using alt-shift. I was just not aware of bringing up the halos. =) Am .10.2018, 10:48 Uhr, schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > I would guess you have 2 instances of the Morphic UI process, probably > left over from some debugging. Kill one using the Process Browser. But > this is just a blind guess. > >> On 13 Oct 2018, at 04:51, Ben Coman <btc(a)openinworld.com> wrote: >> >> >> >> On Fri, 12 Oct 2018 at 18:57, Steffen MÃ¤rcker <merkste(a)web.de> wrote: >> Hi, >> >> Using Pharo 6.1 for some hours, I ended up with quite a few previews >> from >> (long gone) taskbar entries that refuse to go away. They seem to be >> PanelMorphs. How do I get rid of them? >> >> Best, Steffen >> >> I'd guess like any morph you could meta-click on them and choose to >> delete them. >> e.g. on Windows SHIFT-ALT-middleClick >> >> cheers -ben > >

Oct. 13, 2018

Re: [Pharo-users] Persistant Taskbar Previews

by Sven Van Caekenberghe

I would guess you have 2 instances of the Morphic UI process, probably left over from some debugging. Kill one using the Process Browser. But this is just a blind guess. > On 13 Oct 2018, at 04:51, Ben Coman <btc(a)openinworld.com> wrote: > > > > On Fri, 12 Oct 2018 at 18:57, Steffen MÃ¤rcker <merkste(a)web.de> wrote: > Hi, > > Using Pharo 6.1 for some hours, I ended up with quite a few previews from > (long gone) taskbar entries that refuse to go away. They seem to be > PanelMorphs. How do I get rid of them? > > Best, Steffen > > I'd guess like any morph you could meta-click on them and choose to delete them. > e.g. on Windows SHIFT-ALT-middleClick > > cheers -ben

Oct. 13, 2018

Re: [Pharo-users] Persistant Taskbar Previews

by Ben Coman

On Fri, 12 Oct 2018 at 18:57, Steffen MÃ¤rcker <merkste(a)web.de> wrote: > Hi, > > Using Pharo 6.1 for some hours, I ended up with quite a few previews from > (long gone) taskbar entries that refuse to go away. They seem to be > PanelMorphs. How do I get rid of them? > > Best, Steffen > I'd guess like any morph you could meta-click on them and choose to delete them. e.g. on Windows SHIFT-ALT-middleClick cheers -ben

Oct. 13, 2018

Re: [Pharo-users] GlorpSQLite Github release management

by Ben Coman

On Fri, 12 Oct 2018 at 14:04, Alistair Grant <akgrant0710(a)gmail.com> wrote: > Hi Pierce, > > On Fri, 12 Oct 2018 at 06:21, Pierce Ng <pierce(a)samadhiweb.com> wrote: > > > > Hi all, > > > > So GlorpSQLite works on Pharo 5 and 6, but not yet on Pharo 7. > > I've been using GlorpSQLite in Pharo 7 since development started. It > is loaded from another package's baseline as: > > spec > baseline: 'GlorpSQLite' with: [ > spec repository: 'github://pharo-rdbms/glorp-sqlite3' ]. > > I have some patches for date and time handling which I load on top > (and should really submit as a patch), but I don't think these are > Pharo 7 related. > > > > Currently, I have the following: > > > > https://github.com/PierceNg/glorp > > https://github.com/PierceNg/glorp-sqlite3 > > > > Which are forks of these: > > > > https://github.com/pharo-rdbms/glorp > > https://github.com/pharo-rdbms/glorp-sqlite3 > > I'll take a look. > > > > I'm thinking to create a release, say, v1.0, for the current known > > working GlorpSQLite combo for Pharo 5 and 6 in my repos, then, ... > > create a branch for Pharo 7? Then turn the branch into release v2.0 when > > ready? If there is no change to the GlorpSQLite API, but just the implementation (i.e. on Pharo 7), then v1.1 seems a better choice of version number. > I do all of these actions in my repo, and through pull requests > > to upstream, Git will take care of synchronizing across the forks? > Note that git branches are simply pointers to a particular commit hash. There is no computational link between the "branch name" in your repo and the "branch name" in the target repo. On github you can create a PR from any repo/branch to any other repo/branch that exists. As Alistar indicated, if you want a particular "branch name" in the target repo, it needs to have already been created there. Then you can submit a PR to it from any branch in your repo. > I'm not a git expert either, but I suspect the branches will need to > be created in the main repository. The modifications can then be > applied to the appropriate branch as a PR. > btw, for a reproducability of a "release" version, my understanding is that in the canonical repo, tags are better than branches because tags are permanently tied to a particular while branches move. (However I've not direct experience with this) cheers -ben

Oct. 13, 2018

Re: [Pharo-users] [Moose-dev] Re: Re: Plotting genome scale values with Roassal

by Alexandre Bergel

Hi HernÃ¡n, Sorry for the late reply. Regarding your first question, you can do: -=-=-=-=-=-= g := RTGrapher new. d := RTData new. d connectColor: Color blue. d noDot. d points: (-3.14 to: 3.14 by: 0.1). d y: #sin. d x: #yourself. g add: d. g axisX numberOfTicks: 10; numberOfLabels: 5. g -=-=-=-=-=-= As you can see, the line "g axisX numberOfTicks: 10; numberOfLabels: 5.â allows you to set the number of ticks and the number of labels. Regarding your second question, where can I find the file OrderedCollection_3712516797.obj ? Or, how can I reproduce it. Anyway, I believe the problem is that you have too many points. In this case, I suggest you to reduce the number of points. For example, a slight variation of the previous example [DO NOT RUN IT]: -=-=-=-=-=-= points := -3.14 to: 3.14 by: 0.000001. g := RTGrapher new. d := RTData new. d connectColor: Color blue. d noDot. d points: points. d y: #sin. d x: #yourself. g add: d. g axisX numberOfTicks: 10; numberOfLabels: 5. g -=-=-=-=-=-= The script tries to build the same graph but with 6 280 001 points. Which obviously, is way too many. Instead, you can do something like: -=-=-=-=-=-= points := SortedCollection new. 1000 timesRepeat: [ points add: (-3.14 to: 3.14 by: 0.000001) atRandom ]. g := RTGrapher new. d := RTData new. d connectColor: Color blue. d noDot. d points: points. d y: #sin. d x: #yourself. g add: d. g axisX numberOfTicks: 10; numberOfLabels: 5. g -=-=-=-=-=-= Which only display the graph with 1000 points. Cheers, Alexandre > On Oct 4, 2018, at 12:49 AM, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: > > This is weird, could you check: > > http://lists.pharo.org/pipermail/pharo-users_lists.pharo.org/2018-October/0… > > HernÃ¡n > > El miÃ©., 3 oct. 2018 a las 22:41, Alexandre Bergel > (<alexandre.bergel(a)me.com>) escribiÃ³: >> >> I am lost. What are the questions? I do not see them in the mailing list. >> >> Alexandre >> >>> On Oct 3, 2018, at 11:11 AM, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: >>> >>> Hi Alex, >>> >>> Thanks. Please note there are two questions related to Roassal :) >>> I have isolated the script so you don't need to load BioSmalltalk >>> >>> Maybe someone can check or give a hint? >>> >>> El mar., 2 oct. 2018 a las 22:31, Alexandre Bergel >>> (<alexandre.bergel(a)me.com>) escribiÃ³: >>>> >>>> Pretty cool! >>>> >>>> Alexandre >>>> >>>>> On Oct 2, 2018, at 2:21 AM, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: >>>>> >>>>> <a TRMorph(28411392).png><skew_diagram_ecoli.png> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev(a)list.inf.unibe.ch >>>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)list.inf.unibe.ch >> https://www.list.inf.unibe.ch/listinfo/moose-dev >

Oct. 12, 2018

Persistant Taskbar Previews

by Steffen MÃ¤rcker

Hi, Using Pharo 6.1 for some hours, I ended up with quite a few previews from (long gone) taskbar entries that refuse to go away. They seem to be PanelMorphs. How do I get rid of them? Best, Steffen

Oct. 12, 2018

Re: [Pharo-users] GlorpSQLite Github release management

by Alistair Grant

Hi Pierce, On Fri, 12 Oct 2018 at 06:21, Pierce Ng <pierce(a)samadhiweb.com> wrote: > > Hi all, > > So GlorpSQLite works on Pharo 5 and 6, but not yet on Pharo 7. I've been using GlorpSQLite in Pharo 7 since development started. It is loaded from another package's baseline as: spec baseline: 'GlorpSQLite' with: [ spec repository: 'github://pharo-rdbms/glorp-sqlite3' ]. I have some patches for date and time handling which I load on top (and should really submit as a patch), but I don't think these are Pharo 7 related. > Currently, I have the following: > > https://github.com/PierceNg/glorp > https://github.com/PierceNg/glorp-sqlite3 > > Which are forks of these: > > https://github.com/pharo-rdbms/glorp > https://github.com/pharo-rdbms/glorp-sqlite3 I'll take a look. > I'm thinking to create a release, say, v1.0, for the current known > working GlorpSQLite combo for Pharo 5 and 6 in my repos, then, ... > create a branch for Pharo 7? Then turn the branch into release v2.0 when > ready? I do all of these actions in my repo, and through pull requests > to upstream, Git will take care of synchronizing across the forks? I'm not a git expert either, but I suspect the branches will need to be created in the main repository. The modifications can then be applied to the appropriate branch as a PR. > Does the above sound workable? Is there a better approach? > > Pierce, Git noob >

Oct. 12, 2018

GlorpSQLite Github release management

by Pierce Ng

Hi all, So GlorpSQLite works on Pharo 5 and 6, but not yet on Pharo 7. Currently, I have the following: https://github.com/PierceNg/glorp https://github.com/PierceNg/glorp-sqlite3 Which are forks of these: https://github.com/pharo-rdbms/glorp https://github.com/pharo-rdbms/glorp-sqlite3 I'm thinking to create a release, say, v1.0, for the current known working GlorpSQLite combo for Pharo 5 and 6 in my repos, then, ... create a branch for Pharo 7? Then turn the branch into release v2.0 when ready? I do all of these actions in my repo, and through pull requests to upstream, Git will take care of synchronizing across the forks? Does the above sound workable? Is there a better approach? Pierce, Git noob

Oct. 12, 2018

Re: [Pharo-users] World Cup 2018 with Glorp : SQL dump for SQLite : wc2018.sql

by Pierce Ng

On Thu, Oct 11, 2018 at 06:45:07PM +0200, H. Hirzel wrote: > Hi Pierce > > In your blog entry > 'World Cup 2018 with Glorp' > you write about an SQL dump file wc2018.sql and mention a repo? > > https://github.com/openfootball/world-cup/tree/master/2018--russia > > seems to be a candidate, but on SQL. > > In which repo is it? Hi Hannes, I built SQLite databases from the data in https://github.com/openfootball/datafile.git, then generated the SQLite dump files, which went into the 'data' directory in my repo https://github.com/PierceNg/footballdb-Glorp. I don't remember whether the WC 2018 dump file has the match results, but the WC 2014 one ought to contain the full tournament data. Pierce

Oct. 12, 2018