Tuesday, December 01, 2009

doxygen weirdness

Spent most of my day getting Doxygen working with Visual Studio 2008. Finally happy with the output after lots of fiddling and trial-and-error. Now my API documentation is getting generated every time I do a build (and tested with UnitTest++).

Some oddities I had to deal with:
  • doxygen doesn't report an error if you've got \msc in your docs, just silently puts a invalid image reference into the HTML. Doesn't seem to actually try to do anything with the \msc command unless you set MSCGEN_PATH
  • I've got doxygen/dot/mscgen checked-in to subversion relative to my project's source code. Running doxygen from a Visual Studio post-build step, and decided to wrap it with a batch script. At least on windows, doxygen seems to have trouble reading an environment variable to set DOT_PATH / MSCGEN_PATH. Seems like it expands the env variable just fine, but it reports an error saying it can't find dot. Ended up just putting the relative path into the config file. Annoying since now I can't share the config file w/ multiple projects at different levels of the tree... but hey, free-ish UML sequence diagrams via mscgen.
  • If I enable HAVE_DOT, lots of unhelpful error messages whenever it tries to run dot. A little googling turned up the problem -- doxygen tries to avoid re-doing some work if it thinks it doesn't have to regenerate some files. Not sure why it isn't working, but you can work-around the problem by creating a pre-build step that deletes the document-output directory.
When I wasn't messing with Doxygen, I was waiting in line at the DMV to renew my driver's license. Whee.

Monday, November 30, 2009

mingw vs. cygwin -- mingw fail

Cygwin has its warts. But, at least it has a single installer.

There's documentation on the MinGW site with install instructions. Many, many pages w/ seemingly contradictory information. And then you've got to navigate SourceForge's horrible file download interface. Ick.


Wednesday, November 18, 2009

quit stealing my bits

The new job is going well. Working closely with a couple other developers to design and implement some functionality for our new system.

The bad part is... we all have very similar personalities and development styles. All of us are tending to get caught up in the 'big picture' and losing sight of the functionality we need to implement in the near-term. Looooooong conversations about the N number of ways we could do X, Y, or Z.

We need the big picture view to plan the total functionality we need, and to schedule the resources we'll need. But, none of us are being very decisive about limiting the options we have to choose from.
Scarily, I'm probably the least introverted of us -- and, since I'm the 'new guy' I have fewer responsibilities -- so I'm the one writing documents, drawing diagrams, and giving presentations.

In many good ways, I've had to leave my comfort zone. But, today in particular it became clear I'm going to have to be the one to keep us on task and moving forward.

Stupid shoes on other feets.

Monday, November 02, 2009

dependency repository for visual studio / nant / msbuild / whatever

Dear LazyWeb,

For Java builds, you've got both Ivy and Maven as mechanisms to publish / discover inter-project dependencies.

Are there similar tools for C# or C++? Particularly within Visual Studio?

Googling has turned up vague hints about running Ivy from within a NAnt script. And a Visual Studio Dependency Manager on Codeplex that sounds like it might fit the bill, but doesn't have much documentation to judge.

We've got a bunch of thirdparty dependencies, as well as inhouse dependencies -- individual projects might change multiple times a day, or only every year. It'd be nice to have a Ivy-like repository that we can publish new releases into.

Ideally I'd like something integrated with Visual Studio to make our developers happy, as well as something easily scriptable/controllable to make our CM people happy.

Monday, October 26, 2009

argh

I was playing around with some python code a couple months ago. Nothing that special, just a few hours work figuring out how to parse some text files. Nothing too elaborate, but I remember being particularly pleased with one or two pieces of it.

Finally getting back to it tonight and it's nowhere to be found... I've found tons of unrelated crap I saved off and will never use again. The time I'm not anal about putting some experiments into version control is also the time I deleted it without realizing it.

I think it must have also been when I was fiddling with eclipse+pydev+IronPython, and I hadn't bothered to change the project's path from the default place in the default Eclipse workspace. Normally I always change one or both of those...

Sometime in the last few weeks I must have done my usual iteration of "eclipse is acting a little wonky, time to delete it and re-install it and all my usual plugins. Oh, and this workspace directory I never use."

Argh.

I also distinctly remember thinking that I should make a blog post of some of the code. Didn't happen.

Double argh.

Thursday, October 22, 2009

gentlemen broncos

Saw Gentlemen Broncos tonight at a screening.

Yup. I've got the inside track on the Hollywood big time. My friends dog is in the film. The dog has bit me on the bum. I'm not sure how many degrees away that now makes me from Kevin Bacon.
Update: My buttocks are 4 degrees away from Kevin Bacon


