August 2011 - Pharo-dev - lists.pharo.org

[Pharo-project] Thanks Jenkins/Marcus

by Mariano Martinez Peck

Since several months, Fuel tests in Jenkins were all red. We never could understood why because of course in our machines it worked. We tried in Mac, Linux and Windows. All were working correctly. Only Hudson was failing. Of course, we blamed Hudson, Cog, the OS, Marcus (hahhaahaha), everyone. Today, after a couple of hours we finally found the problem. Guess what? of course, it was a bug in Fuel!!! It is difficult to explain why it was only failing in Jenkins. But anyway, thanks for such great tool. Now, every single commit in Fuel fires up a build in Jenkins and run our 162 tests. All green so far. Finally, in Fuel, speed is very important and hence we have a large set of benchmarks. I would LOVE to be able to run benchmarks in addition to tests and then watch nice graphs where I can notice which commit made Fuel faster or slower. Thanks! -- Mariano http://marianopeck.wordpress.com

Aug. 13, 2011

Re: [Pharo-project] formatting style

by Nicolas Cellier

2011/8/13 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> >> The thing that upsets me most is auto-formatting of literals. >> >> 1) the formatter SHALL try to preserve the indenting of array literals >> Â A 256 elements table organised in a 16x16 fashion can be legible. >> Â A rough 256 element suit is not. >> 2) the formatter SHALL preserve the base used to specify a number literal >> Â If i write 2r1011 it's clearly not my intention to read 11. >> Â It's the same for number composing a literal array/byte array >> >> In other words, the literals shall better be left unchanged. >> >> The second thing that is annoying is that it can become hard to >> compare code and track evolutions. >> But this one is just a question of having the right tool to perform >> the comparison... >> I always thought that MC, change list and friends should propose an >> option that simply compares scanned tokens and optionnally ignore >> comments. > > 100% with you. > Marcus made progress on OPAL and once we have AST in the image (now we have it) > we should really invest in bringing the tools to another level. > I hope that we will stop cleaning but really defining new tools. > > Stef > IMO a lexical comparison with a Scanner should be enough. Nicolas

Aug. 13, 2011

Re: [Pharo-project] formatting style

by StÃ©phane Ducasse

> > The thing that upsets me most is auto-formatting of literals. > > 1) the formatter SHALL try to preserve the indenting of array literals > A 256 elements table organised in a 16x16 fashion can be legible. > A rough 256 element suit is not. > 2) the formatter SHALL preserve the base used to specify a number literal > If i write 2r1011 it's clearly not my intention to read 11. > It's the same for number composing a literal array/byte array > > In other words, the literals shall better be left unchanged. > > The second thing that is annoying is that it can become hard to > compare code and track evolutions. > But this one is just a question of having the right tool to perform > the comparison... > I always thought that MC, change list and friends should propose an > option that simply compares scanned tokens and optionnally ignore > comments. 100% with you. Marcus made progress on OPAL and once we have AST in the image (now we have it) we should really invest in bringing the tools to another level. I hope that we will stop cleaning but really defining new tools. Stef

Aug. 13, 2011

Re: [Pharo-project] #name

by StÃ©phane Ducasse

Do you really get that ? :) Stef On Aug 13, 2011, at 5:15 PM, Alexander LazareviÄ wrote: > 2011/8/13 Lukas Renggli <renggli(a)gmail.com> > Just for fun, try implementing #name on the class-side. Your image is > pretty much hosed :-) > > I guess that depends on what that name method does return, no? If it's a String or Symbol it looks funny, but the image doesn't seem to be hosed. :) > > Alex > <bullfrog.png>

Aug. 13, 2011

Re: [Pharo-project] PPElementParser & a small PetitTests contribution

by Lukas Renggli

