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

Re: [Pharo-project] [squeak-dev] SharedQueue doesn't scale

by Igor Stasenko

On 17 October 2010 13:42, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 17 October 2010 12:01, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> Igor sorry we were busy running around :) >> So could you summarize >> Â Â Â Â with pros and cons >> Â Â Â Â with potential path for the next actions >> Â Â Â Â May be we should schedule something for 1.3 >> > > The two implementations i made in Atomic-Collections package run > without using any kind of locking (i.e. semaphores). > However, we should make a difference between lock-free and wait-free algorithms. > > Inserting items in queue (both FIFO and LIFO) using no wait-loops, and > can be considered a O(1) operation, > if we neglect the cost of allocating new queue item. > > But to extract items, both FIFO and LIFO queues using a wait loops, if > queue is in the middle of extraction by > other process. > This means, that if there is only one process, which extracting items > from queue, > extraction will be always wait-free. But if you having more than one, > you should expect wait-loops to be used. > There is, however a way to give a quick answer without entering a > wait-loop at attempt > to extract a single item from queue. But it won't be deterministic answer: > Â - #nextIfNone: will return nil if there either no items in queue or > queue is currently in the middle of extraction by > other process. oops.. #nextIfNone: , will evaluate a block if there is no items in queue, it is a #nextOrNil, which answers nil if there are no items in queue. > > I think that there should be two distinct methods(protocol) for > accessing queue in wait-free way, > which not always guarantees deterministic answers, and methods, which > using wait loops. > Because currently, in order to match with SharedQueue protocol, > there is a mix of methods with wait-free and wait-loops to match the > SharedQueue behavior. > > Then, applications, which using these queues, could have a guarantees > that any access to queue > are wait-free, if they can neglect that answers are non-deterministic, > or use methods with wait-loops to always have a deterministic answers. > >> Stef >> >> >> On Oct 16, 2010, at 4:19 AM, Igor Stasenko wrote: >> > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig.

Oct. 17, 2010

Re: [Pharo-project] [squeak-dev] SharedQueue doesn't scale

by Igor Stasenko

On 17 October 2010 12:01, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Igor sorry we were busy running around :) > So could you summarize > Â Â Â Â with pros and cons > Â Â Â Â with potential path for the next actions > Â Â Â Â May be we should schedule something for 1.3 > The two implementations i made in Atomic-Collections package run without using any kind of locking (i.e. semaphores). However, we should make a difference between lock-free and wait-free algorithms. Inserting items in queue (both FIFO and LIFO) using no wait-loops, and can be considered a O(1) operation, if we neglect the cost of allocating new queue item. But to extract items, both FIFO and LIFO queues using a wait loops, if queue is in the middle of extraction by other process. This means, that if there is only one process, which extracting items from queue, extraction will be always wait-free. But if you having more than one, you should expect wait-loops to be used. There is, however a way to give a quick answer without entering a wait-loop at attempt to extract a single item from queue. But it won't be deterministic answer: - #nextIfNone: will return nil if there either no items in queue or queue is currently in the middle of extraction by other process. I think that there should be two distinct methods(protocol) for accessing queue in wait-free way, which not always guarantees deterministic answers, and methods, which using wait loops. Because currently, in order to match with SharedQueue protocol, there is a mix of methods with wait-free and wait-loops to match the SharedQueue behavior. Then, applications, which using these queues, could have a guarantees that any access to queue are wait-free, if they can neglect that answers are non-deterministic, or use methods with wait-loops to always have a deterministic answers. > Stef > > > On Oct 16, 2010, at 4:19 AM, Igor Stasenko wrote: > -- Best regards, Igor Stasenko AKA sig.

Oct. 17, 2010

Re: [Pharo-project] [squeak-dev] SharedQueue doesn't scale

by StÃ©phane Ducasse

