Project 4 -- Inter-Process Communication (IPC)

NOTE: This assignment, like the other projects in this class, is due at a particular time, listed above. This means that if you are even a minute late, you lose 20%. If you are worried about potentially being late, turn in your project ahead of time. Do this by submitting it electronically before it is due and giving the hard copy to me during office hours or by sliding it under my office door before it is due. Do not send assignments to my personal email address. Do not leave hard copies in my departmental mail box or attempt to give them to departmental staff (who cannot and will not accept them).

In Projects 2 and 3, you took the first two steps toward the development of an IDE by making use of existing editors, compilers, and debuggers as components of MyDE and by adding in basic mechanisms for dealing with files, directories, and permissions to make MyDE2.

However, while MyDE and MyDE2 were first steps toward an IDE, neither of them was very integrated (which is, after all, what the 'I' in IDE stands for). This is because while MyDE and MyDE2 made use of other programs to do some of the work, their communications with those programs was quite limited. The only communication came through parameters passed to those programs when they were called and the SIGCHLD signals and exit status codes generated by those programs when they exited. This meant there was no communication between these helper programs and MyDE or MyDE2 while they were actually running.

In this assignment, you will take the third step toward the development of an IDE that you could use for projects written in C or C++ by adding some integration through inter-process communication (IPC). To keep the assignment simple, you will only add a tiny bit of IPC, and therefore a tiny bit of integration. This is only the third step, since we would need a lot more work on integration to make such an IDE truly useful and you are not assigned the job of creating a nice GUI front end for your IDE. Still, it will let you gain experience with the basic mechanisms for dealing with inter-process communication.

You are to create a program called MyDE3. When run, MyDE3 will present the user with a simple main menu of options:

00. Quit.

01. Enter name of source file.

02. Edit source file.

03. Enter name of executable file.

04. Compile.

05. Enter debug options.

06. Debug.

07. Configure MyDE.

08. Change directory.

09. Set permission modes.

10. Modify access control lists.

11. Review compilation errors and warnings.

For main menu options 00 through 10, MyDE3 will behave according to the specifications of MyDE2 in your previous project, except that the configuration submenu will have one additional option. That option will be which pager to use when the user chooses main menu option 11 -- the configuration submenu should be changed appropriately to add this option as option 4 of the configuration submenu.

If the user chooses main menu option 11, MyDE3 will display to the user, one page at a time, the previous output of the compiler from the last time option 04 was chosen. This means, of course, that MyDE3 will need to read in and retain the output of the compiler each time option 04 is chosen. Naturally, you will do this using a pipe. (Note that, in addition to reading in the compiler messages, MyDE3 should still allow the messages to be viewed at compilation time by the user, as well as having them reviewable when main menu option 11 is chosen.)

Displaying the compiler messages one page at a time also means that you will need some way to display information one page at a time. Naturally, you will use an existing pager on the system and feed the information to it through a pipe. To determine which pager to use, MyDE3 will use the value entered by the user in the configuration submenu. If the user has not set a value for the pager using the configuration submenu, MyDE3 will examine the environment variable PAGER and use the value found there. If the environment variable PAGER is not set or is set to no value, MyDE3 will default to using less as the pager.

For both reading in the messages from the compiler and sending them out again to the pager, you will need to directly use appropriate POSIX systems calls such as pipe(), fork(), exec(), wait(), and/or waitpid() (not ANSI C functions like popen()).

Since it would be nice for the user to be able to see the compiler messages in a separate window, you may choose to have MyDE3 implement option 11 by creating a new terminal window and running the pager in that window. If you chose this option, you will receive up to 25 bonus points on this assignment. (The assignment itself is worth 100 points.)

Again, note that for both reading in the messages from the compiler and sending them out again to the pager, you will need to directly use appropriate POSIX systems calls such as pipe(), fork(), exec(), wait(), and/or waitpid() (not ANSI C functions like popen()).

Should you choose to do the bonus implementation, you may wish to consider something along the lines of using xterm with the -e option.

You will turn in both a hard copy and an electronic copy of your assignment. Please follow the instructions on how to send electronic copies. Do not send them to my email address.

Both the hard copy and the electronic copy will contain a write-up plus the source code for MyDE3. The electronic copy will also contain the executable of MyDE3. The electronic copy of your write-up should not be in a proprietary format (such as MS Word); it should be either in plain ASCII text or in a portable format (such as Postscript or PDF). Your source code for each MyDE3 should be in a single file called MyDE3.c (for C code) or MyDE3.cxx (for C++ code) and your executable code should be called MyDE3.

Your source code should be well structured and well commented. It should conform to good coding standards (e.g., no memory leaks, extraneous variables, type mismatches, or unused code).

Your write-up will include 1/2 to 1 page (roughly 80 characters per line, 50 lines per page) explaining the data structures and algorithms used in your code. This page limitation does not include figures used in your explanations, which are encouraged and may take up any amount of space. (The explanations do not remove the requirement that your code be well commented.)

You may write your program from scratch or may start from programs for which the source code is freely available on the web or through other sources (such as friends or student organizations). If you do not start from scratch, you must give a complete and accurate accounting of where all of your code came from and indicate which parts are original or changed, and which you got from which other source. Failure to give credit where credit is due is academic fraud and will be dealt with accordingly.

As noted in the syllabus, you are required to work on this programming assignment in a group of at least two people. It is your responsibility to find other group members and work with them. The group should turn in only one (1) hard copy and one (1) electronic copy of the assignment. Both the electronic and hard copies should contain the names and student ID numbers of all group members. If your group composition changes during the course of working on this assignment (for example, a group of five splits into a group of two and a separate group of three), this must be clearly indicated in your write-up, including the names and student ID numbers of everyone involved and details of when the change occurred and who accomplished what before and after the change.

Each group member is required to contribute equally to each project, as far as is possible. You must thoroughly document which group members were involved in each part of the project. For example, if you have three functions in your program and one function was written by group member one, the second was written by group member two, and the third was written jointly and equally by group members three and four, both your write-up and the comments in your code must clearly indicate this division of labor.