September 2018 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Pharo 7.0-dev] Build #1249: 22452 Added #labelHeight method.

by Julien

Seems strange to have the CI failing with this changeâ¦ --- Julien Delplanque Doctorant Ã lâUniversitÃ© de Lille http://juliendelplanque.be/phd.html Equipe Rmod, Inria BÃ¢timent B 40, Avenue Halley 59650 Villeneuve d'Ascq NumÃ©ro de tÃ©lÃ©phone: +333 59 35 86 40 > Le 16 sept. 2018 Ã 18:30, ci-pharo-ci-jenkins2(a)inria.fr a Ã©crit : > > There is a new Pharo build available! > > The status of the build #1249 was: FAILURE. > > The Pull Request #1800 was integrated: "22452 Added #labelHeight method." > Pull request url: https://github.com/pharo-project/pharo/pull/1800 > > Issue Url: https://pharo.fogbugz.com/f/cases/22452 > Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 16, 2018

[Pharo 7.0-dev] Build #1250: 22451 Unselecting example from SpecDemo's left list raises an exception

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

There is a new Pharo build available! The status of the build #1250 was: SUCCESS. The Pull Request #1802 was integrated: "22451 Unselecting example from SpecDemo's left list raises an exception" Pull request url: https://github.com/pharo-project/pharo/pull/1802 Issue Url: https://pharo.fogbugz.com/f/cases/22451 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 16, 2018

[Pharo 7.0-dev] Build #1249: 22452 Added #labelHeight method.

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

There is a new Pharo build available! The status of the build #1249 was: FAILURE. The Pull Request #1800 was integrated: "22452 Added #labelHeight method." Pull request url: https://github.com/pharo-project/pharo/pull/1800 Issue Url: https://pharo.fogbugz.com/f/cases/22452 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 16, 2018

[Pharo 7.0-dev] Build #1248: 22454 Add comments to #presenter:configuredAs: and #presenterProvidedBy:configuredAs: methods of DynamicPresentersListBuilder

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

There is a new Pharo build available! The status of the build #1248 was: FAILURE. The Pull Request #1801 was integrated: "22454 Add comments to #presenter:configuredAs: and #presenterProvidedBy:configuredAs: methods of DynamicPresentersListBuilder" Pull request url: https://github.com/pharo-project/pharo/pull/1801 Issue Url: https://pharo.fogbugz.com/f/cases/22454 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 16, 2018

[Pharo 7.0-dev] Build #1247: 22443 Tag and comment ManifestSystemAnnouncements

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

There is a new Pharo build available! The status of the build #1247 was: FAILURE. The Pull Request #1790 was integrated: "22443 Tag and comment ManifestSystemAnnouncements" Pull request url: https://github.com/pharo-project/pharo/pull/1790 Issue Url: https://pharo.fogbugz.com/f/cases/22443 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 14, 2018

Re: [Pharo-dev] UndefinedClasses as first class entities for P7

by Tim Mackinnon

Kind of related - we did get the ability to save methods with undefined classes and undeclared variables (vs having to correct this to save). So at least a nod to that? Tim Sent from my iPhone > On 13 Sep 2018, at 08:22, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > Well it's just a matter of stability, we were too concentrated with other stuff. > But I fear that this would be a too disrupting change to apply now in Pharo 7... > > We were thinking that our focus before the release should be: > - fix the important bugs out there (so, everybody, please raise/report your issues :)) > - iterate on Calypso a bit more so we fix some usability glitches > >> On Thu, Sep 13, 2018 at 4:58 PM Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> We didn't have the time to work on it. >> It is still part of the roadmap (since we need it to dream with a nice module system), but it will probably arrive in P8. >> >> Esteban >> >>> On Thu, Sep 13, 2018 at 4:51 PM Torsten Bergmann <astares(a)gmx.de> wrote: >>> At ESUG 207 there was a presentation about UndefinedClasses as first class entities. >>> >>> According to the slides: >>> >>> https://de.slideshare.net/esug/firstclass-undefined-classes-for-pharo-from-… >>> >>> this was planned for inclusion into Pharo 7. >>> >>> Is this still on the plate? Any status? >>> >>> Thanks >>> T. >>> > > > -- > > 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

Sept. 13, 2018

[Pharo 7.0-dev] Build #1246: 22446 Comment ManifestSpecInspector and ManifestSpecMorphicAdapters

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

There is a new Pharo build available! The status of the build #1246 was: SUCCESS. The Pull Request #1794 was integrated: "22446 Comment ManifestSpecInspector and ManifestSpecMorphicAdapters" Pull request url: https://github.com/pharo-project/pharo/pull/1794 Issue Url: https://pharo.fogbugz.com/f/cases/22446 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 13, 2018

Re: [Pharo-dev] UndefinedClasses as first class entities for P7

by Guillermo Polito

Well it's just a matter of stability, we were too concentrated with other stuff. But I fear that this would be a too disrupting change to apply now in Pharo 7... We were thinking that our focus before the release should be: - fix the important bugs out there (so, everybody, please raise/report your issues :)) - iterate on Calypso a bit more so we fix some usability glitches On Thu, Sep 13, 2018 at 4:58 PM Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > We didn't have the time to work on it. > It is still part of the roadmap (since we need it to dream with a nice > module system), but it will probably arrive in P8. > > Esteban > > On Thu, Sep 13, 2018 at 4:51 PM Torsten Bergmann <astares(a)gmx.de> wrote: > >> At ESUG 207 there was a presentation about UndefinedClasses as first >> class entities. >> >> According to the slides: >> >> >> https://de.slideshare.net/esug/firstclass-undefined-classes-for-pharo-from-… >> >> this was planned for inclusion into Pharo 7. >> >> Is this still on the plate? Any status? >> >> Thanks >> T. >> >> -- 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

Sept. 13, 2018

[Pharo 7.0-dev] Build #1245: 22449-Port-back-old-OSWindow-changes

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

There is a new Pharo build available! The status of the build #1245 was: SUCCESS. The Pull Request #1797 was integrated: "22449-Port-back-old-OSWindow-changes" Pull request url: https://github.com/pharo-project/pharo/pull/1797 Issue Url: https://pharo.fogbugz.com/f/cases/22449 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 13, 2018

Re: [Pharo-dev] UndefinedClasses as first class entities for P7

by Esteban Lorenzano

We didn't have the time to work on it. It is still part of the roadmap (since we need it to dream with a nice module system), but it will probably arrive in P8. Esteban On Thu, Sep 13, 2018 at 4:51 PM Torsten Bergmann <astares(a)gmx.de> wrote: > At ESUG 207 there was a presentation about UndefinedClasses as first class > entities. > > According to the slides: > > > https://de.slideshare.net/esug/firstclass-undefined-classes-for-pharo-from-… > > this was planned for inclusion into Pharo 7. > > Is this still on the plate? Any status? > > Thanks > T. > >

Sept. 13, 2018

UndefinedClasses as first class entities for P7

by Torsten Bergmann

At ESUG 207 there was a presentation about UndefinedClasses as first class entities. According to the slides: https://de.slideshare.net/esug/firstclass-undefined-classes-for-pharo-from-… this was planned for inclusion into Pharo 7. Is this still on the plate? Any status? Thanks T.

Sept. 13, 2018

Re: [Pharo-dev] Artifact and PDFExporter for Roassal

by milton mamani

El jue., 13 sept. 2018 a las 14:06, milton mamani (<akevalion(a)gmail.com>) escribiÃ³: > Hi! > > I am Milton Mamani I work with Roassal2, and now I am in ESUG-Cagliari, > and I have tried to load Artefact with the next piece of code, in the last > Pharo7 image. > > Metacello new > configuration: 'Artefact'; > smalltalkhubUser: 'RMoD' project: 'Artefact'; > version: #stable; > load. > > "To load roassal and pdf roassal exporter" > > Metacello new > configuration: 'GraphQLBeta'; > smalltalkhubUser: 'ObjectProfile' project: 'GraphQL'; > version: #development; > load. > > Gofer new > smalltalkhubUser: 'azazael' project: 'RTPDFExporter'; > package: 'ConfigurationOfRTPDFExporter'; load. > (Smalltalk at: #ConfigurationOfRTPDFExporter) loadDevelopment > > I have a problem, when I tried to export my Roassal-Visualization to pdf > file with for example this piece of code: > > view := RTBoxPlotExample new exampleBoxPlot5 build view. > stream := 'foo.pdf' asFileReference writeStream. > > [RTPDFExporter new > stream: stream; > exportView: view ] ensure: [ stream close ] > > I get a lot of kind exceptions related with the class: PDFStreamPrinter > > In the method visitPDFDataXRefEntry: > And in the logic of the new Stream classes of Pharo7. > > Could you please review Artifact in Pharo7 with this roassal2 > implementation > > Cheers, > Milton > >

Sept. 13, 2018

[Pharo 7.0-dev] Build #1244: 22444 Cleanup manifest in system basic command line handler utilities

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

There is a new Pharo build available! The status of the build #1244 was: SUCCESS. The Pull Request #1791 was integrated: "22444 Cleanup manifest in system basic command line handler utilities" Pull request url: https://github.com/pharo-project/pharo/pull/1791 Issue Url: https://pharo.fogbugz.com/f/cases/22444 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 13, 2018

[Pharo 7.0-dev] Build #1243: 22442 Tag and comment Manifests in all Spec related packages

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

There is a new Pharo build available! The status of the build #1243 was: SUCCESS. The Pull Request #1789 was integrated: "22442 Tag and comment Manifests in all Spec related packages" Pull request url: https://github.com/pharo-project/pharo/pull/1789 Issue Url: https://pharo.fogbugz.com/f/cases/22442 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 13, 2018

[Pharo 7.0-dev] Build #1242: 22439 Cleanup Manifest in RandomCore package

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

There is a new Pharo build available! The status of the build #1242 was: SUCCESS. The Pull Request #1787 was integrated: "22439 Cleanup Manifest in RandomCore package" Pull request url: https://github.com/pharo-project/pharo/pull/1787 Issue Url: https://pharo.fogbugz.com/f/cases/22439 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 13, 2018

[Pharo 7.0-dev] Build #1241: 22376 Add a quick setup to the welcome page

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

There is a new Pharo build available! The status of the build #1241 was: SUCCESS. The Pull Request #1727 was integrated: "22376 Add a quick setup to the welcome page" Pull request url: https://github.com/pharo-project/pharo/pull/1727 Issue Url: https://pharo.fogbugz.com/f/cases/22376 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 13, 2018

[Pharo 7.0-dev] Build #1240: 22435-delete-method-tesOptionAt

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

There is a new Pharo build available! The status of the build #1240 was: FAILURE. The Pull Request #1793 was integrated: "22435-delete-method-tesOptionAt" Pull request url: https://github.com/pharo-project/pharo/pull/1793 Issue Url: https://pharo.fogbugz.com/f/cases/22435 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 11, 2018

Re: [Pharo-dev] Pharo BOF at ESUG

by Christophe Demarey

yes, why not after Â« show us your project Â» today > Le 10 sept. 2018 Ã 15:50, Guillermo Polito <guillermopolito(a)gmail.com> a Ã©crit : > > Ok by me, so tuesday or wednesday? > > On Mon, Sep 10, 2018 at 2:46 PM StÃ©phane Ducasse <stephane.ducasse(a)inria.fr <mailto:stephane.ducasse@inria.fr>> wrote: > Hello > > We would like to have a BOF around Pharo. > Since there are many topics to talk about. > Tuesday after the show us your project? > We can have one at the beach before the social event aroun 17h? > > Stef > -------------------------------------------- > StÃ©phane Ducasse > http://stephane.ducasse.free.fr <http://stephane.ducasse.free.fr/> > http://www.synectique.eu <http://www.synectique.eu/> / http://www.pharo.org <http://www.pharo.org/> > 03 59 35 87 52 > Assistant: Julie Jonas > FAX 03 59 57 78 50 > TEL 03 59 35 86 16 > S. Ducasse - Inria > 40, avenue Halley, > Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza > Villeneuve d'Ascq 59650 > France > > > > -- > > 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

Sept. 11, 2018

Re: [Pharo-dev] Pharo BOF at ESUG

by Guillermo Polito

Ok by me, so tuesday or wednesday? On Mon, Sep 10, 2018 at 2:46 PM StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hello > > We would like to have a BOF around Pharo. > Since there are many topics to talk about. > Tuesday after the show us your project? > We can have one at the beach before the social event aroun 17h? > > Stef > -------------------------------------------- > StÃ©phane Ducasse > http://stephane.ducasse.free.fr > http://www.synectique.eu / http://www.pharo.org > 03 59 35 87 52 > Assistant: Julie Jonas > FAX 03 59 57 78 50 > TEL 03 59 35 86 16 > S. Ducasse - Inria > 40, avenue Halley, > Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza > Villeneuve d'Ascq 59650 > France > > -- 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

Sept. 10, 2018

Pharo BOF at ESUG

by StÃ©phane Ducasse

Hello We would like to have a BOF around Pharo. Since there are many topics to talk about. Tuesday after the show us your project? We can have one at the beach before the social event aroun 17h? Stef -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr http://www.synectique.eu / http://www.pharo.org 03 59 35 87 52 Assistant: Julie Jonas FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

Sept. 10, 2018

Call for Papers: <Programming> 2019

by Fabio Niephaus

<Programming> 2019 : The Art, Science, and Engineering of Programming April 1-4, 2019, Genova, Italy http://2019.programming-conference.org The International Conference on the Art, Science, and Engineering of Programming is a new conference focused on programming topics including the experience of programming. We have named it <Programming> for short. <Programming> seeks for papers that advance knowledge of programming on any relevant topic, including programming practice and experience. Paper submissions and publications are handled by the the Art, Science, and Engineering of Programming journal (http://programming-journal.org) Accepted papers must be presented at the conference. ******************************************************** CALL FOR PAPERS ******************************************************** <Programming> 2019 accepts scholarly papers that advance knowledge of programming. Almost anything about programming is in scope, but in each case there should be a clear relevance to the act and experience of programming. PAPER SUBMISSIONS: October 1, 2018 URL FOR SUBMISSIONS: http://programming-journal.org/submission/ Submissions covering several areas of expertise are accepted, including but not limited to: â¢ General-purpose programming â¢ Distributed systems programming â¢ Parallel and multi-core programming â¢ Graphics and GPU programming â¢ Security programming â¢ User interface programming â¢ Database programming â¢ Visual and live programming â¢ Data mining and machine learning programming â¢ Interpreters, virtual machines and compilers â¢ Modularity and separation of concerns â¢ Model-based development â¢ Metaprogramming and reflection â¢ Testing and debugging â¢ Program verification â¢ Programming education â¢ Programming environments â¢ Social coding ******************************************************** IMPORTANT DATES ******************************************************** Research paper submissions: October 1, 2018 Research paper first notifications: December 1, 2018 Research paper final notifications: January 7, 2019 ******************************************************** ORGANIZATION ******************************************************** General Chair: Davide Ancona, University of Genova Local Organizing Chair: Elena Zucca, University of Genova Program Chair: Matthew Flatt, University of Utah Organizing Committee: Walter Cazzola (Workshops Co-Chair), UniversitÃ degli Studi di Milano Stefan Marr (Workshops Co-Chair), University of Kent Fabio Niephaus (Publicity Co-Chair), Hasso Plattner Institute, University of Potsdam Guido Salvaneschi (Publicity Co-Chair), Darmstadt University of Technology Tobias Pape (Web Technology Chair), Hasso Plattner Institute, University of Potsdam Program Committee: Anya Helene Bagge, University of Bergen Mehdi Bagherzadeh, Oakland University Walter Cazzola, UniversitÃ degli Studi di Milano Ravi Chugh, University of Chicago Joeri De Koster, Vrije Universiteit Brussel Christos Dimoulas, Northwestern University Susan Eisenbach, Imperial College London Richard P. Gabriel, Dream Songs, Inc. & HPI Jeremy Gibbons, University of Oxford Michael Greenberg, Pomona College Philipp Haller, KTH Royal Institute of Technology Robert Hirschfeld, HPI, University of Potsdam Eunsuk Kang, Carnegie Mellon University Stephen Kell, University of Cambridge Stefan Marr, University of Kent Tamara Rezk, Inria Joshua Sunshine, Carnegie Mellon University Steffen Zschaler, King's College London ******************************************************** <Programming> 2019 is kindly supported by AOSA ******************************************************** For more information, visit http://2019.programming-conference.org

Sept. 10, 2018

Re: [Pharo-dev] Iceberg goodness plus ideas

by Guillermo Polito

