HDTenEightyP/NetNews huggingface dataset:
From: ellis@nova.gmi.edu (Stew Ellis)
Subject: Re: Jove for System V.4
Organization: GMI Engineering&Management Institute, Flint, MI
Date: Fri, 14 Aug 1992 23:56:22 GMT

andre@targon.UUCP (Andre van Dalen) writes:

>Hello netters,

>I have jove 4.14 running on Unix, Dos and OS/2 but now we get
>new machines that have unix system V.4 on them and jove will
>not build on those machines.

>Does anybody know of a version of Jove that will build and run
>on SV.4 machines? Or is somebody in the process of porting it?

>-- 
>The mail|    AAA         DDDD  It's not the kill, but the thrill of the chase.
>demon...|   AA AAvv   vvDD  DD        Ketchup is a vegetable.
>hits!.@&|  AAAAAAAvv vvDD  DD                    {nixbur|nixtor}!adalen.via
>--more--| AAA   AAAvvvDDDDDD    Andre van Dalen, uunet!sun4nl!targon!andre

Someone at U. of Toronto has done it 4.14.6 or 7.  The machine is
relay.cs.toronto.edu, cd pub/moraes.  

It is a SYSV version with a few shortcomings compared to BSD.  There is a
problem with signal handling and the setjmp longjmp that caused problems for
me.  I was about ready to pull out my hair.  It does support interactive
shell buffers.  Good luck.

--
--                                                        ___________________
  R.Stewart(Stew) Ellis, Assoc.Prof., (Off)313-762-9765  /   _____  ______ 
  Humanities & Social Science,  GMI Eng.& Mgmt. Inst.   /        / /  /  / /
  Flint, MI 48504      ellis@nova.gmi.edu              /________/ /  /  / /
Newsgroups: comp.editors
From: sjreeves@eng.auburn.edu (Stan Reeves)
Newsgroups: comp.editors
Subject: Regular Expression Question
Date: 12 Aug 92 12:54:06 GMT
Organization: Auburn University Engineering


I need to construct a regular expression that locates all words without
an "@".  I've exhausted all my own ideas and was wondering if I could
draw on the expertise of this group.


--
Stan Reeves
Auburn University, Department of Electrical Engineering, Auburn, AL  36849
INTERNET: sjreeves@eng.auburn.edu
Newsgroups: comp.editors
From: Richard.Kooijman@dnpap.et.tudelft.nl (Richard Kooijman DNPAP)
Subject: Re: X Editors
Organization: Delft University of Technology, Dept. of Electrical Engineering
Date: Sat, 15 Aug 1992 08:04:33 GMT

rahardj@ccu.umanitoba.ca (Budi Rahardjo) writes:

>In <4737@balrog.ctron.com> geremia@legolas (Peter P. Geremia) writes:
>>	I have been scouring the net for a good X based 
>>programmers editor that is not VI or EMACS or BRIEF based...
>>	any one know of one?????

>Well, here's a start :
>- OpenWindows' TextEdit
>- mxedit (tk/tcl based)
>- xedit
>- Not sure whether 'fpted' could be classified as X based editor
>  [You can position the cursor with the mouse under xterm]
>- probably there are others (maybe wafe-based editor ?)


I don't know anything of mxedit, but here we have 'axe' installed and for
a X based editor it is not that bad. Better than textedit and xedit, anyway.

Can be ftp'ed from our site dutepp0.et.tudelft.nl, /pub/Unix/Editors.

Richard.
--
-- ir. Richard Kooijman ------------------ Email: R.Kooijman@ET.TUDelft.NL --
-- Intelligent Network Management Project (INEMA) ---------------------------
-- CARDIT, Delft University of Technology ------------ Tel: (31)-15-786209 --
-- P.O.Box 5031, 2600 GA Delft, The Netherlands ------ Fax: (31)-15-784898 --
From: ant@mks.com (Anthony Howe)
Newsgroups: comp.editors
Subject: Q: Line # addressing using buffer gap.
Keywords: Finseth, Craft, Of, Text, Editing, buffer, gap
Date: 18 Aug 92 13:27:55 GMT
Organization: Mortice Kern Systems Inc., Waterloo, Ontario, CANADA


Is there a reasonably fast technique, given a Buffer Gap structure,
for finding line number X.  Currently, AE, just performs linear scans
for <newline> marks when performing cursor motion, since the
assumption is that the majority of movement is localized.

Being able to find the start of a line quickly would help in
implementing a Goto-Line command and possibly a better screen update
manager.

I think I read somewhere about the idea of keeping a table of buffer
indexes that correspond to each line.  Then as you insert or delete
characters in a given line, all the indexes above line X would need to
be updated.  This idea strikes me as being very ugly since the time to
update the indexes is dependant on which line you are currently at.
If you were at the end of the file, this would be very quick, but if
you were at the beginning of the file, this time maybe unacceptable
for large files.

Ideas anyone?

-ant
-- 
ant@mks.com                                                   Anthony C Howe 
Mortice Kern Systems Inc. 35 King St. N., Waterloo, Ontario, Canada, N2J 6W9
"Nice legs.  For a human that is." - Worf (Q-pid)
Newsgroups: comp.editors
From: wittesa@reks.uia.ac.be (Willy Wittesaele)
Subject: Editor mined (Unix, VMS, MSDOS) available by
Organization: U.I.A.
Date: Fri, 21 Aug 1992 21:14:38 GMT

hello ,

I have tried to compile mined under SCO 3.2.2. but till now
no success.

please let me know via e-mail or via this news if someone
succeeded.

willy

wittesa@reks.uia.ac.be
From: etse@soda.Berkeley.EDU (Eric Tse)
Newsgroups: comp.editors
Subject: jove for AIX 3.2 on RISC 6000
Date: 18 Aug 1992 06:53:25 GMT
Organization: U.C. Berkeley, CS Undergraduate Association
Distribution: world
NNTP-Posting-Host: soda.berkeley.edu

Hi,
	Anyone get jove running on AIX 3.2? I really would like
if someone can give me a patch to the jove release so I can compile
sucessfully on AIX 3.2. Better still, can I have the executable also?:)
	Thanks to any leads....

Eric
Newsgroups: comp.internet.library
From: takefuji@donald.EEAP.CWRU.Edu (Yoshiyasu Takefuji)
Subject: letters.8-20-92
Organization: Dept. of Electrical Engineering, CWRU, Cleve. OH
Date: Thu, 20 Aug 92 20:20:56 GMT

From concert!samba.oit.unc.edu!usenet@concert.net Thu Aug 13 00:11:37 1992
From: lambada.oit.unc.edu!G.t..Jeffries@concert.net (G.t. Jeffries)
Subject: Dial-up SC


Does anyone have the FTP address and IP number of a location that retains
dial-up numbers (via modem) of public libraries.  Or, would someone send
me a list of the dial-up numbers, logon, etc. of libraries in South
Carolina.  Send to: bp976@Cleveland.freenet.edu
Thanks
Gene Jeffries in Columbia, SC

--
   The opinions expressed are not necessarily those of the University of
     North Carolina at Chapel Hill, the Campus Office for Information
        Technology, or the Experimental Bulletin Board Service.
           internet:  bbs.oit.unc.edu or 152.2.22.80



From <@vm.biu.ac.il:root@bimacs.cs.biu.ac.il> Sun Aug 16 14:13:39 1992
From: dov@menora.weizmann.ac.il (Dov Grobgeld)
Subject: Looking for wholesale distributer of magazines in the US


Rumours have told me that there is a wholesale distributor of magazines
in the US who is reachable by internet. I'm looking for more information
as I would like to contact him in order to do some private subscriptions.

