KStars v3.5.0 Release Date?
Wolfgang Reissenberger
wolfgang at openfuture.de
Tue Oct 20 17:17:19 BST 2020
Fully agreed, no need to hurry!
This morning I discovered that flats aren’t working. Hopefully I can push the fix as MR this evening.
Wolfgang
> Am 20.10.2020 um 18:11 schrieb Hy Murveit <murveit at gmail.com>:
>
> I'd like to suggest that since the main KStars branch still core dumps while guiding (every time for me) and perhaps there are other issues with flats, we should push back the release date for at least two weeks. I believe we need a stable two weeks of user testing before any major release.
>
> I know Jasem and Robert are working very hard to fix this, and in no way is this a knock on their work, just a desire to make this a stable release.
>
> I would propose that there only be bug fix commits during those two weeks.
>
> Comments?
> Hy
>
> On Thu, Oct 15, 2020, 9:55 PM Hy Murveit <murveit at gmail.com <mailto:murveit at gmail.com>> wrote:
> Core dump again with the 'load all indexes' flag unchecked. Am running in gdb now.
> ...
>
> Also, it doesn't seem to remember that checkmark, nor the profile type (top menu under ""Options Profiles")--please add that to the todo list too.
> Also, it's my impression that the solver takes longer than it used to. Could it be that the binning isn't being honored?
> Perhaps you derived your speed by threading, and I'm defeating that by unchecking the box?
> ...
>
> Here's the backtrace, as it crashed again--this time in GDB.
>
> I guess I'm done testing for the night.
> Hy
>
> log-odds ratio 0.335153 (1.39815), 0 match, 0 conflict, 0 distractors, 39 index.
> RA,Dec = (318.284,63.9039), pixel scale 3.84851 arcsec/pix.
> log-odds ratio 0.335153 (1.39815), 0 match, 0 conflict, 0 distractors, 39 index.
> RA,Dec = (318.284,63.9039), pixel scale 3.84851 arcsec/pix.
> log-odds ratio 34.6274 (1.09262e+15), 18 match, 0 conflict, 120 distractors, 37 index.
> RA,Dec = (325.282,58.0472), pixel scale 3.97646 arcsec/pix.
> Hit/miss: Hit/miss: ----+-----------+--+--+------+---------------+---+------+----+--+--+---------------+-----------+----
> [Thread 0x83925090 (LWP 1384) exited]
>
> Thread 38 "Thread (pooled)" received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x92c2c090 (LWP 31265)]
> belong (corenb=corenb at entry=0, coreobjlist=coreobjlist at entry=0xb42b9afc <debobjlist>, shellnb=shellnb at entry=0,
> shellobjlist=0x47d6cbc) at /home/pi/Projects/stellarsolver/stellarsolver/sep/deblend.c:378
> 378 int xc=PLIST(cpl+cobj->firstpix,x), yc=PLIST(cpl+cobj->firstpix,y);
> (gdb) bt
> #0 belong (corenb=corenb at entry=0, coreobjlist=coreobjlist at entry=0xb42b9afc <debobjlist>,
> shellnb=shellnb at entry=0, shellobjlist=0x47d6cbc)
> at /home/pi/Projects/stellarsolver/stellarsolver/sep/deblend.c:378
> #1 0xb4217178 in deblend (objlistin=0xa8cb2b00, objlistin at entry=0x92c2b1c4, l=l at entry=0, objlistout=0x0,
> objlistout at entry=0x92c2b0c4, deblend_nthresh=75328520, deblend_nthresh at entry=0,
> deblend_mincont=0.0050000000000000001, minarea=minarea at entry=5)
> at /home/pi/Projects/stellarsolver/stellarsolver/sep/deblend.c:125
> #2 0xb4217b4c in sortit (info=info at entry=0xa8cc52b0, objlist=0x92c2b1c4, objlist at entry=0x92c2b1bc, minarea=5,
> minarea at entry=2, finalobjlist=0xa8c296d8, finalobjlist at entry=0x0, deblend_nthresh=32,
> deblend_nthresh at entry=3, deblend_mincont=0.0050000000000000001, gain=1)
> at /home/pi/Projects/stellarsolver/stellarsolver/sep/extract.c:777
> #3 0xb4219e80 in sep_extract (image=0x5b8d6c <NewFOV::slotDetectFromINDI()+324>, image at entry=0x8ecf2008,
> thresh=thresh at entry=54.3094788, thresh_type=thresh_type at entry=1, minarea=2, minarea at entry=5,
> conv=0xa8cc7100, convw=<optimized out>, convw at entry=3, convh=convh at entry=3, filter_type=<optimized out>,
> filter_type at entry=0, deblend_nthresh=32, deblend_cont=0.0050000000000000001, clean_flag=1, clean_param=1,
> catalog=0x92c2b514, catalog at entry=0x92c2b50c)
> at /home/pi/Projects/stellarsolver/stellarsolver/sep/extract.c:632
> #4 0xb41edc34 in InternalSextractorSolver::runSEPSextractor (this=this at entry=0xa8cb9e70)
> at /usr/include/c++/8/cmath:475
> #5 0xb41eed90 in InternalSextractorSolver::sextract (this=0xa8cb9e70)
> at /home/pi/Projects/stellarsolver/stellarsolver/internalsextractorsolver.cpp:94
> #6 InternalSextractorSolver::run (this=0xa8cb9e70)
> at /home/pi/Projects/stellarsolver/stellarsolver/internalsextractorsolver.cpp:137
> #7 0xb420ddd4 in StellarSolver::extract (this=0x9e403bd0, calculateHFR=calculateHFR at entry=true, frame=...)
> at /usr/include/c++/8/bits/atomic_base.h:390
> #8 0x00c4c4c8 in FITSSEPDetector::findSourcesAndBackground (this=0x92c2b89c, boundary=..., bg=bg at entry=0x0)
> at /usr/include/arm-linux-gnueabihf/qt5/QtCore/qrect.h:60
> #9 0x00c4a32c in QtConcurrent::StoredMemberFunctionPointerCall2<bool, FITSSEPDetector, QRect const&, QRect, SkyBackground*, decltype(nullptr)>::runFunctor() (this=0x424be80)
> at /usr/include/arm-linux-gnueabihf/qt5/QtConcurrent/qtconcurrentstoredfunctioncall.h:911
> #10 0x004df0f0 in QtConcurrent::RunFunctionTask<bool>::run (this=0x424be80)
> at /usr/include/arm-linux-gnueabihf/qt5/QtCore/qmutex.h:240
> #11 0xb4855f30 in ?? () from /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5
> #12 0xb485eb58 in ?? () from /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5
> #13 0xb42c2494 in start_thread (arg=0x92c2c090) at pthread_create.c:486
> #14 0xb397c578 in ?? () at ../sysdeps/unix/sysv/linux/arm/clone.S:73 from /lib/arm-linux-gnueabihf/libc.so.6
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> (gdb)
>
>
>
>
> On Thu, Oct 15, 2020 at 9:36 PM Hy Murveit <murveit at gmail.com <mailto:murveit at gmail.com>> wrote:
> OK, you knew this would happen 10 minutes after I sent that...
>
> log-odds ratio 0.69992 (2.01359), 0 match, 0 conflict, 0 distractors, 17 index.
> RA,Dec = (309.748,70.6162), pixel scale 4.38547 arcsec/pix.
> log-odds ratio 0.69992 (2.01359), 0 match, 0 conflict, 0 distractors, 17 index.
> RA,Dec = (309.748,70.6162), pixel scale 4.38547 arcsec/pix.
> log-odds ratio 6.76328 (865.472), 0 match, 0 conflict, 0 distractors, 14 index.
> RA,Dec = (327.788,50.727), pixel scale 4.50653 arcsec/pix.
> log-odds ratio 6.76328 (865.472), 0 match, 0 conflict, 0 distractors, 14 index.
> RA,Dec = (327.788,50.727), pixel scale 4.50653 arcsec/pix.
> log-odds ratio 53.7431 (2.18938e+23), 18 match, 0 conflict, 100 distractors, 37 index.
> RA,Dec = (325.28,58.0466), pixel scale 3.97665 arcsec/pix.
> Hit/miss: Hit/miss: +------+----+--------++------------+-+---+-----+--------++--+-----------------++--------------+-----
> Segmentation fault
>
>
> It's hard to say what caused it, but if I had to guess, I'd say it was run out of memory.
> It happened during a meridian flip, and perhaps StellarSolver is too greedy with memory.
> I'll uncheck that load all indexes flag and continue.
>
> Hy
>
>
>
>
> On Thu, Oct 15, 2020 at 9:23 PM Hy Murveit <murveit at gmail.com <mailto:murveit at gmail.com>> wrote:
> Some good news.
>
> Tonight, for the first time, I was able to start up the latest (built from latest source as of an hour before I wrote this) KStars and StellarSolver on my RPi4, without issues (so far).
> I've polar aligned, plate solved, focused, guiding, ... and so far all good. I have never been able to get to this point with this new software, so there's definitely been progress.
>
> Still need to bang on it for several nights, I'm sure, but thanks for the hard work!
>
> FWIW, I am not using any of the safeguards I was asked to put in (e.g. I have "Use Scale" and "Load All Indexes In Memory" both checked).
>
> Hy
>
> On Wed, Oct 14, 2020 at 12:35 PM Hy Murveit <murveit at gmail.com <mailto:murveit at gmail.com>> wrote:
> Rob,
>
> Thanks for your hard work on this!
>
> As we discussed privately, I have been unable to get plate-solving to work with the internal StellarSolver on my RPi4.
> Do you think this is unique to me--that is, have others been able to do so? If this a general problem, then I think Oct 22 is too aggressive a release target, as we should give our advanced users at least a few weeks of using the software more-or-less successfully on their target environments. If this is something specific to me, but others are successfully plate-solving on RPi's, then perhaps I'm over-reacting.
>
> FWIW, I just tried to send the full bug report I sent you out to this devel list, but it got blocked (I guess one of my screenshots was too large).
> Hopefully the moderator will accept my thread soon, and it will be available to all.
>
> Until that happens, where should we post bugs related to 3.5.0? This thread? New threads on kstars-devel?
>
> Again, I want to emphasize that this is a huge undertaking and I really appreciate the effort,
> Hy
>
>
> On Wed, Oct 14, 2020 at 5:47 AM Robert Lancaster <rlancaste at gmail.com <mailto:rlancaste at gmail.com>> wrote:
> Hey guys,
>
> I also agree 100%, we are not ready by Oct. 15th. There are still several loose ends that need to be tied up on my end, as well as writing up documentation for how to use StellarSolver. Since it is a major release of KStars (3.5.0 vs 4.4.4), I think major changes in the UI and the functions are perfectly fine, but I agree we don’t want to change everything on the user without warning, so we need time to write up documentation and make sure everything is clear and simple for the user to use. So please let me know what is confusing so that we can try to improve that. As for your suggestion that we allow the old code to work during a transition period, the issue with that is that the old code is not compatible really. But that doesn’t mean that we couldn’t make the UI in the Align module *LOOK* like it used to with the combo boxes in align. I put the options for which source extraction method, which solving method, and which profile to use inside the Options dialog because I thought people would access them less often than the other settings in the align module and I also want those to be available if we plate solve in other places in KStars. But we could also put those same options at the bottom in the align module as well, which would make it look close to what it used to look like. There is no reason they couldn’t be in both places. It might lead to a better transition.
>
> On that note I also agree that we weren’t really ready to put all this in KStars master right away, especially because people rely on the master branch of the repo for nightly builds, and we needed to test it thoroughly before integrating it. I was hoping for more of a testing time period where people could test this on my fork or maybe in a different branch in the main repo and we could have a nice discussion about how to improve it before putting it in the official KStars Master repo. But, let's not be too hard on Jasem for that, he is a great guy and works incredibly hard to support KStars and INDI and us. It has caused a little more pressure on me to fix all these problems and get it all integrated, and maybe that was a good thing, because I had mostly finished StellarSolver back in June, and I was not integrating it into KStars very fast at all. This has pretty much lit a fire under me to get it done. We already did complain to him about putting it in the main repo so quickly, but it really has worked to get things up and running. So instead of focusing on that, now that its done, let's work really hard to polish everything up and get it ready for release. I think we could be on track for a Oct 22nd release. Please keep testing and I will keep trying to perfect things with StellarSolver and its integration with KStars for the release. And I am sorry if the integration has caused anybody any issues because it wasn’t ready yet.
>
> Thank you very much,
>
> Rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kstars-devel/attachments/20201020/3086ae26/attachment-0001.htm>
More information about the Kstars-devel
mailing list