Download from Wayback Machine
These binary files are shown in the log but excluded from this commit: * gps10bin.zip * gps10src.zip * mfc40dll.zip $ wayback_machine_downloader --all-timestamps www.cs.bgu.ac.il/~elad/GALAPAGOS Downloading www.cs.bgu.ac.il/~elad/GALAPAGOS to websites/www.cs.bgu.ac.il/~elad/GALAPAGOS/ from Wayback Machine archives. Getting snapshot pages.. found 52 snaphots to consider. file_list_curated: 52 52 files to download: http://www.cs.bgu.ac.il:80/~elad/GALAPAGOS/ -> websites/www.cs.bgu.ac.il/~elad/GALAPAGOS/19970726164741/~elad/GALAPAGOS/index.html (1/52) http://www.cs.bgu.ac.il:80/%7Eelad/GALAPAGOS/ -> websites/www.cs.bgu.ac.il/~elad/GALAPAGOS/19981205205433/~elad/GALAPAGOS/index.html (2/52) http://www.cs.bgu.ac.il:80/~elad/GALAPAGOS/ -> websites/www.cs.bgu.ac.il/~elad/GALAPAGOS/20010430130433/~elad/GALAPAGOS/index.html (3/52) https://www.cs.bgu.ac.il/~elad/GALAPAGOS/ -> websites/www.cs.bgu.ac.il/~elad/GALAPAGOS/20220312053305/~elad/GALAPAGOS/index.html (4/52) https://www.cs.bgu.ac.il/~elad/GALAPAGOS/ -> websites/www.cs.bgu.ac.il/~elad/GALAPAGOS/20220312053307/~elad/GALAPAGOS/index.html (5/52) http://www.cs.bgu.ac.il:80/~elad/GALAPAGOS/back.gif -> websites/www.cs.bgu.ac.il/~elad/GALAPAGOS/19970812032339/~elad/GALAPAGOS/back.gif (6/52) http://www.cs.bgu.ac.il:80/~elad/GALAPAGOS/background.html -> websites/www.cs.bgu.ac.il/~elad/GALAPAGOS/19970806122533/~elad/GALAPAGOS/background.html (7/52) http://www.cs.bgu.ac.il:80/%7Eelad/GALAPAGOS/background.html -> websites/www.cs.bgu.ac.il/~elad/GALAPAGOS/19991006050747/~elad/GALAPAGOS/background.html (8/52) http://www.cs.bgu.ac.il:80/~elad/GALAPAGOS/background.html -> websites/www.cs.bgu.ac.il/~elad/GALAPAGOS/20010608213604/~elad/GALAPAGOS/background.html (9/52) http://www.cs.bgu.ac.il:80/~elad/GALAPAGOS/bgu_logo_tiny.gif -> websites/www.cs.bgu.ac.il/~elad/GALAPAGOS/19970806122524/~elad/GALAPAGOS/bgu_logo_tiny.gif (10/52) http://www.cs.bgu.ac.il:80/~elad/GALAPAGOS/bib.html -> websites/www.cs.bgu.ac.il/~elad/GALAPAGOS/19970806122740/~elad/GALAPAGOS/bib.html (11/52) http://www.cs.bgu.ac.il:80/%7Eelad/GALAPAGOS/bib.html -> websites/www.cs.bgu.ac.il/~elad/GALAPAGOS/19991006061546/~elad/GALAPAGOS/bib.html (12/52) http://www.cs.bgu.ac.il:80/~elad/GALAPAGOS/bib.html -> websites/www.cs.bgu.ac.il/~elad/GALAPAGOS/20010608214537/~elad/GALAPAGOS/bib.html (13/52) http://www.cs.bgu.ac.il:80/~elad/GALAPAGOS/Envs.gif -> websites/www.cs.bgu.ac.il/~elad/GALAPAGOS/19970812032348/~elad/GALAPAGOS/Envs.gif (14/52) http://www.cs.bgu.ac.il:80/~elad/GALAPAGOS/Envs2.gif -> websites/www.cs.bgu.ac.il/~elad/GALAPAGOS/19970812032356/~elad/GALAPAGOS/Envs2.gif (15/52) http://www.cs.bgu.ac.il:80/~elad/GALAPAGOS/extensions.html -> websites/www.cs.bgu.ac.il/~elad/GALAPAGOS/19970806122623/~elad/GALAPAGOS/extensions.html (16/52) http://www.cs.bgu.ac.il:80/%7Eelad/GALAPAGOS/extensions.html -> websites/www.cs.bgu.ac.il/~elad/GALAPAGOS/19990424140956/~elad/GALAPAGOS/extensions.html (17/52) http://www.cs.bgu.ac.il:80/~elad/GALAPAGOS/extensions.html -> websites/www.cs.bgu.ac.il/~elad/GALAPAGOS/20010608215359/~elad/GALAPAGOS/extensions.html (18/52) http://www.cs.bgu.ac.il:80/~elad/GALAPAGOS/gps.gif -> websites/www.cs.bgu.ac.il/~elad/GALAPAGOS/19970806122512/~elad/GALAPAGOS/gps.gif (19/52) http://www.cs.bgu.ac.il:80/~elad/GALAPAGOS/gps10bin.zip -> websites/www.cs.bgu.ac.il/~elad/GALAPAGOS/19970806123128/~elad/GALAPAGOS/gps10bin.zip (20/52) http://www.cs.bgu.ac.il:80/~elad/GALAPAGOS/gps10src.zip -> websites/www.cs.bgu.ac.il/~elad/GALAPAGOS/19970806123709/~elad/GALAPAGOS/gps10src.zip (21/52) http://www.cs.bgu.ac.il:80/~elad/GALAPAGOS/gui.html -> websites/www.cs.bgu.ac.il/~elad/GALAPAGOS/19970806122632/~elad/GALAPAGOS/gui.html (22/52) http://www.cs.bgu.ac.il:80/%7Eelad/GALAPAGOS/gui.html -> websites/www.cs.bgu.ac.il/~elad/GALAPAGOS/19990128140433/~elad/GALAPAGOS/gui.html (23/52) http://www.cs.bgu.ac.il:80/~elad/GALAPAGOS/gui.html -> websites/www.cs.bgu.ac.il/~elad/GALAPAGOS/20010608220120/~elad/GALAPAGOS/gui.html (24/52) http://www.cs.bgu.ac.il:80/~elad/GALAPAGOS/img00001.gif -> websites/www.cs.bgu.ac.il/~elad/GALAPAGOS/19970812032406/~elad/GALAPAGOS/img00001.gif (25/52) http://www.cs.bgu.ac.il:80/~elad/GALAPAGOS/img00002.gif -> websites/www.cs.bgu.ac.il/~elad/GALAPAGOS/19970812032416/~elad/GALAPAGOS/img00002.gif (26/52) http://www.cs.bgu.ac.il:80/~elad/GALAPAGOS/img00002.gif -> websites/www.cs.bgu.ac.il/~elad/GALAPAGOS/20000427155438/~elad/GALAPAGOS/img00002.gif (27/52) http://www.cs.bgu.ac.il:80/~elad/GALAPAGOS/img00002.gif -> websites/www.cs.bgu.ac.il/~elad/GALAPAGOS/20000927202854/~elad/GALAPAGOS/img00002.gif (28/52) http://www.cs.bgu.ac.il:80/~elad/GALAPAGOS/img00003.gif -> websites/www.cs.bgu.ac.il/~elad/GALAPAGOS/19970812032426/~elad/GALAPAGOS/img00003.gif (29/52) http://www.cs.bgu.ac.il:80/~elad/GALAPAGOS/img00010.gif -> websites/www.cs.bgu.ac.il/~elad/GALAPAGOS/19970812032447/~elad/GALAPAGOS/img00010.gif (30/52) http://www.cs.bgu.ac.il:80/~elad/GALAPAGOS/img00011.gif -> websites/www.cs.bgu.ac.il/~elad/GALAPAGOS/19970812032457/~elad/GALAPAGOS/img00011.gif (31/52) http://www.cs.bgu.ac.il:80/~elad/GALAPAGOS/img00012.gif -> websites/www.cs.bgu.ac.il/~elad/GALAPAGOS/19970812032510/~elad/GALAPAGOS/img00012.gif (32/52) http://www.cs.bgu.ac.il:80/~elad/GALAPAGOS/img00013.gif -> websites/www.cs.bgu.ac.il/~elad/GALAPAGOS/19970812032521/~elad/GALAPAGOS/img00013.gif (33/52) http://www.cs.bgu.ac.il:80/~elad/GALAPAGOS/implementation.html -> websites/www.cs.bgu.ac.il/~elad/GALAPAGOS/19970806122650/~elad/GALAPAGOS/implementation.html (34/52) http://www.cs.bgu.ac.il:80/%7Eelad/GALAPAGOS/implementation.html -> websites/www.cs.bgu.ac.il/~elad/GALAPAGOS/19990128153816/~elad/GALAPAGOS/implementation.html (35/52) http://www.cs.bgu.ac.il:80/~elad/GALAPAGOS/implementation.html -> websites/www.cs.bgu.ac.il/~elad/GALAPAGOS/20010608220848/~elad/GALAPAGOS/implementation.html (36/52) http://www.cs.bgu.ac.il:80/~elad/GALAPAGOS/index.html -> websites/www.cs.bgu.ac.il/~elad/GALAPAGOS/19970812032301/~elad/GALAPAGOS/index.html (37/52) http://www.cs.bgu.ac.il:80/%7Eelad/GALAPAGOS/index.html -> websites/www.cs.bgu.ac.il/~elad/GALAPAGOS/19990417073305/~elad/GALAPAGOS/index.html (38/52) http://www.cs.bgu.ac.il:80/~elad/GALAPAGOS/index.html -> websites/www.cs.bgu.ac.il/~elad/GALAPAGOS/20010921035619/~elad/GALAPAGOS/index.html (39/52) http://www.cs.bgu.ac.il:80/~elad/GALAPAGOS/manual.html -> websites/www.cs.bgu.ac.il/~elad/GALAPAGOS/19970806122731/~elad/GALAPAGOS/manual.html (40/52) http://www.cs.bgu.ac.il:80/%7Eelad/GALAPAGOS/manual.html -> websites/www.cs.bgu.ac.il/~elad/GALAPAGOS/19990129014748/~elad/GALAPAGOS/manual.html (41/52) http://www.cs.bgu.ac.il:80/~elad/GALAPAGOS/manual.html -> websites/www.cs.bgu.ac.il/~elad/GALAPAGOS/20010608221151/~elad/GALAPAGOS/manual.html (42/52) http://www.cs.bgu.ac.il:80/~elad/GALAPAGOS/mfc40dll.zip -> websites/www.cs.bgu.ac.il/~elad/GALAPAGOS/20010614210623/~elad/GALAPAGOS/mfc40dll.zip (43/52) http://www.cs.bgu.ac.il:80/~elad/GALAPAGOS/next.gif -> websites/www.cs.bgu.ac.il/~elad/GALAPAGOS/19970812032317/~elad/GALAPAGOS/next.gif (44/52) http://www.cs.bgu.ac.il:80/~elad/GALAPAGOS/next.gif -> websites/www.cs.bgu.ac.il/~elad/GALAPAGOS/20000429040644/~elad/GALAPAGOS/next.gif (45/52) http://www.cs.bgu.ac.il:80/~elad/GALAPAGOS/next.gif -> websites/www.cs.bgu.ac.il/~elad/GALAPAGOS/20000927044316/~elad/GALAPAGOS/next.gif (46/52) http://www.cs.bgu.ac.il:80/~elad/GALAPAGOS/prev.gif -> websites/www.cs.bgu.ac.il/~elad/GALAPAGOS/19970812032310/~elad/GALAPAGOS/prev.gif (47/52) http://www.cs.bgu.ac.il:80/~elad/GALAPAGOS/stone.jpg -> websites/www.cs.bgu.ac.il/~elad/GALAPAGOS/19970806122448/~elad/GALAPAGOS/stone.jpg (48/52) http://www.cs.bgu.ac.il:80/~elad/GALAPAGOS/toc.gif -> websites/www.cs.bgu.ac.il/~elad/GALAPAGOS/19970812032330/~elad/GALAPAGOS/toc.gif (49/52) http://www.cs.bgu.ac.il:80/~elad/GALAPAGOS/toc.gif -> websites/www.cs.bgu.ac.il/~elad/GALAPAGOS/20000427162611/~elad/GALAPAGOS/toc.gif (50/52) http://www.cs.bgu.ac.il:80/~elad/GALAPAGOS/toc.gif -> websites/www.cs.bgu.ac.il/~elad/GALAPAGOS/20000927020528/~elad/GALAPAGOS/toc.gif (51/52) http://www.cs.bgu.ac.il:80/~elad/GALAPAGOS/vision.gif -> websites/www.cs.bgu.ac.il/~elad/GALAPAGOS/19970812032438/~elad/GALAPAGOS/vision.gif (52/52) Download completed in 87.05s, saved in websites/www.cs.bgu.ac.il/~elad/GALAPAGOS/ (52 files)
This commit is contained in:
commit
e1790c55bd
|
|
@ -0,0 +1,95 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
||||
<HTML>
|
||||
<HEAD>
|
||||
<TITLE>Galapagos</TITLE>
|
||||
</HEAD>
|
||||
<BODY background=stone.jpg>
|
||||
|
||||
<CENTER><P><B><FONT COLOR="#008040" SIZE=+4>Welcome to<BR>
|
||||
<IMG border=0 SRC=gps.gif alt="GALAPAGOS"></FONT></B></P></CENTER>
|
||||
|
||||
Galapagos is an interactive multithreaded Scheme interpreter with turtle
|
||||
graphics for Windows 95. It is built around the SCM interpreter, and it
|
||||
provides multiple interpreters, threads, turtles, and drawing boards, all
|
||||
running concurrently using WIN32's multithreading abilities, and freely
|
||||
<A href="#download">available</A>.
|
||||
|
||||
<P>
|
||||
<HR>
|
||||
<P>
|
||||
<Center>
|
||||
<A href="http://www.cs.bgu.ac.il"><IMG border=0 src="bgu_logo_tiny.gif" alt=""></A><BR><BR>
|
||||
Spring 1997<BR><BR>
|
||||
Graduation project<BR><BR>
|
||||
<A href="http://www.cs.bgu.ac.il">Department of Math & Computer Science,</A><BR><BR>
|
||||
<A href="http://www.bgu.ac.il">Ben-Gurion University of the Negev</A><BR><BR>
|
||||
<BR>
|
||||
Written by <A href="http://www.cs.bgu.ac.il/~elad">Elad Eyal</A> and <A href="http://www.cs.bgu.ac.il/~tebeka">Miki
|
||||
Tebeka</A>.<BR>
|
||||
<BR>
|
||||
Supervisor: <A href="http://www.cs.bgu.ac.il/~elhadad">Dr. Michael Elhadad</A>
|
||||
</CENTER>
|
||||
<P>
|
||||
<P>
|
||||
<HR width=100%>
|
||||
<P>
|
||||
<A name="toc">
|
||||
<CENTER><P><B><FONT SIZE=+3>TABLE OF CONTENTS </FONT></B></P></CENTER>
|
||||
|
||||
<UL>
|
||||
<LI><A HREF="background.html">Background </A></LI>
|
||||
<UL>
|
||||
<LI><A HREF="background.html#SCHEME">SCHEME</A></LI>
|
||||
<LI><A HREF="background.html#LOGO AND TURTLE">LOGO and Turtle Geometry</A></LI>
|
||||
<LI><A HREF="background.html#OBJECTIVES">Objectives</A></LI>
|
||||
<LI><A HREF="background.html#AVAILABILITY">Avaliability</A></LI>
|
||||
</UL>
|
||||
<LI><A HREF="extensions.html">SCHEME extensions</A></LI>
|
||||
<UL>
|
||||
<LI><A HREF="extensions.html#THE NEW ENVIRONMENT">The New Environment Model</A></LI>
|
||||
<LI><A HREF="extensions.html#THREADS">Threads</A></LI>
|
||||
<LI><A HREF="extensions.html#CONSOLES">Consoles</A></LI>
|
||||
<LI><A HREF="extensions.html#DRAWING">Drawing Boards</A></LI>
|
||||
<LI><A HREF="extensions.html#TURTLES">Turtles</A></LI>
|
||||
<LI><A HREF="extensions.html#INTERRUPTS (NOTIFICATIONS) AND MESSAGE">Interrupts (Notifications) and Message handlers</A></LI>
|
||||
</UL>
|
||||
<LI><A HREF="gui.html">The interactive GUI</A></LI>
|
||||
<LI><A HREF="implementation.html">Implementation</A></LI>
|
||||
<UL>
|
||||
<LI><A HREF="implementation.html#FITTING SCM INTO">Fitting SCM into Windows</A></LI>
|
||||
<LI><A HREF="implementation.html#GARBAGE">Garbage Collection</A></LI>
|
||||
<LI><A HREF="implementation.html#BOARDS">Boards</A></LI>
|
||||
<LI><A HREF="implementation.html#TURTLES">Turtles</A></LI>
|
||||
<LI><A HREF="implementation.html#VISION">Vision</A></LI>
|
||||
<LI><A HREF="implementation.html#INTERRUPTS">Interrupts</A></LI>
|
||||
<LI><A HREF="implementation.html#CLASS">Class Organization</A></LI>
|
||||
</UL>
|
||||
<LI><A HREF="manual.html">Programer's Manual</A></LI>
|
||||
<UL>
|
||||
<LI><A HREF="manual.html#ENVIRONMENTS">Environments</A></LI>
|
||||
<LI><A HREF="manual.html#MESSAGE">Message Queues</A></LI>
|
||||
<LI><A HREF="manual.html#WINDOW">Window Commands</A></LI>
|
||||
<LI><A HREF="manual.html#TURTLE">Turtle Commands</A></LI>
|
||||
<LI><A HREF="manual.html#VISION">Vision</A></LI>
|
||||
<LI><A HREF="manual.html#INTERRUPTS">Interrupts (Notifications)</A></LI>
|
||||
<LI><A HREF="manual.html#THREADS">Threads</A></LI>
|
||||
</UL>
|
||||
<LI><A HREF="bib.html">Bibiliography and Links</A></LI>
|
||||
</UL>
|
||||
|
||||
<P>
|
||||
|
||||
<BR>
|
||||
<A name="download">
|
||||
<CENTER><P><B><FONT SIZE=+3>DOWNLOAD CENTER</FONT></B></P></CENTER>
|
||||
<P>
|
||||
<CENTER><FONT size=-1><TT>GNU LICENSE. COPYRIGHTED. PROVIDED "AS IS". NO
|
||||
WARRANTIES OR LIABILITIES. ETC.</TT></CENTER>
|
||||
<P>
|
||||
<P>
|
||||
500K <A href="gps10bin.zip"><TT>gps10bin.zip</TT></A> - Executable and required Scheme libraries (SLIB)<BR>
|
||||
700K <A href="gps10src.zip"><TT>gps10src.zip</TT></A> - Same with all source code <BR>
|
||||
400K <A href="mfc40dll.zip"><TT>mfc40dll.zip</TT></A> - You might need this MFC40.DLL if you
|
||||
don't have it already. <BR>
|
||||
</BODY>
|
||||
</HTML>
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 5.5 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 40 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 137 B |
|
|
@ -0,0 +1,130 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
||||
<HTML>
|
||||
<HEAD>
|
||||
<TITLE>Galapagos - Background</TITLE>
|
||||
<META NAME="Author" CONTENT="">
|
||||
<META NAME="GENERATOR" CONTENT="Mozilla/3.01Gold (Win95; I) [Netscape]">
|
||||
</HEAD>
|
||||
<BODY background=stone.jpg>
|
||||
|
||||
<P>
|
||||
<CENTER>
|
||||
<A href="index.html"><IMG border=0 src=prev.gif ALT=" [PREV] "></A>
|
||||
<A href="extensions.html"><IMG border=0 src=next.gif ALT=" [PREV] "></A>
|
||||
<A href="index.html#toc"><IMG border=0 src=toc.gif ALT=" [PREV] "></A>
|
||||
</CENTER>
|
||||
<HR width=80% align=right color=blue>
|
||||
<P>
|
||||
<H2 ALIGN=CENTER><A NAME="top"></A><FONT SIZE=+4>Background</FONT></H2>
|
||||
|
||||
<UL>
|
||||
<LI><A HREF="background.html#SCHEME">SCHEME</A></LI>
|
||||
<LI><A HREF="background.html#LOGO AND TURTLE">LOGO and Turtle Geometry</A></LI>
|
||||
<LI><A HREF="background.html#OBJECTIVES">Objectives</A></LI>
|
||||
<LI><A HREF="background.html#AVAILABILITY">Avaliability</A></LI>
|
||||
</UL>
|
||||
|
||||
<H2>
|
||||
<HR WIDTH="100%"></H2>
|
||||
|
||||
<H2><A NAME="SCHEME"></A>SCHEME</H2>
|
||||
|
||||
<P>Scheme is a dialect of Lisp that stresses conceptual elegance and simplicity.
|
||||
It is specified in R4RS and IEEE standard P1178. Scheme is much smaller
|
||||
than Common Lisp; the specification is about 50 pages, compared to Common
|
||||
Lisp's 1300 page draft standard. (See the Lisp FAQ for details on standards
|
||||
for Common Lisp.) Advocates of Scheme often find it amusing that the entire
|
||||
Scheme standard is shorter than the index to Guy Steele's "Common
|
||||
Lisp: the Language, 2nd Edition".<BR>
|
||||
</P>
|
||||
|
||||
<P>Scheme is often used in computer science curricula and programming language
|
||||
research, due to its ability to represent many programming abstractions
|
||||
with its simple primitives.<BR>
|
||||
</P>
|
||||
|
||||
<P>There are a lot of traditional SCHEME interpreter available such as
|
||||
Chez, ELK 2.1, GAMBIT, MITScheme, scheme->C, Scheme48, T3.1, VSCM and
|
||||
Scm4e. Many free Scheme implementations (as well as SCM) are available
|
||||
from swiss-ftp.ai.mit.edu [18.43.0.246].<BR>
|
||||
</P>
|
||||
|
||||
<P>Galapagos is built over the SCM interpreter version 4e4 written by Aubrey
|
||||
Jaffer <jaffer@ai.mit.edu>.<BR>
|
||||
<BR>
|
||||
<BR>
|
||||
</P>
|
||||
|
||||
<H2><A NAME="LOGO AND TURTLE"></A>LOGO AND TURTLE GEOMETRY<BR>
|
||||
</H2>
|
||||
|
||||
<P>LOGO is a programming language designed for use by learners, including
|
||||
children. It is a dialect of LISP which has a more natural syntax, using
|
||||
infix arithmetics and (almost) no parentheses. LOGO features a "turtle"
|
||||
which can be instructed to move across the screen and draw shapes. This
|
||||
became known as "Turtle Graphics" or "Turtle Geometry"
|
||||
- a geometry that describes paths "from within" rather than "from
|
||||
outside" or "from above." For example, "turn right"
|
||||
means turn right relative to whatever direction you were heading before;
|
||||
by contrast, "turn east" specifies an apparently absolute direction.
|
||||
A Logo user or program manipulates the graphical turtle by telling it to
|
||||
move forward or back some number of steps, or by telling it to turn left
|
||||
or right some number of degrees.<BR>
|
||||
</P>
|
||||
|
||||
<P>Turtle geometry has two major advantages. One is that many paths are
|
||||
more simply described in relative than in absolute terms. For example,
|
||||
it's easy to indicate the absolute coordinates of the corners of a square
|
||||
with vertical and horizontal sides, but it's not so easy to find the corners
|
||||
of an inclined square. In turtle geometry the same commands (go <B>forward</B>,
|
||||
turn right 90 <B>degrees</B>, etc.) work for squares with any orientation.
|
||||
The second advantage is pedagogic rather than computational: turtle geometry
|
||||
is compatible with a learner's own experience of moving in the world -
|
||||
it's "body syntonic."<BR>
|
||||
</P>
|
||||
|
||||
<P><A NAME="OBJECTIVES"></A><B><FONT SIZE=+2>OBJECTIVES</FONT></B><BR>
|
||||
</P>
|
||||
|
||||
<P>The two major goals behind Galapagos were:<BR>
|
||||
</P>
|
||||
|
||||
<P>First, we wanted to create an environment suitable for teaching programming,
|
||||
patterned after Logo's environment and its easy-to-understand, easy-to-use
|
||||
turtle geometry. We chose Scheme as the programming language because of
|
||||
its educational value, as noted before. We added Turtle Graphics because
|
||||
of its ability to visualize computations, and thus help understanding them
|
||||
better.<BR>
|
||||
</P>
|
||||
|
||||
<P>Second, we wanted to add parallel programming. The importance of multiprocessor
|
||||
machines and of multithreading is becoming more apparent every day, and
|
||||
so is the need for tools to help understanding parallel programming paradigms.
|
||||
By extending Scheme to be multithreaded, we wanted to create such a tool.<BR>
|
||||
</P>
|
||||
|
||||
<P><A NAME="AVAILABILITY"></A><B><FONT SIZE=+2>AVAILABILITY</FONT></B><BR>
|
||||
</P>
|
||||
|
||||
<P>Galapagos was developed to run under Windows 95, and should work under
|
||||
Window NT as well. (It uses 32-bit specific code so Win32s is not enough
|
||||
to run Galapagos). Both binary and source are <A href="index.html#download">available</A> at the
|
||||
homepage:<BR>
|
||||
</P>
|
||||
|
||||
<CENTER><P><TT>
|
||||
<A HREF="http://www.cs.bgu.ac.il/~elad/GALAPAGOS">http://www.cs.bgu.ac.il/~elad/GALAPAGOS</A>
|
||||
</TT>
|
||||
</P></CENTER>
|
||||
|
||||
|
||||
<P>
|
||||
<HR width=80% align=left color=blue>
|
||||
<CENTER>
|
||||
<A href="#top"><IMG border=0 src=back.gif ALT=" [TOP] "></A>
|
||||
<A href="index.html"><IMG border=0 src=prev.gif ALT=" [PREV] "></A>
|
||||
<A href="extensions.html"><IMG border=0 src=next.gif ALT=" [PREV] "></A>
|
||||
<A href="index.html#toc"><IMG border=0 src=toc.gif ALT=" [PREV] "></A>
|
||||
</CENTER>
|
||||
</BODY>
|
||||
</HTML>
|
||||
|
|
@ -0,0 +1,493 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
||||
<HTML>
|
||||
<HEAD>
|
||||
<TITLE>Galapagos - Scheme Extensions</TITLE>
|
||||
<META NAME="Author" CONTENT="">
|
||||
<META NAME="GENERATOR" CONTENT="Mozilla/3.01Gold (Win95; I) [Netscape]">
|
||||
</HEAD>
|
||||
<BODY background=stone.jpg>
|
||||
|
||||
<CENTER>
|
||||
<A href="background.html"><IMG border=0 src=prev.gif ALT=" [PREV] "></A>
|
||||
<A href="gui.html"><IMG border=0 src=next.gif ALT=" [PREV] "></A>
|
||||
<A href="index.html#toc"><IMG border=0 src=toc.gif ALT=" [PREV] "></A>
|
||||
</CENTER>
|
||||
<HR width=80% align=right color=blue>
|
||||
<P>
|
||||
|
||||
<H1 ALIGN=CENTER><A NAME="top"></A>SCHEME EXTENSIONS<BR>
|
||||
</H1>
|
||||
|
||||
<UL>
|
||||
<LI><A HREF="extensions.html#THE NEW ENVIRONMENT">The New Environment Model</A></LI>
|
||||
<LI><A HREF="extensions.html#THREADS">Threads</A></LI>
|
||||
<LI><A HREF="extensions.html#CONSOLES">Consoles</A></LI>
|
||||
<LI><A HREF="extensions.html#DRAWING">Drawing Boards</A></LI>
|
||||
<LI><A HREF="extensions.html#TURTLES">Turtles</A></LI>
|
||||
<LI><A HREF="extensions.html#INTERRUPTS (NOTIFICATIONS) AND MESSAGE">Interrupts
|
||||
(Notifications) and Message handlers</A></LI>
|
||||
</UL>
|
||||
|
||||
<P>
|
||||
<HR WIDTH="100%"></P>
|
||||
|
||||
<P>We have extended Scheme in two main
|
||||
directions: Turtle graphics and multithreading:<BR>
|
||||
</P>
|
||||
|
||||
<P>The <I>turtle</I> object lives on a board on which it can move and draw.
|
||||
A turtle can also communicate with the board and "see" colors
|
||||
or other turtles. Galapagos Scheme provides a set of primitives to create
|
||||
and manage such turtles and the boards they live on. <BR>
|
||||
</P>
|
||||
|
||||
<P>A set of additional primitives enable the programmer to create multiple
|
||||
interpreters that run concurrently. The environment model was extended
|
||||
to support shared or thread-specific environments, and primitives to handle
|
||||
multiple environments were also added. <BR>
|
||||
<BR>
|
||||
</P>
|
||||
|
||||
<H2><A NAME="THE NEW ENVIRONMENT"></A>THE NEW ENVIRONMENT MODEL<BR>
|
||||
</H2>
|
||||
|
||||
<P>A frame is a table which maps (or <I>binds</I>) names to values. An
|
||||
environment is a chained list of frames in which the interpreter works.
|
||||
</P>
|
||||
|
||||
<P>For example the command: </P>
|
||||
|
||||
<P><I>(define x 7)</I> </P>
|
||||
|
||||
<P>creates a binding between <I>x</I> and the value <I>7</I>. </P>
|
||||
|
||||
<P>A typical environment looks like this:</P>
|
||||
|
||||
<P><CENTER>
|
||||
<IMG border=0 SRC="Envs.gif" HEIGHT=125 WIDTH=459><BR>
|
||||
</CENTER></P>
|
||||
<BR>
|
||||
<BR>
|
||||
<BR>
|
||||
Each rectangle denotes a frame and inside it are the bindings it holds.
|
||||
The rightmost rectangle is the global environment.<BR>
|
||||
</P>
|
||||
|
||||
<P>When a variable is evaluated, the interpreter first tries to find it
|
||||
in the current frame. If a suitable binding can't be found, the interpreter
|
||||
moves to the next frame in the environment and searched for a binding there.<BR>
|
||||
</P>
|
||||
|
||||
<P>In our example if we write <I>x</I> in the command line we'll get <I>12</I>
|
||||
as the answer because all such computations take place at the global environment.
|
||||
<BR>
|
||||
</P>
|
||||
|
||||
<P>A function application is always evaluated with respect to the environment
|
||||
the in which it was defined. (A function "holds" its environment,
|
||||
hence the name "closure") This means that if we write </P>
|
||||
|
||||
<P><I>(define (f) x) </I></P>
|
||||
|
||||
<P>and then </P>
|
||||
|
||||
<P><I>(f)</I> </P>
|
||||
|
||||
<P>the result will be </P>
|
||||
|
||||
<P><I>12</I>.<BR>
|
||||
<BR>
|
||||
<BR>
|
||||
<BR>
|
||||
<BR>
|
||||
<P><CENTER>
|
||||
<IMG border=0 SRC="Envs2.gif" HEIGHT=140 WIDTH=551><BR>
|
||||
</CENTER></P>
|
||||
<BR>
|
||||
In traditional SCHEME we have only one interpreter running at a time, so
|
||||
at a given point of calculation there is only one environment. In Galapagos
|
||||
multiple interpreters can run at the same time, and each of them has its
|
||||
own environment.<BR>
|
||||
</P>
|
||||
|
||||
<P>Under Galapagos's environment model, every interpreter works on its
|
||||
branch of an "environments tree", but can also evaluate an expression
|
||||
in any other environment in the tree. If two interpreters have a shared
|
||||
node on the tree, then from that point up (towards the global environment)
|
||||
all the bindings are the same for the two interpreters. The global environment
|
||||
is shared by all interpreters. If an interpreter changes the value of some
|
||||
variable, the binding is changed in all other interpreters that have access
|
||||
to the frame where the variable was declared. Obviously, caution should
|
||||
be taken when writing to a shared variable.<BR>
|
||||
</P>
|
||||
|
||||
<P>As an example, if a user created two new threads, called A and B, and
|
||||
then evaluated: </P>
|
||||
|
||||
<P><TT><FONT FACE="Courier New">First thread></FONT></TT> <I>(define
|
||||
x 7)</I> </P>
|
||||
|
||||
<P><I>(define (f) ...)</I> </P>
|
||||
|
||||
<P><TT><FONT FACE="Courier New">Thread A></FONT></TT> <I>(define (g)
|
||||
x)</I> </P>
|
||||
|
||||
<P><TT><FONT FACE="Courier New">Thread B></FONT></TT> <I>(define x 4)</I>
|
||||
</P>
|
||||
|
||||
<P>this is how the environment model would look like:<BR>
|
||||
</P>
|
||||
|
||||
<CENTER><P><IMG border=0 SRC="img00001.gif" HEIGHT=407 WIDTH=654><BR>
|
||||
</P></CENTER>
|
||||
|
||||
<P>Now consider what happens when the user evaluates this: </P>
|
||||
|
||||
<P><TT><FONT FACE="Courier New">Thread A></FONT></TT> <I>(set! f g)</I>
|
||||
</P>
|
||||
|
||||
<CENTER><P><IMG border=0 SRC="img00002.gif" HEIGHT=431 WIDTH=692><BR>
|
||||
<BR>
|
||||
</P></CENTER>
|
||||
|
||||
<P>Now, evaluating <I>(f)</I> in thread B will call the function defined
|
||||
in thread A. It will return 12 which is the value of x in f's environment.
|
||||
If thread A defines a new x (using <B>define</B>), it will affect the result
|
||||
of subsequent calls to f.<BR>
|
||||
</P>
|
||||
|
||||
<P>Sharing environments and frames are Galapagos's way of allowing shared
|
||||
data. By default, however, most calculations are done at thread-specific
|
||||
frames. (More on this subject in the next section). Primitives are supplied
|
||||
to explicitly reference and manage environments: <B>clone-environment</B>
|
||||
can create a copy of an environment (so changing a binding in one copy
|
||||
does not alter the other); <B>extend-environment</B> and <B>pop-environment</B>
|
||||
can add and remove frames to and from environments. More environment functions
|
||||
are found in the next section of this document.<BR>
|
||||
</P>
|
||||
|
||||
<H2><A NAME="THREADS"></A>THREADS<BR>
|
||||
</H2>
|
||||
|
||||
<P>A thread is a SCHEME interpreter. The <I>base environment</I> of a thread
|
||||
is the thread's topmost environment. All forms entered at the thread's
|
||||
console or as arguments to <B>new-thread</B> are evaluated in the base
|
||||
environment. In traditional SCHEME there is only one thread of execution.
|
||||
It is a single thread and its base environment is the global environment.
|
||||
In Galapagos many interpreters can run concurrently, and each have its
|
||||
own environment (changing dynamically as computation progresses) and a
|
||||
base environment (which can be explicitly changed).<BR>
|
||||
</P>
|
||||
|
||||
<P>One thread is created by Galapagos upon startup. It is called the <I>main
|
||||
thread</I>, and it lasts for the whole Galapagos session. Its base environment
|
||||
is the global one - much like a traditional Scheme interpreter. Additional
|
||||
threads can be created using <B>new-thread</B>. These have their base environment
|
||||
set to a new environment, containing a single fresh frame pointing to the
|
||||
global environment. Any calculation done at the new thread's console takes
|
||||
place in this thread-local environment. However, if closure functions are
|
||||
used, then their evaluation may take place at the global environment or
|
||||
at some other thread's space, depending on where that function was defined.
|
||||
<BR>
|
||||
</P>
|
||||
|
||||
<P>When a thread finishes the execution of its commands it terminates.
|
||||
There are two exceptions to this rule: </P>
|
||||
|
||||
<OL>
|
||||
<LI>The main thread can be only terminated by using <B>quit-program</B>.
|
||||
</LI>
|
||||
|
||||
<LI>A thread that is bound to the console will not terminate at the end
|
||||
of execution but will wait for the next command input. </LI>
|
||||
</OL>
|
||||
|
||||
<P>Threads can communicate using the predicate <B>tell-thread</B> or by
|
||||
using the asynchronous message-queues system described later. In addition,
|
||||
SCM's <B><I>arbiters</I></B> were improved to be multithread safe. An arbiter
|
||||
object can serve as a guard on a critical section (where only one thread
|
||||
can work at a given time) of the program. The relevant primitves are <B>make-arbiter</B>,<B>
|
||||
try-arbiter</B>, and <B>release-arbiter</B>. <BR>
|
||||
</P>
|
||||
|
||||
<P>Note: Galapagos supports Scheme's notation of <B><I>continuations</I></B>.
|
||||
However, two restrictions apply: </P>
|
||||
|
||||
<OL>
|
||||
<LI>Only "cheap" continuations are supported. That is, a continuation
|
||||
can only be called when it is still active. This allows for continuations
|
||||
to be used to implement exception handling, etc. </LI>
|
||||
|
||||
<LI>Continuations can not cross thread boundaries. Also continuations,
|
||||
like any other Scheme object, can be handled by any thread, they can only
|
||||
be called from within the thread that created them. Trying to call a continuation
|
||||
from a different thread will cause an error. </LI>
|
||||
</OL>
|
||||
|
||||
<H2><A NAME="CONSOLES"></A>CONSOLES<BR>
|
||||
</H2>
|
||||
|
||||
<P>A <I>console</I> is a text window where the user can type commands (when
|
||||
the interpreter is idle) and see output. A console has a name which can
|
||||
be changed dynamically, which appears on its title bar. A thread may or
|
||||
may not be bound to a console. Information printed by a non-bound thread
|
||||
is lost; a non-bound thread waiting for input is stuck (unless provisions
|
||||
were made to allow a new console to be created by means of inter-thread
|
||||
communications.) If a non-bound thread has nothing to do, instead of waiting
|
||||
for input like a bound thread, it will terminate.<BR>
|
||||
</P>
|
||||
|
||||
<P>The main thread is always bound to a console. To bind a thread to a
|
||||
console use the command <B>bind-to-console</B> from within the thread.<BR>
|
||||
</P>
|
||||
|
||||
<H2><A NAME="DRAWING"></A>DRAWING BOARDS<BR>
|
||||
</H2>
|
||||
|
||||
<P>A board (window) is the graphical board on which the turtles and the
|
||||
user draw. It is a bitmap on which the user can draw interactively, by
|
||||
using the supplied GUI, or by creating turtles and instructing them to
|
||||
do the drawings.<BR>
|
||||
</P>
|
||||
|
||||
<P>The controls of the graphical user interface are located on the toolbar.
|
||||
The "shapes" of drawing are either a rectangle, a line or free
|
||||
hand drawing. The user pen can have three widths which are found under
|
||||
the <B>User Pen</B> menu. The numbers next to the sizes are the widths
|
||||
in pixels.<BR>
|
||||
</P>
|
||||
|
||||
<P>The colors of the user pen can be changes either from the <B>User Pen
|
||||
</B>menu or from the toolbar's color buttons. When choosing from a toolbar
|
||||
button, the user can know exactly what color (in RGB format) is used. <BR>
|
||||
</P>
|
||||
|
||||
<P>Each window has a name which is written on its title bar which can be
|
||||
changed using the <B>rename-window!</B> command. The board can be cleaned
|
||||
from all drawings using the <B>clear-window </B>command. <BR>
|
||||
</P>
|
||||
|
||||
<P>Since the board is a bitmap it can be saved to a BMP file using the
|
||||
<B>save-bitmap</B> command. A new background from a bitmap file can be
|
||||
loaded using the <B>load-bitmap</B> command.<BR>
|
||||
</P>
|
||||
|
||||
<H2><A NAME="TURTLES"></A>TURTLES<BR>
|
||||
</H2>
|
||||
|
||||
<P>A turtle is an object which is connected to a certain board. Each turtle
|
||||
has a pen with which it can draw on that board. The user can change the
|
||||
state of the turtle's pen including giving it the color of the board's
|
||||
background color (using the <B>pen-erase! </B>command). The pen will draw
|
||||
when it is "down" and will not draw when it is "up".
|
||||
Turtles can move between boards using the <B>move-turtle-to-window</B>
|
||||
command.<BR>
|
||||
</P>
|
||||
|
||||
<P>Each turtle holds its location as the a pair of coordinates where 0,0
|
||||
is the upper left corner of the board and 800,600 is the bottom-right corner
|
||||
of the board. The turtle's location can be changed by giving the turtle
|
||||
commands such as <B>forward!, backwards!, move-to!</B> or by using the
|
||||
move button from the toolbar.<BR>
|
||||
</P>
|
||||
|
||||
<P>A turtle also has a heading which is the direction it will move on the
|
||||
<B>forward!</B> command. The heading is in degrees, 0 meaning upwards and
|
||||
increasing clockwise, thus 90 means rightwards and so on. A turtle's heading
|
||||
can be changed by commands such as <B>right!, left!, </B>and<B> set-heading!</B>
|
||||
or interactively, by using the move button on the toolbar and pressing
|
||||
the control key.<BR>
|
||||
</P>
|
||||
|
||||
<P>A turtle can be visible on the board or be hidden. When it is visible
|
||||
the user can decide if it wants a "solid" or "hollow"
|
||||
turtle using the <B>make-hollow! </B>and <B>make-solid!</B> commands.<BR>
|
||||
</P>
|
||||
|
||||
<P>A turtle is always connected to a certain board, which is the board
|
||||
it is drawing on. To create a new turtle on a board use the <B>make-turtle</B>
|
||||
or the <B>clone-turtle</B> commands. A new turtle (created with the <B>make-turtle</B>
|
||||
command) will be black, solid, heading north and with it's pen down, in
|
||||
the center of the board. A cloned turtle will have exactly the same inner
|
||||
state as its parent.<BR>
|
||||
</P>
|
||||
|
||||
<P>A turtle can also look at the board and see other turtles or colors.
|
||||
By using the command <B>look</B> the user can tell the turtle the area
|
||||
in which to look and what to look in this area. </P>
|
||||
|
||||
<P>Example: </P>
|
||||
|
||||
<P>The command </P>
|
||||
|
||||
<P><I>(look t 50 20 '(0 0 0))</I> </P>
|
||||
|
||||
<P>will cause the turtle <I>t</I> to look for black pixels in the area
|
||||
in radius 50 from the turtle and 20 degrees to each side of the heading
|
||||
line, shown here in blue: </P>
|
||||
|
||||
<CENTER><P><IMG border=0 SRC="img00003.gif" HEIGHT=75 WIDTH=48><BR>
|
||||
</P></CENTER>
|
||||
|
||||
<H2><A NAME="INTERRUPTS (NOTIFICATIONS) AND MESSAGE"></A>INTERRUPTS (NOTIFICATIONS)
|
||||
AND MESSAGE HANDLERS<BR>
|
||||
</H2>
|
||||
|
||||
<P>A turtle can have interrupts. Each interrupt is defined in terms of
|
||||
turtle's vision. Whenever a turtle starts or stops seeing a given target,
|
||||
a predefined message is sent to the thread which asked the interrupt. The
|
||||
user can determine if the interrupt will notify on every change (like a
|
||||
"can see"- "can't see" toggle) or only when one change
|
||||
happens (only "can see" or "can't see" toggle). A message
|
||||
can be any valid SCHEME object.<BR>
|
||||
</P>
|
||||
|
||||
<P>Example: </P>
|
||||
|
||||
<P>The command </P>
|
||||
|
||||
<P><I>(turtle-notify t "I-see" "I-don't-see" 50 20
|
||||
color-black)</I> </P>
|
||||
|
||||
<P>tells the turtle <I>t</I> that every time it sees the color black it
|
||||
should send the message <I>"I-see"</I> and when it doesn't see
|
||||
the color black any more it should send the message <I>"I-don't-see"</I>.
|
||||
</P>
|
||||
|
||||
<P>Below is an example of what messages (or no message) <I>t </I>will send
|
||||
while it is moving forward, encountering two black lines on its way:<BR>
|
||||
<BR>
|
||||
<BR>
|
||||
<IMG border=0 SRC="vision.gif" HEIGHT=183 WIDTH=669></P>
|
||||
|
||||
<P><BR>
|
||||
<BR>
|
||||
If the interrupt was of kind "can see" (<B>notify-when</B> command)
|
||||
only the <I>"I-see"</I> messages were sent, and if it was a the
|
||||
"can't see" interrupt (<B>notify-when-not</B> command) only the
|
||||
<I>"I-can't-see" </I>style messages were sent.<BR>
|
||||
</P>
|
||||
|
||||
<P>A special "user interrupt" is invoked when the user right-clicks
|
||||
the turtle or a window. The <B>notify-on-click</B> command is used to enable
|
||||
this.<BR>
|
||||
</P>
|
||||
|
||||
<P>A thread can tell the turtle to delete a certain interrupt using the
|
||||
<B>turtle-no-notify</B> command. It can also tell the turtle to disable
|
||||
all interrupts using the <B>stop-notifying</B> command. <BR>
|
||||
</P>
|
||||
|
||||
<P>In order to process the messages sent from a turtle's interrupt (or
|
||||
from another thread, as presented later) the thread must install a <I>message
|
||||
handler</I> which is a one argument function. If no handler is installed
|
||||
the turtle's messages are lost. There can be only one handler per thread.
|
||||
If the handler is installed then every time an interrupt is invoked, the
|
||||
handler function in called with the message sent by the interrupt as its
|
||||
argument. <BR>
|
||||
<BR>
|
||||
</P>
|
||||
|
||||
<P>Example: </P>
|
||||
|
||||
<P>We declare the function: </P>
|
||||
|
||||
<P><I>(define (my-print x) (write x) (newline))</I> </P>
|
||||
|
||||
<P>and then install <I>my-print</I> as the current handler with: </P>
|
||||
|
||||
<P><I>(install-handler my-print)</I> </P>
|
||||
|
||||
<P>from now on every message a turtle's interrupt sends will be printed
|
||||
on screen. If <I>my-print</I> was installed in the previous example then
|
||||
we would have seen: <BR>
|
||||
</P>
|
||||
|
||||
<P><I>"I-see"</I> </P>
|
||||
|
||||
<P><I>"I-don't-see"</I> </P>
|
||||
|
||||
<P><I>"I-see"</I><BR>
|
||||
</P>
|
||||
|
||||
<P>on the screen.<BR>
|
||||
</P>
|
||||
|
||||
<P>A good example to view the interrupts in action is to make a turtle
|
||||
turn each time it sees a color and then let it wander aimlessly. Then use
|
||||
the user pen to draw lines the turtle's way and watch it change direction.
|
||||
See the PINGPONG.SCM file for a demo program. <BR>
|
||||
</P>
|
||||
|
||||
<P>The message-handler concept can be used as a mean of synchronous inter-thread
|
||||
communications. The tell-thread functions sends a message to a thread,
|
||||
which will be treated as an interrupt-generated message: It will cause
|
||||
the thread's message handler function to be called with tell-thread's argument
|
||||
as its own. This allows one thread to initiate a computation in a different
|
||||
thread's environment and CPU space synchronously and without sharing environments.
|
||||
<BR>
|
||||
</P>
|
||||
|
||||
<H2><A NAME="MESSAGE"></A>MESSAGE QUEUES<BR>
|
||||
</H2>
|
||||
|
||||
<P>In order to let threads communicate between themselves asynchronously
|
||||
a system of message queues was developed. A queue is an object which stores
|
||||
and relieves messages, stored in FIFO (First In First Out) style, meaning
|
||||
messages are read in the order of arrival to the queue. Supported messages
|
||||
are pairs of type and body, both of which can be any valid SCHEME object.
|
||||
Looking for messages of a certain type is also supported, allowing implementation
|
||||
of more flexible communication schemes than plain FIFO.<BR>
|
||||
</P>
|
||||
|
||||
<P>A thread can check if there are any messages in a given queue, if it
|
||||
does <B>get-message</B> without checking first if there are messages in
|
||||
the queue it will wait a given time-out or forever if no time-out is given.
|
||||
If by the end of the time-out no message were in the queue the result will
|
||||
be false.<BR>
|
||||
</P>
|
||||
|
||||
<P>Example: </P>
|
||||
|
||||
<P>In this example a queue <I>q</I> is created then a message is posted
|
||||
into the queue and read from it.<BR>
|
||||
</P>
|
||||
|
||||
<P><I>(define q (make-queue))</I> </P>
|
||||
|
||||
<P><I>(post-message q (cons 'type-circus 'bozo-the-clown))</I> </P>
|
||||
|
||||
<P><I>(define msg (get-message q))</I><BR>
|
||||
</P>
|
||||
|
||||
<P>now the command </P>
|
||||
|
||||
<P><I>(car msg) </I></P>
|
||||
|
||||
<P>will give </P>
|
||||
|
||||
<P><I>type-circus</I> </P>
|
||||
|
||||
<P>and the command </P>
|
||||
|
||||
<P><I>(cdr msg) </I></P>
|
||||
|
||||
<P>will yield </P>
|
||||
|
||||
<P><I>bozo-the-clown</I>. </P>
|
||||
|
||||
|
||||
<P>
|
||||
<HR width=80% align=left color=blue>
|
||||
<CENTER>
|
||||
<A href="#top"><IMG border=0 src=back.gif ALT=" [TOP] "></A>
|
||||
<A href="background.html"><IMG border=0 src=prev.gif ALT=" [PREV] "></A>
|
||||
<A href="gui.html"><IMG border=0 src=next.gif ALT=" [PREV] "></A>
|
||||
<A href="index.html#toc"><IMG border=0 src=toc.gif ALT=" [PREV] "></A>
|
||||
</CENTER>
|
||||
</BODY>
|
||||
</HTML>
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,73 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
||||
<HTML>
|
||||
<HEAD>
|
||||
<TITLE>Galapago - GUI</TITLE>
|
||||
<META NAME="Author" CONTENT="">
|
||||
<META NAME="GENERATOR" CONTENT="Mozilla/3.01Gold (Win95; I) [Netscape]">
|
||||
</HEAD>
|
||||
<BODY background=stone.jpg>
|
||||
|
||||
<CENTER>
|
||||
<A href="extensions.html"><IMG border=0 src=prev.gif ALT=" [PREV] "></A>
|
||||
<A href="implementation.html"><IMG border=0 src=next.gif ALT=" [PREV] "></A>
|
||||
<A href="index.html#toc"><IMG border=0 src=toc.gif ALT=" [PREV] "></A>
|
||||
</CENTER>
|
||||
<HR width=80% align=right color=blue>
|
||||
<P>
|
||||
|
||||
<H1 ALIGN=CENTER><A NAME="top"></A>THE INTERACTIVE GUI</H1>
|
||||
<HR>
|
||||
<P>In order to make Galapagos more fun to learn with, an interactive GUI
|
||||
(Graphical User Interface) is provided. Users can make changes on the board
|
||||
while a computation is in progress and effect its execution. Drawing tools
|
||||
enable the user to draw on the board while a program is being executed.
|
||||
If a line is drawn in front of a turtle which has a relevant interrupt,
|
||||
the interrupt will be invoked if needed.<BR>
|
||||
</P>
|
||||
|
||||
<P>The user has a special <I>user pen</I> that can draw line, rectangles
|
||||
or free hand. These modes are available from the toolbar. The User's pen
|
||||
width and color can be modified using the User Pen menu or the toolbar.<BR>
|
||||
</P>
|
||||
|
||||
<P>Color buttons are provided on the toolbar to give a known RGB color
|
||||
to the user pen. It is useful when the user draw an object on the board
|
||||
and wants a turtle to see this object. The colors are: </P>
|
||||
|
||||
<P>White - (255 255 255) </P>
|
||||
|
||||
<P>Black - (0 0 0) </P>
|
||||
|
||||
<P><FONT COLOR="#0000FF">Blue</FONT> - (0 0 255) </P>
|
||||
|
||||
<P><FONT COLOR="#FF0000">Red</FONT> - (255 0 0) </P>
|
||||
|
||||
<P><FONT COLOR="#00FF00">Green</FONT> - (0 255 0) </P>
|
||||
|
||||
<P><FONT COLOR="#FFFF00">Yellow</FONT> - (255 255 0)<BR>
|
||||
</P>
|
||||
|
||||
<P>Another option available is changing a turtle's heading and position,
|
||||
using the Move Turtle button: </P>
|
||||
|
||||
<CENTER><P><IMG border=0 SRC="img00010.gif" HEIGHT=33 WIDTH=37><BR>
|
||||
</P></CENTER>
|
||||
|
||||
<P>If this button is pressed then a turtle can be dragged to a new location
|
||||
simply by dragging it with the mouse. In order to change the turtle's heading,
|
||||
hold down a control key and move the move towards the desired location,
|
||||
the turtle will follow the movement of the mouse. </P>
|
||||
|
||||
<P>
|
||||
<HR width=80% align=left color=blue>
|
||||
<CENTER>
|
||||
<A href="#top"><IMG border=0 src=back.gif ALT=" [TOP] "></A>
|
||||
<A href="extensions.html"><IMG border=0 src=prev.gif ALT=" [PREV] "></A>
|
||||
<A href="implementation.html"><IMG border=0 src=next.gif ALT=" [PREV] "></A>
|
||||
<A href="index.html#toc"><IMG border=0 src=toc.gif ALT=" [PREV] "></A>
|
||||
</CENTER>
|
||||
</BODY>
|
||||
</HTML>
|
||||
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,393 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
||||
<HTML>
|
||||
<HEAD>
|
||||
<TITLE>Galapagos - Implementation</TITLE>
|
||||
<META NAME="Author" CONTENT="">
|
||||
<META NAME="GENERATOR" CONTENT="Mozilla/3.01Gold (Win95; I) [Netscape]">
|
||||
</HEAD>
|
||||
<BODY background=stone.jpg>
|
||||
|
||||
<CENTER>
|
||||
<A href="gui.html"><IMG border=0 src=prev.gif ALT=" [PREV] "></A>
|
||||
<A href="manual.html"><IMG border=0 src=next.gif ALT=" [PREV] "></A>
|
||||
<A href="index.html#toc"><IMG border=0 src=toc.gif ALT=" [PREV] "></A>
|
||||
</CENTER>
|
||||
<HR width=80% align=right color=blue>
|
||||
<P>
|
||||
|
||||
<H1 ALIGN=CENTER><A NAME="top"></A>IMPLEMENTATION</H1>
|
||||
|
||||
<UL>
|
||||
<LI><A HREF="implementation.html#GARBAGE">Garbage Collection</A></LI>
|
||||
<LI><A HREF="implementation.html#BOARDS">Boards</A></LI>
|
||||
<LI><A HREF="implementation.html#TURTLES">Turtles</A></LI>
|
||||
<LI><A HREF="implementation.html#VISION">Vision</A></LI>
|
||||
<LI><A HREF="implementation.html#INTERRUPTS">Interrupts</A></LI>
|
||||
<LI><A HREF="implementation.html#CLASS">Class Organization</A></LI>
|
||||
</UL>
|
||||
|
||||
<HR>
|
||||
<P>Galapagos was written using Microsoft Visual C++, and is designed to
|
||||
run under Windows 95. We chose Windows 95 because it seems to have the
|
||||
largest potential Galapagos users base. The following sections describe
|
||||
some implementation details of Galapagos.<BR>
|
||||
</P>
|
||||
|
||||
<P>The SCM interpreter we used as a base is written in C. Most of the original
|
||||
code we added was written in C++. The parts we used from SCM are almost
|
||||
identical to the original. In fact, by changing the scmconfig.h file (which
|
||||
contain machine-specific configuration) and #defining THREAD to be null,
|
||||
the C files should become equivalent to the sources we used.<BR>
|
||||
</P>
|
||||
|
||||
<P>We have implemented two MT-safe FIFO message queue classes. Both will
|
||||
block when trying to read from an empty queue. <B>CMsgQx</B>, the extended
|
||||
message queue, supports the same interface as the one provided in Scheme,
|
||||
plus an additional support for "Urgent Messages". These take
|
||||
precedence over all other messages. <B>CMessageQueue</B> is message queue
|
||||
with exactly the same interface as the Scheme level message queues, but
|
||||
which contain internal logic to handle "Urgent" messages used
|
||||
to deal with cases where synchronous respond is needed, such as I/O, Garbage
|
||||
collection, and Scheme-level inter-thread communications. <BR>
|
||||
</P>
|
||||
|
||||
<H2><A NAME="FITTING SCM INTO"></A>FITTING SCM INTO WINDOWS<BR>
|
||||
</H2>
|
||||
|
||||
<P>Galapagos is based on SCM, which is a single-thread, read-evaluate-print-loop
|
||||
(repl) based Scheme interpreter. The most important issue in migrating
|
||||
SCM was how to maintain the interpreter's natural repl-based approach,
|
||||
yet allow for multiple threads to interact, and for Windows messages to
|
||||
be processed quickly.<BR>
|
||||
</P>
|
||||
|
||||
<P>We used WIN32's multithreading capabilities to solve these problems.
|
||||
A single thread handles all aspects of the GUI - in a sense, "all
|
||||
that is Windows": graphic boards, turtles, consoles, menus and so
|
||||
on. Each interpreter runs in a thread of its own, interacting with the
|
||||
GUI using a message queue similar to the one provided at the Scheme level.<BR>
|
||||
</P>
|
||||
|
||||
<CENTER><P><IMG border=0 SRC="img00011.gif" HEIGHT=182 WIDTH=530><BR>
|
||||
</P></CENTER>
|
||||
|
||||
<P>The GUI thread manages both commands received from the OS and from the
|
||||
different interpreters running on their own threads. To ensure as fast
|
||||
responses as possible, priorities are used: OS messages (such as windows
|
||||
updates and input devices) gets highest priority; Console (text messages)
|
||||
come second, and graphics messages are last. This allows the interpreters
|
||||
to run interactively in a satisfactory manner. <BR>
|
||||
</P>
|
||||
|
||||
<P>SCM interpreter threads each run in the old-fashion repl mode. When
|
||||
a computation is over, the interpreter blocks until new input comes from
|
||||
the GUI thread. All blocking functions were modified to allow synchronous
|
||||
messages (such as the one generated by <B>tell-thread</B>) to work. In
|
||||
addition, SCM's "poll routine" is used to force checking for
|
||||
such messages even during computations.<BR>
|
||||
</P>
|
||||
|
||||
<P>An additional thread is used for Garbage Collection. It is described
|
||||
in detail in the section dealing with garbage collection.<BR>
|
||||
</P>
|
||||
|
||||
<H2><A NAME="GARBAGE"></A>GARBAGE COLLECTION</H2>
|
||||
|
||||
<P>In this section we will briefly describe SCM's garbage collector, and
|
||||
then discuss the modifications done to adapt it to Galapagos's multithreading
|
||||
computations. It should be noted that the garbage collector used is a portable
|
||||
garbage collector taken from "SCHEME IN ONE DEFUN, BUT IN C THIS TIME",
|
||||
by George J Carrette <gjc@world.std.com>. <BR>
|
||||
</P>
|
||||
|
||||
<P>SCM uses a conservative Mark & Sweep garbage collector (GC). All
|
||||
Scheme data objects share some common configuration (called "cells"):
|
||||
They are 8-byte aligned; they reside is specially-allocated memory segments
|
||||
(called hplims); they are the size of two pointers (so a scheme cons is
|
||||
exactly a cell); and they contain a special GC bit used by the garbage
|
||||
collector. This bit is 0 during actual computations. When a new cell is
|
||||
needed and all the hplims are used, garbage collection is initiated. If
|
||||
it does not free enough space to pass a certain threshold, a new hplim
|
||||
is allocated.<BR>
|
||||
</P>
|
||||
|
||||
<P>The first stage in garbage collection is marking all cells which are
|
||||
not to be deleted. Some terminology might be helpful here: <BR>
|
||||
</P>
|
||||
|
||||
<UL>
|
||||
<LI>A cell (or any data object) is called <B><I>alive</I></B> if it may
|
||||
in some way influence the future of the computation. Needless to say, discovering
|
||||
which cells are alive and which are not is impossible, because of the very
|
||||
nature of the future. </LI>
|
||||
</UL>
|
||||
|
||||
<UL>
|
||||
<LI>A cell is called <B><I>reachable</I></B> if the computation can read
|
||||
its value. Some data is <I>immediately reachable</I>: The data on the machine's
|
||||
stack or in the CPU registers, for example; some interpreters store some
|
||||
information in a fixed location so it's permanently reachable. In SCM the
|
||||
array <TT><FONT FACE="Courier New">sys_protects[]</FONT></TT> is used for
|
||||
this propose. The set of reachable cells is the union of all immediately
|
||||
reachable cells, and all those cells pointed by reachable cells, recursively.
|
||||
</LI>
|
||||
</UL>
|
||||
|
||||
<P>Obviously, all unreachable data is dead. Conservative garbage collectors
|
||||
treat all reachable data as alive. <BR>
|
||||
</P>
|
||||
|
||||
<P>The Mark stage of the garbage collector scans the <TT><FONT FACE="Courier New">sys_protects[]</FONT></TT>
|
||||
array and the machine's stack and registers for anything that looks like
|
||||
a valid cell. All cell pointer have their 3 least significant bits zero,
|
||||
and are in one of few known ranges (the hplims). The garbage collector
|
||||
searches for anything matching a cell's bit pattern, and treats it as an
|
||||
immediately reachable cell pointer. In some cases, this may mean an integer,
|
||||
for example, happens to match the binary pattern and thus be interpreted
|
||||
as a cell pointer. However, this will only mean some cell or cells are
|
||||
marked as reachable though they are not such. Because of the uniform structure
|
||||
of the cell and its limited range of possible locations, such an accident
|
||||
is guarantied not to corrupt memory. Furthermore, if we accept the assumption
|
||||
that integers are usually relatively small, and memory addresses are relatively
|
||||
big, we conclude that such accidents are not very likely to happen often
|
||||
anyway.<BR>
|
||||
</P>
|
||||
|
||||
<P>During mark stage, the garbage collector recursively finds (a superset
|
||||
of) all live cells, and marks them by setting their special GC bit to 1.
|
||||
The second stage is the Sweep stage, in which all the hplims are scanned
|
||||
linearly, and every cell which is not marked is recognized as dead, and
|
||||
as such is reclaimed as free. Marked cells get unmarked so they are ready
|
||||
for the next garbage collection. <BR>
|
||||
</P>
|
||||
|
||||
<P>Mark & Sweep garbage collection has two main disadvantages: One,
|
||||
that it requires all computation to stop while garbage collection is in
|
||||
progress. In Galapagos, since all threads use a shared memory heap, it
|
||||
means all threads must synchronize and halt while garbage is collected.
|
||||
Second, Mark & Sweep is very likely to cause memory fragmentation.
|
||||
However, since cells are equally sized, fragmentation is only rarely a
|
||||
problem.<BR>
|
||||
</P>
|
||||
|
||||
<P>We chose to stick with Mark & Sweep in Galapagos because of its
|
||||
two major advantages: Simplicity and efficiency. Mark & Sweep GC does
|
||||
not affect computation speed, because direct pointers are used. Most concurrent
|
||||
garbage collectors work by making all pointers indirect, which may slow
|
||||
computations down considerably. The need to halt all threads for GC is
|
||||
accepted. Since memory is shared, it would only be fair to stop all threads
|
||||
when GC is needed: Threads will probably halt anyway since cells are allocated
|
||||
continuously during computations.<BR>
|
||||
</P>
|
||||
|
||||
<P>Two major issues are introduced when trying to multithread the garbage
|
||||
collector. One is the synchronization of the different threads, which run
|
||||
almost completely unaware one of the other; the second is the need to mark
|
||||
data from every thread's specific stack, registers, and <TT><FONT FACE="Courier New">sys_protects[]</FONT></TT>.
|
||||
We solved these two issues by combining them to one.<BR>
|
||||
</P>
|
||||
|
||||
<P>The intuitive approach might be to let each thread mark its own information,
|
||||
and then sweep centrally. However, since synchronization of threads is
|
||||
mandatory, letting every thread mark its own data will lead only to redundant
|
||||
marking and to excessive context switches, since each threads has to become
|
||||
active. Therefore we created the "<B>Garbage Collection daemon</B>"
|
||||
(GCd), which runs in a distinct thread and lasts for the whole Galapagos
|
||||
session. The GCd is not an interpreter, but a mechanism which keeps track
|
||||
of live threads and their need of GC. The GCd thread is always blocked,
|
||||
except when a thread notifies it on its birth or death, or when a thread
|
||||
indicates the need for garbage collection. Since the GC daemon is blocked
|
||||
whenever it is not needed, and then becomes the exclusive running thread
|
||||
during actual GC (with the exception of the GUI thread), its existence
|
||||
does not hurt performance. <BR>
|
||||
</P>
|
||||
|
||||
<P>To explain how the GCd synchronizes all threads, let us examine the
|
||||
three-way protocol involved. <TT><FONT FACE="Courier New">freelist</FONT></TT>
|
||||
is a global pointer which holds a linked list of free cells - it can be
|
||||
either a cell pointer, a value indicating "busy" (thus implementing
|
||||
busy/wait protection over it) or "end of memory" which is found
|
||||
at the end of the linked list. MIB stands for <B><I>Memory Information
|
||||
Block</I></B>, which is a block of memory containing all of a thread's
|
||||
immediately reachable data.<BR>
|
||||
</P>
|
||||
|
||||
<P><B><U>GCd scenario:</U></B> GCd is blocked until a threads sends a GC
|
||||
request. </P>
|
||||
|
||||
<OL>
|
||||
<LI>GCd scans through its list of active threads, and sends each a <I>MIB
|
||||
request</I>. </LI>
|
||||
|
||||
<LI>It then blocks until all MIB blocks are received. GCd ignores further
|
||||
GC request messages it get. </LI>
|
||||
|
||||
<LI>At this point all threads are blocked. The GCd has gained, therefore,
|
||||
exclusive access to the hplims. The GCd now marks all reachable cells,
|
||||
inspecting each MIB block for immediately reachable cells and proceeding
|
||||
recursively. Then, it sweeps. </LI>
|
||||
|
||||
<LI>If needed, the GCd allocated a fresh hplim. </LI>
|
||||
|
||||
<LI>GCd sends every thread a message allowing it to resume. Then it blocks
|
||||
waiting for the next time. </LI>
|
||||
</OL>
|
||||
|
||||
<P><B><U>Scenario 1:</U></B> A thread needs to allocate a cell but can't.
|
||||
</P>
|
||||
|
||||
<OL>
|
||||
<LI>The thread sends GCd a<I> GC request message.</I> </LI>
|
||||
|
||||
<LI>Then it suspends until GCd sends it an <I>MIB request</I>. </LI>
|
||||
|
||||
<LI>When one arrives, the thread generates and sends a MIB block to the
|
||||
GCd. </LI>
|
||||
|
||||
<LI>And blocks again until GCd notifies it that GC is done. </LI>
|
||||
|
||||
<LI>At this point free cells are available and the computation can resume.
|
||||
</LI>
|
||||
</OL>
|
||||
|
||||
<P><B><U>Scenario 2:</U></B> A thread receives a<I> MIB request</I>. This
|
||||
may happen within a computation or when considered otherwise blocked -
|
||||
waiting for input, for example. </P>
|
||||
|
||||
<OL>
|
||||
<LI>The thread generates and sends a MIB block to the GCd. </LI>
|
||||
|
||||
<LI>And blocks until GCd notifies it that GC is done. </LI>
|
||||
</OL>
|
||||
|
||||
<P>The important thing to note about this protocol is its indifference
|
||||
to the GC "initiator". Several threads can "initiate"
|
||||
GC, and each request is "satisfied", although of course only
|
||||
one GC takes place. The GCd itself is unaware of the initiating thread
|
||||
identity, and completely ignores any further GC requests. It treats all
|
||||
threads identically. This is important because it allows each thread meeting
|
||||
a low memory condition to initiate GC immediately. This is in fact the
|
||||
mechanism which saves us from explicitly checking for a third-party GC
|
||||
request during computation: If a thread runs out of memory, the <TT><FONT FACE="Courier New">freelist</FONT></TT>
|
||||
variable is kept at "out of memory" state, causing any other
|
||||
thread trying to allocate memory to initiate GC as well. This simplifies
|
||||
the GC protocol (technically, if not conceptually), and does it with almost
|
||||
no affect on computation speed.<BR>
|
||||
</P>
|
||||
|
||||
<H2><A NAME="BOARDS"></A>BOARDS<BR>
|
||||
</H2>
|
||||
|
||||
<P>A board or a view as it called in MFC is the environment where a turtle
|
||||
moves and interact with. It hold two main data structures. The first is
|
||||
the bitmap of the drawing. It is a 800X600 bitmap. Every time a turtle
|
||||
draws on the board it makes its pen the active pen on the board and draws
|
||||
on it. Every time the picture needs refreshing (as signaled by the operating
|
||||
system) it is the board's duty to copy the relevant section from the bitmap
|
||||
to the screen. The second data object is the turtles list, an expandable
|
||||
array of turtles which holds pointers to all turtles on the specific board.<BR>
|
||||
</P>
|
||||
|
||||
<P>The most important part in the board's work is to notify the turtles
|
||||
on any event that happened on the board such as drawing, changing background
|
||||
or moving of a turtle. If for example a user draws a line on the board,
|
||||
the board (after drawing the line) goes through the turtles list and tell
|
||||
each one that some event happened at a rectangle that contains the line.
|
||||
Each turtle will decide if this has any importance to it or not.<BR>
|
||||
</P>
|
||||
|
||||
<P>Apart from that, the board handles all the user interface from the menus
|
||||
and the toolbar. The most obvious example is the move turtle button, which,
|
||||
when pressed, causes the board to find a turtle close enough to the click's
|
||||
location. Then, on every movement of the mouse it gives the turtle a command
|
||||
to move to this point. <BR>
|
||||
</P>
|
||||
|
||||
<P>In order to support scrolling of the picture, we derived the <B>CBoardView</B>
|
||||
class from <B>CScrollView</B>. The interface with the interpreter threads
|
||||
is done via a message queue. The main function is <TT><FONT FACE="Courier New">ReadAndEval,</FONT></TT>
|
||||
which gets a message and then interprets its and act upon the result.<BR>
|
||||
</P>
|
||||
|
||||
<H2><A NAME="TURTLES"></A>TURTLES<BR>
|
||||
</H2>
|
||||
|
||||
<P>In addition to a pointer to its current board, and to inner-state variable
|
||||
which affects its graphical aspects, every turtle holds an expandable array
|
||||
of interrupts. When a turtle gets from the window that a message signifying
|
||||
that some change has happened, it sends this change to each of its interrupts
|
||||
(only if the interrupt flag is on) and the interrupt is responsible to
|
||||
send an appropriate message if necessary. The turtle's location are stored
|
||||
as floating points on x,y axes, to allow for accuracy on the turtle's location
|
||||
and heading.<BR>
|
||||
</P>
|
||||
|
||||
<P>The turtles interacts with the interpreter thread using a message queue.
|
||||
As with the board, the main function here is the <TT><FONT FACE="Courier New">ReadAndEval,</FONT></TT>
|
||||
which translates these messages to valid function calls.<BR>
|
||||
</P>
|
||||
|
||||
<H2><A NAME="VISION"></A>VISION<BR>
|
||||
</H2>
|
||||
|
||||
<P>Every turtle holds a pointer to the bitmap it is drawing on. When it
|
||||
is "looking" for a color it calculates the minimal rectangle
|
||||
that holds the desired area. Then it iterates on all the pixels in this
|
||||
rectangle. First it checks if the pixel is in the vision area using the
|
||||
sign rule to determine if a point is clockwise or anti clockwise from a
|
||||
line, and then check for distance. If the point is in the relevant area
|
||||
the turtle gets its color from the bitmap and compares it with the sought
|
||||
color. <BR>
|
||||
</P>
|
||||
|
||||
<P>When looking for a specific turtle, the turtle gets this turtle's position
|
||||
and calculates if this location is in the relevant area using the same
|
||||
algorithm. When looking for any turtle, the turtle passes the relevant
|
||||
arguments to the view, which then uses the same algorithm for each turtle
|
||||
on its turtles array.<BR>
|
||||
</P>
|
||||
|
||||
<H2><A NAME="INTERRUPTS"></A>INTERRUPTS<BR>
|
||||
</H2>
|
||||
|
||||
<P>Each turtle holds an expandable array of interrupts. Each interrupts
|
||||
is an object that is much like a turtle vision. The interrupts has the
|
||||
view area argument and what it is looking for. It also has the message
|
||||
it needs to send and a pointer to the given queue. When the turtle notifies
|
||||
the interrupt that a change has happened, the interrupt first checks if
|
||||
the change is an area which is of interest to it. If so it calls the turtle
|
||||
look function with its location and the sought object. According to the
|
||||
turtle's answer and to the data stored inside the interrupt, the interrupt
|
||||
sends the needed message, if any.<BR>
|
||||
<BR>
|
||||
</P>
|
||||
|
||||
<H2><A NAME="CLASS"></A>CLASS ORGANIZATION<BR>
|
||||
</H2>
|
||||
|
||||
<P><CENTER><IMG border=0 SRC="img00012.gif" HEIGHT=626 WIDTH=693><BR>
|
||||
</CENTER>
|
||||
</P>
|
||||
|
||||
<P>Message-passing mechanisms:<BR>
|
||||
</P>
|
||||
|
||||
<P>
|
||||
<CENTER><IMG border=0 SRC="img00013.gif" HEIGHT=198 WIDTH=694> </CENTER></P>
|
||||
<FONT SIZE=+3></FONT>
|
||||
|
||||
|
||||
<P>
|
||||
<HR width=80% align=left color=blue>
|
||||
<CENTER>
|
||||
<A href="#top"><IMG border=0 src=back.gif ALT=" [TOP] "></A>
|
||||
<A href="gui.html"><IMG border=0 src=prev.gif ALT=" [PREV] "></A>
|
||||
<A href="manual.html"><IMG border=0 src=next.gif ALT=" [PREV] "></A>
|
||||
<A href="index.html#toc"><IMG border=0 src=toc.gif ALT=" [PREV] "></A>
|
||||
</CENTER>
|
||||
</BODY>
|
||||
</HTML>
|
||||
|
||||
|
||||
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
|
|
@ -0,0 +1,81 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
||||
<HTML>
|
||||
<HEAD>
|
||||
<TITLE>Galapagos - Bibliography</TITLE>
|
||||
<META NAME="GENERATOR" CONTENT="Mozilla/3.01Gold (Win95; I) [Netscape]">
|
||||
</HEAD>
|
||||
<BODY background=stone.jpg>
|
||||
|
||||
<CENTER>
|
||||
<A href="index.html#toc"><IMG border=0 src=toc.gif ALT=" [PREV] "></A>
|
||||
</CENTER>
|
||||
<HR width=80% align=right color=blue>
|
||||
<P>
|
||||
|
||||
<H1 ALIGN=CENTER>BIBLIOGRAPHY</H1>
|
||||
<HR>
|
||||
|
||||
<UL>
|
||||
<LI><A HREF="http://www.cs.cmu.edu:8001/Web/Groups/AI/html/faqs/lang/scheme/top.html"><B>The
|
||||
SCHEME FAQ</B></A>,<BR><TT>
|
||||
http://www.cs.cmu.edu:8001/Web/Groups/AI/html/faqs/lang/scheme/top.html
|
||||
</TT></LI><P>
|
||||
|
||||
<LI><A HREF="ftp://cher.media.mit.edu/pub/logo/FAQ"><B>The LOGO FAQ</B></A>,<BR><TT>
|
||||
ftp://cher.media.mit.edu/pub/logo/FAQ
|
||||
</TT></LI><P>
|
||||
|
||||
<LI><B>SCM manual version 4e4</B>, Aubrey Jaffer. SCM 4e4 is available
|
||||
at: <BR>
|
||||
<TT><A
|
||||
HREF="ftp://ftp-swiss.ai.mit.edu/pub/scm/scm4e4.tar.gz">ftp://ftp-swiss.ai.mit.edu/pub/scm/scm4e4.tar.gz</A>
|
||||
</TT></LI><P>
|
||||
|
||||
<LI><B>Structure and interpretation of computer programs,</B>
|
||||
Harold Ableson and Gerald J. Sussman with Julie Sussman.
|
||||
</LI><P>
|
||||
|
||||
<LI><B>Garbage Collection</B>, Andrew W. Appel; appeard
|
||||
in <B>Topics in Advanced Language Implementation</B>, edited by Peter Lee. </LI><P>
|
||||
</UL>
|
||||
|
||||
<P>
|
||||
<HR>
|
||||
<P><B><H1><CENTER>LINKS</CENTER></H1></B>
|
||||
</P>
|
||||
<P>
|
||||
<UL>
|
||||
<LI>Scheme:<P>
|
||||
<UL>
|
||||
<LI><A HREF="http://www.cs.indiana.edu/scheme-repository/home.html">SCHEME repository</A><P></LI>
|
||||
<LI><A HREF="http://people.delphi.com/gjc/siod.html">SIOD</A><P></LI>
|
||||
<LI><A HREF="http://www-swiss.ai.mit.edu/~jaffer/SCM.html">SCM</A><P></LI>
|
||||
</UL>
|
||||
</LI>
|
||||
|
||||
<LI>The Programmers:
|
||||
<P>
|
||||
<UL>
|
||||
<LI><A href="http://www.cs.bgu.ac.il/~elad">Elad's Spot on the Web</A> <<TT><A href="mailto:elad@cs.bgu.ac.il">elad@cs.bgu.ac.il</A></TT>></LI>
|
||||
<P>
|
||||
<LI><A href="http://www.cs.bgu.ac.il/~tebeka">Miki's Terrible Homepage</A> <<TT><A href="mailto:tebeka@cs.bgu.ac.il">tebeka@cs.bgu.ac.il</A></TT>></LI>
|
||||
<P></UL>
|
||||
|
||||
<LI>The Advisor:
|
||||
<P>
|
||||
<UL>
|
||||
<LI><A href="http://www.cs.bgu.ac.il/~elhadad">Dr. Michael Elhadad</A>
|
||||
<<TT><A href="mailto:elhadad@cs.bgu.ac.il">elhadad@cs.bgu.ac.il</A></TT>></LI>
|
||||
</UL>
|
||||
|
||||
</UL>
|
||||
<P>
|
||||
<HR width=80% align=left color=blue>
|
||||
<CENTER>
|
||||
<A href="index.html#toc"><IMG border=0 src=toc.gif ALT=" [PREV] "></A>
|
||||
</CENTER>
|
||||
</BODY>
|
||||
</HTML>
|
||||
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,95 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
||||
<HTML>
|
||||
<HEAD>
|
||||
<TITLE>Galapagos</TITLE>
|
||||
</HEAD>
|
||||
<BODY background=stone.jpg>
|
||||
|
||||
<CENTER><P><B><FONT COLOR="#008040" SIZE=+4>Welcome to<BR>
|
||||
<IMG border=0 SRC=gps.gif alt="GALAPAGOS"></FONT></B></P></CENTER>
|
||||
|
||||
Galapagos is an interactive multithreaded Scheme interpreter with turtle
|
||||
graphics for Windows 95. It is built around the SCM interpreter, and it
|
||||
provides multiple interpreters, threads, turtles, and drawing boards, all
|
||||
running concurrently using WIN32's multithreading abilities, and freely
|
||||
<A href="#download">available</A>.
|
||||
|
||||
<P>
|
||||
<HR>
|
||||
<P>
|
||||
<Center>
|
||||
<A href="http://www.cs.bgu.ac.il"><IMG border=0 src="bgu_logo_tiny.gif" alt=""></A><BR><BR>
|
||||
Spring 1997<BR><BR>
|
||||
Graduation project<BR><BR>
|
||||
<A href="http://www.cs.bgu.ac.il">Department of Math & Computer Science,</A><BR><BR>
|
||||
<A href="http://www.bgu.ac.il">Ben-Gurion University of the Negev</A><BR><BR>
|
||||
<BR>
|
||||
Written by <A href="http://www.cs.bgu.ac.il/~elad">Elad Eyal</A> and <A href="http://www.cs.bgu.ac.il/~tebeka">Miki
|
||||
Tebeka</A>.<BR>
|
||||
<BR>
|
||||
Supervisor: <A href="http://www.cs.bgu.ac.il/~elhadad">Dr. Michael Elhadad</A>
|
||||
</CENTER>
|
||||
<P>
|
||||
<P>
|
||||
<HR width=100%>
|
||||
<P>
|
||||
<A name="toc">
|
||||
<CENTER><P><B><FONT SIZE=+3>TABLE OF CONTENTS </FONT></B></P></CENTER>
|
||||
|
||||
<UL>
|
||||
<LI><A HREF="background.html">Background </A></LI>
|
||||
<UL>
|
||||
<LI><A HREF="background.html#SCHEME">SCHEME</A></LI>
|
||||
<LI><A HREF="background.html#LOGO AND TURTLE">LOGO and Turtle Geometry</A></LI>
|
||||
<LI><A HREF="background.html#OBJECTIVES">Objectives</A></LI>
|
||||
<LI><A HREF="background.html#AVAILABILITY">Avaliability</A></LI>
|
||||
</UL>
|
||||
<LI><A HREF="extensions.html">SCHEME extensions</A></LI>
|
||||
<UL>
|
||||
<LI><A HREF="extensions.html#THE NEW ENVIRONMENT">The New Environment Model</A></LI>
|
||||
<LI><A HREF="extensions.html#THREADS">Threads</A></LI>
|
||||
<LI><A HREF="extensions.html#CONSOLES">Consoles</A></LI>
|
||||
<LI><A HREF="extensions.html#DRAWING">Drawing Boards</A></LI>
|
||||
<LI><A HREF="extensions.html#TURTLES">Turtles</A></LI>
|
||||
<LI><A HREF="extensions.html#INTERRUPTS (NOTIFICATIONS) AND MESSAGE">Interrupts (Notifications) and Message handlers</A></LI>
|
||||
</UL>
|
||||
<LI><A HREF="gui.html">The interactive GUI</A></LI>
|
||||
<LI><A HREF="implementation.html">Implementation</A></LI>
|
||||
<UL>
|
||||
<LI><A HREF="implementation.html#FITTING SCM INTO">Fitting SCM into Windows</A></LI>
|
||||
<LI><A HREF="implementation.html#GARBAGE">Garbage Collection</A></LI>
|
||||
<LI><A HREF="implementation.html#BOARDS">Boards</A></LI>
|
||||
<LI><A HREF="implementation.html#TURTLES">Turtles</A></LI>
|
||||
<LI><A HREF="implementation.html#VISION">Vision</A></LI>
|
||||
<LI><A HREF="implementation.html#INTERRUPTS">Interrupts</A></LI>
|
||||
<LI><A HREF="implementation.html#CLASS">Class Organization</A></LI>
|
||||
</UL>
|
||||
<LI><A HREF="manual.html">Programer's Manual</A></LI>
|
||||
<UL>
|
||||
<LI><A HREF="manual.html#ENVIRONMENTS">Environments</A></LI>
|
||||
<LI><A HREF="manual.html#MESSAGE">Message Queues</A></LI>
|
||||
<LI><A HREF="manual.html#WINDOW">Window Commands</A></LI>
|
||||
<LI><A HREF="manual.html#TURTLE">Turtle Commands</A></LI>
|
||||
<LI><A HREF="manual.html#VISION">Vision</A></LI>
|
||||
<LI><A HREF="manual.html#INTERRUPTS">Interrupts (Notifications)</A></LI>
|
||||
<LI><A HREF="manual.html#THREADS">Threads</A></LI>
|
||||
</UL>
|
||||
<LI><A HREF="bib.html">Bibiliography and Links</A></LI>
|
||||
</UL>
|
||||
|
||||
<P>
|
||||
|
||||
<BR>
|
||||
<A name="download">
|
||||
<CENTER><P><B><FONT SIZE=+3>DOWNLOAD CENTER</FONT></B></P></CENTER>
|
||||
<P>
|
||||
<CENTER><FONT size=-1><TT>GNU LICENSE. COPYRIGHTED. PROVIDED "AS IS". NO
|
||||
WARRANTIES OR LIABILITIES. ETC.</TT></CENTER>
|
||||
<P>
|
||||
<P>
|
||||
500K <A href="gps10bin.zip"><TT>gps10bin.zip</TT></A> - Executable and required Scheme libraries (SLIB)<BR>
|
||||
700K <A href="gps10src.zip"><TT>gps10src.zip</TT></A> - Same with all source code <BR>
|
||||
400K <A href="mfc40dll.zip"><TT>mfc40dll.zip</TT></A> - You might need this MFC40.DLL if you
|
||||
don't have it already. <BR>
|
||||
</BODY>
|
||||
</HTML>
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 752 B |
Binary file not shown.
|
After Width: | Height: | Size: 740 B |
Binary file not shown.
|
After Width: | Height: | Size: 2.4 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 1.5 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 1.4 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 1.7 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 6.4 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 6.7 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 1.1 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 3.5 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 1.0 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 3.7 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 18 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 4.5 KiB |
|
|
@ -0,0 +1,95 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
||||
<HTML>
|
||||
<HEAD>
|
||||
<TITLE>Galapagos</TITLE>
|
||||
</HEAD>
|
||||
<BODY background=stone.jpg>
|
||||
|
||||
<CENTER><P><B><FONT COLOR="#008040" SIZE=+4>Welcome to<BR>
|
||||
<IMG border=0 SRC=gps.gif alt="GALAPAGOS"></FONT></B></P></CENTER>
|
||||
|
||||
Galapagos is an interactive multithreaded Scheme interpreter with turtle
|
||||
graphics for Windows 95. It is built around the SCM interpreter, and it
|
||||
provides multiple interpreters, threads, turtles, and drawing boards, all
|
||||
running concurrently using WIN32's multithreading abilities, and freely
|
||||
<A href="#download">available</A>.
|
||||
|
||||
<P>
|
||||
<HR>
|
||||
<P>
|
||||
<Center>
|
||||
<A href="http://www.cs.bgu.ac.il"><IMG border=0 src="bgu_logo_tiny.gif" alt=""></A><BR><BR>
|
||||
Spring 1997<BR><BR>
|
||||
Graduation project<BR><BR>
|
||||
<A href="http://www.cs.bgu.ac.il">Department of Math & Computer Science,</A><BR><BR>
|
||||
<A href="http://www.bgu.ac.il">Ben-Gurion University of the Negev</A><BR><BR>
|
||||
<BR>
|
||||
Written by <A href="http://www.cs.bgu.ac.il/~elad">Elad Eyal</A> and <A href="http://www.cs.bgu.ac.il/~tebeka">Miki
|
||||
Tebeka</A>.<BR>
|
||||
<BR>
|
||||
Supervisor: <A href="http://www.cs.bgu.ac.il/~elhadad">Dr. Michael Elhadad</A>
|
||||
</CENTER>
|
||||
<P>
|
||||
<P>
|
||||
<HR width=100%>
|
||||
<P>
|
||||
<A name="toc">
|
||||
<CENTER><P><B><FONT SIZE=+3>TABLE OF CONTENTS </FONT></B></P></CENTER>
|
||||
|
||||
<UL>
|
||||
<LI><A HREF="background.html">Background </A></LI>
|
||||
<UL>
|
||||
<LI><A HREF="background.html#SCHEME">SCHEME</A></LI>
|
||||
<LI><A HREF="background.html#LOGO AND TURTLE">LOGO and Turtle Geometry</A></LI>
|
||||
<LI><A HREF="background.html#OBJECTIVES">Objectives</A></LI>
|
||||
<LI><A HREF="background.html#AVAILABILITY">Avaliability</A></LI>
|
||||
</UL>
|
||||
<LI><A HREF="extensions.html">SCHEME extensions</A></LI>
|
||||
<UL>
|
||||
<LI><A HREF="extensions.html#THE NEW ENVIRONMENT">The New Environment Model</A></LI>
|
||||
<LI><A HREF="extensions.html#THREADS">Threads</A></LI>
|
||||
<LI><A HREF="extensions.html#CONSOLES">Consoles</A></LI>
|
||||
<LI><A HREF="extensions.html#DRAWING">Drawing Boards</A></LI>
|
||||
<LI><A HREF="extensions.html#TURTLES">Turtles</A></LI>
|
||||
<LI><A HREF="extensions.html#INTERRUPTS (NOTIFICATIONS) AND MESSAGE">Interrupts (Notifications) and Message handlers</A></LI>
|
||||
</UL>
|
||||
<LI><A HREF="gui.html">The interactive GUI</A></LI>
|
||||
<LI><A HREF="implementation.html">Implementation</A></LI>
|
||||
<UL>
|
||||
<LI><A HREF="implementation.html#FITTING SCM INTO">Fitting SCM into Windows</A></LI>
|
||||
<LI><A HREF="implementation.html#GARBAGE">Garbage Collection</A></LI>
|
||||
<LI><A HREF="implementation.html#BOARDS">Boards</A></LI>
|
||||
<LI><A HREF="implementation.html#TURTLES">Turtles</A></LI>
|
||||
<LI><A HREF="implementation.html#VISION">Vision</A></LI>
|
||||
<LI><A HREF="implementation.html#INTERRUPTS">Interrupts</A></LI>
|
||||
<LI><A HREF="implementation.html#CLASS">Class Organization</A></LI>
|
||||
</UL>
|
||||
<LI><A HREF="manual.html">Programer's Manual</A></LI>
|
||||
<UL>
|
||||
<LI><A HREF="manual.html#ENVIRONMENTS">Environments</A></LI>
|
||||
<LI><A HREF="manual.html#MESSAGE">Message Queues</A></LI>
|
||||
<LI><A HREF="manual.html#WINDOW">Window Commands</A></LI>
|
||||
<LI><A HREF="manual.html#TURTLE">Turtle Commands</A></LI>
|
||||
<LI><A HREF="manual.html#VISION">Vision</A></LI>
|
||||
<LI><A HREF="manual.html#INTERRUPTS">Interrupts (Notifications)</A></LI>
|
||||
<LI><A HREF="manual.html#THREADS">Threads</A></LI>
|
||||
</UL>
|
||||
<LI><A HREF="bib.html">Bibiliography and Links</A></LI>
|
||||
</UL>
|
||||
|
||||
<P>
|
||||
|
||||
<BR>
|
||||
<A name="download">
|
||||
<CENTER><P><B><FONT SIZE=+3>DOWNLOAD CENTER</FONT></B></P></CENTER>
|
||||
<P>
|
||||
<CENTER><FONT size=-1><TT>GNU LICENSE. COPYRIGHTED. PROVIDED "AS IS". NO
|
||||
WARRANTIES OR LIABILITIES. ETC.</TT></CENTER>
|
||||
<P>
|
||||
<P>
|
||||
500K <A href="gps10bin.zip"><TT>gps10bin.zip</TT></A> - Executable and required Scheme libraries (SLIB)<BR>
|
||||
700K <A href="gps10src.zip"><TT>gps10src.zip</TT></A> - Same with all source code <BR>
|
||||
400K <A href="mfc40dll.zip"><TT>mfc40dll.zip</TT></A> - You might need this MFC40.DLL if you
|
||||
don't have it already. <BR>
|
||||
</BODY>
|
||||
</HTML>
|
||||
|
|
@ -0,0 +1,73 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
||||
<HTML>
|
||||
<HEAD>
|
||||
<TITLE>Galapago - GUI</TITLE>
|
||||
<META NAME="Author" CONTENT="">
|
||||
<META NAME="GENERATOR" CONTENT="Mozilla/3.01Gold (Win95; I) [Netscape]">
|
||||
</HEAD>
|
||||
<BODY background=stone.jpg>
|
||||
|
||||
<CENTER>
|
||||
<A href="extensions.html"><IMG border=0 src=prev.gif ALT=" [PREV] "></A>
|
||||
<A href="implementation.html"><IMG border=0 src=next.gif ALT=" [PREV] "></A>
|
||||
<A href="index.html#toc"><IMG border=0 src=toc.gif ALT=" [PREV] "></A>
|
||||
</CENTER>
|
||||
<HR width=80% align=right color=blue>
|
||||
<P>
|
||||
|
||||
<H1 ALIGN=CENTER><A NAME="top"></A>THE INTERACTIVE GUI</H1>
|
||||
<HR>
|
||||
<P>In order to make Galapagos more fun to learn with, an interactive GUI
|
||||
(Graphical User Interface) is provided. Users can make changes on the board
|
||||
while a computation is in progress and effect its execution. Drawing tools
|
||||
enable the user to draw on the board while a program is being executed.
|
||||
If a line is drawn in front of a turtle which has a relevant interrupt,
|
||||
the interrupt will be invoked if needed.<BR>
|
||||
</P>
|
||||
|
||||
<P>The user has a special <I>user pen</I> that can draw line, rectangles
|
||||
or free hand. These modes are available from the toolbar. The User's pen
|
||||
width and color can be modified using the User Pen menu or the toolbar.<BR>
|
||||
</P>
|
||||
|
||||
<P>Color buttons are provided on the toolbar to give a known RGB color
|
||||
to the user pen. It is useful when the user draw an object on the board
|
||||
and wants a turtle to see this object. The colors are: </P>
|
||||
|
||||
<P>White - (255 255 255) </P>
|
||||
|
||||
<P>Black - (0 0 0) </P>
|
||||
|
||||
<P><FONT COLOR="#0000FF">Blue</FONT> - (0 0 255) </P>
|
||||
|
||||
<P><FONT COLOR="#FF0000">Red</FONT> - (255 0 0) </P>
|
||||
|
||||
<P><FONT COLOR="#00FF00">Green</FONT> - (0 255 0) </P>
|
||||
|
||||
<P><FONT COLOR="#FFFF00">Yellow</FONT> - (255 255 0)<BR>
|
||||
</P>
|
||||
|
||||
<P>Another option available is changing a turtle's heading and position,
|
||||
using the Move Turtle button: </P>
|
||||
|
||||
<CENTER><P><IMG border=0 SRC="img00010.gif" HEIGHT=33 WIDTH=37><BR>
|
||||
</P></CENTER>
|
||||
|
||||
<P>If this button is pressed then a turtle can be dragged to a new location
|
||||
simply by dragging it with the mouse. In order to change the turtle's heading,
|
||||
hold down a control key and move the move towards the desired location,
|
||||
the turtle will follow the movement of the mouse. </P>
|
||||
|
||||
<P>
|
||||
<HR width=80% align=left color=blue>
|
||||
<CENTER>
|
||||
<A href="#top"><IMG border=0 src=back.gif ALT=" [TOP] "></A>
|
||||
<A href="extensions.html"><IMG border=0 src=prev.gif ALT=" [PREV] "></A>
|
||||
<A href="implementation.html"><IMG border=0 src=next.gif ALT=" [PREV] "></A>
|
||||
<A href="index.html#toc"><IMG border=0 src=toc.gif ALT=" [PREV] "></A>
|
||||
</CENTER>
|
||||
</BODY>
|
||||
</HTML>
|
||||
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,393 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
||||
<HTML>
|
||||
<HEAD>
|
||||
<TITLE>Galapagos - Implementation</TITLE>
|
||||
<META NAME="Author" CONTENT="">
|
||||
<META NAME="GENERATOR" CONTENT="Mozilla/3.01Gold (Win95; I) [Netscape]">
|
||||
</HEAD>
|
||||
<BODY background=stone.jpg>
|
||||
|
||||
<CENTER>
|
||||
<A href="gui.html"><IMG border=0 src=prev.gif ALT=" [PREV] "></A>
|
||||
<A href="manual.html"><IMG border=0 src=next.gif ALT=" [PREV] "></A>
|
||||
<A href="index.html#toc"><IMG border=0 src=toc.gif ALT=" [PREV] "></A>
|
||||
</CENTER>
|
||||
<HR width=80% align=right color=blue>
|
||||
<P>
|
||||
|
||||
<H1 ALIGN=CENTER><A NAME="top"></A>IMPLEMENTATION</H1>
|
||||
|
||||
<UL>
|
||||
<LI><A HREF="implementation.html#GARBAGE">Garbage Collection</A></LI>
|
||||
<LI><A HREF="implementation.html#BOARDS">Boards</A></LI>
|
||||
<LI><A HREF="implementation.html#TURTLES">Turtles</A></LI>
|
||||
<LI><A HREF="implementation.html#VISION">Vision</A></LI>
|
||||
<LI><A HREF="implementation.html#INTERRUPTS">Interrupts</A></LI>
|
||||
<LI><A HREF="implementation.html#CLASS">Class Organization</A></LI>
|
||||
</UL>
|
||||
|
||||
<HR>
|
||||
<P>Galapagos was written using Microsoft Visual C++, and is designed to
|
||||
run under Windows 95. We chose Windows 95 because it seems to have the
|
||||
largest potential Galapagos users base. The following sections describe
|
||||
some implementation details of Galapagos.<BR>
|
||||
</P>
|
||||
|
||||
<P>The SCM interpreter we used as a base is written in C. Most of the original
|
||||
code we added was written in C++. The parts we used from SCM are almost
|
||||
identical to the original. In fact, by changing the scmconfig.h file (which
|
||||
contain machine-specific configuration) and #defining THREAD to be null,
|
||||
the C files should become equivalent to the sources we used.<BR>
|
||||
</P>
|
||||
|
||||
<P>We have implemented two MT-safe FIFO message queue classes. Both will
|
||||
block when trying to read from an empty queue. <B>CMsgQx</B>, the extended
|
||||
message queue, supports the same interface as the one provided in Scheme,
|
||||
plus an additional support for "Urgent Messages". These take
|
||||
precedence over all other messages. <B>CMessageQueue</B> is message queue
|
||||
with exactly the same interface as the Scheme level message queues, but
|
||||
which contain internal logic to handle "Urgent" messages used
|
||||
to deal with cases where synchronous respond is needed, such as I/O, Garbage
|
||||
collection, and Scheme-level inter-thread communications. <BR>
|
||||
</P>
|
||||
|
||||
<H2><A NAME="FITTING SCM INTO"></A>FITTING SCM INTO WINDOWS<BR>
|
||||
</H2>
|
||||
|
||||
<P>Galapagos is based on SCM, which is a single-thread, read-evaluate-print-loop
|
||||
(repl) based Scheme interpreter. The most important issue in migrating
|
||||
SCM was how to maintain the interpreter's natural repl-based approach,
|
||||
yet allow for multiple threads to interact, and for Windows messages to
|
||||
be processed quickly.<BR>
|
||||
</P>
|
||||
|
||||
<P>We used WIN32's multithreading capabilities to solve these problems.
|
||||
A single thread handles all aspects of the GUI - in a sense, "all
|
||||
that is Windows": graphic boards, turtles, consoles, menus and so
|
||||
on. Each interpreter runs in a thread of its own, interacting with the
|
||||
GUI using a message queue similar to the one provided at the Scheme level.<BR>
|
||||
</P>
|
||||
|
||||
<CENTER><P><IMG border=0 SRC="img00011.gif" HEIGHT=182 WIDTH=530><BR>
|
||||
</P></CENTER>
|
||||
|
||||
<P>The GUI thread manages both commands received from the OS and from the
|
||||
different interpreters running on their own threads. To ensure as fast
|
||||
responses as possible, priorities are used: OS messages (such as windows
|
||||
updates and input devices) gets highest priority; Console (text messages)
|
||||
come second, and graphics messages are last. This allows the interpreters
|
||||
to run interactively in a satisfactory manner. <BR>
|
||||
</P>
|
||||
|
||||
<P>SCM interpreter threads each run in the old-fashion repl mode. When
|
||||
a computation is over, the interpreter blocks until new input comes from
|
||||
the GUI thread. All blocking functions were modified to allow synchronous
|
||||
messages (such as the one generated by <B>tell-thread</B>) to work. In
|
||||
addition, SCM's "poll routine" is used to force checking for
|
||||
such messages even during computations.<BR>
|
||||
</P>
|
||||
|
||||
<P>An additional thread is used for Garbage Collection. It is described
|
||||
in detail in the section dealing with garbage collection.<BR>
|
||||
</P>
|
||||
|
||||
<H2><A NAME="GARBAGE"></A>GARBAGE COLLECTION</H2>
|
||||
|
||||
<P>In this section we will briefly describe SCM's garbage collector, and
|
||||
then discuss the modifications done to adapt it to Galapagos's multithreading
|
||||
computations. It should be noted that the garbage collector used is a portable
|
||||
garbage collector taken from "SCHEME IN ONE DEFUN, BUT IN C THIS TIME",
|
||||
by George J Carrette <gjc@world.std.com>. <BR>
|
||||
</P>
|
||||
|
||||
<P>SCM uses a conservative Mark & Sweep garbage collector (GC). All
|
||||
Scheme data objects share some common configuration (called "cells"):
|
||||
They are 8-byte aligned; they reside is specially-allocated memory segments
|
||||
(called hplims); they are the size of two pointers (so a scheme cons is
|
||||
exactly a cell); and they contain a special GC bit used by the garbage
|
||||
collector. This bit is 0 during actual computations. When a new cell is
|
||||
needed and all the hplims are used, garbage collection is initiated. If
|
||||
it does not free enough space to pass a certain threshold, a new hplim
|
||||
is allocated.<BR>
|
||||
</P>
|
||||
|
||||
<P>The first stage in garbage collection is marking all cells which are
|
||||
not to be deleted. Some terminology might be helpful here: <BR>
|
||||
</P>
|
||||
|
||||
<UL>
|
||||
<LI>A cell (or any data object) is called <B><I>alive</I></B> if it may
|
||||
in some way influence the future of the computation. Needless to say, discovering
|
||||
which cells are alive and which are not is impossible, because of the very
|
||||
nature of the future. </LI>
|
||||
</UL>
|
||||
|
||||
<UL>
|
||||
<LI>A cell is called <B><I>reachable</I></B> if the computation can read
|
||||
its value. Some data is <I>immediately reachable</I>: The data on the machine's
|
||||
stack or in the CPU registers, for example; some interpreters store some
|
||||
information in a fixed location so it's permanently reachable. In SCM the
|
||||
array <TT><FONT FACE="Courier New">sys_protects[]</FONT></TT> is used for
|
||||
this propose. The set of reachable cells is the union of all immediately
|
||||
reachable cells, and all those cells pointed by reachable cells, recursively.
|
||||
</LI>
|
||||
</UL>
|
||||
|
||||
<P>Obviously, all unreachable data is dead. Conservative garbage collectors
|
||||
treat all reachable data as alive. <BR>
|
||||
</P>
|
||||
|
||||
<P>The Mark stage of the garbage collector scans the <TT><FONT FACE="Courier New">sys_protects[]</FONT></TT>
|
||||
array and the machine's stack and registers for anything that looks like
|
||||
a valid cell. All cell pointer have their 3 least significant bits zero,
|
||||
and are in one of few known ranges (the hplims). The garbage collector
|
||||
searches for anything matching a cell's bit pattern, and treats it as an
|
||||
immediately reachable cell pointer. In some cases, this may mean an integer,
|
||||
for example, happens to match the binary pattern and thus be interpreted
|
||||
as a cell pointer. However, this will only mean some cell or cells are
|
||||
marked as reachable though they are not such. Because of the uniform structure
|
||||
of the cell and its limited range of possible locations, such an accident
|
||||
is guarantied not to corrupt memory. Furthermore, if we accept the assumption
|
||||
that integers are usually relatively small, and memory addresses are relatively
|
||||
big, we conclude that such accidents are not very likely to happen often
|
||||
anyway.<BR>
|
||||
</P>
|
||||
|
||||
<P>During mark stage, the garbage collector recursively finds (a superset
|
||||
of) all live cells, and marks them by setting their special GC bit to 1.
|
||||
The second stage is the Sweep stage, in which all the hplims are scanned
|
||||
linearly, and every cell which is not marked is recognized as dead, and
|
||||
as such is reclaimed as free. Marked cells get unmarked so they are ready
|
||||
for the next garbage collection. <BR>
|
||||
</P>
|
||||
|
||||
<P>Mark & Sweep garbage collection has two main disadvantages: One,
|
||||
that it requires all computation to stop while garbage collection is in
|
||||
progress. In Galapagos, since all threads use a shared memory heap, it
|
||||
means all threads must synchronize and halt while garbage is collected.
|
||||
Second, Mark & Sweep is very likely to cause memory fragmentation.
|
||||
However, since cells are equally sized, fragmentation is only rarely a
|
||||
problem.<BR>
|
||||
</P>
|
||||
|
||||
<P>We chose to stick with Mark & Sweep in Galapagos because of its
|
||||
two major advantages: Simplicity and efficiency. Mark & Sweep GC does
|
||||
not affect computation speed, because direct pointers are used. Most concurrent
|
||||
garbage collectors work by making all pointers indirect, which may slow
|
||||
computations down considerably. The need to halt all threads for GC is
|
||||
accepted. Since memory is shared, it would only be fair to stop all threads
|
||||
when GC is needed: Threads will probably halt anyway since cells are allocated
|
||||
continuously during computations.<BR>
|
||||
</P>
|
||||
|
||||
<P>Two major issues are introduced when trying to multithread the garbage
|
||||
collector. One is the synchronization of the different threads, which run
|
||||
almost completely unaware one of the other; the second is the need to mark
|
||||
data from every thread's specific stack, registers, and <TT><FONT FACE="Courier New">sys_protects[]</FONT></TT>.
|
||||
We solved these two issues by combining them to one.<BR>
|
||||
</P>
|
||||
|
||||
<P>The intuitive approach might be to let each thread mark its own information,
|
||||
and then sweep centrally. However, since synchronization of threads is
|
||||
mandatory, letting every thread mark its own data will lead only to redundant
|
||||
marking and to excessive context switches, since each threads has to become
|
||||
active. Therefore we created the "<B>Garbage Collection daemon</B>"
|
||||
(GCd), which runs in a distinct thread and lasts for the whole Galapagos
|
||||
session. The GCd is not an interpreter, but a mechanism which keeps track
|
||||
of live threads and their need of GC. The GCd thread is always blocked,
|
||||
except when a thread notifies it on its birth or death, or when a thread
|
||||
indicates the need for garbage collection. Since the GC daemon is blocked
|
||||
whenever it is not needed, and then becomes the exclusive running thread
|
||||
during actual GC (with the exception of the GUI thread), its existence
|
||||
does not hurt performance. <BR>
|
||||
</P>
|
||||
|
||||
<P>To explain how the GCd synchronizes all threads, let us examine the
|
||||
three-way protocol involved. <TT><FONT FACE="Courier New">freelist</FONT></TT>
|
||||
is a global pointer which holds a linked list of free cells - it can be
|
||||
either a cell pointer, a value indicating "busy" (thus implementing
|
||||
busy/wait protection over it) or "end of memory" which is found
|
||||
at the end of the linked list. MIB stands for <B><I>Memory Information
|
||||
Block</I></B>, which is a block of memory containing all of a thread's
|
||||
immediately reachable data.<BR>
|
||||
</P>
|
||||
|
||||
<P><B><U>GCd scenario:</U></B> GCd is blocked until a threads sends a GC
|
||||
request. </P>
|
||||
|
||||
<OL>
|
||||
<LI>GCd scans through its list of active threads, and sends each a <I>MIB
|
||||
request</I>. </LI>
|
||||
|
||||
<LI>It then blocks until all MIB blocks are received. GCd ignores further
|
||||
GC request messages it get. </LI>
|
||||
|
||||
<LI>At this point all threads are blocked. The GCd has gained, therefore,
|
||||
exclusive access to the hplims. The GCd now marks all reachable cells,
|
||||
inspecting each MIB block for immediately reachable cells and proceeding
|
||||
recursively. Then, it sweeps. </LI>
|
||||
|
||||
<LI>If needed, the GCd allocated a fresh hplim. </LI>
|
||||
|
||||
<LI>GCd sends every thread a message allowing it to resume. Then it blocks
|
||||
waiting for the next time. </LI>
|
||||
</OL>
|
||||
|
||||
<P><B><U>Scenario 1:</U></B> A thread needs to allocate a cell but can't.
|
||||
</P>
|
||||
|
||||
<OL>
|
||||
<LI>The thread sends GCd a<I> GC request message.</I> </LI>
|
||||
|
||||
<LI>Then it suspends until GCd sends it an <I>MIB request</I>. </LI>
|
||||
|
||||
<LI>When one arrives, the thread generates and sends a MIB block to the
|
||||
GCd. </LI>
|
||||
|
||||
<LI>And blocks again until GCd notifies it that GC is done. </LI>
|
||||
|
||||
<LI>At this point free cells are available and the computation can resume.
|
||||
</LI>
|
||||
</OL>
|
||||
|
||||
<P><B><U>Scenario 2:</U></B> A thread receives a<I> MIB request</I>. This
|
||||
may happen within a computation or when considered otherwise blocked -
|
||||
waiting for input, for example. </P>
|
||||
|
||||
<OL>
|
||||
<LI>The thread generates and sends a MIB block to the GCd. </LI>
|
||||
|
||||
<LI>And blocks until GCd notifies it that GC is done. </LI>
|
||||
</OL>
|
||||
|
||||
<P>The important thing to note about this protocol is its indifference
|
||||
to the GC "initiator". Several threads can "initiate"
|
||||
GC, and each request is "satisfied", although of course only
|
||||
one GC takes place. The GCd itself is unaware of the initiating thread
|
||||
identity, and completely ignores any further GC requests. It treats all
|
||||
threads identically. This is important because it allows each thread meeting
|
||||
a low memory condition to initiate GC immediately. This is in fact the
|
||||
mechanism which saves us from explicitly checking for a third-party GC
|
||||
request during computation: If a thread runs out of memory, the <TT><FONT FACE="Courier New">freelist</FONT></TT>
|
||||
variable is kept at "out of memory" state, causing any other
|
||||
thread trying to allocate memory to initiate GC as well. This simplifies
|
||||
the GC protocol (technically, if not conceptually), and does it with almost
|
||||
no affect on computation speed.<BR>
|
||||
</P>
|
||||
|
||||
<H2><A NAME="BOARDS"></A>BOARDS<BR>
|
||||
</H2>
|
||||
|
||||
<P>A board or a view as it called in MFC is the environment where a turtle
|
||||
moves and interact with. It hold two main data structures. The first is
|
||||
the bitmap of the drawing. It is a 800X600 bitmap. Every time a turtle
|
||||
draws on the board it makes its pen the active pen on the board and draws
|
||||
on it. Every time the picture needs refreshing (as signaled by the operating
|
||||
system) it is the board's duty to copy the relevant section from the bitmap
|
||||
to the screen. The second data object is the turtles list, an expandable
|
||||
array of turtles which holds pointers to all turtles on the specific board.<BR>
|
||||
</P>
|
||||
|
||||
<P>The most important part in the board's work is to notify the turtles
|
||||
on any event that happened on the board such as drawing, changing background
|
||||
or moving of a turtle. If for example a user draws a line on the board,
|
||||
the board (after drawing the line) goes through the turtles list and tell
|
||||
each one that some event happened at a rectangle that contains the line.
|
||||
Each turtle will decide if this has any importance to it or not.<BR>
|
||||
</P>
|
||||
|
||||
<P>Apart from that, the board handles all the user interface from the menus
|
||||
and the toolbar. The most obvious example is the move turtle button, which,
|
||||
when pressed, causes the board to find a turtle close enough to the click's
|
||||
location. Then, on every movement of the mouse it gives the turtle a command
|
||||
to move to this point. <BR>
|
||||
</P>
|
||||
|
||||
<P>In order to support scrolling of the picture, we derived the <B>CBoardView</B>
|
||||
class from <B>CScrollView</B>. The interface with the interpreter threads
|
||||
is done via a message queue. The main function is <TT><FONT FACE="Courier New">ReadAndEval,</FONT></TT>
|
||||
which gets a message and then interprets its and act upon the result.<BR>
|
||||
</P>
|
||||
|
||||
<H2><A NAME="TURTLES"></A>TURTLES<BR>
|
||||
</H2>
|
||||
|
||||
<P>In addition to a pointer to its current board, and to inner-state variable
|
||||
which affects its graphical aspects, every turtle holds an expandable array
|
||||
of interrupts. When a turtle gets from the window that a message signifying
|
||||
that some change has happened, it sends this change to each of its interrupts
|
||||
(only if the interrupt flag is on) and the interrupt is responsible to
|
||||
send an appropriate message if necessary. The turtle's location are stored
|
||||
as floating points on x,y axes, to allow for accuracy on the turtle's location
|
||||
and heading.<BR>
|
||||
</P>
|
||||
|
||||
<P>The turtles interacts with the interpreter thread using a message queue.
|
||||
As with the board, the main function here is the <TT><FONT FACE="Courier New">ReadAndEval,</FONT></TT>
|
||||
which translates these messages to valid function calls.<BR>
|
||||
</P>
|
||||
|
||||
<H2><A NAME="VISION"></A>VISION<BR>
|
||||
</H2>
|
||||
|
||||
<P>Every turtle holds a pointer to the bitmap it is drawing on. When it
|
||||
is "looking" for a color it calculates the minimal rectangle
|
||||
that holds the desired area. Then it iterates on all the pixels in this
|
||||
rectangle. First it checks if the pixel is in the vision area using the
|
||||
sign rule to determine if a point is clockwise or anti clockwise from a
|
||||
line, and then check for distance. If the point is in the relevant area
|
||||
the turtle gets its color from the bitmap and compares it with the sought
|
||||
color. <BR>
|
||||
</P>
|
||||
|
||||
<P>When looking for a specific turtle, the turtle gets this turtle's position
|
||||
and calculates if this location is in the relevant area using the same
|
||||
algorithm. When looking for any turtle, the turtle passes the relevant
|
||||
arguments to the view, which then uses the same algorithm for each turtle
|
||||
on its turtles array.<BR>
|
||||
</P>
|
||||
|
||||
<H2><A NAME="INTERRUPTS"></A>INTERRUPTS<BR>
|
||||
</H2>
|
||||
|
||||
<P>Each turtle holds an expandable array of interrupts. Each interrupts
|
||||
is an object that is much like a turtle vision. The interrupts has the
|
||||
view area argument and what it is looking for. It also has the message
|
||||
it needs to send and a pointer to the given queue. When the turtle notifies
|
||||
the interrupt that a change has happened, the interrupt first checks if
|
||||
the change is an area which is of interest to it. If so it calls the turtle
|
||||
look function with its location and the sought object. According to the
|
||||
turtle's answer and to the data stored inside the interrupt, the interrupt
|
||||
sends the needed message, if any.<BR>
|
||||
<BR>
|
||||
</P>
|
||||
|
||||
<H2><A NAME="CLASS"></A>CLASS ORGANIZATION<BR>
|
||||
</H2>
|
||||
|
||||
<P><CENTER><IMG border=0 SRC="img00012.gif" HEIGHT=626 WIDTH=693><BR>
|
||||
</CENTER>
|
||||
</P>
|
||||
|
||||
<P>Message-passing mechanisms:<BR>
|
||||
</P>
|
||||
|
||||
<P>
|
||||
<CENTER><IMG border=0 SRC="img00013.gif" HEIGHT=198 WIDTH=694> </CENTER></P>
|
||||
<FONT SIZE=+3></FONT>
|
||||
|
||||
|
||||
<P>
|
||||
<HR width=80% align=left color=blue>
|
||||
<CENTER>
|
||||
<A href="#top"><IMG border=0 src=back.gif ALT=" [TOP] "></A>
|
||||
<A href="gui.html"><IMG border=0 src=prev.gif ALT=" [PREV] "></A>
|
||||
<A href="manual.html"><IMG border=0 src=next.gif ALT=" [PREV] "></A>
|
||||
<A href="index.html#toc"><IMG border=0 src=toc.gif ALT=" [PREV] "></A>
|
||||
</CENTER>
|
||||
</BODY>
|
||||
</HTML>
|
||||
|
||||
|
||||
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
|
|
@ -0,0 +1,95 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
||||
<HTML>
|
||||
<HEAD>
|
||||
<TITLE>Galapagos</TITLE>
|
||||
</HEAD>
|
||||
<BODY background=stone.jpg>
|
||||
|
||||
<CENTER><P><B><FONT COLOR="#008040" SIZE=+4>Welcome to<BR>
|
||||
<IMG border=0 SRC=gps.gif alt="GALAPAGOS"></FONT></B></P></CENTER>
|
||||
|
||||
Galapagos is an interactive multithreaded Scheme interpreter with turtle
|
||||
graphics for Windows 95. It is built around the SCM interpreter, and it
|
||||
provides multiple interpreters, threads, turtles, and drawing boards, all
|
||||
running concurrently using WIN32's multithreading abilities, and freely
|
||||
<A href="#download">available</A>.
|
||||
|
||||
<P>
|
||||
<HR>
|
||||
<P>
|
||||
<Center>
|
||||
<A href="http://www.cs.bgu.ac.il"><IMG border=0 src="bgu_logo_tiny.gif" alt=""></A><BR><BR>
|
||||
Spring 1997<BR><BR>
|
||||
Graduation project<BR><BR>
|
||||
<A href="http://www.cs.bgu.ac.il">Department of Math & Computer Science,</A><BR><BR>
|
||||
<A href="http://www.bgu.ac.il">Ben-Gurion University of the Negev</A><BR><BR>
|
||||
<BR>
|
||||
Written by <A href="http://www.cs.bgu.ac.il/~elad">Elad Eyal</A> and <A href="http://www.cs.bgu.ac.il/~tebeka">Miki
|
||||
Tebeka</A>.<BR>
|
||||
<BR>
|
||||
Supervisor: <A href="http://www.cs.bgu.ac.il/~elhadad">Dr. Michael Elhadad</A>
|
||||
</CENTER>
|
||||
<P>
|
||||
<P>
|
||||
<HR width=100%>
|
||||
<P>
|
||||
<A name="toc">
|
||||
<CENTER><P><B><FONT SIZE=+3>TABLE OF CONTENTS </FONT></B></P></CENTER>
|
||||
|
||||
<UL>
|
||||
<LI><A HREF="background.html">Background </A></LI>
|
||||
<UL>
|
||||
<LI><A HREF="background.html#SCHEME">SCHEME</A></LI>
|
||||
<LI><A HREF="background.html#LOGO AND TURTLE">LOGO and Turtle Geometry</A></LI>
|
||||
<LI><A HREF="background.html#OBJECTIVES">Objectives</A></LI>
|
||||
<LI><A HREF="background.html#AVAILABILITY">Avaliability</A></LI>
|
||||
</UL>
|
||||
<LI><A HREF="extensions.html">SCHEME extensions</A></LI>
|
||||
<UL>
|
||||
<LI><A HREF="extensions.html#THE NEW ENVIRONMENT">The New Environment Model</A></LI>
|
||||
<LI><A HREF="extensions.html#THREADS">Threads</A></LI>
|
||||
<LI><A HREF="extensions.html#CONSOLES">Consoles</A></LI>
|
||||
<LI><A HREF="extensions.html#DRAWING">Drawing Boards</A></LI>
|
||||
<LI><A HREF="extensions.html#TURTLES">Turtles</A></LI>
|
||||
<LI><A HREF="extensions.html#INTERRUPTS (NOTIFICATIONS) AND MESSAGE">Interrupts (Notifications) and Message handlers</A></LI>
|
||||
</UL>
|
||||
<LI><A HREF="gui.html">The interactive GUI</A></LI>
|
||||
<LI><A HREF="implementation.html">Implementation</A></LI>
|
||||
<UL>
|
||||
<LI><A HREF="implementation.html#FITTING SCM INTO">Fitting SCM into Windows</A></LI>
|
||||
<LI><A HREF="implementation.html#GARBAGE">Garbage Collection</A></LI>
|
||||
<LI><A HREF="implementation.html#BOARDS">Boards</A></LI>
|
||||
<LI><A HREF="implementation.html#TURTLES">Turtles</A></LI>
|
||||
<LI><A HREF="implementation.html#VISION">Vision</A></LI>
|
||||
<LI><A HREF="implementation.html#INTERRUPTS">Interrupts</A></LI>
|
||||
<LI><A HREF="implementation.html#CLASS">Class Organization</A></LI>
|
||||
</UL>
|
||||
<LI><A HREF="manual.html">Programer's Manual</A></LI>
|
||||
<UL>
|
||||
<LI><A HREF="manual.html#ENVIRONMENTS">Environments</A></LI>
|
||||
<LI><A HREF="manual.html#MESSAGE">Message Queues</A></LI>
|
||||
<LI><A HREF="manual.html#WINDOW">Window Commands</A></LI>
|
||||
<LI><A HREF="manual.html#TURTLE">Turtle Commands</A></LI>
|
||||
<LI><A HREF="manual.html#VISION">Vision</A></LI>
|
||||
<LI><A HREF="manual.html#INTERRUPTS">Interrupts (Notifications)</A></LI>
|
||||
<LI><A HREF="manual.html#THREADS">Threads</A></LI>
|
||||
</UL>
|
||||
<LI><A HREF="bib.html">Bibiliography and Links</A></LI>
|
||||
</UL>
|
||||
|
||||
<P>
|
||||
|
||||
<BR>
|
||||
<A name="download">
|
||||
<CENTER><P><B><FONT SIZE=+3>DOWNLOAD CENTER</FONT></B></P></CENTER>
|
||||
<P>
|
||||
<CENTER><FONT size=-1><TT>GNU LICENSE. COPYRIGHTED. PROVIDED "AS IS". NO
|
||||
WARRANTIES OR LIABILITIES. ETC.</TT></CENTER>
|
||||
<P>
|
||||
<P>
|
||||
500K <A href="gps10bin.zip"><TT>gps10bin.zip</TT></A> - Executable and required Scheme libraries (SLIB)<BR>
|
||||
700K <A href="gps10src.zip"><TT>gps10src.zip</TT></A> - Same with all source code <BR>
|
||||
400K <A href="mfc40dll.zip"><TT>mfc40dll.zip</TT></A> - You might need this MFC40.DLL if you
|
||||
don't have it already. <BR>
|
||||
</BODY>
|
||||
</HTML>
|
||||
|
|
@ -0,0 +1,493 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
||||
<HTML>
|
||||
<HEAD>
|
||||
<TITLE>Galapagos - Scheme Extensions</TITLE>
|
||||
<META NAME="Author" CONTENT="">
|
||||
<META NAME="GENERATOR" CONTENT="Mozilla/3.01Gold (Win95; I) [Netscape]">
|
||||
</HEAD>
|
||||
<BODY background=stone.jpg>
|
||||
|
||||
<CENTER>
|
||||
<A href="background.html"><IMG border=0 src=prev.gif ALT=" [PREV] "></A>
|
||||
<A href="gui.html"><IMG border=0 src=next.gif ALT=" [PREV] "></A>
|
||||
<A href="index.html#toc"><IMG border=0 src=toc.gif ALT=" [PREV] "></A>
|
||||
</CENTER>
|
||||
<HR width=80% align=right color=blue>
|
||||
<P>
|
||||
|
||||
<H1 ALIGN=CENTER><A NAME="top"></A>SCHEME EXTENSIONS<BR>
|
||||
</H1>
|
||||
|
||||
<UL>
|
||||
<LI><A HREF="extensions.html#THE NEW ENVIRONMENT">The New Environment Model</A></LI>
|
||||
<LI><A HREF="extensions.html#THREADS">Threads</A></LI>
|
||||
<LI><A HREF="extensions.html#CONSOLES">Consoles</A></LI>
|
||||
<LI><A HREF="extensions.html#DRAWING">Drawing Boards</A></LI>
|
||||
<LI><A HREF="extensions.html#TURTLES">Turtles</A></LI>
|
||||
<LI><A HREF="extensions.html#INTERRUPTS (NOTIFICATIONS) AND MESSAGE">Interrupts
|
||||
(Notifications) and Message handlers</A></LI>
|
||||
</UL>
|
||||
|
||||
<P>
|
||||
<HR WIDTH="100%"></P>
|
||||
|
||||
<P>We have extended Scheme in two main
|
||||
directions: Turtle graphics and multithreading:<BR>
|
||||
</P>
|
||||
|
||||
<P>The <I>turtle</I> object lives on a board on which it can move and draw.
|
||||
A turtle can also communicate with the board and "see" colors
|
||||
or other turtles. Galapagos Scheme provides a set of primitives to create
|
||||
and manage such turtles and the boards they live on. <BR>
|
||||
</P>
|
||||
|
||||
<P>A set of additional primitives enable the programmer to create multiple
|
||||
interpreters that run concurrently. The environment model was extended
|
||||
to support shared or thread-specific environments, and primitives to handle
|
||||
multiple environments were also added. <BR>
|
||||
<BR>
|
||||
</P>
|
||||
|
||||
<H2><A NAME="THE NEW ENVIRONMENT"></A>THE NEW ENVIRONMENT MODEL<BR>
|
||||
</H2>
|
||||
|
||||
<P>A frame is a table which maps (or <I>binds</I>) names to values. An
|
||||
environment is a chained list of frames in which the interpreter works.
|
||||
</P>
|
||||
|
||||
<P>For example the command: </P>
|
||||
|
||||
<P><I>(define x 7)</I> </P>
|
||||
|
||||
<P>creates a binding between <I>x</I> and the value <I>7</I>. </P>
|
||||
|
||||
<P>A typical environment looks like this:</P>
|
||||
|
||||
<P><CENTER>
|
||||
<IMG border=0 SRC="Envs.gif" HEIGHT=125 WIDTH=459><BR>
|
||||
</CENTER></P>
|
||||
<BR>
|
||||
<BR>
|
||||
<BR>
|
||||
Each rectangle denotes a frame and inside it are the bindings it holds.
|
||||
The rightmost rectangle is the global environment.<BR>
|
||||
</P>
|
||||
|
||||
<P>When a variable is evaluated, the interpreter first tries to find it
|
||||
in the current frame. If a suitable binding can't be found, the interpreter
|
||||
moves to the next frame in the environment and searched for a binding there.<BR>
|
||||
</P>
|
||||
|
||||
<P>In our example if we write <I>x</I> in the command line we'll get <I>12</I>
|
||||
as the answer because all such computations take place at the global environment.
|
||||
<BR>
|
||||
</P>
|
||||
|
||||
<P>A function application is always evaluated with respect to the environment
|
||||
the in which it was defined. (A function "holds" its environment,
|
||||
hence the name "closure") This means that if we write </P>
|
||||
|
||||
<P><I>(define (f) x) </I></P>
|
||||
|
||||
<P>and then </P>
|
||||
|
||||
<P><I>(f)</I> </P>
|
||||
|
||||
<P>the result will be </P>
|
||||
|
||||
<P><I>12</I>.<BR>
|
||||
<BR>
|
||||
<BR>
|
||||
<BR>
|
||||
<BR>
|
||||
<P><CENTER>
|
||||
<IMG border=0 SRC="Envs2.gif" HEIGHT=140 WIDTH=551><BR>
|
||||
</CENTER></P>
|
||||
<BR>
|
||||
In traditional SCHEME we have only one interpreter running at a time, so
|
||||
at a given point of calculation there is only one environment. In Galapagos
|
||||
multiple interpreters can run at the same time, and each of them has its
|
||||
own environment.<BR>
|
||||
</P>
|
||||
|
||||
<P>Under Galapagos's environment model, every interpreter works on its
|
||||
branch of an "environments tree", but can also evaluate an expression
|
||||
in any other environment in the tree. If two interpreters have a shared
|
||||
node on the tree, then from that point up (towards the global environment)
|
||||
all the bindings are the same for the two interpreters. The global environment
|
||||
is shared by all interpreters. If an interpreter changes the value of some
|
||||
variable, the binding is changed in all other interpreters that have access
|
||||
to the frame where the variable was declared. Obviously, caution should
|
||||
be taken when writing to a shared variable.<BR>
|
||||
</P>
|
||||
|
||||
<P>As an example, if a user created two new threads, called A and B, and
|
||||
then evaluated: </P>
|
||||
|
||||
<P><TT><FONT FACE="Courier New">First thread></FONT></TT> <I>(define
|
||||
x 7)</I> </P>
|
||||
|
||||
<P><I>(define (f) ...)</I> </P>
|
||||
|
||||
<P><TT><FONT FACE="Courier New">Thread A></FONT></TT> <I>(define (g)
|
||||
x)</I> </P>
|
||||
|
||||
<P><TT><FONT FACE="Courier New">Thread B></FONT></TT> <I>(define x 4)</I>
|
||||
</P>
|
||||
|
||||
<P>this is how the environment model would look like:<BR>
|
||||
</P>
|
||||
|
||||
<CENTER><P><IMG border=0 SRC="img00001.gif" HEIGHT=407 WIDTH=654><BR>
|
||||
</P></CENTER>
|
||||
|
||||
<P>Now consider what happens when the user evaluates this: </P>
|
||||
|
||||
<P><TT><FONT FACE="Courier New">Thread A></FONT></TT> <I>(set! f g)</I>
|
||||
</P>
|
||||
|
||||
<CENTER><P><IMG border=0 SRC="img00002.gif" HEIGHT=431 WIDTH=692><BR>
|
||||
<BR>
|
||||
</P></CENTER>
|
||||
|
||||
<P>Now, evaluating <I>(f)</I> in thread B will call the function defined
|
||||
in thread A. It will return 12 which is the value of x in f's environment.
|
||||
If thread A defines a new x (using <B>define</B>), it will affect the result
|
||||
of subsequent calls to f.<BR>
|
||||
</P>
|
||||
|
||||
<P>Sharing environments and frames are Galapagos's way of allowing shared
|
||||
data. By default, however, most calculations are done at thread-specific
|
||||
frames. (More on this subject in the next section). Primitives are supplied
|
||||
to explicitly reference and manage environments: <B>clone-environment</B>
|
||||
can create a copy of an environment (so changing a binding in one copy
|
||||
does not alter the other); <B>extend-environment</B> and <B>pop-environment</B>
|
||||
can add and remove frames to and from environments. More environment functions
|
||||
are found in the next section of this document.<BR>
|
||||
</P>
|
||||
|
||||
<H2><A NAME="THREADS"></A>THREADS<BR>
|
||||
</H2>
|
||||
|
||||
<P>A thread is a SCHEME interpreter. The <I>base environment</I> of a thread
|
||||
is the thread's topmost environment. All forms entered at the thread's
|
||||
console or as arguments to <B>new-thread</B> are evaluated in the base
|
||||
environment. In traditional SCHEME there is only one thread of execution.
|
||||
It is a single thread and its base environment is the global environment.
|
||||
In Galapagos many interpreters can run concurrently, and each have its
|
||||
own environment (changing dynamically as computation progresses) and a
|
||||
base environment (which can be explicitly changed).<BR>
|
||||
</P>
|
||||
|
||||
<P>One thread is created by Galapagos upon startup. It is called the <I>main
|
||||
thread</I>, and it lasts for the whole Galapagos session. Its base environment
|
||||
is the global one - much like a traditional Scheme interpreter. Additional
|
||||
threads can be created using <B>new-thread</B>. These have their base environment
|
||||
set to a new environment, containing a single fresh frame pointing to the
|
||||
global environment. Any calculation done at the new thread's console takes
|
||||
place in this thread-local environment. However, if closure functions are
|
||||
used, then their evaluation may take place at the global environment or
|
||||
at some other thread's space, depending on where that function was defined.
|
||||
<BR>
|
||||
</P>
|
||||
|
||||
<P>When a thread finishes the execution of its commands it terminates.
|
||||
There are two exceptions to this rule: </P>
|
||||
|
||||
<OL>
|
||||
<LI>The main thread can be only terminated by using <B>quit-program</B>.
|
||||
</LI>
|
||||
|
||||
<LI>A thread that is bound to the console will not terminate at the end
|
||||
of execution but will wait for the next command input. </LI>
|
||||
</OL>
|
||||
|
||||
<P>Threads can communicate using the predicate <B>tell-thread</B> or by
|
||||
using the asynchronous message-queues system described later. In addition,
|
||||
SCM's <B><I>arbiters</I></B> were improved to be multithread safe. An arbiter
|
||||
object can serve as a guard on a critical section (where only one thread
|
||||
can work at a given time) of the program. The relevant primitves are <B>make-arbiter</B>,<B>
|
||||
try-arbiter</B>, and <B>release-arbiter</B>. <BR>
|
||||
</P>
|
||||
|
||||
<P>Note: Galapagos supports Scheme's notation of <B><I>continuations</I></B>.
|
||||
However, two restrictions apply: </P>
|
||||
|
||||
<OL>
|
||||
<LI>Only "cheap" continuations are supported. That is, a continuation
|
||||
can only be called when it is still active. This allows for continuations
|
||||
to be used to implement exception handling, etc. </LI>
|
||||
|
||||
<LI>Continuations can not cross thread boundaries. Also continuations,
|
||||
like any other Scheme object, can be handled by any thread, they can only
|
||||
be called from within the thread that created them. Trying to call a continuation
|
||||
from a different thread will cause an error. </LI>
|
||||
</OL>
|
||||
|
||||
<H2><A NAME="CONSOLES"></A>CONSOLES<BR>
|
||||
</H2>
|
||||
|
||||
<P>A <I>console</I> is a text window where the user can type commands (when
|
||||
the interpreter is idle) and see output. A console has a name which can
|
||||
be changed dynamically, which appears on its title bar. A thread may or
|
||||
may not be bound to a console. Information printed by a non-bound thread
|
||||
is lost; a non-bound thread waiting for input is stuck (unless provisions
|
||||
were made to allow a new console to be created by means of inter-thread
|
||||
communications.) If a non-bound thread has nothing to do, instead of waiting
|
||||
for input like a bound thread, it will terminate.<BR>
|
||||
</P>
|
||||
|
||||
<P>The main thread is always bound to a console. To bind a thread to a
|
||||
console use the command <B>bind-to-console</B> from within the thread.<BR>
|
||||
</P>
|
||||
|
||||
<H2><A NAME="DRAWING"></A>DRAWING BOARDS<BR>
|
||||
</H2>
|
||||
|
||||
<P>A board (window) is the graphical board on which the turtles and the
|
||||
user draw. It is a bitmap on which the user can draw interactively, by
|
||||
using the supplied GUI, or by creating turtles and instructing them to
|
||||
do the drawings.<BR>
|
||||
</P>
|
||||
|
||||
<P>The controls of the graphical user interface are located on the toolbar.
|
||||
The "shapes" of drawing are either a rectangle, a line or free
|
||||
hand drawing. The user pen can have three widths which are found under
|
||||
the <B>User Pen</B> menu. The numbers next to the sizes are the widths
|
||||
in pixels.<BR>
|
||||
</P>
|
||||
|
||||
<P>The colors of the user pen can be changes either from the <B>User Pen
|
||||
</B>menu or from the toolbar's color buttons. When choosing from a toolbar
|
||||
button, the user can know exactly what color (in RGB format) is used. <BR>
|
||||
</P>
|
||||
|
||||
<P>Each window has a name which is written on its title bar which can be
|
||||
changed using the <B>rename-window!</B> command. The board can be cleaned
|
||||
from all drawings using the <B>clear-window </B>command. <BR>
|
||||
</P>
|
||||
|
||||
<P>Since the board is a bitmap it can be saved to a BMP file using the
|
||||
<B>save-bitmap</B> command. A new background from a bitmap file can be
|
||||
loaded using the <B>load-bitmap</B> command.<BR>
|
||||
</P>
|
||||
|
||||
<H2><A NAME="TURTLES"></A>TURTLES<BR>
|
||||
</H2>
|
||||
|
||||
<P>A turtle is an object which is connected to a certain board. Each turtle
|
||||
has a pen with which it can draw on that board. The user can change the
|
||||
state of the turtle's pen including giving it the color of the board's
|
||||
background color (using the <B>pen-erase! </B>command). The pen will draw
|
||||
when it is "down" and will not draw when it is "up".
|
||||
Turtles can move between boards using the <B>move-turtle-to-window</B>
|
||||
command.<BR>
|
||||
</P>
|
||||
|
||||
<P>Each turtle holds its location as the a pair of coordinates where 0,0
|
||||
is the upper left corner of the board and 800,600 is the bottom-right corner
|
||||
of the board. The turtle's location can be changed by giving the turtle
|
||||
commands such as <B>forward!, backwards!, move-to!</B> or by using the
|
||||
move button from the toolbar.<BR>
|
||||
</P>
|
||||
|
||||
<P>A turtle also has a heading which is the direction it will move on the
|
||||
<B>forward!</B> command. The heading is in degrees, 0 meaning upwards and
|
||||
increasing clockwise, thus 90 means rightwards and so on. A turtle's heading
|
||||
can be changed by commands such as <B>right!, left!, </B>and<B> set-heading!</B>
|
||||
or interactively, by using the move button on the toolbar and pressing
|
||||
the control key.<BR>
|
||||
</P>
|
||||
|
||||
<P>A turtle can be visible on the board or be hidden. When it is visible
|
||||
the user can decide if it wants a "solid" or "hollow"
|
||||
turtle using the <B>make-hollow! </B>and <B>make-solid!</B> commands.<BR>
|
||||
</P>
|
||||
|
||||
<P>A turtle is always connected to a certain board, which is the board
|
||||
it is drawing on. To create a new turtle on a board use the <B>make-turtle</B>
|
||||
or the <B>clone-turtle</B> commands. A new turtle (created with the <B>make-turtle</B>
|
||||
command) will be black, solid, heading north and with it's pen down, in
|
||||
the center of the board. A cloned turtle will have exactly the same inner
|
||||
state as its parent.<BR>
|
||||
</P>
|
||||
|
||||
<P>A turtle can also look at the board and see other turtles or colors.
|
||||
By using the command <B>look</B> the user can tell the turtle the area
|
||||
in which to look and what to look in this area. </P>
|
||||
|
||||
<P>Example: </P>
|
||||
|
||||
<P>The command </P>
|
||||
|
||||
<P><I>(look t 50 20 '(0 0 0))</I> </P>
|
||||
|
||||
<P>will cause the turtle <I>t</I> to look for black pixels in the area
|
||||
in radius 50 from the turtle and 20 degrees to each side of the heading
|
||||
line, shown here in blue: </P>
|
||||
|
||||
<CENTER><P><IMG border=0 SRC="img00003.gif" HEIGHT=75 WIDTH=48><BR>
|
||||
</P></CENTER>
|
||||
|
||||
<H2><A NAME="INTERRUPTS (NOTIFICATIONS) AND MESSAGE"></A>INTERRUPTS (NOTIFICATIONS)
|
||||
AND MESSAGE HANDLERS<BR>
|
||||
</H2>
|
||||
|
||||
<P>A turtle can have interrupts. Each interrupt is defined in terms of
|
||||
turtle's vision. Whenever a turtle starts or stops seeing a given target,
|
||||
a predefined message is sent to the thread which asked the interrupt. The
|
||||
user can determine if the interrupt will notify on every change (like a
|
||||
"can see"- "can't see" toggle) or only when one change
|
||||
happens (only "can see" or "can't see" toggle). A message
|
||||
can be any valid SCHEME object.<BR>
|
||||
</P>
|
||||
|
||||
<P>Example: </P>
|
||||
|
||||
<P>The command </P>
|
||||
|
||||
<P><I>(turtle-notify t "I-see" "I-don't-see" 50 20
|
||||
color-black)</I> </P>
|
||||
|
||||
<P>tells the turtle <I>t</I> that every time it sees the color black it
|
||||
should send the message <I>"I-see"</I> and when it doesn't see
|
||||
the color black any more it should send the message <I>"I-don't-see"</I>.
|
||||
</P>
|
||||
|
||||
<P>Below is an example of what messages (or no message) <I>t </I>will send
|
||||
while it is moving forward, encountering two black lines on its way:<BR>
|
||||
<BR>
|
||||
<BR>
|
||||
<IMG border=0 SRC="vision.gif" HEIGHT=183 WIDTH=669></P>
|
||||
|
||||
<P><BR>
|
||||
<BR>
|
||||
If the interrupt was of kind "can see" (<B>notify-when</B> command)
|
||||
only the <I>"I-see"</I> messages were sent, and if it was a the
|
||||
"can't see" interrupt (<B>notify-when-not</B> command) only the
|
||||
<I>"I-can't-see" </I>style messages were sent.<BR>
|
||||
</P>
|
||||
|
||||
<P>A special "user interrupt" is invoked when the user right-clicks
|
||||
the turtle or a window. The <B>notify-on-click</B> command is used to enable
|
||||
this.<BR>
|
||||
</P>
|
||||
|
||||
<P>A thread can tell the turtle to delete a certain interrupt using the
|
||||
<B>turtle-no-notify</B> command. It can also tell the turtle to disable
|
||||
all interrupts using the <B>stop-notifying</B> command. <BR>
|
||||
</P>
|
||||
|
||||
<P>In order to process the messages sent from a turtle's interrupt (or
|
||||
from another thread, as presented later) the thread must install a <I>message
|
||||
handler</I> which is a one argument function. If no handler is installed
|
||||
the turtle's messages are lost. There can be only one handler per thread.
|
||||
If the handler is installed then every time an interrupt is invoked, the
|
||||
handler function in called with the message sent by the interrupt as its
|
||||
argument. <BR>
|
||||
<BR>
|
||||
</P>
|
||||
|
||||
<P>Example: </P>
|
||||
|
||||
<P>We declare the function: </P>
|
||||
|
||||
<P><I>(define (my-print x) (write x) (newline))</I> </P>
|
||||
|
||||
<P>and then install <I>my-print</I> as the current handler with: </P>
|
||||
|
||||
<P><I>(install-handler my-print)</I> </P>
|
||||
|
||||
<P>from now on every message a turtle's interrupt sends will be printed
|
||||
on screen. If <I>my-print</I> was installed in the previous example then
|
||||
we would have seen: <BR>
|
||||
</P>
|
||||
|
||||
<P><I>"I-see"</I> </P>
|
||||
|
||||
<P><I>"I-don't-see"</I> </P>
|
||||
|
||||
<P><I>"I-see"</I><BR>
|
||||
</P>
|
||||
|
||||
<P>on the screen.<BR>
|
||||
</P>
|
||||
|
||||
<P>A good example to view the interrupts in action is to make a turtle
|
||||
turn each time it sees a color and then let it wander aimlessly. Then use
|
||||
the user pen to draw lines the turtle's way and watch it change direction.
|
||||
See the PINGPONG.SCM file for a demo program. <BR>
|
||||
</P>
|
||||
|
||||
<P>The message-handler concept can be used as a mean of synchronous inter-thread
|
||||
communications. The tell-thread functions sends a message to a thread,
|
||||
which will be treated as an interrupt-generated message: It will cause
|
||||
the thread's message handler function to be called with tell-thread's argument
|
||||
as its own. This allows one thread to initiate a computation in a different
|
||||
thread's environment and CPU space synchronously and without sharing environments.
|
||||
<BR>
|
||||
</P>
|
||||
|
||||
<H2><A NAME="MESSAGE"></A>MESSAGE QUEUES<BR>
|
||||
</H2>
|
||||
|
||||
<P>In order to let threads communicate between themselves asynchronously
|
||||
a system of message queues was developed. A queue is an object which stores
|
||||
and relieves messages, stored in FIFO (First In First Out) style, meaning
|
||||
messages are read in the order of arrival to the queue. Supported messages
|
||||
are pairs of type and body, both of which can be any valid SCHEME object.
|
||||
Looking for messages of a certain type is also supported, allowing implementation
|
||||
of more flexible communication schemes than plain FIFO.<BR>
|
||||
</P>
|
||||
|
||||
<P>A thread can check if there are any messages in a given queue, if it
|
||||
does <B>get-message</B> without checking first if there are messages in
|
||||
the queue it will wait a given time-out or forever if no time-out is given.
|
||||
If by the end of the time-out no message were in the queue the result will
|
||||
be false.<BR>
|
||||
</P>
|
||||
|
||||
<P>Example: </P>
|
||||
|
||||
<P>In this example a queue <I>q</I> is created then a message is posted
|
||||
into the queue and read from it.<BR>
|
||||
</P>
|
||||
|
||||
<P><I>(define q (make-queue))</I> </P>
|
||||
|
||||
<P><I>(post-message q (cons 'type-circus 'bozo-the-clown))</I> </P>
|
||||
|
||||
<P><I>(define msg (get-message q))</I><BR>
|
||||
</P>
|
||||
|
||||
<P>now the command </P>
|
||||
|
||||
<P><I>(car msg) </I></P>
|
||||
|
||||
<P>will give </P>
|
||||
|
||||
<P><I>type-circus</I> </P>
|
||||
|
||||
<P>and the command </P>
|
||||
|
||||
<P><I>(cdr msg) </I></P>
|
||||
|
||||
<P>will yield </P>
|
||||
|
||||
<P><I>bozo-the-clown</I>. </P>
|
||||
|
||||
|
||||
<P>
|
||||
<HR width=80% align=left color=blue>
|
||||
<CENTER>
|
||||
<A href="#top"><IMG border=0 src=back.gif ALT=" [TOP] "></A>
|
||||
<A href="background.html"><IMG border=0 src=prev.gif ALT=" [PREV] "></A>
|
||||
<A href="gui.html"><IMG border=0 src=next.gif ALT=" [PREV] "></A>
|
||||
<A href="index.html#toc"><IMG border=0 src=toc.gif ALT=" [PREV] "></A>
|
||||
</CENTER>
|
||||
</BODY>
|
||||
</HTML>
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,130 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
||||
<HTML>
|
||||
<HEAD>
|
||||
<TITLE>Galapagos - Background</TITLE>
|
||||
<META NAME="Author" CONTENT="">
|
||||
<META NAME="GENERATOR" CONTENT="Mozilla/3.01Gold (Win95; I) [Netscape]">
|
||||
</HEAD>
|
||||
<BODY background=stone.jpg>
|
||||
|
||||
<P>
|
||||
<CENTER>
|
||||
<A href="index.html"><IMG border=0 src=prev.gif ALT=" [PREV] "></A>
|
||||
<A href="extensions.html"><IMG border=0 src=next.gif ALT=" [PREV] "></A>
|
||||
<A href="index.html#toc"><IMG border=0 src=toc.gif ALT=" [PREV] "></A>
|
||||
</CENTER>
|
||||
<HR width=80% align=right color=blue>
|
||||
<P>
|
||||
<H2 ALIGN=CENTER><A NAME="top"></A><FONT SIZE=+4>Background</FONT></H2>
|
||||
|
||||
<UL>
|
||||
<LI><A HREF="background.html#SCHEME">SCHEME</A></LI>
|
||||
<LI><A HREF="background.html#LOGO AND TURTLE">LOGO and Turtle Geometry</A></LI>
|
||||
<LI><A HREF="background.html#OBJECTIVES">Objectives</A></LI>
|
||||
<LI><A HREF="background.html#AVAILABILITY">Avaliability</A></LI>
|
||||
</UL>
|
||||
|
||||
<H2>
|
||||
<HR WIDTH="100%"></H2>
|
||||
|
||||
<H2><A NAME="SCHEME"></A>SCHEME</H2>
|
||||
|
||||
<P>Scheme is a dialect of Lisp that stresses conceptual elegance and simplicity.
|
||||
It is specified in R4RS and IEEE standard P1178. Scheme is much smaller
|
||||
than Common Lisp; the specification is about 50 pages, compared to Common
|
||||
Lisp's 1300 page draft standard. (See the Lisp FAQ for details on standards
|
||||
for Common Lisp.) Advocates of Scheme often find it amusing that the entire
|
||||
Scheme standard is shorter than the index to Guy Steele's "Common
|
||||
Lisp: the Language, 2nd Edition".<BR>
|
||||
</P>
|
||||
|
||||
<P>Scheme is often used in computer science curricula and programming language
|
||||
research, due to its ability to represent many programming abstractions
|
||||
with its simple primitives.<BR>
|
||||
</P>
|
||||
|
||||
<P>There are a lot of traditional SCHEME interpreter available such as
|
||||
Chez, ELK 2.1, GAMBIT, MITScheme, scheme->C, Scheme48, T3.1, VSCM and
|
||||
Scm4e. Many free Scheme implementations (as well as SCM) are available
|
||||
from swiss-ftp.ai.mit.edu [18.43.0.246].<BR>
|
||||
</P>
|
||||
|
||||
<P>Galapagos is built over the SCM interpreter version 4e4 written by Aubrey
|
||||
Jaffer <jaffer@ai.mit.edu>.<BR>
|
||||
<BR>
|
||||
<BR>
|
||||
</P>
|
||||
|
||||
<H2><A NAME="LOGO AND TURTLE"></A>LOGO AND TURTLE GEOMETRY<BR>
|
||||
</H2>
|
||||
|
||||
<P>LOGO is a programming language designed for use by learners, including
|
||||
children. It is a dialect of LISP which has a more natural syntax, using
|
||||
infix arithmetics and (almost) no parentheses. LOGO features a "turtle"
|
||||
which can be instructed to move across the screen and draw shapes. This
|
||||
became known as "Turtle Graphics" or "Turtle Geometry"
|
||||
- a geometry that describes paths "from within" rather than "from
|
||||
outside" or "from above." For example, "turn right"
|
||||
means turn right relative to whatever direction you were heading before;
|
||||
by contrast, "turn east" specifies an apparently absolute direction.
|
||||
A Logo user or program manipulates the graphical turtle by telling it to
|
||||
move forward or back some number of steps, or by telling it to turn left
|
||||
or right some number of degrees.<BR>
|
||||
</P>
|
||||
|
||||
<P>Turtle geometry has two major advantages. One is that many paths are
|
||||
more simply described in relative than in absolute terms. For example,
|
||||
it's easy to indicate the absolute coordinates of the corners of a square
|
||||
with vertical and horizontal sides, but it's not so easy to find the corners
|
||||
of an inclined square. In turtle geometry the same commands (go <B>forward</B>,
|
||||
turn right 90 <B>degrees</B>, etc.) work for squares with any orientation.
|
||||
The second advantage is pedagogic rather than computational: turtle geometry
|
||||
is compatible with a learner's own experience of moving in the world -
|
||||
it's "body syntonic."<BR>
|
||||
</P>
|
||||
|
||||
<P><A NAME="OBJECTIVES"></A><B><FONT SIZE=+2>OBJECTIVES</FONT></B><BR>
|
||||
</P>
|
||||
|
||||
<P>The two major goals behind Galapagos were:<BR>
|
||||
</P>
|
||||
|
||||
<P>First, we wanted to create an environment suitable for teaching programming,
|
||||
patterned after Logo's environment and its easy-to-understand, easy-to-use
|
||||
turtle geometry. We chose Scheme as the programming language because of
|
||||
its educational value, as noted before. We added Turtle Graphics because
|
||||
of its ability to visualize computations, and thus help understanding them
|
||||
better.<BR>
|
||||
</P>
|
||||
|
||||
<P>Second, we wanted to add parallel programming. The importance of multiprocessor
|
||||
machines and of multithreading is becoming more apparent every day, and
|
||||
so is the need for tools to help understanding parallel programming paradigms.
|
||||
By extending Scheme to be multithreaded, we wanted to create such a tool.<BR>
|
||||
</P>
|
||||
|
||||
<P><A NAME="AVAILABILITY"></A><B><FONT SIZE=+2>AVAILABILITY</FONT></B><BR>
|
||||
</P>
|
||||
|
||||
<P>Galapagos was developed to run under Windows 95, and should work under
|
||||
Window NT as well. (It uses 32-bit specific code so Win32s is not enough
|
||||
to run Galapagos). Both binary and source are <A href="index.html#download">available</A> at the
|
||||
homepage:<BR>
|
||||
</P>
|
||||
|
||||
<CENTER><P><TT>
|
||||
<A HREF="http://www.cs.bgu.ac.il/~elad/GALAPAGOS">http://www.cs.bgu.ac.il/~elad/GALAPAGOS</A>
|
||||
</TT>
|
||||
</P></CENTER>
|
||||
|
||||
|
||||
<P>
|
||||
<HR width=80% align=left color=blue>
|
||||
<CENTER>
|
||||
<A href="#top"><IMG border=0 src=back.gif ALT=" [TOP] "></A>
|
||||
<A href="index.html"><IMG border=0 src=prev.gif ALT=" [PREV] "></A>
|
||||
<A href="extensions.html"><IMG border=0 src=next.gif ALT=" [PREV] "></A>
|
||||
<A href="index.html#toc"><IMG border=0 src=toc.gif ALT=" [PREV] "></A>
|
||||
</CENTER>
|
||||
</BODY>
|
||||
</HTML>
|
||||
|
|
@ -0,0 +1,81 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
||||
<HTML>
|
||||
<HEAD>
|
||||
<TITLE>Galapagos - Bibliography</TITLE>
|
||||
<META NAME="GENERATOR" CONTENT="Mozilla/3.01Gold (Win95; I) [Netscape]">
|
||||
</HEAD>
|
||||
<BODY background=stone.jpg>
|
||||
|
||||
<CENTER>
|
||||
<A href="index.html#toc"><IMG border=0 src=toc.gif ALT=" [PREV] "></A>
|
||||
</CENTER>
|
||||
<HR width=80% align=right color=blue>
|
||||
<P>
|
||||
|
||||
<H1 ALIGN=CENTER>BIBLIOGRAPHY</H1>
|
||||
<HR>
|
||||
|
||||
<UL>
|
||||
<LI><A HREF="http://www.cs.cmu.edu:8001/Web/Groups/AI/html/faqs/lang/scheme/top.html"><B>The
|
||||
SCHEME FAQ</B></A>,<BR><TT>
|
||||
http://www.cs.cmu.edu:8001/Web/Groups/AI/html/faqs/lang/scheme/top.html
|
||||
</TT></LI><P>
|
||||
|
||||
<LI><A HREF="ftp://cher.media.mit.edu/pub/logo/FAQ"><B>The LOGO FAQ</B></A>,<BR><TT>
|
||||
ftp://cher.media.mit.edu/pub/logo/FAQ
|
||||
</TT></LI><P>
|
||||
|
||||
<LI><B>SCM manual version 4e4</B>, Aubrey Jaffer. SCM 4e4 is available
|
||||
at: <BR>
|
||||
<TT><A
|
||||
HREF="ftp://ftp-swiss.ai.mit.edu/pub/scm/scm4e4.tar.gz">ftp://ftp-swiss.ai.mit.edu/pub/scm/scm4e4.tar.gz</A>
|
||||
</TT></LI><P>
|
||||
|
||||
<LI><B>Structure and interpretation of computer programs,</B>
|
||||
Harold Ableson and Gerald J. Sussman with Julie Sussman.
|
||||
</LI><P>
|
||||
|
||||
<LI><B>Garbage Collection</B>, Andrew W. Appel; appeard
|
||||
in <B>Topics in Advanced Language Implementation</B>, edited by Peter Lee. </LI><P>
|
||||
</UL>
|
||||
|
||||
<P>
|
||||
<HR>
|
||||
<P><B><H1><CENTER>LINKS</CENTER></H1></B>
|
||||
</P>
|
||||
<P>
|
||||
<UL>
|
||||
<LI>Scheme:<P>
|
||||
<UL>
|
||||
<LI><A HREF="http://www.cs.indiana.edu/scheme-repository/home.html">SCHEME repository</A><P></LI>
|
||||
<LI><A HREF="http://people.delphi.com/gjc/siod.html">SIOD</A><P></LI>
|
||||
<LI><A HREF="http://www-swiss.ai.mit.edu/~jaffer/SCM.html">SCM</A><P></LI>
|
||||
</UL>
|
||||
</LI>
|
||||
|
||||
<LI>The Programmers:
|
||||
<P>
|
||||
<UL>
|
||||
<LI><A href="http://www.cs.bgu.ac.il/~elad">Elad's Spot on the Web</A> <<TT><A href="mailto:elad@cs.bgu.ac.il">elad@cs.bgu.ac.il</A></TT>></LI>
|
||||
<P>
|
||||
<LI><A href="http://www.cs.bgu.ac.il/~tebeka">Miki's Terrible Homepage</A> <<TT><A href="mailto:tebeka@cs.bgu.ac.il">tebeka@cs.bgu.ac.il</A></TT>></LI>
|
||||
<P></UL>
|
||||
|
||||
<LI>The Advisor:
|
||||
<P>
|
||||
<UL>
|
||||
<LI><A href="http://www.cs.bgu.ac.il/~elhadad">Dr. Michael Elhadad</A>
|
||||
<<TT><A href="mailto:elhadad@cs.bgu.ac.il">elhadad@cs.bgu.ac.il</A></TT>></LI>
|
||||
</UL>
|
||||
|
||||
</UL>
|
||||
<P>
|
||||
<HR width=80% align=left color=blue>
|
||||
<CENTER>
|
||||
<A href="index.html#toc"><IMG border=0 src=toc.gif ALT=" [PREV] "></A>
|
||||
</CENTER>
|
||||
</BODY>
|
||||
</HTML>
|
||||
|
||||
|
||||
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 6.7 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 2.4 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 740 B |
Binary file not shown.
|
After Width: | Height: | Size: 2.4 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 740 B |
Binary file not shown.
|
After Width: | Height: | Size: 6.7 KiB |
|
|
@ -0,0 +1,95 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
||||
<HTML>
|
||||
<HEAD>
|
||||
<TITLE>Galapagos</TITLE>
|
||||
</HEAD>
|
||||
<BODY background=stone.jpg>
|
||||
|
||||
<CENTER><P><B><FONT COLOR="#008040" SIZE=+4>Welcome to<BR>
|
||||
<IMG border=0 SRC=gps.gif alt="GALAPAGOS"></FONT></B></P></CENTER>
|
||||
|
||||
Galapagos is an interactive multithreaded Scheme interpreter with turtle
|
||||
graphics for Windows 95. It is built around the SCM interpreter, and it
|
||||
provides multiple interpreters, threads, turtles, and drawing boards, all
|
||||
running concurrently using WIN32's multithreading abilities, and freely
|
||||
<A href="#download">available</A>.
|
||||
|
||||
<P>
|
||||
<HR>
|
||||
<P>
|
||||
<Center>
|
||||
<A href="http://www.cs.bgu.ac.il"><IMG border=0 src="bgu_logo_tiny.gif" alt=""></A><BR><BR>
|
||||
Spring 1997<BR><BR>
|
||||
Graduation project<BR><BR>
|
||||
<A href="http://www.cs.bgu.ac.il">Department of Math & Computer Science,</A><BR><BR>
|
||||
<A href="http://www.bgu.ac.il">Ben-Gurion University of the Negev</A><BR><BR>
|
||||
<BR>
|
||||
Written by <A href="http://www.cs.bgu.ac.il/~elad">Elad Eyal</A> and <A href="http://www.cs.bgu.ac.il/~tebeka">Miki
|
||||
Tebeka</A>.<BR>
|
||||
<BR>
|
||||
Supervisor: <A href="http://www.cs.bgu.ac.il/~elhadad">Dr. Michael Elhadad</A>
|
||||
</CENTER>
|
||||
<P>
|
||||
<P>
|
||||
<HR width=100%>
|
||||
<P>
|
||||
<A name="toc">
|
||||
<CENTER><P><B><FONT SIZE=+3>TABLE OF CONTENTS </FONT></B></P></CENTER>
|
||||
|
||||
<UL>
|
||||
<LI><A HREF="background.html">Background </A></LI>
|
||||
<UL>
|
||||
<LI><A HREF="background.html#SCHEME">SCHEME</A></LI>
|
||||
<LI><A HREF="background.html#LOGO AND TURTLE">LOGO and Turtle Geometry</A></LI>
|
||||
<LI><A HREF="background.html#OBJECTIVES">Objectives</A></LI>
|
||||
<LI><A HREF="background.html#AVAILABILITY">Avaliability</A></LI>
|
||||
</UL>
|
||||
<LI><A HREF="extensions.html">SCHEME extensions</A></LI>
|
||||
<UL>
|
||||
<LI><A HREF="extensions.html#THE NEW ENVIRONMENT">The New Environment Model</A></LI>
|
||||
<LI><A HREF="extensions.html#THREADS">Threads</A></LI>
|
||||
<LI><A HREF="extensions.html#CONSOLES">Consoles</A></LI>
|
||||
<LI><A HREF="extensions.html#DRAWING">Drawing Boards</A></LI>
|
||||
<LI><A HREF="extensions.html#TURTLES">Turtles</A></LI>
|
||||
<LI><A HREF="extensions.html#INTERRUPTS (NOTIFICATIONS) AND MESSAGE">Interrupts (Notifications) and Message handlers</A></LI>
|
||||
</UL>
|
||||
<LI><A HREF="gui.html">The interactive GUI</A></LI>
|
||||
<LI><A HREF="implementation.html">Implementation</A></LI>
|
||||
<UL>
|
||||
<LI><A HREF="implementation.html#FITTING SCM INTO">Fitting SCM into Windows</A></LI>
|
||||
<LI><A HREF="implementation.html#GARBAGE">Garbage Collection</A></LI>
|
||||
<LI><A HREF="implementation.html#BOARDS">Boards</A></LI>
|
||||
<LI><A HREF="implementation.html#TURTLES">Turtles</A></LI>
|
||||
<LI><A HREF="implementation.html#VISION">Vision</A></LI>
|
||||
<LI><A HREF="implementation.html#INTERRUPTS">Interrupts</A></LI>
|
||||
<LI><A HREF="implementation.html#CLASS">Class Organization</A></LI>
|
||||
</UL>
|
||||
<LI><A HREF="manual.html">Programer's Manual</A></LI>
|
||||
<UL>
|
||||
<LI><A HREF="manual.html#ENVIRONMENTS">Environments</A></LI>
|
||||
<LI><A HREF="manual.html#MESSAGE">Message Queues</A></LI>
|
||||
<LI><A HREF="manual.html#WINDOW">Window Commands</A></LI>
|
||||
<LI><A HREF="manual.html#TURTLE">Turtle Commands</A></LI>
|
||||
<LI><A HREF="manual.html#VISION">Vision</A></LI>
|
||||
<LI><A HREF="manual.html#INTERRUPTS">Interrupts (Notifications)</A></LI>
|
||||
<LI><A HREF="manual.html#THREADS">Threads</A></LI>
|
||||
</UL>
|
||||
<LI><A HREF="bib.html">Bibiliography and Links</A></LI>
|
||||
</UL>
|
||||
|
||||
<P>
|
||||
|
||||
<BR>
|
||||
<A name="download">
|
||||
<CENTER><P><B><FONT SIZE=+3>DOWNLOAD CENTER</FONT></B></P></CENTER>
|
||||
<P>
|
||||
<CENTER><FONT size=-1><TT>GNU LICENSE. COPYRIGHTED. PROVIDED "AS IS". NO
|
||||
WARRANTIES OR LIABILITIES. ETC.</TT></CENTER>
|
||||
<P>
|
||||
<P>
|
||||
500K <A href="gps10bin.zip"><TT>gps10bin.zip</TT></A> - Executable and required Scheme libraries (SLIB)<BR>
|
||||
700K <A href="gps10src.zip"><TT>gps10src.zip</TT></A> - Same with all source code <BR>
|
||||
400K <A href="mfc40dll.zip"><TT>mfc40dll.zip</TT></A> - You might need this MFC40.DLL if you
|
||||
don't have it already. <BR>
|
||||
</BODY>
|
||||
</HTML>
|
||||
|
|
@ -0,0 +1,130 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
||||
<HTML>
|
||||
<HEAD>
|
||||
<TITLE>Galapagos - Background</TITLE>
|
||||
<META NAME="Author" CONTENT="">
|
||||
<META NAME="GENERATOR" CONTENT="Mozilla/3.01Gold (Win95; I) [Netscape]">
|
||||
</HEAD>
|
||||
<BODY background=stone.jpg>
|
||||
|
||||
<P>
|
||||
<CENTER>
|
||||
<A href="index.html"><IMG border=0 src=prev.gif ALT=" [PREV] "></A>
|
||||
<A href="extensions.html"><IMG border=0 src=next.gif ALT=" [PREV] "></A>
|
||||
<A href="index.html#toc"><IMG border=0 src=toc.gif ALT=" [PREV] "></A>
|
||||
</CENTER>
|
||||
<HR width=80% align=right color=blue>
|
||||
<P>
|
||||
<H2 ALIGN=CENTER><A NAME="top"></A><FONT SIZE=+4>Background</FONT></H2>
|
||||
|
||||
<UL>
|
||||
<LI><A HREF="background.html#SCHEME">SCHEME</A></LI>
|
||||
<LI><A HREF="background.html#LOGO AND TURTLE">LOGO and Turtle Geometry</A></LI>
|
||||
<LI><A HREF="background.html#OBJECTIVES">Objectives</A></LI>
|
||||
<LI><A HREF="background.html#AVAILABILITY">Avaliability</A></LI>
|
||||
</UL>
|
||||
|
||||
<H2>
|
||||
<HR WIDTH="100%"></H2>
|
||||
|
||||
<H2><A NAME="SCHEME"></A>SCHEME</H2>
|
||||
|
||||
<P>Scheme is a dialect of Lisp that stresses conceptual elegance and simplicity.
|
||||
It is specified in R4RS and IEEE standard P1178. Scheme is much smaller
|
||||
than Common Lisp; the specification is about 50 pages, compared to Common
|
||||
Lisp's 1300 page draft standard. (See the Lisp FAQ for details on standards
|
||||
for Common Lisp.) Advocates of Scheme often find it amusing that the entire
|
||||
Scheme standard is shorter than the index to Guy Steele's "Common
|
||||
Lisp: the Language, 2nd Edition".<BR>
|
||||
</P>
|
||||
|
||||
<P>Scheme is often used in computer science curricula and programming language
|
||||
research, due to its ability to represent many programming abstractions
|
||||
with its simple primitives.<BR>
|
||||
</P>
|
||||
|
||||
<P>There are a lot of traditional SCHEME interpreter available such as
|
||||
Chez, ELK 2.1, GAMBIT, MITScheme, scheme->C, Scheme48, T3.1, VSCM and
|
||||
Scm4e. Many free Scheme implementations (as well as SCM) are available
|
||||
from swiss-ftp.ai.mit.edu [18.43.0.246].<BR>
|
||||
</P>
|
||||
|
||||
<P>Galapagos is built over the SCM interpreter version 4e4 written by Aubrey
|
||||
Jaffer <jaffer@ai.mit.edu>.<BR>
|
||||
<BR>
|
||||
<BR>
|
||||
</P>
|
||||
|
||||
<H2><A NAME="LOGO AND TURTLE"></A>LOGO AND TURTLE GEOMETRY<BR>
|
||||
</H2>
|
||||
|
||||
<P>LOGO is a programming language designed for use by learners, including
|
||||
children. It is a dialect of LISP which has a more natural syntax, using
|
||||
infix arithmetics and (almost) no parentheses. LOGO features a "turtle"
|
||||
which can be instructed to move across the screen and draw shapes. This
|
||||
became known as "Turtle Graphics" or "Turtle Geometry"
|
||||
- a geometry that describes paths "from within" rather than "from
|
||||
outside" or "from above." For example, "turn right"
|
||||
means turn right relative to whatever direction you were heading before;
|
||||
by contrast, "turn east" specifies an apparently absolute direction.
|
||||
A Logo user or program manipulates the graphical turtle by telling it to
|
||||
move forward or back some number of steps, or by telling it to turn left
|
||||
or right some number of degrees.<BR>
|
||||
</P>
|
||||
|
||||
<P>Turtle geometry has two major advantages. One is that many paths are
|
||||
more simply described in relative than in absolute terms. For example,
|
||||
it's easy to indicate the absolute coordinates of the corners of a square
|
||||
with vertical and horizontal sides, but it's not so easy to find the corners
|
||||
of an inclined square. In turtle geometry the same commands (go <B>forward</B>,
|
||||
turn right 90 <B>degrees</B>, etc.) work for squares with any orientation.
|
||||
The second advantage is pedagogic rather than computational: turtle geometry
|
||||
is compatible with a learner's own experience of moving in the world -
|
||||
it's "body syntonic."<BR>
|
||||
</P>
|
||||
|
||||
<P><A NAME="OBJECTIVES"></A><B><FONT SIZE=+2>OBJECTIVES</FONT></B><BR>
|
||||
</P>
|
||||
|
||||
<P>The two major goals behind Galapagos were:<BR>
|
||||
</P>
|
||||
|
||||
<P>First, we wanted to create an environment suitable for teaching programming,
|
||||
patterned after Logo's environment and its easy-to-understand, easy-to-use
|
||||
turtle geometry. We chose Scheme as the programming language because of
|
||||
its educational value, as noted before. We added Turtle Graphics because
|
||||
of its ability to visualize computations, and thus help understanding them
|
||||
better.<BR>
|
||||
</P>
|
||||
|
||||
<P>Second, we wanted to add parallel programming. The importance of multiprocessor
|
||||
machines and of multithreading is becoming more apparent every day, and
|
||||
so is the need for tools to help understanding parallel programming paradigms.
|
||||
By extending Scheme to be multithreaded, we wanted to create such a tool.<BR>
|
||||
</P>
|
||||
|
||||
<P><A NAME="AVAILABILITY"></A><B><FONT SIZE=+2>AVAILABILITY</FONT></B><BR>
|
||||
</P>
|
||||
|
||||
<P>Galapagos was developed to run under Windows 95, and should work under
|
||||
Window NT as well. (It uses 32-bit specific code so Win32s is not enough
|
||||
to run Galapagos). Both binary and source are <A href="index.html#download">available</A> at the
|
||||
homepage:<BR>
|
||||
</P>
|
||||
|
||||
<CENTER><P><TT>
|
||||
<A HREF="http://www.cs.bgu.ac.il/~elad/GALAPAGOS">http://www.cs.bgu.ac.il/~elad/GALAPAGOS</A>
|
||||
</TT>
|
||||
</P></CENTER>
|
||||
|
||||
|
||||
<P>
|
||||
<HR width=80% align=left color=blue>
|
||||
<CENTER>
|
||||
<A href="#top"><IMG border=0 src=back.gif ALT=" [TOP] "></A>
|
||||
<A href="index.html"><IMG border=0 src=prev.gif ALT=" [PREV] "></A>
|
||||
<A href="extensions.html"><IMG border=0 src=next.gif ALT=" [PREV] "></A>
|
||||
<A href="index.html#toc"><IMG border=0 src=toc.gif ALT=" [PREV] "></A>
|
||||
</CENTER>
|
||||
</BODY>
|
||||
</HTML>
|
||||
|
|
@ -0,0 +1,81 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
||||
<HTML>
|
||||
<HEAD>
|
||||
<TITLE>Galapagos - Bibliography</TITLE>
|
||||
<META NAME="GENERATOR" CONTENT="Mozilla/3.01Gold (Win95; I) [Netscape]">
|
||||
</HEAD>
|
||||
<BODY background=stone.jpg>
|
||||
|
||||
<CENTER>
|
||||
<A href="index.html#toc"><IMG border=0 src=toc.gif ALT=" [PREV] "></A>
|
||||
</CENTER>
|
||||
<HR width=80% align=right color=blue>
|
||||
<P>
|
||||
|
||||
<H1 ALIGN=CENTER>BIBLIOGRAPHY</H1>
|
||||
<HR>
|
||||
|
||||
<UL>
|
||||
<LI><A HREF="http://www.cs.cmu.edu:8001/Web/Groups/AI/html/faqs/lang/scheme/top.html"><B>The
|
||||
SCHEME FAQ</B></A>,<BR><TT>
|
||||
http://www.cs.cmu.edu:8001/Web/Groups/AI/html/faqs/lang/scheme/top.html
|
||||
</TT></LI><P>
|
||||
|
||||
<LI><A HREF="ftp://cher.media.mit.edu/pub/logo/FAQ"><B>The LOGO FAQ</B></A>,<BR><TT>
|
||||
ftp://cher.media.mit.edu/pub/logo/FAQ
|
||||
</TT></LI><P>
|
||||
|
||||
<LI><B>SCM manual version 4e4</B>, Aubrey Jaffer. SCM 4e4 is available
|
||||
at: <BR>
|
||||
<TT><A
|
||||
HREF="ftp://ftp-swiss.ai.mit.edu/pub/scm/scm4e4.tar.gz">ftp://ftp-swiss.ai.mit.edu/pub/scm/scm4e4.tar.gz</A>
|
||||
</TT></LI><P>
|
||||
|
||||
<LI><B>Structure and interpretation of computer programs,</B>
|
||||
Harold Ableson and Gerald J. Sussman with Julie Sussman.
|
||||
</LI><P>
|
||||
|
||||
<LI><B>Garbage Collection</B>, Andrew W. Appel; appeard
|
||||
in <B>Topics in Advanced Language Implementation</B>, edited by Peter Lee. </LI><P>
|
||||
</UL>
|
||||
|
||||
<P>
|
||||
<HR>
|
||||
<P><B><H1><CENTER>LINKS</CENTER></H1></B>
|
||||
</P>
|
||||
<P>
|
||||
<UL>
|
||||
<LI>Scheme:<P>
|
||||
<UL>
|
||||
<LI><A HREF="http://www.cs.indiana.edu/scheme-repository/home.html">SCHEME repository</A><P></LI>
|
||||
<LI><A HREF="http://people.delphi.com/gjc/siod.html">SIOD</A><P></LI>
|
||||
<LI><A HREF="http://www-swiss.ai.mit.edu/~jaffer/SCM.html">SCM</A><P></LI>
|
||||
</UL>
|
||||
</LI>
|
||||
|
||||
<LI>The Programmers:
|
||||
<P>
|
||||
<UL>
|
||||
<LI><A href="http://www.cs.bgu.ac.il/~elad">Elad's Spot on the Web</A> <<TT><A href="mailto:elad@cs.bgu.ac.il">elad@cs.bgu.ac.il</A></TT>></LI>
|
||||
<P>
|
||||
<LI><A href="http://www.cs.bgu.ac.il/~tebeka">Miki's Terrible Homepage</A> <<TT><A href="mailto:tebeka@cs.bgu.ac.il">tebeka@cs.bgu.ac.il</A></TT>></LI>
|
||||
<P></UL>
|
||||
|
||||
<LI>The Advisor:
|
||||
<P>
|
||||
<UL>
|
||||
<LI><A href="http://www.cs.bgu.ac.il/~elhadad">Dr. Michael Elhadad</A>
|
||||
<<TT><A href="mailto:elhadad@cs.bgu.ac.il">elhadad@cs.bgu.ac.il</A></TT>></LI>
|
||||
</UL>
|
||||
|
||||
</UL>
|
||||
<P>
|
||||
<HR width=80% align=left color=blue>
|
||||
<CENTER>
|
||||
<A href="index.html#toc"><IMG border=0 src=toc.gif ALT=" [PREV] "></A>
|
||||
</CENTER>
|
||||
</BODY>
|
||||
</HTML>
|
||||
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,493 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
||||
<HTML>
|
||||
<HEAD>
|
||||
<TITLE>Galapagos - Scheme Extensions</TITLE>
|
||||
<META NAME="Author" CONTENT="">
|
||||
<META NAME="GENERATOR" CONTENT="Mozilla/3.01Gold (Win95; I) [Netscape]">
|
||||
</HEAD>
|
||||
<BODY background=stone.jpg>
|
||||
|
||||
<CENTER>
|
||||
<A href="background.html"><IMG border=0 src=prev.gif ALT=" [PREV] "></A>
|
||||
<A href="gui.html"><IMG border=0 src=next.gif ALT=" [PREV] "></A>
|
||||
<A href="index.html#toc"><IMG border=0 src=toc.gif ALT=" [PREV] "></A>
|
||||
</CENTER>
|
||||
<HR width=80% align=right color=blue>
|
||||
<P>
|
||||
|
||||
<H1 ALIGN=CENTER><A NAME="top"></A>SCHEME EXTENSIONS<BR>
|
||||
</H1>
|
||||
|
||||
<UL>
|
||||
<LI><A HREF="extensions.html#THE NEW ENVIRONMENT">The New Environment Model</A></LI>
|
||||
<LI><A HREF="extensions.html#THREADS">Threads</A></LI>
|
||||
<LI><A HREF="extensions.html#CONSOLES">Consoles</A></LI>
|
||||
<LI><A HREF="extensions.html#DRAWING">Drawing Boards</A></LI>
|
||||
<LI><A HREF="extensions.html#TURTLES">Turtles</A></LI>
|
||||
<LI><A HREF="extensions.html#INTERRUPTS (NOTIFICATIONS) AND MESSAGE">Interrupts
|
||||
(Notifications) and Message handlers</A></LI>
|
||||
</UL>
|
||||
|
||||
<P>
|
||||
<HR WIDTH="100%"></P>
|
||||
|
||||
<P>We have extended Scheme in two main
|
||||
directions: Turtle graphics and multithreading:<BR>
|
||||
</P>
|
||||
|
||||
<P>The <I>turtle</I> object lives on a board on which it can move and draw.
|
||||
A turtle can also communicate with the board and "see" colors
|
||||
or other turtles. Galapagos Scheme provides a set of primitives to create
|
||||
and manage such turtles and the boards they live on. <BR>
|
||||
</P>
|
||||
|
||||
<P>A set of additional primitives enable the programmer to create multiple
|
||||
interpreters that run concurrently. The environment model was extended
|
||||
to support shared or thread-specific environments, and primitives to handle
|
||||
multiple environments were also added. <BR>
|
||||
<BR>
|
||||
</P>
|
||||
|
||||
<H2><A NAME="THE NEW ENVIRONMENT"></A>THE NEW ENVIRONMENT MODEL<BR>
|
||||
</H2>
|
||||
|
||||
<P>A frame is a table which maps (or <I>binds</I>) names to values. An
|
||||
environment is a chained list of frames in which the interpreter works.
|
||||
</P>
|
||||
|
||||
<P>For example the command: </P>
|
||||
|
||||
<P><I>(define x 7)</I> </P>
|
||||
|
||||
<P>creates a binding between <I>x</I> and the value <I>7</I>. </P>
|
||||
|
||||
<P>A typical environment looks like this:</P>
|
||||
|
||||
<P><CENTER>
|
||||
<IMG border=0 SRC="Envs.gif" HEIGHT=125 WIDTH=459><BR>
|
||||
</CENTER></P>
|
||||
<BR>
|
||||
<BR>
|
||||
<BR>
|
||||
Each rectangle denotes a frame and inside it are the bindings it holds.
|
||||
The rightmost rectangle is the global environment.<BR>
|
||||
</P>
|
||||
|
||||
<P>When a variable is evaluated, the interpreter first tries to find it
|
||||
in the current frame. If a suitable binding can't be found, the interpreter
|
||||
moves to the next frame in the environment and searched for a binding there.<BR>
|
||||
</P>
|
||||
|
||||
<P>In our example if we write <I>x</I> in the command line we'll get <I>12</I>
|
||||
as the answer because all such computations take place at the global environment.
|
||||
<BR>
|
||||
</P>
|
||||
|
||||
<P>A function application is always evaluated with respect to the environment
|
||||
the in which it was defined. (A function "holds" its environment,
|
||||
hence the name "closure") This means that if we write </P>
|
||||
|
||||
<P><I>(define (f) x) </I></P>
|
||||
|
||||
<P>and then </P>
|
||||
|
||||
<P><I>(f)</I> </P>
|
||||
|
||||
<P>the result will be </P>
|
||||
|
||||
<P><I>12</I>.<BR>
|
||||
<BR>
|
||||
<BR>
|
||||
<BR>
|
||||
<BR>
|
||||
<P><CENTER>
|
||||
<IMG border=0 SRC="Envs2.gif" HEIGHT=140 WIDTH=551><BR>
|
||||
</CENTER></P>
|
||||
<BR>
|
||||
In traditional SCHEME we have only one interpreter running at a time, so
|
||||
at a given point of calculation there is only one environment. In Galapagos
|
||||
multiple interpreters can run at the same time, and each of them has its
|
||||
own environment.<BR>
|
||||
</P>
|
||||
|
||||
<P>Under Galapagos's environment model, every interpreter works on its
|
||||
branch of an "environments tree", but can also evaluate an expression
|
||||
in any other environment in the tree. If two interpreters have a shared
|
||||
node on the tree, then from that point up (towards the global environment)
|
||||
all the bindings are the same for the two interpreters. The global environment
|
||||
is shared by all interpreters. If an interpreter changes the value of some
|
||||
variable, the binding is changed in all other interpreters that have access
|
||||
to the frame where the variable was declared. Obviously, caution should
|
||||
be taken when writing to a shared variable.<BR>
|
||||
</P>
|
||||
|
||||
<P>As an example, if a user created two new threads, called A and B, and
|
||||
then evaluated: </P>
|
||||
|
||||
<P><TT><FONT FACE="Courier New">First thread></FONT></TT> <I>(define
|
||||
x 7)</I> </P>
|
||||
|
||||
<P><I>(define (f) ...)</I> </P>
|
||||
|
||||
<P><TT><FONT FACE="Courier New">Thread A></FONT></TT> <I>(define (g)
|
||||
x)</I> </P>
|
||||
|
||||
<P><TT><FONT FACE="Courier New">Thread B></FONT></TT> <I>(define x 4)</I>
|
||||
</P>
|
||||
|
||||
<P>this is how the environment model would look like:<BR>
|
||||
</P>
|
||||
|
||||
<CENTER><P><IMG border=0 SRC="img00001.gif" HEIGHT=407 WIDTH=654><BR>
|
||||
</P></CENTER>
|
||||
|
||||
<P>Now consider what happens when the user evaluates this: </P>
|
||||
|
||||
<P><TT><FONT FACE="Courier New">Thread A></FONT></TT> <I>(set! f g)</I>
|
||||
</P>
|
||||
|
||||
<CENTER><P><IMG border=0 SRC="img00002.gif" HEIGHT=431 WIDTH=692><BR>
|
||||
<BR>
|
||||
</P></CENTER>
|
||||
|
||||
<P>Now, evaluating <I>(f)</I> in thread B will call the function defined
|
||||
in thread A. It will return 12 which is the value of x in f's environment.
|
||||
If thread A defines a new x (using <B>define</B>), it will affect the result
|
||||
of subsequent calls to f.<BR>
|
||||
</P>
|
||||
|
||||
<P>Sharing environments and frames are Galapagos's way of allowing shared
|
||||
data. By default, however, most calculations are done at thread-specific
|
||||
frames. (More on this subject in the next section). Primitives are supplied
|
||||
to explicitly reference and manage environments: <B>clone-environment</B>
|
||||
can create a copy of an environment (so changing a binding in one copy
|
||||
does not alter the other); <B>extend-environment</B> and <B>pop-environment</B>
|
||||
can add and remove frames to and from environments. More environment functions
|
||||
are found in the next section of this document.<BR>
|
||||
</P>
|
||||
|
||||
<H2><A NAME="THREADS"></A>THREADS<BR>
|
||||
</H2>
|
||||
|
||||
<P>A thread is a SCHEME interpreter. The <I>base environment</I> of a thread
|
||||
is the thread's topmost environment. All forms entered at the thread's
|
||||
console or as arguments to <B>new-thread</B> are evaluated in the base
|
||||
environment. In traditional SCHEME there is only one thread of execution.
|
||||
It is a single thread and its base environment is the global environment.
|
||||
In Galapagos many interpreters can run concurrently, and each have its
|
||||
own environment (changing dynamically as computation progresses) and a
|
||||
base environment (which can be explicitly changed).<BR>
|
||||
</P>
|
||||
|
||||
<P>One thread is created by Galapagos upon startup. It is called the <I>main
|
||||
thread</I>, and it lasts for the whole Galapagos session. Its base environment
|
||||
is the global one - much like a traditional Scheme interpreter. Additional
|
||||
threads can be created using <B>new-thread</B>. These have their base environment
|
||||
set to a new environment, containing a single fresh frame pointing to the
|
||||
global environment. Any calculation done at the new thread's console takes
|
||||
place in this thread-local environment. However, if closure functions are
|
||||
used, then their evaluation may take place at the global environment or
|
||||
at some other thread's space, depending on where that function was defined.
|
||||
<BR>
|
||||
</P>
|
||||
|
||||
<P>When a thread finishes the execution of its commands it terminates.
|
||||
There are two exceptions to this rule: </P>
|
||||
|
||||
<OL>
|
||||
<LI>The main thread can be only terminated by using <B>quit-program</B>.
|
||||
</LI>
|
||||
|
||||
<LI>A thread that is bound to the console will not terminate at the end
|
||||
of execution but will wait for the next command input. </LI>
|
||||
</OL>
|
||||
|
||||
<P>Threads can communicate using the predicate <B>tell-thread</B> or by
|
||||
using the asynchronous message-queues system described later. In addition,
|
||||
SCM's <B><I>arbiters</I></B> were improved to be multithread safe. An arbiter
|
||||
object can serve as a guard on a critical section (where only one thread
|
||||
can work at a given time) of the program. The relevant primitves are <B>make-arbiter</B>,<B>
|
||||
try-arbiter</B>, and <B>release-arbiter</B>. <BR>
|
||||
</P>
|
||||
|
||||
<P>Note: Galapagos supports Scheme's notation of <B><I>continuations</I></B>.
|
||||
However, two restrictions apply: </P>
|
||||
|
||||
<OL>
|
||||
<LI>Only "cheap" continuations are supported. That is, a continuation
|
||||
can only be called when it is still active. This allows for continuations
|
||||
to be used to implement exception handling, etc. </LI>
|
||||
|
||||
<LI>Continuations can not cross thread boundaries. Also continuations,
|
||||
like any other Scheme object, can be handled by any thread, they can only
|
||||
be called from within the thread that created them. Trying to call a continuation
|
||||
from a different thread will cause an error. </LI>
|
||||
</OL>
|
||||
|
||||
<H2><A NAME="CONSOLES"></A>CONSOLES<BR>
|
||||
</H2>
|
||||
|
||||
<P>A <I>console</I> is a text window where the user can type commands (when
|
||||
the interpreter is idle) and see output. A console has a name which can
|
||||
be changed dynamically, which appears on its title bar. A thread may or
|
||||
may not be bound to a console. Information printed by a non-bound thread
|
||||
is lost; a non-bound thread waiting for input is stuck (unless provisions
|
||||
were made to allow a new console to be created by means of inter-thread
|
||||
communications.) If a non-bound thread has nothing to do, instead of waiting
|
||||
for input like a bound thread, it will terminate.<BR>
|
||||
</P>
|
||||
|
||||
<P>The main thread is always bound to a console. To bind a thread to a
|
||||
console use the command <B>bind-to-console</B> from within the thread.<BR>
|
||||
</P>
|
||||
|
||||
<H2><A NAME="DRAWING"></A>DRAWING BOARDS<BR>
|
||||
</H2>
|
||||
|
||||
<P>A board (window) is the graphical board on which the turtles and the
|
||||
user draw. It is a bitmap on which the user can draw interactively, by
|
||||
using the supplied GUI, or by creating turtles and instructing them to
|
||||
do the drawings.<BR>
|
||||
</P>
|
||||
|
||||
<P>The controls of the graphical user interface are located on the toolbar.
|
||||
The "shapes" of drawing are either a rectangle, a line or free
|
||||
hand drawing. The user pen can have three widths which are found under
|
||||
the <B>User Pen</B> menu. The numbers next to the sizes are the widths
|
||||
in pixels.<BR>
|
||||
</P>
|
||||
|
||||
<P>The colors of the user pen can be changes either from the <B>User Pen
|
||||
</B>menu or from the toolbar's color buttons. When choosing from a toolbar
|
||||
button, the user can know exactly what color (in RGB format) is used. <BR>
|
||||
</P>
|
||||
|
||||
<P>Each window has a name which is written on its title bar which can be
|
||||
changed using the <B>rename-window!</B> command. The board can be cleaned
|
||||
from all drawings using the <B>clear-window </B>command. <BR>
|
||||
</P>
|
||||
|
||||
<P>Since the board is a bitmap it can be saved to a BMP file using the
|
||||
<B>save-bitmap</B> command. A new background from a bitmap file can be
|
||||
loaded using the <B>load-bitmap</B> command.<BR>
|
||||
</P>
|
||||
|
||||
<H2><A NAME="TURTLES"></A>TURTLES<BR>
|
||||
</H2>
|
||||
|
||||
<P>A turtle is an object which is connected to a certain board. Each turtle
|
||||
has a pen with which it can draw on that board. The user can change the
|
||||
state of the turtle's pen including giving it the color of the board's
|
||||
background color (using the <B>pen-erase! </B>command). The pen will draw
|
||||
when it is "down" and will not draw when it is "up".
|
||||
Turtles can move between boards using the <B>move-turtle-to-window</B>
|
||||
command.<BR>
|
||||
</P>
|
||||
|
||||
<P>Each turtle holds its location as the a pair of coordinates where 0,0
|
||||
is the upper left corner of the board and 800,600 is the bottom-right corner
|
||||
of the board. The turtle's location can be changed by giving the turtle
|
||||
commands such as <B>forward!, backwards!, move-to!</B> or by using the
|
||||
move button from the toolbar.<BR>
|
||||
</P>
|
||||
|
||||
<P>A turtle also has a heading which is the direction it will move on the
|
||||
<B>forward!</B> command. The heading is in degrees, 0 meaning upwards and
|
||||
increasing clockwise, thus 90 means rightwards and so on. A turtle's heading
|
||||
can be changed by commands such as <B>right!, left!, </B>and<B> set-heading!</B>
|
||||
or interactively, by using the move button on the toolbar and pressing
|
||||
the control key.<BR>
|
||||
</P>
|
||||
|
||||
<P>A turtle can be visible on the board or be hidden. When it is visible
|
||||
the user can decide if it wants a "solid" or "hollow"
|
||||
turtle using the <B>make-hollow! </B>and <B>make-solid!</B> commands.<BR>
|
||||
</P>
|
||||
|
||||
<P>A turtle is always connected to a certain board, which is the board
|
||||
it is drawing on. To create a new turtle on a board use the <B>make-turtle</B>
|
||||
or the <B>clone-turtle</B> commands. A new turtle (created with the <B>make-turtle</B>
|
||||
command) will be black, solid, heading north and with it's pen down, in
|
||||
the center of the board. A cloned turtle will have exactly the same inner
|
||||
state as its parent.<BR>
|
||||
</P>
|
||||
|
||||
<P>A turtle can also look at the board and see other turtles or colors.
|
||||
By using the command <B>look</B> the user can tell the turtle the area
|
||||
in which to look and what to look in this area. </P>
|
||||
|
||||
<P>Example: </P>
|
||||
|
||||
<P>The command </P>
|
||||
|
||||
<P><I>(look t 50 20 '(0 0 0))</I> </P>
|
||||
|
||||
<P>will cause the turtle <I>t</I> to look for black pixels in the area
|
||||
in radius 50 from the turtle and 20 degrees to each side of the heading
|
||||
line, shown here in blue: </P>
|
||||
|
||||
<CENTER><P><IMG border=0 SRC="img00003.gif" HEIGHT=75 WIDTH=48><BR>
|
||||
</P></CENTER>
|
||||
|
||||
<H2><A NAME="INTERRUPTS (NOTIFICATIONS) AND MESSAGE"></A>INTERRUPTS (NOTIFICATIONS)
|
||||
AND MESSAGE HANDLERS<BR>
|
||||
</H2>
|
||||
|
||||
<P>A turtle can have interrupts. Each interrupt is defined in terms of
|
||||
turtle's vision. Whenever a turtle starts or stops seeing a given target,
|
||||
a predefined message is sent to the thread which asked the interrupt. The
|
||||
user can determine if the interrupt will notify on every change (like a
|
||||
"can see"- "can't see" toggle) or only when one change
|
||||
happens (only "can see" or "can't see" toggle). A message
|
||||
can be any valid SCHEME object.<BR>
|
||||
</P>
|
||||
|
||||
<P>Example: </P>
|
||||
|
||||
<P>The command </P>
|
||||
|
||||
<P><I>(turtle-notify t "I-see" "I-don't-see" 50 20
|
||||
color-black)</I> </P>
|
||||
|
||||
<P>tells the turtle <I>t</I> that every time it sees the color black it
|
||||
should send the message <I>"I-see"</I> and when it doesn't see
|
||||
the color black any more it should send the message <I>"I-don't-see"</I>.
|
||||
</P>
|
||||
|
||||
<P>Below is an example of what messages (or no message) <I>t </I>will send
|
||||
while it is moving forward, encountering two black lines on its way:<BR>
|
||||
<BR>
|
||||
<BR>
|
||||
<IMG border=0 SRC="vision.gif" HEIGHT=183 WIDTH=669></P>
|
||||
|
||||
<P><BR>
|
||||
<BR>
|
||||
If the interrupt was of kind "can see" (<B>notify-when</B> command)
|
||||
only the <I>"I-see"</I> messages were sent, and if it was a the
|
||||
"can't see" interrupt (<B>notify-when-not</B> command) only the
|
||||
<I>"I-can't-see" </I>style messages were sent.<BR>
|
||||
</P>
|
||||
|
||||
<P>A special "user interrupt" is invoked when the user right-clicks
|
||||
the turtle or a window. The <B>notify-on-click</B> command is used to enable
|
||||
this.<BR>
|
||||
</P>
|
||||
|
||||
<P>A thread can tell the turtle to delete a certain interrupt using the
|
||||
<B>turtle-no-notify</B> command. It can also tell the turtle to disable
|
||||
all interrupts using the <B>stop-notifying</B> command. <BR>
|
||||
</P>
|
||||
|
||||
<P>In order to process the messages sent from a turtle's interrupt (or
|
||||
from another thread, as presented later) the thread must install a <I>message
|
||||
handler</I> which is a one argument function. If no handler is installed
|
||||
the turtle's messages are lost. There can be only one handler per thread.
|
||||
If the handler is installed then every time an interrupt is invoked, the
|
||||
handler function in called with the message sent by the interrupt as its
|
||||
argument. <BR>
|
||||
<BR>
|
||||
</P>
|
||||
|
||||
<P>Example: </P>
|
||||
|
||||
<P>We declare the function: </P>
|
||||
|
||||
<P><I>(define (my-print x) (write x) (newline))</I> </P>
|
||||
|
||||
<P>and then install <I>my-print</I> as the current handler with: </P>
|
||||
|
||||
<P><I>(install-handler my-print)</I> </P>
|
||||
|
||||
<P>from now on every message a turtle's interrupt sends will be printed
|
||||
on screen. If <I>my-print</I> was installed in the previous example then
|
||||
we would have seen: <BR>
|
||||
</P>
|
||||
|
||||
<P><I>"I-see"</I> </P>
|
||||
|
||||
<P><I>"I-don't-see"</I> </P>
|
||||
|
||||
<P><I>"I-see"</I><BR>
|
||||
</P>
|
||||
|
||||
<P>on the screen.<BR>
|
||||
</P>
|
||||
|
||||
<P>A good example to view the interrupts in action is to make a turtle
|
||||
turn each time it sees a color and then let it wander aimlessly. Then use
|
||||
the user pen to draw lines the turtle's way and watch it change direction.
|
||||
See the PINGPONG.SCM file for a demo program. <BR>
|
||||
</P>
|
||||
|
||||
<P>The message-handler concept can be used as a mean of synchronous inter-thread
|
||||
communications. The tell-thread functions sends a message to a thread,
|
||||
which will be treated as an interrupt-generated message: It will cause
|
||||
the thread's message handler function to be called with tell-thread's argument
|
||||
as its own. This allows one thread to initiate a computation in a different
|
||||
thread's environment and CPU space synchronously and without sharing environments.
|
||||
<BR>
|
||||
</P>
|
||||
|
||||
<H2><A NAME="MESSAGE"></A>MESSAGE QUEUES<BR>
|
||||
</H2>
|
||||
|
||||
<P>In order to let threads communicate between themselves asynchronously
|
||||
a system of message queues was developed. A queue is an object which stores
|
||||
and relieves messages, stored in FIFO (First In First Out) style, meaning
|
||||
messages are read in the order of arrival to the queue. Supported messages
|
||||
are pairs of type and body, both of which can be any valid SCHEME object.
|
||||
Looking for messages of a certain type is also supported, allowing implementation
|
||||
of more flexible communication schemes than plain FIFO.<BR>
|
||||
</P>
|
||||
|
||||
<P>A thread can check if there are any messages in a given queue, if it
|
||||
does <B>get-message</B> without checking first if there are messages in
|
||||
the queue it will wait a given time-out or forever if no time-out is given.
|
||||
If by the end of the time-out no message were in the queue the result will
|
||||
be false.<BR>
|
||||
</P>
|
||||
|
||||
<P>Example: </P>
|
||||
|
||||
<P>In this example a queue <I>q</I> is created then a message is posted
|
||||
into the queue and read from it.<BR>
|
||||
</P>
|
||||
|
||||
<P><I>(define q (make-queue))</I> </P>
|
||||
|
||||
<P><I>(post-message q (cons 'type-circus 'bozo-the-clown))</I> </P>
|
||||
|
||||
<P><I>(define msg (get-message q))</I><BR>
|
||||
</P>
|
||||
|
||||
<P>now the command </P>
|
||||
|
||||
<P><I>(car msg) </I></P>
|
||||
|
||||
<P>will give </P>
|
||||
|
||||
<P><I>type-circus</I> </P>
|
||||
|
||||
<P>and the command </P>
|
||||
|
||||
<P><I>(cdr msg) </I></P>
|
||||
|
||||
<P>will yield </P>
|
||||
|
||||
<P><I>bozo-the-clown</I>. </P>
|
||||
|
||||
|
||||
<P>
|
||||
<HR width=80% align=left color=blue>
|
||||
<CENTER>
|
||||
<A href="#top"><IMG border=0 src=back.gif ALT=" [TOP] "></A>
|
||||
<A href="background.html"><IMG border=0 src=prev.gif ALT=" [PREV] "></A>
|
||||
<A href="gui.html"><IMG border=0 src=next.gif ALT=" [PREV] "></A>
|
||||
<A href="index.html#toc"><IMG border=0 src=toc.gif ALT=" [PREV] "></A>
|
||||
</CENTER>
|
||||
</BODY>
|
||||
</HTML>
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,73 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
||||
<HTML>
|
||||
<HEAD>
|
||||
<TITLE>Galapago - GUI</TITLE>
|
||||
<META NAME="Author" CONTENT="">
|
||||
<META NAME="GENERATOR" CONTENT="Mozilla/3.01Gold (Win95; I) [Netscape]">
|
||||
</HEAD>
|
||||
<BODY background=stone.jpg>
|
||||
|
||||
<CENTER>
|
||||
<A href="extensions.html"><IMG border=0 src=prev.gif ALT=" [PREV] "></A>
|
||||
<A href="implementation.html"><IMG border=0 src=next.gif ALT=" [PREV] "></A>
|
||||
<A href="index.html#toc"><IMG border=0 src=toc.gif ALT=" [PREV] "></A>
|
||||
</CENTER>
|
||||
<HR width=80% align=right color=blue>
|
||||
<P>
|
||||
|
||||
<H1 ALIGN=CENTER><A NAME="top"></A>THE INTERACTIVE GUI</H1>
|
||||
<HR>
|
||||
<P>In order to make Galapagos more fun to learn with, an interactive GUI
|
||||
(Graphical User Interface) is provided. Users can make changes on the board
|
||||
while a computation is in progress and effect its execution. Drawing tools
|
||||
enable the user to draw on the board while a program is being executed.
|
||||
If a line is drawn in front of a turtle which has a relevant interrupt,
|
||||
the interrupt will be invoked if needed.<BR>
|
||||
</P>
|
||||
|
||||
<P>The user has a special <I>user pen</I> that can draw line, rectangles
|
||||
or free hand. These modes are available from the toolbar. The User's pen
|
||||
width and color can be modified using the User Pen menu or the toolbar.<BR>
|
||||
</P>
|
||||
|
||||
<P>Color buttons are provided on the toolbar to give a known RGB color
|
||||
to the user pen. It is useful when the user draw an object on the board
|
||||
and wants a turtle to see this object. The colors are: </P>
|
||||
|
||||
<P>White - (255 255 255) </P>
|
||||
|
||||
<P>Black - (0 0 0) </P>
|
||||
|
||||
<P><FONT COLOR="#0000FF">Blue</FONT> - (0 0 255) </P>
|
||||
|
||||
<P><FONT COLOR="#FF0000">Red</FONT> - (255 0 0) </P>
|
||||
|
||||
<P><FONT COLOR="#00FF00">Green</FONT> - (0 255 0) </P>
|
||||
|
||||
<P><FONT COLOR="#FFFF00">Yellow</FONT> - (255 255 0)<BR>
|
||||
</P>
|
||||
|
||||
<P>Another option available is changing a turtle's heading and position,
|
||||
using the Move Turtle button: </P>
|
||||
|
||||
<CENTER><P><IMG border=0 SRC="img00010.gif" HEIGHT=33 WIDTH=37><BR>
|
||||
</P></CENTER>
|
||||
|
||||
<P>If this button is pressed then a turtle can be dragged to a new location
|
||||
simply by dragging it with the mouse. In order to change the turtle's heading,
|
||||
hold down a control key and move the move towards the desired location,
|
||||
the turtle will follow the movement of the mouse. </P>
|
||||
|
||||
<P>
|
||||
<HR width=80% align=left color=blue>
|
||||
<CENTER>
|
||||
<A href="#top"><IMG border=0 src=back.gif ALT=" [TOP] "></A>
|
||||
<A href="extensions.html"><IMG border=0 src=prev.gif ALT=" [PREV] "></A>
|
||||
<A href="implementation.html"><IMG border=0 src=next.gif ALT=" [PREV] "></A>
|
||||
<A href="index.html#toc"><IMG border=0 src=toc.gif ALT=" [PREV] "></A>
|
||||
</CENTER>
|
||||
</BODY>
|
||||
</HTML>
|
||||
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,393 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
||||
<HTML>
|
||||
<HEAD>
|
||||
<TITLE>Galapagos - Implementation</TITLE>
|
||||
<META NAME="Author" CONTENT="">
|
||||
<META NAME="GENERATOR" CONTENT="Mozilla/3.01Gold (Win95; I) [Netscape]">
|
||||
</HEAD>
|
||||
<BODY background=stone.jpg>
|
||||
|
||||
<CENTER>
|
||||
<A href="gui.html"><IMG border=0 src=prev.gif ALT=" [PREV] "></A>
|
||||
<A href="manual.html"><IMG border=0 src=next.gif ALT=" [PREV] "></A>
|
||||
<A href="index.html#toc"><IMG border=0 src=toc.gif ALT=" [PREV] "></A>
|
||||
</CENTER>
|
||||
<HR width=80% align=right color=blue>
|
||||
<P>
|
||||
|
||||
<H1 ALIGN=CENTER><A NAME="top"></A>IMPLEMENTATION</H1>
|
||||
|
||||
<UL>
|
||||
<LI><A HREF="implementation.html#GARBAGE">Garbage Collection</A></LI>
|
||||
<LI><A HREF="implementation.html#BOARDS">Boards</A></LI>
|
||||
<LI><A HREF="implementation.html#TURTLES">Turtles</A></LI>
|
||||
<LI><A HREF="implementation.html#VISION">Vision</A></LI>
|
||||
<LI><A HREF="implementation.html#INTERRUPTS">Interrupts</A></LI>
|
||||
<LI><A HREF="implementation.html#CLASS">Class Organization</A></LI>
|
||||
</UL>
|
||||
|
||||
<HR>
|
||||
<P>Galapagos was written using Microsoft Visual C++, and is designed to
|
||||
run under Windows 95. We chose Windows 95 because it seems to have the
|
||||
largest potential Galapagos users base. The following sections describe
|
||||
some implementation details of Galapagos.<BR>
|
||||
</P>
|
||||
|
||||
<P>The SCM interpreter we used as a base is written in C. Most of the original
|
||||
code we added was written in C++. The parts we used from SCM are almost
|
||||
identical to the original. In fact, by changing the scmconfig.h file (which
|
||||
contain machine-specific configuration) and #defining THREAD to be null,
|
||||
the C files should become equivalent to the sources we used.<BR>
|
||||
</P>
|
||||
|
||||
<P>We have implemented two MT-safe FIFO message queue classes. Both will
|
||||
block when trying to read from an empty queue. <B>CMsgQx</B>, the extended
|
||||
message queue, supports the same interface as the one provided in Scheme,
|
||||
plus an additional support for "Urgent Messages". These take
|
||||
precedence over all other messages. <B>CMessageQueue</B> is message queue
|
||||
with exactly the same interface as the Scheme level message queues, but
|
||||
which contain internal logic to handle "Urgent" messages used
|
||||
to deal with cases where synchronous respond is needed, such as I/O, Garbage
|
||||
collection, and Scheme-level inter-thread communications. <BR>
|
||||
</P>
|
||||
|
||||
<H2><A NAME="FITTING SCM INTO"></A>FITTING SCM INTO WINDOWS<BR>
|
||||
</H2>
|
||||
|
||||
<P>Galapagos is based on SCM, which is a single-thread, read-evaluate-print-loop
|
||||
(repl) based Scheme interpreter. The most important issue in migrating
|
||||
SCM was how to maintain the interpreter's natural repl-based approach,
|
||||
yet allow for multiple threads to interact, and for Windows messages to
|
||||
be processed quickly.<BR>
|
||||
</P>
|
||||
|
||||
<P>We used WIN32's multithreading capabilities to solve these problems.
|
||||
A single thread handles all aspects of the GUI - in a sense, "all
|
||||
that is Windows": graphic boards, turtles, consoles, menus and so
|
||||
on. Each interpreter runs in a thread of its own, interacting with the
|
||||
GUI using a message queue similar to the one provided at the Scheme level.<BR>
|
||||
</P>
|
||||
|
||||
<CENTER><P><IMG border=0 SRC="img00011.gif" HEIGHT=182 WIDTH=530><BR>
|
||||
</P></CENTER>
|
||||
|
||||
<P>The GUI thread manages both commands received from the OS and from the
|
||||
different interpreters running on their own threads. To ensure as fast
|
||||
responses as possible, priorities are used: OS messages (such as windows
|
||||
updates and input devices) gets highest priority; Console (text messages)
|
||||
come second, and graphics messages are last. This allows the interpreters
|
||||
to run interactively in a satisfactory manner. <BR>
|
||||
</P>
|
||||
|
||||
<P>SCM interpreter threads each run in the old-fashion repl mode. When
|
||||
a computation is over, the interpreter blocks until new input comes from
|
||||
the GUI thread. All blocking functions were modified to allow synchronous
|
||||
messages (such as the one generated by <B>tell-thread</B>) to work. In
|
||||
addition, SCM's "poll routine" is used to force checking for
|
||||
such messages even during computations.<BR>
|
||||
</P>
|
||||
|
||||
<P>An additional thread is used for Garbage Collection. It is described
|
||||
in detail in the section dealing with garbage collection.<BR>
|
||||
</P>
|
||||
|
||||
<H2><A NAME="GARBAGE"></A>GARBAGE COLLECTION</H2>
|
||||
|
||||
<P>In this section we will briefly describe SCM's garbage collector, and
|
||||
then discuss the modifications done to adapt it to Galapagos's multithreading
|
||||
computations. It should be noted that the garbage collector used is a portable
|
||||
garbage collector taken from "SCHEME IN ONE DEFUN, BUT IN C THIS TIME",
|
||||
by George J Carrette <gjc@world.std.com>. <BR>
|
||||
</P>
|
||||
|
||||
<P>SCM uses a conservative Mark & Sweep garbage collector (GC). All
|
||||
Scheme data objects share some common configuration (called "cells"):
|
||||
They are 8-byte aligned; they reside is specially-allocated memory segments
|
||||
(called hplims); they are the size of two pointers (so a scheme cons is
|
||||
exactly a cell); and they contain a special GC bit used by the garbage
|
||||
collector. This bit is 0 during actual computations. When a new cell is
|
||||
needed and all the hplims are used, garbage collection is initiated. If
|
||||
it does not free enough space to pass a certain threshold, a new hplim
|
||||
is allocated.<BR>
|
||||
</P>
|
||||
|
||||
<P>The first stage in garbage collection is marking all cells which are
|
||||
not to be deleted. Some terminology might be helpful here: <BR>
|
||||
</P>
|
||||
|
||||
<UL>
|
||||
<LI>A cell (or any data object) is called <B><I>alive</I></B> if it may
|
||||
in some way influence the future of the computation. Needless to say, discovering
|
||||
which cells are alive and which are not is impossible, because of the very
|
||||
nature of the future. </LI>
|
||||
</UL>
|
||||
|
||||
<UL>
|
||||
<LI>A cell is called <B><I>reachable</I></B> if the computation can read
|
||||
its value. Some data is <I>immediately reachable</I>: The data on the machine's
|
||||
stack or in the CPU registers, for example; some interpreters store some
|
||||
information in a fixed location so it's permanently reachable. In SCM the
|
||||
array <TT><FONT FACE="Courier New">sys_protects[]</FONT></TT> is used for
|
||||
this propose. The set of reachable cells is the union of all immediately
|
||||
reachable cells, and all those cells pointed by reachable cells, recursively.
|
||||
</LI>
|
||||
</UL>
|
||||
|
||||
<P>Obviously, all unreachable data is dead. Conservative garbage collectors
|
||||
treat all reachable data as alive. <BR>
|
||||
</P>
|
||||
|
||||
<P>The Mark stage of the garbage collector scans the <TT><FONT FACE="Courier New">sys_protects[]</FONT></TT>
|
||||
array and the machine's stack and registers for anything that looks like
|
||||
a valid cell. All cell pointer have their 3 least significant bits zero,
|
||||
and are in one of few known ranges (the hplims). The garbage collector
|
||||
searches for anything matching a cell's bit pattern, and treats it as an
|
||||
immediately reachable cell pointer. In some cases, this may mean an integer,
|
||||
for example, happens to match the binary pattern and thus be interpreted
|
||||
as a cell pointer. However, this will only mean some cell or cells are
|
||||
marked as reachable though they are not such. Because of the uniform structure
|
||||
of the cell and its limited range of possible locations, such an accident
|
||||
is guarantied not to corrupt memory. Furthermore, if we accept the assumption
|
||||
that integers are usually relatively small, and memory addresses are relatively
|
||||
big, we conclude that such accidents are not very likely to happen often
|
||||
anyway.<BR>
|
||||
</P>
|
||||
|
||||
<P>During mark stage, the garbage collector recursively finds (a superset
|
||||
of) all live cells, and marks them by setting their special GC bit to 1.
|
||||
The second stage is the Sweep stage, in which all the hplims are scanned
|
||||
linearly, and every cell which is not marked is recognized as dead, and
|
||||
as such is reclaimed as free. Marked cells get unmarked so they are ready
|
||||
for the next garbage collection. <BR>
|
||||
</P>
|
||||
|
||||
<P>Mark & Sweep garbage collection has two main disadvantages: One,
|
||||
that it requires all computation to stop while garbage collection is in
|
||||
progress. In Galapagos, since all threads use a shared memory heap, it
|
||||
means all threads must synchronize and halt while garbage is collected.
|
||||
Second, Mark & Sweep is very likely to cause memory fragmentation.
|
||||
However, since cells are equally sized, fragmentation is only rarely a
|
||||
problem.<BR>
|
||||
</P>
|
||||
|
||||
<P>We chose to stick with Mark & Sweep in Galapagos because of its
|
||||
two major advantages: Simplicity and efficiency. Mark & Sweep GC does
|
||||
not affect computation speed, because direct pointers are used. Most concurrent
|
||||
garbage collectors work by making all pointers indirect, which may slow
|
||||
computations down considerably. The need to halt all threads for GC is
|
||||
accepted. Since memory is shared, it would only be fair to stop all threads
|
||||
when GC is needed: Threads will probably halt anyway since cells are allocated
|
||||
continuously during computations.<BR>
|
||||
</P>
|
||||
|
||||
<P>Two major issues are introduced when trying to multithread the garbage
|
||||
collector. One is the synchronization of the different threads, which run
|
||||
almost completely unaware one of the other; the second is the need to mark
|
||||
data from every thread's specific stack, registers, and <TT><FONT FACE="Courier New">sys_protects[]</FONT></TT>.
|
||||
We solved these two issues by combining them to one.<BR>
|
||||
</P>
|
||||
|
||||
<P>The intuitive approach might be to let each thread mark its own information,
|
||||
and then sweep centrally. However, since synchronization of threads is
|
||||
mandatory, letting every thread mark its own data will lead only to redundant
|
||||
marking and to excessive context switches, since each threads has to become
|
||||
active. Therefore we created the "<B>Garbage Collection daemon</B>"
|
||||
(GCd), which runs in a distinct thread and lasts for the whole Galapagos
|
||||
session. The GCd is not an interpreter, but a mechanism which keeps track
|
||||
of live threads and their need of GC. The GCd thread is always blocked,
|
||||
except when a thread notifies it on its birth or death, or when a thread
|
||||
indicates the need for garbage collection. Since the GC daemon is blocked
|
||||
whenever it is not needed, and then becomes the exclusive running thread
|
||||
during actual GC (with the exception of the GUI thread), its existence
|
||||
does not hurt performance. <BR>
|
||||
</P>
|
||||
|
||||
<P>To explain how the GCd synchronizes all threads, let us examine the
|
||||
three-way protocol involved. <TT><FONT FACE="Courier New">freelist</FONT></TT>
|
||||
is a global pointer which holds a linked list of free cells - it can be
|
||||
either a cell pointer, a value indicating "busy" (thus implementing
|
||||
busy/wait protection over it) or "end of memory" which is found
|
||||
at the end of the linked list. MIB stands for <B><I>Memory Information
|
||||
Block</I></B>, which is a block of memory containing all of a thread's
|
||||
immediately reachable data.<BR>
|
||||
</P>
|
||||
|
||||
<P><B><U>GCd scenario:</U></B> GCd is blocked until a threads sends a GC
|
||||
request. </P>
|
||||
|
||||
<OL>
|
||||
<LI>GCd scans through its list of active threads, and sends each a <I>MIB
|
||||
request</I>. </LI>
|
||||
|
||||
<LI>It then blocks until all MIB blocks are received. GCd ignores further
|
||||
GC request messages it get. </LI>
|
||||
|
||||
<LI>At this point all threads are blocked. The GCd has gained, therefore,
|
||||
exclusive access to the hplims. The GCd now marks all reachable cells,
|
||||
inspecting each MIB block for immediately reachable cells and proceeding
|
||||
recursively. Then, it sweeps. </LI>
|
||||
|
||||
<LI>If needed, the GCd allocated a fresh hplim. </LI>
|
||||
|
||||
<LI>GCd sends every thread a message allowing it to resume. Then it blocks
|
||||
waiting for the next time. </LI>
|
||||
</OL>
|
||||
|
||||
<P><B><U>Scenario 1:</U></B> A thread needs to allocate a cell but can't.
|
||||
</P>
|
||||
|
||||
<OL>
|
||||
<LI>The thread sends GCd a<I> GC request message.</I> </LI>
|
||||
|
||||
<LI>Then it suspends until GCd sends it an <I>MIB request</I>. </LI>
|
||||
|
||||
<LI>When one arrives, the thread generates and sends a MIB block to the
|
||||
GCd. </LI>
|
||||
|
||||
<LI>And blocks again until GCd notifies it that GC is done. </LI>
|
||||
|
||||
<LI>At this point free cells are available and the computation can resume.
|
||||
</LI>
|
||||
</OL>
|
||||
|
||||
<P><B><U>Scenario 2:</U></B> A thread receives a<I> MIB request</I>. This
|
||||
may happen within a computation or when considered otherwise blocked -
|
||||
waiting for input, for example. </P>
|
||||
|
||||
<OL>
|
||||
<LI>The thread generates and sends a MIB block to the GCd. </LI>
|
||||
|
||||
<LI>And blocks until GCd notifies it that GC is done. </LI>
|
||||
</OL>
|
||||
|
||||
<P>The important thing to note about this protocol is its indifference
|
||||
to the GC "initiator". Several threads can "initiate"
|
||||
GC, and each request is "satisfied", although of course only
|
||||
one GC takes place. The GCd itself is unaware of the initiating thread
|
||||
identity, and completely ignores any further GC requests. It treats all
|
||||
threads identically. This is important because it allows each thread meeting
|
||||
a low memory condition to initiate GC immediately. This is in fact the
|
||||
mechanism which saves us from explicitly checking for a third-party GC
|
||||
request during computation: If a thread runs out of memory, the <TT><FONT FACE="Courier New">freelist</FONT></TT>
|
||||
variable is kept at "out of memory" state, causing any other
|
||||
thread trying to allocate memory to initiate GC as well. This simplifies
|
||||
the GC protocol (technically, if not conceptually), and does it with almost
|
||||
no affect on computation speed.<BR>
|
||||
</P>
|
||||
|
||||
<H2><A NAME="BOARDS"></A>BOARDS<BR>
|
||||
</H2>
|
||||
|
||||
<P>A board or a view as it called in MFC is the environment where a turtle
|
||||
moves and interact with. It hold two main data structures. The first is
|
||||
the bitmap of the drawing. It is a 800X600 bitmap. Every time a turtle
|
||||
draws on the board it makes its pen the active pen on the board and draws
|
||||
on it. Every time the picture needs refreshing (as signaled by the operating
|
||||
system) it is the board's duty to copy the relevant section from the bitmap
|
||||
to the screen. The second data object is the turtles list, an expandable
|
||||
array of turtles which holds pointers to all turtles on the specific board.<BR>
|
||||
</P>
|
||||
|
||||
<P>The most important part in the board's work is to notify the turtles
|
||||
on any event that happened on the board such as drawing, changing background
|
||||
or moving of a turtle. If for example a user draws a line on the board,
|
||||
the board (after drawing the line) goes through the turtles list and tell
|
||||
each one that some event happened at a rectangle that contains the line.
|
||||
Each turtle will decide if this has any importance to it or not.<BR>
|
||||
</P>
|
||||
|
||||
<P>Apart from that, the board handles all the user interface from the menus
|
||||
and the toolbar. The most obvious example is the move turtle button, which,
|
||||
when pressed, causes the board to find a turtle close enough to the click's
|
||||
location. Then, on every movement of the mouse it gives the turtle a command
|
||||
to move to this point. <BR>
|
||||
</P>
|
||||
|
||||
<P>In order to support scrolling of the picture, we derived the <B>CBoardView</B>
|
||||
class from <B>CScrollView</B>. The interface with the interpreter threads
|
||||
is done via a message queue. The main function is <TT><FONT FACE="Courier New">ReadAndEval,</FONT></TT>
|
||||
which gets a message and then interprets its and act upon the result.<BR>
|
||||
</P>
|
||||
|
||||
<H2><A NAME="TURTLES"></A>TURTLES<BR>
|
||||
</H2>
|
||||
|
||||
<P>In addition to a pointer to its current board, and to inner-state variable
|
||||
which affects its graphical aspects, every turtle holds an expandable array
|
||||
of interrupts. When a turtle gets from the window that a message signifying
|
||||
that some change has happened, it sends this change to each of its interrupts
|
||||
(only if the interrupt flag is on) and the interrupt is responsible to
|
||||
send an appropriate message if necessary. The turtle's location are stored
|
||||
as floating points on x,y axes, to allow for accuracy on the turtle's location
|
||||
and heading.<BR>
|
||||
</P>
|
||||
|
||||
<P>The turtles interacts with the interpreter thread using a message queue.
|
||||
As with the board, the main function here is the <TT><FONT FACE="Courier New">ReadAndEval,</FONT></TT>
|
||||
which translates these messages to valid function calls.<BR>
|
||||
</P>
|
||||
|
||||
<H2><A NAME="VISION"></A>VISION<BR>
|
||||
</H2>
|
||||
|
||||
<P>Every turtle holds a pointer to the bitmap it is drawing on. When it
|
||||
is "looking" for a color it calculates the minimal rectangle
|
||||
that holds the desired area. Then it iterates on all the pixels in this
|
||||
rectangle. First it checks if the pixel is in the vision area using the
|
||||
sign rule to determine if a point is clockwise or anti clockwise from a
|
||||
line, and then check for distance. If the point is in the relevant area
|
||||
the turtle gets its color from the bitmap and compares it with the sought
|
||||
color. <BR>
|
||||
</P>
|
||||
|
||||
<P>When looking for a specific turtle, the turtle gets this turtle's position
|
||||
and calculates if this location is in the relevant area using the same
|
||||
algorithm. When looking for any turtle, the turtle passes the relevant
|
||||
arguments to the view, which then uses the same algorithm for each turtle
|
||||
on its turtles array.<BR>
|
||||
</P>
|
||||
|
||||
<H2><A NAME="INTERRUPTS"></A>INTERRUPTS<BR>
|
||||
</H2>
|
||||
|
||||
<P>Each turtle holds an expandable array of interrupts. Each interrupts
|
||||
is an object that is much like a turtle vision. The interrupts has the
|
||||
view area argument and what it is looking for. It also has the message
|
||||
it needs to send and a pointer to the given queue. When the turtle notifies
|
||||
the interrupt that a change has happened, the interrupt first checks if
|
||||
the change is an area which is of interest to it. If so it calls the turtle
|
||||
look function with its location and the sought object. According to the
|
||||
turtle's answer and to the data stored inside the interrupt, the interrupt
|
||||
sends the needed message, if any.<BR>
|
||||
<BR>
|
||||
</P>
|
||||
|
||||
<H2><A NAME="CLASS"></A>CLASS ORGANIZATION<BR>
|
||||
</H2>
|
||||
|
||||
<P><CENTER><IMG border=0 SRC="img00012.gif" HEIGHT=626 WIDTH=693><BR>
|
||||
</CENTER>
|
||||
</P>
|
||||
|
||||
<P>Message-passing mechanisms:<BR>
|
||||
</P>
|
||||
|
||||
<P>
|
||||
<CENTER><IMG border=0 SRC="img00013.gif" HEIGHT=198 WIDTH=694> </CENTER></P>
|
||||
<FONT SIZE=+3></FONT>
|
||||
|
||||
|
||||
<P>
|
||||
<HR width=80% align=left color=blue>
|
||||
<CENTER>
|
||||
<A href="#top"><IMG border=0 src=back.gif ALT=" [TOP] "></A>
|
||||
<A href="gui.html"><IMG border=0 src=prev.gif ALT=" [PREV] "></A>
|
||||
<A href="manual.html"><IMG border=0 src=next.gif ALT=" [PREV] "></A>
|
||||
<A href="index.html#toc"><IMG border=0 src=toc.gif ALT=" [PREV] "></A>
|
||||
</CENTER>
|
||||
</BODY>
|
||||
</HTML>
|
||||
|
||||
|
||||
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
|
|
@ -0,0 +1,95 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
||||
<HTML>
|
||||
<HEAD>
|
||||
<TITLE>Galapagos</TITLE>
|
||||
</HEAD>
|
||||
<BODY background=stone.jpg>
|
||||
|
||||
<CENTER><P><B><FONT COLOR="#008040" SIZE=+4>Welcome to<BR>
|
||||
<IMG border=0 SRC=gps.gif alt="GALAPAGOS"></FONT></B></P></CENTER>
|
||||
|
||||
Galapagos is an interactive multithreaded Scheme interpreter with turtle
|
||||
graphics for Windows 95. It is built around the SCM interpreter, and it
|
||||
provides multiple interpreters, threads, turtles, and drawing boards, all
|
||||
running concurrently using WIN32's multithreading abilities, and freely
|
||||
<A href="#download">available</A>.
|
||||
|
||||
<P>
|
||||
<HR>
|
||||
<P>
|
||||
<Center>
|
||||
<A href="http://www.cs.bgu.ac.il"><IMG border=0 src="bgu_logo_tiny.gif" alt=""></A><BR><BR>
|
||||
Spring 1997<BR><BR>
|
||||
Graduation project<BR><BR>
|
||||
<A href="http://www.cs.bgu.ac.il">Department of Math & Computer Science,</A><BR><BR>
|
||||
<A href="http://www.bgu.ac.il">Ben-Gurion University of the Negev</A><BR><BR>
|
||||
<BR>
|
||||
Written by <A href="http://www.cs.bgu.ac.il/~elad">Elad Eyal</A> and <A href="http://www.cs.bgu.ac.il/~tebeka">Miki
|
||||
Tebeka</A>.<BR>
|
||||
<BR>
|
||||
Supervisor: <A href="http://www.cs.bgu.ac.il/~elhadad">Dr. Michael Elhadad</A>
|
||||
</CENTER>
|
||||
<P>
|
||||
<P>
|
||||
<HR width=100%>
|
||||
<P>
|
||||
<A name="toc">
|
||||
<CENTER><P><B><FONT SIZE=+3>TABLE OF CONTENTS </FONT></B></P></CENTER>
|
||||
|
||||
<UL>
|
||||
<LI><A HREF="background.html">Background </A></LI>
|
||||
<UL>
|
||||
<LI><A HREF="background.html#SCHEME">SCHEME</A></LI>
|
||||
<LI><A HREF="background.html#LOGO AND TURTLE">LOGO and Turtle Geometry</A></LI>
|
||||
<LI><A HREF="background.html#OBJECTIVES">Objectives</A></LI>
|
||||
<LI><A HREF="background.html#AVAILABILITY">Avaliability</A></LI>
|
||||
</UL>
|
||||
<LI><A HREF="extensions.html">SCHEME extensions</A></LI>
|
||||
<UL>
|
||||
<LI><A HREF="extensions.html#THE NEW ENVIRONMENT">The New Environment Model</A></LI>
|
||||
<LI><A HREF="extensions.html#THREADS">Threads</A></LI>
|
||||
<LI><A HREF="extensions.html#CONSOLES">Consoles</A></LI>
|
||||
<LI><A HREF="extensions.html#DRAWING">Drawing Boards</A></LI>
|
||||
<LI><A HREF="extensions.html#TURTLES">Turtles</A></LI>
|
||||
<LI><A HREF="extensions.html#INTERRUPTS (NOTIFICATIONS) AND MESSAGE">Interrupts (Notifications) and Message handlers</A></LI>
|
||||
</UL>
|
||||
<LI><A HREF="gui.html">The interactive GUI</A></LI>
|
||||
<LI><A HREF="implementation.html">Implementation</A></LI>
|
||||
<UL>
|
||||
<LI><A HREF="implementation.html#FITTING SCM INTO">Fitting SCM into Windows</A></LI>
|
||||
<LI><A HREF="implementation.html#GARBAGE">Garbage Collection</A></LI>
|
||||
<LI><A HREF="implementation.html#BOARDS">Boards</A></LI>
|
||||
<LI><A HREF="implementation.html#TURTLES">Turtles</A></LI>
|
||||
<LI><A HREF="implementation.html#VISION">Vision</A></LI>
|
||||
<LI><A HREF="implementation.html#INTERRUPTS">Interrupts</A></LI>
|
||||
<LI><A HREF="implementation.html#CLASS">Class Organization</A></LI>
|
||||
</UL>
|
||||
<LI><A HREF="manual.html">Programer's Manual</A></LI>
|
||||
<UL>
|
||||
<LI><A HREF="manual.html#ENVIRONMENTS">Environments</A></LI>
|
||||
<LI><A HREF="manual.html#MESSAGE">Message Queues</A></LI>
|
||||
<LI><A HREF="manual.html#WINDOW">Window Commands</A></LI>
|
||||
<LI><A HREF="manual.html#TURTLE">Turtle Commands</A></LI>
|
||||
<LI><A HREF="manual.html#VISION">Vision</A></LI>
|
||||
<LI><A HREF="manual.html#INTERRUPTS">Interrupts (Notifications)</A></LI>
|
||||
<LI><A HREF="manual.html#THREADS">Threads</A></LI>
|
||||
</UL>
|
||||
<LI><A HREF="bib.html">Bibiliography and Links</A></LI>
|
||||
</UL>
|
||||
|
||||
<P>
|
||||
|
||||
<BR>
|
||||
<A name="download">
|
||||
<CENTER><P><B><FONT SIZE=+3>DOWNLOAD CENTER</FONT></B></P></CENTER>
|
||||
<P>
|
||||
<CENTER><FONT size=-1><TT>GNU LICENSE. COPYRIGHTED. PROVIDED "AS IS". NO
|
||||
WARRANTIES OR LIABILITIES. ETC.</TT></CENTER>
|
||||
<P>
|
||||
<P>
|
||||
500K <A href="gps10bin.zip"><TT>gps10bin.zip</TT></A> - Executable and required Scheme libraries (SLIB)<BR>
|
||||
700K <A href="gps10src.zip"><TT>gps10src.zip</TT></A> - Same with all source code <BR>
|
||||
400K <A href="mfc40dll.zip"><TT>mfc40dll.zip</TT></A> - You might need this MFC40.DLL if you
|
||||
don't have it already. <BR>
|
||||
</BODY>
|
||||
</HTML>
|
||||
|
|
@ -0,0 +1,95 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
||||
<HTML>
|
||||
<HEAD>
|
||||
<TITLE>Galapagos</TITLE>
|
||||
</HEAD>
|
||||
<BODY background=stone.jpg>
|
||||
|
||||
<CENTER><P><B><FONT COLOR="#008040" SIZE=+4>Welcome to<BR>
|
||||
<IMG border=0 SRC=gps.gif alt="GALAPAGOS"></FONT></B></P></CENTER>
|
||||
|
||||
Galapagos is an interactive multithreaded Scheme interpreter with turtle
|
||||
graphics for Windows 95. It is built around the SCM interpreter, and it
|
||||
provides multiple interpreters, threads, turtles, and drawing boards, all
|
||||
running concurrently using WIN32's multithreading abilities, and freely
|
||||
<A href="#download">available</A>.
|
||||
|
||||
<P>
|
||||
<HR>
|
||||
<P>
|
||||
<Center>
|
||||
<A href="http://www.cs.bgu.ac.il"><IMG border=0 src="bgu_logo_tiny.gif" alt=""></A><BR><BR>
|
||||
Spring 1997<BR><BR>
|
||||
Graduation project<BR><BR>
|
||||
<A href="http://www.cs.bgu.ac.il">Department of Math & Computer Science,</A><BR><BR>
|
||||
<A href="http://www.bgu.ac.il">Ben-Gurion University of the Negev</A><BR><BR>
|
||||
<BR>
|
||||
Written by <A href="http://www.cs.bgu.ac.il/~elad">Elad Eyal</A> and <A href="http://www.cs.bgu.ac.il/~tebeka">Miki
|
||||
Tebeka</A>.<BR>
|
||||
<BR>
|
||||
Supervisor: <A href="http://www.cs.bgu.ac.il/~elhadad">Dr. Michael Elhadad</A>
|
||||
</CENTER>
|
||||
<P>
|
||||
<P>
|
||||
<HR width=100%>
|
||||
<P>
|
||||
<A name="toc">
|
||||
<CENTER><P><B><FONT SIZE=+3>TABLE OF CONTENTS </FONT></B></P></CENTER>
|
||||
|
||||
<UL>
|
||||
<LI><A HREF="background.html">Background </A></LI>
|
||||
<UL>
|
||||
<LI><A HREF="background.html#SCHEME">SCHEME</A></LI>
|
||||
<LI><A HREF="background.html#LOGO AND TURTLE">LOGO and Turtle Geometry</A></LI>
|
||||
<LI><A HREF="background.html#OBJECTIVES">Objectives</A></LI>
|
||||
<LI><A HREF="background.html#AVAILABILITY">Avaliability</A></LI>
|
||||
</UL>
|
||||
<LI><A HREF="extensions.html">SCHEME extensions</A></LI>
|
||||
<UL>
|
||||
<LI><A HREF="extensions.html#THE NEW ENVIRONMENT">The New Environment Model</A></LI>
|
||||
<LI><A HREF="extensions.html#THREADS">Threads</A></LI>
|
||||
<LI><A HREF="extensions.html#CONSOLES">Consoles</A></LI>
|
||||
<LI><A HREF="extensions.html#DRAWING">Drawing Boards</A></LI>
|
||||
<LI><A HREF="extensions.html#TURTLES">Turtles</A></LI>
|
||||
<LI><A HREF="extensions.html#INTERRUPTS (NOTIFICATIONS) AND MESSAGE">Interrupts (Notifications) and Message handlers</A></LI>
|
||||
</UL>
|
||||
<LI><A HREF="gui.html">The interactive GUI</A></LI>
|
||||
<LI><A HREF="implementation.html">Implementation</A></LI>
|
||||
<UL>
|
||||
<LI><A HREF="implementation.html#FITTING SCM INTO">Fitting SCM into Windows</A></LI>
|
||||
<LI><A HREF="implementation.html#GARBAGE">Garbage Collection</A></LI>
|
||||
<LI><A HREF="implementation.html#BOARDS">Boards</A></LI>
|
||||
<LI><A HREF="implementation.html#TURTLES">Turtles</A></LI>
|
||||
<LI><A HREF="implementation.html#VISION">Vision</A></LI>
|
||||
<LI><A HREF="implementation.html#INTERRUPTS">Interrupts</A></LI>
|
||||
<LI><A HREF="implementation.html#CLASS">Class Organization</A></LI>
|
||||
</UL>
|
||||
<LI><A HREF="manual.html">Programer's Manual</A></LI>
|
||||
<UL>
|
||||
<LI><A HREF="manual.html#ENVIRONMENTS">Environments</A></LI>
|
||||
<LI><A HREF="manual.html#MESSAGE">Message Queues</A></LI>
|
||||
<LI><A HREF="manual.html#WINDOW">Window Commands</A></LI>
|
||||
<LI><A HREF="manual.html#TURTLE">Turtle Commands</A></LI>
|
||||
<LI><A HREF="manual.html#VISION">Vision</A></LI>
|
||||
<LI><A HREF="manual.html#INTERRUPTS">Interrupts (Notifications)</A></LI>
|
||||
<LI><A HREF="manual.html#THREADS">Threads</A></LI>
|
||||
</UL>
|
||||
<LI><A HREF="bib.html">Bibiliography and Links</A></LI>
|
||||
</UL>
|
||||
|
||||
<P>
|
||||
|
||||
<BR>
|
||||
<A name="download">
|
||||
<CENTER><P><B><FONT SIZE=+3>DOWNLOAD CENTER</FONT></B></P></CENTER>
|
||||
<P>
|
||||
<CENTER><FONT size=-1><TT>GNU LICENSE. COPYRIGHTED. PROVIDED "AS IS". NO
|
||||
WARRANTIES OR LIABILITIES. ETC.</TT></CENTER>
|
||||
<P>
|
||||
<P>
|
||||
500K <A href="gps10bin.zip"><TT>gps10bin.zip</TT></A> - Executable and required Scheme libraries (SLIB)<BR>
|
||||
700K <A href="gps10src.zip"><TT>gps10src.zip</TT></A> - Same with all source code <BR>
|
||||
400K <A href="mfc40dll.zip"><TT>mfc40dll.zip</TT></A> - You might need this MFC40.DLL if you
|
||||
don't have it already. <BR>
|
||||
</BODY>
|
||||
</HTML>
|
||||
|
|
@ -0,0 +1,95 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
||||
<HTML>
|
||||
<HEAD>
|
||||
<TITLE>Galapagos</TITLE>
|
||||
</HEAD>
|
||||
<BODY background=stone.jpg>
|
||||
|
||||
<CENTER><P><B><FONT COLOR="#008040" SIZE=+4>Welcome to<BR>
|
||||
<IMG border=0 SRC=gps.gif alt="GALAPAGOS"></FONT></B></P></CENTER>
|
||||
|
||||
Galapagos is an interactive multithreaded Scheme interpreter with turtle
|
||||
graphics for Windows 95. It is built around the SCM interpreter, and it
|
||||
provides multiple interpreters, threads, turtles, and drawing boards, all
|
||||
running concurrently using WIN32's multithreading abilities, and freely
|
||||
<A href="#download">available</A>.
|
||||
|
||||
<P>
|
||||
<HR>
|
||||
<P>
|
||||
<Center>
|
||||
<A href="http://www.cs.bgu.ac.il"><IMG border=0 src="bgu_logo_tiny.gif" alt=""></A><BR><BR>
|
||||
Spring 1997<BR><BR>
|
||||
Graduation project<BR><BR>
|
||||
<A href="http://www.cs.bgu.ac.il">Department of Math & Computer Science,</A><BR><BR>
|
||||
<A href="http://www.bgu.ac.il">Ben-Gurion University of the Negev</A><BR><BR>
|
||||
<BR>
|
||||
Written by <A href="http://www.cs.bgu.ac.il/~elad">Elad Eyal</A> and <A href="http://www.cs.bgu.ac.il/~tebeka">Miki
|
||||
Tebeka</A>.<BR>
|
||||
<BR>
|
||||
Supervisor: <A href="http://www.cs.bgu.ac.il/~elhadad">Dr. Michael Elhadad</A>
|
||||
</CENTER>
|
||||
<P>
|
||||
<P>
|
||||
<HR width=100%>
|
||||
<P>
|
||||
<A name="toc">
|
||||
<CENTER><P><B><FONT SIZE=+3>TABLE OF CONTENTS </FONT></B></P></CENTER>
|
||||
|
||||
<UL>
|
||||
<LI><A HREF="background.html">Background </A></LI>
|
||||
<UL>
|
||||
<LI><A HREF="background.html#SCHEME">SCHEME</A></LI>
|
||||
<LI><A HREF="background.html#LOGO AND TURTLE">LOGO and Turtle Geometry</A></LI>
|
||||
<LI><A HREF="background.html#OBJECTIVES">Objectives</A></LI>
|
||||
<LI><A HREF="background.html#AVAILABILITY">Avaliability</A></LI>
|
||||
</UL>
|
||||
<LI><A HREF="extensions.html">SCHEME extensions</A></LI>
|
||||
<UL>
|
||||
<LI><A HREF="extensions.html#THE NEW ENVIRONMENT">The New Environment Model</A></LI>
|
||||
<LI><A HREF="extensions.html#THREADS">Threads</A></LI>
|
||||
<LI><A HREF="extensions.html#CONSOLES">Consoles</A></LI>
|
||||
<LI><A HREF="extensions.html#DRAWING">Drawing Boards</A></LI>
|
||||
<LI><A HREF="extensions.html#TURTLES">Turtles</A></LI>
|
||||
<LI><A HREF="extensions.html#INTERRUPTS (NOTIFICATIONS) AND MESSAGE">Interrupts (Notifications) and Message handlers</A></LI>
|
||||
</UL>
|
||||
<LI><A HREF="gui.html">The interactive GUI</A></LI>
|
||||
<LI><A HREF="implementation.html">Implementation</A></LI>
|
||||
<UL>
|
||||
<LI><A HREF="implementation.html#FITTING SCM INTO">Fitting SCM into Windows</A></LI>
|
||||
<LI><A HREF="implementation.html#GARBAGE">Garbage Collection</A></LI>
|
||||
<LI><A HREF="implementation.html#BOARDS">Boards</A></LI>
|
||||
<LI><A HREF="implementation.html#TURTLES">Turtles</A></LI>
|
||||
<LI><A HREF="implementation.html#VISION">Vision</A></LI>
|
||||
<LI><A HREF="implementation.html#INTERRUPTS">Interrupts</A></LI>
|
||||
<LI><A HREF="implementation.html#CLASS">Class Organization</A></LI>
|
||||
</UL>
|
||||
<LI><A HREF="manual.html">Programer's Manual</A></LI>
|
||||
<UL>
|
||||
<LI><A HREF="manual.html#ENVIRONMENTS">Environments</A></LI>
|
||||
<LI><A HREF="manual.html#MESSAGE">Message Queues</A></LI>
|
||||
<LI><A HREF="manual.html#WINDOW">Window Commands</A></LI>
|
||||
<LI><A HREF="manual.html#TURTLE">Turtle Commands</A></LI>
|
||||
<LI><A HREF="manual.html#VISION">Vision</A></LI>
|
||||
<LI><A HREF="manual.html#INTERRUPTS">Interrupts (Notifications)</A></LI>
|
||||
<LI><A HREF="manual.html#THREADS">Threads</A></LI>
|
||||
</UL>
|
||||
<LI><A HREF="bib.html">Bibiliography and Links</A></LI>
|
||||
</UL>
|
||||
|
||||
<P>
|
||||
|
||||
<BR>
|
||||
<A name="download">
|
||||
<CENTER><P><B><FONT SIZE=+3>DOWNLOAD CENTER</FONT></B></P></CENTER>
|
||||
<P>
|
||||
<CENTER><FONT size=-1><TT>GNU LICENSE. COPYRIGHTED. PROVIDED "AS IS". NO
|
||||
WARRANTIES OR LIABILITIES. ETC.</TT></CENTER>
|
||||
<P>
|
||||
<P>
|
||||
500K <A href="gps10bin.zip"><TT>gps10bin.zip</TT></A> - Executable and required Scheme libraries (SLIB)<BR>
|
||||
700K <A href="gps10src.zip"><TT>gps10src.zip</TT></A> - Same with all source code <BR>
|
||||
400K <A href="mfc40dll.zip"><TT>mfc40dll.zip</TT></A> - You might need this MFC40.DLL if you
|
||||
don't have it already. <BR>
|
||||
</BODY>
|
||||
</HTML>
|
||||
Loading…
Reference in New Issue