Re: [petsc-dev] Gfortran Fix for "library not found for -lSystem" macOS Big Sur

Jacob Faibussowitsch writes: > If anyone is on macOS and using brew to get gfortran, you may find it > suddenly doesn’t work anymore. > > Fix is to add /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib to > $LIBRARY_PATH in startup shell file, as per this SO post. TLDR; reinstall

Re: [petsc-dev] transition to GitHub

Smith, Barry F. writes: >Jed (and others) > > What do you recommend as the least painful way to move the PETSc > repository and all its issues, etc over to GitHub? > > Thanks > Barry > > > One more time of dealing with Bitbucket's cumbersome way to

Re: [petsc-dev] Getting credit for Contributors graph on github?

Jed Brown <j...@jedbrown.org> writes: > Sean Farley <s...@farley.io> writes: > >> Barry Smith <bsm...@mcs.anl.gov> writes: >> >>> Just a reminder for developers who want to get credit for their PETSc >>> commits. >>>

Re: [petsc-dev] Getting credit for Contributors graph on github?

Satish Balay <ba...@mcs.anl.gov> writes: > On Tue, 3 Oct 2017, Sean Farley wrote: > >> Barry Smith <bsm...@mcs.anl.gov> writes: >> >> > Just a reminder for developers who want to get credit for their PETSc >> > commits. >> > >> &

Re: [petsc-dev] Getting credit for Contributors graph on github?

Barry Smith writes: > Just a reminder for developers who want to get credit for their PETSc > commits. > > >> Begin forwarded message: >> >> From: Jed Brown >> Subject: Re: [petsc-maint] Contributors graph on github? >> Date: September 27, 2017 at

Re: [petsc-dev] possibility of short term subcontract work with PETSc

Barry Smith writes: >PETSc folks, > > Argonne National Laboratory has recently set up a system that may make it > possible for the PETSc group at ANL to subcontract particular PETSc > contribution projects to developers in most of the world. These could be from >

Re: [petsc-dev] Problem with PetscCMPLX()

Lisandro Dalcin writes: > We need someone to resurrect https://twitter.com/shitbsmithsays !!! Ha, I was actually saving that quote in my barry.txt file when I read this. With such latency between Barry and myself, this will be difficult to maintain. Maybe we should get Barry

Re: [petsc-dev] PETSc statistics

Jed Brown <j...@jedbrown.org> writes: > Sean Farley <s...@farley.io> writes: > >> Jed Brown <j...@jedbrown.org> writes: >> >>> Sean Farley <s...@farley.io> writes: >>> >>>> Sean Farley <s...@farley.io> writes: >>&

Re: [petsc-dev] PETSc statistics

Sean Farley <s...@farley.io> writes: > Andrew McRae <a.t.t.mc...@bath.ac.uk> writes: > >> But we clone from our fork (formerly Bitbucket firedrake/petsc, now Github >> firedrakeproject/petsc), not from Bitbucket petsc/petsc. > > Yeah, the stats won't be p

Re: [petsc-dev] PETSc statistics

Andrew McRae writes: > But we clone from our fork (formerly Bitbucket firedrake/petsc, now Github > firedrakeproject/petsc), not from Bitbucket petsc/petsc. Yeah, the stats won't be perfect, of course. Hopefully, useful enough for some general idea of the numbers.

Re: [petsc-dev] PETSc statistics

Sean Farley <s...@farley.io> writes: > Barry Smith <bsm...@mcs.anl.gov> writes: > >>Sean, >> >> Very cool maps. Thanks for the b-day present > > :-D > >> It is strange that there are many archive downloads from the US and >&

Re: [petsc-dev] PETSc statistics

Barry Smith writes: >Sean, > > Very cool maps. Thanks for the b-day present :-D > It is strange that there are many archive downloads from the US and none > from elsewhere. Maybe there is some single weird client (spack?) doing these > downloads? Can you

Re: [petsc-dev] Bad tags

Satish Balay writes: > On Sun, 23 Apr 2017, Satish Balay wrote: > >> Hope bitbucket has a way to control the push of tags.. > > There is a mention of 'tag' in branch permissions - but its not clear how > that works. > >

Re: [petsc-dev] WSL upgrade

Satish Balay writes: > On Wed, 12 Apr 2017, Jed Brown wrote: > >> >> This is the error message that old blog post refers to >> >> >> >> >> >> https://blogs.msdn.microsoft.com/commandline/2016/10/19/interop-between-windows-and-bash/ >> >> >> >> and the new post runs

