What's it all about, Alfie?

Hey... I know I'm on the way out here. Just over six days left. People are going to be getting testy. Some will get nervous and anxious about the "what ifs" of me leaving. That's certainly understandable. I was more than a little worried when Jeremy left, but I also understood that it wasn't he that was the problem. He did what most would do - wrote up what he had and then it was up to me to get it working. That's just the way things are.

But it seems that's not universally the case in this place.

For the last several meetings I've been getting an increasing sense of animosity from the people that I'm doing this favor for. Let's face it, I could have left with less notice, or not had as much written down, or not had all the web sites for each project detailing all the workings - no one else has this level of documentation, and I've never seen anyone sit through three days of de-briefings.

And still... I get the grief.

I'm stunned. Maybe it's something that's been building up, I have no idea. Maybe it's because I've gotten no response from most of the IT management on my leaving - no "Hey, heard you were going, sorry to loose you". Nothing. It's just professionalism... common courtesy... it's not burning your bridges. But that's not happened. Oh well... I'm remembering all this very carefully as it's one of the reasons I had decided to leave. It's confirmed in this week that things are not all happy and chummy here. They are quite adversarial.

But I only have six and a half more days and I'm gone. God Bless CTC.

Well... I'm getting ready for the new MacBook Pro, and when it arrives and I get everything settled in to it's proper spot, I'll probably download the Safari 4 Beta and try it out. There are a lot of things to like in the new version, and there are a few things that some folks have said are a going to take a little bit of time to get used to. Fair enough.

But there's also a ton of hidden preferences to make things look like Safari 3, and if this is a little too different then these hidden preferences can make it a bit more palatable. Just not going to do it until I get the new laptop - too many changes.

UPDATE: I caved... There were a few really neat things, and the download allows for an uninstall, so I'm safe. I'll keep it on my box and have a go with it. So far, I like the tabs in the title bar, but I can see why some would not.

The OmniGroup are now giving away four of their lesser-developed applications, and of these, one is something I've wanted to have for a while - OmniObjectMeter. Back in the NeXTSTEP/OPENSTEP days, OmniObjectMeter was the tool for finding object leaks. And on the Mac, that's about the only memory issue you should run into. So having it is a real feather in your cap. But it was expensive for as often as I needed it. Now that's not the issue any longer.

If you are having issues with memory allocation in Mac OS X - get it. Trust me, it's worth the time.

The group at 280 North are getting very close to what I've been looking for in a web development framework with Atlas. The idea is essentially Interface Builder for the web. You can drag and drop components onto a window, wire things up, and it all works. Of course, it's still nib-ware, so to speak, if you want to create new objects it's going to require code, and the code required for a serious web site might still be a considerable bit of coding, but for the user interface, it's about perfect.

It's what I've wanted since Apple ditched WebObjects, and if we're lucky, Apple will give these guys a bucket of money and have them work on this as the next WebObjects front-end system. I would still love to have the back-end be Java or ObjC and be able to be written with Xcode, as that's my favorite environment, but I'd understand if it needed to be something else.

But what a deal that would be. State management in Java or ObjC and Atlas as the GUI builder. That would be an impressive bit of work. Can't wait to see where it leads.

Well, it's going to be an interesting week as I have a bunch of meetings with the folks here to try and give them as much knowledge as possible in the remaining eight days I have at the Shop. It's back-to-back meetings and tons of questions. Luckily, I've written so much down in the time I've been here, there's little they can ask for that I haven't already written down. But there have been a few little things that I've consolidated into a document for them. Seems only fair.

What amazes me about the transfer process is that there seems to be a decision at this point not to assign an individual for each system. I can understand the logic in having broad coverage of all the systems, but human beings are pretty easy to figure out - if they aren't going to be responsible for something, and they are busy with other work, the optional stuff is going to get dropped.

Maybe it's going to be different after I leave and someone decides that things need to be looked after in more detailed manner. Maybe they'll let me show all the systems to all the people and then they can decide what best fits where. I sure hope so.

I've voiced my concerns that if no one picks this up, when a problem does occur - and they do - eventually, there won't be anyone with even the bare knowledge to start digging into the cause. It's my fear, and now that I've expressed it, I'm done. No need to keep beating the issue. The decision has been made.

Well... the Blender folks have once again released a new version of the interesting 3D modeling software. I know I need to take time to learn to use this thing, but I just haven't had the time yet to do it. But I keep getting the updates so that when I do have the time, I've got the latest version to work with.

A few days ago, I started working on Issue #2 for CorePlot. I worked on this for quite a while trying to get the NSDecimal ivars on the CPCartesianPlotSpace to encode properly in Core Animation, but to no avail. The things I read on Google are basically that if it's not an object that conforms to the NSCoder protocol, then the data type has to be understood by Core Animation. That means it has to be a CG-prefaced data type. Fair enough.

The problem manifests itself as a run-time error message like:

2009-02-11 13:49:39.126 CPTestApp[26427:10b] unhandled property type encoding: 
`{_CPPlotRange="location"{?
="_exponent"b8"_length"b4"_isNegative"b1"_isCompact"b1"_reserved"b18"_mantissa"[8S]}
"length"{?="_exponent"b8"_length"b4"_isNegative"b1"_isCompact"b1"_reserved"b18"
_mantissa"[8S]}}'
2009-02-11 13:49:39.128 CPTestApp[26427:10b] unhandled property type encoding: 
`{_CPPlotRange="location"{?
="_exponent"b8"_length"b4"_isNegative"b1"_isCompact"b1"_reserved"b18"_mantissa"[8S]}
"length
"{?="_exponent"b8"_length"b4"_isNegative"b1"_isCompact"b1"_reserved"b18"
_mantissa"[8S]}}'

I talked to Drew about this and told him that the only way I could see to fix it was to either drop the precision on the CPPlotRange by using CPDoubles or to update the CPPlotRange to a full-blown class with instance variables that are (NSDecimalNumber *). These guys implement the NSCoder protocol, and with a little extra logic, the new CPPlotRange can fit into the codebase nicely.

So that's what I did. It was a blast. I then checked it in and sent Drew an email and updated the issue on Google groups. I asked Drew for comments on the code, and we'll see if he thinks I went overboard on the comments (I didn't), or if there's something he thinks I should have done and didn't do.

All in all - very exciting.

The mailing list alerted me that MacVim Snapshot 43 is out and while the changes aren't earth-shaking, there are new icons, and there are gains in the way the forking is done so as to improve the startup time of the windows. Not bad at all.

I have to say, it's nice to have this reliable tool on my machine as I'm moving from one job to another. It's a constant companion.

I was doing a little work on the CorePlot code today - trying to get rid of a bug that's in the running of the test app, and likely to be in all applications based on the CorePlot framework. It has to do with the fact that CoreAnimation is checking the ivars of the subclasses and making sure they are encodable in it's scheme of things. Not that it's necessary, but maybe it is internally.

In any case, I was remembering this article where there's a simple compile-time definition for the framework that forces the Cocoa and CoreGraphics datatypes to be interchangeable. This would have been really nice, but it's not for the more complex data structures like NSDecimal, which is the problem I'm having at the moment.

However, this is really something to hold onto as it's bound to come up several times in the project, and I wanted to be able to put my finger on it quickly.

Well... I'm stumped. I had been working on a few things for the unit testing framework yesterday, and today I wanted to look at this problem that had been reported on the Google Code site. Basically, there's a build problem, and I wanted to track it down.

First thing: build the code and reproduce the issue. It builds fine - I can't see the error, but when I run it within Xcode, I get the following on the Console:

    [Session started at 2009-02-20 12:05:37 -0600.]
    dyld: Library not loaded: @loader_path/../Frameworks/CorePlot.framework/Versions/
        A/CorePlot
    Referenced from: /Users/drbob/Developer/core-plot/examples/CPTestApp/build/Debug/
        CPTestApp.app/Contents/MacOS/CPTestApp
    Reason: image not found

  The Debugger has exited due to signal 5 (SIGTRAP).The Debugger has exited due to
      signal 5 (SIGTRAP).

OK, this should be easy - it's got to be that the CorePlot.framework isn't properly in the project and that's what's missing. So I looked into that. But it's there. Just where it should be. Then I dug into the built CPTestApp.app wrapper and right where it's supposed to be is the framework! I'm stumped.

I looked at the project settings... nothing popped out at me. I cleared the Xcode project file and reloaded it from the repo... no difference. I even did what I thought should have been done and added in the CorePlot.framework to the Linked Frameworks 'folder' in the project, and still nothing.

I'm blown away! So I finally shot an email to the mailing list and we'll see if we can't find out what's up. I'm really stumped. It used to work!

UPDATE: HA! I got it figured out. First, the path for the library is encoded into the Framework - not in the app using the framework. OK, now that I knew that, I started looking at the CorePlot Framework build parameters. I noticed the one that I was looking for in the Deployment section:

Originally, the Installation Directory was set to:

  @loader_path/../Frameworks

and that was what was being set in the dynamic library, and compiled into the app's executable. What I needed to change was the path to:

  @loader_path/../Resources/Frameworks

and then it was able to find the framework and run.

OK, this wasn't obvious in the least. I Googled this guy and came up with nothing other than the fact that the name was in the shared library - which I had remembered as soon as I was reading the post. So, at least now, I can see the error, and hopefully get a handle on it.

UPDATE: Drew commented that he had changed the @loader_path to @executable_path a while back, but that there may have been issues in the merge that was done to get the testing code working. So I emailed back that he's free to change it back and I'll just pick up the right version in the next 'svn update'. Sounds good to me. Glad to see I wasn't totally missing it.

[2/21] UPDATE: Barry pointed out that @loader_path is the right value - but the project was not configured to copy the framework into the right location. So he fixed that. It builds fine now.