Issues Generating Makefile in OS X

[David Raphael]

I was not having any issues before, but this morning I was unable to generate a Makefile in OS X:

Code: [Select]

======================================================================
PixInsight Makefile Generator Script v1.61
Copyright (C) 2009-2010 Pleiades Astrophoto

======================================================================

==> Finding files for project directory:
/Users/draphael/dev/TestDriver


Source files       :     0
Header files       :     0
Resource files     :     0
Image files        :     0
Source directories :     1

==> Generating makefile:
/Users/draphael/dev/TestDriver/linux/g++/makefile-x86
*** Error [000]: /Applications/PixInsight64.app/Contents/src/scripts/MakefileGenerator.js, line 1033: Unable to create file: /Users/draphael/dev/TestDriver/linux/g++/makefile-x86: No such file or directory


Has anyone else had this problem?

Also, my command line history disappeared at the same time...before I was able to start the app and my Console command line history was still there...but now it is empty each time...

[Juan Conejero]

Hi David,

The problem is that the script isn't finding any source code files. Apparently there are no .c, .cpp or .h files on your TestDriver directory. The script fails (line 1033) because the "/Users/draphael/dev/TestDriver/linux/g++" directory has not been previously created, due to the fact that the project is empty (no source files).

Are you sure you're pointing the script to the correct directory?

As for the command line history, I haven't seen that behavior before. Are you running a single instance of PixInsight? (I ask because command line history, among many other things, are kept on a per-instance basis).

[David Raphael]

There aren't any cpp or h files ;-) 

I guess in Windows you can run this without any directories being defined yet, but in OS X you have to!
Good to know.   I guess I saw this on line 1033:

Code: [Select]

   f.createForWriting( makefilePath );

I figured it would create the directory for me.  I'm pretty sure it does on Windows right?

WRT to the command line history - I don't know what happened.  Maybe it thought there was another instance running?  I have been opening and closing it repeatedly to do module testing...

[Juan Conejero]

f.createForWriting( makefilePath );
I figured it would create the directory for me.  I'm pretty sure it does on Windows right?

File.createForWriting() presumes that the directory where it has to create a new file already exists; it fails otherwise on all platforms. Always keep in mind that PixInsight is truly cross-platform (not just an adaptation of things to some platforms), so all PJSR routines work exactly the same way on all supported platforms, with a few exceptions due to platform-specific idiosyncrasies that we cannot avoid (such as case insensitivity of the file system on Windows).

One of these idiosyncrasies on Mac OS X is that graphical applications (including PI) don't inherit the environment you have defined in your .profile configuration file, as happens on Linux (with .bash_profile for example), so you have to define your PCL environment from PI. More info and how to work around this limitation in this post:

http://pixinsight.com/forum/index.php?topic=2674.msg18098#msg18098

[David Raphael]

However, with Windows - you can create a makefile (VC Project) without creating the directories - I just tried this and it worked.  I think that is where my confusion comes in.

[Juan Conejero]

I think the confusion comes from the fact that on Mac OS X you have to define all PCL environment variables from PI each time you run PI (see the little script I wrote in the post linked above), while on Linux and Windows the variables are already defined system-wide.

How is it going on with that camera control module? 

[David Raphael]

I run the setupenv.scp each time - if I don't, the MakefileGenerator script doesn't even run.

I just ran it from windows with no .h/.cpp files - and it works to generate a file for windows only... but I think I've always run it in OS X with .h/.cpp before...no?

I am progressing very slowly on the camera control. 

I'm trying to figure out the best way to load drivers - so far I am thinking that in the settings of the module, the user will select a driver via a simple control.  Right now I am attempting to dynamically load a driver that is built against an ICamera interface I've defined.  Let me know if you have any ideas here.  I have a lot of questions about how the processes will interact with eachother in PixInsight.  I'm not sure how the ImageAcquisitionSettings<Process/Interface/Parameters> will pass the Camera information to the ExposeImageProcess or vice versa - how the ExposeImageProcess will load the Camera.  It needs to stay connected to control the temperature etc...and then how does the ExposeImageProcess access the shared ICamera object...can the ICamera object instance be kept somewhere where all the modules can interact with it? 

