guider change
Jasem Mutlaq
mutlaqja at ikarustech.com
Fri Jun 5 08:00:05 BST 2020
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/84e7e8fb/attachment.htm>
More information about the Kstars-devel
mailing list