Eclipse XSLT debugger breakpoints don't break

[jokester01au]

Hi,

Another bug in the eclipse XSLT debugger.

Breakpoints on certain elements fail to break. For example, if a new stylesheet is created, with a template

<xsl:template match="/">
<xsl:variable name="la">
56
</xsl:variable>
</xsl:template>

Then a breakpoint on the template start tag will work correctly, but a breakpoint on the variable start tag will run without breaking.

Regards,
Joe.

[sorin_ristache]

Hello,

I cannot reproduce the problem. Please specify the name and version of your platform, the version of your Java virtual machine and the Eclipse build ID. If it is not oXygen 8.0 please specify also the build ID of the oXygen plugin.


Regards,
Sorin

[jokester01au]

This problem also occurs in the standalone version (8.0).

The complete file I am testing is below. If I set a breakpoint on any of the variable tags, the debugger doesn't break. Only if I set a breakpoint on value-of or template does the debugger break.

I am running Windows Vista and JDK 1.6.0RC.

Regards
Joe.

<xsl:stylesheet xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:math="http://exslt.org/math"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="2.0">
<xsl:template match="/">
<xsl:variable name="baseBitCount">
32
</xsl:variable>
<xsl:variable name="meBitCount">
<xsl:apply-templates select="xsd:maxExclusive"/>
</xsl:variable>
<xsl:variable name="thisBitCount" select="if ($meBitCount='') then 9999 else $meBitCount"/>

<xsl:variable name="bitCount" select="min(($baseBitCount,xsd:integer($thisBitCount)))"/>
<xsl:value-of select="$bitCount"/>
</xsl:template>
<xsl:template match="xsd:bin">
fxgh
</xsl:template>
</xsl:stylesheet>

[sorin_ristache]

Hello,

It is the same problem of lazy evaluation of variables. The XSLT processor does not send notifications about variable declarations. It removes those XSLT instructions from the runtime model of the stylesheet.


Regards,
Sorin

[jokester01au]

I notice that this is still the behaviour in oxygen 9.

When debugging java with eclipse, if you try to place a breakpoint somewhere where it will not work, eclipse automatically moves the breakpoint to the next line where it will successfully break.

I think that this behaviour is far more user-friendly than having oxygen accept your breakpoint but never honour it. I think that oxygen should adopt eclipse's model with regard to this behaviour.

On a related point, java breakpoints and expressions are persistent, whereas XWatch, Breakpoint and Breakcondition all lose any data they have on exit. Again, I think that the eclipse/jdt way is much more user friendly and should be adopted by oxygen.

Regards,
Joe.

[sorin_ristache]

I think that this behaviour is far more user-friendly than having oxygen accept your breakpoint but never honour it. I think that oxygen should adopt eclipse's model with regard to this behaviour.

No,starting with oXygen 9.0 the oXygen plugin does not allow setting a breakpoint on a line where the breakpoint cannot be honored. If you try to place a breakpoint on an empty line or on a line with only an end tag then the oXygen plugin displays the error "Breakpoints can only be created on a line containing the end of a start tag". The same error is displayed in the oXygen standalone application for an invalid line for a breakpoint. What is your oXygen plugin build number displayed in Window -> Preferences -> oXygen?

java breakpoints and expressions are persistent, whereas XWatch, Breakpoint and Breakcondition all lose any data they have on exit.

The variables displayed in Variables view and the values of the conditions set in Break Conditions view are computed in the context of the transformation. If the transformation is not running there is no context of a transformation so there is no variable or condition that makes sense in these views.

What do you mean by the content of the Breakpoints view is changed or lost when the transformation is exited? The Breakpoints view does not contain context dependent data so the content is not changed when the transformation is exited. Can you give an example when the content of this view is changed on exit without an editing action on the view executed manually by the user?


Regards,
Sorin

[jokester01au]

If you try to place a breakpoint on an empty line or on a line with only an end tag then the oXygen plugin displays the error "Breakpoints can only be created on a line containing the end of a start tag".

Sorry, I guess I wasn't clear. Take this template

<xsl:template match="sls:SLS">
<xsl:variable name="blah" select="foo"/>
<xsl:apply-templates/>
</xsl:template>

Oxygen 9 will happily install a breakpoint on the xsl:variable. However, when running the stylesheet with saxon 8, lazy execution of variables means that the variable line is never the active instruction, so the execution goes straight past the breakpoint without stopping.

I think that you should avoid letting a breakpoint be set here in the first place, since it won't work properly. However, I realise that there are complexities with this because it will vary depending on the processor that is currently selected. Maybe just "grey out" (show as inactive) breakpoints that aren't going to work given the active processor.

What do you mean by the content of the Breakpoints view is changed or lost when the transformation is exited?

Sorry, I definitely wasn't clear here. I did not mean "exit the transformation", I meant "exit the xslt debugger perspective" and/or "exit eclipse". Also I was incorrect about breakpoints not being persistent, it looks like they are.

So, what I had actually noticed was that if I switch out of the xslt debugger and back again, my XWatch expressions have disappeared and I have to enter them again. The same is true for my break conditions when I exit eclipse.

I think that oxygen should maintain both of these things persistently, just like the java debugger does (sorry, you can tell where I spend a lot of my time .

As an aside, the java debugger integrates the break conditions with breakpoints, so that you can have either an unconditional breakpoint, or a conditional one. I think that this makes more sense becuase nearly everything you could write in the condition (eg variables, relative node-tests) are meaningless everywhere other than the template in which they're defined or used.

Regards,
Joe.

[sorin_ristache]

I think that you should avoid letting a breakpoint be set here in the first place, since it won't work properly. However, I realise that there are complexities with this because it will vary depending on the processor that is currently selected. Maybe just "grey out" (show as inactive) breakpoints that aren't going to work given the active processor.

Yes, it depends on the processor and the processor does the lazy evaluation internally. It does not notify a caller application about lazy variables.

So, what I had actually noticed was that if I switch out of the xslt debugger and back again, my XWatch expressions have disappeared and I have to enter them again. The same is true for my break conditions when I exit eclipse.

I think that oxygen should maintain both of these things persistently, just like the java debugger does

We will consider making the views that do not depend on the current context of the transformation persistent in a future version. Thank you for pointing it out.

As an aside, the java debugger integrates the break conditions with breakpoints, so that you can have either an unconditional breakpoint, or a conditional one. I think that this makes more sense becuase nearly everything you could write in the condition (eg variables, relative node-tests) are meaningless everywhere other than the template in which they're defined or used.

We will consider this suggestion too for a future version.


Thank you,
Sorin

[sorin_ristache]

Hello,

So, what I had actually noticed was that if I switch out of the xslt debugger and back again, my XWatch expressions have disappeared and I have to enter them again. The same is true for my break conditions when I exit eclipse.

I think that oxygen should maintain both of these things persistently, just like the java debugger does

We will consider making the views that do not depend on the current context of the transformation persistent in a future version. Thank you for pointing it out.

As an aside, the java debugger integrates the break conditions with breakpoints, so that you can have either an unconditional breakpoint, or a conditional one. I think that this makes more sense becuase nearly everything you could write in the condition (eg variables, relative node-tests) are meaningless everywhere other than the template in which they're defined or used.

We will consider this suggestion too for a future version.

We implemented both suggestions for the next version of Oxygen, that is version 12.0. The content of the views will be persistent and the Breakpoints and Break Conditions views will be merged.


Regards,
Sorin