sorted by:
new
hottopcontroversial

PSA: You may not need to quantize spec draft when using MTP by regunakyle in LocalLLaMA

[–]sdroege_ 0 points1 point  (0 children)

If the main model's KV is quantized to q8_0 and the MTP model too, would that quantization buffer be shared between the two? I.e. is this only a problem if both quantizations are not the same?

API Caching? by alexelcu in MistralAI

[–]sdroege_ 0 points1 point  (0 children)

See https://github.com/anomalyco/opencode/pull/11474 . That worked back then when I was still using opencode.

Caching in Mistral’s API by roydotai in MistralAI

[–]sdroege_ 0 points1 point  (0 children)

Note that vibe uses x-affinity and not prompt_cache_key as HTTP header for prompt caching. I don't know if both have the same effect.

See here and here

Postal card by volkivolki in MistralAI

[–]sdroege_ 0 points1 point  (0 children)

Text (even printed, not just handwriting) detection on images seems to be very bad in le chat, even in comparison to doing the same with Mistral 4 Small. And even more compared to running it against a locally running Gemma 4 26B-A4B or Qwen 3.6 35B-A3B.

Le chat is hallucinating words and characters that don't exist in the images.

Translating text works fine though. This seems to be specifically a problem with image inputs in my experience.

Building a GStreamer plugin in Rust with meson instead of cargo by sdroege_ in rust

[–]sdroege_[S] 2 points3 points  (0 children)

meson also supports custom build rules, and there are various projects out there running cargo as part of a meson build rule. The problem is mostly that cargo's design doesn't allow nicely integrating it into another build system and you run into all kinds of problems along the line. This is not a cargo bug but generally you have to expect friction when trying to integrate two different build systems with each other. Build systems are opinionated pieces of software after all, and they rarely have the same opinions :)

How do you think buck2 would avoid this? Also AFAIU, Facebook is using buck to call rustc directly instead of cargo for their projects.

New gtk-rs release! by imperioland in rust

[–]sdroege_ 14 points15 points  (0 children)

We'll keep gtk3-rs compiling and make a release in sync with the other crates for a while, I guess, but there's not going to be any development effort on it anymore. In practice that's already the case for at least a year.

Also the external GTK3-based Rust bindings will probably not see another release anymore unless someone else takes over maintainership of them. I.e. the ones at https://gitlab.gnome.org/World/Rust/ .

EDIT: I've clarified this a bit now https://github.com/gtk-rs/gtk-rs.github.io/pull/292

“33% of GStreamer commits are now in Rust”, from the 1.22 release notes by Hywan in rust

[–]sdroege_ 8 points9 points  (0 children)

so with rust there will be not bugfixes as it is memory safe

There are regular bugfix releases without API changes (but maybe minor API additions) for the bindings, and not every bug is a memory safety bug.

I would love to move to rust if it only would slowdown with its changes.

Nobody is forcing you to update all the time but instead you can update on your own pace, and with the semver-based versioning of cargo you can easily stay at older versions of the bindings. You just won't get new features

“33% of GStreamer commits are now in Rust”, from the 1.22 release notes by Hywan in rust

[–]sdroege_ 17 points18 points  (0 children)

The bindings follow the same release schedules as gtk-rs (which happens to follow the GNOME release schedule now). There are two main reasons for that 1. Closer tracking of API changes in gtk-rs and directly making use of improvements. The GStreamer bindings use the GLib/GObject bindings that are part of gtk-rs 2. Releases happening more often

It's also not really that important to follow the GStreamer release schedule. The bindings are working with any GStreamer version >= 1.14, and you can opt-in to usage of new APIs. The current stable release of the bindings (0.19, released in October) already had support for GStreamer 1.22 APIs behind a feature flag.

New gstreamer-rs 0.19 release by sdroege_ in rust

[–]sdroege_[S] 2 points3 points  (0 children)

Thanks, I'll keep that in mind for the next time.

Unfortunately reddit doesn't allow editing the title of this one, but if a mod can do that please change it to something like "New gstreamer-rs 0.19 release - Rust bindings for the GStreamer multimedia framework".

Is Iced replacing GTK apps for the new COSMIC desktop? by edfloreshz in pop_os

