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

Re: [Pharo-project] status of split join in pharo

by Oscar Nierstrasz

OK. split: assumes regexes with cannot work for collections, but this can be generalized, as you suggest. Will try to have a look at this. - on On Apr 5, 2009, at 10:26, StÃ©phane Ducasse wrote: > oscar > > it would be nice to see if the implementation make also sense in > presence of other collection. > I do not have the time to check but if a group of people can check and > report this will > help us to take a decision. > I would like to have split and join in general because this is a cool > abstraction. > Stef > > On Apr 5, 2009, at 9:51 AM, Oscar Nierstrasz wrote: > >> >> Hi Folks, >> >> What's the status of split and join? >> >> http://bugs.squeak.org/view.php?id=4874 >> >> I need them for a project and since they are not there yet, I have >> gone back to RubyShards. >> >> http://squeaksource.com/RubyShards/ >> >> Keith, do you think this can be integrated into Pharo already, or >> does >> it need some work still? >> >> (I think our implementation is not particularly efficient, but it >> should be serviceable.) >> >> Cheers, >> - on >> >> >> _______________________________________________ >> 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

April 5, 2009

[Pharo-project] [ANN] 10266 Merge tool SUnitGUI Setting Integration Enh

by StÃ©phane Ducasse

Issue 710: Merge Tool diff fix Fixes for edge cases when handling conflicts. Fixes for original MC merge browser. SUnitGUI Improvement - do not offer to test coverage of kernel/collection/exception/sunit packages, that will only crash the system - do not consider methods with <ignoreForCoverage> annotation - improving the error messages - don t try show a list if all methods are covered - really save the history - do not wrap abstract methods, they won t be called anyway - update the history even after coverage is run Settings Integration enh - Code cleaning (less classes, more comments) Alain I could not load 45 so I load 39 for now. Stef

April 5, 2009

[Pharo-project] [ANN] 10264 more closure fixes 685 & 10265 unicode

by StÃ©phane Ducasse

Issue 685: Closure fixes TmpVariableNode closure from lukas MethodsFromBlockContext from adrian Issue 706: problem with unicode 10262

April 5, 2009

Re: [Pharo-project] status of split join in pharo

by StÃ©phane Ducasse

I checked the code and it looks nice Now I found split: regexString self assert: regexString size > 0 description: 'Cannot split on empty regex'. ^regexString asRegex split: self and assert: expects a block. for the test testSplit self assert: (eg split: 'the') size = 4. self assert: (eg split: 't\w +e') size = 5. self assert: (eg split: 'hello') size = 1. it would be nice to have also an assert showing the result and not just its size then I have a question what splitBy: returns? does it return a collection that is the same kind of the receiver? Why do you hard code an OrderedCollection in splitBySubCollection: aSplitter. self species would do it too? Syef On Apr 5, 2009, at 9:51 AM, Oscar Nierstrasz wrote: > > Hi Folks, > > What's the status of split and join? > > http://bugs.squeak.org/view.php?id=4874 > > I need them for a project and since they are not there yet, I have > gone back to RubyShards. > > http://squeaksource.com/RubyShards/ > > Keith, do you think this can be integrated into Pharo already, or does > it need some work still? > > (I think our implementation is not particularly efficient, but it > should be serviceable.) > > Cheers, > - on > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 5, 2009

Re: [Pharo-project] status of split join in pharo

by StÃ©phane Ducasse

oscar it would be nice to see if the implementation make also sense in presence of other collection. I do not have the time to check but if a group of people can check and report this will help us to take a decision. I would like to have split and join in general because this is a cool abstraction. Stef On Apr 5, 2009, at 9:51 AM, Oscar Nierstrasz wrote: > > Hi Folks, > > What's the status of split and join? > > http://bugs.squeak.org/view.php?id=4874 > > I need them for a project and since they are not there yet, I have > gone back to RubyShards. > > http://squeaksource.com/RubyShards/ > > Keith, do you think this can be integrated into Pharo already, or does > it need some work still? > > (I think our implementation is not particularly efficient, but it > should be serviceable.) > > Cheers, > - on > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 5, 2009

[Pharo-project] status of split join in pharo

