Might want to check your git logs if you are using the Merge Queue feature. This afternoon, we found that Merge Queue was silently reverting changesets in the merge queue. Acknowledged by GitHub, but could be a very hard problem to debug if you aren't looking for it.
Yeah city is not fully a function of zip. ~I think state is though.~* I believe when multiple cities share a zip code USPS uses the larger one. Usually the wrong city will get delivered though, probably not guaranteed.
* correcting myself, some zip codes do cross state lines
It seems like they should be able to “overweight” newer training data. But the risk is the newer training data is going to skew more towards AI slop than older training data.
I don’t think you can do that. Or at least if you could, it would be an unintelligible version of English that would not seem much different from a programming language.
I like that agent-shell just uses comint instead of a full vterm, but I find myself missing a deeper integration with claude that claude-code-ide has. Like with claude-code-ide you can define custom MCP tools that run Emacs commands.
I went by it a few weeks ago. There's a gate on the driveway, and I assume some kind of security presence. Probably no different than anyone under constant public scrutiny.
I mean you can do it in Nix using overlays and overrides. But it won’t be cached for you and there’s a lot of extra fiddling required. I think it’s pretty much the same as how Bazel and Buck work. This is the future like it or now.
Package maintainers often think in terms of constraints like I need a 1.0.0 <= pkg1 < 2.0.0 and a 2.5.0 <= pkg2 < 3.0.0. This tends to make total sense in the micro context of a single package but always falls apart IMO in the macro context. The problem is:
- constraints are not always right (say pkg1==1.9.0 actually breaks things)
- constraints of each dependency combined ends up giving very little degrees of freedom in constraint solving, so that you can’t in fact just take any pkg1 and use it
- even if you can use a given version, your package may have a hidden dependency on one if pkg1’s dependencies, that is only apparent once you start changing pkg1’s version
Constraint solving is really difficult and while it’s a cool idea, I think Nixpkgs takes the right approach in mostly avoiding it. If you want a given version of a package, you are forced to take the whole package set with you. So while you can’t say take a version of pkg1 from 2015 and use it with a version of pkg2 from 2025, you can just take the whole 2015 Nixpkgs and get pkg1 & pkg2 from 2015.
It used to be you could buy fractions of a mutual fund, but not ETFs. Recently, brokerages have started allowed you to do fractional ETFs as well though.
I guess there's differing definitions. One definition was deciding you're going to quit, but not putting in any notice, and basically trying to delay getting fired as long as possible to collect a paycheck. Potentially even getting another job on top (overemployed), which sounds like it could be fraud.
In my experience, higher level of pay doesn't mean there's less coasters. Like, the $150k job could just as well have a lot more expectations than the $300k. Size of company seems like a much bigger factor: you can't hide your low productivity when there's only a few other engineers. And ironically, bigger companies can pay a lot more & get a lot less from their engineers for it.
You can just show the user the transliteration & have them confirm it makes sense. Always store the original version since you can't reverse the process. But you can compare the transliterated version to make sure it matches.
Debit cards a pretty common example of this. I believe you can only have ASCII in the cardholder name field.
Shouldn't it be even higher if you think your country is literally hell? Maybe they have a more optimistic idea of hell than me. I guess that squares with 3% more believing it's hell than wants to leave.
I still think this survey doesn't make sense, or at least something is lost in transactional.