November 2008 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Nitpicking regarding spelling. Sorry

by StÃ©phane Ducasse

but now I would say carve etoy up informal slash someone with a knife or other sharp object. carve etoy up divide something ruthlessly into separate areas. On Nov 15, 2008, at 8:03 AM, StÃ©phane Ducasse wrote: > > On Nov 15, 2008, at 1:37 AM, Matthew Fulmer wrote: > >> On Fri, Nov 14, 2008 at 10:18:30PM +0100, St?phane Ducasse wrote: >>> Hi all >>> >>> I continued to curved out etoy. >> >> Just curious. Do you mean you are "carving" out etoys? curving >> seems to be the wrong word, but you keep using it > > Apparently > So this is carving > to carve something out > take something from a larger whole, esp. with difficulty > if fits perfectly. >> >> -- >> Matthew Fulmer -- http://mtfulmer.wordpress.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 >

Nov. 15, 2008

Re: [Pharo-project] Nitpicking regarding spelling. Sorry

by StÃ©phane Ducasse

On Nov 15, 2008, at 1:37 AM, Matthew Fulmer wrote: > On Fri, Nov 14, 2008 at 10:18:30PM +0100, St?phane Ducasse wrote: >> Hi all >> >> I continued to curved out etoy. > > Just curious. Do you mean you are "carving" out etoys? curving > seems to be the wrong word, but you keep using it Apparently So this is carving to carve something out take something from a larger whole, esp. with difficulty if fits perfectly. > > -- > Matthew Fulmer -- http://mtfulmer.wordpress.com/ > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Nov. 15, 2008

Re: [Pharo-project] String and Symbol comparison

by StÃ©phane Ducasse

this number is striking may be there is optimization crying to be done. #numberOfCategoryOfElement:->876104 #directoryContentsFor:->111045 On Nov 14, 2008, at 9:56 AM, Adrian Lienhard wrote: > I traced all the senders of #= where either the receiver is a string > and the argument is a symbol and vice versa. I run this for all > tests (the number indicates the number of occurrences). > > ((IdentityDictionary new) add: (#inputUpTo:nestedOn:errorMessage:- > >57); add: (#assertVersionInfo:matches:->8); add: (#testChanges->1); > add: (#=->9); add: (#pragmaStatement->214); add: > (#grabAddressWithRoute->11); add: (#update:->3); add: > (#testDateAndTimes->156); add: (#numberOfCategoryOfElement:- > >876104); add: (#basicRemoveElement:->179302); add: > (#actionSelector:->128); add: (#testEncodingName->1); add: > (#testAccessing->1); add: (#grabAddresses->12); add: > (#nameForVer:base:->2); add: (#testDayOfWeek->3); add: > (#scanForPreviousVersion->10); add: (#assertDict:matchesInfo:->4); > add: (#testWeekday->2); add: (#testLoadAndUnload->1); add: > (#blockSelectCallName:->3561); add: (#grabGroupAddress->15); add: > (#matchToken:->221); add: (#blockSelectModuleName:->5409); add: > (#hasEqualElements:->17); add: (#testRevertOverrideMethod->1); add: > (#visibleClasses->553); add: (#category:matches:->109854); add: > (#borderColor:->256); add: (#testMethodsWithEnabledCallX->2); add: > (#pragmaLiteral->3); add: (#directoryContentsFor:->111045); add: > (#versionForName:in:->5); add: (#indexOf:startingAt:ifAbsent:- > >29695); add: (#testRemoveFromSystem->1); add: > (#fileOutCategory:on:moveSource:toFile:->18); add: (#testMonth->3); > add: (#testNameOfMonth->2); add: (#''~=''->125513); add: (#includes:- > >524976); add: (#testCreation->1); add: (#methodsForSelectedProtocol- > >26); add: (#testPartiallyRevertOverrideMethod->1); add: > (#denyAListHasSelection:->4); add: (#grabBasicAddress->3); add: > (#classify:under:suppressIfDefault:->71); add: > (#filterFileNames:forVersionNamed:->411); add: (#remove:ifAbsent:- > >5512); add: (#methodsForSelectedClass->2410); add: > (#testMethodsWithDisabledCallX->1); add: (#classCommentString->45); > add: (#scanFor:->31750); add: (#piece->126); add: (#testSetUp->2); > yourself) > > This gives a rough idea of what code needs to be reviewed and > possibly adapted. > > Adrian > > On Nov 14, 2008, at 09:24 , StÃ©phane Ducasse wrote: > >> yes! >> may be create a tag for m1.1 >> >> >> On Nov 14, 2008, at 9:13 AM, Lukas Renggli wrote: >> >>> I created: >>> >>> http://code.google.com/p/pharo/issues/detail?id=331 >>> http://code.google.com/p/pharo/issues/detail?id=332 >>> >>> It would be useful to be able to tag issues for specific milestones. >>> >>> Lukas >>> >>> On Fri, Nov 14, 2008 at 9:05 AM, Lukas Renggli <renggli(a)gmail.com> >>> wrote: >>>> On Fri, Nov 14, 2008 at 8:57 AM, StÃ©phane Ducasse >>>> <stephane.ducasse(a)inria.fr> wrote: >>>>> I should say that I always like the fact that >>>>>> >>>>>> 'abc' = #abc --> false >>>>>> #abc = 'abc' --> false >>>>> >>>>> Because a symbol and a string are different to my eyes. >>>>> But when there was the discussion a while back >>>>> I understood that a symbol is a kind of string. >>>>> >>>>> Now how can we make progress on that point >>>>> - evaluate the risks >>>>> - write some tests for strings and symbols >>>>> - give a try >>>>> - but do that for pharo 1.1 :) >>>> >>>> Ok, I will file an issue so that we don't forget. >>>> >>>> Along the same lines is that strings implement the complete >>>> arithmetic >>>> protocol. In my opinion that should go away as well: it is a >>>> source of >>>> errors and portability issues. Furthermore it looks really >>>> unprofessional: >>>> >>>> '1' + '2' --> '3' (in Pharo/Squeak) >>>> >>>> I guess this is some eToy remnant. >>>> >>>> Lukas >>>> >>>> >>>> >>>> >>>>> stef >>>>> >>>>> On Nov 14, 2008, at 7:46 AM, Lukas Renggli wrote: >>>>> >>>>>> I want to open this for discussion: >>>>>> >>>>>> In all Smalltalk dialects the following expressions evaluate to >>>>>> false: >>>>>> >>>>>> 'abc' = #abc --> false >>>>>> #abc = 'abc' --> false >>>>>> >>>>>> This means a String and a Symbol is never the same thing, even >>>>>> if they >>>>>> contain the same characters. In Squeak/Pharo this is different >>>>>> though >>>>>> (at least this is symmetrical, pre 3.9 this wasn't even >>>>>> symmetrical): >>>>>> >>>>>> 'abc' = #abc --> true >>>>>> #abc = 'abc' --> true >>>>>> >>>>>> Unfortunately this difference makes writing portable code that >>>>>> deals >>>>>> with symbols and strings a huge pain. And it is hard to test, >>>>>> debug >>>>>> and find those kind of problems. >>>>>> >>>>>> I wonder if it would be possible to change that behavior in >>>>>> Squeak to >>>>>> match the other Smalltalk implementations? I guess this would >>>>>> break >>>>>> some code, but at least this problem would then be gone forever. >>>>>> >>>>>> Lukas >>>>>> >>>>>> -- >>>>>> 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 >>>> >>> >>> >>> >>> -- >>> 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Nov. 15, 2008

[Pharo-project] Nitpicking regarding spelling. Sorry

by Matthew Fulmer

On Fri, Nov 14, 2008 at 10:18:30PM +0100, St?phane Ducasse wrote: > Hi all > > I continued to curved out etoy. Just curious. Do you mean you are "carving" out etoys? curving seems to be the wrong word, but you keep using it -- Matthew Fulmer -- http://mtfulmer.wordpress.com/

Nov. 15, 2008

[Pharo-project] [ANN] new update

by StÃ©phane Ducasse

Hi all I continued to curved out etoy. If you want to follow my progress or participate http://code.google.com/p/pharo/wiki/CurrentlyWorkingOn?ts=1226697010&update… Now I stop for tonight since I get "nausea" after reading too funny much code. Stef

