- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [squeak-dev] Re: [Metacello] Re: Metacello questions

by Dale Henrichs

Andreas, We're talking conventions here, not hard and fast requirements. The convention is that you create a _baseline_ where you specify the list packages and projects that go into your project including repository info and dependencies. The you create a _version_ that imports a _baseline_ and simply specifies the specific mcz file and project version that goes into the project. As project structure changes, new baselines are created. As new mcz files or project versions are produced, a new version reflecting this new state is released. Separating this out from the beginning just makes it easier (in my opinion) for folks to wrap their minds around the two different concepts... structure of the project and version specification...Which I think is important to understand early on, whether or not you create separate artifacts or not... Dale ----- "Andreas Raab" <andreas.raab(a)gmx.de> wrote: | On 5/10/2010 10:06 AM, Dale Henrichs wrote: | > +1 | | I'll have to admit I find this quite awkward - like designing a | framework that has only one use case. It tends to push the wrong | things | into the abstraction layer. Is there anything fundamentally wrong with | | creating the baseline only at the point where you have more than one | version to deal with? | | Cheers, | - Andreas | | > With at least one exception:) | > | > In Seaside3.0 there is a tight coupling between the Seaside3.0 | packages and the Grease packages ... to the point were (at least for | the time being) a later version of Grease is not likely to work an | earlier version of Seaside3.0, so it _is_ appropriate to slave the | versions together by specifying a version in the baseline ... When | Grease/Seaside matures to the point were structural dependencies are | no longer being worked out, the need to specify the Grease version in | the baseline can (and should) go away. | > | > Dale | > ----- "Mariano Martinez Peck"<marianopeck(a)gmail.com> wrote: | > | > | My advice is not to specify versions in a project reference. | > | | > | If you have a baseline and in such baseline you reference a | project, | > | for | > | example: | > | | > | "this piece of code is inside a baselind" | > | project: 'UI Support' with: [ | > | | > | "One or more of the following | > | attributes may | > | be defined or changed" | > | spec | > | "Name of config class | (i.e., | > | ConfigurationOfXXX)" | > | className: | > | 'ConfigurationOfUI'; | > | "Version of project to be | > | loaded. if | > | theversionString is not specified, then the latest version of the | > | project is | > | used." | > | versionString: '1.0'; | > | | > | | > | Then, DO NOT PUT versionString: there. So: | > | | > | | > | "this piece of code is inside a baselind" | > | project: 'UI Support' with: [ | > | | > | "One or more of the following | > | attributes may | > | be defined or changed" | > | spec | > | "Name of config class | (i.e., | > | ConfigurationOfXXX)" | > | className: | > | 'ConfigurationOfUI'; | > | "Version of project to be | > | loaded. if | > | theversionString is not specified, then the latest version of the | > | project is | > | used." | > | file: 'XXX'. | > | | > | | > | And in a version method that has THAT basline, you write: | > | | > | spec | > | project: 'UISupport' with: '1.0'. | > | | > | | > | In summary, don't put version information in baselines, only in | > | version | > | methods. That's just my advice. | > | | > | Cheers | > | | > | Mariano | > | | > | | > | On Thu, May 6, 2010 at 10:13 PM, Torsten Bergmann<astares(a)gmx.de> | > | wrote: | > | | > |> >Does that mean the documentation is just wrong then? | > |> | > |> I would see/interpret it like this: With the baseline you | describe a | > | set of | > |> packages (structure/dependencies) that form your app/project | > | (MyApp). Beside | > |> the usual loading of a version: | > |> | > |> (ConfigurationOfMyApp project version: '1.0') load | > |> | > |> it is possible to load also a baseline - this would load all | the | > | latest | > |> Monticello package versions of any package described in this | > | baseline: | > |> | > |> (ConfigurationOfMyApp project version: '1.0-baseline') load | > |> | > |> Note that in the baseline you dont say anything about the | > | Monticello | > |> package | > |> version to use/load. | > |> | > |> In a baseline you can also define a dependency on another | project | > | (that | > |> provides a config too, for instance ConfigurationOfMyFoo). | > |> | > |> Now you have two options: | > |> | > |> a) dont say anything about the version of | "ConfigurationOfMyFoo" | > | in the | > |> baseline | > |> => this should load the latest version of Foo's | Metacello | > |> configuration then, | > |> so you get the latest version of "Foo" when loading | the | > | baseline | > |> of MyApp | > |> | > |> b) you note/give a default version for "ConfigurationOfMyFoo" | in | > | the | > |> baseline | > |> => then this specific version of "Foo" is loaded when you | load | > | the | > |> baseline for MyApp. | > |> I think you can override the version specified in the | > | baseline in | > |> a #versionXXX of MyApp if required | > |> | > |> Loading baselines is usefull if you work in a team. If you work | on | > | the | > |> same baseline you can just load it to be up to date with the | latest | > |> commits of the other team members. | > |> | > |> If your dependencies, load order, set of packages/pre-projects | > | change then | > |> you typically create a new baseline. | > |> | > |> But it is more often the case that you just create new versions | > | based on | > |> a baseline. In a versionXXX you pin/mark the Metacello version | of | > | all | > |> packages/projects version that fit/work together to form this | > | version. | > |> | > |> Maybe Dale is able to correct me if I'm wrong. | > |> | > |> Thanks | > |> Torsten | > |> | > |> | > |> | > |> -- | > |> GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! | > |> Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 | > |> | > |> _______________________________________________ | > |> Pharo-project mailing list | > |> Pharo-project(a)lists.gforge.inria.fr | > |> | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project | > |> | > | >

May 10, 2010

Re: [Pharo-project] (igor) Help for 1.1: condenseChanges does not work anymore

by Igor Stasenko

On 10 May 2010 19:26, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > Sorry for the infinite loop, it was my fault. > I thought it had been detected and solved already (in squeak ?). > > Destroying source pointer of un-installed methods was just a > workaround to be used in case of already broken sources. > There is another strategy : detect the source pointer of un-installed > methods and store them in the new change log. > This has to be done before logging source code of installed methods. > I'd like to point, that some trailer kinds don't need to be altered even if you condensing changes. They are completely self sufficient and not related to 'standard' source management system. In fact, a condense changes _should_ take care only about methods which having a trailers carrying the source pointers ("001000" #VarLengthSourcePointer, "111111" #SourcePointer ) while others don't need any changes. There is a test method in CompiledMethodTrailer, #hasSourcePointer which can be used to check if you need to deal with this method when condensing .changes or not. But since currently the variety of trailers its not widely adopted (most of methods just storing a source pointers there), its fine to destroy trailers of non-installed methods. In future, it could be made more clever. > Nicolas > > 2010/5/9 Igor Stasenko <siguctua(a)gmail.com>: >> On 9 May 2010 23:17, Alain Plantec <alain.plantec(a)free.fr> wrote: >>> >>>> Ok, i took the 11343 >>>> - fixed the #condenseChanges >>>> - ran Â Smalltalk condenseChanges >>>> - changed the single method >>>> - saved image >>>> - ran Â Smalltalk condenseChanges again >>>> >>>> no crash reported. >>>> >>> >>> Indeed, with 11343 it seems ok. >>> With 11326 (updated -> 11346), crash during the second condenseChanges :( >> >> Alain, could you please send me an image +.changes saved just before >> running a second condenseChanges? >> I'll try to find the cause of it. >> >>> Alain >>>> >>>> >>>>> >>>>> Alain >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

May 10, 2010

Re: [Pharo-project] could we start to organize MetacelloRepository?

by Dale Henrichs

Stef, Just thinking off the top of my head a bit. Conceptually a separate repository makes sense ... then Gofer Project could be setup to to use this repository by default and the standard instructions for loading things would be reduced to simple expressions like: Gofer project load: 'FFI'. Gofer project load: 'Magma'. The difficulty comes in keeping the repository up-to-date....First you'd need to qualify configurations for inclusion (a hudson server for validation) makes sense. For hudson, it would be nice if there were a list of candidate configuration/version pairs that would be tested against ... In reality we are really looking for an approved list of configuration/version pairs that are known to work in Pharo 1.0. So we're probably really interested in expressions like the following: Gofer project load: 'FFI' version: '1.2'. Gofer project load: 'Magma' version: '1.0r44'. At this point a separate repository becomes a little less useful ... it's not the Configuration alone that the end user is interested in as the version is very important and the important information is that it is "known to work" This leads me to think along the lines of - configs from MetacelloRepository - hudson server validating each version for each config - list of config/(latest passing version) pairs published It would seem to me that a relatively simple morphic/glamour window could be written that read the config/version pairs from the hudson server and provided a means for selecting/loading the config/version pairs. How does this sound? Dale ----- "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> wrote: | Hi Dale and others | | I would like to have a | Pharo1.0 folder in the MetacelloRepository and ideally all the | configurationOf... inside should work for Pharo 1.0. | How can we proceed to get that. | In the future we should also have a process to avoid that we get junk | inside. any idea (I was thinking about an hudson | server that would validate the configuration automatically) | | Stef

May 10, 2010

[Pharo-project] [update 1.1] #11350

by StÃ©phane Ducasse

11349 ----- - HashedCollection: clean dictionary do 11350 ----- - HashedCollection: now dictionary inherits from HashedCollection. tx tristan :)

May 10, 2010

Re: [Pharo-project] [Metacello] Re: Metacello questions

by Andreas Raab

May 10, 2010

Re: [Pharo-project] Which fonts for Pharo 1.1 ?

by Tudor Girba

On 10 May 2010, at 19:15, StÃ©phane Ducasse wrote: > > On May 10, 2010, at 4:01 PM, Mariano Martinez Peck wrote: > >> Hi guys. Last Pharo 1.0 images have the TrueType fonts. Now, in >> Pharo 1.1 Cores we have a StrikeFonts. We have two possibilites: >> >> 1) let those (strike fonts) fonts also for the dev image > 1) > > and people can load TT if they want. I agree. It also makes distributing images easier. Cheers, Doru > > >> 2) Continue to put TrueType in Pharo dev >> >> I am all ears. >> >> Cheers >> >> Mariano >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "Be rather willing to give than demanding to get."

