Aristos Queue

Newer applications on MS Windows have removed "Exit" from their menus. They either rely upon the user using the [x] on the application window or on someone right-clicking on the MS Windows task bar and choosing "Close Window" as their signal to exit. LabVIEW has a plethera of windows open and no "master window" to close them all, so we still need a File >> Exit, but most applications that I've seen written *with* LabVIEW are single window applications (or single master window with floating supports, which amounts to the same). So, I'm curious... when you folks are writing your applications, have you started leaving out File >> Exit? What are your thoughts on that trend?

Ok. I think we have it right this time. At the very least, it passes validation on today's token. CAR #377978 appears to be fixed in LabVIEW 2014 -- the input to Delete From Array is no longer a stomper if the output array is unwired.

Launching to the ISS today. Live webcast started already here: http://www.spacex.com/webcast/

This is why in 2014, NI will be shipping the new Bifurcated Timeline LabVIEW. For any dataflow with an ambiguous answer, we'll fork the entire universe and provide one answer to each quantum state vector. Even if you find yourself in the wrong timeline, you can take solace in the fact that in one of the various realities, LabVIEW did exactly what you expected it did and that other you is quite happy. Be happy for your self's good fortune! The feature is undocumented because documentation being provided is one of those quantum states that got forked during testing and this universe lost out. But it's in there, nonetheless. I hope you enjoy it!

The trick in this case is if you test NaN for "is it greater than Max?" it will say "False!" and if you ask "Is it less than Min?" it will say "False!" ... therefore the value is correctly in the range of 0 to 10. ;-)

NaN returns false for all LV versions that I know of back to AT LEAST 6.1. I've got tools that rely on that fact. I'm not sure why you didn't expect it... you should expect any computation involving NaN should result in NaN. You tried to coerce something that is not a number into a numerical range. The result is, therefore, not a number. To give further details about what happened in 2010... this appears to be the result of third party changes, not something anyone within LabVIEW ever consciously decided to change. LV 2010 was the first version to use LLVM as our low-level optimizer. The conversion code from float to integer is generated by LLVM, and so in making the compiler change, we picked up LLVM's convention for handling NaN. Until I just now asked around, no one here knew about this change of behavior. The coercion code hadn't changed in forever, long before there was a nightly test suite, so there was never a test created to check that behavior during refactorings. It wasn't something we did and then decided not to document. It was something that never needed documentation since it had been that way presumably since LV 2.0 and I don't think anyone realized would be impacted by the LLVM change.

> PropertyObject.SetValVariant This would be possibly technically impossible to ever implement. The TestStand sequence is just that -- a sequence. The reference object that it has is a meta-dataflow -- the value is set when it comes out of LabVIEW and then can be read again by passing it back into LabVIEW. It maintains the same invariant of an immutable reference object because the value in the reference cannot be changed in parallel code. It is not a by-reference shared object; it is just a way of "branching a wire" from one LV call to the next", and just as you cannot set the value of one branch of a LV wire from another branch, you cannot modify the value of the object in the reference. So the value in the object reference is immutable between calls. We have a technology that lets you do the shared-reference. If you want that, put your object in a Data Value Reference and then have TestStand pass the DVR value to different VI calls.

It uses the Read Link Info application method to harvest the linker graph info without loading the files. Most library types do not load their VIs. They do load their nested libraries. Classes and XControls are the only two types of libraries that load their member VIs.

You cannot put launching of nested actors into Pre-Launch Init.vi. That will deadlock because Pre-Launch Init is mutually exclusive with any other actor launching (by design -- it provides the bottleneck where you can acquire multiple resources without worrying that other actors are acquiring those resources at the same moment). Acquisition of resources for references generally works best there. Doing your Launch Actor (soon to be Launch Nested Actor) there won't work. https://decibel.ni.com/content/thread/18246 is the thread you want... including my comments on why I believe you would never want to call "Handle Error.vi" in "Pre-Launch Init.vi"... it just can't really be the same handler when an actor is running as when an actor is not yet running. The things you do to "handle" the error are entirely different.

There's a whole thread on the AF community forum about this error propagation and why it is done this way.

Mike Le: I was having trouble with that happening sometimes -- but only sometimes -- before I made changes. I thought I had fixed it when I made my changes, but I guess not.

I've been working some more on my LabVIEW object serialization library. I wanted to fix the problem of double precision numbers. The standard LabVIEW function for translating double to string does not produce numbers that are bitwise recoverable unless you specify a precision of 17 for all values, meaning a lot of junk in the file. LabVIEW uses the standard C printf function under the hood -- the problems LV has are the same problems most other languages have. I figured someone must have found a way to fix this. Oh, boy, did I stumble into gold. In 2010, a grad student, one Florian Loitsch, not only published an algorithm that does this, it is 5x faster for 99.5% of double values than the standard algorithm. It was the first improvement in the algorithm speed in over 20 years. And just last month, he published the code for a further speed improvement. Here's an article about the improvement. This author found a 10x speed improvement in his JSON library. That's exactly what I want to hear. It's hard to find, so here's the link to the actual C code source for this algorithm. I am going to investigate dropping this code into LabVIEW for 2015. I looked a long while at implementing the C code in G. It's doable, but it isn't small at all, so I'd rather just upgrade LV using his C code than try to recode it. Less error prone and it floats all boats, not just my library.

Yes, because that isn't necessarily a recursive call at run time. Suppose Square and Line inherit from Shape. Shape has a dynamic dispatch method "Draw". Square.Draw might make four calls to Line.Draw. Is that recursion? No. Now suppose you add Collection which inherits from Shape and contains an array of Shapes in its private data. For Collection.Draw, it calls Shape.Draw for every item in itself. Is that recursive? Maybe yes, maybe no... it depends upon whether Collection contains nested Collections. If Collection can only include other basic shapes then there is no possibility of recursion when the dynamic dispatch call to Shape.Draw because it will never dispatch back to Collection.Draw. For that reason, the method can be used on itself without marking the VI as Shared Reentrant. It does explain why they are more expensive, but not why they are (at the moment) very more expensive. Or, at least, that code hasn't changed and did not previously account for a substantial increase. What exactly is accounting for the substantial increase is at this time unknown, so I'll leave the door open to this being part of the problem.

A VI run from the Tools menu always runs in the dialog context. Always. This is intended behavior because the tools VIs are not part of whatever project is currently in memory and should not cross-link with the VIs in the open project.

There's not really enough info here to answer the question. Someone is likely going to have to replicate your system to figure out what's not set right. Contact your NI application engineer.

Not a bug. It's called recursion and it is totally legal. Don't write a recursive function without a base case... you'll use up all of memory.

What LV version? That existed in LV 8.6 and earlier. Haven't seen it since. BTW, fixing it can be made faster by ctrl+shift+click on the broken run arrow -- that'll fix all the VIs in memory.

Tomi: The link is returning an error "Error establishing a database connection".

http://arstechnica.com/tech-policy/2013/12/googles-copyright-win-against-oracle-is-in-danger-on-appeal/ The trial judge ruled that APIs cannot be protected by copyright, only the implementation of those APIs. This is a critical ruling for most of the software industry. If this ruling gets reversed, it becomes much MUCH harder to do multi-platform development because you cannot re-implement a working system on another platform -- you'd have to invent a new wrapper API that looked substantively different from the underlying platform API, and only use your wrapper API on the other platforms. The substantial difference generally means some significant performance loss, even on the main platform, meaning that it would significantly deter apps from being cross-platform on any platforms. This ruling is now being appealed and the new judges aren't initially showing the same technical savvy as the trial judge. I have no idea what kinds of friend-of-the-court briefs are allowed at the appeals court level, but if any of you have legal departments that get involved in software cases, this one is a big deal to all software development.

Fixed.

Since it seems like no one bothered to update this thread... the event structure timeout behavior for registered-but-not-cased events has been modified per user requests. Check page 11 of the LV 2013 upgrade notes. http://www.ni.com/pdf/manuals/371780j.pdf

Check your upgrade notes. Page 11. http://www.ni.com/pdf/manuals/371780j.pdf As for the rest... Two event structures generally indicates the user I'm working with doesn't understand what an event is nor do they have any sense of their own code's operation. That, more than any particular coding error, is the source of the bug. There's no reason to bother fixing the specific issues you describe (FP locking, duplicating events, etc) when the bug is architectural. The advanced users that have posted here are describing cases that sound reasonable, but I have never seen them used in practice.

I was off on vacation. But I got the info I needed -- this is a used feature so don't muck with it. Thanks, all. Oh. I just saw the raft of posts asking why I'm asking this. It's mostly so I know where the bounds of brainstorming are when trying to improve communication systems. I've always thought it was kind of dumb that we enabled multiple event structures within one VI because of the static registration of events, and it was just one more axis I have to worry about if I do anything in that area. I can't answer the question "what would we be getting in return" because I'm not sure -- I don't have a firm proposal at this time. I needed to know if it had intrinsic value at all because it simply does not in any programming I've done. Indeed, my first instinct when I've seen code that does this is to say, "I'm guessing your bug is here, and I bet it gets fixed if we refactor to remove that second event structure." Y'all highlighted some reasons why you like it. I'll keep those in mind.

Magic. Probably rubbing Aladin's lamp and getting the genie to patch up the diagram. Seriously, though, I've given zero thought to how I might fix stuff up in mutation. I'm trying to get a sense for whether or not its even worth brainstorming in that area or not. I'm getting a sense that it would not be viable. Pity. Thanks, all. Have a Happy Thanksgiving.

So, you have an event structure in a loop. It's handling your UI events. In theory, you can have multiple event loops on the same block diagram. In practice, I've never seen anyone actually do this. Do people do this? How bad would it hurt if we said, "Nope... you can only have one event structure per VI." ? I am not saying we're going to make this change. There's a lot of brainstorming going on around possible new features and that aspect of events is causing some difficulties, and I want to know how much flexibility we have to play with the design.