What's it all about, Alfie?

This morning I noticed a somewhat minor update to Google Chrome dev to 20.0.1115.1. The release notes only say that there are "fixes" and an update for the V8 javascript engine to 3.10.5.0. Still, it's nice to see that it's making progress still as I'm thinking about a web project to keep me occupied while I'm off. I still need to finish the iOS/OS X library I'm working on, but after that, possibly a little more web stuff? Who knows.

I was reading a little from the newsgroups today and decided to have a look at the latest from the HPC on Mac OS X to see if they had an updated gfortran for OS X 10.7 - and indeed they did. I downloaded the package, updated my removal script and then installed the latest version. I then rebuilt my thesis code with it, and was happy to see that it all still worked.

Not that I didn't think it would, but it's nice that it still works.

I'm not sure what I was planning, but I have to admit that it might be really nice to get back into FORTRAN and just write code. But that's the same with C++, isn't it? I just want to write code. Not really mess with GUIs… not mess with people, and politics, and all the cruft that comes from dealing with people -- I just want to write code again.

Maybe I'll dig into my thesis and try to see where the convergence issues really are. I know they are there, but I'm not sure that FORTRAN is the best language to find them. Maybe Obj-C might be nice. It's certainly got all the functionality I'd need, and it'd be nice to be able to have the physics in modules, but we'll have to think about it a bit.

This morning I noticed a minor milestone for Google Chrome dev - the 20.x.x.x series is out with 20.0.1096.1. There is a new V8 javascript engine, and a few more nice things in the release notes, but it's interesting that since I've been looking, I haven't done a lot of writing, and noes Chrome 20 is out. Kinda wild.

This evening I decided I wanted to get out of the house a little, so I went with Liza to the Naperville North Women's Lacrosse Board Meeting and sat at a little table for two in the corner and did a bit of coding. I can see why Wil Shipley and so many others do the exact same thing. It's so nice to have a simple little break from the home office where I've been hammering on this same problem for quite a while. Just the change of scene… the different background music… the different table and surroundings - all makes for a really wonderful experience.

Now I don't think I'd do this over the home office, but it's certainly nice to have the change of scene. If I went indie, I'd be doing this a few times a week. Maybe Starbucks, Panera, and other similar places would be where I spent my afternoons. Hard to say, but it's a lot of fun. I can see myself doing a lot more coding here if Liza's going to stay on this board.

Very nice change of pace.

And I got a lot of coding done too!

When putting work up on GitHub, it really pays to have a nice Markdown previewer or editor for building your README.md file as it's the first thing a new user sees when coming to your project page on GitHub. You want to make a nice impression on the user, have good introductory docs, and even the license on the project, and all this is going to be rendered in Markdown - at least GitHub's version of Markdown.

When I was initially doing this, I was using BBEdit, and while it had a preview that worked with Markdown, it didn't support the GitHub CSS that it was going to be rendered in, and it still required that I edit the file, check it in, push it up to GitHub, and then I could see if I liked what it looked like. Not a great workflow, really.

So this morning I was on the hunt for a decent Markdown editor for Mac OS X. I knew there were several available in the Mac App Store, so I was willing to buy one, but I wanted to search the web first, to see what the opinions were out there of the best one to get. I've seen several, and there are two that seemed likely candidates, and I decided to try one, but I'm not really sure that it's what I am looking for. Still, it appears to be a lot closer to what I'm looking for than what I'm doing now.

Mou is a free app that does a split-pane view of source and rendered text. The position of the split pane isn't really resizable like a lot of Mac apps, but it is moveable in the sense that it can be moved by some menu commands to change the split from 1:1 to 1:2 or 2:1, and such. It's not ideal, but it's free. It's certainly a very nice start in the right direction as it currently support GitHub flavored Markdown.

BBEdit can work with Markdown, and even preview it, but it doesn't really use the GitHub style for the preview, and try as I might, I was totally unable to get some CSS file for BBEdit's preview that would work. There were perl and PHP versions, but that's far too much, and the Mac App would then be far better.

The problems with Mou are that it's taking up a ton of space on the screen. There's another application called Valletta 1.0, and it's got a unique take on the two-pane system: it keeps it all in one by having the line with the cursor in input mode and the rest of the document in display mode. This is a good idea, but if you're moving between different sized text, you're going to be having your text move all over the place. What I want is a great preview.

Mou does the preview good enough, and it's got a simple editor built in. Not bad for free. There's another app that does just the previewing, and it's on the Mac App Store for $4 - Marked. I might end up going for this as it's exactly what I'm looking for. I can edit in BBEdit all I want, and then preview in a good GitHub renderer and then check it in and push it all up to GitHub.