Re: [petsc-dev] Fwd: [Bitbucket] Pipeline for master failed on c3c607c (petsc/petsc)

Barry Smith writes: >Thanks! One less thing to wake me up in the middle of the night worrying > about. I know how much you worry ;-)

Re: [petsc-dev] Fwd: [Bitbucket] Pipeline for master failed on c3c607c (petsc/petsc)

Sean Farley <s...@farley.io> writes: > Barry Smith <bsm...@mcs.anl.gov> writes: > >>Once something bugs you with irrelevant things you pretty soon start to >> ignore it and then it becomes useless. > > That's a fair point. I've pinged the pipelines tea

Re: [petsc-dev] git problem

Barry Smith writes: >This came up and I haven't seen it before, google is not helpful in > resolving it. > > > git pull http://bitbucket.org/vlc1/petsc vlc1/dmcomposite > fatal: unable to access 'https://bitbucket.org/vlc1/petsc/': SSL certificate > problem: unable to

Re: [petsc-dev] Watching now

Barry Smith <bsm...@mcs.anl.gov> writes: >> On Jul 22, 2016, at 9:55 PM, Sean Farley <s...@farley.io> wrote: >> >> Barry Smith <bsm...@mcs.anl.gov> writes: >> >>> Man, why are comments disabled? >> >> Because julia in

Re: [petsc-dev] NEVER put // into PETSc code. PETSc is C89, the only real C.

Barry Smith writes: > Hmm, both of these links refer to C99 Standard Library they do not refer > to the C99 standard language. Anywhere that says the language standard? Good question. It's getting dangerously close to beer o'clock for me but if you have a test, we could

Re: [petsc-dev] NEVER put // into PETSc code. PETSc is C89, the only real C.

Barry Smith <bsm...@mcs.anl.gov> writes: >> On Jun 22, 2016, at 5:58 PM, Sean Farley <s...@farley.io> wrote: >> >> C Bergström <cbergst...@pathscale.com> writes: >> >>> Sorry I can't help, but +1 troll on this... >>> >>>

Re: [petsc-dev] NEVER put // into PETSc code. PETSc is C89, the only real C.

C Bergström writes: > Sorry I can't help, but +1 troll on this... > > On Thu, Jun 23, 2016 at 6:47 AM, Jeff Hammond wrote: >> Serious question: >> >> What are your reasons for using a language that is 27 years old? Terrible >> compilers that

Re: [petsc-dev] PETSc "testing" infrastructure

Barry Smith writes: >There is a lot going on currently to enhance the PETSc "testing" > infrastructure; in particular Lisandro has begun to set up stuff on both > github and bitbucket. If you guys need help from the bitbucket side of things, just let me know.

Re: [petsc-dev] Configure push

Matthew Knepley writes: > On Mon, Jun 6, 2016 at 11:57 PM, Barry Smith wrote: > >> >>In order to allow decent pre-testing before merging to next I had Jason >> write a shell script to talk to a Jenkins server and organize a Jenkins >> server to accept

Re: [petsc-dev] petsc branching methodology?

JR Cary writes: > Thanks, Jed. > > Just in case anyone has any thoughts, ideas, experience along this > direction... > > We have multiple internal library projects, lib1, lib2,, and then > multiple applications, app1, app2, app3, all in different repos, and we > are trying

Re: [petsc-dev] Do we still need to support python 2.4?

Åsmund Ervik writes: > Dear petsc-dev, > > Apropos this discussion, I just came across the following from Nick > Coghlan, one of the CPython core devs and a Red Hat guy, and thought it > might be useful for reference. You could even link to it in the error > message

Re: [petsc-dev] problems with shared libraries and pragmatic.py

Jed Brown writes: > Barry Smith writes: > >>> What is lib pragmatic? >> >>I have no idea, but it is in PETSc so needs to be tested or deleted. > > Wow, those Imperial guys sure have a way with language. > > PRAgMaTIc (Parallel anisotRopic Adaptive

Re: [petsc-dev] problems with shared libraries and pragmatic.py

Barry Smith writes: >> On Oct 15, 2015, at 3:11 PM, Jed Brown wrote: >> >> Barry Smith writes: >> >>> Matt and Jed, >>> >>> For some reason the make gnumake doesn't handle libpragmatic problem with >>> shared libraries on my

Re: [petsc-dev] Adding support for new sparse BLAS inspector-executor routines in MKL

Jed Brown writes: > Barry Smith writes: > >>> On Sep 30, 2015, at 9:48 AM, Jed Brown wrote: >>> >>> Matthew Knepley writes: Richard, this is somewhat subtle since PETSc's inheritance model is sucky and

Re: [petsc-dev] plex memory leaks in master

Barry Smith writes: 323a324,334 [0]Total space allocated 96 bytes [ 0]96 bytes DMPlexCreateConstraintMatrix_Anchors() line 5852 in /usr/home/balay/petsc.clone-2/src/dm/impls/plex/plex.c [1]Total space allocated 160 bytes [ 1]96 bytes DMPlexCreateConstraintMatrix_Anchors() line 5852 in

Re: [petsc-dev] TSSetRHSJacobian web page errors

Jed Brown writes: Barry Smith bsm...@mcs.anl.gov writes: Yeah, lazyness and fear of Jed's wraith I'm quite sure I don't have a wraith. Yet.

Re: [petsc-dev] prefix installs and lib/petsc-conf

Barry Smith writes: How about? share/petsc/matlab,python,julia/ non-generated stuff lib/petsc/matlab,python,julia/ generated stuff for example Matlab .mex files lib/petsc/conf include/petsc/finclude,private,mpiuni (note some generated stuff goes in here; could

Re: [petsc-dev] I hate PetscThreadComm

Jed Brown writes: Barry Smith bsm...@mcs.anl.gov writes: Nice, so presumably the RPI guys could potentially use this and toss their custom stuff? It's not publicly released (though I hope it will be). And it's a research implementation (using proxy processes), so there is no reason

Re: [petsc-dev] Sean is going to love this

Jed Brown writes: Sean Farley sean.michael.far...@gmail.com writes: The only problem with using non-system compilers is with C++ because clang++ is not ABI compatible with g++. You could use gcc just fine if there was something to enforce the induced dependency graph. Uh, isn't this libc

Re: [petsc-dev] Sean is going to love this

Jed Brown writes: Sean Farley sean.michael.far...@gmail.com writes: Is this ArchHaskell? It doesn't seem clear to me which method uses the API from https://wiki.archlinux.org/index.php/haskell. The ArchHaskell repository is for binaries. I'm referring to the cabal2pkgbuild tool that uses

Re: [petsc-dev] Sean is going to love this

Jed Brown writes: Geoff Oxberry goxbe...@gmail.com writes: I also agree that mixing package managers is a mess. I still prefer it to manual installation in most cases. A single package manager solution would be best, but I have yet to see one effectively incorporate existing

Re: [petsc-dev] Sean is going to love this

Geoff Oxberry writes: On Jan 2, 2015 1:38 PM, Sean Farley sean.michael.far...@gmail.com wrote: Geoff Oxberry writes: On Jan 1, 2015 8:46 PM, Sean Farley sean.michael.far...@gmail.com wrote: Jed Brown writes: Geoff Oxberry goxbe...@gmail.com writes: Brew bottles were

Re: [petsc-dev] Sean is going to love this

Geoff Oxberry writes: On Jan 1, 2015 8:46 PM, Sean Farley sean.michael.far...@gmail.com wrote: Jed Brown writes: Geoff Oxberry goxbe...@gmail.com writes: Brew bottles were originally only used in situations where building from source would take a long time, and under the assumption

Re: [petsc-dev] Sean is going to love this

Jed Brown writes: Geoff Oxberry goxbe...@gmail.com writes: Brew bottles were originally only used in situations where building from source would take a long time, and under the assumption that most users are interested in a standard build without any command-line options. The dependency

Re: [petsc-dev] Sean is going to love this

Barry Smith writes: On Dec 29, 2014, at 9:56 PM, Geoff Oxberry goxbe...@gmail.com wrote: Date: Sun, 28 Dec 2014 21:27:21 -0600 From: Barry Smith bsm...@mcs.anl.gov To: Sean Farley sean.michael.far...@gmail.com Cc: petsc-dev petsc-dev@mcs.anl.gov Subject: Re: [petsc-dev] Sean

Re: [petsc-dev] Sean is going to love this

Barry Smith writes: Sean, brew install /homebrew/science/petsc brew install /homebrew/science/petsc --HEAD --with-x11 Is there any reason not to use home-brew for everything now? Should we be working with the homebrew/science guys to work out the rough edges? (Like their

Re: [petsc-dev] Sean is going to love this

Jose E. Roman writes: El 23/12/2014, a las 20:38, Sean Farley escribió: 4) Better coordination with dependent packages This item is hard to implement because it's out of the PETSc team's control. For example, packages like SLEPc depend on PETSc but don't have as good of a build system

Re: [petsc-dev] Sean is going to love this

Karl Rupp writes: Hi, The only way to do this, in my experience, is if the package manager has something like 'variants' (macports and homebrew have it, at least, I don't know about others): port install petsc +superlu +mumps +mpich +hdf5 +hypre ... etc. I think variants are a crutch

Re: [petsc-dev] Sean is going to love this

Barry Smith writes: Sean, Say I am writing a PETSc package (for any generic packaging system) that will use the MPICH compilers package and the BLAS/LAPACK package (and say, the hdf5 package). How do I indicate to PETSc's configure the information for MPICH, BLAS/LAPACK, and hdf5

Re: [petsc-dev] Sean is going to love this

Barry Smith writes: On Dec 23, 2014, at 6:11 PM, Sean Farley sean.michael.far...@gmail.com wrote: Barry Smith writes: Sean, Say I am writing a PETSc package (for any generic packaging system) that will use the MPICH compilers package and the BLAS/LAPACK package (and say

Re: [petsc-dev] Sean is going to love this

Jed Brown writes: Sean Farley sean.michael.far...@gmail.com writes: An end-user would then use pkg-config or a PETSc-provided script for compiling and linking, $ pkg-config --libs petsc -L/opt/local/lib -lnetcdf -lpetsc -L/opt/local/lib/mpich-mp -lmpi -lpmpi This actually exists in lib

Re: [petsc-dev] Sean is going to love this

Barry Smith writes: On Dec 23, 2014, at 1:38 PM, Sean Farley sean.michael.far...@gmail.com wrote: Karl Rupp writes: Hi, The only way to do this, in my experience, is if the package manager has something like 'variants' (macports and homebrew have it, at least, I don't know about

Re: [petsc-dev] Sean is going to love this

Jed Brown writes: Sean Farley sean.michael.far...@gmail.com writes: That's entirely up to you of where to put it. Jed, I'm sure, can advise on which files in 'conf' to put into etc, var, or share. I would actually prefer to create a bin/petsc-config that can be used to query everything

Re: [petsc-dev] Sean is going to love this

Jed Brown writes: Barry Smith bsm...@mcs.anl.gov writes: $libdir/petsc/ if we want to be like libtool and pkgconfig. lib - Currently we put Matlab compiled stuff here (Matlab uses arch specific suffixes so versions for any architecture can be dumped in this same place, of course the

Re: [petsc-dev] Sean is going to love this

Matthew Knepley writes: On Mon, Dec 22, 2014 at 8:31 PM, Barry Smith bsm...@mcs.anl.gov wrote: In the past we've been not particularly supportive of getting PETSc in Linux package systems, in fact we've been a bit antagonistic. We should change this. I have the same objection as

Re: [petsc-dev] MUMPS and 64 bit indices

Barry Smith writes: On Dec 15, 2014, at 3:16 PM, Garth N. Wells gn...@cam.ac.uk wrote: It's possible to configure PETSc with the options --with-64-bit-indices --download-mumps and compile and run, but it doesn't look like the MUMPS interface supports 64 bit indices. Should the

Re: [petsc-dev] I hate nagupgrade

Matthew Knepley writes: On Tue, Nov 11, 2014 at 3:55 AM, Jed Brown j...@jedbrown.org wrote: KAUST (or KSA?) internet can be flaky at times and my make was (silently) hanging indefinitely while trying to connect to mcs.anl.gov. Manually touching .nagged allows my build to proceed. The hang

Re: [petsc-dev] 8f4ae08

Emil Constantinescu writes: On 11/11/14 11:33 AM, Mark Adams wrote: On Tue, Nov 11, 2014 at 12:27 PM, Satish Balay ba...@mcs.anl.gov mailto:ba...@mcs.anl.gov wrote: On Tue, 11 Nov 2014, Mark Adams wrote: On Tue, Nov 11, 2014 at 11:56 AM, Satish Balay ba...@mcs.anl.gov

Re: [petsc-dev] I hate nagupgrade

Matthew Knepley writes: On Tue, Nov 11, 2014 at 1:20 PM, Sean Farley sean.michael.far...@gmail.com wrote: Matthew Knepley writes: On Tue, Nov 11, 2014 at 3:55 AM, Jed Brown j...@jedbrown.org wrote: KAUST (or KSA?) internet can be flaky at times and my make was (silently) hanging

[petsc-dev] RFC: allow setting flags via environment variables

For purposes of building PETSc in a package manager setting, it would convenient to have a way to turn off the default behavior of not setting CFLAGS, CXXFLAGS, etc. via environment variables. The reason I bring this up is because in MacPorts (perhaps others) it is impossible to know the full set

Re: [petsc-dev] RFC: allow setting flags via environment variables

Barry Smith writes: Sean, We definitely want to support this ability (in our new quest to be more standards friendly, since we can’t ask others to follow standards if we don’t). :-) Ideally BuildSystem would just know it is a package build and use those variables. Are there

Re: [petsc-dev] [petsc-maint] problem installing petsc 3.4

Jed Brown j...@jedbrown.org writes: Barry Smith bsm...@mcs.anl.gov writes: In an ideal world compilers would have a standard, extensible API. For years I’ve dreamed of day when Unix would be replaced with a modern operating system where there would be a one-to-one mapping between

Re: [petsc-dev] [petsc-maint] problem installing petsc 3.4

Jed Brown j...@jedbrown.org writes: Satish Balay ba...@mcs.anl.gov writes: On Wed, 16 Apr 2014, Jed Brown wrote: Yes, but the current failure case is complicated because people see a library they've never heard of and probably is not documented anywhere. How did PETSc come up with this

Re: [petsc-dev] [petsc-maint] problem installing petsc 3.4

Barry Smith bsm...@mcs.anl.gov writes: Who is the tall guy next to Jed? I thought that was you?

Re: [petsc-dev] configure failed after update of OSX

mfad...@lbl.gov writes: $ sudo port install mpich-default $ sudo port select --set mpi mpich-mp-fortran Then try to build PETSc (minus the --download-mpich and CC, CXX, FC options). That worked Awesome You could also try to install most of the external packages: $ sudo port

Re: [petsc-dev] configure failed after update of OSX

goxbe...@gmail.com writes: To echo what Aron said, I wouldn't point people at the hpc.sourceforge.netbuilds. They do install directly into /usr/bin, and it's a pain in the ass to undo. The R/ATT build of gcc was better, but also installed into /usr/bin, and was also a pain in the ass to

Re: [petsc-dev] configure failed after update of OSX

ba...@mcs.anl.gov writes: On Tue, 28 Jan 2014, Sean Farley wrote: ba...@mcs.anl.gov writes: On Tue, 28 Jan 2014, Sean Farley wrote: mfad...@lbl.gov writes: Oh yes. I had a use-make=make commended out. I uncommented it and its seems to have gotten MPICH installed

Re: [petsc-dev] configure failed after update of OSX

bsm...@mcs.anl.gov writes: I think resolved it by getting rid of some stuff that macports put in maybe I just *completely* revamped the mpi ports in macports and would like to know if these types of problems still exist. MPICH or libtool assumes certain files are there if other files are

Re: [petsc-dev] configure failed after update of OSX

ba...@mcs.anl.gov writes: It looks like a libtool issue to me. grep: /opt/local/lib/liblzma.la: No such file or directory /opt/local/bin/gsed: can't read /opt/local/lib/liblzma.la: No such file or directory libtool: link: `/opt/local/lib/liblzma.la' is not a valid libtool archive The

Re: [petsc-dev] configure failed after update of OSX

mfad...@lbl.gov writes: Sean, I seem to need to reinstall macorts. I ran this: *Edit:* A binary installer for Mavericks (for the 2.2.1 bugfix release) is now available: https://distfiles.macports.org/MacPorts/MacPorts-2.2.1-10.9-Mavericks.pkg. You'll need to remove /opt and

Re: [petsc-dev] CFLAGS and COPTFLAGS

j...@jedbrown.org writes: Barry Smith bsm...@mcs.anl.gov writes: Jed's suggestions here would be great for package maintainers. As an added bonus, it'd be great if $prefix/share/petsc-$foo could be be configurable (so that multiple installations could be live side-by-side). This would

Re: [petsc-dev] CFLAGS and COPTFLAGS

j...@jedbrown.org writes: Sean Farley sean.michael.far...@gmail.com writes: $prefix/bin/petsc-${version}-${arch}-config and symlink $prefix/bin/petsc-config to it by default? Then always namespace libraries and includes? This is what I had in mind as well. Though, distributions would

Re: [petsc-dev] CFLAGS and COPTFLAGS

j...@jedbrown.org writes: Barry Smith bsm...@mcs.anl.gov writes: Where should we put the files that end up in conf? Should we simply not install those? I don't think we should install logs. If it were up to me, I would put the makefiles in $prefix/share/petsc/, but I would

Re: [petsc-dev] CFLAGS and COPTFLAGS

bsm...@mcs.anl.gov writes: On Jan 20, 2014, at 12:49 PM, Sean Farley sean.michael.far...@gmail.com wrote: j...@jedbrown.org writes: Barry Smith bsm...@mcs.anl.gov writes: Where should we put the files that end up in conf? Should we simply not install those? I don't think

Re: [petsc-dev] CFLAGS and COPTFLAGS

bsm...@mcs.anl.gov writes: On Jan 19, 2014, at 5:50 PM, Jed Brown j...@jedbrown.org wrote: Barry Smith bsm...@mcs.anl.gov writes: User runs —with-cc=cc CFLAGS=“-m64” —with-debugging=0 gets the same performance as —with-cc=cc CFLAGS=“-m64” —with-debugging=1 Can’t

Re: [petsc-dev] CFLAGS and COPTFLAGS

ba...@mcs.anl.gov writes: On Sun, 19 Jan 2014, Sean Farley wrote: I haven't chimed in for this thread but I'd like to point out that this CFLAGS trickery is also a problem for package maintainers. These people are usually admins and have no specific knowledge of PETSc internals. Every

Re: [petsc-dev] defaulting gnu compilers on Apple

ba...@mcs.anl.gov writes: unless everyone is using xcode5 - I think gcc/g++ is a safer default. Apple stopped shipping gcc with Xcode 4.2 [1]. Since that version, everyone has been using the llvm backend. Only in version = 5.0 has llvm-gcc been dropped. And in Mavericks only libc++ (and not

Re: [petsc-dev] METIS update - MUMPS crash

bsm...@mcs.anl.gov writes: On Sep 1, 2013, at 1:27 PM, Matthew Knepley knep...@gmail.com wrote: On Sun, Sep 1, 2013 at 1:07 PM, Satish Balay ba...@mcs.anl.gov wrote: I see the errors with valgrind - and I don't know the reason. Perhaps we should revert the metis/parmetis upgrade.. [unless

Re: [petsc-dev] [petsc-maint] Updating PETSc to support Elemental 0.80

Jed Brown writes: Jack Poulson jack.poul...@gmail.com writes: On Fri, Jun 14, 2013 at 9:44 AM, Jack Poulson jack.poul...@gmail.comwrote: On Fri, Jun 14, 2013 at 2:18 AM, Jed Brown jedbr...@mcs.anl.gov wrote: Jack Poulson jack.poul...@gmail.com writes: By the way, was any decision made

[petsc-dev] All petsc-dev users will need to do a reclone of petsc-dev on Tuesday or later

Barry Smith writes: To users of petsc-dev, I promised more details on the planned change and why we are making them. The plan is to move petsc-dev over to the git repository system (remaining on bitbucket.org so no new accounts are needed) with a simple and slow

[petsc-dev] All petsc-dev users will need to do a reclone of petsc-dev on Tuesday or later

Karl Rupp writes: Hi Sean, Satish, please remove me from petsc-maint. Also, remove me from the developers webpage. I have already purged petsc-dev from my system and won't be pushing anything else from now on. Huh, why this? This is not forced change of religion... Why should I bother?

[petsc-dev] All petsc-dev users will need to do a reclone of petsc-dev on Tuesday or later

Karl Rupp writes: Hi Sean, Satish, please remove me from petsc-maint. Also, remove me from the developers webpage. I have already purged petsc-dev from my system and won't be pushing anything else from now on. Huh, why this? This is not forced change of religion... Why should I

[petsc-dev] Commit collision/corruption?

Jed Brown writes: On Wed, Mar 6, 2013 at 10:54 PM, Sean Farley sean at mcs.anl.gov wrote: Responding to this paragraph more in depth now; your information above is at best misinformed and at worse complete bs. Both mercurial and git store the sha1 representation with a binary-safe diff

[petsc-dev] Commit collision/corruption?

On Wed, Mar 6, 2013 at 5:05 PM, Satish Balay balay at mcs.anl.gov wrote: On Wed, 6 Mar 2013, Jed Brown wrote: On Wed, Mar 6, 2013 at 4:54 PM, Karl Rupp rupp at mcs.anl.gov wrote: Hmm, maybe this is just the same commit applied to different branches? (You probably checked

[petsc-dev] Commit collision/corruption?

Jed Brown writes: On Wed, Mar 6, 2013 at 7:08 PM, Sean Farley sean at mcs.anl.gov wrote: Jed Brown writes: On Wed, Mar 6, 2013 at 6:34 PM, Sean Farley sean at mcs.anl.gov wrote: Run 'hg export de73c9a7d341d846b5e16a8d61a48'. Note how they do not exist in the formatted patch. Why

[petsc-dev] Commit collision/corruption?

Jed Brown writes: On Wed, Mar 6, 2013 at 8:15 PM, Sean Farley sean at mcs.anl.gov wrote: No, I got that. I, and no other dev, can reproduce. What I was implying is an error between the chair and the keyboard. Perhaps you didn't realize you did a rebase or some other such human mistake

[petsc-dev] Commit collision/corruption?

Jed Brown writes: On Wed, Mar 6, 2013 at 7:08 PM, Sean Farley sean at mcs.anl.gov wrote: Jed Brown writes: On Wed, Mar 6, 2013 at 6:34 PM, Sean Farley sean at mcs.anl.gov wrote: Run 'hg export de73c9a7d341d846b5e16a8d61a48'. Note how they do not exist in the formatted patch. Why

[petsc-dev] Internal and external symbols

Jed Brown writes: On Tue, Mar 5, 2013 at 5:34 PM, Barry Smith bsmith at mcs.anl.gov wrote: I have no idea what a branch is, nor even more a private branch is? All I know is that branches in hg cause lots of arguments between Sean, Jed, and Matt. Okay, in mercurial, you have to

[petsc-dev] meaning of PETSC_USE_EXTERN_CXX?

Jed Brown writes: On Tue, Mar 5, 2013 at 6:58 PM, Barry Smith bsmith at mcs.anl.gov wrote: I have created a fork https://bitbucket.org/BarryFSmith/petsc-dev-simp this contains all my changes plus Jed's changes with PETSC_INTERN. It works on all configurations I tried. I propose:

[petsc-dev] Internal and external symbols

Jed Brown writes: On Tue, Mar 5, 2013 at 7:37 PM, Sean Farley sean at mcs.anl.gov wrote: In mercurial, you'd do 'hg bookmark simp', 'hg push -B simp'. Jed would 'hg pull -B simp' and complete the merge. One notable difference is that a git user does not see these unless they look

[petsc-dev] Internal and external symbols

Jed Brown writes: On Tue, Mar 5, 2013 at 7:37 PM, Sean Farley sean at mcs.anl.gov wrote: In mercurial, you'd do 'hg bookmark simp', 'hg push -B simp'. Jed would 'hg pull -B simp' and complete the merge. One notable difference is that a git user does not see these unless they look

[petsc-dev] meaning of PETSC_USE_EXTERN_CXX?

Jed Brown writes: On Tue, Mar 5, 2013 at 7:48 PM, Sean Farley sean at mcs.anl.gov wrote: Huh? gitifyhg should only be pulling the new changesets (isn't it keeping some kind of hash mapping around?). Gitifyhg keeps a separate hg clone per remote because we could not find a reliable way

[petsc-dev] Internal and external symbols

Jed Brown writes: On Tue, Mar 5, 2013 at 7:54 PM, Sean Farley sean at mcs.anl.gov wrote: Yes, that has traditionally been true but has changed significantly with the latest release involving hidden changesets. Lots of care has been taken to scale to extremely large repos. I'm not worried

[petsc-dev] meaning of PETSC_USE_EXTERN_CXX?

Jed Brown writes: On Tue, Mar 5, 2013 at 8:09 PM, Sean Farley sean at mcs.anl.gov wrote: And this is why I think git makes things more complicated than need be. By keeping remotes namespaced and having exactly one branching mechanism? By not forcing any branching? All of what you have

[petsc-dev] Internal and external symbols

Jed Brown writes: On Tue, Mar 5, 2013 at 8:54 PM, Sean Farley sean at mcs.anl.gov wrote: Since mercurial was built on the concept of having a contiguous range of revisions, it took quite a bit of work to implement filtering which is what I was referring to (in git, this is accomplished

[petsc-dev] meaning of PETSC_USE_EXTERN_CXX?

Jed Brown writes: On Tue, Mar 5, 2013 at 9:05 PM, Sean Farley sean at mcs.anl.gov wrote: And this is why I think git makes things more complicated than need be. By keeping remotes namespaced and having exactly one branching mechanism? By not forcing any branching? All of what you

[petsc-dev] watching petsc-dev in gource

Jed Brown writes: On Wed, Feb 13, 2013 at 8:57 PM, Barry Smith bsmith at mcs.anl.gov wrote: How come we can't? Didn't the RCS files get input into BK or did we start all over again with BK? Anyway to add the RCS info back in? If you have it archived somewhere, we can import it, but it

[petsc-dev] private branch of petsc-dev (fwd)

Satish Balay writes: Barry/Jed/Sean, Should we have a recommended method of handling 'private branch' for petsc developemnt? thanks, Satish -- Forwarded message -- Date: Fri, 8 Feb 2013 16:24:46 -0600 (CST) From: Satish Balay balay at mcs.anl.gov To: Hong Zhang hzhang

[petsc-dev] private branch of petsc-dev (fwd)

Barry Smith writes: My understanding is that git branches are ideal for this. If the bitbucket issue I linked to before is fixed, then the same workflow is achievable (i.e. garbage collecting obsolete rebased changesets)

[petsc-dev] Python version

On Mon, Feb 4, 2013 at 8:04 PM, Satish Balay balay at mcs.anl.gov wrote: On Mon, 4 Feb 2013, Jed Brown wrote: On Mon, Feb 4, 2013 at 7:35 PM, Karl Rupp rupp at mcs.anl.gov wrote: Hi Jed, interesting, thanks for sharing. I don't think that there is a significant difference for PETSc

[petsc-dev] Pushing non-working code

On Sun, Feb 3, 2013 at 11:17 AM, Matthew Knepley knepley at gmail.com wrote: On Sun, Feb 3, 2013 at 12:16 PM, Jed Brown jedbrown at mcs.anl.gov wrote: On Sun, Feb 3, 2013 at 11:11 AM, Matthew Knepley knepley at gmail.com wrote: Can you quantify your productivity gains that come from pushing

[petsc-dev] Pushing non-working code

On Sun, Feb 3, 2013 at 11:16 AM, Matthew Knepley knepley at gmail.com wrote: Pushing as a checkpointing mechanism discourages review. Review should happend when the section is complete, but this is no way implies that you should not push until it is complete. There seems to be a

[petsc-dev] Uncrustify has fucked up my file

On Thu, Jan 31, 2013 at 7:58 PM, Karl Rupp rupp at mcs.anl.gov wrote: Hi, I am abiding by all the screwed up stuff that is written down. Not what isn't. Well... The blank lines were in the middle of code, not between variables and code. You can revert that if you feel the need to.

[petsc-dev] I hate this one

On Mon, Jan 21, 2013 at 10:06 AM, Karl Rupp rupp at mcs.anl.gov wrote: Hi Matt, Again, there are limits to everything, and this surpasses the useful limit to this kind of specification. This is not personal expression, this is ease of reading. Also, judging by the

[petsc-dev] [mpich-discuss] MPICH migration to git

On Mon, Jan 21, 2013 at 10:07 AM, Jed Brown jedbrown at mcs.anl.gov wrote: As a test for my git-fat extension, I liberated the large files from PETSc's history (managing them outside the repository so that they need not be fetched by everyone; though if you fetch them, the working tree behaves

[petsc-dev] [mpich-discuss] MPICH migration to git

On Mon, Jan 21, 2013 at 11:03 AM, Jed Brown jedbrown at mcs.anl.gov wrote: On Mon, Jan 21, 2013 at 10:53 AM, Sean Farley sean.michael.farley at gmail.com wrote: Well ? did you try this with the equivalent mercurial feature: largefiles? Nope, feel free. Most of the speedup is independent

  1   2   3   >