Michael Aivaliotis

You need to have 3 levels. The first one is for the cheap bastards. The third one is for the rich bastards, and the middle one is for everyone else. You have to identify with one level.

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

Yes, I ran into this issue as well. I couldn't upgrade a customer PC to Windows 10 because I was using LV2014. So then I decided to upgrade to LV2018, but the customer had 1 PC running WindowsXP. yes. XP. So that aborted the whole upgrade, just for 1 PC. So the highest I could go was LV2015.

Yes, but ignoring the IPE error out on read as well? I would think that you would want to know if the IPE structure fails completely. This would be a sign of a bad DVR ref.

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.

See this post. This thread is now closed.

After I made this post I decided to bring the LabVIEW Wiki back online. It was not easy and took several days of server upgrades and hacking. The good news is I was able to bring up all the original pages.. The even better news is I talked with @The Q and @hooovahh and we are all on the same page as to how to move forward. @The Q did a great job of stepping forward and trying to fill the void that the LabVIEW Wiki's absence had left. He's agreed to migrate all the new content he created over to the LabVIEW Wiki, from Fandom and continue to develop new articles and content moving forward on the new site. He will also help in moderating the Wiki and will be promoted to Admin rights on the Wiki. His help is much appreciated. The LabVIEW landing page created here on LAVA is awesome but the forums don't lend themselves to static content creation. Instead @hooovahh has agreed to move the old landing page to here. That will be the new home for the landing page. This will become a valuable resource for the community and I hope all of you start pointing new people in that direction. With many editors, it can only get better and better over time. Where do we go from here: Logging in. - The old accounts are still there. If you're a LAVA old-timer, then you can try to login using your LAVA username. If the password doesn't work then reset it. You can also create a new account here. I'm going to announce a day when new accounts can be created. I'm limiting it for now because of all the spam accounts that can be potentially created. There's an issue with the current Captcha system. if you are super-eager to start creating content now and want to help, send me a direct message on LAVA and I can manually create an account right away. - New account creation is now open. Permitted content: - I'm not going to put restrictions on content at the moment. Obvious vandalism or offensive\illegal content will not be tolerated of course. However, the guidelines will be adjusted as time goes on and new content is created. There's just not enough content right now to be overly concerned about this. We need content. Discussions about the Wiki. - Each article page has an associated discussions page where you can discuss issues related to that article. Please use that mechanism (same etiquette as wikipedia). General Wiki issues\questions and high level discussions can be done here. So now, if you need to add content, you can do it yourself. Feedback as always is welcome.

Isn't it obvious? Charging for desirable features is one way of creating revenue. Deciding where to draw the line between free and paid features is always a challenge.

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?

Ya, I saw that and am planning to read through that to be better knowledgeable on what I'm complaining about. But for starters, there are 3 questions on that doc and nobody from NI has responded. Stuff like that irritates me. There's no NIPM forum though. None that I could find anyway.

Assuming all you claim is true as of this writing. Then yes, I can see several things that are limitations. Let me look at each one: Palette editing. You can edit palettes in LabVIEW and grab the menu file. I know, it would suck, but not a deal-breaker. Package release for every LabVIEW version. Wow, this seems like NI took the one built-in feature of LabVIEW (automatic up-conversion) and threw it out the window. Way to go NI? Pre-Post build actions. I would have to look into this further. I thought NIPM had a command-line interface (or at least this is what I was told). You could build a wrapper around that and create a VIPM-like experience, could you not? Then include your pre-bost build steps? Perhaps include palette editing (see item 1). Only Post-Install and Pre-Uninstall actions are allowed. - Ya, more flexibility is needed. Not a show-stopper though. Package dependencies seem to only be checked between the current feed. - That could either be a fundamental flaw, or a benefit. Not sure. However, it would be nice to have the choice. In VIPM there is no line drawn on this, and it's sometimes useful to limit yourself to a certain repo. Seems Ni took the safe approach. No dependency scanning. - This is a useful feature, but I'm not sure in what context you are referring. Do you mean, during package building, to make sure the dependancies are declared? Manually declaring dependencies might be ok for now. No package of packages.- Meh. Nice to have but there are other possible solutions to the same problem. No offline single file with everything included - VIPM doesn't have this, unless you are referring to VIPC files. Packages can't be loose VIs, they must be in something like an EXE, or source distribution first. - Well, VIPM creates a source distribution behind the scenes when it builds a package. But I get your point. NIPM could hide this complexity. - Not a showstopper though. I think it's a combination of all of these issues that make NIPM a bad choice right now for packaging VIs. However, If I imagined a world where VIPM did not exist and all I had was the current version of NIPM. And I was 15 years younger... I would probably figure out how to create a VIPM-like interface to the NIPM core. Fixing all the inadequacies. Not saying it's possible, but I would be working on that right now. Because it would be a fun thing to do. After all, it's how VIPM was built in the first place. The core of it though is that NI is betting on this horse and is putting resources into it. I suggest we guide it in the right direction and make sure it's a winner and does what we want it to do. If not, then we should figure out a way to work with it, augment it and fix it. The more we do that, the more NI will make it better and modify it to remove limitations. - sigh, at least I hope. Check out the NIPM API

