- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] NonInteractiveUIManager vs. Epicea

by Esteban Lorenzano

I spotted the same problem todayâ¦ yes, fogbugz is better place :) Esteban > On 22 Jun 2016, at 00:23, Holger Freyther <holger(a)freyther.de> wrote: > > Hi, > > would fogbugz be the better place for reports like this? It looks like the introduction of Epicea has broken my use of headless images? > > Should >>#initialize use "Smalltalk ui theme" instead of "UIManager default theme"? > > > NonInteractiveUIManager>>theme > NonInteractiveUIManager(Object)>>doesNotUnderstand: #theme > EpDisplayMorphVisitor>>initialize > EpDisplayMorphVisitor class(Behavior)>>new > EpEntryItem>>displayWidget > [ :item | item displayWidget ] in EpLogBrowser>>initializeItemsModel in Block: [ :item | item displayWidget ] > BlockClosure>>cull: > BlockClosure>>cull:cull: > TreeModel>>wrapItem: > [ :node | self wrapItem: node content ] in TreeModel>>initialize in Block: [ :node | self wrapItem: node content ] > [ :node :cont | self rowMorphGetSelector value: node ] in SpecTreeColumn(MorphTreeColumn)>>rowMorphGetterBlock in Block: [ :node :cont | self rowMorphGetSelector value: no...etc... > SpecTreeColumn>>rowMorphFor: > [ :col | > | v | > v := col rowMorphFor: complexContents. > controls add: v. > col -> v ] in MorphTreeNodeMorph>>buildRowMorph in Block: [ :col | ... > OrderedCollection>>collect: > MorphTreeNodeMorph>>buildRowMorph > MorphTreeNodeMorph>>initRow > MorphTreeNodeMorph>>initWithContents:prior:forList:indentLevel: > [ :item :idx | > priorMorph := self indentingItemClass new > initWithContents: item > prior: priorMorph > forList: self > indentLevel: newIndent. > firstAddition ifNil: [ firstAddition := priorMorph ]. > morphList add: priorMorph. > "Was this row expanded ? if true -> expand it > again " > ((item hasEquivalentIn: expandedItems) or: [ priorMorph isExpanded ]) > ifTrue: [ priorMorph isExpanded: true. > priorMorph > addChildrenForList: self > addingTo: morphList > withExpandedItems: expandedItems ] ] in MorphTreeMorph>>addMorphsTo:from:withExpandedItems:atLevel: in Block: [ :item :idx | ... > OrderedCollection(SequenceableCollection)>>withIndexDo: > OrderedCollection(SequenceableCollection)>>doWithIndex: > MorphTreeMorph>>addMorphsTo:from:withExpandedItems:atLevel: > MorphTreeMorph>>addSubmorphsFromNodeList:previouslyExpanded: > MorphTreeMorph>>addSubmorphsFromNodeList > MorphTreeMorph>>buildContents > MorphicTreeAdapter>>buildWidget > MorphicTreeAdapter(AbstractAdapter)>>adapt: > SpecInterpreter>>actionToPerformWithSelector:arguments: > SpecInterpreter>>performNextSelectorAndIncrementIndex > SpecInterpreter>>interpretASpec:selector: > SpecInterpreter>>interpretASpec:model:selector: > SpecInterpreter class>>private_interpretASpec:model:selector:

June 21, 2016

NonInteractiveUIManager vs. Epicea

by Holger Freyther

Hi, would fogbugz be the better place for reports like this? It looks like the introduction of Epicea has broken my use of headless images? Should >>#initialize use "Smalltalk ui theme" instead of "UIManager default theme"? NonInteractiveUIManager>>theme NonInteractiveUIManager(Object)>>doesNotUnderstand: #theme EpDisplayMorphVisitor>>initialize EpDisplayMorphVisitor class(Behavior)>>new EpEntryItem>>displayWidget [ :item | item displayWidget ] in EpLogBrowser>>initializeItemsModel in Block: [ :item | item displayWidget ] BlockClosure>>cull: BlockClosure>>cull:cull: TreeModel>>wrapItem: [ :node | self wrapItem: node content ] in TreeModel>>initialize in Block: [ :node | self wrapItem: node content ] [ :node :cont | self rowMorphGetSelector value: node ] in SpecTreeColumn(MorphTreeColumn)>>rowMorphGetterBlock in Block: [ :node :cont | self rowMorphGetSelector value: no...etc... SpecTreeColumn>>rowMorphFor: [ :col | | v | v := col rowMorphFor: complexContents. controls add: v. col -> v ] in MorphTreeNodeMorph>>buildRowMorph in Block: [ :col | ... OrderedCollection>>collect: MorphTreeNodeMorph>>buildRowMorph MorphTreeNodeMorph>>initRow MorphTreeNodeMorph>>initWithContents:prior:forList:indentLevel: [ :item :idx | priorMorph := self indentingItemClass new initWithContents: item prior: priorMorph forList: self indentLevel: newIndent. firstAddition ifNil: [ firstAddition := priorMorph ]. morphList add: priorMorph. "Was this row expanded ? if true -> expand it again " ((item hasEquivalentIn: expandedItems) or: [ priorMorph isExpanded ]) ifTrue: [ priorMorph isExpanded: true. priorMorph addChildrenForList: self addingTo: morphList withExpandedItems: expandedItems ] ] in MorphTreeMorph>>addMorphsTo:from:withExpandedItems:atLevel: in Block: [ :item :idx | ... OrderedCollection(SequenceableCollection)>>withIndexDo: OrderedCollection(SequenceableCollection)>>doWithIndex: MorphTreeMorph>>addMorphsTo:from:withExpandedItems:atLevel: MorphTreeMorph>>addSubmorphsFromNodeList:previouslyExpanded: MorphTreeMorph>>addSubmorphsFromNodeList MorphTreeMorph>>buildContents MorphicTreeAdapter>>buildWidget MorphicTreeAdapter(AbstractAdapter)>>adapt: SpecInterpreter>>actionToPerformWithSelector:arguments: SpecInterpreter>>performNextSelectorAndIncrementIndex SpecInterpreter>>interpretASpec:selector: SpecInterpreter>>interpretASpec:model:selector: SpecInterpreter class>>private_interpretASpec:model:selector:

June 21, 2016

Ubuntu Installation Change

by J.F. Rick

You might also want to include the following in the i386 section of the Ubuntu installation: apt-get install libcairo2:i386 While Athens isn't readily used, it is in the image. Cheers, Jeff

June 21, 2016

Re: [Pharo-dev] Pharo vs. Squeak performance

by Guillermo Polito

Also, to remove noise from finalization process, you can try to execute your snippet in a higher process priority. 80 meaning it cannot be interrupted. On Tue, Jun 21, 2016 at 11:38 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > On 21 Jun 2016, at 23:32, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi John, > > On Tue, Jun 21, 2016 at 1:30 PM, John Brant <brant(a)refactoryworkers.com> > wrote: > >> On 06/21/2016 08:13 AM, Sven Van Caekenberghe wrote: >> >>> >>> On 21 Jun 2016, at 11:58, Ben Coman <btc(a)openinworld.com> wrote: >>>> >>>> On Tue, Jun 21, 2016 at 3:29 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> >>>> wrote: >>>> >>>>> Hello John. >>>>> >>>>> I'm just guessing here. Lacking information. It could be: >>>>> >>>>> Guess 3) the UI is known to be much slower in Pharo. Can you try >>>>> headless or >>>>> after ticking "Server mode" In the Pharo settings in System. >>>>> >>>> >>>> Or try something like... >>>> [ Transcript cr; show: (Time millisecondsToRun: [1 to: 100000000 do: >>>> [:i | Object new]] ) ] forkAt: 75. >>>> >>> >>> BTW, this is essentially a garbage collection benchmark: you create >>> 100,000,000 empty objects. It stresses the GC, especially the ephemeral >>> phase of it. Since the GC is part of the VM, you are testing the VM more >>> than any image code. >>> >> >> That's what I thought too, and that's why I was surprised that there was >> much difference between Squeak and Pharo for this. Furthermore, when I ran >> the Pharo image using a Squeak vm, I still saw the difference so I thought >> it must be some image related thing instead of a vm. > > > FYI, the differences between the VMs are minimal. The base VMs differ > only in the FilePlugin API, such that the Pharo API supports accessing > POSIX file permissions whereas the Squeak one does not. There are > differences in the set of external plugins, Pharo providing Freetype and > Cairo support, whereas buy default the Squeak VM does not. But in the > execution machinery they are identical. So it's a relief to me that you've > pin-pointed a UI issue. That makes sense to me, whereas, say, differences > in GC performance due to finalisation load would confuse me as I see no > likely cause of the size of effect you're seeing. > > > yes, I was going to point thereâ¦ also maybe some compilations flag could > change, but I do not think so. > Anywayâ¦ can you test headless? > > pharo Pharo.image eval âetcâ > > and if not, also testing with old Workspace (instead Playground and then > Rubric) would be nice: > > Workspace open. > > (and of course, all other windows closed) > > cheers, > Esteban > > > HTH > > John Brant >> > > _,,,^..^,,,_ > best, Eliot > > >

