dolfin team mailing list archive

[Johannes Ring <johannr@xxxxxxxxx>]

On Wed, Jun 22, 2011 at 9:59 PM, Johan Hake <johan.hake@xxxxxxxxx> wrote:
> On Saturday June 18 2011 00:39:04 Anders Logg wrote:
>> 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).
>
> This is now the behaviour. Now Johannes need to map
>
>   .instant/error/config.log
>
> to a place one can examine it from the webinterface of the buildbot.

Instead of adding this file to the buildbot, I modified the test
scripts in DOLFIN to include the output from compile.log. One should
then be able to see why Instant fails by looking at the "stdio" output
or the demo.log on the buildbot.

Johannes