Objection to restoring deprecated Python subports

[Lawrence Velázquez]

Fred Wright recently opened several tickets that suggest restoring
several Python subports that were deprecated and moved to the Python
graveyard a long time ago.

https://trac.macports.org/ticket/52636
https://trac.macports.org/ticket/52637
https://trac.macports.org/ticket/52638
https://trac.macports.org/ticket/52639
https://trac.macports.org/ticket/52640
https://trac.macports.org/ticket/52641
https://trac.macports.org/ticket/52642

I strenuously object to these proposals.

A few years ago, I proposed a Python subport/variant policy to reduce
project-wide support load. That policy was that we should only provide
subports for the two most recent Python versions on each of the 2.x and
3.x branches (modulo some details about termination of upstream
support).

Thanks to the efforts of many contributors, that proposal has been
mostly carried out. We absolutely should not be going backwards on this.

Users who wish to work with unsupported versions of Python should use
virtualenv to create a contained environment in which they may use the
bundled pip, setuptools, and wheel to install any modules they please.
The deprecated subports would have to be restored to the virtualenv and
setuptools ports; I'd be fine with this.

vq
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Review request for tickets #52545, #52590, #52615

[Ryan Schmidt]

> On Oct 17, 2016, at 7:55 PM, David Evans  wrote:
> 
> On 10/17/16 2:38 PM, Ryan Schmidt wrote:
>> 
>>> On Oct 17, 2016, at 2:43 PM, David Evans  wrote:
>>> 
>>> Ryan,
>>> 
>>> I'm trying to commit as many pending svn commits as soon as possible in 
>>> anticipation of the migration to git.  I'd
>>> appreciate it if you could look at these 3 tickets[1][2][3] and let me know 
>>> if you agree they can be committed as is, or
>>> if you have any suggestions for their improvement.
>>> 
>>> Thanks,
>>> 
>>> Dave
>>> 
>>> [1] https://trac.macports.org/ticket/52545
>>> [2] https://trac.macports.org/ticket/52590
>>> [3] https://trac.macports.org/ticket/52615
>> 
>> I've responded in the tickets.
>> 
> 
> Thanks, Ryan. Based on your review, unless you want to do the honors, I'll go 
> ahead
> and commit the keybinder ports (#52545, #52590) later this evening and add 
> the suggested
> fixups and enhancements to #52615 for further review.

That would be great if you would commit it.


> While we're doing this, if you could comment on ticket #51685 concerning the 
> MyPaint-devel update requested there,
> I'd appreciate it. gimp2-devel has been stuck at its current version since 
> last May for want of libmypaint >= 1.3.0.
> I'd like to be able to update to version 2.9.4.

I looked into this now and added comments in the ticket. Looks like by the time 
libmypaint got to version 1.3.0, it had been fully separated from mypaint, and 
we will need to make a separate port to build that. Fortunately, it's using 
autotools, not scons, so hopefully the port will be straightforward.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Commit request https://trac.macports.org/ticket/52546

[Ken Cunningham]

That I will leave to upstream.

Thanks,

K


On 2016-10-17, at 6:16 PM, Fred Wright wrote:

> 
> On Mon, 17 Oct 2016, Ken Cunningham wrote:
> 
>> For your consideration -- I'd commit this as it stands and fix the port, 
>> rather than spend too much more time on it.
>> 
>> https://trac.macports.org/ticket/52546
>> 
>> I notice something has changed in the sierra time functions -- a couple of 
>> ports seem to have time-related errors.
> 
> Presumably this is because Apple has finally gotten around to implementing
> clock_gettime() in Sierra, and that's colliding with some
> locally-provided replacements.  Typically a configure script would
> determine whether clock_gettime() is available, or whether to provide a
> replacement.  Making that work properly is better than just commenting out
> the colliding typedef.
> 
> Fred Wright
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Commit request https://trac.macports.org/ticket/52546

[Fred Wright]

On Mon, 17 Oct 2016, Ken Cunningham wrote:

> For your consideration -- I'd commit this as it stands and fix the port, 
> rather than spend too much more time on it.
>
> https://trac.macports.org/ticket/52546
>
> I notice something has changed in the sierra time functions -- a couple of 
> ports seem to have time-related errors.

Presumably this is because Apple has finally gotten around to implementing
clock_gettime() in Sierra, and that's colliding with some
locally-provided replacements.  Typically a configure script would
determine whether clock_gettime() is available, or whether to provide a
replacement.  Making that work properly is better than just commenting out
the colliding typedef.

Fred Wright
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [154006] trunk/dports/science/Gyoto

[David Evans]

Looking at the buildbot failures, this needs, at least, a build
dependency on pkgconfig.

On 10/17/16 3:24 PM, thib...@macports.org wrote:
> Revision
> 154006 
> Author
> thib...@macports.org
> Date
> 2016-10-17 15:24:33 -0700 (Mon, 17 Oct 2016)
> 
> 
>   Log Message
> 
> Gyoto: new version 1.1.0.
> 
> Build and ship the LORENE plug-in in the Gyoto subport.
> Build and ship the Python plug-ins in the respective py??-gyoto subports.
> Provide compiler variants for the same compilers as Boost.
> Add python35 to the list of supported Python versions.
> Install the examples.
> 
> 
>   Modified Paths
> 
>   * trunk/dports/science/Gyoto/Portfile <#trunkdportsscienceGyotoPortfile>
> 
> 
>   Removed Paths
> 
>   * trunk/dports/science/Gyoto/files/
> 
> 
>   Diff
> 
> 
> Modified: trunk/dports/science/Gyoto/Portfile (154005 => 154006)
> 
> --- trunk/dports/science/Gyoto/Portfile 2016-10-17 21:33:36 UTC (rev 154005) 
> +++ trunk/dports/science/Gyoto/Portfile
> 2016-10-17 22:24:33 UTC (rev 154006) @@ -4,9 +4,9 @@ PortSystem 1.0 PortGroup 
> github 1.0 PortGroup active_variants 1.1
> +PortGroup compilers 1.0 -github.setup gyoto Gyoto 1.0.1 -revision 4 
> +github.setup gyoto Gyoto 1.1.0 license GPL-3+
> categories science yorick platforms darwin @@ -19,9 +19,11 @@ language. Gyoto 
> can be extended with plug-ins. homepage
> http://gyoto.obspm.fr -checksums rmd160 
> 773c9fe40ea2a17b5fad0b75a0f1376d28927d94 \ - sha256
> 643c1955fdef5ec8747cd42a4fe075ddaeb822e924f9f49ba895a6f0d8832cb1 +checksums 
> rmd160
> 28458c6dc0827b2f859f8cb05906f36835775b09 \ + sha256 
> dfa04cc9ccffc2b20c51784af097b574c844837440d4563d10b3f45e5a4798bf
> +depends_build port:LORENE + depends_lib port:cfitsio \ port:xercesc3 \ 
> port:udunits2 \ @@ -33,25 +35,26 @@ # yorick is
> not universal universal_variant no -patchfiles 
> patch-include-GyotoScreen.h.diff -patch.pre_args -p1 - configure.args
> --with-yorick=${prefix}/bin/yorick \ - --without-lorene \ + 
> --with-lorene=${prefix}/lib/lorene \ --with-xerces \
> --disable-doc \ --with-cfitsio \ 
> --with-udunits-inc=${prefix}/include/udunits2/ \ 
> --with-udunits-lib=-L${prefix}/lib/ \
> --enable-release \ - --without-mpi + --without-mpi \ + --without-python 
> -build.args-append
> Y_CFLAGS="${configure.cxxflags}" Y_CPPFLAGS="${configure.cppflags}" 
> CC="${configure.cc}" COPT_DEFAULT=""
> Y_LDFLAGS="${configure.ldflags}" +build.args-append 
> Y_CFLAGS="${configure.cxxflags}" Y_CPPFLAGS="${configure.cppflags}"
> CC="${configure.cc}" COPT_DEFAULT="" Y_LDFLAGS="${configure.ldflags}" 
> -test.target check -test.run yes +test.target
> check check-lorene +test.run yes +compilers.setup -gcc -dragonegg 
> +compilers.enforce_c lorene + if {![catch {set result
> [active_variants boost openmpi {}]}]} { if {$result} { default_variants 
> +openmpi @@ -62,44 +65,103 @@ } } -foreach nodot
> [list 27 33 34] wdot [list 2.7 3.3 3.4] { +foreach nodot [list 27 33 34 35] 
> wdot [list 2.7 3.3 3.4 3.5] { subport
> py${nodot}-gyoto { depends_build-append port:doxygen port:swig-python 
> depends_lib-append port:python${nodot}
> port:py${nodot}-numpy \ port:Gyoto + compilers.enforce_c Gyoto categories 
> python science + configure.args-delete
> --without-python configure.args-append PYTHON=${prefix}/bin/python${wdot} 
> use_parallel_build no - build.args -C python +
> build.target python plugins/python + destroot.cmd
> PYTHONPATH=${frameworks_dir}/Python.framework/Versions/${wdot}:\$PYHTONPATH 
> make destroot.args -C python
> INSTALL_DATA=true prefix=${frameworks_dir}/Python.framework/Versions/${wdot} 
> + post-destroot { + xinstall -d
> ${destroot}${prefix}/lib/gyoto/5_0_0 + exec -ignorestderr gmake -C 
> ${worksrcpath}/plugins/python install \ +
> DESTDIR=${destroot} + xinstall -d 
> ${destroot}/${prefix}/share/doc/${subport}/examples + xinstall {*}[glob
> ${worksrcpath}/plugins/python/doc/examples/*] \ + 
> ${destroot}/${prefix}/share/doc/${subport}/examples/ + xinstall
> {*}[glob ${worksrcpath}/python/example*.py] \ + 
> ${destroot}/${prefix}/share/doc/${subport}/examples/ + } test.run no } }
> subport Gyoto { post-destroot { - xinstall -W ${worksrcpath}/python gyoto.i 
> gyoto_std.i gyoto_lorene.i numpy.i
> ${destroot}/${prefix}/include/Gyoto/ + xinstall -W ${worksrcpath}/python \ + 
> gyoto.i gyoto_std.i gyoto_lorene.i numpy.i
> \ + ${destroot}/${prefix}/include/Gyoto/ + xinstall -d 
> ${destroot}/${prefix}/share/doc/${subport}/examples + xinstall
> {*}[glob ${worksrcpath}/doc/examples/*] \ + 
> ${destroot}/${prefix}/share/doc/${subport}/examples/ } } if {[string match
> libc++ ${configure.cxx_stdlib}]} { depends_lib-append port:boost - + 
> compilers.enforce_c boost + variant openmpi
> conflicts mpich \ description {Add MPI parallelization using OpenMPI} { + set 
> c_variant [c_variant_name] + if
> {${c_variant} == ""} { + set mpi_port openmpi + set mpi_suffix mp + } { + set 
> mpi_port openmpi-${c_variant} + set
> mpi_suffix 

Re: Review request for tickets #52545, #52590, #52615

[David Evans]

On 10/17/16 2:38 PM, Ryan Schmidt wrote:
> 
>> On Oct 17, 2016, at 2:43 PM, David Evans  wrote:
>>
>> Ryan,
>>
>> I'm trying to commit as many pending svn commits as soon as possible in 
>> anticipation of the migration to git.  I'd
>> appreciate it if you could look at these 3 tickets[1][2][3] and let me know 
>> if you agree they can be committed as is, or
>> if you have any suggestions for their improvement.
>>
>> Thanks,
>>
>> Dave
>>
>> [1] https://trac.macports.org/ticket/52545
>> [2] https://trac.macports.org/ticket/52590
>> [3] https://trac.macports.org/ticket/52615
> 
> I've responded in the tickets.
> 

Thanks, Ryan. Based on your review, unless you want to do the honors, I'll go 
ahead
and commit the keybinder ports (#52545, #52590) later this evening and add the 
suggested
fixups and enhancements to #52615 for further review.

While we're doing this, if you could comment on ticket #51685 concerning the 
MyPaint-devel update requested there,
I'd appreciate it. gimp2-devel has been stuck at its current version since last 
May for want of libmypaint >= 1.3.0.
I'd like to be able to update to version 2.9.4.

Dave


___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Commit request https://trac.macports.org/ticket/52546

[Ken Cunningham]

For your consideration -- I'd commit this as it stands and fix the port, rather 
than spend too much more time on it.

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

I notice something has changed in the sierra time functions -- a couple of 
ports seem to have time-related errors.

K
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [153943] trunk/dports/science

[David Strubbe]

I guess the question is: is x11 definitely what pgplot should be linked
with? +x11 is an optional (though default) variant for pgplot (as below).
Is it necessary to use x11 for these LORENE codes to be compiled? For
example, what if they were to use +aquaterm?

pgplot @5.2.2_10 (graphics, devel)
Variants: aquaterm, docs, dragonegg33, dragonegg34, g95, gcc44,
gcc45, gcc46, gcc47, gcc48, gcc49, gcc5, [+]gcc6, gcc7, [+]x11

Description:  The PGPLOT Graphics Subroutine Library is a Fortran-
or C-callable, device-independent graphics package for making simple
scientific graphs. It is intended for making
  graphical images of publication quality with minimum
effort on the part of the user. For most applications, the program can be
device-independent, and the output can be
  directed to the appropriate device at run time.
Homepage: http://www.astro.caltech.edu/~tjp/pgplot/

Build Dependencies:   perl5, pkgconfig, gcc6
Library Dependencies: libpng, zlib, xorg-libX11, libgcc
Conflicts with:   miriad
Platforms:darwin
License:  Noncommercial
Maintainers:  mcalh...@macports.org, openmaintai...@macports.org


On Mon, Oct 17, 2016 at 11:38 AM, Thibaut Paumard 
wrote:

> This is correct. I will emote the dependency.
>
> Should I also remove -lX11 from LIB_PGPLOT, since libpgplot itself is
> linked with -lX11?
>
> Kind regards, Thibaut.
>
>
> Le 17 oct. 2016 à 20:12, David Strubbe  a écrit :
>
> It appears libX11, in the LIB_PGPLOT variable, is used in principle to
> compile some codes that are not in fact compiled in this package. It looks
> like X11 is only in fact used via pgplot.
>
> On Mon, Oct 17, 2016 at 10:46 AM, Ryan Schmidt 
> wrote:
>
>>
>> > On Oct 16, 2016, at 11:57 PM, David Strubbe 
>> wrote:
>> >
>> > Additionally, the dependency port:xorg-libX11 does not seem necessary:
>> I don't see any evidence in the build log that it is used, and the build
>> succeeds without it being active.
>>
>> Are you sure? libX11 is mentioned in local_settings:
>>
>>
>> > > --- trunk/dports/science/LORENE/files/local_settings
>>   (rev 0)
>> > > +++ trunk/dports/science/LORENE/files/local_settings  2016-10-16
>> 17:41:08 UTC (rev 153943)
>>
>> > > +# Graphical libraries: PGPLOT, PNG and X11
>> > > +# 
>> > > +LIB_PGPLOT = -lcpgplot -lpgplot -lX11
>>
>>
>>
>>
>
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Review request for tickets #52545, #52590, #52615

[Ryan Schmidt]

> On Oct 17, 2016, at 2:43 PM, David Evans  wrote:
> 
> Ryan,
> 
> I'm trying to commit as many pending svn commits as soon as possible in 
> anticipation of the migration to git.  I'd
> appreciate it if you could look at these 3 tickets[1][2][3] and let me know 
> if you agree they can be committed as is, or
> if you have any suggestions for their improvement.
> 
> Thanks,
> 
> Dave
> 
> [1] https://trac.macports.org/ticket/52545
> [2] https://trac.macports.org/ticket/52590
> [3] https://trac.macports.org/ticket/52615

I've responded in the tickets.



___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Review request for tickets #52545, #52590, #52615

[David Evans]

Ryan,

I'm trying to commit as many pending svn commits as soon as possible in 
anticipation of the migration to git.  I'd
appreciate it if you could look at these 3 tickets[1][2][3] and let me know if 
you agree they can be committed as is, or
if you have any suggestions for their improvement.

Thanks,

Dave

[1] https://trac.macports.org/ticket/52545
[2] https://trac.macports.org/ticket/52590
[3] https://trac.macports.org/ticket/52615
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [153943] trunk/dports/science

[Thibaut Paumard]

I think this didn’t go to the list.

Le 17 oct. 2016 à 19:40, Paumard Thibaut  a écrit :

> Many thanks David,
> 
> Let me answer some of your questions:
> 
> Le Lundi 17 Octobre 2016 02:23 CEST, David Strubbe  a 
> écrit:
> 
>> Hi,
>> 
>> Let me add a few comments.
>> - The dependency for BLAS is wrong: the port OpenBLAS provides a library
>> -lopenblas not -lblas. Apparently the "lapack" port includes BLAS anyway.
>> To be simpler and more flexible, I suggest use of the linear algebra port
>> group I created to handle all this and also provide choices of different
>> optimized implementations (ATLAS, Accelerate, or OpenBLAS -- the port has
>> lapack included). See patch below.
> 
> Thanks, I've applied your patch. Does this warrant a rev bump? I would think 
> so, since the library may not be linked with the same version of blas and 
> lapack.
> 
>> - You are installing a lot of Makefiles and C source files -- is this on
>> purpose? It is somewhat unusual.
> 
> Yes, this is on purpose. Those are codes that, unfortunately, need to be 
> recompiled for each use case. So the scenario for using those codes from the 
> macports-installed package is to copy the folder for a given code to a place 
> with write access, configure it by putting the right parameter file in the 
> right place, set HOME_LORENE (see below), and run make.
> 
>> - You are putting everything in the lib directory. This should be reserved
>> for libraries. Headers should go in include; documentation or miscellaneous
>> things should go in share; etc.
> 
> The code is meant to be used that way. I don't want to diverge from what 
> upstream is doing: I could install the headers in ${prefix}/include etc., but 
> I would have to symlink from the "main" lorene directory.
> 
> To use the library, users are expected (by upstream) to set an environment 
> variable to the place that contains the compiled source code for lorene and 
> include $(HOME_LORENE)/local_settings.
> 
>> - Since there are tests apparently available, you should create a test
>> phase rather than install their files, so that users can run "port test".
> 
> Right, I should try and see which tests are suitable for that.
> 
> Kind regards, Thibaut.
> 
>> David
>> 
>> Index: Portfile
>> ===
>> --- Portfile(revision 153958)
>> +++ Portfile(working copy)
>> @@ -3,6 +3,7 @@
>> 
>> PortSystem  1.0
>> PortGroup   compilers 1.0
>> +PortGroup   linear_algebra 1.0
>> 
>> cvs.date   20160908
>> 
>> @@ -29,9 +30,7 @@
>> sha256
>> ef797abc51ed8ae27c200f5b71fd0a3824d1fa310392dac57067de2e423222ed
>> worksrcdir ${distname}-${version}+dfsg
>> 
>> -depends_libport:OpenBLAS \
>> -port:lapack \
>> -port:gsl \
>> +depends_libport:gsl \
>> port:fftw-3 \
>> port:pgplot \
>> port:xorg-libX11
>> @@ -47,6 +46,7 @@
>> reinplace -W ${worksrcpath} "s|@FFLAGS@|${configure.fflags}|g"
>> local_settings
>> reinplace -W ${worksrcpath} "s|@LDFLAGS@|${configure.ldflags}|g"
>> local_settings
>> reinplace -W ${worksrcpath} "s|@LIB_FORTRAN@|${compilers.libfortran}|g"
>> local_settings
>> +reinplace -W ${worksrcpath} "s|@LIB_LAPACK@|${linalglib}|g"
>> local_settings
>> }
>> 
>> build.env-appendHOME_LORENE=${worksrcpath}
>> Index: files/local_settings
>> ===
>> --- files/local_settings(revision 153958)
>> +++ files/local_settings(working copy)
>> @@ -74,7 +74,7 @@
>> 
>> # Linear Algebra Package (LAPACK) library
>> # ---
>> -LIB_LAPACK = -llapack -lblas
>> +LIB_LAPACK = @LIB_LAPACK
>> 
>> # Graphical libraries: PGPLOT, PNG and X11
>> # 
>> 
>> 
>> On Sun, Oct 16, 2016 at 1:27 PM, Ryan Schmidt 
>> wrote:
>> 
>>> 
 On Oct 16, 2016, at 12:41 PM, thib...@macports.org wrote:
 
 Revision
 153943
 Author
 thib...@macports.org
 Date
 2016-10-16 10:41:08 -0700 (Sun, 16 Oct 2016)
 Log Message
 
 New port: LORENE
 Added Paths
 
  • trunk/dports/science/LORENE/
  • trunk/dports/science/LORENE/Portfile
  • trunk/dports/science/LORENE/files/
  • trunk/dports/science/LORENE/files/local_settings
 Diff
 
 Added: trunk/dports/science/LORENE/Portfile (0 => 153943)
 
 --- trunk/dports/science/LORENE/Portfile
>>> (rev 0)
 +++ trunk/dports/science/LORENE/Portfile  2016-10-16 17:41:08 UTC
>>> (rev 153943)
 @@ -0,0 +1,67 @@
 +# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil;
>>> c-basic-offset: 4 -*- vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4
 +# $Id$
>>> 
>>> The whitespace of this portfile does not conform to 

Re: [153943] trunk/dports/science

[Thibaut Paumard]

This is correct. I will emote the dependency.

Should I also remove -lX11 from LIB_PGPLOT, since libpgplot itself is linked 
with -lX11?

Kind regards, Thibaut.


Le 17 oct. 2016 à 20:12, David Strubbe  a écrit :

> It appears libX11, in the LIB_PGPLOT variable, is used in principle to 
> compile some codes that are not in fact compiled in this package. It looks 
> like X11 is only in fact used via pgplot.
> 
> On Mon, Oct 17, 2016 at 10:46 AM, Ryan Schmidt  
> wrote:
> 
> > On Oct 16, 2016, at 11:57 PM, David Strubbe  wrote:
> >
> > Additionally, the dependency port:xorg-libX11 does not seem necessary: I 
> > don't see any evidence in the build log that it is used, and the build 
> > succeeds without it being active.
> 
> Are you sure? libX11 is mentioned in local_settings:
> 
> 
> > > --- trunk/dports/science/LORENE/files/local_settings  
> > > (rev 0)
> > > +++ trunk/dports/science/LORENE/files/local_settings  2016-10-16 17:41:08 
> > > UTC (rev 153943)
> 
> > > +# Graphical libraries: PGPLOT, PNG and X11
> > > +# 
> > > +LIB_PGPLOT = -lcpgplot -lpgplot -lX11
> 
> 
> 
> 

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: port:lapack useful?

[Sean Farley]

Takeshi Enomoto  writes:

> Dear David,
>
>> I just noticed that you created a port lapack (including BLAS) in r146856. 
>> Is this really useful? We already have the ATLAS port which provides BLAS 
>> and LAPACK; the OpenBLAS port which provides exactly the same implementation 
>> of LAPACK from netlib as your port lapack; and the built-in Accelerate 
>> Framework and the vecLibFort port providing a Fortran interface for it. All 
>> of these are optimized and therefore should be faster than the 
>> straightforward netlib implementation, and use directly of 
>> Accelerate/vecLibFort is of course by far the fastest to install. So, what 
>> is the use of a separate port lapack? I suspect its main effect will be to 
>> have users or port packagers use this one instead of an optimized 
>> implementation because they do not realize the optimized ones exist. For 
>> example, see the recent r153943. I would suggest removing it.
>
> I started LAPACK port to provide man pages after Apple removed them.
> Some email exchanges with the LAPACK developers I became aware of the 
> followings:
>
> * LAPACK from netlib is active.

So many things I could say but I will refrain.

> * the man pages can be generated from LAPACK source by make man.
> * the most of the performance gain is due to BLAS, which can be obtained from 
> BLAS.
> * CBLAS and LAPACKE can be provided.
>
> I believe that there is nothing to be harmful to leave the port.

Yeah, that's fine with me. I see there's a linear_algebra portgroup
which should abstract away all these ports, correct (perhaps with some
extra work)?
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [153943] trunk/dports/science

[David Strubbe]

It appears libX11, in the LIB_PGPLOT variable, is used in principle to
compile some codes that are not in fact compiled in this package. It looks
like X11 is only in fact used via pgplot.

On Mon, Oct 17, 2016 at 10:46 AM, Ryan Schmidt 
wrote:

>
> > On Oct 16, 2016, at 11:57 PM, David Strubbe 
> wrote:
> >
> > Additionally, the dependency port:xorg-libX11 does not seem necessary: I
> don't see any evidence in the build log that it is used, and the build
> succeeds without it being active.
>
> Are you sure? libX11 is mentioned in local_settings:
>
>
> > > --- trunk/dports/science/LORENE/files/local_settings
> (rev 0)
> > > +++ trunk/dports/science/LORENE/files/local_settings  2016-10-16
> 17:41:08 UTC (rev 153943)
>
> > > +# Graphical libraries: PGPLOT, PNG and X11
> > > +# 
> > > +LIB_PGPLOT = -lcpgplot -lpgplot -lX11
>
>
>
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: port:lapack useful?

[David Strubbe]

Hi Takeshi,

Thanks for the response.

On Mon, Oct 17, 2016 at 7:55 AM, Takeshi Enomoto 
wrote:

>
> * LAPACK from netlib is active.
>

I do not doubt that the netlib LAPACK is active -- this is of course the
reference implementation that the vendors use in optimization.


> * the man pages can be generated from LAPACK source by make man.
>

The existence of the port lapack-manpages certainly is useful to provide
these manpages, but that is separate from the lapack port, isn't it?


> * the most of the performance gain is due to BLAS, which can be obtained
> from BLAS.

* CBLAS and LAPACKE can be provided.
>

Both of these are true of the OpenBLAS port already, in fact.


> I believe that there is nothing to be harmful to leave the port.
>

Well, what do you respond to my concern: I suspect its main effect will be
to have users or port packagers use this one instead of an optimized
implementation because they do not realize the optimized ones exist, and
therefore get slower performance. Additionally, it is just confusing if we
have too many version of the same software. In what situation would you
expect someone should use this port as opposed to the other ones?


>
> The message from the upstream developer on 15 March 2016.
>
> > Dear Takeshi,
> > I am ccing Julien Langou - he is one of the PI of LAPACK and our most
> active contributor.
> > I saw your vecLibFort port - this is awesome and it was dearly needed.
> > > vecLibFort is lightweight but flexible shim designed to rectify the
> incompatibilities between the Accelerate/vecLib BLAS and LAPACK libraries
> shipped with Mac OS X and FORTRAN code compiled with modern compilers such
> as GNU Fortran.
> >
> > First, there is no real complete “optimized LAPACK” library around that
> I know if except the one's from vendors (for Example: MKL INTEL)
>

Indeed, so for Apple the vendor-optimized version is Accelerate.


> > Second, most of the performance from a LAPACK code will come from an
> Optimized BLAS library (i.e. Veclib)
>

But is there any clear reason why one needs this other combination
(Accelerate BLAS + netlib lapack) as opposed to Accelerate BLAS +
Accelerate LAPACK or OpenBLAS BLAS + netlib lapack which we already have?


> > Veclib is based on Atlas, and I did not check, but I believe the LAPACK
> included inside VecLib and vecLibFort correspond to the ATLAS LAPACK -
> which is a small subset of LAPACK library.
>

I have not noticed any LAPACK routines missing from either vecLibFort or
ATLAS. If there are in fact missing routines, then that would change the
situation -- is there any evidence about that?

Best,
David
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [153943] trunk/dports/science

[Ryan Schmidt]

> On Oct 16, 2016, at 11:57 PM, David Strubbe  wrote:
> 
> Additionally, the dependency port:xorg-libX11 does not seem necessary: I 
> don't see any evidence in the build log that it is used, and the build 
> succeeds without it being active.

Are you sure? libX11 is mentioned in local_settings:


> > --- trunk/dports/science/LORENE/files/local_settings
> >   (rev 0)
> > +++ trunk/dports/science/LORENE/files/local_settings  2016-10-16 17:41:08 
> > UTC (rev 153943)

> > +# Graphical libraries: PGPLOT, PNG and X11
> > +# 
> > +LIB_PGPLOT = -lcpgplot -lpgplot -lX11



___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [153943] trunk/dports/science

[Ryan Schmidt]

> On Oct 17, 2016, at 12:23 PM, Paumard Thibaut  
> wrote:
> 
> Thanks  Ryan,
> 
> I will commit an update tonight to fix those issues.
> 
> Does that warrant a rev bump?

Will it change any files that get installed by the port? If so, yes.


> Kind regards, Thibaut.
> 
> Le Dimanche 16 Octobre 2016 22:27 CEST, Ryan Schmidt 
>  a écrit:
> 
>> 
>>> On Oct 16, 2016, at 12:41 PM, thib...@macports.org wrote:
>>> 
>>> Revision
>>> 153943
>>> Author
>>> thib...@macports.org
>>> Date
>>> 2016-10-16 10:41:08 -0700 (Sun, 16 Oct 2016)
>>> Log Message
>>> 
>>> New port: LORENE
>>> Added Paths
>>> 
>>> • trunk/dports/science/LORENE/
>>> • trunk/dports/science/LORENE/Portfile
>>> • trunk/dports/science/LORENE/files/
>>> • trunk/dports/science/LORENE/files/local_settings
>>> Diff
>>> 
>>> Added: trunk/dports/science/LORENE/Portfile (0 => 153943)
>>> 
>>> --- trunk/dports/science/LORENE/Portfile(rev 0)
>>> +++ trunk/dports/science/LORENE/Portfile2016-10-16 17:41:08 UTC (rev 
>>> 153943)
>>> @@ -0,0 +1,67 @@
>>> +# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil; 
>>> c-basic-offset: 4 -*- vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4
>>> +# $Id$
>> 
>> The whitespace of this portfile does not conform to this modeline. Tabs 
>> should be replaced with spaces.
>> 
>> 
>>> +PortSystem  1.0
>>> +PortGroup   compilers 1.0
>>> +
>>> +cvs.date   20160908
>>> +
>>> +name   LORENE
>>> +version0.0.0~cvs${cvs.date}
>>> +
>>> +categories science
>>> +maintainersthibaut openmaintainer
>>> +descriptionLangage Objet pour la RElativité NumériquE
>>> +long_descriptionLORENE is a set of C++ classes to solve various 
>>> problems \
>>> +arising in numerical relativity, and more generally in 
>>> \
>>> +computational astrophysics. It provides tools to solve 
>>> \
>>> +partial differential equations by means of 
>>> multi-domain \
>>> +spectral methods.
>>> +
>>> +license gpl-2+
>>> +platforms  darwin
>>> +
>>> +homepage   http://www.lorene.obspm.fr/
>>> +master_sites   
>>> https://people.debian.org/~thibaut/debian/pool/main/l/lorene/
>>> +distname   lorene
>>> +distfiles  ${distname}_${version}+dfsg.orig.tar.xz
>> 
>> Because this is not a tar.gz file but a tar.xz file, you must use "use_xz 
>> yes" to tell MacPorts how to decompress it. (Mavericks (?) and later can 
>> figure it out automatically, but our policy is not to rely on that, and to 
>> specify it correctly in the Portfile.)
>> 
>> 
>>> +checksums   rmd160  36346f8d7a50acee20a5b81051af2e7fe5f188c1 \
>>> +sha256  
>>> ef797abc51ed8ae27c200f5b71fd0a3824d1fa310392dac57067de2e423222ed
>>> +worksrcdir ${distname}-${version}+dfsg
>>> +
>>> +depends_libport:OpenBLAS \
>>> +port:lapack \
>>> +port:gsl \
>>> +port:fftw-3 \
>>> +port:pgplot \
>>> +port:xorg-libX11
>>> +
>>> +compilers.choosecxx f77
>>> +compilers.setup require_fortran
>>> +
>>> +configure  {
>>> +file copy ${filespath}/local_settings ${worksrcpath}/
>>> +reinplace -W ${worksrcpath} "s|@CXX@|${configure.cxx}|g" local_settings
>>> +reinplace -W ${worksrcpath} "s|@F77@| ${configure.f77} |g" 
>>> local_settings
>>> +reinplace -W ${worksrcpath} "s|@CXXFLAGS@|${configure.cxxflags}|g" 
>>> local_settings
>>> +reinplace -W ${worksrcpath} "s|@FFLAGS@|${configure.fflags}|g" 
>>> local_settings
>>> +reinplace -W ${worksrcpath} "s|@LDFLAGS@|${configure.ldflags}|g" 
>>> local_settings
>>> +reinplace -W ${worksrcpath} 
>>> "s|@LIB_FORTRAN@|${compilers.libfortran}|g" local_settings
>>> +}
>> 
>> I don't see anywhere in this Portfile that arranges for the correct -arch 
>> (or, in the case of fortran, -m32/-m64) flags to be used. 
>> ([get_canonical_archflags ...])
>> 
>> The universal variant fails and should probably be disabled because:
> 
>> 
>> Error: Cannot install LORENE for the archs 'i386 x86_64' because
>> Error: its dependency pgplot does not build for the required archs by default
>> Error: and does not have a universal variant.
>> 
>> 
>>> +build.env-appendHOME_LORENE=${worksrcpath}
>>> +build.targetcpp fortran export
>>> +use_parallel_build  no
>>> +
>>> +destroot{
>>> +xinstall -d ${destroot}${prefix}/lib/lorene/Lib
>>> +xinstall {*}[glob ${worksrcpath}/Lib/*.a] 
>>> ${destroot}${prefix}/lib/lorene/Lib/
>>> +xinstall -d ${destroot}${prefix}/lib/lorene/C++/Include
>>> +xinstall {*}[glob ${worksrcpath}/C++/Include/*.h] 
>>> ${destroot}${prefix}/lib/lorene/C++/Include/
>>> +xinstall -d ${destroot}${prefix}/lib/lorene/C++/Include/Template
>>> +xinstall 

Re: port:lapack useful?

[Takeshi Enomoto]

Dear David,

> I just noticed that you created a port lapack (including BLAS) in r146856. Is 
> this really useful? We already have the ATLAS port which provides BLAS and 
> LAPACK; the OpenBLAS port which provides exactly the same implementation of 
> LAPACK from netlib as your port lapack; and the built-in Accelerate Framework 
> and the vecLibFort port providing a Fortran interface for it. All of these 
> are optimized and therefore should be faster than the straightforward netlib 
> implementation, and use directly of Accelerate/vecLibFort is of course by far 
> the fastest to install. So, what is the use of a separate port lapack? I 
> suspect its main effect will be to have users or port packagers use this one 
> instead of an optimized implementation because they do not realize the 
> optimized ones exist. For example, see the recent r153943. I would suggest 
> removing it.

I started LAPACK port to provide man pages after Apple removed them.
Some email exchanges with the LAPACK developers I became aware of the 
followings:

* LAPACK from netlib is active.
* the man pages can be generated from LAPACK source by make man.
* the most of the performance gain is due to BLAS, which can be obtained from 
BLAS.
* CBLAS and LAPACKE can be provided.

I believe that there is nothing to be harmful to leave the port.

The message from the upstream developer on 15 March 2016.

> Dear Takeshi,
> I am ccing Julien Langou - he is one of the PI of LAPACK and our most active 
> contributor.
> I saw your vecLibFort port - this is awesome and it was dearly needed.
> > vecLibFort is lightweight but flexible shim designed to rectify the 
> > incompatibilities between the Accelerate/vecLib BLAS and LAPACK libraries 
> > shipped with Mac OS X and FORTRAN code compiled with modern compilers such 
> > as GNU Fortran.
> 
> First, there is no real complete “optimized LAPACK” library around that I 
> know if except the one's from vendors (for Example: MKL INTEL)
> Second, most of the performance from a LAPACK code will come from an 
> Optimized BLAS library (i.e. Veclib)
> Veclib is based on Atlas, and I did not check, but I believe the LAPACK 
> included inside VecLib and vecLibFort correspond to the ATLAS LAPACK - which 
> is a small subset of LAPACK library.
> 
> So I think to write a port for LAPACK itself is a great idea.
> Also LAPACK now includes LAPACKE - A C Standard Interface to LAPACK - A lot 
> of users are using it.
> 
> Regards,
> Julie

Best wishes,

Takeshi
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: 2nd MacPorts Meeting & Online Meeting

[Rainer Müller]

On 2016-10-16 22:36, David Evans wrote:
> * now that I think about it, using irc might be the best way to go since a 
> transcript of the meeting
>   can be obtained from the irc logs.  After the meeting this can be processed 
> into a "minutes" document and
>   published to document the meeting proceedings. That way, people who don't 
> participate can benefit from
>   the meeting's discussion.

IRC bots with support for meeting can be used for this. They can be
instructed with commands to take notes of decisions and action items
during a meeting:

http://meetbot.debian.net/Manual.html

There might also be more modern business chat providers, but I have no
experience with any of them. IRC should be accessible to all and
FreeNode also offers a web interface.

> Establishment of a meeting time that is convenient to participants in a wide 
> range of
> geographical locations is probably the most difficult task and is key to good 
> turnout.  Maybe say 9 to 10 am on the
> US west coast which would translate to 6 to 7 pm in various parts of Europe.  
> Weekends might be better than
> weekdays to avoid conflicts with daily work schedules.

I also think finding the right time and date is the biggest obstacle.

I guess we should also not leave too much time between setting topics
and the actual meeting to avoid starting discussions early.

Rainer
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: 2nd MacPorts Meeting & Online Meeting

[Rainer Müller]

On 2016-10-16 23:58, Clemens Lang wrote:
> On Mon, Oct 10, 2016 at 07:53:13AM +0200, Mojca Miklavec wrote:
>> Me and Aljaž would be willing to host the MacPorts meeting in 2017
>> again.
> 
> Thanks, and sorry for not putting a plan together to do it in Munich in
> the fall. Seems I need to improve my time management :)

I feel guilty for that as well. However, there was a a lot of other
time-consuming stuff going on with the migration. Maybe we can revive
the plan another year.

I would appreciate another meeting next year. I will definitely want to
attend.

Rainer
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev