Re: [Pharo-project] Cmd-t in OB?
The problem is that with gofer only this is tedious to maintain multiple versions of something. Can somebody take care of the ConfigurationOfOB? Stef
I don't know, I do not maintain them.
I just realize that people often report bugs that have been fixed a long time ago.
I suggest that you always load the latest code using the following script:
"Refactoring" Gofer new squeaksource: 'rb'; package: 'AST-Core'; package: 'AST-Semantic'; package: 'Refactoring-Core'; package: 'Refactoring-Changes'; package: 'Refactoring-Critics'; package: 'Refactoring-Environment'; package: 'Refactoring-Spelling'; load. ! "OmniBrowser" Gofer new renggli: 'omnibrowser'; package: 'OmniBrowser'; package: 'OB-Standard'; package: 'OB-Morphic'; package: 'OB-Shout'; package: 'OB-Refactory'; package: 'OB-Regex'; package: 'OB-SUnitIntegration'; load. ! "Tools" Gofer new renggli: 'unsorted'; package: 'Shout'; package: 'ShoutWorkspace'; package: 'RoelTyper'; package: 'ECompletion'; package: 'ECompletionOmniBrowser'; load. ! "Select Tools" SystemBrowser default: (Smalltalk at: #OBSystemBrowserAdaptor).
Lukas
On 8 October 2010 15:09, Alexandre Bergel <alexandre@bergel.eu> wrote:
I did a "ConfigurationOfOmnibrowser project lastVersion load" Apparently ConfigurationOfOmnibrowser is not maintained...
Cheers, Alexandre
On 8 Oct 2010, at 09:03, Lukas Renggli wrote:
Update, this has been fixed half a year ago :-)
Lukas
On 8 October 2010 14:58, Alexandre Bergel <alexandre@bergel.eu> wrote:
hi!
When I press cmd-t in an ob browser in the class category pane, I get a window titled "Selected Command". I would expect executing the test of the class category.
I tried to find out where the "Selected Command" command is defined with: OBCommand allSubclasses select: [:c | c new keystroke = $t ] => an OrderedCollection(OBCmdRunTests)
But apparently only running the test is associated to Cmd-t. Isn't that convenient to be able to run the test from a class category?
Cheers, alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
OB and RB evolve in tiny steps. Each commit is a stable version in itself. Each commit improves or fixes a tiny little bit of the stable core library. I consider it safe to always load the latest versions. For exactly that reason the experimental hard-core changes are in a different repository (http://source.lukas-renggli.ch/ob21). I don't know how to support such a workflow with Metacello? For me it is way faster to use the Gofer scripts below. Lukas On 8 October 2010 15:27, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
The problem is that with gofer only this is tedious to maintain multiple versions of something. Can somebody take care of the ConfigurationOfOB?
Stef
I don't know, I do not maintain them.
I just realize that people often report bugs that have been fixed a long time ago.
I suggest that you always load the latest code using the following script:
"Refactoring" Gofer new    squeaksource: 'rb';    package: 'AST-Core';    package: 'AST-Semantic';    package: 'Refactoring-Core';    package: 'Refactoring-Changes';    package: 'Refactoring-Critics';    package: 'Refactoring-Environment';    package: 'Refactoring-Spelling';    load. ! "OmniBrowser" Gofer new    renggli: 'omnibrowser';    package: 'OmniBrowser';    package: 'OB-Standard';    package: 'OB-Morphic';    package: 'OB-Shout';    package: 'OB-Refactory';    package: 'OB-Regex';    package: 'OB-SUnitIntegration';    load. ! "Tools" Gofer new    renggli: 'unsorted';    package: 'Shout';    package: 'ShoutWorkspace';    package: 'RoelTyper';    package: 'ECompletion';    package: 'ECompletionOmniBrowser';    load. ! "Select Tools" SystemBrowser default: (Smalltalk at: #OBSystemBrowserAdaptor).
Lukas
On 8 October 2010 15:09, Alexandre Bergel <alexandre@bergel.eu> wrote:
I did a "ConfigurationOfOmnibrowser project lastVersion load" Apparently ConfigurationOfOmnibrowser is not maintained...
Cheers, Alexandre
On 8 Oct 2010, at 09:03, Lukas Renggli wrote:
Update, this has been fixed half a year ago :-)
Lukas
On 8 October 2010 14:58, Alexandre Bergel <alexandre@bergel.eu> wrote:
hi!
When I press cmd-t in an ob browser in the class category pane, I get a window titled "Selected Command". I would expect executing the test of the class category.
I tried to find out where the "Selected Command" command is defined with: OBCommand allSubclasses select: [:c | c new keystroke = $t ] => an OrderedCollection(OBCmdRunTests)
But apparently only running the test is associated to Cmd-t. Isn't that convenient to be able to run the test from a class category?
Cheers, alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel  http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel  http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli www.lukas-renggli.ch
On Fri, Oct 8, 2010 at 3:27 PM, Stéphane Ducasse <stephane.ducasse@inria.fr>wrote:
The problem is that with gofer only this is tedious to maintain multiple versions of something. Can somebody take care of the ConfigurationOfOB?
I do as much as my time let me. I even updated several confs. See: http://forum.world.st/Updated-Metacello-Configurations-of-OmniBrowser-Refact... So...if you load that, this should be fixed because I did that few weeks ago (fee weeks ago < 6 months). I cannot update the conf for every Lukas commit. That's not the idea of Metacello. Anyway, I explained several times (I have already put it even in Metacello FAQ) that if you want to load the latest code of every package, just load the baseline. Example: (ConfigurationOfOmnibrowser project version: '1.2-baseline') load
Stef
I don't know, I do not maintain them.
I just realize that people often report bugs that have been fixed a long time ago.
I suggest that you always load the latest code using the following script:
"Refactoring" Gofer new squeaksource: 'rb'; package: 'AST-Core'; package: 'AST-Semantic'; package: 'Refactoring-Core'; package: 'Refactoring-Changes'; package: 'Refactoring-Critics'; package: 'Refactoring-Environment'; package: 'Refactoring-Spelling'; load. ! "OmniBrowser" Gofer new renggli: 'omnibrowser'; package: 'OmniBrowser'; package: 'OB-Standard'; package: 'OB-Morphic'; package: 'OB-Shout'; package: 'OB-Refactory'; package: 'OB-Regex'; package: 'OB-SUnitIntegration'; load. ! "Tools" Gofer new renggli: 'unsorted'; package: 'Shout'; package: 'ShoutWorkspace'; package: 'RoelTyper'; package: 'ECompletion'; package: 'ECompletionOmniBrowser'; load. ! "Select Tools" SystemBrowser default: (Smalltalk at: #OBSystemBrowserAdaptor).
Lukas
On 8 October 2010 15:09, Alexandre Bergel <alexandre@bergel.eu> wrote:
I did a "ConfigurationOfOmnibrowser project lastVersion load" Apparently ConfigurationOfOmnibrowser is not maintained...
Cheers, Alexandre
On 8 Oct 2010, at 09:03, Lukas Renggli wrote:
Update, this has been fixed half a year ago :-)
Lukas
On 8 October 2010 14:58, Alexandre Bergel <alexandre@bergel.eu> wrote:
hi!
When I press cmd-t in an ob browser in the class category pane, I get a window titled "Selected Command". I would expect executing the test of the class category.
I tried to find out where the "Selected Command" command is defined with: OBCommand allSubclasses select: [:c | c new keystroke = $t ] => an OrderedCollection(OBCmdRunTests)
But apparently only running the test is associated to Cmd-t. Isn't that convenient to be able to run the test from a class category?
Cheers, alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Example: (ConfigurationOfOmnibrowser project version: '1.2-baseline') load
I know, but I don't remember. It is far too complicated. Why not ConfigurationOfOmnibrowser project load@*%$LatestCode ? Lukas -- Lukas Renggli www.lukas-renggli.ch
On Fri, Oct 8, 2010 at 3:46 PM, Lukas Renggli <renggli@gmail.com> wrote:
Example: (ConfigurationOfOmnibrowser project version: '1.2-baseline') load
I know, but I don't remember. It is far too complicated.
1) Nobody makes you use Metacello. If you don't want, don't use it 2) We know this is complicated and this is why we have discussing a lot since the last months, and this is why Dale will integrate #stableVersion, #bleedingEdge, etc 3) This is why there is a FAQ and a website. To persist the things your brain cannot. Anyway, for me this is not complicated. It is just one rule: "if you don't define a version, Metacello will take the last one" Since you read the Metacello tutorial I guess, you know a baseline should not define versions. Thus, if you try to load a baseline, it will have no version defined. Then, all the latest ones will be loaded. Is this that complicated? Cheers Mariano
Why not
ConfigurationOfOmnibrowser project load@*%$LatestCode
?
Lukas
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Anyway, for me this is not complicated. It is just one rule: "if you don't define a version, Metacello will take the last one" Since you read the Metacello tutorial I guess, you know a baseline should not define versions. Thus, if you try to load a baseline, it will have no version defined. Then, all the latest ones will be loaded. Is this that complicated?
I want to script it. And I don't want to figure out the baseline name myself. So yes, it is too complicated. Lukas -- Lukas Renggli www.lukas-renggli.ch
ConfigurationOfOmnibrowser project load@*%$LatestCode
better in my opinion: ConfigurationOfOmnibrowser loadLastVersion As a metathough, I think we need a unification of how Configuration are defined and used. We have loadDefault in Moose. I often do a ConfigurationOfXX project lastVersion load. You can directly load the baseline. I know this has been discussed many times. But we really need to come up with a simple and efficient way to use configuration. I would also like to have ConfigurationOfXX forEachVersionsLoadAndDo: [:v | ... ], versionsSelect: [:v | ... ], ... Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On 8 October 2010 15:56, Alexandre Bergel <alexandre@bergel.eu> wrote:
ConfigurationOfOmnibrowser project load@*%$LatestCode
better in my opinion: ConfigurationOfOmnibrowser loadLastVersion
I think the indirection through project to preserve backwards compatibility and to avoid generating lots of boilerplate in the configuration classes is worth it. Lukas -- Lukas Renggli www.lukas-renggli.ch
better in my opinion: ConfigurationOfOmnibrowser loadLastVersion
I think the indirection through project to preserve backwards compatibility and to avoid generating lots of boilerplate in the configuration classes is worth it.
Could be, even though I do not immediately see if this implies really a lot of boilerplate code. I usually only want to load the last version or a particular version of an application. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
El vie, 08-10-2010 a las 09:56 -0400, Alexandre Bergel escribió:
ConfigurationOfOmnibrowser project load@*%$LatestCode
better in my opinion: ConfigurationOfOmnibrowser loadLastVersion
As a metathough, I think we need a unification of how Configuration are defined and used. We have loadDefault in Moose. I often do a ConfigurationOfXX project lastVersion load. You can directly load the baseline. I know this has been discussed many times. But we really need to come up with a simple and efficient way to use configuration.
I would also like to have ConfigurationOfXX forEachVersionsLoadAndDo: [:v | ... ], versionsSelect: [:v | ... ], ...
Alexandre
There is a long thread in the metacello mailing list where those topics are being discussed and Dale is right now working in the new code to support them. So if you want to be heard please propose those guidelines there so they are taken in account. Cheers
-- Miguel Cobá http://miguel.leugim.com.mx
Yeah, I agree, there is definitely a need for Metacello. I suggest to make it easier to use, faster and more lightweight. Currently it is more the opposite. I propose something along Gofer, but for Metacello (I believe somebody already did something like this?): 1. loading the latest stable version must be dead simple Metacello new project: 'OB'; loadStable 2. loading the latest development version must be dead simple Metacello new project: 'OB'; loadDevelopment 3. specifying what groups to load must be dead simple Metacello new project: 'Seaside'; group: 'Tests'; group: 'Javascript'; load 4. loading should not require to additional infrastructure to be loaded into a Pharo image (I imagine a server that has all configurations preloaded and that returns Gofer scripts that can be executed in the target image) Lukas On 8 October 2010 17:15, Miguel Cobá <miguel.coba@gmail.com> wrote:
El vie, 08-10-2010 a las 09:56 -0400, Alexandre Bergel escribió:
 ConfigurationOfOmnibrowser project load@*%$LatestCode
