From: CRDGW2::CRDGW2::MRGATE::"SMTP::PREP.AI.MIT.EDU::INFO-G++-REQUEST" 24-JUL-1989 14:49 To: MRGATE::"ARISIA::EVERHART" Subj: ET++ patches revisited Received: by life.ai.mit.edu (4.1/AI-4.10) id AA26751; Mon, 24 Jul 89 04:59:09 EDT Return-Path: Received: from uunet.uu.net by life.ai.mit.edu (4.1/AI-4.10) id AA26640; Mon, 24 Jul 89 04:51:00 EDT Received: from ukc.UUCP by uunet.uu.net (5.61/1.14) with UUCP id AA00436; Mon, 24 Jul 89 04:50:52 -0400 Received: from root.co.uk by kestrel.Ukc.AC.UK with UUCP id aa29183; 24 Jul 89 9:34 BST Received: from edinburgh.kewill.uucp by kewill.uucp (3.2/SMI-3.2) id AA25966; Sun, 23 Jul 89 17:47:23 BST Received: by edinburgh.kewill.uucp (3.2/SMI-3.2) id AA07621; Sun, 23 Jul 89 17:47:17 BST Date: Sun, 23 Jul 89 17:47:17 BST From: Bryan Boreham Message-Id: <8907231647.AA07621@edinburgh.kewill.uucp> To: info-g++@prep.ai.mit.edu Subject: ET++ patches revisited 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.