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

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.

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

Let me make sure I understand what you mean by this : You mean, they are ignored and don't mess up with extracting the data, right? (appart from the case in issue #1) Because for me one thing that is a bit annoying is if you load data from a TOML file that has some comments, as soon as you write using this lib, you lose all the comments, or am I missing something?

Just released v2.0.0 There's not a lot in it really, I'm hopping that the effort in improving the error reporting will help future developments like adding support for new data types and comments.

I've been thinking about this but as I said above, this a not a short term need for me. I do hope I'll find some me-time to play with comments during the summer. Interestingly, there is a reported issue on the original repo that is linked to comments : https://github.com/erdosmiller/lv-toml/issues/1

Ah.. I knew I'd screw-up the license handling... I have to say I didn't even look up how to handle open source license when forking. My bad, will fix that soon.

Timestamp support is not on my roadmap (yet) but I'll keep that in mind, thanks!

Thanks a lot for the clarification. I'll fix this in my fork.

@bjusticeI've seen issue #2 that you created on the original repo, I have to say I don't understand the problem nor the suggested solution. Could you post more info about this please?

I'm going to fork the repo on GitHub and work on it for my needs, What I'm planning to do is : short term : - move to LV2017 (just because it's the oldest I have already available on a VM) - add support for path - improve error reporting hopefully one day : - add support for comments At this point, I'm not planning to do any major refactoring. If anyone wants to participate... feel free : https://github.com/AntoineChalons/lv-toml

Well that's my case as well, and it worked with my (what we use to call) DSRL license number. As for uploading files, I created a srq last week and could upload files. Maybe things have changed since. If I go to my existing SRQs I can still upload files, I just tried, it worked. What I'm suspecting is that based on your account (partner / not partner / company, etc..) NI filters and gives you a different feature set for creating your SRQ, that wouldn't shock me.

I can confirm, it expects you LabVIEW License number. I've recently created a few SRQ via ni.com/ask The interface and the process have changed a bit, but I could describe my issue and attach files (max report amd a zip containing code).

This is great! Just in case we are thousands of LV users silently wishing for native TOML support : https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Add-native-support-for-TOML-file-format/idi-p/4136157

I see. Well it's great that you created it and shared it on GitHub. The tree display is also a nice feature. Now.. If jsontext gets support for comments and LabVIEW objects, it will be a no brainner.

Sounds great. I've seen you're also working issue 56, which would be another big advantage of jsontext over the TOML library.

Intersting, have you considered submitting your bug-fixes on the github repo? Also, have you implemented support for path? or do you just use strings?

Hi all, A customer is pushing us towards using TOML file for app configuration. So far we're using json - thanks to jsontext from JDP Science - and we're happy with it. I've been testing the MIT-Licensed TOML library available here, but in term of features it's far behind jsontext. The cool thing with TOML - really cool - is the support for comments. So just out of curiosity, has anyone ever tried to use TOML?

Sorry for the lack of clarity, what I meant by threadsafe CLFN is this : therefore : reentrant As opposed to non-threadsafe CLFN : therefore : not reentrant. In my applications I don't need reentrancy for my libpq calls, but as I was trying to make this package as generic as possible. Yes I've tested step by step and running the same simple thing : PQconnect / PQfinish crashes when CLFNs are reentrant, not at the PQconnect though, at the PQfinish. The data base that I try to access does exist and the settings in the string are correct. The result is the same wether this VI is set as reentrant or not. Ok, I'm fealing cheated. If I understand correctly it means NI's libpq.so pretends to be threadsafe but actually isn't.

I've opened a support request with NI because on NI Linux RT, calling libpq.so with a threadsafe CLFN crashes LabVIEW while calling it with a non-threadsafe CLFN works fine. Funny enough, the only exception I've found to this is using a threadsafe CLFN calling "PQisthreadsafe" with a threadsafe CLFN, calling any other function triggers a crash.

It comes from OpenG, see here :

Running on Linux RT with the libpq.so compiled by NI : so they did build the library as thread safe and I get the same on Windows with the libpq dll deployed with the VIP.

I've just pushed new branch to Dr Powell's repo, and built a new version of this package. I used LabVIEW 2017 SP1. What's new : added support for Linux Rt targets (possibly Linux in general but not tested) (issue #1) added support for boolean parameter (issue #2) fix a weakness in parameter detection (issue #3) VIP 0.2.2-b16 can be downloaded from here.

😮 How many of these are use to control the Large Hadron Collider ? 😄

Very true!! I do use nested combinations of set and map - not hugely deep but it does turn out to be very useful. And yes it might not be trivial to handle ALL possible cases. But let's engineer ambitiously, no?