better in my opinion: ConfigurationOfOmnibrowser loadLastVersion
As a metathough, I think we need a unification of how Configuration are defined and used. We have loadDefault in Moose. I often do a ConfigurationOfXX project lastVersion load. You can directly load the baseline. I know this has been discussed many times. But we really need to come up with a simple and efficient way to use configuration.
I would also like to have ConfigurationOfXX forEachVersionsLoadAndDo: [:v | ... ], versionsSelect: [:v | ... ], ...
Alexandre
There is a long thread in the metacello mailing list where those topics are being discussed and Dale is right now working in the new code to support them. So if you want to be heard please propose those guidelines there so they are taken in account.
Cheers
-- Miguel Cobá http://miguel.leugim.com.mx
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli www.lukas-renggli.ch
4. loading should not require to additional infrastructure to be loaded into a Pharo image (I imagine a server that has all configurations preloaded and that returns Gofer scripts that can be executed in the target image)
Let's be imaginative. I want the server to return an image segment that I can directly install in my image :-) Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Fri, Oct 8, 2010 at 5:25 PM, Lukas Renggli <renggli@gmail.com> wrote:
Yeah, I agree, there is definitely a need for Metacello.
I suggest to make it easier to use, faster and more lightweight. Currently it is more the opposite.
I propose something along Gofer, but for Metacello (I believe somebody already did something like this?):
Yes, Esteban: http://www.smallworks.com.ar/en/community/GoferProjectLoader
1. loading the latest stable version must be dead simple
Metacello new project: 'OB'; loadStable
2. loading the latest development version must be dead simple
Metacello new project: 'OB'; loadDevelopment
3. specifying what groups to load must be dead simple
Metacello new project: 'Seaside'; group: 'Tests'; group: 'Javascript'; load
it does all that.
4. loading should not require to additional infrastructure to be loaded into a Pharo image (I imagine a server that has all configurations preloaded and that returns Gofer scripts that can be executed in the target image)
this can be discussed with dale.
Lukas
On 8 October 2010 17:15, Miguel Cobá <miguel.coba@gmail.com> wrote:
El vie, 08-10-2010 a las 09:56 -0400, Alexandre Bergel escribió:
ConfigurationOfOmnibrowser project load@*%$LatestCode
better in my opinion: ConfigurationOfOmnibrowser loadLastVersion
As a metathough, I think we need a unification of how Configuration are defined and used. We have loadDefault in Moose. I often do a ConfigurationOfXX project lastVersion load. You can directly load the baseline. I know this has been discussed many times. But we really need to come up with a simple and efficient way to use configuration.
I would also like to have ConfigurationOfXX forEachVersionsLoadAndDo: [:v | ... ], versionsSelect: [:v | ... ], ...
Alexandre
There is a long thread in the metacello mailing list where those topics are being discussed and Dale is right now working in the new code to support them. So if you want to be heard please propose those guidelines there so they are taken in account.
Cheers
-- Miguel Cobá http://miguel.leugim.com.mx
_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hi, To me this discussion again raises the point of what I call the "default" case for development :). Lukas, the simplest thing that you can do at this moment is to introduce a "default" version (see those in the ConfigurationOfGlamour/Mondrian/Moose...). This is nothing but your order of packages. Afterwards, you just load that one. When someone wants to hardcode a version, you just spawn this version with the package versions you have in the image. Like this, you have best of both worlds: (1) lightweight management for development, and (2) controlled versioning for releases. Cheers, Doru On 8 Oct 2010, at 17:25, Lukas Renggli wrote:
Yeah, I agree, there is definitely a need for Metacello.
I suggest to make it easier to use, faster and more lightweight. Currently it is more the opposite.
I propose something along Gofer, but for Metacello (I believe somebody already did something like this?):
1. loading the latest stable version must be dead simple
Metacello new project: 'OB'; loadStable
2. loading the latest development version must be dead simple
Metacello new project: 'OB'; loadDevelopment
3. specifying what groups to load must be dead simple
Metacello new project: 'Seaside'; group: 'Tests'; group: 'Javascript'; load
4. loading should not require to additional infrastructure to be loaded into a Pharo image (I imagine a server that has all configurations preloaded and that returns Gofer scripts that can be executed in the target image)
Lukas
On 8 October 2010 17:15, Miguel Cobá <miguel.coba@gmail.com> wrote:
El vie, 08-10-2010 a las 09:56 -0400, Alexandre Bergel escribió:
ConfigurationOfOmnibrowser project load@*%$LatestCode
better in my opinion: ConfigurationOfOmnibrowser loadLastVersion
As a metathough, I think we need a unification of how Configuration are defined and used. We have loadDefault in Moose. I often do a ConfigurationOfXX project lastVersion load. You can directly load the baseline. I know this has been discussed many times. But we really need to come up with a simple and efficient way to use configuration.
I would also like to have ConfigurationOfXX forEachVersionsLoadAndDo: [:v | ... ], versionsSelect: [:v | ... ], ...
Alexandre
There is a long thread in the metacello mailing list where those topics are being discussed and Dale is right now working in the new code to support them. So if you want to be heard please propose those guidelines there so they are taken in account.
Cheers
-- Miguel Cobá http://miguel.leugim.com.mx
_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- www.tudorgirba.com "One cannot do more than one can do."
On 10/08/2010 08:25 AM, Lukas Renggli wrote:
Yeah, I agree, there is definitely a need for Metacello.
I suggest to make it easier to use, faster and more lightweight. Currently it is more the opposite.
I propose something along Gofer, but for Metacello (I believe somebody already did something like this?):
1. loading the latest stable version must be dead simple
Metacello new project: 'OB'; loadStable
2. loading the latest development version must be dead simple
Metacello new project: 'OB'; loadDevelopment
3. specifying what groups to load must be dead simple
Metacello new project: 'Seaside'; group: 'Tests'; group: 'Javascript'; load
4. loading should not require to additional infrastructure to be loaded into a Pharo image (I imagine a server that has all configurations preloaded and that returns Gofer scripts that can be executed in the target image)
Lukas, We are headed in exactly this direction. points 1,2 and 3 are directly covered by a combination of the GoferProjectLoader and new features in Metacello. So your expressions would be recast as something like: Gofer project loadStable: 'OB'. Gofer project loadDevelopment: 'OB'. Gofer project loadStable: 'OB' group: #( 'Tests' 'Javascript'). In addition to the notion of #stable and #development we have talked of the notion of #bleedingEdge. The #bleedingEdge loads the latest version of every mcz file...which may be what you were thinking about when you said #loadDevelopment ... Doru's discussion of a 'default' version and the #bleedingEdge are the same idea. So then we'd add the following expression: Gofer project loadBleedingEdge: 'OB'. As for you point 4, I think that that is a future item. I like the idea, but I think that it is not that simple... One of the more subtle things that goes on when loading Metacello configurations is that the current state of the image (i.e., loaded mcz files) is used to calculate what should be loaded ... if a required project is already loaded and especially if it is already at a later version, that project isn't loaded. If the project is at an earlier version then it is upgraded to conform to required version. On top of this, when a project is upgraded, all of the loaded mcz files are upgraded not just those that are specifically requested... With that said, it should be possible to ship a spec of what is loaded in the current image to a server where the calculation is made and a load directive (basically a Gofer script) could be returned, but there are more moving parts in this than I want to tackle at the moment... Unfortunately, a good bit of my time is being consumed at the moment by a GemStone project, but I fully expect to deliver on the above within the next month or so with an early release available within a couple of weeks as we are still hammering out details ... Dale
There is a long thread in the metacello mailing list where those topics are being discussed and Dale is right now working in the new code to support them. So if you want to be heard please propose those guidelines there so they are taken in account.
Yep, I know the value of a mailing list for a community. However, I simply cannot afford to spend hours reading all (very long) the emails on that topic. Once a Pharo community will be bootstrapped in Chile, then I will be more able to participate on topics that do not directly matter for the university, my employer. Writing a six-lines email is as valuable as writing a method of six-line of code, at least to me :-) Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On 10/08/2010 08:26 AM, Alexandre Bergel wrote:
There is a long thread in the metacello mailing list where those topics are being discussed and Dale is right now working in the new code to support them. So if you want to be heard please propose those guidelines there so they are taken in account.
Yep, I know the value of a mailing list for a community. However, I simply cannot afford to spend hours reading all (very long) the emails on that topic. Once a Pharo community will be bootstrapped in Chile, then I will be more able to participate on topics that do not directly matter for the university, my employer.
Writing a six-lines email is as valuable as writing a method of six-line of code, at least to me :-)
Cheers, Alexandre
Alexandre, Understood, that is why the discussion is taking place on the Metacello list ... There are actually a number of issues that are being addressed by a small set of concepts so a number of us are working through the issues trying to iron out the details ... The actual implementation is not that complicated, but we are making significant additions to the conceptual model so we are taking care (the devil is in the details). In the end you will see something like the following announced as the model for loading projects: Gofer project loadStable: 'OB'. Gofer project loadDevelopment: 'OB'. Gofer project loadStable: 'OB' group: #( 'Tests' 'Javascript'). Gofer project loadBleedingEdge: 'OB'. Gofer project load: 'OB' version: '1.1.4'. along with documentation for specifying the #stableVersion, #developmentVersion and #bleedingEdgeVersion. I think that Mariano and I fully expect to make a pass on the majority of configurations in the MetacelloRepository to update the configs to match the expectations and provide examples. Dale
Gofer project loadStable: 'OB'. Gofer project loadDevelopment: 'OB'. Gofer project loadStable: 'OB' group: #( 'Tests' 'Javascript'). Gofer project loadBleedingEdge: 'OB'. Gofer project load: 'OB' version: '1.1.4'.
Yes yes yes !! Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
participants (7)
-
Alexandre Bergel -
Dale Henrichs -
Lukas Renggli -
Mariano Martinez Peck -
Miguel Cobá -
Stéphane Ducasse -
Tudor Girba