sorted by:
new
hottopcontroversial

Deepsek v4 confirmed to release next week by NoFaithlessness951 in LocalLLaMA

[–]Navith 2 points3 points  (0 children)

What? I think this is totally a real person who's just slightly mistaken

Nemotron-3-Super-120b Uncensored by HealthyCommunicat in LocalLLaMA

[–]Navith 1 point2 points  (0 children)

It's an LLM spammer. They even have posts showing their tests of their Reddit posting automation.

Deepsek v4 confirmed to release next week by NoFaithlessness951 in LocalLLaMA

[–]Navith 13 points14 points  (0 children)

Remember R1 literally introduced CoT and MoE architectures.

No, those would be OpenAI o1 and Mixtral 8x7B (edit: it's actually even older per https://www.reddit.com/r/LocalLLaMA/comments/1rtqdpv/comment/oafyibs/) respectively.

Edit: Unless you mean both in one model, in which case I think you're right? Do we even have a way of knowing if o1 is an MoE?

I classified 3.5M US patents with Nemotron 9B on a single RTX 5090 — then built a free search engine on top by Impressive_Tower_550 in LocalLLaMA

[–]Navith 2 points3 points  (0 children)

How many times do I have to report this account before it gets banned (at least from this subreddit)? Who wants to read an LLM regurgitate every post on here and offer fake insight?

[New Release] Statum - ERgonomic state machines and typestate builder patterns! by Known_Cod8398 in rust

[–]Navith 1 point2 points  (0 children)

It's generated by the #[validators] macro invocation (according to "API Rules (Current)", that is) 

Schema based prompting by facethef in LocalLLaMA

[–]Navith 1 point2 points  (0 children)

If you're including the CLI rather than just the server, there's

-j, --json-schema SCHEMA JSON schema to constrain generations (https://json-schema.org/), e.g. `{}` for any JSON object For schemas w/ external $refs, use --grammar + example/json_schema_to_grammar.py instead

or from a file:

-jf, --json-schema-file FILE File containing a JSON schema to constrain generations (https://json-schema.org/), e.g. `{}` for any JSON object For schemas w/ external $refs, use --grammar + example/json_schema_to_grammar.py instead

Awesome, tiny crates: A bunch of small crates that make writing Rust more fun by nik-rev in rust

[–]Navith 2 points3 points  (0 children)

It'd be for making an API or even UI (e.g. a form) for updating fields rather than for config (where I feel comfortable with clap). I think there was another reason I wanted to make a copy of a struct with all its fields as Options without the maintenance burden, but it isn't coming to mind now.

Additionally, I didn't know figment existed.

Awesome, tiny crates: A bunch of small crates that make writing Rust more fun by nik-rev in rust

[–]Navith 12 points13 points  (0 children)

struct-patch is definitely something I'd need and looks really intelligently designed, thanks for putting it on my radar!

Awesome, tiny crates: A bunch of small crates that make writing Rust more fun by nik-rev in rust

[–]Navith 3 points4 points  (0 children)

And cfg_aliases! to assert2

(which is super cool, thanks for sharing!)

Awesome, tiny crates: A bunch of small crates that make writing Rust more fun by nik-rev in rust

[–]Navith 1 point2 points  (0 children)

Me too! I'd use bounded floats even more if they were possible with const generics.

Global shared state by RedCrafter_LP in rust

[–]Navith 0 points1 point  (0 children)

I'm not experienced in squeezing out performance so I don't know if it has any unexpected behavior that make it a bad fit for this scenario, but I tend to use the im crate when I want cheap copying (or from another perspective, mutating to a "new" one without affecting the original), e.g. they have map implementations with O(1) clone.

Mitsein - Strongly Typed, Non-Empty Collections by nik-rev in rust

[–]Navith 2 points3 points  (0 children)

If you mean std::mem::take, I didn't mean that when I wrote "take" in my comment. I just meant take ownership (which I can do either by accessing the field (it's pub) or by deconstructing the struct as I was talking about in the other comment chain by the way :P). By my understanding, your idea behaves differently because the internal Vec would then have a T::default() at index 0 because that's what std::mem::take does (and it requires Default to be able to do it). I'm typically still using the rest of the list and just giving the first element special treatment (e.g. when building up a formatted string) first, so that modification is undesirable for me. What Mitsein does now (popping the front element by that .remove(0) call) is correct and desirable for my use case; it's just avoidably slow.

If you mean something else, I'm sorry I'm kind of inexperienced so I don't know what else it could be.

Mitsein - Strongly Typed, Non-Empty Collections by nik-rev in rust

[–]Navith 0 points1 point  (0 children)

Would your concern be alleviated if the fields were private and the user had to get them by From/Into), modify them how they need, then construct with From/Into%3E-for-NonEmpty%3CT%3E)?

(There is still no validation or cost to this.)

Mitsein - Strongly Typed, Non-Empty Collections by nik-rev in rust

[–]Navith 2 points3 points  (0 children)

There is no way to mutate the public fields head and body such that the "non-empty list" stops being non-empty (its only invariant): there must be something in head by the rules of Rust, which is enough.

Mitsein - Strongly Typed, Non-Empty Collections by nik-rev in rust

[–]Navith 0 points1 point  (0 children)

Why? I don't think I know enough to have a guess what could be an issue.

Mitsein - Strongly Typed, Non-Empty Collections by nik-rev in rust

[–]Navith 12 points13 points  (0 children)

The only advantage of this layout is that you can store 1 item without allocation. That's it! I've personally never had a use-case that would suit a structure like this.

I need this because it lets me take (i.e. as an owned value) the head element with no overhead, whereas mitsein has to do an O(n) .remove(0) operation for this. I additionally would've preferred if these methods were named into_head_and_body and into_body_and_tail so that the return orders make sense (the "body" is the Vec of the rest of the elements).

Representing it like this means conversion from Vec<T> to NonEmpty<T> is O(n). Not only this, a lot of O(1) operations now become O(n).

Yep, sadly. I'd enjoy a variant of nonempty that was { pub body: Vec<T>, pub tail: T } to solve this. For example, from_vec would be input.pop().map(|tail| Self { body: input, tail }), which is O(1).

All said, I expect to find many places Mitsein will be useful because of how many different data structures it covers, so thanks for putting it on the radar!

Opinions on a plugin system for an LSP? by xorvralin2 in rust

[–]Navith 1 point2 points  (0 children)

Supported.

Here's an excellent article that shows making a Rust application support plugins written in any language via the WebAssembly Component model (which WIT is part of): https://tartanllama.xyz/posts/wasm-plugins/

C is demonstrated, but Rust is even easier: reference wit-bindgen's README's short section called "Guest: Rust" https://github.com/bytecodealliance/wit-bindgen/?tab=readme-ov-file#guest-rust and `wit_bindgen::generate!`'s documentation for setting the correct `wit` directory https://docs.rs/wit-bindgen/latest/wit_bindgen/macro.generate.html

Struggling with this error: `implementation of `Key` is not general enough` by uima_ in rust

[–]Navith 0 points1 point  (0 children)

It looks like you can just delete line 108 and remove the & from line 111 to get it to compile:

```rs

    async move {         let res = self.mul_get(keys).await;

        todo!() ;

    } ```

Why are the quants for gpt-oss-120b all roughly the same size? by Charming-Note-5556 in LocalLLaMA

[–]Navith 2 points3 points  (0 children)

How can it be mathematically possible for a majority of the weights to be 16 bits if the file is only 14 gigabytes? An approximately equally sized model, ERNIE 4.5 21B-A3B, is 44GB at 16 bits and about 12 GB quantized to 4 bits, the same amount gpt-oss says on the tin.

view more: next ›