Thread overview
Which TOML package, or SDLang?
Jan 30, 2023
Daren Scot Wilson
Jan 30, 2023
Mathias LANG
Jan 30, 2023
Guillaume Piolat
Jan 30, 2023
Adam D Ruppe
Jan 30, 2023
H. S. Teoh
Jan 31, 2023
Daren Scot Wilson
January 30, 2023

So, which package do I use for TOML?

I find these three:

  • toml-foolery (Andrej Petrović)
  • toml-d, or toml.d (oglu on github) at ver 0.3.0
  • toml, (dlang community on github) at ver 2.0.1

I'm guessing from version numbers that the third one, toml, is officially good for real world use. But I wonder if there are good reasons to use the others.

Also, a low-effort search for TOML in the D world turned up SDLang, where the substring "DLang" has nothing to do with dlang, the common short name for D Language. SDLang looks nice. Should I ditch TOML for it?

I just realized - it's been ages since I've dealt with config files, beyond editing them as an end user. I work on existing software where someone else made the choiced and wrote the code, or it's a small specialized project not needing config. I'm a config caveman!

This is for a small fun personal project with potential show-off value, available on github but too primitive for now to mention. Controlling hardware, needing to store device info to recall for later runs. There are zero compatibility or standards issues to consider. Whatever is simplest to implement and tinker with is the winner.

January 30, 2023

On Monday, 30 January 2023 at 06:38:46 UTC, Daren Scot Wilson wrote:

>

So, which package do I use for TOML?

I find these three:

  • toml-foolery (Andrej Petrović)
  • toml-d, or toml.d (oglu on github) at ver 0.3.0
  • toml, (dlang community on github) at ver 2.0.1

I'm guessing from version numbers that the third one, toml, is officially good for real world use. But I wonder if there are good reasons to use the others.

I would go with the dlang-community one, whenever available.

>

Also, a low-effort search for TOML in the D world turned up SDLang, where the substring "DLang" has nothing to do with dlang, the common short name for D Language. SDLang looks nice. Should I ditch TOML for it?

I would not recommend it. SDL (Simple Declarative Language) is a language we have support for, but it's rather unknown - TOML will probably be simpler for end users.

>

I just realized - it's been ages since I've dealt with config files, beyond editing them as an end user. I work on existing software where someone else made the choiced and wrote the code, or it's a small specialized project not needing config. I'm a config caveman!

This is for a small fun personal project with potential show-off value, available on github but too primitive for now to mention. Controlling hardware, needing to store device info to recall for later runs. There are zero compatibility or standards issues to consider. Whatever is simplest to implement and tinker with is the winner.

If I can allow a shameless self plug, and if you are willing to consider YAML:
https://github.com/dlang-community/configy

If you are willing to stick to a "simple" config where you essentially want some values to end up in a struct, and want decent error messages, this is for you.

January 30, 2023

On Monday, 30 January 2023 at 06:38:46 UTC, Daren Scot Wilson wrote:

>

I just realized - it's been ages since I've dealt with config files, beyond editing them as an end user. I work on existing software where someone else made the choiced and wrote the code, or it's a small specialized project not needing config. I'm a config caveman!

Why not XML? :) It has comments, you can use backslashes too.

January 30, 2023
On Monday, 30 January 2023 at 15:37:56 UTC, Guillaume Piolat wrote:
> Why not XML? :) It has comments, you can use backslashes too.

no kidding, xml is an underrated format.
January 30, 2023
On Mon, Jan 30, 2023 at 03:59:52PM +0000, Adam D Ruppe via Digitalmars-d-learn wrote:
> On Monday, 30 January 2023 at 15:37:56 UTC, Guillaume Piolat wrote:
> > Why not XML? :) It has comments, you can use backslashes too.
> 
> no kidding, xml is an underrated format.

XML is evil.

Let me qualify that statement.  XML, as specified by the XML spec, is pure evil.  It has some absolutely nasty corners that has pathological behaviours like recursive expansion of entities (exploitable for DOS attacks or to induce OOM crashes in XML parsers), which includes token-pasting style pathology like C's preprocessor, and remote fetching of arbitrary network resources (which, no thanks to pathological entities, can be easily obfuscated).

XML as used by casual users, however, is a not-bad format for markup text.  It's far too verbose for my tastes, but for some applications it could be a good fit.  As far as implementation is concerned, a (non-compliant) XML parser that implements the subset of XML employed for "normal" use, i.e., without the pathological bits, would be a good thing, e.g., Jonathan's dxml.  A fully-compliant XML parser that includes the pathological bits, however, I wouldn't touch with a 10-foot pole.


T

-- 
Customer support: the art of getting your clients to pay for your own incompetence.
January 31, 2023
On Monday, 30 January 2023 at 17:54:15 UTC, H. S. Teoh wrote:

> XML is evil.
>

Agreed!


I'm going with TOML, community package. It's working, so far.