<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi John,<div class=""><br class=""></div><div class="">So what I have been doing recently is very similar to what you said. I have been keeping the files in AstroRoot as a pristine copy of everything as it is out there in the world from official repositories. I use that for building my MacOs releases for KStars, StellarSolver, INDIWebManagerApp, and for storing the libraries, include files and all other things. Then I have been keeping my changes to various repos in a separate place on my computer in the ~/Projects folder where I have both my source folders from my forks and my build folders that I build based on it. Craft does a very good job of setting things up in the AstroRoot folder and a good job of updating it when you need to. (You can either use my script or use a craft command to update it) In your own forked source folders in the ~/Projects folder what I would do is commit any changes in a branch, not in master, and then push those changes to your forks on Github for INDI/StellarSolver and to Gitlab for KStars. When you make an MR and it gets accepted, your changes will be updated in the master branch of whatever repo you are contributing to, and at that time you can update your master branch in your fork of whatever repo got updated. And then you can tell craft to update to the new master from git. I would not recommend manually moving your changes to ~/AstroRoot or the master branch of any of your forks in your ~/Projects folder until those changes get accepted and you can just do a "git pull upstream master” or use a script to update to the master branch.</div><div class=""><br class=""></div><div class="">This is something I have learned more recently, I haven’t always done it this way, but I have found (through trial and error including a couple of times where I completely borked my forks) that following this plan has left me in the best overall shape. In my Applications folder, I have the latest stable release of KStars and INDI for my own imaging. In AstroRoot I have the latest master and all the stable libraries to build against. And in my Projects folder, I have the latest stuff I am personally working on. I would like to update my build scripts to help people setup an environment like this, but I have other things to work on first.</div><div class=""><br class=""></div><div class="">Does this help?</div><div class=""><br class=""></div><div class="">Rob</div><div class=""><br class=""></div><div class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On May 8, 2022, at 2:51 PM, John Evans <<a href="mailto:john.e.evans.email@gmail.com" class="">john.e.evans.email@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hi Rob,<div class=""><br class=""></div><div class="">I have another question for you, if I may. I have my environment on OSX Craft which has built everything in ~/AstroRoot which is now out of date as I took a clone of 3.5.8 a few weeks ago. A couple of days ago I made a fork and followed the instructions which created the project in ~/Projects/kstars. So I just copied the files I've been working on in AstroRoot into Projects/kstars, committed them (in a branch) and created a MergeRequest. Now I know a tiny bit more about Git, I can see having an area to work in and a completely different one for Git is probably not ideal.</div><div class=""><br class=""></div><div class="">So, I think what I need to do is:</div><div class="">1. Take a copy of my changed files somewhere safe.</div><div class="">2. Get a version of all of kstars at the time of my fork into AstroRoot. I'm assuming that this would be the best way to get a working environment again rather than getting Projects/kstars working on Craft? But I could well be wrong? Anyway, any suggestions here?</div><div class="">3. Merge my code changes for Linear1Pass Focuser back into AstroRoot. Now Git knows nothing about AstroRoot so is there any way to "move" Git locally from Projects/kstars to AstroRoot?</div><div class=""><br class=""></div><div class="">TIA</div><div class=""><br class=""></div><div class="">Regards,</div><div class="">John.</div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 7 May 2022 at 18:59, Robert Lancaster <<a href="mailto:rlancaste@gmail.com" class="">rlancaste@gmail.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space" class=""><div class="">Hi again John,</div><div class=""><br class=""></div>I have some nice tricks that might help you with #5. If you have been accidentally working in the master branch of the original repo, you can in the terminal go to the Kstars source folder and type<div class=""><br class=""></div><div class="">git diff > mychanges.patch</div><div class=""><br class=""></div><div class="">Then copy that file somewhere else on your computer. Now I assume you have made a fork in gitlab by now? If you have that downloaded, you can go into that source folder and type</div><div class=""><br class=""></div><div class="">git apply <span style="" class="">mychanges.patch (or whatever the path to this file happens to be)</span></div><div class=""><font class=""><span class=""><br class=""></span></font></div><div class=""><font class="">I would recommend moving your changes into a new branch so you can keep the master branch of your repo pristine and matching master (something I haven’t perfectly followed in the past, but I have been admonished multiple times for this and finally it caused me bad enough issues with my fork that I am finally listening to this advice!)</font></div><div class=""><font class=""><br class=""></font></div><div class=""><font class="">git checkout -b newFocuserBranch (or something like that)</font></div><div class=""><font class=""><br class=""></font></div><div class=""><font class="">Then you can commit your changes to the new branch. The neat thing is that once you push your changes in your new branch to your fork on Gitlab, when you go online to your forks page on Gitlab, it automatically asks you if you want to make an MR with it. It is really cool. The way I used to do it, in the master branch of my repo, it didn’t do this automatically, plus I had to then rebase my fork after it got merged. And then if my merge request was not accepted for some reason, it caused me big problems.</font></div><div class=""><font class=""><br class=""></font></div><div class=""><font class="">My hope is that I can update the KStars on OS X Craft repo to have some tools in the future to make this easier to work with. I have some of that in the KStars INDI Mac Dev Repo, but I would like to add this to the KStars on OS X Craft Repo, along with the default to be to assume that all changes will go into a branch, not master.</font></div><div class=""><font class=""><br class=""></font></div><div class=""><font class="">Does this help?</font></div><div class=""><font class=""><br class=""></font></div><div class=""><font class="">Rob<br class=""></font><div class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On May 7, 2022, at 1:37 PM, Hy Murveit <<a href="mailto:murveit@gmail.com" target="_blank" class="">murveit@gmail.com</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class="">Thanks John,<div class=""><br class=""></div><div class="">I just commented on the MR, and we should probably mainly communicate there from now on. Just to answer a few of your points above:</div><div class=""><br class=""></div><div class="">#1: Thanks! Tests are good!</div><div class=""><br class=""></div><div class="">#2: I appreciate that you don't want to break Linear, and I'm thankful for your caution. However, as I said in the MR comment, why not try and use the FocusAlgorithmInterface from focusalgorithms.h? You can still put your Linear1Pass implementation (inheriting from that interface) in a separate file.</div><div class=""><br class=""></div><div class=""><div class=""><div class="">#3: We usually put constants that are not user-changeable in the .cpp file near the top, or in the .h file. I totally agree that too many parameters for users to adjust can be counter-productive, but I also guarantee that as soon as you release this, some user will request the ability to change some of your parameters ;) I think in the end you release and see, and perhaps allow user modification later.</div><div class=""></div></div><div class=""><div class=""></div></div></div><div class=""><div class=""><br class=""></div><div class="">#4: Up to you if you want to include this in your algorithm. As you say, it might make sense to get the basic thing in good shape first.</div><div class=""><br class=""></div></div><div class=""><div class="">#5: you need to become familiar with git rebase. Please take a good look at <a href="https://invent.kde.org/education/kstars/-/blob/master/README.md" target="_blank" class="">https://invent.kde.org/education/kstars/-/blob/master/README.md</a> and find the section called 'rebasing your changes'. Honestly there are much better sources on the web for learning git, but this is a start. You should probably brush up on git from one of the web tutorials, but feel free to ask questions here. I'm far from an expert myself, but have learned enough to get by.</div><div class=""><br class=""></div><div class=""></div></div><div class="">#6: to fix compiling: grep through the CMakeLists.txt files in KStars, and anywhere you see, e.g. focusalgorithms.cpp, add your new cpp files in the same way. I think that would be just in KStars/CMakeLists.txt.</div><div class=""><br class=""></div><div class="">Hy</div><div class=""><br class=""></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, May 7, 2022 at 7:05 PM John Evans <<a href="mailto:john.e.evans.email@gmail.com" target="_blank" class="">john.e.evans.email@gmail.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr" class="">Thanks all,<div class=""><br class=""></div><div class="">I've created a MR, so you should be able to see the code. I had a bit of a struggle with Git (first time using it) but hopefully OK now. </div><div class=""><br class=""></div><div class="">Couple of points:</div><div class="">1. I'll update kstars/Tests/focus/testfocus.cpp as Hy suggests to include some L1P tests.</div><div class="">2. kstars/ekos/focus/focusalgorithms.cpp/h has not been changed. I cloned this to focusalgorithmslinear1pass.cpp/h in order to minimise the chances of breaking the linear algorithm.</div><div class="">3. Currently there are 3 parameters for the solver algorithm that control the number of iterations and the precision required for a "solve". I've picked values that work on my equipment and the simulator but may not be appropriate for all equipment. These parameters are hard-coded into curvefit.h but would probably be better in a config file so could be changed without a rebuild. I don't think exposing these to end users would be a great idea. What would be the best way to do this? (put them in kstarsrc?)</div><div class="">4. Hy, I have currently bypassed the HFR adjustment algorithm for most of L1P. This may not be best but for now it avoids a lot of work that's hard to verify to get a star subset to do further processing on. It will be unchanged for the other focus algos (Linear, etc) though. Whether its worth doing more work on this is probably dependent on how much benefit people are getting out of it, so I'd appreciate any thoughts on this?</div><div class="">5. I started working on the code before forking Git (school boy error I know) so I'll need to make sure I don't blat anybody else's changes. Can Git help me here? (I've manually diff'd the 6 changed files and think 5 are OK - all the changes look to be mine) but manager.cpp has been changed. What's the best way to sync this up?</div><div class="">6. The build process will need to change to include the new files: curvefit.cpp/h focusalgorithmslinear1pass.cpp/h. So locally I've changed CMakeLists.txt but I haven't included anything with the MR as I don't know what to do?</div><div class=""><br class=""></div><div class="">Regards,</div><div class="">John.</div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 7 May 2022 at 09:38, Hy Murveit <<a href="mailto:murveit@gmail.com" target="_blank" class="">murveit@gmail.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr" class="">John,<div class=""><br class=""></div><div class="">Thanks very much for doing this. Here are a few quick notes:</div><div class=""><ul class=""><li class="">Please check out kstars/Tests/focus/testfocus.cpp. You'll find some unit tests for the Linear algorithm there, and you can model unit tests for your new scheme after that. You can also use that test to help check that you haven't changed the standard Linear.</li><li class="">Please include the new scheme in kstars/ekos/focus/focusalgorithms.cpp/h which is where most of Linear is implemented. (Haven't had a chance to look, I assume you're already doing that, but just in case.)</li><li class="">I'd be happy to help code review, as will some of the others, I'm sure. </li><li class="">Feel free to continue asking questions on this email list, and later on the merge review (MR) page once you've started that. Any question is welcome. There are some instructions on the kstars README page about git and MRs if you want to refer to that.</li></ul></div><div class="">Looking forward to it,</div><div class="">Hy</div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, May 7, 2022 at 10:24 AM Jasem Mutlaq <<a href="mailto:mutlaqja@ikarustech.com" target="_blank" class="">mutlaqja@ikarustech.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr" class=""><div class="">Hello John,</div><div class=""><br class=""></div><div class="">I've been following your progress on INDI forum and this is indeed looking very good. I believe after this is merged in KStars, we need to create a table for the different algorithms used to explain use cases, pros/cons for each, which type of equipment they are mostly suited for..etc.. This should help clear up any confusion for end users.</div><div class=""><br class=""></div><div class="">We can only comment on the code after you submit an MR to KStars, and then we'll start the review process. This is very exciting and I'm looking forward to it.</div><div class=""><br class=""></div><div class=""><div dir="ltr" class=""><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><div class="">--</div><div class="">Best Regards,<br class="">Jasem Mutlaq<br class=""></div><div class=""><br class=""></div></div></div></div></div></div><br class=""></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, May 7, 2022 at 11:06 AM John Evans <<a href="mailto:john.e.evans.email@gmail.com" target="_blank" class="">john.e.evans.email@gmail.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr" class="">Hello Everyone,<div class=""><br class=""></div><div class="">Hope you're all well? I have been working on a change to improve focus on my rig. Iterative and Polynomial don't work so well for me on the ASI EAF, due, I think to backlash. The Linear algorithm works best but the second pass usually overshoots the ideal focus position.</div><div class=""><br class=""></div><div class="">So I built a "Linear 1 Pass" algo, that is based on Linear for the 1st pass, but instead of doing a second pass it moves straight to the minimum of the first pass.</div><div class=""><br class=""></div><div class="">I've implemented a couple of curve types (Hyperbola and Parabola) using a generic GSL curve fitting algorithm which could be extended in the future if necessary. The fitting can be done either giving each point equal weighting or weighting them based on the HFR standard deviation of the stars.</div><div class=""><br class=""></div><div class="">See the enclosed document for more details.</div><div class=""><br class=""></div><div class="">I have written most of the code and it basically works on my rig and the simulator. I have a couple of things still to work out though, and more testing to do.</div><div class=""><br class=""></div><div class="">Since this is the first Kstars change I have done (using QT on Mac) I have been following Ron Lancaster's work on getting Kstars running on Mac. In terms of coding standards I've just followed what's been done in the areas I've changed. If there are any resources that someone could point me to, that would be great.</div><div class=""><br class=""></div><div class="">If anyone has any feedback on the change that would also be great (I'll also post on the forum to see if there are any suggestions).</div><div class=""><br class=""></div><div class="">I estimate I'll be finished with coding and testing in a couple of weeks. I would like feedback on deployment as I'm not familiar with the process at all. So if anyone can point me to any resources that would be very helpful.</div><div class=""><br class=""></div><div class="">At the moment I'm thinking:</div><div class="">1. Release 1 - deploy Linear 1 Pass code but concentrate on minimising risk to breaking existing code, esp the Linear algorithm. I have cloned some Linear code for this.</div><div class="">2. Release 2. When Release 1 is working as expected, interface Linear 1 Pass code with Linear in a more integrated way, removing cloned code. If any features of Linear 1 Pass would be useful for other focus algos, this could be done here.</div><div class=""><br class=""></div><div class="">The reason I'm thinking of doing this in 2 steps is that I'm a novice with C++ and this seems the best way to minimize the risks of breaking existing code. However, I'm happy to take advice from more experienced people here.</div><div class=""><br class=""></div><div class="">If anyone would like to offer to help me, do a code review, etc., that would be really appreciated. As I mentioned I'm a novice with C++ so probably not doing things in the best way, but happy to be guided. Also, any suggestions on:</div><div class="">1. Test cases to write for this change.</div><div class="">2. Best way to profile the code, test for memory leaks, etc.</div><div class="">3. Since this would run on a range of different machines, how to configure for different setups, things to watch out for, etc.</div><div class=""><br class=""></div><div class="">Thanks for reading!</div><div class=""><br class=""></div><div class="">Regards,</div><div class="">John.</div></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</div></blockquote></div><br class=""></div></div></div></blockquote></div>
</div></blockquote></div><br class=""></div></body></html>