dolfin team mailing list archive

["Garth N. Wells" <gnw20@xxxxxxxxx>]

Anders Logg wrote:
> 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.
>

I've had a look at this. Using the SWIG wrappers I've deleted tons of
our complicated wrapper code, and things that didn't work now do
automatically. I'll push a first go soon.

Garth

> --
> Anders