anyone using TOML files ?

[Antoine Chalons 90]

Oh, and by the way, the VIP is now available on vipm.io : https://www.vipm.io/package/lv_toml/

[bjustice 14]

Correct.

Ahh, I typically only read the files.  But yeah, the writer portion of the code doesn't in-place edit a file, so yeah, the comments would be lost.  Good point.  I'm not sure of the way around this.

How is JDP handling this?  I assume that he's going to have the same issue with JSONtext (since he added comments in the latest JSONtext release)

Edited April 8 by bjustice

[Antoine Chalons 90]

I haven't checked how he handled comments.

I started thinking about variant attributes to handle them (text and position) but it quickly gets tricky so for now I've accepted to either only read or lose comments.

[drjdpowell 502]

There are actually multiple different use cases of config files, and multiple ways to implement those uses cases.

My most common use case is "Computer writes config; Human reads and may modify; Computer reads config".  The way I do this is mostly:

• Read config file into Application data structures.   
• Later, convert Application data structures into config file. 

Comments don't exist in the Application data structures, so comments get dropped.  

Another (used, by the NI/OpenG INI libraries, and I'm guessing your TOML stuff) is:

• Read config file into intermediate structure
• Query structure to set Application data structures
• Update intermediate structure with changed values from Application data
• convert intermediate structure back to a config file

Here, the intermediate structure can remember the comments in the initial file and thus preserve them.  But, IMO, this is also less clean and more complex than the first method, as you have an additional thing to carry around, and the potential to forget to do that "update" part.

Currently, with the latest version of JSONtext (now available!), I haven't really developed this second, comment-preserving method. I am more thinking of another, less common but important, use case: "Human writes (possibly from a template); Computer reads", where the computer never writes (this is @bjustice use case, I think).   Here, the human writes comments (or the Template can be extensively commented).

But I do intend to support keeping comments.  It will probably involve applying changes from the new JSON into the original config-file JSON, preserving comments (and other formatting).  But that is for the future.

Edited April 8 by drjdpowell

[drjdpowell 502]

48 minutes ago, Antoine Chalons said:

I started thinking about variant attributes to handle them (text and position) but it quickly gets tricky so for now I've accepted to either only read or lose comments.

I think you just need an extra string for each item to hold end-of-line comments, plus a "no item" data type to allow full-line comments.  See how teh NI INI Library does it.

[drjdpowell 502]

BTW, one other use case I've had is "Multiple applications read/write to common config file", which requires careful thinking about preventing one App from overriding changes made by another App.

[ShaunR 858]

1 hour ago, drjdpowell said:

My most common use case is "Computer writes config; Human reads and may modify; Computer reads config".  The way I do this is mostly:

• Read config file into Application data structures.   
• Later, convert Application data structures into config file. 

Comments don't exist in the Application data structures, so comments get dropped.  

Another (used, by the NI/OpenG INI libraries, and I'm guessing your TOML stuff) is:

• Read config file into intermediate structure
• Query structure to set Application data structures
• Update intermediate structure with changed values from Application data
• convert intermediate structure back to a config file

Here, the intermediate structure can remember the comments in the initial file and thus preserve them.  But, IMO, this is also less clean and more complex than the first method, as you have an additional thing to carry around, and the potential to forget to do that "update" part.

There is another method that I use.  Read the entire file  and return a single element (or maybe more) whenever access to an element is required. This relies on OS caching to maintain performance but yields real-time, on-the-fly changes to the ini file being reflected in the application.

[Phillip Brooks 194]

On 4/6/2021 at 11:47 AM, drjdpowell said:

Note: that package also has RFC3339-compliant Datetime format VIs, if you haven't already done Timestamps.

See my signature

[Antoine Chalons 90]

I've fixed quite a few bugs and changed the way timestamps are handled, now using JDP Science Common VIs for RFC-3339

You can follow on GitHub

[ShaunR 858]

What a horrendous format TOML is. 

I won't be using this format unless forced to at knife-point.

[Antoine Chalons 90]

I've had some difficult clients in the past but it never got to that point 🤣