[petsc-dev] Seven days to merge MR before clang-format is instituted on the repository

[Barry Smith]

   In order to limit the amount of painful rebasing after the repository is 
reformatted to use the clang-format we are leaving a week before the reformat 
is done.

   So, if you like, use the next week to focus on getting as many of your 
complete or nearly complete MR merged into main and please help others by 
trying to do timely reviews. 

   Thanks

   Barry


  

Re: [petsc-dev] Not a single person has approved the MR for allowing the use of clang-format on the repository

[Stefano Zampini]

Just did it. I'm on vacation these days

On Sat, Aug 6, 2022, 16:31 Barry Smith  wrote:

>
>   Note that this MR does not clang-format the repository nor require that
> future MR satisfy the clang-format (yet). It merely fixes up everything
> needed so that we can clang-format the repository.
> https://gitlab.com/petsc/petsc/-/merge_requests/5455 in the future.
>
>   Not a single person has approved the MR; so it appears that everyone,
> including Jed, does not like the idea of having a way of automatically
> formatting the repository to eliminate much of the white-space chasing that
> drives Satish nuts.
>
>   This is frustrating; why would anyone go through the effort of
> contributing to PETSc based on long-term requests for improvements if
> everything just hangs ?
>
>   If you object to the MR, please note it in the MR otherwise, at least a
> few people, please approve the MR.
>
>Barry
>
>
>
>

[petsc-dev] Not a single person has approved the MR for allowing the use of clang-format on the repository

[Barry Smith]

  Note that this MR does not clang-format the repository nor require that 
future MR satisfy the clang-format (yet). It merely fixes up everything needed 
so that we can clang-format the repository. 
https://gitlab.com/petsc/petsc/-/merge_requests/5455 
<https://gitlab.com/petsc/petsc/-/merge_requests/5455> in the future.

  Not a single person has approved the MR; so it appears that everyone, 
including Jed, does not like the idea of having a way of automatically 
formatting the repository to eliminate much of the white-space chasing that 
drives Satish nuts.

  This is frustrating; why would anyone go through the effort of contributing 
to PETSc based on long-term requests for improvements if everything just hangs ?

  If you object to the MR, please note it in the MR otherwise, at least a few 
people, please approve the MR.

   Barry


   

Re: [petsc-dev] Should everything in include be a symbolic link in the git repository?

[Barry Smith]

  The example directories will almost for sure always need makefiles the goal 
is not get to rid of them. But they should be as minimalistic as possible and 
not require any unneeded boilerplate, like lists of files. Other makefiles may 
or may not be needed, it doesn't really matter, my goal is to remove the 
unneeded need for the same information in multiple places, for people to put 
that information in initially and maintain it. No goal of removing makefiles 
for the sake of removing. 

  Yes, something this dramatic such as moving include files cannot go into 
master before the release.

   Barry




> On Sep 21, 2020, at 11:37 AM, Satish Balay  wrote:
> 
> A couple of notes:
> 
> - not a good idea to make this change  for this release [even if acceptable 
> to all developers]
> 
> - I'm not sure 'eliminating makefiles' should be the goal. It might
>  not make a difference to most users [well it can break some
>  externalpckages - that look for files - and not links etc] - but it will
>  affect other developers wrt whatever new system is in place
> 
> - I understood that one of the desired features was:
> * work away in some source [or example] dir.
> * run make in this dir - to update libraries - or build examples [without 
> having to cd to PETSC_DIR to run make]
> 
> eliminating makefiles will remove these features. [and its not yet clear to 
> me what features are gained by it - and if that's net positive or not. Sure 
> one can always find some benefit and ignore or trivialize the negatives]
> 
> Satish
> 
> On Mon, 21 Sep 2020, Barry Smith wrote:
> 
>> 
>> 
>>> On Sep 20, 2020, at 11:54 PM, Satish Balay  wrote:
>>> 
>>> For one - the makefiles are primarily used for docs - and the related issue 
>>> with includes is the binding from MANSEC and SUBMANSEC to the corresponding 
>>> sourcefiles.
>>> 
>>> If the makefiles are removed - and alternate mechanism is need for this 
>>> [and all other doc targets that use makefiles]. I don't know what this 
>>> replacement system is - and if that system will be better or more complex 
>>> then the current system.
>> 
>>  I only see to ways of managing things like MANSEC (which is maybe only for 
>> docs but tells each source file what component it is associated with so is 
>> abstractly more than docs). Either we do it based on directories or every 
>> single source file has inside it this information. I think a hybrid system 
>> where sometimes it is inside the file and sometimes it is based on the 
>> directories is not desirable from a maintenance perspective. 
>> 
>>  But if we think of source files as possibly living in multiple "components" 
>> simultaneously (like code for a viewer and for HDF5) then as we talked about 
>> recently maybe all this information just needs to be imbedded in the file.
>> 
>>> 
>>> And wrt moving include files [I'm not sure if this alternate doc system 
>>> really requires this move of include files, but maybe it helps in 
>>> separating the modules better?] - we shouldn't use PETSC_DIR/include anymore
>>> 
>>> They should go into PETSC_DIR/PETSC_ARCH/include (at configure step) - and 
>>> be in sync with --prefix organization.
>> 
>>  Maybe, one advantage of this approach is exactly those links for the 
>> configuration are set and not all of them (for example includes specific to 
>> external packages like hdf5) but I am not sure this is important enough to 
>> be a better system than just having git repository links for all of them. 
>> For application code portability there may be something said for always 
>> having all the includes visible to user code, even those not usable so users 
>> don't need to protect "optional" PETSc includes with ugly ifdef.
>> 
>>  Barry
>> 
>> 
>>> 
>>> Satish
>>> 
>>> On Sun, 20 Sep 2020, Barry Smith wrote:
>>> 
>>>> 
>>>> The include directory is special because it contains source code from all 
>>>> components of PETSc but artificially collected together in a single 
>>>> directory tree because the C/C++/Fortran compilers like it this way to not 
>>>> require hundreds of -I and for distribution without the source.
>>>> 
>>>> Should the PETSc git repository be reorganized where the include files in 
>>>> the include directory tree are actually in the appropriate subdirectories 
>>>> of src/ and symbolic links are used in the include directory tree to point 
>>>> to their locations in  src/ ?
>>>> 
>>>

Re: [petsc-dev] Should everything in include be a symbolic link in the git repository?

[Satish Balay via petsc-dev]

A couple of notes:

- not a good idea to make this change  for this release [even if acceptable to 
all developers]

- I'm not sure 'eliminating makefiles' should be the goal. It might
  not make a difference to most users [well it can break some
  externalpckages - that look for files - and not links etc] - but it will
  affect other developers wrt whatever new system is in place

- I understood that one of the desired features was:
 * work away in some source [or example] dir.
 * run make in this dir - to update libraries - or build examples [without 
having to cd to PETSC_DIR to run make]

eliminating makefiles will remove these features. [and its not yet clear to me 
what features are gained by it - and if that's net positive or not. Sure one 
can always find some benefit and ignore or trivialize the negatives]

Satish

On Mon, 21 Sep 2020, Barry Smith wrote:

> 
> 
> > On Sep 20, 2020, at 11:54 PM, Satish Balay  wrote:
> > 
> > For one - the makefiles are primarily used for docs - and the related issue 
> > with includes is the binding from MANSEC and SUBMANSEC to the corresponding 
> > sourcefiles.
> > 
> > If the makefiles are removed - and alternate mechanism is need for this 
> > [and all other doc targets that use makefiles]. I don't know what this 
> > replacement system is - and if that system will be better or more complex 
> > then the current system.
> 
>   I only see to ways of managing things like MANSEC (which is maybe only for 
> docs but tells each source file what component it is associated with so is 
> abstractly more than docs). Either we do it based on directories or every 
> single source file has inside it this information. I think a hybrid system 
> where sometimes it is inside the file and sometimes it is based on the 
> directories is not desirable from a maintenance perspective. 
> 
>   But if we think of source files as possibly living in multiple "components" 
> simultaneously (like code for a viewer and for HDF5) then as we talked about 
> recently maybe all this information just needs to be imbedded in the file.
> 
> > 
> > And wrt moving include files [I'm not sure if this alternate doc system 
> > really requires this move of include files, but maybe it helps in 
> > separating the modules better?] - we shouldn't use PETSC_DIR/include anymore
> > 
> > They should go into PETSC_DIR/PETSC_ARCH/include (at configure step) - and 
> > be in sync with --prefix organization.
> 
>   Maybe, one advantage of this approach is exactly those links for the 
> configuration are set and not all of them (for example includes specific to 
> external packages like hdf5) but I am not sure this is important enough to be 
> a better system than just having git repository links for all of them. For 
> application code portability there may be something said for always having 
> all the includes visible to user code, even those not usable so users don't 
> need to protect "optional" PETSc includes with ugly ifdef.
> 
>   Barry
> 
> 
> > 
> > Satish
> > 
> > On Sun, 20 Sep 2020, Barry Smith wrote:
> > 
> >> 
> >>  The include directory is special because it contains source code from all 
> >> components of PETSc but artificially collected together in a single 
> >> directory tree because the C/C++/Fortran compilers like it this way to not 
> >> require hundreds of -I and for distribution without the source.
> >> 
> >>  Should the PETSc git repository be reorganized where the include files in 
> >> the include directory tree are actually in the appropriate subdirectories 
> >> of src/ and symbolic links are used in the include directory tree to point 
> >> to their locations in  src/ ?
> >> 
> >>  In the tarball the include files would be actually in the include 
> >> directory when the tarball is generated.
> >> 
> >>  --with-prefix installs will, of course, copy the include files over so 
> >> having them in src does not matter.
> >> 
> >>  Does git handle symbolic links nice enough to support this.
> >> 
> >>  The reason to make the change is as we move away from having makefiles in 
> >> all the directories with lists of files we need to know the "home 
> >> component" of all the files in the include tree and the natural way to 
> >> know the home is to have the true files in the appropriate src 
> >> subdirectory.
> >> 
> >>  Barry
> >> 
> >> 
> >> 
> > 
> 

Re: [petsc-dev] Should everything in include be a symbolic link in the git repository?

[Barry Smith]

> On Sep 21, 2020, at 5:17 AM, Matthew Knepley  wrote:
> 
> On Mon, Sep 21, 2020 at 3:05 AM Barry Smith  <mailto:bsm...@petsc.dev>> wrote:
> 
> 
> > On Sep 20, 2020, at 11:54 PM, Satish Balay  > <mailto:ba...@mcs.anl.gov>> wrote:
> > 
> > For one - the makefiles are primarily used for docs - and the related issue 
> > with includes is the binding from MANSEC and SUBMANSEC to the corresponding 
> > sourcefiles.
> > 
> > If the makefiles are removed - and alternate mechanism is need for this 
> > [and all other doc targets that use makefiles]. I don't know what this 
> > replacement system is - and if that system will be better or more complex 
> > then the current system.
> 
>   I only see to ways of managing things like MANSEC (which is maybe only for 
> docs but tells each source file what component it is associated with so is 
> abstractly more than docs). Either we do it based on directories or every 
> single source file has inside it this information. I think a hybrid system 
> where sometimes it is inside the file and sometimes it is based on the 
> directories is not desirable from a maintenance perspective. 
> 
>   But if we think of source files as possibly living in multiple "components" 
> simultaneously (like code for a viewer and for HDF5) then as we talked about 
> recently maybe all this information just needs to be imbedded in the file.
> 
> > 
> > And wrt moving include files [I'm not sure if this alternate doc system 
> > really requires this move of include files, but maybe it helps in 
> > separating the modules better?] - we shouldn't use PETSC_DIR/include anymore
> > 
> > They should go into PETSC_DIR/PETSC_ARCH/include (at configure step) - and 
> > be in sync with --prefix organization.
> 
>   Maybe, one advantage of this approach is exactly those links for the 
> configuration are set and not all of them (for example includes specific to 
> external packages like hdf5) but I am not sure this is important enough to be 
> a better system than just having git repository links for all of them. For 
> application code portability there may be something said for always having 
> all the includes visible to user code, even those not usable so users don't 
> need to protect "optional" PETSc includes with ugly ifdef.
> 
> I do not think the headers are worth moving. If we improve the source 
> discipline a little, they can be largely autogenerated. We now know all the 
> declarations that
> should be public. There is some other stuff in headers, but very little, and 
> that probably benefits from being in a specific place like include.

  There is actually a great deal of source code in the headers. Definitions of 
all the enum, data structures (in petsc/private), many macros and some in-line 
functions. It is not just function prototypes. 

  Barry

> 
>Matt
>  
>   Barry
> 
> 
> > 
> > Satish
> > 
> > On Sun, 20 Sep 2020, Barry Smith wrote:
> > 
> >> 
> >>  The include directory is special because it contains source code from all 
> >> components of PETSc but artificially collected together in a single 
> >> directory tree because the C/C++/Fortran compilers like it this way to not 
> >> require hundreds of -I and for distribution without the source.
> >> 
> >>  Should the PETSc git repository be reorganized where the include files in 
> >> the include directory tree are actually in the appropriate subdirectories 
> >> of src/ and symbolic links are used in the include directory tree to point 
> >> to their locations in  src/ ?
> >> 
> >>  In the tarball the include files would be actually in the include 
> >> directory when the tarball is generated.
> >> 
> >>  --with-prefix installs will, of course, copy the include files over so 
> >> having them in src does not matter.
> >> 
> >>  Does git handle symbolic links nice enough to support this.
> >> 
> >>  The reason to make the change is as we move away from having makefiles in 
> >> all the directories with lists of files we need to know the "home 
> >> component" of all the files in the include tree and the natural way to 
> >> know the home is to have the true files in the appropriate src 
> >> subdirectory.
> >> 
> >>  Barry
> >> 
> >> 
> >> 
> > 
> 
> 
> 
> -- 
> What most experimenters take for granted before they begin their experiments 
> is infinitely more interesting than any results to which their experiments 
> lead.
> -- Norbert Wiener
> 
> https://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/>

Re: [petsc-dev] Should everything in include be a symbolic link in the git repository?

[Matthew Knepley]

On Mon, Sep 21, 2020 at 3:05 AM Barry Smith  wrote:

>
>
> > On Sep 20, 2020, at 11:54 PM, Satish Balay  wrote:
> >
> > For one - the makefiles are primarily used for docs - and the related
> issue with includes is the binding from MANSEC and SUBMANSEC to the
> corresponding sourcefiles.
> >
> > If the makefiles are removed - and alternate mechanism is need for this
> [and all other doc targets that use makefiles]. I don't know what this
> replacement system is - and if that system will be better or more complex
> then the current system.
>
>   I only see to ways of managing things like MANSEC (which is maybe only
> for docs but tells each source file what component it is associated with so
> is abstractly more than docs). Either we do it based on directories or
> every single source file has inside it this information. I think a hybrid
> system where sometimes it is inside the file and sometimes it is based on
> the directories is not desirable from a maintenance perspective.
>
>   But if we think of source files as possibly living in multiple
> "components" simultaneously (like code for a viewer and for HDF5) then as
> we talked about recently maybe all this information just needs to be
> imbedded in the file.
>
> >
> > And wrt moving include files [I'm not sure if this alternate doc system
> really requires this move of include files, but maybe it helps in
> separating the modules better?] - we shouldn't use PETSC_DIR/include anymore
> >
> > They should go into PETSC_DIR/PETSC_ARCH/include (at configure step) -
> and be in sync with --prefix organization.
>
>   Maybe, one advantage of this approach is exactly those links for the
> configuration are set and not all of them (for example includes specific to
> external packages like hdf5) but I am not sure this is important enough to
> be a better system than just having git repository links for all of them.
> For application code portability there may be something said for always
> having all the includes visible to user code, even those not usable so
> users don't need to protect "optional" PETSc includes with ugly ifdef.
>

I do not think the headers are worth moving. If we improve the source
discipline a little, they can be largely autogenerated. We now know all the
declarations that
should be public. There is some other stuff in headers, but very little,
and that probably benefits from being in a specific place like include.

   Matt


>   Barry
>
>
> >
> > Satish
> >
> > On Sun, 20 Sep 2020, Barry Smith wrote:
> >
> >>
> >>  The include directory is special because it contains source code from
> all components of PETSc but artificially collected together in a single
> directory tree because the C/C++/Fortran compilers like it this way to not
> require hundreds of -I and for distribution without the source.
> >>
> >>  Should the PETSc git repository be reorganized where the include files
> in the include directory tree are actually in the appropriate
> subdirectories of src/ and symbolic links are used in the include directory
> tree to point to their locations in  src/ ?
> >>
> >>  In the tarball the include files would be actually in the include
> directory when the tarball is generated.
> >>
> >>  --with-prefix installs will, of course, copy the include files over so
> having them in src does not matter.
> >>
> >>  Does git handle symbolic links nice enough to support this.
> >>
> >>  The reason to make the change is as we move away from having makefiles
> in all the directories with lists of files we need to know the "home
> component" of all the files in the include tree and the natural way to know
> the home is to have the true files in the appropriate src subdirectory.
> >>
> >>  Barry
> >>
> >>
> >>
> >
>
>

-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener

https://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/>

Re: [petsc-dev] Should everything in include be a symbolic link in the git repository?

[Barry Smith]

> On Sep 20, 2020, at 11:54 PM, Satish Balay  wrote:
> 
> For one - the makefiles are primarily used for docs - and the related issue 
> with includes is the binding from MANSEC and SUBMANSEC to the corresponding 
> sourcefiles.
> 
> If the makefiles are removed - and alternate mechanism is need for this [and 
> all other doc targets that use makefiles]. I don't know what this replacement 
> system is - and if that system will be better or more complex then the 
> current system.

  I only see to ways of managing things like MANSEC (which is maybe only for 
docs but tells each source file what component it is associated with so is 
abstractly more than docs). Either we do it based on directories or every 
single source file has inside it this information. I think a hybrid system 
where sometimes it is inside the file and sometimes it is based on the 
directories is not desirable from a maintenance perspective. 

  But if we think of source files as possibly living in multiple "components" 
simultaneously (like code for a viewer and for HDF5) then as we talked about 
recently maybe all this information just needs to be imbedded in the file.

> 
> And wrt moving include files [I'm not sure if this alternate doc system 
> really requires this move of include files, but maybe it helps in separating 
> the modules better?] - we shouldn't use PETSC_DIR/include anymore
> 
> They should go into PETSC_DIR/PETSC_ARCH/include (at configure step) - and be 
> in sync with --prefix organization.

  Maybe, one advantage of this approach is exactly those links for the 
configuration are set and not all of them (for example includes specific to 
external packages like hdf5) but I am not sure this is important enough to be a 
better system than just having git repository links for all of them. For 
application code portability there may be something said for always having all 
the includes visible to user code, even those not usable so users don't need to 
protect "optional" PETSc includes with ugly ifdef.

  Barry


> 
> Satish
> 
> On Sun, 20 Sep 2020, Barry Smith wrote:
> 
>> 
>>  The include directory is special because it contains source code from all 
>> components of PETSc but artificially collected together in a single 
>> directory tree because the C/C++/Fortran compilers like it this way to not 
>> require hundreds of -I and for distribution without the source.
>> 
>>  Should the PETSc git repository be reorganized where the include files in 
>> the include directory tree are actually in the appropriate subdirectories of 
>> src/ and symbolic links are used in the include directory tree to point to 
>> their locations in  src/ ?
>> 
>>  In the tarball the include files would be actually in the include directory 
>> when the tarball is generated.
>> 
>>  --with-prefix installs will, of course, copy the include files over so 
>> having them in src does not matter.
>> 
>>  Does git handle symbolic links nice enough to support this.
>> 
>>  The reason to make the change is as we move away from having makefiles in 
>> all the directories with lists of files we need to know the "home component" 
>> of all the files in the include tree and the natural way to know the home is 
>> to have the true files in the appropriate src subdirectory.
>> 
>>  Barry
>> 
>> 
>> 
> 

Re: [petsc-dev] Should everything in include be a symbolic link in the git repository?

[Satish Balay via petsc-dev]

For one - the makefiles are primarily used for docs - and the related issue 
with includes is the binding from MANSEC and SUBMANSEC to the corresponding 
sourcefiles.

If the makefiles are removed - and alternate mechanism is need for this [and 
all other doc targets that use makefiles]. I don't know what this replacement 
system is - and if that system will be better or more complex then the current 
system.

And wrt moving include files [I'm not sure if this alternate doc system really 
requires this move of include files, but maybe it helps in separating the 
modules better?] - we shouldn't use PETSC_DIR/include anymore

They should go into PETSC_DIR/PETSC_ARCH/include (at configure step) - and be 
in sync with --prefix organization.

Satish

On Sun, 20 Sep 2020, Barry Smith wrote:

