zben@umd5.UUCP (10/29/87)
I've built a stack of the songlists of all the shows the Grateful Dead
played between 1974 and 1986. It is just under 500K bytes and four main
areas, each with its own background. I've had problems trying to get the
FIND command to work. I haven't quite pinned the problem down exactly,
but it seems that a FIND directed at a field on one background can in some
cases be satisfied with the same data occuring in another field on another
background, as long as the field numbers matched. As a work around, I
create the same list of fields in each background, but with the unused fields
in each background set invisible. Anybody seen anything like this?
The conflict between TOPS and Hypercard on system 4.1 seems to be solved if
you copy the INIT31 resource from a 4.1 system tools disk and paste it over
the INIT31 in the system file. I have not yet tried replacing the system
(3.2?) on the TOPS install disk with a 4.1 system.
If you find you are covering a field with a button, to do something when the
user clicks at the field, it is probably easier to put the mouseup handler
into the field's script. This way you can toggle the "lockText" of the
field back and forth to update it, rather than having to move and replace
the button. The only disadvantage I've seen to this is the area doesn't
get lit-up when the option-cloverleaf keys are used to show the buttons.
I've built a button that reads and executes an arbitrary file of HyperTalk.
I build a 978K+ file on the Unix system that creates the entire stack from
scratch (and it uses only CAT and AWK!). It takes 261 seconds to FTP the
file to the Mac (using NCSA TelNet thru a Kinetics box) and several HOURS
to complete the build. Here is the script. Note there is a bug in the DO
command that causes it to complain about a line with a bare comment, so
the script filters them out.
on mouseUp
put "autoexec.bat" into fileName
open file fileName
repeat
read from file fileName until return
put it into buffer
if buffer is empty then -- end of file
close file fileName
exit mouseUp
end if
put buffer into message
put first word of buffer into indicate
if indicate is "--" then
-- comment (like this one) do nothing
else
do buffer
end if
end repeat
end mouseUp
Does anyone have a handle on a good way to search BACKWARDS, except the
obvious "go to prev card of this background, if/if/if" algorithm? Can
anybody think of a good way to search forward for a match in any one of
a number of fields, other that "go to next card of this background, if/if"?
--
Copyright 1987 Ben Cranston (you may redistribute ONLY if your recipients can).
umd5.UUCP <= {seismo!mimsy,ihnp4!rlgvax}!cvl!umd5!zben
zben @ umd2.UMD.EDU Kingdom of Merryland UniSys 1100/92
umd2.BITNET "via HASP with RSCS"kurtzman@pollux.usc.edu.UUCP (10/30/87)
In article <2014@umd5.umd.edu> zben@umd5.umd.edu (Ben Cranston) writes: >I've had problems trying to get the >FIND command to work. I haven't quite pinned the problem down exactly, >but it seems that a FIND directed at a field on one background can in some >cases be satisfied with the same data occuring in another field on another >background, as long as the field numbers matched. As a work around, I >create the same list of fields in each background, but with the unused fields >in each background set invisible. Anybody seen anything like this? The definition of the find command uses a field number. It is my guess that if you specify a field name, it just substitutes in the field number corresponding to the name. I have had the same problem and I solved it the same inelegant way. My suggestion to the hypertext developers is to add a background specifier to the find command. Example: find target in field n on background m
zben@umd5.UUCP (10/31/87)
In article <4911@oberon.USC.EDU> kurtzman@pollux.usc.edu (Stephen Kurtzman): >In article <2014@umd5.umd.edu> zben@umd5.umd.edu (Ben Cranston) writes: >> ... it seems that a FIND directed at a field on one background can in some >>cases be satisfied with the same data occuring in another field on another >>background, as long as the field numbers matched. ... >The definition of the find command uses a field number. It is my guess that >if you specify a field name, it just substitutes in the field number >corresponding to the name. I have had the same problem and I solved it the >same inelegant way. My suggestion to the hypertext developers is to add >a background specifier to the find command. Example: > find target in field n on background m Well, at first I thought this was indeed the case, but consider this: The stack in question has a single index card (with its own background), hundreds of "place" cards (contiguous, with a place background), similarly hundreds of "song" cards (continguous, with a sound background), and the rest of the thousand-odd cards are "show" cards (contiguous, show background). The only field on the index card is a "CurrentTime" which I plan to have an idle handler in the stack script move the short time into. When, on the Index card, I press a button that does the find command: find "blappo" in field "PlaceName" it finds a blappo in ANY field, "PlaceState", "PlaceCity", etc. When I go in and define 14 empty invisible fields on the index card's background, the button works correctly, and ONLY finds "blappo" in the PlaceName field. My tenative conclusion is that if one issues a "find ... in field fff" and there is no "fff" field on the current card or background then the find command is silently mutated into a "find ..." command and then searches all fields of all cards. At least that seems consistant with what I see... Also, now that I have a fully populated version to play with, I'm struck with the poor performance. A simple find "850911" in field "ShowDate" takes between 45 seconds and a minute to find the appropriate card. Naming the cards with their date and doing it like: go card "850911" STILL takes 45 seconds to a minute. I grabbed my trusty Knuth volume 3 and programmed a binary search in HyperTalk. It took 45 seconds to a minute FOR EACH CYCLE OF THE SEARCH! Looks like ANY attempt to access a card except "go card ID 123456" does a linear search from where you are in the stack. (I suspect the card ID is a physical address.) Since the go by ID is very fast, I put an invisible field on the first card that has the card ID of the first card of each year. Making the button go to the ID of the first card and search from there seems faster, but I might end up with a full index-sequential structure, with the index card pointing to all the "year header" cards, each of those pointing off to 12 "month header" cards. Lots of work for the setup, which already takes several hours... -- Copyright 1987 Ben Cranston (you may redistribute ONLY if your recipients can). umd5.UUCP <= {seismo!mimsy,ihnp4!rlgvax}!cvl!umd5!zben zben @ umd2.UMD.EDU Kingdom of Merryland UniSys 1100/92 umd2.BITNET "via HASP with RSCS"
kurtzman@pollux.usc.edu (Stephen Kurtzman) (11/02/87)
In article <2017@umd5.umd.edu> zben@umd5 (Ben Cranston) writes: >My tenative conclusion is that if one issues a "find ... in field fff" and >there is no "fff" field on the current card or background then the find >command is silently mutated into a "find ..." command and then searches all >fields of all cards. At least that seems consistant with what I see... It would also be consistent with the tendency of hypertext to "correct" errors behind your back. This tendency is a major loss in the design of hypertext as your example illustrates. I have found other instances where either poor performance or non-intuitive results occur due to a mistake on my part and hypertext's "forgiving" attitude. One of these almost caused me to abandon hypercard as unusable: I had a series of commands that refered to the unquoted names of fields rather than field numbers. Apparently, hypertext was parsing the field names as variable names, and when it found no variables (or perhaps empty variables) it would guess at what I wanted and successfully perform some operation that gave me the result I wanted. The problem was it took way to long. When I converted all the (unquoted) field names to field numbers I got a tenfold performance improvement. Don't ask me what hypertext was doing -- I don't know. > >Also, now that I have a fully populated version to play with, I'm struck >with the poor performance. A simple > > find "850911" in field "ShowDate" > >takes between 45 seconds and a minute to find the appropriate card. I have found the find command to be amazingly quick. 45 seconds sounds outrageous. Does anyone know why Ben is getting such horrid performance? As my stacks grow should I expect such rotten performance?