Issue588

Title option parser refactoring
Priority meta Status in-progress
Superseder Nosy List cedric, florian, guillem, haz, jendrik, malte, manuel, patfer, silvan
Assigned To Keywords
Optional summary
High-level goals:
- Decouple the external interface from the implementation better.
  Perhaps reduce the external interface to a single #include.
- ~~Make the option parser code planner-independent.~~

Some details:
- Split the code into smaller parts with clearly defined responsibilities.
- Reduce internal dependencies in option parser code.

General observations about the code that are not yet converted to issues;
some of these may already have been addressed by the changes in the week of
September 17-21, 2018:

- Currently, some of the users of the option parser use the files in the
  main source directory, and some of them directly use the files in the
  "options" directory. The header files in the main source directory are
  marked as temporary stubs, but we think that perhaps they could be more
  generally useful to separate the public interface of the option parser
  from its internals. Whether or not we keep the stubs, all user code should
  access the option parser in the same way.

- The separation between a parser and a parse was very non-existent/unclean.
  This is now quite a bit better by reducing global object use, but there
  is probably still a lot more that can be done.

- The parse_tree.h file and more generally the use of the external tree
  library should be rethought. We are perhaps better off not using an external
  tree implementation.

- The actual parsing of text is currently fragile and should perhaps be
  reimplemented. Perhaps it can also be separated out more from the other
  code.

- The files option_parser.{h,cc} are very large and have multiple
  responsibilities. (This has become better, but may still be the case.)

- As a general principle, we want to have less code in *.h files and more
  code in *.cc files in the option parser because all code in *.h files is
  some form of internal code dependency. Perhaps it is worth using the
  pimpl idiom in a few places to reduce the amount of code that needs to
  live in header files.

- The option parser design should be documented better.

- The parsing code requires better error checking. It should not accept
  invalid specifications (e.g. using non-existent arguments), and when
  faced with an invalid specification, it should give a clean error message.

Specific issues:
- issue481: avoid special case for open lists.
- issue524: Use shared_ptr for landmark factories
- issue526: Use shared_ptr for Heuristic/Evaluator
- issue606: move the code to a directory
- issue608: split code into more files
- issue619: Get rid of need to list plugin types manually for get_help_templ
- issue626: introduce a namespace.
- issue717: Remove special cases for landmark synergy
- issue718: Avoid special case for Heuristics and ScalarEvaluators
- issue764: remove global variables for plan storage
- issue826: split option_parser.{h, cc} into smaller responsibilities
- issue827: Move code from .h to .cc files
- issue830: Use single registry
- issue831: unique names for plug-ins and predefinitions
- issue832: Rework relation Registry-DocPrinter
- issue834: Remove traces of old Plugin class
- issue836: Don't use global object for predefinitions
- issue840: Don't use global object for registry
- issue842: Two-phase initialization of registry (first collect plugin info,
  then construct them later) with better name collision reporting
- issue844: avoid special case for plugin types that support predefinition
- issue873: Make the option parser code planner-independent

Created on 2015-10-31.18:43:36 by malte, last changed by malte.

Summary
High-level goals:
- Decouple the external interface from the implementation better.
  Perhaps reduce the external interface to a single #include.
- Make the option parser code planner-independent.

Some details:
- Split the code into smaller parts with clearly defined responsibilities.
- Reduce internal dependencies in option parser code.

General observations about the code that are not yet converted to issues;
some of these may already have been addressed by the changes in the week of
September 17-21, 2018:

- Currently, some of the users of the option parser use the files in the
  main source directory, and some of them directly use the files in the
  "options" directory. The header files in the main source directory are
  marked as temporary stubs, but we think that perhaps they could be more
  generally useful to separate the public interface of the option parser
  from its internals. Whether or not we keep the stubs, all user code should
  access the option parser in the same way.

- The separation between a parser and a parse was very non-existent/unclean.
  This is now quite a bit better by reducing global object use, but there
  is probably still a lot more that can be done.

- The parse_tree.h file and more generally the use of the external tree
  library should be rethought. We are perhaps better off not using an external
  tree implementation.

- The actual parsing of text is currently fragile and should perhaps be
  reimplemented. Perhaps it can also be separated out more from the other
  code.

- The files option_parser.{h,cc} are very large and have multiple
  responsibilities. (This has become better, but may still be the case.)

- As a general principle, we want to have less code in *.h files and more
  code in *.cc files in the option parser because all code in *.h files is
  some form of internal code dependency. Perhaps it is worth using the
  pimpl idiom in a few places to reduce the amount of code that needs to
  live in header files.

- The option parser design should be documented better.

- The parsing code requires better error checking. It should not accept
  invalid specifications (e.g. using non-existent arguments), and when
  faced with an invalid specification, it should give a clean error message.

Specific issues:
- issue481: avoid special case for open lists.
- issue524: Use shared_ptr for landmark factories
- issue526: Use shared_ptr for Heuristic/Evaluator
- issue606: move the code to a directory
- issue608: split code into more files
- issue619: Get rid of need to list plugin types manually for get_help_templ
- issue626: introduce a namespace.
- issue717: Remove special cases for landmark synergy
- issue718: Avoid special case for Heuristics and ScalarEvaluators
- issue764: remove global variables for plan storage
- issue826: split option_parser.{h, cc} into smaller responsibilities
- issue827: Move code from .h to .cc files
- issue830: Use single registry
- issue831: unique names for plug-ins and predefinitions
- issue832: Rework relation Registry-DocPrinter
- issue834: Remove traces of old Plugin class
- issue836: Don't use global object for predefinitions
- issue840: Don't use global object for registry
- issue842: Two-phase initialization of registry (first collect plugin info,
  then construct them later) with better name collision reporting
- issue844: avoid special case for plugin types that support predefinition
- issue873: Make the option parser code planner-independent
Files
File name Uploaded Type Edit Remove
option-dependencies.png florian, 2015-12-10.11:27:15 image/png
Messages
msg8422 (view) Author: malte Date: 2018-12-26.17:16:23
> Metaclasses are under discussion for C++20

Updated word is they definitely won't be added before C++23 because there is
still too much work to do.
msg8421 (view) Author: malte Date: 2018-12-26.17:11:08
>> Is there interest in working on this further?
>
> I think it would improve the usability of the planner a lot if we made the
> parser more rigorous. In any case, we should decide on which headers to use
> for the option parser to get out of this state of limbo :-)

Sounds good!

>> Should we do this within this issue, or call this one done and open a
>> new one with a clean slate?
>
> I don't have a preference either way.

Nobody else expressed a preference either, so as a tie breaker let's apply the
principle of doing what causes the least amount of immediate work and keep this
issue as the one where we keep track of further option parser refactoring
activities.

So the next step is to identify the next steps. Jendrik mentions two things
above: making the parser more rigorous, and unifying the #includes. I've added
the first item to the summary; the second was already included.
msg8420 (view) Author: malte Date: 2018-12-26.17:06:37
Answering to the first part of msg8365 (will answer to the rest separately):

> One more thing that is currently a bit complicated for users of the option
> parser is the inheritance of options. Ideally, I think a subclass should
> automatically inherit all options from the parent, but I don't know how hard
> it would be to achieve this or if it's worth looking into this.

This is not generally possible to do in C++ in a DRY way. It would require a
language feature like classmethods, introspection into the set of base classes,
or metaclasses. Metaclasses are under discussion for C++20, but it's one of
these big language changes (like concepts) where it's not yet clear if, when and
in which form it will be accepted. For those who are interested, check out Herb
Sutter's recent talks on metaclasses and reflection, for example this one:

    https://www.youtube.com/watch?v=80BZxujhY38

(Note that he talks about an unrelated topic first.)

If we don't worry too much about DRY and are willing to accept that the factory
function has to repeat the base class in some way, then we could make it
possible, but not with the current plugin design because there is nothing
visible outside the factory function that knows which kind of object is actually
created. That is, the factory functions for SumEvaluator, FFHeuristic and
LandmarkCountHeuristic all have the same interface from the perspective of the
option parser: they return a shared_ptr<Evaluator>, and there is no way to
figure out what kind of evaluator it is.

The easiest and cleanest way I can think of to make "inheritance within plugins"
a thing is to move away from our current plug-in design, which is essentially
just wrapped factory functions, to more explicit factory classes. This has the
added advantage that things that are currently mixed up in our factory functions
could be separated. For example, we could get rid of all the "if dry_mode" tests.

We would still need to repeat ourselves: for FFHeuristic to inherit the options
of Heuristics, we would need to have a class FFHeuristicPlugin deriving from a
class HeuristicPlugin, and FFHeuristicPlugin::add_options (or whatever) would
still have to call HeuristicPlugin::add_options manually, or we need some kind
of magical base-class and then derive FFHeuristicPlugin from
MagicBaseClass<FFHeuristic, Heuristic>. Overall, we would probably end up with
more code per plug-in rather than less, but the code could perhaps be cleaner
than it currently is.

There are other ways to design this. Using RTTI, another way to reduce
boilerplate is to explicitly tell the option parser that FFHeuristic derives
from Heuristic and then register each plugin together with the ID of its
associated type. But many of the designs that require less user code end up with
a lot of magic that has its own disadvantages.

In summary, I think this is a major change that would be interesting to work on,
but I wouldn't see it as part of "refactoring" but rather as a larger new
feature request. If we want to work on it, I'd do it outside this issue.
msg8365 (view) Author: jendrik Date: 2018-12-15.18:38:37
One more thing that is currently a bit complicated for users of the option
parser is the inheritance of options. Ideally, I think a subclass should
automatically inherit all options from the parent, but I don't know how hard it
would be to achieve this or if it's worth looking into this.

> Is there interest in working on this further?

I think it would improve the usability of the planner a lot if we made the
parser more rigorous. In any case, we should decide on which headers to use for
the option parser to get out of this state of limbo :-) 

> Should we do this within this issue, or call this one done and open a new one
> with a clean slate?

I don't have a preference either way.
msg8361 (view) Author: malte Date: 2018-12-15.17:04:59
I have cleaned up the summary a bit.

All specific issues we have opened are addressed now, which raises the question
how to proceed. It would be nice to improve the code further now that we have
some momentum. I think now would be a good time to take a step back, look at the
option parser code as a whole again and identify what should be the next steps
in improving the option parser codebase.

There are certainly things that are still very ugly. On the user side, the most
visible things are the lack of proper error checking in the parsing code, the
ugliness required in the iterated search code, and the fact that we currently
use two different sets of header files to access the option parser. On the code
side, I would need to take stock first to identify what the worst bits are at
the moment, but certainly the actual parsing code must be up there on the list
of things in need of improvement.

Is there interest in working on this further?

