Hi,
I am looking into the Moose-Algos-Graph package. It's pretty cool,
especially that you can create graphs easily.
The only problem I encountered so far is that I cannot create nested
graphs.
I just see now that MOGraphStructure is a subclass of MOGraphAlgorithm
and that MOGraphAlgorithm has nodes and edges. This means that these
can handle only one level of nodes and edges.
This problem was solved in Mondrian by making each node or edge a
graph. Using a similar approach, MOGraphAlgorithm could then just
point to one root node that holds everything.
Or maybe we need a MOGraphBuilder that creates the graph and
MOGraphAlgorithm just deals with a set of nodes and edges.
What do you think?
Cheers,
Doru
--
www.tudorgirba.com
"It's not what we do that matters most, it's how we do it."
Hello,
When importing C code with CAnalyzer, if you open a mooseFinder on the
generated model, select allCAUnitElements and then select anyOne of this
CAUnitsElements, it will raise an Error:
"My subclass should have overriden 'classes'".
CAunitElement is a subclass of FAMIXScopingEntity. FAMIXScopingEntity
declare the abstract method 'classes' (which make no sense for a
CAUnitElement ). Then, it seems that the mooseFinder require this method to
browse a CAUnitElement.
Hi Cyrille,
I have a bit of feedback for Distribution Map:
- The computation from Distribution Map Wizard is too expensive
because you iterate over the meta elements and for each of them you go
over all elements of Moose through the method includesElementsOfType:
It would be better if you would go over all cached groups and decide
based on that rather than traversing the entire entities collection
(which can be millions of objects).
- It would be better if Distribution Map gets its own package because
it starts to be large
Cheers,
Doru
--
www.tudorgirba.com
"Next time you see your life passing by, say 'hi' and get to know her."
Begin forwarded message:
> From: Andy Kellens <akellens(a)vub.ac.be>
> Date: May 4, 2010 11:47:00 AM GMT+02:00
> To: Stéphane Ducasse <stephane.ducasse(a)inria.fr>
> Cc: Johan Brichau <johan.brichau(a)uclouvain.be>, Tudor Girba <tudor(a)tudorgirba.com>
> Subject: Re: Cobol parsing?
>
> Hello,
>
> The COBOL parser was work of Kris De Schutter.
> He made it available on sourceforge at http://koopa.sourceforge.net/ .
> Let me know if you have any problems with it!
>
> Cheers,
>
> Andy
>
> On 04 May 2010, at 11:44, Stéphane Ducasse wrote:
>
>> Hi guys
>>
>> for a client we may need a cobol "parser" is yours available and under which license?
>>
>> Stef
>
Hi!
Yesterday I identified and solved a bug related to Source Anchors and
friends. Maybe someone can double check why I did.
Test: #testImportFileAnchors
New versions:
Famix-Tests-Core-Alexandre_Bergel.4
Famix-Extensions-Alexandre_Bergel.120
Famix-SourceAnchor-Alexandre_Bergel.18
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
It may be of some interest one day.
JavaScript Meta-Object System: http://code.google.com/p/joose-js/
Thanks to Norbert for the link.
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
if you take a model and click on an elements I see that the GC is kicked in
each time I change a list element.
There is something strange. We saw that with cyrille.
Stef
HI doru
I have a list of functions, I select the source tab to see its source.
Now when I select the next functions, the source tab gets deselected.
Is it possible to get the tab stay accross element navigation when it makes sense?
Stef
Hi all,
I am looking at srcML, and I see that it make XML files from Java and C++ source code.
Since we use it for C source code, it should be possible to make it works with C++ and java.
This strategy allows us to not us a special tool for each language.
What do you think about it ?
Cheers
---
Jannik Laval
Hi!
I have been looking for a method that give me the depth of the class
hierarchy under a particular class. Doru pointed me the method
FAMIXClass>>maxHierarchyOfChildren. But I was not able to make it work.
I imported Morph into moose, and try to send #maxHierarchyOfChildren
to the famix representation of Canvas or Morph. It simply loops.
#maxHierarchyOfChildren and its unique caller (#ahh) are not tested.
I try to look at the implementation of maxHierarchyOfChildren, but it
was a bit obscure to me (almost midnight here :) I decided to write my
own:
-=-=-=-=-=-=-=-=-=-=-=-=
FAMIXClass>>subclassHierarchyDepth
<property: #SHD longName: 'Subclass hierarchy Depth' description:
'The depth of the class hierarchy for which I am the root'>
^ (self directSubclasses isEmpty or: [ self isStub ])
ifTrue: [ 0 ]
ifFalse:
[ | currentMaxDepth|
currentMaxDepth := 0.
self
subclassesDo:
[ :aClass | currentMaxDepth := currentMaxDepth max: aClass
subclassHierarchyDepth ].
1 + currentMaxDepth ]
-=-=-=-=-=-=-=-=-=-=-=-=
Any one can comment on maxHierarchyOfChildren? Does it make sense to
remove maxHierarchyOfChildren and add my subclassHierarchyDepth?
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
I would like really to have a separate windows that would display all the time the
source anchor of the entity under my mouse.
Source is an important artefact and seeing it is important (without getting a new window
or having to click on a menu).
Stef
Hi!
I have a question regarding browseMeta. In the Map depicted in the
lower pane of the browser, I see two distinct hierarchies, where
FAMIXEntity and MooseEntity are the roots, respectively. However,
FAMIXEntity is a subclass of MooseEntity. Why is there two distinct
hierarchies then?
I haven't checked at a deeper level. I am just wondering.
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi!
I am wondering why MooseElement needs a mooseID. By looking at the
sender of mooseID, I can see methods like:
MooseModel>>includes: anItem
anItem isNil ifTrue: [^ false].
^ self includesID: anItem mooseID
and MooseModel class>>ownerOf: element that makes use of mooseID. But
is this really necessary?
Just wondering...
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi Cyrille,
I saw that during your cleaning effort, you commented the york
variable from the method
TheRoot>>accessingUnknowVariable
york is indeed undeclared, but this is done intentionally because we
want to be able to test such situations :).
Cheers,
Doru
--
www.tudorgirba.com
"Speaking louder won't make the point worthier."
Hi Cyrille,
Thanks for cleaning the entity state and its usage.
This kind of work typically goes unnoticed, but it is so important for
keeping the infrastructure nice and tidy.
Just one note: when you do such core structural changes, please let
the others know what they should do to comply :)
Cheers,
Doru
--
www.tudorgirba.com
"What is more important: To be happy, or to make happy?"
Hi,
I made available a package to integrate Moose with the command line:
http://github.com/girba/automoose
The package consists of a shell script that given a set of src and a
base moose.image (in the res folder) it does:
- parse sources with inFusion and generate an mse file
- take the moose.image and run a number of smalltalk scripts
- produce a time-stamped tgz with the resulting image and the mse file
The package can also be directly integrated with Hudson.
Cheers,
Doru
--
www.tudorgirba.com
"Being happy is a matter of choice."
Hi Tudor,
I got an error when in a column or row there is one presentation that has an icon as title...
here an example:
| browser |
browser := GLMTabulator new.
browser
column: #one.
browser showOn: #one; using: [
browser list
titleIcon:[ MenuIcons windowIcon ];
display: [:x | 1 to: x] ].
browser openOn: 5
Regards,
Veronica
Hi!
As you may know, Mondrian offers additional interaction mechanisms.
The script below shows a system complexity, and by waving the mouse
over a node, clientClasses will be connected. When the mouse leaves
the node, the edges disappear.
-=-=-=-=-=-=-=-=-=-=-=-=
view shape rectangle
width: #numberOfAttributes;
height: #numberOfMethods;
linearFillColor: #numberOfLinesOfCode within: classGroup.
view interaction
action: #inspect;
whenEnteringUpdateNode:
[:node | view edges: {node} from: #yourself toAll: #clientClasses ]
withLayoutUpdate: false.
view nodes: classGroup.
view edgesFrom: #superclass.
view treeLayout
-=-=-=-=-=-=-=-=-=-=-=-=
This mechanism is useful I think, however, the block you provide in
#whenEnteringUpdateNode: should be error free. Else the image may hang
(this is a well known Morphic problem, I will work on it one day).
Do you like this view? Would it make sense to make it as default in
Moose? Any comment?
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hello,
Last week I had a error due to a strange behaviour: I had an instance
variable and an accessor to this instance variable. The instance variable is
instanciated at the initialization of the class. When the error occure, the
instance variable is not nil (when inspecting it from the debugger ). But,
when evaluating the accessor, it return nil.
This occure in the pharo 1.0 dev image. I test it this morning on a clean
image and on a click image with moose. It seems that the bug is specific to
moose. If you want to reproduce it:
Download the last version of Merlin from
www.squeaksource.com/DelaunayTmpStuffs.
run the method MerlinExamples class >> parametrizedMorphDropLists. it should
work correctly.
Now restart, load moose (load ConfigurationOfMoose, and evaluate
'ConfigurationOfMoose loadDefault') and then load Merlin from
'DelaunayTmpStuffs'.
It should raise an error and you should be able to see this strange
behaviour. From the debugger, evaluate 'self dropList' in MorphDropListPart.
After showing this bug to Marcus, it seems that something is not weel
compiled at one point: browse the method 'dropList' in dropListPart. Now,
click on 'view' and 'byte code'. The offset indicated is 10 whereas it
should be 15