Aristos Queue

Debugging enabled? Front panels closed and unloaded? Inlining?

Are there plans to improve the performance of the VariantType library? The few VIs I’ve tested seem to be about an order of magnitude slower than equivalent OpenG functionality based on parsing the Int16 type array. I never use them as result.

— James

No, there are no such plans. They've never been identified as an API in need of high performance.

And you begin to get pulled right back in ...

Hey, I can kibitz. You'd do that too if you sat next to them. :-)

That performance optimization makes sense to me given what I know of the compiler. It's a bit weird, but I know why it is being done. I'll talk to the compiler guys and see if they can clean things up without the need for that oputput (LV2013 or later, so keep your optimization for now).

Should the standard for the OpenG palette the same as for the LabVIEW palette?

To me, they're all the same palettes unless there's a palette with an explicitly different palette with a "for debugging" name.

The current OpenG Data palette is full of VIs for doing non-standard things with variants by using the inefficient method of parsing flattened data. These new object VIs don’t look out of place. What if we call the VI “Class Display Name” to try and make the point that this is really a name for human readability rather than look-up?

That helps. I'd also like the CH to point people toward more info on the topic, perhaps somewhere in the LAVA Wiki.

[Later] Perhaps make it "Class Display File Name" or "Class Display Qualified Name".

[Later again] There actually is a Display Name property on the class itself (see the properties page for classes). This isn't that display name, so there could be a problem calling it "display". I keep coming back to "debug file name" and "debug qualified name", but maybe you've got something better?

Well, in any case, it looks like the OpenG version is considerably faster (I see ~20 ms for OpenG vs. ~300 ms for the vi.lib VI), so that answers that, at least.

Ah, the int16 array. How... quaint.

There are many types created since LV 8.0 that cannot be represented in the int16 array, and even some older types aren't guaranteed to be represented correctly under various conditions (enum, for example, if there are too many characters in the total concatenated list of strings).

The variant type library in vi.lib is the type library of LabVIEW. The Int16 array is no longer maintained for new types, and hasn't been for years. Yes, it still works on many, even most, types, but it isn't what I would suggest you use, certainly not in the long run.

Wouldn’t by-name-lookup code use the Qualified Name, for uniqueness? Getting just the name is really for human readability, i.e. probes and the like. Also, anyone with more than a tiny bit of LabVIEW ability will take less than five minutes to identify “Get LV Class Path” as a way to get the name of a class. Now THAT is a inefficient method!

Misunderstanding between you and I: when I say "name of class", I *always* mean the qualified name unless I specify otherwise.

In any case, the VI that I wrote for jgcode gets the qualified name. And it is an inefficient way to do so that I would not recommend using for most lookup type applications. It works fine for probes/scripting/reflection type utilities, but not production code, which is what anything in the palettes should be intended for.

And, hey, some of us just want to write some probes!

That's why I asked if there were any suggestions for addressing my concerns in the name and iconography, to make sure that this is used only for the probes use case.

Sounds great, but do you really want to add a method to every single command message class you write in the Actor Framework just to support the ability for someone to write a custom message probe?

No. That's my point. This is a fine mechanism *for* *probes*. But it doesn't really belong in the palettes where it might be mistaken for other purposes if you give it the nice friendly name that it has at the moment.

If only we had some VI that returns the default value of object class so we don’t need to flatten the data. Someone should make one of those.

Yes, we need this in order to make a generic XML parser. Currently (as of LabVIEW 2010) this is only accessible to the NI folks, as I understand it.

Isn't the VI up above one that, given an object, returns the default value of that object? And Get LV Class Default Value.vi returns the default value if all you know is the class. What are you looking for?

I would oppose the general disemination of the "Get Name of Class.vi" without a lot of caveats. Specifically, I'd be tempted to name the VI "Get Name of Class in a highly inefficient but generic manner good for probes but inappropriate if you are really writing a by-name-lookup object hierarchy.vi" ;-)

Here's the deal: This VI flattens your entire object data to a string. That's not cheap and it gets even more expensive as the object carries more data.

If I am really writing a hierarchy where I expect to do name lookups -- like for database storage type systems -- as part of my actual runtime code, I'm going to add a dynamic dispatch method to the root class called "Get Class Name.vi" and override that at every level of the hierarchy to return a string constant. This avoids the memory allocation and performance hit of the flattening to the string (indeed, if all goes as planned, in 2013's compiler, it will avoid any memory alloc entirely as long as the returned strings really are constants). This solution is what is used in C++.

Using any sort of reflection API to get this information in C# is less efficient than adding the "get class name" method. As far as I know, nothing beats adding this to your class definition. We don't do it for all classes generally because it extends the dispatch table with a feature that most classes do not need.

The class-to-path function that is in the palettes today is mostly to support scripting and debugging type work.

Can you find a way to address these concerns in the VI's icon, name and documentation?

Actually, a few days ago I was looking at the Class Library Refnum API to see if it could help me with another idea I have for a useful Object VI. One could do some interesting stuff, but unfortunately Class Refnums don't work on RunTime so one can’t put anything built on it in an exe.

You must be using an old version of LabVIEW. They started working in RunTime in LV 2010. I would NOT recommend using them -- they are VERY slow, because they aren't meant to be used in production code (they instantiate entire projects behind the scenes because they assume you're getting one of these references in order to do manipulation of VIs into or out of libraries or to query about project layout stuff). They should be used for scripting and tools work, not for the actual work of your application. The only reason that they're in the runtime engine is someone wanted to be able to do reflection of projects from TestStand without needing the full development environment.

A couple of renaming suggestions:

"Is Default.vi" ---> "Is Default Value.vi" (just seems clearer to me and leaves namespace open for other "Is Default..." type VIs in the future)

"Same or descendant class.vi" ---> "Is Same or Descendant Class.vi" (use of Is to be consistent with other VIs that primarily return a Boolean; also fixing capitalization to match others)

"Fully Qualified Class Name.vi" ---> "Qualified Class Name.vi" (the Fully is redundant and the shorter name gets more useful info into the palette display)

