November 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] [Pharo-Project] About new TxText text model

by StÃ©phane Ducasse

Can you add part of this mail as class comment? Tx On Nov 21, 2012, at 10:58 PM, Igor Stasenko wrote: > On 20 November 2012 21:30, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >> Hello. >> >> Can you add me as project contributor. I try to upload version with detailed >> comment from my first mail but can't. >> >> 2012/11/18 Camillo Bruni <camillobruni(a)gmail.com> >>> >>> I don't think the basic model should know about the visual lines. We >>> discussed >>> that for a while, but in the end that's purely a view on the basic model. >> >> >> If such behaviour will be at view simple Cursor>>moveUp/moveDown will never >> work right from user perspective. So why you need cursor at text model which >> will never reflect state of visual cursor at screen? >> To me text model should completelly represent what user see at text view. >> Otherwise why you call it model? Otherwise it is just raw data like Text in >> current TextMorph. >> > > because same model can have multiple different views. and each view > can have different > dimensions and show different portion(s) of model (text). > The parts we implemented so far is about editing the model itself. > Next step would be to implement text attribute(s) management, > and then implement View(s) which will lay out the text for rendering > it on screen. > > About cursor: The cursor is actually a convenience method in current model, > to avoid using > 'text selection end' every time. > > The selection/cursor in text model there because this should be is the > only way how you can modify text: > - you should not be able to modify text without using selection(s)/cursor. > Any direct usage, like in existing Text , should be prohibited. Only > high level operations via selection. > And no illusions about that you can operate with text as with an > ordinal Collection. > If you want to turn text model into 'collection', you have to pay the > price: use #asString. > An way to treat text as a collection of characters is imo futile and > falls short once you think how to introduce non-textual objects into > text (images etc). > > More about selections: > It is not necessary to have a direct correspondence between model > selection and visual text editor > selection/cursor. And often, actually would be counterproductive. > > Camillo may disagree, but i think the main purpose of selection/cursor > objects and their protocol is to provide a convenient interface for > editing the model. > And the fact that you can have visual selection/cursor == model > selection/cursoe is imo secondary to that, > and completely unnecessary. > > Yes, we tried to map text navigation/selection protocol to look most > natural, as if you editing the text in text editor. > And tests which we have is actually telling that we're on the right > way: we've been able to edit the text without having 'text editor' and > without counting characters, but using high-level commands to > cursor/selection. Which is IMO good. > >>> >>> For instance if you want to get the insertion point when clicking on some >>> text view you have to take so many model-unrelated things into account >>> (global transformation, font sizes). >> >> >> I think It can be solve easilly if text model will reflect visual lines of >> text. >> For example, imagine my simple idea where TextView is just list of >> SpanMorph's. When user click on text concrete span morph will handle it >> because TextView is just morph with submorphs (no special behaviour). So >> target SpanMorph should just compute span position under mouse and change >> text model cursor position appropriatelly. Then cursor will announce >> #changed event and CursorMorph will reflect this automatically. >> > > The decision to use spans was to denote a portion of text which has > same attributes, > so a rendering engine can set up all attributes once, at the start of span, > and render all text characters in single pass, without need to do any > other checks for attribute changes. > I don't think representing spans with morphs will be a good idea. > > >>> 3) What about auto wrap behaviour? >>> If you have auto wrap option at text editors you have line width >>> restriction. And you should spit real lines of text to visual lines which >>> satisfed this restriction. And text mode should know about such restriction >>> because any text insertion can require new visual lines creation. >>> I think insertion single line text at span position should be executed by >>> special "restriction object". It should return new characters of span which >>> satisfied that restriction. And it should return new span object (or just >>> remains characters) which will present new visual lines. Then this "remains >>> characters" should be inserted to next span at 0 position. >>> When wrap behavior not needed "restriction object" just inserts new text >>> into current characters at given position and returns result. >> >> >> Just remember two kinds of such line width restrictions: width in pixels and >> width in characters. First is usual text wrapping behaviour when line width >> restricted by view width. Last is when editor wrap lines which contains >100 >> characters for example. >> > > text wrapping is visual/layout information. > The data flow when you rendering text is following: > > (Text) -> (Layout information) -> (Screen) > > The text , as a model , has nothing to do with layout information. > More than that, don't forget about multiple views for same model, > which can have different dimensions and different wrapping rules. So, > it would be bad idea to mix layout information with text model itself. > > -- > Best regards, > Igor Stasenko. >

