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

Re: [Pharo-dev] FOSDEM > Looks like there is a Smalltalk room :)

by Stephan Eggermont

Yes, I'll put the CFP out soon. Stephan

Oct. 7, 2014

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

by Esteban A. Maringolo

If I evaluate: (CodeImporter evaluateFileNamed: 'foo.st') In a headless pharo image, does it count as interactive? Regards! Esteban A. Maringolo 2014-10-07 16:31 GMT-03:00 Tudor Girba <tudor(a)tudorgirba.com>: > Indeed, I like this approach. Nicely done. > > Doru > > On Tue, Oct 7, 2014 at 9:11 PM, stepharo <stepharo(a)free.fr> wrote: >> >> 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 >>> >> >> > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

Oct. 7, 2014

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

by Tudor Girba

Indeed, I like this approach. Nicely done. Doru On Tue, Oct 7, 2014 at 9:11 PM, stepharo <stepharo(a)free.fr> wrote: > 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 >> >> > > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 7, 2014

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