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

Re: [Pharo-dev] Bisect with Pharo Launcher / Git

by btc＠openinworld.com

I am probably not working on it anytime soon, but btw I logged the idea last week of enhancing Pharo Launcher with some kind of support for bisect operations. https://pharo.fogbugz.com/default.asp?11927. cheers -ben Goubier Thierry wrote: > Hi all, > > I want to thank the combination of Pharo Launcher and the pharo-core > github repo for earching a specific bug in Pharo 3, linked to > https://pharo.fogbugz.com/f/cases/11949/ : > > I noticed that the bug was introduced between 30450 and 30490. With > the Pharo launcher, I then went through a ad-hoc bisecting (loading > the right image version / launching it / testing) : > > Start point is 30450 No bug, 30490 bug. > > 30470 No bug > 30480 No > 30485 Bug > 30483 No > 30484 Bug > > Then I tried to view the changes in Morphic for the bug out of the > Monticello tools... Didn't work :( It's hard to guess which versions > have changed and when in relation to the image version number. > > So I went to github/pharo-core and I searched for the relevant commit: > > https://github.com/pharo-project/pharo-core/commit/5034553d07f342a5a0e51275… > > > And a file that could be relevant: > > https://github.com/pharo-project/pharo-core/commit/5034553d07f342a5a0e51275… > > > And there I could see things in relation with MorpTreeMorph... Bug > solved shortly thereafter. Damn Rectangle stuff :( > > Thanks again

Oct. 22, 2013

Bisect with Pharo Launcher / Git

by Goubier Thierry

Hi all, I want to thank the combination of Pharo Launcher and the pharo-core github repo for earching a specific bug in Pharo 3, linked to https://pharo.fogbugz.com/f/cases/11949/ : I noticed that the bug was introduced between 30450 and 30490. With the Pharo launcher, I then went through a ad-hoc bisecting (loading the right image version / launching it / testing) : Start point is 30450 No bug, 30490 bug. 30470 No bug 30480 No 30485 Bug 30483 No 30484 Bug Then I tried to view the changes in Morphic for the bug out of the Monticello tools... Didn't work :( It's hard to guess which versions have changed and when in relation to the image version number. So I went to github/pharo-core and I searched for the relevant commit: https://github.com/pharo-project/pharo-core/commit/5034553d07f342a5a0e51275… And a file that could be relevant: https://github.com/pharo-project/pharo-core/commit/5034553d07f342a5a0e51275… And there I could see things in relation with MorpTreeMorph... Bug solved shortly thereafter. Damn Rectangle stuff :( Thanks again -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Oct. 22, 2013

Standard Fonts Specs

by Sven Van Caekenberghe

I don't understand why, but StandardFonts class>>#setFontsFromSpec: does not seem to work with the new fonts using a spec generated by StandardFonts class>>#getCurrentFontsSpec, while the following code does work for me: "From Pavel" SourceCodeProRegular new install. OpenSansRegular new install. FreeTypeFontProvider current updateFromSystem. "Set some specific fonts and sizes" #( #(#defaultFont: 'Open Sans' 12) #(#listFont: 'Open Sans' 12) #(#menuFont: 'Open Sans' 12) #(#windowTitleFont: 'Open Sans' 12) #(#balloonFont: 'Open Sans' 10) #(#codeFont: 'Source Code Pro' 11) #(#buttonFont: 'Open Sans' 12) #(#haloFont: 'Open Sans' 10)) do: [ :spec | | font | font := LogicalFont familyName: spec second pointSize: spec third. StandardFonts perform: spec first with: font ] I like the window title font bold, but I didn't manage that ;-) Anyway, this might be useful, I seem to remember Esteban had some trouble there as well. Sven

Oct. 22, 2013

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

by Camillo Bruni

>> For retracting files you need access to files.pharo.org. > > This is what should be written in the readme. BTW have you tried that you actually have access to the machine? Because I remember that it didn't work for you nor Esteban...

