The State of OpenG (is OpenG Dead?)

[ShaunR]

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. 

[ShaunR]

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 November 16, 2018 by ShaunR

[Neil Pate]

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.

[LogMAN]

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

 

[hooovahh]

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.

[Michael Aivaliotis]

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!

[smithd]

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 November 16, 2018 by smithd

[ShaunR]

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

[Jim Kring]

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 ;-)

[hooovahh]

27 minutes ago, Jim Kring said:

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

Well I mean...it can be. ?

[Michael Aivaliotis]

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?

[Rolf Kalbermatter]

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 November 19, 2018 by rolfk

[Michael Aivaliotis]

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.

[Rolf Kalbermatter]

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.

[Jordan Kuehn]

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.

[hooovahh]

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)

[bjustice]

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 November 20, 2018 by bjustice

[Phillip Brooks]

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 

[Michael Aivaliotis]

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.

[Rolf Kalbermatter]

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. 

[LogMAN]

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