guider change

[Jasem Mutlaq]

Hy,

Yes, I agree. We need to avoid any unnecessary duplications of course. If
there is quite a bit of overlap between KStars and the library, then
perhaps integration is the right thing to do. However, Robert might then
have to deal with two codebases instead of one. So we'll need to weigh in
the options.

--
Best Regards,
Jasem Mutlaq



On Fri, Jun 5, 2020 at 10:25 AM Hy Murveit <murveit at gmail.com> wrote:

> 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/9cf2b2c6/attachment-0001.htm>