Moose-dev September 2010

moose-dev@list.inf.unibe.ch

29 participants
92 discussions

Verveine-PHP
by Cyrille Delaunay 13 Nov '11

13 Nov '11

Hello, With nicolas we started to have a look at the eclipse-php-parser (provide with PDT), to export a famix-mse file from a PHP project. We already started to build an eclipse plugin that does some work: => We create an AST for each php file of the project => Then we have a visitor on this ast, and we are therfore able to make a specific action for each kind of node visited => For now, we just export some FAMIXNamespace, FAMIXClass, FAMIXMethods. So what's left is to implement each visit-method to extract informations for each node visited. For that we will have to know a bit more PHP :) Maybe the metamodel will have to be extended to take into account some PHP-specific elements, I don't know. If you want to have a look, sources are available via svn at: https://scm.gforge.inria.fr/svn/lse/Projects/Verveine Vervaine provide the extractor (not yet finished) for Java ans this one for PHP. Both are using a common mechanism to generate famix entities and extract them to mse. I will be on holidays until august and will probably no longer work on it until august. So if you want to have a look (and have the courage to install eclipse to read java code:)), have some suggestions, want to implement something, feel free to participate :)

7 15

Moose for SAS
by Ross Boylan 10 Jun '11

10 Jun '11

Some people suggested trying moose for analysis of SAS programs, and I'm trying to figure out where to start with the meta-modeling. SAS is not object oriented, though parts of it could be imagined to be. The main SAS code contains blocks of statements that begin with DATA or PROC; each block could probably be thought of as a function--to be precise, the application of a function. If I want to make some new models, where do I start? FM3? FAMIX? elsewhere? The 4.0 release announcement says FM3 and FAMIX3 are both implemented in Fame, so maybe start with Fame? I've read some documentation, but I can't tell. My inspiration for the project is understanding how some SAS datasets were produced. I have a system that creates numerous datasets, which feed into later datasets, etc. This is split at least across a couple of program files and it's really too complicated to keep in the brain. If I get ambitious it would also be useful to trace where particular variables came from, in the sense of both datasets and individual expressions. The only thing resembling a SAS parser I've run into (except for SAS, which is closed source) is a Perl module, and it looked relatively primitive. I've been using PetitParser, and at the point I started thinking about what it would parse results into. Thanks for any pointers. Ross Boylan

8 18

Petit SQL Parser
by Fabrizio Perin 11 May '11

11 May '11

Hi all, i did implement an SQL parser using Petit Parser. I toke the grammar specification from SQLite http://www.sqlite.org/lang.html . The grammar implemented is not complete, for now i did implement "just" the create table statement, it means that you should be able to parse at least a script for create the database. The code is in squeaksource http://www.squeaksource.com/@09zbthA-fDDfyUNQ/_OIex3aA . To download it you can evaluate this: Gofer new squeaksource: 'PetitSQLParser'; package: 'ConfigurationOfPetitSQLParser'; load. (Smalltalk at: #ConfigurationOfPetitSQLParser) perform: #loadDefault in the repository there are several packages: the core contains the parser for the grammar. In the package parser there is a parser that instantiate some draft objects representing relational elements. In the next future i will start to implement also other statements. If you start to use it and you have some problem please let me know. Cheers, Fabrizio

3 9

Re: Class renaming in Moose Algos Graph
by Guillermo Schwarz 01 Nov '10

01 Nov '10

Hi Guys, Why don't you do something more focused on the long term and don't you change the Smalltalk compiler with namespaces? I don't think it should be that hard since each class already belongs to a category. Each category could instead be a dictionary from where the compiler could find classes that are mentioned in the class source. This has worked wonders in Java (classes inside packages). This way classes' names can be repeated ad eternum without generating collisions or otherwise polluting excessively the name space. So for example: FAMIXAssociation subclass: #FAMIXInvocation instanceVariableNames: 'sender receiver receiverSourceCode signature candidates' classVariableNames: '' poolDictionaries: '' category: 'Famix-Core' Would be instead: Association subclass: #Invocation instanceVariableNames: 'sender receiver receiverSourceCode signature candidates' classVariableNames: '' poolDictionaries: '' category: #FamixCore Then the category would be an index in the SystemDictionary: SystemDictionary at: #FamixCore put: Category new. (SystemDictionary at: #FamixCore) belongingClassList add: #Invocation "this should be done automatically by the subclass: method above" (SystemDictionary at: #FamixCore) referencedClassList add: ... "classes that are referenced by classes belonging to category #FamixCore" What do you think? Cheers, Guillermo. Message: 1 Date: Mon, 27 Sep 2010 22:00:33 +0200 From: Tudor Girba <tudor.girba(a)gmail.com> Subject: [Moose-dev] Re: Class renaming in Moose Algos Graph To: Moose-related development <moose-dev(a)iam.unibe.ch> Message-ID: <C912A83B-6BDC-4775-AC26-CE2DBC5540AE(a)gmail.com> Content-Type: text/plain; charset=us-ascii Hi Simon, These classes should be called MAlgo (or MAL ?). I started to do that a while ago, but apparently I forgot to commit this change. Cheers, Doru On 27 Sep 2010, at 19:42, Simon Denier wrote: > > On 27 sept. 2010, at 18:17, Lukas Renggli wrote: > >> Please note that the MA* (with an uppercase $A) prefix is already >> taken by Magritte. Ma* (with a lowercase $a) is taken by Magma, if I >> remember correctly they renamed their classes at some point a long >> time ago to avoid the conflict with Magritte. >

