- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Strange code replacement when prompting unknown selector

by StÃ©phane Ducasse

This sounds correct. Did you check how this is done in Cuis? Stef On Oct 9, 2010, at 5:31 AM, Guillermo Polito wrote: > The problem seems to be between TextEditor>>correctFrom:to:with: and Parser>>substituteWord:wordInterval:offset: > > The TextEditor isn't using well the selection offset to calculate the replacement, and the parser is sending an interval that's not the one that the Editor must replace. > > I think the right place to put this is the Editor, but behind another message like replaceInSelectionFrom:to:with: > > What do you think? > > Guille > > > On Wed, Oct 6, 2010 at 6:33 PM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > http://code.google.com/p/pharo/issues/detail?id=3070 > > Cheers! > Guille > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 9, 2010

Re: [Pharo-project] MicroSqueak [was System Tracer]

by StÃ©phane Ducasse

Thanks. In fact, the steps described are similar to a lot of other solutions but this is always interesting to be able to compare. For example how to deal with nil, true false since after a bootstrap they should be instances of the new kernel classes. Stef > Hi All, > > I'm please to let you know that John Maloney has published his MicroSqueak code on his website under the MIT license. http://web.media.mit.edu/~jmaloney/microsqueak/ > Apologies for the premature posting. We can get down to business now. Again huge thanks to John for this code. > > On Thu, Oct 7, 2010 at 10:26 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi All, > > > turns out John does not want this code released, so please can you destroy any and all copies? Also, who do I have to talk to to get the archive message, with attachments, destroyed? > > Apologies to all, I've f***ed up badly here. > > Eliot > > > On Wed, Oct 6, 2010 at 4:22 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > FInd attached. You want MicroSqueak-colonequal.st and the various MSqueak-.st files. This produces a 57k image. John's also given me a 2.0 development image which will run on a 3.8 VM. Let me know if you want that. For me this is a proof of concept. What's needed is to define a headless core that contains the compiler, good error reporting to standard out, the core collection and numeric libraries and file support. Then we try and load packages into it and build up a headful image. > > On Wed, Oct 6, 2010 at 3:03 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Oct 6, 2010, at 7:18 PM, Eliot Miranda wrote: > > > > > > > On Wed, Oct 6, 2010 at 7:31 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > generate a new image. > > > > But that's not what it does. > > Yes I know gnerates = clone in my mail. > > > t merely clones an image, which is a long way form building an image form source. *That*'s a useful project. John Maloney's lovely MicroSqueak is a good starting point for ideas (basically have a copy of a kernel subset of the system in a namespace and generate a fresh image from that). > > Do you have a pointer on the code of john. We are looking at bootstrap code right now. > > > > > On Oct 6, 2010, at 2:23 PM, Alexandre Bergel wrote: > > > > > Hi! > > > > > > What do you want to achieve? > > > > > > Cheers, > > > Alexandre > > > > > > > > > On 6 Oct 2010, at 05:36, Gabriel HernÃ¡n Barbuto wrote: > > > > > >> Hi > > >> > > >> Does anyone know where I can find the system tracer that is currently > > >> in use in Pharo? > > >> > > >> Bests > > >> Gabriel > > >> > > >> _______________________________________________ > > >> Pharo-project mailing list > > >> Pharo-project(a)lists.gforge.inria.fr > > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > -- > > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > > Alexandre Bergel http://www.bergel.eu > > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > 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

Oct. 9, 2010

Re: [Pharo-project] #hasBindingThatBeginsWith:, Shout, E/OCompletion (fwd)

by StÃ©phane Ducasse

Thanks levente The second solution looks good to me. Stef On Oct 8, 2010, at 11:48 PM, Levente Uzonyi wrote: > I accidentally sent this to the pharo-users list... > > ---------- Forwarded message ---------- > Date: Fri, 8 Oct 2010 23:14:02 +0200 (CEST) > From: Levente Uzonyi <leves(a)elte.hu> > To: squeak-dev(a)lists.squeakfoundation.org, pharo-users(a)lists.gforge.inria.fr > Subject: #hasBindingThatBeginsWith:, Shout, E/OCompletion > > Hi folks, > > > there's a method called #hasBindingThatBeginsWith: which seems to be used > only by Shout. If that's true, then it would be better to add it to the Shout/ShoutCore package if possible. > Also this method is responsible for the slowdown of Shout's parser when there are undefined variables in the code. Actually only SystemDictionary >>> #hasBindingsThatBeginsWith: is responsible for the slowdown which uses > Dictionary's implementation which checks all keys. > There's already an issue on Pharo's tracker (with some useful, but with > some wrong info too): http://code.google.com/p/pharo/issues/detail?id=1452 . The slowdown affects E/OCompletion more, because those invoke Shout's parser after every keystroke, while Shout uses a background process for parsing. > I propose two possible solutions here: > > 1) Add the following method (+2-3 other, see below): > > SystemDictionary >> hasBindingThatBeginsWith: aString > > | className | > aString isEmpty ifTrue: [ ^false ]. > (self class fastBindingPrefixSearch and: [ > aString first isLowercase ]) > ifTrue: [ ^false ]. > className := self classNames > findBinary: [ :element | > (element beginsWith: aString) > ifTrue: [ 0 ] > ifFalse: [ > aString < element > ifTrue: [ -1 ] > ifFalse: [ 1 ] ] ] > ifNone: nil. > className ifNotNil: [ ^true ]. > ^super hasBindingThatBeginsWith: aString > > > How does it work? > There are two optimizations. The first checks if the argument's first letter is lowercase. If it's a lowercase letter, then it returns false instead of checking the dictionary. This is the most common case when you're typing methods with undefined local/instance variables. Since this optimization breaks Shout's highlighting when the argument is a prefix of a global that begins with a lowercase letter, there's a boolean preference/setting that enables/disables this optimization (SystemDictionary class >> #fastBindingPrefixSearch). > The other optimization uses binary search on SystemDictionary's cached class names, which is a SortedCollection with all the classnames in the system. This helps when you're typing the name of an existing class. Since Shout uses a background process, this is mostly useful for E/OCompletion. When none of these optimizations are usable, the method simply falls back to scanning all keys. > > Pros: > - very simple addition > - covers the most common cases > Cons: > - it doesn't work for all cases > - it breaks Shout highlighting a bit > > 2) Add a new instance variable to SystemDictionary to hold the name of non-class globals, use binary search on both sorted collections: > > SystemDictionary >> hasBindingThatBeginsWith: aString > > | name searchBlock | > searchBlock := [ :element | > (element beginsWith: aString) > ifTrue: [ 0 ] > ifFalse: [ > aString < element > ifTrue: [ -1 ] > ifFalse: [ 1 ] ] ]. > name := self classNames > findBinary: searchBlock > ifNone: nil. > name ifNotNil: [ ^true ]. > name := self nonClassNames > findBinary: searchBlock > ifNone: nil. > ^name notNil > > (for the rest see System-ul.384 in the Inbox for Squeak and http://leves.web.elte.hu/squeak/SystemDictionary.ul.1.cs for Pharo) > > How does it work? > It's just two binary search, one on the class names and one on the non-clas names. This covers all globals (except those which are not in memory (Squeak only)). > > Pros: > - covers all cases with good performance > - the new cache can be used to speed up other methods (like #allTraits) > Cons: > - modifies SystemDictionary > > I'd go with the second solution. What do you think? > > > Cheers, > Levente > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 9, 2010

Re: [Pharo-project] bad bracket autocompletion in Pharo Core 1.2

by Guillermo Polito

Here is the piece of code that's behaving weird TextEditor>>dispatchOn: ... ... char := aKeyboardEvent keyCharacter. openers := '([{'. closers := ')]}'. ( closers includes: char) ifTrue: [ self blinkPrevParen: char ]. result := self normalCharacter: aKeyboardEvent. (self class autoEnclose and: [ openers includes: char ]) not ifTrue: [ ^ result ]. suffix := closers at: (openers indexOf: char). paragraph text append: suffix asString. self moveCursor: [ : position | position ] forward: true specialBlock: [ : pos | "no special behavior" ] event: aKeyboardEvent . self userHasEdited. ------------------------------------- So, if I evaluate "TextEditor autoEnclose: false", it is stops behaving like that :) What should be the desired behavior? Having it configurable as it is today but fix the strange bracket adding? remove this behavior? I can't find now how ParagraphEditor did this. Guille On Wed, Oct 6, 2010 at 10:34 PM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > Yes, the issue can be reduced to: > > open parenthesis (or brackets), then something else (anywhere in the > editor). > > 2010/10/6 Mariano Martinez Peck <marianopeck(a)gmail.com> > > I detected a similar problem: >> >> once you type an opening parenthesis, and then something else, it adds a >> new one at the END of the code >> >> check http://code.google.com/p/pharo/issues/detail?id=2939 >> >> 2010/10/6 Guillermo Polito <guillermopolito(a)gmail.com> >> >>> http://code.google.com/p/pharo/issues/detail?id=3069 >>> >>> if you type: >>> >>> [] -> []] >>> >>> () -> ()) >>> >>> {} -> {}} >>> >>> >>> >>> Bye! >>> >>> _______________________________________________ >>> 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 >> > >

