November 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] ci down

by Camillo Bruni

all important files are backed up on http://pharo.gforge.inria.fr/ci/ On 2012-11-04, at 16:03, laurent laffont <laurent.laffont(a)gmail.com> wrote: > Sad, rainy sundays are great for hacking :) > > Laurent > > On Sun, Nov 4, 2012 at 3:40 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > >> >> On Nov 4, 2012, at 3:35 PM, laurent laffont <laurent.laffont(a)gmail.com> >> wrote: >> >>> Cannot open https://ci.lille.inria.fr/pharo/ >>> >> >> Yes, we have seen that and I send a mail to the server admin. But it is >> weekend >> and nothing will happen before monday... >> >> The good news is that a new ci installation is starting beta testing phase >> which will >> should be more stable. >> >> Marcus >> >> >> -- >> Marcus Denker -- http://marcusdenker.de >> >> >>

Nov. 4, 2012

Re: [Pharo-project] How to load MetacelloToolbox

by David T. Lewis

On Sun, Nov 04, 2012 at 04:14:00PM +0100, St?phane Ducasse wrote: > > > We looked a bit at OSProcess in 2.0 with Mariano on Friday. > > We tried to have clean loading (i.e., remove FileDirectory references + a couple of other stuff). We also spotted some inconsistencies in the ConfigurationOfOSProcess. > > Good! > > > I'm going to continue what we started but I don't think I will be able to make all the tests pass (if I remember well, they are not passing in 1.4 summer neither...) > > > > Where should I commit the changes? > > if you cannot in the os repo you can in the PharoTaskForces but let us wait that david reply. > Hi, I am open to suggestions :) Doing the work in PharoTaskForces would make sense to me. I don't mind doing integration work to pull things into the OSProcess repository, as long as we do not break the tests for OSProcess running in Squeak. But I am quite familiar with the Squeak environment, so it probably makes sense for me to do the work of testing that. Overall my time is kind of limited so it is better for me of others can do the Pharo development. In the CommandShell repository, I have a package called "CommandShellPharo" for compatibility things. Maybe we should have something similar like "OSProcessPharo" for OSProcess? Note that I am suggesting "CommandShellPharo" and "OSProcessPharo" rather than "CommandShell-Pharo" and "OSProcess-Pharo" because I still maintain "CommandShell" and "OSProcess" MCZ packages the repositories, so I would like to keep any Squeak/Pharo specifics in distinct packages. If there was an OSProcessPharo (or similar) package in PharoTaskForces, I can copy the updates into the OSProcess repo, or give someone the access to do so (currently Sebastian Sastre and Damien Pollet have developer access). Dave

Nov. 4, 2012

Re: [Pharo-project] About a object life

by Max Leske

ups :) On 04.11.2012, at 15:04, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > > On Sun, Nov 4, 2012 at 2:45 PM, Max Leske <maxleske(a)gmail.com> wrote: > Only for new objects? If so, you could add an instance variable to Object and store a timestamp. > > > Well, kind of ;) Because if you do that, your image will crash. This is because the VM directly accesses (by offset) certain instVars of certain classes. For example, it knows that the MethodDictionary of a class is at the offset 2. So, if you add an instVar to Object all these offsets will be shifted, and VM will be accessing incorrect places, and therefore, a crash :) > > > > On 03.11.2012, at 15:26, Edgar J. De Cleene <edgardec2005(a)gmail.com> wrote: > >> Folks: >> >> I wish know how old a object is. >> >> Any have code for this ? >> >> Thanks in advance >> >> Edgar > > > > > -- > Mariano > http://marianopeck.wordpress.com >

Nov. 4, 2012

Re: [Pharo-project] How to load MetacelloToolbox

by StÃ©phane Ducasse

