HDTenEightyP/NetNews huggingface dataset:
From: barmar@think.com (Barry Margolin)
Newsgroups: alt.folklore.computers
Subject: Re: Origin of locked-in subwindows
Date: 27 Aug 1992 18:31:35 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: telecaster.think.com
Keywords: windows

In article <5831@vexpert.dbai.tuwien.ac.at> mst@vexpert.dbai.tuwien.ac.at (Markus Stumptner) writes:
>Does anyone know where the idea of windows that are locked into the
>frame of another window originated?

The Lisp Machine window system has had frames, which are windows that are
subdivided into other windows (called panes), for over a dozen years.

-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
Newsgroups: alt.folklore.computers,comp.unix.misc
From: peter@ferranti.com (peter da silva)
Subject: Re: The need for an assembler (was: Favorite CPU)
Reply-To: peter@ferranti.com (Peter da Silva)
Organization: Xenix Support, FICC
Date: Tue, 1 Sep 1992 16:10:20 GMT

In article <1992Aug31.162630.23913@news.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
> A very popular and recent piece of software is DR-DOS Version 6, which 
> is written in mostly assembler and runs on all of these, picking up options
> along the way in a seamless manner where applicable.

An operating system of that level (basicaly file system and monitor) is
inherently non-portable, so who cares?

> 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.
-- 
Peter da Silva                                               `-_-'
$ EDIT/TECO LOVE                                              'U` 
%TECO-W-OLDJOKE Not war?                        Have you hugged your wolf today?
Ferranti Intl. Ctls. Corp.      Sugar Land, TX  77487-5012       +1 713 274 5180
Newsgroups: alt.folklore.computers,comp.os.ms-windows.apps,comp.os.ms-windows.misc
From: huot@cray.com (Tom Huot)
Subject: PROGRAM BLOAT - was Re: Ye Olde Secrete Screene Cheete Sheete  .....
Organization: Cray Research, Inc.
Date: 4 Sep 92 12:48:55 CDT

In article <jcmorris.715622277@mwunix> jcmorris@mwunix.mitre.org (Joe Morris) writes:
[Entire text about Easter Eggs & Cheats Deleted]

This is just my $.02. It certainly is no wonder that this commercial
software is so bloated and expensive, when totally worthless crap
such as faces, fireworks, undocumented cheats are actually placed
in these programs. Just think of it this way. Someone is actually
getting PAID to do this!

AREN'T THE DAMN PROGRAMS GETTING BIG ENOUGH ALREADY???

-- 
_____________________________________________________________________________
Tom Huot        			       
huot@cray.com 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Newsgroups: alt.folklore.computers,comp.unix.misc
From: peter@ferranti.com (peter da silva)
Subject: Re: The need for an assembler (was: Favorite CPU)
Organization: Xenix Support, FICC
Date: Thu, 27 Aug 1992 16:32:22 GMT

In article <1992Aug26.065533.14600@news.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
> No, I don't think I'm a "super-programmer" rather that in the group of people
> I started in this industry over two decades ago with, I was probably in the
> lower one/third.

OK, so you're a mediocre super-programmer.

> I think all that has happened, is that like academia, the
> standards have dropped,

Yes, I would agree. Programming has become *easier*. Personally, I think
this is a good thing.

I do think people should have more variety in their experience, but real
pedal-to-the-metal assembly is only part of this. Lisp is just as important,
and it's several levels higher than C.

> Again, depends on the task; there are whole avenues of real-time technique
> that you can't even express in C.  Anyone who hasn't seen real-time interrupt
> handling and foreground code written as co-routines has severely shortchanged
> their education.

There are high level languages that support coroutines quite well. Even C is
not too bad in that respect: after all, the traditional UNIX kernel is
implemented that way.

> >> I have friends who are of the opinion that C is more like a demented
> >> macro assembler being misused with the "wrong" macroes, but I won't let
> >> my personal friends bias the count here.

> >Well, it's pretty close to assembly... but I find the macros it uses just
> >fine.

> Spoken like a hll-bigot.

Gee, most HLL-bigots don't consider C worth using... it's too low level. I
guess I'm a MLL-bigot.

> How can C be closely related to assembler when
> it is by definition an abstraction of only some of the more "generic" features
> of certain machines, ignoring pieces of all of these and other machines which
> are only accessible via assembler?

I see, so assembly on a machine that doesn't provide those functions isn't
assembly? All the stuff I've written for the 1802 doesn't count.

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

No, what assembler demands.
-- 
Peter da Silva                                               `-_-'
$ EDIT/TECO LOVE                                              'U` 
%TECO-W-OLDJOKE Not war?                        Have you hugged your wolf today?
Ferranti Intl. Ctls. Corp.      Sugar Land, TX  77487-5012       +1 713 274 5180
Newsgroups: alt.folklore.computers,comp.unix.misc
From: jimf@centerline.com (Jim Frost)
Subject: Re: The need for an assembler (was: Favorite CPU)
Organization: CenterLine Software, Inc.
Date: Fri, 28 Aug 1992 18:30:06 GMT

Charlie_Gibbs@mindlink.bc.ca (Charlie Gibbs) writes:
>In article <jimf.714924310@centerline.com> jimf@centerline.com
>(Jim Frost) writes:

>>lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
>>
>>>A silly remark that doesn't answer the question.  This is a major ugly
>>>feature of the language: all internal procedures have to come first, and
>>>when they reference each other, a kludge is needed to pull it off.
>>
>>That's what happens when you have type-safe languages.  You'll find
>>that predeclaration is also necessary in most other type-safe
>>languages.  It's true, it's to help out the compiler.  So what?

>     This is part of the HLL zealots' argument that I've always had
>trouble with.  Supposedly the purpose of a high-level language is
>to allow you to write your code in a straightforward way that
>readily illustrates the structure of your application.  If we're
>supposed to be free from picky internal details, why then do we
>have to write things in an unnatural order just to satisfy the
>compiler?

Actually it does help readability too, if you're reading top-down,
because you don't run into anything of a type you don't know.  Not a
big deal in the recursive-structure case but a real big deal once
things start to get complicated.

