Installing PL/R into PostgreSQL 9.1 on Mac OS X 10.6 and MacPorts

From the pl/R website instructions:

As of PostgreSQL 8.0.0, PL/R can also be built without the PostgreSQL source tree. Untar PL/R whereever you prefer. The shared object for the R call handler is built and installed in the PostgreSQL library directory via the following commands (starting from/path/to/plr):

    cd plr
    USE_PGXS=1 make
    USE_PGXS=1 make install

I wanted to keep the same version I had worked with on PostgreSQL 9.0 so I tried to follow those instructions after deactivating postgresql 9.0 port and activating 9.1, as well as doing postgresql-select so all the default commands (unversioned psql etc) would target 9.1.

Seems with or without R_HOME env variable the build would fail to find the include headers.


In file included from pg_backend_support.c:33:
plr.h:89:15: error: R.h: No such file or directory
plr.h:90:22: error: Rversion.h: No such file or directory

So I downloaded the latest version (had 8.3.0.13 but downloaded 8.3.0.14 hoping the following recent change would solve my build problems given this in the change log:

- The MacPorts installation has the header filed distributed across two different directories, so there is no single "rincludedir" to query from pkg-config. Instead, do it the proper way and ask pkg-config for the cflags, which should work for all installation variants. (Peter Eisentraut)

Well that did not fix it either.

Desperate and aware my Mac Ports were outdated I figured I'd do an update anyway and retry.

The update brought R 3.0.0 instead of my 2.15 so I'm not sure if this is helping or hurting (my production environment uses 2.15)

Even after the upgrade PL/R build code would complain about the headers. So I checked to see where they were:

port contents R

And specifying that location directly did the trick:

USE_PGXS=1 R_HOME="/Library/Frameworks/R.framework/Resources/" make
sudo USE_PGXS=1 R_HOME="/Library/Frameworks/R.framework/Resources/" make install

More, and nastier, upstart problems

So I thought the symlink issue was worth posting about.

Well until this happened. The job is stopped so it cannot be stopped, it cannot be started since it still has a process it is tracking and it is not in the waiting state. And so on.

# initctl status xcmon
xcmon stop/killed, process 1175

For the full gory and glory:

https://bugs.launchpad.net/upstart/+bug/406397

Luckily someone posted something useful in that thread full of "5 years from now"

https://raw.github.com/ion1/workaround-upstart-snafu/master/workaround-upstart-snafu

# ./workaround-upstart-snafu 1175

You may want to change the first line to look for plain ruby instead of ruby1.8 (on my system it is 1.8 anyway). Then run and wait until process IDs loop around.

# ./workaround-upstart-snafu 1175
                1175

# initctl status xcmon
xcmon stop/waiting

Now you can fix this job's conf and start again. Assuming you can.

Upstart job problems on CentOS 6.x

I needed to launch a process at boot time, monitor and restart it if it crashed. After researching and considering monit, node.js forever, supervisord etc, I chose Upstart. Not that I knew enough about all of them to make an informed decision mind you. But if the distribution (CentOS and many others) has chosen it as a replacement for the venerable System V then who am I to disagree.

Ok enough about why, let's get to the what. It is a simple what like they all are.

I was fighting this one job which I had initially set up to:


start on runlevel [2345]
stop on runlevel [!2345]

but now I wanted to start only when told to start (so as to delay the start at boot time enough to allow my cloud-init script to make some config changes before bringing up the process/server/daemon using those config changes):


start on my-start-event
stop on my-stop-event

And of course I was going to trigger these at the end of the cloud-init script which made the config changes like so:

initctl emit my-start-event

In theory (from docs) it was all supposed to work but it wasn't.

I had tried:

initctl reload-configuration

and so on but no gives.

In the end it was my eagerness to centralize code - had put job.conf in my project under SVN and symlinked to it from /etc/init/job.conf. A little line in the initctl manual was the key to figuring out the problem:


reload-configuration

     Requests that the init(8) daemon reloads its configuration. This  command  is  generally not necessary since init(8) watches its configuration directories with inotify(7) and automatically reloads in cases of changes.

Well the symlink timestamp does not change when the target content changes!! Ok off with it and will implement a deployment script to take the job.conf from project to where it needs to be.

a basic /etc/init.d/rserve (start Rserve at boot time)

#!/bin/sh
#
# chkconfig: 2345 20 80
# description: rserve startup script
#
RSERVE=/usr/local/lib64/R/bin/Rserve

. /etc/rc.d/init.d/functions

test -f /etc/Rserv.conf

export R_HOME=/usr/local/lib64/R

RETVAL=0

case "$1" in
   start)
      echo -n "Starting Rserve: "
      [ -f $RSERVE ] || exit 1

      $RSERVE
      RETVAL=$?
      echo
      [ $RETVAL -eq 0 ] && touch /var/lock/subsys/rserve
      ;;

  stop)
      echo -n "Shutting down RServe: "
      killproc $RSERVE
      RETVAL=$?
      echo
      [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/rserve
      ;;

  restart|reload)
      $0 stop
      $0 start
      RETVAL=$?
      ;;
  status)
      status $RSERVE
      RETVAL=$?
      ;;
  *)
      echo "Usage: $0 {start|stop|restart|status}"
      exit 1
esac

exit $RETVAL

Paranumeral is back under new ... everything

Ok maybe not new management. Still old me running the whole thing. But lots (if not all) has changed both on the inside and outside. What you will see first is the outside - all new Ruby/Rails web with fancy (ok maybe not so fancy but definitely) interactive d3.js charts. Oh yeah and now you'll definitely need to sign up so I can start adding personalization features such as portfolios, quotes, alerts etc. The models have gotten more powerful using more features, more data points, more history, though as always one always wants more cowbell.

Paranumeral is Under (Major Re-) Construction

I am making some major changes which are impacting the predictions. Please ignore all it has it say about anything - Twitter prediction feed, paranumeral web prediction query box, historical performance table etc.

Jim Cramer is way behind - but glad he is behind the same stock which we recommended weeks ago via Twitter (and personally bought a few days back):

http://wallstcheatsheet.com/investing/jim-cramer-tells-investors-buy-these-5-big-name-stocks-now.html/

Follow @paranumeral on Twitter and keep an eye for (significant) positive predictions. Do some research and if you like the company go get it well before others crunch the numbers.