i'm tricking the nintendo switch into thinking my computer is a bluetooth pro controller. I'm using a crate called bluer which exposes bindings to the BlueZ stack and it's been great to use.
I got to the point where it pairs the controller and hits B to exit. However it doesnt seem to accept any more button presses after that... :) So I have some ways to go.
I've also needed a project where I can challenge myself with the basics of async without it being overwhelming, and I think this hits the sweet spot. It's my first time using tokio spawn, join, and select in a real project!
I am currently writing an LSP for the shaderscript used in Godot. Its close to glsl but some differences make me not wanting to just copy paste a glsl one. I am currently trying to wrap my head around chumsky. I am coming from a lot of c code and my head doesnt work like chumsky does, so it has its ups and downs, but lexer for glsl and lexer, parser and like half oft the evaluator for the preprocessor are done and working😊
Well you're writing a Compiler with extra features to tell you where compilation failed but without actually executing the code. If the language you are trying to implement has defined a BNF for its language its quite doable and depending on the features you want to implement almost easy. There are BNF interpreters and chumsky e.g. is close to reading like a BNF. But if you're building a language where you gotta find out the rules yourself it can take a while and finding all the edgecases can be a problem... But the project is big enough that most probably don't finish theirs
Just started reading the Rust book. Made it through Chapter 3 and finished the suggested Fahrenheit/Celsius converter. Been trying to figure out the next suggestion, finding the nth number in the Fibonacci sequence.
Rewriting huge parts of the IDL compiler for Nucom, my implementation of Microsoft’s COM binary interface standard and (in the future) network protocol. The original version was hacked together with a lot of assumptions made in the parser and isn’t very extensible, and I do need to extend it now.
(Nucom is another way to have a stable ABI for Rust, e.g. for a plugin interface, and for Rust/C++ (and more OOP-style C) interop, based on objects with vtable pointers. And hopefully sometime in the future, transparent IPC and networking so you don’t have to load plugins into your process’s memory space if they don’t need to be there, with it working the same as if it were direct calls. All of this I assume you can already do on Windows with the windows-rs crate but it's obviously Windows-only.)
I do have to say though, I need a better way of transforming my syntax tree. Right now I’m just copying the struct definitions over and over for each compile stage and manually writing code to copy everything instead of just the parts I’m actually transforming, and it just seems like there has to be a better way. I might want another proc macro for this.
Still working on Church A/V stuff. The software I made allows us to control an RS-232 PTZ camera via an Xbox Controller, or our slideshow program (ProPresenter). This week we switched from an Xbox Controller to a flight stick, and I added the ability to change the max speed the camera will move at in software.
I actually introduced rust to my workplace this week, with a workshop reimplementing part of one of our service.
It seems people liked it. Now I want to look into how we could create Conan packages (to be consumed by c++ code) out of crates. I guess I'll use the CXX crate to generate C++ headers, but other than that I don't know.