Jump to content

anyone using TOML files ?


Recommended Posts

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 by bjustice
Link to comment

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 by drjdpowell
Link to comment
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.

Link to comment
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.

Link to comment
  • 7 months later...

@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

  • Like 1
Link to comment
  • 1 month later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.