Aristos Queue

EDN Magazine has details of this week's ruling against Toyota in the unintended acceleration case. This report covers the investigation of the prosecution's lead expert witness who dug into Toyota's source code and development practices. Toyota was found guilty in the case on Oct. 24, 2013. http://www.edn.com/design/automotive/4423428/Toyota-s-killer-firmware--Bad-design-and-its-consequences

I've been asked the same question multiple times in the last month from several different groups and I not only do not have a good answer in today's LabVIEW, the solutions I have thought of to propose for tomorrow's LabVIEW all feel clunky to me. So, I figure I'll ask the community for ideas. The situation: Alice creates a collection of VIs that together form two halves of a client-server architecture. The client side sends in requests, the server side sends back responses. Each response includes a name of a dynamically loaded VI or a class (doesn't matter which for the purposes of this problem) that the client has to load in order to process the response. (If we want to get really crafty, the server might have to do similar dynamic loading in response to the information coming from the client, but I don't think that added complexity adds anything to the overall problem to be solved, so let's leave it aside for now.) Bob now builds an application using Alice's VIs. He has his client-side application and his server side application. Everything works in the development environment because all of Alice's VIs are on disk. Now he builds his two applications using AppBuilder. His EXEs do not work because his client application does not include the dynamically loaded VIs/classes (assume Alice did all the right path magic to make it work had the build spec been told to include those files). Problems: 1. The dynamically loaded VIs/classes need to be a part of Bob's built applications. But Bob doesn't even know there's any dynamic loading going on -- that's all private inside Alice's collection of VIs. Is there a way for LabVIEW to magically know "oh, these VIs/classes need to be included in the EXE?" even though there is no static reference to them anywhere in either Alice or Bob's code? 2. Assume there is no way for LabVIEW to magically know this information. Is there something Alice could have done to her code such that Bob is made aware of the need to manually add some files to his build spec as dynamic dependencies (other than just documenting it in some file somewhere and praying that Bob notices)? The answer here may include new features of LabVIEW as needed, but please specify whether you are giving an answer that can be accomplished with LV 2013 vs LV Someday. 3. The whole point of using dynamic loading is so that you don't bring all the VIs/classes into memory at launch. But there may be some VIs/classes that are *never* used in Bob's application. If the answer given in #2 is that Alice specifies all the things she could dynamically load, then they'll all get bundled into Bob's EXE. That may bloat the EXE. Is there any way for Alice to write her code such that Bob can figure out which dynamic loaded VIs/classes are actually possibly used by his application (bonus points if it's a solution that lets LabVIEW can figure it out on Bob's behalf)? 4. Assuming you came up with answers to #2 and #3, do those answers still work if the set of dynamically loaded VIs/classes is open-ended (i.e., a third party could have installed yet more plug-ins for Alice's library to use, and thus Alice cannot enumerate all the possible things that need to be loaded)?

http://xkcd.com/1270/ Functional programming is a thing of beauty. Explaining that beauty to those who do not see it is non-trivial. LabVIEW's dataflow isn't functional, but it has many of the same properties, and is a good deal easier to visualize. I find it to be a more-than-acceptable compromise between the ideal computation space and a usable language for actually getting stuff done.

That's a flavor of weirdness I've never heard of.

Awesome!

Congratulations. It's not an easy exam for any of us.

I think it would work just fine with AF, just not in combination with the preferred implementation (read "easiest to both implement and read") of the State pattern itself within the AF.

It's not a bug. The palettes do not have anything other than names to use as lookup keys. When I designed the shorttcut palettes, I didn't extend this out because supporting multiple items of the same name leads to severe confusion when telling people to drop something from the palettes. Rather than build a bunch of infastructure to try to resolve multiple names, I figured it was better to encourage developers to name things uniquely. And at the time I did it (LV 7.0), libraries were on the horizon to solve any namespacing issues.

Generally speaking, anything that affects all of your state transitions -- and this sort of "store a tidbit for later" action is a potential modifier rule for all of your state transitions -- has to go in the parent class of all your states. You might consider an array of states called "state stack", which you treat as a Push/Pop interface for states, and add a "Try Revert.vi" that you call on yourself periodically. If you have only one method that could trigger the reset, then the other option is to put state into one of your method VIs. This works only if you have a single instance of your Actor running ever because you'll have to make the method non-reentrant and give it state (i.e. an uninitialized shift register or uninitialized feedback node). Personally I don't like this option -- limits future flexibility of the class too much.

imfirefly: Can you describe your localization process? I might be able to get one of our localization engineers to compare yours against ours and see if he/she can highlight some difference.

a) What version of LV are you using? The issues you describe were in LV 8.5 but fixed in 8.6 and later to the best of my knowledge. b) It is hard to help analyze anything without code. Have you opened a service request? Do you still have the corrupted versions?

LAVA user Thoric noticed that the topics about LabVIEW on Wikipedia were poorly maintained and full of inaccuracies. He asked me about updating them -- I told him that it is against Wikipedia policy for anyone who works for NI to update the LabVIEW entries. It's a conflict of interest, so I have never touched them, nor should anyone else who works for NI. If there are LAVA users who are interested, I get the impression from his post last night that Thoric would appreciate help bringing the pages up-to-date. PS: Wikipedia now gives you the option to establish a monthly donation to support their operations. Please consider giving just $3/month to keep one of the most valuable databases on Earth running and independent.

I hereby dub thee "LabVIEW Enthusiast Ambassador To Wikipedia #1". Go forth and edit!

You might be surprised. The requests coming in from Field Sales carry enough weight that it's generally worth asking.

I don't remember how we got it to work. I do know that you can't get two actors launching simultaneously. Regardless of the mechanism, there's no reason for Pre-Launch Init.vi to be reentrant.

Kugr: I have no idea why we made pre-launch init.vi be reentrant. No point since it is only called from a non-reentrant caller. Unfortunately, changing that would be a breaking change needing mutation.

No one at NI can edit those pages -- would be a conflict of interest under Wikipedia rules. Please update the entry if you believe it can be approved. And, while we're on the subject, everyone please consider adding a recurring donation to Wikipedia. They now have set up $3/month recurring donations, which makes it easy to support one of the most valuable databases on the planet.

Were you launching them in parallel? Pre-launch Init.vi is called under Launch Actor which is deliberately not reentrant. Only one VI launches at a time, so if you try to call Launch Actor in parallel, you will get a delay as they serialize launches.

LV 2013 yes, DAQ no. All my development upgraded cleanly from 2012 to 2013 on my home systems with no issues, but I don't program with any of the hardware APIs. You'll need someone else to comment for that aspect.

Ah, the "double dispatch to compare heterogenous types" problem. An ancient frustration of software developers everywhere. And, worse, I suppose you want the comparison operation to be commutative too (i.e., it doesn't matter which object you put into the top input and which into the bottom input)? a) read this: http://en.wikipedia.org/wiki/Double_dispatchhttp://en.wikipedia.org/wiki/Double_dispatch b) I have never heard of a good solution to this problem in any computer language, but LabVIEW is worse than most because of some limitations on our features -- such as the inability to type cast a VI refnum into any connector pane type *without* LabVIEW type checking it. That kind of "reckless type casting" is a damn fine way to crash any application, but if you can write a system that guarantees (and I mean system-level provable) that all the casts are safe, that's the key to a high performance, low maintenance implementation of such a comparison algorithm. But LabVIEW doesn't generally include "use at your own risk" nodes (the exceptions being Type Cast and Call Library, but even Type Cast has some restrictions which is why it doesn't work for this use case). Even if you had such reckless type casting for VI refnums, this is a hard problem to solve elegantly. I generally recommend that you do the type testing, and either have your own static dispatching through a multilayer maze of case structures or build a 2D dynamic dispatch table of your own. This has an obvious performance hit, even if you implement your own "Get Class Index.vi" that every class overrides to return a unique (but compact sequential over the whole set) integer. There is only pain and suffering down this road if you want to avoid runtime type checking. But it is possible. There are multiple ways to do it. All of them are bad in some way. The Visitor pattern is one you will become very familiar with if you try to do this... lots of variations on the Visitor pattern that all essentially go like this: You create a comparison object that visits the first object to be compared, collects some data then visits the second object and actually does the comparison. You can find endless variations online discussing this problem. One solution that does NOT involve the Visitor pattern is this one... If you know the total set of child classes that will ever exist, this works with high performance but high maintenance burden and lots of VIs: 1. In the ancestor class, create a method "Is Valid.vi" that is dynamic dispatch on the top input. 2. In the ancestor class, create N methods named "Is Valid Assuming First Input is <class name>.vi" where <class name> is the name of a child class. The top input is the child class type. The bottom input is the ancestor type and is dynamic dispatch. Do this for every child class that is not an abstract class. 3. Each child overrides "Is Valid.vi" and uses that VI to wrap a call to "Is Valid Assuming First Input is <class name>.vi", where <class name> is this child class' name. 4. Each child overrides ALL of the methods for "Is Valid Assuming First Input Is <class name>.vi" so that it's type is the bottom type and the other class is the top type. Here you write the actual comparison between these two objects because you now know the exact data type. Oh, but there's a problem... you don't have access to the private data of the other class. So you expose the necessary data accessors to dig into the other class. And you write the comparison. 5. But THEN you take that comparison and you do "Create SubVI From Selection" because you need that exact same comparison in the function on the other class where the top and bottom inputs are flipped. -- end -- This results in a system that is actually quite fast at runtime but is a pain to maintain -- the number of methods in the system expands *geometrically* with the number of concrete child classes. All of this gets even worse if you want to have plug-ins or dynamically loaded classes (the difference being with dynamically loaded classes, you know all the classes ahead of time but you don't want them in memory whereas with plug-ins you don't know the complete set when you write the framework). So far as I know, there is no elegant solution to this problem anywhere in CS. If you find one, please let the world know.

Probably won't happen, but I'll mention it. There's a long list already. We did a lot of pruning with customer groups at NIWeek and with some customer education groups over the last year or so.

> It seems there are some major drawbacks! Didn't used to be, and there may not be again in the future. Various folks have talked about reworking the property node to allow VIs that don't have error terminals. there's already a way to disable the error cluster on the property node itself (rarely used and little known popup menu item). > Is it a way to get rid of the 'IDE slowing down' issue > if I remove all the case structures from the property Read/Write VIs? This isn't an "IDE slowing down" issue. This is "my code runs slower at runtime". The choice to use property nodes vs subVIs has *nothing* -- repeat *nothing* -- to do with any IDE slowdowns. Unfortunately, just writing your diagrams to wire the error cluster through and using that popup menu option doesn't suffice -- the property node adds a case structure around every VI call because the syntax of the property node promises not to execute properties if the first one returns an error and it doesn't know whether or not the subVI is going to pass that error wire through unmodified or not when it compiles the caller.

No. I'm not working on LV myself at this point, so my traditional "let me just slip this small tweak in to help LAVA conversation" fixes aren't there this round. Instead I have to convince others to work on it. But there is good news... the plan -- and let me stress plan -- is to work on several debugging-related improvements for 2014, and I'm asking that some work be done to make this task manager work better. No promises, but I am making the request. hilbert00: I missed your question when you first posted it. EXEs are closed boxes with no way to open VI references into an EXE from outside the EXE. So far as I know, there's no way around that. You can compile your EXE with the option to allow remote debugging and then attach the development environment to your running EXE. I haven't tried it... that *might* allow you to open references to the VIs in the EXE. You'd have to test it. If you open projects, each project is a separate application instance. If you're a programmer in other programming environments, the terminology may sound foreign since it is all within a single LabVIEW.exe. It lists all the application instances available within the current LabVIEW. This is why I think the remote debugging idea might work -- a new local application instance is created to debug the remote EXE.

QueueYueue: This is good work. Very good work. Thank you!