Done!

I've only just seen this thread. So the mechanism for creating a repo is simple and the current LAVA server can do this no problem. The issue is file size which would would eat up disk space and is what costs money. However, there are ways around this. For example, as @rolfk pointed out, the OpenG packages are served up from sourceforge but distributed from the JKI repo. So workarounds are possible. I don't want to get into that right now as this is not the main issue. There are 2 main VIPM Pro bottlenecks that have to be addressed for a LAVA repo to become a reality. First is the Repo management. This needs a Pro license. However, since this function only needs to be done be a handful of people and infrequently, it could be acceptable if LAVA purchases a license and assigns some administrators for this. Second bottleneck, and the biggest hurdle, is that in order to subscribe to a repo you need a Pro license. This is the main thing preventing widespread adoption of the VIPM repo model. If JKI removed this barrier, then it would make sense to not only have a LAVA repo, but a number of repos. That would mean that anyone with a free license of VIPM could connect to any repo and get the tools they need from within VIPM, from the repo they care about. Companies could create internal repos and use that to distribute code to their developers. Or special repos for their customers. ?The possibilities are endless ?. Ok, back down to reality. Maybe we can use NIPM? I was browsing this content and it seems NIPM allows public feeds: https://forums.ni.com/t5/NI-Package-Management/Introduction-to-NIPM-Feeds/ta-p/3808155 What's the issue with NIPM exactly?

Based on this discussion thread, there are clearly improvements and restructuring that could be done to make the toolkit better. Even if you look back at old threads for suggestions. Currently there is no mechanism and no plan to do this. Bug reports and suggestions get ignored or go into a void. Documentation is missing or broken with no intent to be fixed. New improvements and efficiencies in LabVIEW have not been incorporated. Etc. I guess my assumption of OpenG was an ongoing community effort to build a great toolkit. I'm not seeing the ongoing community effort part. 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.

Yup, there's so much development in OpenG, it's mind blowing. If I see a tool, application or library that has no development activity in over 5 years, then I cannot trust that application, tool or library. That is a clear sign of intent on the part fo the developers. The message is loud and clear. This library, app or tool is dead, move on. That is a project risk.

The library is still useful. But it can be useful and dead at the same time.

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

NI create directory does this already.

I don't know if JKI is now managing the packages from within GitHub or if those are dead repos. I guess JKI should chime in to explain. For one thing. All the links to open.org are dead. So at least the packages need to be updated to remove that crap.

I love this analogy.

Well, your comments are definitely valid for any tool distributed as a package. Not just OpenG. Also, for OpenG specifically, NI has started to incorporate some of the functionality of VIs from OpenG into the default distribution. There are numerous examples. It makes it even less attractive to use it. There are a handful of VIs in OpenG that I use that I wouldn't miss and could easily be replaced by creating replacements and dropping them into my own library. If there is no development or improvement of OpenG, then it becomes less useful and it just encourages people to roll their own. I think if there is to be any development of OpenG then it should be moved from SourceForge into a different repository system like GitLab or GitHub. This way others can contribute. That would be a good start.

@0_o, thanks for the morning laugh! ? I guess I deserved that.

In this thread, a user makes a suggestion for an improvement to an OpenG VI. Let's say we all agree and want to make changes to the OpenG ini VIs. Now what? What is the procedure to do this? How is this package managed and by whom? In this thread @rolfk states the original authors have moved on and the library is pretty much archived. On the other hand, JKI has migrated the OpenG code to LabVIEW NXG. So there is some interest to keep it alive. What is the state of the union on OpenG? How are changes and improvements made, then released? Is OpenG a dead library?

Reminds me of the most recent Microsoft update bug. They had to pull it: https://www.engadget.com/2018/10/05/windows-10-october-update-1809-delete-data-wipe-user-profile/

I'm sure if you request that from JKI, they could help. But last I recall VIPM typically installs the installer in: C:\ProgramData\JKI\VI Package Manager 20xx\updates\VIPM This might have changed, but try there. Also, if the setup isn't there, look for the vipm-update.aiu file in that area. It's a text file that includes a URL to the installer. PS: I don't work at JKI.