On Mon, Sep 10, 2018 at 5:46 AM Ben Coman <btc(a)openinworld.com> wrote: > > > On Mon, 10 Sep 2018 at 03:40, Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > >> Hi Ben, >> >> I'm really interested on improving on this. Please read below :) >> >> On Sun, Sep 9, 2018 at 5:07 PM Ben Coman <btc(a)openinworld.com> wrote: >> >>> First, kudos to Iceberg team for detecting the mistake I made messing >>> around at the command line under the feet of an Iceberg managed repo. >>> I'm interested in some general discussion of a few ideas before logging >>> any issues. >>> >>> I had an Iceberg managed repo branch "ready-multiple-commands" >>> as shown at [A] in the attached pic. >>> (note that this is "exercism/pharo" not "pharo-project/pharo") >>> >>> I wanted to compare "git log --graph" between a few branches >>> so I jumped into a command prompt and did so. Along the way I changed >>> branch to "master" from the command line [B]. >>> Then friends arrived and it was six hours until I got back to it >>> and was presented with "Detached Working Copy" [C], >>> and I'd forgotten what I'd done. >>> >>> Repair repository [D] didn't make this immediately obvious >>> although given the two commits after a while I managed to work it out >>> and simply `git checkout ready-multiple-commands` at the command line >>> fixed things, returning the display to [A]. >>> >>> So the discussion points I'm interested in are: >>> >>> a. An extra column "Image Branch" with the existing column >>> renamed "Disk Branch" would have made my mistake immediately obvious. >>> >> >> Yes, this could be easily done. We can have a new version with that soon >> to try it out and see if this improves the situation. >> This change would have no significant side effect, and rolling back is >> cheap. >> So I'd like to experiment with this kind of simple UI issues, that may >> improve the overall understanding. >> > > Thinking further, this could independently indicate whether the Image > Working Copy or the Disk Working Copy are dirty. > Yes, we could > >> >>> >>> b. Such under the covers command line operation may be a corner >>> case(??), >>> so if not an extra column, a red Status message "Image Branch >>> ready-multiple-commands" or similar would have helped. >>> >>> Well, it is not necessarily a corner case, because this will happen for >> people maintaining external files... At least with current implementation. >> We are thinking on adding support for external files, but that will not >> arrive soon. >> > > From seeing external files in the diff I had guessed this was already done. > In attached pic /dev/src is the Pharo project folder and changes in > /docs/ABOUT.md can be seen. > That in itself is very cool. btw, I love the way remotes show up on this > screen. > Well, we HAD to prematurely manage external files for merge, because otherwise a merge could produce lost of changes. Imagine that you merge only smalltalk code (the previous solution in iceberg < 0.7), then that means that your current branch will not adopt any changes done in external files from the merged commit. Then, the fact that we show files during checkout is merely "accidental". We had the support for files in the changes tree, so this was just super easy to do :P. However, we don't have yet support for committing arbitrary files changed in the disk. At commit time, Iceberg only cares about what is checked out *in the image*. So this is the missing support. Implementing this would mean to produce a changes tree that mixes - the code in the image - the non-code files in the disk And this could create a new point of conflict (not a git conflict per-se because this is a non-git / iceberg-specific scenario). So we should decide here what to do when the code files in disk are dirty too. > > One experiment I'd like to try, even though it may clutter the screen a > bit more, is on each branch in the left pane > add the commit ID in brackets. I think this would reinforce that git > branches are merely pointers at a commit > which I read is one of the greatest paradigm adjustments for people coming > from other versioning systems. > Having different hashes are attached to local/master, > remote/origin/master, remote/ben/master > would reinforce the distinction between them. > btw, Since all the items in the pane are branches/tags, consider renaming > "Branches" to "Local Branches" > or just "Local", or "Local repository" plus "Remotes" to "Remote > repositories". > You mean in the checkout/branch window? Ah, reading below I see you're talking about the "Repository" window. > > I see here you show two tabs with fixed diffs: > * Blue selection to HEAD, and; > * Blue selection to previous > Now asking for the moon, what I'd like to try is a second selection in > another colour (e.g. purple), > that perhaps you move holding the ALT key, that would select any two > commits to diff. > And also experiment with showing that second selection as either: > * holding down the ALT key to toggle the existing commit list in place to > show the purple selection > * since many of us have wide screen, have a second commit list to the > right of the existing commit list > * have a second commit list below the existing commit list > * flexibility of user changing between those three > > Well, the backend support for that is done. It's the UI support missing only. If you want to play with it, you can: 1. Right click on a commit -> inspect 2. In the inspector type: self diffTo: (self repository lookupCommit: 'somecommithash') And you'll have the tree object. I've opened a feature request: https://github.com/pharo-vcs/iceberg/issues/994 > > >> Also, the "Detached working copy" is also a bit more complicated than >> checking out a different branch :). >> I'll do some writeup here so people can better understand the motivations >> behind the current implementation. >> I'll try to be clear, but this is much easier to talk about this issues >> around a blackboard... I can try to do some drawings next time ^^. >> >> So far we decided that Iceberg will not let you work unless you image's >> working copy is aligned with the repository's working copy/HEAD. >> This provokes this kind of situations when touching the repository from >> outside the image, but we think it is simpler to understand. >> > > Definitely a good first approach. But as we become familiar with git > interaction with Images it may open up ideas. > > >> >> An alternative solution could be to let the image and the disk diverge >> (like implementing in the image some kind of virtual branch). But this >> could be confusing also. Because this could lead to scenarios where you >> touch your disk working copy and the image does not "care" them? >> > > I guess the concern is not so much changing disk-working-branch out of > synch with the image-working-branch, > but that changing image-working-branch modifies the disk-working-branch > and interacting any external changes there is awkward. > Perhaps you can use a stash-like mechanism to place aside the dirty > disk-working. > Well, yes, but un-stashing may create conflicts because the dirty changes may touch files you're committing too :). As a simplification, you can see stashing just as creating a temporary branch and un-stashing as a merge (that does not imply a commit merge)... > > Now I wonder if rather than indicating the current branch with the > conventional emphasis > shown in the pic on "master", perhaps above "Branches" add two entries > that could independently indicate a separate branch. > e.g... > * "Image Working Copy(master)" > * "Disk Working Copy(master)" > Yes, I agree this may be confusing https://github.com/pharo-vcs/iceberg/issues/995 > The latter could have an extra entry at the top of the commit list that > showed "working(disk)" in place of a hash if its dirty, > and the former might have two extra entries "working(disk)" and above it > "working(image)". > You'd have to suck it to see but this might help promote the paradigm that > the Image-Working-Copy > needs to merge into the Disk-Working-Copy before committing into the Local > Repository. > which could be selected for a diff comparison. What you would get is an > Image-Working-Copy > to Disk-Working-Copy comparison within a consistent framework of getting > diffs between any commit. > > > And while the ideas are flowing, in the commit list, where a commit hash > aligns with any branch (local or remote) > mark that hash somehow to encourage a user hover over it for a popup to > show the aligned branch. > We have kind of bubbles in the list already to show tags, we could use them to show branches too, yes [image: image.png] Still, we may have to work on their "beauty" :) https://github.com/pharo-vcs/iceberg/issues/996 > > >> >> Also, take into account that every point of divergence in history will >> lead to new merge points, and this will increase the possibilities of >> conflicts. >> > > Maybe not if we manage this divergence "locally" in a stash-like manner. I > don't know much about it, > but the comment "stashes are not a separate branch...they live in their > own namespace refs/stash" [1] > makes me think its possible to have a namespace refs/iceberg to track > temporary commits sidelining disk-working, > to allow the Image to change branches around dirty disk-branch. Or just > use "refs/stash" if its compatible. > [1] > https://stackoverflow.com/questions/18527171/how-does-stashing-work-in-git-… > > IIUC, the stashes are still commits, but just no risk of ending up in repo > history. > Check the documentation of pop in https://www.git-scm.com/docs/git-stash In practice, it does not really matter too much to me if there is a commit or not, and if visible or not. The problem are conflicts, which should be manually resolved by users and add a lot of cognitive load... > > >> So, we could have: >> >> Image [commit X] - Disk working copy [commit Y] - Remote repository >> [commit Z] >> >> Imagine that we have a more complex (but flexible?) implementation that >> allows you to work in this scenario. >> Then you choose to pull from the image. >> - Merging Z with Y could lead to conflicts >> - Merging Y with X too. >> - And merging Z with X too. >> >> So that would lead to a super mess that would be hyper complicated for >> average users :) >> We have thought about this complex scenarios and we decided we wanted to >> avoid them, because already bare-git is complicated in itself... >> >> Actually, we have been really picky in our merge design and Iceberg only >> lets you merge 2 commits at a time (even if there are three commits in play >> when you pull: image, git HEAD and the pulled commit ;)). >> >> >>> c. In the first paragraph of [D] it was not apparent what "working copy" >>> and "repository commit" referred to (although after a while I worked it out >>> from the given commit hashes -- the former was in-Image and the latter >>> on-disk. But the files on disk are a "working copy" in all other git >>> documentation and it invites confusion not to refer to it like that. It >>> seems to me we deal with two working copies: an "image working copy" and a >>> "disk working copy". That terminology would have eased discovery of my >>> mistake. >>> >> >> There are effectively two working copies, yes :) I'll try to propose a >> new text for the repair action explanations soon enough. I'll ping you so >> you can do a double check on it ^^. >> >> >>> >>> d. Instead of the commit hashes [D], is it feasible to match those to >>> branches/tags and display those. That would have made my mistake more >>> obvious. >>> >> >> Not quite. Iceberg's working copy remembers the commit from where the >> code was loaded, not the branch. >> And the branch can move, so it's not necessarily a good source of that >> information. >> >> What I mean by this is that you will have also a "detached working copy" >> even if you're in the same branch, but on a different commit. >> >> Imagine you go to the command line, edit some tonel file by hand and >> commit. >> Iceberg will detect the change and tell you you're detached. >> > > I just tested this and it didn't seem to work. > Opened Iceberg, for myRepo checked out "master" ==> "Up to date" > Browsed with Windows Explorer to a SomeClass.st file and made an edit to > a method. > Opened new Iceberg, myRepo shows "master" ==> "up to date" > YES, Iceberg will not detect that your disk working copy is dirty. This is related with what I was saying above on commiting non-code files and merging code files in disk... BUT, if you commit your changes from the command line, you'll have a detached working copy. > > btw, "Detached" is a term for when you have a commit-hash checked > out rather than a branch. > I think it risks confusion to reuse that term for a difference between two > working copies. > Perhaps "Diverged disk working copy" or similar would be appropriate. > Well, Detached Working copy means that the *commit* checked out in the image is effectively different than the commit in the repo's HEAD. It has nothing to do with branches. Actually changing the branch from behind produces a detached working copy because changing a branch means changing the current commit too :). > > >> >> >>> >>> d. In [D], its not clear the difference between: >>> "Discard local changes" >>> "Discard image changes" >>> >> >> I think they mean the same, we should review these texts. >> Also, consider that one of those repair actions (checkout what is in >> disk) is just a subset of the other one (checkout an existing branch). >> I was thinking if having both is really worth it or not... >> >> Keep pushing, I like your feedback, and if you're not satisfied with any >> of my answers just go on ^^. >> > > Will do, thanks for the encouragement. > I'm really enjoying using Iceberg now**, bouncing between branches and > social interaction on github. > There was obviously some teething pain along the way, but I think the > effort has borne good fruit > and is a great part of our path to the future. Onward and upward... > > cheers -ben > > **Pharo 6.1 standalone with updated iceberg ( > https://github.com/pharo-vcs/iceberg#update-iceberg) > -- 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

