How to contribute to OpenG Package

[eisenwr]

Maybe a newbie question, but how does someone help contribute items to the packages? I have few VIs that I believe to be useful enough that should be out for everyone to use. How would I go about doing that?

Thanks

[eisenwr]

Bueller, anyone, Bueller?!?

[LogMAN]

I think the lack of feedback is caused by general confusion about the status quo. I'm sure many people still use the library, though there haven't been any update since 2011: https://sourceforge.net/projects/opengtoolkit/ <= Also that is the right spot for your changes

The project is open source, so if you are really committed to get involved, this is what I think you should do:

1. Contact the admins over at SourceForge to either merge your changes or grant you write access.

2. In case you get no reply within say... one or two month, consider the project abandoned and fork it. (you are not limited to SourceForge, use the platform that is to your liking)

I think there are a couple of people here at LavaG that would participate in the project if someone would just start being active and committed to the project again.

[Rolf Kalbermatter]

What LogMan already said. Most people who were active in OpenG have moved on, either into other non-LabVIEW related work, or more into management where the daily coding has been replaced by other tasks that don't involve as much direct LabVIEW programming anymore. There are still some watching the list and trying to keep up with the things that are OpenG related, but other paid work usually takes precedence before something like OpenG. Also many have families now, so when away from work and at home, they often spend their time other than behind the computer.

The canonical code repository for all OpenG related stuff has been and still is on https://sourceforge.net/projects/opengtoolkit/. Look for the SVN repository, the CVS repository is an old version of the Toolkit before sourcforge supported SVN. However while there haven't been any new packages released since 2011, I still am actively working on some of the pet projects that are mine. Mainly the lvzip library and to a lesser extend the lvpipe and labpython library. I also have committed one or two other bug fixes to other libraries in the past, that users have posted here, but didn't go through the trouble to release a new package for them as there were in fact other areas that I would have liked to improve on for those packages, but with absolutely no other feedback in those years, it does also feel a little bit like pulling a dead horse. 

While I have been a member from the beginning on sourceforge and still am, I do not believe that I have administrative privileges to add other developers to it. And I don't think it is very common to just add random people to open source projects without a little track report of commitment and code style by them. So the best approach would be in my opinion to try to post some improvements here in this subforum. If they look reasonable, I'm willing to commit them to the repository with proper credit. After a few such patches I think we could convince the project admins to add that person with commit access to the repository. Adding new code to the repository is however only half of the work. You also then have to create a new OpenG or VIPM package of the library and then get the people from JKI to update the list of available packages on their servers, so that VIPM can show them properly for all users.

Of course, nobody can prevent you to simply fork the repository and start your own as long as you honor the existing licenses. Notice that most of the LabVIEW related code is BSD style licensed, while the C source code for the binary shared libraries that I have developed in the past is all under the LGPL license. Changing that license to any other license for any of the code without full approval by all of the previous authors is basically not an option. I would however find the forking of the repository the absolutely last measure. It would most likely rest in an obscure place, with no way to add its released packages to the VIPM list, so most users would never be aware that it exists and be able to install it on their systems.

Edited August 28, 2016 by rolfk

[ShaunR]

3 hours ago, rolfk said:

lvpipe

What would it take to make this release ready?

[Rolf Kalbermatter]

16 hours ago, ShaunR said:

What would it take to make this release ready?

Testing and more testing. The code as it is does sort of work for the things I tried, although I do have an occasional hang where the initial connection seems to not go through, but trying a second time then always seems to work. The pipe idea in Windows is a powerful feature but at the same time also something that I feel they didn't entirely go through with. It definitely is a niche feature that gets seldom used by real code, unlike under Unix (Linux) systems where pipes are more or less the infrastructure many applications use for all kind of interprocess communication.

And when you look at the C code of the DLL you will notice that the code to do standard IO redirection looks pretty complicated in the Windows case. It certainly has a flair of an additional API that got tacked onto the existing Windows process model in order to provide Unix like features.

I'll go and create in the next few days a thread here and attach the latest version of an OpenG package for lvpipe here. If I get some good feedback about it with more than just "it works" or "it doesn't work" and preferably some easy to reproduce (it shouldn't involve installing other software) unit tests, I might be tempted to actually create a real package and add it to the sourceforge download repository so it is then available from within VIPM.

[ShaunR]

5 hours ago, rolfk said:

Testing and more testing. The code as it is does sort of work for the things I tried, although I do have an occasional hang where the initial connection seems to not go through, but trying a second time then always seems to work. The pipe idea in Windows is a powerful feature but at the same time also something that I feel they didn't entirely go through with. It definitely is a niche feature that gets seldom used by real code, unlike under Unix (Linux) systems where pipes are more or less the infrastructure many applications use for all kind of interprocess communication.

And when you look at the C code of the DLL you will notice that the code to do standard IO redirection looks pretty complicated in the Windows case. It certainly has a flair of an additional API that got tacked onto the existing Windows process model in order to provide Unix like features.

I'll go and create in the next few days a thread here and attach the latest version of an OpenG package for lvpipe here. If I get some good feedback about it with more than just "it works" or "it doesn't work" and preferably some easy to reproduce (it shouldn't involve installing other software) unit tests, I might be tempted to actually create a real package and add it to the sourceforge download repository so it is then available from within VIPM.