June 21, 2016

Re: [Pharo-dev] Pharo vs. Squeak performance

by Esteban Lorenzano

> On 21 Jun 2016, at 23:32, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi John, > > On Tue, Jun 21, 2016 at 1:30 PM, John Brant <brant(a)refactoryworkers.com <mailto:brant@refactoryworkers.com>> wrote: > On 06/21/2016 08:13 AM, Sven Van Caekenberghe wrote: > > On 21 Jun 2016, at 11:58, Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com>> wrote: > > On Tue, Jun 21, 2016 at 3:29 PM, ClÃ©ment Bera <bera.clement(a)gmail.com <mailto:bera.clement@gmail.com>> wrote: > Hello John. > > I'm just guessing here. Lacking information. It could be: > > Guess 3) the UI is known to be much slower in Pharo. Can you try headless or > after ticking "Server mode" In the Pharo settings in System. > > Or try something like... > [ Transcript cr; show: (Time millisecondsToRun: [1 to: 100000000 do: > [:i | Object new]] ) ] forkAt: 75. > > BTW, this is essentially a garbage collection benchmark: you create 100,000,000 empty objects. It stresses the GC, especially the ephemeral phase of it. Since the GC is part of the VM, you are testing the VM more than any image code. > > That's what I thought too, and that's why I was surprised that there was much difference between Squeak and Pharo for this. Furthermore, when I ran the Pharo image using a Squeak vm, I still saw the difference so I thought it must be some image related thing instead of a vm. > > FYI, the differences between the VMs are minimal. The base VMs differ only in the FilePlugin API, such that the Pharo API supports accessing POSIX file permissions whereas the Squeak one does not. There are differences in the set of external plugins, Pharo providing Freetype and Cairo support, whereas buy default the Squeak VM does not. But in the execution machinery they are identical. So it's a relief to me that you've pin-pointed a UI issue. That makes sense to me, whereas, say, differences in GC performance due to finalisation load would confuse me as I see no likely cause of the size of effect you're seeing. yes, I was going to point thereâ¦ also maybe some compilations flag could change, but I do not think so. Anywayâ¦ can you test headless? pharo Pharo.image eval âetcâ and if not, also testing with old Workspace (instead Playground and then Rubric) would be nice: Workspace open. (and of course, all other windows closed) cheers, Esteban > > HTH > > John Brant > > _,,,^..^,,,_ > best, Eliot

June 21, 2016

Re: [Pharo-dev] Pharo vs. Squeak performance

by Eliot Miranda

