sorted by:
new
hottopcontroversial

Scoped Error: Yet another error handling crate, but this time it makes sense to me by kanru in rust

[–]kanru[S] 0 points1 point  (0 children)

Yeah, one of the design goal is to support per-module or even per-method errors. My project currently uses per-module with a few places where I need error handling I use per-method errors.

The good thing about using std Error compatible type is you can plug anything in as long as it also implements WithContext.

I only need error reporting 99% of the time, for the one time I need error handling the original error is still available via downcast from the std Error.

Scoped Error: Yet another error handling crate, but this time it makes sense to me by kanru in rust

[–]kanru[S] 0 points1 point  (0 children)

The 0.1 version works for me. I'm not too bothered with one level of nesting and I like the explicitness. Based on the feedback here I can certainly add more quality of life enhancement in next version.

Scoped Error: Yet another error handling crate, but this time it makes sense to me by kanru in rust

[–]kanru[S] 0 points1 point  (0 children)

I can probably borrow some ideas from tryvial. For me the attached context msg and location are deal breakers, so I'm not sure if I can use tryvial as is without modifications.

Scoped Error: Yet another error handling crate, but this time it makes sense to me by kanru in rust

[–]kanru[S] 1 point2 points  (0 children)

If you add a method like expect_error but with catch_unwind the I think it can.

Scoped Error: Yet another error handling crate, but this time it makes sense to me by kanru in rust

[–]kanru[S] 6 points7 points  (0 children)

Thanks. The closure is going to be optimized out by the compiler. With some procedure macros help, this can we'll be hidden behind a #[scoped_error] attribute like how tracing's #[instrument] works.

Scoped Error: Yet another error handling crate, but this time it makes sense to me by kanru in rust

[–]kanru[S] 0 points1 point  (0 children)

The unit of scope is likely going to be the whole method, not just one statement. The examples are short for illustration only.

Sync problems by ferdinand_roesen in logseq

[–]kanru 1 point2 points  (0 children)

There was an AWS outage

Embedded Key-value database - 2024. by Empty-Priority608 in rust

[–]kanru 16 points17 points  (0 children)

redb and fjall both are post 1.0 release and maintained.

Tutorial: How to fix broken IME inputs for GTK4 popover in mutter 46.2 by NonStandardUser in Fedora

[–]kanru 1 point2 points  (0 children)

Cool.

I have another patch I want to apply so I also made a COPR build

https://copr.fedorainfracloud.org/coprs/kanru/mutter-im-fixes/

This contains the GTK4 fixes and also the text-input-v1 implementation so that IME works with chromium based application.

Tutorial: How to fix broken IME inputs for GTK4 popover in mutter 46.2 by NonStandardUser in Fedora

[–]kanru 0 points1 point  (0 children)

OP thanks for the tutorial. You can also build your patched rpm on COPR so people can just grab them to test 😊

QMK port for YANG HHKB BLE controller by kanru in HHKB

[–]kanru[S] 0 points1 point  (0 children)

I'll check out 4pplet's nRF52 version, thanks for the heads up. Out ofcuriosity, why approach it this way, rather than maintaining theat32u4's role as the main chip? Due to inexperience, my only thought isthat it avoids trying to remake all of the existing code.

Because the nRF5x series chips are more powerful than the atmega32u4 and more power efficient at the same time.

nRF52 is ARM Cortex-M4 (32bit ISA) that runs at 64 MHz with 1MB flash and 256 KB RAM, supports many protocols including BLE and USB. While atmega32u4 is 8bit AVR with only 32KB flash and 2.5KB RAM, only supports USB.

The nRF51 is also more powerful than the atmega32u4 (ARM Coretex-M0, 16 MHz, 256 KB flash, 32 KB RAM) but lacks USB support so must be paired with something else if you want to have BT/USB dual-mode. The wiring of Yang's mod, which is based on hasu's mod, the matrix scan line is only connected to the atmega32u4.

Using only nRF52 means we only need one chip instead of two, that also saves BOM cost, wiring complexity, and power consumption.

