>>>>> "Eric" == Eric Bezault <ericb@...> writes:
Eric> Also, are you sure that the hash_code of your keys does not
Eric> change between the time you insert objects in the hash table
Eric> and the time you call `has'?
>> I've checked trough this - the answer is Yes.
Eric> I'm afraid the answer in No.
Sorry about that. I must have inserted by print statement at the wrong
place when debugging.
Thanks for all your work on this.
Eric> The other difference is that a documentation cannot belong
Eric> only to one XM_XPATH_NAME_POOL.
That's not a problem.
In fact, at the moment, there is only one, shared, name pool (I intend to
insert invariants and pre-conditions all over the place soon, to
confirn this, with a view to making all references direct to the
shared name pool, rather than passing the name pool as a parameter
I only envisage using of multiple name pools for pre-compiled
stylesheets. When a compiled stylesheet is loaded into memory, then
the name pool that was used when it was compiled needs to be loaded
into memeory too, and set to be the shared name pool.
But I think pre-compiled stylesheets (stored in the file system, or a
database, or somewhere), although a useful performance feature , is a
rather distant prospect, as we do not have a STORABLE facility in
Changing the subject a little, I have nearly finished the code
necessary to transform books.xml with books.xsl to yield html.
These files are in $GOBO/test/xml/xpath/data, and are slightly
modified versions of samples that come with Saxon 8.0.
Books.xsl is an XSLT 2.0 stylesheet, and makes use of
xsl:for-each-group - a really wonderful feature which makes
Muenchian grouping using keys - which was necessary in XSLT 1.0,
but very awkward, completly uncessary. I have already got this
The situation so far:
I am able to perform the transform to xml (rather than html), although
a few things are not quite implemented yet (mostly number formatting).
I am writing the HTML and XHTML serializers today, and I would hope that I can
achieve identical result to saxon 8.0 within 2 weeks.
then I shall switch to tackling the gobo2html.xsl. I would hope to be
able to sucessfully transform all existing documentation by the end of
I shall do this by implementing just those features that are necessary
for these particular transformations.
Not that this approach does not guarantee that any new documentation
will necessarily transform sucessfully, but I think it will be useful
if the next version of gobo can compile all of it's documentation at
install time (the only question mark is VE because of the problem with
invariants and MA_DECIMAL, but that should be circumventable simply be
building a version of gexslt without invariant checking - I've not
tried this test yet).
Do you have a projected release date for the next version of Gobo?
Colin Paul Adams