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

Re: [Pharo-users] [Seaside] [ANN] TelescopeCytoscape for Seaside v1.0.0

by Cyril Ferlicot D.

Le 03/05/2018 Ã 21:02, Esteban A. Maringolo a Ã©critÂ : > You announced so many things, that I'll use this last one to thank you > for sharing this. > > I found a few of the projects very interesting and I look forward to > use them for real. It was all the open source projects in which I participated and that we never took the time to release. I decided to move them to github to try the new iceberg and to have a stable version on which people can rely. Now it's done and I hope the community will find them helpful and participate (even if it's just opening issues) :) > > Thank you again. > Esteban A. Maringolo > _______________________________________________ > seaside mailing list > seaside(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > -- Cyril Ferlicot https://ferlicot.fr

May 3, 2018

Re: [Pharo-users] #ast vs. #parseTree

by Guillermo Polito

I don't think so... any compiler book talks about ASTs using acronyms. Acronyms are good when acronyms are good. Le jeu. 3 mai 2018 Ã 20:48, Esteban A. Maringolo <emaringolo(a)gmail.com> a Ã©crit : > +1 to avoid acronyms. > > Esteban A. Maringolo > > 2018-05-03 12:47 GMT-03:00 Francisco Garau <francisco.garau(a)gmail.com>: > >> I'd rather be also explicit in the name and avoid acronyms. >> #newAbstractSyntaxTree and #cachedAbstractSyntaxTree >> >> - Francisco >> >> >> -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

May 3, 2018

Re: [Pharo-users] [Seaside] [ANN] TelescopeCytoscape for Seaside v1.0.0

by Esteban A. Maringolo

You announced so many things, that I'll use this last one to thank you for sharing this. I found a few of the projects very interesting and I look forward to use them for real. Thank you again. Esteban A. Maringolo 2018-05-03 12:29 GMT-03:00 Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com>: > Hi, > > Telescope is an engine for efficiently creating meaningful > visualizations. It allow users to create models of visualizations and to > render them via connectors to visualization frameworks. > > Until now, it was hosted on SmalltalkHub and we just migrated it to Github. > > https://github.com/TelescopeSt/Telescope > > We also finished the v1.0.0 of the CytoscapeJs > (http://js.cytoscape.org/) Telescope connector. It is build on top of > Seaside to use visualizations as components. > > You can find the project at: > https://github.com/TelescopeSt/TelescopeCytoscape > > And a demo at: https://demos.ferlicot.fr/TelescopeDemo > > -- > Cyril Ferlicot > https://ferlicot.fr > _______________________________________________ > seaside mailing list > seaside(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

May 3, 2018

Re: [Pharo-users] #ast vs. #parseTree

by Esteban A. Maringolo

+1 to avoid acronyms. Esteban A. Maringolo 2018-05-03 12:47 GMT-03:00 Francisco Garau <francisco.garau(a)gmail.com>: > I'd rather be also explicit in the name and avoid acronyms. > #newAbstractSyntaxTree and #cachedAbstractSyntaxTree > > - Francisco > > >

May 3, 2018

Re: [Pharo-users] #ast vs. #parseTree

by Francisco Garau

I'd rather be also explicit in the name and avoid acronyms. #newAbstractSyntaxTree and #cachedAbstractSyntaxTree - Francisco > On 3 May 2018, at 09:59, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > Ahh explicitness :) > >> On Thu, May 3, 2018 at 10:56 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> How about: #newAst & #cachedAst? >> >> Cheers, >> Doru >> >> >> > On May 3, 2018, at 9:30 AM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >> > >> > method newAst ? >> > >> > On Wed, May 2, 2018 at 11:03 PM, Bernardo Ezequiel Contreras <vonbecmann(a)gmail.com> wrote: >> > a "parse tree" is not equal to an "ast"(abstract syntax tree) >> > but its difficult to find a name for an ast that is not cached. >> > maybe >> > parsedAst >> > parseAst >> > .... >> > >> > >> > On Wed, May 2, 2018 at 3:28 PM, Richard Sargent <richard.sargent(a)gemtalksystems.com> wrote: >> > On Wed, May 2, 2018 at 11:06 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >> > Hi. >> > >> > Maybe #parseSourceCode would be better name for #parseTree. >> > >> > I've always found it good advice to avoid using a verb phrase to name something which does not entail some kind of action. >> > #parseSourceCode realy reads like something which would parse the source code. #parseTree also has that effect, except for the lack of a tree to parse. >> > >> > >> > >> > 2018-05-02 16:33 GMT+03:00 Marcus Denker <marcus.denker(a)inria.fr>: >> > >> > >> > > On 27 Apr 2018, at 21:36, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> > > >> > > Marcus Denker-4 wrote >> > >> I will add commentsâ¦ >> > > >> > > I got confused by this again and created an issue: >> > > https://pharo.manuscript.com/f/cases/21806/Document-Difference-between-ast-… >> > > >> > > And then Peter Uhnak reminded me on Discord about this thread. I'm happy to >> > > add the comments, but not sure I understand the issue well enough. IIUC #ast >> > > is cached, but #parseTree is not. What I don't understand is the purpose of >> > > this difference and when one would use one over the other. >> > >> > the cached #ast is for one interesting for speed (that is, in situations where you ask for it often). >> > >> > The other use-case is if you want to annotate the AST and keep that annotation around (till the next >> > image save, but you can subscribe to ASTCacheReset and re-install the AST in the cache after cleaning. >> > (This is used by MetaLinks to make sure they survive image restart). >> > >> > The last thing that it provides is that we do have a quite powerful mapping between bytecode/text/context >> > and the AST. Regardless how you navigate, you get the same object. >> > >> > e.g. even this one works: >> > >> > [ 1+2 ] sourceNode == thisContext method ast blockNodes first >> > >> > > For example, >> > > when, if ever, would a user want to access a CM's #ast (as opposed to >> > > #parseTree) and could modifying it create problems? >> > > >> > >> > Modification is a problem, yes.. code that wants to modify the AST without making sure the compiledMethod is in sync later >> > should use #parseTree. >> > >> > Code that does not modify the AST (or makes sure to compile it after modification) is free to use #ast. >> > or if you want to annotate the AST (which is a modification, after all). >> > >> > This is not perfect (not at allâ¦) but the simplest solution to get (to some extend) what you would have if the system would have >> > a real persistent, first class ASTâ¦ >> > >> > To be improved. The ASTCache with itâs naive âlets just cache everything till the next image saveâ was done with the idea to see >> > when it would show that it is too naiveâ¦ for that it worked amazingly well till now. >> > >> > Marcus >> > >> > >> > >> > >> > >> > -- >> > Bernardo E.C. >> > >> > Sent from a cheap desktop computer in South America. >> > >> > >> > >> > -- >> > >> > Guille Polito >> > Research Engineer >> > >> > Centre de Recherche en Informatique, Signal et Automatique de Lille >> > CRIStAL - UMR 9189 >> > French National Center for Scientific Research - http://www.cnrs.fr >> > >> > Web: http://guillep.github.io >> > Phone: +33 06 52 70 66 13 >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "What is more important: To be happy, or to make happy?" > > > > -- > > Guille Polito > Research Engineer > Centre de Recherche en Informatique, Signal et Automatique de Lille > CRIStAL - UMR 9189 > French National Center for Scientific Research - http://www.cnrs.fr > > Web: http://guillep.github.io > Phone: +33 06 52 70 66 13

May 3, 2018

[ANN] TelescopeCytoscape for Seaside v1.0.0

by Cyril Ferlicot D.

Hi, Telescope is an engine for efficiently creating meaningful visualizations. It allow users to create models of visualizations and to render them via connectors to visualization frameworks. Until now, it was hosted on SmalltalkHub and we just migrated it to Github. https://github.com/TelescopeSt/Telescope We also finished the v1.0.0 of the CytoscapeJs (http://js.cytoscape.org/) Telescope connector. It is build on top of Seaside to use visualizations as components. You can find the project at: https://github.com/TelescopeSt/TelescopeCytoscape And a demo at: https://demos.ferlicot.fr/TelescopeDemo -- Cyril Ferlicot https://ferlicot.fr

May 3, 2018

Re: [Pharo-users] [Pharo-dev] [Ann] Iceberg 0.7.5

by Guillermo Polito

On Thu, May 3, 2018 at 5:25 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > Will it be too hard to do 6.2? I encourage the backport but it will break > stuff which is also really annoying. > @esteban? :) I'd really like to have that or a 6.1.1, a way to actually differentiate them... > > Norbert > > > Am 03.05.2018 um 17:16 schrieb Guillermo Polito <guillermopolito(a)gmail.com > >: > > Time for the weekly Iceberg update. > > Iceberg 0.7.5. will be in the next Pharo build. > Thanks to all brave users, issue reporters and contributors :). > > Key improvements: > - Several improvements in metacello integration. (see #625, #664, #688 + > more tests) > - For those using CI, we think this release will also fix > https://github.com/pharo-vcs/iceberg/issues/643 > > Infrastructure improvements: > - In 0.7.4 we introduced in the build tests againt pharo 6.1 and 64 bits > * https://travis-ci.org/pharo-vcs/iceberg/builds/372408795 > - In 0.7.5 all iceberg tests run green on Pharo 6.1 32 bits > * https://travis-ci.org/pharo-vcs/iceberg/builds/374433920 > - In the next release we plan to do a pass on 64 bits > > ** Pharo 6.1 backport ** > - We plan to backport this version to Pharo 6.1 > - Cyril has been using the development version of Iceberg on Pharo 6.1 > for a couple of weeks now. > - This plus the green CI encourages us to backport to Pharo 6.1 > > Detailed ChangesLog: > > #625 Non explicit error while loading a project > #758 [Regression] Repair action clone is not setting pharo repository > #756 Iceberg dev-0.7 is broken in Pharo6.1 (Instance of > IceTipURLLabelMorph did not understand #addEmphasis:) > #749 Adding repair actions to the code subdirectory missing problem > #655 Rename extension method buildToolbarItem of CommandActivator > #755 Extracting the URL label behavior as a component that we can reuse > #468 Commiting via Iceberg does not commit package removal > #750 Add possibility to see current commit in Repositories/Package view > #754 Showing and coping the Commit ID > #753 Create branch dialog layout is broken > #664 Package wrongly shown with "uncommited changes" status > #752 Add "invalid ssh" > #747 Cloning a Git repository should change the path with the project name. > #738 Remove "pharo" Repository with "also remove from filesystem" gives > error > #746 Make tests run on pharo 6 > #735 Issue while registering a new project on Pharo 6.1 > #733 Add license file > #740 Fogbugz panel: Improve label, focus order and layout > #549 IceRestoreRepositoryModel should have a class comment > #688 Duplicated project error when loading in a fresh image > > Enjoy, > Guille in behalf of all people that contributed :) > > > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