> 
>   The include directory is special because it contains source code from all 
> components of PETSc but artificially collected together in a single directory 
> tree because the C/C++/Fortran compilers like it this way to not require 
> hundreds of -I and for distribution without the source.
> 
>   Should the PETSc git repository be reorganized where the include files in 
> the include directory tree are actually in the appropriate subdirectories of 
> src/ and symbolic links are used in the include directory tree to point to 
> their locations in  src/ ?
> 
>   In the tarball the include files would be actually in the include directory 
> when the tarball is generated.
> 
>   --with-prefix installs will, of course, copy the include files over so 
> having them in src does not matter.
> 
>   Does git handle symbolic links nice enough to support this.
> 
>   The reason to make the change is as we move away from having makefiles in 
> all the directories with lists of files we need to know the "home component" 
> of all the files in the include tree and the natural way to know the home is 
> to have the true files in the appropriate src subdirectory.
> 
>   Barry
> 
> 
> 

[petsc-dev] Should everything in include be a symbolic link in the git repository?

[Barry Smith]

  The include directory is special because it contains source code from all 
components of PETSc but artificially collected together in a single directory 
tree because the C/C++/Fortran compilers like it this way to not require 
hundreds of -I and for distribution without the source.

  Should the PETSc git repository be reorganized where the include files in the 
include directory tree are actually in the appropriate subdirectories of src/ 
and symbolic links are used in the include directory tree to point to their 
locations in  src/ ?

  In the tarball the include files would be actually in the include directory 
when the tarball is generated.

  --with-prefix installs will, of course, copy the include files over so having 
them in src does not matter.

  Does git handle symbolic links nice enough to support this.

  The reason to make the change is as we move away from having makefiles in all 
the directories with lists of files we need to know the "home component" of all 
the files in the include tree and the natural way to know the home is to have 
the true files in the appropriate src subdirectory.

  Barry

Re: [petsc-dev] Getting .gitlab.ci file out of repository? https://docs.gitlab.com/ee/ci/pipelines/settings.html

[Barry Smith]

  Yes, if that is our policy, which in seems to have to be, with the GitLab's 
hardwired .gitlab-ci  I have added this, not yet tested or pushed.

  Barry


> On Jun 23, 2020, at 9:58 AM, Satish Balay  wrote:
> 
> BTW: You might want to update petscgitbash to check if a rebase is needed 
> before it starts a test pipeline..
> 
> This might need a modified version of 
> ./lib/petsc/bin/maint/check-ci-settings.sh ['git fetch --unshallow ...' is 
> for the clones created by gitlab-ci]
> 
> Satish
> 
> On Tue, 23 Jun 2020, Satish Balay via petsc-dev wrote:
> 
>> On Tue, 23 Jun 2020, Barry Smith wrote:
>> 
>>> 
>>>   The issue was when a machine went down we suddenly unknowningly had to 
>>> rebase against some strange branch before running the pipeline. That was 
>>> not a good work flow. Perhaps Satish fixed it so master and maint are 
>>> adjusted when a machine goes down hence no strange branches to merge 
>>> against.
>> 
>> This was my attempt to work-around - until I pushed a better tested change 
>> to maint/master. It clearly didn't work. So I pushed my change to maint 
>> [which forced a rebase] - triggering this email thread.
>> 
>> And the issue here is - do you want pipelines to succeed [and be ready for 
>> merge - when some tests are not working and ignored. And when they do come 
>> back - maint/master would be broken.
>> 
>>> 
>>>   I do think a model that "just worked" when a machine went down without 
>>> needing to change the .gitlab-ci file would be better.  If I remember 
>>> vaguely can't every enry in .gitlab-ci be marked as "skip if the runner is 
>>> not available". Can we adopt that model? We may have tried it before and 
>>> were not happy with it?
>> 
>> Then there won't be any test failures per CI - an one would have to check 
>> every failed job manually to verify if should be ignored or nor.
>> 
>> 
>> 
>> One way to do this is with redundancy [of machines - where same test would 
>> work on either machine] - which we don't have for all OSes..
>> 
>> I think saving rebases is the wrong goal here.. Its cheap - its 
>> easy.[compared to other issues], and reorganizing to a more complicated CI 
>> to save this doesn't sound right. And there are many other reasons CI will 
>> change - not just machines going down..
>> 
>> Satish
>> 
>>> 
>>>   Barry
>>> 
>>> 
 On Jun 23, 2020, at 12:19 AM, Jed Brown  wrote:
 
 Satish Balay via petsc-dev  writes:
 
> say - you reorganized some configure code - and changed with-x to with-x11
> 
> This means the corresponding change should also be config/*.py - for 
> tests not to break. [but other branches would still have to use whats 
> valid for them].
> 
> So encoding examples/*.py a single/remote gitlab-ci.yaml just creates 
> more problems
 
 I thought Barry was just proposing inlining the configure options into 
 .gitlab-ci.yml, which I think would work fine, but also don't clearly see 
 a point.
 
> On Mon, 22 Jun 2020, Barry Smith wrote:
> 
>> 
>> I see, the way it is now each test case in the .gitlab file is hardwired 
>> to an examples/*.py maybe we should just delete the examples/*.py and 
>> put them directly in the yaml file.
>>> 
>> 
> 

Re: [petsc-dev] Getting .gitlab.ci file out of repository? https://docs.gitlab.com/ee/ci/pipelines/settings.html

[Satish Balay via petsc-dev]

On Tue, 23 Jun 2020, Satish Balay wrote:

> On Tue, 23 Jun 2020, Satish Balay via petsc-dev wrote:
> 
> > One way to do this is with redundancy [of machines - where same test would 
> > work on either machine] - which we don't have for all OSes..
> 
> Just wanted to add - this was not easy to do even with linux or OSX.. 
> [Windows is a different beast :(]
> 
> With linux:
> 
> -  difference in hardware versions [different gen Intel CPUs] cause PGI test 
> failures [when reusing petsc-hash-packages built on a slightly different 
> version]
> - slight difference in software stack [- even with the same OS/version] 
> causes gcov failures [when reusing petsc-hash-packages built on a slightly 
> different version]
> 
> With OSX - For some reason Apple decides to have slightly different version 
> of compilers on each of the boxes - even though I run updates at the same 
> time..
> 
> balay@sb /home/balay/tmp
> $ ssh ipro clang --version
> Apple clang version 11.0.3 (clang-1103.0.32.62)
> Target: x86_64-apple-darwin19.5.0
> Thread model: posix
> InstalledDir: /Library/Developer/CommandLineTools/usr/bin
> balay@sb /home/balay/tmp
> $ ssh jpro clang --version
> Apple clang version 11.0.3 (clang-1103.0.32.62)
> Target: x86_64-apple-darwin19.5.0
> Thread model: posix
> InstalledDir: 
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
> balay@sb /home/balay/tmp
> $ ssh kpro clang --version
> Apple clang version 11.0.0 (clang-1100.0.33.8)
> Target: x86_64-apple-darwin19.5.0
> Thread model: posix
> InstalledDir: /Library/Developer/CommandLineTools/usr/bin
> balay@sb /home/balay/tmp
> $ 
> 
> And some (opt) test failed (or gave different results?) on of these boxes 
> (jpro).  The other one gets random  errors (kpro)
> 
> So i have some these tests bound to a machine instead of having them float 
> between equivalent machines..
> 
> I guess things can be improved by somehow deploying the exact same hardware, 
> software etc, but then this reduces some of the test coverage.. [for ex: 
> removing various linux OS variants - and using a single  one]
> 
> Different trade-offs that are already represented in current .gitlab-ci.yaml.

The other trade-off:  the more machines for a given build [that don't share NFS 
or a common file system] => less petsc-package-cache reuse [i.e longer builds]

Satish

Re: [petsc-dev] Getting .gitlab.ci file out of repository? https://docs.gitlab.com/ee/ci/pipelines/settings.html

[Satish Balay via petsc-dev]

On Tue, 23 Jun 2020, Satish Balay via petsc-dev wrote:

> One way to do this is with redundancy [of machines - where same test would 
> work on either machine] - which we don't have for all OSes..

Just wanted to add - this was not easy to do even with linux or OSX.. [Windows 
is a different beast :(]

With linux:

-  difference in hardware versions [different gen Intel CPUs] cause PGI test 
failures [when reusing petsc-hash-packages built on a slightly different 
version]
- slight difference in software stack [- even with the same OS/version] causes 
gcov failures [when reusing petsc-hash-packages built on a slightly different 
version]

With OSX - For some reason Apple decides to have slightly different version of 
compilers on each of the boxes - even though I run updates at the same time..

balay@sb /home/balay/tmp
$ ssh ipro clang --version
Apple clang version 11.0.3 (clang-1103.0.32.62)
Target: x86_64-apple-darwin19.5.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
balay@sb /home/balay/tmp
$ ssh jpro clang --version
Apple clang version 11.0.3 (clang-1103.0.32.62)
Target: x86_64-apple-darwin19.5.0
Thread model: posix
InstalledDir: 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
balay@sb /home/balay/tmp
$ ssh kpro clang --version
Apple clang version 11.0.0 (clang-1100.0.33.8)
Target: x86_64-apple-darwin19.5.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
balay@sb /home/balay/tmp
$ 

And some (opt) test failed (or gave different results?) on of these boxes 
(jpro).  The other one gets random  errors (kpro)

So i have some these tests bound to a machine instead of having them float 
between equivalent machines..

I guess things can be improved by somehow deploying the exact same hardware, 
software etc, but then this reduces some of the test coverage.. [for ex: 
removing various linux OS variants - and using a single  one]

Different trade-offs that are already represented in current .gitlab-ci.yaml.

Satish

Re: [petsc-dev] Getting .gitlab.ci file out of repository? https://docs.gitlab.com/ee/ci/pipelines/settings.html

[Satish Balay via petsc-dev]

BTW: You might want to update petscgitbash to check if a rebase is needed 
before it starts a test pipeline..

This might need a modified version of 
./lib/petsc/bin/maint/check-ci-settings.sh ['git fetch --unshallow ...' is for 
the clones created by gitlab-ci]

Satish

On Tue, 23 Jun 2020, Satish Balay via petsc-dev wrote:

> On Tue, 23 Jun 2020, Barry Smith wrote:
> 
> > 
> >The issue was when a machine went down we suddenly unknowningly had to 
> > rebase against some strange branch before running the pipeline. That was 
> > not a good work flow. Perhaps Satish fixed it so master and maint are 
> > adjusted when a machine goes down hence no strange branches to merge 
> > against.
> 
> This was my attempt to work-around - until I pushed a better tested change to 
> maint/master. It clearly didn't work. So I pushed my change to maint [which 
> forced a rebase] - triggering this email thread.
> 
> And the issue here is - do you want pipelines to succeed [and be ready for 
> merge - when some tests are not working and ignored. And when they do come 
> back - maint/master would be broken.
> 
> > 
> >I do think a model that "just worked" when a machine went down without 
> > needing to change the .gitlab-ci file would be better.  If I remember 
> > vaguely can't every enry in .gitlab-ci be marked as "skip if the runner is 
> > not available". Can we adopt that model? We may have tried it before and 
> > were not happy with it?
> 
> Then there won't be any test failures per CI - an one would have to check 
> every failed job manually to verify if should be ignored or nor.
> 
> 
> 
> One way to do this is with redundancy [of machines - where same test would 
> work on either machine] - which we don't have for all OSes..
> 
> I think saving rebases is the wrong goal here.. Its cheap - its 
> easy.[compared to other issues], and reorganizing to a more complicated CI to 
> save this doesn't sound right. And there are many other reasons CI will 
> change - not just machines going down..
> 
> Satish
> 
> > 
> >Barry
> > 
> > 
> > > On Jun 23, 2020, at 12:19 AM, Jed Brown  wrote:
> > > 
> > > Satish Balay via petsc-dev  writes:
> > > 
> > >> say - you reorganized some configure code - and changed with-x to 
> > >> with-x11
> > >> 
> > >> This means the corresponding change should also be config/*.py - for 
> > >> tests not to break. [but other branches would still have to use whats 
> > >> valid for them].
> > >> 
> > >> So encoding examples/*.py a single/remote gitlab-ci.yaml just creates 
> > >> more problems
> > > 
> > > I thought Barry was just proposing inlining the configure options into 
> > > .gitlab-ci.yml, which I think would work fine, but also don't clearly see 
> > > a point.
> > > 
> > >> On Mon, 22 Jun 2020, Barry Smith wrote:
> > >> 
> > >>> 
> > >>>  I see, the way it is now each test case in the .gitlab file is 
> > >>> hardwired to an examples/*.py maybe we should just delete the 
> > >>> examples/*.py and put them directly in the yaml file.
> > 
> 

Re: [petsc-dev] Getting .gitlab.ci file out of repository? https://docs.gitlab.com/ee/ci/pipelines/settings.html

[Satish Balay via petsc-dev]

On Tue, 23 Jun 2020, Barry Smith wrote:

> 
>The issue was when a machine went down we suddenly unknowningly had to 
> rebase against some strange branch before running the pipeline. That was not 
> a good work flow. Perhaps Satish fixed it so master and maint are adjusted 
> when a machine goes down hence no strange branches to merge against.

This was my attempt to work-around - until I pushed a better tested change to 
maint/master. It clearly didn't work. So I pushed my change to maint [which 
forced a rebase] - triggering this email thread.

And the issue here is - do you want pipelines to succeed [and be ready for 
merge - when some tests are not working and ignored. And when they do come back 
- maint/master would be broken.

> 
>I do think a model that "just worked" when a machine went down without 
> needing to change the .gitlab-ci file would be better.  If I remember vaguely 
> can't every enry in .gitlab-ci be marked as "skip if the runner is not 
> available". Can we adopt that model? We may have tried it before and were not 
> happy with it?

Then there won't be any test failures per CI - an one would have to check every 
failed job manually to verify if should be ignored or nor.



One way to do this is with redundancy [of machines - where same test would work 
on either machine] - which we don't have for all OSes..

I think saving rebases is the wrong goal here.. Its cheap - its easy.[compared 
to other issues], and reorganizing to a more complicated CI to save this 
doesn't sound right. And there are many other reasons CI will change - not just 
machines going down..

Satish

> 
>Barry
> 
> 
> > On Jun 23, 2020, at 12:19 AM, Jed Brown  wrote:
> > 
> > Satish Balay via petsc-dev  writes:
> > 
> >> say - you reorganized some configure code - and changed with-x to with-x11
> >> 
> >> This means the corresponding change should also be config/*.py - for tests 
> >> not to break. [but other branches would still have to use whats valid for 
> >> them].
> >> 
> >> So encoding examples/*.py a single/remote gitlab-ci.yaml just creates more 
> >> problems
> > 
> > I thought Barry was just proposing inlining the configure options into 
> > .gitlab-ci.yml, which I think would work fine, but also don't clearly see a 
> > point.
> > 
> >> On Mon, 22 Jun 2020, Barry Smith wrote:
> >> 
> >>> 
> >>>  I see, the way it is now each test case in the .gitlab file is hardwired 
> >>> to an examples/*.py maybe we should just delete the examples/*.py and put 
> >>> them directly in the yaml file.
> 

Re: [petsc-dev] Getting .gitlab.ci file out of repository? https://docs.gitlab.com/ee/ci/pipelines/settings.html

[Barry Smith]

   The issue was when a machine went down we suddenly unknowningly had to 
rebase against some strange branch before running the pipeline. That was not a 
good work flow. Perhaps Satish fixed it so master and maint are adjusted when a 
machine goes down hence no strange branches to merge against.

   I do think a model that "just worked" when a machine went down without 
needing to change the .gitlab-ci file would be better.  If I remember vaguely 
can't every enry in .gitlab-ci be marked as "skip if the runner is not 
available". Can we adopt that model? We may have tried it before and were not 
happy with it?

   Barry


> On Jun 23, 2020, at 12:19 AM, Jed Brown  wrote:
> 
> Satish Balay via petsc-dev  writes:
> 
>> say - you reorganized some configure code - and changed with-x to with-x11
>> 
>> This means the corresponding change should also be config/*.py - for tests 
>> not to break. [but other branches would still have to use whats valid for 
>> them].
>> 
>> So encoding examples/*.py a single/remote gitlab-ci.yaml just creates more 
>> problems
> 
> I thought Barry was just proposing inlining the configure options into 
> .gitlab-ci.yml, which I think would work fine, but also don't clearly see a 
> point.
> 
>> On Mon, 22 Jun 2020, Barry Smith wrote:
>> 
>>> 
>>>  I see, the way it is now each test case in the .gitlab file is hardwired 
>>> to an examples/*.py maybe we should just delete the examples/*.py and put 
>>> them directly in the yaml file.

Re: [petsc-dev] Getting .gitlab.ci file out of repository? https://docs.gitlab.com/ee/ci/pipelines/settings.html

[Jed Brown]

Satish Balay via petsc-dev  writes:

> say - you reorganized some configure code - and changed with-x to with-x11
>
> This means the corresponding change should also be config/*.py - for tests 
> not to break. [but other branches would still have to use whats valid for 
> them].
>
> So encoding examples/*.py a single/remote gitlab-ci.yaml just creates more 
> problems

I thought Barry was just proposing inlining the configure options into 
.gitlab-ci.yml, which I think would work fine, but also don't clearly see a 
point.

> On Mon, 22 Jun 2020, Barry Smith wrote:
>
>> 
>>   I see, the way it is now each test case in the .gitlab file is hardwired 
>> to an examples/*.py maybe we should just delete the examples/*.py and put 
>> them directly in the yaml file.

Re: [petsc-dev] Getting .gitlab.ci file out of repository? https://docs.gitlab.com/ee/ci/pipelines/settings.html

[Satish Balay via petsc-dev]

say - you reorganized some configure code - and changed with-x to with-x11

This means the corresponding change should also be config/*.py - for tests not 
to break. [but other branches would still have to use whats valid for them].

So encoding examples/*.py a single/remote gitlab-ci.yaml just creates more 
problems

Satish

On Mon, 22 Jun 2020, Barry Smith wrote:

> 
>   I see, the way it is now each test case in the .gitlab file is hardwired to 
> an examples/*.py maybe we should just delete the examples/*.py and put them 
> directly in the yaml file.
> 
>   Barry
> 
> 
> > On Jun 22, 2020, at 7:01 PM, Satish Balay  wrote:
> > 
> > An automatic message asking rebase was preferred over other issues we 
> > previously had.
> > 
> > And the examples/arch*.py are in sync with the sources [in branch] and 
> > .gitlab.ci is in sync with examples/arch*.py
> > 
> > And updates to any of them can be done in a feature branch [as feature 
> > changes result in CI changes] - and the merge propagates such changes 
> > nicely [and does force a rebase]
> > 
> > And if they are split up - then we'll have to worry about manually syncing 
> > them  - can't really test changes before doing updates. [and worry about 
> > having a single config file that handles both maint and master.]
> > 
> > However - in some sense - the ability to modify .gitlab.ci in any feature 
> > branch is not a good thing..
> > 
> > Satish
> > 
> > On Mon, 22 Jun 2020, Barry Smith wrote:
> > 
> >> 
> >>   Should we get the .gitlab.ci yaml file out of the repository so people 
> >> don't need to constantly monkey around with rebasing etc when something 
> >> needs to change in the file?
> >> 
> >>   Seems to be number of ways of having out of the repository.
> >> 
> >>   What about the the examples/arch*.py files? Do we have to use the ones 
> >> in the repository? 
> >> 
> >>   Of course we should rebase against master or maint when testing but it 
> >> gets annoying when you did do that but then immediately you have to do it 
> >> again since some test machine when down. Shouldn't really be a concern of 
> >> the developer when test machines go up and down.
> >> 
> >>   Barry
> >> 
> > 
> 

Re: [petsc-dev] Getting .gitlab.ci file out of repository? https://docs.gitlab.com/ee/ci/pipelines/settings.html

[Barry Smith]

  I see, the way it is now each test case in the .gitlab file is hardwired to 
an examples/*.py maybe we should just delete the examples/*.py and put them 
directly in the yaml file.

  Barry


> On Jun 22, 2020, at 7:01 PM, Satish Balay  wrote:
> 
> An automatic message asking rebase was preferred over other issues we 
> previously had.
> 
> And the examples/arch*.py are in sync with the sources [in branch] and 
> .gitlab.ci is in sync with examples/arch*.py
> 
> And updates to any of them can be done in a feature branch [as feature 
> changes result in CI changes] - and the merge propagates such changes nicely 
> [and does force a rebase]
> 
> And if they are split up - then we'll have to worry about manually syncing 
> them  - can't really test changes before doing updates. [and worry about 
> having a single config file that handles both maint and master.]
> 
> However - in some sense - the ability to modify .gitlab.ci in any feature 
> branch is not a good thing..
> 
> Satish
> 
> On Mon, 22 Jun 2020, Barry Smith wrote:
> 
>> 
>>   Should we get the .gitlab.ci yaml file out of the repository so people 
>> don't need to constantly monkey around with rebasing etc when something 
>> needs to change in the file?
>> 
>>   Seems to be number of ways of having out of the repository.
>> 
>>   What about the the examples/arch*.py files? Do we have to use the ones in 
>> the repository? 
>> 
>>   Of course we should rebase against master or maint when testing but it 
>> gets annoying when you did do that but then immediately you have to do it 
>> again since some test machine when down. Shouldn't really be a concern of 
>> the developer when test machines go up and down.
>> 
>>   Barry
>> 
> 

Re: [petsc-dev] Getting .gitlab.ci file out of repository? https://docs.gitlab.com/ee/ci/pipelines/settings.html

[Jed Brown]

If we used the merge_request trigger, it could do the merge automatically and 
thus we wouldn't need to think about this.  (Perhaps we'd put "-o ci.skip" into 
our default push options.)

I don't like the idea of taking it out of the repository; it'd make it much 
harder to reproduce tests from an earlier time.  I think it would create a lot 
of new failure modes.

Satish Balay via petsc-dev  writes:

> An automatic message asking rebase was preferred over other issues we 
> previously had.
>
> And the examples/arch*.py are in sync with the sources [in branch] and 
> .gitlab.ci is in sync with examples/arch*.py
>
> And updates to any of them can be done in a feature branch [as feature 
> changes result in CI changes] - and the merge propagates such changes nicely 
> [and does force a rebase]
>
> And if they are split up - then we'll have to worry about manually syncing 
> them  - can't really test changes before doing updates. [and worry about 
> having a single config file that handles both maint and master.]
>
> However - in some sense - the ability to modify .gitlab.ci in any feature 
> branch is not a good thing..
>
> Satish
>
> On Mon, 22 Jun 2020, Barry Smith wrote:
>
>> 
>>Should we get the .gitlab.ci yaml file out of the repository so people 
>> don't need to constantly monkey around with rebasing etc when something 
>> needs to change in the file?
>> 
>>Seems to be number of ways of having out of the repository.
>> 
>>What about the the examples/arch*.py files? Do we have to use the ones in 
>> the repository? 
>> 
>>Of course we should rebase against master or maint when testing but it 
>> gets annoying when you did do that but then immediately you have to do it 
>> again since some test machine when down. Shouldn't really be a concern of 
>> the developer when test machines go up and down.
>> 
>>Barry
>> 

Re: [petsc-dev] Getting .gitlab.ci file out of repository? https://docs.gitlab.com/ee/ci/pipelines/settings.html

[Satish Balay via petsc-dev]

An automatic message asking rebase was preferred over other issues we 
previously had.

And the examples/arch*.py are in sync with the sources [in branch] and 
.gitlab.ci is in sync with examples/arch*.py

And updates to any of them can be done in a feature branch [as feature changes 
result in CI changes] - and the merge propagates such changes nicely [and does 
force a rebase]

And if they are split up - then we'll have to worry about manually syncing them 
 - can't really test changes before doing updates. [and worry about having a 
single config file that handles both maint and master.]

However - in some sense - the ability to modify .gitlab.ci in any feature 
branch is not a good thing..

Satish

On Mon, 22 Jun 2020, Barry Smith wrote:

> 
>Should we get the .gitlab.ci yaml file out of the repository so people 
> don't need to constantly monkey around with rebasing etc when something needs 
> to change in the file?
> 
>Seems to be number of ways of having out of the repository.
> 
>What about the the examples/arch*.py files? Do we have to use the ones in 
> the repository? 
> 
>Of course we should rebase against master or maint when testing but it 
> gets annoying when you did do that but then immediately you have to do it 
> again since some test machine when down. Shouldn't really be a concern of the 
> developer when test machines go up and down.
> 
>Barry
> 

[petsc-dev] Getting .gitlab.ci file out of repository? https://docs.gitlab.com/ee/ci/pipelines/settings.html

[Barry Smith]

   Should we get the .gitlab.ci yaml file out of the repository so people don't 
need to constantly monkey around with rebasing etc when something needs to 
change in the file?

   Seems to be number of ways of having out of the repository.

   What about the the examples/arch*.py files? Do we have to use the ones in 
the repository? 

   Of course we should rebase against master or maint when testing but it gets 
annoying when you did do that but then immediately you have to do it again 
since some test machine when down. Shouldn't really be a concern of the 
developer when test machines go up and down.

   Barry

Re: [petsc-dev] [petsc-users] IMPORTANT PETSc repository changed from Bucketbit to GitLab

[Balay, Satish via petsc-dev]

On Thu, 5 Sep 2019, Balay, Satish via petsc-dev wrote:

> On Thu, 22 Aug 2019, Balay, Satish via petsc-users wrote:

> All,
> 
> We now have a preliminary CI in place that can process merge requests (MRs) - 
> so please go ahead and submit them.

We have a notice on 'Data Center Outage,  starting 5PM CST on Sep 6 -to 
sometime Sep 9'

So PETSc CI will likely not be working during this time [as (some of) the test 
machines go down] i.e MRs won't get tested during this outage.

Satish

Re: [petsc-dev] [petsc-users] IMPORTANT PETSc repository changed from Bucketbit to GitLab

[Balay, Satish via petsc-dev]

On Thu, 22 Aug 2019, Balay, Satish via petsc-users wrote:

> > 
> > Please do not make pull requests to the Gitlab site yet; we will be 
> > manually processing the PR from the BitBucket site over the next couple of
> > days as we implement the testing.
> > 
> > Please be patient, this is all new to use and it may take a few days to 
> > get out all the glitches.
> 
> Just an update:
> 
> We are still in the process of setting up the CI at gitlab. So we are
> not yet ready to process PRs [or Merge Requests (MRs) in gitlab terminology]
> 
> As of now - we have the old jenkins equivalent [and a few additional]
> tests working with gitlab setup. i.e
> 
> https://gitlab.com/petsc/petsc/pipelines/77669506
> 
> But we are yet to migrate all the regular [aka next] tests to this
> infrastructure.

All,

We now have a preliminary CI in place that can process merge requests (MRs) - 
so please go ahead and submit them.

Satish

Re: [petsc-dev] IMPORTANT PETSc repository changed from Bucketbit to GitLab

[Balay, Satish via petsc-dev]

On Mon, 19 Aug 2019, Smith, Barry F. via petsc-dev wrote:

> 
> 
>PETSc folks.
> 
> This announcement is for people who access PETSc from the BitBucket 
> repository or post issues or have other activities with the Bitbucket 
> repository
> 
>We have changed  the location of the PETSc repository from BitBucket to 
> GitLab. For each copy of the repository you need to do
> 
>git remote set-url origin 
> g...@gitlab.com<mailto:g...@gitlab.com>:petsc/petsc.git
>or
>git remote set-url origin https://gitlab.com/petsc/petsc.git
> 
>You will likely also want to set up an account on gitlab and remember to 
> set the ssh key information
> 
>if you previously had write permission to the petsc repository and cannot 
> write to the new repository please email 
> bsm...@mcs.anl.gov<mailto:bsm...@mcs.anl.gov> with your GitLab
>username and the email used
> 
> Please do not make pull requests to the Gitlab site yet; we will be 
> manually processing the PR from the BitBucket site over the next couple of
> days as we implement the testing.
> 
> Please be patient, this is all new to use and it may take a few days to 
> get out all the glitches.

Just an update:

We are still in the process of setting up the CI at gitlab. So we are
not yet ready to process PRs [or Merge Requests (MRs) in gitlab terminology]

As of now - we have the old jenkins equivalent [and a few additional]
tests working with gitlab setup. i.e

https://gitlab.com/petsc/petsc/pipelines/77669506

But we are yet to migrate all the regular [aka next] tests to this
infrastructure.

Satish


> 
> Thanks for your support
> 
> Barry
> 
>The reason for switching to GitLab is that it has a better testing system 
> than BitBucket and Gitlab. We hope that will allow us to test and manage
>pull requests more rapidly, efficiently and accurately, thus allowing us 
> to improve and add to PETSc more quickly.
> 

Re: [petsc-dev] IMPORTANT PETSc repository changed from Bucketbit to GitLab

[Smith, Barry F. via petsc-dev]

  Great


> On Aug 20, 2019, at 7:22 PM, Fande Kong  wrote:
> 
> Never mind. I updated everything to point to gitlab. Everything looks fine 
> for me now.
> 
> 
> Fande 
> 
>> On Aug 20, 2019, at 6:05 PM, Smith, Barry F.  wrote:
>> 
>> 
>> Is it so difficult for you to change the link in your test system to 
>> petsc-pre-gitlab?
>> 
>> Barry
>> 
>> 
>>> On Aug 20, 2019, at 4:40 PM, Fande Kong via petsc-dev 
>>>  wrote:
>>> 
>>> Any way to have the link https://bitbucket.org/petsc/petsc valid (read 
>>> only) for a couple of weeks?  We have some tests that dynamically picks up 
>>> a particular version of PETSc (master, maint, tag).  The link was removed 
>>> now,  and that disabled us to have daily tests. If we could keep this link 
>>> for a couple of weeks, that will give me a grace period to update all the 
>>> impacted tests. 
>>> 
>>> Any particular reason that we have to rename petsc to petsc-pre-gitlab?
>>> 
>>> Thanks,
>>> 
>>> Fande Kong, 
>>> 
>>> On Tue, Aug 20, 2019 at 2:52 AM Lisandro Dalcin via petsc-dev 
>>>  wrote:
>>> Dear Satish, are you planning to migrate petsc4py?
>>> 
>>> On Mon, 19 Aug 2019 at 23:47, Balay, Satish via petsc-dev 
>>>  wrote:
>>> A note:
>>> 
>>> The bitbucket repository is saved at 
>>> https://bitbucket.org/petsc/petsc-pre-gitlab 
>>> 
>>> The git part is now read-only. The other parts [issues, PRs, wiki etc] are 
>>> perhaps writable - but we should avoid that.
>>> 
>>> Satish
>>> 
>>>> On Mon, 19 Aug 2019, Smith, Barry F. via petsc-dev wrote:
>>>> 
>>>> 
>>>> 
>>>>  PETSc folks.
>>>> 
>>>>   This announcement is for people who access PETSc from the BitBucket 
>>>> repository or post issues or have other activities with the Bitbucket 
>>>> repository
>>>> 
>>>>  We have changed  the location of the PETSc repository from BitBucket to 
>>>> GitLab. For each copy of the repository you need to do
>>>> 
>>>>  git remote set-url origin 
>>>> g...@gitlab.com<mailto:g...@gitlab.com>:petsc/petsc.git
>>>>  or
>>>>  git remote set-url origin https://gitlab.com/petsc/petsc.git
>>>> 
>>>>  You will likely also want to set up an account on gitlab and remember to 
>>>> set the ssh key information
>>>> 
>>>>  if you previously had write permission to the petsc repository and cannot 
>>>> write to the new repository please email 
>>>> bsm...@mcs.anl.gov<mailto:bsm...@mcs.anl.gov> with your GitLab
>>>>  username and the email used
>>>> 
>>>>   Please do not make pull requests to the Gitlab site yet; we will be 
>>>> manually processing the PR from the BitBucket site over the next couple of
>>>>   days as we implement the testing.
>>>> 
>>>>   Please be patient, this is all new to use and it may take a few days to 
>>>> get out all the glitches.
>>>> 
>>>>   Thanks for your support
>>>> 
>>>>   Barry
>>>> 
>>>>  The reason for switching to GitLab is that it has a better testing system 
>>>> than BitBucket and Gitlab. We hope that will allow us to test and manage
>>>>  pull requests more rapidly, efficiently and accurately, thus allowing us 
>>>> to improve and add to PETSc more quickly.
>>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> Lisandro Dalcin
>>> 
>>> Research Scientist
>>> Extreme Computing Research Center (ECRC)
>>> King Abdullah University of Science and Technology (KAUST)
>>> http://ecrc.kaust.edu.sa/
>> 

Re: [petsc-dev] IMPORTANT PETSc repository changed from Bucketbit to GitLab

[Smith, Barry F. via petsc-dev]

  Is it so difficult for you to change the link in your test system to 
petsc-pre-gitlab?

  Barry


> On Aug 20, 2019, at 4:40 PM, Fande Kong via petsc-dev  
> wrote:
> 
> Any way to have the link https://bitbucket.org/petsc/petsc valid (read only) 
> for a couple of weeks?  We have some tests that dynamically picks up a 
> particular version of PETSc (master, maint, tag).  The link was removed now,  
> and that disabled us to have daily tests. If we could keep this link for a 
> couple of weeks, that will give me a grace period to update all the impacted 
> tests. 
> 
> Any particular reason that we have to rename petsc to petsc-pre-gitlab?
> 
> Thanks,
> 
> Fande Kong, 
> 
> On Tue, Aug 20, 2019 at 2:52 AM Lisandro Dalcin via petsc-dev 
>  wrote:
> Dear Satish, are you planning to migrate petsc4py?
> 
> On Mon, 19 Aug 2019 at 23:47, Balay, Satish via petsc-dev 
>  wrote:
> A note:
> 
> The bitbucket repository is saved at 
> https://bitbucket.org/petsc/petsc-pre-gitlab 
> 
> The git part is now read-only. The other parts [issues, PRs, wiki etc] are 
> perhaps writable - but we should avoid that.
> 
> Satish
> 
> On Mon, 19 Aug 2019, Smith, Barry F. via petsc-dev wrote:
> 
> > 
> > 
> >PETSc folks.
> > 
> > This announcement is for people who access PETSc from the BitBucket 
> > repository or post issues or have other activities with the Bitbucket 
> > repository
> > 
> >We have changed  the location of the PETSc repository from BitBucket to 
> > GitLab. For each copy of the repository you need to do
> > 
> >git remote set-url origin 
> > g...@gitlab.com<mailto:g...@gitlab.com>:petsc/petsc.git
> >or
> >git remote set-url origin https://gitlab.com/petsc/petsc.git
> > 
> >You will likely also want to set up an account on gitlab and remember to 
> > set the ssh key information
> > 
> >if you previously had write permission to the petsc repository and 
> > cannot write to the new repository please email 
> > bsm...@mcs.anl.gov<mailto:bsm...@mcs.anl.gov> with your GitLab
> >username and the email used
> > 
> > Please do not make pull requests to the Gitlab site yet; we will be 
> > manually processing the PR from the BitBucket site over the next couple of
> > days as we implement the testing.
> > 
> > Please be patient, this is all new to use and it may take a few days to 
> > get out all the glitches.
> > 
> > Thanks for your support
> > 
> > Barry
> > 
> >The reason for switching to GitLab is that it has a better testing 
> > system than BitBucket and Gitlab. We hope that will allow us to test and 
> > manage
> >pull requests more rapidly, efficiently and accurately, thus allowing us 
> > to improve and add to PETSc more quickly.
> > 
> 
> 
> 
> -- 
> Lisandro Dalcin
> 
> Research Scientist
> Extreme Computing Research Center (ECRC)
> King Abdullah University of Science and Technology (KAUST)
> http://ecrc.kaust.edu.sa/

Re: [petsc-dev] IMPORTANT PETSc repository changed from Bucketbit to GitLab

[Balay, Satish via petsc-dev]

A note:

The bitbucket repository is saved at 
https://bitbucket.org/petsc/petsc-pre-gitlab 

The git part is now read-only. The other parts [issues, PRs, wiki etc] are 
perhaps writable - but we should avoid that.

Satish

On Mon, 19 Aug 2019, Smith, Barry F. via petsc-dev wrote:

> 
> 
>PETSc folks.
> 
> This announcement is for people who access PETSc from the BitBucket 
> repository or post issues or have other activities with the Bitbucket 
> repository
> 
>We have changed  the location of the PETSc repository from BitBucket to 
> GitLab. For each copy of the repository you need to do
> 
>git remote set-url origin 
> g...@gitlab.com<mailto:g...@gitlab.com>:petsc/petsc.git
>or
>git remote set-url origin https://gitlab.com/petsc/petsc.git
> 
>You will likely also want to set up an account on gitlab and remember to 
> set the ssh key information
> 
>if you previously had write permission to the petsc repository and cannot 
> write to the new repository please email 
> bsm...@mcs.anl.gov<mailto:bsm...@mcs.anl.gov> with your GitLab
>username and the email used
> 
> Please do not make pull requests to the Gitlab site yet; we will be 
> manually processing the PR from the BitBucket site over the next couple of
> days as we implement the testing.
> 
> Please be patient, this is all new to use and it may take a few days to 
> get out all the glitches.
> 
> Thanks for your support
> 
> Barry
> 
>The reason for switching to GitLab is that it has a better testing system 
> than BitBucket and Gitlab. We hope that will allow us to test and manage
>pull requests more rapidly, efficiently and accurately, thus allowing us 
> to improve and add to PETSc more quickly.
> 

[petsc-dev] IMPORTANT PETSc repository changed from Bucketbit to GitLab

[Smith, Barry F. via petsc-dev]

   PETSc folks.

This announcement is for people who access PETSc from the BitBucket 
repository or post issues or have other activities with the Bitbucket repository

   We have changed  the location of the PETSc repository from BitBucket to 
GitLab. For each copy of the repository you need to do

   git remote set-url origin 
g...@gitlab.com<mailto:g...@gitlab.com>:petsc/petsc.git
   or
   git remote set-url origin https://gitlab.com/petsc/petsc.git

   You will likely also want to set up an account on gitlab and remember to set 
the ssh key information

   if you previously had write permission to the petsc repository and cannot 
write to the new repository please email 
bsm...@mcs.anl.gov<mailto:bsm...@mcs.anl.gov> with your GitLab
   username and the email used

Please do not make pull requests to the Gitlab site yet; we will be 
manually processing the PR from the BitBucket site over the next couple of
days as we implement the testing.

Please be patient, this is all new to use and it may take a few days to get 
out all the glitches.

Thanks for your support

Barry

   The reason for switching to GitLab is that it has a better testing system 
than BitBucket and Gitlab. We hope that will allow us to test and manage
   pull requests more rapidly, efficiently and accurately, thus allowing us to 
improve and add to PETSc more quickly.

Re: [petsc-dev] including PETSc4py (and Tao4py) inside PETSc repository

[Lisandro Dalcin]

On 26 October 2015 at 01:44, Barry Smith  wrote:
> Maybe someday git will have additional features that allow multiple repos to 
> share things like branches, commits, other stuff? so that having all these 
> packages in different repos is possible, but for now it appears having one 
> repo is just so much dang more convenient.

A final note regarding the subject of this thread: tao4py is part of
petsc4py since TAO was incorporated to PETSc.


-- 
Lisandro Dalcin

Research Scientist
Computer, Electrical and Mathematical Sciences & Engineering (CEMSE)
Numerical Porous Media Center (NumPor)
King Abdullah University of Science and Technology (KAUST)
http://numpor.kaust.edu.sa/

4700 King Abdullah University of Science and Technology
al-Khawarizmi Bldg (Bldg 1), Office # 4332
Thuwal 23955-6900, Kingdom of Saudi Arabia
http://www.kaust.edu.sa

Office Phone: +966 12 808-0459

Re: [petsc-dev] including PETSc4py (and Tao4py) inside PETSc repository

[Lisandro Dalcin]

On 23 October 2015 at 06:30, Barry Smith  wrote:
>
>> On Oct 22, 2015, at 10:24 PM, Satish Balay  wrote:
>>
>> As I said - depending on the precondition for how tightly petsc &
>> petsc4py should be synced - we can choose the appropriate model.
>>
>> [for the metioned precondition - I was suggestion the model].
>>
>> As you say - the initilal phrasing is wrong - so the model is not
>> suitable.
>>
>> A single repo does make it easy for 'all feature branches' to be in
>> sync..
>>
>> In that model with-petsc4py=1 would be the default. However anyone
>> changing the petsc UI would also have to update petsc4py with the
>> change.. [and Lisandro says - that change could be buggy - and he
>> would like to review it -before its applied]
>
>Just like Jed was going to review everything anybody put into PETSc before 
> it got into master. That is just unrealistic and won't last long. Better to 
> just have a good test suite.
>

OK, Barry, I very much understand all your concerns. My opposition to
incorporate petsc4py within petsc is not strong. I agree maintenance
and contribution will be much easier, my concern is just about adding
more and more stuff to the PETSc repo  year over year. If for the case
of petsc4py you think that is not a big issue, then I have to trust
you, it is not easy to catch you on the wrong side ;-).

BTW, I no longer care about keeping petsc4py compatible with previous
PETSc releases. While such approach is workable for pure C code (like
in PetIGA), things get complicated when you add Cython to the stack.

So, let's go ahead and do the merge.




-- 
Lisandro Dalcin

Research Scientist
Computer, Electrical and Mathematical Sciences & Engineering (CEMSE)
Numerical Porous Media Center (NumPor)
King Abdullah University of Science and Technology (KAUST)
http://numpor.kaust.edu.sa/

4700 King Abdullah University of Science and Technology
al-Khawarizmi Bldg (Bldg 1), Office # 4332
Thuwal 23955-6900, Kingdom of Saudi Arabia
http://www.kaust.edu.sa

Office Phone: +966 12 808-0459

Re: [petsc-dev] including PETSc4py (and Tao4py) inside PETSc repository

[Barry Smith]

  Maybe someday git will have additional features that allow multiple repos to 
share things like branches, commits, other stuff? so that having all these 
packages in different repos is possible, but for now it appears having one repo 
is just so much dang more convenient.


> On Oct 25, 2015, at 3:12 AM, Lisandro Dalcin  wrote:
> 
> On 23 October 2015 at 06:30, Barry Smith  wrote:
>> 
>>> On Oct 22, 2015, at 10:24 PM, Satish Balay  wrote:
>>> 
>>> As I said - depending on the precondition for how tightly petsc &
>>> petsc4py should be synced - we can choose the appropriate model.
>>> 
>>> [for the metioned precondition - I was suggestion the model].
>>> 
>>> As you say - the initilal phrasing is wrong - so the model is not
>>> suitable.
>>> 
>>> A single repo does make it easy for 'all feature branches' to be in
>>> sync..
>>> 
>>> In that model with-petsc4py=1 would be the default. However anyone
>>> changing the petsc UI would also have to update petsc4py with the
>>> change.. [and Lisandro says - that change could be buggy - and he
>>> would like to review it -before its applied]
>> 
>>   Just like Jed was going to review everything anybody put into PETSc before 
>> it got into master. That is just unrealistic and won't last long. Better to 
>> just have a good test suite.
>> 
> 
> OK, Barry, I very much understand all your concerns. My opposition to
> incorporate petsc4py within petsc is not strong. I agree maintenance
> and contribution will be much easier, my concern is just about adding
> more and more stuff to the PETSc repo  year over year. If for the case
> of petsc4py you think that is not a big issue, then I have to trust
> you, it is not easy to catch you on the wrong side ;-).
> 
> BTW, I no longer care about keeping petsc4py compatible with previous
> PETSc releases. While such approach is workable for pure C code (like
> in PetIGA), things get complicated when you add Cython to the stack.
> 
> So, let's go ahead and do the merge.
> 
> 
> 
> 
> -- 
> Lisandro Dalcin
> 
> Research Scientist
> Computer, Electrical and Mathematical Sciences & Engineering (CEMSE)
> Numerical Porous Media Center (NumPor)
> King Abdullah University of Science and Technology (KAUST)
> http://numpor.kaust.edu.sa/
> 
> 4700 King Abdullah University of Science and Technology
> al-Khawarizmi Bldg (Bldg 1), Office # 4332
> Thuwal 23955-6900, Kingdom of Saudi Arabia
> http://www.kaust.edu.sa
> 
> Office Phone: +966 12 808-0459

Re: [petsc-dev] including PETSc4py (and Tao4py) inside PETSc repository

[Barry Smith]

   Lisandro,

You never responded to this. I assume it was because you did not like the 
idea? This is not an attempt to take control of petsc4py or to take credit away 
from petsc4py from you. Petsc4py is your package and you will always be the one 
who deserves the credit.

The problem is that mutual efficient development of very intertwined 
packages is difficult if they are in different respositories. For example 
petsc4py has been out of date with petsc master for many weeks now because it 
is too much effort to update the petsc4py repository each time we make some 
change in PETSc. Thus it becomes a burden on you to go in every once in a while 
and fix up petsc4py. With one repository changes would happen in both PETSc 
source and petsc4py source at the same time and tests would detect problems 
immediately.

   Thoughts?

   Barry



> On Sep 22, 2015, at 3:39 PM, Barry Smith <bsm...@mcs.anl.gov> wrote:
> 
> 
>   Lisandro,
> 
>Now that everyone is using git and knows branches well can we move 
> PETSc4py inside the PETSc repository as was done a couple of years ago with 
> BuildSystem. Now when changes/additions are made to PETSc there is a slow 
> inefficient, often forgotten manual process of bringing them over to 
> petsc4py. If we put them all in one repository the updates happen quickly and 
> far more efficiently, as would testing. We'll also get the ability to do 
> bi-section.
> 
>   I realize you want a PETSc4py release to be compatible with previous 
> versions of PETSc; this property could still remain and we could easily have 
> a tool that "pulls out" the petsc4py release material from the petsc 
> repository.
> 
>   I think once we make this change we'll wonder why we didn't do it log ago; 
> just as when we changed BuildSystem.  Thoughts?
> 
>   Thanks
> 
>Barry
> 

Re: [petsc-dev] including PETSc4py (and Tao4py) inside PETSc repository

[Barry Smith]

  Lisandro,

   It is tested nightly but there is apparently currently no email sent on 
failure. See the bottom of, for example, 
http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2015/10/22/make_next_arch-linux-pkgs-opt_crank.log

   I think what should happen is the petsc4py log file should be published to 
the web (like the other log files) and a script look through it and decide to 
send email if it detects a problem. Like we currently have for the other log 
files. Someone has to dig into the nightly test infrastructure to figure out 
where the new logic needs to go. Currently Satish and Karl understand that 
infrastructure the best.

  Barry





> On Oct 22, 2015, at 6:44 PM, Lisandro Dalcin <dalc...@gmail.com> wrote:
> 
> On 22 October 2015 at 23:20, Barry Smith <bsm...@mcs.anl.gov> wrote:
>> 
>>   Lisandro,
>> 
>>You never responded to this. I assume it was because you did not like the 
>> idea? This is not an attempt to take control of petsc4py or to take credit 
>> away from petsc4py from you. Petsc4py is your package and you will always be 
>> the one who deserves the credit.
>> 
> 
> Oh, sorry! I missed this email.
> 
> 
>>The problem is that mutual efficient development of very intertwined 
>> packages is difficult if they are in different respositories. For example 
>> petsc4py has been out of date with petsc master for many weeks now because 
>> it is too much effort to update the petsc4py repository each time we make 
>> some change in PETSc. Thus it becomes a burden on you to go in every once in 
>> a while and fix up petsc4py. With one repository changes would happen in 
>> both PETSc source and petsc4py source at the same time and tests would 
>> detect problems immediately.
>> 
>>   Thoughts?
>> 
> 
> I general terms, I prefer to keep things separate as much a possible.
> IMHO, a much important step would be to incorporate petsc4py to the
> nightly tests, clearly separating the petsc and petsc4py tests runs. I
> would love to get an email every time petsc4py nightly breaks, this
> way I would be able to push fixes within a day or two, say.
> Maintaining petsc4py requires knowledge of PETSc+Python+Cython, so
> ultimately I'm the one in best position to do such work, if you guys
> start adding commits to petsc4py withing the main petsc repo, I'm
> likely going to miss these changes. For example, today Michael Lange
> made some changes, I got an email from Bitbucket, then did a review
> and spotted a few issues.
> 
> My hesitation to incorporate petsc4py within petsc repo is, in
> Python's [and linear algebra :-)] Zen : "Sparse is better than dense".
> If we continue adding stuff to core PETSc, at same point we will endup
> like Trilinos ( DON'T MISS the sencond entry in the FAQ:
> https://trilinos.org/download/public-git-repository/).
> 
> All that being said, I don't have any problem at all adding petsc4py
> to the main PETSc repository. But I still think this is not a good
> idea, it will not solve all the problems. Nightly tests with automatic
> notifications to me about breakages is perhaps is all what we need to
> keep petsc4py in close sync with petsc/master. What about trying this
> first to see how it goes?
> 
> 
> PS: Please understand my position has nothing to do with credits about
> the project or ego-related crap. Actually, your proposal would mean
> less responsibility and maintenance work for me. But I don't think it
> is a move in the right direction.
> 
> 
> -- 
> Lisandro Dalcin
> 
> Research Scientist
> Computer, Electrical and Mathematical Sciences & Engineering (CEMSE)
> Numerical Porous Media Center (NumPor)
> King Abdullah University of Science and Technology (KAUST)
> http://numpor.kaust.edu.sa/
> 
> 4700 King Abdullah University of Science and Technology
> al-Khawarizmi Bldg (Bldg 1), Office # 4332
> Thuwal 23955-6900, Kingdom of Saudi Arabia
> http://www.kaust.edu.sa
> 
> Office Phone: +966 12 808-0459

Re: [petsc-dev] including PETSc4py (and Tao4py) inside PETSc repository

[Lisandro Dalcin]

On 22 October 2015 at 23:20, Barry Smith <bsm...@mcs.anl.gov> wrote:
>
>Lisandro,
>
> You never responded to this. I assume it was because you did not like the 
> idea? This is not an attempt to take control of petsc4py or to take credit 
> away from petsc4py from you. Petsc4py is your package and you will always be 
> the one who deserves the credit.
>

Oh, sorry! I missed this email.


> The problem is that mutual efficient development of very intertwined 
> packages is difficult if they are in different respositories. For example 
> petsc4py has been out of date with petsc master for many weeks now because it 
> is too much effort to update the petsc4py repository each time we make some 
> change in PETSc. Thus it becomes a burden on you to go in every once in a 
> while and fix up petsc4py. With one repository changes would happen in both 
> PETSc source and petsc4py source at the same time and tests would detect 
> problems immediately.
>
>Thoughts?
>

I general terms, I prefer to keep things separate as much a possible.
IMHO, a much important step would be to incorporate petsc4py to the
nightly tests, clearly separating the petsc and petsc4py tests runs. I
would love to get an email every time petsc4py nightly breaks, this
way I would be able to push fixes within a day or two, say.
Maintaining petsc4py requires knowledge of PETSc+Python+Cython, so
ultimately I'm the one in best position to do such work, if you guys
start adding commits to petsc4py withing the main petsc repo, I'm
likely going to miss these changes. For example, today Michael Lange
made some changes, I got an email from Bitbucket, then did a review
and spotted a few issues.

My hesitation to incorporate petsc4py within petsc repo is, in
Python's [and linear algebra :-)] Zen : "Sparse is better than dense".
If we continue adding stuff to core PETSc, at same point we will endup
like Trilinos ( DON'T MISS the sencond entry in the FAQ:
https://trilinos.org/download/public-git-repository/).

All that being said, I don't have any problem at all adding petsc4py
to the main PETSc repository. But I still think this is not a good
idea, it will not solve all the problems. Nightly tests with automatic
notifications to me about breakages is perhaps is all what we need to
keep petsc4py in close sync with petsc/master. What about trying this
first to see how it goes?


PS: Please understand my position has nothing to do with credits about
the project or ego-related crap. Actually, your proposal would mean
less responsibility and maintenance work for me. But I don't think it
is a move in the right direction.


-- 
Lisandro Dalcin

Research Scientist
Computer, Electrical and Mathematical Sciences & Engineering (CEMSE)
Numerical Porous Media Center (NumPor)
King Abdullah University of Science and Technology (KAUST)
http://numpor.kaust.edu.sa/

4700 King Abdullah University of Science and Technology
al-Khawarizmi Bldg (Bldg 1), Office # 4332
Thuwal 23955-6900, Kingdom of Saudi Arabia
http://www.kaust.edu.sa

Office Phone: +966 12 808-0459

Re: [petsc-dev] including PETSc4py (and Tao4py) inside PETSc repository

[Barry Smith]

> On Oct 22, 2015, at 7:28 PM, Satish Balay <ba...@mcs.anl.gov> wrote:
> 
> The current infrastruture tests --download-petsc4py in petsc 'next'
> and 'master' branches.
> 
> Wrt next - usually a change in a feature branch (when it gets merged
> to next) triggers this breakage.  And usual thing to do is to fix it
> in the feature branch (and merge to next again)
> 
> Wrt to petsc4py - this would mean updating petsc4py.py [in petsc] with
> the petsc4py repo gitcommit [optionally also tarball ] that
> corresponds to the fix. [one way to handle this on petsc4py repo is to
> create a feature branch for this fix]

  Yeah this is nuts, having to maintaining matching branches between petsc and 
petsc4py and merge them at the same time into next and then master. Clearly no 
one will ever do this and hence petsc4py will always be out of step from PETSc. 
I do really believe that incorporating petsc4py into PETSc would just make all 
these difficulties go away. For example maintaining Tao is a breeze now since 
it is updated in the same branches as PETSc.

  Barry

> 
> When this (petsc) feature branch is merged into master - the
> corresponding feature branch on the petsc4py side can be merged into
> petsc4py master [if petsc4py-master is to be in sync with
> petsc-master].
> 
> [if there are multiple feature branches on the petsc side requiring
> corresponding petsc4py changes - somehow that has to be handled]
> 
> Perhaps testing petsc4py via petsc infrastructure [using
> --download-petsc4py] is not the appropriate approach?
> 
> Or we should do this only on master - not next?  [or just have a
> single --download-petsc4py test - thats not mixed with other tests? -
> so its breakage is not critical for other things]
> 
> Also we don't currently run any petsc4py tests. [we just test if it
> compiles or not]
> 
> Satish
> 
> On Thu, 22 Oct 2015, Barry Smith wrote:
> 
>> 
>>  Lisandro,
>> 
>>   It is tested nightly but there is apparently currently no email sent on 
>> failure. See the bottom of, for example, 
>> http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2015/10/22/make_next_arch-linux-pkgs-opt_crank.log
>> 
>>   I think what should happen is the petsc4py log file should be published to 
>> the web (like the other log files) and a script look through it and decide 
>> to send email if it detects a problem. Like we currently have for the other 
>> log files. Someone has to dig into the nightly test infrastructure to figure 
>> out where the new logic needs to go. Currently Satish and Karl understand 
>> that infrastructure the best.
>> 
>>  Barry
>> 
>> 
>> 
>> 
>> 
>>> On Oct 22, 2015, at 6:44 PM, Lisandro Dalcin <dalc...@gmail.com> wrote:
>>> 
>>> On 22 October 2015 at 23:20, Barry Smith <bsm...@mcs.anl.gov> wrote:
>>>> 
>>>>  Lisandro,
>>>> 
>>>>   You never responded to this. I assume it was because you did not like 
>>>> the idea? This is not an attempt to take control of petsc4py or to take 
>>>> credit away from petsc4py from you. Petsc4py is your package and you will 
>>>> always be the one who deserves the credit.
>>>> 
>>> 
>>> Oh, sorry! I missed this email.
>>> 
>>> 
>>>>   The problem is that mutual efficient development of very intertwined 
>>>> packages is difficult if they are in different respositories. For example 
>>>> petsc4py has been out of date with petsc master for many weeks now because 
>>>> it is too much effort to update the petsc4py repository each time we make 
>>>> some change in PETSc. Thus it becomes a burden on you to go in every once 
>>>> in a while and fix up petsc4py. With one repository changes would happen 
>>>> in both PETSc source and petsc4py source at the same time and tests would 
>>>> detect problems immediately.
>>>> 
>>>>  Thoughts?
>>>> 
>>> 
>>> I general terms, I prefer to keep things separate as much a possible.
>>> IMHO, a much important step would be to incorporate petsc4py to the
>>> nightly tests, clearly separating the petsc and petsc4py tests runs. I
>>> would love to get an email every time petsc4py nightly breaks, this
>>> way I would be able to push fixes within a day or two, say.
>>> Maintaining petsc4py requires knowledge of PETSc+Python+Cython, so
>>> ultimately I'm the one in best position to do such work, if you guys
>>> start adding commits to petsc4py withing the main petsc repo, I'm
>>> likely going to miss these changes

Re: [petsc-dev] including PETSc4py (and Tao4py) inside PETSc repository

[Barry Smith]

mail.com> wrote:
>>>>> 
>>>>> On 22 October 2015 at 23:20, Barry Smith <bsm...@mcs.anl.gov> wrote:
>>>>>> 
>>>>>> Lisandro,
>>>>>> 
>>>>>>  You never responded to this. I assume it was because you did not like 
>>>>>> the idea? This is not an attempt to take control of petsc4py or to take 
>>>>>> credit away from petsc4py from you. Petsc4py is your package and you 
>>>>>> will always be the one who deserves the credit.
>>>>>> 
>>>>> 
>>>>> Oh, sorry! I missed this email.
>>>>> 
>>>>> 
>>>>>>  The problem is that mutual efficient development of very intertwined 
>>>>>> packages is difficult if they are in different respositories. For 
>>>>>> example petsc4py has been out of date with petsc master for many weeks 
>>>>>> now because it is too much effort to update the petsc4py repository each 
>>>>>> time we make some change in PETSc. Thus it becomes a burden on you to go 
>>>>>> in every once in a while and fix up petsc4py. With one repository 
>>>>>> changes would happen in both PETSc source and petsc4py source at the 
>>>>>> same time and tests would detect problems immediately.
>>>>>> 
>>>>>> Thoughts?
>>>>>> 
>>>>> 
>>>>> I general terms, I prefer to keep things separate as much a possible.
>>>>> IMHO, a much important step would be to incorporate petsc4py to the
>>>>> nightly tests, clearly separating the petsc and petsc4py tests runs. I
>>>>> would love to get an email every time petsc4py nightly breaks, this
>>>>> way I would be able to push fixes within a day or two, say.
>>>>> Maintaining petsc4py requires knowledge of PETSc+Python+Cython, so
>>>>> ultimately I'm the one in best position to do such work, if you guys
>>>>> start adding commits to petsc4py withing the main petsc repo, I'm
>>>>> likely going to miss these changes. For example, today Michael Lange
>>>>> made some changes, I got an email from Bitbucket, then did a review
>>>>> and spotted a few issues.
>>>>> 
>>>>> My hesitation to incorporate petsc4py within petsc repo is, in
>>>>> Python's [and linear algebra :-)] Zen : "Sparse is better than dense".
>>>>> If we continue adding stuff to core PETSc, at same point we will endup
>>>>> like Trilinos ( DON'T MISS the sencond entry in the FAQ:
>>>>> https://trilinos.org/download/public-git-repository/).
>>>>> 
>>>>> All that being said, I don't have any problem at all adding petsc4py
>>>>> to the main PETSc repository. But I still think this is not a good
>>>>> idea, it will not solve all the problems. Nightly tests with automatic
>>>>> notifications to me about breakages is perhaps is all what we need to
>>>>> keep petsc4py in close sync with petsc/master. What about trying this
>>>>> first to see how it goes?
>>>>> 
>>>>> 
>>>>> PS: Please understand my position has nothing to do with credits about
>>>>> the project or ego-related crap. Actually, your proposal would mean
>>>>> less responsibility and maintenance work for me. But I don't think it
>>>>> is a move in the right direction.
>>>>> 
>>>>> 
>>>>> -- 
>>>>> Lisandro Dalcin
>>>>> 
>>>>> Research Scientist
>>>>> Computer, Electrical and Mathematical Sciences & Engineering (CEMSE)
>>>>> Numerical Porous Media Center (NumPor)
>>>>> King Abdullah University of Science and Technology (KAUST)
>>>>> http://numpor.kaust.edu.sa/
>>>>> 
>>>>> 4700 King Abdullah University of Science and Technology
>>>>> al-Khawarizmi Bldg (Bldg 1), Office # 4332
>>>>> Thuwal 23955-6900, Kingdom of Saudi Arabia
>>>>> http://www.kaust.edu.sa
>>>>> 
>>>>> Office Phone: +966 12 808-0459

Re: [petsc-dev] including PETSc4py (and Tao4py) inside PETSc repository

[Barry Smith]

> On Oct 22, 2015, at 10:24 PM, Satish Balay <ba...@mcs.anl.gov> wrote:
> 
> As I said - depending on the precondition for how tightly petsc &
> petsc4py should be synced - we can choose the appropriate model.
> 
> [for the metioned precondition - I was suggestion the model].
> 
> As you say - the initilal phrasing is wrong - so the model is not
> suitable.
> 
> A single repo does make it easy for 'all feature branches' to be in
> sync..
> 
> In that model with-petsc4py=1 would be the default. However anyone
> changing the petsc UI would also have to update petsc4py with the
> change.. [and Lisandro says - that change could be buggy - and he
> would like to review it -before its applied]

   Just like Jed was going to review everything anybody put into PETSc before 
it got into master. That is just unrealistic and won't last long. Better to 
just have a good test suite.

> 
> For 2 repos model - perhaps sync at 'master' might work.
> 
> Satish
> 
> On Thu, 22 Oct 2015, Barry Smith wrote:
> 
>> 
>>> On Oct 22, 2015, at 9:53 PM, Satish Balay <ba...@mcs.anl.gov> wrote:
>>> 
>>> If dmplex with petsc4py is the primary use case [and assuming the
>>> usage is primarily --download-petsc4py] - we chould use the first
>>> model I mentioned - and that should not be too difficult.
>>> 
>>> The workflow would be something like:
>>> 
>>> - Matt would do the updates in petsc/dmplex feature branch & petsc4py
>>> dmplex branches simultaneosusly.
>> 
>>   That's nuts; Matt is a college professor he doesn't have time to keep two 
>> branches in sync for no good reason when they could be in the same 
>> repository.
>> 
>>   Plus other people will be making other changes in PETSc that break petsc4py
>> 
>>   This discussion has shown to me that keeping petsc and petsc4py in 
>> different repositories is just silly and unproductive.
>>> 
>>> - And would always use --download-petsc4py for all his build tests
>>> [we'll have to fix auto-update for --download-pkg for git version of
>>> pkg]
>>> 
>>> - Any isues that come up - Matt will fix in petsc4py/dmplex and update
>>> petsc4py [before this branch is ever merged to next]
>>> 
>>> So after next testing - a merge to master - Matt could issue a pull
>>> requst to Lisandro [or leave it for Lisandro to figureout when
>>> petsc4py-master gets updated with the fix].
>>> 
>>> The update would involve merging/updating petsc4py-master [and and
>>> update to petsc4py.py in petsc-master]
>>> 
>>> [even if this petsc4py-master update doesn't happen immediately] it
>>> won't affect petsc4py/dmplex users as they would be using
>>> --download-petsc4py [which will use the working petsc4py.commitid set
>>> my Matt anyway]
>>> 
>>> If the usage is not via --download-petsc4py - then there could be a
>>> more appropriate workflow for that.. [and a different testsuite to
>>> match that usage..]
>>> 
>>> Satish
>>> 
>>> On Thu, 22 Oct 2015, Barry Smith wrote:
>>> 
>>>> 
>>>> The model we adopt also depends on how cutting edge petsc4py users want to 
>>>> be with petsc. For example if people want to use dmplex with petsc4py then 
>>>> the two packages have to move very closely in sync.
>>>> 
>>>>> On Oct 22, 2015, at 9:11 PM, Satish Balay <ba...@mcs.anl.gov> wrote:
>>>>> 
>>>>> On Thu, 22 Oct 2015, Barry Smith wrote:
>>>>> 
>>>>>> 
>>>>>>> On Oct 22, 2015, at 7:28 PM, Satish Balay <ba...@mcs.anl.gov> wrote:
>>>>>>> 
>>>>>>> The current infrastruture tests --download-petsc4py in petsc 'next'
>>>>>>> and 'master' branches.
>>>>>>> 
>>>>>>> Wrt next - usually a change in a feature branch (when it gets merged
>>>>>>> to next) triggers this breakage.  And usual thing to do is to fix it
>>>>>>> in the feature branch (and merge to next again)
>>>>>>> 
>>>>>>> Wrt to petsc4py - this would mean updating petsc4py.py [in petsc] with
>>>>>>> the petsc4py repo gitcommit [optionally also tarball ] that
>>>>>>> corresponds to the fix. [one way to handle this on petsc4py repo is to
>>>>>>> create a feature branch for this fix]
>>>>>> 
>>>>>> Yeah this is nuts, having to maint

Re: [petsc-dev] including PETSc4py (and Tao4py) inside PETSc repository

[Satish Balay]

On Thu, 22 Oct 2015, Barry Smith wrote:

> 
> > On Oct 22, 2015, at 7:28 PM, Satish Balay <ba...@mcs.anl.gov> wrote:
> > 
> > The current infrastruture tests --download-petsc4py in petsc 'next'
> > and 'master' branches.
> > 
> > Wrt next - usually a change in a feature branch (when it gets merged
> > to next) triggers this breakage.  And usual thing to do is to fix it
> > in the feature branch (and merge to next again)
> > 
> > Wrt to petsc4py - this would mean updating petsc4py.py [in petsc] with
> > the petsc4py repo gitcommit [optionally also tarball ] that
> > corresponds to the fix. [one way to handle this on petsc4py repo is to
> > create a feature branch for this fix]
> 
>   Yeah this is nuts, having to maintaining matching branches between petsc 
> and petsc4py and merge them at the same time into next and then master. 
> Clearly no one will ever do this and hence petsc4py will always be out of 
> step from PETSc. I do really believe that incorporating petsc4py into PETSc 
> would just make all these difficulties go away. For example maintaining Tao 
> is a breeze now since it is updated in the same branches as PETSc.
> 

Perhaps I should rephrase the issue in the following way:

We should decide on what level petsc4py and petsc should be synced.
[and the testsuite should be modified appropriately for that]

Currently its done at next, master branchs. For this to work - the
above - previously mentioned workflow is required. [and for this
workflow - a single repo does makes thing easier]

We could say sync should happen only between petsc4py-master &
petsc-master. [so issues - if any in feature branches/next wont't be
dealt with - and its ok for the master branches to be out of sync for
a brief time for the fix to propergate].

For this - we would have a different workflow [wrt syncing petsc4py
wrt petsc - and a slightly different test suite - testing only
master. [We could continue having the curent test suite - but ignore
errors in next].  And e-mails to Lisandro will trigger only on
petsc4py errors on master.  Lisandro would then fix petsc4py (master)
- and then update petsc4py.py in petsc-master.

Or perhaps some other mode is preferable..

Satish

>   Barry
> 
> > 
> > When this (petsc) feature branch is merged into master - the
> > corresponding feature branch on the petsc4py side can be merged into
> > petsc4py master [if petsc4py-master is to be in sync with
> > petsc-master].
> > 
> > [if there are multiple feature branches on the petsc side requiring
> > corresponding petsc4py changes - somehow that has to be handled]
> > 
> > Perhaps testing petsc4py via petsc infrastructure [using
> > --download-petsc4py] is not the appropriate approach?
> > 
> > Or we should do this only on master - not next?  [or just have a
> > single --download-petsc4py test - thats not mixed with other tests? -
> > so its breakage is not critical for other things]
> > 
> > Also we don't currently run any petsc4py tests. [we just test if it
> > compiles or not]
> > 
> > Satish
> > 
> > On Thu, 22 Oct 2015, Barry Smith wrote:
> > 
> >> 
> >>  Lisandro,
> >> 
> >>   It is tested nightly but there is apparently currently no email sent on 
> >> failure. See the bottom of, for example, 
> >> http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2015/10/22/make_next_arch-linux-pkgs-opt_crank.log
> >> 
> >>   I think what should happen is the petsc4py log file should be published 
> >> to the web (like the other log files) and a script look through it and 
> >> decide to send email if it detects a problem. Like we currently have for 
> >> the other log files. Someone has to dig into the nightly test 
> >> infrastructure to figure out where the new logic needs to go. Currently 
> >> Satish and Karl understand that infrastructure the best.
> >> 
> >>  Barry
> >> 
> >> 
> >> 
> >> 
> >> 
> >>> On Oct 22, 2015, at 6:44 PM, Lisandro Dalcin <dalc...@gmail.com> wrote:
> >>> 
> >>> On 22 October 2015 at 23:20, Barry Smith <bsm...@mcs.anl.gov> wrote:
> >>>> 
> >>>>  Lisandro,
> >>>> 
> >>>>   You never responded to this. I assume it was because you did not like 
> >>>> the idea? This is not an attempt to take control of petsc4py or to take 
> >>>> credit away from petsc4py from you. Petsc4py is your package and you 
> >>>> will always be the one who deserves the credit.
> >>>> 
> >>> 
> >>> Oh, sorry! I missed 

Re: [petsc-dev] including PETSc4py (and Tao4py) inside PETSc repository

[Satish Balay]

As I said - depending on the precondition for how tightly petsc &
petsc4py should be synced - we can choose the appropriate model.

[for the metioned precondition - I was suggestion the model].

As you say - the initilal phrasing is wrong - so the model is not
suitable.

A single repo does make it easy for 'all feature branches' to be in
sync..

In that model with-petsc4py=1 would be the default. However anyone
changing the petsc UI would also have to update petsc4py with the
change.. [and Lisandro says - that change could be buggy - and he
would like to review it -before its applied]

For 2 repos model - perhaps sync at 'master' might work.

Satish

On Thu, 22 Oct 2015, Barry Smith wrote:

> 
> > On Oct 22, 2015, at 9:53 PM, Satish Balay <ba...@mcs.anl.gov> wrote:
> > 
> > If dmplex with petsc4py is the primary use case [and assuming the
> > usage is primarily --download-petsc4py] - we chould use the first
> > model I mentioned - and that should not be too difficult.
> > 
> > The workflow would be something like:
> > 
> > - Matt would do the updates in petsc/dmplex feature branch & petsc4py
> >  dmplex branches simultaneosusly.
> 
>That's nuts; Matt is a college professor he doesn't have time to keep two 
> branches in sync for no good reason when they could be in the same repository.
> 
>Plus other people will be making other changes in PETSc that break petsc4py
> 
>This discussion has shown to me that keeping petsc and petsc4py in 
> different repositories is just silly and unproductive.
> > 
> > - And would always use --download-petsc4py for all his build tests
> > [we'll have to fix auto-update for --download-pkg for git version of
> > pkg]
> > 
> > - Any isues that come up - Matt will fix in petsc4py/dmplex and update
> >  petsc4py [before this branch is ever merged to next]
> > 
> > So after next testing - a merge to master - Matt could issue a pull
> > requst to Lisandro [or leave it for Lisandro to figureout when
> > petsc4py-master gets updated with the fix].
> > 
> > The update would involve merging/updating petsc4py-master [and and
> > update to petsc4py.py in petsc-master]
> > 
> > [even if this petsc4py-master update doesn't happen immediately] it
> > won't affect petsc4py/dmplex users as they would be using
> > --download-petsc4py [which will use the working petsc4py.commitid set
> > my Matt anyway]
> > 
> > If the usage is not via --download-petsc4py - then there could be a
> > more appropriate workflow for that.. [and a different testsuite to
> > match that usage..]
> > 
> > Satish
> > 
> > On Thu, 22 Oct 2015, Barry Smith wrote:
> > 
> >> 
> >>  The model we adopt also depends on how cutting edge petsc4py users want 
> >> to be with petsc. For example if people want to use dmplex with petsc4py 
> >> then the two packages have to move very closely in sync.
> >> 
> >>> On Oct 22, 2015, at 9:11 PM, Satish Balay <ba...@mcs.anl.gov> wrote:
> >>> 
> >>> On Thu, 22 Oct 2015, Barry Smith wrote:
> >>> 
> >>>> 
> >>>>> On Oct 22, 2015, at 7:28 PM, Satish Balay <ba...@mcs.anl.gov> wrote:
> >>>>> 
> >>>>> The current infrastruture tests --download-petsc4py in petsc 'next'
> >>>>> and 'master' branches.
> >>>>> 
> >>>>> Wrt next - usually a change in a feature branch (when it gets merged
> >>>>> to next) triggers this breakage.  And usual thing to do is to fix it
> >>>>> in the feature branch (and merge to next again)
> >>>>> 
> >>>>> Wrt to petsc4py - this would mean updating petsc4py.py [in petsc] with
> >>>>> the petsc4py repo gitcommit [optionally also tarball ] that
> >>>>> corresponds to the fix. [one way to handle this on petsc4py repo is to
> >>>>> create a feature branch for this fix]
> >>>> 
> >>>> Yeah this is nuts, having to maintaining matching branches between petsc 
> >>>> and petsc4py and merge them at the same time into next and then master. 
> >>>> Clearly no one will ever do this and hence petsc4py will always be out 
> >>>> of step from PETSc. I do really believe that incorporating petsc4py into 
> >>>> PETSc would just make all these difficulties go away. For example 
> >>>> maintaining Tao is a breeze now since it is updated in the same branches 
> >>>> as PETSc.
> >>>> 
> >>> 
> >>> Pe

Re: [petsc-dev] including PETSc4py (and Tao4py) inside PETSc repository

[Barry Smith]

> On Oct 22, 2015, at 9:53 PM, Satish Balay <ba...@mcs.anl.gov> wrote:
> 
> If dmplex with petsc4py is the primary use case [and assuming the
> usage is primarily --download-petsc4py] - we chould use the first
> model I mentioned - and that should not be too difficult.
> 
> The workflow would be something like:
> 
> - Matt would do the updates in petsc/dmplex feature branch & petsc4py
>  dmplex branches simultaneosusly.

   That's nuts; Matt is a college professor he doesn't have time to keep two 
branches in sync for no good reason when they could be in the same repository.

   Plus other people will be making other changes in PETSc that break petsc4py

   This discussion has shown to me that keeping petsc and petsc4py in different 
repositories is just silly and unproductive.
> 
> - And would always use --download-petsc4py for all his build tests
> [we'll have to fix auto-update for --download-pkg for git version of
> pkg]
> 
> - Any isues that come up - Matt will fix in petsc4py/dmplex and update
>  petsc4py [before this branch is ever merged to next]
> 
> So after next testing - a merge to master - Matt could issue a pull
> requst to Lisandro [or leave it for Lisandro to figureout when
> petsc4py-master gets updated with the fix].
> 
> The update would involve merging/updating petsc4py-master [and and
> update to petsc4py.py in petsc-master]
> 
> [even if this petsc4py-master update doesn't happen immediately] it
> won't affect petsc4py/dmplex users as they would be using
> --download-petsc4py [which will use the working petsc4py.commitid set
> my Matt anyway]
> 
> If the usage is not via --download-petsc4py - then there could be a
> more appropriate workflow for that.. [and a different testsuite to
> match that usage..]
> 
> Satish
> 
> On Thu, 22 Oct 2015, Barry Smith wrote:
> 
>> 
>>  The model we adopt also depends on how cutting edge petsc4py users want to 
>> be with petsc. For example if people want to use dmplex with petsc4py then 
>> the two packages have to move very closely in sync.
>> 
>>> On Oct 22, 2015, at 9:11 PM, Satish Balay <ba...@mcs.anl.gov> wrote:
>>> 
>>> On Thu, 22 Oct 2015, Barry Smith wrote:
>>> 
>>>> 
>>>>> On Oct 22, 2015, at 7:28 PM, Satish Balay <ba...@mcs.anl.gov> wrote:
>>>>> 
>>>>> The current infrastruture tests --download-petsc4py in petsc 'next'
>>>>> and 'master' branches.
>>>>> 
>>>>> Wrt next - usually a change in a feature branch (when it gets merged
>>>>> to next) triggers this breakage.  And usual thing to do is to fix it
>>>>> in the feature branch (and merge to next again)
>>>>> 
>>>>> Wrt to petsc4py - this would mean updating petsc4py.py [in petsc] with
>>>>> the petsc4py repo gitcommit [optionally also tarball ] that
>>>>> corresponds to the fix. [one way to handle this on petsc4py repo is to
>>>>> create a feature branch for this fix]
>>>> 
>>>> Yeah this is nuts, having to maintaining matching branches between petsc 
>>>> and petsc4py and merge them at the same time into next and then master. 
>>>> Clearly no one will ever do this and hence petsc4py will always be out of 
>>>> step from PETSc. I do really believe that incorporating petsc4py into 
>>>> PETSc would just make all these difficulties go away. For example 
>>>> maintaining Tao is a breeze now since it is updated in the same branches 
>>>> as PETSc.
>>>> 
>>> 
>>> Perhaps I should rephrase the issue in the following way:
>>> 
>>> We should decide on what level petsc4py and petsc should be synced.
>>> [and the testsuite should be modified appropriately for that]
>>> 
>>> Currently its done at next, master branchs. For this to work - the
>>> above - previously mentioned workflow is required. [and for this
>>> workflow - a single repo does makes thing easier]
>>> 
>>> We could say sync should happen only between petsc4py-master &
>>> petsc-master. [so issues - if any in feature branches/next wont't be
>>> dealt with - and its ok for the master branches to be out of sync for
>>> a brief time for the fix to propergate].
>>> 
>>> For this - we would have a different workflow [wrt syncing petsc4py
>>> wrt petsc - and a slightly different test suite - testing only
>>> master. [We could continue having the curent test suite - but ignore
>>> errors in next].  And e-mails to Lisandro will trigger only on
>

Re: [petsc-dev] including PETSc4py (and Tao4py) inside PETSc repository

[Satish Balay]

 testing petsc4py via petsc infrastructure [using
> >>> --download-petsc4py] is not the appropriate approach?
> >>> 
> >>> Or we should do this only on master - not next?  [or just have a
> >>> single --download-petsc4py test - thats not mixed with other tests? -
> >>> so its breakage is not critical for other things]
> >>> 
> >>> Also we don't currently run any petsc4py tests. [we just test if it
> >>> compiles or not]
> >>> 
> >>> Satish
> >>> 
> >>> On Thu, 22 Oct 2015, Barry Smith wrote:
> >>> 
> >>>> 
> >>>> Lisandro,
> >>>> 
> >>>>  It is tested nightly but there is apparently currently no email sent on 
> >>>> failure. See the bottom of, for example, 
> >>>> http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2015/10/22/make_next_arch-linux-pkgs-opt_crank.log
> >>>> 
> >>>>  I think what should happen is the petsc4py log file should be published 
> >>>> to the web (like the other log files) and a script look through it and 
> >>>> decide to send email if it detects a problem. Like we currently have for 
> >>>> the other log files. Someone has to dig into the nightly test 
> >>>> infrastructure to figure out where the new logic needs to go. Currently 
> >>>> Satish and Karl understand that infrastructure the best.
> >>>> 
> >>>> Barry
> >>>> 
> >>>> 
> >>>> 
> >>>> 
> >>>> 
> >>>>> On Oct 22, 2015, at 6:44 PM, Lisandro Dalcin <dalc...@gmail.com> wrote:
> >>>>> 
> >>>>> On 22 October 2015 at 23:20, Barry Smith <bsm...@mcs.anl.gov> wrote:
> >>>>>> 
> >>>>>> Lisandro,
> >>>>>> 
> >>>>>>  You never responded to this. I assume it was because you did not like 
> >>>>>> the idea? This is not an attempt to take control of petsc4py or to 
> >>>>>> take credit away from petsc4py from you. Petsc4py is your package and 
> >>>>>> you will always be the one who deserves the credit.
> >>>>>> 
> >>>>> 
> >>>>> Oh, sorry! I missed this email.
> >>>>> 
> >>>>> 
> >>>>>>  The problem is that mutual efficient development of very intertwined 
> >>>>>> packages is difficult if they are in different respositories. For 
> >>>>>> example petsc4py has been out of date with petsc master for many weeks 
> >>>>>> now because it is too much effort to update the petsc4py repository 
> >>>>>> each time we make some change in PETSc. Thus it becomes a burden on 
> >>>>>> you to go in every once in a while and fix up petsc4py. With one 
> >>>>>> repository changes would happen in both PETSc source and petsc4py 
> >>>>>> source at the same time and tests would detect problems immediately.
> >>>>>> 
> >>>>>> Thoughts?
> >>>>>> 
> >>>>> 
> >>>>> I general terms, I prefer to keep things separate as much a possible.
> >>>>> IMHO, a much important step would be to incorporate petsc4py to the
> >>>>> nightly tests, clearly separating the petsc and petsc4py tests runs. I
> >>>>> would love to get an email every time petsc4py nightly breaks, this
> >>>>> way I would be able to push fixes within a day or two, say.
> >>>>> Maintaining petsc4py requires knowledge of PETSc+Python+Cython, so
> >>>>> ultimately I'm the one in best position to do such work, if you guys
> >>>>> start adding commits to petsc4py withing the main petsc repo, I'm
> >>>>> likely going to miss these changes. For example, today Michael Lange
> >>>>> made some changes, I got an email from Bitbucket, then did a review
> >>>>> and spotted a few issues.
> >>>>> 
> >>>>> My hesitation to incorporate petsc4py within petsc repo is, in
> >>>>> Python's [and linear algebra :-)] Zen : "Sparse is better than dense".
> >>>>> If we continue adding stuff to core PETSc, at same point we will endup
> >>>>> like Trilinos ( DON'T MISS the sencond entry in the FAQ:
> >>>>> https://trilinos.org/download/public-git-repository/).
> >>>>> 
> >>>>> All that being said, I don't have any problem at all adding petsc4py
> >>>>> to the main PETSc repository. But I still think this is not a good
> >>>>> idea, it will not solve all the problems. Nightly tests with automatic
> >>>>> notifications to me about breakages is perhaps is all what we need to
> >>>>> keep petsc4py in close sync with petsc/master. What about trying this
> >>>>> first to see how it goes?
> >>>>> 
> >>>>> 
> >>>>> PS: Please understand my position has nothing to do with credits about
> >>>>> the project or ego-related crap. Actually, your proposal would mean
> >>>>> less responsibility and maintenance work for me. But I don't think it
> >>>>> is a move in the right direction.
> >>>>> 
> >>>>> 
> >>>>> -- 
> >>>>> Lisandro Dalcin
> >>>>> 
> >>>>> Research Scientist
> >>>>> Computer, Electrical and Mathematical Sciences & Engineering (CEMSE)
> >>>>> Numerical Porous Media Center (NumPor)
> >>>>> King Abdullah University of Science and Technology (KAUST)
> >>>>> http://numpor.kaust.edu.sa/
> >>>>> 
> >>>>> 4700 King Abdullah University of Science and Technology
> >>>>> al-Khawarizmi Bldg (Bldg 1), Office # 4332
> >>>>> Thuwal 23955-6900, Kingdom of Saudi Arabia
> >>>>> http://www.kaust.edu.sa
> >>>>> 
> >>>>> Office Phone: +966 12 808-0459
> 
> 

[petsc-dev] including PETSc4py (and Tao4py) inside PETSc repository

[Barry Smith]

   Lisandro,

Now that everyone is using git and knows branches well can we move PETSc4py 
inside the PETSc repository as was done a couple of years ago with BuildSystem. 
Now when changes/additions are made to PETSc there is a slow inefficient, often 
forgotten manual process of bringing them over to petsc4py. If we put them all 
in one repository the updates happen quickly and far more efficiently, as would 
testing. We'll also get the ability to do bi-section.

   I realize you want a PETSc4py release to be compatible with previous 
versions of PETSc; this property could still remain and we could easily have a 
tool that "pulls out" the petsc4py release material from the petsc repository.

   I think once we make this change we'll wonder why we didn't do it log ago; 
just as when we changed BuildSystem.  Thoughts?

   Thanks

Barry

Re: [petsc-dev] plex crap in the repository

[Tobin Isaac]

On Mon, Feb 23, 2015 at 11:39:38AM -0600, Barry Smith wrote:
 
 /Users/barrysmith/Src/PETSc/arch-debug/bin/mpicc -o ex3.o -c -fPIC -Wall 
 -Wwrite-strings -Wno-strict-aliasing -Wno-unknown-pragmas -g3 -O0   
 -I/Users/barrysmith/Src/PETSc/include 
 -I/Users/barrysmith/Src/PETSc/arch-debug/include -I/opt/X11/include
 `pwd`/ex3.c
 /Users/barrysmith/Src/petsc/src/dm/impls/plex/examples/tests/ex3.c:363:111: 
 warning: variable 'aDof' is uninitialized when used here [-Wuninitialized]
   if (cDof != 1) SETERRQ1(PETSC_COMM_SELF,PETSC_ERR_PLIB,Found %d 
 anchor points: should be just one,aDof);
   
 ^~~~
 
 What kind of terrible compiler are you using that doesn't flag this stuff?
 

Fixed in master, merged into next.

  Toby


signature.asc
Description: Digital signature

[petsc-dev] dos endings getting into git repository

[Barry Smith]

 Jed,

https://help.github.com/articles/dealing-with-line-endings/

 I think we need a .gitattributes to fix this. Since a bunch of dos files have 
crept into the repository

  Barry

[petsc-dev] questions on Tao integration into PETSc repository

[Barry Smith]

   I’ve made a lot of progress in processing tao source to PETSc coding 
standards in the branch balay/tao-to-petsc 

   But now I have some observations/questions

   tao.h just includes petsc.h

TaoInitialize/Finalize() basically calls PetscInitialize/Finalize

   The single abstract Tao solver object is called TaoSolve  and is defined in 
taosolver.h
  However all methods on the TaoSolver are prefixed with only Tao, for 
example TaoSetXXX()

   The single abstract Tao line search object is called TaoLineSearch  and is 
defined in taolinesearch.h 

   With everyone’s permission I would like to 

 1) remove TaoInitialize/Finalize()

 2) rename the TaoSolver object to Tao

 3) move the taosolver.h include to tao.h

   With this change Tao will be name-spaced and appear in the same character as 
SNES does

   Do I have everyone’s agreement to make these changes? Other suggestions?

   Thanks

   Barry

Re: [petsc-dev] questions on Tao integration into PETSc repository

[Geoffrey Irving]

On Wed, Jan 29, 2014 at 7:29 PM, Barry Smith bsm...@mcs.anl.gov wrote:

I've made a lot of progress in processing tao source to PETSc coding 
 standards in the branch balay/tao-to-petsc

But now I have some observations/questions

tao.h just includes petsc.h

 TaoInitialize/Finalize() basically calls PetscInitialize/Finalize

The single abstract Tao solver object is called TaoSolve  and is defined 
 in taosolver.h
   However all methods on the TaoSolver are prefixed with only Tao, 
 for example TaoSetXXX()

The single abstract Tao line search object is called TaoLineSearch  and is 
 defined in taolinesearch.h

With everyone's permission I would like to

  1) remove TaoInitialize/Finalize()

  2) rename the TaoSolver object to Tao

  3) move the taosolver.h include to tao.h

With this change Tao will be name-spaced and appear in the same character 
 as SNES does

Do I have everyone's agreement to make these changes? Other suggestions?

Thanks

Barry

This may be outside of the desired scope of changes, but would it be
possible to remove the two-level option structure imposed by Tao for
ksps and preconditioners?  E.g., currently to specify minres, one does

-tao_nls_ksp_type petsc -ksp_type minres

Is there a reason the namespace can't be flattened?  Possibly more
unreasonably, is there a need for TaoLineSearch to be distinct from
SNESLineSearch?

Geoffrey

Re: [petsc-dev] questions on Tao integration into PETSc repository

[Jed Brown]

Geoffrey Irving irv...@naml.us writes:
 This may be outside of the desired scope of changes, but would it be
 possible to remove the two-level option structure imposed by Tao for
 ksps and preconditioners?  E.g., currently to specify minres, one does

 -tao_nls_ksp_type petsc -ksp_type minres

 Is there a reason the namespace can't be flattened?  

Agreed.

 Possibly more unreasonably, is there a need for TaoLineSearch to be
 distinct from SNESLineSearch?

They really should be, but I think we should merge Tao to 'master'
before digging into that.  Is Tao going to be part of the petsc-3.5
release?  How should we warn about interfaces that are likely to change?


pgp_0osk3pulu.pgp
Description: PGP signature

Re: [petsc-dev] branches in the git repository

[Barry Smith]

  1) this syntax is absurd

  2) it don’t work

git push origin :barry/fix-get-create
error: unable to delete 'barry/fix-get-create': remote ref does not exist
error: failed to push some refs to 'g...@bitbucket.org:petsc/petsc.git'
~/Src/petsc  master $ git branch -a | grep fix-get-create
  remotes/origin/barry/fix-get-create


On Dec 10, 2013, at 12:07 AM, Jed Brown jedbr...@mcs.anl.gov wrote:

 
 If you want to delete a branch on the server, use
 
 $ git push origin :barry/fix-get-create

Re: [petsc-dev] branches in the git repository

[Jed Brown]

git fetch --prune

And read that syntax as pushing nothing to the remote branch.

Barry Smith bsm...@mcs.anl.gov wrote:

  1) this syntax is absurd

  2) it don’t work

git push origin :barry/fix-get-create
error: unable to delete 'barry/fix-get-create': remote ref does not
exist
error: failed to push some refs to 'g...@bitbucket.org:petsc/petsc.git'
~/Src/petsc  master $ git branch -a | grep fix-get-create
  remotes/origin/barry/fix-get-create


On Dec 10, 2013, at 12:07 AM, Jed Brown jedbr...@mcs.anl.gov wrote:

 
 If you want to delete a branch on the server, use
 
 $ git push origin :barry/fix-get-create

Re: [petsc-dev] branches in the git repository

[Satish Balay]

I've been using

git remote prune origin

satish

On Wed, 11 Dec 2013, Jed Brown wrote:

 git fetch --prune
 
 And read that syntax as pushing nothing to the remote branch.
 
 Barry Smith bsm...@mcs.anl.gov wrote:
 
   1) this syntax is absurd
 
   2) it don’t work
 
 git push origin :barry/fix-get-create
 error: unable to delete 'barry/fix-get-create': remote ref does not
 exist
 error: failed to push some refs to 'g...@bitbucket.org:petsc/petsc.git'
 ~/Src/petsc  master $ git branch -a | grep fix-get-create
   remotes/origin/barry/fix-get-create
 
 
 On Dec 10, 2013, at 12:07 AM, Jed Brown jedbr...@mcs.anl.gov wrote:
 
  
  If you want to delete a branch on the server, use
  
  $ git push origin :barry/fix-get-create
 
 

Re: [petsc-dev] branches in the git repository

[Matthew Knepley]

On Tue, Dec 10, 2013 at 12:07 AM, Jed Brown jedbr...@mcs.anl.gov wrote:

 Barry Smith bsm...@mcs.anl.gov writes:

 We need a way to organize the “intent” of branches in the
 repository. Are they throw away tests, long term projects, simple
 fixes meant to go into next/master soon ….

 Usually I either refrain from pushing throw-away stuff or totally
 incomplete stuff (though sometimes I just name that 'jed/wip-xyz').


I think the names work if we are consistent. I am using 'fix', 'feature',
'remove'.


 Now aside from the names how do we know the intent and history? I’m
 finding branches of mine that should have been merged into next
 months ago and are now so far behind they need to be discarded
 since they cannot be merged.

 You should still be able to rebase them.


Or just merge in master.


   Plus how come no mater how many times and ways I try to delete
   origin/barry/fix-get-create I cannot get rid of it?

 If you want to delete a branch on the server, use

 $ git push origin :barry/fix-get-create


Someone needs to hang for this one.

   Matt

-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener

[petsc-dev] branches in the git repository

[Barry Smith]

   We need a way to organize the “intent” of branches in the repository. Are 
they throw away tests, long term projects, simple fixes meant to go into 
next/master soon …. 

   Now aside from the names how do we know the intent and history? I’m finding 
branches of mine that should have been merged into next months ago and are now 
so far behind they need to be discarded since they cannot be merged.

   Barry

 Plus how come no mater how many times and ways I try to delete 
origin/barry/fix-get-create  I cannot get rid of it?

Re: [petsc-dev] branches in the git repository

[Jed Brown]

Barry Smith bsm...@mcs.anl.gov writes:

We need a way to organize the “intent” of branches in the
repository. Are they throw away tests, long term projects, simple
fixes meant to go into next/master soon ….

Usually I either refrain from pushing throw-away stuff or totally
incomplete stuff (though sometimes I just name that 'jed/wip-xyz').

Now aside from the names how do we know the intent and history? I’m
finding branches of mine that should have been merged into next
months ago and are now so far behind they need to be discarded
since they cannot be merged.

You should still be able to rebase them.

  Plus how come no mater how many times and ways I try to delete
  origin/barry/fix-get-create I cannot get rid of it?

If you want to delete a branch on the server, use

$ git push origin :barry/fix-get-create


pgpz0eeWG68PS.pgp
Description: PGP signature

[petsc-dev] next broken no DMPlexGetCoordinateSection() in next repository

[Barry Smith]

next builds fail  no DMPlexGetCoordinateSection() in next repository

Re: [petsc-dev] request for a petsc4py repository on bitbucket.org

[Satish Balay]

created https://bitbucket.org/petsc/petsc4py [hg repo] which you can
push to.

I've also added you and Lisandro as admins - so you can modify the
access control list appropriately.

Satish

On Wed, 7 Aug 2013, Aron Ahmadia wrote:

 Hi Team,
 
 Lisandro and I would like to move petsc4py hosting over from Google Code
 hosting to a repository on BitBucket under the petsc URL.  Lisandro is
 currently a member with push access.  I'm requesting that the petsc4py
 repository be created and commit writes granted to me/Lisandro.
 
 My user account on bitbucket is ahmadia
 
 Thanks,
 Aron
 

Re: [petsc-dev] [petsc-maint] Who fucked up the repository?

[Jed Brown]

Matthew Knepley knep...@gmail.com writes:

 On Sat, Jun 15, 2013 at 10:44 PM, Karl Rupp r...@mcs.anl.gov wrote:

 Hey,


  1) I ran the push again, even after issuing the command above, and still
 got the same error

 
  2) How do I update my copy of 3.4.1? I pulled every branch and did a
 fetch.
 

 Did you try `git pull --tags` and/or `git fetch --tags`?


 Yes, that worked. I cannot understand why this tag was different from all
 the others.

Satish explained this in the other mail.  We should use annotated
(preferably signed) tags for release tags since it makes 'git describe'
do the right thing without options and because it makes it faster to
check tags in another clone of PETSc (versus manually comparing SHA1).

[petsc-dev] Who fucked up the repository?

[Matthew Knepley]

I get this every time I try to push a branch:

git -c diff.mnemonicprefix=false -c core.quotepath=false push -v --tags
origin knepley/pylith:knepley/pylith

Pushing to g...@bitbucket.org:petsc/petsc

To g...@bitbucket.org:petsc/petsc

 = [up to date]  v2.0.29 - v2.0.29

 = [up to date]  v2.1.0 - v2.1.0

 = [up to date]  v2.3.2 - v2.3.2

 = [up to date]  v2.3.3 - v2.3.3

 = [up to date]  v3.0.0 - v3.0.0

 = [up to date]  v3.1 - v3.1

 = [up to date]  v3.2 - v3.2

 = [up to date]  v3.3 - v3.3

 = [up to date]  v3.4 - v3.4

   3d2e007..e4fc00d  knepley/pylith - knepley/pylith

 ! [rejected]v3.4.1 - v3.4.1 (non-fast-forward)

updating local tracking ref 'refs/remotes/origin/knepley/pylith'

error: failed to push some refs to 'g...@bitbucket.org:petsc/petsc'

hint: Updates were rejected because a pushed branch tip is behind its remote

hint: counterpart. Check out this branch and merge the remote changes

hint: (e.g. 'git pull') before pushing again.

hint: See the 'Note about fast-forwards' in 'git push --help' for details.

Completed with errors, see above


If I remove --tags, then it works.


   Matt

-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener

Re: [petsc-dev] [petsc-maint] Who fucked up the repository?

[Matthew Knepley]

On Sat, Jun 15, 2013 at 10:36 PM, Karl Rupp r...@mcs.anl.gov wrote:

 Hi Matt,

 did you issue

 $ git config --global push.default simple


Yes, I believe so, but I just did it again.


 as described here:
  
 https://bitbucket.org/petsc/**petsc/wiki/developer-**instructions-githttps://bitbucket.org/petsc/petsc/wiki/developer-instructions-git
 ? It looks like you did not update your working copy of 3.4.1, but try to
 push your local version (the git default). The 'simple' strategy would turn
 this off so that you only push knepley/pylith


1) I ran the push again, even after issuing the command above, and still
got the same error

2) How do I update my copy of 3.4.1? I pulled every branch and did a fetch.

   Matt


 Best regards,
 Karli



 On 06/15/2013 03:23 PM, Matthew Knepley wrote:

 I get this every time I try to push a branch:

 git -c diff.mnemonicprefix=false -c core.quotepath=false push -v --tags
 origin knepley/pylith:knepley/pylith

 Pushing to g...@bitbucket.org:petsc/petsc

 To g...@bitbucket.org:petsc/petsc

   = [up to date]  v2.0.29 - v2.0.29

   = [up to date]  v2.1.0 - v2.1.0

   = [up to date]  v2.3.2 - v2.3.2

   = [up to date]  v2.3.3 - v2.3.3

   = [up to date]  v3.0.0 - v3.0.0

   = [up to date]  v3.1 - v3.1

   = [up to date]  v3.2 - v3.2

   = [up to date]  v3.3 - v3.3

   = [up to date]  v3.4 - v3.4

 3d2e007..e4fc00d  knepley/pylith - knepley/pylith

   ! [rejected]v3.4.1 - v3.4.1 (non-fast-forward)

 updating local tracking ref 'refs/remotes/origin/knepley/**pylith'

 error: failed to push some refs to 'g...@bitbucket.org:petsc/**petsc'

 hint: Updates were rejected because a pushed branch tip is behind its
 remote

 hint: counterpart. Check out this branch and merge the remote changes

 hint: (e.g. 'git pull') before pushing again.

 hint: See the 'Note about fast-forwards' in 'git push --help' for details.

 Completed with errors, see above


 If I remove --tags, then it works.


 Matt


 --
 What most experimenters take for granted before they begin their
 experiments is infinitely more interesting than any results to which
 their experiments lead.
 -- Norbert Wiener





-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener

Re: [petsc-dev] [petsc-maint] Who fucked up the repository?

[Karl Rupp]

Hey,


1) I ran the push again, even after issuing the command above, and still
got the same error


 2) How do I update my copy of 3.4.1? I pulled every branch and did a 
fetch.



Did you try `git pull --tags` and/or `git fetch --tags`?

Best regards,
Karli



Matt

Best regards,
Karli



On 06/15/2013 03:23 PM, Matthew Knepley wrote:

I get this every time I try to push a branch:

git -c diff.mnemonicprefix=false -c core.quotepath=false push -v
--tags
origin knepley/pylith:knepley/pylith

Pushing to g...@bitbucket.org:petsc/petsc

To g...@bitbucket.org:petsc/petsc

   = [up to date]  v2.0.29 - v2.0.29

   = [up to date]  v2.1.0 - v2.1.0

   = [up to date]  v2.3.2 - v2.3.2

   = [up to date]  v2.3.3 - v2.3.3

   = [up to date]  v3.0.0 - v3.0.0

   = [up to date]  v3.1 - v3.1

   = [up to date]  v3.2 - v3.2

   = [up to date]  v3.3 - v3.3

   = [up to date]  v3.4 - v3.4

 3d2e007..e4fc00d  knepley/pylith - knepley/pylith

   ! [rejected]v3.4.1 - v3.4.1 (non-fast-forward)

updating local tracking ref 'refs/remotes/origin/knepley/__pylith'

error: failed to push some refs to 'g...@bitbucket.org:petsc/__petsc'

hint: Updates were rejected because a pushed branch tip is
behind its remote

hint: counterpart. Check out this branch and merge the remote
changes

hint: (e.g. 'git pull') before pushing again.

hint: See the 'Note about fast-forwards' in 'git push --help'
for details.

Completed with errors, see above


If I remove --tags, then it works.


 Matt


--
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which
their experiments lead.
-- Norbert Wiener





--
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which
their experiments lead.
-- Norbert Wiener

Re: [petsc-dev] [petsc-maint] Who fucked up the repository?

[Matthew Knepley]

On Sat, Jun 15, 2013 at 10:44 PM, Karl Rupp r...@mcs.anl.gov wrote:

 Hey,


  1) I ran the push again, even after issuing the command above, and still
 got the same error

 
  2) How do I update my copy of 3.4.1? I pulled every branch and did a
 fetch.
 

 Did you try `git pull --tags` and/or `git fetch --tags`?


Yes, that worked. I cannot understand why this tag was different from all
the others.

   Matt


 Best regards,
 Karli


  Matt

 Best regards,
 Karli



 On 06/15/2013 03:23 PM, Matthew Knepley wrote:

 I get this every time I try to push a branch:

 git -c diff.mnemonicprefix=false -c core.quotepath=false push -v
 --tags
 origin knepley/pylith:knepley/pylith

 Pushing to g...@bitbucket.org:petsc/petsc

 To g...@bitbucket.org:petsc/petsc

= [up to date]  v2.0.29 - v2.0.29

= [up to date]  v2.1.0 - v2.1.0

= [up to date]  v2.3.2 - v2.3.2

= [up to date]  v2.3.3 - v2.3.3

= [up to date]  v3.0.0 - v3.0.0

= [up to date]  v3.1 - v3.1

= [up to date]  v3.2 - v3.2

= [up to date]  v3.3 - v3.3

= [up to date]  v3.4 - v3.4

  3d2e007..e4fc00d  knepley/pylith - knepley/pylith

! [rejected]v3.4.1 - v3.4.1 (non-fast-forward)

 updating local tracking ref 'refs/remotes/origin/knepley/_**
 _pylith'

 error: failed to push some refs to 'g...@bitbucket.org:petsc/__**
 petsc'


 hint: Updates were rejected because a pushed branch tip is
 behind its remote

 hint: counterpart. Check out this branch and merge the remote
 changes

 hint: (e.g. 'git pull') before pushing again.

 hint: See the 'Note about fast-forwards' in 'git push --help'
 for details.

 Completed with errors, see above


 If I remove --tags, then it works.


  Matt


 --
 What most experimenters take for granted before they begin their
 experiments is infinitely more interesting than any results to
 which
 their experiments lead.
 -- Norbert Wiener





 --
 What most experimenters take for granted before they begin their
 experiments is infinitely more interesting than any results to which
 their experiments lead.
 -- Norbert Wiener





-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener

Re: [petsc-dev] [petsc-maint] Who fucked up the repository?

[Satish Balay]

On Sat, 15 Jun 2013, Matthew Knepley wrote:

 On Sat, Jun 15, 2013 at 10:44 PM, Karl Rupp r...@mcs.anl.gov wrote:

  Did you try `git pull --tags` and/or `git fetch --tags`?
 
 Yes, that worked. I cannot understand why this tag was different from all
 the others.

 
  I get this every time I try to push a branch:
 
  git -c diff.mnemonicprefix=false -c core.quotepath=false push -v 
  --tags origin knepley/pylith:knepley/pylith

Hm - any perticular reason for this complicated push command?
[so far I've just been using 'git checkout branch  git push']

Wrt the v3.4.1 tag - the following was a reply from Jed when I spun
the v3.4.1 tarball.

Satish



 Presumably we should start tagging the patch releases aswell?
 git tag v3.4.1

Yes, definitely tag them, but please use an annotated (or better yet,
signed) tag.  I just pushed a signed tag for v3.4.1 (which should
replace your lightweight tag).

Some tools, most notably, 'git describe' need an extra option to use
lightweight tags, probably because they are easy to add accidentally,
and there is no way to figure who did the tagging.  With annotated tags
(which can be signed), you have all that information.

[petsc-dev] WHo the Fuck Broke the Repository

[Matthew Knepley]

remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 2 changesets with 5 changes to 5 files
remote: pushing to ssh://hg at bitbucket.org/petsc/petsc-dev
remote: searching for changes
remote: remote: adding changesets
remote: remote: adding manifests
remote: remote: adding file changes
remote: remote: added 2 changesets with 5 changes to 5 files
remote: remote: transaction abort!
remote: remote: rollback completed
remote: remote: ** unknown exception encountered, please report by visiting
remote: remote: ** http://mercurial.selenic.com/wiki/BugTracker
remote: remote: ** Python 2.7.3 (default, Apr 23 2012, 00:40:27) [GCC 4.4.6
20110731 (Red Hat 4.4.6-3)]
remote: remote: ** Mercurial Distributed SCM (version 2.2.2+11-cab7fc8c33b6)
remote: remote: ** Extensions loaded: convert
remote: remote: Traceback (most recent call last):
remote: remote:   File /opt/python/domains/
bitbucket.org/2012-08-14/bitbucket/local/env/bin/hg, line 38, in module
remote: remote: mercurial.dispatch.run()
remote: remote:   File /opt/python/domains/
bitbucket.org/2012-08-14/bitbucket/local/env/lib/python2.7/site-packages/mercurial/dispatch.py,
line 28, in run
remote: remote: sys.exit((dispatch(request(sys.argv[1:])) or 0)  255)
remote: remote:   File /opt/python/domains/
bitbucket.org/2012-08-14/bitbucket/local/env/lib/python2.7/site-packages/mercurial/dispatch.py,
line 65, in dispatch
remote: remote: return _runcatch(req)
remote: remote:   File /opt/python/domains/
bitbucket.org/2012-08-14/bitbucket/local/env/lib/python2.7/site-packages/mercurial/dispatch.py,
line 88, in _runcatch
remote: remote: return _dispatch(req)
remote: remote:   File /opt/python/domains/
bitbucket.org/2012-08-14/bitbucket/local/env/lib/python2.7/site-packages/mercurial/dispatch.py,
line 739, in _dispatch
remote: remote: cmdpats, cmdoptions)
remote: remote:   File /opt/python/domains/
bitbucket.org/2012-08-14/bitbucket/local/env/lib/python2.7/site-packages/mercurial/dispatch.py,
line 513, in runcommand
remote: remote: ret = _runcommand(ui, options, cmd, d)
remote: remote:   File /opt/python/domains/
bitbucket.org/2012-08-14/bitbucket/local/env/lib/python2.7/site-packages/mercurial/dispatch.py,
line 829, in _runcommand
remote: remote: return checkargs()
remote: remote:   File /opt/python/domains/
bitbucket.org/2012-08-14/bitbucket/local/env/lib/python2.7/site-packages/mercurial/dispatch.py,
line 800, in checkargs
remote: remote: return cmdfunc()
remote: remote:   File /opt/python/domains/
bitbucket.org/2012-08-14/bitbucket/local/env/lib/python2.7/site-packages/mercurial/dispatch.py,
line 736, in lambda
remote: remote: d = lambda: util.checksignature(func)(ui, *args,
**cmdoptions)
remote: remote:   File /opt/python/domains/
bitbucket.org/2012-08-14/bitbucket/local/env/lib/python2.7/site-packages/mercurial/util.py,
line 475, in check
remote: remote: return func(*args, **kwargs)
remote: remote:   File /opt/python/domains/
bitbucket.org/2012-08-14/bitbucket/local/env/lib/python2.7/site-packages/mercurial/commands.py,
line 5045, in serve
remote: remote: s.serve_forever()
remote: remote:   File /opt/python/domains/
bitbucket.org/2012-08-14/bitbucket/local/env/lib/python2.7/site-packages/mercurial/sshserver.py,
line 93, in serve_forever
remote: remote: while self.serve_one():
remote: remote:   File /opt/python/domains/
bitbucket.org/2012-08-14/bitbucket/local/env/lib/python2.7/site-packages/mercurial/sshserver.py,
line 111, in serve_one
remote: remote: rsp = wireproto.dispatch(self.repo, self, cmd)
remote: remote:   File /opt/python/domains/
bitbucket.org/2012-08-14/bitbucket/local/env/lib/python2.7/site-packages/mercurial/wireproto.py,
line 349, in dispatch
remote: remote: return func(repo, proto, *args)
remote: remote:   File /opt/python/domains/
bitbucket.org/2012-08-14/bitbucket/local/env/lib/python2.7/site-packages/mercurial/wireproto.py,
line 588, in unbundle
remote: remote: r = repo.addchangegroup(gen, 'serve', proto._client())
remote: remote:   File /opt/python/domains/
bitbucket.org/2012-08-14/bitbucket/local/env/lib/python2.7/site-packages/mercurial/localrepo.py,
line 2176, in addchangegroup
remote: remote: url=url, pending=p)
remote: remote:   File /opt/python/domains/
bitbucket.org/2012-08-14/bitbucket/local/env/lib/python2.7/site-packages/mercurial/localrepo.py,
line 263, in hook
remote: remote: return hook.hook(self.ui, self, name, throw, **args)
remote: remote:   File /opt/python/domains/
bitbucket.org/2012-08-14/bitbucket/local/env/lib/python2.7/site-packages/mercurial/hook.py,
line 173, in hook
remote: remote: r = _pythonhook(ui, repo, name, hname, hookfn, args,
throw) or r
remote: remote:   File /opt/python/domains/
bitbucket.org/2012-08-14/bitbucket/local/env/lib/python2.7/site-packages/mercurial/hook.py,
line 38, in _pythonhook
remote: remote: obj = __import__(modname)
remote: remote:   File /opt/python/domains/

[petsc-dev] WHo the Fuck Broke the Repository

[Sean Farley]

On Mon, Sep 17, 2012 at 8:14 PM, Matthew Knepley knepley at gmail.com wrote:
 remote: remote:   File
 /opt/python/domains/bitbucket.org/2012-08-14/bitbucket/local/env/lib/python2.7/site-packages/django/conf/__init__.py,
 line 139, in __init__
 remote: remote: logging_config_func(self.LOGGING)
 remote: remote:   File /opt/python/2.7.3/lib/python2.7/logging/config.py,
 line 777, in dictConfig
 remote: remote: dictConfigClass(config).configure()
 remote: remote:   File /opt/python/2.7.3/lib/python2.7/logging/config.py,
 line 575, in configure
 remote: remote: '%r: %s' % (name, e))
 remote: remote: ValueError: Unable to configure handler 'backup': [Errno 13]
 Permission denied:
 '/opt/python/domains/bitbucket.org/current/bitbucket/local/logs/backup.log'
 remote: abort: unexpected response: empty string
 remote: warning: changegroup hook exited with status 255

Hmmm, this seems really weird. Maybe it was a hiccup on the bitbucket
side? Some others have permission denied problems as well:

https://twitter.com/bitbucket/status/247850787089293312

[petsc-dev] WHo the Fuck Broke the Repository

[Matthew Knepley]

On Mon, Sep 17, 2012 at 8:19 PM, Sean Farley sean at mcs.anl.gov wrote:

 On Mon, Sep 17, 2012 at 8:14 PM, Matthew Knepley knepley at gmail.com
 wrote:
  remote: remote:   File
  /opt/python/domains/
 bitbucket.org/2012-08-14/bitbucket/local/env/lib/python2.7/site-packages/django/conf/__init__.py
 ,
  line 139, in __init__
  remote: remote: logging_config_func(self.LOGGING)
  remote: remote:   File
 /opt/python/2.7.3/lib/python2.7/logging/config.py,
  line 777, in dictConfig
  remote: remote: dictConfigClass(config).configure()
  remote: remote:   File
 /opt/python/2.7.3/lib/python2.7/logging/config.py,
  line 575, in configure
  remote: remote: '%r: %s' % (name, e))
  remote: remote: ValueError: Unable to configure handler 'backup': [Errno
 13]
  Permission denied:
  '/opt/python/domains/
 bitbucket.org/current/bitbucket/local/logs/backup.log'
  remote: abort: unexpected response: empty string
  remote: warning: changegroup hook exited with status 255

 Hmmm, this seems really weird. Maybe it was a hiccup on the bitbucket
 side? Some others have permission denied problems as well:

 https://twitter.com/bitbucket/status/247850787089293312


Yep, I pushed again and it was cleaned up.

  Thanks,

 Matt

-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120917/3cc0ed0e/attachment-0001.html

[petsc-dev] WHo the Fuck Broke the Repository

[Sean Farley]

On Mon, Sep 17, 2012 at 8:28 PM, Matthew Knepley knepley at gmail.com wrote:

 Yep, I pushed again and it was cleaned up.

My favorite part about this was that I didn't have to run down to IIT
in the rain to fix it.

[petsc-dev] WHo the Fuck Broke the Repository

[Barry Smith]

On Sep 17, 2012, at 8:38 PM, Sean Farley sean at mcs.anl.gov wrote:

 On Mon, Sep 17, 2012 at 8:28 PM, Matthew Knepley knepley at gmail.com wrote:
 
 Yep, I pushed again and it was cleaned up.
 
 My favorite part about this was that I didn't have to run down to IIT
 in the rain to fix it.

   You don't have a cot down there? 

[petsc-dev] WHo the Fuck Broke the Repository

[Sean Farley]

On Mon, Sep 17, 2012 at 8:43 PM, Barry Smith bsmith at mcs.anl.gov wrote:

You don't have a cot down there?

Oh, right, I forgot about my hammock in the abandoned tunnels.

[petsc-dev] WHo the Fuck Broke the Repository

[Jed Brown]

On Mon, Sep 17, 2012 at 8:45 PM, Sean Farley sean at mcs.anl.gov wrote:

 On Mon, Sep 17, 2012 at 8:43 PM, Barry Smith bsmith at mcs.anl.gov wrote:
 
 You don't have a cot down there?

 Oh, right, I forgot about my hammock in the abandoned tunnels.


hammock  no hammock.

http://www.mountainproject.com/images/97/11/107319711_medium_a1c94e.jpg
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120917/55adaa12/attachment.html

[petsc-dev] WHo the Fuck Broke the Repository

[Sean Farley]

On Mon, Sep 17, 2012 at 8:51 PM, Jed Brown jedbrown at mcs.anl.gov wrote:

 hammock  no hammock.

 http://www.mountainproject.com/images/97/11/107319711_medium_a1c94e.jpg

That's true. I'm able to live off the leftover ramen packs that the
Chinese students leave in the trash.

[petsc-dev] WHo the Fuck Broke the Repository

[Peter Brune]

Alternatively, you could use the discarded cup-of-noodles packaging to
camouflage petsc.cs.iit.edu, obscuring it from the reset-pushing index
fingers of roaming BOFHs.

- Peter

On Mon, Sep 17, 2012 at 9:03 PM, Sean Farley sean at mcs.anl.gov wrote:

 On Mon, Sep 17, 2012 at 8:51 PM, Jed Brown jedbrown at mcs.anl.gov wrote:
 
  hammock  no hammock.
 
  http://www.mountainproject.com/images/97/11/107319711_medium_a1c94e.jpg

 That's true. I'm able to live off the leftover ramen packs that the
 Chinese students leave in the trash.

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120917/a95b979e/attachment.html

[petsc-dev] ctetgen into its own repository

[Barry Smith]

Because of the tetgen license we cannot include ctetgen directly in the 
PETSc tarball.  Thus we have forked it off into its own repository and it is 
available for users as --download-ctetgen   Developers may choose to hg clone 
the repository directly into petsc-dev/externalpackages if they have any need 
to work on the ctetgen source code.


   Barry

[petsc-dev] ctetgen into its own repository

[Barry Smith]

Because of the tetgen license we cannot include ctetgen directly in the 
PETSc tarball.  Thus we have forked it off into its own repository and it is 
available for users as --download-ctetgen   Developers may choose to hg clone 
the repository directly into petsc-dev/externalpackages if they have any need 
to work on the ctetgen source code.


   Barry

[petsc-dev] ctetgen into its own repository

[Matthew Knepley]

On Fri, May 25, 2012 at 4:03 PM, Barry Smith bsmith at mcs.anl.gov wrote:


Because of the tetgen license we cannot include ctetgen directly in the
 PETSc tarball.  Thus we have forked it off into its own repository and it
 is available for users as --download-ctetgen   Developers may choose to hg
 clone the repository directly into petsc-dev/externalpackages if they have
 any need to work on the ctetgen source code.


How can the fucking license say that we cannot include ASCII code is our
goddamn release. What if I
take a picture of the code and include the JPG? I already put in a
configure option to turn it on. This is
ridiculous. Are you sure that we can include the letter P. I think Sesame
Street has rights to that.

Matt



   Barry





-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120525/70db1276/attachment.html

[petsc-dev] ctetgen into its own repository

[Barry Smith]

On May 25, 2012, at 4:02 PM, Matthew Knepley wrote:

 On Fri, May 25, 2012 at 4:03 PM, Barry Smith bsmith at mcs.anl.gov wrote:
 
Because of the tetgen license we cannot include ctetgen directly in the 
 PETSc tarball.  Thus we have forked it off into its own repository and it is 
 available for users as --download-ctetgen   Developers may choose to hg clone 
 the repository directly into petsc-dev/externalpackages if they have any need 
 to work on the ctetgen source code.
 
 How can the fucking license say that we cannot include ASCII code is our 
 goddamn release. What if I
 take a picture of the code and include the JPG? I already put in a configure 
 option to turn it on. This is
 ridiculous. Are you sure that we can include the letter P. I think Sesame 
 Street has rights to that.

  Sarcastic answer:

   I broke into Microsoft headquarters last week and took a copy of the Windows 
8 source code. As a convenience to some of our users I have added it to the 
PETSc source code tree and it will be included in the future releases.

  Unsarcastic answer:

  Yes we can include ctetgen in our release but then we need to change our 
license to be much more restrictive (non-MIT etc) which we do not want. The 
tetgen license doesn't say anything about allowing it under more general 
license  if the compiling of it is optional 

   Barry


 
 Matt
  
 
   Barry
 
 
 
 
 
 -- 
 What most experimenters take for granted before they begin their experiments 
 is infinitely more interesting than any results to which their experiments 
 lead.
 -- Norbert Wiener

Repository

[Matthew Knepley]

I cannot ping petsc.cs.iit.edu. I have a tutorial scheduled for 8:30am and
was planning for everyone to pull and build.

  Matt

-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which
their experiments lead.
-- Norbert Wiener

Repository

[Satish Balay]

Matt,

Looks like the machine is down.

Perhaps everyone can just grab the nightly traball for now..
ftp://info.mcs.anl.gov/pub/petsc/petsc-dev.tar.gz

Satish

On Fri, 18 Jul 2008, Matthew Knepley wrote:

 I cannot ping petsc.cs.iit.edu. I have a tutorial scheduled for 8:30am and
 was planning for everyone to pull and build.
 
   Matt
 
 

Petsc Repository

[Hong Zhang]

Yong,

petsc.cs.iit.edu is back now.
Thanks,

Hong
On Fri, 18 Jul 2008, Hong Zhang wrote:


 Yong,

 Please check if the petsc machine is running?
 Thanks,

 Hong

 On Fri, 18 Jul 2008, Satish Balay wrote:

 Matt,
 
 Looks like the machine is down.
 
 Perhaps everyone can just grab the nightly traball for now..
 ftp://info.mcs.anl.gov/pub/petsc/petsc-dev.tar.gz
 
 Satish
 
 On Fri, 18 Jul 2008, Matthew Knepley wrote:
 
 I cannot ping petsc.cs.iit.edu. I have a tutorial scheduled for 8:30am and
 was planning for everyone to pull and build.

   Matt
 
 
 
 

testing new repository

[Hong Zhang]

Lisandro,

The memory leak occurs for all in-place MatConvert().
I suspect your changes might affect
 MatHeaderReplace() used in the in-place MatConvert().
I have trouble figuring out what causes it.
You might have some clue about it.

Hong

On Sat, 6 Oct 2007, Satish Balay wrote:

 On Fri, 5 Oct 2007, Lisandro Dalcin wrote:

  And please, send me the failures...

 Lisandro,

 I haven't yet checked the nightly builds properly. Some of the issues
 I've been checking were with code already in petsc-dev. [So the
 current checks are from the tests I ran on my laptop]

 Most of the 'strict aliasing' I've seen so far are compile issues with
 sieve and other external pacakges[spooles,superlu_dist,pmetis.c etc..]
 wrt PetscObject usage.

 [so the fix for PetscObject stuff was simple enough for met to do and
 test]. I'm attaching the patch of the changes that worked. Let me know
 if this is ok to commit and push.

 There is also the following memory leak - which I haven't checked
 yet..  Perhaps there is some incorrect reference counting somewhere.

 
 testexamples_C in: /home/balay/tmp/petsc-dalcinl/src/mat/examples/tests
 0a1,10
  [0]Total space allocated 1380 bytes
  [ 0]460 bytes MatCreate() line 80 in src/mat/utils/gcreate.c
[0]  MatConvert_SeqBAIJ_SeqSBAIJ() line 276 in 
  src/mat/impls/sbaij/seq/aijsbaij.c
[0]  MatConvert() line 3142 in src/mat/interface/matrix.c
  [ 0]460 bytes MatCreate() line 80 in src/mat/utils/gcreate.c
[0]  MatDuplicate_SeqBAIJ() line 2448 in src/mat/impls/baij/seq/baij.c
[0]  MatConvert() line 3142 in src/mat/interface/matrix.c
  [ 0]460 bytes MatCreate() line 80 in src/mat/utils/gcreate.c
[0]  MatConvert_SeqBAIJ_SeqAIJ() line 17 in 
  src/mat/impls/baij/seq/aijbaij.c
[0]  MatConvert() line 3142 in src/mat/interface/matrix.c
 Possible problem with ex55_1, diffs above
 52a53,55
  [0]Total space allocated 460 bytes
  [ 0]460 bytes MatCreate() line 80 in src/mat/utils/gcreate.c
[0]  MatCreateSeqAIJ() line 2777 in src/mat/impls/aij/seq/aij.c
 Possible problem with ex114_1, diffs above
 

 Prometheus also nees some PetscObject changes - I can send Mark the
 changes to update the prometheus tarball later..

 thanks,
 Satish

testing new repository

[Lisandro Dalcin]

I'll try to take a look, I think you catched the source. Now
PetscHeaderDestory_Private does not frees the 'ops' member of a mat
structure, as this 'ops' field is not in the base object header. I'll
try to fix this ASAP.



On 10/12/07, Hong Zhang hzhang at mcs.anl.gov wrote:

 Lisandro,

 The memory leak occurs for all in-place MatConvert().
 I suspect your changes might affect
  MatHeaderReplace() used in the in-place MatConvert().
 I have trouble figuring out what causes it.
 You might have some clue about it.

 Hong

 On Sat, 6 Oct 2007, Satish Balay wrote:

  On Fri, 5 Oct 2007, Lisandro Dalcin wrote:
 
   And please, send me the failures...
 
  Lisandro,
 
  I haven't yet checked the nightly builds properly. Some of the issues
  I've been checking were with code already in petsc-dev. [So the
  current checks are from the tests I ran on my laptop]
 
  Most of the 'strict aliasing' I've seen so far are compile issues with
  sieve and other external pacakges[spooles,superlu_dist,pmetis.c etc..]
  wrt PetscObject usage.
 
  [so the fix for PetscObject stuff was simple enough for met to do and
  test]. I'm attaching the patch of the changes that worked. Let me know
  if this is ok to commit and push.
 
  There is also the following memory leak - which I haven't checked
  yet..  Perhaps there is some incorrect reference counting somewhere.
 
  
  testexamples_C in: /home/balay/tmp/petsc-dalcinl/src/mat/examples/tests
  0a1,10
   [0]Total space allocated 1380 bytes
   [ 0]460 bytes MatCreate() line 80 in src/mat/utils/gcreate.c
 [0]  MatConvert_SeqBAIJ_SeqSBAIJ() line 276 in 
   src/mat/impls/sbaij/seq/aijsbaij.c
 [0]  MatConvert() line 3142 in src/mat/interface/matrix.c
   [ 0]460 bytes MatCreate() line 80 in src/mat/utils/gcreate.c
 [0]  MatDuplicate_SeqBAIJ() line 2448 in 
   src/mat/impls/baij/seq/baij.c
 [0]  MatConvert() line 3142 in src/mat/interface/matrix.c
   [ 0]460 bytes MatCreate() line 80 in src/mat/utils/gcreate.c
 [0]  MatConvert_SeqBAIJ_SeqAIJ() line 17 in 
   src/mat/impls/baij/seq/aijbaij.c
 [0]  MatConvert() line 3142 in src/mat/interface/matrix.c
  Possible problem with ex55_1, diffs above
  52a53,55
   [0]Total space allocated 460 bytes
   [ 0]460 bytes MatCreate() line 80 in src/mat/utils/gcreate.c
 [0]  MatCreateSeqAIJ() line 2777 in src/mat/impls/aij/seq/aij.c
  Possible problem with ex114_1, diffs above
  
 
  Prometheus also nees some PetscObject changes - I can send Mark the
  changes to update the prometheus tarball later..
 
  thanks,
  Satish




-- 
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

testing new repository

[Lisandro Dalcin]

Hong, many thanks, you were right. MatHeaderReplace() now needs a
PetscFree() for 'A-ops'. I fixed the problem and pushed.

On 10/12/07, Hong Zhang hzhang at mcs.anl.gov wrote:

 Lisandro,

 The memory leak occurs for all in-place MatConvert().
 I suspect your changes might affect
  MatHeaderReplace() used in the in-place MatConvert().
 I have trouble figuring out what causes it.
 You might have some clue about it.

 Hong

 On Sat, 6 Oct 2007, Satish Balay wrote:

  On Fri, 5 Oct 2007, Lisandro Dalcin wrote:
 
   And please, send me the failures...
 
  Lisandro,
 
  I haven't yet checked the nightly builds properly. Some of the issues
  I've been checking were with code already in petsc-dev. [So the
  current checks are from the tests I ran on my laptop]
 
  Most of the 'strict aliasing' I've seen so far are compile issues with
  sieve and other external pacakges[spooles,superlu_dist,pmetis.c etc..]
  wrt PetscObject usage.
 
  [so the fix for PetscObject stuff was simple enough for met to do and
  test]. I'm attaching the patch of the changes that worked. Let me know
  if this is ok to commit and push.
 
  There is also the following memory leak - which I haven't checked
  yet..  Perhaps there is some incorrect reference counting somewhere.
 
  
  testexamples_C in: /home/balay/tmp/petsc-dalcinl/src/mat/examples/tests
  0a1,10
   [0]Total space allocated 1380 bytes
   [ 0]460 bytes MatCreate() line 80 in src/mat/utils/gcreate.c
 [0]  MatConvert_SeqBAIJ_SeqSBAIJ() line 276 in 
   src/mat/impls/sbaij/seq/aijsbaij.c
 [0]  MatConvert() line 3142 in src/mat/interface/matrix.c
   [ 0]460 bytes MatCreate() line 80 in src/mat/utils/gcreate.c
 [0]  MatDuplicate_SeqBAIJ() line 2448 in 
   src/mat/impls/baij/seq/baij.c
 [0]  MatConvert() line 3142 in src/mat/interface/matrix.c
   [ 0]460 bytes MatCreate() line 80 in src/mat/utils/gcreate.c
 [0]  MatConvert_SeqBAIJ_SeqAIJ() line 17 in 
   src/mat/impls/baij/seq/aijbaij.c
 [0]  MatConvert() line 3142 in src/mat/interface/matrix.c
  Possible problem with ex55_1, diffs above
  52a53,55
   [0]Total space allocated 460 bytes
   [ 0]460 bytes MatCreate() line 80 in src/mat/utils/gcreate.c
 [0]  MatCreateSeqAIJ() line 2777 in src/mat/impls/aij/seq/aij.c
  Possible problem with ex114_1, diffs above
  
 
  Prometheus also nees some PetscObject changes - I can send Mark the
  changes to update the prometheus tarball later..
 
  thanks,
  Satish




-- 
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

testing new repository

[Hong Zhang]

The leak is fixed. Thanks!
Hong

On Fri, 12 Oct 2007, Lisandro Dalcin wrote:

 Hong, many thanks, you were right. MatHeaderReplace() now needs a
 PetscFree() for 'A-ops'. I fixed the problem and pushed.

 On 10/12/07, Hong Zhang hzhang at mcs.anl.gov wrote:
 
  Lisandro,
 
  The memory leak occurs for all in-place MatConvert().
  I suspect your changes might affect
   MatHeaderReplace() used in the in-place MatConvert().
  I have trouble figuring out what causes it.
  You might have some clue about it.
 
  Hong
 
  On Sat, 6 Oct 2007, Satish Balay wrote:
 
   On Fri, 5 Oct 2007, Lisandro Dalcin wrote:
  
And please, send me the failures...
  
   Lisandro,
  
   I haven't yet checked the nightly builds properly. Some of the issues
   I've been checking were with code already in petsc-dev. [So the
   current checks are from the tests I ran on my laptop]
  
   Most of the 'strict aliasing' I've seen so far are compile issues with
   sieve and other external pacakges[spooles,superlu_dist,pmetis.c etc..]
   wrt PetscObject usage.
  
   [so the fix for PetscObject stuff was simple enough for met to do and
   test]. I'm attaching the patch of the changes that worked. Let me know
   if this is ok to commit and push.
  
   There is also the following memory leak - which I haven't checked
   yet..  Perhaps there is some incorrect reference counting somewhere.
  
   
   testexamples_C in: /home/balay/tmp/petsc-dalcinl/src/mat/examples/tests
   0a1,10
[0]Total space allocated 1380 bytes
[ 0]460 bytes MatCreate() line 80 in src/mat/utils/gcreate.c
  [0]  MatConvert_SeqBAIJ_SeqSBAIJ() line 276 in 
src/mat/impls/sbaij/seq/aijsbaij.c
  [0]  MatConvert() line 3142 in src/mat/interface/matrix.c
[ 0]460 bytes MatCreate() line 80 in src/mat/utils/gcreate.c
  [0]  MatDuplicate_SeqBAIJ() line 2448 in 
src/mat/impls/baij/seq/baij.c
  [0]  MatConvert() line 3142 in src/mat/interface/matrix.c
[ 0]460 bytes MatCreate() line 80 in src/mat/utils/gcreate.c
  [0]  MatConvert_SeqBAIJ_SeqAIJ() line 17 in 
src/mat/impls/baij/seq/aijbaij.c
  [0]  MatConvert() line 3142 in src/mat/interface/matrix.c
   Possible problem with ex55_1, diffs above
   52a53,55
[0]Total space allocated 460 bytes
[ 0]460 bytes MatCreate() line 80 in src/mat/utils/gcreate.c
  [0]  MatCreateSeqAIJ() line 2777 in src/mat/impls/aij/seq/aij.c
   Possible problem with ex114_1, diffs above
   
  
   Prometheus also nees some PetscObject changes - I can send Mark the
   changes to update the prometheus tarball later..
  
   thanks,
   Satish
 
 


 --
 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

testing new repository

[Satish Balay]

I pushed petsc-dalcinl to petsc-dev

Satish

testing new repository

[Lisandro Dalcin]

Satish, do you think that the breackages on win32 could be related to
my changes? In that case, please send me the output of the fails to
take a look.

On 10/10/07, Satish Balay balay at mcs.anl.gov wrote:
 Lisandro,

 I checked the nightly builds today and pused fixes for other external
 packages [blocksolve  dscpack].

 Curently I see no compile breakages [related to the strict aliasing
 changes]. There are some win32 breakages and some example breakages
 that need more debugging.

 thanks,
 Satish


 On Mon, 8 Oct 2007, Satish Balay wrote:

  Thanks. I've pushed these changes - and also synced with current
  petsc-dev.




-- 
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

testing new repository

[Satish Balay]

On Wed, 10 Oct 2007, Lisandro Dalcin wrote:

 Satish, do you think that the breackages on win32 could be related to
 my changes? In that case, please send me the output of the fails to
 take a look.

The compile breakages [with gcc] are zope related. There is some wierd
runtime behavior [with ms-c] - this could also be zope related...

satish

testing new repository

[Satish Balay]

Lisandro,

I checked the nightly builds today and pused fixes for other external
packages [blocksolve  dscpack].

Curently I see no compile breakages [related to the strict aliasing
changes]. There are some win32 breakages and some example breakages
that need more debugging.

thanks,
Satish


On Mon, 8 Oct 2007, Satish Balay wrote:

 Thanks. I've pushed these changes - and also synced with current
 petsc-dev.

testing new repository

[Lisandro Dalcin]

Satish, your patch is fine... You catched sources that I did not
checked because I did not have all external packages available to
test.

Please, push this patch to 'petsc-dev-dalcinl', I'll try ASAP to make
more checking and take a look to the memory leak issue.

There are also leaks related to MatMFFD, but I was not able to figure
out the source of the problem yet, this was already on 'petsc-dev' and
I catched it running the full petsc4py unittest suite.

Regards,

On 10/7/07, Satish Balay balay at mcs.anl.gov wrote:
 On Fri, 5 Oct 2007, Lisandro Dalcin wrote:

  And please, send me the failures...

 Lisandro,

 I haven't yet checked the nightly builds properly. Some of the issues
 I've been checking were with code already in petsc-dev. [So the
 current checks are from the tests I ran on my laptop]

 Most of the 'strict aliasing' I've seen so far are compile issues with
 sieve and other external pacakges[spooles,superlu_dist,pmetis.c etc..]
 wrt PetscObject usage.

 [so the fix for PetscObject stuff was simple enough for met to do and
 test]. I'm attaching the patch of the changes that worked. Let me know
 if this is ok to commit and push.

 There is also the following memory leak - which I haven't checked
 yet..  Perhaps there is some incorrect reference counting somewhere.

 
 testexamples_C in: /home/balay/tmp/petsc-dalcinl/src/mat/examples/tests
 0a1,10
  [0]Total space allocated 1380 bytes
  [ 0]460 bytes MatCreate() line 80 in src/mat/utils/gcreate.c
[0]  MatConvert_SeqBAIJ_SeqSBAIJ() line 276 in 
  src/mat/impls/sbaij/seq/aijsbaij.c
[0]  MatConvert() line 3142 in src/mat/interface/matrix.c
  [ 0]460 bytes MatCreate() line 80 in src/mat/utils/gcreate.c
[0]  MatDuplicate_SeqBAIJ() line 2448 in src/mat/impls/baij/seq/baij.c
[0]  MatConvert() line 3142 in src/mat/interface/matrix.c
  [ 0]460 bytes MatCreate() line 80 in src/mat/utils/gcreate.c
[0]  MatConvert_SeqBAIJ_SeqAIJ() line 17 in 
  src/mat/impls/baij/seq/aijbaij.c
[0]  MatConvert() line 3142 in src/mat/interface/matrix.c
 Possible problem with ex55_1, diffs above
 52a53,55
  [0]Total space allocated 460 bytes
  [ 0]460 bytes MatCreate() line 80 in src/mat/utils/gcreate.c
[0]  MatCreateSeqAIJ() line 2777 in src/mat/impls/aij/seq/aij.c
 Possible problem with ex114_1, diffs above
 

 Prometheus also nees some PetscObject changes - I can send Mark the
 changes to update the prometheus tarball later..

 thanks,
 Satish



-- 
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

testing new repository

[Satish Balay]

Thanks. I've pushed these changes - and also synced with current
petsc-dev.

Satish

On Mon, 8 Oct 2007, Lisandro Dalcin wrote:

 Satish, your patch is fine... You catched sources that I did not
 checked because I did not have all external packages available to
 test.
 
 Please, push this patch to 'petsc-dev-dalcinl', I'll try ASAP to make
 more checking and take a look to the memory leak issue.
 
 There are also leaks related to MatMFFD, but I was not able to figure
 out the source of the problem yet, this was already on 'petsc-dev' and
 I catched it running the full petsc4py unittest suite.
 
 Regards,
 
 On 10/7/07, Satish Balay balay at mcs.anl.gov wrote:
  On Fri, 5 Oct 2007, Lisandro Dalcin wrote:
 
   And please, send me the failures...
 
  Lisandro,
 
  I haven't yet checked the nightly builds properly. Some of the issues
  I've been checking were with code already in petsc-dev. [So the
  current checks are from the tests I ran on my laptop]
 
  Most of the 'strict aliasing' I've seen so far are compile issues with
  sieve and other external pacakges[spooles,superlu_dist,pmetis.c etc..]
  wrt PetscObject usage.
 
  [so the fix for PetscObject stuff was simple enough for met to do and
  test]. I'm attaching the patch of the changes that worked. Let me know
  if this is ok to commit and push.
 
  There is also the following memory leak - which I haven't checked
  yet..  Perhaps there is some incorrect reference counting somewhere.
 
  
  testexamples_C in: /home/balay/tmp/petsc-dalcinl/src/mat/examples/tests
  0a1,10
   [0]Total space allocated 1380 bytes
   [ 0]460 bytes MatCreate() line 80 in src/mat/utils/gcreate.c
 [0]  MatConvert_SeqBAIJ_SeqSBAIJ() line 276 in 
   src/mat/impls/sbaij/seq/aijsbaij.c
 [0]  MatConvert() line 3142 in src/mat/interface/matrix.c
   [ 0]460 bytes MatCreate() line 80 in src/mat/utils/gcreate.c
 [0]  MatDuplicate_SeqBAIJ() line 2448 in 
   src/mat/impls/baij/seq/baij.c
 [0]  MatConvert() line 3142 in src/mat/interface/matrix.c
   [ 0]460 bytes MatCreate() line 80 in src/mat/utils/gcreate.c
 [0]  MatConvert_SeqBAIJ_SeqAIJ() line 17 in 
   src/mat/impls/baij/seq/aijbaij.c
 [0]  MatConvert() line 3142 in src/mat/interface/matrix.c
  Possible problem with ex55_1, diffs above
  52a53,55
   [0]Total space allocated 460 bytes
   [ 0]460 bytes MatCreate() line 80 in src/mat/utils/gcreate.c
 [0]  MatCreateSeqAIJ() line 2777 in src/mat/impls/aij/seq/aij.c
  Possible problem with ex114_1, diffs above
  
 
  Prometheus also nees some PetscObject changes - I can send Mark the
  changes to update the prometheus tarball later..
 
  thanks,
  Satish
 
 
 
 

testing new repository

[Satish Balay]

On Fri, 5 Oct 2007, Lisandro Dalcin wrote:

 And please, send me the failures...

Lisandro,

I haven't yet checked the nightly builds properly. Some of the issues
I've been checking were with code already in petsc-dev. [So the
current checks are from the tests I ran on my laptop]

Most of the 'strict aliasing' I've seen so far are compile issues with
sieve and other external pacakges[spooles,superlu_dist,pmetis.c etc..]
wrt PetscObject usage.

[so the fix for PetscObject stuff was simple enough for met to do and
test]. I'm attaching the patch of the changes that worked. Let me know
if this is ok to commit and push.

There is also the following memory leak - which I haven't checked
yet..  Perhaps there is some incorrect reference counting somewhere.


testexamples_C in: /home/balay/tmp/petsc-dalcinl/src/mat/examples/tests
0a1,10
 [0]Total space allocated 1380 bytes
 [ 0]460 bytes MatCreate() line 80 in src/mat/utils/gcreate.c
   [0]  MatConvert_SeqBAIJ_SeqSBAIJ() line 276 in 
 src/mat/impls/sbaij/seq/aijsbaij.c
   [0]  MatConvert() line 3142 in src/mat/interface/matrix.c
 [ 0]460 bytes MatCreate() line 80 in src/mat/utils/gcreate.c
   [0]  MatDuplicate_SeqBAIJ() line 2448 in src/mat/impls/baij/seq/baij.c
   [0]  MatConvert() line 3142 in src/mat/interface/matrix.c
 [ 0]460 bytes MatCreate() line 80 in src/mat/utils/gcreate.c
   [0]  MatConvert_SeqBAIJ_SeqAIJ() line 17 in 
 src/mat/impls/baij/seq/aijbaij.c
   [0]  MatConvert() line 3142 in src/mat/interface/matrix.c
Possible problem with ex55_1, diffs above
52a53,55
 [0]Total space allocated 460 bytes
 [ 0]460 bytes MatCreate() line 80 in src/mat/utils/gcreate.c
   [0]  MatCreateSeqAIJ() line 2777 in src/mat/impls/aij/seq/aij.c
Possible problem with ex114_1, diffs above


Prometheus also nees some PetscObject changes - I can send Mark the
changes to update the prometheus tarball later..

thanks,
Satish
-- next part --
diff -r 069050f22c2f src/dm/mesh/impls/cartesian/cartesian.c
--- a/src/dm/mesh/impls/cartesian/cartesian.c   Fri Oct 05 23:01:32 2007 -0500
+++ b/src/dm/mesh/impls/cartesian/cartesian.c   Sat Oct 06 21:57:12 2007 -0500
@@ -110,7 +110,7 @@ PetscErrorCode PETSCDM_DLLEXPORT MeshVie
   } else if (isdraw){ 
 SETERRQ(PETSC_ERR_SUP, Draw viewer not implemented for Cartesian Mesh);
   } else {
-SETERRQ1(PETSC_ERR_SUP,Viewer type %s not supported by this mesh object, 
viewer-type_name);
+SETERRQ1(PETSC_ERR_SUP,Viewer type %s not supported by this mesh object, 
((PetscObject)viewer)-type_name);
   }
   PetscFunctionReturn(0);
 }
diff -r 069050f22c2f src/dm/mesh/mesh.c
--- a/src/dm/mesh/mesh.cFri Oct 05 23:01:32 2007 -0500
+++ b/src/dm/mesh/mesh.cSat Oct 06 21:57:12 2007 -0500
@@ -247,7 +247,7 @@ PetscErrorCode MeshView_Sieve(const ALE:
   } else if (isdraw){ 
 SETERRQ(PETSC_ERR_SUP, Draw viewer not implemented for Mesh);
   } else {
-SETERRQ1(PETSC_ERR_SUP,Viewer type %s not supported by this mesh object, 
viewer-type_name);
+SETERRQ1(PETSC_ERR_SUP,Viewer type %s not supported by this mesh object, 
((PetscObject)viewer)-type_name);
   }
   PetscFunctionReturn(0);
 }
@@ -317,7 +317,7 @@ PetscErrorCode PETSCDM_DLLEXPORT MeshVie
   PetscValidHeaderSpecific(mesh, MESH_COOKIE, 1);
   PetscValidType(mesh, 1);
   if (!viewer) {
-ierr = PetscViewerASCIIGetStdout(mesh-comm,viewer);CHKERRQ(ierr);
+ierr = 
PetscViewerASCIIGetStdout(((PetscObject)mesh)-comm,viewer);CHKERRQ(ierr);
   }
   PetscValidHeaderSpecific(viewer, PETSC_VIEWER_COOKIE, 2);
   PetscCheckSameComm(mesh, 1, viewer, 2);
@@ -596,7 +596,7 @@ PetscErrorCode PETSCDM_DLLEXPORT MeshSet
   ierr = PetscTypeCompare((PetscObject)mesh,type,match);CHKERRQ(ierr);
   if (match) PetscFunctionReturn(0);
 
-  ierr =  PetscFListFind(MeshList,mesh-comm,type,(void (**)(void)) 
r);CHKERRQ(ierr);
+  ierr =  PetscFListFind(MeshList,((PetscObject)mesh)-comm,type,(void 
(**)(void)) r);CHKERRQ(ierr);
   if (!r) SETERRQ1(PETSC_ERR_ARG_UNKNOWN_TYPE,Unable to find requested Mesh 
type %s,type);
   /* Destroy the previous private Mesh context */
   if (mesh-ops-destroy) { ierr = (*mesh-ops-destroy)(mesh);CHKERRQ(ierr); }
@@ -631,7 +631,7 @@ PetscErrorCode PETSCDM_DLLEXPORT MeshGet
   PetscFunctionBegin;
   PetscValidHeaderSpecific(mesh,MESH_COOKIE,1);
   PetscValidPointer(type,2);
-  *type = mesh-type_name;
+  *type = ((PetscObject)mesh)-type_name;
   PetscFunctionReturn(0);
 }
 
diff -r 069050f22c2f src/dm/mesh/section.c
--- a/src/dm/mesh/section.c Fri Oct 05 23:01:32 2007 -0500
+++ b/src/dm/mesh/section.c Sat Oct 06 21:57:12 2007 -0500
@@ -35,7 +35,7 @@ PetscErrorCode SectionRealView_Sieve(Sec
   } else if (isdraw){ 
 SETERRQ(PETSC_ERR_SUP, Draw viewer not implemented for Section);
   } else {
-SETERRQ1(PETSC_ERR_SUP,Viewer type %s not supported by this section 
object, viewer-type_name);
+SETERRQ1(PETSC_ERR_SUP,Viewer type %s not supported by this section 
object, ((PetscObject)viewer)-type_name);
   }
   

testing new repository

[Satish Balay]

I've changed the petsc-dev URL for the nightly builds to use
http://petsc.cs.iit.edu/petsc/petsc-dev-dalcinl.

Just so that these machines don't have issues with pulling from
petsc-dev-dalcinl, I've merged the latest petsc-dev changes into
petsc-dev-dalcinl

Satish

On Thu, 4 Oct 2007, Barry Smith wrote:

 
   Satish,
 
 Could you please switch ALL the nightly builds over to this repository
 and see how it goes?
 
Thanks
 
  Barry
 
 On Thu, 4 Oct 2007, Lisandro Dalcin wrote:
 
  I've just pushed the changes for solving the c99 strict aliasing issue
  regarding PetscObject and derived objects.
  
  As the conversion was a mixture of sed trickery and manual editing,
  perhaps there are bugs, but  'petsc-dev-dalcinl' clone with
  ML+HYPRE+MUMPS builds fine and all testsuite (C and Fortran) pass for
  me.
  
  Regards,
  
  
  
 
 

testing new repository

[Lisandro Dalcin]

And please, send me the failures...

On 10/5/07, Satish Balay balay at mcs.anl.gov wrote:
 I've changed the petsc-dev URL for the nightly builds to use
 http://petsc.cs.iit.edu/petsc/petsc-dev-dalcinl.

 Just so that these machines don't have issues with pulling from
 petsc-dev-dalcinl, I've merged the latest petsc-dev changes into
 petsc-dev-dalcinl

 Satish

 On Thu, 4 Oct 2007, Barry Smith wrote:

 
Satish,
 
  Could you please switch ALL the nightly builds over to this repository
  and see how it goes?
 
 Thanks
 
   Barry
 
  On Thu, 4 Oct 2007, Lisandro Dalcin wrote:
 
   I've just pushed the changes for solving the c99 strict aliasing issue
   regarding PetscObject and derived objects.
  
   As the conversion was a mixture of sed trickery and manual editing,
   perhaps there are bugs, but  'petsc-dev-dalcinl' clone with
   ML+HYPRE+MUMPS builds fine and all testsuite (C and Fortran) pass for
   me.
  
   Regards,
  
  
  
 
 




-- 
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