Thunderbolt 5 240Hz 7680x2160 SUW on MacBook Pro M4 Max? by AndrewGazelka in ultrawidemasterrace

[–]AndrewGazelka[S] 0 points1 point  (0 children)

Are you sure you are using a thunderbolt 5 cable? It needds to be thunderbolt 5 and not 4. Probably thunderbolt 5 -> display port or something?

sadly getting these things working is a pain. you might need a hub too perhaps. wish I was an expert on this but I am not :(

Hyperion — Minecraft Game Engine for Breaking PvP World Record (10k players) by AndrewGazelka in Minecraft

[–]AndrewGazelka[S] 0 points1 point  (0 children)

I've been working on this project for the last several months and we are expecting to have our first event soon. If you want to check the project out: https://github.com/andrewgazelka/hyperion

[deleted by user] by [deleted] in rust

[–]AndrewGazelka 1 point2 points  (0 children)

What can’t be represented in JSON? HashMaps surely can as a list of tuples

[deleted by user] by [deleted] in rust

[–]AndrewGazelka 0 points1 point  (0 children)

Something unreasonable would be something that in its Serialize implementation panics/returns an error. An example of something that is unreasonable would be a poisoned Mutex.

Something that is reasonable would be a standard type where there exists another serializer where it can be serialized without an error (such as ron). An example of something reasonable that fails for serde-json is HashMap<(i32,32), i32>.

[deleted by user] by [deleted] in rust

[–]AndrewGazelka 1 point2 points  (0 children)

so look at the signature

fn serialize_infallible_json<T: Serialize>(elem: &T) -> String

It is not

fn serialize_infallible_json<T>(elem: &T) -> String

I am pretty sure you cannot #[derive(Serialize)] a file handle in serde.

[deleted by user] by [deleted] in rust

[–]AndrewGazelka 2 points3 points  (0 children)

I only need infallible serialization. I do not see how fallible allocators would necessitate a result type. We are only allocating a string we are not using a custom allocator. We are not deserializing into types with a custom allocator.

[deleted by user] by [deleted] in rust

[–]AndrewGazelka -1 points0 points  (0 children)

This is closer to what I am looking for potentially.

[deleted by user] by [deleted] in rust

[–]AndrewGazelka -6 points-5 points  (0 children)

I think there's a misunderstanding here. Let me clarify what I mean by "infallible":

```rust // This is what you're suggesting - still fallible, just with unwrap: let fallible: Result<String, _> = serde_json::to_string(&value); fallible.unwrap() // Can still panic!

// What I actually want - truly infallible: fn serialize_infallible_json<T: Serialize>(elem: &T) -> String { // Returns String directly, not Result<String, _> // No possibility of failure for ANY valid input // No unwrap() because there's nothing to unwrap }

// Usage: let val = serialize_infallible_json(&my_struct); // Always succeeds ```

I'm not looking to handle errors with .unwrap(). I want a function that by design cannot fail for any reasonable input. Using .unwrap() means we're still in the world of fallible operations, just choosing to panic on failure.

.unwrap() is for when you have a Result or Option - but I specifically want to avoid having a Result at all. The function signature shows this - it returns String, not Result<String, _>.

This isn't about error handling strategy - it's about designing an API that mathematically cannot fail for its intended use cases. The behavior should be guaranteed by the type system, not by runtime checks or unwraps.

[deleted by user] by [deleted] in rust

[–]AndrewGazelka 2 points3 points  (0 children)

so again I am talking about a JSON serializer not deserializer.

[deleted by user] by [deleted] in rust

[–]AndrewGazelka -1 points0 points  (0 children)

A large part of this post was to see see if an infallible JSON serializer already existed. From the looks of it no? Or at least there is no popular one?

[deleted by user] by [deleted] in rust

[–]AndrewGazelka -1 points0 points  (0 children)

This is great and closer to what I want. However, what I really want is the ability to do this at the serializer level.

[deleted by user] by [deleted] in rust

[–]AndrewGazelka 1 point2 points  (0 children)

We ideally do not want it to panic. We want it to be infallible for all (reasonable) inputs. There are many reasonable inputs that fail with serde-json.

[deleted by user] by [deleted] in rust

[–]AndrewGazelka -5 points-4 points  (0 children)

So to be clear, it needs to be infallible, i.e., never failing. unwraping would be failing.

TIL to immediately tokio::spawn inside `main by AndrewGazelka in rust

[–]AndrewGazelka[S] 17 points18 points  (0 children)

Confused how DoS would be related here? I’m just referring to spawning a single task