drjdpowell

A big part of the payoff of a good framework is making large complex applications simpler. But it's hard to see this when you're on the wrong side of the learning curve.

On 10/1/2019 at 6:41 AM, Michael Aivaliotis said:

I like to read opinions from people who have tried the various frameworks and can compare based on real implementations.

On 10/1/2019 at 8:11 AM, LogMAN said:

Of course we shouldn't be afraid to learn about new frameworks, no matter how complex or simple they may appear.

Unfortunately, there is a significant learning curve for all frameworks, so it is hard to compare them.  Here though is a GDevCon1 talk by Richard Thomas, where he discusses frameworks: 

Frameworks: An Executive Summary

Ah, by-ref objects, GOOP, G#, and the like. That should have been a poll option.

7 hours ago, G-CODE said:

I'm so habituated to creating typedefs, events, and registrations for every message. Maybe there's a better way

I remember a conversation, which I can't find now, where AQ mentioned that most messages will involve multiple bits of information, but I was surprised because I think it's natural for messages to usually only having a single piece of info.  Often just a simple number, path, string. Even when the message contains a typedef cluster (or class) that typedef usually exists for reasons beyond the message.  So I might have a "Data Set" object that passes through multiple actors for different types of processing, using a generic message rather than a number of type-specific messages.

BTW, I was partly prompted to do this poll after seeing there is yet-another-framework on the Tools Network: WORKERS by Scarfe Controls. 

8 hours ago, G-CODE said:

I'm going to have to know the type at some point in time whether it be at edit time or at run time. So at what point in time would I rather know it?

Your right, the question of strict versus weak typing is an important question and involves trade offs, and different frameworks make different choices.  I, in using Messenger Library, seem to spend almost no time bothered by problems caused run-time type mismatches, so I am not much impressed by the edit-time type safety if it comes with the negative trade offs of requiring large scripting tools to work productively.  Why that is might be a long discussion about other features of how I code, and what information is put in a message.  I've tried to point out before that code frameworks support mental frameworks, sets of guidelines that work together, and it can be difficult to compare code frameworks because it is hard to full grasp the full set of its mental guidelines.  You found that yourself when AQ's strong criticism of State-Machine-Objects didn't really move you, because you just have to "impose some rules when developing with this framework".

5 hours ago, G-CODE said:

That doesn't necessarily have to be true if you're willing to dig in to specifics of existing frameworks even if you haven't spent a lot of time developing with them. For example, Antoine points out that DQMH has good scripting tools. I agree with him, even though I haven't developed a large project with it. DQMH seems like it makes it very easy to create new messages with custom data types.

Ahh, your illustrating my point.  DQMH is similar to SMO in having custom-type "plumbing", with new messages requiring changes in multiple places.  AF also has its own busywork of multiple things to do for each message.  Now, all this work is highly repetitive and thus scriptable.  So you can value the strength of DQMH's scripting tools, because similar tools would be a help for SMO.

But from the point of view of Messenger Library, which uses more generic messages, scripting is just a way of reducing one of the weak points of custom data-type messages: all the extra work to carry the new custom types through the communication code.  Scripting Tools aren't a strength, they're the minimization of a disadvantage that is shared by DQMH, SMO and AF.  

39 minutes ago, Antoine Chalons said:

G#

Didn't think to include G#, GOOP and similar, as I've never used them.

14 hours ago, G-CODE said:

SMO. I'm guessing Francois will say the same thing since he wrote a large part of it.

Several months ago I was comparing three common community frameworks and I had Francois chime in. I attached a screenshot of what we put together with our rankings obscured. If he's ok with me showing it, I'd love to reveal our rough rankings for the categories shown.

Apologies to JKI for not explicitly including State-Machine-Objects in the poll.  Though I think what you compared was two common community frameworks, plus the framework you use, and largely developed, regardless of how common it is.  Difficult to make such comparisons, as the stuff-you-know-well usually trumps stuff-you've-read-about.  Even getting unbiased comparison categories is hard; I'd probably have "messaging pattern support" and "network communication", two things Messenger Library does well, yet not "Teststand Integration", which I've never tried.

I was interested in the relative numbers of LAVA developers using different "frameworks" or types of architecture.  Apologies, my list of poll options shows my biases towards a message-passing, actor-ish, style of architecture.

Sorry, I seem to have forgotten to allow more than one option, so you'll have to pick the the best answer and explain more in a post. 

I pick "Messenger Library", though as I developed that, my honest answer is that I use my own internal framework.

Oops, two things called "name".  The "Names" output is an array of item names.  Your item name is, confusingly, "name".  "Cartographie" is one of your date values.  It is a string, and I in my example provided a string as the data type.  But you provided as data type an empty/void Variant, which will fail.  Use a string like in my example.

Your names are strings, not variants.

4 hours ago, Thomas Pedot said:

How would you do that easily ?

You certainly can do this with LAVA JSON, but I would suggest you use the JSONtext library instead, if possible:

Your right, there is a reference leak here.  That Queue is a reference created in the actor's calling code, and is used to trigger the "Autoshutdown" message when the caller stops, thus invalidating the Queue.  There is an async component called the "ReferenceMonitor" which watches that Queue and sends the Autoshutdown message then closes.   ReferenceMonitor also polls the actor's address, so it can shut itself down if the actor dies.  However, I forgot to destroy the Queue in that case.   Here is an image where I have added the needed Close operation:

Thank for spotting this,

-- James

Yes, these references are intended to only be closed when the actor that created them stops running.  The term "reference leak" is used by the trace toolkit to indicate any reference cleaned up by LabVIEW when a vi goes idle, regardless of whether it is an actual leak.

A JSONtext example, ssumming all dictonary items are the same type:

Alternately, keep items in JSON format so they can be treated differently at a later step:

37 minutes ago, nickster said:

As for dealing with the JSON string itself, yes, I can go there, but code reuse will go in the toilet.

Don't quite understand that. JSON is a standard data format, widely reusable. Your weird Variant/Cluster/Dictionary thingies are very non-standard.

33 minutes ago, nickster said:

But when I sit down to wire this up, I realize I'm not understanding the instructions. Could you show an example diagram?

This idea, though it is a request for the reverse operation, illustrates how one can convert a cluster (in a variant) into an array-of-variants that contain the individual cluster elements.   This did not exist when the OpenG Variant Tools were made, and OpenG is based on the (much slower) operation of manipulating flattened data.

If you can access the original JSON string, then you have more options to convert it, such as with the in-built JSON primatives or JSONtext, both of which should be quicker and use less memory.  The code would be simpler too.

One suggestion is to use Variant-to-Data to convert your Cluster-in-a-Variant to an Array of Variants containing the Cluster elements.  Then use the Data type palette to get element names.  This will be much faster and less memory intensive than using OpenG Vis.

The problem is, if there are two dialogue actors, which should be on top.  Only one dialog can be interacted with, but that one isn't necessarily on top.

I do that.  But the problems I have are reported by Users of the EXEs

Does anyone have a solution to the problem of ordering of floating windows, where for example a modal dialog box is behind another floating window, and thus can never be dismissed?  Or a floating window opens a file-selection dialog, and it opens behind the first window.  Is there a way to determine which modal window has control (and must be dismissed first) and then force that to the front?

The programming term you should look into is Futures and Promises.  It is about handling results not yet received (such as defining their order, as you wish to do).  Single-element Queues, as TomOrr0W suggests, is what I usually use.

You can easily customise a standard boolean by swapping out the on/off elements for whatever decoration you want.  Then you can colour on and off states differently.  Alternately you can use PNG images (already coloured) for the on/off states.