Re: Bootstrapping Gobo CVS using Visual Eiffel

Hi Eric,

> Well, Visual Eiffel has not been maintained for a loooonnnnng time.

Yes, and Visual Eiffel has suffered some bitrot as a result. In
particular, it does not build when using up-to-date versions of its
dependencies.

Also, due to its origins as a commercial product it doesn't always use
the usual open-source toolchains for building some components (e.g. help
files).

Nevertheless, Visual Eiffel itself is written in very clean, readable
and solid Eiffel. The underlying compiler technology is full-featured
and robust (incremental compilation, solid implementation of expanded
types and generics, precompilation, exception handling, etc).

The included libraries were developed with an emphasis on compatibility
and a respect for working code. They include ports of EiffelBase and
WEL, and the kernel libraries are full of "obsolete" features that
support code written for earlier compilers (Eiffel/S, pre-ELKS VE etc).

> Supporting Visual Eiffel means that we cannot use Agents, Tuples,
> INTEGER_64 and unsigned integers among other things in Gobo.

Back in the day when NICE maintained the Eiffel standard, the policy of
Object Tools was to implement these things if and when they were adopted
by NICE. That's why Visual Eiffel supports "precursor" (which NICE did
endorse) but not yet the other things that you mention.

Agents etc are pretty much mainstream in modern Eiffel, and I don't
imagine many people would object in principle to implementing them for
Visual Eiffel. It's "just a matter of programming" :-)

> ... 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.

Of course. One example of this bidirectional support is that Visual
Eiffel 5.0 supports XACE files "out of the box".

> Now I noticed that the OpenEiffel seems to take over Visual Eiffel
> source code...

It's true, although I don't want to announce it too loudly until the
code there bootstraps fully, and until housekeeping such as license
changes is complete, and until a binary distribution is available.

Object Tools has kindly donated the codebase under the MIT license
(which is compatible with the GPL and with just about everything else
too). The old restriction that changes to the Visual Eiffel trunk had to
be contributed to the proprietary version of VE is now of course gone.

> If it means that this compiler will be maintained again...

I sure hope it will, but until everything is usable with a modern
open-source toolchain I don't think we are quite there yet.

> ... 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 principle that's how it should work, but in practise it's going to be
a rocky ride over the next few years because "directions already
supported by EiffelStudio" is not always the same as "directions already
supported by SmartEiffel".

> 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.

Thanks very much. I've also succeeded here.

Regards,
Roger Browne



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/