- Pharo-dev - lists.pharo.org

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

Re: [Pharo-dev] [pharo3 issues] down to 17 issues

by Ben Coman

Marcus Denker wrote: > Hi, > > We are down to 17 open issues that are tagged âmust fixâ or higher: > > https://pharo.fogbugz.com/f/filters/64/3-0-TODO > > two of those have code that is in need of review. > > Marcus > > That is really great Marcus. Thanks for your efforts and those of the other integrators. cheers -ben

April 5, 2014

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

by Marcus Denker

On 05 Apr 2014, at 13:50, Hilaire Fernandes <hilaire.fernandes(a)gmail.com> wrote: > Ã temps, suspends ton vol! > > I will add this quote: It is costless to get things done right than undone. 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). Marcus

April 5, 2014

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

by Hilaire Fernandes

Ã temps, suspends ton vol! I will add this quote: It is costless to get things done right than undone. Hilaire Le 05/04/2014 13:16, Marcus Denker a Ã©crit : > Time. The secret is that in the end only those things are done that are done. -- Dr. Geo http://drgeo.eu

April 5, 2014

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

by Marcus Denker

On 05 Apr 2014, at 13:08, Hilaire Fernandes <hilaire.fernandes(a)gmail.com> wrote: > Hello, > > I have a question regarding the way the Pharo image is technically and > socially built. > One of the Pharo aim is to be a small and clean environment one can use > to develop and build dedicated application. > Dedicated tools as Metacello and Gofer are developed for this purpose. > Many architecture and dev tools are developed and replacing the old > ones: spec, nautillus, etc. > Now from the my peripheral point of view, it looks like these tools are > carved in the image, breaking the idea of a small and clean core image; > making difficult to build dedicated application image. > My question: why those tools were not developed to be loadable in a Pharo? > Time. The secret is that in the end only those things are done that are done. Marcus

April 5, 2014