Jim Kring

There are some OpenG VIs, like the Variant Configuration File IO VIs, that use the legacy form of recursion (VI Server Call By Reference to self), which is (I believe) much less efficient than using the native recursion feature introduced in LabVIEW 2009. I would recommend changing all VIs that use legacy recursion to use native recursion, provided that a performance improvement would be gained.

Here's a screenshot, showing what I mean:

I would definitely call this a bug. How I typically deal with such things is to create an argument called "in recursive call?" and warn the user to leave it unwired, but wire up a TRUE whenever calling it recursively. If this input needs to be hidden (which is probably a good idea), then the actual recursive VI can be moved into a private subVI with the public VI being a thin wrapper around the private, recursive subVI that only passes through all the inputs/outputs (except for the private "in recursive call?" input).

What are the use cases for choosing random elements in an array?

Personally, I've only had to do this once, and it was in an NIWeek coding challenge about 6 years ago

Just thinking.... could this be further generalized to a function that chooses a random integer between two ranges (for example an array element index between 0 and Length - 1)? Maybe it would be good to add such general purpose functionality to the OpenG Random Number within Range (adding the ability to work with integers), as opposed to the more specific use case of choosing random elements in an array.

I thought it couldn't hurt, so I have gone ahead and tried to ontact the author and see if the code could be donated to OpenG etc... (given that Library is no longer available and it was released as Open Source).

Well, technically, it doesn't need to be "donated" to OpenG, it just needs to be released under a BSD license, so that OpenG can distribute it -- that's the (semantic) difference between ownership (copyright) and rights (license)?

AQ,

Great points. Windows/OS permissions are a very important consideration.

My thoughts are that OpenG should probably follow suite with the official standard, since I believe that both NI and JKI will be working hard to solve this problem for everyone. For example, stuff that is installed by VIPM could be done so with special permissions (signature) granted by NI.

If there is a VI that creates a GUID, it's a good thing to have.

So is there a VI that will do this in string package?

//Mike

If that is VI that you would like too see (currently does not exist) in OpenG then we can definitely look at this?

Community, please comment on the addition of such a VI to OpenG as well in this thread (in relation to the attached VI).

Cheers

-JG

I'm really in favor of creating OpenG functions for Create GUID and Is a GUID. Enrique Vargas contributed the MD5 code to OpenG, which was part of the CryptoG library -- I know that there's a function in there for creating a GUID with a pseudo-random generator via SHA functions.

-Jim

Playing devil's advocate: What are the common scenarios for testing whether the length of two strings are equal?

This looks like an interesting idea. Playing devil's advocate:

