Huh? I might be misunderstanding something (maybe a joke, even!), but this is my lemmy account, that's kinda older indeed. How would that be connected to my mastodon account?
KillTheMule
Huh haven't heard of this for quite some time, nice it's still going strong :)
I hope this is the first of many contributions we’ll have between the two projects and that we can continue to collaborate with and help each other.
Great to hear!
I wasn't on X, but now I've created a mastodon account :)
Man, I'd love that, if only the pay was better... but than again, if the pay was better I'd be even less qualified. But typst is awesome, all the best wishes for the team including the new hire :)
Oh yeah, the docs even mention Unblock<Stdin>
explicitely. Thanks a lot!
Yeah that looks fine, thanks! It would introduce a new dependency (async_io
) though, so I might go with Unblock
mentioned above. Let's see what happens when I try to make the switch :)
(e) Ah I don't think this really works, I'd need to wrap it in an Async
, but the docs explicitely mention not to use that with Stdin
: https://docs.rs/smol/latest/smol/struct.Async.html#supported-types. Unblock
it is then :)
unsafe
does not disable the borrow checker. It does however give you abilities to circumvent it, namely by letting you dereference pointers, which are not subject to the borrow checker.
Sure, but isn't this in a dependency? Can't be reached when only importing your crate anyways? And if you're building a binary, I don't think this could really considered exported, is what I mean :)
Actually, dead code eliminination should do the trick, if you're compiling a binary at least (same for a library I think, but there could be re-exports there). Did you compile in release mode?
Huh, I did not know that you can speed up builds by stripping debug info, need to try that out :)
Yeah I was very happy to find that out. I was calling latex externally before, and there was a lot of pain interacting with the filesystem and temporary files. Now it all happens in-memory :)
And it really only concerns a certain subset - 32bit applications compiled with the gnu toolchain. I'm glad they keep the workload in check this way.