On Mar 5, 2013, at 7:47 PM, Matthew Knepley <knepley at gmail.com> wrote:
> On Tue, Mar 5, 2013 at 8:38 PM, Barry Smith <bsmith at mcs.anl.gov> wrote: > > On Mar 5, 2013, at 7:19 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote: > > > > > On Tue, Mar 5, 2013 at 6:58 PM, Barry Smith <bsmith at mcs.anl.gov> wrote: > > I have created a fork https://bitbucket.org/BarryFSmith/petsc-dev-simp > > this contains all my changes plus Jed's changes with PETSC_INTERN. It works > > on all configurations I tried. > > > > I propose: > > > > Jed check it out and fix any thing I broke ASAP. > > > > Unfortunately, gitifyhg is slow for these one-shot pulls, mainly because hg > > bookmarks and branches are not namespaced. Perhaps we can hack a > > namespacing using the (perpetually unstable) Python API to make these fast. > > > > I'm testing it now. > > > > We rework this fork to the new model, C compiler and C++ compiler > > (with C bindings). (No -with-c-support flag or PETSC_USE_EXTERN_CXX flag) > > > > Can we also get rid of --with-c++-support? > > Hmm, doesn't seem to do anything. Yes we should get rid of this. > > > > > We will need to coordinate our edits on this, I am available > > to work on it but will not do anything until Jed tells me what to do. So > > Jed tell me what to do and I'll do it. Better sooner (like now :-) then > > later. > > > > I would start by deleting all occurrences of PETSC_USE_EXTERN_CXX (assume > > it is always defined, but use defined(__cplusplus) for some include guards). > > > > Then I would change all PETSC_EXTERN_C and PETSC_INTERN_C statements to > > PETSC_EXTERN and PETSC_INTERN. > > Ok, keep me informed with what is happening and if you want me to do > something, just tell me. > > > > > I don't think we can delete include/*.hh until Sieve is gone. > > Matt, > > Can we get rid of Sieve/Mesh/C++ code in PETSc and tell the current > users to stick with the latest Mecurial before it was deleted? > > I would really rather not do that. I think I can get everything done in 2 > weeks, and then I can remove everything, > but doing it before that would cut that off from all the development which I > think would be a big hassle. I am very > close and don't want to disrupt it right at the end. Ok, Barry > > Matt > > Barry > > > > > > > > -- > What most experimenters take for granted before they begin their experiments > is infinitely more interesting than any results to which their experiments > lead. > -- Norbert Wiener