May 3, 2018

[ANN] Heimdall logging manager for Seaside v1.0.0

by Cyril Ferlicot D.

Hi! Guillaume Larcheveque begun a simple login manager for Seaside. I just finished to port it to github and we released the v1.0.0. It is still experimental and help is welcomed. Project can be found at: https://github.com/DuneSt/Heimdall -- Cyril Ferlicot https://ferlicot.fr

May 3, 2018

[ANN] PrismCodeDisplayer for Seaside v1.0.0

by Cyril Ferlicot D.

Hi! We just finished the release v1.0.0 of PrismCodeDisplayer for Seaside. Prism (https://github.com/PrismJS/prism/) is a lightweight, robust, elegant syntax highlighting library. The Seaside binding allows to: Display code See line numbers Select code and act on the selection Customize the style of some text intervals Add links to text intervals Add a search feature Have a dynamic loading of the text content Copy the text content Have a minimap Project can be found at: https://github.com/DuneSt/PrismCodeDisplayer Demo at: https://demos.ferlicot.fr/PrismDemo -- Cyril Ferlicot https://ferlicot.fr

May 3, 2018

[ANN] ChartJs for Seaside v1.0.0

by Cyril Ferlicot D.

Hi! I'm happy to announce the release v1.0.0 of ChartJs for Seaside. This is a binding of ChartJs v1. We did not got the time to bind v2 of ChartJs. v1.0.0 includes: Creation of 1D charts Creation of 2D charts Creation of Boxplots Callbacks on 1D and 2D charts Tooltips on charts Style customization ... The project can be found at: https://github.com/DuneSt/ChartJs Demo at: https://demos.ferlicot.fr/ChartJs -- Cyril Ferlicot https://ferlicot.fr

May 3, 2018

Re: [Pharo-users] [Pharo-dev] [Ann] Iceberg 0.7.5

by Norbert Hartl

Will it be too hard to do 6.2? I encourage the backport but it will break stuff which is also really annoying. Norbert > Am 03.05.2018 um 17:16 schrieb Guillermo Polito <guillermopolito(a)gmail.com>: > > Time for the weekly Iceberg update. > > Iceberg 0.7.5. will be in the next Pharo build. > Thanks to all brave users, issue reporters and contributors :). > > Key improvements: > - Several improvements in metacello integration. (see #625, #664, #688 + more tests) > - For those using CI, we think this release will also fix https://github.com/pharo-vcs/iceberg/issues/643 <https://github.com/pharo-vcs/iceberg/issues/643> > > Infrastructure improvements: > - In 0.7.4 we introduced in the build tests againt pharo 6.1 and 64 bits > * https://travis-ci.org/pharo-vcs/iceberg/builds/372408795 <https://travis-ci.org/pharo-vcs/iceberg/builds/372408795> > - In 0.7.5 all iceberg tests run green on Pharo 6.1 32 bits > * https://travis-ci.org/pharo-vcs/iceberg/builds/374433920 <https://travis-ci.org/pharo-vcs/iceberg/builds/374433920> > - In the next release we plan to do a pass on 64 bits > > ** Pharo 6.1 backport ** > - We plan to backport this version to Pharo 6.1 > - Cyril has been using the development version of Iceberg on Pharo 6.1 for a couple of weeks now. > - This plus the green CI encourages us to backport to Pharo 6.1 > > Detailed ChangesLog: > > #625 Non explicit error while loading a project > #758 [Regression] Repair action clone is not setting pharo repository > #756 Iceberg dev-0.7 is broken in Pharo6.1 (Instance of IceTipURLLabelMorph did not understand #addEmphasis:) > #749 Adding repair actions to the code subdirectory missing problem > #655 Rename extension method buildToolbarItem of CommandActivator > #755 Extracting the URL label behavior as a component that we can reuse > #468 Commiting via Iceberg does not commit package removal > #750 Add possibility to see current commit in Repositories/Package view > #754 Showing and coping the Commit ID > #753 Create branch dialog layout is broken > #664 Package wrongly shown with "uncommited changes" status > #752 Add "invalid ssh" > #747 Cloning a Git repository should change the path with the project name. > #738 Remove "pharo" Repository with "also remove from filesystem" gives error > #746 Make tests run on pharo 6 > #735 Issue while registering a new project on Pharo 6.1 > #733 Add license file > #740 Fogbugz panel: Improve label, focus order and layout > #549 IceRestoreRepositoryModel should have a class comment > #688 Duplicated project error when loading in a fresh image > > Enjoy, > Guille in behalf of all people that contributed :)

May 3, 2018

[Ann] Iceberg 0.7.5

by Guillermo Polito

Time for the weekly Iceberg update. Iceberg 0.7.5. will be in the next Pharo build. Thanks to all brave users, issue reporters and contributors :). Key improvements: - Several improvements in metacello integration. (see #625, #664, #688 + more tests) - For those using CI, we think this release will also fix https://github.com/pharo-vcs/iceberg/issues/643 Infrastructure improvements: - In 0.7.4 we introduced in the build tests againt pharo 6.1 and 64 bits * https://travis-ci.org/pharo-vcs/iceberg/builds/372408795 - In 0.7.5 all iceberg tests run green on Pharo 6.1 32 bits * https://travis-ci.org/pharo-vcs/iceberg/builds/374433920 - In the next release we plan to do a pass on 64 bits ** Pharo 6.1 backport ** - We plan to backport this version to Pharo 6.1 - Cyril has been using the development version of Iceberg on Pharo 6.1 for a couple of weeks now. - This plus the green CI encourages us to backport to Pharo 6.1 Detailed ChangesLog: #625 Non explicit error while loading a project #758 [Regression] Repair action clone is not setting pharo repository #756 Iceberg dev-0.7 is broken in Pharo6.1 (Instance of IceTipURLLabelMorph did not understand #addEmphasis:) #749 Adding repair actions to the code subdirectory missing problem #655 Rename extension method buildToolbarItem of CommandActivator #755 Extracting the URL label behavior as a component that we can reuse #468 Commiting via Iceberg does not commit package removal #750 Add possibility to see current commit in Repositories/Package view #754 Showing and coping the Commit ID #753 Create branch dialog layout is broken #664 Package wrongly shown with "uncommited changes" status #752 Add "invalid ssh" #747 Cloning a Git repository should change the path with the project name. #738 Remove "pharo" Repository with "also remove from filesystem" gives error #746 Make tests run on pharo 6 #735 Issue while registering a new project on Pharo 6.1 #733 Add license file #740 Fogbugz panel: Improve label, focus order and layout #549 IceRestoreRepositoryModel should have a class comment #688 Duplicated project error when loading in a fresh image Enjoy, Guille in behalf of all people that contributed :)

May 3, 2018

Re: [Pharo-users] [Ann] Iceberg 0.7.3

by Sven Van Caekenberghe

Hi Guillermo (et al), I finally found the time to test this new setup and I found it much easier and quite straightforward to make a PR. The new approach, with the simpler UI and lots more dialogs/explanations (and the glossary) is really well done. It felt much better, much higher quality. I am sure we are on the right track now. Thanks for all the hard work. Sven > On 25 Apr 2018, at 10:27, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > Hi all, > > We just introduced Iceberg 0.7.3 into Pharo. This new version solves several issues people had when contributing to Pharo in general and others. I've made a screencast on how to contribute to Pharo, and added some tutorial and glossary in Iceberg's wiki. > > Below the links and the changes log. > > Thanks for making your issue reports ^^. We will schedule a backporting to Pharo6.1 in a couple of weeks, once we have another iteration. > > Cheers, > Guille > > # Contribute to Pharo with Iceberg 0.7.3 > > - wiki page: https://github.com/pharo-vcs/iceberg/wiki/Contribute-to-Pharo-with-Iceberg-… > > - Screencast: https://www.youtube.com/watch?v=PK2yCu2rWCc&feature=youtu.because > > This screencast shows how to use Iceberg 0.7.3 to contribute to latest Pharo 7, by cloning from scratch your own (potentially outdated) clone. > > This video will guide you through: > - solve the "Missing local repository" by cloning > - solve the "Fetch required" that appears because the fork is out of date > - solve the "Detached working copy" by creating a new branch > - use the pharo plugin to create an issue branch > - make some changes, commit them and push them to your fork > - make a pull request > > If you already have a clone, you can just import an existing repository from your disk. The rest of the instructions should be the same. > > If you don't have a fork, create one before doing anything else. > > New videos to come with more explanations. > > # Iceberg Glossary > > https://github.com/pharo-vcs/iceberg/wiki/Iceberg-glossary > > # 0.7.3 ChangesLog > > â¢ #693: fixing problem when the announcement of changes in a package is nil. (bug, important) > â¢ #682: update update script (Pharo6-backport) > â¢ #681: Author name is not correctly decoded (UI, enhancement) > â¢ #680: Repair actions dialog should explain the situation (UI, enhancement, important) > â¢ #679: Create branch repair action should show create branch from issue if available (Pharo plugin, UI) > â¢ #678: Iceberg does not correctly recognize packages (bug, important) > â¢ #677: Unknown commit can only be solved with repair action (Model, bug, important) > â¢ #676: Unknown commit state is not properly shown (UI, bug, important) > â¢ #667: Merging branches with file deletion doesn't seem possible (bug, important, merge) > â¢ #666: Iceberg sometimes add a $ to commit message (Model, bug) > â¢ #662: The Pharo plugin has to do the fetch only if required. (Pharo plugin, enhancement) > â¢ #660: Add a star badge in the push button in case of a new branch () > â¢ #658: Progress Bar during checkout of Repository. (UI, enhancement) > â¢ #657: Confusing UI: Ghost Test maybe should be default? (UI, enhancement) > â¢ #656: Typo in Progress Bar (UI, bug) > â¢ #651: When pushing a new branch the list of commit is empty (UI, bug) > â¢ #650: "Create new branch from issue" is leaving image in detached working copy state () > â¢ #649: The VM is crashing when trying to use Iceberg from a saved image (bug) > â¢ #645: IceLibgitRepository should use "utilities" protocol instead of "utils" (clean up) > â¢ #644: Unnecessary temp in IceTipGitHubRepositoryPanel>>#getGitHubRepository" (clean up) > â¢ #643: LGit_GIT_ERROR: error authenticating: no auth sock variable loading a Tonel based baseline dependency in smalltalkCI (bug, important) > â¢ #639: Create pull request fails if branch has not been pushed (Github plugin, bug) > â¢ #636: The pull button should have a star badge when it has no upstream (UI, enhancement, important) > â¢ #634: Travis is not building Pull Requests (CI, bug, important) > â¢ #624: add "add remote" to remote picking on pull/push browsers (enhancement) > â¢ #610: Fix for issue #608 and #607. (clean up) > â¢ #609: New branch repair action does not refresh dirty packages (UI, bug) > â¢ #583: Creating a tonel project does not commit the properties file (Model, bug) > â¢ #542: Bug during commit of a new package (Model, bug) > > > -- > > Guille Polito > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > CRIStAL - UMR 9189 > French National Center for Scientific Research - http://www.cnrs.fr > > Web: http://guillep.github.io > Phone: +33 06 52 70 66 13

May 3, 2018

Re: [Pharo-users] #ast vs. #parseTree

by Sean P. DeNigris

Guillermo Polito wrote > Ahh explicitness :) +1! ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

