R 4.0 was released over the weekend and immediately I got an email that said one of my packages does not build anymore with R-4.0. The email from R core said I have 2 weeks to bring the package into compliance. The Ubuntu Linux repositories do not have R 4.0 yet, so I built my own. This is something that I've done many times over the years, but I expect many Linux newcomers have not done it. So I'll copy/paste some notes in case it helps.

In all of these details, there are two especially important things to know. First, build R in a separate folder, not in the original source code folder. Second, specify the prefix so that the newly built version of R does not interfere with the previous one that still exists in the /usr file hierarchy.

First, on CRAN, download the file R-4.0.0.tar.gz. Put that in an out-of-the-way folder and decompress (I ran tar xzvf R-4.0.0.tar.gz). That crates a folder R-4.0.0.

cd into that directory and make a new subdirectory called build (mkdir build). We are going to compile R in build in order to prevent the build process from altering the R source code itself. Then cd into build.

The usual process to build GNU software packaged in this traditional style is to run a 3 step process

1. configure
2. make
3. make install

The first thing we do, usually, is to inspect the configure options, with a command like

../configure --help

I want to install my new R-4.0.0 in a separate part of the file system, one where I can read/write as an ordinary user. So the VERY important option is --prefix=/tmp/R. In most softare, it would be sufficient to run this in the build directory:

../configure --prefix=/tmp/R

That would configure the software and so when finishe, it is installed in /tmp/R. However, as luck would have it, I tried that and it failed because the R system tries to write files in /usr/share even after I set the prefix. That was a little unusual.

On Ubuntu, the R packages are built by experts who know what to do. I looked at the file provided with R-3.6.3 called /etc/R/Makeconf to find out what options they used to build R. Their configure statement seems to be quite massive and I played with it for a while. In the end, I decided to take their version,

# R was configured using the following call
# (not including env. vars and site configuration)
# configure  '--prefix=/usr' '--with-cairo' '--with-jpeglib' '--with-readline' '--with-tcltk' '--with-system-bzlib' '--with-system-pcre' '--with-system-zlib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--datadir=/usr/share/R/share' '--includedir=/usr/share/R/include' '--with-blas' '--with-lapack' '--enable-R-profiling' '--enable-R-shlib' '--enable-memory-profiling' '--without-recommended-packages' '--build' 'x86_64-linux-gnu' 'build_alias=x86_64-linux-gnu' 'R_PRINTCMD=/usr/bin/lpr' 'R_PAPERSIZE=letter' 'TAR=/bin/tar' 'R_BROWSER=xdg-open' 'LIBnn=lib' 'JAVA_HOME=/usr/lib/jvm/default-java' 'R_SHELL=/bin/bash' 'CC=gcc -std=gnu99' 'CFLAGS=-g -O2 -fdebug-prefix-map=/build/r-base-5i6V25/r-base-3.6.3=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -g' 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro' 'CPPFLAGS=' 'FC=gfortran' 'FCFLAGS=-g -O2 -fdebug-prefix-map=/build/r-base-5i6V25/r-base-3.6.3=. -fstack-protector-strong' 'CXX=g++' 'CXXFLAGS=-g -O2 -fdebug-prefix-map=/build/r-base-5i6V25/r-base-3.6.3=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -g'

and I trimmed it down to something I could understand. I don't want to use build options that I don't understand. I will trust R's configure script to guess defaults correctly.

../configure '--prefix=/tmp/R' '--with-cairo' '--with-jpeglib' '--with-readline' '--with-tcltk' '--with-system-bzlib' '--with-system-pcre' '--with-system-zlib' '--mandir=/tmp/share/man' '--infodir=/tmp/share/info' '--datadir=/tmp/share/R/share' '--includedir=/tmp/share/R/include' '--with-blas' '--with-lapack' '--enable-R-profiling' '--enable-R-shlib' '--enable-memory-profiling' '--with-recommended-packages'

When that finished, there was a message indicating that I had the required software and that recommended packages would be installed.

Compiling R (with make) is time consuming (perhaps 8-10 minutes one core) and it is faster if you ask make to try to parallelize the build. I allowed 6 cores for that.

make -j6

When that was finished, the last step is to run make install. However, because I diverted the R info and data files to /tmp/share, I needed to prepare for that. I created the folder /tmp/share.

Then the all important installation

make install

Now, when I want to use R-4.0.0, I need to adjust the system path interactively. In the terminal, I run this to put the new R at the FRONT of the path.

export PATH=/tmp/R/bin:$PATH

To use the the system-wide R-3.6, I need to open a different terminal where /usr/bin/ will be at the front of the path.

Behold:

$ R

R version 4.0.0 (2020-04-24) -- "Arbor Day"
Copyright (C) 2020 The R Foundation for Statistical Computing
Platform: x86_64-pc-linux-gnu (64-bit)

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

  Natural language support but running in an English locale

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.
> sessionInfo()
R version 4.0.0 (2020-04-24)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 19.10

