For the last 2 weeks I’ve been down to only one machine, from my usual two development machines. Mishap with the power connector when replacing the hard drive in my iBook. Thanks to the good folks at DT&T Computer Services (who fixed, vs replaced, my motherboard), my machine is back up and running. Service from them was great (although they were having email sending issues so I had to call them to get my RMA number, and it seems like you have to send them an email to check the status of your machine).
I develop different projects on different machines, so when one machine goes down I have to set up the project on the other machine. Sometimes this is easy… sometimes not. One project quickly moved over (aside from some productivity hits), one project moved over except for talking to some hardware (which I just didn’t bother to set up), and one project I couldn’t compile the support libraries for ( first wxWidgets compile/link oddities, then wxWebKit link errors. Big C++ libraries are quite a pain sometimes).
The iBook is back up and running, so progress can move forward at a slightly faster (and portable!) pace once again.
On the machine front, yesterday I spent a good chunk of time updating my Debian server to the latest of everything. That did mean the blogs and the wiki were flaky yesterday, but they’re back to normal today.
Given Apple’s 64 Bit Carbon plans, a lot of people are wondering if Carbon is dead (or not). (See one example of this over at Michael Tsai’s blog entry on 64-bit Carbon).
All I have to say here: there’s an advantage here that wxWidgets brings me: one can hope that the wxCocoa port of wxWidgets will step up to the plate. If it does (and I’ll probably pitch in here), then I just recompile my wxWidgets apps with wxCocoa, and I’ve made a major shift already. No rewriting all of my view (or controller) code, just recompile the underlaying library. Since wxWidgets is an abstraction, it just abstracted the API change away from me.
The only thing I would need to rework in my apps would be the places where I’ve called Carbon routines directly to provide Mac OS specific features, or where I’ve modified wxWidgets and now need to rewrite my modifications.
So I’m using a little bit of Cocoa in a client’s application. The fun thing is that this application is mostly Carbon/wxWidgets. This isn’t too terribly odd: people use Cocoa in Carbon applications all the time (anymore). The wxWidgets part is different than normal, but whatever.
The trippy thing comes when I needed to adapt when the system Appearance color changed (so Aqua to Graphite, for example). You can get that via [NSColor currentControlTint], but the old Appearance Manager Apple Event (kAppearanceEventClass/kAEAppearanceChanged) must fire too soon, because looking at the currentControlTint color then just gives me the old color.
Cocoa has a notification for this NSControlTintDidChangeNotification, and using this in a Cocoa app, then retrieving the control tint, got me the new tint.
So I had an idea: Register for the (Cocoa) notification (via NSNotificationCenter) in my Carbon/wxWidgets app (in a wrapper function). Whatdayaknow… my notification got to me! (Which I then turned into a wxWidgets event and sent along its way).
So now my (Carbon/wxWidgets) + Cocoa app has three ways of getting events: Carbon Events, wxWidgets Events, and the occasional Cocoa Notification. It’s the first time I’ve used that last one, and I think it’s pretty trippy (and really really cool).
Last week I worked entirely on the G5, with my laptop in Firewire Target Disk Mode. This week the G5 is doing other production work, so I’m back to working and building on my laptop. It’s quite a change…
Comments Off on Back to the portable
I worked all week on VonTrapp stuff. It kinda felt good.
One of my responsibilities is working on rewriting the menu code. This week I got the menus looking much better than they did last week, and also took care of two issues.
The two issues were the Apple menu (under OS 9) (aka: the Application menu (under OS X)), and the Font menu. However, since we’re using a cross-platform framework, platform specific features (such as these) tend to be, well, not included.
Comments Off on A Week’s Work
Starting back on the VonTrapp project after having pretty much left it for a few weeks. Since that time there have been two pretty big checkins by Other People.
So now I have to recompile the codebase. All of it. I would rather be working right now, making actual progress. Instead I’m waiting for a compile to happen. There are also two errors in the compile that I have to track down somehow. I’ll be waiting for a while – the pascal code takes about 15-20 minutes to compile on my machine, and the C++ code probably takes 15 as well.
At least it’s compiling the C++ now. Halfway done, probably.
Counting down the days until I order/get my new G5… I’m pretty sure I’d already be working on me stuff now if I set that baby to compiling this.
I would almost prefer compiling remotely, on the On Load xServe then I would locally. At least that’s fast. A laggy interface, with the whole Remote Desktop/TB2 thing going on, but I can mostly deal.
Comments Off on I just want to Work!
Merging C++ is not fun. After you deal with CVS issues (like merging and dealing with conflicts), you get to compile. Or try to anyway.
The first challenge was precompiling the precompiled headers. (These speed up compile time – the files are only compiled once, instead of once per #include.)
In compiling these headers, I ran across a problem – someone didn’t end an #if where they should have. This may have been a human somewhere, or just the cvs merge process not knowing any better. Here the story begins…
Comments Off on How I mastered preprocessor directives (finally)
CVS takes sooo long to import sometimes. Then, after the import, I have to merge branches.
All this is fairly easy work, with my scripts and whatnot. But, my word, sometimes the easy stuff is the most painful. Just sitting here waiting for CVS, gahhhhh.
And I hope I got all my settings right – because I have to do it all again if they aren’t. Thanks MacCVS Pro.
Comments Off on CVS Rant
Today I got wierd errors from CodeWarrio. File Contains Null Character. Looking at the file – there really were.
Of course, MacCVS Pro says the files are no different, and have not been changed – oh no.
Eventually I relized that they were somehow different. Modify Read-Only, Rollback to about 14 files. Not exactly hard, just… odd.
Thank you fun file system corruption.
But I made progress on other stuff
Comments Off on WierdStuffHappens
I finally finished merging vendor code with our code. Along with the ordinary fun cvs conflicts, several dozen files also had this problem
That folks is what a cvs conflict looks like. Of course, this won’t compile (that’s part of the point, I think).
But it’s also conflicting on a autogenerated keyword!
You see, CVS will replace keywords (“stuff betwee $s”) with Useful Information it figured out during commit time.
Of course, these two files were committed at different times with differnet versions. Because they were (and that’s the point).
None of these lines contain useful information (because CVS will replace it with real information when it does a commit). So I wrote a script to un-expand those keywords.
Of course, it still probably added a half hour to the job, as I had to locate the files that had those kind of conflicts and run the script on them. Plus I’ll have to check in these “changed” files to the repository.
In Summary: CVS conflicts and merging are fun. Especially when its CVS that causes the conflict in the first place