On Wed, Feb 27, 2013 at 6:26 AM, Fabrizio Perin <[hidden email]> wrote:
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 |
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 |
In reply to this post by Fabrizio Perin-3
On Feb 27, 2013, at 9:59 PM, Fabrizio Perin <[hidden email]> wrote:
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
In reply to this post by cbc
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
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:
_______________________________________________ Moose-dev mailing list [hidden email] 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 <[hidden email]>
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
On Mar 4, 2013, at 4:49 PM, Fabrizio Perin <[hidden email]> wrote:
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
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Free forum by Nabble | Edit this page |