The test passes for me. --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 > _______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
