Skip to content

Conversation

@duizendnegen
Copy link
Contributor

@duizendnegen duizendnegen commented Apr 8, 2017

Issue

Normalizing the usage & file names across config files by referring to a single config file.

Tasklist

  • contractor_config
  • updater_config
  • customizer_config
  • partition_config
  • extractor_config
  • review
  • adjust for comments
  • engine_config
  • transform to use GetPath

@duizendnegen
Copy link
Contributor Author

Currently pointed config files to use storage_config. This is slightly confusing as IsValid doesn't make sense now in all cases.

Alternatively we can create an io_config, either as a reference or as a parent class. Welcoming suggestions.

@TheMarex
Copy link
Member

What is the motivation for using StorageConfig in all modules? It is meant as the configuration for the storage component, what is the relation with the other modules?

@duizendnegen
Copy link
Contributor Author

duizendnegen commented Apr 11, 2017

No motivation - I misunderstood it at the start and then just got it to a working situation. I will replace that. What's your opinion of using io_config as a parent class (option A) or as a reference / variable (option B)?

@duizendnegen duizendnegen force-pushed the feature/config-normalization branch 2 times, most recently from 9502ca7 to 1416aea Compare April 18, 2017 08:55
@duizendnegen duizendnegen force-pushed the feature/config-normalization branch 7 times, most recently from b125b82 to c8a68e5 Compare April 24, 2017 21:00
@duizendnegen duizendnegen force-pushed the feature/config-normalization branch 9 times, most recently from f4449fb to 447b534 Compare April 29, 2017 12:46
@duizendnegen
Copy link
Contributor Author

Ready for review!

Copy link
Member

@daniel-j-h daniel-j-h left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do we guarantee wrt. our public headers? (cc @TheMarex) I can see some modifications in publicly exposed config headers - not sure if this is fine for compatibility.

@@ -0,0 +1,82 @@
#ifndef IO_CONFIG_HPP
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should probably be prefix with OSRM_

{
struct IOConfig
{
IOConfig() = default;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is the default constructor needed? A default constructed IOConfig can't do anything, no?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I would prefer to drop this as a constructor, but in practice it doesn't work:

return_code parseArguments(int argc, char *argv[], extractor::ExtractorConfig &extractor_config)
is how command line arguments are parsed, they require an instantiated version of the Config files. I started without that and without the UseDefaultOutputNames function, but I couldn't get it to work like that.

compressed_node_based_graph_path = {osrm_path.string() + ".cnbg"};
cnbg_ebg_mapping_path = {osrm_path.string() + ".cnbg_to_ebg"};
restriction_path = {osrm_path.string() + ".restrictions"};
intersection_class_data_path = {osrm_path.string() + ".icd"};
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm is there a way we can make it so that we get a warning if we forget to initialize a path below?

Should this e.g. all be done in the constructor, as in

struct io {
  io(path base)
    : a(base + '.a'),
      b(base + '.b') { }

  path a;
  path b;
};

?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See above - yes, should be the case, but didn't work out in practice.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok I see. Thanks for explaining! :)

@daniel-j-h
Copy link
Member

Also needs a rebase onto master before we can merge 🎄

@duizendnegen duizendnegen force-pushed the feature/config-normalization branch 3 times, most recently from 9c94502 to 80c30b4 Compare May 5, 2017 09:03
@duizendnegen
Copy link
Contributor Author

From IRC: Hey _1009 there's a small backwards incompatible change in your current IOConfig PR - https://github.com/Project-OSRM/osrm-backend/pull/3920/files#diff-9b0fcadd9f362547a7dd4f631c4ec3fcR33 breaks the API. What you can do is make it protected and call the function in all sub-class constructors.

@duizendnegen
Copy link
Contributor Author

Ping @daniel-j-h

// Configure based on a .osrm base path, and no datasets in shared mem from osrm-datastore
EngineConfig config;
config.storage_config = {argv[1]};
config.storage_config.UseDefaultOutputNames(argv[1]);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm user coder here needs to change this is still breaking the api

*v8::String::Utf8Value(Nan::To<v8::String>(args[0]).ToLocalChecked()));
std::string base_path(*v8::String::Utf8Value(args[0]->ToString()));
engine_config->storage_config = osrm::StorageConfig();
engine_config->storage_config.UseDefaultOutputNames(base_path);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here

osrm::StorageConfig(*v8::String::Utf8Value(Nan::To<v8::String>(path).ToLocalChecked()));
std::string base_path(*v8::String::Utf8Value(path->ToString()));
engine_config->storage_config = osrm::StorageConfig();
engine_config->storage_config.UseDefaultOutputNames(base_path);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And here

// Configure based on a .osrm base path, and no datasets in shared mem from osrm-datastore
EngineConfig config;
config.storage_config = {argv[1]};
config.storage_config.UseDefaultOutputNames(argv[1]);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And here

@daniel-j-h
Copy link
Member

Ah I've just seen you added a constructor calling UseDefaultOutputNames. Can you switch all the public code to using that and make the UseDefaultOutputNames protected so only sub-classes can call it.

@duizendnegen
Copy link
Contributor Author

But in previous versions most subclasses had UseDefaultOutputNames type of constructs, right...? This is why the initialisation from command line worked. Are you proposing making it protected (for storage_config) and public in customizer_config, extractor_config, ...?

@daniel-j-h
Copy link
Member

Yeah the user should not see the UseDefaultOutputNames function on the publicly exposed configs. And especially should not have to adapt her code to call this function.

@duizendnegen duizendnegen force-pushed the feature/config-normalization branch from 3224072 to c2dbf22 Compare July 14, 2017 05:50
@duizendnegen duizendnegen force-pushed the feature/config-normalization branch from c2dbf22 to 3c2c1a5 Compare July 14, 2017 08:57
@duizendnegen
Copy link
Contributor Author

Addressed comments (waiting for builds to pass, might have to do some clang-formatting, feel free to leave additional comments)

@daniel-j-h
Copy link
Member

Yep Travis complains about clang-formating include/storage/io_config.hpp - otherwise looks good!

@duizendnegen
Copy link
Contributor Author

👍 formatted the file, now waiting for 📗 🍏

@duizendnegen duizendnegen force-pushed the feature/config-normalization branch from 3c2c1a5 to 5c520e4 Compare July 15, 2017 08:55
@duizendnegen
Copy link
Contributor Author

One test seemed to have timed out, could you restart?

@daniel-j-h daniel-j-h merged commit 8da4041 into Project-OSRM:master Jul 20, 2017
@daniel-j-h
Copy link
Member

Thanks for this - it's making some I/O parts nicer for sure! I just merged it into master.

@duizendnegen duizendnegen deleted the feature/config-normalization branch July 20, 2017 18:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants