Aristos Queue

This is what SOPA stands on end -- among other things. It would make T&Cs like this one invalid and make LAVA (in the case of lavag.org) or NI (in the case of ni.com) liable if someone posted code they claimed was copyright free that turned out not to be. LAVA and NI would have to constantly police their sites and verify that everything posted was legit. Otherwise, if someone came through and said, "Hey, that's my code you're sharing!" then it is no longer sufficient for LAVA or NI to take down the offending post -- they're already on the hook for anyone who downloaded it in the interim. This is great if you're a giant media conglomerate and you don't want to police your own copyrights, but it is terrible for all other players in the media game. There's no way that a site like LAVA or ni.com could exist under those conditions -- every posted VI would have to be held until some site administrator could verify that it was legitimately free from copyright. And how exactly is that done? Do we check a database of all VIs ever written? That's what the media companies want Google and other sites to do for movies and music. I suppose NI could maintain a database of all VIs ever written, but it would probably hurt us in other ways if we insisted that all VIs you write had to be sent to us, just so we can track their authenticity. This is why the tech community is trying so hard to stop SOPA and its variations. And failing miserably thus far.

No, it doesn't give everyone the right to use it... but the person posting it is testifying that they do have the right to use it, and if that happens to not be true, it is the person posting who becomes the legal shield for everyone else -- in other words, it's the poster who is liable for all downstream damages, not the person who uses it.

Actually, I've warned my new manager that at some point I may have a nervous breakdown and wrap all those function calls in VIs directly and thereafter deny the existence of the under-the-hood code. It just feels so wrong not having pictures to tell me what's going on in the code...

That contradicts what I've been told directly face-to-face by our lawyers. If you find a bug in a LV VI and post the fix, I will ask you to post it on ni.com because the lawyers tell me that you've granted us license to use anything you post there in any sort of repackaging we like without attribution or compensation -- my understanding is that that extends not just to NI, but to any other user on the forums who downloads your posted VI.

Shaun, I think LAVA would be in the clear under the safe harbor provisions of DMCA. Now, if SOPA passes, LAVA would be screwed, so everyone call your reps and senators and tell them to stop that trainwreck. But assuming sanity prevails, it would only be the LAVA users who download the code and use it that would be open to lawsuit threat.

I am excited -- it's a cautious excitement as this takes me well outside my comfort zone, but excitement nonetheless. I've been encouraging some of the others to participate more and more on the forums. In particular, Mr. Mike has taken up some of that challenge. And I'm not vanishing entirely, just changing tune.

Well, folks, after 11.5 years of essentially the same job, I'm going to do something new starting next week. This transition is going to change some of my online interaction with the LV user community. For many years, I have directly shaped labview.exe and the VI libraries that ship with LabVIEW. Now, I will switch from "working on LabVIEW" to "working with LabVIEW" -- but I still won't be a G programmer. You see, the text code of LabVIEW has many parts: an editor, a type system, a compiler, etc. Over the last three years, R&D has reworked each of these components to become an isolated API that could -- in theory -- be reused to build a completely different editor, a different type system, a different compiler. In my new role, I'm going to be attempting to do just that, but not to develop any new products. Instead, I'm going to be building small applications that prove out the usability and documentation of these various layers -- apps that are more about being a good tutorial for the API than for doing anything particularly useful themselves. The goal of this work is to prep these layers to be opened up for more people to use. In the short run, that means helping LV R&D team members around the world get the documentation and API support they need when they can't just walk to someone's desk in Austin, TX, to ask questions. In the long run (3 to 5 years), we hope that we'll be able to open these APIs up to the full LabVIEW community to use. That means not just augmenting LabVIEW but also writing whole new applications in the LabVIEW product environment. I am handing off all of my duties for maintenance of features I have built over the years, and LV 2012 is the last LV version for the next few years that will have my fingerprints on the EXE. Oh, I'll probably fix a CAR or two, but I won't be working on the code on a daily basis. I do plan to keep working on G in my spare time, and it may be that I'll have a few small contributions to LabVIEW G tools and vi.lib, but certainly not to the level I've been working at lately. I will still be monitoring LAVA, but for the next few years, I am going to be much more of a "LabVIEW user" than a "LabVIEW developer". That means I will be saying less of "oh, let me go fix that real fast" and saying more of "yeah, I wish they'd fix that, too". In the short run, that means my direct impact on improving LabVIEW is going to decrease. But I think that this new position will be beneficial to LabVIEW in the long run if I really can get the entire platform to be a more open system. And, who knows, some of those mini apps may actually have some functionality that proves useful... I've got a couple ideas in my head already. If all goes as planned, a few years down the road, the APIs that empower creating custom nodes, specifying alternate models of computation, and compiling to truly foreign targets will be wide open. Then I could move happily back to the Language team armed with a lot more power and with a whole community of developers able to help build the future. Now, if you'll excuse me, I'm going to go get some sleep... I've got two days left and a sizable list of CARs that Certain People have asked me to fix before I switch roles. :-)

This CAR should be fixed in LV 2012. LV will be able to parse for "<Cluster/>". By the official documentation, "<Cluster />" is legal XML as well, but LV does not allow for spaces between the tag and the forward slash when parsing any other XML tags, so I did not include that in this fix. That would be a more systemic fix to all of LV's parsing.

In at least some instances, I would hope that you would reach for a parallel solution to run all of these tests in parallel, such as kicking off a Parallel For Loop or launching N Asynchronous Call By Reference operations and taking the first one that returns TRUE (and aborting the others).

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.

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. :-)

Other sites include a clause that if you post something that you don't have the right to post, part of the content of the terms of use says you agree to serve as legal shield for anyone else who gets caught by your goof. I don't know if ni.com includes something like that.

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.

In general, Darren and I add comments to our diagrams when, during a buddy session, we actually have to explain what's going on to the other. That's our standard measure for when a comment is needed. If the buddy session proceeds without the other person getting lost as we walk through, then the code and the API documentation (i.e. the Context Help) likely suffices as it is. My instinct in this case would be to put a Diagram Disable structure down and put the other version that I had tried in the Disabled frame -- then I don't have to describe what I tried, people can look at it. Now, that is only true when the other version of the code is all prims or vi.lib VIs, things that don't cause my source code to have additional dependencies when distributing it. As much as possible, I would still prefer to include the graphical "here's what I tried" and avoid a text description of it. It is both more accurate to say "I tried this" and if someone else says, "But that other way really should, by rights, be faster..." they can benchmark it themselves easily and/or spot any errors I had in my implementation. And if the compiler takes advances, it's easy to flip in the other code.Now, having said all of that, I do tend to include "proof of correctness" comments with complex algorithms, along the lines of "This loop works because earlier in this VI we already guaranteed that there are no duplicates in the array". This is especially true when I'm relying on a less-than-obvious fact of one of the upstream functions. For example, I recently wrote a VI with the comment "This works because the Controls[ ] property of a Front Panel refnum guarantees that the controls are returned in tab order." Most people analyzing my code for correctness wouldn't know that fact, even if it was properly documented (it will be in LV 2012), so it was worthy, IMHO, of a comment.

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.

According to everything I could find on ni.com, the event structure is supported on RT ever since LV 7.0. I would be surprised if you're still using LV 6.1, which was the only version where it could not deploy to RT. I used to maintain versions of LV on my home machine going back that far, but at this point, I only have as far back as 8.6, so I can't actually check.