2 2

pharo sprint / moose dojo - october 23-24, bern
by Tudor Girba 11 Oct '10

11 Oct '10

Hi, We will organize a joint Pharo sprint / Moose dojo during October 23-24, in Bern (at the Software Composition Group, University of Bern). Some action points are mentioned on the dedicated page (of course, other ideas and interests are welcome as well): http://www.moosetechnology.org/events/2010-10-22-dojo For planning purposes, please let me know if you will attend. Cheers, Doru p.s. In case it is of interest, on October 22, we also have CHOOSE Forum 2010 in Bern, an event on the topic of Domain-Specific Engineering where, among others we'll learn about the role of Smalltalk :) http://choose.s-i.ch/events/forum2010 -- www.tudorgirba.com "Problem solving should be focused on describing the problem in a way that makes the solution obvious."

2 3

Class renaming in Moose Algos Graph
by Simon Denier 03 Oct '10

03 Oct '10

I just performed a mass class renaming in Moose Algos Graph. Some classes still had the old prefix MO*, they now all have a MA* prefix. Class references in default Moose have been updated too (this includes DSM...) So, if you use Moose-Algos-Graph and your package is not part of Moose default, you might to take a look and see if you need to update some references. Also, the API of MAGraphAlgorithm has been extracted into trait MATGraphBuilder if someone wants to reuse it in a different setting (as requested). I don't support nested graph for now though, as it is not clear for me the best way to build them. -- Simon

4 3

Pbm with Torch
by Simon Denier 01 Oct '10

01 Oct '10

Hi Veronica Today when I tried to launch Torch on package, I got a DNU on RBSemanticAnnotator>>start:class: In a Pharo 1.1 How should I update RB? -- Simon

3 4

Re: Class renaming in Moose Algos Graph
by Simon Denier 29 Sep '10

29 Sep '10

