Ah, wait a minute; do you get ``` AttributeError: 'list' object has no attribute 'dtype' ``` ?
--Nico On Thu, Jul 24, 2014 at 6:32 PM, Nico Schlömer <[email protected]> wrote: > 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