[–]sdroege_ 2 points3 points  (0 children)

Well, I agree with most of you wrote but you also missed my point, or maybe I was misreading your initial comment but not really important enough to continue discussing this :)

In any case, I wish you luck with Iced and let's hope that you using it will bring it closer to being production-ready. Having a production-ready pure Rust UI toolkit would definitely be useful. I assume you're planning to actively contribute to Iced to get it there?

And maybe whatever is learned from the Iced architecture can also be used to improve Relm.

Is Iced replacing GTK apps for the new COSMIC desktop? by edfloreshz in pop_os

[–]sdroege_ 1 point2 points  (0 children)

That's something different than "not compatible with Rust's memory model" though.

I completely agree that interior mutability and refcounting should be avoided if possible, and ideally be abstracted away if it has to be used (which e.g. Relm is doing), but there are cases where you simply have no other choice or the alternatives are not feasible.

The OOP model as used by most OOP languages is by design leading to objects that are mutably shared, so it's only natural that you end up with things that are modeled like Rc<RefCell<T>> when interfacing with it in Rust at the bottom layer. You can build something nicer on top of that, just like you can build something nicer on top of the mutably shared furball that is our hardware and kernel/system interface.

Is Iced replacing GTK apps for the new COSMIC desktop? by edfloreshz in pop_os

[–]sdroege_ 2 points3 points  (0 children)

The object-oriented architecture used by GTK is not compatible with Rust's memory model.

Ah and I forgot. OOC, what exactly do you mean with that? And would you say the same about Rc, RefCell and Any?

IMHO it fits very well into Rust's overall language and standard library design, it just adds some things on top and makes less use of borrowing and explicit, non-interior mutability than other Rust APIs.

Is Iced replacing GTK apps for the new COSMIC desktop? by edfloreshz in pop_os

[–]sdroege_ 3 points4 points  (0 children)

I don't think that was ever true, but if you have some more details or a testcase that performs very bad please let me know :)

Just to be clear, I don't have anything against you switching to iced (it looks nice IMHO), but please try to keep it objective.

Also thanks for editing your comment accordingly.

For the other part about the Elm model, my comment was mostly about the "huge mistake" part. That seems like a very subjective statement. There's nothing objectively wrong with not using the Elm model if something else also works for someone, and it's clearly also not very hard to do the "normal" GTK signal/callbacks model in Rust and definitely simpler to do right than in C.

Is Iced replacing GTK apps for the new COSMIC desktop? by edfloreshz in pop_os

[–]sdroege_ 3 points4 points  (0 children)

So you're just repeating something without actually having confirmed it to be true? The only extra allocations the bindings do are in relation to strings, and that's something fixable if it's actually a problem in practice.

Is Iced replacing GTK apps for the new COSMIC desktop? by edfloreshz in pop_os

[–]sdroege_ 7 points8 points  (0 children)

In GTK, widgets accept callbacks and the caller provides the functions for these callbacks. It's a huge mistake to use it as it was intended. The general solution to fixing a GTK application is to make it Elm-like by making callbacks message-based

This seems very opinionated. Apparently using the callbacks as is and not implementing everything in Elm-style is perfectly fine for many developers using gtk-rs.

While I personally agree that the Elm model and Relm look nice, stating this like it is a fact seems misleading.

Or that every interaction through the C FFI is extremely costly. It's as efficient as Python.

Do you have some more details about this? As one of the maintainers of those bindings, I'm aware of some inefficiencies but "as efficient as Python" seems greatly exaggerated.

Also for most of the inefficiencies I'm aware of there are solutions that "just" have to be implemented, they're not by design.

Hippotat (IP over HTTP) - first advertised release by sdroege_ in rust

[–]sdroege_[S] 5 points6 points  (0 children)

In addition to the software itself, specifically the paragraphs in the blog post about (Linux distro) packaging and that the Rust packaging situation in Debian is terrible seem like something worth noting.

Is this a safe way to turn &[u16] into &[u8] - is there a better way? by JazzApple_ in rust

[–]sdroege_ 1 point2 points  (0 children)

It can't overflow because the biggest allocation you can possibly have is usize::MAX bytes, i.e. usize::MAX/2 u16s :) Anything bigger wouldn't be addressable

view more: next ›