OK, I have added the regexes to the parser, so this bug can be closed again.

I'm not sure if there is a clear answer to that. It is possible to declare
several landmark graphs (e.g. to be used for different heuristics in an
alternation search), but that's probably a rare use case. So usually only once,
but more than once is possible.

Are those values written only once (cumulative) or many times 
(iterative) in the output?

Thanks! Marking this one as resolved -- finally! :-)

Thanks a lot, Silvan!

Sure, I'll readd that parsing, you can discard Silvan's changes for now 
since there have been many changes in that file.

I merged Silvan's changes. There are two things I did not merge:

1) Changes to downward_configs.py:

These seemed to overlap significantly with changes in the default branch, and
there was a huge amount of differences between the two branches, so I think it
would be easier to just add back in whatever we need.

2) Changes to downward-resultfetcher.py:

Silvan added two lines there:

    eval.add_pattern('landmarks', r'Discovered (\d+) landmarks', type=int,
required=False)
    eval.add_pattern('landmark time', r'Landmarks generation time: (.+)s',
type=float, required=False)

which I would really like to have in the default branch, but I don't understand
Jendrik's new code in downward-resultfetcher.py well enough to integrate this.
Jendrik, can you help?

Erez's idea makes a lot of sense, but I agree with Silvia: refactor first, add
functionality later. Erez, maybe open a new issue for this idea so that it
doesn't get lost.

Hmm, we still need classes that generate the initial landmark graphs though.
I vote for the traditional approach, as Malte suggested, of having the
factories generate landmark graphs. We could possibly extend these factories
at a later stage to be chainable (by having them take as an optional
argument an existing landmark graph to build on). I would defer such
extensions though until we're done with putting the current landmark
functionality into the desired new structure.

I like this idea, but I have one small suggestion.
Instead of having these factories *generate* landmark graphs, have them *modify* 
landmark graphs.
So their signature would be:
bool LandmarkFactory::discover(LandmarkGraph &lm_graph)

and they would 
1. Utilize the information already present in the landmarks graph (for example, 
backchain from existing landmarks rather than just goals).
2. Add landmarks/orderings to the given graph

This would allow us to create a landmarks graph that is the combination of 
several landmark generation methods.

I suggest the method return whether it modified the graph or not, which would 
allow us to iteratively combine landmark generation methods until we reach a 
fixpoint.

Silvan and I discussed how to approach the refactoring, and we decided that the
first step should be to turn the existing LM generation methods that derive from
LandmarksGraph into factories that do not derive from LandmarksGraph but
*generate* landmark graphs.

In this process, we should hopefully be able to see which parts of the humungous
LandmarksGraph class are only necessary for discovery/construction and which
parts are necessary for maintenance/usage. These latter parts can then be
cleaned up later.

Renaming this issue so that it only refers to this first step of LM code
refactoring. Once we're done, we can add a new issue for the second step. (Or if
someone else wants to work on this concurrently, let us know.)

I removed the action landmark code. (I did this directly in the default branch
since Silvan owns the to-be-created issue139 branch.)

Silvia, Erez, as always feel free to un-nosy yourself it you don't want to
follow this.

Note: this is not urgent and should be dealt with post-1.0. In particular, we
should wait with this until we've properly assessed the recent changes to the LM
heuristc. I'm just writing this up now so that it doesn't get forgotten.

The landmark code could use some refactoring, and this issue is for keeping
track on what should be done.

I'll start with:

1. Get rid of the remaining traces of action landmark code since we don't use
   that any more.