| Thread Previous • Date Previous • Date Next • Thread Next |
On 10/05/10 16:20, Johan Hake wrote:
On Sunday May 9 2010 13:26:04 Garth N. Wells wrote:On 09/05/10 21:08, Marie Rognes wrote:Garth N. Wells wrote:On 09/05/10 20:11, Anders Logg wrote:On Sun, May 09, 2010 at 07:50:14PM +0100, Garth N. Wells wrote:On 09/05/10 19:25, Anders Logg wrote:On Sun, May 09, 2010 at 07:06:04PM +0100, Garth N. Wells wrote:On 09/05/10 15:04, Marie Rognes wrote:Garth N. Wells wrote:Does this work from the C++ interface too?Nope. It is a pure python prototype.This isn't the design philosophy that we've used in developing DOLFIN. We have developed in C++ (and I think still should) and generated the Python interface automatically, and implemented Python extensions by hand only when necessary. I don't want to see a divergence of the interfaces and advocate that Python 'prototypes' should not be part of DOLFIN. GarthI think this prototype is too good to be kept as a prototype. We will move the things that can be moved to C++, but it might not be possible to move all of it since it relies on automatic differentiation and auto-generation of the dual problem.Having Python-only parts when required is fine (like we do now), but why not develop the C++ building blocks before committing to dolfin-main?Simply because we just finished the Python version and thought it would be useful to others.If the structure is clear and clean, it doesn't take much effort to write the C++ code. By not adding the C++ code now, there is a strong likelihood that it will never be added.It's not unlikely. There is quite a strong commitment to moving parts of it to C++.I would prefer that prototypes remain in the sandbox until the C++ code is in place. The addition of the Python adaptivity code marks a change in development approach and should be discussed.I'm not sure the sandbox is a good place (at least not in its current form). It's a mixture of stuff that works and stuff that doesn't work, things that are broken, test snippets etc. If we decide to enforce a strong policy that we should not add experimental code to DOLFIN,The question is not on experimental code - it's preserving the language-neutral nature of DOLFIN and whether we want to continue this approach. I would like DOLFIN to remain language-neutral.is there a way that we could organize modules like the adaptivity module and make them easily installable? I don't think it's a good idea to create things as separate projects, if the intention is to merge it into DOLFIN. It would be something between dolfin-sandbox and dolfin-main.A DOLFIN-app? Once ready, it could be merged into dolfin-main. I would like to have the adaptivity code in dolfin-main now (with C++ code), but I'm too much of a cynic to be sold on assurances that C++ code will be added ;). What's the driver if the code already meets the need of the developer?I don't think I'll embark on the philosophical issues. However, (1) I take personal responsibility for adding this on the c++ side to the extent this is possible (at least as long as it stays in dolfin-main ;) )hGreat! I look forward to it . . . soon ;).(2) I'm envisioning having a hard time at explaning (potential) users that "we can do this really cool thing, that nobody else can do, but we do not want to make it easily accessible because of our language philosophy".Two points on the argumentation under (2): (a) Code can always be made available. I've made Python-only code publicly available in support of papers, etc (e.g., http://www.dspace.cam.ac.uk/handle/1810/221687)This is true, but the availability of the features decrease dramatically, which I think is a very important argument.(b) What you describe under point (2) is exactly what Python-only features says to users of the DOLFIN C++ interface.Live with it! ;) For a long time alot of features were only available for C++ users. For example everything regardning paralell assemble in DOLFIN. Also when I found something that were not available for Python, or suboptimal, I had to implement it my self.
We do our best to be indifferent, which means use C++ when possible and allow SWIG to generate the Python wrappers, and then add hand-made Python features when necessary. If SWIG could generate good C++ from Python, then I would be very happy with Python-only development.
My point is our development model. The philoso.phy relates to the design/development process which we described in http://doi.acm.org/10.1145/1731022.1731030 and which I argue has worked pretty well so far. There is no language philosophy.Which still, I would say, is mostly true. I would obviously like the above mentioned feature to be implemented in C++ too. But having more eyes and most important users of a features, creates dynamics to the development process, we would not have if it was not committed to main. It might also not be the author of a particular feature that implements it for the other language.
That's fine, but who? Unfortunately we don't employ any programmers to do this for us.
Garth
Sometimes (read almost everytime) the main author has a prefered language. Implementing the feature in the other language might be frustrating and it is likely the results get suboptimal. JohanGarth-- Marie_______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : dolfin@xxxxxxxxxxxxxxxxxxx Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
| Thread Previous • Date Previous • Date Next • Thread Next |
