- Pharo-dev - lists.pharo.org

[Ann] Iceberg 0.7.3

by Guillermo Polito

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 <https://github.com/pharo-vcs/iceberg/pull/693>: fixing problem when the announcement of changes in a package is nil. (bug, important) - #682 <https://github.com/pharo-vcs/iceberg/issues/682>: update update script (Pharo6-backport) - #681 <https://github.com/pharo-vcs/iceberg/issues/681>: Author name is not correctly decoded (UI, enhancement) - #680 <https://github.com/pharo-vcs/iceberg/issues/680>: Repair actions dialog should explain the situation (UI, enhancement, important) - #679 <https://github.com/pharo-vcs/iceberg/issues/679>: Create branch repair action should show create branch from issue if available (Pharo plugin, UI) - #678 <https://github.com/pharo-vcs/iceberg/issues/678>: Iceberg does not correctly recognize packages (bug, important) - #677 <https://github.com/pharo-vcs/iceberg/issues/677>: Unknown commit can only be solved with repair action (Model, bug, important) - #676 <https://github.com/pharo-vcs/iceberg/issues/676>: Unknown commit state is not properly shown (UI, bug, important) - #667 <https://github.com/pharo-vcs/iceberg/issues/667>: Merging branches with file deletion doesn't seem possible (bug, important, merge) - #666 <https://github.com/pharo-vcs/iceberg/issues/666>: Iceberg sometimes add a $ to commit message (Model, bug) - #662 <https://github.com/pharo-vcs/iceberg/issues/662>: The Pharo plugin has to do the fetch only if required. (Pharo plugin, enhancement) - #660 <https://github.com/pharo-vcs/iceberg/pull/660>: Add a star badge in the push button in case of a new branch () - #658 <https://github.com/pharo-vcs/iceberg/issues/658>: Progress Bar during checkout of Repository. (UI, enhancement) - #657 <https://github.com/pharo-vcs/iceberg/issues/657>: Confusing UI: Ghost Test maybe should be default? (UI, enhancement) - #656 <https://github.com/pharo-vcs/iceberg/issues/656>: Typo in Progress Bar (UI, bug) - #651 <https://github.com/pharo-vcs/iceberg/issues/651>: When pushing a new branch the list of commit is empty (UI, bug) - #650 <https://github.com/pharo-vcs/iceberg/issues/650>: "Create new branch from issue" is leaving image in detached working copy state () - #649 <https://github.com/pharo-vcs/iceberg/issues/649>: The VM is crashing when trying to use Iceberg from a saved image (bug) - #645 <https://github.com/pharo-vcs/iceberg/issues/645>: IceLibgitRepository should use "utilities" protocol instead of "utils" (clean up) - #644 <https://github.com/pharo-vcs/iceberg/issues/644>: Unnecessary temp in IceTipGitHubRepositoryPanel>>#getGitHubRepository" (clean up) - #643 <https://github.com/pharo-vcs/iceberg/issues/643>: LGit_GIT_ERROR: error authenticating: no auth sock variable loading a Tonel based baseline dependency in smalltalkCI (bug, important) - #639 <https://github.com/pharo-vcs/iceberg/issues/639>: Create pull request fails if branch has not been pushed (Github plugin, bug) - #636 <https://github.com/pharo-vcs/iceberg/issues/636>: The pull button should have a star badge when it has no upstream (UI, enhancement, important) - #634 <https://github.com/pharo-vcs/iceberg/issues/634>: Travis is not building Pull Requests (CI, bug, important) - #624 <https://github.com/pharo-vcs/iceberg/issues/624>: add "add remote" to remote picking on pull/push browsers (enhancement) - #610 <https://github.com/pharo-vcs/iceberg/pull/610>: Fix for issue #608 <https://github.com/pharo-vcs/iceberg/issues/608> and #607 <https://github.com/pharo-vcs/iceberg/issues/607>. (clean up) - #609 <https://github.com/pharo-vcs/iceberg/issues/609>: New branch repair action does not refresh dirty packages (UI, bug) - #583 <https://github.com/pharo-vcs/iceberg/issues/583>: Creating a tonel project does not commit the properties file (Model, bug) - #542 <https://github.com/pharo-vcs/iceberg/issues/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 <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