Oct. 9, 2010

Re: [Pharo-project] Strange code replacement when prompting unknown selector

by Guillermo Polito

The problem seems to be between *TextEditor>>correctFrom:to:with:* and * Parser>>substituteWord:wordInterval:offset:* The TextEditor isn't using well the selection offset to calculate the replacement, and the parser is sending an interval that's not the one that the Editor must replace. I think the right place to put this is the Editor, but behind another message like replaceInSelectionFrom:to:with: What do you think? Guille On Wed, Oct 6, 2010 at 6:33 PM, Guillermo Polito <guillermopolito(a)gmail.com>wrote: > http://code.google.com/p/pharo/issues/detail?id=3070 > > Cheers! > Guille >

Oct. 9, 2010

Re: [Pharo-project] MicroSqueak [was System Tracer]

by Eliot Miranda

Hi All, I'm please to let you know that John Maloney has published his MicroSqueak code on his website under the MIT license. http://web.media.mit.edu/~jmaloney/microsqueak/ <http://web.media.mit.edu/~jmaloney/microsqueak/>Apologies for the premature posting. We can get down to business now. Again huge thanks to John for this code. On Thu, Oct 7, 2010 at 10:26 AM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > Hi All, > > > turns out John does not want this code released, so please can you > destroy any and all copies? Also, who do I have to talk to to get the > archive message, with attachments, destroyed? > > Apologies to all, I've f***ed up badly here. > > Eliot > > > On Wed, Oct 6, 2010 at 4:22 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > >> FInd attached. You want MicroSqueak-colonequal.st and the various >> MSqueak-.st files. This produces a 57k image. John's also given me a 2.0 >> development image which will run on a 3.8 VM. Let me know if you want that. >> For me this is a proof of concept. What's needed is to define a headless >> core that contains the compiler, good error reporting to standard out, the >> core collection and numeric libraries and file support. Then we try and >> load packages into it and build up a headful image. >> >> On Wed, Oct 6, 2010 at 3:03 PM, StÃ©phane Ducasse < >> stephane.ducasse(a)inria.fr> wrote: >> >>> >>> On Oct 6, 2010, at 7:18 PM, Eliot Miranda wrote: >>> >>> > >>> > >>> > On Wed, Oct 6, 2010 at 7:31 AM, StÃ©phane Ducasse < >>> stephane.ducasse(a)inria.fr> wrote: >>> > generate a new image. >>> > >>> > But that's not what it does. >>> >>> Yes I know gnerates = clone in my mail. >>> >>> > t merely clones an image, which is a long way form building an image >>> form source. *That*'s a useful project. John Maloney's lovely MicroSqueak >>> is a good starting point for ideas (basically have a copy of a kernel subset >>> of the system in a namespace and generate a fresh image from that). >>> >>> Do you have a pointer on the code of john. We are looking at bootstrap >>> code right now. >>> >>> > >>> > On Oct 6, 2010, at 2:23 PM, Alexandre Bergel wrote: >>> > >>> > > Hi! >>> > > >>> > > What do you want to achieve? >>> > > >>> > > Cheers, >>> > > Alexandre >>> > > >>> > > >>> > > On 6 Oct 2010, at 05:36, Gabriel HernÃ¡n Barbuto wrote: >>> > > >>> > >> Hi >>> > >> >>> > >> Does anyone know where I can find the system tracer that is >>> currently >>> > >> in use in Pharo? >>> > >> >>> > >> Bests >>> > >> Gabriel >>> > >> >>> > >> _______________________________________________ >>> > >> Pharo-project mailing list >>> > >> Pharo-project(a)lists.gforge.inria.fr >>> > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> > > >>> > > -- >>> > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> > > Alexandre Bergel http://www.bergel.eu >>> > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > _______________________________________________ >>> > > 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 >>> >> >> >

