- Pharo-dev - lists.pharo.org

Re: [Pharo-project] newinspector?

by Adrian Lienhard

Great, thanks! Adrian On Dec 4, 2009, at 13:07 , Frederic Pluquet wrote: > Hello Adrian, > > I deleted the Elements child in CompiledMethod (it had no sense in > CompiledMethod). > I added also added a literals child to inspect CompiledMethod literals > easily. > > FrÃ©d > ---- > FrÃ©dÃ©ric Pluquet > UniversitÃ© Libre de Bruxelles (ULB) > Assistant > http://www.ulb.ac.be/di/fpluquet > > > On Thu, Dec 3, 2009 at 9:44 PM, Adrian Lienhard <adi(a)netstyle.ch> > wrote: > >> Hi Frederic, >> >> I just run into a problem: clicking on Elements of a NewInspector >> on a >> CompiledMethod gives an error: 'CompiledMethods may only be created >> with >> newMethod:header:' >> >> Shall I create an issue in the Pharo tracker? >> >> Adrian >> >> >> On Nov 26, 2009, at 19:40 , Adrian Lienhard wrote: >> >> Just yesterday, I asked Frederic to remove the class and method >>> entries that add a lot of the noise and are most often not needed. >>> He >>> committed a new version with these changes. >>> >>> But from Stef's analysis it seems there is a bit more needed to make >>> this inspector fly... And a really good inspector is key! >>> >>> Another item to add to Stef's list: what is the point of the item >>> "Keys"? I can see the keys of the dictionary already by opening >>> "Elements". So this seems superfluous. >>> >>> I wonder why inspecting a dictionary could not be reduced to the >>> information that is actually of interest, namely the keys and their >>> values. So when opening a dictionary, the subtree would directly >>> display the keys in the left pane (no array, tally, Keys, Elements). >>> If a key is selected, its value is printed in the right pane. >>> Expanding a key would dive into its associated value. Actually, I >>> think what I described here is more or less the behavior of the old >>> explore tool. >>> >>> Cheers, >>> Adrian >>> >>> >>> On Nov 26, 2009, at 18:39 , StÃ©phane Ducasse wrote: >>> >>> Hi guys >>>> >>>> again I did a demo of smalltalk and the newInspecotr got in my way. >>>> I tried to analyze what did not work: >>>> - apparently the refresh does not work. Does change in >>>> instance >>>> variables get refreshed in the inspector? >>>> >>>> I try to understand what get in my way in general. >>>> - when an object has few instance variable I think that it >>>> is lost >>>> in the sea of trees. >>>> >>>> - I think that the |> class is not useful at the top level. >>>> May be just having Class: and the class Name is enough no >>>> need for >>>> the |> >>>> May be the Class : ByteString should appear after the >>>> Elements: >>>> >>>> - the |> methods to be useful should be sorted by category >>>> >>>> in the screenshot >>>> Why do I see the instance variable of the dictionary >>>> (array and >>>> tally) I find that confusing? >>>> Because I get elements and at the same time the instance >>>> variables. >>>> >>>> I do not understand why some lines are bold and other blue >>>> >>>> When we click on connectInfo I see on the right pane >>>> - size : 5 >>>> [#host] : a SocketAddress (size: 24) >>>> [#loginMethod] : #zork >>>> [#password] : nil >>>> [#port] : 110 >>>> [#user] : 'stephane.ducasse' >>>> But I cannot modify anything. >>>> >>>> What is the point to have Elements expanded in the left >>>> pane when >>>> I >>>> get the contents by clicking on the instance >>>> variable and getting the contents on the right. >>>> >>>> Then Keys should probably close to Elements. >>>> >>>> I do not see the point to have |> for individual method >>>> I do not understand why we see Elements and ByteCode >>>> I get a DNU when I click on Elements of a method BTW >>>> >>>> >>>> <Screen shot 2009-11-26 at 6.14.31 >>>> PM.png>_______________________________________________ >>>> 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. 4, 2009

Re: [Pharo-project] How do I know which issues are resolved in each new release?

by Marcus Denker