Nov. 14, 2008

Re: [Pharo-project] Wrapper bug (is ByteSurgeon the cause of it ?)

by StÃ©phane Ducasse

In 3.9 you can wrap it with bytesurgeon? Stef On Nov 14, 2008, at 9:16 PM, Antoine Marot wrote: > For now it works fine on other methods. That's why I don't get what > the problem might be. > > Unfortunately, my project requires to be able to wrap any method and > to instrument it with ByteSurgeon. > > > Antoine > > > Le 14-nov.-08 Ã 20:57, StÃ©phane Ducasse a Ã©crit : > >> can you try on something less sensitive than copyFrom:to: to debug >> it? >> >> Stef >> >> On Nov 14, 2008, at 4:59 PM, Antoine Marot wrote: >> >>> Hi all, >>> >>> I have a very strange bug when I use method wrappers. >>> >>> Here is my wrapper code (actually it does nothing but calling the >>> method) : >>> >>> ProtoObject variableSubclass: #Wrapper >>> instanceVariableNames: 'compiledMethod' >>> classVariableNames: '' >>> poolDictionaries: '' >>> category: 'Wrapper-Core' >>> >>> Wrapper>>#doesNotUnderstand: aMessage >>> ^aMessage sendTo: compiledMethod >>> >>> Wrapper>>#run: aSymbol with: arguments in: rec >>> ^rec >>> withArgs: arguments >>> executeMethod: compiledMethod >>> >>> Wrapper>>#compiledMethod: c >>> compiledMethod:=c. >>> ^self >>> >>> >>> Now I want to execute this : >>> >>> SequenceableCollection methodDict at: #copyFrom:to: put: (Wrapper >>> new compiledMethod: (SequenceableCollection>>#copyFrom:to:)). >>> >>> >>> It works fine with a new pharo-dev image. >>> But if I install ByteSurgeon before that, it crashes the VM if I >>> click on the workspace for instance. >>> >>> I just don't know what possibly happen, any help would be very >>> appreciated :) >>> >>> >>> Regards, >>> >>> Antoine >>> >>> ------ >>> Antoine Marot >>> Ph.D Student >>> UniversitÃ© Libre de Bruxelles >>> DÃ©partement d'Informatique >>> _______________________________________________ >>> 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Nov. 14, 2008

Re: [Pharo-project] Wrapper bug (is ByteSurgeon the cause of it ?)

by Antoine Marot

For now it works fine on other methods. That's why I don't get what the problem might be. Unfortunately, my project requires to be able to wrap any method and to instrument it with ByteSurgeon. Antoine Le 14-nov.-08 Ã 20:57, StÃ©phane Ducasse a Ã©crit : > can you try on something less sensitive than copyFrom:to: to debug it? > > Stef > > On Nov 14, 2008, at 4:59 PM, Antoine Marot wrote: > >> Hi all, >> >> I have a very strange bug when I use method wrappers. >> >> Here is my wrapper code (actually it does nothing but calling the >> method) : >> >> ProtoObject variableSubclass: #Wrapper >> instanceVariableNames: 'compiledMethod' >> classVariableNames: '' >> poolDictionaries: '' >> category: 'Wrapper-Core' >> >> Wrapper>>#doesNotUnderstand: aMessage >> ^aMessage sendTo: compiledMethod >> >> Wrapper>>#run: aSymbol with: arguments in: rec >> ^rec >> withArgs: arguments >> executeMethod: compiledMethod >> >> Wrapper>>#compiledMethod: c >> compiledMethod:=c. >> ^self >> >> >> Now I want to execute this : >> >> SequenceableCollection methodDict at: #copyFrom:to: put: (Wrapper >> new compiledMethod: (SequenceableCollection>>#copyFrom:to:)). >> >> >> It works fine with a new pharo-dev image. >> But if I install ByteSurgeon before that, it crashes the VM if I >> click on the workspace for instance. >> >> I just don't know what possibly happen, any help would be very >> appreciated :) >> >> >> Regards, >> >> Antoine >> >> ------ >> Antoine Marot >> Ph.D Student >> UniversitÃ© Libre de Bruxelles >> DÃ©partement d'Informatique >> _______________________________________________ >> 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

