December 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] SUnit forked, gofer it

by Mariano Martinez Peck

On Fri, Dec 25, 2009 at 1:54 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > I maintain my own "stable" fork of OB at > http://source.lukas-renggli.ch/omnibrowser. Colin merges the code from > time-to-time. I found that the official code was often broken or > in-stable, because too many people changed things ... > > Ok... I didn't know about that. The problem is that in the pharo scripts we are using to generate the dev image we install OB from here: http://source.wiresong.ca/ob :( Can I commit it there? what can be the problem ? Thanks Mariano Lukas > > 2009/12/25 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > > > > > On Thu, Dec 24, 2009 at 10:56 AM, Lukas Renggli <renggli(a)gmail.com> > wrote: > >> > >> Changed in > >> > >> Name: OB-SUnitIntegration-lr.16 > >> Author: lr > >> Time: 24 December 2009, 10:54:56 am > >> UUID: 661b0ef3-03df-4193-84ed-e482c9baaec6 > >> Ancestors: OB-SUnitIntegration-AdrianKuhn.15 > >> > >> - run tests depending on selection > >> > > > > Are you sure you commited ? In http://source.wiresong.ca/ob the last > > version I see is OB-SUnitIntegration-AdrianKuhn.15 > > But maybe is a problem in my image or proxy caching something. > > > > Cheers and happy christmas. > > > > mariano > > > >> > >> 2009/12/24 Mariano Martinez Peck <marianopeck(a)gmail.com>: > >> > > >> > > >> > On Thu, Dec 24, 2009 at 9:52 AM, Lukas Renggli <renggli(a)gmail.com> > >> > wrote: > >> >> > >> >> Indeed, it aways runs all tests of a class. Should that be changed? I > >> > > >> > Yes!!!! If you have selected a particular method, the idea is to run > >> > THAT > >> > method, not all. Why you need to select then ? > >> > If you want all methods go to the class or even to the tests runner. > >> > > >> >> > >> >> found it more useful to run them all, instead of just one. > >> >> > >> >> Lukas > >> >> > >> >> 2009/12/24 Adrian Kuhn <akuhn(a)iam.unibe.ch>: > >> >> > Tudor Girba <tudor.girba@...> writes: > >> >> > > >> >> >> It should work if your mouse is over the methods pane. > >> >> > > >> >> > Not true in OB. > >> >> > > >> >> > > >> >> > -- > >> >> > 4th Workshop on Dynamic Languages and Applications > >> >> > Submit papers by March 31, 2010. http://bit.ly/dyla2010 > >> >> > > >> >> > > >> >> > _______________________________________________ > >> >> > Pharo-project mailing list > >> >> > Pharo-project(a)lists.gforge.inria.fr > >> >> > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> >> > > >> >> > >> >> > >> >> > >> >> -- > >> >> Lukas Renggli > >> >> http://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 > >> > > >> > > >> > _______________________________________________ > >> > Pharo-project mailing list > >> > Pharo-project(a)lists.gforge.inria.fr > >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > > >> > >> > >> > >> -- > >> Lukas Renggli > >> http://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 > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > -- > Lukas Renggli > http://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 >

Dec. 25, 2009

[Pharo-project] sender, thisContext...

by StÃ©phane Ducasse

