-
Notifications
You must be signed in to change notification settings - Fork 1
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
Refactoring Code Structure #91
Comments
BTW perhaps an |
Bonus question: The |
Hola @gfrances,
Un abrazo! |
Thanks Miquel, good info. Related question: I'm seeing here that the SBFWS driver now has some
This however does not solve the situation here, since in the code as it is now will always end up including soplex, irrespective of whether the runtime configuration dictates its use or not... |
Hello @gfrances , certainly, the code needs to be decluttered a bit. There is no reason for
wrapping the call and the dependency with those norms. Factorising the computation of the R-sets if something we would want to do anyways (so we can use intervals/sets from the CRPG heuristic, landmarks, etc.) Cheers, Miquel. |
Another quick one, @miquelramirez : what was the purpose of duplicating |
Hello @gfrances , I didn't want to break inadvertently the implementation of |
haha ok, but you mean that it could well be that there is no major incompatibility? |
The sheer number of template parameters we have on every class is starting to give me serious headaches... |
The Let's say that the profusion of template parameters was for sure one of the reasons why I duplicated stuff. Compile time polymorphism, like |
So if I slowly started making some template parameters disappear by using a bit more of runtime polymorphism, trading off some (hopefully small) runtime performance by some peace of mind, would I have your blessing? |
Actually, an old colleague of mine and very experienced |
Yes, please |
It'd be good if I have your opinion on the main difficulties to merge back both variants - but after no more than a quick 5-minute look, no worries for that |
Will try to do so over the next few days @gfrances :) |
Hi there @gfrances , some notes on this:
SummaryThe filtering of R sets and its associated methods need to be moved out of the class. I would like to have them somewhere, as a snippet of some sort and a note, since the idea of post-processing R-sets may have some potential. The rest of the changes are related to switching the underlying datum used to compute w(s) from |
I hope this helps! |
@miquelramirez ! I have finished a slight refactoring of the code to start really decoupling the modules, so that e.g. I can compile and run the planner without soplex, etc. (of course NOT run the LP-based parts of the planner). This is done in commit ed16894.
G. |
Great to see this going forward @gfrances :) Some thoughts inline:
#include <fs/core/problem.hxx> that would be a robust approach when deploying fs as a library.
on each translation unit and header that depends on XXXX. The #error macro would be generating these errors at compile time. Checking for dependencies at run time and this on a per-method/per-attribute basis sounds useful, if the class / interface remains meaningful or useful without those components. I am not sure how often this happens to us, other than in very high level interfaces such as the factories for constructing heuristics, etc.
|
Sure, if you do that PR I will try to merge that right away. The "proper includes" suggestion sounds heavenly. Agree with the relative includes, I've just started using CLion, which by the way I'm finding far better than Kdevelop, but I need to see how to make it generate absolute includes. |
Doing the PR in a few minutes! |
PR #92 is up |
Ok, I merged your PR into beta5. I understand that you're still actively making changes in your branch of the code? Are you planning to make changes to the "core" part as well? I'm eager to push this forward, as I have other things that need to build upon some working version of the code, which I don't really have at the moment, or not too reliably. Let me know what your plans regarding code changes are, and let's see how we can better do this :-) Thanks! |
Hello there @gfrances , What I can assure you that within the next 24 hours I am not planning on doing any further changes on the framework - I will be working on the satellite repos, trying to gather more experimental observations. So no major changes other than bugfixes. My suggestion is that you go and finish the refactoring as quickly as possible, so I can then bring Also, as long as no filenames are changed, I should be able to bring over any emergency changes. Keeping a changelog of sorts detailing what was moved where and how includes need to change would also be very helpful. If something gets broken in a subtle way - i.e. BFWS/IW etc. - then I will fall back to Cheers, Miquel. |
Sounds good - but don't try to merge anything into your fork until after the deadline! |
BTW, which name do you suggest for the "hybrid" module? "Hybrid" works well? Something different? |
Okay, @gfrances if you say don't merge I won't merge, no worries.
As I said before with proper documentation explaining the changes in some detail, things will be way easier. At least one can go and sort out the big stuff and then worry about the bits that always fall through the cracks. |
Note: I'm starting to document the changes in file beta7-dev-notes.md |
In particular, let me highlight this change: The rapidjson library is no longer under the I take this as a test... with things such as rapidjson I guess using submodules is perfect. |
That basically automates the process of synching with
I don't think so. If we want to do spin offs from |
You mean you don't think that submodules are the way to go, right? My point however is whether the same idea is also good for more complex settings such as hybrid planning itself. Could we for instance separate the hybrid planning part of the code into a different repo that imports and makes use of the FS library in the same manner? That'd be a good thing to have. But then we could further modularize the planner, as we're starting to do, and have all things that depende on a CSP solver as a separate module. And so on. But the development of all of this modules is (at least at the moment) quite interlocked - i.e. changes are likely to occur simultaneously accross the different modules. Hence I was thinking that keeping everything separate might be a nightmare, as it'll be crucial to keep track of which commits in each modules are compatible with which commits in the other modules, etc. That's where git submodules could prove useful, although I'm a bit skeptical about their ease of use...? P.D: By the way, very cool hybrid planner, eventually we'll get to the point where |
I am closing this big and messy issue here, as we're mostly done with it. I opened #96 for the only part which remains to be done. |
@miquelramirez , I'm trying to figure out which of the novelty features here could/should be moved to a new location
modules/hybrid
that I'm creaing (don't look for that, only in local ATM). The very name modules/hybrid is tentative, but essentially I wanted to put there all code related with soplex. Feel free to suggest a better name, or to suggest splitting that into two or more conceptually differentiated modules, and I'll do that. In any case, for instance theelliptical_2d.*
code will end up there, because it uses soplex, etc. etc.I will probably have some "feature wrapper" code in modules/hybrid that conditionally includes soplex, and throws a runtime error if both
use_soplex
flag was not used during compilation, andfeatures.elliptical_2d
, etc.Thoughts?
The text was updated successfully, but these errors were encountered: