Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!dciem!nrcaer!cognos!roberts
From: roberts@cognos.uucp (Robert Stanley)
Newsgroups: comp.sys.mac
Subject: Re: Hypercard
Message-ID: <1387@cognos.UUCP>
Date: Thu, 3-Sep-87 13:06:50 EDT
Article-I.D.: cognos.1387
Posted: Thu Sep  3 13:06:50 1987
Date-Received: Sat, 5-Sep-87 14:33:49 EDT
References: <3766@sdcsvax.UCSD.EDU>
Reply-To: roberts@cognos.UUCP (Robert Stanley)
Organization: Cognos Inc., Ottawa, Canada
Lines: 57
Summary: Large stacks

In article <3766@sdcsvax.UCSD.EDU> graifer@net1.UUCP (Dan Graifer) writes:

>How will HyperCard react to a really large stack?  Most of the the examples
>distributed are fairly small (except for the help stack).

The quoted limits for a stack are 16 million cards or 500 megabytes.  Obviously
what you are doing will decide which limit you hit first.  Of course, I don't
have any 500 megabyte drives on my system, and havent found a way to split a
stack across multiple disks.  These limits are supposed to allow for the CD-ROM
world in the near future, when these numbers will start to be practical.

> (~60 meetings X ~10 people X ~15 beers = ~9000 records).  Is HyperCard going
> to choke completely if I try to put this up?

If you really want to prove the point, write a stack script that creates n
cards, where n is a suitable integer.  You can easily have the script fill in
a few fields with random words, which you can use to test retrieval.  9,000
sounds like an awfully small number to me - I have Excel databases with more
entries than that running on the Lisa.  The biggest stack (in terms of numbers
of cards) that I have created is about 28,000, but the links were very simple.
Worked fine for what I wanted, which was creating and testing a set of patterns
and their permutations.  The most complex card I have created is one with just
over 300 buttons, but these are split between card and background, and only 
some are active (on top) at any one time, controlled by scripts.

As far as calculation is concerned, you can lock the displayed card on screen
and have a script retrieve all sorts of other cards in the background, perform
calculations (or whatever) and return the answer to the displayed card.  In
other words, you don't see a display of all the intermediate steps (cards), and
this can significantly improve speed.  The most complex I have built to date
has to look at only four or five other cards, and it seems that timing is more
sensitive to what you do with the card than the time taken to retrieve it.  I
have not yet done any timing tests to discover if absolute linking (by card id)
is faster than symbolic linking (by card name) or if card ordering is of any
great importance.  Observation tends to suggest that links are being prefetched
in some way for the currently displayed card.

>Anybody seen a ~10K stack on plus?

I built a stack with a lot of imported bit-maps (paint images) which tops 5
megabytes, in a few hundred cards (I am not on my mac right now and don't have
the exact stats to hand).  This does quite complex retrieval via scripts in
well under 5 seconds per card fetch.  Using a standard Mac Plus with a 20 meg
HD-20 (non-SCSI).

Someone asked what we were doing with stacks.  Well, for fun I am creating a
periodic table that works, but for real I am modeling and prototyping some
interactive interfaces for one of my colleagues.  I am also investigating
the practicality of building a computer-based training tool in it - the issues
here are those of capturing and analyzing user input.  Anyone know the limit
on script sizes?  I don't have the magic book yet.

-- 
Robert Stanley           Cognos Incorporated     S-mail: P.O. Box 9707
Voice: (613) 738-1440 (Research: there are 2!)           3755 Riverside Drive 
  FAX: (613) 738-0002    Compuserve: 76174,3024          Ottawa, Ontario 
 uucp: decvax!utzoo!dciem!nrcaer!cognos!roberts          CANADA  K1G 3Z4