Hi,
Synoptic is a nice tool that offers mining of event state machines from custom logs. You basically get some log file, you define a regular expression that identifies the events (usually, an event on each line) and then pass both the file and the expression to Synoptic.
The result is an inferred state machine. This sounds pretty cool, and I think it can be used as an importer for Moose.
Here is the development webpage:
http://code.google.com/p/synoptic/
Cheers,
Doru
--
www.tudorgirba.com
"If you interrupt the barber while he is cutting your hair,
you will end up with a messy haircut."
---------- Forwarded message ----------
From: Franco Sabadini <fsabadi(a)gmail.com>
Date: 2011/6/21
Subject: problems linking code
To: info(a)moosetechnology.org
Cc: juan.yue(a)hotmail.com, Santiago Vidal <santiago.a.vidal(a)gmail.com>
Hello,
We're trying to use Moose to analyze code replication on a Java application,
but we haven't been able to link the model with the code, we already tried
the 2 possibilities that are shown on the moose book and nothing worked,
also we tried to do it with ArgoUML app and we couldn't do it either.
The Moose versions we tried are from 4.0 to 4.5, and we tried it in linux,
windows and in mac OS.
Do you have any idea what could be happening?
Thanks.
- Franco
Hello,
I created a extension of the FAMIX meta-model to support XML. It was also
implemented an importer, some metrics and some simple visualization to the
XML tree.
The importer is in "Import FAMIX XML model from file sources" on the import
menu of Moose. It possible to import: setting a file, a directory with XML
files or from an URL.
Visualization is now under a group of FAMIXXMLElement ->
FAMIXXMLElementGroup.
To try, first install the last version of Merlin and then the FamixXML:
Gofer new
squeaksource: 'FamixXML';
package: 'ConfigurationOfMerlin';
load.
(ConfigurationOfMerlin project version: #development) load.
Gofer new
squeaksource: 'FamixXML';
package: 'ConfigurationOfFamixXML';
load.
(Smalltalk at: #ConfigurationOfFamixXML) perform: #loadDefault
regards,
--
Andre Hora
Hi,
I am happy you like Moose.
We know that "MooseScripts createModelForConfigurationOfMoose" creates a model that is stored in a global model cache. However, the idea was to reproduce an image that is large enough to not be openable with the Windows VM. The image with three large models opens just fine on Mac.
In the meantime, Igor produced a new version of the Windows VM that enables one to load this image. However, now the question is when these fixes will make it in the main branch.
Igor, do you happen to have an update on this issue?
Cheers,
Doru
On 26 Jun 2011, at 18:43, Alain Rastoul wrote:
> Hi,
> There was a previous message in the list about an out of memory problem with
> Moose when running
> 3 times MooseScripts createModelForConfigurationOfMoose
> I downloaded moose suite 4.5 (Pharo 1.3) and played a bit with it reading
> the moose book (nice).
>
> IMHO although something is perhaps not completly clear in the vm in memory
> allocation and/or ui process and/or low space watcher (I tryed to debug the
> vm but did not succeed), here the problem seems to be in the Moose model.
> I suspect that the problem is just that the cache keeps a reference to the
> Moose model each time the script is run, see at the end of
> MooseScripts>>createModelForConfigurationOfMoose the model is added to a
> cache ((MooseModel root => MooseGroupRuntimeStorage>> byType) and takes abut
> 130M of memory each time.
> clearing the Moose cache resolve the problem.
> MooseModel allInstancesDo:[ :m | m remove ] seems to be working here, except
> that there is an exception for the root model (I don't know Moose, it may
> not be the best command).
> Perhaps the moose model should not be added by type but overriden each time
> (beeing identified by a "name" ?).
>
> PS: Moose is cool :)
>
> Cheers
> Alain
>
>
>
>
--
www.tudorgirba.com
"Problem solving efficiency grows with the abstractness level of problem understanding."
Hi,
For Java, there is a grammar in PetitJava.
This ships with Moose and is available in the PetitJava squeaksource repo.
Cheers,
Doru
On 26 Jun 2011, at 18:59, Alain Rastoul wrote:
> Hi all,
>
> Do someone know about a PetitParser grammar for c# or java ?
> Verveine seems to be a Java development (and is not accessible).
> TIA
>
> Cheers
> Alain
>
>
>
>
--
www.tudorgirba.com
"Every successful trip needs a suitable vehicle."
On Jun 26, 2011, at 6:59 PM, Alain Rastoul wrote:
> Hi all,
>
> Do someone know about a PetitParser grammar for c# or java ?
> Verveine seems to be a Java development (and is not accessible).
Verveine is based on JDT.
> TIA
>
> Cheers
> Alain
>
>
>
>
Begin forwarded message:
> From: "Alain Rastoul" <alr.dev(a)free.fr>
> Date: June 26, 2011 6:43:58 PM GMT+02:00
> To: pharo-project(a)lists.gforge.inria.fr
> Subject: [Pharo-project] Moose out of memory
> Reply-To: Pharo-project(a)lists.gforge.inria.fr
>
> Hi,
> There was a previous message in the list about an out of memory problem with
> Moose when running
> 3 times MooseScripts createModelForConfigurationOfMoose
> I downloaded moose suite 4.5 (Pharo 1.3) and played a bit with it reading
> the moose book (nice).
>
> IMHO although something is perhaps not completly clear in the vm in memory
> allocation and/or ui process and/or low space watcher (I tryed to debug the
> vm but did not succeed), here the problem seems to be in the Moose model.
> I suspect that the problem is just that the cache keeps a reference to the
> Moose model each time the script is run, see at the end of
> MooseScripts>>createModelForConfigurationOfMoose the model is added to a
> cache ((MooseModel root => MooseGroupRuntimeStorage>> byType) and takes abut
> 130M of memory each time.
> clearing the Moose cache resolve the problem.
> MooseModel allInstancesDo:[ :m | m remove ] seems to be working here, except
> that there is an exception for the root model (I don't know Moose, it may
> not be the best command).
> Perhaps the moose model should not be added by type but overriden each time
> (beeing identified by a "name" ?).
>
> PS: Moose is cool :)
>
> Cheers
> Alain
>
>
>
>
Is there a way to do something like:
#digit asParser, 'same digit that I just parsed' asParser ?
I snooped around and saw PPMemoizedParser, but didn't exactly understand the
test for it.
Thanks.
Sean
--
View this message in context: http://forum.world.st/PetitParser-refer-to-previous-values-tp3624600p362460…
Sent from the Moose mailing list archive at Nabble.com.
Hello,
I created a extension of the FAMIX meta-model to support XML. It was also
implemented an importer, some metrics and some simple visualization to the
XML tree.
The importer is in "Import FAMIX XML model from file sources" on the import
menu of Moose. It possible to import: setting a file, a directory with XML
files or from an URL.
Visualization is now under a group of FAMIXXMLElement ->
FAMIXXMLElementGroup.
To try, first install the last version of Merlin and then the FamixXML:
Gofer new
squeaksource: 'FamixXML';
package: 'ConfigurationOfMerlin';
load.
(ConfigurationOfMerlin project version: #development) load.
Gofer new
squeaksource: 'FamixXML';
package: 'ConfigurationOfFamixXML';
load.
(Smalltalk at: #ConfigurationOfFamixXML) perform: #loadDefault
regards,
--
Andre Hora
For a project on a large Eclipse Application (Papyrus, for drawing UML graphs), we needed to add Eclipse Plugins.
Jannik did a first implementation in Famix to be able to run moose, but it would be nice to do-it-right.
So the proposition would be (this is not how we implemented it right now):
FamixComponent sub-concept of FamixEntity
has:
- belongsTo another FamixComponent
- childNamedEntities
A component is suppose to provide interfaces and require interfaces.
How can we represent that? with Type?
Eclipse plugins actually decalre other plugins that they require. I believe this is not standard as component should only rely on interfaces, not other explicitly named components ...
all input welcome
nicolas
