ufl team mailing list archive

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

Anders Logg wrote:
> On Sun, Jan 24, 2010 at 12:32:29PM +0000, Garth N. Wells wrote:
>>
>> 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
> 
> This should be possible to fix in either FFC or DOLFIN. I can look at
> it when I'm done writing the regression tests for FFC (which is a bit
> of a pain).
>

Here's another bug (UFL):

    https://bugs.launchpad.net/ufl/+bug/512425

Garth

>> We need a sprint at some point to knock off some blueprints.
> 
> Yes.
> 
> --
> Anders
> 
> 
>> Garth
>>
>>>>> 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.
>>>>>
>>