Maybe you can give me some pointers...

Cheers,
Dave

[Nocturnal]

Ah yes, you've run into an issue we discussed earlier when debating how to implement a full image calibration pipeline. How does process X get information to/from process Y that's already instantiated. I don't think it's possible but Juan will know.

[Juan Conejero]

I'm not sure how the ImageAcquisitionSettings<Process/Interface/Parameters> will pass the Camera information to the ExposeImageProcess or vice versa - how the ExposeImageProcess will load the Camera.

The best and easiest way is that you implement all of them —all processes requiring intercommunication— in a single module (that is, in the same .so/.dylib/.dll). Being built in the same module, they can simply share the necessary data items.

Don't try to build each process in a different module; that's a bad approach. A set of related processes should be defined within the same module. By following this design, everything is much simpler —both for you and your users— and there are many advantages; for example some of your processes can share instances, if necessary.

You have an example of two processes that can share instances in the IntensityTransformations module (the full source code is included in the PCL distribution). The HistogramTransformation and ScreenTransferFunction tools can share instances; that's why you can drag an instance of HT to STF's control bar, and vice-versa.

[David Raphael]

OK - good.  This is my approach so far - everything is in the same module/library - ImageAcquisition.dll/.so/.dylib 

But I have a question about this

Being built in the same module, they can simply share the necessary data items.

Are the marshaling the data back and forth? Or are they actually able to pass references/pointers back and forth?

Cheers,
Dave

[Juan Conejero]

How does process X get information to/from process Y that's already instantiated.

The current version of PCL has limitations to implement this kind of interprocess communication. This will be fully implemented in a future release (it is planned for the 1.7 cycle).

Basically, right now there are two options to implement these procedures:

- Implement X and Y in the same module. For processes within the same module, PI Core allows instance assignments. Along with that, sharing data within a module is easy because X and Y are implemented by classes declared in the same compilation unit.

- Implement the task as a script. The PJSR allows dynamic generation of instances for all installed processes.

[Juan Conejero]

Are the marshaling the data back and forth? Or are they actually able to pass references/pointers back and forth?

PCL classes can pass references and pointers to process instances and other objects freely, if they lie in the same module. Within the same module there are no restrictions. However, if two processes are implemented by different modules, the Core application does not allow sharing instances (for example, try to drag an icon of CurvesTransformation to FastRotation's control bar).

As I've said above this will be overcome in a future version. That will require a new set of PCL classes for instance data interchange and their core application counterparts.

Let us know if you need more help or information. I'm glad to know you're progressing on this project!

[David Raphael]

Thanks for patiently answering my newbie questions ;-)

Based on my understanding, here is what I want to do:

1.  Have a "toggle" button on the ExposeImageInterface that will connect and disconnect the camera in the ExposeImageInstance.  These settings will be stored like the settings are stored in the Global Module.
2.  If you click "execute global" on the ExposeImageInterface,  the ValidateProcess() will check if you are connected to a camera etc...at this point the ExposeImageInstance will be passed the "handle" to the connected camera.
3.  An ExposeImageThread will be created that will run the image capture process for a single image...
4.  When that Thread is complete it will pass it's data back to the ExposeImageInstance for file io or screen etc...
5.  It will repeat this process as many times as specified by the user...

Does this seem reasonable?  I may have missed a thing or 2, but I want to make sure I am not way off base here before I go too much further.

Cheers,
Dave

[Nocturnal]

What kind of cameras do you intend to support? Perhaps connect to Nebulosity 2 using a socket interface and have it do the heavy lifting (camera compatibility) for you? No ASCOM on Mac/Linux so that doesn't look like an option. Are there Indi cameras?

[David Raphael]

I plan on supporting ASCOM on Windows and QHY cameras on Mac and maybe eventually Linux.

I may also add support for SBIG and QSI as well...but I am probably over committing as it is ;-)