Aristos Queue

Shut down your computer and head home for the day because the world is ending... I agree with ShaunR on this one. Collect the data as you read, and when you have read all the pieces to know exactly your final type of object, then and only then instantiate your object. You'll probably end up with some sort of "variant with named attributes hanging off of it" to collect as you read and then you'll evaluate the collected attributes and make it into an object.

I recommend the tree data structure Damien implemented to underlie his priority queue:

http://forums.ni.com/t5/LabVIEW/Dr-Damien-s-Development-Priority-Queue/td-p/837194

You, mi'lady, are asking for a feature we like to call "Zoom." And, no, there is no way to make LabVIEW itself bigger. Or smaller, for that matter. Your operating system might supply such features (use ctrl+scroll wheel on a Mac and you get the OS and all hosted apps zoomed in... quite nice). The feature to have LV able to zoom its diagrams/panels/etc is one that we are indeed working on, but when you have 20+ years of pixel manipulation code, it takes a monumental refactoring effort, and we are still a few years away from having that graphics layer reworked.

I had two sets at the BBQ for folks to play with, but I did not give them away. :-)

When LV builds just the string array, you get the copy of the array stored by the ring control itself -- no copy is made unless/until you modify the array downstream. Since you are only searching the array, no copy gets made, so it seems fast. When you ask for the array of strings and values, we have to build you a whole new data structure including copying each individual string so that the new data structure is independent of the one in the ring (that's how dataflow works; it is not a bug or something for LV to fix someday). So you see a massive penalty hit.

You can maintain this data structure yourself, as various people have pointed out, in diagram local storage, like a shift register on your event loop (I wouldn't use an LV2-style global unless you really need this information elsewhere in your program and not just on the local diagram). Then, yes, when you make a change to one data structure, you make the same change to the other data structure.

This CAR is noted as already fixed in LV 2012.

Antoine: That JKI mass compile tool... I never saw it before. It is described as being for LV 8.0. There were a lot of issues in LV 8.0. Is that tool still relevant at LV 2012? Has the built-in mass compile come up to speed with the JKI tool? Or is there still a difference?

No, it is index and the default is "last element" so I would want to see "index (last element)".

If we named it "index (last element)", that would be a lie. It is only by being unwired that you get the last element. There is no value you can pass in that will get you the last element. And it is named "index 0" in the context help because there are N indicies depending upon the dimensionality of the array, and the CH is trying to depict what happens for any dimensionality of array, but when you wire a 1D array, the terminal -- as it is on the diagram (see tip strip) -- is just "index" because there is no additional terminal that we need to differentiate.

This seems like a good CAR to file. Filed as CAR #377978.

Interesting conjecture. I'll keep it in mind if I ever have to dig into one of those systems.

Weird.

The constant size thing can't be the issue... after all, the waveform itself contains a variable sized array for the numbers. The array of variants shouldn't have any impact.

Can't explain it, but useful to know.

...with attributes.

The attributes are just another field of the cluster, it just gets exposed on the block diagram differently. Still just a cluster.

I'm assuming since you are using clusters you are not using RT FIFO's. That said, if you are using RT FIFOs, I believe waveform attributes are lost when using them so be aware of this.

Citation needed. I'm not saying you're wrong, but there's nothing in the design of the RTFIFOs (they share a lot with the Queues) that would necessitate this, so I'd be surprised. It may be something in the transmission requirements that I'm not aware of. Please test and confirm this.

Except bugs in the Close function code ;-)

Nope. Those don't return errors. :-)

> What other conditions could cause a close function to fail

> besides having an invalid or previously closed input reference?

That's the only one.

Waveforms are clusters.

Well. Tell us which licence IS acceptable then. Alternatively, NI could create a licence (LabVIEW Open Source Licence?) that doesn't require giving up IP then everyone will be happy.

That's exactly the problem. I do not know of one and I have been trying to research it, but I am not a lawyer, so it is slow going. My original post was because I know of only one existing mechanism that works under US and international laws, for various reasons. Most long-term solutions seem to require the transfer of IP, the way the Creative Commons OReiley group does by buying it from you for a dollar and then licensing it back to you. It was not meant to rule out other possibilities, but upload to ni.com (or some variation that requires IP transfer) is the only solution I have thus far found.

Need a source of true random numbers? Here's an excellent source, assuming you have an Internet connection available to your application. What's the National Instruments connection? The system was developed with NI PXI systems and LabVIEW.

https://decibel.ni.com/content/groups/sweet-apps/blog/2012/10/22/never-pick-your-own-lottery-numbers-again

The online generator mentioned by the article is here: http://qrng.anu.edu.au/

This sort of begs to be packaged into a single "Get Real Random Number From Internet.vi". Very handy utility for lots of applications!

As the NI run-time (for executables) or the development IDE must be distributed to use anything; from NI, that aspect is a bit moot. If it wasn't the case, and there weren't other examples that require attribution already shipped; then I would probably have agreed with you by now.

There's no VI that falls into that category. There's no DLL that isn't core to LV itself that falls into that category. In short, everything that currently ships with LV that falls in that category is installed by LV and thus requires no secondary notation from a user. A VI in vi.lib is not part of the runtime engine and so would require separate acknowledgement by any EXE that used that VI.

For goodness sake, Shaun, have you listened at all to my explanation for why the attribution requirement is a problem? It has *nothing* to do with NI and everything to do with the next user downstream. It's an impossible tracking problem. If we start shipping a vi.lib with tons of different BSD contributors in it such that a user has to keep track of which parts of vi.lib they've used just so they can distribute their app, we're killing usability. There's no way I'm dragging all LV users into this morass of licensing. When I voluntarily download a library to use, I'm consciously aware of the need to handle the licensing of that library. But in this case, we're talking about a library of thousands of VIs and having to sort through it to figure out which ones have special licensing rules is unacceptable.

It isn't about giving credit where credit is due. Credit is given when someone says, "Thank you" on the forums, when NI notes a user's contribution in the Upgrade Notes, or other similar acknowledgements. Burdening every downstream user with having to maintain a README.TXT file does nothing to stroke your ego because you'll probably never see it. What it does do is put another impediment in the software engineering process in LabVIEW. It's a non-starter for vi.lib to be encumbered that way, not because of NI's need to control a damn thing but because all of you -- yes, you included, Shaun -- need to be able to use vi.lib without checking your code for licensing requirements just because you happened to use a palette you hadn't used before. I am trying to find a policy that is actually beneficial to the community, not burdensome. And that means finding a way to put the IP into LabVIEW in a way that does not require any acknowledgement of the original author.

I'm fully supportive of some solution that acknowledges the brilliance of authors as long as it does not require lots of bookkeeping to do it.

How do you make sure this will never run more than once a minute?

The usual solution is to have a sequence counter in your application that increments while the app is running and the sequence number is appended to the end of the file name so that names are unique within a minute/second/whatever. If you need something that is unique globally (i.e. multiple machines generating files simultaneously that may then be shared with each other), adding a random number of sufficient length to the end is the generally accepted solution, provided you use something for your random number seed *other* than the clock. :-)

