Jump to content

All Activity

This stream auto-updates     

  1. Yesterday
  2. As @Daklu mentioned, "complexity" is being used for various perspectives in this thread. Maybe this entire discussion should also be moved to another thread? Here is a definition for "complexity" I find helpful at times like this: The important part is "difficult to re-create". Now let me pick up the example from before: By this definition of complexity, DQMH is indeed more complex than the Actor Framework because it produces many more potential outcomes (its operating state space is larger). The keyword in this example is "determinism": Priority messages in DQMH are nondeterministic (less deterministic is probably a better definition). Priority messages in AF are deterministic. A subtle yet important difference. Of course, here we are looking at the complexity of the framework itself, not the complexity of the user's code. When designing the architecture of a software, optional features like this should be taken into account. If determinism is a key requirement, AF is certainly a better choice than DQMH (not taking other key requirements into account). Let's assume we went with DQMH. This decision can lead to higher costs in the future if determinism turns out to be important and priority messages are being used a lot. In this case there are multiple options: Keep using DQMH and work around the problem with a custom solution => see sunk-cost-fallacy. Switch to another framework like AF You might think "that's never going to happen to me" => see Murphy's law If options were truly optional they would be extensions, not part of the core framework. The fact that priority messages are part of the core framework is a strong indicator that it is not possible to create the same behavior with the API. Thus, it is not optional but an important feature of the framework. As a user certainly, yes.
  3. Last week
  4. Here you're talking about the complexity of an application that uses the framework, in which case I agree the application's complexity isn't necessarily increased by the unused framework options. (This is especially true if the person inheriting the code has previously used the framework. I'm not convinced it's true if the inheritor knows nothing about the framework.) I'm talking about the complexity of the framework itself (which is also what your original comment seemed to refer to) and how easy it is to build a mental model of how the thing works. More behavioral exceptions and options make it more difficult to understand, which I equate to being more complicated. I completely agree how an option is presented can dramatically impact how a user perceives the complexity. I disagree optional terminals add zero complexity to the framework. It may be an insignificant amount of additional complexity for those who see it and mentally discard it immediately, but even in that extreme case it still takes a non-zero amount of effort to process that option and decide where it fits in the mental model we're creating. While learnability and complexity are not exactly synonymous, in my mind they're at least very closely correlated. What kind of complexity are you referring to?
  5. Thanks.It worked great but I don't think I'm going to go through the other 13 versions and installing it. Can a mod move these posts to a new thread (about VI Analyzer) so as not to clutter up this one?
  6. Right, VI Analyzer Toolkit 2016 was the first version to officially support 64-bit LabVIEW. For unofficial support in previous versions, we have this resource: https://forums.ni.com/t5/VI-Analyzer-Enthusiasts/Using-the-VI-Analyzer-Toolkit-with-64-bit-LabVIEW/ta-p/3494395
  7. Hmm. No 64 bit versions for 2009-2015. Thanks for the info.
  8. Yes, it's a LabVIEW Toolkit, which means you have to install it separately for each LabVIEW you have. Here's the download page where you can get whichever version (and bitness) toolkit installer(s) you need: https://www.ni.com/en-us/support/downloads/software-products/download.labview-vi-analyzer-toolkit.html
  9. I'm interested in learning more about it-- can we see the presentation? I have never installed NXG but this sort of thing is what would sell me on it. My superficial impression has been that it's, at this point, LabVIEW with vector graphics.
  10. 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.
  11. 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). To further complicate the issue, choosing to use an optional feature might actually decrease the complexity of the user's code written within the framework -- there are options that are available for specific tasks that avoid the user having to work out those tasks on their own. While the learnability of a framework might be impacted by options, I don't think the complexity is changed by them. Does that make sense?
  12. I disagree. While it is entirely realistic to build apps without using priority queues, having this option available does add complexity to the AF and DQMH. If you show someone a regular piano and an electric piano/synthesizer and ask then which is more complicated, what do you think they'll say? Having more optional features available, especially when they're easily discoverable by users, adds complexity. Users are going to spend a non-zero amount of time considering those optional features and adjusting their mental model of how the framework works.
  13. Hi there from the future! I stumbled upon the same problem due to this exact .NET bug in labview, which apparently is known to NI since at least 2014 and hasn't been fixed 5 years later. The issue is that you can't select the constructor with CompressionMode as parameter - it's always overridden with the version using CompressionLevel as parameter. So you can use it for compression (because the default CompressionMode is compression) but you can't decompress. Anyway, thanks for the great workaround and the excellent explanation - that's rare to find!
  14. I've got it in 2019 but not in all the other versions. Is there a separate test install for each version?
  15. Potato, Potato Like i keep saying (and you agreed earlier) the Priority Queue is ordered PRIORITIES, not necessarily the elements (we disagree on this bit). The underlying implementation is irrelevant the name-it could even be a linked list.
  16. The VI Analyzer has core components installed with LabVIEW, like the UI you're seeing. The VI Analyzer Toolkit is a separate install with 90+ tests, including the Complexity Metrics tests. So you need to install the VI Analyzer Toolkit to see the tests.
  17. 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 using C++ correctly. Incorrect C++ use is generally associated with euphoria and a belief that you've found "an easy way to do it!" by avoiding some part of the standard template library.)
  18. 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.
  19. I mostly meant that this is internal tool used by a company, created years back. Not sure if it was created internally on by a contractor. Anyway, looks like the tool re-compiles properly from the reversed sources. Can't be completely sure as I don't have a related hardware, but various forms are properly linked to each other and are trying to display something. The original project probably had some fake dependencies in it - the smaller binary I built seem to do the same thing as original. (though I can't be sure there's no corner case where it will go "file not found") General steps: 1. Extract EXE, decrypt ZIP inside 2. Create a folder, create new LabView project there 3. create sub-folder within project folder, ie. "app" or "lv" or however you want to call the labview app part; copy the files extracted from ZIP there 4. Copy any config and data files (and folders) distributed with original binary to the project folder 5. Copy options from BinryName.ini into your BinaryName.lvproj (created in step 2) 6. Open the project in LabView 7. Add each folder from your labview app part to the project; use "My Computer" -> "Add" -> "Folder (Auto-populating)" 8. Make new build target; use "Build Specifications" -> "New" -> "Application" 9. Set proper "Name: and "Target filename" in build target "Information" tab 10. Find the starting form of the original app and add it as "Startup VIs" in build target "Source files" tab 11. You shouldn't have to put anything in "Always included" list in build target "Source files" tab; but if you want - you can now 12. Disable all the "Remove ..." and "Disconnect ..." options in build target "Additional Exclusions" tab 13. Fix any "Missing items" in the project, by placing files in correct places or modifying *.lvlib files which point to locations of additional files 14. Build the project Now I'm getting interested in the single VI files, and how to get their edit functionality back.
  20. Unless you use STL which makes a lot of use of them. The big question is if STL buys you much or just causes you even more trouble. It's better than using the C++ template feature yourself though. That is pure evil.
  21. I don't think it does Cyclomatic Complexity Correct if I'm wrong because I rarely use it.
  22. Perhaps in the AF case. However it's also fairly common for the underlying implementation to be a stack (LIFO). That is effectively what the DQMH implementation is. Like "accidental"? You understimate the power of a marketing department, my friend
  23. I've had a google and you're right, there are uses of "priority queue" for structures that are not analogous to common meaning of "queue". Wikipedia even labels a stack with priority as being a "priority queue". Personally I think this counterproductive when used with frameworks as only a subset of users will know the secret language. Surely we can use English words with their standard meanings.
  1. Load more activity
×
×
  • Create New...

Important Information

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