dogma VS pulsar

Yes, the offset function does this by specifying an offset to branch to. For example the ICO dir_entry, which is a directory list of icon resources in the file.

- https://github.com/kstenerud/dogma/blob/master/v1/examples/i...

I'm facing this dilemma now with the Dogma metalanguage [1]. On the one hand, I want it to be small so that it can be picked up quickly and mastered easily (very important since its primary use case is documentation). On the other hand, it needs enough power to actually be useful in the real world.

In the end I opted to avoid most conveniences since they can easily be built using a few common macros such as `u16(v) = ordered(uint(16,v))` and the like, except for cases where it would be just silly not to (like strings and regex-style repetition chars ? * +).

But even then the spec is over 2000 lines long (admittedly the examples take up a fair bit of room, though).

[1] https://github.com/kstenerud/dogma/blob/master/v1/dogma_v1.m...

Hi HN!

I've just released the 5th beta of the Dogma metalanguage, which is designed to describe text and binary data for use in documentation.

https://github.com/kstenerud/dogma/blob/master/v1/dogma_v1.md

Most of the kinks are now worked out, and I'm hoping for a final release soon.

Notable changes:

* Cleaner byte ordering support with new byte_order, ordered, and bom_ordered functions

* New peek and offset functions

* Renamed swapped function to reversed

* More examples in the examples dir https://github.com/kstenerud/dogma/tree/master/v1/examples

Thanks to all for reviewing and helpful criticism :)

The diversity of notations stems from the fact that the current BNF notations are always lacking in something fundamental that each use case needs.

For me, the breaking point came in trying to describe binary formats. I eventually had to come up with my own: https://github.com/kstenerud/dogma

https://concise-encoding.org/ will be released this year and has been in development for 5 years. This one has been slow because of all the support projects such as https://github.com/kstenerud/compact-float and https://github.com/kstenerud/compact-time and https://github.com/kstenerud/enctool

https://github.com/kstenerud/dogma has been in development for 4 months and will be released in about a month. This is yet another support project for Concise Encoding (hopefully the last!).

https://github.com/kstenerud/kscrash was in development for about a year and a half before being released.

https://github.com/kstenerud/Musashi took just under a year before its first release as a MAME core (after a TON of testing - I spent 4x more time testing it than I did writing it).

But other smaller things that don't require so much precision I just write up in a couple of weeks and release, such as https://github.com/kstenerud/virtual-builders

The key is to build empathy with your potential users. What will their motivations be that lead them to try out your project? What will they be looking for when they use it? What would someone who has never seen the project before struggle with? (that last one is the hardest because you're so close to the project that it's hard to see what it's like to know nothing about it). These tell you what kind of UX you'll need, what kind of documents you'll need, what kind of tutorials you'll need, how to structure your project for your target audience, etc ("it's for everybody" is never a good idea).

A lot of times it comes down to recruiting people to just try it and do a brain dump of everything that goes wrong or frustrates or confuses them. I've done show-HN posts for things that are unreleased, just to get the valuable criticism. It's nearly impossible to develop good projects in a vacuum.

If you're not posting out of worry for doing it wrong, THAT is doing it wrong. The point is to find out where you're doing it wrong so that you can correct it! And that's where the crowd is a HUGE help.

I have two projects that could use help:

---

The first is Concise Encoding, a secure ad-hoc data format (think JSON, but secure, more data types, and also has a binary encoding). https://concise-encoding.org/

The spec is largely done, and I'm primarily working on the reference implementation (in golang) and portable tests (so people don't have to keep rewriting tests for every implementation), but I could use help getting other language implementations out there.

---

