June 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] A more concise array access (using negative indices)

by Ramon Leon

On 6/7/2010 12:17 PM, Niko Schwarz wrote: > Well, I'm just arguing that in Ruby, the simple convention that > negative indices start from left to right map to a zoo of different > methods in Smalltalk. > > You didn't comment on: > > ('hello' from: 2 toFromEnd: 2) should = 'ell' > > Would that find your blessing? > > niko What's the goal, to be more like Ruby? If that's the case I'm sure there's a thousand things you could change, but it's not Ruby, it's Smalltalk. Ruby seems to have a style where you can send just about anything to a method and it tries to figure out what to do based on the type of the arg, they like magic and the smaller API; Smalltalk tends to just have a dozen different but similarly named methods that let you accomplish the same thing. I prefer that latter style, less magic and more smaller simpler well factored methods with a larger API and less implicit assumptions. Personally, I don't like a lot of unspoken assumptions like negative indices meaning something that isn't stated in the method name, so yes I like... ('hello' from: 2 toFromEnd: 2) should = 'ell' better than using negative indices. Not sure I like #from:toFromEnd: as the selector name, but I like the spirit of it, it makes it explicit. I'd probably like #copyFrom:fromEnd: better, but that's just personal preference as it goes better with #copyFrom:to: which would seem to be a related method in that protocol. I really don't want to learn 10 different ways to use #at:, I'd rather see 10 similarly named methods each doing it one way that look like they're all variations of a theme. When someone comes up with a new idea like #copyFrom:fromEnd:, it's easier to add that than it is to go back and patch #at: to do something new, it allows the system to grow over time yet remain stable for existing code. -- Ramon Leon http://onsmalltalk.com

June 7, 2010

Re: [Pharo-project] SmalltalkImage vs SystemDictionary

by GermÃ¡n Leiva

2010/6/7 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> 2010/6/7 Lukas Renggli <renggli(a)gmail.com> Thanks for the info. Cheers 2010/6/7 Lukas Renggli <renggli(a)gmail.com> > To separate the namespace (SmalltalkDictionary) from all the image > related tasks (SmalltalkImage). > > On Monday, June 7, 2010, GermÃ¡n Leiva <leivagerman(a)gmail.com> wrote: > > I expected that but what's the reason behind that change? > > > > The entry is http://code.google.com/p/pharo/issues/detail?id=2136 > > > > 2010/6/7 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > > > > > On Jun 7, 2010, at 1:32 AM, GermÃ¡n Leiva wrote: > > > >> Hi, > >> > >> I have a doubt ... > >> > >> why in Pharo 1.0 > >> > >> Smalltalk class == SystemDictionary > >> > >> and in Pharo 1.1 > >> > >> Smalltalk class == SmalltalkImage? > > > > Yes this is normal > > > > now Smalltalk globals class == SystemDictionary > > > >> Looking at the issue tracker (thanks Carla): > >> We should make > >> > >> - Smalltalk pointing to SmalltalkImage current > >> - have SystemDictionary only having classbindings management. > >> and Smalltalk globals pointing to SystemDictionary instance. > > > > this is done. > > which entry is that? > >> > >> This way we finish the refactoring started long time ago. > >> We should have a look at the way this was done in Squeak so that we get > the same > >> compatible for now solution. > >> > >> What's involved in the refactoring started long time ago and what's the > motivation for it? > >> > >> Cheers > >> -- > >> GermÃ¡n Leiva > >> LeivaGerman(a)gmail.com > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > -- > > GermÃ¡n Leiva > > LeivaGerman(a)gmail.com > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- GermÃ¡n Leiva LeivaGerman(a)gmail.com

June 7, 2010

Re: [Pharo-project] About TDD and Pharo

by Niko Schwarz

