The 6.001 Laboratory Assistant Manual

Niki Pantelias, Michael Ernst, John Buck, Luis Rodriguez,

Arthur Gleckler, and Paula Ferguson

October 28, 1991

Contents

1 About This Document 3 1.1 Formatting and LaTEX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 General 6

2.1 Athena . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1.1 Mailing Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2 Administrivia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2.1 Hours . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.2.2 Timecards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.2.3 LA Meetings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.2.4 Course Handouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3 What to do when you get to the lab . . . . . . . . . . . . . . . . . . . . . . . 10 2.3.1 Lab Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.3.2 Ethics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.3.3 The Help Queue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.3.4 Bug Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.3.5 Problem Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.3.6 The Sign-Up Sheets . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.3.7 Login Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.4 The Lab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.4.1 The Filing Cabinet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.4.2 The Blackboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.4.3 The Phone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.4.4 The Room Alarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.4.5 Off-hours access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3 Hardware 17

3.1 Printers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.2 Graphics Printers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.3 Chipmunks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.4 SRMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4 Software 22 4.1 General Software Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 4.2 Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 4.3 Edwin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 4.4 Bare Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 4.5 The Pascal System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.5.1 How To Get There . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.5.2 The Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 4.5.3 The Pascal Filer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 4.5.4 Kermit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.6 The Monitor or Assembly-Level Debugger . . . . . . . . . . . . . . . . . . . 32 4.7 Graphics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.7.1 Login Screen Pictures and Message . . . . . . . . . . . . . . . . . . . 33 4.8 Problem Set Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 4.9 Software Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 4.10 Updating the SRMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.10.1 Syntaxing Scheme source files . . . . . . . . . . . . . . . . . . . . . . 36 4.10.2 Generating a new 6.001 band . . . . . . . . . . . . . . . . . . . . . . 36 4.10.3 Copying SRMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 4.10.4 Copying SRM Boot Disks . . . . . . . . . . . . . . . . . . . . . . . . 39

Chapter 1

About This Document

This manual describes features of the 6.001 Chipmunk computer system (hardware and software) which are not described in the Don’t Panic manual and which may be useful to Lab Assistants (LAs). In addition, it describes administrative details of LA life (time cards, lab hours, etc.).

Please expand and revise this manual so that it can be an up-to-date compilation of the accumulated knowledge of generations of 6.001 Lab Assistants. The sources for this manual are currently on the Zurich file server at the Artificial Intelligence Lab (zurich.ai.mit.edu)

in the directory /scheme/documentation/6001labmanual.

Please maintain the style in which this manual is now written. Don’t delete large sections of text; rather, comment them out (along with an explanation of why they were removed) using the % character. Sections of text in [square brackets] need revision. A comment at the beginning of the modified section should indicate the date of each significant change, along with the name of the person who made the change.

1.1 Formatting and LaTEX

Briefly: \index{stuff} causes stuff to be put in the index. \idx{stuff} places stuff in the index and in the LaTEX output; this saves typing and replaces stuff\index{stuff}.

{\em stuff} emphasizes stuff, {\bf stuff} boldfaces it, {\tt stuff} puts it in typeout

font, and {\sc stuff} puts stuff in small caps (for names of buttons and knobs). (Note the placement of the brackets.) Use \key{stuff} to put stuff in a key box . Comments begin with % and run to the end of the line. Cross-references use \label{name} at the point of the text referenced with \ref{name} and \pageref{name} at the point of the reference.

Run LaTEX three times on the lab manual source file in order to guarantee a sensible index and table of contents; see section 1.2, page 5 for more details on producing the index. There are examples of all these formatting commands in this document.

1.2 Index

The index to this document was created using the windex program (written in C) and its associated macros, provided by Ron Rivest. Windex consists of four files, kept with the manual sources:

windex executable file; analogous to bibtex program

windex.c source file for windex program

windex.doc documentation for using the package

windex.tex macro to include

To create an index, make sure that the lines

\makeindex
\makeatletter
\def\@wrindex#1#2{\let\thepage\relax
   \xdef\@gtempa{\write#1{\string
      #2:\thepage}}\endgroup\@gtempa
   \if@nobreak \ifvmode\nobreak\fi\fi\@esphack}
\makeatother

are in the preamble of the document (before the \begin{document}). Then place \input{filename.index} where you want the index (probably at the end of the file). Windex is analogous to bibtex: that is, to guarantee correct output, run LaTEX, then run windex, then run LaTEX twice more. In general, LaTEX should be run twice on any input file to ensure that cross-references are correct. The initial LaTEX run and the windex run can be omitted if no new index entries have been made and if no existing entries have changed pages.

General

2.1 Athena

Every 6.001 Lab Assistant should have an account on Project Athena or some other computer network at MIT. All LAs should make sure that the head TA has their correct e-mail address, so that everyone can be included on the appropriate 6.001 mailing lists. LAs should get in the habit (if you are not already addicted) of reading their e-mail at least every couple of days. Notices about LA meetings and problem set bugs, requests for trading hours, and other important information is sent out via the LA mailing list, so you need to read your mail to stay up-to-date.

The Athena workstations in the lab are very convenient for checking mail and doing other small tasks while on duty. However, you should be careful not to get so engrossed in what you are doing on Athena that you neglect your duties as a lab assistant. Don’t try to staff the lab (especially if it is busy) and work on a paper or your 6.170 final project at the same time – you won’t do a good job on either. LAs should use only the two workstations that are in the 6.001 area (ie. don’t use the ones on the 6.004 side while you are staffing the lab) so that you are still accessible to students. Make sure to put a Lab Assistant sign on the computer you are using.

2.1.1 Mailing Lists

There are a number of useful mailing lists set up on a machine in the AI lab. To send mail to all of the people on one of the lists, send the mail message to list-name@ai.mit.edu. The names of the different lists and who is included on each one are listed below.

   6001-lecture@ai.mit.edu – The lecturer(s).
   6001-secretary@ai.mit.edu – The course secretary.
   6001-recitation@ai.mit.edu – The recitation instructors.
   6001-head-ta@ai.mit.edu – The head TA.
   6001-ta@ai.mit.edu – All the TAs.
   6001-head-la@ai.mit.edu – The head Lab Assistant
   6001-la@ai.mit.edu – The Lab Assistants.
   6001-staff@ai.mit.edu – All of the above

2.2 Administrivia

The head LA and/or head TA keep a list of all the LAs, their e-mail addresses, and their phone numbers. This list will be distributed to all the lab assistants soon after the beginning of the term. Copies of the list will also be in the top drawer of the file cabinet. You should make sure that the information on the list is accurate and let the head TA and head LA know if there are any changes.

The head TA and head LA also keep a schedule that details lab coverage. Once the schedule is set at the beginning of the term, copies will be posted in lab, placed in the top drawer of the file cabinet, and sent to everyone. If you permanently trade hours with someone else, you should let the head TA and head LA know, so that they can update the schedule.

2.2.1 Hours

LAs sign up for lab hours at the beginning of the term. The sign-ups are done by seniority, based on the numbers of terms that you have been an LA. LAs that have worked the same number of terms receive priority based on their class year. Once you sign up for hours, they are your responsibility for the rest of the term. 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. If no one is willing to take the hours, talk to the head LA and head TA to work something out.

If you cannot make a shift for some reason, it is your responsibility to get a replacement. The sooner that you start looking for a replacement, the better your chances of finding someone. If you know that you have a Thursday night exam coming up in three weeks that will prevent you from making your hours, start looking for help now. This means sending out e-mail and even calling individual LAs if necessary. The students are counting on the lab being staffed! If absolutely no one can take your hours, please let the head LA and the head TA know at least one day in advance. Canceling at the last moment is frowned upon, especially on days when the lab is busy.

LAs should try to help each other resolve scheduling conflicts whenever possible. If someone needs a replacement and you can cover the shift, help him or her out. It may be you that needs the replacement the next time.