Hello, Yes, we should improve information on what changed.... I would want to have a changelog for any image that is downloaded. And we should use the Blog. And Twitter. And. And. We will do all that, but not today :-) Marcus On Dec 1, 2009, at 3:19 PM, Tim Mackinnon wrote: > So can can I see this somewhere? I was expecting on the download page there would be a link to show me what changes have been fixed in that release. ( even a list so that I can filter on 9.11.4 - and then see that #11504,11523... is included etc. would be fine). > > Maybe in the future there might be some way to do something like the Trac guys do - where they have the convention that their SVN commit comments (I guess this could be MCZ comments or naming convention) include the ticket id number of the bug/feature they are fixing - they can then generate a list of whats in a build - and when you do a release, whats in the release. e.g. look at the following page on their website: http://trac.edgewall.org/wiki/TracL10N (press the edit button and see how they are querying out the outstanding tickets for a release). Is this what Mason and the things mentioned do? > > The best system I have seen running was Trac with Hudson - however all these things are doable in any system (the ones mentioned here sound interesting). > > I would just like to see something concrete so I can try and help in some way to make sure that V1.0 is stable and as bug free as possible. > > > Tim > > On 1 Dec 2009, at 12:35, StÃ©phane Ducasse wrote: > >> this is what we do also. >> >> On Dec 1, 2009, at 2:03 AM, Dale Henrichs wrote: >> >>> In the google issues list, one can add a column called "Fixed" and a version can be supplied for the value of that field (like Version or Milestone) when the bug is fixed ... I think this is what Tim is getting at. I've just done this for Metacello, since I think it is a good idea:) >>> >>> Dale >>> ----- "Tim Mackinnon" <tamackinnon(a)gmail.com> wrote: >>> >>> | Hi guys - I noticed there was a new 9.11.4 release since buenos aires >>> | - and I got to wondering what issues have been resolved in it (as I am >>> | trying to follow Pharo by example - I am trying to test out features >>> | to see if they work as I progress through the material). >>> | >>> | Anyway - is there a list of issues fixed marked against each new >>> | version? I can see the list at: >>> | http://code.google.com/p/pharo/issues/list# - but it doesn't list any >>> | build numbers - just milestone 1.1? >>> | >>> | Tim >>> | _______________________________________________ >>> | 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 4, 2009

Re: [Pharo-project] about keys returning a set

by Lukas Renggli

> Even with these numbers I cannot evaluate what could be a slowdown/pseed up > impact on the complete system. I imgain that the ietration slow down should be minimal > and compensated by the creation speed up. Yeah, the iteration slowdown should be minimal of using Set vs. Array. What I think is more critical that you change the semantics of the returned data-structure. That could not only break clients, but also their expectations towards performance. I find interesting that most sets are almost empty. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Dec. 4, 2009

[Pharo-project] christmas coding parties?

by StÃ©phane Ducasse

Hi all I would like to organize a couple of coding parties around christmas. The 18 of december? is one possibility (even if I can only start at 11h). So if some of you are close to lille during holidays we could have fun coding together. I would like to organize a moose day too. I want to code what I have in mind with CAnalyzer and mondrian. Stef

Dec. 4, 2009

Re: [Pharo-project] about keys returning a set

by StÃ©phane Ducasse

this is interesting to see that this is still a guess game. Even with these numbers I cannot evaluate what could be a slowdown/pseed up impact on the complete system. I imgain that the ietration slow down should be minimal and compensated by the creation speed up. May be in the future when system will have a better knowledge of themselves we may end up having better tools... > I posted these numbers a while ago. > > In my image the average length of a Dictionary is 10, the average > length of a Set is 1.2. > > Lukas > > > 2009/12/4 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> I would be curious to see the average length of dictionary keys (except Smalltalk) >> and see the performance penalty between set and array for the do: >> >> Stef >> >>> 2009/12/4 Lukas Renggli <renggli(a)gmail.com>: >>>> Actually the code can be further optimized: >>>> >>>> Dictionary>>keys >>>> "Answer a Set containing the receiver's keys." >>>> >>>> | result container | >>>> result := Set basicNew setTally: tally array: array copy. >>>> container := result array. >>>> 1 to: container size do: [ :index | >>>> (container at: index) >>>> ifNotNil: [ :assoc | container at: index put: assoc key ] ]. >>>> ^ result >>>> >>>> This is roughly 22 times faster than the current implementation, and 5 >>>> times faster than the squeak implementation. >>>> >>>> The system doesn't seem to break with this change :-) >>>> >>>> Lukas >>>> >>> >>> Yes Levente considered this implementation as keysAsSet, but did not >>> pushed it in trunk so far. >>> You must also consider that each further usage of a Set will add a >>> performance penalty vs an Array, especially do: >>> >>> Nicolas >>> >>>> 2009/12/4 Lukas Renggli <renggli(a)gmail.com>: >>>>> I wonder if ever something along the following lines was considered? >>>>> >>>>> Dictionary>>keys >>>>> "Answer a Set containing the receiver's keys." >>>>> >>>>> | result | >>>>> result := Set basicNew. >>>>> result setTally: tally array: (array collect: [ :each | >>>>> each isNil ifFalse: [ each key ] ]). >>>>> ^ result >>>>> >>>>> This returns a Set, so it wouldn't break any semantics. In my >>>>> benchmark this is roughly 8x faster than the current implementation, >>>>> and 2x faster than the optimized Squeak implementation. >>>>> >>>>> The drawback is that it makes some heavy assumptions on the internal >>>>> structure of Dictionary, Association and Set. >>>>> >>>>> Lukas >>>>> >>>>> 2009/12/4 Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no>: >>>>>> A small addendum ;) >>>>>> On 03.12.2009 22:13, Nicolas Cellier wrote: >>>>>>> 3) identify thise sending a potential inefficient message (includes:) >>>>>>> insert keys asSet in this case (only if includes: is in a loop!) >>>>>>> >>>>>>> >>>>>> 3b. If the keys collection isn't used for anything else, change to use >>>>>> includesKey: instead. >>>>>> >>>>>> Cheers, >>>>>> Henry >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >> > > > > -- > 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. 4, 2009

Re: [Pharo-project] getting rid of Symbol >> new: ?

by Adrian Lienhard

Hi Sheri, Sounds ok to make new: raise an exception if you adjust the tests (and any code that exists in the image using new: (but I assume there is none)). However, the actual reason why you get multiple same symbols after loading a segment likely is unrelated to ByteSymbol class>>new:. I guess it is because when creating the segment you do not hold onto these symbols. Like this they do not get into the outPointers ref stream but in the bytearray. When installing the segment again, with same symbols existing in the image already, then you get duplicates. The "right way" to do this is to strongly hold onto all symbols when creating a segment. See #createSegmentFrom:. You can reproduce this problem by commenting out the first line of #createSegmentFrom: and running #testSymbols. Let us know how it goes... BTW, Mariano is also writing ImageSegment tests, so maybe you want to join forces (or maybe he already is the colleague you mentioned?). Cheers, Adrian On Dec 3, 2009, at 23:10 , StÃ©phane Ducasse wrote: >> From: Sheridan Mahoney <sheridan(a)sheridan-mahoney.com> >> Date: December 3, 2009 11:04:19 PM GMT+01:00 >> To: pharo-project-bounces(a)lists.gforge.inria.fr >> Subject: Re: getting rid of Symbol >> new: ? >> Reply-To: sheridan(a)sheridan-mahoney.com >> >> >> A colleague and I are investigating the ImageSegment class and its >> methods, we came across an issue I would like to get external >> opinions on. Newbie alert, BTW (at least one of us, no names >> mentioned...). Also, this is not a problem that will affect many >> users, but it is familiarizing us with the check-in process, >> slices, etc. While working on ImageSegment tests, we discovered a >> problem on trying to load segments that had Symbols in the root >> array. It is possible to create 2 ByteSymbols with the same >> sequence of characters. :( In trying to track down how this is >> possible, we came across a side issue, that ByteSymbol new: had >> the capacity to create multiple new ByteSymbols with the same >> number of nil characters (as in, initialized with nil). We want to >> dissallow Symbol new: , which would cause people to use one of >> the nicer methods for Symbol/ByteSymbol creation (namely, one which >> checks that the sequence of characters doesn't already exist, as >> part of the creation process). We have a fix we want to check in, >> but currently it breaks a test case in the SymbolTest class, which >> is checking that new: works. We also changed the intern: >> method on the class side of Symbol to use basicNew: instead >> of new: . Are there reasons to keep 'Symbol new:' , that >> outweigh the reasons to get rid of it? >> Many thanks, >> and Cheers, >> Sheri Mahoney > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 4, 2009

Re: [Pharo-project] allowUnderscoreAssignment is not functional

by StÃ©phane Ducasse

what are the pros and cons? I would like to avoid to have _ in the code but this is good to let people load their code. So I would keep it and make it work. Stef On Dec 4, 2009, at 9:40 AM, Alain Plantec wrote: > Hi all, > maybe I've missed something but whatever value is set to this preference, > the result is that underscore is always allowed. > > Note that it is used by the scanner: > Scanner>>xUnderscore > Preferences allowUnderscoreAssignment ifFalse:[^self xIllegal]. > self step. > tokenType := #leftArrow. > ^token := #':=' > > The question behind is do we keep this preference ? > > Cheers > Alain > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 4, 2009

Re: [Pharo-project] about keys returning a set

by Tudor Girba

Using this script: (Dictionary allInstances inject: 0 into: [ :r :e | r + e size ]) / Dictionary allInstances size asFloat I get 14.23 in my image. Using this script: (Set allInstances inject: 0 into: [ :r :e | r + e size ]) / Set allInstances size asFloat I get 0.49 Cheers, Doru On 4 Dec 2009, at 11:49, Lukas Renggli wrote: > I posted these numbers a while ago. > > In my image the average length of a Dictionary is 10, the average > length of a Set is 1.2. > > Lukas > > > 2009/12/4 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> I would be curious to see the average length of dictionary keys >> (except Smalltalk) >> and see the performance penalty between set and array for the do: >> >> Stef >> >>> 2009/12/4 Lukas Renggli <renggli(a)gmail.com>: >>>> Actually the code can be further optimized: >>>> >>>> Dictionary>>keys >>>> "Answer a Set containing the receiver's keys." >>>> >>>> | result container | >>>> result := Set basicNew setTally: tally array: array copy. >>>> container := result array. >>>> 1 to: container size do: [ :index | >>>> (container at: index) >>>> ifNotNil: [ :assoc | container at: index >>>> put: assoc key ] ]. >>>> ^ result >>>> >>>> This is roughly 22 times faster than the current implementation, >>>> and 5 >>>> times faster than the squeak implementation. >>>> >>>> The system doesn't seem to break with this change :-) >>>> >>>> Lukas >>>> >>> >>> Yes Levente considered this implementation as keysAsSet, but did not >>> pushed it in trunk so far. >>> You must also consider that each further usage of a Set will add a >>> performance penalty vs an Array, especially do: >>> >>> Nicolas >>> >>>> 2009/12/4 Lukas Renggli <renggli(a)gmail.com>: >>>>> I wonder if ever something along the following lines was >>>>> considered? >>>>> >>>>> Dictionary>>keys >>>>> "Answer a Set containing the receiver's keys." >>>>> >>>>> | result | >>>>> result := Set basicNew. >>>>> result setTally: tally array: (array collect: [ :each | >>>>> each isNil ifFalse: [ each key ] ]). >>>>> ^ result >>>>> >>>>> This returns a Set, so it wouldn't break any semantics. In my >>>>> benchmark this is roughly 8x faster than the current >>>>> implementation, >>>>> and 2x faster than the optimized Squeak implementation. >>>>> >>>>> The drawback is that it makes some heavy assumptions on the >>>>> internal >>>>> structure of Dictionary, Association and Set. >>>>> >>>>> Lukas >>>>> >>>>> 2009/12/4 Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no>: >>>>>> A small addendum ;) >>>>>> On 03.12.2009 22:13, Nicolas Cellier wrote: >>>>>>> 3) identify thise sending a potential inefficient message >>>>>>> (includes:) >>>>>>> insert keys asSet in this case (only if includes: is in a loop!) >>>>>>> >>>>>>> >>>>>> 3b. If the keys collection isn't used for anything else, change >>>>>> to use >>>>>> includesKey: instead. >>>>>> >>>>>> Cheers, >>>>>> Henry >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >> > > > > -- > 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 -- www.tudorgirba.com "No matter how many recipes we know, we still value a chef."

Dec. 4, 2009

Re: [Pharo-project] about keys returning a set

by Lukas Renggli

I posted these numbers a while ago. In my image the average length of a Dictionary is 10, the average length of a Set is 1.2. Lukas 2009/12/4 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > I would be curious to see the average length of dictionary keys Â (except Smalltalk) > and see the performance penalty between set and array for the do: > > Stef > >> 2009/12/4 Lukas Renggli <renggli(a)gmail.com>: >>> Actually the code can be further optimized: >>> >>> Dictionary>>keys >>> Â Â Â Â "Answer a Set containing the receiver's keys." >>> >>> Â Â Â Â | result container | >>> Â Â Â Â result := Set basicNew setTally: tally array: array copy. >>> Â Â Â Â container := result array. >>> Â Â Â Â 1 to: container size do: [ :index | >>> Â Â Â Â Â Â Â Â (container at: index) >>> Â Â Â Â Â Â Â Â Â Â Â Â ifNotNil: [ :assoc | container at: index put: assoc key ] ]. >>> Â Â Â Â ^ result >>> >>> This is roughly 22 times faster than the current implementation, and 5 >>> times faster than the squeak implementation. >>> >>> The system doesn't seem to break with this change :-) >>> >>> Lukas >>> >> >> Yes Levente considered this implementation as keysAsSet, but did not >> pushed it in trunk so far. >> You must also consider that each further usage of a Set will add a >> performance penalty vs an Array, especially do: >> >> Nicolas >> >>> 2009/12/4 Lukas Renggli <renggli(a)gmail.com>: >>>> I wonder if ever something along the following lines was considered? >>>> >>>> Dictionary>>keys >>>> Â Â Â Â "Answer a Set containing the receiver's keys." >>>> >>>> Â Â Â Â | result | >>>> Â Â Â Â result := Set basicNew. >>>> Â Â Â Â result setTally: tally array: (array collect: [ :each | >>>> Â Â Â Â Â Â Â Â each isNil ifFalse: [ each key ] ]). >>>> Â Â Â Â ^ result >>>> >>>> This returns a Set, so it wouldn't break any semantics. In my >>>> benchmark this is roughly 8x faster than the current implementation, >>>> and 2x faster than the optimized Squeak implementation. >>>> >>>> The drawback is that it makes some heavy assumptions on the internal >>>> structure of Dictionary, Association and Set. >>>> >>>> Lukas >>>> >>>> 2009/12/4 Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no>: >>>>> A small addendum ;) >>>>> On 03.12.2009 22:13, Nicolas Cellier wrote: >>>>>> 3) identify thise sending a potential inefficient message (includes:) >>>>>> insert keys asSet in this case (only if includes: is in a loop!) >>>>>> >>>>>> >>>>> 3b. If the keys collection isn't used for anything else, change to use >>>>> includesKey: instead. >>>>> >>>>> Cheers, >>>>> Henry >>>>> >>>>> _______________________________________________ >>>>> 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 > -- Lukas Renggli http://www.lukas-renggli.ch

Dec. 4, 2009

Re: [Pharo-project] allowUnderscoreAssignment is not functional

by Lukas Renggli

Yes, that we noticed too. This method is never called. Lukas 2009/12/4 Alain Plantec <alain.plantec(a)free.fr>: > Hi all, > maybe I've missed something but whatever value is set to this preference, > the result is that underscore is always allowed. > > Note that it is used by the scanner: > Scanner>>xUnderscore > Â Â Preferences allowUnderscoreAssignment ifFalse:[^self xIllegal]. > Â Â self step. > Â Â tokenType := #leftArrow. > Â Â ^token := #':=' > > The question behind is do we keep this preference ? > > Cheers > Alain > > _______________________________________________ > 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. 4, 2009