Oct. 9, 2010

Re: [Pharo-project] #hasBindingThatBeginsWith:, Shout, E/OCompletion (fwd)

by Miguel CobÃ¡

El vie, 08-10-2010 a las 23:48 +0200, Levente Uzonyi escribiÃ³: > I accidentally sent this to the pharo-users list... > > ---------- Forwarded message ---------- > Date: Fri, 8 Oct 2010 23:14:02 +0200 (CEST) > From: Levente Uzonyi <leves(a)elte.hu> > To: squeak-dev(a)lists.squeakfoundation.org, pharo-users(a)lists.gforge.inria.fr > Subject: #hasBindingThatBeginsWith:, Shout, E/OCompletion > > Hi folks, > > > there's a method called #hasBindingThatBeginsWith: which seems to be used > only by Shout. If that's true, then it would be better to add it to the > Shout/ShoutCore package if possible. > Also this method is responsible for the slowdown of Shout's parser when there > are undefined variables in the code. Actually only SystemDictionary > >> #hasBindingsThatBeginsWith: is responsible for the slowdown which uses > Dictionary's implementation which checks all keys. > There's already an issue on Pharo's tracker (with some useful, but with > some wrong info too): http://code.google.com/p/pharo/issues/detail?id=1452 . > The slowdown affects E/OCompletion more, because those invoke Shout's parser > after every keystroke, while Shout uses a background process for parsing. > I propose two possible solutions here: > > 1) Add the following method (+2-3 other, see below): > > SystemDictionary >> hasBindingThatBeginsWith: aString > > | className | > aString isEmpty ifTrue: [ ^false ]. > (self class fastBindingPrefixSearch and: [ > aString first isLowercase ]) > ifTrue: [ ^false ]. > className := self classNames > findBinary: [ :element | > (element beginsWith: aString) > ifTrue: [ 0 ] > ifFalse: [ > aString < element > ifTrue: [ -1 ] > ifFalse: [ 1 ] ] ] > ifNone: nil. > className ifNotNil: [ ^true ]. > ^super hasBindingThatBeginsWith: aString > > > How does it work? > There are two optimizations. The first checks if the argument's first letter is > lowercase. If it's a lowercase letter, then it returns false instead of > checking the dictionary. This is the most common case when you're typing > methods with undefined local/instance variables. Since this optimization breaks > Shout's highlighting when the argument is a prefix of a global that begins with > a lowercase letter, there's a boolean preference/setting that enables/disables > this optimization (SystemDictionary class >> #fastBindingPrefixSearch). > The other optimization uses binary search on SystemDictionary's cached class > names, which is a SortedCollection with all the classnames in the system. This > helps when you're typing the name of an existing class. Since Shout uses a > background process, this is mostly useful for E/OCompletion. When none of these > optimizations are usable, the method simply falls back to scanning all keys. > > Pros: > - very simple addition > - covers the most common cases > Cons: > - it doesn't work for all cases > - it breaks Shout highlighting a bit > > 2) Add a new instance variable to SystemDictionary to hold the name of > non-class globals, use binary search on both sorted collections: > > SystemDictionary >> hasBindingThatBeginsWith: aString > > | name searchBlock | > searchBlock := [ :element | > (element beginsWith: aString) > ifTrue: [ 0 ] > ifFalse: [ > aString < element > ifTrue: [ -1 ] > ifFalse: [ 1 ] ] ]. > name := self classNames > findBinary: searchBlock > ifNone: nil. > name ifNotNil: [ ^true ]. > name := self nonClassNames > findBinary: searchBlock > ifNone: nil. > ^name notNil > > (for the rest see System-ul.384 in the Inbox for Squeak and > http://leves.web.elte.hu/squeak/SystemDictionary.ul.1.cs for Pharo) > > How does it work? > It's just two binary search, one on the class names and one on the non-clas > names. This covers all globals (except those which are not in memory (Squeak > only)). > > Pros: > - covers all cases with good performance > - the new cache can be used to speed up other methods (like #allTraits) > Cons: > - modifies SystemDictionary > > I'd go with the second solution. What do you think? +1 to the second option with two caches for class and non class names. > > > Cheers, > Levente > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Oct. 9, 2010

