PCL development workflow (and question about linking to the gsl)

[rga218]

Hi, I'm working on a PCL module to generate photometric superflats based on tables created by the AperturePhotometry script. So far it's going fine, but I have a couple of basic questions that I'm hoping somebody can give me a bit of advice on.

1. Right now I'm finding debugging to be pretty slow, because every time I recompile my module I am restarting PixInsight to get it to reload the module with the changes I've made. I'm sure I'm doing something silly --- could somebody tell me how to reload the updated module from within PixInsight without having to restart it?

2. I'm recycling some existing numerical code, so my module currently links against the gsl (the GNU Scientific Library), which is licensed under the GPL. While I'm mostly writing the module for my own use, I'd like to release it so it's available for others to use too. However, I find the GPL's terms to be confusing in the context of program add-ons, and I'm wondering if I need to rewrite the relevant bits of the code so I don't link against the gsl at all. (The required changes are not exactly rocket science -- I just need to solve a linear system -- but I'd rather not do extra work if it's not needed). Should I spend the time needed to get rid of the gsl calls?

Thanks,

Bob

[georg.viehoever]

1) I am not aware of any reliable method to allow shared libraries to be reloaded during runtime - and PCL modules are basically shared libs. But maybe Juan knows tricks.
2) GPL is incompatible with when it is delivered and used by closed source software - which PI is. Even the open source nature of the PCL library does not change that. You will be free to distribute the module as open source, but Juan cannot compile and distribute it with PI. However, this means that you or your users will have to compile it for each and every PI platform - which is close to impossible.

So if you want it to be distributed with PI, you need to check with Juan and probably need to get rid of GPLed elements. If you can, consider doing a PJSR version first.

Georg

[rga218]

Hi, thanks Georg. It will be interesting to see if Juan has a mechanism for unloading a dynamically linked library (or any other suggestions for more efficient debugging). I suspect unloading shared libraries is possible in principle, but whether or not it's a good idea is a different thing. 

I will also be curious to hear Juan's opinion on the GPL in this context -- though at the end of the day I should probably just rewrite the affected (infected?) bits of code just to keep life simple.

I originally envisioned writing this module using PJSR but I want to incorporate it into a modified version of the BatchPreprocessing script that I've written in order to reduce data from an array of telephoto lenses. And I can see other circumstances where it would be useful if it could be called in scripts. And as far as I can tell it's not easy to call scripts from other scripts.

Thanks,

Bob

[Juan Conejero]

Hi Bob,

Modules can't be unloaded in the current versions of PixInsight; they can be scheduled for uninstallation, but effective uninstallation requires a core application restart. Shared objects (or dynamic load libraries on Windows) can indeed be unloaded, but this has been disabled in the PixInsight Core application for the sake of stability. PixInsight modules can integrate in quite complex and subtle ways with the whole platform, and unloading them can leave unrooted living objects that in turn can cause many problems.

I am aware that this limitation can turn debugging a PixInsight module into a tedious task sometimes. Perhaps in a future version I'll implement a special module unloading feature for developers.

I will also be curious to hear Juan's opinion on the GPL in this context

As Georg has said, we can't release a module as part of the official PixInsight distribution if it contains any GPLed code. This means that we can't include it in PixInsight Core installation packages for any supported platform, and we can't release it through the update system either. Note also that this includes both static and dynamic linking. On the other hand, our PCL license is a BSD-like open source license, which is by nature incompatible with GPL.

I just need to solve a linear system

In this case, we have a few PCL classes that perhaps can help you to replace the GPL code you're using:

pcl::GenericGaussJordan
pcl::GenericSVD
pcl::GenericInPlaceSVD

Probably not as fancy as the libraries you're using, but usually more than sufficient in many practical cases.

[rga218]

Thank you Juan. I will just ditch the gsl calls to keep life simple.

So far I'm finding PCL module development to be pretty straightforward -- the tutorial in the PixInsight magazine was very useful.

Regards,

Bob