HDTenEightyP/NetNews huggingface dataset:
From: smith@sctc.com (Rick Smith)
Subject: Re: Longtime PDP-11 users, tune in now
Organization: SCTC
Date: Fri, 28 Aug 1992 21:00:20 GMT

linden@positive.Eng.Sun.COM (Peter van der Linden) writes:

>Theory: 
>   The PDP-11 assembler just put its output in "a.out" by default,

You mean "linker" not assembler. The first linker I used on an -11
didn't write a.out files. If you gave it file foo.obj it would
write file foo.abs ...

Rick.
smith@sctc.com    arden hills, minnesota
Xref: sparky alt.folklore.computers:13082 alt.religion.computers:554
From: bmb1021@ultb.isc.rit.edu (B.M. Buck )
Newsgroups: alt.folklore.computers,alt.religion.computers
Subject: Re: The halting problem (was Re: Good source code to read?)
Date: 25 Aug 92 20:06:40 GMT
Organization: Rochester Institute of Technology
Originator: bmb1021@ultb

In article <9223810.11723@mulga.cs.mu.OZ.AU> pdt@mundil.cs.mu.OZ.AU (Peter David THOMPSON) writes:
>john@mullet.gu.uwa.edu.au (John West) writes:
>>brnstnd@nyu.edu (D. J. Bernstein) writes:
>>>*The halting problem is decidable in practice.*
>
>>People can 'prove' otherwise as much as they like. The difference between
>>the machine in the proof and the one on my desk is that mine has a finite
>>memory. There is a finite number of possible programs (large, but still
>>finite), and a finite number of states they can be in. The proof requires
>>a very different situation. It proves absolutely nothing about real machines.
>>Can we please have an end to this? I see an infinite future of people saying
>>'it can be done!' 'no it can't!' ...
>>John West
>
> Sorry to confuse the issue a little, but I've always understood the
> halting problem to be:
>  "Given a machine architecture, the set of possible programs, and the
>  set of possible inputs, is it possible to write a program that
>  determines whether any program will or will not halt for any input?"

I always thought that it included the additional caveate "...in a finite
amount of time.", otherwise, a perfectly valid "solution" would be to
simply run the program, with the given inputs, and see if it finishes...

>
>The schemes previously proposed seem to rely on extending the machine
>somehow; getting a pair of machines, one half speed; running two copies
>of a program; and so on. It seems to me that any definitive answer to
>whether the halting problem is soluble in practice is going to have to
>deal with the following:
>	a) Finite but unbounded inputs (e.g. keyboard, /dev/zero)
>	b) The fact that any software solution is going to take up part
>	of the machine resources, thus reducing the number of programs
>	it is possible to run. Virtual memory doesn't count; I can in
>	principle (and quite possibly in practice) write a program that
>	uses all of the resources that the machine offers (for a finite
>	machine).  
>        c) The fact that hardware solutions are not the original machine.
>Anyone care to flame me on these? (Hint: part c)
another issue:
        d) Unpredictable inputs.  Since the solutions given rely on
           repeatedly running the machines with the same input over and
	   over again, it fails when the input is, say, the last 1000
           time-separations of scintillations in a geiger counter.

>
>* These opinions belong to pdt@munta.cs.mu.OZ.AU unless otherwise specified.
>You were expecting an intelligent, witty, and articulate .signature? Ha!

Just my two cents...
  Buddha BUck (bmb1021@ultb.isc.rit.edu)
Newsgroups: alt.folklore.computers
Subject: Re: ISO date format
From: gavin@mdcbbs.com (Gavin Matthews)
Date: 26 Aug 92 03:09:17 PDT
Organization: Shape Data - a division of EDS Ltd

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?

ISO 2014-1976 All numeric date format
From: "scott gregory" <scott.gregory@canrem.com>
Newsgroups: alt.folklore.computers
Subject: apple /// (and many o
Date: 3 Sep 92 06:27:51 EST
Reply-To: "scott gregory" <scott.gregory@canrem.com>
Distribution: alt
Organization: Canada Remote Systems

<<<David Steffen> said to All> on 09-01-92>

DS>As I posted last time this topic came up, I have a relatively modest
DS>collection of "antique" micros, and the collection of the same is of
DS>great interest to me.  I wonder if there is some way to set up some
DS>kind of archive/newsgroup/mailing-list/club of antique computer
DS>collectors?

