July 2015 - Pharo-users - lists.pharo.org

Re: [Pharo-users] NeoCSVReader and an empty field at the very end of a file

by 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

July 5, 2015

Re: [Pharo-users] STON wtf parsing

by Peter UhnÃ¡k

Ok but how does the parser knows whether the input is multiexpression or an error? I mean it stops parsing in the middle of the string which seems really weird to me. Peter On Sun, Jul 5, 2015 at 3:28 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi Peter, > > > On 05 Jul 2015, at 14:36, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > > > How come this passes? > > > > STON fromString: '{ > > "a": "b" > > }wtf", > > "x": "y" > > '. > > > > The result is dictionary "a" -> "b". > > > > I would expect for it to die on parse error. > > > > Peter > > The reason this does not fail is because (1) STON is a stream parser that > accepts possibly multiple top-level expression from one stream (2) your > input is basically valid and complete until the closing curly brace. > > You could enforce the fact that the whole input should be consumed > yourself. > > | input reader result | > input := '{ > "a": "b" > }wtf", > "x": "y" > ' readStream. > reader := STON reader on: input. > result := reader next. > reader consumeWhitespace. > self assert: reader atEnd. > result > > Sven > > >

July 5, 2015

Re: [Pharo-users] STON wtf parsing

by Sven Van Caekenberghe

Hi Peter, > On 05 Jul 2015, at 14:36, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > How come this passes? > > STON fromString: '{ > "a": "b" > }wtf", > "x": "y" > '. > > The result is dictionary "a" -> "b". > > I would expect for it to die on parse error. > > Peter The reason this does not fail is because (1) STON is a stream parser that accepts possibly multiple top-level expression from one stream (2) your input is basically valid and complete until the closing curly brace. You could enforce the fact that the whole input should be consumed yourself. | input reader result | input := '{ "a": "b" }wtf", "x": "y" ' readStream. reader := STON reader on: input. result := reader next. reader consumeWhitespace. self assert: reader atEnd. result Sven

July 5, 2015

Re: [Pharo-users] Kivy

by Hilaire

Le 04/07/2015 23:06, stepharo a Ã©crit : > >>> For the information we are working on touch and OSWindow improvements. >>> Alain is imporving Bloc the future graphic layer of Pharo, people from >>> bern are working on new widgets. >>> We are working on cleaning widgets. Now we also accept help. >>> >>> Stef >> Sure I know. The constituting parts does not make the whole however. I >> mean a larger plan could help structuring the parts and give a focus. > > Hilaire > we have a plan > a new graphics core > with new widgets > and event touch support and several windows. > > So I do not see why you say that we are not focused. > Now you do not create a graphics core in 2 days. And if more people > would help > then we would go faster :) > Alex is experimenting to port Roassal on Bloc and he is finding bugs > that Alain is fixing. > > When I proposed topics to students this is also with this vision in mind. > > Stef > > I didn't write Pharo is unfocused, I just think broader project like kivy can give structuring focus. When reading Pharo vision document, I see great parts/foci, but I am not sure about the whole vision. I agree it is easy to raise external opinion than working on that internally, but however it does not dismiss the opinion. Hilaire -- Dr. Geo http://drgeo.eu http://google.com/+DrgeoEu

July 5, 2015

STON wtf parsing

by Peter UhnÃ¡k

How come this passes? STON fromString: '{ "a": "b" }wtf", "x": "y" '. The result is dictionary "a" -> "b". I would expect for it to die on parse error. Peter

July 5, 2015

Finding error in STON string

by Peter UhnÃ¡k

Would be possible for STON to report context for error? For example STON fromString: '[ "first", "second", ]' reports "At character 23: invalid input" which is not very useful especially in longer strings. (at: 23 is actually Character cr) Maybe better would be something like 'At character 23: invalid input near "second", ]' so I already see the surrounding text (this is not perfect, but I find it very common for example to forget comma when moving things around in array. Or even better, allow comma after the last item. (Arguably even JSON (unlike JavaScript) doesn't allow this so maybe it would break stuff.) Peter

July 5, 2015

Re: [Pharo-users] NeoCSVReader and an empty field at the very end of a file

by stepharo

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" <stepharo(a)free.fr > <mailto:stepharo@free.fr>> 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, jtuchel(a)objektfabrik.de > <mailto:jtuchel@objektfabrik.de> 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 > >>>> > >>>> > >>> > >>> > >>> > >> > >> > >> > > > > >

July 5, 2015

Re: [Pharo-users] NeoCSVReader and an empty field at the very end of a file

by Thierry Goubier

Joachim, Le 2 juil. 2015 9:49 AM, "jtuchel(a)objektfabrik.de" <jtuchel(a)objektfabrik.de> 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

July 4, 2015

Re: [Pharo-users] NeoCSVReader and an empty field at the very end of a file

by Thierry Goubier

Le 4 juil. 2015 10:58 PM, "stepharo" <stepharo(a)free.fr> 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, jtuchel(a)objektfabrik.de 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 >>>> >>>> >>> >>> >>> >> >> >> > >

July 4, 2015

Re: [Pharo-users] Kivy

by stepharo

>> For the information we are working on touch and OSWindow improvements. >> Alain is imporving Bloc the future graphic layer of Pharo, people from >> bern are working on new widgets. >> We are working on cleaning widgets. Now we also accept help. >> >> Stef > Sure I know. The constituting parts does not make the whole however. I > mean a larger plan could help structuring the parts and give a focus. Hilaire we have a plan a new graphics core with new widgets and event touch support and several windows. So I do not see why you say that we are not focused. Now you do not create a graphics core in 2 days. And if more people would help then we would go faster :) Alex is experimenting to port Roassal on Bloc and he is finding bugs that Alain is fixing. When I proposed topics to students this is also with this vision in mind. Stef

July 4, 2015