Sun-Spots Digest, v6n156
William LeFebvre
Sun-Spots-Request at RICE.EDU
Sat Jul 30 02:44:11 AEST 1988
SUN-SPOTS DIGEST Wednesday, 27 July 1988 Volume 6 : Issue 156
Today's Topics:
Re: malloc() - free() problems
Re: What means "-From hostname (sendmail)" in the process status
Re: Sun - IBM tape transfer
Misery loves company...
tools dying in general
PC-NFS rev 3.0 not much beter than 2.0
need help compiling emacs on Sun 3 OS 4.0
Differences between Sun and Apollo?
Franz Inc. makes available Allegro CL/GNU Emacs Interface (LONG)
Send contributions to: sun-spots at rice.edu
Send subscription add/delete requests to: sun-spots-request at rice.edu
Bitnet readers can subscribe directly with the CMS command:
TELL LISTSERV AT RICE SUBSCRIBE SUNSPOTS My Full Name
Recent backissues are available via anonymous FTP from "titan.rice.edu".
For volume X, issue Y, "get sun-spots/vXnY". They are also accessible
through the archive server: mail the request "send sun-spots vXnY" to
"archive-server at rice.edu" or mail the word "help" to the same address
for more information.
----------------------------------------------------------------------
Date: Fri, 15 Jul 88 19:34:55 EDT
From: Root Boy Jim <rbj at nav.icst.nbs.gov>
Subject: Re: malloc() - free() problems
> From: unido!bilbo.irb!tb at uunet.uu.net (Torsten Beyer)
> I have a little c-program which malloc()s 10 Mb, free()s these 10Mb,
> malloc()s another 10Mb and then waits for a key to be hit. If I do a ps
> aux on another terminal at this stage, ps tells me that my program has
> allocated 20 Mb of virtual storage....
> Am I wrong or is my OS wrong ?
Dunno. But I can pass along a few rumors. I have heard that malloc alloc's
in chunks of powers of two. Thus, a 10Mb request may get rounded up to
16Mb. In fact, an 8Mb request might also, because of the malloc overhead.
Since Sun and Ultrix seem to do different things, it would seem that they
are using different policys. It is also possible that ps is lying and that
you are really only using 10Mb.
A workaround might be to keep the original 10Mb chunk around, and flag it
as being free, so that when you need it again, you just take it and flag
it as being used. Good luck.
(Root Boy) Jim Cottrell <rbj at icst-cmr.arpa>
National Bureau of Standards
Flamer's Hotline: (301) 975-5688
The opinions expressed are solely my own
and do not reflect NBS policy or agreement
------------------------------
Date: Fri, 15 Jul 88 19:45:14 EDT
From: Root Boy Jim <rbj at nav.icst.nbs.gov>
Subject: Re: What means "-From hostname (sendmail)" in the process status
> From: mcvax!ecn!wim at uunet.uu.net (Wim Rijnsburger)
> I'm wondering:
> - what does it mean?
Sendmail typically changes it's `program name' (argv[0]) to be the current
SMTP command it is processing. I have seen HELO, RCPT, and DATA, as well
as the MAIL command, in caps, on a VAX. Sun may do it differently.
> - is it normal?
Well, if it isn't, at least it's widespread :-)
> - where can I read about it?
In the source.
> I have not found anything in the manuals. Is there anyone who can help me?
> Thanks in advance.
As wnl sez, it's not documented in TFM.
(Root Boy) Jim Cottrell <rbj at icst-cmr.arpa>
National Bureau of Standards
Flamer's Hotline: (301) 975-5688
The opinions expressed are solely my own
and do not reflect NBS policy or agreement
------------------------------
Date: Fri, 15 Jul 88 10:32:09 BST
From: Zdravko Podolski <mcvax!insignia!zdrav at uunet.uu.net>
Subject: Re: Sun - IBM tape transfer
One way is to use the 'dd' command documented in section 1 of the manual.
Something like:
dd if=input-file of=/dev/rmt0 conv=ibm,ucase,sync cbs=80 obs=X
(where X is the preferred block size on your IBM, maybe 80 will do)
If I remember correctly the ASCII to EBCDIC conversion is not fully
reversible, but it's close.
Zdravko Podolski, Insignia Solutions Ltd, Victoria House, 28-38 Desborough St,
High Wycombe, Bucks, HP11 2NF, England
Email: ...!ukc!insignia!zdrav or zdrav%insignia.uucp at ukc.ac.uk
Tel: +44 494 459426, Fax: +44 494 459540, Telex: 83389 BUSENT G
------------------------------
Date: Fri, 15 Jul 88 21:35:13 EDT
From: bzs%bu-cs.bu.edu at bu-it.bu.edu (Barry Shein)
Subject: Misery loves company...
The names have been changed to protect the guilty :-)
-Barry Shein, Boston University
> Return-Path: <Mailer-Daemon%xxx at Sun.COM>
> Date: Fri, 15 Jul 88 17:39:44 PDT
> From: Mailer-Daemon%xxx%Sun.COM at bu-it.BU.EDU (Mail Delivery Subsystem)
> Subject: Returned mail: unknown mailer error 127
> To: <bzs at bu-cs.bu.edu>
>
> ----- Transcript of session follows -----
> ld.so: swap space exhausted for mmap data of /usr/lib/libc.so.0.10
> 554 xxx at xxx... unknown mailer error 127
>
> ----- Unsent message follows -----
[[ I've had sun-spots digests returned for the same reason!! --wnl ]]
------------------------------
Date: Fri, 15 Jul 88 13:09:37 EDT
From: Harold Pomeranz <pomeranz at cs.swarthmore.edu>
Subject: tools dying in general
Since my original posting about cmdtool dying under OS 4.0, I've gotten a
lot of mail from people who have had other tools die on them under other
OS versions (mostly 3.5 and 4.0, though). My perusal of the dumped core
wasn't very informative-- but then I'm not a great dbx hacker. Anyway,
this is an open note to Sun to fix this problem. If they're going to
market SunView, they should make it more robust.
Hal Pomeranz
pomeranz at cs.swarthmore.edu
..rutgers!bpa!swatsun!pomeranz
------------------------------
Date: Fri, 15 Jul 88 23:05:47 EDT
From: "Greg Hullender" <novavax!proxftl!greg at bikini.cis.ufl.edu>
Subject: PC-NFS rev 3.0 not much beter than 2.0
This is an excerpt from a message sent to SUN a few minutes ago.
Fourteen months ago, I switched our company from DEC to SUN after ten
years as a DEC customer. A large part of the reason for selecting SUN
over any other vendor was PC-NFS.
Since we've had it, PC-NFS (ALL revisions) has been an unending source of
trouble. It seems to be the only product from SUN that doesn't work and
that SUN can't fix. We have reported problems with it from day one, and
it is not clear that it is better now than when we received it. Next
week, most of us will probably be forced to DEINSTALL revision 3.0,
because it effectively prevents you from using the PC as a terminal. (See
below).
Two days ago, I upgraded my PC from PC-NFS revision 2.0 to PC-NFS revision
3.0. At the same time, a few other people at Proximity also did the
upgrade, hoping it fixed a few of PC-NFS's problems.
We were pleased to discover that two old problems seem to be fixed: first,
control-S/control-Q flow control now seem to work. (They corrupted your
data before). Also, running the Microsoft C compiler with Telnet
installed no longer seems to crash the machine every few compiles. These
were welcome changes from before.
However, a new bug has been introduced that makes telnet very difficult to
use. Every few minutes, telnet stops echoing input for a minute or so.
In earlier revisions, this happened a few times a day, but with rev 3.0,
this is so frequent that the system becomes almost unusable. (Certainly
far worse than before). Anyway, this happens even when I have the 3/280
and the ethernet all to myself, so it has nothing to do with the load.
Another serious problem that is still pending is that groups (beyond your
main group) are not supported over PC-NFS. We make extensive use of
groups in product development, and continue to waste a lot of effort on PC
projects working around this defect.
In addition, a few annoying minor problems persist, and 3.0 introduced a
few new ones.
1) It still isn't possible to mount more than eight file systems, which
means we always have to leave some unmounted.
2) Telnet still doesn't let you get at anything like the number of
function keys you should be able to. The PC has many keys that do not
generate unique sequences under telnet; this makes a lot of things more
difficult than they ought to be.
3) Non-DOS filenames under PC-NFS are given random and CHANGING DOS
equivalents. We understand why this poses a problem, but the current
implementation is much worse than it needs to be. We've offered
suggestions before; we can again, if it would help.
4) On PC-AT's and better machines, telnet was sufficiently fast to
allow the PC to serve as a person's main terminal. PC-XT's (ordinary
8088-based PC's in general) are FAR slower -- too slow to be used this
way except in an emergency. MUCH slower than you'd guess from their
relative performance in anything else. Analysis of the ethernet traffic
shows significant packet retransmission when the only thing happening is
output to a single XT via telnet.
New with PC-NFS 3.0
1) The installation program treats "net join" the same as any other net
command, which causes it to put such commands into the NFS\NETWORK.BAT
file, which is executed BEFORE NFS\DRIVES.BAT. This guarantees that
any installation which uses the join command will no longer boot
properly, and requires manual editing of two batch files.
2) NFSCONF will not deal with join's in any way, shape or form, which
makes it effectively useless for our purposes, even though it is
otherwise very nice.
3) NFSRUN fails if it has to read the net command from a RAM disk.
Since this speeds up booting, most of our people had installed it this
way, but 3.0 won't work that way at all.
------------------------------
Date: Fri, 15 Jul 88 13:03:13 EDT
From: Harold Pomeranz <pomeranz at cs.swarthmore.edu>
Subject: need help compiling emacs on Sun 3 OS 4.0
I've been trying to compile emacs version 18.51.3 on our SUN 3's running
SunOS 4.0 and have encountered several problems. I'm tired and frustrated
and hope somebody has a quick fix.
The first problem occured while linking temacs. I got:
Undefined:
f68881_used
Consulting the SUN Floating Point Programmers' Guide, I discovered that
this was a "low technology trick" (read: kludge or hack) to prevent
modules compiled with the '-f68881' switch and the '-ffpa' switch from
being mixed. Now I can't see that ANY of the modules were compiled with
EITHER of these switches, but there we are. Anyway, the FPPG says that
you can get around this problem by creating an assembly language module
which defines 'f68881_used'. I did this, and temacs linked without any
other problems.
But MY problems didn't end there, immediately after linking temacs, the
makefile tries to create ../etc/DOC using a program called
../etc/make-docfile which had been created earlier in the make process.
However, it seems that make-docfile doesn't work. Frankly, I'm too
frustrated to hunt down the problem in the code myself. Here's the bomb:
swatsun# make
------------------------------
Date: Sat, 16 Jul 88 19:48:07 -0300
From: moj at cs.utu.fi (Matti Jokinen)
Subject: Differences between Sun and Apollo?
I plan to move a compiler from Sun-3 to Apollo workstation. I would be
grateful of any information about the differences between the Unix
versions of the two systems. Please reply by mail, I will post a summary
to the net.
Matti Jokinen UUCP: ...mcvax!tucos!moj
Department of Computer Science Internet: moj at cs.utu.fi
Unviversity of Turku
Finland
------------------------------
Date: Sat, 16 Jul 88 10:46:08 PDT
From: franz!akbar!layer at ucbarpa.berkeley.edu (Kevin Layer)
Subject: Franz Inc. makes available Allegro CL/GNU Emacs Interface
Introduction
------------
Franz Inc. is offering to the Lisp community version 1.2 of their
interface between Allegro Common Lisp (previously known as "Extended
Common Lisp") and GNU Emacs. This interface will also work between GNU
Emacs and Franz Lisp Opus 43 (the current release from Franz Inc.) or
Franz Lisp Opus 38 (the last public domain version).
The goal of this interface is to offer the Lisp programmer a tightly
integrated Lisp environment. The interface can be broken down into three
parts:
* Lisp editing modes for Common and Franz Lisp,
* Inferior modes for Common and Franz Lisp subprocesses, and
* TCP Common Lisp modes for socket communication with Common
Lisp.
The first two are available for both Common and Franz Lisp, but the third
feature, which enables the tight coupling of the environments, is only
available for Allegro CL. It uses multiprocessing in Allegro CL and UNIX
domain socket to communicate information between the GNU Emacs and Allegro
CL worlds.
The features of the interface are:
* enhanced subprocess modes, including
- file name completion
- an input ring to allow fetching of previously typed input
* macroexpansion of forms in a Lisp source file
* `find-tag' for Lisp functions (the Allegro CL world is
queried for the location of Lisp functions)
* who-calls: find all callers of a Lisp function
* Arglist, `describe' and function documentation are available
in Lisp source buffers (again, the information comes
dynamically from Allegro CL)
* automatic indentation of forms entered to an inferior Lisp
The interface is written entirely in GNU Emacs Lisp, with the exception of
a replacement for the standard `open-network-stream' in src/process.c.
Some of the advanced features use UNIX domain sockets and also use
features specific to the implementation of Allegro CL (multiprocessing).
The interface is fully documented on-line.
Ownership
---------
The Lisp/GNU Emacs interface is the property of Franz Incorporated. The
Emacs Lisp source code is distributed and the following notice is present
in all source files for which it applies:
;;
;; copyright (C) 1987, 1988 Franz Inc, Berkeley, Ca.
;;
;; The software, data and information contained herein are the property
;; of Franz, Inc.
;;
;; This file (or any derivation of it) may be distributed without
;; further permission from Franz Inc. as long as:
;;
;; * it is not part of a product for sale,
;; * no charge is made for the distribution, other than a tape
;; fee, and
;; * all copyright notices and this notice are preserved.
;;
;; If you have any comments or questions on this interface, please feel
;; free to contact Franz Inc. at
;; Franz Inc.
;; Attn: Kevin Layer
;; 1995 University Ave
;; Suite 275
;; Berkeley, CA 94704
;; (415) 548-3600
;; or
;; emacs-info%franz.uucp at Berkeley.EDU
;; ucbvax!franz!emacs-info
Some files contain GNU Emacs derived code, and those files contain the GNU
Emacs standard copyright notice.
Obtaining the Software
----------------------
To obtain version 1.2 of this interface either:
1) copy it from ucbarpa.berkeley.edu or ucbvax.berkeley.edu via FTP
(login `ftp', password your login name) from the directory
pub/fi/gnudist-1.2-tar.Z, or
2) send a check (sorry, no PO's accepted) in the amount of $50 for a
US address and $75 for a foreign address to Franz Inc. to the
following address:
Franz Inc.
Attn: Emacs/LISP Interface Request
1995 University Ave
Suite 275
Berkeley, CA 94704
Please specify the media (`tar' format only) which is one of:
* 1/2", 1600 bpi, 9-track
* 1/4", cartridge tape--specify the machine type (ie, TEK, SUN)
Future Work
-----------
Improvements to this interface will be made in the future, so to
facilitate the exchange of information about this and user's experiences,
questions and suggestions a mailing list will be created as a forum for
discussion on topics relating to this interface. If you would like to be
on this mailing list (local redistribution is encouraged), please drop me
a note. If you have trouble with one of the addresses below, try one of:
layer at Berkeley.EDU
-or-
ucbvax!layer
D. Kevin Layer Franz Inc.
layer%franz.uucp at Berkeley.EDU 1995 University Avenue, Suite 275
ucbvax!franz!layer Berkeley, CA 94704
(415) 548-3600, FAX: (415) 548-8253
------------------------------
End of SUN-Spots Digest
***********************
More information about the Comp.sys.sun
mailing list