\input texinfo   @c -*-texinfo-*-
@comment check footnotes

@comment login nonrotate script doesn't appear when you do:
@comment   close edwin xterm
@comment   soft reboot
@comment   close edwin window (say yes)
@comment it appears if you powercycle the machine (have to login with N,
@comment   then M-x checkpoint-floppy)

@c %**start of header
@setfilename NWWYW.info
@settitle LA Manual
@c %**end of header

@setchapternewpage odd
@c -----------------------------------------------------------------
@c --------------- Summary Description and Copyright ---------------
@c -----------------------------------------------------------------

@ifinfo
Copyright @copyright{} 1992 Massachusetts Institute of Technology
@end ifinfo

@c -----------------------------------------------------------------
@c -------------------- Titlepage and Copyright --------------------
@c -----------------------------------------------------------------

@titlepage
@title Never Whistle While You're Wizzing
@subtitle Lab Assistant Manual For 6.001 Wizards
@author by
@author Natalya Cohen
@author and the Scheme Team

@c The copyright page
@page
@vskip 0pt plus 1filll
Copyright @copyright{} 1992 Massachvsetts Institvte of Technology

Department of Electrical Engineering and Computer Science.

Permission is granted to distribute verbatim copies of this manual
provided that the copyright notice and this permission notice are
preserved on all copies.
@end titlepage

@c -----------------------------------------------------------------
@c -------------------- Top Node and Master Menu -------------------
@c -----------------------------------------------------------------

@ifinfo
@node Top, Warning, (dir), (dir)
@top

This is the on-line version of the 6.001 Lab Assistant manual.  It will
probably be most useful to you for looking up information that you
remember reading in the printed version of this manual.

@menu
* Warning::                     Warning
* Administrivia::               Administrivia
* The Lab::                     In the Lab
* Software::                    Software in the Lab
* Crises::                      Crises, Big and Small
* Students::                    How to Deal with Students
* Concept Index::               Concept Index

@end menu

@end ifinfo

@c -----------------------------------------------------------------
@c ------------------------- Document Body -------------------------
@c -----------------------------------------------------------------

@c ----------------------------Chapter 0----------------------------
@node Warning, Administrivia, Top, Top
@unnumbered Warning
@cindex "The Illuminatus! Trilogy"
@cindex lloigor
@cindex Fnord!
As you might've guessed from the title, the author of this document has
been recently exposed to a very dangerous, mind-disturbing lloigor of a
book, co-authored by Robert Shea and Robert Anton Wilson.  Thus, some of
the references in this manual will appear slightly amusing to the
illuminated ones and obscure to the mehums (see what I mean?).  As a
matter of fact, most of it is plain gibberish, so don't let the silly
remarks distract you into ignoring the serious and important stuff
contained in the manual.  (What can I say?  Writing an LA manual, of all
things, is such an unilluminizing experience that you almost have to
introduce a factor which makes it worthwhile.  Just be grateful I did
not employ the writing style of the authors of "The Illuminatus!
Trilogy.")  For what it's worth, though, I hope I've intimidated you
into reading the book, and I also hope this manual proves to be useful
otherwise, as a guide to being a successful Fnord! Lab Assistant.


@c ----------------------------Chapter 1----------------------------
@node Administrivia, The Lab, Warning, Top
@chapter Administrivia

Welcome, the Legionnaires of the Lab of Dynamic
Discord@footnote{Otherwise known as Little Deluded Dupes.}.  Following
is a quick review of the administrivia---your basic duties outside the
lab, as well as the rules of lab coverage.  You will probably be
brainwashed enough about this in LA meetings.

@c ----------------------------------------------------------------
@section Timecards
@cindex timecards
@cindex payroll paperwork
@cindex filing cabinet
@cindex Fnord!
imecards are picked up in the Course VI administrative office, 38-445.
This is also where you go at the beginning of the term (regardless of
whether you LAd the term before or not) to fill out the forms necessary
to get you on payroll.  Timecards should be filled out and signed by the
LA and dropped off in a pendaflex folder in the top drawer of the filing
cabinet in the lab by the end of the day on Friday (if you have lab
hours on weekends, go ahead and claim them ahead of time, as long as you
plan to make them).  The head TA or LA will sign them and turn them in
for you by 10:00 the following Monday morning so that you can get paid
the following Friday.
  
The anal-retentive administrators downstairs request that you indicate
and circle the total number of hours you worked, as a check on their
addition skills.  Also, you should sign your timecards, not in the place
supplied for the head TA/LA signature, but to the right of that space,
under the lower right hand corner of the time table.

In addition, for the purposes of monitoring Fnord! your work more
effectively (although the Eye in the Pyramid is always
watching@footnote{If you don't believe me, look at the back of a dollar
bill.}, the head LA will check over your timecards to make sure the hours
you claimed are reasonable---just in case), please make sure your
timecard makes it clear what the numbers on it represent.  Specifically,
write LAB to the right of the hours you spent in the lab, MEET by the
hour of the LA meeting, and PREP by the hours of preparation---i.e.,
doing the problem sets and checking over the solutions.  If you were
covering the lab hours for someone else, you might want to indicate the
name of that person as well.  On the weeks of the quiz reviews, write
REVIEW by the hours you spent giving the review.

As the above makes clear, an LA is paid not only for lab coverage, but
also for attending the LA meetings, doing the problem sets, and,
occasionally, giving the quiz reviews.@footnote{Sometimes, you may get
paid for baking chocolate chip cookies or even watching the head TA play
hockey---but we'll leave it to you to figure out how to finagle the head
TA into letting you do that.}  Each of these will be discussed in the
following sections.

@c ----------------------------------------------------------------
@section Lab Hours
@cindex lab coverage
@cindex schedule conflicts
@cindex koppeling hours
Time slots for lab duties are selected at the first Lab Assistant
meeting, at the beginning of the term.  The sign-ups are traditionally
done by seniority, based on the number of terms as a Lab Assistant (LAs
that have served the same sentence receive priority based on their class
year), although usually everyone is reasonable enough that any serious
conflicts can be worked out quickly and easily without too much
bloodshed.  Once the lab hours are assigned, they are your
responsibility for the rest of the term.  The head LA keeps the schedule
of the lab coverage; it is also put on the blackboard on the back of the
lab.

Be prompt.  It is always a good idea to show up ten to fifteen minutes
ahead of time and spend the extra time making sure nothing and nobody is
dead, catching up on the new developments, assessing the situation,
meditating, etc.---see Chapter 2 for details.

Be prepared.  This means you should be familiar with the problem set the
students are working on to the extent that you can help them understand
it and catch their bugs---and that, you will find, requires a pretty good
preparation.

If you find that you have a permanent schedule conflict, try to find
another LA who can either take your hours or trade with you, talk to the
head LA, or bring it up in the LA meeting.

Similarly, if you cannot make a shift, it is your responsibility to get
a replacement.  @emph{Please} start looking for one early, if at all
possible.  You can either get someone to "koppel"@footnote{In honor of
Josh Koppelman, who claims to have taken a lot of people's hours on
demand.} your hours or trade them.  This is relatively easily
accomplished by sending out e-mail several days before your shift, but
last minute cancellations are usually more of a problem.  @strong{If you
cannot find anyone who would koppel your hours}, let the head LA
@emph{and} the head TA know.  There have been precedents of graduate TAs
and even lecturers coming in to help out.

@strong{Don't ever punt your lab hours.} Your lab hours are your
responsibility.  If you punt them, you are shafting hordes of 6.001
students who are eager for your guidance and advice, and bringing
dishonor to the 6.001 staff, the EECS department, MIT, and the entire
quadrant of the galaxy.  You will be hunted down, dealt with, and dogs
will eat your bones.

If a last-minute distraction should arise, for example, if you are
kidnapped by space aliens on your way to the lab, be sure they let you
make a phone call to the head TA or lecturer and leave a message
reporting the emergency.

In other words, be very responsible about this.  Everybody has problems
from time to time, and nobody expects you to be perfect, but you
@emph{are} expected to arrange for someone to cover your hours at all
times, even if you are feeling particularly imperfect.

@c ----------------------------------------------------------------
@section LA meetings
@cindex LA meetings
@cindex feedback
The weekly LA meeting (with the head TA, and sometimes one of the
lecturers, present) is scheduled at the beginning of the term, hopefully
to fit into everyone's schedule.  As mentioned before, you get paid for
this hour long meeting (needless to say, you don't get paid if you don't
show up).  Make every attempt to attend all of the meetings.  If there's
a conflict, let the head LA and/or head TA know.

In the meeting, the upcoming problem sets (and sometimes solutions) are
handed out and discussed.  Also, this is your chance to give the rest of
the 6.001 staff your feedback on how things are going in the lab and
what specific problems students are having with the material.

@c ----------------------------------------------------------------
@section Preparation
@cindex feedback
@cindex bug reports
@cindex problem sets
@cindex floppies
You also get paid for no more and no less than two hours for preparation
every week a problem set is given out (the early ones usually take much
less than two hours, the late ones take longer, so it all balances out).
Draft problem sets are given out to you in the meeting at least a week
before they go out to the students.  Do every problem set (not just
glance at it, really @emph{do} it) as soon as it is handed out to you.
This is not only to prepare you for your lab hours, but also to catch
bugs and judge the difficulty of assignments.  You will normally be
given draft solutions as a reference (not a crutch) which you should
also eventually read over carefully so we can catch bugs in these too.
Send your bug reports to @code{6001-feedback@@sicp-00.mit.edu}.

If you missed the LA meeting where the problem set was given out, some
extra copies are usually available in the top drawer of the filing
cabinet.  If not, you can always get one from the course secretary.

At the beginning of the term, course notes, a copy of this manual, the
"Don't Panic" manual, Revised 4th Report on Scheme (R4RS), and two
floppy disks are given out to every LA.  Read the manuals at least
briefly.  If you want to keep the problem set solutions you hack up in
the lab, use your floppies to store them; do not leave your code in some
random temporary directory you created.

@c ----------------------------------------------------------------
@section Quiz Reviews
@cindex quiz reviews
LAs are usually responsible for organizing and executing review sessions
before the quizzes (and sometimes the final).  In the past, these have
been done in many different ways.  Usually, the course material is
divided into sections which are then allocated to an LA or two, and the
allocated LAs prepare a few examples of problems which demonstrate the
ideas in their section.  Preparation for the review takes place of
otherwise cancelled prep hours for that week (no problem sets are due on
the week of the quiz), and the hours you spend doing the review can be
claimed as well.

@c ----------------------------------------------------------------
@section Mailing Lists
@cindex feedback
@cindex bug reports
You should be prepared to check your mail @emph{a lot}---at least, once
a day during the week.  You will need it to stay up-to-date.  Besides,
since you will be on a couple of mailing lists listed below, not
checking your mail may prove fatal---for example, if your mailbox lives
on Anathema, you may go over your quota.  And you really don't want to
read through thirty--forty--fifty 6.001-related messages @emph{alone} at
a time.

Following are the e-mail addresses of the major cliques and conspiracies
behind 6.001.  All the bugs you (or students) find as well as reports of
the problems you find within the system should be sent to
@code{6001-feedback}.  Matters of relevance to the LAs are addressed
through @code{6001-las}; please don't use @code{6001-staff} for this
purpose, but do use it when you wish to illuminize the entire staff on
some issue.  Those are probably the only three you'll ever use; the rest
are there for reference.

@page
@table @code
@item 6001-lecturers@@ai.mit.edu
the lecturers

@item 6001-secretary@@ai.mit.edu
the course secretary

@item 6001-recitation@@ai.mit.edu
the recitation instructors

@item 6001-tas@@ai.mit.edu
the graduate TAs

@item 6001-head-ta@@ai.mit.edu 
the head TA

@item 6001-head-la@@ai.mit.edu
the head LA

@item 6001-las@@ai.mit.edu 
the Little Deluded Dupes themselves

@item 6001-staff@@ai.mit.edu
the entire staff: lecturers, recitation instructors, TAs, LAs, and
course secretary 

@item 6001-feedback@@sicp-00.mit.edu  
people who should know about/are responsible for fixing bugs; includes
lecturers and LAs but also people in charge of the system and the lab,
for example; this is also the mailing list the students use to report
bugs and register complaints---it may get quite hectic at times
@end table

@c ----------------------------Chapter 2---------------------------
@node The Lab, Software, Administrivia, Top
@chapter In the Lab

This chapter is about your basic duties in the lab, assuming no crisis
occurs.  For the ways to deal with minor, as well as major, crises refer
to Chapter 4.

@c ----------------------------------------------------------------
@section What to Do When You Get to the Lab

If you believe in the Second Law of Thermodynamics, you will believe me
when I say there are enough things to check over when you start your
shift.  That is why it is advisable to show up a little earlier,
especially if your hours are on a busy night.  In any event, here are
the things you should worry about when you first get to the lab.

@c ----------------------------------------------------------------
@subsection The Snakes
@cindex rebooting
@cindex hardware problems
@cindex servers
@cindex instrument desk
@cindex filing cabinet
@cindex Fnord!
Make sure that all the snakes are functional.  Logout or reboot machines
where necessary.  If rebooting doesn't help, or some other problem is
encountered that prevents the snake from working correctly, follow the
procedure for reporting hardware problems described in the Chapter on
crises---i.e., inform the instrument desk people, send mail to
@code{6001-feedback}, and put a tag on the machine (the tags can usually
be found on top or in the top drawer of the filing cabinet).  If you
encounter a machine with a tag on it, but you do not recall reading
about the problem on @code{6001-feedback}, follow the first two
steps---it is better to report the problem twice than to neglect it
altogether.

When first checking the snakes, have a look at the network lights on
each machine to make sure it isn't swapping without any apparent reason
(the two network lights are the ones with arrows above them; they will
be blinking heavily if the machine is swapping).  You should also do
this from time to time as you walk around the lab.  A machine should
never be swapping heavily, even when in use.  If it is swapping, either
some joker is logged into it over the network, or there are a few
abandoned Schemes also running on the machine and need to be killed (see
section 4.2.1).

If you have absolutely nothing better Fnord! to do, one useful and
heroic practice is to go around killing old Scheme processes.  This
might not be a problem anymore, but it proved to be a rather painful
annoyance in the past.  Hail Eris.

The two servers, sicp-00 and sicp-01, are in the closet behind the
printers.  You will certainly notice it if either one of them is down.
Pray to the Goddess and refer to the chapter on crises.  All Hail
Discordia.

@c ----------------------------------------------------------------
@subsection The Printers
@cindex printers
@cindex printer paper
@cindex instrument desk
The two printers, sicp-48 and sicp-49, are to the left of the entrance
into the lab (sicp-49 is the left one).  Make sure both of them are in
working condition and on-line (the @sc{on line} light should be on),
there are no paper jams anywhere, and there is enough paper.  Throw old
printouts into the recycling bin.

If either printer is low on paper, get some from the instrument desk (if
it is open) or from the server closet.  Resort to visiting the closet
only if the instrument desk is closed.  In this case, send e-mail to the
@code{6001-las} to warn the first person who comes in the next day to
re-supply the closet cache.

When getting paper for the printers, make sure there are always a couple
of extra reams in the closet. (If the desk folks give you any grief,
tell them to grow up.)

@c ----------------------------------------------------------------
@subsection The Rest of the Lab; Lost and Found
@cindex filing cabinet
@cindex Lambda Lounge
@cindex plants
@cindex lost and found
@cindex Bavarian Fire Drill
@cindex floppies
Make sure the filing cabinet is locked whenever you're not using it.  It
often contains problem set solutions, and we don't want them to be of
public use.

The Lambda Lounge, or the tutorial area, should be a pleasant place to
be in.  Straighten out the furniture.  Get rid of all the junk people
throw in there.  Erase the irrelevant stuff from the blackboard.
@strong{Water the plants} if it looks like they need it---we don't want
them dead.

Speaking of junk, you might want to tour the lab, looking for old
printouts to recycle and other things people tend to leave behind.  If
you find something that appears useful---e.g., someone's floppy---throw
it in the "Lost But Found" box by the door.  If the object is really
valuable---e.g., an expensive HP calculator---lock it in the filing
cabinet and put a sign on the board to that effect, so that the person
can recover it from an LA when (s)he comes in. 

If you want to be totally compulsive, you may also go around arranging
the chairs neatly by the tables.  It is incredible what other things you
can think of when bored---like having a Bavarian Fire Drill.  A pity it
doesn't happen that often.

@c ----------------------------------------------------------------
@subsection Settling into your Shift
@cindex @file{motd}
@cindex blackboards
@cindex help queue
Add your name to the list of "LAs On Duty" on the blackboard and erase
any names of LAs who are not on duty (erase your own name when leaving
the lab).  Read the @file{motd} file and/or announcements on the back
blackboards to see if there is anything new, and erase any outdated
messages.  If the help queue is on, start helping the students listed on
the queue.

If the lab is not busy, you will probably spend most of your time in
front of a terminal.  In that case, it is a good idea to put an LA sign
on top of your machine so that students can see you@footnote{At least,
until we get the LA baseball caps.}, especially if the help queue is
off.  Don't forget to remove the sign when you leave.

@c ----------------------------------------------------------------
@section The Help Q
@cindex help queue
@cindex Fnord!
The help queue is kept on the blackboard to the right of the Lambda
Lounge.  In fact, it is a good idea to keep at least two separates
queues---one for people with technical problems, usually dead or hung up
Schemes, where your help is needed in recovering the students' work; the
other for people with conceptual problems.  Priority is given to the
first of the above.

You are the one who decides if the queue is on or off.  You definitely
want it on if the lab is busy, to avoid (further) chaos.  During the
more quiet hours, handle the queue however feels most comfortable to
you.  Make sure to check the @sc{on} or @sc{off} box on the Q board.

When the queue is on, help students in the order their machine names are
listed on the board@footnote{At the beginning of the term, some will put
their own name instead of the machine name on the queue.  Straighten
them out.} (watch out for people who sign up twice, just in case they
will have another question by the time you get to them again---this is a
common phenomenon on the more busy nights).  The map of the lab with the
machines numbered is posted on the wall by the board.  @strong{Always
erase the name of the machine off the Q before going to help the
student}, so that if there are any other LAs on duty, they can proceed
to help the next person on the queue.  If you get distracted while in
the process of going over to someone's machine (having already dequeued
the machine name), be sure to remember to come back to it
afterwards---if you are afraid you may forget the machine name, write it
down somewhere.

When the queue is off, the students should look for an LA and ask for
help.  Beware that some students will tend to use the queue even when
it's off.  Help them but explain Fnord! what the policy is.  To bring
the point even closer to home, put a big cross or some other hideously
noticeable sign across the board@footnote{You may resort to drawings, in
which case the Sacred Chao symbol could be used, or to obscure signs of
the sort "Anyone who uses the queue while it's off will be beheaded.
THE MGT."}---the simple @sc{off} box doesn't seem to do the trick.

And the last important point: if no LA has hours scheduled immediately
after yours, turn the queue off in the manner described above when
leaving the lab.  Otherwise, the LA coming in a couple hours after you
might find a stale queue waiting for him/her (if you do come in and find
that the queue is a few hours old, don't hesitate to erase it;  students
should know that signing up for help when there is no LA in the lab, in
hopes that one will come around, is not only useless but not a sociable
thing to do).  
                                         
@c ----------------------------------------------------------------
@section Using and Updating Student Resources
@cindex servers
@cindex @file{motd}
These are the resources available to 6.001 students in the lab.  People
will be asking you about these, so you should definitely know about all
of them.  You should also refer the students to these when they ask you
questions which can be answered with the help of @file{motd} or @kbd{M-x
info}, for example.

THIS IS IMPORTANT: whenever you change the message of the day, the info
tree, the default in the @file{probset.scm} file, or anything else which
needs to be changed @emph{on all the machines}, you have to make the
relevant changes @strong{to both servers}.  See Chapter 4 for details.

@c ----------------------------------------------------------------
@subsection On-Line Documentation
@cindex info
@cindex food
@cindex Emacs
@cindex Fnord!
The info tree installed in the lab contains the on-line version of the
"Don't Panic" manual, this manual, MIT Scheme Reference Manual, MIT
Scheme User's Manual, Emacs documentation, etc.  You can activate the
info tree by typing @kbd{M-x info} in Edwin (type @kbd{C-h m} for
available commands).  Familiarize yourself with the contents of the
major sources, so you know where to refer students later.  In
particular, you should read the "Don't Panic" manual, which contains the
answers to most of the questions people ask in the first couple of weeks
of the term.  Rather than spending the time explaining something to the
students, tell them to read the manual first (RTFM!).

You will notice that one of the menu items in the tree is "Food."
Considering the food Fnord! policy in the lab, you might wonder what
it's doing there.  After you figure that one out, look under the entry
named "Taco Bell Delivery" for more surprises.

Another useful feature is an Emacs/Edwin tutorial, accessible by typing
@kbd{C-h t}.  Refer students to this if they don't have much experience
with Emacs and need to learn the basic commands.

@c ----------------------------------------------------------------
@subsection Message of the Day
@cindex @file{motd}
@cindex bug reports
@cindex feedback
@cindex blackboards
@cindex Emacs
@file{Motd}, or message of the day, file exists in the @file{u6001} home
directory.  It contains corrections/bugs in the current problem set
students should know about, as well as some relevant announcements about
problem sets/quizzes/lab hours/etc.  If you login as u6001, you will see
the contents of this file in the @file{*motd*} buffer on login.  Since
@file{motd} changes all the time, you should make sure you know what the
@file{motd} file says at all times, for that is the primary source of
bug reports.

If you or a student encounters a bug in the current problem set, you
should (besides reporting the bug to @code{6001-feedback}, as usual)
change the @file{motd} file to reflect that.  The file is writeable by
hacker, so you can easily edit it from Emacs (or Edwin) if logged in as
hacker (or if you open an Emacs window while su'd to hacker).  To open
an Emacs window, if logged in as u6001, type @kbd{emacs &} from an
xterm; if logged in as hacker, choose the appropriate label after
clicking on the left mouse button.  The @file{motd} file, as well as the
blackboard, is also a good place to put the answer to a
commonly-encountered problem or question.

@c ----------------------------------------------------------------
@subsection Changing the Default of @kbd{M-x load-problem-set}
@cindex problem sets
@cindex Emacs
The problem sets are installed on the machines by the head TA or the
head LA.  However, it is the responsibility of the LAs to make sure the
number of the current problem set is the default in @kbd{M-x
load-problem-set}.  Specifically, if a problem set was due on Friday and
a new problem set has been handed out, the change should be made by the
LA who is first to come in on Saturday.

To change the default, go to the file called
@file{~u6001/psets/probsets.scm}, where you will find something like the
following definition: 

@page
@lisp
(define problem-sets
  `(4                          ; this number is the default problem set
    (1 (load "ps1go.scm"))
    (2 ... )
  ... ))
@end lisp

As it stands, the default is 4.  To change it to 5, simply change the
car to 5, leaving the cdr in peace (the file is, again, writeable by
hacker and can be edited in Emacs or Edwin).

@c ----------------------------------------------------------------
@subsection Blackboards
@cindex blackboard
@cindex @file{motd}
@cindex lab coverage
@cindex Emacs
For some reason, some students seem more comfortable reading the
bug-related information and other kinds of announcements that are
typically put in @file{motd} off the blackboard.  For this reason, and
also to make sure people who logged in @emph{before} the most recent
change in the @file{motd} file are well informed, you should probably
duplicate the most important messages on the blackboards at the back of
the lab.

Another type of thing to put on the board is, say, an Emacs issue
students seem to be having trouble with, something that is likely to
remain on the board for a long time, such as "Use @kbd{C-x C-f}, not
@kbd{C-x b}, to create new files."

The schedule of lab coverage is put on one of the boards at the
beginning of the term, to be consulted by LAs and/or students.


@c ----------------------------------------------------------------
@subsection Filing Cabinet
@cindex filing cabinet
@cindex instrument desk
@cindex server closet
@cindex problem sets
@cindex Mr. Potatoehead
@cindex floppies
The key to the filing cabinet can be obtained from the instrument desk.
If the desk is closed, an extra key may be found in the server closet,
on the chain hanging by the light switch.

The top drawer of the filing cabinet contains extra copies of the
problem sets and solutions.  If a student requests a copy of a current
(or previous) problem set, give it to him only after making sure it
isn't a draft version (these usually say @sc{draft} in big letters on
the top).  If there are no copies of the legitimate problem set
available in the lab, students should try the 6.001 tutorial area
(36-115) or the office of the course secretary.

The top drawer also contains such other useful things as a stapler,
which students tend to ask for a lot, extra floppies, etc.  A few copies
of "Don't Panic" and of the text itself, as well as other references
(including such winning documents as the Scheme Reference Manual) can
usually be found in the "Head LA" drawer---these are more of a benefit
to the LAs than the students.  Oh, and if you are inside the "Guano"
drawer, don't knock out Mr. Potatoehead [sic.].  Other drawers are less
interesting.

Again, @strong{lock the filing cabinet} after you are done using it.

@c ----------------------------------------------------------------
@subsection Sign-up Sheets
@cindex sign-up sheets
@cindex Fnord!
Putting up sign-up sheets is a responsibility of the head LA.  You
should familiarize yourself with the sign-up rules posted below the
sheets, however.  On busy nights, people might try to cheat by signing
up for more than one slot at a time.  If you notice this, or if a
student complains to you about this, you should Fnord! act according to
the rules.

@c ----------------------------------------------------------------
@subsection Drop Cards
@cindex drop cards
Drop cards printed on the spot!  Explore one of the nicer features of
the system, @kbd{M-x print-drop-card}.@footnote{Actually, it would be
nice if someone would extend it to be even more of a feature.}

@c ----------------------------------------------------------------
@section Passwords, Codes, Locks
@cindex server closet
@cindex hacker account
@cindex filing cabinet
Besides the lab door codes, you have to remember the server closet door
code and the hacker password.  Both of these will be given to you at the
first LA meeting.  Please remember them (don't rely on them being
written down or saved somewhere, like your mailbox), since you will be
pretty much helpless without them in times of crisis, and use them
wisely.@footnote{@emph{You} are more trustworthy than all the Buddhas and
sages.}

Even more importantly, don't let the students find out what they are.
Knowing the hacker password allows students to copy each others' work,
not to mention the damage they can do to the system.  A little knowledge
is a dangerous thing.

Be @emph{super} careful when opening the closet door (yes, this means
pressing your body against the door and covering everything that remains
to be seen with a palm of one hand while pushing the buttons with the
other).  Remember: the closet contains the two servers, the key from the
filing cabinet, the printer paper, and more.  If some well-meaning
curious student gets in there, we're toast!

@c ----------------------------------------------------------------
@section Other Lab Policies

@c ----------------------------------------------------------------
@subsection Food
@cindex food
There is absolutely, positively no food or drinks allowed in the lab.
Whenever you see a person come in with food or in the process of eating
something, say in a very serious, official tone of voice "Excuse me, but
there's no food in the lab.  Please finish eating it right now.  And...
can I have some?"  Better plots will wait until we get a big picture of
Dr. Professor Hal Abelson with a piece of pizza in one hand and a bottle
of Coke in the other to hang on the wall.

@c ----------------------------------------------------------------
@subsection Frisbees
@cindex frisbees
@cindex filing cabinet
There is absolutely, positively no frisbee throwing allowed in the lab,
except when done by LAs (not on duty) on Thursday nights.  (There are a
few nice glow-in-the-dark frisbees, courtesy of Burger King, stored in
the "Kipple" drawer of the filing cabinet.)  Posting of the signs to
this effect will be postponed until more frisbees are obtained to hang
underneath the signs.

@c ----------------------------------------------------------------
@subsection Phone
@cindex phone

If you are not helping someone, answer the phone (no, only if it rings,
dupe).  The list of possible responses is hanging on the wall, by the
phone.  The standard one is "00 Lab."  The more creative ones include
"Hello, I'd like to order a pizza," "This phone booth reserved for Clark
Kent," "What?"  "Yo, Idaho!" "Are you a turtle?" and, of course, "Where
the hell is DML?"

By the way, in case @emph{you} ever need to call the lab, the phone
number there is x3-7976.  The thing to do when calling (unless you are
actually trying to accomplish something) is to wait for some clueless
person to answer with "001 Lab." If that happens, respond with "Oh,
sorry, I wanted the 004 Lab," and hang up.  Ones and fours can be
switched appropriately.

@c ----------------------------------------------------------------
@subsection Alarm
@cindex alarm
If the room alarm starts whining, turn it off.  Basically, you have to
wave your hands a little by the door to the lab.  But don't just do it;
make it dramatic and look important.  This works especially well when
you're on rollerblades, but---oh, did I forget to mention?---there is
absolutely, positively no rollerblading in the lab, and there's even a
$25 fine.

@c ----------------------------Chapter 3----------------------------
@node Software, Crises, The Lab, Top
@chapter Software in the Lab
@cindex u6001 account
@cindex hacker account
There are only a few user accounts on the system.  The two you should
worry about are u6001 (with the inconspicuous password u6001, as the
dialogue box readily reveals), which all 6.001 students use, and the
hacker account, existing mainly for the purpose of unwedging students,
the password to which will be given to you in the first LA meeting and
as it changes.  We will first discuss the student band, as you will
spend most of your time dealing with it, then talk about the hacker
account and privileges.

@c ----------------------------------------------------------------
@section General Software Setup
@cindex UNIX
@cindex DOS
@cindex Edwin
@cindex Edwin xterm
@cindex floppies
When you login as u6001, an Edwin window (Scheme running Edwin) is
automatically started for you.  You will be doing most of your work
inside the Edwin window, although opening an xterm might prove useful,
especially when unwedging people.  You can open an xterm (and, also,
xclock and xload) by pressing the left mouse button and selecting the
appropriate label.

As any respectable system would have it, there are three levels of
abstraction you should worry about.  At the bottom level is the
underlying UNIX (also, the floppies use MS-DOS format).  On top of that
is bare Scheme, the manifestation of which is the so-called Edwin xterm
window in the bottom right hand corner of the screen.  Finally, there is
the student Scheme environment, running Edwin (that is, your
Scheme/Edwin process is the child of the process running bare
Scheme---you can verify that by typing @kbd{ps -ef} in an xterm and
observing the results).  Edwin itself is written in Scheme.  We will
discuss the things you should know about each of the levels starting
from the top.

@c ----------------------------------------------------------------
@section Student Scheme/Edwin
@cindex student environment
The "Don't Panic" manual is a good source if you want to familiarize
yourself with the student environment.  In this section, you will find
things that are not covered in the manual or those which we want
emphasized.

@c ----------------------------------------------------------------
@subsection Scheme Debugger
@cindex debugger
@cindex Fnord!
@strong{Learn how to use the debugger.} As an LA, you will spend a
majority of your time debugging students' code, so you should be
comfortable with the Scheme debugger.  Refer to "Don't Panic" for
initial info.  You will find (as soon as you stop whining that noone has
taught you how to use the debugger and just try it) that it really is
quite easy to use.  For starters, write and try to execute a buggy
procedure, answer @kbd{y} when prompted by Edwin on whether you want to
enter the debugger, and type @kbd{C-h m} to get a list of commands.  

You will find that sometimes---whenever a student's code runs on top of
a big chunk of source code, as is often the case in problem sets
involving graphics, for example---the debugger is not very helpful,
since it mostly shows you what happens to the expression being evaluated
as the source code, not the code the student wrote, is being run.  The
debugger is particularly useless if the source code is compiled, and it
usually is.  That is probably not a feature, but there is not much you
can do about it.  Try to get @emph{some} information out of the
debugger, but, if all fails, resort to some other method of debugging.

Encourage students to learn to use the debugger as well.  Most of them
have an inexplicable paranoia of it Fnord! which overtakes them and
forces them to type @kbd{n} whenever the friendly Edwin tries to help
out.  Show them how easy it is; just a simple @kbd{C-h m} goes a long
way.  Teaching the students some of the basics will ultimately save you
a lot of work, not to mention that it will deny them another excuse to
use you as a human debugger and force them to be more independent.

@unnumberedsubsubsec Things to Look for when Debugging

While we are on the subject of debuggery: you will find that, especially
at the beginning of the term, students will be generating many
predictable, classifiable bugs.  Infinite loops, for example, are
usually rather obvious.  Another common bug in the beginners' code is an
unused definition (e.g., writing an internal iterative procedure without
ever calling it).  Later in the term, there will be quite a number of
students wedging themselves by not being careful with their parentheses.
An easy way to fix that is to always start your debugging by going to
the beginning of the definition and typing @kbd{C-M-q} (next section
describes this and other indentation commands).  You don't want to spend
half an hour staring at a piece of code only to realize that some parens
were in the wrong place.  Seems rather obvious when dealing with a
LISP-like language, but an amazing number of people needs to be reminded
of this particular feature of Scheme.

There are also some more obscure, but still rather common, error
messages.  "Anonymous arithmetic error" means a piece of compiled code
tried to do some arithmetic and suddenly lost; it's usually caused by
division by zero.  If you find something else that pops up a lot, bring
it up---there are usually different common bugs associated with
different problem sets.

@c ----------------------------------------------------------------
@subsection Useful Edwin Commands
@cindex Edwin
Edwin is just a version of Emacs written in Scheme.  Thus, most of Emacs
commands work in Edwin.  Here we remind you of the most useful ones
(students usually neglect most of these and resort to the more primitive
means of achieving their goals, which really is a pity; you might try to
open the eyes of the more clueless ones and save them and, consequently,
yourself a lot of time and frustration).  They should be tatood upon the
eyelids of the more clueless students.

@c ----------------------------------------------------------------
@unnumberedsubsubsec Motion

@table @kbd

@item C-n, C-p, C-f, C-b
Use these to move up (previous), down (next), forwards and backwards.
Don't use the losing arrow keys.  

@item C-a, C-e
Moves the cursor to the beginning/end of the line.

@item C-M-a, C-M-e
Moves the cursor to the beginning/end of the definition.

@item M-<, M->
Moves the cursor to the beginning/end of the buffer.

@item C-v, M-v
Scrolls to next/previous screen.
@end table

@c ----------------------------------------------------------------
@unnumberedsubsubsec Multiple Windows

@table @kbd

@item C-x o
Switches you to another window.  You @emph{do not} need your mouse to do
this! 

@item C-x 2, C-x 5
Splits the current window in two vertically/horizontally.

@item C-x 1
Deletes all windows but the current one.
 
@item C-x 0
Deletes the current window.


@item C-x ^, C-x @{
When used with a numeric argument, allows you to extend the length
of a vertically-split window/width of a horizontally-split window by a
number of lines indicated;  negative argument makes it shrink.
@end table

@c ----------------------------------------------------------------
@unnumberedsubsubsec Buffers, Files, Directories

@table @kbd

@item C-x b
Switches you to another buffer after prompting for its name (the default
is the latest visited buffer).  If the buffer doesn't exist, creates it.
Some students get wedged when they use this command to create new
buffers, since they expect a file under the same name to be created as
well---this is not the case.  Tell them to use C-x C-f instead.

@item C-x C-b
Lists all buffers.

@item C-x C-f
Finds a file (hit @key{TAB} to see your choices at any point);  if the file
doesn't exist, creates it in the current directory.  This can also be
used to get the directory listing---just hit @key{RET} after the name of
the directory. 

@item C-x C-s
Saves the current buffer to a file under the same name.  If the file
doesn't exist, asks you for the name of the file to write to.

@item C-x C-w
Saves the current buffer, prompts for a name of the file to save to.

@item C-x d (M-x dired)
Produces the directory listing.  Hit @kbd{C-h m} for the commands in
this buffer.  Also, a short listing of files in the directory can be
accessed by issuing @kbd{C-x C-d}.
@end table

@c ----------------------------------------------------------------
@unnumberedsubsubsec Search and Query Replace

@table @kbd

@item C-s, C-r
Prompts you for a string to forward/backward-search for (the default is
the last thing you searched for).  To continue the search, press
@kbd{C-s} or @kbd{C-r} again.  The students usually look for things by
going up and down and up and down using the arrow keys---which is
@emph{not} very efficient. 

@item M-x query-replace
Replaces one string by another.  You will be given an opportunity to
either make the change (press @key{SPC}) or not (press @kbd{n}) at
every occurence of the string.  Type @kbd{!} to replace @emph{all} the
occurences.
@end table

@c ----------------------------------------------------------------
@unnumberedsubsubsec Indentations

@table @kbd

@item @key{TAB}
Correctly indents (pretty-prints) the current line with respect to the
previous line (another use of @key{TAB} is for completions; see below).

@item C-M-q 
Indents each line of the following form (s-expression).  This is an
extremely useful command, since you can usually tell whether the parens
are matched properly just by looking at the indentation.  

@item C-M-f, C-M-b
Finds the matching parenthesis to the one the cursor is currently on.
This, as you might imagine, is also quite helpful.
@end table

@c ----------------------------------------------------------------
@unnumberedsubsubsec Killing and Yanking

@table @kbd

@item @key{BS}
@cindex helping students
Kills the character to the left of the cursor;  does not enter it on the
kill ring.  Students @emph{love} using it because it is so primitive.
Don't wait for them for half an hour to delete a couple of lines like
this; tell them about @kbd{C-k}.

@item C-d
Kills the character the cursor is currently on;  does not enter it on
the kill ring.  

@item C-k 
Kills everything on the line to the right of the cursor, putting the
deleted text on the kill ring so it can be yanked later.  

@item C-@key{SPC}
Sets the mark.  

@item C-x C-x
The exchange point and mark command (point is where the cursor is).
Shows you where the mark is. 

@item C-w
Kills the marked region.  To mark the region, set the mark at the
beginning of the region with @kbd{C-@key{SPC}} and go to the end of the
region.  

@item M-w 
Enters the region onto a kill ring without removing it from the screen;
used to copy text as opposed to cutting and pasting.  

@item C-y, M-y 
@kbd{C-y} yanks the last piece of text on the kill ring (the text you
deleted by the means of either @kbd{C-k}, @kbd{C-w} or @kbd{M-w}).
@emph{After} typing @kbd{C-y}, you can keep trying @kbd{M-y} to recall
the text killed earlier.
@end table

@c ----------------------------------------------------------------
@unnumberedsubsubsec Completions

@table @kbd

@item @key{TAB}
Completes command names/filenames/etc. in the minibuffer; if several
completions are possible, displays the choices available.  Again,
students usually ignore this and type @kbd{M-x load-problem-set}, for
example, while, in fact, @kbd{M-x lo @key{TAB} p @key{TAB}} will achieve
the same result;  illuminize them, please. 

@item M-@key{TAB}
When used in the @file{*scheme*} buffer, completes the names of
procedures, both primitive and the ones currently defined in the global
environment (actually, you can use this inside the debugger, too, in
which case it is not the global environment, but the environment of the
frame you are currently in---winning, isn't it?); also displays available
choices in case of ambiguity.
@end table

@c ----------------------------------------------------------------
@unnumberedsubsubsec Evaluating Scheme Expressions

@table @kbd

@item C-x C-e
Evaluates the expression just before the point regardless of where it is
in relation to the parentheses.  I advise you to use this instead of
@kbd{M-z}.

@item M-z
Evaluates the current definition (searches backwards for a left paren on
the left margin, then searches forward to find its mate, evaluates the
expression in between).

@item C-M-z (M-x eval-region)
Evaluates a marked region.

@item M-o
When used in a scheme-mode buffer, evaluates the entire buffer (any
buffer with a name that ends in @file{.scm} is in scheme mode by
default; otherwise, use @kbd{M-x scheme-mode} to change the mode to
scheme mode).  Cannot be used in the @file{*scheme*} buffer.

@item M-p 
When used in @file{*scheme*} buffer, yanks the latest expression
evaluated.  May be used over and over to recall previously evaluated
expressions.
@end table

@c ----------------------------------------------------------------
@unnumberedsubsubsec Printing

@table @kbd 

@item M-x print-buffer
@cindex printers
Prints the current buffer; the default printers are sicp-48 for machines
sicp-02 through sicp-24 and sicp-49 for the rest.  To change the default
(in case one of the printers isn't working), type @kbd{M-x set-variable
@key{RET} lpr-switches @key{RET} '("-Psicp-49")} to print to sicp-49, for
example.  To print without a header page, make that @kbd{'("-h
-Psicp-49")}. 

@item M-x print-graphics 
Prints the picture displayed in one of the graphics windows.  You can
specify which window to print from by either giving its name (what it is
bound to in your Scheme) or clicking on it (the default option).

@item C-q C-l 
Quotes @kbd{^L}, which forces a page break on that line.  @kbd{C-q} in
general is used to quote things.
@end table
          
@c ----------------------------------------------------------------
@unnumberedsubsubsec Help Commands
@cindex help
@table @kbd

@item C-h C-h
Your basic help command; gives you a bunch of options and is pretty much
self-explanatory.  

@item C-h m
Use it to get mode-specific information.

@item C-h t
Activates the Emacs tutorial.

@item M-x apropos 
Prompts you for a topic and delivers a list of commands including short
descriptions of their functions on that topic.  One of the most
effective ways of getting help fast.

@item M-x manual-entry
This is equivant to Unix @kbd{man} command but nicer, because the manual
entry is placed in a buffer which obeys Edwin commands.
@end table

@c ----------------------------------------------------------------
@unnumberedsubsubsec Other Commands

@table @kbd

@item
@cindex feedback
@cindex bug reports
@item M-x mail
Used to send (anonymous) mail.

@item M-x info
@cindex info
Activates the info tree; see Chapter 2 for more information.  

@item M-x load-problem-set 
@cindex problem sets
Loads a problem set (the current one by default) into Scheme.  

@item M-x checkpoint-floppy 
@cindex floppies
Saves all the files in the @file{~u6001/work} directory onto the floppy
in disk drive.

@item M-x logout
The proper way to logout.

@item M-x repl
If a @file{*scheme*} buffer exists, switches you there; else initiates a
new read-eval-print loop (creates another @file{*scheme*} buffer).
Useful when students wedge themselves by either killing their
@file{*scheme*} buffer or saving it under a different name.

@item M-x scheme-mode
Puts the current buffer into scheme mode (this enables @kbd{M-o},
pretty-printing, etc.).  All @file{.scm} buffers are supposed to be in
scheme mode by default, but sometimes something funny happens.  If
@kbd{M-o} isn't working or things are not getting indented properly, try
this command.  

@item C-c C-c 
Cancels the command; gets you out of whatever you were doing.
@end table

@c ----------------------------------------------------------------
@section Bare Scheme
@cindex Edwin xterm
There really isn't much you need to know about the underlying bare
Scheme.  Sometimes the Edwin xterm window can be used to recover hung up
Scheme processes, but that rarely works so don't count on it.
Basically, typing @kbd{C-g} or @kbd{C-c C-c} inside Edwin xterm
transfers control from the Edwin window to the Edwin xterm (you can then
type in Scheme expressions at the REPL prompt and evaluate them simply
by pressing @key{RET}).  Type in @kbd{(edwin) @key{RET}} to return
control back to Edwin.  You can familiarize yourself with some other
interrupt commands inside the Edwin xterm window by de-iconizing it and
typing @kbd{C-c} followed by @kbd{?}.  See the chapter on crises for
info on how these can be used to try to unwedge people's Schemes.

Beware that, since the window is readily available for people to play
with, students will sometimes wedge themselves by doing just that.  In
particular, @strong{closing the Edwin xterm window will kill your Scheme
process and log you out} (this is probably the only way to @emph{really}
make yourself lose by not logging out properly---aside from totally
wedging your Scheme---since @kbd{C-x C-c} is disabled in the student
environment, and even closing your Edwin window is possible only after
all the files you care to save have been saved, so they can at least be
recovered.).  Whenever you see students fiddling with the Edwin xterm,
tell them not to.

@c ----------------------------------------------------------------
@section UNIX/DOS
@cindex UNIX
@cindex DOS
This is the good old losing UNIX we all know and love.  Use your xterm
to talk to it (you can also open a shell with @kbd{M-x shell} and use
that, but most people don't enjoy the experience).

@c ----------------------------------------------------------------
@subsection The u6001 Home Directory
@cindex u6001 account
@cindex @file{motd}
@cindex problem sets
@cindex @file{work} directories
@cindex login 
@cindex logout
@cindex floppies
@cindex Fnord!
Most of the relevant files/subdirectories are located in the u6001 home
directory.  One such file is the @file{motd} file discussed earlier.
The file is writeable by hacker but not by u6001, so you have to either
be logged in as hacker or "su" to be able to make changes to it.  Refer
to the section on @file{motd} in an earlier chapter for more information
on when and how the @file{motd} file should be changed.

The @file{~u6001/psets} directory contains all the problem sets.  The
file @file{probsets.scm}, again writeable by hacker, is also there; you
will need to edit it in order to change the default of @kbd{M-x
load-problem-set}.  See the relevant section in Chapter 2 for more
information.

The @file{work} subdirectory is where the student's files are copied
from his/her floppy if (s)he logs in with the floppy option.  Needless
to say, this directory is different on each machine, and students cannot
access Fnord! each others' @file{work} directories, for security
reasons.  There are also three other subdirectories, @file{work.~1~},
@file{work.~2~}, and @file{work.~3~}, used to store the work of the
people who were the previous (most recent) users of the machine.  This
is a safety measure; it allows us to recover students' work when their
Schemes get wedged, their floppies get corrupted, and other kinds of
natural disasters happen.  @file{Work.~1~} contains the work of the most
recent user, and so on.  These directories get shuffled on student login
and logout---see the section below about what happens on login/logout
for the exact procedure.  Again, the files contained in these
directories are not readable or writeable by students because of
security issues, so you have to have hacker privileges to be able to
recover their work.

@c ----------------------------------------------------------------
@subsection Telnet and Ftp
@cindex telnet
@cindex ftp
@cindex Athena
You can telnet out of the lab by typing @kbd{telnet @var{destination}}
from an xterm.  To telnet to Athena, for example, type @kbd{telnet
athena.dialup} or @kbd{telnet athena-x} if you want X applications.
When prompted for the display you're using, type the name of the machine
you are on---e.g., @kbd{sicp-23}.  Telnetting @emph{into} the lab is
disabled, since we don't want strangers to use the most powerful
machines on campus at the expense of 6.001 students.

Similarly, you can use ftp to transfer files to and from Athena or any
other accounts you might have, by typing @kbd{ftp @var{destination}}.

@c ----------------------------------------------------------------
@subsection "Su"ing to Hacker
@cindex hacker account
@cindex Edwin
To "su" to hacker when logged in as u6001, type @kbd{su hacker} at an
xterm prompt.  You will be prompted for a password.  Be careful when
typing it in; make sure the students don't find out what it is.  Once
the password is verified, you can do anything hacker can do (your Edwin
window will still think you're u6001, but that shouldn't be much of a
problem, as you probably won't be using it anyway).  When you are done
doing whatever it was you needed to "su" to hacker for, type @kbd{exit}.
Don't forget to do this; if a student discovers (s)he has hacker
privileges, a lot of damage can be done to the system.

@c ----------------------------------------------------------------
@subsection Making Software Changes on Both Servers
@cindex software changes
@cindex servers
@cindex printers
@cindex Law of Fives
@cindex @file{motd}
@cindex problem sets
There are 46 snakes in the lab, sicp-02 through sicp-47, not including
the two servers, sicp-00 and sicp-01, and two printers, sicp-48 and
sicp-49.  That's 23 @code{*} 2, or 23 machines per
server.@footnote{Whadya know?  By the way, the Law of Fives also
applies: go ahead and count the number of chapters within this very
document and the number of subsections within this particular section.}
Machines sicp-02 through sicp-24 are connected to the server sicp-00 and
the printer sicp-48, the rest to the server sicp-01 and the printer
sicp-49.  The most important consequence of having two servers is that
@strong{all the software changes should be made on both servers}, so
that @emph{all} the machines remain up-to-date.  Synchronicity is your
friend.  You should remember that, specifically, when installing or
making changes to the problem set code, editing the message of the day,
changing the default of @kbd{M-x load-problem-set}, and altering other
things in the entire system.
@c For your information, there are also 17
@c [...well, I don't know what yet.  But I'll find something later, don't
@c worry].  For the benefit of the mehums, @math{23+17=40=(2+3)*(1+7)=5*8}.
@c Also, @math{2+3=5}, and @math{2^3=8}.  

You have to be logged in as/"su"d to hacker while making the changes.
If you are making the change from one of the sicp-00 machines---you are
logged in from sicp-05, for example---changing the appropriate file will
bring all the machines on that side up-to-date (i.e., the change will be
made to the code on sicp-00, the server).  To make the change on sicp-01
as well, type @kbd{cp @var{filename}
/nfs/sicp-01/users/u6001/@var{filename}} at the xterm prompt.  For
example, to copy the @file{motd} file when in the u6001 home directory,
type @kbd{cp motd /nfs/sicp-01/users/u6001/motd}.  To make sure the
change has been made correctly, do @kbd{more
/nfs/sicp-01/users/u6001/motd}.

@c ----------------------------------------------------------------
@subsection DOS
@cindex DOS
@cindex floppies
@cindex Athena
@cindex Fnord!
The floppy disks use an MS-DOS file format.  This is nice, because
students can work on their problem sets without having to come in to the
lab---i.e., they can type the code in somewhere else, like an Athena
workstation Fnord! or a PC, and use their lab time for debugging
purposes only.  If you know enough about DOS commands to use them to
copy stuff to disk, etc. and want to fool around with them, more power
to you---just make sure you don't make anyone lose in the
process@footnote{You can find out more about @kbd{dosls},
@kbd{doscp(1)}, and so on by typing @kbd{M-x manual-entry @key{RET}
doscp(1) @key{RET}}, for instance.  The floppy device is @kbd{/dev/rfd},
so, for example, to copy the file @file{foo.scm} to a floppy, you would
use @kbd{doscp foo.scm /dev/rfd:/foo.scm}}.  Usually, though, the only
command you need is @kbd{M-x checkpoint-floppy} (this is an Edwin
command, issued from your Edwin window), used to copy everything in your
@file{work} directory to the floppy.  The only other thing I've found
pretty useful so far that students often ask about is how to see the
contents of your floppy disk: in an xterm, type @kbd{dosls /dev/rfd:/}.

While we are on the topic of saving files to disk: by the end of the
term, checkpointing a typical floppy will prove to be quite a lengthy
affair, since students will accumulate all their work from day one on
their floppy disk.  Please advise them that at least all the @file{.bak}
(backup) and @file{.asv} (autosave) files can be deleted from the
disk---this will speed things up quite a bit.  Specifically, you can do
the following:

@page
@enumerate
@item 
% cd work

@item
% rm *.bak *.asv (this removes files from the @file{work} directory)

@item
After you do this, when executing @kbd{M-x checkpoint-floppy} or
@kbd{M-x logout}, you will be asked whether these files should be erased
from the floppy.  Answer yes.

@end enumerate

@c ----------------------------------------------------------------
@section What Happens on Login/Logout
@cindex login
@cindex logout
@cindex @file{work} directories
@cindex recovering files
@cindex u6001 account
@cindex hacker account
The login/logout procedure outlined in this section has been changed
around a lot ever since the system was setup.  It is still unclear if it
is the right thing.  While the description below is accurate as of the
time of this printing, it may change over time.  The relevant files to
consult for reference are @file{~u6001/.xsession} and most of the files
in the @file{~u6001/bin} directory, such as @file{login},
@file{logout}, @file{rotate}, etc.

When you are a u6001 user, on logout (this is a clean logout, caused by
executing @kbd{M-x logout}) the files in your @file{work} directory get
shifted over to @file{work.~1~}.  The files in the other @file{work}
directories get rotated accordingly.  The events are, in this order:

@need 1000
@enumerate
@item
The @file{work.~3~} directory is deleted.

@item
@file{Work.~2~} is renamed @file{work.~3~}.

@item 
@file{Work.~1~} is renamed @file{work.~2~}.

@item 
@file{Work} is renamed @file{work.~1~}; protections are changed to make
the new @file{work.~1~} directory unreadable by u6001.

@item
The new @file{work} directory is created, with appropriate protections.  
@end enumerate

It is unclear, however, what happens on an unclean logout---e.g., a
Scheme crash---since the logout script may never have been run.

Therefore, there exists a mechanism run at login time which should
detect unclean logouts, explain the situation, and ask if the user wants
to recover any possibly unsaved work.  If (s)he says yes, the script
prompts for the hacker password.  If the student answers no, the
@file{work} directories are rotated as usual.  See chapter 4 (the
section on software crises, case 3) for details.

If someone somehow gets their files rotated away from them, there is a
setuid script called @file{unrotate} in the @file{bin} subdir, that
prompts for the hacker password (i.e., you needn't be logged in as
hacker).  To run it, type @kbd{~u6001/bin/unrotate} in an xterm.  This
will do the obvious thing: move the @kbd{work.~1~} files up to
@file{work}, and so on.

When you login as hacker, no rotations happen.  Thus, logging in as
hacker may be useful when recovering students' work, since you know for
sure that it is still somewhere around---in the @file{work} directory if
no rotation has been done, or in the @file{work.~1~} directory in case
of proper logout.  See the chapter on crises for more information on
when to login as hacker and when as u6001, and on how to recover
students' files.

@c ----------------------------------------------------------------
@section Hacker Account
@cindex hacker account
@cindex Edwin
@cindex Athena
@cindex ftp
@cindex recovering files
@cindex login
@cindex floppies
@cindex @file{motd}
@cindex Fnord!
When you login as hacker, a Scheme process is not started for you
automagically.  If you want to start one up, open an xterm and type
@kbd{edwin &} for a regular Edwin window or @kbd{edwin -band 6001.com &}
for a student band (probably the only difference you'll notice is that
you don't get all the silliness about the floppies, motd, etc. when
using the regular band).

The @file{hacker} Fnord! home directory doesn't contain anything really
interesting.

Be careful if and when you create temporary subdirectories in the
@file{hacker}, @file{u6001} or any other directory (sometimes you might
want to do that in the process of recovering some student's files, for
example).  If the files contain anything resembling problem set
solutions (and they usually do), make sure they are not readable by
u6001 so as to not promote cheating.  Try to avoid creating such
subdirectories at all; there are usually ways around it.  Similarly, if
you are using the @file{hacker} directory to temporarily store your own
problem set solutions, make sure they are not available for public use.
And @strong{please clean up after yourself}.  Store your work on your
floppy, or ftp it to your Athena account if you have to, but don't leave
it hanging around.

There are really no advantages to logging in as hacker in non-crisis
situations.  (In times of crisis, on the other hand, it may prove
necessary to do so, since logging in as hacker does not rotate the
@file{work} directories, whereas a normal u6001 might.  See the next
chapter for more information on these kinds of situations.)  When the
lab is not busy and you find yourself spending most of your time at the
terminal, however, you may use whichever account you find more
agreeable.  For one thing, the default size of hacker xterms is much
more Fnord! sensible than the one used by u6001.

@c ----------------------------Chapter 4----------------------------
@node Crises, Students, Software, Top
@chapter Crises, Big and Small
@cindex help
@cindex instrument desk
@cindex immanentizing the Eschaton
Most of the crises that occur in the lab, such as students wedging their
Scheme processes or paper jams in the printer, are of a rather routine
nature.  You will get the hang of these rather quickly and will usually
have no problems dealing with them.  If something extraordinary happens,
however---a server dies, for instance, or it looks like someone is about
to immanentize the Eschaton@footnote{In other words, bring the end of
the world closer.}---and you don't know what to do or need help in
dealing with the situation (when the server dies, for example, you will
probably appreciate a few warm bodies who know the hacker password and
can recover people's work present in the lab), use all the means known
to you to summon help.  Send out e-mail, if you can, since quite a few
people on the staff are addicted enough that they will actually read it
within minutes after you send it.  Don't hesitate to call the head TA,
head LA or lecturers at their offices or at home, if needed (you can
probably find out their phone numbers by fingering them).  Get the
instrument desk people to help you out.

@c ----------------------------------------------------------------
@section Hardware
@cindex hardware problems 
@cindex instrument desk
@cindex filing cabinet
Whenever you encounter a hardware problem (such as a machine not
operating correctly) that you cannot fix yourself, do @emph{all} of the
following: report the problem to the instrument desk, send mail to
@code{6001-feedback}, and put a blue tag on the machine, filling in the
problem, your name, and the date.  The tags can usually be found either
on top or in the top drawer of the filing cabinet.

@c ----------------------------------------------------------------
@subsection One Machine Dies/Acts Funny

@c ----------------------------------------------------------------
@subsubsection Circuit Breaker Problems
@cindex circuit breakers
@cindex rebooting
If a snake is showing no signs of life (specifically, the heartbeat
light, which is the first one on the left, is not blinking), the problem
is usually a tripped circuit breaker.  Unfortunately, this happens more
often than it should, because the cheap circuit breakers in the lab are
flakey and unreliable.  There are two circuit breaker boxes on the 001
side of the lab, one, to the right of the Lambda Lounge, by the help Q
board (#1), another to the left of the lounge, close to the blackboards
at the back of the room (#2).  To recover a machine in case its circuit
breaker trips:

@enumerate
@item
Get under the table on which the machine is standing.  Find one of the
cables that lead from the machine to the power outlet, and read off the
number written on the outlet corresponding to the cable (be sure to get
the correct cable---you don't want to get the wrong number and make a
student on a neighboring machine lose by playing with the wrong circuit
breaker).

@item 
Proceed to the appropriate circuit breaker box, according to the number
you read off.  For example, 2-23 means it's box #2.  Open it and look
for the breaker labeled 23.  If the number is correct, the corresponding
breaker should look different from the other ones: it will not be lined
up with the others but will usually be in the dead center
position.@footnote{Some of the flakier circuit breakers might not change
their appearance when tripped.  Go ahead and turn the breaker on in the
manner described below, but only after making sure it is indeed the
right one---i.e., if there is one next to it that appears tripped, maybe
you got the wrong number in step 1.} To recover it, first push it all
the way @sc{off} (i.e., opposite the direction the other circuit
breakers point in), and only then bring it back to line up with the
rest.  The machine should now make some noise and show signs of life.
It will reboot and come around in a minute.
@end enumerate

If you notice that a particular machine experiences the circuit breaker
problem on a regular basis, report the problem in a manner described
above.

@c ----------------------------------------------------------------
@subsubsection Rebooting a Snake
@cindex rebooting
If you cannot get a snake to respond (i.e., the screen is locked up so
nothing you type is being acknowledged and the mouse does not respond),
you need to reboot it.  For soft reboot, press
@kbd{C-@key{SHIFT}-@key{RESET}}; it should only take a few seconds for
the machine to come around.  To powercycle the machine, press the white
power button, located at the bottom of the machine, below the disk
drive; hard reboot takes a little longer, maybe a couple of minutes.

@c [Does powercycling mean work.~ directories will not be preserved?  I 
@c don't think so, but make sure and say so.]

If the machine does not reboot properly, leave it alone and report the
problem (make sure to put a tag on it).

@c ----------------------------------------------------------------
@subsubsection A Machine Is Using a Wrong Version of a PS
@cindex @file{motd}
@cindex servers
@cindex hardware problems
If one machine seems to be using the wrong version of a problem set or
any other file, such as @file{motd}, chances are all the other machines
on that side of the room---i.e., connected to the same server---are
experiencing the same problem.  Check this by looking at the file in
question on both sicp-00 and sicp-01 and comparing the two versions; if
that is indeed the case, and @strong{only if you are absolutely sure
which of the versions is correct}, copy the correct version to the
losing server (see the section on how to make software changes to both
servers in the previous chapter).  If you are not sure what the correct
version is, don't try to guess; simply report the problem to the head
TA/LA.  In any case, the head TA should be informed if you encounter two
different versions of a file.

If the problem seems to be something else and you cannot figure out how
to fix it, ask the student to switch to another machine and put a sign
on the machine asking people not to use it.  In addition, report the
problem by following the procedure described above.

@c ----------------------------------------------------------------
@subsection A Server Dies
@cindex immanentizing the Eschaton
@cindex servers
@cindex help
@cindex server closet
@cindex circuit breakers
@cindex rebooting
@cindex recovering files
Speaking of immanentizing the Eschaton... Murphy's law says that the
first server crash must occur the night before a problem set is due, in
which case you will notice it momentarily, for it will be accompanied by
the sound of 46 students screaming, sighing, taking a deep breath, and
doing whatever else people do in times of crisis.  Don't panic.  Try to
calm the students down, too.  A server crash is a serious problem, but
their work can usually still be recovered.  Call for help right away
(you will need it even if you can fix the problem itself, to recover
people's work as fast as possible), get into the server closet (it is
located in the front of the lab, behind the printers), and start
investigating.

One of the ways a server can crash is the same way any machine does, by
means of a circuit breaker tripping.  The consequence of this, as you
might imagine, is that all the machines connected to that server panic
and crash as well.  To fix the problem, do what you would normally do in
a case of circuit breaker blowing (consult the section on circuit
breakers above).  The circuit breaker box for the servers is located
inside the server closet.

If the server crashes for an unknown reason, and is @emph{completely
catatonic}, the only thing you should try is powercycling it (see the
section on rebooting above): turn it off, wait a few seconds, turn it
back on.  If this doesn't help, do not spend the time in an attempt to
figure out what the problem is; get help immediately.  Do not even do
that much (i.e., don't powercycle the server) if it seems to be running,
since that is usually an indication of a different problem.
Powercycling a system with an active filesystem may cause data lossage,
and we only want that as our last alternative.

It will take quite a while for the machines to come back to life.  When
they do, start recovering students' work (see the software section below
to find out how).  Be extremely careful.  If you can find a student who
did @kbd{M-x checkpoint-floppy} recently and thus doesn't care if
his/her files get recovered, make his/her machine your first guinea pig.
If and when the reinforcement arrives, the total recovery shouldn't take
long.

@c ----------------------------------------------------------------
@subsection Printer Problems
@cindex printer problems
If you think there is a paper jam in one of the printers, lift the cover
of the printer by pressing the button on the left of the cover, and look
inside.  If no paper is visible, try pulling out the paper trays and see
if any paper is stuck on the bottom.  In addition, there is a side
access door; open it by pressing the left side of the printer in the
right magic place--the access door should pop open.  In any case, you
will usually be able to pull the paper out somehow.  If there is no
paper seen anywhere inside the printer, maybe the paper jam is not the
problem.

When the printer complains that the toner is low and does not print:

@itemize @bullet
@item
If the number following "toner low" is 1 or 2, you don't need to
replace the toner cartridge. Just lift off the cover, pull it out, shake
it up a little, and put it back in.  The printer should come back to life.

@item
@cindex instrument desk
If the number is 3, the toner cartridge needs to be replaced.  Go to the
instrument desk and ask for help.
@end itemize

If a printer goes catatonic with some weird error message, you can try
powercycling it.  

If one of the printers dies mysteriously or experiences a problem you
cannot fix yourself, report the problem.  Ask the students on the side
of the room with the broken printer as their default to switch printers,
by executing @kbd{M-x set-variable @key{RET} lpr-switches @key{RET}
'("-Psicp-48") [or 49]} in Edwin.  If both printers die, we are in
trouble; get help fast.

@c ----------------------------------------------------------------
@section Software
@cindex Fnord!
One of the more common software problems is the lack of synchronicity
between the code on the two servers---consult the section on making
software changes on both servers in Chapter 3 Fnord! to find out how to
bring the wrong versions of the code up to date.  The two others are
stray Scheme processes and people with wedged Schemes.

@c ----------------------------------------------------------------
@subsection  Machine is Slow:  Killing Extra Scheme Processes
@cindex slow machines
If a student complains that his/her machine is slow, check the network
lights.  If the machine is swapping, that is usually a sign that there
are some extra Scheme processes running on it, left over from previous
users (often the machines will be thrashing to death and students won't
even notice it).  Here is how to look for/get rid of them:

@enumerate
@item
Ask the student to save, Just In Case.

@item
Open an xterm.

@item
% ps -ef | fgrep scheme

@item
If there's more than one "scheme -edwin" process, look for the one that
has the "xterm ... edwin ..." process as a parent (the lines in the
fgrep output should have matching magic PID's).  

@item
Kill all the @emph{other} scheme processes (using kill without
options---i.e., % kill @var{PID}---works fine if you're doing it from a
student's xterm).

@item 
% exit
@end enumerate

You can also get rid of stale Scheme processes by typing
@kbd{~u6001/bin/killschemes} at the prompt; this will run the
appropriate script.  However, doing so will kill @emph{all} the Scheme
processes currently running on the machine which have u6001 as their
owner---@strong{including the student's Scheme}.  Needless to say, you
should not do this when logged in as u6001, unless you desire to kill
your current Scheme process and be logged out without even having a
chance to save your work on disk.

If the machine is slow but no extra Schemes are running, it may be the
case that the student is hosing it down by writing losing Scheme
procedures (for example, creating a lot of streams will slow down a
machine considerably).  Tell the students to at least kill their
xclocks, xloads, xterms, etc. to speed it up a little.  If the problem
seems to be something else, report it: it may be a hardware problem.

@c ----------------------------------------------------------------
@subsection Unwedging People With Dead Schemes
@cindex recovering files
@cindex autosave files
@cindex floppies
@cindex Fnord!
When a student's Scheme crashes, you get to (joy!) recover his/her
files.  Naturally, you can only recover as much as they have saved, so
if the student doesn't Fnord! believe in @kbd{C-x C-s}, some of his/her
work is bound to be lost.  Students should get into the habit of saving
@emph{often}; beat it into their heads every time a crash occurs and
they call you to recover their work.  The best way to save is by doing
@kbd{M-x checkpoint-floppy} after writing each significant chunk of
code, and especially @emph{before} running the code that is likely to
crash the machine (this happens a lot when dealing with streams, for
example, because it is easy to get into an infinite loop and run out of
memory)---this way, your help may not even be needed, since the versions
of the files read in from the floppy on login will be recent.  If
@kbd{M-x checkpoint-floppy} seems as too much trouble, the students
should at least do @kbd{C-x C-s} as often as possible.

There @emph{is} a fallback, though.  The system creates and updates an
@file{.asv} (autosave) file for each of the @file{.scm} files in the
@file{work} directory.  These @file{.asv} files prove to be pretty
useful; they get updated often enough that most of the time they contain
the more recent versions of the files than the @file{.scm} files
themselves.  Don't forget about them---sometimes they will save a
student a headache by recovering a good chunk of work that is otherwise
lost.  After recovering someone's files, show him/her the @kbd{.asv}
versions and ask him/her if those are more recent.  If that is the case,
and if the student would like the contents of @kbd{.asv} files to be
copied to the @file{.scm} files, from an xterm,

@enumerate 
@item
% cd work (if you're not already there)

@item
% cp @var{filename1}.asv @var{filename1}.scm  

@item
% cp @var{filename2}.asv @var{filename2}.scm ; and so on
@end enumerate

With regards to the machine crash itself, there are several kinds of
lossages which require recovery of students' files, and each dictates a
different kind of treatment.  We discuss them all below.  Note that this
is just @emph{one} way of doing things; there are other ways to go about
recovering files, some riskier than others.  You may like something else
better---use it at your will, but please make sure it is safe as to not
make students lose.  Here, I tried to come up with procedures which are
both fast and safe.

@c ----------------------------------------------------------------
@unnumberedsubsubsec Case 1:  Edwin xterm Saves the Day.
@cindex Edwin xterm
If the Scheme is hung up, but you can still manipulate your mouse, it is
possible (although not very likely) that you can bring the Scheme back
to life with the help of the Edwin xterm window.  After de-iconizing it,
(if not already in REPL) press @kbd{C-c C-c}; at the prompt, type
@kbd{(edwin) @key{RET}}.  If this doesn't liven up your Scheme, there's
not much you can do to recover the process itself (option @samp{R},
"hard reset possibly killing Scheme in the process," though it looks
vaguely promising, seems to justify the warning every time, indeed
killing Scheme in the process).  

Try at least recovering the files by typing @kbd{(save-editor-files)
@key{RET}}.  This will save all your buffers the files for which already
exist; it will also ask you whether you want to save other buffers, such
as @file{*scheme*}, @file{*transcript*}, and so on.  That can prove
useful to students who would like to save the transcript of their
work---to figure out what went wrong, for example, or in order to try to
get the bug to repeat.  @kbd{(Save-editor-files)} is an excellent
command (when it works), because the students don't lose any work.
However, it doesn't solve the problem of writing the saved files out to
the floppy.  You still have to follow the procedure outlined in the next
section to make sure the files which are now in the @file{work}
directory find their way to the student's disk.

@c ----------------------------------------------------------------
@unnumberedsubsubsec Case 2:  You Can Open an xterm.
@cindex @file{work} directories
@cindex logout
@cindex floppies
If you can get no help from Edwin xterm, but you still have control of
the screen---i.e., you can open an xterm---your best bet is to do the
following (the last eight steps of this procedure, 5 through 12, may also
be used to recover the work of a previous user of the machine who has
lost his/her floppy or some such thing; the only change is in step 8,
where the appropriate directory---@file{work.~2~} or
@file{work.~3~}---should be substituted for @file{work.~1~}.): 

@enumerate 
@item
Open an xterm.

@c @item
@c % su hacker

@c @item
@c % mkdir joe (for example; the name of the directory you create should
@c not be something obvious like @file{tmp} or @file{temp}, in case another
@c LA is doing something like this at the same time; that's why I use the
@c student's name)

@c @item 
@c % cd work

@c @item
@c % cp @code{*} ../joe

@item
% ps -ef | fgrep scheme

@item
Find the PID of your scheme -edwin process.

@item
% kill @var{PID} (this logs you out)

@item
Now log back in as u6001 (not hacker!), with the disk in drive.

@item
Open another xterm.

@item
% su hacker

@item
% cd ../work.~1~

@item
% mv @code{*} ../work

@item
% chown u6001 @code{*} (important!)

@c @item
@c % cd 

@c @item
@c % rmdir joe (clean up after yourself!)

@item
% exit

@item
In Edwin, do @kbd{M-x checkpoint-floppy}, so the student can go crash
again as soon as (s)he re-evaluates the code, and not really care. 
@end enumerate

The advantage of the above method is that it minimizes disk accesses,
and leaves the machine in a state where the student can continue work as
soon as file recovery is complete, without having to logout.  Logging in
as hacker in this kind of situation is unnecessary and will only
complicate things.  Since you issue the @kbd{kill} command, the logout
should proceed as normal, in the sense that the @file{work} directories
will be rotated.  Thus, you will be able to find the student's files in
@file{work.~1~}.
@c It can be argued that making a temporary directory is not necessary,
@c since the student's files are supposed to be copied to @file{work.~1~}
@c on logout, so they can be recovered directly from there.  However, it is
@c not clear this will always be the case when the logout is forced by the
@c kill command rather than by @kbd{M-x logout}.  If you are confident that
@c the files will be in the @file{work.~1~} directory when you log back in,
@c you may skip steps 2 through 5 and substitute @file{work.~1~} for joe in
@c step 12.  I tend to be safe and use the above method, though.

@c ----------------------------------------------------------------
@unnumberedsubsubsec Case 3:  No Keys are Responding
@cindex @file{work} directories
@cindex logout
@cindex rebooting
@cindex hacker account
If the screen is locked up completely and you can't open an xterm or
even move your mouse, your only alternative is to reboot the machine and
log back in to recover files.  It should still be safe to login as
u6001.  Presumably, if the logout was clean (i.e., if the directories
got rotated correctly), you can follow the procedure outlined in case 2
above (steps 5 through 12).  If, on the other hand, the logout script
did not get run, this will be detected on login.

As mentioned earlier, the login script checks for unclean logouts and,
if one is found, explains the situation to the user.  If the student
wishes to recover files, the system then prompts for the hacker
password.  With the correct password entered, directories are left
unrotated, and the student can continue the login process by selecting
the @strong{@kbd{N} option (practice login), not the default (@kbd{L})
option}.  Note that this means the student should use @kbd{M-x
checkpoint-floppy} before logging out, since @kbd{M-x logout} won't try
to save anything to disk.  Besides that, however, everything should
appear just the way it was before the crash---in particular, the
student's files will still be in the @file{work} directory, and nothing
will need to be moved.

@c login as hacker to recover files (In some cases, logging in as u6001, as
@c described above, will still work; howeve is no guarantee that the
@c @file{work} directory has been copied to @file{work.~1~} on logout, the
@c way it was supposed to.  Thus, I login as hacker to be safe.).  Refer to
@c the section on rebooting above to find out how to perform a soft reboot.
@c Note that it is @emph{necessary} to login as hacker if the student's
@c work is @emph{already} in @file{work.~3~}, since logging in as u6001
@c will hose it all.  Here is the entire procedure, remarkably similar to
@c the one above:

@unnumberedsubsubsec Case 4:  Student's Work is in @file{work.~3~}

While logging in as hacker may be considered a safe thing to do in some
situations, it is a @emph{necessary} action if the student's work is
@emph{already} in the @file{work.~3~} directory, since logging in as
u6001 will hose it all.  Here is the entire procedure, remarkably
similar to the one above (the major difference is that you need to
create a directory to temporarily store the student's files):

@enumerate
@item
Login as hacker. 

@item 
Open an xterm.

@item 
% cd ../u6001 

@item 
% mkdir joe (for example; the name of the directory you create should
not be something obvious like @file{tmp} or @file{temp}, in case another
LA is doing something like this at the same time; that's why I use the
student's name)

@item 
% cd work.~3~

@c @item 
@c Ask the student if these are his files, to be sure.

@item 
% cp @code{*} ../joe 

@item 
Logout;  log back in as u6001.

@item 
Open an xterm.

@item 
% su hacker

@item 
% cd ../joe

@item 
% mv @code{*} ../work

@c [@item
@c  % cd ../work

@c  @item 
@c  % chown u6001 @code{*}]

@item 
% cd 

@item 
% rmdir joe (clean up after yourself!)

@item 
% exit

@item 
In Edwin, do @kbd{M-x checkpoint-floppy}.
@end enumerate

Don't forget to remind students that @file{.asv} files may be more
up-to-date and that they may recover some of their lost work that way.

@c ----------------------------Chapter 5----------------------------
@node Students, Concept Index, Crises, Top
@chapter How to Deal with Students
@cindex Atlantis
@cindex Fnord!
Back in the old days, when LAs were called Lab TAs, when all we had were
ones and zeros, when Atlantis ruled the Earth... anyway, the point is
that missing T in LA, the one that stood for Teaching.  Remember what
your function in the lab is?  Fnord!  Helping students, dealing with
their problems and answering their questions, however
easy/hard/stupid/ridiculous they may seem (we all know by now Fnord!
that ALL questions are good questions), trying to @emph{make them
understand}.

@c ----------------------------------------------------------------
@section Helping a Student
@cindex helping students
When you are helping students, don't do their work for them.  Ask them
to show you the different pieces of code and to try running it for you.
@strong{Do not take over at the keyboard} for them.  Although this may
be frustrating when the student is slow, that is the only way they will
learn.  When the students are off on the wrong track, try to guide them
onto the right track, but don't solve the problem for them.  Don't let
students badger you into telling them the answers---that's not your job.

Try not to spend a lot of time helping a single student, especially if
the lab is busy.  Point the student in the right direction and let
him/her think about it some more.
                   
@c ----------------------------------------------------------------
@section Collaboration Policy
@cindex collaboration
It is a very good idea to get students to help each other, especially
when the lab is crowded and the LAs are swamped.  6.001 collaboration
policy states that "we are very much in favor of collaborative work:
students working together in small groups on problem sets---in working
through problems, planning programs, and programming in the lab---so
long as everyone is involved in all aspects of the work."  Take
advantage of this.  For example, when you encounter a person with a
question or problem similar to the one you just answered for someone
else, ask the person you just helped if (s)he would mind helping another
student.  You will find that most people are quite cooperative in this
respect.  Besides lessening your workload, this technique actually aids
the students, who may understand the issue better after explaining it to
someone else.

@c ----------------------------------------------------------------
@section Do not Get Angry
@cindex helping students
Do not get irritated at students, or, at any rate, don't show it when
you do.@footnote{I guess, the best analogy is "The customer is always
right."}  Helping them is not always easy and can be frustrating.  When
you think you are about to lose your cool, don't take it out on the
student---that will only make the situation worse.  Take a step back and
try another approach, or if there is another LA on duty, see if (s)he
can help.

In general, it helps to be relaxed and armed with a sense of humor.
Instead of blowing up when you are getting frustrated, laugh.

@c ----------------------------------------------------------------
@section What to do When you Feel Like you're in a Bad TV Show

Here is the (paraphrased) text of an e-mail message sent to
@code{6001-feedback} by a student (we'll call him Bruce) after one of
the 6.001 quizzes:

@quotation
[lecturers],

i came to mit because i wanted to graduate from a decent college and get
a reasonable job.  your test is going to stop all that.  i can't believe
you did this to me.  what am i supposed to do now?  i can't take any
more.  i hope you are below me.  this is on your heads.

goodby.
@end quotation

This is the kind of message you should not dismiss as an ordinary flame,
as we (a couple of us LAs on duty) once did when "Bruce" came in to the
lab to write it.  As it turned out, this particular bruce @emph{was}
just flaming; some students, however, may be quite serious in their
suicidal tendencies.  If you encounter anything of the sort, start
acting as if you were a character in Beverly Hills 90210: try to find
out how serious the student is and, if you think there is even the
slightest chance that (s)he @emph{is} serious, call the lecturers, the
CPs and/or anyone else you think could help or should know about the
situation.  Please take this seriously; MIT is a stressful place, and
6.001 can be a stressful subject, and things like this do happen.

@c ----------------------------------------------------------------
@section Quick Questions
@cindex quick questions
@emph{All} questions are good questions; however, @emph{no} question is
a quick question.  On the slowest and on the busiest nights, at the end
of the term as well as at the beginning, invariably, you will have
students coming up to you saying: "Can I ask you a QUICK QUESTION?"
You should learn that @emph{that} in itself is @emph{the only} quick
question anyone ever asks.  There are no others.  This is ok if the lab
is not busy and noone is waiting on the queue.  Even when there are a
couple of people waiting for help, you might try to answer the question
on the fly---if it is truly quick, you will not need to go to the
student's terminal (if, on the other hand, (s)he starts by "I wrote this
piece of code, and it doesn't work," throw up your hands in disgust and
tell him/her to enqueue him/herself and wait for his/her turn just like
everyone else).  The situation does not improve on the busier nights.
In short, pretty soon you find that the only workable answer when
someone says "I have a quick question" is "I have a quick answer...
NO@footnote{Or 42, or 23 Skidoo, or anything else you find amusing.}"
Just make sure you have a nice friendly grin on your face the entire
time.

All Hail Discordia!  and now even I am finished, and the only quick
question I have left is: did Joe Malik ever have any dogs?  and if he
did, how many?  and what happened to them after he went underground? and
what did he do with the dogfood? and if he didn't, what were the
neighbors complaining about?

The rest will be printed in Heaven.

@c -----------------------------------------------------------------
@c ---------------------- End of the Document ----------------------
@c -----------------------------------------------------------------

@node    Concept Index, , Students, Top
@unnumbered Concept Index

@printindex cp

@contents

@bye

@bye