Nov. 22, 2012

Re: [Pharo-project] when do we go beta?

by Sebastian Sastre

sounds like we are in a less is more stage we always have time for new nice surprises let the incomplete stuff for later keep the great work sebastian o/ On Nov 21, 2012, at 8:58 PM, Esteban Lorenzano wrote: > new class builder is NOT marked for inclusion, I'm sorry (even as a preview) > > On Nov 21, 2012, at 11:56 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > >> >> >> On Wed, Nov 21, 2012 at 11:47 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> >> On 2012-11-21, at 19:41, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >> > >> > On Nov 21, 2012, at 11:37 PM, Mariano Martinez Peck wrote: >> > >> >> +1 for including only NB and then just bug fixes. No new stuff. >> >> So...slots and new classbuilder will be for next release. Same for Opal I guess. >> > >> > No Opal should be in previous as well as Athens. >> > These projects should come back to light. Else this will never happen. >> >> I think that the thing we did with filesystem in 1.4 was good >> - integrate the detached project >> - apply the refactorings during development >> >> then in the next release >> - change tools to use the new infrastructure >> - remove old code >> >> I think we did almost the same with Zinc, no? >> >> >> What about NOT including new class builder nor Opal in 2.0 but as soon as we create the initial repo for 2.1 (or whatever), the first 2 things we do is to integrate them? >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >

Nov. 22, 2012

Re: [Pharo-project] Metacello Why symbolicversion and not simply tagged version:?

by Dale Henrichs

----- Original Message ----- | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> | To: Pharo-project(a)lists.gforge.inria.fr | Sent: Wednesday, November 21, 2012 2:34:36 PM | Subject: Re: [Pharo-project] Metacello Why symbolicversion and not simply tagged version:? | | | On Nov 21, 2012, at 8:16 PM, Dale Henrichs wrote: | | > Doru, | > | > I guess because I don't agree that the following statement would be | > true: | > | > there will never be a regular version named 'stable' | > | > I know that in git I can have a branch named 'stable' and a tag | > named 'stable' and that causes problems ... for me. | > | > Besides, the set of symbolic versions is not restricted to #stable | > and #development ... one could choose to define a symbolic version | > called #default or #'1.0'â¦ | | I would not. I would not, at least right now... But someday, #stable may not be sufficient it may be necessary to reason about "the #stable version of Metacello 1.0 and the #stable version of Metacello 2.0", then #'1.0' and #'2.0' may turn out to be useful ... | I would like that Metacello constraints the space. Because we should | have less option and more structured supported scenarios. I'm not sure that we know the extent of the space quite yet, but for now we have a convention where we are primarily using only the #stable symbolic version so we've successfully avoided a proliferation of symbolic versions which is a good thing ... As I do more work with git I see the linear versions become more like tags of specific git commits with the burden of version management falling onto git instead of Metacello. Then with platform-specific branches in the git repository it becomes possible to use a cross branch tag (a linear version) which may obsolete symbolic versions altogether, but it is way too early in the learning curve with git to tell... | | > I intend for there to be two namespaces the linear version | > namespace and the symbolic version namespace to make a clear | > distinction between the two, because they have different | > semantics. | | Ok it was not clear to me that they have a different semantics. I think it is important that we have a language that differentiates between a linear version '1.0' which refers to a specific set of packages that do not change over time and a symbolic version #stable (or #'1.0') which refers to a family of related versions the members of which may change over time. | | > One shouldn't be surprised that when version #stable of project foo | > is loaded the current version of the project is '1.0' on one day | > and '1.1' on the next. | | How this can be possible? Ok you mean because the guy changed the | stable definition. Exactly ... symbolic versions were invented exactly because the "recommended version" changes over time .... | | > Or when they load #'1.0' that the current version is '1.0-beta.19'. | > | > This distinction is obviously not important to you and I am okay | > with that:) | > | > Dale

Nov. 21, 2012

Re: [Pharo-project] Metacello loading semantics

by Dale Henrichs

Stef, The Thanksgiving holiday is coming up tomorrow and through the weekend ... I promised my wife that I would avoid the computer this weekend since I was away in Argentina for 10 days, but I will probably be able to find a couple of hours poke at an image and try to see where things are falling through the cracks:) Dale ----- Original Message ----- | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> | To: Pharo-project(a)lists.gforge.inria.fr | Sent: Wednesday, November 21, 2012 2:40:17 PM | Subject: Re: [Pharo-project] Metacello loading semantics | | | On Nov 21, 2012, at 8:51 PM, Dale Henrichs wrote: | | > Doru, | > | > The loadDirectives structure is the structure that does the actual | > package load for metacello, so extracting the information from the | > loadDirectives is the correct technique for producing a list of | > packages in load order. From a cursory read of Stefs code he | > appears to be doing it correctly ... atomic/linear loadType is an | > important distinction that has to be taken into account when | > attempting to reproduce the Metacello load behavior without using | > Metacelloâ¦ | | We thought that too but I got a problem with Roassal since it looks | like some classes are not loaded first. | | > Of course in the end, it's the details like which packages/projects | > specifically are causing trouble that will help me figure out | > exactly where things are breaking down. I assume that when | > Metacello does the load, everything gets loaded correctly? | | Well when we use the configuration of Moose (not the flatten one) it | loads: this is the Moose default configuration. | | > If you want me to help build/debug a package flattener for Moose I | > would be glad to help, but I need more detailed information about | > what you are trying to do and why. Also having the actual code to | > look at and a reproducible test case makes addressing issues a ton | > easier...Perhaps making an image available with a workspace doit | > primed for failure is a good first step:) | | The code in MooseReloader on smalltalkhub. I'm going to bed that and | tomorrow I follow lectures so I will explain it to you. | | | | > | > Dale | > | > ----- Original Message ----- | > | From: "Tudor Girba" <tudor(a)tudorgirba.com> | > | To: Pharo-project(a)lists.gforge.inria.fr | > | Sent: Wednesday, November 21, 2012 10:49:12 AM | > | Subject: Re: [Pharo-project] Metacello loading semantics | > | | > | Hi Dale, | > | | > | The question is how to get all packages that will be loaded for a | > | given configuration version in the correct order. We want to | > | obtain | > | that to provide a flattened configuration version based on what | > | is | > | in the image. | > | | > | Cheers, | > | Doru | > | | > | | > | | > | On 21 Nov 2012, at 19:33, Dale Henrichs <dhenrich(a)vmware.com> | > | wrote: | > | | > | > Stef, | > | > | > | > If you need to leverage the multi-package load, you can do that | > | > in | > | > Metacello by using the #atomic loadType in the project method | > | > of | > | > your configuration: | > | > | > | > project | > | > ^ project | > | > ifNil: [ | > | > "Bootstrap Metacello if it is not already loaded" | > | > self class ensureMetacello. | > | > project := self projectClass new projectAttributes: | > | > self | > | > customProjectAttributes. "Create the Metacello | > | > project" | > | > project versionNumberClass: self versionNumberClass. | > | > project class versionConstructorClass on: self | > | > project: | > | > project. "Construct the project" | > | > project loadType: #'atomic'. "change to #atomic if | > | > desired" | > | > project ] | > | > | > | > With #atomic, all of the packages are loaded in one | > | > multi-package | > | > load. with #linear (the default) each package is loaded | > | > individually. | > | > | > | > If you inspect the loadDirectives that are produced by the | > | > #record | > | > message, the load type is encoded in the class of the | > | > directive, | > | > so you can tell whether #linear or #atomic loadTypes are used | > | > in | > | > the configurations... | > | > | > | > Does this help? | > | > | > | > Dale | > | > | > | > ----- Original Message ----- | > | > | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> | > | > | To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr> | > | > | Sent: Saturday, November 17, 2012 11:28:03 AM | > | > | Subject: [Pharo-project] Metacello loading semantics | > | > | | > | > | Hi dale | > | > | | > | > | I implemented a little tool that | > | > | - create a kind of specification (version, package, repo) | > | > | for | > | > | all | > | > | the packages reachable from a configurationOf | > | > | (see below method method | > | > | packagesAndAssociatedRepositoriesFromConfigurationRecord ) | > | > | | > | > | It generates a script looking as follows: | > | > | script3 | > | > | ^ #( | > | > | #('ConfigurationOfFame-TudorGirba.5.mcz' | > | > | 'http://www.squeaksource.com/Fame/' | > | > | 'ConfigurationOfFame' ) | > | > | #('ConfigurationOfMooseAlgos-usmanbhatti.27.mcz' | > | > | 'http://www.squeaksource.com/MooseAlgos/' | > | > | 'ConfigurationOfMooseAlgos' ) | > | > | #('ConfigurationOfGlamour-TudorGirba.98.mcz' | > | > | 'http://www.squeaksource.com/Glamour/' | > | > | 'ConfigurationOfGlamour' | > | > | ) | > | > | #('ConfigurationOfDSM-AlexandreBergel.56.mcz' | > | > | 'http://www.squeaksource.com/dsm/' 'ConfigurationOfDSM' | > | > | ) | > | > | #('ConfigurationOfKumpel-AlexandreBergel.3.mcz' | > | > | 'http://www.squeaksource.com/Kumpel/' | > | > | 'ConfigurationOfKumpel' ) | > | > | #('ConfigurationOfSmallDudâ¦â¦â¦â¦.) | > | > | | > | > | - I keep the order given by Metacello. I extract the | > | > | information | > | > | as | > | > | follows: | > | > | | > | > | packagesAndAssociatedRepositoriesFromConfigurationRecord: | > | > | aConfigurationRecord | > | > | "| record | | > | > | record := ((Smalltalk globals at: #ConfigurationOfMoose) | > | > | project | > | > | version: 'default') ignoreImage: true; record. | > | > | self | > | > | packagesAndAssociatedRepositoriesFromConfigurationRecord: | > | > | record | > | > | " | > | > | | > | > | | pkgs | | > | > | pkgs := OrderedCollection new. | > | > | aConfigurationRecord loadDirective packageDirectivesDo: | > | > | [:directive | | > | > | pkgs add: | > | > | {directive spec name, '*'. | > | > | (self removeCache: directive spec workingCopy | > | > | repositoryGroup repositories) anyOne | > | > | locationWithTrailingSlash} ]. | > | > | ^ pkgs | > | > | | > | > | | > | > | - then I try to load the package as follows: | > | > | | > | > | flatVersion47: spec | > | > | <version: '4.7-flat'> | > | > | | > | > | spec for: #common do: [ | > | > | self populateSpec: spec with: self script3 ] | > | > | | > | > | I load them doing | > | > | (ConfigurationOfMoose project version: '4.7-flat') load | > | > | Now It does not work because after fetching all the packages, | > | > | the | > | > | system complain that some classes that will be loaded later | > | > | are | > | > | not | > | > | present. | > | > | I imagine that you use Gofer and that Gofer does not use the | > | > | merging | > | > | semantics of MC over multiple projects (that you can have | > | > | multiple | > | > | package in any order and that the classes get loaded - as I | > | > | use | > | > | it | > | > | for the scriptLoader and below). | > | > | | > | > | | > | > | - before I was doing it by doing a diff between the pharo | > | > | package | > | > | and the one loaded and I was loading the specification after | > | > | installing the repository | > | > | and the working copies using the MCVersionLoader and it | > | > | worked I | > | > | could reload completely Moose! | > | > | | > | > | | > | > | load: aCollectionOfPackageString | > | > | "self new | > | > | load: #( 'Famix-C-TudorGirba.15' | > | > | 'Famix-Core-NicolasAnquetil.201'))" | > | > | | > | > | | loader | | > | > | loader := MCVersionLoader new. | > | > | (self newerVersionsIn: aCollectionOfPackageString) | > | > | do: [ :fn | loader addVersion: (self | > | > | loadVersionFromFileNamed: | > | > | fn). | > | > | (Delay forSeconds: 2) wait.] | > | > | displayingProgress: 'Adding versions...'. | > | > | loader hasVersions ifTrue: [loader load]. | > | > | | > | > | | > | > | So my question is | > | > | - Does the packageDirectivesDo: provide an order that I can | > | > | use | > | > | to | > | > | load package with the gofer-load on project at a time? | > | > | May be my code does not keep the same order but I payed | > | > | attention to | > | > | this point. I will check that further. | > | > | | > | > | - may be I could extend Gofer to support multiple project | > | > | merge | > | > | loading. | > | > | | > | > | So right now I'm stuck and this is sad because freezing a | > | > | complex | > | > | configuration is really needed. | > | > | | > | > | Stef | > | > | | > | > | | > | > | | > | > | | > | > | | > | > | | > | > | > | | > | -- | > | www.tudorgirba.com | > | | > | "It's not what we do that matters most, it's how we do it." | > | | > | | > | | > |

