Re: Strange behavior involving (p:)resolve-uri, variables, attributes, calabash, oxygen, saxon, ...

I've attached the full log from oXygen. This is the essence of it:

21996 DEBUG [ Thread-7 ]
ro.sync.xml.transformer.xproc.calabash.XProcTransformerImpl -
java.lang.IllegalStateException: *** Internal Saxon error: local variable
encountered whose binding has been deleted
java.lang.IllegalStateException: *** Internal Saxon error: local variable
encountered whose binding has been deleted
    at
net.sf.saxon.expr.ExpressionTool.allocateSlots(ExpressionTool.java:541)
    at
net.sf.saxon.expr.ExpressionTool.allocateSlots(ExpressionTool.java:547)
    at
net.sf.saxon.expr.ExpressionTool.allocateSlots(ExpressionTool.java:547)
    at
net.sf.saxon.expr.ExpressionTool.allocateSlots(ExpressionTool.java:547)
    at
net.sf.saxon.expr.ExpressionTool.allocateSlots(ExpressionTool.java:547)
    at
net.sf.saxon.expr.ExpressionTool.allocateSlots(ExpressionTool.java:547)
    at
net.sf.saxon.expr.ExpressionTool.allocateSlots(ExpressionTool.java:547)
    at
net.sf.saxon.expr.ExpressionTool.allocateSlots(ExpressionTool.java:547)
    at
net.sf.saxon.sxpath.XPathEvaluator.createExpression(XPathEvaluator.java:126)
    at
net.sf.saxon.s9api.XPathCompiler.internalCompile(XPathCompiler.java:416)
    at net.sf.saxon.s9api.XPathCompiler.compile(XPathCompiler.java:397)
    at
com.xmlcalabash.runtime.XAtomicStep.evaluateXPath(XAtomicStep.java:754)
    at
com.xmlcalabash.runtime.XAtomicStep.computeValue(XAtomicStep.java:643)
    at com.xmlcalabash.runtime.XPipeline.doRun(XPipeline.java:231)
    at com.xmlcalabash.runtime.XPipeline.run(XPipeline.java:136)
    at
ro.sync.xml.transformer.xproc.calabash.XProcTransformerImpl.transform(Unknown
Source)
    at ro.sync.xml.transformer.xproc.c$2.run(Unknown Source)
    at java.lang.Thread.run(Unknown Source)
21998 DEBUG [ Thread-7 ] ro.sync.xml.transformer.xproc.c -
ro.sync.exml.editor.xmleditor.ErrorListException
ro.sync.exml.editor.xmleditor.ErrorListException
    at
ro.sync.xml.transformer.xproc.calabash.XProcTransformerImpl.transform(Unknown
Source)
    at ro.sync.xml.transformer.xproc.c$2.run(Unknown Source)
    at java.lang.Thread.run(Unknown Source)
21998 DEBUG [ Transformation Performer ] ro.sync.exml.editor.xmleditor.cc -
javax.xml.transform.TransformerException: Cannot transform
file:/home/jostein/Skrivebord/debug.xpl because:
javax.xml.transform.TransformerException: Cannot transform
file:/home/jostein/Skrivebord/debug.xpl because:
    at ro.sync.xml.transformer.xproc.c.transform(Unknown Source)
    at ro.sync.exml.editor.xproc.transform.m.b(Unknown Source)
    at ro.sync.exml.editor.xmleditor.cc.nd(Unknown Source)
    at ro.sync.exml.editor.xmleditor.cc$4.vzi(Unknown Source)
    at ro.sync.ui.application.y.run(Unknown Source)
Caused by: ro.sync.exml.editor.xmleditor.ErrorListException
    at
ro.sync.xml.transformer.xproc.calabash.XProcTransformerImpl.transform(Unknown
Source)
    at ro.sync.xml.transformer.xproc.c$2.run(Unknown Source)
    at java.lang.Thread.run(Unknown Source)
---------
ro.sync.exml.editor.xmleditor.ErrorListException
    at
ro.sync.xml.transformer.xproc.calabash.XProcTransformerImpl.transform(Unknown
Source)
    at ro.sync.xml.transformer.xproc.c$2.run(Unknown Source)
    at java.lang.Thread.run(Unknown Source)


Regards
Jostein

2011/12/8 Norman Walsh <ndw@nwalsh.com>

> Jostein Austvik Jacobsen <josteinaj@gmail.com> writes:
> > I'm getting the error "Internal Saxon error: local variable
> > encountered whose binding has been deleted" in my pipeline, and have
> > reduced the problem into this pipeline (which I run using oXygen):
>
> Can you get a stack trace? I'm not sure how to do that when running
> From oXygen, it would be "-D" on the command line.
>
> > Is this a bug or am I missing something? If it's a bug, can anyone
> reproduce it with Calabash,
> > or is it an oXygen bug?
>
> It appears to be an oXygen bug, but it could be my error. I'm baffled
> by the differences that work and don't work. If you think it's my bug,
> George, let me know and I'll see what I can do.
>
> With respect to p:resolve-uri or fn:resolve-uri, you really only need
> to use p:resolve-uri if you are trying to maintain compatibility with
> other implementations based on XPath 1.0. In any XPath 2.0-based
> implementation, fn:resolve-uri should work.
>
>                                        Be seeing you,
>                                          norm
>
> --
> Norman Walsh
> Lead Engineer
> MarkLogic Corporation
> Phone: +1 413 624 6676
> www.marklogic.com
>