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

Re: [Pharo-dev] MCVersionInfo: 10% of the image

by Chris Muller

> Chris, didn't you do something about this in Squeak? It would be nice to keep consistent if possible... Yes, but no one liked it because it employed the Proxy design-pattern and requires a become. Perhaps if I'd gotten it perfect the first time it'd have been better-received. But, I didn't, and the ensuing backlash wiped out any motivation for me to fix it. Marcus' suggestion is more explicit, and so might be better received by the community. There's a tradeoff between the two designs: In my design, you have to make sure you get it right or the image could lock up. In Marcus' design, you have to sprinkle multiple checks for #reload in the code and make sure you get it right, or you might end up saving corrupt MCZ packages (e.g., with #reload as the ancestry). Either way, its a wasteful part of the design of MC that should be addressed. I'm partial to fixing the Proxy solution, but I'd be in favor of ripping it out and adopting a stable alternative from Pharo if it becomes available. > > Eliot (phone) > > On Feb 20, 2015, at 6:41 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> Hi, >> >> The current Pharo4 contains *a lot* of MCVersionInfo instances. >> >> MCVersionInfo allInstances size >> >> 11095 >> >> The hold on to strings, Date, UUIDâ¦ a lot of stuff. All in all, this is around 10% of the current >> image. >> >> If you do >> >> MCVersionInfo allInstances do: [ :each | each instVarNamed: 'ancestors' put: nil ]. >> >> you image is a couple of MB smaller. >> >> In the past, when this information started to be >8MB, we did that. With the bad effect >> that we can not merge anymore across this boundary: we kill the past. >> >> Now this information is of course continained in the last MCZ file, too (all of them contain >> the complete historyâ¦) >> >> So would the following work? >> >> -> we set the âancestorsâ of MCVersionInfo to #reload >> -> the accessor, when it sees #reload, takes the name, deduces from that the package, >> and goes to the repo to load the ancestry info from the MCZFile. >> >> This means that e.g when saving a MCZFile, it would first re-create history info and then save >> it completely (like now), yet someone who just uses the system would never need to have this >> info in the image. >> >> Marcus

Feb. 20, 2015

Re: [Pharo-dev] MCVersionInfo: 10% of the image

by Eliot Miranda

Chris, didn't you do something about this in Squeak? It would be nice to keep consistent if possible... Eliot (phone) On Feb 20, 2015, at 6:41 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Hi, > > The current Pharo4 contains *a lot* of MCVersionInfo instances. > > MCVersionInfo allInstances size > > 11095 > > The hold on to strings, Date, UUIDâ¦ a lot of stuff. All in all, this is around 10% of the current > image. > > If you do > > MCVersionInfo allInstances do: [ :each | each instVarNamed: 'ancestors' put: nil ]. > > you image is a couple of MB smaller. > > In the past, when this information started to be >8MB, we did that. With the bad effect > that we can not merge anymore across this boundary: we kill the past. > > Now this information is of course continained in the last MCZ file, too (all of them contain > the complete historyâ¦) > > So would the following work? > > -> we set the âancestorsâ of MCVersionInfo to #reload > -> the accessor, when it sees #reload, takes the name, deduces from that the package, > and goes to the repo to load the ancestry info from the MCZFile. > > This means that e.g when saving a MCZFile, it would first re-create history info and then save > it completely (like now), yet someone who just uses the system would never need to have this > info in the image. > > Marcus

Feb. 20, 2015

Re: [Pharo-dev] development workflow for GTools (GToolkitCore)

by Tudor Girba

