PyPy isn't unmaintained. We are certainly fixing bugs and are occasionally improving the jit. However, the remaining core devs (me among them) don't have the capacity to keep up with cpython. So for supporting new cpython versions we'll need new people to step up. For 3.12 this has started, we have a new contributor who is pushing this along.

The text merged to the documentation is more concise than the PR title:

> not actively developed anymore

The English term for 'Bildungsroman' is actually... 'bildungsroman' https://en.wikipedia.org/wiki/Bildungsroman

Complaining about a rest (however long) in a piece by the composer of 4'33'' is certainly A Take.

This is really fun, I'm getting badly nerd sniped by this.

It's been 4 hours already. How are you doing? Didn't forget to eat and drink? Just checking in on you :)

The equivalent of this (and strongly inspired by luajit's ffi) in the python world is cffi, btw: https://cffi.readthedocs.io/en/stable/

Oh, thanks! That's a second thing in this thread I'm embarrassed to have not known already. Does it get native-like performance in PyPy the way LuaJIT's FFI does? I'll have to try it with Yeso to see if it's an improvement.

It should get pretty good performance yes. Not sure how native like we get with the jit. Gut feeling would be a bit slower than gcc -O0? I would be very interested in your experience if you do try it.

Thanks! I guess now I've assumed the obligation. Probably I should look for you on Mastodon in order to tell you about my experience?

And a significant chunk of these important extension libraries are supported in pypy using the emulated C-extension api (cpyext)

Right, the performance cost of cpyext is what we're contrasting with ctypes-like approaches like LuaJIT's FFI in this thread. In https://news.ycombinator.com/item?id=42656395 Antonio Cuni linked the standard explanation of why cpyext is so slow and also HPy, which I'm embarrassed to say I didn't know about.

Yeah, that's exactly right. It's operating on an SSA-based intermediate representation. So if an operation gets removed, the arguments are still being computed. The earlier operations that produce those arguments can also be removed by dead code elimination (which runs later), but indeed only if they have no side effects.

I suppose the notation of the rule heads makes it look like there actually are expression trees, which is maybe sort of confusing.

I only support integer operations in the DSL so far.

(but yes, turning the python expression x*y+z into an fma call would not be a legal optimization for the jit anyway. And Z3 would rightfully complain. The results must be bitwise identical before and after optimization)

Does Z3 distinguish between x*y+z and z+y*x, in terms of floating point output?

math.fma() would be a different function call with the same or similar output.

(deal-solver is a tool for verifying formal implementations in Python with Z3.)

Yeah, that's a good point!

The 'empty' parts of the beginning of the program are actually a 'configure' phase, where the program runs a bunch of subprocesses (C compiler with small query programs) and the vm is mostly waiting for the results of that. That's why there are pauses in the coins.

On the other end, I also artificially limit the samples to 10 coins a second (iirc), because if the jit is really compiling a lot it would be just too annoying.

Good idea! There are various other extensions possible.

Unfortunately there's a bit of an observer effect, the sounds are made with python code running in the same process, and the more complicated I made the sound generation logic, the more garbage it produces itself .