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

Problem with Finder

by jannik laval

Hi guys, When I use the Finder, on a specific package, it does not take into account the class extensions. Is this bug already reported ? -- ~~Jannik Laval~~ Ãcole des Mines de Douai Enseignant-chercheur http://www.jannik-laval.eu http://www.phratch.com http://car.mines-douai.fr/

April 6, 2014

Re: [Pharo-dev] Syntax Visualisation in the C# infrastructure

by ClÃ©ment Bera

Yeah I use Roassal + Mondrian to visualize my intermediate representations in the compiler and doing it for the AST is really simple (like 5 min of work). In addition the GTInspector view on trees/graph is really nice. So basically we have all the tools they provide. 2014-04-05 17:56 GMT-07:00 Alexandre Bergel <alexandre.bergel(a)me.com>: > I am not sure to what syntax visualization is useful for, but indeed, this > is easy in Roassal > > Assuming a class MyVisitor, that simples collect the nodes of the AST. > > -=-=-=-=-=-=-=-=-=-= > | ast visitor g | > "We get the nodes from the AST" > ast := RBParser parseMethod: (ArrayTest>>#testReplaceFromToWithStartingAt) > getSource. > visitor := MyVisitor new. > ast acceptVisitor: visitor. > > "Visualization" > g := RTGraphBuilder new. > g node > if: #isMessage shape: (RTEllipse new size: 10; color: Color red ) + > (RTLabel new text: #selector); > if: #isReturn shape: (RTEllipse new size: 10; color: Color red ); > if: #isBlock shape: (RTBox new size: 10; color: Color blue ); > shape: (RTEllipse new size: 10; color: Color gray ). > g layout use: RTTreeLayout new. > g edge connectTo: #parent. > > g addAll: visitor nodes. > > g applyLayout. > g view > -=-=-=-=-=-=-=-=-=-= > > > Cheers, > Alexandre > > > On Apr 4, 2014, at 4:34 AM, Goubier Thierry <thierry.goubier(a)cea.fr> > wrote: > > 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 > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >

April 6, 2014

Fogbugz simple review voting

by Ben Coman

Just musing over a simple voting system for Fogbugz, perhaps just the addition of statuses: * Resolved (Reviewed by 1) * Resolved (Reviewed by 2) and also useful might be: * Working On (Feedback Requested) cheers -ben

April 6, 2014

12178 Extended-class-shown-twice-in-Browser

by Ben Coman

This one is ready to go. Been review by Martin, Nicolai and myself. https://pharo.fogbugz.com/f/cases/12178/Extended-class-shown-twice-in-Brows…

April 6, 2014

Re: [Pharo-dev] Syntax Visualisation in the C# infrastructure

by Alexandre Bergel

I am not sure to what syntax visualization is useful for, but indeed, this is easy in Roassal Assuming a class MyVisitor, that simples collect the nodes of the AST. -=-=-=-=-=-=-=-=-=-= | ast visitor g | "We get the nodes from the AST" ast := RBParser parseMethod: (ArrayTest>>#testReplaceFromToWithStartingAt) getSource. visitor := MyVisitor new. ast acceptVisitor: visitor. "Visualization" g := RTGraphBuilder new. g node if: #isMessage shape: (RTEllipse new size: 10; color: Color red ) + (RTLabel new text: #selector); if: #isReturn shape: (RTEllipse new size: 10; color: Color red ); if: #isBlock shape: (RTBox new size: 10; color: Color blue ); shape: (RTEllipse new size: 10; color: Color gray ). g layout use: RTTreeLayout new. g edge connectTo: #parent. g addAll: visitor nodes. g applyLayout. g view -=-=-=-=-=-=-=-=-=-= Cheers, Alexandre On Apr 4, 2014, at 4:34 AM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > 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 > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 6, 2014

Hierarchy view in Nautilus

by Alexandre Bergel

Hi! Selecting a class in a hierarchy view in Nautilus switches back to the Flat new. Is this really something we want? Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 6, 2014

Re: [Pharo-dev] Build process of Pharo image

by Hilaire Fernandes

Still, I do not get why the newer packages are not loadable with configurations instead of been carved in the image. Why can't packages developers provide such configurations? Why don't we have an image without those packages? Then public images built with. Is it not what Jenkins is supposed to do? I am afraid the situation looks like Etoys carved in Squeak. Hilaire Le 05/04/2014 18:32, Marcus Denker a Ã©crit : > Yes, we need to look into a more modular build in Pharo4â¦ to not just load updates > on the server but instead build from a small core (and possibly even from a bootstrap). -- Dr. Geo http://drgeo.eu

April 5, 2014

Re: [Pharo-dev] Puzzled

by Pharo4Stef

In fact there was an error in the debugger code => endless loop in another thread it was strange because the test was not returning On 05 Apr 2014, at 19:30, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Stef, > > I think it is because forContext:priority: does not schedule the process, just creates it. The debugger code steps the process but after stepping the process is still not runnable. So the process terminate is unnecessary; the process should not have been added to the run queue and should juts be GCed. Since it is not the question is what refers to the process after the test has run. > > To debug, I would rewrite the test as such: > > testBasic > | process debugger printedString | > process := Process > forContext: [ 20 factorial ] asContext > priority: Processor activePriority. > > 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'. > > ^process > > and then chase pointers on the result to see what is holding onto the process. Sicne the process is never runnable there's no need to set its priority to anything special. > > However, one should also be able to replace the "process terminate" with "process resume" to get it to run to termination (provided its priority stays at Processor userInterruptPriority). > > HTH > > > On Thu, Apr 3, 2014 at 10:41 AM, 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 > > > > > > > > > -- > best, > Eliot

April 5, 2014

Re: [Pharo-dev] Puzzled

by Eliot Miranda

On Sat, Apr 5, 2014 at 10:30 AM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > Hi Stef, > > I think it is because forContext:priority: does not schedule the > process, just creates it. The debugger code steps the process but after > stepping the process is still not runnable. So the process terminate is > unnecessary; the process should not have been added to the run queue and > should juts be GCed. Since it is not the question is what refers to the > process after the test has run. > (Since it is not GCed, the question is "what refers to the process after the test has run?"). To debug, I would rewrite the test as such: > > testBasic > | process debugger printedString | > process := Process > forContext: [ 20 factorial ] asContext > priority: Processor activePriority. > > > 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'. > > ^process > > and then chase pointers on the result to see what is holding onto the > process. Sicne the process is never runnable there's no need to set its > priority to anything special. > > However, one should also be able to replace the "process terminate" with > "process resume" to get it to run to termination (provided its priority > stays at Processor userInterruptPriority). > > HTH > > > On Thu, Apr 3, 2014 at 10:41 AM, 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 >> >> >> >> >> >> > > > -- > best, > Eliot > -- best, Eliot

April 5, 2014

Re: [Pharo-dev] Puzzled

by Eliot Miranda

Hi Stef, I think it is because forContext:priority: does not schedule the process, just creates it. The debugger code steps the process but after stepping the process is still not runnable. So the process terminate is unnecessary; the process should not have been added to the run queue and should juts be GCed. Since it is not the question is what refers to the process after the test has run. To debug, I would rewrite the test as such: testBasic | process debugger printedString | process := Process forContext: [ 20 factorial ] asContext priority: Processor activePriority. 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'. ^process and then chase pointers on the result to see what is holding onto the process. Sicne the process is never runnable there's no need to set its priority to anything special. However, one should also be able to replace the "process terminate" with "process resume" to get it to run to termination (provided its priority stays at Processor userInterruptPriority). HTH On Thu, Apr 3, 2014 at 10:41 AM, 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 > > > > > > -- best, Eliot

April 5, 2014