Bob Edwards G4BBY

Yes, Jeff Kodosky's proposal was still an 'add-on' supported by scripting with whatever limitations that brings. However it's heartening that one of the founders is thinking about the issue - I bet it's not the only idea he's had on the subject either. The event structure radically dropped the complexity level of LabView programs. Added features to event structure for Actor programming might be part of the solution. I guess it all hinges on where NI is going to take LabView, post-NXG. Adding OOP was NI's last 'big deal' for LabView and that was sometime back. I read (via the critics on this forum) that NI could still do with something reasonably big to revive relevancy to the programming community. Might this be it? The 3rd party Actor system designers (and the 'Actor Framework' people within NI) have done a fantastic job exploring what works and what doesn't - why don't they and NI get their heads together to agree on a common, simple syntax for built-in Actor programming? There's a wealth of experience out there in Actor application and we would be more likely to end up with something usable, if their views were heard or they were involved. A built-in Actor syntax should have, as it's number one goal, the promotion of a new breed of 'Actor library' circulating between users as a higher level of IP exchange with a common api. At the moment 'Actor Framework' authors can't exchange Actors with Delacor authors who can't exchange with 'Messenger Library' authors etc. The upshot is that the Actor community and IP exchange is fragmented, like we saw before built-in OOP came along. In my many years of studying Labview from writings on the internet, a fair number of text books and so on, it has always struck me that the language did not scale well beyond the confines of the computer monitor - a complex state machine at best. You just don't come across that many non-Actor articles on writing modular applications without 'ugly' coupling. The time feels ripe to change that. Actor fundamentals are simple, adding built-in Actors fills a need to facilitate an elegant, higher level modularity; it's time that was reflected in the 'wires'. <Steps down of soapbox>

I remember when labview's internal OOP replaced the complicated 3rd party OOP frameworks. Similarly, the 3rd party Actor systems (and NI's own 'Actor Framework' are verbose for the same reason as those early OOP systems - they are written in G and so a lot of the 'internal works' are exposed and need care and attention. (I have nothing but admiration for these systems of course). There are many different Actor systems now available - in part that must be because people are dissatisfied and are casting around for a 'better' solution. How to design, edit and maintain a hierarchy of state machines with the minimum of effort. With that quest in mind, has anyone considered the 'Actor' object provided by the messaging libraries CZMQ or NetMQ? Could these objects be usefully called from Labview to simplify Actor programming in G or are they only useful from within a C or C# programming environment? I've studied what zeromq has to offer and written a decent labview application that used several of the messaging types - if the zeromq Actor was useful as well that would be a powerful combination. I ask the question because I haven't fathomed so far the rather scanty documentation of the zeromq Actor. I'm not a text-based programmer. Cheers, Bob - retired EMC engineer now doodling ham radio projects in labview

Will the 2020 community edition still be issued in May please? This locked-down ex-engineer would be very grateful if it was.

Basic question: I've written actor templates with config and plugin features. Using those to write soundcard in and out actors. They have helper loops that use 'register' and 'notify' to transmit the waveforms around. A standard labview notifier is set by the messaging loop to shut down the helper loop. How do you shut down your helper loops - is there a 'messenger library' feature you use? When using queues I used to close the queue in the main loop and detect queue errors in the helper loops.

I've got it - storing each clone by name suits a fixed architecture, storing a JSON array suits the case where the number of clones is determined at run time.

Say I've created a number of clones of a reentrant actor and each has a unique setup that needs to be preserved. What's the niftiest way of identifying one clone from another when saving state using JSON? Cheers, Bob