Re: numpy/scipy and mkl

[Sean Farley]

Ryan Schmidt  writes:

>> On Jun 11, 2016, at 10:11 AM, Gideon Simpson  
>> wrote:
>> 
>> I have an intel mkl license, and I know that numpy/scipy can be built 
>> against it for a performance boost. I was wondering two things:
>> 
>> 1.  Is it possible that we could have a variant of numpy/scipy that supports 
>> mkl, or is that fundamentally at odds with macports, since the mkl is 
>> commercial?
>
> I wouldn't be opposed to adding that option. MacPorts already contains 
> commercial software (like libxl, for which you must buy a license for certain 
> uses, and oracle-instantclient, which connects to a commercial database and 
> for which you must register and manually download the installer). I see there 
> are a number of ways we might get a copy of mkl for free to help us create 
> such a variant:
>
> https://software.intel.com/en-us/articles/free-mkl
>
> The question is whether all those packages contain the same or equivalent 
> software, such that a variant created for use with one of them would work 
> with the others as well.
>
> Another question is whether to code the variant to work with the files 
> installed by the Intel MKL installer in their normal locations, or whether we 
> should create a port for Intel MKL which would adjust the installation to 
> place the files inside the MacPorts prefix.

This is quite challenging, actually. MKL would be a replacement for
ATLAS or OpenBLAS, essentially but is insane to link against. You
basically have to ask an Intel webapp for how to link with MKL:

https://software.intel.com/en-us/articles/intel-mkl-link-line-advisor

I could try to help if someone wants to go down this long rabbit-hole
but I'm quite busy this summer.
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: py-hgsubversion install fails

[Sean Farley]

j. van den hoff  writes:

> on one of two machines (both running 10.10.5 and current `port')  
> installation of py-hgsubversion fails with (end of logfile):
>
> 8<--
> ...
> CC='/usr/bin/clang'
> CC_PRINT_OPTIONS='YES'
> CC_PRINT_OPTIONS_FILE='/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_python_py-hgsubversion/py27-hgsubversion/work/.CC_PRINT_OPTIONS'
> CFLAGS=''
> CPATH='/opt/local/include'
> CXX='/usr/bin/clang++'
> CXXFLAGS=''
> F90FLAGS=''
> FCFLAGS=''
> FFLAGS=''
> LDFLAGS=''
> LIBRARY_PATH='/opt/local/lib'
> MACOSX_DEPLOYMENT_TARGET='10.10'
> OBJC='/usr/bin/clang'
> OBJCFLAGS=''
> :debug:build Assembled command: 'cd  
> "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_python_py-hgsubversion/py27-hgsubversion/work/1.8.5"
>   
> &&  
> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7  
> setup.py --no-user-cfg build'
> :debug:build Executing command line:  cd  
> "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_python_py-hgsubversion/py27-hgsubversion/work/1.8.5"
>   
> &&  
> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7  
> setup.py --no-user-cfg build
> :info:build Traceback (most recent call last):
> :info:build   File "setup.py", line 106, in 
> :info:build from hgsubversion.svnwrap import svn_swig_wrapper
> :info:build   File  
> "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_python_py-hgsubversion/py27-hgsubversion/work/1.8.5/hgsubversion/__init__.py",
>   
> line 198, in 
> :info:build commands.optionalrepo += ' svn'
> :info:build AttributeError: 'module' object has no attribute 'optionalrepo'

This seems like a mismatch with Mercurial. Which version do you have
installed? Do you have Mercurial installed into /usr/local or something
like that?
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: py-hgsubversion install fails

[Sean Farley]

j. van den hoff <veedeeh...@gmail.com> writes:

> On Wed, 16 Mar 2016 19:41:39 +0100, Sean Farley <s...@macports.org> wrote:
>
>>
>> j. van den hoff <veedeeh...@gmail.com> writes:
>>
>>> on one of two machines (both running 10.10.5 and current `port')
>>> installation of py-hgsubversion fails with (end of logfile):
>>>
>>> 8<--
>>> ...
>>> CC='/usr/bin/clang'
>>> CC_PRINT_OPTIONS='YES'
>>> CC_PRINT_OPTIONS_FILE='/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_python_py-hgsubversion/py27-hgsubversion/work/.CC_PRINT_OPTIONS'
>>> CFLAGS=''
>>> CPATH='/opt/local/include'
>>> CXX='/usr/bin/clang++'
>>> CXXFLAGS=''
>>> F90FLAGS=''
>>> FCFLAGS=''
>>> FFLAGS=''
>>> LDFLAGS=''
>>> LIBRARY_PATH='/opt/local/lib'
>>> MACOSX_DEPLOYMENT_TARGET='10.10'
>>> OBJC='/usr/bin/clang'
>>> OBJCFLAGS=''
>>> :debug:build Assembled command: 'cd
>>> "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_python_py-hgsubversion/py27-hgsubversion/work/1.8.5"
>>> &&
>>> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7
>>> setup.py --no-user-cfg build'
>>> :debug:build Executing command line:  cd
>>> "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_python_py-hgsubversion/py27-hgsubversion/work/1.8.5"
>>> &&
>>> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7
>>> setup.py --no-user-cfg build
>>> :info:build Traceback (most recent call last):
>>> :info:build   File "setup.py", line 106, in 
>>> :info:build from hgsubversion.svnwrap import svn_swig_wrapper
>>> :info:build   File
>>> "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_python_py-hgsubversion/py27-hgsubversion/work/1.8.5/hgsubversion/__init__.py",
>>> line 198, in 
>>> :info:build commands.optionalrepo += ' svn'
>>> :info:build AttributeError: 'module' object has no attribute  
>>> 'optionalrepo'
>>
>> This seems like a mismatch with Mercurial. Which version do you have
>
> Mercurial Distributed SCM (version 3.7.2)
>
> $ which hg # ==> /opt/local/bin/hg
>
>> installed? Do you have Mercurial installed into /usr/local or something
>> like that?
>
> no, I have not: everything is installed via macports. in fact, the problem  
> appeared during today's `sudo port selfupdate; sudo port upgrade outdated'  
> run. maybe the error is related to some other dependency? only guessing,  
> of course ...

It must be picking up some python path because that error was introduced
in aa73d6a5d9ea in hg:

https://bitbucket.org/seanfarley/hg/commits/aa73d6a5d9ea

But that commit was after the 3.7.2 release. Certainly strange. I wonder
which path it's picking up.
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: py-hgsubversion install fails

[Sean Farley]

j. van den hoff  writes:

> if it helps, I'll type in everything you want (expect `/bin/rm -r'  I mean  
> ;-)) to get more info and solve the issue. just let me know (possibly  
> off-list as well).

My best guess at debugging would be to clean and extract the port:

$ sudo port -v clean py27-hgsubversion
$ sudo port -v extract py27-hgsubversion

Then edit the file that has the stacktrace to print out all the python
paths and modules (I forgot the variable names off the top of my head).

After you've editing that (perhaps printing it to stderr), try to
install again and hopefully it will print what it finds:

$ sudo port -v install py27-hgsubversion

Not sure what else to do besides that.
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: pypy 5.0.0 failing to build...

[Sean Farley]

Carlo Tambuatco  writes:

> Uninstalling pypy @4.0.1_0 and installing pypy @5.0.0 seems to have done the 
> trick.
>
> What went wrong?

It seems that pypy looks for an installed version.
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: pypy 5.0.0 failing to build...

[Sean Farley]

Carlo Tambuatco  writes:

> Upgrading pypy @4.0.1_0 to pypy @5.0.0 fails with following error:
>
> Building pypy
> Error: org.macports.build for port pypy returned: command execution failed
> Please see the log file for port pypy for details:
> 
> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_pypy/pypy/main.log
> Error: Unable to upgrade port: 1
>
> Attached is the log file

Ok, I added conflicts_build in r146539. Let me know if that works for you.
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: dolfin on el capitan

[Sean Farley]

Gideon Simpson  writes:

> Since vtk5 seems to be broken on el capitan, dolfin won’t install.  Is it 
> possible to work around that?

Is there a ticket for this? I have vtk5+python+tcltk installed just fine.
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: py33-scipy problem

[Sean Farley]

Jerry  writes:

> On Jan 21, 2016, at 9:20 PM, David Strubbe  wrote:
>
> David, thank you for this explanation. Installing py33-scipy +gfortran 
> worked. However, I have these notes.
>
>> As the message says, you need to select a Fortran variant. You have not. You 
>> can see this from the fact that the file trying to be fetched is 
>> py33-scipy-0.16.1_0.darwin_13.x86_64.tbz2 not 
>> py33-scipy-0.16.1_0+gcc48.darwin_13.x86_64.tbz2.
>
> No, I can't see this because I'm not schooled in the arcania of MacPorts. I'm 
> just a semi-sophisticated user following the admonishment to update his 
> MacPorts installation.
>
>> Yes, you had py33-scipy +gcc48 installed previously, and macports will try 
>> to use the same variants you had selected before when upgrading.
>
> I never selected any variants; any installation of py33-scipy was handled by 
> the ports system.
>
>> However, there is no longer a variant +gcc48 (as below). Therefore, you must 
>> choose one of the four currently existing Fortran variants. e.g. sudo port 
>> install py33-scipy +gfortran.
>
> Why is this not handled automatically? If I can type sudo port install 
> py33-scipy +gfortran and the upgrade script recognizes the problem then why 
> can't the upgrade script handle it?
>
> I humbly submit that this is poor design, and wonder why it is not a bug.

