Moose-dev August 2010

moose-dev@list.inf.unibe.ch

27 participants
81 discussions

MooseGroups'concatenation - side effect
by Cyrille Delaunay 19 Aug '10

19 Aug '10

Hello, I got some problems by concatenating some mooseGroups together. You can evaluate this script in a workspace (it correspond to what I did in my code): |mooseModel| Transcript open. MooseScripts createLightModelForLAN. mooseModel := MooseModel root allModels detect: [:aMooseModel | aMooseModel name ='lightLAN']. "at the begening, all famixClasses from this model have methods" Transcript show: (mooseModel allModelClasses select: [:each | each methods isEmpty]) size asString, String cr. "here we do several concatenations with methods from all FAMIXClasses:" mooseModel allModelClasses do: [:aFamixClass | aFamixClass methods , aFamixClass inheritedMethods ]. "let see the new result: " Transcript show: (mooseModel allModelClasses select: [:each | each methods isEmpty]) size asString, String cr. You can see that after the concatenations, some FAMIXClasses have lost their methods. Is it a real problem or is it me that is missing something obvious?

3 2

may be any useful: compute C, C++, Javascript, python metrics
by Stéphane Ducasse 19 Aug '10

19 Aug '10

http://pypi.python.org/pypi/metrics/

1 0

Method invocation for Smalltalk code in Moose
by Alexandre Bergel 19 Aug '10

19 Aug '10

Hi! I am analyzing Mondrian in Moose. One thing that I am bumping into, is that wrong dependencies are inferred whereas I am sure that they do not exist. This is not a new, we have to type in Smalltalk. For example: MOEdge>>fromPositions ^ shape fromPositions #fromPositions is implemented 3 times, by MOAbstractLayout, MOEdge, and MOLineShape. In the case of MOEdge>>fromPositions, I am sure that it does not invoke MOAbstractLayout>>fromPositions I guess that everyone analyzing smalltalk code bumped into this very situation. My question is how do we do in that case? One easy solution, is to annotate Mondrian with an adequate pragma: MOEdge>>fromPositions <invoke: #fromPositions of: MOLineShape> ^ shape fromPositions We can decline this pragma into: <doesNotInvoke: #selector of: AClass> <invoke: #fromPositions of: #(MOLineShape MOEdge)> Simon told me Cyrille has worked on this problem. I am currently trying to use RoelTyper. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

5 10

RoelTyper
by Alexandre Bergel 19 Aug '10

19 Aug '10

Hi Roel! I hope you're fine. I tried to use RoelTyper to have more accurate method invocations in Moose. I use Mondrian as my case study. I tried in a workspace (TypeCollector typeInstvar: #shape ofClass: MOGraphElement ) types => an OrderedCollection(SmallInteger) This is surprising since I expect #shape to reference to an instance of a subtype of MOShape. I did: (TypeCollector typeInstvar: #shape ofClass: MOGraphElement ) interface => an IdentitySet(#shapeBoundsAt:ifPresent: #computeBoundsFor: #isCached #copy #defaultBounds #absoluteBoundsFor: #extentFor: #apply:bounds: #isFormsShape) #shapeBoundsAt:ifPresent:, #computeBoundsFor: are defined in MOShape and not SmallInteger. I probably miss something obvious here... Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

2 3

Extending the core of Mondrian
by Alexandre Bergel 18 Aug '10

18 Aug '10

Hi! The class MOAbstractLayout is in the category Layout. However, I believe it belongs to the Core since the Core cannot work without this class. MOAbstractLayout defines applyOn:, which is invoked by MORoot>>applyLayout. I will also rename MOAbstractLayout into MOLayout to keep the name short and consistent with MOShape (and not MOAbstractShape). If someone is against this, let me know. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

2 1

moosechef
by Tudor Girba 18 Aug '10

18 Aug '10

Hi Simon, Is MooseChef ready for a trial? :) Cheers, Doru -- www.tudorgirba.com "Being happy is a matter of choice."

4 5

FamixAssociation and sourceAnchor
by Simon Denier 17 Aug '10

17 Aug '10

I just noticed that FamixAssociation is a subclass of FamixSourcedEntity and as such, inherits a sourceAnchor field. To me, it sounds like we could define FamixAssociation>>sourceAnchor as a redirection: FamixAssociation>>sourceAnchor ^ self from sourceAnchor Indeed, an association is defined by the from side entity. Is there any practical case where we want to link a dedicated SourceAnchor object to an Association? -- Simon

3 5

Status of the Glamour-Seadide renderer
by Simon Denier 16 Aug '10

16 Aug '10

Hi Doru I would like to know what is the status of the Glamour-Seadide renderer? Is there some progress on this side? -- Simon

6 11

Looking for PhD candidates
by Tudor Girba 16 Aug '10

16 Aug '10

For your information. Doru Begin forwarded message: > From: Alexandre Bergel <alexandre(a)bergel.eu> > Date: 16 August 2010 15:01:49 GMT+02:00 > To: ESUG Mailing list <esug-list(a)lists.esug.org>, Pharo Development <Pharo-project(a)lists.gforge.inria.fr > > > Subject: [Pharo-project] Looking for PhD candidates > Reply-To: Pharo-project(a)lists.gforge.inria.fr > > Hi! > > The Chilean funding agency has a number of scholarships for doing a > PhD. If you have a master or an engineering diploma and you want to > work for 4 years on pharo and moose, contact me. > The PhD will have to be realized in Santiago. > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "Presenting is storytelling."

1 0

Mondrian and timelines
by Mircea Lungu 16 Aug '10

16 Aug '10

Hi guys, I would like to generate a view in which the versions of a project are ordered on a timeline. Is there a timeline layout in Mondrian? Thanks, M.

3 2

← 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 August 2010