> We looked a bit at OSProcess in 2.0 with Mariano on Friday. > We tried to have clean loading (i.e., remove FileDirectory references + a couple of other stuff). We also spotted some inconsistencies in the ConfigurationOfOSProcess. Good! > I'm going to continue what we started but I don't think I will be able to make all the tests pass (if I remember well, they are not passing in 1.4 summer neither...) > > Where should I commit the changes? if you cannot in the os repo you can in the PharoTaskForces but let us wait that david reply. stef > > > > On 04/11/12 11:57, Esteban Lorenzano wrote: >> Hi Dale, >> >> On Nov 4, 2012, at 11:51 AM, Dale Henrichs <dhenrich(a)vmware.com> wrote: >> >>> Esteban, >>> >>> If I'm not mistaken the MetacelloToolBox is a candidate for inclusion to support Versionner. >> >> damn! I didn't though in that :) >> >>> >>> If you are getting Github stuff in Pharo2.0, then I am curious which version of Metacello you are using. The #stable version of Metacello doesn't include github. >>> >>> The github support stuff needs OSProcess and from what I understand OSProcess won't be included in Pharo2.0, so perhaps you are more concerned about >>> the GitHub support than MetacelloToolBox? >> >> no idea, I just checked the latest baseline, and probably not the used one (sunday mode, today :) >> >>> >>> I really can't think of anything in MetacelloToolBox that makes it a "bad idea" to include in Pharo2.0. >> >> well.. is not about the toolbox, is about over-bloating the image... but the Versionner needs are a good point for its inclusion :) >> anyway, the most important thing is to be sure that packages we include and correspond to dev-support are unloadable when you do a shrink for production, and Metacello completelly fulfills that requirement :) >> >>> >>> I think that you might be happier if you stuck with 1.0-beta.31.1.5 as that predates the github support. >> >> as I said, this was my mistake on checking the baseline... github is not in current 2.0 images. >> >> Esteabn >> >>> >>> Dale >>> >>> ----- Original Message ----- >>> | From: "Esteban Lorenzano" <estebanlm(a)gmail.com> >>> | To: Pharo-project(a)lists.gforge.inria.fr >>> | Sent: Sunday, November 4, 2012 2:37:29 AM >>> | Subject: Re: [Pharo-project] How to load MetacelloToolbox >>> | >>> | ConfigurationOfMetacello ... load: 'Metacello-ToolBox'. >>> | >>> | should doit, and the baseline says: >>> | >>> | package: 'Metacello-ToolBox' with: [ spec requires: >>> | #('Metacello-Base' 'Metacello-Core') ]; >>> | >>> | >>> | and the "already included" metacello should be what is in the 'batch' >>> | group (Base and some Github access stuff). >>> | >>> | And I insist, including MetacelloToolBox in the 2.0 core image is a >>> | bad idea... >>> | >>> | Esteban >>> | >>> | On Nov 4, 2012, at 11:31 AM, Camillo Bruni <camillobruni(a)gmail.com> >>> | wrote: >>> | >>> | > Anyway what would be the default way to install it? >>> | > >>> | > AFAIK I didn't find any reference in the ConfigurationOfMetacello >>> | > but then again I am not particularly at searching :P >>> | > >>> | > On 2012-11-04, at 11:27, Marcus Denker <marcus.denker(a)inria.fr> >>> | > wrote: >>> | >> On Nov 3, 2012, at 8:34 PM, Dale Henrichs <dhenrich(a)vmware.com> >>> | >> wrote: >>> | >> >>> | >>> Out of curiosity, what are some of the undeclared references? >>> | >>> >>> | >>> There shouldn't be any undeclared references, unless you ignored >>> | >>> the required packages or ??? offhand I can't imagine what they >>> | >>> might be... >>> | >> >>> | >> >>> | >> I checked the latest 2.0 image and there are no Undeclareds >>> | >> there... >>> | >> >>> | >> With the build server dead (again...) checking of something is >>> | >> destroyed there we need to wait... >>> | >> >>> | >> >>> | >> -- >>> | >> Marcus Denker -- http://marcusdenker.de >>> | >> >>> | >> >>> | > >>> | > >>> | >>> | >>> | >>> >> >> > > -- > http://tulipemoutarde.be > CA: +1 778 558 3225 > BE: +32 65 709 131 >

Nov. 4, 2012

Re: [Pharo-project] 20381 running the test does not work ...

by StÃ©phane Ducasse

