- Pharo-users - lists.pharo.org

Re: [Pharo-users] [ANN] Territorial Re-Licensing

by Ben Coman

Hi Hernan, Thanks for your balanced response. Licensing discussion can be boring but also crucial, hence the sometimes religious views on it. Like a lot of things, from a distance it seems easy - but the devil is in the details. Consider anyway that "Territorial" may otherwise have been a single blip in your first [ANN] post, but its now had more exposure. I hope you don't mind I follow up with one more post that has been sitting almost complete in Drafts folder a few days, after researching some interesting points. cheers -ben On Thu, Sep 8, 2016 at 12:00 PM, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: > > I consider GNU AGPL v3 a fair license choice which protects somehow authors. > After some talks with friends today, I began to consider it useless for a > niche community like Smalltalk *and* solo projects. I then read all your > mails, many posts in other communities, and finally asked for advices. > Conclusion: The ideal license option for me was not yet invented. > > Now about parasite behavior and easy living for freeloaders. > > - I doubt Smalltalkers are in position for doing anything valuable against > parasites. GPL scares a niche community. All of us having MIT code published > can be stealed and we have no legal options to defend our work/authorship. > That should be addressed one day. > > - However, I would like one day to read people releasing software under > whatever license they want and not to be pointed them. That's a matter of > freedom. I feel we are far away from there. > > - I hope we can talk about interesting Territorial features, what do you > need, what could be modeled better, etc. Licensing is boring, really. > > I re-licensed Territorial to MIT for the nice Pharo people, for the nice > Smalltalkers, people who helped me here in mailing lists, or sending > supportive private messages, and for cool users with nice intentions. > > HernÃ¡n > > PS: Updated User Manual: http://bit.ly/2c4RrCJ > > >

Sept. 8, 2016

Re: [Pharo-users] Profiling

by Ben Coman

On Thu, Sep 8, 2016 at 11:37 AM, Ben Coman <btc(a)openinworld.com> wrote: > - 9989 tallies, 10003 msec. > > **Tree** > -------------------------------- > Process: other processes > -------------------------------- > 99.2% {9928ms} ProcessorScheduler class>>startUp > 99.2% {9928ms} ProcessorScheduler class>>idleProcess > **Leaves** > 99.2% {9928ms} ProcessorScheduler class>>idleProcess > > **Memory** > old +0 bytes > young -223,912 bytes > used -223,912 bytes > free +223,912 bytes > > **GCs** > full 0 totalling 0ms (0.0% uptime) > incr 2 totalling 6ms (0.0% uptime), avg 3.0ms > tenures 0 > root table 0 overflows > > On Thu, Sep 8, 2016 at 9:44 AM, Vitor Medina Cruz <vitormcruz(a)gmail.com> wrote: >> Hello, >> >> While profiling some I/O code that takes ~20 seconds to execute under my >> local image, the report says that about ~13 seconds is waste on >> OtherProcesses -> ProcessorScheduler class>>idleProcess. I could not >> understand what this idleProcess do by looking at the code. First I thought >> this could be time waiting the I/O operation to terminate, but that don't >> make much sense because I have the same code on a Digital Ocean Doplet and >> it takes ~6 seconds to execute. >> >> Can someone help me understand what does this time on idleProcess means? > > I don't have an exact answer for you, but a comparative example... > > Tools > Time Profiler... > 10 seconds wait > Full report... > ========================================== > - 9989 tallies, 10003 msec. > > **Tree** > -------------------------------- > Process: other processes > -------------------------------- > 99.2% {9928ms} ProcessorScheduler class>>startUp > 99.2% {9928ms} ProcessorScheduler class>>idleProcess > **Leaves** > 99.2% {9928ms} ProcessorScheduler class>>idleProcess > > **Memory** > old +0 bytes > young -223,912 bytes > used -223,912 bytes > free +223,912 bytes > > **GCs** > full 0 totalling 0ms (0.0% uptime) > incr 2 totalling 6ms (0.0% uptime), avg 3.0ms > tenures 0 > root table 0 overflows > ========================================== > > Now over that time, Windows 7 Task Manager showed Pharo process CPU load of 0%, > indicating the 9.9 seconds spent in idleProcess has no impact on performance. > Or put another way, for 99.2% of that 10 seconds Pharo was *not* busy. > > Applying that to your results, I would guess that for 73.3% of that 20 > seconds you were waiting on I/O. > > To find your performance issues, follow down the percentages for where > there are big jumps without splits. > That is, ignore jumps where the splits add up to the parent. > For example 14.3 + 10.8 ==> 25.1 - so no lost performance here... > 25.0% {4656ms} TweetsServiceRestConsumer>>fetchLastTweetsUpTo:fromHandler: > 14.3% {2653ms} OAuthProvider>>httpGet: > | > 10.8% {2002ms} NeoJSONObject class>>fromString: > > Your biggest loss in a linear line seems to be... > 5.6% {1041ms} NeoJSONReader>>parseValue > to > 1.5% {285ms} NeoJSONReader>>parseMap > > > I am curious about the recursive calls to > ZdcSecureSocketStream(ZdcSimpleSocketStream)>>fillReadBuffer > and multiple accumulations from DelayExperimentalSpinScheduler>>unschedule: > but that method doesn't really do a lot. I wouldn't expect the > whileTrue loop to be spinning much, but you could examine that by > > > You might try another scheduler... > World>System>Settings>System>Delay Scheduler Another experiment might try could be divide-and-conquer by examining a sample of what is returned by... 10.8% {2002ms} NeoJSONObject class>>fromString: and return a similar constant. cheers -ben

