Thanks for the kind (deleted) words :-) Yes the next step for watchpoints would be better management of the values that are recorded. Visualizations would be really great, I have been thinking about that (just in the abstract) and the sky is the limit. There is nothing yet because we have not had time to work on this. Also some standard logging infrastructure in Pharo would be nice, now it’s just an ordered collection but this should be changed to a better way to do logging.

On Nov 27, 2015, at 13:39, Dimitris Chloupis <kilon.alios@gmail.com> wrote:

Breakpoints are very convenient but I am in love with watchpoints !!!! You guys are amazing ! A million thank you :)

As I said to Marcus I imagine some very nice graph visualization of data evolution with roassal for this :)

---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile

Hi Johan, I just gave it a try and it's super awesome (mostly the watchpoints). No need to halt + inspect anymore :) Pharo 5.0 looks sooooo cool!! On Fri, Nov 27, 2015 at 5:03 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:

This is really great news.

Thanks a lot to all of you for working together on this and for working on it persistently for such long time (years).

I would like to add that people should realise that the technology behind it is really great and holds even more potential for the future. Furthermore, these relatively simple features combine several key foundational technologies (new compiler, AST, reflection, tools, spec, ...).

This (and all the other impressive things everybody else is doing) is what Pharo is all about.

Sven

...

On 27 Nov 2015, at 15:17, Johan Fabry <jfabry@dcc.uchile.cl> wrote:

Hi all,

Marcus, Miguel Campusano and me have been working the last few weeks on getting breakpoints and watchpoints working for Pharo 5. Since a few days we have functionality that works for many cases and that is easily accessible. It’s really cool, I urge you to try it out!

Breakpoints: In Nautilus in the methods list you can add a breakpoint to a method, as well as a breakpoint that triggers once, or a breakpoint that takes a condition. (The last is still a bit complicated. Marcus promised that he will clean that up :-).) Also in the code pane the suggestions menu allows you to add a breakpoint to expressions. They will be highlighted in red, and an icon appears in the gutter. Clicking it removes the breakpoint and also bringing up the suggestions menu allows you to remove them.

Watchpoints: Watchpoints are a simple mechanism to log the results of specific expressions. In the code pane the suggestions menu allows you to set a watchpoint. The expression is highlighted in red and in the gutter a green ball appears. Click it and you will have a simple UI that shows the last values recorded. (Actually the watchpoint records every execution and never throws anything away, so this can become a memory hog, be careful.) You can remove the watchpoint from the UI and from the suggestions menu.

In our experiments we found both very useful and powerful, try them out and be sure to tell us if there are any problems

---> Save our in-boxes! http://emailcharter.org <---

Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile

-- Mariano http://marianopeck.wordpress.com

Is there a way to query all breakpoints like a query of senders of #halt?

you can search for the senders of #break. But as class Breakpoint has a list of all active breakpoints, we add a browseAll method there easily.

Any reason for Whatchpoints doesn't work with expressions in the Playground?

The Playground does not yet support suggestions. This should be fixed.

Breakpoints seems to work fine (apart from some problem setting up from the menu method in Nautilus), If you find a repeatable case for that , can you add an issue on the tracker?

but a problem you could be aware is setting a break once in InputEventFetcher>>signalEvent: , and then moving the mouse, the image hangs.

Thanks, we will investigate. The “once” breakpoint triggers a recompile before opening the debugger. but of course the devil is in the details… we will check to see what exactly is happening here. Marcus

On 30 Nov 2015, at 11:23, Ben Coman <btc@openinworld.com> wrote:

When doing [Add break once] on RubTextEditor>>selectWord, then double-clicking on any word in the Nautilus code pane, the debugger that pops up shows all temporary variables are nil, which seems wrong. Can someone confirm this behaviour?

A break once added to a method means that it stops at the start of the method, before any temps are assigned. What seems to be wrong is the highlight… we need to put some more effort into making sure that highlighting is correct. Marcus

...

...

but a problem you could be aware is setting a break once in InputEventFetcher>>signalEvent: , and then moving the mouse, the image hangs.

Thanks, we will investigate. The “once” breakpoint triggers a recompile before opening the debugger. but of course the devil is in the details… we will check to see what exactly is happening here.

I think I understand what happens: the method is called because there is an interrupt. Check for interrupt happens on all message sends ==> even though we *want* to recompile before calling the method again, the check for interrupt happens and it is called again before the new method is installed.

Hmm.. I think it could be fixed by changing priorities of running threads: if we lover (temporarily) the input-event fetcher priority and raise the thread that does the compiling/installing, maybe we can make sure that the signalEvent: is not called before the break is removed… Marcus

thank you! it's really useful On Mon, Nov 30, 2015 at 10:08 PM, Ben Coman <btc@openinworld.com> wrote:

On Tue, Dec 1, 2015 at 4:32 AM, Marcus Denker <marcus.denker@inria.fr> wrote:

...

...

...

...

but a problem you could be aware is setting a break once in

InputEventFetcher>>signalEvent: , and then moving the mouse, the image hangs.

...

...

...

...

Thanks, we will investigate. The “once” breakpoint triggers a recompile before opening the debugger. but of course the devil is in the details… we will check to see what exactly is happening here.

I think I understand what happens: the method is called because there is an interrupt. Check for interrupt happens on all message sends ==> even though we *want* to recompile before calling the method again, the check for interrupt happens and it is called again before the new method is installed.

Hmm.. I think it could be fixed by changing priorities of running threads: if we lover (temporarily) the input-event fetcher priority and raise the thread that does the compiling/installing, maybe we can make sure that the signalEvent: is not called before the break is removed…

I speculate that changing the priority of input-event fetcher would have more impact than just raising the installing thread above it, but then I guess the DelayScheduler timing-priority event loop will be susceptible to the same problem. Maybe the final part of the install needs to be done with a primitive like #become: ? cheers -ben

-- Bernardo E.C. Sent from a cheap desktop computer in South America.

But as class Breakpoint has a list of all active breakpoints, we add a browseAll method there easily.

Thanks, that would be a useful addition to easily locate breakpoints.

This has been integrated in the mean time: have a look at Breakpoint class>>browseAll

Finally I found how to reproduce it, if you open a Nautilus browser, set a breakpoint in a method, then left-click another method focus is lost and code pane seems to double-refresh to finally display the class definition.

But this happens also if you right-click a method to display menu, do nothing, then click another method. So it's a Nautilus problem. If nobody reported it before I will open a case tomorrow.

I concur that it is a Nautilus problem. So I guess you should add a bug report. Here are steps to reproduce both cases you mention: 1 have a method selected 2 bring up context menu on that method 3 don’t select anything OR add a breakpoint OR File out OR (I stopped trying out options at this point) 4 click on other method Note that you did not include step 1 but it is required. ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile