proposal Migration of OpenG Projects to LabVIEW Project Libraries?

[jgcode]

This thread was manually moved from OpenG to LAVA.

Howdy

LabVIEW Project Libraries (.lvlibs) provide namespacing, scope and iconography among other things and I would like to discuss their role in OpenG Projects (I did not use the term libraries to avoid confusion). Also, some cool things can be done like making all Polymorphic Member VIs private, but the Polymorphic VI public (and whether that would be desired). NI also seem to be moving their code to this paradigm (but have the benefit of linking to the new namespacing automatically on upgrade).

Anyways, my intention is to keep the question pretty general in order to generate a discussion in any direction (reasoning, process, benefits etc...).

What are developer's thoughts on migrating the OpenG Projects to LabVIEW Project Libraries?

Cheers

-JG

I guess we should put together a pros and cons list and weigh everything together.

I think that some things are a great fit for LVLibs: poly VIs, Dictionary, Message Queue, Zip Tools, etc.

However, I wonder about how much benefit there is to grouping everything in the OpenG Array or String libraries into an LVLib (where the VIs are only grouped based on the data type that they operate on).

Maybe this is a good discussion for LAVA.

[Ton Plomp]

In theory:

YES

I would opt for a library name with the following naming theme: OpenG.String.lvib, on the actual VIs we could lose the name mangling (__ogtk).

Now for real, I think this is a hard one to do. It would mean deprecating all of out VIs and wrapping them in complementary libraries. Our could we hack some update code in congregation with NI?

I think it's doable to write some 'wrap and deprecate' tool to do this and regenerate our palettes.I wouldn't want the polymorphic VIs to be public and make the specific instances private, main reason is that Real-time cannot cope with variants, and you couldn't bypass the public polymorphic VI by calling directly into the specific instance you need.

Ton

[Ton Plomp]

I've been thinking a little bit more about this, and I would say it's pretty good doable!

We should deprecate all of our current VIs and we should add some things to our deprecation process:

-Each VI that is deprecated should have a boolean tag 'Deprecated ==True'

-If a VI is deprecated there should be a relative path tag 'Replaced by' that contains the path of the VI it's replaced by.

Now we could write a tool that goes over all the VIs in a folder or hierarchy to update the code to the latest version.

Ton

[Ton Plomp]

On the LabVIEW beta forum somebody said that he was able to move a VI into a library, and he had no issus with VIs finding the (renamed) VI.

The only downside is that calling VIs are 'dirty'. So I see no issues with this move anymore.

Ton

[Val Brown]

From my perspective, again, this would be an example of "doing it right" -- even if it involves some work now (cf Ton's comments above) it still would be the most consistent and comprehensive way to organize OpenQ. But then again I don't have years of legacy code using OpenG so I'm certainly not down in the trenches on this one.

[jgcode]

Personally, I would like to see this happen, for reasons listed in the OP (namely scope and namespacing) - but this is more from an OpenG Developer POV.

Additionally, I think it is inline with the way LabVIEW libraries are heading (or have been heading) too.

On a side note, I like the fact the VIs are just VIs for some of the ways I do building (tools etc...), but regardless I think .lvlibs are a positive move forward.

What are some of the End User benefits (or downfalls) of such a migration?

Please discuss - as I would like to see this topic advance.

[GregSands]

My experience with .lvlibs is that it is very straightforward to move VIs into them, but very difficult to change anything later. I once (and only once) made the mistake of splitting a large .lvlib into several smaller ones, thereby moving VIs into new namespaces. It was a real headache relinking all the code that called those VIs - there doesn't seem to be a way to automatically find them in a new namespace. Very nearly rolled it all back - though I do now appreciate having the smaller libraries, as loading any one VI from a .lvlib loads the whole library. (If any does know how to do this, please tell me -- I'll feel silly for 5 minutes, then really appreciate it!).

So, yes, in my opinion it's worth doing, but you have to do it right the first time. OpenG is probably defined well enough that this won't be an issue.

[jgcode]

It was a real headache relinking all the code that called those VIs - there doesn't seem to be a way to automatically find them in a new namespace. Very nearly rolled it all back

I am confident that the OpenG team will be able to solve this problem technically, without causing re-linking issues (with the help of a tool etc...).

If not, that would be a reason not to migrating IMHO.

...though I do now appreciate having the smaller libraries, as loading any one VI from a .lvlib loads the whole library. (If any does know how to do this, please tell me -- I'll feel silly for 5 minutes, then really appreciate it!).

It is my understanding that VIs are not loaded into memory, only the Library (.lvlib) is and any child Libraries.

If that child Library is a Class Library than yes, those Class method VIs will be loaded into memory as per the how Classes work.

[Jim Kring]

Is there a list of Pros/Cons anywhere? Perhaps a list could be maintained in the original post of this thread?

[Aristos Queue]

> Our could we hack some update code in congregation with NI?

You don't have to hack.

Suppose Alpha.vi calls Beta.vi. When Alpha.vi saves, it writes down the path to Beta.vi in its save image. When you load Alpha.vi, it tries to load Beta.vi at that path. If it doesn't find Beta.vi, it searches disk.

Now, modify Beta.vi to be inside Yoda.lvlib. Now load Alpha.vi. What happens this time is Alpha.vi goes to the location it recorded, and it finds a file named Beta.vi. It loads it, and discovers that the file is actually Yoda.lvlib:Beta.vi. That's ok. Normally on load we require that qualified names match exactly, but we make an exemption for "caller last saved looking for an qualified name with no library at all and caller now found -- at *exactly* the same path (no searching) -- a VI of the right file name but different library name, so count that as a match." Now, if Alpha.vi is saved looking for Yoda.lvlib:Beta.vi and you then move Beta.vi out of Yoda.lvlib and into Yolanda.lvlib, now when you load Alpha.vi, it finds Beta.vi at the right path, but the qname doesn't match, so it considers the subVI to be missing, and searches accordingly.

This is why upgrading from no library to library is easy. It is why upgrading to a different library ownership requires the same machinations as renaming the VI file itself.

> ...though I do now appreciate having the smaller libraries, as loading any one

> VI from a .lvlib loads the whole library. (If any does know how to do this,

> please tell me -- I'll feel silly for 5 minutes, then really appreciate it!).

There are five library types: lvlib, xctl, lvclass, lvsc and xnode (the last of these being somewhat mythical). Lvlib and lvsc do NOT load all of their member VIs. The others do. They do list all their VIs in the project tree, but the VIs are not loaded into memory. All of them do load their nested libraries into memory.

> I wouldn't want the polymorphic VIs to be public and

> make the specific instances private, main reason is that

> Real-time cannot cope with variants, and you couldn't bypass

> the public polymorphic VI by calling directly into the specific

> instance you need.

Um, yes, that's the whole point. You couldn't bypass the poly VI. Under what conditions is that undesirable?

[jgcode]

> Our could we hack some update code in congregation with NI?

You don't have to hack...

...This is why upgrading from no library to library is easy. It is why upgrading to a different library ownership requires the same machinations as renaming the VI file itself.

That's cool.

But what about if the name changes e.g. the dist code is namespaced whilst the source is not.

We now use the Library Name to namespace the code and want to remove the original VI namespacing.

E.g. "an_openg_function__ogtk.vi" becomes "OpenG Library:an_openg_function.vi" - then we would be needing some tool (something I have already given thought to) to handle this.

[eberaud]

Now, if Alpha.vi is saved looking for Yoda.lvlib:Beta.vi and you then move Beta.vi out of Yoda.lvlib and into Yolanda.lvlib, now when you load Alpha.vi, it finds Beta.vi at the right path, but the qname doesn't match, so it considers the subVI to be missing, and searches accordingly.

 

Old thread, but explains exactly what I've been working on for the last 3 weeks! 

There are five library types: lvlib, xctl, lvclass, lvsc and xnode (the last of these being somewhat mythical). Lvlib and lvsc do NOT load all of their member VIs. The others do. They do list all their VIs in the project tree, but the VIs are not loaded into memory. All of them do load their nested libraries into memory.

 

I understand the concept of loading VIs into memory while in the dev environment. But what about building an executable? Let's say I have some VIs in a lvlib that are not being used anywhere in a certain application I'm going to build. But since there are other VIs in that lvlib that are being called, I see the lvlib and all its members in the dependencies. The unused VIs won't be loaded in memory, but are they going to be included in the executable?

[Aristos Queue]

I understand the concept of loading VIs into memory while in the dev environment. But what about building an executable? 

Depends upon how you configured your build. There are options in the build settings to include or exclude them as you choose.