May 3, 2018

Re: [Pharo-users] Pharo70 session start and silent failures

by Sean P. DeNigris

Holger Freyther wrote > I have had plenty Pharo70 images that didn't restore anymoreâ¦ +1. I think it has been related to errors in my startup code e.g. classes renamed/removed since 6.1, but not sure. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

May 3, 2018

Pharo70 session start and silent failures

by Holger Freyther

I am facing a problem with the new SessionManager>>#snapshot:andQuit: code. I have had plenty Pharo70 images that didn't restore anymore as the code is waiting for the "wait" semaphore. For sure it is something my code is doing but could anyone think of ways to make it more robust and handle failures more gracefully? My main concerns are: * When the failure becomes noticeable it is too late. :( * It fails silently. Maybe WorkingSession>>#runStartup: shouldn't rely on the UIManager doing the right thing (before the UI was fully initialized?) * Debugging is hard, there is no indication of why it broke, and getting to the situation of breakage takes a bit of time (installing the baseline..). holger

May 3, 2018

Re: [Pharo-users] #ast vs. #parseTree

by Guillermo Polito

Ahh explicitness :) On Thu, May 3, 2018 at 10:56 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > How about: #newAst & #cachedAst? > > Cheers, > Doru > > > > On May 3, 2018, at 9:30 AM, Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > > > > method newAst ? > > > > On Wed, May 2, 2018 at 11:03 PM, Bernardo Ezequiel Contreras < > vonbecmann(a)gmail.com> wrote: > > a "parse tree" is not equal to an "ast"(abstract syntax tree) > > but its difficult to find a name for an ast that is not cached. > > maybe > > parsedAst > > parseAst > > .... > > > > > > On Wed, May 2, 2018 at 3:28 PM, Richard Sargent <richard.sargent@ > gemtalksystems.com> wrote: > > On Wed, May 2, 2018 at 11:06 AM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > > Hi. > > > > Maybe #parseSourceCode would be better name for #parseTree. > > > > I've always found it good advice to avoid using a verb phrase to name > something which does not entail some kind of action. > > #parseSourceCode realy reads like something which would parse the source > code. #parseTree also has that effect, except for the lack of a tree to > parse. > > > > > > > > 2018-05-02 16:33 GMT+03:00 Marcus Denker <marcus.denker(a)inria.fr>: > > > > > > > On 27 Apr 2018, at 21:36, Sean P. DeNigris <sean(a)clipperadams.com> > wrote: > > > > > > Marcus Denker-4 wrote > > >> I will add commentsâ¦ > > > > > > I got confused by this again and created an issue: > > > https://pharo.manuscript.com/f/cases/21806/Document- > Difference-between-ast-and-parseTree > > > > > > And then Peter Uhnak reminded me on Discord about this thread. I'm > happy to > > > add the comments, but not sure I understand the issue well enough. > IIUC #ast > > > is cached, but #parseTree is not. What I don't understand is the > purpose of > > > this difference and when one would use one over the other. > > > > the cached #ast is for one interesting for speed (that is, in situations > where you ask for it often). > > > > The other use-case is if you want to annotate the AST and keep that > annotation around (till the next > > image save, but you can subscribe to ASTCacheReset and re-install the > AST in the cache after cleaning. > > (This is used by MetaLinks to make sure they survive image restart). > > > > The last thing that it provides is that we do have a quite powerful > mapping between bytecode/text/context > > and the AST. Regardless how you navigate, you get the same object. > > > > e.g. even this one works: > > > > [ 1+2 ] sourceNode == thisContext method ast blockNodes first > > > > > For example, > > > when, if ever, would a user want to access a CM's #ast (as opposed to > > > #parseTree) and could modifying it create problems? > > > > > > > Modification is a problem, yes.. code that wants to modify the AST > without making sure the compiledMethod is in sync later > > should use #parseTree. > > > > Code that does not modify the AST (or makes sure to compile it after > modification) is free to use #ast. > > or if you want to annotate the AST (which is a modification, after all). > > > > This is not perfect (not at allâ¦) but the simplest solution to get (to > some extend) what you would have if the system would have > > a real persistent, first class ASTâ¦ > > > > To be improved. The ASTCache with itâs naive âlets just cache everything > till the next image saveâ was done with the idea to see > > when it would show that it is too naiveâ¦ for that it worked amazingly > well till now. > > > > Marcus > > > > > > > > > > > > -- > > Bernardo E.C. > > > > Sent from a cheap desktop computer in South America. > > > > > > > > -- > > > > Guille Polito > > Research Engineer > > > > Centre de Recherche en Informatique, Signal et Automatique de Lille > > CRIStAL - UMR 9189 > > French National Center for Scientific Research - http://www.cnrs.fr > > > > Web: http://guillep.github.io > > Phone: +33 06 52 70 66 13 > > -- > www.tudorgirba.com > www.feenk.com > > "What is more important: To be happy, or to make happy?" > > > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

