Jump to content

How to contribute to OpenG Package


Recommended Posts

  • 2 weeks later...

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 :D

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.

  • Like 1
Link to comment

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 by rolfk
  • Like 2
Link to comment
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.

Link to comment
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?

Link to comment
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. :lol: Until that happens I see no reason to change anything on the license. :P

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 by rolfk
Link to comment
38 minutes ago, rolfk said:

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

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 :worshippy:

Link to comment
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 by rolfk
Link to comment
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.

Link to comment
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 :)

Link to comment
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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.