Why is OpenG Installed to the user.lib?

[lvb]

NI is now suggesting that reusable libraries should be located in the vi.lib. I was curious why the OpenG Toolkit 4.0 is installed to the user.lib.

File and Folder Names for Integrating into LabVIEW

Thanks for all the hard work!

[Val Brown]

Because it's not (yet????) an officially supported re-use library -- not officially supported by NI that is. But at another level you ARE right -- it should be there because it should be "adopted" by NI. Well at least that's my perspective on it.

How many here use OpenG in their commercial products? Do those who do that include the appropriate EULA in the installer for their product? What is the proper way to include OpenG in a released commercial product? I'm sure these have been responded to in the past but they are now coming up as real questions for me, given the changes at NI (like including VIPM in the startup to manage addon tools).

Any help would be appreciate, including refs to useful prior posts here on these issues. For those who are interested in what I've written most recently about this issue look at: https://decibel.ni.com/content/docs/DOC-15014#comment-17128.

Thanks.

val

[Ton Plomp]

NI is now suggesting that reusable libraries should be located in the vi.lib. I was curious why the OpenG Toolkit 4.0 is installed to the user.lib.

File and Folder Names for Integrating into LabVIEW

The main reason is compatibility with older versions, since NI has openend the 'upgrade' functionalities they use internally (open up an old 6.x file VI and you'll see what I mean). So without breaking all the software allready utilizin OpenG we cannot move the files (we could deprecate the old locations though).

And I have another perspective than NI, I've always assumed that everything inside vi.lib should be available on any LabVIEW install. This assumption alwasy told me to post add-ons into user.lib or instr.lib. So I'm in favour of the user.lib location.

Ton

[crelf]

How many here use OpenG in their commercial products?

We do.

Do those who do that include the appropriate EULA in the installer for their product?

Of course - it would be illegal not to.

What is the proper way to include OpenG in a released commercial product?

I don't understand the question.

You can find out more about BSD licensing (which is the license the majority - if not, all - of the OpenG components are releaed under) here: http://en.wikipedia....ki/BSD_licenses Each OpenG componens includes the license text, so you can know what you're up for when distributing it.

[jgcode]

To the best of my knowledge (on phone so don't have VIPM fired up) all packages part of the core OpenG Library have BSD licenses except LVZIP because it leverages other code (and must inherent it's license or similar).

That document is referring to creating add-ons by anyone, I can't see anywhere it's saying offically supported by NI only if it goes in here - it's just merely a suggestion?

Anyways, there is nothing wrong with user.lib. I use it, as well as other companies, to distribute reuse libraries. I can't see the location really matters, and my opinion is the similar to Ton's wrt vi.lib.

As Ton mentioned moving would cause relinking a recompiling issues, which would be a big problem.

Btw - OpenG is a LabVIEW Tools Network Silver Certified product. Whilst not supported by NI, it has passed the above standard.

[Val Brown]

OK, to be clear (CRELF because he asked it) I was definitely NOT suggesting to not include the appropriate info if OpenG is in your code. Rather I was asking for clarification from those who do it routinely about what specific info needs to be put into my code to be fully compliant. I'll follow up on the refs -- thanks!

Jgcode, I appreciate that OpenG is Silver Certified. I didn't know but that alleviates that level of concern for me. And as we all know LAVA is the "gold standard" of highly talented, well-seasoned LV architects and aficionadi who give us all the benefits of their experience by giving us their time: and that is the single biggest gift anyone can give you.

I think if (and I really hope it's WHEN) OpenG is fully integrated into LV "officially", it should then be in vi.lib as it should be part of the default instll: ie available to all users. But that's probably just simply an IMHO kind of statement.

[jgcode]

Jgcode, I appreciate that OpenG is Silver Certified. I didn't know but that alleviates that level of concern for me. And as we all know LAVA is the "gold standard" of highly talented, well-seasoned LV architects and aficionadi who give us all the benefits of their experience by giving us their time: and that is the single biggest gift anyone can give you.

Concern? OpenG is striving to conform to standards set by NI.

That should be reason for feeling relief if anything?

As for LAVA, whilst I fully support and agree with the above LAVA compliments, I don't think you are comparing apples with apples here, i.e. Open Source code certification, versus - help you get on the forums?

I think if (and I really hope it's WHEN) OpenG is fully integrated into LV "officially", it should then be in vi.lib as it should be part of the default instll: ie available to all users. But that's probably just simply an IMHO kind of statement.

Wouldn't really be Open Source if NI owned it and distributed it with LabVIEW!

FWIW I hope this day never comes. What I would love to see on the other hand is that if an OpenG VI was so awesome (e.g. covering a functionality gap) NI decided to include such functionality in a future version of LabVIEW (this is my personal opinion only).

I.e. OpenG influenced LabVIEW positively then that would be great, but I don't want to see them manage the entire OpenG organization!!

And it is available for everyone - simply download VIPM and away you go (Note: I appreciate that some companies cannot or do not wish to leverage such resources for internal reasons, and I have no issues with that).

The LVTN is a way for any organization to plug into LabVIEW and OpenG views certification as very important.

Anyways, I am just trying to understand your reasoning - are u able to go into details on why you would want the above?

[lvb]

Because it's not (yet????) an officially supported re-use library -- not officially supported by NI that is. But at another level you ARE right -- it should be there because it should be "adopted" by NI. Well at least that's my perspective on it.

The recent direction of NI to push VI Package Manager leads me to believe OpenG will never be integrated into LabVIEW. It seems that NI is attempting to leverage the community for extra value added toolkits and re-use code while giving credit to the toolkit developers. Many of these toolkits have "NI part numbers" but are 100% supported by partners.

Wouldn't really be Open Source if NI owned it and distributed it with LabVIEW!

FWIW I hope this day never comes. What I would love to see on the other hand is that if an OpenG VI was so awesome (e.g. covering a functionality gap) NI decided to include such functionality in a future version of LabVIEW (this is my personal opinion only).

I.e. OpenG influenced LabVIEW positively then that would be great, but I don't want to see them manage the entire OpenG organization!!

And it is available for everyone - simply download VIPM and away you go (Note: I appreciate that some companies cannot or do not wish to leverage such resources for internal reasons, and I have no issues with that).

The LVTN is a way for any organization to plug into LabVIEW and OpenG views certification as very important.

Anyways, I am just trying to understand your reasoning - are u able to go into details on why you would want the above?

I concur with the above reasons for keeping OpenG as a third party package. I believe the reason why some want OpenG integrated into LabVIEW is due to issues with the process of getting the library into LabVIEW. For instance, my organization had to tweak the firewall for VIPM to properly download the OpenG packages. I can see how this may be a hurdle to install "additional" software with IT among large organizations.

And to follow-up on the original thread: thank you for the information. My hunch was backwards compatibility. It would be nice to have OpenG libraries excluded from the VI Hierarchy window which is not an option for user.lib.

[jgcode]

It seems that NI is attempting to leverage the community for extra value added toolkits and re-use code while giving credit to the toolkit developers. Many of these toolkits have "NI part numbers" but are 100% supported by partners.

Yes, that seems correct, and IMHO is very logical to mainstreaming LabVIEW.

On a side note, it provides a great market place, allowing developers to make money from selling tools etc...

I concur with the above reasons for keeping OpenG as a third party package. I believe the reason why some want OpenG integrated into LabVIEW is due to issues with the process of getting the library into LabVIEW. For instance, my organization had to tweak the firewall for VIPM to properly download the OpenG packages. I can see how this may be a hurdle to install "additional" software with IT among large organizations.

As a side note, from reading their forums, posts and blogs etc.. JKI are able to help with this process.

And to follow-up on the original thread: thank you for the information. My hunch was backwards compatibility. It would be nice to have OpenG libraries excluded from the VI Hierarchy window which is not an option for user.lib.

If there is any logical reason(s) such as the above, that would make sense to move the libraries (or do anything else to them) then OpenG want to hear it!

The only other use case I can think of, off the top of my head is when - I have wanted to do this in during a source distribution build:

I wanted to exclude NI vi.lib but not my library VIs (which was under vi.lib at the time), but I couldn't so having it in user.lib lets me etc...

[Val Brown]

I wasn't suggesting that NI should OWN OpenG, just that it should "live" in vi.lib and be officially supported by NI in addition to the support given by the OpenG community. My less than optimal experiences all occurred a number of years (and versions!) ago -- way before VIPM was available. VIPM does make a difference re: migrating code to newer versions and that would ease the pain, but it wouldn't have solved the specific problem I had "back in the day". And I agree that the Open Source community is an incredibly valuable community -- but I also lived through the C/Pascal/etc "wars" of the early days -- before C## was developed. I saw the battles and fights for control over unix and its variants and ALL of that was incredibly challenging to active programmers: just when you'd get a "complete" system approach going, new versions would come out and, like spring flowers and weeds, bugs would pop-up everywhere.

One of the big plusses for me in moving to LV when I did (back in v4) was that I could essentially and almost completely avoid those kinds of problems: because I ONLY used code that was supported by NI.

Now that's not entirely true because, in the early days of my project, I had to deal with legacy VB and C## code leftover from other consultants who "knew that was the better way to go" when it DEFINITELY wasn't. But it did serve THEIR purpose of trying to maintain value for themselves, as well as not having to deal with the fact that they didn't know how to make LV work, and also were embarrassed by what I (with no CS degree and "just" a domain expert) was already doing with it. The first several years were largely spent by me removing that crap from the project so that it was ultimately all native LV.

The only thing now that remains non-NI has been the Blowfish implementation -- and I do so wish someone would update that. It's still got CINs in it! And we all know they are .

So, no, I don't want NI to OWN OpenG -- just include it in vi.lib or, since it appears that won't be happening (at least "not yet") then I want NI to and the OpenG community to not ever move it to vi.lib. If it's home is going to be -- and remain! -- user.lib then that's fine and makes some sense for reasons others have stated, esp backwards compatibility. And it was developed by users, so of course that location makes sense...

[jgcode]

Can you define "officially supported by NI" I.e. What would you expect feom them? Phone support, for them to code bug fixes etc...?

Also are you go into detail about the issue you had?

Cheers

-JG

[Ton Plomp]

.... For instance, my organization had to tweak the firewall for VIPM to properly download the OpenG packages.

Brian, could you specify how you tweaked the firewall. I don't know where the OpenG packages are hosted (and I don't think IT is willing to open the firewall for sourceforge.net), so if you have any info on that please add.

Ton

[lvb]

Brian, could you specify how you tweaked the firewall. I don't know where the OpenG packages are hosted (and I don't think IT is willing to open the firewall for sourceforge.net), so if you have any info on that please add.

Ton

Ton,

I am not sure why the forum insists on cropping the URL links below, so I apologize for the formatting. You will have to copy the URLs.

My issues are on the JKI forum located at http://forums.jki.ne...curity-gateway/

Our company runs an Astaro Security Gateway which does not allow direct file downloads. This prevented VIPM from any operation related to the internet. Our solution was to whitelist sourceforge.net, jkisoft.com, and ni.com.

VIPM acts a lot like a linux repository. Note: I used wireshark to packet sniff where the information is coming from.

1. Package Mirror List

You can specify here a preferred package source.

http://jkisoft.com/p...orgeMirrors.txt

2. Repository

This downloads the available packages to obtain from the Package Mirrors.

http://ftp.ni.com/ev.../index.vipr.zip

3. Packages

These come from

The following work-arounds exist:

1. IT Department Whitelist

Extensions: .zip, .vip, .txt

http://jkisoft.com/p...orgeMirrors.txt

http://ftp.ni.com/ev.../index.vipr.zip

http://www.ni.com

selected sourceforge mirror

2. Download from home

Install LabVIEW Run-Time Engine and VIPM.

Download desired packages.

Copy downloaded files from C:\ProgramData\JKI\VIPM\cache

3. Manual Package Download

Subscribe to the RSS feed and manually download the files. Double click on each file to install with VIPM.

http://sourceforge.n...gtoolkit/files/

RSS Feed: http://sourceforge.n...sc/limit/20/rss

4. VIPM Enterprise Repository

This was suggested by Jim Kring. I am not sure how this would bypass the firewall:

"Another option, altogether, would be for you to set up your own VIPM Enterprise Package Repository and, on your VIPM Clients located on your corporate network, disable (in the VIPM Options dialog) the connection to the VI Package Network. Then, have each of your VIPM Clients connect to your corporate package repository where you would make all the OpenG and other packages available to your corporate users."

Hope this helps.

-Brian

Edited August 13, 2011 by brianafischer

[Val Brown]

Can you define "officially supported by NI" I.e. What would you expect feom them? Phone support, for them to code bug fixes etc...?

Also are you go into detail about the issue you had?

Cheers

-JG

Good questions....

Re: the first one I have to say I'm not entirely sure but perhaps SOME degree of phone support (perhaps only for PLatinum certified addons????) not just a blanket: "Sorry that's not our problem." Now that's not a literal quote but it was clear that there was no possibility of further information from NI and, frankly, I didn't blame them at the time. It was just unfortunate given my predicament.

So that brings us to the second question. I could look up the exact dates and the exact LV versions involved but I believe it was during the transition to v7. The critical marker was that the "Legacy I/O" VIs in the serial palette were all deprecated and replaced -- internally -- and replaced with code that called VISA instead. That caused ENORMOUS problems for me -- it was essentially unworkable -- so I started looking about for a substitute and find the OpenG Serial library, which also didn't work. Follow up with NI was completely useless -- VISA was not workable given the prior working code. And the author of the (then) OpenG serial library couldn't offer any help either.

It was a terrible couple of months because I couldn't go forward and, for a number of reasons, couldn't revert the code to what worked in the prior version of LV. Fortunately I did get some absolutely fabulous backdoor support (thanks to bp ) that arose out of conversations on LAVA -- so thanks to LAVA as well .

That workaround persisted through another couple of versions of LV and it really saved me.

Now one could say that NI dropped the ball first because it was how they did the deprecation of the prior Legacy Serial VIs that caused the fundamental -- perhaps. And I did give NI a lot of grief over that but also I didn't really know enough to develop a better work around and I also didn't know enough to make VISA work -- and that is now the basis of our hardware interface code. But the suggestion from a number of sources was to migrate to OpenG and that certainly didn't help in this instance.

Now I do want everyone to be clear that I highly respect all those involved in OpenG. The work is exemplary, well organized, thorough, etc. But it didn't work for me back in the day. Today is another day and now, I'm looking into it, because of this OO Design Pattern example and because VIPM has now been introduced into LV. I just think that process should continue.

val

[Yair]

It would be nice to have OpenG libraries excluded from the VI Hierarchy window which is not an option for user.lib.

Vote for this idea (http://forums.ni.com/t5/LabVIEW-Idea-Exchange/more-exclusion-settings-for-the-VI-Hierarchy/idi-p/963121) and follow the comments there.

[crelf]

...the suggestion from a number of sources was to migrate to OpenG and that certainly didn't help in this instance.

Your tale reminds me of a similar story: I had a very senior co-worker at a company I worked at years ago who was bitten by a bug in an OpenG VI once, and his solution was to proclaim that no one at the company be permitted to use open source reuse libraries. Most of the other developers were relatively junior, so they all took his lead. A couple of years later I started working at that company, someone asked for my help on something, and I told them there was an OpenG VI that did exactly what they wanted. He told me the story, so I went and talked to the guy that was originally bitten by the bug and he told me his story of woe. I asked him why he didn't fix the bug and upload it back to OpenG? Or maybe even just post a quick couple of lines to the forum to let everyone else know about it? His reply was that his job isn't to help others outside the company to profit.

The code you get from OpenG may not be perfect. The code you get in vi.lib may not be perfect. The code you write isn't perfect. don't tell my boss, but the code I write isn't perfect. But that's part of why we're all here: to accept challenges and make things better. Now, if you can't tolerate any code that doesn't do exactly what you want it to, then you need to start coding in assembly. Otherwise, accept that what you get from OpenG, NI, etc is best effort from the developers, and (and this is the bottom line here) is created to try to help you. If it doesn't, drop them a line and let them know why, but don't write it off because it wasn't a perfect fit. Better yet, get involved so that others can benefit from the code you write.

I'm not saying that OpenG shouldn't be criticized: in fact, the OpenG architects and developers actively encourage it - it's only through constructive criticism that it will grow and better serve the people it was created for: you!

[Val Brown]

CRELF,

Yes I appreciate what you're saying here and it was appropriate to migrate this hijacked thread here, away from the example posted by Eli. My original point was simply that it wasn't announced -- or indicated -- anywhere that the example included OpenG. I was in the Hands On session at NI Week that featured it and no one there mentioned it either -- but did give instructions on how to download the example for our own use. Had Eli documented somewhere obviously that OpenG was not only used but necessary to run the example code, then I might have had somewhat of a reaction -- "Oh no, OpenG again and I have to download it...." -- but then it would have been my choice to continue BEFORE investing time and energy into an example that was supposed to show a Design Pattern, not just "how to do OO".

All that having been said, my preference is to have parts of OpenG integrated into the distro LV so tat we can all be clear about using at least those parts of (what had been) OpenG and do it transparently. Or, if that isn't done, then let's at least have all of us post somewhere on a FP or in the documentation or, or, or about what the dependencies are, esp when one is OpenG -- or a special NI Toolkit like Sound and Vibration. It's just good style.

val

[Omar Mussa]

(Note - from cross post on ni.com but since these issues keep coming up I re-posted here)

Just to point out a couple of OpenG feature that are highly overlooked:

• The source code is available, so it is possible to test OpenG libraries during the LabVIEW beta periods and prevent bugs from LabVIEW upgrades from getting their way into the OpenG libraries.
  
• OpenG library functions are all unit tested and the unit tests are also open source, so it is possible for anyone to both test and improve the quality of OpenG libraries by running/creating unit tests. The unit tests for OpenG have been one of the primary mechanisms for ensuring that the quality of OpenG code is really high. For example, the unit tests for the OpenG array library can be found here:http://opengtoolkit.svn.sourceforge.net/viewvc/opengtoolkit/trunk/array/tests/?s ortby=date
  

Note that the unit tests predate both JKI VI Tester and the NI Unit Test Framework, so the tests themselves are just VIs that have a pass/fail status (update: but there are plans to update them to utilize an existing unit test framework). Hopefully this helps anyone who cares about the quality of OpenG code (both developers including OpenG in their source and developers receiving code that depends on OpenG).

Also, the example code included a VI Package Configuration file (used by VIPM) that is used to download and install the specific OpenG libraries that the example depends on from the LabVIEW Tools Network, and instructions on how to apply the VI Package Configuration file. I personally don't see what additional transparency needs to exist in terms of notifying people what the example code depends on.

[Val Brown]

Omar,

I think I must not be explaining this process clearly enough. UNTIL I did the download AND stated to use the VIPC file, there was NO mention ANYWHERE that ANY OpenG tools/VIs/etc would be needed. There SHOULD have been some mention of the need for OpenG -- beyond VIPM itself -- somewhere in the documentation online, the printed materials for the "Hands On" session at NI Week, by the instructors, and on the BD of the main.vi. We used the code during the hands on session with no direct awareness that OpenG was being used.

Is that clear enough?

val

[jgcode]

I don't see a link to the cross thread anywhere (but I may of missed it) I have been following both, you can check it out here:

https://decibel.ni.com/content/docs/DOC-15014#comment-17129

Val - I am not sure from ur comment above about 'Crelf moving threads to here' - did u post on the cross thread? If so what is your alias?

Cheers

-JG

[Marcus J]

Hi Folks,

I think perhaps this discussion is in part related (or will be when I post my next comment) to an idea i have posted at LV idea exchange: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Add-a-Package-Manager-to-LabVIEW/idi-p/1670074 check it out.

Cheers,

/MArcus

[jgcode]

Hi Folks,

I think perhaps this discussion is in part related (or will be when I post my next comment) to an idea i have posted at LV idea exchange: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Add-a-Package-Manager-to-LabVIEW/idi-p/1670074 check it out.

Cheers,

/MArcus

A valid idea but I don't think it is related at all to this discussion. Even if NI 'owned' the package (or whatever) building and distribution software you would still have the same discussion happening.

JKI have done a fantastic job with VIPM, provide a very high level of support and have made package building available to everyone as, as of VIPM 2010 it is available in the Community Edition.

[Val Brown]

I'm drval both here and there. The original post was as a comment to the web article posted by Eli re: his OO example -- the example which was used in the NI Week hands on sessions about OO Design Patterns.