So how do we deal with this function not being implemented unless an F2003 compiler is used? Just #ifdef its body and produce a run-time error when an old compiler is used? Satish, are you doing this?
On Thu, May 31, 2012 at 11:36 AM, Satish Balay <balay at mcs.anl.gov> wrote: > Added configure check. > > http://petsc.cs.iit.edu/petsc/releases/BuildSystem-3.3/rev/a6a959d40d3d > > Satish > > On Thu, 31 May 2012, Jed Brown wrote: > > > And we have our first petsc-maint breakage due to this Fortran 2003 > thingy. > > > > On Thu, May 31, 2012 at 9:03 AM, Satish Balay <balay at mcs.anl.gov> wrote: > > > > > This code is using "use,intrinsic :: iso_c_binding" > > > > > > Isn't this a fortran 2003 thingy? Perhaps there should be a configure > > > checks for it. > > > > > > Satish > > > > > > On Wed, 30 May 2012, Barry Smith wrote: > > > > > > > > > > > Blaise, > > > > > > > > I have pushed PetscOptionsGetEnum() and PetscBagRegisterEnum() > for > > > f90 to petsc-dev tests are in src/sys/examples/tutorials > > > > > > > > Barry > > > > > > > > On May 29, 2012, at 3:29 AM, Blaise Bourdin wrote: > > > > > > > > > > > > > > On May 29, 2012, at 1:18 AM, Barry Smith wrote: > > > > > > > > > >> > > > > >> Blaise, > > > > >> > > > > >> How about the attached? My goal is to have the usage be as > similar > > > to the other PetscOptions... calls and too not require the Fortran > user to > > > be C aware that is, they should not have to append null characters or > > > declare special C type declaration. In other words, the user writes > > > Fortran77 code :-).[see attached file: ex1f.F90] > > > > >> > > > > >> I don't think it should bleed, but then I am no longer a > Fortran > > > programmer. > > > > > > > > > > Once a fortran programmer, always a fortran programmer... It's not > > > like there is a lot to forget. > > > > > > > > > > Now I understand what you want. I agree with your goal of making > the > > > call standard and transparent. There is one issue with this approach > for a > > > function like PetscBagRegisterEnum (as far as I understand the C code), > > > where you don't copy the string array in the bag item structure, but > keep a > > > reference to it (l. 80 in bag.c). After Carray and list1 are > deallocated, > > > the bag item->list points to some nonsense. I lost my mind trying to > find a > > > workaround last week. > > > > > > > > > > Would you be OK with requesting that each of the strings in list > have > > > some padding at the end, and be modified in the wrapper (adding the > > > C_NULL_CHAR)? The alternative would be to modify PetscBagRegisterEnum, > in > > > order to store the content of list instead of just a reference, which > may > > > not be something you want to do right now. > > > > > > > > > > Blaise > > > > > > > > > > > > > > >> > > > > >> Barry > > > > >> > > > > >> > > > > >> > > > > >> On May 27, 2012, at 10:16 AM, Blaise Bourdin wrote: > > > > >> > > > > >>> Barry, > > > > >>> > > > > >>> If I frame your email, will you sign it for me? ;) > > > > >>> > > > > >>> I am traveling so I did not have much time to do it, even in my > > > sleep, but Tim's solution is essentially right. > > > > >>> > > > > >>> Have a look at the attached code. I had to write my own > interface to > > > PetscOptionsGetEnum, but I have to do the equivalent of FIXCHAR by > myself > > > (basically appending //C_NULL_CHAR). I checked in the debugger, and > the > > > list argument that is passed to PetscOptionsGetEList is the same as > the one > > > passed from C. Is this what you want? > > > > >>> > > > > >>> Do you want to do the FIXCHAR business in the C or fortran side? > I > > > suspect that you would prefer not having to append the C_NULL_CHAR in > > > fortran, but I can't figure how to do that without allocating a new > array > > > of strings, and causing a memory leak. What do you think? > > > > >>> > > > > >>> If this is not what you want, could you meet me half way and > write > > > the fortran interface you would like to use, in which case I will try > to > > > write the missing fortran parts. > > > > >>> > > > > >>> Blaise > > > > >>> <PetscF2003.F90> > > > > >>>> > > > > >>>> Tim, > > > > >>>> > > > > >>>> Thanks. But what I want is all bundled up a routine that takes > in > > > the Fortran array of character strings and allocates and copies over > them > > > to the C ptr business. Likely I could figure it out myself with but > Blaise > > > is such a Fortran wizard he can do it optimally in his sleep :-) > > > > >>>> > > > > >>>> Barry > > > > >>>> > > > > >>>> On May 25, 2012, at 8:14 PM, Tim Gallagher wrote: > > > > >>>> > > > > >>>>> For what it's worth, I answered a question about how to pass > > > string arrays awhile ago on StackOverflow: > > > > >>>>> > > > > >>>>> > > > > http://stackoverflow.com/questions/9686532/arrays-of-strings-in-fortran-c-bridges-using-iso-c-binding/9686741#9686741 > > > > >>>>> > > > > >>>>> Tim > > > > >>>>> > > > > >>>>> ----- Original Message ----- > > > > >>>>> From: "Barry Smith" <bsmith at mcs.anl.gov> > > > > >>>>> To: "For users of the development version of PETSc" < > > > petsc-dev at mcs.anl.gov> > > > > >>>>> Sent: Friday, May 25, 2012 8:57:52 PM > > > > >>>>> Subject: Re: [petsc-dev] What needs to be done before a > release? > > > > >>>>> > > > > >>>>> Blaise > > > > >>>>> > > > > >>>>> If you provide a fortran function to convert an array of > Fortran > > > strings to an array of C strings and tell us how to delete the result > then > > > we'll provide a PetscOptionsGetEnum() for Fortran. > > > > >>>>> > > > > >>>>> Barry > > > > >>>>> > > > > >>>>> On May 2, 2012, at 12:02 PM, Blaise Bourdin wrote: > > > > >>>>> > > > > >>>>>> Barry, > > > > >>>>>> > > > > >>>>>>>> Also, fortran wrappers over PetscOptionsEnum and > > > PetscBagRegisterEnum would be nice. I understand that it > > > > >>>>>>>> is a bit tricky since it involves passing fortran arrays of > > > strings. > > > > >>>>>>> > > > > >>>>>>> Yup. We'd be willing to support these from FORTRAN but > someone > > > else has to do the dirty work of figuring out how to handle those > array of > > > strings (maybe F2003?). > > > > >>>>>> > > > > >>>>>> I am attaching a simple proof of concept example that > > > demonstrates how to write a fortran interface and call petsc C > functions > > > from fortran using F2003 C-interoperability instead of going through > the > > > fortran bindings. > > > > >>>>>> > > > > >>>>>> Don't be put off by all the warnings if you use gfortran. They > > > would be easy to avoid. Basically, right now, you detect the fortran > > > integer and real kinds that match that of the C ones. It would be quite > > > simple to get the fortran C-interoperable integer and real types > associated > > > with the C type of PetscInt, PetscReal etc. > > > > >>>>>> > > > > >>>>>> Basically, we (I?) could write a fortran interface and a > fortran > > > function for the tricky functions involving arrays of string, instead > of > > > creating a custom binding in C. Are you willing to let some fortran > > > pollution into the petsc code? Where would these function have to be? > > > > >>>>>> > > > > >>>>>> Blaise > > > > >>>>>> > > > > >>>>>> PS: you need FCFLAGS='-ffixed-line-length-none > > > -ffree-line-length-none -ffree-form' or some subset of these to > compile > > > with gfortran. I'm not sure why these are not the default with a file > > > suffix .F90 > > > > >>>>>> > > > > >>>>>> <PetscF2003Binding.F90> > > > > >>>>>> -- > > > > >>>>>> Department of Mathematics and Center for Computation & > Technology > > > > >>>>>> Louisiana State University, Baton Rouge, LA 70803, USA > > > > >>>>>> Tel. +1 (225) 578 1612, Fax +1 (225) 578 4276 > > > http://www.math.lsu.edu/~bourdin > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>> > > > > >>>> > > > > >>> > > > > >>> -- > > > > >>> Department of Mathematics and Center for Computation & Technology > > > > >>> Louisiana State University, Baton Rouge, LA 70803, USA > > > > >>> Tel. +1 (225) 578 1612, Fax +1 (225) 578 4276 > > > http://www.math.lsu.edu/~bourdin > > > > >>> > > > > >>> > > > > >>> > > > > >>> > > > > >>> > > > > >>> > > > > >>> > > > > >> > > > > >> <ex1f.F90> > > > > > > > > > > -- > > > > > Department of Mathematics and Center for Computation & Technology > > > > > Louisiana State University, Baton Rouge, LA 70803, USA > > > > > Tel. +1 (225) 578 1612, Fax +1 (225) 578 4276 > > > http://www.math.lsu.edu/~bourdin > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120531/5d23bdbf/attachment.html>
