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

Re: [Pharo-project] [squeak-dev] Re: Menu Registries

by Andreas Raab

On 4/29/2010 3:21 AM, Alain Plantec wrote: > Andreas Raab a Ã©crit : >> On 4/28/2010 11:32 PM, StÃ©phane Ducasse wrote: >>> Good but what is your point? >> >> Compatibility and simplicity. > Come on Andreas, "simple" is not so much more precise than "cool" That comment deserves a more detailed exploration than I want to put into this message. You can find my response here: http://squeakingalong.wordpress.com/2010/04/30/measuring-simplicity/ > and I don't think that having: > > ------------------ > Editor class>>blinkingCursor > ^ BlinkingCursor ifNil: [ true ] > > EditorSetting class>>editorSettingsOn: aBuilder > <systemsettings> > (aBuilder setting: #blinkingCursor) > label:'Blinking Text Cursor') > parent: #Morphic; > target: Editor; description: 'When true, the text cursor will blink.' > ------------------- > > is so much more "complicated" than > > ------------------- > Editor class>>blinkingCursor > <preference: 'Blinking Text Cursor' > category: 'Morphic' > description: 'When true, the text cursor will blink.' > type: #Boolean> > ^ BlinkingCursor ifNil: [ true ] > ------------------- You're right, by itself it may not be "so much more complicated". But isn't this forgetting a few things? Like for example, that not only are you adding the extra method, but also an extra class and an extra package? This gets you from a single entity (the domain code) to four entities (the domain code, the builder method, class and package). In terms of both conceptual and interface simplicity that seems significant (and a dozen of messages in the builder all add to interface complexity). BTW, I want to point out something important here. I'm not saying your approach is "bad". Good and bad, black and white, are not categories that I use for evaluating software design. I leave that to the people with overly simplified views on software development ;-) There are only different trade-offs for different goals. Your approach is perfectly reasonable for a given set of goals and trade-offs. If there is a need to have specific fine-grained control over the UI to particular preferences, I would choose precisely the same approach - make a package with views for the values that I want to modify. It's a perfectly fine approach for such a set of goals. Moreover, "simplicity" isn't an absolute attribute of software. Simplicity is a tradeoff. It is often worthwhile to trade off simplicity, for example when adding valuable new features. So my claim here is not about "good" and "bad". My claim is this: 1. The approach in Squeak is measurably simpler than yours. It may not fit your goals, you may need a different approach, that's quite possible. But there are numbers we can put on things to compare them and if we put the numbers on then Squeak's approach is simpler. 2. Because of the difference in interface complexity, I expect Squeak's approach will be easier to support in the long term. There's no proof for that, but I think the claim is valid, and I will watch the future developments in both Pharo and Squeak with interest. 3. Your initial design choice of using a builder framework for preferences implied the later complexity. Because the approach requires adding non-domain code to core classes it creates pressure to put this code elsewhere and to package that code separately. It's a valuable lesson about the impact of early design choices. > You prefer UI+domain mixing, we prefer UI separated from domain. I'm missing something. What UI+domain mixing? There is no UI code in Squeak's preference tags. There is only domain code and a method tag for discovery of the preference. Only Pharo has UI (builder) code; there is no equivalent in Squeak's preference tags. > And yes, the SettingBrowser implementation could be improved. > I know, but I'm happy because it can be removed or remade > without any other consequence. > And compare it to the PreferenceBrowser ... I'm not certain what your point here is. I'm only talking about preference declaration, not about how the preference browser functions. PreferenceBrowser itself is reloadable in Squeak 4.1 and one of the packages that I customarily unload for creating smaller images, because I'm quite happy to set my preferences by sending message to objects directly :-) Cheers, - Andreas

April 30, 2010

Re: [Pharo-project] [NativeBoost] new win32 build available

by Igor Stasenko

On 30 April 2010 02:16, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Interesting. Â Scary<g> but interesting. Â At the risk of seeming obsessed with numerical analysis, is there a way to use this for callbacks? > Not yet. But i plan to add the callbacks support. > Bill > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

April 29, 2010

Re: [Pharo-project] [NativeBoost] new win32 build available

by Igor Stasenko