by Oscar Nierstrasz

Hi Folks, What's the status of split and join? http://bugs.squeak.org/view.php?id=4874 I need them for a project and since they are not there yet, I have gone back to RubyShards. http://squeaksource.com/RubyShards/ Keith, do you think this can be integrated into Pharo already, or does it need some work still? (I think our implementation is not particularly efficient, but it should be serviceable.) Cheers, - on

April 5, 2009

Re: [Pharo-project] old debugger bugs and the Closure changes

by StÃ©phane Ducasse

I will send you the code of the closure that we got. Stef On Apr 5, 2009, at 2:08 AM, Dale Henrichs wrote: > StÃ©phane, > > What image did the changes come from? Presumably there are also > changes that have been made to the pharo image that are not > compatible with the new code ... > > I've 'fixed' the obvious problems in the changes that were in the > install changeSet, but that didn't fix the 'step into' problem... > > In order to straighten things out, it may be necessary to review > code on both sides.. > > Dale > ----- "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> wrote: > > | ok probably because we could not check all the code unfortunately. > | So changes between 3.9 and pharo may have been supplanted by the > | closure changes. > | > | On Apr 4, 2009, at 6:39 PM, Dale Henrichs wrote: > | > | > I've started taking a look at the problem reported by Michael > | Roberts. > | > > | > I got slightly different misbehavior using the 10259- > | > ClosureBootstrap download on linux than reported by Michael, but > in > | > | > checking things out I discovered that the code in the Debugger for > | > | > the *Core* downloads is different from the *dev* downloads. > | > > | > For example the source for Debugger>>selectedMessageName in the > | > *Core* image (10259-ClosureBootstrap) is: > | > selectedMessageName > | > "Answer the message selector of the currently selected context. > | > If the method is unbound we can still usefully answer its old > | > selector." > | > > | > | selector | > | > selector := self selectedContext methodSelector. > | > ^(selector ~~ self selectedContext method selector > | > and: [selector beginsWith: 'DoIt']) > | > ifTrue: [self selectedContext method selector] > | > ifFalse: [selector] > | > > | > and I get a DNU for #methodSelector. On the other hand in the > *dev* > | > | > image (pharo0.1-10259dev09.03.3) the source is: > | > selectedMessageName > | > "Answer the message selector of the currently selected context." > | > > | > ^self selectedContext selector > | > > | > When I looked at the Pharo0.1Core-10259 image, the source is > | > identical to the pharo0.1-10259dev09.03.3, so the Closure > changeset > | > | > is apparently introducing some 'unwanted' changes to the Debugger > | > (and perhaps elsewhere?). > | > > | > Dale > | > > | > _______________________________________________ > | > Pharo-project mailing list > | > Pharo-project(a)lists.gforge.inria.fr > | > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- > project > | > >

April 5, 2009

Re: [Pharo-project] old debugger bugs and the Closure changes

by Dale Henrichs

StÃ©phane, What image did the changes come from? Presumably there are also changes that have been made to the pharo image that are not compatible with the new code ... I've 'fixed' the obvious problems in the changes that were in the install changeSet, but that didn't fix the 'step into' problem... In order to straighten things out, it may be necessary to review code on both sides.. Dale ----- "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> wrote: | ok probably because we could not check all the code unfortunately. | So changes between 3.9 and pharo may have been supplanted by the | closure changes. | | On Apr 4, 2009, at 6:39 PM, Dale Henrichs wrote: | | > I've started taking a look at the problem reported by Michael | Roberts. | > | > I got slightly different misbehavior using the 10259- | > ClosureBootstrap download on linux than reported by Michael, but in | | > checking things out I discovered that the code in the Debugger for | | > the *Core* downloads is different from the *dev* downloads. | > | > For example the source for Debugger>>selectedMessageName in the | > *Core* image (10259-ClosureBootstrap) is: | > selectedMessageName | > "Answer the message selector of the currently selected context. | > If the method is unbound we can still usefully answer its old | > selector." | > | > | selector | | > selector := self selectedContext methodSelector. | > ^(selector ~~ self selectedContext method selector | > and: [selector beginsWith: 'DoIt']) | > ifTrue: [self selectedContext method selector] | > ifFalse: [selector] | > | > and I get a DNU for #methodSelector. On the other hand in the *dev* | | > image (pharo0.1-10259dev09.03.3) the source is: | > selectedMessageName | > "Answer the message selector of the currently selected context." | > | > ^self selectedContext selector | > | > When I looked at the Pharo0.1Core-10259 image, the source is | > identical to the pharo0.1-10259dev09.03.3, so the Closure changeset | | > is apparently introducing some 'unwanted' changes to the Debugger | > (and perhaps elsewhere?). | > | > Dale | > | > _______________________________________________ | > Pharo-project mailing list | > Pharo-project(a)lists.gforge.inria.fr | > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project | >

April 5, 2009

Re: [Pharo-project] old debugger bugs and the Closure changes

by Michael Roberts

I started a small diagnosis on the issue tracker. Some of the changes are intentional. The closure image introduces a layer of indirection to get out the offsets for highlighting code. I think the next place to check is the compiler/ method changes since I think that's where they come from but I need to check. Mike On 4/4/09, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > ok probably because we could not check all the code unfortunately. > So changes between 3.9 and pharo may have been supplanted by the > closure changes. > > On Apr 4, 2009, at 6:39 PM, Dale Henrichs wrote: > >> I've started taking a look at the problem reported by Michael Roberts. >> >> I got slightly different misbehavior using the 10259- >> ClosureBootstrap download on linux than reported by Michael, but in >> checking things out I discovered that the code in the Debugger for >> the *Core* downloads is different from the *dev* downloads. >> >> For example the source for Debugger>>selectedMessageName in the >> *Core* image (10259-ClosureBootstrap) is: >> selectedMessageName >> "Answer the message selector of the currently selected context. >> If the method is unbound we can still usefully answer its old >> selector." >> >> | selector | >> selector := self selectedContext methodSelector. >> ^(selector ~~ self selectedContext method selector >> and: [selector beginsWith: 'DoIt']) >> ifTrue: [self selectedContext method selector] >> ifFalse: [selector] >> >> and I get a DNU for #methodSelector. On the other hand in the *dev* >> image (pharo0.1-10259dev09.03.3) the source is: >> selectedMessageName >> "Answer the message selector of the currently selected context." >> >> ^self selectedContext selector >> >> When I looked at the Pharo0.1Core-10259 image, the source is >> identical to the pharo0.1-10259dev09.03.3, so the Closure changeset >> is apparently introducing some 'unwanted' changes to the Debugger >> (and perhaps elsewhere?). >> >> Dale >> >> _______________________________________________ >> 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 >

April 4, 2009

Re: [Pharo-project] old debugger bugs and the Closure changes

by StÃ©phane Ducasse

ok probably because we could not check all the code unfortunately. So changes between 3.9 and pharo may have been supplanted by the closure changes. On Apr 4, 2009, at 6:39 PM, Dale Henrichs wrote: > I've started taking a look at the problem reported by Michael Roberts. > > I got slightly different misbehavior using the 10259- > ClosureBootstrap download on linux than reported by Michael, but in > checking things out I discovered that the code in the Debugger for > the *Core* downloads is different from the *dev* downloads. > > For example the source for Debugger>>selectedMessageName in the > *Core* image (10259-ClosureBootstrap) is: > selectedMessageName > "Answer the message selector of the currently selected context. > If the method is unbound we can still usefully answer its old > selector." > > | selector | > selector := self selectedContext methodSelector. > ^(selector ~~ self selectedContext method selector > and: [selector beginsWith: 'DoIt']) > ifTrue: [self selectedContext method selector] > ifFalse: [selector] > > and I get a DNU for #methodSelector. On the other hand in the *dev* > image (pharo0.1-10259dev09.03.3) the source is: > selectedMessageName > "Answer the message selector of the currently selected context." > > ^self selectedContext selector > > When I looked at the Pharo0.1Core-10259 image, the source is > identical to the pharo0.1-10259dev09.03.3, so the Closure changeset > is apparently introducing some 'unwanted' changes to the Debugger > (and perhaps elsewhere?). > > Dale > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 4, 2009