Jump to content

Aristos Queue

Members
  • Content Count

    3,119
  • Joined

  • Last visited

  • Days Won

    170

Everything posted by Aristos Queue

  1. No. Those were built exactly to customer spec and do exactly what they promise to do. The fact that they’re a horrible idea doesn’t make them left-hand scissors. There isn’t a better design for shared variables that would make them safer or more practical. Shared variables are more like the 1950s kids’ science kits that shipped with pieces of actual uranium to play with.
  2. Major differences: One was an off-the-cuff prototype that frequently crashed, couldn't nest properly, had no well-defined recompile semantics (so you couldn't trust that if you made a change the callers saw it), and didn't integrate with any of the rest of LabVIEW features except by accident (and, in the case of polyVIs, that accidental interaction was a bug). The other is an actual feature. I don't think we retained any of the original code. Comparing them, especially in the context of complaining about loss of functionality, spreads disinformation to anyone who doesn't know the background h
  3. Malleable VIs didn't exist in 2009. They were new in 2017.
  4. Funny thing... most people use winding can openers wrong, even when they're designed for the correct hand. The intended use of the winding can openers is to open the outside of the can, not the inner edge. If used the intended way, there are way fewer problems with the cans. The usability of can openers is a fascinating metaphor all on its own. 🙂 https://www.insider.com/right-way-to-use-a-can-opener-2018-8
  5. Lately, I've been using a phrase "oh, that's a left-handed scissors feature." I've found it to be a useful concept, so I'm posting it here to the LV community generally. When software engineers create software, we aim to create software that is usable by our customers. To use the colloquialism: the software should delight the user. We sometimes miss. But just because the software isn't designed as the user expects does not mean that it wasn't designed somehow. Often, I find myself fighting my tools (Visual Studio, Perforce, web browser, operating system, etc.) because it just isn't d
  6. 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.
  7. 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.
  8. 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 typ
  9. 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.)
  10. I have no idea why that limitation exists. I’ll ask on Monday.
  11. 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
  12. 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.
  13. That should work. That is how the Assert Type VIs work.
  14. 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 t
  15. 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!"
  16. 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"
  17. 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
  18. 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
  19. 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 tha
  20. 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 followe
  21. Malleable VIs, not VI macros. VI macros is a never-released, LV2016-and-earlier prototype feature.
  22. The time dilation near a massive, dense, nearly-impenetrable object (aka Fortran) keeps them forever young. It's also why fixing a bug takes so long from the perspective of those standing further away. The LIGO gravity wave detector had to filter out Fortran code submissions to detect black holes (both cause merge collisions). My second internship involved Fortran. I know of what I speak. I was grateful for the experience... it set me on the path to ever higher-level languages!!!
  23. The reverse engineering isn’t the driver of trustzone and similar. The driver is the threat of untrustworthy code being distributed by malicious authors. We need a chain of trust back to the original code author in all cases.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.