- Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] String and Symbol comparison

by StÃ©phane Ducasse

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 >

Nov. 14, 2008

Re: [Pharo-project] String and Symbol comparison

by Lukas Renggli

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

Nov. 14, 2008

Re: [Pharo-project] String and Symbol comparison

by StÃ©phane Ducasse

Yeap! Stef On Nov 14, 2008, at 9:10 AM, Michael Roberts wrote: > +1 on removing arithmetic protocol > > cheers, > Mike > > _______________________________________________ > 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] String and Symbol comparison

by Michael Roberts

+1 on removing arithmetic protocol cheers, Mike

Nov. 14, 2008

Re: [Pharo-project] String and Symbol comparison

by Lukas Renggli

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

Nov. 14, 2008

Re: [Pharo-project] String and Symbol comparison

by StÃ©phane Ducasse

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 :) 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 >

Nov. 14, 2008

[Pharo-project] String and Symbol comparison

by Lukas Renggli

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

Nov. 14, 2008