Nov. 21, 2012

Re: [Pharo-project] when do we go beta?

by Esteban Lorenzano

new class builder is NOT marked for inclusion, I'm sorry (even as a preview) On Nov 21, 2012, at 11:56 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > On Wed, Nov 21, 2012 at 11:47 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > On 2012-11-21, at 19:41, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > > > > On Nov 21, 2012, at 11:37 PM, Mariano Martinez Peck wrote: > > > >> +1 for including only NB and then just bug fixes. No new stuff. > >> So...slots and new classbuilder will be for next release. Same for Opal I guess. > > > > No Opal should be in previous as well as Athens. > > These projects should come back to light. Else this will never happen. > > I think that the thing we did with filesystem in 1.4 was good > - integrate the detached project > - apply the refactorings during development > > then in the next release > - change tools to use the new infrastructure > - remove old code > > I think we did almost the same with Zinc, no? > > > What about NOT including new class builder nor Opal in 2.0 but as soon as we create the initial repo for 2.1 (or whatever), the first 2 things we do is to integrate them? > > > -- > Mariano > http://marianopeck.wordpress.com >

Nov. 21, 2012

Re: [Pharo-project] when do we go beta?

by Esteban Lorenzano

my proposal so far is: - prepare the vms as "NB ready" (I was planning to work on that next week, using the new infraestructure) - include NB as "ready to use" - include Opal as "preview" No more integrations for 2.0. We will be able to load Athens (since VMs and image will be prepared) with just a simple Metacello configuration. I don't know if including it as "preview" (like opal) Igor, what do you think? I need all next week to prepare that (with Marcus assistance, of course :P)... Are we ok with that? Esteban ps: If we don't go to beta next week will be really difficult to release in February (as is stipulated now) On Nov 21, 2012, at 11:47 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > On 2012-11-21, at 19:41, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> >> On Nov 21, 2012, at 11:37 PM, Mariano Martinez Peck wrote: >> >>> +1 for including only NB and then just bug fixes. No new stuff. >>> So...slots and new classbuilder will be for next release. Same for Opal I guess. >> >> No Opal should be in previous as well as Athens. >> These projects should come back to light. Else this will never happen. > > I think that the thing we did with filesystem in 1.4 was good > - integrate the detached project > - apply the refactorings during development > > then in the next release > - change tools to use the new infrastructure > - remove old code > > I think we did almost the same with Zinc, no?