May 3, 2018

Re: [Pharo-users] #ast vs. #parseTree

by Tudor Girba

How about: #newAst & #cachedAst? Cheers, Doru > On May 3, 2018, at 9:30 AM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > method newAst ? > > On Wed, May 2, 2018 at 11:03 PM, Bernardo Ezequiel Contreras <vonbecmann(a)gmail.com> wrote: > a "parse tree" is not equal to an "ast"(abstract syntax tree) > but its difficult to find a name for an ast that is not cached. > maybe > parsedAst > parseAst > .... > > > On Wed, May 2, 2018 at 3:28 PM, Richard Sargent <richard.sargent(a)gemtalksystems.com> wrote: > On Wed, May 2, 2018 at 11:06 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Hi. > > Maybe #parseSourceCode would be better name for #parseTree. > > I've always found it good advice to avoid using a verb phrase to name something which does not entail some kind of action. > #parseSourceCode realy reads like something which would parse the source code. #parseTree also has that effect, except for the lack of a tree to parse. > > > > 2018-05-02 16:33 GMT+03:00 Marcus Denker <marcus.denker(a)inria.fr>: > > > > On 27 Apr 2018, at 21:36, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > > > Marcus Denker-4 wrote > >> I will add commentsâ¦ > > > > I got confused by this again and created an issue: > > https://pharo.manuscript.com/f/cases/21806/Document-Difference-between-ast-… > > > > And then Peter Uhnak reminded me on Discord about this thread. I'm happy to > > add the comments, but not sure I understand the issue well enough. IIUC #ast > > is cached, but #parseTree is not. What I don't understand is the purpose of > > this difference and when one would use one over the other. > > the cached #ast is for one interesting for speed (that is, in situations where you ask for it often). > > The other use-case is if you want to annotate the AST and keep that annotation around (till the next > image save, but you can subscribe to ASTCacheReset and re-install the AST in the cache after cleaning. > (This is used by MetaLinks to make sure they survive image restart). > > The last thing that it provides is that we do have a quite powerful mapping between bytecode/text/context > and the AST. Regardless how you navigate, you get the same object. > > e.g. even this one works: > > [ 1+2 ] sourceNode == thisContext method ast blockNodes first > > > For example, > > when, if ever, would a user want to access a CM's #ast (as opposed to > > #parseTree) and could modifying it create problems? > > > > Modification is a problem, yes.. code that wants to modify the AST without making sure the compiledMethod is in sync later > should use #parseTree. > > Code that does not modify the AST (or makes sure to compile it after modification) is free to use #ast. > or if you want to annotate the AST (which is a modification, after all). > > This is not perfect (not at allâ¦) but the simplest solution to get (to some extend) what you would have if the system would have > a real persistent, first class ASTâ¦ > > To be improved. The ASTCache with itâs naive âlets just cache everything till the next image saveâ was done with the idea to see > when it would show that it is too naiveâ¦ for that it worked amazingly well till now. > > Marcus > > > > > > -- > Bernardo E.C. > > Sent from a cheap desktop computer in South America. > > > > -- > > Guille Polito > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > CRIStAL - UMR 9189 > French National Center for Scientific Research - http://www.cnrs.fr > > Web: http://guillep.github.io > Phone: +33 06 52 70 66 13 -- www.tudorgirba.com www.feenk.com "What is more important: To be happy, or to make happy?"

