On Thu, 2006-10-12 at 02:40 +1000, Edward d'Auvergne wrote:
Now that I can see the errors of my ways (or thinking), and that the
idea is implemented at the level of the user functions themselves, the
concept is quite good. Essentially the run loop switches between the
pipes executing the actual user function on each - that is a good
idea! That does add an extra level of optional flexibility to relax.
Thanks for clearing that up.
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
Your idea Chris should definitely be part of the changes. It would be
extremely simple to implement too (once the pipe concept has been
implemented). I hope I didn't offend you by misunderstanding your
proposal.
No offence taken at all.
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.
Edward
Chris
Re: Redesign of the relax data model: 2. A new run concept