> This should be implemented at the level of the user functions as it
> would be messy implementing it at the next level (the individual
> functions of the 'generic_fns', 'specific_fns', and 'dx' directories).
> The 'runs' argument (or possibly 'pipes' argument) would then only
> exist for a very short time in the code of the 'prompt' directory. I
> would suggest that the run loop be placed in the file
> 'generic_fns/runs.py'. If the full proposal is accepted, this will be
> renamed to 'generic_fns/pipes.py' and the function hence called
> 'pipe_loop'.
I agree. It is important for the logic of the proposal that it lies at
the highest level of code. Moreover as you point out, other interfaces
(GUI, eg) could use a very different mechanism for achieving multi-run
operations, so the code shouldn't be somewhere where it might get in the
way of that. Thus run_loop should be called from the user functions at
the prompt level
Each UI could call the run_loop function as necessary.
> Oh, I have one simple question. Do you think that the
> current pipe should be included in the pipe loop, even if it isn't
> passed in as an argument?
I would have thought not - this way of working expects the user to be
explicit about what runs they want to opperate on, so we should do
exactly what the user says and no more. That said I don't think it
matters too much so long as the behaviour is correctly and clearly
documented.
This can be explained in the 'Keyword Arguments' section. It makes
more sense that only those on the list should be processed.
Edward
Re: Redesign of the relax data model: 2. A new run concept