Jump to content
News about the LabVIEW Wiki! Read more... ×
Michael Aivaliotis

The State of OpenG (is OpenG Dead?)

Recommended Posts

49 minutes ago, Michael Aivaliotis said:

I don't get that from your site at all. If someone contacts you about a bug to your tool, do you ignore it? I assume no.

Of course not. But some of the toolkits haven't been updated for a few years because of the reasons I stated. So it's an example of why the trope about no development activity is untrue. This is why I don't put dates on the public version history.

By the way. The idea that development activity is a sign of a "live" project only came about in recent history once people got used to buggy code and alpha releases purporting to be a release proper. I view continuous updates and lots of activity as unstable and therefore unusable code. If one is contemplating using a library or piece of software and think it is less a project risk if there is lots of activity, then, IMO, one has admitted that ones own software will be unstable and bug ridden. I don't exactly know at what point alpha software was accepted as the the norm for final product but it seemed proliferate in the switch to Agile Development. 

Share this post


Link to post
Share on other sites
1 hour ago, LogMAN said:

A simple place to share VIs might be easier to manage and contribute to in the long run.

Lava serves this purpose well.

In fact. my last interaction with openG was here

Edited by ShaunR

Share this post


Link to post
Share on other sites

I still use a few OpenG VIs in most of my projects. Things like fit to decoration, some array stuff, INI file stuff. I consider the library to be mature, not dead, but do not really expect any more updates on current gen.

Share this post


Link to post
Share on other sites
11 minutes ago, ShaunR said:

Lava serves this purpose well. 

I agree. It just needs to be more visible to users (i.e. by putting "Downloads" in the main navigation bar next to "Leaderbord")

It also brings us back to this poll

 

Share this post


Link to post
Share on other sites
5 hours ago, Michael Aivaliotis said:

So were the VIM versions ever incorporated into the latest OpenG?

I've seen in the past that when updates were made to OpenG (years and years ago), they weren't to the newest version of LabVIEW and would support a couple versions back.  Since VIMs are officially only in 2017 and newer that would limit those wanting OpenG's new refresh to that version.  BTW I think these are the links that were intended for the XNode and VIM versions of the OpenG array tools.  Both aren't just direct replacements but have a few other new functions, or new features to existing ones.  Other improvements like inlining removing debugging, and automatic error handleing can also improve performance over the ones from 2009 or so.

And yes I forgot about the zip utilities which work so much better than the native NI ones.

Share this post


Link to post
Share on other sites
6 hours ago, LogMAN said:

I agree. It just needs to be more visible to users (i.e. by putting "Downloads" in the main navigation bar next to "Leaderbord")

Done!

  • Thanks 1

Share this post


Link to post
Share on other sites
9 hours ago, ShaunR said:

That's a trope initially perpetuated by marketing people. There is no message. If developers discontinue a product they will [almost] always say so in the notes, comments or website unless they were unexpectedly hit by a bus. 

For a counter argument, ask NI marketing "is DSC dead?"

Last time I heard that question they bent over backwards to claim it's not, and yet...

Edited by smithd

Share this post


Link to post
Share on other sites
21 minutes ago, smithd said:

For a counter argument, ask NI marketing "is DSC dead?"

Last time I heard that question they bent over backwards to claim it's not, and yet...

Ask them about BridgeVIEW :D

  • Haha 1
  • Sad 1

Share this post


Link to post
Share on other sites

OpenG isn't dead. There just hasn't been a lot of work on it lately (though we have been working to keep them working in NXG).  I've been in the process of moving the libraries over to GitHub, as needed.  LAVA posts aren't the best way to get in touch ;-)

  • Like 1

Share this post


Link to post
Share on other sites
27 minutes ago, Jim Kring said:

LAVA posts aren't the best way to get in touch ?

Well I mean...it can be. ?

Share this post


Link to post
Share on other sites
2 hours ago, Jim Kring said:

LAVA posts aren't the best way to get in touch

The OpenG forums here on LAVA have been considered as official channels for some time, unless that's changed. But thanks for finding this. I think moving to GitHub is a great idea and would allow better collaboration. Bug reports and feature requests can be managed on GitHub more efficiently probably than on LAVA. However, freeform discussion forums are also very usefull. What can we do to accelerate the Github migration?

  • Like 1

Share this post


Link to post
Share on other sites

I've been making a few small changes in the past to the string package in the repository based on bug reports I saw.

Revision: 1494
Author: labviewer
Date: vrijdag 23 mei 2014 23:07:42
Message:
Attempt to fix the String to 1D Array.vi function when ignore duplicate delimiters is true.
----
Modified : /trunk/string/source/library/String to 1D Array.vi
Modified : /trunk/string/tests/TEST - String to 1D Array.vi

But I'm not familiar with the exact release procedure. When not seeing any more action I eventually build a new VIP file oglib_string-4.2.0.13.vip and uploaded it to the sourceforge file store in 2017 but that seems not enough to make it appear in VIPM unfortunately.

Edited by rolfk

Share this post


Link to post
Share on other sites
10 hours ago, Rolf Kalbermatter said:

But I'm not familiar with the exact release procedure

That's great @Rolf Kalbermatter . If we can figure out this last piece, then it would go a long way to allowing improvements to the library. I think it would also be useful to document this procedure somewhere, perhaps in the Wiki. However, I think the answer might be: email JKI to get it released.

Share this post


Link to post
Share on other sites
17 hours ago, Michael Aivaliotis said:

However, I think the answer might be: email JKI to get it released.

I think that's a short term fix but not really something that should be part of every new OpenG library release cycle, nor a possible future LavaG library release.

Share this post


Link to post
Share on other sites

I just loaded a bunch of JKI VIPM packages onto a new laptop and a bunch of OpenG packages were dependencies. I would not say this is dead at all.

  • Like 1

Share this post


Link to post
Share on other sites

The real death of an API isn't when development stops, but instead the last time someone uses it as a dependency. (loosely quoting several people about existentialism)

  • Haha 1

Share this post


Link to post
Share on other sites

I still actively use the OpenG toolkit.  I would say that 90% of my usage lies in the Array and File palettes.

I also recently learned that Hooovahh rewrote the Array pallette using VIMs though, so I've been using that in newer projects.

Hooovahh Arrays

It might be nifty if OpenG added Hooovahh Arrays to the OpenG Arrays palette...

Edited by bjustice
  • Like 1

Share this post


Link to post
Share on other sites
23 hours ago, Jordan Kuehn said:

I just loaded a bunch of JKI VIPM packages onto a new laptop and a bunch of OpenG packages were dependencies. I would not say this is dead at all.

EasyXML Toolkit :thumbup1:

Share this post


Link to post
Share on other sites
3 hours ago, Phillip Brooks said:

EasyXML Toolkit

Ya, but at least I can checkout the EasyXML repo locally and even fork it, which I have.

Share this post


Link to post
Share on other sites
19 hours ago, Michael Aivaliotis said:

Ya, but at least I can checkout the EasyXML repo locally and even fork it, which I have.

You can do the same with any of the other OpenG libraries. Yes they are in a SubVersion repository so not the exact same experience as with GIT repos, but similar enough. 

Share this post


Link to post
Share on other sites
On 11/22/2018 at 2:10 PM, Rolf Kalbermatter said:

Yes they are in a SubVersion repository so not the exact same experience as with GIT repos, but similar enough. 

You can use git-svn to make your dreams come true (and nobody will know) ?

https://git-scm.com/docs/git-svn

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×

Important Information

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