Local Julia packages

I'm working on some Julia scripts and recently needed to write some utility functions usable from multiple files. I could be very careful with includes to make sure the file is included exactly once when needed, but that seemed rickety to me. I wanted it to be like a package I could confidently bring in with a using directive. Unfortunately this doesn't seem to be common in the Julia ecosystem and only really became possible (?) recently.

I had to make a subdirectory for the utility package containing a separate project with its own metadata. So the MyModule subdirectory had a Manifest.toml, Project.toml, and src subdirectory, containing MyModule.jl. The metadata files were created by the package manager, but I had to edit Project.toml to give the package a name and uuid. Then in the package environment for the root project, I ran develop MyModule to add the utility package as a development/local dependency.

Policy Plus - ADMX download suggestion

A Policy Plus user filed an issue today stating that it was not showing many policies. I suggested using Help | Acquire ADMX Files if they were on a Home edition and this brought in all the expected policies. That step is mentioned in the GitHub README, but not all users will see that. So I added a first-run check: if Policy Plus is running on a Home edition and there are several orphaned non-empty categories (which happens if referenced ADMX files are missing), the user will be asked whether they want to download ADMX files. Selecting Yes produces the standard Acquire ADMX Files dialog. This should improve the new-user experience.

FMod - v2.11.3

I received a report from a PCKF user that Abiathar was unable to open a certain mod's levels because one level was wider than 255 tiles. Indeed, Abiathar's level size restrictions structure uses one byte to store each dimension, so it couldn't handle larger levels. Such levels have weird behavior in-game past coordinate 255, but they can be played. 

So I increased the default limits to 65,535 (the maximum that can be stored in the standard level format). It wasn't as simple as just increasing some constants, though, because some parts need to pack two coordinates into one 16-bit number, mostly having to do with links. I added some checks to reject link destinations with coordinates larger than 255. Then I found that saving really huge levels crashed because their compressed plane data sizes couldn't be fit into two bytes. I introduced a "maximum area" field to the level size restrictions and added checks for this to the level properties dialog and row/column manipulators.

Since inability to open valid levels is a major problem, I released these changes (and the IMF-related ones waiting in beta) immediately as v2.11.3.

Finding out what a "Host Process for Windows Tasks" is doing

Today I noticed a "Host Process for Windows Tasks" process (taskhostw.exe) with heavy disk usage. That name isn't very specific, and indeed the program seems to be just a holder for various tasks' modules. To look at it more closely I fired up Process Explorer as administrator and opened the instance of taskhostw.exe with the most activity. I switched to the Threads tab and looked at the thread with CPU activity. Its Start Address was in SetupCleanupTask.dll, which is located in C:\Windows\System32\oobe.

That was at least more specific, but it didn't tell me exactly what that module does. I went back to the main Process Explorer screen and set View | Lower Pane View to Handles to see what the process had open. Selecting the process and looking through the lower pane, I found that it had some log files open in C:\Windows\Logs\SetupCleanupTask. Skimming those logs suggested that this module checks to see if it's been long enough (10 days) since the last Windows feature update was installed, then deletes the C:\Windows.old folder, reclaiming disk space.

Tiny Blogger glitch: extra space

Since Google revamped the Blogger management UI to be more modern and bubbly, there's been a tiny glitch with the post editor. When starting a new post, the editor box initially contains one space, so clicking in the box and just starting to type makes the first line start shifted to the right slightly. Deleting the initial space is easy, it's just a strange UI thing.

Selecting a Python virtualenv in Visual Studio Code

I'm using Visual Studio Code to do some Python development over SSH. The project is in a virtualenv, so many packages are not available system-wide, so for autocomplete to fully work VSCode needs to recognize the virtual environment. For some reason I thought this would be more complicated than it is: when selecting the Python interpreter, pick the python symlink inside the virtualenv's bin folder. I also enabled the "Activate Env In Current Terminal" so the shell in the Terminal tab would be immediately ready to go. VSCode doesn't consistently display the environment as a virtualenv in the status bar, at least over SSH, but autocomplete picked up the libraries.