2.2.2 Timecards

Timecards are picked up in the Course VI administrative office, 38-445. They should be filled out and signed by the LA and dropped off in a pendaflex folder in the upper drawer of the filing cabinet in the lab by 12 noon on Friday. The head TA will sign them and return them to the administrative office by 10:00 the following Monday morning so that you can get paid the following Friday.

You will need to go to the administrative office at the beginning of the term to fill out some forms so that you are on the payroll and a timecard is printed for you.

If you worked extra hours either because someone didn’t show up or because the lab was really busy and you decided to stay and help, you will, in general, get paid for those hours.

Make sure you let the head TA and the head LA know about it, so she or he will know what the extra hours on your timecard are for. Please don’t mis-interpret this as an OK to work extra hours whenever you wish. There is a fixed number of LA hours (and money) allocated each term by the department.

If you miss some hours for whatever reason, you are on your honor not to claim them on your time card. Because no one is monitoring lab coverage at all times, the head LA and head TA might not notice that you missed a shift. Then again, they might. However, it is certain that the students will notice.

LAs get paid for two additional hours every week for doing the problem sets. Just fill in the two extra hours on your time card each week. This means that you should do every problem set. Some problem sets will take more that two hours and some will take less, so it will balance out.

2.2.3 LA Meetings

LAs typically have a weekly meeting with the head TA, and sometimes one of the lecturers. The time and location of the meeting will be set at the beginning of the term, hopefully so that it fits into eneryone’s schedule. LAs should make every attempt to attend all of the meetings. If there is a conflict, you should let the head LA and the head TA know why you won’t be there.

The head TA will hand out upcoming problem sets (and sometimes solutions) at the meetings, as well as talk about what’s currently being covered in class. The meetings provide a forum for questions about a variety of things, including problem set bugs and mysterious Chipmunk behavior. They also allow LAs to get to know each other and work out schedule conflicts. Finally, the meetings are the LAs’ main contact with the rest of the 6.001 staff, which lets LAs know what’s going on with the course and also lets LAs offer feedback to the staff about specific problems that students are having with the material.

2.2.4 Course Handouts

LAs will receive copies of relevant course handouts, such as problem sets and lecture notes on subjects not covered by the book, at the weekly LA meetings. Sometimes the solutions for upcoming problem sets will also be distributed. If you miss getting important handouts, you should get them in lecture (TR10 in 10-250) or pick them up in the 6.001 tutorial area (36-115). The copies in the tutorial area tend to disappear quickly, so make sure you get one. Additional copies of problem sets may also be available in the top drawer of the file cabinet, but don’t count on it.

2.3 What to do when you get to the lab

When you get to the lab, make sure that all Chipmunks are running correctly. Reboot or logout machines where necessary. If a machine is not working correctly, report the problem to the instrument desk, send mail to the LAs, and put a sign on the Chipmunk with the problem, your name, and when the problem was reported. If a sign is up but does not have the time that the problem was reported, report it again; the sign was probably put up by a student or by a LA who didn’t have time to report it.

Make sure that the spoolers are up on all of the SRMs and police the printer area, throwing old printouts into the recycling bin.

Put an LA sign on the top of your computer so that students can see you. Add your name to the list of “LA On Duty” on the blackboard and erase any names of LAs who are not on duty. Read the “Bugs and Hints” section of the board to see if there is anything new, and erase any outdated messages. Start helping any students listed on the help queue. You can decide whether or not you want to use the help queue by marking whether the queue is “On” or “Off.”

When you are not helping a student, you can do small things Athena, like read you mail, but don’t get too involved. Students need to feel like you are there to help them. If you are no using the help queue, it is a good idea to walk around the room occasionally and see how people are doing. Some students may be reluctant to approach you for help, but they will ask you a question if you wander by.

When you are helping a student, don’t do his/her work for him/her. Ask the student to show you the different pieces of code and to try running it for you. Don’t take over at the keyboard for her/him. Although this may be frustrating when the student is slow, it is how she/he learns to do things. When a student is off on the wrong track, try to guide him/her onto the right track, but don’t tell him/her how to solve the problem. 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 her/him think about it some more. Don’t let students badger you into telling them the answers – that’s not your job. Your job is to help students, not do their work for them.

One final note of advice – helping students is not always easy and it can be frustrating. When you feel yourself getting frustrated, don’t take it out on the student, because it will only make the situation worse. Take a step back and try another approach, or if there is another LA on duty, see if she/he can help. Learning to help students effectively is a skill that takes practice to develop, so don’t get discouraged.

2.3.1 Lab Protocol

• Don’t get irritated at students; all questions are good questions.

• Never make a student feel stupid, or tell that a question is stupid.

• If you’re not helping someone, answer the lab phone.

• If the room alarm starts whining, turn it off.

• Always put a Lab Assistant sign on the top of your computer when you are on duty.

• Always remove the Lab Assistant sign from your computer when you leave.

• Always change the ”LA On Duty” section on the blackboard when you arrive and when you leave.

• Never refuse to help a student on the grounds that he is not in 6.001, particularly if no 6.001 students need help. It is okay to give 6.001 students priority.

• Never refuse to do LA work while you’re on duty.

• If no one needs help, write additions and revisions for this manual.

• Never justify ignorance because something isn’t in this manual — especially if you haven’t looked for it here!

• Don’t force off-duty LAs who happen to be in the lab to do your work for you.

• Don’t punt your hours — the lab must always be staffed.

• Don’t ignore the help queue — some students put their names on it instead of directly approaching LAs. If the queue is not in use, write a note to that effect on the board.

• If you find a commonly-encountered problem or question, put the answer on the board in the helpful hints section to reduce the load on you and the other LAs and to help students who use the lab during off-hours.

• Never make a student wait while you finish something on your computer, even for a moment. If you do, students will get the idea that you don’t want to be bothered — that shouldn’t be true. Don’t do anything on your computer which requires making a student wait for help.

2.3.2 Ethics

One difficult aspect of being a 6.001 Lab Assistant is that you have to help people who are your peers. Although this situation does not have to be a problem, it can be especially difficult when a student is a neighbor in your living group, a close friend, or a significant other. As an LA, you have a position of power and authority over the students. It is your responsibility not to abuse this power. There is a fine line between giving a friend a little extra help and doing his/her work for him/her. Don’t cross that line. It really won’t help the student in the long run.

Most LAs don’t have a problem with this issue, but occasionally a difficult situation does arise. If you have any questions about this subject or feel like you may be in a difficult position, talk to the head TA or one of the lecturers. If you talk to someone and explain the situation, any problems will most likely be resolved in your favor. However, if the head TA or one of the professors hears something through the grapevine, you will have a lot of explaining to do. The best advice is: use good judgement and you won’t have any problems.

2.3.3 The Help Queue

When you are staffing the lab, you need to decide whether or not you are going to use the help queue. Check the “On” or “Off” box on the blackboard to let students know how they should get help. If the lab is busy, you should probably use the queue because it will be less chaotic. If the lab isn’t busy, handle the queue however feels most comfortable for you.

When you are using the queue, help students in the order that they have put themselves on the queue. At the beginning of the term, students will tend to put their own name instead of their machine name on the queue. When you help these students, remind them to put their machine name on the queue. Before you help someone on the queue, erase their machine name, so that if there are any other LAs on duty, they can proceed to help the next person on the queue. If you are not using the queue, you should be aware that some students will still put their name on the board. If a student does this, help her/him and then explain that the queue is off and that she/he should find an LA and ask for help when this is the case.

2.3.4 Bug Reporting

If you find a dead Chipmunk in lab that cannot be revived by any of the methods detailed later in this manual, you should report the problem. The process of reporting hardware bugs is: notify the instrument room that the machine is dead and give them any relevant details that you can see, send mail to the rest of the LAs so that everyone knows that the problem has been reported, and put a sign on the machine saying that the problem has been reported. The sign should have the date and time of the bug report, as well as your name, on it.

