jdxcode (u/jdxcode) - Readit News

jdxcode commented on Reverse engineering of Linear's sync engine github.com/wzhudev/revers... · Posted by u/flashblaze

notpushkin · 3 months ago

I’ve built a custom layout for that (and a bunch of other symbols I frequently use). ⌥ hyphen for en-dash, ⌥ ⇧ hyphen for em-dash (and ⌥ M is for minus): https://typo.ale.sh/

(The idea isn’t new, of course: the default macOS layout’s 3rd layer is absolutely bonkers. I think Ilya Birman was the first: https://ilyabirman.net/typography-layout/)

jdxcode · 3 months ago

those are the default macos keybindings for en-dash and em-dash characters

jdxcode commented on Splash-free urinals: Design through physics and differential equations academic.oup.com/pnasnexu... · Posted by u/yeknoda

wjnc · 4 months ago

This comes close to my hobby science of 20 yrs+! Toilet statistics! What distribution do people follow in choosing doors? Linear (no!), Negative Binomial (I think so, but which parameters? And do the number of stalls matter?), Gaussian? Do cleaners clean all stalls proportionally? Which urinal to choose? Never pick a neighbor? Is there an optimization there? Then the economics part…

Regarding OP. Splash isn’t the only factor in urinals alas. Ease of cleaning and the ability to stop junk. I’ve seen innovative splash less designs in bars. Usually a plastic cup upside down will seriously mess up the flow. People throw paper and gum and cigarettes in them. You need it splash free And robust.

jdxcode · 4 months ago

TFA does mention the fourth one is preferred in part because of cleaning. I think they wanted to show something that maximized for splash and a more realistic solution.

jdxcode commented on Python lock files have officially been standardized discuss.python.org/t/pep-... · Posted by u/ofek

kh_hk · 5 months ago

Very personal nitpick, but I don't like prefixing things with py, it makes no sense to me. A lock is a lock, so why a pylock.toml and not a lock.toml? You do what you want with it. Same with pyproject.toml

jdxcode · 5 months ago

because python isn't the only language?

jdxcode commented on China is developing some startling new kit in its quest to invade Taiwan economist.com/china/2025/... · Posted by u/_tk_

suraci · 5 months ago

weird that the economist uses the word 'reclaim' instead of 'invade'

jdxcode · 5 months ago

did the economist edit the title? it uses "seize"

jdxcode commented on uv downloads overtake Poetry for Wagtail users wagtail.org/blog/uv-overt... · Posted by u/ThibWeb

sureglymop · 5 months ago

The tool mise-en-place seems to have this. It is a replacement for asdf that I think can be used as a drop in replacement (compatible CLI interface).

jdxcode · 5 months ago

Yes you can sync versions python versions bidirectionally with uv and mise. I intend to make further deeper integrations with uv where possible directly into mise core in order to offload python complexity out of mise and into uv where possible.

jdxcode commented on Switching from Pyenv to Uv bluesock.org/~willkg/blog... · Posted by u/harryvederci

rsyring · 5 months ago

Mise does way more than uv, it's a much larger scope than just Python tooling.

I think the current status quo, that of mise utilizing uv for it's Python integration support, makes sense and I don't see that changing.

Also, FWIW, mise has other methods for Python integration support, e.g. pyenv, virtualenv, etc.

Edit:

Ha... Didn't realize who I was replying to. Don't need me to tell you anything about mise. I apparently misinterpreted your comment.

jdxcode · 5 months ago

the reality that I'm sure you've heard me say many times is that I'm just not a python dev and astral is likely always going to build a better solution around python than I ever could. They've just focused a lot more on the package manager side of things than the runtime/venv management side so far but I suspect that will change—and given astral's velocity I doubt we'll be waiting long

and btw mise's venv support isn't going anywhere probably ever, but I do hope that at some point we could either let uv do the heavy lifting internally or point users to uv as a better solution

jdxcode commented on Switching from Pyenv to Uv bluesock.org/~willkg/blog... · Posted by u/harryvederci

rsyring · 5 months ago

15 year Python dev who usually adopts tooling slowly. Just do it, uv's absolutely worth it.

I also use mise with it, which is a great combination and gives you automatic venv activation among other things.

See, among other mise docs related to Python, https://mise.jdx.dev/mise-cookbook/python.html

See also a Python project template I maintain built on mise + uv: https://github.com/level12/coppy

jdxcode · 5 months ago

ideally mise could be replaced entirely by uv or at least just be a thin wrapper around uv (in some ways that's already the case), but given this article requires the use of the custom uv-python-symlink utility it seems uv isn't quite there yet

jdxcode commented on Hk, a new Git hook manager hk.jdx.dev/about.html... · Posted by u/DrBenCarson

rounce · 6 months ago

The subject program doesn't seem to provide a way in which to specify the dependencies between hooks, hence they will just race each other assuming they are all fired off in parallel.

jdxcode · 6 months ago

in fact I do believe I have a solution to this problem. I should have this fully implemented soon but right now it is not.

First, I intend to be able to define simple "dependencies", but IMO that's not the interesting part.

I am going to use rw mutexes on every file with staged changes. If 2 steps are running against disjoint files there is no problem. If 2 steps are running against "check" (not "fix" which edit files by convention), they can also run at the same time. The only scenario where blocking is necessary is when you have 2 "fix" or 1 "check" and 1 "fix" on an intersection of their files.

For that scenario there is going to be a setting that you can enable to run a steps "check" command first (only if this scenario is about to happen, if no files will be in contention it will simply run "fix"), and if "check" fails, then it will switch to "fix".

This is my current idea and in my head I think it would work. There are caveats, notably running "check" and then "fix" might be slower than just waiting and running "fix" once which is why it needs to be optional behavior. You also may not care about things stomping on each other (maybe the linters themselves have their own locking logic).