Oh hellfire. I learned something new about copyright today.

I was digging into the BSD license and exploring the reason for the attribution requirement. I followed jcarmoody's "Copyright is very sticky" link and found this gem:

Now, some have tried to find ways to let you abandon your copyright, or “dedicate” it to “the public.” Creative Commons has a proposed “Public Domain Dedication“, but: (a) it doesn’t seem easy, at least for the typical user; and (b) there appear to be doubts as to whether it would work–and until it’s clear that it does, it’s worse than a CC license, since publishers would be afraid to rely on it. It is possible that a type of estoppel would apply, preventing the “dedicator” from complaining if someone else relied on his “dedication” to his detriment; but there is “a quirk of U.S. copyright law which grants the author of a work the right to cancel ‘the exclusive or nonexclusive grant of a transfer or license of copyright or of any right under a copyright” thirty-five years later, unless the work was originally a work for hire.’” So sayeth Wikipedia; and it outlines other deficiencies of the “public domain dedication.”

Yeesh.

Problem solved.

There is already a Json library on NI.com written by an NI employee that AQ can use and can be included in LabVIEW. So we can now broaden the discussion away from the Json library here to a more general Lavag CR to NI compatibility without getting bogged down on a specific piece of software.

Although nice to know now, I've already built the parser I need. The serialization library will be complete within the next couple weeks.

Uh, wait, what? Can I be sued for stuff I post on NI.com? Sounds like an argument to not post anything on NI.com.

You can be sued for anything you post to LAVA also if you didn't have the legal right to post it.

It looks like*you* (meaning not NI) will have to jump through all the hoops

That's what the law requires... you're the copyright owner. You have to do something to allow NI to use it. There's nothing NI can do on its own to appropriate the rights -- and you wouldn't want there to be a way to do that.

We've made it as easy as possible to transfer those rights through the ni.com EULA. I'm still arguing for changes to that EULA that would clarify some aspects, but it's the only mechanism I have ever heard of for you to easily state unambiguously, "I don't mind if NI unconditionally uses this, sells this, and redistributes this." If you know of another mechanism, I'd love to hear it.

What about a test case? In OpenG there is a Trim Whitespace function that duplicates the same function in LabVIEW. Due to the work of several programmers, OpenG’s version has considerably higher performance. I don’t believe there is any other difference in function, no “advanced” features or anything, and thus no reason why the OpenG version shouldn’t be adopted as standard. What would it take to do this?

That's a good test case.

Option A) All the authors involved would need to sign licensing agreements with each other giving all their rights to one person and then that person upload to ni.com. That one person then becomes the lightening rod for NI in the event that the others want to sue.

Option B) All the authors involved would need to sign a licensing agreement with National Instruments, similar to the one that another customer just went through, giving NI the right to use the VI as part of LV Base. It would likely include clauses requiring NI to actually use the VI in LV Base and not put it in some higher level module exclusively.

If you cannot contact all the authors of this VI, I'm not sure it is possible legally. Trim Whitespace is a prime example of a VI that cannot be BSD when it goes into the palettes... we can't require every user of LV to remember to thank the authors of that VI everytime they clean up a string.