dolfin team mailing list archive

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

Anders Logg wrote:
> On Sun, Jan 24, 2010 at 12:22:24PM +0000, Garth N. Wells wrote:
>>
>> Anders Logg wrote:
>>> On Sun, Jan 24, 2010 at 08:38:08AM +0000, Garth N. Wells wrote:
>>>> Anders Logg wrote:
>>>>> What shape are we in currently for making a new release next week?
>>>> FFC/FIAT/UFL should have some more testing time before a release given
>>>> all the changes.
>>> Yes, ideally we should have more time but we don't. We can't move the
>>> Debian import freeze and I think it would be good to get the latest
>>> release in there.
>>>
>> If it goes into Debian, we should be confident that it's all ok and not
>> rush it. DOLFIN 0.9.4 is in Ubuntu Lucid, so if we can get it to 0.9.5
>> it should be OK. Not that much has changed on the outside from 0.9.5 to
>> the upcoming 0.9.6 (or with the related packages).
>>
>> Garth
> 
> Yes, we should be confident that it's ok so it's just a matter of
> finishing testing on time. If we do, then we can release. If not, we
> have to wait.
> 
> Are there any issues to fix in DOLFIN before 0.9.6 other than the
> const-const Array thing?
>

There is an open bug:

  https://bugs.launchpad.net/dolfin/+bug/497509

We need a sprint at some point to knock off some blueprints.

Garth

> --
> Anders
> 
> 
>>> It all depends on whether we finish testing on time. We will have
>>> quite massive testing (unit and regression tests) to back up the new
>>> release.
>>>
>>>>> I've been locked up in FFC/UFL for the last month so I'm not fully
>>>>> up to speed.
>>>>>
>>>>> One thing I'm not completely happy with is
>>>>>
>>>>>   const Array<const double>& x
>>>>>
>>>>> It would look better if we could somehow manage to have
>>>>>
>>>>>   const Array<double>& x
>>>>>
>>>>> Would that be possible to fix?
>>>>>
>>>> We can't fix it properly. We looked at it some time ago. The reason is
>>>> that Array does not necessarily own the data, unlike a std::vector. We
>>>> therefore need
>>>>
>>>>   const Array<const foo> bar
>>>>
>>>> when wrapping const pointers.
>>> Would it help if we let data.x own its values and then copy the values
>>> into data.x instead of
>>>
>>>   this->x.update(ufc_cell.geometric_dimension, x);
>>>
>>> inside Data::set. It might be slower potentially, but I doubt it will
>>> matter.
>>>
>>> It would make the interface more intuitive. As it is now, we force an
>>> extra const that looks strange.
>>>
>>>>> What needs to happen before ca next Wednesday is to fix any remaining
>>>>> issues in DOLFIN (how many?) and FFC (quite a few) and then make new
>>>>> releases of
>>>>>
>>>>>   DOLFIN (0.9.6)
>>>>>   FFC (0.9.0)
>>>>>   UFL (0.5.0)
>>>>>   FIAT (0.4.0?)
>>>>>   UFC (1.2.1)
>>>>>
>>>>> Anything else?
>>>>>
>>>> There was an update to Viper recently.
>>> You mean the LUT thing? It wouldn't hurt, but I'm not sure how
>>> important that is.
>>>