Sept. 10, 2018

Esteban's ChangeLog week of 3 September 2018

by estebanlm＠gmail.com

Hello! This is my weekly ChangeLog, from 3 September 2018 to 9 September 2018. You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=3/9/2018&to=9/9/2018 ChangeLog ========= 4 September 2018: ----------------- * While I'm back from my holidays, this week will be slow and full of admin work. Nothing very relevant to inform :) Also, I'm preparing my presentation for ESUG :) cheers! Esteban

Sept. 10, 2018

Re: [Pharo-dev] Iceberg goodness plus ideas

by Ben Coman

On Mon, 10 Sep 2018 at 03:40, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Hi Ben, > > I'm really interested on improving on this. Please read below :) > > On Sun, Sep 9, 2018 at 5:07 PM Ben Coman <btc(a)openinworld.com> wrote: > >> First, kudos to Iceberg team for detecting the mistake I made messing >> around at the command line under the feet of an Iceberg managed repo. >> I'm interested in some general discussion of a few ideas before logging >> any issues. >> >> I had an Iceberg managed repo branch "ready-multiple-commands" >> as shown at [A] in the attached pic. >> (note that this is "exercism/pharo" not "pharo-project/pharo") >> >> I wanted to compare "git log --graph" between a few branches >> so I jumped into a command prompt and did so. Along the way I changed >> branch to "master" from the command line [B]. >> Then friends arrived and it was six hours until I got back to it >> and was presented with "Detached Working Copy" [C], >> and I'd forgotten what I'd done. >> >> Repair repository [D] didn't make this immediately obvious >> although given the two commits after a while I managed to work it out >> and simply `git checkout ready-multiple-commands` at the command line >> fixed things, returning the display to [A]. >> >> So the discussion points I'm interested in are: >> >> a. An extra column "Image Branch" with the existing column >> renamed "Disk Branch" would have made my mistake immediately obvious. >> > > Yes, this could be easily done. We can have a new version with that soon > to try it out and see if this improves the situation. > This change would have no significant side effect, and rolling back is > cheap. > So I'd like to experiment with this kind of simple UI issues, that may > improve the overall understanding. > Thinking further, this could independently indicate whether the Image Working Copy or the Disk Working Copy are dirty. > > >> >> b. Such under the covers command line operation may be a corner case(??), >> so if not an extra column, a red Status message "Image Branch >> ready-multiple-commands" or similar would have helped. >> >> Well, it is not necessarily a corner case, because this will happen for > people maintaining external files... At least with current implementation. > We are thinking on adding support for external files, but that will not > arrive soon. > >From seeing external files in the diff I had guessed this was already done. In attached pic /dev/src is the Pharo project folder and changes in /docs/ABOUT.md can be seen. That in itself is very cool. btw, I love the way remotes show up on this screen. One experiment I'd like to try, even though it may clutter the screen a bit more, is on each branch in the left pane add the commit ID in brackets. I think this would reinforce that git branches are merely pointers at a commit which I read is one of the greatest paradigm adjustments for people coming from other versioning systems. Having different hashes are attached to local/master, remote/origin/master, remote/ben/master would reinforce the distinction between them. btw, Since all the items in the pane are branches/tags, consider renaming "Branches" to "Local Branches" or just "Local", or "Local repository" plus "Remotes" to "Remote repositories". I see here you show two tabs with fixed diffs: * Blue selection to HEAD, and; * Blue selection to previous Now asking for the moon, what I'd like to try is a second selection in another colour (e.g. purple), that perhaps you move holding the ALT key, that would select any two commits to diff. And also experiment with showing that second selection as either: * holding down the ALT key to toggle the existing commit list in place to show the purple selection * since many of us have wide screen, have a second commit list to the right of the existing commit list * have a second commit list below the existing commit list * flexibility of user changing between those three > Also, the "Detached working copy" is also a bit more complicated than > checking out a different branch :). > I'll do some writeup here so people can better understand the motivations > behind the current implementation. > I'll try to be clear, but this is much easier to talk about this issues > around a blackboard... I can try to do some drawings next time ^^. > > So far we decided that Iceberg will not let you work unless you image's > working copy is aligned with the repository's working copy/HEAD. > This provokes this kind of situations when touching the repository from > outside the image, but we think it is simpler to understand. > Definitely a good first approach. But as we become familiar with git interaction with Images it may open up ideas. > > An alternative solution could be to let the image and the disk diverge > (like implementing in the image some kind of virtual branch). But this > could be confusing also. Because this could lead to scenarios where you > touch your disk working copy and the image does not "care" them? > I guess the concern is not so much changing disk-working-branch out of synch with the image-working-branch, but that changing image-working-branch modifies the disk-working-branch and interacting any external changes there is awkward. Perhaps you can use a stash-like mechanism to place aside the dirty disk-working. Now I wonder if rather than indicating the current branch with the conventional emphasis shown in the pic on "master", perhaps above "Branches" add two entries that could independently indicate a separate branch. e.g... * "Image Working Copy(master)" * "Disk Working Copy(master)" The latter could have an extra entry at the top of the commit list that showed "working(disk)" in place of a hash if its dirty, and the former might have two extra entries "working(disk)" and above it "working(image)". You'd have to suck it to see but this might help promote the paradigm that the Image-Working-Copy needs to merge into the Disk-Working-Copy before committing into the Local Repository. which could be selected for a diff comparison. What you would get is an Image-Working-Copy to Disk-Working-Copy comparison within a consistent framework of getting diffs between any commit. And while the ideas are flowing, in the commit list, where a commit hash aligns with any branch (local or remote) mark that hash somehow to encourage a user hover over it for a popup to show the aligned branch. > > Also, take into account that every point of divergence in history will > lead to new merge points, and this will increase the possibilities of > conflicts. > Maybe not if we manage this divergence "locally" in a stash-like manner. I don't know much about it, but the comment "stashes are not a separate branch...they live in their own namespace refs/stash" [1] makes me think its possible to have a namespace refs/iceberg to track temporary commits sidelining disk-working, to allow the Image to change branches around dirty disk-branch. Or just use "refs/stash" if its compatible. [1] https://stackoverflow.com/questions/18527171/how-does-stashing-work-in-git-… IIUC, the stashes are still commits, but just no risk of ending up in repo history. > So, we could have: > > Image [commit X] - Disk working copy [commit Y] - Remote repository > [commit Z] > > Imagine that we have a more complex (but flexible?) implementation that > allows you to work in this scenario. > Then you choose to pull from the image. > - Merging Z with Y could lead to conflicts > - Merging Y with X too. > - And merging Z with X too. > > So that would lead to a super mess that would be hyper complicated for > average users :) > We have thought about this complex scenarios and we decided we wanted to > avoid them, because already bare-git is complicated in itself... > > Actually, we have been really picky in our merge design and Iceberg only > lets you merge 2 commits at a time (even if there are three commits in play > when you pull: image, git HEAD and the pulled commit ;)). > > >> c. In the first paragraph of [D] it was not apparent what "working copy" >> and "repository commit" referred to (although after a while I worked it out >> from the given commit hashes -- the former was in-Image and the latter >> on-disk. But the files on disk are a "working copy" in all other git >> documentation and it invites confusion not to refer to it like that. It >> seems to me we deal with two working copies: an "image working copy" and a >> "disk working copy". That terminology would have eased discovery of my >> mistake. >> > > There are effectively two working copies, yes :) I'll try to propose a new > text for the repair action explanations soon enough. I'll ping you so you > can do a double check on it ^^. > > >> >> d. Instead of the commit hashes [D], is it feasible to match those to >> branches/tags and display those. That would have made my mistake more >> obvious. >> > > Not quite. Iceberg's working copy remembers the commit from where the code > was loaded, not the branch. > And the branch can move, so it's not necessarily a good source of that > information. > > What I mean by this is that you will have also a "detached working copy" > even if you're in the same branch, but on a different commit. > > Imagine you go to the command line, edit some tonel file by hand and > commit. > Iceberg will detect the change and tell you you're detached. > I just tested this and it didn't seem to work. Opened Iceberg, for myRepo checked out "master" ==> "Up to date" Browsed with Windows Explorer to a SomeClass.st file and made an edit to a method. Opened new Iceberg, myRepo shows "master" ==> "up to date" btw, "Detached" is a term for when you have a commit-hash checked out rather than a branch. I think it risks confusion to reuse that term for a difference between two working copies. Perhaps "Diverged disk working copy" or similar would be appropriate. > > >> >> d. In [D], its not clear the difference between: >> "Discard local changes" >> "Discard image changes" >> > > I think they mean the same, we should review these texts. > Also, consider that one of those repair actions (checkout what is in disk) > is just a subset of the other one (checkout an existing branch). > I was thinking if having both is really worth it or not... > > Keep pushing, I like your feedback, and if you're not satisfied with any > of my answers just go on ^^. > Will do, thanks for the encouragement. I'm really enjoying using Iceberg now**, bouncing between branches and social interaction on github. There was obviously some teething pain along the way, but I think the effort has borne good fruit and is a great part of our path to the future. Onward and upward... cheers -ben **Pharo 6.1 standalone with updated iceberg ( https://github.com/pharo-vcs/iceberg#update-iceberg)

Sept. 10, 2018

Re: [Pharo-dev] Iceberg goodness plus ideas

by Guillermo Polito

Hi Ben, I'm really interested on improving on this. Please read below :) On Sun, Sep 9, 2018 at 5:07 PM Ben Coman <btc(a)openinworld.com> wrote: > First, kudos to Iceberg team for detecting the mistake I made messing > around at the command line under the feet of an Iceberg managed repo. > I'm interested in some general discussion of a few ideas before logging > any issues. > > I had an Iceberg managed repo branch "ready-multiple-commands" > as shown at [A] in the attached pic. > (note that this is "exercism/pharo" not "pharo-project/pharo") > > I wanted to compare "git log --graph" between a few branches > so I jumped into a command prompt and did so. Along the way I changed > branch to "master" from the command line [B]. > Then friends arrived and it was six hours until I got back to it > and was presented with "Detached Working Copy" [C], > and I'd forgotten what I'd done. > > Repair repository [D] didn't make this immediately obvious > although given the two commits after a while I managed to work it out > and simply `git checkout ready-multiple-commands` at the command line > fixed things, returning the display to [A]. > > So the discussion points I'm interested in are: > > a. An extra column "Image Branch" with the existing column > renamed "Disk Branch" would have made my mistake immediately obvious. > Yes, this could be easily done. We can have a new version with that soon to try it out and see if this improves the situation. This change would have no significant side effect, and rolling back is cheap. So I'd like to experiment with this kind of simple UI issues, that may improve the overall understanding. > > b. Such under the covers command line operation may be a corner case(??), > so if not an extra column, a red Status message "Image Branch > ready-multiple-commands" or similar would have helped. > > Well, it is not necessarily a corner case, because this will happen for people maintaining external files... At least with current implementation. We are thinking on adding support for external files, but that will not arrive soon. Also, the "Detached working copy" is also a bit more complicated than checking out a different branch :). I'll do some writeup here so people can better understand the motivations behind the current implementation. I'll try to be clear, but this is much easier to talk about this issues around a blackboard... I can try to do some drawings next time ^^. So far we decided that Iceberg will not let you work unless you image's working copy is aligned with the repository's working copy/HEAD. This provokes this kind of situations when touching the repository from outside the image, but we think it is simpler to understand. An alternative solution could be to let the image and the disk diverge (like implementing in the image some kind of virtual branch). But this could be confusing also. Because this could lead to scenarios where you touch your disk working copy and the image does not "care" them? Also, take into account that every point of divergence in history will lead to new merge points, and this will increase the possibilities of conflicts. So, we could have: Image [commit X] - Disk working copy [commit Y] - Remote repository [commit Z] Imagine that we have a more complex (but flexible?) implementation that allows you to work in this scenario. Then you choose to pull from the image. - Merging Z with Y could lead to conflicts - Merging Y with X too. - And merging Z with X too. So that would lead to a super mess that would be hyper complicated for average users :) We have thought about this complex scenarios and we decided we wanted to avoid them, because already bare-git is complicated in itself... Actually, we have been really picky in our merge design and Iceberg only lets you merge 2 commits at a time (even if there are three commits in play when you pull: image, git HEAD and the pulled commit ;)). > c. In the first paragraph of [D] it was not apparent what "working copy" > and "repository commit" referred to (although after a while I worked it out > from the given commit hashes -- the former was in-Image and the latter > on-disk. But the files on disk are a "working copy" in all other git > documentation and it invites confusion not to refer to it like that. It > seems to me we deal with two working copies: an "image working copy" and a > "disk working copy". That terminology would have eased discovery of my > mistake. > There are effectively two working copies, yes :) I'll try to propose a new text for the repair action explanations soon enough. I'll ping you so you can do a double check on it ^^. > > d. Instead of the commit hashes [D], is it feasible to match those to > branches/tags and display those. That would have made my mistake more > obvious. > Not quite. Iceberg's working copy remembers the commit from where the code was loaded, not the branch. And the branch can move, so it's not necessarily a good source of that information. What I mean by this is that you will have also a "detached working copy" even if you're in the same branch, but on a different commit. Imagine you go to the command line, edit some tonel file by hand and commit. Iceberg will detect the change and tell you you're detached. > > d. In [D], its not clear the difference between: > "Discard local changes" > "Discard image changes" > I think they mean the same, we should review these texts. Also, consider that one of those repair actions (checkout what is in disk) is just a subset of the other one (checkout an existing branch). I was thinking if having both is really worth it or not... Keep pushing, I like your feedback, and if you're not satisfied with any of my answers just go on ^^. > > cheers -ben > -- 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

Sept. 9, 2018

Re: [Pharo-dev] Iceberg goodness plus ideas

by Ben Coman

On Sun, 9 Sep 2018 at 23:06, Ben Coman <btc(a)openinworld.com> wrote: > d. In [D], its not clear the difference between: > "Discard local changes" > "Discard image changes" > Sorry, disregard [d.]. I missed that I could click on these to get a description. cheers -ben

Sept. 9, 2018

Re: [Pharo-dev] Iceberg goodness plus ideas

by Ben Coman

I found a related issue https://github.com/pharo-vcs/iceberg/issues/762 and attached there the pic I left off the previous post. cheers -ben On Sun, 9 Sep 2018 at 23:06, Ben Coman <btc(a)openinworld.com> wrote: > First, kudos to Iceberg team for detecting the mistake I made messing > around at the command line under the feet of an Iceberg managed repo. > I'm interested in some general discussion of a few ideas before logging > any issues. > > I had an Iceberg managed repo branch "ready-multiple-commands" > as shown at [A] in the attached pic. > (note that this is "exercism/pharo" not "pharo-project/pharo") > > I wanted to compare "git log --graph" between a few branches > so I jumped into a command prompt and did so. Along the way I changed > branch to "master" from the command line [B]. > Then friends arrived and it was six hours until I got back to it > and was presented with "Detached Working Copy" [C], > and I'd forgotten what I'd done. > > Repair repository [D] didn't make this immediately obvious > although given the two commits after a while I managed to work it out > and simply `git checkout ready-multiple-commands` at the command line > fixed things, returning the display to [A]. > > So the discussion points I'm interested in are: > > a. An extra column "Image Branch" with the existing column > renamed "Disk Branch" would have made my mistake immediately obvious. > > b. Such under the covers command line operation may be a corner case(??), > so if not an extra column, a red Status message "Image Branch > ready-multiple-commands" or similar would have helped. > > c. In the first paragraph of [D] it was not apparent what "working copy" > and "repository commit" referred to (although after a while I worked it out > from the given commit hashes -- the former was in-Image and the latter > on-disk. But the files on disk are a "working copy" in all other git > documentation and it invites confusion not to refer to it like that. It > seems to me we deal with two working copies: an "image working copy" and a > "disk working copy". That terminology would have eased discovery of my > mistake. > > d. Instead of the commit hashes [D], is it feasible to match those to > branches/tags and display those. That would have made my mistake more > obvious. > > d. In [D], its not clear the difference between: > "Discard local changes" > "Discard image changes" > > cheers -ben >

Sept. 9, 2018

Iceberg goodness plus ideas

by Ben Coman

First, kudos to Iceberg team for detecting the mistake I made messing around at the command line under the feet of an Iceberg managed repo. I'm interested in some general discussion of a few ideas before logging any issues. I had an Iceberg managed repo branch "ready-multiple-commands" as shown at [A] in the attached pic. (note that this is "exercism/pharo" not "pharo-project/pharo") I wanted to compare "git log --graph" between a few branches so I jumped into a command prompt and did so. Along the way I changed branch to "master" from the command line [B]. Then friends arrived and it was six hours until I got back to it and was presented with "Detached Working Copy" [C], and I'd forgotten what I'd done. Repair repository [D] didn't make this immediately obvious although given the two commits after a while I managed to work it out and simply `git checkout ready-multiple-commands` at the command line fixed things, returning the display to [A]. So the discussion points I'm interested in are: a. An extra column "Image Branch" with the existing column renamed "Disk Branch" would have made my mistake immediately obvious. b. Such under the covers command line operation may be a corner case(??), so if not an extra column, a red Status message "Image Branch ready-multiple-commands" or similar would have helped. c. In the first paragraph of [D] it was not apparent what "working copy" and "repository commit" referred to (although after a while I worked it out from the given commit hashes -- the former was in-Image and the latter on-disk. But the files on disk are a "working copy" in all other git documentation and it invites confusion not to refer to it like that. It seems to me we deal with two working copies: an "image working copy" and a "disk working copy". That terminology would have eased discovery of my mistake. d. Instead of the commit hashes [D], is it feasible to match those to branches/tags and display those. That would have made my mistake more obvious. d. In [D], its not clear the difference between: "Discard local changes" "Discard image changes" cheers -ben

Sept. 9, 2018

Re: [Pharo-dev] Pharo and Docker (some steps)

by Pierce Ng

On Mon, Aug 20, 2018 at 03:10:58PM +0200, Torsten Bergmann wrote: > I recently played with Pharo and Docker and summarized some of my > steps in a small tutorial in my Pharo wiki: Monkey saw, and monkey did. :-) Here's my report on my experimentation: http://www.samadhiweb.com/blog/2018.09.09.docker.html Pierce

