[-] KillTheMule@programming.dev 1 points 2 months ago

That might indeed be the case, I did not look very closely, but mlua has gotten quite some coverage (and I do like lua quite a bit), so I wanted it mentioned :)

[-] KillTheMule@programming.dev 2 points 2 months ago

Seems to be missing mlua at least: https://github.com/mlua-rs/mlua

[-] KillTheMule@programming.dev 4 points 2 months ago

The post mentioned that the introduction of these new algorithms brings compile-time improvements too, so how should I see this?

I assume you mean the first post of the PR? I'd assume it's simply outdated (or might not have been true to begin with). See https://github.com/rust-lang/rust/pull/124032#issuecomment-2181789935 for the perf run with this PR, it's showing quite a bit of regression.

[-] KillTheMule@programming.dev 5 points 2 months ago

Alas, on the whole the compiler slowed down as a result of this. I think it's a worthy tradeoff though.

[-] KillTheMule@programming.dev 4 points 4 months ago

Did I get it right? The crate lets you directly input data into a typst document from an arbitrary struct?

Well, typst provides those means in itself, this crate just makes it easier to fulfill the necessary trait.

Also out of scope of OP, is typst in anyway capable of typesetting music notation?

I don't really think so. Music notation is also pretty specific, so I'd look into specialized software for that (although it might be theres a latex package, those things are everywhere ^^).

[-] KillTheMule@programming.dev 3 points 6 months ago

It's absolutely awesome. For my use case, it already surpasses latex, but I'm pretty sure that for other usecases there will be a point where latex offers more, at least due to ecosystem support. I for sure made the switch (wrote some personal docs in typst as well), and I'd suggest anybody at least looks into switching, it's so much better :)

From a dev perspective, it's also great that this is useable as a lib, instead of having to muck with an external binary (or rather full external latex installation).

[-] KillTheMule@programming.dev 4 points 8 months ago* (last edited 8 months ago)

This parting shot sounds pretty dire

a bug in safe code can easily cause unsound behavior in your unsafe code if you’re not careful.

That's definitely not how it should be. Fortunately, I think I disagree with that, since miri points to the "real" buggy code:

unsafe { inner.as_ref() }

As opposed to the article, I'd argue this code is not correct, since it did not account for alignment, which it must (I mean, by standard use of the word unsound this is unsound, since it can be called from safe code introducing UB). Or am I wrong? Is the fundamental value proposition of rust moot?

[-] KillTheMule@programming.dev 4 points 10 months ago

I've written nvim-rs, an async library for interfacing with neovim via RPC.

As a sidejob, I'm writing and selling a program to create school reports.

[-] KillTheMule@programming.dev 2 points 10 months ago

The question was specifically about shared references

Sure, but the way I read the answer was "All primitive values on the stack are Copy", which isn't true (my example being mutable references, which have the same representation as shared ones, "just" a different semantic meaning). That's what I meant by misleading.

[-] KillTheMule@programming.dev 3 points 11 months ago

I don't know, I was just surprised by the short timeframe.

[-] KillTheMule@programming.dev 1 points 1 year ago* (last edited 1 year ago)

Note that when you change num to take &self instead, this works out (you also need to mark foo as mutable, of course).

[-] KillTheMule@programming.dev 2 points 1 year ago

I’m sure everyone’s thought about it already but hasn’t done enough so far.

Note though that the rust foundation has established a security initiative (see e.g. here), which does include the supply chain via crates.io.

view more: ‹ prev next ›

KillTheMule

joined 1 year ago