On Monday 30 November 2009 17:22:19 Garth N. Wells wrote: > 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.
I'am not at all satisfied with this change. I would have hoped that you at least could wait for my response on this issue, as the amount of hours of both payed and free time, I have put down on the code is quite large. I do not want to be grumpy, but I think the point is legitimate, as DOLFIN is a community project, and this change really turned me off. I see your point of having a manageable SWIG interface. It's a strong one. However the lack of compatibility with NumPy still exists. NumPy is the natural choice when one want to use contiguous arrays back and forth to Python. I would say that a strong design goal is to have a Python interface that works smoothly with NumPy, which neither std::vector nor std_vector.i do. A better solution, in my point, would either be to stay with double/uint * for the communication of contiguous arrays, or to add a light weight wrapped class in C++ for these data structures. Johan > Garth > > > -- > > Anders > _______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : [email protected] Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
