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

Senders Changing

by Sven Van Caekenberghe

Hi, Has anyone seen this: open a senders list, leave it open like a todo, implement another method somewhere, it appears in the senders list even if it does not match... Sven

Jan. 15, 2014

Re: [Pharo-dev] Roassal Visualization for control flow graph issues

by ClÃ©ment Bera

Hello, I looked in the literature and there are a few paper about exactly the visualization I want. Examples: a paper about Graph Layout for Code Flow Visualization http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.112.3748&rep=rep1&… a bachelor thesis on java control flow graph visualization for compiler optimization http://ssw.jku.at/General/Staff/TW/Wuerthinger06Bachelor.pdf Perhaps at some point if we find a bachelor to hire in our team we could ask him to implement such a visualization too (as they did for java seemingly). But I looked at java's control flow graph I saw they would not increase much my productivity compared to what I have now, back jumps are displayed but not in a so good way. Therefore I'll use what I have now. However it would be nice to have that to teach easily compiler optimizations to people. Doru, I *really* need dedicated tools but I have already built them myself. A year ago, I didn't know about GTInspector and Moldable debugger, so I built dedicated inspectors with the old inspector framework of Pharo, then as it was not good enough I built new inspectors based on Spec, and I ported the generic classes of these inspectors in Pharo 3. Specific subclasses of these inspectors exist for my projects. For example, here's an inspector of an object in memory (an object oriented pointer): [image: Images intÃ©grÃ©es 1] With on the left the current address in memory, then what field it is for the object (which is the class MethodDictionary), then the address written at this memory location, and the result of #printString sent to this new address. The next tool I'm going to built is a read only debugger (I mean without on the fly method edition) to step on x86 disassembled instructions and its abstract representation (similar to R*egister Transfer Language <http://fr.wikipedia.org/wiki/Register_Transfer_Language>)* I used in my compilation chain. I discussed once with Andrei and it seems the moldable debugger fits more in the case where you need to debug smalltalk code or at least byte code dependent code. In my case I compile from AST to x86 skipping the byte code so as far as I know it is quite hard to build a tool with what you have. In addition, I'd like to plug the Spec inspectors I built before, which may not be easy if I choose to build the additional tools in Glamour. So the timing is not very good for tools in my projects. Thanks for offering your help anyway. However the tool you showed on RB AST is really cool, especially that I use all the time intermediate representations that could perfectly fit this kind of inspectors (mostly graphs). But I prefer visualization like the one of roassal. Regards 2014/1/15 Marcus Denker <marcus.denker(a)inria.fr> > > On 14 Jan 2014, at 22:06, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > > As far as I can see, the visualization is derived from source code. This > can be seen as being similar to how an AST is derived from source code. The > GTInspector already provides an implementation of understanding this > mapping. For example, in an image with GTInspector (just download the Moose > one for quick tests) do: > > (Collection>>#collect:) parseTree inspect > > > > and you get a picture like the attached one. > > <Inspector on a RBMethodNode (coll...ion).png> > > This is *very* impressiveâ¦ :-) > > Marcus > > >

Jan. 15, 2014

Re: [Pharo-dev] Roassal Visualization for control flow graph issues

by Goubier Thierry

