understanding existing code
Locked
 
|
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- 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 |
|
|
You can take an expression and "debug it" using over and through + run to here, inspecting things all over. You can also use Halt>>if: #selector Halt if: is really useful: if: condition <debuggerCompleteToSender> "This is the typical message to use for inserting breakpoints during debugging. The argument can be one of the following: - a block: if the Block has one arg, the calling object is bound to that. - an expression - a selector: Halt if found in the call chain" condition isSymbol ifTrue: [ ^ self haltIfCallChainContains: condition ]. condition isBlock ifTrue: [ ^ self haltIfBlockWithCallingObject: condition]. condition ifTrue: [self signal]. That helped me :-) Phil On Thu, Jan 5, 2017 at 8:24 PM, Siemen Baader <[hidden email]> wrote:
|
|
|
In reply to this post by Siemen Baader
Another option: Use the Moose Image and explore code using Roassal. Check Also RTUMLClassBuilder can be useful. Phil On Thu, Jan 5, 2017 at 8:24 PM, Siemen Baader <[hidden email]> wrote:
|
|
In reply to this post by Siemen Baader
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 <[hidden email]> wrote:
|
Re: understanding existing code
|
|
In reply to this post by Siemen Baader
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 <[hidden email]> 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-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 |
Re: understanding existing code
|
|
In reply to this post by philippeback
On Thu, Jan 5, 2017 at 9:13 PM, [hidden email] <[hidden email]> wrote:
|
Re: understanding existing code
|
|
In reply to this post by kilon.alios
On Thu, Jan 5, 2017 at 9:33 PM, Dimitris Chloupis <[hidden email]> wrote:
Yes, the mailing list is awesome! |
Re: understanding existing code
|
|
In reply to this post by Siemen Baader
A break once + debugger is a lifesaver if what you really want is a sequence diagrams of a specific operation; for general structure, the browser is usually a better place to start. In a well-structured package, the different tags will usually also give a good indication about the class collaboration structure (or, sometimes, lack thereof), or at least the areas that are worth investigating. Some structural pattern uses are quite easy to spot using the class hierarchy view (at least when not restricted to current package...), such as visitors and polymorphic delegation. Searching base class references /senders of the polymorphic methods in such cases, will usually progressively take you to classes operating at higher abstraction levels; where the class comment are more likely to describe significant pieces of functionality. (Some anti-patterns can also be spotted browsing the methods in a polymorphic base class, such as large methods on a super that has overriddes, usually implying copy-pasta-edit, rather than a habit of extracting the bits that actually differ) Class collaboration is an area that can be a nuisance to get a good picture of with the standard tools; senders/implementors will usually do the trick when interested in a single area (in a manner similar to the debugger), for a more complete picture, loading Roassal and scripting your own visualizations, or going full throttle and using Moose (which includes a useful set of premade ones, probably/hopefully including scoped collaboration) may be worth the effort. Cheers, Henry |
Re: understanding existing code
|
|
> On 6 Jan 2017, at 14:39, Henrik Johansen <[hidden email]> wrote: > > >> On 5 Jan 2017, at 20:24 , Siemen Baader <[hidden email]> 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-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 > > A break once + debugger is a lifesaver if what you really want is a sequence diagrams of a specific operation; for general structure, the browser is usually a better place to start. > > In a well-structured package, the different tags will usually also give a good indication about the class collaboration structure (or, sometimes, lack thereof), or at least the areas that are worth investigating. > > Some structural pattern uses are quite easy to spot using the class hierarchy view (at least when not restricted to current package...), such as visitors and polymorphic delegation. > Searching base class references /senders of the polymorphic methods in such cases, will usually progressively take you to classes operating at higher abstraction levels; where the class comment are more likely to describe significant pieces of functionality. > (Some anti-patterns can also be spotted browsing the methods in a polymorphic base class, such as large methods on a super that has overriddes, usually implying copy-pasta-edit, rather than a habit of extracting the bits that actually differ) > > Class collaboration is an area that can be a nuisance to get a good picture of with the standard tools; senders/implementors will usually do the trick when interested in a single area (in a manner similar to the debugger), for a more complete picture, loading Roassal and scripting your own visualizations, or going full throttle and using Moose (which includes a useful set of premade ones, probably/hopefully including scoped collaboration) may be worth the effort. > > Cheers, > Henry I would also say that trying to figure out the structure/design is more important than going into the details using the debugger. A well designed package should have some logic to it. Even if there are no comments, well chosen names should guide you. Not just class names, but package, protocol names and selector names should normally help you, a lot. It is also often a requirement that you have a basic understanding of the subject - it is really hard if not impossible to understand how the (quite nice) XML packages are implemented if you don't understand XML, tags, attributes, namespaces, encoding, parsing, DOM, SAX, etc. Wikipedia is a great resource and starting point. When you get stuck, ask for pointers on the ML. Sven |
|
|
In reply to this post by Siemen Baader
On Fri, Jan 6, 2017 at 3:24 AM, Siemen Baader <[hidden email]> 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-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 :) This one I just thought of, so YMMV. Try... World menu > Tools > Time Profiler Evaluate code for some point of interest (you may need to wrap it in a loop) then browse the static call tree to * view the common execution paths as an overview of code structure * provide a reading order for class comments * suggest places to insert breakpoints to watch what live is happening. In some cases you might need... World menu > System > Start profiling all processes Another way I often to learn what happens behind Pharo tools if opening halos on a button-of-interest (make sure you click cycling through to the PluggableButtonMorph) then "Inspect Morph" and determine the method called when the button is pressed and drop a halt in that method. This might not be applicable to PharoJS. cheers -ben |
Re: understanding existing code
|
In reply to this post by Siemen Baader
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 |
|
|
|
Re: understanding existing code
|
|
Once you are an expert the mind map is in your mind, but it does not
mean the mind map is useless for newbie. So every thing helping the newbie to build their own mind map is important to catch them and more importantly to make them stay with Pharo Le 06/01/2017 à 21:39, Dimitris Chloupis a écrit : > > A thing I want to try is is creating mind maps tool inside Pharo, a > variant of the pen and paper technique I was using when I was studying Law. -- Dr. Geo http://drgeo.eu |
|
|
Well, what can help is the ability to create a gist and retrieve/search/list them. This would be nice to be able to push things from Playground or emails of the list or Slack into gists right from Pharo. I have a couple that I look at from time to time: It is boring to go to github and do it by hand, so, a feature along those lines can be helpful for all of us. Phil On Fri, Jan 6, 2017 at 9:55 PM, Hilaire <[hidden email]> wrote: Once you are an expert the mind map is in your mind, but it does not |
|
|
In reply to this post by HilaireFernandes
mind maps can extend into infinite complexity and detail, so yes the mind map will become a memory the more you use it but you still can create thousands of mind maps like I did with little chance of remembering all. I will say that for experts mind maps are far more important because a newbie even though he or she may benefit from it, the beginner concept are simple enough to be found among tutorials and documentation.I used mind maps on my master degree where we dealt with very special complex cases that went far beyond the fundamentals of law. To be exact Commercial and E-Commercial Law. My dissertation was quite a challenge, was dealing with the legal protections offered against malicious attacks and malicious software. Mind maps helped me identify important key points that was very hard to understand just by reading text and trying to memories and make sense of it. I even passed some exams using nothing more than mind maps created by other students in a fraction of time it would have taken by just reading the books. On Fri, Jan 6, 2017 at 10:56 PM Hilaire <[hidden email]> wrote: Once you are an expert the mind map is in your mind, but it does not |
Re: understanding existing code
|
|
Thanks for all these tips and reflections. There are a number of things for me to try now.
@Hilaire: I'll try try Calypso. There are indeed several things one could experiment with in making the important connections more visible in the development tools. I have also been thinking of a more OSX/GT like browser design that just opens new panels to the right and opens inheritance view, code view, class side methods in that way too... it would be more compact and uniform and easier to put relevant pieces side-by-side. @Ben: Clever to use the profiler to see what the code does most of, I didn't think of it. Also thanks for your tips on the general workflow of understanding the code, everyone. I'm glad you have provided so much input and discussion, I was following it eagerly. thanks, Siemen |
Re: understanding existing code
|
|
In reply to this post by HilaireFernandes
We think about it since long time ago. This is why we rewrote and produce Nautilus (but the design was not good) - remember in nautilus we could edit mutliple methods but it was not good and why that because we needed also panes and ..... I agree with you about tooltip and ghost for input. You see in the debugger having a nicer message for DNU is a big improvement and it was super simple. Stef On Fri, Jan 6, 2017 at 9:27 PM, Hilaire <[hidden email]> wrote: What you say here is very important, it is usability problem report. |
Re: understanding existing code
|
|
In reply to this post by Siemen Baader
2017-01-07 11:42 GMT+01:00 Siemen Baader <[hidden email]>:
And please, report any ideas on UI, missing features, bugs here. It is very initial version now |
Re: understanding existing code
|
|
In reply to this post by Stephane Ducasse-3
Le 08/01/2017 à 10:44, Stephane Ducasse a écrit : > We think about it since long time ago. This is why we rewrote and > produce Nautilus (but the design was not good) - remember in nautilus we > could edit mutliple methods but it was not good and why that because we > needed also panes and ..... > Yet, the pane feature of Calypso will not help when browsing for implementors. One thing that seem simple to me is an option for the message browser ([X] Open new window), when uncheck it will just use the existing message browser window and avoid duplication window. I try to give a look at the MessageBrowser code, but I understand nothing of it. > > I agree with you about tooltip and ghost for input. > You see in the debugger having a nicer message for DNU is a big > improvement and it was super simple. > > Stef -- Dr. Geo http://drgeo.eu |
Re: understanding existing code
|
|
2017-01-08 11:28 GMT+01:00 Hilaire <[hidden email]>:
It will always help :). For example I want to add matcher/rewrite tool as tab which will work on selected scope. So in system browser it will allow search/rewrite in selected package, selected class, selected group. And same tool will be very useful in message browser too: ability to search/rewrite over results of method query (senders/implementors). I have in mind a couple of other extensions for both browser types. And I hope people will contribute in this direction when I document how extend Calypso |
«
Return to Pharo Smalltalk Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |