Hi all. I don't know why but today I am completly dumb. I need to take a
MooseModel and get two things:
- how many objects represents such MooseModel object. I mean, suppose that
MooseModel references objects, and those objects references other
objects....etc. I need to know the "size" of such graph.
- how many classes represents such MooseModel object.
So for example, for Moose default model I could have 4034 objects, 8
classes.
For Moose Network Model, I could have 54354365 objects and 344 classes
(I put random numbers)
I tried analysing the RuntimeStorage, but didn't get anything.
Thanks in advance.
Mariano
Hi,
With the recent changes in Mondrian it looks like the class blueprint
is broken. The problem seems to be due to incorrect bounds of the
parent node. I noticed when by spawning the blueprint of a hierarchy
of classes, I got overlapping classes.
I will take a closer look, but it would be great if someone could
confirm this problem. I guess it should happen with other nested
visualizations.
Cheers,
Doru
--
www.tudorgirba.com
"Reasonable is what we are accustomed with."
Hi all,
I localized the bug of Mondrian,
As Alex said, width and height are stored in cache, so a script like this work fine:
======
|view o |
view := MOViewRenderer new.
o := OrderedCollection new: 100.
1 to: 100 do:[:i | o add: i].
(view shape: (MORectangleShape new
width: [:e | (Delay forMilliseconds: 50) wait. 200];
height: 200;
withBorder;
borderColor: [:e | Color gray])).
view nodes: o.
view layout: (MOGridLayout new gapSize: 1).
view open
======
It is slow to generate, then it scroll well.
Now, if I do the same thing with a Delay in the block of borderColor:, the visualization is dead.
======
|view o |
view := MOViewRenderer new.
o := OrderedCollection new: 100.
1 to: 100 do:[:i | o add: i].
(view shape: (MORectangleShape new
width: [:e | 200];
height: 200;
withBorder;
borderColor: [:e | (Delay forMilliseconds: 50) wait. Color gray])).
view nodes: o.
view layout: (MOGridLayout new gapSize: 1).
view open
======
This is the bug we have in Blueprint, in eDSM and all the visualization we made.
I think shapes should keep these state and maybe react to announcement.
Cheers,
---
Jannik Laval
I want a way to represent where in the source code something came from.
FAMIXSourceAnchor looks as if it might be intended for this, but its
only attribute, entity, apparently refers to another FAMIX entity, not
to the source code. But perhaps entity is supposed to be a FAMIXFile or
method source? It doesn't appear that FAMIXSourceAnchor is used, even
though every FAMIXSourcedEntity can have one.
Can anyone provide more info on what FAMIXSourceAnchor is supposed to be
doing? There is no class comment.
Second, every FAMIXSourcedEntity has a comments attribute. This seems a
mixed blessing, since the attachment of comments is often ambiguous.
For example, in SAS one might have
data a;
x=34;
/* a very silly example */
data b;
y=1;
It's unclear whether the comment applies to the data a or data b step.
If you're a parser, it might also apply to 34, x=34, data, or data b.
Third, I'm probably going to need a richer concept of source location.
SAS allows inclusion of other files in the source code (like #include
for C) and also has a macro processor, which may expand out a macro and
discover more macros that it recursively expands.
Comments?
Ross
I just tried the new Cog VM on a Pharo image 1.2 with Moose inside.
It s really fast.
I will do benchmark when the MessageTally will work.
Cheers,
---
Jannik Laval
I've got a bit of my parser going, and am now wondering what I should
parse the elements into. My initial thought was to extend FAMIX and
then create appropriate elements of it. I'm not sure that's
appropriate, and would appreciate some advice.
First, it looks as if the sample smalltalk parser uses the AST from RB,
and not the FAMIX models directly.
Second, there are clear differences between the FAMIX models and the
immediate parse results. For example, suppose I have a variable (or
dataset for SAS) named X. The parser may treat each as distinct, while
my model needs to describe the single entity to which each occurrence of
the name refers. That single entity will have much richer information
(relations to other variables, the block of source code in which the
variable is defined or referenced ....) than the parser would initially
care about.
On the other hand, I could use the FAMIX models in initially a
lightweight way; otherwise it seems I could end up with fairly
duplicative parser classes and model classes.
So, would it be best to parse directly into my model classes, or to
parse into some other AST that is later used to make the model?
Thanks.
Ross Boylan
Hello,
I have been looking a bit for the place where we set the canvas to use in
Mondrian, but I didn't find.
I know that all shapes are drawn on a FormCanvas, but there is no references
to FormCanvas in mondrian classes.
I just saw that there is a 'defaultCanvasClass' method in the class Form for
example, so maybe such a method is use somewhere in the code.
Does somoene know the way to set a new Canvas to Mondrian ?
Hi Jannik,
I got a small problem in the packaging of DSM: you have a DSMCore
package, and a DSMCore-Test package. This is a problem with
Monticello, and it causes problems with the Metacello configuration.
So, I now moved the tests into DSM-Tests-Core package and updated the
ConfigurationOfDSM. I am testing it now. Please let me know if you
have any problems.
Cheers,
Doru
--
www.tudorgirba.com
"When people care, great things can happen."
Hi!
Is there any of you going to TOOLS this year?
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Begin forwarded message:
> From: Henrik Johansen <henrik.s.johansen(a)veloxit.no>
> Date: June 18, 2010 10:01:53 AM GMT+02:00
> To: Stéphane Ducasse <stephane.ducasse(a)inria.fr>
> Subject: Re: PDF of Software Metrics
>
> What he was most interested in, was the C++ thresholds for the overview pyramid in Moose.
> Found those in an online presentation, so wasn't as pressing after all :)
> Is there any reason why only JavaThresholds are included/used by default, instead of being selected automatically based on what language your model originated from?
>
> On the bright side, he's found the tools really useful (doing an architectural review of a large C++ program) after I tipped him of the existence of Moose :)
>
> Mondrian visualizations do not scale very well for a project of this size though, the display model seems more geared towards traversing the model rather than culling what does not show up on screen, which turns into a problem when it redraws 50000 nodes each refresh rather than the 100 - 200 actually visible on screen... (ie. 8-10 seconds for one refresh after clicking scroll bars) (This was an enriched DSM chart for 20 namespaces)
>
> The blueprint complexity visualization never even opened (as in, at least in the first minute), the algorithm for calculating edges is waaay too slow with 500 entities :)
>
> Which is kind of a shame, since those large, complex systems are what it really would be nice to have good visualizations of... :/
> Maybe better scaleability would be a good goal for Moose 4.1?
>
> Cheers,
> Henry
>
>
>
Begin forwarded message:
> From: Basile Starynkevitch <basile(a)starynkevitch.net>
> Date: June 18, 2010 7:09:03 AM GMT+02:00
> To: stephane ducasse <stephane.ducasse(a)free.fr>
> Subject: Re: contact au sujet de votre analyseur C++
> Reply-To: basile(a)starynkevitch.net
>
> On Thu, 2010-06-17 at 23:20 +0200, stephane ducasse wrote:
>> merci
>>
>> on cherche a extraire un modele "object"
>> class variable methodes invocation de methodes... de C++ est ce que cela serait possible/simple de faire cela avec melt.
>
>
> Les aspects *declarations* (de classes, de méthodes)... sont dans GCC en
> représentation Generic/Tree.
>
> Les aspects *instructions* (corps de méthode ou de fonction) sont dans
> GCC en représentation Gimple.
>
> MELT permet de manipuler aussi bien les Tree que les Gimple, mais je
> suis bien plus familier avec Gimple que avec Tree.
>
> Et de toutes façons, rien n'est "simple" avec GCC. GCC est un très gros
> code (4.5 millions de lignes!), un peu vieux et fouilli, avec une
> documentation disparate. Sa taille est lié à sa puissance, mais c'est
> quand même compliqué.
>
> Disons qu'il faudrait au moins un stagiaire motivé pendant un trimestre
> pour débroussailler le sujet et avoir peut-être un résultat. (Mais je
> n'ai pas compris le détail de tes besoins).
>
> Toutefois, sur les aspects déclarations C++, dans le projet GlobalGCC,
> une équipe universitaire de Madrid UPM a travaillé dans GCC (mais pas
> avec MELT qui à l'époque était embryonnaire).
>
> Il y a une difficulté préalable à tout ça. Savoir simplement compiler
> gcc 4.5 -ou la branche GCC MELT [c'est la même difficulté, les
> dépendances sont les mêmes]. J'ai un stagiaire (brillant et motivé) de
> licence, Jérémie Salvucci, qui y est arrivé tout seul en 2 jours. Mais
> il y a aussi eu 2 stagiaires de Mastère chez Emmanuel Chailloux (Paris 6
> PPS) qui ont peinés simplement pour compiler GCC, et l'un a abandonné
> son stage!
>
> L'idéal serait peut-être d'essayer de compiler GCC MELT et de jouer
> avec.
>
> Extraire les informations de class variable methodes invocation de
> methodes... de C++ avec GCC MELT est possible, mais je ne crois pas que
> ça soit simple, pour la bonne raison que rien n'est simple dans GCC.
> MELT simplifie la vie de ceux qui ont compris (un peu) les
> représentations internes de GCC et les passes, mais il faut faire
> l'effort de le comprendre. MELT n'enlève pas la difficulté de
> compréhension des internes de GCC, c'est juste un outil pour les
> manipuler plus facilement.
>
> A bientôt.
>
> --
> Basile STARYNKEVITCH http://starynkevitch.net/Basile/
> email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
> 8, rue de la Faiencerie, 92340 Bourg La Reine, France
> *** opinions {are only mines, sont seulement les miennes} ***
>
>
>
sorry in french
Begin forwarded message:
> Date: June 16, 2010 9:58:19 AM GMT+02:00
> To: "stephane ducasse" <stephane.ducasse(a)free.fr>
> Cc: <basile(a)starynkevitch.net>
> Subject: RE: contact au sujet de votre analyseur C++
>
> Bonjour
>
>> Nous aimerions savoir si on peut utiliser votre bibliotheque pour extraire un meta modele
> de code. Est ce que la resolution des variables est faite?
>
> GCC MELT http://gcc.gnu.org/wiki/MELT n'est pas un analyseur C++, c'est un greffon [=plugin] de GCC [au niveau middle-end], et aussi un langage lispien (Domain Specific Language) -avec un pattern matching puissant - pour coder des extensions de GCC.
>
> Le middle-end de GCC est la majeure partie de GCC (GCC totalise 4.5MLOC, et le middle end doit en représenter les deux-tiers). Il contient notamment beaucoup de passes de compilations (GCC contient 250 passes, dont la plupart travaille au niveau middle-end).
>
> Le middle-end de GCC travaille surtout sur les representations internes Gimple (& Tree/Generic) de GCC http://gcc.gnu.org/onlinedocs/gccint/GIMPLE.html et http://gcc.gnu.org/onlinedocs/gccint/GENERIC.html
>
> GIMPLE est une représentation normalisée (à "3 adresses") -commune à C, C++, Fortran, et tout language source accepté par GCC, et peu dépendante de la machine cible [x86/Sparc/ARM....]- du *code* compilé par GCC. En particulier, les descriptions des classes C++ n'y sont plus (mais elles sont dans Tree/Generic qui est accessible du Gimple).
>
>
>
>> Avant de vous inviter pour faire une presentation de votre outil. Avez-vous qq
>> pointeurs sur votre outil?
>
> Oui, le code de GCC MELT est une branche de GCC accessible par SubVersion et il est compilable comme un greffon de gcc 4.5
>
> Il y a plusieurs pages sur le wiki, voir http://gcc.gnu.org/wiki/MELT pour commencer. On y trouve quelques papiers sur MELT.
>
> Il y a une documentation interne incomplète (faire un make pdf).
>
> Il y a une liste francophone gcc-melt-french(a)googlegroups.com sur GCC
>
> Pour une introduction aux greffons de GCC et à MELT, je vous conseille d'abord les transparents de mon exposé (avec Zbigniew Chamski) à Solutions Linux: http://starynkevitch.net/Basile/solinux2010-greffons-GCC.pdf
>
>
> MELT permet de coder (en dialecte MELT de LISP, donc moins péniblement qu'en C) toute extension de GCC de son middle-end, qui travaille sur les représentations internes existantes (principalement Gimple & Tree/Generic) de GCC. On code en MELT plus facilement qu'en C une extension de GCC. Ainsi, coder en MELT une extension de GCC est moins fastidieux que coder en C un greffon de GCC. MELT comme les greffons étendent GCC en y ajouter des passes supplémentaires.
> J'ai un stagiaire (Jérémie Salvucci) qui a pu coder en 15 jours une extension en MELT (qui va transcrire le Gimple en du code C, et plus tard OpenCL).
>
> La difficulté commune au développement en C de greffons de GCC ou au développement en MELT d'extensions de GCC est de comprendre en gros les représentations internes principales de GCC (notamment Gimple, Tree/Generic, Edge/ControlFlowGraph, ...) et l'organisation des (250+) passes de GCC.
>
>
> Je n'ai pas compris dans le *détail* ce que vous appelez "méta-modèle du code", et "résolution de variables". GCC fait ce genre de choses (puisqu'il est capable de compiler C++). Mais il faut être bien conscient que Gimple est surtout une représentation intermédiaire du *code* et pas des déclarations C++: au niveau de Gimple par exemple, il n'y a plus de champs protected: du C++.
>
> Je joins aussi:
>
> un feuillet en français décrivant GCC MELT. feuille-gcc-melt-fr.pdf (2 pages rectoverso A4). N'hesitez pas à rediffuser ce feuillet.
>
> un papier MELT-Basile-Starynkevitch-CC2010.pdf en anglais soumis et rejeté à CC2010 sur MELT. Merci de ne pas le rediffuser, car je voudrais en réutiliser une partie à d'autres soumissions.
>
> Cordialement
> --
> Basile STARYNKEVITCH : basile dot starynkevitch at cea dot fr
> CEA LIST/DILS/LSL Saclay bat.528; 91191 GIF/YVETTE CEDEX; FRANCE
> tel: +33 1 6908 6595; mobile: +33 6 8501 2359; www.starynkevitch.net/Basile
> http://www-list.cea.fr/labos/gb/LSL/index.html fax: +33 1 6908 8395
>
>
>
>
>
Hi Jannik,
Nice job with hooking Moose in the Pharo menu. I now added the Moose
icon :)
Cheers,
Doru
--
www.tudorgirba.com
"Next time you see your life passing by, say 'hi' and get to know her."
Hi,
I tried to make a script for Mondrian and I made a writing error.
I put a bloc on borderColor: without the bloc parameter.
The reaction of Mondrian is strange: Rectangle becomes red.....
When I remove the bloc or I put the bloc parameter (as: [:e | Color gray]), it works fine.
Here is the small script to test:
=============
|view o o2|
view := MOViewRenderer new.
o := OrderedCollection new: 1000.
o2 := #(1 2 3 4 5 6 7 8 9 10).
1 to: 100 do:[:i | o add: i].
(view shape: (MORectangleShape new
width: 200;
height: 200;
withBorder;
borderColor: [Color gray])).
view nodes: o.
view layout: (MOGridLayout new gapSize: 1).
view open
=============
Cheers
---
Jannik Laval
Hi Alexandre,
I am using popupViews, but depending on the position of the entity that displays the popup, sometimes only part of it is visible (see attached image).
in those cases, it should be displayed to the left-side.
Veronica
Hi,
I just make an entry for moose in pharo main menu.
It should replace the Moose workspace.
I place the method menuCommandOn: in MooseModel, class side.
We should place it in a better place, I will do it soon.
I need an icons, as for now there is the debug icon.
Doru, do you have a better icon ?
Cheers,
---
Jannik Laval
Hi!
I would like to identify duplication of code execution in unit tests. Does anyone know whether there is some related work?
I went through Orla's paper (she worked on execution tracing) and I have seen nothing related to code execution duplication.
Any pointer?
Cheers,
Alexandre
Hi Doru,
I have defined as part of the listing presentation the tag style field, by default is gray rounded button.
GLMMorphic knows the details of each style, for now the default one, and the white rectangled button I am using.
With this you should not see any change on your tags.
cheers,
Veronica
Consider the following Java code:
class X {
int y = getnum();
static int getnum() { return 0; }
}
line 2 is a method invocation:
- receiver = this
- signature = getnum()
- sender = class X
But metamodel says that 'sender' is a BehaviouralEntity (i.e. a Method or a Function)
Therefore the code cannot be represented .... :-(
Mondrian-Alexandre_Bergel.464 is the last version...
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi!
I haven't closely followed the status of the moose algo. I am looking for a way to get group of interconnected nodes.
A simple test would be:
testCycle1
| view |
view := MOViewRenderer new.
view nodes: (1 to: 5).
view edges: {1 -> 2. 2 -> 3 . 4 -> 5} from: #key to: #value.
view treeLayout.
window := view open.
self assert: (view root numberOfDistinctGroups = 2).
self assert: (view root distinctGroups first includesAllOf: (1 to: 3)).
self assert: (view root distinctGroups second includesAllOf: (4 to: 5)).
Is there some material that I can use to code #numberOfDistinctGroups and #distinctGroups ?
Cheers,
Alexandre
I was trying to install Moose (and Moose 4.0) from Pharo 1.0 on
Windows XP using
Gofer new
squeaksource: 'Moose';
package: 'ConfigurationOfMoose';
load.
(Smalltalk at: #ConfigurationOfMoose) perform: #loadDefault.
For both #loadDefault or perform: #loadRelease40 the process hangs at
"Loading default of ConfigurationOfMoose. Atomic load" window.
How can this fix fixed?
