Moose-dev June 2010

moose-dev@list.inf.unibe.ch

20 participants
48 discussions

Fwd: PDF of Software Metrics
by Stéphane Ducasse 18 Jun '10

18 Jun '10

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 > > >

3 4

Fwd: contact au sujet de votre analyseur C++
by stephane ducasse 18 Jun '10

18 Jun '10

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} *** > > >

1 0

Fwd: contact au sujet de votre analyseur C++
by stephane ducasse 18 Jun '10

18 Jun '10

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 > > > > >

5 4

menu
by Tudor Girba 18 Jun '10

18 Jun '10

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."

1 0

New version of Mondrian
by Alexandre Bergel 17 Jun '10

17 Jun '10

Hi! Jannik, Veronica, please try Mondrian-UNSTABLE-Alexandre_Bergel.462 I hope this addresses the flickering problem Let me know. Cheers, Alexandre

3 7

Mondrian side-effect
by Laval Jannik 16 Jun '10

16 Jun '10

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

3 4

Mondrian: popup view
by Veronica Isabel Uquillas Gomez 16 Jun '10

16 Jun '10

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

2 4

Moose menu
by Laval Jannik 16 Jun '10

16 Jun '10

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

1 0

Trace and duplication of code execution
by Alexandre Bergel 15 Jun '10

15 Jun '10

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

1 0

glamour: tag styles
by Veronica Isabel Uquillas Gomez 15 Jun '10

15 Jun '10

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

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev June 2010