- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] specialSelectors

by Marcus Denker

On Sep 4, 2013, at 12:08 AM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > I note that #class was removed from specialSelectors (nilled entry) so as to not use the VM hack which fetches the class without sending a message. > Pharo prefers the regular message send. > But next to that entry, there is #blockCopy: which was formerly used for blue book BlockContext. > BlockContext was removed from Pharo... > So that makes two available slots for optimizing most used (sent) messages... > We might choose some candidates and test on some macro benchmark if ever that really makes a difference. I am not sure if optimizations on that level make senseâ¦ Marcus

Sept. 4, 2013

Re: [Pharo-dev] Switching context(s) in browser while method is not-yet accepted

by Norbert Hartl

Am 03.09.2013 um 15:07 schrieb Igor Stasenko <siguctua(a)gmail.com>: > > this is most annoying to me, that UI interrupts you in very strange manner > and asks you to make a decision: > - accept, or discard the method, or cancel the action. > > often, you are in the middle of typing new stuff and source code > can be even not syntactically correct.. so, you have to discard or die :) > > what i think the solution could be is that browser should allow you to switch contexts > at any moment without asking you anything.Instead it should remember your > unsaved changes in special 'drafts' collection, which later you can get back on, > when you finish what you wanted to do. > > And the only time when you want unaccepted edits to not get lost forever is when you closing > a browser window.. (but of course, drafts can be stored globally somewhere, > then it also not a big deal, since you can simply return to your draft in different window). We have method versions. I don't see a reason why uncommited methods can not go just on the list. They could be marked as unsaved/unommited (in fact they are not compiled so different per se) or even better the method version list should be a timeline where the current version is the present and everything else is a past or a potential future version. Norbert

Sept. 4, 2013

Re: [Pharo-dev] OSProcess for Pharo3.0

by Marcus Denker

On Sep 4, 2013, at 4:52 AM, "David T. Lewis" <lewis(a)mail.msen.com> wrote: > On Tue, Sep 03, 2013 at 01:48:46PM +0200, Goubier Thierry wrote: >> >> Le 03/09/2013 13:36, David T. Lewis a ?crit : >>> >>> Can you post the method here first? I'd like to check it on some Squeak >>> images >>> before it goes into the repository. >> >> Here it is (at least an example): >> >> in OSProcess class >> >> isPharo3AndLater >> "Test if we are on Pharo 3.0" >> >> ^ (Smalltalk classNamed: 'SystemVersion') >> ifNil: [ false ] >> ifNotNil: [ :v | v current type = 'Pharo' and: [ v current >> major >= 3 ] ] > > The idea is right, but the details can be a PITA ;-) > > - In Squeak trunk, class SystemVersion exists. But it does not understand #type, so this fails at runtime. > > - There are no implementors of #major in Squeak (but this can be rewritten using #perform:). > > - In Squeak 3.8, #ifNil:ifNotNil: requires a block with no arguments. > Why do you need to support Squeak 3.8? This is how many years old? I really do not understand this idea to be compatible to all old versions ever. In the end it will just make sure that no progress is possible at all. Marcus

Sept. 4, 2013

Re: [Pharo-dev] OSProcess for Pharo3.0

by David T. Lewis

On Tue, Sep 03, 2013 at 01:48:46PM +0200, Goubier Thierry wrote: > > Le 03/09/2013 13:36, David T. Lewis a ?crit : > > > >Can you post the method here first? I'd like to check it on some Squeak > >images > >before it goes into the repository. > > Here it is (at least an example): > > in OSProcess class > > isPharo3AndLater > "Test if we are on Pharo 3.0" > > ^ (Smalltalk classNamed: 'SystemVersion') > ifNil: [ false ] > ifNotNil: [ :v | v current type = 'Pharo' and: [ v current > major >= 3 ] ] The idea is right, but the details can be a PITA ;-) - In Squeak trunk, class SystemVersion exists. But it does not understand #type, so this fails at runtime. - There are no implementors of #major in Squeak (but this can be rewritten using #perform:). - In Squeak 3.8, #ifNil:ifNotNil: requires a block with no arguments. I did not check the other Pharo versions. Something like this might work: isPharo3AndLater Smalltalk at: #SystemVersion ifPresent: [:cls | ((cls canUnderstand: #type) and: [ cls canUnderstand: #major ]) ifTrue: [^ cls current type = 'Pharo' and: [ cls current major >= 3 ]]]. ^false Dave > > platformName > "After Squeak version 3.6, #platformName was moved to SmalltalkImage > Some > versions of Pharo move this to OSPlatform and issue deprecation > warnings > about the other usages. Then Pharo moved away from OSPlatform and > deprecated > its use." > > "self platformName" > > self isPharo3AndLater > ifTrue: [ ^ Smalltalk os name ]. > ^ (((Smalltalk hasClassNamed: #OSPlatform) > and: [(Smalltalk at: #OSPlatform) > respondsTo: #platformName]) > ifTrue: [Smalltalk at: #OSPlatform] > ifFalse: [((Smalltalk classNamed: 'SmalltalkImage') > ifNil: [^ Smalltalk osVersion]) current]) > platformName > > >Thanks! > >Dave > > > >> > >>>Dave > >>> > >>> > >>> > >>> > >> > >>-- > >>Thierry Goubier > >>CEA list > >>Laboratoire des Fondations des Syst?mes Temps R?el Embarqu?s > >>91191 Gif sur Yvette Cedex > >>France > >>Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 > > > > > > > > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des Syst?mes Temps R?el Embarqu?s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Sept. 4, 2013

Re: [Pharo-dev] specialSelectors

by Nicolas Cellier

Hmm... my timings are not reliable, I tried again with IRByteCodeGenerator>> specialSelectorsArray ^ #(#+ 1 #- 1 #< 1 #> 1 #<= 1 #>= 1 #= 1 #~= 1 #* 1 #/ 1 #\\ 1 #@ 1 #bitShift: 1 #// 1 #bitAnd: 1 #bitOr: 1 #at: 1 #at:put: 2 #size 0 #next 0 #nextPut: 1 #atEnd 0 #== 1 nil 0 nil 0 #value 0 #value: 1 #do: 1 #new 0 #new: 1 #x 0 #y 0) Recompiled all: IRBytecodeGenerator initializeSpecialSelectors. Smalltalk specialObjectsArray at: 24 put: IRBytecodeGenerator specialSelectorsArray. OpalCompiler recompileAll. and got a fast run 84446 too without optimizing assert: so it looks just like a space optimization. 2013/9/4 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> > > Well, #class slot is not really available because the trick is hardcoded > in the VM as well as == trick, so no lookup in specialSelectors > (specailObjectsArray at: 24) is attempted for these 2. > COG also optimize some arithmetic messages, comparisons, bit ops, and all > is hardcoded in the VM, so better not playing with those indices. > > So I tried to just replace #blockCopy: 1 with #not 0, ran some tests but > saw no significative speed up. > > Then I tried to run Kernel tests twice in a unmodified 3.0 image > > [(Smalltalk allClasses > select: [:e | (e category beginsWith: 'KernelTests') > and: [e inheritsFrom: TestCase]]) > do: [:e | e suite run]] timeToRun. > 113342 114337 > > Then optimized the mosttly sent message during tests : > > IRByteCodeGenerator>>specialSelectorsArray > > ^ #(#+ 1 #- 1 #< 1 #> 1 #<= 1 #>= 1 #= 1 #~= 1 #* 1 #/ 1 #\\ 1 #@ 1 > #bitShift: 1 #// 1 #bitAnd: 1 #bitOr: 1 #at: 1 #at:put: 2 #size 0 #next 0 > #nextPut: 1 #atEnd 0 #== 1 nil 0 #assert: 1 #value 0 #value: 1 #do: 1 #new > 0 #new: 1 #x 0 #y 0) > > Recompiled all: > > IRBytecodeGenerator initializeSpecialSelectors. > Smalltalk specialObjectsArray at: 24 put: IRBytecodeGenerator > specialSelectorsArray. > OpalCompiler recompileAll. > > Then tried the tests twice again: > > [(Smalltalk allClasses > select: [:e | (e category beginsWith: 'KernelTests') > and: [e inheritsFrom: TestCase]]) > do: [:e | e suite run]] timeToRun. > 84328 83974 > > So it seems like it's not just a space optimization but also a speed one, > and I don't know why... > It would be better if someone could repeat these results... > > Nicolas > > > 2013/9/4 Camillo Bruni <camillobruni(a)gmail.com> > >> that would actually be interesting on how much you win by doing so, and >> if you could run this dynamically (for instance reintroduce the #class >> optimization if you never override it in the image)... >> >> >> On 2013-09-03, at 19:07, Nicolas Cellier < >> nicolas.cellier.aka.nice(a)gmail.com> wrote: >> > I note that #class was removed from specialSelectors (nilled entry) so >> as >> > to not use the VM hack which fetches the class without sending a >> message. >> > Pharo prefers the regular message send. >> > But next to that entry, there is #blockCopy: which was formerly used for >> > blue book BlockContext. >> > BlockContext was removed from Pharo... >> > So that makes two available slots for optimizing most used (sent) >> > messages... >> > We might choose some candidates and test on some macro benchmark if ever >> > that really makes a difference. >> >> >