If you discover what you think may be a bug in the course software or the problem set code, you should notify the head LA and the head TA immediately. The sooner that the problem is fixed, the better. If there is a way that students can fix the problem themselves, put a note on the “Bugs and Hints” section of the blackboard.

2.3.5 Problem Sets

The head LA is responsible for making sure that the current problem set code is loaded on the Chipmunks. The details on how to load problem set code are explained in a later section.

All LAs are responsible for doing every problem set. LAs are given the problem sets far enough in advance so that everyone should have done the assignment before attempting to help students with it. Although LAs are sometimes given the solutions before the problem set is due, you should not depend on getting solutions. The best way to understand the problems that students are having with the assignment is to have done the problem set and possibly had the same problems yourself. LAs get paid for two hours a week to do the problem sets, so do them! If you find any bugs in the problem set handout or code, report them to the head TA and head LA.

2.3.6 The Sign-Up Sheets

It is the responsibility of the head LA to make sure that the sign-up sheets in the lab are current. A new set of sheets should be posted on the bulletin board every few days. The procedure is documented here for completeness.

The new signup sheet stuff is on Athena. First login into Athena, then type:

   attach swmpthng
cd /mit/swmpthng/genericbin

signup -s day, month date signup -s day2, month2 day2 ⋮ on Athena. The sheets will be sent to the printer over in the 6.004 part of the lab. There are a few different options for the signup command which are explained if you type signup

-longhelp.

2.3.7 Login Message

The head LA is responsible for creating and updating the login message on the Chipmunks. The message normally contains course-related information and announcements about lab policy. Details about changing the message are explained in a later section.

2.4 The Lab

2.4.1 The Filing Cabinet

There are two upright filing cabinets near the door to the lab; 6.001 uses the top three drawers of the left one. Completed timecards are placed in a pendaflex folder in the top drawer of the filing cabinet, which also contains copies of Don’t Panic, the LA phone list and lab schedule, current problem sets (sometimes), and other documentation. LA signs, which are placed on top of on-duty LAs’ computers, are stored on top of the filing cabinet; the lost and found is also there. The filing cabinet should be kept locked when no LA is in the lab; the key can be obtained from the instrument desk on the fifth floor of Building 38 or from the head LA. Be prepared to work hard to convince the desk staff that you are actually an LA and should have a key; be persistent and you will win.

2.4.2 The Blackboard

The blackboard at the back of the 6.001 lab is the home of the help queue, the bugs and hints section, and the LA on Duty sign-in. LAs should always sign in on the board when starting a shift. Read the bugs and hints section to see if there is anything new about the current problem set and decide whether or not you want to use the help queue.

2.4.3 The Phone

The telephone by the printers is connected to the MIT phone system. The phone number is 253-7976. You can use it to make calls anywhere on campus, but nowhere off campus. If the phone rings and you are not busy, answer it. Sometimes a student will call for another student, which is fine. Don’t make a habit of helping students over the phone; they should come in to lab to get help. Feel free to use the phone when the lab isn’t busy and no one needs help, but don’t spend hours on it, especially when the lab is busy.

2.4.4 The Room Alarm

If the room door is held open for more than about ten seconds, a high-pitched alarm will whine until you reset it. To reset the alarm, wave your hands in the air in front of the alarm box by the door. Bonus points are awarded for mysterious hand-waving that convinces the students the alarm is actually magic. In reality, the alarm is actually disabled by a motion sensor which is mounted in the ceiling near the doors.

2.4.5 Off-hours access

The 6.001 lab is not open 24 hours per day; except during regularly scheduled hours the combination lock is disabled. If it is absolutely, positively necessary that you get in to the Lab during off-hours, contact the Head TA or one of the lecturers. You can also call the Campus Police. After waiting for the CPs to show up, convincing them why you need to get into the lab and verifying that you are an MIT student, they may let you in.

Hardware

3.1 Printers

Extra paper is in the printer cabinets and in boxes under the tables holding the SRMs. If there is no paper there, ask someone at the instrument desk for access to the closet where the boxes are stored, and yell at the head LA.

To load paper, first make sure the printer is off-line (the on-line button will toggle the printer on and off line). Lift the hood of the printer. At the left-hand side of the carriage you will find the paper release lever. Pull it forward, then slide the paper up through the bottom of the printer. Align the paper with the 11\frac{1}{2} mark on the top of the printer. There are a pair of buttons under the hood (next to the reset button) which can be helpful in making fine adjustments. Then press reset to reset the top-of-form to where the paper is now. Finally, push the paper release back into place, bring the printer back on line, and make sure that the spooler is up. (See below; taking the printer off line usually stops the spooler.)

If the ribbon on a printer begins to go dry, get the head LA (or the instrument desk if you’re desperate) to get a new ribbon out of the same closet the paper is in. A diagram explaining ribbon installation is printed on the ribbon box. Once the ribbon is installed, align the paper, press reset, bring the printer on line, and make sure that the spooler is up.

Once the printer is back on-line, you must explain this to the corresponding SRM by bringing the spooler up: type sp 6 up at the SRM nearest the printer. Printing should then resume at the beginning of the interrupted job. Everything that has been sent to the printer since it went down will still be in the queue, so discourage students from sending multiple copies of a file if the first one doesn’t appear. If the printer has been down for a while, you should check and, if necessary, clear the print queue before you let it start printing. This is done with the Pascal Filer’s Remove command, which is described on page 31 in Section 4.5.3.

Sometimes students will complain that the printer isn’t working. Normally this means that the printing spooler has gone down for some mysterious reason. Check to make sure that there is paper and the printer isn’t jammed. Typing sp 6 up at the SRM nearest the printer should fix the problem.

3.2 Graphics Printers

The graphics printers are attached to the two Chipmunks near the sign-up sheets, Todd and Cycle. When the current problem set requires students to print out graphics, the head LA will reserve the machines for “Graphics Printing Only.” A special program is no longer used on these machines to print out graphics. The graphics-printing functions are use instead. LAs should note that many copies of Don’t Panic incorrectly list the printing function as

print-graphics-file. The correct command is print-picture-file.

If the inkjet printer does not respond when a student tries to print a picture file, try turning the printer off and then on again. (The switch is on the back right-hand side of the printer.) You can also try pushing the blue button, labelled with “Aa”, on the printer. If one of the printer runs out of paper, go to the instrument desk and ask for more paper for the inkjet printers. The printers take a special kind of paper; they won’t print properly on the paper used by the regular printers. If the printer is printing very faintly, the ink cartridge is either empty or clogged. Remove the cartridge by lowering the black lever that holds it in place and lifting it out. See if there is ink in the cartridge. If so, shake it up, wipe off the printing surface, and replace it. If not, get a new cartridge from the top drawer of the filing cabinet or the instrument desk, and install it.

3.3 Chipmunks

Each Chipmunk is an independent microcomputer and is connected to an SRM (Shared Resource Module) so it can share files (operating system, the Scheme interpreter, login pictures, problem sets, etc.) with other Chipmunks.

Each machine has a main computer with a bus expander on top, and these two units have separate power switches. If for some reason it is necessary to power down a Chipmunk, always use the switch on the main unit (underneath the keyboard). Be sure to leave the Chipmunk powered down for about five seconds before turning the switch on again; this allows the power supply capacitors to fully discharge. Don’t use the green switch on the bus expander, as this is very likely to throw a circuit breaker. Use of the green switch causes a power surge, which may trigger the chipmunk power supply to cause an even bigger surge, which throws the circuit breaker. This will disrupt service to the other three chipmunks which share the multiplexor if the multiplexor was on a same power strip served by the blown circuit breaker. Aside from these nasty side effects, power-cycling the green bus expander switch has the same effect as using the chipmunk power: the computer is completely reset.

