Software updates by Troy D. Hanson

uthash v1.9.8 has been released.

What’s in version 1.9.8 (2013-03-10)

• We now have a HASH_REPLACE macro (thanks, Nick Vatamaniuc!)
• fixed clang warnings (thanks wynnw!)
• fixed utarray_insert when inserting past array end (thanks Rob Willett!)
• you can now find uthash on GitHub
• there’s a uthash Google Group

On GitHub…
The official home of uthash is now the Github site. You can go there to clone it, grab a zipfile, or to contribute changes back as a pull request.

Google Group
The uthash Google Group is the new “go-to” place, to ask questions. Please ask them there first- and help me answer them there, if you can help!

Simplifying
Regarding versioned releases- it’s much easier to just merge changes, than to also bump version numbers and do announcements. Going forward I may only bump version numbers rarely and keep the master branch as a rolling current release.

I’ve also removed a few things– the PDF version of the documentation, and the tarball of the sources. Long live the tarball.

I’m bad at replying to people
An apology to people who have sent contributions and questions and didn’t hear back from me for weeks or months at a time: sorry! My life, and probably yours, is hectic. I hope the Google Group and the pull queue on Github help.

Twitter
You can follow me at @troydhanson for this kind of news too.

Thanks, again, to everyone who helps keep uthash going.

Here’s a quick example of how to run a daemon process at boot on four platforms:

• Ubuntu, using upstart
• CentOS/RHEL, using sysvinit
• Debian, using sysvinit
• Mac OS X, using launchd

Typically your system services- web servers, etc, start up through these mechanisms. The idea across all these platforms is that you put a script or text file describing your service in the right place, and the OS init apparatus starts everything.

Caveat: I’m not a initscript expert by any means. There are many options that vary across these platforms. What I’ve written here is a quick glance.

For the examples here – imagine we have a daemon called exd that we want to run at boot. The settings used in the initscripts here expect exd to stay in init’s foreground (that is, it doesn’t daemonize by forking again).

Ubuntu

Ubuntu uses “upstart” to manage jobs (at least for the modern releases).

1. Place this script in /etc/init/exd.conf.
2. It’s all ready to go. Start it up: start exd

CentOS/RHEL

This platform uses sysvinit-style scripts.

1. Place this script in /etc/rc.d/init.d/exd.
2. Symlink it to the runlevel-specific directories: chkconfig --add exd
3. Start up the job (on reboot it’ll be automatic): /etc/init.d/exd start

Debian

1. Place this script in /etc/init.d/exd
2. Symlink it into place: /usr/sbin/update-rc.d exd defaults
3. Start it: /usr/sbin/service exd start

Mac OS X

Mac uses “launchd” to start daemons.

1. Place this file in /Library/LaunchDaemons/exd.plist
2. Load and start it: launchctl load /Library/LaunchDaemons/exd.plist

That’s it

That’s a minimalistic look at initscripts on four platforms.

Edited to add: Debian example and replace the inline files with links.

Six years of uthash

I noticed on SourceForge that it’s been six years and a month since uthash was first released on March 28, 2006. Their counter shows 23,421 downloads. Thanks to everyone who has contributed features and suggestions. Over the years uthash grew offshoots, the “bonus” headers for dynamic strings, arrays and lists. These have become handy tools in their own right, judging by the emails I’ve received.

There’s more options for C hash libraries now than there were in 2006. It would be tempting to keep sharpening the axe and make a shiny new uthash, but API compatibility and time have kept things to incremental changes. So it is with the release of uthash v1.9.6.

This is a minor release of uthash with a few bug fixes and edits to the documentation in response to questions I’d received.

Version 1.9.6 (2012-04-28)

• add utarray_prev (thanks, Ben Hiett!)
• add parens/casts for greater compatibility (thanks, Atis, Debasis Ganguly, and Steve McClellan!)
• added ifndef to uthash_malloc and related hooks (thanks, Holger Machens!)
• edit examples so they do not leak memory (thanks, 任晶磊!)

Apparently, I forgot to post about the previous minor version, so for the record:

Version 1.9.5 (2011-11-16)

• added utarray_renew
• fixed memory leak in uthash_clear when using Bloom filter (thanks, Jan Hättig!)
• utarray now copies the UT_icd on array creation rather than storing a pointer
• add parentheses to HASH_ADD to fix preprocessing of certain arguments (thanks, Aaron Rosen!)
• more parenthesizations for greater macro argument flexibility

With that, I’m off to Hawaii. Aloha!

I’ve placed my kvspool library on GitHub.

kv-spool (“key-value” spool)

a Linux-based C library, with Perl, Python and Java bindings, to stream data between programs as key-value dictionaries. The data stream is backed to disk, supports rewind, snapshot, network replication, and bounded disk consumption.

It’s a tiny API. It’s been useful to me in streaming data applications, where you have a never-ending event stream. Besides making it trivial to generate or consume the event stream between different programs in different languages- I wanted kvspool to enable me to “copy off” a sample from a running stream, take it back to a laptop as canned data, and “rewind” and “replay” while developing newer versions of software that consumes the stream.

I also wanted to send the event stream over a network, effortlessly- in fact, invisibly- to the programs that generate or consume the events.

So there it is.

Thanks to the awesome Trevor Adams for his help on this.

Starting processes at boot time, and keeping them running, is not glamorous but it’s important (if your computer gets power cycled, it’s nice to have your applications bounce right back… but I’m sure you already do this).

I put together a utility called pmtr (process monitor) to run my application daemons at boot time, and restart them as needed. I wanted to keep all of these jobs defined in one place– one configuration file. No rooting around in sysvinit files. Just my application’s jobs, all in one place. Like this,

/etc/pmtr.conf

  job {
    name weather-server
    cmd /usr/local/bin/weather -v
  }

  # this one keeps stderr and stdout
  job {
    name doppler-update
    cmd /usr/bin/dop-up
    dir /var/log
    err dop.err
    out dop.out
  }

That’s a simple pmtr.conf with just two jobs. No rocket science – just two jobs, in one place. There’s a handful of job configuration options it supports.

A friend asked me to support “deltas” if you change the configuration file- and this turned into one of the most useful features. It’s really two handy features that go together: pmtr monitors the file (using inotify) for changes so you don’t have to signal it when you make a change; then, when it rescans the configuration, it only fiddles with the jobs you’ve actually changed. You can disable or reconfigure jobs, or add new ones, and have that take effect without disrupting the other ones.

It’s not sysvinit, it’s not upstart, it’s not sophisticated. It’s just … handy.

You can read more about pmtr on it’s GitHub page.