August 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Disable the debugger

by StÃ©phane Ducasse

would be nice to have a class responsible for that and that slowly we get a complete system ready for this kind of deployement Stef On Aug 2, 2011, at 7:06 PM, Mariano Martinez Peck wrote: > Check in older Pharo images like 1.1.1 all the stuff in #disableProgrammerFacilities > > > disableProgrammerFacilities > "Warning: do not call this lightly! It disables all access to menus, debuggers, halos. There is no guaranteed return from this, which is to say, you cannot necessarily reenable these things once they are disabled -- you can only use whatever the UI of the current project affords, and you cannot even snapshot -- you can only quit. > > You can completely reverse the work of this method by calling the dual Preferences method enableProgrammerFacilities, provided you have left yourself leeway to bring about a call to that method. > (does not reverse the ToolSet registrations) > > To set up a system that will come up in such a state, you have to request the snapshot in the same breath as you disable the programmer facilities. To do this, put the following line into the 'do' menu and then evaluate it from that 'do' menu: > > Preferences disableProgrammerFacilities. > > You will be prompted for a new image name under which to save the resulting image." > self deprecated: 'No replacement for now'. > > Beeper beep. > (self > confirm: 'CAUTION!! > This is a drastic step! > Do you really want to do this?') > ifFalse: > [Beeper beep. > ^self inform: 'whew!']. > self disable: #cmdDotEnabled. "No user-interrupt-into-debugger" > self disable: #editableStringMorphs. "turn off shift-click editing" > ToolSet registeredClasses copy do: [:c | ToolSet unregister: c]. > ToolSet default: nil. "unregister and make sure default is nil to really prevent debug windows" > "also now takes care of low space watcher interrupts" > self compileHardCodedPref: #cmdGesturesEnabled enable: false. "No halos, etc." > self compileHardCodedPref: #cmdKeysInText enable: false. "No user commands invokable via cmd-key combos in text editor" > self enable: #noviceMode. "No control-menu" > self disable: #warnIfNoSourcesFile. > self disable: #warnIfNoChangesFile. > Smalltalk saveAs > > On Tue, Aug 2, 2011 at 5:59 PM, laurent laffont <laurent.laffont(a)gmail.com> wrote: > Hi, > > is it possible to disable the debugger in a Seaside image for production ? > > Laurent Laffont - @lolgzs > > Pharo Smalltalk Screencasts: http://www.pharocasts.com/ > Blog: http://magaloma.blogspot.com/ > Developer group: http://cara74.seasidehosting.st > > > > > -- > Mariano > http://marianopeck.wordpress.com >

Aug. 2, 2011

Re: [Pharo-project] Polymorph improvements

by StÃ©phane Ducasse

thanks for sharing that with us. BTW did you see my question (some weeks ago) about minimalExtent or maximalExtent for window it seems that it is totally unused. Stef > Screenshot of part of project: http://www.flickr.com/photos/12018791@N06/6001799235/in/photostream > > Regards, Gary > ----- Original Message ----- > From: Gary Chambers > To: Pharo Development > Sent: Tuesday, August 02, 2011 4:40 PM > Subject: [Pharo-project] Polymorph improvements > > Hi all. > > I've added an issue with some tweaks/improvements to a few Polymorph classes. > > http://code.google.com/p/pharo/issues/detail?id=4590 > > Groupboxes can now have dynamic content (model/getContentSelector based). > Abaility to create icon lists via builder/TEasilyThemed. > Expander labels now LabelMorphs rather than TextMorphs (can therefore appear as disabled) > IncrementalSliderMorphs now honour minWidth/minHeight in layouts > Panel morphs allow event based mouse over handling (call to super was missing). > Label groups allow for nil labels (equates to empty string) > > Regards, Gary

Aug. 2, 2011

Re: [Pharo-project] identityHash bits not incremented for new objects?

by StÃ©phane Ducasse

+ 10000000 >>>>>>> >> > > Please include a comment with that. :) > Like this has shown, it's rather hard to know wtf to do when you can't unambiguously read what its actually intended to test from the code itself. > > Cheers, > Henry > >

Aug. 2, 2011

Re: [Pharo-project] trait method tagging is not consistent

by StÃ©phane Ducasse

