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:
Lassi Kortela 2023-03-11 22:16:44 +02:00
commit e1790c55bd
49 changed files with 8482 additions and 0 deletions

View File

@ -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 &amp; 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

View File

@ -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 &quot;Common
Lisp: the Language, 2nd Edition&quot;.<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-&gt;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 &lt;jaffer@ai.mit.edu&gt;.<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 &quot;turtle&quot;
which can be instructed to move across the screen and draw shapes. This
became known as &quot;Turtle Graphics&quot; or &quot;Turtle Geometry&quot;
- a geometry that describes paths &quot;from within&quot; rather than &quot;from
outside&quot; or &quot;from above.&quot; For example, &quot;turn right&quot;
means turn right relative to whatever direction you were heading before;
by contrast, &quot;turn east&quot; 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 &quot;body syntonic.&quot;<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>

View File

@ -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 &quot;see&quot; 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 &quot;holds&quot; its environment,
hence the name &quot;closure&quot;) 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 &quot;environments tree&quot;, 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&gt;</FONT></TT> <I>(define
x 7)</I> </P>
<P><I>(define (f) ...)</I> </P>
<P><TT><FONT FACE="Courier New">Thread A&gt;</FONT></TT> <I>(define (g)
x)</I> </P>
<P><TT><FONT FACE="Courier New">Thread B&gt;</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&gt;</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 &quot;cheap&quot; 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 &quot;shapes&quot; 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 &quot;down&quot; and will not draw when it is &quot;up&quot;.
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 &quot;solid&quot; or &quot;hollow&quot;
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
&quot;can see&quot;- &quot;can't see&quot; toggle) or only when one change
happens (only &quot;can see&quot; or &quot;can't see&quot; toggle). A message
can be any valid SCHEME object.<BR>
</P>
<P>Example: </P>
<P>The command </P>
<P><I>(turtle-notify t &quot;I-see&quot; &quot;I-don't-see&quot; 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>&quot;I-see&quot;</I> and when it doesn't see
the color black any more it should send the message <I>&quot;I-don't-see&quot;</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 &quot;can see&quot; (<B>notify-when</B> command)
only the <I>&quot;I-see&quot;</I> messages were sent, and if it was a the
&quot;can't see&quot; interrupt (<B>notify-when-not</B> command) only the
<I>&quot;I-can't-see&quot; </I>style messages were sent.<BR>
</P>
<P>A special &quot;user interrupt&quot; 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>&quot;I-see&quot;</I> </P>
<P><I>&quot;I-don't-see&quot;</I> </P>
<P><I>&quot;I-see&quot;</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>

View File

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

View File

@ -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 &quot;Urgent Messages&quot;. 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 &quot;Urgent&quot; 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, &quot;all
that is Windows&quot;: 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 &quot;poll routine&quot; 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 &quot;SCHEME IN ONE DEFUN, BUT IN C THIS TIME&quot;,
by George J Carrette &lt;gjc@world.std.com&gt;. <BR>
</P>
<P>SCM uses a conservative Mark &amp; Sweep garbage collector (GC). All
Scheme data objects share some common configuration (called &quot;cells&quot;):
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 &amp; 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 &amp; 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 &amp; Sweep in Galapagos because of its
two major advantages: Simplicity and efficiency. Mark &amp; 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 &quot;<B>Garbage Collection daemon</B>&quot;
(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 &quot;busy&quot; (thus implementing
busy/wait protection over it) or &quot;end of memory&quot; 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 &quot;initiator&quot;. Several threads can &quot;initiate&quot;
GC, and each request is &quot;satisfied&quot;, 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 &quot;out of memory&quot; 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 &quot;looking&quot; 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>

View File

@ -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> &lt;<TT><A href="mailto:elad@cs.bgu.ac.il">elad@cs.bgu.ac.il</A></TT>&gt;</LI>
<P>
<LI><A href="http://www.cs.bgu.ac.il/~tebeka">Miki's Terrible Homepage</A> &lt;<TT><A href="mailto:tebeka@cs.bgu.ac.il">tebeka@cs.bgu.ac.il</A></TT>&gt;</LI>
<P></UL>
<LI>The Advisor:
<P>
<UL>
<LI><A href="http://www.cs.bgu.ac.il/~elhadad">Dr. Michael Elhadad</A>
&lt;<TT><A href="mailto:elhadad@cs.bgu.ac.il">elhadad@cs.bgu.ac.il</A></TT>&gt;</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>

View File

@ -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 &amp; 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