[4/10] UPDATE: I ended up getting Marked from the Mac App Store. They updated it to 1.4, and included the color syntax highlighting on GitHub. It's exactly what I'm looking for. $4 well spent. I can edit it in BBEdit, save, and it's automatically updated in Marked. Very nice indeed.

This morning I noticed that Google Chrome dev 19.0.1077.3 was out with a few little updates and a few known Mac issues. Interestingly, the new V8 javascript engine is there, but there are a few incorrectly drawn icons in the Mac version. Odd little combination of changes, but I'm guessing it's a merge that needs to be done, and then things will clear up. There's also a fix for the Flash plug-in, but it's going to be interesting to see what becomes of Flash now that Adobe is all but giving up on it. Google may go back to HTML5 and the more widely supported codecs. Hard to say.

Well… today has been an interesting day for one open source project that I've been working with for about the last year or so - ZeroMQ. Today I learned that two of the key developers in the group have "jumped ship" and forked the codebase, and are calling themselves Crossroads I/O. Their project, libxs, is really just a fork of the ZeroMQ code, and they are off to the races with a new Open Source company/project, and without the backing and support of a lot of the ZeroMQ community.

Today in IRC, it was a real surprise to hear Pieter talking about all the grief that was hidden from me, at least, in 2011. Trying to keep the group together was his job - and in the end, he realized that it just wasn't possible. So away Mato and Martin went, and the group is now light those two major developers.

I look at this with a lot of curiosity. When they had 2.1.x, it was good, decent, and while not perfect, it could have used a lot of improvement. Rather than do that, they started a 3.0 branch, with a completely different API, and all of a sudden, the upgrade path to me wasn't clear. I didn't mind it so much as we were moving away from it as the delivery transport in the project, but it still bothered me that they wanted to have a new API and a re-write of large sections of the code so soon after they just got 2.x out the door.

Dynamic and flamboyant individuals are nice to really move a project, but I can see that they can also be the worst liability to a project like ZeroMQ, as well. If they want to take the project in directions that the majority of users don't want, then they are going to make the project appear to be run by lunatics. But without them, you may face the problem that fixing the bugs they made are near to impossible in any reasonable timeframe.

So on the whole, I hope things work out for ZeroMQ, I really do. I think it's got a good idea that needs a little work to make it a really robust and reliable messaging system. But it's going to need to attract a few key, strong, developers to make it work.

Since I've been looking for a job, I haven't been doing a lot of posting because not a lot has been happening - except all the stuff associated with getting a new job. But one of the things I wanted to do this time around was to create a GitHub project that could showcase a little bit of my coding skills as well as being generally useful for folks - me included, and just get something out there. So I created DKit.

The idea behind DKit is simple - it's a very specialized C++ library with classes and templates, that contains atomic and lockless data structures for very efficient C++ coding. I've used classes like these in projects at previous employers, but I started fresh, and expanded the classes significantly so that the atomic integers paralleled those in the stdint.h header - signed and unsigned, 8, 16, 32, and 64 bit sizes. These will make counters trivial as they are all atomic and so you'll get great counts even if you don't go through the overhead of locking.

I also added in two groups of containers, so far: single-producer/single-consumer, and multiple-producer/single-consumer. To the first, I put in a simple circular FIFO, and to the latter I put in a linked FIFO and a circular FIFO. These were ideas I had at a previous job, but I wanted to make them fresh so as not to get into any IP issues.

All told, it's a nice start. I want to keep it free of the issues that I might have had in the past, and just keep it OPen Source. I picked the MIT license as it seems to be the most liberal while protecting the original copyright and the removal of any liability. I think it's the start of something really nice.

This morning a good friend messaged me about something I might want to keep in mind as I do more massively parallel projects in the future, and that's a C++ library that fits in will with the STL, and is written by a couple of engineers at NVIDIA - Thrust. This looks very interesting.

The idea is that with the CUDA nvcc compiler, and a little pre-processing and some templates, they have made the STL std::vector equivalent for GPU/CPU usage. You can say where you want this vector to be held, and then process a functor on it to get things done very quickly. It's not as clean as OpenCL, in my opinion, but it's far more likely to be used as throwing NVIDIA cards into boxes - even server boxes, and using GCC/nvcc is a lot more likely in the typical business use-case.

Macs still aren't getting significant penetration there, but it's getting better.

So this is something to keep in mind, for sure. Thankfully, it'll run on Macs as well - so I just need to get a Mac Pro with NVIDIA card(s) and then I can start playing with it. Sweet.

This morning, sometime, I noticed that Google Chrome dev 19.0.1068.0 was released and the release notes seem focused on the Android stack and a few side things, but I guess not every release can come up with a new way of doing things, or a massive speed improvement. But progress is progress.