Aristos Queue

For the record, this bug goes all the way back to 2003 (before LV classes were even released to the public in 2005 beta or 2006 release). It has not been reported before now. It affects a corner case -- you have to have a class that contains floating point fields, whose value is NaN, which is compared against itself. I recognize that comparing a value against itself is exactly how you detect NaN, but that is only going to apply to classes that are, in aggregate, being used to represent numeric calculations, so I'm not surprised the bug has gone this long without being noticed. I'll make sure it gets addressed in LV 2015. It is too late for 2014 SP1.

So... there is a bug in LabVIEW. It has to do with NaN. When there are two objects in memory, LabVIEW compares them, just like it does any other type. But there's a small performance cheat -- if the two objects are from the same memory address, the function returns TRUE -- they are equal. But that's not true if the class could contain a NaN. So we need to eliminate the performance check. This is why your comparison against the tunnel value directly gave different results than the other two comparisons. What threw me off was some of your comments about how these should be equal and the subVI wasn't giving the same results as the caller. Here's a couple tidbits that might help your understanding of the issue. a) NaN compares false when compared against itself and true for not equal. b) SubVI isn't going to show its results because you've got it marked as inline. The VI that you're looking at never executes so the panel never updates. That accounts for the difference between the caller and the subVI. Turn off inlining and you'll see the panel update. c) Compare Agg vs Compare Elt does not affect classes. Classes are defined as scalar values. Their internal implementation is opaque to external callers of the class. A class containing NaN compared against itself will always say it is not equal (so the Not Equal prim will return true). [barring the bug mentioned above.]

Ignore previous post. I found your bug. Please hold while I type it up.

Disagree all you want -- my statement was assertive. In the current API, a "buffer" is a single element bounded queue. Sorry if I didn't make that clear. Now, whether it should be or not, that is the open question. :-)

You have over a million open DVRs at the same time? Let me guess... 1,048,576 open refnums? Isn't that a rather suspicious number... a power of 2. Hmm... This simple VI will fail after exactly 1,048,576 iterations: LabVIEW uses a rather clever algorithm to allocate DVRs (or any refnum kind) in such a way to EFFICIENTLY support this trick: you can allocate a DVR, release it, and then allocate a new one, and you won't get the same refnum, which means that your other threads that might still be holding onto that old refnum will get errors about the refnum having been disposed instead of messing with the new refnum. I haven't dug into all the details of the algorithm, but the result is that you can only have 1,048,576 refnums of the same type open at any given time. After that, we can't allocate more until you free some -- you'll still get a unique refnum when you do this. So, that's the way it works. Congratulations... you're the first user in 15 years I've ever heard complain about this --- I hadn't had to dig into this before now. So... > I've recently run into problems with an application that creates a lot of objects. That's "by-reference objects." Can I ask why you have all your objects as refnums? What application do you have that requires that sort of architecture? Let me clarify my question... > I'd much rather use U32 as a type for that array than a 1kB cluster with the actual results. If your array is an array of objects, then the top-level array size will be pointer sized... on a 64-bit system, that's a U64.

Got an API that I'm helping to review. It has options for communication over a "Buffer" or a "Pipe". Reading the documentation, a pipe is an open-ended queue of values; a buffer is a single-element bounded queue. I have trouble remembering which is one element and which is N elements. I suggested renaming "Buffer" as "1 Element Pipe," but the developer really wants a single term to describe each as it does (I agree) make a lot of the rest of the documentation easier to write. We also don't want to use the term "queue" because the actual implementation may or may not be a LabVIEW queue (depending upon how other things get configured, the system chooses the best actual implementation). Does anyone have good terms to recommend for these two settings? In particular, I'd like a term that means "single element pipe". We've discussed "Tag," but this is a queue, not a variable -- the value gets removed by the reader. "Variable" gets rejected for similar reasons. Thoughts?

Jeannius: LabVIEW Containers... already exist: http://forums.ni.com/t5/LabVIEW/The-LabVIEW-Container/td-p/2838928

I'm looking for a G VI or sequence of VIs that I can use to highlight a file in the OS environment that works on all platforms. I've got mechanisms for opening a window for the directory -- that works fine. But I can't find any way to actually highlight a specific file within the directory. Any ideas?

Not for lack of trying, but no, I have not succeeded. The problem comes down to the number of people who have *ahem* made deep calls into what should have been private VIs of the General Error Handler (they weren't in the palettes for a reason, people... ok, I know that's never been a barrier, but it is really a problem for trying to improve code when the entry points aren't bottlenecked). Any attempt to refactor generally runs into problems. And it HAS to be a refactor, not a deprecate and add a new function. The two times I've worked with real code to do this, we've realized that all modules in the system must be using the same error system or nothing works, and that means that the language level error system has to be replaced. What all of that means is that I'm having to refactor on the assumption that just about every VI in the existing hierarchy is a *valid entry point* into the new error system, and that requires a lot more code than I would otherwise have, but we want anyone who does just use the main entry points (the 99% case) to not have code bloat (indeed, a big part of my refactoring actually brings the code size down from current). So... what all of that means is that I have to have a lot of running room to make the system work. There's a couple of other barriers within NI -- systems that chose not to support certain parts of VI Server, which means no part of the core libraries can ever use those features, which means I have to either convince someone to finish out every target with a full VI Server or get my refactoring to work without them. The long and short of it is this is not a small project by any stretch of the imagination and I'm having to line up a bunch of forces across NI to make it work along with a fairly large block of my own time. I am not confident I'll ever actually manage to do it, but I continue to try.

There is a lot that is interesting about the following blog post, but most notable for me is the formal definition of "elegant code". http://bartoszmilewski.com/2014/11/04/category-the-essence-of-composition/ We've all seen elegant code. We know it when we see it, but stating precisely why this code is elegant and that code is not is quite hard sometimes. The definition is offered just past the halfway point of the blog post, in the paragraph that starts "This process of hierarchical decomposition and recomposition is not..." Side note... the blog post concludes with a set of challenges for you to implement in "your favorite programming language." If you've ever heard me or a few others complain about a lack of basic functional concepts in LabVIEW, just try implementing the challenges, even just as a thought experiment. Your results will be a long way from elegant. Someday, we'll fix this about LabVIEW. Someday. *sigh*

GeorgeG: a) Have you read the white paper about the AF that comes with the template projects? The section on high, low and zero coupling is relevant to your question. We are all frustrated by the lack of interfaces in LabVIEW which would simplify the system considerably. b) For debugging the current AF, check http://ni.com/actorframework for a number of posts on the topic. In particular, check out the Monitor Actor, which adds a debug layer to the AF. Also, the Desktop Execution Trace Toolkit is your friend when debugging the AF. The 2015 version of the AF should be even better in this regard.

Thanks for the feedback, everyone. This is one of those "years away on the horizon" projects for me, but I wanted to get a feel for how to start thinking about it. Let me ask the question another way -- there is a body of research out there on software constructs that cannot create race conditions. Certain operations are simply ruled out even if they are frequently ok because they open the door to problems but it is too hard (or unknown) to prove whether a given usage of an operation is safe or not. Assume that LabVIEW retained the ability to have a raw global or a free-for-all DVR to do the "I just want to do this and have it work the easy way" solution, we could also have a separate feature -- let's call it a "safe global" for the moment -- which didn't allow all the flexibility but in return allowed you to know that you didn't have issues. Would there be interest in LabVIEW developing that as a parallel solution? Or would you rather LV focus on improving the warning feedback for questionable cases in the easier-to-use-but-error-allowing solutions? The two areas are somewhat orthogonal.

That's a good way to summarize it. :-)

I don't think that approach would work. No one is going to have their phone out and visiting a web page during the event. I need a device that can figure out its location and transmit it while sitting in someone's pocket. I thought you were proposing some way that I could simply identify all the phones on site and triangulate their positions, but if it requires them to be actively in use, that won't fly. I think I need to keep investigating some of the custom hardware options.

That's essentially what coercion dots are. We could certainly do more in this area -- annotating diagrams with extra info to emphasize "this is what is going to happen".

All I'm after is x, y coordinates for ~30 moving objects on a plane to within 1 meter resolution. Anything more than that might actually get in the way of the project simply by being more data than is useful at this point. Actually, that sounds like about exactly the right amount of "fun" for this project, but I have no idea how I would go about doing any such thing. Are you suggesting loading some sort of app onto their phone that would send location data to a central device? (And can some phones actually provide that level of precision location? My iPhone certainly cannot -- if I use any map app while walking, my position on the map is liable to update about once a block in some places.)

mje: I don't actually know if I can do anything to improve this area, I just noted that there was an increasing amount of analysis in the compiler that might be useful and I decided the time had come to ask, "if I did start working on something like that, what vector should I be on?" On the other hand, he's even more confused if he gets his program running, tests it on three systems, deploys it, and it fails once every three days out on his client's site. :-) We break VIs when you forget to wire required terminals. We put coercion dots when you have a type change. The race condition is somewhere between these two -- the former being "this isn't ever going to do what you think it will" and the latter being "this will be good enough most of the time but maybe could be more efficient but at least it does what you intended". But I'm not sure which one it is closer to.

I would have thought that you'd have different wi-fi routers and whichever routers it was closest to would tell you the position. How would the distance factor into it? Or are you saying that most of these products rely upon all the tags being attached to a single router point?

