Mac *.txt.rtfd to *.txt

In a recent project, an assistant used TextEdit to supposedly save documents as pure (UTF-8) text files. We managed to fix the workflow, but I was left with a bunch of Zip files full of *.rtf from TextEdit. On a Windows or GNU/Linux machine, these files show up as what they are: folders that contain a rich text document (and potentially other stuff). I needed text documents.

After a bit of searching and tweaking, I got the following shell script to convert all the rich text documents in these folders/containers into text documents:

find . -name '*.rtf' -exec unoconv -f txt {} \;

There was a problem, though. The files all had a name containing important meta data. So I had the folder with the name of the file, and inside this folder the file but it was called TXT.txt (converted from TXT.rtf). I’m sure there’s a quick way in a shell script (if you know one, please share it in the comments), but I got stuck with the shell.

Enter LiveCode. Here’s a script that does just that. I guess I could have called the above shell script, but I already had this.

on mouseup
-- INPUT: select a folder with the *.txt.rtfd folders
answer folder "Input: Choose folder:"
put it into infoldername
set the defaultFolder to infoldername
put the folders into listoffolders
-- filter . and .. can cause problems
filter listoffolders without "."
filter listoffolders without ".."
-- OUTPUT: select a destination folder
answer folder "Output: Choose folder:"
put it into outfoldername
repeat with i = 1 to the number of lines of listoffolders
put line i of listoffolders into currentfolder
revCopyFile infoldername & slash & currentfolder &
slash & "TXT.txt", outfoldername & slash & textname
end repeat
end mouseup

Full LiveCode stack here on OSF (it’s nothing more than a button and a text field with a basic log).

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.

Set Encoding When Importing CSV Data in R Under Windows

This is another simple thing I keep on looking up: how to set the encoding when importing CSV data in R under Windows. I need this when my data file is in UTF-8 (pretty standard these days), but I’m using R under Windows; or when I have a Windows-encoded file when using R elsewhere. The default encoding in Windows is not UTF-8, and R uses the default encoding — well, by default. Typically this is not an issue unless my data file contains accented characters in strings, which can lead to garbled text when the wrong encoding is set/assumed.

The solution is quite simple: add encoding="" to the read.csv() command, like this:

x <- read.csv("datafile.csv", encoding="Windows-1252")

or like this:

x <- read.csv("datafile.csv", encoding="UTF-8")

R package not available on R-Forge?

Apparently it is still the case that some R packages on R-Forge are unavailable for download. For instance, the package Austin to calculate Wordscores and Wordfish has no download candidate for Windows. Does that mean Windows users cannot run Wordscores using R? Far from it, they just have to compile the package themselves. This might sound a bit scary, but is actually quite easy if you follow the instructions I have posted over a year ago.