Re: [Pharo-project] XTream was Re: Ocean (was Re: Less plugins, more Smalltalk code!)

by mkobetic＠gmail.com

"Nicolas Cellier"<nicolas.cellier.aka.nice(a)gmail.com> wrote: > More example than the site http://code.google.com/p/xtreams/ ? If so, I'm interested. Not more, but different. For example I'm quite fond of the Morse code decoding example: ('. ... ..- --. -... .- .-. -.-. . .-.. --- -. .- -- -- -..- ' reading transforming: [ :in :out || node beep | node := MorseTree. [ beep := in get. beep = Character space ] whileFalse: [ node := beep = $. ifTrue: [ node at: 3 ] ifFalse: [ node at: 2 ] ]. out put: node first ] ) rest Where MorseTree is (http://en.wikipedia.org/wiki/File:Morse_code_tree3.png) encoded as nested three element arrays: #($ ($T ($M ($O) ($G ($Q) ($Z))) ($N ($K ($Y) ($C)) ($D ($X) ($B)))) ($E ($A ($W ($J) ($P)) ($R () ($L))) ($I ($U () ($F)) ($S ($V) ($H))))) Anyway, I'll send you the PDF directly. > Yes, that makes sense, what I call the Xtreme approach... Less confusion. > However it would be wonderfull to get feedback from average programmer > about this on real application. Not sure what you meant. > Maybe this will be a matter of adding one missing convenient message or two... Yes we can certainly add a package that implements most (maybe all) of the classic API as an extension. But I'd rather keep the Core clean and minimal. This way you have the choice of both. > Of course the best option is to share. Though I don't think Xtream was > developped with portability as main goal, it's not sure it has so many > external dependencies. Yes, we didn't spend much time thinking about portability so far. We rewrote the whole thing bottom up several times trying to get the design right, so we didn't want to be distracted by other concerns. That doesn't mean that we can't focus on that now assuming we're reasonably happy with current design. I don't think there are particular dependencies that are critical to make Xtreams work in general. As long as we can preserve the efficiency, we can certainly make necessary changes. That said, I think we'll just have dialect specific versions of some of the packages. Hopefully Xtreams-Core can be fully portable. Xtreams-Terminals are likely going to be dialect specific. Xtreams-Transforms could probably be portable if we move the VW specific encoding stuff elsewhere. Maybe it can just go into Xtreams-Xtras. It was nice to have the encodings with the core transforms but until we have portable encoders we can just maintain those in dialect specific packages. Something like that. > Is there a tool to identify the dependency on classes outside the package in VW ? Yes there is a tab in the browser that autocomputes prerequisites and a menu option that gives you depenedents if you want the other direction. > We know in advance a few concerning the system, File & Sockets, DLLCC, compression... Yes, I would expect each dialect to have it's own implementation of most of the terminal streams. It might be possible to share some of those, e.g. collection or buffer streams, but given that different dialects have different ways to deal with them efficiently, we may want to have dialect specific implementations anyway. Ultimately, it's fine if different dialects support different set of terminals. There will probably be some that we want everywhere, but maybe it would be great to be able to stream over some Morphs in Squeak or something such. If that's useful, there's no reason not to do it because VW doesn't have Morphic. Anyway, the point is not all the code has to be portable, we can try to share as much as is feasible and have dialect specific implementation of the rest. So at least initially, I'd focus on getting a portable Core and Transforms, with dialect specific Terminals, and we can think about stuff in Xtras later. > Then, there is the question of using Exception handling or not. In > Squeak, this isn't going to be a matter of compatibility (though the > difference might be subtle), rather a matter of efficiency. > However, Incomplete is a corner stone of Xtream implementation if I > understand correctly... > Squeak is not using EndOfStream > http://bugs.squeak.org/view.php?id=6755 and some of the efficiency > reasons are there > http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-November/122434… > > On the other hand, the endOfStreamAction of Squeak_Xtream is pleasant > at first, but hard to handle across wrappers. I don't yet have an > answer whether it scales on a more complete xtream library or not > (thinking of blocking streams...). Yes, this one is tricky. Exceptions cost something in VW as well, so you need to be reasonably prudent with them. As Michael mentioned we've made some serious adjustments in Xtreams earlier this year to avoid triggering Incomplete internally if we could get by without it. See http://www.cincomsmalltalk.com/userblogs/mls/blogView?entry=3445952077 http://www.cincomsmalltalk.com/userblogs/mls/blogView?entry=3448891140 But I think your original argument that in common case the exception should not be triggered frequently is valid. Certainly if you write a micro-benchmark which stacks the odds the other way it will show, but as they say micro-benchmarks are not applications. At the same time consider the cost of not using an exception. Exception allows me to write my algorithm without worrying about the end of stream if I wrap the whole thing in a handler. And the handler is normally located in the right place to handle the end of stream. Without the exception you'll have to add end checks to every single read call of the algorithm. I'm not talking about runtime cost here, I'm talking code complexity. And I don't see how an "end of stream block" makes this much better. The exception allows me to get out of the main body of the algorithm at any of its points, and if the handler exits, the main block gets unwound cleanly. How do I do that with a block that I set on the stream instance? You'd have to carefully structure the code so that the algorithm body is in a method of its own and then there's a dedicated wrapper method around that so that the block can use a side-ways return to exit the method. That is some pretty hideous boiler-plate code, if you ask me.f So, I'm not saying that exception costs are negligible, but there are often ways to minimize them in specific scenarios, often via well designed APIs and patterns (and proper internal implementation). As Michael's posts above show, we were able to match and beat the speed of regular streams in the example without sacrificing the API. At the same time Squeak is getting faster, so I'm not at all convinced that the slow-down factor always does and always will trump the other costs. In fact I feel that it's more often than not the other way around, that the slow down can be made sufficiently small so that it does pay off in terms of code complexity. Maybe some things will always want a stream that doesn't trigger exceptions, but that doesn't mean most things are better off that way. That's just my opinion. Anyway, so far we've been doing quite well in terms of performance without sacrificing exceptions. I'd say let's see if we can keep that track record on Squeak as well. If we find out that it's just not good enough in general case, maybe we'll re-evaluate then. But at this point I'm not convinced that we need to drop the exception to keep Xtreams reasonably usable. Martin

