Re: a question with glamour
by Stéphane Ducasse
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
12 years, 11 months
Re: a question with glamour
by Esteban Lorenzano
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
12 years, 11 months
a question with glamour
by Esteban Lorenzano
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
12 years, 11 months
Re: PackageCacheTest failing
by Simon Denier
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
12 years, 11 months
PackageCacheTest failing
by Tudor Girba
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."
12 years, 11 months
Reporting system
by Cyrille Delaunay
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
12 years, 11 months
smalldude tests
by Tudor Girba
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."
12 years, 11 months
Re: [Fame] MooseEntity >>handleFameProperty:value:
by Simon Denier
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
12 years, 11 months
[Fame] MooseEntity >>handleFameProperty:value:
by Cyrille Delaunay
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 ?
12 years, 11 months
