Weechat on OSX

This is recording how I got weechat on OSX updated to 4.0.4, and how I fixed /script to work as well, thanks to some helpful folks on IRC.

One of the slight annoyances with using weechat on OSX is that the Homebrew version is still 3.8 or so. I have multiple systems, with weechat on all of them, and OSX is the outlier in being outdated.

The #weechat channel on libera was horribly useful, and got everything straightened out, with first updating to 4.0.4, and then fixing a problem with scripts. I’m writing up what I did here, so it’s easily searchable.

First, the upgrade to 4.0.4. It’s important to know that while I did all this, I didn’t originate any of it. I can’t claim credit, and don’t. I was doing things that others suggested. (The users in question were trygveaa and R2robot; I don’t know them outside of those names.)

The first thing I did was run brew edit weechat, to edit the weechat recipe file for Homebrew. The values I needed to change were the url and hash values for the downloaded file; they’re lines 4 and 5 for me, and this is what I changed them to:

url "https://weechat.org/files/src/weechat-4.0.4.tar.xz" sha256 "ae5f4979b5ada0339b84e741d5f7e481ee91e3fecd40a09907b64751829eb6f6"

After that, it’s a simple matter of running:
brew reinstall -s weechat
… which should download weechat from source (and thus get 4.0.4) and install it from there.

Now, running weechat gives me 4.0.4; that’s one problem down!

~ > weechat -v
4.0.4
~ >

The other problem was that /script didn’t work; it would tell me it was trying to download the scripts from an external server, and… that’s it. No progress. No scripts window, no nothing. That’s suboptimal, because there are a few scripts I find highly useful.

I got it working by setting an environment variable. I actually tried two of them, but only one turned out to be significant:

export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES

With that set, /script downloaded the list of scripts, and I could install, autoload, et cetera. I had also tried setting WEECHAT_HOME to a different location (also a suggestion), and that worked as long as I had the fork safety disabled – and removing WEECHAT_HOME left my configuration where it was “supposed to be” (the default) and /script still worked, so the OBJC_DISABLE_INITIALIZE_FORK_SAFETY is what made the difference.

Scrivener 3.2 Compile Issue

I’m a big fan of Literature and Latte’s Scrivener product. If I’m writing “for real,” it’s typically in Scrivener, although I think my process there could still use a lot of work. (I use a graduated system for writing, which … now that I think about it, isn’t very efficient for organization or promotional purposes.)

Anyway: Scrivener! If you write, it’s a fantastic product. Highly recommended.

However, they recently put out 3.2, and I ran into a problem with it.

The process in Scrivener is to write a draft (surprise!) and then compile that draft into a final product, which can be in any of a number of formats: Word document, PDF, Mobi, Epub, and so forth and so on.

What was happening is that I could not get it to run that compilation step, at all. I’d select the menu option, the program would… do nothing. It was as if I wasn’t even hitting the menu item.

I reported it to Literature and Latte, and they figured out a workaround: it’s related to a setting for fonts in the compile.xml file.

There are a number of ways you can approach this: my project’s still in early draft mode, so I simply opened the directory that my project was in, went to Settings, and deleted compile.xml. Once that was done, the menu item worked again and I could generate a draft document from my project.

You can also open up compile.xml in a handy text editor, and delete the lines that have <Font> in them. (The error is related to a font lookup, somewhere internally.) I haven’t tried this, because, well, the project I’m working on is in early draft so I don’t need anything special here.

Lastly, you can wait for Literature and Latte to release a new build of Scrivener 3.2. I’m on build 14343, and I expect they’ll suss out this problem quickly and there’ll be a fix out soon.

Big Sur and Homebrew

I converted to a mostly-Apple home office over the past couple of years. I still have different platforms hanging out – I have a Windows laptop for games (which is currently gathering a lot of dust), a few Linux embedded devices lurking about… but my primary tools are all running OSX.

I typically keep them all up to date. That’s got advantages and disadvantages; it puts me at Apple’s mercy for security (and there are legitimate security concerns with the Apple technology stack) but it also means everything mostly magically works.

Big Sur came out last week, and I updated my main work machine – an iMac – through the automatic process. My media creation machine – a MacBook Pro – is still on Catalina, because I record music and a lot of my music software isn’t ready for Big Sur yet. I’m going to wait until I have more confidence that I’m not locking myself out of my tools before upgrading that machine.

However, Homebrew stopped working on Big Sur, with a complaint that the command line tools weren’t working. This is related to Xcode.

The solution, though, was simple: I validated my version of Xcode (to make sure it was Xcode 12.2, the current version), and then went to https://developer.apple.com/download/more/ and installed the Command Line Tools for Xcode 12.2.

After that, brew upgrade worked as it always did. Everything’s back on track.

Installing GraalVM on OSX with SDKMan

Want to install GraalVM on OSX? It’s easy.

First, get SDKMan. Trust me. You want it. Almost as much as brew, if you’re doing anything with the JVM. You’ll want to install bash – via brew – because SDKMan uses bash and the OSX bash shell is badly outdated.

Once you have SDKMan installed and available in your shell, execute the following command:

$ sdk install java 19.3.0.2.r11-grl

If you don’t install it as the default JVM, you can select it as the current JVM with this:

$ sdk default java 19.3.0.2.r11-grl

You can check it with java -version:

$ java -version
openjdk version "11.0.5" 2019-10-15
OpenJDK Runtime Environment GraalVM CE 19.3.0.2 (build 11.0.5+10-jvmci-19.3-b06)
OpenJDK 64-Bit Server VM GraalVM CE 19.3.0.2 (build 11.0.5+10-jvmci-19.3-b06, mixed mode, sharing)

This installs the latest GraalVM installation for Java 11, as of when this was written. Enjoy!