"Class Name.vi" ---> "Class File Name Without Extension.vi" (the class name is defined throughout LV as either the file name or the qualified name. This makes it clear what is being returned. Again, I wouldn't ship this VI myself, but if you do include it...)

> Putting these VIs in LabVIEW Data would be fine, though that library is quite large already

Can you add them to a subpalette of the "Cluster, Class & Variant" palette? I don't know what ability you have to add to the built-in palettes of LV, but that would seem to me to be the right place for them.

Do you have any specific guidelines on what goes into a library as far as class hierarchies go?

I discussed this issue a bit in the Actor Framework documentation. My personal policy is that "a library should contain intimately connected pieces that are almost always needed together for operations". In other words, your plug-ins and dynamically loaded content should not be in the same library as your core framework. In the case of the Actors, we've been making libraries that contain the actor and all messages that can be sent to that actor on the theory that each message represents a call to one method of the public API, and the public API is always expected to exist on a class.

I doubt it is possible. As soon as something is a member of a library, loading that item will force the library to be read so that item scope (among other things) can be determined. But when you load a library, LabVIEW must make sure that the library isn't broken, which demands that every item get loaded to verify status.

Only classes load all their member VIs. Regular libraries do not. Regular libraries do not care if VIs in them are broken as far as the functionality of other VIs is concerned. They do load all their member libraries, which, by the transitive property of "things that load things", means that a library having a class will load all the member VIs of that class.

Classes can relax this rule in the runtime environement, which we do when you deploy a class to RT, but we never found a satisfactory user experience in the dev environement without having all the members in memory. One weirdness was changing the name of a VI causing VIs of child classes to load or unload, and the unload case was especially weird if you got a Save Changes dialog -- no one expected Save As on one VI to cause a Save Changes dialog on a bunch of other VIs. There were multiple other weirdnesses. Eventually we decided that loading everything in a class is mostly ok since classes are generaly bundles of tightly related functionality such that if you need one part of the class, you mostly need the entire class. Mostly. As long as we could strip out unused methods when going to RT where memory is particularly tight, the tradeoffs seemed worth it.

What I’d like to see is for a LVLib to not automatically load its contained LVClasses until and unless something else in memory refers to that class. In other words, have LVClasses follow the same loading rule as regular VIs in libraries. That would allow me to organize classes in libraries without issue. It would be nice if LVClass libraries could load piece-by-peice, but that is less important and probably not doable.

Yes. I'd like this too. I hope they make something like this.

Ooo... that felt good... hoping something improves and not having to feel guilty that I'm not actively improving it... probably not a habit I should get into since I do expect to go back to direct LV development someday... ;-)

I would just create a VI that returns the paired arrays of strings as a constant... use that all over the place, including to populate the ring in the one place that is actually a user interface.

> An X-Control seems like overkill here, though.

And an XControl is not a diagram element. I think that's pretty much the whole problem: you're using panel elements for diagram information.

> AQ, you should add the Actor Framework to one of the courses! Or maybe a separate class on just that. Maybe at least an excellent webcast like the LVOOP webcast...

Allen Smith and I just did the AF intro in a web cast a couple weeks ago.

http://zone.ni.com/wv/app/doc/p/id/wv-3101

I believe you. Really. I just don't see these crashes myself.

I probably develop more classes than most people on this list, whether it be apps on my own, quick demos for people who ask for them, or testing for CARs. I *don't* typically have the problems you're discussing when editing the private data control or renaming classes. Just today, I had a hierarchy four levels deep in which I had classes in one library. I moved some of those classes to another library, renamed them, moved them on disk and then deleted fields from the private data control and had no problems, before, during or after the operations. I do this on both my Windows machine at work and my Mac at home.

If you have a situation where this happens, I need you to file CARs. Even though I'm not working on them myself any more (see thread in LAVA Lounge from last week), I still care about the quality. My team has done a huge amount to stabilize LV classes over the years. We will do more if you bring it to our attention. This is especially true for those of you who use source code control and can provide before and after images of the classes if they become corrupted.

I helped write the OO course, so take my comments with a grain of salt... of course I'm going to say it's worth it. :-)

The course is 2 days. Day one focuses on design; Day two focuses on implementation. You work your way through designing a single application, working from a customer specification and identifying the classes that will be needed to do the project, and then you turn to implementing it, how that works in LabVIEW and the tools that are available to edit, debug and deploy the app. It's dense -- no question about that. I wish we could have made it three days so we could've added a little bit more breathing room and a few other topics, but at two days, a lot more customers can afford the time away from work, so it's more accessible.

As for whether it helps with the CLA... the best prep for the CLA is still 5 years of actually architecting code. You do not need any OO knowledge to pass the CLA, though you are welcome to use OO in your architecture when you do the CLA if that's the architecture you think fits best.

Like this:

(VI is saved in LV 2011... should work back to 2009... back to 8.2 if you rewrite the subVI.)

Get Name of Class of Object.vi

Use the Flatten To String primitive and take the name off the front. The details of doing this are posted somewhere on LAVA... I forget where. Try searching the OO category for "flat format".

You then pray to the great god MemMan and hope that the garbage collection will get rid of allocations

FOR THE NTH TIME: THERE IS NO GARBAGE COLLECTOR IN LABVIEW.

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.

Finally! AQ is going to provide text-based LabVIEW!

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

Nope. They can't do what they like with it. Their T&Cs only allow them to admonish distribution. You are not granting any license, that requires a document.

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.

Seriously AQ, I guess that congratulations are in order but I didn't actually hear you say that you're really looking forward to this change, or that you even especially wanted it so I guess the jury is out on some of that but still and FWIW -- congratulations! :beer_mug:

I am excited -- it's a cautious excitement as this takes me well outside my comfort zone, but excitement nonetheless.

Who will be "filling your shoes"?

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.

That's not to say it doesn't have utility in discovery-esque scenarios, like Mikael describes. In fact, I think it's the only sane, scalable way to tackle such a problem.

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