guider change

[Hy Murveit]

Jasem,

I fully support that. I just ask about the timeframe for the Robert's
library. Do you think it can be integrated in the next week or two? If so,
great. If it looks like a month, or realistically two, why not do it in
stages if the fits changes are small?

WRT Robert's library, I think the major discussion has to be (a) will it be
an external library, and if it is, how will the replication of important
classes and structs be dealt with? I think this needs to be addressed soon
in order to make progress with sexysolver.

Hy

On Fri, Jun 5, 2020 at 12:00 AM Jasem Mutlaq <mutlaqja at ikarustech.com>
wrote:

> This is very exciting Hy and I'm looking forward to testing your new
> algorithm! I believe Robert's library is going to be a major component of
> Ekos and therefore I'd prefer it if we base all the current SEP algorithm
> on it. There is already another PR from Eric that I asked the same. So the
> most critical thing now is to incorporate the libsexysolver either directly
> or as a 3rd party library into KStars and start integrating it with any
> functionality that would require sextracting or solving.
>
> By no means this is a simple task, and I think it would require the
> collaboration of core KStars developers to aid Robert in this integration.
> --
> Best Regards,
> Jasem Mutlaq
>
>
>
> On Fri, Jun 5, 2020 at 8:16 AM Robert Lancaster <rlancaste at gmail.com>
> wrote:
>
>> Sounds good to me
>>
>> Sent from my iPhone
>>
>> On Jun 5, 2020, at 1:03 AM, Hy Murveit <murveit at gmail.com> wrote:
>>
>> 
>> Rob: Of course I will use your kstars clone and try and integrate my new
>> code with your new system. I can start that soon--this weekend perhaps.
>> However, before I start, I only ask that you (a) rebase your clone to the
>> newest KStars (you'll have to continually do that anyway, may as well start
>> now), and (b) send me doc on the API for star detection--or better, add it
>> to the sexysolver.h file.
>>
>> Rob and Jasem: The reason I hesitate to wait, is I really don't think it
>> will be that soon that Rob's code is fully integrated. I think there are
>> some basic issues to work through (see below) that will take time, and
>> there's no sense rushing it. Once Rob is ready for the merge, I think it
>> will be step by step, where we start-out with both systems and the existing
>> SEP is phased-out commit-by-commit. My system can be the first commit where
>> SEP starts getting phased out, and I can do that PR, but I'd prefer to
>> start with the legacy system and not rush Rob's work.
>>
>> I think the big issue to work through re sexysolver is whether it is a
>> stand-alone library downloaded and used, vs incorporated into KStars. I
>> (selfishly) would prefer the later, but I understand the attraction of the
>> former. The problem with a standalone is that there will be (or at least is
>> right now) significant duplication of important data structures -- stars,
>> fits file info, RA, DEC representations. That duplication is nasty and can
>> cause issues when one is changed and not the other.
>>
>> I am doing a code-review with Rob. It's starting slowly as we're both
>> inexperienced with the github web-based review process, but I'm using the
>> Google code-review methodology, and I'm hopeful I can contribute to Rob's
>> work. I definitely support sexysolver, but I don't think it should be
>> rushed, and I think this separate-vs-integrated question needs to be worked
>> out carefully, and I don't think other contributions should necessarily
>> wait a month or two until it's ready.
>>
>> I have submitted my code as a PR so you can get a background about what
>> I've been working on, and hopefully to have it integrated with KStars (as
>> well as me experimentally integrating it into Rob's tree).
>>
>> Hy
>>
>> On Thu, Jun 4, 2020 at 3:47 PM Robert Lancaster <rlancaste at gmail.com>
>> wrote:
>>
>>> Well my thoughts Hy are that you are currently working with me on the
>>> code review.  I believe that right now it is ready for you to start trying
>>> the code for an intended purpose like this and you could probably try using
>>> it for your planned implementation as an experiment.  Maybe by trying to
>>> use it in this way, we discover more things that could be done to make it
>>> better.  We might change some things as you make suggestions to me, but I
>>> imagine that it isn’t going to change all that much.  The name could change
>>> and maybe some of the functions could change names or something, but I
>>> don’t think that is a problem if you don’t.  But of course doing it this
>>> way means it takes a little longer to get out there and get tested.
>>>
>>> I should have a lot more time on my hands shortly because my students
>>> are finishing up and we are ending the year.  We might be able to finish
>>> things up pretty quickly.
>>>
>>> > On Jun 4, 2020, at 6:18 PM, Hy Murveit <murveit at gmail.com> wrote:
>>> >
>>> > Jasem, Rob,
>>> >
>>> > I've been testing my new guide algorithms for a while and I think it's
>>> ready for me to start the PR process. My changes should not affect current
>>> users who don't 'opt in' to my new algorithms. It would be an option to the
>>> guider, in the same list as the current Smart/SEP/Fast/... choices. I would
>>> love to start getting people to test, if they want.
>>> >
>>> > I'm writing to ask your advice because I've been waiting for Rob's
>>> changes to sep. I do depend on getting some new information out of sep, and
>>> configuring the extractor a certain way. Thus my changes include some
>>> changes to fitssepextactor.cpp/h. I don't change existing functionality,
>>> but need information that wasn't previously released.  My gut is that it
>>> may be a while before Rob releases/integrates sexysolver into KStars.
>>> >
>>> > Here are 3 possibilities:
>>> >
>>> > (a) I go ahead and send in a MR and hopefully integrate this into
>>> KStars in the next week or two. I would work with Rob to integrate my
>>> changes when the time comes for SexySolver to be merged in. I could even do
>>> it in advance of Rob's eventual MR using a clone of Rob's code.
>>> > (b) I could add my MR as a WIP, so you or other could look at it,
>>> assuming Rob's not too far off.
>>> > (c) I hold off doing anything.
>>> >
>>> > What do you think?
>>> > Hy
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kstars-devel/attachments/20200605/dd29ad8e/attachment.htm>