Nov. 21, 2012

Re: [Pharo-project] when do we go beta?

by Mariano Martinez Peck

On Wed, Nov 21, 2012 at 11:47 PM, Camillo Bruni <camillobruni(a)gmail.com>wrote: > > On 2012-11-21, at 19:41, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > > > > > On Nov 21, 2012, at 11:37 PM, Mariano Martinez Peck wrote: > > > >> +1 for including only NB and then just bug fixes. No new stuff. > >> So...slots and new classbuilder will be for next release. Same for Opal > I guess. > > > > No Opal should be in previous as well as Athens. > > These projects should come back to light. Else this will never happen. > > I think that the thing we did with filesystem in 1.4 was good > - integrate the detached project > - apply the refactorings during development > > then in the next release > - change tools to use the new infrastructure > - remove old code > > I think we did almost the same with Zinc, no? > What about NOT including new class builder nor Opal in 2.0 but as soon as we create the initial repo for 2.1 (or whatever), the first 2 things we do is to integrate them? -- Mariano http://marianopeck.wordpress.com

Nov. 21, 2012

Re: [Pharo-project] when do we go beta?

by Camillo Bruni

On 2012-11-21, at 19:41, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Nov 21, 2012, at 11:37 PM, Mariano Martinez Peck wrote: > >> +1 for including only NB and then just bug fixes. No new stuff. >> So...slots and new classbuilder will be for next release. Same for Opal I guess. > > No Opal should be in previous as well as Athens. > These projects should come back to light. Else this will never happen. I think that the thing we did with filesystem in 1.4 was good - integrate the detached project - apply the refactorings during development then in the next release - change tools to use the new infrastructure - remove old code I think we did almost the same with Zinc, no?

