- Moose-dev - INF Mailman

Re: [Metacello] specific problem when loading a nested configuration

by Dale Henrichs

I wouldn't be entirely opposed to having an abstract configuration class, but I hate to switch the configuration structure in midstream again... it is very nice that a config can be loaded into any old smalltalk image without any prerequisites.... The #ensureMetacello method should simply load ConfigurationOfMetacello and go from there ... To require an abstract configuration class, I would want that class to be in the core for Pharo, GemStone and Squeak ... Metacello is already bundled with the core in GemStone so that leaves Squeak ... I really don't want to have to preface all of the install instructions with "Before loading the configuration, make sure that you've done X, Y and Z" If bootstrapping is the only consideration, I don't think it is worth making the change ... there isn't a lot protocol that I would want to put into the Abstract configuration class ... project instance variable and method ... If there are enough other arguments for an Abstract configuration class, then it would be good to make the switch sooner rather than later. Being able to view the configurations using a hierarchy browser is an advantage, but that's more of a tools issue. As I think about it, most of the advantages that come to mind are tools related. Even bootstrapping is a tools issue of sorts... What do others think? Dale ----- "Tudor Girba" <tudor.girba(a)gmail.com> wrote: | Oh! I am slightly embarrassed :) | | I updated ConfigurationOfMooseJEE to use the latest | ConfigurationOfMetacello and indeed it works. | | But I think this basically means that it starts to make sense to have | | an abstract configuration in Pharo-Core, because copy paste just does | | not scale anymore. | | Cheers, | Doru | | p.s. Btw, I love the progress bar :) | | | On 11 Dec 2009, at 19:24, Dale Henrichs wrote: | | > Doru, | > | > I looked at the #ensureMetacello method ConfigurationOfMooseJEE, but | | > didn't notice (the first, second and third time that I looked:) that | | > it is using MetacelloConfiguration so latest version isn't getting a | | > recent enough version of Metacello ... | > | > So update the ConfigurationOfMooseJEE class>>ensureMetacello to boot | | > with ConfigurationOfMetacello instead of MetacelloConfiguration... | > | > Dale | > ----- "Dale Henrichs" <dale.henrichs(a)gemstone.com> wrote: | > | > | Doru, | > | | > | Things worked fine (well almost fine) with my first try at | loading | > | MooseJEE ... initialization failed in FSPlatformResolver, because | > | there is no FSUnixResolver, however the Morphic-MorphTreeWidget | is | > | being loaded. I used this expression: | > | | > | Gofer new squeaksource: 'MooseJEE'; addPackage: | > | 'ConfigurationOfMooseJEE'; load. | > | (Smalltalk at: #ConfigurationOfMooseJEE) perform: #loadDefault | > | | > | ... This test was run with 1.0-beta.18 preloaded, so I will try | > again | > | with a virgin image... | > | | > | Dale | > | ----- "Tudor Girba" <tudor.girba(a)gmail.com> wrote: | > | | > | | Hi, | > | | | > | | A strange problem, that appeared before but was solved at the | > time, | > | | > | | seems to resurface again in a slightly different context. | > | | | > | | It is related to the Morphic-MorphTreeWidget from the Momo | > | | squeaksource repository. This is needed in Glamour. | > | | | > | | Glamour is needed in Moose. | > | | | > | | Now, if you load ConfigurationOfMoose, it all works fine: | > | | | > | | Gofer new squeaksource: 'Moose'; addPackage: | > 'ConfigurationOfMoose'; | > | | > | | | > | | load. | > | | (Smalltalk at: #ConfigurationOfMoose) perform: #loadDefault | > | | | > | | However, Moose is needed in MooseJEE. And if you load | > | | ConfigurationOfMooseJEE it does not work anymore: | > | | | > | | Gofer new squeaksource: 'MooseJEE'; addPackage: | > | | 'ConfigurationOfMooseJEE'; load. | > | | (Smalltalk at: #ConfigurationOfMooseJEE) perform: #loadDefault | > | | | > | | If you look in the packages to load, Morphic-MorphTreeWidget | does | > | not | > | | | > | | seem to appear among them in the latter case. | > | | | > | | I would need help for this one, if someone has time to look | into | > | that | > | | :) | > | | | > | | Cheers, | > | | Doru | > | | | > | | -- | > | | www.tudorgirba.com | > | | | > | | "The coherence of a trip is given by the clearness of the | goal." | | -- | www.tudorgirba.com | | "Presenting is storytelling."

15 years, 6 months

2
1
0 0

Re: [Metacello] specific problem when loading a nested configuration

by Dale Henrichs

