Jump to content

jon_mcbee

Members
  • Posts

    25
  • Joined

  • Last visited

  • Days Won

    1

jon_mcbee last won the day on July 22 2016

jon_mcbee had the most liked content!

Profile Information

  • Gender
    Male
  • Location
    *New* England
  • Interests
    I really enjoy playing the banjo

Contact Methods

LabVIEW Information

  • Version
    LabVIEW 2023
  • Since
    2004

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

jon_mcbee's Achievements

Newbie

Newbie (1/14)

  • Conversation Starter Rare
  • Reacting Well Rare
  • Week One Done
  • One Month Later
  • One Year In Rare

Recent Badges

7

Reputation

  1. I am using git submodules + some custom tooling as a package management system for reuse code and I have found myself wanting to remove VIs associated with a given project from the compiled object cache. Anyone gone down this road and found anything useful? I am expecting to need to take the next step and just start building my submodules into PPLs and depending on those, but since I am here I thought I would ask if anyone has had any fun experiences with manually manipulating the compiled object cache.
  2. I think that we are saying pretty similar things. The only reason you would ever chose to consume a package is that the API hides complexity in a way that simplifies your application. If the cost of consuming the API is high then you probably will decide not to consume it. If the cost of the implementation behind the API is high you definitely will decide not to consume it (because what is the point?). That said I suppose I should update the slides to explicitly show that cost/benefit is a sliding scale, something with low cost probably has high benefit, and something with high cost probably has low benefit, and that is true for both the API and the functionality behind it.
  3. So Stream is a mediator-ish message/data bus with transport abstraction, so two parts of the code can publish/subscribe to data/message by type and name and not be concerned with how the data/message moves. MVA takes what Stream does and uses it to extend the Actor Framework, while also building in extension points for Views, View Management, Models, and a ViewModel (so MVVM as an extension of the AF with a built in message/data bus to help decouple Views from Models). Over the past two and a half years we have only used MVA for project code, so it is under active development/maintenance while Stream is not and has not been used in project code. I am working on ramping back up with the blogging, been too busy with business lately unfortunately, and MVA will be featured more prominently in the new blog entries.
  4. So what I was going for was that the API has a cost associated with learning and using it as a consumer of the component, while the functionality encapsulated within the component is the benefit that you get when you pay the cost to consume the API. As a consumer of the component you don't pay a cost for the functionality hidden behind the API, I suppose that if you find yourself paying a cost for the functionality hidden behind the component you would probably stop using the component because it isn't adding any value.
  5. As Michael mentioned above we (Composed Systems) primarily use the MVA Framework (which is an extension of the Actor Framework). One note is that MVA is our separation of concerns focused framework that we use for decoupling of UI and Business Logic and the messaging between them, but we also use other frameworks that are not messaging frameworks for other aspects of development. After a few years of building up our tool chain we have MVA for messaging, a sequencing framework (Test Executive), and an event logging framework. We use each of these frameworks in each of our projects and extend each for application specific needs. I had lunch with a customer last week that we have been working with for coming up on two years, and he was saying that from his point of view he doesn't program in LabVIEW anymore, he just uses our tools (frameworks). I think this is great, I'd be curious if other people agree or are horrified by it.
  6. Composed Systems will be donating an Uncle Bob Book Bundle comprised of "Agile Software Development, Principles, Patterns, and Practices"; "Clean Code: A Handbook of Agile Software Craftsmanship"; and "The Clean Coder: A Code of Conduct for Professional Programmers".
  7. Just got my ticket, I actually remembered to buy it ahead of time this year (although I was still too slow for the early bird pricing so there is room for improvement next year).
  8. Hey guys, I updated the tool based on some feedback from John Lokanis, I'd be interested in hearing your feedback, especially on how to host the VIP. I put the VIP on my blogsite as an experiment to see if I could drive traffic up but I know its not the proper place for it. http://www.labviewcraftsmen.com/blog/labview-class-dependency-viewer-part-2 Thanks Jon
  9. Hey John, I updated the tool based on your feedback and added the force directed graph as a visualization option. Let me know what you think: http://www.labviewcraftsmen.com/blog/labview-class-dependency-viewer-part-2 -Jon
  10. Hey John, I'm a little late to the party, but I am curious what metric you used to drive the size of the nodes in your graph? Thanks, Jon
  11. I dont know if this will help you or not, but would love to get feedback from you on its usefulness. I have attached an example project that compares a very simple piece of code written with a QMH, written with an LVOOP approach, and written with the Actor Framework. I used this as a demo at a recent CLA/CLD summit. It is intended to be an apples to apples to apples comparison for someone who is looking to learn LVOOP/Actor Framework. It was originally posted on the NI Community Forums, but I apparently cant link to the page from LAVA(?) (Thanks Todd). EDIT: Replaced attached files with link to files on the NI Community Forums so that I only have to maintain one set of files: https://decibel.ni.com/content/docs/DOC-32600
  12. Is it possible to call the oldest ancestors implementation of a dynamic dispatch VI? Lets say that I have an inheritance hierarchy where the oldest ancestor is called DUT and has three abstract dynamic dispatch methods (to be overridden and not extended by children): Read Torque, Read Trip, Read Serial Number. DUT has a child class called Mindbender3000, and Mindbender3000 overrides all of the parent dynamic dispatch methods: Read Torque, Read Trip, and Read Serial Number. Somewhere down the road an upgrade is made to the Mindbender3000 product, and Mindbender5000 is born. The upgrade incorporated two main improvements, a clock was added to the new hardware that we can now query using a Read Clock method, and the ability to Read Trip was removed from the device. To account for these changes, a new abstract dynamic dispatch method is added to the DUT class, Read Clock, and a child class of MindBender3000 is created, named Mindbender5000. Mindbender5000 uses its parents implementation of the Read Torque, and Read Serial Number override methods, and overrides the DUT classes dynamic dispatch method for Read Clock. Ideally, Mindbender5000 would use the DUT classes implementation of the Read Trip method, as it is abstract and doesn't really do anything. However, because Mindbender 3000 has already overridden the Read Trip method, the Mindbender5000 product wants to use its implementation. Is there a way to call DUTs Read Trip dynamic dispatch method from the Mindbender5000 class? Lets assume that DUT has other children that need to be able to override these dynamic dispatch methods, including the new Read Clock method. Thanks!
  13. I admit I am not as well versed in UML as I should be, so I may be misreading your diagram. I don't understand why the DUT class holds a reference to the Message class in its object definition.
  14. I see. The Message parent class is abstract and its implementation of the "Execute Message" dynamic-dispatch method does nothing. Message's children override (not extend) the "Execute Message". An extra input is added to the "Execute Message" method for DUT class. The DUT parent class has a dynamic-dispatch method for every child of the Message class. The DUT dynamic-dispatch methods are embedded in their corresponding Message child override "Execute Message" method. The trick to making this work is that the DUT parent class must have an abstract dynamic-dispatch method for every child class of the Method Message class, and the corresponding DUT dynamic-dispatch method must be embedded into the "Execute Message" override method of each Message child class. Is there a name for this pattern? Is this a pattern? Or is this just common knowledge?
  15. I have a problem I am trying to solve using LVOOP, it seems like there should be an established way to solve it but I have been unable to think of/find anything that works. Here is a description, I dont have any code mocked up that I can attach, but if it would be helpful I can put some together. I am writing a test executive that will test multiple families of devices. Each family has the same set of commands, but the commands may be implemented differently (don't have to be though). I have an abstract parent class called DUT, and have children for each device family. I also have an abstract parent class called Message, with a child message class for each command in my command set. This is where I am getting stuck. All devices have the same messages, certain devices implement (structure and parse) certain messages differently. It smells like I want to override based on both device type and individual message, but this is not possible. I am hoping that someone can point out either where I went wrong, or what the logical next step would be. If more information is needed, please ask questions and I will do my best to answer. Thanks!
×
×
  • Create New...

Important Information

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