On 13 August 2011 18:43, Damien Pollet <damien.pollet(a)gmail.com> wrote: > On 13 August 2011 18:29, Lukas Renggli <renggli(a)gmail.com> wrote: >>> Should I commit my patched PetitParser package to Coral's repo until >>> it gets accepted? How will metacello deal with that? I have to update >>> my config in the meantime? >> >> Did you patch PetitParser? AFAIK you didn't change anything, you just >> added a class and a few extension methods. > > I modified the package == patched it == new PetitParser-DamienPollet.XXX.mcz > > Question is, how/where do I commit so you can review/accept code into > petitparser, but coral continues to load and work, and we don't get > too many surprises when you decide to accept the new functionality. Packaging separately seems to be the way to go. -- Lukas Renggli www.lukas-renggli.ch

Aug. 13, 2011

Re: [Pharo-project] PPElementParser & a small PetitTests contribution

by Lukas Renggli

On 13 August 2011 18:41, Damien Pollet <damien.pollet(a)gmail.com> wrote: > On 13 August 2011 18:27, Lukas Renggli <renggli(a)gmail.com> wrote: >> This is kind of ambiguous of how to report such nested errors. I >> wonder if you couldn't avoid all the troubles if you just used a flat >> string, instead of a preprocessed one? > > ARGV is not a flat string, and I can't join it with spaces since I > can't reproduce how the shell split it in the first place. What about a special sentinel like Character value: 0? Lukas -- Lukas Renggli www.lukas-renggli.ch

Aug. 13, 2011

Re: [Pharo-project] PPElementParser & a small PetitTests contribution

by Damien Pollet

On 13 August 2011 18:29, Lukas Renggli <renggli(a)gmail.com> wrote: >> Should I commit my patched PetitParser package to Coral's repo until >> it gets accepted? How will metacello deal with that? I have to update >> my config in the meantime? > > Did you patch PetitParser? AFAIK you didn't change anything, you just > added a class and a few extension methods. I modified the package == patched it == new PetitParser-DamienPollet.XXX.mcz Question is, how/where do I commit so you can review/accept code into petitparser, but coral continues to load and work, and we don't get too many surprises when you decide to accept the new functionality. -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

Aug. 13, 2011

Re: [Pharo-project] PPElementParser & a small PetitTests contribution

by Damien Pollet

On 13 August 2011 18:27, Lukas Renggli <renggli(a)gmail.com> wrote: > This is kind of ambiguous of how to report such nested errors. I > wonder if you couldn't avoid all the troubles if you just used a flat > string, instead of a preprocessed one? ARGV is not a flat string, and I can't join it with spaces since I can't reproduce how the shell split it in the first place. -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

Aug. 13, 2011

Re: [Pharo-project] PPElementParser & a small PetitTests contribution

by Lukas Renggli

> Should I commit my patched PetitParser package to Coral's repo until > it gets accepted? How will metacello deal with that? I have to update > my config in the meantime? Did you patch PetitParser? AFAIK you didn't change anything, you just added a class and a few extension methods. Lukas -- Lukas Renggli www.lukas-renggli.ch

Aug. 13, 2011

Re: [Pharo-project] PPElementParser & a small PetitTests contribution

by Lukas Renggli

On 13 August 2011 17:28, Damien Pollet <damien.pollet(a)gmail.com> wrote: > On 13 August 2011 16:23, Lukas Renggli <renggli(a)gmail.com> wrote: >> Ahh, I didn't understand that you try parse nested structures :-) >> >> I discussed with Doru at some point about that and I believe he >> intended to implement some support for it, but I don't know the >> current state. Maybe you want to check with him? > > I now realize that this should more or less work: > > #any asParser ==> [:node | elementParser parse: node] > > But in case of error it would return the inner petitfailure rather > than a proper one about the position in the outer streamâ¦ This is kind of ambiguous of how to report such nested errors. I wonder if you couldn't avoid all the troubles if you just used a flat string, instead of a preprocessed one? Lukas -- Lukas Renggli www.lukas-renggli.ch

Aug. 13, 2011