I have taken a (short) look at KOReader and saw that there's an instructions page on its wiki on how to install it on the rM2; it still uses rm2fb but it suggests using timower's version, which works on newer versions of the OS. What I should've made more clear in the post was that there are options, they're just less convenient to use because Toltec doesn't work.
Bluesky lets you select the language your post is written in before posting it and it is attached as metadata to the skeet. I guess the backend for this only searches posts in English, but it's possible the dataset is not 100% accurate due to some users forgetting to switch language before posting.
Turns out I managed to use almost all of these during a refactor of a project at work, even metaclasses... (Metaclass usage is justified in my case: we have a sort of language evaluator and using a metaclass lets us define function arguments with their types and validators in a very coincise and obvious way similar to Pydantic.)
I think this list should also include descriptors[0]: it's another metaprogramming feature that allows running code when accessing or setting class attributes similar to @property but more powerful. (edit: nvm, I saw that they are covered in the proxy properties section!)
I think the type system is quite good actually, even if you end up having to sidestep it when doing this kind of meta-programming. The errors I do get are generally the library's fault (old versions of SQLAlchemy make it impossible to assign types anywhere...) and there's a few gotchas (like mutable collections being invariant, so if you take a list as an argument you may have to type it as `Sequence[]` or you'll get type errors) but it's functional and makes the language usable for me.
I stopped using Ruby because upstream would not commit on type checking (yes I know you have a few choices if you want typing, but they're a bit too much overhead for what I usually use Ruby for, which is writing scripts), and I'm glad Python is committing here.
Some points about the introduction, but otherwise this seems like an interesting collection of (slightly deranged?) patterns in C.
> The truth is that any reasonably complicated software system created by humans will have bugs, regardless of what technology was used to create it.
"Drivers wearing seatbelts still die in car accidents and in some cases seatbelts prevent drivers from getting out of the wreckage so we're better off without them." This is cope.
> Using a stricter language helps with reducing some classes of bugs, at the cost of reduced flexibility in expressing a solution and increased effort creating the software.
...and a much smaller effort debugging the software. A logic error is much easier to reason about than memory corruption or race condition on shared memory. The time you spend designing your system and handling the errors upfront pays dividends later when you get the inevitable errors.
I'm not saying that all software should be rewritten in memory-safe languages, but I'd rather those who choose to use the only language where this kind of errors regularly happens be honest about it.
I spent a good while looking at the image on my phone trying to spot what the author was talking about, but ironically the comparison image itself is compressed (not using a NN ;) ) and that obscures the artifacts you're supposed to be looking at.
If you're looking for examples of ringing and hallucinated details, they're really obvious in the framed picture on the right on respectively the character's shirt and the frame.
Sounds like you'd enjoy using JJ! It looks to me that you have this workflow to work around git's poor tooling for manipulating local commits before pushing. JJ makes that very easy!
Forgot to add something to a previous commit? Run "jj squash -i" to move the lines you select to whatever commit you want. Or you can run "jj edit" to check out that commit and edit it directly.
Want to split a commit into two separate commits? Run "jj split".
Need to reorder commits? Run "jj rebase", and if you have a conflict you can "jj edit" the commits that are marked as conflicted to fix it later, unlike Git where you have to run through a lengthy process of fixing conflicts on commits you don't remember and then review the changes later to see whether they still make sense.
If you want to have a messy working copy of your repo that's very easy to do. The workflow would mostly involve:
- Develop the feature
- "jj split" to pick out the stuff you need into a separate commit, which will appear between master and the working copy commit
- "jj describe" to add a commit message
- "jj bookmark set feature-branch" on the commit containing the stuff you want to push
- "jj git push" to push it
- "jj edit" to return to the commit containing the working copy.
You'd end up with a tree that looks kind of like this:
JJ doesn't currently have a "native" repository format (or rather, it's in development and not ready for general usage), so right now a JJ forge wouldn't look too different from your usual Git forges.
Everybody who's using it right now uses it on Git repos on Git forges. I've been using it for months on my own and at work and I didn't make any changes to the infrastructure outside of my own command line usage.
It would be interesting to see what a JJ-native forge would even look like in the future, but I don't think anybody knows exactly what that would be right now! JJ is in development (but stable enough to work with) and people have only just started using it, so it's still in the phase of discovering what workflows are possible.
> Plus a good IDE support.
Now that's something I would love to see. Git tooling works mostly fine but due to how JJ's git backend works, it always thinks it's in a "detached HEAD" state.
I have taken a (short) look at KOReader and saw that there's an instructions page on its wiki on how to install it on the rM2; it still uses rm2fb but it suggests using timower's version, which works on newer versions of the OS. What I should've made more clear in the post was that there are options, they're just less convenient to use because Toltec doesn't work.