On 30 April 2010 01:54, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > Â On 29.04.2010 17:13, Igor Stasenko wrote: >> >> Core packages were broken, and were unable to load w/o errors. >> But now seems everything loads well. >> Use NBInstaller install. >> >> Thanks to Henrik for help! > > Here's a small example, as well as profile: > > SmallInteger >> nbFib > <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> > Â Â ^ NBNativeCodeGen methodAssembly: [:gen | > Â Â Â Â | loopStart proxy asm Â EAX EBX ECX | > Â Â Â Â asm := gen asm. > Â Â Â Â proxy := NBInterpreterProxy new asm: asm. > Â Â Â Â loopStart := asm uniqueLabelName: 'loopStart'. > > Â Â Â Â EAX := asm assembler reg0. > Â Â Â Â EBX := asm assembler reg3. > Â Â Â Â ECX := asm assembler reg1. > Â Â Â Â proxy receiver. > Â Â Â Â proxy integerValueOf: EAX. > > Â Â Â Â asm mov: EAX to: ECX; > Â Â Â Â Â Â Â Â mov: 0 to: EAX; > Â Â Â Â Â Â Â Â mov: 1 to: EBX; > Â Â Â Â Â Â Â Â label: loopStart; > Â Â Â Â Â Â Â Â add: EAX with: EBX; > Â Â Â Â Â Â Â Â xchg: EAX with: EBX; > Â Â Â Â Â Â Â Â "next three could be replaced by loopnz and a dec ECX before > loop, but loopnz isn't there yet" > Â Â Â Â Â Â Â Â dec: ECX; > Â Â Â Â Â Â Â Â cmp: ECX with: 1; > Â Â Â Â Â Â Â Â jg: loopStart. > > Â Â Â Â proxy positive32BitIntegerFor: EBX. > Â Â Â Â gen epilogue] > > SmallInteger >>fib > Â Â |tmp res| > Â Â tmp := 1. > Â Â res := 0. > Â Â 0 to: self -1 do: [:ix | |oldRes| > Â Â Â Â Â Â oldRes := res. > Â Â Â Â Â Â res := tmp + res. > Â Â Â Â Â Â tmp := oldRes.]. > Â Â ^res > > Neither work for negative integers, and nbFib overflows for 48, haven't > added largeInt creation logic :) > ohh.. you will be need more than just create large int. Since at 48 you will get past the size of register, you'll have to switch to different loop. And it will end up with quite complex assembler :) But if we leave the complexity aside, the thing is, that you can greatly optimize it comparing to smalltalk implementation. You can use stack, for keeping a variable-length big int during calculation. So, you will need to create a single final BigInt oop only when loop ends. > [1 to: 100000 do: [:ix | 47 fib]] timeToRun 361 > [1 to: 100000 do: [:ix | 47 nbFib]] timeToRun 21 > [1 to: 100000 do: [:ix | ]] timeToRun 2 > > Cheers, > Henry > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

April 29, 2010

Re: [Pharo-project] Legitimate syntax for # ... foo

by Nicolas Cellier