Sept. 8, 2016

Re: [Pharo-users] Profiling

by Ben Coman

Ahhh... gmail pre-emptive send strikes again.... To continue... I am curious about the recursive calls to ZdcSecureSocketStream(ZdcSimpleSocketStream)>>fillReadBuffer and multiple accumulations from DelayExperimentalSpinScheduler>>unschedule: but that method doesn't really do a lot. I wouldn't expect the whileTrue loop to be spinning much, but you could examine that by trying something like... Object subclass: #SpinCount instanceVariableNames: 'counter' classVariableNames: '' package: 'Play' SpinCount>>initialize counter := 0. SpinCount>>count counter := counter + 1. SpinCount>>printOn: aStream super printOn: aStream. aStream nextPut: $=. counter printOn: aStream. DelayMicrosecondScheduler subclass: #DelayExperimentalSpinScheduler instanceVariableNames: '' classVariableNames: 'Tally' package: 'Kernel-Processes' DelayExperimentalSpinScheduler class >> startTally Tally := WaitfreeQueue new. DelayExperimentalSpinScheduler class >> endTally |result finalTally| finalTally := Tally. Tally := nil. result := OrderedCollection new. finalTally flush: [ :item | result add: item ]. ^ result DelayExperimentalSpinScheduler >> unschedule: aDelay |spinCount| "self startTally" "self endTally inspect" spinCount := SpinCount new. Tally ifNotNil: [Tally nextPut: spinCount]. aDelay schedulerBeingWaitedOn ifTrue: [^self error: 'This Delay has already been scheduled.']. [ Tally ifNotNil: [spinCount count]. scheduledDelay == nil ifTrue: [ scheduledDelay := aDelay. timingSemaphore signal. ^self]. true. ] whileTrue. Actually, I wonder does the "timingSemaphore signal" invoking the priority 80 DelaySchedulingProcess to wake up and run above the priority of the profiler? So all of that activity gets attributed to #unschedule: ??? cheers -ben

Sept. 8, 2016

[ANN] Territorial Re-Licensing

by HernÃ¡n Morales Durand

I consider GNU AGPL v3 a fair license choice which protects somehow authors. After some talks with friends today, I began to consider it useless for a niche community like Smalltalk *and* solo projects. I then read all your mails, many posts in other communities, and finally asked for advices. Conclusion: The ideal license option for me was not yet invented. Now about parasite behavior and easy living for freeloaders. - I doubt Smalltalkers are in position for doing anything valuable against parasites. GPL scares a niche community. All of us having MIT code published can be stealed and we have no legal options to defend our work/authorship. That should be addressed one day. - However, I would like one day to read people releasing software under whatever license they want and not to be pointed them. That's a matter of freedom. I feel we are far away from there. - I hope we can talk about interesting Territorial features, what do you need, what could be modeled better, etc. Licensing is boring, really. I re-licensed Territorial to MIT for the nice Pharo people, for the nice Smalltalkers, people who helped me here in mailing lists, or sending supportive private messages, and for cool users with nice intentions. HernÃ¡n PS: Updated User Manual: http://bit.ly/2c4RrCJ