May 10, 2010

Re: [Pharo-project] (igor) Help for 1.1: condenseChanges does not work anymore

by StÃ©phane Ducasse

nicolas do you have an idea where we can look? Stef On May 10, 2010, at 6:26 PM, Nicolas Cellier wrote: > Sorry for the infinite loop, it was my fault. > I thought it had been detected and solved already (in squeak ?). > > Destroying source pointer of un-installed methods was just a > workaround to be used in case of already broken sources. > There is another strategy : detect the source pointer of un-installed > methods and store them in the new change log. > This has to be done before logging source code of installed methods. > > Nicolas > > 2010/5/9 Igor Stasenko <siguctua(a)gmail.com>: >> On 9 May 2010 23:17, Alain Plantec <alain.plantec(a)free.fr> wrote: >>> >>>> Ok, i took the 11343 >>>> - fixed the #condenseChanges >>>> - ran Smalltalk condenseChanges >>>> - changed the single method >>>> - saved image >>>> - ran Smalltalk condenseChanges again >>>> >>>> no crash reported. >>>> >>> >>> Indeed, with 11343 it seems ok. >>> With 11326 (updated -> 11346), crash during the second condenseChanges :( >> >> Alain, could you please send me an image +.changes saved just before >> running a second condenseChanges? >> I'll try to find the cause of it. >> >>> Alain >>>> >>>> >>>>> >>>>> Alain >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 10, 2010

