Re: [ITP] R-2.14.1-1
On Sat, 2012-02-11 at 11:12 +0100, marco atzeri wrote: > uploading (wait a bit) again > > bumped to 2.14.1-2 vs your effort. Thank you; uploaded. Yaakov
Re: [ITP] R-2.14.1-1
On 2/10/2012 5:08 AM, Yaakov (Cygwin/X) wrote: On Thu, 2012-02-09 at 21:37 -0600, Yaakov (Cygwin/X) wrote: On Thu, 2012-02-09 at 23:39 +0100, marco atzeri wrote: following last discussion with Yaakov about dll and reusing most of his effort, please find the package for R But why didn't you use *all* my effort? Ports git is public for a reason, and my modifications fix the problems your package has by not using them: * missing import libs for shared libR * misidentification of multilib support when installing from CRAN * missing runtime dependencies in setup.hint * static libiconv/libintl were used instead of dynamic (solved by cygautoreconf) * bundled liblzma is used instead of system version (missing liblzma-devel on your system?) Furthermore, is there a reason you use libRblas/libRlapack instead of the system lapack libraries? I forgot to mention: * I updated Ports git for 2.14.1 * I have no objections to dropping libRmath; nothing that I know of uses it. Yaakov uploading (wait a bit) again bumped to 2.14.1-2 vs your effort. wget -r -np -nH --cut-dirs=2 \ http://matzeri.altervista.org/cygwin-1.7/R/index.html rm ./index.html \ ./libRmath/index.html \ ./libRmath-devel/index.html libRmath/libRmath-2.14.1-2.tar.bz2 libRmath/setup.hint libRmath-devel/libRmath-devel-2.14.1-2.tar.bz2 libRmath-devel/setup.hint R-2.14.1-2-src.tar.bz2 R-2.14.1-2.tar.bz2 setup.hint Regards Marco
Re: [ITP] R-2.14.1-1
On 2/10/2012 11:39 AM, Corinna Vinschen wrote: On Feb 10 10:52, marco atzeri wrote: On 2/10/2012 10:11 AM, Yaakov (Cygwin/X) wrote: On Fri, 2012-02-10 at 07:30 +0100, marco atzeri wrote: On 2/10/2012 4:37 AM, Yaakov (Cygwin/X) wrote: Furthermore, is there a reason you use libRblas/libRlapack instead of the system lapack libraries? A tough discussion with R developers. They consider the standard Blas crippled as non correctly handling NaN. For what I saw they have the tendency to make their own version of any lib that does not fit on their exact expectation, for the same reason they do not consider libtool and have a very unusual build. Bundling libs is usually a bad idea, and as Debian, Fedora, and Gentoo all seem to use the system lapack, I'd suggest to do so as well (as done in Ports). Yaakov the request was a bit strong https://stat.ethz.ch/pipermail/r-devel/2011-November/062565.html It seems R is assuming math for NaN is a must. Question: Are the lapack packages for Debian, Fedora, and Gentoo less broken than the Cygwin ones? If so, why? Is that just a version problem which can be fixed by updating the package or is it due to the underlying implementation of some math functions in newlib? Corinna Our blas/lapack is a clean netlib reference implementation, I have not checked in detail but I expect Debian, Fedora, and Gentoo are the same. R expect blas to handle corner NaN case, that are not covered by netlib (I found nothing on the old netlib blas specification about NaN) as there are some short path handling multiplication by zero. I don't know if other implementations handle this case better or they do not care. In theory "NaN * 0 = NaN", but if you ignore NaN/Inf existence you can decide that "anything * 0 = 0" to speed-up the matrix math and save substantial time on matrix sparse multiplications. I politely suggested that if the reference is wrong, it should be patched upstream but I guess there is some "can of worms" somewhere in the past of the R development community about this issue. Regards Marco
Re: [ITP] R-2.14.1-1
On Feb 10 10:52, marco atzeri wrote: > On 2/10/2012 10:11 AM, Yaakov (Cygwin/X) wrote: > >On Fri, 2012-02-10 at 07:30 +0100, marco atzeri wrote: > >>On 2/10/2012 4:37 AM, Yaakov (Cygwin/X) wrote: > >>>Furthermore, is there a reason you use libRblas/libRlapack instead of > >>>the system lapack libraries? > >> > >>A tough discussion with R developers. They consider the standard Blas > >>crippled as non correctly handling NaN. > >> > >>For what I saw they have the tendency to make their own version of any > >>lib that does not fit on their exact expectation, for the same reason > >>they do not consider libtool and have a very unusual build. > > > >Bundling libs is usually a bad idea, and as Debian, Fedora, and Gentoo > >all seem to use the system lapack, I'd suggest to do so as well (as done > >in Ports). > > > > > >Yaakov > > > > the request was a bit strong > https://stat.ethz.ch/pipermail/r-devel/2011-November/062565.html > > It seems R is assuming math for NaN is a must. Question: Are the lapack packages for Debian, Fedora, and Gentoo less broken than the Cygwin ones? If so, why? Is that just a version problem which can be fixed by updating the package or is it due to the underlying implementation of some math functions in newlib? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [ITP] R-2.14.1-1
On Fri, 2012-02-10 at 10:52 +0100, marco atzeri wrote: > On 2/10/2012 10:11 AM, Yaakov (Cygwin/X) wrote: > >> For what I saw they have the tendency to make their own version of any > >> lib that does not fit on their exact expectation, for the same reason > >> they do not consider libtool and have a very unusual build. > > > > Bundling libs is usually a bad idea, and as Debian, Fedora, and Gentoo > > all seem to use the system lapack, I'd suggest to do so as well (as done > > in Ports). > > the request was a bit strong > https://stat.ethz.ch/pipermail/r-devel/2011-November/062565.html > > It seems R is assuming math for NaN is a must. > > I agree that bundling libs is usually a bad idea, and that the normal > solution is to solve the problem with upstream libs. But it seems > that the math guys have less cross-cooperation skill than I usually > expect by open source teams. > > Also netlib (blas/Lapack) have a peculiar development method I'm a bit confused from that thread. Is this a Cygwin-specific problem in our lapack package or do they just insist on using their own (modified) blas/lapack? As for their "request", experience has made me very skeptical (if not downright cynical) of upstreams mixing in to downstream packaging issues, *particularly* when it comes to Cygwin. That being said, if their blas/lapack is a must, then I won't object. The other issues I raised must definitely be fixed though, as they are already in Ports. Yaakov
Re: [ITP] R-2.14.1-1
On 2/10/2012 10:11 AM, Yaakov (Cygwin/X) wrote: On Fri, 2012-02-10 at 07:30 +0100, marco atzeri wrote: On 2/10/2012 4:37 AM, Yaakov (Cygwin/X) wrote: Furthermore, is there a reason you use libRblas/libRlapack instead of the system lapack libraries? A tough discussion with R developers. They consider the standard Blas crippled as non correctly handling NaN. For what I saw they have the tendency to make their own version of any lib that does not fit on their exact expectation, for the same reason they do not consider libtool and have a very unusual build. Bundling libs is usually a bad idea, and as Debian, Fedora, and Gentoo all seem to use the system lapack, I'd suggest to do so as well (as done in Ports). Yaakov the request was a bit strong https://stat.ethz.ch/pipermail/r-devel/2011-November/062565.html It seems R is assuming math for NaN is a must. I agree that bundling libs is usually a bad idea, and that the normal solution is to solve the problem with upstream libs. But it seems that the math guys have less cross-cooperation skill than I usually expect by open source teams. Also netlib (blas/Lapack) have a peculiar development method Marco
Re: [ITP] R-2.14.1-1
On Fri, 2012-02-10 at 07:30 +0100, marco atzeri wrote: > On 2/10/2012 4:37 AM, Yaakov (Cygwin/X) wrote: > > Furthermore, is there a reason you use libRblas/libRlapack instead of > > the system lapack libraries? > > A tough discussion with R developers. They consider the standard Blas > crippled as non correctly handling NaN. > > For what I saw they have the tendency to make their own version of any > lib that does not fit on their exact expectation, for the same reason > they do not consider libtool and have a very unusual build. Bundling libs is usually a bad idea, and as Debian, Fedora, and Gentoo all seem to use the system lapack, I'd suggest to do so as well (as done in Ports). Yaakov
Re: [ITP] R-2.14.1-1
On 2/10/2012 4:37 AM, Yaakov (Cygwin/X) wrote: On Thu, 2012-02-09 at 23:39 +0100, marco atzeri wrote: following last discussion with Yaakov about dll and reusing most of his effort, please find the package for R But why didn't you use *all* my effort? Ports git is public for a reason, and my modifications fix the problems your package has by not using them: I took it some time ago, so I could have missed something in the meantime. I will look again. * missing import libs for shared libR * misidentification of multilib support when installing from CRAN * missing runtime dependencies in setup.hint * static libiconv/libintl were used instead of dynamic (solved by cygautoreconf) * bundled liblzma is used instead of system version (missing liblzma-devel on your system?) liblzma-devel was missing...gr. Furthermore, is there a reason you use libRblas/libRlapack instead of the system lapack libraries? A tough discussion with R developers. They consider the standard Blas crippled as non correctly handling NaN. For what I saw they have the tendency to make their own version of any lib that does not fit on their exact expectation, for the same reason they do not consider libtool and have a very unusual build. Yaakov Marco
Re: [ITP] R-2.14.1-1
On Thu, 2012-02-09 at 21:37 -0600, Yaakov (Cygwin/X) wrote: > On Thu, 2012-02-09 at 23:39 +0100, marco atzeri wrote: > > following last discussion with Yaakov about dll and reusing most of > > his effort, please find the package for R > > But why didn't you use *all* my effort? Ports git is public for a > reason, and my modifications fix the problems your package has by not > using them: > > * missing import libs for shared libR > * misidentification of multilib support when installing from CRAN > * missing runtime dependencies in setup.hint > * static libiconv/libintl were used instead of dynamic (solved by > cygautoreconf) > * bundled liblzma is used instead of system version (missing > liblzma-devel on your system?) > > Furthermore, is there a reason you use libRblas/libRlapack instead of > the system lapack libraries? I forgot to mention: * I updated Ports git for 2.14.1 * I have no objections to dropping libRmath; nothing that I know of uses it. Yaakov
Re: [ITP] R-2.14.1-1
On Thu, 2012-02-09 at 23:39 +0100, marco atzeri wrote: > following last discussion with Yaakov about dll and reusing most of > his effort, please find the package for R But why didn't you use *all* my effort? Ports git is public for a reason, and my modifications fix the problems your package has by not using them: * missing import libs for shared libR * misidentification of multilib support when installing from CRAN * missing runtime dependencies in setup.hint * static libiconv/libintl were used instead of dynamic (solved by cygautoreconf) * bundled liblzma is used instead of system version (missing liblzma-devel on your system?) Furthermore, is there a reason you use libRblas/libRlapack instead of the system lapack libraries? Yaakov
[ITP] R-2.14.1-1
Hi, following last discussion with Yaakov about dll and reusing most of his effort, please find the package for R R is a free software environment for statistical computing and graphics http://www.r-project.org/ It is already present on major distribution. To do download: wget -r -np -nH --cut-dirs=2 \ http://matzeri.altervista.org/cygwin-1.7/R/index.html rm ./index.html file list: 23M R-2.14.1-1-src.tar.bz2 43M R-2.14.1-1.tar.bz2 1.0K setup.hint Regards Marco
