Cyrus' New Completely Useless Blog

Ugh... more R General

(pieced together from some random twitter comments I made)

So... R 3.6 has this new staged install mechanism that doesn't like my use of rprojroot and its makefixfile. I can get around the problem by installing with --no-staged-install but this makes me think I'm just sweeping the problem under the rug.

This makes me think maybe I should redo the way my packages load/process/provide data in the first place. I'm not a huge fan of the R package installation mechanism, but I get that it's there and that I should use it. How do folks deal with loading non-R data from packages?

One thing I see from @hadleywickham, e.g., is the use of the data-raw directory and some hand-run scripts that generate the .Rdata files. I guess this can work, but seems like a bit of a hack to me.

There are a couple of distinct issues here. One is finding data at runtime. It seems like rprojroot hasn't been updated in a while and isn't designed to deal with staged installs. The "here" package that @JennyBryan raved about a while back seems to have disappeared.

The second is the time at which very pieces of code are run (in this case to do the processing of the "external" data and the generation of .Rdata files and/or various exported variables with "canned/processed" data in them.

Anyone have good suggestions for managing both of these issues in the face of staged installs?

So far the cleanest thing I've got is to setup global variables, use .onLoad to populate them, and to, e.g., from my vignettes, use requireNamespace(...) to load the namespace and (implicitly) call my .onLoad function.

R dput General

I just learned about dput today. This is one of the many things I've been looking for in R. Note to self: use dput to print things "readably" (in the lisp sense).

More bionic beaver trials and tribulations General

So... it's safe to say that the upgrade to bionic beaver (Ubuntu 18.04) hasn't been the smoothest. On my main development box (madbox), it took my many days to sort through the problems I mentioned the other day, but those are at least temporarily solved by using lightdm instead of gdm3. Anyway, my latest issues are 1) no video in firefox when running jackd at 48k and 2) on a somewhat related note, qjackctl won't start.

So issue 2 is only somewhat related as it doesn't really have anything to do with firefox, but I was hoping to run qjackctl to get a sense of what's going on with the various jack ports. So, try qjacktcl and get:

sly@madbox:~$ qjackctl

This application failed to start because it could not find or load the Qt platform plugin "xcb" in "".

Available platform plugins are: dxcb, eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, xcb.

Reinstalling the application may fix this problem.
Aborted (core dumped)

Awesome. So it turns out that I'm not the only who has had this problem and searching for xcb failures turns up a whole mess of problems and possible solutions, none of which seemed to do anything helpful.

Finally, I came across the following Stack Overflow page which helpfully describes the QTDEBUGPLUGINS=1 environment variable.

Starting qjacktl with this set gives:

Got keys from plugin meta data ("xcb")
QFactoryLoader::QFactoryLoader() checking directory path "/usr/bin/platforms" ...
Cannot load library /usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/ ( cannot open shared object file: No such file or directory)
QLibraryPrivate::loadPlugin failed on "/usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/" : "Cannot load library /usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/ ( cannot open shared object file: No such file or directory)"

After which doing:

sudo apt-get install --reinstall libxcb-xinerama0

fixes the problem. Hooray for debugging environment variables. Still, would have been nice if the application had told me that's where the problem lay in the first place.

Bionic Beaver/NVIDIA Workaround General

So... it turns out that a temporary solution (at least) to my NVIDIA woes is to use lightdm instead of gdm3 as the display manager.

I made the necessary changes by hand (roughly), but this article suggests that the "proper" way to do this is with dpkg-reconfigure lightdm. Perhaps I'll try dpkg-reconfigure gdm3 once bug 1768906 is fixed.

Ubuntu 18.04/NVIDIA Woes General

