- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Assigning to Block and Method arguments

by stepharo

This sounds like a good strategy this difference between interactive and loading time. On 7/10/14 18:25, Marcus Denker wrote: > Hi, > > In Pharo3 we had the bug that assigning to method arguments was allowed. > > *Block* arguments are traditionally assignable, but this is equally a bad idea (there was already a setting > to forbid it, but no idea how to make it a default without making a lot of code unlovable). > > First we made method arg assignment in Pharo4 an error, like it was in Pharo2, but > the problem with that is that there is code out there alreadyâ¦ so (thanks to Nicolai Hess), > now assignments to method arguments raise an error in interactive mode (when coding), but > load fine e.g. with Monticello. > > Yesterday I extended that scheme to block arguments: Now block argument assignments > are forbidden in interactive mode, while legacy code loads fine. > > (I removed the #allowBlockArgumentAssignment setting, too). > > This way we have a good transition and in some versions can make raising errors on assignments > to arguments the default even in non-interactive mode. > > Marcus >

Oct. 7, 2014

Program visualisation

by Thierry Goubier

Hi Florin, I've changed the header for our discussion :) Le 07/10/2014 05:29, Florin Mateoc a Ã©crit : > Hi Thierry, > > > Thanks for pointing it out. It is indeed interesting, but not what I > had in mind. I am not talking about debugging here so much. I am > quite good at that, and I find it natural to build tools that help me > do it (and of course, Smalltalk debuggers are very good already > (restarting a method/block pretty much gives you the benefits of > stepping backwards)), but debugging broken behavior is more about > mapping an internalized model of the execution with what's really > happening, seeing where they diverge. You are just checking that what > you think you know is true. Of course, when you find out it's not, > you gain insight/experience. But what to do when there is nothing to > check? What if, like in the situation you mentioned, the algorithm is > already working (so it's producing the correct/expected results)? But > you still want to make it better.... First, when dealing with complex algorithms, a restart a method/a block does not match what a full trace allows, first because you may have side-effects (which defeats the restarting thing), second because you don't have to set the next halt point when you go backward and restart, third because the debugger may lock your environment (think about halting one of the Rectangle methods, for example). However, you may loose some of the context in the trace. Second, your last statement is self-defeating: you want to make your algorithm better, which means you have the knowledge of what makes it tick and improve. I describe that process as moving in the design space of the algorithm, and that great tools are the ones which help you find the right direction in that design space. > What I want help with is what I am not as good at. I want to > literally "see" what's wrong (not good enough) with the picture, > since the brain has those very powerful visual pattern matching > capabilities. They remain unused when you are lost in the minutiae of > the debugger, where you only see text and numbers, the > granularity/level of abstraction is too low. Profilers are a little > better - they also succinctly capture the execution tree, and I have > also used traces for hard to debug sequences. The brain has some good abilities, but they are not what I'd call pattern matching (or at least you need to be very carefull with which visual variable you want to exploit: some are not suited at all to that type of visual analysis). I refer to SÃ©miologie Graphique, J. Bertin, for that. What I have considered in the work I did in the past on that is that visual systems have natural abstraction capabilities if we use / exploit them, and that they avoid the problems associated with building a formal abstraction process which may miss the point or the analysis we may extract from that. For example, a very high level view of a profile or a trace, as a tree with just a one pixel wide line per item (with identation according to depth + length related to some other execution property) may convey a lot about an execution. Another path that Alexandre Bergel makes wonder with is to use interaction to add and remove additional contextual data; you can't do comparative analysis visually with that, but, given a fast system, you may scan for a large amount of additional data without overloading the base display. I have used it to couple a code visualisation with a large C source file, with hovering over nodes jumping instantaneously to the right place in the source, and this is really effective for fast understanding of code structures (and loop / field of view focus effects). > Coming back to the WhyLine example, they already had something to > (visually) look at: objects colliding. Other times, the visual > representation is obvious/implied (say an algorithm for driving a car > on a given course - even if all you are given are coordinates, it is > common sense that you would draw the course on the screen and watch > the car as it makes progress when the algorithm ticks). In many > algorithms you don't have that. How do you find, in such cases, what > pictures/graphs/animations to look at? For an algorithm one obvious > candidate would be to the dynamic behavior of the main data > structures used (although, say you do this for the car example and > compare and contrast visualizing the data structures used by the > algorithm vs visualizing the car moving, or the objects colliding). > And you still have to find the right scale and level of abstraction. I guess here you have ideas: heat maps on data accesses, evolving over time; a representation of all objects in memory, with their color which evolves according to freshness (animated). Could be very interesting to compare that way two versions of the same algorithm, to see how they differ in time? Trace may be very valuable there, because it may be tuned to record the type of events you are interested in, and then be exploited to build a visualisation on top. With experience, what I value now a lot is code interaction: anything that very easily couple the visualisation with the relevant code (and not only the method, but the point in the code). I'm also dealing with safety properties of the code: safe, correct multithreaded code, either through run time analysis (see VectorFabrics tools :)) or through static analysis (Frama-C). Interesting subject and I am totally out of available work hours to implement stuff on that :) Thierry

