Moose-dev December 2009

moose-dev@list.inf.unibe.ch

29 participants
67 discussions

by Laval Jannik

Hi all, Is it possible to add actions in a Mondrian Pane in Glamour ? I would like to add somethink like: ----- browser mondrian title: 'test'; act: [:each | each selection inspect] entitled: 'inspect'; painting:....... ----- But now, it does not work. Is there another way to do it ? Cheers, --- Jannik Laval ---

15 years

Glamour view update triggering, how?

by Johan Fabry

Hi all, a question: I have a tree on a collection of elements, with the following specification: tags: [:asp | {asp show ifTrue:[MenuIcons smallOkIcon] ifFalse: [MenuIcons smallCancelIcon]}]; act: [:tree | |asp| asp := tree selection. asp show: (asp show not) ] on: $t entitled: 'Toggle On/Off (t)'; Now when the toggle action is performed, the tree should redisplay, as the tag needs to change. (adding a tree update within the act block does not work :-( ) How do I achieve this? Thanks in advance! -- Johan Fabry jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile

15 years

description of FAMIXPrimitiveType seems to not appear in 'MooseModel meta'

by Cyrille Delaunay

Hi, When executing 'FAMIXPrimitiveType asMooseDescription' we get an Error as result. The problem is that FAMIXPrimitiveType is not found in the moose metaRepository . Is it a normal behavior ?

15 years

Welcome and question!

by Mariano Martinez Peck

Hi folks! I have just subscribed to the mailing list. I have a little question for you. I want to analyze and see a graphic of a graph of objects and the references between them. Note that I want objects, at runtime. Not static, not classes. Is there something in Moose that I can use ? Cheers, Mariano

15 years

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

by Dale Henrichs

Mariano, Would you be in favor of the abstract class, if the abstract class itself had to be booted into the image? It's just a practical issue for me ... if we can count on the abstract class being preloaded in all dialects, then an abstract class makes sense. If we can count on Metacello being preloaded in some of the dialects, then the ensureMetacello method need only be present for portability to platforms in which Metacello is not preloaded. I don't disagree with the oddity of copy and paste. Earlier versions of Metacello configurations did rely on a superclass, but booting the superclass into the image was problematic. Granted bootstrapping would only be hard in Squeak, but it isn't supposed to be hard! The ensureMetacello method is only there for ease of bootstrapping software that is supposed to make it easy to boostrap software, but can't do the bootstrapping until it is bootstrapped itself:) I just hate the idea of making it harder to share configurations with Squeak... Dale ----- "Mariano Martinez Peck" <marianopeck(a)gmail.com> wrote: | On Fri, Dec 11, 2009 at 8:26 PM, Dale Henrichs | <dale.henrichs(a)gemstone.com>wrote: | | > 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? | > | | The first time I have to create my configuration, when I did the | tutorial, | and I have to copy paste the template I wondered myself why there | wasn't an | abstract configuration class :) | In my opinion, it is easier for the configurations. You put the | ensure | metacello and all those methods that are in the template there and | that's | all. | | So... +1 to have an abstract class for me. | | | > | > 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

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

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

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

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

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev December 2009