kbolino

25 दिन पहलेdiscuss

It's quite difficult to find fixed-point number systems that include trigonometry, never mind fancier tools like elliptic integrals. The problem is not just one of static number representations, but also geodetic/geometric computations. [ed: I see this is where the other thread is heading already]

kbolino

25 दिन पहलेdiscuss

> People are convinced you have to use doubles because of the inaccuracy of floats

With single-precision floats, considering the worst case, i.e. longitudes close to the equator but far away from the prime meridian, one ulp can translate into as much as 1.68 m (5.5 ft) of distance on the surface (*). That's good enough for some uses, but not for dGPS or any other serious geometric computation. Whereas, with double precision, one ulp in this worst case scenario corresponds to about 3 nanometers. It's overkill, for sure, but if these are the only two types you have, you pick the latter.

* = To represent the integer 179, you need 8 bits, leaving only 16 for the fraction. Since 1 degree of longitude near the equator is about 110 km, you have 1/2^16 degrees * 110 km/degree giving 0.0016784... km.

kbolino

पिछला माहdiscuss

I had this problem on the first Apple Silicon Mac Mini in 2020 so it's at least a little older than 2023.

kbolino

पिछला माहdiscuss

It's also the corporate standard for generic cubicle workstation monitors, though it's unusual to find a Mac in such a place anyway.

kbolino

पिछला माहdiscuss

I wonder if they can solve the "ecosystem fracture" issue by borrowing the bubble concept from e.g. testing/synctest. The way the synctest API works is by creating a "bubble" around the test harness and the code under test such that the standard library's time package behaves differently, but only for the code running in the bubble.

So, maybe we could also have allocator bubbles, where code running inside the bubble is just as allocator-naive as any other Go code, but when it allocates (make/new/pointer escape), it uses the bubble's allocator instead of the default one.

The big problem I can think of, though, which doesn't apply to time bubbles, would be that pointers drawn from that allocator might escape the bubble (e.g. by assigning them to a longer-lived struct field). It's possibly something that can be detected by the runtime, but because the API is non-invasive by design, it's not something that will be apparent to the programmer when looking at the code.

kbolino

पिछला माहdiscuss

There's another big one, 4K page support. The MMU can be told to set up a virtual address space with smaller, x86-compatible 4096-byte memory pages instead of the default 16384-byte pages.

kbolino

पिछला माहdiscuss

The entire existence of 32-bit x86 Macs is in and of itself a tragedy of Apple's own making. Intel shipped the Core 2, a 64-bit CPU widely regarded as one of the company's greatest products, later in the very same year that Apple shipped the first x86 Macs. There was never any reason for 32-bit x86 Macs to exist except for Apple's rush to get them out the door and close down the AIM alliance.

kbolino

2 माह पहलेdiscuss

For example, you have an envelope format that goes: length prefix in LEB128, message, signature. One party controls the length prefix and signature, a different party controls the message. The message-writing party carefully crafts the message so that, in isolation, it appears innocuous, but when wrapped in the envelope, the first few bytes of the message look like continuation of the length prefix. Best case is the receiving party safely fails to parse the message, worst case is the receiving party successfully parses the message, verifies its digital signature, and interprets it differently than the signer did.

kbolino

2 माह पहलेdiscuss

Generic interfaces already exist. Generic interface methods, which would be relevant, are not planned. The reason is outlined early in the proposal: nobody knows how to implement them efficiently. Rust has the same problem, for what it's worth: dispatchable functions on dyn-compatible traits cannot be generic [1].

[1]: https://doc.rust-lang.org/reference/items/traits.html#r-item...

kbolino

2 माह पहलेdiscuss

Indeed, I ran two tests (missing indirect dependency, stale indirect dependency version) and it refused to compile both. Either what I said was never true, or it was only true for earlier versions of the `go` command. Nevertheless, adjusted accordingly, I believe the following statement is true: `go mod tidy` doesn't change versions in go.mod unless it needs to, to satisfy the other dependencies listed in go.mod, or to fill in a missing dependency for an import in code. It would be nice if there were a flag to turn off the latter behavior, though.

kbolino

2 माह पहलेdiscuss

There is something you can do to stop it actually. You can use a replace directive, specifying that a module is replaced by itself at a fixed version. See e.g. https://stackoverflow.com/a/77412524/814422

It is worth noting though that, even without such pinning, `go mod tidy` does not update versions willy-nilly. [edit: the following is inaccurate, see grandchild comment] It only syncs go.mod with what is already being used by the build process. In other words, if you see `go mod tidy` change a version, it means that you haven't tidied the file since making other changes to it, and the listing in go.mod was stale with respect to the resolved set of transitive dependencies actually being used.

