Archive for the ‘Open Source Software’ Category

Throwing my Name into the Hat for a Good Project

Wednesday, January 21st, 2009

xcode.jpg

I was reading the RSS feeds the other day and came across this in my reading. It was a "call to arms" for an open source Mac OS X plotting framework. Something I've always wished there were, but nothing seems quite right.

So I decided today to shut up and do it. So I sent Drew my name and a brief description of what I was looking for, and explicit instructions about what he wanted me to do. I'm no fool - one chief, lots of braves. I'm a brave on this guy.

That's OK. If I can get this to a point that it does all I need from VantagePoint or DataGraph and it's something I understand and can work with, then that's fantastic. It's certainly something to get involved in and see if I can make it better.

I'm hoping this turns out to be a good thing to do. I think it is.

MacVim Snapshot 42 – Emergency Fix

Tuesday, January 13th, 2009

MacVim.jpg

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.

MacVim Snapshot 41 is Out

Sunday, January 11th, 2009

MacVim.jpg

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.

Cyberduck 3.1 is Out

Friday, January 9th, 2009

Cyberduck.jpg

I noticed this morning that Cyberduck 3.1 was released with several nice additions: Cloud Files, Amazon CloudFront S3 support, better defaults for MobileMe (WebDAV), new icons in the site list, and lots of other stuff.

I don't use it a ton, but it's a nice, clean app that's a breeze to use. Great tool to have when you need it.

Interesting Developments in Gimp on OS X

Thursday, January 8th, 2009

Gimp.jpg

I was looking at the latest from Gimp for OS X this morning and I realized that it requires an updated X11 install for OS X. While I might not mind that, I just ordered a new box, and with Snow Leopard on the way it's just not something I'm going to hassle with and put my box in an odd state over.

So I went back to the GIMP.app site which has the native port of Gimp for OS X. This is interesting to me because I think that the native port beats the X11 one because it fits in better with the rest of the applications on the box. Not that I have anything against X11 - it's just that if I had a choice, I'd go native.

Well... with the move by the Gimp on OS X folks to use the non-standard X11, the native port is getting my attention. While it's on 2.6.0 and the other is 2.6.4 (the most recent stable cut), there's a lot that can be done in 2.6.0, and it actually runs on my box without the new X11 libraries.

I'm wondering if the GIMP.app guys have given up, but if that's the case, then the only long-term way to get Gimp on OS X is to use the non-standard X11. Maybe they'll go back to the 'standard' one with Snow Leopard, but if they diverged once, they'll do it again. We'll just have to wait and see.

For now, the GIMP.app runs just fine on 10.5.6. I can do all the things I need to do and while that's not much (I use Acorn much more these days) it's nice to know it's there if I need it. Also... it's less than half the size of the X11 port. Wow! that's a big difference.

Nice Git Repo Tool for Mac OS X – GitX

Wednesday, January 7th, 2009

GitX.jpg

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:

GitX - xercesFun

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.

Working with Xerces-C – Examples are Hard to Find

Tuesday, January 6th, 2009

cplusplus.jpg

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.

Perl 5 Moves to Git – Impressive Change

Monday, January 5th, 2009

gitLogo_vert.gif

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.

Interesting SQLite3 Wrapper from Gus Mueller

Wednesday, December 31st, 2008

SQLite3.gif

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.

Fun with SQLite3 and Base v1.1

Wednesday, December 31st, 2008

Base.jpg

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.