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

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