What's it all about, Alfie?

Today I decided to try and see if I could get the latest source of MAGIC (7.5.140) compiled on Mac OS X 10.5 without a lot of major hassles. Turns out there are a few things you need to know, and I'll detail them here, but the end result is that yes, you can get it compiled and it'll use the X11/OpenGL display and it's not bad at all.

I used MAGIC on some old DEC VAXStations and even an Amiga 1000 back at Auburn University when I taught there. It was a lot better than the home-grown layout tools that I had been using in my graduate work at Purdue - but most of that was likely because the guys at Purdue had to write their own tools - there just weren't any layout tools for the old TEK 4014 screens they had, and they didn't get color screens until late in my work. So it was probably a necessity. But MAGIC is just beautiful.

It can display the overlaps with different visual cues so that you know you have a gate when the poly crosses the n-diffusion. Also it had design rule checks built-in which made it a hundred times easier to really make something in MAGIC as you didn't have to constantly worry if your layout was going to fail in mask fabrication or in the actual foundry. The real kicker for grad students was the MOSIS rules and the pads they created.

With the MOSIS rules and the 'tiny chip' pad, we could have designs sent out to be fabbed at any of a number of silicon foundries in the country. It was an amazing thing to send out the file and see the chips come back and have the students see what they had made. Pretty cool stuff. Anyway, let's get to the building.

First thing is to get the source. I went to the MAGIC site and got the source for 7.5.140. I then unpacked it into a directory and went into the magic directory (a symlink is made in the un-tar).

The only change needed is to edit the configure command due to a linking issue with X11 and OpenGL - as OpenGL is referenced in both the X11 libs and the OpenGL Framework. Apple discusses it here and the fix to the configure script is pretty easy. Replace:

  -lGL

with:

  -lGL -dylib_file \
  /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib:\
  /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib

where it's all one line - I just put in the line breaks for readability sake.

Then it's the standard configure, make, and make install and it's installed in /usr/local/bin with supporting files in /usr/local/lib. Make sure you have the path right and you're golden.

I did notice that wish 8.4 segfaulted when I tried to run it, but that was fixed by using the configure command:

  configure --with-interpreter=scheme

so that the default Tcl/Tk interpreter is not used, but the built-in scheme interpreter is used, and then there aren't the issues. I'm sure if I built Tcl/Tk 8.4 from scratch and used that, it'd work, but I don't need an interpreter for MAGIC - I'm not doing that fancy of layouts and I didn't have one in the past, so I'm OK for now. If it gets to be an issue, I can deal with it later.

That's it... it runs.

  magic circuit.mag

and up comes the file. Just like I remember. Pretty sweet.

UPDATE: I tried getting it to work with the Tcl interpreter and it just wasn't going to fly. I'm not sure why, but the segfaults were in wish and that's not a good sign. Also, I had a hard time getting the scroll bars to work and the middle-button emulation wasn't working as I had hoped. So all in all, it's working, but only barely. It's not something I'd use for real. Oh well... it was a good try.

UPDATE: they have implemented the scrolling with the arrow keys, so it's not the scroll bars that's the problem, it's user error and remembering it the way it used to be. So I think I'll keep it for a while. Also, I figured out the middle-button issue - I had to enable 3 button behavior on X11.app in the Preferences. WIth that, I get the same one finger = left... two fingers = right... and Option+one finger = middle. Perfect. Now it's good enough to use. Good.

While I'm no artist, that doesn't mean I don't wish I were. Several years ago, I got an SGI Indigo² workstation with the HighImpact graphics card off eBay. I wanted to do lots of things - including a little graphics work because the graphics capabilities of that Indigo² were so bloody awesome! I've done a lot with barney over the years, lots of web development, database work, application icon creation - everything I wanted to do but the graphics work.

Back then, there was blender for the SGI - it was free then, even though it was owned by a company, and I was amazed at the speed and grace with which you could create 3D objects in it. When I moved to the Mac a few years ago, I was following the 'buying' of the blender code from the company by an open source group. It was interesting to see them get to the point that they had the money, and then took it over.

They even had a Mac OS X port.

Well today, they have released 2.46 of blender and it's as nice as it ever was, and just as snappy on my MacBook Pro. I'm still no artist, but if I get to the point in my life that I have months and months of time, I'm liable to try my hand at this. Take a few classes at some local college and then practice, practice, practice... Maybe I'll do this as a second career - I could do a lot worse.

I was talking to a friend today and he mentioned that these first four months of this year had been the worst he's experienced in this 3 years at the job he's at now. Everything is a give and take... good times and bad. So it's tough to know the difference between being tough and committed and over staying your usefulness. Are you being dedicated, or simply ignorant of the changing landscape? It's not an easy decision for anyone to make. We're almost always too close to the 'problem' (the job) to be able to make a good, impartial decision.

Dorey's mantra - Just keep swimming is a nice thought to keep in mind. But if you're fighting a losing battle, when does the Discretion is the better part of valor come into play? It's tough. Listening to my friend, I can see what he's saying... lots of changes, excessive management oversight (micromanagement), inadequate staff for the expected deliverables, it's nothing new, but all told, it can make a decent job downright unbearable.

But is it temporary? I can remember a lot of times in grad school where I was convinced that this was the last minute I could possibly do this. I was about to scream. But I didn't. Somehow, the spirit of Dorey saved me - Just keep swimming. It's probably not the smartest thing to do in every occasion, but it might just be the wisest in most.

I made it through grad school... maybe if my friend sticks it out, he can make it through this, too, and be better for it on the other side. Maybe it won't last much longer. Good questions, all, and not a soul on this earth can possibly answer any of them. And in the absence of any real, solid, answers, we each have to decide for ourselves.

As for me, I think I'm going with Dorey, I just need to keep swimming until a change is clear and obvious to me. Maybe it won't last four months, like my friend - maybe it will. No way to know.

This morning I noticed that Firefox 3.0rc1 was released... good news! I'm using it all the time on Windows, my Mac, and Linux - I guess I'm converted over. I still think we're a month or so away from full release, but it's nice to get the fixes and such that they are putting in as they polish this release. Still a good browser.

Still... in my tests, Safari beats all of them in speed and stability, but Safari surely does consume the memory. I keep Firefox around because it renders web sites that Safari can't because of the user agent.

I read this article this morning and from the sounds of it, Intel is getting closer to getting it's quad-core into an operating mode where it'll be able to be dropped-into the MacBook Pro frame and just run. While the report estimates that the shipping date would be sometime during the summer, it's unlikely we'll see anything from Apple until the fall, even if the chip ships from Intel on time. Apple has it's hands full with the iPhone and iPhone Store on iTunes.

However, it's very exciting to see that they will be producing something this year that should make it to the MacBook Pros by early next year at the latest. That will be an exciting thing to see.

I was looking at a problem today and saw a code snippet that looked a lot like this:

    try {
      if (timeToDoA) {
        ...
      } else if (timeToDoB) {
        ...
      } else {
        ...
      }
    } catch (Exception & e) {
    } catch (...) {
    }

where there were several if-then clauses each trying to determine what needed to be done based on the input conditions. Standard stuff.

Except for that try/catch block. That wasn't right at all.

While it was nice that the try/catch block was there to catch exceptions, I realized that it wasn't doing anything with them. This was most likely someone else in the group who put this in - if for no other reason than that's not how I would have structured it. In the end, I had something like:

    if (timeToDoA) {
      try {
        ...
      } catch (Exception & e) {
        // log error about doing 'A' with exception
      } catch (...) {
        // log error about doing 'A' with unknown exception
      }
    } else if (timeToDoB) {
      try {
        ...
      } catch (Exception & e) {
        // log error about doing 'B' with exception
      } catch (...) {
        // log error about doing 'B' with unknown exception
      }
    } else {
      try {
        ...
      } catch (Exception & e) {
        // log error about doing 'C' with exception
      } catch (...) {
        // log error about doing 'C' with unknown exception
      }
    }

With this approach, I get the logging and proper error handling with the focus on the events that precipitated the exception(s) in the first place. This level of logging might seem a bit much, but if there is a section of code that's too broad and an exception is thrown, it's going to be very difficult to find what exactly caused it. Better to invest the time and keep things tight and contained rather than too loose. Certainly in this codebase.

So watch out for those try/catch blocks that go nowhere. You may bot get an exception, but you may and not know it.

Well, I have to say that this Kindle is awesome. It makes carrying books a dream. I got a sub-$50 4GB SD memory card and now it can hold more than 3,200 books - based on their estimates. That's a ton of books. The battery life is great - I haven't had to recharge it for days after turning off the wireless access. The page flipping is not a big deal to me - a simple flash, and it's the new page. The print is crisp and legible - I can read it as easily as a paperback. It really almost makes it fun to read. Not that reading wasn't fun, but this just makes it exciting.

It's a wonderful little gadget. I'm very glad I got it. I know there are downsides, there always are. But if you believe that Amazon is going to be around for the long haul to support this, then it's a great way to get, carry, and read books. Highly recommended.

Everyone is talking about the update to the iPhone to optionally use 3G networks and all the spiffy new things they want with that - apps, access to this and that. If I had one wish for the iPhone it would be to be able to use it as a bridge to the internet via something like Ethernet over Bluetooh. It's already in the network preferences - all that would need to happen is to make it possible from the iPhone. Then, with a fast 3G network, I'd be able to use my MacBook Pro from the train. That would be most excellent.

I don't expect them to deliver this as it would really crush the network, and that's not the point of the iPhone - at least not Apple's point. They are looking at it not as a gateway, but as a stand-alone device in it's own right. I can see this, too. But I wouldn't spend $500 for that - I just don't need it. But I might spend $500 for a gateway to the internet. I would use it that much.

We'll have to wait and see. It certainly would be cool.

This morning I'm still thinking about the in-memory database. As the first step towards that, I realized that my CKTable didn't have indexing on the column headers or row labels. This is in the Java version of the table - BKTable, but not yet in the CKit version. So I took the time this morning to add those indexes into the CKTable. I also took the time to add the operator() to the table with two arguments - one for the row, the other for the column. This makes indexing into the data in the table very easy, and isn't available in the Java version.

The last thing I did this morning to move a step closer to the in-memory database is to add the cast operators for the CKVariant. This makes it a lot easier to use the variant in places where an int is need - or a string, assuming that the variant is holding the type of data you're casting it to. If not, it'll throw an exception, which is essentially the same as the ClassCastException in Java.

With these two things done, I'm off to thinking about how I might create an object that takes a table and does the extraction from it for a complex SELECT/WHERE clauses. It would be nice, but there may be real problems still ahead.

Today I realized that one of my price injectors wasn't properly updating the data structures. Well... that's not really right... it was working, it just wasn't doing what I needed. Basically, the first cut I had of the data structure was to have a map where the key was the price identifier (RIC for Reuters, BBG Symbol for Bloomberg, etc.) and the value was an array of instruments that would need to be updated if a price with this identifier came into the injector. Pretty simple. Price comes in... we pick off the identifier... we hit the map and get the array of instruments, and then for each instrument we send an update. Simple.

But it's got a flaw.

What if I received a new price identifier for an existing instrument? Then, I'd add another key to the map with one instrument on it. I wouldn't remove the old one, and so there might be two price injections for the same instrument. Bad idea.

The simple fix would be to remove the old instrument from the array in the map - but that would require a large scan - first, of all the price identifiers, and then for each element in the array associated with the identifier. I didn't like this scanning as it was bound to be inefficient when the numbers got very large. So I had to change, or at least augment, the data structures.

What I chose to do was to have another map - this one from the instrument to the identifier so that I could easily look up the identifier given an instrument. This would then allow me to quickly find all the instruments for an identifier, and then the identifier for an instrument. With this, I was able to quickly remove an instrument if the identifier changed, and also easily send out the instrument updates when a price (with identifier) came in.

But it got me thinking... what I really wanted was a simple database table. Something where I could say 'SELECT identifier WHERE instrument=blah', and then 'SELECT instrument WHERE identifier=zip'. This would allow me the freedom to look at the same data two ways, and even if I didn't have the complete relational database, a simple SELECT on a table would be all I'd really need.

There's a lot to think about here. Maybe it would be easier to just use the multimap in STL and see if that doesn't handle all my needs. If I did a multimap of identifier to instrument, I could easily find all the instruments for a given identifier, and with a reverse map, I could find the one identifier for a given instrument. I guess that making a simple template might be all I'd need and then I'd have all this functionality.

But that in-memory database table would be really nice. I can think of a lot of uses for it. I may have to spend more time on this tomorrow. It's a really interesting idea.

UPDATE: I looked more at the STL multimap and I don't like it's insertion methods at all. Yuck. Why not put in the operator[] like the map? It's got to be possible - but I can't fit it in after the fact. The best I can do is to subclass it or something. I'm really a bit surprised at this. In any case, I'm not going to keep going after the multimap for the price feeder. Ick.