Problem

You want your OTRS installation to send your agents notifications whenever a ticket is created through the web service interface.

Analysis

The default notification configuration does not do this, perhaps because the triggering event is NotificationNewTicket, whatever that is.

Solution

Create a new ticket notification, or change the existing one, and set the “Event” field to TicketCreate.

Problem

When replying to or forwarding a message in Outlook, the attribution header uses a 12-hour clock (AM/PM).

You are of the opinion that this format is a remnant from the Dark Ages, when it was, well, dark and people had to be told whether it was day or night, and so you would really like Outlook to stop that.

Analysis

Outlook is being excessively clever here, as usual. It has an option to override the language used for formatting the attribution header, and this option overrides not just the language but the entire locale with the (im)moral equivalent of en-US.

Solution

In Options/Advanced/International options, turn off “Use English for message headers on replies and forwards and for forward notifications. [sic]".

Outlook will now use the format defined in Windows regional settings. It will also use the language defined there.

ZFS backup via SSH tunnel. Throughput without SSH compression is ~4 Mb/s. With compression, it is >30 Mb/s (of compressed data!), and about 400 MiB/min net (about 1.7:1 compression). How come?

#include <algorithm>

std::vector<int> spaces = std::accumulate(lines.begin() + 1, lines.end(),
        std::vector<int>(max_length, 1), [](auto acc, auto line) {
    std::vector<int> tmp(acc.size(), 0);
    std::transform(line.begin(), line.end(), acc.begin(), tmp.begin(), 
            [](wchar_t ch, int b) {
        return b && (ch == L' '); 
    });
    return tmp;
});

It’s Maplebark. Not Marble Arch.

I just used Vim’s listchars feature for the first time to make non-breaking spaces visible. Only I found that it did not appear to work correctly; the nbsp item in listchars only worked if I also included trail, on the other hand, including eol would not change the behavior.

Before reporting bugs, one should always try the latest release, and so I did. I was not inconsiderably surprised that the bug was indeed fixed there.

Then I looked at the repo, and found that it had been fixed not 24 hours before I hit it when using the entire feature for the first time.

Typisch.

WHAT THE ACTUAL F?

concurrent.future's ProcessPoolExecutor does not work from a venv, at least on Windows. It fails with a lot of “invalid handle” and “access denied” errors.

The reason is the usual one that explains everything that goes wrong on Windows if multiple processes are involved: No fork(). Instead, ProcessPoolExecutor creates a pipe to feed commands to a spawned subprocess. To do that, it lets the subprocess inherit the pipe and uses the command line to tell it about the handle.

Fatally, the venv python.exe in turn invokes the “parent” one, with the same command line, and waits for it to exit to forward the exit code, but without also letting it inherit the handle again (and how should it know to do that?).

So the “base” Python, two layers down, gets a handle value on the command line, tries opening it, and finds nothing, or a handle to something unexpected, and dies.

Workaround? No idea. Get the main installation from the Registry, overwrite sys.executable or whatever concurrent uses to find the interpreter to run, then fake up a PYTHONPATH and cross ten packets of fish fingers. Oh, and do not expect to use the interpreter you do that in for much else afterwards, I suppose.

Update: Fixed!

I just dropped my tablet pen onto the keyboard, and somehow that resulted in an absolutely huge mouse pointer. Huh?

Resetting is simple; just switch to another pointer scheme and back.

What strange key combination did the pen hit to cause this? The list of accessibility shortcuts does not have an entry that fits.