dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Mon, Nov 30, 2009 at 10:57:17PM +0000, Garth N. Wells wrote:
>
>
> Johan Hake wrote:
> > On Monday 30 November 2009 12:11:34 Anders Logg wrote:
> >> 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?
> >
> > Yes.
> >
> > At least the amount of time I feel correct using on it. It is a bit more nasty
> > than I first anticipated. But I have good hope!
> >
>
> Would these difficulties be resolved if we use the native SWIG wrappers
> for std::vector instead of homemade versions case-by-case? I know that
> the SWIG std::vector wrapper was removed to reduce the size of the
> wrapper code, but perhaps the same could be achieved by using more %ignore?
>
> Garth

If the built-in wrappers work, I suggest we use them instead of the
our homemade versions even if the code increases if that makes the
wrapper code easier to maintain.

--
Anders

Attachment: signature.asc
Description: Digital signature