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

Re: no file comments for hg
by Barry Smith 25 Jul '06

25 Jul '06

Satish, Your proposed solution is ridiculously cumbersome; no sane person would put up with that nonsense. If the authors of the ct would get their heads out of their asses and update it to Qt4 (which is like, what, a year old) instead of the outdated Qt3 maybe people who use updated software could use it. Barry On Tue, 25 Jul 2006, Satish Balay wrote: > On Tue, 25 Jul 2006, Barry Smith wrote: > >> On Tue, 25 Jul 2006, Satish Balay wrote: >> >>> Yes - not having file comments makes it more difficult to go back in >>> file history. >>> >>> But one way to look at it is - for some of these senarios - it meanas >>> multiple changesets should be created [with the correct grouping of >>> changes] instead of the atempted single changeset. >> >> Yes, the problem with this is that there is no decent way of >> making multiple change-sets. > > - quit emacs without typing in any comments [so no commit is done] > - 'hg status' to get the list of modified files > - hg commit file1 file2 [ to make the appropriate changeset] > > I use 'hg ct' though.. > >> If I could just edit out the files >> I did not want when doing the comment for a commit it would make >> life a MILLION times better (could that be added?). > > I'll check on this on the mercurial list.. > > Satish > >> >> Barry >> >>> >>> And perhaps some comments can actually go into the code. >>> >>> Satish >>> >>> On Tue, 25 Jul 2006, Barry Smith wrote: >>> >>>> >>>> Not having file by file comments for changesets is >>>> starting to annoy me. >>>> >>>> Barry >>>> >>>> >>> >>> >> >> > >

1 0

Re: no file comments for hg
by Matthew Knepley 25 Jul '06

25 Jul '06

We need to find out if per file comments are possible, but just not supported by the tool. Matt On 7/25/06, Satish Balay <balay(a)mcs.anl.gov> wrote: > > On Tue, 25 Jul 2006, Barry Smith wrote: > > > On Tue, 25 Jul 2006, Satish Balay wrote: > > > > > Yes - not having file comments makes it more difficult to go back in > > > file history. > > > > > > But one way to look at it is - for some of these senarios - it meanas > > > multiple changesets should be created [with the correct grouping of > > > changes] instead of the atempted single changeset. > > > > Yes, the problem with this is that there is no decent way of > > making multiple change-sets. > > - quit emacs without typing in any comments [so no commit is done] > - 'hg status' to get the list of modified files > - hg commit file1 file2 [ to make the appropriate changeset] > > I use 'hg ct' though.. > > > If I could just edit out the files > > I did not want when doing the comment for a commit it would make > > life a MILLION times better (could that be added?). > > I'll check on this on the mercurial list.. > > Satish > > > > > Barry > > > > > > > > And perhaps some comments can actually go into the code. > > > > > > Satish > > > > > > On Tue, 25 Jul 2006, Barry Smith wrote: > > > > > > > > > > > Not having file by file comments for changesets is > > > > starting to annoy me. > > > > > > > > Barry > > > > > > > > > > > > > > > > > > > > -- "Failure has a thousand explanations. Success doesn't need one" -- Sir Alec Guiness

1 0

Re: no file comments for hg
by Satish Balay 25 Jul '06

25 Jul '06

On Tue, 25 Jul 2006, Barry Smith wrote: > On Tue, 25 Jul 2006, Satish Balay wrote: > > > Yes - not having file comments makes it more difficult to go back in > > file history. > > > > But one way to look at it is - for some of these senarios - it meanas > > multiple changesets should be created [with the correct grouping of > > changes] instead of the atempted single changeset. > > Yes, the problem with this is that there is no decent way of > making multiple change-sets. - quit emacs without typing in any comments [so no commit is done] - 'hg status' to get the list of modified files - hg commit file1 file2 [ to make the appropriate changeset] I use 'hg ct' though.. > If I could just edit out the files > I did not want when doing the comment for a commit it would make > life a MILLION times better (could that be added?). I'll check on this on the mercurial list.. Satish > > Barry > > > > > And perhaps some comments can actually go into the code. > > > > Satish > > > > On Tue, 25 Jul 2006, Barry Smith wrote: > > > > > > > > Not having file by file comments for changesets is > > > starting to annoy me. > > > > > > Barry > > > > > > > > > > > >

1 0

Re: no file comments for hg
by Barry Smith 25 Jul '06

25 Jul '06

On Tue, 25 Jul 2006, Satish Balay wrote: > Yes - not having file comments makes it more difficult to go back in > file history. > > But one way to look at it is - for some of these senarios - it meanas > multiple changesets should be created [with the correct grouping of > changes] instead of the atempted single changeset. Yes, the problem with this is that there is no decent way of making multiple change-sets. If I could just edit out the files I did not want when doing the comment for a commit it would make life a MILLION times better (could that be added?). Barry > > And perhaps some comments can actually go into the code. > > Satish > > On Tue, 25 Jul 2006, Barry Smith wrote: > >> >> Not having file by file comments for changesets is >> starting to annoy me. >> >> Barry >> >> > >

1 0

Re: no file comments for hg
by Satish Balay 25 Jul '06

25 Jul '06

Yes - not having file comments makes it more difficult to go back in file history. But one way to look at it is - for some of these senarios - it meanas multiple changesets should be created [with the correct grouping of changes] instead of the atempted single changeset. And perhaps some comments can actually go into the code. Satish On Tue, 25 Jul 2006, Barry Smith wrote: > > Not having file by file comments for changesets is > starting to annoy me. > > Barry > >

1 0

no file comments for hg
by Barry Smith 25 Jul '06

25 Jul '06

Not having file by file comments for changesets is starting to annoy me. Barry

1 0