Matrix products: default
BLAS:   /usr/lib/x86_64-linux-gnu/atlas/libblas.so.3.10.3
LAPACK: /usr/lib/x86_64-linux-gnu/atlas/liblapack.so.3.10.3

locale:
 [1] LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C
 [3] LC_TIME=en_US.UTF-8        LC_COLLATE=en_US.UTF-8
 [5] LC_MONETARY=en_US.UTF-8    LC_MESSAGES=en_US.UTF-8
 [7] LC_PAPER=en_US.UTF-8       LC_NAME=C
 [9] LC_ADDRESS=C               LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base

loaded via a namespace (and not attached):
[1] compiler_4.0.0

As soon as the Ubuntu repositories have R-4.0, I'll switch to that version. But the lesson here may still benefit you in the long run. When a package is submitted to CRAN, one must sign an oath that the package installs cleanly on the CURRENT version of R as well as the DEVELOPMENT version of R. Now that you know how to build R from a tar archive, it is not so bothersome to install R-devel and test your package.

semTable-1.7 includes a bug fix for tables that include variances estimated between latent variables and exogenous predictors. It has been proposed to CRAN.

In the meanwhile, to avail yourselves, try this to put KRAN (our test server) at the front of your repo search path:

CRAN <-"http://rweb.crmda.ku.edu/cran"
KRAN <-"http://rweb.crmda.ku.edu/kran"
options(repos =c(KRAN,CRAN))
install.packages("semTable", dep=TRUE, type="source")

The parameter 'type="source"' is required for download of the newest from KRAN, but when the new version percolates into KRAN, it will not be necessary. The CRAN auto-processor has accepted the proposed package and usually it takes 2 days for versions to become available for Linux, Mac, and Windoze systems.

In case you have not tried semTable yet, it can make presentable tables of structural equations estimated in R with lavaan. My initial focus was LaTeX tables, but now it generates HTML and CSV files as well. There is a vignette distributed with the package. I uploaded a copy here for your review.

http://pj.freefaculty.org/scraps/semtable.pdf

I have updated to PhP 7.2 FastCGI and WordPress 5.2. I want to use WordPress to display markdown documents that have some latex, so I've installed a plugin for markdown which seems to work. However, I'm getting mixed results with "mathjax-latex". Perhaps markdown and mathjax-latex were not meant to cooperate, I will need to do more testing.

The main issue is that the LaTeX markup that does work in a markdown document that we export to HTML with, say pandoc, does not work "as is" with mathjax-latex. In particular, to get in-line math, special markup seems required.

