June 2008 - petsc-dev - mailman3.cels.anl.gov

Re: request for hosting new petsc4py
by Lisandro Dalcin 27 Jun '08

27 Jun '08

On 6/27/08, Satish Balay <balay(a)mcs.anl.gov> wrote: > Sure - I can create a new 'project' account for this - and you can > manage your own access control list. [and host multiple repos if > necessary]. Well, that would be really, really great. > Also - I'm guessing you'll want public/http access aswell.. Probably yes. Hope this is not too much trouble for you to setup. -- Lisandro Dalcï¿½n --------------- Centro Internacional de Mï¿½todos Computacionales en Ingenierï¿½a (CIMEC) Instituto de Desarrollo Tecnolï¿½gico para la Industria Quï¿½mica (INTEC) Consejo Nacional de Investigaciones Cientï¿½ficas y Tï¿½cnicas (CONICET) PTLC - Gï¿½emes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594

1 0

Re: request for hosting new petsc4py
by Satish Balay 27 Jun '08

27 Jun '08

On Fri, 27 Jun 2008, Lisandro Dalcin wrote: > Could I ask you for hosting a Mercurial repo for the new Cython-based > petsc4py, alongside with all your others repos? Sure - I can create a new 'project' account for this - and you can manage your own access control list. [and host multiple repos if necessary]. Also - I'm guessing you'll want public/http access aswell.. Satish

1 0

request for hosting new petsc4py
by Lisandro Dalcin 27 Jun '08

27 Jun '08

Could I ask you for hosting a Mercurial repo for the new Cython-based petsc4py, alongside with all your others repos? -- Lisandro Dalcï¿½n --------------- Centro Internacional de Mï¿½todos Computacionales en Ingenierï¿½a (CIMEC) Instituto de Desarrollo Tecnolï¿½gico para la Industria Quï¿½mica (INTEC) Consejo Nacional de Investigaciones Cientï¿½ficas y Tï¿½cnicas (CONICET) PTLC - Gï¿½emes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594

1 0

Re: change to petsc-dev
by Barry Smith 25 Jun '08

25 Jun '08

