Moose meta-model extension
by Andrea Caracciolo
Hi,
I'm writing to this mailing list for the first time, so let me shortly introduce myself: I'm a PhD student at SCG (prof. O. Nierstrasz / University of Bern) and i'm currently working on architecture validation.
I recently started a little project (a more flexible and generic version of moose chef), and since i wanted to display my output in moose i tried to build an extension to the moose meta-model.
What i did was creating a new class named FAMIXLiftedAssociation which extends FAMIXAssociation and has a 'from' and to 'to' attribute.
I defined the following methods:
to
<MSEProperty: #to type: #MooseEntity>
<MSEComment: 'to-side of the association'>
^ to.
from
<MSEProperty: #from type: #MooseEntity>
<MSEComment: 'from-side of the association'>
^ from
where both 'from' and 'to' attributes are MooseEntity objects.
On the class side i redefined:
annotation
<MSEClass: #FAMIXLiftedAssociation super: #FAMIXAssociation>
<package: #FAMIX>
^self
When i try to browse a group populated with instances of the above described class, i'm able to see them all correctly.
But as soon as i click on one of them i get the following error:
MessageNotUnderstood: receiver of "allPrimitiveAttributes" is nil
I guess the new class has not been recognized as being part of the moose meta-model. Am i wrong ?
Did i forget any pragma ?
Andrea Caracciolo
11 years, 6 months
[ANN] Roassal 1.28
by Alexandre Bergel
Dear Fellow,
A couple of weeks ago we have released the Roassal visualization engine. Many of you gave us feedback and we are deeply grateful for this.
Since we released the first version, we have closed 25 issues [*]. Many things are left to do, especially to satisfy all the requirements from the Moose community.
We are currently working on an HTML exporter for Roassal. We know this is a highly wanted feature. In a couple of weeks we should be able to deliver it.
Since the first release of Roassal, we have worked very hard on it and we will continue to do so.
Thanks to all of you!
Alexandre, Vanessa, Juan Pablo
[*] http://code.google.com/p/objectprofile/issues/list?can=1&q=status=Fixed%2...
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
11 years, 6 months
the owner of mondrian edges
by Tudor Girba
Hi Fabrizio.
Thanks for helping me reproduce the problem.
It should be fixed now.
However, there are still some red tests because they assume the old wrong behavior of assigning edges to an owner node.
Cheers,
Doru
On 26 May 2012, at 15:28, Fabrizio Perin wrote:
> Hi Doru,
> Here is the code you were working on:
>
> view := MOViewRenderer new.
> view nodes: #(2) forEach: [:each |
> view shape label.
> view node: each* 10.
> view shape label.
> view node: (each * 10 + 1).
> view treeLayout.
> ].
> view edgesFromAssociations: {"10->20. 10 -> 11 ." 20->21}.
> view open.
>
> Cheers,
> Fabrizio
--
www.tudorgirba.com
"It's not what we do that matters most, it's how we do it."
11 years, 6 months
displaced edges in the new version of Roassal
by Usman Bhatti
Hello,
I am having trouble with the new version of Roassal (downloaded with latest
moose version today), the edges are abnormally displaced (c.f: attached
figure).
Here is the script to generate the visu.
|mainNode view title childNodes ab mainTitle|
view := ROView new.
mainNode := (ROElement spriteOn: 'A Test Node') + ROBorder.
mainTitle := (ROLabelElement on: 'A Test Node') textColor: Color gray.
ab := Array with: 'Moose' with: 'Mondrian' with: 'Glamour'.
childNodes := OrderedCollection new.
ab do:
[:each |
element := ((ROElement spriteOn: each) + ROBorder).
title := (ROLabelElement on: each) textColor: Color red.
box := ROBox new color: Color transparent.
element addInteraction: RODraggable.
('Mondrian' matches: each) ifTrue: [box color: Color lightBlue].
('Glamour' matches: each) ifTrue: [box color: Color blue].
element add: title; addShape: box.
childNodes add: element.
].
view add: (ROEdge arrowedLineFrom: childNodes first to: childNodes second)
+ ROLine blue.
view add: (ROEdge arrowedLineFrom: childNodes first to: childNodes third) +
ROLine blue.
view add: (ROEdge arrowedLineFrom: childNodes second to: childNodes third)
+ ROLine blue.
mainNode addAll: (ROGridLayout on: childNodes).
view addAll: (ROVerticalLineLayout on: (Array with: mainTitle with:
mainNode)).
view open
Should I open a bug entry?
thanx
Usman
[image: Inline image 1]
11 years, 6 months
filterOn: in glamour
by Usman Bhatti
Hello all,
I am trying to understand the functionality of filterOn: method in
GLMListingPresentation. I am not able trigger the block in glamour examples
by typing the search criteria in the provided search box (c.f:
multipleFinderWithFilter example). How do we trigger the filterOn: block so
that the matching entities appear in the next pane of the example?
What I am trying to achieve is to reduce the list of items in a tree with
the criterion provided in the search box. Currently with the searchOn:
block, I can select the matching entities in the tree, my idea is to remove
the entities from the tree which do not fulfill the selection criterion.
tx
Usman
11 years, 6 months
graph of object references
by Tudor Girba
Hi,
I would need to debug memory leaks (maybe induced by announcements), and for that I am thinking to use a graph of object references.
I guess this would be easily possible with Fuel. If I have an object, how would I go about doing this?
Cheers,
Doru
--
www.tudorgirba.com
"Don't give to get. Just give."
11 years, 6 months
AbstractDistributionMap >> defaultTitleFormattingBlock looks wrong
by Mariano Martinez Peck
AbstractDistributionMap >> defaultTitleFormattingBlock
^ [ :each |
| t |
t := each.
(t beginsWith: 'Citezen-')
ifTrue: [ t := t copyReplaceAll: 'Citezen-' with: 'C' ].
(t beginsWith: 'Seaside-')
ifTrue: [ t := t copyReplaceAll: 'Seaside-' with: 'S' ].
t := t copyReplaceAll: 'Tests-' with: 'T-'.
"t := (Kontract reduce: t upTo: 10)."
t ]
On the one hand, it hardcodes stuff like Citizen or Seaside. But what is
worse is that that Kontract does not exist...
Cheers,
--
Mariano
http://marianopeck.wordpress.com
11 years, 6 months
New release of FuelMooseExtension
by Mariano Martinez Peck
Hi Doru. I have updated FuelMooseExtension to work with the latest stable
version of Fuel 1.8. I think this is worth it because:
1) Right now you are using an old version of Fuel (1.6) which is like an
year ago. The older it is the more difficult it will be in the future to
update.
2) If you don't take into account the time to compute attributes we can
have improvement up to 30% in export time.
3) Fuel 1.8 is integrated by default in Pharo 2.0 now, meaning that you
will have problems when moving Moose to Pharo 2.0 (because you would need
1.6).
Of course the bad news is that if you have already exported files you won't
be able to import them with this new version.
If you agree, let me know. I will create a new version 1.5 in
ConfigurationOfFuelMooseExtension but I don't know how the Moose image is
built (it seems it is not using ConfigurationOfFuel).
Cheers
--
Mariano
http://marianopeck.wordpress.com
11 years, 6 months
Issue 501 in moose-technology: Cache independence
by moose-technology＠googlecode.com
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 501 by alexandr...(a)gmail.com: Cache independence
http://code.google.com/p/moose-technology/issues/detail?id=501
The core of Mondrian is not independent of the cache implementation. The
logic of Mondrian rely on the cache to implement its semantics. This is
obviously wrong.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
bounds
"Answer the bounds of the receiver."
"the bounds is has an absolute origin"
"Note that the bounds computed above, may have (and it is likely to) a
different origin. The reason is that the layout is in charge to position
the nodes properly"
| basicBounds |
boundsCache ifNotNil: [ ^ boundsCache ].
"We check if the shape if present"
self shapeBoundsAt: self shape ifPresent: [ :b | ^ boundsCache := b ].
basicBounds := self shape computeBoundsFor: self.
self shapeBoundsAt: self shape put: basicBounds.
^ boundsCache := basicBounds
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
translateAbsoluteCacheBy: aPoint
absoluteBoundsCache ifNil: [ ^ self ].
absoluteBoundsCache := absoluteBoundsCache translateBy: aPoint
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Thanks to Santiago Vidal for pointing this out!
11 years, 6 months
