← Back to team overview

dolfin team mailing list archive

Re: [noreply@xxxxxxxxxxxxx: [Branch ~dolfin-core/dolfin/main] Rev 5939: Minor change in adaptivity test - was failing to build. This might help . . . .]

 

On Fri, Jun 17, 2011 at 11:44:30PM -0700, Johan Hake wrote:
> On Friday June 17 2011 23:28:53 Anders Logg wrote:
> > On Fri, Jun 17, 2011 at 10:37:29PM -0700, Johan Hake wrote:
> > > On Thursday June 16 2011 14:15:46 Anders Logg wrote:
> > > > On Thu, Jun 16, 2011 at 09:48:02PM +0100, Garth N. Wells wrote:
> > > > > On 16/06/11 21:44, Johan Hake wrote:
> > > > > > Do you have a self cleaning /tmp directory ;) ?
> > > > > >
> > > > > > Could you try run it again, maybe after an instant-clean?
> > > > >
> > > > > I've done that a bunch of times.
> > > > >
> > > > > > We need a better way of reporting this kindoff errors. As the
> > > > > > output on a buildbot is not reachable either. For now I have
> > > > > > bugged Johannes to log into the buildbot and report the messages.
> > > > > > Maybe we can make instant print the content of the config.log on
> > > > > > error?
> > > > >
> > > > > It's usually *very* long since there are lots of SWIG-related
> > > > > warnings.
> > > >
> > > > Would it help if Instant in addition to storing the output to a file
> > > > with a long "random" name which is difficult to access also stored it
> > > > in a file with a predictable name, like "instant_error.log" in the
> > > > current directory, or in ~/.instant? Perhaps one can then link to that
> > > > file from the buildbot.
> > >
> > > Instant now copies any config.log to
> > > .instant/error/modulename/config.log. It would be cool if the file could
> > > be grabbed by the buldbot and displayed in the errorlog when something
> > > goes wrong.
> > >
> > > Not sure the name is predictive enough for the buildbot as modulename
> > > dependes on a hashsum...
> >
> > Can't we choose a common name that does not depend on the module name?
>
> Yeah, I first thought of this. But went with including the module as the path
> is printed to the user. Couldn't a smart server script grab the content of the
> latest folder added under .instant/error?
>
> > It might fail if two processes try to write at the same time, but only
> > if those processes *fail* at the same time. That's unlikely and if it
> > already fails, perhaps it's not a problem that on very rare occasions
> > the copying of the logfile fails.
>
> Not sure this will be a problem. Isn't the "only" thing that might happen is
> that one file gets overwritten by the other? But I still think including the
> hashed module name is cleaner.

My suggestion would be to do both (module-specific file + last known error).

--
Anders


Follow ups

References