Visual Eiffel - a clarification
Frieder Monninger
In order to clarify some misunderstandings, we have explained the reasons
why we did this in http://visual-eiffel.org/The_future
In short:
Object Tools has absolutely no plans to stop support of Visual Eiffel !
Ulrich Windl
Good! Very good! However I wonder about the fact that since it's open source
there seems less progress than before. What about supporting an non i386
compatible processor? WOuld it be a good idea to join the Eiffel compiler with
the GNU C compiler (than already can compile Fortran, Java, and Ada)? You
would get optimizers and backends for free...
Regards,
Ulrich
Roger Browne
> ... WOuld it be a good idea to join the Eiffel compiler with
> the GNU C compiler...
The Linux version of Visual Eiffel already uses gcc as its back-end.
Unfortunately, it doesn't bootstrap using gcc4.0 (which is what comes as
standard with Fedora Core 4). gcc4.0 is stricter about the language that
it accepts, and it won't take cast-as-lvalue - which has been deprecated
for a while. Unfortunately I don't have sufficient C-programming skills
to fix this myself, but I've reported the problem to Object Tools.
The binary distribution of VE for Linux runs fine with gcc4.0 though.
Regards,
Roger Browne
Pascal Obry
> The Linux version of Visual Eiffel already uses gcc as its back-end.
So why not push the Eiffel frontend into the GCC FSF tree ? The Ada,
Fortran, C, C++, Java and Objective-C languages are already there. Why
not Eiffel ?
It will get more support from the community and will be easier for you
to maintain in the long run.
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
Friedrich Dominicus
> Roger Browne a écrit :
>
>> The Linux version of Visual Eiffel already uses gcc as its back-end.
>
> So why not push the Eiffel frontend into the GCC FSF tree ? The Ada,
> Fortran, C, C++, Java and Objective-C languages are already there. Why
> not Eiffel ?
Have you an idea on how long it has took them to implement
VisualEiffel as is at the moment? Why should they spend nearly the
same amount of time and *money* just to please the FSF people?
>
> It will get more support from the community and will be easier for you
> to maintain in the long run.
I doubt that very much.
Friedrich
--
Please remove just-for-news- to reply via e-mail.
Pascal Obry
> Have you an idea on how long it has took them to implement
> VisualEiffel as is at the moment? Why should they spend nearly the
> same amount of time and *money* just to please the FSF people?
How strange ! If VisualEiffel is based on a GCC backend it should not
take as much time to merge into the FSF tree than to develop it!
>>It will get more support from the community and will be easier for you
>>to maintain in the long run.
>
> I doubt that very much.
See what is happening with the Ada backend. As soon as there is a
regression with a new backend it is reported and tracked. Just that is
already a lot as it is easy to know what is the regression about. Also
on the Ada side, Ada enthusiasts have done a great job like adding a
non-regression test suite... It is always better to share the work.
Pascal Obry
Just to add that there is also one Ada enthusiast that creates Debian
packages for the compiler, to install:
$ apt-get gnat
As I said, sharing the work is good for everybody.
So if VisualEiffel is really OpenSource at this point I think it is a
path to consider.
Just my 2 cents,
Roger Browne
> So if VisualEiffel is really OpenSource at this point I think it
> [merge into the FSF tree] is a path to consider.
Go for it, Pascal! You can obtain the GPL source from
http://sourceforge.net/projects/visualeiffel/
Regards,
Roger Browne
Pascal Obry
> Go for it, Pascal! You can obtain the GPL source from
> http://sourceforge.net/projects/visualeiffel/
I understand that everybody can take the work load :)
But I'm sorry to decline the offer, I'm already contributing a lot to
the Ada community and cannot afford more than that!
Ulrich Windl
> Friedrich Dominicus a écrit :
>
> > Have you an idea on how long it has took them to implement
> > VisualEiffel as is at the moment? Why should they spend nearly the
> > same amount of time and *money* just to please the FSF people?
>
> How strange ! If VisualEiffel is based on a GCC backend it should not
> take as much time to merge into the FSF tree than to develop it!
I think the original poster meant the VE for Linux uses gcc to _compile_ the C
code VE generates. Using a GCC backend is something different.
Roger Browne
> I think the original poster meant the VE for Linux uses gcc to _compile_ the C
> code VE generates.
Visual Eiffel is a native-code compiler, i.e. it doesn't translate
Eiffel to C. However, VE for Linux uses gcc 3.x or 4.x for linking.
The Visual Eiffel compiler includes some code written in C, and the
Linux version requires gcc 3.x to compile the compiler (the code uses
lvalue casts so it doesn't work with gcc 4.x).
Regards,
Roger Browne
Roger Browne
The open-source Visual Eiffel compiler includes some code written
in C, and the Linux version requires gcc 3.x to compile the
compiler (the code uses lvalue casts so it doesn't work with gcc 4.x).
Anyone know how to modify the source code to get VE to build on recent
Linux distributions such as Fedora Core 4 that use gcc 4.x?
The binary distribution of Visual Eiffel works fine on those platforms.
The Visual Eiffel compiler follows ETL2 closely, and has very clean
implementations of expanded types, generics and low-level operations
such as memory access. It would be good to get some more mileage out of
VE, now that it has been released under the GPL.
Perhaps someone can produce a "streamlined" bootstrapping guide for
Linux. The existing instructions
http://visual-eiffel.org/index.php?title=Bootstrapping
list many dependencies (gcc 3.x, Gobo CVS, JDK 1.4+, Ant 1.6.2+, DocBook
XSL) but perhaps some of these can be removed from the basic bootstrap.
For example, unless someone is building documentation, they can
presumably get by without DocBook. And unless someone wants to modify
the few small parts of VE that use C, they can presumably get by with a
version that supplies this part as a library rather than as C source.
(The bulk of Visual Eiffel is written in Eiffel, and can be compiled
with the binary distribution of Visual Eiffel).
A "lean-and-mean" source distribution that people can successfully build
might trigger a renaissance of this product.
Regards,
Roger Browne
Friedrich Dominicus
> Are there any C gurus out there who are familiar with Eiffel and
>Linux?
Well I don't think I have reached C guru status, but you should know
that I'm quite used to it ;-), the others things are also on my "been
there, done that" List.
>
> The open-source Visual Eiffel compiler includes some code written
> in C, and the Linux version requires gcc 3.x to compile the
> compiler (the code uses lvalue casts so it doesn't work with gcc
> 4.x).
Well that is not really a problem is it? And how terrible difficult is
it to use a gcc 3.4.x for compiling?
> It would be good to get some more mileage out of
> VE, now that it has been released under the GPL.
may be ...
>
> Perhaps someone can produce a "streamlined" bootstrapping guide for
> Linux. The existing instructions
> http://visual-eiffel.org/index.php?title=Bootstrapping
> list many dependencies (gcc 3.x, Gobo CVS, JDK 1.4+, Ant 1.6.2+, DocBook
> XSL) but perhaps some of these can be removed from the basic
> bootstrap.
Could be done of course but for whom? If you feel a stream lined build
is needed you could probably ask OT to do that for you....
> A "lean-and-mean" source distribution that people can successfully build
> might trigger a renaissance of this product.
May be
Regards
Pascal Obry
> Roger Browne <ro...@eiffel.demon.co.uk> writes:
>>A "lean-and-mean" source distribution that people can successfully build
>>might trigger a renaissance of this product.
>
> May be
On thing sure, if nobody can built it nobody will use it.
Georg Bauhaus
> Friedrich Dominicus a écrit :
>
>>Roger Browne <ro...@eiffel.demon.co.uk> writes:
>>
>>>A "lean-and-mean" source distribution that people can successfully build
>>>might trigger a renaissance of this product.
>>
>>May be
>
>
> On thing sure, if nobody can built it nobody will use it.
It is possible, it just takes the time to read and interpret
the instructions :-)
-- Georg
Roger Browne
> On thing sure, if nobody can built it nobody will use it.
Just to make sure no-one misinterpreted my comments: you can _use_
Visual Eiffel easily on Linux, because the binary distribution works on
any mainstream Linux distribution.
But it's not so easy to become a developer of Visual Eiffel for Linux,
because it won't build from source on many recent distributions.
Friedrich Dominicus wrote:
> [removing lvalue casts] Well that is not really a problem is it?
Eugene, one of the Object Tools developers, feels that it's not so
straightforward. I'm afraid the piles of asterisks and parentheses
around these lvalue casts move the problem beyond my limited C skills.
If I was good enough at C to fix this reliably, then I wouldn't need
Eiffel :-)
> And how terrible difficult is it to use a gcc 3.4.x for compiling?
Sure it's possible to install and configure multiple versions of gcc on
a system. But every extra barrier to building a piece of open source
software reduces the number of potential developers by maybe a factor of
10. For a minority product, it's not viable if it won't build on
standard distributions.
As far as I know, no-one outside of Object Tools has bootstrapped VE for
Linux. Certainly no-one will admit to it on the VE Wiki:
http://visual-eiffel.org/index.php?title=Bootstrapping
Regards,
Roger Browne
Roger Browne
> It is possible, it just takes the time to read and interpret
> the instructions :-)
I spent a whole week on it, discovered and corrected several errors in
the instructions, and still didn't get it bootstrapped. I finished with
a comment from Eugene (of Object Tools) that it wasn't going to build on
my distribution.
What platform did you build it on? Do you have any comments to add to
the instructions here
and in the distribution? That would certainly help others...
Regards,
Roger Browne
Georg Bauhaus
> Georg Bauhaus wrote:
>
>>It is possible, it just takes the time to read and interpret
>>the instructions :-)
>
>
> I spent a whole week on it, discovered and corrected several errors in
> the instructions,
sounds familiar.
> and still didn't get it bootstrapped. I finished with
> a comment from Eugene (of Object Tools) that it wasn't going to build on
> my distribution.
It's a while ago, I'll check whether my memory is just playing
tricks on me. 8-| If not, it was a stable Debian GNU/Linux system,
using a GCC C compiler from the 3.3 series IIRC.
-- Georg
Friedrich Dominicus
>
> Friedrich Dominicus wrote:
>> [removing lvalue casts] Well that is not really a problem is it?
>
> Eugene, one of the Object Tools developers, feels that it's not so
> straightforward. I'm afraid the piles of asterisks and parentheses
> around these lvalue casts move the problem beyond my limited C skills.
> If I was good enough at C to fix this reliably, then I wouldn't need
> Eiffel :-)
>
>> And how terrible difficult is it to use a gcc 3.4.x for compiling?
>
> Sure it's possible to install and configure multiple versions of gcc on
> a system. But every extra barrier to building a piece of open source
> software reduces the number of potential developers by maybe a factor of
> 10. For a minority product, it's not viable if it won't build on
> standard distributions.
Well you know the usual answer:" It's free to get the source and do it
yourself. If you are not able of doing it you can ask someone to do it
for you"... or the like. Of course those FOSS guys would find this a
very reasonable answer, it's up to you to agree or disagree.
However having multiple gcc around is not really problem. On Debian
you can type apt-get install gcc-3.4 and are done whith it. That's not
a barrier by any means. Of course if you don't use Debian and your
distribution does not offer such way, bad luck.
>
> As far as I know, no-one outside of Object Tools has bootstrapped VE for
> Linux.
You like to challenge someone ;). Nice try... but again I just have to
think of ISE and SmartEiffel and I suddenly realize it's not worth a
second thought.
Roger Browne
> ... I just have to
> think of ISE and SmartEiffel and I suddenly realize it's not worth a
> second thought.
Do you mean: between ISE (free as in beer) and SmartEiffel (free as in
speech) there are enough Eiffel compilers already?
Roger
kin...@gmail.com
Ubuntu Linux box without much difficulty.
The only problem we had is with building Gobo's CVS HEAD gexslt with
the binary Visual Eiffel 5.0b release, which is only necessary for
building Visual Eiffel docs. The build process does depend upon
several tools and environmental variables, but it is certainly no worse
than any other compiler of comparable complexity.
The main problem is indeed the dependency on an old gcc release (we
used 2.9x) which is no longer available on some Linux distributions,
even as an old package. On some distros this means you will have to
build gcc yourself; on others (like Ubuntu) you can find a binary
package and just install it.
I just updated the Visual Eiffel wiki to reflect our success.
Friedrich Dominicus
Nice put. I was thinking of a different thing. They try to maximie
incompatiblity, and they are really successfull on this. So I meant I
considered working on it, but then I thought what they have done to
Eiffel and lost interest completly. Of course that's unfair towards
VE, but if one works on it one is working on yet another Eiffel
dialect (although it's the closest to ETLII)...
Regards
Roger Browne
> I was able to successfully bootstrap Visual Eiffel last week on an
> Ubuntu Linux box without much difficulty.
Fabulous news, Joseph. Thanks for letting us know, and for putting it on
the Visual Eiffel wiki.
Regards,
Roger Browne
Colin Paul Adams
JK> gexslt with the binary Visual Eiffel 5.0b release, which is
JK> only necessary for building Visual Eiffel docs.
Gobo docs, not VE docs.
--
Colin Adams
Preston Lancashire