Well, two of three updates to Bionic Beaver (Ubuntu 18.04) went smoothly, but the third has turned into a giant disaster. On this computer the OS boots when logging in via the gdm-session-manager (?) screen, once you log in, the display completely freezes up. Have tried numerous drivers (different versions (current, beta, old, etc...), different methods of installing the drivers (NVIDIA proprietary installer, ubuntu packages, etc...), multiple graphics cards (an old GTX 770 and a brand new GTX 1070 Ti), different grub settings, etc..., all to no avail.

There's a bug here for those interested.


Hey R (#rstats), WTF? General

So I regularly find myself thinking "what where the designers of R thinking?". For today's example, consider the following contrived example. Say I've got the following function definition:

foo <- function(x) {
    cat("Hey, I've got a", x, "\n")

So far so good. I can do:

> foo("moose")
Hey, I've got a moose 

Ok, but now I want to default the argument, but I don't want to just say x = "moose" as I might want to use the same string elsewhere, only write it once, etcd... So I do:

x <- moose

foo <- function(x=x) {
    cat("Hey, I've got a", x, "\n")

and if I do: > foo("gazelle") Hey, I've got a gazelle

It looks like everything is OK. Until I go to do:

> foo()
Error in cat("Hey, I've got a", x, "\n") : 
  promise already under evaluation: recursive default argument reference or earlier problems?

WTF? Of course I want the value of x I defined above and of course setting the value of x to the currently-being-defined value makes n sense. Who designed the scoping rules here?

Fun with Docker: Passing Arguments to Shell Scripts General

So it's 2018 and it's still a pain to pass arguments to shell scripts. Or at least that's how it seems to me. In putting together the davical-docker stuff, I realized that I wanted to be able to call my file with (potentially anyway) some arguments. In particular, I wanted an argument for a container to initialize the docker database, otherwise, not. There are a million ways to handle this and one obvious alternative would be to use environment variables to pass this sort of info. But I wanted to be able to say "docker run ... sly/davical davical --initialize" and have the right thing happen.

So, after some googling, I came up with following:


# -temporarily store output to be able to check for errors
# -e.g. use “--options” parameter by name to activate quoting/enhanced mode
# -pass arguments only via   -- "$@"   to separate them correctly
PARSED=$(getopt --options=$OPTIONS --longoptions=$LONGOPTIONS --name "$0" -- "$@")
if [ $? -ne 0 ]; then
# e.g. $? == 1
#  then getopt has complained about wrong arguments to stdout
exit 2
# read getopt’s output this way to handle the quoting right:
eval set -- "$PARSED"

# now enjoy the options in order and nicely split until we see --
while true; do
case "$1" in
            case "$2" in
                "") initdavical=true ; shift 2 ;;
                *) initdavical=$2 ; echo $@ ; shift 2 ;;
            case "$2" in
                "") updatedb=true ; shift 2 ;;
                *) updatedb=$2 ; echo $@ ; shift 2 ;;
            echo "Error!"
            exit 3

if [ ${initdavical} = true ];
    echo "running database setup scripts"
    psql -qXAt -U ${DAVICAL_DBA_USER} -h ${DAVICAL_DB_HOST} ${DAVICAL_DB_NAME} < /usr/share/awl/dba/awl-tables.sql 
    psql -qXAt -U ${DAVICAL_DBA_USER} -h ${DAVICAL_DB_HOST} ${DAVICAL_DB_NAME} < /usr/share/awl/dba/schema-management.sql
    psql -qXAt -U ${DAVICAL_DBA_USER} -h ${DAVICAL_DB_HOST} ${DAVICAL_DB_NAME} < /usr/share/davical/dba/davical.sql 

if [ ${updatedb} = true ];
    echo "updating database"
    /usr/share/davical/dba/update-davical-database \
        --dbname ${DAVICAL_DB_NAME} \
        --dbuser ${DAVICAL_DBA_USER} \
        --dbhost ${DAVICAL_DB_HOST} \
        --dbpass ${DAVICAL_DBA_PASSWORD} \
        --appuser ${DAVICAL_APP_USER} \
        --nopatch --owner ${DAVICAL_DBA_USER}

if [ ${initdavical} = true ];
    echo "finishing configuration"
         < /usr/share/davical/dba/base-data.sql 
    psql -qXAt -U ${DAVICAL_DBA_USER} -h ${DAVICAL_DB_HOST} \
         -c "UPDATE usr SET password = '**${DAVICAL_ADMIN_PASSWORD}' WHERE user_no = 1;" \

Arghhh... there's a bug in cl-markdown that is causing underscore characters to be displayed as or as appropriate. Hopefully that will get fixed one day.

Fun With Docker: davical and davical-db General

So one thing I've been working with on and off over the past few months is getting a docker-ized setup for Davical going. I've finally published pushed my Dockerfiles and related files to github. There's davical-docker and davical-db-docker which are images for the Davical server and Davical postgres database respectively.

One of these days I'll get around to pushing images to docker hub.

It's back General

Nuclblog is dead. Long live nuclblog. But, I have a new blog, based on Eitaro Fukamichi's excellent Caveman2 web framework. More details to come.

R devtools library General

The R devtools library is something I had been missing in R for a long time. The problem I was having was that I couldn't figure out to put code into a package, edit the code in the package, and then reload the edited package code into a (still-)running R session. I knew there had to be a better way than quitting R, re-installing the package with R CMD INSTALL, and then restarting R.

It turns out that the devtools library lets you do just that with:


Much better.

1 2 Next