May 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] ConfigurationOfPharo and OmniBrowser

by Alexandre Bergel

> I'm actually working through this scenario right now. Hi Dale! Any progress? Cheers, Alexandre > Moving OB BEFORE AutomaticMethodCategorizer will load the proper > version of OB ... with this load order the older version of OB > shouldn't be loaded by AutomaticMethodCategorizer (this is the area > where I suspected a bug in 1.0-beta.26 that is fixed in 1.0-beta. > 26.1). > > However, I have run into an issue with SHOUT using the deprecated > API and then I ran into an MNU in another part of the system (doing > initialization) so I'm trying to determine if this is a problem for > Metacello or not ... when I have characterized the issues, I'll send > mail... > > Dale > > > ----- "Alexandre Bergel" <alexandre(a)bergel.eu> wrote: > > | > Thanks Dale for the dedicated answer. I understood you > correclty? If > | > | > I change baseline11: and I put > | > > | > project: 'AutomaticMethodCategorizer' > | > with: > | > [ spec > | > className: > | > 'ConfigurationOfAutomaticMethodCategorizer'; > | > file: > | > 'ConfigurationOfAutomaticMethodCategorizer'; > | > repository: > | 'http://www.squeaksource.com/MetacelloRepository' > | > ]; > | > > | > > | > AFTER > | > > | > project: 'OB Dev' > | > with: > | > [ spec > | > className: > | > 'ConfigurationOfOmniBrowser'; > | > loads: #('Dev'); > | > file: > 'ConfigurationOfOmniBrowser'; > | > repository: > | 'http://www.squeaksource.com/MetacelloRepository' > | > ]; > | > > | > > | > then it should work ok ? > | > | I understand that if you do this, then the version 1.1.3 of > | Omnibrowser will be loaded, then AutomaticMethodCategorizer will > load > | > | the old version of OB. > | > | I think that ConfigurationOfAutomaticMethodCategorizer needs to be > | updated. > | I work on it now... > | > | Cheers, > | Alexandre > | > | > > | > > | > > | > This implies that ConfigurationOfAutomaticMethodCategorizer will > not > | > | > load correctly into Pharo 1.1, so the solution is to create a new > | > version ConfigurationOfAutomaticMethodCategorizer that will load > | > into Pharo 1.1 (i.e. referencing version 1.1.3 of > | > ConfigurationOfOmniBrowser) and then update ConfigurationOfPharo > | > accordingly... > | > > | > yes...the problem is that you have to do that in all the confs > that > | > | > points to OB. > | > > | > ..... > | > > | > > | > The nesting level for '1.1.3 [ConfigurationOfOmniBrowser]' and > '1.1 > | > | > [ConfigurationOfAutomaticMethodCategorizer]' are the same which > | > means that they are both referenced in '1.1 > [ConfigurationOfPharo]'. > | > | > That was enough to solve this particular problem, but in an > | > Inspector, you can dive into the directives themselves and > actually > | > | > get to the MetacelloSpec that was used to create the directive... > | > > | > > | > > | > Here is what I don't understand. If you have that directive, and > you > | > | > have ALL that information, can't you guess that if you need to > load > | > | > the N version of a package and then the version M, where M > N, > then > | > | > you can skip to load N and just load M directly ? > | > > | > In this example, can you DO NOT load OmniBrowser-lr.458 as you > know > | > | > that after you will load OmniBrowser-lr.469 ? > | > Or maybe directly about conf: Do not load 1.1 > | > [ConfigurationOfOmniBrowser] if you know that then you will need > | > | > to load 1.1.3 [ConfigurationOfOmniBrowser] > | > > | > Thanks a lot for the explanation dale! > | > > | > mariano > | > > | > _______________________________________________ > | > Pharo-project mailing list > | > Pharo-project(a)lists.gforge.inria.fr > | > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- > project > | > | -- > | _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > | Alexandre Bergel http://www.bergel.eu > | ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 5, 2010

[Pharo-project] ESUG call for contribution + student volunteer programs

by StÃ©phane Ducasse

please distribute widely 18th International Smalltalk Joint Conference - Call for Contributions Barcelona, Spain September 13 - 17, 2010; Camp Smalltalk September 11-12 http://www.esug.org/conferences/2010/ This call includes: Developer program Free ESUG tickets Business day 16th of September (sponsored by Cincom Smalltalk) International Workshop http://www.esug.org/Conferences/2010/International+Workshop+on+Smalltalk+Te… Student Volunteer http://www.esug.org/Conferences/2010/Student+Volunteers+program Camp Smalltalk 11-12 September 2010 ---------------------------------------------------------------------- For the past 18 years, the European Smalltalk User Group (ESUG) has organised the International Smalltalk Conference, a lively forum on cutting edge software technologies that attract people from both academia and industry for a whole week. The attendees are both engineers using Smalltalk in business and students and teachers using Smalltalk both for research and didactic purposes. As every year, this year's edition of the largest European Smalltalk event will include the regular Smalltalk developers conference with renowned invited speakers, a Smalltalk camp that proves fruitful for interactions and discussions. Besides, this year will be held the - 6th edition of the Innovation Technology Awards where prizes will be awarded to authors of best pieces of Smalltalk-related projects - an international workshop on Smalltalk and dynamic languages http://www.esug.org/Conferences/2010/International+Workshop+on+Smalltalk+Te… * New this year: - There will be a business day: thursday 16th of September 2010. The focus will be on "Agile Development Processes and Smalltalk" - ESUG will offer 10 free entrance tickets. To get a free ticket you should send a mail to the esug board (board(a)esug.org) Subject: [ESUG 2010 Free entrance] + your name And you should write a small motivation. You can support the ESUG conference in many different ways: * Sponsor the conference. New sponsoring packages are described at http://www.esug.org/supportesug/becomeasponsor/ * Submit a talk, a software or a paper to one of the events. See below. * Attend the conference. We'd like to beat the previous record of attendance (156 participants at Brest and 170 people at Amsterdam)! * Students can get free registration and hosting if they enroll into the the Student Volunteers program. See below. Developers Forum: International Smalltalk Developers Conference ------------------------------------------------------------------------ This year we are looking for YOUR experience on using Smalltalk. In addition, we are looking for tutorials. The list of topics includes, but is not limited to the following: * XP practices * Development tools * Experience reports * Model driven development * Web development * Team management * Meta-Modeling * Security * New libraries & frameworks * Educational material * Embedded systems and robotics * SOA and Web services * Interaction with other programming languages Submissions due on 1 July 2010 Notification of acceptance on 15 of July 2010 More information at http://www.esug.org/conferences/2010 How to submit? ------------------ Pay attention: the places are limited so do not wait till the last minute to apply. Prospective presenters should submit a request to board(a)esug.org AND stephane.ducasse(a)free.fr following the template below. Please use this template since the emails will be automatically processed! Subject: [ESUG 2010 Developers] + your name First Name: Last Name: Email where you can always be reached: Title: Abstract: Bio: Any presentation not respecting this form will be discarded automatically Innovation Technology Award ------------------------------------------------------------------------ We are proud to announce the 6th Innovation Technology Awards. The top 3 teams with the most innovative software will receive, respectively, 500 Euros, 300 Euros and 200 Euros during an awards ceremony at the conference. Developers of any Smalltalk-based software are welcome to compete. This year we will request 3-5min videos. More information at http://www.esug.org/Conferences/2010/Innovation+Technology+Awards Student Volunteer Program ------------------------------------------------------------------------ If you are a student wanting to attend ESUG, have you considered being a student volunteer? Student volunteers help keep the conference running smoothly; in return, they have free accommodations, while still having most of the time to enjoy the conference. More information at http://www.esug.org/conferences/2010 http://www.esug.org/Conferences/2010/Student+Volunteers+program We hope to see you there and have fun together. Ze ESUG board_______________________________________________ Board mailing list Board(a)lists.esug.org

May 5, 2010

Re: [Pharo-project] Help System

by StÃ©phane Ducasse

Yes and I want the same for tests. - we get better tests - we get better documentation stef On May 5, 2010, at 11:42 AM, Lukas Renggli wrote: > Yes, I imagine something along ... > > PPParser class>>helpOn: aBuilder > <help> > > aBuilder newBook: [ :book | > book > title: 'PetitParser'; > newPage: [ :page | page title: 'Tutorial'; contents: self blogArticle ]; > newChapter: [ :chap | chap title: 'Operator API'; methodComments: > PPParser selectors in: PPParser ]; > newChapter: [ :chap | chap title: 'Parser Classes'; classComments: > PPParser withAllSubclasses ] ] > > This allows me to assemble the help from things that I have already > written anyway. It does not introduce new dependencies and is small > and concise. > > Lukas > > On 5 May 2010 11:24, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> Lukas >> >> I agree with you. Now my point was let us learn >> there is a builder that can use pragma and this is the one we should use. >> See my mails and the answers of torsten. >> >> What I would love to have is >> - HelpSystemBuilder that collect some class comments and tests >> based on a given pragma. >> >> Alain? Lukas? Torsten? Other? what could be a nice pragma for a Sunit >> >> >> testAbsoluteAuthority >> "self debug: #testAbsoluteAuthority" >> >> <test: #URI about: 'absolute uri with authority' tag: #(network )> >> >> | uri absoluteURIString | >> "An absolute URI with authority. An absolute URI starts with a scheme:" >> absoluteURIString := 'http://www.pharo-project.org'. >> uri := URI fromString: absoluteURIString. >> self assert: (uri asString = absoluteURIString). >> self assert: (uri isAbsolute). >> self assert: (uri authority asString = 'www.pharo-project.org'). >> self deny: (uri isOpaque). >> >> >> Then now we could use help system to force us to write better tests. >> >> >> Stef >> >> >>> I think it is a design flaw that the help system doesn't make use of >>> extensibility in the spirit of the new preference system, the >>> extensible menus, or the metacello configurations. They all don't have >>> external dependencies and load fine into any image. >>> >>> Being forced to have strong references to the HelpSystem package (with >>> subclasses and class references) makes it impossible to just include >>> some documentation into a package, without introducing a dependency >>> onto the HelpSystem. This doesn't encourage me at all to provide some >>> quick documentation (e.g. for Gofer, PetitParser, RB, OB, ...), >>> because I would need to create separate packages. >>> >>> For deployment I usually use kernel images, or core images with >>> unnecessary code unloaded (tests, examples, help system, ...). With >>> the current setup I cannot just include some documentation into a core >>> package without being forced to package it separately. >>> >>> Lukas >>> >>> -- >>> Lukas Renggli >>> www.lukas-renggli.ch >>> >>> _______________________________________________ >>> 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 >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 5, 2010

Re: [Pharo-project] Help System

by Tudor Girba

+1 Doru On 5 May 2010, at 11:42, Lukas Renggli wrote: > Yes, I imagine something along ... > > PPParser class>>helpOn: aBuilder > <help> > > aBuilder newBook: [ :book | > book > title: 'PetitParser'; > newPage: [ :page | page title: 'Tutorial'; contents: self > blogArticle ]; > newChapter: [ :chap | chap title: 'Operator API'; methodComments: > PPParser selectors in: PPParser ]; > newChapter: [ :chap | chap title: 'Parser Classes'; classComments: > PPParser withAllSubclasses ] ] > > This allows me to assemble the help from things that I have already > written anyway. It does not introduce new dependencies and is small > and concise. > > Lukas > > On 5 May 2010 11:24, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: >> Lukas >> >> I agree with you. Now my point was let us learn >> there is a builder that can use pragma and this is the one we >> should use. >> See my mails and the answers of torsten. >> >> What I would love to have is >> - HelpSystemBuilder that collect some class comments and tests >> based on a given pragma. >> >> Alain? Lukas? Torsten? Other? what could be a nice pragma for a Sunit >> >> >> testAbsoluteAuthority >> "self debug: #testAbsoluteAuthority" >> >> <test: #URI about: 'absolute uri with authority' tag: >> #(network )> >> >> | uri absoluteURIString | >> "An absolute URI with authority. An absolute URI starts with >> a scheme:" >> absoluteURIString := 'http://www.pharo-project.org'. >> uri := URI fromString: absoluteURIString. >> self assert: (uri asString = absoluteURIString). >> self assert: (uri isAbsolute). >> self assert: (uri authority asString = 'www.pharo- >> project.org'). >> self deny: (uri isOpaque). >> >> >> Then now we could use help system to force us to write better tests. >> >> >> Stef >> >> >>> I think it is a design flaw that the help system doesn't make use of >>> extensibility in the spirit of the new preference system, the >>> extensible menus, or the metacello configurations. They all don't >>> have >>> external dependencies and load fine into any image. >>> >>> Being forced to have strong references to the HelpSystem package >>> (with >>> subclasses and class references) makes it impossible to just include >>> some documentation into a package, without introducing a dependency >>> onto the HelpSystem. This doesn't encourage me at all to provide >>> some >>> quick documentation (e.g. for Gofer, PetitParser, RB, OB, ...), >>> because I would need to create separate packages. >>> >>> For deployment I usually use kernel images, or core images with >>> unnecessary code unloaded (tests, examples, help system, ...). With >>> the current setup I cannot just include some documentation into a >>> core >>> package without being forced to package it separately. >>> >>> Lukas >>> >>> -- >>> Lukas Renggli >>> www.lukas-renggli.ch >>> >>> _______________________________________________ >>> 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 >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > 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 "In a world where everything is moving ever faster, one might have better chances to win by moving slower."

May 5, 2010

Re: [Pharo-project] Help System

by Lukas Renggli

Yes, I imagine something along ... PPParser class>>helpOn: aBuilder <help> aBuilder newBook: [ :book | book title: 'PetitParser'; newPage: [ :page | page title: 'Tutorial'; contents: self blogArticle ]; newChapter: [ :chap | chap title: 'Operator API'; methodComments: PPParser selectors in: PPParser ]; newChapter: [ :chap | chap title: 'Parser Classes'; classComments: PPParser withAllSubclasses ] ] This allows me to assemble the help from things that I have already written anyway. It does not introduce new dependencies and is small and concise. Lukas On 5 May 2010 11:24, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Lukas > > I agree with you. Now my point was let us learn > there is a builder that can use pragma and this is the one we should use. > See my mails and the answers of torsten. > > What I would love to have is > Â Â Â Â - HelpSystemBuilder that collect some class comments and tests > Â Â Â Â based on a given pragma. > > Alain? Lukas? Torsten? Other? what could be a nice pragma for a Sunit > > > testAbsoluteAuthority > Â Â Â Â "self debug: #testAbsoluteAuthority" > > Â Â Â Â <test: #URI about: 'absolute uri with authority' tag: #(network )> > > Â Â Â Â | uri absoluteURIString | > Â Â Â Â "An absolute URI with authority. An absolute URI starts with a scheme:" > Â Â Â Â absoluteURIString := 'http://www.pharo-project.org'. > Â Â Â Â uri := URI fromString: absoluteURIString. > Â Â Â Â self assert: (uri asString = absoluteURIString). > Â Â Â Â self assert: (uri isAbsolute). > Â Â Â Â self assert: (uri authority asString = 'www.pharo-project.org'). > Â Â Â Â self deny: (uri isOpaque). > > > Then now we could use help system to force us to write better tests. > > > Stef > > >> I think it is a design flaw that the help system doesn't make use of >> extensibility in the spirit of the new preference system, the >> extensible menus, or the metacello configurations. They all don't have >> external dependencies and load fine into any image. >> >> Being forced to have strong references to the HelpSystem package (with >> subclasses and class references) makes it impossible to just include >> some documentation into a package, without introducing a dependency >> onto the HelpSystem. This doesn't encourage me at all to provide some >> quick documentation (e.g. for Gofer, PetitParser, RB, OB, ...), >> because I would need to create separate packages. >> >> For deployment I usually use kernel images, or core images with >> unnecessary code unloaded (tests, examples, help system, ...). With >> the current setup I cannot just include some documentation into a core >> package without being forced to package it separately. >> >> Lukas >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> >> _______________________________________________ >> 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 > -- Lukas Renggli www.lukas-renggli.ch

May 5, 2010

Re: [Pharo-project] Help System

by StÃ©phane Ducasse

Lukas I agree with you. Now my point was let us learn there is a builder that can use pragma and this is the one we should use. See my mails and the answers of torsten. What I would love to have is - HelpSystemBuilder that collect some class comments and tests based on a given pragma. Alain? Lukas? Torsten? Other? what could be a nice pragma for a Sunit testAbsoluteAuthority "self debug: #testAbsoluteAuthority" <test: #URI about: 'absolute uri with authority' tag: #(network )> | uri absoluteURIString | "An absolute URI with authority. An absolute URI starts with a scheme:" absoluteURIString := 'http://www.pharo-project.org'. uri := URI fromString: absoluteURIString. self assert: (uri asString = absoluteURIString). self assert: (uri isAbsolute). self assert: (uri authority asString = 'www.pharo-project.org'). self deny: (uri isOpaque). Then now we could use help system to force us to write better tests. Stef > I think it is a design flaw that the help system doesn't make use of > extensibility in the spirit of the new preference system, the > extensible menus, or the metacello configurations. They all don't have > external dependencies and load fine into any image. > > Being forced to have strong references to the HelpSystem package (with > subclasses and class references) makes it impossible to just include > some documentation into a package, without introducing a dependency > onto the HelpSystem. This doesn't encourage me at all to provide some > quick documentation (e.g. for Gofer, PetitParser, RB, OB, ...), > because I would need to create separate packages. > > For deployment I usually use kernel images, or core images with > unnecessary code unloaded (tests, examples, help system, ...). With > the current setup I cannot just include some documentation into a core > package without being forced to package it separately. > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 5, 2010

Re: [Pharo-project] Help System

by Lukas Renggli

I think it is a design flaw that the help system doesn't make use of extensibility in the spirit of the new preference system, the extensible menus, or the metacello configurations. They all don't have external dependencies and load fine into any image. Being forced to have strong references to the HelpSystem package (with subclasses and class references) makes it impossible to just include some documentation into a package, without introducing a dependency onto the HelpSystem. This doesn't encourage me at all to provide some quick documentation (e.g. for Gofer, PetitParser, RB, OB, ...), because I would need to create separate packages. For deployment I usually use kernel images, or core images with unnecessary code unloaded (tests, examples, help system, ...). With the current setup I cannot just include some documentation into a core package without being forced to package it separately. Lukas -- Lukas Renggli www.lukas-renggli.ch

May 5, 2010

Re: [Pharo-project] gettext package

by Philippe Marschall

On 04/29/2010 10:55 PM, Hilaire Fernandes wrote: > I have move in a Gettext package in PharoInbox classes for gettext > support. Do not expect it to work. Some of the classes there, are just > moved from former categories in pharo System-Localization and > Multilingual other are coming from Etoys. > > I have not yet test to load it in a fresh image. I'm interested in this for Seaside. I have a couple of notes: - Why do you move LocaleID from System-Localization to Gettext? - Do we really need GetTextExporter2 if you don't have a GetTextExporter1? - Why is there a #translate:in: if it's empty? The protocol I have in mind for Seaside is something like: html translate: html translate:to: What would the way to hook into GetTextExporter(2) to make it pick that up? Cheers Philippe

May 5, 2010

Re: [Pharo-project] ConfigurationOfPharo and OmniBrowser

by Dale Henrichs

Mariano, I think that #linear is the best default loadType...#atomic should only be used when it is really needed... I think that for 1.1 new versions of "all of the configs" will need to be done eventually since they need to load into a 1.1 Pharo Core independently without requiring one to disable the deprecated warning... Since 1.1 is still unstable, it might make sense to wait until _all_ of the issues get resolved so we don't end up spinning multiple versions for 1.1 compatibility reasons... You could put a preload doit that disables deprecation warnings (if they are enabled) and a postload doit that reenables deprecation warnings at the end of the load .... this would only be a temporary measure until 1.1 stabilizes... With my short experience using 1.1 I cannot imagine that anyone would _enable_ deprecation warnings and expect anything to work without lots and lots and lots of proceeds:) Dale ----- "Mariano Martinez Peck" <marianopeck(a)gmail.com> wrote: | On Tue, May 4, 2010 at 9:23 PM, Dale Henrichs | <dale.henrichs(a)gemstone.com>wrote: | | > | > ----- "Mariano Martinez Peck" <marianopeck(a)gmail.com> wrote: | > | > | > | > The nesting level for '1.1.3 [ConfigurationOfOmniBrowser]' and | '1.1 | > | > [ConfigurationOfAutomaticMethodCategorizer]' are the same which | > | means that | > | > they are both referenced in '1.1 [ConfigurationOfPharo]'. That | was | > | enough to | > | > solve this particular problem, but in an Inspector, you can | dive | > | into the | > | > directives themselves and actually get to the MetacelloSpec that | was | > | used to | > | > create the directive... | > | > | > | > | > | > | > | Here is what I don't understand. If you have that directive, and | you | > | have | > | ALL that information, can't you guess that if you need to load the | N | > | version | > | of a package and then the version M, where M > N, then you can | skip to | > | load | > | N and just load M directly ? | > | | > | In this example, can you DO NOT load OmniBrowser-lr.458 as you | know | > | that | > | after you will load OmniBrowser-lr.469 ? | > | Or maybe directly about conf: Do not load 1.1 | > | [ConfigurationOfOmniBrowser] if you know that then you will need | to | > | load | > | 1.1.3 [ConfigurationOfOmniBrowser] | > | > Mariano, | > | > If you were using #atomic loads then what you are suggesting would | happen | > ... Metacello would recognize that OmniBrowser-lr.469 was later and | would | > use that instead of the older mcz file. | > | > With #linear loads it isn't necessarily safe to substitute a newer | version | > of an mcz file earlier into the load sequence, because the newer | version may | > have dependencies that wouldn't necessarily be satisfied this early | in the | > load sequence...The only safe way is to explicitly move the project | earlier | > in the sequence. | > | > | Ahhhh those ones ;) Now is much clear. Thanks Dale. I forgot sbout | those | friends. Now I wonder.... if we select #linear is cool because all | the | packages will be loaded and initialized one after one. But we usually | would | need to update a lot of configurations to load ONLY the last version | in a | conflic. | On the other hand, if we use #atomic most of the times the newests | verions | will ONLY be loaded automatically, but we may have a problem as all | the | postDoIts are done all together at the end. | | So...which one do you think is the best approach for | ConfogurationOfPharo | ? I guess linear and update the others confs....what do you think ? | | cheers | | mariano | | | | | | > Moving the specification of OmniBrowser before the spec for | > AutomaticMethodCategorizer does result in the correct mcz file for | > OB-Standard to be loaded, however, other issues are exposed: | > | > SHOUT uses the deprecated registerMenu API | > Refactoring Browser needs to be moved earlier to avoid double | > loading. I didn't notice any ill effects of loading earlier | version of | > Refactoring Browser. | > Nile-Clients-MarianoMartinezPeck.178 has an issue with #isInMemory | not | > understood | > | > Perhaps the MNU is due to the fact that I haven't updated | > PharoCore-1.1-11326-UNSTABLE. | > | > My tests to this point were done with Metacello 1.0-beta.26.1 (in | > development) to eliminate any (known) Metacello bugs from the | equation. | > | > At this point I don't think 1.0-beta.26.1 is needed, but I will run | an | > additional test and let you know... | > | > Dale | >

May 4, 2010

Re: [Pharo-project] ConfigurationOfPharo and OmniBrowser

by Mariano Martinez Peck

On Tue, May 4, 2010 at 9:23 PM, Dale Henrichs <dale.henrichs(a)gemstone.com>wrote: > > ----- "Mariano Martinez Peck" <marianopeck(a)gmail.com> wrote: > > > | > The nesting level for '1.1.3 [ConfigurationOfOmniBrowser]' and '1.1 > | > [ConfigurationOfAutomaticMethodCategorizer]' are the same which > | means that > | > they are both referenced in '1.1 [ConfigurationOfPharo]'. That was > | enough to > | > solve this particular problem, but in an Inspector, you can dive > | into the > | > directives themselves and actually get to the MetacelloSpec that was > | used to > | > create the directive... > | > > | > > | > > | Here is what I don't understand. If you have that directive, and you > | have > | ALL that information, can't you guess that if you need to load the N > | version > | of a package and then the version M, where M > N, then you can skip to > | load > | N and just load M directly ? > | > | In this example, can you DO NOT load OmniBrowser-lr.458 as you know > | that > | after you will load OmniBrowser-lr.469 ? > | Or maybe directly about conf: Do not load 1.1 > | [ConfigurationOfOmniBrowser] if you know that then you will need to > | load > | 1.1.3 [ConfigurationOfOmniBrowser] > > Mariano, > > If you were using #atomic loads then what you are suggesting would happen > ... Metacello would recognize that OmniBrowser-lr.469 was later and would > use that instead of the older mcz file. > > With #linear loads it isn't necessarily safe to substitute a newer version > of an mcz file earlier into the load sequence, because the newer version may > have dependencies that wouldn't necessarily be satisfied this early in the > load sequence...The only safe way is to explicitly move the project earlier > in the sequence. > > Ahhhh those ones ;) Now is much clear. Thanks Dale. I forgot sbout those friends. Now I wonder.... if we select #linear is cool because all the packages will be loaded and initialized one after one. But we usually would need to update a lot of configurations to load ONLY the last version in a conflic. On the other hand, if we use #atomic most of the times the newests verions will ONLY be loaded automatically, but we may have a problem as all the postDoIts are done all together at the end. So...which one do you think is the best approach for ConfogurationOfPharo ? I guess linear and update the others confs....what do you think ? cheers mariano > Moving the specification of OmniBrowser before the spec for > AutomaticMethodCategorizer does result in the correct mcz file for > OB-Standard to be loaded, however, other issues are exposed: > > SHOUT uses the deprecated registerMenu API > Refactoring Browser needs to be moved earlier to avoid double > loading. I didn't notice any ill effects of loading earlier version of > Refactoring Browser. > Nile-Clients-MarianoMartinezPeck.178 has an issue with #isInMemory not > understood > > Perhaps the MNU is due to the fact that I haven't updated > PharoCore-1.1-11326-UNSTABLE. > > My tests to this point were done with Metacello 1.0-beta.26.1 (in > development) to eliminate any (known) Metacello bugs from the equation. > > At this point I don't think 1.0-beta.26.1 is needed, but I will run an > additional test and let you know... > > Dale >

May 4, 2010