Alex this is strange because the log mention mondrian configuration file.
Begin forwarded message:
> From: Hani Abdeen <hani.abdeen(a)gmail.com>
> Subject: Pharo + Moose on Windows 7
> Date: December 4, 2011 8:52:57 PM GMT+01:00
> To: Stéphane Ducasse <stephane.ducasse(a)inria.fr>
> Hi Stef,
> I started reading "Pharo by Example" and "Moose book" and familiarizing myself with the new implementation of Moose.
> I use Pharo 1.3 release on Windows 7.
> Now, each time I open a clean image of Pharo and try to load the default configuration of Moose, using the code below, I get an error or the VM crashes!
> Gofer new
> squeaksource: 'MetacelloRepository';
> package: 'ConfigurationOfMagma';
> ((Smalltalk at: #ConfigurationOfMagma) project latestVersion) load
> The error Stack and the crash dmp file are herewith attached for more information.
> I thought that before all I should ask you if I have to use another release of Pharo or if I have to load Moose differently...
> Thanks in advance,
> Dr. Hani Abdeen
> Phd. in Software Engineering - RMod, INRIA Lille-Nord Europe
Labels: Type-Defect Priority-Medium Component-EyeSee Milestone-4.6
New issue 755 by tu...(a)tudorgirba.com: EyeSee form does not properly take
into account the size of axis labels
It seems that the bounds of the form do not take into account the size of
the axis labels. Because of this, we get a cropped picture when we export,
and we get some refresh problems.
Try the following:
(ESExamples new verticalBar7 findDeeplyA: ESCanvas) exportAsPNG
If you inspect the resulting image, you will see that both the bottom
labels and the right one gets trimmed.
I did several "improvements" to MooseChef.
Reviews are welcome (Simon if you are around, please read this, specifically, at the end) .
- Created withoutSelfLoops in MooseQueryObjectResult as discussed before (see discussion on MooseChef end of november)
- Renamed all queryXxxIncoming/OutgoingDependencies to queryXxxIncoming/OutgoingAssociations (see discussion on MooseChef & hidden dependencies last week)
- Introduced a virtual association : Instanciation that relates a variable (structuredEntity to its type and a method (behaviouralEntity) to its returnType. I created MooseChefInstanciationAssociation for this. It is not in Famix as it is only intended to do queries.
- Followed up with creating appropriate queryIncoming/OutgoingInstanciations in FamixPackage , FamixClass, FamixMethod
All this has been tested and commited (this morning). Documentation on the web site was not updated
Meanwhile, I performed other modifications/corrections:
- Better comment initiative: commented some MooseQueryResult classes
- FamixPackage and FamixNamespace had the same classScope method that [only makes sense to reject self loops in #collectAtScope:], I moved it to FAMIXScopingEntity.
- I found strange that there was no methodScope method, for consistency, I added it, again in FAMIXScopingEntity.
- Still for consistency, I added a methodScope method to FamixType
Finally, I still have some questions (Simon?)
- the trait TScopingEntityQuery seems to exist only to be added to FamixScopingEntity. Is that so?
Why having a trait in this case? Consistency? If so, may be it should be documented (comment).
- MooseOutgoingCompositionQueryResult does not use TDependencyQueryResult whereas its sisters (MooseOutgoing/IncommingQueryResult) do. This means MooseOutgoingCompositionQueryResult is lacking many selectors that its sisters have (opposites, ...)
Error or feature?
I have an inconvenient with the positions in which edges are being drawn. Attached a screenshot to explain what is happening.
My visualization displays at the beginning all the edges (grey), and then when interacting with a node, its edges change color.
However, when drawing the edges in another color (green/red) some appear in a different location (see the red one).
For me this creates confusion as it seems to be a different edge (i know that when drawing it's a different object but i think it should appear in the same location as most of them do).
I thought that it was related with the type of line (arrowed) but in fact the same happens with a simple line or in a different layout.
This case in particular uses the dominance tree layout.
Now I am wondering if that is a bug of the layout or of the edge's drawing itself. And, if this can be fixed..
Labels: Type-Engineering Priority-Medium Component-Famix
New issue 753 by usman.bh...(a)gmail.com: Move annotations to NamedEntities
Usman and Nicolas, we are working on improving comments of Famix entities.
We thought that this thing is worth discussing.
Should all famix entities have annotations? For example, source-language,
source-anchor and associations cannot be annotated.
Good question. This is a question that we discussed a long time ago,
and we did not come up with a proper answer so, we just made it
However, in the meantime we learned a bit, and now we know that it
does not make sense to have annotation instances higher than
NamedEntity. So, we can safely move it there.
Labels: Type-Enhancement Priority-Medium Component-Metanool Milestone-4.6
New issue 726 by andreho...(a)gmail.com: FM3PropertyDescription>>getRawFrom:
should return false in Boolean properties instead of nil
It avoids to use the binary message into the Finder with meta-annotated
Boolean properties when using Metanool.
For example, instead of:
each annotations hugeClasses = true
each annotations hugeClasses
What do you think?
Code to fix it is below.
^ element privateState
attributeAt: self name
(self type = FM3 boolean)
ifFalse: [nil] ]
Labels: Type-Defect Priority-Medium Component-Famix Milestone-4.6
New issue 758 by tudor.gi...(a)gmail.com: referenced/referencing* FAMIX
navigation methods should be named invoked/invoking*
This is has long been a problem.
An example is provided by: FAMIXMethod>>sureReferencedClasses. At the very
least, we should name it sureInvokedClasses.
This is the first step towards re-sanitizing the FAMIX API.
Summary: Glamour text presentation does not properly refresh after the
text morph changes
Comment #1 on issue 752 by tu...(a)tudorgirba.com: Glamour text presentation
does not properly refresh after the text morph changes
First, please use a sentence to describe the problem :).
The current issue is due to the rendering of the text presentation not
properly notifying the text change in some circumstances.
The problem can be reproduced like this on windows:
- open GLMBasicExamples new textPortsExamples openOn: 'Type'
- type some characters
- the pane on the bottom right will preview correctly the changes
- now, press cmd+s (to tell the morph that we accept the change)
- type some more characters
- the pane on the bottom right will not update
- now, press cmd+s
- the pane on the bottom right will update
As all of us know, Famix recognizes 4 types of associations (reference, access, inheritance, invocation) and Moosechef was built upon these dependencies (queryAllOutgoingReferences, ...)
For convenience, it adds queryAllOutgoingDependencies
but this will miss a good deal of actual dependencies, because many of them are not expressed by associations:
- return type of a method
- type of a variable
- exceptions caught, thrown
- parameter types in parameterized classes
- use of annotations
Since we now have a nice general API to query dependencies, it would be nicer if it were complete, ...
A possible solution would to rename queryAllOutgoingDependencies into queryAllOutgoingAssociations and change queryAllOutgoingDependencies to "do the right thing"
Or maybe invent new "virtual associations" (like ofTyp e) and create queries for these associations, ...