Hi Erwin,
> Nice to hear that some of the submission was useful. I've been seeing a
> lot of XSLTC bug reports on the list; hopefully they weren't caused by
> those changes.
Not at all. We are starting to use the Xalan test suite with XSLTC now,
and a lot of bugs have surfaced. We're in the phase of implementing
JAXP/TrAX support now, so we have decided to let the bugs rest for the
time being and focus on the JAXP work. It still remains to be seen how
many of these bugs are real and how many that are duplicates.
> I see the Dublin conference has been cancelled. That's a shame, I had
> hoped to see some faces 'behind' the names.
Tell me about it!
> > o) I've already made some changes to our handling of <xsl:if>
> > and <xsl:when> to check if they wrap unsupported external
> > functions. I still added your fix to FunctionCall and the
> > BasisLibrary classes, with the minor modification of emitting
> > warning messages when calls to unsupported functions are
> > compiled into the translet.
>
> That's nice. I've only seen such use of extension functions in Norman
> Walsh'es stylesheets, but they are important enough to take into account,
> IMHO.
Absolutely. It is good "programming practice".
> > o) Some of the illegal method names had already been changed
> > and now contain underscores instead of dollar-signs.
>
> Okay. Have you thought about real escaping? I think that according to the
> spec, you can have different named templates (or variable names, etc) that
> only differ by a hyphen, dot or underscore character (i.e. "tmpl_1",
> "tmpl.1" and "tmpl-1") and that is not possible in XSLTC if you use
> The dollar sign is nice since the Java language spec advices that it is
> only used for automatically generated names, and it is not valid in an
> XSL variable or template name.
>
> You could use the sequence $d for a dot and $h for a hyphen.
> single-character escaping.
Hmmm. I'll have to look into that. I am not even sure what the compilers
behaviour would be in this case. I think the compiler would complain and
see the named templates as having the same name, and thereafter terminating
the transformation.
> > o) I've made some minor changes to the way you compiled
> > IFNE skip
> > GOTO_W far_away
> > instead of
> > IFEQ far_away
> >
> > but most of your changes are exactly as they were in the diffs.
> > Some of these changes are very impressive, especially in the
> > Mode class, where the code can be very hard to understand.
>
> Thanks.
> It is still problematic, though. If the method is quite small, the
> extra space used by IFNE/GOTO_W instead of IFEQ is significant, and in
> large methods I didn't fix all cases.
>
> I believe that an extra level of abstraction is be needed that allows the
> bytecode to be split up in several methods after it has been generated.
> That would involve significant changes in the way the BCEL library is
> used.
Yes, I've been thinking about this myself. It would be brilliant if the
BCEL library had a way of telling us when the compiled code contains
branch offsets that are too long. I should send Markus Dahm a few lines...
Morten
