LabVIEW
"Invalid Refnum" check doesn't work on Semaphores?
Given that the Semaphore API has the Not A Semaphore VI, I doubt R&D would prioritize updating the Not A Number/Path/Refnum? function to do the extra work required (casting the datalog reference to a queue reference) to check the reference validity.
Nevertheless, feel free to post the idea to the LabVIEW Idea Exchange if you want to try to drum up support for the idea.
In the LV 2016 help file, it says not to use it for rendezvous or semaphore, so I'd say not a bug. I'm not too familiar with vims (using LV 2016), but maybe you could make one that incorporates the functions for different kinds of references.
@Darren wrote:
Given that the Semaphore API has the Not A Semaphore VI, I doubt R&D would prioritize updating the Not A Number/Path/Refnum? function to do the extra work required (casting the datalog reference to a queue reference) to check the reference validity.
Nevertheless, feel free to post the idea to the LabVIEW Idea Exchange if you want to try to drum up support for the idea.
When this popped up in our code, we had the idea of EITHER making it work with the "Invalid Refnum" or actually not supporting wiring a semaphore to the function. It gives the impression that it works, but doesn't..... I'll post on the Idea Exchange
@Darren wrote:
Given that the Semaphore API has the Not A Semaphore VI, I doubt R&D would prioritize updating the Not A Number/Path/Refnum? function to do the extra work required (casting the datalog reference to a queue reference) to check the reference validity.
Nevertheless, feel free to post the idea to the LabVIEW Idea Exchange if you want to try to drum up support for the idea.
Well, what would NI R&D Proitize? Would it be a sub millisecond timing vi that is at least a decade and a half overdue? Perhaps a JSON parser that is merely 5 years late?
Seriously, what code (that has previously been posted on these forums) does NI R&D "prioritize "?
@JÞB wrote:Well, what would NI R&D Proitize? Would it be a sub millisecond timing vi that is at least a decade and a half overdue? Perhaps a JSON parser that is merely 5 years late?
Seriously, what code (that has previously been posted on these forums) does NI R&D "prioritize "?
Seriously, why do we need NI to do everything? The community needs to step up more. Make open source libraries and make them available through VIPM or some other method of distribution. At least Intaris is asking for a change to a primitive, which is something the community cannot do.
@Andrey_Dmitriev wrote:
To be honest, NI R&D should do something. Personally, I’m not very happy with the developments of recent years, when the “what’s new” notes can sometimes fit on a single Post‑it sticker. There is still no comprehensive native Unicode support, and HiDPI issues remain unresolved. There are also shortcomings in many areas — not only in LabVIEW itself, but in toolkits like VDM and OPC UA as well, etc. Unfortunately, LabVIEW is not very popular as a general-purpose programming language like C/C++/Python/Rust, ... .—it’s only slightly above Scala, Haskell, or Erlang. Nigel is still far from what modern AI tools can do with code generation and assistance today. The attempt with LabVIEW NXG and .NET was a nice effort to modernize the platform, but it clearly failed for many reasons. So, given that, having an obvious polymorphic primitive “Not a Refnum” that would also cover semaphores and rendezvous—why not? And not everything could be covered with open source libs.
I did not say R&D should do nothing. But there are A LOT of things the community can do. My comment was geared more toward Jay asking for NI to create a new VI. But you can create a VI and make it available through various distribution methods. So do that. NI has more than enough keeping them busy. Yes, primitive changes we cannot do. I made that distinction in my previous post.
I have been told Unicode will start to release in the next version or two. We'll see if it actually comes out. Nigel code generation was stated at NI Connect to be released in Q3.