Sept. 9, 2018

Added Pharo8 milestone to issue tracker

by Marcus Denker

Hi, As part of getting ready for the release, we should check all issue tracker entries tagged for pharo7 and decide if they are real show stoppers. I added a Pharo8 Milestone (but when removing the pharo7 milestone, it is in most cases better to just put it on âLaterâ). Marcus

Sept. 9, 2018

[Pharo 7.0-dev] Build #1239: 22434 Cleanup FloatTest

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

There is a new Pharo build available! The status of the build #1239 was: SUCCESS. The Pull Request #1783 was integrated: "22434 Cleanup FloatTest" Pull request url: https://github.com/pharo-project/pharo/pull/1783 Issue Url: https://pharo.fogbugz.com/f/cases/22434 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 8, 2018

[Pharo 7.0-dev] Build #1238: 22404-NECSymbolCache-is-not-needed-anymore

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

There is a new Pharo build available! The status of the build #1238 was: SUCCESS. The Pull Request #1769 was integrated: "22404-NECSymbolCache-is-not-needed-anymore" Pull request url: https://github.com/pharo-project/pharo/pull/1769 Issue Url: https://pharo.fogbugz.com/f/cases/22404 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 8, 2018

[Pharo 7.0-dev] Build #1237: 22422 Correctly deprecate Ring- Core-Kernel and Ring Tests Kernel

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

