dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

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).

> 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.
> >>>
>
>

Attachment: signature.asc
Description: Digital signature