Re: tecomp 0.6 released

On Dec 6, 5:51 pm, scholz.lot...@xxxxxxxxx wrote:
On 6 Dez., 14:44, Helmut <helmut.bra...@xxxxxxx> wrote:

What can you do with BSD which you cannot do with (L)GPL?

If the community (or in this case the only maintainer) drops the
product you can try to maintain it and refinance it by turning it
into a commercial product and sharing the development cost of it
in this way. The idiots of Visual Eiffel didn't like this and so the
whole now GPL project is just more bits in the giant sourceforge
trashcan.

I learned this because i made the huge mistake with FOX and
SmallEiffel,
two projects where i have to spend a lot of time on development.
Communitiy died or went total crazy.

So if the part is mission critical then for me i will never ever use
LGPL again.

Also, LGPL for a runtime library is not really clever, you have to
allow reverse engineering (for some projects this is surely a
killer) ,
provide linkable executables (a lot of extra work, so some people
extend LGPL it with a static linking clause) and when using
C++ or C with inline functions the whole LGPL concept is quite
stupid.

Remember you are not Sun and this project will never reach a big
community
big enough to be able to survive. So for me it is 100% important
to give the project a BSD license.

I'm not sure how to continue. I don't want to drop Eiffel, i can't
to purchase EiffelStudio for 15000 US$, gec will never be useable
for large eiffel projects just for the same reason why i can't use
SmallEiffel anymore.

I'm also 90% sure that tecomp can't do it because they all suffer
from
a huge problem: Compilation time with a stupid simple command line
one
system at once compiler is larger the O(n). Also "gec" and "Small/
SmartEiffel"
are producing extremely large binaries. My programm with 300KLoc
compiles
into a 38MB executable at the moment (using SmallEiffel). This is
insane.

I don't see any ideas in your design to provide a compile server
(keeping
whole system information across compilation runs) or any way to at
least
just use more CPU cores to speed the compilation up. And no - you
can't add
this later. The whole system has to be designed from ground up for
this.

What does that mean for your specific project? (If you can, could you
disclose some information of the project you have in mind?).

Rewriting Eclipse or NetBeans.

This might not be a problem, because I as the author can release
tecomp under different licenses, one for public use and one for
integration into gcc or llvm.

Yes if you change the license before you receive patches from other
people.
A dual license would be good enough.

And by the way. Have you ever looked at GCC ? It's a nightmare and
with eiffel there are more options, the easiest is to just generate
clever splitted ANSI C code. No need to write a GNU frontend.

There are 100 reasons why the GCC stuff should be avoided as hell.
Read the threads about using PCC for OpenBSD to get a few points.

Hello Lothar,

an answer to your technical concerns:

I don't understand why other Eiffel compilers produce that large
binaries. If you write a simple "Hello world"-program, the binary
should have nearly the same size as the same program written in plain
C (at least if compiled as optimized). An optimized to C compilation
should just translate the Eiffel code to plain C and nothing more.

If you want garbage collection, you get some overhead for it (but it
is a rather small offset, nothing that grows with the code).

If you want exception handling, you will get some (code proportional)
overhead, but I wouldn't expect more than 10%.

If you want incremental compilation to C, you will get some overhead.
But only if you want to exploit the really minimum of recompilation
(e.g. treat all feature calls with dynamic bind, even if not necessary
in the current version but to avoid recompilation for future
versions). But I am in favor of doing incremental compilation not on
the C level, but on the intermediate code.

You see that I have some ifs, but I don't expect large binaries for
Eiffel code compiled with tecomp. Having not yet done compilation to
C, you might put a question mark on that statement. But remember: One
of the reasons to start the tecomp project was that the big footprint
of C-code and binaries of some competitors horrified me.

With respect to support fast edit-compile-run cycles: Yes, the
internal structures of tecomp are designed to support saving of
compilation results between compilation runs. I have not yet decided
if I will do it with a compile server, but compilations will not be
wasted and recompilations will only be done, if necessary.

Some of my measurement have shown that after parsing and validation
(which are class local without doing global analysis) there is a good
point to save the results. Parsing is very fast, but validation needs
some time and should not be wasted across compilations.

In other compilers (EiffelStudio and SmartEiffel), C-compilation is
the bottleneck. I do not yet know the reason. If the reason is
inflated C output from the compiler, the point of attack is the C code
generator. But let's see.


Regards
Helmut
.

Relevant Pages

  • Re: tecomp 0.6 released
    ... An optimized to C compilation ... should just translate the Eiffel code to plain C and nothing more. ... well unless you are using a lot of inheritance. ... I think the Eiffel step is pretty under control in tecomp. ...
    (comp.lang.eiffel)
  • Re: Unexplainable ActiveX Error
    ... in Dolphin, I simply sent this off to Codejock's technical support. ... I can speak more confidently about Eiffel, however, and I can assure you ... It sees a variable, as Smalltalk calls it, ... between the two during compilation and, therefore, like VFP, would ...
    (comp.lang.smalltalk.dolphin)
  • Re: tecomp 0.6 released
    ... If the community drops the ... The idiots of Visual Eiffel didn't like this and so the ... Compilation time with a stupid simple command line ... Yes if you change the license before you receive patches from other ...
    (comp.lang.eiffel)
  • The Eiffel Compiler tecomp version 0.11 released.
    ... The Eiffel Compiler tecomp version 0.11 has been released. ... Therefore the usefulness of tecomp has been rather limited. ... Beside the provision of powerful standard libraries, ... Having standard libraries and compilation to c, ...
    (comp.lang.eiffel)
  • The Eiffel Compiler tecomp version 0.11 released.
    ... The Eiffel Compiler tecomp version 0.11 has been released. ... Therefore the usefulness of tecomp has been rather limited. ... Beside the provision of powerful standard libraries, ... Having standard libraries and compilation to c, ...
    (comp.object)
Loading