On 29 sept. 2010, at 09:08, Stéphane Ducasse wrote: > simon can you open bug entry for pharo? What issue should I report? The fact that Monticello is not aware/notified of the impact of class/trait renaming on external clients? > > Stef > >>> Hi, >>> >>> I just tried creating a new image, but there is a problem with traits definition: >>> http://hudson.moosetechnology.org/job/moose-latest-dev/370/console >>> >>> Could you take a look? >> >> >> Re-argh, same problem, renaming a trait does not make a package dirty by default, and I didn't check for external users of traits (now I know how to do that :() >> Fixed in Famix-Extensions and DSM. >> >> Can you try again? >> >> >>> >>> Cheers, >>> Doru >>> >>> >>> On 28 Sep 2010, at 17:20, Simon Denier wrote: >>> >>>> >>>> >>>> It's done. Squeaksource was down a bit this afternoon, and Lukas's server seems down since this morning, so I can't test a load default now, but hopefully everything is alright now. We will see tomorrow. >>>> >>>> >>>> >>>> On 28 sept. 2010, at 13:01, Simon Denier wrote: >>>> >>>>> >>>>> On 28 sept. 2010, at 09:11, Tudor Girba wrote: >>>>> >>>>>> Hi Simon, >>>>>> >>>>>> It looks like while renaming you missed to publish some packages: MOTarjanNodeDSM still seems to inherit from the old MOTarjanNode, and because of that the build breaks :). >>>>> >>>>> >>>>> Argh, never thought I could still be bitten by the non-dirty package bug in MC :( >>>>> >>>>> So changing a superclass does not make a package dirty mmm... I guess I will to check with Package Blueprints what's the impact of renaming classes. >>>>> >>>>> >>>>> As for the prefix, I will take Mal, just because fireflies do not bite (...) >>>>> >>>>> >>>>>> >>>>>> Cheers, >>>>>> Doru >>>>>> >>>>>> >>>>>> On 27 Sep 2010, at 22:00, Tudor Girba wrote: >>>>>> >>>>>>> Hi Simon, >>>>>>> >>>>>>> These classes should be called MAlgo (or MAL ?). I started to do that a while ago, but apparently I forgot to commit this change. >>>>>>> >>>>>>> Cheers, >>>>>>> Doru >>>>>>> >>>>>>> >>>>>>> On 27 Sep 2010, at 19:42, Simon Denier wrote: >>>>>>> >>>>>>>> >>>>>>>> On 27 sept. 2010, at 18:17, Lukas Renggli wrote: >>>>>>>> >>>>>>>>> Please note that the MA* (with an uppercase $A) prefix is already >>>>>>>>> taken by Magritte. Ma* (with a lowercase $a) is taken by Magma, if I >>>>>>>>> remember correctly they renamed their classes at some point a long >>>>>>>>> time ago to avoid the conflict with Magritte. >>>>>>>> >>>>>>>> >>>>>>>> ok, one issue is that all classes in Moose-Algos (not only Moose-Algos-Graph) are prefixed with MA so we will need to change that... >>>>>>>> >>>>>>>> but at least now there is some consistency in class names. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Lukas >>>>>>>>> >>>>>>>>> On 27 September 2010 17:51, Simon Denier <Simon.Denier(a)inria.fr> wrote: >>>>>>>>>> I just performed a mass class renaming in Moose Algos Graph. Some classes still had the old prefix MO*, they now all have a MA* prefix. Class references in default Moose have been updated too (this includes DSM...) >>>>>>>>>> >>>>>>>>>> So, if you use Moose-Algos-Graph and your package is not part of Moose default, you might to take a look and see if you need to update some references. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Also, the API of MAGraphAlgorithm has been extracted into trait MATGraphBuilder if someone wants to reuse it in a different setting (as requested). I don't support nested graph for now though, as it is not clear for me the best way to build them. >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Simon >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Moose-dev mailing list >>>>>>>>>> Moose-dev(a)iam.unibe.ch >>>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Lukas Renggli >>>>>>>>> www.lukas-renggli.ch >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Moose-dev mailing list >>>>>>>>> Moose-dev(a)iam.unibe.ch >>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>>>> >>>>>>>> -- >>>>>>>> Simon >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Moose-dev mailing list >>>>>>>> Moose-dev(a)iam.unibe.ch >>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>>> >>>>>>> -- >>>>>>> www.tudorgirba.com >>>>>>> >>>>>>> "Not knowing how to do something is not an argument for how it cannot be done." >>>>>>> >>>>>> >>>>>> -- >>>>>> www.tudorgirba.com >>>>>> >>>>>> "Be rather willing to give than demanding to get." >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Moose-dev mailing list >>>>>> Moose-dev(a)iam.unibe.ch >>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>> >>>>> -- >>>>> Simon >>>>> >>>>> >>>>> >>>> >>>> -- >>>> Simon >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev(a)iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> www.tudorgirba.com >>> >>> "We cannot reach the flow of things unless we let go." >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev(a)iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> Simon >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- Simon

1 0

Re: Class renaming in Moose Algos Graph
by Stéphane Ducasse 29 Sep '10

29 Sep '10

