One must kill the Asus TF700T in order to save it

I bought an Asus Transformer Infinity back in 2013 to take notes on PowerPoint slides. It worked well at first, until I installed the OTA upgrade to Android 4.2. Then it became clear that the only “infinite” part of it was the lag that would occur under even tiny amounts of IO. Such as loading a webpage, which is mainly what a tablet is supposed to do? So it sat in a shoe box for the past two years. Supposedly installing a different ROM fixes the issue for some folks. It did for me. Here’s the newbie guide:

1. You need to unlock the bootloader. But first, you’ll need to remove your Google account from the tablet. The unlock tool wants your password, and it uses some old, unsupported Google auth API. It will acquiesce if it can’t find any accounts.
2. Download the unlock tool for bootloader from one of a number sketchy websites. Version 8 worked for me. Other versions gave me “invalid group signature errors.” YMMV.
3. Enable developer mode, plug the tablet into a computer and install the unlocker app with adb install. Run it and unlock the bootloader.
4. Install TWRP with fastboot.
5. Boot into TWRP using the recovery mode (power + volume down). Format cache with ext4. Format /data with f2fs.
6. adb push your desired ROM onto the device over USB. I used Timduru’s Katkiss ROM and it works nicely. (ROM is a misnomer, since it’s getting written onto SSD..?)
7. Install (“flash”) a new ROM using the option in TWRP.
8. Push and flash SuperSU.
9. Push and flash gapps.
10. Cross your fingers and hit reboot. If all went accounting to plan, you’ll boot into a shiny, new, usable OS.

Stan and NIMBLE so that computer does the hard part

Erin and I made a trip out to New York last weekend so that I could catch the STAN conference. There were some great talks, especially the “come to Jesus” seminar with Michael Betancourt on typical sets of high-dimensional posteriors and the previously cryptic warnings that STAN’s sampler sometimes emits in my models. I was also pleased that STAN developers are thinking seriously about sustainability beyond its current academic home at Columbia.

STAN has some competition in the Bayesian programming language domain. NIMBLE is a project primarily based out of UC Berkeley that also offers a modern, actively developed domain-specific language for specifying Bayesian models. NIMBLE and STAN have similar goals, but differ as far as methodology.

Similarities

• Both compile to C++
• Both use a domain-specific modeling language

Differences

• NIMBLE explicitly infers the directed graph of the model while STAN is imperative. So you can make pretty pictures of the model more easily with NIMBLE, but maybe more sophisticated programming in STAN.
• NIMBLE actually does use an extended version of the BUGS/JAGS language, so if you already know that there are fewer things to learn
• STAN offers fancy auto-tuning hamiltonian Monte Carlo. NIMBLE offers a number of samplers, but probably nothing as advanced. STAN is probably faster per effective sample (taking in account autocorrelation)
• STAN has an API offering programmatic evaluation of log-likelihoods and gradients
• STAN does not allow for discrete parameters (data are fine). If you’ve got a discrete parameter, you need to figure out how to marginalize it out.
• STAN seems to have a larger library of mathematical functions (gaussian processes/matrix distributions/differential equations, and more)
• STAN automatically handles constrained parameters (non-negativity, positive definite or interval) by transforming them to be unconstrained
• STAN can do MAP and variational inference. NIMBLE has some interesting looking particle filters.

On the joys of running multiple R environments

Once you have reached a certain level of depravity, it no longer suffices to have a single R environment, where the environment can be defined as the R version, the version of all packages, and possibly the version of the compiler and linear algebra libraries that compiled the whole mess to begin with. Such perversion arises when you are developing a package and need to develop against R/Bioconductor development, or you need to run a legacy version of R.

Herein find some notes:

1. You can tell R where to look for its package libraries by setting the environment variable R_LIBS_USER to a non-default directory, eg, R_LIBS_USER=~/R/x86_64-unknown-linux-gnu-library/3.3-bioc-release tells R to put ~/R/x86_64-unknown-linux-gnu-library/3.3-bioc-release first in the places it looks for packages (the .libPaths() search order).

2. Standard advice is to make an alias, ie, in .bashrc:

   alias R-devel R_LIBS_USER=~/R/x86_64-unknown-linux-gnu-library/3.4-bioc-devel R
   

3. But this doesn’t work easily or well if you are trying to run R remotely, say via ESS/tramp in emacs. Instead it is better to write a few shell scripts

   #!/bin/bash
   #put this in a file called R-devel accessible on your path
   R_LIBS_USER=~/R/x86_64-unknown-linux-gnu-library/3.4-bioc-devel R "$@"
   

4. This seems not to be entirely respected by devtools 1.12.0. At least when you call check, it has complicated ways of mangling the library paths that break this, I believe during the “checking whether package XXX can be installed” phase. So you will probably have to call R-devel CMD check myPackage.tar.gz from the shell. Details currently under investigation.
5. It’s possible that using packrat might obviate the custom .libPaths() situation, but not the multiple versions of R situation. But I haven’t had great luck with packrat (probably my own fault).

2017.01.04 Addendum

Working multiple R versions via ESS/TRAMP requires even more bizarre incantations. Supposedly, ESS is supposed to discover R versions searching the EMACS variable exec-path for commands starting with strings provided in the list ess-r-versions, though even this doesn’t seem to work on MacOS. It definitely doesn’t simply work with TRAMP, which sets its own remote PATH based on the variable tramp-remote-path. This, in turn, takes default values that generally don’t reflect the PATH you’d get with a standard login shell on the remote system. Instead, to find a version of R, you may alter tramp-remote-path to put the directory containing your desired version first in the path list, eg, with M-x customize-variables tramp-remote-path.