Re: Bootstrapping Gobo CVS using Visual Eiffel
Eric Bezault <ericb-D6Qt/9opevxWk0Htik3J/[email protected]>
| Newsgroups | gmane.comp.lang.eiffel.gobo.general |
|---|---|
| Message-ID | <[email protected]> |
Roger Browne wrote:
> I'm attempting to bootstrap Gobo (CVS HEAD) using Visual Eiffel 5.0b
> (Build 2508) and it's throwing up a few compilation errors due to recent
> changes to Gobo.
>
> Eric, is it still your desire to support Visual Eiffel? If not, let me
> know and I'll revert to an older "known good for VE" version of Gobo.
Well, Visual Eiffel has not been maintained for a loooonnnnng time.
Supporting Visual Eiffel means that we cannot use Agents, Tuples,
INTEGER_64 and unsigned integers among other things in Gobo. So yes,
I was about to think about dropping the support for Visual Eiffel
in one of the forthcoming releases of Gobo. Indeed, support should
be bidirectional: Gobo can support various Eiffel compilers, but
these compilers should make an effort to support libraries like
Gobo as well and make sure that they will still be able to compile
those libraries as they are both evolving.
Now I noticed that the OpenEiffel seems to take over Visual Eiffel
source code. If it means that this compiler will be maintained
again, then I will definitely be willing to have Gobo still be
compilable with it provided that Gobo can nevertheless evolves in
directions already supported by other compilers. In fact I already
filled in a Feature Request about that yesterday on the SourceForge
OpenEiffel web site.
> Otherwise, here are the first three compilation errors:
>
> 1. Class DS_SPARSE_TABLE line 515: Visual Eiffel wants to see
>
> precursor {DS_SPARSE_CONTAINER [G, K]} (other)
>
> instead of
>
> precursor {DS_SPARSE_CONTAINER} (other)
>
> because there could potentially be inheritance from more than
> one generic derivation of the same class.
This one is not easy because ISE Eiffel will not compile it if
it is something else than the second form above. There is a bug
which prevents us from removing the optional parent clause in
this particular case.
But after changing the inheritance clause I managed to have
something which works with both compilers (and with gec as well).
> 2. Class DS_SPARSE_TABLE_KEYS_CURSOR line 19: Visual Eiffel
> rejects "redefine container" because 'container' is
> inherited deferred.
This is fixed now.
> 3. Class ET_IMPLEMENTATION_CHECKER line 182: Visual Eiffel
> rejects "ensure then". It wants "ensure" because there
> is no inherited postcondition.
This is fixed now.
Thank you for reporting these problems. I just tried it and it
is now possible to bootstrap the CVS version of Gobo using
Visual Eiffel 5.0b.
--
Eric Bezault
mailto:ericb-D6Qt/9opevxWk0Htik3J/[email protected]
http://www.gobosoft.com
To Post a message, send it to: [email protected]
To Unsubscribe, send a blank message to: [email protected]
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/gobo-eiffel/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/gobo-eiffel/join
(Yahoo! ID required)
<*> To change settings via email:
mailto:[email protected]
mailto:[email protected]
<*> To unsubscribe from this group, send an email to:
[email protected]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/