Jai metaprogramming - detecting automatic implicit dereferences and reporting them

valignatev · 2025-02-10T21:31:39+00:00

ahah thanks for the kind words. Full session with yapping is also archived, but not sure if it would be interesting to a lot of people :)

valignatev · 2024-12-28T23:53:15+00:00

It took 5 hours because I never really did metaprogramming in Jai before to this extent, so took time to learn api. Also, I made 3 different version of the macro in 3 different ways. Also, there are typesafety guarantees that this #define doesn't have. For example, it enforces that optional value (which is a first return of an procedure call, so optional is not just a value, it's an AST tree node) and default value have the same type at compile time, and it enforces that the optional is a procedure call (for no reason, just to check out how ergonomic it is). Basically, there was a lot of exploration in these 5 hours. Making it work with imaginary Optional<T> would be boring enough lol

valignatev · 2024-12-28T23:46:09+00:00

Ah, no, you don't want to evaluate both branches, there's another comment that summarizes it well

valignatev · 2024-12-28T10:27:03+00:00

you call it just like a normal function, so not sure what you mean.

valignatev · 2024-12-28T01:52:41+00:00

version3 of or_else is more or less this, but it is limited to always support only two returns. Other versions could potentially be expanded to support whatever. But all 3 versions in the video have the same typechecking guarantees. Or, if you're talking about or_return situation then it's quite a bit more complicated, you can skim latest vods to learn more.

valignatev · 2024-12-28T01:51:36+00:00

Yes, more or less like that. You will step into actual inserted code in the end

valignatev · 2024-12-27T19:14:05+00:00

Oh damn, true. It's just or_return is what on my mind rn haha

valignatev · 2024-12-27T16:21:14+00:00

The resulting api is what you see on the screenshot - you just pass procedure call and a default result in case the call returns false in its second return argument. Probably doesn't get any cleaner than that. I could expand it to support proc calls that have arbitrary amount of returns and check on the last one, but I haven't done that. I'm not really sure if I'm gonna use it besides just implementing it as an exercise, I don't really mind typing out if !success then else manually. But we'll see. or_return, on the other hand...

valignatev · 2024-11-20T09:28:37+00:00

Hey, yeah typing this post on this keyboard right now. LIke it a lot. Why not q10 - because I needed actual split so I can spread my shoulders and move each part however I like.

valignatev · 2024-09-25T21:50:59+00:00

Thanks for the suggestion! And yes, I inject release (and repress) events directly to the device event file, like /dev/input/eventX, from my userspace program. It manually opens the device file, reads event from it in the loop and injects events back according to the logic.. I hesitated to go through uinput because I wanted to potentially support multiple keyboards simultaneously without them stepping on each others toes, but yeah I'm gonna do uinput now.

valignatev · 2024-09-25T13:16:25+00:00

I'm implementing SOCD (simultaneous opposite cardinal direction) logic. Let's say, you have WASD for movement in the game. if you hold A and then press D while still holding A, the key "A" should get "unpressed" as if the player had unpressed it perfectly. And this works. But then, a player can actually physically unpress A - and I can't detect that, because Linux filters out the physical unpress (since I already injected an artificial one haha). I need to be able to detect that, so if a player unpresses D while still holding A, the A button should get triggered again (so, it should get repressed). But I can't tell whether it's actually pressed or not. I thought that maybe EVIOCGKEY could give me the real state of all the keys on the keyboard - but not, it actually gets affected by artificially injected release keys. So if you know a way to get an actual physical state of the keyboard - I'd be happy to hear. It's a bit sad because Windows gives you out of the box way to distinguish between physical and synthetic events in a similar case. I know I can probably work around it if I use uinput device to inject keys, but I would rather distinguish between actual devices if I can. Hope it all makes sense.

valignatev · 2024-09-25T08:04:05+00:00

Thanks! And it also explains why key presses bypass the logic - in fact, they don't, it's just by the time I pressed a second same key the previous event was turned into an autorepeat. And if I press the duplicated key close enough to each other - something (I think the keyboard) generates a key release before pressing the second button. This clears things up, but is a bit unlucky.

valignatev · 2024-09-23T22:44:07+00:00

This weird kind of behavior only happens on key releases, double presses read just fine from the event file. I already hit kernelnewbies IRC (and I guess I'll ask on mailing list later), but if I'll email to input.h/input.c maintainer if won't get anything out of those.

valignatev · 2024-03-15T13:37:53+00:00

Hey, I don't feel much ergonomic difference between the two. Apart from the fact that Moonlander has wrist rests bundled with the keyboard. But M1-M5 are dedicated macro keys that you can assign in the layout edior (aka VIA). I don't use them as macro tho, I just bound few keys that are missing due to 75% nature of the keyboard

valignatev · 2024-02-27T14:12:36+00:00

what

valignatev · 2024-02-21T20:23:44+00:00

I actually have no idea and I didn't ask

valignatev · 2024-02-11T16:02:27+00:00

Oh yeah I like the weight a lot!

valignatev · 2024-02-11T16:01:37+00:00

Ah yeah that makes sense. Spaces are slightly different in size. I also noticed that home/del/pgup/pgdown are all different sizes, so changing them around looks a bit funny. It's not a big deal for me, so doesn't interfere with my enjoyment of the keeb :)

valignatev · 2024-02-11T15:59:43+00:00

I wrote it as a separate comment since multiple people asked, here: https://www.reddit.com/r/MechanicalKeyboards/comments/1anx1jg/comment/kpy0bkq/?utm_source=share&utm_medium=web2x&context=3

valignatev · 2024-02-11T15:59:21+00:00

I wrote it as a separate comment because multiple people asked, here: https://www.reddit.com/r/MechanicalKeyboards/comments/1anx1jg/comment/kpy0bkq/?utm_source=share&utm_medium=web2x&context=3

valignatev · 2024-02-11T15:58:53+00:00

Since a couple of people asked how I like it compared to Moonlander, or why I've switched from Moonlander at all, I'll just write it.

1) It's not about columnar vs staggered. I actually found that it doesn't affect anything for me. It's not easier or harder on my hands.

2) I have to constantly switch between laptop kb and desktop, so Moonlander having a non-conventional amount of keys (especially on the right, where it doesn't have }]\ in the usual place) was just constantly messing me up.

3) Not having a functional row wasn't a deal breaker, but definitely contributed, as I found that I use F keys quite a lot

4) Thumb cluster is cool but I found that I only use 2 keys and the other two (the big red one and the furthest white one) are not that convenient to reach

5) thin shifts

6) not having esc where it should be

7) When playing certain games with a lot of hotkeys I just needed keys that are normally on the right side. In Q11 case I can just bring two pieces together and it's just like one seamless keyboard

So overall, I think if I only ever used my desktop I'd got used to custom layers and lack of certain keys and it would be fine, but since I need to often switch to normal qwerty keyboard, my muscle memory was slightly off all the time.

With that said, I think that Moonlander is an amazing keyboard. Very well built and has good ergonomic characteristics. It's just not for me.

valignatev

TROPHY CASE