Aristos Queue

jgcode: That's nice, but the main thrust of the discussion is how do you *certify* that code posted is legally allowed to be posted as CC0 (or any other sharing license)? Unless I can certify the chain of intellectual property (like the chain of evidence in police work) OR I have a legal shield at some point in the chain, I can't use something posted to LAVA in work I do for NI regardless of the licensing that LAVA defaults to. There are some users that I know well enough to believe them when they post something and claim it is their own work and I'm free to use it, but I know very few users that well, and the graph of "users who know other users well enough to trust the code chain of IP" is generally quite sparse. A community site like can never be as reusable as you would like without that certification on every upload, not just the highly scrubbed CR.

No, Shaun. You'd create JSON Object.lvclass. As each one comes in, you'd create the object of the named type (all of which inherit from JSON Object), and then invoke "JSON Object.lvclass:Do Appropriate Processing.vi" and each class would have overridden the method to do whatever it needs to do. At no point would you type test.

Ideally you would implement this as an interface, if LV had those, but plain inheritance would suffice for the problem as you've described it here. Oh, and you'd be a lot better off than the string testing of the non-OO solution.

drjdpowell: I do remember those earlier conversations. I'd still like to see the actual code that you wrote so I could evaluate it in context. The text descriptions for architectures this large do not suffice -- I can see that an implementation that needs the exact type testing could work, but I can also imagine several other implementations that do not need type matching, and in my head, those work out as better solutions, but I can't assert that they necessarily would be better because you might have found a case where exact type testing really is necessary.

Ton: By complete coincidence, a fairly old 2010 thread got new life yesterday when someone posted on it, and it is a post from Norm showing exactly what you show here.

Couldn’t we have a few nice primitives for determining class relationships, so I don’t have to learn this weird compiler voodoo?

We put the classes together with priority on the operations we thought people were going to need regularly. Exact type equivalence is nearly anathema to good design, as MJE noted in his original post on this topic. Yes, we could create a prim to do exact type equivalence. But the question is, why are you creating any hierarchy where the child class cannot fully substitute for the parent class? That usually leads to serious problems and hacks piling onto hacks. So we spent time on other stuff. :-)

Right, I think I said as much, albeit a lot less clearly.

The real issue is that ni.com can't really prevent you from posting infringing code. It would be a violation and I'm sure they would take it down if duly notified by the copyright owner, but in the meantime if someone else downloaded the offending code and reused it, they could still be liable to the copyright holder.

Actually, I was planning my retirement based on suing all the LAVA users, but then I found out that all my work is "work for hire" and owned by NI, so that plan's no good. :-)

> It seems like a site has no authority to assert that

> donated code is public domain or any other license,

It does if you agree to the site's terms of use when you created your account, which you do with NI.com.

> Another issue: aren’t all these object manipulating techniques rather obtuse code? Sort of LabVIEW alchemy?

I never said otherwise. You asked for a solution. You didn't ask for a *planned* solution. :-)

> Why does that work?!?

Because the defined behavior for LV classes is to be the default value of the object *as if the loop had iterated once*. It is a feature choice that makes automatic downcasting work a lot better.

There's a problem with your benchmarks: your benchmarks for MJE solution will vary depending upon the contents of the private data control of the class and which OS you're running on.