Re: [Pharo-project] Which fonts for Pharo 1.1 ?

by StÃ©phane Ducasse

On May 10, 2010, at 4:01 PM, Mariano Martinez Peck wrote: > Hi guys. Last Pharo 1.0 images have the TrueType fonts. Now, in Pharo 1.1 Cores we have a StrikeFonts. We have two possibilites: > > 1) let those (strike fonts) fonts also for the dev image 1) and people can load TT if they want. > 2) Continue to put TrueType in Pharo dev > > I am all ears. > > Cheers > > Mariano > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 10, 2010

Re: [Pharo-project] [Metacello] Re: Metacello questions

by Dale Henrichs

May 10, 2010

Re: [Pharo-project] Incremental garbage collection

by John M McIntosh

http://www.smalltalkconsulting.com/papers/GCPaper/GCTalk%202001.htm see slides 46 & 47 You need to have a tenure event, or a full GC to move the youngStart pointer past all previously allocated objects, thus promoting a previously allocated object from new space into old space. There is btw a primitive I added many years back primitiveForceTenure SystemDictionary>>forceTenure Understanding when and why you would want to use it is another question... On 2010-05-10, at 9:02 AM, Igor Stasenko wrote: > On 10 May 2010 18:33, Alexandre Bergel <alexandre.bergel(a)inria.fr> wrote: >> Hi! >> >> The garbage collection offered by the Pharo VM has two divisions. One for >> young objects, and another for old objects. I was wondering when a young >> object become old? I start to have a pretty good idea for human beings, but >> I am not so sure for Pharo objects. >> Is it when the object survives its first garbage collection? >> > I'd say, whenever VM decides to change a youngStart pointer. > Its quite sophisticated, and having a lot of quirks & preconditions. > But after compaction (either incremental or full), it usually picks a > free memory region which will serve as a space > for newly created objects. After that, obviously, all objects, which > survived GC treated as old ones. > > >> Cheers, >> Alexandre >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

May 10, 2010