Re: [Pharo-project] 20381 running the test does not work ...
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 >> 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. 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.teodo...@gmail.com >> www.teodorov.ro > >
Re: [Pharo-project] How to load MetacelloToolbox
On Nov 3, 2012, at 8:34 PM, Dale Henrichs 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
Re: [Pharo-project] 20381 running the test does not work ...
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 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 >> 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. 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.teodo...@gmail.com >> www.teodorov.ro > >
Re: [Pharo-project] How to load MetacelloToolbox
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 wrote: > On Nov 3, 2012, at 8:34 PM, Dale Henrichs 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 > >
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 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 wrote:
>> On Nov 3, 2012, at 8:34 PM, Dale Henrichs 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
>>
>>
>
>
Re: [Pharo-project] How to load MetacelloToolbox
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" | To: Pharo-project@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 | 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 | | |
Re: [Pharo-project] How to load MetacelloToolbox
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"
| To: Pharo-project@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
| 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
| > wrote:
| >> On Nov 3, 2012, at 8:34 PM, Dale Henrichs
| >> 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
| >>
| >>
| >
| >
|
|
|
Re: [Pharo-project] How to load MetacelloToolbox
Hi Dale,
On Nov 4, 2012, at 11:51 AM, Dale Henrichs 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"
> | To: Pharo-project@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
> | 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
> | > wrote:
> | >> On Nov 3, 2012, at 8:34 PM, Dale Henrichs
> | >> 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
> | >>
> | >>
> | >
> | >
> |
> |
> |
>
Re: [Pharo-project] Are the any Fuel file analysis tools/techniques?
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/Debugging 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 wrote: > +1 > I'd be very interested in that sort of thing. > > On 02.11.2012, at 19:08, Yanni Chiu 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
Re: [Pharo-project] How to load MetacelloToolbox
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 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"
| To: Pharo-project@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
| 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
| > wrote:
| >> On Nov 3, 2012, at 8:34 PM, Dale Henrichs
| >> 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
Re: [Pharo-project] About a object life
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 wrote: > Folks: > > I wish know how old a object is. > > Any have code for this ? > > Thanks in advance > > Edgar
Re: [Pharo-project] About a object life
On Sun, Nov 4, 2012 at 2:45 PM, Max Leske 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 > wrote: > > Folks: > > I wish know how old a object is. > > Any have code for this ? > > Thanks in advance > > Edgar > > > -- Mariano http://marianopeck.wordpress.com
Re: [Pharo-project] ci down
On Nov 4, 2012, at 3:35 PM, laurent laffont 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
Re: [Pharo-project] ci down
Sad, rainy sundays are great for hacking :) Laurent On Sun, Nov 4, 2012 at 3:40 PM, Marcus Denker wrote: > > On Nov 4, 2012, at 3:35 PM, laurent laffont > 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 > > >
Re: [Pharo-project] How to load MetacelloToolbox
>> 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"
>> | To: Pharo-project@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
>> | 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
>> | > wrote:
>> | >> On Nov 3, 2012, at 8:34 PM, Dale Henrichs
>> | >> 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
>> | >>
>> | >>
>> | >
>> | >
>> |
>> |
>> |
>>
>
>
Re: [Pharo-project] 20381 running the test does not work ...
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 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 >>> 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. > > > 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.teodo...@gmail.com >>> www.teodorov.ro >> >> > >
Re: [Pharo-project] How to load MetacelloToolbox
> 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 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"
>>> | To: Pharo-project@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
>>> | 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
>>> | > wrote:
>>> | >> On Nov 3, 2012, at 8:34 PM, Dale Henrichs
>>> | >> 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
>
Re: [Pharo-project] About a object life
ups :) On 04.11.2012, at 15:04, Mariano Martinez Peck wrote: > > > > On Sun, Nov 4, 2012 at 2:45 PM, Max Leske 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 wrote: > >> Folks: >> >> I wish know how old a object is. >> >> Any have code for this ? >> >> Thanks in advance >> >> Edgar > > > > > -- > Mariano > http://marianopeck.wordpress.com >
Re: [Pharo-project] How to load MetacelloToolbox
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
Re: [Pharo-project] ci down
all important files are backed up on http://pharo.gforge.inria.fr/ci/ On 2012-11-04, at 16:03, laurent laffont wrote: > Sad, rainy sundays are great for hacking :) > > Laurent > > On Sun, Nov 4, 2012 at 3:40 PM, Marcus Denker wrote: > >> >> On Nov 4, 2012, at 3:35 PM, laurent laffont >> 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 >> >> >>
Re: [Pharo-project] PluggableListMorph error, how to debug ?
In pharo2.0 you can click on it and it opens a debugger. Stef On Nov 4, 2012, at 6:04 PM, laurent laffont wrote: > Hi, > > sometimes I have a PluggableListMorph that displays a big red square (see > attached screenshot). How can I debug why this happens ? > > > > Cheers, > > Laurent
Re: [Pharo-project] PluggableListMorph error, how to debug ?
In Pharo 1.4, browse Morph Find the method fullDrawOn: and replace on: Error do: [:err | self setProperty: #errorOnDraw toValue: true. self setProperty: #drawError toValue: err freeze. ^ self drawErrorOn: aCanvas ] by: value Now you will have a debugger instead of the red square of death But do it at you own risk ^^ Ben On Nov 4, 2012, at 6:04 PM, laurent laffont wrote: > Hi, > > sometimes I have a PluggableListMorph that displays a big red square (see > attached screenshot). How can I debug why this happens ? > > > > Cheers, > > Laurent
Re: [Pharo-project] PluggableListMorph error, how to debug ?
Thanks for the tip ! Laurent On Sun, Nov 4, 2012 at 6:37 PM, Benjamin < benjamin.vanryseghem.ph...@gmail.com> wrote: > In Pharo 1.4, browse Morph > Find the method fullDrawOn: > > and replace > > on: Error do: [:err | > self setProperty: #errorOnDraw toValue: true. > self setProperty: #drawError toValue: err freeze. > ^ self drawErrorOn: aCanvas > ] > > by: > value > > Now you will have a debugger instead of the red square of death > > But do it at you own risk ^^ > Ben > > On Nov 4, 2012, at 6:04 PM, laurent laffont wrote: > > > Hi, > > > > sometimes I have a PluggableListMorph that displays a big red square > (see attached screenshot). How can I debug why this happens ? > > > > > > > > Cheers, > > > > Laurent > > >
Re: [Pharo-project] PluggableListMorph error, how to debug ?
Cool :) Laurent On Sun, Nov 4, 2012 at 6:13 PM, Stéphane Ducasse wrote: > In pharo2.0 you can click on it and it opens a debugger. > > Stef > > On Nov 4, 2012, at 6:04 PM, laurent laffont wrote: > > > Hi, > > > > sometimes I have a PluggableListMorph that displays a big red square > (see attached screenshot). How can I debug why this happens ? > > > > > > > > Cheers, > > > > Laurent > > >
Re: [Pharo-project] 20381 running the test does not work ...
do you know what is the ProgressIndicatorMorph and LoggingSystemProgressItemMorph (which inherits from Object)? I will start to group all the classes into a separate package. Potentially rename them so that we can edit them and try to fix that. Stef On Nov 4, 2012, at 11:30 AM, Camillo Bruni wrote: > 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)
Re: [Pharo-project] About a object life
Hi Edgar-- Do you really want to know how old an object is, or just whether it's older than some other object? If you don't care about degrading the identity hash distribution, you could steal a few bits from the object header for a counter. -C -- Craig Latta www.netjam.org/resume +31 6 2757 7177 + 1 510 396 5727
Re: [Pharo-project] PluggableListMorph error, how to debug ?
Excellent tip!! Alexandre On Nov 4, 2012, at 2:37 PM, Benjamin wrote: > In Pharo 1.4, browse Morph > Find the method fullDrawOn: > > and replace > > on: Error do: [:err | > self setProperty: #errorOnDraw toValue: true. > self setProperty: #drawError toValue: err freeze. > ^ self drawErrorOn: aCanvas > ] > > by: > value > > Now you will have a debugger instead of the red square of death > > But do it at you own risk ^^ > Ben > > On Nov 4, 2012, at 6:04 PM, laurent laffont wrote: > >> Hi, >> >> sometimes I have a PluggableListMorph that displays a big red square (see >> attached screenshot). How can I debug why this happens ? >> >> >> >> Cheers, >> >> Laurent > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Re: [Pharo-project] About a object life
On 11/4/12 4:33 PM, "Craig Latta" wrote: > > Hi Edgar-- > > Do you really want to know how old an object is, or just whether > it's older than some other object? If you don't care about degrading the > identity hash distribution, you could steal a few bits from the object > header for a counter. Craig: Like to know how old an object is. As my reply to Hans-Martin, guess this is not possible in current Pharo/Squeak. Nice to read you ! Edgar
Re: [Pharo-project] Are the any Fuel file analysis tools/techniques?
On 04/11/12 6:43 AM, Mariano Martinez Peck wrote: But this only works for the serialization, not for the materialization. FLMaterializer>>materializeFromFileNamed: aFilename ^ (self materializationFromFileNamed: aFilename) root I've been using #materializeFromFileNamed: in my code, but I just happened to pick #materializationFromFileNamed: while debugging another problem, a moment ago. When I inspect the resulting FLMaterialization object, I can see the clusters - which is exacting what I was looking for a few days ago. By scanning the clusters, it should have been easy to figure out what objects should never have been serialized (e.g. WASession). Which was a critical clue to figure out where to look for where the extra objects were coming from.
