Sukera

Serializing an e.g. `Xoshiro` should be perfectly possible, it just needs to serialize the internal state & then reconstruct the RNG object from that state. I'm kind of surprised this...

Is this really the correct fix? On 1.11, the reproducer in #58593 was printed like ``` julia> s = "\xc0\xa0\xe2\x88\xe2|" "\xc0\xa0\xe2\x88\xe2|" ``` which has one overlong encoded character (`\xc0\xa0`) at...

That does make sense, but the reproducer from the issue still hits this error from `show`, no? If `textwidth` is for `print`, then that error shouldn't happen in the first...

Whatever the final implementation looks like, please consider making it CFS aware - ref https://github.com/JuliaLang/julia/issues/46226.

I can try to make a PR to the LLVM_jll repo, is it just adding TOML as a dependency and rebuilding so we get v13.0.1+4? Or do I need to...

I have no idea - since the original issue is due to a JLL, I opened it here. I'm not familiar enough with the internals of a JLL package to...

I've observed the same issue [here](https://github.com/Seelengrab/SVD2Julia.jl/commit/c6719c6ba4547721d6806ddda7063593f1c65dae#comments). The circumstances are identical - I first tried to register SVD2Julia.jl last week and forgot that one of its dependencies was still not registered....

I think the usual pattern for this is simply ``` @everywhere f(a) = a ``` The reason you get this error is because `@everywhere` executes the expression you give it...

The line with `time = ` is a valid ISO-8601 datetime string with timezone information (that's the `Z`, here for Zulu or UTC time) - what shouldn't be there is...

The point is that the `Manifest.toml` is machine generated and shouldn't have such an issue in the first place.