Please reply by e-mail as I'm not a regular subscriber of these newsgroups.

--
                                                        ___   ___
                                                      /  o  \   o \
Dov Grobgeld                                         ( o  o  ) o   |
The Weizmann Institute of Science, Israel             \  o  /o  o /
"Where the tree of wisdom carries oranges"              | |   | |
                                                       _| |_ _| |_
From: amg@boriquen.austin.ibm.com
Newsgroups: comp.arch
Subject: HP 7XX Series: Cache Info Needed
Date: 17 Aug 92 18:22:55 GMT
Organization: IBM, Austin

Hi!

I am looking for cache size information for the HP 710, 720 and 750 
(specifically cache size, line size and associativity).

Thanks!

@_@_@_@_@_@_@_@_@_@_@_@_@_@_@_@_@_@_@_@_@_@_@_@_@_@_@_@_@_@_@_@_@_@_@_@_@_@ 
|                                                                         | 
@                    Ann Marie Grizzaffi Maynard                          @
|             IBM Austin               amg@perfmap.austin.ibm.com         |
@                                                                         @
|          They say once you drink the waters of Puerto Rico              |
@                     you never want to leave!!!                          @
|                                                                         |
@_@_@_@_@_@_@_@_@_@_@_@_@_@_@_@_@_@_@_@_@_@_@_@_@_@_@_@_@_@_@_@_@_@_@_@_@_@

-- 
@_@_@_@_@_@_@_@_@_@_@_@_@_@_@_@_@_@_@_@_@_@_@_@_@_@_@_@_@_@_@_@_@_@_@_@_@_@ 
|                                                                         | 
@                    Ann Marie Grizzaffi Maynard                          @
|             IBM Austin               amg@perfmap.austin.ibm.com         |
From: chased@rbbb.Eng.Sun.COM (David Chase)
Newsgroups: comp.arch
Subject: Re: 32 => 64 Transition
Date: 22 Aug 92 00:18:36 GMT
Organization: Sun Microsystems, Mt. View, Ca.
NNTP-Posting-Host: rbbb

guyd@harpo.hursley.ibm.com (Guy Dawson) writes:
>Reading K&R2, section 2.2 Data Types and Sizes, for a '64 bit' CPU I
>would expect the following sizes :

>char		8 bits
>short		32 bits
>int		64 bits
>long		128 bits

>For me, the key phrase is given in the short table of sizes :-

>int	an integer, typically reflecting the natural size of integers on the
>host machine

The talk of "natural size" on the host machine is a little misguided,
if you ask me.  There's not an appreciable performance penalty in
having an integer be smaller than the register width on a machine
(consider the Macintosh, where many C compilers give you 16-bit
integers).  In the case where you need a big integer, and you need
portable code, saying "int" won't help you, because the size isn't
portable -- better to punt and say "long long" (yes, I know it is not
strictly compliant -- a true standards weenie would whip up a typedef
and do it all with subroutines, providng a portability package that
used structures for strict compliance, and long long for speed where
it is supported.  However, since you can get compilers that support
long long, I'd have to say that I've got better ways to spend my
time).

There are other issues besides naturalness.  Here are a few
that seem to matter to various (different) people:

* Fortran compatibility.  Fortran 77 (yeah, I know that '90 is
different) mandates that

    sizeof(INTEGER) = sizeof(REAL) = sizeof(DOUBLE PRECISION)/2.

A corollary of this is that there had better be a 32-bit integer data
type in C, unless your hardware implements quad-word floating point.

* Common descriptions of data structures.  On almost all machines in
the world (PC, Mac, 32-bit workstations) char, short, and long have
the same size, though "int" floats.  In theory, clean coding avoids
this problem.  Theory and practice diverge somewhat, unfortunately.
Even so, this doesn't solve endianness problems.

