The CachingDms error is mostly a note for us developers. It has no real consequence on the functioning of KStars. It's just a warning that some trigonometric functions are being pointlessly recomputed, which is expensive if it is happening in the innermost loop with many stars, but is a non-issue otherwise. I've made sure that it doesn't happen in star rendering, which is bulk of the trigonometry that KStars does.

The assert failure, however, is more serious -- and I do not have it on my system. Could you tell me which projection you were using? Were you using Equatorial Coordinates ("Star globe view") or Horizontal Coordinates ("Horizontal View") in the view menu? I don't see that happening on my laptop (in debug mode, the assert failure would lead to a crash, and KStars is not being very crashy on my laptop)

Regards
Akarsh

You are correct, in debug mode, it does lead to a crash, which is why I have been running it in release mode. The error appears in horizontal mode as kstars is starting up. In star globe view it appears to not occur.

Hi

Unfortunately, I don't have time to work on this today -- I'm about to leave for an astronomy trip, so there's all the packing and stuff. If I do have time to work on it during the day over the next few days, I will. But if someone else wants to look into it sooner than I can, please do so.

Workaround: Avoid altaz grid and horizontal coordinates.

Some developer information: While I believe that the transition to CachingDms could be responsible for this, I haven't found any immediate evidence. The problem seems to be:
1. A line that returns a Vector2f(0, 0) in Projector::toScreenVec instead of failing an assert and crashing (added in Android transition efforts)
2. A call to NoPrecessIndex::JITUpdate() seems to mangle the azimuth. I guess this is the effect of calling HorizontalToEquatorial and then EquatorialToHorizontal when altitude = 90.0 (i.e. when alt = 90, azimuth is indeterminate).
3. It should be okay to set the azimuth to something finite just so computations don't turn out to become NaN all the time -- but I would refrain from doing it in toScreenVec, since it is called a million times per draw under certain settings.

Regards
Akarsh

Hi Akarsh,

Thats perfectly fine enjoy your trip! KStars has been perfectly usable on OS X, even in Horizontal mode (which I like better anyway). The error messages just happen at the beginning and then its fine. I agree the horizontal grid looks weird, but its fine if you don't turn on the horizontal grid

Thanks,

Rob

Updated instructions on how to Install KStars/INDI/Ekos and even GSC on OS X. Most of the commands can be simply copied and pasted to a terminal. Adam, I made the changes you suggested, please look over it and see if there is anything else you would add. I hope in the future that these instructions can be made simpler or even that we can make an installer and/or dmg. But for now, I'm just glad we got it all working!!

I've been following this thread remotely and it's awesome to see the progress. I think all of my pull requests have been integrated into the mainline so you shouldn't need to use my branch anymore (as mentioned earlier). I have a fix for the Debug mode crash which I'll post once I get my backup laptop working (beer on MBP keyboard = death).

Once we come up with a reliable build configuration I'd like to set up a Travis CI job to keep things running and upload nightly builds to S3 so everyone can have fresh OSX/MacOS builds without suffering through 6 hour Qt builds (!).

That sounds excellent! Yes, if you look at the updated directions, i am using the current kstars git instead of yours now. Mainly we are using your excellent instructions for the preparations with the environment variables.

As of right now I have kstars, indi, ekos, and gsc working on my system. I havent tested xplanet or astrometry with os x yet. There are still a few bugs, the biggest being the download new data problem.

And yes, not having to build every time would be awesome! Your assistance is most welcome!

Hi all,

Akarsh, enjoy your trip!
Rob, thanks for your update on the instructions. I want to add that I also had to export the directories as described by Sean before building libindi for it to find the homebrew qt5 installation. Maybe you also have a manual installation of qt5 so it works for you without the exports. In addition, I had to install cmake using homebrew before everything else. So maybe it would be good to move all the homebrew stuff to the top of the instructions. I would also add "brew install pkgconfig" there as I needed that for kstars to detect indi.
You could also add the changes to the qt5 formula I had to follow to make it build using homebrew in case someone wants to try before this is fixed officially.
I will also try to build kstars and indi on macos 10.12 again if I can, so for now you could also add a remark that the instructions are only tested on 10.11 yet.
Also, thanks for the gsc instructions! I haven't tried them yet.
And Sean, thanks for your initial work! It would indeed be great if the whole process could be eased in the end. As most of the dependencies are installed using homebrew already, maybe it would be possible to also make indi and kstars available through homebrew somehow in the end? I have absolutely no experience with that however and homebrew doesn't seem that reliable on recent versions of OS X.

Hi Adam,

No, you are right, when I installed libindi from source, I definitely used the exports because otherwise, it doesn't know where things are. I believe I already had cmake on my mac, and I don't remember installing pkgconfig, but I do see both of them in my home-brew /usr/local/cellar directory so I don't know when I did that, so you might be right on that too. I just added all this to the instructions. Please take a look at them again.



Thanks,

Rob

Hi Rob,
I think that should be easy to follow, well done! Just to save the reader some searching, you could add the directory of the qt5 formula which is a bit hard to find:
/usr/local/Homebrew/Library/Taps/homebrew/homebrew-core/Formula/qt5.rb

I have yet to try gsc (and astrometry.net), but from your instructions, I don't see a reason why it shouldn't work.

Thanks for the nice write-up!
Adam

do you possibly have a link to somewhere the fix is discussed so I can put a link in the instructions too?

Yes, the fix is somewhere in the last third of the discussion here:
github.com/Homebrew/homebrew-core/issues/4841
and the issue is being further tracked here:
github.com/Homebrew/homebrew-core/issues/5391