Sept. 8, 2016

Re: [Pharo-users] Profiling

by Ben Coman

- 9989 tallies, 10003 msec. **Tree** -------------------------------- Process: other processes -------------------------------- 99.2% {9928ms} ProcessorScheduler class>>startUp 99.2% {9928ms} ProcessorScheduler class>>idleProcess **Leaves** 99.2% {9928ms} ProcessorScheduler class>>idleProcess **Memory** old +0 bytes young -223,912 bytes used -223,912 bytes free +223,912 bytes **GCs** full 0 totalling 0ms (0.0% uptime) incr 2 totalling 6ms (0.0% uptime), avg 3.0ms tenures 0 root table 0 overflows On Thu, Sep 8, 2016 at 9:44 AM, Vitor Medina Cruz <vitormcruz(a)gmail.com> wrote: > Hello, > > While profiling some I/O code that takes ~20 seconds to execute under my > local image, the report says that about ~13 seconds is waste on > OtherProcesses -> ProcessorScheduler class>>idleProcess. I could not > understand what this idleProcess do by looking at the code. First I thought > this could be time waiting the I/O operation to terminate, but that don't > make much sense because I have the same code on a Digital Ocean Doplet and > it takes ~6 seconds to execute. > > Can someone help me understand what does this time on idleProcess means? I don't have an exact answer for you, but a comparative example... Tools > Time Profiler... 10 seconds wait Full report... ========================================== - 9989 tallies, 10003 msec. **Tree** -------------------------------- Process: other processes -------------------------------- 99.2% {9928ms} ProcessorScheduler class>>startUp 99.2% {9928ms} ProcessorScheduler class>>idleProcess **Leaves** 99.2% {9928ms} ProcessorScheduler class>>idleProcess **Memory** old +0 bytes young -223,912 bytes used -223,912 bytes free +223,912 bytes **GCs** full 0 totalling 0ms (0.0% uptime) incr 2 totalling 6ms (0.0% uptime), avg 3.0ms tenures 0 root table 0 overflows ========================================== Now over that time, Windows 7 Task Manager showed Pharo process CPU load of 0%, indicating the 9.9 seconds spent in idleProcess has no impact on performance. Or put another way, for 99.2% of that 10 seconds Pharo was *not* busy. Applying that to your results, I would guess that for 73.3% of that 20 seconds you were waiting on I/O. To find your performance issues, follow down the percentages for where there are big jumps without splits. That is, ignore jumps where the splits add up to the parent. For example 14.3 + 10.8 ==> 25.1 - so no lost performance here... 25.0% {4656ms} TweetsServiceRestConsumer>>fetchLastTweetsUpTo:fromHandler: 14.3% {2653ms} OAuthProvider>>httpGet: | 10.8% {2002ms} NeoJSONObject class>>fromString: Your biggest loss in a linear line seems to be... 5.6% {1041ms} NeoJSONReader>>parseValue to 1.5% {285ms} NeoJSONReader>>parseMap I am curious about the recursive calls to ZdcSecureSocketStream(ZdcSimpleSocketStream)>>fillReadBuffer and multiple accumulations from DelayExperimentalSpinScheduler>>unschedule: but that method doesn't really do a lot. I wouldn't expect the whileTrue loop to be spinning much, but you could examine that by You might try another scheduler... World>System>Settings>System>Delay Scheduler

Sept. 8, 2016

Profiling

by Vitor Medina Cruz

Hello, While profiling some I/O code that takes ~20 seconds to execute under my local image, the report says that about ~13 seconds is waste on OtherProcesses -> ProcessorScheduler class>>idleProcess. I could not understand what this idleProcess do by looking at the code. First I thought this could be time waiting the I/O operation to terminate, but that don't make much sense because I have the same code on a Digital Ocean Doplet and it takes ~6 seconds to execute. Can someone help me understand what does this time on idleProcess means? The full report is: - 18407 tallies, 18605 msec. **Tree** -------------------------------- Process: (40s) Morphic UI Process: nil -------------------------------- 25.1% {4663ms} UndefinedObject>>DoIt 25.1% {4663ms} TweetsServiceRestConsumer(TweetsService)>>hashesTop:usingLastTweetsUpTo:fromHandler: 25.0% {4656ms} TweetsServiceRestConsumer>>fetchLastTweetsUpTo:fromHandler: 14.3% {2653ms} OAuthProvider>>httpGet: |14.3% {2653ms} ZnOAuth1Service>>httpGet:using: | 14.3% {2653ms} ZnOAuth1Service>>executeRequest:token: | 14.3% {2653ms} ZnOAuth1Service>>executeRequest:token:followRedirects: | 14.2% {2646ms} ZnClient>>execute | 14.2% {2646ms} ZnClient>>withProgressDo: | 14.2% {2646ms} ZnSignalProgress class(DynamicVariable class)>>value:during: | 14.2% {2646ms} ZnSignalProgress(DynamicVariable)>>value:during: | 14.2% {2646ms} BlockClosure>>ensure: | 14.2% {2646ms} ZnSignalProgress(DynamicVariable)>>value:during: | 14.2% {2646ms} ZnClient>>withProgressDo: | 14.2% {2646ms} ZnClient>>execute | 14.2% {2646ms} ZnClient>>executeWithTimeout | 14.2% {2646ms} ZnClient>>withTimeoutDo: | 14.2% {2646ms} ZnConnectionTimeout class(DynamicVariable class)>>value:during: | 14.2% {2646ms} ZnConnectionTimeout(DynamicVariable)>>value:during: | 14.2% {2646ms} BlockClosure>>ensure: | 14.2% {2646ms} ZnConnectionTimeout(DynamicVariable)>>value:during: | 14.2% {2646ms} ZnClient>>withTimeoutDo: | 14.2% {2646ms} ZnClient>>executeWithTimeout | 14.2% {2646ms} BlockClosure>>on:do: | 14.2% {2646ms} ZnClient>>executeWithTimeout | 14.2% {2646ms} ZnClient>>executeWithRetriesRemaining: | 14.2% {2644ms} BlockClosure>>on:do: | 14.2% {2644ms} ZnClient>>executeWithRetriesRemaining: | 14.2% {2644ms} ZnClient>>executeWithRedirectsRemaining: | 14.2% {2641ms} ZnClient>>getConnectionAndExecute | 13.8% {2569ms} BlockClosure>>ensure: | 13.8% {2569ms} ZnClient>>getConnectionAndExecute | 13.8% {2569ms} ZnClient>>executeRequestResponse | 13.8% {2569ms} ZnClient>>readResponse | 13.8% {2569ms} ZnResponse class(ZnMessage class)>>readFrom: | 13.8% {2569ms} ZnResponse(ZnMessage)>>readFrom: | 13.8% {2559ms} ZnResponse>>readEntityFrom: | 13.8% {2559ms} ZnResponse(ZnMessage)>>readEntityFrom: | 13.8% {2559ms} ZnEntityReader>>readEntity | 13.8% {2559ms} ZnEntityReader>>readEntityFromStream | 13.7% {2555ms} ZnEntityReader>>readFrom:usingType:andLength: | 13.7% {2555ms} ZnEntity class>>readFrom:usingType:andLength: | 13.7% {2555ms} ZnStringEntity>>readFrom: | 13.7% {2550ms} BlockClosure>>on:do: | 13.7% {2550ms} ZnStringEntity>>readFrom: | 13.7% {2550ms} ZnUTF8Encoder>>readInto:startingAt:count:fromStream: | 13.7% {2550ms} ZnUTF8Encoder>>optimizedReadInto:startingAt:count:fromStream: | 13.7% {2550ms} ZnLimitedReadStream>>readInto:startingAt:count: | 13.7% {2547ms} ZdcSecureSocketStream(ZdcOptimizedSocketStream)>>readInto:startingAt:count: | 13.7% {2547ms} ZdcSecureSocketStream(ZdcSimpleSocketStream)>>fillReadBuffer | 9.0% {1669ms} ZdcSecureSocketStream(ZdcSimpleSocketStream)>>fillReadBuffer | |5.8% {1076ms} ZdcSecureSocketStream(ZdcSimpleSocketStream)>>fillReadBuffer | | |3.6% {671ms} ZdcSecureSocketStream(ZdcSimpleSocketStream)>>fillReadBuffer | | | |1.8% {337ms} ZdcSecureSocketStream(ZdcSimpleSocketStream)>>fillReadBuffer | | | | |1.2% {225ms} BlockClosure>>on:do: | | | | | 1.2% {225ms} ZdcSecureSocketStream(ZdcSimpleSocketStream)>>fillReadBuffer | | | | | 1.2% {225ms} ZdcSecureSocketStream(ZdcAbstractSocketStream)>>socketWaitForData | | | | | 1.2% {225ms} Socket>>waitForDataFor: | | | | | 1.2% {225ms} Socket>>waitForDataFor:ifClosed:ifTimedOut: | | | | | 1.2% {225ms} Semaphore>>waitTimeoutMSecs: | | | | | 1.2% {225ms} DelayWaitTimeout>>wait | | | | | 1.2% {225ms} BlockClosure>>ensure: | | | | | 1.2% {225ms} DelayWaitTimeout>>wait | | | | | 1.1% {196ms} DelayWaitTimeout(Delay)>>unschedule | | | | | 1.1% {196ms} DelayExperimentalSpinScheduler>>unschedule: | | | |1.8% {335ms} BlockClosure>>on:do: | | | | 1.8% {335ms} ZdcSecureSocketStream(ZdcSimpleSocketStream)>>fillReadBuffer | | | | 1.8% {335ms} ZdcSecureSocketStream(ZdcAbstractSocketStream)>>socketWaitForData | | | | 1.8% {335ms} Socket>>waitForDataFor: | | | | 1.8% {335ms} Socket>>waitForDataFor:ifClosed:ifTimedOut: | | | | 1.8% {335ms} Semaphore>>waitTimeoutMSecs: | | | | 1.8% {335ms} DelayWaitTimeout>>wait | | | | 1.8% {335ms} BlockClosure>>ensure: | | | | 1.8% {335ms} DelayWaitTimeout>>wait | | | | 1.5% {273ms} DelayWaitTimeout(Delay)>>unschedule | | | | 1.5% {273ms} DelayExperimentalSpinScheduler>>unschedule: | | |2.2% {405ms} BlockClosure>>on:do: | | | 2.2% {405ms} ZdcSecureSocketStream(ZdcSimpleSocketStream)>>fillReadBuffer | | | 2.2% {405ms} ZdcSecureSocketStream(ZdcAbstractSocketStream)>>socketWaitForData | | | 2.2% {405ms} Socket>>waitForDataFor: | | | 2.2% {405ms} Socket>>waitForDataFor:ifClosed:ifTimedOut: | | | 2.2% {405ms} Semaphore>>waitTimeoutMSecs: | | | 2.2% {405ms} DelayWaitTimeout>>wait | | | 2.2% {405ms} BlockClosure>>ensure: | | | 2.2% {405ms} DelayWaitTimeout>>wait | | | 1.7% {314ms} DelayWaitTimeout(Delay)>>unschedule | | | 1.7% {314ms} DelayExperimentalSpinScheduler>>unschedule: | |3.2% {592ms} BlockClosure>>on:do: | | 3.2% {592ms} ZdcSecureSocketStream(ZdcSimpleSocketStream)>>fillReadBuffer | | 3.2% {592ms} ZdcSecureSocketStream(ZdcAbstractSocketStream)>>socketWaitForData | | 3.2% {592ms} Socket>>waitForDataFor: | | 3.2% {592ms} Socket>>waitForDataFor:ifClosed:ifTimedOut: | | 3.2% {592ms} Semaphore>>waitTimeoutMSecs: | | 3.2% {592ms} DelayWaitTimeout>>wait | | 3.2% {592ms} BlockClosure>>ensure: | | 3.2% {592ms} DelayWaitTimeout>>wait | | 2.3% {429ms} DelayWaitTimeout(Delay)>>unschedule | | 2.3% {429ms} DelayExperimentalSpinScheduler>>unschedule: | 4.7% {876ms} BlockClosure>>on:do: | 4.7% {876ms} ZdcSecureSocketStream(ZdcSimpleSocketStream)>>fillReadBuffer | 4.7% {876ms} ZdcSecureSocketStream(ZdcAbstractSocketStream)>>socketWaitForData | 4.7% {876ms} Socket>>waitForDataFor: | 4.7% {876ms} Socket>>waitForDataFor:ifClosed:ifTimedOut: | 4.7% {876ms} Semaphore>>waitTimeoutMSecs: | 4.7% {876ms} DelayWaitTimeout>>wait | 4.7% {876ms} BlockClosure>>ensure: | 4.7% {876ms} DelayWaitTimeout>>wait | 2.9% {532ms} DelayWaitTimeout(Delay)>>unschedule | |2.9% {532ms} DelayExperimentalSpinScheduler>>unschedule: | 1.4% {268ms} primitives 10.8% {2002ms} NeoJSONObject class>>fromString: 10.8% {2002ms} NeoJSONReader>>next 10.8% {2002ms} NeoJSONReader>>parseValue 10.8% {2002ms} NeoJSONReader>>parseList 10.8% {2002ms} Array class(SequenceableCollection class)>>streamContents: 10.8% {2002ms} Array class(SequenceableCollection class)>>new:streamContents: 10.8% {2002ms} NeoJSONReader>>parseList 10.8% {2002ms} NeoJSONReader>>parseListElementsDo: 10.8% {2002ms} NeoJSONReader>>parseListDo: 10.8% {2002ms} NeoJSONReader>>parseListElementsDo: 10.8% {2002ms} NeoJSONReader>>parseValue 10.8% {2002ms} NeoJSONReader>>parseMap 10.8% {2002ms} NeoJSONReader>>parseMapKeysAndValuesDo: 10.8% {2002ms} NeoJSONReader>>parseMapKeysDo: 10.8% {2002ms} NeoJSONReader>>parseMapDo: 10.7% {1994ms} NeoJSONReader>>parseMapKeysDo: 9.6% {1785ms} NeoJSONReader>>parseMapKeysAndValuesDo: |9.2% {1717ms} NeoJSONReader>>parseValue | 8.6% {1600ms} NeoJSONReader>>parseMap | 8.6% {1600ms} NeoJSONReader>>parseMapKeysAndValuesDo: | 8.6% {1600ms} NeoJSONReader>>parseMapKeysDo: | 8.6% {1600ms} NeoJSONReader>>parseMapDo: | 8.5% {1577ms} NeoJSONReader>>parseMapKeysDo: | 6.4% {1187ms} NeoJSONReader>>parseMapKeysAndValuesDo: | |5.6% {1041ms} NeoJSONReader>>parseValue | | 3.8% {708ms} NeoJSONReader>>parseList | | 3.8% {706ms} Array class(SequenceableCollection class)>>streamContents: | | 3.8% {706ms} Array class(SequenceableCollection class)>>new:streamContents: | | 3.7% {693ms} NeoJSONReader>>parseList | | 3.7% {693ms} NeoJSONReader>>parseListElementsDo: | | 3.7% {693ms} NeoJSONReader>>parseListDo: | | 3.7% {689ms} NeoJSONReader>>parseListElementsDo: | | 3.7% {689ms} NeoJSONReader>>parseValue | | 3.7% {687ms} NeoJSONReader>>parseMap | | 3.7% {687ms} NeoJSONReader>>parseMapKeysAndValuesDo: | | 3.7% {687ms} NeoJSONReader>>parseMapKeysDo: | | 3.7% {687ms} NeoJSONReader>>parseMapDo: | | 3.6% {672ms} NeoJSONReader>>parseMapKeysDo: | | 3.0% {550ms} NeoJSONReader>>parseMapKeysAndValuesDo: | | 2.6% {486ms} NeoJSONReader>>parseValue | | 1.5% {285ms} NeoJSONReader>>parseMap | | 1.5% {285ms} NeoJSONReader>>parseMapKeysAndValuesDo: | | 1.5% {285ms} NeoJSONReader>>parseMapKeysDo: | | 1.5% {285ms} NeoJSONReader>>parseMapDo: | | 1.5% {285ms} NeoJSONReader>>parseMapKeysDo: | | 1.4% {252ms} NeoJSONReader>>parseMapKeysAndValuesDo: | | 1.3% {236ms} NeoJSONReader>>parseValue | | 1.0% {193ms} NeoJSONReader>>parseMap | | 1.0% {193ms} NeoJSONReader>>parseMapKeysAndValuesDo: | | 1.0% {193ms} NeoJSONReader>>parseMapKeysDo: | | 1.0% {188ms} NeoJSONReader>>parseMapDo: | 1.9% {347ms} NeoJSONReader>>parsePropertyName | 1.1% {196ms} NeoJSONReader>>parseValue | 1.0% {189ms} NeoJSONReader>>parseString 1.0% {189ms} NeoJSONReader>>parsePropertyName -------------------------------- Process: other processes -------------------------------- 73.2% {13628ms} ProcessorScheduler class>>startUp |73.2% {13628ms} ProcessorScheduler class>>idleProcess 1.4% {259ms} WeakArray class>>restartFinalizationProcess 1.4% {259ms} WeakArray class>>finalizationProcess 1.4% {257ms} primitives **Leaves** 73.3% {13631ms} ProcessorScheduler class>>idleProcess 10.0% {1861ms} DelayExperimentalSpinScheduler>>unschedule: 3.1% {581ms} DelayWaitTimeout>>wait 1.4% {257ms} WeakArray class>>finalizationProcess 1.0% {191ms} WeakSet>>scanFor: **Memory** old +16,777,216 bytes young -17,303,480 bytes used -526,264 bytes free +17,303,480 bytes **GCs** full 1 totalling 247ms (1.0% uptime), avg 247.0ms incr 127 totalling 199ms (1.0% uptime), avg 2.0ms tenures 480,033 (avg 0 GCs/tenure) root table 0 overflows Thanks in advance, Vitor

Sept. 8, 2016

Performance vs Ruby performance

by Vitor Medina Cruz

Hello, How is Pharo compared with Ruby in terms of performance? Has someone done some comparison benchmark? If yes, that was done with other platforms? Regards, VItor

Sept. 7, 2016

Re: [Pharo-users] SpecBooklet: Strange behavior of ProtocolBrowser

by Johan Fabry

Excellent, you found a bug in my code! What happens is that when one item is selected in a list, in the other list the currently selected item is de-selected. This causes *both* blocks (whenAPIChanged: and whenEventChanged:) to be executed, and depending on what order they are executed the behavior is different. (A classical concurrent programming problem.) This order apparently changes depending on how many windows you have open, et cetera, I guess because of how the announcement system is implemented. So, yes the easiest solution is to remove both ifNil: [â¦] lines. The UI will not work as cleanly, but it is a quick fix. Alternatively, and a bit more complicated, is to check if the selection in the other list is also empty before setting the text to the empty string. For the sake of the example, I will simply remove both ifNil: [â¦] lines from the documentation. Thanks for reporting this, and if you have further issues do not hesitate to tell us! -- Does this mail seem too brief? Sorry for that, I donât mean to be rude! Please see http://emailcharter.org . Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile > On Sep 7, 2016, at 19:51, Matteo <matteob8(a)yahoo.it> wrote: > > Hello Johan, > I've coded all the examples manually, changing the names to avoid > any conflict with the ProtocolBrowser "bundled" in the Pharo 5 image > (i.e. instead of "ProtocolBrowser" I've named my class as "ProtcolFlipper"). > But the result is the same. > > Things improve if all the "ifNil: [ text text: '' ]" get removed from > the ProtcolFlipper>>initializePresenter method. > Obviously the text pane is no more "cleaned" when deselecting an "api" > or "api-event" row. > > I've tried to substitute the "ifNil: [ text text: '' ]" with "ifNil: [ > text text: 'api' ] and ifNil: [ text text: 'api-events' ] , respectively > on the "api" and "event" instances, in the ProtocolBrowser >> > initializePresenter method. > In this way I found that "ifNil:" message is sent improperly, i.e. when > a "api-event" row is selected then the message "ifNil:" of the "api" > instance is triggered, and vice-versa. > In some way this is correct: when a "api-event" row is selected then > none of the "api" rows are selected... > > However I'm puzzled by the fact that the behavior seems random: creating > 3 instances I can get 3 different behaviors. > > have you never experienced this? > > Maybe I'll check again my code... > > thanks, > Matteo