strange! Stef On Aug 2, 2011, at 3:33 PM, Veronica Isabel Uquillas Gomez wrote: > > On 01 Aug 2011, at 21:30, StÃ©phane Ducasse wrote: > >> (SourceFiles sourcedDataAt: (Point>>#dist:) sourcePointer) >> 'Point methodsFor: ''point functions'' stamp: ''lr 7/4/2009 10:42''' >> >> >> SourceFiles sourcedDataAt: (ComposableMorph>>#newToolSpacer) sourcePointer >> 'Trait method' >> > > Stef, for this example I am getting: > 'ComposableMorph methodsFor: ''controls''' > > Only the stamp is missing. I tried in Pharo 1.3 and Pharo 1.4 > >> >> so protocol, stamp: .... got confused. >> >> http://code.google.com/p/pharo/issues/detail?id=4581 >> >> Stef >> >> > >

Aug. 2, 2011

Re: [Pharo-project] a.4 combox box bug

by StÃ©phane Ducasse

No problem :) Indeed this method was really strange and this is why we were wrong thinking that our semantics was better. Stef >> :) >> >> delete or delete => remove delete :) >> > > Disregard my last mail. > That's what I get for not read mail for couple of days, then briefly scan list for replies, and miss one :) > > Cheers, > Henry

Aug. 2, 2011

Re: [Pharo-project] [squeak-dev] Optimizing RunArray

by Nicolas Cellier

Normal text editing (inserting) follows that path and main RunArray operation is #copyReplaceFrom:to:with: It seems it could be marginally optimized, but I don't think this would be noticed at all. Anyway, the operation never appear on a MessageTally (maybe I should try again with a huge Text). TextMorph handleKeyStroke: TextMorphForEditView keyStroke: TextMorph keyStroke: TextMorphForEditView handleInteraction:fromEvent: TextMorph handleInteraction:fromEvent: TextEditor readKeyboard TextEditor dispatchOnCharacter:with: TextEditor normalCharacter: TextEditor zapSelectionWith: NewParagraph replaceFrom:to:with: Text replaceFrom:to:with: RunArray copyReplaceFrom:to:with: Nicolas 2011/8/2 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > No, I wanted to reuse RunArray for other purposes, that's why the > methods weren't optimized. > For Text, the major operation is ... Hmm wait, this is really hard to > track by just reading code, and debugging it is not that easy ! > > Nicolas > > 2011/8/2 Bert Freudenberg <bert(a)freudenbergs.de>: >> On 02.08.2011, at 10:17, Nicolas Cellier wrote: >> >>> I played a bit with RunArray, and found some un-optimized features. >>> First, I don't know why RunArray is an ArrayedCollection. It cannot >>> #add: but it can #addFirst: and #addLast:. >>> It cannot #add:withOccurrences: but it can #addLast:times:. Why >>> inventing new selectors for old behaviours ? >> >> The RunArray selectors may in fact precede the more common ones. RunArray's purpose was to make Text operations efficient. I think that's still the only actual use of RunArrays. In any case, speeding up Text is a good idea, though you might want to check what methods it actually uses. >> >> - Bert - >> >>> These operations will cost a realloc it the last value is different, >>> so the underlying runs/values could better be an OrderedCollection if >>> these operations are used often. >>> A RunArray cannot remove at all. >>> Very weird collection species, I don't like the implementation too much. >>> >>> Then, #do: loops could be far faster. They rely on ArrayedCollection >>> which inlines do: loops with #to:do: and #at: >>> But #at: is not that fast. Scanning the runs and counting elements >>> would result in a n^2 cost. >>> Fortunately there is a cache lastIndex,lastRun,lastOffset to keep a cost n. >>> Nonetheless, all the tests cost, and the loop is suboptimal. >>> Let use see: >>> >>> version 1: >>> RunArray>>fastDo: aBlock >>> Â Â Â runs with: values do: [:r :v | >>> Â Â Â Â Â Â Â r timesRepeat: [aBlock value: v]]. >>> >>> | tmp | >>> tmp := ((Array new: 1000) collect: [:e | 4 atRandom]) as: RunArray. >>> { >>> [ tmp do: [:e |]] bench. >>> [ tmp fastDo: [:e |]] bench. >>> } >>> #('3,220 per second.' '6,290 per second.') >>> >>> But timesRepeat: is slow, it is unoptimized by the compiler and costs >>> a message send. >>> I think we should implement BlockClosure>>repeat: and optimize that >>> call in Compiler. >>> But let's not do it, and rather inline by ourself: >>> >>> version 2: >>> Â Â Â runs with: values do: [:r :v | >>> Â Â Â Â Â Â Â 1 to: r do: [:i | aBlock value: v]]. >>> >>> | tmp | >>> tmp := ((Array new: 1000) collect: [:e | 4 atRandom]) as: RunArray. >>> { >>> [ tmp do: [:e |]] bench. >>> [ tmp do2: [:e |]] bench. >>> } >>> #('3,070 per second.' '25,500 per second.') >>> >>> We can even inline the with:do: loop itself: >>> version 3: >>> Â Â Â 1 to: runs size do: [:i | >>> Â Â Â Â Â Â Â | r v | >>> Â Â Â Â Â Â Â v := values at: i. >>> Â Â Â Â Â Â Â r := runs at: i. >>> Â Â Â Â Â Â Â [( r := r - 1) >= 0] >>> Â Â Â Â Â Â Â Â Â Â Â whileTrue: [aBlock value: v]]. >>> >>> | tmp | >>> tmp := ((Array new: 1000) collect: [:e | 4 atRandom]) as: RunArray. >>> { >>> [ tmp do: [:e |]] bench. >>> [ tmp do2: [:e |]] bench. >>> } >>> #('3,370 per second.' '32,200 per second.') >>> >>> Now the operation I wanted to use was reverseDo: so I implemented: >>> RunArray>>fastReverseDo: aBlock >>> Â Â Â | i | >>> Â Â Â i := runs size. >>> Â Â Â [i > 0] >>> Â Â Â Â Â Â Â whileTrue: >>> Â Â Â Â Â Â Â Â Â Â Â [ | r v | >>> Â Â Â Â Â Â Â Â Â Â Â v := values at: i. >>> Â Â Â Â Â Â Â Â Â Â Â r := runs at: i. >>> Â Â Â Â Â Â Â Â Â Â Â i := i - 1. >>> Â Â Â Â Â Â Â Â Â Â Â [( r := r - 1) >= 0] >>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â whileTrue: [aBlock value: v]]. >>> | tmp | >>> tmp := ((Array new: 1000) collect: [:e | 4 atRandom]) as: RunArray. >>> { >>> [ tmp reverseDo: [:e |]] bench. >>> [ tmp reverseDo2: [:e |]] bench. >>> } >>> #('83.9 per second.' '32,600 per second.') >>> >>> Ouch! The cache is missing a lot of indices, and our loop turns into a n^2 cost. >>> I know, premature optimization bla bla bla, but a factor x400 is worth >>> some inlining no? >>> >>> I guess these features are never used. >>> By now RunArray is kind of private utility for Text implementation. >>> But it could / should be generic. >>> >>> I also have proposals for count: / select: / collect:. etc... >>> It would be to evaluate the block only once per group of values. >>> For example >>> RunArray>>collect: aBlock >>> Â Â Â "Beware, the block will be evaluated only once per group of values." >>> Â Â Â ^(self class runs: (runs collect: aBlock) contents values: values >>> copy) coalesce >>> But that's controversial, it would make the RunArray behave >>> differently if the block has side effects... >>> >>> | i tmp tmp2 tmp3 | >>> tmp := ((Array new: 1000) collect: [:e | 4 atRandom]). >>> i := 0. >>> tmp2 := tmp collect: [:e | i := i + 1]. >>> i := 0. >>> tmp3 := (tmp as: RunArray) collect: [:e | i := i + 1]. >>> tmp2 = tmp3 asArray >>> ==> false >>> >>> Nicolas >>> >> >> >> >> >

Aug. 2, 2011

Re: [Pharo-project] [squeak-dev] Optimizing RunArray

by Nicolas Cellier

No, I wanted to reuse RunArray for other purposes, that's why the methods weren't optimized. For Text, the major operation is ... Hmm wait, this is really hard to track by just reading code, and debugging it is not that easy ! Nicolas 2011/8/2 Bert Freudenberg <bert(a)freudenbergs.de>: > On 02.08.2011, at 10:17, Nicolas Cellier wrote: > >> I played a bit with RunArray, and found some un-optimized features. >> First, I don't know why RunArray is an ArrayedCollection. It cannot >> #add: but it can #addFirst: and #addLast:. >> It cannot #add:withOccurrences: but it can #addLast:times:. Why >> inventing new selectors for old behaviours ? > > The RunArray selectors may in fact precede the more common ones. RunArray's purpose was to make Text operations efficient. I think that's still the only actual use of RunArrays. In any case, speeding up Text is a good idea, though you might want to check what methods it actually uses. > > - Bert - > >> These operations will cost a realloc it the last value is different, >> so the underlying runs/values could better be an OrderedCollection if >> these operations are used often. >> A RunArray cannot remove at all. >> Very weird collection species, I don't like the implementation too much. >> >> Then, #do: loops could be far faster. They rely on ArrayedCollection >> which inlines do: loops with #to:do: and #at: >> But #at: is not that fast. Scanning the runs and counting elements >> would result in a n^2 cost. >> Fortunately there is a cache lastIndex,lastRun,lastOffset to keep a cost n. >> Nonetheless, all the tests cost, and the loop is suboptimal. >> Let use see: >> >> version 1: >> RunArray>>fastDo: aBlock >> Â Â Â runs with: values do: [:r :v | >> Â Â Â Â Â Â Â r timesRepeat: [aBlock value: v]]. >> >> | tmp | >> tmp := ((Array new: 1000) collect: [:e | 4 atRandom]) as: RunArray. >> { >> [ tmp do: [:e |]] bench. >> [ tmp fastDo: [:e |]] bench. >> } >> #('3,220 per second.' '6,290 per second.') >> >> But timesRepeat: is slow, it is unoptimized by the compiler and costs >> a message send. >> I think we should implement BlockClosure>>repeat: and optimize that >> call in Compiler. >> But let's not do it, and rather inline by ourself: >> >> version 2: >> Â Â Â runs with: values do: [:r :v | >> Â Â Â Â Â Â Â 1 to: r do: [:i | aBlock value: v]]. >> >> | tmp | >> tmp := ((Array new: 1000) collect: [:e | 4 atRandom]) as: RunArray. >> { >> [ tmp do: [:e |]] bench. >> [ tmp do2: [:e |]] bench. >> } >> #('3,070 per second.' '25,500 per second.') >> >> We can even inline the with:do: loop itself: >> version 3: >> Â Â Â 1 to: runs size do: [:i | >> Â Â Â Â Â Â Â | r v | >> Â Â Â Â Â Â Â v := values at: i. >> Â Â Â Â Â Â Â r := runs at: i. >> Â Â Â Â Â Â Â [( r := r - 1) >= 0] >> Â Â Â Â Â Â Â Â Â Â Â whileTrue: [aBlock value: v]]. >> >> | tmp | >> tmp := ((Array new: 1000) collect: [:e | 4 atRandom]) as: RunArray. >> { >> [ tmp do: [:e |]] bench. >> [ tmp do2: [:e |]] bench. >> } >> #('3,370 per second.' '32,200 per second.') >> >> Now the operation I wanted to use was reverseDo: so I implemented: >> RunArray>>fastReverseDo: aBlock >> Â Â Â | i | >> Â Â Â i := runs size. >> Â Â Â [i > 0] >> Â Â Â Â Â Â Â whileTrue: >> Â Â Â Â Â Â Â Â Â Â Â [ | r v | >> Â Â Â Â Â Â Â Â Â Â Â v := values at: i. >> Â Â Â Â Â Â Â Â Â Â Â r := runs at: i. >> Â Â Â Â Â Â Â Â Â Â Â i := i - 1. >> Â Â Â Â Â Â Â Â Â Â Â [( r := r - 1) >= 0] >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â whileTrue: [aBlock value: v]]. >> | tmp | >> tmp := ((Array new: 1000) collect: [:e | 4 atRandom]) as: RunArray. >> { >> [ tmp reverseDo: [:e |]] bench. >> [ tmp reverseDo2: [:e |]] bench. >> } >> #('83.9 per second.' '32,600 per second.') >> >> Ouch! The cache is missing a lot of indices, and our loop turns into a n^2 cost. >> I know, premature optimization bla bla bla, but a factor x400 is worth >> some inlining no? >> >> I guess these features are never used. >> By now RunArray is kind of private utility for Text implementation. >> But it could / should be generic. >> >> I also have proposals for count: / select: / collect:. etc... >> It would be to evaluate the block only once per group of values. >> For example >> RunArray>>collect: aBlock >> Â Â Â "Beware, the block will be evaluated only once per group of values." >> Â Â Â ^(self class runs: (runs collect: aBlock) contents values: values >> copy) coalesce >> But that's controversial, it would make the RunArray behave >> differently if the block has side effects... >> >> | i tmp tmp2 tmp3 | >> tmp := ((Array new: 1000) collect: [:e | 4 atRandom]). >> i := 0. >> tmp2 := tmp collect: [:e | i := i + 1]. >> i := 0. >> tmp3 := (tmp as: RunArray) collect: [:e | i := i + 1]. >> tmp2 = tmp3 asArray >> ==> false >> >> Nicolas >> > > > >

