Blog Closed

This blog has moved to Github. This page will not be updated and is not open for comments. Please go to the new site for updated content.

Thursday, April 30, 2009

Lost: Daniels Monologue

Did this blow anybody else's mind out of the water last night, or was it just me? Daniels soliloquy last night in the forrest, when he talked about the "Variables" of time and changing the past to affect the future was so...unexpected.

I was expecting things to go as they were laying out: the past was unchangable and the losties were in 1977 not to change things, but to learn about the island and take that knowledge with them (eventually) to the present day. The logical end result would be using this knowledge to "save the world". Not so. Now it seems that their goal is not only to observe and report, but actually to change events so that the planes never crashed, so the various people never died, etc. I wonder how well it's all going to work out.

The universe, as they have pointed out on numerous occasions, is self-correcting. Bringing the losties back to the seventies apparently is the universe's way of correcting for the huge mistake made by the Dharma people in releasing the electromagnetic energy, and thus causing a bunch of people to die who weren't "ready". Previously I had posited that Locke was the only "special" person, and the rest of the Ajira 316 passengers were only there to ensure Locke could return to the island as intended. Now, this doesn't seem to be the case, the rest of the members appear to be special too and are each going to play a unique role in this huge Rube Goldberg device to save the world.

This does raise some new questions from me now:
1) In show-time, they only have about 4 hours to detonate that bomb and stop the events from happening. Once that occurs, they obviously won't just fade away (a la Back To The Future) and resume their lives from where they would have been without it. There's no way that they could just resume normal lives and still have any material left over for a sixth season.
2) A lot of people have met loved ones as a result of the various show events (Swayer/Juliet, Jack/Kate sortof, Kate/Aaron) Kate even suggested that it was crazy that she would never have met the people on the plane. Are these people going to let the past be "undone" like Daniel suggests?

So I'm very much looking forward to the episode next week and then the 2-hr season finale sometime after that. Something tells me that the finale this year is going to be BIG.

Wednesday, April 29, 2009

Small Relocation

As my last post indicates, I'm a family man now. My wife and I are going to be doing all our personal and family-related blogging on a new dedicated family blog. This blog is instead going to be dedicated to my other interests: Wikibooks, Wikimedia, Parrot, Perl, and some of the technical things that I do at work.



The answer, as it turns out, is "yes". Dana and I are pleased to announce that we can haz it sometime around late November. Not sure if it's a boy or a girl yet, but we're 9 weeks along, and it has a heart rate of 162. We've been sort of keeping the news to ourselves until today, when we had our first ultrasound appointment. We thought it best to save the good news until we talked to a doctor and saw a strong heartbeat on the monitor.


Of course, here it is:


Of course I'll be talking about it later, I'm sure I'll be posting updates about the new baby...for the rest of my life. Also, Dana was talking about creating a new blog specifically for the kid, so I'm sure lots of information will end up there.

Friday, April 24, 2009

On the Moose

I've been reading a lot about Moose lately, and I'm thinking it's about time I took it for a spin. The whole Perl world is all aflutter about it, so I'm sure everybody who's ever subscribed to a Perl-related blog has heard about it by now too. I haven't done a lot of coding in Perl recently, most of my stuff at work has been migrated to C# and most of the stuff I've been doing at home has been Parrot-related (C for the guts, PIR for the rest).

It's funny because I originally got into Parrot because of my overbrimming excitement for Perl 6. However, the more I got into Parrot, the less I seemed to be doing in Perl. Quite the irony!

I had been doing a lot of stuff at work with Perl, because it was quick and I could do great work with the database in a fraction of the time it took most other people to do. Then my boss decided that for the sake of standardization and interoperability that I should write my programs in the language that everybody else was using: Visual Basic.NET. Two words: "Hell No". The "upgrade" to VB.NET wasn't an upgrade at all and I basically hosted a little rebellion in order to switch to a language that felt less like building with legos and more like programming a computer. We argued for a good long while. It's amazing how vehement people were getting about wanting C++ instead of C#, especially when so many arguments in that direction were either baseless or blatantly false. Anyway, long story short I've been writing C# at work ever since, and I'm happy with it. I digress.