* (strict) Standard compliance.  This means that (for instance) adding
new type names is not allowed (whether "long long" or "__int32"), and
that "int" cannot be larger than "long".  A more relaxed notion of
compliance (defined in the standard) allows the introduction of new
type names provided that they take certain forms ("long long" or
"__int32" are both admissable).

* The naturalness argument reappears when people who "know" that the
underlying machine is a 64-bit machine get their arithmetic truncated
accidentally to 32-bits in some intermediate step, and are unhappy
about it.  It certainly doesn't help speed to force the truncation,
though optimizer writers will do their best to hide the cost.

My opinion on what is the right decision has changed sufficiently many
times that it would probably be stupid to state it publicly, because I
might well find myself arguing with myself (which happens often enough
as is, but it's much less embarrassing in private).

David Chase
Sun
Newsgroups: comp.arch
From: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky)
Subject: Re:  What would you like in a debugger?
Reply-To: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky)
Organization: Snake Island Research Inc, Toronto
Date: Thu, 13 Aug 92 14:49:12 GMT

In article <1992Aug12.011403.16934@technix.mn.org> bret@technix.mn.org (Bret Indrelee) writes:
>
>I don't know how many debuggers I have given up on because they decided
>to display the contents of a pointer, rather than the value of the pointer.
>
>If you keep with the syntax of the native language, the programmer should
>be able to see that they asked for the pointer rather than the value at
>the pointer.  If you try to 'fix their error' it makes it really nasty
>to really see the value of a pointer.
>
>Go chase a linked list bug if you don't think you need to see the value
>of a pointer.  Or use mmap() with your favorite memory-mapped device.  Or
>any number of other similair things...
>
>If you can manage it, another feature that would be nice is disassembing
>code when someone asks you to display the contents of a pointer to function.
>If your feeling really hot, try to relate it to the source line in the
>program...just make sure that this 'feature' can be disabled for when there
>is a misinterpretation.

I think the important point here is that no debugger designer can
determine which debugging facilities are adequate for a specific
debugging job. Because of this (and for convenience), we at I.P. Sharp
Associates (May it rest in peace, stomped as it was by Big Feet)
developed a system which combined interactive debugger and dump
analysis facilities, written entirely in SHARP APL.

Since everything was just APL functions, it was trivial to 
build a special purpose function on the fly for your particular
problem. So, special purpose formatters (funny translations,
linked list chasers, table transposers, etc) are trivial to
build. 
This work was incredibly successful, and I strongly recommend
that those of you who are in possession of USABLE interactive
systems consider the development and/or integration of interactive
tools to allow on-the-fly customization of dump/debug tools to
make the programmer's job easier.

Bob



Robert Bernecky      rbe@yrloc.ipsa.reuter.com  bernecky@itrchq.itrc.on.ca 
Snake Island Research Inc  (416) 368-6944   FAX: (416) 360-4694 
18 Fifth Street, Ward's Island
Toronto, Ontario M5J 2B9 
Canada
Newsgroups: comp.arch
From: S_JUFFA@iravcl.ira.uka.de (|S| Norbert Juffa)
Subject: Re: CACHE MISS PENALTY FOR 386/486??
Organization: University of Karlsruhe (FRG) - Informatik Rechnerabt.
Date: Thu, 20 Aug 1992 16:58:58 GMT
X-News-Reader: VMS NEWS 1.23

In <1992Aug19.042318.10163@nuscc.nus.sg> eletanjm@nuscc.nus.sg writes:

> Just what is a typical cache miss penalty on 
> (1) a 386 system with external cache 
> (2) a 486 system with only internal cache
> (3) a 486 system with internal cache and external secondary cache 
> 
> I'm assuming an typical AT style system.
> 
> Just how do you determine the miss penalty anyway?

