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
<https://bitbucket.org/aslakbergersen/fiat/branch/aslakbergersen/topic-prepare-py3>
[6] https://bitbucket.org/fenics/ffc/
<https://bitbucket.org/aslakbergersen/fiat/branch/aslakbergersen/topic-prepare-py3>
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] <javascript:;>> 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]
> <javascript:;>>:
> >
> >> 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] <javascript:;>> 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]
> <javascript:;>>:
> >> >
> >> >> Do those tests fail with the latest FIAT master, too?
> >> >>
> >> >> --Nico
> >> >>
> >> >> On Thu, Jul 24, 2014 at 7:27 PM, Aslak Bergersen
> >> >> <[email protected] <javascript:;>> 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]
> <javascript:;>>:
> >> >> >
> >> >> >> 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] <javascript:;>> 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] <javascript:;>>:
> >> >> >> >
> >> >> >> >> > 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] <javascript:;>>
> >> >> >> >> 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] <javascript:;>>
> >> >> >> >> > 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] <javascript:;>>:
> >> >> >> >> >>
> >> >> >> >> >>> > 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] <javascript:;>> 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] <javascript:;>>:
> >> >> >> >> >>> >
> >> >> >> >> >>> >> 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]
> <javascript:;>>
> >> >> >> >> >>> >> 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] <javascript:;>> 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] <javascript:;>>
> >> >> >> >> >>> >>>> 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]
> <javascript:;>> 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] <javascript:;>>
> >> >> >> >> >>> >>>>> > 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] <javascript:;>> 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] <javascript:;>
> >> >> >> >> >>> >>>> http://fenicsproject.org/mailman/listinfo/fenics
> >> >> >> >> >>> >>>>
> >> >> >> >> >>> >>>
> >> >> >> >> >>> >>
> >> >> >> >> >>> >
> >> >> >> >> >>> >
> >> >> >> >> >>> >
> >> >> >> >> >>> > --
> >> >> >> >> >>> > Mvh
> >> >> >> >> >>> > Aslak Bergersen
> >> >> >> >> >>> > 993 22 848
> >> >> >> >> >>> >
> >> >> >> >> >>> >
> >> >> >> >> >>> > _______________________________________________
> >> >> >> >> >>> > fenics mailing list
> >> >> >> >> >>> > [email protected] <javascript:;>
> >> >> >> >> >>> > 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
_______________________________________________
fenics mailing list
[email protected]
http://fenicsproject.org/mailman/listinfo/fenics
