Cyrus' New Completely Useless Blog more R<p> (pieced together from some random twitter comments I made) </p> <p> So... R 3.6 has this new staged install mechanism that doesn't like my use of rprojroot and its make<em>fix</em>file. 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. </p> <p> 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? </p> <p> 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. </p> <p> 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 </p>SBCL 1.5.3 released<p> The <a href="">Release Announcement can be found here</a>. </p> <p> Some of the new goodies (from the ChangeLog) are: </p> <ul> <li> platform support: <ul> <li> RISC-V: numerous bug fixes and improvements </li> <li> all platforms: better run-program performance when used from multiple threads. </li> </ul> </li> <li> enhancement: (declaim (optimize (debug 2))) ensures compilation of top-level forms, providing better debugging for simple forms that are otherwise "byte-code interpreted" when compiled into FASLs. </li> <li> bug fix: use of finalizers could in rare circumstances cause a crash in the garbage collector. </li> <li> bug fix: show extended function designators, e.g. (setf foo), in the disassembler </li> <li> optimization: reduced overhead of calling NTH/NTHCDR. </li> <li> optimization: improved FLOAT-SIGN on DOUBLE-FLOATs on 64-bit platforms </li> </ul> <p> More excellent work from, particularly, Stas Boukarev and Douglas Katzman to continue cleaning up the guts of SBCL and to, once again, trim the core si </p>Fun with R scoping<p> R's default variable scoping behavior is weird, at least coming from the Common Lisp world. </p> <p> I want the equivalent of: </p> <pre><code>(defparameter *foo* "moose") (defun doit () (print *foo*)) (doit) (let ((*foo* "bogus")) (doit))</code></pre> <p> <em>foo</em> is a dynamically scoped (special) variable in Common Lisp parlance. I can rebind <em>foo</em> in the let form, set its value to something and call a function that expects to see <em>foo</em> and have the called function see the new value of <em>foo</em> while but only while executing code in the dynamic scope of the LET form. Simplifying things a bit, if we call doit from code that is not called (directly or indirectly) from inside the LET form, doit will see the value of <em>foo</em> as "moose", whereas any code called from inside the LET form (or from code that calls it inside the LET block) the value of <em>foo</em> will be "bogus". This may seem confusing at first but becomes quite natural over time and is how I think about variable binding and scope. </p> <p> R has its </p>R dput<p> 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). </p>Cleaning up after upgrading quicklisp<p> After a new quicklisp release comes out, I usually spend a few minutes manually cleaning up ~/quicklisp/dists/quicklisp/software/ by deleting newly out of date source directories. </p> <p> Turns out there's a (much) easier way: </p> <pre><code>(map nil #'ql-dist:clean (ql-dist:all-dists))</code></pre> <p> Does the job for me. Nice. Should have found this a long time ago. </p>Making new Java classes with ABCL<p> <a href="">Armed Bear Common Lisp</a> (ABCL) is an implementation of Common Lisp that runs on top of the JVM. One nice feature of this is that ABCL supports interoperability with java code so one can use java libraries from Common Lisp code. </p> <p> One neat feature of ABCL is that you can create java classes directly in Common Lisp, in addition to just defining functions, lisp (CLOS) classes, generic functions, methods, etc... </p> <p> Let's look at a toy example of creating a new java class: </p> <pre><code>;; let's define a new class (defparameter *forty-two-class* (java:jnew-runtime-class "FortyTwo" :interfaces (list "java.lang.Comparable") :methods `(("compareTo" ,"java.lang.Integer" (,"java.lang.Integer") (lambda (this x) (declare (ignore this)) (cond ((&gt; 42 x) -1) ((= 42 x) 0) ((&lt; 42 x) 1) (t (error "bogus!")))</code></pre> More bionic beaver trials and tribulations<p> 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 <a href="">problems</a> 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. </p> <p> 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: </p> <p> sly@madbox:~$ qjackctl </p> <p> This application failed to start because it could not find or load the Qt platform plugin "xcb" in "". </p> <pre><code>Available platform plugins are: dxcb, eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, xcb. Reinstalling the application may fix this problem. Aborted (core</code></pre> Bionic Beaver/NVIDIA Workaround<p> 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. </p> <p> I made the necessary changes by hand (roughly), but this <a href="">article</a> suggests that the "proper" way to do this is with dpkg-reconfigure lightdm. Perhaps I'll try dpkg-reconfigure gdm3 once <a href="">bug 1768906</a> is fixed. </p>Ubuntu 18.04/NVIDIA Woes<p> 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. </p> <p> There's a bug <a href="">here</a> for those interested. </p> <p> Arghh.... </p>Hey R (#rstats), WTF?<p> 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: </p> <pre><code>foo &lt;- function(x) { cat("Hey, I've got a", x, "\n") }</code></pre> <p> So far so good. I can do: </p> <pre><code>&gt; foo("moose") Hey, I've got a moose </code></pre> <p> 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: </p> <pre><code>x &lt;- moose foo &lt;- function(x=x) { cat("Hey, I've got a", x, "\n") }</code></pre> <p> and if I do: &gt; foo("gazelle") Hey, I've got a gazelle </p> <p> It looks like everything is OK. Until I go to do: </p> <pre><code>&gt; foo() Error in cat("Hey, I've got a", x, "\n") : promise already under evaluation: recursive default argument reference or earlier problems?</code></pre> <p> WTF? Of course I want the value of x I defined above and of course setting the value of x to the currently-being-defi </p>