Aristos Queue

I have implemented it is a two-element queue instead and had two copies of the same data in the queue.

Then this wasn't a singleton. By definition, a singleton class allows only one copy of the data to exist anywhere in memory ever. It should be impossible to create a second copy. If you can create a second copy, it's not a Singleton. That's just a reference to an object.

Or am I missing something?

Poly VI A.vi contains instances B.vi and C.vi, each of which has a unique conpane. There's no reason a descendant class couldn't have an override for B.vi or C.vi or both. It wouldn't allow the child VI to add D.vi to the poly VI, but it would let the child customize the behavior of the conpanes as given.

The buffer is still allocated. That doesn't mean anything is copied to it when the VI runs. That's true up through LV 2009. In later versions, ... oh... nevermind.

You want to post your question here:

http://decibel.ni.com/content/groups/enhanced-icon-editor-2009

For the record, the icon directly in the .lvclass file is just the icon of the library itself. The icon of the .ctl file is embedded in the private data control, which is itself an entire .ctl file embedded inside the .lvclass file. Unfortunately, you can't just copy/paste that text directly into another file -- its a binary file that has been escaped in order to be saved inside the .lvclass file. Assuming you can somehow extract that from the .lvclass file, there are ways of extracting the icon of a VI without loading it into memory (I forget the name of the VI Server method that does this, but it does exist). I would *not* try loading the .ctl into memory directly -- control VIs that are tagged as private data controls make a lot of assumptions about the conditions under which they are loaded (notably that their owning library exists and is already in memory) and you'll almost certainly crash before the load finishes. But reading the icon data out of the file should work. Again -- the easiest way would be to just load the class into memory and then use the Icon Editor VIs to edit the icon.

Can you make it reentrant? If you can, I believe this will allow the inlining.

A non-reentrant VI will block inlining if it contains any asynchronous nodes (like a Dequeue Element). Why? Because non-reentrant subVIs are mutex locks (ie two callers to the same subVI cannot execute simultaneously), inlining a non-reentrant subVI that includes asynchronous nodes would create timing changes to the behavior of the nodes, and so inlining is barred. I *think* that if the subVI is made reentrant then we ignore that check because inlining the reentrant subVI doesn't create any timing changes since two callers already could've executed in parallel (that being the point of reentrancy).

(For the record, I have only observed others using this token, never used it myself, so I'm definitely not speaking with any certainty in this.)

If polymorphic VIs are "compile time polymorphism" and LVOOP Dynamic Dispatch VIs are "runtime polymorphic"... is there any reason (besides the fact that LabVIEW doesnt let me) combine the two?

No, no other reason. It is something that LV R&D would have to implement, and it has never percolated to the top of the priority list.

I guess my work around is to create a bunch of static VIs calling dynamic dispatch equivalents (a la DVR classes) but, as with DVR classes this seems a little bit hacky and a bunch more work than it should be.

Yep. I agree that it's more work, but it's not a hack, insofar as we said, "Well, there's a reasonably obvious way to make this work. Given that, let's deprioritize the ease-of-use feature for having poly VIs contain dynamic dispatch VIs directly."

It still isn't on the roadmap for any of the near term releases. It is not on the Idea Exchange... you should go post it there and see if it drums up enough support to get attention.

Here's the original attachment:

Map_Class.zip

It was deleted when LAVA got wiped out in early 2009.

but I was wondering if anyone has tackled this design pattern yet

Yep.

The tag is nothing special. It's the same tag used by all VIs for the Icon Editor. Go use the VIs there to manipulate it.

. But I was wondering, does shared reentrancy create a "pool" of instances where it only opens up as many as are needed for parallel execution at one point in time or does an instance get allocated every time the VI is executed.

The pool will grow if the need for more parallelism arises. In other words, if a thread requests an instance and all are in use, another will be allocated. It's a standard "grow by double until threshold then grow by threshold increments" algorithm -- so you start with one instance in the pool. The first time the pool grows, it doubles to 2, then 4, then 8 and so on until some threshold... in this case I think it is 32, but I'm honestly not sure... at which point each request increases the pool by the threshold amount, which, again, I think is 32.

You were the one who said it was a primitive

Ok... I guess it could've been one of *my* LabVIEW classes. :-)

Which means that add primitive also supports ...(gasp)... operator overloading?

Or that someone used the Icon Editor and drew a triangle with a plus sign on it. Occam's Razor, man, Occam's Razor.

There's an idea I'd really like to see implemented in LV but I haven't got traction for it, so I need kudos from the community if it is ever going to happen. I posted it to the LV Idea Exchange here. Please review the idea and kudos it if you think its worth implementing!

I wonder this too! I guess it's a class...

I like to believe that NI was prescient enough 25 years ago to know that classes would be so fundamental to the language that they would put classes on the logo in expectation of their arrival. On the other hand, the logo includes the sequence structure, which casts doubt on the prescience idea. :-)

