20 Feb
2013
20 Feb
'13
1:01 p.m.
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)
20 Feb
20 Feb
1:17 p.m.
New subject: Parse VisualAge Smalltalk st files (or app as they are called)
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(a)gmail.com>wrote;wrote:
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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Every thing has its own flow"
26 Feb
26 Feb
9:20 p.m.
New subject: Parse VisualAge Smalltalk st files (or app as they are called)
On Feb 20, 2013, at 1:17 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote:
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.
+1 for option 2
20 Feb
20 Feb
5:41 p.m.
New subject: Parse VisualAge Smalltalk st files (or app as they are called)
Hi.
On Wed, Feb 20, 2013 at 4:01 AM, Fabrizio Perin <fabrizio.perin(a)gmail.com>wrote;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
21 Feb
21 Feb
9:42 a.m.
New subject: Parse VisualAge Smalltalk st files (or app as they are called)
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(a)gmail.com>om>:
Hi.
On Wed, Feb 20, 2013 at 4:01 AM, Fabrizio Perin <fabrizio.perin(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
23 Feb
23 Feb
10:57 a.m.
New subject: Parse VisualAge Smalltalk st files (or app as they are called)
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(a)gmail.com>om>:
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(a)gmail.com>om>:
> Hi.
>
> On Wed, Feb 20, 2013 at 4:01 AM, Fabrizio Perin <fabrizio.perin(a)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(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
25 Feb
25 Feb
8:22 a.m.
New subject: Parse VisualAge Smalltalk st files (or app as they are called)
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(a)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(a)gmail.com>om>:
--
www.tudorgirba.com
"It's not what we do that matters most, it's how we do it."
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(a)gmail.com>om>:
> Hi.
>
> On Wed, Feb 20, 2013 at 4:01 AM, Fabrizio Perin <fabrizio.perin(a)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(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 
26 Feb
26 Feb
9:29 p.m.
New subject: Parse VisualAge Smalltalk st files (or app as they are called)
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(a)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(a)gmail.com>om>:
--
www.tudorgirba.com
"It's not what we do that matters most, it's how we do it."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 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(a)gmail.com>om>:
> Hi.
>
> On Wed, Feb 20, 2013 at 4:01 AM, Fabrizio Perin <fabrizio.perin(a)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(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
9:40 p.m.
New subject: Parse VisualAge Smalltalk st files (or app as they are called)
Hi Stef,
On Feb 26, 2013, at 9:29 PM, stephane ducasse <stephane.ducasse(a)free.fr> wrote:
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.
Indeed, it would be nice to know what the difference is.
:)
Doru
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
--
www.tudorgirba.com
"Obvious things are difficult to teach."
Cheers,
Doru
On Feb 23, 2013, at 10:57 AM, Fabrizio Perin <fabrizio.perin(a)gmail.com> wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)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(a)gmail.com>om>:
--
www.tudorgirba.com
"It's not what we do that matters most, it's how we do it."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 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(a)gmail.com>om>:
> Hi.
>
> On Wed, Feb 20, 2013 at 4:01 AM, Fabrizio Perin <fabrizio.perin(a)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(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
10:05 p.m.
New subject: Parse VisualAge Smalltalk st files (or app as they are called)
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.
Indeed, it would be nice to know what the difference is.
:)
Doru
- 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
--
www.tudorgirba.com
"Obvious things are difficult to teach."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Cheers,
Doru
On Feb 23, 2013, at 10:57 AM, Fabrizio Perin <fabrizio.perin(a)gmail.com> wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)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(a)gmail.com>om>:
> 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(a)gmail.com>om>:
>> Hi.
>>
>> On Wed, Feb 20, 2013 at 4:01 AM, Fabrizio Perin <fabrizio.perin(a)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(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
_______________________________________________
Moose-dev mailing list
Moose-dev(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
27 Feb
27 Feb
1:49 p.m.
New subject: Parse VisualAge Smalltalk st files (or app as they are called)
> 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
1:55 p.m.
New subject: Parse VisualAge Smalltalk st files (or app as they are called)
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
1:56 p.m.
New subject: Parse VisualAge Smalltalk st files (or app as they are called)
I believe the code will be opensource but I have to sinch with my boss.
Cheers,
Fabrizio
2013/2/27 Fabrizio Perin <fabrizio.perin(a)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
2:15 p.m.
New subject: Parse VisualAge Smalltalk st files (or app as they are called)
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(a)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(a)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
28 Feb
28 Feb
2:07 p.m.
New subject: Parse VisualAge Smalltalk st files (or app as they are called)
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(a)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(a)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(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
4 Mar
4 Mar
4:49 p.m.
New subject: Parse VisualAge Smalltalk st files (or app as they are called)
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(a)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(a)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(a)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(a)gmail.com>
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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
5 Mar
5 Mar
9:28 a.m.
New subject: Parse VisualAge Smalltalk st files (or app as they are called)
On Mar 4, 2013, at 4:49 PM, Fabrizio Perin <fabrizio.perin(a)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(a)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(a)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(a)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(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
27 Feb
27 Feb
3:26 p.m.
New subject: Parse VisualAge Smalltalk st files (or app as they are called)
> - 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.
9:36 p.m.
New subject: Parse VisualAge Smalltalk st files (or app as they are called)
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(a)gmail.com> wrote:
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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Some battles are better lost than fought."
- 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.
9:59 p.m.
New subject: Parse VisualAge Smalltalk st files (or app as they are called)
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(a)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(a)gmail.com>
wrote:
which
is evidently a MethodNode since RBMethodNode do not implement the
methodClass which is invoked in createMethod:
>> - 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
So, am I missing something? Should I use another parser other than
PPSmalltalkParser?
Cheers,
Fabrizio
_______________________________________________
Moose-dev mailing list
Moose-dev(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
10:17 p.m.
New subject: Parse VisualAge Smalltalk st files (or app as they are called)
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(a)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(a)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(a)gmail.com> wrote:
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(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)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."
- 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.
28 Feb
28 Feb
2:02 p.m.
New subject: Parse VisualAge Smalltalk st files (or app as they are called)
On Feb 27, 2013, at 9:59 PM, Fabrizio Perin <fabrizio.perin(a)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(a)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(a)gmail.com> wrote:
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(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)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.
27 Feb
27 Feb
10:28 p.m.
New subject: Parse VisualAge Smalltalk st files (or app as they are called)
On Wed, Feb 27, 2013 at 6:26 AM, Fabrizio Perin <fabrizio.perin(a)gmail.com>wrote;wrote:
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 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.
28 Feb
28 Feb
2:03 p.m.
New subject: Parse VisualAge Smalltalk st files (or app as they are called)
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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
27 Feb
27 Feb
2:38 p.m.
New subject: Parse VisualAge Smalltalk st files (or app as they are called)
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(a)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(a)gmail.com>
wrote:
--
www.tudorgirba.com
"It's not what we do that matters most, it's how we do it."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)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(a)gmail.com>om>:
> 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(a)gmail.com>om>:
>> Hi.
>>
>> On Wed, Feb 20, 2013 at 4:01 AM, Fabrizio Perin <
fabrizio.perin(a)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(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
26 Feb
26 Feb
9:14 p.m.
New subject: Parse VisualAge Smalltalk st files (or app as they are called)
On Feb 23, 2013, at 10:57 AM, Fabrizio Perin <fabrizio.perin(a)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(a)gmail.com>om>:
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(a)gmail.com>om>:
> Hi.
>
> On Wed, Feb 20, 2013 at 4:01 AM, Fabrizio Perin <fabrizio.perin(a)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(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
28 Feb
28 Feb
2 p.m.
New subject: Parse VisualAge Smalltalk st files (or app as they are called)
On Feb 21, 2013, at 9:42 AM, Fabrizio Perin <fabrizio.perin(a)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(a)gmail.com>om>:
Hi.
On Wed, Feb 20, 2013 at 4:01 AM, Fabrizio Perin <fabrizio.perin(a)gmail.com>
wrote:
<snip>
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
- 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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
4080
days inactive
4093
days old
26 comments
5 participants
participants (5)
-
Chris Cunningham -
Fabrizio Perin -
stephane ducasse -
Stéphane Ducasse -
Tudor Girba