January 2017 - Pharo-users - lists.pharo.org

Re: [Pharo-users] [Pharo-dev] Call of projects of open-dev lectures

by Nicolas Passerini

What do you think about Iceberg? 2017-01-04 15:48 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > Hi > > We are organising a lecture where students should > - learn pharo > - learn how to communicate with open source community > - learn how to reverse engineer, fix bugs.... > They should work by 3/4. > > We are looking for projects that would like to accept > - propose some bugs to be fixed > - to communicate with newbies and from time to time > > I was thinking about > - MDL > - Roassal > - Moose ? > - Pillar ? but nobody beside me and I do not have the time > - DRGeoII > - Telescope > - Artefact > - Scale > - Ecstatic > > So if you have a project and you want to participate. > We would like to have > - web page? > - mailing-list > - bug trackers/todo? > > Stef >

Jan. 6, 2017

Re: [Pharo-users] understanding existing code

by Siemen Baader

On Thu, Jan 5, 2017 at 9:33 PM, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > 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". > Yes, the mailing list is awesome!

Jan. 6, 2017

Re: [Pharo-users] understanding existing code

by Siemen Baader

On Thu, Jan 5, 2017 at 9:13 PM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > Another option: > > Use the Moose Image and explore code using Roassal. > http://www.moosetechnology.org/#install > > This is an interesting approach. Thanks! > 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(a)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-UsingTheDeb >> ugger-V2-HD_720p_4Mbs.m4v. >> >> Any tips? I think I don't see the forest for the trees here I'm afraid :) >> >> thanks, >> Siemen >> > >

Jan. 6, 2017

Re: [Pharo-users] Reverse interval

by John Pfersich

I can see uses for C, but C++ just turns my stomachs, and has since 1986, when I first experienced it ð . Sent from my iPhone > On Jan 5, 2017, at 00:46, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > plus I hate C/C++ with a vengeance , so :D

Jan. 6, 2017

Pharo and WebAssembly

by horrido

Hey, Rust can now target WebAssembly <https://blog.rust-lang.org/2016/12/22/Rust-1.14.html> . Pharo must do the same! -- View this message in context: http://forum.world.st/Pharo-and-WebAssembly-tp4928888.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Jan. 6, 2017

Re: [Pharo-users] understanding existing code

by Peter H. Meadows

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(a)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/Pilla… > 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-VideosDebugge…. > > Any tips? I think I don't see the forest for the trees here I'm afraid :) > > thanks, > Siemen

Jan. 5, 2017

Re: [Pharo-users] understanding existing code

by Dimitris Chloupis

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(a)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/Pilla… > 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-VideosDebugge… > . > > Any tips? I think I don't see the forest for the trees here I'm afraid :) > > thanks, > Siemen >

Jan. 5, 2017

Re: [Pharo-users] understanding existing code

by phil＠highoctane.be

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(a)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 >

Jan. 5, 2017

Re: [Pharo-users] understanding existing code

by phil＠highoctane.be

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 <siemenbaader(a)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 >

Jan. 5, 2017

understanding existing code

by Siemen Baader

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-VideosDebugge… . Any tips? I think I don't see the forest for the trees here I'm afraid :) thanks, Siemen

Jan. 5, 2017