- Pharo-dev - lists.pharo.org

[Pharo-project] BDD: Cucumber Toy Project

by Sean P. DeNigris

I'm playing with Polymorph to make a BDD tool like Ruby's Cucumber (but infinitely better because we're in a live image and don't have to cram the infinite richness of our imagination into dead text, lol). It's amazing how a few lines of code got me *very* close to an active essay of the cucumber book's first example. Here is a screenshot of the Cucumber book: http://forum.world.st/file/n3742986/Screen_Shot_2011-08-14_at_10.30.11_AM.p… And here is a quick Polymorph view: http://forum.world.st/file/n3742986/Screen_Shot_2011-08-14_at_10.29.44_AM.p… Hopefully I'll have something we can play with by ESUG! Sean -- View this message in context: http://forum.world.st/BDD-Cucumber-Toy-Project-tp3742986p3742986.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 14, 2011

Re: [Pharo-project] #name

by Schwab,Wilhelm K

I looked at this early on, and decided that since Object>>name is defined in terns of #printString, there couldn't be anything terribly important happening with the result, because #printSring is not under the system's control. I have freely added name as an instance variable in many classes. Process>>name and #name: are interesting. I didn't do the hash part, but I advocated for adding the name aspect to Process, and was very much surprised to see it adopted. This was in the days when most requests for changes prompted a reply something like "Do you realize that YOU can do that to YOUR image?" - emphasis added, but it was always clearly present. However, it has apparently been there since 2002. If there were going to be problems, I think we would have seen them by now :) That of course does nothing to fix the real problem, but I think it does provide evidence that one can safely ignore Object>>name. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] Sent: Saturday, August 13, 2011 9:39 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] #name On Aug 12, 2011, at 5:35 PM, Sean P. DeNigris wrote: > How is #name used by the system? I often want to use it in my classes, but I > don't want to mess with whatever Object is doing with it. There are +++ > senders. Yes name is object is quite a bad smell to me. This is on my radar to nule setname: and friends. Since this is only used to give name to part in etoyish morphic If I remember also pay attention for class methods too. > On the flip side, should the system use a different, more specific, > intention-revealing selector to avoid this confusion? > > Thanks. > Sean > > -- > View this message in context: http://forum.world.st/name-tp3739677p3739677.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Aug. 14, 2011

Re: [Pharo-project] Smalltalk lecture Saturday 20th of August at ESUG

by StÃ©phane Ducasse

They told me that the building will be open a 10 so 10h15 Stef > > Hi Stef-- > >> I will give a free lecture >> >> ... >> >> Starting time: 9h30 >> Closing: 16h00 > > When does the lecture start and end? > > I'm looking forward to it! Thanks! > > > -C > > -- > Craig Latta > www.netjam.org/resume > +31 6 2757 7177 > + 1 415 287 3547 > > >

Aug. 14, 2011

Re: [Pharo-project] Smalltalk lecture Saturday 20th of August at ESUG

by Craig Latta

Hi Stef-- > I will give a free lecture > > ... > > Starting time: 9h30 > Closing: 16h00 When does the lecture start and end? I'm looking forward to it! Thanks! -C -- Craig Latta www.netjam.org/resume +31 6 2757 7177 + 1 415 287 3547

Aug. 14, 2011

Re: [Pharo-project] #name

by Craig Latta

Hi Sean-- > How is #name used by the system? I often want to use it in my > classes, but I don't want to mess with whatever Object is doing with > it. There are +++ senders. And several implementers that could be using more descriptive selectors, too, which makes answering the question harder, of course. > On the flip side, should the system use a different, more specific, > intention-revealing selector to avoid this confusion? Certainly. From my work with minimal systems (which includes logging many specific send-sites), I'm convinced that this behavior should have a more descriptive selector, and is not essential to Object anyway. -C -- Craig Latta www.netjam.org/resume +31 6 2757 7177 + 1 415 287 3547

Aug. 14, 2011

[Pharo-project] Smalltalk lecture Saturday 20th of August at ESUG

by StÃ©phane Ducasse

