Moose-dev June 2012

moose-dev@list.inf.unibe.ch

20 participants
112 discussions

Moose meta-model extension
by Andrea Caracciolo 05 Jun '12

05 Jun '12

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

3 3

[ANN] Roassal 1.28
by Alexandre Bergel 04 Jun '12

04 Jun '12

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%20c… -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

3 3

the owner of mondrian edges
by Tudor Girba 04 Jun '12

04 Jun '12

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."

3 3

Jenkins build is still unstable: moose-latest-dev #960
by admin＠moosetechnology.org 04 Jun '12

04 Jun '12

See <http://hudson.moosetechnology.org/job/moose-latest-dev/960/>

5 55

displaced edges in the new version of Roassal
by Usman Bhatti 04 Jun '12

04 Jun '12

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]

2 2

filterOn: in glamour
by Usman Bhatti 03 Jun '12

03 Jun '12

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

2 3

graph of object references
by Tudor Girba 02 Jun '12

02 Jun '12

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."

2 2

AbstractDistributionMap >> defaultTitleFormattingBlock looks wrong
by Mariano Martinez Peck 01 Jun '12

01 Jun '12

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

3 4

New release of FuelMooseExtension
by Mariano Martinez Peck 01 Jun '12

01 Jun '12

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

4 11

Issue 501 in moose-technology: Cache independence
by moose-technology＠googlecode.com 01 Jun '12

01 Jun '12

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!

1 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev June 2012