NeoCSVReader and an empty field at the very end of a file

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: NeoCSVReader and an empty field at the very end of a file

Thierry Goubier
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

Reply | Threaded
Open this post in threaded view
|

Re: NeoCSVReader and an empty field at the very end of a file

stepharo
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
>>>
>>>
>>
>>
>>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: NeoCSVReader and an empty field at the very end of a file

Thierry Goubier


Le 4 juil. 2015 10:58 PM, "stepharo" <[hidden email]> a écrit :
>
>
>>> 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

One more on my list of things to follow.

>>
>>> 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.

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

>
>>
>> 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
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: NeoCSVReader and an empty field at the very end of a file

Thierry Goubier
In reply to this post by jtuchel

Joachim,

Le 2 juil. 2015 9:49 AM, "[hidden email]" <[hidden email]> a écrit :
>
> The problem with Step 2 is: I am not sure if RewriteRules can work in code that's not compiled. (Well, I am mostly sure this won't work, just asking for confirmation) You cannot compile methods with Arrays constructed with curly braces on VAST.

Rewrite rules do work on non compiled code.

RB contains all the necessary models to do everything RB on non compiled code.

Regards,

Thierry

Reply | Threaded
Open this post in threaded view
|

Re: NeoCSVReader and an empty field at the very end of a file

stepharo
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 4 juil. 2015 10:58 PM, "stepharo" <[hidden email]> a écrit :
>
>
>>> 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

One more on my list of things to follow.

>>
>>> 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.

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

>
>>
>> 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
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: NeoCSVReader and an empty field at the very end of a file

Thierry Goubier
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

12