omarandlorraine

It's an import error actually; debian seems to not ship python-pygments in the standard repositories. Perhaps they stopped shipping it with Bullseye. But of course, they *do* ship python3-pygments. EDIT:...

>That is OK. Use python3 in all the shebangs. I've changed all the shebangs that had python to python3

Gah! I realize now the branch is marred by the inclusion of commits from my other PR. Let me know if there's a problem here and I'll try to right...

Could you maybe pipe the results through sed and whatever to achieve this?

Looks like the locus of the bug is line 826 of mos6502.cpp. But also, I don't know if C++ actually defines the order in which those reads happen. Can anyone...

>since the idea of constant for these variables is a convention in Python which doesn't stop you from re-assigning. Huh? Isn't a big point of a linter to warn you...

> The discussion become highly similar to #3585. It's hard/impossible to know if something is a constant or not for a module level variable. Right now we rely on mutability...

I've just checked, there is no warning for module-level variables in SCREAMING_SNAKE_CASE coming after classes or module-level functions. Is this a problem?

I've discovered another memory leak ``` loop { load_ttf_font(&"/path/to/font.ttf").await.unwrap(); } ``` Unlike `Texture2D`, there is no such method as `.delete` on a `Font` object. so I don't have a workaround...

>So currently Texture2D::clone() just clones the pointer to a texture, and not the texture itself. This would need to be fixed as well. It seems like a different, maybe unrelated...