jgcode

In summary:

• Add this VI to OpenG
  
• Move to MD5 package
  
• Allow non-strict capitalization
  
• Implement code similar to this:
  

With the non-strict capitalization issue, could an optional Boolean flag called "Strict Capitalization" (default = F) be added to the interface?

Would that be a good feature to have?

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

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

I will close this thread and reject this inclusion into OpenG.

(Thumbs up for the extensive document).

How would this work for legacy packages?

One of the requirements is that you have a 'lava-compliant'-namespace.

That's quite hard for the Code Capture Tool with an allready existing API.

Ton

I am sure we can work this out - I would love to see CCT on LVTN thru LAVA

With flexibility mind - can you conform to everything else bar VI namespacing?

If namespacing was maintained, but was in a LAVA version you 'may' have some relinking to the new folder location but LabVIEW 'may' handle this automatically (like I tested for OpenG -in the moving to vi.lib? thread). Can you test it and report back?

With the LAVA package name, you can just have a conflict with the current CCT version so it uninstalls automatically.

Thoughts?

This Article outlines the Requirements and Recommendations for publishing code through LAVA onto the LabVIEW Tools Network. My Package is used as an example in throughout this Article.

Requirements

Installation Type

Code must be distributed as a package (.vip or .ogp). This will mean it is compatible with both the LabVIEW Tools Network and VIPM

Installation Directories

Installation directories have been standardized for the purpose of organisation and avoiding namespace clashes etc.

No package released on LAVA, in the LAVA-CR or elsewhere should install to these locations - only those packages that are approved by LAVA for the LabVIEW Tools Network