Hi Clement, for something like that, try the Sugiyama Layout in Roassal. This is the layout we usually use when we have to display control flow graphs over code with Dot. Thierry Le 14/01/2014 16:50, ClÃ©ment Bera a Ã©crit : > Hello Roassal developers, > > A few time ago Usman Bhatti showed me Roassal. Today I decided to use it > for my daily work on a project that aims to optimize Pharo's methods. > > Firstly I am quite impressed by the quality of Roassal, I am currently > using the Roassal + Mondrian builder and I have a visual representation > which is very close to what I want after 1 hour of work with the help of > Usman. Good job guys. > > Here are 2 examples of what I use: > > exampleIfTrueIfFalse2 > | a b | > a := true. > a > ifTrue: [ > false ifTrue: [ ^ b := 1 ] ifFalse: [ b := 2 ] ] > ifFalse: [ > true ifTrue: [ b := 4 ] ifFalse: [ b := 5 ] ]. > ^ b > > Images intÃ©grÃ©es 1 > > Here there's one rectangle for each basic block, entrance/exits are > basic blocks with bigger borders, and borders in red represents the "hot > path", which the path the execution flow most frequently uses (based on > native code counters added at some spots in the method by Cogit). > > Another example: > > exampleToDo > 1 to: 10 do: [ :i | > self kick: i ] > > Images intÃ©grÃ©es 3 > > Now I have a few issues with the layout. I am currently using > the narrowTreeLayout which seems to be the best for my visualisation. > > *issue 1:* When branches merges, which is in a tree when a node has 2 or > more parents, or when I have a #ifTrue:ifFalse:, the child is not well > aligned horizontally. Here in the first visualisation I showed, > BasicBlock 5 is below but not in the middle of Basic block 8,7 and 4 > (horizontally). I put a minimal width for each basic block to make it > better but it's still not perfect. > *issue 2:* (most important issue) I cannot display back jumps because > then all the graph is missdrawn, therefore I need to remember where they > are instead of visualizing them all the time (I cannot display the back > jump from basic block 3 to basic block 2 in the second representation. > In addition, the back jump edge, when well displayed, overlaps the basic > blocks visualizations. > > Here is an example of what I would like for the edges and basic block > positions: > > Images intÃ©grÃ©es 2 > > As you can see, here exit is in the middle of B2 and B5 horizontally, > which is not the case in my roassal visualization. > In addition, there's a back jump from B6 to B4 that I cannot display (or > all the visual representation goes nuts). The edge for the back jump > does not overlap with the basic blocks. In this graph, arrows follow a > grid. I don't care that arrows are diagonals instead of a mix of > horizontal and vertical lines but I would like to be able to see nicely > the back jumps as in this graph. > > Do you have an idea on what layout/view options I could use with Roassal > +Mondrian to have a better result ? > > I tried to create my own layout but after 2 hours I understood this cost > too much time for my planning (or perhaps I'm just too dumb to do it > fast :-( ). > > Anyway, the representation I have now is good enough for me to use it. > But a better one would be better, especially for back jumps :-). > > Thanks for any help. > > Clement -- 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

Jan. 15, 2014

Re: [Pharo-dev] Smalltalk Impact

by Marcus Denker

On 15 Jan 2014, at 09:01, Hilaire Fernandes <hilaire.fernandes(a)gmail.com> wrote: > Le 15/01/2014 08:17, Marcus Denker a Ã©crit : >>> Scratch is very famous worldwide. A few days ago I heard about it in a >>>> national radio show about sciences. >>>> This is why Phratch & al are jewels, to keep the lineage to Smalltalk ;-) >>>> >> No imagine how big the impact *could* have been if we would have done it right... >> > > It doesn't matter, it belongs to the past, and each one has his/her own > share of it. Pharo is a nice attempt to fix it and to make an opensource > environment to develop portable Smalltalk application, step by step, > stone after stone. > > Btw, do you have a list of the right things? > Etoys should have contributed to Squeak when they had the resources. To secure their own future. âWe are not payed to work on Squeakâ, that is what I got toldâ¦ in a tone as if my questions was the dumbest question one could have asked. Marcus

Jan. 15, 2014

Re: [Pharo-dev] Smalltalk Impact

by Hilaire Fernandes

Le 15/01/2014 08:17, Marcus Denker a Ã©crit : >> Scratch is very famous worldwide. A few days ago I heard about it in a >> > national radio show about sciences. >> > This is why Phratch & al are jewels, to keep the lineage to Smalltalk ;-) >> > > No imagine how big the impact *could* have been if we would have done it right... > It doesn't matter, it belongs to the past, and each one has his/her own share of it. Pharo is a nice attempt to fix it and to make an opensource environment to develop portable Smalltalk application, step by step, stone after stone. Btw, do you have a list of the right things? Hilaire -- Dr. Geo http://drgeo.eu

Jan. 15, 2014

[pharo-project/pharo-core] 6a9824: 30696

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: 6a982436b9d619bbc10517f2aa766db85dfa742f https://github.com/pharo-project/pharo-core/commit/6a982436b9d619bbc10517f2… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-01-14 (Tue, 14 Jan 2014) Changed paths: M Kernel.package/NumberParser.class/instance/parsing-large int/nextLargeIntegerBase_nPackets_.st A KernelTests.package/NumberParserTest.class/instance/tests - Float/testFloatmin.st M NativeBoost-Tests.package/NBWin32WindowTest.class/instance/tests/testIsVisible.st M NativeBoost-Tests.package/NBWin32WindowTest.class/instance/tests/testWindowFromPoint.st M Nautilus.package/NautilusUI.class/instance/accessing/selectedClassWithoutChangingSelection_.st A Nautilus.package/NautilusUI.class/instance/private/selectedClass_withSelection_.st A Nautilus.package/NautilusUI.class/instance/private/unselectClass.st A Nautilus.package/NautilusUI.class/instance/private/updateOnClassSelection.st R Nautilus.package/PackageTreeNautilusUI.class/instance/accessing/selectedClassWithoutChangingSelection_.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script349.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30696.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 30696 12625 toggling hierarchy/flat shows wrong package and hides selected class https://pharo.fogbugz.com/f/cases/12625 12647 NativeBoost: two tests failing on windows https://pharo.fogbugz.com/f/cases/12647 12642 bug in NumberParser when reading a number with fraction part https://pharo.fogbugz.com/f/cases/12642 http://files.pharo.org/image/30/30696.zip