simon can you open bug entry for pharo? Stef >> Hi, >> >> I just tried creating a new image, but there is a problem with traits definition: >> http://hudson.moosetechnology.org/job/moose-latest-dev/370/console >> >> Could you take a look? > > > Re-argh, same problem, renaming a trait does not make a package dirty by default, and I didn't check for external users of traits (now I know how to do that :() > Fixed in Famix-Extensions and DSM. > > Can you try again? > > >> >> Cheers, >> Doru >> >> >> On 28 Sep 2010, at 17:20, Simon Denier wrote: >> >>> >>> >>> It's done. Squeaksource was down a bit this afternoon, and Lukas's server seems down since this morning, so I can't test a load default now, but hopefully everything is alright now. We will see tomorrow. >>> >>> >>> >>> On 28 sept. 2010, at 13:01, Simon Denier wrote: >>> >>>> >>>> On 28 sept. 2010, at 09:11, Tudor Girba wrote: >>>> >>>>> Hi Simon, >>>>> >>>>> It looks like while renaming you missed to publish some packages: MOTarjanNodeDSM still seems to inherit from the old MOTarjanNode, and because of that the build breaks :). >>>> >>>> >>>> Argh, never thought I could still be bitten by the non-dirty package bug in MC :( >>>> >>>> So changing a superclass does not make a package dirty mmm... I guess I will to check with Package Blueprints what's the impact of renaming classes. >>>> >>>> >>>> As for the prefix, I will take Mal, just because fireflies do not bite (...) >>>> >>>> >>>>> >>>>> Cheers, >>>>> Doru >>>>> >>>>> >>>>> On 27 Sep 2010, at 22:00, Tudor Girba wrote: >>>>> >>>>>> Hi Simon, >>>>>> >>>>>> These classes should be called MAlgo (or MAL ?). I started to do that a while ago, but apparently I forgot to commit this change. >>>>>> >>>>>> Cheers, >>>>>> Doru >>>>>> >>>>>> >>>>>> On 27 Sep 2010, at 19:42, Simon Denier wrote: >>>>>> >>>>>>> >>>>>>> On 27 sept. 2010, at 18:17, Lukas Renggli wrote: >>>>>>> >>>>>>>> Please note that the MA* (with an uppercase $A) prefix is already >>>>>>>> taken by Magritte. Ma* (with a lowercase $a) is taken by Magma, if I >>>>>>>> remember correctly they renamed their classes at some point a long >>>>>>>> time ago to avoid the conflict with Magritte. >>>>>>> >>>>>>> >>>>>>> ok, one issue is that all classes in Moose-Algos (not only Moose-Algos-Graph) are prefixed with MA so we will need to change that... >>>>>>> >>>>>>> but at least now there is some consistency in class names. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Lukas >>>>>>>> >>>>>>>> On 27 September 2010 17:51, Simon Denier <Simon.Denier(a)inria.fr> wrote: >>>>>>>>> I just performed a mass class renaming in Moose Algos Graph. Some classes still had the old prefix MO*, they now all have a MA* prefix. Class references in default Moose have been updated too (this includes DSM...) >>>>>>>>> >>>>>>>>> So, if you use Moose-Algos-Graph and your package is not part of Moose default, you might to take a look and see if you need to update some references. >>>>>>>>> >>>>>>>>> >>>>>>>>> Also, the API of MAGraphAlgorithm has been extracted into trait MATGraphBuilder if someone wants to reuse it in a different setting (as requested). I don't support nested graph for now though, as it is not clear for me the best way to build them. >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Simon >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Moose-dev mailing list >>>>>>>>> Moose-dev(a)iam.unibe.ch >>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Lukas Renggli >>>>>>>> www.lukas-renggli.ch >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Moose-dev mailing list >>>>>>>> Moose-dev(a)iam.unibe.ch >>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>>> >>>>>>> -- >>>>>>> Simon >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Moose-dev mailing list >>>>>>> Moose-dev(a)iam.unibe.ch >>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>> >>>>>> -- >>>>>> www.tudorgirba.com >>>>>> >>>>>> "Not knowing how to do something is not an argument for how it cannot be done." >>>>>> >>>>> >>>>> -- >>>>> www.tudorgirba.com >>>>> >>>>> "Be rather willing to give than demanding to get." >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> Moose-dev(a)iam.unibe.ch >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> -- >>>> Simon >>>> >>>> >>>> >>> >>> -- >>> Simon >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev(a)iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> www.tudorgirba.com >> >> "We cannot reach the flow of things unless we let go." >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > Simon > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev

1 0

Re: Urget question about CodeCity
by Simon Denier 28 Sep '10

28 Sep '10

On 23 sept. 2010, at 10:30, Mariano Martinez Peck wrote: > Hi Folks...Sorry for the "urgen" but I got an idea for my paper with deadline tomorro hahahahah > > I was using DistributionMaps where the containers were packages for example, elements classes, and properties the amount of instances. For example, see the attached screenshot. > > Now....it is difficult to find the classes with most instances since I need to search for an specific color. I am not sure I understand what it is difficult: - because the mapping color <-> range does not match your expectations (like red would be highest, blue would be lowest) - or because you are looking for one class with the most instances - or because you want to compare the real values, not ranges. > > I thoguht that having someting like CodeCity can be interesting. I would like: > > - EAch building (square) is a container -> package > - Each little squeare (that has heigh) is a element -> class > - The heigh is a property, in this case, the amount of instances for example. > > Then I can easily see packages/classes with several intances easily (the highest ones). > > So...is that possible? how easier? :) > > Right now I was doing my DM something like this: > > I checked for *City* class in Moose 4.1 but I didn't find anything :( > > The only thing I found was this link: http://www.moosetechnology.org/tools/vw/codecity > > Thanks for any help > > Mariano > <amuntUsedInstances.png>_______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- Simon

4 4

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev September 2010