## ~skeeto

#### ~skeeto/public-inbox

Last active 8 days ago

### Recent activity

#### Re: Well-behaved alias commands on Windows 8 days ago

From Christopher Wellons to ~skeeto/public-inbox

Yeah, Notepad++'s uninstall.exe is PATH-hostile and poor planning. In
other cases even adjacent DLLs can get in the way since they're eligible
for resolving dependencies. Notepad++ is a good candidate for a command
alias.

You don't need to modify alias.c to achieve this, though. You only need to
provide a path relative to the alias program. For example, if you have a
"bin" directory in your profile directory (assuming standard location),
you can install the alias in there with this EXE path:

Since that's awkward, I just modified alias.c to support absolute paths
starting with a drive. See w64devkit commit 0b63b1c. That permits:

#### Re: Elfeed and Reeder a month ago

From Christopher Wellons to ~skeeto/public-inbox

This was a problem I had intended to solve with the "elfeed-web" part of
Elfeed. The plan was to visit using a browser on a mobile device and use
the links to open tabs, if not just read inline. However, it wasn't useful
enough to me, and I've only kept it around because it has users. If it's a
long-form article I want to read more comfortably, I manually navigate and
open it on my tablet. (It's shocking the number of websites that make this
difficult, as though they don't want visitors.) There's an Android app,
not written by me, linked in the README, though I don't know the state of
it, nor is it helpful for iOS.

If you have some sort of browser sync, maybe you could open the article in
other devices.

#### Re: The quick and practical "MSI" hash table a month ago

From Christopher Wellons to ~skeeto/public-inbox

With a good-quality hash (especially xorshift finalized) it's unnecessary,
and "higher" vs. "highest" will have no measurable difference. When using
a multiplicative hash like FNV-1a without a finalizer, you probably want
to use the highest bits since they're higher quality, and specifically
using the highest bits may let you avoid paying for a finalizer. On the
other hand, Java's String.hashCode() has poor-quality high bits (i.e.
zeros) for short inputs. To a certain degree it's about knowing your
inputs.

I picked the highest bits for my example since it's simple, obvious, and
maximizes the effect. Sometimes I've even used overlapping regions of the
hash which, as you noticed, can't happen in my example. My example would
reasonably still work well with a 32-bit hash input, overlapping when exp
is 17 or greater. (The main detriment may be in the hash function itself

#### Re: Configuring w64devkit.exe to add more directories to the PATH a month ago

From Christopher Wellons to ~skeeto/public-inbox

> what other options do you have potentially in mind?

* Tell w64devkit.exe to start a new console window instead of reusing the
one it was given.

* The "clear the environment" idea I mentioned since it's difficult to
accomplish in the .profile. Could help normalize the environment across
different machines by keeping the local junk out of the way.

* CreateProcess options. For example, starting the shell under a new job
object with a "kill on job close" flag. I've been experimenting with
running w64devkit, including the home directory, from a thumb drive using
the new .ini configuration. I've found GnuPG Agent even more irritating
than usual. It prevents me from ejecting the drive until I manually kill

#### Re: Configuring w64devkit.exe to add more directories to the PATH 2 months ago

From Christopher Wellons to ~skeeto/public-inbox

I have a small surprise for you, Peter. Instead of "w64devkithome.txt" I
have opted for "w64devkit.ini" which currently lives on the "ini" branch:

https://github.com/skeeto/w64devkit/commit/8db776f

It supports variable expansion and paths relative to the .ini file. You'd
use "home = ..\homedir" in your case. I went for an .ini file since I
figured this would grow more options in the future.

I carefully read the .ini file as UTF-8 and pass wide paths to Windows,
though unfortunately busybox-w32 remains limited by the narrow API.

I'm going to dogfood this for awhile, in case I notice issues and to
incorporate feedback you or others might have.

#### Re: Configuring w64devkit.exe to add more directories to the PATH 2 months ago

From Christopher Wellons to ~skeeto/public-inbox

> I can't really think of why this would be useful

I occasionally use invocations like "env - PATH=/usr/bin" on Linux, and
similar on Windows with w64devkit in order to establish a clean(er)
environment for testing and reproduction. I may even set a temporary HOME
to keep (most) programs from reading custom configs. In particular, some
application defaults are poor or newbie-oriented, the default can be
overridden by an environment variable — directly or indirectly — so I do
so. Then I eventually forget that I'm not running the default. It's an
easy way to wipe the slate clean.

For Windows this also means clearing out junk added to the environment by
various installers, which may interfere with issue reproduction. (A stray
PYTHONHOME or JAVA_HOME, etc.)

#### Re: Configuring w64devkit.exe to add more directories to the PATH 2 months ago

From Christopher Wellons to ~skeeto/public-inbox

Interesting, Peter, thanks! I'd been considering adding environment
variable arguments to w64devkit.exe, a la make and configure scripts:

w64devkit.exe HOME=C:\path\to\home PATH+=c:\git\cmd

You'd include such arguments in a shortcut target, then launch w64devkit
from that shortcut. There would also be syntax to compute an absolute path
from a path relative to w64devkit.exe (a la %~dp0), though I haven't
worked that out. That would be essential for your use case.

If one of the arguments is "-" (or maybe "-i"?) then it would delete all
environment variables, a la the "env" command, giving you a clean slate.
Though it might leave a couple special, soft-required variables behind
like SYSTEMROOT and TEMP, since many programs break badly when these are

From Christopher Wellons to ~skeeto/public-inbox

If it's not atomic then it's a data race since there's a concurrent store
and load on the same memory location, which simply isn't allowed. Even if
the result is provably correct for all possible orderings, it's still
undefined behavior. There may be unanticipated effects beyond reordering,
though no particular examples come to mind at the moment.

#### Re: Assertions should be more debugger oriented 3 months ago

From Christopher Wellons to ~skeeto/public-inbox

Quick followup: Simply searching for the title readily produces a 1st
edition PDF, which is exactly what I wanted. I have since finished reading
it, and I was very impressed. Your recommendation was sound and on point!

I don't agree with everything — particularly parts of the candy-machine
interfaces chapter — but overall it's full of great, practical advice.
It's provided me with more techniques for automatically findings bugs, and
I'm sure I'll be putting some of it into practice in the future.

#### Re: Assertions 3 months ago

From Christopher Wellons to ~skeeto/public-inbox

Thanks for the tips, Miguel!