×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

AstroPi3 Scripts revised

  • Posts: 2876
  • Thank you received: 809
I’m glad you got it fixed Hy.

Some other folks have given me some ideas of how to make the script even better recently. I hope I will have some time soon to make some of those improvements, but I have had a lot of grading to do recently. My students have to come first. But I will get back to this soon.
4 years 5 months ago #44630

Please Log in or Create an account to join the conversation.

  • Posts: 73
  • Thank you received: 8
I purchased a second RiP4 yesterday and was going to mess around with installing various images and try to build my own setup but this one looks so good I decided to follow the instructions on first page and I am now looking at a desktop that seems to work just fine!

My question is about updating ekos/indi/kstars. Jasem has been very helpful recently squashing some bugs in a camera driver I use. I've seen him remote to my system (I have stellarmate on my main rp4) and update it from a build minutes old.

How can I get this system to update to nightly builds? I believe I understand that I need to "git" from the source code on git hub and build it. How do I do that? Can some one help me with the command lines to get latest and compile it? Assuming I don't need other software to compile.

Very new to this.
4 years 5 months ago #44662

Please Log in or Create an account to join the conversation.

  • Posts: 1309
  • Thank you received: 226

Replied by Andrew on topic AstroPi3 Scripts revised

The script will build the latest nightly kstars. So if the fixes are in the main git branch, you should be ok.
4 years 5 months ago #44663

Please Log in or Create an account to join the conversation.

  • Posts: 73
  • Thank you received: 8
Oh ok great!

One thing more and unrelated to kstars. Conky is not transparent on the desktop. Has a black background. I didn't change anything. Everything is still brand new install scent.

I looked at the .conf file and nothing there about transparency.
4 years 5 months ago #44664

Please Log in or Create an account to join the conversation.

  • Posts: 19
  • Thank you received: 1
Not sure if I have a bug here Rob, but could do with a pointer or two if not.

Seems INDI/EKOS can't see my Atik cameras, yet they seem to have drivers in the right place, but then I am only just beginning my Linux Learning...

Posted EKOS output here after searching for asolution on the boards, it contains a link to the initial thread I raised wehen I first got stuck:

indilib.org/forum/ekos/5710-ekos-setup-q...noobie.html?start=24
4 years 5 months ago #44962

Please Log in or Create an account to join the conversation.

  • Posts: 1208
  • Thank you received: 559

Replied by Hy Murveit on topic AstroPi3 Scripts revised

Rob,

One more thing. I have started configuring the KStars part of the install script (could do this with Indi & Phd2 too, I suppose) to compile optimized. Currently your script compiles debug binaries.

That is, I re-ran cmake with the following flag
-DCMAKE_BUILD_TYPE=Release
and then recompiled the entire system with my standard 'make -j 6 kstars'

This results in dramatic speedups for KStars on my RPi4 4Gb. I've suggested to Jasem that he consider releasing this way; he will look into it.
You (and anyone else adventurous) should try and give it a shot. It does make the compile a little slower, but once compiled, it's really much faster.
Let me know what you think!
4 years 5 months ago #45061

Please Log in or Create an account to join the conversation.

  • Posts: 1309
  • Thank you received: 226

Replied by Andrew on topic AstroPi3 Scripts revised


I'm not sure I follow. Are you claiming that applications get a performance boost when compiled this way? Please explain.
4 years 5 months ago #45068

Please Log in or Create an account to join the conversation.

  • Posts: 2876
  • Thank you received: 809
This is an interesting idea. I'm not sure about it though. Are you saying there is a speed improvement in building the program or a speed improvement in running the program?

I understand that typically software is distributed as a "release" build instead of a "debug" build. But with KStars I have always built it as debug due to the fact that it is open source software that is continuously under development. So if there is a crash or issue, I would want it to have all the debug symbols so that we can get a detailed backtrace of the crash. Doesn't compiling as a "Release" build mean that the debug symbols would not be available? I think that would be an issue for diagnosing potential problems.
4 years 5 months ago #45069

Please Log in or Create an account to join the conversation.

  • Posts: 1208
  • Thank you received: 559

Replied by Hy Murveit on topic AstroPi3 Scripts revised

@Ihoujin: When you run the compiler the standard way, it does NOT make much of an effort to make your code run quicker (e.g. by noticing that a value you just computed will be needed again soon and keeping it on hand, avoiding a trip to memory. There are many optimizations, see the like below). It simply tries to make the compiler run quickly and accurately. Depending on the code, you can get dramatic improvements with -O2 or -O3 flags to g++. For instance, I noticed that stretching images from my camera in kstars' fitsviewer goes from about 0.5s - 1.0s / image to something like 0.15s/image. I've been looking at the speed of the fitsviewer computations, and those things get much faster with optimization. Of course, code that runs fast anyway, or waits for cameras or the UI won't be affected much. I believe it is standard practice to release optimized code, however, see Rob's point below. Here's a link to the g++ page on its optimizer and what it might try improve: gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html

Rob: Debug vs execution speed is always a tradeoff. However (a) you can still have all the logs you've had before, and (b) you don't have to strip away the symbol tables, they can mostly still be there and still be used with optimized code. it's just that it's possible that the compiler, depending on its options, will change the order of certain operations, if that doesn't effect the end result but allows for quicker code. I believe that any commercial code you currently use is optimized. I think that for the most part it won't affect debugging you do for other users. For debugging on your own system, sure you can compile with debug flags while developing and debugging if you prefer. The main gotcha is that it is possible that the optimized code, which let's say is optimized correctly but is a little bit different than the non-optimzed code, can expose (or hide) bugs. That is, say you have a memory error (you overwrite some pointers in memory). The debug and optimize versions may react differently in one version than the other, so errors you see in optimized code may not show up in non-optimized code, or vica versa. However, I'd say this is relatively rare and worth the price paid for getting much quicker overall performance. Try it!
4 years 5 months ago #45073

Please Log in or Create an account to join the conversation.

  • Posts: 1208
  • Thank you received: 559

Replied by Hy Murveit on topic AstroPi3 Scripts revised

Rob: and, yes, I was saying that there should be a noticeable improvement in execution speed. Compile times will be longer.
4 years 5 months ago #45074

Please Log in or Create an account to join the conversation.

  • Posts: 472
  • Thank you received: 165
There is CMAKE_BUILD_TYPE=RelWithDebInfo which is a bit of both, you get symbol info so you get useful stack traces, but the code still is optimized. I've found it a good tradeoff between speed when actually using the program and still being able to pinpoint issues if they happen and then possibly switch to debug build if the cause isn't clear and the problem can be reproduced.
4 years 5 months ago #45077

Please Log in or Create an account to join the conversation.

  • Posts: 1309
  • Thank you received: 226

Replied by Andrew on topic AstroPi3 Scripts revised

For me, and many users, debugging is not something I'd get too into, so I would happily try this for myself. Might I suggest creating a new thread under development for this idea.
4 years 5 months ago #45080

Please Log in or Create an account to join the conversation.

Time to create page: 0.571 seconds