Moose-dev December 2008

moose-dev@list.inf.unibe.ch

13 participants
14 discussions

Mondrian 4 Squeak
by Alexandre Bergel 26 Dec '08

26 Dec '08

Dear All, I am spending some time on the Squeak Version of Mondrian. It seems that there is a bug when on how edges are drawn. For example, the following code draw some edges between nodes that does not exist. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= | view nodes | nodes := Collection withAllSubclasses. view := MOViewRenderer new. view nodeShape: (MORectangleShape new width: [:each | each instVarNames size * 5]; height: [:each | each methodDictionary size ]). view nodes: nodes. view edges: nodes from: [:each| each superclass] to: [:each| each]. view layout: (MOTreeLayout new). view open -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= You can compare the result with the VW version: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= | nodes | nodes := Collection withAllSubclasses. view newShape rectangle; width: [:each | each instVarNames size * 5]; height: [:each | each methodDictionary size]; withBorder. view nodes: nodes. view edges: nodes from: [:each| each superclass] to: [:each| each]. view treeLayout. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= I also fixed a bug related to the translation of edges. It is in Mondrian@Squeaksource Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

1 1

Mondrian for Squeak
by Alexandre Bergel 24 Dec '08

24 Dec '08

Dear List, I am not sure whether this is the right list to ask this question. What is the current status of Mondrian for Squeak? The Squeak scripting facility is quite different from the one in VW. Is the squeak version stable ? I am just curious Merry Christmas to all of you, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

2 1

Difference between CodeFoo and CodeFooDev ?
by Alexandre Bergel 18 Dec '08

18 Dec '08

Is there an obsolete one? If yes, maybe it could be renamed so Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

4 3

Re: ci.Doctor Walter
by moose-dev＠iam.unibe.ch 16 Dec '08

16 Dec '08

1 0

About above: and below:
by Stéphane Ducasse 16 Dec '08

16 Dec '08

Hi doru in association we (simon and me) have problems with above: and below: (which only works for inheritance) we suggest from: to: which would have the benefit that when we do not want to distinguish between access and reference give us the interface with want. Access from a method to a structure Access accessor a method to a structure Reference from a method to a structure Inheritance from a class to its superclass Then I do not understand why the instance variable is defined both in the class and its superclass either we have abstract methods in Association and no state in Association and attributes in subclasses. or we have state in Association and method in subclass reuse this state (= no definition of other iv in subclasses) To help debugging we prefer to have state in subclasses and abtsract superclass methods. Stef

4 6

Moose core model
by Simon Denier 12 Dec '08

12 Dec '08

Hi I was wondering if I could get more explanations on the classes of Moose core: MooseElement - not sure why it is not merged with MooseEntity MooseEntity - described as the base class for any entity MooseAbstractGroup - abstract composite MooseGroup - my guess, a group of common entities like 'all packages', 'methods from selected class'. Comment says 'Group adds on top the ability to change the type of a group when we add more items inside', which is not clear to me MooseModel - a named group, created only when importing a project into Moose. I'm not sure why it is a sibling of MooseGroup and not, for example, a sibling. Now I am not sure how this model is handled through the moose finder. Any details to share? -- Simon

3 4

Property pragmas handling
by Simon Denier 11 Dec '08

11 Dec '08

Hi I was wondering how some pragmas should be handled in Moose? Apparently there is currently two "kind" of pragmas in use: the ones which begin with MSESomething are used to describe the model in Fame. But there is also a range of "property:longName:description:" pragmas which are used to describe entity properties like "numberOfMethods", "numberOfAccesses"... Such pragmas allow a generic mean to access some metrics, using MooseEntity#propertyNamed: But the implementation of #propertyNamed: relies on attributes which should be described in the metamodel. Now it seems that the responsibility to parse and interpret those pragmas belongs to Fame. Currently they are not handled, and I just found a TODO note in FM3MetaDescription#attributeNamed:ifAbsent: -- Simon

4 7

Mondrian - version
by Itsme (Sophie) 11 Dec '08

11 Dec '08

I loaded the latest Mondrian packages into Damien 3.10 dev on OSX in this order - announcements - mondrian - mondrian paintings Running all 26 tests gave 16 errors. MOFormsBuilderTest testAdvancedApi sort-of hangs the image (drawing not displayed until I Alt-. interrupt). I occasionally see MNU for MOLabelShape>>width Am I using an incorrect version/combination? Thanks ~ Sophie

2 3

About isStub and friend
by Stéphane Ducasse 11 Dec '08

11 Dec '08

Hi doru I would like to know what is the status of isStub in Famix30? I'm trying to get that working in FAMIX30 I have FAMIXEntity stub: aBoolean self isStub: aBoolean and isStub: is defined only on and EntityState FAMIXNamedEntity isStub: aBoolean isStub := aBoolean Then in MinimalState isStub: boolean [boolean == false] assert I imagine that the code above is only used when there is no property EntityState isStub: boolean ^self attributeSet: #privateIsStub value: boolean

2 1

Bump ... Mondrian question
by Itsme (Sophie) 10 Dec '08

10 Dec '08

Sorry if this is a repeat, not sure if my first post came through. Is it possible with Mondrian to do any of the following: - generate labels on graph edges e.g. names of association ends in a UML class diagram? - generate nodes like class nodes (with name, line, attributes list, etc.)? - possibly with some layout coding, generate component-port-connector models: labeled boxes, labeled lines between boxes, labeled mini-boxes on the edges of the connections - Are these reasonable usages of current Mondrian capability? Thanks!

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev December 2008