Nostr notes by Grégoire Locqueville

Fascinating, thank you!

2026-10-28T11:30:24Z

In reply to nevent1q…gssl
_________________________

Fascinating, thank you!

I've always found it striking how this gif resembles the ...

2026-10-28T11:20:56Z

In reply to nevent1q…v6j3
_________________________

I've always found it striking how this gif resembles the approximation of a (discontinuous) periodic function by its Fourier series, but I don't know enough about number theory to know how deep the connection is. Based on your use of the phrase "constructive interference" I guess there is at least *some* connection...

Let me answer that one question, though: > Can you say the ...

2026-10-23T22:39:28Z

In reply to nevent1q…88sr
_________________________

Let me answer that one question, though:

> Can you say the same of Typst?

Of course I can't. I'm not claiming Typst, a 4(?) year old project, is more stable than LaTeX. What I can say is:
* Typst has given me an impression of thoughtfulness and robustness from the start.
* It solves the many pains I always had with LaTeX (and I have written a Ph.D. thesis with LaTeX — not the most typographically demanding, but still, I'm not a novice)
* It's not a huge deal for me if my documents don't compile 5 years from now, or if the tool I use to compile them needs some reasonably standard, if not minimal, toolchain to itself compile. Sure, something as portable and stable as TeX would be nice. But if I retain 1. the compiled document itself, which is what I care about first and foremost, and 2. the document Typst source, which IMO is much more readable and understandable than LaTeX source, I personally consider that sufficient preserved information, even if the tool that was used to go from the later to the former was lost/rendered unusable.

Ok I think I understand your point. I understand that being ...

2026-10-23T21:55:33Z

In reply to nevent1q…gp90
_________________________

Ok I think I understand your point. I understand that being "nominally open source" isn't the be all end all of software, but IMO your initial criticism lacked specifics to the point of being misleading.

From what I understand, all your concerns are related to Typst being written in Rust. I don't think I'm alone in not immediately identifying the Rust compiler as a potentially problematic dependency (with how standard it's become). It would have helped being more specific.

Did you perhaps miss that Typst (the web app) relies on the ...

2026-10-23T21:15:48Z

In reply to nevent1q…fl5r
_________________________

Did you perhaps miss that Typst (the web app) relies on the `typst` self-contained executable, whose source is released under the FOSS Apache license, and whose (command-line) interface is dead simple? Otherwise I have no idea what you're talking about... (this is a genuine question by the way)

I feel like in languages (at least those with an expressive type ...

2026-10-15T10:29:50Z

In reply to nevent1q…xmdd
_________________________

I feel like in languages (at least those with an expressive type system), the pain of remembering syntax pretty much disappears thanks to static analysis tools (typically, LSP servers) that catch syntax errors, and more, in real time.

In contrast, there's a very real pain in setting up new tools and technologies, having them talk to each other, understanding why some piece of technology you're not supposed to worry about does not behave as expected... — in a nutshell, leaving the comfort of a well-identified language or technology. The issue in the thread you quoted is an example of that pain.

Ever wanted to make a game that takes place in a procedurally ...

2026-06-20T16:56:30Z

Ever wanted to make a game that takes place in a procedurally generated world, but don't want to deal with the hassle of instantiating chunks as your player moves?

With my #fernweh library for #bevy, you declaratively define what chunks are made of, using the brand new Bevy scene system, and fernweh takes care of asynchronously computing and spawning/despawning them as needed.

Fernweh is *very* generic: it doesn't care if your game is 2D, 3D, or whatever else. *You* get to decide how to refer to chunks, *you* get to decide what chunks should be visible at what point, and chunks may be composed of *anything* that can be represented as a Bevy scene, that is, pretty much anything you could want (meshes, colliders, audio sources...).

https://crates.io/crates/fernweh

#rust #RustLang #BevyEngine #procgen #ProceduralGeneration #bsn

Does it really qualify as microtonality when there's no ...

2026-04-10T23:10:44Z

In reply to nevent1q…aazq
_________________________

Does it really qualify as microtonality when there's no precise target pitch, though?
John Carlos Baez (npub1nf4…nqe4)

It seems that installing audio plugins on #NixOS is its own can ...

2026-01-25T18:23:47Z

It seems that installing audio plugins on #NixOS is its own can of worms 🙃

What do you mean? Doesn't ``` someArray.join(", ", ...

2026-01-20T07:51:28Z

In reply to nevent1q…xvz8
_________________________

What do you mean? Doesn't
```
someArray.join(", ", last: ", and ")
```
work?

It's honestly shocking how charitable the people in that ...

2025-11-28T22:30:57Z

In reply to nevent1q…2eh6
_________________________

It's honestly shocking how charitable the people in that thread are, with some spammer who basically just dumped tens of thousands of lines of code that he has not even bothered to understand (let alone write) and expects them to review it...

Unless I'm missing something, you need as many steps as you ...

2025-07-07T22:26:04Z

In reply to nevent1q…y7sv
_________________________

Unless I'm missing something, you need as many steps as you have elements, minus the number of elements that remain unchanged:
- You "obviously" need at least as many steps, because otherwise there would be an element that does not change
- You need at most as many steps, because you can decompose any permutation into a product of cyclic permutations with disjoint orbits, and you can apply your little algorithm for cyclic permutations for each of those

Ok but I still don't get why he should "see her at a ...

2024-11-30T13:02:24Z

In reply to nevent1q…5rk3
_________________________

Ok but I still don't get why he should "see her at a close distance"?

> Bob will eventually see her at a close distance I don't ...

2024-11-30T11:50:46Z

In reply to nevent1q…set4
_________________________

> Bob will eventually see her at a close distance

I don't think so. From Bob's conceptual perspective, Alice's progress is stalled near the horizon only as long as Bob is a distant observer. Once he approaches the black hole, there's a time on his clock at which he can say she's crossed the horizon, even though the light of Alice crossing the horizon hasn't reached him yet.

I assume "question 2" refers to your question about Alice ...

2024-11-30T11:20:43Z

In reply to nevent1q…zd54
_________________________

I assume "question 2" refers to your question about Alice being flattened in my scenario where you follow her from a short distance. But in that scenario I was assuming you were following her from close enough (compared to the size of the black hole), at the same speed.

If you go slow enough and leave enough space between some ships and you that you start to see them flatten, I think (not 100% sure of that) you will still see them flat (but not infinitely flat!) while you're crossing the horizon. But I may be wrong, and you might see them progressively get (some of) their thickness back as you're approaching the horizon.

Either way, I don't see anything paradoxical?

Correct @npub1nf4…nqe4 @npub12cu…d38p

2024-11-30T07:06:40Z

In reply to nevent1q…edzz
_________________________

Correct
John Carlos Baez (npub1nf4…nqe4) Greg Egan (npub12cu…d38p)

I think you need to make it clear if the observer is going into ...

2024-11-30T00:40:02Z

In reply to nevent1q…60r6
_________________________

I think you need to make it clear if the observer is going into the black hole with the object or not.

1. If not, then yes they will be seeing the object flatten above the horizon to avoid crossing it.

2. If they are going into the black hole too, then things will look normal, and they will see the object cross the horizon just while they are crossing it themselves (see my other toot).

3. If they follow the object, but accelerate backwards enormously at the last minute, to avoid crossing it, then they will first be seeing a normal image of it before it crossed the black hole (see my previous toot), then after the backwards acceleration they will suddenly see it flattened because their relative speed will have become suddenly high.

You can try to imagine all kinds of scenarios like that, and the answer will generally be somewhere on the spectrum between 1. and 2.

John Carlos Baez (npub1nf4…nqe4) Greg Egan (npub12cu…d38p)

Just so we're clear: you're suggesting that the bacterium ...

2024-11-27T21:27:26Z

In reply to nevent1q…gw5x
_________________________

Just so we're clear: you're suggesting that the bacterium in my eye shoot a tiny laser towards my nose, on which a tiny mirror will have been placed, allowing the laser light to bounce on it and get back to my eye; and that the bacterium measure the time (on its clock) between the moment it shoots the laser and the moment it gets its light back. Right?

Now you say my nose is "receding", and my eye is "running towards" it — but what frame of reference are we talking about now? I thought we were talking about my local frame of reference, in which neither my eye nor my nose are moving! If we're talking a distant observer's point of view, we've already established they do indeed think I am flattened!

John Carlos Baez (npub1nf4…nqe4) Greg Egan (npub12cu…d38p)

What experiment do you suggest I do, once near the horizon, to ...

2024-11-27T21:07:44Z

In reply to nevent1q…a790
_________________________

What experiment do you suggest I do, once near the horizon, to measure the thickness of my nose in my frame of reference?
John Carlos Baez (npub1nf4…nqe4) Greg Egan (npub12cu…d38p)

No, the bacterium is also flattened (from the point of view of a ...

2024-11-27T18:34:19Z

In reply to nevent1q…3lca
_________________________

No, the bacterium is also flattened (from the point of view of a distant observer), along with its local environment, including my nose, and thus it does not notice that my nose is flattened — there's no local experiment it can perform to determine that my nose is in fact flat, any more than it could in space away from the black hole.

It's the exact same in special relativity. If you and I were flying close to light speed relative to each other, from the perspective of each of us the other would be flattened, yet we wouldn't think of ourselves as flattened.

John Carlos Baez (npub1nf4…nqe4) Greg Egan (npub12cu…d38p)

Your first paragraph is correct *as long as you're looking ...

2024-11-27T18:07:20Z

In reply to nevent1q…acvj
_________________________

Your first paragraph is correct *as long as you're looking from far enough from the horizon*.

The second paragraph is incorrect. Locally, you are still in euclidean spacetime before, during, and after your crossing of the *event horizon*; this only becomes false as you approach the *singularity*.

Sure, if you're close to the horizon, people far away from the black hole do see you flat and redshifted, but you don't agree with them!

John Carlos Baez (npub1nf4…nqe4) Greg Egan (npub12cu…d38p)

The first ship does actually "wait for you", i.e. its ...

2024-11-25T23:47:50Z

In reply to nevent1q…wage
_________________________

The first ship does actually "wait for you", i.e. its clock slows down relative to yours and it slows down so much it appears to stop at the even horizon — that is, until you go to the event horizon yourself.
(It also gets redshifted more and more to the point you can't see it anymore — again, until you go to the event horizon yourself)

If Bob could see the horizon, at the moment he crossed it, he ...

2024-11-25T18:18:02Z

In reply to nevent1q…gt4x
_________________________

If Bob could see the horizon, at the moment he crossed it, he would see it in front of him, overlapping him, and behind him all at once, like an invisible wall passing him at light speed. When Bob crosses the horizon, it appears to him everywhere — like a volume instead of a surface. But Alice only appears at one point in this volume, in front of him.

He sees her in front of him, but by the time the photons coming ...

2024-11-25T18:07:58Z

In reply to nevent1q…6y6r
_________________________

He sees her in front of him, but by the time the photons coming from the event "Alice crosses the horizon" reach Bob, the horizon also reaches him.

It certainly depends on your definition of "implicit", ...

2024-11-08T15:17:12Z

In reply to nevent1q…zhhh
_________________________

It certainly depends on your definition of "implicit", but for what it's worth, I did have to scratch my head about this specific dependency (if I remember correctly).

pkg-config works if the dependency is installed on your system, but it's useless if you don't have the dependency installed already, right?

I am guessing the lack of examples is a consequence of library ...

2024-11-07T17:42:00Z

In reply to nevent1q…9qdj
_________________________

I am guessing the lack of examples is a consequence of library authors relying on the types too much

I know it's totally subjective and I'm completely biased ...

2024-09-29T03:44:38Z

I know it's totally subjective and I'm completely biased in favor of the latter, but #Rust feels so much "bigger" than #Haskell

Sure, depending on your background Haskell might be very hard to grasp*, and GHC is huge and complicated, and a lot of Haskell code hurts the brain, but in terms of core concepts and syntax, I actually feel it's pretty straightforward :
- Basic function application is as simple as can be. The one complication is infix operators/functions and precedence rules
- Pattern matching is immediately understandable
- At the type level, you need to know about algebraic data types and record types
- And then there's a sugar layer on top of that, with a couple of constructs that you need to know: string literals, if-then-else, do notation... only the latter of which may be confusing.
I feel like the rest is either building on that, or not essential to the language?

Whereas in Rust you have to grasp:
- Most of that too (functions, some operators, algebraic data types, records, pattern matching)
- Plus general imperative control flow structures
- Plus low-level stuff like pointers and references
- And then Rust's own innovations (everything related to borrowing)
- ... and some confusing, ad hoc sugar too; see https://cheats.rs/#language-sugar

*Not getting into the debate of whether one of Haskell or <insert your favorite imperative language here> is easier to learn as a first programming language here