Are there any examples of similar functions in other programming languages/libraries? (if there are a lot of other languages that have a similar function, then it's probably indicative of it having a lot of use cases)

What are some common use cases for such a function?

Hi All,

I'm very friendly to moving OpenG into vi.lib in order to conform with NI's new standards for add-ons (and I don't see any obvious show stoppers). There are various reasons to do this (in terms of how LabVIEW gives vi.lib some special treatment not given to user.lib), in addition to the fact that it's a standard (which are probably the reasons for the standard). That said, we should consider all the possible negative impacts of the move to vi.lib and figure out their significance and ways to mitigate the problems. One possible negative impact I can think of is: any VIs that might have a hard-coded path to call these VIs by reference (low probability).

Regarding adding tools into the existing palette categories, this is an idea that JKI is currently (in the early stages of) discussing with NI, since it will involve the adoption of some new standards. The JKI team has some ideas that need to be put down onto (electronic) paper as a functional spec proposal. I'm just mentioning this, since I think that OpenG (and others like SAPHIR) would benefit from this, so I want you all to bug me/JKI about it later/often

Do you think this is something that the developer editing the VI can document and maintain when they make changes to the VI?

I think that the update of this information could very easily be automated during the build process.

What if there were a special package that OpenG Developers had installed that included a dialog for editing these tags and performing other, similar/related activities?

What are the use cases for removing non-printable characters? How do non-printable characters get into a string? Why would one want them removed? Is this common in string operations, or is it more focused to a specific problem/application domain?

I'll chime in, since I spearheaded an OpenG license transition process once before

I like the current (new BSD) license used by OpenG. Also, it's pretty tough to change to a new license since it (most of the time) requires the consent of all the original authors.

Regarding how we document the licensing information, I think that the following might work:

- Each VI could clearly state which package it belongs to and how it is licensed (e.g. "This VI is a member of the OpenG Array Tools 4.1 package and is licensed under the BSD license. Please see the VI description and VI Package description for more information."). This gives the average user some kind of breadcrumb that they can use to figure out the license details.

- The package itself could contain details about the license, authors, etc.

- The VI could create, in tags, a list of authors.

Consideration:

- It's helpful to have the VI name in the license agreement somewhere, to give the user an indication of where the VI came from, if it's name is changed in order to make a derivative work. For example, sometimes I'll rename an OpenG VI and make some tweaks to it. It's helpful to be able to see the original VI name and version information, so that if I want to contribute my changes back into OpenG (or pull new changes from OpenG into my derivative work), then I can.

That's some nice looking code!

@Jon: This is a great plan. I think that breaking things out into separate review threads/topics for each proposed change will let people contribute as they have time. Also, if people make a significant contribution, we should be sure to include them in the copyright notice, so they receive credit for helping. Another thought is that it would be helpful if the original post gets updated with status and decisions, so that people know what stage in the process things are at. For example, after the review process is over, it should be obvious that that review/comments period for a given proposal has ended.

A few thoughts on performance benchmarking (which is a pretty tricky thing):

1) In addition to performing a short operation thousands of times and averaging, I like to keep track of the fastest time over some period (run continuously and then stop when I see the time settle) -- the fastest time is more representative of it's true performance capabilities.

Trim Test - Fastest.zip

2) Care should also be taken to use appropriate test vectors and compare performance for each class of vector. For example:

• Small strings vs. Large strings
  
• Mixed whitespace vs most common whitespace
  

I think it's important that the code be optimized for the most common scenarios (a few space "\s" characters at the head and tail, and probably some EOLs at the tail). So, if there are design choices that affect performance (like the order of characters in the whitespace array being searched), then we should lean toward those.

Regards,

-Jim

Hey Jon,

Thanks for posting this design change for review.

A couple questions:

A) Do users often need to "Remove non-printable characters (False)" -- is this a common use case?

B) Does it add much value to couple the removal of non-printable characters to the trimming of leading/trailing whitespace? (For example, do users often need to perform these operations together?)

It seems to me that if the answers to these questions aren't an overwhelming "YES" (in all caps , then removal of non-printable characters should be decoupled from Trim Whitespace, since decoupling orthogonal functionality tends to make the software more maintainable, understandable, testable, etc. If the decision is to decouple them, then maybe it makes sense to add a new function called Remove Non-printable Characters.

Regards,

-Jim

I love the new site -- simple and clean design. More LAVA, less blabla.

Unfortunately, the OpenG Toolkit package doesn't specify that it's incompatible with old versions of the dependency packages, so it won't upgrade them if they are already installed.

I think I have a workaround for that - VIPM does not allow you to specific a relationship with incompatible packages in that direction:

However, we could make the value of the dependency packages comparison operator to be equal:

Which forces an upgrade - if this is what we want to do? (ignore portio in screenshot, I snapped this before I had finished):

I will ping you offline to discuss further.

I think my statement was wrong -- the problem was that the OpenG Toolkit package didn't declare a dependency on OpenG LabVIEW Data Tools. Changing the dependency comparitor from ">=" to "=" created new problems (like the fact that newer versions of the dependencies won't be compatible, anymore -- we need it to be ">=")

Thanks for that. Did you also notice that the OpenG LabVIEW Data Library is not installing with the full toolkit? It's easy to do by upgrading the old lvdata manually, but I imagine it should be part of the standard install.

