

Couldn’t find any info, so maybe someone here knows: Is QT statically linkable, in particular when used from Rust? That’s something that I really value in fltk.


Couldn’t find any info, so maybe someone here knows: Is QT statically linkable, in particular when used from Rust? That’s something that I really value in fltk.
Here’s a blog post about the miscompilation bug: https://parsa.wtf/cast/


Ha, nice idea, but I don’t know C++ and that’s a yak I won’t shave :) I’ve also tried working with a folder with symlinks, and I discarded the idea for some reason I’m not really sure on (I think it has something to do with the fact that entering a symlinked directory will have you work inside the symlink, rather than the symlink’s target).


Thank you :) I’ve not been successfull really thus far. My best hope is that someone cooks up something in Rust that I can contribute to/fork to make it into what I want. One can dream ;) I use doublecmd right now, which ticks many boxes, but has some other oddities.
Yeah, so, bookmarks, I “just” need to be able to organize them, like with a folder structure (or even subfolders, but I don’t want to get greedy), and name them independently of their target. Using tags as a folder substitute is probably ok, that’s why I looked at blazepilot. I also don’t want that dreaded “places” list wasting my screen space, so maybe putting them into a menu or behind a shortcut is in order…


Dolphin is somewhat ok-ish, exactly like you say. It’s slightly better than that gnome-thingy I’m forced to use at work, but the bookmarks aspect it important enough for me to avoid it for personal usage (where I’m free to choose).
“File commands don’t block GUI” means: If I e.g. copy a file, I want to directly use the filemanager, even while the copy is still running. I think most of the more popular file managers do this, but it is really important :)




I’ve no idea. I kinda assume AI is basically used everywhere, but unless explicitely stated one can seldom be sure.


Wait, what? Any more details about this, I’ve never heard about that before. Partially run Drop impls sounds like a big potential for undefined behavior, how could catch_unwind possibly cause that?
Yeah, no, I don’t think this is true. It’s the reason a double panic will cause an abort. The docs do recommend against using this for general error recovery, but there’s no mention of any possibillity of inconsistent state.
I don’t have anything to add, except that typst is awesome. And that ‘accessibler’ should be a word.


I did fill out the survey. Turns out I don’t have a usecase for any of this, and therefore I’m in the “don’t care” realm really, since I’m also not really appreciative of corresponding features in other languages I know. I’d generally be critical of the cost vs. gain balance here though…


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.


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?
Ahh too bad, thanks for the answer though :)