Nov. 21, 2012

Re: [Pharo-project] when do we go beta?

by StÃ©phane Ducasse

On Nov 21, 2012, at 11:37 PM, Mariano Martinez Peck wrote: > +1 for including only NB and then just bug fixes. No new stuff. > So...slots and new classbuilder will be for next release. Same for Opal I guess. No Opal should be in previous as well as Athens. These projects should come back to light. Else this will never happen. Stef

Nov. 21, 2012

Re: [Pharo-project] Metacello loading semantics

by StÃ©phane Ducasse

On Nov 21, 2012, at 8:51 PM, Dale Henrichs wrote: > Doru, > > The loadDirectives structure is the structure that does the actual package load for metacello, so extracting the information from the loadDirectives is the correct technique for producing a list of packages in load order. From a cursory read of Stefs code he appears to be doing it correctly ... atomic/linear loadType is an important distinction that has to be taken into account when attempting to reproduce the Metacello load behavior without using Metacelloâ¦ We thought that too but I got a problem with Roassal since it looks like some classes are not loaded first. > Of course in the end, it's the details like which packages/projects specifically are causing trouble that will help me figure out exactly where things are breaking down. I assume that when Metacello does the load, everything gets loaded correctly? Well when we use the configuration of Moose (not the flatten one) it loads: this is the Moose default configuration. > If you want me to help build/debug a package flattener for Moose I would be glad to help, but I need more detailed information about what you are trying to do and why. Also having the actual code to look at and a reproducible test case makes addressing issues a ton easier...Perhaps making an image available with a workspace doit primed for failure is a good first step:) The code in MooseReloader on smalltalkhub. I'm going to bed that and tomorrow I follow lectures so I will explain it to you. > > Dale > > ----- Original Message ----- > | From: "Tudor Girba" <tudor(a)tudorgirba.com> > | To: Pharo-project(a)lists.gforge.inria.fr > | Sent: Wednesday, November 21, 2012 10:49:12 AM > | Subject: Re: [Pharo-project] Metacello loading semantics > | > | Hi Dale, > | > | The question is how to get all packages that will be loaded for a > | given configuration version in the correct order. We want to obtain > | that to provide a flattened configuration version based on what is > | in the image. > | > | Cheers, > | Doru > | > | > | > | On 21 Nov 2012, at 19:33, Dale Henrichs <dhenrich(a)vmware.com> wrote: > | > | > Stef, > | > > | > If you need to leverage the multi-package load, you can do that in > | > Metacello by using the #atomic loadType in the project method of > | > your configuration: > | > > | > project > | > ^ project > | > ifNil: [ > | > "Bootstrap Metacello if it is not already loaded" > | > self class ensureMetacello. > | > project := self projectClass new projectAttributes: self > | > customProjectAttributes. "Create the Metacello project" > | > project versionNumberClass: self versionNumberClass. > | > project class versionConstructorClass on: self project: > | > project. "Construct the project" > | > project loadType: #'atomic'. "change to #atomic if > | > desired" > | > project ] > | > > | > With #atomic, all of the packages are loaded in one multi-package > | > load. with #linear (the default) each package is loaded > | > individually. > | > > | > If you inspect the loadDirectives that are produced by the #record > | > message, the load type is encoded in the class of the directive, > | > so you can tell whether #linear or #atomic loadTypes are used in > | > the configurations... > | > > | > Does this help? > | > > | > Dale > | > > | > ----- Original Message ----- > | > | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > | > | To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr> > | > | Sent: Saturday, November 17, 2012 11:28:03 AM > | > | Subject: [Pharo-project] Metacello loading semantics > | > | > | > | Hi dale > | > | > | > | I implemented a little tool that > | > | - create a kind of specification (version, package, repo) for > | > | all > | > | the packages reachable from a configurationOf > | > | (see below method method > | > | packagesAndAssociatedRepositoriesFromConfigurationRecord ) > | > | > | > | It generates a script looking as follows: > | > | script3 > | > | ^ #( > | > | #('ConfigurationOfFame-TudorGirba.5.mcz' > | > | 'http://www.squeaksource.com/Fame/' 'ConfigurationOfFame' ) > | > | #('ConfigurationOfMooseAlgos-usmanbhatti.27.mcz' > | > | 'http://www.squeaksource.com/MooseAlgos/' > | > | 'ConfigurationOfMooseAlgos' ) > | > | #('ConfigurationOfGlamour-TudorGirba.98.mcz' > | > | 'http://www.squeaksource.com/Glamour/' > | > | 'ConfigurationOfGlamour' > | > | ) > | > | #('ConfigurationOfDSM-AlexandreBergel.56.mcz' > | > | 'http://www.squeaksource.com/dsm/' 'ConfigurationOfDSM' ) > | > | #('ConfigurationOfKumpel-AlexandreBergel.3.mcz' > | > | 'http://www.squeaksource.com/Kumpel/' > | > | 'ConfigurationOfKumpel' ) > | > | #('ConfigurationOfSmallDudâ¦â¦â¦â¦.) > | > | > | > | - I keep the order given by Metacello. I extract the information > | > | as > | > | follows: > | > | > | > | packagesAndAssociatedRepositoriesFromConfigurationRecord: > | > | aConfigurationRecord > | > | "| record | > | > | record := ((Smalltalk globals at: #ConfigurationOfMoose) > | > | project > | > | version: 'default') ignoreImage: true; record. > | > | self > | > | packagesAndAssociatedRepositoriesFromConfigurationRecord: > | > | record > | > | " > | > | > | > | | pkgs | > | > | pkgs := OrderedCollection new. > | > | aConfigurationRecord loadDirective packageDirectivesDo: > | > | [:directive | > | > | pkgs add: > | > | {directive spec name, '*'. > | > | (self removeCache: directive spec workingCopy > | > | repositoryGroup repositories) anyOne > | > | locationWithTrailingSlash} ]. > | > | ^ pkgs > | > | > | > | > | > | - then I try to load the package as follows: > | > | > | > | flatVersion47: spec > | > | <version: '4.7-flat'> > | > | > | > | spec for: #common do: [ > | > | self populateSpec: spec with: self script3 ] > | > | > | > | I load them doing > | > | (ConfigurationOfMoose project version: '4.7-flat') load > | > | Now It does not work because after fetching all the packages, the > | > | system complain that some classes that will be loaded later are > | > | not > | > | present. > | > | I imagine that you use Gofer and that Gofer does not use the > | > | merging > | > | semantics of MC over multiple projects (that you can have > | > | multiple > | > | package in any order and that the classes get loaded - as I use > | > | it > | > | for the scriptLoader and below). > | > | > | > | > | > | - before I was doing it by doing a diff between the pharo > | > | package > | > | and the one loaded and I was loading the specification after > | > | installing the repository > | > | and the working copies using the MCVersionLoader and it worked I > | > | could reload completely Moose! > | > | > | > | > | > | load: aCollectionOfPackageString > | > | "self new > | > | load: #( 'Famix-C-TudorGirba.15' > | > | 'Famix-Core-NicolasAnquetil.201'))" > | > | > | > | | loader | > | > | loader := MCVersionLoader new. > | > | (self newerVersionsIn: aCollectionOfPackageString) > | > | do: [ :fn | loader addVersion: (self loadVersionFromFileNamed: > | > | fn). > | > | (Delay forSeconds: 2) wait.] > | > | displayingProgress: 'Adding versions...'. > | > | loader hasVersions ifTrue: [loader load]. > | > | > | > | > | > | So my question is > | > | - Does the packageDirectivesDo: provide an order that I can use > | > | to > | > | load package with the gofer-load on project at a time? > | > | May be my code does not keep the same order but I payed > | > | attention to > | > | this point. I will check that further. > | > | > | > | - may be I could extend Gofer to support multiple project merge > | > | loading. > | > | > | > | So right now I'm stuck and this is sad because freezing a complex > | > | configuration is really needed. > | > | > | > | Stef > | > | > | > | > | > | > | > | > | > | > | > | > | > > | > | -- > | www.tudorgirba.com > | > | "It's not what we do that matters most, it's how we do it." > | > | > | >

Nov. 21, 2012