This is my fault and, indeed, a bug. I'll push a fix shortly.
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: IPython 4.0 and Jupyter in MacPorts

[Sean Farley]

Fielding, Eric J (329A)  writes:

> I only use IPython occasionally, so I just now found out that the new version 
> of IPython 4.0 has major changes, and MacPorts has installed the new version 
> in one of my port upgrades. We used to run “ipython notebook” to get the 
> notebook version of IPython, but this has been removed and we are supposed to 
> use a new program called Jupyter. I installed what I guessed is required to 
> use Jupyter with port install py34-jupyter and py34-ipykernel.
>
> Is there something else I need to install to be able to run the new command 
> “jupyter notebook”? The “jupyter” program is not in my path. I found 
> /opt/local/bin/jupyter-3.4, but “jupyter-3.4 notebook” says it does not know 
> “notebook”.

Looks like we need a `port select` group for the jupyter binaries. As
for you issue, it appears to be this bug:

https://github.com/jupyter/notebook/issues/448

which looks like the next release will fix.

For now, you can run jupyter-notebook-3.4 (assuming py34-notebook is
installed).

> The Jupyter documentation 
> (http://jupyter.readthedocs.org/en/latest/install.html) says to use pip to 
> install Jupyter, but I understand that this will likely mess up the MacPorts 
> installation.

Correct, please don't do that.
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: New Mac OS Forge administrator

[Sean Farley]

Ryan Schmidt  writes:

> Dear MacPorts users and developers,
>
> I'm pleased finally to be able to tell you that I have been hired to be your 
> new Mac OS Forge administrator. I have been involved in improving MacPorts 
> for years as a committer and as a manager, and now as a Mac OS Forge 
> administrator I will work on ensuring our infrastructure runs smoothly too.
>
> I apologize for the downtime we've experienced in the past months. My 
> priority right now is to resolve the existing issues, as I become familiar 
> with the systems.
>
> Please continue to report new problems with MacPorts infrastructure (server 
> not working) as you have before, using the server/hosting component in Trac 
> or via email to admin at macosforge dot org. And continue to report MacPorts 
> administrative issues (mailing list issues, commit access requests) to 
> portmgr at macports dot org.
>
> Thanks for your patience and support and thank you for using MacPorts.

This is great for MacPorts! Congrats!
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: MacPorts 2.3.4 has been released

[Sean Farley]

Joshua Root  writes:

> The MacPorts Project is pleased to announce the release of version
> 2.3.4. This is a bugfix release with small changes only. See the
> ChangeLog [1] for the list of changes.

Thanks man!
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: OS X 10.11 status

[Sean Farley]

Dominik Reichardt domi...@gmail.com writes:

 Hi,

 I’m itching to switch but often need MacPorts. Do any of you have experience 
 yet with it *AND* MacPorts?

Join the club :-(

 In previous switches, I switched by using the development version of MacPorts 
 and following the migration steps of any major OS X upgrade, still the way to 
 go?

Yep, still the way to go. Many things will have trouble building, fyi.
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: ipython notebook problem

[Sean Farley]

Peter Danecek peter.dane...@ingv.it writes:

 Any news on this?
 Or should I have a look at it?

Ack, I completely forgot about this. If you can do it, that'd be great.
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: ipython notebook problem

[Sean Farley]

Peter Danecek peter.dane...@ingv.it writes:

 Hi all,
 should this thread become a ticket?
 This issue was observed by a one of my colleagues as well. I have not YET run 
 into it.

I was going to get around to doing it tonight at our python group
meetup, if no one else got to it before then.
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: ipython notebook problem

[Sean Farley]

Gideon Simpson gideon.simp...@gmail.com writes:

 This appears to have something to do with the recent upgrade of 
 py27-jsonschema from 2.4.0 to 2.5.1.  As soon as I downgraded this to the 
 earlier version, things ran as they had in the past.
 -gideon

Yep, it would seem there is a new dependency based on this commit:

https://github.com/Julian/jsonschema/commit/e2a604f7ebc230e811ec6af15ac20551553b8a81
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: dolfin 1.5.0 and OS X 10.9

[Sean Farley]

Gideon Simpson writes:

 On one my machines I still have 10.9 installed and with the recent update to 
 dolfin (which works fine on my 10.10 machine), I now get errors during the 
 build: 

 _opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_dolfin/dolfin/work/dolfin-1.5.0/build/dolfin/swig/modules/function
   /opt/local/bin/swig -python -module function -shadow -modern -modernargs 
 -fastdispatch -fvirtual -nosafecstrings -noproxydel -fastproxy -fastinit 
 -fastunpack -fastquery -nobuildnone -Iinclude/swig -DBOOST_UBLAS_NDEBUG 
 -DDOLFIN_SIZE_T=8 -DDOLFIN_LA_INDEX_SIZE=4 -DHAS_UMFPACK -DHAS_CHOLMOD 
 -DHAS_ZLIB -DHAS_MPI -DHAS_QT4 -DHAS_VTK -DNUMPY_VERSION_MAJOR=1 
 -DNUMPY_VERSION_MINOR=8 -DNUMPY_VERSION_MICRO=2 
 -DNPY_NO_DEPRECATED_API=NPY_1_8_API_VERSION -outdir 
 /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_dolfin/dolfin/work/dolfin-1.5.0/build/dolfin/swig/modules/function
  -c++ 
 -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_dolfin/dolfin/work/dolfin-1.5.0/build
  -I/opt/local/include -I/opt/local/include/QtGui -I/opt/
 lo
  cal/include/QtCore -I/opt/local/include/vtk-6.1 -I/usr/include/python2.7 
 -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_dolfin/dolfin/work/dolfin-1.5.0
  -I/opt/local/include/libxml2 
 -I/opt/local/Library/Frameworks/Python.framework/Versions/2.7/include 
 -I/opt/local/include/mpich-mp -I/opt/local/include/eigen3 
 -I/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/include
  
 -I/opt/local/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7
  -o 
 /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_dolfin/dolfin/work/dolfin-1.5.0/build/dolfin/swig/modules/function/modulePYTHON_wrap.cxx
  
 /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_dolfin/dolfin/work/dolfin-1.5.0/build/dolfin/swig/modules/function/module.i
 :info:build 
 /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_dolfin/dolfin/work/dolfin-1.5.0/build/dolfin/swig/modules/la/module.i:137:
  Error: Unable to find 'dolfin/swig/la/docstrings.i'
 :info:build 
 /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_dolfin/dolfin/work/dolfin-1.5.0/build/dolfin/swig/modules/la/module.i:138:
  Error: Unable to find 'dolfin/swig/nls/docstrings.i'
 :info:build make[2]: *** [dolfin/swig/modules/la/modulePYTHON_wrap.cxx] Error 
 1
 :info:build make[2]: Leaving directory 
 `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_dolfin/dolfin/work/dolfin-1.5.0/build'
 :info:build make[1]: *** [dolfin/swig/modules/la/CMakeFiles/_la.dir/all] 
 Error 2
 :info:build make[1]: *** Waiting for unfinished jobs
 :info:build 
 /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_dolfin/dolfin/work/dolfin-1.5.0/build/dolfin/swig/modules/common/module.i:78:
  Error: Unable to find 'dolfin/swig/common/docstrings.i'
 :info:build 
 /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_dolfin/dolfin/work/dolfin-1.5.0/build/dolfin/swig/modules/common/module.i:79:
  Error: Unable to find 'dolfin/swig/parameter/docstrings.i'
 :info:build 
 /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_dolfin/dolfin/work/dolfin-1.5.0/build/dolfin/swig/modules/common/module.i:80:
  Error: Unable to find 'dolfin/swig/log/docstrings.i'
 :info:build make[2]: *** [dolfin/swig/modules/common/modulePYTHON_wrap.cxx] 
 Error 1
 :info:build make[2]: Leaving directory 
 `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_dolfin/dolfin/work/dolfin-1.5.0/build'
 :info:build make[1]: *** 
 [dolfin/swig/modules/common/CMakeFiles/_common.dir/all] Error 2
 :info:build 
 /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_dolfin/dolfin/work/dolfin-1.5.0/build/dolfin/swig/modules/mesh/module.i:160:
  Error: Unable to find 'dolfin/swig/mesh/docstrings.i'
 :info:build 
 /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_dolfin/dolfin/work/dolfin-1.5.0/build/dolfin/swig/modules/mesh/module.i:161:
  Error: Unable to find 'dolfin/swig/generation/docstrings.i'
 :info:build 
 /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_dolfin/dolfin/work/dolfin-1.5.0/build/dolfin/swig/modules/mesh/module.i:162:
  Error: Unable to find 

Re: Processing of port freecad fails

[Sean Farley]

Ryan Schmidt writes:

 On Jan 9, 2015, at 1:16 PM, Marius Schamschula wrote:
 
 freecad used to declare +gcc48 as the default variant until  
 https://trac.macports.org/changeset/130949 was committed. Given that this 
 change set deleted fortran related default variants for a number of 
 packages, we will likely hear about these in the near future.

 Actually, in that revision, setting the default compiler variant was moved 
 from the individual portfiles to the compilers portgroup.

 Then in r130953 the default was changed from gcc48 to gcc49. But what about 
 the ports like freecad that don't have a gcc49 variant?

Welp, that's unintended. In cases like these, I imagined portfile
authors would override and add their own default variant. I'm a little
busy now, so if someone feels encouraged they can add it back.

A longer term fix would be to test for gcc49 and work backwards to
gcc48, etc.

Is there a reason why +gfortran was left out?
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Processing of port freecad fails

[Sean Farley]

Ryan Schmidt writes:

 On Jan 9, 2015, at 1:34 PM, Sean Farley wrote:
 
 Ryan Schmidt writes:
 
 On Jan 9, 2015, at 1:16 PM, Marius Schamschula wrote:
 
 freecad used to declare +gcc48 as the default variant until  
 https://trac.macports.org/changeset/130949 was committed. Given that this 
 change set deleted fortran related default variants for a number of 
 packages, we will likely hear about these in the near future.
 
 Actually, in that revision, setting the default compiler variant was moved 
 from the individual portfiles to the compilers portgroup.
 
 Then in r130953 the default was changed from gcc48 to gcc49. But what about 
 the ports like freecad that don't have a gcc49 variant?
 
 Welp, that's unintended. In cases like these, I imagined portfile
 authors would override and add their own default variant. I'm a little
 busy now, so if someone feels encouraged they can add it back.
 
 A longer term fix would be to test for gcc49 and work backwards to
 gcc48, etc.
 
 Is there a reason why +gfortran was left out?

 My guess is that a gcc49 variant could be added to freecad and that it would 
 work fine. I guess gcc49 wasn't stable when freecad's default of gcc48 was 
 chosen. But if you're leaving it up to each port to decide which variants to 
 provide, then you have to either let each port decide which of them is the 
 default, or else have much more intelligent logic in the portgroup to pick 
 the best one as the default, and not make assumptions about which variants 
 exist.

I agree. I'll update the portgroup accordingly.
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Yosemite buildbot?

[Sean Farley]

Brandon Allbery writes:

 On Sun, Oct 19, 2014 at 8:52 PM, Jason Mitchell jason-macpo...@maiar.org
 wrote:

 Is there a buildbot in the works for Yosemite ports?  I checked
 https://build.macports.org/buildslaves but didn't see anything for
 Yosemite yet.  Maybe I've  misunderstood the process, or am just being
 greedy?


 It was requested; they're waiting on Apple to provision it.

Any update on this?
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Installing Metis V4

[Sean Farley]

Jeremy Lavergne writes:

 It seems parmetis is still version 4.0.3.

Unfortunately, parmetis is not the same as metis. George decided to keep
two separate projects. I have done the leg work to make parmetis depend
on metis.

 On Oct 23, 2014, at 10:01 AM, L.Bryce Whitson Jr. wrote:

 I have a need to install Metis V4 for a project that I am working on right
 now. I notice that the Metis in Macports is V5 and unfortunately the code I
 have won't compile under V5. Is there an easy way to install V4 using the
 Macports infrastructure?

The upgrade isn't that bad, actually. Which project is this? If it's a C
project, you can look at the SuiteSparse port to see how I patched it to
work with metis 5.x. If it's fortran, take a look at mumps.
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: dolfin petsc

[Sean Farley]

Gideon Simpson writes:

 I have macports petsc 3.5.2 installed, and i tried installing  sudo port 
 install dolfin +mpich +suitesparse +petsc +slepc.  I got an error that looks 
 like there was some break in the functionality of Petsc, at least with regard 
 to dolfin:

 _opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_dolfin/dolfin/work/dolfin-1.4.0/dolfin/la/STLFactory.cpp
 :info:build 
 /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_dolfin/dolfin/work/dolfin-1.4.0/dolfin/la/PETScKrylovSolver.cpp:528:62:
  error: use of undeclared identifier 'SAME_PRECONDITIONER'
 :info:build ierr = KSPSetOperators(_ksp, _matA-mat(), _matP-mat(), 
 SAME_PRECONDITIONER);


 The log file is a bit too large to attach.

It looks like this is just outdated but I can't test because dolfin is
currently broken due to scientific python (will be fixed in the next
release).

Either way, can you create a ticket for this so I can track it?
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Error installing petsc

[Sean Farley]

Daniel Watkins writes:

 I attempted to install petsc using the command
 sudo port install petsc +mpich +superlu +suitesparse
 and was unsuccessful. The log file is attached.

Ouch. This appears to be a compiler bug with clang. What OS and version
of Xcode are you running?
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: dolfin issue

[Sean Farley]

Ryan Schmidt writes:

 On Sep 29, 2014, at 7:45 PM, Gideon Simpson wrote:
 
 I don’t seem to have that file

 Ok, looks like the compiler name is just being specified as mpicc-mpich-mp, 
 without a path, and cmake is incorrectly inferring that it is in the build 
 directory.

 Do you have any of the mpich ports installed?

 port installed name:mpich

 Do any of them provide this file?

The issue is that dolfin needs a clean configure. I don't know why it
has trouble with this (do any cmake people know?). Try 'port clean
dolfin' before attempting to build dolfin again.
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: dolfin issue

[Sean Farley]

Gideon Simpson writes:

 I did a port uninstall and a port clean, and I got the same error.

Huh. I'll try to reproduce this, then.

 I do have petsc/slepc installed with mpich, if that’s part of the problem.  I 
 suspect that petsc is built as a C library, while dolfin is C++.  Perhaps 
 that’s the incompatibility?

It's perfectly fine to link C to C++. Dolfin has been doing this with
PETSc for years.
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: fortran compiler for f2py

[Sean Farley]

Clemens Lang writes:

 Hi,

 Run port select to read the help message about the select mechanism. I
 would think it's also documented elsewhere in more detail, though not,
 apparently, via port help select.

 It is, in 2.3.1, but not in trunk. See
   
 http://trac.macports.org/browser/branches/release_2_3/base/src/port/port-help.tcl
 for the message you are looking for. I'm working on getting those manpages
 written. Help very welcome.

Quick question: is this going to finally remove the doc-new folder?
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: can't upgrade py27-zmq

[Sean Farley]

Comer Duncan comer.dun...@gmail.com writes:

 I have today run across a failure to update py27-zmq.  The output seems
 non-instructive so I am hoping to get some help.  I paste the output of my
 attempt here:

 comermacpro:MarkFiniteDiffDerivativs comerduncan$ sudo port upgrade py27-zmq

Ah, there's your problem: finite difference. All the cool kids use
finite elements!
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: MacPorts automake and python

[Sean Farley]

Adam Mercer r...@macports.org writes:

 Hi

 Since automake was bumped to 1.14.1_1 it can't be used to build any
 python software outside of MacPorts as it always tries to install the
 python modules into MacPorts prefix. I understand why we want to
 ensure that ports always installs modules into the MacPorts prefix,
 but I can't understand why we would force this for everything using
 MacPorts python.

 When I questioned this I was told that I should be using a non
 MacPorts python if I don't want the modules to end up in the MacPorts
 prefix? If that is the case what's the point of MacPorts? I was under
 the impression that the goal of the project was to provide an
 easy-to-use system for compiling, installing, and upgrading either
 command-line, X11 or Aqua based open-source software on the OS X
 operating system. But now I'm getting told that I shouldn't be using
 MacPorts but I should be installing things locally if I don't want to
 install modules into the MacPorts prefix.

 This change seems like a very bad idea and is surely going to cause
 problems down the line, in fact at work several users have already
 been bitten by this.

I tend to agree with you but need help seeing how this worked
before. What path did automake pick up before this change?
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: MacPorts automake and python

[Sean Farley]

Adam Mercer r...@macports.org writes:

 On Thu, Mar 20, 2014 at 2:55 PM, Sean Farley s...@macports.org wrote:

 I tend to agree with you but need help seeing how this worked
 before. What path did automake pick up before this change?

 If you look at the patch you can see the original paths:

 http://trac.macports.org/browser/trunk/dports/devel/automake/files/patch-m4-python.m4.diff

 The original paths are:

 AC_SUBST([PYTHON_PREFIX], ['${prefix}'])
 AC_SUBST([PYTHON_EXEC_PREFIX], ['${exec_prefix}'])

 Just to clarify this isn't the MacPorts prefix but the prefix for the
 running configure process.

Right, sorry, I meant more along the lines of:

Before: my project installed into /path/foo/a
After:  my project installed into /path/foo/b
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: help on 'Xcode tool not installed'

[Sean Farley]

Shiyuan gshy2...@gmail.com writes:

 Hi all,
 I am on Mac 10.8.5 and Xcode 5.0.2 is installed. From Xcode
 Preference/Downloads, I can see that the command line tool is installed. I
 also installed again the command line too (released in 10/2013)l from the
 following link
 https://developer.apple.com/downloads/index.action#

 However,
 when I try to run 'sudo port  install py27-scipy', I got the error,
 ---
 Warning: The Command Line Tools for Xcode don't appear to be installed;
 most ports will likely fail to build.
 Warning: See http://guide.macports.org/chunked/installing.xcode.html for
 more information.
 ---  Computing dependencies for py27-scipy
 Error: Dependency 'python27' not found.
 To report a bug, follow the instructions in the guide:
 http://guide.macports.org/#project.tickets
 Error: Processing of port py27-scipy failed
 

 I use svn instead of rsync for sources and `port -d sync` runs
 successfully.

 Any help is appreciated.

Have you accepted the license yet? This is the command:

$ sudo xcodebuild -license
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: building my own ports of py27-matplotib and py27-numpy

[Sean Farley]

On Thu, Nov 14, 2013 at 8:29 PM, Arturo Rinaldi arty.n...@gmail.com wrote:
 Il 15/11/13 01:37, Ryan Schmidt ha scritto:

 On Nov 14, 2013, at 15:27, Arturo Rinaldi wrote:

 Hi folks, I need some help to build my own port of these two packages. I
 want to update them to their latest version (1.3.1 and 1.8.0 respectively)
 and I was using as basis the original Portfile file, we all know that just a
 few tweaks are necessary to achieve this goal.

 I only changed the version and the chekcsum in the Portfile, but it's not
 enough…..

 That sounds like a good first step. Why didn’t it work? What error did you
 receive?



 CRC error..there's a mismatch between the one detected by macports and
 the one calculted by my checksum tool from the shell :

 $ shasum -a 256 numpy-1.8.0.tar.gz

 returns :

 2764d0819acc77e9ff81b060fe7f69530b0d85c26ac9d162639b787cb227d253

 for the tar.gz file which is not the one macpors asks for. I am attaching my
 custom Portfile to show you my changes….

I've been busy with travel but am close to pushing the matplotlib
changes (#40802). I'll look at the numpy changes soon as well.
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Suggestion: Time to Use Trello?

[Sean Farley]

On Wed, Jun 26, 2013 at 7:27 AM, Rainer Müller rai...@macports.org wrote:
 On 2013-06-26 13:19, Rodolfo Aramayo wrote:
 Many projects out there are transitioning to trello

 https://trello.com/

 What the heck does it do? The website tells me something about
 organizing things. There seems to be an app, but also a web page, so is
 it a service? Sorry, but I am unable to figure out what this is.

 Anyway, how would this be helpful in the context of using MacPorts?

Changing topics a bit, has anyone here tried Phrabricator:

https://phabricator.org

It's the software used internally by Facebook and looks neat. It would
aim at replacing the current Trac workflow. I've installed it on my
own site to play around with and could configure it to link up with
the macports subversion repo if anyone is interested in seeing it in
action.
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: emacs-mac-app port build failure

[Sean Farley]

Marion Dumas writes:

 Hello,

 I wanted to de-install and re-install Emacs on my mac (10.5.8). I de- 
 installed Emacs.app by simply deleting the contents. I then downloaded  
 the emacsformac dmg installer but it just doesn't work: the  
 application crashes at launch. I tried installing through macports and  
 it fails to build.

 Error: org.macports.build for port emacs-mac-app returned: command  
 execution failed Please see the log file for port emacs-mac-app for  
 details:

   Error: Processing of port emacs-mac-app failed

 After that, I tried looking for other emacs related files on my  
 computer in case they were conflicting with the new ones (so removing / 
 usr/bin/emacs and /usr/share/emacs), but that didn't help.

 Thanks for any tips! I am befuddled

 I'm attaching the log file.

Thanks for the report. It looks like I missed libxml, ncurses, and
gnutls as dependencies. I'll try to get a fix out today (and also update
to the newest version).
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: emacs-mac-app port build failure

[Sean Farley]

On Thu, Feb 14, 2013 at 4:04 PM, Lawrence Velázquez lar...@macports.org wrote:
 On Feb 14, 2013, at 4:44 PM, Marion Dumas mario...@gmail.com wrote:

 I wanted to de-install and re-install Emacs on my mac (10.5.8). I 
 de-installed Emacs.app by simply deleting the contents. I then downloaded 
 the emacsformac dmg installer but it just doesn't work: the application 
 crashes at launch. I tried installing through macports and it fails to build.

 Error: org.macports.build for port emacs-mac-app returned: command execution 
 failed Please see the log file for port emacs-mac-app for details:

  Error: Processing of port emacs-mac-app failed

 You should file a ticket for this. Attach the main.log.

 http://guide.macports.org/chunked/project.html#project.tickets

Yes, please do, Marion. That would help us keep track of issues with
repository history.

 After that, I tried looking for other emacs related files on my computer in 
 case they were conflicting with the new ones (so removing /usr/bin/emacs and 
 /usr/share/emacs), but that didn't help.

 Thanks for any tips! I am befuddled

 You can start by ceasing your haphazard rampage through your system. You just 
 deleted the system emacs. Hope you didn't use rm.

Yes, totally agree with Lawrence here!
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Side effects?

[Sean Farley]

On Thu, Jan 31, 2013 at 7:34 PM, Ian Wadham iandw...@gmail.com wrote:
 On 01/02/2013, at 11:05 AM, Ryan Schmidt wrote:
 On Jan 31, 2013, at 16:53, Ian Wadham wrote:
 I did sudo port install -k -s pallet

 Single-letter flags like -k and -s have no effect unless you put them 
 immediately after the word port.

 sudo port -k -s install Pallet

 Oops. That's what I actually commanded but not what I emailed.

 I am unfamiliar with both Objective C and the Macports structure … :-(

 However, I am familiar with C++, Qt and Qt Designer (a forms designer
 and code generator for Qt-based GUIs).  Is there a forms designer for
 Mac, BTW?  Hand-coding of widgets can be laborious ...

 Interface Builder. It's part of Xcode.

 http://en.wikipedia.org/wiki/Interface_Builder

 Thanks, Ryan.  That looks good.  It's not exactly lying around on the surface
 in Xcode, though.  FWICG, you have to use File-New… and ask for a XIB
 file(?).

 Or maybe I could prototype in C++ and Qt while boning up on Xcode
 and Cocoa …  BTW I have OS X 10.7.5 Lion and Xcode 4.2.1.  Would
 those be OK as a platform, from Macports' point of view?

 Yes, but please update to Xcode 4.6. It's a free update for Lion or Mountain 
 Lion users on the Mac App Store or at Apple Developer Connection.

 Will do.

 My opinion is that cross-platform frameworks like Qt or wxWidgets or Java 
 result in programs that don't look at home on any platform, especially not 
 OS X which has a very specific interface design aesthetic, and which are 
 also far larger and slower than if they had been written to the target OS 
 directly. If cross-platform compatibility is your primary interest and you 
 cannot afford to create separate native interfaces for each of your target 
 platforms then so be it. But for a MacPorts GUI, which need only run on OS 
 X, I strongly suspect that the best user experience will result from writing 
 in Objective-C with Cocoa.

 I tend to agree in this case.  No need for a Macports GUI to be 
 cross-platform.

 However, for me there is a learning curve to be climbed on Objective C, Cocoa
 and Xcode.  I don't know if I have the energy for that.  I will be 75 next 
 month and
 I wrote my first computer program about 50 years ago in Autocoder on a Ferrant
 Sirius, which is now in a local museum.  So don't expect too much … :-)

I just want to point out that this is where having a gui that is open
source would really help: the responsibility wouldn't have to be
shouldered by just one person.
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Side effects?

[Sean Farley]

On Thu, Jan 31, 2013 at 8:25 PM, Lawrence Velázquez lar...@macports.org wrote:
 On Jan 31, 2013, at 8:46 PM, Sean Farley s...@macports.org wrote:

 I just want to point out that this is where having a gui that is open
 source would really help: the responsibility wouldn't have to be
 shouldered by just one person.

 This is technically true, but GUI development is one broth that is *very* 
 easily spoiled by too many cooks.

Yeah, that's a fair point.
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Using -std=c++11 with the macports gcc-4.7 compiler

[Sean Farley]

On Wed, Jan 16, 2013 at 7:16 PM, Jeremy Huddleston Sequoia
jerem...@apple.com wrote:

 On Jan 15, 2013, at 8:52 AM, Sean Farley s...@macports.org wrote:

 On Mon, Jan 14, 2013 at 8:32 AM, David Barto dba...@visionpro.com wrote:
 fails because the /usr/lib/libstdc++.so is found first. What can I do to
 find the proper /opt/local/lib/libstdc++.so?

 I've not modified the search paths in any way, I'm just trying to compile a
 c++ program using the newer standard features.

 Hmm, I can't reproduce this error. Using no special environment
 variables and just a vanilla install of gcc47 on Mountain Lion, I get:

 snip /

 Yeah, all of the MacPorts gcc compilers should be using 
 /opt/local/lib/libstdc++.dylib instead of /usr/libstdc++.dylib.  This should 
 just work … if you're seeing something differnet, it would be helpful to 
 see how ld is being called by the compiler.  Run:

 g++-mp-4.7 -std=c++11 test11.cxx -v -Wl,-v

 ---

 That being said, is there something wrong with clang++ that is causing you to 
 try g++ instead?

Jeremy, please understand that this is a frustrating position / stance
to have from the perspective of the user. In the scientific community,
it is *expected* to try out all the compilers you have access to.
Usually, this just means Intel, Portland Group, IBM, and gcc; but now
it also includes clang. Also, there are _tons_ of reasons that
projects use different compilers. The most common is fortran (don't
even get me started on Apple stripping out gfortran from gcc 4.2 AND
THEN providing a bogus mpif{77,90} wrapper). If your project has both
C++ and Fortran dependencies, then the only way to compile the Fortran
is to install gcc4X. Well, that usually means your configure script
will also pick up gcc4X's C/C++ compiler.

The second most common reason I've seen is the one you mention: errors
in the C++ compiler. If Apple decides to update their Xcode clang
version to 3.1 or later anytime soon, then everyone on a mac will run
into this bug,

http://llvm.org/bugs/show_bug.cgi?id=14768

I personally have had clang++ bugs with libmesh, moose, armadillo, and
dolfin. What makes this sentiment frustrating is the whole use this
one version of the library with no optimization or debug control
which is at odds with try this library with {gcc,clang,etc.}'s
-O{1,2,3} and then write a paper about the results. This actually was
my whole motivation for writing scienceports: provide a way to use a
library with gcc4X or clang3X and somehow manage the combinatorial
explosion of variants (the correct data structure, by the way, is a
DAG).

Ok, this rant is too long now. I hope no one is offended as I tried to
explain some of the science community's frustration.
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-users

Re: Using -std=c++11 with the macports gcc-4.7 compiler

[Sean Farley]

On Wed, Jan 16, 2013 at 9:19 PM, Jeremy Huddleston Sequoia
jerem...@macports.org wrote:

 On Jan 16, 2013, at 17:49, Sean Farley s...@macports.org wrote:

 On Wed, Jan 16, 2013 at 7:16 PM, Jeremy Huddleston Sequoia
 jerem...@apple.com wrote:

 On Jan 15, 2013, at 8:52 AM, Sean Farley s...@macports.org wrote:

 On Mon, Jan 14, 2013 at 8:32 AM, David Barto dba...@visionpro.com wrote:
 fails because the /usr/lib/libstdc++.so is found first. What can I do to
 find the proper /opt/local/lib/libstdc++.so?

 I've not modified the search paths in any way, I'm just trying to compile 
 a
 c++ program using the newer standard features.

 Hmm, I can't reproduce this error. Using no special environment
 variables and just a vanilla install of gcc47 on Mountain Lion, I get:

 snip /

 Yeah, all of the MacPorts gcc compilers should be using 
 /opt/local/lib/libstdc++.dylib instead of /usr/libstdc++.dylib.  This 
 should just work … if you're seeing something differnet, it would be 
 helpful to see how ld is being called by the compiler.  Run:

 g++-mp-4.7 -std=c++11 test11.cxx -v -Wl,-v

 ---

 That being said, is there something wrong with clang++ that is causing you 
 to try g++ instead?

 Jeremy, please understand that this is a frustrating position / stance
 to have from the perspective of the user.  In the scientific community,
 it is *expected* to try out all the compilers you have access to.
 Usually, this just means Intel, Portland Group, IBM, and gcc; but now
 it also includes clang.

 Whoa … I'm simply asking if you're using g++ because you came across a bug in 
 clang++ … there's no reason to get jumpy.  I, myself, test with a huge 
 variety of compilers in order to discover potential code generation issues 
 before they effect average developers.  Don't bite me for asking.

Apologies if that was too harsh. I didn't mean to sound like I was
biting back, but rather was trying to start a dialogue / point out a
different reasoning for multiple compilers. No offense / attack was
meant; sorry.

 Also, there are _tons_ of reasons that
 projects use different compilers. The most common is fortran (don't
 even get me started on Apple stripping out gfortran from gcc 4.2 AND
 THEN providing a bogus mpif{77,90} wrapper). If your project has both
 C++ and Fortran dependencies, then the only way to compile the Fortran
 is to install gcc4X. Well, that usually means your configure script
 will also pick up gcc4X's C/C++ compiler.

 The second most common reason I've seen is the one you mention: errors
 in the C++ compiler. If Apple decides to update their Xcode clang
 version to 3.1 or later anytime soon

 XCode 4.5 (and I think 4.4) was based on llvm 3.1

 , then everyone on a mac will run into this bug,

 http://llvm.org/bugs/show_bug.cgi?id=14768

 The compiler distributed with Xcode has assertions disabled by default, so 
 end users are likely to not trip over that assertion.  What affect that 
 actually has on generated code, I don't know… but thanks for pointing that 
 out to me.

Ah, that would explain why there's no crash for the Apple compiler.
Thanks for explaining that.

 I personally have had clang++ bugs with libmesh, moose, armadillo, and
 dolfin.

 There are plenty of g++ bugs as well ;) … have you filed radars (or at least 
 llvm bugzilla reports) about all of the clang issues you are finding?  Can 
 you point me to them?

Unfortunately, 1) I didn't report them at the time (and can't
reproduce) and 2) some of the repos are private :-(

 What makes this sentiment frustrating is the whole use this
 one version of the library with no optimization or debug control
 which is at odds with try this library with {gcc,clang,etc.}'s
 -O{1,2,3} and then write a paper about the results.

 I'm not really sure I know what you're referring to with the above sentence.

Ah, I meant to explain the need for having multiple versions of a
library / program with different optimization levels for numerical
computation.

 This actually was
 my whole motivation for writing scienceports: provide a way to use a
 library with gcc4X or clang3X and somehow manage the combinatorial
 explosion of variants (the correct data structure, by the way, is a
 DAG).

 How are you planning to manage the inherent difficulty with some clients 
 using libstdc++ and libc++?  It's possible for two separate libraries to use 
 different C++ runtime versions so long as they're not passing objects back 
 and forth, but most of the time, libraries that are implemented in C++ 
 provide C++ APIs to that library.

You are right to point out that a DAG alone won't solve compatibility
issues. I just meant that it's impossible to do correct dependency
analysis without having (or having something isomorphic to) a DAG.

 Ok, this rant is too long now. I hope no one is offended as I tried to
 explain some of the science community's frustration.

 Please try to be specific about issues you are concerned with.

Agreed, I'll try to be more specific.

 The bug you

Re: Using -std=c++11 with the macports gcc-4.7 compiler

[Sean Farley]

On Wed, Jan 16, 2013 at 9:32 PM, Ryan Schmidt ryandes...@macports.org wrote:

 On Jan 16, 2013, at 19:49, Sean Farley wrote:

 On Wed, Jan 16, 2013 at 7:16 PM, Jeremy Huddleston Sequoia wrote:

 That being said, is there something wrong with clang++ that is causing you 
 to try g++ instead?

 Jeremy, please understand that this is a frustrating position / stance
 to have from the perspective of the user. In the scientific community,
 it is *expected* to try out all the compilers you have access to.
 Usually, this just means Intel, Portland Group, IBM, and gcc; but now
 it also includes clang. Also, there are _tons_ of reasons that
 projects use different compilers. The most common is fortran (don't
 even get me started on Apple stripping out gfortran from gcc 4.2 AND
 THEN providing a bogus mpif{77,90} wrapper). If your project has both
 C++ and Fortran dependencies, then the only way to compile the Fortran
 is to install gcc4X. Well, that usually means your configure script
 will also pick up gcc4X's C/C++ compiler.

 The second most common reason I've seen is the one you mention: errors
 in the C++ compiler. If Apple decides to update their Xcode clang
 version to 3.1 or later anytime soon, then everyone on a mac will run
 into this bug,

 http://llvm.org/bugs/show_bug.cgi?id=14768

 I personally have had clang++ bugs with libmesh, moose, armadillo, and
 dolfin. What makes this sentiment frustrating is the whole use this
 one version of the library with no optimization or debug control
 which is at odds with try this library with {gcc,clang,etc.}'s
 -O{1,2,3} and then write a paper about the results. This actually was
 my whole motivation for writing scienceports: provide a way to use a
 library with gcc4X or clang3X and somehow manage the combinatorial
 explosion of variants (the correct data structure, by the way, is a
 DAG).

 Ok, this rant is too long now. I hope no one is offended as I tried to
 explain some of the science community's frustration.

 That's a valuable and valid viewpoint, and a totally reasonable answer to 
 Jeremy's question. The need or want to compile some programs with different 
 compilers or different compiler settings is a valid reason not to use clang. 
 I'm guessing only a minority of our users are interested in that, and that 
 only a minority of software would significantly benefit from such 
 optimization, but that doesn't make it unimportant.

Thanks :-) There's a bit of a catch-22 here: most scientists don't use
macports because of the need to do this kind of operation; so there
could be more users that macports had. By the way, something like 90%
of the people working at Argonne have MacBooks (thank you, Taxpayers!)

You are right that most software wouldn't benefit from changing the
optimization level. It's even arguable about the numeric software but
that's another issue. Your domain is pretty much limited to dense
linear algebra or embarrassingly parallel data structures (e.g.
bioinformatics). That, of course, doesn't change people's minds that
they need it.

Anyway, if I understand it correctly, having multiple versions of a
library is basically equivalent to issue 126 :-) I was able to dance
around that issue by making a port group, though.

 But we must also understand Jeremy's viewpoint. You can see from his email 
 address where he works. Clang is the compiler that OS X will use from now on; 
 Xcode does not come with gcc anymore. So Apple clearly wants as much software 
 to be compilable with Clang as possible, and wants to fix any bugs that are 
 found with regard to that.

Sorry; I didn't mean to sound so critical. Perhaps it comes from the
long standing resentment about not including fortran and shipping a
broken mpi wrapper for two OS X versions :-( What I was more or less
trying to convey is the desire / need for easily switching compilers.
That will take much more discussion, though.
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-users

Re: Using -std=c++11 with the macports gcc-4.7 compiler

[Sean Farley]

On Wed, Jan 16, 2013 at 10:06 PM, Jeremy Huddleston Sequoia
jerem...@macports.org wrote:

 On Jan 16, 2013, at 19:44, Sean Farley s...@macports.org wrote:
 I personally have had clang++ bugs with libmesh, moose, armadillo, and
 dolfin.

 There are plenty of g++ bugs as well ;) … have you filed radars (or at 
 least llvm bugzilla reports) about all of the clang issues you are finding? 
  Can you point me to them?

 Unfortunately, 1) I didn't report them at the time (and can't
 reproduce) and 2) some of the repos are private :-(

 With newer versions of clang, it will output the preprocessed source and a 
 shell script to run to reproduce the issue with the preprocessed source.  If 
 it's not private, simply providing those two files (source and script) are a 
 big help to the developers.  If it is private, you can hopefully come up with 
 a reduced test case within 10 minutes or so and submit that.  Also, you may 
 feel more comfortable submitting pseudo-private test cases to 
 bugreport.apple.com rather than the llvm bugzilla as it will then be between 
 you and Apple.

I did not know that. That's pretty awesome, actually. I'll have to
keep it in mind.

 What makes this sentiment frustrating is the whole use this
 one version of the library with no optimization or debug control
 which is at odds with try this library with {gcc,clang,etc.}'s
 -O{1,2,3} and then write a paper about the results.

 I'm not really sure I know what you're referring to with the above sentence.

 Ah, I meant to explain the need for having multiple versions of a
 library / program with different optimization levels for numerical
 computation.

 Ok, so you're analyzing the effects of different optimizations or something … 
 yeah… in that case, you can't really work around it by using a different 
 compiler or optimization set because you want to test *THAT* set.  That is 
 certainly understandable.  You're bound to run into bugs with any compiler at 
 -O3 and above.  Back when I was a Gentoo dev, I learned never to trust -O3 
 and above, and that rule has served me well.  Sometimes it's a corner case of 
 a compiler bug, sometimes it's buggy source that just works without some 
 strict optimizations… in general, if it's not widely tested, it's more likely 
 to not work the way you want.  I don't really have a good answer to give you 
 to this problem, but a good first step is to always report the bug.  Chance 
 are you're one of a few people to ever trip over it based on your 
 non-standard use case.

Agreed. We've filed many bug reports with Intel's compilers over the
years :-) In fact, Intel's -O3 _still_ crashes in some cases!

 This actually was
 my whole motivation for writing scienceports: provide a way to use a
 library with gcc4X or clang3X and somehow manage the combinatorial
 explosion of variants (the correct data structure, by the way, is a
 DAG).

 How are you planning to manage the inherent difficulty with some clients 
 using libstdc++ and libc++?  It's possible for two separate libraries to 
 use different C++ runtime versions so long as they're not passing objects 
 back and forth, but most of the time, libraries that are implemented in C++ 
 provide C++ APIs to that library.

 You are right to point out that a DAG alone won't solve compatibility
 issues. I just meant that it's impossible to do correct dependency
 analysis without having (or having something isomorphic to) a DAG.

 Yeah, it would be great if dependencies were a nice tree, but they're not. =)

But! It is a graph! It's just sometimes a bad graph :-(

 Seriously though, if you're using C++ extensively in your ports, you should 
 try intermixing some builds with clang++ using libc++ and see what happens.  
 New symbol mangling will make interoperability difficult.

I have put off doing this due to time. I have some pure C++ projects
to incorporate in the next few weeks that might be good candidates.

 We may need to figure out a way to deal with this ABI compatibility issue in 
 base … is there currently a way to query what configure.compiler was for 
 another installed port?

I ran into this issue as well but couldn't find an easy answer. I
solved it by using custom variants, e.g. petsc +debug +gcc47, and then
writing my own tool to activate / deactivate all dependent ports of a
certain variant at once so that I could switch, say, everything petsc
depended on to use +debug +gcc48.

 Can you please provide the information I requested regarding libstdc++ 
 linkage?

 I thought you were talking to the guy that reported the error?

 Yeah, it's late.  Forgive me =)

No worries :-)

 What other issues are you specifically frustrated with?

 Pretty much just the ability to easily manage ports compiled with
 different compilers.

 I don't think that will change any time soon.  It should hopefully be better 
 now that we have just three C++ runtimes to worry about (host libstdc++, 
 MacPorts libstdc++, and host libc++) instead of one for each gcc version

Re: Using -std=c++11 with the macports gcc-4.7 compiler

[Sean Farley]

On Mon, Jan 14, 2013 at 8:32 AM, David Barto dba...@visionpro.com wrote:
 fails because the /usr/lib/libstdc++.so is found first. What can I do to
 find the proper /opt/local/lib/libstdc++.so?

 I've not modified the search paths in any way, I'm just trying to compile a
 c++ program using the newer standard features.

Hmm, I can't reproduce this error. Using no special environment
variables and just a vanilla install of gcc47 on Mountain Lion, I get:

$ g++-mp-4.7 -std=c++11 test11.cxx  ./a.out
Hello world

$ otool -L a.out
a.out:
/opt/local/lib/libstdc++.6.dylib (compatibility version 7.0.0, current
version 7.17.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 169.3.0)
/opt/local/lib/gcc47/libgcc_s.1.dylib (compatibility version 1.0.0,
current version 1.0.0)

# shamelessly stolen from
http://www.cprogramming.com/c++11/c++11-lambda-closures.html
$ cat test11.cxx
#include iostream

using namespace std;

int main()
{
auto func = [] () { cout  Hello world  endl; };
func(); // now call the function
}
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-users

Re: running script error (eigen symmetric)

[Sean Farley]

On Mon, Dec 17, 2012 at 3:46 PM, Amy Anderson amyla...@gmail.com wrote:
 Hi macport users,

 I am trying to run this script in python and the script is now working with
 the test data (eigen problem solved) but when I input my own data to be
 called by script I got the following errors.

 [moriaht-5:~/Desktop/pyClusterROI] moriah% python pyClusterROI_test.py
 tcorr connectivity subject2002.nii

 Traceback (most recent call last):
   File pyClusterROI_test.py, line 89, in module
 make_local_connectivity_tcorr( infiles[i], maskname, outname, 0.5 )
   File
 /Users/moriah/Desktop/pyClusterROI/make_local_connectivity_tcorr.py, line
 114, in make_local_connectivity_tcorr
 msk=csc_matrix((range(1,m+1),(iv,zeros(m))),shape=(prod(sz[1:]),1))
   File
 /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/scipy/sparse/compressed.py,
 line 44, in __init__
 other = self.__class__( coo_matrix(arg1, shape=shape) )
   File
 /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/scipy/sparse/coo.py,
 line 188, in __init__
 self._check()
   File
 /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/scipy/sparse/coo.py,
 line 220, in _check
 raise ValueError('row index exceedes matrix dimensions')
 ValueError: row index exceedes matrix dimensions


 I was wondering if anyone might know what this error might mean or how to
 fix it?