The solution posted by ShaunR is going to be the stable option regardless of the contents of the class. The performance of the MJE method will vary greatly depending upon the private data control of the objects being compared. Going through the Preserve Run-Time Class primitive will require a new allocation every time (because the wire starts with an instance of LabVIEW Object, copied from the constant, which is deallocated in favor of a new handle pointing to an object of the middle terminal's class). On a desktop system, that handle will just be assigned to point at the default value, since LV shares only one copy of the default value, but on real-time targets, that would be a full allocation (because everything has to be preallocated to avoid jitter in the event that the object gets passed into a deterministic section). Then we get to the equals primitive. In the case where the types do not match, you'll get a very quick answer because the type pointers can be compared. But if the types do match, if the class contains non-trivial data fields, you'll have the time overhead of actually comparing the fields. On a desktop system, again, we'll notice that they both point to the default value and you'll get a quick answer, but on real-time, we'll actually run the comparison proc to see if the values come out the same.

Now, if you're on a desktop system, the MJE, as I described above, does really well. I am guessing that this one would do even better:

Yes, that's a hardcoded zero iteration For Loop with the class wires wired across using tunnels, not shift registers. It does the job. I haven't benchmarked it -- you're free to do so -- but it avoids the type comparison work entirely that the Preserve Run-Time Class primitive does.

Having said all of that, even on RT, I would probably not use the stable solution because it requires the construction of those interim variants, which is a memory allocation. I just figured you should be aware of the trickiness of benchmarking this stuff.

On a completely unrelated topic, MJE, you can replace the error generation code you've got with this:

It's a lot simpler. The VI is in the palettes near the General Error Handler.vi.

Oh... and the path solution does have one problem: if a class has never been saved, the path will be empty.

I won't use it (diag disable struct) if I'm fixing a bug or something like that -- that's what source code control is for. But if I want to document "this alternative was tried and is less performant", that's often easier to document for the future using a disable structure. Also, sometimes the speedier algorithm is more complex, and if we get a bug in the future, the disable structure makes it easy for me to flip back to the slower but easier to prove right algorithm, so I can tell if the bug is in the algorithm or somewhere else.

The bytes used are because classes carry with them their type information which is what enables the significantly more powerful flattening/unflattening abilities over and above raw data.

Please post your picture here rather than linking to it. I don't trust any link that claims to be to a picture but where the picture name is actually a directory name and takes me to a site in a foreign language with all sorts of complaints about me having my security settings too high.

If you're looking for draw.llb, look here:

http://forums.ni.com/t5/LabVIEW/Primative-quot-paint-quot-functionailty-and-where-is-Draw-llb/td-p/617628

Oh. Gotcha. Since the front panel doesn't even exist on an RT target, I didn't even stop to think that might be what the poster was looking for.

To do a full user interface for RT, you actually have to build a host VI, running on the host, that has communication back to the RT chasis. The remote panel from an RT box is just designed to do debugging and limited control, not be a substitute for a full application.

Classes are libraries, so you already have namespace protection for the VIs therein. I only apply a library wrapper when the classes will always be loaded together. Classes that are just distributed together as part of a toolkit don't get packaged into a library. The only exception that I can imagine is if you're using licensing (available from NI for those in the NI Partner's Program) since licensing requires a library wrapper.

Ahhhh, if only I could upgrade... That would make things easier.

That may be so, but anyone's welcome to post about what they think are possible bugs here - so we can all discuss it, and maybe flesh it out more before it's reported.

I'm hoping that we get an analysis of which questions are being missed so we can analyze them to see if they're bad questions and, if so, fix them. Unfortunately, it takes multiple people actually taking the exam to generate that data pool. Curiously, the annecdotes I'm hearing seem to indicate that our beta test group of CLAs was abnormally skilled at passing the CLA-R compared to the general body of CLAs. Perhaps CLAs become smarter when in physical proximity to each other? :-)

CAR 328228 filed.

For future reference, posting something like this at http://forums.ni.com/ is more effective than posting it on LAVA -- the NI application engineers monitor those forums continuously and can directly file CARs and they know the known issues and workarounds better than anyone. Yes, sometimes posting here works, but no one from NI (myself included) assiduously reads every LAVA post, so bug reports like this can get easily missed.

> Also I wouldn't put too much untested faith in the idea that each time a sub-vi runs w/an event reg node in it, that the executions of that node will be wholly unrelated.

Though I agree with Norm's admonitions on this topic generally, if you make the subVI that generates the event refnum be inlined (LV 2011 feature on the VI Properties dialog >> Execution page), I'd be very confident that it is just like having the event registration node on the caller diagram.

WHOA. You can bundle event registrations?!!?!?!? WHY HAS NO ONE EVER SHOWN ME THAT TRICK BEFORE?!?!

does 2009 actually outpace 2011?

If I use a Run VI method which is using the LV2G which is already initialized before in another hirearchy, and having a valid reference in its SR (I am not re-initializing the .NET constructor in dynamically called VI, I am just reading the reference out of SR), does that mean that it would still be loaded in a different hirearchy and would have an invalid reference? I think it shouldn't?

To the best of my knowledge, no, no one has made efforts in that direction.

If someone has a real aversion to the polling method, it might be just as well to make a parallel event loop, registering for the same events you would in your main loop.