My understanding is that this is an OOP in LabVIEW problem and not an AF problem. So, if you are going to use classes and dynamic dispatch you "may" run into problems.
Perhaps you could elaborate on the issue with dynamic dispatch?
I think we should end the discussion of license rates. Let's keep this thread about AF on cRIO please.
Agreed, take is elsewhere. Preferrable another thread in this group b/c this seems to be the one where the most advanced LVOOP is talked about.
But part of me is also annoyed. I work for a very large company, and we must have hundreds if not 1K labview licenses, all at about $5k a pop. The culture is such that we value stability in our code, as well as avoid potential security conflicts by "trusting" open source code.
Further, for the amount we pay NI, it seems like they should be able to develop watertight frameworks for OOP application development on their own.
I'm confused. You're annoyed at the community source projects because you are concerned about the stability and security of your code base, but you've been considering using new features in the experimental forks we've posted on the community page?
Allow me to clarify: the official version of Actor Framework is the version that ships with LabVIEW. The first official release was in 2012. There were improvements that shipped with 2014, and we're looking at some changes for future versions, but we continue to maintain backward compatibility.
Since AF started as a community project, we have continued to solicit feedback from the community on how to move forward. The various forks released here have been a means of testing some of those ideas. The forks were a useful concept but not sustainable, so we have moved to the community source model, which is a single development path. Our community source projects still have feature owners within NI who are responsible for selecting or rejecting changes; those that we consider sufficiently useful and mature will become part of a future release.
One thing we have learned from working on AF is that framework design is a multi-brain problem, and one that benefits tremendously from extensive outside feedback (more brains, and more importantly, more perspectives).
If you need stability, then please stick to the official releases that ship with LabVIEW. Those are the versions that have gone through our beta process, and are best known within our support organizations.
If you need the latest features, or want to contribute, or just want to see where we are headed, then look to the community source projects.
Yes you are right - I was confused. Somewhere in the READ THIS FIRST I had wandered into these branches which culminated in your revelation of moving to Github. I do not disagree with community source code, and I acknowledged that before I took exception above, based on the fact that developers pay NI to reduce their time to market by investing in Labview (regardless of specific license cost). Thanks for clarifying.
I would say that from the READ THIS FIRST, all I see is a bunch of stuff that talks about 2011 and 2012, and there's not much to say "here we are in 2015, and here's where we're going. These are known weaknesses and we hope to address them by release X". I'm not saying it's not there, but it's not in my face, something which other noobs must certainly experience.
Finally, to save Casey from further hijack, would you be able to point me to instructions on how to host a center for discussion, where I can have a conversation that may touch many topics? I almost feel that what Casey needs is a subforum, where all cRIO AF issues can be posted to get all that good tag traceability stuff while allowing conversations to occur naturally. Some of my stuff here was cRIO based, and you can't always address cRIO issues without acknowledging the AF issue in general, or a labview class issue in general, or...
Rik_aspinall: You know, I honestly hadn't noticed how dated the top of the READ THIS FIRST page had gotten. I have been adding small notes in the bottom sections, but hadn't updated the top. It looks like it needs a fairly substantial rewrite soon. I'll put it in my backlog of tasks and try to get to it shortly. Thanks for flagging that.
I'm currently using the Nested Network Endpoint with TCP, and I was wondering how you implemented this for multiple clients or connections. I was hoping to be able to launch and differentiate the NEAs without resorting to changing the port; any thoughts?
Thanks and see you soon!