gobo-eiffel-develop — Development discussions

Re: [gobo-eiffel-develop] Gestalt now crashes when compiled with gec only

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

Colin Paul Adams wrote:
>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
> 
>     Eric> Please try to use the two files attached.
> 
> Same problem as before.

Now, if you remove the line 21:

   ((void (*)(EIF_REFERENCE))disp)((EIF_REFERENCE)C);

in the file ge_gc.c that I sent you?

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

Re: [gobo-eiffel-develop] Gestalt now crashes when compiled with gec only

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

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

    Eric> Please try to use the two files attached.

Same problem as before.
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Gestalt now crashes when compiled with gec only

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

Colin Paul Adams wrote:
> Are these two alternative versions of ge_gc.h to try, or are they two
> different files?

There is ge_gc.h and ge_gc.c. They should be tried together.

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

Re: [gobo-eiffel-develop] Gestalt now crashes when compiled with gec only

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

Are these two alternative versions of ge_gc.h to try, or are they two
different files?
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Gestalt now crashes when compiled with gec only

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

Colin Paul Adams wrote:
>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
> 
>     Eric> So it's either a problem in the way I use Boehm's finalizer
>     Eric> registration (in particular I pass a function pointer where
>     Eric> a void* is expected!), or a problem in Boehm's finalization,
>     Eric> or a problem in the implementation of `dispose'. I would
>     Eric> favor the first alternative considering that what you say
>     Eric> below.
> 
>     >> But note that I do not have the problem on my 32-bit system (I
>     >> tried both before and after an svn update), so it might be a
>     >> problem with Boehm gc 7.0 on 64-bit systems. I will try a newer
>     >> version.
> 
> That doesn't work (I used the 24th February version of 7.1 alpha).

Please try to use the two files attached.

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

Re: [gobo-eiffel-develop] Gestalt now crashes when compiled with gec only

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

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

    Eric> So it's either a problem in the way I use Boehm's finalizer
    Eric> registration (in particular I pass a function pointer where
    Eric> a void* is expected!), or a problem in Boehm's finalization,
    Eric> or a problem in the implementation of `dispose'. I would
    Eric> favor the first alternative considering that what you say
    Eric> below.

    >> But note that I do not have the problem on my 32-bit system (I
    >> tried both before and after an svn update), so it might be a
    >> problem with Boehm gc 7.0 on 64-bit systems. I will try a newer
    >> version.

That doesn't work (I used the 24th February version of 7.1 alpha).
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Gestalt now crashes when compiled with gec only

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

Colin Paul Adams wrote:
>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
> 
>     Eric> If the problem comes from gec, it might be a consequence of
>     Eric> that:
> 
>     Eric>   * When gec compiles an application with the Boehm GC, it
>     Eric> now generates code that will let the GC trigger the feature
>     Eric> `dispose' when objects are reclaimed.
> 
>     Eric> You can try to edit the file
>     Eric> $GOBO/tool/gec/runtime/c/ge_gc.h and replace line 68:
> 
>     Eric> #define GE_register_dispose(obj, disp)
>     Eric> GC_REGISTER_FINALIZER((void*)(obj), (void (*) (void*,
>     Eric> void*)) &GE_boehm_dispose, (void*)(disp), NULL, NULL)
> 
>     Eric> by:
> 
>     Eric> #define GE_register_dispose(obj, disp) /* do nothing */
> 
>     Eric> and then recompile gestalt.
> 
> This works.

So it's either a problem in the way I use Boehm's finalizer registration
(in particular I pass a function pointer where a void* is expected!),
or a problem in Boehm's finalization, or a problem in the implementation
of `dispose'. I would favor the first alternative considering that what
you say below.

> But note that I do not have the problem on my 32-bit system (I
> tried both before and after an svn update), so it might be a problem
> with Boehm gc 7.0 on 64-bit systems. I will try a newer version.

OK.

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

Re: [gobo-eiffel-develop] Gestalt now crashes when compiled with gec only

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

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

    Eric> If the problem comes from gec, it might be a consequence of
    Eric> that:

    Eric>   * When gec compiles an application with the Boehm GC, it
    Eric> now generates code that will let the GC trigger the feature
    Eric> `dispose' when objects are reclaimed.

    Eric> You can try to edit the file
    Eric> $GOBO/tool/gec/runtime/c/ge_gc.h and replace line 68:

    Eric> #define GE_register_dispose(obj, disp)
    Eric> GC_REGISTER_FINALIZER((void*)(obj), (void (*) (void*,
    Eric> void*)) &GE_boehm_dispose, (void*)(disp), NULL, NULL)

    Eric> by:

    Eric> #define GE_register_dispose(obj, disp) /* do nothing */

    Eric> and then recompile gestalt.

This works.

But note that I do not have the problem on my 32-bit system (I
tried both before and after an svn update), so it might be a problem
with Boehm gc 7.0 on 64-bit systems. I will try a newer version.
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Gestalt now crashes when compiled with gec only

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

Colin Paul Adams wrote:
> As of today (I don't know when I last compiled it sucessfully),
> gestalt (but not gexslt) seg-faults at start up, when compiled with
> gec + boehm gc 7.0, but not without gec, nor when compiled with ISE
> 6.1.
> 
> This seems very strange. It requires both eposix and boehm gc to
> produce the error (gexslt compiled with boehm gc does not produce the
> error), but does not depend upon any eposix facilities being used
> (just typing the command name - expecting the usage message, is
> sufficent to seg-fault).

> So I can't think of what might be the problem. Anyone have any ideas?

If the problem comes from gec, it might be a consequence of that:

  * When gec compiles an application with the Boehm GC, it now generates
    code that will let the GC trigger the feature `dispose' when objects
    are reclaimed.

You can try to edit the file $GOBO/tool/gec/runtime/c/ge_gc.h and
replace line 68:

#define GE_register_dispose(obj, disp) 
GC_REGISTER_FINALIZER((void*)(obj), (void (*) (void*, void*)) 
&GE_boehm_dispose, (void*)(disp), NULL, NULL)

by:

#define GE_register_dispose(obj, disp) /* do nothing */

and then recompile gestalt.

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

Re: [gobo-eiffel-develop] [eposix] Gestalt now crashes when compiled with gec only

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

Colin Paul Adams wrote:
>>>>>> "Berend" == Berend de Boer <be...@po...> writes:
> 
>>>>>> "Colin" == Colin Paul Adams <co...@co...> writes:
>     Colin> As of today (I don't know when I last compiled it Librt has
>     Colin> not been updated for a long time, and in any case, it is
>     Colin> linked in even without the boehm gc.
> 
>     Berend> You could try linking without.
> 
> That works, but is not a solution.
> 
>     Colin> So I can't think of what might be the problem. Anyone have
>     Colin> any ideas?
> 
>     Berend> What I can think of is that eposix isn't 64 bit aware. I
>     Berend> have never tested it on a 64 bit platform, not having
>     Berend> access to one. Hopefully in a couple of months.
> 
> Well it has been working satisfactorily for over a month.

You can try to check-out the code from a couple of weeks
ago (both Gobo and gestalt), bootstrap Gobo and see if
it works. If it works, then we have to see if the problem
comes from the code evolution, or from gec's evolution.

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

Re: [gobo-eiffel-develop] Gestalt now crashes when compiled with gec only

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

>>>>> "Eric" == Eric Bezault <er...@go...> writes:
> [colin@susannah gestalt]$ ldd ./gestalt
>         linux-vdso.so.1 =>  (0x00007fff8bbfe000)
>         libm.so.6 => /lib64/libm.so.6 (0x0000003eb4a00000)
>         libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003eb5200000)
>         librt.so.1 => /lib64/librt.so.1 (0x0000003eb7200000)
>         libc.so.6 => /lib64/libc.so.6 (0x0000003eb4600000)
>         /lib64/ld-linux-x86-64.so.2 (0x0000003eb3400000)
> [colin@susannah gestalt]$ ldd ~/gobo/bin/gexslt
>         linux-vdso.so.1 =>  (0x00007fff075fe000)
>         libm.so.6 => /lib64/libm.so.6 (0x0000003eb4a00000)
>         libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003eb5200000)
>         libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003ebec00000)
>         libc.so.6 => /lib64/libc.so.6 (0x0000003eb4600000)
>         /lib64/ld-linux-x86-64.so.2 (0x0000003eb3400000)
>
    Eric> Can you also run ldd on the executable of gestalt compiled
    Eric> with ISE 6.1?

