Parse VisualAge Smalltalk st files (or app as they are called)

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

Re: Parse VisualAge Smalltalk st files (or app as they are called)

cbc
On Wed, Feb 27, 2013 at 6:26 AM, Fabrizio Perin <[hidden email]> wrote:
>> - The visiting of method ASTs happens in the SmalltalkMethodVisitor which is triggered by SmalltalkImporter>>createMethod:. It is this visitor which is the responsible for triggering the creation of low-level objects like invocations and accesses.
>
> Yes.
 
The SmalltalkImporter>>createMethod: need as parameter acompiledMethod which is evidently a MethodNode since RBMethodNode do not implement the methodClass which is invoked in createMethod:
 
So, am I missing something? Should I use another parser other than PPSmalltalkParser?

I think SmalltalkImporter is coded to pull the code directly out of Pharo/Moose - that is, Smalltalk code already in the image, so it uses MethodNode.  Since you are not actually loading it into Moose in a runable format, but instead parsing it, you don't have MethodNode.

I think you should extend RBMethodNode with the methods that are needed to satisfy SmalltalkImporter - this will make future handling of other Smalltalk sources much nicer.

-Chris

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

Re: Parse VisualAge Smalltalk st files (or app as they are called)

stephane ducasse
In reply to this post by Fabrizio Perin-3

On Feb 21, 2013, at 9:42 AM, Fabrizio Perin <[hidden email]> wrote:

> Hi,
> thanks for the responses. I think I will go for the second option
> proposed by Doru but first I would like to check this Rossetta stuff
> which supports VA to squeak export.
>
> The only think that make me scheptical is that the VA Smalltalk have
> concepts that are not in squeak. i.e. in VA you can have private
> methods and there is this concept of application. So I don't know if
> the RB AST is expressive enough and, most of all, if the importer will
> actually import this kind of info.

for private or public methods (I do not know how they inforce it)
        can you invoke a private method
                Object new privateMethod?
       
for the model in a first cut I would model it as a method and add the modifier (as property if this is not in FMMethod but it should be
because you can do it in Java).
               
map an application to a package.


>
> Let you know how it goes.
>
> Cheers,
> Fabrizio
>
> 2013/2/20 Chris Cunningham <[hidden email]>:
>> Hi.
>>
>> On Wed, Feb 20, 2013 at 4:01 AM, Fabrizio Perin <[hidden email]>
>> wrote:
>> <snip>
>>>
>>> - Should I customize the PPSmalltalkParser or should I start a parser
>>> from scratch?
>>> - Did anybody tried to import in moose a smalltalk dilect different
>>> from pharo? If yes how did he do that?
>>>
>>> I just want to understand if I can save time or I should build a whole
>>> parser and importer from scratch.
>>
>>
>> I've done similar work (except from VSE Smalltalk).  My path was to use port
>> the code to moose first, then work with it in the image.  The tool I use
>> doesn't appear to be readily available anymore, but there are other options,
>> such as:
>>
>> http://rosettast.sourceforge.net/
>> (this that might support VisualAge to Moose already)
>>
>> https://github.com/CampSmalltalk/Cypress
>> (those doesn't appear to currently support VisualAge to Moose, but has been
>> active recently)
>>
>> I have not used either of these, though.
>>
>> Enjoy,
>> Chris
>>
>> _______________________________________________
>> 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


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

Re: Parse VisualAge Smalltalk st files (or app as they are called)

stephane ducasse
In reply to this post by Fabrizio Perin-3

On Feb 27, 2013, at 9:59 PM, Fabrizio Perin <[hidden email]> wrote:

Hi Doru,
probably I got confused. You wrote:
- The visiting of method ASTs happens in the SmalltalkMethodVisitor which is triggered by SmalltalkImporter>>
createMethod:. It is this visitor which is the responsible for triggering the creation of low-level objects like invocations and accesses.

I though that the SmalltalkImporter was used to instantiate a famix model out of a RB infrastructure but probably there is something missing. I have in output from my parser  RBMethodNodes and RBClasses (plus other stuff) but I cannot make the SmalltalkImporter running on them. Either I did not instantiate properly the RBMethods or there is something else.

You can probably add a new method createMethodFromNode: that takes an ast and not a compiledmethod as input.


Anyway the output of my parser is a list of nodes that are independent from one another, i.e. a RBMethod node is not into a RBClass node. It might be that the problem. I will investigate tomorrow.

Cheers,
Fabrizio



2013/2/27 Tudor Girba <[hidden email]>
Hi Fabrizio,

I think I do not understand the question.

SmalltalkImporter>>createMethod: takes a compiled method, and then uses the RB infrastructure to build the AST. In your case, you will probably have to use your parser for the method, obtain the AST and traverse that one with a visitor.

Cheers,
Doru



On Feb 27, 2013, at 3:26 PM, Fabrizio Perin <[hidden email]> wrote:

> >> - The visiting of method ASTs happens in the SmalltalkMethodVisitor which is triggered by SmalltalkImporter>>createMethod:. It is this visitor which is the responsible for triggering the creation of low-level objects like invocations and accesses.
> >
> > Yes.
>
> The SmalltalkImporter>>createMethod: need as parameter acompiledMethod which is evidently a MethodNode since RBMethodNode do not implement the methodClass which is invoked in createMethod:
>
> So, am I missing something? Should I use another parser other than PPSmalltalkParser?
>
> Cheers,
> Fabrizio
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--
www.tudorgirba.com

"Some battles are better lost than fought."




_______________________________________________
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


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

Re: Parse VisualAge Smalltalk st files (or app as they are called)

stephane ducasse
In reply to this post by cbc

 
The SmalltalkImporter>>createMethod: need as parameter acompiledMethod which is evidently a MethodNode since RBMethodNode do not implement the methodClass which is invoked in createMethod:
 
So, am I missing something? Should I use another parser other than PPSmalltalkParser?

I think SmalltalkImporter is coded to pull the code directly out of Pharo/Moose - that is, Smalltalk code already in the image, so it uses MethodNode.  Since you are not actually loading it into Moose in a runable format, but instead parsing it, you don't have MethodNode.

I think you should extend RBMethodNode with the methods that are needed to satisfy SmalltalkImporter - this will make future handling of other Smalltalk sources much nicer.

yes if someone publish code I will have a look and see how we can integrate it.


-Chris
_______________________________________________
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: Parse VisualAge Smalltalk st files (or app as they are called)

stephane ducasse
In reply to this post by Fabrizio Perin-3
Fabrizio 

the importing context is an object that implements a coherent view on an extracted model.
The idea is that you should not import accesses if you do not import variable.
So the importing context manages such dependencies and the user just 
configures the importing context and the importer will follow the dependencies graph represented by the importing context.

The importer always ask
shouldIImport…. to the importingContext.

Stef



On Feb 27, 2013, at 2:15 PM, Fabrizio Perin <[hidden email]> wrote:

Another question: what about the importing context?
 
I tried something basic like:
 
stImpo := SmalltalkImporter targetModel: self targetModel.
stImpo createClass: aRBClassNode.
 
and a MNU rised because importingContext is nil:
 
createClass: aClass
 | class inheritance |
 
 importingContext shouldMergeClassAndMetaclass
.....
 
now I will try with the method parser.
 
Cheers,
Fabrizio
 
 
2013/2/27 Fabrizio Perin <[hidden email]>
I believe the code will be opensource but I have to sinch with my boss.
 
Cheers,
Fabrizio

2013/2/27 Fabrizio Perin <[hidden email]>
About the importer I will give a try to the SmalltalkImporter. Anyway my main concern is not to create the structure of the smalltalk application (since the app file is really linear you always have the parent of a node at hand), but the part where I have to campute method invocations and accesses. Is that second part somehow there already?
 
Let you know how it goes with the importer.
 
Thanks and cheers,
Fabrizio
 


_______________________________________________
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: Parse VisualAge Smalltalk st files (or app as they are called)

Fabrizio Perin-3
Hi,
I tried to use SmalltalkMethodVisitor and it is pretty unusable: as soon as you put in the importing context something more fancy than #LocalVariable, for example, #Invocations, the importer uses the method SmalltalkMethodVisitor>>resolve: to identify the invoked entity. This method at certain point execute

self methodEntity smalltalkClass theNonMetaClass.

from that invocation you end up looking into the Pharo image for the entity with that name.

Do you think would be easy to made the import of smalltalk independent from the pharo image?

Cheers,
Fabrizio


2013/2/28 stephane ducasse <[hidden email]>
Fabrizio 

the importing context is an object that implements a coherent view on an extracted model.
The idea is that you should not import accesses if you do not import variable.
So the importing context manages such dependencies and the user just 
configures the importing context and the importer will follow the dependencies graph represented by the importing context.

The importer always ask
shouldIImport…. to the importingContext.

Stef



On Feb 27, 2013, at 2:15 PM, Fabrizio Perin <[hidden email]> wrote:

Another question: what about the importing context?
 
I tried something basic like:
 
stImpo := SmalltalkImporter targetModel: self targetModel.
stImpo createClass: aRBClassNode.
 
and a MNU rised because importingContext is nil:
 
createClass: aClass
 | class inheritance |
 
 importingContext shouldMergeClassAndMetaclass
.....
 
now I will try with the method parser.
 
Cheers,
Fabrizio
 
 
2013/2/27 Fabrizio Perin <[hidden email]>
I believe the code will be opensource but I have to sinch with my boss.
 
Cheers,
Fabrizio

2013/2/27 Fabrizio Perin <[hidden email]>
About the importer I will give a try to the SmalltalkImporter. Anyway my main concern is not to create the structure of the smalltalk application (since the app file is really linear you always have the parent of a node at hand), but the part where I have to campute method invocations and accesses. Is that second part somehow there already?
 
Let you know how it goes with the importer.
 
Thanks and cheers,
Fabrizio
 


_______________________________________________
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



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

Re: Parse VisualAge Smalltalk st files (or app as they are called)

stephane ducasse

On Mar 4, 2013, at 4:49 PM, Fabrizio Perin <[hidden email]> wrote:

Hi,
I tried to use SmalltalkMethodVisitor and it is pretty unusable: as soon as you put in the importing context something more fancy than #LocalVariable, for example, #Invocations, the importer uses the method SmalltalkMethodVisitor>>resolve: to identify the invoked entity. This method at certain point execute

self methodEntity smalltalkClass theNonMetaClass.

from that invocation you end up looking into the Pharo image for the entity with that name.

Do you think would be easy to made the import of smalltalk independent from the pharo image?


Did you try to map your VA imported methods instance of RingMethod and RIngClass
because normally ring class are polymorph with Pharo objects representing classes and methods.
So 

self methodEntity
should be a FAMIXMethod
SmalltalkClass would return a ringVAInstance 
Stef


Cheers,
Fabrizio


2013/2/28 stephane ducasse <[hidden email]>
Fabrizio 

the importing context is an object that implements a coherent view on an extracted model.
The idea is that you should not import accesses if you do not import variable.
So the importing context manages such dependencies and the user just 
configures the importing context and the importer will follow the dependencies graph represented by the importing context.

The importer always ask
shouldIImport…. to the importingContext.

Stef



On Feb 27, 2013, at 2:15 PM, Fabrizio Perin <[hidden email]> wrote:

Another question: what about the importing context?
 
I tried something basic like:
 
stImpo := SmalltalkImporter targetModel: self targetModel.
stImpo createClass: aRBClassNode.
 
and a MNU rised because importingContext is nil:
 
createClass: aClass
 | class inheritance |
 
 importingContext shouldMergeClassAndMetaclass
.....
 
now I will try with the method parser.
 
Cheers,
Fabrizio
 
 
2013/2/27 Fabrizio Perin <[hidden email]>
I believe the code will be opensource but I have to sinch with my boss.
 
Cheers,
Fabrizio

2013/2/27 Fabrizio Perin <[hidden email]>
About the importer I will give a try to the SmalltalkImporter. Anyway my main concern is not to create the structure of the smalltalk application (since the app file is really linear you always have the parent of a node at hand), but the part where I have to campute method invocations and accesses. Is that second part somehow there already?
 
Let you know how it goes with the importer.
 
Thanks and cheers,
Fabrizio
 


_______________________________________________
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


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