May 3, 2018

Re: [Pharo-users] Restoring a class via Epicea didn't recompile a reference?

by Marcus Denker

> On 2 May 2018, at 14:09, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > >> On 26 Apr 2018, at 09:28, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >> >> Hi, >> >> It looks you got bit by this issue: >> >> https://pharo.fogbugz.com/f/cases/21519/RemoveFromSystem-does-not-work-well… >> >> It's not particular to Epicea. There should be a better management of Undeclareds in general in all Pharo. >> > > It can be fixed by moving the binding to undeclared in #removeFromSystem: > > This is done by adding > > Undeclared declare: self name asSymbol from: Smalltalk globals. > > before the "forgetClass: self logged:" line. > > What we need to do in addition: Only do that when the class is referenced. #isUsedClass: does that, but it does integrate over all methods in the system. > I did a PR: https://github.com/pharo-project/pharo/pull/1281 <https://github.com/pharo-project/pharo/pull/1281> Marcus

May 3, 2018

Re: [Pharo-users] #ast vs. #parseTree

by Guillermo Polito

method newAst ? On Wed, May 2, 2018 at 11:03 PM, Bernardo Ezequiel Contreras < vonbecmann(a)gmail.com> wrote: > a "parse tree" is not equal to an "ast"(abstract syntax tree) > but its difficult to find a name for an ast that is not cached. > maybe > parsedAst > parseAst > .... > > > On Wed, May 2, 2018 at 3:28 PM, Richard Sargent <richard.sargent@ > gemtalksystems.com> wrote: > >> On Wed, May 2, 2018 at 11:06 AM, Denis Kudriashov <dionisiydk(a)gmail.com> >> wrote: >> >>> Hi. >>> >>> Maybe #parseSourceCode would be better name for #parseTree. >>> >> >> I've always found it good advice to avoid using a verb phrase to name >> something which does not entail some kind of action. >> #parseSourceCode realy reads like something which would parse the source >> code. #parseTree also has that effect, except for the lack of a tree to >> parse. >> >> >> >>> >>> 2018-05-02 16:33 GMT+03:00 Marcus Denker <marcus.denker(a)inria.fr>: >>> >>>> >>>> >>>> > On 27 Apr 2018, at 21:36, Sean P. DeNigris <sean(a)clipperadams.com> >>>> wrote: >>>> > >>>> > Marcus Denker-4 wrote >>>> >> I will add commentsâ¦ >>>> > >>>> > I got confused by this again and created an issue: >>>> > https://pharo.manuscript.com/f/cases/21806/Document-Differen >>>> ce-between-ast-and-parseTree >>>> > >>>> > And then Peter Uhnak reminded me on Discord about this thread. I'm >>>> happy to >>>> > add the comments, but not sure I understand the issue well enough. >>>> IIUC #ast >>>> > is cached, but #parseTree is not. What I don't understand is the >>>> purpose of >>>> > this difference and when one would use one over the other. >>>> >>>> the cached #ast is for one interesting for speed (that is, in >>>> situations where you ask for it often). >>>> >>>> The other use-case is if you want to annotate the AST and keep that >>>> annotation around (till the next >>>> image save, but you can subscribe to ASTCacheReset and re-install the >>>> AST in the cache after cleaning. >>>> (This is used by MetaLinks to make sure they survive image restart). >>>> >>>> The last thing that it provides is that we do have a quite powerful >>>> mapping between bytecode/text/context >>>> and the AST. Regardless how you navigate, you get the same object. >>>> >>>> e.g. even this one works: >>>> >>>> [ 1+2 ] sourceNode == thisContext method ast blockNodes first >>>> >>>> > For example, >>>> > when, if ever, would a user want to access a CM's #ast (as opposed to >>>> > #parseTree) and could modifying it create problems? >>>> > >>>> >>>> Modification is a problem, yes.. code that wants to modify the AST >>>> without making sure the compiledMethod is in sync later >>>> should use #parseTree. >>>> >>>> Code that does not modify the AST (or makes sure to compile it after >>>> modification) is free to use #ast. >>>> or if you want to annotate the AST (which is a modification, after all). >>>> >>>> This is not perfect (not at allâ¦) but the simplest solution to get (to >>>> some extend) what you would have if the system would have >>>> a real persistent, first class ASTâ¦ >>>> >>>> To be improved. The ASTCache with itâs naive âlets just cache >>>> everything till the next image saveâ was done with the idea to see >>>> when it would show that it is too naiveâ¦ for that it worked amazingly >>>> well till now. >>>> >>>> Marcus >>>> >>> >>> >> > > > -- > Bernardo E.C. > > Sent from a cheap desktop computer in South America. > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