Doru, I looked at the #ensureMetacello method ConfigurationOfMooseJEE, but didn't notice (the first, second and third time that I looked:) that it is using MetacelloConfiguration so latest version isn't getting a recent enough version of Metacello ... So update the ConfigurationOfMooseJEE class>>ensureMetacello to boot with ConfigurationOfMetacello instead of MetacelloConfiguration... Dale ----- "Dale Henrichs" <dale.henrichs(a)gemstone.com> wrote: | Doru, | | Things worked fine (well almost fine) with my first try at loading | MooseJEE ... initialization failed in FSPlatformResolver, because | there is no FSUnixResolver, however the Morphic-MorphTreeWidget is | being loaded. I used this expression: | | Gofer new squeaksource: 'MooseJEE'; addPackage: | 'ConfigurationOfMooseJEE'; load. | (Smalltalk at: #ConfigurationOfMooseJEE) perform: #loadDefault | | ... This test was run with 1.0-beta.18 preloaded, so I will try again | with a virgin image... | | Dale | ----- "Tudor Girba" <tudor.girba(a)gmail.com> wrote: | | | Hi, | | | | A strange problem, that appeared before but was solved at the time, | | | seems to resurface again in a slightly different context. | | | | It is related to the Morphic-MorphTreeWidget from the Momo | | squeaksource repository. This is needed in Glamour. | | | | Glamour is needed in Moose. | | | | Now, if you load ConfigurationOfMoose, it all works fine: | | | | Gofer new squeaksource: 'Moose'; addPackage: 'ConfigurationOfMoose'; | | | | | load. | | (Smalltalk at: #ConfigurationOfMoose) perform: #loadDefault | | | | However, Moose is needed in MooseJEE. And if you load | | ConfigurationOfMooseJEE it does not work anymore: | | | | Gofer new squeaksource: 'MooseJEE'; addPackage: | | 'ConfigurationOfMooseJEE'; load. | | (Smalltalk at: #ConfigurationOfMooseJEE) perform: #loadDefault | | | | If you look in the packages to load, Morphic-MorphTreeWidget does | not | | | | seem to appear among them in the latter case. | | | | I would need help for this one, if someone has time to look into | that | | :) | | | | Cheers, | | Doru | | | | -- | | www.tudorgirba.com | | | | "The coherence of a trip is given by the clearness of the goal."

15 years, 6 months

3
2
0 0

loading Moose in latest Pharo-Dev

by Johan Brichau

