wht@n4hgf.Mt-Park.GA.US (Warren Tucker) (02/09/91)
In article <5850@uafhp.uark.edu> bbs00361@uafcseg.uucp (Jose Gomez) writes: >To compile ecu3, remove all malloc references in the makefile and in >ecu.h. Undefine the #define MALLOC_3X to #undef MALLOC_3X in ecu.h and >remove the -lmalloc from the $(LDFLAGS) declaration. >I have it running and works fine. Patch 5 is coming out soon. .---------------. | ECU 3 PATCH 5 | `---------------' 1. Fixed memory leak + bad free in feval_str(). 2. Some common types of procedure string operations have been made faster by redesign of the realloc_esd() function. 3. Octal integer constants were implemented; they may be denoted by prefixing them with "0o". Leading zero octal constants are not supported due to ECUs mutiple use of the same integer constant parser. I thought most people would rather %itos("0200") return 200(10) than 128(10). 4. Many line drivers, particularly FAS, will wait a process closing a tty line until all characters queued for output have been sent. When closing a tty line that has been permanently XOFF'ed by a dead remote system or a noisy XOFF, this can result in a hang. Now, a SIGALRM/setjmp scheme is used to recover from this condition and flush line output before reattempting the close. Five seconds are allowed for the draining to occur. 5. Multiscreen normal and reverse foreground and background colors in effect at the beginning of ecu execution are restored when the program terminates (thanks to staceyc@sco for illuminating the undocumented GIO_IOCTL ioctl; I've wanted to be able to do this for a long time). 6. lamy@glsys.in-berlin.de reported a core dump immediately after the one-line startup message under XENIX 286. Others have had the problem too. I am puzzled -- it is happening in get_home_dir(), which seems rather straightforward. A patch to avoid the problem is included: get the home directory from the environment variable HOME if possible rather than invoke libpwent.a. 7. An embarassing nroff problem was reported by slerner@eingedi. Patches are included for the nroff source. Mr. Lerner also pointed out an obsolete reference to samplproc.man. The models subdirectory contain many sample, even useful, procedures and samplproc.man was discarded a long time ago. If you do not have nroff or the spare CPU cycles to make the manual from nroff source, I'll email you one. Just mail me at wht@n4hgf.Mt-Park.GA.US or emory!n4hgf!wht and put "send ecu305 manual" in the subject line. If I get enough requests, I'll repost it to c.s.m as ecuman305. 8. A make bug in the trial ISC port was fixed in Make.ecu (thanks to jmd@p1so). 9. During non-curses file transfer, the cumulative elapsed time is reported once per complete line of 'RRRTRR..' status. 10. ache@hq.demos.su reported a bug in XENIX utmp handler code. This is a fix for most XENIX systems, but define OLD_WAY in utmpstat.c if you have problems. 11. Sometimes upon adding a new phone entry, it would be marked for redial upon creation. This has been fixed by using calloc() instead malloc(). 12. We seem to be bumping some limits on 286 systems. I added more code to handle more core dumps reported by lamy@glsys.in-berlin.de: somehow newwin() managed to return zero (probably memory alloc fail). The patch to ecuwinutil.c won't fix the problem, but will at least report it and die gracefully, rather than splatter on the pavement with a core dump. Please write me with bug reports and crash info: see below. .--------------------. | NOTES and REQUESTS | `--------------------' 1. I do not have any XENIX system to test with. It is a tribute to SCO orthogonality that 35,000+ line program works so well across 2 CPUs and two operating systems of many minor releases and many versions of development systems. I continue to point this out when I hear SCO-bashers do their thing. However, since s**t does happen, if you are reporting a problem that results in a core dump, please run the following for me (I would APPRECIATE it): % cd where ecu is % ./ecu ----- kaboom ----- % ^Jstty sane^J if needed (probably) % adb ./ecu |& tee to.wht * $x * $c * $r * $q If you are a really industrious one and have sdb and compiled with -g, % sdb ./ecu |& tee -a to.wht % t % q Then % mail -s 'ecu 3.xx core dump' wht@n4hgf.mt-park.ga.us < to.wht 2. ache@hq.demos.su has made some excellent suggestions which would enhance the line handling/choosing algorithms. They will require a change in the phone directory. He suggests I interpret old directory formats, while writing only new ones. The changes are far reaching and I haven't the time now to plug them in, but kudos to him and I'll try to find A Round Tuit. ----------------------------------------------------------------------- Warren Tucker, TuckerWare gatech!n4hgf!wht or wht@n4hgf.Mt-Park.GA.US Many [Nobel physics] prizes have been given to people for telling us the universe is not as simple as we thought it was. -Stephen Hawking in A Brief History of Time In computing, there are no such prizes. -me Newsgroups: gomez@enuxha.eas.asu.edu Subject: Re: Help - Compiling ecu3 Summary: Expires: References: <4396@ubbs-nh.MV.COM> <1991Jan13.040319.7912@nshore.uucp> <5850@uafhp.uark.edu> Sender: Reply-To: wht@n4hgf.Mt-Park.GA.US (Warren Tucker) Followup-To: Distribution: na Organization: Amateur Radio Station N4HGF Keywords: In article <5850@uafhp.uark.edu> bbs00361@uafcseg.uucp (Jose Gomez) writes: >To compile ecu3, remove all malloc references in the makefile and in >ecu.h. Undefine the #define MALLOC_3X to #undef MALLOC_3X in ecu.h and >remove the -lmalloc from the $(LDFLAGS) declaration. >I have it running and works fine. Patch 5 is coming out soon. .---------------. | ECU 3 PATCH 5 | `---------------' 1. Fixed memory leak + bad free in feval_str(). 2. Some common types of procedure string operations have been made faster by redesign of the realloc_esd() function. 3. Octal integer constants were implemented; they may be denoted by prefixing them with "0o". Leading zero octal constants are not supported due to ECUs mutiple use of the same integer constant parser. I thought most people would rather %itos("0200") return 200(10) than 128(10). 4. Many line drivers, particularly FAS, will wait a process closing a tty line until all characters queued for output have been sent. When closing a tty line that has been permanently XOFF'ed by a dead remote system or a noisy XOFF, this can result in a hang. Now, a SIGALRM/setjmp scheme is used to recover from this condition and flush line output before reattempting the close. Five seconds are allowed for the draining to occur. 5. Multiscreen normal and reverse foreground and background colors in effect at the beginning of ecu execution are restored when the program terminates (thanks to staceyc@sco for illuminating the undocumented GIO_IOCTL ioctl; I've wanted to be able to do this for a long time). 6. lamy@glsys.in-berlin.de reported a core dump immediately after the one-line startup message under XENIX 286. Others have had the problem too. I am puzzled -- it is happening in get_home_dir(), which seems rather straightforward. A patch to avoid the problem is included: get the home directory from the environment variable HOME if possible rather than invoke libpwent.a. 7. An embarassing nroff problem was reported by slerner@eingedi. Patches are included for the nroff source. Mr. Lerner also pointed out an obsolete reference to samplproc.man. The models subdirectory contain many sample, even useful, procedures and samplproc.man was discarded a long time ago. If you do not have nroff or the spare CPU cycles to make the manual from nroff source, I'll email you one. Just mail me at wht@n4hgf.Mt-Park.GA.US or emory!n4hgf!wht and put "send ecu305 manual" in the subject line. If I get enough requests, I'll repost it to c.s.m as ecuman305. 8. A make bug in the trial ISC port was fixed in Make.ecu (thanks to jmd@p1so). 9. During non-curses file transfer, the cumulative elapsed time is reported once per complete line of 'RRRTRR..' status. 10. ache@hq.demos.su reported a bug in XENIX utmp handler code. This is a fix for most XENIX systems, but define OLD_WAY in utmpstat.c if you have problems. 11. Sometimes upon adding a new phone entry, it would be marked for redial upon creation. This has been fixed by using calloc() instead malloc(). 12. We seem to be bumping some limits on 286 systems. I added more code to handle more core dumps reported by lamy@glsys.in-berlin.de: somehow newwin() managed to return zero (probably memory alloc fail). The patch to ecuwinutil.c won't fix the problem, but will at least report it and die gracefully, rather than splatter on the pavement with a core dump. Please write me with bug reports and crash info: see below. .--------------------. | NOTES and REQUESTS | `--------------------' 1. I do not have any XENIX system to test with. It is a tribute to SCO orthogonality that 35,000+ line program works so well across 2 CPUs and two operating systems of many minor releases and many versions of development systems. I continue to point this out when I hear SCO-bashers do their thing. However, since s**t does happen, if you are reporting a problem that results in a core dump, please run the following for me (I would APPRECIATE it): % cd where ecu is % ./ecu ----- kaboom ----- % ^Jstty sane^J if needed (probably) % adb ./ecu |& tee to.wht * $x * $c * $r * $q If you are a really industrious one and have sdb and compiled with -g, % sdb ./ecu |& tee -a to.wht % t % q Then % mail -s 'ecu 3.xx core dump' wht@n4hgf.mt-park.ga.us < to.wht 2. ache@hq.demos.su has made some excellent suggestions which would enhance the line handling/choosing algorithms. They will require a change in the phone directory. He suggests I interpret old directory formats, while writing only new ones. The changes are far reaching and I haven't the time now to plug them in, but kudos to him and I'll try to find A Round Tuit. ----------------------------------------------------------------------- Warren Tucker, TuckerWare gatech!n4hgf!wht or wht@n4hgf.Mt-Park.GA.US Many [Nobel physics] prizes have been given to people for telling us the universe is not as simple as we thought it was. -Stephen Hawking in A Brief History of Time In computing, there are no such prizes. -me