General questions regarding OpenG continued development/bugfixes

[David Boyd]

Not sure whether I should post here, or on the developers' forum... so here goes...

 

I've used parts of the OpenG tools for a number of years, particularly the data tools, string, and variant config packages.  Recently I've taken to modifying a few VIs and typedefs and carefully segregating out the modified bits.  The specific modification I'd like to discuss was the inclusion of support within the variant and string routines for fixed-point datatype.  (I have a concise list of the changes needed to support FXP.)

 

So, first question: are any of the members of the OpenG developers' community planning to officially roll this in?  I saw it brought up as a request (perhaps informally) over a year ago.

 

Second question - if I have identified what I feel is a bug/incorrect behavior, to whom do I direct the description?  I've found some inelegancies with how the Scan Variant from String VI behaves with enums, and have a proposed fix.  Any takers?

 

Thanks,

Dave

[Rolf Kalbermatter]

Not sure whether I should post here, or on the developers' forum... so here goes...

 

I've used parts of the OpenG tools for a number of years, particularly the data tools, string, and variant config packages.  Recently I've taken to modifying a few VIs and typedefs and carefully segregating out the modified bits.  The specific modification I'd like to discuss was the inclusion of support within the variant and string routines for fixed-point datatype.  (I have a concise list of the changes needed to support FXP.)

 

So, first question: are any of the members of the OpenG developers' community planning to officially roll this in?  I saw it brought up as a request (perhaps informally) over a year ago.

 

Second question - if I have identified what I feel is a bug/incorrect behavior, to whom do I direct the description?  I've found some inelegancies with how the Scan Variant from String VI behaves with enums, and have a proposed fix.  Any takers?

 

Thanks,

Dave

 

I think the best approach is to actually post your proposed fix here for discussion. There will usually be some discussion about it and if it is considered useful and also doesn't break existing applications significantly, it is quite likely that it gets included in the next release, whenever that might be. But significant improvements to the code as it is in the sourceforge repository certainly warrant the effort to go through the hassles of releasing a new package.

 

Unfortunately the current procedure about who does a new release is a bit unclear. I lack the detailed knowledge about the actual release procedures and also the time to commit to doing this on a regular base. Jonathan Green did a great job in releasing new packages when there was something to release but his focus has been shifting to other areas lately, which is unfortunate but of course his full right. But getting the discussion started about a proposed fix is for sure the first step anyways.

[Mads]

The array functions were subject to a lot of discussion and rework here on LAVA in this thread back in 2012:

 

http://lavag.org/topic/15980-openg-filter-array-revised/

 

At the time I was quite eager to get the improvements included in the official OpenG release. I made a complete replacement of the existing array library, back-saved it to 2011 and posted it there...but I could not see a way forward from there so I asked a question similar to yours on that thread.

 

Ton then sent me a PM though asking me to recompile everything back to LV 2009, sign up on SourceForge, and send my SF ID to Jim or Jonathon. I got around to do the sign-up, sent the ID, did not hear anything at first, and then things got hectic at work so I dropped the ball. I've never picked it up since.

 

Ideally it would be simpler to contribute, and the path to do so could be clearer. In the mentioned case I wished there was a way to just hand off the 2011 code to someone who would then do the boring tasks involved in getting an update released...But that's just not the case (at least that is my impression), and I'm not blaming anyone for it.

Edited October 4, 2013 by Mads

[David Boyd]

So, if I created an ID on SourceForge, I could check in my updates, as long as I did the work in... LV2009?  (Is that the backmost version currently still supported?)

 

And then those in charge could accept those changes for a future release, or modify, or reject/rollback?

 

Meantime, if I posted here the textual description of changes, it would garner some attention and hopefully provoke a discussion?

 

Does that sound like the proper way forward?

 

Thanks for the replies.

 

Dave

[Rolf Kalbermatter]

The sourceforge repository for OpenG uses SVN which does not have pull and push requests like GIT. So the administrator of the OpenG Toolkit project, which I believe is still Jim Kring, would have to add your sourceforge ID to the project before you can actually commit anything to it. Anyone with commit rights can change anything about the OpenG Toolkit so it is not a right that everybody out there should have.

 

In general it is anyhow preferable to have some discussion beforehand about proposed changes before committing anything to the repository.

[David Boyd]

Here are my notes for modifying OpenG LabVIEW Data, String, and VariantConfig to support FXP.  I did this originally to support FXPs in structures populated from INI files.  I am not certain of what other packages have lv_data as a dependency that might also be affected.

 