2010/4/29 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > On Thu, Apr 29, 2010 at 1:25 PM, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >> 2010/4/29 Eliot Miranda <eliot.miranda(a)gmail.com>: >> > >> > >> > On Thu, Apr 29, 2010 at 12:50 PM, Nicolas Cellier >> > <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >> >> >> I don't think any other st dialect would accept that syntax but Squeak. >> > >> > VisualWorks accepts it just fine. >> > # "hello" foo => #foo >> > # "hello" (foo # "hello" foo) => #(#foo #foo) >> > I think this is the way the language works. Â Relax. Â Celebrate its >> > weirdness. Â Don't sweat the petty stuff, pet the sweaty stuff: >> > >> > http://www.popsci.com/gadgets/article/2010-04/exclusive-making-elements-one… >> >> Maybe I should relax about comment anywhere, but these: >> >> [Compiler evaluate: '#( # 2 # -2 )'] on: Error do: [:exc | exc return: >> nil]. >> [Compiler evaluate: '# -2'] on: Error do: [:exc | exc return: nil]. >> [Compiler evaluate: '#-2'] on: Error do: [:exc | exc return: nil]. >> [Compiler evaluate: '#$a'] on: Error do: [:exc | exc return: nil]. >> [Compiler evaluate: '##(1##)1)'] on: Error do: [:exc | exc return: nil]. >> >> would all return nil in VW, not so in Squeak. >> Also, I mind the difference of first two in Squeak. >> That's hardly predictable and much too weird to my own taste... > > That's fair enough, but that's a different issue to there being allowable > whitespace between the literal hash and the literal. Â In any case, comparing > against VW is probably a sensible thing to do. > best > Eliot Here we go: fix at http://code.google.com/p/pharo/issues/detail?id=2371 Some tests from Lukas would be appreciated :) Nicolas >> >> Nicolas >> >> >> >> >> It's just how the parser/scanner works now, but It wouldn't break much >> >> code IMO if we stop supporting these weirdnesses. >> >> >> >> Nicolas >> >> >> >> 2010/4/29 Lukas Renggli <renggli(a)gmail.com>: >> >> > Actually I didn't have all the latest code loaded in the open image. >> >> > There is more, hold your breath: >> >> > >> >> > testSymbolNumbers >> >> > Â Â Â Â #(('#1' 1) ('#12' 12) ('#12.3' 12.3) ('# 1' 1) ('##1' 1) >> >> > ('#"bar"1' >> >> > 1)) do: [ :pair | >> >> > Â Â Â Â Â Â Â Â tree := RBParser parseExpression: pair first. >> >> > Â Â Â Â Â Â Â Â self assert: tree value = pair second. >> >> > Â Â Â Â Â Â Â Â self assert: tree start > 1. >> >> > Â Â Â Â Â Â Â Â self assert: tree stop = pair first size ] >> >> > >> >> > On 29 April 2010 21:12, Lukas Renggli <renggli(a)gmail.com> wrote: >> >> >>> # "helllooo" foo >> >> >>> >> >> >>> prints >> >> >>> #foo >> >> >>> >> >> >>> is this correct? >> >> >> >> >> >> Probably not, but the standard compiler accepts it. So I had to >> >> >> patch >> >> >> the parser of the refactoring engine to accept a whole series of >> >> >> degraded constructs. Below a small collection of tests documenting >> >> >> some of these strange things: >> >> >> >> >> >> testSymbolLiteral >> >> >> Â Â Â Â | tree | >> >> >> Â Â Â Â #(('# foo' #foo) ('#"bar"foo' #foo) ('##foo' #foo) ('###foo' >> >> >> #foo) >> >> >> ('#foo:' #foo:) ('#foo::' #'foo::') ('#foo::bar' #'foo::bar') >> >> >> ('#foo::bar:' #'foo::bar:') ('#foo::bar::' #'foo::bar::')) do: [ >> >> >> :pair >> >> >> | >> >> >> Â Â Â Â Â Â Â Â tree := RBParser parseExpression: pair first. >> >> >> Â Â Â Â Â Â Â Â self assert: tree value = pair second. >> >> >> Â Â Â Â Â Â Â Â self assert: tree start = 1. >> >> >> Â Â Â Â Â Â Â Â self assert: tree stop = pair first size ] >> >> >> >> >> >> testStatements >> >> >> Â Â Â Â | tree | >> >> >> Â Â Â Â #(('' 0 0) ('.' 0 1) ('| bar |' 0 0) ('| bar | .' 0 1) ('| >> >> >> bar | >> >> >> ..' >> >> >> 0 2) ('foo. bar' 2 1) ('foo. bar.' 2 2) ('foo. bar. .' 2 3) ('. foo. >> >> >> bar' 2 2)) do: [ :each | >> >> >> Â Â Â Â Â Â Â Â tree := RBParser parseExpression: each first. >> >> >> Â Â Â Â Â Â Â Â self assert: tree statements size = each second. >> >> >> Â Â Â Â Â Â Â Â self assert: tree periods size = each last ] >> >> >> >> >> >> testNumberParsing >> >> >> Â Â Â Â | numbers node | >> >> >> Â Â Â Â numbers := #(('1' 1) ('-1' -1) ('123' 123) ('123' 123) >> >> >> ('-123' >> >> >> -123) >> >> >> ('1.1' 1.1) ('-1.1' -1.1) ('1.23' 1.23) ('-1.23' -1.23) ('1e3' 1e3) >> >> >> ('1d3' 1d3) ('1q3' 1q3) ('-1e3' -1e3) ('1e-3' 1e-3) ('-1e-3' -1e-3) >> >> >> ('2r1e8' Â 2r1e8) ('-2r1e8' -2r1e8) ('2r1e-8' 2r1e-8) ('-2r1e-8' >> >> >> -2r1e-8) ('0.50s2' 0.50s2) ('0.500s3' 0.500s3) ('0.050s3' 0.050s3)). >> >> >> Â Â Â Â numbers do: [ :spec | >> >> >> Â Â Â Â Â Â Â Â node := RBParser parseExpression: spec first. >> >> >> Â Â Â Â Â Â Â Â self assert: node token source = spec first. >> >> >> Â Â Â Â Â Â Â Â self assert: node value = spec second ] >> >> >> >> >> >> Lukas >> >> >> >> >> >> -- >> >> >> Lukas Renggli >> >> >> www.lukas-renggli.ch >> >> >> >> >> > >> >> > >> >> > >> >> > -- >> >> > Lukas Renggli >> >> > 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 >> > >> >> _______________________________________________ >> 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 29, 2010

