On Fri, Jan 23, 2009 at 2:16 PM, Johan Hake <[email protected]> wrote: > On Friday 23 January 2009 14:02:31 [email protected] wrote: >> > On Fri, Jan 23, 2009 at 1:33 PM, <[email protected]> wrote: >> >>> On Fri, Jan 23, 2009 at 12:40:21PM +0100, Johan Hake wrote: >> >>>> On Friday 23 January 2009 12:15:51 Martin Sandve Alnæs wrote: >> >>>> > On Fri, Jan 23, 2009 at 12:00 PM, Johan Hake <[email protected]> wrote: >> >>>> > > On Friday 23 January 2009 11:54:50 Martin Sandve Alnæs wrote: >> >>>> > >> On Fri, Jan 23, 2009 at 11:48 AM, Johan Hake <[email protected]> >> >>>> >> >>>> wrote: >> >>>> > >> > On Friday 23 January 2009 11:27:31 Ola Skavhaug wrote: >> >>>> > >> >> On Fri, Jan 23, 2009 at 10:32 AM, Johan Hake <[email protected]> >> >>>> >> >>>> wrote: >> >>>> > >> >> > On Friday 23 January 2009 10:09:12 Martin Sandve Alnæs >> >>>> >> >>>> wrote: >> >>>> > >> >> > > On Fri, Jan 23, 2009 at 9:39 AM, Johannes Ring >> >>>> > >> >> > > <[email protected]> >> >>>> > >> >> > >> >>>> > >> >> > wrote: >> >>>> > >> >> > > > On Thu, January 22, 2009 19:10, Johan Hake wrote: >> >>>> > >> >> > > >> On Thursday 22 January 2009 17:02:41 A Navaei wrote: >> >>>> > >> >> > > >>> Johan, >> >>>> > >> >> > > >>> >> >>>> > >> >> > > >>> Thanks, instant-clean did the trick! Maybe this should >> >>>> >> >>>> be >> >>>> >> >>>> > >> >> > > >>> somehow automated. >> >>>> > >> >> > > >> >> >>>> > >> >> > > >> Yes, I have thought about it. >> >>>> > >> >> > > >> >> >>>> > >> >> > > >> Is it possible to add a call to instant-clean in the >> >>>> >> >>>> install >> >>>> >> >>>> > >> >> > > >> script of the ffc >> >>>> > >> >> > > >> and dolfin packages Johannes? >> >>>> > >> >> > > > >> >>>> > >> >> > > > Yes, it is possible to add post installation scripts to >> >>>> >> >>>> the FFC >> >>>> >> >>>> > >> >> > > > and DOLFIN packages (and perhaps Instant) that runs >> >>>> > >> >> > > > instant-clean. Should I add this? >> >>>> > >> >> > > > >> >>>> > >> >> > > > Johannes >> >>>> > >> >> > > >> >>>> > >> >> > > Can you add it to SyFi as well please? But we don't want >> >>>> >> >>>> this in >> >>>> >> >>>> > >> >> > > development versions though, we should at least have an >> >>>> >> >>>> option >> >>>> >> >>>> > >> >> > > to avoid it. >> >>>> > >> >> > >> >>>> > >> >> > I think it will be sufficient to add the automatic cleaning >> >>>> >> >>>> in >> >>>> the >> >>>> >> >>>> > >> >> > ubuntu scripts. >> >>>> > >> >> > >> >>>> > >> >> > I can add the swig version to the signature generation in >> >>>> >> >>>> ffc >> >>>> and >> >>>> >> >>>> > >> >> > dolfin. >> >>>> > >> >> > >> >>>> > >> >> > While on the topic, does instant check whether swig is >> >>>> >> >>>> installed, >> >>>> >> >>>> > >> >> > when a module is built? Also I have on several occasions now >> >>>> > >> >> > checked for the swig version. Should I put this code in >> >>>> >> >>>> instant, >> >>>> >> >>>> > >> >> > e.g. >> >>>> > >> >> > >> >>>> > >> >> > check_swig_version("1.3.35") >> >>>> > >> >> > >> >>>> > >> >> > It will return false if the current swig version is lesser >> >>>> >> >>>> than >> >>>> >> >>>> > >> >> > "1.3.35"? I think it would be natural for instant to provide >> >>>> >> >>>> such a >> >>>> >> >>>> > >> >> > function. >> >>>> > >> >> >> >>>> > >> >> There is a related problem that needs to be adressed here. If >> >>>> >> >>>> you >> >>>> >> >>>> > >> >> build an extension of a module wrapped with version x of swig, >> >>>> >> >>>> you >> >>>> >> >>>> > >> >> should require the same version of swig in instant. Perhaps >> >>>> >> >>>> the >> >>>> >> >>>> > >> >> check_swig_version("1.3.35") should only return true if you >> >>>> >> >>>> have >> >>>> >> >>>> > >> >> exactly that version. Another function, a-la >> >>>> > >> >> >> >>>> > >> >> assert_swig_min_version("1.3.35") >> >>>> > >> > >> >>>> > >> > This could probably be kept in one function. By default the >> >>>> >> >>>> function >> >>>> >> >>>> > >> > returns whether a version of swig is equal or greater than the >> >>>> > >> > prescribed version, and: >> >>>> > >> > >> >>>> > >> > check_swig_version("1.3.35", equal = True) >> >>>> > >> > >> >>>> > >> > will return true only if the version is the same as the >> >>>> >> >>>> prescribed >> >>>> >> >>>> > >> > one? >> >>>> > >> > >> >>>> > >> > The assertion functionality will then be handled by the >> >>>> >> >>>> function >> >>>> that >> >>>> >> >>>> > >> > use instant, i.e., ffc, sfc, dolfin compile_function a.s.o. >> >>>> > >> >> >>>> > >> But FFC isn't compiled with SWIG. Dolfin will have to do that, >> >>>> >> >>>> for >> >>>> >> >>>> > >> example at import time. >> >>>> > > >> >>>> > > No, but it produces code that is compiled with swig. And this code >> >>>> >> >>>> should >> >>>> >> >>>> > > be compiled with the same swig version that dolfin is compiled >> >>>> >> >>>> with. >> >>>> Then >> >>>> >> >>>> > > dolfin need to hand its swig version to ffc when it is using it so >> >>>> >> >>>> ffc >> >>>> >> >>>> > > can check which version is installed while swigging compiled >> >>>> >> >>>> forms. >> >>>> If >> >>>> >> >>>> > > this version is not the same as the handed version from dolfin -> >> >>>> >> >>>> raise >> >>>> >> >>>> > > error. >> >>>> > >> >>>> > In my opinion, >> >>>> > >> >>>> > dolfin gets its swig version >> >>>> > dolfin calls instant to check whether it's compatible with the >> >>>> >> >>>> current >> >>>> >> >>>> > swig >> >>>> > >> >>>> > is simpler than >> >>>> > >> >>>> > dolfin gets its swig version >> >>>> > dolfin passes its swig version to ffc >> >>>> > ffc calls instant to check whether it's compatible with the >> >>>> >> >>>> current >> >>>> swig >> >>>> >> >>>> > why pass the info to ffc at all? It would need to be handled in >> >>>> >> >>>> dolfin >> >>>> >> >>>> > for function compilation anyway. If dolfin checks that the current >> >>>> > swig is compatible with the version it was compiled with at import >> >>>> > time, it doesn't have to be checked anywhere else. With your model, >> >>>> > both DOLFIN, FFC and SFC would need to be modified. >> >>>> >> >>>> Sounds reasonable. Dolfin defines it own jit function and the check >> >>>> could be >> >>>> added here. >> >>>> >> >>>> We will still have the problem for older forms, which are allready in >> >>>> the >> >>>> cache and are compiled with an older swig. Putting the swig version in >> >>>> the >> >>>> signature would prevent this to happen though. >> >>>> >> >>>> Johan >> >>> >> >>> I think we should throw as much as possible into the signature, just >> >>> to make sure. DOLFIN passes some signature prefix to the form compiler >> >>> (which could be the DOLFIN version and the SWIG version), then the >> >>> form compiler adds whatever it feels to add to the signature (form >> >>> signature, form compiler name and form compiler version), then Instant >> >>> adds whatever it feels like adding. >> >>> >> >>> -- >> >>> Anders >> >> >> >> Ok, so Instant should add Swig version to the signature. Dolfin and the >> > >> > No, as Johan pointed out, Instant can't add to the signature. Instant >> > will either construct its own signature from the files and options it >> > gets, or use the provided signature as-is. So the form compilers >> > should add whatever they need to the signature. >> > >> > Martin >> >> But the form compilers / Dolfin do not know which SWIG version Instant >> will use >> (although this might not be a big issue since it is probably basically the >> same process >> that decides on which SWIG to use in both cases). > > The form compiler/dolfin can get the present swig version (instant can provide > a function swig_version()?), which will be used to compile a signature.
Exactly. >> Anyway, this is really independent of Dolfin and the compilers. What >> should Instant >> do eg. if SWIG has been updated since the last time it inlined the exact >> same code? > > I think Instant should just do what it is told to. Any checks need to be done > in the caller of instant. Exactly. And we can add the swig version if instant creates the signature itself. >> Should it just import the module or regenerate it? > > Then ffc/dolfin will provide a different signature and a new module will be > compiled. Exactly. Martin _______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
