Author Topic: PCL: call another module ?  (Read 4459 times)

Offline kwiechen

  • PixInsight Addict
  • ***
  • Posts: 186
PCL: call another module ?
« on: 2012 January 06 07:29:19 »
Hi,

is it (or will it be) possible to call from one module another module and get a signal or something like this, if the other module has finished its task?

Best,

Kai


Offline zvrastil

  • PixInsight Addict
  • ***
  • Posts: 179
    • Astrophotography
Re: PCL: call another module ?
« Reply #1 on: 2012 January 06 11:48:48 »
Hi Kai,

this is not possible just now (with the exception of using Format Module to load an image). AFAIK Juan plans to implement intermodule communication, but this feature requires deep changes in the platform. Maybe 2.0? I'm sure Juan will comment it in more detail.

regards, Zbynek

Offline Juan Conejero

  • PTeam Member
  • PixInsight Jedi Grand Master
  • ********
  • Posts: 7111
    • http://pixinsight.com/
Re: PCL: call another module ?
« Reply #2 on: 2012 January 06 15:18:43 »
Hi Kai,

As Zbynek has pointed out, this is not possible currently. This functionality will be implemented in PixInsight 1.8, which should be released somewhere on next Spring.

If you are asking this because you want to implement your batch calibration script as a C++ PCL-based module, please reconsider it. I personally think this task can be implemented much better as a script with PJSR.

Scripts have many advantages in PixInsight: they are portable by nature, don't require additional tools, are much easier to maintain than C++ modules, and can interact with the whole platform in very powerful ways (and this power will be incremented in the next releases considerably). I can anticipate one of the main improvements that we'll have in PJSR in the near future: We'll have an integrated C/C++ compiler in PixInsight (based on clang) that will allow writing small routines callable from JavaScript code, which will be compiled just-in-time automatically. With C/C++ JIT compilation, JavaScript scripts will rival in performance with PCL-based modules.
Juan Conejero
PixInsight Development Team
http://pixinsight.com/

Offline kwiechen

  • PixInsight Addict
  • ***
  • Posts: 186
Re: PCL: call another module ?
« Reply #3 on: 2012 January 07 06:48:26 »
Hi Juan,

the batch task for preprocessing raw data is only a shiny wrapper to call these excellent PI modules - so also in my opinion it is better to use a script approach here.

However, I have a few problems with PJSR javascript:

- I have never used javascript before.
- it is loosely typed (of course this should be no problem with integrated clang)
- the script is not easy to maintain in the internal editor if the length exceeds a few hundred lines (is there another IDE - best with integrated debugger?)
- in C++ I can separate for example GUI and logic in different classes and files and one DLL/shared object is installed. Is it possible to compile javascript from several project files to one bytecode "executable"
- the Dialog is in principle modal in its nature - so user interaction appears to be limited. This prevents me from adding additional functions like a final integration step where careful adjustment of parameters is necessary


Best,

Kai






Offline georg.viehoever

  • PTeam Member
  • PixInsight Jedi Master
  • ******
  • Posts: 2132
Re: PCL: call another module ?
« Reply #4 on: 2012 January 07 07:48:22 »
I tend to agree with Kai. JavaScript is good for prototyping, but if you want full flexibility (such as the ability to switch between views, zoom, try other parameters, store instance (only partly functional for scripts), use preview, ...) and speed, it means C++/PCL. The only bit that is currently missing from PCL is the ability to call other modules.

Georg
Georg (6 inch Newton, unmodified Canon EOS40D+80D, unguided EQ5 mount)

Offline Juan Conejero

  • PTeam Member
  • PixInsight Jedi Grand Master
  • ********
  • Posts: 7111
    • http://pixinsight.com/
Re: PCL: call another module ?
« Reply #5 on: 2012 January 07 18:09:03 »
Quote
- I have never used javascript before.

A good reason to use it ;)

Quote
- it is loosely typed

That's true. Static typing is something that ES4 tried to address, but unfortunately ES4 was dynamited in the way we know. On the positive side JavaScript is a fully dynamic language, which is one of its strongest points: everything is resolved at run time. There's no practical problem with this; it's just that good programming and design practices are even more important to write large scripts.

Quote
- the script is not easy to maintain in the internal editor if the length exceeds a few hundred lines (is there another IDE - best with integrated debugger?)

Well, I've written very large scripts with PI's Script Editor. One of them is MakefileGenerator with some 4000 lines and another is the PIDoc compiler with more than 5000 lines. We don't have a debugger but this is also in the to-do list; I am just waiting until Mozilla's JS debugger becomes stable.

Unfortunately you can't debug JavaScript scripts for PixInsight with another applications, mainly due to PI's scripting engine, which only exists in PI.

Quote
- in C++ I can separate for example GUI and logic in different classes and files and one DLL/shared object is installed. Is it possible to compile javascript from several project files to one bytecode "executable"

Absolutely. JavaScript is a fully object-oriented language. It doesn't use a class-based OO model, but a prototype-based model. Modularity is also possible, which is important for large projects. For example, I divided the PIDoc compiler script into seven source files where the compiler, the contents generators, the document generator and the GUI are separated into independent units.

Quote
- the Dialog is in principle modal in its nature - so user interaction appears to be limited.

Yes, script interfaces are always modal. This is a limitation that we'll overcome in the future, but not in the short-middle term. It is true that this involves a limitation in functionality, compared to PCL-based modules. For scripts implementing batch procedures this is no problem at all IMO. There are other tasks for which modal interfaces can work well, as those that require interactive image analysis.

Quote
This prevents me from adding additional functions like a final integration step where careful adjustment of parameters is necessary

Well, this depends on what you want to implement and how. Integration of master calibration frames, calibration and alignment can be implemented as a pipelined batch process. However, integration of light frames is a completely separate task; it doesn't have to be part of a calibration batch process IMO. The ImageIntegration tool provides many control data precisely for this reason: because the user has to fine tune parameters and evaluate control data to achieve the best result. There are other applications that prioritize simplicity over accuracy, but this is not the philosophy of PixInsight (just the contrary).
Juan Conejero
PixInsight Development Team
http://pixinsight.com/