April 2013 - petsc-dev - mailman3.cels.anl.gov

Re: [petsc-dev] macro wrappers around functions to caste suck
by Barry Smith 07 Apr '13

07 Apr '13

On Apr 7, 2013, at 4:16 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > Barry Smith <bsmith(a)mcs.anl.gov> writes: > >> That was my rationalization for ugly code; until a better solution >> appeared and I no longer needed the rationalization :-) > > Okay, are we removing _all_ those casts, or only for a few highly-used > PetscObject functions? PetscObjectComm() is one we changed recently. Seems inconsistent to only handle the cast automatically for some. We should do it all or nothing. That is be C++ish and let the user always pass a subclass where the class is expected or be C ish and always require the cast. > > Note that absorbing the cast into the macro is backward-compatible in > that code with an explicit cast continues to work without a warning. Ok, then we shouldn't make this change, you know I hate changes that are backward compatible :-)

1 0

Re: [petsc-dev] macro wrappers around functions to caste suck
by Jed Brown 07 Apr '13

07 Apr '13

Barry Smith <bsmith(a)mcs.anl.gov> writes: > That was my rationalization for ugly code; until a better solution > appeared and I no longer needed the rationalization :-) Okay, are we removing _all_ those casts, or only for a few highly-used PetscObject functions? PetscObjectComm() is one we changed recently. Note that absorbing the cast into the macro is backward-compatible in that code with an explicit cast continues to work without a warning.

1 0

Re: [petsc-dev] macro wrappers around functions to caste suck
by Barry Smith 07 Apr '13

07 Apr '13

On Apr 5, 2013, at 9:34 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > > On Fri, Apr 5, 2013 at 9:28 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > The biggest mistake of C was CPP > > Hey, we can eliminate the currently needed (PetscObject) cast in a bunch of places with this horrible trick. > > I thought you liked the explicitness of that cast. That was my rationalization for ugly code; until a better solution appeared and I no longer needed the rationalization :-) > > This actually doesn't introduce any more macros, its the same number with more reasonable naming. > > Sure, it just uses #undef. I have no problem with changing it.

1 0

Re: [petsc-dev] Matlab interface
by Barry Smith 07 Apr '13

07 Apr '13

I have pushed Jose's additional fixes into next. Barry On Apr 6, 2013, at 4:35 AM, Jose E. Roman <jroman(a)dsic.upv.es> wrote: > > El 06/04/2013, a las 02:25, Barry Smith escribió: > >> >> I have fixed the bug, it was introduced by me when changing MPIUni to have different MPI_COMM_SELF and WORLD. The fix is in next and in barry/fix-matlab >> >> Note I did not update the MATLAB scripts that are out of date. >> >> This fix needs to get into Master before the release. >> >> Thanks for reporting the problem, >> >> Barry >> > > Thanks. I pushed one change to barry/fix-matlab. I only had a look at the 6 examples listed in demo.m. Still two of them do not work: > > - exKSPDM: uses DMSetFunction that does not exist anymore. > - exSNES_DVI: I got a segmentation fault. > > Jose >

1 0

Re: [petsc-dev] petscsf infects everything
by Jed Brown 06 Apr '13

06 Apr '13

Barry Smith <bsmith(a)mcs.anl.gov> writes: > On Apr 6, 2013, at 6:48 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > >> Barry Smith <bsmith(a)mcs.anl.gov> writes: >> >>> If that would achieve the same object then that sounds fine. So include petscsftypes.h in petscis.h? >> >> Yeah, it's the same pattern we use for petscdrawtypes.h, petscdmtypes.h, >> etc. > > As Captain Picard says, "make it so, if you want to" 'jed/sftypes' is now in 'next'

1 0

Re: [petsc-dev] petscsf infects everything
by Barry Smith 06 Apr '13

06 Apr '13

On Apr 6, 2013, at 6:48 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > Barry Smith <bsmith(a)mcs.anl.gov> writes: > >> If that would achieve the same object then that sounds fine. So include petscsftypes.h in petscis.h? > > Yeah, it's the same pattern we use for petscdrawtypes.h, petscdmtypes.h, > etc. As Captain Picard says, "make it so, if you want to" Barry

1 0

Re: [petsc-dev] petscsf infects everything
by Jed Brown 06 Apr '13

06 Apr '13

Barry Smith <bsmith(a)mcs.anl.gov> writes: > If that would achieve the same object then that sounds fine. So include petscsftypes.h in petscis.h? Yeah, it's the same pattern we use for petscdrawtypes.h, petscdmtypes.h, etc.

1 0

Re: [petsc-dev] petscsf infects everything
by Barry Smith 06 Apr '13

06 Apr '13

On Apr 6, 2013, at 6:41 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > Barry Smith <bsmith(a)mcs.anl.gov> writes: > >> petscis.h includes petscsf.h and thus infects almost all petsc >> source code. Should we have a petscissf.h that has the is/sf >> related stuff that is in petscis.h and thus avoid including >> petscsf.h everywhere (like every pc, ksp, and ts file?)? > > Why not split petscsftype.h out of petscsf.h, as per the pattern used > everywhere else? If that would achieve the same object then that sounds fine. So include petscsftypes.h in petscis.h? Barry

1 0

Re: [petsc-dev] petscsf infects everything
by Jed Brown 06 Apr '13

06 Apr '13

Barry Smith <bsmith(a)mcs.anl.gov> writes: > petscis.h includes petscsf.h and thus infects almost all petsc > source code. Should we have a petscissf.h that has the is/sf > related stuff that is in petscis.h and thus avoid including > petscsf.h everywhere (like every pc, ksp, and ts file?)? Why not split petscsftype.h out of petscsf.h, as per the pattern used everywhere else?

1 0

petscsf infects everything
by Barry Smith 06 Apr '13

06 Apr '13

petscis.h includes petscsf.h and thus infects almost all petsc source code. Should we have a petscissf.h that has the is/sf related stuff that is in petscis.h and thus avoid including petscsf.h everywhere (like every pc, ksp, and ts file?)? Thanks Barry

1 0