Yeah, yeah.  Me too.  Particular interest in Apple //, Commodore PET and
a few others.

*Scott Gregory* - - - - - - - - - - - Unix/X Guru in training...
- - - - - - - scott.gregory@canrem.com - - - - - - - - - - - - - - - -
---
  DeLuxe 1.21 #5411  
--
Canada Remote Systems  - Toronto, Ontario/Detroit, MI
World's Largest PCBOARD System - 416-629-7000/629-7044
Newsgroups: alt.folklore.computers
Subject: Re: Computers killing people? (WAS Re: 9 track data storage???)
From: alanb@sdl.mdcbbs.com (Alan Braggins)
Date: 26 Aug 92 16:01:44 GMT
Organization: Shape Data (Division of EDS), Cambridge UK
In-reply-to: parry@yoyo.cc.monash.edu.au's message of Wed, 26 Aug 1992 03:13:19 GMT

>>>>> On Wed, 26 Aug 1992 03:13:19 GMT, parry@yoyo.cc.monash.edu.au (Tom J Parry) said:

> Nobody seems to have considered that the printer could be 'infected' (or
> built) with the virus in _IT_. Such a change to the printer's software
> (let's assume its a laser printer so it's effectively a computer itself)
> could be made to change output, add errors into location data, troop
> movements, whatever. i don't see the _necessity_ that a secondary machine
> be infected BY the printer.

If this code is built into the printer and can't get out, it's hardly a virus.
I suppose a virus that travels between PCs and does its work when it finds one
with a suitable printer by downloading code to the printer and cleaning itself
up on the PC (so avoiding being found when the PC is examined when the printer
has problems) is possible.

More likely - the printers in question aren't connected to PCs.
Even more likely - the story is a complete red herring. Various people have
hinted they know the real story, but it's unlikely to be published on the net.
--
Alan Braggins, Shape Data (A Division of EDS Ltd), Cambridge, UK +44-223-316673
   "Any technology distinguishable from magic is insufficiently advanced."
 "My employer does not necessarily share my views - but I'm working on it."
From: ddb@tdkt.kksys.com (David Dyer-Bennet)
Sender: FredGate@tdkt.kksys.com
Newsgroups: alt.folklore.computers
Subject: Indentation
Date: Wed, 26 Aug 1992 21:39:15 -0600

 TS> Graphics computers have been shipping since 1976 (Apple II).
 TS> Why are you all still programming completely in text?

Because it's the only interchange standard among systems.  Because
it's suitable to the task.  Because it's the most expressive
programming medium currently available.

 * Origin: Terraboard, Mpls MN: Home of the SF echo (1:282/341.0)
Newsgroups: alt.folklore.computers
From: lemay@epx.cis.umn.edu (Lawrence LeMay)
Subject: Re: You know when you're hacking too long when...
Organization: University of Minnesota
Date: Mon, 31 Aug 1992 17:13:18 GMT

In article <1992Aug30.231556.3672@vax.muskingum.edu> geschwent@vax.muskingum.edu writes:
>In article <1992Aug25.053335.22465@blaze.cs.jhu.edu>, arromdee@jyusenkyou.cs.jhu.edu (Ken Arromdee) writes:
>> In article <a=anyyn@lynx.unm.edu> quirk@pioneer.unm.edu (Gym Z. Quirk) writes:
>>>Come to think of it, It's probably some marketoid's miscalculation.
>>>He included the bun in the list of ingredients (making a total of 10)
>>>and forgot to consider the consequences of *not* having a bun.
>
>One tends to agree, but nobody has pointed out that *a bun* consists of
>2 objects itself, thus 11, etc.
>
>P.K.  

The 10th option is probably the Whopper Jr (a small sized whopper). 

-Larry (I'd like a Double Whopper Jr please!) LeMay
Newsgroups: alt.folklore.computers
From: rupert@europa.inmos.co.uk (Rupert Pigott (PFUE))
Subject: Re: Better dead than IBM
Organization: INMOS Limited, Bristol, UK
Date: Fri, 28 Aug 1992 14:43:50 GMT

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.
{Stuff omitted}
|> 
|> Frank Stuart           |   Slower traffic keep right.  |  Don't Panic
|> fstuart@eng.auburn.edu |   MMMMMmmmmm lutefisk.        |  Never moon a werewolf

How about "International Bull-cookie Merchants" ?

rupert@inmos.co.uk / rupey@dcs.warwick.ac.uk
From: parke@star.enet.dec.com (Bill Parke)
Newsgroups: alt.folklore.computers
Subject: Re: opcodes
Date: 1 Sep 92 17:56:09 GMT
Reply-To: parke@star.enet.dec.com
Distribution: alt
Organization: DIGITAL - VMS Engineering


In article <199227.337.12491@execnet>, "jeff zeitlin" <jeff.zeitlin@execnet.com> writes:
|>Path: nntpd.lkg.dec.com!news.crl.dec.com!deccrl!caen!uunet!psinntp!execnet![jeff.zeitlin@execnet.com]
|>From: "jeff zeitlin" <jeff.zeitlin@execnet.com>
|>
|>  [...deleted for brevity...]
|>
|>  I seem to remember seeing a few variations on some of them, as
|>  well as variations on the theme...
|>
|>  BBL           Branch on Burned-out Light
|>  DWIM          Do What I Mean
|>  HCF           Halt and Catch Fire          (yes, I really saw it!)
    ^^^   On the 360 "Orange" (or Yellow?) pocket card.  I saw one in 67

|>  IDM           Invert Dot Matrix
|>  JRL           Jump to Random Location
|>  RWD           ReWind Disk
|>  XOP           eXecute OPerator

    XOI           eXecute OPerator Imediately - Same source as above

I always likes

        TRASH     Tip Rack And Smash Human


|>
|>  J/
|>  jewff.zeitlin@execnet.com
|>
|> * OLX 2.2 * umop ap!sdn s! an!l6ef s!yf
|>--
|>Executive Network Information System  (914) 667-4567
|>International ILink Host
|>
Bill Parke 			parke%star.enet.dec@decwrl.dec.com
VMS Development			decwrl!star.enet.dec.com!parke
Digital Equipment Corp		parke@star.enet.dec.com
110 Spit Brook Road ZK01-2/D59, Nashua NH 03063

The views expressed are my own.
Xref: sparky alt.folklore.computers:13137 comp.unix.misc:3372
From: swaim@owlnet.rice.edu (Michael Parks Swaim)
Newsgroups: alt.folklore.computers,comp.unix.misc
Subject: Re: The need for an assembler (was: Favorite CPU)
Date: 26 Aug 1992 18:38:46 GMT
Organization: Rice University

In article <1992Aug26.065533.14600@news.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
>So, in your book, a competent person is someone writing in C, who really
>hasn't a clue in the "under the hood sense" yet is expected to not make
>unreasonable amounts of programming errors, while is statistically likely
>to not comment well, and is also likely responsible for at least their
>fair share of the errors found in the released code of this world.  I'm glad
>that they may be other measures of competency :-).

  It depends. If the person's just a bad typist, and can lucidly explain
what he's doing, and why, then he's I'd call him competent, even if he just
knew C, and had no idea what his CPU was. Someone who writes code without
thinking about where he's going is sloppy, and will generate lots of 
interesting bugs.

>  Indeed, the usual argument given to use
>C is to *avoid* what assembler offers!

  That's because assembly's generally harder than C. In assembly, you can
use whatever calling conventions you like, as long as you're consistant.
With C, I (generally) don't have to worry about calling conventions. While
this degrades performance, it's one less thing for me to have to think
about. I consider this a good thing. I also don't have to worry about
addressing elements in an array larger than 64K on my '386. I can also
write programs that'll run on the Sparcs at school, which would be really
difficult in assembler.

  On the other hand, any programmer should have SOME idea of why the machine
works the way it does. Not necissarily being a competent assembly programmer,
but understanding tradeoffs in the system architecture.

  As an aside, how many people here have programmed in only 5 or less
languages? I've used at least 10 that come to mind immediately, and I don't
consider myself that experienced. Most languages involve some sort of
tradeoff, and I think that people should use whatever language that's both
available and the programmer feels comfortable with. I don't think that C
or assembly is the "best" language most of the time.



-- 
Mike Swaim            | "What izzis wunnderful thing? S' Beautiful
swaim@owlnet.rice.edu | I think I'll put my tongue on it." -Arthur
Rupp doesn't even know who I am,
 much less care what I think
