gobo-eiffel-develop — Development discussions

Re: [gobo-eiffel-develop] No -O2 flag in gcc.cfg

[Eric B. <er...@go...>]

Colin Adams wrote:
> I see that in gcc.cfg, the -O2 flag is commented out.
> What's the reason for this?

I don't remember. I guess it was back when I tried it in
SourceForge's compile farm. You can try uncommenting it
and see what happens.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

[gobo-eiffel-develop] Raising the visibility level

[Colin P. A. <co...@co...>]

For some reason, while I was monitoring another strange bug a few
minutes ago, the thought occured to me to try and get Gestalt into the
Linux distributions - it would be a way to raise the visibility of
Eiffel (showing more people that it is actually used for real).

I only know the Fedora packaging at all well (and that not very well),
but I would guess that all the Linux distributions would insist on
compilable packaging being available, not just binaries.

In Fedora then, a gestalt.rpm would depend upon an eposix.rpm which
would in turn depend upon a gobo.rpm (no need to depend upon
eiffelstudio now that gec is usable for real to some extent) and the
boehm garbage collector (I don't if this is distributed in any
distributions currently).

If we were to do this, then I think aiming for for a gobo package
based on 3.8 would be a sensible target, with eposix to come as soon
after that as Berend felt ready.

What do people (especially Eric and Berend) think?
-- 
Colin Adams
Preston Lancashire

[gobo-eiffel-develop] No -O2 flag in gcc.cfg

[Colin A. <col...@go...>]

I see that in gcc.cfg, the -O2 flag is commented out.
What's the reason for this?

Re: [gobo-eiffel-develop] Unhandled exception from gec-compiled tests

[Colin A. <col...@go...>]

OK - mystery solved.

The function concerned is:

XM_XPATH_ATOMIC_SORT_COMPARER.raise_non_comparable_exception

This is the sole exception in the XPath library, and it does not leak
out of any API.
But it's a problem when compiled with gec at the moment.

I couldn't find a design to report the error except by using an
internal exception.

On 26/12/2007, Colin Adams <col...@go...> wrote:
> On 26/12/2007, Colin Adams <col...@go...> wrote:
> > On 26/12/2007, Eric Bezault <er...@go...> wrote:
> >
> > > > How much effort is involved to implement that?
> > >
> > > The thing is that if `eeocode' and `stack_trace_string' are called,
> > > it's because an exception has been raised in the first place. So
> > > it might be interesting to know why an exception has been raise,
> > > and when. So I suggest again that you put breakpoints in the generated
> > > C code at the beginning of 'GE_raise', and also on function 'eeocode'.
> >
> > I tried that.
> > In this case gdb does not break, but says "Program exited normally.".
>
> I forgot that I had commented out the test case from the catalog.
> When I restored it, I now get a break at GE_raise. Here is the stack trace:
>
> (gdb) backtrace
> #0  0x09b02216 in GE_raise ()
> #1  0x09b023af in eraise ()
> #2  0x084b07b9 in T24f12 ()
> #3  0x084b078b in T24f11 ()
> #4  0x093de773 in T1809f12 ()
> #5  0x093de701 in T1809f5 ()
> #6  0x082af3e2 in T1820x31356T0T0 ()
> #7  0x08965ec5 in T2167f35 ()
> #8  0x08964ece in T2262f5 ()
> #9  0x089647be in T2262f4 ()
> #10 0x0896470d in T2262f3 ()
> #11 0x0896773c in T2167f41 ()
> #12 0x08967582 in T2167f38 ()
> #13 0x0895878b in T2167f37 ()
> #14 0x082eee23 in T422x20234 ()
> #15 0x0847934e in T2020f301 ()
> #16 0x08b45262 in T2020f302 ()
> #17 0x082d5ddb in T405x18742T0 ()
> #18 0x084a3e9e in T1978f316 ()
> #19 0x0831b4cb in T2128x21386T0T0 ()
> #20 0x0845cc6d in T393f13 ()
> #21 0x0922cfb6 in T317f84 ()
> ---Type <return> to continue, or q <return> to quit---
> #22 0x093769a8 in T317f77 ()
> #23 0x093757d6 in T276f81 ()
> #24 0x0937529f in T276f69 ()
> #25 0x0936c75b in T27f163 ()
> #26 0x082b10f9 in T42x2331T0T0T0 ()
> #27 0x0936c47c in T56f33p1 ()
> #28 0x0936be80 in T56f33 ()
> #29 0x082b1125 in T42x2331T0T0T0 ()
> #30 0x0936bd75 in T57f12p1 ()
> #31 0x0936bd0c in T57f12 ()
> #32 0x082b1151 in T42x2331T0T0T0 ()
> #33 0x0838dcfa in T62f250 ()
> #34 0x0832f285 in T62f229 ()
> #35 0x08321358 in T62f220 ()
> #36 0x08320be4 in T62f216 ()
> #37 0x0831d52d in T62f213 ()
> #38 0x0831d46c in T62f207 ()
> #39 0x0831c8ec in T27f152 ()
> #40 0x0831c469 in T21c13 ()
> #41 0x09b021d2 in main ()
>

Re: [gobo-eiffel-develop] Unhandled exception from gec-compiled tests

[Colin A. <col...@go...>]

On 26/12/2007, Colin Adams <col...@go...> wrote:
> On 26/12/2007, Eric Bezault <er...@go...> wrote:
>
> > > How much effort is involved to implement that?
> >
> > The thing is that if `eeocode' and `stack_trace_string' are called,
> > it's because an exception has been raised in the first place. So
> > it might be interesting to know why an exception has been raise,
> > and when. So I suggest again that you put breakpoints in the generated
> > C code at the beginning of 'GE_raise', and also on function 'eeocode'.
>
> I tried that.
> In this case gdb does not break, but says "Program exited normally.".

I forgot that I had commented out the test case from the catalog.
When I restored it, I now get a break at GE_raise. Here is the stack trace:

(gdb) backtrace
#0  0x09b02216 in GE_raise ()
#1  0x09b023af in eraise ()
#2  0x084b07b9 in T24f12 ()
#3  0x084b078b in T24f11 ()
#4  0x093de773 in T1809f12 ()
#5  0x093de701 in T1809f5 ()
#6  0x082af3e2 in T1820x31356T0T0 ()
#7  0x08965ec5 in T2167f35 ()
#8  0x08964ece in T2262f5 ()
#9  0x089647be in T2262f4 ()
#10 0x0896470d in T2262f3 ()
#11 0x0896773c in T2167f41 ()
#12 0x08967582 in T2167f38 ()
#13 0x0895878b in T2167f37 ()
#14 0x082eee23 in T422x20234 ()
#15 0x0847934e in T2020f301 ()
#16 0x08b45262 in T2020f302 ()
#17 0x082d5ddb in T405x18742T0 ()
#18 0x084a3e9e in T1978f316 ()
#19 0x0831b4cb in T2128x21386T0T0 ()
#20 0x0845cc6d in T393f13 ()
#21 0x0922cfb6 in T317f84 ()
---Type <return> to continue, or q <return> to quit---
#22 0x093769a8 in T317f77 ()
#23 0x093757d6 in T276f81 ()
#24 0x0937529f in T276f69 ()
#25 0x0936c75b in T27f163 ()
#26 0x082b10f9 in T42x2331T0T0T0 ()
#27 0x0936c47c in T56f33p1 ()
#28 0x0936be80 in T56f33 ()
#29 0x082b1125 in T42x2331T0T0T0 ()
#30 0x0936bd75 in T57f12p1 ()
#31 0x0936bd0c in T57f12 ()
#32 0x082b1151 in T42x2331T0T0T0 ()
#33 0x0838dcfa in T62f250 ()
#34 0x0832f285 in T62f229 ()
#35 0x08321358 in T62f220 ()
#36 0x08320be4 in T62f216 ()
#37 0x0831d52d in T62f213 ()
#38 0x0831d46c in T62f207 ()
#39 0x0831c8ec in T27f152 ()
#40 0x0831c469 in T21c13 ()
#41 0x09b021d2 in main ()

Re: [gobo-eiffel-develop] Unhandled exception from gec-compiled tests

[Colin A. <col...@go...>]

On 26/12/2007, Eric Bezault <er...@go...> wrote:
> Colin Adams wrote:
> > On 26/12/2007, Colin Adams <col...@go...> wrote:
> >
> >> In test-case errorcode1030: Finishing early, having processed test case
> >> 'eeocode' in 'eif_except.h' not implemented
> >> 'stack_trace_string' in 'eif_except.h' not implemented
> >> Call on Void target!
> >> Unhandled exception
> >
> > This problem also occurs on Windows.
>
> Can you tell me how to reproduce it?

Compile gexslt with boehm.

Then the following command line reproduces it:

gexslt --template=main errorcode1030.xsl

where errorcode1030.xsl look like this:

<?xml version="1.0"?>

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="2.0"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:my="http://my.com/">

<?error XTDE1030?>


  <xsl:template name="main">
    <out>
      <xsl:for-each select="1 to 5, 'fred'">
        <xsl:sort select="."/>
        <xsl:value-of select="."/>
      </xsl:for-each>
    </out>
  </xsl:template>




</xsl:stylesheet>

Re: [gobo-eiffel-develop] Unhandled exception from gec-compiled tests

[Eric B. <er...@go...>]

Colin Adams wrote:
> On 26/12/2007, Colin Adams <col...@go...> wrote:
> 
>> In test-case errorcode1030: Finishing early, having processed test case
>> 'eeocode' in 'eif_except.h' not implemented
>> 'stack_trace_string' in 'eif_except.h' not implemented
>> Call on Void target!
>> Unhandled exception
> 
> This problem also occurs on Windows.

Can you tell me how to reproduce it?

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] Unhandled exception from gec-compiled tests

[Eric B. <er...@go...>]

Colin Adams wrote:
> In this case gdb does not break, but says "Program exited normally.".
> However I do not get the correct output.
> Maybe I can try stepping through the code to see what is happening.
> Does gec provide an eiffel-to-c function name mapping?

No, mapping has to be done manually by looking at the generated .h file.

Note that the "trace" option works, but the program runs much slower
and in my experience the output is harder to make sense of than the
C execution trace. This is because "trace" does not provide an
execution trace, but prints to the output a message each time the
execution enters or exits a routine. I started to implement an
Eiffel execution trace mechanism, but I stopped when I realized that
for what I was doing it was faster to use the C execution trace
and then translate the function names manually than to implement
the Eiffel execution trace mechanism.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] Unhandled exception from gec-compiled tests

[Colin A. <col...@go...>]

On 26/12/2007, Colin Adams <col...@go...> wrote:

> In test-case errorcode1030: Finishing early, having processed test case
> 'eeocode' in 'eif_except.h' not implemented
> 'stack_trace_string' in 'eif_except.h' not implemented
> Call on Void target!
> Unhandled exception

This problem also occurs on Windows.

Re: [gobo-eiffel-develop] Unhandled exception from gec-compiled tests

[Colin A. <col...@go...>]

On 26/12/2007, Eric Bezault <er...@go...> wrote:

> > How much effort is involved to implement that?
>
> The thing is that if `eeocode' and `stack_trace_string' are called,
> it's because an exception has been raised in the first place. So
> it might be interesting to know why an exception has been raise,
> and when. So I suggest again that you put breakpoints in the generated
> C code at the beginning of 'GE_raise', and also on function 'eeocode'.

I tried that.
In this case gdb does not break, but says "Program exited normally.".
However I do not get the correct output.
Maybe I can try stepping through the code to see what is happening.
Does gec provide an eiffel-to-c function name mapping?

> It might be that eposix is relying too much on exceptions to program
> expectable error cases! ;-)

That may be the case, but this test case is not using any of the
network stuff, so eposix code is not actually being exercised by the
test case.

> The effort to implement it is not worth it. We are in the process to
> move to exceptions implemented as objects.

OK. That makes sense.

Re: [gobo-eiffel-develop] Unhandled exception from gec-compiled tests

[Eric B. <er...@go...>]

Colin Adams wrote:
> It doesn't fix the problems where I get:
> 
> In test-case errorcode1030: Finishing early, having processed test case
> 'eeocode' in 'eif_except.h' not implemented
> 'stack_trace_string' in 'eif_except.h' not implemented
> Call on Void target!
> Unhandled exception
> 
> How much effort is involved to implement that?

The thing is that if `eeocode' and `stack_trace_string' are called,
it's because an exception has been raised in the first place. So
it might be interesting to know why an exception has been raise,
and when. So I suggest again that you put breakpoints in the generated
C code at the beginning of 'GE_raise', and also on function 'eeocode'.

It might be that eposix is relying too much on exceptions to program
expectable error cases! ;-)

The effort to implement it is not worth it. We are in the process to
move to exceptions implemented as objects.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] Unhandled exception from gec-compiled tests

[Colin A. <col...@go...>]

On 25/12/2007, Eric Bezault <er...@go...> wrote:
> Colin Paul Adams wrote:
> > Maybe, maybe not. I may try the original problem (by removing the
> > parallel collecting option) to see if that catches it.
> > Then we might as well report a bug in boehm.
>
> I found (and fixed) a bug in `deep_twin':
>
>     * Fixed bug (read/write to non-allocated memory) in implementation of
>       `deep_twin' when traversing objects of type SPECIAL.
>
> Do you know if `deep_twin' is used in your program? It might explain
> the weird behavior that you get if the memory gets corrupted in such
> a way.
>
> I also improved things when declaring user-defined expanded types,
> in particular when creating SPECIAL objects of expanded). Feature
> `default_create' is still not called on initialization, and `copy'
> is still not called on reattachment. If neither of these are redefined
> in your user-defined expanded types, then it should now be safe to
> use them.

It doesn't fix the problems where I get:

In test-case errorcode1030: Finishing early, having processed test case
'eeocode' in 'eif_except.h' not implemented
'stack_trace_string' in 'eif_except.h' not implemented
Call on Void target!
Unhandled exception

How much effort is involved to implement that?

Nor does it affect the original problem (revealed by turning off
parallel marking in boehm gc).

Re: [gobo-eiffel-develop] Unhandled exception from gec-compiled tests

[Colin A. <col...@go...>]

On 25/12/2007, Eric Bezault <er...@go...> wrote:
> I found (and fixed) a bug in `deep_twin':
>
>     * Fixed bug (read/write to non-allocated memory) in implementation of
>       `deep_twin' when traversing objects of type SPECIAL.
>
> Do you know if `deep_twin' is used in your program? It might explain
> the weird behavior that you get if the memory gets corrupted in such
> a way.

I don't know. I don't use them in my own classes. I tried checking
with Eiffel Studio, and it reports no callers other than deep_clone,
and deep_copy, and in turn reports no callers for those.

But experience tells me that it doesn't always report all calls. But I
checked that there are no other implementations except those in ANY.

> I also improved things when declaring user-defined expanded types,
> in particular when creating SPECIAL objects of expanded). Feature
> `default_create' is still not called on initialization, and `copy'
> is still not called on reattachment. If neither of these are redefined
> in your user-defined expanded types, then it should now be safe to
> use them.

Well Berend can say whether or not they are used within eposix. I
don't have any user-defined expanded classes in my own code that I
remember (I don't think I have ever created an expanded class).

Anyway, I will update my repository tomorrow, and see if it makes any
difference.

Re: [gobo-eiffel-develop] Unhandled exception from gec-compiled tests

[Eric B. <er...@go...>]

Colin Paul Adams wrote:
> Maybe, maybe not. I may try the original problem (by removing the
> parallel collecting option) to see if that catches it.
> Then we might as well report a bug in boehm.

I found (and fixed) a bug in `deep_twin':

    * Fixed bug (read/write to non-allocated memory) in implementation of
      `deep_twin' when traversing objects of type SPECIAL.

Do you know if `deep_twin' is used in your program? It might explain
the weird behavior that you get if the memory gets corrupted in such
a way.

I also improved things when declaring user-defined expanded types,
in particular when creating SPECIAL objects of expanded). Feature
`default_create' is still not called on initialization, and `copy'
is still not called on reattachment. If neither of these are redefined
in your user-defined expanded types, then it should now be safe to
use them.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] Unhandled exception from gec-compiled tests

[Eric B. <er...@go...>]

Colin Paul Adams wrote:
>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
> 
>     Eric> Colin Paul Adams wrote:
>     >> Anyway, reviewing my outstanding bugs on sourceforge, I
>     >> wondered if 1847164 was now fixed.  Not exactly. I get:
>     >> 
>     >> 'eeocode' in 'eif_except.h' not implemented
>     >> 'stack_trace_string' in 'eif_except.h' not implemented Call on
>     >> Void target!  Unhandled exception

> 
> But what is 'eeocode'?

See EXCEPTIONS.original_exception

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] Unhandled exception from gec-compiled tests

[Colin P. A. <co...@co...>]

>>>>> "Eric" == Eric Bezault <er...@go...> writes:

    Eric> Colin Paul Adams wrote:
    >> Anyway, reviewing my outstanding bugs on sourceforge, I
    >> wondered if 1847164 was now fixed.  Not exactly. I get:
    >> 
    >> 'eeocode' in 'eif_except.h' not implemented
    >> 'stack_trace_string' in 'eif_except.h' not implemented Call on
    >> Void target!  Unhandled exception
    >> 
    >> I assume this is not "no more memory", but I'm going to
    >> recompile anyway, to see what happens.

    Eric> If "no more memory", the message "No more memory" would be
    Eric> printed.

I'm not getting that for any of the problems. I'm not too concerned
about the original problem, as parallel marking seems to bypass it
(although I think it will be worth reporting it to Hans Boehm - I'll
get roud to that some time).

But what is 'eeocode'?
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Unhandled exception from gec-compiled tests

[Eric B. <er...@go...>]

Berend de Boer wrote:
>>>>>> "Colin" == Colin Paul Adams <co...@co...> writes:
> 
>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
> 
>     Eric> * use of user-defined expanded classes * call to external
>     Eric> routines returning an object whose type is not a basic
>     Eric> expanded type or STRING.
> 
>     Colin> I guess eposix might be returning either of those.
> 
> eposix uses the former, not the later.

OK, so I will try to implement user-defined expanded types
before taking care of DbC ;-)

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] Unhandled exception from gec-compiled tests

[Eric B. <er...@go...>]

Colin Paul Adams wrote:
> Anyway, reviewing my outstanding bugs on sourceforge, I wondered if
> 1847164 was now fixed.
> Not exactly. I get:
> 
> 'eeocode' in 'eif_except.h' not implemented
> 'stack_trace_string' in 'eif_except.h' not implemented
> Call on Void target!
> Unhandled exception
> 
> I assume this is not "no more memory", but I'm going to recompile
> anyway, to see what happens.

If "no more memory", the message "No more memory" would be printed.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] Unhandled exception from gec-compiled tests

[Berend de B. <be...@po...>]

>>>>> "Colin" =3D=3D Colin Paul Adams <co...@co...> writes:

>>>>> "Eric" =3D=3D Eric Bezault <er...@go...> writes:

    Eric> * use of user-defined expanded classes * call to external
    Eric> routines returning an object whose type is not a basic
    Eric> expanded type or STRING.

    Colin> I guess eposix might be returning either of those.

eposix uses the former, not the later.

=2D-=20
Cheers,

Berend de Boer

Re: [gobo-eiffel-develop] Unhandled exception from gec-compiled tests

[Colin P. A. <co...@co...>]

>>>>> "Eric" == Eric Bezault <er...@go...> writes:

    Eric> Colin Paul Adams wrote:
    >>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
    Eric> with the GC, it thinks that there is no more memory and
    Eric> 'GC_malloc' returns a null pointer (i.e. Void
    Eric> object). Currently gec does not raise yet a "no more memory"
    Eric> exception in this case.  So a creation instruction would
    Eric> silently return a Void reference.
    >> 
    >> How soon could you change gec to raise "no more memory"? I
    >> would think its definietly worth trying to confirm that this is
    >> what is happening.

    Eric> It's probably too late for you, but it's now implemented in
    Eric> gec.

Maybe, maybe not. I may try the original problem (by removing the
parallel collecting option) to see if that catches it.
Then we might as well report a bug in boehm.

Anyway, reviewing my outstanding bugs on sourceforge, I wondered if
1847164 was now fixed.
Not exactly. I get:

'eeocode' in 'eif_except.h' not implemented
'stack_trace_string' in 'eif_except.h' not implemented
Call on Void target!
Unhandled exception

I assume this is not "no more memory", but I'm going to recompile
anyway, to see what happens.
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Unhandled exception from gec-compiled tests

[Eric B. <er...@go...>]

Colin Paul Adams wrote:
>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
>     Eric> with the GC, it thinks that there is no more memory and
>     Eric> 'GC_malloc' returns a null pointer (i.e. Void
>     Eric> object). Currently gec does not raise yet a "no more memory"
>     Eric> exception in this case.  So a creation instruction would
>     Eric> silently return a Void reference.
> 
> How soon could you change gec to raise "no more memory"? I would think
> its definietly worth trying to confirm that this is what is happening.

It's probably too late for you, but it's now implemented in gec.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] Unhandled exception from gec-compiled tests

[Colin P. A. <co...@co...>]

>>>>> "Colin" == Colin Paul Adams <co...@co...> writes:

    Colin> OK. I corrected my error, and now everything is fine with
    Colin> the following configuration options:

    Colin> ./configure --enable-large-config --enable-gc-debug
    Colin> --enable-gc-assertions --enable-parallel-mark
    Colin> --prefix=/usr/local

    Colin> (I added --enable-parallel-mark for extra performance).

    Colin> I'll not try to find out which options are actually
    Colin> necessary.

In fact, just supplying --enable-parallel-mark is sufficient to
eliminate the problem.
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Unhandled exception from gec-compiled tests

[Colin P. A. <co...@co...>]

>>>>> "Colin" == Colin Paul Adams <co...@co...> writes:

    Colin> So it looks like todays new problem is genuinely distinct
    Colin> from the original problem, and I should be able to debug
    Colin> that myself just using Eiffel debugging.

OK. I corrected my error, and now everything is fine with the
following configuration options:

./configure --enable-large-config --enable-gc-debug --enable-gc-assertions --enable-parallel-mark --prefix=/usr/local

(I added --enable-parallel-mark for extra performance).

I'll not try to find out which options are actually necessary.
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Unhandled exception from gec-compiled tests

[Eric B. <er...@go...>]

Colin Paul Adams wrote:
> I'll run the gobo test cases, and if they all pass, I'll check in my changes.

Before doing that, what about getting a fresh copy from SVN
and try your test case to see if it crashes or not?

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] Unhandled exception from gec-compiled tests

[Colin P. A. <co...@co...>]

>>>>> "Eric" == Eric Bezault <er...@go...> writes:

    Eric> Colin Paul Adams wrote:
    >>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
    >> 
    Eric> What I didn't get yet is an execution trace of the problem
    Eric> where "unhandled exception" is printed. For that, I would
    Eric> need the trace at the point when GE_raise is first
    Eric> called. Last time you tried it, it was something like that:

Sorry about that.

Anyway, the XPath test suite just failed, and the test names that
aborted were:

ABORT:  [XM_XPATH_TEST_IDREFS.test_idrefs_against_tiny_tree] Eiffel exception
ABORT:  [XM_XPATH_TEST_IDREFS.test_idrefs_against_standard_tree]
Eiffel exception

So it looks like todays new problem is genuinely distinct from the
original problem, and I should be able to debug that myself just using
Eiffel debugging.
-- 
Colin Adams
Preston Lancashire