Why not offer "not yet categorized" as the first option as a category to choose from? Niko 2010/6/7 Gabriel Brunstein <gaboto(a)gmail.com>: > maybe the right name would be something like "donÂ´t categorize"Â ;) > > On Mon, Jun 7, 2010 at 11:54 AM, Niko Schwarz <niko.schwarz(a)googlemail.com> > wrote: >> >> Right, only that I'm unhappy with the naming. I'd never have guessed >> that "cancel" does what I want. So far, I've always chosen a random >> junk category and fixed it up later. A button "Cancel" I'd expect to >> cancel the creation altogether. >> >> Niko >> >> 2010/6/7 Hernan Wilkinson <hernan.wilkinson(a)gmail.com>: >> > it is true, I almost all the time cancel that dialog to put the method >> > as >> > not yet categorized... but sometimes I select the category... I think >> > that >> > pressing ESC or cancel is not that bad in this case and I would keep >> > this >> > dialog. >> > >> > On Mon, Jun 7, 2010 at 5:45 AM, Niko Schwarz >> > <niko.schwarz(a)googlemail.com> >> > wrote: >> >> >> >> I think the rationale must be: during TDD it's ok to ask the developer >> >> questions that he can answer right away. Thus, it's ok that the create >> >> button asks for the class: you know instantly what to answer. But >> >> asking for the method category is a major pain. I don't know about >> >> y'all, but I never quite know upfront how I'll structure my >> >> categories. That emerges much later in the process. >> >> >> >> In short: remove the asking for the method category. Just put it in >> >> 'not yet categorized', and have me figure it out later. >> >> >> >> Cheers, >> >> >> >> Niko >> >> >> >> 2010/6/2 GermÃ¡n Leiva <leivagerman(a)gmail.com>: >> >> > I'm thinking out load here ... >> >> > In the debugger when a DNU is raised, for speeding up the programming >> >> > in >> >> > "TDD mode": >> >> > >> >> > The create button must add the method in the class of the receiver, >> >> > the >> >> > possibility to choose a superclass of the receiver must be optional >> >> > (I >> >> > don't >> >> > like the recurrent asking...) in other button for example or having >> >> > different shortcuts from the keyboard >> >> > If I send a message that I already know that will be a getter, some >> >> > option >> >> > like "Create getter"Â couldÂ automagicallyÂ create the method and the >> >> > instance >> >> > variable. >> >> > When we a accept a method for the first time the pop-ups saying >> >> > "Unkown >> >> > selector please confirm, select or cancel" are really annoying and >> >> > decrease >> >> > coding speed >> >> > Same for the category pop-ups >> >> > In the creation of a new class through "define new class" it will be >> >> > helpful >> >> > to remember the last class category used >> >> > >> >> > Some ToDo list supported from the environment and some facility for >> >> > the >> >> > creation of test. >> >> > All of the above maybe just make sense in TDD mode or not =P >> >> > Cheers >> >> > 2010/6/2 Alexandre Bergel <alexandre.bergel(a)inria.fr> >> >> >> >> >> >> The problems that I would like to see Pharo address are: >> >> >> Â - redundancies in unit tests >> >> >> Â - coverage of tests >> >> >> Â - classification of low and high levels of tests (implementation >> >> >> tests >> >> >> vs >> >> >> user stories) >> >> >> >> >> >> What are the tools to identify and solve this issues ? Research is >> >> >> needed >> >> >> :-) >> >> >> >> >> >> Alexandre >> >> >> >> >> >> >> >> >> >> >> >> On 2 Jun 2010, at 15:30, StÃ©phane Ducasse wrote: >> >> >> >> >> >> > Hi all >> >> >> > >> >> >> > Imagine that we would like to sell pharo (+ seaside) as THE agile >> >> >> > platform for doing TDD. >> >> >> > What would be the changes that we could do support it. >> >> >> > I know that hernan did a package for that but not I would like to >> >> >> > have a >> >> >> > new list of items >> >> >> > to support it. >> >> >> > >> >> >> > Stef >> >> >> > _______________________________________________ >> >> >> > Pharo-project mailing list >> >> >> > Pharo-project(a)lists.gforge.inria.fr >> >> >> > >> >> >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> >> Pharo-project mailing list >> >> >> Pharo-project(a)lists.gforge.inria.fr >> >> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> > >> >> > >> >> > >> >> > -- >> >> > GermÃ¡n Leiva >> >> > LeivaGerman(a)gmail.com >> >> > >> >> > _______________________________________________ >> >> > Pharo-project mailing list >> >> > Pharo-project(a)lists.gforge.inria.fr >> >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> > >> >> >> >> >> >> >> >> -- >> >> http://scg.unibe.ch/staff/Schwarz >> >> twitter.com/nes1983 >> >> Tel: +41 076 235 8683 >> >> >> >> _______________________________________________ >> >> Pharo-project mailing list >> >> Pharo-project(a)lists.gforge.inria.fr >> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >> > >> > _______________________________________________ >> > Pharo-project mailing list >> > Pharo-project(a)lists.gforge.inria.fr >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >> >> >> >> -- >> http://scg.unibe.ch/staff/Schwarz >> twitter.com/nes1983 >> Tel: +41 076 235 8683 >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683

June 7, 2010

Re: [Pharo-project] A more concise array access (using negative indices)

by Niko Schwarz

That would be precisely what ruby does. It's ary at: (1 to: 3) vs. ary from: 1 to: 3. Right there, the second one looks more useful. But, the first thing leads to beautiful code in Matlab and Mathematica when dealing with vectors and matrices. So it may well be worth it. Cheers, Niko On Mon, Jun 7, 2010 at 9:30 PM, Hilaire Fernandes <hilaire.fernandes(a)gmail.com> wrote: > Niko Schwarz a Ã©crit : > >> Just to put something on the table, how about: >> >> (ary at: 1, -2) > > Or #at: could accept an interval as argument > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683

June 7, 2010

Re: [Pharo-project] squeaksource.com is down?

by StÃ©phane Ducasse

no unfortunately this is the server. May be having a cron job restarting every day the server could be good. Stef > I couldn't access it for the last couple of hours, is it some planned > maintenance? > > Thank you, > Andrei > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 7, 2010

[Pharo-project] squeaksource.com is down?

by Andrei Stebakov

I couldn't access it for the last couple of hours, is it some planned maintenance? Thank you, Andrei

June 7, 2010

Re: [Pharo-project] About TDD and Pharo

by Gabriel Brunstein

maybe the right name would be something like "donÂ´t categorize" ;) On Mon, Jun 7, 2010 at 11:54 AM, Niko Schwarz <niko.schwarz(a)googlemail.com>wrote: > Right, only that I'm unhappy with the naming. I'd never have guessed > that "cancel" does what I want. So far, I've always chosen a random > junk category and fixed it up later. A button "Cancel" I'd expect to > cancel the creation altogether. > > Niko > > 2010/6/7 Hernan Wilkinson <hernan.wilkinson(a)gmail.com>: > > it is true, I almost all the time cancel that dialog to put the method as > > not yet categorized... but sometimes I select the category... I think > that > > pressing ESC or cancel is not that bad in this case and I would keep this > > dialog. > > > > On Mon, Jun 7, 2010 at 5:45 AM, Niko Schwarz < > niko.schwarz(a)googlemail.com> > > wrote: > >> > >> I think the rationale must be: during TDD it's ok to ask the developer > >> questions that he can answer right away. Thus, it's ok that the create > >> button asks for the class: you know instantly what to answer. But > >> asking for the method category is a major pain. I don't know about > >> y'all, but I never quite know upfront how I'll structure my > >> categories. That emerges much later in the process. > >> > >> In short: remove the asking for the method category. Just put it in > >> 'not yet categorized', and have me figure it out later. > >> > >> Cheers, > >> > >> Niko > >> > >> 2010/6/2 GermÃ¡n Leiva <leivagerman(a)gmail.com>: > >> > I'm thinking out load here ... > >> > In the debugger when a DNU is raised, for speeding up the programming > in > >> > "TDD mode": > >> > > >> > The create button must add the method in the class of the receiver, > the > >> > possibility to choose a superclass of the receiver must be optional (I > >> > don't > >> > like the recurrent asking...) in other button for example or having > >> > different shortcuts from the keyboard > >> > If I send a message that I already know that will be a getter, some > >> > option > >> > like "Create getter" could automagically create the method and the > >> > instance > >> > variable. > >> > When we a accept a method for the first time the pop-ups saying > "Unkown > >> > selector please confirm, select or cancel" are really annoying and > >> > decrease > >> > coding speed > >> > Same for the category pop-ups > >> > In the creation of a new class through "define new class" it will be > >> > helpful > >> > to remember the last class category used > >> > > >> > Some ToDo list supported from the environment and some facility for > the > >> > creation of test. > >> > All of the above maybe just make sense in TDD mode or not =P > >> > Cheers > >> > 2010/6/2 Alexandre Bergel <alexandre.bergel(a)inria.fr> > >> >> > >> >> The problems that I would like to see Pharo address are: > >> >> - redundancies in unit tests > >> >> - coverage of tests > >> >> - classification of low and high levels of tests (implementation > tests > >> >> vs > >> >> user stories) > >> >> > >> >> What are the tools to identify and solve this issues ? Research is > >> >> needed > >> >> :-) > >> >> > >> >> Alexandre > >> >> > >> >> > >> >> > >> >> On 2 Jun 2010, at 15:30, StÃ©phane Ducasse wrote: > >> >> > >> >> > Hi all > >> >> > > >> >> > Imagine that we would like to sell pharo (+ seaside) as THE agile > >> >> > platform for doing TDD. > >> >> > What would be the changes that we could do support it. > >> >> > I know that hernan did a package for that but not I would like to > >> >> > have a > >> >> > new list of items > >> >> > to support it. > >> >> > > >> >> > Stef > >> >> > _______________________________________________ > >> >> > Pharo-project mailing list > >> >> > Pharo-project(a)lists.gforge.inria.fr > >> >> > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> >> > >> >> > >> >> _______________________________________________ > >> >> Pharo-project mailing list > >> >> Pharo-project(a)lists.gforge.inria.fr > >> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > > >> > > >> > > >> > -- > >> > GermÃ¡n Leiva > >> > LeivaGerman(a)gmail.com > >> > > >> > _______________________________________________ > >> > Pharo-project mailing list > >> > Pharo-project(a)lists.gforge.inria.fr > >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > > >> > >> > >> > >> -- > >> http://scg.unibe.ch/staff/Schwarz > >> twitter.com/nes1983 > >> Tel: +41 076 235 8683 > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > -- > http://scg.unibe.ch/staff/Schwarz > twitter.com/nes1983 > Tel: +41 076 235 8683 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 7, 2010

Re: [Pharo-project] A more concise array access (using negative indices)

by StÃ©phane Ducasse

nope this is a primitive and we do not have multiple dispatch Stef On Jun 7, 2010, at 9:30 PM, Hilaire Fernandes wrote: > Niko Schwarz a Ã©crit : > >> Just to put something on the table, how about: >> (ary at: 1, -2) > > Or #at: could accept an interval as argument > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 7, 2010

Re: [Pharo-project] A more concise array access (using negative indices)

by StÃ©phane Ducasse

If you want a chance to your idea propose some code and some tests H E L L O 1 2 3 4 5 -5 -4 -3 -2 -1 hello from: 2 to: -2 -> ell ok 'hello' from: 2 to: -2 -> ello 'hello' from: 2 to: 0 -> ??? This is strange because I thought intuitively and wrong that it would be means complete from: 2 toFromEnd: 2 from: 2 to: -2 So do you have other usage of negative index in ruby? Because I'm not sure I like that? Stef >> copyFrom: 1 to: does not convey that you should pass the second argument starting reverse. > > Well, in ruby it's a general convention that negative indices start > counting from the right. A reasonable implementation would change all > sequenceable collections such that they accept negative indices. > > In Phexample syntax: > > ((1 to: 5) at: -2) should = 4. > > The alternative is to always have two accessors, then of course non-negative: > > (1 to: 5) atFromEnd: 2) should = 4. > > and: > > ('hello' from: 2 toFromEnd: 2) should = 'ell' > > I clearly prefer the negative indices. Things you do all the time can > be much shorter than things you don't do so often. Huffman-encode your > programming :) > > Cheers, > > Niko > > > -- > http://scg.unibe.ch/staff/Schwarz > twitter.com/nes1983 > Tel: +41 076 235 8683 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 7, 2010

Re: [Pharo-project] A more concise array access (using negative indices)

by StÃ©phane Ducasse

On Jun 7, 2010, at 3:36 PM, Niko Schwarz wrote: > On Mon, Jun 7, 2010 at 3:23 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> yes this one looks good. >> but >> >> copyFrom: 1 to: does not convey that you should pass the second argument starting reverse. > > Well, in ruby it's a general convention that negative indices start > counting from the right. A reasonable implementation would change all > sequenceable collections such that they accept negative indices. > > In Phexample syntax: > > ((1 to: 5) at: -2) should = 4. > > The alternative is to always have two accessors, then of course non-negative: > > (1 to: 5) atFromEnd: 2) should = 4. > > and: > > ('hello' from: 2 toFromEnd: 2) should = 'ell' > > I clearly prefer the negative indices. Things you do all the time can > be much shorter than things you don't do so often. Huffman-encode your > programming :) s stef ? sure ? shit ? huffman encding your programming is a stupid idea.

June 7, 2010