Hi, On Fri, Feb 20, 2015 at 4:53 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > > > 2015-02-08 13:01 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: > >> Hi Nicolai, >> >> >> >> On Thu, Feb 5, 2015 at 9:36 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: >> >>> 14850 <https://pharo.fogbugz.com/default.asp?14850> Integrate GTools >>> #development >>> "From this version onwards the development version should be >>> integrated." >>> >>> Is this a good idea? Does the #development version always include *all* >>> the latest >>> changes, because after Andrei opened >>> 14866 <https://pharo.fogbugz.com/default.asp?14866> Integrate GTools >>> (which got integrated in 40475) >>> I uploaded some changes for issue >>> 14608 <https://pharo.fogbugz.com/default.asp?14608> >>> ClassTest>>#testClassRespectsPolymorphismWithTrait failing due to >>> Spotter methods >>> I set the status to "Fix Review needed", >>> >> but my changes are integrated in 40475 too! >>> >> >> I think that in the current situation, it is actually a good idea. And >> yes, the integration does include all latest versions of GT-related >> packages. >> >> Before changing to development, we required a stable release for the >> integration. That implied: >> 1. creating a stable release and >> 2. integrating it in the Pharo through a separate issue. >> >> Yet, in GT we all work on the very latest version, and creating a >> "stable" release is somewhat artificial given the speed at which things are >> changing now. Creating the "stable" version also led to delays between a >> fix in GT and an integration in Pharo (sometimes measured in weeks). >> > > It still takes weeks. the last GToolkitCore integration was 3 weeks ago. > That's because of two reasons: (1) we did some changes that took longer, and (2) by the time we were ready to commit the jenkins went off. So, this time it is not so representative. We do want this to happen faster. > >> So, in the case of GT requiring the stable release did not provide any >> added value, but it has the negative consequence of delays. >> >> I am not satisfied with the way external packages are handled. >>> 1. if there is not one slice/changeset per issue, it is even less likely >>> someone will >>> review the changes. >>> 2. you don't know who works when on a issue. They are solved in a bulk. >>> 3. a new configuration might not only includes bugfixes but new features >>> as well. >>> 4. often we have unbound globals / undeclared references or other test >>> failures. >>> >>> Can we use the build server for those external projects (like >>> GToolkitCore, Athens, TxText), >>> and that if a project makes a new configuration, it uses the same >>> issue validator for loading and testing that configuration? >>> >> >> We already have a GToollkitCore job, but it only runs the GT tests. >> Perhaps this is not enough? >> https://ci.inria.fr/moose/job/gtoolkitcore/ >> > > It would be nice if it runs some of the image validation tests > ReleaseTest > ClassTest > BehaviorTest > ... > It now runs the ReleaseTest. We can add the ClassTest and BehaviorTest. What other tests should we add? Doru > That way we can we see early enough, if GT-Extensions will break some > validation rules (unresovled externals / Obsolete classes / Polymorphism > Trait/Class) > > > >> >> But, could the Monkey not be able to run all tests before an integration >> of the development version? >> > > I don't know if the Monkey can load Configurations. > > >> >> Cheers, >> Doru >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > > -- www.tudorgirba.com "Every thing has its own flow"

Feb. 20, 2015

Re: [Pharo-dev] development workflow for GTools (GToolkitCore)

by Nicolai Hess

2015-02-08 13:01 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi Nicolai, > > > > On Thu, Feb 5, 2015 at 9:36 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > >> 14850 <https://pharo.fogbugz.com/default.asp?14850> Integrate GTools >> #development >> "From this version onwards the development version should be integrated." >> >> Is this a good idea? Does the #development version always include *all* >> the latest >> changes, because after Andrei opened >> 14866 <https://pharo.fogbugz.com/default.asp?14866> Integrate GTools >> (which got integrated in 40475) >> I uploaded some changes for issue >> 14608 <https://pharo.fogbugz.com/default.asp?14608> >> ClassTest>>#testClassRespectsPolymorphismWithTrait failing due to Spotter >> methods >> I set the status to "Fix Review needed", >> > but my changes are integrated in 40475 too! >> > > I think that in the current situation, it is actually a good idea. And > yes, the integration does include all latest versions of GT-related > packages. > > Before changing to development, we required a stable release for the > integration. That implied: > 1. creating a stable release and > 2. integrating it in the Pharo through a separate issue. > > Yet, in GT we all work on the very latest version, and creating a "stable" > release is somewhat artificial given the speed at which things are changing > now. Creating the "stable" version also led to delays between a fix in GT > and an integration in Pharo (sometimes measured in weeks). > It still takes weeks. the last GToolkitCore integration was 3 weeks ago. > So, in the case of GT requiring the stable release did not provide any > added value, but it has the negative consequence of delays. > > I am not satisfied with the way external packages are handled. >> 1. if there is not one slice/changeset per issue, it is even less likely >> someone will >> review the changes. >> 2. you don't know who works when on a issue. They are solved in a bulk. >> 3. a new configuration might not only includes bugfixes but new features >> as well. >> 4. often we have unbound globals / undeclared references or other test >> failures. >> >> Can we use the build server for those external projects (like >> GToolkitCore, Athens, TxText), >> and that if a project makes a new configuration, it uses the same >> issue validator for loading and testing that configuration? >> > > We already have a GToollkitCore job, but it only runs the GT tests. > Perhaps this is not enough? > https://ci.inria.fr/moose/job/gtoolkitcore/ > It would be nice if it runs some of the image validation tests ReleaseTest ClassTest BehaviorTest ... That way we can we see early enough, if GT-Extensions will break some validation rules (unresovled externals / Obsolete classes / Polymorphism Trait/Class) > > But, could the Monkey not be able to run all tests before an integration > of the development version? > I don't know if the Monkey can load Configurations. > > Cheers, > Doru > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