The German computer magazine c't had a review of several identical configured
386 motherboards recently, each with a different chip set. They measured the
cache miss penalty for the cache controllers that are included in the chip set.
The cache miss penalty ranged between 3 clock cycles for an ACT chip set, 4
clock cycles for the Forex chip set up to 40 (for an UMC chip set, I think).
Apart from the speed of the cache logic, the cache line length heavily
influences time for a cache miss. Most 386 systems have 4 byte cache lines
that can be filled by a single access to memory. There are some that feature
longer cache lines, though. I think line sizes of up to 16 bytes are common.
In a naive approach, the CPU would have to wait until the complete cache line
had been loaded. There is a more clever approach possible that delivers the
word the CPU wanted directly to the CPU and fills the cache line afterwards
(I think this is called "read-around" or similar). 

You should find data about the cache miss penalty for the 486 in the i486 
Hardware Reference Manual available from Intel's literature department.

As for measuring the miss penalty, you try to force cache misses and measure
the load time from memory and then compare it to the time it takes the
memory access to complete in the case of 100% cache hits. Assume you have an
8 kByte cache. If you load a block of memory of exactly 8 kByte and read it
twice, you will have close to 100% hit rate on the second access (since the
386/486 feature unified code/data caches, executing the instructions to
read from memory throws out some of the data read before, but not much).
Now assume you read a 16 kByte block linearly into the same cache. After
the first read, the second 8 kByte half of the 16 kByte block will completely 
occupy the cache. Now you read the same 16 kByte block again. On every access
to a cache line for the first 8 KByte, you have a cache miss. If you measure
the for both read operations and factor in the cache line length, you can
compute the miss time. I have tried this approach and it seems to work
quite well. There may be more sophisticated ideas though I am not aware of.


Norbert 
------------------------------------------------------------------------------
Norbert Juffa     email: S_JUFFA@IRAVCL.IRA.UKA.DE          Live and let live!
From: peter@ferranti.com (peter da silva)
Newsgroups: comp.arch
Subject: Re: 32 => 64 Transition
Date: 12 Aug 92 14:46:45 GMT
Reply-To: peter@ferranti.com (Peter da Silva)
Organization: Xenix Support, FICC

In article <1992Aug08.165832.114442@cs.cmu.edu>, lindsay+@cs.cmu.edu (Donald Lindsay) writes:
> [DEC]	32-bit system	64-bit system

> char		 8		 8
> short		16		16
> int		32		32
> long		32		64
> long long	to be added	64
> pointer	32		64

I applaud these choices. With them all normal integer sizes remain available,
and no valid code will be broken.

In article <1992Aug11.125326.16719@email.tuwien.ac.at> anton@mips.complang.tuwien.ac.at (Anton Martin Ertl) writes:
> I find these choices bad. IMO the relations between types should be
> preserved. Specifically, pointers and ints should have the same size.

But pointers and ints *aren't* the same size. Look:

+ cat test.c 
#include <stdio.h>

main()
{
	printf("sizeof (int) = %d\n", sizeof (int));
	printf("sizeof (char *) = %d\n", sizeof (char *));
}
+ cc -Ms -o testsmall test.c 
test.c
+ cc -Ml -o testlarge test.c 
test.c
+ testsmall 
sizeof (int) = 2
sizeof (char *) = 2
+ testlarge 
sizeof (int) = 2
sizeof (char *) = 4

> Well-written programs hide dependencies on type sizes by defining
> types like Int32. They read machine-independent data from files by
> using XDR or sgetl or ASCII data anyway.

Well written programs don't assume that sizeof (int) == sizeof (char *).
This is the classic vaxocentric coding error. It's caused me untold grief
over the past 5 years, and will cause untold grief for other programmers
over the next 5. It's a pity that 64-bit machines will only exacerbate the
infamous "infinite VM" fallacy, though.

What size would *you* make an int? 64 bits? What do you do for a 32-bit
data type? Short? Then what do you do for a 16-bit data type? Create another
abomination "short short" or "long char"? "long long" is bad enough.
-- 
Peter da Silva                                               `-_-'
$ EDIT/TECO LOVE                                              'U` 
%TECO-W-OLDJOKE Not war?                        Have you hugged your wolf today?
Ferranti Intl. Ctls. Corp.      Sugar Land, TX  77487-5012       +1 713 274 5180
From: S_JUFFA@iravcl.ira.uka.de (|S| Norbert Juffa)
Newsgroups: comp.arch
Subject: Who wants bibliography for floating-point arithmetic?
Date: 20 Aug 1992 15:42:59 GMT
Organization: University of Karlsruhe (FRG) - Informatik Rechnerabt.
Distribution: world
NNTP-Posting-Host: irav1.ira.uka.de
X-News-Reader: VMS NEWS 1.23

Hi netters!

Over the past two years, one of my main interest was in floating-point
arithmetic. During this time, I wrote a floating-point package and also
aquired quite a lot of literature. I listed all the literature in a
rather big file. If anyone is interested in this list, send email.
If I get more than ten requests, I will post the bibliography to
comp.arch. My main interest was in microprocessor based, binary floating
point arithmetic implemented in software, and the literature selection
for my bibliography reflects this fact. Most of the articles referenced
are from scientific magazines like IEEE Transactions on Computers, but
there also quite a few from popular magazines like BYTE or Computer 
Language.

Norbert
---------------------------------------------------------------------------
Norbert Juffa     email: S_JUFFA@IRAVCL.IRA.UKA.DE       Live and let live!

Newsgroups: comp.arch
From: pchris@dcc.uchile.cl (Chris Perleberg)
Subject: Re: Die aspect ratio.
Originator: pchris@pehuen
Date: Fri, 14 Aug 1992 21:39:00 GMT
Reply-To: pchris@dcc.uchile.cl
Organization: Universidad de Chile, Depto. de Ciencias de la Computacion


In article <16edveINN7or@agate.berkeley.edu>, krste@ICSI.Berkeley.EDU (Krste Asanovic) writes:
> 
> It seems unlikely that an irregular design such as a processor or
> cache controller would map naturally to a square die floorplan.  Is
> there some inherent yield or manufacturability advantage to having a
> square die?  I can think of reticle size and maybe efficient wafer
> tiling as two reasons.

I believe one reason for a square die is to try to minimize clock skew by
trying to minimize the length of the longest possible delay path (a square 
has shorter paths than a long rectangle with the same area).

	Chris Perleberg
	pchris@dcc.uchile.cl
Newsgroups: comp.arch
From: mcvey@mpr.ca (Iain McVey)
Subject: Re: 32 => 64 Transition
Organization: MPR Teltech Ltd., Burnaby, B.C., Canada
Date: Thu, 13 Aug 92 18:28:51 GMT

In article <id.UHAS.9TA@ferranti.com> peter@ferranti.com (Peter da Silva) writes:
>In article <1992Aug08.165832.114442@cs.cmu.edu>, lindsay+@cs.cmu.edu (Donald Lindsay) writes:
>> [DEC]	32-bit system	64-bit system
>
>> char		 8		 8
>> short	16		16
>> int		32		32
>> long		32		64
>> long long	to be added	64
>> pointer	32		64
>
>I applaud these choices. With them all normal integer sizes remain available,
>and no valid code will be broken.
>

Hmm, perhaps I have my wires crossed here, but I thought that int was
supposed to be processor defined, and that tiny, short and long were
of standard size.  ie.

		16 bit	32 bit	64 bit
tiny		8	8	8
short		16	16	16
long		32	32	32
long long	(64)	(64)	64

int		16	32	64

with pointers implementation dependent.

no?

- Iain -
-- 
Iain McVey (mcvey@mpr.ca)    | Kodachrome, gives us those nice, bright colours,
Software Designer            | Gives the greens of summers,
MPR Teltech Ltd.             | Makes you think all the world's a sunny day.
8999 Nelson Way, Burnaby, BC | - Paul Simon