Hi Friends please distribute that widely I will give a free lecture Discovering Smalltalk Smalltalk is a pure and elegant object language. This lectures will cover the fundamental aspects of Smalltalk: syntax, semantics, and key aspects of the system. Doing so we will also revise the real semantics of self/super. We will show the power of polymorphism in action by simply learning from the system. Finally we will go into more design aspect again based on the systems. As a bonus we will start the lecture with a 15 min presentation of Seaside a powerful web framework for dynamic web application. This lecture may be followed by a lecture on more advanced object-oriented design: law of demeter, encapsulation, multiple interface of classes, composition vs. inheritance Starting time: 9h30 Closing: 16h00 Location: http://www.esug.org/wiki/pier/Conferences/2011/The-Venue-in-Edinburgh Bio: He is expert in object-oriented language design, dynamic languages, reflective programming, language semantics as well as reengineering, program analysis, visualizations, software metrics. Recently he worked on traits, composable method groups, and this work got some impact. Traits have been introduced AmbiantTalk, Pharo, Perl-6, PHP 5.4 and Squeak. They influenced Scala and Fortress SUN Microsystems. Stephane is one of the developer of Pharo (http://www.pharo.project.org/) an open-source language inspired by Smalltalk. He is one of the core developer of Moose, an open-source reengineering environment (http://moose.unibe.ch/) He is the president of the European Smalltalk User Group and organize a yearly international conference on Smalltalk. He wrote a couple of fun books to teach programming and other serious topics such as dynamic web development (http://book.seaside.st) Stef

Aug. 14, 2011

Re: [Pharo-project] formatting style

by Eliot Miranda

On Sat, Aug 13, 2011 at 8:41 AM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > 2011/8/13 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > > > > On Aug 12, 2011, at 3:58 PM, Lukas Renggli wrote: > > > >> On 12 August 2011 15:42, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > >>> I mean that I prefer > >>> > >>>>> Smalltalk tools > >>>>> register: ;lkl;k;lk;l > >>>>> in: lkl;k;lkl;kl; > >>> > >>> over > >>> > >>>>> Smalltalk tools register: ;lkl;k;lk;l > >>>>> in: lkl;k;lkl;kl; > >>> > >>> > >>> because I do not see fast that the message is register: in: > >> > >> Hmm, I still don't understand your example because the $; has semantic > >> meaning and because the example doesn't even compile :-) > > > >>>>> Smalltalk tools > >>>>> register: 'string' > >>>>> in: 'hkjjkhkhjh' > > > > :) > > > > > > > >> > >>> and I guess that you are formatting the way I like but the rb formatter > may be wrong because > >> > >> You can configure after how how many keyword parts (that is probably > >> too low right now) it should print on one line. Also you can tell it > >> how many characters per line you maximally want (used to be 80, I > >> think i changed the default to 100; but probably should be inifite). > >> > > > > I will play with it. > > I'm really thinking that having a systematic formatting of code within > the core would be good. > > > > 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. > +2 raisedTo: SmallInteger maxVal > > 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. > > Nicolas > > > > >> Lukas > >> > >>> > >>> On Aug 12, 2011, at 1:49 PM, Lukas Renggli wrote: > >>> > >>>> Hmm, I don't get your example. > >>>> > >>>> What I changed is that the formatter does not enforce the useless > >>>> parenthesis around the receiver of a cascade. Can be disabled though. > >>>> > >>>> Also note that there are settings to automatically format code on > >>>> display and/or accept. I use the "on display" mode often to read ugly > >>>> code :-) > >>>> > >>>> Lukas > >>>> > >>>> On 12 August 2011 13:29, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > >>>>> Yes > >>>>> > >>>>> Smalltalk tools > >>>>> register: ;lkl;k;lk;l > >>>>> in: lkl;k;lkl;kl; > >>>>> > >>>>> > >>>>> stef > >>>>> On Aug 12, 2011, at 1:20 PM, Lukas Renggli wrote: > >>>>> > >>>>>>> I always think of this a the Seaside style, but I am not sure if > that is a correct attribution. > >>>>>> > >>>>>> Haha, thank you. > >>>>>> > >>>>>> Actually the refactoring browser formatter with the default settings > >>>>>> is quite close to the Seaside style, I just recently submitted some > >>>>>> fixes for cascades. The only thing that I don't like about the > >>>>>> automatic formatter is how the brackets in multiline blocks are > >>>>>> aligned. Anyway, the formatter would style #inject:into: as you > >>>>>> suggest. > >>>>>> > >>>>>> Lukas > >>>>>> > >>>>>> -- > >>>>>> Lukas Renggli > >>>>>> www.lukas-renggli.ch > >>>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> Lukas Renggli > >>>> www.lukas-renggli.ch > >>>> > >>> > >>> > >>> > >> > >> > >> > >> -- > >> Lukas Renggli > >> www.lukas-renggli.ch > >> > > > > > > > > -- best, Eliot

Aug. 13, 2011

[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