Hi rustaceans! What are you working on this week? Did you discover something new, you want to share?
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😊
How difficult is writing an LSP? I would like to be able to use a reasonably complete implementation for Kotlin, but Kotlin is not a simple language.
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
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.
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.
