pandoc-citeproc: “stdin” (line 31, column 2): unexpected “b”

Today I came across the following error in pandox (pandoc-citeproc) that was a bit cryptic to me:

pandoc-citeproc: "stdin" (line 31, column 2): unexpected "b"
expecting "c", "C", "p", "P", "s" or "S"
[...]

When I also got this on an empty text (markdown) file with just a reference in it, I realized that the markdown document was not the problem. Indeed, I had inadvertedly deleted a trailing comma in the bibtex document.

@article{lee
title = {Racial [...]

doesn’t work; it should be:

@article{lee,
title = {Racial [...]

Livecode: write document on Android

Android does not allow apps to write just anywhere as a matter of safety. That’s probably generally a useful feature, but this time I wanted to save data to a text file that is accessible to the user (me). The official guide wasn’t really helpful in this case, because there are ways to save data on Android that are not accessible by the users — e.g. for settings.

Apparently the ‘easiest’ way is to save like this:

set the defaultFolder to specialFolderPath("external documents")
put field "write" into URL ("file:test.txt")

The other (common) special folders (“documents”, “desktop”, “engine”) don’t seem to work on Android.

OK, but where is this file we created? Here:
Local/internal storage/Android/data/com.yourcompany.yourapp/files/test.txt

Not the most intuitive place to me, but whatever, I can access this file from the Android device.

Livecode: resolving “could not compile service support class”

I’m not going to tell you how long I’ve spent figuring out why LiveCode wouldn’t compile to Adroid, throwing “could not compile service support class” errors. Apparently this is one of the more common errors when compiling to Android, but typically this indicates a problem with the “mobile setup” (Android Studio, Java).

This was different. I had LiveCode (9.0.3) setup on a Windows machine, Android Studio installed and properly setup. The “mobile” preferences looked OK (path to Android SDK and Java were present and correct), and most crucially, using this setup I had compiled stacks successfully. Now I had a very simply stack and suddenly I got this error. Shockingly, the stack that had compiled an hour earlier wouldn’t compile anymore. I tried many things, and sometimes the stack that was ‘good’ before would still compile, but sometimes it wouldn’t.

It turns out that although LiveCode generally is not case sensitive, it actually can be. I had this one line in my code (this code actually doesn’t work on Android, but I wanted to test whether it works):

set the defaultFolder to specialFolderPath("Documents")

it should have been:

set the defaultFolder to specialFolderPath("documents")

Yes, really, that was all. So in this instance, LiveCode was case sensitive, and quite atypically it didn’t detect the error during coding (LiveCode’s errors when compiling for mobile can be quite cryptic/useless).

Now, I also found that once I got this error, LiveCode would fail to compile anything (yes, even an empty stack) — until I restart the program. So I learned two things here: first, LiveCode can be case sensitive, second, when LiveCode throws this error, I need to re-start the program before trying to compile again.

LiveCode: The package appears to be corrupt on Android

I’ve spent a while figuring out why my LiveCode app on Android wouldn’t install. It was quite odd given that I have compiled and installed other apps from the same machine on the same tablet, but I couldn’t even get an empty card to work. Several pages on the web pointed out that “The package appears to be corrupt” cannot be the case for LiveCode, and I did allow external apps to be installed (otherwise I wouldn’t even get this far).

It turns out that I forgot to set the right key! Of course, once I figured this out, it seemed to obvious, but I needed the setting under “Standalone Application Settings…” to look like this:

I’m putting this out there because none of the pages discussing the “The package appears to be corrupt” error on Android and LiveCode seem to mention this.

Turning R into SPSS?

I have written about several free alternatives to SPSS, including PSPP, Jamovi, and JASP. Bob Munchen has reviewed a few more options: Deducer, RKWard, Rattle, and the good old R Commander (in the screenshot on the left). We also find a review of Blue Sky Statistics. Blue Sky Statistics is another option for those seeking SPSS “simplicity” with R power underneath.

Blue Sky Statistics is available for Windows, and is open source. They make money from paid support. I note that it comes with a polished interface and this data editor that reminds us of Excel. I was very happy to see that Blue Sky Statistics offers many options for data handling, like recoding, merging, computing variables, or subsetting — that’s much better than what say jamovi offers at the moment.

The dialogs are quite intuitive if you are familiar with SPSS, and they can also produce R code. This is a feature we know from the R Commander, and ostensibly the aim is to allow users to wean from the graphical interface and move to the console. Nice as the idea is, it is defeated by custom commands like BSkyOpenNewDataset() that we don’t normally use.

The models offered by Blue Sky Statistics are fine for many uses — for those not living on the cutting edge. A nice touch are the interactive tables in the output, where you can customize to some degree.

Exciting as Blue Sky Statistics and other GUI are at first sight, I’m gradually becoming less excited about GUI for R. Probably the biggest challenge is the “hey, this is all text!” shock when you first open R (or typically Rstudio these days). Once you realize that the biggest challenge is to make the right choices and then interpret your results, you become less hung up about the “right” software. Once you realize that you’ll have to remember either way — where to click, or what to type — copying and pasting code fragments becomes less daunting. If you restrict yourself to a few basic commands like lm(), plot(), and summary(), R isn’t that difficult. Sure, when you come across idiosyncrasies because different developers use different naming conventions, R can be hard. But then, there are also the moments where you realize that there are so many ready-made solutions (i.e. packages) available and that with R you really are in control of your analysis. And the day you learn about replication and knitr, there’s hardly a way back.

One reason I kept looking for GUI was my MA students. I’m excited to see more and more of them choosing Rstudio over SPSS (they are given the choice, we’re currently use both in parallel)… so I there might be simply no need for turning R into SPSS.