This depends on the learning code that is no longer part of the master
repository. Closing this.

Let's talk before the next round of LM refactoring.
The multi-landmarks paper and another one I am working on already caused me to 
make some changes, and I've got ideas for even more.

Depending on how urgent this is, it might make sense to wait with this until the
next round of LM refactoring is done. I have some hopes that we can simplify
some of the data structures there. But that will mean significant changes, so
you probably don't want to spend a lot of time coding against the "old"
interface, Erez.

I have never touched these parts of the code so far, thus I really can't say
anything qualified about this problem, sorry.
I am still working on the landmarks (synergy issue/refactoring the whole
factories stuff) part, although this may change, depending on what Malte assigns me.

It is now possible to do this in a prettier way than before: create parsers for 
feature extractors and for classifiers (where a classifier takes a feature 
extractor, and the lm_feature_extractor takes a landmark graph).

However, to implement this cleanly (without depending on the 
lm_count_heuristic), we would need to have a lm_status_manager for the feature 
extractor, which would be a rather large increase in memory overhead, as well as 
cause some difficulties with updating the lm_status_manager with the state space 
structure via  reach_state).

I'm nosy-ing Silvan to see if he has any ideas.

Currently landmark feature extractor is disabled. We need to come up with a nice 
way of adding it back. The problem is it depends on both landmarks and learning, 
so the plugin mechanism is a bit problematic.