May 3, 2018

Re: [Pharo-users] Saving a Smalltalk Project

by Sean P. DeNigris

horrido wrote > what types of recent industrial projects youve come across that use > Smalltalk? One that immediately comes to mind is Lam Research: https://pharo.org/success/LAMRC ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

May 2, 2018

Re: [Pharo-users] #ast vs. #parseTree

by Bernardo Ezequiel Contreras

a "parse tree" is not equal to an "ast"(abstract syntax tree) but its difficult to find a name for an ast that is not cached. maybe parsedAst parseAst .... On Wed, May 2, 2018 at 3:28 PM, Richard Sargent < richard.sargent(a)gemtalksystems.com> wrote: > On Wed, May 2, 2018 at 11:06 AM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > >> Hi. >> >> Maybe #parseSourceCode would be better name for #parseTree. >> > > I've always found it good advice to avoid using a verb phrase to name > something which does not entail some kind of action. > #parseSourceCode realy reads like something which would parse the source > code. #parseTree also has that effect, except for the lack of a tree to > parse. > > > >> >> 2018-05-02 16:33 GMT+03:00 Marcus Denker <marcus.denker(a)inria.fr>: >> >>> >>> >>> > On 27 Apr 2018, at 21:36, Sean P. DeNigris <sean(a)clipperadams.com> >>> wrote: >>> > >>> > Marcus Denker-4 wrote >>> >> I will add commentsâ¦ >>> > >>> > I got confused by this again and created an issue: >>> > https://pharo.manuscript.com/f/cases/21806/Document-Differen >>> ce-between-ast-and-parseTree >>> > >>> > And then Peter Uhnak reminded me on Discord about this thread. I'm >>> happy to >>> > add the comments, but not sure I understand the issue well enough. >>> IIUC #ast >>> > is cached, but #parseTree is not. What I don't understand is the >>> purpose of >>> > this difference and when one would use one over the other. >>> >>> the cached #ast is for one interesting for speed (that is, in situations >>> where you ask for it often). >>> >>> The other use-case is if you want to annotate the AST and keep that >>> annotation around (till the next >>> image save, but you can subscribe to ASTCacheReset and re-install the >>> AST in the cache after cleaning. >>> (This is used by MetaLinks to make sure they survive image restart). >>> >>> The last thing that it provides is that we do have a quite powerful >>> mapping between bytecode/text/context >>> and the AST. Regardless how you navigate, you get the same object. >>> >>> e.g. even this one works: >>> >>> [ 1+2 ] sourceNode == thisContext method ast blockNodes first >>> >>> > For example, >>> > when, if ever, would a user want to access a CM's #ast (as opposed to >>> > #parseTree) and could modifying it create problems? >>> > >>> >>> Modification is a problem, yes.. code that wants to modify the AST >>> without making sure the compiledMethod is in sync later >>> should use #parseTree. >>> >>> Code that does not modify the AST (or makes sure to compile it after >>> modification) is free to use #ast. >>> or if you want to annotate the AST (which is a modification, after all). >>> >>> This is not perfect (not at allâ¦) but the simplest solution to get (to >>> some extend) what you would have if the system would have >>> a real persistent, first class ASTâ¦ >>> >>> To be improved. The ASTCache with itâs naive âlets just cache everything >>> till the next image saveâ was done with the idea to see >>> when it would show that it is too naiveâ¦ for that it worked amazingly >>> well till now. >>> >>> Marcus >>> >> >> > -- Bernardo E.C. Sent from a cheap desktop computer in South America.