Re: Using complex from C code
by Mathieu Taillefumier 03 Jul '06

03 Jul '06

>> I still have to check the example code which does compile with. I have >> some suggestions for this modifications. >> > > I've pushed some changes [I -> Ii] to a bunch of examples to make them > work. There could be some more examples that need this change. Some > complex examples were giving errors - I'm not sure if this is some > PETSc bug or a bug with the C99 complex change. This needs debugging. > If you look the changes I made in the different codes, they correspond mostly to change I to Ii. It can be a bug in this changes but I think that it comes from the examples. I will check also... Of course I had to modify one header file, but I don't that the problem come from this part. >> - Since I don't really know python, I made a very bad modification on >> the language.py file. I put in comment two lines. However I think that >> it is better to still have the c++ version as default language at this >> time since I don't have enough feedback for C version. So the best is >> I think that c++ is the default language for complex but have an >> option to activate C version for complex numbers. I should also indicate >> that the we need to have a C99 compliant compiler gcc 3.4 and after >> work well but they are still not very optimized. Intel compiler works >> also, but I don't know about the other. So use the option with care. The >> modifications should not break anything. >> > I've made further fixes to configure to get complex working in C mode. > > Now the option --with-scalar-type is decoupled from > --with-clanguage. This mode is a bit cleaner than trying to preserve > the old default of complex => c++. > > BTW - gcc295 worked on my laptop [which also had gcc-3.4]. Not sure > what that is.. [I have glibc-headers-2.3.6-0.fc3.1 - which is > providing /usr/include/complex.h - which gcc295 is able to use] > I am surprised that gcc -2.95 works with complex numbers, but it is a good news > You might want to get the latest petsc-dev & BuildSystem [or > petsc-dev.tar.gz snapshot] and see if it works. > Yes, I will download the last version of petsc-dev. Thank you Regards Mathieu

1 0

Re: Using complex from C code
by Satish Balay 01 Jul '06

01 Jul '06

On Sat, 1 Jul 2006, Mathieu Taillefumier wrote: > I still have to check the example code which does compile with. I have > some suggestions for this modifications. I've pushed some changes [I -> Ii] to a bunch of examples to make them work. There could be some more examples that need this change. Some complex examples were giving errors - I'm not sure if this is some PETSc bug or a bug with the C99 complex change. This needs debugging. > - Since I don't really know python, I made a very bad modification on > the language.py file. I put in comment two lines. However I think that > it is better to still have the c++ version as default language at this > time since I don't have enough feedback for C version. So the best is > I think that c++ is the default language for complex but have an > option to activate C version for complex numbers. I should also indicate > that the we need to have a C99 compliant compiler gcc 3.4 and after > work well but they are still not very optimized. Intel compiler works > also, but I don't know about the other. So use the option with care. The > modifications should not break anything. I've made further fixes to configure to get complex working in C mode. Now the option --with-scalar-type is decoupled from --with-clanguage. This mode is a bit cleaner than trying to preserve the old default of complex => c++. BTW - gcc295 worked on my laptop [which also had gcc-3.4]. Not sure what that is.. [I have glibc-headers-2.3.6-0.fc3.1 - which is providing /usr/include/complex.h - which gcc295 is able to use] You might want to get the latest petsc-dev & BuildSystem [or petsc-dev.tar.gz snapshot] and see if it works. Satish > - As I said before. I still have to look at the example code with do > not compile when Complex are activated. It is just question of time. > > Regards > > Mathieu >

1 0

Re: Using complex from C code
by Mathieu Taillefumier 01 Jul '06

01 Jul '06

I still have to check the example code which does compile with. I have some suggestions for this modifications. - Since I don't really know python, I made a very bad modification on the language.py file. I put in comment two lines. However I think that it is better to still have the c++ version as default language at this time since I don't have enough feedback for C version. So the best is I think that c++ is the default language for complex but have an option to activate C version for complex numbers. I should also indicate that the we need to have a C99 compliant compiler gcc 3.4 and after work well but they are still not very optimized. Intel compiler works also, but I don't know about the other. So use the option with care. The modifications should not break anything. - As I said before. I still have to look at the example code with do not compile when Complex are activated. It is just question of time. Regards Mathieu -- -- Dr Mathieu Taillefumier Max Planck Institute for Microstructure physics Weinberg 2, D-06120 Halle (Saale) Germany Laboratoire Louis Neel - CNRS 25 Avenue des martyrs BP 166 38042 Grenoble Cedex 09 France

1 0

Re: Using complex from C code
by Satish Balay 30 Jun '06

30 Jun '06

Added to petsc-dev now. Satish On Fri, 30 Jun 2006, Barry Smith wrote: > > Mathieu, > > Cool, thanks. > > Satish, > > Could you please apply the diff to petsc-dev now and then push > so any future changes anyone makes will be combatiable with the new > code. > > Thanks > > Barry > > On Fri, 30 Jun 2006, Mathieu Taillefumier wrote: > > > Good morning everybody, > > > > I finished to modify the code of the library in order to compile the > > complex version with a C compiler. A few numbers of files have been > > modified. This modifications include a modification of the file > > language.py where I put in comment two lines forcing to compile the > > library with a c++ compiler. Since I don't really know python, I just > > put them as a comment, but i think it is better to put a message > > indicating that compiling the complex version of Petsc needs a C90 > > compliant compiler (gcc 3.4 and after work, it works also with icc) and > > is experimental. Actually I am working with this modifications and it > > seems to work like a charm (I had no problem with it). > > I still need some time to convert the example programs which do not > > compile but it will be done soon. > > Note for all of us : > > Don't use the name I as a variable anymore. It is a reserved word of > > the language. > > For most of us, the modifications must be transparent. > > > > Regards > > > > Mathieu > > > > > >

1 0