>(You
>can always tell C code that was written by a Pascalite or Moduloid -
>it's upside-down.)

Not necessarily true.  I sometimes write C programs with callee first
on the page so I don't have to declare the function in advance of its
use (the definition is the declaration this way).

You can write your Pascal program this way too, but because of the
annoying fact that you have to omit the parameter list and return type
information it becomes harder to read.

>If these compilers are so damn smart, they
>should be able to figure it out for themselves.

They can, but do you want to wait for it to do so?  I figure if it
doesn't particularly hurt readability (and I think it improves it) and
it's not too hard, I can give the compiler a little help.

jim frost
jimf@centerline.com
Xref: sparky alt.folklore.computers:12945 alt.religion.computers:520
From: jfc@athena.mit.edu (John F Carr)
Newsgroups: alt.folklore.computers,alt.religion.computers
Subject: Re: Good source code to read?
Date: 24 Aug 92 01:22:16 GMT
Organization: Massachusetts Institute of Technology

In article <1992Aug23.234300.3595@monu6.cc.monash.edu.au>
parry@yoyo.cc.monash.edu.au (Tom J Parry) writes:

>Now consider what happens if you call funny(funny) ...
>... Funny calls the halt() function to ask
>if it will halt on it's own input (i.e. will funny(funny) halt?), if
>halt() says it does halt, then it loops forever, if halt says it loops
>forever, it halts.

This reminds me of the proof of Godel's theorem: given an infinitely
powerful logical system, one can prove a contradiction.  The concepts
do seem to map well.

--
    John Carr (jfc@athena.mit.edu)
Newsgroups: alt.folklore.computers,comp.unix.misc
From: ae@sei.cmu.edu (Arthur Evans)
Subject: Re: SAGE
Organization: Software Engineering Institute
Date: Wed, 2 Sep 1992 13:15:34 GMT

mchance@nyx.cs.du.edu (Michael Chance) says:
>> I saw the SAGE display at the Computer Museum when I was in Boston in
>> 1984.  The story that I got from the folks at the museum then was
>> that it's a fully functional SAGE installation, except for one thing
>> - the power generators.  Apparently, Boston wouldn't rate the dock
>> the museum is built on as capable of supporting the weight of the
>> generators, which are 100+ tons!

There's another problem: air conditioning.  SAGE was a vacuum tube
computer and generated _HUGE_ amounts of heat.  When I visited a SAGE
installation in about 1963, I was told that there was a backup A/C (as
well as two SAGE computers, one for backup), and that after an A/C
failure they had some very small number of minutes (five?  ten?) to get
the backup A/C working or the computer and people in the building would
start to cook.  In the tube days of computers, you could count on an A/C
installation about the same size as the computer, or larger.

I suspect that's a big part of the problem in getting a SAGE computer
running now.  Also, of course, is the cost of electricity to run the
computer and A/C.

Art Evans
Newsgroups: alt.folklore.computers,alt.religion.computers
From: yamada@stego.ifa.hawaii.edu (Hubert Yamada)
Subject: Re: Good source code to read?
Organization: University of Hawaii, Institute for Astronomy
Date: Thu, 27 Aug 1992 23:38:38 GMT

In article <8503.Aug2522.12.5992@virtualnews.nyu.edu> brnstnd@nyu.edu (D. J. Bernstein) writes:
>I pointed out that the halting problem is decidable in practice. You can
>write a compiler which takes a program and certain specified variables
>and produces a halting executable. The executable uses twice as much
>memory for those variables, and runs at one-third speed, but if the
>variables loop then the executable will stop sometime during the first
>loop.
>
>Hubert Yamada alludes to two programs, one of which counts in
>multi-precision up to 2^100 and repeats, the other of which counts up to
>2^100 and halts. Naturally, the halting executable will have to run a
>very long time before detecting this loop. But *in practice* you
>wouldn't trace that counter.

This is not what I said.  In my original posting, I talked about a
program with 100 bits of state information.  I specifically did _not_
refer to a simple 100 bit counter, because intelligent flow analysis
can handle that fairly easily.  I said nothing about how that state
infomation was being used, nor did I say anything about what algorithm
was being used for loop detection.  The 100 bits could be used, for
example, to disprove fermat's last theorem by trial and error, to
handle a 2^100-state finite state machine (possible, for example, with
some form of self-modifying code), or to generate random numbers using
some linear congruential method.  The only requirement is that the
program have the potential to enter a significant number of the
possible states.  The point that I was making is that the fact that any
program (written on computer with finite memory) must eventually loop
or terminate does not lead to the conclusion that all programs can be
analyzed in a resonable amount of time.
-- 
Hubert Yamada                   * Our hero is called before the alien
yamada@galileo.ifa.hawaii.edu   * potentate!  Where it becomes clear that
yamada@uhunix.uhcc.hawaii.edu   * Spiff is about to be sacrificed to appease
Bitnet: yamada@uhunix.bitnet    * the evil god they call "Nollij"!
From: pw@panix.com (Paul Wallich)
Newsgroups: alt.folklore.computers
Subject: Re: CyC project
Date: 25 Aug 92 21:28:52 GMT
Organization: Trivializers R Us

In <1992Aug25.102605.13501@dxcern.cern.ch> xexeo@dxcern.cern.ch (Geraldo Xexeo) writes:

>A recent issue of Scientific American cited the CyC being done
>at MCC, Austin. The CyC (say 'psych') is a database with currently
>2 Mrules, and its creators say when it arrives 10Mrules it should
>be intelligent. If I am not hacking for too long time, D.Lenat is
>the creator.

Lenat also desperately hopes that after about 5 Mrules Cyc will have
enough vestiges of common sense to be able to learn new stuff from
reading books and articles rather than having each rule painstakingly
encoded. This will put a small but very interesting cadre of bright
strange twits out of a job.

>In another direction, Thinking Machines wants to use CM-5 to 
>process the CyC database, eventually to create an AI.

TMC doesn't care one way or another, except insofar as they can
sell boxes, but it does look like CYC running on a CM will be at
least 10,000 times as fast as it is now, i.e. seconds instead of
days. This could be useful in evaluating whether the sucker is
in fact intelligent.

paul
Newsgroups: alt.folklore.computers
From: smith@sctc.com (Rick Smith)
Subject: Re: SAGE
Organization: SCTC
Date: Tue, 25 Aug 1992 20:32:17 GMT

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

>Some of the blinken-lights from SAGE appeared in the submarine in Voyage
>to the Bottom of the Sea.

I'd never heard this before. How did this happen? I didn't think SAGE
was decommissioned long enough ago to be used in that show. Or did
they really use a mockup to look like a Real Computer?

Rick.
smith@sctc.com        arden hills, minnesota
Newsgroups: alt.folklore.computers
From: frank@rover.uchicago.edu (Frank - Hardware Hacker - Borger)
Subject: Re: Movie "Stay Tuned" and PDP-11 spotted?
News-Software: VAX/VMS VNEWS 1.41    
Reply-To: frank@rover.uchicago.edu
Organization: Joint Center for Radiation Therapy
Date: Sat, 29 Aug 1992 17:09:00 GMT

In article <9208290414.AA20495@cue.bc.ca>, tdzubin@cue.bc.ca (Thomas Dzubin) writes...
>Did anyone notice the PDP-11 in the current movie "Stay Tuned"?
> 
>It is in the scene where Roy (John Ritter) is a crash-test dummy in a
>car about to hit a wall.  The data-gathering computer used by the Devil's
>helper, Spike seems to be a PDP-11.  ...
>What does this mean?  All of the dead PDP11's have gone to hell????!?!?
>I would have thought they'd be all using VMS or MSDOS down there.

	No, even the Devil isn't THAT mean!!!

   Frank R. Borger - Physicist    __       Internet:  Frank@rover.uchicago.edu
Michael Reese - Univ. of Chicago |___      Phone : 312-791-8075 fax : 567-7455
  Center for Radiation Therapy   | |_) _   It's the responsibility of the media
    2929 South Ellis Avenue        | \|_)  to look at the president with a mic-
    Chicago, Illinois 60616           |_)  roscope, but they go to far when they
					   use a proctoscope. - Richard M. Nixon
From: widenius@klaava.Helsinki.FI (Risto Widenius)
Newsgroups: alt.folklore.computers
Subject: Re: Flash illiteracy; was: Re: Deutsches Museum (was: Zuse Computers
Date: 28 Aug 92 18:21:20 GMT
Organization: University of Helsinki

mcovingt@athena.cs.uga.edu (Michael A. Covington) writes:

>I have been asked whether one needs flash to photograph a solar eclipse.

I win. I saw this happen during a total eclipse a few years ago. A
nearby hill, crowded by thousands of people, was magically illuminated
by flashes during the dark minutes. I took some long-exposure shots (no
flash) of the hill rather than the eclipse, but haven't seen these, they
are filed somewhere at my sister's.

rw
-- 
-rw-hki-fi GeekSig(tm)
Newsgroups: alt.folklore.computers
From: lasner@watsun.cc.columbia.edu (Charles Lasner)
Subject: Re: The need for an assembler (was: Favorite CPU)
Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner)
Organization: Columbia University
Date: Tue, 1 Sep 1992 23:27:06 GMT

In article <8387@sirius.ucs.adelaide.edu.au> newton@iagu.itd.adelaide.edu.au (Mark Newton) writes:
>In article <1992Aug31.055948.14380@news.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
>>There are demented assemblers out there.  We have been fighting them for
>>years.  Not all of them are so demented, and besides these effects are
>>known, and quite localized.  A competent programmer caring about this
>>problem works around it.
>
>There are demented compilers out there.  We have been fighting them for
>years.  Not all of them are so demented, and besides these effects are
>known, and quite localized.  A competent programmer caring about this
>problem works around it.

I totally agree, but the original poster was trying to make something out of
that.  Writing in *any* language means that sometimes you have to "fight"
with it.  Just that some people seem to think that whatever they have
stumbled across in their experience is so wonderful that they lose sight
of this.

My purpose is not to extoll assembly language as a language per se, which
seems to be mixed up here with other notions.  I find deficiencies in all
assemblers by comparing the best features of incompatible systems.  Hll
comparisons will yield similar results.  The purpose of writing in
assembler is to provide a *reasonable* way to express machine code while
removing as much tedium in it as possible.  Sometimes you have to fight
to get what you want when the language "differs" from your requirements.

But, the main purpose is to express the code I want to run, not an abstraction
that can make the expression inefficient or even obfuscated.  The code
created by a hll may be the square peg-round hole kind of solution, regardless
of the ease of expressing it.

