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

Re: [Pharo-project] Metacello issues on Pharo 2.0

by Dale Henrichs

embedded comments ----- Original Message ----- | From: "Christophe Demarey" <Christophe.Demarey(a)inria.fr> | To: Pharo-project(a)lists.gforge.inria.fr | Sent: Thursday, February 21, 2013 1:11:49 AM | Subject: Re: [Pharo-project] Metacello issues on Pharo 2.0 | | Hi Dale | | Sure no problem was tired and nervous because Metacello is key for us. No harm no foul ... we're on the same page and that's what counts! | I'm sitting with christophe to check. | Information that can interest you | | - on the repository of Pharo the Metacello-Core was fixed to handle | FileReference | Now I do not know how you want to manage it for your bootstrap. | | let us know how you want that we proceed. I will have to look at the changes themselves to determine which direction to go ... if the changes are isolated enough I'd be inclined to hide them in MetacelloPlatform ... that's where the platform uglies go ... If the changes are extensive, then I'd consider extracting out a filedirectory[1]/filesystem[2] utilities package (as was done for zinc and filetree). [1] https://github.com/dalehenrich/filetree/tree/pharo2.0/repository/Monticello… [2] https://github.com/dalehenrich/filetree/tree/pharo2.0/repository/Monticello… | | - for the tests (not version 10.32 that I cannot load - I will have a look Metacello 1.0-beta.32 is the Metacello Preview version (not yet released anywhere) and porting that version stopped me cold last summer ... OSProcess was the final straw:) | at profStef to make it 2.0 aware I guess that this is that the problem) | runCase refers to SystemNotifier | | we have to check how we control silently the announcement of the new | announcer. | Probably SystemAnnouncer uniqueInstance suspendAllWhile: | | For the Toolbox problem | | Christophe checked the version of '1.0-beta.31.1.5' since this is the latest | stable version | | | spec | package: 'Metacello-Base' with: | 'Metacello-Base-DaleHenrichs.19'; -> | Metacello-Base-MarcusDenker.20 (no difference) | | | package: 'Metacello-Core' with: 'Metacello-Core-dkh.492'; | -> Metacello-Core-MarcusDenker.494 (handle FileSystem This looks fine and it also looks like it can easily be added to the MetacelloPlatform ... | | package: 'Metacello-MC' with: 'Metacello-MC-dkh.664'; | -> Metacello-MC-StephaneDucasse.666 (apparently we remove the | versions accesssor => look really suspicious) Yeah, that looks very suspicious and tests won't pass without that puppy:) | | package: 'Metacello-Reference' with: | 'Metacello-Reference-DaleHenrichs.31'; | package: 'Metacello-Tutorial' with: | 'Metacello-Tutorial-dkh.25'; | package: 'OB-Metacello' with: 'OB-Metacello-dkh.82'; | package: 'Metacello-TestsReference' with: | 'Metacello-TestsReference-DaleHenrichs.17'; | package: 'Metacello-TestsCore' with: | 'Metacello-TestsCore-DaleHenrichs.14'; | package: 'Metacello-TestsMC' with: | 'Metacello-TestsMC-dkh.351'; | package: 'Metacello-TestsTutorial' with: | 'Metacello-TestsTutorial-dkh.33'; | package: 'Metacello-ToolBox' with: | 'Metacello-ToolBox-dkh.130' | -> Metacello-ToolBox-MarcusDenker.135 | | here this is strange because the version of the toolbox in Pharo is | based on 135 134 133 132 131 127 126 .... so should we take another | version of the toolbox? | May be there was a mistake from our side to take a wrong branch. You are on the right branch, Metacello-ToolBox-dkh.130 is okay (it's part of Metacello 1.0-beta.31.1.5) but Metacello-ToolBox-dkh.131 is part of the Preview release. | | In particular neither version of configurationClasses work in pharo | | configurationClasses | "Return a set of the Metacello configuration classes that have been | loaded into the image." | | <apiDocumentation> | ^ MetacelloProjectRegistration configurationClasses This is code is from the preview version and shouldn't be used...yet. | | configurationClasses | "Return a set of the Metacello configuration classes that have been | loaded into the image." | | <apiDocumentation> | self flag: 'more work needed about MetacelloProjectRegistration'. | ^ Array streamContents: [ :s| | SystemNavigation default allClassesDo: [ :cls| | (cls name beginsWith: 'ConfigurationOf') | ifTrue: [ s nextPut: cls ]]] This is the variant that SHOULD work, presumably there is a problem with SystemNavigation? | | | So this means that we do not know what to do but Christophe cannot work on | 2.0 for versioner. | | | | Stef & Christophe | | | > Stef, | > | > AFAIK, this is the first report of any bugs with Metacello since | > September... just saying.... | > | > Dale | > | > ----- Original Message ----- | > | From: "stephane ducasse" <stephane.ducasse(a)free.fr> | > | To: Pharo-project(a)lists.gforge.inria.fr | > | Sent: Wednesday, February 20, 2013 11:53:28 AM | > | Subject: Re: [Pharo-project] Metacello issues on Pharo 2.0 | > | | > | | > | > Metacello is perfectly well maintained, and runs on a number of | > | > Smalltalks. | > | | > | I do not know. If Dale did not had a look since this summer this is 8 | > | months | > | ago. | > | I have no problem that this would happen. I just want to know because | > | we want to build all the validation of packages on top of metacello. | > | | > | > It broke on Pharo 2.0 because things changed too quickly, | > | > too quickly for Dale to keep up. | > | | > | Probably. But I do not think so. | > | | > | > What would be vastly more | > | > constructive than implying that Dale has abandoned Metacello would be | > | > applying some Pharo effort towards making it work again on 2.0. | > | | > | Frank I spent a lot of time pushing Metacello, christophe is working on a | > | tool | > | so that everybody can produce more easily configuration. | > | | > | Now my question is still valid. I just want to know because my time is | > | counted | > | and christophe is trying to understand metacello since some time and we | > | should | > | move forward. | > | | > | Stef | > | | > | > | > | > frank | > | > | > | >> Stef | > | >> | > | >> | > | >> | > | >> | > | >> On Feb 15, 2013, at 3:09 PM, Christophe Demarey | > | >> <Christophe.Demarey(a)inria.fr> wrote: | > | >> | > | >> Hi all, | > | >> | > | >> I have issues with Metacello on Pharo 2.0 | > | >> | > | >> If I load and run tests for the version used in Pharo1.4, it gives: | > | >> (ConfigurationOfMetacello project version: '1.0-beta.31.1.4') load: | > | >> 'Tests' | > | >> | > | >> <Capture dâÃ©cran 2013-02-15 Ã 14.45.15.png> | > | >> | > | >> Metacello packages shipped with Pharo 2.0 are all packages derived | > | >> from | > | >> the | > | >> latest stable Metacello baseline (1.0-beta.31.1.5) except the | > | >> MetacelloToolBox. | > | >> If I load and run tests packages with version described in the latest | > | >> stable | > | >> Metacello baseline (1.0-beta.31.1.5), i.e. : | > | >> | > | >> Metacello-TestsCore-DaleHenrichs.14 and | > | >> Metacello-TestsMC-dkh.351, | > | >> | > | >> it gives (Pharo 2.0 #20547): | > | >> <Capture dâÃ©cran 2013-02-15 Ã 14.55.36.png> | > | >> | > | >> So, it seems there are some problems. Do we use the rigth versions of | > | >> Metacello packages? | > | >> | > | >> Regards, | > | >> Christophe. | > | >> | > | >> | > | >> | > | > | > | | > | |

Feb. 25, 2013

[Pharo-project] Wanted to change my desktop background to a dark color and got a LazyListMorph should not happen...

by phil＠highoctane.be

In #20571 Settings > Appearance > Desktop > .. Uh? empty, nothing, zilch, nada. Except the LazyListMorph SNH Looks like a recurring problem... Phil

Feb. 25, 2013

Re: [Pharo-project] BalloonCanvas>>drawPolygon

by Hilaire Fernandes

Le 25/02/2013 16:28, Fernando Olivero a Ã©crit : > is a first step. Another option would be to work on a different Athens > backend for IOS, based on Quartz. The overall goal is to ditch Cairo > in favor of hardware accelerated backends. Not in my scope sadly. Hilaire

Feb. 25, 2013

Re: [Pharo-project] Building on Debian 6 amd64: not a walk in the park but works!

by Camillo Bruni

On 2013-02-24, at 22:25, phil(a)highoctane.be wrote: > Camillo, > > The zeronconf version is build with an older GLIBC and fails when > started on deb6 amd64. I still think it is the oposite `ldd --version` gives me something like EGLIBC 2.11 and this thread here says exactly the same http://steamcommunity.com/app/221410/discussions/0/882965118613928324/ > So it seems us Debian users have the following options: > * Wait for Debian to upgrade libc6 to >= 2.15 > * Recompile Steam for libc6 = 2.13 > * Modify the game executable to shell scripts which set the appropriate LD_LIBRARY_PATH and run the real game executable the same will apply for Pharo. It looks like you can manually install a glibc version from ubuntu (hack) or we have to downgrade our linux build slave or change the build process to manually specify an older glibc version for Pharo

Feb. 25, 2013

Re: [Pharo-project] please test 2.0

by Yanni Chiu

On 21/02/13 3:12 AM, Sven Van Caekenberghe wrote: > > On 20 Feb 2013, at 22:23, Yanni Chiu <yanni-bJEeYj9oJeDQT0dZR+AlfA(a)public.gmane.org> wrote: >> >> Switch to a CogVM (early version of PharoVM) that was lying around. > > This is a bit to be expected when you use older VMs, the one-click or designated Pharo (NBCog) VMs would have prevented these issues. Actually, the older VM worked fine - it's just a version of PharoVM, before it's name was changed from CogVM. The problem is that even the latest cog vm from http://mirandabanda.org will not work with Pharo-2.0. >> Next step, try to load my custom codeâ¦ > > Let us know how it goes ! I just had to change my build script to stop loading an older version of Fuel on top of the version already present in Pharo-2.0. After some quick manual testing, things look good. But, the newer Fuel version means I have to migrate Fuel versions again, which is not something I expected to have to do. Hmmm, will have to back away from moving to 2.0, for now.

Feb. 25, 2013

[Pharo-project] [update 2.0] #20571

by Esteban Lorenzano

20571 ----- Issue 7201: Check Fuel: merge back changes, load latest version https://code.google.com/p/pharo/issues/detail?id=7201 Diff information: http://ss3.gemstone.com/ss/Pharo20/FuelTools-Debugger-EstebanLorenzano.2.di… http://ss3.gemstone.com/ss/Pharo20/FuelTests-EstebanLorenzano.310.diff http://ss3.gemstone.com/ss/Pharo20/FuelSystem-FileRegistry-EstebanLorenzano… http://ss3.gemstone.com/ss/Pharo20/FuelCommandLineHandler-EstebanLorenzano.… http://ss3.gemstone.com/ss/Pharo20/Fuel-EstebanLorenzano.762.diff

Feb. 25, 2013

[Pharo-project] vm-test image

by Camillo Bruni

I just added http://files.pharo.org/image/20/vm-test.zip which is used to test the new VM builds This way we don't have 2 changing variables for the VM builds, the image stays fixed and only the VM behind changes. We can add a future job that tests the VM against the current image, but I think that will be of lesser importance as we cannot directly see if the VM performs well or not if there are already failing tests in the latest image. vm-test.zip changes compared to the latest 2.0 image ---------------------------------------------------- - fixed version with manual updates - all red tests are removed - all unstable tests are removed TODO: ----- - maybe add some more VM stress tests (adding classes / recompiling classes / adding instvars)

Feb. 25, 2013

Re: [Pharo-project] pharo-contribution triggering for new Pharo versions

by Pavel Krivanek

On Mon, Feb 25, 2013 at 3:17 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > On 2013-02-25, at 15:06, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> >> On Feb 25, 2013, at 3:01 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: >> >>> Hi, >>> >>> how to setup the jobs on pharo-contribution to be executed with every >>> new Pharo version? I tried simply to setup URL trigger on >>> http://pharo.gforge.inria.fr/ci/image/20/ but it was not started for >>> new versions. >> >> For Opal, I set a content trigger on >> >> https://ci.inria.fr/pharo/job/Pharo-2.0/lastSuccessfulBuild/buildTimestamp > > I added a placeholder job > https://ci.inria.fr/pharo-contribution/job/Pharo-2.0-Update-Trigger/ > > so you can just let it depend on that. > > Great! Thank you, done -- Pavel

Feb. 25, 2013

[Pharo-project] fast #becomeForward: crashes without PharoV10.sources

by Camillo Bruni

While setting up the new multi platform VM tests I saw that the tests fail extremely quickly when there are not PharoV10.sources available. It is still our know #becomeForward: but on CompiledMethods, but I just want to share that.

Feb. 25, 2013

Re: [Pharo-project] new build slaves

by Frank Shearar

On 25 February 2013 15:51, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > On 2013-02-25, at 16:49, Frank Shearar <frank.shearar(a)gmail.com> wrote: > >> As in "a stack in the cloud" or as in Apache's CloudStack >> (http://incubator.apache.org/cloudstack/)? > > Yes, inria has its own CloudStack setup for the CI servers Ah, nice! frank

Feb. 25, 2013