anyone using TOML files ?

[Antoine Chalons]

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

[bjustice]

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, 2021 by bjustice

[Antoine Chalons]

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]

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.

 

Note added later: the config-file JSON with Comments is now available in JSONtext 1.6.5.  See https://forums.ni.com/t5/JDP-Science-Tools/BETA-version-of-JSONtext-1-6/m-p/4146235#M39

Edited January 28, 2022 by drjdpowell

[drjdpowell]

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]

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]

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]

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]

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]

What a horrendous format TOML is. 

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

[Antoine Chalons]

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

[Porter]

It seems that there are now two forks of the erdosmiller TOML library:

https://github.com/AntoineChalons/lv-toml

https://github.com/justiceb/BlueTOMLSerializer

@bjustice is the BlueTOML a fork of the original erdosmiller library or of Antoine's library?

[Antoine Chalons]

I'm pretty sure I read somewhere that he started from the erdosmiller TOML library

 

Edit : I knew :

 

Edited December 13, 2021 by Antoine Chalons

[bjustice]

@Porter @Antoine Chalons

There's some background info here.  A few things.

Both of those libraries are branches of the Erdos Miller code.
However, I communicated all of my modifications to Antoine, who then re-implemented them in his library.
I have little intention of making additional changes to my branch.
Conversely, I suspect that Antoine intends to continue to support his branch, if only in a limited manner.

BlueTOMLSerializer is not just a TOML library.  It was written as a TOML-based plugin for the BlueSerialization engine.
https://www.vipm.io/package/blue_origin_lib_blueserialization/
This is a large piece of code that handles serialization and deserialization of classes quite well.
The user can select an implementation of JSON, TOML, or other by choosing a different plugin library.

I fully intend to modify BlueTOMLSerializer to drop all the TOML code and directly consume Antoine's library as a dependency.
This, for example, is what I do for JSONtext.
Unfortunately, I'm waiting on a specific feature request to be implemented in Antoine's library:
https://github.com/AntoineChalons/lv-toml/issues/24

Hope this helps

[Porter]

47 minutes ago, bjustice said:

I fully intend to modify BlueTOMLSerializer to drop all the TOML code and directly consume Antoine's library as a dependency.

That's what I was thinking. Thanks for the clarification.

[Antoine Chalons]

1 hour ago, bjustice said:

Unfortunately, I'm waiting on a specific feature request to be implemented in Antoine's library:

https://github.com/AntoineChalons/lv-toml/issues/24

Maybe for xmas

[bjustice]

🎅🎄

[Betty_Green_]

Thanks for the information!

[Antoine Chalons]

new release in my fork : https://github.com/AntoineChalons/lv-toml/releases/tag/releases%2Fv2.3.2

 

what's new : I've improved the error reporting when there is a typo in the value, ex :

[cluster]
some-numerial-value = 10
other-numerial-value-with-a-typo = 10s

The error source will quote the line at fault and give you the line index, something like "Parsing error at line 3 : 'other-numerical-value-with-a-typo = 10s'

[Jim Kring]

Adding a link to this new tool:

TOML Edit LabVIEW

it is a thin wrapper around a popular Rust library that supports preservation of formatting and comments.

Edited July 18, 2023 by Jim Kring