As was posted earlier, sometimes assembler programmers will resort to a
few hll-type "tricks" of their own such as defining and using macros that
superfically resemble hll.  This allows *selective* abstraction where
appropriate without giving up anything.  In fact, you can implement
pseudo-code as macros that generate the efficient code if you're clever.
(You can write pseudo-code in hll preprocessors as well, but the code
generation part isn't as flexible.)

cjl
From: bevan@cs.man.ac.uk (Stephen J Bevan)
Newsgroups: alt.folklore.computers
Subject: Re: Indentation
Date: 27 Aug 92 18:48:34 GMT
	<X1B604K@math.fu-berlin.de> <1606@anagld.analytics.com>
	<Q8E6H9J@math.fu-berlin.de>
Organization: Department of Computer Science, University of Manchester
In-reply-to: weberwu@inf.fu-berlin.de's message of 26 Aug 92 13:36:59 GMT

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.


   As another argument for proper block markers, it's so comforting to
   use emacs to edit LISP or C or such which jumps back with the
   cursor to the block begin when you type the block end. That not only
   trains the eye, but helps avoid lots of block problems.

So has somebody hacked it so it works for languages that don't use
single characters for block markers e.g. Ada, Pascal, Algol 60 ...
etc?  I was sure I saw some code for this a long time ago, possibly
for Pop, but I can't remember where.

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.  Does anybody think there is
something wrong with the way indentation is done in Haskell?

bevan
From: miner@kuhub.cc.ukans.edu
Newsgroups: alt.folklore.computers
Subject: Why is kermit called kermit?
Date: 3 Sep 92 21:44:38 CDT
Organization: University of Kansas Academic Computing Services

I don't know where else to ask this: why is kermit called kermit?

	- Ken Miner 


Newsgroups: alt.folklore.computers
From: aldavi01@starbase.spd.louisville.edu (Arlie Davis)
Subject: Re: You know you've been using X too long...
Date: Sun, 30 Aug 1992 17:54:39 GMT
Organization: University of Louisville

In <1992Aug30.132018.14433@geovision.gvc.com> pt@geovision.gvc.com (Paul Tomblin) writes:

> aldavi01@starbase.spd.louisville.edu (Arlie Davis) writes:

> >taste in colors anymore!", and prompty decided to make the rivers a deep red,
> >and the skies shades of grey, by thinking "*River*background: #FF0000" and
> >"*Sky*background: #808080".
> Not much of an improvement, if you ask me.

Not much of an improvement?  Well, you should have seen the dream.
The background colors for the Sky and River widgets were used to set up
a linear scale of colors.  The red rivers were great, and the sky went from
gun-metal gray to an oily black, and the sun reminded me of the output of
"pgmramp -ellipse".

> >I think I've been hacking X too long...

> I think you've found what I've always found: I'm unable to come up with a
> better colour selection than the developer's defaults.

Quite the opposite, in this case!  I wish I lived in that world.
But you are right -- often, the developer's defaults are usually fairly
evolved, and decent fallbacks.  It's not always the case though...

> For instance, when I
> had a DecStation on my desk, I used the Mwm file that came with it, with
> only minor tweaking.  When I tried to get radical in changing the colours, I
> ended up with something that I hated even more than the defaults.  Now I've
> got a SPARC, I'm not even going to _try_ and change the open-windows
> defaults.

Only a few packages I've used have come with tolerable default resources.
HP's X editor, ved, is one of them, and their LAserrom is decent.  But mwm
and vuewm both make me cry.
-- 
lrwx------   1 aldavi01 emacsstu       9 Jun  6 12:43 .signature -> /dev/null
Newsgroups: alt.folklore.computers
From: fjh@mundil.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: The need for an assembler (was: Favorite CPU)
Organization: Computer Science, University of Melbourne, Australia
Date: Wed, 26 Aug 1992 16:06:29 GMT

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

>>ABusing a stack?
>
>Fortran need not allocate in the first place.  The program can be statically
>loaded.  Only one DMA cycle per word to get it loaded. 
>
>Statement stands.  Faster than what?  I can imagine some horrible methods
>they could have used that using the stack is better than. :-).

Using a stack reduces memory usage (thus avoiding thrashing in some
cases), improves locality and hence reduces cache misses.
Using a stack also supports recursion (necessary for Fortran 90).

-- 
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