Each chipmunk is on a separate power strip, which is plugged into its own outlet in the ceiling, which in turn has its own circuit breaker. The outlets are labeled with a box and switch number (e.g., 1.15 means box one, switch 15). If the light on a power strip is out even though the switch is on, check the circuit breaker. (Box 1 is on our side near the signup sheets, box 2 is on our side toward the back of the room, and box 4 is on the 6.004 side opposite box 1.) A tripped circuit breaker will have its switch in the middle rather than to one side. To reset the breaker, flip the switch all the way to the off position and then back on.

There is an brightness control on the back of each machine (it’s almost hidden by the metal bars that hold it to the table).

When examining seemingly dead screens, try pressing the alpha key. Also check the display output plug at the lower left of the rear of the Chipmunk.

Chipmunks are identified by an SRM name (the top name on the label) and a machine name (on the bottom). They are connected to their SRM in groups of four via multiplexors under the table. When a chipmunk refuses to boot, the first thing to check is its connection to the multiplexor; if this connection is loose (it may not look it, so give it a good shove) the machine will not talk to its SRM.

Each multiplexor gets its power from one of the four machines to which it is connected. If this machine is powered down or its connection is loose, none of the four will be able to talk to the SRM. The way to tell which machine provides power to the multiplexor is to look at the cables connecting them. There should be three fat ones and one thin one; the thin cable is the one carrying the multiplexor power.

Be careful not to power cycle the machine powering the muliplexor when students are working on any of the other machines to which it is connected, because they will all lose their ability to talk to the SRM. If you power cycle the Chipmunk powering the muliplexor, you must reboot the other three Chipmunks to which it is connected.

To reboot a chipmunk, type reset ( shift – pause ); this will clear the screen and leave a little arrow prompt. At this point hitting continue will make the Chipmunk continue running as if you hadn’t pressed reset . Typing sb (using the shift key to get lower case) and either enter or execute will reboot the machine.

Booting one chipmunk takes about six minutes. Unfortunately, the SRMs are very slow at communicating with several Chipmunks simultaneously, so booting two Chipmunks at once takes longer than booting them each one at a time (especially if they are on the same multiplexor). The more machines you boot at once, the worse things get — four at once on the same multiplexor will take about an hour. Booting them all at once, while it takes a long long time, does work. If you can, boot Chipmunks one a time.

If you discover a bug you can’t fix, send mail to 6.001-la (so the other LAs know that the problem was reported), report the problem to the instrument desk, and hang a sign on the machine whose problem was reported.

If you suspect a Chipmunk disk drive is broken, test it by trying a different disk in it; 6.001 disks seem to go bad at a much higher rate than ordinary disks. Formatting a blank disk is a good check of a Chipmunk disk drive; if the drive is broken, there will probably be an error. If the problem turns out to be the disk itself, the files which are on it may be able to be retrieved by using the Edwin dired feature: instead of using Find File with the filename, do dired on the disk, move the cursor over the desired file, and press F to load the file. It may also be possible to repair the disk (or at least work around the damage) by using the Pascal Filer Bad Blocks feature.

3.4 SRMs

SRM stands for Shared Resource Module. SRMs look exactly like Chipmunks without Expander Boxes on top. Students should never touch the SRMs. The SRM holds all the code for booting chipmunks and logging in and out, problem set code, archives, and other randomness. It is also the only route to the printer. If an SRM goes down, its twelve Chipmunks will be unable to load problem sets, boot, send jobs to the printer, or even log out! This is obviously something to be avoided. Unfortunately, it is very easy for a random person to discover that typing system down will do exactly that. Just typing system up won’t fix it — once the system is brought down and up, all twelve machines must be rebooted before things will work normally. If the an SRM goes down, it must be brought up and then each machine it serves must be rebooted. This takes a good long time — so don’t bring the system down and don’t let anyone else do it either!

In addition to system down and sp 6 up (see Section 3.1, page 18), there are various other not-too-useful commands the SRMs understand. You can use the ? command to look at them (units and users are mildly interesting), but don’t do anything other than informational commands without checking with someone who knows first.

On very rare occasions, the SRM itself will crash. Symptoms of this situation include complaints by booting machines that the SRM doesn’t exist and repeated communications error messages on the SRM display. Check with someone who knows (the head LA or a Scheme team person) before rebooting the SRM. If you must reboot an SRM, find a disk labeled “SRM.” Such a disk lives in the right-hand drive of at least two of the SRMs, and usually all four. Power down the SRM, insert the disk in the right-hand drive, power it up again, and answer questions about the date and time. If the disk fails to spin up the first time (the SRM will print a big warning message if this is the case), type system up. If this fails to bring the SRM up, there is a real problem — notify the Head TA immediately! Once the SRM has recovered, all twelve of its Chipmunks must be rebooted as with system down. This takes about an hour and a half if you do them all at once.

Software

4.1 General Software Setup

The chipmunk system is built in several levels of interpretation. At the bottom level is an assembly-level debugger (also known as the monitor) written in the machine code of whatever chip runs these things. (This debugger, which is not very useful, should not be confused with the Scheme debugger.) On top of this is a Pascal system, which seems to be complete and working and actually useful, even if you don’t know Pascal. The Pascal system is an operating system shell for manipulation of files and execution of programs. Scheme runs in this system.

Edwin (and much of scheme itself) is written in Scheme and runs in the global environment. The student environment, where you’ll spend most of your time, is a child of the global environment into which much (but not all; see section 4.2 on page 24) of the global environment is copied. If you poke around Edwin or Scheme (with (debug) or (where) or whatever), you will discover that most of it is written in Scheme. Exceptions are primitive procedures and graphics routines, which are written in Pascal and exist as compiled code; additionally, as much of Scheme (and Edwin) as possible has been compiled to enhance performance.

Some of these various stacked systems are useful and some aren’t. We will discuss the things you should know about them all, starting from the top:

4.2 Scheme

This section deals chiefly with the student version of Scheme. For information on the Scheme in which Edwin and other parts of the system are written, see section 4.4, page 28.

All LAs should know how to use the Scheme debugger! As a LA you will spend the majority of your time finding bugs in other people’s code, so experiment with the Scheme debugger — use ? to list its commands and try them all. Strongly encourage students to learn its use early in the term — it will make life survivable when they get to the later problem sets.

For some inexplicable reason, the Chipmunks seem to crash more often when a student uses the debugger. When you are going to help someone using the debugger, encourage her/him to save any work before entering the debugger. Although the Chipmunk may not crash, if it does the student will be grateful that no work was lost.

The Scheme debugger started up by the (debug)^{1} command in Scheme is an older debugger with basically the same functionality but a different (mostly poorer) user interface. One difference is that in the older one, break works, and there is also a proceed option.

The stepper is currently in limbo but may be restored at a future date.

The trace procedure, a Scheme primitive, is almost as useful. Also look up and experiment with where, the environment inspector.

If you ever have questions about the debugging tools, please ask an experienced LA. The quicker you can locate and understand bugs, the more effective (and less frustrated) you will be as a LA. Experienced LAs will be more than happy to help you.

Every now and then, Scheme will crash. When this happens the computer will say “Scheme Microcode 5.12 / Band to Load:” and sit there quietly waiting for the magic word. The magic word is #5:/SCHEME/BANDS/STUDENT; the new system, however, knows which band should be loaded, so you need only press the enter key.

1To invoke the new debugger, use the Browse Continuation command from Edwin. Another method of invoking it is to evaluate the form ((access start-debugger debugger-package edwin-package)), which explicitly calls the start-debugger function, which isn’t visible from the student envrionment but must be accessed from the debugger environment, which is itself in the edwin envrionment. A package is a private envrionment whose symbols may or may not be exported (bound) outside the package.

That band is the student band, a file which contains the standard student version of Scheme. A band contains all the Scheme code for a particular Scheme environment, but not the machine code for primitives.

Once the band is finished loading, a login picture (see page 33 in Section 4.7.1) will appear on the screen. The student’s work will be lost and the machine will be in a fresh state.

If you need to straighten out a balking machine or clean up the Scheme environment when things get confused, you can force the student band to be reloaded. At a Scheme prompt, do

(enable-language-features) enter , then (disk-restore "#5:/scheme/bands/student").

Reload the student band if Scheme has become confused but the operating system is fine, a complete reboot is not necessary in thais case. For instance, if someone reset car to cdar in the global environment^{2} (not the student environment — changes to that are undone by executing the Logout command from Edwin), this would be appropriate.

   The function enable-language-features and its foil, disable-language-features,

take an optional argument, a string which will be used as the prompt while in that mode. If someone decides to change the prompt on their machine to something like 6001sucks>, you should probably change it back. Basically, these functions erect and dismantle a block between the student environment and the global environment; when language features are enabled, functions in the global environment that are normally not available to students can be called directly.

When language features are enabled, the Chipmunks run a version of Scheme compatible with the R^{3} Report. Among other features, in the R^{3} mode the Chipmunks recognize the backquote, comma, and atsign characters. The call-with-current-continuation function is enabled as well. The file #5:/scheme/scm/studen.scm contains a list of the functions in the student environment: first those whose names are different from the corresponding function in the global environment, then those with the same name in both environments. Some functions have syntax differences in the two environments as well. There is no explicit list of the functions in the global environment which are not accessible in the student environment. The student environment, which is a limited copy of the global environment, is recreated each time someone logs in (to prevent any student’s modifications, which will almost always be confined to the student environment, from affecting the next student).