Sept. 4, 2013

Re: [Pharo-dev] specialSelectors

by Mariano Martinez Peck

On Tue, Sep 3, 2013 at 7:14 PM, Camillo Bruni <camillobruni(a)gmail.com>wrote: > that would actually be interesting on how much you win by doing so, and if > you could run this dynamically (for instance reintroduce the #class > optimization if you never override it in the image)... > > Please don't. Sometimes this is useful for proxies.... > > On 2013-09-03, at 19:07, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> wrote: > > I note that #class was removed from specialSelectors (nilled entry) so as > > to not use the VM hack which fetches the class without sending a message. > > Pharo prefers the regular message send. > > But next to that entry, there is #blockCopy: which was formerly used for > > blue book BlockContext. > > BlockContext was removed from Pharo... > > So that makes two available slots for optimizing most used (sent) > > messages... > > We might choose some candidates and test on some macro benchmark if ever > > that really makes a difference. > > -- Mariano http://marianopeck.wordpress.com

Sept. 4, 2013

Re: [Pharo-dev] specialSelectors

by Nicolas Cellier

Well, #class slot is not really available because the trick is hardcoded in the VM as well as == trick, so no lookup in specialSelectors (specailObjectsArray at: 24) is attempted for these 2. COG also optimize some arithmetic messages, comparisons, bit ops, and all is hardcoded in the VM, so better not playing with those indices. So I tried to just replace #blockCopy: 1 with #not 0, ran some tests but saw no significative speed up. Then I tried to run Kernel tests twice in a unmodified 3.0 image [(Smalltalk allClasses select: [:e | (e category beginsWith: 'KernelTests') and: [e inheritsFrom: TestCase]]) do: [:e | e suite run]] timeToRun. 113342 114337 Then optimized the mosttly sent message during tests : IRByteCodeGenerator>>specialSelectorsArray ^ #(#+ 1 #- 1 #< 1 #> 1 #<= 1 #>= 1 #= 1 #~= 1 #* 1 #/ 1 #\\ 1 #@ 1 #bitShift: 1 #// 1 #bitAnd: 1 #bitOr: 1 #at: 1 #at:put: 2 #size 0 #next 0 #nextPut: 1 #atEnd 0 #== 1 nil 0 #assert: 1 #value 0 #value: 1 #do: 1 #new 0 #new: 1 #x 0 #y 0) Recompiled all: IRBytecodeGenerator initializeSpecialSelectors. Smalltalk specialObjectsArray at: 24 put: IRBytecodeGenerator specialSelectorsArray. OpalCompiler recompileAll. Then tried the tests twice again: [(Smalltalk allClasses select: [:e | (e category beginsWith: 'KernelTests') and: [e inheritsFrom: TestCase]]) do: [:e | e suite run]] timeToRun. 84328 83974 So it seems like it's not just a space optimization but also a speed one, and I don't know why... It would be better if someone could repeat these results... Nicolas 2013/9/4 Camillo Bruni <camillobruni(a)gmail.com> > that would actually be interesting on how much you win by doing so, and if > you could run this dynamically (for instance reintroduce the #class > optimization if you never override it in the image)... > > > On 2013-09-03, at 19:07, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> wrote: > > I note that #class was removed from specialSelectors (nilled entry) so as > > to not use the VM hack which fetches the class without sending a message. > > Pharo prefers the regular message send. > > But next to that entry, there is #blockCopy: which was formerly used for > > blue book BlockContext. > > BlockContext was removed from Pharo... > > So that makes two available slots for optimizing most used (sent) > > messages... > > We might choose some candidates and test on some macro benchmark if ever > > that really makes a difference. > >

Sept. 4, 2013

Re: [Pharo-dev] specialSelectors

by Camillo Bruni

that would actually be interesting on how much you win by doing so, and if you could run this dynamically (for instance reintroduce the #class optimization if you never override it in the image)... On 2013-09-03, at 19:07, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > I note that #class was removed from specialSelectors (nilled entry) so as > to not use the VM hack which fetches the class without sending a message. > Pharo prefers the regular message send. > But next to that entry, there is #blockCopy: which was formerly used for > blue book BlockContext. > BlockContext was removed from Pharo... > So that makes two available slots for optimizing most used (sent) > messages... > We might choose some candidates and test on some macro benchmark if ever > that really makes a difference.

Sept. 3, 2013

Re: [Pharo-dev] Should Job use SystemAnnouncer?

by Camillo Bruni

On 2013-09-03, at 18:57, Stephan Eggermont <stephan(a)stack.nl> wrote: > Camillo wrote: >> in this case it is only the instance of Job which knows the status. >> Thread-safeness is not an issue since the progress bar is pure approximation. > > The problem is not approximation. Objects are not reentrant, getting the value > out of a model while it is reorganizing its datastructure is likely to give interesting > and difficult to reproduce results (dividing by 0, nil-pointer exceptions). > >> that does not work properly and inaccurately reports long running jobs, for instance >> when running tests. Usually tests take far less than 1 ms, in which case this scheme >> works perfectly. However from time to time you have 1 test that runs for a couple of >> seconds. If you run 5000 tests you have to run quite a few tests to get that 1% update >> margin, so very often the UI does not correctly report the current status. > > That is not a solvable problem. A progress bar depends on a value increasing from > min to max. The model is responsible for making reasonable steps. ok, different question, how do you solve this very use-case without polling? 1. run test 1 [1ms] ..... N. run test N [1ms] ------------------------------------------- Progress Bar update limit reached after a) either N update calls b) N ms => next update will happen in a) N calls b) N ms ------------------------------------------- N+1. run test N+1 [1000 ms] That means that the UI shows the wrong value (run test N) instead of the current progress value (run test N+1), which is not interesting. The model, in this case the test runner, properly informed the UI about every change, but the update limitations in the ProgressBarMorph cannot properly detect such a case. - either you update way to often => performance overhead - or you update not often enough => inaccurate progress indication when progress step times differ a lot There is simply no way you can properly solve this case without active polling. As for your doubts about thread-safeness: The model for the ProgressBar is the Job class. It is hence the only entry point for the PogressBar and thus can easily be made threadsafe. My use-case is simply that I want to see in which test-case the test runner hangs.

Sept. 3, 2013

specialSelectors

by Nicolas Cellier

I note that #class was removed from specialSelectors (nilled entry) so as to not use the VM hack which fetches the class without sending a message. Pharo prefers the regular message send. But next to that entry, there is #blockCopy: which was formerly used for blue book BlockContext. BlockContext was removed from Pharo... So that makes two available slots for optimizing most used (sent) messages... We might choose some candidates and test on some macro benchmark if ever that really makes a difference.

Sept. 3, 2013