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.
Actually. I think PetscBagRegisterEnum() should be modified to copy the list, it is an unsafe function even from C now. Implicitly I assumed that list was declared as a global static variable (hence the current PetscBagRegisterEnum() is ok) but I should not have made that assumption. Barry > > 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 > > > > > > >
