dolfin team mailing list archive

[Johannes Ring <johannr@xxxxxxxxx>]

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.

Johannes