Kevin SS WeeklyJournal2005
Kevin's Weekly Journals for Senior Seminar 2005
31 Aug - 07 Sep
07 Sep - 14 Sep
My main work this week has been cognition. I'm jealous of some of my peers who have ideas already. I'm completely at a loss. I know that if I ask Charlie, his canned response will be "Well, what's your itch?" I've got nails, but nothing to itch, that's the problem. I've come up with a project that I think would be entirely cool, but I'm not sure how to create it. It's The Teaching Language. Unfortunately, I'm not exactly sure how to implement it. I've never written a langauge before. I'm kind of thinking of something similar to HTML and CSS, but in the context of objects as opposed to text. I'm not initially sure how to go about this. The language creation will probably come second as I'm going to have to research how to describe these objects in my own mind first. I really want them to be manipulatable, so the complexity is ginormous. If I can get past that the first hurdle ... man! I'm so psyched.
14 Sep - 21 Sep
Even as I was writing The Teaching Language abstract last week, I knew that I didn't (don't) have the background to complete such a project in one semester. However, the ideas are there: I just need to focus them. I think I've decided on the direction that has already proven to have some merit: CSLets. I mentioned them in the context of not knowing exactly where I wanted to go, but I think that they might prove the best direction. I'm currently cogitating about ideas for CSLets.
21 Sep - 28 Sep
I spent the majority of this week brainstorming about tools that I would like to create. I seem to be having delusions of grandeur though, because a lot of the CSlets that I might want to create are probably just a bit beyond my current capabilities (or at least time scope). One CSlet that is worming its way through my mind is the C-string Let that I mentioned last week. I started trying to write it, but I found, in the midst of working on a consistent interface for the user, that I have more of a desire for a visual memory manager. I'm not entirely sure of the structure, but this has implications of extensability, much more so than the C-string Let idea. For one thing, if I do it right, the C-string Let could sit on top of this. Thinking continues ...
28 Sep - 05 Oct
A teacher once told me that the best way to tackle problems is to draw a picture. True to form, I have drawn a picture
of my initial ideas regarding a memory manager. What I'm thinking is that users can click on the buttons in the lower left hand part of the screen to create and access variables. The contents would be displayed in the gray bar on the bottom, as well as the location "physically" identified by the purple circle. The idea of this program is to represent the memory in a visual manner that is accessible to new students. Ideally this would be something with which students could at first rotely interact, but then also find other uses for it such helping to visualize problems they will encounter as they continue in CS. Thought it is still not complete, -- I haven't thought entirely through how I'm going to deal with some of the details of implementation -- I'm kind of excited.
05 Oct - 12 Oct
In the meeting last week, it became apparent that Tom and I are working on projects of an extremely similar nature. It was clear that we should work together, especially as we both have hopes that our code gets used and is extensible. Charlie pointed out that the easiest way to make something extensible is to write it to conform with two different ideas (in so many words ...).
To this end, I started to write the implentation behind my Visual Memory Manager Let. I got lost in some of the implementation details, however. Tom and I found some time to talk about how we might make some headway. We came up with some great ideas.
For extensability, we are still thinking in terms of modules and packages, but our scope suddenly has some wider prospects. Currently, it looks like we're going to make a Memory Manager and then make modules that lie on top of that. One of Tom's project ideas is to teach data structures in a visual manner. One of my project ideas is to (partially) demystify the workings of the memory. My current drive is to create a memory system that can be interfaced via an API. Then Tom can write his program to conform to the API: at the same time his module is demonstrating a data stucture concept, my program can show exactly what is happening behind the scenes.
12 Oct - 19 Oct
This past week was hampered by Fall Break, but I did manage to change the code that I had written to begin to conform to what Tom and I talked about in our meeting last week. A personal failing that I'm having is an inability to step back from the code. I'm still having some problems with the implementation, and I think it's because I haven't completely thought out the structure to which I want to conform. But, as the old adage goes, "Time stops for no man;" so I'd better hurry up and get my head in gear.
In other news, I have read some of the website provided by Alex (Thank you!). Mark Guzdial has done some interesting work, but it is not quite the same avenue that Tom and I are wishing to explore. Guzdial's work is centered around bringing out the things that can be done with a computer and making it accessible. The main thrust of what I read is about using computers to play with different multimedia (pictures, movies). A couple of examples include his explainations of how to manipulate images with some python programs, and how Disney did/does some of its digital animation. A fun read, with some real output potential for people who don't want to be deeply involved in CS. However, not for Tom or myself.
19 Oct - 21 Oct
SUCCESS!!! I completed the underlying MemoryManager class code! Gotta say that at this point, it looks like I was doing just fine in my struggles last week. The inability to step back from the code proved a good thing as I was much more facile with what I had created. I've written the basic MemoryManager class, as well as
Variable class that inherits from it. On top of that
Variable class I've written a two extensions:
VariableChar. Since I'm taking somewhat of a C approach to the process, I felt it also necessary to write a
VariablePointer classs. This class has shown me some errors in logic in my other two classes, and some functions that I needed to write in my base classes. In other words, I'm still working on the
21 Oct - 28 Oct
VariablePointer finally fell into place last night. The key was that I realized that having pointers is an integral decision to a "language" – meaning that every class that is written must have support for pointers. I had to add a couple of functions into each of the other
Variable extension classes, but so far, things are looking great. I'm to a point now where I'm think I'm ready to start working on a GUI to look at the memory in a visual manner. So far it's all been in my head. (What a mind job!)
28 Oct - 02 Nov
Tom and I are struggling with how to combine our projects. Neither has quite the experience in Java to immediately know how they are going to mesh. We have an inkling of inheritance, but we haven't actually gotten it to work yet. Tom is still fervently working on the GUI side of his project, and hasn't had much time to work developing an ADT. Since he has been working with a stack as his test case, I decided to go ahead and implement a stack.
This has proven harder than I was expecting because I had forgotten about all of the niceties given to one by the language in which they're working. More importantly however, we had a part of our paper due today. I had to turn my attention to solidifying what I'd been reading. This was especially hard and time consuming because I haven't been doing the best at keeping track of what I've been reading where. (A little bit lack of focus early on in the semester coupled with a sense of complacency because nothing was immediately due. Whoops!) Luckily I had some browser history that I could peruse to find what I had missed.
02 Nov - 09 Nov
I completed the Stack class on Friday. The trick was to decide how to implement it. I haven't implemented array functionality yet, so I thought that I would create a pointer based stack. This led way to extending the VariablePointerClass. Once I did this, some things fell into place, but not everything. The gist of what I was missing was that, again, I was thinking that things would just "take care of themselves." Not so. Since I'm writing this memory, if I haven't told it do something, it isn't going to do it. Basically, I'm getting a new found respect for the memory issues with which the old timers had to deal.
At some point while I was working on the
VariablePointerClass code, I realized that I should probably start storing class Variables in the memory as well. However, at this early developmental stage I'm not going to worry about it. The storage and access functionality will be the same, so it should be a minor change later. For now, I'm more worried about making sure that what I've got going on is correct. I want to get something working and on screen first. However, before that can get started, I need to make sure that Tom's project can actually use mine. I started looking at that on Sunday morning.
Looking for how to do it brought me to the notion of libraries, or, in Java-speak, packages. They aren't difficult in concept, but it took me 3 hours to nail down just how to do it. The gist is this:
If you want to make a class (file) part of a package, you must put
at the head of your file. That was easy. The difficult part came in getting the compiler to compile the different parts of my program as part of the package. The problem was the directory structure and place of invocation of the compiler. How the Java compiler interprets the
package statement is as a directory structure. The above would mean that from where the compiler is invoked, there should be a subdirectory named "packageName" that contains all the files. So, if I had my java files A.java, B.java, and C.java, and I wanted to put them in the edu.earlham.cs.Graphics package I would add this to the very beginning of each file (excluding comments, it must be the first line):
Then, you would need to create a directory structure that matched that package line. (The '.' character delineates a subdirectory.) I would need to find somewhere to create the structure and copy the files into it. On Windows and *nix:
C:\Documents and Settings\Kevin\My Documents\Classes\SeniorSem\7dGraphics\>md edu\earlham\cs\7dGraphics
C:\Documents and Settings\Kevin\My Documents\Classes\SeniorSem\7dGraphics\>copy *.java edu\earlham\cs\7dGraphics
C:\Documents and Settings\Kevin\My Documents\Classes\SeniorSem\7dGraphics\>
$: mkdir edu/earlham/cs/7dGraphics
$: cp *.java edu/earlham/cs/7dGraphics
The trick is to compile from here, not in the subdirectory like you might think:
$: javac edu/earlham/cs/7dGraphics/Visualizer.java
09 Nov - 16 Nov
This week has been stale as nothing new has surfaced. There was some good success with Tom on the 10th (Thursday) as I rewrote/reorganized a major portion of his and my code to finally make the two projects work together. Since that's done, I'm letting myself think more about the visual aspect of my project. I spent the major portion of this past week working on my code and am thinking about how to organize the visual layout of the Memory Viewer. (Actually, I've named it MemoryWatcher, but I'm not fully settled on that name. Inconsequential, I know.) I'm mostly struggling now with Java and the visual components, trying to give myself places on which to draw. (It's frustrating to receive a NullPointerException when Java supposedly has no pointers. It's not true of course, Java just tries to hide them, but it's still funny.) And finally, the presentation has been looming. I'm still working on it as I write this log entry. We'll see how it goes tomorrow.