Thanks I will try to digest that. > - Job/ProgressBar should only use a single progress variable (0.0 - 1.0), no more > unbounded min/max/current which leads to duplicate size calculations everywhere > - The Visual part should be adapted to only take a single variable into account > - The ProgressMorph only updates maximally every 50ms no matter how many change/updates it got > - Make sure that concurrent progress are supported (currently only the last added progress > morph is updated) > > > On 2012-11-03, at 22:48, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> Ouch two problems! >> >> I'm also wondering why we have >> >> SystemProgressItemMorph and ProgressBarMorph >> in addition to SystemProgressMorph >> >> and of course JobProgressMorph and JobProgressBarMorph >> >> to me it looks like this is ok to have >> >> - one with the forbidden flag = JobProgressMorph >> - a default one = SystemProgressMorph >> and the bar = ProgressBarMorph > > definitely the hierarchy is mess there. And there are indeed only 4 items needed > - the Global displayed SystemProgressMorph which contains multiple progress indicators > and the logics to force update the UI even when stuff runs in the UI thread > - the item (title + progress bar) > - the progress bar > - the job item (title + progress bar + interrupt button) > > >> and I saw that the size of the SystemProgressMorph is not passed to the its inner elements leading to this ugly bar getting out of the >> size of the progress bar. > > the size should and has to be adapted automatically. > Currently it's not properly updated since I removed a forced refresh, which makes it >factor 10 faster. > Of course this should be rewritten once the previous points have been fixed. > > My idea was that the progress bar only grows but newer shrinks so that you avoid > this nasty size flickering when lots of subjobs are launched. > > >> Stef >> >> >> On Nov 3, 2012, at 10:12 PM, Ciprian Teodorov wrote: >> >>> Hi Stef, >>> >>> I have seen this problem too, and I think that JobTest is guilty for this behaviour, since its tearDown method removes all bars, even though they are not his to remove. >>> Try removing the tearDown... it work in my case >>> >>> JobTest>>tearDown >>> SystemProgressMorph uniqueInstance bars do: [ :e | e close ]. >>> >>> I hope that this helps... >>> >>> If not I think that there is a problem with the SystemProgressMorph api in a concurrent context... An arbitrary class should not be able to remove bars from our nice progress morph... >>> >>> Cheers, >>> Ciprian >>> >>> On Sat, Nov 3, 2012 at 9:57 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> Yes apparently the code run by the test uses the progress bar (do display progress) and at some point put its max to 1 (since there is only one definition to process) >>> => boum. >>> >>> since in that case we get a zeroDivide. >>> >>> Stef >>> >>> On Nov 3, 2012, at 9:51 PM, StÃ©phane Ducasse wrote: >>> >>>> I'm wondering if the progress bar code is not bogus and that it is created with wrong values. >>>> >>>>> Apparently there was failing test which invoked a on:fork:â¦. >>>>> >>>>> This is strange since the processTest were red. >>>>> Now running them alone brings green tests. >>>>> >>>>> <Screen Shot 2012-11-03 at 7.42.47 PM.pdf> >>>>> Stef >>>>> On Nov 3, 2012, at 12:53 PM, StÃ©phane Ducasse wrote: >>>>> >>>>>> There is a bug blocking the image. >>>>>> SubscriptOutOfBounds: 0 >>>>>> >>>>>> in the SystemProgressMorph class updateJob: >>>>>> >>>>> >>>> >>>> >>> >>> >>> >>> >>> >>> -- >>> Dr. Ciprian TEODOROV >>> IngÃ©nieur DÃ©veloppement CAO >>> >>> tÃ©l : 06 08 54 73 48 >>> mail : ciprian.teodorov(a)gmail.com >>> www.teodorov.ro >> >> > >

Nov. 4, 2012

Re: [Pharo-project] How to load MetacelloToolbox

by StÃ©phane Ducasse