I can easily show the result of failed efforts, but have difficulty showing the markup. The ordinary markdown code tricks, like indenting four spaces or enclosing in ```, seem not to protect code from latex interpretation.

For inline math, the single dollar sign does not work. Observe, you see dollars $x_i$. However, writing the words "latex" within hard brackets "[" does work, along with "["/latex"]". The symbol "["latex"]" is converted to slash-paren, "\ (". Also I can explicitly type a double escaped "\\ (". Here is a gamma inserted inline with the first method: \(\gamma\), and using the second method \(\gamma\). Here is another Einstein favorite with the double-backslashed parenthesis: \(E=mc^2\), but the single dollar sign is a dud $E=mc^2$. However, if I literally write '$latex' at the beginning, it works: \(E=mc^2\).

Here is an example where the dollar sign notation does not work: This x sub i is at the end of a line: $x_i$. That is a big disappointment because all of my example documents use that notation. Just now I wonder about using escapes, '\$x_i\$'. Fail!

But if I put double dollar sign xsub i on line by itself, we get a displayed equation,

$$x_i$$

Double dollar signs work to get a display equation works OK if the dollar signs are on lines by themselves, which is happy news.

$$
y_{i}\label{1b}
$$

Bad news: the preferred LaTeX markup "\[" does not work to give an inline equation:

[
E = mc^2
]

To make that work, apparently I need a double back slash. That's unfortunate.

Here is a double back slash hard bracket, to show it can work:

\[E-mc^2\]

I use double backslashed "\begin{equation}" to try for a labeled/numbered display:

\begin{equation}
\gamma\label{eq:gam}
\end{equation}

No number, and label doesn't work, trying to cross-reference, equation(\ref{eq:gam}) fails.

So, LaTeX that begins with a backslash apparently needs a double backslash, but that does not work for all \LaTeX, as you see from the fact that LaTeX is not displayed with any special markup.

One problem in git is that when a user deletes a file accidentally, git acts as though the user intended to do that. The next time the user runs "git commit -a" then the list of transactions will include the formal deletion of the file. People who don't inspect the file list, or who carelessly run "git commit -a -m 'your message'" will delete files.

Today I had that situation arise and I have a brief report on how I fixed it. If you don't know for sure what the file path was, first scan all deleted files to see if you spot the ones you want:

$ git log --diff-filter=D --summary | grep delete

If the list is huge, grep for an element in the file name or path you are looking for. In my case, the missing file was an ogv file:

$ git log --diff-filter=D --summary | grep delete | grep ogv

delete mode 100644 36.LaTeX_Overview/LaTeX-Overview.ogv
delete mode 100644 37.LyX-for_LaTeX_homework/LyX-LaTeX_homework.ogv
delete mode 100644 46.windows_R_setup/46.windows_R_setup-slides.ogv

I had 3 files to restore. Now I know their full paths.

Find out which commit removed the files (I've sanitized the name of the author of the commit):

$ git log --all -- 37.LyX-for_LaTeX_homework/LyX-LaTeX_homework.ogv
commit b67eaa335379d5bb5e1187482d3647000426644d
Author: Anonymous
Date: Thu Sep 27 15:43:43 2018 -0500

Finished the installing dependencies and R sections.

There are 2 ways to recover files. These files happened to be in an LFS-enabled git repo, so the first method I tried retrieved the "reference" version of the file. I was not sure I could trust that. This method retrieved the actual ogv file:

$ git checkout b67eaa33^ -- 37.LyX-for_LaTeX_homework/LyX-LaTeX_homework.ogv

The ^ means "the one before this" because the one before this commit was the last one that had the file.

The other method of retrieving uses git show. In my git instruction manual (crmda.ku.edu/guides), we have illustration of the show method.

In the askubuntu web forum (http://askubuntu.com/questions/821940/configure-mouse-buttons-in-xfce4), I asked if it is possible to change the behavior of the mouse in response to  Alt-Middle click. Currently, that causes a window to be moved to the bottom of the stack of windows. On a new Dell precision 5510, the trackpad makes it difficult to know where the left button is separated from the middle button and I often accidentally get the middle when I want left.

There were no answers for a while, so I asked same question in the XFCE4 support forum. https://forum.xfce.org/viewtopic.php?pid=43174#p43174

The answer is that the Alt-Middle click behavior (pushes window to bottom of stack) is hard coded in the xfwm4 source code. Only way to change it is to recompile xfwm4. Helpful person pointed at src file events.c line 928 for revision. I found easy to build new package and now have xfwm4 behaving the way I want!

In case you have not tried this for yourself, the process is much more straightforward than one might expect. It seems quite a bit better than it was just 18 months ago. In brief, get the source for the package, fiddle the source code, try to rebuild, let it make a patch, then build again.

$ sudo apt-get build-dep xfwm4
$ mkdir -p tmp/xfmw4
$ cd tmp/xfwm4
$ apt-get source xfwm4 
$ cd xfwm4-4.12.3/src
$ vi events.c

In that file I made a correction that amounted to this patchfile. It looks like the spaces were destroyed in cutting an pasting, but if you open events.c and go to line 928, you see there is one line I've commented out and one I've added.

+++ xfwm4-4.12.3/src/events.c
@@ -925,7 +925,8 @@ handleButtonPress (DisplayInfo *display_
}
else if ((ev->button == Button2) && (state) && (state == screen_info->params->easy_click))
{
- clientLower (c, None);
+ /* clientLower (c, None); */
+ button1Action (c, ev);
}
else if ((ev->button == Button3) && (state) && (state == screen_info->params->easy_click))
{

This causes the Alt-Middle and Alt-Left behaviors to be the same. I fiddle those lines in the source, then run

$ dpkg-buildpackage -rfakeroot

In new version of this program, there is a very handy feature. The builder notices you edited the file and it makes a patch for you and puts the patch in the debian directory, under patches. Read the output, it will be obvious what to do.

$ dpkg-source commit

Before running the builder again, edit the changelog to update the version. The easiest way is to use the helper named "dch"

$ dch

Opens a dialogue where you need to make sure you are incrementing the package name, so that when you install the new xfwm4 you will build, it gets a new number.

Then run the builder again

$ dpkg-buildpackage -rfakeroot

If all goes well, then the new packages will be in the directory above.

$ cd ..
$ sudo dpkg -i xfwm4_4.12.3-1ubuntu4_amd64.deb
$ xfwm4 --replace &

You'll see the effect of the change right away.

If you've never rebuild a Debian/Ubuntu package, you might as well download the source and give it a try. This is one of the most satisfying parts of being a Linux user.

This change in xfwm4 helps me quite a lot because this touchpad is, well, very difficult to use. Without looking down at the touchpad, I find it impossible to know for sure where the left button area ends and the middle button begins. My right thumb does not always reach far enough to find the left button. By making the left and middle button alt-click behaviors the same, I reduce the error rate quite a bit.

In caveman talk, I'd say to Dell: "trackpad bad! buttons good!". I know I'm out of style here.

Today, I was struck by the beauty of the desert on a crystal clear morning. As the panorama below  indicates, there is no apparent sign of life in this seemingly barren, desolate part of the high plains. Only the grizzled veterans like me can see the glimmers of life that lie deep within the sand, waiting for the rainy season to bring precious moisture.

The library on new year's eve

When the rainy season comes (or the semester starts), the isolated cedar and cactus trees will not look so lonely.