On Jun 25, 2008, at 9:37 AM, Lisandro Dalcin wrote: > On 6/24/08, Barry Smith <bsmith(a)mcs.anl.gov> wrote: >> Actually I consider that I added the const to make the compiler happy >> without really >> understanding what I was doing with const (I still don't completely >> understand const). > > Well, at least you understand why the program below segfaults, right? > > static void myfun(char* p) { > p[0] = 'Z'; > } > int main() { > myfun("Lisandro"); > return 0; > } > > Yes, this is the simplest use of const. I understand this case. >> Somehow Matt and Lisandro seem to think my "fix" of adding >> const to VecType (and XXType) was fundamentally correct; >> I think it was just a result of my stupidity. > > I still think the const was fundamentally correct, at least if you > want VecType to be like an 'opaque' handle being employed on the USER ^^^^^^^^^^^^ I never saw these as 'opaque' handles, I always saw them as 'names' of object types. > > side. If you think about XXXTypes being opaque handles, then having to > declare a 'const XXXType' variable is confusing, unnatural, and ugly. > > > >> We can easily eliminate the XXType completely and just have >> XXXSetType(XXX,const char *) >> then one could do >> const char *vtype = VECMPI; >> instead of >> const VecType vtype = VECMPI; >> >> Perhaps this is best, I introduced XXXType just to make the code more >> transparent, > > IMHO, XXXType (the const form) makes the USER-level code cleaner. > Additionally, it make more explicit the prototipes of PETSc routines. > > Consider this: > > (1) PetscErrorCode DMGetMatrix(DM, MatType, Mat*); > > against this: > > (2) PetscErrorCode DMGetMatrix(DM, const char*, Mat*); > > > Do you think (2) makes clear what the pourpose of the 'const char*' > argument is? Clearly 1 is clearer, which is why I introduced the XXType. > > > And the same reasoning could be applied to VecLoad, MatLoad, > MatConvert, MatGetOrdering, etc. > > So I still convinced that all XXX types should be a typedef with const > (NOT a #define) like this: > > typedef const char* XXXType; > > I can understand your point of view; as Satish says it is a tradeoff of competing issues. Barry > > > > -- > Lisandro Dalcï¿½n > --------------- > Centro Internacional de Mï¿½todos Computacionales en Ingenierï¿½a (CIMEC) > Instituto de Desarrollo Tecnolï¿½gico para la Industria Quï¿½mica (INTEC) > Consejo Nacional de Investigaciones Cientï¿½ficas y Tï¿½cnicas (CONICET) > PTLC - Gï¿½emes 3450, (3000) Santa Fe, Argentina > Tel/Fax: +54-(0)342-451.1594 >

1 0

Re: change to petsc-dev
by Lisandro Dalcin 25 Jun '08

25 Jun '08

On 6/24/08, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > Actually I consider that I added the const to make the compiler happy > without really > understanding what I was doing with const (I still don't completely > understand const). Well, at least you understand why the program below segfaults, right? static void myfun(char* p) { p[0] = 'Z'; } int main() { myfun("Lisandro"); return 0; } > Somehow Matt and Lisandro seem to think my "fix" of adding > const to VecType (and XXType) was fundamentally correct; > I think it was just a result of my stupidity. I still think the const was fundamentally correct, at least if you want VecType to be like an 'opaque' handle being employed on the USER side. If you think about XXXTypes being opaque handles, then having to declare a 'const XXXType' variable is confusing, unnatural, and ugly. > We can easily eliminate the XXType completely and just have > XXXSetType(XXX,const char *) > then one could do > const char *vtype = VECMPI; > instead of > const VecType vtype = VECMPI; > > Perhaps this is best, I introduced XXXType just to make the code more > transparent, IMHO, XXXType (the const form) makes the USER-level code cleaner. Additionally, it make more explicit the prototipes of PETSc routines. Consider this: (1) PetscErrorCode DMGetMatrix(DM, MatType, Mat*); against this: (2) PetscErrorCode DMGetMatrix(DM, const char*, Mat*); Do you think (2) makes clear what the pourpose of the 'const char*' argument is? And the same reasoning could be applied to VecLoad, MatLoad, MatConvert, MatGetOrdering, etc. So I still convinced that all XXX types should be a typedef with const (NOT a #define) like this: typedef const char* XXXType; -- Lisandro Dalcï¿½n --------------- Centro Internacional de Mï¿½todos Computacionales en Ingenierï¿½a (CIMEC) Instituto de Desarrollo Tecnolï¿½gico para la Industria Quï¿½mica (INTEC) Consejo Nacional de Investigaciones Cientï¿½ficas y Tï¿½cnicas (CONICET) PTLC - Gï¿½emes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594

1 0

Re: change to petsc-dev
by Barry Smith 24 Jun '08

24 Jun '08

On Jun 24, 2008, at 4:45 PM, Satish Balay wrote: > On Tue, 24 Jun 2008, Barry Smith wrote: > >> >> Absolutely NOT! >> >> It is perfectly reasonable to have the const in user code; WHENEVER >> a user uses a static string they should/must make it const > > Expecting users to use 'const char*' is "perfectly reasonable" - but > expecting users to use 'const VecType' (which is a predefied type) is > a step below it. [esp when we don't have const Mat, const Vec etc...]. > > So the above expectation assumes the user knows the internal impl of > this type is 'char *' - etc.. - and its not 'const *' due to these > implemenation issues etc.. > > So I think the current expectation is a minor deviation - and what I > propose is also a minor hack.. [with a benifit of more consistant user > code]. So whatever option we choose - we do it by accepting the > limitation of that choice. > > > > I guess part of the design issue is: we have a requirement for > 'VecType' functionality. > > Initially we choose 'enum' for this. This choice had limitations > [could not add new types]. > Yupp > Then we choose "char *" Yupp, > which evolved into "const char*" due to > compiler issues. Actually I consider that I added the const to make the compiler happy without really understanding what I was doing with const (I still don't completely understand const). I consider now my "fix" at that time was wrong (adding the const to VecType etc) and I should have properly prototyped each function, like I have just tried to change things to do. Somehow Matt and Lisandro seem to think my "fix" of adding const to VecType (and XXType) was fundamentally correct; I think it was just a result of my stupidity. > But now we have new issues with the 'const' side of > things - limiting the extensibility of 'VecType'. [cannot dynamically > construct a string and assign is as a new type] > > Perhaps we should get away from strings [and its implemetation > consequences] - and look for a better way to abstact out the impl > details from the interface requirements. [I don't have any proposal > along these lines - so the above is just noisy thoughts with no > value..] We can easily eliminate the XXType completely and just have XXXSetType(XXX,const char *) then one could do const char *vtype = VECMPI; instead of const VecType vtype = VECMPI; Perhaps this is best, I introduced XXXType just to make the code more transparent, not to have some kind of magic correctness checking. If it is not making the code more transparent, we might as well toss it. Barry > > > Satish >

1 0

Re: change to petsc-dev
by Satish Balay 24 Jun '08

24 Jun '08

On Tue, 24 Jun 2008, Lisandro Dalcin wrote: > Well, that's not completelly true. What's wrong with building a type > name from pieces in a temporary char[] (non-const) buffer, and pass it > to XXXSetType() ?? Of course, PETSc internals will have to deal with > the implementation detail of VecType, but the majority of USER code > would be alleviated of such a detail. You mean - instead of: >>>>>>>> MatType t; PetscMalloc(256*sizeof(char),&t); PetscStrcpy(t,"mytypenamepart1"); PetscStrcat(t,"someadditionalpart"); MatSetType(mat,t); <<<<<<<< do: >>>>>> char *t; PetscMalloc(256*sizeof(char),&t); PetscStrcpy(t,"mytypenamepart1"); PetscStrcat(t,"someadditionalpart"); MatSetType((MatType)mat,t); >>>>>>>> I think this would handle only part of the problem. I'm ok with this impl. [to keep userinterface clean] There is the other issue of who does the free() on this malloc() [but I guess this issue exists in both of the above impls]. Satish

1 0

Re: change to petsc-dev
by Lisandro Dalcin 24 Jun '08

24 Jun '08

On 6/24/08, Satish Balay <balay(a)mcs.anl.gov> wrote: > Expecting users to use 'const char*' is "perfectly reasonable" - but > expecting users to use 'const VecType' (which is a predefied type) is > a step below it. [esp when we don't have const Mat, const Vec etc...]. > > So the above expectation assumes the user knows the internal impl of > this type is 'char *' - etc.. - and its not 'const *' due to these > implemenation issues etc.. > > So I think the current expectation is a minor deviation - and what I > propose is also a minor hack.. [with a benifit of more consistant user > code]. So whatever option we choose - we do it by accepting the > limitation of that choice. Satish, all my previous objections were all related to your previous comments. > I guess part of the design issue is: we have a requirement for > 'VecType' functionality. > Initially we choose 'enum' for this. This choice had limitations > [could not add new types]. Well, the an approach like PetscCookie would permit to create new types, but IMHO, that would be overkill. > Then we choose "char *" which evolved into "const char*" due to > compiler issues. But now we have new issues with the 'const' side of > things - limiting the extensibility of 'VecType'. [cannot dynamically > construct a string and assign is as a new type] Well, that's not completelly true. What's wrong with building a type name from pieces in a temporary char[] (non-const) buffer, and pass it to XXXSetType() ?? Of course, PETSc internals will have to deal with the implementation detail of VecType, but the majority of USER code would be alleviated of such a detail. > Perhaps we should get away from strings [and its implemetation > consequences] - and look for a better way to abstact out the impl > details from the interface requirements. [I don't have any proposal > along these lines - so the above is just noisy thoughts with no > value..] Again, that would be overkill. If the whole point of this change is to dynamically build a type name from pieces, I would just maintain XXXType being 'const char*', and handle in a non-const char buffer the building of type names. Just my 2 cents. -- Lisandro Dalcï¿½n --------------- Centro Internacional de Mï¿½todos Computacionales en Ingenierï¿½a (CIMEC) Instituto de Desarrollo Tecnolï¿½gico para la Industria Quï¿½mica (INTEC) Consejo Nacional de Investigaciones Cientï¿½ficas y Tï¿½cnicas (CONICET) PTLC - Gï¿½emes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594

1 0

Re: change to petsc-dev
by Satish Balay 24 Jun '08

24 Jun '08

On Tue, 24 Jun 2008, Barry Smith wrote: > > Absolutely NOT! > > It is perfectly reasonable to have the const in user code; WHENEVER > a user uses a static string they should/must make it const Expecting users to use 'const char*' is "perfectly reasonable" - but expecting users to use 'const VecType' (which is a predefied type) is a step below it. [esp when we don't have const Mat, const Vec etc...]. So the above expectation assumes the user knows the internal impl of this type is 'char *' - etc.. - and its not 'const *' due to these implemenation issues etc.. So I think the current expectation is a minor deviation - and what I propose is also a minor hack.. [with a benifit of more consistant user code]. So whatever option we choose - we do it by accepting the limitation of that choice. I guess part of the design issue is: we have a requirement for 'VecType' functionality. Initially we choose 'enum' for this. This choice had limitations [could not add new types]. Then we choose "char *" which evolved into "const char*" due to compiler issues. But now we have new issues with the 'const' side of things - limiting the extensibility of 'VecType'. [cannot dynamically construct a string and assign is as a new type] Perhaps we should get away from strings [and its implemetation consequences] - and look for a better way to abstact out the impl details from the interface requirements. [I don't have any proposal along these lines - so the above is just noisy thoughts with no value..] Satish

1 0

Re: change to petsc-dev
by Barry Smith 24 Jun '08

24 Jun '08

Absolutely NOT! It is perfectly reasonable to have the const in user code; WHENEVER a user uses a static string they should/must make it const Barry On Jun 24, 2008, at 3:19 PM, Satish Balay wrote: > On Tue, 24 Jun 2008, Barry Smith wrote: > >> >> I have pushed the change to PETSc-dev that eliminates the const >> from the >> definition of XXXType (for example VecType). >> In theory this should have minimal affects on your codes. The only >> change I >> think you may need are changing, for example, >> >> VecType mt = MPIVEC; >> >> to >> >> const VecType mt = MPIVEC. > > I think we can avoid this change to user-code - if we do the > following: > > #define VECMPI (char *)"mpi" > > [I guess the tradeoff is slightly less rigorous const check by the > compiler] > > > I tried this change with MatType - and looks like it requires a > corresponding change of MatGetType() from: > > MatGetType(Mat mat,const MatType *type) > to > MatGetType(Mat mat,MatType *type) > > Satish >

1 0