May 2, 2018

Re: [Pharo-users] Saving a Smalltalk Project

by Todd Blanchard

OK, so I'm curious what hardware platforms you guys use for your "things"? Been doing things with Particle lately. Interested to try their new mesh offering. > On May 2, 2018, at 12:30 PM, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: > > If they are interested, we can get in touch. We are working on IoT for environmental monitoring and Iâm working in Cameroon. > > Regards, > > EnvoyÃ© de mon iPad > >> Le 2 mai 2018 Ã 19:21, horrido <horrido.hobbies(a)gmail.com> a Ã©crit : >> >> I received the following message: >> >> *We started off doing a small project in conservation in South Africa that >> involved tracking Rhinos in a remote GPS denied environment and ended up >> with some impressive building blocks for a Big Data Platform for IoT. The >> platform includes its own GIS subsystem and parts of an Expert System. >> >> Due to the choice made by my business partner and handful of contractors the >> platform ended up being built in Smalltalk on Squeak VM and the Magma >> Object Database. >> >> We now believe we may have the beginning of a commercial platform however >> its notoriously difficult to find Smalltalk developers so I am in half minds >> to migrate to a platform which uses a more mainstream language (Java / >> Python) as I have been getting some strange reactions from Angel Investors / >> VCs and mainstream developers. >> >> ... >> >> I wanted to ask you if you have information on how big the Smalltalk >> community is and whether its better to migrate to Pharo from Squeak and what >> types of recent industrial projects youve come across that use Smalltalk? >> >> Also I wondered if you know of any active smalltalk group in Silicon Valley >> and what are the best forums for professional SmallTalk development.* >> >> I would very much like to save their project as a Smalltalk project. The >> principal issue seems to be finding enough Smalltalk developers. I don't >> know if they need on-site developers or if remote developers can pass >> muster. I strongly suspect the former. >> >> How hard would it be to find Smalltalkers willing to work in Silicon Valley, >> or South Africa? >> >> What is the best response to this person? Thanks. >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> >

