Moose-dev October 2010

moose-dev@list.inf.unibe.ch

24 participants
90 discussions

Re: a question with glamour
by Stéphane Ducasse 26 Oct '10

26 Oct '10

On Oct 25, 2010, at 12:45 PM, Esteban Lorenzano wrote: > Hi, > I'm making my "first steps" with glamour and I have a question (a couple of then, actually). Excellent. I want to start too. > > 1) I what to hear some events, like for example when something changes in a list > 2) I what to pre-select some item in a list > > How I can do this? > > Thanks, > Esteban > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev

1 0

could we have a fly by help with the syntax in the query pane?
by Stéphane Ducasse 26 Oct '10

26 Oct '10

cyrille this would good to have a flybyhelp in the query pane. Stef

2 1

Re: a question with glamour
by Esteban Lorenzano 25 Oct '10

25 Oct '10

Hi, I'm still lost here :( What I want is to listen the GLMTreeMorphSelectionChanged event, and I can't find a way to do it... and the example is a little bit confusing for me :(. Cheers, Esteban

2 1

a question with glamour
by Esteban Lorenzano 25 Oct '10

25 Oct '10

Hi, I'm making my "first steps" with glamour and I have a question (a couple of then, actually). 1) I what to hear some events, like for example when something changes in a list 2) I what to pre-select some item in a list How I can do this? Thanks, Esteban

2 1

Re: PackageCacheTest failing
by Simon Denier 25 Oct '10

25 Oct '10

On 24 oct. 2010, at 10:26, Tudor Girba wrote: > Hi, > > It looks like we have one failing test. > > This is due to the fact that somehow we have a new Collections package in our image, and because of that counting the amount of packages in the cache fails. This is: > a PackageInfo(Collections-CharacterMap) > > In a previous image, we did not have that even though the base image is just the same. Does anyone know where this comes from? Apparently, this is a dependency coming from XMLSupport. CharacterMap is referenced in class-side initializer. The package dependency was a bit difficult to track down, it is actually a monticello required package of XML-Parser. I guess we should just update the test (although I would like the dependency to CharacterMap to appear in the Configuration, rather than as a required package) Name: XML-Parser-JAAyer.97 Author: JAAyer Time: 23 October 2010, 12:38:30 pm UUID: 9b2bd823-569f-447a-a7bc-a8c9fd474f5f Ancestors: XML-Parser-JAAyer.96 Dependencies: Collections-CharacterMap-JAAyer.1 * #qualifiedName is deprecated; #name suffices. * Refactored XMLNodeTest and XMLNestedStreamReader * CharacterMap is now bundled separately. -- Simon

2 1

PackageCacheTest failing
by Tudor Girba 24 Oct '10

24 Oct '10

Hi, It looks like we have one failing test. This is due to the fact that somehow we have a new Collections package in our image, and because of that counting the amount of packages in the cache fails. This is: a PackageInfo(Collections-CharacterMap) In a previous image, we did not have that even though the base image is just the same. Does anyone know where this comes from? Cheers, Doru -- www.tudorgirba.com "Beauty is where we see it."

1 0

Reporting system
by Cyrille Delaunay 22 Oct '10

22 Oct '10

Hello, The reporting system based on arki, on which I work, start to be 'usable'. Some goals was to: - implement a first set of concerns to be able to make a first try with pharo as model ( http://code.google.com/p/moose-technology/wiki/PharoHealthSystem) - have an interface allowing to easily build, modify, save, display reports (an extended arki browser). - be able to export a report as MSE, then be able import a mse file. For now all of that seem to work not so bad :) but I'm sure there is a lot of thing to change, improve that I have not yet (or maybe no longer) in mind. If you want to have a look you can evaluate this script in a fresh moose image: Gofer new squeaksource: 'MooseDemoReport'; package: 'System-Benchmarking'; load. Gofer new squeaksource: 'MooseDemoReport'; package: 'MooseComputedConcerns'; load. Then you can simply right click on a model in the moosePanel, 'open arki reporter', and follow instructions. Any comment about: how it could better, what you would like to be able to do, things that seems to be wrong or not well implemented are welcome. The name of the repository is clearly bad, and I have also to change the name of of the package. An idea for the package name is: Menssana, (shortcut for "Mens sana in corpore sano"). If you have any suggestion, I would be really happy. A think with which I have some difficulties, is to see the 'borders' between this package and the arki package. We have an arki package providing the basic structure to build reports and this new package mainly making extensions to the arki package. So I don't know if some things should be merged, and what should be merged? Then I think I could start to set up automatic jobs with hudson that archive (at least for now) the mse exported files of a 'PharoHealthReport'. Then see how we manage to deal with the 'evolution' aspect

3 3

smalldude tests
by Tudor Girba 22 Oct '10

22 Oct '10

Hi Cyrille, Your modifications to SmallDude look nice, but they make the tests fail because probably some entities are not initialized with the mooseModel. Please take a look, because right now the Moose build is yellow. Cheers, Doru -- www.tudorgirba.com "Speaking louder won't make the point worthier."

1 1

Re: [Fame] MooseEntity >>handleFameProperty:value:
by Simon Denier 21 Oct '10

21 Oct '10

On 21 oct. 2010, at 17:34, Cyrille Delaunay wrote: > > > 2010/10/21 Cyrille Delaunay <cy.delaunay(a)gmail.com> > Hello, > > Currently, i'm looking a bit at the way moose export and import entities using Fame descriptions. > handleFameProperty:value: is a method used by fame when we try to set a value to an attribute not described in the current metaModel used to import. By default It does nothing and just inform by writing in the Transcript. > > A thing that I understand (or at least that I think I understand :)) is that the method handleFameProperty:value: is overriden by MooseEntity for this reason: > If an attribute is not described in the metaModel, this is certainly a property from the cache and therefore we should store this value in the cache of the element. This is what the method handleFameProperty:value: does in MooseEntity. > > I was wondering if it would be a good idea to look before if a mutator selector does not exist for the property name and only after that store in the cache. Usually when you use the classic exporter from moose, you can not be in this case, because the metamodel use to export is exactly the same than the one to import. It could be. This is what Fame does anyway for regular property. > In my case,I generate my own metaModel to export (subclassing PragmaProcessor) and export some property that are not described with Fame pragmas (what did usually the classic exporter). Those properties will therefore be lost. > Maybe the idea is also that if you export with a specific metaModel, you should import with this same specific metaModel ? > > In fact I guess this is the best solution :) I am able to re-compute the meta-model, give it to the fame importer and it seems to work well. > At least you are aware of my thoughts of the day :) Yes that's certainly the way to go. I want to be able to quickly specify a metamodel to reuse Fame facilities like import-export. Then let Fame handles all the process. We will se tomorrow for the thing with pragma :) -- Simon

1 0

[Fame] MooseEntity >>handleFameProperty:value:
by Cyrille Delaunay 21 Oct '10

21 Oct '10

Hello, Currently, i'm looking a bit at the way moose export and import entities using Fame descriptions. handleFameProperty:value: is a method used by fame when we try to set a value to an attribute not described in the current metaModel used to import. By default It does nothing and just inform by writing in the Transcript. A thing that I understand (or at least that I think I understand :)) is that the method handleFameProperty:value: is overriden by MooseEntity for this reason: If an attribute is not described in the metaModel, this is certainly a property from the cache and therefore we should store this value in the cache of the element. This is what the method handleFameProperty:value: does in MooseEntity. I was wondering if it would be a good idea to look before if a mutator selector does not exist for the property name and only after that store in the cache. Usually when you use the classic exporter from moose, you can not be in this case, because the metamodel use to export is exactly the same than the one to import. In my case,I generate my own metaModel to export (subclassing PragmaProcessor) and export some property that are not described with Fame pragmas (what did usually the classic exporter). Those properties will therefore be lost. Maybe the idea is also that if you export with a specific metaModel, you should import with this same specific metaModel ?

1 1

← Newer
1
2
3
4
5
6
7
8
9
Older →

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev October 2010