Tuesday, October 06, 2009

fall 2009 status

  • dog still good. Other than chomping on the neighbor's cat.
  • new job still good. Fixed a long-outstanding bug in the code. Waiting to get more bugs to work on, and in the meantime working on a new tool to help ease our transition from ClearCase to Subversion. Getting to play in python most of the day, good times.
  • Best book I've read lately: Soon I Will Be Invincible, by Austin Grossman.
  • Best audiobook I've listened to lately: How to Succeed in Evil, by Patrick McLean
Odd that both the book and the audiobook are superhero satire/homage.

Currently reading: Matter, by Iain M. Banks

Tuesday, September 08, 2009

things learned on my first day at the new job

  • eclipse is positively snappy on a 8-core workstation
  • lotus notes still exists
  • there is such thing as too big a monitor. So far, not liking the ginormous widescreen. Would much rather have 2 or more 19"-20" monitors.

Monday, September 07, 2009

good presentation on TDD

http://www.infoq.com/presentations/tdd-ten-years-later

daemon

Just finished Daemon by Daniel Suarez. Very good, devoured it in a day this weekend. Not sure if I liked how it ended -- very clearly setting up the sequel, which isn't due until 2010.

Sunday, September 06, 2009

Saturday, July 25, 2009

losing my geek cred

Finding pydev + eclipse a decent IDE for playing around with python. That place in my heart used to be held by Vim.

The very new IronPython integration in pydev is surprisingly functional.

interesting dynamic languages on .net talk from 2008

Tuesday, July 21, 2009

argh

why did it take 10+ years for us to realize our round-to-nearest-100th algorithm is busted (on windows)?

Not sure why the original developer cast to 'long' rather than using some modulo division on the floating point number. Stupid windows 32bit long.

And, we can't do the easy solution of 'long long' because of incompatibility with the HP-UX C-runtime on the old-as-dirt patch levels some of our customers refuse to move from.

Saturday, July 18, 2009

why I love python

Lately, discussions at the NFJS conference and recent conversations with friends have made me introspective about why I like Python.

I first started using Python about 9 years ago. Previously, I'd used mostly C, C++, Perl, Pascal, and a very little bit of Visual Basic.

Pascal was what I'd learned in High School. VB, C, and C++ were what I'd used during college (I guess there was a teeeeny bit of Lisp thrown in there too). My first couple years as a software engineer, C++ was the hammer with which I'd pounded all programming nails.

Eventually I learned Perl. It was OK. But, like most people, I'd write Perl scripts and not be able to read them the next month.

After a recomendation I'd read online, I tried the Python tutorial. The conciseness was a revelation. The way it got out of my way and let me worry about the problem and not the compile/run/debug loop. Having dictionaries and lists as a first-class language features blew me away. I don't know why similar features in Perl never struck me in the same way.

Learning Python not only completely reinvigorated my interest in programming, but it also and completely changed the way I program. Maybe I still love Python because of the sentimental attachment to it from that first revelatory period of experimentation.

no fluff just stuff SLC 2009

It was pretty good. Only went to one session that was a dud. Decided to try to go to a number of different speakers in an attempt to not get burnt out. But, I should have just stuck with all of Venkat Subramanian's sessions the first day's afternoon. He's an awesome speaker.

I enjoyed seeing other dynamic languages -- groovy, scala, clojure. Definitely seems like mixing in Groovy to any java project would be pretty easy. Loved that it removed a lot of Java's verbosity, but kept the barrier of entry low. Groovy also seemed to be much more readable than clojure or scala.

Scala seemed very interesting -- liked the type inference, and concurrency support. But, I hate hate hate the underscore. And that g-damn colon that changed the operator/operand. Maybe if I used it every day, it'd seem more readable.

I guess if people can hate Python's significant whitespace (which I love), I can have an irrational hatred of Scala's underscores/colons.

Monday, July 13, 2009

further adventures in horrible code -- effin assert

Lots of assert() checks spread throughout our code, testing perfectly valid error conditions. Used sparingly, testing things that absolutely could not happen... ok. But checking for NULL values passed as parameters to various type comparison functions? Eeesh.

It's caused problems up a couple times before... but last Friday's was extra awesome. I'd been working for 3 days with a customer, trying to resolve the cause of a crash of our application at their site. Finally get them to install WinDbg and run our debug build so we can get some crash dumps.

Bang. Assertion failure. Nowhere near the crash we see when running a release build.

Dig into the crash dump. Dirty data in their database that the release-compiled version of our application just ignores because the assert() check is turned into a no-op by the preprocessor for release builds.

I can't tell them it's their data that needs to be fixed. This application and its periodic releases has been running just fine on their system for 5+ years.

But, I also can't run the debug version of the latest release to diagnose their current problem. It's stopping during initialization due to the asserts.

Argh.

Saturday, June 13, 2009

Friday, June 05, 2009

readin'

Just finished Use of Weapons by Iain M. Banks. For whatever reason, found it hard to get through. Mostly because I wasn't in much of a reading mood. The two timelines also confused me at first. I enjoyed it though, and will definitely re-read in a few months to see if I like it better the second time.

Next on the to-be-read pile, in no particular order
  • IronPython in Action
  • Watchmen
  • Dark Knight Returns
  • In Defense of Food
  • Pride and Prejudice and Zombies
In other news: Got a promotion at work (in semi-official-title but not in salary). Now I get to do even more of the things I'd rather not be doing. Good times.

Tuesday, January 20, 2009

parable of the goose

The windows near my cube overlook a winding river through the nearby golf course.

Early this morning the ice was pretty patchy. Open in places, other sections just thin enough.

Thin enough that geese walking across would crack through, plop into the water, and create a 3x-goose-size hole in the ice. A pair of them fell through within a section of ice around 30 feet across. Then, a different pair swam happily past in the open area.

One goose got so upset it starts swimming back and forth. Zigging and zagging, banging into the sides of the ice. Trying to get closer to its fellow stuck in the ice, then zooming towards the freely swimming pair. Lots of excitement and action, but ultimately no movement.

Later today....

While talking over all the crazy synchronization steps that my team has to follow in order to stay useful and relevant to the rest of the project, and how we'll transition that into our long-term goals, I tell them the above parable of the goose.

I was talking with the project's PM and current SD-manager (my boss), and was trying to describe how frustrated I was getting. Back and forth, the same discussions, different groups pulling our priorities all over, and ultimately no real progress towards the end goal.

Of course... rather than end the story there, I accidentally finish it up with the goose getting fed up and flying away.

The moral of the story:
I suck at fairy tales. But, I'm awesome at Fruedian slips.

Monday, January 12, 2009

belated reading/listening/watching/playing updates

Read:
  • The Algebraist, by Iain Banks. Re-read this. Even better the second time.
  • World War Z, by Max Brooks. Also a re-read, also awesome.
Listened:
  • Ancestor and Infected, by Scott Sigler. I think I'd have liked these better in print form than as audiobooks... The author does the audiobooks, which I assume allows them to be free. As stingey as I can be, I might pony up some cash if the voices of the characters weren't so lame. Story-wise, I much prefered Infected to Ancestor.
Watched:
  • Finally saw WALL*E, The Dark Knight, and Wanted. All great.
Played:
  • Many, many games with friends and family. Some new/continuing favorites: Ticket to Ride, Game of Thrones, Hey That's My Fish, Snorta, Samurai. 

Saturday, January 10, 2009

best weird debugging experience ever

I am captivated by each nugget of horrible code.

typedef struct RMAP
{
bill* pbill;
line* pline;
rule* prule;
} rmap;

I'm not sure what I find the most interesting... The fact that somebody thought it was fine to copy that struct definition throughout 15+ .c files.

Or, the fact that somebody slightly modified a couple of those instances.

typedef struct RMAP
{
bill* pbill;
line* pline;
rule* prule;
Bool overrideFlg;
} rmap;

typedef struct RMAP
{
bill* pbill;
line* pline;
rule* prule;
double accum;
} rmap;

Or... the best subtle weirdness, in one instance someone reordered the pointers.

typedef struct RMAP
{
rule* prule;
bill* pbill;
line* pline;
} rmap;

So... when you debug the following code in any of the _other_ .c files...

void myCrazyFunction(rmap* a_rmap)
{
rule* r = a_rmap->prule;
double reduction = r->reduction;
... blahblahblahblahblah ...
}

At runtime, everything works -- the definition of rmap used by the compiler is the definition within the .c file, and the third set of pointer-size bits within the a_rmap struct are assigned to 'r'.

But, when I try to debug the code in Visual Studio and hover over the a_rmap->prule I see a bunch of garbage. I hover of 'r', and I see it's got the values I expect.

I'm guessing the debugger finds the first instance of the rmap type in the .pdb file, and the one oddly ordered struct just so happens to be in the first .c file alphabetically (and also first in build order).

But, that realization doesn't come until about 2 hours of other wild goose chases through the rest of the call stack to eliminate the other 'more likely' possibilities.

Good times.