Computing scenarios

I am writing this as if you are using C or C++. If you are using another programming language, then of course the necessary changes would be made to your procedures. I am not giving every detail. (In some cases, such as Borland, I really don't know every detail.)

Each project in the class has two essential phases, and a third phase that is not essential, but very useful.

1. The first essential thing is a C-program (or possibly a suite of C-programs). This program may occasionally read input (such as a database of star coordinates), usually not. It will always write output, in the form of a device-independent file, as described on pages 89 and 107. This program is the heart of the project. It is where the real work occurs. A prototype program for a small problem is described on pages 83-88 (see curve.c in prototypes). The exact nature of the program will of course depend on the problem being solved.
2. The .di file must be converted to a picture. In most cases, you will turn in printed graphics work. (One or more pictures.)
3. Almost everyone will want to be able to preview pictures. Although things usually seem straightforward when you're done, many false steps are possible, and a preview saves wasting time and paper on printing a useless picture.

All work done at home.

At one end of the spectrum, one would do everything at home. (Of course, this requires the right equipment.)

1. You can use, e.g., Borland C++ as your compiler.
2,3. For printing and viewing, there are two possibilities:
- You can download a postscript viewer, called ghostscript, free from Ghostscript home page). Then you use the file to_ps.c that I have developed (see code samples) to build a filter that translates .di to .ps in the manner of Section 2.3. (You will need to compile this once; you can use the same executable over and over.) The resulting .ps pictures can be viewed and printed using ghostscript. You are on your way.
- You can also use the Acrobat PDF reader that is most likely built into your computer (if relatively new). For that you need to instead use to_pdf.c from code samples. From the Acrobat reader you can both view and print.

Even in your own home, you need to be attentive to backing up your files!

All work done in simlab.

The other end of the spectrum is to do everything in Simlab (see computing facilities).

0. After logging on to a client, you may have no X-window in which to type. Luckily, there is a solution: you click the icon that looks like a computer with a big X on its screen.
1. Here you would use vi or emacs to edit your programs, and cc or c++ to compile your programs.
2. To print, you would simply run the .di file through to_ps.c (which needs - once only - to be compiled), and then run the .ps output through lpr. I specifically mean these two commands (with qsllj being the printer name in simlab):
```
		to_ps < yourfile.di > yourfile.ps
		lpr -P qsllj yourfile.ps
```
3. For previewing you would use ghostscript (known to unix as gs).
By the way, you can't (and don't need to) use PDF on simlab and its clients. It isn't available. Also, the unix command ps2psf isn't available on simlab.

By the way, here is a file of (somewhat randomly chosen) unix commands), which you might find useful.

Whenever working in unix, make sure that the noclobber variable is set, and make sure that "mv" and "cp" are aliased to "mv -i" and "cp -i." (There is a way to ask for these in your .cshrc file.) Believe me, there have been tragic moments when a student clobbered a week's work.

On a networked unix system, your work is automatically saved to the shared disk when you exit from vi or another editor (unless you ask to exit without saving). It is saved in such a way that no one else can erase or alter it (without your password). However, it is urgently recommended that you frequently make backup copies of your important work. Backups can be made on a disk (using telnet from a PC), rcp'ed or ftp'ed to another unix machine, mailed to yourself at your mailhome, or simply copied into another directory (less recommended). Accidents do happen, both systems-induced (rare) and user-induced (more frequent). I cannot give any credit for work that has disappeared.

The third step here (viewing with gs) is something that one can do only when logged on to console, or onto one of simlab's clients. (This means one must log in directly, not remotely, to one of the twenty machines in Simlab.) The reason is that one is using the X-windows system, which can only address a screen that is running X. (If you happen to have access to some machine on campus that is networked and running X, then of course you can make a remote login and use gs. The only such machines generally available to students are those in simlab.) My one experience in simlab was that the X-tools functioned automatically, with no intervention required from myself. Be aware, however, that occasionally one has to set the environment variable called DISPLAY. (More on this if it turns out to be needed.)

However, you do not by any means have to use the X-windows system, even if you prefer unix. Keep reading

The PC-lab Math 217 (alone, or combined with a home setup).

Now there are a number of variations and even some hybrid approaches. To begin with, you could use Math 217 (see computing facilities) just as the home-computer was described above. Two differences:

You must save to diskette every time. It may be a good idea even to work from diskette.
We now (11/4) have GhostScript and GhostView available on the machines in Math 217. (Until you get to the raytrace project, you won't need them, because PDF will work fine.) See a detailed description on this page.

Obviously you can combine the home approach with Math 217 (or other sites on campus) if you carry diskettes with you. This approach might be particularly useful if you have a computer at home, but no printer (or if your printer is broken).

Warning. Although people have indeed done it successfully, it is a little isolating to confine your work to a home system, especially if that system has different compilers and so on from those available on campus. The most serious problem with this is that I cannot help you as well as I might. If it's Borland or Unix, I can say, "let's go look at it in the lab." If it is another compiler, then all i can say is, "go home, try the following fix, and let me know if it worked." Therefore -- if you do work at home -- you will be better off with a home setup that will interface also with the system in e.g. Math 217.

Math 217 as a Unix Lab!

Here is a variation on the pure simlab approach. You can use simlab as your main computer, using it in two ways: both on-site, as described above, and also via remote login. You can log in remotely from any spot with telnet. This includes Math 217 and just about any PC-lab on campus. When logged in remotely, you will be able to do all the compiling and generally look over your work. It will not, however, be an X-windows connection, so you will not have immediate use of ghostscript. (However, all is not lost: see "Unix previewing" below.) Moreover if you are remotely logged into simlab from Math 217, you can access the printer in that room by using this unix command:

		lpr -P mathps yourfile.ps

(The other PC-labs have printers with other names. Inquire locally.)

Your home as a Unix Lab!

A remote login to simlab (or any university unix machine) is possible from your home if you have a PC or Mac with a modem. You will able to do everything mentioned above for Math 217, with the exception of network printing. (I doubt if your home has a networked printer.)

Unix previewing on a (networked) PC

Here is a hybrid approach for previewing while you are remotely logged in to simlab (or rtt, or any unix machine), either from your home (via ppp) or from Math 217 (or another PC-lab):

Do your main work on simlab, obtaining as usual a .di file.
On simlab, use your (or my) compiled version of to_pdf to translate your .di file to .pdf.
Use ftp (or ws_ftp) to bring the .pdf file to the PC where you are working. (Start ftp from a DOS window on your PC, by simply typing e.g. "ftp simlab." On the university's PS, you can find WS_ftp on the program menu. It is self-prompting and easy to use.)
Use your PC's Acrobat Reader to view the file as a picture.

Once you get set up, this works pretty well. Usually you can leave Acrobat and ftp running, as you make a series of pictures to view while fine-tuning your work. If you like this approach, you might never go to the actual simlab. (If you choose this path, you could use rintintin as well as simlab.)

Linux

You might possibly have a PC running Linux (a version of unix). (I just got a linux machine in my office -- will be learning it as the semester progresses.) Your linux probably has cc and c++, and it may also have ghostscript and Acrobat. (Or you can get ghostscript and acrobat for linux from the URLs mentioned above. I think Linux refers to the Acrobat Reader as acroread.) Then things should be easy for you. It is much like the unix-lab situation described above, although there will be possibly some local differences.

Macs

I haven't mentioned the Mac, simply because none of CU's publicly available Macs has any compiler. (This appears to be a long-term policy.) Thus it has not been practical for me to recommend their use for this course.

Nevertheless, everything said above concerning home-use of PC's is also valid for the Mac, if you have the right setup. (Some care may be required in bringing Mac files to the PC and back. Nevertheless all our files are ASCII, so this problem should be surmountable.)

I don't have much experience with programming on Macs.