What's it all about, Alfie?

As reported on Mac Rumors, there seems to be a way in Leopard to disable the shelf-style Dock in favor of the Tiger-like window-style Dock. The tip is pretty easy:

    $ defaults write com.apple.dock no-glass -boolean YES
    $ killAll Dock

and the Dock is back to the Tiger-style Dock. I'm not sure which I'll like more, but I had a feeling that the new "glass" style would be something that annoyed me to no end as I typically hide my dock, and when it comes up, I want it to look more like a window and less like a shelf.

Let's not forget about the defaults value that makes hidden apps visibly hidden on the dock:

    $ defaults write com.apple.dock showhidden -boolean true
    $ killAll Dock

I've used this one for a long time, but I'm not sure if the upgrade to Leopard is going to remove this, so I'll keep it handy just in case I have to re-apply.

The way to enable the root user on 10.5 is to open the Directory Utility in the Utilities folder under Applications. Unlock it for changes and then under the Edit menu, select Enable Root User and type in the password for the root user. No need to login as root, but it's proven itself very handy when making backup scripts, etc.

I read this from Ars Technica this morning about the new Verison FIOS 20/20 plan, and all I can say is Wow!

Some residents of New York, Connecticut, and New Jersey who live inside the boundaries of Verizon's FiOS network will be the first to be able to take advantage of Verizon's new 20/20 FiOS service. As the name implies, 20/20 FiOS is a symmetrical 20Mbps connection (same speed in both directions), and it's one of the first symmetrical services to target the consumer market.

Available today, 20/20 will cost $64.99 per month and will include Verizon's Internet Security Suite and 1GB of online backup (up to 50GB can be purchased at "competitive rates").

20 Mbps down and up. It's just what I've been hoping would come to Chicago, but they don't seem any too interested in rolling it out to these parts - yet. However, it would be nice if Comcast responded with something like 10/10 which I'd be all over. The problem I've run into in setting up my home network services is not the uptime of my boxes, it's the speed and unreliability of the link. From home, in download mode, it's great. But accessing services from the road has always proved really quite hit or miss.

I look forward to the day when I don't have to worry about what's a home versus what's on my laptop. It'll make getting things done a lot easier.

This week marks the time when we have to make final preparations for going off Daylight Savings Time (DST) which is important because Hong Kong does not observe DST, and so we're going to loose an hour at the end of our day and the start of theirs. This is important for trading and risk apps like mine. The original solution was to make my app run 24x5 without any interruptions. This was a significant technical challenge and after about a day or two of this, I decided that it'd be better to make use of extra hardware to have two servers - one that covered the US and Europe, and another that covered the Far East.

Problem was, this meant that there was going to be a lot more maintenance of the system to keep two systems up and in sync. After hearing me say this, most said "Yeah, yeah" nodding their heads, but thought I really didn't understand the situation. When I came back with a list of things that would have to be done each evening to make this work, all of a sudden the easier solution to the problem appeared.

The problem really comes down to the fact that we typically didn't start the nightly processing until about 5:30 pm, Chicago time. This was 6:30 am Hong Kong time, and after the DST change, it'd be 7:30 am Hong Kong time. Given that the start is then, it's likely that we are not up and going by 8:00 am local time in Hong Kong, and that's the problem. So I had suggested that we move up the end-of-day processing, but that got nowhere. Then they saw what they'd have to do to support the two servers capable of giving Hong Kong the data they needed when they needed it.

All of a sudden, the end-of-day processing was moved up to 4:15 pm Chicago time. Plenty of time before Hong Kong would need it.

While I'm a little frustrated by the fact that I wasn't listened to earlier, I have to take solace in the fact that eventually my ideas found ears, and things started to move in the right direction. Now the second hardware is for disaster/recovery and there's only one server covering the globe. It's simpler, and while there are bound to be bumps in the road, things are going to be better by moving up the end-of-day processing.

That first bump was last night when I got a call on the train. It was from someone asking if there was a way to edit the data that's sitting in the middle-tier of the application. I said "Nope, it flows from the server, and that's already thinking it's tomorrow." I knew what they wanted to hear, but it wasn't going to happen. The data in the middle-tier is too complex to simply edit with something like a text editor. The values are interrelated and computationally intensive calculations need to be done in order to derive some values from others. It's not easy. Which is why there's no easy editor of that data. But because of the early restart, the guys didn't check on the state of the system early enough in the afternoon to make sure that it would be good to go for the earlier restart.

Lessons learned. Like I said... a few bumps in the road, but it's a better place we're going to.

Several years ago I got an iBook after not having owned a Mac for many years. When I was at Auburn I was a big Mac Fan because I'd tried to write papers using PCs, and there just wasn't a reasonable set of tools on DOS/Windows that even remotely compared to the tools on the Mac. But when I went into business for myself, I targeted the largest audience possible and that meant PCs. Later, when the only thing that mattered was what I wanted, I got the iBook. I looked around, and while TextEdit was OK for somethings, and ProjectBuilder used it, I wanted a little more powerful editor. I went with BBEdit.

I haven't regretted the decision, BBEdit has been a wonderful tool. But a while back, Hydra was written by some interesting guys in Germany. Collaborative text editing. I could see that being a big deal. They had to change the name, so they picked SubEthaEdit. It was shareware for a while and then they went full commercial with a 30-day trial period. There were some things about BBEdit that I didn't like, and as importantly, I wanted to like SubEthaEdit. So I gave it a spin.

I liked the syntax highlighting a lot better than BBEdit's. I liked the collaboration, though I have to admit that I've never really needed to use it. Probably most importantly, it looked more like a Mac OS X app as opposed to a converted Classic Mac OS app - which is where BBEdit originally started. There were a lot of things that I thought could be better, and my philosophy has been - if you want to ask for more, pay for it. So I did. And then I sent in the requests.

Things got a little better, and now with version 3.0 several things have gotten a lot better. The speed of syntax highlighting is vastly improved. They have added the ability to save an editing session with all the meta-data so that it's easy to pick up where you left off. They also added SSL encryption on the communication so that you can edit in secret. Nice features, to be sure. And while I appreciate that they are not interested in making a bloated package, there are a few things that I'd still like to see:

• Fix the method signatures in the method list - this is a complaint I have with BBEdit as well. Both apps have a touch time getting the method signatures right. This is a big deal when you're trying to quickly find the method you need to work on. If I have a C++ file with 10 different add() methods, it doesn't help a lot to see 10 add() entries in the list - I need to see add(int) and add(double), etc.
• Allow for marks to jump back to - this is one place where Vim beats BBEdit and SubEthaEdit - the ability to set little marks, go somewhere else in the code, do what you need, and then jump back to the place you left. BBEdit is close with it's Marks, and I've added the key-combinations to make it easy to set them, but jumping is still a mouse-driven process. I'd love to be able to use the keyboard alone. SubEthaEdit doesn't have the feature at all.
• Allow Page-Dn with the cursor - most editors allow the user to 'page-down' the file with the cursor by hitting some key combination. BBEdit does this with Option-<Arrow> and SubEthaEdit allows you to page-down, but you don't move the cursor. It's a mouse action to do it in SubEthaEdit.
• Fix the highlighting of -1.0e-12 in FORTRAN code - I submitted this bug a while back and they didn't get around to fixing it. The problem is that for the number 1.0e-12, their C++ highlighter works wonderfully, but their FORTRAN highlighter colors the '1.0' as a number, the 'e-' as text, and the '12' as a number. It needs to be consistent. Also, both their C++ and FORTRAN highlighters miss the leading minus sign ('-') on negative numbers and color it as text as opposed to the numerical constant. It needs to be tagged and colored with the number - not as text.

The thing is, I still want to like it. I want it to get better. So I get the upgrades, pay the money and send in the requests. After a time, maybe they'll see that I'm serious about supporting them and get the few little features that I keep asking for. I can't think of another way to make it happen, and I'm pushing on BBEdit the same way. I have no desire to write my own, and if BBEdit and SubEthaEdit don't turn out, I can go to Vim and be happy enough, but I want a Mac experience in my editor, and one of these guys is going to get there. I hope.

UPDATE: I figured out that the FORTRAN syntax coloring problem was in the Fortran77.mode file that I got from them - but was not a built-in syntax mode in SubEthaEdit. This meant that I could edit it and fix all the syntax colorization issues without having to wait for them to fix them. So I did. I fixed several problems, in fact. In the end, I went to the bug tracking system and updated the bug entries saying I had solved it. Unfortunately, I was unable to upload the changed Fortran77.mode, but I left a note there for them to contact me if they wanted me to email it to them.

I was taking a break this morning, trying to get rid of a headache that is really killing me, waiting for the Advil to kick in, and was thinking about the fun games that have really held my interest for a long time. There aren't many. But what has kept my interest are the really great games that I've been playing for a very long time.

Risk - this classic board game is a pain in the neck to play with people because if you don't have a good group of at least 5 people, it's not really that fun, and can really get quite annoying if you have a few people that don't even try to play the game. Thankfully, there's iConquer on the Mac which is a superb version of Risk with decent, though not really super challenging, computer opponents. It's a great for 15 to 20 minutes, but if you want a real challenge, you're going to have to play against something with a pulse. They have network play, but again, there's the need to get 5 good people together.

Xconq - this classic adaption of Empire is about as fun as strategy/turn-based games get. There have been a lot of these in the 'bookshelf' games over the years, but again, since this guy has pretty decent computer opponents, it's a great way to spend about an hour. Unfortunately, they are dropping the native Mac OS X interface from the project, and it's even questionable if anyone is supporting it any longer. It used to be worked on by guys from Apple and RedHat, but it's gotten away from these guys and into the general SourceForge community. I haven't received a message on the mailing lists for a very long time. Still nice, so long as I can get it to run, but there will come a time it's dead, and that will be a sad day.

ChopLifter - this has been on Apple ][, Sega, Mac OS X, and probably a dozen other platforms as well. It's the classic 'rescue the guys' game and fun for about 10 min. After that, I get a little bored and my interest falls off. It's fun enough every now and then to hold my interest for those 10 mins., but I can't say that I really look forward to playing it - it's just "there", and I play it for a bit.

I've played a few FPS games - no real interest. Networked games are nice, but only as a way to get those critical people together. I guess I'm just Old School - or just Old.

Whew!

It's been a week.

Pretty much all this week I've been heads-down coding this 'infinite' precision floating point number first in Java and then in C++. There were a lot more issues to deal with than I had expected to run into in this little class - face it, it holds a number, adds, subtracts, multiplies, and divides. That's it! But, boy-o-boy, there's a lot more to just that than it sounds.

I've talked about a few of the issues in the post I made after the Java version was done. But then the conversion was pretty easy for many things, but had quite a few gotchas in the C++ codebase. Little things like clearing memory on creation - thought that was covered, but then I realized No, of course not... and had to fix that. Then there's the locking scheme - mutexes are great, but it's nice that Java allows the same thread to "relock" a section of code without blocking. I'm guessing that I could probably do the same thing on the CKit's mutexes, but it might be a bit dodgey, and so I may just hold off on that idea.

The Java class was 2442 lines, and the C++ was over 3700. Lots of comments, or course, but still... that's a ton of coding for a week. The test apps were another 390+ lines each - so I was plenty tired of typing by the time I got the C++ version ported along with the test app.

I'm glad it's done and all checked in.

As an aside, this all started from a problem a developer came and talked to me about last Friday. Since then, his initial work-around failed for one condition and others put in their $0.02 to say that they didn't think it would be that hard to do. Silly people... If I spent a week on this then it's hard. Impossible? no. But it's a lot harder to get right than most people think. I know it was a lot harder than I thought it would be. I figured a few hours for the Java version and then a few more for the port. I should have thought "days" as opposed to "hours". Glad it's done.

Well... this is a pain in the neck, but I'm glad it's solved. The problem is that I was trying to rebuild CKit on my Mac using make and Xcode 2.4.1. It compiled fine, the test programs linked fine against the generated .dylib dynamic shared libraries, but when I tried to run it I got:

    dyld: Library not loaded: /var/tmp//ccr3sui.out
    Referenced from: <path_to_test_app>/test
    Reason: image not found
    Trace/BPT trap

The problem was that the 'tmp' file wasn't there. When I did an otool -L on the application I got:

    test:
      /var/tmp//ccr3sui.out (compatibility version 0.0.0, current version 0.0.0)
      /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.3.3)
      /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.4.0)
      /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)

When I looked at the shared library that I was testing, it had the same reference to this temporary file. I was stumped and blown away. I googled a lot of things and then found a reference that had a similar problem. The solution was amazingly simple and yet it should have been taken care of my Apple's compiler.

The link phase of the build of a dynamic shared library allows for the addition of a few options that shouldn't really matter unless you want to take advantage of the unique features of Mac OS X. They are:

    -install_name libCKit.dylib
    -current_version 1.0.0
    -compatibility_version 1.0.0

where you can make the versions anything you want, but the key to this riddle is the -install_name. By default, the linker is setting it to the temporary output of the link, and not the name in the -o parameter. The docs say this is the default for the install name, but it's not. When you use the same value for the -o option and the -install_name you'll see that the output of otool -L changes to be:

    test:
      libCKit.dylib (compatibility version 1.0.0, current version 1.0.0)
      /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.3.3)
      /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.4.0)
      /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)

We can now clearly see the difference. As long as you have this library in the path specified by DYLD_LIBRARY_PATH, you're good to go.

I spent hours on this. I was trying all kinds of things to see where these temp files were. It's a stroke of luck that I found the web site with the reference that I needed. Yikes. Well... now it's here and maybe it'll help the next poor sap that's got the same type of problem.

For the last several days I've been heads down coding this 'infinite' precision floating point number in Java for BKit - BKFloat. I learned a lot of really interesting things in the process. Now that I've dug myself out of that all-encompassing task, I can take a little time to talk about it.

When I started working on it I thought that the best way to implement the class was to have a long as the whole number part and another as the fractional part. Then, when I needed to do any math, it was pretty easy as I could take advantage of the long's ability to do the math. And this got me quite a ways to the end. But I started running into a lot of problems when I got to the point of really building the add() and subtract() methods because I was getting into coding based on the long and not a general 'infinite' precision floating point number.

For instance, with the long, I still had to deal with the fact that I did have an upper limit on the number of digits I could represent. Sure, it was big, but it wasn't as big as it might need to be. Some of my test cases had numbers in scientific notation and for those guys I had 5.5511232344325E-17 and the like which made it very hard to make sure that I had enough digits to express the non-zero elements as well as the proper magnitude of the number.

The final problem that snapped this design was the use of the sign on the fractional part. Imagine that you had two longs - one for the whole number part and another for the fraction with an implied decimal point in between them. If I had a number like -0.5 the whole number part would be 0 and the fractional part would be 5 - but where did the sign go? If you had -1.5, the whole number part would be -1 - there's the sign. So I had to 'pack' the sign on the fractional part if the whole number part were zero. This lead to a lot of code to make sure I had the right sign of the number for the operation. It was looking ugly and I just knew there was a better way.

So after about a day of that I backed off and thought that the better way had to include the resizing of the digit storage in order to make sure that the only limitation to the size of the floating point number was the capacity of the machine. I also had a feeling that by separating the digits I'd be able to implement the arithmetic operations a lot easier because I could code it like third-grade math. So I started off on that tack.

The next day was spent gutting the code of the long-based code in factor of byte[] storage for the digits. I spent a little more than half a day getting to basically the same point that took me the previous day. I had added a lot of little things like the ability to shift the number right or left as if multiplying (or dividing) by 10. This made a lot of things easier and in general the code was drastically simplified.

The things we learn in third-grade are really powerful. Coding carry and borrow on the add() method was interesting and a bit of amazement at what we all do so easily. It's really quite amazing. I've done the classic computer numerical manipulation with the XOR for multiplication and the full adder, but this is interesting in that it wasn't base 2 and yet it was exactly a digit at a time. Very interesting. I don't think I've ever written code like it.

Multiplication was interesting and fun at the same. Division was almost fun once I got into it. Of course, the division was the first one that might have a loss of precision due to the mature of the operation so I had to do a few interesting things there, but in the end it was working remarkably well. I don't think this is going to set any speed records, but the point is not speed but precision and accuracy. The test cases I used in the development pointed out that there were plenty of times where a simple double in Java is just not very good at representing values. This class is for those times when you have a handful of numbers that have to be added, etc. without any loss of precision. For those cases, speed is typically not as important as the precision. Good enough.

Now I'm back down into the hole to convert it to C++ for CKit. Shouldn't take too long... all the logic and method calls are already worked out.

This morning I got a visit from Ammo and he's guarding my desk now when I take a break. It's nice to know that I've got an angry amoeba with an automatic weapon looking out for me.

Friday, a developer stopped by and talked about the problem of dealing with the precision problems in Java and C++. I thought about it a lot over the weekend and decided that I wanted to code something up for BKit that would be a general purpose object that could hold these floating point numbers without loss of precision due to representation or operation.

I think the best way to go about this is to have a long for the whole number part and a long for the fractional part. This way, it's very easy to work on the parts, but they will be able to hold a very large number.

It's off to coding...

UPDATE: after spending the day on this approach, I've decided that it's not the best. I'm going to start over tomorrow morning with byte[] where each byte is a digit in the two parts of the floating point number. The reason for this is simple - the longs were giving me limitations that I needed to deal with and it was getting very much code for the sake of the data storage choices. So I think I'll be slower, but much better with a more general storage like byte[]