HDTenEightyP/NetNews huggingface dataset:
From: fjh@mundil.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: Crashing in hacker haven (was: You know when you're hacking too long when...)
Keywords: hacking
Organization: Computer Science, University of Melbourne, Australia
Date: Wed, 26 Aug 1992 16:53:59 GMT

claird@NeoSoft.com (Cameron Laird) writes:

>In article <1992Aug25.060803.4021@u.washington.edu> fetrow@biostat.washington.edu (David Fetrow) writes:
>>richg@hatch.socal.com (Rich Greenberg) writes:
>>>. . . instead of phoning someone local (same company, same city) you
>>>send email even when you know they have voicemail/answering machine.
>>
>> Naw. Email doesn't usually wake a person up when they've been on a hacking run.
>>
>> That includes the office number (I suspect many of us have sleeping materials
>>stashed in the office for the occasional allday+allnight+allday).
>			.
>			.
>			.
>Some don't?

Who needs sleeping materials? Sleep is for wimps. 

-- 
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!
From: samw@bucket.rain.com (Sam Warden)
Subject: Re: The need for an assembler
Organization: Rick's Home-Grown Un*x
Date: 26 Aug 92 17:43:07 GMT

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

>In article <samw.714592304@bucket> samw@bucket.rain.com (Sam Warden) writes:
>>A chainsaw is the only tool anyone will ever need.
>>No! A scalpel is the only tool anyone will ever need!
[ ... ]
>I have my own opinion, but what's your opinion about which is which?
>cjl

OK.  I was going to let that pregnant question hang, Zen-like, in the
air, but since everyone is asking: the original (late-night) thought
was that the hll was the chainsaw (less effort for the result but  
a less precise result) and vice versa.  Others may differ.  8-)

-- 
 
samw@bucket.rain.com (Sam Warden) -- and not a mere Device.
From: jt@dcs.ed.ac.uk (Sebastian Theriault)
Newsgroups: alt.folklore.computers
Subject: Re: TeX and C (was: you know when you're hacking too long when...)
Date: 29 Aug 92 17:21:00 GMT
Reply-To: jt@dcs.ed.ac.uk (Sebastian Theriault)
Organization: Laboratory for the Foundations of Computer Science, Edinburgh U

In article <42778@skye.dcs.ed.ac.uk> jt@dcs.ed.ac.uk (Sebastian Theriault) writes:
[example of how to include a C program in a LaTeX document deleted...]

>foo.S:
>-----
>/* } \begin{verbatim} 

That should read:
/* \begin{verbatim}

A gremlin inserted a '}' in my previous posting!

--
Jean-Sebastien Theriault               "This is my signature quote."
jt@dcs.ed.ac.uk                                            -me
From: pjdm@chmeee.enet.dec.com (Peter Mayne)
Newsgroups: alt.folklore.computers
Subject: Re: Branching in HLL vs. Assembler (was Re: The need for an assembler)
Date: 2 Sep 92 02:53:17 GMT
Reply-To: Peter.Mayne@cao.mts.dec.com
Organization: Digital Equipment Corporation



When I did this kind of stuff (program correctness proofs), we also did
program inversions.

This leads to such things as the comefrom statement, the inverse of goto. Your
program executes until it gets to a point referenced by a comefrom statement
somewhere in your program, then execution resumes at the comefrom.

The troba (inverse of abort) statement takes your processor's state from
"undefined" to exactly what you want it to be, a fast way of calculating
prime numbers, Mandelbrot sets, etc.

Being able to treat a program mathematically isn't as silly as it sounds. One
of the exercises we did was a proof that was quite difficult mathematically,
but became (comparatively) simple when translated into a program and
"debugged".

And we didn't use goto, either. :-)

PJDM
--
Peter Mayne                     | My statements, not Digital's.
Digital Equipment Corporation   | WNT is not vapourware,
Canberra, ACT, Australia        |     it was released in 1978.
From: billaud@mistral.greco-prog.fr (Michel BILLAUD)
Newsgroups: alt.folklore.computers
Subject: Re: Longtime PDP-11 users, tune in now
Date: 2 Sep 92 16:28:34 GMT
Organization: GRECO Programmation du CNRS - Bordeaux,France

In article <l9t0gjINNjon@exodus.Eng.Sun.COM>, linden@positive.Eng.Sun.COM (Peter van der Linden) writes:
|> Has it ever struck you as strange that the output file
|> from compiling any C file goes into "a.out"?

|> It's somewhat of a nuisance that the final binary goes into a.out 
|>     -- you might forget where it came from 
|>     -- it will be overwritten by the next compilation.

Not such a nuisance IMHO, if you consider the situation of 1st year 
students who use to write, compile and test thousands of totally
useless programs, too lazy to build subdirectories. It saves gigabytes !

Other gigabytes are saved when poor student X types "rm *>bak" instead
of "rm *.bak". The Unix way of garbage collecting ?  :-)

Michel

-- 
Michel BILLAUD                 :  billaud@geocub.greco-prog.fr
Departement d'Informatique     :  phone W: 56.84.57.92  // 56.84.69.22
IUT "A", Universite Bordeaux I :  "Je veux jouer de l'helicon
33405 Talence  (FRANCE)        :        pon pon pon pon !    "
Newsgroups: alt.folklore.computers
From: marc@vieta.math.uni-sb.de (Marc Conrad)
Subject: TeX and C (was: you know when you're hacking too long when...)
Organization: U of Saarbruecken, Dept. of Computational Linguistics
Date: Sat, 29 Aug 1992 14:32:52 GMT


>BTW Have you been using Latex too long when your (handwritten) letters 
>include things like \begin{verbatim} ? I recently did that when writing
>a letter that included a newspaper article.

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: 
\begin{verbatim}
\input{foo.S}
\end{verbatim}
Try it, and you will see, that it don't work :-).
My solution was then to write \begin{verbatim} and \end{verbatim} 
in the file foo.c itself. But it's not a good solution, because then 
compilation of foo fails....
Any ideas ?

--
     \   /                     | Marc Conrad, Universitaet des Saarlandes 
      \ Luxemburg              | marc@math.uni-sb.de  phone: 0681 302-2297
France \|   Germany            | these opinions are not necessarily these   
        \x <---- you are here! | of the SIMATH-group (and maybe even not mine).
Xref: sparky alt.folklore.computers:13170 comp.unix.misc:3381
Newsgroups: alt.folklore.computers,comp.unix.misc
Subject: Re: The need for an assembler (was: Favorite CPU)
From: alanb@sdl.mdcbbs.com (Alan Braggins)
Date: 27 Aug 92 11:05:23 GMT
 ex.com><1hWg3m#4Vl3RN4DjxvS3d3FGK4Nt5RG=esr@snark.thyrsus.com><1992Aug26.075307.15738@news.columbia.edu>
Organization: Shape Data (Division of EDS), Cambridge UK
In-reply-to: lasner@watsun.cc.columbia.edu's message of Wed, 26 Aug 1992 07:53:07 GMT

>>>>> On Wed, 26 Aug 1992 07:53:07 GMT, lasner@watsun.cc.columbia.edu (Charles Lasner) said:

> In article <1hWg3m#4Vl3RN4DjxvS3d3FGK4Nt5RG=esr@snark.thyrsus.com> esr@snark.thyrsus.com (Eric S. Raymond) writes:

>>who agrees with you.  I think there's some truth to Mr. Lasner's claim that
>>learning assembler *improves* one's HLL, but characterizing anyone who
>>doesn't know assembler at all as incompetent is absurd.

> OK, we all know that there is a segment of our industry cranking out poor
> HLL code, and there is another segment doing a better job.  Anyone want to
> counter the statement that *most* of those in the first segment are also
> somehow good assembly programmers?  Let me be the first :-).

And *most* of those in the second are good assembly programmers, and would consider
assembler a better language to do their job? Rubbish. They produce good HLL code.
My code is expected to run on >10 different architectures, including some which
didn't exist when it was written. My limited knowledge of assembler has very
rarely, if ever, been helpful in doing that.

> If my remark is so self-serving, then let me see either of you defend how
> ignorance of assembler helps your hll skills.

Let me see where anyone has claimed that "doesn't write assembler doesn't
imply incompetent" is the same thing as "ignorance of assembler helps your
hll skills", and this might be relevent to the discussion.
--
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."
Newsgroups: alt.folklore.computers
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: Indentation
Organization: Computer Science, University of Melbourne, Australia
Date: Wed, 2 Sep 1992 16:02:37 GMT

dick.zeitlin%acc1bbs@ssr.com (Dick Zeitlin)  writes:

>I ... believe in significant and uniform naming conventions.  Try
>the following.  (Drummed into all our customers by my former
>employer...)
>
>Variables are composed of a prefix, root, and postfix.
>
>Prefixes: b        byte
>          c        count
>          ch       char
[...]
>             etc.
>
>Suffixes: Ret        returned from call
>          Max
>          Min
[...]
>And so far into the night.  It passes enough information so that it's
>easy to spot if the wrong kind of variable is being passed to a routine.
>Makes code quite readable and maintainable.  Try it, you'll like it!

This practice of encoding variable types into their names is known
as Hungarian notation. It is useful in untypes languages such as assembler
and BCPL, but serves little purpose in strongly typed languages such
as C++, where the compiler automatically checks the types for you.
Instead of "mangling" the names by hand, you can get the compiler
to mangle them for you! Most C++ compilers automatically "mangle" the
names to include type information before passing them to the linker,
so that you can have type-safe linkage.

-- 
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!
From: Volker.Kaechele@quattro.stgt.sub.org (Volker Kaechele)
Sender: FredMail@quattro.stgt.sub.org
Newsgroups: alt.folklore.computers
Subject: Re: Better dead than IBM
Date: Sun, 30 Aug 1992 15:56:00 -0200

> What does IBM *really* stand for?  Let me know if you know the answer and
 
International Bubblegum Machines
I've Been Moved (Moving seems to be a hobby within IBM departments)
 
Chow-Chow
 
Volker

 * Origin: Aber da unten war's warm! Es war schoen! (2:244/55)
Xref: sparky alt.folklore.computers:13449 comp.unix.misc:3454
From: 01ksdavis@bsu-ucs.uucp
Newsgroups: alt.folklore.computers
Subject: Re: Better dead than IBM
Date: 1 Sep 92 05:15:46 GMT

In article <715247949.F00001@quattro.stgt.sub.org>, Volker.Kaechele@quattro.stgt.sub.org (Volker Kaechele) writes:
>> What does IBM *really* stand for?  Let me know if you know the answer and
>  
> International Bubblegum Machines
> I've Been Moved (Moving seems to be a hobby within IBM departments)
>  
> Chow-Chow
>  
> Volker
> 
>  * Origin: Aber da unten war's warm! Es war schoen! (2:244/55)
	

	I have every reason to believe it is an acrononym (since when did any
computer company stand for anything?) for 


	Incredibly Boring Machine!!
Newsgroups: alt.folklore.computers
From: peter@taronga.com (Peter da Silva)
Subject: Re: Branching in HLL vs. Assembler (was Re: The need for an assembler)
Organization: Taronga Park BBS
Date: Fri, 4 Sep 1992 11:38:59 GMT

In article <1992Aug31.160756.23324@news.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
>a)	That's ludicrous since no code does a GOTO the middle of a module

Coroutines?
Entry?
Call with label?
For that matter I've seen a lot of:

	mod1	entry stuff
		yadda yadda yadda
	cleanup	pop	buncha registers
		save	return value
		return

	mod2	entry stuff
		yadda yadda
	clean2	pop regs
		save different return value
		return

...

	mod999	entry stuff
		yadda yadda yadda
		jmp	cleanup

...

	mod1024	entry stuff
		yadda yadda yadda
		beq	cleanup
		jmp	clean1

Particularly in small language interpreters where space was a premium.
Putting the common return code inline in the most common case saves a
jump instruction.
-- 
                                                                `-_-'
                         Have you hugged your wolf today?        'U`

Peter da Silva, Taronga Park BBS, Houston, TX  +1 713 568 0480/1032
Newsgroups: alt.folklore.computers,comp.unix.misc
From: nevin@apple.com (Nevin ":-]" Liber)
Newsgroups: alt.folklore.computers
Subject: Re: 5ESS & Big projects (Was: The need for an assembler)
Date: 25 Aug 92 03:48:50 GMT
Followup-To: alt.folklore.computers
Organization: Apple Computer, Inc.

In article <pfe.714483580@meryl>, pfe@meryl.csd.uu.se (Per Ekman) wrote:

> What was (is?) 5ESS about? Maybe someone involved could tell us some
> horror-stories or anecdotes about being involved in such a mega-project.

It's a telephone switch, around 50M lines of C as of about two years ago. 
Variable names were only significant to 8 characters, with the first two
used for the subsystem abbreviation, leaving only six for readability. 
What a mess.
___
NEVIN ":-)" LIBER, RISC Porting Specialist/Blue Meanie, Mac System Software
 email:     nevin@apple.com        paper:  Apple Computer, Inc.
 voice:     (408) 974-MIX1                 20525 Mariani Avenue, MS: 81-GC
 AppleLink: BADENOV                        Cupertino, CA 95014
Xref: sparky alt.folklore.computers:13208 comp.unix.misc:3393
From: avg@rodan.UU.NET (Vadim Antonov)
Newsgroups: alt.folklore.computers,alt.religion.computers
Subject: Re: Good source code to read?
Date: 25 Aug 1992 13:52:34 -0400
Organization: Berkeley Software Design
NNTP-Posting-Host: rodan.uu.net

In article <STEVEV.92Aug24235052@miser.uoregon.edu>
stevev@miser.uoregon.edu (Steve VanDevender) writes:
>Self-reference in proofs
>does not make them "false"

You porobably missed the context. Original poster was suggesting
that it is a proof of insolvability of halting problem for
FINITE machines. Evidently, a halting predicate over finite
set of algoritms with N bits of state information can be computed
in time not exceeding O(2^N).

The proofs employing self-reference make sense in dealing with
infinife sets.

>Your description of an _external_ device for determining the
>halting status of a program appears to be correct

Yep, i think that a halting predicate for algorithms
with N bits of state cannot belong to that class of algorithms.
It doesn't make it incomputable anyway. As for _external_
devices -- anybody familiar with the concept of single-step
traps can do it without any additional hardware on any real
machine.

>Dan Bernstein's claim that "the halting problem is solvable *in
>practice*" is mostly correct.

I don't agree because there are simple examples of practically
insolvable problems (like factoring of large prime numbers).
If you have such a problem and construct a program which loops
or stops depending on the result of the factoring you cannot
determine if it halts in a practical time.  This is what the
cryptography is about.

>It is possible to write a program
>that analyzes other programs and determines their halting status;
>the vast majority of programs that it would encounter are
>decidable.

Or all of them. If P = NP.

>It is just that not _all_ programs that it could be
>asked to analyze are decidable--there is a small but important
>class of programs that are not decidable, one of which is the
>program for the halting problem solver itself, modified so that
>it goes into an infinite loop when the program it is analyzing
>halts, fed its own source code as input.

You fell in the very same trap. 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). It still has NOTHING to do with
the solvability of the halting problem.

--vadim
From: dick.zeitlin%acc1bbs@ssr.com (Dick Zeitlin) 
Newsgroups: alt.folklore.computers
Subject: Re: Favorite CPU
Date: 25 Aug 92 00:40:00 GMT
Distribution: world
Organization: Advanced Computer Concepts BBS, New Rochelle, NY 914-654-1981
Reply-To: dick.zeitlin%acc1bbs@ssr.com (Dick Zeitlin) 

PZ> .Didn't one of the Air Force's recent jets have a flight control system tha
  > .caused the plane to flip over when it crossed the equator into the souther
  > .hemisphere?

Urban legend.  Aside from all other considerations, nothing in the
attitude control of the aircraft cares about, or knows about, the
latitude and/or longitude of the aircraft.

But it makes a good story!  <~>

        D/

 * OLX 2.2 * Dick.Zeitlin%acc1bbs@ssr.com
From: dick.zeitlin%acc1bbs@ssr.com (Dick Zeitlin) 
Newsgroups: alt.folklore.computers
Subject: Re: Flash pix
Date: 2 Sep 92 21:51:00 GMT
Distribution: world
Organization: Advanced Computer Concepts BBS, New Rochelle, NY 914-654-1981
Reply-To: dick.zeitlin%acc1bbs@ssr.com (Dick Zeitlin) 

DG> .Talking about taking flash photo's. I once heard a story of a demo of some
  > .sort of new computer (no details given) which has some parts in EPROM (you
  > .know, the PROMS you can clear by shining light on its top). They had hidde
  > .this new computer behind a curtain. When the room was filled with all kind
  > .of news people, including photographers, they removed the curtain. On this
  > .very moment every photographer in the room started taking his 'exclusive'
  > .picture. But as the technicians had forgotten to seal the EPROM's erasing
  > .windows the flash light cleared the EPROMs or at least erased them enough
  > .to be unable to continue with the demo.

Unlikely.  It takes quite a bit more energy to erase an EPROM than what
those flashes would provide.  More likely is the fact that an EPROM
wasn't properly programmed.  In that case, even time alone could cause a
fault.

 * OLX 2.2 * Real Pilots enjoy NDB approaches to minimums!  Inverted!!
                                                 
Newsgroups: alt.folklore.computers
From: alawrenc@sobeco.com (a.lawrence)
Subject: Re: On the care and feeding of GOTOS
Reply-To: alawrenc@sobeco.com
Organization: Lawrence & Assc.
Date: Tue, 1 Sep 92 00:00:34 GMT

In <5235@tuegate.tue.nl> koen@blade.stack.urc.tue.nl (Koen Holtman) writes:

>rh@smds.com (Richard Harter) writes:
> [....]
>>Or at least you can interpret them that way.  As Knuth observed in one
>>of his essays, proof of correctness of goto/label programming is very
>>simple -- for each label there is an assertion that states what conditions
>>must be satisfied for a legitimate transfer to that label.  For each
>>goto there must be a proof that the preconditions for transferring to
>>the target label hold.

>This method is only sufficient for proving _partial_ correctness, that
>is `if the program halts, it will have produced the right result'
>For proving _total_ correctness, the program halts and gives the
>right result, you need more than that.
  [...]
>If you can prove that PUX will never drop below zero, then you know that
>the program will end. Needless to say, proving this is slightly unsimple
>in most cases.

  Your logic is flawed.  Yes, proving PUX > 0 is a sufficient condition,
but it is not a necessary condition.  (i.e. recursion where the derived
value approaches a limit is also ufficient condition). 

BTW:  Have you ever considered that all structured concepts are composed
      of three elements: a) straight line code, b) if then ... else ..., 
      and c) goto.  And even if then ... else ... breaks down to
      compare & goto.

-- 
On a clear disk you can seek forever.
-------------------------------------------------------------------------
Andrew Lawrence, Informaticien Conseil           |  alawrenc@sobeco.com
3605 St-Urbain, #1605                            |  uunet!sobeco!alawrenc
Newsgroups: alt.folklore.computers
From: jem@calypso.unc.edu (Jonathan Magid)
Subject: Computer filks
Keywords: songs computers filks
Reply-To: jem@calypso.unc.edu
Organization: Sun Microsystems
Date: Thu, 3 Sep 1992 06:07:39 GMT

hi,
a few months ago someone posted a fairly complete collection of
computer filks; I apparently didn't save a copy; could someone
give me a pointer to a copy or could the the collector repost
the article? 

thanks,
jem.


Jonathan Magid     jem@sunsite.unc.edu       SunSite Administrator
Virtual pizza Delivery (tm)::faxed in 30 cycles or less or you get it
----------------------------------------FREE!!!-----------------------

Newsgroups: alt.folklore.computers
From: hgz@cs5.informatik.uni-stuttgart.de (Hans-Georg Zipperer)
Subject: Re: Flash pix
Organization: Informatik, Uni Stuttgart, W. Germany
Date: Mon, 31 Aug 1992 13:12:27 GMT

In article <1992Aug28.082723.1@bronco.fnal.gov> colombo@bronco.fnal.gov (Rick Colombo - Fermilab) writes:
>In article <1992Aug27.114044.22877@echo.philips.nl>, dolf@echo.philips.nl (Dolf Grunbauer) writes:
>> Talking about taking flash photo's. I once heard a story of a demo of some
>> sort of new computer (no details given) which has some parts in EPROM (you
>> know, the PROMS you can clear by shining light on its top). They had hidden
>> this new computer behind a curtain. When the room was filled with all kind
>> of news people, including photographers, they removed the curtain. On this
>> very moment every photographer in the room started taking his 'exclusive'
>> picture. But as the technicians had forgotten to seal the EPROM's erasing
>> windows the flash light cleared the EPROMs or at least erased them enough
>> to be unable to continue with the demo.
>
>So this EPROM was sitting on top of the computer mugging for the camera?
>Sounds like real folklore to me, but at least it's in the appropriate place.
>I've seen EPROMs erased, they use UV light and set the timer for 15 minutes.

There are flash erasers available that will erase EPROMs in a few seconds *if
you bring the xenon tube in direct contact with the window*. But I doubt that
flashing from some distance will harm an EPROM. Also remember that older EPROMs
had many, many electrons sitting on the gate of the MOS transistor in the cell.
For example, the Intel 1702 must be programmed 32 times with 48 V for 2 ms per
word!

But I remember a similar story. I think it is in the book 'History of Computing
Technology' by Williams. The first IBM computer, the 701, used Williams tubes
as main memory. To make the computer look impressive, the frames had glass doors,
so you could see the wiring and the glowing tubes and the blinkenlights. The
story now proceeds as above. When the photographers were taking pictures, the
light fell on the phosphor coating of the Williams tubes. This lead to electron
emission that destroyed the charge patterns of the memory and the program crashed.

-- 
  Hans-Georg Zipperer     Universit"at Stuttgart, Institut f"ur Informatik
  Tel. (0711) 7816-405    e-mail: zipperer@ifi.informatik.uni-stuttgart.de
Newsgroups: alt.folklore.computers,comp.unix.misc