Is it an integer? There's no coercion dot at the add function.

Clearly the blue wire is also an object, and the add primitive supports automatic downcasting.

Although the question that nobody seems to have answered yet is what you do when you want both loops to run in parallel, but one of them to deterministically start first.

The standard producer/consumer pattern does this. The producer loop has an Enqueue prim somewhere inside it. The consumer loop starts with a Dequeue prim. Until the producer hits that first Enqueue prim, the consumer loop sits waiting. To see this, go to "File >> New ..." and in the dialog that appears, go to Patterns (or Frameworks in some versions of LabVIEW) and open the Producer/Consumer template.

I am working on a refurbished IC test system. It was state of the art in 1998. The controller workstation uses Solaris 2.5. It comes with something called TestVIEW, which seems to be a wrapper for a C driver library using LabVIEW 5.1. Is there a more modern version of LabVIEW that can be used with Solaris 2.5? Do you know where I might find a license for such a version?

The last version of LabVIEW released for Solaris was LV 6.0 *I think*. Contact your local NI sales rep and he/she can probably (with a bit of searching) find an installer disk. I don't know cost for older versions -- that's something to ask your sales rep.

I've begun a RCF plugin that extracts the contents of a snippet made with the Code Capture Tool in LabVIEW 8.6, and it uses some SuperSecret stuff. Is it Ok if I leave the Block Diagram unlocked?

NI would prefer if you password protect those diagrams. The mystic ini token may not be the most secure gate latch ever, but it does generally keep the kids out of the briar patch. Scripting is being cleaned up for the next release, and at that point most of the operations that the token hides will be exposed but in ways that are closer to safe. Until then, please latch the gate behind you.

An easy way to enforce ordering of parallel loops is to use timed loops instead. Wiring a different value to the offset input of each loop will cause them to start at different times.

This is NOT true on desktop platforms (Windows, Mac, Linux). Only real-time operating systems maintain the synchronicity of timed loops. On the other platforms, LV will try, but inevitably there will be slippage since there's no real-time guarantees from the OS. True concurrency can be achieved with the Synchronization primitives -- queues, notifiers, rendezvous and semaphores.

I've always been under the impression stacked sequence structures are considered bad style but flat sequence structures are okay, even when using multiple frames. Did I miss the announcement?

Sequence structures are to LabVIEW what sentence fragments are to English. Both are so problematic that we have to teach newbies "never use these" and then later we can say, "ok, now you can use them because you now understand how they work with relation to the rest of the grammer." Sequence structures have value, but new users to LV tend to over use them gratuitously and thus end up killing the performance of their code. Similar with sentence fragments. ;-)

If I drop two independent while loops into a VI, independent in the sense that neither while loop requires any information from the other to proceed to some conclusion, in what order will they execute? How can I control this order?

As multiple folks have said, in the absence of any data dependency between the loops, the loops will run in parallel as threads become available. One thread may race ahead of the other, one may even complete before the other gets started, and it will be different every time you run the VI. In general, this is highly desirable as it maximizes the use of your available CPUs, thus the answer to your "How can I control this order?" question should be, "Are you sure you want to?" If and only if the answer is "yes" should you try to enforce a particular ordering. Adding a dependency order just to do so only reduces the efficiency of your program and looses one of the biggest advantages of dataflow programming.

Initially we did it because we followed the same rules as VI Server, which does show coercion dots for the hierarchy of control refnums (wire a Knob refnum wire to a Control Refnum terminal and you'll get a coercion dot). Later we figured out that it helped you recognize whether or not automatic downcasting was operating or not. But I'm still in the camp that wishes we had different colors of coercion dots for different cases.

Ok. I really want to know: Why do you need Singleton? What are you using it for? I implemented the example that ships with LabVIEW because lots of people wanted to see some implementation for it. But I honestly am not sure why you want it in LabVIEW. In C++ it makes perfect sense, but not so much in LabVIEW. At least, that's my opinion. Now, you can ask why I would think a construct would be useful in one language and useless in another... I have an answer, but I'd rather not share it at the moment. First I'd like to know what you're doing with these Singleton classes. I have yet to be convinced that it is a useful pattern in LabVIEW.

LVOOP FAQ (includes links to other resources at the end):

http://zone.ni.com/devzone/cda/tut/p/id/3573

Excellent 1 hour video presentation on getting started with LVOOP:

I view it as child needs to be able to lock parent, but parent shouldn't lock child.

If you're facing this situation, I think the correct answer is to eliminate the inheritance relationship in favor of a container class that contains both "parent" and "child" as separate internal objects. Then you are back to only having mutex locking on an entire object.

jgcode: Does your customized version handle the new options in LV 2009 to not include the error terminals and case structure?