>> If I'm not mistaken the MetacelloToolBox is a candidate for inclusion to support Versionner. > > damn! I didn't though in that :) > >> >> If you are getting Github stuff in Pharo2.0, then I am curious which version of Metacello you are using. The #stable version of Metacello doesn't include github. I do not think that we will have the time for that. Lot of bugs to close. >> The github support stuff needs OSProcess and from what I understand OSProcess won't be included in Pharo2.0, so perhaps you are more concerned about >> the GitHub support than MetacelloToolBox? > > no idea, I just checked the latest baseline, and probably not the used one (sunday mode, today :) > >> >> I really can't think of anything in MetacelloToolBox that makes it a "bad idea" to include in Pharo2.0. > > well.. is not about the toolbox, is about over-bloating the image... but the Versionner needs are a good point for its inclusion :) > anyway, the most important thing is to be sure that packages we include and correspond to dev-support are unloadable when you do a shrink for production, and Metacello completelly fulfills that requirement :) Yes We should spend some time on the building process based on metacello and a core to make sure that we keep the system modular. I will try to allocate some time reading Metacello internals. Stef > >> >> I think that you might be happier if you stuck with 1.0-beta.31.1.5 as that predates the github support. > > as I said, this was my mistake on checking the baseline... github is not in current 2.0 images. > > Esteabn > >> >> Dale >> >> ----- Original Message ----- >> | From: "Esteban Lorenzano" <estebanlm(a)gmail.com> >> | To: Pharo-project(a)lists.gforge.inria.fr >> | Sent: Sunday, November 4, 2012 2:37:29 AM >> | Subject: Re: [Pharo-project] How to load MetacelloToolbox >> | >> | ConfigurationOfMetacello ... load: 'Metacello-ToolBox'. >> | >> | should doit, and the baseline says: >> | >> | package: 'Metacello-ToolBox' with: [ spec requires: >> | #('Metacello-Base' 'Metacello-Core') ]; >> | >> | >> | and the "already included" metacello should be what is in the 'batch' >> | group (Base and some Github access stuff). >> | >> | And I insist, including MetacelloToolBox in the 2.0 core image is a >> | bad idea... >> | >> | Esteban >> | >> | On Nov 4, 2012, at 11:31 AM, Camillo Bruni <camillobruni(a)gmail.com> >> | wrote: >> | >> | > Anyway what would be the default way to install it? >> | > >> | > AFAIK I didn't find any reference in the ConfigurationOfMetacello >> | > but then again I am not particularly at searching :P >> | > >> | > On 2012-11-04, at 11:27, Marcus Denker <marcus.denker(a)inria.fr> >> | > wrote: >> | >> On Nov 3, 2012, at 8:34 PM, Dale Henrichs <dhenrich(a)vmware.com> >> | >> wrote: >> | >> >> | >>> Out of curiosity, what are some of the undeclared references? >> | >>> >> | >>> There shouldn't be any undeclared references, unless you ignored >> | >>> the required packages or ??? offhand I can't imagine what they >> | >>> might be... >> | >> >> | >> >> | >> I checked the latest 2.0 image and there are no Undeclareds >> | >> there... >> | >> >> | >> With the build server dead (again...) checking of something is >> | >> destroyed there we need to wait... >> | >> >> | >> >> | >> -- >> | >> Marcus Denker -- http://marcusdenker.de >> | >> >> | >> >> | > >> | > >> | >> | >> | >> > >

Nov. 4, 2012

Re: [Pharo-project] ci down

by laurent laffont

Sad, rainy sundays are great for hacking :) Laurent On Sun, Nov 4, 2012 at 3:40 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > On Nov 4, 2012, at 3:35 PM, laurent laffont <laurent.laffont(a)gmail.com> > wrote: > > > Cannot open https://ci.lille.inria.fr/pharo/ > > > > Yes, we have seen that and I send a mail to the server admin. But it is > weekend > and nothing will happen before monday... > > The good news is that a new ci installation is starting beta testing phase > which will > should be more stable. > > Marcus > > > -- > Marcus Denker -- http://marcusdenker.de > > >

Nov. 4, 2012

Re: [Pharo-project] ci down

by Marcus Denker

On Nov 4, 2012, at 3:35 PM, laurent laffont <laurent.laffont(a)gmail.com> wrote: > Cannot open https://ci.lille.inria.fr/pharo/ > Yes, we have seen that and I send a mail to the server admin. But it is weekend and nothing will happen before monday... The good news is that a new ci installation is starting beta testing phase which will should be more stable. Marcus -- Marcus Denker -- http://marcusdenker.de

Nov. 4, 2012

[Pharo-project] ci down

by laurent laffont

Cannot open https://ci.lille.inria.fr/pharo/ Laurent

Nov. 4, 2012

Re: [Pharo-project] About a object life

by Mariano Martinez Peck

On Sun, Nov 4, 2012 at 2:45 PM, Max Leske <maxleske(a)gmail.com> wrote: > Only for new objects? If so, you could add an instance variable to Object > and store a timestamp. > > Well, kind of ;) Because if you do that, your image will crash. This is because the VM directly accesses (by offset) certain instVars of certain classes. For example, it knows that the MethodDictionary of a class is at the offset 2. So, if you add an instVar to Object all these offsets will be shifted, and VM will be accessing incorrect places, and therefore, a crash :) > > On 03.11.2012, at 15:26, Edgar J. De Cleene <edgardec2005(a)gmail.com> > wrote: > > Folks: > > I wish know how old a object is. > > Any have code for this ? > > Thanks in advance > > Edgar > > > -- Mariano http://marianopeck.wordpress.com

Nov. 4, 2012