Let me start by saying what I mean by "race condition": two processes (or threads or execution paths or <your favorite term here>) both simultaneously read some bit of data representing system state, then modify the system state accordingly, and when both are finished, the new state of the system depends upon which one executed first. That is a very broad definition. Most users know the trivial case: you have a global variable representing some sort of counter, and you have two processes, Alpha and Beta, both wanting to increment the value. If the starting value is "1", then the ending value is expected to be "3". The race occurs here: Process Alpha reads the counter: value =1. Process Beta reads the counter: value =1. Alpha adds 1 to the value it read and gets 2. Beta adds 1 to the value it read and gets 2. Alpha writes to the counter: value = 2. Beta writes to the counter: value = 2. Oops. But there can be much more subtle bugs. For example: Alpha is a Producer Loop Beta is a Consumer Loop Beta checks "Is the queue empty?" to decide whether it has finished processing all the data. At some point, Beta is just a bit faster than Alpha and the queue empties, so Beta decides to quit, thinking it is done with all the data. Alpha adds more items to the queue, but Beta never processes them. Race conditions are notoriously hard for users to catch. They have historically been just as hard for compilers to notice in all but the most trivial conditions. As the LabVIEW compiler has gotten better at its analysis over the years, I see some potential for the compiler to recognize when a bit of memory is potentially being used by multiple execution paths in "a race condition like manner". I'm using that deliberately vague term because the definition of what exactly constitutes a race condition may be part of the conversation here. If the LV compiler knows beyond a shadow of a doubt that some egregious behavior, such as an unprotected global VI or shared variable being used for read-modify-write in multiple execution paths, should LabVIEW break the VI? Is that a compiler error? Or is it something more like a coercion dot that should be highlighted but not ruled out? To put it another way: Are there race conditions that you have in code that are desirable conditions? Is that because it is just too hard to program the right way? Or do you have some where the correct program really is one where execution order should matter to program output? If the robot's right hand grabs the apple a microsecond before its left hand grabs the orange, are there cases where it is correct for that to affect which one it chooses to serve you for lunch?

Gribo: Almost all of the RTLS systems I have found online are targeted to medical... and priced accordingly. :-S The fact that your website even mentions other use cases is unusual. ... and they are all missing a "Buy Now" button, which I have observed is a very bad sign for cost effectiveness.

I volunteer for Scare For A Cure. As a charity event, we run a huge haunted experience every October, and in April, we turn our 3.5 acres of land into a live-action D&D dungeon crawl. We have hundreds of players come through every Thursday, Friday and Saturday night during these months. To make the experience work, we need to keep the groups from running into each other. This requires massive coordination, with various keywords inserted into scripts so actors can pass messages without cluing in guests, and little hidden LEDs showing when rooms are occupied, when they clear, when storyline needs to be adjusted to get groups to empty a room quickly, etc. It's a real pain and we do occasionally botch (like we did last night with two groups hitting into each other, which tends to break the suspension of disbelief). This would be made a lot easier if our central command and secondary posts could actually watch in real time where each group is located. We recently got a bunch of new computers for these posts, so I started wondering if we could build such an application. So I'm here on LAVA looking for recommendations for hardware and APIs for that hardware. In the subject line, I said "GPS", but I am aware of just how drifty GPS is, particularly when guests are moving from inside to outside of buildings regularly. Since I'm wanting to track room-to-room movement, I probably need something with higher precision. I'm open to technologies that require us to have some sort of base station installed throughout the haunt. The trackers need to be something that our guides could carry on their persons discretely. They need to be waterproof -- not just water resistent. They will be used in an environment where there is frequent rain and even more frequent gore cannon (yes, that means exactly what you think it means). I would want to be able to track up to 20 simultaneous groups. If there was a way to put this information on tablets, we have a bunch of cheap Android tablets that could be carried by admins. If there's an off-the-shelf solution to this problem, I'd like to know about it. If not, I'd like to hear any community ideas for devices they've seen that would serve in this environment. Since we have a central computer, my thought is I could build in LabVIEW gather and correlate the data to draw the map of where every group is located, turn that into a web service, and then use Data Dashboard to push that information out to the tablets. Any ideas?

Nope.

No, they aren't checked at startup. And that's as much help as you'll get from me. :-)

Mwuhahahahaha! Three config tokens have escaped your grasp! I modified them specifically for folks like Flarn! They don't appear as plain text anywhere in the EXE (or in any VI for that matter). Do they guard any great secret of LabVIEW? I'm not telling! But you can have fun pouring through the code and looking for interesting bits and trying to figure out what you need to put in your config file. LabVIEW 2013 or later. Good luck.

I'm looking at a spec for a future feature in LabVIEW today. The spec talks about top-level VIs and not-top-level VIs. The top-level VIs are the ones that are the top of your application or that are kicked off and run independently (through Asynch Call By Ref or the Run VI method). The not-top-level VIs are all the other VIs. Does anyone have a term better than "not-top-level VIs"? I'd like to call them "subVIs", but people both inside and outside NI abuse that term all the time to refer to all VIs since any given VI could become a subVI at any time. Using "subVIs" for a specific subset of VIs apparently creates confusion -- trying to do that appears to be what lead this spec document that I'm reading to use "not-top-level VIs". Does anyone have a good term expressly for "not-top-level VIs"? Or should I just tell people "use the term 'subVI' and we'll educate the confused."?