Prior to my C# work I've never really done a lot of OO programming. In school my work was all either assembly language, C, or MATLAB. Even though MATLAB is very high-level and has good OO support now, it was lousy in the OO arena back when I was in school. I took two courses in Java, one on basic "hello world" programming and one about datastructures+algorithms, but neither of those really dug into what it meant to be OO. I did a lot of my personal coding work in Perl 5, but let's face the fact that Perl 5's OO system is absolutely abysmal and I only ever wrote hideous Perl objects to avoid having to write hideous Exporter boilerplate everywhere and pollute my namespace. I also dabbled in Javascript, although I never really got into any of the OO features of that either, besides using classes as a way to separate unrelated stuff (also, I'm still not convinced that their implementation of classes is completely sane, but that's for a different post).

My work with C# has really taught me the value of OO (and it's also kindled an appreciation for strongly-typed languages). So I'm thinking to myself, what could be better then Perl 5 with a world-class OO system? Actually, the answer to that might just be "Perl 6 with a world-class OO system". So, as soon as I learn enough Moose to become functional with it, I want to start migrating some of my Perl 5 stuff to use it.

I'm looking for a good reference on the topic, preferrably a good book. I'm open to suggestions if anybody knows one, otherwise I'll pick up something from Amazon that looks like it has some decent non-computer-generated reviews.

Thursday, April 23, 2009


Last year I was one of the student coders in the Google Summer of Code program. This year, I'm playing the role of backup mentor. No money involved, but then again I don't do open-source software work for the money.

The student is Daniel Arbelo Arrocha, "darbelo" on IRC, and his project is implementing some big number arithmetic PMCs for Parrot. Parrot currently has a BigInt and a prototype BigNum PMC based on the GNU GMP arbitrary precision arithmetic library. Daniel is taking a different approach and attempting to rewrite them using the IBM Decimal Arithmetic Library, libdecnumber. I don't know enough (yet) to be able to intelliently compare and contrast the two approaches, but I'm sure there is a lot to be learned from this project whether it turns out to be a better or worse implementation then the GMP-based one. He's started a GoogleCode project where his work will be carried out. Since libdecnumber is under the ICU license, and not the Artistic 2.0 license like Parrot uses, the work can't be done in a branch in the Parrot repo like my GC work was last year.

Kevin Tew, "tewk" on IRC, is doing the LLVM project that I mentioned in a few earlier posts. I won't be involved in that project directly (besides being an enthusiastic well-wisher), but I sincerely hope that it too will be successful.

GSOC is going to be awesome this year, and I think that Parrot is going to benefit a lot from these two projects.

Tuesday, April 21, 2009

Parrot of the future

#parrotsketch (the weekly design meeting for Parrot) was quite a productive meeting today. Parrot 1.1 is probably going to be released any minute now, if it hasn't been released yet.

I suggested the idea that we rip out the current JIT system, an idea that I had discussed on this blog and elsewhere previously. Though there was some support, it was generally decided that we shouldn't rip JIT out entirely just yet. I'm not going to argue the point, there are plenty of good reasons why not to (at least, not yet).

We also discussed an idea that chromatic had a while back, and that i've been growing increasingly fond of: rewriting PMCs and OPS files in a small special-purpose language, instead of writing them directly in C. The Parrot build process would convert these files into the various forms they need to be in for compilation: C code for the various "regular" runcores, and JIT code generating thunks for any future JIT cores. One of the biggest problems with our current system in my mind is that currently all ops need to be defined twice: once in ordinary C, and once for the JIT variant (actually, it's more then twice because we need to define a JIT variant for each platform). If we change one and not the other, we have breakage. Such breakage is particularly annoying because the JIT system is so murky and hard to navigate that fixes are slow in developing.