[colin@susannah gestalt]$ ldd gestalt
        linux-vdso.so.1 =>  (0x00007fff3fdfe000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003eb5200000)
        librt.so.1 => /lib64/librt.so.1 (0x0000003eb7200000)
        libm.so.6 => /lib64/libm.so.6 (0x0000003eb4a00000)
        libc.so.6 => /lib64/libc.so.6 (0x0000003eb4600000)
        /lib64/ld-linux-x86-64.so.2 (0x0000003eb3400000)

So its the same as when compiled with gec.
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Gestalt now crashes when compiled with gec only

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

Colin Paul Adams wrote:
> As of today (I don't know when I last compiled it sucessfully),
> gestalt (but not gexslt) seg-faults at start up, when compiled with
> gec + boehm gc 7.0, but not without gec, nor when compiled with ISE
> 6.1.
> 
> This seems very strange. It requires both eposix and boehm gc to
> produce the error (gexslt compiled with boehm gc does not produce the
> error), but does not depend upon any eposix facilities being used
> (just typing the command name - expecting the usage message, is
> sufficent to seg-fault).
> 
> So I suspected a library change. doing an ldd on the executbles gives:
> 
> [colin@susannah gestalt]$ ldd ./gestalt
>         linux-vdso.so.1 =>  (0x00007fff8bbfe000)
>         libm.so.6 => /lib64/libm.so.6 (0x0000003eb4a00000)
>         libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003eb5200000)
>         librt.so.1 => /lib64/librt.so.1 (0x0000003eb7200000)
>         libc.so.6 => /lib64/libc.so.6 (0x0000003eb4600000)
>         /lib64/ld-linux-x86-64.so.2 (0x0000003eb3400000)
> [colin@susannah gestalt]$ ldd ~/gobo/bin/gexslt
>         linux-vdso.so.1 =>  (0x00007fff075fe000)
>         libm.so.6 => /lib64/libm.so.6 (0x0000003eb4a00000)
>         libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003eb5200000)
>         libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003ebec00000)
>         libc.so.6 => /lib64/libc.so.6 (0x0000003eb4600000)
>         /lib64/ld-linux-x86-64.so.2 (0x0000003eb3400000)
> 
> so the difference is that gestalt has librt whereas gexslt has
> libgcc_s.
> 
> Librt has not been updated for a long time, and in any case, it is
> linked in even without the boehm gc.
> 
> So I can't think of what might be the problem. Anyone have any ideas?

Can you also run ldd on the executable of gestalt compiled with
ISE 6.1?

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

[gobo-eiffel-develop] Gestalt now crashes when compiled with gec only

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

As of today (I don't know when I last compiled it sucessfully),
gestalt (but not gexslt) seg-faults at start up, when compiled with
gec + boehm gc 7.0, but not without gec, nor when compiled with ISE
6.1.

This seems very strange. It requires both eposix and boehm gc to
produce the error (gexslt compiled with boehm gc does not produce the
error), but does not depend upon any eposix facilities being used
(just typing the command name - expecting the usage message, is
sufficent to seg-fault).

So I suspected a library change. doing an ldd on the executbles gives:

[colin@susannah gestalt]$ ldd ./gestalt
        linux-vdso.so.1 =>  (0x00007fff8bbfe000)
        libm.so.6 => /lib64/libm.so.6 (0x0000003eb4a00000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003eb5200000)
        librt.so.1 => /lib64/librt.so.1 (0x0000003eb7200000)
        libc.so.6 => /lib64/libc.so.6 (0x0000003eb4600000)
        /lib64/ld-linux-x86-64.so.2 (0x0000003eb3400000)
[colin@susannah gestalt]$ ldd ~/gobo/bin/gexslt
        linux-vdso.so.1 =>  (0x00007fff075fe000)
        libm.so.6 => /lib64/libm.so.6 (0x0000003eb4a00000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003eb5200000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003ebec00000)
        libc.so.6 => /lib64/libc.so.6 (0x0000003eb4600000)
        /lib64/ld-linux-x86-64.so.2 (0x0000003eb3400000)

so the difference is that gestalt has librt whereas gexslt has
libgcc_s.

Librt has not been updated for a long time, and in any case, it is
linked in even without the boehm gc.

So I can't think of what might be the problem. Anyone have any ideas?
-- 
Colin Adams
Preston Lancashire

[gobo-eiffel-develop] XML 1.0 proposed fifth edition

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

For information:

http://lists.w3.org/Archives/Public/xml-editor/2008JanMar/0007.html

Re: [gobo-eiffel-develop] Creating a test case

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

Colin Paul Adams wrote:
> I'm not exactly sure how to create a test case now that they have
> changed slightly.

Please run the bootstrap again so that getest gets recompiled.

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

[gobo-eiffel-develop] Creating a test case

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

I'm not exactly sure how to create a test case now that they have
changed slightly.

I have coded the following:

class RX_UC_TEST_COMPILER

inherit

	TS_TEST_CASE

create

	make_default

feature -- Test

	test_compile is
			-- Test basics of class RX_UC_COMPILER.
		local
			l_matcher: RX_UC_PATTERN
		do
			create l_matcher.compile ("^.*$")
			assert ("Compiled", l_matcher.is_compiled)
			assert ("No error", l_matcher.is_valid)
		end

end

but the compiler is objecting:

Error code: VMFN
Error: two or more features have same name.
What to do: if they must indeed be different features, choose different
  names or use renaming; if not, arrange for a join (between deferred
  features), an effecting (of deferred by effective), or a redefinition. 

Class: RX_UNICODE
Feature: suite: TS_TEST_SUITE Version from: RX_UNICODE
Feature: suite: TS_TEST_SUITE inherited from: TS_TESTER Version from: TS_TESTER

-------------------------------------------------------------------------------

Error code: VDRS(1)
Error: identifier in Redefine subclause does not denote inherited feature.  
What to do: make sure that all identifiers in subclause are final names
  of features inherited from the given parent. 

Class: XRX_UC_TEST_COMPILER
Invalid feature name: execute_i_th
In Redefine clause for parent: RX_UC_TEST_COMPILER

-------------------------------------------------------------------------------

Error code: VDRS(1)
Error: identifier in Redefine subclause does not denote inherited feature.  
What to do: make sure that all identifiers in subclause are final names
  of features inherited from the given parent. 

Class: XRX_UC_TEST_COMPILER
Invalid feature name: name_of_id
In Redefine clause for parent: RX_UC_TEST_COMPILER

It looks like something is being inherited twice, but I can't see why.

RX_UNICODE is the name of the root class I specified in the
system.xace for the test suite.
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Sized integer constants

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

Colin Paul Adams wrote:
> I have code thus:
> 
> 
> 	rule_set_rule_char: INTEGER_8 is 128
> 			-- Unicode character class index
> 
> 	rule_set_digit_char: INTEGER_8 is 129
> 			-- Unicode character class index
> 
> 
> ISE 6.1 is complaining:
> 
> 
> Error code: VQMC
> Error: type of manifest constant does not match declaration.
> What to do: use appropriate manifest constant type as value,
>   or change declared type to match value.
> 
> Class: RX_UC_GRAMMAR
> Constant name: rule_set_rule_char
> Found constant of type: INTEGER_32
> Declared type: INTEGER_8
> 
> 
> I guess that means I need to write:
> 
> 
> 
> 	rule_set_rule_char: INTEGER_8 is {INTEGER_8} 128
> 			-- Unicode character class index
> 
> 	rule_set_digit_char: INTEGER_8 is {INTEGER_8} 129
> 			-- Unicode character class index
> 
> 
> but is that OK in Gobo for all currently supported compilers?

I depends what we mean by "supported compilers". I doubt that
SE 1.2 supports that notation.

> If not, will changing the manifest constants to once routines be the
> best work-around?

No. SE 1.2 will still complain I guess. In any case, I'm
not sure I understand what you want to do. INTEGER_8 are
between -128 and 127. So even with a cast, it does not work.
So you should either use NATURAL_8 (which again might cause
a problem with SE 1.2), or state clearly that your values
are actually stored as -1 and -2.

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

[gobo-eiffel-develop] Sized integer constants

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

I have code thus:


	rule_set_rule_char: INTEGER_8 is 128
			-- Unicode character class index

	rule_set_digit_char: INTEGER_8 is 129
			-- Unicode character class index


ISE 6.1 is complaining:


Error code: VQMC
Error: type of manifest constant does not match declaration.
What to do: use appropriate manifest constant type as value,
  or change declared type to match value.

Class: RX_UC_GRAMMAR
Constant name: rule_set_rule_char
Found constant of type: INTEGER_32
Declared type: INTEGER_8


I guess that means I need to write:



	rule_set_rule_char: INTEGER_8 is {INTEGER_8} 128
			-- Unicode character class index

	rule_set_digit_char: INTEGER_8 is {INTEGER_8} 129
			-- Unicode character class index


but is that OK in Gobo for all currently supported compilers?

If not, will changing the manifest constants to once routines be the
best work-around?
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Subversion broken?

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

Colin Paul Adams wrote:
> I can't do anything with subversion (for gobo and others) - not even
> an update. I assume this is a sourceforge problem, but just in case
> it's my system, can someone else please confirm?

It worked for me earlier today, but indeed it does not work anymore.
Here is what I got:

Error: Can't create directory 
'/svnroot-fuse/gobo-eiffel/db/transactions/6313-1.txn': No space left on 
device

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

[gobo-eiffel-develop] Subversion broken?

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

I can't do anything with subversion (for gobo and others) - not even
an update. I assume this is a sourceforge problem, but just in case
it's my system, can someone else please confirm?
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Change in export status to exceptions?

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

Eric Bezault wrote:
> Colin Paul Adams wrote:
>>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
>>     Eric> Fixed. You should note that for the second one, there is no
>>     Eric> guarantee that `developer_exception_name' is never Void.
>>
>> Thanks.
>>
>> Under what circumstances might it be Void (given
>> Exceptions.is_developer_exception is True)?
> 
> I don't know either. I'm just reporting that neither ISE
> nor SmartEiffel have a postcondition stating that it is
> not Void.

Note that `raise' has no precondition either. That might
explain why `developer_exception_name' has no postcondition.

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

Re: [gobo-eiffel-develop] Change in export status to exceptions?

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

Colin Paul Adams wrote:
>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
> 
>     Eric> Fixed. You should note that for the second one, there is no
>     Eric> guarantee that `developer_exception_name' is never Void.
> 
> Thanks.
> 
> Under what circumstances might it be Void (given
> Exceptions.is_developer_exception is True)?

I don't know either. I'm just reporting that neither ISE
nor SmartEiffel have a postcondition stating that it is
not Void.

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

Re: [gobo-eiffel-develop] Change in export status to exceptions?

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

Colin Paul Adams wrote:
>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
> 
>     Eric> Colin Paul Adams wrote:
>     >>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
>     >> 
>     Eric> Colin Paul Adams wrote:
>>>> After updaing Gobo today, I can no longer compile gestalt. I
>     >> >> get: >> >> >> Class: EPX_FTP_URI_RESOLVER Feature:
>     >> retrieve_file Feature: >> exception Class: KL_EXCEPTIONS
>     >> Version from: EXCEPTIONS Not >> exported to class
>     >> EPX_FTP_URI_RESOLVER Line: 321 else
>     -> set_local_error ("An attempt to retrieve a file by ftp resulted
>     -> in exception code " + Exceptions.exception.out)
>     >> >> end
>     >> 
>     Eric> It should be fixed now.
>     >> 
>     >> I'm afraid not.
>     >> 
>     >> I got an update for KI_EXCEPTIONS, but I still get the same
>     >> error. (I did a goat install).
> 
>     Eric> I don't understand, `exception' should now be exported.
> 
> Ah yes - but there are additional problems:
> 
> 
> Error code: VUEX(2)
> Error: feature of qualified call is not available to client class.
> What to do: make sure feature after dot is exported to caller.
> 
> Class: EPX_FTP_URI_RESOLVER
> Feature: retrieve_file
> Feature: is_developer_exception Class: KL_EXCEPTIONS Version from: EXCEPTIONS
> Not exported to class EPX_FTP_URI_RESOLVER
> Line: 318
>         is_retrieving := False
> ->      if Exceptions.is_developer_exception then
>           set_local_error ("An attempt to retrieve a file by ftp resulted in the condition: " + Exceptions.developer_exception_name)
> 
> 
> Error code: VUEX(2)
> Error: feature of qualified call is not available to client class.
> What to do: make sure feature after dot is exported to caller.
> 
> Class: EPX_FTP_URI_RESOLVER
> Feature: retrieve_file
> Feature: developer_exception_name Class: KL_EXCEPTIONS Version from: EXCEPTIONS
> Not exported to class EPX_FTP_URI_RESOLVER
> Line: 319
>         if Exceptions.is_developer_exception then
> ->        set_local_error ("An attempt to retrieve a file by ftp resulted in the condition: " + Exceptions.developer_exception_name)
>         else
> 
> -------------------------------------------------------------------------------

Fixed. You should note that for the second one, there is no guarantee
that `developer_exception_name' is never Void.

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

Re: [gobo-eiffel-develop] Change in export status to exceptions?

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

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

    Eric> Fixed. You should note that for the second one, there is no
    Eric> guarantee that `developer_exception_name' is never Void.

Thanks.

Under what circumstances might it be Void (given
Exceptions.is_developer_exception is True)?
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Change in export status to exceptions?

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

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

    Eric> Colin Paul Adams wrote:
    >>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
    >> 
    Eric> Colin Paul Adams wrote:
> >> After updaing Gobo today, I can no longer compile gestalt. I
    >> >> get: >> >> >> Class: EPX_FTP_URI_RESOLVER Feature:
    >> retrieve_file Feature: >> exception Class: KL_EXCEPTIONS
    >> Version from: EXCEPTIONS Not >> exported to class
    >> EPX_FTP_URI_RESOLVER Line: 321 else
    -> set_local_error ("An attempt to retrieve a file by ftp resulted
    -> in exception code " + Exceptions.exception.out)
    >> >> end
    >> 
    Eric> It should be fixed now.
    >> 
    >> I'm afraid not.
    >> 
    >> I got an update for KI_EXCEPTIONS, but I still get the same
    >> error. (I did a goat install).

    Eric> I don't understand, `exception' should now be exported.

Ah yes - but there are additional problems:


Error code: VUEX(2)
Error: feature of qualified call is not available to client class.
What to do: make sure feature after dot is exported to caller.

Class: EPX_FTP_URI_RESOLVER
Feature: retrieve_file
Feature: is_developer_exception Class: KL_EXCEPTIONS Version from: EXCEPTIONS
Not exported to class EPX_FTP_URI_RESOLVER
Line: 318
        is_retrieving := False
->      if Exceptions.is_developer_exception then
          set_local_error ("An attempt to retrieve a file by ftp resulted in the condition: " + Exceptions.developer_exception_name)


Error code: VUEX(2)
Error: feature of qualified call is not available to client class.
What to do: make sure feature after dot is exported to caller.

Class: EPX_FTP_URI_RESOLVER
Feature: retrieve_file
Feature: developer_exception_name Class: KL_EXCEPTIONS Version from: EXCEPTIONS
Not exported to class EPX_FTP_URI_RESOLVER
Line: 319
        if Exceptions.is_developer_exception then
->        set_local_error ("An attempt to retrieve a file by ftp resulted in the condition: " + Exceptions.developer_exception_name)
        else

-------------------------------------------------------------------------------

BUILD FAILED!

-- 
Colin Adams
Preston Lancashire