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

[C Bergström]

Google tells me
https://msdn.microsoft.com/en-us/library/hh409293.aspx


C99 Conformance Visual Studio 2015 fully implements the C99 Standard
Library, with the exception of any library that needs to use petsc or
other useful features not yet supported by the Visual C++ compiler
(for example,  is not implemented).

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

[C Bergström]

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 have not been compliant with the current ISO C for 16 years?
> Because MPICH does it?
>

Jeff - I work for a horrible, truly terrible compiler company
(sarcasm) and empathetically (sincerely) I don't think MSVC supports
C99. So just taking a random guess that it could be part of the
justification to maintain that level of compatibility.

My 2nd guess would be someone really *loves* their SPARC workstation...

Re: [petsc-dev] those who use cmake are SANE

[C. Bergström]

On 11/12/13 03:20 AM, Matthew Knepley wrote:
On Mon, Nov 11, 2013 at 1:21 PM, Barry Smith bsm...@mcs.anl.gov 
mailto:bsm...@mcs.anl.gov wrote:



   Man o man, it is worse than autoconf (how is that possible?)


Its the essential masochism of programming, where shitty interfaces 
are elevated to
grand status because some people can cope with them. Notice that this 
phenomenon

also appears in mathematics.

Just a drive-by comment, but I can't help add to some flames to this
Are you people on drugs?

1) My personal hands on experience - I'd rather deal with cmake syntax 
than m4 any day of the week
2) cmake is super easy to bootstrap everywhere - autocrap and all the 
auto* stuff is a bitch by comparison
3) cmake is more or less portable and adding new backends is possible 
(ninja)
4) cmake projects typically lack the idiot proof ./configure --help 
option list, but there is ccmake (which I've never used). (Internally we 
overcome this with good documentation)

-
I know of some complaints about the cmake codebase itself - I'm not 
going to comment on those.


cmake may leave a rash, but better than having gangrene aka autoconf
--
More productively - Specific complaints about cmake? Have any of those 
complaints been raised on the cmake developers list? In my experience 
they are quite responsive

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

[C. Bergström]

On 01/10/13 11:23 AM, Barry Smith wrote:
 On Jan 9, 2013, at 10:19 PM, Dmitry Karpeevkarpeev at mcs.anl.gov  wrote:

 My summary would be that
 1. Git's ui is bad
 2. There is the crappy index thingie
 3.  I don't see how git branches are better than hg bookmarks (again, the ui 
 is bad).
 4. I still use multiple repos along with branches in git.
 5. I am willing to bet money Satish will use multiple repos, rather than 
 branches.
 Thanks. This is why I want to see Jed and Satish's mapping; I don't want 
 to change to git and then have a gotcha of but that was easy in hg but is a 
 big fucking pain in git and I have to do it every day.
Everyone on this list should know this is a bikeshed discussion.  
Someone should pick something - do the migration and announce it as done 
if possible.  Some people will be disgruntled for a while, workflows may 
change a bit and eventually everything settles down.
-
+1 git
-
Why
 github (project visibility, easy to fork, pull requests, features.. 
almost all devs I know have github id and few have bitbucket)
 More people are familiar with and using git than hg at this point
 it's good enough
-
(I think git has an illogical crap way of doing some things.  I never 
liked and still don't like git, but I've adjusted.)

/* Apologies for contributing to this bikeshed discussion */

./C

[petsc-dev] OpenMPI is a menace

[C. Bergström]

On 11/ 5/12 10:13 AM, Matthew Knepley wrote:
 I am tired of wasting time on their stupid bugs which we report but 
 are never fixed. Is there a way to retaliate without grenades?
Switch over to HPX?
http://stellar.cct.lsu.edu/tag/hpx/

I'm not sure it's at a point where it can handle petsc, but keep it in 
mind for 2013.  I'm cc'ing one of the devs who is probably not 
subscribed, but can answer questions.  (bandwidth permitting and maybe 
delayed until @SC12 or after)
---
Option 2 - We (PathScale) have been considering to take on shipping a 
supported version of OpenMPI for some time.  If anyone would be 
interested in add-on support or just paying a bounty to fix bugs - We 
may be able to work it out.  (Not the perfect open source answer, but 
maybe it's better (cheaper?) than grenades..

Which bugs are you specifically interested in getting fixed?

[petsc-dev] OpenMPI is a menace

[C. Bergström]

On 11/ 5/12 10:48 AM, Matthew Knepley wrote:

 On Sun, Nov 4, 2012 at 10:38 PM, C. Bergstr?m 
 cbergstrom at pathscale.com mailto:cbergstrom at pathscale.com wrote:


 Which bugs are you specifically interested in getting fixed?


 When they install to a non-standard location, they do not add RPATH 
 support for the
 library link in their compiler wrappers.
(That's really it?  You're going to throw a grenade over this?)

I just pulled the svn nightly tarball of OpenMPI and I'm wondering if of 
these below could be used to help?  Have you tried and it's buggy?  They 
seem to propagate to the wrapper scripts

   --with-wrapper-ldflags  Extra flags to add to LDFLAGS when using 
wrapper compilers
   --with-wrapper-libs Extra flags to add to LIBS when using wrapper 
compilers

[petsc-dev] OpenMPI is a menace

[C. Bergström]

On 11/ 5/12 10:55 AM, Jed Brown wrote:
 I just bumped the thread on this over on their mailing list.

 Educating users about LD_LIBRARY_PATH is a losing battle, in my opinion.
(I wholly agree and I wish -rpath matched Solaris -R behavior.  preload 
can be a slightly better alternative in some cases)  I'm still not 
getting exactly what's being done -

What  --prefix= is used to build openmpi?
Where is it installed?
Can the installed location be known at compile time?

[petsc-dev] OpenMPI is a menace

[C. Bergström]

On 11/ 5/12 11:02 AM, Matthew Knepley wrote:


 These don't solve the problem. Check the mailing list.

Please forward the emails/thread to me so I can catch-up.  I'll honestly 
try to resolve this if I can

[petsc-dev] OpenMPI is a menace

[C. Bergström]

On 11/ 5/12 12:21 PM, Bryce Lelbach wrote:

 When they install to a non-standard location, they do not add RPATH support
 for the
 library link in their compiler wrappers.
bingo - and users aren't setting 
--with-wrapper-ldflags=-Wl,-rpath,${prefix}/lib
-
imho it's a bug and should be considered a part of the minimal flags - 
Hopefully I can get Jeff's patch or that it gets finished/resolved 
before SC12

[petsc-dev] OT: Testers needed for PathScale ENZO 2012

[C. Bergström]

Hi

I'm hoping someone with some spare cycles and patience is willing to 
help test a nightly ENZO build with petsc.

Here's the nightly which won't require a key (It will ask, but it's 
optional)
http://c591116.r16.cf2.rackcdn.com/enzo/nightly/Linux/enzo-2012-09-18-installer.run

For BLAS we're testing against this (and in the future will ship our own 
built version)
https://github.com/xianyi/OpenBLAS/
--
I'm specifically looking for feedback on the GPGPU side of this and 
performance.  The reason why anyone would care - We've put a lot of work 
in performance for memory bound kernels, predictable latency and lowest 
latency.  (We don't generate any PTX and go direct to bare metal codegen 
tied with our own very small runtime.  We officially only support Tesla 
2050/2070 cards at this time, but ping me if you have another card you 
can test with)

You can replace nvcc with pathcu (We don't support the nvcc flags)

pathcu -c foo.cu # CUDA (Bugs found should be fixed quickly, but expect 
bugs - Thrust and CuSP testing also in progress)
pathcc/f90 -hmpp # OpenHMPP
pathcc/f90 -openacc # OpenACC and the flag will be changed to -acc soon

For more details, documentation and or bug reports please email me directly.

Cheers,


Christopher

[petsc-dev] OT: Testers needed for PathScale ENZO 2012

[C. Bergström]

On 09/19/12 08:05 AM, Barry Smith wrote:
 Good paper, 
 http://www.epcc.ed.ac.uk/wp-content/uploads/2011/11/PramodKumbhar.pdf, worth 
 reading
We dropped the ball on this and meeting their schedule was impossible 
for us (Section 1.5 of the paper Change in Project Plan)
-
(I'm extremely happy to see that they did end up publishing some nice work)