Leaderboard

I've just implemented this and posted a beta: https://forums.ni.com/t5/JDP-Science-Tools/BETA-version-of-JSONtext-1-5-0/m-p/4136116 Handles comments like this: // Supports Comments { "a":1 // like this "b":2 /*or this style of multiline comment*/ "c": 3 /*oh, and notice I'm forgetting some commas A new line will serve as a comma, similar to HJSON*/ "d":4, // except I've foolishly left a trailing one at the end }

I haven't checked the behavior now, but I did remember this discussion from some years ago - https://forums.ni.com/t5/LabVIEW/Queues-Enqueue-Dequeue-Element-Scheduling/m-p/2367134#M737149 Note that in the post I linked to AQ does say that "the writers are serviced in the order they put in their request to write, so there's never a starvation" and that only the dequeues could be starved, but maybe this behaves differently in limited size queues or maybe this is different in different LV versions?

I've been toying with the idea of implementing a new TOML library for LabVIEW. I've been using OpenG variant config for years, but I would prefer to use a more standardized format for my ini config files. TOML is the best candidate for this. Erdosmiller's library is pretty good, but as the author points out, it is no longer maintained, and it didn't gracefully handle all of the datatypes that I wanted to use. It would be great to have the flexibility of jsontext but for TOML format. I'll post back here if I manage to get the project off the ground.

I've been a big advocate for the Enthought Python integration toolkit in the past. Unfortunately, the product was discontinued when LabVIEW introduced the native python node. I'm still scraping by on this product as I've not found a good alternative, and the built-in LabVIEW python node doesn't meet my needs. Under the hood, the Enthought product was just a TCP link to Enthought's flavor of python called Canopy... which has also been discontinued. This product was fantastic for a few reasons: Canopy environment could be packaged into a lightweight Python runtime engine, which can be zipped up and passed around with LabVIEW executables. Made it easy to deploy the code to many machines. 32/64 bit LabVIEW compatible fast read/write of large data to/from Python Relevant link: https://support.enthought.com/hc/en-us/articles/360035630192-Toolkit-End-of-Life-Porting-to-LabVIEW-s-native-Python-support I recognize that this probably isn't helpful... but a datapoint

Apparently, NI has changed there Support's website. - you cannot write a description of a problem. You choose your preferred communication means and write a one-liner topic, press "Send", and... wait to be contacted by NI. - you cannot provide example files when filing a bug "report". You can only provide "steps to reproduce". I guess there are so few bugs nowadays in LabVIEW that NI figured they could get rid of the whole obsolete process of filing detailed bug reports.