Re: [Pharo-project] [NativeBoost] new win32 build available

by Schwab,Wilhelm K

Interesting. Scary<g> but interesting. At the risk of seeming obsessed with numerical analysis, is there a way to use this for callbacks? Bill

April 29, 2010

Re: [Pharo-project] [NativeBoost] new win32 build available

by Henrik Sperre Johansen

On 29.04.2010 17:13, Igor Stasenko wrote: > Core packages were broken, and were unable to load w/o errors. > But now seems everything loads well. > Use NBInstaller install. > > Thanks to Henrik for help! Here's a small example, as well as profile: SmallInteger >> nbFib <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> ^ NBNativeCodeGen methodAssembly: [:gen | | loopStart proxy asm EAX EBX ECX | asm := gen asm. proxy := NBInterpreterProxy new asm: asm. loopStart := asm uniqueLabelName: 'loopStart'. EAX := asm assembler reg0. EBX := asm assembler reg3. ECX := asm assembler reg1. proxy receiver. proxy integerValueOf: EAX. asm mov: EAX to: ECX; mov: 0 to: EAX; mov: 1 to: EBX; label: loopStart; add: EAX with: EBX; xchg: EAX with: EBX; "next three could be replaced by loopnz and a dec ECX before loop, but loopnz isn't there yet" dec: ECX; cmp: ECX with: 1; jg: loopStart. proxy positive32BitIntegerFor: EBX. gen epilogue] SmallInteger >>fib |tmp res| tmp := 1. res := 0. 0 to: self -1 do: [:ix | |oldRes| oldRes := res. res := tmp + res. tmp := oldRes.]. ^res Neither work for negative integers, and nbFib overflows for 48, haven't added largeInt creation logic :) [1 to: 100000 do: [:ix | 47 fib]] timeToRun 361 [1 to: 100000 do: [:ix | 47 nbFib]] timeToRun 21 [1 to: 100000 do: [:ix | ]] timeToRun 2 Cheers, Henry

April 29, 2010

Re: [Pharo-project] ICMP/ping

by Igor Stasenko

On 29 April 2010 21:06, Damien Cassou <damien.cassou(a)gmail.com> wrote: > Dear list, > > is it possible to ping a host from pharo ? It seems that OSProcess > would do, but it is for a windows machine and I haven't found a > pre-compiled library. > hmm.. i don't sure if squeak VM socket plugin supports raw sockets which you need for forming IMCP packets.. > Thank you > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

April 29, 2010

Re: [Pharo-project] [Metacello] Problem with ConfigurationOfGofer in Pharo1.0 [WAS] Re: ConfigurationOfGofer class

by Dale Henrichs

Mariano, Sorry for the delay in getting.....wait, I've already told you:) You can safely unload and reload a configuration. Dale ----- "Mariano Martinez Peck" <marianopeck(a)gmail.com> wrote: | Thanks for the investigation Dale...now...suppose I want to fix it and | I | want to force to load gofer again. How can I do that ? because if I | try to | install it normally, it won't do it as it is already installed. | | Thanks | | Mariano | | On Tue, Apr 20, 2010 at 6:21 PM, Dale Henrichs | <dale.henrichs(a)gemstone.com>wrote: | | > Mariano, | > | > The Pharo-1.0.changes file looks to be corrupted. If you edit the | the | > changes file and search for ConfigurationOfGofer here's what you | see: | > | > !ConfigurationOfGofer methodsFor: 'accessing' stamp: 'nk 3/5/2005 | 15:28'! | > sNil! ! | > | > !ConfigurationOfGofer methodsFor: 'baselines'! | > 1 into: [:sum :each | sum * (self foo: each)]! ! | > | > !ConfigurationOfGofer methodsFor: 'versions'! | > tring]. | > ^string! ! | > | > !ConfigurationOfGofer methodsFor: 'versions'! | > RefactoryTestDataApp methodsFor: 'inline'! ! | > | > !ConfigurationOfGofer methodsFor: 'versions'! | > inlineComponent | > | a | | > a := 5. | > ^a class | > superclass; | > hasImmediateInstances; | > yourself! ! | > | > !ConfigurationOfGofer class methodsFor: 'accessing'! | > h | | > each printString. | > ^anObject]! ! | > | > !ConfigurationOfGofer class methodsFor: 'loading'! | > ! ! | > | > !ConfigurationOfGofer class methodsFor: 'metacello tool support' | stamp: 'md | > 3/14/2006 16:47'! | > malltalk at: #MyTest | > ifAbsent: | > [| collection | | > collection := #(). | > Smalltalk at: #MyTest put: collection]! ! | > | > !ConfigurationOfGofer class methodsFor: 'metacello tool support'! | > ng new! ! | > | > !ConfigurationOfGofer class methodsFor: 'metacello tool support'! | > or: 'inline'! ! | > | > !ConfigurationOfGofer class methodsFor: 'private' stamp: | 'DaleHenrichs | > 1/25/2010 13:14'! | > bootstrapPackage: aString from: aPath | > | reposito | > ! ! | > | > !ConfigurationOfGofer class methodsFor: 'private'! | > 4:51'! ! | > | > So somehow the source was corrupted ... the compiled methods are | correct | > since: | > | > ConfigurationOfGofer project versions | > | > gives the correct answer. The source following ConfigurationOfGofer | looks | > fine so I can't imagine how the source would have been corrupted | especially | > since the methods were compiled correctly... | > | > Dale | > | > ----- "Mariano Martinez Peck" <marianopeck(a)gmail.com> wrote: | > | > | wow...you are right....but I have NO idea how that could have | been | > | done. | > | | > | Adrian: look at the instance methods of the class | ConfigurationOfGofer | > | and | > | you will notice what Erwann says. | > | | > | Dale, do you have an idea how this can be done ? As I remember | > | correctly, I | > | just evaluated: | > | | > | | > | Gofer new | > | squeaksource: 'MetacelloRepository'; | > | package: 'ConfigurationOfPharo'; | > | load. | > | | > | ((Smalltalk at: #ConfigurationOfPharo) project version: | '1.0-10517') | > | perform: #silently: with: true; perform: #load. | > | | > | | > | to generate the Pharo1.0 dev image. This code will bootstrap | Metacello | > | and | > | thus, install Gofer. Do you think there could be a problem there | ? | > | | > | Thanks Erwann for reporting! Open a bug ticket please. | > | | > | Cheers | > | | > | Mariano | > | | > | On Tue, Apr 20, 2010 at 4:52 PM, Adrian Lienhard | > | <alienhard(a)netstyle.ch>wrote: | > | | > | > Hi Erwann | > | > | > | > What does scrambled mean? | > | > | > | > I cc-ed to Mariano, he may more quickly see whether there is | > | something | > | > wrong. | > | > | > | > Cheers, | > | > Adrian | > | > | > | > ___________________ | > | > http://www.adrian-lienhard.ch/ | > | > | > | > On Apr 20, 2010, at 16:34 , Erwann Wernli wrote: | > | > | > | > > "ConfigurationOfGofer class" seem scrambled in the download | of | > | Pharo 1.0 | > | > form the website -- don't know what happened or if it's only on | my | > | image. | > | > > | > | > > Erwann | > | > > | > | > > | > | > > | > | > | > | > | > | | > | | > | -- | > | Subscription settings: | > | http://groups.google.com/group/metacello/subscribe?hl=en | >

April 29, 2010

[Pharo-project] gettext package

by Hilaire Fernandes

I have move in a Gettext package in PharoInbox classes for gettext support. Do not expect it to work. Some of the classes there, are just moved from former categories in pharo System-Localization and Multilingual other are coming from Etoys. I have not yet test to load it in a fresh image. Hilaire

April 29, 2010

Re: [Pharo-project] Legitimate syntax for # ... foo

by Eliot Miranda

On Thu, Apr 29, 2010 at 1:25 PM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > 2010/4/29 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > > > > On Thu, Apr 29, 2010 at 12:50 PM, Nicolas Cellier > > <nicolas.cellier.aka.nice(a)gmail.com> wrote: > >> > >> I don't think any other st dialect would accept that syntax but Squeak. > > > > VisualWorks accepts it just fine. > > # "hello" foo => #foo > > # "hello" (foo # "hello" foo) => #(#foo #foo) > > I think this is the way the language works. Relax. Celebrate its > > weirdness. Don't sweat the petty stuff, pet the sweaty stuff: > > > http://www.popsci.com/gadgets/article/2010-04/exclusive-making-elements-one… > > Maybe I should relax about comment anywhere, but these: > > [Compiler evaluate: '#( # 2 # -2 )'] on: Error do: [:exc | exc return: > nil]. > [Compiler evaluate: '# -2'] on: Error do: [:exc | exc return: nil]. > [Compiler evaluate: '#-2'] on: Error do: [:exc | exc return: nil]. > [Compiler evaluate: '#$a'] on: Error do: [:exc | exc return: nil]. > [Compiler evaluate: '##(1##)1)'] on: Error do: [:exc | exc return: nil]. > > would all return nil in VW, not so in Squeak. > Also, I mind the difference of first two in Squeak. > That's hardly predictable and much too weird to my own taste... > That's fair enough, but that's a different issue to there being allowable whitespace between the literal hash and the literal. In any case, comparing against VW is probably a sensible thing to do. best Eliot > Nicolas > > >> > >> It's just how the parser/scanner works now, but It wouldn't break much > >> code IMO if we stop supporting these weirdnesses. > >> > >> Nicolas > >> > >> 2010/4/29 Lukas Renggli <renggli(a)gmail.com>: > >> > Actually I didn't have all the latest code loaded in the open image. > >> > There is more, hold your breath: > >> > > >> > testSymbolNumbers > >> > #(('#1' 1) ('#12' 12) ('#12.3' 12.3) ('# 1' 1) ('##1' 1) > >> > ('#"bar"1' > >> > 1)) do: [ :pair | > >> > tree := RBParser parseExpression: pair first. > >> > self assert: tree value = pair second. > >> > self assert: tree start > 1. > >> > self assert: tree stop = pair first size ] > >> > > >> > On 29 April 2010 21:12, Lukas Renggli <renggli(a)gmail.com> wrote: > >> >>> # "helllooo" foo > >> >>> > >> >>> prints > >> >>> #foo > >> >>> > >> >>> is this correct? > >> >> > >> >> Probably not, but the standard compiler accepts it. So I had to patch > >> >> the parser of the refactoring engine to accept a whole series of > >> >> degraded constructs. Below a small collection of tests documenting > >> >> some of these strange things: > >> >> > >> >> testSymbolLiteral > >> >> | tree | > >> >> #(('# foo' #foo) ('#"bar"foo' #foo) ('##foo' #foo) ('###foo' > >> >> #foo) > >> >> ('#foo:' #foo:) ('#foo::' #'foo::') ('#foo::bar' #'foo::bar') > >> >> ('#foo::bar:' #'foo::bar:') ('#foo::bar::' #'foo::bar::')) do: [ > :pair > >> >> | > >> >> tree := RBParser parseExpression: pair first. > >> >> self assert: tree value = pair second. > >> >> self assert: tree start = 1. > >> >> self assert: tree stop = pair first size ] > >> >> > >> >> testStatements > >> >> | tree | > >> >> #(('' 0 0) ('.' 0 1) ('| bar |' 0 0) ('| bar | .' 0 1) ('| bar > | > >> >> ..' > >> >> 0 2) ('foo. bar' 2 1) ('foo. bar.' 2 2) ('foo. bar. .' 2 3) ('. foo. > >> >> bar' 2 2)) do: [ :each | > >> >> tree := RBParser parseExpression: each first. > >> >> self assert: tree statements size = each second. > >> >> self assert: tree periods size = each last ] > >> >> > >> >> testNumberParsing > >> >> | numbers node | > >> >> numbers := #(('1' 1) ('-1' -1) ('123' 123) ('123' 123) ('-123' > >> >> -123) > >> >> ('1.1' 1.1) ('-1.1' -1.1) ('1.23' 1.23) ('-1.23' -1.23) ('1e3' 1e3) > >> >> ('1d3' 1d3) ('1q3' 1q3) ('-1e3' -1e3) ('1e-3' 1e-3) ('-1e-3' -1e-3) > >> >> ('2r1e8' 2r1e8) ('-2r1e8' -2r1e8) ('2r1e-8' 2r1e-8) ('-2r1e-8' > >> >> -2r1e-8) ('0.50s2' 0.50s2) ('0.500s3' 0.500s3) ('0.050s3' 0.050s3)). > >> >> numbers do: [ :spec | > >> >> node := RBParser parseExpression: spec first. > >> >> self assert: node token source = spec first. > >> >> self assert: node value = spec second ] > >> >> > >> >> Lukas > >> >> > >> >> -- > >> >> Lukas Renggli > >> >> www.lukas-renggli.ch > >> >> > >> > > >> > > >> > > >> > -- > >> > Lukas Renggli > >> > 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 > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 29, 2010