Newsgroups: alt.folklore.computers
From: lasner@watsun.cc.columbia.edu (Charles Lasner)
Subject: Re: Computers killing peo
Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner)
Organization: Columbia University
Date: Sat, 29 Aug 1992 08:30:28 GMT

In article <21224239@zl2tnm.gen.nz> don@zl2tnm.gen.nz (Don Stokes) writes:
>lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
>> In article <3894.168.uupcb@ssr.com> dick.zeitlin%acc1bbs@ssr.com (Dick Zeitlin)  writes:
>> >TO> .With a SERIAL port, maybe. But very unlikely. Few printers have
>> >  > .the transmit data line hooked up.
>> >
>> >You run printers with serial interfaces that don't support XON/XOFF
>> >interface?  Strange...  Which printers don't support this??
>> 
>> Unfortunately, most of the IBM-PC world does it this way :-(.  The printer
>> usually is ready, and accepts chars spewing out the port at the rate of
>> the connection until the buffer gets say, 3/4 full.  At that point, it
>> lowers one of the handshakes like CTS which makes the PC end unable to
>                                    ^^^
>Try DSR.  You wire the RTS line (or whatever the printer uses as a handshake)
>to the PeeCee's DSR line.

I believe that while you are correct, there are gender benders, and various
attempts at null modems that DEC would puke at, but used with PC's, that will
bring the signal out as CTS handshaking RTS at some connecting point.  And
again, were a pair of modems inserted into the picture instead of the
basic null-modem portion (if necessary, picture what's used as being the
cascade of a real correct null-modem in series with whatever kludge you need
such that the cascade substitutes for some aspect of the printer connection.
Now substitute two real modems and a phone connection for the proper null
modem portion, and watch the phone hangup when this "protocol" is attempted
on a (nearly) full buffer.

cjl
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 17:08:10 GMT

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

>>>  Indeed, the usual argument given to use
>>>C is to *avoid* what assembler offers!
>>
>>  That's because assembly's generally harder than C.
>
>This is the first time someone used that word.  So, this would imply that
>C is to be used as an "easy way out" of getting "something" to work even if
>it's not necessarily the "best" thing.  In other words, to advance the art of
>mediocrity and expediency and "close enough for government work".

Just because something is easy doesn't mean it is an "easy way out".

A good craftsman will use the best tool for the job, and that usually means
using whichever tool makes it "easiest" to achieve what they are after.

For a lot of things, C *is* the best tool for the job, precisely BECAUSE
it is "easier" than assembler (not to mention more portable, more maintainable,
etc., etc.)

-- 
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,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:01:42 GMT

In article <1992Aug21.232934.17951@cirrus.com> dhesi@cirrus.com (Rahul Dhesi) 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.  Anybody who exclusively uses assembly language, or exclusively
>uses a high-level language, belongs on Usenet.
>-- 
>Rahul Dhesi <dhesi@cirrus.com>
>also: dhesi@rahul.net

If someone will go back and check, they will find that this whole thing
started because some people wanted to have us believe that hll-exclusivity
was the only way to go.  I challenged that, and never said that all projects
should be done all-assembler, but rather that assembler was largely 
underutilized for a variety of reasons.

Furthermore, the only way to achieve what Rahul Dhesi states *demands* 
knowledge of assembler, which goes even further than my point that it
helps an hll-user to know it, which certain people have taken to 
misinterpreting for their own purposes, etc.

cjl
From: lasner@watsun.cc.columbia.edu (Charles Lasner)
Newsgroups: alt.folklore.computers
Subject: Re: The need for an assembler (was: Favorite CPU)
Date: 3 Sep 92 09:40:56 GMT
Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner)
Organization: Columbia University

In article <jimf.715441613@centerline.com> jimf@centerline.com (Jim Frost) writes:
>
>I don't have any particular "brand" of organization.  I merely
>maintain that it's easier for most people to write and maintain
>organized code when they have some help doing so -- and usually that
>help is some kind of HLL.  There's over twenty years of hard evidence
>showing that HLL use results in less buggy code and much better
>overall programmer productivity in mid-size to large projects to back
>up my opinion (if you don't think so then compare MULTICS to OS/360
>and contrast the ESS projects -- they provide excellent examples).

Programming by committee enforces your requirement to have low expectation
of performance of any project.  Anything that helps trim the body count
will have more improving effect than anything else.  HLL may attract too
many of the wrong kind of people depending.  Management may have hidden
agendas like hiring 2*N mini-experienced people for 2/3 the total salary
demanded by N well-experienced people, so you may be stuck.  Such is life
in a mediocracy :-(.

>
>>I always assume that I am writing for someone as good
>>as I am, or is there a problem with that?
>
>Yes, there is a problem with that.  If you're any good at all then
>statistically speaking it's very likely that the next person to play
>with your code will *not* be as good as you are.  They'll need to be
>able to understand and modify your code anyway.  And what if you're
>the next person and *you're* not as good as the guy who wrote it?
>Have you ever come across an algorithm implementation you just plain
>couldn't understand, but which you needed to fix or modify anyway?

Yes, I needed to study some code to see what it was doing, and doing it
wrong btw.  I sure wish it had been commented even 1/10th as much as I do.
I *fanatically* comment.  If they can't figure out what I did, and need to
modify it, get someone else.  Or is the computer industry another old boy
network merely there to ensure full employment :-).

>
>Have you ever tried to explain your code to someone who just doesn't
>get it?  If so, you've already seen the problem.  Now imagine how
>often that happens in a million line project.

Why would I want that person in the project at all?  If management is
foolish enough to support the participation in a project of that kind of
dunce, the thing is doomed from the start.  Army of monkeys approaches
never work.

cjl



>
>Happy hacking,
>
>jim frost
>jimf@centerline.com
From: lasner@watsun.cc.columbia.edu (Charles Lasner)
Newsgroups: alt.folklore.computers
Subject: Re: The need for an assembler
Date: 3 Sep 92 10:57:18 GMT
Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner)
Organization: Columbia University

