OpenG 4.0 Release Blog

[jgcode]

Hi All

This thread has been created to blog about information relating to the OpenG 4.0 Release.

It will contain what we did and why we choose to do it and anything else we find interesting.

Please feel free to add in any comments or feedback about the release.

I will just keep adding to this thread.

Cheers

Jonathon Green

OpenG Developer

[jgcode]

Upgrading to LabVIEW 2009

We decided to upgrade the sources to LabVIEW 2009 in an effort to keep OpenG current.

The great thing about packages is that if OpenG users are programming in an earlier LabVIEW version then the newest release, all previous releases will still work.

Upgrading allows OpenG to take advantage of new features as well as to unit test in a later version to increase quality and identify any issues early.

This is a standard progression as OpenG 3.0 migrated sources from 6.1 to 8.2 for the same reasons.

[jgcode]

Upgrading to VIPM 2010

This feature does not have a direct benefit to end-users of OpenG - but its dear to my heart as we sure spend a lot of time working on it - I learnt to appreciate the time it takes to make edits to an SVN Repo over the web

The driving force behind migrating from OpenG Package Builder (OGPB) to VIPM 2010 as the primary package building application was that package building is now available in VIPM 2010 Community Edition i.e. it is free!

This is huge in itself, but it now means that the OpenG package building process is a lot easier and will benefit from new features over time.

Don’t get me wrong, OGPB is a great product, has its use cases and OpenG currently still builds select packages using it, but this will make it easier for Developers join up and help out by using a familiar environment.

The OpenG projects' disk hierarchy was changed to better support the migration from OGPB to VIPM 2010 (where a project forms an individual release e.g. OpenG Application Control Library).

A lot of thought was given to this new layout so that the disk hierarchy can be scaled in the future and would also be easy to navigate for new Developers.

Additionally, older OGPB etc... support files have been cleaned-up and/or removed.

On a side note, changing from OGPB (which have .ogp file extensions) to VIPM (which have .vip file extensions) packages creates no problems as VIPM considers this an upgrade (as long as the file name has not changed and the version has increased) - this was a very important point in upgrading the packages.

So in summary, the transition was very manual, but its all done now, and adding to it is as simple as, so it was well worth the effort.

Check out an example of how we upgraded a project here on the OpenG Wiki.

[jgcode]

Using VIPM 2010's Custom Category Feature

One of the new features of VIPM 2010 is the Custom Category which, is an easy way to provide a top level category palette for a Toolkit (not just OpenG’s – but your own too!).

OpenG decided to use this awesome new feature however, it creates a consequence that I need to point out in case you come across it and think its a bug:

When an OpenG 4.0 package and an older package are installed together, two palettes will appear in the Functions (or Controls) palette.

Which would look something like this:

Being a neat freak this one annoys me but of course this does not create any functional issues - more aesthetic or organisational ones.

This is why the OpenG 4.0 release was synchronised.

The benefit of releasing Libraries in individual packages is well known however, to minimise this annoyance we released them all at the same time (assuming a lot of users would upgrade at once).

This issue was identified early on in the OpenG 4.0 process and we decided that we wanted to incorporate the Custom Category feature and that it would be better to handle it now, as we upgraded to VIPM 2010, rather than later.

Previously, the ogsrc_dynamicpalette.ogp package was a dependency of all OpenG Library packages and handled installing all menus etc...

Now, each package will create the top level category palette if it does not exist - or replace it if newer, making the ogsrc_dynamicpalette.ogp package redundant (with respect to OpenG 4.0).

Anyways, I really like the Custom Category feature

[jgcode]

All The Packages

Below is a list of all packages that have been updated that are part of the OpenG 4.0 Release:

• OpenG Application Control Library
• OpenG Array Library
• OpenG Boolean Library
• OpenG Buttons Library
• OpenG Comparison Library
• OpenG Dictionary Library
• OpenG Error Library
• OpenG File Library
• OpenG LabVIEW Data Library
• OpenG LabVIEW ZIP Library
• OpenG Large File Library
• OpenG MD5 Digest Library
• OpenG Message Queue Library
• OpenG Numeric Library
• OpenG Picture Library
• OpenG Port IO Library
• OpenG String Library
• OpenG Time Library
• OpenG Variant Configuration File Library
• OpenG Builder
• OpenG Toolkit

Note that OpenG LabVIEW ZIP Library, OpenG Port IO Library and OpenG Builder are the only packages not upgraded to and tested with LabVIEW 2009 as part of this release.
There are a few reasons for this relevant to each package therefore, the sources for these projects remain as per their previous release.
However, the palette location was required to be changed in order to be consistent with the OpenG 4.0 release.
As a result OpenG LabVIEW ZIP Library (oglib_lvzip) and OpenG Port IO Library (oglib_portio) versions' were both bumped up to 4.0.
OpenG Builder (ogrsc_builder) - not considered part of the OpenG Toolkit - was incremented using the Fix version number only.
It was also decided that some of the packages would be merged.
These were mainly palette only packages - don't worry i.e. this does not relink VIs or anything like that!
The following packages are redundant and have been merged as follows:

• ogmnu_appcontrol_plus is now available as a sub-palette in OpenG Application Control Library
• ogmnu_classic_sync is now available as a sub-palette in OpenG Message Queue Library
• nilib_rectangle is now available as a sub-palette in OpenG Picture Library

As mentioned in a previous post, ogsrc_dynamicpalette is also redundant.

One package was renamed in order for automatically generated palettes to be in alphabetically order - ogctl_buttons was renamed to oglib_buttons.

[jgcode]

Installation Issue - OpenG LabVIEW ZIP Library

As GregsSands pointed out here there is an issue with the OpenG LabVIEW Zip Library installing.

When you install the other Libraries, if OpenG LabVIEW ZIP Library installs with an error you have to re-install it again.

It is a known issue that I have reported here so I won't go into detail again other than to say that we are also looking for a workaround to fix it.

[jgcode]

We Fixed Bugs Too!

At the time of design we fixed all outstanding bugs in the Tracker for all packages.

We also made use of another new feature of VIPM 2010 - Release Notes.

Release Notes allows you can check out the upgrade in detail when you add the package in VIPM or when you popup and select Get Info on a package in the main window.

It includes the ability to easily track fixes via their SourceForge IDs - if you file OpenG bug reports this is similar to getting an NI CAR#.

[GregSands]

When you install the other Libraries, if OpenG LabVIEW ZIP Library installs with an error you have to re-install it again.

It is a known issue that I have reported here so I won't go into detail again other than to say that we are also looking for a workaround to fix it.

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.

[Jim Kring]

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.

[GregSands]

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 had oglib_lvdata v2.9-1 installed previously (along with all the other old oglibs). The other oglibs updated as dependencies of OpenG Toolkit, but the lvdata did not get touched - though it indicated an update was available so I could easily do it manually.

[Mads]

When I saw this release and the statement that all reported bugs had been fixed (including one described as a fix for custom decimal signs) I thought that the bug that prevents it from correctly interpreting floating point arrays in configuration files created on another machine with a different decimal sign had been solved as well, but that problem is still there, right?

I had hoped to be able to ditch my custom version of Read Key (Variant) that automatically detects what the decimal sign is in the file and adjusts the format specifier accordingly

Edited June 28, 2011 by Mads

[jgcode]

I had oglib_lvdata v2.9-1 installed previously (along with all the other old oglibs). The other oglibs updated as dependencies of OpenG Toolkit, but the lvdata did not get touched - though it indicated an update was available so I could easily do it manually.

Greg thanks for your feedback - much appreciated, it seems LabVIEW Data was missing from the dependencies of the OpenG Toolkit.

So I can do a fix for that and I will update the LVTN post too.

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.

****************************************************************************************************

Here is the OpenG Toolkit Package post updated for the above reasons

LVTN 'OpenG Toolkit' Package

One package you may or may not have seen is the OpenG Toolkit package.

Chris Bolin from NI was the original author and released v1.0.0.5 on the LabVIEW Tools Network (LVTN) as a way for new users to easily download the base OpenG Library - very clever.

OpenG has now extended this package and used it to allow a user to quickly configure their LabVIEW installation with OpenG 4.0.

This means that VIPM automatically installs the new packages and automatically removes the redundant ones, even handling the renamed oglib_buttons package - a clean way to handle things, and was the installation method I personally used.

Note that all older OpenG packages were uninstalled for the upgrade to work but we are going to try and fix this to make it better (watch this space).

The great thing about this is that anyone who clicks through the LVTN to download OpenG will automatically download the latest version.

Yeah, we're smart like that

****************************************************************************************************

When I saw this release and the statement that all reported bugs had been fixed (including one described as a fix for custom decimal signs) I thought that the bug that prevents it from correctly interpreting floating point arrays in configuration files created on another machine with a different decimal sign had been solved as well, but that problem is still there, right?

I had hoped to be able to ditch my custom version of Read Key (Variant) that automatically detects what the decimal sign is in the file and adjusts the format specifier accordingly

Hi Mads - what is the ID of this bug in the Tracker?

[Mads]

I see it was only added as a feature request so I guess that's why it has not been included:

http://forums.openg.org/index.php?showtopic=1117

Version 4 does not include the manual solution with a format specifier input on the read section or ini cluster either. However that would not be a good solution because then you would need to open the file and check what decimal sign is used in it prior to running the read * cluster function.

[jgcode]

I see it was only added as a feature request so I guess that's why it has not been included:

http://forums.openg....?showtopic=1117

Version 4 does not include the manual solution with a format specifier input on the read section or ini cluster either. However that would not be a good solution because then you would need to open the file and check what decimal sign is used in it prior to running the read * cluster function.

Thanks, there is a link in there which points it to the Feature Request Tracker (as opposed to the Bug Tracker), and the OpenG forum has your VI, I can follow up and post back in the near future.

The Bug Tracker was cleared in this update - but I need to find out some history on the FR Tracker (I am new here )

Cheers

-JG

[Jim Kring]

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 ">=")

[jgcode]

...the problem was that the OpenG Toolkit package didn't declare a dependency on OpenG LabVIEW Data Tools....

You can track this bug here: ID: 3386109

[Ton Plomp]

In the 4.0 release I miss the Rectangle package, is this by design?

Ton

[Val Brown]

In the 4.0 release I miss the Rectangle package, is this by design?

Ton

nilib_rectangle is now available as a sub-palette in OpenG Picture Library (from a post further up on this thread).

[Ton Plomp]

In the 4.0 release I miss the Rectangle package, is this by design?

nilib_rectangle is now available as a sub-palette in OpenG Picture Library (from a post further up on this thread).

Thanks!

[jgcode]

Thanks Val, yes that is correct.

Furthermore, nothing was removed in 4.x, in fact that was one of our design goals. Some things were shuffled though to leverage some awesome new features of VIPM (with no affect on relinking of course etc...).

Cheers

-JG

[jgcode]

You can track this bug here: ID: 3386109

This issue is fixed in the OpenG Toolkit 4.0.1.9 release.