← Back to team overview

ffc team mailing list archive

Re: buildbot failure in FEniCS Buildbot on ffc-hardy-i386

 

instant.build_module?
      - B{cache_dir}:
        - A directory to look for cached modules and place new ones.
          If missing, a default directory is used. Note that the module
          will not be cached if C{modulename} is specified.
          The cache directory should not be used for anything else.

the argument is "cache_dir". If this is unclear, look at how the
instant unit tests uses this.

--
Martin

On Fri, Feb 27, 2009 at 10:47 PM, Anders Logg <logg@xxxxxxxxx> wrote:
> What is the argument? And what does local mean? Current directory?
>
> --
> Anders
>
>
> On Fri, Feb 27, 2009 at 06:00:11PM +0100, Martin Sandve Alnæs wrote:
>> You should use a local cache-directory for the unit tests,
>> instant takes an argument for this. This will be separate
>> from the global cache and can be deleted in the unit
>> tests to make sure the caching works. The instant
>> unit tests do this.
>>
>> Martin
>>
>>
>>
>> On Fri, Feb 27, 2009 at 5:38 PM, Anders Logg <logg@xxxxxxxxx> wrote:
>> > On Fri, Feb 27, 2009 at 10:03:06AM +0100, Anders Logg wrote:
>> >> On Fri, Feb 27, 2009 at 09:45:49AM +0100, Kristian Oelgaard wrote:
>> >> > Quoting buildbot@xxxxxxxxxx:
>> >> >
>> >> > > The Buildbot has detected a new failure of ffc-hardy-i386 on FEniCS
>> >> > > Buildbot.
>> >> > > Full details are available at:
>> >> > >  http://fenics.org:8080/builders/ffc-hardy-i386/builds/42
>> >> > >
>> >> > > Buildbot URL: http://fenics.org:8080/
>> >> > >
>> >> > > Buildslave for this Build: hardy-i386
>> >> > >
>> >> > > Build Reason:
>> >> > > Build Source Stamp: HEAD
>> >> > > Blamelist:
>> >> > >
>> >> > > BUILD FAILED: failed ffc check
>> >> >
>> >> > The JIT unit test fails as I reported earlier when I do:
>> >> >
>> >> > instant-clean
>> >> > python test.py
>> >> >
>> >> > but if I run
>> >> > python test.py
>> >> >
>> >> > a second time the test is OK.
>> >> > Kristian
>> >
>> > The problem is that the first time a form is compiled, FFC will
>> > simplify the form and thus the signature will be different on the
>> > second call. I solved this by jit-compiling twice before timing.
>> >
>> > Don't know why it worked before when instant-clean has not been
>> > called. It should only affect the disk cache. There is probably a good
>> > explanation but I haven't bothered to figure it out. It will change
>> > with UFL anyway since the compiler will not be allowed to modify the
>> > forms.
>> >
>> >
>> > -----BEGIN PGP SIGNATURE-----
>> > Version: GnuPG v1.4.9 (GNU/Linux)
>> >
>> > iEYEARECAAYFAkmoFx0ACgkQTuwUCDsYZdFaMQCdHIJjxsZ3Slv/27a3S6N9OVkm
>> > WMwAn2jjIwsATLZNbiXG8oCEaIQuM+6h
>> > =zKjh
>> > -----END PGP SIGNATURE-----
>> >
>> > _______________________________________________
>> > FFC-dev mailing list
>> > FFC-dev@xxxxxxxxxx
>> > http://www.fenics.org/mailman/listinfo/ffc-dev
>> >
>> >
>> _______________________________________________
>> FFC-dev mailing list
>> FFC-dev@xxxxxxxxxx
>> http://www.fenics.org/mailman/listinfo/ffc-dev
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkmoX4MACgkQTuwUCDsYZdEC9ACgkSJYmLQC6gtxyxBgXgxdN+Ec
> f08An2bsPtk7DOg1X3l18u3WOdicOEp1
> =UleR
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> FFC-dev mailing list
> FFC-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/ffc-dev
>
>


References