G#
Possible future developments
Hello Andrea. Thank you for your questions and thoughts.
1:
It is not for backwards compatibility with LabVIEW 2009 that G# is not in an lvlib or ppl, it is because G# was created when lvlib’s did not exist, and if we would move G# to an lvlib, the namespace of all G#-VIs would change. All existing code that will now be using ppl-G# would need to replace the G# VI’s with the lvlib/ppl-version. The best way to do it is to keep everything in the project in memory before changing the namespace. I tried this a couple of years ago for a project where I wanted to move G# to a ppl. It always ended with LabVIEW out of memory or crash. I was using 32 bit LabVIEW at that time though. And when this has been done one time, G# is now in an lvlib and when you want to repeat the process for the next project, G# will need to be moved out of the lvlib first, or reinstalled. It is easy to make a mistake and mess up the code using G# saving them in an incorrect state . So for many or most people, this is not an easy task, and since no-one (at least for 5 years) have asked for how to do this well with G#-projects, I have not put much more work into it.
If the ppl-G#-version is to be used for code that uses normal G#, all G# VIs will need to be replaced. There is no good way to replace VIs with other VIs, especially not for larger projects. It’s not relinking, since it is not seen as the same file by LabVIEW since the namespace has changed. I did a bit of research a couple of years ago and tried to automate the process but It always ended with various LabVIEW-crashes. I gave up when I read a reply from Darren Nattinger on a forum-thread related to this problem, where he said “never, ever rename classes. I'm serious.”, concluding that LabVIEW is not made for managing namespace-change.
So let’s say you don’t care about compatibility with current G# and are fine with creating new G#-classes using a PPL-version of G#. Is that what you want? I guess one could argue that since G# root classes are then in a new namespace, there cannot be a conflict with current G# root classes, they are essentially other classes. It would have to be well explained though and could be confusing.
Do you want to be able to load both current G# and ppl-G# plugins? I guess that there could be plugins that other projects use that you do not want to change, and the new ones you will create using ppl. Is that something you want to do?
In your plugin architecture, is your intention to have one ppl for G# and one ppl for each plugin that will link to the G#-ppl? I’m just trying to understand your use-case so I can give you the best answer, and that we can make the best decisions if we update G#.
Since you found the readme-file in "\resource\Framework\Providers\AddQ\G#IDE\G# Packed Libraries ReadMe!.txt" describing how to put G# in a ppl, what is not sufficient with that solution? Is it too much work to create it, or do you just think “why not include it” in the distribution of G#? Or are you limited in some way since it is the ppl is not included? Another reason G# has not been included as a ppl in the distribution is that it will have to be one ppl per LabVIEW-version. OK, since G# 1.8.0, we do not have to care for versions older than 2017, but 2018 is soon here... Hmm, I wonder with the backwards-compatibility of the runtime-engine since 2017 that also means that ppl’s can span several LabVIEW-versions. I will take look at that.
There are also some obstacles regarding the IDE. It will need to support both/either current or ppl-G#-classes. I think that is doable though. I have a few ideas here. The build process of G# will also be more complicated, but that could be automated I assume.
2:
Malleable VIs are compile-time dynamic and not run-time dynamic, so a true dynamic interface implementation is not possible. It would be possible to leverage the features of malleable VIs for creating a new type of G#Interface-template though. There was a discussion and solution sketch of this after a presentation by Andrei Zagorodny at the E-CLA in Madrid. From what was concluded at that discussion, I did not see a real benefit compared to the existing interface-templates. It would be something of a holy-grail to find such a solution though, so any thoughts here are appreciated. I would like to experiment and see what could be done though, but I have not had time for it.
Best regards,
Thomas
Hi Andrea,
I didn't mean to scare you off. I would really like to explore the possibilities of using a ppl architecture, but one thing I learned is that the architecthure of namespaces has to be set at the start of the project, or it will be too much work/risk, and I have not been lucky enough the last years to be starting from scratch.
G# does not have to be a separate ppl, but there could be benefits of it. Both will work, but I have not explored what the best option is. I think it is best explained by Nancy: http://labviewjournal.com/2011/10/packed-project-libraries-part-2/. In her example, G# would exist in all ppls where G# is used. I would advise to keep the ppl small though, as large ppls can take a long time to load and work with (at least that was the case in LV2013). I guess it would make sense though to have G# in its own lvlib since it has its own release-cycle, but that could be managed without ppls too. And since copies of G# will still be made for each ppl, and ppl's cannot locate other ppls dynamically, I'm not sure how much of the benefits of ppls are left.
I have no personal experience of ppl's in a plugin architecture of a larger system, but I did a lot of research when I was in a similar situation as you (in 2013). In the end, I kept the non-lvlib/ppl architecture I had, and it works really well, although that project never needed to share plugins with other projects. My goal then was, since it was a huge application, I wanted to break it down in to smaller pieces, dynamically loadable. I wanted to explore if it could load faster too with pll's. But since it turned out to be near impossible to change namespace on a large scale, I gave up. And then we did a lot of refactoring and then the fast file format came, and the initial load time went from 90+ seconds to 1 second.
Creating a ppl-structure and managing the distribution process is not simple. In addition to Nancy's blog post, I found this guide that could be helpful: https://forums.ni.com/t5/LabVIEW-Development-Best/Plug-in-Architecture-using-Packed-Project-Librarie.... I also noted that in the comments, Stephen Mercer (Aristos Queue) says he also gave up more than once: "As hard as this sequence of steps is, even harder is the steps needed to build the plugin architecture when the code is already written without that in mind -- i.e., there's one project with the application, a parent class that isn't in its own library, and a bunch of already written child classes that are successfully doing dynamic loading. Making the conversion at that point is more complicated -- something I've tried to do a time or two and always botched. It's really important to have the end design in mind when writing the original code". There is more information on namespace changing and ppl-building out there to search for too.
I can se the benefit of ppl's in your environment, but is not that much different to maintain separate release-timelines for different parts of the code, if the releases are managed in a SCC and the builds are built from SCC-configurations that points to the correct revisions/releases of the included Components. If you then have a PDM system to store your releases/products or/and configurations in, you should have full control of the process and be able to share plugins/componenst between projects/software suites.
So in short, I gave up the idea of ppl's in my project since it was hard to change namespace and since I did not see/get the benefits of it, compared to managing it via SCC and a PDM-system.
If you will be changing namespaces, I suggest you use 64-bit LabVIEW, as the memory will be eaten-up very fast. Also do it on a high-performance PC as it can take a long time for large projects.
Have you checked out VIPM? I think they can manage dependencies between packages. I guess its a manual configuration, but perhaps that could be an option for you if you will be distributing parts of your code as packages/components throughout your organisation.