There are a lot of cool things that people would like to do in Parrot over the long term. Obviously there are some things that need to be tackled more immediately: the calling conventions reworks (on which Allison is currently doing a wonderful job), improved encapsulation of various subsystems (including GC ad JIT), replacing IMCC with PIRC, etc. There are also a number of features that need to be implemented from the ground up such as asynchronous IO and the whole security infrastructure. A self-hosting small language for Ops and PMCs is another cool little wishlist item that I hope we as a community decide to pursue.

Friday, April 17, 2009

Parrot JIT extravaganza

A lot of talk about JIT has been going on lately in Parrot world. Tewk submitted a very cool looking proposal to implement an LLVM-based JIT backend. We received another post to the list about libJIT. Here are some of my general Parrot-related thoughts right now:

  1. I don't have a particular preference for using LLVM or libJIT in Parrot. Both have associated pros and cons. Either solution (or even GNU Lightning, which hasn't been mentioned as regularly) would be far superior to what we have now.
  2. Our opcode files are written in a C-like superset, and our JIT system is responsible for providing secondary definitions of them as well. Change an opcode file without changing the corresponding JIT definition, you break JIT. Instead, what we should do is generate the JIT definitions automatically from the opcode definition files. This means that we probably can't write the opcodes in C (unless we can find a good translation engine from arbitrary C code to JIT code emitters). Begs the question: What would be the smallest number of operation primitives we would need in order to implement our various operations in a way that could be translated both to C and JIT definitions at build time?
  3. I took another long look at the Boehm collector today, and I learned something interesting that I did not know previously: The collector allows custom finalization methods to be run on destroyed data objects. This comes with some caveats, not the least of which is that finalizers of reachable objects are not run prior to program termination. This is rectifiable if we maintain a list of PMCs that absolutely must be finalized, and run through that list manually in Parrot_exit. I also don't think there is any guarantee about order-of-destruction when we're calling finalizers, so that can raise some problems for us. In any case, it's definitely doable, and a Boehm-based GC core could probably be a reality for Parrot in the not-to-distant future.

Friday, April 10, 2009

Cool projects at work

I've been doing a lot of coding work at my job lately, which has largely been scratching my programming itch. So much so that I've been pretty non-involved lately in my other programming projects like Parrot and Matrixy. Some background:

The products we make at work are embedded devices that contain a number of separate processing elements. We use a smart modem device that interfaces with the GPS, communications satellite, and GPRS cellphone network for over-the-air (OTA) communication. We have a master processor component that manages the smart modem and interfaces with the sensor network. Then, we have a self-organizing wireless sensor network, which connects through another processing element to the central master. In total each system we ship, depending on configuration, can have anywhere between 1 and 18 separate controllers. Since the controllers come in a variety of makes and models, each needs to be programmed separarely with various firmware, software, and configuration files, often each needing to be loaded and managed through a separate hardware/software programming interface. It's a logistical nightmare to program these units, especially when we need to program--and test--them in bulk. Because of this complexity, there has always been a dream for a single software solution that would manage it all automatically.

That, in a nutshell, is what the tool I've been developing does. I have four primary audiences, each with different (and often conflicting) needs for the software:
  1. Development Engineers. These people need reliable low-level interfaces so they can interact with the unit directly. They also need basic testing facilities to ensure that the unit is operating correctly so they can identify bugs early.
  2. Test Engineers. We're a small company so there is a lot of overlap between the two, but the people doing dedicated testing tend to be distinct from the group doing primary development. These people need logging and monitoring tools, along with data extraction: Important information from the unit cannot be burried in a logfile somewhere, it needs to be extracted and presented in a clear way. When there is a problem or even a small incongruity, the testers need to be made aware of it immediately.
  3. Manufacturing Engineers. These people need to be able to program and configure the units quickly, with a minimum amount of spent time and effort. They also need to be able to run quick and easy canned sanity tests to identify potential problems early in the manufacturing process. Since a majority of our assembly personel will eventually consist of unskilled manual laborers, it's imperative that the programming and testing interfaces be user-friendly and mostly automated.
  4. Field Engineers. These are the people who are responsible for travelling across the country and welding our units onto the top of a train car. These people need monitoring and sanity testing capabilities, along with basic diagnostic and repair functionality. The field engineers are not all employees of our company, so they can't all be assumed to have prior training on anything we send them.