Off the top of my head, no ideas besides the obvious the index is
larger than the number of rows in the matrix from the error message.
Since this error is coming from make_local_connectivity_tcorr, you'll
have to the authors of pyClusterROI.py to look into it, or better yet,
use a newer script (if available) from http://nipy.sourceforge.net.
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-users

Re: py25-cairo Fails to build

[Sean Farley]

On Mon, Dec 10, 2012 at 12:47 PM, Rodolfo Aramayo raram...@gmail.com wrote:
 I am experiencing problems building py25-cairo in all my computers
 I am attaching the log file
 Will wait for ideas before filing a bug report?

This is due to py25-cairo needing to have an older version of
py2cairo, as reported here:

https://trac.macports.org/ticket/37254

I'm almost done with a patch now. Just testing it before submitting it.
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-users

Re: Cairo Failed to Build

[Sean Farley]

On Mon, Dec 10, 2012 at 12:01 AM, Jasper Frumau jasperfru...@gmail.com wrote:
 Thanks Sean. Looking forward to the patch!

Ok, I've just posted my patches to get it working here:

https://trac.macports.org/ticket/37254

Hopefully, they can be tested and committed by a macports developer
soon. Let me know if there are any other errors.
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-users

Re: Cairo Failed to Build

[Sean Farley]

