The MacVim guys had a problem with Snapshot 41 - the iconv library wasn't included in the package. So they quickly released Snapshot 42 this morning. I'm not exactly sure what uses this library's functionality, but I didn't hit it in the two days running it.
Nevertheless, update I did, and here we go.
Today I saw that MacVim Snapshot 41 is out and they have put in some really nice new fixes and features. The first one is that the Sparkle support is working which means that I won't have to download it directly each time - very nice. The next is that they have changed the default font loading for the initial window load, and since I don't use the default font, adding the following default:
defaults write org.vim.MacVim MMLoadDefaultFont 0
I can significantly improve the opening speed of the editor windows. I will admit it looks a little snappier. I'm glad to see that, as well.
Once again, this is the superlative implementation of Vim on the Mac OS X platform. If you have any use for Vim, get it. You won't be sorry.
I started using Git for a simple project (the Xerces-C stuff I was playing with) just to get in the habit of using it and making sure I didn't forget what I read - which, of course, I had. But the purpose of this little project is to exercise Xerces-C and Git - and for that it's working perfectly. But I was still using just the command-line tools, which isn't bad, but I knew there were a few GUI tools for Git on OS X that I had seen. So I decided to track them down this afternoon.
I stopped as soon as I found GitX v0.5 - what a find! This is exactly what I was looking for - something that will make the harder Git repo work a little easier. It all seems to be in ObjC and a decent interface to boot:
I like that it's easy to understand, and when branches and merges get in the mix it'll be nice to have something to make sure it's clear what came from what. Still, it's a little rough still - no ability to configure the toolbar, which I noticed right away. Not horrible, and I can't imagine it'll replace the command line version for me, but it's great to see something that can help out if I need a little something.
I also like that once you start the app, you can have it place a link into /usr/local/bin/ for gitx so that you can start it easily from the command-line. Nice touch, guys! Very nice.
Last night I got a call from the second-shift operators here at work about a problem with my fast-tick risk engine. Basically, a process that gets the information on all the options in the system was handing and timing out and therefore was failing. This code hasn't been changed in years (so I thought) so I had no idea what to make of the problem. Time to dig into it.
I got online and looked at the stack trace of the error. I tried to match that up to the code in CVS, and couldn't. Great! Someone changed the code and didn't check it in! ran through my head more than once. So I had to get the manager of the unknown coder that had to have changed this online as well. He looked at the diffs in ViewCVS and came to the conclusion that the changes were all cosmetic. I had said that I could track this down, but I'd need to be able to rebuild the code to add in some debugging/logging statements that were very much absent in the existing code. But to do that, I had to know that I had the right version of the source or we'd be in even bigger trouble than we already were.
He gave me the go-ahead and I updated a few libraries of mine to make sure that it wasn't a flaky problem I'd fixed in the last year or two, and then rebuilt and deployed it. I got the same errors, but this time, the line numbers lined up with the stack trace. Finally! I could get to the bottom of this.
What I found was that even though the server appeared to be working properly, it most likely had a locking problem that was causing this issue and while I could not be positive on this, it certainly appeared that this was the cause. So I let everyone know and restarted the server. When it came up, everything worked as it should. Good.
This morning, I then dug into the effected code and noticed that since it was very old I hadn't updated it to the more consistent locking scheme I'd put in place for the rest of the app. I didn't have the read-lock on the master list of instruments - and it needed to be there so I'd be safe from any additions/deletions, and there was a read-lock on the instrument which wasn't necessary because the data I was looking at is set at load time and there's no way to change it during the run-time. I replaced it with a safer retain()/release() pair, and this will also protect me from having the instrument deleted out from under me.
With these changes, the dev server worked perfectly and I've been able to get several large queries through it without any problem. Nice.
The lesson here is that all good code needs to be maintained regularly to make sure that changes in one part of the code make it to all other effected areas. This hasn't happened in this codebase simply because there isn't time to do so. When something breaks (like last night), there's time to fix it, but not before. I've said it many times before, and it's still true - the best time to fix a hole in the roof is not during a monsoon. Too bad we just don't have the time.
I was trying to get a decent handle on working with Xerces-C today as I know I'm going to need to know how it works when the specs come from the vendor that I have to interface with. I'm going to be putting together a large XML file of a lot of data for nightly shipping to this vendor. They, in turn, will massage the data and make the results available for us to pull down and view/process. It's essentially an outsourced compute facility that's got a great reputation for the numbers they create.
But to the point, I needed to have some way of reliably making an XML file and I didn't want to go back down the path of using a Java-based DOM libraries as I've been there, and it's a mess. Far too heavy in memory and CPU usage. So I looked around and picked Xerces-C as a decent alternative.
Today I was simply trying to create a DOM tree and output it to a file. Simple - right? Wrong. The documentation for doing this should be clear and easy to follow, but it's not. It's just not there. There are plenty of examples for the parsing of an XML file with Xerces-C, but nothing for the creation of a tree. It's just not there.
So I got bits and pieces of the code from here and there, and finally put this together:
// System Includes #include <iostream> #include <ostream> // Third-Party Includes #include <xercesc/dom/DOM.hpp> #include <xercesc/util/XMLString.hpp> #include <xercesc/util/PlatformUtils.hpp> #include <xercesc/framework/LocalFileFormatTarget.hpp> XERCES_CPP_NAMESPACE_USE /* * This method writes out the DOM tree starting at the provided node to the * file specified. This is going to be a pretty optimistic way of writing * out this guy, but it should look nice. */ void printTreeUnderNode(DOMNode *top, char *filename) { DOMImplementation *impl = DOMImplementationRegistry::getDOMImplementation(NULL); DOMWriter *writer = ((DOMImplementationLS*)impl)->createDOMWriter(); // set it so that it looks nice on the output if (writer->canSetFeature(XMLUni::fgDOMWRTFormatPrettyPrint, true)) { writer->setFeature(XMLUni::fgDOMWRTFormatPrettyPrint, true); } LocalFileFormatTarget myFormTarget(filename); writer->writeNode(&myFormTarget, *top); myFormTarget.flush(); writer->release(); } /* * Main entry point */ int main(int argc, char *argv[]) { /* * Xerces-C doesn't play around. You need to set up the environment * so that all the xerces calls can actually work. */ try { // Initialize Xerces infrastructure XMLPlatformUtils::Initialize(); } catch (XMLException &e) { char *message = XMLString::transcode(e.getMessage()); std::cerr << "XML toolkit initialization error: " << message << std::endl; XMLString::release(&message); return 1; } std::cout << "Transcoding the features..." << std::endl; XMLCh tempStr[100]; XMLString::transcode((const char*)"XML 1.0", tempStr, 99); std::cout << "Creating the implementation..." << std::endl; DOMImplementation *impl = DOMImplementationRegistry::getDOMImplementation(tempStr); std::cout << "Creating the document and root..." << std::endl; DOMDocument *doc = impl->createDocument(NULL, XMLString::transcode("root"), NULL); DOMElement *root = doc->getDocumentElement(); std::cout << "Adding an IBM..." << std::endl; DOMElement *ibm = doc->createElement(XMLString::transcode("Instrument")); ibm->setAttribute(XMLString::transcode("symbol"), XMLString::transcode("IBM")); ibm->setAttribute(XMLString::transcode("CUSIP"), XMLString::transcode("123456789")); // now add in the position DOMElement *ibm_pos = doc->createElement(XMLString::transcode("Position")); DOMText *ibm_pos_val = doc->createTextNode(XMLString::transcode("1000")); ibm_pos->appendChild(ibm_pos_val); ibm->appendChild(ibm_pos); // now add in the price DOMElement *ibm_prc = doc->createElement(XMLString::transcode("Price")); DOMText *ibm_prc_val = doc->createTextNode(XMLString::transcode("95.88")); ibm_prc->appendChild(ibm_prc_val); ibm->appendChild(ibm_prc); // finally, add this tree to the root root->appendChild(ibm); std::cout << "Adding an AAPL..." << std::endl; DOMElement *aapl = doc->createElement(XMLString::transcode("Instrument")); aapl->setAttribute(XMLString::transcode("symbol"), XMLString::transcode("AAPL")); aapl->setAttribute(XMLString::transcode("CUSIP"), XMLString::transcode("333444555")); // now add in the position DOMElement *aapl_pos = doc->createElement(XMLString::transcode("Position")); DOMText *aapl_pos_val = doc->createTextNode(XMLString::transcode("-955")); aapl_pos->appendChild(aapl_pos_val); aapl->appendChild(aapl_pos); // now add in the price DOMElement *aapl_prc = doc->createElement(XMLString::transcode("Price")); DOMText *aapl_prc_val = doc->createTextNode(XMLString::transcode("112.80")); aapl_prc->appendChild(aapl_prc_val); aapl->appendChild(aapl_prc); // finally, add this tree to the root root->appendChild(aapl); // write this all out std::cout << "Writing out tree to 'output.xml'..." << std::endl; printTreeUnderNode(doc, "output.xml"); /* * Done with the document, must call release() to release the entire document * resources */ std::cout << "Cleaning everything up..." << std::endl; doc->release(); /* * Now we need to shut down Xerces as we started it up. */ try { XMLPlatformUtils::Terminate(); } catch(XMLException &e) { char *message = XMLString::transcode(e.getMessage()); std::cerr << "XML toolkit teardown error: " << message << std::endl; XMLString::release(&message); } std::cout << "Done" << std::endl; return 0; }
There's a lot of wasted effort here, and the code is far too optimistic to be used in production, but the ideas are clear, and that's what I needed. You have to get pretty low-level with Xerces-C to make up the XML tree. The attributes are tacked onto a node, and then you can make sub-nodes that might have attributes or values themselves. It's pretty easy when you realize the level you're dealing with, it's just going to take a lot of calls to build up the complete tree.
When I build the code for the project, it's clearly going to have to be based on the objects at hand, and not the XML representation. That will be set up once in the generation/output cycle and then all the attributes of the classes will be properly added to the tree, one by one, and then the tree itself will be serialized to the file.
In general, I think I can wrap up all the Xerces-C stuff so that it's hidden from the rest of the implementation and so could, in theory, be changed out. It's pretty low-level, so except for the writing it out, reproducing it shouldn't be that hard.
Today I started looking at the XML tools available to me in C++ as I have a project coming up that is going to need to have XML document creation and accessible from C++. There are certainly several libraries to choose from, but after talking to friends about it (at some length) I think the best thing is to use Xerces-C from the Apache Project.
It seems complete, feature-rich, and as with all Apache projects, it's got to have been hammered on for a long time to make sure there are so few bugs it's as good as fool-proof. There was one issue, however, and that was with the documentation.
In the package for Mac OS X (version 2.7.0, 32-bit) the formatting of the DOxygen comments is not very nice. In fact, after looking at the web pages on the Xerces web site and the docs I downloaded, the difference was two little CSS includes:
<link href="doxygen.css" rel="stylesheet" type="text/css"> <link href="tabs.css" rel="stylesheet" type="text/css">
I was fixing up the HTML files in the doc/ folder, but then realized there were a ton of them and needed an easier solution. So I did a little digging, and noticed that the one CSS file that was properly imported was XercesApi.css in the same directory. So to that file I simply added the two lines:
@import url(doxygen.css); @import url(tabs.css);
With this, and a few other well-placed <br> entries before the <h1> tags, things are looking much better. Now I can build this on my Mac as well as linux and things should be fine. I really needed the docs online, and this does the trick.
I read this article this morning and I have to say that I'm very impressed. To get all the changes and version control from the entire Perl 5 project into Git is clearly a significant body of work. Additionally, I have to say that I'm really pleased that they chose Git, as I did a few months ago, as I believe it's really the future of source control for non-institutional developers.
There's no way a big place is going to allow developers to control their own repositories, but that's really only a small part of all the development that's being done. Several small to medium shops don't want the overhead, and all the open source software is perfectly suited to this tool. I'm glad to have gone through the curve and seen what I needed to do. Don't get me wrong, I'll still have CVS for a long time to come as I don't feel the need to convert off it yet, but it's nice to know could, if I needed to.
In keeping with the digging I've been doing with SQLite3 this morning, I found this link on a web site discussing Objective-C SQLite3 wrappers. I happen to think Gus' work at Flying Meat is really nice, and given that, it's probably a pretty solid piece of code. I like the fact that it complements CoreData in that it deals with the data in the database as just that - data in a database. The object-level abstractions are great for CoreData, but if I have data that I need to store in a database that's not an object representation, for some reason, then I want this kind of access to make it easier to get to.
I'll hang onto this link just in case, as SQLAPI++ doesn't have SQLite3 bindings and I know that I might very well need them sooner or later.
This morning I decided to do a little digging into SQLite3 after thinking about CoreData more and talking to a friend who uses it a lot at his Shop. Interestingly, it's a file-based database system, much like MySQL, but in this case, they update the database only once - at night, and then it's read-only all day long. Because it's a file-based database, it's going to be very fast to get the data out of it. Sure, there will be limitations - like I can't really do foreign keys - yet, but they say they are working on it.
But it's got stored procedures, triggers, and C/C++ extensibility. So there's a lot there to like - considering it's the basis of CoreData. So the engineers at Apple must have seen something in it, and my friend says it's rock-solid and "just works". So I started digging.
The command-line interface, sqlite3 is nice - very similar to other tools in this genre, but I have to say that the output of simple requests like select * from person are a lot nicer in PostgreSQL than SQLite3, but there's a ton of flexibility in the output format in SQLite3, I could just be missing it.
I happened across a neat tool - Base, that is a Mac GUI to SQLite3 databases. It's clean, fast, and at v1.1, it's got a lot of room for improvement. I'm hoping that they add a few things - like preferences for the fonts in the table views, and the ability to re-arrange the columns on the data and SQL output panes. It's got a lot of promise, so I registered it to at least support them in their efforts.
So I'll see what I can do with SQLite3 - I'm thinking there's an app in here waiting for me to write. Not sure yet, but it is nice and fast, and dovetails with CoreData so nicely... it seems a waste to miss this opportunity. Feels right... we'll see what I dig up.
It's been a while since I checked on SubEthaEdit, and this morning I decided to check and see if it's been updated recently. To my surprise, it was up to 3.2.1 - from 3.1 I'd been running for a long time. Turns out there are a ton of changes - and all of them good.
There were a few things that I didn't really like about SubEthaEdit, and the first was the syntax highlighting was slower than I could type. It would look like "normal" text for half a second and then convert to the correct style. Not horrible, but not as fast as BBEdit or MacVim, and those are the two that I use daily. Even the editor in Xcode was faster at the change. Well... with 3.2 (and then 3.2.1) they have improved the syntax highlighting performance significantly.
They have also improved the PHP, Perl, CSS, Javascript, and a few other modes. This is going to be a lot faster. I'm very excited about what they have been doing here. If they only added the ability for me to mark/jump and also navigate by the keyboard and fix the method sorting.
There are a few other things: the scrolling 'jumps' when you get to the bottom of the screen and while this is fine for people that didn't get used to 'vi' or other editors that scrolled one line at a time, it's really distracting for me as I have to refocus on the moved text.
It's getting better, and I'm really happy to support them as they get better, but for now it's not going to supplant BBEdit or MacVim.