- Pharo-dev - lists.pharo.org

How to decompile a block?

by Jan Vrany

Hi, Decompiler>>decompileBlock: vanished in 3.0 (present in 2.0). What's the code for doing the same in 3.0? Jan P.S.: Copy-paste of code from 2.0 to 3.0 does not work, not a big surprise :-)

April 4, 2014

Syntax Visualisation in the C# infrastructure

by Goubier Thierry

It seems that Microsoft has opened interesting parts of the C# compilation infrastructure, including syntax visualisation. http://roslyn.codeplex.com/wikipage?title=Syntax%20Visualizer&referringTitl… Ideas for Opal+Roassal2 ? Thierry -- 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

April 4, 2014

Re: [Pharo-dev] Puzzled

by Camille Teruel

I tried on my machine in latest image and no matter how many times I run this test, this test still passes and I don't notice any slowdown nor image freeze. But I see the hanging processes. Adding 'process terminate' at the end works for me. On 3 avr. 2014, at 19:41, Pharo4Stef <pharo4Stef(a)free.fr> wrote: > Hi guys > > I need your brain cells. > > When I execute the test > > testBasic > | context process debugger printedString | > context := [ 20 factorial ] asContext. > > process := Process > forContext: context > priority: Processor userInterruptPriority. > > debugger := Smalltalk tools debugger new > process: process > controller: nil > context: context. > debugger stack expand. > > self assert: debugger stack selectedIndex = 1. > printedString := OpalCompiler isActive > ifTrue: [ '[ 20 factorial ] in DebuggerTest>>testBasic'] > ifFalse: [ '[...] in DebuggerTest>>testBasic' ]. > self assert: debugger stack selectedItem printString = printedString. > > debugger send. > debugger send. > self assert: debugger code getText = (Integer>>#factorial) sourceCode. > self assert: debugger stack selectedItem printString = 'SmallInteger(Integer)>>factorial'. > > two times my image (latest get totally unusable). > I thought that may be the process should be terminated > so I added > > process terminate > > But nothing changes. I tried to debug the code but not chance. > I tried self halt after [ 20 factorial ] asContext. > > I tried to execute the beginning in a workspace and not as a test to eliminate problem. > But again no chance. > > > So did I miss something obvious? > > Stef > > > > >

April 4, 2014

Re: [Pharo-dev] Puzzled

by Sven Van Caekenberghe

It is hard for everyone to get a complex issue cleanly integrated. On 04 Apr 2014, at 08:30, Pharo4Stef <pharo4Stef(a)free.fr> wrote: > Iâm sorry but I will stop working on this issue since I do not have time for pharo anymore this week and the next one. > Apparently Iâm the only one to care about this bogus logic so let it be but be prepared to have too many hanging process around. > Stef > >> Hey, >> >> I remembered removing the initializeAutoRefresh code from the debugger. Perhaps I didn't commit that package. Or I forgot this one. >> >> >> 2014-04-03 12:34 GMT-07:00 Pharo4Stef <pharo4Stef(a)free.fr>: >> ok now I understand: an endless loop inside the debugger creation. I do not understand why we did not address it with clement >> because we open the debugger and other when we fixed the logic of the inspector (to avoid polling refresh). >> >> Stef >> On 03 Apr 2014, at 21:13, Pharo4Stef <pharo4Stef(a)free.fr> wrote: >> >> > >> > | context process debugger | >> > context := [ 20 factorial ] asContext. >> > >> > process := Process >> > forContext: context >> > priority: Processor userInterruptPriority. >> > [ >> > debugger := Smalltalk tools debugger new >> > process: process >> > controller: nil >> > context: context. >> > Transcript show: debugger stack class ; cr >> > ] ensure: [ process terminate] >> > >> > >> > When I look at some of the stuck processes >> > >> > SpecDebugger>>initializePresenter >> > super initializePresenter. >> > self flag: 'some of this logic could be moved to the stack widget'. >> > self flag: 'The toolbar should not be updated when the list changes, but when an action is perormed.'. >> > self stack whenListChanged: [ :aList | >> > aList isEmpty ifFalse: [ self stack setSelectedItem: aList first ]. >> > "Updating the toolbar will result in changing the button widgets. >> > If the widget hasn't been opened, there will be no spec, which leads to an error." >> > self spec ifNotNil: [ >> > self updateToolbar ] ]. >> > >> > self stack whenSelectedItemChanged: [:aContext | >> > self updateCodeFromContext: aContext. >> > self updateInspectorsFromContext: aContext. >> > self stack updateForSelectionChanged ]. >> > >> > self contextInspector initializeAutoRefresh. >> > >> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> > >> > And initializeAutoRefresh does not exist in the latest image. >> > I have no idea why the debugger may work may be this method is not used at all. >> > >> > Can somebody else confirm because I have the impression to fall into a rat nest. >> > stef >> >> >> >

