mcgrew@dartagnan.rutgers.edu (Charles Mcgrew) (09/15/89)
Submitted-by: apctrc!zmls04@uunet.uu.net (Martin L. Smith)
Posting-number: Volume 1, Issue 61
Archive-name: hype/part01
#! /bin/sh
# This is a shell archive, meaning:
# 1. Remove everything above the #! /bin/sh line.
# 2. Save the resulting text in a file.
# 3. Execute the file with /bin/sh (not csh) to create the files:
# Makefile
# Readme
# example.hyp
# This archive created: Thu Sep 14 20:44:16 1989
export PATH; PATH=/bin:$PATH
echo shar: extracting "'Makefile'" '(318 characters)'
if test -f 'Makefile'
then
echo shar: will not over-write existing file "'Makefile'"
else
sed 's/^ X//' << \SHAR_EOF > 'Makefile'
X
Xhype :
X cd archives/container; make
X cd archives/hash; make
X cd archives/info; make
X cd archives/mfile; make
X cd src; make
X
Xtest: hype
X hype -Sexample.hyp
X
Xlpr:
X cd Guide; make lpr
X cd Tutorial; make lpr
X cd ToDo; make lpr
X
Xclean:
X find archives src -name "*.[oa]" -print -exec rm {} \;
SHAR_EOF
if test 318 -ne "`wc -c < 'Makefile'`"
then
echo shar: error transmitting "'Makefile'" '(should have been 318 characters)'
fi
fi # end of overwriting check
echo shar: extracting "'Readme'" '(21953 characters)'
if test -f 'Readme'
then
echo shar: will not over-write existing file "'Readme'"
else
sed 's/^ X//' << \SHAR_EOF > 'Readme'
X August 21, 1989
X Tulsa, Oklahoma
X
X This is our submission to the world. Hope someone enjoys it.
X
XDISCLAIMER:
X Hype was written by Robert L. Read (read@cs.utexas.edu) in 1988
X under contract to the Amoco Production Company, Tulsa Research
X Center. Amoco has released Hype in its entirety to its author,
X Rob Read. Rob has elected to place the code into the public
X domain and I (Martin L. Smith, zmls04@trc.amoco.com) am doing
X the donkey work for Rob.
X
X Hype is free and absolutely unsupported. Neither Amoco nor
X Rob Read nor I nor anyone on this earth make any claims about
X its suitability or reliability and we accept absolutely no
X responsibility for any consequences which may result from its
X use.
X
X So far as we are concerned, you may do anything whatsoever that
X you wish with this program.
X
XRECLAIMER:
X
X Rob and I would like to hear from you if you use it, hate it,
X like it, extend it, or have some cogent remarks to make about
X it. (His e-mail gets through more regularly than mine does.)
X
XShameless Claims:
X
X Hype is a visual-interface configurable machine which supports
X a tree-structured hierarchy of visible windows. Windows
X may contain a collection of widgets (buttons, sliders, etc).
X The class of all hype entities (windows, widgets, etc) are `objects.'
X A hype configuration (called a state) is built interactively
X within hype. (It's a little like emacs in that it consists
X of an engine that has to be programmed to become an application;
X it's internal flexibility is much less than emacs'.)
X
X Hype currently sits on Sunview. It's mostly been run on
X Sun3's. Not sure if we actually tested it on a 4.
X
X Hype windows and widgets communicate by message-passing.
X A message consists of a name string (such as `mouseUp')
X and an optional parameter string which, like all hype strings,
X can be of arbitrary length. Messages are initiated by
X asynchronous system events such as mouse clicking,
X program start-up, death of a child, etc,
X or by
X synchronous hype events such as an object sending a
X message to another object.
X Messages may be directed to a specific object or broadcast to
X the entire tree. Directed messages which are not intercepted
X are hierarchically routed up the window tree until they are
X either intercepted by someone along the way or they pass off
X the root of the tree into oblivion.
X
X An object's behavior is defined by specifying which messages
X it will intercept and how it will handle those messages. We
X do this by giving each object a (possibly empty) set of methods.
X Each method is programmed in a C-like language and can include
X such actions as changing the visual appearance of objects,
X initiating new messages, executing other programs, messing with
X the file system, etc.
X
X Hype was built to provide an easy way to interactively create
X light-weight windowed user interfaces. We spent more time
X building it than actually using it but we think that it met
X our original expectations. It's fun to play with (there's
X a cold-start tutorial in the documentation) and it's a fairly
X neat prototyping system as well. Give it a shot.
X
XMaking Stuff:
X
X From this directory,
X
X make creates ./hype, the executable.
X
X make test creates ./hype, the executable, and
X executes it with the state file
X "example.hyp," approximately based on
X the tutorial (below)
X
X make lpr sends all the documentation to lpr.
X Some of the docs use postscript figures
X and the makefile assumes your printer can
X handle postscript.
X
X make clean erases a bunch of *.o and *.a files
X
X All of the `real' makefiles have CFLAGS = -g embedded in them.
X Don't think we've tried anything more macho than that. We
X considered cleaning up the program structure before submitting
X it to the net but decided instead to `share' all of our
X intellectualy and personal defects with you good people as
X well as our code itself. Think of it as a contribution
X to the rest-of-the-world's self-esteem.
X
XSource Directories:
X
X The subdirectories src and archive/* contain all the source.
X There is lots of relative-path linking among all these, all
X for include and library files, so either maintain this relative
X tree or grep around and fix the connections.
X
XDocumentation Directories:
X
X Guide:
X Programmers guide. Mostly -ms (troff, nroff) document.
X The guide has three figures, prepared with Frame. Postscript
X versions of those figures have been included. If you have
X a ps printer, just try
X make lpr
X and you should get all the pieces. Don't have an alternative
X way to do the figures; regrets to you ps-less people out there.
X
X ToDo:
X A list of things to fix/change/think about. If you're
X i[Bnterested in extending, or re-doing hype, look at this.
X
X Tutorial:
X A tutorial introduction to hype. Comments under `Guide'
X (above) apply here.
X
XMore Documentation
X
X We are preparing a paper, which we will probably submit to SPE,
X on the design of hype and our experiences with it. I haven't
X included it here because some journals (don't know about SPE)
X get irritated at rampant outside dissemination. If you extremely,
X really, honestly, no I am not shitting you, want a preprint
X then send surface mail (e-mail is too easy for compulsive
X archivists) to
X Martin L. Smith
X Amoco Research
X POB 3385
X Tulsa, OK 74102
X and we'll see what we can do. Include the phrase "I can still
X see portions of my desk top and I promise I will read your
X paper when I get it."
X
X
XHype state files
X
X example.hyp:
X is a hype state which started out as the
X examples worked out in the tutorial. We've added some
X stuff for various purposes, mostly testing.
X
XIf Make Breaks:
X
X Here is the output, after a modest bit of cosmetology, from
X running make on our system, a Sun 3/60:
X
X cd archives/container; make
X cc -g -sun3 -c container.c
X ar rcv container.a container.o
X a - container.o
X ranlib container.a
X cd archives/hash; make
X cc -g -sun3 -c hash.c
X cc -g -sun3 -c shash.c
X ar rcv hash.a hash.o shash.o
X a - hash.o
X a - shash.o
X ranlib hash.a
X cd archives/info; make
X cc -g -sun3 -c info_tl.c
X cc -g -sun3 -c info_obj.c
X cc -g -sun3 -c info_item.c
X cc -g -sun3 -c info_util.c
X ar rcv info.a *.o
X a - info_item.o
X a - info_obj.o
X a - info_tl.o
X a - info_util.o
X ranlib info.a
X cd archives/mfile; make
X cc -g -sun3 -c mfile.c
X ar rcv mfile.a mfile.o
X a - mfile.o
X ranlib mfile.a
X cd src; make
X cc -g -sun3 -c attr.c
X cc -g -sun3 -c amcomp.c
X cc -g -sun3 -c clipboard.c
X cc -g -sun3 -c color.c
X cc -g -sun3 -c confirm.c
X cc -g -sun3 -c deque.c
X cc -g -sun3 -c dialogue.c
X cc -g -sun3 -c emalloc.c
X cc -g -sun3 -c edit_cont.c
X cc -g -sun3 -c fileio.c
X cc -g -sun3 -c global.c
X cc -g -sun3 -c handler.c
X cc -g -sun3 -c hype.c
X cc -g -sun3 -c iam.c
X cc -g -sun3 -c info.c
X cc -g -sun3 -c init.c
X cc -g -sun3 -c interface.c
X cc -g -sun3 -c itemmod.c
X cc -g -sun3 -c map.c
X cc -g -sun3 -c objmod.c
X cc -g -sun3 -c pathname.c
X "pathname.c", line 64: warning:
X illegal combination of pointer and integer, op RETURN
X cc -g -sun3 -c screen.c
X cc -g -sun3 -c select.c
X cc -g -sun3 -c sighandler.c
X cc -g -sun3 -c symbol.c
X cc -g -sun3 -c textboard.c
X cc -g -sun3 -c tlmod.c
X cc -g -sun3 -c util.c
X cc -g -sun3 -c visual.c
X yacc scripter.y
X
X conflicts: 73 shift/reduce
X cc -g -sun3 -c -o scripter.o y.tab.c
X rm -f y.tab.c
X cc -g -sun3 -c lex.c
X cc -g -o ../hype scripter.o lex.o attr.o amcomp.o clipboard.o
X color.o confirm.o deque.o dialogue.o
X emalloc.o edit_cont.o fileio.o global.o
X handler.o hype.o iam.o info.o
X init.o interface.o itemmod.o map.o objmod.o
X pathname.o screen.o select.o sighandler.o
X symbol.o textboard.o tlmod.o util.o
X visual.o
X ../archives/info/info.a ../archives/mfile/mfile.a
X ../archives/container/container.a ../archives/hash/hash.a
X /usr/lib/debug/malloc.o -ll -lm
X -lsuntool -lsunwindow -lpixrect
X size ../hype
X text data bss dec hex
X 172032 24576 52952 249560 3ced8
X
X
XMiscellany:
X
X These are some notes that Rob made during the latter stages of
X development. Some of them refer to bugs that have been fixed
X or are otherwise out of date. I've included them just to keep
X the record complete.
X
X ----- NOTES ABOUT BUGS -----
X
X HYPE seems to be running rather smoothly. However it is a large system
X and is bound to contain bugs. In particuliar, SunView is known to be
X buggy in certain ways. The text following describes known and anticipated
X problems, ways to avoid them, and what to do if they occur.
X
X 1) Hype is dangerously sensitive to special characters, in particuliar
X the ^. I may be able to fix that before I leave.
X
X 2) I have had at least one unexplainable crash.
X
X 3) Sun claims that their advertised menu utility GEN_PROC is unreliable.
X I am still using that facility at present. This could produce problems
X that would be extremely difficult to debug or even explain.
X
X 4) In OS3.5 their is a repeatable case of hype invoking a UNIRAS routine
X and smashing the machine, i.e., the message
X PANIC!!! RESYNCHING DISKS.
X is displayed and the machine reboots. Further, this has on one
X occasion damaged files in the file system. This is clearly a major
X bug. I am attempting to verify if the same thing is true for
X OS4.0.
X
X 5) Because of admitted bugs in SunView, I am unable to deallocate
X menu space perfectly. There are undoubtably other memory leaks
X in the system, but at present they seem to be slow enough not
X to be a problem. It is possible however that one of the builtin
X functions has a leak, and thus a script calling it which was
X executed often would be a problem. Luckily, simply quitting HYPE
X and restarting reclaims all lost memory, although of course it
X will begin leaking again.
X
X 6) OS4.0 -- Hype appears to run as is under os4.0, but an exhaustive
X test is impossible. If something breaks on 4.0 that didn't break
X on 3.5, it may be a failue on my part to return a value from a
X function. Simply returning the correct value will fix the problem.
X (the OS3.5 compiler has a tendency to return the right value without
X an explicit return statement. Obviously I should have no functions
X without explicit returns, but I might anyway.)
X
X 7) DUPLICATE AND EMPTY NAMES -- Hype duplicate allows and empty names.
X This
X is convenient since the clipboard can be used easily to manipulate
X entities, but creates a non-deterministic situation as to which will
X be chosen. I know of no bugs with this but suspect if pushed a
X failure could be found.
X
X 8) BAD SCRIPTS -- I know of no case in which righting an erroneous
X script can cause HYPE to crater. However, this is a very difficult
X bug to for which to test. If this occurs, tell someone and right
X the script correctly. (or be wrong in a different way.)
X
X WHAT TO DO IF THERE IS A PROBLEM:
X AVOID THE BEHAVIOUR THAT PRODUCED THE PROBLEM.
X
X Lame advice, surely, but the best available. Hype is flexible
X enough that there will be many solutions to MOST problems. If
X one brings hype down, use another one.
X
X STATE FILES AND HOW THEY HELP
X Hype carries it's information in "state files". If hype crashes,
X all changes up to the last "saving" of the state file are lost.
X Thus, saving often makes you less susceptible to HYPE crashes
X (which seem very rare at the moment but may become a problem.)
X
X Furthermore, it's a good idea to keep backups of state files just
X as you keep backup of source code, thus protecting from:
X 1) Disk crashes
X 2) Accidental erasure
X 3) Hype corruption of its own state files.
X
X TO A CODE MAINTAINER
X Where do I begin? Hype is written at about C-- grade coding
X right now. The one thing it does have going for it is a high degree
X of modularity for a program that handles such a complicated data
X structure. I tend to use functional interfaces, which make things
X wordy and a bit slower, but do provide a level of abstraction.
X
X Hype is basically a maintainer of a huge attributed graph. That is,
X "object"s form a tree, each node of which has a lot of information.
X If the links in that system are corrupted, hype will crash eventually.
X
X The language implementation is straightforward (as those things go.)
X The huge file iam.c contains all of the builtin functions, and provides
X lots of examples an adding more. To add a new primitive function you
X DO NOT have to change the YACC or Lex specification. The function
X address and a suitable name must be added to the table defined in
X init.c, and the function should be added to iam.c. Of course,
X each function must obey several constraints, that are pretty clear
X from looking at the other functions in iam.c. It must:
X
X 1) Use the macro CHECK_NUM_ARGS (or whatever I called it.)
X This macro updates the PC, and so must be used even for functions
X of zero arguments.
X
X 2) A STRING (not a Container, or integer etc.) MUST be pushed
X on the stack as the return value.
X
X 3) The appropriate number of arguments MUST be popped.
X
X
X WORKING WITH SUNVIEW
X This is a major downer. Sunview is a nice package but it does have
X bugs. Further, it is just high enough level that you don't really
X know what's going on. In particuliar, you can't successfully
X manage the events as they occor.
X
X FILE DESCRIPTORS
X SunView uses file descriptors to implement windows. This means
X that the number of windows open at one time is limited. I have
X solved this problem by closing old windows behind the user. It
X is tempting to increase the number of windows I allow to be open,
X however when hype performs certain operations it may need three
X or four at once. I have it set now to the highest level that
X does not cause problems. In OS4 it may be better.
X
X ----- NOTES ABOUT THINGS THAT NEED ATTENTION -----
X
X
XThis file contains an incomplete list of the work I would accomplish to
Ximprove HYPE short of a major rewrite, which is what it really needs.
XHowever, this file may be informative to a maintainer or as a guide for
Xrewriting (although I hope to be involved in that process.)
X
X1) The number of argument checks could be print the function in question
Xif it failed, thus providing better error checking.
X
X2) The number of argument checks could be compile time checked, thus
Xproviding superior error checking.
X
X3) The syntax error linenumbers should be reported script-file relative
Xrather than relative to the particuliar message handler in question.
X
X4) Message handlers could be specified with regular expressions. (messages
Xthemselves can not be easily made into regular expressions.)
X
X5) The source code should compile without warnings.
X
X6) Standard functions should take a variable number of arguments.
X
X7) Most of the string handling functions defined in the UNIX manuals
Xshould be supported.
X
X8) Speed could be tremendously increased by a better string handler
X(container) package. In particuliar, a system that uses a union of
Xflat strings and containers, and keeps track of the current representation
Xcould greatly accelerate actions, especially script actions.
X
X9) An increased mathematical set of functions should be provided.
X
X10) Several general "find" functions should be provided. These would
Xsearch an entire hype structure:
X a) looking for handlers that caught a given message
X b) searching all data fields for a string.
X
X11) The type of items should be expanded to include invisible items,
Xchoice items, etc.
X
X12) An item expansion facility would be nice but fairly difficult, at
Xleast in Sunview.
X
X13) Bit-mapped image importation is a must.
X
X14) Cursor icon control (easy in X, hard in Sunview) would be nice.
X
X15) Underlying string operations need to be fast.
X
X16) The template bgtext facility is very stop-gap now.
X
X17) The refreshing takes far to long, and should be done on an item-by-item
Xbasis rather than by redrawing the whole object.
X
X18) OBVIOUSLY, WE NEED X NOW!!
X
X19) The functional interfaces to the object modules need to be better thought
Xout.
X
X20) The information module info.c could be easily obviated by a hash table
Xthat would decrease code volume and increase speed.
X
X21) Each enitity should maintain its own absolute pathname so that the
X expensive conversions in pathname.c could be really cut down.
X
X22) Each entity should have a set of static variables that are part of the
X state and thus stored on quit. These should be declared with some nice
X syntax somewhere in the message handling files.
X
X23) The state files should be more efficiently readable--that is, not
X require character by character input.
X
X24) It would be really, really cool if some sort of open pipe facility
X was allowed, and messages would be generated by hype when the pipe
X closed. This is very hard in SunView especially because of the
X file descriptor problem, but should be easy in X.
X
X25) It might be possilbe to build some sort of dynamic link or automatic
X new process incorporation.
X
X26) The next designer needs to sit down with SmallTalk and build and pick
X all the good stuff. Hype, for this audience, is NOT meant to be an
X object-oriented programming environment, but IS meant to take advantage
X of whatever it can to make user interface design easy.
X
X27) With X, it is not inconceivable that HYPE could start managing some
X graphics functions.
X
X28) Hype could provide somesort of debugging mode that printed all
X kinds of messages. Debugging object-oriented systems is hard.
X
X29) The hash table implementation does not now expand itself when it gets
X full. It makes sense to have it detect fullness and recompute itself.
X
X30) The awk approach to subscripted variables might will work out.
X
X31) Image importation should employ a standard canned SUN painting program,
X whichever one is useful.
X
X32) The benefits of X's control over the event stream are too numerous
X to name.
X
X33) It would be nice to have some standard internal quoting system so
X that spaces aren't such a downer.
X
X34) It is still true that a browser would be quite useful, and not really
X that hard.
X
X35) The Apple/NeWS concept of using a bit compression of the images as
X its own icon might work especially will since we have fixed item
X shapes (even in an X version.)
X
X36) Hype might very well offer access to some other interpreter, namely
X an SPL/mathlab like language, or a LISP interpreter or both.
X Since no copilation is required, Hype could pipe back and forth
X between the stated interpreter. This would allow a user to use
X hype in a HYPERCARD like fashion, as a graphics window onto another
X high-level language, or more importantly to use a fast computational
X engine like a COMMON LISP interpreter to do HYPE dirty work. This
X seems cooler than trying to make the HYPE LANGUAGE fast, since that
X should not really be part of it's design criteria.
X
X37) HYPE can definitely be modified to run as a stand alone program just
X as spl could be. (I mean here in pipes.) Perhaps the interactive
X design of hype makes this unnecessary though.
X
X38) If Hype had sort of an internal graphics tablet the user could draw
X on, we could do stuff like string processes together like SEISPROC,
X only better. Perhaps more realistic is to write a special program
X that HYPE knows how to communicate with to that, and then have
X HYPE extract the given information from it.
X
X39) Along those lines, it might be possible to write a package that
X lets a (presumably but not necessarily) child process actually send
X (using a function call that looks just like the HYPE "send" call)
X messages to a different HYPE process. Thus HYPE could be extended
X by any number of auxilliary programs that HYPE is "unaware" of but
X know how to talk to HYPE.
X
X40) Clearly one important aspect of HYPE/X is the networking concept.
X X makes it easy for HYPE to run on a Cray and be driven from a SUN.
X I suggest the following additional support functionality:
X 1) High level HYPE functions that manage network job spawning
X and maintenance. A HYPE programmer should be protected from
X the exact syntax of a remote shell command, or an ftp , etc.
X (Of course, unix and unixbg still work, and can spawn remote
X shells.
X
X 2) Possibly support for a networking monitoring "PSEUDO-OBJECT"
X like the current (real) object "history" in the public file
X with greatly increased functionality.
X
X50) A hype window clear switch, to iconify all hype windows.
X
X51) BUILD AN EDITOR INTO HYPE!!!! Maybe emacs could be mock-lisp
X programmed to do the job. Who knows what evil lurks in the
X hearts of men?
X
X52) A special hypnotic hype pattern that will make users my absolute
X slave forever.
X
X53) The kitchen sink.
X
X54) The browser migh be anotated with known message creation and reception
X arcs.
X
X55) If truly large hype machines were ever built, we could have an object
X load on-demand function that would keep the internal memory structure
X reaonable.
X
X56) We really would like to have a generaly object-ownership and privilege
X mechanism, so that JOE BLOW can create an object that JOE-SIXPACK can
X use but not modify, even though JOE-SIXPACK can build his own objects.
X
X57) Conceivably some kind of mega-funky delta versioning system might
X be kept on state files.
X
X58) TOTAL INSULATION OF THE USER FROM THE FACT THAT HE IS USING HYPE.
X Thus HYPE could be a real programming tool.
X
X59) The concept of PSEUDO-OBJECTS is an appealing aproach to graphics
X that does not require the full inheritance and class-definablility
X of Smalltalk.
X
X60) On-line HYPE help.
X
X61) So it goes, on and on, through the setting sun, we go
X round and round and round and round until we
X pick it up again
X time flies
X on and on it goes
X
X------ END -----
SHAR_EOF
if test 21953 -ne "`wc -c < 'Readme'`"
then
echo shar: error transmitting "'Readme'" '(should have been 21953 characters)'
fi
fi # end of overwriting check
echo shar: extracting "'example.hyp'" '(2969 characters)'
if test -f 'example.hyp'
then
echo shar: will not over-write existing file "'example.hyp'"
else
sed 's/^ X//' << \SHAR_EOF > 'example.hyp'
X!!!
Xglobals=0
XTutorial
X^
XMy Tutorial Root^
X^
X^
X1
XButtons
X^
X^
X^
X^
X3
XThermometer
XThermometer
X1
X0
X^
XmouseUp:
X{
X open("Thermometer");
X}.
X
X^
X^
X^
X^
X^
X^
X^
X^
X^
X^
X^
X^
X^
X^
X^
X30 10 0 0 1 0
X^
X^
XExit
XExit
X1
X0
X^
XmouseUp:
X{
X exit();
X}.
X
X^
X^
X^
X^
X^
X^
X^
X^
X^
X^
X^
X^
X^
X^
X^
X30 90 0 0 0 0
X^
X^
XSandBox
XSand Box
X1
X0
X^
XmouseUp:
X{
X open("SandBox");
X close(".");
X}.
X
X^
X^
X^
X^
X^
X^
X^
X^
X^
X^
X^
X^
X^
X^
X^
X30 50 0 0 65536 0
X^
X^
X185 356 187 138 0 1
X^
X^
X1
X!Buttons
X0 0 187 126 0 0
X^
X^
X2
XThermometer
X^
XThermometer^
X^
XdegreesC:
X{
X newtemp = param();
X for(i = 0; i < numpanes(self()); i++) {
X pane = self() $$ "!" $$ i;
X for(j = 0; j < numitems(pane); j++) {
X item = getnthitem(pane, j);
X send("changeTo", item, newtemp);
X }
X }
X}.
XinitHype:
X{
X if(param() == "thermometer")
X open(self());
X}.
X
X^
X1
XMercury
X^
X^
X^
X^
X3
XC
XC
X1
X0
X^
XmouseUp:
X{
X close(".");
X}.
X^
X^
X^
X^
X^
X^
X^
X^
X^
X^
X^
X^
X^
X^
X^
X10 5 0 0 0 0
X^
X^
XDegF
XDeg F
X2
X0
X^
XmouseUp:
X{
X value = getitemval(self());
X centigrade = 5.0 * ( value - 32 ) / 9.0;
X send("degreesC", self(), centigrade);
X}.
XchangeTo:
X{
X farenheit = (9 * param() / 5) + 32;
X if(farenheit != getitemval(self()))
X setitemval(self(), farenheit);
X}.
X^
X^
X55^
X^
X32^
X^
X212^
X^
X^
X^
X^
X^
X^
X^
X180^
X10 50 0 0 0 0
X^
X^
XDegC
XDeg C
X2
X0
X^
XmouseUp:
X{
X value = getitemval(self());
X send("degreesC", ".", value);
X}.
XchangeTo:
X{
X celsius = param();
X if(celsius != getitemval(self()))
X setitemval(self(), celsius);
X}.
X^
X^
X^
X^
X0^
X^
X100^
X^
X^
X^
X^
X^
X^
X^
X180^
X10 30 0 0 255 0
X^
X^
X742 432 389 93 0 1
X^
X^
X1
X!Mercury
X0 0 389 93 0 0
X^
X^
X0
X748 272 399 116 32767 0
X^
X214 153 81^
X^
X63^
X/Tutorial/Thermometer!Mercury#DegC
X^
X145^
X/Tutorial/Thermometer!Mercury#DegF
X+
XSandBox
X^
XSand Box^
X^
X^
X1
XToys
X^
X^
X^
X^
X3
XRecursionTest
XRecursionTest
X1
X0
X^
XmouseUp:
X{
X open("RecursionTest");
X}.
X^
X^
X^
X^
X^
X^
X^
X^
X^
X^
X^
X^
X^
X^
X^
X20 10 0 0 1 0
X^
X^
XC
XC
X1
X0
X^
XmouseUp:
X{
X open("..");
X close(".");
X}.
X
X^
X^
X^
X^
X^
X^
X^
X^
X^
X^
X^
X^
X^
X^
X^
X280 10 0 0 0 0
X^
X^
XX
XX
X1
X0
X^
XmouseUp:
X{
X exit();
X}.
X
X^
X^
X^
X^
X^
X^
X^
X^
X^
X^
X^
X^
X^
X^
X^
X280 40 0 0 0 0
X^
X^
X744 305 408 109 0 1
X^
X^
X1
X!Toys
X0 0 399 109 0 0
X^
X^
X1
XRecursionTest
X^
XRecursionTest^
X^
X^
X1
XToys
X^
X^
X^
XExecuting this test will break hype:
X^
X3
XRecursionCount
XRecursion Count
X0
X0
X^
X
X^
X^
X1^
X^
X^
X^
X^
X^
X^
X^
X^
X^
X^
X^
X10^
X70 60 0 0 0 0
X^
X^
XGo
XGo
X1
X0
X^
XmouseUp:
X{
X count = param();
X if(count == "null" ) { # must be the real mouseUp
X count = getitemval("!Toys#RecursionCount");
X stderr("Recursion to depth " $$ count $$ " starting." );
X } else {
X --count;
X# stderr(" count = " $$ count );
X# if(count <= 0)
X# return "";
X }
X stderr(" count = " $$ count );
X if(count > 1)
X send("mouseUp", self(), count);
X if(count == "null")
X stderr("Done.");
X}.
X^
X^
X^
X^
X^
X^
X^
X^
X^
X^
X^
X^
X^
X^
X^
X10 60 0 0 0 0
X^
X^
XC
XC
X1
X0
X^
XmouseUp:
X{
X open("..");
X close(".");
X}.
X
X^
X^
X^
X^
X^
X^
X^
X^
X^
X^
X^
X^
X^
X^
X^
X370 60 0 0 -1 0
X^
X^
X0 431 408 109 0 1
X^
X^
X1
X!Toys
X0 0 399 109 0 0
X^
X^
X0
X153 223 409 132 0 0
X^
X99 126 132^
X^
X15^
X/Tutorial/SandBox/RecursionTest!Toys#RecursionCount
X+
X741 0 409 132 24 0
X^
X99 126 132^
X+
X753 0 197 149 0 0
X^
X132 92 83^
X+
SHAR_EOF
if test 2969 -ne "`wc -c < 'example.hyp'`"
then
echo shar: error transmitting "'example.hyp'" '(should have been 2969 characters)'
fi
fi # end of overwriting check
# End of shell archive
exit 0