Igor sorry we were busy running around :) So could you summarize with pros and cons with potential path for the next actions May be we should schedule something for 1.3 Stef On Oct 16, 2010, at 4:19 AM, Igor Stasenko wrote: > Hello, > > just out of interest, i tried to compare the speed of my FIFOQueue > implementation and SharedQueue, > using Levente's benchmarks for stack: > > "The linked Stack implementation" > (1 to: 5) collect: [ :run | > | stack | > Smalltalk garbageCollect. > stack := FIFOQueue new. > { > [ 1 to: 1000000 do: [ :each | stack nextPut: each ] ] timeToRun. > [ 1 to: 1000000 do: [ :each | stack next ] ] timeToRun } ] > > #(#(291 69) #(170 65) #(168 66) #(168 65) #(168 65)) > > Then i changed FIFOQueue to SharedQueue and run it again.. > waiting 1 minute.. wait a bit more.. then i came to smoke.. and after > returning, it was still running.. > i interrupted it, and inspected the queue size.. it was slightly above > 300000 items. > > Of course, SharedQueue usually not used in scenarios, where you need > to push such large number of items. > So, its just a warning. > > Btw, here is another comparison (Stack vs thread-safe LIFO queue): > > (1 to: 5) collect: [ :run | > | stack | > Smalltalk garbageCollect. > stack := Stack new. > { > [ 1 to: 1000000 do: [ :each | stack push: each ] ] timeToRun. > [ 1 to: 1000000 do: [ :each | stack pop ] ] timeToRun } ] > > Stack: > #(#(166 94) #(160 90) #(162 91) #(162 92) #(160 92)) > > LIFOQueue: > #(#(172 250) #(174 248) #(172 250) #(174 252) #(172 250)) > > Yes, it is slower (mainly for reading). But it is price for being thread safe :) > > > -- > Best regards, > Igor Stasenko AKA sig. >

Oct. 17, 2010

Re: [Pharo-project] [squeak-dev] [ANN] Atomic collections.

by StÃ©phane Ducasse

thanks I would really like to have some solid basis for such kind of issue in pharo. Stef On Oct 16, 2010, at 8:20 AM, Igor Stasenko wrote: > Hello, > > as a result of recently happened discussion about atomic operations, > i implemented two kinds of thread-safe queues FIFO and LIFO, > which using atomic operations, instead of semaphore to add/remove items. > > You may review it by loading the code from SqueakSource: > > MCHttpRepository > location: 'http://www.squeaksource.com/Atomics' > user: '' > password: '' > > > FIFOQueue scales much better than SharedQueue, and after some > additional testing can fully replace it. > > I tested FIFOQueue by replacing a SharedQueue class for EventSensor (a > core system part, responsible for delivering events). > In attached file you can find a patch, which will make your sensor to > work with FIFOQueue, after you save image, > or do 'EventSensor install'. > > There are also a heavy-concurrency tests in corresponding test > classes, which is passing ok. > > Concurrency is highly complex field, thus i won't be surprised if code > still contains a bugs. > > Code license is MIT, moreover a repository is publicly writeable, so > if you wanna add tests, benchmarks, fixes, > or implement new kind of lock-free container, feel free to do it. > > Any feedback is welcome. > > > -- > Best regards, > Igor Stasenko AKA sig. > <sensor-queue-patch.1.cs>

Oct. 17, 2010

Re: [Pharo-project] Speeding up Pharo 1.1

by StÃ©phane Ducasse