The second one is Dogma, a BNF-style metalanguage for describing binary and text data (because there wasn't a decent one for describing binary data). https://github.com/kstenerud/dogma

Dogma is mostly there as well, but while it is primarily focused around writing technical documentation (and I have written a syntax highlighter for VS Code), there are probably a lot of other tools that could be built around this technology (which I simply don't have enough time to pursue).

Two things, one which supports the other:

First is Concise Encoding, a secure, binary and text ad-hoc data format with full type support: https://concise-encoding.org/

Almost all existing data formats are horribly insecure and ripe for exploitation (many of them are already). And they can't be fixed because the formats aren't versioned.

-----------------

But describing the data format was painful because most existing metalanguages are only for describing textual grammars, and the few that support binary aren't really suited for documenting for human consumption.

So I'm putting the finishing touches on Dogma ( https://github.com/kstenerud/dogma/blob/master/dogma_v1.md ), a modernized BNF-style metalanguage with better expressiveness and binary grammar support.

For example:

A UDP packet consists of a source port, a destination port, a length, a checksum, and a body. The length field refers to the size of the entire packet, not just the body.

    udp_packet   = src_port

You may be thinking of Pulsar (<https://pulsar-edit.dev/>)?

> VSCodium is not "designed" to be less functional, since it is a project maintained by developers who are unaffiliated with Microsoft.

In today's (OSS) world, employment or affiliation doesn't matter much. Microsoft can propose what they want and get what they want from the project, at the end of the day. I don't think these independent maintainers have power to say "No" (if a VSCodium developer can chime in here, I'd love to be stand corrected), or they risk VSCodium to be forked to VSCodiumX, by developers who are friendlier to the megacorp which loves Linux.

Yes, VSCodium is a node to Chromium. "-ium" has a ring akin to "-ish" in today's conjecture. Freemium - Free-ish but not. Chromium - Chrome-ish but not. VSCodium - VSCode-ish, but not. This might be curse in the naming, but it feels like that, at least for me.

The blog post I linked quotes a tweet which supports what I'm saying, heck even the blog post does a much better job of detailing what I was trying to say here in my previous comments.

To circle back, the problem with -ium projects are, they are effectively banned from participating in the main ecosystem which drives these projects forward, and to be in "The Ecosystem", you need to use the closed source versions with pervasive data collection and whatnot. Heck, even Google abuses Chromium with "Experiments and Proposals", which they use to politely yet forcefully push the web to the places they want. VSCodium is the same getaway drug and test vessel for Microsoft.

Lure with Open Source version, trap with closed source version for "Full Benefits" (for the company, because user is the product).

> You're entitled to your own opinion, but Atom was developed by GitHub...

Yes & yes.

> which was acquired by Microsoft.

Yes.

> It doesn't help that Atom was discontinued last year, with the final version having been released in March 2022

However, it's forked as Pulsar [0], which I meant by "current form" in my previous comment. Again, it's MIT licensed, and that's not my favorite, but at least it's not a company editor now.

Atom's original developers started to build Zed, which is worst of both worlds currently (Open source with a closed backend, plus "All your data belong to us" clause).

At the end of the day, from my perspective "-ium" projects and their sanitized versions are just open-core versions of the "main tools" developed from them.

Just because these versions somehow work, and have a permissive license doesn't make them open source in the meta sense. Pedantically they are open source software, yes, but they are just the "Open Core" or Demo/Shareware versions of the tools which companies use to strange to ecosystems.

This is just enshittification of open source in my eyes.

More power to you if you're happy with the -ium tools, but I'd rather use truly free software (Like Eclipse), or use completely honest closed source software (like BBEdit), instead of using tools designed to look like open source but not.

[0]: https://pulsar-edit.dev/

I thought spiritual successor to Atom is Pulsar. https://github.com/pulsar-edit/pulsar

Pulsar has a TTS package, for those who were very comfortable in Atom.

In addition to the already mentioned Emacs, I would check Pulsar, the Atom successor.

Community-led fork of Atom

Also, don't worry - we understand that there's documentation lacking on the "extend Pulsar" part and on package creation, but we're working on it. We're also working on better ways to test, document, and create packages (and grammars - see, for example, how we usually tested grammars in the past and how we're migrating to for example), so it's just a matter of time, really.

Our website is https://pulsar-edit.dev/, feel free to check out or Discord server if you want to come and say hi or have any questions - we are a friendly bunch.