Nov. 14, 2008

Re: [Pharo-project] Wrapper bug (is ByteSurgeon the cause of it ?)

by StÃ©phane Ducasse

can you try on something less sensitive than copyFrom:to: to debug it? Stef On Nov 14, 2008, at 4:59 PM, Antoine Marot wrote: > Hi all, > > I have a very strange bug when I use method wrappers. > > Here is my wrapper code (actually it does nothing but calling the > method) : > > ProtoObject variableSubclass: #Wrapper > instanceVariableNames: 'compiledMethod' > classVariableNames: '' > poolDictionaries: '' > category: 'Wrapper-Core' > > Wrapper>>#doesNotUnderstand: aMessage > ^aMessage sendTo: compiledMethod > > Wrapper>>#run: aSymbol with: arguments in: rec > ^rec > withArgs: arguments > executeMethod: compiledMethod > > Wrapper>>#compiledMethod: c > compiledMethod:=c. > ^self > > > Now I want to execute this : > > SequenceableCollection methodDict at: #copyFrom:to: put: (Wrapper > new compiledMethod: (SequenceableCollection>>#copyFrom:to:)). > > > It works fine with a new pharo-dev image. > But if I install ByteSurgeon before that, it crashes the VM if I > click on the workspace for instance. > > I just don't know what possibly happen, any help would be very > appreciated :) > > > Regards, > > Antoine > > ------ > Antoine Marot > Ph.D Student > UniversitÃ© Libre de Bruxelles > DÃ©partement d'Informatique > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Nov. 14, 2008

[Pharo-project] Wrapper bug (is ByteSurgeon the cause of it ?)

by Antoine Marot

Hi all, I have a very strange bug when I use method wrappers. Here is my wrapper code (actually it does nothing but calling the method) : ProtoObject variableSubclass: #Wrapper instanceVariableNames: 'compiledMethod' classVariableNames: '' poolDictionaries: '' category: 'Wrapper-Core' Wrapper>>#doesNotUnderstand: aMessage ^aMessage sendTo: compiledMethod Wrapper>>#run: aSymbol with: arguments in: rec ^rec withArgs: arguments executeMethod: compiledMethod Wrapper>>#compiledMethod: c compiledMethod:=c. ^self Now I want to execute this : SequenceableCollection methodDict at: #copyFrom:to: put: (Wrapper new compiledMethod: (SequenceableCollection>>#copyFrom:to:)). It works fine with a new pharo-dev image. But if I install ByteSurgeon before that, it crashes the VM if I click on the workspace for instance. I just don't know what possibly happen, any help would be very appreciated :) Regards, Antoine ------ Antoine Marot Ph.D Student UniversitÃ© Libre de Bruxelles DÃ©partement d'Informatique

Nov. 14, 2008

Re: [Pharo-project] String and Symbol comparison

by Adrian Lienhard