Should we do this within this issue, or call this one done and open a new one
with a clean slate?
msg8357 (view) Author: jendrik Date: 2018-12-14.18:03:26
Add issue873 to summary.
msg7746 (view) Author: patfer Date: 2018-09-21.14:25:47
added missing issue840
msg7734 (view) Author: malte Date: 2018-09-21.13:18:32
I added some thoughts from the current sprint to the summary in section "General
observations about [...]".
msg7729 (view) Author: malte Date: 2018-09-21.12:50:35
Summary: added reference to issue844 and minor cleanup.
msg7720 (view) Author: malte Date: 2018-09-21.12:22:06
Moved items in summary with specific issue numbers from "Some details" to
"Specific issues".
msg7719 (view) Author: malte Date: 2018-09-21.12:19:19
Clean-up of summary: be consistent about use of strikethrough. (Don't use manual
strike-through in the list of specific issues; instead rely on roundup's
automatic striking through of resolved issues.)
msg7718 (view) Author: malte Date: 2018-09-21.12:17:15
Added issue842 to summary and removed more deteailed comments from the summary
that were specific to issue842. They have been added to that issue as msg7717.
msg7609 (view) Author: jendrik Date: 2018-09-19.20:22:50
Fix summary.
msg7608 (view) Author: jendrik Date: 2018-09-19.20:21:05
Add issue834 to summary.
msg6857 (view) Author: florian Date: 2018-03-15.12:22:18
For issue764 we should talk about the way that options like
"--internal-plan-file" are parsed.
msg6602 (view) Author: jendrik Date: 2017-11-27.12:23:32
Update summary.
msg6385 (view) Author: jendrik Date: 2017-05-22.11:47:43
Copy plans for detecting plugin name collisions from issue729.
msg6270 (view) Author: malte Date: 2017-04-28.14:00:32
We should only strike these things through once the code is merged. In the
current master repository, the special case for Heuristic and Evaluator is still
present. Hence, I'm putting it back in, but adding a reference to issue718 there.
msg6268 (view) Author: manuel Date: 2017-04-28.13:53:33
Updated summary by striking item "Avoid special case for Heuristics and
ScalarEvaluators". This item was resolved with issue718.
msg5995 (view) Author: malte Date: 2016-12-31.15:52:16
Testing the tracker after server maintenance.
msg5110 (view) Author: florian Date: 2016-01-19.10:54:12
updated summary to show that issue626 is merged.
msg5092 (view) Author: florian Date: 2016-01-15.22:01:31
Split off issue626 to introduce a namespace.
msg4933 (view) Author: florian Date: 2015-12-10.11:27:15
Attached a graph showing the current header dependencies.
msg4913 (view) Author: malte Date: 2015-12-09.02:38:21
Made the summary a bit more structured.
msg4912 (view) Author: malte Date: 2015-12-09.02:35:03
Updated summary to take into account issue608 is done.
msg4910 (view) Author: malte Date: 2015-12-09.00:48:20
Added issue608 for splitting the option parser code into more files.
msg4907 (view) Author: malte Date: 2015-12-09.00:27:23
Updated summary.
msg4902 (view) Author: florian Date: 2015-12-08.16:44:38
issue606 will move the code to a subdirectory.
msg4723 (view) Author: malte Date: 2015-10-31.18:43:36
This is a followup to issue586.

The plugin support in the option parser still has a few gaps:

- All plugin types still need to be manually listed in two places in
option_parser.cc
  (calls to get_help_templ).
- Heuristics and ScalarEvaluators need special-casing in a few places because
  of their inheritance relationship. The suggestion made in issue586 for this
  was to get rid of the plugin inheritance feature and unify Heuristics and
  ScalarEvaluators from the UI perspective.
- Open lists need special-casing because they are templated. This is issue481.
- Plugin types that support predefinition still need special-cased code, e.g. to
  define the command-line option name. Currently, the only such options are
  --heuristic for Heuristic and --landmarks for LandmarkGraph.

Additionally, there are other things in the option parser that could be refactored:
- The code should be moved to a directory and use a namespace.
- If possible, the compile-time dependencies should be reduced: currently all users
  of plugins and/or options drag in a lot of code, mainly because of the extensive
  use of templates. Perhaps we can decouple the external interface from the
  implementation better.

