- Pharo-dev - lists.pharo.org

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50543 Home: https://github.com/pharo-project/pharo-core

Jan. 24, 2016

Spur Garbage collection takes 4 times more when loading MSE (WAS: mse loading looks slower :()

by Vincent BLONDEAU

Hi, I made the benchmarks with the files you provided. I have more or less the same magnitude: Version 504: 0:00:01:09.021 Version 1175: 0:00:02:37.507 However, by launching it in the time profiler (MooseModel new importFromMSEStream: (StandardFileStream readOnlyFileNamed: 'd:/ArgoUML-0-34.mse')), it takes 504: 1 min 55 1175: 4 min 25 Well there is a delta... After investigation, the standard process has almost the same duration (120 secs for prespur and 140 secs for spur). But, there is a large difference in GC time: 504: not spur **Memory** old +144,822,000 bytes young -8,293,660 bytes used +136,528,340 bytes free -104,186,788 bytes **GCs** full 1 totalling 965ms (1.0% uptime), avg 965.0ms incr 3264 totalling 42,279ms (33.0% uptime), avg 13.0ms tenures 2,497 (avg 1 GCs/tenure) root table 0 overflows 1175: spur **Memory** old +0 bytes young +340,048 bytes used +340,048 bytes free -340,048 bytes **GCs** full 7 totalling 145,003ms (66.0% uptime), avg 20715.0ms incr 3288 totalling 30,912ms (14.0% uptime), avg 9.0ms tenures 7,146,505 (avg 0 GCs/tenure) root table 0 overflows Total GC time 504: 43 secs 1175: 176 secs See the performance reports attached. I let VM people take care of the issue ;) Cheers, Vincent -----Original Message----- From: moose-dev-bounces(a)list.inf.unibe.ch [mailto:moose-dev-bounces@list.inf.unibe.ch] On Behalf Of Tudor Girba Sent: dimanche 24 janvier 2016 09:08 To: Moose-related development Subject: [Moose-dev] Re: mse loading looks slower :( Hi, I am talking about the difference between Moose 6 images: - October 7: https://ci.inria.fr/moose/job/moose-6.0/504/artifact/moose-6.0.zip - yesterday: https://ci.inria.fr/moose/job/moose-6.0/1175/artifact/moose-6.0.zip Multiple things did change, but not in Moose. In the end, I would like to understand where the slowness comes. Maybe it comes from Spur itself, but maybe it comes from somewhere else. Cheers, Doru > On Jan 24, 2016, at 1:41 AM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > Doru...just to be sure it is not a Pharo (image change), when you said before and after Spur, do you mean a Pharo 5.0 exactly (just before Spur) and a Pharo JUST after it? Otherwise, the slowness may come from the difference between the 2 Pharos you are running. > > Cheers, > > On Sat, Jan 23, 2016 at 5:55 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > I am doing some performance testing of Moose with the Spur VM on Mac. > > I tried to load an MSE file with ArgoUML 0.34 and on my machine it loads twice as slow with Spur than before: > - PreSpur: 0:00:01:07.272 > - Spur: 0:00:02:10.508 > > Here is the reference file: > https://dl.dropboxusercontent.com/u/18323746/Tmp/ArgoUML-0-34.mse.zip > > And here is the script: > [ > MooseModel new > importFromMSEStream: (StandardFileStream readOnlyFileNamed: > (FileSystem workingDirectory / 'src' / 'ArgoUML-0-34' / 'ArgoUML-0-34.mse') fullName). > ] timeToRun > > Do you get the same? > > Cheers, > Doru > > > -- > www.tudorgirba.com > www.feenk.com > > "Problem solving should be focused on describing the problem in a way > that makes the solution obvious." > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev > > > > -- > Mariano > http://marianopeck.wordpress.com > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev -- www.tudorgirba.com www.feenk.com "What is more important: To be happy, or to make happy?" _______________________________________________ Moose-dev mailing list Moose-dev(a)list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev

Jan. 24, 2016

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50542 Home: https://github.com/pharo-project/pharo-core

Jan. 24, 2016

[pharo-project/pharo-core] 89d0e7: 50542

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 89d0e74f2ae2ba6c22e5fca2be2a60184e598f5d https://github.com/pharo-project/pharo-core/commit/89d0e74f2ae2ba6c22e5fca2… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-01-24 (Sun, 24 Jan 2016) Changed paths: M ConfigurationOfFastTable.package/ConfigurationOfFastTable.class/instance/symbolic versions/stable_.st A ConfigurationOfFastTable.package/ConfigurationOfFastTable.class/instance/versions/version09_.st M Morphic-Widgets-FastTable.package/FTAllItemsStrategy.class/instance/action/filter.st M Morphic-Widgets-FastTable.package/FTAllItemsStrategy.class/instance/action/matchingFilter_.st R Morphic-Widgets-FastTable.package/FTBasicItem.class/instance/converting/asString.st M Morphic-Widgets-FastTable.package/FTBasicItem.class/instance/printing/printOn_.st A Morphic-Widgets-FastTable.package/FTBasicItem.class/instance/private/expandWithoutChange.st A Morphic-Widgets-FastTable.package/FTColumnResizerMorph.class/README.md A Morphic-Widgets-FastTable.package/FTColumnResizerMorph.class/class/accessing/resizerWidth.st A Morphic-Widgets-FastTable.package/FTColumnResizerMorph.class/class/instance creation/container_left_right_.st A Morphic-Widgets-FastTable.package/FTColumnResizerMorph.class/class/instance creation/new.st A Morphic-Widgets-FastTable.package/FTColumnResizerMorph.class/definition.st A Morphic-Widgets-FastTable.package/FTColumnResizerMorph.class/instance/Polymorph-Widgets/mouseUp_.st A Morphic-Widgets-FastTable.package/FTColumnResizerMorph.class/instance/Polymorph-Widgets/shouldDraw.st A Morphic-Widgets-FastTable.package/FTColumnResizerMorph.class/instance/Polymorph-Widgets/themeChanged.st A Morphic-Widgets-FastTable.package/FTColumnResizerMorph.class/instance/accessing/splitsTopAndBottom.st A Morphic-Widgets-FastTable.package/FTColumnResizerMorph.class/instance/actions/resizeCursor.st A Morphic-Widgets-FastTable.package/FTColumnResizerMorph.class/instance/drawing/drawOn_.st A Morphic-Widgets-FastTable.package/FTColumnResizerMorph.class/instance/event handling/mouseDown_.st A Morphic-Widgets-FastTable.package/FTColumnResizerMorph.class/instance/event handling/mouseEnter_.st A Morphic-Widgets-FastTable.package/FTColumnResizerMorph.class/instance/event handling/mouseLeave_.st A Morphic-Widgets-FastTable.package/FTColumnResizerMorph.class/instance/event handling/mouseMove_.st A Morphic-Widgets-FastTable.package/FTColumnResizerMorph.class/instance/event handling/updateFromEvent_.st A Morphic-Widgets-FastTable.package/FTColumnResizerMorph.class/instance/initialization/initializeContainer_left_right_.st A Morphic-Widgets-FastTable.package/FTColumnResizerMorph.class/instance/private - testing/canResizeColumn.st A Morphic-Widgets-FastTable.package/FTColumnResizerMorph.class/instance/private/setGrabbedColor.st A Morphic-Widgets-FastTable.package/FTColumnResizerMorph.class/instance/style/normalFillStyle.st A Morphic-Widgets-FastTable.package/FTColumnResizerMorph.class/instance/style/pressedFillStyle.st A Morphic-Widgets-FastTable.package/FTColumnResizerMorph.class/instance/submorphs-add%2Fremove/delete.st A Morphic-Widgets-FastTable.package/FTColumnResizerMorph.class/instance/submorphs-add%2Fremove/release.st A Morphic-Widgets-FastTable.package/FTDisplayColumn.class/README.md A Morphic-Widgets-FastTable.package/FTDisplayColumn.class/class/instance creation/column_width_.st A Morphic-Widgets-FastTable.package/FTDisplayColumn.class/definition.st A Morphic-Widgets-FastTable.package/FTDisplayColumn.class/instance/accessing/column.st A Morphic-Widgets-FastTable.package/FTDisplayColumn.class/instance/accessing/column_.st A Morphic-Widgets-FastTable.package/FTDisplayColumn.class/instance/accessing/width.st A Morphic-Widgets-FastTable.package/FTDisplayColumn.class/instance/accessing/width_.st M Morphic-Widgets-FastTable.package/FTExampleMethodTableDataSource.class/instance/private/colorFor_.st A Morphic-Widgets-FastTable.package/FTExamples.class/class/examples/exampleTable4.st M Morphic-Widgets-FastTable.package/FTOutlineDataSource.class/instance/accessing/newDataSourceMatching_.st M Morphic-Widgets-FastTable.package/FTRootItemsStrategy.class/instance/action/filter.st M Morphic-Widgets-FastTable.package/FTSimpleDataSource.class/instance/accessing/newDataSourceMatching_.st A Morphic-Widgets-FastTable.package/FTTableContainerMorph.class/instance/drawing/addResizeSplitters.st M Morphic-Widgets-FastTable.package/FTTableContainerMorph.class/instance/drawing/drawOn_.st M Morphic-Widgets-FastTable.package/FTTableContainerMorph.class/instance/private/calculateColumnWidths.st M Morphic-Widgets-FastTable.package/FTTableContainerMorph.class/instance/private/calculateExactVisibleRows.st A Morphic-Widgets-FastTable.package/FTTableContainerMorph.class/instance/private/createResizableHeaderWith_between_and_.st M Morphic-Widgets-FastTable.package/FTTableContainerMorph.class/instance/testing/isRowIndexExceding_.st M Morphic-Widgets-FastTable.package/FTTableContainerMorph.class/instance/updating/updateExposedRows.st M Morphic-Widgets-FastTable.package/FTTableContainerMorph.class/instance/updating/updateHeaderRow.st M Morphic-Widgets-FastTable.package/FTTableMorph.class/class/accessing/defaultHeaderColor.st M Morphic-Widgets-FastTable.package/FTTableMorph.class/class/accessing/defaultIntercellSpacing.st M Morphic-Widgets-FastTable.package/FTTableMorph.class/definition.st A Morphic-Widgets-FastTable.package/FTTableMorph.class/instance/accessing/beNotResizable.st A Morphic-Widgets-FastTable.package/FTTableMorph.class/instance/accessing/beResizable.st M Morphic-Widgets-FastTable.package/FTTableMorph.class/instance/accessing/intercellSpacing_.st M Morphic-Widgets-FastTable.package/FTTableMorph.class/instance/initialization/initialize.st A Morphic-Widgets-FastTable.package/FTTableMorph.class/instance/testing/isResizable.st M Morphic-Widgets-FastTable.package/FTTableRowMorph.class/instance/initialization/initializeTable_.st M Morphic-Widgets-FastTable.package/FTTreeDataSource.class/instance/accessing/cellColumn_row_.st A Morphic-Widgets-FastTable.package/FTTreeFunctionStrategy.class/instance/accessing/dataSource.st M Morphic-Widgets-FastTable.package/FTVisibleItemsStrategy.class/instance/action/filter.st M Morphic-Widgets-FastTable.package/FTVisibleItemsStrategy.class/instance/action/matchingFilter_.st A Morphic-Widgets-FastTable.package/extension/UITheme/instance/fastTableColumnResizingColor.st A Morphic-Widgets-FastTable.package/extension/UITheme/instance/fastTableColumnSplitterSelectedColor.st A Morphic-Widgets-FastTable.package/extension/UITheme/instance/fastTableHeaderColor.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50541.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50542.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50541.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50542.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50542 17450 Add resize columns to fast table columns https://pharo.fogbugz.com/f/cases/17450 http://files.pharo.org/image/50/50542.zip

Jan. 24, 2016

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50541 Home: https://github.com/pharo-project/pharo-core

Jan. 24, 2016

[pharo-project/pharo-core] d56ab8: 50541

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: d56ab8399d8756c9f671332e11c5dde1c1dc92ec https://github.com/pharo-project/pharo-core/commit/d56ab8399d8756c9f671332e… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-01-24 (Sun, 24 Jan 2016) Changed paths: M Growl.package/GrowlMorph.class/class/settings/growlSettingsOn_.st R NautilusCommon.package/extension/RGClassDefinition/instance/definition.st A Ring-Core-Kernel.package/RGBehaviorDefinition.class/instance/filein%2Fout/definition.st M Rubric.package/RubTextAreaExamples.class/class/examples/profileSourcesFileViewing.st M Rubric.package/RubTextAreaExamples.class/class/private/show_while_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50540.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50541.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50540.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50541.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Tool-ExternalBrowser.package/ExternalBrowser.class/instance/structure accessing/showClassDefinition.st Log Message: ----------- 50541 17404 ExternalBrowser can not show meta class definition https://pharo.fogbugz.com/f/cases/17404 17443 RubTextAreaExamples>>#show:while: should not use #displayWorldSafely https://pharo.fogbugz.com/f/cases/17443 17457 Change Growl setting name to PopupNotifier https://pharo.fogbugz.com/f/cases/17457 http://files.pharo.org/image/50/50541.zip

Jan. 24, 2016

Re: [Pharo-dev] OSSubprocess use

by Thierry Goubier

Le 23/01/2016 19:23, Eliot Miranda a Ã©crit : > Hi Thierry, > >> On Jan 23, 2016, at 8:38 AM, Thierry Goubier >> <thierry.goubier(a)gmail.com> wrote: >> >> Hi Eliot, >> >> Le 23/01/2016 17:04, Eliot Miranda a Ã©crit : >>> Hi Both, Hi Dale, >>> >>>> On Jan 23, 2016, at 7:42 AM, Thierry Goubier >>>> <thierry.goubier(a)gmail.com> wrote: >>>> >>>> Le 23/01/2016 15:44, Mariano Martinez Peck a Ã©crit : >>>>> Hi Thierry, >>>>> >>>>> The Metacello answer here would be "it's up to you" hahahaha. >>>>> I don't have a strong opinion. Most of the times I am in the >>>>> similar situation, I tend to use fixed versions when the >>>>> projects are really coupled and one cannot work without the >>>>> other. And use #stable when they are less coupled and I would >>>>> not die if that dependency is broken for some time until >>>>> fixed. >>>>> >>>>> What would be the problem of using #stable? That I may >>>>> release new versions which may break the user API, or I may >>>>> introduce bugs that I didn't discover before, etc etc. It >>>>> won't be fun if I update GitFileTree and suddenly I cannot >>>>> commit anymore. But at the same time, you don't expect a user >>>>> to be updating GitFileTree in his image. In addition, you >>>>> have a CI that will tell you immediately if the build fail or >>>>> your tests failed. >>>>> >>>>> If you ask me, I think I would use fixed versions. Then, >>>>> whenever I release a new version, you give it a try, you test >>>>> it, you try it in the CI, etc. If everything seems to work, >>>>> then I would update your conf and point to new version. >>>> >>>> Yes. What is interesting is I can just target the baseline of >>>> OSSubprocess in that case, using that url >>>> >>>> github://marianopeck/OSSubprocess:v0.2.0/repository >>>> >>>> which is convenient. >>>> >>>> Thierry >>> >>> Maybe soon enough we can find a way of integrating CI server >>> test results for specific packages with Metacello and talk not >>> about #stable, but #greenest. Green means tests have passed, but >>> i think the connotation of green=young is common too, no? (viÃ±o >>> verde). This doesn't protect against API changes, when the tests >>> get changed to match the new API, but that implies versioning the >>> API separately from the package so one can ask for #greenest >>> #api=1.23. >> >> Well, if you take a Travis / Github integration and you fetch from >> branch 1.23, then you should only merge into that branch with a >> pull request if the tests are green. Moreover, with Metacello, >> baselines and branches you allways target the newest version; as >> long as your CI ensure that tests are green before merging into >> public/stable branches, then that already works. >> >> The branch methodology would look like that, then: >> >> - one branch for each stable / long lived version with garanteed >> API compatibility - v1.1 - one tag for each released version, when >> merged in their right overall branch - v1.1.0, v1.1.1, v1.1.2, >> v1.1.3 (inside branch v1.1) - development branches for the main >> work. - and an integrated CI like travis so that no merge can be >> done in a release branch without having everything green. >> >> Like that, if you target v1.1, you'll get the latest green version >> on API 1.1 :) > > Listening to Stephan I think the key point is "with the minimum > amount of manual work". Of course I can use the process above. But > if what the tests were to run were specified in code or as package > metadata, and the ci to run the tests was "available as a service" > without my having to configure, then I wouldn't need to manually > manage the process of only committing to the public version when the > tests were green; the system would do that for me. I certainly agree with that "minimum amount of manual work", and this is why I'm looking for the less friction setup: one that doesn't require me to update a few configurations in addition to merging and checking my integration tests. However, I would prefer to have, when releasing, a decision where I decide to push something, when all tests are green, and not automatically. As, for example, Dale has setup the FileTree repository, then I can commit and push on separate branches, let CI check those, and merge when I'm sure to a stable branch (when everything is green). Now, having nightly builds automatically the latest green one... I guess that can be done. > The only thing I'd have to do as a designer is name or version the > API if it needed to evolve. But the setup you describe is a bleeding edge type of things, on which some commits or pushes just fail the CI tests. So I'm not sure I'd like to be a user of that. Thierry

Jan. 23, 2016

Re: [Pharo-dev] How to manage GitFileTree and being integrated in-image (QualityAssistant example?)

by Thierry Goubier

Le 23/01/2016 19:00, Mariano Martinez Peck a Ã©crit : > > > On Fri, Jan 22, 2016 at 1:39 PM, Thierry Goubier > <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: > > > > 2016-01-22 17:22 GMT+01:00 Mariano Martinez Peck > <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>>: > > > > On Fri, Jan 22, 2016 at 11:50 AM, Thierry Goubier > <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> > wrote: > > Hi Mariano, > > this is a common question for external projects integrated > inside the Pharo image. And we have an issue with version > numbers, but let's try to keep that separate. > > Fixes to the code of external projects integrated inside > Pharo should be done upstream (on the external project > itself), not in the Pharo image. This is what is currently > happening with the GT tools, NeoJSON, Zinc, and probably a > few more. So, as a maintainer of such a projects in github, > say, you can ask people to create issues on your project, > pull requests and the like, and this is the only way bugs > found in Pharo in your release project should be corrected. > Then, everytime a new version of the Pharo image is built, a > version of your project is integrated; and you can add an > issue to update your project to a newer version inside Pharo. > > > Well, that covers A PART of the problem. If someone finds a bug > or whatever in MY project, then your workflow sounds perfect. > Now...consider internal refactors of Pharo that affects multiple > projects. For example few months ago, someone changes all > senders of #instVarNames to #instanceVariabls (or something like > that...I don't remember the exact change but something like > that). As part of those senders, there was Fuel. So when that > SLICE was integrated (with multiple packages as dependencies of > the SLICE), Fuel package was one of them. > > So what should be the path in this case: > > 1) Ask the poor guy that make the slice to also do the fork, git > clone, install gitfiletree, commit, push and make PR ... > > > Hum, takes about: > - 1 click or two on github for the fork > - 1 click on the configuration manager for gitfiletree > - 4 lines of metacello for remote clone + repository > - 3 clicks and a bit of text for the commit in the fork > - two clicks for the push to github > - 2 or 3 clicks for the pull request > > Soon (or even already now?), Skip Github code would allow that > without git/gitfiletree. But in github world, you would need a fork > anyway. > > > > Indeed. I have to admit that at the beginning I also thought it was > quit a pain. But now that I have done that many times, I can confirm > it's quite really easy. What is nice in there is that you have a clear way to open upstream to contributions (pull requests and issues) and manage those. In practice, I'd guess contributors will do the fork only once. But they will have to learn to keep it up to date with the upstream project :) > 2) Myself (as the developer of the tool) get notified when my > package gets changed and then, I take care of doing a diff and > manaully "port" the fix to my upstream project? > > > Probably this one. Technically, it is easy to: get the latest image; > get the gitfiletree repository; create a branch at the previous > stable version of the project; save the changed packages into that > branch; then decide (git merge?) those changes into either a new > stable version or on a development branch. Git will take care of the > difference between your new stuff and the stuff changed in Pharo, > and merge properly unless both sides have changed the same method / > line in a method. > > > That's a very cool path! The idea of making a branch from the last tag > version is great. Then you are at the normal branch/merge behavior. Yes. Especially since in such a change, you want to merge in two places: a successor to the tag (a v1.1.3 if it was v1.1.2) to release a new stable with the change for integration in the Pharo image, and a merge into your development branch. > I don't expect this sort of changes to occur very often. As you say, > this is a particular use case, with a large number of packages > changed, so I would consider that a rare occurrence for which I > don't have to specially optimize the process, just to have it > possible. Smaller fixes should be done the 1) way. > > > Fully agree. Thierry

