What's it all about, Alfie?

It seems that the auditing of a new IRC server at The Shop is too much to think of adding at this point - given that they have an existing XMPP/Jabber system that's up and running and working just fine. So rather than mess with using the IRC stuff I've used in the past, it looks like I'm off into the world of XMPP and Jabber. Thankfully, there seems to be more client libraries than you can shake a stick at. Including C++.

The one I'm looking at initially is called gloox, and looks to be a reasonable well done library, but I haven't even tried to build it - let alone use it. Still, it looks reasonably well defined and designed, and I'll need to get it, read through the code to see how it's commented and built. If it looks good, I'll use it until it doesn't work. I'll be certain to isolate it nicely so that should I need to replace it, it'll be easy enough to do later.

Still... it looks promising and it means that I don't have to hassle with implementing a new chat protocol. But it might have been nice... I'll never know.

I was trying to get some decent fonts going in CentOS GNOME, and I followed the obvious steps to get one of my favorites working:

  $ cd
  $ mkdir .fonts
  $ cd .fonts
  $ wget http://www.levien.com/type/myfonts/Inconsolata.otf
  $ cd
  $ fc-cache ~/.fonts

and then verify that the font is properly installed:

  $ fc-list | grep consol
  Inconsolata:style=Medium

but then we need to kill all GNOME Terminal sessions. This was something that I messed with for about 30 mins before I figured it out. You have to drop all the existing terminal sessions - every one, and then when you start it up, you'll be able to see the new font.

Holy Cow! That was an enormous pain in the rump to figure out. But hey, now that I have it, I know it, and we're not going to be bitten by it again.

This morning at The Shop I was installing NoMachine on a CentOS 5 server and an XP Client. The client was fine, but I kept getting SSH errors about Authentication failed. I looked at the NoMachine web site, and their knowledge base recommendation was to make sure the permissions on the ~/.ssh/config file were set properly.

Did that, didn't work.

I then stumbled onto the key to the problem: the nxserver wasn't really running. When I found this article, I saw that I had a way to check and see if it was really running:

  $ sudo /usr/NX/bin/nxserver --status

and if all is going well, we'll see something like:

  $ sudo /usr/NX/bin/nxserver --status 
  NX> 900 Connecting to server ...
  NX> 110 NX Server is running.
  NX> 999 Bye.

but if there's a problem - like I had, it'll look like this:

  $ sudo /usr/NX/bin/nxserver --status 
  NX> 900 Connecting to server ... 
  NX> 204 Authentication to NX server failed. 
  NX> 110 NX Server is stopped. 
  NX> 999 Bye.

OK... we now have a way to prove it's the server without including the client. Progress. Unfortunately, the solution was very difficult to find. Forget the knowledge base... that didn't help. Turns out, several of the guys here did figure this out in the past, but have since forgotten the exact solution.

So they had to play around. So they played.

The solution was in the user nx that's installed with the RPMs. This guy doesn't have the proper groups, so we had to manually add him to the localssh group:

  localssh:x:500:dbususer,...,nx

where the key is that the nx user be added (with a comma separator) on the end of the line. Save that, restart sshd with:

  $ sudo /etc/init.d/sshd restart

and you're ready to go. You just need to restart the NX Server:

  $ sudo /etc/init.d/nxserver stop
  $ sudo /etc/init.d/nxserver start

then:

  $ sudo /usr/NX/bin/nxserver --status 
  NX> 900 Connecting to server ...
  NX> 110 NX Server is running.
  NX> 999 Bye.

works just fine.

Whew! That was a ton of work to find the three characters to type into the right fine to get it to work.

There have been a few widely publicized security holes in Flash in the last week, and it seems Adobe has responded to them with a new version of the player. Good enough. This one is still not the guy that uses the hardware acceleration on the Mac, but that's coming, and soon enough it'll be a decent player for the Mac. For now, I can rest a little easy knowing that it's at least not a security risk. That's something.

This morning I read this on Slashdot about the new features coming in PostgreSQL 9.0. I have to say, it's really quite impressive. I remember when I was researching an open source database for the work I was starting to do at First Chicago, and still think I made the right decision all these years later. It's just an amazing database.

The features it has, and the comparisons it's making - to say it's more like Oracle and beats SQL Server 2003/2008 is pretty darn impressive. I have to say that I'm glad The Shop is using it as an alternative to either of these - it's just a nice tool to work with.

I'll have to wait and see when KyngChaos gets the build up for Mac OS X that I've taken to using. It's a good package he's putting together.

My old favorite, Cyberduck, has jut released a new version - 3.5, and I did a quick glance at it to see what had changed that might make me come back to this old favorite. Seems the big thing is adding the Google Docs storage which includes OCR. That's interesting, but I'm not exactly sure how OCR fits into a file transfer app... seems like a bit of a stretch, but I'm willing to let them go there.

The addition of Google Docs storage is nice in that Amazon S3 has been out there for quite a while, and this evens the bar, but I haven't done a lot with either, so it's OK for now. But it's nice to know that it's there, if I need it.

This morning I noticed that Google Chrome (dev) 6.0.427.0 for the Mac is out and did a quick update to get the latest version. I haven't heard what this new version brings, but I did hear that Google was trying a little harder to get WebM, their video codec, into the open/standards realm so that they could counter the claims of Apple about WebM vs. H.264. I'm not that big into this, but the arguments heating up between Apple and Google are very interesting to watch.

I was looking at github this afternoon for examples of Clojure apps to see how they were using the language, and what problems they were solving. It's something that I find useful now that I'm half-way through Programming in Clojure from Pragmatic Programmers. It's a nice book, and while I'm not really thrilled with the order of topics, I think the second time through I'll pick up a lot more. But it's going to take a second trip through all this for a non-Lisp developer like myself.