On Sun, Dec 9, 2012 at 11:55 PM, Jasper Frumau jasperfru...@gmail.com wrote:
 cairo failed to build. Here is the tail of the main log:

 tail -n 20
 /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_ports_python_py-cairo/py25-cairo/main.log
 :info:build ^
 :info:build SyntaxError: invalid syntax
 :info:build Command failed:  cd
 /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_python_py-cairo/py25-cairo/work/py2cairo-1.10.0
  /opt/local/bin/python2.5 setup.py --no-user-cfg build
 :info:build Exit code: 1
 :error:build org.macports.build for port py25-cairo returned: command
 execution failed
 :debug:build Error code: CHILDSTATUS 50928 1
 :debug:build Backtrace: command execution failed
 while executing
 system -nice 0 $fullcmdstring
 (eval body line 1)
 invoked from within
 eval system $notty $nice \$fullcmdstring
 invoked from within
 command_exec build
 (procedure portbuild::build_main line 8)
 invoked from within
 $procedure $targetname
 :info:build Warning: targets not executed for py25-cairo:
 org.macports.install org.macports.build org.macports.destroot
 :notice:build Please see the log file for port py25-cairo for details:

 /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_ports_python_py-cairo/py25-cairo/main.log

 Any idea why the command failed?

This is due to py25-cairo needing to have an older version of
py2cairo, as reported here:

https://trac.macports.org/ticket/37254

I'll send a patch for this hopefully tomorrow morning.
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-users

Re: running script error (eigen symmetric)

[Sean Farley]

On Mon, Dec 3, 2012 at 10:35 AM, Amy Anderson amyla...@gmail.com wrote:
 Dear macports-users,

 I am a new macports, python, and scipy user and I am looking for some help
 to troubleshoot an error I have been getting when trying to run a script in
 python. The script I am trying to run is called pyCluster ROI and it needs
 python, pynifti, scipy, and numpy to run. I have installed all these
 programs successfully using macports on Mac OS 10.8.


 I unarchived the scripts and ran the test script getting this error:

 $ python pyClusterROI_test.py

 Traceback (most recent call last):

   File pyClusterROI_test.py, line 48, in module

 from make_local_connectivity_scorr import *

   File
 /Users/matthewnye/Downloads/pyClusterROI/make_local_connectivity_scorr.py,
 line 40, in module

 from scipy.sparse.linalg.eigen.arpack import eigen_symmetric

 ImportError: cannot import name eigen_symmetric


 I have been trying to hunt down what this error may be and it seems that
 older versions of scipy might have used
 ‘scipy.sparse.linalg.eigen.arpack.eigen symmetric()’  where as new versions
 it has been renamed as scipy.sparse.linalg.eigen.arpack.eigs().


 Does anyone know what might be causing this error or if it is a version
 problem, is there any way to get an older version of scipy through macports?
 Also I have considered installing all these modules through a manual install
 but since i am a novice user I did not want to attempt that if there was a
 potentially simpler solution.

Woah, woah, woah now. Let's not go down the (more difficult) rabbit
hole of installing an older version of a port. For this issue, there
is a much easier solution (so please undo all the installations of an
older scipy, etc.). After scipy 0.9.0, the function 'eigen_symmetric'
was renamed to 'eigsh'. All you have to do is run,

$ perl -i -pe 's,eigen_symmetric,eigsh,g' *.py

in the pyClusterROI directory and you should get much further along.
Alternatively, attached is a patch if you would prefer that, which you
can run with,

$ patch -p1  /path/to/eigen_symmetric.patch

For reference, I'm able to get to script to run on the test data and
produce subject{1,2,…,etc.}.nii.gz. Also, as a bonus, I was able to
get this pyClusterROI thing to work with the newer nibabel (which
replaces pynifty [macports devs:I'll create a ticket later today to
file these]). You can use the attached nibabel.patch to try it out.

Though, judging by the age of this script, you might find a suitable
replacement here (which is also where the pynifti replacement lives),

http://nipy.sourceforge.net

Hope that helps!


eigen_symmetric.patch
Description: Binary data


nibabel.patch
Description: Binary data
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-users

Re: ipython3 port not working ?

[Sean Farley]

On Tue, Dec 4, 2012 at 12:25 PM, Trémouilles David david.t...@gmail.com wrote:
 Maybe I was not precise enough. I meant py33-ipython
 ipython version for python33.  Are your running precisely
 this version with the few patches you mentioned ?

Yep, I understood. I still don't know how that path of yours got there
/Volumes/macports/... and it looks like py33-ipython installs fine for
me (and Chris).
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-users

Re: ipython3 port not working ?

[Sean Farley]

On Mon, Dec 3, 2012 at 11:06 PM, Trémouilles David david.t...@gmail.com wrote:
 Hello,

 Is ipython3 working for you ?

I have a few patches that update ipython to 0.13.1 and correctly fixes
a missing py-matplotlib dependency. That might be what you're seeing
here, but I'm not 100% sure. (I'll be sending these patches tomorrow, hopefully)

 I sudo install py33-ipython without any issue but
 when I try to launch ipython3 I get an error:
 ~ $ ipython3-3.3
 -bash: /opt/local/bin/ipython3-3.3:
 /Volumes/work/macports/Library/Frameworks/Python.framework/Versions/3.3/bin/py:
 bad interpreter: No such file or directory

This looks odd to me: /Volumes/work/macports. You have
/opt/local/bin/ipython3-3.3 installed but it's looking for something
in /Volumes/.../macports?
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-users

Re: pandoc

[Sean Farley]

On Sat, Nov 3, 2012 at 7:04 PM, Clemens Lang c...@macports.org wrote:
 On Sat, Nov 03, 2012 at 03:23:27PM -0400, Lenore Horner wrote:
 I see there is a ticket from a few weeks ago that may be related, but
 there's not closure or work-around suggested.
 https://trac.macports.org/ticket/36608

 The solution is probably to update hs-utf8-string (and maybe pandoc,
 too) to the latest version. This is necessary after updating ghc, which
 we finally did a couple of weeks ago.

 I am aware of the problem but do not have time to solve it at the
 moment. Feel free to provide a patch updating these broken ports (it
 should be pretty straightforward if you start from a haskell-related
 Portfile I recently updated, e.g., hs-HTTP).

It was indeed pretty straightforward and I posted my changes here:

https://bitbucket.org/seanfarley/scienceports/changesets/tip/keyword(%22pandoc%22)%20or%20keyword(%22hs-%22)

Since it's 57 changesets, I'd rather not make all the tickets for them
and would prefer if a macports developer could review them and merge
them into macports-trunk.
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-users

Re: Problem intalling Pandoc

[Sean Farley]

On Fri, Sep 28, 2012 at 8:41 AM, Ryan Schmidt ryandes...@macports.org wrote:

 On Sep 28, 2012, at 06:27, Trémouilles David david.t...@gmail.com wrote:

 ---  Fetching archive for hs-pandoc-types
 ---  Attempting to fetch hs-pandoc-types-1.8_0.darwin_11.x86_64.tbz2 from 
 http://lil.fr.packages.macports.org/hs-pandoc-types
 ---  Attempting to fetch hs-pandoc-types-1.8_0.darwin_11.x86_64.tbz2.rmd160 
 from http://lil.fr.packages.macports.org/hs-pandoc-types
 ---  Installing hs-pandoc-types @1.8_0
 ---  Activating hs-pandoc-types @1.8_0
 Error: org.macports.activate for port hs-pandoc-types returned: command 
 execution failed
 Error: Failed to install hs-pandoc-types

 Ok, so hs-pandoc-types failed to activate.

Ryan,

This is a deep rabbit hole, fyi. The gap between cabal and macports is
non-trivial. I was able to get pandoc (and add a pandoc-devel port)
that both work but since there are *so* many ports that are required
to get pandoc to work, I've been lazy with filing the tickets for each
one. I'll leave it to a macports dev to incorporate them [^1] :-)

David,

I don't know how comfortable you feel with using a local repository
[^2] but feel free to try my repo [^3] out to get pandoc working for
yourself.

[^1]: https://bitbucket.org/seanfarley/scienceports
[^2]: http://guide.macports.org/chunked/development.local-repositories.html
[^3]: https://bitbucket.org/seanfarley/scienceports/wiki/Installation
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-users

Re: Oddity using Xcode 4.4 on OS 10.7.

[Sean Farley]

 I'm curious if this is still happening.  If anyone sees this issue when 
 initiating the install from XCode's preferences (*after* this email), please 
 let me know.

I can try later this afternoon, if not before and let you (and the list) know.
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-users

