- Pharo-dev - lists.pharo.org

Re: [Pharo-project] How to load MetacelloToolbox

by Esteban Lorenzano

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 > | >> > | >> > | > > | > > | > | > | >

Nov. 4, 2012

Re: [Pharo-project] How to load MetacelloToolbox

by Dale Henrichs

Esteban, If I'm not mistaken the MetacelloToolBox is a candidate for inclusion to support Versionner. 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? I really can't think of anything in MetacelloToolBox that makes it a "bad idea" to include in Pharo2.0. I think that you might be happier if you stuck with 1.0-beta.31.1.5 as that predates the github support. 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] How to load MetacelloToolbox

by Dale Henrichs

Okay, I didn't think that there should be undeclared references showing up because of MetacelloToolBox ... a bug of some sort is more likely the root cause... Thanks, Dale ----- Original Message ----- | From: "Marcus Denker" <marcus.denker(a)inria.fr> | To: Pharo-project(a)lists.gforge.inria.fr | Sent: Sunday, November 4, 2012 2:27:41 AM | Subject: Re: [Pharo-project] How to load MetacelloToolbox | | | 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] How to load MetacelloToolbox

by Esteban Lorenzano

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] How to load MetacelloToolbox

by Camillo Bruni

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] 20381 running the test does not work ...

by Camillo Bruni

There are a couple of things missing in the progress refactoring I started with sean - 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 Marcus Denker

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] 20381 running the test does not work ...

by StÃ©phane Ducasse

While riding under the rain I was thinking and I guess that SystemProgressMorph => singleton that accepts several tasks and bars ProgressBarMorph => basic elements Job: progress bar + title + I will probably repackage this together and add comments then I will try to fix the size problem. Stef On Nov 3, 2012, at 10:48 PM, StÃ©phane Ducasse 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 > > 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. > > > 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] Are the any Fuel file analysis tools/techniques?

by Yanni Chiu

[cc: Seaside and Pier mailing lists] Postmortem, no polished code... First tried the "space" analysis tool from the "status" application tool of Seaside. It showed only objects with more than 100 instances, which did not give much useful info. with my data set. I suppose I could have changed the threshold. Second try: since the exported structure is a Pier kernel, I created a subclass of PRVisitor that visited each structure and its children, printing each structure on the Transcript. It did not find any extra objects in the deserialized kernel. Third try: create another PRVisitor that visited the kernel using #instVarAt: and #at: for variable classes. Again, it did not locate the extra objects. Fourth try: somehow inspired to examine #fuelAfterMaterialization. Placed a halt where it was called. Tried to filter the calls to only the objects where my code had specialize #fuelAfterMaterialization. While trying to get this filtering right, I noticed that the materialized object was a WAUserConfiguration instance. Using explore pointers, eventually found WASession instances and whatnot, being de-serialized. Using Smalltalk>>garbageCollect and regenerating a test Pier kernel, eventually led to a single WASession instance to trace. It led to a PRComponent holding its prototypeInstance object, which then held a non-nil PRContext. The solution, add: PRWidget class>>fuelIgnoredInstanceVariableNames ^#(context) The prototypeInstance construct was introduce by Magritte3/Pier3. I didn't have this issue before moving the Pier3. Clearly, I need better test cases. On 03/11/12 5:54 AM, Max Leske 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?

Nov. 4, 2012

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

by Ciprian Teodorov

loool... divisionByZero indeed On Sat, Nov 3, 2012 at 10:52 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > SystemProgressMorph show: 'Doing...' from: 0 to: 1 during: [ :bar | > 1 to: 2 do: [ :x | > bar current: x. > (Delay forMilliseconds: 20) wait "Just to slow it down so > we can see what's going on" ] ]. > > > Works while > > SystemProgressMorph show: 'Doing...' from: 1 to: 1 during: [ :bar | > 1 to: 2 do: [ :x | > bar current: x. > (Delay forMilliseconds: 20) wait "Just to slow it down so > we can see what's going on" ] ]. > > > not :) > > 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 > > > -- 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. 3, 2012