Jan. 23, 2016

Re: [Pharo-dev] OSSubprocess use

by Eliot Miranda

Hi Thierry, > On Jan 23, 2016, at 8:38 AM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > Hi Eliot, > > Le 23/01/2016 17:04, Eliot Miranda a Ã©crit : >> Hi Both, Hi Dale, >> >>> On Jan 23, 2016, at 7:42 AM, Thierry Goubier >>> <thierry.goubier(a)gmail.com> wrote: >>> >>> Le 23/01/2016 15:44, Mariano Martinez Peck a Ã©crit : >>>> Hi Thierry, >>>> >>>> The Metacello answer here would be "it's up to you" hahahaha. I >>>> don't have a strong opinion. Most of the times I am in the >>>> similar situation, I tend to use fixed versions when the projects >>>> are really coupled and one cannot work without the other. And use >>>> #stable when they are less coupled and I would not die if that >>>> dependency is broken for some time until fixed. >>>> >>>> What would be the problem of using #stable? That I may release >>>> new versions which may break the user API, or I may introduce >>>> bugs that I didn't discover before, etc etc. It won't be fun if I >>>> update GitFileTree and suddenly I cannot commit anymore. But at >>>> the same time, you don't expect a user to be updating GitFileTree >>>> in his image. In addition, you have a CI that will tell you >>>> immediately if the build fail or your tests failed. >>>> >>>> If you ask me, I think I would use fixed versions. Then, whenever >>>> I release a new version, you give it a try, you test it, you try >>>> it in the CI, etc. If everything seems to work, then I would >>>> update your conf and point to new version. >>> >>> Yes. What is interesting is I can just target the baseline of >>> OSSubprocess in that case, using that url >>> >>> github://marianopeck/OSSubprocess:v0.2.0/repository >>> >>> which is convenient. >>> >>> Thierry >> >> Maybe soon enough we can find a way of integrating CI server test >> results for specific packages with Metacello and talk not about >> #stable, but #greenest. Green means tests have passed, but i think >> the connotation of green=young is common too, no? (viÃ±o verde). >> This doesn't protect against API changes, when the tests get changed >> to match the new API, but that implies versioning the API separately >> from the package so one can ask for #greenest #api=1.23. > > Well, if you take a Travis / Github integration and you fetch from branch 1.23, then you should only merge into that branch with a pull request if the tests are green. Moreover, with Metacello, baselines and branches you allways target the newest version; as long as your CI ensure that tests are green before merging into public/stable branches, then that already works. > > The branch methodology would look like that, then: > > - one branch for each stable / long lived version with garanteed API compatibility > - v1.1 > - one tag for each released version, when merged in their right overall branch > - v1.1.0, v1.1.1, v1.1.2, v1.1.3 (inside branch v1.1) > - development branches for the main work. > - and an integrated CI like travis so that no merge can be done in a release branch without having everything green. > > Like that, if you target v1.1, you'll get the latest green version on API 1.1 :) Listening to Stephan I think the key point is "with the minimum amount of manual work". Of course I can use the process above. But if what the tests were to run were specified in code or as package metadata, and the ci to run the tests was "available as a service" without my having to configure, then I wouldn't need to manually manage the process of only committing to the public version when the tests were green; the system would do that for me. The only thing I'd have to do as a designer is name or version the API if it needed to evolve. > > Thierry >

