HDTenEightyP/NetNews huggingface dataset:
From: dnichols@ceilidh.beartrack.com (Don Nichols (DoN.))
Newsgroups: alt.folklore.computers,comp.unix.misc
Subject: Re: The need for an assembler (was: Favorite CPU)
Date: 3 Sep 92 01:33:50 GMT
Organization: D & D Data

In article <jimf.715439665@centerline.com> jimf@centerline.com (Jim Frost) writes:
>peter@ferranti.com (peter da silva) writes:
>>In article <1992Aug31.162630.23913@news.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes:

	[ ... ]

>>> Within the world of Kermit, we have frustrating cases of even small programs
>>> that need worlds of conditionals to satisfy the bizarre variations floating
>>> around the industry.
>
>>Within the world of Kermit the latest release I've tried still runs on Xenix-
>>286 (System III Xenix, not SCO), System V on the 386, System V on the 68000,
>>and on the Sparc. I would take some convincing that this would be possible
>>in any other language that's reasonably widely available, except maybe Fortran.
>
>That's just the tip of the iceburg.  You really don't see many
>machines Kermit *doesn't* run on.

	Of course, he was talking about these machines (which represent a
fairly wide range of architectures and Unix variants) all running code
compiled from *THE SAME SOURCE FILES* :-)

-- 
Donald Nichols (DoN.)     | Voice (Days): (703) 704-2280 (Eves): (703) 938-4564
D&D Data                  |  Email: <dnichols@ceilidh.beartrack.com>
I said it - no one else   |         <nichols@nvl.army.mil>
	--- Black Holes are where God is dividing by zero ---
Newsgroups: alt.folklore.computers
From: smiley@akasha.eng.hou.compaq.com (Colin Smiley)
Subject: Re: Better dead than IBM
Organization: Compaq Computer Corporation
Date: Fri, 28 Aug 1992 16:00:57 GMT

In article <1992Aug28.072749.1@cc.curtin.edu.au>, zcookbruc@cc.curtin.edu.au writes:
|> In article <fstuart.920827112330@lab16.eng.auburn.edu>, fstuart@eng.auburn.edu (Frank Stuart) writes:
|> > What does IBM *really* stand for?  Let me know if you know the answer and
|> > I'll post a summary in a week or two.


From my Dad, a former IBM employee...

Itty Bitty Machines

and I have heard,

I've Been Managed...


Colin


-- 
-------------------------------------------------------------------------
Colin Smiley, Compaq Computer Corporation, Houston, Texas 77269-2000
e-mail: smiley@compaq.com                           Phone: (713) 378-8426
-------------------------------------------------------------------------
Disclaimer:  Any opinons expressed here do not reflect the opinions of
Compaq Computer Corp.  They make computers.  I make noise.
From: linden@positive.Eng.Sun.COM (Peter van der Linden)
Newsgroups: alt.folklore.computers
Subject: Computer world champ
Date: 28 Aug 1992 19:51:49 GMT
Organization: Sun Microsystems, Mt. View, Ca.
Distribution: world
NNTP-Posting-Host: positive

I'm looking for information about computers that have become
very very good at playing certain games.

Everyone knows about the World Computer Chess Championships,
not quite up to world human standard yet, but I recently heard 
that a program had become world checkers ("draughts" in UK)
champ -- beating the human champ.

I also heard a while back that a computer had beaten the
world human backgammon champ.  I think I read that in CACM.
Does anyone have any more details?  And, Brian -- get back to work.
;-)


--
linden@eng.sun.com|| P. van der Linden and his uncustomary theories.
Go Giants!! Don't || When solving a "panic" you must first ask yourself what you
stop at Florida...|| were doing that could possibly frighten an operating system
Newsgroups: alt.folklore.computers
From: artn@bert.eecs.uic.edu (Ellyn Sandor)
Subject: Re: On the care and feeding of GOTOS
Organization: University of Illinois at Chicago
Date: Tue, 1 Sep 1992 20:01:35 GMT

bmarcum@world.std.com (Bill Marcum) writes:
>In article <5235@tuegate.tue.nl> koen@blade.stack.urc.tue.nl (Koen Holtman) writes:
>>Very few programmers document their code at all....
>>But if they do:
>>FILRR     BLWP @0       file not open, give up
>>I would say `file not open' is the precondition of FILRR.
>>
>>ObFolklore: what assembly am I using?
>>
>Judging by the BLoWuP instruction, I would say it's TMS9900 (TI 99/4)
>assembler.  But I only know that language from the old Osborne "Introduction
>to Microprocessors" book.

	Definitely 9900 (I'm an old TI-99 hacker).  BLWP=Branch and Load
Workspace Pointer.  The 9900 had 16 registers or 16 bits each, kept in
RAM.  The registers could be moved anywhere you wanted by loading the
Workspace Pointer.  BLWP took the first two words at the address and
loaded them into the Program Counter, and took the second two words,
loading them into the Workspace Pointer, thus executing a total context
switch, with a new set of registers and all.  The return address, old
workspace pointer, and something else were kept in the registers 13, 14,
and 15.  (Or maybe there was no something else and it was just R14 and
R15).  BLWP is a pretty nifty way to jump to a subroutine, since you
don't have to keep a stack or do register juggling.
	And a BLWP @0 is a total system reset.  When the system boots,
it uses >0000 as the boot PC and >0002 as the boot WP.
	Interrupts were also implemented as a BLWP (although most of
them were ROMed and unchangable) so an interrupt routine could have
its own set of registers.

			sbm

-- 
--
Stephan Meyers | artn@uicbert.eecs.uic.edu
(Art)^n Laboratories, inventors of the Stealth Negative PHSCologram
(312) 567-3762
Newsgroups: alt.folklore.computers
From: kjell@elixir.e.kth.se (Kjell Rilbe)
Subject: Re: ISO date format
Organization: Dept. of EE, Royal Institute of Technology, Stockholm, Sweden
Date: Tue, 25 Aug 1992 18:20:13 GMT

In article <1992Aug25.163109.907@nrao.edu> cflatter@nrao.edu writes:
>I seem to remember a lengthy thread on date formats here during which it
>transpired that there was an ISO standard format (YYYY-MM-DD).  What
>was the standard number?

Hey, I didn't know this date format was used anywhere outside Sweden! 
Great! Now, could someone PLEASE convince Borland that their date fields
should be able to accept dates entered in this format???? They're almost
there, but they put in dots instead of the dashes!!!! :-(

/Kjell

-- 
-----------------------------------------------------------------------------
! Kjell Rilbe           ! Love is not about getting everything on the list, !
! kjell@elixir.e.kth.se ! it's about accepting the things that aren't on    !
!                       ! the list!             - Stewart Markowitz, LA Law !
Xref: sparky alt.folklore.computers:13593 comp.windows.misc:1336 comp.windows.x:16186 comp.human-factors:2070
Newsgroups: alt.folklore.computers,comp.windows.misc,comp.windows.x,comp.human-factors
From: akao@.com (Adam Kao)
Subject: Re: GUIs Considered Harmful
Followup-To: comp.human-factors
Organization: Oracle Corporation, Redwood Shores, CA
Date: Fri, 4 Sep 1992 15:58:17 GMT
X-Disclaimer: This message was written by an unauthenticated user
              at Oracle Corporation.  The opinions expressed are those
              of the user and not necessarily those of Oracle.

Everybody:  Edit your Followup lines.

In article <3SEP199217474904@rover.uchicago.edu> frank@rover.uchicago.edu writes:
>	Mice, (and sonic pens, etc,) should be used for what they were designed
>	for, that of tracking human movement on a 1 for 1 base, such as free-
>	hand scetching.

Mice are not good for sketching.  Mice are not good for signing your name.
Pens are and always will be the optimal freehand device.

Adam

Newsgroups: alt.folklore.computers
From: hallam@zeus02.desy.de (Phill Hallam-Baker)
Subject: Re: Indentation
Reply-To: Hallam@zeus02.desy.de
Organization: Deutsches Elektronen Synchrotron, Experiment ZEUS bei HERA
Date: Fri, 28 Aug 1992 21:15:38 GMT

In article <BEVAN.92Aug27194834@tiger.cs.man.ac.uk>, bevan@cs.man.ac.uk (Stephen
J Bevan) writes:

|>In article <Q8E6H9J@math.fu-berlin.de> weberwu@inf.fu-berlin.de (Debora
|>Weber-Wulff) writes:
|>   In response to the folks that offered the hacks for the lexer:
|>   sure, it's no problem to write a hack, but what if you want to
|>   prove your program correct (Arrrrrgh! She used that *word*)? 
|>   Lexers should be deterministic, finite state automata. DFSA can't
|>   count, neither can push-down automata. So adding your little hack just
|>   blows apart all the mathematics you might be able to use in the
|>   proof of correctness.
|>
|>Maybe so, but if you're not going to allow the lexer to count, then
|>you won't be able to track the line/column and give any reasonable
|>error message.

Maybe so?... Absolutely not!

The most rigourously designed language in common use, Occam uses indentation to
delineate blocks. If you are going to prove a compiler correct there are much
more serious problems than minor twiddling to the lexical analyser. There is no
divine law that states that only regular expressions are allowable for the front
end of a parser. There are plenty of ways that you can rigourously define
indentation. All that is required is to prove that the resultant grammar is
either not ambiguous or that the ambiguities do not change the semantics.

There are a number of people working on non LR(1) grammars about. On interesting
result achieved recently at the Oxford PRG was a system which could parse
ambiguous grammars in n log(n) time provided the ambiguities are definable in an
LR(1) grammar. No idea what practical value that has but anyway there you go.


|>Finally, regarding indentation I've heard plenty of arguments against
|>it but they've all been based on a particular (bad) implementation.
|>Haskell has an indentation rule (better than Miranda's IMHO) and I
|>haven't had any problems with it so far.

I don't think that indentation is inherently a bad idea. It does get messy if
you have 300 line procedures but there are plenty of arguments against 300 line
code segments! Occam got indentation wrong through being overly pedantic. There
is no real intrinsic value in giving PAR and SEQ equal importance. SEQ is much
more often used and should be the default. Also the equivalence IF () == STOP is
just plain crass, the identity IF () == SKIP would save a lot of typing *AND*
make it a damn sight easier to avoid bugs. I can't beleive that the semantics
would be one whit harder to formulate since the language would merely be the
subset of standard occam in which all IF clauses are terminated by a (TRUE:
SKIP) process. The law <IF-stop-unit> would have to be changed to <IF-skip-unit>
but that is all. These changes woud dramaticaly shorten many programs.


--

Phill Hallam-Baker
Newsgroups: alt.folklore.computers
From: ansok@cco.caltech.edu (Gary Ansok)
Subject: Re: what is halt_and_catch_fire?
Organization: California Institute of Technology, Pasadena
Date: Fri, 28 Aug 1992 17:54:12 GMT

Two that I have wanted on occasion in the past:

    XOI   eXecute Operator Immediately
    XOS   eXecute Operator Slowly      (and painfully... :-)

Gary

P.S.  If any real operators are reading this, remember:  :-) :-) :-)
(No, I don't want to start a thread on Real Operators (tm))
Newsgroups: alt.folklore.computers,comp.unix.misc
From: lasner@watsun.cc.columbia.edu (Charles Lasner)
Subject: Re: The need for an assembler (was: Favorite CPU)
Keywords: Pascal
Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner)
Organization: Columbia University
Date: Wed, 26 Aug 1992 08:06:52 GMT

In article <1992Aug22.043848.14218@decuac.dec.com> mjr@hussar.dco.dec.com (Marcus J. Ranum) writes:
>>You are ALL wrong.  The right way to write code is to do it all in a
>>high-level lanauge, then recode the speed-critical parts in assembly
>>language.
>
>	Nzzzt.
>
>	You forgot the "if" clause.
>
>	"The right way to write code is to do it all in a high level
>language and then *IF* *NECESSARY* recode speed critical parts in
>assembly language."
>
>	Some applications are bounded by I/O and further effort (other
>than improving basic algorithms) is wasted.
>
>mjr.

Wrong: by definition, the I/O bounded parts aren't speed critical, since their
speed isn't a function of the program, but rather the device.

However, even this simple statement doesn't always apply, since sometimes, 
it's possible to "cheat" around I/O bounds by faking the device in RAM, etc.,
at which point the speed-critical parts may very well become the limiting
factor towards any further improvement.

In some applications, the size of the program could be a factor towards its
speed, so the overall size reduction possible may be a consideration.

cjl

Newsgroups: alt.folklore.computers
From: fjh@cs.mu.OZ.AU (Fergus Henderson)
Subject: Re: The need for an assembler (was: Favorite CPU)
Organization: Computer Science, University of Melbourne, Australia
Date: Thu, 27 Aug 1992 16:58:23 GMT

lasner@watsun.cc.columbia.edu (Charles Lasner) writes:

>Fortran has no "singled-out" feature implemented in bastardized form like
>PASCAL.  Further, there have been non-standard implementations of Fortran
>around for years that allow symbolic labels on gotos.  You brought up Fortran
>not me, I prefer to take this argument to be PASCAL versus PL/I.  In PL/I
>the functions are recursive or not as I choose, Globality of variables is
>determined by my usage, not by arbitrary wimpy restrictions of the compiler,
>and all labels are equally symbolic.  I can use while-type loops or do-type
>loops, or if then goto else goto or whatever I want.  If I'm not sure what
>the compiler does about a side effect of a while as described above, I'll
>have to avoid it, but I know I can rather easily.  Further, I can transfer
>in and out of loops as I see fit, just like Fortran.

Why are we arguing about the relative merits of Fortan, Pascal,
PL/1, Assembler, C, and APL, when *all* of these languages are more than
a decade old?

I mean, surely you would agree that we have made *some* progress in the
last 10 years?

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature VIRUS is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!
-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature VIRUS is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!
Newsgroups: alt.folklore.computers
From: dsiebert@icaen.uiowa.edu (Doug Siebert)
Subject: Re: Branching in HLL vs. Assembler (was Re: The need for an assembler)
Date: Thu, 27 Aug 1992 21:27:52 GMT
Organization: ISCA

In article <1992Aug27.135129.24542@usenet.ins.cwru.edu> rfd@po.CWRU.Edu (Richard F. Drushel) writes:
>
>	That is something I have always wondered...being a self-taught
>programmer, on the outside of computer engineering looking in, I have
>heard the dogmatic "All GOTOs are bad" philosophy, with nary the
>acknowledgement that the CPU does nothing *BUT* GOTOs.

The reason people are taught that "all GOTOs are bad" in schools doesn't have
anything to do with the fact the CPU can only do GOTOs, or that a structured
statement like for or while compiles into code using GOTOs.  The reason is an
outgrowth of the idea of mathematically "proving" programs correct.  Any code
written with the traditional "structured" constructs can be mathematically
proven correct, but if there is a GOTO in that code, forget it!

In reality, most of us aren't concerned with proving code correct.  But for
certain applications this can be important.  I'm sure there are people who have
written programs where critical sections had to be proven correct, especially
if they are doing work for the defense department.  Currently it is totally
impractical to prove any but the tiniest programs correct, but it is possible
that at some point a combination of new language designs and automation will
make it feasible for reasonable-sized programs.

However, I'm sure that purists like Mr. Lasner will still claim assembly is
the best language and that writing provably correct programs in assembly is
possible if you work hard enough at it :-)

-- 
/-----------------------------------------------------------------------------\
| Doug Siebert                             | "I don't have to take this abuse |
| Internet:  dsiebert@isca.uiowa.edu       |  from you - I've got hundreds of |
| NeXTMail:  dsiebert@chop.isca.uiowa.edu  |  people waiting in line to abuse |
|     ICBM:  41d 39m 55s N, 91d 30m 43s W  |  me!"  Bill Murray, Ghostbusters |
\-----------------------------------------------------------------------------/
Newsgroups: alt.folklore.computers
From: neeri@iis.ethz.ch (Matthias Neeracher)
Subject: Re: TeX and C (was: you know when you're hacking too long when...)
Organization: Integrated Systems Laboratory, ETH, Zurich
	<4106@cruzio.santa-cruz.ca.us> <snippe.714993982@boerang>
	<marc.715098772@vieta.math.uni-sb.de>
	<1992Aug30.031603.8813@ccu1.aukuni.ac.nz>
Date: Tue, 1 Sep 1992 12:55:30 GMT

In article <1992Aug30.031603.8813@ccu1.aukuni.ac.nz> ecmtwhk@ccu1.aukuni.ac.nz (Thomas Koenig) writes:
>marc@vieta.math.uni-sb.de (Marc Conrad) writes:
>
>>That reminds me to a problem, I had, when I wrote a TeX-text, which should 
>>contain a compileable C-Programm (let's call it foo.c)
>>My first try was: 
>[...]
>>Any ideas ?
>
>Since you are not the first with that kind of problem, there are several
>solutions available: tgrind (that will do a good job at prettyprinting,
>too) and verbatim.sty. Check them out at your friendly neighbourhood TeX
>ftp site.  There even is a web for C, if you feel you need it.
>
>Unfortunately, I found nothing to prettyprint FORTRAN when it would
>have come in handy last year,

How about FWEB ?

>but then that's a mismatching of concepts,
>anyway :-)

Actually, most UN*X versions ship with a Fortran prettyprinter: "rm"

Matthias

-----
Matthias Neeracher                                   neeri@iis.ethz.ch
  "... Rice walked out wondering if the world was nothing but wimps,
   pimps, psychos and sex fiends" -- James Ellroy, _Suicide Hill_
Newsgroups: alt.folklore.computers
From: sarr@sinshan.citi.umich.edu (Sarr J. Blumson)
Subject: Re: uNIX on tired iron FAQ
Organization: University of Michigan, CITI
Date: Fri, 4 Sep 1992 14:12:09 GMT

In article <1992Sep4.133517.13039@cbnewse.cb.att.com>
LOGIN@cbnewse.cb.att.com writes: > 
>What about the Tandy 6000 and Microsoft/Tandy XENIX. It would run on 768K 
>of memory. Or even better yet. When Tandy first introduced XENIX to the 
>world (~1983) it would run on their Model 16A with only 256K of memory 
>required. A real dog, but it would run. All of these were M68000 based boxes 
>so maybe that says something about the Itel chip family.  

Not much.  In 1982 we were running Xenix on 8086 boxes from
Altos (with an Altos proprietary memory manager) and their own UNIX
port on the Onyx Z-8000 machines mentioned earlier.  Both were 512k
machines, and both worked well.


(Sarr Blumson)
Newsgroups: alt.folklore.computers
From: samw@bucket.rain.com (Sam Warden)
Subject: the REAL software pirates 
Organization: Rick's Home-Grown Un*x
Distribution: USA 
Date:  4 Sep 92 16:45:17 GMT

smith@sctc.com (Rick Smith) writes:

>I also remember some pointed rumors in the early 80s about various home
>computer software houses that got started by pirating the Unix
>portable C compiler and adapting it to run on Z80s and such.
 
From the rumors I've heard just about ALL of the big-name commercial
software outfits today, who are now so litigation-happy, got started
by appropriating existing code, using school computers for commercial
development, etc.  Like the old US railroad barons, they've gotten
untouchably wealthy by stealing from the public domain and will soon
have us in a stranglehold (of patents this time).  
-- 
 
samw@bucket.rain.com (Sam Warden) -- and not a mere Device.
From: avg@rodan.UU.NET (Vadim Antonov)
Newsgroups: alt.folklore.computers
Subject: Re: The need for an assembler (was: Favorite CPU)
Date: 3 Sep 1992 19:12:18 -0400
Organization: Berkeley Software Design
NNTP-Posting-Host: rodan.uu.net

In article <jimf.715546564@centerline.com> jimf@centerline.com (Jim Frost) writes:
>That balance seems to be at about six or seven people in documented
>experience (Brooks even thought so back in 1975).  Unfortunately six
>or seven people can't generate a million line program in a year no
>matter how hard they try -- they'd need to write about 150,000 lines
>of debugged code in that year.  Good programmers -- and I mean *very*
>good programmers -- can do *maybe* a third of that if they don't need
>to do outside documentation or administration, and don't take
>vacations.

Six *really* smarty people can sit down and think a bit and after
that they will be able to solve the problem in 100 thousand lines
and enjoy their vacations and fat bank accounts. Monster programs
reflect only the lack of imagination and overall low qualification
of their creators.

I had pleasure to see some VERY fat programs -- they're extremely
boring and with a minimal effort could be reimplemented in a proper
language with tenfold reducing of code size (providing someone
invented that language in the first place).

I *never* heard of any software project which can be implemented
only by brute-force efforts of zillions of underqualified programmers
under guidance of stacked layers of managers which never understood
what their subordinates do.

Want examples? Look at IBM.

Unfortunately it's really hard to get six smart people to work
together :-)

--vadim
Newsgroups: alt.folklore.computers
From: IQTI400@INDYCMS.IUPUI.EDU (macphil)
Subject: Re: Better dead than IBM
Organization: IUPUI
Date: Sat, 29 Aug 1992 02:44:44 GMT

In article <BtpKz8.369@hatch.socal.com>
richg@hatch.socal.com (Rich Greenberg) writes:
 
>In article <1992Aug28.072749.1@cc.curtin.edu.au> zcookbruc@cc.curtin.edu.au writes:
>
>Any IBM employee will tell you it stands for:  "I've Been Moved".
>(IBMers get transferred a lot.)
 
 
USA Today had an article about a contest for the filling in the acronym.
 
One of the mentioned winners was "Incredible Bowel Movement"
Xref: sparky alt.folklore.computers:13126 alt.religion.computers:566
From: koen@blade.stack.urc.tue.nl (Koen Holtman)
Newsgroups: alt.folklore.computers,alt.religion.computers
Subject: Re: Good source code to read?
Date: 26 Aug 92 13:58:01 GMT
Followup-To: alt.folklore.computers

avg@rodan.UU.NET (Vadim Antonov) writes:
 [....]
>     For the beginning, a halting
>analyzer which is able to handle any program which can run on
>the machine WILL NOT BE ABLE to run on the same machine simply
>because it will require additional memory (for the source program
>and for the primitive itself).
 [...]

Why would a halting analyser running on a machine with _infinite_
memory require any additional memory?

The halting problem is about machines with potentially infinite
memory (or programs that can get as much memory as they want), not 
about finite machines. 

If I see someone write `all programs', I assume that this includes the
programs that ask you to
 `insert an empty disk in drive 1 and press enter'.

>--vadim

Koen.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Koen Holtman                  TUE computing science     "Dat zieje wel"
koen@blade.stack.urc.tue.nl    (Ax:*p)==(*p&p!=&x)         --Multatuli