Aug. 2, 2011

Re: [Pharo-project] [squeak-dev] Re: SS down?

by Tobias Pape

You may want to temporarily push to http://ss3.gemstone.com/ and copy from there to squeaksource.com when it's up again :) best -tobias Am 2011-08-02 um 09:24 schrieb laurent laffont: > grrrrrrrrrrrrrrrrrrr............... > > Laurent > > > On Tue, Aug 2, 2011 at 8:10 AM, Alexander LazareviÄ <laza(a)blobworks.com> wrote: > http://www.downforeveryoneorjustme.com/squeaksource.com > > Alex > >

Aug. 2, 2011

[Pharo-project] [update 1.4] #14071

by Marcus Denker

14071 ----- Issue 4582: Failing tests: CompiledMethodTest restReadField and testWriteField http://code.google.com/p/pharo/issues/detail?id=4582 Issue 4583: Undeclared in #allLocalCallsOn:ofClass: http://code.google.com/p/pharo/issues/detail?id=4583 Issue 4585: Failing Test: uncategorized methods in MethodReference http://code.google.com/p/pharo/issues/detail?id=4585 Issue 4584: Undeclared in #doTestDebuggerTempAccessWith:with: http://code.google.com/p/pharo/issues/detail?id=4584 Issue 4588: Failing test: #testSizeInMemoryNormalClasses http://code.google.com/p/pharo/issues/detail?id=4588 Issue 4590: Polymorph improvements http://code.google.com/p/pharo/issues/detail?id=4590 -- Marcus Denker -- http://marcusdenker.de

Aug. 2, 2011

Re: [Pharo-project] Disable the debugger

by Igor Stasenko

ToolSet is deprecated in 1.4 (will be removed) Use Smalltalk tools instead. On 2 August 2011 19:06, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Check in older Pharo images like 1.1.1 all the stuff in > #disableProgrammerFacilities > > > disableProgrammerFacilities > Â Â Â "Warning: do not call this lightly!Â It disables all access to menus, > debuggers, halos.Â There is no guaranteed return from this, which is to say, > you cannot necessarily reenable these things once they are disabled -- you > can only use whatever the UI of the current project affords, and you cannot > even snapshot -- you can only quit. > > Â Â Â Â You can completely reverse the work of this method by calling the dual > Preferences method enableProgrammerFacilities, provided you have left > yourself leeway to bring about a call to that method. > (does not reverse the ToolSet registrations) > > Â Â Â To set up a system that will come up in such a state, you have to > request the snapshot in the same breath as you disable the programmer > facilities.Â To do this, put the following line into the 'do' menu and then > evaluate it from that 'do' menu: > > Â Â Â Â Â Â Â Â Preferences disableProgrammerFacilities. > > You will be prompted for a new image name under which to save the resulting > image." > Â Â Â self deprecated: 'No replacement for now'. > > Â Â Â Beeper beep. > Â Â Â (self > Â Â Â Â Â Â confirm: 'CAUTION!! > This is a drastic step! > Do you really want to do this?') > Â Â Â Â Â Â Â Â Â ifFalse: > Â Â Â Â Â Â Â Â Â Â Â Â [Beeper beep. > Â Â Â Â Â Â Â Â Â Â Â Â ^self inform: 'whew!']. > Â Â Â self disable: #cmdDotEnabled.Â Â Â "No user-interrupt-into-debugger" > Â Â Â self disable: #editableStringMorphs. "turn off shift-click editing" > Â Â Â ToolSet registeredClasses copy do: [:c | ToolSet unregister: c]. > Â Â Â ToolSet default: nil. "unregister and make sure default is nil to really > prevent debug windows" > Â Â Â Â Â Â "also now takes care of low space watcher interrupts" > Â Â Â self compileHardCodedPref: #cmdGesturesEnabled enable: false.Â Â Â "No > halos, etc." > Â Â Â self compileHardCodedPref: #cmdKeysInText enable: false.Â Â Â "No user > commands invokable via cmd-key combos in text editor" > Â Â Â self enable: #noviceMode.Â Â Â "No control-menu" > Â Â Â self disable: #warnIfNoSourcesFile. > Â Â Â self disable: #warnIfNoChangesFile. > Â Â Â Smalltalk saveAs > > On Tue, Aug 2, 2011 at 5:59 PM, laurent laffont <laurent.laffont(a)gmail.com> > wrote: >> >> Hi, >> is it possible to disable the debugger in a Seaside image for production >> ? >> Laurent Laffont -Â @lolgzs >> >> Pharo Smalltalk Screencasts: http://www.pharocasts.com/ >> Blog: http://magaloma.blogspot.com/ >> Developer group: http://cara74.seasidehosting.st > > > > -- > Mariano > http://marianopeck.wordpress.com > > -- Best regards, Igor Stasenko AKA sig.

Aug. 2, 2011