_OpenG.liblvdatalvdata.llbType Descriptor Enumeration__ogtk.ctl:- change value 0x5F to "FXP"propagate type changes_OpenG.liblvdatalvdata.llbGet Data Name from TD__ogtk.vi:add case "FXP" (as dupe of case "I8".."CXT", "Boolean", "Variant")change Pstring offset from 4 to 36_OpenG.libstringstring.llbFormat Variant Into String__ogtk.vi:add "FXP" to existing case  "SGL".."EXT"_OpenG.libstringstring.llbScan Variant from String__ogtk.vi;add "FXP" to existing case  "SGL".."EXT"_OpenG.libvariantconfigvariantconfig.llbWrite Key (Variant)__ogtk.vi:add FXP to existing case  "SGL".."CXT", "SGL PQ".."CXT PQ"and do same modification for internal case structure under case "array"_OpenG.libvariantconfigvariantconfig.llbRead Key (Variant)__ogtk.vi:add "FXP" to existing case  "SGL".."EXT"and under "Array" case, add "FXP" to case  "I8".."I32", "U8".."U32", "SGL".."EXT", "SGL PQ".."EXT PQ"and under *that* case, add "FXP" to case "DBL", "DBL PQ"

 

 

I have a separate change to Scan Variant From String__ogtk.vi, to fix the aforementioned problem with scanning into an enum.  To match the behavior of the 'Scan From String' primitive, I find it necessary to do the following:

 

1) Get Strings From Enum__ogtk

2) sort string array by string length (max to min)

3) use Match First String (therefore, the maximal match)

4) Set Enum String Value__ogtk with string at resultant index

 

I'm not at all sure this is the most efficient method.  But the existing code in Scan Variant From String__ogtk fails for matching enums with embedded whitespace, and may have other issues as well when an enum' strings share common initial character patterns.

 

I don't seem to be set up to get timely alerts from LAVA by email when someone posts a reply.  If anyone wants to follow up directly, please drop me an email.  I'll try to fix the alert thing in the meantime.

 

Best regards,

Dave

[Michael Aivaliotis]

Please keep all OpenG discussions on these forums and not in offline email discussions.

[David Boyd]

Michael: so noted, will do.

 

I just created an account on SF (as respdave).  Also noted in the OpenG buglist here that Jim McNally reported the enum-to-Scan Variant From String issue just a few months back.  I'll try to post my proposed fix here shortly so others can evaluate it.

 

Should I switch this to the 'Developers' forum at this point?  Also: I've eliminated LV2009 from my work machine, my oldest installation is 2011.  Do I need to back-save to 2009 for discussion/review purposes?

Dave

[Rolf Kalbermatter]

Michael: so noted, will do.

 

I just created an account on SF (as respdave).  Also noted in the OpenG buglist here that Jim McNally reported the enum-to-Scan Variant From String issue just a few months back.  I'll try to post my proposed fix here shortly so others can evaluate it.

 

Should I switch this to the 'Developers' forum at this point?  Also: I've eliminated LV2009 from my work machine, my oldest installation is 2011.  Do I need to back-save to 2009 for discussion/review purposes?

Dave

 

While the minimum version for OpenG submission is still currently 2009, I think it is ok to place code for discussion in a newer version, if it is not just the latest and greatest. 2011 would seem like a very workable version for almost anyone here.

[David Boyd]

Attached is the existing code for Scan Variant to String_ogtk and a proposed alternative/fix to the enum case.

 

[Jim Kring]

Hi David,

 

I'll work with you to get this proposed fix through the process!

 

-Jim

[Mads]

Any chance the updated array functions could be evaluated/included as well? The new Delete Array Elements functions for example can deliver a 100X speed increase compared to the existing ones.

[Jim Kring]

Any chance the updated array functions could be evaluated/included as well? The new Delete Array Elements functions for example can deliver a 100X speed increase compared to the existing ones.

 

Hey Mads, If you're interested in looking into this and making some specific recommendations, I'd be happy to consider them for inclusion.

[David Boyd]

Just so I don't run afoul of Michael, a summary:

I have been in touch with Jim by email. With his help I got set up with TortoiseSVN and have pulled down the OpenG string source, for starters. I plan to update Scan Variant into String per the code above (but not with the FXP support, just yet) and include some new vectors in the test harness for enums (at present there are none).

Beyond this string fix, I'd like to add FXP to the known types in lvdata, but that will propagate through string and variantconfig and perhaps others. I suppose if Mads wants to take on the array package changes we can all get what we want in a pretty comprehensive set of new releases. And Jim told me he's cool with moving OpenG up to LV2011. It's good to know that OpenG still gets support!

Dave

[Mads]

Hey Mads, If you're interested in looking into this and making some specific recommendations, I'd be happy to consider them for inclusion.

 

The recommendations (from myself and others) were all covered in this thread: http://lavag.org/topic/15980-openg-filter-array-revised/

 

I summarized the recommended changes in this file.  Not all the VIs in the library were changed, but most of the ones that repeatedly resize the arrays were modified to reduce the memory footprint and increase the speed.