Le 02/07/2015 23:16, stepharo a écrit :
> > > Le 1/7/15 21:10, Thierry Goubier a écrit : >> Le 01/07/2015 21:07, [hidden email] a écrit : >>> I gave up on porting tests. VAST doesn't support creating Arrays with >>> curly braces, and they are used all over the place in Pharo code. I wuld >>> use them if I had them, so this is not an accuse or anything. It's just >>> a huge load of work to keep tests up to date when porting newer >>> versions, so I just ignore tests when porting. A sad truth. >> >> Maybe we should write a refactoring to change those curly braces into >> an equivalent Array based syntax? >> >> I'll have some significant porting from Pharo to do one of these days, >> so maybe I'll setup something for that. > Why from Pharo? What is the problem? Not really any problem. There are just a thing or two I'd like to try, and I need to get up to speed on refactorings. Thierry |
In reply to this post by Thierry Goubier
>> Hi thierry >> >> mark will arriv at Lille saturday for a month. He is working with >> Camille on a new tree pattern matching algorithm > > A generic algorithm or one tied to the RB AST? A generic algo. We will talk with Camille monday > >> because we lost energy on RB matcher. > > What was your analysis? JC did his Phd on code transformation and with anne they try to really document how the unification works in RB and ... after tears and pain they gave up. So we really want to see if we cannot do something better. > > Thanks, > > Thierry > >> >> Stef >> >> Le 1/7/15 21:29, Thierry Goubier a écrit : >>> Le 01/07/2015 21:16, [hidden email] a écrit : >>>> You mean RewriteRules? I was planning to do that, for this exact >>>> reason. >>>> But you know how things go when there is a long list of priorities. >>>> I know it saves a lot of time and makes porting so much more safe, but >>>> it needs an up-front investment in time... >>> >>> Yes, rewrite rules. Mark Rizun GUI attempts are a very interesting >>> direction to handle that... >>> >>> Oh, by the way, Mark, if you're listening... I did what you were >>> trying to do by changing AST nodes positions in Pharo, but on a SmaCC >>> based AST for another language. I have to admit that you were right to >>> try to do it that way, but that the Pharo/RB AST infrastructure wasn't >>> suitable whereas SmaCC infrastructure is. >>> >>> Thierry >>> >>> >> >> >> > > > |
One more on my list of things to follow. >> Did they asked John Brant? He told me he was using the RB parser for everything Smalltalk and SmaCC for other languages. Oh, for JC: SmaCC does both string and ast node replacement... With a small bug in SmaCCString I need to correct (but with a design suitable for doing that over very long files). > So we really want to see if we cannot do something better. Or something you master ;) Thierry > |
In reply to this post by jtuchel
Joachim, Le 2 juil. 2015 9:49 AM, "[hidden email]" <[hidden email]> a écrit : Rewrite rules do work on non compiled code. RB contains all the necessary models to do everything RB on non compiled code. Regards, Thierry |
In reply to this post by Thierry Goubier
Check the chapter Anne and JC wrote on pharoinprogress.
We discussed a lot about RB because the unification does not identify the subtree people think about. I will let Camille and JC comment on it. What we saw is that we should try something because they are too many edge corner. Le 5/7/15 01:12, Thierry Goubier a
écrit :
|
Le 05/07/2015 12:41, stepharo a écrit :
> Check the chapter Anne and JC wrote on pharoinprogress. > We discussed a lot about RB because the unification does not identify > the subtree people think about. > I will let Camille and JC comment on it. > What we saw is that we should try something because they are too many > edge corner. I'm certainly interested to learn what is happening... In part because I need matching on code with more knowledge than the AST. Thanks in advance, Thierry |
Free forum by Nabble | Edit this page |