postmaster@uunet.uu.net (06/17/88)
Reason: local mail handler complained as follows
jmail: HuwR -- unknown user or mailbox
-------- rejected letter ---------
Via: 00004001015218/UCL-CS.FTP.MAIL ; 16 Jun 1988 20:36:13 GMT
Received: from NSS.CS.UCL.AC.UK by NSS.Cs.Ucl.AC.UK via List-Channel
id aa05399; 16 Jun 88 16:36 BST
Received: from sem.brl.mil by NSS.Cs.Ucl.AC.UK via Satnet with SMTP
id aa05313; 16 Jun 88 16:26 BST
Received: from SEM.BRL.MIL by SEM.brl.ARPA id ab12525; 14 Jun 88 2:59 EDT
Received: from sem.brl.mil by SEM.BRL.ARPA id aa12521; 14 Jun 88 2:45 EDT
Date: Tue, 14 Jun 88 02:45:54 EST
From: The Moderator (Mike Muuss) <Info-Unix-Request@arpa.brl>
To: INFO-UNIX@arpa.brl
Reply-To: INFO-UNIX@arpa.brl
Subject: INFO-UNIX Digest V5#068
Message-ID: <8806140246.aa12521@SEM.BRL.ARPA>
Sender: info-unix-request@uk.ac.ucl.cs.nss
INFO-UNIX Digest Tue, 14 Jun 1988 V5#068
Today's Topics:
Re: Trouble with floor ()
Cartridge Tape Holders
Re: TeX->nroff Conversion Package
A 'vi' question: the answer
afio
Re: HDB UUCP for SCO Xenix
Re: Trouble with floor ()
Re: Software performance
Re: questions regarding databases created with dbm and ndbm routines
Re: Core files ...
Re: VT100 emulators
-----------------------------------------------------------------
From: Andrew Klossner <andrew@frip.gwd.tek.com>
Subject: Re: Trouble with floor ()
Date: 12 Jun 88 02:42:54 GMT
Sender: andrew@tekecs.tek.com
To: info-unix@brl-sem.arpa
> I'm having trouble with ceil () & floor ().
> This program returns the correct values on the first loop only.
> On successive passes, floor() returns the same result as ceil().
> I'm using a Tektronix 4301 (68020, UTEK & BSD4.3,
> GreenHills C compiler.)
>
> #include <math.h>
> main () {
> double value, ceil (), floor ();
>
> for (;;) {
> printf ("\nInput value: ");
> scanf ("%lf", &value);
> printf ("\nCeiling: %lf, Floor: %lf\n", ceil (value), floor (value));
> }
> }
>
> Anyone else having this problem on other hardware?
Blush. This isn't a hardware problem; it's a bug in the Tektronix
implementation of libm. The rest of you 68881 users can breathe easy.
Thanks for pointing out this bug. It will be corrected in an upcoming
software release. In the meantime, you can work around by putting the
following into a shell script and executing it as root:
--------------- Cut here
chdir /tmp
cat >floor.s <<"EOF"
.globl _floor
_floor:
fmove.l fpcr,d0
move.l d0,d1
and.l #0xFFFFFFF0,d0
or.l #0x00000020,d0
fmove.l d0,fpcr
fint.d 4(a7),fp0
fmove.l d1,fpcr
rts
EOF
cat >ceil.s <<"EOF"
.globl _ceil
_ceil:
fmove.l fpcr,d0
move.l d0,d1
and.l #0xFFFFFFF0,d0
or.l #0x00000030,d0
fmove.l d0,fpcr
fint.d 4(a7),fp0
fmove.l d1,fpcr
rts
EOF
cat >rint.s <<"EOF"
.globl _rint
_rint:
fmove.l fpcr,d0
move.l d0,d1
and.l #0xFFFFFFF0,d0
fmove.l d0,fpcr
fint.d 4(a7),fp0
fmove.l d1,fpcr
rts
EOF
as -68020 -M floor.s
as -68020 -M ceil.s
as -68020 -M rint.s
mv /usr/lib/libm.a /usr/lib/libm.a.OLD
cp /usr/lib/libm.a.OLD /usr/lib/libm.a
ar r /usr/lib/libm.a floor.o ceil.o rint.o
rm floor.s floor.o ceil.s ceil.o rint.s rint.o
--------------- Cut here
If you use profiled libraries, make similar changes to
/usr/lib/libm_p.a.
-=- Andrew Klossner (decvax!tektronix!tekecs!andrew) [UUCP]
(andrew%tekecs.tek.com@relay.cs.net) [ARPA]
-----------------------------
From: Steve Simmons <simmons@applga.uucp>
Subject: Cartridge Tape Holders
Date: 9 Jun 88 16:36:33 GMT
Keywords: 8x11 3ring need supplier dc300 dc600
To: info-unix@brl-sem.arpa
I know this isn't the best newsgroup for this, but everything else
has failed:
We're looking for a data processing product which ought to exist but
we cannot find. It's a holder for a DC-300/DC-600 sized cartridge
which will let you put the cartridge into a 3-ring binder for storage.
We get a fair amount of software delivered in this medium, and would
like to be able to put the cartridge into our library in the same
binder with the install manual.
Ideally this holder would have space for two cartridges like so:
Front View Side View
+----------------------------+ |
| +--------------------------+ +---+
|O| | | |
| | | | |
| | Cartridge 1 | | |
| | | | |
| | | | |
| | | | |
| | | | |
+O|--------------------------+ +---+
| +--------------------------+ +---+
| | | | |
| | | | |
| | Cartridge 2 | | |
| | | | |
| | | | |
| | | | |
|O| | | |
| | | | |
+----------------------------+ +---+
The back should be stiff plastic, the fronts could be stiff or soft pockets.
It should close completely (dust) and be anti-static.
With the constant increase in use of cartridge tapes, the *ought* to be
somebody making this! If there are any plastics manufacturers out there
reading, you can *have* the idea. Just send me a complimentary case :-).
--
+- Steve Simmons UNIX Systems Mgr. Schlumberger CAD/CAM -+
+ simmons@applga.uucp ...umix!applga!simmons +
+- "Opinions expressed are all my own, etc, etc, etc, etc, etc, etc, etc." -+
-----------------------------
From: Chris Torek <chris@mimsy.uucp>
Subject: Re: TeX->nroff Conversion Package
Date: 13 Jun 88 19:41:33 GMT
To: info-unix@brl-sem.arpa
In article <16150@brl-adm.ARPA> JPLILER@simtel20.arpa (John R. Pliler) writes:
>... I am looking for a conversion package to convert TeX documents into
>nroff format.
I would say that it cannot be done, except that nroff and TeX both
contain programming languages. Certainly it is not easy (even the
other direction is quite difficult).
>Even better, where can I obtain sources for TeX?
The program is effectively in the public domain (although the sources
are in fact copyright by D. E. Knuth). You need to be more specific;
TeX is available on everything from IBM PCs to Crays (at least if they
are running Unix: I believe there is a SysV port that should run on
them). Unix-flavoured TeX is available from the University of Washington;
contact Pierre MacKay <mackay@washington.edu> (or uw-beaver!mackay,
or mackay@umpqua.cs.washington.edu for those ARPA mailers without MX).
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
-----------------------------
From: Lloyd Zusman <ljz@fxgrp.uucp>
Subject: A 'vi' question: the answer
Date: 13 Jun 88 21:31:11 GMT
To: info-unix@brl-sem.arpa
The other day I posed a question about 'vi': what is the syntax of the
commands you can embed near the top of your file which can be used
to set tab stops?
I got several prompt replies, for which I am grateful. Thanks to all
of you.
Here's how to do what I asked:
The commands can reside anywhere in the first or last 5 lines of the
file that is being edited. They are of the form
<W>ex:<commands>:
or
<W>vi:<commands>:
where "<W>" is one or more whitespace (space or tab) and "<commands>"
are any commands you can issue from the ":" prompt. For example, to
set the tab stops to 13 characters, you could put the following stuff
within 5 lines of the top or bottom of your file:
<TAB>ex:set tabstop=13 shiftwidth=13:
(the 'shiftwidth' is there so that the "<<", ">>", and other shifting
commands will properly shift the text to a tab stop).
Of course, these lines should probably be contained within comments.
In many recent versions of 'vi', you must also set the 'modeline'
variable in order to enable the execution of these embedded commands.
I found that this only works by putting the following command into
.exrc or your EXINIT variable:
set modeline
(I couldn't get "vi '+set modeline' file" to work after not trying all
that hard). In these recent versions of 'vi', the default is 'set
nomodeline'.
Keep in mind that you can theoretically execute any commands that are
legal at the ":" prompt, not just tab setting commands.
Thanks again for all the quick replies.
--
Lloyd Zusman UUCP: ...!ames!fxgrp!ljz
Master Byte Software Internet: ljz%fx.com@ames.arc.nasa.gov
Los Gatos, California or try: fxgrp!ljz@ames.arc.nasa.gov
"We take things well in hand."
-----------------------------
From: J L Gomez <jlg@killer.uucp>
Subject: afio
Date: 13 Jun 88 22:02:04 GMT
Posted: Mon Jun 13 18:02:04 1988
To: info-unix@SEM.BRL.MIL
I've compiled the afio program but do not how to use it with the
UNIX-PC's floppy disk drive. I know how to use cpio but using the same
syntax with afio doesn't work. I need to know how to use the -i, -o, and
-t options of afio. The floppy disk drive name is /dev/rfp021.
Thanks for the help and info!
JL Gomez ..{ihnp4,ames}!killer!jlg
-----------------------------
From: Karl Denninger <karl@ddsw1.uucp>
Subject: Re: HDB UUCP for SCO Xenix
Date: 12 Jun 88 17:33:05 GMT
Keywords: Any 3rd party products?
To: info-unix@SEM.BRL.MIL
In article <11204@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes:
>In article <266@mjbtn.UUCP> root@mjbtn.UUCP (Mark J. Bailey) writes:
>| Well, with SCO uucp "as is" being brain-damaged, is there any third party
>| vendor out there that has ported HDB uucp for the '286 or '386 Xenix
>| packages?
>
>You can get the Trailblazer update from SCO for free. It isn't HDB
>(there are those of us who don't much care for it), but BREAK, PAUSE,
>and most of the needed escapes, such as \s \c \r \t work. I just
>switched to it two days ago because a new system wanted to autobaud on a
>mixture of CR and blanks. So far about 600 calls to 38 systems, still
>looks good.
It does work.
But it doesn't solve the character-at-a-time-slowdown problems. HDB uucp
would give much better performance when you've got many connections going
at once.
This is from first-hand experience, both here and with our feed. When our
feed site is going with two or three feeds at once (note: all outbound, and
they have a smart SIO board) the system gets unreasonably slow in
transmission. This is a Compaq 20Mhz 80386! No excuse at all for the
slowdown....
Another site with HDB running under SCO doesn't have this problem...
About all I can come up with is that the uucp is doing character-at-a-time
reads 'n' writes, which are nice and inefficient.... (without source, of
course, it's a guess, but probably a good one)
SCO Xenix *badly* needs a better uucp -- it (and the attendant problems with
terminal locking; we ended up doing our own ungetty/getty replacement!) is
the only part of the system that gets a "horrid" rating from us.... a
better uucp (ie: HDB or a late 4BSD version), complete with graded transfers
and *real* port interlocking done in the driver would make one hell of a
difference.
--
Karl Denninger (ihnp4!ddsw1!karl) Data: (312) 566-8912, Voice: (312) 566-8910
Macro Computer Solutions, Inc. "Quality solutions for work or play"
-----------------------------
From: The Beach Bum <haugj@pigs.uucp>
Subject: Re: Trouble with floor ()
Date: 13 Jun 88 21:46:23 GMT
Posted: Mon Jun 13 17:46:23 1988
To: info-unix@SEM.BRL.MIL
In article <1146@csustan.UUCP>, robert@csustan.UUCP (Robert Zeff) writes:
>
> I'm having trouble with ceil () & floor ().
> I'm using a Tektronix 4301 (68020, UTEK & BSD4.3,
> GreenHills C compiler.)
I'm running a Plexus P/95 (68020, System V, no 68881) and have the Greenhills
C compiler. We currently have 1.8.0 of the compiler. I haven't had any
trouble with the compiler. I compiled the example which was given and all
seems well.
- John.
--
The Beach Bum Big "D" Home for Wayward Hackers
UUCP: ...!killer!rpp386!jfh jfh@rpp386.uucp :SMAILERS
"You are in a twisty little maze of UUCP connections, all alike" -- fortune
-----------------------------
From: Malaclypse the Elder <dwc@homxc.uucp>
Subject: Re: Software performance
Date: 13 Jun 88 20:47:03 GMT
Posted: Mon Jun 13 16:47:03 1988
To: info-unix@brl-sem.arpa
> Check out the prof(1), and gprof(1) manuals, as well as the -p and -pg options
> of cc(1). That should give you what you want. I use gprof(1) personally.
>
see "inaccuracies in program profilers" by carl ponder and richard fateman
in software practice and experience, may 1988 to read about the limitations
of sampling based program profilers.
we are presenting a paper in the upcoming usenix conference on a new tool
that actually measures the elapsed time spent in a function rather than
using a sampling method. the paper is titled "CASPER the friendly daemon".
danny chen
ihnp4!homxc!dwc
-----------------------------
From: Chris Torek <chris@mimsy.uucp>
Subject: Re: questions regarding databases created with dbm and ndbm routines
Date: 14 Jun 88 03:27:19 GMT
To: info-unix@SEM.BRL.MIL
In article <16103@brl-adm.ARPA> sundar@wheaties.ai.mit.edu (Sundar
Narasimhan) writes:
>In the bugs section of the man pages [for dbm and ndbm] there is a
>comment indicating that these database files ... cannot be copied,
>tar'ed etc without filling the holes in them.
(Note that this `merely' wastes disk space. Also, it is not hard
to write a variant of `cp' that recreates holes.)
>Does this comment also apply to the dump program that does file system
>backups?
(ref V7/4BSD dump+restor[e]) No.
>Is [huge size] normal for ndbm databases?
The .pag files grow more or less by powers of two (imagine a tree with
the nodes numbered thus:
level tree hash mask (in binary)
0: 0 0000
1: 0 1 0001
2: 0 2 1 3 0011
3: 0 4 2 6 1 5 3 7 0111
------- -------
these these
hash to hash to
XXX0 XXX1
etc.). In a fresh database, you start at level 0, and to store an
item, you compute a hash number for it, then use no bits; all items
thus wind up in node 0. When node zero gets full, you `split' to level
1, recomputing the hash for each item in 0; you now use one bit to move
about half the data to node 1. If node 0 gets full again, you start
using two bits, and (since the things in it all end with a zero bit)
about half the items move to node 2; if node 1 gets full, you start
using two bits there and about half move to 3. It takes one bit per
node per level to remember what was split; this bit can be named by
(hash & mask) + mask. If you get (un)lucky with the hash function or
have enough data, the hashing could lean on one path through the tree,
making the apparent database size much larger.
The heart of the whole thing is the loop
hash = calculate_hash(item);
for (hash_mask = 0;; hash_mask = (hash_mask << 1) + 1) {
split_memory_bit = (hash & hash_mask) + hash_mask;
if (!bit_is_set(split_memory_bit, split_map_table))
break;
}
block = hash & hash_mask;
/* item is either in node `block' or not there at all */
/* read that node and search for it sequentially */
and, of course the hashing function. (Pseudocode for the split
routine is left as an exercise for the student :-) .)
In dbm and ndbm, tuples are stored as (key,datum) with `key' being the
item hashed above, and the key and its datum being stored next to each
other. The format of each node (block) is:
(s = sizeof(short), o_d => `offset of datum', o_k => `offset of _key')
0s: item_count (always even)
1s: offset of key 0
2s: offset of datum 0
3s: o_k_1
4s: o_d_1
...
(2n+1)s: o_k_n
(2n+2)s: o_d_n
<free space>
o_d_n: key n
o_k_n: datum n
...
o_d_0: datum 0
o_k_0: key 0
<end of .pag file block>
The length of any item can be computed as (offset of previous item) -
(offset of this item), where the `offset' of item number -1 is the block
size.
>How does this compare with databases created with dbm routines ?
In 4.3BSD, dbm is just ndbm with a single static `DBM' variable to hold
the (single) database. The 4.3BSD ndbm is a tweaked version of the V7
dbm, with the block sizes expanded. A larger block size means that
fewer splits occur (fewer tree levels used), and larger items can be
stored, but more items must be searched with each lookup. Fewer splits
is desirable to keep the split table size down; if the whole table fits
in memory, only one disk read ever needs to be done to find an item.
Larger items are desirable for the obvious reason.
>Although the size is large, the database is fast for lookups. However,
>I have a need for a search capability that may need to iterate over
>all the records. This tends to be slow. Is there any version of these
>routines that is faster than the std. routines in 4.2/3/Sun OS 3.5?
Not as far as I know. In my `multi-keyed' dbm, the format of a block
is different. Items are still hashed as always, but instead of storing
(key,datum) pairs, when an item is to be a key, I store its datum's
hash value and its datum's `in index' in the item's `out hash' and `out
index'; when an item is to be a datum, it acquires an `in index'.
(Actually, all items get in indices always.) Each item also has a link
(reference) count since it might be used as a datum by any number of
keys. But the loop I described as the heart of the algorithm must run
twice---once to hash and find the key, and again to find the datum
given the key's `out hash' and `out index'---so lookups generally take
two disk reads instead of one.
>One last question, regarding reclamation of file space upon deletion.
>Why is this hard to do?
You would need to `un-split' blocks. That would not be hard, but
without `ftruncate' you could never shorten the file, and even with
ftruncate, you cannot get the kernel to replace a disk block with a
hole, so it really would not save space after all.
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
-----------------------------
From: Chris Torek <chris@mimsy.uucp>
Subject: Re: Core files ...
Date: 14 Jun 88 03:31:03 GMT
Keywords: core
To: info-unix@brl-sem.arpa
In article <790@scubed.UUCP> warner@scubed.UUCP (Ken Warner) writes:
>Is there a way to run a core file?
It cannot be done portably, but with certain restrictions, it can
almost always be done.
>I know most Lisp implementations allow you to save an image. Would anyone
>know have any insight into how that is done? I'm on a Sun under OS 3.5
Franz does it unportably: it writes its text image, then its data. It
puts an appropriate executable header on the front, and adds a symbol
table. When it starts up it checks to see if it was doing something
special before.
Note that file descriptors are generally lost, and that saving the
environment is sometimes wrong. Generally, the best way to save state
is to save the important stuff instead of blindly writing everything.
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
-----------------------------
From: Dave Haynie <daveh@cbmvax.uucp>
Subject: Re: VT100 emulators
Date: 13 Jun 88 22:24:51 GMT
To: info-unix@brl-sem.arpa
in article <3014@ihlpe.ATT.COM>, stuart@ihlpe.ATT.COM (S. D. Ericson) says:
> Keywords: VT100, emulation
> Summary: Cheap Toshiba Portable
> Xref: cbmvax comp.sys.misc:1618 comp.unix.questions:8368
> In article <10383@udenva.cair.du.edu>, R. Neitzel writes:
>> Due to a small windfall, I am now able to afford a small computer.
>> I want to be able to use the system to access the UNIX machines at
>> school. My budget limit is about $800-900, so I figure on looking at
>> the following systems: C64, C128, Apple IIx. My question is: what
>> VT100 emulations are available if any for these machines? If not a
>> VT100, what about other common terminals? Will they give true 80x24
>> lines?
The C64 won't give you a real 80 column display; it's only capable of doing
320x200 pixels, so you're stuck with a maximum of 40x25 using 8x8 characters,
though some terminal emulators give you 80x24 or 80x25 by creating very thin
characters. Not something I'd recommend for long term use.
The C128 has a built-in 80 column display that'll give you nominally 80x25
characters using an 8x8 cell. It hooks up to a standard IBM style RGBI
(4 bit digital --> 16 colors) color monitor or a monochrome composite monitor.
Some folks have managed to squeeze 760x600 or so pixels out of the C128 80 column
display in interlace mode, but that's too flickery for normal telecom use.
The C128 and C64 have the advantage of being able to use the dirt cheap Commodore
1670 1200 baud modem. This comes with a VT100 emulator for the C128 which isn't
perfect, but is currently being fixed at Commodore. The disadvantage of
either machine is that they don't work well beyond 1200 baud; the C128 might
do 2400 OK with the right terminal emulator, but the C64 can just about handle 1200.
I don't know much about the Apple II series these days, though you can get real
close to an Amiga500 + Monitor + Modem for around $1000. It can use just about
any monitor and any RS-232 modem. There are at least two freely-redistributable
VT100 emulators which are good enough to run GNUmacs, uEmacs, VN, and CCalc
without a hitch. I think the one called HandShake passes the complete VT100
test suite that was posted hereabouts a year or two ago. All Amigas can give
you a fair 80-90 column display, which 25 lines non-interlaced or 50 lines
interlaced (some folks don't mind this interlace flicker, some do). There are also
more sophisticated and free telecom tools for the Amiga, like a VT200 emulator
and some serial-line networking tools.
--
Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests"
{ihnp4|uunet|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy
"I can't relax, 'cause I'm a Boinger!"
-----------------------------
End of INFO-UNIX Digest
***********************postmaster@uunet.uu.net (06/19/88)
Reason: local mail handler complained as follows
jmail: HuwR -- unknown user or mailbox
-------- rejected letter ---------
Via: 00004001015218/UCL-CS.FTP.MAIL ; 19 Jun 1988 11:20:40 GMT
Received: from NSS.CS.UCL.AC.UK by NSS.Cs.Ucl.AC.UK via List-Channel
id aa02260; 19 Jun 88 11:29 BST
Received: from sem.brl.mil by NSS.Cs.Ucl.AC.UK via Satnet with SMTP
id aa02241; 19 Jun 88 11:24 BST
Received: from SEM.BRL.MIL by SEM.brl.ARPA id ab12525; 14 Jun 88 2:59 EDT
Received: from sem.brl.mil by SEM.BRL.ARPA id aa12521; 14 Jun 88 2:45 EDT
Date: Tue, 14 Jun 88 02:45:54 EST
From: The Moderator (Mike Muuss) <Info-Unix-Request@arpa.brl>
To: INFO-UNIX@arpa.brl
Reply-To: INFO-UNIX@arpa.brl
Subject: INFO-UNIX Digest V5#068
Message-ID: <8806140246.aa12521@SEM.BRL.ARPA>
Sender: info-unix-request@uk.ac.ucl.cs.nss
INFO-UNIX Digest Tue, 14 Jun 1988 V5#068
Today's Topics:
Re: Trouble with floor ()
Cartridge Tape Holders
Re: TeX->nroff Conversion Package
A 'vi' question: the answer
afio
Re: HDB UUCP for SCO Xenix
Re: Trouble with floor ()
Re: Software performance
Re: questions regarding databases created with dbm and ndbm routines
Re: Core files ...
Re: VT100 emulators
-----------------------------------------------------------------
From: Andrew Klossner <andrew@frip.gwd.tek.com>
Subject: Re: Trouble with floor ()
Date: 12 Jun 88 02:42:54 GMT
Sender: andrew@tekecs.tek.com
To: info-unix@brl-sem.arpa
> I'm having trouble with ceil () & floor ().
> This program returns the correct values on the first loop only.
> On successive passes, floor() returns the same result as ceil().
> I'm using a Tektronix 4301 (68020, UTEK & BSD4.3,
> GreenHills C compiler.)
>
> #include <math.h>
> main () {
> double value, ceil (), floor ();
>
> for (;;) {
> printf ("\nInput value: ");
> scanf ("%lf", &value);
> printf ("\nCeiling: %lf, Floor: %lf\n", ceil (value), floor (value));
> }
> }
>
> Anyone else having this problem on other hardware?
Blush. This isn't a hardware problem; it's a bug in the Tektronix
implementation of libm. The rest of you 68881 users can breathe easy.
Thanks for pointing out this bug. It will be corrected in an upcoming
software release. In the meantime, you can work around by putting the
following into a shell script and executing it as root:
--------------- Cut here
chdir /tmp
cat >floor.s <<"EOF"
.globl _floor
_floor:
fmove.l fpcr,d0
move.l d0,d1
and.l #0xFFFFFFF0,d0
or.l #0x00000020,d0
fmove.l d0,fpcr
fint.d 4(a7),fp0
fmove.l d1,fpcr
rts
EOF
cat >ceil.s <<"EOF"
.globl _ceil
_ceil:
fmove.l fpcr,d0
move.l d0,d1
and.l #0xFFFFFFF0,d0
or.l #0x00000030,d0
fmove.l d0,fpcr
fint.d 4(a7),fp0
fmove.l d1,fpcr
rts
EOF
cat >rint.s <<"EOF"
.globl _rint
_rint:
fmove.l fpcr,d0
move.l d0,d1
and.l #0xFFFFFFF0,d0
fmove.l d0,fpcr
fint.d 4(a7),fp0
fmove.l d1,fpcr
rts
EOF
as -68020 -M floor.s
as -68020 -M ceil.s
as -68020 -M rint.s
mv /usr/lib/libm.a /usr/lib/libm.a.OLD
cp /usr/lib/libm.a.OLD /usr/lib/libm.a
ar r /usr/lib/libm.a floor.o ceil.o rint.o
rm floor.s floor.o ceil.s ceil.o rint.s rint.o
--------------- Cut here
If you use profiled libraries, make similar changes to
/usr/lib/libm_p.a.
-=- Andrew Klossner (decvax!tektronix!tekecs!andrew) [UUCP]
(andrew%tekecs.tek.com@relay.cs.net) [ARPA]
-----------------------------
From: Steve Simmons <simmons@applga.uucp>
Subject: Cartridge Tape Holders
Date: 9 Jun 88 16:36:33 GMT
Keywords: 8x11 3ring need supplier dc300 dc600
To: info-unix@brl-sem.arpa
I know this isn't the best newsgroup for this, but everything else
has failed:
We're looking for a data processing product which ought to exist but
we cannot find. It's a holder for a DC-300/DC-600 sized cartridge
which will let you put the cartridge into a 3-ring binder for storage.
We get a fair amount of software delivered in this medium, and would
like to be able to put the cartridge into our library in the same
binder with the install manual.
Ideally this holder would have space for two cartridges like so:
Front View Side View
+----------------------------+ |
| +--------------------------+ +---+
|O| | | |
| | | | |
| | Cartridge 1 | | |
| | | | |
| | | | |
| | | | |
| | | | |
+O|--------------------------+ +---+
| +--------------------------+ +---+
| | | | |
| | | | |
| | Cartridge 2 | | |
| | | | |
| | | | |
| | | | |
|O| | | |
| | | | |
+----------------------------+ +---+
The back should be stiff plastic, the fronts could be stiff or soft pockets.
It should close completely (dust) and be anti-static.
With the constant increase in use of cartridge tapes, the *ought* to be
somebody making this! If there are any plastics manufacturers out there
reading, you can *have* the idea. Just send me a complimentary case :-).
--
+- Steve Simmons UNIX Systems Mgr. Schlumberger CAD/CAM -+
+ simmons@applga.uucp ...umix!applga!simmons +
+- "Opinions expressed are all my own, etc, etc, etc, etc, etc, etc, etc." -+
-----------------------------
From: Chris Torek <chris@mimsy.uucp>
Subject: Re: TeX->nroff Conversion Package
Date: 13 Jun 88 19:41:33 GMT
To: info-unix@brl-sem.arpa
In article <16150@brl-adm.ARPA> JPLILER@simtel20.arpa (John R. Pliler) writes:
>... I am looking for a conversion package to convert TeX documents into
>nroff format.
I would say that it cannot be done, except that nroff and TeX both
contain programming languages. Certainly it is not easy (even the
other direction is quite difficult).
>Even better, where can I obtain sources for TeX?
The program is effectively in the public domain (although the sources
are in fact copyright by D. E. Knuth). You need to be more specific;
TeX is available on everything from IBM PCs to Crays (at least if they
are running Unix: I believe there is a SysV port that should run on
them). Unix-flavoured TeX is available from the University of Washington;
contact Pierre MacKay <mackay@washington.edu> (or uw-beaver!mackay,
or mackay@umpqua.cs.washington.edu for those ARPA mailers without MX).
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
-----------------------------
From: Lloyd Zusman <ljz@fxgrp.uucp>
Subject: A 'vi' question: the answer
Date: 13 Jun 88 21:31:11 GMT
To: info-unix@brl-sem.arpa
The other day I posed a question about 'vi': what is the syntax of the
commands you can embed near the top of your file which can be used
to set tab stops?
I got several prompt replies, for which I am grateful. Thanks to all
of you.
Here's how to do what I asked:
The commands can reside anywhere in the first or last 5 lines of the
file that is being edited. They are of the form
<W>ex:<commands>:
or
<W>vi:<commands>:
where "<W>" is one or more whitespace (space or tab) and "<commands>"
are any commands you can issue from the ":" prompt. For example, to
set the tab stops to 13 characters, you could put the following stuff
within 5 lines of the top or bottom of your file:
<TAB>ex:set tabstop=13 shiftwidth=13:
(the 'shiftwidth' is there so that the "<<", ">>", and other shifting
commands will properly shift the text to a tab stop).
Of course, these lines should probably be contained within comments.
In many recent versions of 'vi', you must also set the 'modeline'
variable in order to enable the execution of these embedded commands.
I found that this only works by putting the following command into
.exrc or your EXINIT variable:
set modeline
(I couldn't get "vi '+set modeline' file" to work after not trying all
that hard). In these recent versions of 'vi', the default is 'set
nomodeline'.
Keep in mind that you can theoretically execute any commands that are
legal at the ":" prompt, not just tab setting commands.
Thanks again for all the quick replies.
--
Lloyd Zusman UUCP: ...!ames!fxgrp!ljz
Master Byte Software Internet: ljz%fx.com@ames.arc.nasa.gov
Los Gatos, California or try: fxgrp!ljz@ames.arc.nasa.gov
"We take things well in hand."
-----------------------------
From: J L Gomez <jlg@killer.uucp>
Subject: afio
Date: 13 Jun 88 22:02:04 GMT
Posted: Mon Jun 13 18:02:04 1988
To: info-unix@SEM.BRL.MIL
I've compiled the afio program but do not how to use it with the
UNIX-PC's floppy disk drive. I know how to use cpio but using the same
syntax with afio doesn't work. I need to know how to use the -i, -o, and
-t options of afio. The floppy disk drive name is /dev/rfp021.
Thanks for the help and info!
JL Gomez ..{ihnp4,ames}!killer!jlg
-----------------------------
From: Karl Denninger <karl@ddsw1.uucp>
Subject: Re: HDB UUCP for SCO Xenix
Date: 12 Jun 88 17:33:05 GMT
Keywords: Any 3rd party products?
To: info-unix@SEM.BRL.MIL
In article <11204@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes:
>In article <266@mjbtn.UUCP> root@mjbtn.UUCP (Mark J. Bailey) writes:
>| Well, with SCO uucp "as is" being brain-damaged, is there any third party
>| vendor out there that has ported HDB uucp for the '286 or '386 Xenix
>| packages?
>
>You can get the Trailblazer update from SCO for free. It isn't HDB
>(there are those of us who don't much care for it), but BREAK, PAUSE,
>and most of the needed escapes, such as \s \c \r \t work. I just
>switched to it two days ago because a new system wanted to autobaud on a
>mixture of CR and blanks. So far about 600 calls to 38 systems, still
>looks good.
It does work.
But it doesn't solve the character-at-a-time-slowdown problems. HDB uucp
would give much better performance when you've got many connections going
at once.
This is from first-hand experience, both here and with our feed. When our
feed site is going with two or three feeds at once (note: all outbound, and
they have a smart SIO board) the system gets unreasonably slow in
transmission. This is a Compaq 20Mhz 80386! No excuse at all for the
slowdown....
Another site with HDB running under SCO doesn't have this problem...
About all I can come up with is that the uucp is doing character-at-a-time
reads 'n' writes, which are nice and inefficient.... (without source, of
course, it's a guess, but probably a good one)
SCO Xenix *badly* needs a better uucp -- it (and the attendant problems with
terminal locking; we ended up doing our own ungetty/getty replacement!) is
the only part of the system that gets a "horrid" rating from us.... a
better uucp (ie: HDB or a late 4BSD version), complete with graded transfers
and *real* port interlocking done in the driver would make one hell of a
difference.
--
Karl Denninger (ihnp4!ddsw1!karl) Data: (312) 566-8912, Voice: (312) 566-8910
Macro Computer Solutions, Inc. "Quality solutions for work or play"
-----------------------------
From: The Beach Bum <haugj@pigs.uucp>
Subject: Re: Trouble with floor ()
Date: 13 Jun 88 21:46:23 GMT
Posted: Mon Jun 13 17:46:23 1988
To: info-unix@SEM.BRL.MIL
In article <1146@csustan.UUCP>, robert@csustan.UUCP (Robert Zeff) writes:
>
> I'm having trouble with ceil () & floor ().
> I'm using a Tektronix 4301 (68020, UTEK & BSD4.3,
> GreenHills C compiler.)
I'm running a Plexus P/95 (68020, System V, no 68881) and have the Greenhills
C compiler. We currently have 1.8.0 of the compiler. I haven't had any
trouble with the compiler. I compiled the example which was given and all
seems well.
- John.
--
The Beach Bum Big "D" Home for Wayward Hackers
UUCP: ...!killer!rpp386!jfh jfh@rpp386.uucp :SMAILERS
"You are in a twisty little maze of UUCP connections, all alike" -- fortune
-----------------------------
From: Malaclypse the Elder <dwc@homxc.uucp>
Subject: Re: Software performance
Date: 13 Jun 88 20:47:03 GMT
Posted: Mon Jun 13 16:47:03 1988
To: info-unix@brl-sem.arpa
> Check out the prof(1), and gprof(1) manuals, as well as the -p and -pg options
> of cc(1). That should give you what you want. I use gprof(1) personally.
>
see "inaccuracies in program profilers" by carl ponder and richard fateman
in software practice and experience, may 1988 to read about the limitations
of sampling based program profilers.
we are presenting a paper in the upcoming usenix conference on a new tool
that actually measures the elapsed time spent in a function rather than
using a sampling method. the paper is titled "CASPER the friendly daemon".
danny chen
ihnp4!homxc!dwc
-----------------------------
From: Chris Torek <chris@mimsy.uucp>
Subject: Re: questions regarding databases created with dbm and ndbm routines
Date: 14 Jun 88 03:27:19 GMT
To: info-unix@SEM.BRL.MIL
In article <16103@brl-adm.ARPA> sundar@wheaties.ai.mit.edu (Sundar
Narasimhan) writes:
>In the bugs section of the man pages [for dbm and ndbm] there is a
>comment indicating that these database files ... cannot be copied,
>tar'ed etc without filling the holes in them.
(Note that this `merely' wastes disk space. Also, it is not hard
to write a variant of `cp' that recreates holes.)
>Does this comment also apply to the dump program that does file system
>backups?
(ref V7/4BSD dump+restor[e]) No.
>Is [huge size] normal for ndbm databases?
The .pag files grow more or less by powers of two (imagine a tree with
the nodes numbered thus:
level tree hash mask (in binary)
0: 0 0000
1: 0 1 0001
2: 0 2 1 3 0011
3: 0 4 2 6 1 5 3 7 0111
------- -------
these these
hash to hash to
XXX0 XXX1
etc.). In a fresh database, you start at level 0, and to store an
item, you compute a hash number for it, then use no bits; all items
thus wind up in node 0. When node zero gets full, you `split' to level
1, recomputing the hash for each item in 0; you now use one bit to move
about half the data to node 1. If node 0 gets full again, you start
using two bits, and (since the things in it all end with a zero bit)
about half the items move to node 2; if node 1 gets full, you start
using two bits there and about half move to 3. It takes one bit per
node per level to remember what was split; this bit can be named by
(hash & mask) + mask. If you get (un)lucky with the hash function or
have enough data, the hashing could lean on one path through the tree,
making the apparent database size much larger.
The heart of the whole thing is the loop
hash = calculate_hash(item);
for (hash_mask = 0;; hash_mask = (hash_mask << 1) + 1) {
split_memory_bit = (hash & hash_mask) + hash_mask;
if (!bit_is_set(split_memory_bit, split_map_table))
break;
}
block = hash & hash_mask;
/* item is either in node `block' or not there at all */
/* read that node and search for it sequentially */
and, of course the hashing function. (Pseudocode for the split
routine is left as an exercise for the student :-) .)
In dbm and ndbm, tuples are stored as (key,datum) with `key' being the
item hashed above, and the key and its datum being stored next to each
other. The format of each node (block) is:
(s = sizeof(short), o_d => `offset of datum', o_k => `offset of _key')
0s: item_count (always even)
1s: offset of key 0
2s: offset of datum 0
3s: o_k_1
4s: o_d_1
...
(2n+1)s: o_k_n
(2n+2)s: o_d_n
<free space>
o_d_n: key n
o_k_n: datum n
...
o_d_0: datum 0
o_k_0: key 0
<end of .pag file block>
The length of any item can be computed as (offset of previous item) -
(offset of this item), where the `offset' of item number -1 is the block
size.
>How does this compare with databases created with dbm routines ?
In 4.3BSD, dbm is just ndbm with a single static `DBM' variable to hold
the (single) database. The 4.3BSD ndbm is a tweaked version of the V7
dbm, with the block sizes expanded. A larger block size means that
fewer splits occur (fewer tree levels used), and larger items can be
stored, but more items must be searched with each lookup. Fewer splits
is desirable to keep the split table size down; if the whole table fits
in memory, only one disk read ever needs to be done to find an item.
Larger items are desirable for the obvious reason.
>Although the size is large, the database is fast for lookups. However,
>I have a need for a search capability that may need to iterate over
>all the records. This tends to be slow. Is there any version of these
>routines that is faster than the std. routines in 4.2/3/Sun OS 3.5?
Not as far as I know. In my `multi-keyed' dbm, the format of a block
is different. Items are still hashed as always, but instead of storing
(key,datum) pairs, when an item is to be a key, I store its datum's
hash value and its datum's `in index' in the item's `out hash' and `out
index'; when an item is to be a datum, it acquires an `in index'.
(Actually, all items get in indices always.) Each item also has a link
(reference) count since it might be used as a datum by any number of
keys. But the loop I described as the heart of the algorithm must run
twice---once to hash and find the key, and again to find the datum
given the key's `out hash' and `out index'---so lookups generally take
two disk reads instead of one.
>One last question, regarding reclamation of file space upon deletion.
>Why is this hard to do?
You would need to `un-split' blocks. That would not be hard, but
without `ftruncate' you could never shorten the file, and even with
ftruncate, you cannot get the kernel to replace a disk block with a
hole, so it really would not save space after all.
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
-----------------------------
From: Chris Torek <chris@mimsy.uucp>
Subject: Re: Core files ...
Date: 14 Jun 88 03:31:03 GMT
Keywords: core
To: info-unix@brl-sem.arpa
In article <790@scubed.UUCP> warner@scubed.UUCP (Ken Warner) writes:
>Is there a way to run a core file?
It cannot be done portably, but with certain restrictions, it can
almost always be done.
>I know most Lisp implementations allow you to save an image. Would anyone
>know have any insight into how that is done? I'm on a Sun under OS 3.5
Franz does it unportably: it writes its text image, then its data. It
puts an appropriate executable header on the front, and adds a symbol
table. When it starts up it checks to see if it was doing something
special before.
Note that file descriptors are generally lost, and that saving the
environment is sometimes wrong. Generally, the best way to save state
is to save the important stuff instead of blindly writing everything.
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
-----------------------------
From: Dave Haynie <daveh@cbmvax.uucp>
Subject: Re: VT100 emulators
Date: 13 Jun 88 22:24:51 GMT
To: info-unix@brl-sem.arpa
in article <3014@ihlpe.ATT.COM>, stuart@ihlpe.ATT.COM (S. D. Ericson) says:
> Keywords: VT100, emulation
> Summary: Cheap Toshiba Portable
> Xref: cbmvax comp.sys.misc:1618 comp.unix.questions:8368
> In article <10383@udenva.cair.du.edu>, R. Neitzel writes:
>> Due to a small windfall, I am now able to afford a small computer.
>> I want to be able to use the system to access the UNIX machines at
>> school. My budget limit is about $800-900, so I figure on looking at
>> the following systems: C64, C128, Apple IIx. My question is: what
>> VT100 emulations are available if any for these machines? If not a
>> VT100, what about other common terminals? Will they give true 80x24
>> lines?
The C64 won't give you a real 80 column display; it's only capable of doing
320x200 pixels, so you're stuck with a maximum of 40x25 using 8x8 characters,
though some terminal emulators give you 80x24 or 80x25 by creating very thin
characters. Not something I'd recommend for long term use.
The C128 has a built-in 80 column display that'll give you nominally 80x25
characters using an 8x8 cell. It hooks up to a standard IBM style RGBI
(4 bit digital --> 16 colors) color monitor or a monochrome composite monitor.
Some folks have managed to squeeze 760x600 or so pixels out of the C128 80 column
display in interlace mode, but that's too flickery for normal telecom use.
The C128 and C64 have the advantage of being able to use the dirt cheap Commodore
1670 1200 baud modem. This comes with a VT100 emulator for the C128 which isn't
perfect, but is currently being fixed at Commodore. The disadvantage of
either machine is that they don't work well beyond 1200 baud; the C128 might
do 2400 OK with the right terminal emulator, but the C64 can just about handle 1200.
I don't know much about the Apple II series these days, though you can get real
close to an Amiga500 + Monitor + Modem for around $1000. It can use just about
any monitor and any RS-232 modem. There are at least two freely-redistributable
VT100 emulators which are good enough to run GNUmacs, uEmacs, VN, and CCalc
without a hitch. I think the one called HandShake passes the complete VT100
test suite that was posted hereabouts a year or two ago. All Amigas can give
you a fair 80-90 column display, which 25 lines non-interlaced or 50 lines
interlaced (some folks don't mind this interlace flicker, some do). There are also
more sophisticated and free telecom tools for the Amiga, like a VT200 emulator
and some serial-line networking tools.
--
Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests"
{ihnp4|uunet|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy
"I can't relax, 'cause I'm a Boinger!"
-----------------------------
End of INFO-UNIX Digest
***********************