There is a new Pharo build available! The status of the build #1237 was: SUCCESS. The Pull Request #1773 was integrated: "22422 Correctly deprecate Ring- Core-Kernel and Ring Tests Kernel" Pull request url: https://github.com/pharo-project/pharo/pull/1773 Issue Url: https://pharo.fogbugz.com/f/cases/22422 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 7, 2018

Re: [Pharo-dev] [Pharo-users] [Moose-dev] Pharo eye-candy: Domain-Specific Modeling and Simulation

by Nick Papoylias

Thanx Alex :) Looking forward to the Roassal talk on Thursday ! On Fri, Sep 7, 2018 at 5:22 PM Alexandre Bergel via Pharo-users < pharo-users(a)lists.pharo.org> wrote: > Wow!!!!! > You guys rock! > > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > On Sep 6, 2018, at 2:17 PM, Nick Papoylias <npapoylias(a)gmail.com> wrote: > > A nice example of how Pharo can be used for > domain-specific modeling and simulation. Short > session from one of our projects at Rochelle: > > https://www.youtube.com/watch?v=Z7wJNhAIaVQ > > Some additional info here: https://goo.gl/jS4NjB > > Currently investigating how to incorporate the new Bloc based > widgets of @feenkcom into the workflow. > > Cheers, > > Nick > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev > > >

Sept. 7, 2018

Re: [Pharo-dev] Release test for unused temps and other

by Torsten Bergmann

Thank you all for your feedback - so let's do it with a TestCase added into the image. PR is available, according CI is green and ready for review/integration: https://github.com/pharo-project/pharo/pull/1782 Â

Sept. 7, 2018

Re: [Moose-dev] Pharo eye-candy: Domain-Specific Modeling and Simulation

by Alexandre Bergel

Wow!!!!! You guys rock! Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > On Sep 6, 2018, at 2:17 PM, Nick Papoylias <npapoylias(a)gmail.com> wrote: > > A nice example of how Pharo can be used for > domain-specific modeling and simulation. Short > session from one of our projects at Rochelle: > > https://www.youtube.com/watch?v=Z7wJNhAIaVQ <https://www.youtube.com/watch?v=Z7wJNhAIaVQ> > > Some additional info here: https://goo.gl/jS4NjB <https://goo.gl/jS4NjB> > > Currently investigating how to incorporate the new Bloc based > widgets of @feenkcom into the workflow. > > Cheers, > > Nick > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev

Sept. 7, 2018

Re: [Pharo-dev] Iceberg > review pull request & repo name clash

by Guillermo Polito

Hi Ben, The github integration has sure problems, since we were not actively working on it. So I really think it needs some love. Please go ahead an open as many issues (or PRs) as you want ^^. On Fri, Sep 7, 2018 at 4:54 AM Ben Coman <btc(a)openinworld.com> wrote: > Two concerns from one flow of events... > > I was trying out "review a pull request" feature for the first time. This > looks very promising, but I got stuck. > > In Pharo 6.1... > Downloaded http://files.pharo.org/platform/Pharo6.1-win.zip > Updated Icerberg per https://github.com/pharo-vcs/iceberg#update-iceberg > Iceberg > > Settings > Use custom keys = Enabled > > Add > Clone remote repository > Remote URL = git@github.com:exercism/pharo.git > ==> "pharo" repo appears, status "Not loaded" > > "pharo" repo > Packages ==> BaselineOfExercism, Exercism, etc > > > > "pharo" repo > Github > View pull request > origin > enter github > account password > ==> shows PR#98 "Move setup to class initialization..." > > right-click 98 > Review pull request > ==> an empty window titled "Browsing pull request: #98...." appeared > (see attached) > Trying the same in Pharo 7 gave a different problem... > From Launcher started > Pharo-7.0.0-alpha.build.1231.sha.cf8aa48.arch.32bit... > Iceberg > > Settings > Use custom keys = Enabled > > "pharo" repo > Forget Repository > Ticked "Also remove repository from > file system" > > Add > Clone remote repository > Remote URL = git@github.com:exercism/pharo.git > ==> "pharo" appears, status = "Fetch required. Unknown cf8aa48" > > "pharo" repo > Fetch > ==> no change in status, > but I do see the the expected files in repo on disk > > > "pharo" repo > Packages > ==> only shows LICENSE and README.md. > Why did this "just work" in 6.1 ? > It seems the source directory is wrong. > From this point is it possible to update the source directory to > "dev/src/" ? > > Maybe its due to the name clash "pharo-project/pharo" versus > "exercism/pharo" > and something was retained after the "Forget Repository". > Such a name clash is unfortunate, but is a corner case that should be > handled. > This could be a useful test case. > > Before I log an issue, could someone check I'm not doing something wrong. > > cheers -ben > > > P.S. A work around might have been giving a custom local name for the > exercism/pharo repo, > much like you can specify the folder created by command line 'git clone'. > Is such a feature planned for Iceberg? > > > > -- 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

Sept. 7, 2018

[Pharo 7.0-dev] Build #1236: 22424 Correctly deprecate Ring-Deprecated-Tests-Containers and Ring-Dâ¦

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

There is a new Pharo build available! The status of the build #1236 was: SUCCESS. The Pull Request #1775 was integrated: "22424 Correctly deprecate Ring-Deprecated-Tests-Containers and Ring-Dâ¦" Pull request url: https://github.com/pharo-project/pharo/pull/1775 Issue Url: https://pharo.fogbugz.com/f/cases/22424 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 7, 2018

[Pharo 7.0-dev] Build #1235: 22426 Cleanup LzwGifEncoder and GIFReadWriter

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

There is a new Pharo build available! The status of the build #1235 was: SUCCESS. The Pull Request #1777 was integrated: "22426 Cleanup LzwGifEncoder and GIFReadWriter" Pull request url: https://github.com/pharo-project/pharo/pull/1777 Issue Url: https://pharo.fogbugz.com/f/cases/22426 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 7, 2018

Re: [Pharo-dev] [Moose-dev] [cormas-dev] Pharo eye-candy: Domain-Specific Modeling and Simulation

by Stephan Eggermont

Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > Bloc is a new world and the intention is to build a new stack on it. It > can be embedded in Morphic, but not the other way around. Higher level > frameworks, like Spec would have to build a renderer for Bloc. Which of course doesnât stop you from opening a morphic menu on a bloc mouseclick. Here I open a ColorChooser https://vimeo.com/236419682 Stephan

Sept. 7, 2018

[Pharo 7.0-dev] Build #1234: 22420 Cleanup DateAndTimeLeapTest

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

There is a new Pharo build available! The status of the build #1234 was: SUCCESS. The Pull Request #1771 was integrated: "22420 Cleanup DateAndTimeLeapTest" Pull request url: https://github.com/pharo-project/pharo/pull/1771 Issue Url: https://pharo.fogbugz.com/f/cases/22420 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 7, 2018

[Pharo 7.0-dev] Build #1233: 22429-Enable-completion-for-the-selector-of-a-method

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

There is a new Pharo build available! The status of the build #1233 was: SUCCESS. The Pull Request #1779 was integrated: "22429-Enable-completion-for-the-selector-of-a-method" Pull request url: https://github.com/pharo-project/pharo/pull/1779 Issue Url: https://pharo.fogbugz.com/f/cases/22429 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 7, 2018

Re: [Pharo-dev] Bloc consideration - TextActions

by Ben Coman

On Fri, 7 Sep 2018 at 14:52, Ben Coman <btc(a)openinworld.com> wrote: > This is may not be worth investigating much in Morphic, but tips are > welcome. > Mainly this is a use case for consideration with the TextAction equivalent > in Bloc. > > For the #text: of a TextEntryDialogWindow > I wanted clickable link similar to the bottom of ```WelcomeHelp open``` > which would open a link in a web browser using > https://github.com/seandenigris/Pharo-Web-Browser. > > Experimenting in Playground, this[1] looked promising... > ``` > linkText := 'https://exercism.io/my/settings' asText > addAttribute: (TextAction new actOnClickBlock: [ > self inform: 'STUB: Invoke web browser here']); > addAttribute: (TextColor new color: Color cyan). > requestText := 'Enter your Exercism token (from ' asText, linkText, '):'. > requestText inspect. > ``` > where clicking on the link displays the information message. > > But this[2] didn't work... > ```UIManager default request: requestText``` > or to be more explicit, diving in a few calls down and simplifying, > neither did this... > ```(TextEntryDialogWindow new text: requestText) openInWorld``` > > I tracked it down to [2] having a locked TextMorph for requestText. > (observed using the following instrumentation...) > TextMorph isLocked > (text asString includesSubstring: 'Enter your Exercism token') > ifTrue: [ Transcript show: (super isLocked ifTrue: 'x' ifFalse:'.')]. > ^ super isLocked > and confirmed with this experiment... > ``` > tm1 := TextMorph new newContents: requestText. > tm2 := tm1 copy lock. > > tm1 openInWorld. > "Test clicking the text - action is invoked" > tm1 delete. > > tm2 openInWorld. > "Test clicking the text - action not invoked" > tm2 delete. > ``` > > This is due to #isLocked call here...: > ``` > Morph>>rejectsEvent: anEvent > "Return true to reject the given event. > Rejecting an event means neither the receiver nor any of it's submorphs > will be given any chance to handle it. > If the event is a mouse wheel event then only reject if the receiver is > not visible." > (anEvent isMouse and: [anEvent isMouseWheel]) > ifTrue: [^self visible not]. > ^self isLocked or: [self visible not] > ``` > > Now the functional paradox here is that: > * an unlocked TextMorph is editable, which you don't want for a static UI > label; > * but a locked TextMorph doesn't pass events through to trigger the > TextAction. > Thus it you can't have a clickable link in a static UI label. > Yet that is almost an essential feature in today's "linked" world > and I hope Bloc will provide a facility for actions within static/locked > text. > > cheers -ben > > P.S. Any tips on getting this to work in Pharo 6.1 would be appreciated. > Considering... TextMorph >> enabled ^super enabled and: [ self isLocked not ] a reasonable workaround might be... TextMorph subclass: #StaticTextMorph instanceVariableNames: '' classVariableNames: '' package: 'ExercismTools' StaticTextMorph >> enabled ^false then... stm1 := StaticTextMorph new newContents: requestText. stm1 openInWorld allows the link to be clicked while preventing edits. P.S. btw "TextMorph >> enabled:" seems suspect, since its visual only and doesn't prevent editing (if I guess correctly the expected functionality of enabled)

Sept. 7, 2018

[Pharo 7.0-dev] Build #1232: 22410-NECWorkspaceController-is-not-used

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

There is a new Pharo build available! The status of the build #1232 was: FAILURE. The Pull Request #1778 was integrated: "22410-NECWorkspaceController-is-not-used" Pull request url: https://github.com/pharo-project/pharo/pull/1778 Issue Url: https://pharo.fogbugz.com/f/cases/22410 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 7, 2018

Re: [Pharo-dev] Release test for unused temps and other

by Guillermo Polito

Hi, I don't think that 20 seconds will affect the overall process :). It will only become a problem if we increment the number of these kind of tests by *a lot*... Another solution is to make some tests run in parallel. But for this to run properly we have to increase the number of slaves in Jenkins, and the bad news is that we reached the current maximum limit (of 5 slaves). We have to talk to the inria people to see what solution they could provide to us for this, because otherwise the infrastructure does not scale for lots of PRs with big jobs. Guille On Fri, Sep 7, 2018 at 8:23 AM Alistair Grant <akgrant0710(a)gmail.com> wrote: > On Thu, 6 Sep 2018 at 23:06, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com> > wrote: > > > > > > Maybe we could have a package with release tests that are not executed > > by the CI but that are executed at the moment of the feature freeze and > > some time before the Pharo release to ensure the quality of the code > > base for tests that are too long? > > The drawback of this approach is that it relies on the original author > going back and submitting a fix in a timely manner (quite possibly > after they've moved on to other things). > > If the tests could be run on a specified set of classes / methods, > perhaps we could run them as part of Iceberg, i.e. when going to > commit code, these tests are run on the classes in the commit and a > warning opened prompting the user to fix them before actually > committing. > > Cheers, > Alistair > > -- 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

Sept. 7, 2018

Bloc consideration - TextActions

by Ben Coman

This is may not be worth investigating much in Morphic, but tips are welcome. Mainly this is a use case for consideration with the TextAction equivalent in Bloc. For the #text: of a TextEntryDialogWindow I wanted clickable link similar to the bottom of ```WelcomeHelp open``` which would open a link in a web browser using https://github.com/seandenigris/Pharo-Web-Browser. Experimenting in Playground, this[1] looked promising... ``` linkText := 'https://exercism.io/my/settings' asText addAttribute: (TextAction new actOnClickBlock: [ self inform: 'STUB: Invoke web browser here']); addAttribute: (TextColor new color: Color cyan). requestText := 'Enter your Exercism token (from ' asText, linkText, '):'. requestText inspect. ``` where clicking on the link displays the information message. But this[2] didn't work... ```UIManager default request: requestText``` or to be more explicit, diving in a few calls down and simplifying, neither did this... ```(TextEntryDialogWindow new text: requestText) openInWorld``` I tracked it down to [2] having a locked TextMorph for requestText. (observed using the following instrumentation...) TextMorph isLocked (text asString includesSubstring: 'Enter your Exercism token') ifTrue: [ Transcript show: (super isLocked ifTrue: 'x' ifFalse:'.')]. ^ super isLocked and confirmed with this experiment... ``` tm1 := TextMorph new newContents: requestText. tm2 := tm1 copy lock. tm1 openInWorld. "Test clicking the text - action is invoked" tm1 delete. tm2 openInWorld. "Test clicking the text - action not invoked" tm2 delete. ``` This is due to #isLocked call here...: ``` Morph>>rejectsEvent: anEvent "Return true to reject the given event. Rejecting an event means neither the receiver nor any of it's submorphs will be given any chance to handle it. If the event is a mouse wheel event then only reject if the receiver is not visible." (anEvent isMouse and: [anEvent isMouseWheel]) ifTrue: [^self visible not]. ^self isLocked or: [self visible not] ``` Now the functional paradox here is that: * an unlocked TextMorph is editable, which you don't want for a static UI label; * but a locked TextMorph doesn't pass events through to trigger the TextAction. Thus it you can't have a clickable link in a static UI label. Yet that is almost an essential feature in today's "linked" world and I hope Bloc will provide a facility for actions within static/locked text. cheers -ben P.S. Any tips on getting this to work in Pharo 6.1 would be appreciated.

Sept. 7, 2018

Re: [Pharo-dev] Release test for unused temps and other

by Alistair Grant

On Thu, 6 Sep 2018 at 23:06, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com> wrote: > > > Maybe we could have a package with release tests that are not executed > by the CI but that are executed at the moment of the feature freeze and > some time before the Pharo release to ensure the quality of the code > base for tests that are too long? The drawback of this approach is that it relies on the original author going back and submitting a fix in a timely manner (quite possibly after they've moved on to other things). If the tests could be run on a specified set of classes / methods, perhaps we could run them as part of Iceberg, i.e. when going to commit code, these tests are run on the classes in the commit and a warning opened prompting the user to fix them before actually committing. Cheers, Alistair

Sept. 7, 2018

Iceberg > review pull request & repo name clash

by Ben Coman

Two concerns from one flow of events... I was trying out "review a pull request" feature for the first time. This looks very promising, but I got stuck. In Pharo 6.1... Downloaded http://files.pharo.org/platform/Pharo6.1-win.zip Updated Icerberg per https://github.com/pharo-vcs/iceberg#update-iceberg Iceberg > Settings > Use custom keys = Enabled > Add > Clone remote repository Remote URL = git@github.com:exercism/pharo.git ==> "pharo" repo appears, status "Not loaded" > "pharo" repo > Packages ==> BaselineOfExercism, Exercism, etc > "pharo" repo > Github > View pull request > origin > enter github account password ==> shows PR#98 "Move setup to class initialization..." > right-click 98 > Review pull request ==> an empty window titled "Browsing pull request: #98...." appeared (see attached) Trying the same in Pharo 7 gave a different problem... >From Launcher started Pharo-7.0.0-alpha.build.1231.sha.cf8aa48.arch.32bit... Iceberg > Settings > Use custom keys = Enabled > "pharo" repo > Forget Repository > Ticked "Also remove repository from file system" > Add > Clone remote repository Remote URL = git@github.com:exercism/pharo.git ==> "pharo" appears, status = "Fetch required. Unknown cf8aa48" > "pharo" repo > Fetch ==> no change in status, but I do see the the expected files in repo on disk > "pharo" repo > Packages ==> only shows LICENSE and README.md. Why did this "just work" in 6.1 ? It seems the source directory is wrong. From this point is it possible to update the source directory to "dev/src/" ? Maybe its due to the name clash "pharo-project/pharo" versus "exercism/pharo" and something was retained after the "Forget Repository". Such a name clash is unfortunate, but is a corner case that should be handled. This could be a useful test case. Before I log an issue, could someone check I'm not doing something wrong. cheers -ben P.S. A work around might have been giving a custom local name for the exercism/pharo repo, much like you can specify the folder created by command line 'git clone'. Is such a feature planned for Iceberg?

Sept. 7, 2018

Re: [Pharo-dev] Release test for unused temps and other

by Gabriel Cotelli

In my experience this is not a good idea. When you're in the pressure of the release the last thing you want it's to fix things that shouldn't be merged in that form. It sends the wrong message to the people contributing, If you have this fail in your own PR you can easily fix it and learn for it for the next time. But at the time Pharo enter feature freeze probably is someone else who has to fix it. Maintaining code quality is way easier if you keep it in good shape everyday. > Hi, > > Maybe we could have a package with release tests that are not executed > by the CI but that are executed at the moment of the feature freeze and > some time before the Pharo release to ensure the quality of the code > base for tests that are too long? > > > Thanks > > T. > > > > > > > > > > > -- > Cyril Ferlicot > https://ferlicot.fr > >

Sept. 6, 2018

Re: [Pharo-dev] Release test for unused temps and other

by Cyril Ferlicot D.

Le 06/09/2018 Ã 17:50, Torsten Bergmann a Ã©critÂ : > Hi, > > the very nice contribution on GIFReadWriter/animated images (see https://pharo.manuscript.com/f/cases/22137) > unfortunately introduced some methods that had no sender, were uncategorized and had unused temporary variables, etc. > > Something that is meanwhile shown by our tools and easy to fix. I guess it was some overseen leftover. Unfortunately this > also slipped through the integration process as it was merged without an approval from a community reviewer. > > I dont want to lament too much on this specifc case (especially as I now fixed it in https://pharo.fogbugz.com/f/cases/22426) > > But after I cleaned the P7 image this spring to not have unused temporaries anymore I was suprised to find such > glitches again now. So to me it shows that we need to write more tests to detect violations and keep our achieved quality standards > up and also should not solely rely on the review process. > > Otherwise we need to invest our time in cleaning up our own stuff afterwards again and again. > > To be specific one can evaluate: > > CompiledMethod allInstances select: [:m | m ast temporaries anySatisfy: [:x | x binding isUnused ]]. > > to find unused temps - which would be easy to package up into one of the release test to ensure no unused temp vars are left > (the tearDown would require an "ASTCache reset"). > > The problem is that this simple test would take around 20-30 seconds depending on machine and I do not know if it would be a > good idea/good solution to integrate. Especially I'm not sure if it is worth the issue or will kill the CI again and again. > > What do you think about it? Comments appreciated? > Hi, Maybe we could have a package with release tests that are not executed by the CI but that are executed at the moment of the feature freeze and some time before the Pharo release to ensure the quality of the code base for tests that are too long? > Thanks > T. > > > > -- Cyril Ferlicot https://ferlicot.fr

Sept. 6, 2018