Anyway, I was looking and saw that one of the most watched projects was a build system for clojure called Leiningen. Odd name, and they talk about it in the README, and I like their concise project.clj file:

(defproject leiningen "0.5.0-SNAPSHOT"
  :description "A build tool designed not to set your hair on fire."
  :url "http://github.com/technomancy/leiningen"
  :dependencies [[org.clojure/clojure "1.1.0"]
                 [org.clojure/clojure-contrib "1.1.0"]
                 [ant/ant-launcher "1.6.2"]
                 [org.apache.maven/maven-ant-tasks "2.0.10"]]
  :dev-dependencies [[org.clojure/swank-clojure "1.2.1"]])

The question that first came to my mind was Why? I mean, I understand the need for a build system - but with Make and Ant and a hundred other lesser-used build systems, it's amazing to me that someone took the time to actually go and create another. So I started to dig into the code and I think it's helped me realize the place clojure has in the spectrum of software development languages.

When I first started reading about clojure, I was thinking it was a lot like Smalltalk - or Lisp, where you have a 'workarea' or 'sandbox', and you spend a lot of time essentially augmenting the language or environment - making it more powerful, more complete, more customized to your way of doing things. In the end, you have a place to do the things you need very efficiently and without loading up a ton of libraries, etc.

It's entirely different if you're writing Java code, for instance.

So... what's Leiningen all about?

I dug in and saw that it's got links into github - and now it starts to make sense. If you wanted to incorporate apt get or yum with a "sandbox" and custom code, you could... but it'd be platform-dependent. And you could only pull pre-built projects from the sources you had in your package manager.

It appears that Leiningen is a package puller in addition to a code compiler, and even a code pusher. It's tightly integrated with github, and that's not bad, it's just exclusive. But if I want to get something you've written in clojure, and we all use github for our code, then this is an interesting solution.

I can pull your code from github, use Leiningen to build it, and it'll pull in any needed projects that I don't already have from github and make sure they are properly integrated into my sandbox. You don't have to package everything in your project, and I don't have to mess with getting your dependencies - or even what they are! I can use pull it from github, build it and use it.

That's pretty impressive, I've got to admit.

But I'm not sure it's what I'd call a "build system" - it's more than that, and it's not going to really help you a ton if you're starting to work on something and want to put it on github for the first time. I'm going to have to get the code I need, or at least identify it - including the version of each, and then build the project.clj file. But at that point, I've already built my project. This helps you use my work, but not really me build it.

I think it's worth watching, as it might become more of what I'm thinking about, but in general, this looks to be a great tool when posting your code to github, but before that - or if it's not on github, it's not as useful.

But it does shed light on who uses clojure and how they use it.

I've been doing a little searching today looking for some lockless data structures for C++ because I'm expecting to have to do quite a bit of coding for the new market data (ticker plants) work that should be coming up pretty soon, and I thought it'd be nice to see if there was something that was going to give me a nice leg up as opposed to sticking with traditional locks.

The problem is that the state of the C++ support for this is pretty limited. In fact, there's going to be support for std::atomic<> for elemental data types and even regular C structures. There's no support for the STL classes, but that's a reasonable limitation. The problem is that this is not really the same as having std::map<> and such as lockless structures, but there's no support in the standard (yet) planned, and even Boost doesn't have anything - yet.

It's kind of depressing, as I expected to see some kind of lockless data structures because the Java Concurrent package has been around for quite a while and I would have just assumed someone would have taken the code for that package and converted it to C++. But I was wrong. Shucks.

No matter, I can still make it work, I was just had hoped to see something a little more...

Today I was telling a friend on chat that I like the idea of mutable objects. It's how I think about programming. I realize that immutability is all the rage with Clojure and Erlang, but it's not how my mind thinks - at least not yet. So I was saying that what I wanted was someone to implement the atomic compare/replace needed for lockless data structures in ObjC. Well... I had a few minutes while digesting the ordering of set elements in Clojure, and decided to google lockless data structures for ObjC - lo and behold, there's a podcast with Mike Ash on exactly this topic.

I haven't listened to it (yet), it's still downloading, but I'm going to listen and see if in the latest developer tools there is support for the lockless data structures. If so, what a lucky break! It would certainly make things a lot easier for me when I get to that level of coding.

[6/9] UPDATE: I found TransactionKit on the web, and it's got a partially done implementation of NSDictionary and NSMutableDictionary. His warnings are nice, but it leaves me with the impression that I shouldn't really trust this. It looks nice, but I need to do a lot more reading on it, and looking at the code before I'm convinced. The problem is that I also need an NSArray equivalent. We'll have to see when I get around to it.

As a note, the description of TransactionKit by it's author is here, and it's a pretty significant piece of code. Not at all what I had anticipated in my initial thoughts. In fact, it sounds pretty amazing, but he warns us all:

There's also almost certainly bugs here and there, so the idea of unwinding stack frames by hand and being able to almost reflexively spot pointers to stack variables, and which threads stack it refers to should be second nature to you. When things go wrong, they will go wrong in a stunningly complex way.

Also, Apple has done a reasonably good job of implementing a LIFO queue with OSAtomicEnqueue() and OSAtomicDequeue(), which are in the man pages. The man page even gives a nice example of putting it to use - the only problem is that you need to drop into C structs to hold the data so it's not likely to be used in a simple Cocoa implementation.

Additionally, Mike Ash (in the podcast) talks about how the atomic increment is about 10x slower than the simple ++i implementation, but it's far, far faster than the lock, increment and unlock. Makes sense, but again, it goes to Apple's comments on threading - make code that doesn't need to use lockless data structures and you're even better off. Good to know.