Antoine Chalons 90 Posted April 8 Author Report Share Posted April 8 Oh, and by the way, the VIP is now available on vipm.io : https://www.vipm.io/package/lv_toml/ 1 Quote Link to post
bjustice 14 Posted April 8 Report Share Posted April 8 (edited) 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 Quote Link to post
Antoine Chalons 90 Posted April 8 Author Report Share Posted April 8 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. Quote Link to post
drjdpowell 502 Posted April 8 Report Share Posted April 8 (edited) 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 Quote Link to post
drjdpowell 502 Posted April 8 Report Share Posted April 8 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. Quote Link to post
drjdpowell 502 Posted April 8 Report Share Posted April 8 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. 1 Quote Link to post
ShaunR 858 Posted April 8 Report Share Posted April 8 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. Quote Link to post
Phillip Brooks 194 Posted April 12 Report Share Posted April 12 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 1 Quote Link to post
Antoine Chalons 90 Posted Friday at 10:14 PM Author Report Share Posted Friday at 10:14 PM 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 1 1 Quote Link to post
ShaunR 858 Posted Saturday at 12:40 PM Report Share Posted Saturday at 12:40 PM What a horrendous format TOML is. I won't be using this format unless forced to at knife-point. 1 Quote Link to post
Antoine Chalons 90 Posted Saturday at 05:26 PM Author Report Share Posted Saturday at 05:26 PM I've had some difficult clients in the past but it never got to that point 🤣 Quote Link to post
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.