Jump to content

Daklu

Members
  • Content Count

    1,824
  • Joined

  • Last visited

  • Days Won

    82

Everything posted by Daklu

  1. 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 opti
  2. 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.
  3. The AF priority queue does enforce ordering. The DQMH priority queue does not. (I'm not advocating for one or the other... personally I think priority queues are a bad idea.)
  4. That's a great example, and I'll add that I think your conclusion holds even if you didn't look at the implementation. On the surface the conceptual model presented by the AF seems more complex. It has multiple priority levels available whereas the DQMH has only a single priority level. But the AF implementation behaves predictably--messages sent in order (with the same priority level) execute in order, while the DQMH implementation may not. On the other hand, I think Fab strongly recommends only sending Exit/Abort messages as priority, and as long as one follows that rule you coul
  5. Yeah, I agree with you for the most part. Maybe that's because the applications LV developers are typically asked to write are a small fraction of the kinds of software that can be written. My projects almost always boil down to some sort of machine control or acquire/analyze/present. (I've not heard of anyone building a load-balancing web server, a cool 3D game, or a spreadsheet using LV.) Eh... that may be true for some of them. There's an inherent impedance in connecting non-AF code to AF code that tends to encourage people to use AF for the entire app. (At least there w
  6. 1. What application architecture do you use for higher-level organisation? I'm going to be pedantic and change my answer, since the options listed are frameworks, not architectures. 😋 The architecture I most frequently use is the "hierarchical actor architecture." If one were to ask for a little more detail, I'd say "hierarchical actors with asynchronous name-data messages."
  7. The things I've read always refer to it as "accidental" complexity, but you can think of it as "unnecessary", "incidental", or simply "non-required" complexity. It's just complexity in a system that isn't a necessary to meet the requirement (both functional and non-functional) of the system. System complexity is a subjective evaluation, so these are more abstract ideas than concrete rules to follow.
  8. Hmm... I'd slightly change that to say the payoff of a good architecture is in managing an application's inherent complexity. IMO, the whole point of a framework is to increase productivity, so a "good" framework is one that does that. Naturally, the frameworks we're talking about here are neither wholly good or bad, just good or less-good for a specific set of project requirements. I disagree with the claim that a good framework makes complex applications simpler. An application with complicated requirements is going to have some minimum amount of inherent complexity. The best a
  9. Funny you mention this. Here's a slide from the most recent version of my Fundamentals of AOP presentation.
  10. Is this restricted to AF actors specifically, or would our own actors also be first-class citizens?
  11. I have experienced the exact same thing using LapDog over the past 10 years. There are very few (if any?) times when I have to have to write lengthy boiler-plate code that could be made more efficient with scripting.
  12. I chose, "Other publicly available message-passing-style 'framework,'" though I could have also chosen "Your own or your company's internal framework or templates" or "Other (please post, this includes architecting each application from scratch)" since outside of a few templates I typically write each app more or less from scratch. (I will yank modules used in previous apps and modify as needed, but I don't typically bother making them into reuse packages.) Predictably, I use LapDog, and I'm glad you put "framework" in quotes as messaging libraries aren't frameworks. [Edit
  13. FYI, I got a file permission error on Windows 10 when trying to set the file extensions I wanted the launcher to handle. It was easy enough to fix by manually giving myself write permission to C:\ProgramData\LabVIEW Tray Launcher\config.ini, but it is an issue I ran into. Also, do you have the source up on GitHub?
  14. That's in line with what I remembered, but I didn't want to spread misinformation. (Age plays havoc on my memory.)
  15. My apologies if I misrepresented what you said. Can you elaborate on why you recommend against using XControls?
  16. I am under the impression XControls have more or less been relegated to the rusty nails bin. I know I've seen NI employees recommend against using them in presentations.
  17. Nope. AFAIK the only way to set a class constant value is to write a VI setting the object's value, then copy the object with the desired values from an indicator and paste it onto the block diagram. I (as most developers I know) generally avoid using class constants on block diagrams and have adopted something more like what Dan suggests. Good ideas win out... For example, all my classes have a "Create <MyClass>" method that more or less acts like a constructor. The only time I ever drop a class constant on a block diagram is for typing operations (eg: upcasting o
  18. I agree none of this is a trivial task and recompiling NI Linux RT to run on an x86 processor might be easier. I haven't looked at the source code (and have never recompiled Linux), do you have any idea how much code would need to be changed to support an x86 processor? My gut says more than I'd be comfortable with. FWIW, QEMU looks the most promising of the VMs I looked at.
  19. I was thinking more along the lines of a direct ARM VM, not an ARM emulator running inside an x86 VM. There are a few out there... I haven't had a chance to try any of them yet.
  20. No, I haven't tried to do this. I didn't know ARM-based VMs were available.
  21. Wow... was it really four years ago that we talked about this? Time flies when you get old... I don't think I've used futures again since this thread** so I can't speak to the attitudes of the larger community, but my terminology preference is "future token" and "redeem." I do agree with Shaun though, it probably doesn't matter as long as you communicate it effectively and are consistent. [**My development focus over the last several years has shifted from pushing boundaries on actor-oriented and messaging systems to figuring out how to refactor, componentize, and deploy an NI-RT a
  22. I've never thought of eliminating the object out for methods that do not change state... interesting idea. One side effect of doing that is you are also ensuring no child classes can ever change their state in the overriding method either. That may or may not be desirable in any given situation. Just out of curiosity AQ, how do you arrange your block diagram when making calls to multiple non-state-changing methods? Do you just run the class wire underneath the methods that don't return an object?
  23. No, I didn't. To be honest it ended up on the ever-growing pile of partially finished things I hope to get to sometime.
×
×
  • Create New...

Important Information

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