resent from a discussion on squeak-dev Hi David, Interesting! To my mind that definition is incorrect. I would expect the sender of a block to be the sender of the enclosing method, in which case the definition would arguably be BlockClosure methods for accessing sender ^self home sender A block activation's caller would be it's sender slot, so within a block you might refer to thisContext caller. But what is arguably a bug in my implementation is that within a block activation thisContext sender refers to the caller (the sender of value: to the activation's block) not to the sender of the enclosing method. I think I may have screwed up badly here and that the correct implementations should be MethodContext methods for accessing caller ^closureOrNil ifNil: [self error: 'this is a method activation and so has no caller'] ifNotNil: [sender] sender ^closureOrNil ifNil: [sender] ifNotNil: [closureOrNil outerContext sender] BlockClosure methods for accessing sender ^outerContext sender and either BlockClosure methods for accessing caller "Since a BlockClosure is by definition not an activation it does not have a caller. It has a sender because it is always created within the context of a method." ^nil or BlockClosure methods for accessing caller ^self error: 'this is an inactive block and so has no caller' I believe the pre-closure definitions are ContextPart methods for accessing sender ^sender BlockContext methods for accessing caller ^sender which to my mind is missing BlockContext methods for accessing sender ^home sender What do people think the right definitions should be? - Show quoted text - On Fri, Dec 18, 2009 at 8:36 PM, <commits(a)source.squeak.org> wrote: David T. Lewis uploaded a new version of Kernel to project The Trunk: http://source.squeak.org/trunk/Kernel-dtl.331.mcz ==================== Summary ==================== Name: Kernel-dtl.331 Author: dtl Time: 18 December 2009, 11:32:44 am UUID: 20ffffda-86bc-47a7-8eae-cd11b55aa65e Ancestors: Kernel-bs.330 Add BlockClosure>>sender required for MessageTally class>>tallySends: Harvested from Pharo (nice 4/14/2009 19:09). =============== Diff against Kernel-bs.330 =============== Item was added: + ----- Method: BlockClosure>>sender (in category 'debugger access') ----- + sender + "Answer the context that sent the message that created the receiver." + + ^outerContext sender!

Dec. 25, 2009

Re: [Pharo-project] SUnit forked, gofer it

by Lukas Renggli

I maintain my own "stable" fork of OB at http://source.lukas-renggli.ch/omnibrowser. Colin merges the code from time-to-time. I found that the official code was often broken or in-stable, because too many people changed things ... Lukas 2009/12/25 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > > On Thu, Dec 24, 2009 at 10:56 AM, Lukas Renggli <renggli(a)gmail.com> wrote: >> >> Changed in >> >> Name: OB-SUnitIntegration-lr.16 >> Author: lr >> Time: 24 December 2009, 10:54:56 am >> UUID: 661b0ef3-03df-4193-84ed-e482c9baaec6 >> Ancestors: OB-SUnitIntegration-AdrianKuhn.15 >> >> - run tests depending on selection >> > > Are you sure you commited ? In http://source.wiresong.ca/obÂ the last > version I see is Â OB-SUnitIntegration-AdrianKuhn.15 > But maybe is a problem in my image or proxy caching something. > > Cheers and happy christmas. > > mariano > >> >> 2009/12/24 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> > >> > >> > On Thu, Dec 24, 2009 at 9:52 AM, Lukas Renggli <renggli(a)gmail.com> >> > wrote: >> >> >> >> Indeed, it aways runs all tests of a class. Should that be changed? I >> > >> > Yes!!!!Â Â If you have selected a particular method, the idea is to run >> > THAT >> > method, not all. Why you need to select then ? >> > If you want all methods go to the class or even to the tests runner. >> > >> >> >> >> found it more useful to run them all, instead of just one. >> >> >> >> Lukas >> >> >> >> 2009/12/24 Adrian Kuhn <akuhn(a)iam.unibe.ch>: >> >> > Tudor Girba <tudor.girba@...> writes: >> >> > >> >> >> It should work if your mouse is over the methods pane. >> >> > >> >> > Not true in OB. >> >> > >> >> > >> >> > -- >> >> > 4th Workshop on Dynamic Languages and Applications >> >> > Submit papers by March 31, 2010. http://bit.ly/dyla2010 >> >> > >> >> > >> >> > _______________________________________________ >> >> > Pharo-project mailing list >> >> > Pharo-project(a)lists.gforge.inria.fr >> >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> > >> >> >> >> >> >> >> >> -- >> >> Lukas Renggli >> >> http://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 >> > >> > >> > _______________________________________________ >> > Pharo-project mailing list >> > Pharo-project(a)lists.gforge.inria.fr >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >> >> >> >> -- >> Lukas Renggli >> http://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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch

Dec. 25, 2009

Re: [Pharo-project] SUnit forked, gofer it

by Mariano Martinez Peck

On Thu, Dec 24, 2009 at 10:56 AM, Lukas Renggli <renggli(a)gmail.com> wrote: > Changed in > > Name: OB-SUnitIntegration-lr.16 > Author: lr > Time: 24 December 2009, 10:54:56 am > UUID: 661b0ef3-03df-4193-84ed-e482c9baaec6 > Ancestors: OB-SUnitIntegration-AdrianKuhn.15 > > - run tests depending on selection > > Are you sure you commited ? In http://source.wiresong.ca/ob the last version I see is OB-SUnitIntegration-AdrianKuhn.15 But maybe is a problem in my image or proxy caching something. Cheers and happy christmas. mariano > 2009/12/24 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > > > > > On Thu, Dec 24, 2009 at 9:52 AM, Lukas Renggli <renggli(a)gmail.com> > wrote: > >> > >> Indeed, it aways runs all tests of a class. Should that be changed? I > > > > Yes!!!! If you have selected a particular method, the idea is to run > THAT > > method, not all. Why you need to select then ? > > If you want all methods go to the class or even to the tests runner. > > > >> > >> found it more useful to run them all, instead of just one. > >> > >> Lukas > >> > >> 2009/12/24 Adrian Kuhn <akuhn(a)iam.unibe.ch>: > >> > Tudor Girba <tudor.girba@...> writes: > >> > > >> >> It should work if your mouse is over the methods pane. > >> > > >> > Not true in OB. > >> > > >> > > >> > -- > >> > 4th Workshop on Dynamic Languages and Applications > >> > Submit papers by March 31, 2010. http://bit.ly/dyla2010 > >> > > >> > > >> > _______________________________________________ > >> > Pharo-project mailing list > >> > Pharo-project(a)lists.gforge.inria.fr > >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > > >> > >> > >> > >> -- > >> Lukas Renggli > >> http://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 > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > -- > Lukas Renggli > http://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 >

Dec. 25, 2009

Re: [Pharo-project] More from TheTrunk

by Alexandre Bergel

> I thought it was already in Pharo, wasn't it ? > The fix only apply to this one (Interval>>do:): Ok, but part of your fix was not in Pharo. With SLICE-IntervalFix-FromTrunk-Alexandre_Bergel.1 , it is now in. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 25, 2009

Re: [Pharo-project] More from TheTrunk

by Nicolas Cellier

2009/12/25 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Yes but when I load the fix > the bug is still there. > Did you slice changes this behavior? > or the slice is just about adding a test that fails? > > > >> Yes, that's the bug, identified by Nicolas >> >> Alexandre >> >> >> On 25 Dec 2009, at 10:49, StÃ©phane Ducasse wrote: >> >>> I tried to understand >>>> >>>> >>>> >>>> A very simple example to illustrate the bug: >>>> >>>> | x | >>>> x := (1.0 timesTwoPower: 53). >>>> (x to: x + 2) size. >>>> x to: x+2 do: [:i | Transcript cr; show: i printString] >>> >>> it is normal that it still loops forever after loading the slice? > I thought it was already in Pharo, wasn't it ? The fix only apply to this one (Interval>>do:): (x to: x+2) do: [:i | self doSomethingWith: i] not to this one (Number:>#to:do:): x to: x+2 do: [:i | self doSomethingWith: i] The second one is inlined by compiler as something like i := x. end := x+2. [i <= end] whileTrue: [ self doSomethingWith: i. i := i+1] Converting to a (step*index+start) pattern would cost consumption of additional temporary variable slots and complexified code for every inlined #to:do: loop. I did not find any satisfying solution yet, just to make silly loop on Float work, so by now this remains a known limitation. General rule: avoid using interval of Float. Don't use to:by:do: with a Float receiver nor a Float step. Nicolas > > > >>> >>> Stef >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel Â http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> 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 >

Dec. 25, 2009

[Pharo-project] [update 1.1] #11116

by StÃ©phane Ducasse

11116 ----- Issue 1214: [Squeak] Collection possible improvements Stef (back with the kids and coding after)

Dec. 25, 2009

Re: [Pharo-project] More from TheTrunk

by StÃ©phane Ducasse

Yes but when I load the fix the bug is still there. Did you slice changes this behavior? or the slice is just about adding a test that fails? > Yes, that's the bug, identified by Nicolas > > Alexandre > > > On 25 Dec 2009, at 10:49, StÃ©phane Ducasse wrote: > >> I tried to understand >>> >>> >>> >>> A very simple example to illustrate the bug: >>> >>> | x | >>> x := (1.0 timesTwoPower: 53). >>> (x to: x + 2) size. >>> x to: x+2 do: [:i | Transcript cr; show: i printString] >> >> it is normal that it still loops forever after loading the slice? >> >> Stef >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 25, 2009

[Pharo-project] about resetTo: in newFrom:

by StÃ©phane Ducasse

Hi levente Reading your changes I was wondering if resetTo: should not be moved into OrderedCollection class >> new: and why only have it for the default new? OrderedCollection class >>newFrom: aCollection "Answer an instance of me containing the same elements as aCollection." + ^(self new: aCollection size) + resetTo: 1; + addAll: aCollection; + yourself - | newCollection | - newCollection := self new: aCollection size. - newCollection addAll: aCollection. - ^newCollection I did OrderedCollection new: 100. and contrary to what I expected firstIndex is not 1 but 33. Now when you add resetTo: 1 firstIndex get 1. new: anInteger "Create a collection with enough room allocated to contain up to anInteger elements. The new instance will be of size 0 (allocated room is not necessarily used)." ^self basicNew setCollection: (Array new: anInteger) setCollection: anArray array := anArray. self reset reset firstIndex := array size // 3 max: 1. lastIndex := firstIndex - 1

Dec. 25, 2009

Re: [Pharo-project] More from TheTrunk

by Alexandre Bergel

Yes, that's the bug, identified by Nicolas Alexandre On 25 Dec 2009, at 10:49, StÃ©phane Ducasse wrote: > I tried to understand >> >> >> >> A very simple example to illustrate the bug: >> >> | x | >> x := (1.0 timesTwoPower: 53). >> (x to: x + 2) size. >> x to: x+2 do: [:i | Transcript cr; show: i printString] > > it is normal that it still loops forever after loading the slice? > > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 25, 2009