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

[Pharo-project] [update 1.2] #12195
by StÃ©phane Ducasse Oct. 17, 2010

Oct. 17, 2010

12195 ----- - Issue 3113: TextEditor autoEnclose settings. Thanks Pavel Krivanek. - Issue 3110: ProjectLauncher readDocumentAtStartup needs a setting. Thanks Pavel Krivanek. - Issue 3103: better Morphic detection in AutoStart startUp:. Thanks Pavel Krivanek. - Issue 3102: removeAllButPackages: hackish method. Thanks Pavel Krivanek.

1 0

[Pharo-project] Missing Close in About Dialog
by Bernhard Pieber Oct. 17, 2010

Oct. 17, 2010

Dear Pharo Folks, It is a very minor thing but I wanted to let you know that the About Dialog (World Menu > System > Aboutâ¦) in the latest stable Pharo Dev image (Pharo-1.1.1-dev10.09.1) has not got any Close button. Cheers, Bernhard

2 2

Re: [Pharo-project] bad bracket autocompletion in Pharo Core 1.2
by StÃ©phane Ducasse Oct. 17, 2010

Oct. 17, 2010

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

2 1

[Pharo-project] [ANN] Atomic collections.
by Igor Stasenko Oct. 17, 2010

Oct. 17, 2010

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.

2 1

Re: [Pharo-project] Speeding up Pharo 1.1
by StÃ©phane Ducasse Oct. 17, 2010

Oct. 17, 2010

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.

1 0

Re: [Pharo-project] Speeding up Pharo 1.1
by StÃ©phane Ducasse Oct. 17, 2010

Oct. 17, 2010

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.

1 0

Re: [Pharo-project] bad bracket autocompletion in Pharo Core 1.2
by StÃ©phane Ducasse Oct. 17, 2010

Oct. 17, 2010

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

1 0

Oct. 16, 2010

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

2 1

[Pharo-project] Experimental Cocoa OS-X based Squeak Cog JIT VM 5.8b12
by John M McIntosh Oct. 16, 2010

Oct. 16, 2010

I've stuck a version (5.8b12) of the cocoa based os-x squeak cog JIT based VM in my experimental folder. http://homepage.mac.com/johnmci/.Public/experimental/Squeak%205.8b12.app.zip This is based on the latest Cog VM source (oct 10/10/10). Changes to the support logic: (a) Supply file create/mod times & size based on target of symbolic link versus the link file node. (b) Untrusted directory was set wrong, use same default value as 4.2.x VM ~/Library/Preferences/Squeak/Internet/My Squeak/ (c) There is no -pathenc option (d) Attempt to integrate changes into Cog branch to allow you to compile VM from the Cog branch. *** This does not work yet, 90% there, Eliot and I still have some pencil sharping to do... *** Now the big news is that I pushed a version of the Squeak Cog stack VM to the Apple App Store! It's rough, but it's a candidate for review by Apple's special App review committee. It does not have socket support and we are seeing if they allow us to move image/change files in and out of the Documents folder via a desktop machine. I should know more by next weekend. If accepted then I am looking to the Smalltalk community to help in building a viable image to allow people to edit source code on an iPad. Lastly, yes something broken in open/gl on os-x 10.4 I hope to look at the issue this week. -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

3 2

Re: [Pharo-project] Xtreams vs become:
by mkobetic＠gmail.com Oct. 16, 2010

Oct. 16, 2010

"Nicolas Cellier"<nicolas.cellier.aka.nice(a)gmail.com> wrote: > I've tested this strategy, and it works well: > > - use accessors self input/self output instead of inst. var. > - lazily initialize the input for Collection and File Sounds good to me, less work too. I just thought the write:read: approach makes it clearer that you need to do all the writing first and then all the reading. But that'll probably become clear quite quickly. So I think I'll go with your approach. The only case I wonder about is the one where we loop with progressively larger buffer sizes, so we'll need to be able to rebuild the input and output several times. I'll see if I can figure something out. > In collection tests, I have used > ^input ifNil:[input := outer terminal reading] > where: outer := output := collection writing. > This is because some Block transforms can't access the terminal collection... Not sure what you mean, but it will probably get clearer when I go do it. BTW, I've updated the package comments and regenerated the docs on the site yesterday. If you want to see the changes highlighted, go through the Sources tab and switch to the wiki repository. The diff view is quite usable there. Martin

2 1