New week, new Rust! What are you folks up to?
Trudging along with my communication middleware -- almost have all the message passing primitives in place (working on the last one now).
Next, I'm going to work on authentication. I settled on a way to support "any" authentication scheme. Less work for me, more work for application developers, but it should mean that basically any authentication framework can be used.
Writing documentation. Now that my parser generator can also produce bottom-up parsers and not just top-down parsers, I'm adding that part to the existing doc.
But it's awkward to mix explanations of LL(1) and *LR (LALR for now) versions, yet they're not too different from the generated interface's perspective, so writing two separate doc doesn't feel right; showing the differences seems preferable.
I find myself limited by mdbook, hence my question about preprocessors in another category. I don't really want to port everything to another system, either (especially since nobody seemed interested in it so far).
I'm working through some improvements in my recently-release typed-ident crate.
Namely I'm adding some new case profiles (#1), and cleaning up the buffered types API (#5).
This is a bit of a niche crate, but it's been fun to work on, and I need it for some other crates.
EDIT: And v0.0.2 is released! You can view the changes here
Yesterday released update for the historia - event-driven framework I'm working on. Added NATS as a supported broker in addition to Kafka.
Curious thing about features management I'd like to share, perhaps it will be useful for someone else:
My project has multiple crates one of which is transactional outbox implementation which is provided as both binary and library. Binary requires exactly one broker feature to be enabled. I'm using macro to validate it, if multiple broker features or none are enabled, it throws compile error. While I had only one broker feature it was fine to run tests, coverage reports and other checks with --all-features flag but now it breaks the binary compilation. As long as I have a lot of optional features (I'd like to let the users pick only what things need) I don't really want to enumerate features in --features ... flag. So my idea was to disable binary compilation.
Initially I thought that I can just pass --lib flag so only my libraries will compile. And yes, it actually compile only libraries... but not integration tests which are binaries. In that case my integration tests are not included in coverage report. Not an option. If also enable --test flag (which should enable integration tests too) I found that it tries to compile my binary crate too. I'm not sure if it's expected behavior but in my case it worked like that. So it's not an option either.
The working solution I found is add another feature and add it to bin's required-features in Cargo.toml. It allows me to control whether I'd like to compile the binary or not. But as I mentioned earlier I don't really want to enumerate all features I have in each command I run. So the simplest solution was to add another full feature which enables all of them but not the one which controls binary compilation. In that case I'm able to run something like cargo llvm-cov --features full ... and have my coverage working fine, include integration tests but not compile the binary which has mutually exclusive features.
Full example of how it's done can be found in historia repo.
I got my Pali text analyzer working with Tantivy:
pub enum AnalyzerConfig {
Algorithmic,
Dictionary { stem_file: PathBuf },
}
impl TryFrom<AnalyzerConfig> for TextAnalyzer {
type Error = Error;
fn try_from(config: AnalyzerConfig) -> Result<Self, Self::Error> {
match config {
AnalyzerConfig::Algorithmic => {
Ok(TextAnalyzer::builder(PaliTokenizer::default())
.filter(LowerCaser)
.filter(stop_word_filter())
.filter(AlgorithmicStemmer)
.build())
}
AnalyzerConfig::Dictionary { stem_file } => {
let reader = Reader::from_path(stem_file)?;
let table = StemTable::try_from(reader)?;
Ok(TextAnalyzer::builder(PaliTokenizer::default())
.filter(LowerCaser)
.filter(stop_word_filter())
.filter(DictionaryStemmer::from(table))
.build())
}
}
}
}
After having been occupied with some other tasks, I finally found some time to refactor the code of our Zigbee stack.
I am working on a sports tournament engine. I have implemented one already in php years ago, but want to do a full revamp in Rust :). The idea is to be able to run offline (we encountered often tournaments at places with poor internet connection) but then also sync with a server. To that end I want to use an append-only transition log that defines everything about the tournament.
As a starting point for this transition log I have created a small independent crate undoable-state-machine.
Everything should be open source in the end, that's the goal :).
Am trying to implement an Event Driven architecture in a webapp to get exposed to more problems within rust. Learning architecture is super fun with cargo. I'll hopefully write a small post to help other people figure it out if I get good enough.
Implementing WAL for my database written in rust
Working on own formalization platform + utilities for it.
I'm also starting to move my repositories to Codeberg. GitHub was fine as a service, but my values aren't aligned with that place any more.
I've started with the trait-gen and vectree crates, and archived their corresponding repositories on GitHub. Next, I'll try one I'm working on more actively to see if the server is stable enough.
Sadly, it doesn't seem to have the equivalent of GitHub's Pages, though. I'll have to leave my doc there for a while.
I didn't yet try it myself, but Codeberg has docs about their Pages service.
A little late, but here what I have done this week:
I re-write a popular 3D demo from Godot Engine from GDScript to Rust, using the Rust bindings (gdext: https://godot-rust.github.io/), my intention is to use it in future projects as reference for my gameplay code, I even had a version with bevy_ecs integrated to it, raw stuff but functional 
I used an approach that I wanna try for sometime, basically divide the re-write into two parts (three in this case):
v1/main - raw port, a direct translation of each GDScript file into one gdext class with the same base node, no abstractions, no optimizations, the result is a rust that still reads like Godot GDScript (Godot engines default scripting language).
With the v1 as "baseline" I made it to the second round.
v2 - (a fork from v1 baseline) remodel the code around rust's type system and idioms, and separate engine glue from testable game logic. Two pillars: 1) the type system does the validating, enums with data instead of loose flags and counters, typed config parsed once, typed signals and references. 2) interface vs. implementation, the engine-facing trait impls and #[godot_api] blocks are thin glue, and the game logic lives in plain rust modules with no engine types, unit-tested without the need of running Godot entirely, very useful for production deployment and testing.
v3 - (a fork from v2 after completion) Is more an experiment of mine than something that I will probably use in any serious project, write the gameplay as ECS systems over entities, with bevy_ecs sitting over the Godot nodes: the node becomes a view of its entity, touched only by an explicit sync layer, I lost the cache locality benefits of bevy_ecs but that is fine, because the idea here is to write Godot gameplay allowing us to think in terms of systems and entities, which I think is a better mental model during development.
Thanks! 
I completely missed that bit; I haven't read all the doc yet.
-
JavaScript input => Rust ECMAScript interpreter (boa) => native binary and WASM targets
-
Compiling V8's
d8shell to WASM. was not intended for that purpose; hasn't been done, yet. Not strictly Rust related.
[quote="Redglyph, post:13, topic:142419"]
GitHub was fine as a service, but my values aren't aligned with that place any more.
[/quote]
Interesting. If you don't mind me asking, what specific "values"?
I sometimes marvel at how much "social" ideologies get baked in to technological decisions.
Sorry for intervention but I also decided to move from github to codeberg because of “values” and yeah, in my case the decision is more “social” than technical.
First of all their AI policy. They train copilot on my open source repos by default, without asking my permission. Although it might be disabled, it still not obvious and completely disrespectful practice IMO.
Another reason is more technical - github CI. I don’t like it as a concept when I have to rely on code snippets written by other people by design. This system already has abused so if you don’t pin the action version, it will load the latest version by default which may contain malicious code (see actions-cool/issues-helper case).
Codeberg is not as mature as github, it may lack some features and it might be non-trivial to make CI work there but it’s fair with me. That’s why I moved.
Privacy and the AI policy are an important part of my reluctance for GitHub, too. Privacy is obviously not something we can trust Microsoft and GitHub with. That privacy was violated to train an LLM-based AI, of all things, and while it's not the worst one (meaning the one that consumes the most insane amount of resources), I'd rather not be associated with something like that.
Then they're based in the US. Since I'm in Europe, and given US has recently turned away and aligned itself with, let's say, other ideals, I'll take my distance where I can, even if I can't afford to do it for everything. I have no idea of how that'll turn out, but I prefer my data to be here rather than there.
Codeberg is indeed not as mature, but it has a better overall policy, including regarding AI, and it seems to have the necessary features. I'm hesitating between that and SourceHut, where AI is completely banned and which allows private repositories without restrictions (I think—I haven't looked at the details nor tried it yet).
Technology is there to help us, not the other way round. People seem to forget that sometimes.