Aristos Queue

Malleable VIs never could go in a poly VI. It's been that way since they were introduced in LV 2017. That's by design: they conflict with the rules of polyVIs for deciding which instance to use. Poly VIs need a fixed list of connector panes.

Those two primitives were explicitly tagged to be blocked... none of the people involved are still at NI. The comment says, essentially, “These boded crash sometimes when inlined,” with no useful detail, no steps to reproduce. I’ll look into it some more, but I have no clue what the issues could be.

We have an undefined type. Create an output tunnel from Your Favorite Structure node and don't wire the inside. You'll get a void wire, which is distinct from a broken wire. Void is also the type of a wire output from a subVI call node when you delete the terminal from the subVI's connector pane. Void wires don't have a control/indicator, and most poly nodes won't adapt to void (deliberately), so the VIM instances cannot adapt to void type. Void is probably not what you're looking for. Something like empty cluster is what you're looking for, but VIMs deliberately cannot have that type in their conpane, and it contradicts a key principle of VIMs: the conpane shows the user the intended usage, and by having one required working base case, we avoid many of the ambiguous interpretation issues of C++ templates. The code has to be semantically valid for at least one set of types. Having a terminal whose type is "undefined" doesn't tell the user the kind of data that they should be wiring to that terminal. I see your problem. I don't see a solution at the moment. An undefined type seems fundamentally flawed to me.

I’m pretty sure that’s the easiest to implement, so I’m liking your opinion. (Trying to be non-biased, I do think that’s the better option from usability. If I pick a name in a template, it’s because I expect the provided thing to use that name. It is consistent with the class method behavior, but for cluster fields.)

I have no idea why that limitation exists. I’ll ask on Monday.

Huh. I never considered that case. Everything is behaving as designed... but that’s clearly not desirable. So far, no node has custom type prop behavior when inside a VIM other than the adaptive class method calls. You’re suggesting (I think rightly) that "(un)bundle by name" nodes need to adapt different inside VIMs than in VIs. I’d have to teach the bundle by name nodes to have deeper history than they currently have so they always compute from original configuration instead of latest configuration. Or... would it be better to just freeze the named bundle nodes inside VIMs so they always look for the exact name? There’s some risk with either solution to break existing VIMs, but the current model seems mostly useless. What option sounds best? One of the two options is waaaaay easier to implement, and I’m trying not to let that sway me. 🙂

DVRs in VIMs works just fine (just double checked). It has worked since the feature released, still works in 2019. I have no idea what you’re talking about.

That should work. That is how the Assert Type VIs work.

If you have suggestions for how to report those errors, I'm all ears. I've been in hours of design meetings trying to come up with some algorithm for reversing type prop to figure out which inputs contributed to a given break *and* figuring out how to get the errors invalidated when the VIM gets edited. The current "break them all" is the best we've got at this time. There are some simple cases where the VIM's FP term connects directly to a particular node and the node refuses that input, but the further downstream, the harder it gets. And the most syntactically correct solution is "any wire that connects to the node is at fault", but that is essentially equivalent to the current solution as soon as you put one Type Specialization structure or error Case structure down (those tend to encompass the whole diagram, so all the FP terms wire into them). Opening the instance VI and looking at the diagram to see what broke is the best I've got. I would like to make the diagram visible without having to convert the instance to a real VI, but if there's a better option, please let me (and the rest of R&D) know.

Different users, different use cases... and for some, the passwords have real value. So they linger. Just occurred to me: maybe we should call it something other than a "password", since that sounds like security. Instead of "Set password", call it "Join editing region". Instead of "Enter password", use "Enable editing for region". It preserves the functionality but steps us away from this constant drumbeat of "your security is broken!"

Just locking doesn't suffice: 1. It doesn't give you the ability to unlock specific subsets of VIs. 2. It doesn't keep production line engineers from "just unlocking it"

I don't know if that was the same meeting I was in or if I was pulled in after the fact, but that was where I tried to argue against having password protection at all. The answer I got back was, "This isn't a security feature. It's a feature to keep developers and production line techs from accidentally modifying VIs they didn't intend to modify, and providing a way (by using the common password) to unlock specific subsets of VIs when editing is desired." That seemed like a useful concept to me. Ever since then, I've been fine with basic security around the password, as long as we make it clear to users that the password isn't intended to protect intellectual property. And that's what we do: There's a lot more detail in that KB entry. We document this in a few other places as well.

If they can be vetted and approved for signing. But the big point is that unsigned code simply cannot execute on these CPUs, so unknown actors cannot approve. But you are already in that situation. The operating systems already can (and do) lock out a bunch of functionality. OSes and CPUs can already break backward compatibility if they choose. You already trust those companies deeply. "nothing more"? Yes. It is exactly that. I don't know what you mean by nothing more... it should be "nothing less than Cert Authority", which is what we have today. Also, as I said, you can get your own signature for installation on your CPU to allow you to sign other apps. The system doesn't make you beholden to those companies. But it does keep foreign code that gets smuggled onto your system from executing, which is a massive and rising problem today.

That's level 1 signing, to verify provenance. Good practice, but what we are talking about is level 2 signing, which requires you to submit your EXE to MS/Intel/Apple/etc to have it signed by the chip's own signature. Without that, a secure CPU will refuse to run your code. MS/Intel/Apple/etc would pretty much operate the way Apple does with the Apple App Store, where they vet who you are, why you're putting this EXE out into the world, etc. A company could create their own signature (derived from the MS/Intel/Apple/etc) signature and install that on all the CPUs of their company, and that would let them sign their own apps. So you would deliver your EXE to your customer and they would have to sign it before installing it on their machines.

The only correct, intended, non-hack ways to get a reference to an existing clone VI is to use the "This VI Reference" node on the clone VI's own block diagram and have the clone send that reference to someone else as part of its own execution. Any other mechanism was never intended to work and is generally unstable outside of very specific use patterns. There is one mechanism available, and I requested that R&D leave it working even though it can be unstable, and that is the Open VI Reference node when you pass a string. You can pass the qualified name of the original VI followed by a colon followed by an integer to get a reference to that specific clone. The big big big caveat is that you need to close that reference before the clone is disposed. This technique is used by the LV Task Manager, and that tool is the only reason that this feature remains instead of being fixed as a bug. Unfortunately, it really isn't possible to make this feature stable without a significant performance hit on calls to clone VIs. It wasn't intended to work, which is why there's no official way to do it, just the devs forgot to close Open VI Reference loophole. Even if you do get a reference to one clone, any properties you set on that clone while running will be set only on that clone. Likewise, anything you set on the original VI ref will only be set on the original VI (with exception of breakpoints). LV has intentionally never created a "me and all my clones" ref (the reasons why are a topic for a different discussion thread). If you make changes to the original VI BEFORE the clones are replicated, then the clones will have any changes you make. That generally means never calling the original VI as a subVI and instead always calling it through Call By Reference node.