Kevin Roberts - COSI Final Report Fall 2004


My work this semester falls into two main categories.

Z/VM Graphical User Interface
This project started out slow this semester, as we were waiting for code to be released from IBM so that we could work on it and expand on it. It then slowed to all but a full halt as most of our team was working on the Gentoo Linux Updater GUI (see below). Before it slowed to a complete halt, I fixed outstanding bugs and completed my CMS User Monitor. Most notably I made it so that if the user monitoring got kicked off, a dialog pops up and asks if you want to be reconnected and continue monitoring or just exit the program. I also cleaned up the code a little bit, it could be cleaner, but it should be more legible than before.
We also made some progress on another proof of concept program, the DASD Format/Copy queue. we did a bunch of research to see what commands we needed to execute in order to accomplish the tasks. Specifically I researched the copying part of the project, how to use DDR to copy the contents of one DASD to another. The results of this research can be found here
I will also be submitting this project as a Linux Challenge Entry. The Final Draft can be found here

Gentoo Linux Updater GUI
This was a joint project with some of the time being spent for CS450 and other time being spent for COSI. The final report for the CS450 class can be found here
My Personal Project Plan can be found here
This project was quite a learning experience, before beginning this project I had never worked with GTK, my C experience was rather limited, mostly working in C++ before. Knowing I was going to be working with GTK, I went through the GTK tutorial which made it seem very much like Java which I had worked with previously with the Z/VM GUI and otherwise. I couldn't have been further from being wrong. Pointers can be a pain, especially when it's been awhile since you really had to deal with them. Half of the bugs that I had to trace down came back to a pointer not being initialized properly. The documentation made it seem rather easy to do things, but that's because the documentation on GTK was incomplete. Rant mostly done, here are some of the main things I did:
Worked with forking/threading interfaces for the Graphical part. At first, I used forks, which I had examples from the backend to work with, but everywhere I looked seemed to indicate that forks should be used to then exec a command, which I wasn't doing, and even though everything worked just fine doing things this way and somehow it just seemed wrong, trying to make it modular so that it would be easier for the other people working on the project to be able to fork things off without having to copy over too much code proved to be rather difficult and what I ended up with I questioned as to if it helped or actually ended up being a hindrance. So, I looked at threading. Found two different methods, one was found in the GTK FAQ (nowhere in the tutorial, and as for the documentation, not very likely it was there), this one was not really recommended and was said to cause a lot of asynchronous problems, I thought it best to avoid this, I wanted the least hassle possible with things that would be very hard to track down. Another threading method I found had all of the GUI stuff executing in the main thread and all of the interaction with the backend which might take any great deal of time being done in the new threads. This seemed a lot simpler, and if we were going to get any errors it would be because of us not doing things right, not because of GTK, even though the code would be a lot cleaner with the first of the threading options, this one still allowed for it to be fairly modular once I made a function to handle the creating of a thread. My teammates still didn't entirely understand it, so I had to go back later and extensively comment everything I did, but I think that was good for me as well, I don't normally comment that much, if at all. Bad habit I know. But after that they mostly understood it, and I had to only remind them a few times to put all of the GUI calls into the idle callbacks run in the main thread. Before they did that it caused some weird errors on some machines while the error didn't occur on others, some kind of weird flushing GTK was doing I think. I wonder if the other method would've been any better, probably not.
Wrote package_tree() function which initially went through the directory structure of /usr/portage and returned a listing of all the packages. This ran in about 1 second. I rewrote it a bit later when I realized that esearch could return a listing of all of the packages along with their descriptions, their masked status, etc. which simply reading from the directory structure didn't give. This returned a lot more information, but ran in a little bit over 2 seconds. I chalked the increase in time up to gathering more information, but further analysis would be interesting since esearch first gathered information, then printed it out, I gathered that, if I were to do what esearch does, remove that layer, I may just be able to shave some of that time off.
That was the meat of my contribution, I also did the backend emerge pretend world function, grabbing the package names and versions from the output of emerge world. Other than that it was mostly finding bugs that other people were having trouble finding (multiple times :-P), updating documentation (too much), commenting code (again too much), etc.
Overall, a very successful project, and we're making it a sourceforge project and I, and I believe at least one other member, will continue to work on it next semester.