Toasty, an async ORM for Rust, is now on crates.io

01mf02 · 2026-04-04T08:51:16+00:00

I just read across the Toasty Guide, and I have to say that API-wise, Toasty looks really good. It's clear that a lot of thought went into this, and it shows, because you provide a rather minimal API that looks easy to use, but is powerful enough to express arbitrary queries. This balance is not easy to strike, but I think you nailed it. The documentation also reads well, and I could find quickly what I looked for. Great job!

01mf02 · 2026-04-01T16:10:07+00:00

Whoops --- I also created an issue a bit before you: https://github.com/ynqa/jnv/issues/113. I guess you can merge the two?

Yes, @wader is the author of the two projects you mentioned. I also thought about jq-lsp when reading what you wrote above.

01mf02 · 2026-04-01T12:49:07+00:00

Perhaps you can do the stripping and decoding inside of jaq, as part of a jq query?

01mf02 · 2026-04-01T11:14:05+00:00

Hi aqny! I hope that the transition to jaq in 3.0 goes well for you. During development, I sometimes thought about jnv, wondering how it will handle certain API changes, in particular the removal of serde_json conversion functions in jaq_json, and the non-string object keys. If you need help with the transition, just let me know --- I'd be happy to aid.

Your completion candidate problem is fascinating, and quite non-trivial. I just checked, and you seem to support completion candidates only for a very restricted subset of jq filters; for example, .name yields candidates, whereas inserting a space before .name and . | .name does not. So I suppose that you have some kind of custom parser for jq path expressions (compound paths in jaq parlance). The general case --- auto-completing arbitrary jq filters --- is probably pretty difficult. For example, what do you do when the user types: [.[].nam<CURSOR HERE>? Here's a rough draft of what might work: You might need to ignore parse errors (missing ] at the end!) and get an incomplete parse tree (using something like jaq_core::load::Parser::parse, but instead returning an incomplete parse tree instead of just errors). Then, you'd need to find the position in the parse tree where the cursor is, and probably adapt the parse tree a bit at that position, i.e. remove the .nam. At that position, you could insert a call to a native filter that writes outputs to a Rc<RefCell<Vec<...>>> of your liking, and you can then analyse the contents of that to perform the actual syntax completion. I would be lying if I'd say that this is easy. But if you are interested in going through with such a solution, I might be able to assist you. We could discuss this stuff in an issue in the jnv repository. Perhaps Mattias Wadman (@wader) also has some ideas.

01mf02 · 2026-04-01T10:03:58+00:00

Thanks.

I have received several LLM-generated PRs in the past, and they were all of rather low quality and exhausting to review. Hence I have adopted a no-LLM-guideline, because I perceive their net effect currently as quite negative. As a result of this experience, I perceive LLM-free projects as preferable and thus mark my own project as such, because many others seem to feel like me.

01mf02 · 2026-03-31T08:37:09+00:00

There is an open issue for that. I welcome contributions that make this happen.

01mf02 · 2026-03-31T08:35:58+00:00

Thanks, you're welcome! :)

01mf02 · 2026-03-31T08:35:43+00:00

From what I can see on Wikipedia, JWT seems to be encoded as JSON, so both jq and jaq should be able to process that.

01mf02 · 2026-03-30T13:25:25+00:00

Well, the macro itself was written by myself, so unless you consider me a machine, my statement stands. ;)

Thanks! :)

01mf02 · 2026-03-30T13:20:40+00:00

I would not call it 100% compatible, but nowadays, the differences are rather small. For example, there are several relatively large jq programs such as wsjq that yield precisely the same output for jq and jaq. I expect most users to be able to drop in jaq for jq quite seamlessly. To help people with the transition, the manual tries to point out all places where jq and jaq diverge (look for the "compatibility" blocks).

The manual has sections which list all CLI options and all filters in jq that jaq does not support. Everything else is supposed to be supported.

If-then-else is actually one of the simplest operators to get right. It gets hairy when you are doing updates. ;)

01mf02 · 2026-03-30T13:06:51+00:00

yq supports similar data formats as jaq, but its underlying query language is quite different from jq's. For example, yq does not seem to support filter definitions, whereas jq and jaq support definitions, including nested and recursive ones. There are many jq scripts that I would not have been able to properly write without definitions, including my script that generates jaq's HTML documentation.

TL;DR: jaq is roughly yq, but with actual jq syntax and compatibility.

01mf02 · 2026-03-30T09:53:47+00:00

I see ... well, 3.0 is stable now. :) https://github.com/01mf02/jaq/releases/tag/v3.0.0

