Use a connection per-thread instead. By sharing a connection across threads you’ll be limiting concurrency - and transactions won’t work as you’d expect. SQLite connections are not heavy.

Also: use WAL mode and enable mmap.

Retries won’t work in that case. Would be better to have two endpoints: get the time in x seconds and wait until time passed. That way retrying the wait endpoint will work fine and if time hasn’t elapsed it can just curl itself with the same arguments.

What stickers did you used to have? I'm always fascinated with how people change their mind.

I used to have Pokemon stickers on my laptop.

I still do, but I used to, too.

Looks like it's caused by `backdrop-filter: blur(6px);` on `.menu-content`. After disabling that it's slow, but not that slow.

Edit: This is with Firefox 144 on Ubuntu 22.04

No, actually the biggest difference is removing the `filter` property from the `.wave2` class which is used for rendering the background. With that removed the page is responsive even with the backdrop-filter - and it makes no visual difference AFAICS.

Thanks folks for all the suggestions, I've rewritten the whole page :)

It's also perfectly responsive if you disable JavaScript. Maybe something related to the --positionX and --positionY CSS variables that are updated on every mouse move?

Even with volatile it’s a load and then a store no? It may not be undefined behaviour, but I don’t think it will be atomic.

You're correct. If you have:

  public int someField;
 
  public void inc() {
    someField += 1;
  }

that still compiles down to:

  GETFIELD [someField]
  ICONST_1
  IADD
  PUTFIELD [somefield]

whether 'someField' is volatile or not. The volatile just affects the load/store semantics of the GETFIELD/PUTFIELD ops. For atomic increment you have to go through something like AtomicInteger that will internally use an Unsafe instance to ensure it emits a platform-specific atomic increment instruction.

> SSH is a "legacy protocol" and its users are "uneducated troglodytes",

Who are you quoting here?

I assume that's a parody on systemd developers' attitude towards The Unix Way (TM).

This github issue comes to mind:

https://github.com/tmux/tmux/issues/428

With jinja you’d use template inheritance and just update the base template for this:

https://jinja.palletsprojects.com/en/stable/templates/#templ...

sure, that's just one of the many frameworks or tools i could use. the point is, there is no way to do that without any processing, either on the server or in the browser.

And also:

> and so have 4 different libraries they rely on

HTMX has no dependencies. https://htmx.org/essays/vendoring/

> and actually the most up to date version of two libraries you rely on are not interoperable right now because they depend on different node versions

HTMX has no build step. https://htmx.org/essays/no-build-step/

> Its always funny when i see these kinds of posts.

What's funny about it?

Basically that you list the obvious benefits we knew since the 70s (in a new blogpost).

Its a form of re-discovery, and im happy people "find" the joy of it.

Rust borrows heavily from the other ml's and thats why many like it, not realizing there is decades of research behind the whys.

It’s not about ‘this’ being a global, it’s if you see ‘i++’ in code it’s not obvious if ‘i’ is a member or not without having to check context.

If you see "i++" in code and you don't have any context about what "i" is, then what difference does it make if "i" is a member variable, global variable, parameter, etc etc...

If all you see in code is a very tiny 3 character expression, you won't be able to make much of a judgement about it to begin with.

Not allowing a variable to implicitly refer to a member variable makes it much easier to find. If it is not declared in the function and there is no implicit dereferencing of a this pointer, the variable is global. If the variable name is commonly used and it is a member variable, it is a nightmare to hunt for the correct declaration in the codebase with cscope.

Good point. I had misunderstood the previous comment as suggesting that this be passed to the member function as an explicit argument, rather than requiring dereferences of this be explicit. The latter makes far more sense and I agree it makes reasoning about things much easier.