Almost all of Theo’s communications are straightforward and polite. It’s just that people cherry-picked and publicized the few occasions where he really let loose, so he got an undeserved reputation for being vitriolic.

Pleasantly surprised, even.

I’m going to go ahead and postulate that if you tried to rip a waffle three hundred times, at some point during that process the bit stream would start to diverge wildly as mould grows on it, pieces get flung away by rotation and eventually it rots.

The fact that he was able to get 13 copies (even out of 300) that have the same CRC suggests that there’s something real there. That wouldn’t happen by chance.

And thinking about it no, you couldn’t rip a waffle. For a CD drive to read anything at all it has to see pit/land transitions every 3 spaces (at least) at something approximating the correct rate. A random physical object would just have no signal at all and you’d know there was no signal, like trying to receive digital radio when there’s no carrier wave.

In Python 2.7, you can do this by constructing a new code object and assigning it to a function’s func_code attribute. The function’s func_name is ignored by the traceback generation. Still, no eval necessary!

Running this:

from types import CodeType

def make_raiser(name, lineno, filename, type_to_raise):
    def raises():
        raise type_to_raise()
    co = raises.func_code
    raises.func_name = name
    raises.func_code = CodeType(
        co.co_argcount,
        co.co_nlocals,
        co.co_stacksize,
        co.co_flags,
        co.co_code,
        co.co_consts,
        co.co_names,
        co.co_varnames,
        filename,
        name,
        lineno - 1,
        co.co_lnotab,
        co.co_freevars,
        co.co_cellvars,
    )
    return raises

foo = make_raiser('foo', 3, 'foo.rs', lambda: IndexError(0))
bar = make_raiser('bar', 4, 'bar.rs', foo)
bar()

with python2.7 gives me this output:

$ python2 maketraceback.py 
Traceback (most recent call last):
  File "maketraceback.py", line 27, in <module>
    bar()
  File "bar.rs", line 4, in bar
  File "foo.rs", line 3, in foo
IndexError: 0

For Python3, there’s one extra argument to the CodeType constructor, so it’s just:

from types import CodeType

def make_raiser(name, lineno, filename, type_to_raise):
    def raises():
        raise type_to_raise()
    co = raises.__code__
    raises.__name__ = name
    raises.__code__ = CodeType(
        co.co_argcount,
        co.co_kwonlyargcount,
        co.co_nlocals,
        co.co_stacksize,
        co.co_flags,
        co.co_code,
        co.co_consts,
        co.co_names,
        co.co_varnames,
        filename,
        name,
        lineno - 1,
        co.co_lnotab,
        co.co_freevars,
        co.co_cellvars,
    )
    return raises

foo = make_raiser('foo', 3, 'foo.rs', lambda: IndexError(0))
bar = make_raiser('bar', 4, 'bar.rs', foo)
bar()

and output looks the same:

$ python3 maketraceback3.py 
Traceback (most recent call last):
  File "maketraceback3.py", line 29, in <module>
    bar()
  File "bar.rs", line 4, in bar
  File "foo.rs", line 3, in foo
IndexError: 0

Yes, this is what I’m planning for the next post :)

A potentially interesting challenge: What does a design language for maker-first applications look like?

P.S. compared with “hipster” modernist things of ~2010

What do you mean by this

I can’t install pocketsphinx on the system I’m typing this on, but this should work. Well, it may not be perfectly accurate, but its a transcript :D

wget https://cdn.changelog.com/uploads/podcast/194/the-changelog-194.mp3 -O /tmp/file.mp3 && ffmpeg -i /tmp/file.mp3 -ar 16000 -ac 1 /tmp/file.wav && pocketsphinx_continuous -infile /tmp/file.wav 2> pocketsphinx.log > ~/result.txt

And then just read ~/result.txt for the transcript.

AC seems like an application that would really benefit from always-listening voice control.

Instead of switching on and off with commands like “AC on” and “AC off”, it should be programmed to respond to either “fuck me it’s hot” or “aaaaa the day-star it burnsssss” to switch on and and “brrrrr” to deactivate.

it’s hard to reach for the mouse

For this reason I have vi keybindings in all the programs I use most. It’s not a productivity thing, I just really dislike taking my paws off home row to reach for a pointing device.

SIGUSR1 has an nasty disadvantage relative to SIGINFO: by default it kills the process receiving it if no handler is installed. 🙁 The behavior you really want is what SIGINFO has, which is defaulting to a no-op if no handler is installed.

• I don’t want to risk killing a long-running complicated pipeline that I was monitoring by accidentally sending SIGUSR1 to some process that doesn’t have a handler for it
• there’s always a brief period between process start and the call to signal() or sigaction() during which SIGUSR1 will be lethal

