Jump to content

Aristos Queue

Members
  • Content Count

    3,119
  • Joined

  • Last visited

  • Days Won

    170

Everything posted by Aristos Queue

  1. Speaking as a 19-year dev in LabVIEW R&D, Hooovaaah is pretty much right. NI wouldn’t do anything to change our EXE format because of this work. None of the current design is viewed as a security layer. We’ve talked about secure computing initiatives in R&D. NI will probably lag the curve there (NI tends to adopt tech when it is already commodity), but I suspect it’ll happen this decade. I very much hope the world gets there soon. Unsigned EXEs are a major threat vector, and the IOT threat just keeps increasing. The world can’t afford to keep running arbitrary code much longer, i
  2. This is a question that is probably better posted to https://forums.ni.com where a National Instruments Tech Support Engineer can maybe help you.
  3. I'm not sure what the term is for the negativity introduced by options, but it is not (as I see it) the same as "complexity" being discussed elsewhere in this thread. The unused options do not add anything to the complexity as far as the user having to create more code or having more difficulty reading the code that they do create using the framework. Depending upon how the option is presented, it might not even add anything to the complexity of adopting the framework (there are plenty of optional terminals that we just gloss over on commonly used functions and never bother to even read about)
  4. In the wrong hands, perhaps it is some evil. I made extensive use of it to get sets and maps in LV 2019 acceleration for specific inner data types with some quite readable code (according to my reviewers). I save "pure evil" for data multiple inheritance and single character variable names. This is a question??? In 2005, maybe. At this point, if you aren't using the STL in your C++ code, I suggest you change languages because you aren't using C++ right. (Note that if you are weeping constantly and your hands bleed and your stomach ulcers bloom, those are good signs that you're usi
  5. That would be a "stack", not a "queue." What the DQMH implements is a third thing: a "bug". 🙂 Note that it is a known, documented bug because the single message is good enough for DQMH purposes and not intended for more than one message.
  6. A priority queue DOES order priorities. You enqueue a pair of data items: a message and a priority. The queue sorts the pair by the priority. It just ALSO retains the secondary sort order of FIFO. How the queue is implemented under-the-hood is anyone's guess, but ordering actual physical priorities is one possible implementation (and one that is used for an arbitrary priority heap).
  7. A framework's artificial complexity is only from the things that the framework forces on your code, not the options that it enables if you choose to buy into it. AF and DQMH without priority queuing are no more or less complex than AF and DQMH with priority queuing. The priority queuing only becomes a part of the complexity computations if "priority" were a required input and you had to send some messages at a non-normal priority. Because you can use both frameworks entirely without ever using priority, it isn't part of the computation. It is an option that you can choose to exercise in y
  8. > The tool is proprietary So you cannot just rebuild from source code because you don't own the source code? I'm going to assume the EULA agreement on this tool lets you do this. If it doesn't, please don't tell me... that's between you and the code owner. But you might consider contacting the author of the tool and asking for the source code and/or asking for some specific changes. Sometimes asking works, and either would be less work than reverse engineering LV's internal EXE structure.
  9. I'm intellectually intrigued by the project, but I hesitate to help since the tool you're building would allow someone to create a new EXE that looks like an EXE that might come from some reputable source but has had various key components replaced. That is, of course, something someone could do today (in LV or any other programming language), given enough effort and time. But it takes effort and time, and I don't think I should help short circuit that, given who I work for. I am interested in your use case. I take it you have some EXE that you don't have the source code for but you need/
  10. OO is contradictory to functional as practiced by C#/JAVA/C++. Those languages insist on by classes by pointer or reference (C++ can do by value, but doesn't use it commonly). OO is compatible to functional when it behaves by value, as it does in LabVIEW. But many functional languages consider OO to be a half step toward more functional features: dynamic dispatching is subsumed by pattern matching, for example.
  11. No. The AF remains as it is in NXG. This would be something new.
  12. Allow me to introduce you to implied spaces. When I build a two-story house, I consciously add a staircase between the zeroth and first floors. I add handrails for safety, optimize the height of the steps for average human legs, etc. I spend a lot of time designing the staircase. What I don't spend a lot of time designing is the room under the stairs. I put a door on it and turn it into a closet, a storage place for the people who live in the house. Now, the people who live in the house start using that storage space -- exactly as intended. But after a while, they are complaini
  13. I'm not sure how to answer this question. To me, it's equivalent of asking whether LabVIEW will let you add your own definition of VIs. NXG has the ability for you to create your own models of computation. To make your question more confusing, these actors aren't AF actors... the AF is a library where actors are constructed out of bits and pieces of language that we have available. This would be its own thing. Regardless, it is years away, and I don't want to hijack Powell's discussion on things that exist today.
  14. Y'all sometimes ask me, "AQ, why are you so eager for LabVIEW NXG?" Language extension is the biggest answer. The code layers of NXG are far more amenable to language extensions. I've got an 80-slide PPTX on actors as first-class citizens: no queue management, no classes for messages but retaining type safety, no weird error codes, easy handling of parallel loops without custom stop signals, direct execution testing, debug monitoring... but I just don't see it happening in LabVIEW. The compiler simply isn't sophisticated enough to take a high-level diagram and generate the code implied by it -
  15. Ask the others on this forum... they'll tell you I try never to promise future functionality. All sorts of things can conspire against a feature. I mean, everything from a malicious server virus wipes out all of last week's code changes across all backups to NI deciding to "change course" and go into knitting and not releasing any more software. But... taking all of that into account... you can have some faith that it'll be in the next full version of LabVIEW, sometime next year. If there is a next year... 🙂
  16. If you have LV 2019, this will be faster if your array gets large enough* * "large enough" varies by CPU and memory of specific hardware.
  17. I wouldn't trust a malleable VI inside an XNode at all without extensive testing. XNodes are unsupported tech when used for general purpose problem solving. Although I did do some light testing of the interaction between the two technologies a couple years ago, I did not vet their interaction fully. When NI writes an XNode, we don't assume that "XNode" is a safe tech to use... we vet the specific XNode that we are writing, checking its correctness and stability under its various scenarios. None of our shipping XNodes have used VIMs. You may have success using the two together, but I'd adv
  18. I suspect UTF uses "Set Scope", which is a separate method that doesn't do the propagation. The UTF authors may have written their own propagation loop. You could use the same workaround (I acknowledge how annoying that would be to write, but at least the option exists). BTW, looking at code, turns out that the "And Propagate" version was written to always prompt. That's how the Library Properties dialog works. On my machine as of this morning, there's a new Boolean parameter to "skip prompt" on that method.
  19. pktl: Yuck. I don't know how long *that* has been broken. We shouldn't be prompting from the scripting method. I'll file a bug report for it. The gUnattended does repress the dialog box, but it also makes the scope change *not* propagate, which defeats the purpose.
  20. DVRs can be upcast and downcast with To More Generic and To More Specific. So if you have a public type that is the ancestor of the private one, you can upcast to the public one in public and then downcast when you need to actually use it. That's all completely type safe. (Note: DVR of LabVIEW Object works without you having to create a new ancestor class.)
  21. Even as a pointer, that wouldn't work in C++. Any use of the type in a public signature must be public, even by pointer, even by reference.
  22. You people are so laid back and forgiving. I’m an editor on multiple wikis across cyberspace, and none of the others are anything less than draconian. Capitalization whatever?! Wow. I’m going to need to wear my oversized Hawaiian shirt and cargo shorts when I’m editing, just to get in the right state of mind! 🙂
  23. If you want to run the VI in the IDE as a tool of some sort, save it into the "<LabVIEW>\project" subdirectory. Every VI in that directory gets automatically picked up and added to the Tools menu. The menu item gets its text from the display name of the VI, saved in VI Properties. When the menu item is chosen, your VI is run in an isolated application instance so it never interferes with running applications. App instance isolation is how all the G parts of the IDE execute, like the icon editor, the getting started window, or the right-click menus.
  24. I noted a few uses of lowercase "boolean". Capitalizing that B is often confusing because it is the only non-class type that is typically capitalized. Text languages have solved this by using keyword "bool", and therefore that is the actual type name. LabVIEW doesn't typically type out data types. NI style guide says to capitalize Boolean. Does LV wiki agree? When I'm editing the wiki, I will generally follow NI documentation style guidelines (so "subVI" instead of "SubVI", for example). Are there any particular conventions that the community has established that differ from NI standa
×
×
  • Create New...

Important Information

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