October 2013 - Pharo-dev - lists.pharo.org

Tracker issue need of review: 11954 MorphTreeMorph selection cleanup

by Marcus Denker

Hi, is this good to add? 11954 MorphTreeMorph selection cleanup https://pharo.fogbugz.com/f/cases/11954

Oct. 22, 2013

Re: [Pharo-dev] missing updates: 30503 30504

by StÃ©phane Ducasse

I changed the readme to be Pharo 3.0 Update Files ====================== This repository contains a collection of the updates files used for the system-updates of Pharo 3.0. The files are made available on the [file server](http://files.pharo.org/updates/pharo3.0/). The [updates30.list](updates30.list) is contains a list of all update files and is generated by a [jenkins job](https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-3-Release/). Do not touch these files manually if you do not know what you are doing. Read the class comments of the `ScriptLoader` class for a complete description of the Pharo integration process. Here is a bit of an explanation of how the staged and update.list are merged: this is the script of the jenkins job https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-3-Release/ ./pharo Pharo.image eval " updates := (ZnEasy get: 'http://files.pharo.org/updates/pharo3.0/updates30.list') contents lines. updates := updates reject: [ :each | each beginsWith: '#' ]. staged := 'updates30.staged' asFileReference readStream contents asString lines. staged := staged reject: [ :each | each beginsWith: '#' ]. updates := (updates, staged) asSet asArray sorted. 'updates30.list' asFileReference ensureDeleted writeStreamDo: [ :output | output nextPutAll: '#Pharo3.0'; cr. updates do: [ :each | output nextPutAll: each; cr ]]. Smalltalk snapshot: false andQuit: true." The update30.list file is generated on the server and in case of emergency this is the way to modify it. ssh file-pharo.inria.fr sudo su - filepharosync cd /appli/files.pharo.org/updates/pharo3.0/ vi updates30.list Good luck because you should not need it at all.

Oct. 22, 2013

Re: [Pharo-dev] missing updates: 30503 30504

by StÃ©phane Ducasse

On Oct 22, 2013, at 12:00 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Oct 21, 2013, at 9:24 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> >> >> Indeed but instead of getting on your favorite topic, tell me where is the update.list? > > on the server files.pharo.org > >> I do not understand why it is not in the pharo-update folder >> > because it is generated on the server and to have it in git would mean to have git installed on the server > and check it in. > > We found that too complex and instead treat the updates.list as a cache that is just generated on the server > > The thing is that this is all crappy stuff, the next step is to remove the updates.list and just rely on files in a directory. > > So and *accessing* files.pharo.org to edit the file is sadly compacted, but that is because Inria admins can't give > us anything else. > > ssh file-pharo.inria.fr > sudo su - filepharosync > cd /appli/files.pharo.org/updates/pharo3.0/ > vi updates30.list > > (yes, and then this is not in unix line endingsâ¦ so editing is a pain) > > yes, this all sucks. But what are the options? Doing nothing until it is beautiful and perfect? No add this info to the readme I added it because I do not have enough braincell to remember all these details. > Pharo 3.0 Update Files ====================== This repository contains a collection of the updates files used for the system-updates of Pharo 3.0. The files are made available on the [file server](http://files.pharo.org/updates/pharo3.0/). The [updates30.list](updates30.list) is contains a list of all update files and is generated by a [jenkins job](https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-3-Release/). Do not touch these files manually if you do not know what you are doing. Read the class comments of the `ScriptLoader` class for a complete description of the Pharo integration process. The update30.list file is generated on the server and in case of emergency this is the way to modify it. ssh file-pharo.inria.fr sudo su - filepharosync cd /appli/files.pharo.org/updates/pharo3.0/ vi updates30.list Good luck because you should not need it at all.

Oct. 22, 2013

Re: [Pharo-dev] missing updates: 30503 30504

by StÃ©phane Ducasse

On Oct 21, 2013, at 10:56 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > On 2013-10-21, at 22:30, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>>> It is fundamentally wrong to rely on written description of processes (not to be confused with documentation). We script, we >>>>> write code, we do not read prose. >>>> >>>> Sorry but the integration requires human intervention at least to make sure we do not merge bullshits or checking conflicts just before. >>>> Right now this is like that. Then even a script should be commented and documented. When I read you, you give the impression to >>>> the rest of the world that we are idiots doing everything manually. But this is not the case. We are doing only 2%: checking conflicts, >>>> writing the log and closing the bugs. Of course we should continue and make it fully automate. >>> >>> Which is something we solved with Ben 2 years ago. It did not do everything automatically, but as much as you can: >>> - it list the issues that can be integrated >>> - it lets you select the issues to be integrated >>> - it shows the diff of the integrated changes >>> - it triggers a new update cycle >> >> I'm favor of that. Now why neither marcus me or esteban do not use it? >> May be because we are afraid that if something break we are at loss. At least this is a stress to integrate a fix (even fullllllllly automated - the prove is that >> our wonderful staged process lets me publish cs while it should not else you would not complain that the system produced new items without corresponding images) > > I still didn't get what went exactly wrong with the updates. > Maybe you can explain the steps you did, so we can prevent such kind of faulty updates in the future. really simple I commited a package on top of its previous dirty version. graphics was dirty and I save it again to get everything clean now there was a pop up "you will lostâ¦." proceed/cancelâ¦. So I do not understand why it did not fail on the server. Marcus was doing some magic manually to handle this case. Now with my changes we will not have the pop up anymore. > For retracting files you need access to files.pharo.org. This is what should be written in the readme. Stef

Oct. 22, 2013

Re: [Pharo-dev] [Moose-dev] Class AthensCairoSurface missing in Athens Version 2.5?

by Alexandre Bergel

> version 2.5 is for Pharo 3.0 only. > for pharo 2.0 use stable version (which should load 2.1) Ok, thanks! Cheers, Alexandre > > > On 21 October 2013 20:46, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > True, I've tried with Pharo 3.0 and it works fine. Really strange... the class AthensCairoSurface is loaded > > Alexandre > > > On Oct 21, 2013, at 6:31 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > > Moose is in Pharo 20! > > Igor is talking about Pharo30 > > Stef > > > > On Oct 21, 2013, at 4:00 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > > >> Not sure whether I do the right thing. > >> > >> In a fresh Moose image, I doit: > >> Gofer new smalltalkhubUser: 'Pharo' project: 'Athens'; package: 'ConfigurationOfAthens'; load. (Smalltalk at: #ConfigurationOfAthens) loadDevelopment > >> > >> then executing: AthensCairoSurfaceExamples exampleInterop > >> raises an error => AthensCairoSurface not found > >> > >> Alexandre > >> > >> On Oct 21, 2013, at 2:02 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> > >>> Yes, i just checked, it loads fine in latest image, > >>> though, there are some unmerged stuff (no idea why) while loading, i just pressed 'load' > >>> > >>> ConfigurationOfAthens loadDevelopment > >>> > >>> AthensCairoSurfaceExamples exampleInterop > >>> working fine to me. > >>> > >>> > >>> > >>> > >>> On 21 October 2013 13:34, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > >>> Any update? > >>> > >>> Cheers, > >>> Alexandre > >>> > >>> > >>> On Oct 20, 2013, at 3:27 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >>> > >>>> > >>>> > >>>> > >>>> On 20 October 2013 15:03, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > >>>> hi! > >>>> > >>>> Apparently this class is not present in Version 2.5. > >>>> The example is broken because of this apparently: > >>>> AthensCairoSurfaceExamples exampleInterop > >>>> => error > >>>> > >>>> Any idea what's going on? > >>>> > >>>> > >>>> Error in Configuration? > >>>> I will check loading it in fresh image. > >>>> > >>>> > >>>> Cheers, > >>>> Alexandre > >>>> > >>>> -- > >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > >>>> Alexandre Bergel http://www.bergel.eu > >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> Best regards, > >>>> Igor Stasenko. > >>>> _______________________________________________ > >>>> Moose-dev mailing list > >>>> Moose-dev(a)iam.unibe.ch > >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >>> > >>> -- > >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > >>> Alexandre Bergel http://www.bergel.eu > >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> -- > >>> Best regards, > >>> Igor Stasenko. > >>> _______________________________________________ > >>> Moose-dev mailing list > >>> Moose-dev(a)iam.unibe.ch > >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >> > >> -- > >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > >> Alexandre Bergel http://www.bergel.eu > >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > >> > >> > >> > >> > > > > > > _______________________________________________ > > Moose-dev mailing list > > Moose-dev(a)iam.unibe.ch > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > -- > Best regards, > Igor Stasenko. -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 21, 2013

Re: [Pharo-dev] [Moose-dev] Class AthensCairoSurface missing in Athens Version 2.5?

by Igor Stasenko

version 2.5 is for Pharo 3.0 only. for pharo 2.0 use stable version (which should load 2.1) On 21 October 2013 20:46, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > True, I've tried with Pharo 3.0 and it works fine. Really strange... the > class AthensCairoSurface is loaded > > Alexandre > > > On Oct 21, 2013, at 6:31 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > > > Moose is in Pharo 20! > > Igor is talking about Pharo30 > > Stef > > > > On Oct 21, 2013, at 4:00 PM, Alexandre Bergel <alexandre.bergel(a)me.com> > wrote: > > > >> Not sure whether I do the right thing. > >> > >> In a fresh Moose image, I doit: > >> Gofer new smalltalkhubUser: 'Pharo' project: 'Athens'; package: > 'ConfigurationOfAthens'; load. (Smalltalk at: #ConfigurationOfAthens) > loadDevelopment > >> > >> then executing: AthensCairoSurfaceExamples exampleInterop > >> raises an error => AthensCairoSurface not found > >> > >> Alexandre > >> > >> On Oct 21, 2013, at 2:02 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> > >>> Yes, i just checked, it loads fine in latest image, > >>> though, there are some unmerged stuff (no idea why) while loading, i > just pressed 'load' > >>> > >>> ConfigurationOfAthens loadDevelopment > >>> > >>> AthensCairoSurfaceExamples exampleInterop > >>> working fine to me. > >>> > >>> > >>> > >>> > >>> On 21 October 2013 13:34, Alexandre Bergel <alexandre.bergel(a)me.com> > wrote: > >>> Any update? > >>> > >>> Cheers, > >>> Alexandre > >>> > >>> > >>> On Oct 20, 2013, at 3:27 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >>> > >>>> > >>>> > >>>> > >>>> On 20 October 2013 15:03, Alexandre Bergel <alexandre.bergel(a)me.com> > wrote: > >>>> hi! > >>>> > >>>> Apparently this class is not present in Version 2.5. > >>>> The example is broken because of this apparently: > >>>> AthensCairoSurfaceExamples exampleInterop > >>>> => error > >>>> > >>>> Any idea what's going on? > >>>> > >>>> > >>>> Error in Configuration? > >>>> I will check loading it in fresh image. > >>>> > >>>> > >>>> Cheers, > >>>> Alexandre > >>>> > >>>> -- > >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > >>>> Alexandre Bergel http://www.bergel.eu > >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> Best regards, > >>>> Igor Stasenko. > >>>> _______________________________________________ > >>>> Moose-dev mailing list > >>>> Moose-dev(a)iam.unibe.ch > >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >>> > >>> -- > >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > >>> Alexandre Bergel http://www.bergel.eu > >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> -- > >>> Best regards, > >>> Igor Stasenko. > >>> _______________________________________________ > >>> Moose-dev mailing list > >>> Moose-dev(a)iam.unibe.ch > >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >> > >> -- > >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > >> Alexandre Bergel http://www.bergel.eu > >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > >> > >> > >> > >> > > > > > > _______________________________________________ > > Moose-dev mailing list > > Moose-dev(a)iam.unibe.ch > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > -- Best regards, Igor Stasenko.

Oct. 21, 2013

Re: [Pharo-dev] Use #shouldnt:raise: only with specific errors, or evaluate the given expression directly

by Camillo Bruni

On 2013-10-22, at 00:20, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Instead of using shouldnt:raise:, you can simply remove the assertion, as in: > > -=-=-=-=-=-=-=-=-= > testNoErrorWhenDrawing > self shouldnt: [ view raw drawOn: tracingCanvas ] raise: Error > -=-=-=-=-=-=-=-=-= > > || > V > > -=-=-=-=-=-=-=-=-= > testNoErrorWhenDrawing > view raw drawOn: tracingCanvas > -=-=-=-=-=-=-=-=-= > > With the second version of the test, the test may be listed as an error in case of an exception, whereas the first version it can only be listed as a failure. Right, but that doesn't make any difference IMO, using `shouldnt: [...] raise: Error` to not have errors does not make much sense. It makes a little bit more sense when using a specific Error, and it makes sense when testing for Notifications, which would go otherwise unnoticed. Which is the reason that `#shouldnt:raise:` no longer accepts `Error` as an argument, but still lets you use anything else. > I read your post and I kind of agree. > I will fix my tests then. nice :)

Oct. 21, 2013

Re: [Pharo-dev] Use #shouldnt:raise: only with specific errors, or evaluate the given expression directly

by Alexandre Bergel

Instead of using shouldnt:raise:, you can simply remove the assertion, as in: -=-=-=-=-=-=-=-=-= testNoErrorWhenDrawing self shouldnt: [ view raw drawOn: tracingCanvas ] raise: Error -=-=-=-=-=-=-=-=-= || V -=-=-=-=-=-=-=-=-= testNoErrorWhenDrawing view raw drawOn: tracingCanvas -=-=-=-=-=-=-=-=-= With the second version of the test, the test may be listed as an error in case of an exception, whereas the first version it can only be listed as a failure. I read your post and I kind of agree. I will fix my tests then. Alexandre On Oct 22, 2013, at 12:08 AM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > see my long explanation here https://pharo.fogbugz.com/default.asp?11876#87218 > it looks unsuspicous until the moment you try understand such a failing assertion. > > On 2013-10-21, at 23:42, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > >> Hi! >> >> Just to share some thought. >> I am now playing with Pharo 3. I have seen TestCase has some additional checks for assertion with exception. I perfectly understand the idea behind this, however, on the other hand, I see nothing suspect with the following assertion (which Roassal's tests are full of): >> >> self shouldnt: [ view raw drawOn: tracingCanvas ] raise: Error >> >> I have to shut down the method #validateShouldntException: >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 21, 2013

Re: [Pharo-dev] [regression reporter]regression occurred

by Camillo Bruni

The idea would be that the whole integration fails with only a single test failing. But for that the monkey has to be at 100% ;) and we're at 95% or so and only integrate a single issue at a time and then rerun all validations, but thats future talk. For now, I think the only reasonable thing is to look at the build each friday and make it green, since classifying tests is not that easy, and the jenkins setup is already close to be unmaintainable. On 2013-10-21, at 23:24, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Tests that fail indicate that something is broken. They are like a kind of todo. But sometimes they are hard to fix and remain open for a long time. I understand that that conflicts with the notion of being 'all green all the time'. Maybe we should classify them somehow ? > > On 21 Oct 2013, at 23:08, Camillo Bruni <camillobruni(a)gmail.com> wrote: > >> sad but true :( >> >> On 2013-10-21, at 08:37, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >>> I have turned off these emails for now, they are too many and thus get ignored >>> (I have never seen anyone but me filing an issue tracker entry for a newly failing testâ¦) >>> >>> Marcus >>> >>> On Oct 21, 2013, at 8:32 AM, no-reply(a)ci.inria.fr wrote: >>> >>>> https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2.1-Validation-M-Z/labe… >>>> >>>> 2 regressions found. >>>> Tests.Release.ReleaseTest.testLocalMethodsOfTheClassShouldNotBeRepeatedInItsTraits >>>> Zinc.Tests.ZnServerTests.testEntityTooLarge

Oct. 21, 2013

Re: [Pharo-dev] Use #shouldnt:raise: only with specific errors, or evaluate the given expression directly

by Camillo Bruni

see my long explanation here https://pharo.fogbugz.com/default.asp?11876#87218 it looks unsuspicous until the moment you try understand such a failing assertion. On 2013-10-21, at 23:42, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Hi! > > Just to share some thought. > I am now playing with Pharo 3. I have seen TestCase has some additional checks for assertion with exception. I perfectly understand the idea behind this, however, on the other hand, I see nothing suspect with the following assertion (which Roassal's tests are full of): > > self shouldnt: [ view raw drawOn: tracingCanvas ] raise: Error > > I have to shut down the method #validateShouldntException: > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >

Oct. 21, 2013