Greg. Was an older version of the OpenG LabVIEW Data Library already installed? Unfortunately, the OpenG Toolkit package doesn't specify that it's incompatible with old versions of the dependency packages, so it won't upgrade them if they are already installed.

I want to give a huge kudos to Jon Green (jgcode) for spearheading the OpenG 4.0 Release. Jon did an incredible amount of work, while I mostly tried to keep out of his way.

This is an exciting release, since a majority of the work was spent trying to make it easier for OpenG Developers to make improvements to (and release new) packages, in the future.

Great work, Jon!

Hey Doug,

Here's the scoop. When OpenG Builder is run for the first time, it "mass compiles" itself and does a little extra trick where it creates its own copy of some VI's that it calls, which are found inside vi.lib (it does this, so that it's VI hierarchy doesn't share any VIs with the end user's LabVIEW projects that OpenG Builder is building into EXEs or Source Distributions). So, you probably looked inside ogb_NI.llb and found nothing, because you hadn't run OpenG Builder yet (and it hadn't copied this file for itself, yet), and then you looked again after this had occurred and then you found the file.

Something to note: You should never directly call VIs that you find under the "<LabVIEW>\resource" unless you have a really good reason to do so, and really know what you're doing (since there are a ton of caveats -- if I sound emphatic, it's because it's an issue that's caused me some pain). Also, these VIs called by OpenG Builder are not intended to be called by end users -- those all get put under vi.lib or user.lib. These resource VIs are internal stuff that are called by OpenG Builder. And, if they disappear, please don't be surprised (since these are basically private functions, and might someday even be made private using LVLIBs so that users don't accidentally call them).

That said, if you see a VI you like, copy it into your project and use it

Hopefully, that clears things up and leaves you with fewer questions than you started with

Cheers,

-Jim

Hey everyone,

I have a fairly simple problem and I hope the solution is just as such. I am on a proxy server and I am currently waiting to here back from the IT department about setting up VIPM with a proxy server. I am not 100% sure if they will allow it. One of the projects we have here depends on one of the VIs in the OpenG library (Temporary Filename__ogtk.vi). I have contacted NI and they gave me a link that has a lot of the user libraries on an FTP ( ftp://ftp.ni.com/evaluation/labview/lvtn/vipm/packages/ ) and it has the OpenG library included, but it is dependent on connecting to the internet to install the full library. I was wondering if anyone had a link where I can directly download the libraries.

Thank you very much,

Seth

Hey Seth,

Check out this page for some info about getting VIPM working with a proxy:

• how-do-i-configure-vipm-to-use-a-proxy-server

Regarding the "Temporary Filename__ogtk.vi", this is located in the OpenG File library.

You can get the latest version of this library, here:

• http://sourceforge.net/projects/opengtoolkit/files/lib_file/

Or, you can get the sources, here:

• https://opengtoolkit.svn.sourceforge.net/svnroot/opengtoolkit/trunk/file/source/library/

-Jim

Hi Yair,

Ya, objects really aren't supported well at this time. I'd love for the OpenG team to consider adding support, and I'm sure there are some fun things we'd all learn in the process.

In the mean-time, you might consider flattening the object and writing that to file or have a VI that converts the object to some data cluster that can be persisted.

-Jim

Hello LabVIEW Community.

I'm gathering some research and would like to know the following:

1. Do you use LabVIEW Snippets?

2. How often do you create new snippets?

3. How do you organize your snippets?

Just general answers. I'm just getting a feel for how the community is using this feature.

Thank you in advance.

Ryan

Hey Ryan,

I use VI Snippets for posting examples on the web. I also like to send them to my colleagues via skype (send file), occasionally, when I'm trying explain how to do something.

I do not ever save my snippets -- I don't consider them to be reusable code.

-Jim

Or is the bug the behaviour of the actual 'Replace' action?

I can see how the fix could be the default behaviour for 'Replace'! (or is it a big no-no in computer science)

Ton

I'm not sure if I agree with changing the default behavior of "replace". I can see how this would change the behavior of some people's applications who already rely on the fact that "replace" also replaces all of the permissions/ownership settings of a file.