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