Ideally, we would like the option parser code to be encapsulated to the extent
that it could be reused in a different project without changes.
History
Date User Action Args
2018-12-26 17:16:23maltesetmessages: + msg8422
2018-12-26 17:11:08maltesetmessages: + msg8421
summary: High-level goals: - Decouple the external interface from the implementation better. Perhaps reduce the external interface to a single #include. - ~~Make the option parser code planner-independent.~~ Some details: - Split the code into smaller parts with clearly defined responsibilities. - Reduce internal dependencies in option parser code. General observations about the code that are not yet converted to issues; some of these may already have been addressed by the changes in the week of September 17-21, 2018: - Currently, some of the users of the option parser use the files in the main source directory, and some of them directly use the files in the "options" directory. The header files in the main source directory are marked as temporary stubs, but we think that perhaps they could be more generally useful to separate the public interface of the option parser from its internals. Whether or not we keep the stubs, all user code should access the option parser in the same way. - The separation between a parser and a parse was very non-existent/unclean. This is now quite a bit better by reducing global object use, but there is probably still a lot more that can be done. - The parse_tree.h file and more generally the use of the external tree library should be rethought. We are perhaps better off not using an external tree implementation. - The actual parsing of text is currently fragile and should perhaps be reimplemented. Perhaps it can also be separated out more from the other code. - The files option_parser.{h,cc} are very large and have multiple responsibilities. (This has become better, but may still be the case.) - As a general principle, we want to have less code in *.h files and more code in *.cc files in the option parser because all code in *.h files is some form of internal code dependency. Perhaps it is worth using the pimpl idiom in a few places to reduce the amount of code that needs to live in header files. - The option parser design should be documented better. Specific issues: - issue481: avoid special case for open lists. - issue524: Use shared_ptr for landmark factories - issue526: Use shared_ptr for Heuristic/Evaluator - issue606: move the code to a directory - issue608: split code into more files - issue619: Get rid of need to list plugin types manually for get_help_templ - issue626: introduce a namespace. - issue717: Remove special cases for landmark synergy - issue718: Avoid special case for Heuristics and ScalarEvaluators - issue764: remove global variables for plan storage - issue826: split option_parser.{h, cc} into smaller responsibilities - issue827: Move code from .h to .cc files - issue830: Use single registry - issue831: unique names for plug-ins and predefinitions - issue832: Rework relation Registry-DocPrinter - issue834: Remove traces of old Plugin class - issue836: Don't use global object for predefinitions - issue840: Don't use global object for registry - issue842: Two-phase initialization of registry (first collect plugin info, then construct them later) with better name collision reporting - issue844: avoid special case for plugin types that support predefinition - issue873: Make the option parser code planner-independent -> High-level goals: - Decouple the external interface from the implementation better. Perhaps reduce the external interface to a single #include. - ~~Make the option parser code planner-independent.~~ Some details: - Split the code into smaller parts with clearly defined responsibilities. - Reduce internal dependencies in option parser code. General observations about the code that are not yet converted to issues; some of these may already have been addressed by the changes in the week of September 17-21, 2018: - Currently, some of the users of the option parser use the files in the main source directory, and some of them directly use the files in the "options" directory. The header files in the main source directory are marked as temporary stubs, but we think that perhaps they could be more generally useful to separate the public interface of the option parser from its internals. Whether or not we keep the stubs, all user code should access the option parser in the same way. - The separation between a parser and a parse was very non-existent/unclean. This is now quite a bit better by reducing global object use, but there is probably still a lot more that can be done. - The parse_tree.h file and more generally the use of the external tree library should be rethought. We are perhaps better off not using an external tree implementation. - The actual parsing of text is currently fragile and should perhaps be reimplemented. Perhaps it can also be separated out more from the other code. - The files option_parser.{h,cc} are very large and have multiple responsibilities. (This has become better, but may still be the case.) - As a general principle, we want to have less code in *.h files and more code in *.cc files in the option parser because all code in *.h files is some form of internal code dependency. Perhaps it is worth using the pimpl idiom in a few places to reduce the amount of code that needs to live in header files. - The option parser design should be documented better. - The parsing code requires better error checking. It should not accept invalid specifications (e.g. using non-existent arguments), and when faced with an invalid specification, it should give a clean error message. Specific issues: - issue481: avoid special case for open lists. - issue524: Use shared_ptr for landmark factories - issue526: Use shared_ptr for Heuristic/Evaluator - issue606: move the code to a directory - issue608: split code into more files - issue619: Get rid of need to list plugin types manually for get_help_templ - issue626: introduce a namespace. - issue717: Remove special cases for landmark synergy - issue718: Avoid special case for Heuristics and ScalarEvaluators - issue764: remove global variables for plan storage - issue826: split option_parser.{h, cc} into smaller responsibilities - issue827: Move code from .h to .cc files - issue830: Use single registry - issue831: unique names for plug-ins and predefinitions - issue832: Rework relation Registry-DocPrinter - issue834: Remove traces of old Plugin class - issue836: Don't use global object for predefinitions - issue840: Don't use global object for registry - issue842: Two-phase initialization of registry (first collect plugin info, then construct them later) with better name collision reporting - issue844: avoid special case for plugin types that support predefinition - issue873: Make the option parser code planner-independent
2018-12-26 17:06:37maltesetmessages: + msg8420
2018-12-15 18:38:37jendriksetmessages: + msg8365
2018-12-15 17:04:59maltesetmessages: + msg8361
summary: High-level goals: - Decouple the external interface from the implementation better. Perhaps reduce the external interface to a single #include. - Make the option parser code planner-independent (issue873). Some details: - Split the code into smaller parts with clearly defined responsibilities. - Reduce internal dependencies in option parser code. General observations about the code that are not yet converted to issues; some of these may already have been addressed by the changes in the week of September 17-21, 2018: - Currently, some of the users of the option parser use the files in the main source directory, and some of them directly use the files in the "options" directory. The header files in the main source directory are marked as temporary stubs, but we think that perhaps they could be more generally useful to separate the public interface of the option parser from its internals. Whether or not we keep the stubs, all user code should access the option parser in the same way. - The separation between a parser and a parse was very non-existent/unclean. This is now quite a bit better by reducing global object use, but there is probably still a lot more that can be done. - The parse_tree.h file and more generally the use of the external tree library should be rethought. We are perhaps better off not using an external tree implementation. - The actual parsing of text is currently fragile and should perhaps be reimplemented. Perhaps it can also be separated out more from the other code. - The files option_parser.{h,cc} are very large and perhaps have multiple dependencies. - As a general principle, we want to have less code in *.h files and more code in *.cc files in the option parser because all code in *.h files is some form of internal code dependency. Perhaps it is worth using the pimpl idiom in a few places to reduce the amount of code that needs to live in header files. - The option parser design should be documented better. Specific issues: - issue481: avoid special case for open lists. - issue524: Use shared_ptr for landmark factories - issue526: Use shared_ptr for Heuristic/Evaluator - issue606: move the code to a directory - issue608: split code into more files - issue619: Get rid of need to list plugin types manually for get_help_templ - issue626: introduce a namespace. - issue717: Remove special cases for landmark synergy - issue718: Avoid special case for Heuristics and ScalarEvaluators - issue764: remove global variables for plan storage - issue826: split option_parser.{h, cc} into smaller responsibilities - issue827: Move code from .h to .cc files - issue830: Use single registry - issue831: unique names for plug-ins and predefinitions - issue832: Rework relation Registry-DocPrinter - issue834: Remove traces of old Plugin class - issue836: Don't use global object for predefinitions - issue840: Don't use global object for registry - issue842: Two-phase initialization of registry (first collect plugin info, then construct them later) with better name collision reporting - issue844: avoid special case for plugin types that support predefinition -> High-level goals: - Decouple the external interface from the implementation better. Perhaps reduce the external interface to a single #include. - ~~Make the option parser code planner-independent.~~ Some details: - Split the code into smaller parts with clearly defined responsibilities. - Reduce internal dependencies in option parser code. General observations about the code that are not yet converted to issues; some of these may already have been addressed by the changes in the week of September 17-21, 2018: - Currently, some of the users of the option parser use the files in the main source directory, and some of them directly use the files in the "options" directory. The header files in the main source directory are marked as temporary stubs, but we think that perhaps they could be more generally useful to separate the public interface of the option parser from its internals. Whether or not we keep the stubs, all user code should access the option parser in the same way. - The separation between a parser and a parse was very non-existent/unclean. This is now quite a bit better by reducing global object use, but there is probably still a lot more that can be done. - The parse_tree.h file and more generally the use of the external tree library should be rethought. We are perhaps better off not using an external tree implementation. - The actual parsing of text is currently fragile and should perhaps be reimplemented. Perhaps it can also be separated out more from the other code. - The files option_parser.{h,cc} are very large and have multiple responsibilities. (This has become better, but may still be the case.) - As a general principle, we want to have less code in *.h files and more code in *.cc files in the option parser because all code in *.h files is some form of internal code dependency. Perhaps it is worth using the pimpl idiom in a few places to reduce the amount of code that needs to live in header files. - The option parser design should be documented better. Specific issues: - issue481: avoid special case for open lists. - issue524: Use shared_ptr for landmark factories - issue526: Use shared_ptr for Heuristic/Evaluator - issue606: move the code to a directory - issue608: split code into more files - issue619: Get rid of need to list plugin types manually for get_help_templ - issue626: introduce a namespace. - issue717: Remove special cases for landmark synergy - issue718: Avoid special case for Heuristics and ScalarEvaluators - issue764: remove global variables for plan storage - issue826: split option_parser.{h, cc} into smaller responsibilities - issue827: Move code from .h to .cc files - issue830: Use single registry - issue831: unique names for plug-ins and predefinitions - issue832: Rework relation Registry-DocPrinter - issue834: Remove traces of old Plugin class - issue836: Don't use global object for predefinitions - issue840: Don't use global object for registry - issue842: Two-phase initialization of registry (first collect plugin info, then construct them later) with better name collision reporting - issue844: avoid special case for plugin types that support predefinition - issue873: Make the option parser code planner-independent
2018-12-14 18:03:26jendriksetmessages: + msg8357
summary: High-level goals: - Decouple the external interface from the implementation better. Perhaps reduce the external interface to a single #include. - Make the option parser code planner-independent. Some details: - Split the code into smaller parts with clearly defined responsibilities. - Reduce internal dependencies in option parser code. General observations about the code that are not yet converted to issues; some of these may already have been addressed by the changes in the week of September 17-21, 2018: - Currently, some of the users of the option parser use the files in the main source directory, and some of them directly use the files in the "options" directory. The header files in the main source directory are marked as temporary stubs, but we think that perhaps they could be more generally useful to separate the public interface of the option parser from its internals. Whether or not we keep the stubs, all user code should access the option parser in the same way. - The separation between a parser and a parse was very non-existent/unclean. This is now quite a bit better by reducing global object use, but there is probably still a lot more that can be done. - The parse_tree.h file and more generally the use of the external tree library should be rethought. We are perhaps better off not using an external tree implementation. - The actual parsing of text is currently fragile and should perhaps be reimplemented. Perhaps it can also be separated out more from the other code. - The files option_parser.{h,cc} are very large and perhaps have multiple dependencies. - As a general principle, we want to have less code in *.h files and more code in *.cc files in the option parser because all code in *.h files is some form of internal code dependency. Perhaps it is worth using the pimpl idiom in a few places to reduce the amount of code that needs to live in header files. - The option parser design should be documented better. Specific issues: - issue481: avoid special case for open lists. - issue524: Use shared_ptr for landmark factories - issue526: Use shared_ptr for Heuristic/Evaluator - issue606: move the code to a directory - issue608: split code into more files - issue619: Get rid of need to list plugin types manually for get_help_templ - issue626: introduce a namespace. - issue717: Remove special cases for landmark synergy - issue718: Avoid special case for Heuristics and ScalarEvaluators - issue764: remove global variables for plan storage - issue826: split option_parser.{h, cc} into smaller responsibilities - issue827: Move code from .h to .cc files - issue830: Use single registry - issue831: unique names for plug-ins and predefinitions - issue832: Rework relation Registry-DocPrinter - issue834: Remove traces of old Plugin class - issue836: Don't use global object for predefinitions - issue840: Don't use global object for registry - issue842: Two-phase initialization of registry (first collect plugin info, then construct them later) with better name collision reporting - issue844: avoid special case for plugin types that support predefinition -> High-level goals: - Decouple the external interface from the implementation better. Perhaps reduce the external interface to a single #include. - Make the option parser code planner-independent (issue873). Some details: - Split the code into smaller parts with clearly defined responsibilities. - Reduce internal dependencies in option parser code. General observations about the code that are not yet converted to issues; some of these may already have been addressed by the changes in the week of September 17-21, 2018: - Currently, some of the users of the option parser use the files in the main source directory, and some of them directly use the files in the "options" directory. The header files in the main source directory are marked as temporary stubs, but we think that perhaps they could be more generally useful to separate the public interface of the option parser from its internals. Whether or not we keep the stubs, all user code should access the option parser in the same way. - The separation between a parser and a parse was very non-existent/unclean. This is now quite a bit better by reducing global object use, but there is probably still a lot more that can be done. - The parse_tree.h file and more generally the use of the external tree library should be rethought. We are perhaps better off not using an external tree implementation. - The actual parsing of text is currently fragile and should perhaps be reimplemented. Perhaps it can also be separated out more from the other code. - The files option_parser.{h,cc} are very large and perhaps have multiple dependencies. - As a general principle, we want to have less code in *.h files and more code in *.cc files in the option parser because all code in *.h files is some form of internal code dependency. Perhaps it is worth using the pimpl idiom in a few places to reduce the amount of code that needs to live in header files. - The option parser design should be documented better. Specific issues: - issue481: avoid special case for open lists. - issue524: Use shared_ptr for landmark factories - issue526: Use shared_ptr for Heuristic/Evaluator - issue606: move the code to a directory - issue608: split code into more files - issue619: Get rid of need to list plugin types manually for get_help_templ - issue626: introduce a namespace. - issue717: Remove special cases for landmark synergy - issue718: Avoid special case for Heuristics and ScalarEvaluators - issue764: remove global variables for plan storage - issue826: split option_parser.{h, cc} into smaller responsibilities - issue827: Move code from .h to .cc files - issue830: Use single registry - issue831: unique names for plug-ins and predefinitions - issue832: Rework relation Registry-DocPrinter - issue834: Remove traces of old Plugin class - issue836: Don't use global object for predefinitions - issue840: Don't use global object for registry - issue842: Two-phase initialization of registry (first collect plugin info, then construct them later) with better name collision reporting - issue844: avoid special case for plugin types that support predefinition
2018-09-21 14:25:47patfersetmessages: + msg7746
summary: High-level goals: - Decouple the external interface from the implementation better. Perhaps reduce the external interface to a single #include. - Make the option parser code planner-independent. Some details: - Split the code into smaller parts with clearly defined responsibilities. - Reduce internal dependencies in option parser code. General observations about the code that are not yet converted to issues; some of these may already have been addressed by the changes in the week of September 17-21, 2018: - Currently, some of the users of the option parser use the files in the main source directory, and some of them directly use the files in the "options" directory. The header files in the main source directory are marked as temporary stubs, but we think that perhaps they could be more generally useful to separate the public interface of the option parser from its internals. Whether or not we keep the stubs, all user code should access the option parser in the same way. - The separation between a parser and a parse was very non-existent/unclean. This is now quite a bit better by reducing global object use, but there is probably still a lot more that can be done. - The parse_tree.h file and more generally the use of the external tree library should be rethought. We are perhaps better off not using an external tree implementation. - The actual parsing of text is currently fragile and should perhaps be reimplemented. Perhaps it can also be separated out more from the other code. - The files option_parser.{h,cc} are very large and perhaps have multiple dependencies. - As a general principle, we want to have less code in *.h files and more code in *.cc files in the option parser because all code in *.h files is some form of internal code dependency. Perhaps it is worth using the pimpl idiom in a few places to reduce the amount of code that needs to live in header files. - The option parser design should be documented better. Specific issues: - issue481: avoid special case for open lists. - issue524: Use shared_ptr for landmark factories - issue526: Use shared_ptr for Heuristic/Evaluator - issue606: move the code to a directory - issue608: split code into more files - issue619: Get rid of need to list plugin types manually for get_help_templ - issue626: introduce a namespace. - issue717: Remove special cases for landmark synergy - issue718: Avoid special case for Heuristics and ScalarEvaluators - issue764: remove global variables for plan storage - issue826: split option_parser.{h, cc} into smaller responsibilities - issue827: Move code from .h to .cc files - issue830: Use single registry - issue831: unique names for plug-ins and predefinitions - issue832: Rework relation Registry-DocPrinter - issue834: Remove traces of old Plugin class - issue836: Don't use global object for predefinitions - issue842: Two-phase initialization of registry (first collect plugin info, then construct them later) with better name collision reporting - issue844: avoid special case for plugin types that support predefinition -> High-level goals: - Decouple the external interface from the implementation better. Perhaps reduce the external interface to a single #include. - Make the option parser code planner-independent. Some details: - Split the code into smaller parts with clearly defined responsibilities. - Reduce internal dependencies in option parser code. General observations about the code that are not yet converted to issues; some of these may already have been addressed by the changes in the week of September 17-21, 2018: - Currently, some of the users of the option parser use the files in the main source directory, and some of them directly use the files in the "options" directory. The header files in the main source directory are marked as temporary stubs, but we think that perhaps they could be more generally useful to separate the public interface of the option parser from its internals. Whether or not we keep the stubs, all user code should access the option parser in the same way. - The separation between a parser and a parse was very non-existent/unclean. This is now quite a bit better by reducing global object use, but there is probably still a lot more that can be done. - The parse_tree.h file and more generally the use of the external tree library should be rethought. We are perhaps better off not using an external tree implementation. - The actual parsing of text is currently fragile and should perhaps be reimplemented. Perhaps it can also be separated out more from the other code. - The files option_parser.{h,cc} are very large and perhaps have multiple dependencies. - As a general principle, we want to have less code in *.h files and more code in *.cc files in the option parser because all code in *.h files is some form of internal code dependency. Perhaps it is worth using the pimpl idiom in a few places to reduce the amount of code that needs to live in header files. - The option parser design should be documented better. Specific issues: - issue481: avoid special case for open lists. - issue524: Use shared_ptr for landmark factories - issue526: Use shared_ptr for Heuristic/Evaluator - issue606: move the code to a directory - issue608: split code into more files - issue619: Get rid of need to list plugin types manually for get_help_templ - issue626: introduce a namespace. - issue717: Remove special cases for landmark synergy - issue718: Avoid special case for Heuristics and ScalarEvaluators - issue764: remove global variables for plan storage - issue826: split option_parser.{h, cc} into smaller responsibilities - issue827: Move code from .h to .cc files - issue830: Use single registry - issue831: unique names for plug-ins and predefinitions - issue832: Rework relation Registry-DocPrinter - issue834: Remove traces of old Plugin class - issue836: Don't use global object for predefinitions - issue840: Don't use global object for registry - issue842: Two-phase initialization of registry (first collect plugin info, then construct them later) with better name collision reporting - issue844: avoid special case for plugin types that support predefinition
2018-09-21 13:18:32maltesetmessages: + msg7734
summary: High-level goals: - Decouple the external interface from the implementation better. Perhaps reduce the external interface to a single #include. - Make the option parser code planner-independent. Some details: - Split the code into smaller parts with clearly defined responsibilities. - Reduce internal dependencies in option parser code. Specific issues: - issue481: avoid special case for open lists. - issue524: Use shared_ptr for landmark factories - issue526: Use shared_ptr for Heuristic/Evaluator - issue606: move the code to a directory - issue608: split code into more files - issue619: Get rid of need to list plugin types manually for get_help_templ - issue626: introduce a namespace. - issue717: Remove special cases for landmark synergy - issue718: Avoid special case for Heuristics and ScalarEvaluators - issue764: remove global variables for plan storage - issue826: split option_parser.{h, cc} into smaller responsibilities - issue827: Move code from .h to .cc files - issue830: Use single registry - issue831: unique names for plug-ins and predefinitions - issue832: Rework relation Registry-DocPrinter - issue834: Remove traces of old Plugin class - issue836: Don't use global object for predefinitions - issue842: Two-phase initialization of registry (first collect plugin info, then construct them later) with better name collision reporting - issue844: avoid special case for plugin types that support predefinition -> High-level goals: - Decouple the external interface from the implementation better. Perhaps reduce the external interface to a single #include. - Make the option parser code planner-independent. Some details: - Split the code into smaller parts with clearly defined responsibilities. - Reduce internal dependencies in option parser code. General observations about the code that are not yet converted to issues; some of these may already have been addressed by the changes in the week of September 17-21, 2018: - Currently, some of the users of the option parser use the files in the main source directory, and some of them directly use the files in the "options" directory. The header files in the main source directory are marked as temporary stubs, but we think that perhaps they could be more generally useful to separate the public interface of the option parser from its internals. Whether or not we keep the stubs, all user code should access the option parser in the same way. - The separation between a parser and a parse was very non-existent/unclean. This is now quite a bit better by reducing global object use, but there is probably still a lot more that can be done. - The parse_tree.h file and more generally the use of the external tree library should be rethought. We are perhaps better off not using an external tree implementation. - The actual parsing of text is currently fragile and should perhaps be reimplemented. Perhaps it can also be separated out more from the other code. - The files option_parser.{h,cc} are very large and perhaps have multiple dependencies. - As a general principle, we want to have less code in *.h files and more code in *.cc files in the option parser because all code in *.h files is some form of internal code dependency. Perhaps it is worth using the pimpl idiom in a few places to reduce the amount of code that needs to live in header files. - The option parser design should be documented better. Specific issues: - issue481: avoid special case for open lists. - issue524: Use shared_ptr for landmark factories - issue526: Use shared_ptr for Heuristic/Evaluator - issue606: move the code to a directory - issue608: split code into more files - issue619: Get rid of need to list plugin types manually for get_help_templ - issue626: introduce a namespace. - issue717: Remove special cases for landmark synergy - issue718: Avoid special case for Heuristics and ScalarEvaluators - issue764: remove global variables for plan storage - issue826: split option_parser.{h, cc} into smaller responsibilities - issue827: Move code from .h to .cc files - issue830: Use single registry - issue831: unique names for plug-ins and predefinitions - issue832: Rework relation Registry-DocPrinter - issue834: Remove traces of old Plugin class - issue836: Don't use global object for predefinitions - issue842: Two-phase initialization of registry (first collect plugin info, then construct them later) with better name collision reporting - issue844: avoid special case for plugin types that support predefinition
2018-09-21 12:50:35maltesetmessages: + msg7729
summary: High-level goals: - Decouple the external interface from the implementation better. Perhaps reduce the external interface to a single #include. - Make the option parser code planner-independent. Some details: - Split the code into smaller parts with clearly defined responsibilities. - Reduce internal dependencies in option parser code. - Avoid special case for plugin types that support predefinition. Specific issues: - issue481: avoid special case for open lists. - issue524: Use shared_ptr for landmark factories - issue526: Use shared_ptr for Heuristic/Evaluator - issue606: move the code to a directory - issue608: split code into more files - issue619: Get rid of need to list plugin types manually for get_help_templ - issue626: introduce a namespace. - issue717: Remove special cases for landmark synergy - issue718: Avoid special case for Heuristics and ScalarEvaluators - issue764: remove global variables for plan storage - issue826: split option_parser.{h, cc} into smaller responsibilities - issue827: Move code from .h to .cc files - issue830: Use single registry - issue832: Rework relation Registry-DocPrinter - issue834: Remove traces of old Plugin class - issue836: Don't use global object for predefinitions - issue842: Two-phase initialization of registry (first collect plugin info, then construct them later) with better name collision reporting -> High-level goals: - Decouple the external interface from the implementation better. Perhaps reduce the external interface to a single #include. - Make the option parser code planner-independent. Some details: - Split the code into smaller parts with clearly defined responsibilities. - Reduce internal dependencies in option parser code. Specific issues: - issue481: avoid special case for open lists. - issue524: Use shared_ptr for landmark factories - issue526: Use shared_ptr for Heuristic/Evaluator - issue606: move the code to a directory - issue608: split code into more files - issue619: Get rid of need to list plugin types manually for get_help_templ - issue626: introduce a namespace. - issue717: Remove special cases for landmark synergy - issue718: Avoid special case for Heuristics and ScalarEvaluators - issue764: remove global variables for plan storage - issue826: split option_parser.{h, cc} into smaller responsibilities - issue827: Move code from .h to .cc files - issue830: Use single registry - issue831: unique names for plug-ins and predefinitions - issue832: Rework relation Registry-DocPrinter - issue834: Remove traces of old Plugin class - issue836: Don't use global object for predefinitions - issue842: Two-phase initialization of registry (first collect plugin info, then construct them later) with better name collision reporting - issue844: avoid special case for plugin types that support predefinition
2018-09-21 12:22:06maltesetmessages: + msg7720
summary: High-level goals: - Decouple the external interface from the implementation better. Perhaps reduce the external interface to a single #include. - Make the option parser code planner-independent. Some details: - Split the code into smaller parts with clearly defined responsibilities. - Reduce internal dependencies in option parser code. - Avoid special case for Heuristics and ScalarEvaluators (issue718). - Avoid special case for plugin types that support predefinition. - Get rid of need to list plugin types manually for get_help_templ (issue619). - Remove special cases for landmark synergy (issue717). - Use shared_ptr for Heuristic/Evaluator (issue526). - Use shared_ptr for landmark factories (issue524). - Move code from .h to .cc files (issue827) Specific issues: - issue481: avoid special case for open lists. - issue606: move the code to a directory - issue608: split code into more files - issue626: introduce a namespace. - issue764: remove global variables for plan storage - issue826: split option_parser.{h, cc} into smaller responsibilities - issue830: Use single registry - issue832: Rework relation Registry-DocPrinter - issue834: Remove traces of old Plugin class - issue836: Don't use global object for predefinitions - issue842: Two-phase initialization of registry (first collect plugin info, then construct them later) with better name collision reporting -> High-level goals: - Decouple the external interface from the implementation better. Perhaps reduce the external interface to a single #include. - Make the option parser code planner-independent. Some details: - Split the code into smaller parts with clearly defined responsibilities. - Reduce internal dependencies in option parser code. - Avoid special case for plugin types that support predefinition. Specific issues: - issue481: avoid special case for open lists. - issue524: Use shared_ptr for landmark factories - issue526: Use shared_ptr for Heuristic/Evaluator - issue606: move the code to a directory - issue608: split code into more files - issue619: Get rid of need to list plugin types manually for get_help_templ - issue626: introduce a namespace. - issue717: Remove special cases for landmark synergy - issue718: Avoid special case for Heuristics and ScalarEvaluators - issue764: remove global variables for plan storage - issue826: split option_parser.{h, cc} into smaller responsibilities - issue827: Move code from .h to .cc files - issue830: Use single registry - issue832: Rework relation Registry-DocPrinter - issue834: Remove traces of old Plugin class - issue836: Don't use global object for predefinitions - issue842: Two-phase initialization of registry (first collect plugin info, then construct them later) with better name collision reporting
2018-09-21 12:19:19maltesetmessages: + msg7719
summary: High-level goals: - Decouple the external interface from the implementation better. Perhaps reduce the external interface to a single #include. - Make the option parser code planner-independent. Some details: - Split the code into smaller parts with clearly defined responsibilities. - Reduce internal dependencies in option parser code. - Avoid special case for Heuristics and ScalarEvaluators (issue718). - Avoid special case for plugin types that support predefinition. - Get rid of need to list plugin types manually for get_help_templ (issue619). - Remove special cases for landmark synergy (issue717). - Use shared_ptr for Heuristic/Evaluator (issue526). - Use shared_ptr for landmark factories (issue524). - Move code from .h to .cc files (issue827) Specific issues: - ~~issue481: avoid special case for open lists.~~ - ~~issue606: move the code to a directory~~ - ~~issue608: split code into more files~~ - ~~issue626: introduce a namespace.~~ - issue764: remove global variables for plan storage - issue826: ~~split option_parser.{h, cc} into smaller responsibilities~~ - issue830: ~~Use single registry~~ - issue832: Rework relation Registry-DocPrinter - issue834: Remove traces of old Plugin class - issue836: Don't use global object for predefinitions - issue842: Two-phase initialization of registry (first collect plugin info, then construct them later) with better name collision reporting -> High-level goals: - Decouple the external interface from the implementation better. Perhaps reduce the external interface to a single #include. - Make the option parser code planner-independent. Some details: - Split the code into smaller parts with clearly defined responsibilities. - Reduce internal dependencies in option parser code. - Avoid special case for Heuristics and ScalarEvaluators (issue718). - Avoid special case for plugin types that support predefinition. - Get rid of need to list plugin types manually for get_help_templ (issue619). - Remove special cases for landmark synergy (issue717). - Use shared_ptr for Heuristic/Evaluator (issue526). - Use shared_ptr for landmark factories (issue524). - Move code from .h to .cc files (issue827) Specific issues: - issue481: avoid special case for open lists. - issue606: move the code to a directory - issue608: split code into more files - issue626: introduce a namespace. - issue764: remove global variables for plan storage - issue826: split option_parser.{h, cc} into smaller responsibilities - issue830: Use single registry - issue832: Rework relation Registry-DocPrinter - issue834: Remove traces of old Plugin class - issue836: Don't use global object for predefinitions - issue842: Two-phase initialization of registry (first collect plugin info, then construct them later) with better name collision reporting
2018-09-21 12:17:15maltesetmessages: + msg7718
summary: High-level goals: - Decouple the external interface from the implementation better. Perhaps reduce the external interface to a single #include. - Make the option parser code planner-independent. Some details: - Split the code into smaller parts with clearly defined responsibilities. - Reduce internal dependencies in option parser code. - Avoid special case for Heuristics and ScalarEvaluators (issue718). - Avoid special case for plugin types that support predefinition. - Get rid of need to list plugin types manually for get_help_templ (issue619). - Remove special cases for landmark synergy (issue717). - Use shared_ptr for Heuristic/Evaluator (issue526). - Use shared_ptr for landmark factories (issue524). - Move code from .h to .cc files (issue827) Plans for detecting plugin name collisions: - Put the test that no two plug-ins have the same name in a more central place of the option parser code rather than in the DocStore. - Change option parser design to do a two-phase registration of plug-ins, so that we can first collect all of them, then do global checks against duplicates etc., and then proceed with the later parts of registration at a stage where we know that all plug-ins (including type plug-ins) have been initialized. - Report name collisions of plug-ins in a well-defined order, e.g. alphabetically by name and for each name alphabetically listing the types. Specific issues: - ~~issue481: avoid special case for open lists.~~ - ~~issue606: move the code to a directory~~ - ~~issue608: split code into more files~~ - ~~issue626: introduce a namespace.~~ - issue764: remove global variables for plan storage - issue826: ~~split option_parser.{h, cc} into smaller responsibilities~~ - issue830: ~~Use single registry~~ - issue832: Rework relation Registry-DocPrinter - issue834: Remove traces of old Plugin class - issue836: Don't use global object for predefinitions -> High-level goals: - Decouple the external interface from the implementation better. Perhaps reduce the external interface to a single #include. - Make the option parser code planner-independent. Some details: - Split the code into smaller parts with clearly defined responsibilities. - Reduce internal dependencies in option parser code. - Avoid special case for Heuristics and ScalarEvaluators (issue718). - Avoid special case for plugin types that support predefinition. - Get rid of need to list plugin types manually for get_help_templ (issue619). - Remove special cases for landmark synergy (issue717). - Use shared_ptr for Heuristic/Evaluator (issue526). - Use shared_ptr for landmark factories (issue524). - Move code from .h to .cc files (issue827) Specific issues: - ~~issue481: avoid special case for open lists.~~ - ~~issue606: move the code to a directory~~ - ~~issue608: split code into more files~~ - ~~issue626: introduce a namespace.~~ - issue764: remove global variables for plan storage - issue826: ~~split option_parser.{h, cc} into smaller responsibilities~~ - issue830: ~~Use single registry~~ - issue832: Rework relation Registry-DocPrinter - issue834: Remove traces of old Plugin class - issue836: Don't use global object for predefinitions - issue842: Two-phase initialization of registry (first collect plugin info, then construct them later) with better name collision reporting
2018-09-20 11:14:21salomesetsummary: High-level goals: - Decouple the external interface from the implementation better. Perhaps reduce the external interface to a single #include. - Make the option parser code planner-independent. Some details: - Split the code into smaller parts with clearly defined responsibilities. - Reduce internal dependencies in option parser code. - Avoid special case for Heuristics and ScalarEvaluators (issue718). - Avoid special case for plugin types that support predefinition. - Get rid of need to list plugin types manually for get_help_templ (issue619). - Remove special cases for landmark synergy (issue717). - Use shared_ptr for Heuristic/Evaluator (issue526). - Use shared_ptr for landmark factories (issue524). - Move code from .h to .cc files (issue827) Plans for detecting plugin name collisions: - Put the test that no two plug-ins have the same name in a more central place of the option parser code rather than in the DocStore. - Change option parser design to do a two-phase registration of plug-ins, so that we can first collect all of them, then do global checks against duplicates etc., and then proceed with the later parts of registration at a stage where we know that all plug-ins (including type plug-ins) have been initialized. - Report name collisions of plug-ins in a well-defined order, e.g. alphabetically by name and for each name alphabetically listing the types. Specific issues: - ~~issue481: avoid special case for open lists.~~ - ~~issue606: move the code to a directory~~ - ~~issue608: split code into more files~~ - ~~issue626: introduce a namespace.~~ - issue764: remove global variables for plan storage - issue826: ~~split option_parser.{h, cc} into smaller responsibilities~~ - issue830: Use single registry - issue832: Rework relation Registry-DocPrinter - issue834: Remove traces of old Plugin class -> High-level goals: - Decouple the external interface from the implementation better. Perhaps reduce the external interface to a single #include. - Make the option parser code planner-independent. Some details: - Split the code into smaller parts with clearly defined responsibilities. - Reduce internal dependencies in option parser code. - Avoid special case for Heuristics and ScalarEvaluators (issue718). - Avoid special case for plugin types that support predefinition. - Get rid of need to list plugin types manually for get_help_templ (issue619). - Remove special cases for landmark synergy (issue717). - Use shared_ptr for Heuristic/Evaluator (issue526). - Use shared_ptr for landmark factories (issue524). - Move code from .h to .cc files (issue827) Plans for detecting plugin name collisions: - Put the test that no two plug-ins have the same name in a more central place of the option parser code rather than in the DocStore. - Change option parser design to do a two-phase registration of plug-ins, so that we can first collect all of them, then do global checks against duplicates etc., and then proceed with the later parts of registration at a stage where we know that all plug-ins (including type plug-ins) have been initialized. - Report name collisions of plug-ins in a well-defined order, e.g. alphabetically by name and for each name alphabetically listing the types. Specific issues: - ~~issue481: avoid special case for open lists.~~ - ~~issue606: move the code to a directory~~ - ~~issue608: split code into more files~~ - ~~issue626: introduce a namespace.~~ - issue764: remove global variables for plan storage - issue826: ~~split option_parser.{h, cc} into smaller responsibilities~~ - issue830: ~~Use single registry~~ - issue832: Rework relation Registry-DocPrinter - issue834: Remove traces of old Plugin class - issue836: Don't use global object for predefinitions
2018-09-19 20:22:51jendriksetmessages: + msg7609
summary: High-level goals: - Decouple the external interface from the implementation better. Perhaps reduce the external interface to a single #include. - Make the option parser code planner-independent. Some details: - Split the code into smaller parts with clearly defined responsibilities. - Reduce internal dependencies in option parser code. - Avoid special case for Heuristics and ScalarEvaluators (issue718). - Avoid special case for plugin types that support predefinition. - Get rid of need to list plugin types manually for get_help_templ (issue619). - Remove special cases for landmark synergy (issue717). - Use shared_ptr for Heuristic/Evaluator (issue526). - Use shared_ptr for landmark factories (issue524). - Move code from .h to .cc files (issue827) Plans for detecting plugin name collisions: - Put the test that no two plug-ins have the same name in a more central place of the option parser code rather than in the DocStore. - Change option parser design to do a two-phase registration of plug-ins, so that we can first collect all of them, then do global checks against duplicates etc., and then proceed with the later parts of registration at a stage where we know that all plug-ins (including type plug-ins) have been initialized. - Report name collisions of plug-ins in a well-defined order, e.g. alphabetically by name and for each name alphabetically listing the types. Specific issues: - ~~issue481: avoid special case for open lists.~~ - ~~issue606: move the code to a directory~~ - ~~issue608: split code into more files~~ - ~~issue626: introduce a namespace.~~ - issue764: remove global variables for plan storage - issue826: ~~split code of option_parser.{h, cc} into smaller responsibilities~~ - issue830: Single registry for PluginRegistry, PluginTypeRegistry, - issue832: Rework relation Registry-DocPrinter - issue834: Remove traces of old Plugin class PluginGroupRegistry -> High-level goals: - Decouple the external interface from the implementation better. Perhaps reduce the external interface to a single #include. - Make the option parser code planner-independent. Some details: - Split the code into smaller parts with clearly defined responsibilities. - Reduce internal dependencies in option parser code. - Avoid special case for Heuristics and ScalarEvaluators (issue718). - Avoid special case for plugin types that support predefinition. - Get rid of need to list plugin types manually for get_help_templ (issue619). - Remove special cases for landmark synergy (issue717). - Use shared_ptr for Heuristic/Evaluator (issue526). - Use shared_ptr for landmark factories (issue524). - Move code from .h to .cc files (issue827) Plans for detecting plugin name collisions: - Put the test that no two plug-ins have the same name in a more central place of the option parser code rather than in the DocStore. - Change option parser design to do a two-phase registration of plug-ins, so that we can first collect all of them, then do global checks against duplicates etc., and then proceed with the later parts of registration at a stage where we know that all plug-ins (including type plug-ins) have been initialized. - Report name collisions of plug-ins in a well-defined order, e.g. alphabetically by name and for each name alphabetically listing the types. Specific issues: - ~~issue481: avoid special case for open lists.~~ - ~~issue606: move the code to a directory~~ - ~~issue608: split code into more files~~ - ~~issue626: introduce a namespace.~~ - issue764: remove global variables for plan storage - issue826: ~~split option_parser.{h, cc} into smaller responsibilities~~ - issue830: Use single registry - issue832: Rework relation Registry-DocPrinter - issue834: Remove traces of old Plugin class
2018-09-19 20:21:05jendriksetstatus: chatting -> in-progress
messages: + msg7608
summary: High-level goals: - Decouple the external interface from the implementation better. Perhaps reduce the external interface to a single #include. - Make the option parser code planner-independent. Some details: - Split the code into smaller parts with clearly defined responsibilities. - Reduce internal dependencies in option parser code. - Avoid special case for Heuristics and ScalarEvaluators (issue718). - Avoid special case for plugin types that support predefinition. - Get rid of need to list plugin types manually for get_help_templ (issue619). - Remove special cases for landmark synergy (issue717). - Use shared_ptr for Heuristic/Evaluator (issue526). - Use shared_ptr for landmark factories (issue524). - Move code from .h to .cc files (issue827) Plans for detecting plugin name collisions: - Put the test that no two plug-ins have the same name in a more central place of the option parser code rather than in the DocStore. - Change option parser design to do a two-phase registration of plug-ins, so that we can first collect all of them, then do global checks against duplicates etc., and then proceed with the later parts of registration at a stage where we know that all plug-ins (including type plug-ins) have been initialized. - Report name collisions of plug-ins in a well-defined order, e.g. alphabetically by name and for each name alphabetically listing the types. Specific issues: - ~~issue481: avoid special case for open lists.~~ - ~~issue606: move the code to a directory~~ - ~~issue608: split code into more files~~ - ~~issue626: introduce a namespace.~~ - issue764: remove global variables for plan storage - issue826: ~~split code of option_parser.{h, cc} into smaller responsibilities~~ - issue830: Single registry for PluginRegistry, PluginTypeRegistry, - issue832: Rework relation Registry-DocPrinter PluginGroupRegistry -> High-level goals: - Decouple the external interface from the implementation better. Perhaps reduce the external interface to a single #include. - Make the option parser code planner-independent. Some details: - Split the code into smaller parts with clearly defined responsibilities. - Reduce internal dependencies in option parser code. - Avoid special case for Heuristics and ScalarEvaluators (issue718). - Avoid special case for plugin types that support predefinition. - Get rid of need to list plugin types manually for get_help_templ (issue619). - Remove special cases for landmark synergy (issue717). - Use shared_ptr for Heuristic/Evaluator (issue526). - Use shared_ptr for landmark factories (issue524). - Move code from .h to .cc files (issue827) Plans for detecting plugin name collisions: - Put the test that no two plug-ins have the same name in a more central place of the option parser code rather than in the DocStore. - Change option parser design to do a two-phase registration of plug-ins, so that we can first collect all of them, then do global checks against duplicates etc., and then proceed with the later parts of registration at a stage where we know that all plug-ins (including type plug-ins) have been initialized. - Report name collisions of plug-ins in a well-defined order, e.g. alphabetically by name and for each name alphabetically listing the types. Specific issues: - ~~issue481: avoid special case for open lists.~~ - ~~issue606: move the code to a directory~~ - ~~issue608: split code into more files~~ - ~~issue626: introduce a namespace.~~ - issue764: remove global variables for plan storage - issue826: ~~split code of option_parser.{h, cc} into smaller responsibilities~~ - issue830: Single registry for PluginRegistry, PluginTypeRegistry, - issue832: Rework relation Registry-DocPrinter - issue834: Remove traces of old Plugin class PluginGroupRegistry
2018-09-19 16:44:09patfersetsummary: High-level goals: - Decouple the external interface from the implementation better. Perhaps reduce the external interface to a single #include. - Make the option parser code planner-independent. Some details: - Split the code into smaller parts with clearly defined responsibilities. - Reduce internal dependencies in option parser code. - Avoid special case for Heuristics and ScalarEvaluators (issue718). - Avoid special case for plugin types that support predefinition. - Get rid of need to list plugin types manually for get_help_templ (issue619). - Remove special cases for landmark synergy (issue717). - Use shared_ptr for Heuristic/Evaluator (issue526). - Use shared_ptr for landmark factories (issue524). - Move code from .h to .cc files (issue827) Plans for detecting plugin name collisions: - Put the test that no two plug-ins have the same name in a more central place of the option parser code rather than in the DocStore. - Change option parser design to do a two-phase registration of plug-ins, so that we can first collect all of them, then do global checks against duplicates etc., and then proceed with the later parts of registration at a stage where we know that all plug-ins (including type plug-ins) have been initialized. - Report name collisions of plug-ins in a well-defined order, e.g. alphabetically by name and for each name alphabetically listing the types. Specific issues: - ~~issue481: avoid special case for open lists.~~ - ~~issue606: move the code to a directory~~ - ~~issue608: split code into more files~~ - ~~issue626: introduce a namespace.~~ - issue764: remove global variables for plan storage - issue826: ~~split code of option_parser.{h, cc} into smaller responsibilities~~ - issue830: Single registry for PluginRegistry, PluginTypeRegistry, PluginGroupRegistry -> High-level goals: - Decouple the external interface from the implementation better. Perhaps reduce the external interface to a single #include. - Make the option parser code planner-independent. Some details: - Split the code into smaller parts with clearly defined responsibilities. - Reduce internal dependencies in option parser code. - Avoid special case for Heuristics and ScalarEvaluators (issue718). - Avoid special case for plugin types that support predefinition. - Get rid of need to list plugin types manually for get_help_templ (issue619). - Remove special cases for landmark synergy (issue717). - Use shared_ptr for Heuristic/Evaluator (issue526). - Use shared_ptr for landmark factories (issue524). - Move code from .h to .cc files (issue827) Plans for detecting plugin name collisions: - Put the test that no two plug-ins have the same name in a more central place of the option parser code rather than in the DocStore. - Change option parser design to do a two-phase registration of plug-ins, so that we can first collect all of them, then do global checks against duplicates etc., and then proceed with the later parts of registration at a stage where we know that all plug-ins (including type plug-ins) have been initialized. - Report name collisions of plug-ins in a well-defined order, e.g. alphabetically by name and for each name alphabetically listing the types. Specific issues: - ~~issue481: avoid special case for open lists.~~ - ~~issue606: move the code to a directory~~ - ~~issue608: split code into more files~~ - ~~issue626: introduce a namespace.~~ - issue764: remove global variables for plan storage - issue826: ~~split code of option_parser.{h, cc} into smaller responsibilities~~ - issue830: Single registry for PluginRegistry, PluginTypeRegistry, - issue832: Rework relation Registry-DocPrinter PluginGroupRegistry
2018-09-19 11:25:16patfersetsummary: High-level goals: - Decouple the external interface from the implementation better. Perhaps reduce the external interface to a single #include. - Make the option parser code planner-independent. Some details: - Split the code into smaller parts with clearly defined responsibilities. - Reduce internal dependencies in option parser code. - Avoid special case for Heuristics and ScalarEvaluators (issue718). - Avoid special case for plugin types that support predefinition. - Get rid of need to list plugin types manually for get_help_templ (issue619). - Remove special cases for landmark synergy (issue717). - Use shared_ptr for Heuristic/Evaluator (issue526). - Use shared_ptr for landmark factories (issue524). - Move code from .h to .cc files (issue827) Plans for detecting plugin name collisions: - Put the test that no two plug-ins have the same name in a more central place of the option parser code rather than in the DocStore. - Change option parser design to do a two-phase registration of plug-ins, so that we can first collect all of them, then do global checks against duplicates etc., and then proceed with the later parts of registration at a stage where we know that all plug-ins (including type plug-ins) have been initialized. - Report name collisions of plug-ins in a well-defined order, e.g. alphabetically by name and for each name alphabetically listing the types. Specific issues: - ~~issue481: avoid special case for open lists.~~ - ~~issue606: move the code to a directory~~ - ~~issue608: split code into more files~~ - ~~issue626: introduce a namespace.~~ - issue764: remove global variables for plan storage - issue826: split code of option_parser.{h, cc} into smaller responsibilities -> High-level goals: - Decouple the external interface from the implementation better. Perhaps reduce the external interface to a single #include. - Make the option parser code planner-independent. Some details: - Split the code into smaller parts with clearly defined responsibilities. - Reduce internal dependencies in option parser code. - Avoid special case for Heuristics and ScalarEvaluators (issue718). - Avoid special case for plugin types that support predefinition. - Get rid of need to list plugin types manually for get_help_templ (issue619). - Remove special cases for landmark synergy (issue717). - Use shared_ptr for Heuristic/Evaluator (issue526). - Use shared_ptr for landmark factories (issue524). - Move code from .h to .cc files (issue827) Plans for detecting plugin name collisions: - Put the test that no two plug-ins have the same name in a more central place of the option parser code rather than in the DocStore. - Change option parser design to do a two-phase registration of plug-ins, so that we can first collect all of them, then do global checks against duplicates etc., and then proceed with the later parts of registration at a stage where we know that all plug-ins (including type plug-ins) have been initialized. - Report name collisions of plug-ins in a well-defined order, e.g. alphabetically by name and for each name alphabetically listing the types. Specific issues: - ~~issue481: avoid special case for open lists.~~ - ~~issue606: move the code to a directory~~ - ~~issue608: split code into more files~~ - ~~issue626: introduce a namespace.~~ - issue764: remove global variables for plan storage - issue826: ~~split code of option_parser.{h, cc} into smaller responsibilities~~ - issue830: Single registry for PluginRegistry, PluginTypeRegistry, PluginGroupRegistry
2018-09-18 13:31:39silvansetnosy: + silvan
2018-09-18 12:43:51salomesetsummary: High-level goals: - Decouple the external interface from the implementation better. Perhaps reduce the external interface to a single #include. - Make the option parser code planner-independent. Some details: - Split the code into smaller parts with clearly defined responsibilities. - Reduce internal dependencies in option parser code. - Avoid special case for Heuristics and ScalarEvaluators (issue718). - Avoid special case for plugin types that support predefinition. - Get rid of need to list plugin types manually for get_help_templ (issue619). - Remove special cases for landmark synergy (issue717). - Use shared_ptr for Heuristic/Evaluator (issue526). - Use shared_ptr for landmark factories (issue524). Plans for detecting plugin name collisions: - Put the test that no two plug-ins have the same name in a more central place of the option parser code rather than in the DocStore. - Change option parser design to do a two-phase registration of plug-ins, so that we can first collect all of them, then do global checks against duplicates etc., and then proceed with the later parts of registration at a stage where we know that all plug-ins (including type plug-ins) have been initialized. - Report name collisions of plug-ins in a well-defined order, e.g. alphabetically by name and for each name alphabetically listing the types. Specific issues: - ~~issue481: avoid special case for open lists.~~ - ~~issue606: move the code to a directory~~ - ~~issue608: split code into more files~~ - ~~issue626: introduce a namespace.~~ - issue764: remove global variables for plan storage - issue826: split code of option_parser.{h, cc} into smaller responsibilities -> High-level goals: - Decouple the external interface from the implementation better. Perhaps reduce the external interface to a single #include. - Make the option parser code planner-independent. Some details: - Split the code into smaller parts with clearly defined responsibilities. - Reduce internal dependencies in option parser code. - Avoid special case for Heuristics and ScalarEvaluators (issue718). - Avoid special case for plugin types that support predefinition. - Get rid of need to list plugin types manually for get_help_templ (issue619). - Remove special cases for landmark synergy (issue717). - Use shared_ptr for Heuristic/Evaluator (issue526). - Use shared_ptr for landmark factories (issue524). - Move code from .h to .cc files (issue827) Plans for detecting plugin name collisions: - Put the test that no two plug-ins have the same name in a more central place of the option parser code rather than in the DocStore. - Change option parser design to do a two-phase registration of plug-ins, so that we can first collect all of them, then do global checks against duplicates etc., and then proceed with the later parts of registration at a stage where we know that all plug-ins (including type plug-ins) have been initialized. - Report name collisions of plug-ins in a well-defined order, e.g. alphabetically by name and for each name alphabetically listing the types. Specific issues: - ~~issue481: avoid special case for open lists.~~ - ~~issue606: move the code to a directory~~ - ~~issue608: split code into more files~~ - ~~issue626: introduce a namespace.~~ - issue764: remove global variables for plan storage - issue826: split code of option_parser.{h, cc} into smaller responsibilities
2018-09-18 12:38:26patfersetnosy: + patfer
summary: High-level goals: - Decouple the external interface from the implementation better. Perhaps reduce the external interface to a single #include. - Make the option parser code planner-independent. Some details: - Split the code into smaller parts with clearly defined responsibilities. - Reduce internal dependencies in option parser code. - Avoid special case for Heuristics and ScalarEvaluators (issue718). - Avoid special case for plugin types that support predefinition. - Get rid of need to list plugin types manually for get_help_templ (issue619). - Remove special cases for landmark synergy (issue717). - Use shared_ptr for Heuristic/Evaluator (issue526). - Use shared_ptr for landmark factories (issue524). Plans for detecting plugin name collisions: - Put the test that no two plug-ins have the same name in a more central place of the option parser code rather than in the DocStore. - Change option parser design to do a two-phase registration of plug-ins, so that we can first collect all of them, then do global checks against duplicates etc., and then proceed with the later parts of registration at a stage where we know that all plug-ins (including type plug-ins) have been initialized. - Report name collisions of plug-ins in a well-defined order, e.g. alphabetically by name and for each name alphabetically listing the types. Specific issues: - ~~issue481: avoid special case for open lists.~~ - ~~issue606: move the code to a directory~~ - ~~issue608: split code into more files~~ - ~~issue626: introduce a namespace.~~ - issue764: remove global variables for plan storage -> High-level goals: - Decouple the external interface from the implementation better. Perhaps reduce the external interface to a single #include. - Make the option parser code planner-independent. Some details: - Split the code into smaller parts with clearly defined responsibilities. - Reduce internal dependencies in option parser code. - Avoid special case for Heuristics and ScalarEvaluators (issue718). - Avoid special case for plugin types that support predefinition. - Get rid of need to list plugin types manually for get_help_templ (issue619). - Remove special cases for landmark synergy (issue717). - Use shared_ptr for Heuristic/Evaluator (issue526). - Use shared_ptr for landmark factories (issue524). Plans for detecting plugin name collisions: - Put the test that no two plug-ins have the same name in a more central place of the option parser code rather than in the DocStore. - Change option parser design to do a two-phase registration of plug-ins, so that we can first collect all of them, then do global checks against duplicates etc., and then proceed with the later parts of registration at a stage where we know that all plug-ins (including type plug-ins) have been initialized. - Report name collisions of plug-ins in a well-defined order, e.g. alphabetically by name and for each name alphabetically listing the types. Specific issues: - ~~issue481: avoid special case for open lists.~~ - ~~issue606: move the code to a directory~~ - ~~issue608: split code into more files~~ - ~~issue626: introduce a namespace.~~ - issue764: remove global variables for plan storage - issue826: split code of option_parser.{h, cc} into smaller responsibilities
2018-05-11 17:03:44guillemsetnosy: + guillem
2018-03-15 12:22:18floriansetmessages: + msg6857
summary: High-level goals: - Decouple the external interface from the implementation better. Perhaps reduce the external interface to a single #include. - Make the option parser code planner-independent. Some details: - Split the code into smaller parts with clearly defined responsibilities. - Reduce internal dependencies in option parser code. - Avoid special case for Heuristics and ScalarEvaluators (issue718). - Avoid special case for plugin types that support predefinition. - Get rid of need to list plugin types manually for get_help_templ (issue619). - Remove special cases for landmark synergy (issue717). - Use shared_ptr for Heuristic/Evaluator (issue526). - Use shared_ptr for landmark factories (issue524). Plans for detecting plugin name collisions: - Put the test that no two plug-ins have the same name in a more central place of the option parser code rather than in the DocStore. - Change option parser design to do a two-phase registration of plug-ins, so that we can first collect all of them, then do global checks against duplicates etc., and then proceed with the later parts of registration at a stage where we know that all plug-ins (including type plug-ins) have been initialized. - Report name collisions of plug-ins in a well-defined order, e.g. alphabetically by name and for each name alphabetically listing the types. Specific issues: - ~~issue481: avoid special case for open lists.~~ - ~~issue606: move the code to a directory~~ - ~~issue608: split code into more files~~ - ~~issue626: introduce a namespace.~~ -> High-level goals: - Decouple the external interface from the implementation better. Perhaps reduce the external interface to a single #include. - Make the option parser code planner-independent. Some details: - Split the code into smaller parts with clearly defined responsibilities. - Reduce internal dependencies in option parser code. - Avoid special case for Heuristics and ScalarEvaluators (issue718). - Avoid special case for plugin types that support predefinition. - Get rid of need to list plugin types manually for get_help_templ (issue619). - Remove special cases for landmark synergy (issue717). - Use shared_ptr for Heuristic/Evaluator (issue526). - Use shared_ptr for landmark factories (issue524). Plans for detecting plugin name collisions: - Put the test that no two plug-ins have the same name in a more central place of the option parser code rather than in the DocStore. - Change option parser design to do a two-phase registration of plug-ins, so that we can first collect all of them, then do global checks against duplicates etc., and then proceed with the later parts of registration at a stage where we know that all plug-ins (including type plug-ins) have been initialized. - Report name collisions of plug-ins in a well-defined order, e.g. alphabetically by name and for each name alphabetically listing the types. Specific issues: - ~~issue481: avoid special case for open lists.~~ - ~~issue606: move the code to a directory~~ - ~~issue608: split code into more files~~ - ~~issue626: introduce a namespace.~~ - issue764: remove global variables for plan storage
2017-11-27 12:23:32jendriksetnosy: + cedric
messages: + msg6602
summary: High-level goals: - Decouple the external interface from the implementation better. Perhaps reduce the external interface to a single #include. - Make the option parser code planner-independent. Some details: - Split the code into smaller parts with clearly defined responsibilities. - Reduce internal dependencies in option parser code. - Avoid special case for Heuristics and ScalarEvaluators (issue718). - Avoid special case for plugin types that support predefinition. - Get rid of need to list plugin types manually for get_help_templ. (This should also fix issue619.) Plans for detecting plugin name collisions: - Put the test that no two plug-ins have the same name in a more central place of the option parser code rather than in the DocStore. - Change option parser design to do a two-phase registration of plug-ins, so that we can first collect all of them, then do global checks against duplicates etc., and then proceed with the later parts of registration at a stage where we know that all plug-ins (including type plug-ins) have been initialized. - Report name collisions of plug-ins in a well-defined order, e.g. alphabetically by name and for each name alphabetically listing the types. Specific issues: - ~~issue481: avoid special case for open lists.~~ - ~~issue606: move the code to a directory~~ - ~~issue608: split code into more files~~ - ~~issue626: introduce a namespace.~~ -> High-level goals: - Decouple the external interface from the implementation better. Perhaps reduce the external interface to a single #include. - Make the option parser code planner-independent. Some details: - Split the code into smaller parts with clearly defined responsibilities. - Reduce internal dependencies in option parser code. - Avoid special case for Heuristics and ScalarEvaluators (issue718). - Avoid special case for plugin types that support predefinition. - Get rid of need to list plugin types manually for get_help_templ (issue619). - Remove special cases for landmark synergy (issue717). - Use shared_ptr for Heuristic/Evaluator (issue526). - Use shared_ptr for landmark factories (issue524). Plans for detecting plugin name collisions: - Put the test that no two plug-ins have the same name in a more central place of the option parser code rather than in the DocStore. - Change option parser design to do a two-phase registration of plug-ins, so that we can first collect all of them, then do global checks against duplicates etc., and then proceed with the later parts of registration at a stage where we know that all plug-ins (including type plug-ins) have been initialized. - Report name collisions of plug-ins in a well-defined order, e.g. alphabetically by name and for each name alphabetically listing the types. Specific issues: - ~~issue481: avoid special case for open lists.~~ - ~~issue606: move the code to a directory~~ - ~~issue608: split code into more files~~ - ~~issue626: introduce a namespace.~~
2017-05-22 11:47:43jendriksetmessages: + msg6385
summary: High-level goals: - Decouple the external interface from the implementation better. Perhaps reduce the external interface to a single #include. - Make the option parser code planner-independent. Some details: - Split the code into smaller parts with clearly defined responsibilities. - Reduce internal dependencies in option parser code. - Avoid special case for Heuristics and ScalarEvaluators (issue718). - Avoid special case for plugin types that support predefinition. - Get rid of need to list plugin types manually for get_help_templ. (This should also fix issue619.) Specific issues: - ~~issue481: avoid special case for open lists.~~ - ~~issue606: move the code to a directory~~ - ~~issue608: split code into more files~~ - ~~issue626: introduce a namespace.~~ -> High-level goals: - Decouple the external interface from the implementation better. Perhaps reduce the external interface to a single #include. - Make the option parser code planner-independent. Some details: - Split the code into smaller parts with clearly defined responsibilities. - Reduce internal dependencies in option parser code. - Avoid special case for Heuristics and ScalarEvaluators (issue718). - Avoid special case for plugin types that support predefinition. - Get rid of need to list plugin types manually for get_help_templ. (This should also fix issue619.) Plans for detecting plugin name collisions: - Put the test that no two plug-ins have the same name in a more central place of the option parser code rather than in the DocStore. - Change option parser design to do a two-phase registration of plug-ins, so that we can first collect all of them, then do global checks against duplicates etc., and then proceed with the later parts of registration at a stage where we know that all plug-ins (including type plug-ins) have been initialized. - Report name collisions of plug-ins in a well-defined order, e.g. alphabetically by name and for each name alphabetically listing the types. Specific issues: - ~~issue481: avoid special case for open lists.~~ - ~~issue606: move the code to a directory~~ - ~~issue608: split code into more files~~ - ~~issue626: introduce a namespace.~~
2017-04-28 14:00:32maltesetmessages: + msg6270
summary: High-level goals: - Decouple the external interface from the implementation better. Perhaps reduce the external interface to a single #include. - Make the option parser code planner-independent. Some details: - Split the code into smaller parts with clearly defined responsibilities. - Reduce internal dependencies in option parser code. - ~~Avoid special case for Heuristics and ScalarEvaluators.~~ - Avoid special case for plugin types that support predefinition. - Get rid of need to list plugin types manually for get_help_templ. (This should also fix issue619.) Specific issues: - ~~issue481: avoid special case for open lists.~~ - ~~issue606: move the code to a directory~~ - ~~issue608: split code into more files~~ - ~~issue626: introduce a namespace.~~ -> High-level goals: - Decouple the external interface from the implementation better. Perhaps reduce the external interface to a single #include. - Make the option parser code planner-independent. Some details: - Split the code into smaller parts with clearly defined responsibilities. - Reduce internal dependencies in option parser code. - Avoid special case for Heuristics and ScalarEvaluators (issue718). - Avoid special case for plugin types that support predefinition. - Get rid of need to list plugin types manually for get_help_templ. (This should also fix issue619.) Specific issues: - ~~issue481: avoid special case for open lists.~~ - ~~issue606: move the code to a directory~~ - ~~issue608: split code into more files~~ - ~~issue626: introduce a namespace.~~
2017-04-28 13:53:33manuelsetnosy: + manuel
messages: + msg6268
summary: High-level goals: - Decouple the external interface from the implementation better. Perhaps reduce the external interface to a single #include. - Make the option parser code planner-independent. Some details: - Split the code into smaller parts with clearly defined responsibilities. - Reduce internal dependencies in option parser code. - Avoid special case for Heuristics and ScalarEvaluators. - Avoid special case for plugin types that support predefinition. - Get rid of need to list plugin types manually for get_help_templ. (This should also fix issue619.) Specific issues: - ~~issue481: avoid special case for open lists.~~ - ~~issue606: move the code to a directory~~ - ~~issue608: split code into more files~~ - ~~issue626: introduce a namespace.~~ -> High-level goals: - Decouple the external interface from the implementation better. Perhaps reduce the external interface to a single #include. - Make the option parser code planner-independent. Some details: - Split the code into smaller parts with clearly defined responsibilities. - Reduce internal dependencies in option parser code. - ~~Avoid special case for Heuristics and ScalarEvaluators.~~ - Avoid special case for plugin types that support predefinition. - Get rid of need to list plugin types manually for get_help_templ. (This should also fix issue619.) Specific issues: - ~~issue481: avoid special case for open lists.~~ - ~~issue606: move the code to a directory~~ - ~~issue608: split code into more files~~ - ~~issue626: introduce a namespace.~~
2016-12-31 15:52:17maltesetmessages: + msg5995
2016-12-29 18:24:07hazsetnosy: + haz
2016-01-19 10:54:12floriansetmessages: + msg5110
summary: High-level goals: - Decouple the external interface from the implementation better. Perhaps reduce the external interface to a single #include. - Make the option parser code planner-independent. Some details: - Split the code into smaller parts with clearly defined responsibilities. - Reduce internal dependencies in option parser code. - Avoid special case for Heuristics and ScalarEvaluators. - Avoid special case for plugin types that support predefinition. - Get rid of need to list plugin types manually for get_help_templ. (This should also fix issue619.) Specific issues: - ~~issue481: avoid special case for open lists.~~ - ~~issue606: move the code to a directory~~ - ~~issue608: split code into more files~~ - issue626: introduce a namespace. -> High-level goals: - Decouple the external interface from the implementation better. Perhaps reduce the external interface to a single #include. - Make the option parser code planner-independent. Some details: - Split the code into smaller parts with clearly defined responsibilities. - Reduce internal dependencies in option parser code. - Avoid special case for Heuristics and ScalarEvaluators. - Avoid special case for plugin types that support predefinition. - Get rid of need to list plugin types manually for get_help_templ. (This should also fix issue619.) Specific issues: - ~~issue481: avoid special case for open lists.~~ - ~~issue606: move the code to a directory~~ - ~~issue608: split code into more files~~ - ~~issue626: introduce a namespace.~~
2016-01-15 22:01:31floriansetmessages: + msg5092
summary: High-level goals: - Decouple the external interface from the implementation better. Perhaps reduce the external interface to a single #include. - Make the option parser code planner-independent. Some details: - Split the code into smaller parts with clearly defined responsibilities. - Reduce internal dependencies in option parser code. - Avoid special case for Heuristics and ScalarEvaluators. - Avoid special case for plugin types that support predefinition. - Get rid of need to list plugin types manually for get_help_templ. (This should also fix issue619.) - Introduce a namespace. Specific issues: - ~~issue481: avoid special case for open lists.~~ - ~~issue606: move the code to a directory~~ - ~~issue608: split code into more files~~ -> High-level goals: - Decouple the external interface from the implementation better. Perhaps reduce the external interface to a single #include. - Make the option parser code planner-independent. Some details: - Split the code into smaller parts with clearly defined responsibilities. - Reduce internal dependencies in option parser code. - Avoid special case for Heuristics and ScalarEvaluators. - Avoid special case for plugin types that support predefinition. - Get rid of need to list plugin types manually for get_help_templ. (This should also fix issue619.) Specific issues: - ~~issue481: avoid special case for open lists.~~ - ~~issue606: move the code to a directory~~ - ~~issue608: split code into more files~~ - issue626: introduce a namespace.
2016-01-09 11:32:17floriansetsummary: High-level goals: - Decouple the external interface from the implementation better. Perhaps reduce the external interface to a single #include. - Make the option parser code planner-independent. Some details: - Split the code into smaller parts with clearly defined responsibilities. - Reduce internal dependencies in option parser code. - Avoid special case for Heuristics and ScalarEvaluators. - Avoid special case for plugin types that support predefinition. - Get rid of need to list plugin types manually for get_help_templ. - Introduce a namespace. Specific issues: - ~~issue481: avoid special case for open lists.~~ - ~~issue606: move the code to a directory~~ - ~~issue608: split code into more files~~ -> High-level goals: - Decouple the external interface from the implementation better. Perhaps reduce the external interface to a single #include. - Make the option parser code planner-independent. Some details: - Split the code into smaller parts with clearly defined responsibilities. - Reduce internal dependencies in option parser code. - Avoid special case for Heuristics and ScalarEvaluators. - Avoid special case for plugin types that support predefinition. - Get rid of need to list plugin types manually for get_help_templ. (This should also fix issue619.) - Introduce a namespace. Specific issues: - ~~issue481: avoid special case for open lists.~~ - ~~issue606: move the code to a directory~~ - ~~issue608: split code into more files~~
2015-12-10 11:27:15floriansetfiles: + option-dependencies.png
messages: + msg4933
2015-12-09 02:38:21maltesetmessages: + msg4913
summary: - no longer list plugin types manually for get_help_templ. - avoid special case for Heuristics and ScalarEvaluators. - ~~issue481: avoid special case for open lists.~~ - avoid special case for plugin types that support predefinition. - ~~issue606: move the code to a directory~~ - decouple the external interface from the implementation better. - introduce a namespace - ~~issue608: split code into more files~~ -> High-level goals: - Decouple the external interface from the implementation better. Perhaps reduce the external interface to a single #include. - Make the option parser code planner-independent. Some details: - Split the code into smaller parts with clearly defined responsibilities. - Reduce internal dependencies in option parser code. - Avoid special case for Heuristics and ScalarEvaluators. - Avoid special case for plugin types that support predefinition. - Get rid of need to list plugin types manually for get_help_templ. - Introduce a namespace. Specific issues: - ~~issue481: avoid special case for open lists.~~ - ~~issue606: move the code to a directory~~ - ~~issue608: split code into more files~~
2015-12-09 02:35:03maltesetmessages: + msg4912
summary: - no longer list plugin types manually for get_help_templ. - avoid special case for Heuristics and ScalarEvaluators. - ~~issue481: avoid special case for open lists.~~ - avoid special case for plugin types that support predefinition. - ~~issue606: move the code to a directory~~ - decouple the external interface from the implementation better. - introduce a namespace - issue608: split code into more files -> - no longer list plugin types manually for get_help_templ. - avoid special case for Heuristics and ScalarEvaluators. - ~~issue481: avoid special case for open lists.~~ - avoid special case for plugin types that support predefinition. - ~~issue606: move the code to a directory~~ - decouple the external interface from the implementation better. - introduce a namespace - ~~issue608: split code into more files~~
2015-12-09 00:48:20maltesetmessages: + msg4910
summary: - no longer list plugin types manually for get_help_templ. - avoid special case for Heuristics and ScalarEvaluators. - ~~issue481: avoid special case for open lists.~~ - avoid special case for plugin types that support predefinition. - ~~issue606: move the code to a directory~~ - decouple the external interface from the implementation better. - introduce a namespace - split code into multiple files -> - no longer list plugin types manually for get_help_templ. - avoid special case for Heuristics and ScalarEvaluators. - ~~issue481: avoid special case for open lists.~~ - avoid special case for plugin types that support predefinition. - ~~issue606: move the code to a directory~~ - decouple the external interface from the implementation better. - introduce a namespace - issue608: split code into more files
2015-12-09 00:27:23maltesetmessages: + msg4907
summary: - no longer list plugin types manually for get_help_templ. - avoid special case for Heuristics and ScalarEvaluators. - issue481: avoid special case for open lists. - avoid special case for plugin types that support predefinition. - issue606: move the code to a directory and use a namespace. - decouple the external interface from the implementation better. -> - no longer list plugin types manually for get_help_templ. - avoid special case for Heuristics and ScalarEvaluators. - ~~issue481: avoid special case for open lists.~~ - avoid special case for plugin types that support predefinition. - ~~issue606: move the code to a directory~~ - decouple the external interface from the implementation better. - introduce a namespace - split code into multiple files
2015-12-08 16:44:38floriansetnosy: + florian
messages: + msg4902
summary: - no longer list plugin types manually for get_help_templ. - avoid special case for Heuristics and ScalarEvaluators. - issue481: avoid special case for open lists. - avoid special case for plugin types that support predefinition. - issue606: move the code to a directory and use a namespace. - decouple the external interface from the implementation better.
2015-10-31 18:56:39jendriksetnosy: + jendrik
2015-10-31 18:43:36maltecreate