On BSD it’s part of the TTY layer, where ^T is the default value of the STATUS special character. The line printed is actually generated by the kernel itself, before sending SIGINFO to the foreground process group. SIGINFO defaults to ignored, but an explicit handler can be installed to print some extra info.

I’m not sure how equivalent functionality could be done in userspace.

Nice! About the leftward bit propagation: can you do multiplication modulo a compile time constant fast? If you compute (((x * constant1) % constant2) % (1<<32)) where constant1 is the aforementioned constant with lots of ones, and constant2 is a prime number quite close to 1<<32 then that would get information from the upper bits to propagate into the lower bits too, right? Assuming you’re okay with having just slightly fewer than 1<<32 hash outputs.

(Replace 1<<32 with 1<<64 above if appropriate of course.)

So does that mean that when the author says Dinkumware’s FNV1-based strategy is too expensive, it’s only more expensive because FNV1 is byte-by-byte and fibonacci hashing multiplying by 2^64 / Φ works on 8 bytes at a time?

Does that mean you could beat all these implementations by finding a multiplier that produces an even distribution when used as a hash function working on 8 byte words at a time? That is, he says the fibonacci hash doesn’t produce a great distribution, whereas multipliers like the FNV1 prime are chosen to produce good even distributions. So if you found an even-distribution-producing number for an 8 byte word multiplicative hash, would that then work just as well whatever-hash-then-fibonacci-hash? But be faster because it’s 1 step not 2?

A fair point that came up over on HN is that people mean really different things by “hash” even in non-cryptographic contexts; I mostly just meant “that thing you use to pick hashtable buckets.”

In a trivial sense a fixed-size multiply clearly isn’t a drop-in for hashes that take arbitrary-length inputs, though you can use multiplies as a key part of variable-length hashing like xxHash etc. And if you’re judging your hash by checking that outputs look random-ish in a large statistical test suite, not just how well it works in your hashtable, a multiply also won’t pass muster. A genre of popular non-cryptographic hashes are like popular non-cryptographic PRNGs in that way–traditionally judged by running a bunch of statistical tests.

That said, these “how random-looking is your not-cryptographically-random function” games annoy me a bit in both cases. Crypto-primitive-based functions (SipHash for hashing, cipher-based PRNGs) are pretty cheap now and are immune not just to common statistical tests, but any practically relevant method for creating pathological input or detecting nonrandomness; if they weren’t, the underlying functions would be broken as crypto primitives. They’re a smart choice more often than you might think given that hashtable-flooding attacks are a thing.

If you don’t need insurance against all bad inputs, and you’re tuning hard enough that SipHash is intolerable, I’d argue it’s reasonable to look at cheap simple functions that empirically work for your use case. Failing statistical tests doesn’t make your choice wrong if the cheaper hashing saves you more time than any maldistribution in your hashtable costs. You don’t see LZ packers using MurmurHash, for example.

Small suggestion: use a darker, bigger font. There are likely guidelines somewhere but I don’t think you can fail with using #000 for text people are supposed to read for longer than a couple of seconds.

I think the byte-order argument doesn’t hold when you mentioned ntohs and htons which are exactly where byte-order needs to be accounted for…

Right. “This is a feature of the standard library!” means something entirely different in C++ than in other programming languages.

Can you make it much less of a headache by defining a generic function that takes a lambda, calls it in a try/catch, returns the successful value from the try branch, returns nullopt from the catch?

To be honest we are already in that situation.

You can’t really use GL on mac, it’s been stuck at D3D10 feature level for years and runs 2-3x slower than the same code under Linux on the same hardware.

It always seemed like a weird decision from Apple to have terrible GL support, like if I was going to write a second render backend I’d probably pick DX over Metal.

To be clear, and a little pedantic, Lua =/= Luajit.

Even if your compiler emits exclusively SSE instructions for actual arithmetic, the de-facto-standard calling conventions on x86 (but not x86-64), cdecl and stdcall, return floating-point values from functions by sticking them onto the x87 FPU stack. So there will still be a handful of x87 instructions emitted solely to push/pop the FPU stack, even if no other x87 features are used, which seems to be what’s happening here. That convention was set ages ago and changing it would break ABI compatibility.

I saw a talk about this. Very cool stuff! It is a good antidote to the thrall of benchmarks.

Cool work! You should make that a submission on its own in the morning in case someone misses it due to a filter. For instance, people who don’t care about Python specifically like main post is tagged with. Just programming, performance, and compiler tags should do. Good news is a lot of people still saw and enjoyed it per the votes. You definitely deserve an “authored by” submission, though. :)

Added to rtss - stderr of the child still goes to stderr, so redirection works as you’d expect.