kbolino

2 माह पहलेdiscuss

Though there may be other reasons not to use it, invokedynamic is not a new feature of the JVM. If they're targeting 1.8 binary compatibility, they certainly have it at their disposal, since it landed in 1.7.

kbolino

2 माह पहलेdiscuss

I also don't know a whole lot, but yes, they both are ultimately implemented as families of client-server protocols over Unix domain sockets (X11 also supports TCP). Inasmuch as you are content with targeting a single version-set of those protocols, then that is sufficient to enable static compilation.

However, the real issue I'm getting at is the ability to run the same statically compiled binary many years later. That requires a dedication to compatibility (in this case, protocol compatibility). X11 was a bit all over the place on this, though it is probably stable enough now by dint of not getting much attention anymore. It seems like Wayland takes protocol compatibility pretty seriously [1] but there's an important caveat:

  [W]hen a protocol transitions from unstable to stable, one last breaking change is permitted.
  [ ... ]
  Note that many useful protocols are still unstable at the time of writing.

Though this itself may be out of date by now (I can't find a date of authorship in that book).

[1]: https://wayland-book.com/protocol-design/design-patterns.htm...

kbolino

2 माह पहलेdiscuss

I've been intrigued by the possibility of statically compiled games for Linux but I don't think they're the more compatible option. For typical games and players, the game needs to cooperate and interact with the window system. Even setting aside the X11 vs. Wayland issue, AFAIK neither have promised to maintain compatibility for static binaries.

kbolino

2 माह पहलेdiscuss

There's two problems as I see it.

The first is that value types themselves are immutable. This affects code generation and optimization. If you were to modify the value with unmanaged code then you may not observe the modification properly from managed code. Maybe this restriction will get relaxed, but I don't see that on any roadmap any time soon.

The second problem is that value types are still nullable. The flattened array is not going to be identical to a Go slice or a C# Span etc. because it has to track the nullness of each element. It seems they don't want to nail down the exact storage format for that yet, possibly to change it in the future, and possibly because they want to add language-level control over nullability eventually too.

kbolino

2 माह पहलेdiscuss

[dead]

kbolino

2 माह पहलेdiscuss

For whatever it's worth, you don't have to write anything special to handle the reference system, because the final, published version of RFC 7946 only allows WGS84 anyway.

kbolino

2 माह पहलेdiscuss

The other nice thing about rg and fd is that they work natively on Windows.

kbolino

3 माह पहलेdiscuss

> Path names are UTF-8-encoded, unrooted, slash-separated sequences of path elements, like “x/y/z”

This is only for the "io/fs" package and its generic filesystem abstractions. The "os" package, which always operates on the real filesystem, doesn't actually specify how paths are encoded, nor does its associated helper package "path/filepath".

In practice, non-UTF-8 already wasn't an issue on Unix-like systems, where file paths are natively just byte sequences. You do need to be aware of this possibility to avoid mangling the paths yourself, though. The real problem was Windows, where paths are actually WTF-16, i.e. UTF-16 with unpaired surrogates. Go has addressed this issue by accepting WTF-8 paths since Go 1.21: https://github.com/golang/go/issues/32334#issuecomment-15500...

kbolino

3 माह पहलेdiscuss

> There is no realistic risk of a SHA collision attack.

Indeed. To illustrate why:

1. It is not possible to "retroactively" find a SHA-1 collision for an already known hash. If somebody has produced a SHA-1 hash non-maliciously at any point in the past, it is safe from collisions. This is due to second-preimage resistance, which hasn't been broken for SHA-1 and doesn't seem likely to be broken any time soon.

2. The only way to obtain a SHA-1 collision is to do so knowingly when producing the original hash. You generate a pair of inputs at the same time that both hash to the same value. Certainly, this is an imaginable scenario; e.g. a trusted committer could push one half of the pair wittingly or a reviewer could be fooled into accepting one half of the pair unwittingly, both scenarios creating a timebomb where the malicious actor swaps the commit to the second half of the pair (which presumably carries a malicious payload) later. However, there are two blockers to this approach: Git (not just GitHub) will not accept a commit with a duplicate hash, always sticking with the original one, and GitHub specifically has implemented signature detection for the known SHA-1 collision-generating methods and will reject both halves of such a pair.

In short, there's just no practical way to exploit this weakness of SHA-1 with Git.

Submissions

Rust 1.94

comments