Unix: Dump backtrace info in case of signals

kkretzschmar commented 9 years ago

Hi Juan, here a first version of a backtrace dump in the Unix Signal handler. The backtrace contains demangled function names and the function offset. With a debug version of a module it should be possible to find the exact code location using the "addr2line" tool.

All modules should be linked with an additional compiler flag -rdynamic. The adaptation of the makefiles or the makefile generator is not part of this change.

Unfortunately I was not able to test the changes on macos.

Klaus

jconejero commented 9 years ago

Hi Klaus, Nice work. I'm going to merge this now, and will integrate it in the next PCL version that I'm about to release. Thank you!

kkretzschmar commented 9 years ago

Hi Juan, Thanks! Concerning the INDIclient change. Could you resolve the string build problems? Before I am going to release a first version of the INDI client I'd like to do some changes on the CCDFrame interface. But I am trying to avoid that branches diverge so much .

jconejero commented 9 years ago

Hi Klaus,

Of course yes. I'm going to start working on this task later today. Hopefully it will be completed tomorrow.

Juan

On 10/07/2015 08:06 AM, kkretzschmar wrote:

Hi Juan, Thanks! Concerning the INDIclient change. Could you resolve the string build problems? Before I am going to release a first version of the INDI client I'd like to do some changes on the CCDFrame interface. But I am trying to avoid that branches diverge so much .

— Reply to this email directly or view it on GitHub https://github.com/PixInsight/PCL/pull/14#issuecomment-146086114.

jconejero commented 9 years ago

Hi Klaus,

I have just committed a first revision of your INDIClient module (PCL/src/modules/processes/contrib/kkretzschmar/INDIClient).

I have fixed all problems with new PCL versions, so the module compiles and builds perfectly for core version 1.8.4.

I have decided to make some drastic changes which I think are really necessary for the future development and integration of this module. If we defer these changes now, they will be much more painful and problematic when the module grows. I hope you'll agree with these changes and won't mind too much the extra work involved for you:

I have renamed some source files and class names. Basically, all files and classes starting with "PixInsightINDI" start now with "INDI" because the word "PixInsight" is redundant and doesn't add significant meaning IMO. For example, "PixInsightINDIClient" is now just "INDIClient". Other classes have been renamed differently to keep the whole architecture more coherent and consistent with identifiers exposed to the user. The most remarkable changes are "PixInsightINDIProcess", "PixInsightINDIInstance" and "PixInsightINDIInterface", which are now "INDIDeviceControllerProcess", "INDIDeviceControllerInstance" and "INDIDeviceControllerInterface", respectively. "IPixInsightINDIInstance" is now "IINDIDeviceControllerInstance".
The two exposed processes are now "INDIDeviceController" and "INDICCDFrame". You'll have to change test and driver scripts accordingly. Process parameter identifiers remain the same as before.
INDI source files released under the LGPL have been moved to an INDI subdirectory. This isolates third-party source files and makes clear which are not covered by our PCLL.
I have replaced IsoString with String in all cases where IsoString is not really necessary and/or was causing problems with function prototypes. In previous versions of PCL, the constructors String( const IsoString& ) and IsoString( const String& ) were not explicit, so automatic type conversions were allowed between both classes. Starting from PCL 2.1, these constructors are explicit to prevent some subtle bugs and performance issues caused by automatic conversions in PixInsight <= 1.8.3.
I have debugged the process interfaces, especially CCDFrameInterface, which I have reorganized and optimized with the use of NumericEdit controls. Interfaces are now fully scalable and implement correct alignments and spacings to follow PixInsight interface style guidelines.
I have replaced the use of std::ifstream and std::ofstream with pcl::File instances and static member functions. pcl::File is much more efficient, easier to use, and is completely platform-independent, so no more "#ifdef _WIN32" directives are necessary.
Similarly, std::auto_ptr and std::vector should be replaced IMO with pcl::AutoPointer and pcl::Array (or pcl::ReferenceArray, where appropriate), respectively. std::map could easily be replaced with a simple structure of PCL containers. I haven't made these changes, though.

Let's continue with the development of this exciting new tool set. Thank you so much for your excellent work, and please don't hesitate to tell me if you don't agree with the changes I've made.

kkretzschmar commented 9 years ago

Hi Juan, I agree with all of your changes. Actually some of them (renaming modules, moving INDI files to subdirectory,...) were on my TODO list and I am very grateful that you already have finished them;). In fact, I was unsure expecially with the styles of my interfaces, so your changes will help me to learn better the PixInsight style guidelines, thanks for that!

I'll check and give feedback on Friday, when I'll find time to build and test the new code.

What I am wondering about is that my newest module INDIMount is not part of your change. Maybe you missed to synch with the current "dev" branch? This module contains a stereographic projection of the sky and shows stars and the position of the telescope. It also contains queries to the Simbad database (so it requires internet connection) to retrieve coordinates of objects you want to take images from. The coordinates are then used to send corresponding GOTO commands to your mount, etc... It is very useful;).

Thanks again for your help!

Klaus

2015-10-13 19:05 GMT+02:00 Juan Conejero notifications@github.com:

Hi Klaus,

I have just committed a first revision of your INDIClient module (PCL/src/modules/processes/contrib/kkretzschmar/INDIClient).

I have fixed all problems with new PCL versions, so the module compiles and builds perfectly for core version 1.8.4.

I have decided to make some drastic changes which I think are really necessary for the future development and integration of this module. If we defer these changes now, they will be much more painful and problematic when the module grows. I hope you'll agree with these changes and won't mind too much the extra work involved for you:

-

I have renamed some source files and class names. Basically, all files and classes starting with "PixInsightINDI" start now with "INDI" because the word "PixInsight" is redundant and doesn't add significant meaning IMO. For example, "PixInsightINDIClient" is now just "INDIClient". Other classes have been renamed differently to keep the whole architecture more coherent and consistent with identifiers exposed to the user. The most remarkable changes are "PixInsightINDIProcess", "PixInsightINDIInstance" and "PixInsightINDIInterface", which are now "INDIDeviceControllerProcess", "INDIDeviceControllerInstance" and "INDIDeviceControllerInterface", respectively. "IPixInsightINDIInstance" is now "IINDIDeviceControllerInstance".

The two exposed processes are now "INDIDeviceController" and "INDICCDFrame". You'll have to change test and driver scripts accordingly. Process parameter identifiers remain the same as before.

INDI source files released under the LGPL have been moved to an INDI subdirectory. This isolates third-party source files and makes clear which are not covered by our PCLL.

I have replaced IsoString with String in all cases where IsoString is not really necessary and/or was causing problems with function prototypes. In previous versions of PCL, the constructors String( const IsoString& ) and IsoString( const String& ) were not explicit, so automatic type conversions were allowed between both classes. Starting from PCL 2.1, these constructors are explicit to prevent some subtle bugs and performance issues caused by automatic conversions in PixInsight <= 1.8.3.

I have debugged the process interfaces, especially CCDFrameInterface, which I have reorganized and optimized with the use of NumericEdit controls. Interfaces are now fully scalable and implement correct alignments and spacings to follow PixInsight interface style guidelines.

I have replaced the use of std::ifstream and std::ofstream with pcl::File instances and static member functions. pcl::File is much more efficient, easier to use, and is completely platform-independent, so no more "#ifdef _WIN32" directives are necessary.

Similarly, std::auto_ptr and std::vector should be replaced IMO with pcl::AutoPointer and pcl::Array (or pcl::ReferenceArray, where appropriate), respectively. std::map could easily be replaced with a simple structure of PCL containers. I haven't made these changes, though.

Let's continue with the development of this exciting new tool set. Thank you so much for your excellent work, and please don't hesitate to tell me if you don't agree with the changes I've made.

— Reply to this email directly or view it on GitHub https://github.com/PixInsight/PCL/pull/14#issuecomment-147779278.

jconejero commented 9 years ago

Hi Klaus,

Thank YOU for your work. I used the version of your code in the "need-revision" folder of our master branch, which now I see has been a mistake.

No problem, I'll download your dev branch to include the lacking files. I have revised your current code, and I don't see any conflict with the code that I have committed here, but I'll check that thoroughly. The INDIMount process is very nice!

I can't wait to see this module released :)

kkretzschmar commented 9 years ago

I'll download your dev branch to include the lacking files. I think it is already in the PCL dev branch. With https://github.com/PixInsight/PCL/pull/13 I pushed it directly to the PCL dev branch.

I have revised your current code, and I don't see any conflict with the code Great!

2015-10-14 9:59 GMT+02:00 Juan Conejero notifications@github.com:

Hi Klaus,

Thank YOU for your work. I used the version of your code in the "need-revision" folder of our master branch, which now I see has been a mistake.

No problem, I'll download your dev branch to include the lacking files. I have revised your current code, and I don't see any conflict with the code that I have committed here, but I'll check that thoroughly. The INDIMount process is very nice!

I can't wait to see this module released :)

— Reply to this email directly or view it on GitHub https://github.com/PixInsight/PCL/pull/14#issuecomment-147966952.

kkretzschmar commented 9 years ago

Hi Juan,

I'll check and give feedback on Friday, when I'll find time to build and test the new code.

I could successfully connect and control a local and remote indiserver. So seems to work ;). But as already mentioned the module is not the current one.

Klaus

PixInsight / PCL

Unix: Dump backtrace info in case of signals #14

The two exposed processes are now "INDIDeviceController" and "INDICCDFrame". You'll have to change test and driver scripts accordingly. Process parameter identifiers remain the same as before.

INDI source files released under the LGPL have been moved to an INDI subdirectory. This isolates third-party source files and makes clear which are not covered by our PCLL.

I have debugged the process interfaces, especially CCDFrameInterface, which I have reorganized and optimized with the use of NumericEdit controls. Interfaces are now fully scalable and implement correct alignments and spacings to follow PixInsight interface style guidelines.

I have replaced the use of std::ifstream and std::ofstream with pcl::File instances and static member functions. pcl::File is much more efficient, easier to use, and is completely platform-independent, so no more "#ifdef _WIN32" directives are necessary.