Sounds great. I'm a great fan of examples as black-box, system tests so when you post the code I'll come up with some "examples" to exercise it. Can the c source be under the same BSD iicence or is there a particular reason for LGPL shenanigans?

[Rolf Kalbermatter]

2 hours ago, ShaunR said:

Sounds great. I'm a great fan of examples as black-box, system tests so when you post the code I'll come up with some "examples" to exercise it. Can the c source be under the same BSD iicence or is there a particular reason for LGPL shenanigans?

Basically, I have yet to see anyone bother with the C source at all.  Until that happens I see no reason to change anything on the license. 

There is absolutely nothing evil about LGPL when the resulting binary is anyhow dynamically linked, as is the case with all shared libraries. It doesn't contanimate your LabVIEW application in any way with anything GPL related.

Edited August 29, 2016 by rolfk

[ShaunR]

38 minutes ago, rolfk said:

Basically, I have yet to see anyone bother with the C source at all.  Until that happens I see no reason to change anything on the license. 

There is absolutely nothing evil about LGPL when the resulting binary is anyhow dynamically linked, as is the case with all shared libraries. It doesn't contanimate your LabVIEW application in any way with anything GPL related.

It doesn't just affect the source. It places a burden on making the particular source code used, and the entire build environment (usually tripling the distribution size) available for three years even if you just link to the binary.  99% of the time I' can't commit to that and adding  the confusion when redistributing because the toolkit user needs to understand that as well (and usually they don't) means it's more hassle than its worth. As far as I can tell with GPL and LGPL. They are just licences designed to set traps for programmers without lawyers.

Anyway. You are well aware of the arguments and the utter confusion voiced by many about openG licencing. So you release what you must. You seem to be the last man standing with the openG stuff and we all thank you for still consistently delivering. They say "one supports ones products until one dies" and so far you have kept to that

[Rolf Kalbermatter]

12 hours ago, ShaunR said:

It doesn't just affect the source. It places a burden on making the particular source code used, and the entire build environment (usually tripling the distribution size) available for three years even if you just link to the binary.  99% of the time I' can't commit to that and adding  the confusion when redistributing because the toolkit user needs to understand that as well (and usually they don't) means it's more hassle than its worth. As far as I can tell with GPL and LGPL. They are just licences designed to set traps for programmers without lawyers.

For the distribution and archiving of the source code I rely on sourceforge. No need to provide my own download page for that (just yet). Admittingly, sourceforge is heading into a direction that may at some point pose a problem for this. If and when that happens I will bother with it at that time and not let it deprive me of my sleep at this point already.

In the worst case I have to move it to Github or some other place and exchange the ease of SVN with the pericles of GIT. I might also loose the SVN history in that process, if sourceforge just gets taken out of the air by übercommercial Geeknet Inc without a chance to properly export everything first.

Edited August 30, 2016 by rolfk

[ShaunR]

28 minutes ago, rolfk said:

For the distribution and archiving of the source code I rely on sourceforge. No need to provide my own download page for that (just yet). Admittingly, sourceforge is heading into a direction that may at some point pose a problem for this. If and when that happens I will bother with it at that time and not let it deprive me of my sleep at this point already.

In the worst case I have to move it to Github or some other place and exchange the ease of SVN with the pericles of GIT. I might also loose the SVN history in that process, if sourceforge just gets taken out of the air by übercommercial Geeknet Inc without a chance to properly export everything first.

Indeed. But It is not a problem for you as the author but for me as a distributor of a composite or derivative works (including executables). Anyway, We digress into a well worn rabbit hole. Lets get this done.

[Stinus Olsen]

On 29/8/2016 at 11:01 AM, rolfk said:

Testing and more testing. The code as it is does sort of work for the things I tried, although I do have an occasional hang where the initial connection seems to not go through, but trying a second time then always seems to work. The pipe idea in Windows is a powerful feature but at the same time also something that I feel they didn't entirely go through with. It definitely is a niche feature that gets seldom used by real code, unlike under Unix (Linux) systems where pipes are more or less the infrastructure many applications use for all kind of interprocess communication.

And when you look at the C code of the DLL you will notice that the code to do standard IO redirection looks pretty complicated in the Windows case. It certainly has a flair of an additional API that got tacked onto the existing Windows process model in order to provide Unix like features.

I'll go and create in the next few days a thread here and attach the latest version of an OpenG package for lvpipe here. If I get some good feedback about it with more than just "it works" or "it doesn't work" and preferably some easy to reproduce (it shouldn't involve installing other software) unit tests, I might be tempted to actually create a real package and add it to the sourceforge download repository so it is then available from within VIPM.

Count me in on this as well! - I have quite a few ideas about where pipes would come in handy in my daily home- and work-related projects.
I never really understood why this toolset hasn't gained more attention than it has, so I'll be happy to help testing and promoting it

[hooovahh]

On 8/24/2016 at 1:02 PM, LogMAN said:

I think the lack of feedback is caused by general confusion about the status quo.

....

I think there are a couple of people here at LavaG that would participate in the project if someone would just start being active and committed to the project again.

Yup totally agree.  Array stuff needs to be evaluated.  Many improvements could be made from inlining, to the new conditional, and concatenating terminals in 2012.  Several things could be removed from the palette too to use the native functions if they have replacing functionality.  Things like Strip File Extension exist on the File I/O palette, but don't quite cover all of the same functions.  Same with some functions on the LabVIEW Data palette, and the newer variant palette.