so this is happening.

All my #Rust #RustLang repos are moved over. Now I just need to figure out CI, republish to crates.io, and archive the github side (and document a tombstone in their readmes).

I have a bunch of other repos I'll either archive or delete as well.

#KDL and #orogene will remain github-side for now because they're a bit more dependent on github services, but I would like to at least move orogene over eventually. KDL might be stuck, though, unfortunately, but I might move only kdl-rs.

#bevy #miette

semi-cursed idea: a #KDL representation of _every #XMPP stanza_, mostly for denser raw storage.

Most clients decide very-lossy data storage is good enough, but that doesn't satisfy me. The current storage mechanism for Spades is based on the XML stanzas (in MAM form) and the size of the XML in bytes represented as an ASCII number, wrapped in ASCII record/field separator characters. (Actually, the XML might be gzipped, I can't remember.) To condense it further, I could try to write a dense KDL representation and convert at store and read time. I could also try Brotli instead of gzip or xz.

I'm also thinking I'll want to split the history into multiple files (possibly by file size), and figure out how I'm going to page through that. Also it's all stored unencrypted at rest right now. (I think when I tried to do E2EE last, I had to have it save the unencrypted version because I had no direct access to the original encryption module to re-decrypt it; it's more or less embedded in the SDK and decrypted before I get it.)

@pid_eins
In many components of #systemd inluding mainly #systemd-userdb , JSON is used for configuration and serialization.
Although this is fine, #kdl could be a better format for that purpose...
https://kdl.dev
What are your opinions?

#kdl file formatter! Check it out:

https://github.com/hougesen/kdlfmt

secretly genius #xmpp idea: #KDL representation of Data Forms.

So this beast:

      Bot Configuration
      Fill out this form to configure your new bot!
      
        jabber:bot
      
      Section 1: Bot Info
      
      
      
        
      
      
      Section 2: Features
      
        contests
        news
        polls
        reminders
        search
        news
        search
      
      Section 3: Subscriber List
      
        20
        10
        20
        30
        50
        100
        none
      
      Section 4: Invitations
      
        Tell all your friends about your new bot!
      
    

(form)meta {
  title "Bot Configuration"
  instructions "Fill out this form to configure your new bot."
}
(hidden)FORM_TYPE jabber:bot

(fixed)"" "Section 1: Bot Info"
(text-single)botname label="The name of your bot"
(text-multi)description label="Helpful description of your bot"
(boolean)public label="Public bot?" required=#true
(text-private)password label="Password for special access"

(fixed)"" "Section 2: Features"
(list-multi)features label="What features will the bot support?" {
  (option)contests label="Contests"
  (option)news label="News"
  (option)polls label="Polls"
  (option)reminders label="Reminders"
  (option)search label="Search"
  news
  search
}

(fixed)"" "Section 3: Subscriber List"
(list-single)maxsubs label="Maximum number of subscribers" {
  20
  (option)10
  (option)20
  (option)30
  (option)50
  (option)100
  (option)none label=None
}

(fixed)"" "Section 4: Invitations"
(jid-multi)invitelist label="People to invite" desc="Tell all your friends about your new bot!"

Still looking for some help from an extra set of eyeballs or such for some #KDL consistency checking

From: @zkat
https://toot.cat/@zkat/114359709628259341

A request for folks interested in language grammar stuff who might look at the newest #KDL feature and try to poke holes in it: https://github.com/kdl-org/kdl/issues/510#issuecomment-2815654392

Finally managed to go back to my #KDL suffix type annotations PR, and I'm pretty happy with where I've landed so far with the usage criteria, which had gotten a bit hairy. These rules are MUCH more straightforward, and focus on preventing accidentally parsing something successfully as unexpected data, as opposed to yielding a parse error and telling you to use a different syntax.

What do y'all think? Does this make sense?

PR: https://github.com/kdl-org/kdl/pull/513

The PR to add bare suffixes to #KDL numbers is ready, if anyone wants to eyeball it and give their 2c: https://github.com/kdl-org/kdl/pull/513

This means that you’ll be able to write things like 20px, 10.5%, and 512GiB as numbers in KDL and have those suffixes interpreted as type annotations.

FINALLY got around to speccing out the new suffix type annotation feature for #KDL: https://github.com/kdl-org/kdl/pull/513 Commentary welcome! It's very exciting!

I believe right now that the complexity cost, especially taking into account that there's a serviceable escape hatch, and fairly good ambiguity/typo protection, is well worth the value of people being able to write DSLs that use this feature.

I am, by the way, mostly writing out the grammar/spec itself after a much longer discussion by a bunch of people who poked all sorts of holes in a silly idea I threw over the fence: https://github.com/kdl-org/kdl/issues/510

I am immensely thankful to the KDL spec and implementer community for everything they do! We're really all making an amazing language here.

Some example testcase errors, thanks to the awesome #miette crate from @zkat (who also authored #KDL btw!)

Alright!

I just released a first functional version of a new crate:

🔧 test-dsl at 0.1.0

🦀 https://github.com/TheNeikos/test-dsl/

To paraphrase the readme: test-dsl allows you to easily author tests by decoupling between the 'test harness', 'verbs' and 'conditions'.

It's role in your testing infra would be as boilerplate reduction, so that you can focus on just writing tests around the behaviour of your system. I'm using this pattern for example in a client-server context. So I have verbs like start_server 1, start_client 2, connect_client 2 1 etc...

Of course the meaning of these verbs is highly project-specific.

If a verb does fail, either by panicking or returning an error, you get a nice error output telling you exactly which file and which verb caused the error. Allowing you to more easily pin-point directly what went wrong, rather than potentially searching through a log.

It works great together with datatest-stable from the nextest project, but it works just as fine standalone.

It uses #KDL as the language to write your testcases in, so its fairly nice to read.

It's still missing more comprehensive documentation, but as a prototype it should work just fine!

It actually sprung out from having used this pattern a few times, and I didn't want to re-write the boilerplate around it, and maybe re-use some code between projects.

#rust #rustlang

GitHub is now officially highlighting #KDL docs!! On the app, too!

Realistically, would #KDL being officially standardized by one of the major international standards organizations influence your interest and/or ability to use KDL, especially at work?

There is a proposal for #KDL to extend it such that you can have things like 10% or 20px and have that mostly Just Work in terms of existing KDL features

But, t’s not as perfectly clean as I would’ve liked, and so I’m hoping others (you?) will help 👀 for other issues

https://github.com/kdl-org/kdl/issues/510

lol turns out that when you base a language on xml/s-exp and you give it a really lightweight syntax, it just kinda turns into a really really nice DSL format #KDL

I think that might be what actually sets apart node-based formats from JSON-semantic “map and array” formats. It’s much less convoluted, usually, to make the former look and feel like an executable language

https://github.com/kdl-org/kdl/issues/510 what do y’all think of this? I know I promised not to change stuff anymore but it’s… a reasonable ask, and I think this might be an elegant solution? #KDL

Is someone already working on a rust adapter that implements json-in-kdl to serde compatibility?

#kdl cc: @zkat

I should probably figure out a way to put this on the site but honestly, it's not the cutesy+professional vibe #KDL is really trying to give off so maybe I'll just post it here and be done with it.

how do y'all feel about this hypothetical package.kdl?

#KDL