Support for conditional breakpoints #52

Open
cueman opened this Issue Jul 11, 2014 · 6 comments

Comments

Projects
None yet
4 participants
@cueman

cueman commented Jul 11, 2014

Currently, breakpoints that are conditional are always triggered as if there were no condition on them. It would be nice to support them. Even better would be if this could be done by writing Java, so you can have something of the form:

foo.getBar().equals("something")

If this is too hard for now, then perhaps it should be documented in the "Status" section of the project's home page that the conditions on conditional breakpoints are ignored (which is what I assume is happening).

@ivmarkov

This comment has been minimized.

Show comment
Hide comment
@ivmarkov

ivmarkov Jul 11, 2014

Contributor

Point taken - conditional breakpoints breaking "unconditionally" deserves mentioning on the status page.

As for supporting them in Java - this is very challenging and would probably require extensions to GWT itself, as we'll have to somehow be capable of compiling Java snippets on-the-fly to Javascript, in the context of the currently selected stack-frame of the suspended application.

Contributor

ivmarkov commented Jul 11, 2014

Point taken - conditional breakpoints breaking "unconditionally" deserves mentioning on the status page.

As for supporting them in Java - this is very challenging and would probably require extensions to GWT itself, as we'll have to somehow be capable of compiling Java snippets on-the-fly to Javascript, in the context of the currently selected stack-frame of the suspended application.

@g-mat

This comment has been minimized.

Show comment
Hide comment
@g-mat

g-mat Feb 13, 2015

Is it possible to add javascript conditional breakpoints - like in chrome? It would be nice to at least stop at something like:

foo_1_g$.bar_2_g$ == 'name'

g-mat commented Feb 13, 2015

Is it possible to add javascript conditional breakpoints - like in chrome? It would be nice to at least stop at something like:

foo_1_g$.bar_2_g$ == 'name'
@ivmarkov

This comment has been minimized.

Show comment
Hide comment
@ivmarkov

ivmarkov Feb 13, 2015

Contributor

The beauty of how SDBG is integrated with the Eclipse Java Development Tools is that SDBG is reusing the breakpoints (including the conditional ones) which are actually placed and owned by the standard Java (JDWP) debugger. So if you have shared code between the client and server, you don't have to think whether you need an SDBG breakpoint, or a Java breakpoint.

This means that the conditional breakpoints are Java, not JavaScript breakpoints. I may be able to cheat those and enter a JavaScript expression in the window where a Java expression is expected. However, the syntax highlighting and code completion will be for Java and for the Java functional context, not for JavaScript.

Contributor

ivmarkov commented Feb 13, 2015

The beauty of how SDBG is integrated with the Eclipse Java Development Tools is that SDBG is reusing the breakpoints (including the conditional ones) which are actually placed and owned by the standard Java (JDWP) debugger. So if you have shared code between the client and server, you don't have to think whether you need an SDBG breakpoint, or a Java breakpoint.

This means that the conditional breakpoints are Java, not JavaScript breakpoints. I may be able to cheat those and enter a JavaScript expression in the window where a Java expression is expected. However, the syntax highlighting and code completion will be for Java and for the Java functional context, not for JavaScript.

@g-mat

This comment has been minimized.

Show comment
Hide comment
@g-mat

g-mat Feb 13, 2015

I had in mind exactly the cheat you described. I think it is better to have some possibility of conditional breakpoints than have non. I work on a large GWT application and it is frustrating to jump from eclipse to chrome dev tools.

g-mat commented Feb 13, 2015

I had in mind exactly the cheat you described. I think it is better to have some possibility of conditional breakpoints than have non. I work on a large GWT application and it is frustrating to jump from eclipse to chrome dev tools.

@ivmarkov

This comment has been minimized.

Show comment
Hide comment
@ivmarkov

ivmarkov Feb 13, 2015

Contributor

Tell me about it. OK I'll see if I can make the cheat working...

Contributor

ivmarkov commented Feb 13, 2015

Tell me about it. OK I'll see if I can make the cheat working...

@skybrian

This comment has been minimized.

Show comment
Hide comment
@skybrian

skybrian Feb 15, 2015

You can also simulate a conditional breakpoint by adding some code temporarily:

if (..) {
GWT.debugger();
}

But it does require a recompile.

You can also simulate a conditional breakpoint by adding some code temporarily:

if (..) {
GWT.debugger();
}

But it does require a recompile.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment