Hi, I would like to create a Moose model of a VisualAge smalltalk application. I tried to fileout a bunch of applications (which are groups of packages as far as I understood) and the result file .app has naturally a different syntax from pharo st files. Now, the questions are:
- 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.
Thanks for any suggestion or information.
Cheers, Fabriyio (bloodz german kezboard)
Hi Fabrizio,
I think you have two strategies:
1. Build the importer in VA and export MSE This is way we are dealing with VW: use the importer in VW and export the MSE file. This was because we already had the importer and FAMIX in VW.
2. Build a dedicated Parser and importer As you suggested, you could build a parser. I guess that the syntax is not (much) different. In this case, I would build a surrounding parser that deals with the specifics of the .st file and uses PPSmalltalkParser for the actual method parsing. Given that the Pharo importer already uses the RB AST, perhaps you can directly make the parser to instantiate RB AST nodes.
I would rather favor the second option. If we go in this direction, we could also make it so that the Smalltalk importing infrastructure is flexible enough to only require different parsers.
Cheers, Doru
On Wed, Feb 20, 2013 at 1:01 PM, Fabrizio Perin fabrizio.perin@gmail.comwrote:
Hi, I would like to create a Moose model of a VisualAge smalltalk application. I tried to fileout a bunch of applications (which are groups of packages as far as I understood) and the result file .app has naturally a different syntax from pharo st files. Now, the questions are:
- 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.
Thanks for any suggestion or information.
Cheers, Fabriyio (bloodz german kezboard) _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On Feb 20, 2013, at 1:17 PM, Tudor Girba tudor@tudorgirba.com wrote:
Hi Fabrizio,
I think you have two strategies:
- Build the importer in VA and export MSE
This is way we are dealing with VW: use the importer in VW and export the MSE file. This was because we already had the importer and FAMIX in VW.
- Build a dedicated Parser and importer
As you suggested, you could build a parser. I guess that the syntax is not (much) different. In this case, I would build a surrounding parser that deals with the specifics of the .st file and uses PPSmalltalkParser for the actual method parsing. Given that the Pharo importer already uses the RB AST, perhaps you can directly make the parser to instantiate RB AST nodes.
I would rather favor the second option. If we go in this direction, we could also make it so that the Smalltalk importing infrastructure is flexible enough to only require different parsers.
+1 for option 2
Hi.
On Wed, Feb 20, 2013 at 4:01 AM, Fabrizio Perin fabrizio.perin@gmail.comwrote: <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
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.
Let you know how it goes.
Cheers, Fabrizio
2013/2/20 Chris Cunningham cunningham.cb@gmail.com:
Hi.
On Wed, Feb 20, 2013 at 4:01 AM, Fabrizio Perin fabrizio.perin@gmail.com 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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi again, I'm developing a parser for VA .app files and .st files. I'm using PPSmalltalkParsers to parse smalltalk methods but I need to enrich these objects with more information so I specialized RBMethodNode to add the info I need. The question is now, what about the importer? Is there any I can reuse that compute already method invocations and accesses or I should write a brand new one?
Cheers, Fabrizio
2013/2/21 Fabrizio Perin fabrizio.perin@gmail.com:
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.
Let you know how it goes.
Cheers, Fabrizio
2013/2/20 Chris Cunningham cunningham.cb@gmail.com:
Hi.
On Wed, Feb 20, 2013 at 4:01 AM, Fabrizio Perin fabrizio.perin@gmail.com 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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi Fabrizio,
Great.
The Importer has two parts: - The SmalltalkImporter deals with all classes. It has these create* and ensure* methods to deal with creating the actual entities. For this to work, it needs a Pharo model. For example, in createClass, you ensure the associated package, but this is based on the RPackage model. - 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.
As I see it, you would probably benefit from subclassing both of these classes to deal with your input model and ASTs. In the future, perhaps we can generalize a bit the infrastructure to handle your case without dirty overrides.
Btw, would your code be open source?
Cheers, Doru
On Feb 23, 2013, at 10:57 AM, Fabrizio Perin fabrizio.perin@gmail.com wrote:
Hi again, I'm developing a parser for VA .app files and .st files. I'm using PPSmalltalkParsers to parse smalltalk methods but I need to enrich these objects with more information so I specialized RBMethodNode to add the info I need. The question is now, what about the importer? Is there any I can reuse that compute already method invocations and accesses or I should write a brand new one?
Cheers, Fabrizio
2013/2/21 Fabrizio Perin fabrizio.perin@gmail.com:
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.
Let you know how it goes.
Cheers, Fabrizio
2013/2/20 Chris Cunningham cunningham.cb@gmail.com:
Hi.
On Wed, Feb 20, 2013 at 4:01 AM, Fabrizio Perin fabrizio.perin@gmail.com 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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"It's not what we do that matters most, it's how we do it."
Hi Fabrizio,
Great.
The Importer has two parts:
- The SmalltalkImporter deals with all classes. It has these create* and ensure* methods to deal with creating the actual entities. For this to work, it needs a Pharo model. For example, in createClass, you ensure the associated package, but this is based on the RPackage model.
ensure* methods make sure that you do not create twice the same entity so you should use them each time you want to create an entity. I guess that you mean a Moose model.
- 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.
As I see it, you would probably benefit from subclassing both of these classes to deal with your input model and ASTs.
Yes but what is so different in VA Smalltalk code? Because the AST should be nearly the same. Fabrizio did you encounter the static array or something like that in VA because we could have simply a Node to handle such case.
In the future, perhaps we can generalize a bit the infrastructure to handle your case without dirty overrides.
What are the methods that should be overriden? Because yes providing hooks would be good.
Btw, would your code be open source?
I hope :)
Stef
Cheers, Doru
On Feb 23, 2013, at 10:57 AM, Fabrizio Perin fabrizio.perin@gmail.com wrote:
Hi again, I'm developing a parser for VA .app files and .st files. I'm using PPSmalltalkParsers to parse smalltalk methods but I need to enrich these objects with more information so I specialized RBMethodNode to add the info I need. The question is now, what about the importer? Is there any I can reuse that compute already method invocations and accesses or I should write a brand new one?
Cheers, Fabrizio
2013/2/21 Fabrizio Perin fabrizio.perin@gmail.com:
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.
Let you know how it goes.
Cheers, Fabrizio
2013/2/20 Chris Cunningham cunningham.cb@gmail.com:
Hi.
On Wed, Feb 20, 2013 at 4:01 AM, Fabrizio Perin fabrizio.perin@gmail.com 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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"It's not what we do that matters most, it's how we do it."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi Stef,
On Feb 26, 2013, at 9:29 PM, stephane ducasse stephane.ducasse@free.fr wrote:
Hi Fabrizio,
Great.
The Importer has two parts:
- The SmalltalkImporter deals with all classes. It has these create* and ensure* methods to deal with creating the actual entities. For this to work, it needs a Pharo model. For example, in createClass, you ensure the associated package, but this is based on the RPackage model.
ensure* methods make sure that you do not create twice the same entity so you should use them each time you want to create an entity. I guess that you mean a Moose model.
I know what ensure* does, and I do mean the RPackage model :). I was referring to what the ensureClass relies on. And asking a class for its package relies at this moment on the RPackage model.
- 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.
As I see it, you would probably benefit from subclassing both of these classes to deal with your input model and ASTs.
Yes but what is so different in VA Smalltalk code? Because the AST should be nearly the same. Fabrizio did you encounter the static array or something like that in VA because we could have simply a Node to handle such case.
Indeed, it would be nice to know what the difference is.
In the future, perhaps we can generalize a bit the infrastructure to handle your case without dirty overrides.
What are the methods that should be overriden? Because yes providing hooks would be good.
Btw, would your code be open source?
I hope :)
:)
Doru
Stef
Cheers, Doru
On Feb 23, 2013, at 10:57 AM, Fabrizio Perin fabrizio.perin@gmail.com wrote:
Hi again, I'm developing a parser for VA .app files and .st files. I'm using PPSmalltalkParsers to parse smalltalk methods but I need to enrich these objects with more information so I specialized RBMethodNode to add the info I need. The question is now, what about the importer? Is there any I can reuse that compute already method invocations and accesses or I should write a brand new one?
Cheers, Fabrizio
2013/2/21 Fabrizio Perin fabrizio.perin@gmail.com:
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.
Let you know how it goes.
Cheers, Fabrizio
2013/2/20 Chris Cunningham cunningham.cb@gmail.com:
Hi.
On Wed, Feb 20, 2013 at 4:01 AM, Fabrizio Perin fabrizio.perin@gmail.com 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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"It's not what we do that matters most, it's how we do it."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Obvious things are difficult to teach."
I know what ensure* does,
Yes I know you know I was talking to fabrizio
and I do mean the RPackage model :).
Ok I see what you mean. So what you implied is that fabrizio may be should create package for his code.
I was referring to what the ensureClass relies on. And asking a class for its package relies at this moment on the RPackage model.
- 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.
As I see it, you would probably benefit from subclassing both of these classes to deal with your input model and ASTs.
Yes but what is so different in VA Smalltalk code? Because the AST should be nearly the same. Fabrizio did you encounter the static array or something like that in VA because we could have simply a Node to handle such case.
Indeed, it would be nice to know what the difference is.
In the future, perhaps we can generalize a bit the infrastructure to handle your case without dirty overrides.
What are the methods that should be overriden? Because yes providing hooks would be good.
Btw, would your code be open source?
I hope :)
:)
Doru
Stef
Cheers, Doru
On Feb 23, 2013, at 10:57 AM, Fabrizio Perin fabrizio.perin@gmail.com wrote:
Hi again, I'm developing a parser for VA .app files and .st files. I'm using PPSmalltalkParsers to parse smalltalk methods but I need to enrich these objects with more information so I specialized RBMethodNode to add the info I need. The question is now, what about the importer? Is there any I can reuse that compute already method invocations and accesses or I should write a brand new one?
Cheers, Fabrizio
2013/2/21 Fabrizio Perin fabrizio.perin@gmail.com:
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.
Let you know how it goes.
Cheers, Fabrizio
2013/2/20 Chris Cunningham cunningham.cb@gmail.com:
Hi.
On Wed, Feb 20, 2013 at 4:01 AM, Fabrizio Perin fabrizio.perin@gmail.com 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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"It's not what we do that matters most, it's how we do it."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Obvious things are difficult to teach."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Yes but what is so different in VA Smalltalk code?
Well, so far I saw that:
- methods can be private or public (eventhough I think at the end they all have a public scope) - there are 4 different ways to define classes: e.g.: String *variableByteSubclass:* #MyString classVariableNames: '' poolDictionaries: '' (and instanceVariableNames: is missing)
or:
AClass *variableSubclass:* #AnotherClass instanceVariableNames: '' classVariableNames: '' poolDictionaries: ''
- another think I never saw and was not part of the parse for methods was the pool dictionary access (but this should be the same in pharo I think): Class::AnotherClass!!variable for this I had to subclass the method parser - another think I never saw but it might be the static array stuff you mentioned is: mapAspect: aString | map | map := *##*(Dictionary new at: 'Numberblabla' put: blablabla; at: 'BLABLABLA' put: MyConstants::ContantClass; yourself ). ^map at: aString
To parse this I added a unary operator ## followed by an expression. - There is class extension not package extension - There are no packages or categories only applications(which are like packages): an application contains classes, can depend from other applications and can be use in class extension (so you say to a class that it is extended by a certain application). From the the point of view of the class you see the application that extend the class and from an application point of view you see the extended classes.
So far this what was new from VA.
When you file out an application (or a set of them) you get a file.app. The syntax of this file is very similar to the st one but of course you need to consider most od the peculiaritis I wrote before (e.g. variableSubclass: etc.).
The parser for the app file btw is done (pretty much). I extended some elements of RB like RBMethod and RBClass and I had to add other AST node for elements that are not present normaly in st file like for example class context switch line: (!MyClass class publicMethods !) after which there are all class side public methods of MyClass and stuff like that.
Cheers, Fabrizio
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
I believe the code will be opensource but I have to sinch with my boss.
Cheers, Fabrizio
2013/2/27 Fabrizio Perin fabrizio.perin@gmail.com
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
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 fabrizio.perin@gmail.com
I believe the code will be opensource but I have to sinch with my boss.
Cheers, Fabrizio
2013/2/27 Fabrizio Perin fabrizio.perin@gmail.com
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
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 fabrizio.perin@gmail.com 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 fabrizio.perin@gmail.com I believe the code will be opensource but I have to sinch with my boss.
Cheers, Fabrizio
2013/2/27 Fabrizio Perin fabrizio.perin@gmail.com 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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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 stephane.ducasse@free.fr
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 fabrizio.perin@gmail.com 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 fabrizio.perin@gmail.com
I believe the code will be opensource but I have to sinch with my boss.
Cheers, Fabrizio
2013/2/27 Fabrizio Perin fabrizio.perin@gmail.com
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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On Mar 4, 2013, at 4:49 PM, Fabrizio Perin fabrizio.perin@gmail.com 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 stephane.ducasse@free.fr 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 fabrizio.perin@gmail.com 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 fabrizio.perin@gmail.com I believe the code will be opensource but I have to sinch with my boss.
Cheers, Fabrizio
2013/2/27 Fabrizio Perin fabrizio.perin@gmail.com 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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
- 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
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 fabrizio.perin@gmail.com 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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Some battles are better lost than fought."
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.
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 tudor@tudorgirba.com
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 fabrizio.perin@gmail.com 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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Some battles are better lost than fought."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi,
SmalltalkImporter gets as input a collection of classes. Based on these class objects, it creates the structural entities up to the level of methods. To build the entities that reside at the level of method bodies, The SmalltalkMethodVisitor is used and this traverses the RB AST. The RB AST is only used in the SmalltalkMethodVisitor.
But, if you want to get more details, you could: - put a self halt in createMethod: - run LANImporterTest>>testClassName - and then step through the execution :)
Cheers, Doru
On Feb 27, 2013, at 9:59 PM, Fabrizio Perin fabrizio.perin@gmail.com 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.
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 tudor@tudorgirba.com 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 fabrizio.perin@gmail.com 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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Some battles are better lost than fought."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"We can create beautiful models in a vacuum. But, to get them effective we have to deal with the inconvenience of reality."
On Feb 27, 2013, at 9:59 PM, Fabrizio Perin fabrizio.perin@gmail.com 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 tudor@tudorgirba.com 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 fabrizio.perin@gmail.com 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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Some battles are better lost than fought."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On Wed, Feb 27, 2013 at 6:26 AM, Fabrizio Perin fabrizio.perin@gmail.comwrote:
- 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
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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Sorry Doru I read more carefully this email and I found all the answers for my previous questions. I think I need coffee :)
If some more meaningful question will rise I will let you know.
Cheers, Fabrizio
2013/2/25 Tudor Girba tudor@tudorgirba.com
Hi Fabrizio,
Great.
The Importer has two parts:
- The SmalltalkImporter deals with all classes. It has these create* and
ensure* methods to deal with creating the actual entities. For this to work, it needs a Pharo model. For example, in createClass, you ensure the associated package, but this is based on the RPackage model.
- 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.
As I see it, you would probably benefit from subclassing both of these classes to deal with your input model and ASTs. In the future, perhaps we can generalize a bit the infrastructure to handle your case without dirty overrides.
Btw, would your code be open source?
Cheers, Doru
On Feb 23, 2013, at 10:57 AM, Fabrizio Perin fabrizio.perin@gmail.com wrote:
Hi again, I'm developing a parser for VA .app files and .st files. I'm using PPSmalltalkParsers to parse smalltalk methods but I need to enrich these objects with more information so I specialized RBMethodNode to add the info I need. The question is now, what about the importer? Is there any I can reuse that compute already method invocations and accesses or I should write a brand new one?
Cheers, Fabrizio
2013/2/21 Fabrizio Perin fabrizio.perin@gmail.com:
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.
Let you know how it goes.
Cheers, Fabrizio
2013/2/20 Chris Cunningham cunningham.cb@gmail.com:
Hi.
On Wed, Feb 20, 2013 at 4:01 AM, Fabrizio Perin <
fabrizio.perin@gmail.com>
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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"It's not what we do that matters most, it's how we do it."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On Feb 23, 2013, at 10:57 AM, Fabrizio Perin fabrizio.perin@gmail.com wrote:
Hi again, I'm developing a parser for VA .app files and .st files. I'm using PPSmalltalkParsers to parse smalltalk methods but I need to enrich these objects with more information so I specialized RBMethodNode to add the info I need. The question is now, what about the importer? Is there any I can reuse that compute already method invocations and accesses or I should write a brand new one?
the importer works breadfirst and you only use the node visitor if you say it (want to extract information about method body) now I do not see why you could not reuse the importer because if you create the same node it should work. If you subclass a node then it should probably work too.
Cheers, Fabrizio
2013/2/21 Fabrizio Perin fabrizio.perin@gmail.com:
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.
Let you know how it goes.
Cheers, Fabrizio
2013/2/20 Chris Cunningham cunningham.cb@gmail.com:
Hi.
On Wed, Feb 20, 2013 at 4:01 AM, Fabrizio Perin fabrizio.perin@gmail.com 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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On Feb 21, 2013, at 9:42 AM, Fabrizio Perin fabrizio.perin@gmail.com 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 cunningham.cb@gmail.com:
Hi.
On Wed, Feb 20, 2013 at 4:01 AM, Fabrizio Perin fabrizio.perin@gmail.com 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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-
Chris Cunningham -
Fabrizio Perin -
stephane ducasse -
Stéphane Ducasse -
Tudor Girba