ShaunR

That's progress No one uses Mac anyway On a more serious note: I'm not sure what you mean its not recognised.

I'm saying that dataflow, in a dataflow paradigm, has a specific operational meaning and is a defined concept. It is not is just an analogy to a river flowing to aid comprehension for data being produced and consumed. I'm just picking you up on watering down (no pun intended ) the definition by conveniently ignoring state. Do "Channel Wires", "Asynchronous Wires", "Pipes", "Conduits", "Meanders", "Dunaway Dynamic Data Doorways" or whatever you want to call them implicitly impart execution state? The answer is the answer to whether they are part of a dataflow paradigm or not.

One of my long standing annoyances was not having a completely generic re-use solution for encapsulating queues and events. As much as AQ thinks my vanishing wires is a no-no, it is a necessity to me to create reusable modular code that has the benefit of being clean and easy to read. Taking the backbone of my message systems as an example, the Queue.vi, I was able to do this somewhat but had to make a decision to forgo data typing. Since my messaging is string based, I could encapsulate but had to wire a string to the input of the queue and fix the datatype - I had to wire something. This meant for rare occasions when I did not want a string, waveforms, for example, I had to type cast or flatten. (I actually wired it to the name wire, but at that time it was just so a wire didn't cross another. OCD? ) This was ugly, but acceptable for the 10% of use cases. It would have been possible to create a polymorphic VI which could work for simple types (bools, integers et. al.) but clusters, a more probable requirement, would be back to flattening. A poly would also have bloated the code base by a huge factor meaning that a simple, single VI of 16kB would have taken up an order of magnitude more space and compile time. I wasn't OK with that either. A Xnode would also have sufficed, but Xnodes where not around in those days, are an unsupported feature even now and just too damned hard - if we ignore how flakey they can be. It's hard to justify any of the other complex technologies when all use cases are covered by a single small VI with some effort by the developer just for type casting. The thing that was missing was VIM style of polymorphism that would transfer the datatype to the underlying queue primitive, transparently, without defining all permutations and combinations up front and without having a supporting entourage of VIs just to turn tricks. That would make it simpler to use. Simpler to understand and maintain modularity. It would be more elegant! And now we know about VIMs. Woohoo! And I get all that (or should I say all that disappears) just by moving a wire and adding the letter m to the VI name , No code bloat. Still 16kB. Still a single VI. Whats not to like? The one down side is that it can now produce a run-time conversion error. In the old days that would have been a problem as there were virtually no primitives that could generate run-time errors so that would have ruled out this usage. With LVPOOP, though, run-time errors have become acceptable so it is a small price to pay. This is why I'm so excited about the VIM. Finally my Queue VI doesn't need the flattening and unflattening verbosity and can relieve the user of that burden making the code even more compact and cleaner. My OCD has been satisfied I was never able to find a generic solution to events, however. They were always application specific due to the registration refnum.. Now, though, I think VIMs will enable me to do to events, what I did with queues and that makes me even more excited.

Sorry. I'm not going to let you get away with that conflation. Dataflow has a specific architectural meaning from an operational stand-point. I won't let you conflate an abstract, analogous idea of data moving with an operational paradigm through tortured wording. It's like saying by-value is the same as by-reference because they both enable passing data by-something, right?

You sort of can. If you wire a boolean to numeric primitive inside the VIM then try to wire a string, for example. . The VI will be broken with the error: "You have connected a polymorphic terminal that cannot accept this data type" So it not only adapts to type and does some intelligent type conversions, you can force terminal types with with a bit of verbosity in function use. Sort of agree except about where they sit. Xnodes and VIMs aren't competing, but VIMs are closer to polymorphic VIs, IMO, without the code replication overhead of diagrams per instance that I always point out.. If you don't need to adapt to type for different companes, then these are the tool of choice to give adapt to type with a single diagram, single point of maintenance and no VI bloat or replication.

Lol. That's hoping a bit (from me ;P ) , If you'd put the wire in the hierarchy window, I'd be all over it So that's an admission that its a solution looking for a problem as I surmised?

What I actually said was breaking dataflow is a consequence, not a weakness. The issue I have with this is that wires have always been the method to be able to sequence execution. Its how data flows in LabVIEW and is very intuitive as an analogy! We have always been taught that we should use them instead of sequence structures and wire error clusters to make execution order unambiguous and repeatable. Well. This type of wire doesn't do any of that and if you think it does you are in a whole world of hurt. I can guarantee that people will expect it to though, especially when single stepping or highlight execution debugging etc. I also said. I'm willing to be convinced. When we do break dataflow it would be helpful to know where data pops out but why not do something with existing asynchronous methods like events? So. Show me the killer app. Lets see how easy it makes understanding the Actor Framework. Lets upgrade some existing software to use this technology so we can compare the benefits directly. Is it just a fancy global variable with a confusing wire type or is it like buffered TCPIP endpoints?

Holy crap in a cabbage!......Have 500 likes (compressed into one) To celebrate, you can all have data aware controls in the next release of the SQLite API for LabVIEW because I couldn't be bothered with xnodes.but this should work.

I chose 1 & 3. I thought that covered the most basic requirements with an offload of decision in strategy to the person who knows more. There is no need to flush a queue if you destroy it and my little queue wrapper means you can just crowbar queues and they get reconstituted if it really was being used. (effectively just clearing it) You will find the lossy/normal and limit choice in the Dispatcher and the queue size transmitted to the Dispatcher so the status could be monitored for each producer to assist the strategy decision (#1) . I never got around to a heartbeat or pinging and fail-over/retrying which was the next on my list (#3) before I got sidetracked by Websockets.. I wouldn't be too concerned about complexity of the API as such. As long as it is a simple interface. Things like heartbeats, pings, bandwidth management and fail-over etc can all be switchable features and completely transparent. Many of those don't make sense if your not traversing the network boundary but your design isn't limited to local processes Can't wait to see where you go with this.

OK. So what if a subscriber doesn't unregister but fails to service its queue? Both our systems are reliant on the registration being valid , up to date and the subscriber consuming otherwise messages start piling up. In mine, I have the TCPIP refnum that acts as a notifier for remote subscribers disappearing but locally I have the same problem as I bypass the TCPIP and place directly on subscribers queues like you do. What is your strategy here?

This is something the hierarchy diagram (HD) has needed for a while. The HD could be so much more useful for navigating the architecture - an interface like the Firefox 3D view. It would mean I wouldn't have to visualise the bipyramidal architectures in my head (the flat diamond is all you can see) and give real insight into multi-level state machines. Double click and open a VI diagram.....it'd be great.

I like this idea. Encryption is demonstrably faster on 64 bit machines than 32. SQLite performance is very disk dependent. There was a benchmark from NI to demonstrate VI call overhead to compare inline, re-entrant and normal which is extremely insightful (not sure where I saw it). There;s the disk performance comparison tests from NI used for benchmarking our SSDs. You've already mentioned Fourier. Sort algorithms are good for assessing computation capability. There used to be an issue with 64 bit labview when allocating memory so something to assess array performance could be used as a proxy for memory efficiency. During investigating the Ring buffer we bench-marked queues and while loops and stuff. Has to be lots around here for you to pull out and formalise into a test suite.

OK. So let me clarify some points here. There is a "distributor" which is launched dynamically and acts as the dealer to deal out the messages to a number of "registered" subscribers to that producer. So when you "create" you launch a distributor. The distributor is a permanent consumer for the producer (i.e. it prevents queue fill-up when no subscribers). It also is the "dealer" to multiply messages by copying a message to each subscriber's incoming queue, if and when they appear. So you have a Distributor per publisher that deals messages on a per publisher basis to subscribers. If I'm close in understanding; it might be worth looking at Dispatcher as it sounds like this is an almost identical philosophy where I call the "distributor" a "handler"

Leaving aside "what a wire means" in LabVIEW for now. There are two points I would raise here. If data flow isn't followed. That's not a weakness. That is a consequence of breaking dataflow in a dataflow language.LabVIEW is inherently concurrent and has implicit sequencing but go ahead and use your GO4 templated framework - just don;t come crying to me about needing extra language semantics to get synchronization back again for an architecture where you've specifically chosen to remove what the language gave you. I spend a lot of my time writing little bits of code to remove wires. I remove them for three reasons. 1) Modularity-I can just plonk the VI on any number of diagrams and it will just work (get rid of init, do something, deinit). 2) Break dataflow - Encapsulate events, for example, into an API where each call is atomic and refnum free. 3) Diagram readability-More of a side effect. I feel the example they show is rather contrived. Most of the time I would use such a system in different VIs because of 1&2 Generally I want to share data between processes, not individual while loops. Then the whole idea showing where the data comes from with a wire becomes moot and it is no different to what I usually use.....except more complex to create,, it seems. That said. I haven't played fully yet. So I am open to being convinced with a killer application of them.

Woah, there pardner. Apart from giving you many ways to confuse and shoot yourself and others in the foot. What problem do these "asynchronous wires" solve, exactly? At first glance, it looks to me like a solution looking for a problem.

FTFY

This is desirable in my apps too. I created a queue wrapper (umpteen years ago) that ensures there is always exactly one of any queue and is created when any queue function is called thereby removing the Init, Do Something. Destroy overhead and memory runaway from creating refs. Destroying the queue merely has the effect of clearing the queue which is reconstituted on the next call, Queue.vi

I gave you closure; move on. The List is here by the way.

Available in the LabVIEW Real-Time module: No (Hover your mouse of the name property)

Attached is a tentative alpha for 2.0.0. As much as I hate the alpha and beta philosophy, I only have one test device so I am not comfortable in fully releasing as it may be tuned to that one device. I usually pull products I cannot adequately test; the choice was an alpha release or remove it completely and put it back in my "cool stuff for me" toolbox. But I said I would do something so lets see if we can get this usable for most people with a view to a release proper. Oh. And I changed the licence to a much more amenable BSD3 .OPP 2.0.0-ALPHA.zip Of course, if you want to send me lots and lots of bluetooth enabled phones, I'll happily support them

I can see it fine.

Here are the upgrade notes that detail the new features. I don;t see anything in there about loading block diagrams in different versions, though.

Sweet. Check back next week for version 2.0.0.

OK. Figured it out. The spec has changed quite a lot over the 5 or so years since it was written-damned progress I've got it working now with some non trivial changes i.e. it works but is a mess and it needs refactoring. So my question is what is your timeline for this? Do you need it by tomorrow, by the weekend? By next month? By next year?

Set the prepend array size to false on the Binary Write