[Simfactory] Automatically updating Cactus configuration options?
Steven R. Brandt
sbrandt at cct.lsu.edu
Thu Feb 24 08:32:01 CST 2011
It now seems that we have two issues where people have different
preferences. There is the automatic updating of cfg files, and there is
the automatic cleaning up of old simulations. At what point does it make
sense to have a ~/.simfactory.ini with these settings configurable?
Cheers,
Steve
On 02/24/2011 08:09 AM, Erik Schnetter wrote:
> It seems there is no clear consensus of what would be best for all of
> us. Let me rephrase the question then:
>
> What is the "best" behaviour for a "naive" user? This isn't
> necessarily what they would expect; it should rather be what and
> old-timer would recommend to a new student. Would you advise people to
> update the option list / script file etc. if a new one becomes
> available?
>
> Given that there is no consensus, SimFactory should offer both
> options, probably with a command line option to build [--autoupdate /
> --noautoupdate] for which people can set a default value in their
> defs.local.ini.
>
> Of course, the name "autoupdate" is not good since it doesn't say what
> is updated. Do you have better ideas?
>
> -erik
>
> On Thu, Feb 24, 2011 at 7:44 AM, Ian Hinder<ian.hinder at aei.mpg.de> wrote:
>> On 24 Feb 2011, at 13:31, Eloisa Bentivegna wrote:
>>
>>> On Feb 24, 2011, at 9:52 AM, Ian Hinder wrote:
>>>
>>>> Elo and Luca: do you often rebuild a configuration with new code and want the optionlists and submit scripts to stay the same? You have control over whether you update these scripts in simfactory when you update simfactory.
>>>> ...
>>>> One thing which I know for sure is that I have wasted a large amount of time due to forgetting to add the "--scriptfile" option to a build command when modifying the script file, and I have never felt that I needed configs' script files to stay the same when rebuilding.
>>> This really depends on how much low-level development one is doing. If I'm going through many coding-testing repetitions, I don't really want libs or compiler flags to change silently underneath.
>> OK - I see the point, but would you update simfactory in that case? Maybe you would, in order to get the updated version for a different configuration for an unrelated project.
>>
>>> Sure, there are other ways to ensure that in addition to the current simfactory mechanism -- but please, let's at least have a message when the options change.
>> Something like:
>>
>> Updating optionlist for configuration sim.
>>
>> much like the "Compiling XXX" you get when building.
>>
>> However, with all the other simfactory output, I suspect that this would be overlooked.
>>
>>> Or what about being prompted for the reconfig? Are simfactory files changing so frequently that this would turn into too much of an obstruction?
>> I think this might be the best option. If I build a configuration and the optionlists etc have changed, there could be a prompt:
>>
>> Optionlist changed: update in configuration? y/n
>>
>> and the same for the other files. But this would be annoying if you always *didn't* want them to be updated, since you would be prompted every time. So to avoid that, you would need an option --dont-update-config-files (with a better name) which you could add in the case that you didn't want them updated.
>>
>> In the end, I don' t know which is the better option.
>>
>> --
>> Ian Hinder
>> ian.hinder at aei.mpg.de
>>
>> _______________________________________________
>> SimFactory mailing list
>> SimFactory at cct.lsu.edu
>> https://mail.cct.lsu.edu/mailman/listinfo/simfactory
>>
>
>
More information about the SimFactory
mailing list