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.

Stop using population estimates as evidence of racism

I’ve long been critical of population estimates as ‘evidence’ of racism, but now there is no reason left to do so. The basic ‘evidence’ is as follows: There are say 5% immigrants in country X, you ask the general population, and their mean estimate is maybe that there are 15% immigrants in the country. Shocking, they overestimate the immigrant population, which is ‘evidence’ that the general population is generally racist (I enjoyed this phrase). I’ve been critical of this because of three reasons. First, we don’t generally tell survey participants what we mean by ‘immigrants’, but use a specific definition (foreign citizens, foreign born) for the supposedly correct answer. Second, why should members of the general population have a good grasp of the size of the immigrant population? We might be able to estimate the share of immigrants in our personal network, but that’s not the same as estimating population shared. Third, if we see this as evidence of racism, we assume that the threat perspective is dominant.

It turns out, however, that there is a general human tendency to overestimate the population share of small groups: immigrants, homosexuals, you name it. David Landy and colleagues demonstrate that this tendency to overestimate small groups comes hand in hand with a tendency to underestimate large groups — a pull towards the average. There’s nothing particular about immigrants there, and nothing about racism either.

Landy, D., B. Guay, and T. Marghetis. 2017. ‘Bias and Ignorance in Demographic Perception’. Psychonomic Bulletin & Review, August, 1–13.

Photo: CC-by-nc-nd by IceBone

pandoc document conversion failed with error 43

Today I had a “pandoc document conversion failed with error 43” error when compiling a document in Rstudio and directly with rmarkdown. Such an error used to occur a couple of years ago, but that bug has long been fixed. At first I was a bit puzzled, given that this was a rather simple document. It turned out that this error can be a sign of a poorly specified ‘date’ argument in the header, more specifically pandoc does not like a period there.

title: "Something"
author: "Didier Ruedin"
date: "7 March 2017"
output: pdf_document

works, while

title: "Something"
author: "Didier Ruedin"
date: "7. March 2017"
output: pdf_document

does not. In German, typically there is a period in dates, like 7. März 2017.

Factorizing Error (in Zelig)

Today I re-run some code in R and was greeted with an error “Error in factorize(formula, data, f_out = TRUE)” and (more specifically) “Unable to find variable to convert to factor.” I immediately suspected the as.factor(x) among the predictor variables to be the culprit, but since this is analysis that has worked a few days earlier (on a different machine), I quickly searched on the web and found nothing. For some reason, in this case the as.factor(x) did not work, and the solution was simple: create a new (factor) variable separately and then run the regression analysis with the new variable. So instead of:

z <- zelig(y ~ x1 + as.factor(x2) + x3, model="normal", data=d)

I first create the new variable:

d$x2_factor <- as.factor(d$x2)

and then run the regression analysis with the new variable:

z <- zelig(y ~ x1 + x2_factor + x3, model="normal", data=d)

I just thought I’d share this in case someone else comes across this error and doesn’t find it obvious what the solution is.