Oct. 22, 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 09:46, Johan Brichau <johan(a)inceptive.be> wrote: > In Seaside, there are a couple of tests that now fail because of this change. > > Although I agree it's good practice to use specific error classes in such assertions, the tests that are failing in Seaside use the Error class because they are written to be cross-platform. Different subclasses of Error will be thrown on different platforms. Moreover, the use of the assertion specifically documents that this test is testing for any errors being thrown. Removing the assertion means we need to write it down in comments, which is less explicit imho. That's not true, that is the default behavior that you test for not Errors. I mean every code that is run must work and testing that it does not raise and Error is duplicated efforts. As I said, checking for any other error makes somehow sense, but not for Error itself. Because that basically means that you ignore what the test does since you are not specific at all. The test framework takes already care of that part, if you have an error the test fails. I think that is the goal. I do not understand why you would have to explain this to the user of the tests, since for him the result does not change. Yes it is red instead of yellow, but does that matter? I mean you just transformed at will an error into an assertion failure, to me this sounds very bogus. Just because you transform the error to an assertion, you did not anticipated anything, since you cannot be sure at all where the error happened, since you do not test for an explicit error. On the other hand if you call a method that is very small to check if it really works, you know which errors are signaled and you test explicitly for those. I think I can come up with a tree transformation rule to go from #shouldnt:raise:Error to a refactored version that even includes a comment. > I'm not in favour of enforcing best practices this way. It just yields more workarounds in the end. > I also do not understand the problem with debugging the test. If the test fails, you step through it and will discover the cause. But if you just use the expression directly, the debugger pops up in the place where the error was signaled. Not somewhere in deep in the assertion framework. Furthermore if you run the test under jenkins you will get no reasonable feedback (yes this should be changed as well). Just try to debug the following statement in a test: self shouldnt: [ 0/0 ] raise: Error vs. 0/0. Of course we can change it back at some point, but I haven't heard a solid reason in favor of shouldnt:raise:Error. > Johan > > On 22 Oct 2013, at 00:26, Camillo Bruni <camillobruni(a)gmail.com> wrote: > >> >> 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. 22, 2013

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

by Johan Brichau

In Seaside, there are a couple of tests that now fail because of this change. Although I agree it's good practice to use specific error classes in such assertions, the tests that are failing in Seaside use the Error class because they are written to be cross-platform. Different subclasses of Error will be thrown on different platforms. Moreover, the use of the assertion specifically documents that this test is testing for any errors being thrown. Removing the assertion means we need to write it down in comments, which is less explicit imho. I'm not in favour of enforcing best practices this way. It just yields more workarounds in the end. I also do not understand the problem with debugging the test. If the test fails, you step through it and will discover the cause. Johan On 22 Oct 2013, at 00:26, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > 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. 22, 2013

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

by Camillo Bruni

I'll remove the script again, this is silly duplication that is going to be outdated very quickly. It points already to the jenkins job, this is where everything happens. On 2013-10-22, at 08:38, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > 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

[Issues fixed at the sprint] please double check

by Marcus Denker

Hi, A number issues worked on at the sprint where checked by the automatic issue checker. Some of them got *rejected* because of some conflict/failing test/hard critic error. These issues have been re-opened and need to be fixed again (and the status then needs to be put back in "review needed"). !!! This will not happen by itself! !!! Even more: to anyone these tracker entries look "owned" and waiting for someone else to fix it will for sure not lead to the desired result, people look at these issues and only will start to do something after weeks of inactivity, if ever ("If it was not important enough for those who fixed it originally to fix this triviality and resubmit, why should I care?"). Marcus

Oct. 22, 2013

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

by StÃ©phane Ducasse

I will add a discussion to the SUnit Chapter about this point. Stef 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 >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >

Oct. 22, 2013

Re: [Pharo-dev] Anyone else teaching programming in Pharo?

by J.F. Rick

It seems like there are enough people interested that it might be worthwhile sharing resources (e.g., Ozono). At minimum, these can act as inspiration for others doing the same thing. Is there a good Pharo way of doing that? For instance, is there a wiki we could use? I'm sure we could just add things to the Squeak wiki but I'm surprised that there is no Pharo wiki to utilize. I like the idea of adding a Dr. Geo MicroWorld, though my students aren't that math savvy. I'm sure I'll investigate that possibility a bit further down the line. And, I will take the suggestion of moving this discussion to pharo-users (last post to -dev from here), though I think there's a dev element to it (e.g., I added my MicroWorld environment to the shared server). Cheers, Jeff On Mon, Oct 21, 2013 at 10:04 AM, Alexandre Bergel <alexandre.bergel(a)me.com>wrote: > > I'm using smaller home-made examples for the lab that I port to the > latests version of Pharo. > > Are these available somewhere? > > Cheers, > Alexandre > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > -- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick

Oct. 22, 2013