April 4, 2014

Re: [Pharo-dev] [Moose-dev] Re: Re: Re: Fwd: Font problem is still there

by Pharo4Stef

> > I don't think there is any way for the VM to know the #pixelsPerInch of the > display, regardless of the display resolution. There is no api in the OS for that? It would be really strange that we cannot know such information. > Maybe that implies that some > calibration would be needed in the image to relate font points to the > physical display. > > Dave >

April 4, 2014

Re: [Pharo-dev] [Moose-dev] Re: Re: Re: Fwd: Font problem is still there

by Pharo4Stef

Igor I was wondering the following: ? But TextStyle is not about strikefont? Stef On 04 Apr 2014, at 02:55, Igor Stasenko <siguctua(a)gmail.com> wrote: > Okay, i think i got it.. > > Here is what happens: > - the font size is usually specified in points, not x@y points, but typographical points, > which is > 1/72 inch > > > TextStyle pointsToPixels: 14 > > TextStyle pointsToPixels: 14 => 18.666666666666668 > > pointsToPixels: points > ^points * self pixelsPerInch / 72.0 > > > but in Athens, i , stupid idiot, completely forgot about that, > and use point size directly, to scale up font .. > but the point is that this scaling performed in font units (EMs). > > so, to actually scale font correctly, i must use same TextStyle pointsToPixels: .. > as Freetype package using.. > > there is one caveat, that if you really want to see exactly , say 16 points sized font on your screen, > it is not possible without knowing the display resolution - how many pixels in one inch (hence > #pixelsPerInch ). > Unfortunately, our VMs don't give us a way to determine DPI of display.. > and so, it is always 96 :/ > > pheww.... > > fromFreetypeFont: aFont cairoFace: face > ..... > > - fontMatrix scaleBy: aFont pointSize. > > + fontMatrix scaleBy: (TextStyle pointsToPixels: aFont pointSize). > > problem solved ... (i hope) :) > > -- > Best regards, > Igor Stasenko.

April 4, 2014

Re: [Pharo-dev] Puzzled

by Pharo4Stef

Iâm sorry but I will stop working on this issue since I do not have time for pharo anymore this week and the next one. Apparently Iâm the only one to care about this bogus logic so let it be but be prepared to have too many hanging process around. Stef > Hey, > > I remembered removing the initializeAutoRefresh code from the debugger. Perhaps I didn't commit that package. Or I forgot this one. > > > 2014-04-03 12:34 GMT-07:00 Pharo4Stef <pharo4Stef(a)free.fr>: > ok now I understand: an endless loop inside the debugger creation. I do not understand why we did not address it with clement > because we open the debugger and other when we fixed the logic of the inspector (to avoid polling refresh). > > Stef > On 03 Apr 2014, at 21:13, Pharo4Stef <pharo4Stef(a)free.fr> wrote: > > > > > | context process debugger | > > context := [ 20 factorial ] asContext. > > > > process := Process > > forContext: context > > priority: Processor userInterruptPriority. > > [ > > debugger := Smalltalk tools debugger new > > process: process > > controller: nil > > context: context. > > Transcript show: debugger stack class ; cr > > ] ensure: [ process terminate] > > > > > > When I look at some of the stuck processes > > > > SpecDebugger>>initializePresenter > > super initializePresenter. > > self flag: 'some of this logic could be moved to the stack widget'. > > self flag: 'The toolbar should not be updated when the list changes, but when an action is perormed.'. > > self stack whenListChanged: [ :aList | > > aList isEmpty ifFalse: [ self stack setSelectedItem: aList first ]. > > "Updating the toolbar will result in changing the button widgets. > > If the widget hasn't been opened, there will be no spec, which leads to an error." > > self spec ifNotNil: [ > > self updateToolbar ] ]. > > > > self stack whenSelectedItemChanged: [:aContext | > > self updateCodeFromContext: aContext. > > self updateInspectorsFromContext: aContext. > > self stack updateForSelectionChanged ]. > > > > self contextInspector initializeAutoRefresh. > > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > And initializeAutoRefresh does not exist in the latest image. > > I have no idea why the debugger may work may be this method is not used at all. > > > > Can somebody else confirm because I have the impression to fall into a rat nest. > > stef > > >

April 4, 2014

Re: [Pharo-dev] [Moose-dev] Re: Re: Re: Fwd: Font problem is still there

by David T. Lewis

On Fri, Apr 04, 2014 at 02:55:01AM +0200, Igor Stasenko wrote: > > there is one caveat, that if you really want to see exactly , say 16 points > sized font on your screen, > it is not possible without knowing the display resolution - how many pixels > in one inch (hence > #pixelsPerInch ). > Unfortunately, our VMs don't give us a way to determine DPI of display.. > and so, it is always 96 :/ > > pheww.... I don't think there is any way for the VM to know the #pixelsPerInch of the display, regardless of the display resolution. Maybe that implies that some calibration would be needed in the image to relate font points to the physical display. Dave

April 4, 2014

Re: [Pharo-dev] [Moose-dev] Re: Re: Re: Fwd: Font problem is still there

by Igor Stasenko

Okay, i think i got it.. Here is what happens: - the font size is usually specified in points, not x@y points, but typographical points, which is 1/72 inch TextStyle pointsToPixels: 14 TextStyle pointsToPixels: 14 => 18.666666666666668 pointsToPixels: points ^points * self pixelsPerInch / 72.0 but in Athens, i , stupid idiot, completely forgot about that, and use point size directly, to scale up font .. but the point is that this scaling performed in font units (EMs). so, to actually scale font correctly, i must use same TextStyle pointsToPixels: .. as Freetype package using.. there is one caveat, that if you really want to see exactly , say 16 points sized font on your screen, it is not possible without knowing the display resolution - how many pixels in one inch (hence #pixelsPerInch ). Unfortunately, our VMs don't give us a way to determine DPI of display.. and so, it is always 96 :/ pheww.... fromFreetypeFont: aFont cairoFace: face ..... - fontMatrix scaleBy: aFont pointSize. + fontMatrix scaleBy: (TextStyle pointsToPixels: aFont pointSize). problem solved ... (i hope) :) -- Best regards, Igor Stasenko.

April 4, 2014

Re: [Pharo-dev] Puzzled

by ClÃ©ment Bera

Hey, I remembered removing the initializeAutoRefresh code from the debugger. Perhaps I didn't commit that package. Or I forgot this one. 2014-04-03 12:34 GMT-07:00 Pharo4Stef <pharo4Stef(a)free.fr>: > ok now I understand: an endless loop inside the debugger creation. I do > not understand why we did not address it with clement > because we open the debugger and other when we fixed the logic of the > inspector (to avoid polling refresh). > > Stef > On 03 Apr 2014, at 21:13, Pharo4Stef <pharo4Stef(a)free.fr> wrote: > > > > > | context process debugger | > > context := [ 20 factorial ] asContext. > > > > process := Process > > forContext: context > > priority: Processor userInterruptPriority. > > [ > > debugger := Smalltalk tools debugger new > > process: process > > controller: nil > > context: context. > > Transcript show: debugger stack class ; cr > > ] ensure: [ process terminate] > > > > > > When I look at some of the stuck processes > > > > SpecDebugger>>initializePresenter > > super initializePresenter. > > self flag: 'some of this logic could be moved to the stack widget'. > > self flag: 'The toolbar should not be updated when the list > changes, but when an action is perormed.'. > > self stack whenListChanged: [ :aList | > > aList isEmpty ifFalse: [ self stack setSelectedItem: aList > first ]. > > "Updating the toolbar will result in changing the button > widgets. > > If the widget hasn't been opened, there will be no spec, > which leads to an error." > > self spec ifNotNil: [ > > self updateToolbar ] ]. > > > > self stack whenSelectedItemChanged: [:aContext | > > self updateCodeFromContext: aContext. > > self updateInspectorsFromContext: aContext. > > self stack updateForSelectionChanged ]. > > > > self contextInspector initializeAutoRefresh. > > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > And initializeAutoRefresh does not exist in the latest image. > > I have no idea why the debugger may work may be this method is not used > at all. > > > > Can somebody else confirm because I have the impression to fall into a > rat nest. > > stef > > >

April 3, 2014