[Dune] [Dune-Commit] dune-common r5537 - trunk/bin#

[Christian Engwer]

Hi Martin, and the rest,


> I never took any offense. The idea was just to point out that I think the 
> current technique is a very good compromise between a lot of work and nothing at 
>   all. By the way, I like the idea of storing the options used in the previous 
> run. But then, we cannot take the name of the resume file from the options file 
> anymore...
> 
> Personally, I'm very content with the current situation, so unless running 
> multiple dune-controls in parallel _and_ desiring a resume file at the same time 
> is an issue, I think nothing needs be done, here.

I must admit that I'm more content with being able to install dune
than with having multiple installations, as it will help in teaching
when you can provide the core modules installed on the machines and
the students just have to compile their own module.

Thus I had chose the current compromise.

Cheers
Christian

> 
> Cheers,
> 
> Martin
> 
> Christian Engwer wrote:
> > Hi Martin,
> > 
> >> of course, Christian is right that the file I used will not work for installed
> >> versions of Dune. However, I agree that a file in the home directory is
> >> problematic, too (and it was never fool-proof in the sense mentioned by
> >> Christian).
> > 
> > I didn't want to degrade your work with my comment.
> > 
> >> There are at least the following solutions to this problem:
> >>
> >> (a) do a correct implementation (that might take weeks with no extra gain)
> > 
> > No.
> > 
> >> (b) remove the feature again
> > 
> > Why? I is working with certain limitations.
> > 
> >> (c) leave it as it is
> > 
> > I think it is best to leave it as it is, perhaps combined with (d) and
> > with a little sanity check. We might perhaps keep the command and the
> > module-path in the file and then use this particular setup. This means
> > that you can not change the command or the set of modules when using --resume.
> > 
> > Anyway I don't really understand Svens problem. Sven, do you really
> > run dunecontrol something on the 1.2 modules, they fail, then you run
> > dunecontrol for the head branch and afterwards you want to resume the
> > 1.2 run?
> > 
> > Christian
> > 
> >> (d) let the user specify the file in his options (if none is given, we simply
> >> disable the resume feature).
> >>
> >> All I wanted was a fast and easy to use possibility to resume a failed
> >> dunecontrol run (because this frequently happens to me). That's why I would be
> >> content with solution (d). On the other hand, this is a bit harder to
> >> communicate to the "users".
> >>
> >> What are your opinions?
> >>
> >> Yours,
> >>
> >> Martin
> >>
> >>
> >> Christian Engwer wrote:
> >>> On Wed, Jun 10, 2009 at 01:12:38PM +0200, Sven Marnach wrote:
> >>>> Hi Christian,
> >>>>
> >>>> christi at dune-project.org schrieb am Di, 09. Jun 2009, um 22:55:49 +0200:
> >>>>> save RESUME file in home directory
> >>>> for me, this breaks things, because I have multiple DUNE trees
> >>>> (different versions) and they now all use the same resume file.  I
> >>>> often compile multiple trees in parallel and I would like to be able
> >>>> to resume either of them when things fail.
> >>>>
> >>>> Before this patch, the resume feature worked fine.  What is the
> >>>> rationale for this patch?
> >>> An installed DUNE can't write to `basename $0`.
> >>>
> >>> It was Martins proposal to have a resume feature and I told him that
> >>> it will be a lot of work implement it properly. I don't think we will
> >>> support your use pattern. You can still resume it, it is just that you
> >>> should not run an other one in between. But anyway the old version did
> >>> was not fool-proof, because it would still (and does still) allow you
> >>> to resume an old run with a different command. The proper way would be
> >>> to add stamp files for the different commands in the different
> >>> source/build directories.
> >>>
> >>> Christian
> >>>
> >>>
> >>> _______________________________________________
> >>> Dune mailing list
> >>> Dune at dune-project.org
> >>> http://lists.dune-project.org/mailman/listinfo/dune
>