KStars v3.5.0 Release Date?

Hy Murveit murveit at gmail.com
Tue Nov 10 04:18:57 GMT 2020 

*Polar Align*
I just tried polar alignment and 2 things were a litle bit worse than I
remembered:

1) The slew, capture and solver were quick, but after the successful solve
it said: "Please wait while WCS data is processed" and this took 10-20s per
iteration. I don't ever remember this delay before.

2) The process wasn't as reliable as it used to be. It used to polar
aligned really reliably (e.g after doing it, then retrying, it would tell
me I was withing 30 arc-seconds). Now, though I moved the target just to
where I wanted, it would tell me I was off by 1.5 arc-minutes (twice).

Anything change with polar align recently? Could this be the StellarSolver
solving near the pole? Anyone else tried this? Is there a particular
configuration I should use for this?

*Flats*
Took a bunch of flats and saw a minor issue in the fitsviewer hfr display.
Sent MR https://invent.kde.org/education/kstars/-/merge_requests/127

Hy



On Mon, Nov 9, 2020 at 6:39 PM Hy Murveit <murveit at gmail.com> wrote:

> Jasem,
>
> I see you removed the meridian flip options set in the polar alignment,
> which is a good thing. Thanks.
> However, there's still
>      Options::setAutoWCS(false);
>      Options::setAstrometrySolverWCS(true);
> which might benefit from the MR I sent.
> Do you want to me to withdraw my MR and you can deal with that as you see
> fit, or do you want me to modify my MR
> to drop the exectureMeridianFlip, but still keep those two?
> Thanks,
> Hy
>
> On Mon, Nov 9, 2020 at 2:51 PM Hy Murveit <murveit at gmail.com> wrote:
>
>> I looked into the issue with executeMeridianFlip unchecking itself, and,
>> yes, it was in the polar align code.
>> I have submitted an MR, see
>> https://invent.kde.org/education/kstars/-/merge_requests/126 (Jasem,
>> please double check for me that this makes sense to you.)
>> As I say in the MR comment, but I feel it's important enough to repeat
>> here:
>>
>> *Honestly, this isn't a 100% fix. I believe it is a fix worth doing, as
>> it will solve the problem much of the time (as long as the user explicitly
>> exits the polar align).*
>>
>> *However, if the user simply leaves polar align without clicking 'done'
>> (e.g. by just clicking on the Solution Results sub-tab) then his/her flags
>> won't be restored. Polar align should not be messing with the user's
>> Options--there should be another way of preventing the MF. That said, it's
>> too close to the release for me (with limited knowledge of align) to
>> re-wire the thing. I'd recommend that someone more familiar with align
>> refactors/re-organizes at some point so that Options::executeMeridianFlip()
>> is never changed inside of polar align.*
>>
>> Hy
>>
>> PS I did find an odd issue while doing this.
>>
>> Stderr or stdout spewed hundreds of lines like:
>>
>> Error: seeking, reading, or closing file
>> /tmp/internalSextractorSolver_21.solved: Invalid argument
>> Error: seeking, reading, or closing file
>> /tmp/internalSextractorSolver_21.solved: Invalid argument
>> Error: seeking, reading, or closing file
>> /tmp/internalSextractorSolver_21.solved: Invalid argument
>> ...
>>
>> when I tried to polar align with the simulator (I was using profile:
>> "Internal SEP/Internal Solver/4-SmallScaleSolving"). Does this ring a bell?
>>
>> On Mon, Nov 9, 2020 at 1:27 PM Hy Murveit <murveit at gmail.com> wrote:
>>
>>> I would say it's been pretty solid for me the last few days. I've tried
>>> to test every night when possible. Good work folks!
>>>
>>> Two things I wanted to bring up:
>>>
>>> #1. There was one thing I was looking into, going to try again right now.
>>> I think this would be a good thing to fix for 3.5.0 if I can find the
>>> fix and it is straightforward.
>>> Occasionally, though I try to set it so that it's always enabled, the
>>> Meridian Flip Checkbox sometimes
>>> mysteriously is not set when I start Ekos.
>>>
>>> This has led to missed flips & a few tripod collisions for me over the
>>> past year (though now I mostly always
>>> remember to check if it's on). A friend recently privately reported to
>>> me that the same thing happened to him last week.
>>> I suspect the polar alignment code is to blame, (I noticed it unchecks
>>> and later re-checks the option) but not sure yet.
>>>
>>> #2. I'm not thrilled that Align's star-extraction profiles default to a
>>> profile labeled "*Default profile. Generic and not optimized for any
>>> specific purpose*".
>>> I would rather it defaulted to one of the profiles optimized for
>>> Align--e.g. Small Scale Solving. Or, perhaps some middle
>>> ground between Small Scale and Large Scale. What do you think?
>>>
>>> Hy
>>>
>>> On Mon, Nov 9, 2020 at 1:04 PM Jasem Mutlaq <mutlaqja at ikarustech.com>
>>> wrote:
>>>
>>>> Hello Folks,
>>>>
>>>> So back to this topic, any major blockers to the KStars 3.5.0 release
>>>> now?
>>>>
>>>> 1. Remote Solver should be fixed now.
>>>> 2. StellarSolver Profiles are more optimized now.
>>>> 3. Handbook not updated yet, but we can probably work on this shortly.
>>>> 4. Couple of pending MRs to take care of.
>>>>
>>>> How about Friday the 13th?
>>>>
>>>> --
>>>> Best Regards,
>>>> Jasem Mutlaq
>>>>
>>>>
>>>>
>>>> On Thu, Nov 5, 2020 at 3:41 AM Robert Lancaster <rlancaste at gmail.com>
>>>> wrote:
>>>>
>>>>> Hi Eric,
>>>>>
>>>>> Ok so then we would be changing the way we do version numbering with
>>>>> this, right?
>>>>> I believe now we typically add features in each new iteration 3.4.1,
>>>>> 3.4.2, etc etc
>>>>> and when it is really big like StellarSolver, then we make it a big
>>>>> release like 3.5.0
>>>>>
>>>>> With this new paradigm, we wouldn’t put new features into the master
>>>>> of the main 3.5 branch
>>>>> But instead we would work on a new 3.6 branch, and then bug fixes
>>>>> would go into the 3.5 branch
>>>>> to make each new minor release, like 3.5.1, 3.5.2 etc.
>>>>>
>>>>> Do I have this correct?
>>>>>
>>>>> If this is right, then it would be longer before users see new
>>>>> features in the main branch, but the
>>>>> tradeoff is that the main branch would have a LOT more stability.  I
>>>>> see this as a big positive.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Rob
>>>>>
>>>>> > On Nov 4, 2020, at 5:54 PM, Eric Dejouhanet <
>>>>> eric.dejouhanet at gmail.com> wrote:
>>>>> >
>>>>> > Hello Hy,
>>>>> >
>>>>> > Version 3.5.0 is only the beginning of the 3.5.x series, with more
>>>>> > bugfixes on each iteration (and possibly, only bugfixes).
>>>>> > So I have no problem leaving unresolved issues in 3.5.0.
>>>>> >
>>>>> > For instance, the Focus module now has a slight and unforeseeable
>>>>> > delay after the capture completes.
>>>>> > The UI reflects the end of the capture only, not the end of the
>>>>> detection.
>>>>> > This makes the UI Focus test quite difficult to tweak, as running an
>>>>> > average of the HFR over multiple frames now has an unknown duration.
>>>>> > Right now, the test is trying to click the capture button too soon 2
>>>>> > out of 10 attempts.
>>>>> > But this won't block 3.5 in my opinion (and now that I understood the
>>>>> > problem, I won't work on it immediately).
>>>>> >
>>>>> > In terms of reporting problems, the official way is stil
>>>>> bugs.kde.org,
>>>>> > but there's quite a cleanup/followup to do there.
>>>>> > I'd say we can use issues in invent.kde.org to discuss planned
>>>>> > development around a forum/bugzilla issue or invent proposal (like
>>>>> > agile stories).
>>>>> > There are milestones associated with several issues (although I think
>>>>> > they should be reviewed and postponed).
>>>>> > And we can certainly write a punchlist: check the board at
>>>>> > https://invent.kde.org/education/kstars/-/milestones/3
>>>>> >
>>>>> > Le mer. 4 nov. 2020 à 22:38, Hy Murveit <murveit at gmail.com> a écrit
>>>>> :
>>>>> >>
>>>>> >> Eric,
>>>>> >>
>>>>> >> I would add to your list:
>>>>> >>
>>>>> >> - KStars Handbook (review update sections to reflect 3.5.0) and
>>>>> finally (perhaps manually if necessary) put the latest handbook online.
>>>>> >>
>>>>> >> - Review the extraction settings. I spent a bit of time looking at
>>>>> the default HFR settings, and based on some experimentation (truth be told,
>>>>> with a limited amount of data) adjust things a little differently than my
>>>>> first guess (which was basically focus' settings).
>>>>> >> Rob: My intuition is that I should adjust the default StellarSolver
>>>>> star-extraction settings for Focus and Guide as well in
>>>>> stellarsolverprofile.cpp. I don't know whether you've already verified
>>>>> them, and want to release them as they are, or whether they are a first
>>>>> shot and you'd welcome adjustment?
>>>>> >>
>>>>> >> Also, Eric, I suppose I should be adding these things here:
>>>>> https://invent.kde.org/education/kstars/-/issues
>>>>> >> Is that right? Sorry about that--ok, after this thread ;) But
>>>>> seriously, your email is a good summary, and from that link
>>>>> >> it doesn't seem as easy to see which are "must do by 3.5.0" and
>>>>> which are "nice to have someday".
>>>>> >> A 3.5.0 punchlist would be a nice thing to have.
>>>>> >>
>>>>> >> Hy
>>>>> >>
>>>>> >> On Wed, Nov 4, 2020 at 12:58 PM Eric Dejouhanet <
>>>>> eric.dejouhanet at gmail.com> wrote:
>>>>> >>>
>>>>> >>> Hello,
>>>>> >>>
>>>>> >>> Where do we stand now in terms of bugfixing towards 3.5.0?
>>>>> >>>
>>>>> >>> - StellarSolver has all features in, and 1.5 is finally out at
>>>>> Jasem's PPA.
>>>>> >>> - However Gitlab CI still complains about that lib package (see
>>>>> >>> https://invent.kde.org/education/kstars/-/jobs/75941)
>>>>> >>> - Unitary tests are being fixed progressively, mount tests are
>>>>> down to
>>>>> >>> ~20 minutes (yeees!)
>>>>> >>> - From my tests, the remote Astrometry INDI driver is not usable
>>>>> >>> anymore from Ekos.
>>>>> >>> - The issue raised with flat frames is confirmed fixed (at least
>>>>> by me).
>>>>> >>> - Meridian flip is OK (but I had not enough time to test TWO flips
>>>>> in a row).
>>>>> >>> - Memory leaks are still being researched in Ekos.
>>>>> >>> - There is an issue when duplicating an entry in a scheduler job,
>>>>> >>> where the sequence associated is copied from the next job.
>>>>> >>>
>>>>> >>> Could we get a 3.6 branch where we will merge development of new
>>>>> features?
>>>>> >>> And master for bugfixing 3.5.x until we merge 3.6 new features in?
>>>>> >>> (we'd still have to port bugfixes from master to 3.6)
>>>>> >>> I don't think the opposite, master for 3.6 and a separate living
>>>>> >>> 3.5.x, is doable in the current configuration (build, ppas,
>>>>> MRs...).
>>>>> >>>
>>>>> >>> --
>>>>> >>> -- eric.dejouhanet at gmail.com - https://astronomy.dejouha.net
>>>>> >
>>>>> >
>>>>> >
>>>>> > --
>>>>> > -- eric.dejouhanet at gmail.com - https://astronomy.dejouha.net
>>>>>
>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kstars-devel/attachments/20201109/907ec9b9/attachment-0001.htm>

More information about the Kstars-devel mailing list