May 2, 2018

Re: [Pharo-users] Saving a Smalltalk Project

by Serge Stinckwich

If they are interested, we can get in touch. We are working on IoT for environmental monitoring and Iâm working in Cameroon. Regards, EnvoyÃ© de mon iPad > Le 2 mai 2018 Ã 19:21, horrido <horrido.hobbies(a)gmail.com> a Ã©crit : > > I received the following message: > > *We started off doing a small project in conservation in South Africa that > involved tracking Rhinos in a remote GPS denied environment and ended up > with some impressive building blocks for a Big Data Platform for IoT. The > platform includes its own GIS subsystem and parts of an Expert System. > > Due to the choice made by my business partner and handful of contractors the > platform ended up being built in Smalltalk on Squeak VM and the Magma > Object Database. > > We now believe we may have the beginning of a commercial platform however > its notoriously difficult to find Smalltalk developers so I am in half minds > to migrate to a platform which uses a more mainstream language (Java / > Python) as I have been getting some strange reactions from Angel Investors / > VCs and mainstream developers. > > ... > > I wanted to ask you if you have information on how big the Smalltalk > community is and whether its better to migrate to Pharo from Squeak and what > types of recent industrial projects youve come across that use Smalltalk? > > Also I wondered if you know of any active smalltalk group in Silicon Valley > and what are the best forums for professional SmallTalk development.* > > I would very much like to save their project as a Smalltalk project. The > principal issue seems to be finding enough Smalltalk developers. I don't > know if they need on-site developers or if remote developers can pass > muster. I strongly suspect the former. > > How hard would it be to find Smalltalkers willing to work in Silicon Valley, > or South Africa? > > What is the best response to this person? Thanks. > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

May 2, 2018

Re: [Pharo-users] Iceberg Pharo6.1 on Microsoft Windows 7

by Ben Coman

On 2 May 2018 at 22:02, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Hi Federico, > > I don't think compiling libgit in your box will solve the problem. I think > libgit is correctly compiled (otherwise you'd have another kind of error). > What you probably have is an ssh authentication error. > It would be nice if a test like the following could done, and if failed, some platform specific help information be provided - like that Windows needs "Custom" credentials. https://help.github.com/articles/testing-your-ssh-connection/ cheers -ben > > Could you try cloning using the https url provided by github instead? > > That should generally solve your problem. > > The other thing is that the version of iceberg in pharo 6 is really > outdated. We will soon backport the new version, I'll keep everybody posted > in this mailing list. > > Otherwise, you can test latest Pharo 7, with the latest Iceberg version. > The issue tracker is here: > > https://github.com/pharo-vcs/iceberg/issues > > Tx, > Guille > > On Wed, May 2, 2018 at 2:01 PM, Federico.Balaguer < > federico.balaguer(a)gmail.com> wrote: > >> Hello, >> >> I am trying to help some newbies to Smalltalk to use Iceberg on Pharo6.1 >> on >> Windows 7. >> I have a VirtualBox with Windows 7, I have the PharoLauncher installed >> from >> where I launch the Pharo 6.1 image. >> >> I cannot clone github repositories, I get a debugger: "LGit_GIT_ERROR: >> failed to get server certificate: The handle is in the wrong state for the >> requested operation" >> >> Do I have to compile libgit or libgit2 on the MSWindows virtual machine? >> >> thanks. federico >> >> >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> >> > > > -- > > > > Guille Polito > > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > > CRIStAL - UMR 9189 > > French National Center for Scientific Research - *http://www.cnrs.fr > <http://www.cnrs.fr>* > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 >

May 2, 2018