Jan. 23, 2016

Re: [Pharo-dev] How to manage GitFileTree and being integrated in-image (QualityAssistant example?)

by Mariano Martinez Peck

On Fri, Jan 22, 2016 at 1:39 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > 2016-01-22 17:22 GMT+01:00 Mariano Martinez Peck <marianopeck(a)gmail.com>: > >> >> >> On Fri, Jan 22, 2016 at 11:50 AM, Thierry Goubier < >> thierry.goubier(a)gmail.com> wrote: >> >>> Hi Mariano, >>> >>> this is a common question for external projects integrated inside the >>> Pharo image. And we have an issue with version numbers, but let's try to >>> keep that separate. >>> >>> Fixes to the code of external projects integrated inside Pharo should be >>> done upstream (on the external project itself), not in the Pharo image. >>> This is what is currently happening with the GT tools, NeoJSON, Zinc, and >>> probably a few more. So, as a maintainer of such a projects in github, say, >>> you can ask people to create issues on your project, pull requests and the >>> like, and this is the only way bugs found in Pharo in your release project >>> should be corrected. Then, everytime a new version of the Pharo image is >>> built, a version of your project is integrated; and you can add an issue to >>> update your project to a newer version inside Pharo. >>> >> >> Well, that covers A PART of the problem. If someone finds a bug or >> whatever in MY project, then your workflow sounds perfect. >> Now...consider internal refactors of Pharo that affects multiple >> projects. For example few months ago, someone changes all senders of >> #instVarNames to #instanceVariabls (or something like that...I don't >> remember the exact change but something like that). As part of those >> senders, there was Fuel. So when that SLICE was integrated (with multiple >> packages as dependencies of the SLICE), Fuel package was one of them. >> >> So what should be the path in this case: >> >> 1) Ask the poor guy that make the slice to also do the fork, git clone, >> install gitfiletree, commit, push and make PR ... >> > > Hum, takes about: > - 1 click or two on github for the fork > - 1 click on the configuration manager for gitfiletree > - 4 lines of metacello for remote clone + repository > - 3 clicks and a bit of text for the commit in the fork > - two clicks for the push to github > - 2 or 3 clicks for the pull request > > Soon (or even already now?), Skip Github code would allow that without > git/gitfiletree. But in github world, you would need a fork anyway. > Indeed. I have to admit that at the beginning I also thought it was quit a pain. But now that I have done that many times, I can confirm it's quite really easy. > > >> 2) Myself (as the developer of the tool) get notified when my package >> gets changed and then, I take care of doing a diff and manaully "port" the >> fix to my upstream project? >> > > Probably this one. Technically, it is easy to: get the latest image; get > the gitfiletree repository; create a branch at the previous stable version > of the project; save the changed packages into that branch; then decide > (git merge?) those changes into either a new stable version or on a > development branch. Git will take care of the difference between your new > stuff and the stuff changed in Pharo, and merge properly unless both sides > have changed the same method / line in a method. > > That's a very cool path! The idea of making a branch from the last tag version is great. Then you are at the normal branch/merge behavior. > I don't expect this sort of changes to occur very often. As you say, this > is a particular use case, with a large number of packages changed, so I > would consider that a rare occurrence for which I don't have to specially > optimize the process, just to have it possible. Smaller fixes should be > done the 1) way. > > Fully agree. Mariano http://marianopeck.wordpress.com

Jan. 23, 2016