Moose for SAS

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

Moose for SAS

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

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: Moose for SAS

Tudor Girba
Hi Ross,

> Some people suggested trying moose for analysis of SAS programs, and  
> I'm
> trying to figure out where to start with the meta-modeling.

Welcome to Moose :).

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

FAMIX is a meta-model, FM3 is the meta-meta-model. If a clarification  
of terms is needed, you can check:
http://www.tudorgirba.com/blog/subject-model-meta-model

The core of FAMIX models in a language independent fashion object-
oriented and procedural languages. You can see a diagrammatic overview  
here:
http://www.themoosebook.org/book/internals/famix/core

I do not know SAS, but you should check to see if the concepts present  
in FAMIX are of use to you. If yes, you can directly instantiate them  
from your parser. If not, then you will want to code a new meta-model,  
or extend the current ones to accommodate your needs. You can then  
describe this new meta-model using FM3 (this is achieved via Smalltalk  
pragmas) and you get a browser and import-export in the MSE format for  
free.

Once you have your Smalltalk objects as instances of the meta-model,  
you can then use Mondrian and Glamour for building visual tools, or  
the MooseAlgos to express graph-specific algorithms.

Does this help?

Cheers,
Doru

> 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
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--
www.tudorgirba.com

"Relationships are of two kinds: those we choose and those that  
happen. They both matter."




_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: Moose for SAS

Ross Boylan
On Wed, 2010-06-16 at 02:17 +0200, Tudor Girba wrote:

>
> I do not know SAS, but you should check to see if the concepts
> present  
> in FAMIX are of use to you. If yes, you can directly instantiate
> them  
> from your parser. If not, then you will want to code a new
> meta-model,  
> or extend the current ones to accommodate your needs. You can then  
> describe this new meta-model using FM3 (this is achieved via
> Smalltalk  
> pragmas) and you get a browser and import-export in the MSE format
> for  
> free.
>
> Once you have your Smalltalk objects as instances of the meta-model,  
> you can then use Mondrian and Glamour for building visual tools, or  
> the MooseAlgos to express graph-specific algorithms.
>
> Does this help?
Well, I was hoping that I would need to specify the meta-model or the
meta-meta-model, but not both.  That is, I was hoping the tools could
build one out of the other.  It sounds as if you're telling me I need to
do both.

I hope I'm misunderstanding :)

Also, is there a guide to what the pragmas are?

Ross

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: Moose for SAS

Tudor Girba
Hi,

On 16 Jun 2010, at 02:27, Ross Boylan wrote:

> On Wed, 2010-06-16 at 02:17 +0200, Tudor Girba wrote:
>>
>> I do not know SAS, but you should check to see if the concepts
>> present
>> in FAMIX are of use to you. If yes, you can directly instantiate
>> them
>> from your parser. If not, then you will want to code a new
>> meta-model,
>> or extend the current ones to accommodate your needs. You can then
>> describe this new meta-model using FM3 (this is achieved via
>> Smalltalk
>> pragmas) and you get a browser and import-export in the MSE format
>> for
>> free.
>>
>> Once you have your Smalltalk objects as instances of the meta-model,
>> you can then use Mondrian and Glamour for building visual tools, or
>> the MooseAlgos to express graph-specific algorithms.
>>
>> Does this help?
> Well, I was hoping that I would need to specify the meta-model or the
> meta-meta-model, but not both.  That is, I was hoping the tools could
> build one out of the other.  It sounds as if you're telling me I  
> need to
> do both.

You do not define the meta-meta-model, you use the existing one (FM3)  
by just describing in your meta-model elements (classes and  
attributes) using pragmas. That is, the meta-model holds the Smalltalk  
implementation, while the pragmas provide a higher level description  
for other kinds of manipulations.

> I hope I'm misunderstanding :)

I think you are :)

> Also, is there a guide to what the pragmas are?

We do not have much of a guide for the moment, but we have plenty of  
examples. For a class named "C" with one attribute  
"interestingAttribute" of type String, you have to define the  
followings:
- On the class size:
annotation
        <MSEClass: 'X'>

- On the instance side:
interestingAttribute
        <MSEProperty: #interestingAttribute type: #String>
        ^ interestingAttribute

Cheers,
Doru

> Ross
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> 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."

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: Moose for SAS

Ross Boylan
In reply to this post by Ross Boylan
On Tue, 2010-06-15 at 17:27 -0700, Ross Boylan wrote:

> On Wed, 2010-06-16 at 02:17 +0200, Tudor Girba wrote:
> >
> > I do not know SAS, but you should check to see if the concepts
> > present  
> > in FAMIX are of use to you. If yes, you can directly instantiate
> > them  
> > from your parser. If not, then you will want to code a new
> > meta-model,  
> > or extend the current ones to accommodate your needs. You can then  
> > describe this new meta-model using FM3 (this is achieved via
> > Smalltalk  
> > pragmas) and you get a browser and import-export in the MSE format
> > for  
> > free.
> >
> > Once you have your Smalltalk objects as instances of the meta-model,  
> > you can then use Mondrian and Glamour for building visual tools, or  
> > the MooseAlgos to express graph-specific algorithms.
> >
> > Does this help?
> Well, I was hoping that I would need to specify the meta-model or the
> meta-meta-model, but not both.
Whoops: I think I meant model or meta-model.
>  That is, I was hoping the tools could
> build one out of the other.  It sounds as if you're telling me I need to
> do both.
>
> I hope I'm misunderstanding :)
>
> Also, is there a guide to what the pragmas are?
>
I meant the FM3 pragmas.
> Ross
>

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: Moose for SAS

Ross Boylan
In reply to this post by Tudor Girba
On Wed, 2010-06-16 at 02:43 +0200, Tudor Girba wrote:

> Hi,
>
> On 16 Jun 2010, at 02:27, Ross Boylan wrote:
>
> > On Wed, 2010-06-16 at 02:17 +0200, Tudor Girba wrote:
> >>
> >> I do not know SAS, but you should check to see if the concepts
> >> present
> >> in FAMIX are of use to you. If yes, you can directly instantiate
> >> them
> >> from your parser. If not, then you will want to code a new
> >> meta-model,
> >> or extend the current ones to accommodate your needs. You can then
> >> describe this new meta-model using FM3 (this is achieved via
> >> Smalltalk
> >> pragmas) and you get a browser and import-export in the MSE format
> >> for
> >> free.
> >>
> >> Once you have your Smalltalk objects as instances of the meta-model,
> >> you can then use Mondrian and Glamour for building visual tools, or
> >> the MooseAlgos to express graph-specific algorithms.
> >>
> >> Does this help?
> > Well, I was hoping that I would need to specify the meta-model or the
> > meta-meta-model, but not both.  That is, I was hoping the tools could
> > build one out of the other.  It sounds as if you're telling me I  
> > need to
> > do both.
>
> You do not define the meta-meta-model, you use the existing one (FM3)  
> by just describing in your meta-model elements (classes and  
> attributes) using pragmas. That is, the meta-model holds the Smalltalk  
> implementation, while the pragmas provide a higher level description  
> for other kinds of manipulations.
>
> > I hope I'm misunderstanding :)
>
> I think you are :)
>
> > Also, is there a guide to what the pragmas are?
>
> We do not have much of a guide for the moment, but we have plenty of  
> examples. For a class named "C" with one attribute  
> "interestingAttribute" of type String, you have to define the  
> followings:
> - On the class size:
> annotation
> <MSEClass: 'X'>
>
> - On the instance side:
> interestingAttribute
> <MSEProperty: #interestingAttribute type: #String>
> ^ interestingAttribute
>
> Cheers,
> Doru
So, rephrasing the question slightly, is there a way to generate the
smalltalk implementation directly from the pragmas?  Or, even better, a
graphical tool that allows you to specify the model and produces
everything else from it?

On the pragmas, at least some of them are "documented" by the methods
FMPragmaProcessor>>processCompiledMethod:
MSEPragmaProcessor>>processClass:

There are some huge strings that are (meta-)*model specifications, e.g.,
FAMIXSpecifications>>famixCore30mse and their use by
FAMIXSpecifications>>generateFamixCore30.  What role do they play in the
system?

Ross

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: Moose for SAS

Tudor Girba
Hi,

On 16 Jun 2010, at 05:33, Ross Boylan wrote:

> On Wed, 2010-06-16 at 02:43 +0200, Tudor Girba wrote:
>> Hi,
>>
>> On 16 Jun 2010, at 02:27, Ross Boylan wrote:
>>
>>> On Wed, 2010-06-16 at 02:17 +0200, Tudor Girba wrote:
>>>>
>>>> I do not know SAS, but you should check to see if the concepts
>>>> present
>>>> in FAMIX are of use to you. If yes, you can directly instantiate
>>>> them
>>>> from your parser. If not, then you will want to code a new
>>>> meta-model,
>>>> or extend the current ones to accommodate your needs. You can then
>>>> describe this new meta-model using FM3 (this is achieved via
>>>> Smalltalk
>>>> pragmas) and you get a browser and import-export in the MSE format
>>>> for
>>>> free.
>>>>
>>>> Once you have your Smalltalk objects as instances of the meta-
>>>> model,
>>>> you can then use Mondrian and Glamour for building visual tools, or
>>>> the MooseAlgos to express graph-specific algorithms.
>>>>
>>>> Does this help?
>>> Well, I was hoping that I would need to specify the meta-model or  
>>> the
>>> meta-meta-model, but not both.  That is, I was hoping the tools  
>>> could
>>> build one out of the other.  It sounds as if you're telling me I
>>> need to
>>> do both.
>>
>> You do not define the meta-meta-model, you use the existing one (FM3)
>> by just describing in your meta-model elements (classes and
>> attributes) using pragmas. That is, the meta-model holds the  
>> Smalltalk
>> implementation, while the pragmas provide a higher level description
>> for other kinds of manipulations.
>>
>>> I hope I'm misunderstanding :)
>>
>> I think you are :)
>>
>>> Also, is there a guide to what the pragmas are?
>>
>> We do not have much of a guide for the moment, but we have plenty of
>> examples. For a class named "C" with one attribute
>> "interestingAttribute" of type String, you have to define the
>> followings:
>> - On the class size:
>> annotation
>> <MSEClass: 'X'>
>>
>> - On the instance side:
>> interestingAttribute
>> <MSEProperty: #interestingAttribute type: #String>
>> ^ interestingAttribute
>>
>> Cheers,
>> Doru
> So, rephrasing the question slightly, is there a way to generate the
> smalltalk implementation directly from the pragmas?  Or, even  
> better, a
> graphical tool that allows you to specify the model and produces
> everything else from it?

At this moment, there is no graphical tool to define the meta-model.

> On the pragmas, at least some of them are "documented" by the methods
> FMPragmaProcessor>>processCompiledMethod:
> MSEPragmaProcessor>>processClass:

Those are all that are relevant for the meta-describing your meta-
model part.

> There are some huge strings that are (meta-)*model specifications,  
> e.g.,
> FAMIXSpecifications>>famixCore30mse and their use by
> FAMIXSpecifications>>generateFamixCore30.  What role do they play in  
> the
> system?

These strings are indeed the meta-model specifications written in the  
MSE format. From an MSE format you can generate the Smalltalk  
implementation and the other way around. For example, through the MSE  
format we can import meta-models developed in another language and  
generate the Smalltalk implementation.

As mentioned before, there is no support for graphical support for  
writing MSE files. The main reason here is that Smalltalk already  
provides a good enough solution for quickly building classes and  
methods, and annotating them is a practical solution.

However, we do have a tool for browsing an existing meta-model:
http://www.themoosebook.org/book/internals/famix/meta-browser

Cheers,
Doru


> Ross
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> 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."

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: Moose for SAS

Ross Boylan
On Wed, 2010-06-16 at 09:37 +0200, Tudor Girba wrote:
> As mentioned before, there is no support for graphical support for  
> writing MSE files. The main reason here is that Smalltalk already  
> provides a good enough solution for quickly building classes and  
> methods, and annotating them is a practical solution.
I gather there is no facility to generate the smalltalk out of the
method annotations.  Is there any reason, in principle, that it couldn't
be done?

Ross

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: Moose for SAS

Tudor Girba
Hi Ross,

On 16 Jun 2010, at 21:17, Ross Boylan wrote:

> On Wed, 2010-06-16 at 09:37 +0200, Tudor Girba wrote:
>> As mentioned before, there is no support for graphical support for
>> writing MSE files. The main reason here is that Smalltalk already
>> provides a good enough solution for quickly building classes and
>> methods, and annotating them is a practical solution.
> I gather there is no facility to generate the smalltalk out of the
> method annotations.  Is there any reason, in principle, that it  
> couldn't
> be done?

Well, if you have the method annotations, you already have the  
Smalltalk code :).

Right now, the only possibility is to generate Smalltalk code out of  
MSE code that represents your meta-model. This is like the famixCore  
string that you saw in the image.

Cheers,
Doru


--
www.tudorgirba.com

"Not knowing how to do something is not an argument for how it cannot  
be done."

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: Moose for SAS

Ross Boylan
On Wed, 2010-06-16 at 22:14 +0200, Tudor Girba wrote:

> Hi Ross,
>
> On 16 Jun 2010, at 21:17, Ross Boylan wrote:
>
> > On Wed, 2010-06-16 at 09:37 +0200, Tudor Girba wrote:
> >> As mentioned before, there is no support for graphical support for
> >> writing MSE files. The main reason here is that Smalltalk already
> >> provides a good enough solution for quickly building classes and
> >> methods, and annotating them is a practical solution.
> > I gather there is no facility to generate the smalltalk out of the
> > method annotations.  Is there any reason, in principle, that it  
> > couldn't
> > be done?
>
> Well, if you have the method annotations, you already have the  
> Smalltalk code :).
Consider RPGDragon>>hoard
        <MSEProperty: #hoard type: #RPGTreasure opposite: #keeper>
<multivalued>
        ^hoard
^hoard is smalltalk code.  You also have to create the instance
variable, define
hoard: aTreasure
        hoard value: aTreasure
and
initialize
        super initialize.
        hoard := FMMultivalueLink on: self opposite: #keeper:.
        killedBy := FMMultiMultivalueLink on: self opposite: #kills.

It's the redundancy, along with the possibilities for error that would
put the smalltalk and annotation out of sync, that concerns me (and that
I'm trying to avoid).

I do not in some other classes the names in the annotations and the
names of the methods and variables are not quite in sync, so maybe this
is a feature.
Ross

>
> Right now, the only possibility is to generate Smalltalk code out of  
> MSE code that represents your meta-model. This is like the famixCore  
> string that you saw in the image.
>
> Cheers,
> Doru
>
>
> --
> www.tudorgirba.com
>
> "Not knowing how to do something is not an argument for how it cannot  
> be done."
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: Moose for SAS

Simon Denier-3
Hi Ross


It's true that the metamodeling tools in Moose seem crude compared to what exist elsewhere, but that's because we spend much more time using metamodels in new tools than building metamodels :)


Here is the procedure when you need to define a completely new metamodel. You can still make mistake when defining the metamodel but it eliminates most redundancy.
Once you have defined your metamodel, a set of lint rules can be run to check some aspects of the metamodel (see below)

The essential pragma documentation is here (should be integrated in the book)
http://code.google.com/p/moose-technology/wiki/FameMetaDescriptions

Also, a good rule of thumb is to have MooseEntity as root instead of Object, it facilitates integration with Moose tools.


1) Metamodel declaration
For the example below:
- Create class RPGDragon from a class browser
- add (class-side)
RPGDragon class>>annotation
        <MSEClass: #Dragon super: #Object>
        <package: #RPG>

Notice I just define the method with pragmas, I don't add any code in the body for now.

For each attribute, I need to define the accessor (the getter, not the setter):
- define RPGDragon>>hoard
        <MSEProperty: #hoard type: #RPGTreasure opposite: #keeper><multivalued>

(same thing, method decl + pragma, no code)
No need to add the initialize, it will be defined by the generator.


2) To generate the implementation, do:
MooseModel generateClassesFrom: {RPGDragon. RPGHero. RPGWall} "collection of classes defining the metamodel"

It should open a preview window, where you can see which method will be defined/overridden by the generator. You can always tap Cmd-x to remove the selected definition (in case you are doing some incremental metamodel definition).
You can repeat the generation step as much as you want, provided you understand it will overwrite existing methods.

It works like a charm if you are doing your own metamodel. If you need to extend (as in class extension, not the Java extend for inheritance) some existing Famix classes with new attributes, you should be a bit more careful. Actually, when I need to extend an existing metamodel with a few attributes, I just define the attributes directly in the Smalltalk way (with pragmas AND method body). It's fast to do.


3) optionally, check that your metamodel is correct with lint rules (especially soundness of opposite relationships): can be done from the meta browser...





On 16 juin 2010, at 22:36, Ross Boylan wrote:

> On Wed, 2010-06-16 at 22:14 +0200, Tudor Girba wrote:
>> Hi Ross,
>>
>> On 16 Jun 2010, at 21:17, Ross Boylan wrote:
>>
>>> On Wed, 2010-06-16 at 09:37 +0200, Tudor Girba wrote:
>>>> As mentioned before, there is no support for graphical support for
>>>> writing MSE files. The main reason here is that Smalltalk already
>>>> provides a good enough solution for quickly building classes and
>>>> methods, and annotating them is a practical solution.
>>> I gather there is no facility to generate the smalltalk out of the
>>> method annotations.  Is there any reason, in principle, that it  
>>> couldn't
>>> be done?
>>
>> Well, if you have the method annotations, you already have the  
>> Smalltalk code :).
> Consider RPGDragon>>hoard
> <MSEProperty: #hoard type: #RPGTreasure opposite: #keeper>
> <multivalued>
> ^hoard
> ^hoard is smalltalk code.  You also have to create the instance
> variable, define
> hoard: aTreasure
> hoard value: aTreasure
> and
> initialize
> super initialize.
> hoard := FMMultivalueLink on: self opposite: #keeper:.
> killedBy := FMMultiMultivalueLink on: self opposite: #kills.
>
> It's the redundancy, along with the possibilities for error that would
> put the smalltalk and annotation out of sync, that concerns me (and that
> I'm trying to avoid).
>
> I do not in some other classes the names in the annotations and the
> names of the methods and variables are not quite in sync, so maybe this
> is a feature.
> Ross
>>
>> Right now, the only possibility is to generate Smalltalk code out of  
>> MSE code that represents your meta-model. This is like the famixCore  
>> string that you saw in the image.
>>
>> Cheers,
>> Doru
>>
>>
>> --
>> www.tudorgirba.com
>>
>> "Not knowing how to do something is not an argument for how it cannot  
>> be done."
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--
 Simon




_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: Moose for SAS

Alexandre Bergel
Thanks simon for this documentation

Alexandre


On 24 Jun 2010, at 18:21, Simon Denier wrote:

> Hi Ross
>
>
> It's true that the metamodeling tools in Moose seem crude compared to what exist elsewhere, but that's because we spend much more time using metamodels in new tools than building metamodels :)
>
>
> Here is the procedure when you need to define a completely new metamodel. You can still make mistake when defining the metamodel but it eliminates most redundancy.
> Once you have defined your metamodel, a set of lint rules can be run to check some aspects of the metamodel (see below)
>
> The essential pragma documentation is here (should be integrated in the book)
> http://code.google.com/p/moose-technology/wiki/FameMetaDescriptions
>
> Also, a good rule of thumb is to have MooseEntity as root instead of Object, it facilitates integration with Moose tools.
>
>
> 1) Metamodel declaration
> For the example below:
> - Create class RPGDragon from a class browser
> - add (class-side)
> RPGDragon class>>annotation
> <MSEClass: #Dragon super: #Object>
> <package: #RPG>
>
> Notice I just define the method with pragmas, I don't add any code in the body for now.
>
> For each attribute, I need to define the accessor (the getter, not the setter):
> - define RPGDragon>>hoard
> <MSEProperty: #hoard type: #RPGTreasure opposite: #keeper><multivalued>
>
> (same thing, method decl + pragma, no code)
> No need to add the initialize, it will be defined by the generator.
>
>
> 2) To generate the implementation, do:
> MooseModel generateClassesFrom: {RPGDragon. RPGHero. RPGWall} "collection of classes defining the metamodel"
>
> It should open a preview window, where you can see which method will be defined/overridden by the generator. You can always tap Cmd-x to remove the selected definition (in case you are doing some incremental metamodel definition).
> You can repeat the generation step as much as you want, provided you understand it will overwrite existing methods.
>
> It works like a charm if you are doing your own metamodel. If you need to extend (as in class extension, not the Java extend for inheritance) some existing Famix classes with new attributes, you should be a bit more careful. Actually, when I need to extend an existing metamodel with a few attributes, I just define the attributes directly in the Smalltalk way (with pragmas AND method body). It's fast to do.
>
>
> 3) optionally, check that your metamodel is correct with lint rules (especially soundness of opposite relationships): can be done from the meta browser...
>
>
>
>
>
> On 16 juin 2010, at 22:36, Ross Boylan wrote:
>
>> On Wed, 2010-06-16 at 22:14 +0200, Tudor Girba wrote:
>>> Hi Ross,
>>>
>>> On 16 Jun 2010, at 21:17, Ross Boylan wrote:
>>>
>>>> On Wed, 2010-06-16 at 09:37 +0200, Tudor Girba wrote:
>>>>> As mentioned before, there is no support for graphical support for
>>>>> writing MSE files. The main reason here is that Smalltalk already
>>>>> provides a good enough solution for quickly building classes and
>>>>> methods, and annotating them is a practical solution.
>>>> I gather there is no facility to generate the smalltalk out of the
>>>> method annotations.  Is there any reason, in principle, that it  
>>>> couldn't
>>>> be done?
>>>
>>> Well, if you have the method annotations, you already have the  
>>> Smalltalk code :).
>> Consider RPGDragon>>hoard
>> <MSEProperty: #hoard type: #RPGTreasure opposite: #keeper>
>> <multivalued>
>> ^hoard
>> ^hoard is smalltalk code.  You also have to create the instance
>> variable, define
>> hoard: aTreasure
>> hoard value: aTreasure
>> and
>> initialize
>> super initialize.
>> hoard := FMMultivalueLink on: self opposite: #keeper:.
>> killedBy := FMMultiMultivalueLink on: self opposite: #kills.
>>
>> It's the redundancy, along with the possibilities for error that would
>> put the smalltalk and annotation out of sync, that concerns me (and that
>> I'm trying to avoid).
>>
>> I do not in some other classes the names in the annotations and the
>> names of the methods and variables are not quite in sync, so maybe this
>> is a feature.
>> Ross
>>>
>>> Right now, the only possibility is to generate Smalltalk code out of  
>>> MSE code that represents your meta-model. This is like the famixCore  
>>> string that you saw in the image.
>>>
>>> Cheers,
>>> Doru
>>>
>>>
>>> --
>>> www.tudorgirba.com
>>>
>>> "Not knowing how to do something is not an argument for how it cannot  
>>> be done."
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> [hidden email]
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> Simon
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev



--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.






_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Fwd: Re: Moose for SAS

simondenier
In reply to this post by Simon Denier-3

There was some questions last week about extending the Famix metamodel. I just forward the following guide I wrote last year. It should be formatted and put online too.


Begin forwarded message:

From: Simon Denier <[hidden email]>
Date: 24 juin 2010 18:21:34 HAEC
To: Related to the development of Moose and other related tools <[hidden email]>
Cc: Simon Denier <[hidden email]>
Subject: Re: [Moose-dev] Re: Moose for SAS

Hi Ross


It's true that the metamodeling tools in Moose seem crude compared to what exist elsewhere, but that's because we spend much more time using metamodels in new tools than building metamodels :)


Here is the procedure when you need to define a completely new metamodel. You can still make mistake when defining the metamodel but it eliminates most redundancy.
Once you have defined your metamodel, a set of lint rules can be run to check some aspects of the metamodel (see below)

The essential pragma documentation is here (should be integrated in the book)
http://code.google.com/p/moose-technology/wiki/FameMetaDescriptions

Also, a good rule of thumb is to have MooseEntity as root instead of Object, it facilitates integration with Moose tools.


1) Metamodel declaration
For the example below:
- Create class RPGDragon from a class browser
- add (class-side)
RPGDragon class>>annotation
<MSEClass: #Dragon super: #Object>
<package: #RPG>

Notice I just define the method with pragmas, I don't add any code in the body for now.

For each attribute, I need to define the accessor (the getter, not the setter):
- define RPGDragon>>hoard
<MSEProperty: #hoard type: #RPGTreasure opposite: #keeper><multivalued>

(same thing, method decl + pragma, no code)
No need to add the initialize, it will be defined by the generator.


2) To generate the implementation, do:
MooseModel generateClassesFrom: {RPGDragon. RPGHero. RPGWall} "collection of classes defining the metamodel"

It should open a preview window, where you can see which method will be defined/overridden by the generator. You can always tap Cmd-x to remove the selected definition (in case you are doing some incremental metamodel definition).
You can repeat the generation step as much as you want, provided you understand it will overwrite existing methods.

It works like a charm if you are doing your own metamodel. If you need to extend (as in class extension, not the Java extend for inheritance) some existing Famix classes with new attributes, you should be a bit more careful. Actually, when I need to extend an existing metamodel with a few attributes, I just define the attributes directly in the Smalltalk way (with pragmas AND method body). It's fast to do.


3) optionally, check that your metamodel is correct with lint rules (especially soundness of opposite relationships): can be done from the meta browser...





On 16 juin 2010, at 22:36, Ross Boylan wrote:

On Wed, 2010-06-16 at 22:14 +0200, Tudor Girba wrote:
Hi Ross,

On 16 Jun 2010, at 21:17, Ross Boylan wrote:

On Wed, 2010-06-16 at 09:37 +0200, Tudor Girba wrote:
As mentioned before, there is no support for graphical support for
writing MSE files. The main reason here is that Smalltalk already
provides a good enough solution for quickly building classes and
methods, and annotating them is a practical solution.
I gather there is no facility to generate the smalltalk out of the
method annotations.  Is there any reason, in principle, that it  
couldn't
be done?

Well, if you have the method annotations, you already have the  
Smalltalk code :).
Consider RPGDragon>>hoard
<MSEProperty: #hoard type: #RPGTreasure opposite: #keeper>
<multivalued>
^hoard
^hoard is smalltalk code.  You also have to create the instance
variable, define
hoard: aTreasure
hoard value: aTreasure
and
initialize
super initialize.
hoard := FMMultivalueLink on: self opposite: #keeper:.
killedBy := FMMultiMultivalueLink on: self opposite: #kills.

It's the redundancy, along with the possibilities for error that would
put the smalltalk and annotation out of sync, that concerns me (and that
I'm trying to avoid).

I do not in some other classes the names in the annotations and the
names of the methods and variables are not quite in sync, so maybe this
is a feature.
Ross

Right now, the only possibility is to generate Smalltalk code out of  
MSE code that represents your meta-model. This is like the famixCore  
string that you saw in the image.

Cheers,
Doru


--
www.tudorgirba.com

"Not knowing how to do something is not an argument for how it cannot  
be done."

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--
Simon




--
Simon Denier




_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Re: Moose for SAS

Nicolas Anquetil
I was discussing with Usman yesterday about these emails to the list that are also documentation artefacts.

It would be nice to have a mean to flag such emails (manually) so that they can form collectively some documentation of Moose that would be easier to search in than the entire mailing list archive.

nicolas


De: "Simon Denier" <[hidden email]>
À: "Moose-related development" <[hidden email]>
Envoyé: Mardi 7 Juin 2011 09:40:55
Objet: [Moose-dev] Fwd:  Re: Moose for SAS


There was some questions last week about extending the Famix metamodel. I just forward the following guide I wrote last year. It should be formatted and put online too.


Begin forwarded message:

From: Simon Denier <[hidden email]>
Date: 24 juin 2010 18:21:34 HAEC
To: Related to the development of Moose and other related tools <[hidden email]>
Cc: Simon Denier <[hidden email]>
Subject: Re: [Moose-dev] Re: Moose for SAS

Hi Ross


It's true that the metamodeling tools in Moose seem crude compared to what exist elsewhere, but that's because we spend much more time using metamodels in new tools than building metamodels :)


Here is the procedure when you need to define a completely new metamodel. You can still make mistake when defining the metamodel but it eliminates most redundancy.
Once you have defined your metamodel, a set of lint rules can be run to check some aspects of the metamodel (see below)

The essential pragma documentation is here (should be integrated in the book)
http://code.google.com/p/moose-technology/wiki/FameMetaDescriptions

Also, a good rule of thumb is to have MooseEntity as root instead of Object, it facilitates integration with Moose tools.


1) Metamodel declaration
For the example below:
- Create class RPGDragon from a class browser
- add (class-side)
RPGDragon class>>annotation
<MSEClass: #Dragon super: #Object>
<package: #RPG>

Notice I just define the method with pragmas, I don't add any code in the body for now.

For each attribute, I need to define the accessor (the getter, not the setter):
- define RPGDragon>>hoard
<MSEProperty: #hoard type: #RPGTreasure opposite: #keeper><multivalued>

(same thing, method decl + pragma, no code)
No need to add the initialize, it will be defined by the generator.


2) To generate the implementation, do:
MooseModel generateClassesFrom: {RPGDragon. RPGHero. RPGWall} "collection of classes defining the metamodel"

It should open a preview window, where you can see which method will be defined/overridden by the generator. You can always tap Cmd-x to remove the selected definition (in case you are doing some incremental metamodel definition).
You can repeat the generation step as much as you want, provided you understand it will overwrite existing methods.

It works like a charm if you are doing your own metamodel. If you need to extend (as in class extension, not the Java extend for inheritance) some existing Famix classes with new attributes, you should be a bit more careful. Actually, when I need to extend an existing metamodel with a few attributes, I just define the attributes directly in the Smalltalk way (with pragmas AND method body). It's fast to do.


3) optionally, check that your metamodel is correct with lint rules (especially soundness of opposite relationships): can be done from the meta browser...





On 16 juin 2010, at 22:36, Ross Boylan wrote:

On Wed, 2010-06-16 at 22:14 +0200, Tudor Girba wrote:
Hi Ross,

On 16 Jun 2010, at 21:17, Ross Boylan wrote:

On Wed, 2010-06-16 at 09:37 +0200, Tudor Girba wrote:
As mentioned before, there is no support for graphical support for
writing MSE files. The main reason here is that Smalltalk already
provides a good enough solution for quickly building classes and
methods, and annotating them is a practical solution.
I gather there is no facility to generate the smalltalk out of the
method annotations.  Is there any reason, in principle, that it  
couldn't
be done?

Well, if you have the method annotations, you already have the  
Smalltalk code :).
Consider RPGDragon>>hoard
<MSEProperty: #hoard type: #RPGTreasure opposite: #keeper>
<multivalued>
^hoard
^hoard is smalltalk code.  You also have to create the instance
variable, define
hoard: aTreasure
hoard value: aTreasure
and
initialize
super initialize.
hoard := FMMultivalueLink on: self opposite: #keeper:.
killedBy := FMMultiMultivalueLink on: self opposite: #kills.

It's the redundancy, along with the possibilities for error that would
put the smalltalk and annotation out of sync, that concerns me (and that
I'm trying to avoid).

I do not in some other classes the names in the annotations and the
names of the methods and variables are not quite in sync, so maybe this
is a feature.
Ross

Right now, the only possibility is to generate Smalltalk code out of  
MSE code that represents your meta-model. This is like the famixCore  
string that you saw in the image.

Cheers,
Doru


--
www.tudorgirba.com

"Not knowing how to do something is not an argument for how it cannot  
be done."

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--
Simon




--
Simon Denier




_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Re: Moose for SAS

simondenier
<base href="x-msg://533/">
On 7 juin 2011, at 09:53, Nicolas Anquetil wrote:

I was discussing with Usman yesterday about these emails to the list that are also documentation artefacts.

It would be nice to have a mean to flag such emails (manually) so that they can form collectively some documentation of Moose that would be easier to search in than the entire mailing list archive.


I think the simplest solution would be to copy-paste the email on the website, with just a bit of formatting. Is it ok?



nicolas


De: "Simon Denier" <[hidden email]>
À: "Moose-related development" <[hidden email]>
Envoyé: Mardi 7 Juin 2011 09:40:55
Objet: [Moose-dev] Fwd:  Re: Moose for SAS


There was some questions last week about extending the Famix metamodel. I just forward the following guide I wrote last year. It should be formatted and put online too.


Begin forwarded message:

From: Simon Denier <[hidden email]>
Date: 24 juin 2010 18:21:34 HAEC
To: Related to the development of Moose and other related tools <[hidden email]>
Cc: Simon Denier <[hidden email]>
Subject: Re: [Moose-dev] Re: Moose for SAS

Hi Ross


It's true that the metamodeling tools in Moose seem crude compared to what exist elsewhere, but that's because we spend much more time using metamodels in new tools than building metamodels :)


Here is the procedure when you need to define a completely new metamodel. You can still make mistake when defining the metamodel but it eliminates most redundancy. 
Once you have defined your metamodel, a set of lint rules can be run to check some aspects of the metamodel (see below)

The essential pragma documentation is here (should be integrated in the book)
http://code.google.com/p/moose-technology/wiki/FameMetaDescriptions

Also, a good rule of thumb is to have MooseEntity as root instead of Object, it facilitates integration with Moose tools.


1) Metamodel declaration
For the example below:
- Create class RPGDragon from a class browser
- add (class-side) 
RPGDragon class>>annotation
<MSEClass: #Dragon super: #Object>
<package: #RPG>

Notice I just define the method with pragmas, I don't add any code in the body for now.

For each attribute, I need to define the accessor (the getter, not the setter):
- define RPGDragon>>hoard
<MSEProperty: #hoard type: #RPGTreasure opposite: #keeper><multivalued>

(same thing, method decl + pragma, no code)
No need to add the initialize, it will be defined by the generator.


2) To generate the implementation, do:
MooseModel generateClassesFrom: {RPGDragon. RPGHero. RPGWall} "collection of classes defining the metamodel"

It should open a preview window, where you can see which method will be defined/overridden by the generator. You can always tap Cmd-x to remove the selected definition (in case you are doing some incremental metamodel definition).
You can repeat the generation step as much as you want, provided you understand it will overwrite existing methods.

It works like a charm if you are doing your own metamodel. If you need to extend (as in class extension, not the Java extend for inheritance) some existing Famix classes with new attributes, you should be a bit more careful. Actually, when I need to extend an existing metamodel with a few attributes, I just define the attributes directly in the Smalltalk way (with pragmas AND method body). It's fast to do.


3) optionally, check that your metamodel is correct with lint rules (especially soundness of opposite relationships): can be done from the meta browser...





On 16 juin 2010, at 22:36, Ross Boylan wrote:

On Wed, 2010-06-16 at 22:14 +0200, Tudor Girba wrote:
Hi Ross,

On 16 Jun 2010, at 21:17, Ross Boylan wrote:

On Wed, 2010-06-16 at 09:37 +0200, Tudor Girba wrote:
As mentioned before, there is no support for graphical support for
writing MSE files. The main reason here is that Smalltalk already
provides a good enough solution for quickly building classes and
methods, and annotating them is a practical solution.
I gather there is no facility to generate the smalltalk out of the
method annotations.  Is there any reason, in principle, that it  
couldn't
be done?

Well, if you have the method annotations, you already have the  
Smalltalk code :).
Consider RPGDragon>>hoard
<MSEProperty: #hoard type: #RPGTreasure opposite: #keeper>
<multivalued>
^hoard
^hoard is smalltalk code.  You also have to create the instance
variable, define
hoard: aTreasure
hoard value: aTreasure
and
initialize
super initialize.
hoard := FMMultivalueLink on: self opposite: #keeper:.
killedBy := FMMultiMultivalueLink on: self opposite: #kills.

It's the redundancy, along with the possibilities for error that would
put the smalltalk and annotation out of sync, that concerns me (and that
I'm trying to avoid).

I do not in some other classes the names in the annotations and the
names of the methods and variables are not quite in sync, so maybe this
is a feature.
Ross

Right now, the only possibility is to generate Smalltalk code out of  
MSE code that represents your meta-model. This is like the famixCore  
string that you saw in the image.

Cheers,
Doru


--
www.tudorgirba.com

"Not knowing how to do something is not an argument for how it cannot  
be done."

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--
Simon




--
Simon Denier




_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--
Simon Denier




_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Re: Moose for SAS

Tudor Girba-2
Yes :)

Doru


On 7 Jun 2011, at 11:20, Simon Denier wrote:

>
> On 7 juin 2011, at 09:53, Nicolas Anquetil wrote:
>
>> I was discussing with Usman yesterday about these emails to the list that are also documentation artefacts.
>>
>> It would be nice to have a mean to flag such emails (manually) so that they can form collectively some documentation of Moose that would be easier to search in than the entire mailing list archive.
>
>
> I think the simplest solution would be to copy-paste the email on the website, with just a bit of formatting. Is it ok?
>
>
>>
>> nicolas
>>
>> De: "Simon Denier" <[hidden email]>
>> À: "Moose-related development" <[hidden email]>
>> Envoyé: Mardi 7 Juin 2011 09:40:55
>> Objet: [Moose-dev] Fwd:  Re: Moose for SAS
>>
>>
>> There was some questions last week about extending the Famix metamodel. I just forward the following guide I wrote last year. It should be formatted and put online too.
>>
>>
>> Begin forwarded message:
>>
>> From: Simon Denier <[hidden email]>
>> Date: 24 juin 2010 18:21:34 HAEC
>> To: Related to the development of Moose and other related tools <[hidden email]>
>> Cc: Simon Denier <[hidden email]>
>> Subject: Re: [Moose-dev] Re: Moose for SAS
>>
>> Hi Ross
>>
>>
>> It's true that the metamodeling tools in Moose seem crude compared to what exist elsewhere, but that's because we spend much more time using metamodels in new tools than building metamodels :)
>>
>>
>> Here is the procedure when you need to define a completely new metamodel. You can still make mistake when defining the metamodel but it eliminates most redundancy.
>> Once you have defined your metamodel, a set of lint rules can be run to check some aspects of the metamodel (see below)
>>
>> The essential pragma documentation is here (should be integrated in the book)
>> http://code.google.com/p/moose-technology/wiki/FameMetaDescriptions
>>
>> Also, a good rule of thumb is to have MooseEntity as root instead of Object, it facilitates integration with Moose tools.
>>
>>
>> 1) Metamodel declaration
>> For the example below:
>> - Create class RPGDragon from a class browser
>> - add (class-side)
>> RPGDragon class>>annotation
>> <MSEClass: #Dragon super: #Object>
>> <package: #RPG>
>>
>> Notice I just define the method with pragmas, I don't add any code in the body for now.
>>
>> For each attribute, I need to define the accessor (the getter, not the setter):
>> - define RPGDragon>>hoard
>> <MSEProperty: #hoard type: #RPGTreasure opposite: #keeper><multivalued>
>>
>> (same thing, method decl + pragma, no code)
>> No need to add the initialize, it will be defined by the generator.
>>
>>
>> 2) To generate the implementation, do:
>> MooseModel generateClassesFrom: {RPGDragon. RPGHero. RPGWall} "collection of classes defining the metamodel"
>>
>> It should open a preview window, where you can see which method will be defined/overridden by the generator. You can always tap Cmd-x to remove the selected definition (in case you are doing some incremental metamodel definition).
>> You can repeat the generation step as much as you want, provided you understand it will overwrite existing methods.
>>
>> It works like a charm if you are doing your own metamodel. If you need to extend (as in class extension, not the Java extend for inheritance) some existing Famix classes with new attributes, you should be a bit more careful. Actually, when I need to extend an existing metamodel with a few attributes, I just define the attributes directly in the Smalltalk way (with pragmas AND method body). It's fast to do.
>>
>>
>> 3) optionally, check that your metamodel is correct with lint rules (especially soundness of opposite relationships): can be done from the meta browser...
>>
>>
>>
>>
>>
>> On 16 juin 2010, at 22:36, Ross Boylan wrote:
>>
>> On Wed, 2010-06-16 at 22:14 +0200, Tudor Girba wrote:
>> Hi Ross,
>>
>> On 16 Jun 2010, at 21:17, Ross Boylan wrote:
>>
>> On Wed, 2010-06-16 at 09:37 +0200, Tudor Girba wrote:
>> As mentioned before, there is no support for graphical support for
>> writing MSE files. The main reason here is that Smalltalk already
>> provides a good enough solution for quickly building classes and
>> methods, and annotating them is a practical solution.
>> I gather there is no facility to generate the smalltalk out of the
>> method annotations.  Is there any reason, in principle, that it  
>> couldn't
>> be done?
>>
>> Well, if you have the method annotations, you already have the  
>> Smalltalk code :).
>> Consider RPGDragon>>hoard
>> <MSEProperty: #hoard type: #RPGTreasure opposite: #keeper>
>> <multivalued>
>> ^hoard
>> ^hoard is smalltalk code.  You also have to create the instance
>> variable, define
>> hoard: aTreasure
>> hoard value: aTreasure
>> and
>> initialize
>> super initialize.
>> hoard := FMMultivalueLink on: self opposite: #keeper:.
>> killedBy := FMMultiMultivalueLink on: self opposite: #kills.
>>
>> It's the redundancy, along with the possibilities for error that would
>> put the smalltalk and annotation out of sync, that concerns me (and that
>> I'm trying to avoid).
>>
>> I do not in some other classes the names in the annotations and the
>> names of the methods and variables are not quite in sync, so maybe this
>> is a feature.
>> Ross
>>
>> Right now, the only possibility is to generate Smalltalk code out of  
>> MSE code that represents your meta-model. This is like the famixCore  
>> string that you saw in the image.
>>
>> Cheers,
>> Doru
>>
>>
>> --
>> www.tudorgirba.com
>>
>> "Not knowing how to do something is not an argument for how it cannot  
>> be done."
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> --
>> Simon
>>
>>
>>
>>
>> --
>> Simon Denier
>>
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> Simon Denier
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--
www.tudorgirba.com

"Problem solving efficiency grows with the abstractness level of problem understanding."




_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Re: Moose for SAS

jfabry

+1 on that. Having selected e-mails as a reference/documentation on-line is much better than having to search the mailing lists.

On 07 Jun 2011, at 05:26, Tudor Girba wrote:

> Yes :)
>
> Doru
>
>
> On 7 Jun 2011, at 11:20, Simon Denier wrote:
>
>>
>> On 7 juin 2011, at 09:53, Nicolas Anquetil wrote:
>>
>>> I was discussing with Usman yesterday about these emails to the list that are also documentation artefacts.
>>>
>>> It would be nice to have a mean to flag such emails (manually) so that they can form collectively some documentation of Moose that would be easier to search in than the entire mailing list archive.
>>
>>
>> I think the simplest solution would be to copy-paste the email on the website, with just a bit of formatting. Is it ok?
>>
>>
>>>
>>> nicolas
>>>
>>> De: "Simon Denier" <[hidden email]>
>>> À: "Moose-related development" <[hidden email]>
>>> Envoyé: Mardi 7 Juin 2011 09:40:55
>>> Objet: [Moose-dev] Fwd:  Re: Moose for SAS
>>>
>>>
>>> There was some questions last week about extending the Famix metamodel. I just forward the following guide I wrote last year. It should be formatted and put online too.
>>>
>>>
>>> Begin forwarded message:
>>>
>>> From: Simon Denier <[hidden email]>
>>> Date: 24 juin 2010 18:21:34 HAEC
>>> To: Related to the development of Moose and other related tools <[hidden email]>
>>> Cc: Simon Denier <[hidden email]>
>>> Subject: Re: [Moose-dev] Re: Moose for SAS
>>>
>>> Hi Ross
>>>
>>>
>>> It's true that the metamodeling tools in Moose seem crude compared to what exist elsewhere, but that's because we spend much more time using metamodels in new tools than building metamodels :)
>>>
>>>
>>> Here is the procedure when you need to define a completely new metamodel. You can still make mistake when defining the metamodel but it eliminates most redundancy.
>>> Once you have defined your metamodel, a set of lint rules can be run to check some aspects of the metamodel (see below)
>>>
>>> The essential pragma documentation is here (should be integrated in the book)
>>> http://code.google.com/p/moose-technology/wiki/FameMetaDescriptions
>>>
>>> Also, a good rule of thumb is to have MooseEntity as root instead of Object, it facilitates integration with Moose tools.
>>>
>>>
>>> 1) Metamodel declaration
>>> For the example below:
>>> - Create class RPGDragon from a class browser
>>> - add (class-side)
>>> RPGDragon class>>annotation
>>> <MSEClass: #Dragon super: #Object>
>>> <package: #RPG>
>>>
>>> Notice I just define the method with pragmas, I don't add any code in the body for now.
>>>
>>> For each attribute, I need to define the accessor (the getter, not the setter):
>>> - define RPGDragon>>hoard
>>> <MSEProperty: #hoard type: #RPGTreasure opposite: #keeper><multivalued>
>>>
>>> (same thing, method decl + pragma, no code)
>>> No need to add the initialize, it will be defined by the generator.
>>>
>>>
>>> 2) To generate the implementation, do:
>>> MooseModel generateClassesFrom: {RPGDragon. RPGHero. RPGWall} "collection of classes defining the metamodel"
>>>
>>> It should open a preview window, where you can see which method will be defined/overridden by the generator. You can always tap Cmd-x to remove the selected definition (in case you are doing some incremental metamodel definition).
>>> You can repeat the generation step as much as you want, provided you understand it will overwrite existing methods.
>>>
>>> It works like a charm if you are doing your own metamodel. If you need to extend (as in class extension, not the Java extend for inheritance) some existing Famix classes with new attributes, you should be a bit more careful. Actually, when I need to extend an existing metamodel with a few attributes, I just define the attributes directly in the Smalltalk way (with pragmas AND method body). It's fast to do.
>>>
>>>
>>> 3) optionally, check that your metamodel is correct with lint rules (especially soundness of opposite relationships): can be done from the meta browser...
>>>
>>>
>>>
>>>
>>>
>>> On 16 juin 2010, at 22:36, Ross Boylan wrote:
>>>
>>> On Wed, 2010-06-16 at 22:14 +0200, Tudor Girba wrote:
>>> Hi Ross,
>>>
>>> On 16 Jun 2010, at 21:17, Ross Boylan wrote:
>>>
>>> On Wed, 2010-06-16 at 09:37 +0200, Tudor Girba wrote:
>>> As mentioned before, there is no support for graphical support for
>>> writing MSE files. The main reason here is that Smalltalk already
>>> provides a good enough solution for quickly building classes and
>>> methods, and annotating them is a practical solution.
>>> I gather there is no facility to generate the smalltalk out of the
>>> method annotations.  Is there any reason, in principle, that it  
>>> couldn't
>>> be done?
>>>
>>> Well, if you have the method annotations, you already have the  
>>> Smalltalk code :).
>>> Consider RPGDragon>>hoard
>>> <MSEProperty: #hoard type: #RPGTreasure opposite: #keeper>
>>> <multivalued>
>>> ^hoard
>>> ^hoard is smalltalk code.  You also have to create the instance
>>> variable, define
>>> hoard: aTreasure
>>> hoard value: aTreasure
>>> and
>>> initialize
>>> super initialize.
>>> hoard := FMMultivalueLink on: self opposite: #keeper:.
>>> killedBy := FMMultiMultivalueLink on: self opposite: #kills.
>>>
>>> It's the redundancy, along with the possibilities for error that would
>>> put the smalltalk and annotation out of sync, that concerns me (and that
>>> I'm trying to avoid).
>>>
>>> I do not in some other classes the names in the annotations and the
>>> names of the methods and variables are not quite in sync, so maybe this
>>> is a feature.
>>> Ross
>>>
>>> Right now, the only possibility is to generate Smalltalk code out of  
>>> MSE code that represents your meta-model. This is like the famixCore  
>>> string that you saw in the image.
>>>
>>> Cheers,
>>> Doru
>>>
>>>
>>> --
>>> www.tudorgirba.com
>>>
>>> "Not knowing how to do something is not an argument for how it cannot  
>>> be done."
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> [hidden email]
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> [hidden email]
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>> --
>>> Simon
>>>
>>>
>>>
>>>
>>> --
>>> Simon Denier
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> [hidden email]
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> [hidden email]
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> --
>> Simon Denier
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> www.tudorgirba.com
>
> "Problem solving efficiency grows with the abstractness level of problem understanding."
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--
Johan Fabry  
[hidden email] - http://dcc.uchile.cl/~jfabry
PLEIAD Lab - Computer Science Department (DCC) - University of Chile




_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Re: Moose for SAS

Ross Boylan
In reply to this post by simondenier
Just to update people on my SAS work: I got caught in a maze of twisty
passages with the SAS preprocessor and macro language, and solved my
immediate SAS needs by hand.

One alternative would be to parse a SAS log instead of the SAS code,
where the log is generated with SAS options like mprint to  print the
results of macro expansion (and some other options I don't recall for
printing code from included files).  This would replace the relatively
tricky task of getting the SAS preprocessor right with the more
straightforward one of extracting the expanded code from the log file.
However, it would require old code to be rerun, which might be a
problem.

Replicating the behavior of the SAS preprocessor is not an all or
nothing activity; there are various tricky cases that are relatively
unlikely to arise.

Ross

On Tue, 2011-06-07 at 09:40 +0200, Simon Denier wrote:

>
>
> There was some questions last week about extending the Famix
> metamodel. I just forward the following guide I wrote last year. It
> should be formatted and put online too.
>
>
> Begin forwarded message:
>
> > From: Simon Denier <[hidden email]>
> >
> > Date: 24 juin 2010 18:21:34 HAEC
> >
> > To: Related to the development of Moose and other related tools
> > <[hidden email]>
> >
> > Cc: Simon Denier <[hidden email]>
> >
> > Subject: Re: [Moose-dev] Re: Moose for SAS
> >
> >
> > Hi Ross
> >
> >
> > It's true that the metamodeling tools in Moose seem crude compared
> > to what exist elsewhere, but that's because we spend much more time
> > using metamodels in new tools than building metamodels :)
......
>

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Re: Moose for SAS

