-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a persistent layer of setting options and introduce a Tutorial mode #354
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #354 +/- ##
==========================================
+ Coverage 99.45% 99.53% +0.08%
==========================================
Files 69 69
Lines 6418 6454 +36
==========================================
+ Hits 6383 6424 +41
+ Misses 35 30 -5 ☔ View full report in Codecov by Sentry. |
So the tutorial already has a section about this, I just have to figure out how to convince Quarto to display warnings :) https://manoptjl.org/previews/PR354/tutorials/Optimize/#Using-the-“Tutorial”-mode |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The suggested usage of Preferences.jl is that you restart your Julia session to take any preference changes into account. This ensures that all preference checks can be done very fast. Are you sure you want dynamic checks here?
Co-authored-by: Mateusz Baran <[email protected]>
Co-authored-by: Mateusz Baran <[email protected]>
My honest answer is: I would prefer to be able to set this dynamically – otherwise I for example have no clue how to test that? How do I restart Julia in testing to test the other mode? Besides the testing, I would also have not much clue how to implement what you refer to? So one would set the preference but that is never accessed but something different, because only on start (load of Manopt) the local preferences of preferences.jl are read? To me (but maybe I am just not that clever here) that reads like probably 100 more lines of code to split that into two layers, one that we load and one that we have during runtime? edit: I also do not fully agree with your statement, the first word here is the important one I think:
so with the macros it can be used at compile time, it does not say it has to, and the way I have this feature in mind here, I would not know how this should be done at compile time for the tutorial mode. |
I thought about it again and you are most likely right to keep preferences dynamic. Let's not over-complicate it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a few last minor things.
GitHub has some Hickups today, first not being able to pull from gh-pages, now this is merged but this PR not closed?! Strange. |
I don't see this as merged, only closed. |
Wait, master branch history shows it's merged but his PR does not. Weird. |
I see a commit that refers to this on master, but also this not marked as merged. But if I open it, the changelog check fails, since the changelog is identical with master – so it is on master. I am confused. |
…de (#354) * Add Preferences for persistent global settings. * Document the `:Mode` setting and implement a reset possibility * Add the new global code to Quasi Newton Debug and the start tutorial. * Update Changelog. --------- Co-authored-by: Mateusz Baran <[email protected]>
This adresses a point raised in #346 and is for now realised in the
quasi_Newton
solver.