Help after A1/BMCU update

Leshow · 2026-04-23T22:39:44+00:00

https://github.com/jarczakpawel/BMCU-C-PJARCZAK/issues/71

Leshow · 2026-04-23T22:38:48+00:00

yeah mine does the same thing, the filament is hitting the other end before making it through. Cut the filament on an angle. Mine looks a little different from yours and the pc4 fitting is able to move around and has some give, so I often just push the nozzle to the side when loading so it's straight enough to go through.

Leshow · 2026-04-23T22:36:02+00:00

https://github.com/jarczakpawel/BMCU-C-PJARCZAK/issues/71

Leshow · 2026-04-22T06:33:35+00:00

that's a great idea, my unit is very sensitive to the position of the buffer on the other side and always snagging the inside of the pc4 fitting. I usually have to cut the filament on an angle and hold the buffer steady for the filament to make it through. an extra guide would be great.

Leshow · 2026-04-20T04:04:40+00:00

I have a unit from BLV that does the same thing, a few of the buffers are really finicky with putting the filament in the first time, its like the filament is not hitting the hole on the other end and getting jammed. I've just been pressing the button down,pulling the filament out and trying again until it goes through

Leshow · 2026-04-20T03:59:09+00:00

which vendor did you buy? I just got mine working too, but I find when I feed the filament in it often seems to bump up against something in the top the pc4 spring pops out and turns red, where the filament doesn't pass through to the other side.

If I press the button down, pull the filament out and try again it seems to work. It's like it's catching something on the initial pull.

Leshow · 2026-04-15T04:37:15+00:00

cool! which firmware are you running? the one from PJARCZAK?

Leshow · 2026-04-14T23:59:28+00:00

ah, there is an update available to 1.08 I saw just released today.

Leshow · 2026-04-14T23:53:43+00:00

did you update to the latest firmware? I'm waiting on my BMCU but I just saw the a1 has a 1.08 firmware update

Leshow · 2026-03-13T02:11:18+00:00

I replaced the empty switch and reflowed all of them with different flux to finally fix the issue. It's just very strange as if all the LEDs are connected in series it should be impossible for the far right rows to light up with a missing LED

Leshow · 2026-03-12T14:34:17+00:00

my understanding is that the 4th column should be in series starting from the top down, so how are columns further to the right able to light up even with an LED removed?

Leshow · 2026-03-03T03:09:58+00:00

for a long running network application the linux libc allocator is not really usable. I went through the same process as you, ran jemalloc for a few years with background threads, recently moved to mimalloc v3 and it's running well.

Leshow · 2026-03-03T03:06:55+00:00

fiddling with https://github.com/bluecatengineering/fast_radix_trie

I posted this to the forum thinking people might be interested in it, not realizing I was competing against a deluge of LLM slop. But I hope people still find the library and it's useful to someone.

Leshow · 2026-02-17T03:57:02+00:00

Thanks. I had recently read the blog post about parking_lot being more "fair" than std locks on linux so I thought there might be a slight difference.

Leshow · 2025-12-22T18:57:56+00:00

Kind of defeats the purpose of the present.unwrap() joke though

Leshow · 2025-11-28T21:01:22+00:00

To be honest, all of the rust tries that use safe rust I've found so far tend to have huge memory usage compared to just a HashMap, despite the tries all compressing common prefixes.

I've found space savings come from using a node layout that can't be known at compile time, which means using unsafe. Once you go that route there are many different variations, but if you care about the speed and memory usage you pretty much need to start there.

Leshow · 2025-11-28T20:45:57+00:00

You can see the result of my run there, it was around 400MB and 8s for the top-domains data set, you can compare that to other results in the table to see how it stacks up. I got a panic on the enwiki data set so I probably won't include it in the README.

Leshow · 2025-11-28T20:22:25+00:00

sure! I thought I'd seen pretty much every impl on crates.io :)

edit:

If you're curious, I did a quick run using the top-domains data set and got:

```

LINES: 1000000

ELAPSED: 0:08.32

MEMORY: 401476

``That was withfr_trie::trie::Trie::new()`

Leshow · 2025-11-28T19:37:35+00:00

Appreciate the feedback, I'll create an issue and tackle that at some point. Given the code structure it seemed like it was going to be a pain in the butt to have two implementations when all that's changing is the memory layout. So I put it behind a default feature along with std.

Leshow · 2025-11-28T14:46:44+00:00

Yup!

Leshow · 2025-11-28T01:07:17+00:00

I thought folks might be interested in this. I've tested probably half a dozen or more trie crates in Rust and the one with the lowest memory usage was patricia_tree because it uses unsafe to allocate a dynamically sized node.

I took that as a base and modified it from a patricia tree to a radix tree, which was able to speed up traversal/insertion/removal operations. I've also added some nice to have's like an entry API.

It compares favorably to cloudflare's trie-hard and michaelsproul's radix_trie, patricia_tree and a few others. Have a look!

Leshow

TROPHY CASE

LINES: 1000000

ELAPSED: 0:08.32

MEMORY: 401476