Hi John, On Tue, Jun 21, 2016 at 1:30 PM, John Brant <brant(a)refactoryworkers.com> wrote: > On 06/21/2016 08:13 AM, Sven Van Caekenberghe wrote: > >> >> On 21 Jun 2016, at 11:58, Ben Coman <btc(a)openinworld.com> wrote: >>> >>> On Tue, Jun 21, 2016 at 3:29 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> >>> wrote: >>> >>>> Hello John. >>>> >>>> I'm just guessing here. Lacking information. It could be: >>>> >>>> Guess 3) the UI is known to be much slower in Pharo. Can you try >>>> headless or >>>> after ticking "Server mode" In the Pharo settings in System. >>>> >>> >>> Or try something like... >>> [ Transcript cr; show: (Time millisecondsToRun: [1 to: 100000000 do: >>> [:i | Object new]] ) ] forkAt: 75. >>> >> >> BTW, this is essentially a garbage collection benchmark: you create >> 100,000,000 empty objects. It stresses the GC, especially the ephemeral >> phase of it. Since the GC is part of the VM, you are testing the VM more >> than any image code. >> > > That's what I thought too, and that's why I was surprised that there was > much difference between Squeak and Pharo for this. Furthermore, when I ran > the Pharo image using a Squeak vm, I still saw the difference so I thought > it must be some image related thing instead of a vm. FYI, the differences between the VMs are minimal. The base VMs differ only in the FilePlugin API, such that the Pharo API supports accessing POSIX file permissions whereas the Squeak one does not. There are differences in the set of external plugins, Pharo providing Freetype and Cairo support, whereas buy default the Squeak VM does not. But in the execution machinery they are identical. So it's a relief to me that you've pin-pointed a UI issue. That makes sense to me, whereas, say, differences in GC performance due to finalisation load would confuse me as I see no likely cause of the size of effect you're seeing. HTH John Brant > _,,,^..^,,,_ best, Eliot

June 21, 2016

Re: [Pharo-dev] Pharo vs. Squeak performance

by ClÃ©ment Bera

On Tue, Jun 21, 2016 at 10:18 PM, John Brant <brant(a)refactoryworkers.com> wrote: > On 06/21/2016 02:29 AM, ClÃ©ment Bera wrote: > >> Hello John. >> >> I'm just guessing here. Lacking information. It could be: >> >> Guess 1) the vm versions are different. >> What version of Pharo do you use ? (world menu>System>About) Something >> like: >> Pharo6.0 >> Latest update: #60030 >> What version of Squeak do you use ? (world menu>Help>About this system) >> Something like: >> Squeak5.0 >> latest update: #15792 >> What vm do you use in both cases ? What does answer ? >> In Pharo: Smalltalk vm version >> In Squeak: Smalltalk vmVersion >> > > I just downloaded the latest to test on my Linux machine: > > Pharo6.0 > Latest update: #60101 > > Pharo VM: > 'CoInterpreter VMMaker.oscog-HolgerHansPeterFreyther.1880 uuid: > 16138eb3-2390-40f5-a6c8-15f0494936f8 Jun 21 2016 > StackToRegisterMappingCogit VMMaker.oscog-HolgerHansPeterFreyther.1880 > uuid: 16138eb3-2390-40f5-a6c8-15f0494936f8 Jun 21 2016 > https://github.com/pharo-project/pharo-vm.git Commit: > 9638b0190a9fc01479bfb752becd96edfd253c8c Date: 2016-06-21 12:29:26 +0200 > By: GitHub <noreply(a)github.com> Jenkins build #594 > ' > > Squeak: > Image > ----- > /home/brant/Smalltalk/Squeak/SpurTrunkImage.image > Squeak5.1 > latest update: #16066 > Current Change Set: Unnamed1 > Image format 6521 (32 bit) > > Virtual Machine > --------------- > /home/brant/Smalltalk/Squeak/lib/squeak/5.0-3732/squeak > Croquet Closure Cog[Spur] VM [CoInterpreterPrimitives > VMMaker.oscog-eem.1872] > Unix built on May 26 2016 15:18:08 Compiler: 4.4.7 20120313 (Red Hat > 4.4.7-4) > platform sources revision VM: r3732 > http://www.squeakvm.org/svn/squeak/branches/Cog Date: 2016-05-26 13:01:37 > -0700 Plugins: r3730 > http://squeakvm.org/svn/squeak/trunk/platforms/Cross/plugins > CoInterpreter VMMaker.oscog-eem.1872 uuid: > 6db6d610-b1a5-4f4d-978d-22c917bdb3e4 May 26 2016 > StackToRegisterMappingCogit VMMaker.oscog-eem.1860 uuid: > 4d58d995-ee0c-4330-9190-adfa038e8f24 May 26 2016 > > Starting the image, opening a workspace/playground, and executing "Time > millisecondsToRun: [1 to: 100000000 do: [:i | Object new]]" 10 times, I got > these times in Pharo: > > "2147" "2303" "1177" "1127" "1153" "1179" "1162" "1136" "1262" "1148" > > Closing that image, and doing it again, I got these: > > "2128" "2210" "2239" "2051" "2040" "2070" "2087" "2166" "2060" "2078" > > Doing it once in Squeak, I got: > > 1183 1189 1193 1189 1216 1238 1193 1273 1218 1214 > > I done it a few more times in both, and Squeak always had times from the > upper 1100's to the upper 1200's, but Pharo had times from the low 1100's > to the 2300's. > > Guess 2) the machine code zone size are different >> Can you try in Squeak: >> Smalltalk vmParameterAt: 46 >> and in Pharo: >> Smalltalk vm parameterAt: 46. >> >> Is it the same ? >> It's the number of bytes of the machine code zone. If you need >> performance and you can afford wasting an extra Mb, you can speed it up >> by doing: >> Smalltalk vm parameterAt: 47 put: ((Smalltalk vm parameterAt: 46) * 2) >> And then restarting the image. >> Don't grow over 2Mb. >> > > They are both 1MB. > > Guess 3) the UI is known to be much slower in Pharo. Can you try >> headless or after ticking "Server mode" In the Pharo settings in System. >> > > This appears to be what is causing the problem. Even though I'm not using > any UI when I run my code, it must be doing something in the background > that is causing the slowdown. When I ran my model code headlessly in > Pharo, it actually finished the 2 minute job a couple seconds faster than > the headless Squeak image (instead of 30 seconds slower). Very interesting. So it's UI-related. If you close all windows but the workspace where you run your code, does it solve the problem ? I believe it tries to update something somehow. > > > > John Brant > >