April 25, 2018

Re: [Pharo-dev] Do we kill the catalog?

by Sean P. DeNigris

Thierry Goubier wrote > If using a baseline in the Catalog forces it to be more complexâ¦ I didn't think we were discussing changing baselines themselves, just a better adapter layer than hand-edited Configs Thierry Goubier wrote > A typical git-based development is one tag or branch per pharo > version, hence one BaselineOf per supported Pharo version. Hmm, I didn't know that. I have not been using that workflow, but '*-PlatformPharo60' packages. I wonder what the tradeoffs areâ¦ ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

April 24, 2018

[Pharo 7.0-dev] Build #805: 21777 Some assert:equal: and formatting cleanups in UFFI

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #805 was: SUCCESS. The Pull Request #1250 was integrated: "21777 Some assert:equal: and formatting cleanups in UFFI" Pull request url: https://github.com/pharo-project/pharo/pull/1250 Issue Url: https://pharo.fogbugz.com/f/cases/21777 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 24, 2018

Re: [Pharo-dev] Do we kill the catalog?

by monty

Thanks! ___ montyos.wordpress.com > Sent: Tuesday, April 24, 2018 at 1:31 AM > From: "Sven Van Caekenberghe" <sven(a)stfx.eu> > To: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Subject: Re: [Pharo-dev] Do we kill the catalog? > > > > > On 24 Apr 2018, at 00:49, monty <monty2(a)programmer.net> wrote: > > > > +1. > > > > Replacing is sometimes necessary (Sven's stream work is an obvious example), but I don't see why Nautilus had to be junked rather than gradually evolved into Calypso. And I don't see why the catalog can't be gradually evolved into something better. Killing it off would be discouraging to the users who went through the trouble of adding #catalogXXX methods to their configs and publishing them to the meta repos. Why would they bother adopting whatever replaces the catalog if they think it will just get killed off too? > > > > ___ > > montyos.wordpress.com > > Nice blog, BTW! > > Your XML work is much appreciated. > > >> Sent: Sunday, April 22, 2018 at 9:29 AM > >> From: "Torsten Bergmann" <astares(a)gmx.de> > >> To: pharo-dev(a)lists.pharo.org > >> Cc: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > >> Subject: Re: [Pharo-dev] Do we kill the catalog? > >> > >> Hi Stef, > >> > >> do not worry - I'm fully relaxed. It is you - who suggested to kill the catalog - without having > >> or proposing a suitable alternative yet. If you want to route the thread to talking about "idiots" > >> and "assholes" you go offtopic and I guess I have nothing more to contribute to the discussion. > >> > >> If it was not clear from my writing: I only expressed my wish that we should better improve it > >> instead of killing it. That's all. > >> > >> Because anytime we have a better idea we get more disruptive in what we provide ... and this > >> leads to the unfortunate situation: > >> > >> - that we replace our own stuff with newer ones again and again (which can but must not be good > >> as things get more diverse and complicated over time) > >> - that users have to know how things historically have been progressed to find its way > >> through Pharo (including the terms and tools we use) > >> > >> I would not see this as a rant - but rather a true effect we can spot on many places in our > >> ecosystem already. > >> > >> Long story short: I would vote for the "fix" if the sole other option is to "remove". > >> > >> Bye > >> T. > >> > >> > >>> Gesendet: Samstag, 21. April 2018 um 15:31 Uhr > >>> Von: "Stephane Ducasse" <stepharo.self(a)gmail.com> > >>> An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > >>> Betreff: Re: [Pharo-dev] Do we kill the catalog? > >>> > >>> Torsten > >>> > >>> Sometimes you should relax. Because if you remember I pushed the > >>> catalog (in fact I love it and we need a much more powerful one) > >>> and I even improved it. I made it better to automatically add MC repositories. > >>> Of course Thierry is exagerating. > >>> > >>> Now we should fix or remove it. Simple no? > >>> > >>> Now you can rant in your corner thinking that I'm asshole. > >>> This is ok for me. > >>> > >>> Stef > >>> > >>> On Sat, Apr 21, 2018 at 3:06 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > >>>> Even there is no learning from the past - it's deja vu all over again... > >>>> > >>>> > >>>>> Gesendet: Freitag, 20. April 2018 um 08:53 Uhr > >>>>> Von: "Stephane Ducasse" <stepharo.self(a)gmail.com> > >>>>> An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > >>>>> Betreff: Re: [Pharo-dev] Do we kill the catalog? > >>>>> > >>>>> Hi torsten > >>>>> > >>>>> the wise shows the moon, the idiot sees his finger. > >>>>> > >>>>> Stef > >>>>> > >>>>> > >>>>> On Thu, Apr 19, 2018 at 10:38 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > >>>>>> Now today you had loading trouble with Smacc from Catalog ... and now directly want to > >>>>>> kill catalog. Wow! > >>>>>> > >>>>>> Sometimes I have the impression that our community tries to reinvent itself each day > >>>>>> doing it differently (but not only better) instead of extending, improving and supporting > >>>>>> what we have have done before. Which sometimes is good ... but not always. > >>>>>> > >>>>>> Thx > >>>>>> T. > >>>>>> > >>>>>>> Gesendet: Donnerstag, 19. April 2018 um 08:42 Uhr > >>>>>>> Von: "Stephane Ducasse" <stepharo.self(a)gmail.com> > >>>>>>> An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > >>>>>>> Betreff: [Pharo-dev] Do we kill the catalog? > >>>>>>> > >>>>>>> Hi guys > >>>>>>> > >>>>>>> What do we do with it? > >>>>>>> What alternatives? > >>>>>>> > >>>>>>> Stef > >>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>>> > >>>> > >>> > >>> > >> > >> > > > > >

April 24, 2018

Re: [Pharo-dev] Do we kill the catalog?

by monty

> Sent: Tuesday, April 24, 2018 at 3:42 AM > From: "Esteban Lorenzano" <estebanlm(a)gmail.com> > To: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Subject: Re: [Pharo-dev] Do we kill the catalog? > > hi, > > > > On 24 Apr 2018, at 00:49, monty <monty2(a)programmer.net> wrote: > > > > +1. > > > > Replacing is sometimes necessary (Sven's stream work is an obvious example), but I don't see why Nautilus had to be junked rather than gradually evolved into Calypso. > > thatâs clearly because you didnât see nautilus at the inside. Actually, I did see the inside, to improve its SUnit integration. > In fact, calypso started like thatâ¦ we wanted to refactor nautilus into something usable, but after losing two months of Denis work, we decided to go other direction, since it was just impossible to do it properly without doing it again. And the effort of doing it from scratch was less than âdestroy the house for the inside but let the faÃ§adeâ that would have been working with Nautilus. Also, in the case of Nautilus (or any system browser), there is the adding complexity of refactoring within itself. > Not everything can be refactored/patched up to the infinite. > > > And I don't see why the catalog can't be gradually evolved into something better. Killing it off would be discouraging to the users who went through the trouble of adding #catalogXXX methods to their configs and publishing them to the meta repos. Why would they bother adopting whatever replaces the catalog if they think it will just get killed off too? > > catalog was a âtemporary pieceâ that stayed for years. > it was never intend to stay because it has some important limitations. > said that, it can evolve from the quasi-prototype it is now (I should know, it was me who did it) to a real catalog. > > curiously, Iâm thinking one part of making it better would be simplify it, but thatâs another story. > > I wonder why people is so concerned about the use of âkilling catalogâ phrase. If you know the history of Pharo, we never âkillâ anything we do not have a replacement for it so it was never in the table a proposal of just removing it. But to be good it needs: > > - some better way of collect baselines than force to build a configuration > - a better place to be > - some kind of validation rules > - etc, etc, etc. > > So well, in this case maybe refactor it is not an option, since many of the assumptions it has are no longer valid. > > cheers, > Esteban > > > > > ___ > > montyos.wordpress.com > > > > > >> Sent: Sunday, April 22, 2018 at 9:29 AM > >> From: "Torsten Bergmann" <astares(a)gmx.de> > >> To: pharo-dev(a)lists.pharo.org > >> Cc: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > >> Subject: Re: [Pharo-dev] Do we kill the catalog? > >> > >> Hi Stef, > >> > >> do not worry - I'm fully relaxed. It is you - who suggested to kill the catalog - without having > >> or proposing a suitable alternative yet. If you want to route the thread to talking about "idiots" > >> and "assholes" you go offtopic and I guess I have nothing more to contribute to the discussion. > >> > >> If it was not clear from my writing: I only expressed my wish that we should better improve it > >> instead of killing it. That's all. > >> > >> Because anytime we have a better idea we get more disruptive in what we provide ... and this > >> leads to the unfortunate situation: > >> > >> - that we replace our own stuff with newer ones again and again (which can but must not be good > >> as things get more diverse and complicated over time) > >> - that users have to know how things historically have been progressed to find its way > >> through Pharo (including the terms and tools we use) > >> > >> I would not see this as a rant - but rather a true effect we can spot on many places in our > >> ecosystem already. > >> > >> Long story short: I would vote for the "fix" if the sole other option is to "remove". > >> > >> Bye > >> T. > >> > >> > >>> Gesendet: Samstag, 21. April 2018 um 15:31 Uhr > >>> Von: "Stephane Ducasse" <stepharo.self(a)gmail.com> > >>> An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > >>> Betreff: Re: [Pharo-dev] Do we kill the catalog? > >>> > >>> Torsten > >>> > >>> Sometimes you should relax. Because if you remember I pushed the > >>> catalog (in fact I love it and we need a much more powerful one) > >>> and I even improved it. I made it better to automatically add MC repositories. > >>> Of course Thierry is exagerating. > >>> > >>> Now we should fix or remove it. Simple no? > >>> > >>> Now you can rant in your corner thinking that I'm asshole. > >>> This is ok for me. > >>> > >>> Stef > >>> > >>> On Sat, Apr 21, 2018 at 3:06 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > >>>> Even there is no learning from the past - it's deja vu all over again... > >>>> > >>>> > >>>>> Gesendet: Freitag, 20. April 2018 um 08:53 Uhr > >>>>> Von: "Stephane Ducasse" <stepharo.self(a)gmail.com> > >>>>> An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > >>>>> Betreff: Re: [Pharo-dev] Do we kill the catalog? > >>>>> > >>>>> Hi torsten > >>>>> > >>>>> the wise shows the moon, the idiot sees his finger. > >>>>> > >>>>> Stef > >>>>> > >>>>> > >>>>> On Thu, Apr 19, 2018 at 10:38 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > >>>>>> Now today you had loading trouble with Smacc from Catalog ... and now directly want to > >>>>>> kill catalog. Wow! > >>>>>> > >>>>>> Sometimes I have the impression that our community tries to reinvent itself each day > >>>>>> doing it differently (but not only better) instead of extending, improving and supporting > >>>>>> what we have have done before. Which sometimes is good ... but not always. > >>>>>> > >>>>>> Thx > >>>>>> T. > >>>>>> > >>>>>>> Gesendet: Donnerstag, 19. April 2018 um 08:42 Uhr > >>>>>>> Von: "Stephane Ducasse" <stepharo.self(a)gmail.com> > >>>>>>> An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > >>>>>>> Betreff: [Pharo-dev] Do we kill the catalog? > >>>>>>> > >>>>>>> Hi guys > >>>>>>> > >>>>>>> What do we do with it? > >>>>>>> What alternatives? > >>>>>>> > >>>>>>> Stef > >>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>>> > >>>> > >>> > >>> > >> > >> > > > > > ___ montyos.wordpress.com

April 24, 2018

Re: [Pharo-dev] (no subject)

by Tudor Girba

Welcome, Tristan! Please let us know how we can help you. Cheers, Doru > On Apr 24, 2018, at 5:14 PM, Tristan Debrousse <tristandebrousse(a)gmail.com> wrote: > > Hello, I am a student at UniversitÃ© de Bretagne Occidentale (Brest, France) and I just began an internship project of 6 weeks with Alain Plantec and Steven Costiou. The project involves the use of Pharo with Bloc to develop a GUI. > > -- > Tristan -- www.tudorgirba.com www.feenk.com "Innovation comes in the least expected form. That is, if it is expected, it already happened."

April 24, 2018

Re: [Pharo-dev] (no subject)

by Sven Van Caekenberghe

That's great, Tristan. Welcome ! Have fun. Sven > On 24 Apr 2018, at 17:14, Tristan Debrousse <tristandebrousse(a)gmail.com> wrote: > > Hello, I am a student at UniversitÃ© de Bretagne Occidentale (Brest, France) and I just began an internship project of 6 weeks with Alain Plantec and Steven Costiou. The project involves the use of Pharo with Bloc to develop a GUI. > > -- > Tristan

April 24, 2018

(no subject)

by Tristan Debrousse

Hello, I am a student at UniversitÃ© de Bretagne Occidentale (Brest, France) and I just began an internship project of 6 weeks with Alain Plantec and Steven Costiou. The project involves the use of Pharo with Bloc to develop a GUI. -- Tristan

April 24, 2018

Re: [Pharo-dev] Do we kill the catalog?

by Thierry Goubier

Hi Sean, Guille, 2018-04-24 15:31 GMT+02:00 Sean P. DeNigris <sean(a)clipperadams.com>: > Guillermo Polito wrote >> Should we continue providing configurations that point to the >> baselines? I've read some rants against it. >> I know it may be "uncomfortable", but publishing some meta-data in a >> repository in XXX technology is kind of the same... Baselines are simple. If using a baseline in the Catalog forces it to be more complex (like need to add a repository url in the baseline), then do not do it and only support configurations. > This seems like an implementation detail. IHMO what people are really > complaining about is lack of tool support to map some standard, repeatable > trustability system like a Config's #stable and #development to a baseline > that refers to an exact snapshot of code (i.e. commitish in git parlance > IIUC). Sort of. A typical git-based development is one tag or branch per pharo version, hence one BaselineOf per supported Pharo version. A single configuration in the Catalog can triage on those baselines, and be used by multiple Pharo versions (4, 5, 6, 7, etc...) This would point out to having only one repository for the Catalog (for all Pharo versions); but the ability for the Catalog to filter out Configurations that are not updated on newer versions. Bonus: if you're tracking Pharo versions in your branches (if you have pharo5.0, pharo6.0, pharo7.0 branches, for example), it may be possible to write a generic url in the configurationOf, like that: repository: 'github://dalehenrich/filetree:pharo', SystemVersion current dottedMajorMinor ,'_dev/repository' Bonus+: you can also play with Unix / Windows dependent branches (because you can also query additional system attributes) Bonus++: Smalltalkhub repositories would still work... Feature: it would be nice to be able to test if the current version-dependent branch or tag exists on the target (i.e. query github), then it would be easy to write something like -> no pharo8.0 branch on repository ? Not available on Pharo8. Thierry > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

April 24, 2018

Re: [Pharo-dev] Do we kill the catalog?

by Sean P. DeNigris

Guillermo Polito wrote > Should we continue providing configurations that point to the > baselines? I've read some rants against it. > I know it may be "uncomfortable", but publishing some meta-data in a > repository in XXX technology is kind of the same... This seems like an implementation detail. IHMO what people are really complaining about is lack of tool support to map some standard, repeatable trustability system like a Config's #stable and #development to a baseline that refers to an exact snapshot of code (i.e. commitish in git parlance IIUC). ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

April 24, 2018