Oct. 8, 2010

Re: [Pharo-project] [vwnc] XTream was Re: Ocean (was Re: Less plugins, more Smalltalk code!)

by Nicolas Cellier

Resent, reply to all... 2010/10/9 Michael Lucas-Smith <michael.lucassmith(a)gmail.com>: >> >> Hehe, I've got the feeling to surf on your hard work with low investment ;) >> Xtream ideas should definitly continue to attract. J'espÃ¨re que la >> mayonnaise va prendre. >> Of course the best option is to share. Though I don't think Xtream was >> developped with portability as main goal, it's not sure it has so many >> external dependencies. >> Is there a tool to identify the dependency on classes outside the >> package in VW ? >> We know in advance a few concerning the system, File & Sockets, DLLCC, >> compression... >> With good package delimitation, that can be worked out. > > We divided the Xtreams packages up with this in mind. The Core should be portable, the Terminals are not -- they must be implemented for each platform because they're the ones that use the platform specific objects. > I'm browsing VW right now, at first sight there are not so many uncompatibilities in core, should be solved easily Incomplete>>#raise could be added (#signal in Squeak) #copyEmpty: could be an extension #isFixedArgument not existing in Squeak (external heap notion exists though) Lack of namespace in Squeak shall force use of a prefix (XT ?). Some terminals are generic and should port easily too: BlockClosure/Buffer/Collection For File, assuming they are non blocking, we can arrange a quick hack. For transforms, the StreamEncoder does not exist in Squeak (better not use existing Multilingual, a rewrite will be cleaner). >> The problem with Squeak is that we don't have a good File library (non >> blocking). The good point with Xtream is that we don't need that many >> primitives. >> And last good point is the huge effort you made to coverage tests... >> That should ease porting. > > It's okay if not all terminals and transformation are supported on every platform. We could create a capabilities grid for the different ports to show what can and can't be done. > >> >> Then, there is the question of using Exception handling or not. In >> Squeak, this isn't going to be a matter of compatibility (though the >> difference might be subtle), rather a matter of efficiency. >> However, Incomplete is a corner stone of Xtream implementation if I >> understand correctly... >> Squeak is not using EndOfStream >> http://bugs.squeak.org/view.php?id=6755 and some of the efficiency >> reasons are there >> http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-November/122434… > > Even in VisualWorks Exceptions are expensive. We went to great lengths to make sure the exception mechanism did not fire constantly. We spent several agonizing weeks studying the effects of our implementation on garbage generation and efficiency until we finally arrived at the design we have now. The biggest problems were with substreaming which we eventually solved. > > Michael The simplest thing is just to port a few classes then bench... That's worth a try. Nicolas