Re: Build Petsc with Shared Libraries

[Sean Farley]

 Sean, it's up to the maintainers of those ports as to whether they would like 
 to incorporate your changes, and for the petsc port, I would encourage you to 
 file a bug report with a diff with these changes and explanations about why 
 the changes need to be made.

That actually was my plan but most of the time when I interact with
the MacPorts devs, I never hear back:

https://trac.macports.org/ticket/33889
http://lists.macosforge.org/pipermail/macports-dev/2012-May/019203.html
https://trac.macports.org/ticket/34831
https://trac.macports.org/ticket/34846
https://trac.macports.org/ticket/34933

As a new person to the MacPorts scene, I've found that it's mostly
discouraging to try to submit patches for discussion.

 In the case of our metis and SuiteSparse ports, they have no maintainers. You 
 can still file tickets with diffs and someone will review them and commit 
 them eventually. If the tickets don't get addressed in a timely manner you 
 can ping the macports-dev mailing list to remind us.

 None of the other ports you mentioned exist in MacPorts at this time. You 
 would be welcome to contribute your ports to us by filing tickets in the 
 issue tracker as usual. Note that for parmetis a port has already been 
 submitted; you could see if that one is the same as yours, or if not, submit 
 an updated version there:

 https://trac.macports.org/ticket/20844

How is a three-year old ticket that never got reviewed suppose to
encourage someone that the MacPorts devs will even bother to respond?

I would love to one day submit all my patches for review but I just
don't have a clear message from the MacPorts community that the
patches would even be reviewed; much less, constructively reviewed.
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-users

Re: Build Petsc with Shared Libraries

[Sean Farley]

 I see that you use many variants in your Portfile. As a rule of thumb most 
 functionality should be enabled by default. Couldn’t most be enabled by 
 default (possibly as a default_variant)?

Sure; I have no preference either way. My only note is that the
--download-* options shouldn't be used for PETSc since that could lead
to conflicting symbols.

 I like your mpi PortGroup [1]. I can see that could be helpful for other 
 packages as well.

Thanks :-) Yes, my goal with the MPI PortGroup was to unify the use of
+gcc47, +mpi, etc. so that (hopefully) a portfile wouldn't need to
specify any custom compiler variant (ala +gcc4X). I haven't decided on
a nice way to specify that mpi is optional (similarly, how to specify
fortran is optional).

 Isn’t MPI support something that should be enabled by default for Petsc?

It doesn't really matter one way or the other. If no MPI is specified
to PETSc, then it will use its own internal MPI (via MPIUNI).

 Is there any consensus within the MacPorts community on what should be the 
 default MPI implementation used in ports that require MPI?

Good question. Due to the latest few releases of OpenMPI not being
valgrind clean, PETSc recommends mpich2 (well, that and the fact that
the mpich guys are on the next floor to the petsc team).

Following up with mpi, it should be noted that lam, lammpi, and mpich
are all deprecated (and should be removed / replaced_by).
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-users

Re: Build Petsc with Shared Libraries

[Sean Farley]

 The libraries have not been linked correctly. I assume the first line in
 otool -L /opt/local/lib/petsc/lib/libpetsc.dylib contains the
 worksrcdir, which causes this issue when linking against it.

 Please file a bug so the maintainer can fix this.

The PETSc portfile is very wrong, particularly with the prefix
install. I've been meaning to submit a diff but for the time being,
here my own PETSc portfile that I use:

https://bitbucket.org/seanfarley/scienceports/src/5b57adccee2f/math/petsc/Portfile

Notable things that need to be fixed in the MacPorts version:

* don't use both --with-c-support and --with-c++-support
* unnecessary to use --with-python
* don't use --with-pic
* don't use --with-mpi=1
* don't pass ${destroot} to --prefix
* don't pass mpi compiler wrappers to --with-{cc,cxx}; just use
--with-mpi-dir=${prefix} (the correct compilers will be used based on
that)
* don't ever mess with blas/lapack options
* don't pass things to --LIB

If the devs at macports want, they could update metis, parmetis,
blacs, scalapck, mumps, ml, and SuiteSparse to my ports located at
bitbucket; they are the same ones that are used for
--download-{metis,parmetis,blacs,scalapack,mumps,ml,umfpack} and, as a
bonus, are all updated to the latest versions.
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-users

Re: gfortran with Xcode 4.3.2 unreliable

[Sean Farley]

 There was a thread ~1 month ago regarding gfortran that was acting
 strangely.  Here's a link to that
 thread: http://lists.macosforge.org/pipermail/macports-dev/2012-May/019098.html

 I haven't seen any responses or anything to this, and I was wondering if
 anyone else had run into issues trying to use gfortran from any of the gcc4X
 builds using Xcode 4.3.x on Lion.

 There seems to be something *seriously* wrong with the Fortran compiler
 built with MacPorts -- in a very Fortran-heavy program suite, nearly half of
 the tests are suddenly failing when built with these compilers even after
 the selected_real_kind() issues are resolved.  And the failures are not
 blatantly ridiculous, they're subtle, but currently I'm wary of trusting
 anything the MacPorts-built GCC compilers (at least the Fortran compilers)
 spit out.

Yes, you are correct that this is seriously wrong and very subtle. The
issue is with gmp and causes gfortran to erroneously double the size
of (at least) ints. I opened a ticket here with a patch:

https://trac.macports.org/ticket/34491

that fixes the gmp issue and also fixes debuggers loading shared
symbols; but haven't heard back from the macports devs at all on the
issue. You should be able to apply the patch yourself and rebuild
everything from source with the -s option:

$ sudo port uninstall --follow-dependents gmp
$ sudo port -vs install gcc47

or whichever gcc you have installed. Hope that helps!
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: Trying to install ld64 port from source, but binaries installed instead?

[Sean Farley]

 I just tried to port install ld64, and instead of compiling from source,
 it downloads a .tbz2 package from packages.macports.org which contains the
 binaries. I guess I thought macports always built from source unless you
 added pkg to the port command? Thanks for any help.

This is a newer change; you'll need to add the '-s' option to signify
that you want to build from source.
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

re: strange gfortran problem

[Sean Farley]

(cc'ing macports-dev)

 The problem is actually with MacPorts 4.3.2. A little more accurately, this 
 is NOT an actual bug. The problem is that the behavior you are seeing is 
 allowed under the Fortran standard -- that's why selected_int_kind exists in 
 the first place.

This is wrong. The Fortran standard, and in particular gfortran, call
for the *smallest* integer type:

http://gcc.gnu.org/onlinedocs/gfortran/SELECTED_005fINT_005fKIND.html

For selected_int_kind(5), this *must* be INTEGER*4 (4 bytes = 32 bits;
pow(2,32)/2-1 will suffice 5 for digits)

 I had to issue a patch for a piece of software that used 
 selected_real_kind(), but assumed that it would always return 8 as used. From 
 all the searching I did, I found that this behavior was perfectly within the 
 Fortran standard, and that we had to become compliant with it.

 My suggestion is to avoid roll-your-own precision to avoid problems like 
 this. If you need to use it, make sure you always use the enquiry intrinsics 
 (selected_real_kind and selected_int_kind), and never assume it will take a 
 particular value.

That's what this piece of software does, actually (uses select_*_kind).

 To reiterate, this behavior ONLY arose when I built all my ports with Xcode 
 4.3.2, and never with older Xcodes (that is, if I built gcc4x with Xcode 
 4.3.2, it would happen regardless of which FCC I built).

 I agree the behavior differs in my experiences with Linux, but there are 
 other OSes and compilers that behave differently as well (or so I read)

There is a bug here but it's not with gcc / gfortran. It appears to be
gmp; and it seems to occur when missing the 10.6 sdk. I don't know why
it happens, but that look like the common failure (i.e. using
MacPorts's gmp generated from the buildbot will expose this bug). Or
it could be the +universal logic in the gmp Portfile.

For my machine, I have the 10.6 sdk so I needed to uninstall gmp and
build it from source (using the -s option):

$ sudo port uninstall --follow-dependents gmp
$ sudo port -vs install gcc47 (or gcc46, gcc48; all gcc ports
experience this bug with gmp)

This really, *really* needs to be fixed on the buildbot. Is there any
particular reason the buildbot doesn't have the 10.6 SDK? The test
case is easy to see with Victor's attached fortran test (which I
reattached to this email). The output should be:

$ ./a.out
 int4:4
 int8:8

Are there any other macport devs that can test building gmp / gcc47 on
their local machine to see if the output matches (e.g. just run my two
above command that uninstalls gmp and its dependents, then install
gcc47 and its dependencies from source)?

Also, it would be nice if all compilers included their debug symbols
(i.e. run dsymutil *.dylib in the destroot phase) which I put a patch
here:

https://trac.macports.org/attachment/ticket/33821/base-create-dsym.patch

This would stop millions of warnings when using gdb with *anything*
compiled by one of the compilers provided by MacPorts. The impact of
including the .dSYM files is extremely low but saves so much
frustration on the users.


sizeof-ftn.f90
Description: Binary data
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users