dolfin team mailing list archive

[Johan Hake <johan.hake@xxxxxxxxx>]

On Tuesday November 1 2011 11:02:39 Johannes Ring wrote:
> On Tue, Nov 1, 2011 at 5:44 PM, Johan Hake <johan.hake@xxxxxxxxx> wrote:
> > On Monday October 31 2011 23:46:46 Johannes Ring wrote:
> >> On Tue, Nov 1, 2011 at 6:06 AM, Johan Hake <johan.hake@xxxxxxxxx> wrote:
> >> > Is one of:
> >> > 
> >> >  flufl.lock, fcntl
> >> > 
> >> > installed on the buildbots? If looks like the file locking mechanism
> >> > is not working on there.
> >> 
> >> fcntl is available on all the buildbots.
> > 
> > I figured this was the case the moment I sent the email. The error
> > message at the buildbot was presented just before the parallel runs,
> > which made me suspicius of the failing had something to do with runs in
> > parallel. So never mind...
> > 
> >> Should I try to install
> >> flufl.lock on this buildbot?
> > 
> > That is probably not worth it as flufl.lock is only needed on clusters
> > which need file lock over nfs.
> 
> Ok.
> 
> > All this said there is a unit test (Expression), which tends to fail
> > sometimes on the linux64-exp. This is just terribly annoying. That it
> > also triggers some logic bug in instant where a file which does not
> > excist is copied doesn't make it better...
> > 
> > Looking just a bit more into it, it looks like it is Expressions (note
> > the last 's'), which fails. I suggest we remove this function, as it
> > introduces complex logics (compressing several Expressions into one
> > instant call), on top of something that is already complex (JIT
> > compilations of a single Expression). It is also not mentioned in the
> > book. I have checked.
> > 
> > Then I suggest we reconsider the copying of compile.log file to
> > ~/.instant/error, as it is not working as intented. Not sure what we
> > should do, but maybe we could set an environment variable
> > 
> >  INSTANT_DISPLAY_COMPILE_LOG
> > 
> > on the buildbot, and if that is set we print the content of compile.log.
> > I can then set the copying of files within a try clause and silently
> > ignore the exception. Not pretty but we can issue a warning that the
> > file does not excist.
> 
> Sounds good to me.

Ok done.

Now you should be able to define INSTANT_DISPLAY_COMPILE_LOG on the buildbots 
and we will get all gory details from the _correct_ compile.log when a JIT 
compilation fails.

Johan