Once your package has been accepted, you will own that namespace and can install to other locations (if haven't already) in the future (think of it like a domain) without worry of collisions

Palettes: <vi.lib>\LAVA<\package_name>

Tools: <project>\LAVA\<package_name>

Examples VIs: <examples>\LAVA\<package_name>

Examples .bin3 files: <examples>\exbins

Addons^#: <vi.lib>\addons\_LAVA\<package_name>

^# Not for distributions that contain public VIs (i.e. VIs appear in palette or need to be linked to by end users)

Package and Palette Namespacing

Example package names will be lava_<type>_<my_package>-<version>

Where type = lib for Libraries and type=rsc for Resouces/Tools

E.g. lava_lib_my_package-1.0.0.1.vip

In VIPM the package name is directly related to the palette name

We require packages to be ordered alphabetically in the dynamic palette hence, the above convention must be followed

Additionally, if using OpenG Package Builder, palette name must match the equivalent VIPM name

VI Namespacing

It is recommended that VIs should be namespaced similar to old school VIPM renaming syntax (e.g. __lava_lib_<package_name> however, at a minimum __lava should be used

If a LabVIEW Project Library is used to namespace code instead, then add __lava namespace to the distributed library

Palette Location

Both .ogp and .vip packages that contain palette VIs will link to the LAVA Palette package as a dependency which is published on the LabVIEW Tools Network.

The palette must appear under the Addons\LAVA top level palette however, users may wish to include another palette under the correct programming sub-palette.

The VIPM Custom Category feature is currently not used

Dependencies

Any package dependencies must be also published on the LabVIEW Tools Network (aka external dependencies). Packages (especially Tools) should try to limit all dependencies by building in supporting VIs to the package (aka internal dependencies)

Coding Standards

The code distributed must meet the requirements of being LAVA Certified. Additionally you should follow the LabVIEW Development Guidelines and the standards for the Compatible with LabVIEW level that you ultimately want to achieve

Recommendations

Iconography

We recommend you use any color, glyphs, text etc... for your icons. There is no set theme or icons - we don't want to stifle your creativity!

License

We recommend that you distribute under the most flexible license to aid in end user reuse (e.g. new-BSD license), but there is no licensing requirement - only that you have one

It is recommended that this license is Open Source Initiative approved

Adding a License Agreement file is also recommended (but this requires VIPM Professional)

Premium Membership

It would be helpful if members maintained Premium Member status so they can edit and delete posts etc... to maintain their forum professionally

However, if not, we will open up this functionality for Team LAVA Developers

Folder Naming

Excluding Tools location, it is recommended that the folder name is package_name note: lower case and contains underscores for space

E.g. <LabVIEW>\vi.lib\LAVA\my_package

Click here to view the article

I have found one really interesting link about error management.

http://zone.ni.com/d...a/epd/p/id/6253

Eric

Elijah Kerry has blogged about that one a bit.

I have moved this thread to pending.

If not many are interested I will close this in the near future and reject this proposal.

Build a class with creator method(s) and getters but don't provide any setters. Once the object (not class) is created it is immutable and can only be read.

Thx, I do this but didn't know it had a name.

You are probably right, but I still think there should be a OpenG tool that can create a listing of all OpenG modules and their licencing with a default layout. If you want to change the default layout, use an API to build your own.

For most people that would be enough, but the point is that they will at least be able to correctly give credit to OpenG.

Regarding performance, I don't think that is an issue, we have used a tool to scan pretty big projects for specific strings, and that completed in very short time.

/J

I haven't benchmarked it personally, so I cannot comment there, as I am just gathering requirements for this project (if it goes ahead).

I see the use case that the OpenG copyright will be integrated with other copyrights, so I don't see the value in create a single screen etc... just for OpenG.

What do others think?

renaming a global breaks all the references. A minor annoyance to be sure, but an annoyance nonetheless.

There is a (not very popular) idea to fix this issue here (I would like to see it fixed regardless as, yes, it is annoying).

I would like to have this as an option, i.e. to have the licence information available in the RunTime.

Since most of the licencing states that you have to give credits where it is due, this would be an easy way of including all this licencing text, and never forget a toolkit.

/J

The only thing that concerns with this is that the operation may take a while to complete in very large projects, plus information could be missing.

I would rather have a tool where I can parse the information and format it the way I like in the IDE, then its simply a matter of displaying it to the user in the app.

If the formatting was done in code, I could always just run the tool then re-run the formatting code when I needed to update the license.

I think this would be better?

This may have been less alarming but I don't know.

I would be inclined to say no based on the fact this already has a meaning.

Therefore if you saw it in RTE is it actually the ultimate ancestor or is it a class with its icon stripped?

Least I know what the ? means now....

The project is (hopefully) a series of well-defined components

As you mention, if you implement a constant then you can easily decouple that from your code by passing the data by wire from the application to the modules etc...

At the end of the day if you want to update the constant you only want to do it one spot, I can't see a difference between subVI and global in that regard, unless you wanted to add the constant to a re-use library then yes, subVI would be easier/more-common.

Maybe it does come down to expectations....

My question... why would you ever want to test if a string looks like it is a md5 string?

Most likely for data validation.

Of course the main reason for the review is verify whether this would be a useful function (and then how to implement it, if it is useful).

• Should it be rejected?
  

So, please continue to let us know either way.

I would really like to have a OpenG tool that can scan and create a Licence information file, perhaps also open a Licence dialog.

A tool like this would depend on that the licence information is intact even after a we build an application (where BD's and perhaps FP's are removed)?

/J

Hi Jonas

Can you please clarify - are you saying you would like this tool to run in the Run Time Environment and it would popup a dialog showing the license information after having scanned the VIs for that information?

Cheers

-JG

Anyone interested in this functionality? Please give feedback.

Hey JG, related to the question of location in the LabVIEW hierarchy I guess that you need to think about the palette location. National Instruments ask us to move our toolkits from custom SAPHIR palette to existing category (i.e Connectivity, Data communication...) for future LV2012 Compatible for LabVIEW program. Other possible place could be Add-ons palette if you want to keep VIs in OpenG palette.

Olivier

Hi Olivier

Thanks for the hot tip - can you go into details about these changes for 2012?

I will head over to that NI Group also and see what I can find out.

At the moment VIPM handles generation of Top Level Menus using the Custom Category feature, so any changes to NI protocols I assume will be reflected in VIPM.

The good thing is, palette and disk hierarchy are not always related, which is the case with OpenG, so palette location would not affect a move to vi.lib (as long as everything is configured to point to the new location etc... of course).

Can anyone else comment on CC license with respect to LabVIEW?

I see the LAVA-CR allows CC license for submissions.

Indeed, globals are just SO EASY. But I dislike doing that because you never know when one of these VIs will end up in a tight loop once your code gets refactored for the umpteenth time.

If its a constant then its never going to change - refactor it out and pass by wire into the loop.

No probs.

You could make sections of code optional.

-George

You are still going to get an error Opening a reference to the Task if the device is not on the network.

You would have to disable the entire workflow (Open, Read, Close resources) if you wanted to to that.

Cheers

-JG

I am down with Tim_S here, IMO that's a perfect use case for Global Variables - why? because anything else (FGV, MAPs) seems like much too hard work.

I took this lead from Darren, for your use case he calls them WNRM Globals.

The cool this is that the Global acts like a config screen for developers in edit time - I find that handy.

You can even scope them if required.

You just have to get past that feeling that they are icky to use

Otherwise if it is a constant I will reuse - I will create a VI so I can mine it later for reuse.

The way I see it, if it was done - the End User should install all the latest packages so the entire Library is in vi.lib (which would be in the current version e.g. LabVIEW 2009).

As for manually installing the code, I don't know, OpenG is designed to be installed using VIPM, if someone is doing some custom install I don't think we can handle all those use cases - I guess the End User would have to do what's necessary to maintain the installation then.

In terms of your example above, I would not recommend having two versions of any code installed under <LabVIEW> just for the possibility of linking to the wrong code. VIPM only allows one version of the code to be installed e.g. A v1 or A v2 - assuming of course that in your workflow you would never create two separate package streams (e.g. A v1 and B v1) with code of the same names etc..

This recommendation might be of interest. Specifically if a generation VI is created, all bits are not random (section 4.1).

Just from quickly browsing the doc, is that was jcarmody has done (or similar) in his screenshot?