joppy

The commenter says pre-rendered/server-side-rendered mathematics (via katex) is great - I’ve found the opposite. It’s probably great if you have an article with one or two equations. On the other hand, if you have an article which uses mathematics pervasively, like many pure mathematics articles, it quickly becomes far more space efficient to render the mathematics on the client side. You can quickly get 200kB+ pages by pre-rendering.

“Pixi instead of uv” would be a more fair comparison, as Pixi is a more modern tool which still uses the conda package format and ecosystem, much like uv is a modernised pip which still uses the PyPI package format.

One thing an conda package can do which an PyPI package cannot is have binary dependencies: a conda package is linked upon installation, and packages can declare dependencies on shared libraries. As common example is numeric libraries depending on a BLAS implementation: in a conda/pixi environment you will get exactly one BLAS shared library linked into your process, used by numpy, scipy, optimisers, etc. For some foundational libraries like BLAS which have multiple implementations, the user even has the power to consistently switch the implementation within the environment, eg from OpenBLAS to Intel’s MKL.

The PyPI package format does not allow binary dependencies: wheels must be self-contained when it comes to binary code (not when it comes to Python code - which hopefully makes it clear that something here is inconsistent). Take any numerical python environment and enumerate the copies of BLAS you have, it is probably 3-5. All running their own threadpools.

Another very simple example is with inbuilt modules depending on native code, like the sqlite3 module. In a conda/pixi installation you are guaranteed that the python binary links against the same sqlite3 code as the command-line sqlite3 cli tool in the same environment. Stuff like this removes many cross-language or cross-tool hassles.

I prefer uv or poetry if I’m doing anything simple or pure python (or perhaps with a small binary dependency like an event loop). But pixi is the way to go for large environments with lots of extra tools and numerical libraries.

Title: this is about the geometric Langlands, not Langlands. They are related but in separate fields.

If a country has the capability to "lock down ports", they're probably shipping ports - do you think Australia is just suddenly going to (or has the capability to) block all IP traffic on certain ports? A notable exception is China.

Thanks for making this! I’ve found that as a pedestrian in Sydney, up to half my walking time is spent waiting for traffic lights, and have always wondered what could be done about it.

Use pipx. It works well.

The compare-how-big-a-lookup-table-is argument is a bit of a red herring for comparing how complex things are. For example, a 3x3 matrix implements a map from 3 floats to another three floats, a huge space of possibilities (if we have 4-byte floats, this function space has (2^96)^(2^96) elements). From this perspective, representing that map as 9 numbers is an amazing compression ratio. But surely one cannot argue that matrices “have more going on” than arbitrary functions.

The Mazda software works ok with the wheel, but using something like CarPlay with it is almost impossible without taking your eyes off the road for a long time. It’s worse than touch-screens in that respect: what will the spinning knob select next on a screen which has three separate panes?

There a lots of tiny issues: some UI settings like rulers (or whatever PyCharm calls them, vertical guides that tell you when you’re at 100 chars or something) just don’t work, and don’t show up in the main editor (but they show up in the diffs!). Some editor settings, like the main Python settings pane, just doesn’t load its settings page, and requires restarting the editor. Scrolling diffs with the scroll wheel is so janky and laggy to be unusable, but the main editor scrolls fine. Reconnecting after a short disconnect (open and close laptop lid) takes too long. The git client gets itself into a weird state sometimes where it will create the same 5 files no matter which branch I switch to, and the only way I’ve found to reset that is to delete every trace of IntelliJ off the remote and reconnect.

The IntelliJ git interface makes a lot of sense, and makes many helpful operations easy, like “compare what I have now to this particular commit”. The VSCode git interface, even with plugins like GitLens, seems to make these operations hard to get to, and how VSCode manages diffs with the staging area involved is totally bananas.

Aside from that, PyCharm has a slightly better debugging interface but otherwise it’s quite close to VSCode for Python development. Sane version control is a bit aside though.

I hope they also worked on removing the many UI bugs from PyCharm remote: laggy scrolling while in the diff view, some editor settings like rulers at 100/120 chars not working properly, some settings panes lagging out until the editor is restarted, etc etc. I need to develop on a remote VM and I’m using VSCode at the moment because it’s remote story is less buggy, but would much rather be using PyCharm.

At LAN parties we used to share our SteamApps folders so that others could copy games across. Interestingly (perhaps due to Windows networking handling copy-many-small-files poorly?) it was often faster to make an uncompressed ZIP of the files, copy that over the network, and unzip it on the other side.

Great to see that the steam client now does all this transparently.

Unfortunately it doesn’t work so well with some larger games. I tried backing up a 120GB up-to-date game, uninstalling and reinstalling steam (to a newly purchased drive), and reloading the game from backup. It still wanted to download 90GB.