April 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] How to decompile a block?

by Jan Vrany

Works like a charm, thanks! Jan On 04/04/14 09:51, Marcus Denker wrote: > > On 04 Apr 2014, at 09:45, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: > >> Hi, >> >> Decompiler>>decompileBlock: vanished in 3.0 (present in 2.0). >> What's the code for doing the same in 3.0? >> > > you call #sourceNode: > > [ 1 + 2 ] sourceNode > > Marcus > >

April 4, 2014

Re: [Pharo-dev] SmalltalkHub hug : recent watched events list frozen

by phil＠highoctane.be

My watched events list is in the same shape. Le 4 avr. 2014 09:47, "Serge Stinckwich" <serge.stinckwich(a)gmail.com> a Ã©crit : > Dear all, > > I dunno if this is know bug. I'm following more than 30 projects on > SmalltalkHub, but y recent watched events list is frozen since months > (last event from november). > Maybe there is a relationship with this issue : > https://code.google.com/p/smalltalk-hub/issues/detail?id=29 > > Regards, > -- > Serge Stinckwich > UCBN & UMI UMMISCO 209 (IRD/UPMC) > Every DSL ends up being Smalltalk > http://www.doesnotunderstand.org/ > >

April 4, 2014

Re: [Pharo-dev] How to decompile a block?

by Marcus Denker

On 04 Apr 2014, at 09:45, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: > Hi, > > Decompiler>>decompileBlock: vanished in 3.0 (present in 2.0). > What's the code for doing the same in 3.0? > you call #sourceNode: [ 1 + 2 ] sourceNode Marcus

April 4, 2014

SmalltalkHub hug : recent watched events list frozen

by Serge Stinckwich

Dear all, I dunno if this is know bug. I'm following more than 30 projects on SmalltalkHub, but y recent watched events list is frozen since months (last event from november). Maybe there is a relationship with this issue : https://code.google.com/p/smalltalk-hub/issues/detail?id=29 Regards, -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

April 4, 2014

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