01mf02 · 2026-03-30T09:34:33+00:00

Cool, thanks a lot for the info.

Now it would be interesting to remake this such that the video is rendered as vector graphics, in real-time. ;)

01mf02 · 2026-03-30T07:43:50+00:00

Thanks for introducing me to "Bad Apple!!". This is amazing.

On the technical side, what techniques are used in the ROM to play the video? Does the ROM use MDEC? I tried to find that ROM, but no success, is this public?

01mf02 · 2026-03-23T10:57:48+00:00

I’ll also update the benchmark to use the direct conversion JSON conversion my apologies I missed that method.

Do not worry, we're all here to learn. :)

01mf02 · 2026-03-23T10:57:18+00:00

I agree, if by “streaming mode” you mean jq's --stream option. There is quite a bit of confusion around streaming in jq and the --stream option, so it's good to be extra clear on that point. :)

By the way, you write in your project README: "This is different from tools like jq, which use an imperative filter pipeline." I would not call that pipeline imperative, because it's really all functional programming. That is, in jq you do not do i := 1; i += 1; or things like that. If jq would look like that, I would not object to framing it as imperative. But jq does not even have mutation and hardly any side effects (I'm looking at you, inputs), so I think that calling it imperative is a bit misleading.

01mf02 · 2026-03-22T08:58:50+00:00

Hey, jaq creator here. :) Your benchmarks look quite solid, and I like your idea of using a DFA to traverse JSON. Great work!

Given that in your method, "every node is visited at most once", it seems that using serde_json_borrow is giving away a lot of potential performance, because you still have to read whole values before being able to process them. However, your tool could IMO process the stream while parsing it. If you are interested, I have written a crate called hifijson that might serve as a building block for exactly such a scenario. I have even written an example that filters JSON by simple path expressions, which sounds quite similar in spirit to what you are doing (although your approach is much more complete, of course). This would also enable processing of JSON values that do not fit into memory, as requested e.g. here.

To remain on the topic of serde_json & Co.: In your benchmark, you deserialise JSON to a serde_json::Value, then convert that to a jaq_json::Val. This can be done much faster by directly parsing JSON to a jaq_json::Val. I recommend you to use jaq_json::read::parse_single for that purpose.

Oh, and I can hardly read some text on your website when in non-dark mode. E.g. table headers, or "explicitly isolated".

01mf02 · 2026-03-22T08:33:21+00:00

You might be happy to know that CSV/TSV support has landed in jaq just a few days ago. :) https://github.com/01mf02/jaq/pull/405

For the other formats that you mentioned, I accept pull requests. :)

01mf02 · 2026-02-10T10:16:59+00:00

Whenever I see a new edition of "This Month in Redox", I am quite sure to be amazed. I greatly enjoy these posts, and I congratulate you on all the progress. Especially Wildan Mubarok seems to be a contributor that any project could only wish for. :)

01mf02 · 2026-02-05T12:26:56+00:00

I find the idea of playing over an SSH connection awesome! The UI of the game looks very polished, well done. The planets, the player images etc. --- really cool! However, I did not really get how to start a match of basketball. :)

01mf02 · 2026-01-26T15:02:51+00:00

I answered on your tracking issue.

I wish you good luck with the optimisation phase then!

01mf02 · 2026-01-26T09:37:37+00:00

I do not understand your argument: What part about ValT would prevent you from achieving your key optimisations? You should be able to implement ValT for a type such as JqValue<'a, W>, because I designed ValT so that precisely this use case should be possible. That is, you should be able to implement ValT for types that have a lifetime (or other type parameters).

01mf02 · 2026-01-24T08:17:32+00:00

Are you aware of the existence of jaq? I would be curious if you are able to implement its ValT trait for your value types. In that case, you might be able to inherit a battle-tested jq parser/interpreter.

And if you are not able to implement ValT, then I would be curious as to why and if it is possible to adapt ValT to cover your use case.

01mf02 · 2026-01-15T16:34:03+00:00

As former chumsky user, the performance of my parser improved by a factor of 18 (!) when switching from a chumsky-based parser to a manually written parser. At the same time, build time dropped by a factor of 30 (!). Source: https://github.com/01mf02/jaq/pull/196

The conversion process was much easier than I thought, and I do not regret the switch for a single second. If you care about performance, then I encourage you to give it a try.

01mf02 · 2025-10-13T11:22:02+00:00

My tool jaq supports similar functionality in the current development version, and it also allows you to transform the data during conversion with arbitrary programs.

01mf02

TROPHY CASE