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/

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.

If my average returns NaN by trying to divide by 0, then the coerce in range returns NaN not 0 or 10.  This functionality isn't what I expected, but it is what is documented in the help.

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. 

So am I to understand that DD VIs are in fact different from other VIs and support recursion even in the absence of the usual settings for reentrency?  

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. 

This might also go some way to explaining why DD calls are actually very expensive compared to standard VI calls.....?

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

 the #$%@#$% bug that unhandled dynamic events still reset the timeout. 

Check your upgrade notes. Page 11.

http://www.ni.com/pdf/manuals/371780j.pdf

As for the rest...

The true LV ninja would look at the code and determine the specific cause of the bug. 

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.

But I am curious, AQ, if you went ahead with this enforced limitation, what kind of upgrade mutation could possibly save such (IMHO, barely maintainable) code that's out there?

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.