jgcode

I think that an output name of 'MD5 Hash?' is better, if that's the case we should change the name of the function to 'Is an MD5 hash?'

I have taken this on board however, I checked with other similarly named LabVIEW primitives in e.g. Comparison palette - there is no is/an prefixing (hence I renamed the VIs).

Also added a noted about Hexadecimal String as I will be updating the MD5 Digest with a Hexadecimal String output as previously requested to compliment this VI.

Thoughts?

MD5 Hash.vi

TEST - MD5 Hash.vi

Code is in LabVIEW 2009.

What benefits are you looking for by storing the string data in binary files?

When reading this back in, we would have to assume that "Unnamed_Variable-1" is linked to "Cluster Element 2" and "Unnamed_Variable-2" is linked to "Cluster Element 3". Again this could possibly introduce a bug in your application.

Yer, at the moment I can only see negative connotations with introducing such a change.

I really think it is on the user to define unique names when using this API.

FWIW, section names can be specified using the API, so even if two clusters that the same name you can override this (that's how I like to do it personally).

(Also, Darren Rocks!!!)

I concur!

If anyone is interested here is Darren's suggestion implemented.

(It doesn't change functionality) but I am also one to try/learn new things/VIs

Thanks again D!

Check OpenG Library for Recursive VIs.vi

Code is in LabVIEW 2009

Another "major change" that may be worth considering at the same time is whether to put the OpenG packages into .lvlib libraries. Pros and cons?

Please keep this thread on topic.

But, by all means, create a new thread to discuss new ideas (other than moving to vi.lib)!!

In this case, this thread already exists here: Migration of OpenG Projects to LabVIEW Project Libraries?

Cheers

-JG

I am going to go ahead and close this topic as it already exists here: Migration of OpenG Projects to LabVIEW Project Libraries?

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 quickly wrote a tool using Traverse Refs (thanks D!) to scan the OpenG Library to discover CallBeRef node and if Re-entrant.

Here are the results:

Please comment if you think tool may have missed any VIs etc...

I can add these to DB to be fixed based on outcomes of this performance benefits discussion.

Check OpenG Library for Recursive VIs.vi

Code in LabVIEW 2009.

Labels are one of those things that--in my experience--developers tend to change without thinking too much. Writing algorithms that unnecessarily depends on label text causes brittle code.

FWIW, when I have to do this I like to use the following convention:

If the Label is red (BD and FP), its dependent so don't go changing it.

I think I copied it off someone after seeing it on LAVA (thanks to Olivier I think )

Other than that, thanks for dedicating the time to this

Likewise (to everyone who's posted too)

* "Is an MD5? returns TRUE if Input String represents an MD5 hash, otherwise it returns FALSE."

I changed everything else you mentioned but to be consistent I use the variable names so MD5? instead of Is an MD5?

Is an MD5.vi

TEST - Is an MD5.vi

Code is in LabVIEW 2009.

For a long time now, me and a couple other guys here have dreamed of being able to drop a "black terminal" which will literally take any type without coercion. I saw AQ's post when he first wrote it and I was excited to see that we're getting closer to having that feature. I wish I knew more about how it was written.

Well, lets get this party started then...

which is being handled very well IMHO given all that you've said.

The OpenG Board will make the final decision on changes related to the direction of OpenG, but by all means, everyone's opinions, ideas and feedback are very much welcome and respected - so please keep them coming.

Given the nature of the change, does it justify a "major" version increment?

I would think most definitely (this is just my personal opinion at the moment).

Great points, thanks for the feedback.

It also means anyone loading any of these VIs dynamically needs to update their code. This is, in many ways, a change that breaks backward compatibility.

If the user linked to the VIs correctly this will not be an issue (i.e. will not break any code).

There is a OpenG VI that defines the OpenG directory.

Therefore, for this move it is noted that:

• The OpenG Library VI will need to be updated
  
• Underlying sub folder structure will not change
  

You're going to be forcing a relink of any existing VIs that expect to find their subVIs in user.lib but now find them in vi.lib. That's going to be a source-code level change for caller VIs (updating their saved subVI paths).

This should be ok? Given that the user chooses to upgrade to the newer version, they will need to except that a recompile will be required. LabVIEW should handle this automatically (as reported earlier from my testing). However, we could even provide a VI to be downloaded that is an OpenG VI Tree containing all OpenG VIs so the user could open it first, then open their project code. The VI Tree will have the OpenG VIs in memory and LabVIEW will link to these on opening the user's code. (then they just do a save).

Does VIPM give you any way to give feedback to users about the effects of a particular upgrade at the time that they choose to upgrade? If so, you probably want to employ that mechanism.

Yes, we have been using that feature since switching to VIPM and will continue to do so.

As mentioned above, this would also be a major release e.g. v5).

Given that, I can imagine some people wanting to have both the user.lib and the vi.lib versions installed on the same LabVIEW. You could choose to not call this an upgrade but instead issue brand new packages, deprecating the ones in user.lib. That way people don't see these new versions as "upgrades" but actual new tools, which they would only adopt for new projects, and might continue to use the existing user.lib packages for existing projects.

I (personally) cannot think of a reason users would have both installed?

So I am thinking upgrades would be preferable for this.

You can track this bug here: ID: 3409853

What are people's thoughts on this (does it cover all use cases)?

Is an MD5.vi

TEST - Is an MD5.vi

Code in LabVIEW 2009

I used to use Riffle for this, but now I sometimes look for excuses to use the following since it is so darned cool:

http://forums.ni.com...light/true#M462

Can't help but feel like NI is taunting us though...

Now that you bought it up...

This has been on my radar as it sure would make distributing OpenG (and my own) Array code easier.

I checked and the idea exists on the IE, so I would really love to see Provide a Better Way to Implement a Polymorphic VI voted up enough to get enough visibility.

I like what AQ has posted and would love to see it in 2012.

What I really want to do is run a campaign for it like AQ and Darren did for Create SubVI From Selection.

Now, I just need to find some high profile devs to help promote it and make it happen...

I would like to see a tool/exe like this developed.

I've been using the OpenG Variant to Config VI to save clusters. It is a very nice function, but there are two issues which prevent it from being as useful as it could be. The first is that if I have a cluster with two identically-named items (stupid to do, but for argument's sake), one of the two values will not be saved. This is because the key in the key-value pair is the same in both cases, and so the second value with name "Variable" overwrites the first.

Doesn't having identically named values in a cluster cause you issues when developing?

Anyways, IMHO identical items should not be used.

One problem I can see with this is that INI files are designed so that order of the sections/keys in the file does not matter (hence the name-value paradigm).

E.g. If in the future, the first item was removed from your cluster, then on reading an existing config file, the API would now return the first item's value when reading the original second item, and therefore introduce a bug into your code.

Do you ever find yourself doing a whole bunch of extra programming just to avoid an "ugly solution" that was robust and really had nothing wrong with it, but it just bothered you so much you put in the extra work for something "cleaner"?

Yes I do sometimes, but I always consider the lifetime of the code/application and what the trade-offs are (e.g. doing it now vs later etc...).

So, to summarize, the majority of users would support this move (and that we would do it atomically all in one release avialable at the same time)?

Hi Guys

These are the latest I have saved on my HDD

oglib_openg_object-1.0beta4-1.ogp

ogrsc_active_obj_tmpl-1.0beta1-1.ogp

ogrsc_pure_abstract_ref_class_tmpl-1.0beta1-1.ogp

ogrsc_ref_obj_tmpl-1.0beta1-1.ogp

ogrsc_val_obj_tmpl-1.0beta2-1.ogp

...a dependency map of OpenG packages?

This is something I have played with in the past with my reuse library in LabVIEW where VIs represent packages and I link them and then use the VI Heirarchy window to view it.

If VIPM had that feature it would be really cool. But it's probably heaps of work for a little used feature.

I didn't here a reason why not to move to vi.lib (except for Chris's reasoning about manpower), so I guess it's save to go for the move. However we should go package by package, is there anybody that has a dependency map of OpenG packages?

I disagree - I think it would be easier for end users and OpenG developers if all packages are rolled out at once (like we did for v4.0).

...but the execution of a mixed-case regular expression suffers ~20% performance penalty in some brief benchmarks.

No, i was thinking that the flag would select the correct RegEx string to use in the MP primitive. So overhead should be negligible.

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

Cool.

In the context of the email I sent, 'donated' referred to if OpenG would maintain the library (upgraded, fixes etc...), if e.g. the author preferred this.