Try again with https://bitbucket.org/nschloe/fiat/commits/76786e404db13db5b5ac611eb16aad3395b3974f?at=master.
--Nico On Fri, Jul 25, 2014 at 10:34 AM, Aslak Bergersen <[email protected]> wrote: > Well, it passes for the 1D tests, but it fails for all 2D tests and most of > the 3D tests. I get > > ``` > IndexError: tuple index out of range > ``` > > Both the tests in fiat and ffc fails. > > Aslak > > > 2014-07-24 23:53 GMT+02:00 Nico Schlömer <[email protected]>: > >> I just pushed >> >> >> https://bitbucket.org/nschloe/fiat/commits/4e8dab41de10545d671921a722199e78d25a878e >> >> which should hopefully do the trick. Aslak, can you try it out? >> >> --Nico >> >> On Thu, Jul 24, 2014 at 8:40 PM, Aslak Bergersen >> <[email protected]> wrote: >> > No, it's: >> > >> > FIAT tests: >> > 1D 2D 3D >> > FIAT master pass pass pass >> > [2] fail pass pass >> > >> > FFC tests: >> > 1D 2D 3D >> > FIAT master pass pass pass >> > [2] fail pass pass >> > >> > Note that this with [5] and python 2, but I don't think that matters. >> > The >> > result is the same for python 3 and [6]. And that the 1D FIAT test is >> > the >> > one that I implemented. >> > >> > [5] >> > >> > https://bitbucket.org/aslakbergersen/ffc/branch/aslakbergersen/topic-prepare-py3 >> > [6] https://bitbucket.org/fenics/ffc/ >> > >> > Den torsdag 24. juli 2014 skrev Nico Schlömer <[email protected]> >> > følgende: >> >> >> >> > By SP-removal branch you mean [4]? >> >> >> >> >> >> No sorry, [4] is a misnomer and should have been removed (which I did >> >> just now). [1]/[2] is the actual SP-removal branch. >> >> Could you run the FFC and FIAT tests on [2] again? If I understand >> >> correctly, the outcome i: >> >> >> >> FIAT tests: >> >> 1D 2D 3D >> >> FIAT master pass pass pass >> >> [2] fail pass pass >> >> >> >> FFC tests: >> >> 1D 2D 3D >> >> FIAT master pass pass pass >> >> [2] fail fail fail >> >> >> >> Correct? >> >> >> >> --Nico >> >> >> >> [1] https://bitbucket.org/nschloe/fiat/branch/improve-tests >> >> [2] >> >> >> >> https://bitbucket.org/aslakbergersen/fiat/branch/aslakbergersen/topic-prepare-py3 >> >> [4] https://bitbucket.org/nschloe/fiat/branch/replace-scientific-python >> >> >> >> >> >> >> >> On Thu, Jul 24, 2014 at 8:12 PM, Aslak Bergersen >> >> <[email protected]> wrote: >> >> > By SP-removal branch you mean [4]? >> >> > >> >> > I run ffc with [4] and it passes for 1D and 3D but not 2D. >> >> > The test that I implemented in FIAT is not possible to run. >> >> > >> >> > If you mean [1] by SP-removal, then yes the test that I just >> >> > implemented >> >> > in >> >> > FIAT gives the same error as the tests in ffc and passes for the >> >> > fenics/master branch. >> >> > >> >> > >> >> > [4] >> >> > https://bitbucket.org/nschloe/fiat/branch/replace-scientific-python >> >> > >> >> > >> >> > 2014-07-24 19:45 GMT+02:00 Nico Schlömer <[email protected]>: >> >> > >> >> >> Okay, then this is a problem. Do you know if your 1D test captures a >> >> >> difference in behavior between FIAT master and the SP-removal >> >> >> branch? >> >> >> >> >> >> --Nico >> >> >> >> >> >> On Thu, Jul 24, 2014 at 7:31 PM, Aslak Bergersen >> >> >> <[email protected]> wrote: >> >> >> > No, for [3] all tests passes in ffc. >> >> >> > >> >> >> > >> >> >> > [3] https://bitbucket.org/fenics-project/fiat >> >> >> > >> >> >> > >> >> >> > 2014-07-24 19:28 GMT+02:00 Nico Schlömer >> >> >> > <[email protected]>: >> >> >> > >> >> >> >> Do those tests fail with the latest FIAT master, too? >> >> >> >> >> >> >> >> --Nico >> >> >> >> >> >> >> >> On Thu, Jul 24, 2014 at 7:27 PM, Aslak Bergersen >> >> >> >> <[email protected]> wrote: >> >> >> >> > If you run ffc with this version of fiat then all 1D tests >> >> >> >> > fails >> >> >> >> > with >> >> >> >> > both >> >> >> >> > python 2 and python 3. Isn't that a problem that >> >> >> >> > needs to be addressed now? Try running the following (got this >> >> >> >> > from >> >> >> >> > Martin): >> >> >> >> > >> >> >> >> > $ more test.ufl >> >> >> >> > element = FiniteElement("Lagrange", interval, 1) >> >> >> >> > >> >> >> >> > ffc --verbose test.ufl >> >> >> >> > >> >> >> >> > Aslak >> >> >> >> > >> >> >> >> > >> >> >> >> > 2014-07-24 19:14 GMT+02:00 Nico Schlömer >> >> >> >> > <[email protected]>: >> >> >> >> > >> >> >> >> >> Okay, so the issue seems to be that the API for 1D differs >> >> >> >> >> from >> >> >> >> >> 2D >> >> >> >> >> and >> >> >> >> >> 3D. Consequently, the test needs to look differently, too. >> >> >> >> >> >> >> >> >> >> The 1D `tabulate_derivatives()` says: >> >> >> >> >> """Returns a tuple of length one (A,) such that >> >> >> >> >> A[i,j] = D phi_i(pts[j]). The tuple is returned for >> >> >> >> >> compatibility with the interfaces of the triangle and >> >> >> >> >> tetrahedron expansions.""" >> >> >> >> >> >> >> >> >> >> 2D and 3D say: >> >> >> >> >> # Put data in the required data structure, i.e., >> >> >> >> >> # k-tuples which contain the value, and the k-1 >> >> >> >> >> derivatives >> >> >> >> >> # (gradient, Hessian, ...) >> >> >> >> >> >> >> >> >> >> This should probably be aligned, but the API will break. I >> >> >> >> >> would >> >> >> >> >> say >> >> >> >> >> that this needs to be addressed at some point, but the removal >> >> >> >> >> of >> >> >> >> >> ScientificPython/Python3 operability is a different issue. For >> >> >> >> >> now, >> >> >> >> >> you could just adjust the test for 1D. >> >> >> >> >> >> >> >> >> >> Cheers, >> >> >> >> >> Nico >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Thu, Jul 24, 2014 at 6:06 PM, Aslak Bergersen >> >> >> >> >> <[email protected]> wrote: >> >> >> >> >> > I have added a test for 1D now, you can see it in [2]. >> >> >> >> >> > >> >> >> >> >> > Yes, I was talking about [1]. >> >> >> >> >> > >> >> >> >> >> > Aslak >> >> >> >> >> > >> >> >> >> >> > [2] >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > https://bitbucket.org/aslakbergersen/fiat/branch/aslakbergersen/topic-prepare-py3 >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > 2014-07-24 17:31 GMT+02:00 Nico Schlömer >> >> >> >> >> > <[email protected]>: >> >> >> >> >> > >> >> >> >> >> >> > The code is a little opaque and the returned data >> >> >> >> >> >> > structure >> >> >> >> >> >> > is >> >> >> >> >> >> > a >> >> >> >> >> >> > mix >> >> >> >> >> >> > of >> >> >> >> >> >> > lists and tuples and >> >> >> >> >> >> > numpy arrays that differ between 2D and 1D and is not >> >> >> >> >> >> > documented >> >> >> >> >> >> > well. >> >> >> >> >> >> >> >> >> >> >> >> Indeed! When I dived into the code it was hard to figure >> >> >> >> >> >> out >> >> >> >> >> >> what >> >> >> >> >> >> data >> >> >> >> >> >> structure is needed since everything seems quite convoluted >> >> >> >> >> >> at >> >> >> >> >> >> first. >> >> >> >> >> >> Cleanup and documentation is needed here. >> >> >> >> >> >> >> >> >> >> >> >> --Nico >> >> >> >> >> >> >> >> >> >> >> >> On Wed, Jul 23, 2014 at 3:28 PM, Martin Sandve Alnæs >> >> >> >> >> >> <[email protected]> >> >> >> >> >> >> wrote: >> >> >> >> >> >> > Note: This is about 1D elements, not linear. >> >> >> >> >> >> > >> >> >> >> >> >> > Aslak, can you link to the bitbucket branch where you've >> >> >> >> >> >> > fixed >> >> >> >> >> >> > some >> >> >> >> >> >> > of >> >> >> >> >> >> > the >> >> >> >> >> >> > other issues with Nicos branch, so others can download it >> >> >> >> >> >> > and >> >> >> >> >> >> > get >> >> >> >> >> >> > to >> >> >> >> >> >> > the >> >> >> >> >> >> > issue? >> >> >> >> >> >> > >> >> >> >> >> >> > Basically the tabulate_derivative method doesn't return a >> >> >> >> >> >> > data >> >> >> >> >> >> > structure >> >> >> >> >> >> > in >> >> >> >> >> >> > the right format so indexing errors occur. The code is a >> >> >> >> >> >> > little >> >> >> >> >> >> > opaque >> >> >> >> >> >> > and >> >> >> >> >> >> > the returned data structure is a mix of lists and tuples >> >> >> >> >> >> > and >> >> >> >> >> >> > numpy >> >> >> >> >> >> > arrays >> >> >> >> >> >> > that differ between 2D and 1D and is not documented well. >> >> >> >> >> >> > >> >> >> >> >> >> > Martin >> >> >> >> >> >> > >> >> >> >> >> >> > >> >> >> >> >> >> > >> >> >> >> >> >> > On 23 July 2014 13:59, Aslak Bergersen >> >> >> >> >> >> > <[email protected]> >> >> >> >> >> >> > wrote: >> >> >> >> >> >> >> >> >> >> >> >> >> >> Hi! >> >> >> >> >> >> >> >> >> >> >> >> >> >> I found an error in your implementation in fiat, Nico. >> >> >> >> >> >> >> And >> >> >> >> >> >> >> I'm >> >> >> >> >> >> >> having >> >> >> >> >> >> >> some >> >> >> >> >> >> >> trouble removing it. It is an error for all linear >> >> >> >> >> >> >> elements >> >> >> >> >> >> >> (which >> >> >> >> >> >> >> is >> >> >> >> >> >> >> not >> >> >> >> >> >> >> tested by fiat), and can be easy be reconstructed by >> >> >> >> >> >> >> running >> >> >> >> >> >> >> >> >> >> >> >> >> >> element = FiniteElement("Lagrange", interval, 1) >> >> >> >> >> >> >> >> >> >> >> >> >> >> The problem seems to be that tabulate_derivative in >> >> >> >> >> >> >> LineExpansionSet >> >> >> >> >> >> >> is >> >> >> >> >> >> >> not changed to return the same as tabulate_derivative in >> >> >> >> >> >> >> TriangleExpansionSet and TetrahedronExpansionSet. Is >> >> >> >> >> >> >> there >> >> >> >> >> >> >> an >> >> >> >> >> >> >> easy >> >> >> >> >> >> >> fix >> >> >> >> >> >> >> for >> >> >> >> >> >> >> this? >> >> >> >> >> >> >> >> >> >> >> >> >> >> Aslak >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> 2014-06-29 22:31 GMT+02:00 Nico Schlömer >> >> >> >> >> >> >> <[email protected]>: >> >> >> >> >> >> >> >> >> >> >> >> >> >>> > Changing idioms >> >> >> >> >> >> >>> > 2py3 changes idioms that are "outdated". When running >> >> >> >> >> >> >>> > the >> >> >> >> >> >> >>> > script >> >> >> >> >> >> >>> > it >> >> >> >> >> >> >>> > changes >> >> >> >> >> >> >>> > type(t) != type(q) to not isinstance(t, type(q)). Is >> >> >> >> >> >> >>> > this >> >> >> >> >> >> >>> > this >> >> >> >> >> >> >>> > something I >> >> >> >> >> >> >>> > should do? >> >> >> >> >> >> >>> > >> >> >> >> >> >> >>> > Python syntax >> >> >> >> >> >> >>> > The 2to3 scripts have the possibility to change the >> >> >> >> >> >> >>> > comma-syntax >> >> >> >> >> >> >>> > to >> >> >> >> >> >> >>> > correct >> >> >> >> >> >> >>> > python syntax. For example, it changes (a,b) to (a, >> >> >> >> >> >> >>> > b). >> >> >> >> >> >> >>> > Should >> >> >> >> >> >> >>> > I >> >> >> >> >> >> >>> > run >> >> >> >> >> >> >>> > this on >> >> >> >> >> >> >>> > the files as well? >> >> >> >> >> >> >>> >> >> >> >> >> >> >>> Those are things that Python2 linters like >> >> >> >> >> >> >>> >> >> >> >> >> >> >>> pep8 >> >> >> >> >> >> >>> pyflakes >> >> >> >> >> >> >>> flake8 >> >> >> >> >> >> >>> >> >> >> >> >> >> >>> usually bring up too. I would say that getting FEniCS >> >> >> >> >> >> >>> clean >> >> >> >> >> >> >>> w.r.t. >> >> >> >> >> >> >>> to >> >> >> >> >> >> >>> those three (largely overlapping) improves the code >> >> >> >> >> >> >>> readability >> >> >> >> >> >> >>> and >> >> >> >> >> >> >>> quality. >> >> >> >> >> >> >>> >> >> >> >> >> >> >>> Cheers, >> >> >> >> >> >> >>> Nico >> >> >> >> >> >> >>> >> >> >> >> >> >> >>> >> >> >> >> >> >> >>> On Fri, Jun 27, 2014 at 9:21 AM, Aslak Bergersen >> >> >> >> >> >> >>> <[email protected]> wrote: >> >> >> >> >> >> >>> > Hi! >> >> >> >> >> >> >>> > >> >> >> >> >> >> >>> > I have some questions about the supporting to python >> >> >> >> >> >> >>> > 3.x. >> >> >> >> >> >> >>> > You >> >> >> >> >> >> >>> > can >> >> >> >> >> >> >>> > take >> >> >> >> >> >> >>> > a >> >> >> >> >> >> >>> > look at the changes I have done if you want (or >> >> >> >> >> >> >>> > need). >> >> >> >> >> >> >>> > >> >> >> >> >> >> >>> > Testing with python 3.3 >> >> >> >> >> >> >>> > I have installed python 3.3 such that I can use it >> >> >> >> >> >> >>> > when >> >> >> >> >> >> >>> > I >> >> >> >> >> >> >>> > want >> >> >> >> >> >> >>> > (e.g. >> >> >> >> >> >> >>> > py3 >> >> >> >> >> >> >>> > script.py). However, when I'm running the tests all >> >> >> >> >> >> >>> > the >> >> >> >> >> >> >>> > dependencies >> >> >> >> >> >> >>> > are >> >> >> >> >> >> >>> > missing (For now I'm running python -3). So how do I >> >> >> >> >> >> >>> > build >> >> >> >> >> >> >>> > it >> >> >> >> >> >> >>> > with >> >> >> >> >> >> >>> > python 3? >> >> >> >> >> >> >>> > >> >> >> >> >> >> >>> > Support python 3.1 >> >> >> >> >> >> >>> > callable() returned in python 3.2, so there is no >> >> >> >> >> >> >>> > need >> >> >> >> >> >> >>> > to >> >> >> >> >> >> >>> > change >> >> >> >> >> >> >>> > it, >> >> >> >> >> >> >>> > unless >> >> >> >> >> >> >>> > we want to support python 3.1? >> >> >> >> >> >> >>> > >> >> >> >> >> >> >>> > Changing idioms >> >> >> >> >> >> >>> > 2py3 changes idioms that are "outdated". When running >> >> >> >> >> >> >>> > the >> >> >> >> >> >> >>> > script >> >> >> >> >> >> >>> > it >> >> >> >> >> >> >>> > changes >> >> >> >> >> >> >>> > type(t) != type(q) to not isinstance(t, type(q)). Is >> >> >> >> >> >> >>> > this >> >> >> >> >> >> >>> > this >> >> >> >> >> >> >>> > something I >> >> >> >> >> >> >>> > should do? >> >> >> >> >> >> >>> > >> >> >> >> >> >> >>> > Python syntax >> >> >> >> >> >> >>> > The 2to3 scripts have the possibility to change the >> >> >> >> >> >> >>> > comma-syntax >> >> >> >> >> >> >>> > to >> >> >> >> >> >> >>> > correct >> >> >> >> >> >> >>> > python syntax. For example, it changes (a,b) to (a, >> >> >> >> >> >> >>> > b). >> >> >> >> >> >> >>> > Should >> >> >> >> >> >> >>> > I >> >> >> >> >> >> >>> > run >> >> >> >> >> >> >>> > this on >> >> >> >> >> >> >>> > the files as well? >> >> >> >> >> >> >>> > >> >> >> >> >> >> >>> > Six module >> >> >> >> >> >> >>> > I have used the six modules to make it compatible >> >> >> >> >> >> >>> > with >> >> >> >> >> >> >>> > 2.x >> >> >> >> >> >> >>> > and >> >> >> >> >> >> >>> > 3.x, >> >> >> >> >> >> >>> > but >> >> >> >> >> >> >>> > I'm >> >> >> >> >> >> >>> > a bit unsure where to put it, or how to properly >> >> >> >> >> >> >>> > include >> >> >> >> >> >> >>> > it >> >> >> >> >> >> >>> > to >> >> >> >> >> >> >>> > the >> >> >> >> >> >> >>> > project >> >> >> >> >> >> >>> > such that all files have access. >> >> >> >> >> >> >>> > >> >> >> >> >> >> >>> > -- >> >> >> >> >> >> >>> > Mvh >> >> >> >> >> >> >>> > Aslak Bergersen >> >> >> >> >> >> >>> > 993 22 848 >> >> >> >> >> >> >>> > >> >> >> >> >> >> >>> > >> >> >> >> >> >> >>> > 2014-05-23 12:56 GMT+02:00 Martin Sandve Alnæs >> >> >> >> >> >> >>> > <[email protected]>: >> >> >> >> >> >> >>> > >> >> >> >> >> >> >>> >> UFL doesn't use __metaclass__ but it uses __new__, >> >> >> >> >> >> >>> >> is >> >> >> >> >> >> >>> >> the >> >> >> >> >> >> >>> >> behaviour >> >> >> >> >> >> >>> >> of >> >> >> >> >> >> >>> >> that the same? I'd like to clean up those parts at >> >> >> >> >> >> >>> >> some >> >> >> >> >> >> >>> >> point >> >> >> >> >> >> >>> >> but I >> >> >> >> >> >> >>> >> won't >> >> >> >> >> >> >>> >> have time before the summer. >> >> >> >> >> >> >>> >> >> >> >> >> >> >> >>> >> If we have to change behaviour of Expression we >> >> >> >> >> >> >>> >> should >> >> >> >> >> >> >>> >> consider >> >> >> >> >> >> >>> >> doing >> >> >> >> >> >> >>> >> that >> >> >> >> >> >> >>> >> simultaneously with the introduction of an >> >> >> >> >> >> >>> >> Expression-like >> >> >> >> >> >> >>> >> ufl >> >> >> >> >> >> >>> >> type >> >> >> >> >> >> >>> >> which >> >> >> >> >> >> >>> >> will have several advantages. >> >> >> >> >> >> >>> >> >> >> >> >> >> >> >>> >> Martin >> >> >> >> >> >> >>> >> >> >> >> >> >> >> >>> >> >> >> >> >> >> >> >>> >> On 23 May 2014 12:24, Johan Hake >> >> >> >> >> >> >>> >> <[email protected]> >> >> >> >> >> >> >>> >> wrote: >> >> >> >> >> >> >>> >>> >> >> >> >> >> >> >>> >>> And then there is the change of syntax for >> >> >> >> >> >> >>> >>> metaclasses >> >> >> >> >> >> >>> >>> in >> >> >> >> >> >> >>> >>> Python3... >> >> >> >> >> >> >>> >>> Just >> >> >> >> >> >> >>> >>> goggle metaclass python 3 and there are several >> >> >> >> >> >> >>> >>> pointers >> >> >> >> >> >> >>> >>> to >> >> >> >> >> >> >>> >>> the >> >> >> >> >> >> >>> >>> different >> >> >> >> >> >> >>> >>> syntax. >> >> >> >> >> >> >>> >>> >> >> >> >> >> >> >>> >>> Maybe this will be a good point to throw out the >> >> >> >> >> >> >>> >>> usage >> >> >> >> >> >> >>> >>> of >> >> >> >> >> >> >>> >>> metaclasses >> >> >> >> >> >> >>> >>> in >> >> >> >> >> >> >>> >>> DOLFIN? What we need is to add a distinction >> >> >> >> >> >> >>> >>> between >> >> >> >> >> >> >>> >>> CompiledExpression and >> >> >> >> >> >> >>> >>> Expression. I have tried this before with no luck >> >> >> >> >> >> >>> >>> ;) >> >> >> >> >> >> >>> >>> >> >> >> >> >> >> >>> >>> Johan >> >> >> >> >> >> >>> >>> >> >> >> >> >> >> >>> >>> >> >> >> >> >> >> >>> >>> On Thu, May 22, 2014 at 11:40 AM, Martin Sandve >> >> >> >> >> >> >>> >>> Alnæs >> >> >> >> >> >> >>> >>> <[email protected]> wrote: >> >> >> >> >> >> >>> >>>> >> >> >> >> >> >> >>> >>>> Yes, and if we're lucky we can get to that point >> >> >> >> >> >> >>> >>>> without >> >> >> >> >> >> >>> >>>> as >> >> >> >> >> >> >>> >>>> much >> >> >> >> >> >> >>> >>>> work as >> >> >> >> >> >> >>> >>>> sympy, since we don't have as much code. >> >> >> >> >> >> >>> >>>> >> >> >> >> >> >> >>> >>>> The 2to3 tool can do selective changes like change >> >> >> >> >> >> >>> >>>> print >> >> >> >> >> >> >>> >>>> "" >> >> >> >> >> >> >>> >>>> to >> >> >> >> >> >> >>> >>>> print("") >> >> >> >> >> >> >>> >>>> and fix exception syntax, which are compatible >> >> >> >> >> >> >>> >>>> with >> >> >> >> >> >> >>> >>>> 2.7. >> >> >> >> >> >> >>> >>>> >> >> >> >> >> >> >>> >>>> It can also do things like change "a = >> >> >> >> >> >> >>> >>>> dict.iteritems()" >> >> >> >> >> >> >>> >>>> into >> >> >> >> >> >> >>> >>>> "a >> >> >> >> >> >> >>> >>>> = >> >> >> >> >> >> >>> >>>> dict.items()" which changes the memory usage when >> >> >> >> >> >> >>> >>>> run >> >> >> >> >> >> >>> >>>> on >> >> >> >> >> >> >>> >>>> 2.7. >> >> >> >> >> >> >>> >>>> These >> >> >> >> >> >> >>> >>>> differences can instead be resolved by using the >> >> >> >> >> >> >>> >>>> python >> >> >> >> >> >> >>> >>>> module >> >> >> >> >> >> >>> >>>> "six" >> >> >> >> >> >> >>> >>>> which >> >> >> >> >> >> >>> >>>> implements cross-compatible helper functions for a >> >> >> >> >> >> >>> >>>> lot >> >> >> >> >> >> >>> >>>> of >> >> >> >> >> >> >>> >>>> things. >> >> >> >> >> >> >>> >>>> >> >> >> >> >> >> >>> >>>> Btw when we switch we should go straight to python >> >> >> >> >> >> >>> >>>> 3.3-3.4. >> >> >> >> >> >> >>> >>>> Supporting 3.0-3.2 side by side with 2.7 is >> >> >> >> >> >> >>> >>>> apparently >> >> >> >> >> >> >>> >>>> harder. >> >> >> >> >> >> >>> >>>> >> >> >> >> >> >> >>> >>>> (Note to Aslak: read the link from Jan!) >> >> >> >> >> >> >>> >>>> >> >> >> >> >> >> >>> >>>> Martin >> >> >> >> >> >> >>> >>>> >> >> >> >> >> >> >>> >>>> >> >> >> >> >> >> >>> >>>> On 22 May 2014 11:22, Jan Blechta >> >> >> >> >> >> >>> >>>> <[email protected]> >> >> >> >> >> >> >>> >>>> wrote: >> >> >> >> >> >> >>> >>>>> >> >> >> >> >> >> >>> >>>>> Note that there is also an approach of having >> >> >> >> >> >> >>> >>>>> simultaneously >> >> >> >> >> >> >>> >>>>> 2.x >> >> >> >> >> >> >>> >>>>> and >> >> >> >> >> >> >>> >>>>> 3.x >> >> >> >> >> >> >>> >>>>> compatible codebase without a need of using 2to3. >> >> >> >> >> >> >>> >>>>> Allegedly, >> >> >> >> >> >> >>> >>>>> this >> >> >> >> >> >> >>> >>>>> is >> >> >> >> >> >> >>> >>>>> used in SymPy, NumPy and SciPy projects. See >> >> >> >> >> >> >>> >>>>> >> >> >> >> >> >> >>> >>>>> >> >> >> >> >> >> >>> >>>>> >> >> >> >> >> >> >>> >>>>> >> >> >> >> >> >> >>> >>>>> >> >> >> >> >> >> >>> >>>>> >> >> >> >> >> >> >>> >>>>> >> >> >> >> >> >> >>> >>>>> >> >> >> >> >> >> >>> >>>>> http://ondrejcertik.blogspot.cz/2013/08/how-to-support-both-python-2-and-3.html >> >> >> >> >> >> >>> >>>>> >> >> >> >> >> >> >>> >>>>> Jan >> >> >> >> >> >> >>> >>>>> >> >> >> >> >> >> >>> >>>>> >> >> >> >> >> >> >>> >>>>> On Thu, 22 May 2014 11:05:43 +0200 >> >> >> >> >> >> >>> >>>>> Martin Sandve Alnæs <[email protected]> wrote: >> >> >> >> >> >> >>> >>>>> >> >> >> >> >> >> >>> >>>>> > The plan for the initial work here is to keep >> >> >> >> >> >> >>> >>>>> > the >> >> >> >> >> >> >>> >>>>> > code >> >> >> >> >> >> >>> >>>>> > python >> >> >> >> >> >> >>> >>>>> > 2.7 >> >> >> >> >> >> >>> >>>>> > compatible but ready for a later swift switch >> >> >> >> >> >> >>> >>>>> > to 3 >> >> >> >> >> >> >>> >>>>> > only. >> >> >> >> >> >> >>> >>>>> > I >> >> >> >> >> >> >>> >>>>> > suggest we >> >> >> >> >> >> >>> >>>>> > release fenics 1.5 with python 2.7 >> >> >> >> >> >> >>> >>>>> > compatibility >> >> >> >> >> >> >>> >>>>> > intact >> >> >> >> >> >> >>> >>>>> > but >> >> >> >> >> >> >>> >>>>> > convertible to python 3 by just running py2to3. >> >> >> >> >> >> >>> >>>>> > Otherwise >> >> >> >> >> >> >>> >>>>> > there >> >> >> >> >> >> >>> >>>>> > will >> >> >> >> >> >> >>> >>>>> > be too much simultaneous breakage. Then we can >> >> >> >> >> >> >>> >>>>> > discuss >> >> >> >> >> >> >>> >>>>> > whether >> >> >> >> >> >> >>> >>>>> > we >> >> >> >> >> >> >>> >>>>> > leave python 2.7 behind in fenics 1.6 or not. >> >> >> >> >> >> >>> >>>>> > >> >> >> >> >> >> >>> >>>>> > However, I haven't thought about the swig side >> >> >> >> >> >> >>> >>>>> > in >> >> >> >> >> >> >>> >>>>> > dolfin, >> >> >> >> >> >> >>> >>>>> > and >> >> >> >> >> >> >>> >>>>> > as >> >> >> >> >> >> >>> >>>>> > Johan >> >> >> >> >> >> >>> >>>>> > mentions keeping the Python CAPI code >> >> >> >> >> >> >>> >>>>> > compatible >> >> >> >> >> >> >>> >>>>> > is >> >> >> >> >> >> >>> >>>>> > not >> >> >> >> >> >> >>> >>>>> > covered >> >> >> >> >> >> >>> >>>>> > by >> >> >> >> >> >> >>> >>>>> > py2to3. I'll discuss this with Johan and Aslak. >> >> >> >> >> >> >>> >>>>> > >> >> >> >> >> >> >>> >>>>> > Martin >> >> >> >> >> >> >>> >>>>> > >> >> >> >> >> >> >>> >>>>> > >> >> >> >> >> >> >>> >>>>> > On 22 May 2014 10:49, Garth N. Wells >> >> >> >> >> >> >>> >>>>> > <[email protected]> >> >> >> >> >> >> >>> >>>>> > wrote: >> >> >> >> >> >> >>> >>>>> > >> >> >> >> >> >> >>> >>>>> > > Nice. Do we want to support Python 2.7 and 3, >> >> >> >> >> >> >>> >>>>> > > or >> >> >> >> >> >> >>> >>>>> > > would >> >> >> >> >> >> >>> >>>>> > > it >> >> >> >> >> >> >>> >>>>> > > be >> >> >> >> >> >> >>> >>>>> > > more >> >> >> >> >> >> >>> >>>>> > > sustainable to go all Python 3? My preference >> >> >> >> >> >> >>> >>>>> > > is >> >> >> >> >> >> >>> >>>>> > > for >> >> >> >> >> >> >>> >>>>> > > simplicity >> >> >> >> >> >> >>> >>>>> > > and >> >> >> >> >> >> >>> >>>>> > > low maintenance, which points to Python 3 >> >> >> >> >> >> >>> >>>>> > > only >> >> >> >> >> >> >>> >>>>> > > support. >> >> >> >> >> >> >>> >>>>> > > >> >> >> >> >> >> >>> >>>>> > > Garth >> >> >> >> >> >> >>> >>>>> > > On Thu, 22 May, 2014 at 9:39 AM, Martin >> >> >> >> >> >> >>> >>>>> > > Sandve >> >> >> >> >> >> >>> >>>>> > > Alnæs >> >> >> >> >> >> >>> >>>>> > > <[email protected]> wrote: >> >> >> >> >> >> >>> >>>>> > > >> >> >> >> >> >> >>> >>>>> > >> We have a summer intern at Simula, Aslak >> >> >> >> >> >> >>> >>>>> > >> Bergersen, >> >> >> >> >> >> >>> >>>>> > >> who will work on preparations for python 3 >> >> >> >> >> >> >>> >>>>> > >> support >> >> >> >> >> >> >>> >>>>> > >> in >> >> >> >> >> >> >>> >>>>> > >> FEniCS, >> >> >> >> >> >> >>> >>>>> > >> as well as some other FEniCS tasks, from >> >> >> >> >> >> >>> >>>>> > >> late >> >> >> >> >> >> >>> >>>>> > >> June >> >> >> >> >> >> >>> >>>>> > >> and >> >> >> >> >> >> >>> >>>>> > >> throughout July. >> >> >> >> >> >> >>> >>>>> > >> >> >> >> >> >> >> >>> >>>>> > >> The preparations for python 3 involves >> >> >> >> >> >> >>> >>>>> > >> mainly: >> >> >> >> >> >> >>> >>>>> > >> - Replacing ScientificPython for AD in FIAT >> >> >> >> >> >> >>> >>>>> > >> - Applying and committing backwards >> >> >> >> >> >> >>> >>>>> > >> compatible >> >> >> >> >> >> >>> >>>>> > >> parts >> >> >> >> >> >> >>> >>>>> > >> of >> >> >> >> >> >> >>> >>>>> > >> py2to3 >> >> >> >> >> >> >>> >>>>> > >> - Replacing several functions such as >> >> >> >> >> >> >>> >>>>> > >> dict.iteritems >> >> >> >> >> >> >>> >>>>> > >> with >> >> >> >> >> >> >>> >>>>> > >> six.iteritems in UFL and possibly FFC to >> >> >> >> >> >> >>> >>>>> > >> make >> >> >> >> >> >> >>> >>>>> > >> sure >> >> >> >> >> >> >>> >>>>> > >> we >> >> >> >> >> >> >>> >>>>> > >> keep >> >> >> >> >> >> >>> >>>>> > >> the >> >> >> >> >> >> >>> >>>>> > >> same performance and memory behaviour with >> >> >> >> >> >> >>> >>>>> > >> python >> >> >> >> >> >> >>> >>>>> > >> 2 >> >> >> >> >> >> >>> >>>>> > >> and >> >> >> >> >> >> >>> >>>>> > >> 3. >> >> >> >> >> >> >>> >>>>> > >> >> >> >> >> >> >> >>> >>>>> > >> I will be on vacation part of his time here >> >> >> >> >> >> >>> >>>>> > >> so >> >> >> >> >> >> >>> >>>>> > >> please >> >> >> >> >> >> >>> >>>>> > >> help him out if he has questions to the >> >> >> >> >> >> >>> >>>>> > >> list. >> >> >> >> >> >> >>> >>>>> > >> >> >> >> >> >> >> >>> >>>>> > >> Martin >> >> >> >> >> >> >>> >>>>> > >> >> >> >> >> >> >> >>> >>>>> > > >> >> >> >> >> >> >>> >>>>> > > >> >> >> >> >> >> >>> >>>>> >> >> >> >> >> >> >>> >>>> >> >> >> >> >> >> >>> >>>> >> >> >> >> >> >> >>> >>>> _______________________________________________ >> >> >> >> >> >> >>> >>>> fenics mailing list >> >> >> >> >> >> >>> >>>> [email protected] >> >> >> >> >> >> >>> >>>> http://fenicsproject.org/mailman/listinfo/fenics >> >> >> >> >> >> >>> >>>> >> >> >> >> >> >> >>> >>> >> >> >> >> >> >> >>> >> >> >> >> >> >> >> >>> > >> >> >> >> >> >> >>> > >> >> >> >> >> >> >>> > >> >> >> >> >> >> >>> > -- >> >> >> >> >> >> >>> > Mvh >> >> >> >> >> >> >>> > Aslak Bergersen >> >> >> >> >> >> >>> > 993 22 848 >> >> >> >> >> >> >>> > >> >> >> >> >> >> >>> > >> >> >> >> >> >> >>> > _______________________________________________ >> >> >> >> >> >> >>> > fenics mailing list >> >> >> >> >> >> >>> > [email protected] >> >> >> >> >> >> >>> > http://fenicsproject.org/mailman/listinfo/fenics >> >> >> >> >> >> >>> > >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> >> >> >> >> Mvh >> >> >> >> >> >> >> Aslak Bergersen >> >> >> >> >> >> >> 993 22 848 >> >> >> >> >> >> >> >> >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > -- >> >> >> >> >> > Mvh >> >> >> >> >> > Aslak Bergersen >> >> >> >> >> > 993 22 848 >> >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > -- >> >> >> >> > Mvh >> >> >> >> > Aslak Bergersen >> >> >> >> > 993 22 848 >> >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > -- >> >> >> > Mvh >> >> >> > Aslak Bergersen >> >> >> > 993 22 848 >> >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > -- >> >> > Mvh >> >> > Aslak Bergersen >> >> > 993 22 848 >> >> > >> > >> > >> > >> > -- >> > Mvh >> > Aslak Bergersen >> > 993 22 848 >> > >> > > > > > > -- > Mvh > Aslak Bergersen > 993 22 848 > _______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