Sept. 7, 2016

Re: [Pharo-users] SpecBooklet: Strange behavior of ProtocolBrowser

by Matteo

Hello Johan, I've coded all the examples manually, changing the names to avoid any conflict with the ProtocolBrowser "bundled" in the Pharo 5 image (i.e. instead of "ProtocolBrowser" I've named my class as "ProtcolFlipper"). But the result is the same. Things improve if all the "ifNil: [ text text: '' ]" get removed from the ProtcolFlipper>>initializePresenter method. Obviously the text pane is no more "cleaned" when deselecting an "api" or "api-event" row. I've tried to substitute the "ifNil: [ text text: '' ]" with "ifNil: [ text text: 'api' ] and ifNil: [ text text: 'api-events' ] , respectively on the "api" and "event" instances, in the ProtocolBrowser >> initializePresenter method. In this way I found that "ifNil:" message is sent improperly, i.e. when a "api-event" row is selected then the message "ifNil:" of the "api" instance is triggered, and vice-versa. In some way this is correct: when a "api-event" row is selected then none of the "api" rows are selected... However I'm puzzled by the fact that the behavior seems random: creating 3 instances I can get 3 different behaviors. have you never experienced this? Maybe I'll check again my code... thanks, Matteo On 08/09/16 00:09, Johan Fabry wrote: > Hello Matteo, > > are you using the ProtocolBrowser class that comes default with Pharo 5? > (In the Spec-Examples package). This is different from what is in the > booklet, the code in Pharo 5 is not up to date. For now, you should > define a new protocol browser class (MyProtocolBrowser for example) and > the other classes that are in that section. Sorry for that... > > -- > Does this mail seem too brief? Sorry for that, I donât mean to be rude! > Please see http://emailcharter.org . > > Johan Fabry - http://pleiad.cl/~jfabry <http://pleiad.cl/%7Ejfabry> > PLEIAD and RyCh labs - Computer Science Department (DCC) - > University of Chile > >> On Sep 7, 2016, at 18:57, Matteo via Pharo-users >> <pharo-users(a)lists.pharo.org <mailto:pharo-users@lists.pharo.org>> wrote: >> >> >> *From: *Matteo <matteob8(a)yahoo.it <mailto:matteob8@yahoo.it>> >> *Subject: **SpecBooklet: Strange behavior of ProtocolBrowser* >> *Date: *September 7, 2016 at 18:56:08 GMT-3 >> *To: *pharo-users(a)lists.pharo.org <mailto:pharo-users@lists.pharo.org> >> >> >> Hi, >> I'm playing with the ProtocolBrowser class, as coded in the >> "SpecBooklet.pdf" document (release of the 3rd August 2016). >> I'm using Pharo 5. >> >> I'm experiencing a strange behavior of the ProtocolBrowser instance: >> -if I open a ProtocolBrowser instance, and I click on a "api" item, I >> do not get any code in the text pane. >> -If I open another ProtocolBrowser instance then I do not see any code, >> even in the "api" protocol than the "api-events" one. >> -If I open a further instance then the widget works correctly, showing >> the "api" or "api-events" code in the text pane. >> >> Please note that the ProtocolBrowser is instantiated as follow: >> (ProtocolBrowser new) openWithSpec >> >> Could my Pharo image be faulty? >> Is there some problem with ProtocolBrowser>>initializePresenter? >> >> Thanks, >> Matteo Bellotto >> >> >> >> >> >

Sept. 7, 2016

Re: [Pharo-users] Lint Rule for Class-Side Method

by Sean P. DeNigris

Uko2 wrote > Ok, can you also, please, clarify which version of Pharo are you using? Sure, sorry for the vague report. Pharo 5 ----- Cheers, Sean -- View this message in context: http://forum.world.st/Lint-Rule-for-Class-Side-Method-tp4914121p4914682.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Sept. 7, 2016