Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!mit-eddie!kewill.UUCP!bryan
From: bryan@kewill.UUCP (Bryan Boreham)
Newsgroups: comp.lang.c++
Subject: ET++ patches revisited
Message-ID: <8907231647.AA07621@edinburgh.kewill.uucp>
Date: 23 Jul 89 16:47:17 GMT
Sender: daemon@eddie.MIT.EDU
Lines: 67

Hello again. If you're sick of hearing about ET++, hit 'n'. If you
want to know what it is, look back about four weeks in this newsgroup,
or mail me to ask.

So, I sent out 110K of patches, and a README file which warned that I
might have missed out a few things. I did.

The first problem is that the ET++/src/*/makefiles ran CC instead of
g++. I didn't spot this because I have a script called CC that runs
g++ -fno-defer-pop.

Note that g++ has a bug that is cured by -fno-defer-pop, so you should
use this flag for all programs, not just ET++, unless you are very
sure you know the envelope of this bug.

Next, the GNU pre-processor seems to have a bug relating to #pragma
once, causing it to report "too many open files". I have taken these
lines out of all the .h files except for Object.h and Types.h.

The makefiles in the ET++/applications/* directories will run the etld
script, which is for cfront only. I hadn't got round to looking at
those when I sent out the patches. I have now moved etld to somewhere
else so the makefiles will fall over, and I can link the application
by hand, or use dynamic linking.

If you get as far as a producing a binary that core-dumps, you need to
patch a bug in gdb before it will work well on ET++ programs. I have
posted fixes to versions 3.1.2.1 and 3.2 in gnu.gdb.bug. If you want
to run an ET++ program under X with gdb, use the -Eb flag to stop ET++
locking up the X server.

We only have Sun-3 systems here, so there are no patches for Sun-4's.
If you want to give me a SPARCstation...

I believe there are more problems with the patches, but I don't know
exactly what they are. If you know, please tell me.

Since I sent out the patches, I have done a bit more work on ET++.
Menus work properly on X now; link time for applications is down to 30
seconds; I ported the dynamic linking code, and the stack-trace
routine (but not both together :-( ); and I'm working on a way to
bring down the compilation time, which is very bad because of the
amount of stuff #included by even the simplest ET++ program.  I'll
release all of this once I'm sure it works, and once I've cleared up
the problems in the first set of patches.

ET++ is a wonderful system, and as I've said, it could be built into a
really great integrated C++ environment. Something like ObjectWorks
from ParcPlace, only written entirely in C++, and with the source code
available free.

It is, however, a bitch to learn. The inheritance hierarchy is deep
and complicated, and there is no tool to identify where a particular
method is actually implemented. Also, there are only a few comments,
and no manual. InterViews remains way ahead on this last point, but I
have documented some of the classes, and may distribute this if there
is interest. The paper in "Structured Programming" describes a
"cookbook" used by students to learn the system; unfortunately this
has not been distributed by the authors (yet?).

Bryan Boreham			bryan@kewill.uucp  
Software Engineer	||	bryan%kewill@uunet.uu.net
Kewill Systems PLC	||  ... uunet!mcvax!ukc!root44!kewill!bryan
Walton-On-Thames	
Surrey, England		Telephone: (+44) 932 248 328

ObjectWorks is a trademark of ParcPlace Systems Inc.