On Oct 17, 2010, at 12:37 AM, Levente Uzonyi wrote: > On Sat, 16 Oct 2010, Bart Veenstra wrote: > >> Hi list, >> >> I have been working with Pharo for almost a month now, and I suspect >> that the performance is degrading fast. UI tasks takes several seconds >> to react to my keyboard. > > That kind of sluggishness is probably related to finalization/gc. Please send us the result of the following expression: > > (WeakArray classPool at: #FinalizationDependents) > select: [ :each | each notNil ] > thenCollect: [ :each | each class -> each size ] > > There's another source of sluggishness though. The input is only processed at every 10 milliseconds (actually more rarely, because there's at least 10 ms delay between input processing). > If I evalute [InputEventPollingFetcher eventPollPeriod: 1], then Pharo 1.1 feels more responsive. > Btw it would be better to use the input semaphore instead of polling for events, like Squeak does it. I wonder why was it changed. The idea was to remove the poll behavior now I do not remember if the semaphore was removed or simply was waiting for the windows vm to get the support and was forgotten.

Oct. 17, 2010

Re: [Pharo-project] Speeding up Pharo 1.1

by StÃ©phane Ducasse

Can you check in 1.2 because I seem to remember that it was fixed? TX On Oct 16, 2010, at 8:51 PM, Nicolas Cellier wrote: > Oh, comparison was not fair, I ran Squeak with COG. > When I try COG+Pharo, some updates are missing, I can't print the VMstats.

Oct. 17, 2010

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

by StÃ©phane Ducasse

I have a question: does shout support closing parenthesis behavior? Stef On Oct 16, 2010, at 10:27 PM, Pavel Krivanek wrote: > Can we add a setting for it? (issue > http://code.google.com/p/pharo/issues/detail?id=3113) > > Cheers, > -- Pavel > > On Tue, Oct 12, 2010 at 8:58 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> thanks! >> >> >> On Oct 11, 2010, at 9:37 AM, Fernando olivero wrote: >> >>> Hi , it was a enhancement i did starting from a Chris Muller enhancement for Squeak. >>> >>> ISSUE 2653. >>> http://code.google.com/p/pharo/issues/detail?id=2653&can=1&q=auto&colspec=I… >>> >>> I did a test, maybe a good start would be to see if its failing now. >>> >>> Fernando >>> >>> On Oct 9, 2010, at 2:18 PM, Juan Vuletich wrote: >>> >>>> Hi Folks, >>>> >>>> Cuis doesn't include #autoEnclose, so I don't know how it should behave. >>>> >>>> Cheers, >>>> Juan Vuletich >>>> >>>> Mariano Martinez Peck wrote: >>>>> Guille, if I remember correctly (not sure), these new classes like >>>>> TextEditor and Smalltalk editor came from Cuis. Juan (Cuis author) i >>>>> think he is in the mailing list but not read it so frequently. So, for >>>>> this issues maybe you can cc'ed him. >>>>> >>>>> Cheers >>>>> >>>>> Mariano >>>>> >>>>> 2010/10/9 Guillermo Polito <guillermopolito(a)gmail.com >>>>> <mailto:guillermopolito@gmail.com>> >>>>> >>>>> 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 <mailto:guillermopolito@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 >>>>> <mailto:marianopeck@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 >>>>> <mailto:guillermopolito@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 >>>>> <mailto:Pharo-project@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 >>>>> <mailto:Pharo-project@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 >>>>> <mailto:Pharo-project@lists.gforge.inria.fr> >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> >>>>> No virus found in this incoming message. >>>>> Checked by AVG - www.avg.com >>>>> Version: 9.0.862 / Virus Database: 271.1.1/3184 - Release Date: 10/08/10 03:34:00 >>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> 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. 17, 2010

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

by StÃ©phane Ducasse

hi guys If you refer and change closed bug entry we will not see them. Since we look for fixed items. So please open new issues. Stef On Oct 16, 2010, at 10:27 PM, Pavel Krivanek wrote: > Can we add a setting for it? (issue > http://code.google.com/p/pharo/issues/detail?id=3113) > > Cheers, > -- Pavel > > On Tue, Oct 12, 2010 at 8:58 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> thanks! >> >> >> On Oct 11, 2010, at 9:37 AM, Fernando olivero wrote: >> >>> Hi , it was a enhancement i did starting from a Chris Muller enhancement for Squeak. >>> >>> ISSUE 2653. >>> http://code.google.com/p/pharo/issues/detail?id=2653&can=1&q=auto&colspec=I… >>> >>> I did a test, maybe a good start would be to see if its failing now. >>> >>> Fernando >>> >>> On Oct 9, 2010, at 2:18 PM, Juan Vuletich wrote: >>> >>>> Hi Folks, >>>> >>>> Cuis doesn't include #autoEnclose, so I don't know how it should behave. >>>> >>>> Cheers, >>>> Juan Vuletich >>>> >>>> Mariano Martinez Peck wrote: >>>>> Guille, if I remember correctly (not sure), these new classes like >>>>> TextEditor and Smalltalk editor came from Cuis. Juan (Cuis author) i >>>>> think he is in the mailing list but not read it so frequently. So, for >>>>> this issues maybe you can cc'ed him. >>>>> >>>>> Cheers >>>>> >>>>> Mariano >>>>> >>>>> 2010/10/9 Guillermo Polito <guillermopolito(a)gmail.com >>>>> <mailto:guillermopolito@gmail.com>> >>>>> >>>>> 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 <mailto:guillermopolito@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 >>>>> <mailto:marianopeck@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 >>>>> <mailto:guillermopolito@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 >>>>> <mailto:Pharo-project@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 >>>>> <mailto:Pharo-project@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 >>>>> <mailto:Pharo-project@lists.gforge.inria.fr> >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> >>>>> No virus found in this incoming message. >>>>> Checked by AVG - www.avg.com >>>>> Version: 9.0.862 / Virus Database: 271.1.1/3184 - Release Date: 10/08/10 03:34:00 >>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> 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. 17, 2010

Re: [Pharo-project] Speeding up Pharo 1.1

by Levente Uzonyi

On Sat, 16 Oct 2010, Bart Veenstra wrote: > Hi list, > > I have been working with Pharo for almost a month now, and I suspect > that the performance is degrading fast. UI tasks takes several seconds > to react to my keyboard. That kind of sluggishness is probably related to finalization/gc. Please send us the result of the following expression: (WeakArray classPool at: #FinalizationDependents) select: [ :each | each notNil ] thenCollect: [ :each | each class -> each size ] There's another source of sluggishness though. The input is only processed at every 10 milliseconds (actually more rarely, because there's at least 10 ms delay between input processing). If I evalute [InputEventPollingFetcher eventPollPeriod: 1], then Pharo 1.1 feels more responsive. Btw it would be better to use the input semaphore instead of polling for events, like Squeak does it. I wonder why was it changed. Levente > > At work we use VAST and I have experience with VW as well and those > smalltaks react to my keyboard and mouse actions instantly. But Pharo > works very sluggish. > > My image is about 130MB because I have loaded all dutch postcode in > memory, but that should not affect the performance of general > operations like typing with the keyboard. I am not a fast typer, but > sometimes it takes seconds to show my keyboard input. I can't use the > down key to select the right method from suggestions, because it seems > to lockup completely. > > Are there ways to speedup Pharo? I would love to use cogVM but I > haven't got gemtools working on it... > > Will upgrading to 1.1.1 fix these issues? > > Is my OS (Windows 7-64bit) causing these issues? > > Regards, > > Bart > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 16, 2010

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

by Pavel Krivanek

Can we add a setting for it? (issue http://code.google.com/p/pharo/issues/detail?id=3113) Cheers, -- Pavel On Tue, Oct 12, 2010 at 8:58 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > thanks! > > > On Oct 11, 2010, at 9:37 AM, Fernando olivero wrote: > >> Hi , it was a enhancement i did starting from a Chris Muller enhancement for Squeak. >> >> ISSUE 2653. >> http://code.google.com/p/pharo/issues/detail?id=2653&can=1&q=auto&colspec=I… >> >> I did a test, maybe a good start would be to see if its failing now. >> >> Fernando >> >> On Oct 9, 2010, at 2:18 PM, Juan Vuletich wrote: >> >>> Hi Folks, >>> >>> Cuis doesn't include #autoEnclose, so I don't know how it should behave. >>> >>> Cheers, >>> Juan Vuletich >>> >>> Mariano Martinez Peck wrote: >>>> Guille, if I remember correctly (not sure), these new classes like >>>> TextEditor and Smalltalk editor came from Cuis. Juan (Cuis author) i >>>> think he is in the mailing list but not read it so frequently. So, for >>>> this issues maybe you can cc'ed him. >>>> >>>> Cheers >>>> >>>> Mariano >>>> >>>> 2010/10/9 Guillermo Polito <guillermopolito(a)gmail.com >>>> <mailto:guillermopolito@gmail.com>> >>>> >>>> Â Â 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 <mailto:guillermopolito@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 >>>> Â Â Â Â <mailto:marianopeck@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 >>>> Â Â Â Â Â Â <mailto:guillermopolito@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 >>>> Â Â Â Â Â Â Â Â <mailto:Pharo-project@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 >>>> Â Â Â Â Â Â <mailto:Pharo-project@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 >>>> Â Â <mailto:Pharo-project@lists.gforge.inria.fr> >>>> Â Â http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> No virus found in this incoming message. >>>> Checked by AVG - www.avg.com >>>> Version: 9.0.862 / Virus Database: 271.1.1/3184 - Release Date: 10/08/10 03:34:00 >>>> >>>> >>> >>> >>> _______________________________________________ >>> 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. 16, 2010