Jan. 15, 2014

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/30696 Home: https://github.com/pharo-project/pharo-core

Jan. 15, 2014

Re: [Pharo-dev] Roassal Visualization for control flow graph issues

by Marcus Denker

On 14 Jan 2014, at 22:06, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > As far as I can see, the visualization is derived from source code. This can be seen as being similar to how an AST is derived from source code. The GTInspector already provides an implementation of understanding this mapping. For example, in an image with GTInspector (just download the Moose one for quick tests) do: > (Collection>>#collect:) parseTree inspect > > and you get a picture like the attached one. > <Inspector on a RBMethodNode (coll...ion).png> This is *very* impressiveâ¦ :-) Marcus

Jan. 15, 2014

Re: [Pharo-dev] Smalltalk Impact

by Marcus Denker

On 14 Jan 2014, at 22:38, Hilaire Fernandes <hilaire.fernandes(a)gmail.com> wrote: > Scratch is very famous worldwide. A few days ago I heard about it in a > national radio show about sciences. > This is why Phratch & al are jewels, to keep the lineage to Smalltalk ;-) > No imagine how big the impact *could* have been if we would have done it right... > Thanks > > Hilaire > > Le 14/01/2014 19:02, Sean DeNigris a Ã©crit : >> Last week I attended an event at the The Metropolitan Museum of Art Media Lab. While networking, two educators told me that they use Scratch with their kidsâ¦ not knowing I knew anything about it. They showed me some of their students' projects and were so proud and excited. They were also intrigued when I shared Scratch's lineage, connecting the dots back to the dynabook vision of computers as a metamedium to transform human thought. I talked about Smalltalk, and directed them to Phratch - and its ability to create tiles - as a bridge between tile-based and "full fledged" programming, for those students who yearn for more expressive power. >> >> I thought you'd like to know that all of our work is rippling out in ways we can't imagineâ¦ >> >> Cheers, >> Sean >> > > > -- > Dr. Geo http://drgeo.eu > >

Jan. 15, 2014

Re: [Pharo-dev] [Moose-dev] Re: Feature for request for GraphET?

by Tudor Girba

I took a bit of time and added gapFraction support for horizontal bar diagram. It is not quite solid yet (it needs some refactoring), but the core is in place. We have to adapt the vertical bar diagram as well. There are two tests that fail, but I do not quite understand why: https://ci.inria.fr/moose/job/graph-et/307/testReport/junit/ In any case, now if you execute this in the very latest Moose image: MessageTally new spyEvery: 1 on: [10000 timesRepeat: [Collection withAllSubclassesDo: #printString]]; yourself. You get this (I still seem to have problems with the alignment of the inner bars): [image: Inline image 1] Doru On Wed, Jan 8, 2014 at 10:44 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi Daniel, > > Good work! > > But, there is still something I do not quite understand. Take a look at > the produced image. Why is it that in the first red bar appears behind the > gray one, and the rest appear in front of the corresponding gray bars? > > Related to the GapFraction: Could you describe what makes it such an > expensive issue to compute the width of the bar with a bit of scaling? I am > asking because this particular diagram does not work without it. > > Cheers, > Doru > > [image: Inline image 1] > > > > On Wed, Jan 8, 2014 at 6:50 PM, Daniel Aviv Notario < > daniel_avivnotario(a)hotmail.com> wrote: > >> So, attending to the request Doru made, here's something similar to the >> example he provided in EyeSee... All the methods were already implemented >> but most of them didn't have a clear accesor to modify them. >> >> So, if you just load the last version of GraphET and do this: >> >> >> builder := GETDiagramBuilder new. >> grouped := { #item1->{10 . 12 . 11 . 14 } . #item2-> { 1 . 1 . 20 >> } >> . #item3->{ 1 . 1 . 1 . 1 . 1} }. >> diag := (GETVerticalBarDiagram new) >> modelLabels: [:each | each key ]; >> y: [:each | each value size]; >> yAxisLabel: 'Count'; >> valueAxis; >> height:200; >> spacing:20; >> yAxisOnRight; >> color: Color veryLightGray; >> axisColor: Color veryLightGray; >> models: grouped; >> yourself. >> diag2 := (GETVerticalBarDiagram new) >> y: [:each | each value sum]; >> regularAxis; >> height: 200; >> spacing:20; >> yAxisLabel: 'Sum'; >> color: (Color red); >> axisColor: (Color red); >> models: grouped; >> yourself. >> (builder unionDiagram) >> add: diag; >> add: diag2. >> builder open >> >> >> You'll see it's very similar. There's two things I couldn't replicate so >> far, one of them is the rotating labels, as Roassal can't rotate labels >> yet, and the second one was the GapFraction, as axis in GraphET need some >> work yet, so implementing that kind of thing would be hard. I think I'll >> dedicate to a proper axis in the next couple of weeks. >> >> Cheers :)! >> >> > > >>> ---------- Forwarded message ---------- >> > > >>> From: Tudor Girba <tudor(a)tudorgirba.com> >> > > >>> Date: Sat, Jan 4, 2014 at 10:39 PM >> > > >>> Subject: Re: [Pharo-dev] Feature for request for GraphET? >> > > >>> To: Pharo Development List <pharo-dev(a)lists.pharo.org> >> > > >>> >> > > >>> >> > > >>> Here is one thing I would want: a correspondent Graph-ET >> > > >>> functionality to make something like this EyeSee script work as >> > > >>> in >> > > >>> the first attached picture. >> > > >>> >> > > >>> renderer := ESDiagramRenderer new. >> > > >>> grouped := { #item1->{10 . 12 . 11 . 14 } . #item2-> { 1 . 1 . 20 >> > > >>> } >> > > >>> . #item3->{ 1 . 1 . 1 . 1 . 1} }. >> > > >>> diag := (ESVerticalBarDiagram new) >> > > >>> identifier: [:each | each key ]; >> > > >>> y: [:each | each value size]; >> > > >>> yAxisLabel: 'Count'; >> > > >>> valueAxis; >> > > >>> rightYAxis; >> > > >>> defaultColor: Color veryVeryLightGray; >> > > >>> axisColor: Color veryVeryLightGray; >> > > >>> models: grouped; >> > > >>> rotatedLabels: true; >> > > >>> yourself. >> > > >>> diag2 := (ESVerticalBarDiagram new) >> > > >>> y: [:each | each value sum]; >> > > >>> regularAxis; >> > > >>> yAxisLabel: 'Sum'; >> > > >>> gapFraction: 2 / 3; >> > > >>> defaultColor: (Color red); >> > > >>> axisColor: (Color red); >> > > >>> models: grouped; >> > > >>> yourself. >> > > >>> (renderer compositeDiagram) >> > > >>> add: diag; >> > > >>> add: diag2. >> > > >>> renderer open >> > > >>> >> > > >>> >> > > >>> <Screenshot 2014-01-04 22.31.57.png> >> > > >>> >> > > >>> >> > > >>> The best I could produce with Graph-ET is this (I commented out >> > > >>> the >> > > >>> message to which I did not find a correspondent): >> > > >>> >> > > >>> builder := GETDiagramBuilder new. >> > > >>> grouped := { #item1->{10 . 12 . 11 . 14 } . #item2-> { 1 . 1 . 20 >> > > >>> } >> > > >>> . #item3->{ 1 . 1 . 1 . 1 . 1} }. >> > > >>> diag := (GETVerticalBarDiagram new) >> > > >>> "identifier: [:each | each key ];" >> > > >>> y: [:each | each value size]; >> > > >>> yAxisLabel: 'Count'; >> > > >>> valueAxisLine; >> > > >>> "rightYAxis;" >> > > >>> color: Color veryLightGray; >> > > >>> "axisColor: Color veryLightGray;" >> > > >>> models: grouped; >> > > >>> "rotatedLabels: true;" >> > > >>> yourself. >> > > >>> diag2 := (GETVerticalBarDiagram new) >> > > >>> y: [:each | each value sum]; >> > > >>> regularAxis; >> > > >>> yAxisLabel: 'Sum'; >> > > >>> "gapFraction: 2 / 3;" >> > > >>> color: (Color red); >> > > >>> "axisColor: (Color red);" >> > > >>> models: grouped; >> > > >>> yourself. >> > > >>> (builder compositeDiagram) >> > > >>> add: diag; >> > > >>> add: diag2. >> > > >>> builder open >> > > >>> >> > > >>> <Screenshot 2014-01-04 22.36.40.png> >> > > >>> >> > > >>> Cheers, >> > > >>> Doru >> > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > -- www.tudorgirba.com "Every thing has its own flow"

Jan. 15, 2014