News and commentary from the cross-platform scripting community.
	Tuesday morning development update

By Doug Baron, dougb@chilehead.com.

Dave,

I kicked butt at the end of last week. As I mentioned earlier, I decided that the most productive way to move forward is to bring most of the remaining Frontier code base over to the PC. We already have the core of the language, the odb, and the outliner working, but now we're talking about table and wp windows, complete window management (with its verb set), and even the menubar editor. Most important, to me, is being able to view and edit the odb. But we're looking at a lot of new code being ported.

Thursday, I got most these Frontier files to compile under CodeWarrior in a Win95 project. That's when I spoke to you last. I then moved the files over to the PC and made a small number of additional changes to get it all compiling under MSVC. Finally, the link: a little over a hundred errors. My work was cut out for me...

Friday I dug in. I could see that the most difficult area to resolve was going to be the process/thread management layer. The file process.c hadn't been ported at all because of its dependence on Mac threading. Some of its entrypoints had already been stubbed out, and I considered stubbing out all of the newly-referenced routines. But why make work? Instead, I went back to the Mac and set out to a long-overdue cleanup: separating out the threading code from Frontier's internal process management, which have been comingled historically.

I thought that might take all day, but in a few hours I had a new file, threads.c, and a process.c that doesn't include the Mac's Threads.h. Much better!

Back on the PC, link errors went down into the sixties. Chunk-by-chunk, error-by-error, I whittled them down. Finally, at the end of the day, I reached my goal: zero unresolved references. Yeah! Of course, the program crashed before a window could get onto the screen. That's where this week started.

Yesterday, I squashed several bugs, but didn't quite get to the point of getting code to run in the new environment. I found some problems at the very highest, event-loop level: the shell's backgrounding code wasn't being invoked at all. More importantly, I realized that running scripts out of outlines that don't live in the database presents a significant new twist for the script debugger, which has always assumed that scripts come from the odb or from a menubar item. New code had to be written to allow for this new case.

I've now finished cleaning all of that up, and have fixed a couple more bugs -- including one that wasn't new, but doesn't happen to show up on the Mac. Before I started writing this memo, I reached the first milestone: running a script out of a standalone window, living in the full Frontier windowing and threading environment. It works! Of course, at this point threads.c has not been implemented under Windows, so it's going through the code path for when the Thread Manager isn't present. But it's for real!

The next step is to get this script working:

edit (@root)

Actually, since there isn't a system.verbs table, this needs to be written as:

lang.edit (@root);

Once this succeeds, I'll be able to see whether or not table windows work. There's a lot of code in there waiting to be proven. It shouldn't be long now!

Doug