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

Re: [Pharo-project] [Failing Tests] Cleaned up failing test serialization

by Ben Coman

Marcus Denker wrote: > Hi, > > To make it easy to explore why a test fails on the test server we serialize the stack of falling tests. > > With two changes this has now gotten much easier: > > 1) Drag and Drop support for .fuel file > Just drag the file to the Pharo Desktop --> Debugger opens > Could you advise how to do this from an operational image (that is, not a CI test image). I would like to use this to demonstrate Pharo's outstanding development environment. A killer feature would be the debugger having a <File out> button, that a user could use to mail to support. Does any other programming system allow this ? > 2) There where always a lot of fuel files. Reason: Expected failures where serialized, too. > This is now changed and the only serialized tests are those that failed. > > E.g for linux, you can download them here: > > https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/lastCompletedBuild/label=linu… > > > Marcus > >

Feb. 16, 2013

Re: [Pharo-project] Pharo vm builds restored

by Marcus Denker

On Feb 16, 2013, at 1:57 PM, Ben Coman <btc(a)openInWorld.com> wrote: > Marcus Denker wrote: >> On Feb 15, 2013, at 6:26 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> >>> Hi, >>> >>> Finally, with a lot of work, mana, power cards and jedi tricks, we made the pharo vm builds work again :) >>> >>> This builds are up-to-date with latest sources from Eliot's cog and adds pharo branding (AFAIK, this is the first time we are going to release something like that :) >>> >>> You can download it here: https://ci.inria.fr/pharo/view/VM/job/PharoVM/ >>> >>> >> >> Very good! >> >> So now we need to step by step.. >> -> use the build in the one-click >> -> link the VM zips on pharo-project.org >> -> replace the VM we use for running jobs on jenkins with this. >> >> And of course: >> -> test those builds on all three architectures automatically with a test image (e.g. current 2.0 with all failing tests removed) >> The idea is that this image should not change frequently (the only variable is the VM) >> > Could the CI test new VMs against all previous "release" images eg Pharo 1.3, 1.4, 1.4 Summer, 2.0, 2.x > or some subset, like the last release of each major version. While you may not want a very old release to fail a VM, at least the compatibility would be on record. One idea we had was to give up the "all VMs need to run all images", because this makes it very hard to moveâ¦ Marcus

Feb. 16, 2013

Re: [Pharo-project] Pharo vm builds restored

by Ben Coman

Marcus Denker wrote: > On Feb 15, 2013, at 6:26 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > >> Hi, >> >> Finally, with a lot of work, mana, power cards and jedi tricks, we made the pharo vm builds work again :) >> >> This builds are up-to-date with latest sources from Eliot's cog and adds pharo branding (AFAIK, this is the first time we are going to release something like that :) >> >> You can download it here: https://ci.inria.fr/pharo/view/VM/job/PharoVM/ >> >> > > Very good! > > So now we need to step by step.. > -> use the build in the one-click > -> link the VM zips on pharo-project.org > -> replace the VM we use for running jobs on jenkins with this. > > And of course: > -> test those builds on all three architectures automatically with a test image (e.g. current 2.0 with all failing tests removed) > The idea is that this image should not change frequently (the only variable is the VM) > Could the CI test new VMs against all previous "release" images eg Pharo 1.3, 1.4, 1.4 Summer, 2.0, 2.x or some subset, like the last release of each major version. While you may not want a very old release to fail a VM, at least the compatibility would be on record. > -> only when this is green the zip is updated in the archive > >

Feb. 16, 2013

[Pharo-project] [update 2.0] #20550

by Marcus Denker

20550 ----- Issue 7516: Failing test: Undeclared http://code.google.com/p/pharo/issues/detail?id=7516 Issue 7514: Nautilus cache for last modified classes prevents obsolete classes being GCd http://code.google.com/p/pharo/issues/detail?id=7514 Issue 7462: Failing tests RectangleTest http://code.google.com/p/pharo/issues/detail?id=7462 Issue 7460: Icons for TestCase in Nautilus, after a clean for production http://code.google.com/p/pharo/issues/detail?id=7460 Diff information: http://ss3.gemstone.com/ss/Pharo20/NautilusCommon-MarcusDenker.120.diff http://ss3.gemstone.com/ss/Pharo20/Nautilus-MarcusDenker.425.diff http://ss3.gemstone.com/ss/Pharo20/Kernel-MarcusDenker.1312.diff http://ss3.gemstone.com/ss/Pharo20/CI-Core-MarcusDenker.64.diff

Feb. 16, 2013

[Pharo-project] [Failing Tests] Cleaned up failing test serialization

by Marcus Denker

Hi, To make it easy to explore why a test fails on the test server we serialize the stack of falling tests. With two changes this has now gotten much easier: 1) Drag and Drop support for .fuel file Just drag the file to the Pharo Desktop --> Debugger opens 2) There where always a lot of fuel files. Reason: Expected failures where serialized, too. This is now changed and the only serialized tests are those that failed. E.g for linux, you can download them here: https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/lastCompletedBuild/label=linu… Marcus

Feb. 16, 2013

Re: [Pharo-project] obsolete behaviors in image

by stephane ducasse

indeed it looks strange. stef On Feb 15, 2013, at 1:39 PM, Martin Dias <tinchodias(a)gmail.com> wrote: > Hi > > In 20547, I do: > > SystemNavigation default obsoleteBehaviors. > > and obtain: > > an Array(Behavior Behavior class) > > > Which sounds weird. I tried with: > > SystemNavigation default obsoleteBehaviors first == Behavior > > and it's false. > > So at least it's not the class installed in system dictionary, but an > older version (probably). > > > I tried to remove them with: > > SmalltalkImage current fixObsoleteReferences. > 3 timesRepeat: [ Smalltalk garbageCollect ]. > > but no changes. > > Is this a known issue? > > I used #pointersTo to see who is pointing it but I didn't understand yet. > > Martin >

Feb. 16, 2013

[Pharo-project] [update 2.0] #20549

by Marcus Denker

20549 ----- Issue 7517: HDTestRunner: fuel files should not be written for expected failures http://code.google.com/p/pharo/issues/detail?id=7517 Diff information: http://ss3.gemstone.com/ss/Pharo20/SUnit-Core-MarcusDenker.66.diff http://ss3.gemstone.com/ss/Pharo20/HudsonBuildTools20-MarcusDenker.23.diff

Feb. 16, 2013

Re: [Pharo-project] Pharo vm builds restored

by Igor Stasenko

On 16 February 2013 10:24, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Feb 15, 2013, at 6:26 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Hi, > > Finally, with a lot of work, mana, power cards and jedi tricks, we made the > pharo vm builds work again :) > > This builds are up-to-date with latest sources from Eliot's cog and adds > pharo branding (AFAIK, this is the first time we are going to release > something like that :) > > You can download it here: https://ci.inria.fr/pharo/view/VM/job/PharoVM/ > > > Very good! > > So now we need to step by step.. > -> use the build in the one-click > -> link the VM zips on pharo-project.org > -> replace the VM we use for running jobs on jenkins with this. > > And of course: > -> test those builds on all three architectures automatically with a test > image (e.g. current 2.0 with all failing tests removed) > The idea is that this image should not change frequently (the > only variable is the VM) > -> only when this is green the zip is updated in the archive > yes. we should test new artifacts. > Marcus -- Best regards, Igor Stasenko.

Feb. 16, 2013

Re: [Pharo-project] Pharo vm builds restored

by stephane ducasse

thanks igor and esteban. Stef On Feb 16, 2013, at 12:36 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > Things you should know: > > - all VMs including: > OSProcess plugin > SSL Plugin (bundled with ssl library for win32) > NB Plugin > Freetype (bundled with freetype library for win32 & mac) > bundled with Cairo library (win32 & mac) > > linux VMs don't needs to be bundled, since you can install those libs > from their corresponding distros. > > -- > Best regards, > Igor Stasenko. >

Feb. 16, 2013

Re: [Pharo-project] Another stupid question

by stephane ducasse

so could you write two tests and submit a slice so that we improve the system Stef >> convertFromBase: sourceBase to: targetBase >> "Convert the receiver (who has to represent a number string) from the given source base to >> the given target base >> >> 'FFFF' convertFromBase: 16 to: 2 >> " >> ^(sourceBase asString,'r', self) asNumber printStringBase: targetBase > > Please, make that > > ^ (Number readFrom: self base: sourceBase) printStringBase: targetBase > > No useless copying and concatenating, simpler and more elegant. > > Sven > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > >

Feb. 16, 2013