-
Notifications
You must be signed in to change notification settings - Fork 36
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Define API to set/get SCR params #40
Comments
@white238 , as the next task, I'd like to look at creating an API to set SCR parameters from within the code. I'd like to have one of our new SCR developers assist with that. Do you have an idea of different parameters you'd like to set to get started? |
Some of these params are used only in the scripts (like SCR_RUNS), some are only in the library (like SCR_SET_SIZE), and some are in both (like SCR_CACHE_BASE). The ones used in both must be consistent so that the scripts and the library see the same values. For the scripts, some portion of the scripts run before the library and some portion runs after the library. As a first task, we can list all params and where they must be valid. If a script needs a value, but the library runs first, we could have the library record its set of params in a file that the scripts can read after the library has run. If a script needs a value before the library runs, we probably should not allow the application to set that param via the API, since that would lead to inconsistent values. Most of the params, but probably not all, are listed here: |
I have a kind-of API implemented in https://github.com/rhaas80/scr/tree/rhaas/scr_param_set which does let you add parameters to be used by scr_get_params() (or any of the scr_param_get calls). This lets a code set all SCR parameters but right now, at least without some largish changes to SCR, will require that these calls are made before SCR_Init (since it calls scr_get_params()).
The current API follows: ECP-VeloC/AXL#38 ie there is a call
that basically takes a line of the configuration files. If there is an item in the string that does not have an equal sign then this is just a query and no value is set. |
@rhaas80 , I may not have time to review your code in detail, but your description here sounds good. @gonsie mentioned that you had your own parser logic in there. You could perhaps simplify things if you can use the existing functions that are used to parse the SCR config files instead. It would be nice for the end user to support the same syntax in both places if possible. https://github.com/rhaas80/scr/blob/ddfa45939b92ca3997b51153bba37f2b23c73cc3/src/scr_config.c#L265 I wouldn't worry about setting properties after SCR_Init. Perhaps return an error if someone tries to do that? For that matter, it could be nice to return an error in the case someone tries to set a parameter that can't be set using SCR_Config even before SCR_Init. For example, any parameter that has to be set before the user's job runs cannot be set with SCR_Config. Having said that, I think returning an error is a nice to have thing, rather than a need. We'll also want to document which parameters can be set when. We could create a table to show whether the parameter can be set: as an environment variable, in the user config file, the system config file, and SCR_Config. |
@adammoody thank you. I was certainly not expecting a full review. Mostly I had the code written to make sure I had an understanding of what needed changing and to be able to point to an explicit implementation. I had thought about trying to re-use the file parsing code, but in the end ended up written my own parser which should (untested, so likely untrue) parse the same set of configuration lines (minus comments and minus expanding environment variables I think). The main reason I decided that I could not use the existing function (easily) is because that function is tied to read from a file eg in the whitespace skipping code https://github.com/rhaas80/scr/blob/ddfa45939b92ca3997b51153bba37f2b23c73cc3/src/scr_config.c#L277 . There's also a difference in syntax because in the configuration files a line like
is invalid but is is a valid query for the configuration function. And finally I did not want to make the existing config file reader use a (modified) version of my parser since such a change almost always ends up causing changes in corner case behaviour that someone relied on. If indeed changing parameters after I will go ahead and collect information on which parameters can be set programmatically and will try and see what would be required to have a single function parse either lines from a configuration file or strings passed to the config functions. |
Parameters used by non-main code installed into bin:
Scripts only in scr but not installed on my workstation contain some more perl code,
Kathryn's grep list of parameters
Compile time:
What is not used in src:
|
@rhaas80 , how are things coming along on this work? I'm working several codes teams to update the SCR calls in their applications. It's a prime opportunity to add the new config API as part of that effort. |
Addressed in merge request #184 |
No description provided.
The text was updated successfully, but these errors were encountered: