Another option: Use the Moose Image and explore code using Roassal. http://www.moosetechnology.org/#install Check http://agilevisualization.com/ Also RTUMLClassBuilder can be useful. http://forum.world.st/Addling-lines-to-RTUMLClassBuilder-td4876221.html Phil On Thu, Jan 5, 2017 at 8:24 PM, Siemen Baader <siemenbaader@gmail.com> wrote:

Hi All,

I may be missing the obvious, but what are good strategies to understand the structure of existing code? Specifically, I'm trying to understand more of PharoJS to solve my own problems and eventually also to contribute back - but this is a general question.

There is this one MOOC exercise: http://rmod-pharo-mo oc.lille.inria.fr/MOOC/Exercises/Exercises-Pillar/Pillar-Questions.pdf that helps, and reading tests and comments helps if they exist. But I often get trapped in drilling down a long call stack and opening many, many browser windows, a new one for every message send to a new class.

While writing this it occured to me that I can use the debugger to follow a call stack by putting a breakpoint in the top level method, then stepping down using the debugger. There is also a MOOC lecture on that that I will look at again, http://rmod-pharo-mooc.lille.inria.fr/MOOC/Videos/W5/C019- W2S-VideosDebugger1-UsingTheDebugger-V2-HD_720p_4Mbs.m4v.

Any tips? I think I don't see the forest for the trees here I'm afraid :)

thanks, Siemen

After 5 years of using Pharo by far the best way to understand code is to ask questions here. I have read and still read a fair amount of code, but in 50% of the cases I have no clue what I am reading because following the chain of method calls can be confusing and frustrating even inside a cool IDE like that of Pharo. The good news is that pharoers here we have each our area of "expertise" even those like me that cannot be regarded as "pharo experts". My method is what I call "nuclear bombardment from orbit type of questioning" aka "I will question the hell out of this mailing lists". I miss the gene of shame when it comes to food , questions and some other things. So far, none has got angry with my unending streams of questions, quite the contrary I see evidently a trend of masochism of enjoying answering even the simplest questions, something that has infected me as well the last few years. As a workflow I love tests. I have to confess I am not a big fan of TDD development but I do abuse a lot Playground and Inspector. Reading tests can be also helpful if they are available. Its slow , its tedious at times but it almost always gets my questions answered if the mailing list cannot answer them. Its a kinda freestyle TDD, if you could call it TDD. I also love "self halt" aka debugger breakpoint. Debugger comes with its own inspector and Playground/Workspace so basically you got all the great tools in one place and is easy to see the stream of execution. But knowing where to put your breakpoints can be a challenge which sends me back to Playground. Finally I am the ultimate sinner and I generally avoid learning things I can easily create myself. I just find it far more productive. In theory it should not be, but in practice it is, especially against non documented complex APIs. For example with morphic, I have created my own buttons, switch buttons, input fields with automatic formatting for time etc. Most of these things do exist but I never bothered even subclassing them because creating them from scratch was faster and easier than understanding how to manipulate code that already exists. It also gives me more confidence when it comes to bug fixing which is the most annoying part of coding. There is however one case this approach went terrible wrong, with recreating the taskbar support , the api for that feature is just plain insane and I still have no clue how it works in its entirety. But it was a fun challenge more the less. We also doing surprisingly well in the documentation department and we have to thank the awesomeness of me, stephane, nicolas heis , Damien and many others that are regular contributors together with those that are not. Things are night and day compared to when I was introduced to Pharo back in 2011. We still have a ton of things that need documentation desperately but in 2016 was the first year I actually stopped complain like a child about the documentation because it has improved a lot and that makes feel all happy inside. I am sure it made other people here even happier that I stopped complaining. The nice thing is that Pharo code is a bit like puzzle, you start with no clue with what piece goes where but if you starting putting down the obvious/easy ones it gets easier and easier down the line. As a closing thought there is one advice I find the best advise that is given inside the PBE and basically says that is ok not to know how things work. At first I found it silly but now I see that knowing what you should invest on learning is an art and a skill by itself that every coder has to posses. Many questions here have been answered with people having no idea how something works but nonetheless the brainstorming ensuing after the initial question is enough to find the solution which of course as you probably know is so simple that is looking at our face . Its actually a fun experience which bonds our community close together in some cases with hilarious results. On Thu, Jan 5, 2017 at 9:25 PM Siemen Baader <siemenbaader@gmail.com> wrote:

Hi All,

I may be missing the obvious, but what are good strategies to understand the structure of existing code? Specifically, I'm trying to understand more of PharoJS to solve my own problems and eventually also to contribute back - but this is a general question.

There is this one MOOC exercise: http://rmod-pharo-mooc.lille.inria.fr/MOOC/Exercises/Exercises-Pillar/Pillar... that helps, and reading tests and comments helps if they exist. But I often get trapped in drilling down a long call stack and opening many, many browser windows, a new one for every message send to a new class.

While writing this it occured to me that I can use the debugger to follow a call stack by putting a breakpoint in the top level method, then stepping down using the debugger. There is also a MOOC lecture on that that I will look at again, http://rmod-pharo-mooc.lille.inria.fr/MOOC/Videos/W5/C019-W2S-VideosDebugger... .

Any tips? I think I don't see the forest for the trees here I'm afraid :)

thanks, Siemen

I found that at first I was very slow at reading/groking Smalltalk code, it was like being in a twisty maze with lots of paths leading to tiny little rooms that make little sense if you're only thinking about the room that you're in. I wondered if Smalltalk wasn't over complicating things with all it's tiny methods. But the more time I spent using the tools (browse senders/implementers / and debugger) to slowly go through the maze, the more it started to make sense. These days I feel like Smalltalk is the perfect system for allowing me to quickly understand what the code does. I think the more you read code the more you start to develop intuition about how things are usually put together, and often I see methods and patterns and think 'ahh, that probably does this', and i don't even need to check senders/implementers. I also noticed that now when i read new code I tend to look from a higher level first and make some guesses about what is doing what, then zoom in and get the details. On 5 January 2017 at 19:24, Siemen Baader <siemenbaader@gmail.com> wrote:

Hi All,

I may be missing the obvious, but what are good strategies to understand the structure of existing code? Specifically, I'm trying to understand more of PharoJS to solve my own problems and eventually also to contribute back - but this is a general question.

There is this one MOOC exercise: http://rmod-pharo-mooc.lille.inria.fr/MOOC/Exercises/Exercises-Pillar/Pillar... that helps, and reading tests and comments helps if they exist. But I often get trapped in drilling down a long call stack and opening many, many browser windows, a new one for every message send to a new class.

While writing this it occured to me that I can use the debugger to follow a call stack by putting a breakpoint in the top level method, then stepping down using the debugger. There is also a MOOC lecture on that that I will look at again, http://rmod-pharo-mooc.lille.inria.fr/MOOC/Videos/W5/C019-W2S-VideosDebugger....

Any tips? I think I don't see the forest for the trees here I'm afraid :)

thanks, Siemen

What you say here is very important, it is usability problem report. Often expert users and developers are trapped in their own world: want to add the super cool and elaborated features in the browser, but can't see that super cool and simple feature addition to the browser that will make life easier for new Pharo user ( = user acceptability = will the user stay with Pharo or will it move away after 1 hour of test and try?) A few weeks ago Denis posted about Calypso, and his browser comes with what you will need: code pane tabs. Damn! How can't think about it earlier. In the past I did complain about usability problem, mainly with undocumented feature in the interface (no tooltip). I don't care personally but I exactly know how a newbie will fell against a poorly helpful UI, especially when Pharo argument about its super cool IDE. Pharo developers should get serious about usability and discoverable features (include not only method comment but clearly written tooltips). Pharo 5 was released with really poorly documented UI code, although the tools set is all there (settings browser). Hilaire Le 05/01/2017 à 20:24, Siemen Baader a écrit :

that helps, and reading tests and comments helps if they exist. But I often get trapped in drilling down a long call stack and opening many, many browser windows, a new one for every message send to a new class.

-- Dr. Geo http://drgeo.eu