10/23

Figured out why my OMSMIDIPacket's were getting scrambled: OMS doesn't play well with MacsBug (presumably because it turns off interrupts, when OMS needs serial interrupts enabled...)

Am getting that annoying "illegal use of precompiled header" error again! Can't remember how I fixed it last time. (That's why I'm now keeping notes!)

10/24

Fixed the "illegal use of precompiled header" error: just commented out every #include <MacHeaders.h> line anywhere in my code.

***********************

11/15

Took a long break from this project, while I was working on the web site and other projects. Now that I'm back, have some TO DO's:

Realized I've been sloppy and let some circular dependencies creep into my code (especially around the debugging and exception-handling modules. Need to figure out a non-cyclic dependency graph:

g_interrupt_depth
(okay, this is only a single global variable, but *every* function that might get called at interrupt time needs to use it, so we need to make sure that it gets defined in a header file that doesn't depend on anything else...)
debug
since every bit of code that might need to get debugged (which is every bit of code in the project) depends on this module, this module needs to be completely self-contained. No more using T_Scheduler to do interrupt stuff: debug needs to implement its own interrupt-safety mechanisms.
Also, need to add thorough input-checking: since debug is going to be called mostly when things are going *wrong*, it really cannot make any assumptions about how it's going to be called.
T_Exception / T_Scheduler
These are the tricky ones: they both seem to require the other. T_Scheduler needs T_Exception to be able to throw exceptions, but T_Exception needs T_Scheduler in order to offer interrupt-safe exceptions.

11/20

Taking another break to work on some Perl/HTML stuff.

11/24

So, I've come to a decision: there's no point in struggling with Apple's crackheaded "Classic" API (even Apple admits that it sucks) for implementing the UI. At first, I thought it would be useful to learn the Carbon APIs at least, but even those are fairly whack. By the time I get around to writing another MacOS application, it will be for OS X, and I'll be using Cocoa. For this project, I'm going to write all the UI code in Java, and reserve the C++ code for the engine (which is basically done now anyway...)

12/01

Misc. design decisions:

I'm using AWT rather than Swing, because Swing doesn't produce the MacOS "native look-and-feel" -- at least not in OS 8.
I'm using JDirect to call the C++ code from the Java UI. (Don't forget to extern "C" all the C++ interface routines!)

12/05

A few coding conventions from <http://java.sun.com/docs/codeconv/> that seem worth adopting:

10.5.4 Special Comments
Use XXX in a comment to flag something that is bogus but works. Use FIXME to flag something that is bogus and broken.
-

12/06

More design decisions:

Handles/Pointers passed to/from native code with JDirect
Any heap memory that gets passed to/from Java code is assumed to be "owned" by a Java object. The native code will NEVER dispose of any heap structures once JDirect has "seen" it. (Since the JVM has garbage collection, we might as well use it.) It's up to the Java wrapper object to free the memory when it's no longer needed. As a correlary: native code should NEVER assume that a heap structure will remain between calls. Any information that it needs to keep must be copied to a private (non-shared) data structure.
-