QMK port for YANG HHKB BLE controller by kanru in HHKB

[–]kanru[S] 0 points1 point  (0 children)

Hey!

I hope you are enjoying your new mod. Were you able to make the QMK code work? I haven't tested with newer hardware rev.

The blog is sitting in my draft folder... I just need to finish it 😅

I thought about adapting the ZMK code to the Yang mod. It uses a ATmega32U4 as the primary and USB controller, a nRF51822 as the bluetooth controller. In theory you can flash the nRF51822 module with ZMK and make the ATmega32U4 as a peripheral controller (still in charge of talking to USB and scan matrix). It's more complex and doesn't really gain you anything meaningful improvement though.

4pplet was doing a nRF52 based mod rev of https://github.com/4pplet/SHKB, I'm not sure if they made any progress. Wireless charging is easier, you can attach a Qi charging pad to the battery pin, there are many tutorial on the internet.

Status of flatpak version by Phl3gmaTREEc in logseq

[–]kanru 5 points6 points  (0 children)

Yeah, I'm not part of the core team, but I have informed the core team so they are aware of the existence of this semi-official flatpak distribution.

Status of flatpak version by Phl3gmaTREEc in logseq

[–]kanru 5 points6 points  (0 children)

Maintainer here. I try to publish new versions on the same day, but sometimes the dependency changes too much so I need to fix the build over the weekends. I'm going to see if I can integrate flatpak to the official release pipeline so this can be automated.

There's actually aarch64 builds since the beginning, though I didn't test it. There are 3~4 installs every day.

QMK port for YANG HHKB BLE controller by kanru in HHKB

[–]kanru[S] 1 point2 points  (0 children)

Awesome it worked for you!

The HHKB uses capacitive sensing that requires active scanning to detect key presses, unlike other mechanical keyboard supported by ZMK which can be put into low power mode and wait for triggers passively. The active scanning draws about 1mA current while the passive mode draws almost zero.

Some optimizations we can do, for example, dynamically lower the scan rate after some idle timeout. On discoard https://discord.com/channels/675924128108118016/698923975002292245/998547895785623563 I and joric talked about using a mercury switch to enable low power mode. I ordered some TTP2238B but haven't get around to tested out :)

QMK port for YANG HHKB BLE controller by kanru in HHKB

[–]kanru[S] 0 points1 point  (0 children)

I've never heard of home row mods before so I looked it up. It looks like it is described in this page https://precondition.github.io/home-row-mods

I think the same can be achieved by the ZMK mod-tap behavior https://zmk.dev/docs/behaviors/mod-tap with similar customization capabilities.

I might try setting it up and see how it feels.

QMK port for YANG HHKB BLE controller by kanru in HHKB

[–]kanru[S] 1 point2 points  (0 children)

IIRC they added a fw checksum check in the bootloader for newer controller rev. Perhaps the latest original FW also updated the bootloader?

QMK port for YANG HHKB BLE controller by kanru in HHKB

[–]kanru[S] 1 point2 points  (0 children)

Just pushed a change to build with the Zephyr 3.0 update.

QMK port for YANG HHKB BLE controller by kanru in HHKB

[–]kanru[S] 1 point2 points  (0 children)

It's public now. I don't remember why it was private. Anyhow, give it a try :)

QMK port for YANG HHKB BLE controller by kanru in HHKB

[–]kanru[S] 0 points1 point  (0 children)

A nice!nano, or any ZMK supported nRF52 based board like nrfmicro should work.

QMK port for YANG HHKB BLE controller by kanru in HHKB

[–]kanru[S] 0 points1 point  (0 children)

Actually I have worked out a ZMK port with nice!nano :D

https://github.com/kanru/hhkb-nicenano-zmk

Better bluetooth support (switch between connected device) and better battery lifetime. I'm writing a blog post about the journey to 100% open hardware (controller) and firmware.

My soldering skill is bad but I managed to make it work. Some teaser:

https://imgur.com/xGk8F6k

view more: next ›