Feb. 20, 2015

[Pharo4] Action needed: Issue tracker at 684 issues

by Marcus Denker

Hello, The issue tracker has an ever growing list of issues. We do a lot (e.g. last 7 days we closed 55), but nevertheless, as some point this is so much that issues are just not being acted on because there are so many. Therefore: -> Please check *ALL* the issue that you submitted. Have they been fixed? Are they really so important that they should take away attentions from other things? -> Check all the issues that you where involved in. With 684 issues, there is *NOBODY* that will look at your issue to fix trivalities (e.g. Monkey failed due to a system problem) the than you. -> Try to push some issue that you think is important. Even if you canât do anything, maybe you can convince others to help you to fix this? Marcus

Feb. 20, 2015

Re: [Pharo-dev] Spec terminology: renaming some terms

by Peter UhnÃ¡k

> > Do we even need "Composable" in the name? Why not just "SpecModel" or "SpecUIModel"? Btw there's also DynamicComposableModel.

Feb. 20, 2015

Re: [Pharo-dev] Spec terminology: renaming some terms

by Johan Fabry

> On Feb 20, 2015, at 12:07, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Henrik Sperre Johansen wrote >> If the goal is avoiding confusion to data model classes... > > Do we even need "Composable" in the name? This is relevant from a "where we > came from" standpoint, but to a new user, maybe it can be documented without > adding 10 characters to the class nameâ¦ Sure, we could consider that â¦ do you have any concrete suggestions? ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile

Feb. 20, 2015

Re: [Pharo-dev] Spec terminology: renaming some terms

by Sean P. DeNigris

Henrik Sperre Johansen wrote > If the goal is avoiding confusion to data model classes... Do we even need "Composable" in the name? This is relevant from a "where we came from" standpoint, but to a new user, maybe it can be documented without adding 10 characters to the class name... ----- Cheers, Sean -- View this message in context: http://forum.world.st/Spec-terminology-renaming-some-terms-tp4806486p480667… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Feb. 20, 2015

Re: [Pharo-dev] [FIX]: Issue 4795: Horizontal wheel

by Sean P. DeNigris

ccrraaiigg wrote >> Bueller? > > I think the devs here are perhaps *slightly* more busy than the > drooling teenagers in that scene... :) Hopefully, our days with Smalltalk are more like "borrowing" the Ferrari for an adventure ;) ----- Cheers, Sean -- View this message in context: http://forum.world.st/FIX-Issue-4795-Horizontal-wheel-tp4805005p4806674.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Feb. 20, 2015

Re: [Pharo-dev] Why was #asLegalSelector removed?

by Sean P. DeNigris

As you know, I love cleaning ;) But... stepharo wrote > https://github.com/pharo-project/pharo-workingRoadmaps/blob/master/StringCl… What enlightenment am I supposed to gain from "candidates for removal... asLegalSelector", and later "Done: candidates for removal... asLegalSelector". I still understand nothing of the rationale. stepharo wrote > This code is bogus and shitty. And useful ;) (as evidenced by this thread). Okay, it's limited, but what's better - having users roll their own every time? For now, I'll package it with my code, but I think we should add it back, maybe with a method comment to clarify that it creates a unary selector only... Bring back #asLegalSelector https://pharo.fogbugz.com/default.asp?14969 Fix in inbox: SLICE-Issue-14969-Bring-back-asLegalSelector-SeanDeNigris.1 ----- Cheers, Sean -- View this message in context: http://forum.world.st/Why-was-asLegalSelector-removed-tp4806427p4806671.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Feb. 20, 2015