I traced all the senders of #= where either the receiver is a string and the argument is a symbol and vice versa. I run this for all tests (the number indicates the number of occurrences). ((IdentityDictionary new) add: (#inputUpTo:nestedOn:errorMessage:- >57); add: (#assertVersionInfo:matches:->8); add: (#testChanges->1); add: (#=->9); add: (#pragmaStatement->214); add: (#grabAddressWithRoute->11); add: (#update:->3); add: (#testDateAndTimes->156); add: (#numberOfCategoryOfElement:->876104); add: (#basicRemoveElement:->179302); add: (#actionSelector:->128); add: (#testEncodingName->1); add: (#testAccessing->1); add: (#grabAddresses->12); add: (#nameForVer:base:->2); add: (#testDayOfWeek->3); add: (#scanForPreviousVersion->10); add: (#assertDict:matchesInfo:->4); add: (#testWeekday->2); add: (#testLoadAndUnload->1); add: (#blockSelectCallName:->3561); add: (#grabGroupAddress->15); add: (#matchToken:->221); add: (#blockSelectModuleName:->5409); add: (#hasEqualElements:->17); add: (#testRevertOverrideMethod->1); add: (#visibleClasses->553); add: (#category:matches:->109854); add: (#borderColor:->256); add: (#testMethodsWithEnabledCallX->2); add: (#pragmaLiteral->3); add: (#directoryContentsFor:->111045); add: (#versionForName:in:->5); add: (#indexOf:startingAt:ifAbsent:->29695); add: (#testRemoveFromSystem- >1); add: (#fileOutCategory:on:moveSource:toFile:->18); add: (#testMonth->3); add: (#testNameOfMonth->2); add: (#''~=''->125513); add: (#includes:->524976); add: (#testCreation->1); add: (#methodsForSelectedProtocol->26); add: (#testPartiallyRevertOverrideMethod->1); add: (#denyAListHasSelection:- >4); add: (#grabBasicAddress->3); add: (#classify:under:suppressIfDefault:->71); add: (#filterFileNames:forVersionNamed:->411); add: (#remove:ifAbsent:- >5512); add: (#methodsForSelectedClass->2410); add: (#testMethodsWithDisabledCallX->1); add: (#classCommentString->45); add: (#scanFor:->31750); add: (#piece->126); add: (#testSetUp->2); yourself) This gives a rough idea of what code needs to be reviewed and possibly adapted. Adrian On Nov 14, 2008, at 09:24 , StÃ©phane Ducasse wrote: > yes! > may be create a tag for m1.1 > > > On Nov 14, 2008, at 9:13 AM, Lukas Renggli wrote: > >> I created: >> >> http://code.google.com/p/pharo/issues/detail?id=331 >> http://code.google.com/p/pharo/issues/detail?id=332 >> >> It would be useful to be able to tag issues for specific milestones. >> >> Lukas >> >> On Fri, Nov 14, 2008 at 9:05 AM, Lukas Renggli <renggli(a)gmail.com> >> wrote: >>> On Fri, Nov 14, 2008 at 8:57 AM, StÃ©phane Ducasse >>> <stephane.ducasse(a)inria.fr> wrote: >>>> I should say that I always like the fact that >>>>> >>>>> 'abc' = #abc --> false >>>>> #abc = 'abc' --> false >>>> >>>> Because a symbol and a string are different to my eyes. >>>> But when there was the discussion a while back >>>> I understood that a symbol is a kind of string. >>>> >>>> Now how can we make progress on that point >>>> - evaluate the risks >>>> - write some tests for strings and symbols >>>> - give a try >>>> - but do that for pharo 1.1 :) >>> >>> Ok, I will file an issue so that we don't forget. >>> >>> Along the same lines is that strings implement the complete >>> arithmetic >>> protocol. In my opinion that should go away as well: it is a >>> source of >>> errors and portability issues. Furthermore it looks really >>> unprofessional: >>> >>> '1' + '2' --> '3' (in Pharo/Squeak) >>> >>> I guess this is some eToy remnant. >>> >>> Lukas >>> >>> >>> >>> >>>> stef >>>> >>>> On Nov 14, 2008, at 7:46 AM, Lukas Renggli wrote: >>>> >>>>> I want to open this for discussion: >>>>> >>>>> In all Smalltalk dialects the following expressions evaluate to >>>>> false: >>>>> >>>>> 'abc' = #abc --> false >>>>> #abc = 'abc' --> false >>>>> >>>>> This means a String and a Symbol is never the same thing, even >>>>> if they >>>>> contain the same characters. In Squeak/Pharo this is different >>>>> though >>>>> (at least this is symmetrical, pre 3.9 this wasn't even >>>>> symmetrical): >>>>> >>>>> 'abc' = #abc --> true >>>>> #abc = 'abc' --> true >>>>> >>>>> Unfortunately this difference makes writing portable code that >>>>> deals >>>>> with symbols and strings a huge pain. And it is hard to test, >>>>> debug >>>>> and find those kind of problems. >>>>> >>>>> I wonder if it would be possible to change that behavior in >>>>> Squeak to >>>>> match the other Smalltalk implementations? I guess this would >>>>> break >>>>> some code, but at least this problem would then be gone forever. >>>>> >>>>> Lukas >>>>> >>>>> -- >>>>> 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 >>> >> >> >> >> -- >> 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

Nov. 14, 2008