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?
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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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
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."
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.