Oct. 8, 2010

[Pharo-project] #hasBindingThatBeginsWith:, Shout, E/OCompletion (fwd)

by Levente Uzonyi

I accidentally sent this to the pharo-users list... ---------- Forwarded message ---------- Date: Fri, 8 Oct 2010 23:14:02 +0200 (CEST) From: Levente Uzonyi <leves(a)elte.hu> To: squeak-dev(a)lists.squeakfoundation.org, pharo-users(a)lists.gforge.inria.fr Subject: #hasBindingThatBeginsWith:, Shout, E/OCompletion Hi folks, there's a method called #hasBindingThatBeginsWith: which seems to be used only by Shout. If that's true, then it would be better to add it to the Shout/ShoutCore package if possible. Also this method is responsible for the slowdown of Shout's parser when there are undefined variables in the code. Actually only SystemDictionary >> #hasBindingsThatBeginsWith: is responsible for the slowdown which uses Dictionary's implementation which checks all keys. There's already an issue on Pharo's tracker (with some useful, but with some wrong info too): http://code.google.com/p/pharo/issues/detail?id=1452 . The slowdown affects E/OCompletion more, because those invoke Shout's parser after every keystroke, while Shout uses a background process for parsing. I propose two possible solutions here: 1) Add the following method (+2-3 other, see below): SystemDictionary >> hasBindingThatBeginsWith: aString | className | aString isEmpty ifTrue: [ ^false ]. (self class fastBindingPrefixSearch and: [ aString first isLowercase ]) ifTrue: [ ^false ]. className := self classNames findBinary: [ :element | (element beginsWith: aString) ifTrue: [ 0 ] ifFalse: [ aString < element ifTrue: [ -1 ] ifFalse: [ 1 ] ] ] ifNone: nil. className ifNotNil: [ ^true ]. ^super hasBindingThatBeginsWith: aString How does it work? There are two optimizations. The first checks if the argument's first letter is lowercase. If it's a lowercase letter, then it returns false instead of checking the dictionary. This is the most common case when you're typing methods with undefined local/instance variables. Since this optimization breaks Shout's highlighting when the argument is a prefix of a global that begins with a lowercase letter, there's a boolean preference/setting that enables/disables this optimization (SystemDictionary class >> #fastBindingPrefixSearch). The other optimization uses binary search on SystemDictionary's cached class names, which is a SortedCollection with all the classnames in the system. This helps when you're typing the name of an existing class. Since Shout uses a background process, this is mostly useful for E/OCompletion. When none of these optimizations are usable, the method simply falls back to scanning all keys. Pros: - very simple addition - covers the most common cases Cons: - it doesn't work for all cases - it breaks Shout highlighting a bit 2) Add a new instance variable to SystemDictionary to hold the name of non-class globals, use binary search on both sorted collections: SystemDictionary >> hasBindingThatBeginsWith: aString | name searchBlock | searchBlock := [ :element | (element beginsWith: aString) ifTrue: [ 0 ] ifFalse: [ aString < element ifTrue: [ -1 ] ifFalse: [ 1 ] ] ]. name := self classNames findBinary: searchBlock ifNone: nil. name ifNotNil: [ ^true ]. name := self nonClassNames findBinary: searchBlock ifNone: nil. ^name notNil (for the rest see System-ul.384 in the Inbox for Squeak and http://leves.web.elte.hu/squeak/SystemDictionary.ul.1.cs for Pharo) How does it work? It's just two binary search, one on the class names and one on the non-clas names. This covers all globals (except those which are not in memory (Squeak only)). Pros: - covers all cases with good performance - the new cache can be used to speed up other methods (like #allTraits) Cons: - modifies SystemDictionary I'd go with the second solution. What do you think? Cheers, Levente

Oct. 8, 2010