Our project consists of two distinct pieces of software: LibGist, a
library to be linked against a parallel program on a limited set
of platforms; and JavaGist, a portable Java application which
reads and displays information from log files written by
We have finished the design decisions (at least, the first iteration
thereof) on which both software components depend. Accordingly, we
have divided the group into two subgroups, one for each component. We
expect the LibGist portion to take less time, so we have allocated two
group memebers (culver, xiao) to this part, and three members
(mccauley, gao, guan) to JavaGist. We hope that the LibGist
component will be operative relatively early, so that then the entire
group can work on the more demanding JavaGist.
Progress this week has focused on completing the user manual for both
components, and the GUI prototype for JavaGist.
User manual. As a group, we decided it's appropriate to have
two main sections to the user manual: Chapter 1, JavaGist. Chapter
2, LibGist. Each of these two chapters will have sections on
installation, getting started, and so forth. We decided this is
better than having a single installation section and a single
getting started section for several reasons. The table of
contents was recorded in HTML (drafted by gao; updated by culver).
There is also currently a Chapter 0, General Introduction, and a
Chapter 3, Glossary. The Glossary is underway as of this week
- The client has said that he plans to run the two components on
different machines---e.g., LibGist on the Reality Monster
"evans", and JavaGist on the Macintosh in his office. So even
if installation is in one chapter, it will still be in two
distinct stages for the client.
- A user may prefer to experiment with JavaGist first, before going
to the trouble of instrumenting his own program. He may not
want to know anything about instrumentation until he knows
what the capabilities of the browser are. Alternately, he may
want to start with instrumenting. Thus, we should make it as
easy as possible to learn the two components in either order.
JavaGist. The GUI prototype continues toward completion with
the following new features added:
- The event window now supports rescaling the range. Modified
the GistRule and EventSequencePanel classes to support this.
Event sequence panels now paint events. States will be in by
tonight. A simple parser has been implimented to permit
reading event files. (mccauley)
- Working on interface design and implementation, combining the
codes from Rob and me together, added in some new classes, such as
profile panel, rule for diagram window, etc., put on numbers on each
event sequence panel, and other small operations to beautify the
interface and the codes as well. (guan)
- These improvements by the time the boss reads this document:
- Add a basic profile graph (probably a static image).
- Complete the scalability functionality.
- Implement the events/states switch to control the drawing method for
- Implement a legend (again, probably static).
- Write a getting started section for the manual, and a Using Online
Setbacks. We have had some problems with CVS. It is an
unforgiving piece of software. We have in fact ended up
discarding some code changes and starting over, wasting
valuable time. In an attempt to encourage
all members of the team to continually contribute to the
web pages, I (culver) have put all of our html files under
CVS. I fear it has had the opposite effect.
Nevertheless, I feel it will become a very helpful tool
once the setup is stable and all of us are comfortable
- Finished defining the API for LibGist. (xiao, culver)
- Updated the section of the User's manual documenting this
API. This is currently section 2.3 of the manual. (xiao)
- Wrote the platform-independent part of the LibGist Getting Started
guide. This is currently section 2.2 of the
We also have not yet found a way to make our web pages attractive and
visually consistent. The obvious solution is to appoint a webmaster.
However, this project will produce so much documentation that
webmastery might use up all of that one team member's time, while
adding a 24-48 hour delay on the posting of anything on our web page
that was not written by the webmaster. For now, we will have
unattractive and inconsistent web pages.