simondenier
In reply to this post by jfabry

I posted a first version here, which is possibly incomplete
http://www.moosetechnology.org/docs/famix/extendingFamix

It should also include
http://code.google.com/p/moose-technology/wiki/FameMetaDescriptions
- how to reset the metamodel
- how to run lint rules
- what are the lint rules for metamodel


On 7 juin 2011, at 16:18, Johan Fabry wrote:

>
> +1 on that. Having selected e-mails as a reference/documentation on-line is much better than having to search the mailing lists.
>
> On 07 Jun 2011, at 05:26, Tudor Girba wrote:
>
>> Yes :)
>>
>> Doru
>>
>>
>> On 7 Jun 2011, at 11:20, Simon Denier wrote:
>>
>>>
>>> On 7 juin 2011, at 09:53, Nicolas Anquetil wrote:
>>>
>>>> I was discussing with Usman yesterday about these emails to the list that are also documentation artefacts.
>>>>
>>>> It would be nice to have a mean to flag such emails (manually) so that they can form collectively some documentation of Moose that would be easier to search in than the entire mailing list archive.
>>>
>>>
>>> I think the simplest solution would be to copy-paste the email on the website, with just a bit of formatting. Is it ok?
>>>
>>>
>>>>
>>>> nicolas
>>>>
>>>> De: "Simon Denier" <[hidden email]>
>>>> À: "Moose-related development" <[hidden email]>
>>>> Envoyé: Mardi 7 Juin 2011 09:40:55
>>>> Objet: [Moose-dev] Fwd:  Re: Moose for SAS
>>>>
>>>>
>>>> There was some questions last week about extending the Famix metamodel. I just forward the following guide I wrote last year. It should be formatted and put online too.
>>>>
>>>>
>>>> Begin forwarded message:
>>>>
>>>> From: Simon Denier <[hidden email]>
>>>> Date: 24 juin 2010 18:21:34 HAEC
>>>> To: Related to the development of Moose and other related tools <[hidden email]>
>>>> Cc: Simon Denier <[hidden email]>
>>>> Subject: Re: [Moose-dev] Re: Moose for SAS
>>>>
>>>> Hi Ross
>>>>
>>>>
>>>> It's true that the metamodeling tools in Moose seem crude compared to what exist elsewhere, but that's because we spend much more time using metamodels in new tools than building metamodels :)
>>>>
>>>>
>>>> Here is the procedure when you need to define a completely new metamodel. You can still make mistake when defining the metamodel but it eliminates most redundancy.
>>>> Once you have defined your metamodel, a set of lint rules can be run to check some aspects of the metamodel (see below)
>>>>
>>>> The essential pragma documentation is here (should be integrated in the book)
>>>> http://code.google.com/p/moose-technology/wiki/FameMetaDescriptions
>>>>
>>>> Also, a good rule of thumb is to have MooseEntity as root instead of Object, it facilitates integration with Moose tools.
>>>>
>>>>
>>>> 1) Metamodel declaration
>>>> For the example below:
>>>> - Create class RPGDragon from a class browser
>>>> - add (class-side)
>>>> RPGDragon class>>annotation
>>>> <MSEClass: #Dragon super: #Object>
>>>> <package: #RPG>
>>>>
>>>> Notice I just define the method with pragmas, I don't add any code in the body for now.
>>>>
>>>> For each attribute, I need to define the accessor (the getter, not the setter):
>>>> - define RPGDragon>>hoard
>>>> <MSEProperty: #hoard type: #RPGTreasure opposite: #keeper><multivalued>
>>>>
>>>> (same thing, method decl + pragma, no code)
>>>> No need to add the initialize, it will be defined by the generator.
>>>>
>>>>
>>>> 2) To generate the implementation, do:
>>>> MooseModel generateClassesFrom: {RPGDragon. RPGHero. RPGWall} "collection of classes defining the metamodel"
>>>>
>>>> It should open a preview window, where you can see which method will be defined/overridden by the generator. You can always tap Cmd-x to remove the selected definition (in case you are doing some incremental metamodel definition).
>>>> You can repeat the generation step as much as you want, provided you understand it will overwrite existing methods.
>>>>
>>>> It works like a charm if you are doing your own metamodel. If you need to extend (as in class extension, not the Java extend for inheritance) some existing Famix classes with new attributes, you should be a bit more careful. Actually, when I need to extend an existing metamodel with a few attributes, I just define the attributes directly in the Smalltalk way (with pragmas AND method body). It's fast to do.
>>>>
>>>>
>>>> 3) optionally, check that your metamodel is correct with lint rules (especially soundness of opposite relationships): can be done from the meta browser...
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 16 juin 2010, at 22:36, Ross Boylan wrote:
>>>>
>>>> On Wed, 2010-06-16 at 22:14 +0200, Tudor Girba wrote:
>>>> Hi Ross,
>>>>
>>>> On 16 Jun 2010, at 21:17, Ross Boylan wrote:
>>>>
>>>> On Wed, 2010-06-16 at 09:37 +0200, Tudor Girba wrote:
>>>> As mentioned before, there is no support for graphical support for
>>>> writing MSE files. The main reason here is that Smalltalk already
>>>> provides a good enough solution for quickly building classes and
>>>> methods, and annotating them is a practical solution.
>>>> I gather there is no facility to generate the smalltalk out of the
>>>> method annotations.  Is there any reason, in principle, that it  
>>>> couldn't
>>>> be done?
>>>>
>>>> Well, if you have the method annotations, you already have the  
>>>> Smalltalk code :).
>>>> Consider RPGDragon>>hoard
>>>> <MSEProperty: #hoard type: #RPGTreasure opposite: #keeper>
>>>> <multivalued>
>>>> ^hoard
>>>> ^hoard is smalltalk code.  You also have to create the instance
>>>> variable, define
>>>> hoard: aTreasure
>>>> hoard value: aTreasure
>>>> and
>>>> initialize
>>>> super initialize.
>>>> hoard := FMMultivalueLink on: self opposite: #keeper:.
>>>> killedBy := FMMultiMultivalueLink on: self opposite: #kills.
>>>>
>>>> It's the redundancy, along with the possibilities for error that would
>>>> put the smalltalk and annotation out of sync, that concerns me (and that
>>>> I'm trying to avoid).
>>>>
>>>> I do not in some other classes the names in the annotations and the
>>>> names of the methods and variables are not quite in sync, so maybe this
>>>> is a feature.
>>>> Ross
>>>>
>>>> Right now, the only possibility is to generate Smalltalk code out of  
>>>> MSE code that represents your meta-model. This is like the famixCore  
>>>> string that you saw in the image.
>>>>
>>>> Cheers,
>>>> Doru
>>>>
>>>>
>>>> --
>>>> www.tudorgirba.com
>>>>
>>>> "Not knowing how to do something is not an argument for how it cannot  
>>>> be done."
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> [hidden email]
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> [hidden email]
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>
>>>> --
>>>> Simon
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Simon Denier
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> [hidden email]
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> [hidden email]
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>> --
>>> Simon Denier
>>>
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> [hidden email]
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> --
>> www.tudorgirba.com
>>
>> "Problem solving efficiency grows with the abstractness level of problem understanding."
>>
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> Johan Fabry  
> [hidden email] - http://dcc.uchile.cl/~jfabry
> PLEIAD Lab - Computer Science Department (DCC) - University of Chile
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--
Simon Denier




_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev