Tag: Windows

Posted on

Cleaning up Zotero’s “The attached file could not be found at the following path”

After an upgrade to one of the machines linked to my Zotero account, I got errors that some of the attached filed could not be found. Now, I attach most of my files, so I was pretty sure that the files were there. I also double-checked that the base directory was set correctly, and that it was set to relative paths (moreover, only some of the attached PDF were affected, so I knew that the basic setup was OK).

Using Zutilo (a plugin for Zotero), I could figure out that the problem of those attached files was that an absolute path was set. In fact, on the Windows machine (i.e. the machine that was upgraded and where Zotero was set up afresh), I could simply choose to select the file again to resolve the issue, but there were more than a handful of attachments involved.

So I used the Zotero Storage Scanner (another plugin for Zotero). I was useful to read the instructions, as the scanner plugin has no GUI and works in the background to tag broken attachments. On my machine, I got around 1 entry tagged per second, so adjust your expectations accordingly.

Because the scanner plugin tags the attachments/PDF and not the articles, I then created a new collection in Zotero. Selecting the #broken_attachments tag, pressing minus (to collapse all items), I then added all the items to that collection. This way, I was sure to select the entries for the next step.

Selecting all articles with broken attachments, enter Zutilo for the second time. This time, I needed to “Modify attachment paths”. There are two boxes, one after the other. So in the first one, I entered that part of the absolute path, that wasn’t needed (I copied this from Zutilo’s “show attachment paths”), like “D:\ZoteroPDF\” (without quotes). In the second one, I added “attachments:” (without quotes, but including the colon). On my machine, this took around 3 seconds for 2k items.

Because I did the fixes on the GNU/Linux machine (this will also apply to Mac), I used Zutilo once again to modify attachment paths: In the first box, I entered the backslash (“\” without quotes), and made sure to tick “change all instances”, and then in the second box I entered the forward slash (“/” without quotes).

Getting everything synced on the Zotero servers took a while, but all my attachments work again as they should.

Posted on

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).

Posted on

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 Android, 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 simple stack and suddenly I got this error. Shockingly, the stack that had compiled an hour earlier wouldn’t compile any more. 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.

Posted on

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")

Posted on

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.