HDTenEightyP/NetNews huggingface dataset:
From: wolff@inf.fu-berlin.de (Thomas Wolff)
Subject: Re: Internationalized editing, Euro characters
Organization: Free University of Berlin, Germany
Date: Tue, 22 Dec 1992 18:59:53 GMT

alex@igor.tamri.com (Alex Olender) writes:

> Is there a way to tell "vi" to display these
> characters as they "should" look.

.login settings like 'stty pass8', 'stty -istrip' and similar ones 
(and of course, the right setup of your hardware) should convince Unix 
interfaces to allow 8 bit characters. The exact command varies with Unix 
versions. Choice of complete screen fonts may also be important.

Other, also varying settings may be required to convince programs to 
accept 8 bit data as characters. On then Sun, e.g., the convention is 
setenv LC_CTYPE iso_8859_1
vi would behave well in that environment.

For input, the most general method without redefining keys / attaching 
function keys etc, is the compose key which is available on all modern 
keyboards and terminals. E.g., you would get a letter E with a grave accent 
by typing the key sequence compose-E-` . Certain programs, especially 
editors, may have their own methods.

Printing may be another horror...
Newsgroups: comp.editors
From: it1@ra.msstate.edu (Tim Tsai)
Subject: Re: wordstar on unix
Keywords: wordstar editor
Organization: Mississippi State University
Date: Wed, 30 Dec 1992 09:46:38 GMT

>I don't like vi or emacs.  Is there a wordstar compatible editor
>anywhere on unix?  does anyone have the source code to simple full
>screen editor that's easy to use like wordstar?

  DTE is a pretty decent editor that uses the Wordstar command set.  You
can find it in wuarchive.wustl.edu under /mirror/msdos/editor/dte5-1.zip

  Unix source is included in the distribution.  Let me know if
you have trouble compiling it on pure BSD machines.  I have a
set of hacks here that may help.

Newsgroups: comp.editors
From: davis@pacific.mps.ohio-state.edu ("John E. Davis")
Subject: Re: jed editor?
Reply-To: davis@pacific.mps.ohio-state.edu  (John E. Davis)
Organization: "Dept. of Physics, The Ohio State University"
Date: Wed, 23 Dec 1992 00:22:31 GMT

In article <45054@ucbvax.BERKELEY.EDU> matloff@toto.Berkeley.EDU (Norman
Matloff) writes:

   What is the ftp site for the jed editor?  I know it was posted here
   a while ago, but I didn't keep it.


JED 0.70 is available via anonymous FTP from amy.tch.harvard.edu in the
pub/jed directory.  JED is an emacs inspired extensible editor for
unix, VMS, and MSDOS.  I have been told by several people that its EDT
emulation is better than that provided by emacs.
--
     _____________
#___/John E. Davis\_________________________________________________________
#
# internet: davis@amy.tch.harvard.edu
#   bitnet: davis@ohstpy
#   office: 617-735-6746
#
From: titus@dallas.sil.org
Newsgroups: comp.editors
Subject: Re: Extension Languages
Date: 28 Dec 92 13:10:00 CST
Organization: Summer Institute of Linguistics, Dallas Center

Craig Durland (craig@cv.hp.com) writes:

>I've done this and it seems like a big win.  I didn't use C for the
>language-to-write-editor-extensions and I don't think you want to - C
>is too "low" level for writing extensions in (its great for writing the
>editor itself).  Extension writers shouldn't have to worry about memory
>allocation and all the other little details that C requires you to.
>This doesn't have to take lots of memory - I have garbage collection,
>recursion, lists, etc and the total editor size is < 150k (68k Unix).
>The extensions run slower than native C code but that doesn't seem to be
>much of a problem.

I realize that you work for one of their major competitors,
but DEC's TPU (Text PRocessing Utility) offers a real nice
language for implementing editors.  You might want to have a
look at it, or the third-party implementation nu/TPU.

               * * * * * * * * * * * * * * * * *
Mike Titus, Programmer                  /\   Summer Institute
SIL                                    /  \        of
7500 West Camp Wisdom Road            /SIL \   Linguistics
Dallas, Texas  75236-5699            --------
U.S.A.
Voice    : (214) 709-2400             * Internet <titus@dallas.sil.org>
Facsimile: (214) 709-3387             * UUCP     ...utafil!txsil!dalsil!titus
"I can do everything through Him who gives me strength."
      Philippians 4:13 (NIV)
Newsgroups: comp.editors
From: michael@chpc.utexas.edu (Michael Lemke)
Subject: Re: EDT emulator for EMACS
Organization: The University of Texas System - CHPC
Distribution: comp.editors
Date: Sun, 27 Dec 92 09:05:45 GMT

In article <MIKE.92Dec24144535@cucbs.chem.columbia.edu> mike@cucbs.chem.columbia.edu (Michael New) writes:
>
>Hello all:
>	We are converting from a VAXCluster to a cluster of IBM 
>RS/6000's.  To ease the migration for some of our users, I would
>like to run an EDT emulator in EMACS.  Does anyone know where
>I can get it?

Get tpu-edt.el from an elisp archive near your (or e-mail me if you 
can't find any and I mail you a copy).  tpu-edt.el is probably the best 
TPU EDT-keypad-emulation emulation available.

Michael
-- 
Michael Lemke
Astronomy, UT Austin, Texas
(michael@io.as.utexas.edu or UTSPAN::UTADNX::IO::MICHAEL [SPAN])
Newsgroups: comp.editors
From: alien@boi.hp.com (Tom von Alten)
Subject: Re: Mouse cognizant vi?
Date: Thu, 31 Dec 1992 19:15:44 GMT
Organization: Hewlett-Packard / Boise, Idaho
X-Newsreader: TIN [version 1.1.7 PL6]

Eric R. Johnson (ejohnson@enuxha.eas.asu.edu) wrote:
: Is there a version of vi that will move the cursor to a point
: clicked on with a mouse?  Most times it's _great_ to not leave the
: home row, but if I resize a window, and want to jump to a new point,
: it would be nice to just be able to _go_ there with one click, and 
: not a bunch of keystrokes.

If you have the "copyline" feature or equivalent (mine is with HP's
Xwindows and hpterm) you can simulate this behavior.  This feature copies
from the mouse position to the end of line, including the <lf> and pastes
this buffer.  In command mode,

	1. type "/" (for search)
	2. position the mouse and press "copyline" (on my system
	   it's mapped to the right mouse button)

A windows-based cut/paste functionality could be used also, but likely adds
up to more than 1 key and 1 boink.
_____________
Tom von Alten           email: alien@boi.hp.com
                        Hewlett-Packard Disk Memory Division
From: rrg@rtp.fibercom.com (Rhonda Gaines)
Newsgroups: comp.editors
Subject: How to Run VAX Screen Editor From Sun Workstation
Date: 21 Dec 92 20:13:41 GMT
Organization: FiberCom, Inc., Roanoke, Virginia


How can I from my Sun Workstation log into our DEC VAX 4000/200
(VMS) and run a full screen editor?  The usual scenario, from a
VT220 terminal, is to type EDT fn.ft which puts me into a screen
oriented editor.  The same thing from my sun (even with changing my
terminal type to vt220 before telneting to the VAX) yields a line
editor.  Any ideas?  Replies to rrg@fibercom.com.

 -thanks
  rhonda
-- 
Rhonda Gaines              INTERNET: gaines@fibercom.com
FiberCom, Inc.             UUCP: ...!uunet!fibercom!gaines   
P.O. Box 11966             PHONE: 703-342-6700 or 800-423-1183 x291
Roanoke, VA  24022-1966    FAX:   703-342-5961
Newsgroups: comp.editors
From: rkoehler@author.gsfc.nasa.gov (BOB KOEHLER)
Subject: Re: Extension Languages
News-Software: VAX/VMS VNEWS 1.4-b1  
Organization: CSC System Sciences Division
Date: Tue, 29 Dec 1992 13:32:00 GMT

In article <1992Dec29.064438.24211@physiol.su.OZ.AU>, john@physiol.su.OZ.AU (John Mackin) writes...

>I don't know about the merits of TPU in the abstract.  I just want to
>discourage everyone from using nu/TPU.  It is a real pain in the bottom.
>It has very restrictive `oh no, you have pirated me' code built into
>it.  Now I have _not_ tried to pirate the damn thing, all I have
>tried to do is support it for my users in a distributed computing
>environment, and the pirate-detction stuff is very flakey: all
>you have to do, just about, is breathe on the environment it's
>installed in, and the damn thing decides it's been pirated and
>refuses to run any more.  And naturally, they've taken the
>security-through-obscurity approach (probably because they
>couldn't make it secure any other way), so there's not a
>shred of documentation on this stuff to help you figure out
>what it was you did `wrong', or how to fix it or avoid
>doing it in the future.
> 
>Set knows I'm opposed to commercial software in general, but
>this sort of thing really needs to be stamped out.  Please
>do not buy nu/TPU.
> 

   I do know about TPU's merits in the abstract, and in the practical. I have
had no problems of any such manner with nu/TPU, and the problems I have gone
through have been well worth the result.  A great full screen, character-cell
as well as X11 compatable editting interface, especially for those moving from
a VMS to UNIX or DOS environment already knowing DEC's EDT, or EVE, or
progamming in TPU. And an extension language specifially designed for writing
text editors (talk about the right tool for the job).  There are, of course
competitors to nu/TPU in the TPU arena, as well as in the EDT-only arena which
should be considered before spending money.  We consider our purchase as money
well spent, and intend to do so again in the future.
From: titus@dallas.sil.org
Newsgroups: comp.editors
Subject: Re: wordstar on unix
Date: 30 Dec 92 11:56:28 CST
Organization: Summer Institute of Linguistics, Dallas Center

  I believe that microEMACS can be set up to behave rather
like WordStar, via the EMACS.RC file.  You can bind whatever
commands you want to to whatever keys you desire.  I'm not
absolutely sure that you can put all of the desired
combinations together, but it WILL allow you to re-map the
META-prefix (usually <escape>) and the CTRLX-prefix.  Also,
for those of us who are unable to fathom LISP, its extension
language is something besides a dialect of lisp; in fact it
is rather structurable in design.

               * * * * * * * * * * * * * * * * *
Mike Titus, Programmer                  /\   Summer Institute
SIL                                    /  \        of
7500 West Camp Wisdom Road            /SIL \   Linguistics
Dallas, Texas  75236-5699            --------
U.S.A.
Voice    : (214) 709-2400             * Internet <titus@dallas.sil.org>
Facsimile: (214) 709-3387             * UUCP     ...utafil!txsil!dalsil!titus

"I can do everything through Him who gives me strength."

      Philippians 4:13 (NIV)
Newsgroups: comp.editors
From: andy@research.canon.oz.au (Andy Newman)
Subject: Re: Extension Languages
Organization: Canon Information Systems Research Australia
Date: Wed, 30 Dec 1992 13:44:12 GMT

I wrote:
>>Tim Long's ICI (ftp from extro.ucs.su.oz.au). 
>
>That should be extro.ucc.su.oz.au. Unfortunately ici doesn't seem
>to be there. I'll find out where it's gone....

Extro's FTP archive is being re-organised. ICI is available for FTP thanks
to Ozan Yigit ... try /pub/oz/ici.tar.Z at nexus.yorku.ca 

-- 
Andy Newman (andy@research.canon.oz.au)
From: tdbear@dvorak.amd.com (Thomas D. Barrett)
Newsgroups: comp.arch
Subject: Re: COMPAQ PROPOSED SCALABLE I/O ARCHITECTURE
Date: 3 Jan 93 13:44:41 GMT
Organization: Advanced Micro Devices, Inc.; Austin, Texas

In article <AJC.93Jan1182933@thendara.pa.dec.com> ajc@pa.dec.com (AJ Casamento) writes:
>  However, my point was that COMPAQ could also provide a common interface ASIC,
>equivalent to the TcIA, that would provide a very cheap cut and paste logic for
>Option card vendors that would provide a lowest risk path for migrating their
>current designs to this new interconnect. 

Good point AJ... but having the design and the simulation of the
design shared by more of the members would insure the openess and help
get the ball rolling faster.  Mind you, though, I'm not volunteering
unless you folks want a DABL model :)

-- 
|Tom Barrett (TDBear), Sr. Engineer|tom.barrett@amd.com|v:512-462-6856 |
|AMD PCD MS-520 | 5900 E. Ben White|Austin, TX  78741  |f:512-462-5155 |
|"No is yes, And we're all free"   |CO made a #2 no-no... PU!          |
|My views are my own and may not be the same as the company of origin  |
Newsgroups: comp.arch
From: wbeebe@bilver.uucp (Bill Beebe)
Subject: Re: IBM AS/400 is the world's slowest computer
Organization: W. J. Vermillion - Winter Park, FL
Date: Sat, 2 Jan 1993 19:57:06 GMT

In article <1993Jan1.102554.28575@metapro.DIALix.oz.au> bernie@metapro.DIALix.oz.au (Bernd Felsche) writes:

>For small organizations with limited computing staff (yes,
>even none!), a multi-user box is often the way to go.
>Networking introduces many complications which are often
>difficult to diagnose from off-site using anything less than
>a megabit/second link and a voice link to have a "slave" do
>the physical checks.

Well, at this small organization of 4 engineers, I do the network support
as well as billable hours. We started with a cheap 25MHz 386DX box running
Netware 2.2. We keep our group work on the server, migrating our development
work as it matures. I kept us out of trouble by simply backing up the
server and keeping a "stock" copy of our work systems disk environment.
When we went to Windows for Workgroups I was able to do backups of both
the server as well as the clients via peer-to-peer. I have everything
automated, and we use the mail and schedule modules now to let the others
know something important when we can't do it face-to-face. Based upon
my costs for boxes, NICs, and various pieces of software, it's a wash when
it comes to network versus box-and-terminals. But the nicest part of our
setup is the fact that my 33MHz 486 system is _mine_. If I have to do some
real intense work (like major builds or 3-D simulation) then I can withoug
hearing about it because it's impacted the rest of the group. If I want
to install some other environment (which I do on occassion) because of
a client's project, then I can. I have lived on WANs since 82 and LANs
(specifically Novell) since 86. I find LAN life preferable to living
on archaic multi-user boxes.

-- 
William H. Beebe, Jr. - wbeebe@bilver.UUCP
                 UUCP - {ucf-cs,peora,uunet}!tarpit!bilver!wbeebe
                      - bilver Public Access Unix, Orlando FL
                      - (407)644-8327  2400/9600  24 hours  8N1
Newsgroups: comp.arch
From: glew@pdx007.intel.com (Andy Glew)
Subject: Re: branch-and-link
Organization: Intel Corp., Hillsboro, Oregon
	<1hm0cpINN8nf@darkstar.UCSC.EDU> <1hm114INN6v2@transfer.stratus.com>
Date: Fri, 1 Jan 1993 00:34:59 GMT

    On a related note (vis-a-vis debugging ease) to the branch-and-link issue, another peeve
    I've always had is that no commercially available processors (that I know of) make NULL
    pointer detection easy withou serious run-time overhead.  Various OS's try by unmapping
    the first N pages of memory, which works fine until you run into a chip like the 68030,
    which supports huge displacements.  Not to mention if the index register pushes the
    effective address out of your protected window, you're hosed.  If you have a standard
    base_reg+index_reg+disp format, it would seem to me that having the processor check the
    base register for NULL and faulting if it is wouldn't be that hard (or inefficient).
    Especially if NULL happens to be zero on that machine.

Rather contradicts another thread.

Compilers can perform significantly more optimizations if accesses
to address 0 (and neighbourhood) are guaranteed not to fault.

See:

    "Proving safety of speculative load instructions at compile time"
    David Bernstein
    Michael Rodeh
    Mooly Sagiv
    IBM Israel
--

Andy Glew, glew@ichips.intel.com
Intel Corp., M/S JF1-19, 5200 NE Elam Young Pkwy, 
Hillsboro, Oregon 97124-6497

This is a private posting; it does not indicate opinions or positions
of Intel Corp.

Intel Inside (tm)
From: sritacco@wet.UUCP (Steve Ritacco)
Newsgroups: comp.arch
Subject: Low-power R4000 ???
Date: 23 Dec 92 06:32:10 GMT
Organization: Wetware Diversions, San Francisco

Hi,

Back around the original R4000 roll-out there was mention of a low-power
device to be co-designed with NEC.  What ever happened to this effort?

Thanks,

Steve

Newsgroups: comp.arch,comp.sys.dec,comp.sys.sgi,comp.sys.hp
From: larry@eco.twg.com (Lawrence B. Henry III)
Subject: Re: Comparison of Alpha, MIPS and PA-RISC-II wanted
Reply-To: larry@eco.twg.com
Organization: The Wollongong Group (East Coast Operations)
Date: Thu, 24 Dec 92 05:42:33 GMT


In article <9212232308.59@rmkhome.UUCP>, rmk@rmkhome.UUCP (Rick Kelly) writes:
|>Xref: eco.twg.com comp.arch:23046 comp.sys.dec:10890 comp.sys.sgi:26977 comp.sys.hp:20648
|>Newsgroups: comp.arch,comp.sys.dec,comp.sys.sgi,comp.sys.hp
|>Subject: Re: Comparison of Alpha, MIPS and PA-RISC-II wanted
|>Path: eco.twg.com!uunet!think.com!unixland!rmkhome!rmk
|>From: rmk@rmkhome.UUCP (Rick Kelly)
|>Organization: The Man With Ten Cats
|>Date: Thu, 24 Dec 1992 04:08:57 GMT
|>Reply-To: rmk@rmkhome.UUCP (Rick Kelly)
|>Message-ID: <9212232308.59@rmkhome.UUCP>
|>References: <mwp.724991851@iconix.oz.au> <1992Dec22.203644.5908@ais.com> <id.3H2W.BOB@ferranti.com>
|>Lines: 13
|>
|>In article <id.3H2W.BOB@ferranti.com> peter@ferranti.com (peter da silva) writes:
|>>In article <1992Dec22.203644.5908@ais.com> bruce@ais.com (Bruce C. Wright) writes:
|>>> added functionality.  C, unfortunately, does not provide a very good
|>>> interface to RMS;  but other languages do (eg, PL/I).
|>>
|>>Near as I can tell, VAX C is a deliberate attempt to discourage the use
|>>of C on VMS. It's *that* bad.
|>
|>No, it's worse. :-)
|>
|>-- 
|>
|>Rick Kelly	rmk@rmkhome.UUCP	merk!rmkhome!rmk	rmk@frog.UUCP
|>

Isn't that why they are doing DEC C ??? it seems to be focused on being a real
industrial strength C compiler.. with a corresponding RTL.. they seem to be
getting there..

-Larry.
Newsgroups: comp.arch
Subject: Asking info about Alpha
From: fen@vax1.mankato.msus.edu
Date: 29 Dec 92 22:35:06 -0600
Organization: Mankato State University

Can any tell me some info about Alpha branch prediction strategies?
Thank.
Feng Zhou
fen&vax1.mankato.MSUS.edu
From: paul@taniwha.UUCP (Paul Campbell)
Newsgroups: comp.arch
Subject: Re: UNIX fseek time (was Re: Comparison of Alpha, MIPS and PA-RISC-II wanted)
Date: 28 Dec 92 22:07:30 GMT
Organization: Taniwha Systems Design

In article <1992Dec24.151500.11047@cis.uab.edu> hyatt@cis.uab.edu (Robert Hyatt) writes:
-In article <1992Dec24.112422.12434@titan.inmos.co.uk> conor@lion.inmos.co.uk (Conor O'Neill) writes:

->But, given that 'fseek' is incredibly slow on most Unix systems,
->one could almost assume that Unix doesn't support random-access files.


-As to it being slow, I haven't noticed it being any slower than most any
-system call.... there IS a lot of work to cross the kernel boundary and
-then get back.  fseek() doens't do much work, just computes where the

Actually I thought he was being facetious ..... however fseek() may indeed 
sometimes be slow because if you have recently been writing the stdio
package may flush it's (user mode) buffers (by write()ing them) before the
actual lseek() gets done. All you are really doing here is trading off
fseek() latency for fwrite() (or putc()) latency. In fact if you are
doing lots of random writing stdio is NOT what you want to use for exactly
this reason - or at least turn off the buffering since it isn't helping
you.

The system call lseek() simply changes a pointer in a kernel data structure,
the next read/write causes that new address to be accessed. (A smart system
might force the block the lseek() points at to be asynchronously prefetched).

	Paul
-- 
Paul Campbell    UUCP: ..!mtxinu!taniwha!paul     AppleLink: CAMPBELL.P
"Finally after much thought he tied a dollar bill to the top of the tree, it
seemed to fit - after all it was the premier capitalist holiday, besides after
the 'fall' of communism a star didn't seem appropriate anymore ..."
Newsgroups: comp.arch
From: lindsay+@cs.cmu.edu (Donald Lindsay)
Newsgroups: comp.arch
Subject: Re: IBM AS/400 is the world's slowest computer
Date: 24 Dec 92 19:40:34 GMT
Article-I.D.: cs.Bzs3zn.43H.2
Organization: School of Computer Science, Carnegie Mellon


cecchi@rchland.vnet.ibm.com (Del Cecchi) writes:
>In article <1992Dec22.092355.29859@adobe.com>, zstern@adobe.com (Zalman Stern) writes:
>|> In particular, is it based on PowerPC or is IBM going to  
>|> have two 64 bit RISC architectures floating around.

>"IBM doesn't comment on un-announced machines"

The workstation group has tried to persuade the rest of IBM to use
its silicon. As long as the division making the AS/400 is profitable,
it will have the option of resisting this pressure.
-- 
Don		D.C.Lindsay	Carnegie Mellon Computer Science
Newsgroups: comp.arch
From: bwilson@leland.Stanford.EDU (Robert Wilson)
Subject: Re: Superscalar vs. multiple CPUs ?
Organization: DSG, Stanford University, CA 94305, USA
Date: Mon, 21 Dec 92 17:37:32 GMT


In article <lj976dINNg4d@exodus.Eng.Sun.COM> grover@brahmand.Eng.Sun.COM (Vinod Grover) writes:
> I suggest you read the Butler et. al. paper cited [1] earlier by someone
> in this thread. These authors claim that on an unrestricted data flow
> machine, *general purpose* codes like gcc, li, eqntott, (taken from
> SPEC89) have pretty high degree of parallelisms in them. Measured in
> terms of IPC:
> 
>   gcc - 38
>   espresso - 179
>   eqntott - 300
>   li - 162
> 
> Judging from these claims, the issue is not how much parallelism there
> is but how cost-effective is it to extract it. As CPU resources
> approach realistic values the sustainable issue rates on these codes
> fall dramatically, (2-4). These are limits imposed by the
> hardware/compilers. 
> 
> [1] Butler, Yeh, Patt, Alsup, Scales, Shebanow, "Single Instruction
> Stream Parallelism is Greater than Two", Intnl. Symp. on Comp. Arch
> 1991. 

Unfortunately, the limited degree of parallelism in general-purpose
codes is NOT just due to the current state of hardware and compilers.
The study by Butler et al. contains some interesting results and is
definitely worth reading but don't put too much weight on the numbers
for the Unrestricted Dataflow (UDF) Machine.  This machine only considers
data dependences.  In the programs mentioned above, however, most of the
computation centers around executing branches, so the limiting factor is
not just WHEN can the instructions execute, but also WHICH instructions
will be executed.  The UDF machine completely ignores these control
dependences which are an inherent part of the program semantics and not
just a side effect of limited hardware and compilers.

There are, of course, some things we can do to try to mitigate the
effects of control dependences.  Branch prediction with speculative
execution, control dependence analysis, and multiple processors are
three things that we have found so far [2].  As new techniques are
developed, we can certainly expect to extract more parallelism from
general-purpose codes, but for now, I think 2 - 4 is a reasonable
estimate for the IPC of a uniprocessor.

Bob Wilson
bwilson@shasta.stanford.edu

[2] Monica Lam and Robert Wilson, "Limits of Control Flow on Parallelism",
19th Intnl. Symp. on Comp. Arch, 1992.