dolfin team mailing list archive
-
dolfin team
-
Mailing list archive
-
Message #16755
Re: Release
On Sun, Nov 29, 2009 at 09:51:25PM +0000, Garth N. Wells wrote:
>
>
> Anders Logg wrote:
> > On Sat, Nov 28, 2009 at 11:26:07PM +0100, Anders Logg wrote:
> >> On Sat, Nov 28, 2009 at 11:23:58PM +0100, Anders Logg wrote:
> >>> On Sat, Nov 28, 2009 at 10:21:18PM +0000, Garth N. Wells wrote:
> >>>>
> >>>> Anders Logg wrote:
> >>>>> On Sat, Nov 28, 2009 at 09:32:03PM +0000, Garth N. Wells wrote:
> >>>>>> It would be good to make a release of DOLFIN/FFL/UFL next week with the
> >>>>>> new syntax for Constants and Expressions. Are there any pressing issues
> >>>>>> which need to be addressed before making a new release?
> >>>>>>
> >>>>>> Garth
> >>>>> I agree. Let's make a release as soon as possible.
> >>>>>
> >>>>> The only things I see missing are
> >>>>>
> >>>>> 1. std::vector argument in eval. I see you've started on this.
> >>>>>
> >>>>> 2. Getting the buildbot running in on form or another.
> >>>>>
> >>>> If we don't get this running in time, I'm happy if we run the tests by
> >>>> hand on a few OSes.
> >>> Me too.
> >>>
> >>>>> Andre Massing has prepared a major bundle on the CGAL stuff but that
> >>>>> can wait until after 0.9.5, but it would be good to do it immediately
> >>>>> after so we get that done.
> >>>>>
> >>>> Perhaps he could publish it first as a personal branch on Launchpad?
> >>> Yes, it would be a good opportunity to test that feature.
> >>>
> >>> What do you think Andre? Could you give it a try?
> >> Another thing to figure out is the logic/algorithm for selecting
> >> coefficient element degrees.
> >>
> >> We have another thread going on this.
> >
> > Another thing that we might want to fix in the new release is the
> > ability to do
> >
> > return (foo, bar)
> >
> > instead of
> >
> > values[0] = foo
> > values[1] = bar
> >
> > in the Expression class in Python.
> >
> > Johan hinted that it would be possible to implement this.
> >
> > On the other hand, one can argue that the simplified Expression
> > interface (using C++ string expressions) is already simple enough for
> > simple cases and that one should need to assign to values when
> > subclassing Expression to make it consistent with the C++ interface.
> >
> > Opinions?
> >
>
> I like to keep the consistency with C++, plus Expressions which demand a
> subclass in place of JIT are usually reasonably complicated, so it may
> in practice be more like
>
> return (............................................,
> ......................................)
Agreed. Let's keep the eval interface as is.
What remains before a release? I can see these two:
1. Getting the la unit tests (get_row) working. Are you working on
this Johan?
2. The strategy for selecting degree in FFC. Please comment on this
(in another thread I just opened).
3. ?
--
Anders
Attachment:
signature.asc
Description: Digital signature
Follow ups
References