I've got a lot of automation in my program, as should be evidenced from some of the audience requirements above. Yesterday I migrated the whole program to a new unified concurrency scheduler to facilitate it all. It sounds a little bit more grandiose then it currently is: it's a basic queue structure attached to a high-granularity timer. Previously, all individual subsystems handled their own asynchronous behavior, which lead to a few different and incompatible systems.

I'm trying to relentlessly follow some of the Agile Programming lessons I've learned, especially from chromatic and the Parrot project. I refactor and improve relentlessly, I cut regular releases every 2-4 days (I only work on the program part-time, and some days I am so busy with other high-priority projects that I don't have time to cut the release), and solicit lots of feedback and bug reports from the people who are using the software. So far, I think the results have been pretty impressive and I've gotten a lot of compliments not only on the quality of the software but also on the rapidity that I've been developing it.

There are a few parts of the Agile method that I don't partake in. For instance, there is no pair programming, which makes sense when you consider that the entire development team is me. I do, however, interact in a very high-bandwidth face-to-face way with the program end users, so that helps. I also don't do a lot of unit testing, I simply haven't found a good way yet to do that in this particular application (I'm also a bit of a testing n00b, so maybe I just am not creative enough to find a good way to do the testing). All told however, I think I am definitely an Agile programmer now, and the benefits of the system to me are very apparent.

Wednesday, April 8, 2009

Microsoft Outlook

I have simply never used a program that was so lousy or buggy as Microsoft Outlook. I'm not a big email guy, I use Gmail for all my personal stuff and only use Outlook at work because our server prevents me from gaining POP3 access to it for unification into Gmail.

Also, as I've said before, I'm not anti-Microsoft. I use Vista at work and like it reasonably well. I use other Microsoft Office products that I enjoy (except Groove, which I've discussed before on this blog). All my coding work recently has been done in various Visual Studio IDEs (Visual C#, Visual C++, Visual Web Developer and Visual Basic), which I like very much. To put into perspective, I hated code completion features that I had used in the past, but I learned to love them with Visual Studio.

But Outlook is terrible. For professional, pay-to-use software, it's miserable. If I could find an alternative that did what I needed it to do, I would switch in a heartbeat and light the installation CD on fire so I couldn't ever use it again. Not a day goes by where the software doesn't hang, or freeze, or stall. Some days it crashes in the middle of an operation, and the program just disappears. Other days, it freezes up and I can't make it go away at all. It is a terrible hog of my internet bandwidth, and slows down all the other programs on my computer in a significant and noticable way when it is connecting or interacting with the server.

Today, it helpfully told me that all my emails were overdue. I didn't even know any of them had due dates, much less that they were expiring. I've never gotten this message before, and suddenly all thousand items in my inbox need my immediate attention. So I click "Dismiss All" to make the stupid message go away. This was a mistake, apparently, since now the program is locked up and completely unresponsive while it traverses it's database dismissing all my apparently-overdue emails.

I click the red 'X', and nothing happens. So I click it again, and a dialog pops up to tell me that the program is unresponsive, and asks if I would like to close it. As I move my mouse to click "OK", the dialog disappears. The dialog disappears, the titlebar loses the "(Not Responding)" tag, the window which had been a faded white color to show that it was unresponsive suddenly lights up. In short, a few things happen that make me think that the program is responding again. Not so, as my next click does nothing, and the click after that makes the program unresponsive again.

Every day when I connect to the server, it asks me for my email address and password. I provide both, and click the box "Remember me". Every day, it doesn't remember. Why even have the checkbox there if it doesn't do anything?

Not a day goes by when I don't have some kind of problem with this software, and I hate it so much. It is, without a doubt, the absolute worst part of my job.