I'm basically over that cold I had. I spent almost all of
today studying for tomorrow's exam---I will be at school
from 8:30AM - 7PM!! For those last 2 hours I will be
tutoring Computability Theory students, but besides that and
the robotics meeting I must complete that Java assignment
and also my Visual Design project for this week :-(. Gonna
be a big crunch, probably worse than today. I'm planning to
write the program at school, type it in at home and debug. I
don't know what I'm going to do about the art assignment---I
may have to leave it for the nighttime and stay up late.

Better remind myself to pick up some 3M Spray adhesive
and my Rx in the evening.

Ari and I watched Silence of the Lambs last night.
It's our favorite movie, and we wanted to get up to speed in
preparation for the release of the sequel next week. Pretty
exciting!

I don't know what it is about printing out code to reread
it and make notes with a pencil. I find it clears my head,
lets me see the code in a new light. Lots of fun. I also
printed out Owen Taylor's GTK drawing tutorial, as it shows
how to do backing stores to prevent flicker. I'll probably
take these pages all to bed tonight to read.

I've been using Nautilus for about 2 days now. Pretty
schweet. This app has a lot of potential. Now that I have
kernel 2.4 running, my IDE chipset can run in the much
faster DMA mode. My machine is noticeably a bit more peppy.

I rearranged the control_box API. The previous setup was
causing impossible-to-find bugs... the storage was managed
by engine_view, and there are just too many combinations of
machine deletion / machine creation / slot reuse, too many
events to get the engine viewer to deal with it correctly
itself.

My solution was to make the control box totally manage
its own storage, to the point where, when deleted, it nulls
out the pointer that points to that storage. In addition,
cb_create does nothing in the event that you try to create
two control boxes for the same machine. When the control_box
is either closed or when its machine is deleted, the GTK
resources and memory are freed and the pointer is zeroed
out. So there is never a dangling pointer around,
despite the different kinds of events that can cause a box
to get destroyed.

I guess the idea is that control_box really
knows best when it should be destroyed, so why make another
object understand it?

Octal 0.8b release thoughts

I have a few more changes to make to OCTAL's API before
releasing it. They are all small, and if I can get the docs
done I will release them on Sunday (tomorrow.) I'm thinking
of revamping the use of "machine::state", and making it more
like GTK+'s use of "user data". I'd rather just pass it as
the last parameter to all the instance functions, and have
them do a quickie cast like my_struct *s = user_data;.

Here is my master list of things coming in 0.8b:

Adopt the GTK-style naming convention for all the
enumeration constants.

Hopefully some preview code for multiple widget control
types in control_box. I would like to have at least
trigger buttons work before releasing. I will try to get
some consistent handling of creating different widget types,
perhaps with a function accepting the OxWidget number and
returning a gtk_widget* with its signals and data
already connected. Perhaps the names for this data could
always be the same, and a single callback can handle all
widget types (much like the current one retrieves some data
items from the widget's adjustment, widgets without
adjustments could benefit from the same thing.)

I fixed the bug (for now) that was causing incorrect text
rendering in engine_view.c. Not setting the GC clip
rectangle makes it go away. I wonder why... aren't I
supposed to do this?

I made sure the GUI blocks until it recieves a ready
message from the core.

I added some ideas to mvcpac.txt. I now have in
mind a simple mechanism for propagating core events to
multiple viewers, and it will be very simple to replace the
working-prototype forwarding mechanism with this one.

Now that I think of it, the bandwidth problem is solved.
As long as we keep track of which machines are being
observed, we can have the core send param updates thru the
pipes only so often. Perhaps on a rotating basis. It's only
being done to give an idea of what is going on inside the
core thread, it's not supposed to have perfect accuracy.

As for play-position... I may be able to just use a
global variable and lock it with a mutex. Or if the user
thread never actually updates this integer, I may be able to
skip the locking.

I gave the Octal
project page at GNU a little bit of a makeover and added
a new link or two.

Have no idea what I'm doing about the show coming up... I
presume I will be ready in time. :-) I have several weeks,
so I am not that stressed. There is some kind of web-ad at
c-fom's page. Nice,
top billing :-) even if it is alphabetical...

We had our first meeting about the Mobile Robotics
senior independent study. Went very well, I'm even
considering writing a kind of flow-network editor for doing
subsumption architectures on the handyboard. The UI
certainly wouldn't be very hard--I just did something MORE
complex and it was not difficult. The only tricky part
would be converting the flow networks into inputs for some
kind of C code. I think this would be hard, because by
default this thing runs a weird dialect of C where pointers
and arrays aren't interchangeable and I don't think it even
has function pointers. In other words, it is basically
Pascal77. Sucks.

There is a GCC port to the Motorola 6811 and people do
compiled programs for it, so perhaps I will check this out.

I'm listening to an excerpt
from the live show in NYC jan 2000. Wow... has it really
been a year since then? :-)

School's going well so far. Earlier today I worked on
Octal's pattern system, doing a partial rewrite of
pattern.c. Now it has the ability to add mixing
tracks to the machines. I am only weeks away from a
beta test.

In other news, I heard that the source code to Buzz
and
Buzz2 were lost sometime last year. No backups??? A similar
blunder destroyed the code to Ultima VII.

Lots of good stuff working. The Engine View, in
which you can create, delete, connect, rename, and destroy
machines, is nearly complete. Going along with it are
multitrack-capable Control Boxes. You can pop one
open for each machine, and interactively move the sliders.
(Eventually there will be more widget types, including a 2-d
one I'm planning.) These work with OX_API, and communicate
with machine libraries to create the right display and give
feedback as the slider is manipulated.

So far several of the operations are working in the
engine_viewer. Perhaps I can get it finished for this
weekend. I can tell that now that I've finished the IPC
framework, everything else is just going to fall into place.

First day back at school today--just one class, with Aparna.
It's a Java/OOP/OOD class. Not really looking forward to
Java given what I read about it, but...

Got lots more work on Octal done last night, part of the
PAC bit is now working. Working on simplifying some bits. I
hope to have more working tonight, as soon as I figure out
some more GTK+ stuff. The old engine_viewer code is being
adapted as its own little object.... all I need is to be
able to somehow get the instance pointer from the gtkwidget
parameter that's in the parameter list of gtk callbacks.