- Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] About a object life

by Max Leske

Only for new objects? If so, you could add an instance variable to Object and store a timestamp. 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

Nov. 4, 2012

Re: [Pharo-project] How to load MetacelloToolbox

by Francois Stephany

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. 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? 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] Are the any Fuel file analysis tools/techniques?

by Mariano Martinez Peck

Hi guys. Indeed, this is something we wanted since a long time and it has already been discussed: http://code.google.com/p/fuel/issues/detail?id=163 Unfortunately, nobody had time to do it. What we do have is written here: http://rmod.lille.inria.fr/web/pier/software/Fuel/Version1.8/Documentation/… but the visualization that does not work well if the graph is large. If your object graphs you usually serializer are around a known range of size, you can check after the serialization if that was the case, and if it was not, then debug it. Something you can do is to put a halt in FLSerialization >> #run just after doing the "self analysisStep.". At that point, you can inspect the instVar 'clusters'. You can see which clusters you have and each cluster understand #objects which answers all the list of objects associated to that cluster. If a cluster corresponds to a particular class you can also ask #theClass. But this only works for the serialization, not for the materialization. Cheers, On Sat, Nov 3, 2012 at 10:54 AM, Max Leske <maxleske(a)gmail.com> wrote: > +1 > I'd be very interested in that sort of thing. > > On 02.11.2012, at 19:08, Yanni Chiu <yanni(a)rogers.com> wrote: > > > This scenario has happened a few times... Stuff is serialized and > de-serialized (to/from files) without problem. Code changes are made. At > some later date, I notice that the Fuel file is orders of magnitude bigger > than it used to be. > > > > I usually manually de-serialize, and navigate the structures until I > find the cause of the bloating. > > > > Is there some package or code snippets that can quickly summarize the > object classes and sizes in a serialized file, or from its in-memory > de-serialized form? > > > > > > > -- Mariano http://marianopeck.wordpress.com

Nov. 4, 2012