Hi Moosers, I just loaded Moose in the latest Pharo-Dev using the script on your website but I got a bunch of unloadable definitions: This package depends on the following classes: MorphTreeModel MorphTreeColumn MorphTreeNodeModel I did a proceed and obviously, Moose Finder does not open :-( Can you help me out ? ---------------------------- Johan Brichau johan.brichau(a)uclouvain.be

15 years, 6 months

3
6
0 0

Re: [Metacello] specific problem when loading a nested configuration

by Dale Henrichs

Doru, Things worked fine (well almost fine) with my first try at loading MooseJEE ... initialization failed in FSPlatformResolver, because there is no FSUnixResolver, however the Morphic-MorphTreeWidget is being loaded. I used this expression: Gofer new squeaksource: 'MooseJEE'; addPackage: 'ConfigurationOfMooseJEE'; load. (Smalltalk at: #ConfigurationOfMooseJEE) perform: #loadDefault ... This test was run with 1.0-beta.18 preloaded, so I will try again with a virgin image... Dale ----- "Tudor Girba" <tudor.girba(a)gmail.com> wrote: | Hi, | | A strange problem, that appeared before but was solved at the time, | seems to resurface again in a slightly different context. | | It is related to the Morphic-MorphTreeWidget from the Momo | squeaksource repository. This is needed in Glamour. | | Glamour is needed in Moose. | | Now, if you load ConfigurationOfMoose, it all works fine: | | Gofer new squeaksource: 'Moose'; addPackage: 'ConfigurationOfMoose'; | | load. | (Smalltalk at: #ConfigurationOfMoose) perform: #loadDefault | | However, Moose is needed in MooseJEE. And if you load | ConfigurationOfMooseJEE it does not work anymore: | | Gofer new squeaksource: 'MooseJEE'; addPackage: | 'ConfigurationOfMooseJEE'; load. | (Smalltalk at: #ConfigurationOfMooseJEE) perform: #loadDefault | | If you look in the packages to load, Morphic-MorphTreeWidget does not | | seem to appear among them in the latter case. | | I would need help for this one, if someone has time to look into that | :) | | Cheers, | Doru | | -- | www.tudorgirba.com | | "The coherence of a trip is given by the clearness of the goal."

15 years, 6 months

1
0
0 0

specific problem when loading a nested configuration

by Tudor Girba

Hi, A strange problem, that appeared before but was solved at the time, seems to resurface again in a slightly different context. It is related to the Morphic-MorphTreeWidget from the Momo squeaksource repository. This is needed in Glamour. Glamour is needed in Moose. Now, if you load ConfigurationOfMoose, it all works fine: Gofer new squeaksource: 'Moose'; addPackage: 'ConfigurationOfMoose'; load. (Smalltalk at: #ConfigurationOfMoose) perform: #loadDefault However, Moose is needed in MooseJEE. And if you load ConfigurationOfMooseJEE it does not work anymore: Gofer new squeaksource: 'MooseJEE'; addPackage: 'ConfigurationOfMooseJEE'; load. (Smalltalk at: #ConfigurationOfMooseJEE) perform: #loadDefault If you look in the packages to load, Morphic-MorphTreeWidget does not seem to appear among them in the latter case. I would need help for this one, if someone has time to look into that :) Cheers, Doru -- www.tudorgirba.com "The coherence of a trip is given by the clearness of the goal."

15 years, 6 months

3
4
0 0

Glamour default examples hanging Pharo

by Johan Fabry

Hi, all, something that is a major inconvenience: with todays default configuration of moose, a bunch of glamour basic examples hang Pharo. I submitted a bugreport: http://code.google.com/p/moose-technology/issues/detail?id=258 that uses one case but there are many more. Select something in a list and the image hangs. A bit of a shame, I wanted to play around with Glamour to implement the control panel for AspectMaps, but now I cannot do anything at all :-( -- Johan Fabry jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile

15 years, 6 months

3
7
0 0

Mondrian-Alexandre_Bergel.302

by Alexandre Bergel

The comment of this version says: -=-=-=-=-=-=-=-=-=-=-=-= This version contains a number of important refactorings and improvement: - MOGraphElement.children has been renamed into MOGraphElement.nodes - allChildrenDo: -> allNodesDo: - added a method MOGraphElement>>handleException: that handle error. Normally, an image should not freeze when rendering an erroneous Mondrian script. - Bug fixed in MOGraphElement>>elementAt:ifAbsent: This solve the ISSUE #193. A test has been added: MOViewRendererTest>>testEdgeContainsPointWithEdges - recagorization of methods in MOArrowedOrthoVerticalLineShape - Bug fixed in MOLineShape>>containsPoint:for: This solved the ISSUE #249. The problem stems from using CurvedLine. I added a test MOViewRendererTest>>testEdgeContainsPointCurveFitter for this - Added a safeguard in MOAnnouncer>>popupText: All 164 Test methods are green! -=-=-=-=-=-=-=-=-=-=-=-= Doru, I wanted to do a merge with tg.296, but you redefined MOSplineShape>>display:on: and I provide a new version of this method (I refactored some part). Maybe you want to do the merging of this method. I can do it if you want. I am now updating the corresponding issues in code.google.com Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

15 years, 6 months

5
8
0 0

[infusion] Importing calls from static context

by Simon Denier

Hi there the infusion team I would like to know if/how inFusion handles calls in static block in Java. I can not find such invocations in a model. Would it be complicated to add them? I have the following sample: class KeyMapping { static final KeyMapping keyMapping1 = new KeyMapping(KeyEvent.VK_LEFT, KeyEvent.VK_RIGHT, KeyEvent.VK_UP, KeyEvent.VK_SPACE); static final KeyMapping keyMapping2 = new KeyMapping(KeyEvent.VK_X, KeyEvent.VK_V, KeyEvent.VK_D, KeyEvent.VK_ALT); int left, right, thrust, fire; KeyMapping(int k_left, int k_right, int k_thrust, int k_fire) { left = k_left; right = k_right; thrust = k_thrust; fire = k_fire; } } -- Simon

15 years, 6 months

2
1
0 0

Review long-term goals / milestones etc

by Simon Denier

So now that we have discussed a bit more how to use the bug tracker, what about these two other pages. http://code.google.com/p/moose-technology/wiki/improveMooseTaksList http://code.google.com/p/moose-technology/wiki/PhamooseRoadmap They should at least be merged together, cleaned from some items, and some items could be pushed in the issue tracker perhaps. I will create a page describing the HowToIssue. -- Simon

15 years, 7 months

4
6
0 0

Re: [Metacello] Re: Branch blessing and lastVersion

by Dale Henrichs

Stef, I tend to agree, but you want it fairly obvious to the end user that they are wandering onto the bleeding edge when using nano versions:) For example, by default, Metacello would filter out nano versions... Dale ----- "stephane ducasse" <stephane.ducasse(a)gmail.com> wrote: | simon my gut feeling is telling me that four level is too complex. | | Stef | | On Dec 5, 2009, at 5:07 PM, Simon Denier wrote: | | > | > | > Thinking again about the dev process specifically in Moose (not | subprojects such as CAnalyzer, Mondrian...), branches for developer | should be 'nano' releases actually, that is: | > - 4 is a major release of Moose | > - 4.1 is a minor release, but still something consistent | > - 4.2.x should be for release in the main trunk, i.e. mostly dev and | beta version before releasing a minor release (would be 4.2) | > - 4.2.x.y is a branch of one developer (something short-lived, | typically for a task resolution, once finished should be merged in | main trunk) | > | > We could also follow the linux rule: | > - 4.1, 4.1.1, 4.1.1.1 are the dev versions for the future 4.2 stable | releases | > - 4.2, 4.2.1 etc are minor and micro releases but stable, with bug | fixes | > i.e. minor is odd -> dev version, minor is even -> stable version | > This does not mean we work on two versions in parallel (we dont have | the manpower), but it just to help distinguish between dev and stable | versions | > | > I'm just pushing ideas out of my head. Now, with this process, we | have three main requirements for Moose: | > - making it easy for anybody to retrieve (and identify it) the | latest stable version | > - making integration in the main dev trunk the priority (we have | limited resources, so each developer should take care to merge its | changes in the main trunk, and start over from the main trunk for a | new task, NOT always working in the same branches) | > - managing micro/nano releases from each developer | > | > I'm sorry if this feels too complicated and overly complex, it is | not. I'm just playing with different schemas and see what could work | best. | > | > | ----------------------------------------------------------------------------------------------------------------------------- | > Now of course Metacello should not care about conventions (minor, | micro...) of each project. Your proposition seems reasonable and | flexible enough. | > | > But then, how can I ask for a version with a specific blessing? | > | > | > | > On 4 déc. 2009, at 18:48, Dale Henrichs wrote: | > | >> | >> Thinking off the top of my head, would it be work to supply a | pattern of some sort as an arg? Something like: | >> | >> ConfigurationOfXXX project lastVersion: '*.*' | >> | >> Not a real regex (because of the periods would need to be escaped, | but mainly because reading regex for me is like trying to read | russian:). | >> | >> Maybe best is a special purpose character like '#' in addition to | the standard(?) smalltalk patterns '*' and '?': | >> | >> ConfigurationOfXXX project lastVersion: '#.#' ---> matches all | major.minor | >> ConfigurationOfXXX project lastVersion: '1.#' ---> matches all | 1.minor | >> ConfigurationOfXXX project lastVersion: '*' ---> is current | algorithm | >> ConfigurationOfXXX project lastVersion: '*.0' ---> matches | versions with trailing .0 | >> ConfigurationOfXXX project lastVersion: '?.#' ---> matches single | character major.minor | > | > I dont see what is the use of this one? | > | > | > | >> ConfigurationOfXXX project lastVersion: '1.#.3' ---> is invalid | >> | >> This one seems to the right approach ... I can add a #match: method | to MetacelloVersionNumber to implement the pattern matching. | >> | >> What do you think? | >> | >> Dale | >> | >> ----- "Simon Denier" <Simon.Denier(a)inria.fr> wrote: | >> | >> | Suppose I have versions like this: | >> | 1.3.2 #development --> branch by a developer | >> | 1.3.1 #development --> branch by a developer | >> | 1.3 #development --> main trunk, last dev | >> | 1.2 #stable --> main trunk, last stable | >> | | >> | When I perform a ConfigurationOfXXX project lastVersion, I would | like | >> | | >> | to retrieve the config for the last dev version common to | everybody, | >> | | >> | and I would like this to be 1.3, not 1.3.2 which is the work of | one | >> | guy not yet merged in the main trunk. | >> | | >> | Right now, I get 1.3.2 | >> | | >> | Perhaps we could have something like this: | >> | 1.3.2 #branch --> branch by a developer | >> | 1.3.1 #branch --> branch by a developer | >> | 1.3 #development --> main trunk, last dev | >> | 1.2 #stable --> main trunk, last stable | >> | | >> | and branch would be an 'unstable' tag ignored by the loader when | >> | asking for latestVersion or lastVersion (and veryLastVersion | could | >> | retrieve the latest version, be it a branch, dev, or stable). | >> | | >> | I have no special requirements here, I'm just playing with the | idea | >> | and process of how to manage micro releases with Metacello. | >> | | >> | -- | >> | Simon | > | > -- | > Simon | > | > | >

15 years, 7 months

1
0
0 0

Re: [Metacello] Re: Branch blessing and lastVersion

by Dale Henrichs

Simon, I've been thinking about the same problems for GLASS ... I want it to be possible for individual developers to release bugfixes/improvements for sharing, but hadn't thought too far into it ... nano releases sounds like the right way to go...as far as a convention ... Re: filtering on version and blessing ... I think that the special '#' character in patterns should stay ... blessings don't have a sort order so at the moment they are odd beasts ... for example I can't say 'belssing > #alpha' ... so perhaps we need to define a sort order for blessings ... I lean away from a canonical list of blessings, so folks would need to be able to add blessings/priority to a project ... Have to come up with the low-level filtering api and then create come higher level helper methods ... I'm open to suggestions at the moment... Dale ----- "Simon Denier" <Simon.Denier(a)inria.fr> wrote: | Thinking again about the dev process specifically in Moose (not | subprojects such as CAnalyzer, Mondrian...), branches for developer | should be 'nano' releases actually, that is: | - 4 is a major release of Moose | - 4.1 is a minor release, but still something consistent | - 4.2.x should be for release in the main trunk, i.e. mostly dev and | | beta version before releasing a minor release (would be 4.2) | - 4.2.x.y is a branch of one developer (something short-lived, | typically for a task resolution, once finished should be merged in | main trunk) | | We could also follow the linux rule: | - 4.1, 4.1.1, 4.1.1.1 are the dev versions for the future 4.2 stable | | releases | - 4.2, 4.2.1 etc are minor and micro releases but stable, with bug | fixes | i.e. minor is odd -> dev version, minor is even -> stable version | This does not mean we work on two versions in parallel (we dont have | | the manpower), but it just to help distinguish between dev and stable | | versions | | I'm just pushing ideas out of my head. Now, with this process, we have | | three main requirements for Moose: | - making it easy for anybody to retrieve (and identify it) the latest | | stable version | - making integration in the main dev trunk the priority (we have | limited resources, so each developer should take care to merge its | changes in the main trunk, and start over from the main trunk for a | new task, NOT always working in the same branches) | - managing micro/nano releases from each developer | | I'm sorry if this feels too complicated and overly complex, it is not. | | I'm just playing with different schemas and see what could work best. | | ----------------------------------------------------------------------------------------------------------------------------- | Now of course Metacello should not care about conventions (minor, | micro...) of each project. Your proposition seems reasonable and | flexible enough. | | But then, how can I ask for a version with a specific blessing? | | | | On 4 déc. 2009, at 18:48, Dale Henrichs wrote: | | > | > Thinking off the top of my head, would it be work to supply a | > pattern of some sort as an arg? Something like: | > | > ConfigurationOfXXX project lastVersion: '*.*' | > | > Not a real regex (because of the periods would need to be escaped, | | > but mainly because reading regex for me is like trying to read | > russian:). | > | > Maybe best is a special purpose character like '#' in addition to | > the standard(?) smalltalk patterns '*' and '?': | > | > ConfigurationOfXXX project lastVersion: '#.#' ---> matches all | > major.minor | > ConfigurationOfXXX project lastVersion: '1.#' ---> matches all | > 1.minor | > ConfigurationOfXXX project lastVersion: '*' ---> is current | > algorithm | > ConfigurationOfXXX project lastVersion: '*.0' ---> matches | > versions with trailing .0 | > ConfigurationOfXXX project lastVersion: '?.#' ---> matches single | | > character major.minor | | I dont see what is the use of this one? | | | | > ConfigurationOfXXX project lastVersion: '1.#.3' ---> is invalid | > | > This one seems to the right approach ... I can add a #match: method | | > to MetacelloVersionNumber to implement the pattern matching. | > | > What do you think? | > | > Dale | > | > ----- "Simon Denier" <Simon.Denier(a)inria.fr> wrote: | > | > | Suppose I have versions like this: | > | 1.3.2 #development --> branch by a developer | > | 1.3.1 #development --> branch by a developer | > | 1.3 #development --> main trunk, last dev | > | 1.2 #stable --> main trunk, last stable | > | | > | When I perform a ConfigurationOfXXX project lastVersion, I would | | > like | > | | > | to retrieve the config for the last dev version common to | everybody, | > | | > | and I would like this to be 1.3, not 1.3.2 which is the work of | one | > | guy not yet merged in the main trunk. | > | | > | Right now, I get 1.3.2 | > | | > | Perhaps we could have something like this: | > | 1.3.2 #branch --> branch by a developer | > | 1.3.1 #branch --> branch by a developer | > | 1.3 #development --> main trunk, last dev | > | 1.2 #stable --> main trunk, last stable | > | | > | and branch would be an 'unstable' tag ignored by the loader when | > | asking for latestVersion or lastVersion (and veryLastVersion | could | > | retrieve the latest version, be it a branch, dev, or stable). | > | | > | I have no special requirements here, I'm just playing with the | idea | > | and process of how to manage micro releases with Metacello. | > | | > | -- | > | Simon | | -- | Simon

15 years, 7 months

1
0
0 0

Re: [Metacello] Re: Branch blessing and lastVersion

by Simon Denier

Thinking again about the dev process specifically in Moose (not subprojects such as CAnalyzer, Mondrian...), branches for developer should be 'nano' releases actually, that is: - 4 is a major release of Moose - 4.1 is a minor release, but still something consistent - 4.2.x should be for release in the main trunk, i.e. mostly dev and beta version before releasing a minor release (would be 4.2) - 4.2.x.y is a branch of one developer (something short-lived, typically for a task resolution, once finished should be merged in main trunk) We could also follow the linux rule: - 4.1, 4.1.1, 4.1.1.1 are the dev versions for the future 4.2 stable releases - 4.2, 4.2.1 etc are minor and micro releases but stable, with bug fixes i.e. minor is odd -> dev version, minor is even -> stable version This does not mean we work on two versions in parallel (we dont have the manpower), but it just to help distinguish between dev and stable versions I'm just pushing ideas out of my head. Now, with this process, we have three main requirements for Moose: - making it easy for anybody to retrieve (and identify it) the latest stable version - making integration in the main dev trunk the priority (we have limited resources, so each developer should take care to merge its changes in the main trunk, and start over from the main trunk for a new task, NOT always working in the same branches) - managing micro/nano releases from each developer I'm sorry if this feels too complicated and overly complex, it is not. I'm just playing with different schemas and see what could work best. ----------------------------------------------------------------------------------------------------------------------------- Now of course Metacello should not care about conventions (minor, micro...) of each project. Your proposition seems reasonable and flexible enough. But then, how can I ask for a version with a specific blessing? On 4 déc. 2009, at 18:48, Dale Henrichs wrote: > > Thinking off the top of my head, would it be work to supply a > pattern of some sort as an arg? Something like: > > ConfigurationOfXXX project lastVersion: '*.*' > > Not a real regex (because of the periods would need to be escaped, > but mainly because reading regex for me is like trying to read > russian:). > > Maybe best is a special purpose character like '#' in addition to > the standard(?) smalltalk patterns '*' and '?': > > ConfigurationOfXXX project lastVersion: '#.#' ---> matches all > major.minor > ConfigurationOfXXX project lastVersion: '1.#' ---> matches all > 1.minor > ConfigurationOfXXX project lastVersion: '*' ---> is current > algorithm > ConfigurationOfXXX project lastVersion: '*.0' ---> matches > versions with trailing .0 > ConfigurationOfXXX project lastVersion: '?.#' ---> matches single > character major.minor I dont see what is the use of this one? > ConfigurationOfXXX project lastVersion: '1.#.3' ---> is invalid > > This one seems to the right approach ... I can add a #match: method > to MetacelloVersionNumber to implement the pattern matching. > > What do you think? > > Dale > > ----- "Simon Denier" <Simon.Denier(a)inria.fr> wrote: > > | Suppose I have versions like this: > | 1.3.2 #development --> branch by a developer > | 1.3.1 #development --> branch by a developer > | 1.3 #development --> main trunk, last dev > | 1.2 #stable --> main trunk, last stable > | > | When I perform a ConfigurationOfXXX project lastVersion, I would > like > | > | to retrieve the config for the last dev version common to everybody, > | > | and I would like this to be 1.3, not 1.3.2 which is the work of one > | guy not yet merged in the main trunk. > | > | Right now, I get 1.3.2 > | > | Perhaps we could have something like this: > | 1.3.2 #branch --> branch by a developer > | 1.3.1 #branch --> branch by a developer > | 1.3 #development --> main trunk, last dev > | 1.2 #stable --> main trunk, last stable > | > | and branch would be an 'unstable' tag ignored by the loader when > | asking for latestVersion or lastVersion (and veryLastVersion could > | retrieve the latest version, be it a branch, dev, or stable). > | > | I have no special requirements here, I'm just playing with the idea > | and process of how to manage micro releases with Metacello. > | > | -- > | Simon -- Simon

15 years, 7 months

2
1
0 0

for mondrian designers

by stephane ducasse

vedea: new microsoft scripting graphices.... http://blogs.zdnet.com/microsoft/?p=4691 and http://processing.org/ The future of mondrian may be in Cairo support or Juan works. So consider to have a look at the cairo package in PharoTaskForces because it will not come to you alone :) Stef

15 years, 7 months

5
12
0 0

Re: mse file export doesn't work

by Tudor Girba

Thanks Fabrizio, Please provide the following info: - inFusion version - case study (how to get the code) so that I can reproduce the problem. Cheers, Doru On 4 Dec 2009, at 12:43, Fabrizio Perin wrote: > Hi Tudor, > i have problem to export the mse file from inFusion. It doesn't work > form the command line. Trying in the GUI I get this message: > > FAMIX 3.0 MSE Exporter could not be run ! > java.lang.NullPointerException > at > com > .intooitus > .infusion > .util.FAMIX30MSEExporter.visitMethod(FAMIX30MSEExporter.java:171) > at com.intooitus.memoria.core.Method.accept(Method.java:222) > at > com > .intooitus.infusion.util.MSEExporter.exportToStream(MSEExporter.java: > 70) > at > com > .intooitus > .infusion > .plugins.tools.memoria.MSEExporterTool.run(MSEExporterTool.java:40) > at > com > .intooitus > .infusion > .gui.ui.EntityMouseAction.actionPerformed(EntityMouseAction.java:198) > at > javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java: > 2028) > at javax.swing.AbstractButton > $Handler.actionPerformed(AbstractButton.java:2351) > at > javax > .swing > .DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:387) > at > javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:242) > at javax.swing.AbstractButton.doClick(AbstractButton.java:389) > at > com.birosoft.liquid.LiquidMenuItemUI.doClick(LiquidMenuItemUI.java: > 492) > at com.birosoft.liquid.LiquidMenuItemUI > $MouseInputHandler.mouseReleased(LiquidMenuItemUI.java:1161) > at java.awt.Component.processMouseEvent(Component.java:6348) > at javax.swing.JComponent.processMouseEvent(JComponent.java:3267) > at java.awt.Component.processEvent(Component.java:6113) > at java.awt.Container.processEvent(Container.java:2085) > at java.awt.Component.dispatchEventImpl(Component.java:4714) > at java.awt.Container.dispatchEventImpl(Container.java:2143) > at java.awt.Component.dispatchEvent(Component.java:4544) > at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java: > 4618) > at java.awt.LightweightDispatcher.processMouseEvent(Container.java: > 4282) > at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4212) > at java.awt.Container.dispatchEventImpl(Container.java:2129) > at java.awt.Window.dispatchEventImpl(Window.java:2475) > at java.awt.Component.dispatchEvent(Component.java:4544) > at java.awt.EventQueue.dispatchEvent(EventQueue.java:635) > at > java > .awt > .EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java: > 296) > at > java > .awt > .EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:211) > at > java > .awt > .EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java: > 201) > at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java: > 196) > at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java: > 188) > at java.awt.EventDispatchThread.run(EventDispatchThread.java:122) > > Hope that can help you. > > Cheers, > > Fabrizio > -- www.tudorgirba.com "We are all great at making mistakes."

15 years, 7 months

4
8
0 0

building a MooseModel is very long

by Cyrille Delaunay

For example you can run the method MooseModel class >> mseExportationTest I remember that some times ago ( some weeks) it was not as long as that. Is it normal ? Am I doing something wrong ?

15 years, 7 months

3
12
0 0

issue tracker

by Tudor Girba

Hi, I would kindly ask you to place an entry in the issue tracker before you start working on something (even if it's not a bug): http://code.google.com/p/moose-technology/issues/list Also, when you add an issue, please make sure to tag it at least with the Component that is affected by it. If you want to work on it, also assign it to yourself. This has the benefit of communicating your intention around and synchronize with the rest of us. If you want to be up to date with the changes in the issue tracker, you can subscribe to the RSS feed: http://code.google.com/feeds/p/moose-technology/issueupdates/basic Cheers, Doru -- www.tudorgirba.com "Beauty is where we see it."

15 years, 7 months

5
13
0 0

Re: [Fame-dev] Re: Changes in Fame

by Adrian Kuhn

If there are not dependencies back to Moose, having the filter in Fame is genau the right place. --AA On Dec 3, 2009, at 11:49 , Cyrille Delaunay wrote: > Ok. But the class 'ParseClientFilter' is not FAMIX-specific and I > thougth it would maybe be usefull for fame. If it's not, I can move > it into a moose package :) > > 2009/12/3 stephane ducasse <stephane.ducasse(a)gmail.com> > but cyrille > > FAMIX stuff should not polute Fame > so you should extend (subclass) in moose pckage and hope that FAME > will take your extension into account. > > Stef > On Dec 3, 2009, at 11:34 AM, Cyrille Delaunay wrote: > > > Hi, > > > > I just save some changes on the Fame squeaksource repository: > > > > - Implement a 'ParseClientFilter' that enable to parse and import > mse filtering some elements. This is use in Moose to specify the > FAMIX elements (FAMIX.Class, FAMIX.Method, ...) you want to import > in a MooseModel from a MSE File (This is already available by > selecting 'import from MSE' in the MoosePanel). > > > > - Two Lint rules in Fame-Util about the Moose issue 143 > > -> checking if a FM3 class respect the fame name convention > between FM3 and Smalltalk > > -> checking if the superclass defined in a FM3MetaDescription > t exist and is well defined. > > > > > > > > >

15 years, 7 months

1
0
0 0

mse import wizard

by Tudor Girba

Hi Cyrille, The MSE Import Wizard is a good step forward, but it has a problem: The entity types are hardcoded. This is a big problem because we should be able to load any entity. It would be better if that list would be gathered from the types from MooseModel meta. ImportingContext should not be hardcoded either, but it should be computed from the same repository by traversing the properties. For example, in FAMIXMethod>>parentType says that FAMIXClass is required for FAMIXMethod. In the same time, FAMIXMethod is not required for a FAMIXClass because the property FAMIXClass>>methods isDerived. Basically in this way, we should be able to create the graph dynamically and thus we can use the mechanisms for any meta-model. What do you think? In the meantime I restored the previous implementation as a temporary solution, because now we have PrimitiveType that should also be loadable. Cheers, Doru -- www.tudorgirba.com "From an abstract enough point of view, any two things are similar."

15 years, 7 months

3
9
0 0

inFusion 7.2.6

by Tudor Girba

Hi, inFusion 7.2.6 was just released: http://www.intooitus.com/infusion/download/inFusion.zip With it, we now have export of PrimitiveType and of declaredType for Method, Function and all variables. Also the access modifiers are now correct. Cheers, Doru -- www.tudorgirba.com "No matter how many recipes we know, we still value a chef."

15 years, 7 months

2
1
0 0

About Metacello and the Moose process

by Simon Denier

Unfortunately, there have been too many threads this morning *About Metacello* Well Metacello is still in beta, so good news is that we can make it better. Problem is that it can do a lot of things about which we (I) dont a clear picture for now, it requires some usage and conventions, and myself I'm still quite unsure about how Metacello manages nested configuration (for example right now, when I perform a ConfigurationOfMoose updateDefault, it does not update the nested configurations. I am not sure but I think it should) Suggestions: 1) have better names loadLast -> loadDevVersion or loadVeryLast loadLatest -> loadStableVersion or loadLastStable (those 2 are really annoying) Also the names in the OB commands could be better and reflect the current conventions: Save project -> save configuration update project -> update configuration Update Package Methods -> update current version??? Now, when I do a "Current Project Version" on any ConfigurationOf, it does not work except for the one with Metacello. I dont know, maybe the configurations do not respect some rules? It's annoying because it breaks the above tools. 2) refactor the documentation When I started with Metacello 3 months ago it was easy because there was one recent post describing the things. Now three months later this is a problem because things have changed a lot but this post is still the first hit in google "metacello" http://gemstonesoup.wordpress.com/2009/08/25/metacello-package-management-f… Now if you try to follow links there is this post and then this post http://gemstonesoup.wordpress.com/2009/10/14/a-shiny-new-api-for-metacello/ http://gemstonesoup.wordpress.com/2009/11/16/metacello-1-0-beta-14-released/ Finally it appears that http://code.google.com/p/metacello/w/list is now the source for documentation. There is the API reference for declaration, description of OBCommands,... Unfortunately it lacks something about how to play with last/latest versions with the API. - if I go to the tutorial, it just refers to the embedded tutorial in the code and I dont want to load the tutorial each time I need some documentation So please Dale, can you put a few items about things such as ConfigurationOfXXX project lastVersion, how to manipulate groups, things discussed with Lukas? 3) Good tool for managing configuration, saving projects... There is a small browser in GLMSmalltalkExamples>>metacelloBrowser, maybe somebody can start to enhance it to display version and perform commands. *About the Moose process* I dont think the Pharo process and the Moose process compare. The Pharo process is about integrating fixes from packages which are supposed to do one and only one thing, and do it well and is tested. The Moose process is about developers making incremental changes to the code base so that they can work and share it immediately. Which means it can break other things. Now I'm pretty sure I dont want a release every time someone commits a package in Moose, because I'm pretty sure this someone didn't run all the tests before committing. So making a release for each new commit makes no sense for me. We dont integrate changes, we just merge when there are some divergent branches. That's why we are always working with the dev version and the 'default' is one way to do it. If we want historical data about Moose, I guess it's still possible to retrieve all latest packages at a given date. It will not be very different from what we used at this date. Now about the *release* process for Moose: sure I would like that there will be more releases. Now as Doru said, when we do a release, we should do it for every sub projects and it's bit difficult with the current tools. - One way to do automatically it is to use the test server to at least create a new version from the latest dev version and blessed it as 'tested' if 100% tests passed or 'broken' But I dont want such versions to pollute the manual versions, which are supposed to be stronger. So something like create automatically 'testedVersionXXX' with tests or broken as possible blessing. - Then we can do manual release from time to time (every two weeks, every months?), which requires more work as we have to do it for the different subprojects first, and blessed it as beta or stable. BTW, why is the beta version in Moose marked as 'baseline'? It does not make sense. It should be beta or stable. -- Simon

15 years, 7 months

3
12
0 0

faster stream

by Stéphane Ducasse

hi guys Apparently nicolas cellier is implementing faster stream so this would probably help moose loading huge models. Nicolas could you let us know when you have a version that we can try. We could come up with real bench on really large files. Cyrille it could be really worth that you have a look. There is a thread on squeak-dev Stef

15 years, 7 months

3
3
0 0

Re: About Metacello and the Moose process

by Dale Henrichs

----- "Simon Denier" <Simon.Denier(a)inria.fr> wrote: | Unfortunately, there have been too many threads this morning | | *About Metacello* | | Suggestions: | 1) have better names | loadLast -> loadDevVersion or loadVeryLast | loadLatest -> loadStableVersion or loadLastStable | (those 2 are really annoying) | | Also the names in the OB commands could be better and reflect the | current conventions: | Save project -> save configuration | update project -> update configuration | Update Package Methods -> update current version??? Yeah, I have sucked in creating names for things ... and the terminology has evolved. Frankly, at the moment I am caught in between two points, where I'm not sure that the new names are really really better and the desire to avoid changing the tool labels too frequently ... You are raising good points, so I will be interested in what other people think in terms of naming suggestions ... I have holiday time coming as well (today and tomorrow are "vacation" days), so I will spend some time thinking about names... | | Now, when I do a "Current Project Version" on any ConfigurationOf, it | does not work except for the one with Metacello. I dont know, maybe | the configurations do not respect some rules? It's annoying because it | breaks the above tools. I am very interested in these problems ... a pointer to the ConfigurationOf package that is causing the problem would allow me to fix the problem. In the recent releases of Metacello I have fixed the problems that I've seen and am interested in getting the issues shaken out. | | | 2) refactor the documentation | When I started with Metacello 3 months ago it was easy because there | was one recent post describing the things. Now three months later this | is a problem because things have changed a lot but this post is still | the first hit in google "metacello" | http://gemstonesoup.wordpress.com/2009/08/25/metacello-package-management-f… | | Now if you try to follow links there is this post and then this post | http://gemstonesoup.wordpress.com/2009/10/14/a-shiny-new-api-for-metacello/ | http://gemstonesoup.wordpress.com/2009/11/16/metacello-1-0-beta-14-released/ | | Finally it appears that | http://code.google.com/p/metacello/w/list | is now the source for documentation. | | There is the API reference for declaration, description of OBCommands,... | Unfortunately it lacks something about how to play with last/latest | versions with the API. | - if I go to the tutorial, it just refers to the embedded tutorial in | the code and I dont want to load the tutorial each time I need some | documentation | | So please Dale, can you put a few items about things such as | ConfigurationOfXXX project lastVersion, how to manipulate groups, | things discussed with Lukas? Excellent points ... I will take a crack at cleaning up the documentation. | | 3) Good tool for managing configuration, saving projects... | There is a small browser in GLMSmalltalkExamples>>metacelloBrowser, | maybe somebody can start to enhance it to display version and perform | commands. | | | *About the Moose process* | I dont think the Pharo process and the Moose process compare. | | The Pharo process is about integrating fixes from packages which are | | supposed to do one and only one thing, and do it well and is tested. | | The Moose process is about developers making incremental changes to | the code base so that they can work and share it immediately. Which | means it can break other things. | Now I'm pretty sure I dont want a release every time someone commits a | | package in Moose, because I'm pretty sure this someone didn't run all | | the tests before committing. So making a release for each new commit | makes no sense for me. We dont integrate changes, we just merge when | there are some divergent branches. That's why we are always working | with the dev version and the 'default' is one way to do it. | | If we want historical data about Moose, I guess it's still possible to | retrieve all latest packages at a given date. It will not be very | different from what we used at this date. | | Now about the *release* process for Moose: sure I would like that | there will be more releases. Now as Doru said, when we do a release, | we should do it for every sub projects and it's bit difficult with the | current tools. | - One way to do automatically it is to use the test server to at least | create a new version from the latest dev version and blessed it as | 'tested' if 100% tests passed or 'broken' | But I dont want such versions to pollute the manual versions, which | are supposed to be stronger. So something like create automatically | 'testedVersionXXX' with tests or broken as possible blessing. | - Then we can do manual release from time to time (every two weeks, | every months?), which requires more work as we have to do it for the | different subprojects first, and blessed it as beta or stable. Metacello does have the notion of a #development version. #development means that the specification of the version is in flux and may change over time ... It sounds like you'd want to use the #development version for the 100% tested versions, then when you are ready to snap off a real version, you'd mark all of the development versions as beta or stable or whatever (for all the contricuting projects) and then open a new #development version. BTW when I say development version I mean something like: version '1.1' with a #development blessing. Dale

15 years, 7 months

3
2
0 0

how to we produce new version of moose

by Stéphane Ducasse

Hi I ***REALLLY*** want that we are able to use moose for future code analysis so I want to be able to script and reload version of moose. So now if I modify something in moose how do I create a new version in ConfigurationOfMoose? Stef

15 years, 7 months

3
5
0 0

duplication between default: and version40beta2:?

by Stéphane Ducasse

15 years, 7 months

7
14
0 0

please make sur that configuration are up to date.

by Stéphane Ducasse

for example ConfigurationOfCAnalyzer was not.

15 years, 7 months

4
6
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev