Add 'breakpoint' similar to 'debugger' from JavaScript.

Add 'breakpoint' similar to 'debugger' from JavaScript.

[ahe, 2014-03-19 12:59:44]

This adds the equivalent of "self halt" to dart:core.

[floitsch, 2014-03-19 13:22:03]

Would it make more sense to add this to the isolate interface?
For example:
Isolate.self.waitForDebugger()

[ahe, 2014-03-19 13:38:57]

On 2014/03/19 13:22:03, floitsch wrote:
> Would it make more sense to add this to the isolate interface?
> For example:
> Isolate.self.waitForDebugger()

I'd prefer it to be easy to use.

[ahe, 2014-03-19 13:40:32]

On 2014/03/19 13:38:57, ahe wrote:
> On 2014/03/19 13:22:03, floitsch wrote:
> > Would it make more sense to add this to the isolate interface?
> > For example:
> > Isolate.self.waitForDebugger()
> 
> I'd prefer it to be easy to use.

And by easy to use, I mean "not having to import something and then typing a
long sequence of characters that I don't think are related to my goal (setting a
breakpoint)" :-)

[Lasse Reichstein Nielsen, 2014-03-20 08:25:39]

https://codereview.chromium.org/204483002/diff/1/dart/sdk/lib/core/breakpoint...
File dart/sdk/lib/core/breakpoint.dart (right):

https://codereview.chromium.org/204483002/diff/1/dart/sdk/lib/core/breakpoint...
dart/sdk/lib/core/breakpoint.dart:7: /// Pause execution during debugging, a
breakpoint.
What does it means to be "during debugging". I'm always debugging my code, but I
usually do it by inserting print statements.

How about more text to elaborate it:

Returns `null` when resuming after the pause.

If an external debugger is attached to the program, reading this getter will
trigger that debugger and allow it to interrupt the program at this point.
If no debugger is present, reading `breakpoint` does nothing, it just returns
`null` normally.

https://codereview.chromium.org/204483002/diff/1/dart/sdk/lib/core/breakpoint...
dart/sdk/lib/core/breakpoint.dart:9: external void get breakpoint;
This is regrettably a breaking change (no pun intended).

The lower-case name can conflict with instance variables in user classes, and
due to Dart's scoping rules, this declaration will override unqualified
references to that variable in subclasses.

https://codereview.chromium.org/204483002/diff/1/dart/sdk/lib/core/breakpoint...
dart/sdk/lib/core/breakpoint.dart:9: external void get breakpoint;
"external void get" is not allowed by the spec. The return type of top-level
external getters must match "type?", which does not include "void".
(I think it is a mistake that top-level non-external getters do allow void -
class getter members don't either).

[floitsch, 2014-03-20 11:05:46]

Other small thought: if we made break() a function we could allow an optional
argument and break in the middle of expressions:

foo(break(bar());  // break when bar has been computed, but foo hasn't been
executed yet.

[ahe, 2014-03-20 11:59:15]

On 2014/03/20 11:05:46, floitsch wrote:
> Other small thought: if we made break() a function we could allow an optional
> argument and break in the middle of expressions:
> 
> foo(break(bar());  // break when bar has been computed, but foo hasn't been
> executed yet.

Making it a function for use in expressions is an awesome idea, IMO.

Using the keyword "break" makes me feel uneasy.

[gbracha, 2014-03-20 15:51:46]

On 2014/03/20 11:59:15, ahe wrote:
> On 2014/03/20 11:05:46, floitsch wrote:
> > Other small thought: if we made break() a function we could allow an
optional
> > argument and break in the middle of expressions:
> > 
> > foo(break(bar());  // break when bar has been computed, but foo hasn't been
> > executed yet.
> 
> Making it a function for use in expressions is an awesome idea, IMO.
> 
> Using the keyword "break" makes me feel uneasy.

Of course it should be a function (otherwise it really isn't equivalent to 'self
halt').

[kevmoo, 2014-03-20 16:34:46]

DBC

https://codereview.chromium.org/204483002/diff/1/dart/sdk/lib/core/breakpoint...
File dart/sdk/lib/core/breakpoint.dart (right):

https://codereview.chromium.org/204483002/diff/1/dart/sdk/lib/core/breakpoint...
dart/sdk/lib/core/breakpoint.dart:9: external void get breakpoint;
DBC: Can we make this a method?

break() or setBreakPoint()

This has a side effect. Let's not copy Javascript unless it makes sense.

[ahe, 2014-03-20 16:46:07]

On 2014/03/20 15:51:46, gbracha wrote:
> On 2014/03/20 11:59:15, ahe wrote:
> > On 2014/03/20 11:05:46, floitsch wrote:
> > > Other small thought: if we made break() a function we could allow an
> optional
> > > argument and break in the middle of expressions:
> > > 
> > > foo(break(bar());  // break when bar has been computed, but foo hasn't
been
> > > executed yet.
> > 
> > Making it a function for use in expressions is an awesome idea, IMO.
> > 
> > Using the keyword "break" makes me feel uneasy.
> 
> Of course it should be a function (otherwise it really isn't equivalent to
'self
> halt').

I guess you're arguing that "self halt" can also be used in expressions.

But "halt" is an instance method in Smalltalk. I wouldn't want to do that in
Dart. I don't think it is an intrinsic property of all objects that they can
interact with the debugger.

[ahe, 2014-03-20 16:50:47]

https://codereview.chromium.org/204483002/diff/1/dart/sdk/lib/core/breakpoint...
File dart/sdk/lib/core/breakpoint.dart (right):

https://codereview.chromium.org/204483002/diff/1/dart/sdk/lib/core/breakpoint...
dart/sdk/lib/core/breakpoint.dart:9: external void get breakpoint;
On 2014/03/20 16:34:46, kevmoo wrote:
> DBC: Can we make this a method?
> 
> break() or setBreakPoint()

Breakpoint is one word according to DevTools, and the spell checker in Chrome.

I don't think setBreakpoint would be a good fit. This *is* a break point. A
method named "setBreakpoint" would be found in a  debugger and its arguments
would be a location.

> This has a side effect. Let's not copy Javascript unless it makes sense.

It doesn't really have a side-effect in terms of normal language semantics. But
Florian provided a really good argument for having it take one argument. So I'm
all for making it a method.

[Lasse Reichstein Nielsen, 2014-03-20 16:59:12]

I like the function-with-argument idea.
For maximum flexibility, it should be an optional argument:
   breakpoint([Object object]);
(and it should return the argument value, as Florian suggested).

[ahe, 2014-03-20 17:01:37]

On 2014/03/20 16:59:12, Lasse Reichstein Nielsen wrote:
> I like the function-with-argument idea.
> For maximum flexibility, it should be an optional argument:
>    breakpoint([Object object]);
> (and it should return the argument value, as Florian suggested).

Yes. But without the redundant type annotation ;-)

[floitsch, 2014-03-20 17:06:30]

We could also put the focus on inspecting the returned value:
bar(debug(foo()))
bar(inspect(foo())
...

If the dev-tools then show the value we would shift from "set a breakpoint", to
"inspect a value".
Maybe that gives us better naming options. Frequently I want to look at a
specific variable when breaking anyways. So this would make this just easier,
and if I don't care I would just see a "null" somewhere.

[kevmoo, 2014-03-20 17:33:01]

On 2014/03/20 17:06:30, floitsch wrote:
> We could also put the focus on inspecting the returned value:
> bar(debug(foo()))
> bar(inspect(foo())
> ...
> 
> If the dev-tools then show the value we would shift from "set a breakpoint",
to
> "inspect a value".
> Maybe that gives us better naming options. Frequently I want to look at a
> specific variable when breaking anyways. So this would make this just easier,
> and if I don't care I would just see a "null" somewhere.

debug([Object value = const _Something()]) works.

If value is not specified, nothing is echoed.

[hausner, 2014-03-31 23:52:14]

FWIW, also check dartbug.com/10536

[ahe, 2014-04-01 08:55:56]

On 2014/03/31 23:52:14, hausner wrote:
> FWIW, also check dartbug.com/10536

Thank you, I wasn't aware of that bug.