In article <1992Sep3.061925.3942@unmvax.cs.unm.edu> ctm@ardi.com (Clifford T. Matthews) writes:

[lots of bullshit deleted]

Post your so-called example; let others see if it's consistent with the
assembler code, or does it suffer from incompatibility with C at the source
level?  (If I can provide data to the algorithm that makes it flunk, then
C wasn't good enough to catch that; a programmer assumes that generated code
is functional.  In assembler, I can make up the "rules" that an algorithm
applies only to if need be.  The language can't support a special-case
limited range algorithm, because code writers in C want to abstract themselves
from hardware details.  So even if you in fact duplicate the code per se, you
have tied the code writer to being a micro-level "inspector" of his
binary.  I seriously doubt if anyone wants to use a hll and have to do that.
The point is that the limited range test can only be used on contrived
data types, not on all integers; a compiler that implements this code as a
general solution is creating buggy code; if this is meant to be looked at with
awe or admiration, then if so by whom?)

I won't respond to the rest of the fatuous post except to say good luck in
making your million.  Just don't use me as a reference when you don't make it.

As to interpreters being smaller code, this was posted by me; I suggested that
the best way to implement truly higher-level languages was with an interpreter
at the top level calling assembler-written elements at a lower level to
implement details not describable any other way.

Furthermore, the poster's attempting an end run around the larger issue:

There has been discussion of several classes of programming areas where
hll comes up short; the entire subject matter of his attempt to "win" this
argument is overly focused on just one specific example of one kind of
assembler-dominant method in the most insignificent class of programming
areas mentioned in this thread by myself and others, some of which have
long departed this thread due to the wild and hysterical nature of much of
it as it aberrates wildly in unproductive directions.  I'll not speak for
them, but I doubt that many of them are interested enough in posting their
examples of the other classes of areas not addressed by example, but only
by reference.  Some people don't have the patience, etc.

If anyone has noticed, I have largely taken a defensive posture throughout
this "exercise" posting only to respond, not attack.  As long as people 
regard this issue as an inflamed "war" that's what you get instead of a
useful technical forum.  Anyone who wants to include elements of either their
resume or product advertising as part of their argument is posting to the
wrong newsgroup; try alt.dev.null or alt.jobs.wanted.

cjl
From: chuck@cco.caltech.edu (Charles M. Higgins)
Newsgroups: alt.folklore.computers
Subject: Re: Better dead than IBM
Date: 27 Aug 92 23:17:50 GMT
Organization: California Institute of Technology, Pasadena

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.

  Among IBM employees (I was one for years), it stands for
     

        I've Been Moved


        Chuck Higgins, Caltech EE