June 21, 2016

Re: [Pharo-dev] [pharo-project/pharo-core] 90d82f: 60103

by Tudor Girba

It only took 8 years or so :) Doru > On Jun 21, 2016, at 11:02 PM, stepharo <stepharo(a)free.fr> wrote: > > Hourray!!!!!! > > Object has no name :) > > Stef > > > Le 21/6/16 Ã 18:02, GitHub a Ã©crit : >> 60103 >> 18554 Update SystemCommandLineHandler dependencies >> https://pharo.fogbugz.com/f/cases/18554 >> >> 18553 AST based execution counter >> https://pharo.fogbugz.com/f/cases/18553 >> >> 18552 Move menu item morph creation to RubSegment >> https://pharo.fogbugz.com/f/cases/18552 >> >> 7241 Object>>#name should best be removed >> https://pharo.fogbugz.com/f/cases/7241 > > -- www.tudorgirba.com www.feenk.com "Quality cannot be an afterthought."

June 21, 2016

Re: [Pharo-dev] [pharo-project/pharo-core] 90d82f: 60103

by stepharo

Hourray!!!!!! Object has no name :) Stef Le 21/6/16 Ã 18:02, GitHub a Ã©crit : > 60103 > 18554 Update SystemCommandLineHandler dependencies > https://pharo.fogbugz.com/f/cases/18554 > > 18553 AST based execution counter > https://pharo.fogbugz.com/f/cases/18553 > > 18552 Move menu item morph creation to RubSegment > https://pharo.fogbugz.com/f/cases/18552 > > 7241 Object>>#name should best be removed > https://pharo.fogbugz.com/f/cases/7241

June 21, 2016

Re: [Pharo-dev] Easy to use execution counter with Icon in Editor

by Tudor Girba

He he! I love these goodies. Doru > On Jun 21, 2016, at 5:45 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Hi, > > In the 60#103 there will be a new kind of âWatcherâ: an execution-counter. > > Using the âsuggestionâ menu one can add a counter to any AST node. > After, the editor shows a (c) Icon. Mouse over â> current state of the counter is shown. > > Of course, UI is just a stand-in and could be *much* better. But from a debug > perspective, it already should be quite useful to get a feel of how often something > gets executed. > > Henrik suggest this as a demo (and an example of how to install a Counter without using > the UI): > > ExecutionCounter installOn: (RubParagraphDecorator >> #doesNotUnderstand:) ast > > Marcus -- www.tudorgirba.com www.feenk.com "Quality cannot be an afterthought."

June 21, 2016