Oct. 7, 2014

Re: [Pharo-dev] Someone remember a video ?

by Paul DeBruicker

Was it this BabyMock one: https://www.youtube.com/watch?v=ZDjEky4u16o SergeStinckwich wrote > I remember someone (Stef ?) send a link to a video demo in the > mailing-list about a framework in order to verify lively that an > object is initialized correctly. Everytime you send a message to a new > object, there was a report about uninitialized properties. Anyone > remember about this work ? > > Thank you. > -- > Serge Stinckwich > UCBN & UMI UMMISCO 209 (IRD/UPMC) > Help fight Ebola by joining the Computing for Ebola Challenge > http://bit.ly/1oEdBag -- View this message in context: http://forum.world.st/Someone-remember-a-video-tp4783181p4783222.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Oct. 7, 2014

Assigning to Block and Method arguments

by Marcus Denker

Hi, In Pharo3 we had the bug that assigning to method arguments was allowed. *Block* arguments are traditionally assignable, but this is equally a bad idea (there was already a setting to forbid it, but no idea how to make it a default without making a lot of code unlovable). First we made method arg assignment in Pharo4 an error, like it was in Pharo2, but the problem with that is that there is code out there alreadyâ¦ so (thanks to Nicolai Hess), now assignments to method arguments raise an error in interactive mode (when coding), but load fine e.g. with Monticello. Yesterday I extended that scheme to block arguments: Now block argument assignments are forbidden in interactive mode, while legacy code loads fine. (I removed the #allowBlockArgumentAssignment setting, too). This way we have a good transition and in some versions can make raising errors on assignments to arguments the default even in non-interactive mode. Marcus

Oct. 7, 2014

ShoreLine Reporter - A tool to collect stack traces

by Tommaso Dal Sasso

Hello everybody, for those of you who were not at ESUG, I present ShoreLine Reporter. ShoreLine Reporter is a Pharo plugin to collect stack traces from exceptions and send them to a central repository. You can give feedback to the community by breaking things: how cool is that? * Why? We are collecting stack traces for research purposes and to identify the Pharo components that can be improved or optimized. We are also working on a web platform where users can access the submitted data and use them during the debugging process. More on that soon! * How? You can install ShoreLine Reporter by visiting the project page on SmalltalkHub: http://www.smalltalkhub.com/#!/~dalsat/ShoreLine-Reporter/ Installing ShoreLine Reporter requires only a couple of seconds, and you can configure it with the level of feedback that you prefer. On the SmalltalkHub page you can find a script to automatically install ShoreLine Reporter with every new Pharo image. Just drop it in your Pharo preferences directory and forget about it. Once ShoreLine Report is installed, you can decide to configure if you want to be prompted to submit a stack trace, or to automatically submit each exception without any bother. * What? We try to collect as few data as possible: the execution stacktrace, the name of the author and the Pharo build. We do *not* any collect personal data, such as passwords or repositories. The data is currently stored on our server, at the University of Lugano. * Compatibility ShoreLine Reporter is developed for the Pharo debugger. We are improving ShoreLine Reporter to work with GTInspector, we will push an update in the following days. For any problem, contact me! Thanks, hope to see a lot of your exceptions ;-) Tommaso Dal Sasso @ REVEAL

Oct. 7, 2014

Re: [Pharo-dev] ANNC: QR Code (v.2)

by J.F. Rick

On Tue, Oct 7, 2014 at 8:52 AM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > ps: There is also a way to encode a QR with a image/logo inside, but I > don't know how that works. > As far as I can tell, that whole "embed an image / logo" is a stupid hack. QR codes have error correction. So, if you choose a high error correction, you can replace meaningful pixels with a logo and it will still function. But, it means that you have to choose high error correction, leading to a larger code, which is inherently harder to scan. My advice is to keep the QR code small and it doesn't have to take up that much real estate. Then, you can put your nice logo next to the QR code, taking up the same amount of space and looking better. A more promising angle is a translucent QR code, such as featured on the following: http://www.visualead.com/explore-qr-code-designs/ Cheers, Jeff -- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick

Oct. 7, 2014

Re: [Pharo-dev] Someone remember a video ?

by Henrik Johansen

On 07 Oct 2014, at 2:56 , Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: > I remember someone (Stef ?) send a link to a video demo in the > mailing-list about a framework in order to verify lively that an > object is initialized correctly. Everytime you send a message to a new > object, there was a report about uninitialized properties. Anyone > remember about this work ? > > Thank you. > -- > Serge Stinckwich > UCBN & UMI UMMISCO 209 (IRD/UPMC) > Help fight Ebola by joining the Computing for Ebola Challenge > http://bit.ly/1oEdBag > Reminds me of the patterns presented in the Patagonia presentation at ESUG2010. http://www.slideshare.net/esug/design-principlesbehindpatagonia Cheers, Henry

Oct. 7, 2014

Re: [Pharo-dev] [Moose-dev] [ANN] Test Coverage with Hapao

by Alexandre Bergel

Thanks Maximiliano for your kind words. Regarding your particular menu entry, I guess I understand well how you did it. No need to share it with me then. Let us know how to adapt Hapao. We will improve it. For example, the small window popup at the bottom of the window is not that useful. We will fix this... Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. On Oct 6, 2014, at 12:49 PM, Maximiliano Taborda <mtaborda(a)gmail.com> wrote: > Hi Alexandre. > > Perfect about the legends problem. Thanks. > > And about the best way to exclude some methods, I don't know what it is. I use the world menu to run Hapao. In fact, I made a new entry in the world menu that fit with my needs, that is: > - excludes all initialization methods, i.e. selectors named like #initialize* > - excludes all the #new methods > - excludes all methods that are defined in a protocol named as private, i.e. 'accessing - private' > This new entry checks the coverage over a class/es hierarchy and, also, > - run only the tests related to this hierarchy > - not take into account the abstract methods when computing the covered percentage; if I have an abstract method without a concrete one implemented in all the subclasses, I have a design error, so my real problem is the absence of the concrete method and not the absence of the test. > > If you are interested I leave you attached to this email the code related to this entry. Maybe is not the best way to implement what I need, but is a quickly one. > > Congratulations for this tool, is great to easily visualize what portion of my model are not covered by tests. > > Regards. > Maximiliano > > > > 2014-10-05 22:27 GMT-03:00 Alexandre Bergel <alexandre.bergel(a)me.com>: > Hi Maximiliano! > > The legend problem is now fixed. Can you double check please? > > What would be the best way to exclude some methods? This question slightly rephrased: how do you run Hapao? Programmatically or using the World menu? > > Cheers, > Alexandre > > > On Oct 2, 2014, at 11:34 PM, Maximiliano Taborda <mtaborda(a)gmail.com> wrote: > > > Hi Alexandre. > > > > Yes, now it works. Thank you. But, the box with the legends don't show very well. Like in the attached image: > > > > <RelativeDate.png> > > > > And, a question. Is there a way to exclude some methods from the analysis? I have some class methods, used for initialize some singletons for example, that I do not want to be considered for coverage. > > > > Regards. > > Maxi > > > > 2014-10-02 18:39 GMT-03:00 Alexandre Bergel <alexandre.bergel(a)me.com>: > > Hi! > > > > Sorry, we somehow slightly messed up with the configurations. > > I just took the last Pharo 4.0, and loaded Roassal2: > > > > -=-=-=-=-=-=-=-=-=-=-=-= > > Gofer new smalltalkhubUser: 'ObjectProfile' > > project: 'Roassal2'; > > package: 'ConfigurationOfRoassal2'; > > load. > > (Smalltalk at: #ConfigurationOfRoassal2) loadDevelopment > > -=-=-=-=-=-=-=-=-=-=-=-= > > > > Then I loaded S2py: > > -=-=-=-=-=-=-=-=-=-=-=-= > > Gofer new smalltalkhubUser: 'ObjectProfile' > > project: 'S2py'; > > package: 'S2py'; > > load. > > -=-=-=-=-=-=-=-=-=-=-=-= > > > > It works here. > > Can you confirm? > > > > Sorry for having taken long to answer... > > > > Cheers, > > Alexandre > > > > On Sep 24, 2014, at 8:24 PM, Maximiliano Taborda <mtaborda(a)gmail.com> wrote: > > > > > Hi Alexandre, > > > > > > I want to try Hapao2 to check the coverage level of Chalten, but it's not working (at least for me). > > > I load Roassal2 and S2py in a fresh 3.0 image like you say and the new entries appear in the world menu, but the only option that partially works is the one for a particular class (Hapao @ Class ...) and after run all the tests (I see the progress showing that) a MNU is raised in the method #addMethodEdges:scope:view: of Hapa2 class because RTEdgeBuilder is not loaded. > > > > > > So, could you tell me what I missed please? I need to load another thing, which?, at least the package which defines RTEdgeBuilder. > > > > > > Thanks for your help. > > > > > > Regards. > > > Maxi > > > > > > 2014-09-16 20:10 GMT-03:00 Alexandre Bergel <alexandre.bergel(a)me.com>: > > > Excellent! > > > > > > Alexandre > > > > > > Le 16-09-2014 Ã 16:15, Tudor Girba <tudor(a)tudorgirba.com> a Ã©crit : > > > > > >> Great! > > >> > > >> I will go over it more thoroughly in the following weeks and get back to you with feedback. > > >> > > >> Cheers, > > >> Doru > > >> > > >> > > >> > > >> On Tue, Sep 16, 2014 at 6:03 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > >> Dear all, > > >> > > >> We are happy to release Hapao2 for Pharo. Ricard Jacas and Alejandro Infante put quite some work on Spy2 (an Ã¼ber cool profiling framework for Pharo) and Hapao2. > > >> Hapao2 is about assessing the test coverage of your code and is a major revamp of Hapao1, which was presented a couple of years ago by Vanessa. > > >> Hapao2 does not only list covered and uncovered methods, as most test coverage tool on Earth will do. Hapao gives a great visualization to easily navigate in your code, assess its complexity, and give you a great visual output telling its coverage. > > >> > > >> You need Roassal in your image: > > >> > > >> Gofer new smalltalkhubUser: 'ObjectProfile' > > >> project: 'Roassal2'; > > >> package: 'ConfigurationOfRoassal2'; > > >> load. > > >> (Smalltalk at: #ConfigurationOfRoassal2) load > > >> > > >> > > >> and you need S2py: > > >> MCHttpRepository > > >> location: 'http://smalltalkhub.com/mc/ObjectProfile/S2py/main' > > >> user: '' > > >> password: '' > > >> > > >> > > >> New entries will appear in the world menu: > > >> <Screen Shot 2014-09-16 at 11.49.06 AM.png> > > >> > > >> You can run the test coverage on : > > >> - the class classes you have modified, > > >> - on a particular > > >> - on a particular class category > > >> - on the last class categories you have modified > > >> - on the last packages you have modified > > >> > > >> Here is a portion of a large coverage: > > >> > > >> <Screen Shot 2014-09-16 at 12.00.11 PM.png> > > >> > > >> A technical description of Hapao may be found on http://bergel.eu/download/papers/Berg12c-HapaoSCP.pdf > > >> > > >> We are daily using Hapao to help us understand our tests. > > >> > > >> Cheers, > > >> Ricardo, Alejandro & Alexandre > > >> -- > > >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > >> Alexandre Bergel http://www.bergel.eu > > >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > >> > > >> > > >> > > >> > > >> _______________________________________________ > > >> Moose-dev mailing list > > >> Moose-dev(a)iam.unibe.ch > > >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > >> > > >> > > >> > > >> > > >> -- > > >> www.tudorgirba.com > > >> > > >> "Every thing has its own flow" > > > > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > <S2py-MaximilianoTaborda.73.mcz>

Oct. 7, 2014

Re: [Pharo-dev] GT-Inspectors need live updating

by stepharo

On 6/10/14 23:14, Sven Van Caekenberghe wrote: > It seems that currently there is no automatic live updating for GT-Inspectors. > > That has to be fixed since we had that in both the old and in the eye inspectors. > > I remember Stef did something to do this with an extra process. I removed it and I made the window ticking to pass step to its contained objects :) > > Sven >

Oct. 7, 2014

Someone remember a video ?

by Serge Stinckwich

I remember someone (Stef ?) send a link to a video demo in the mailing-list about a framework in order to verify lively that an object is initialized correctly. Everytime you send a message to a new object, there was a report about uninitialized properties. Anyone remember about this work ? Thank you. -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Help fight Ebola by joining the Computing for Ebola Challenge http://bit.ly/1oEdBag

Oct. 7, 2014