2One way of doing this would be to execute the form (set! (access car '()) cdar); in an access form, '() represents the global environment

This works well unless the global environment is somehow changed, in which case the band must be reloaded to completely reconstruct the global environment.

The Scheme read function does not work properly in the student version of scheme which is run under Edwin because the underlying (‘bare’) scheme captures the read request, returning control to Edwin after the user has entered an expression. Since bare scheme’s idea of the current cursor position is different from Edwin’s idea of the current point, the evaluating a (read) construct can cause the cursor to jump to another location on the screen to read the input, causing confusion to the user and perhaps a loss of displayed information. Since the input was read by bare scheme, Edwin does not know that its control of the screen was interrupted, and so it does not refresh the screen. Of course, no internal data is lost, but the effect is disturbing. The solution is to use the function read-from-keyboard, which takes care to remain in Edwin and read from the current point. There is a subtlety here: the user may type anything he likes, and in fact edit buffers normally, but as soon as the execute key is pressed, the preceeding form is evaluated and used as the value of the (read-from-keyboard) form. The result may thus come from a different buffer than the one in which the read was executed. If a student forgets that a read is in progress and attempts to evaluate a form by pressing the execute key after it, the result may be different than expected because the form has been sent to the function which called read-from-keyboard. Neither abort nor ctrl – g will abort this type of read. Cancel read-from-keyboard by typing a b o r t execute ; Edwin will return to its top-level loop above the calling read-from-keyboard, and the call to read-from-keyboard will never return.

4.3 Edwin

Edwin is a version of Emacs and almost all Emacs commands work in Edwin. Most LAs find it easier not to use the function keys at the top of the keyboard, but this may confuse students. (Note, however, that now both the function key and the equivalent ctrl or meta keystrokes are included in the student manual.) Many students don’t realize that Edwin is a version of Emacs; more sophisticated students can use this information to their advantage. As an example, there are four ways to invoke Save File: by pressing the meta prefix (the run key) and X and then typing Save File, by pressing extend (which is equivalent to typing meta – X ) and then typing Save File, by pressing k_{0} , or by typing ctrl – x ctrl – s .

As with Scheme, there are things in Edwin that it would be helpful to know that you might not have picked up as a student in 6.001. One such thing is the use of the kill ring. Observe how the delete and recall commands work; this is probably the easiest way to move code within a buffer or back and forth between buffers. You should also teach students how to use the Select Buffer and Browse Buffer commands; the earlier they learn this, the easier the term will be for them and for you.

There are four “hidden” characters on the keyboard; these are ‘, |, \, and ~. They can be obtained by pressing the shift key simultaneously with, respectively, the E , ( , ) , and ^keys; these four keys are found at the top of the chipmunk numeric keypad.

‘Named’ Edwin commands (those which are specified in this manual with a preceeding run x ), are invoked by pressing the meta key (labeled run ), then x , then typing the command name. There are several other ways to invoke them as well, particularly when the command is also bound to a key. For instance, Indent Region can be invoked by using the extend or meta – x prefix keys and typing Indent Region, or by ctrl – z \. Typing ctrl – z simply sets the meta and ctrl prefixes for the next character typed (that is, ctrl – z n is equivalent to meta – ctrl – n ), so run ctrl –\ would also work.

Useful commands include ctrl – l , which refreshes the screen and repositions the text so that the line with the cursor is at a specific point on the terminal screen. ctrl – x p (print buffer) sends the current buffer directly to the printer. ctrl – x v invokes the reverse video command.

The indentation characters are very useful for debugging code. Tab causes the line containing the cursor to be correctly indented with respect to the previous line. meta – ctrl – q runs Lisp-Indent-Sexpr: it indents each line of the following form (s-expression) and is extremely useful. This command can be used in place of Indent Region, which is missing from Edwin. With some practice, you will be able to tell whether parentheses are properly matched just by looking at the indentation; in fact, this is by far the fastest way to debug a student’s code.

The region is the area between the cursor and the mark; ctrl – x ctrl – x , the exchange point (point is where the cursor is) and mark command, will show you where the mark is, and ctrl – space will set it.

Edwin has lots and lots of on-line documentation; you are encouraged to use it. If you spend some time with Edwin using the ctrl – h commands (for instance, Apropos is ctrl – h a ), you will doubtless discover many useful commands and learn the control keys that correspond to all those ugly function keys across the top. (The run key corresponds to the esc key on an “ordinary” keyboard – this is the meta prefix key. Better keyboards have meta keys that act like ctrl or shift keys and are pressed in conjunction with one or more other keys.) Also try ctrl – { and ctrl – } , the esc (not to be confused with the run key, which is a meta prefix key) and lisp prefix characters.

Info is also installed on the SRMs. Use ctrl – h i or M-X Info to invoke it. Be careful when loading it, as its files are large. If you have too little heap (for example, because you have too many large buffers), you may get into an infinite garbage collection when you load an Info file. This problem may be fixed in the future, but just be careful for now.

You can recall the previously-evaluated s-expression by doing ctrl – c ctrl – y ; this is very useful in interaction mode, and students often try to simply use ctrl – y (or the recall key, k_{something} ) to perform this function. ctrl – c ctrl – r goes backward (the other direction) in the s-expression ring.

If you can’t find an Edwin command you think does exist, try looking for it with a name beginning with “ˆ R ”, like “ˆ R Indent Region”. This is a carry-over from early versions of Emacs, where commands which were usually bound to keys were given names with that prefix so that, when you did completion on the name of an Emacs command, those functions wouldn’t show up (since you probably weren’t looking for them, since they’re available directly from keys).

run (the meta prefix character) behaves as it does in Emacs. Do ctrl – h m in Scheme mode to see some commands which use the Scheme prefix.

Enable Dangerous Keys also lets you use meta – , to run the terminal program (if it is loaded already, which it isn’t on the machines in the 6.001 lab, to save memory) and meta – + runs an inferior filer process (which also isn’t loaded, to save memory). These can also be invoked from the Pascal Command Line, which is explained in the section on the Pascal System.

Around problem set two or three, you will be swamped with questions from students who have loaded a problem set file from the SRM (these files are identified by the #5: directory name), modified it and then used Save File to try to save their work. The problem is that Save File tries to update the same file that was loaded in in the first place, but the students obviously can’t update the copy that’s on the SRM; instead they need to use Write File to save the file to their own disk.

The big problem with all this is that the Chipmunk is not very smart about this sort of thing. It opens a channel to the SRM to make the update, discovers it can’t, and doesn’t bother to close the channel. If there are too many channels left open to the SRM, nothing will work and the system has to be brought down. So strongly discourage students from making this mistake, and don’t make it yourself either! The number of open channels is displayed in the upper right corner of the SRM’s screen.

The maximum number of open channels on an SRM is 250. If the number of open channels is close to that number, do the following to lower the number (so as to avoid nasty problems): Go to an SRM and type in users. This gives a list of the unit and node numbers of each machine. Find a machine that is not being used by anyone, and remove it from the system by typing remove <unit> <node> at the appropriate SRM. The number of open files should go down. There is no way to tell (as far as I know) how many files a Chipmunk actually has open (the number displayed by users is NOT accurate). Please note that the node number shown by users refers to the unit number on the actual machine.

The open channel problem which resulted in too many open files (this was the problem with printing which was caused by the nonexistence of a necessary file) on the SRMs was supposedly fixed in November 1988.

4.4 Bare Scheme

Edwin is itself written in scheme, except for some Edwin-specific primitives which are written in assembly; scheme itself is written in the same style. To get to the scheme in which Edwin runs, do M-X Enable Dangerous Keys, then press ctrl – x ctrl – z . Bare scheme is itself a 6.001 scheme, so all scheme features should work in it. It has a debugger without the full-screen user-interface, and in this debugger breakpoints do work. However, there is no editor interface for bare scheme. This version of scheme is so much less convenient that you probably will never want to work in it. To return to Edwin from bare scheme, press the edit key in the upper right corner of the keyboard. The prompt displayed by bare scheme is

Bare-Scheme:press-the-EDIT-key-to-return-to-Edwin==>

4.5 The Pascal System

The Pascal System, which runs everything discussed so far, is eminently useful. It ordinarily does not make itself known to students; occasionally, however, you may get a Pascal error:

[Pascal trap in Scheme; . . . ]
Should a scheme abort be attempted?  (Y or N, default Y)

If this happens, press Y. The question is not whether the scheme program (run by the Pascal system) should be aborted; rather, this message indicates a serious problem and is asking whether control should be passed back to a potentially trashed scheme system in the form of a scheme error. This is precisely what you want. Get out of the scheme debugger, save work where appropriate, and then reboot the machine: it is in an unstable state and is very likely to crash again. A second Pascal trap is even less likely to be recoverable than the first.

4.5.1 How To Get There

There are several ways to get to the Pascal system; if you discover others, please document them here.

1. In Edwin, do M-X Enable Dangerous Keys, followed by ctrl – x ctrl – z , which is the Edwin exit-to-superior command. This will give you the Command line of the Pascal system. You can get to the filer by typing F (Filer); in the filer typing Q (Quit) will take you back to the command line. (If typing F doesn’t get you the filer, but instead gets you a message like SYSTEM93:FILER: file not found, the machine probably needs rebooting.) To get back to Edwin from the command line (students will occasionally find themselves stuck here somehow), type X (eXecute), then when it asks you what file to execute, just type scheme and then enter . The chipmunk should pop back into Edwin faster than you can blink. If it doesn’t, but instead says something disagreeable, like SCHEME.CODE: file not found, then rebooting is necessary. If scheme.code isn’t found, you can, instead of rebooting, try #5:/scheme/bands/student. This is pretty futile, however, since the student’s work is lost and doing this seems to give you a brain-damaged version of the system.

2. Also from Edwin, do M-X Enable Dangerous Keys, then ctrl – x ctrl – c to exit Edwin and get directly to the command line.

3. From the monitor (assembly-level debugger), which is described below, use the stop key, more easily located as shift – clr-i/o — the clear-i/o key is a function key at the very top right of the keyboard, above the numeric keypad. This will leave you at the command line. Doing X SCHEME (see preceding paragraph) will put you back into a hopefully thriving Edwin. If you have used this method to wake up a stuck machine, have the student immediately save his files and move to another machine, because you can be fairly certain that next time you try to leave Edwin, the machine will go away and not come back. Now, this method is anything but foolproof, and it may turn out that this whole section is a lie as I haven’t been able to get this trick to work recently.

4.5.2 The Command Line

The main point of going to the command line is to get back to Edwin via X SCHEME. Unless you are into Pascal, most of the rest of the commands are not much help. Nevertheless, feel free to try them out. If you get to a prompt and you don’t know what to say, entering a blank line will take you out of it.

4.5.3 The Pascal Filer

M-X Pascal Filer doesn’t work because the inferior filer process isn’t loaded, to save memory. Instead, get to the filer by pressing F at the Pascal Command Line

The filer is by far the most useful part of the Pascal system. You should sit down and experiment with its commands yourself (they are listed across the top of the screen; hit ? to see more of them and enter a blank line to get out of any prompt you don’t like); the most important ones are listed here.

L is for List directory. In addition to listing the files in whatever directory you specify, it tells you lots of other good things like how big they are, when they were put there, and how much space is left on the disk. Edwin’s Dired doesn’t give you this sort of info – the Pascal Filer is the only way to find out for sure if a disk is full.

B does a Bad sector check on a disk. This takes a long time but is worthwhile if you suspect a disk is bad. A bad sector check is also a good way to test a chipmunk’s disk drives (if you know that your disk is good). [If you discover a way to abort this command let me know — there probably is a way but I’ve forgotten.]

V tells you the names of all the Volumes (directories) on line, including the SRM and both floppies. The SRM is usually referred to as #5: rather than by name.

K stands for Krunch, which is very important. Sometimes a disk will have plenty of space but won’t have enough of it in one place to write a file. Sometimes the disk will only THINK it doesn’t have enough space in one place to write a file. Either way, Edwin will say that it is “Unable to write file”. When this happens, the disk needs to be crunched. When it asks you for the name of a directory, be sure to put the colon on the end of the disk name.

The R command, for Remove, is what’s used to clear the queue on the printer when it is backed up. The printer queue can be seen by doing List-directory #5:/LPT. If the person using, shall we say, the machine named Maid has sent eight copies of his file to the printer, you can remove them all by asking it to remove the file #5:/LPT/MAID-=. If the printer has been down for a long time, so that many of the printouts are outdated or there are too many of them, just remove the file #5:/LPT/=. As you may have guessed, = is a wildcard for this filer.

Whatever you do, don’t, don’t, don’t accidentally remove #5:/LPT rather than #5:/LPT/=. This will remove the directory itself, rather than all the files in it, and if #5:/LPT is removed, nothing can print through that SRM. Unfortunately, while that particular directory can be removed by anyone, it can only be put back by the head LA or a Scheme wizard. If you do make this mistake, call one of the above.

4.5.4 Kermit

Kermit, when invoked on the specially-equipped LA machine Zebulon, allows for the transfer of files between the Chipmunk and a computer network, like Athena. The connection from the Chipmunk to the network is via MITEE-Mouse, a terminal concentrator which, if working properly, will allow logins almost anywhere on campus.

From the Pascal System, do X #5:/KERMIT to execute the Kermit program. When it is ready it will clear the screen. Press Kermit’s interrupt character, ctrl – execute , to get to the Kermit-9000s200> prompt. Type SET BAUD 4800 to set up Kermit (you must do this every time you restart Kermit from the Pascal Emulator, even if you already have an open connection). To connect to MITEE-Mouse, type CON. The screen will clear once again. Type enter to get MITEE-Mouse’s attention and you will get a prompt. Type connect machine-name to connect to a remote machine. To get back to Edwin, type ctrl – execute to get to Kermit, enter Q to get back to the Pascal System, and execute scheme (that is, press X, then type SCHEME; you shouldn’t need to specify a volume name before the program name). Alternately, you can use the stop key (which is also the shift – clr-i/o key), to get to the Pascal System from Kermit.

To use Kermit to transfer files, start Kermit on the Chipmunk, use MITEE-Mouse to connect to a remote machine, and execute the Kermit program on the remote machine. You should execute Kermit from the directory where you want to transfer files. This Kermit is a separate program which runs entirely on the remote host. Type server in response to the C-Kermit> prompt. Go back to the Chipmunk Kermit prompt (using ctrl – execute and use send or get to transfer files. Both commands take two file names as arguments: the first file name is the name of the file on the remote machine and the second is the name of the file on the Chipmunk. When you are finished, type FINISH or BYE from the Chipmunk Kermit to exit the server and then reconnect to the remote machine by typing CON. You can then exit Kermit on the remote host and continue working on the remote machine or logout and return to the Chipmunk.

4.6 The Monitor or Assembly-Level Debugger

To get to this debugger, press shift – pause , otherwise known as reset .

The continue key will put you right back where you came from. Another way to exit is to hit shift – clr-i/o , as described above; this takes you to the Pascal command line. And, there’s soft rebooting (type sb, using shift to get lower-case letters).

Another monitor command that sometimes unwedges the Chipmunks is EC 0. I think EC stands for Escape Code. This seems to work in some instances when the machine is hung and all that can be done is to enter the assembly-level debugger; EC 0 is less destructive than soft-booting and may put you back in a working version of Edwin. Be warned, however, that like some other fixes, this is not guaranteed to work, and even if it does, the Chipmunk is likely to fail again. It is a good idea to use EC 0 to save one’s work, then reboot the chipmunk.

The main use of this debugger derives from the fact that the reset key overrides everything else. Even if the rest of the keyboard is completely frozen and the machine is hung up in the middle of Scheme never-never land and ctrl – g gives you nothing but a picture of a bell at the bottom, reset may still get you a response. Then you can go to the Pascal command line, and from there to Edwin, and the files should be saved. However, you won’t get away with this twice; have the student save his/her work and move to another machine.

If per chance hitting reset doesn’t get you a response, then everything is hopeless and the machine must be powered down (use the lower switch, not the upper one!) and back up. Always wait five to ten seconds between powering down and back up (to let capacitors completely discharge, etc.). This should take five to ten minutes. If this doesn’t work, report the problem to 6001-la and the instrument desk and put a sign on the machine. Be sure to warn students not to try this themselves: they may not allow enough time between powerdown and powerup, they may press the wrong switch, and they also don’t know enough about the system to save themselves in a less extreme manner. See section 3.3, page 19 for a description of what may happen if the green swictch on the bus expander is used. (In short, don’t.)

4.7 Graphics

A special program is no longer used on the graphics terminals to print out graphics. The graphics-printing functions are used instead. The graphics commands are load-picture,

store-picture, and print-picture-file. Note that print-picture-file is what prints

the specified graphics file on the inkjet printer, not print-graphics-file. The print graphics key has been disabled to prevent students from wedging the system by trying it on machines without ink jet printers.

4.7.1 Login Screen Pictures and Message

The login screen pictures are in #5:/scheme/logscr. Don’t put non-picture files in that directory, as the login procedure assumes that any file there is a picture file. I don’t know their format, but they are generated with the procedure store-picture, which writes the current graphics screen to the file given as argument.

The head LA is responsible for setting up the message that is printed on login. It is located in the file #5:/scheme/greeting and ususally contains course-related information. In order to change the file, it is necessary to delete the old file and replace it with a new file. Although the login message is a good place to put announcements, students seldom read it.

4.8 Problem Set Code

The files loaded for each problem set are specified by the file #5:/scheme/probsets.scm, which defines the scheme variable problem-sets. The format of problem-sets is (default-ps-name ps-specs), where each ps-spec is of the form (ps-name mode-lists) and each mode-list is of the form (mode filenames). Each file specified is used according to the related mode. The valid modes are:

load The file is loaded into scheme. This mode can be used with binary files.

reference The file is placed in an Edwin buffer.

load&reference The file is loaded into scheme and placed in an Edwin buffer.

copy The file is to be copied onto the student’s disk. This mode is usually used either for answer files or in conjunction with the load mode. The file is also placed in an editor buffer.

select A single buffer name follows this keyword; that buffer is the one selected when the problem set is done loading. The default is "*scheme*".

The modes may appear in any order. Problem set names may be any symbol or number. A partial example follows:

(define problem-sets
  '(10a
     (1  (copy "ps1-debug.scm") (load&reference "ps1-debug.scm"))
     (picture (load "picture.bin"))
     (2  (copy "ps2-2.scm") (load "ps2-2.scm" "ps2-1.scm"))
...

The problem set files themselves are in #5:/psets (not #5:/scheme/psets).

The head LA is responsible for loading new problem sets onto the Chipmunks throughout the term. To add a new problem set, simply add the problem set code files to #5:/psets and modify #5:/scheme/probsets.scm to include the new files. To change the file, you have to delete the old version and replace it with a new one. Note that the files are loaded in right-to-left order. The code must be loaded onto each of the four SRMs.

4.9 Software Changes

This section is for the use of LAs who may recall the days when the system was different (and LAs were called Lab TAs).

The Edwin prompt is now ==>.

Load Problem Set loads into the correct environment. This should eliminate some of the variable-shadowing problems students had with the last problem set.

enter is now bound to newline-and-indent, execute to evaluate-previous-sexp. This brings usage in Edwin’s scheme and interaction modes into line.

graphics and alpha work the old way. The screen are three modes: graphics, graphics/alpha, and alpha. Pressing graphics moves the screen mode toward the graphics end of the spectrum and pressing alpha does the reverse. Thus, pressing alpha twice is certain to put the screen in text-only mode. The advantage of this (over the use of the keys as toggles) is that the screen cannot be in the (useless) non-alpha non-graphics mode.

The cursor positioning wheel is no longer enabled; Edwin can’t keep up with the characters it sends, so it is less than useless. Students should be encouraged to use the editing commands which permit movement by a word, s-expression, or line at a time.

Auto-repeat is disabled for all practical purposes, for the same reason. There is a quartersecond wait before first repeat, quarter-second wait between repeats.

backup-floppy is now implemented (see manual).

Both the Emacs (e.g., ctrl – f ) and Edwin (e.g., right-arrow key) [replace this with the graphic] commands are now included in the 6.001 student manual.

ctrl – ? no longer works; instead, use ctrl – h for Edwin help.

4.10 Updating the SRMs

This section is primarily for the head LA, who is the one that does these kinds of things.

4.10.1 Syntaxing Scheme source files

Make sure there is an up to date EDWIN band #5:/SCHEME/BANDS/EDWIN. If there isn’t, follow the instructions for generating an EDWIN band in 4.10.2.

Load the EDWIN band, since there isn’t enough room for the syntaxer when the STU-DENT band is loaded:

      (disk-restore "#5:/SCHEME/BANDS/EDWIN")

Load the syntaxer:

      (load "bin:beta")

Syntax the file. If it’s in the #5:/SCHEME/SCM directory, do:

      (sf "#5:/SCHEME/SCM/filename" "#5:/SCHEME/BIN<password>/")

If the file is in the #5:/EDWIN/SCM directory, do:

      (sf "#5:/EDWIN/SCM/filename" "#5:/EDWIN/BIN<password>/")

4.10.2 Generating a new 6.001 band

Keep a copy of the old STUDENT band:

Get to the Pascal ”Command:” prompt.

      F
       C #5:/SCHEME/BANDS<password>/STUDENT, OLDSTUDENT
       X SCHEME

Do DIRED on #5:/SCHEME/BANDS. Look for three bands in particular:

BARE, the bare Scheme band without Edwin or the 6.001 stuff EDWIN, BARE with Edwin STUDENT, EDWIN with 6.001 stuff

If EDWIN exists and has the same date as STUDENT, assume it is up to date:

    (disk-restore "#5:/SCHEME/BANDS/EDWIN")

Skip to step STUDENT.

If EDWIN doesn’t exist or has a different date than STUDENT, assume that it is not up to date and must be regenerated.

If BARE exists and has the same date as STUDENT, assume it is up to date:

    (disk-restore "#5:/SCHEME/BANDS/BARE")

Skip to step EDWIN.

If BARE doesn’t exist or has a different date than STUDENT, assume that it is not up to date and must be regenerated.

Change the current directory to #5:/SCHEME/BIN as follows:

Get to the Pascal ”Command:” prompt.

   W D #5:/SCHEME/BIN<password> ; May require closing ”/”

If BARE band exists, delete it:

   F
    R #5:/SCHEME/BANDS<password>/BARE
    Q

Start Scheme from scratch:

   X *MARK
    P *MARK
    P #5:/SCHEME/CODE/SCHEME
    X SCHEME

COLDMD.BIN ; to the ”Band to load?” prompt

   ((access finish-load runtime-system))

Save new BARE band:

   (disk-save "#5:/SCHEME/BANDS/BARE")

EDWIN: Start here if BARE band was up to date but EDWIN band wasn’t. If EDWIN band exists, delete it:

   (delete-file "#5:/SCHEME/BANDS<password>/EDWIN")

Load Edwin:

   (load "#5:/EDWIN/SCM/EDWIN")

Save new EDWIN band:

   (disk-save "#5:/SCHEME/BANDS/EDWIN")

STUDENT: Start here if EDWIN band was up to date. Delete existing STUDENT band:

   (delete-file "#5:/SCHEME/BANDS<password>/STUDENT")

Load pathname translation software (only if creating band for SRM, not 7945):

   (load "#5:/SCHEME/SCM/PATHTRANS" '())

Load 6.001 stuff:

   (load "#5:/SCHEME/SCM/SBUILD")

Save new STUDENT band:

   ((access student-band 6001-package edwin-package))

Now, reboot the machine and test the band before distributing the new system to the other SRMs. Remember, if anything goes wrong, you can always fall back on the OLDSTU-DENT band you saved above.

4.10.3 Copying SRMs

It is best to do the copying of SRMs when there are no students in the 6.001 lab, as you have to bring down two SRMs (source and destination) for each copy.

Find the COPIER: disk in the filing cabinet (there should be two copies). Choose an SRM to do the copying. It is easiest to use the SRM which is connected to

the source disk, because you’ll have to move one less cable.

Disconnect the printer from the SRM; it’s attached at the bottom center of the back of the SRM display/keyboard unit. Connect the destination SRM disk where the printer cable was before.

If the source disk is not already connected to the SRM, remove the SRM disk cable from the top right of the back of the SRM display/keyboard unit and replace it with the cable to the source SRM disk.

Power on the SRM with the COPIER: disk in the right drive and wait for the copier software to boot.

At the prompt, check the cables once again before pressing a key to start the copy. Unfortunately, the copier program doesn’t give any error messages, so the only way to tell if a copy is successful is to check the contents of the destination disk.

Once the copier program announces that it is finished, replace the cables on both SRMs and boot them from their SRM disks. If there is no SRM boot disk in one SRM, you can use the disk from another SRM; they are interchangeable.

Once the destination SRM boots (and you’ve given it the date and time, if it asks for it), you must change the name of its disk back to its original name, because it now has the same name as the source disk:

      SYSTEM DOWN
       RENAME "source-srm<srm-password>" "destination-srm<srm-password>"
       SYSTEM UP

4.10.4 Copying SRM Boot Disks

To copy the SRM boot disk (the floppy that must be in the right drive of an SRM to boot it), login as “guest” (no password) to a 6.004 machine. Write-protect an existing SRM boot disk an place it in the left disk drive of the 6.004 machine. Place a blank disk in the right drive. Type:

         dd if=/dev/fd.1 of=/dev/fd.0 bs=256 return

Once the copying is finished, the right drive contains the new SRM boot disk. Make sure that you remove both disks and that you log out from the 6.004 machine (by typing bye return ).

Keep only one SRM boot disk out (in one of th SRM’s right drives) at a time; keep the rest of the SRM boot disks locked in the filing cabinet for safekeeping. Label the disks! Always make sure there are four disks available.

Index

access, 23–24

adding index entries, 5 alarm, 16 aligning paper, 17 alpha key, 35 Apropos, 26 assembly-level debugger, 32 Athena, 6 auto-repeat, 35 backquote reader macro, 24

backup-floppy, 35

bad disk drives, 20 bad disks, 20 band

new, 36 reloading, 24

bare scheme, 25, 28 bibtex, 5 blackboard, 10, 12–13, 15 booting

chipmunk, 19–20, 20 SRM, 21

break, 23

brightness, 19 Browse Continuation, 23 bug logging, 13, 20 bus expander, 19 channel, open, see open channel circuit breakers, 19 Course VI administrative office, 8 cursor positioning wheel, 35 dangerous keys, see Enable Dangerous Keys dead screen, 19 debugger

no full-screen interface, 28 scheme, 23

dired, 20

                                        disable-language-features, 24

disk drives bad, 20

disks

bad, 20 display output plug, 19 Don’t Panic, 3 e-mail, 6–7

                                        EC 0, 32

edit key, 28 EDWIN band, 36 Enable Dangerous Keys, 27–28

                                        enable-language-features, 24

environment inspector, 23

error file not found, 29 Pascal trap in Scheme, 29 Unable to write file, 31

ethics, 12 extra hours, 8 file cabinet, 10 file transfer, 32 filer, see Pascal Filer filing cabinet, 15, 18 formatting, see text formatting function keys, 25, 27 global environment, 24 graphics key, 35 graphics printers, 18, 33 graphics terminals, 33 green switch, 19 handouts, 9 help queue, 10, 12 helping students, 10 hidden characters, 26 hours, 8 indentation, 26 index, 4 index entries, 5 info, 27 ink jet printer, 33 instrument desk, 10, 15, 17–18, 20, 33 keyboard, 26 Krunch, 31 LA meetings, 9 LA sign, 6, 10

storage, 15 LaTEX, 3 loading paper, 17 login file, 14, 33 login message, 14, 33 login screen, 33 Logout, 24 lost and found, 15 mailing lists, 6–7 meetings, 9 meta prefix key, 25 missing a shift, 8 missing hours, 9 multiplexor, 19 multiplexor power, 20 new index entries, 5 numeric keypad, 26 off-hours access to the lab, 16 open channel, 28 package, 23 paper, 17 Pascal Filer, 30–31 Pascal System, 29–31 pay, 8 phone, 15 phone numbers, 7 powering down chipmunks, 19, 33 previous s-expression, 27 print buffer, 26 print graphics key, 33 printer queue, 31 printer

ink jet, 33 printers, 18 problem logging, 20 problem set, 34 problem sets, 9, 13 prompt

                                           ==>, 35

arrow, 20

bare-scheme, 28 Edwin, 35 scheme, 24

queue

printer, 31 R^{3} Report, 24

                                        read, 25
                                        read-from-keyboard, 25

recall key, 27 remove command, 28 reset , 32 reset button, 17 reverse video, 26 Rivest, Ronald, 4 running LaTEX, 5 schedule, 7 schedule conflict, 8 scheme abort, 29 Scheme debugger, 23 Scheme prefix, 27 scheme prompt, 24 scheme

bare, see bare scheme Shared Resource Module, see SRM sign-up sheets, 14 single-stepper, 23 SRM, 21–21

Copying, 38

Copying Boot Disks, 39

start-debugger, 23

stepper, 23 STUDENT band, 36 student environment, 24 style of this manual, 3 tab, 26 telephone, 15 text formatting, 3 timecards, 8, 15 top-of-form, 17

trace, 23

users command, 28 wheel

cursor positioning, 35

where, 23

windex program, 4 working extra hours, 8 alpha, 19