Re: [R-pkg-devel] Lapack: undefined symbol: zgbsv_

[Baptiste Auguie]

On 13 February 2018 at 22:07, Ralf Stubner 
wrote:

> On 13.02.2018 05:49, Baptiste Auguie wrote:
> > On 13 February 2018 at 01:05, Dirk Eddelbuettel  > > wrote:
> > Maybe we are setting a more global "no advanced lapack" for Windows
> that
> > assures success when we assume that the other system will always
> > have it.
> >
> >
> > it sounds plausible, but it would be nice to know for sure.
>
> It is the case, c.f.
> https://github.com/RcppCore/RcppArmadillo/blob/master/inst/i
> nclude/RcppArmadilloConfig.h#L96-L106
>
> > In
> > particular, it doesn't explain why the external Lapack on linux appears
> > to be missing these symbols (they're not very recent, as far as I can
> > tell). I don't really know how to figure this out, but it seems to be
> key.
>
> My understanding:
>
> * On Windows internal LAPACK is used but it is not affected due to the
> defines quoted above.
> * At least Debian & Co but probably also other Linux distributions
> compile R with external LAPACK and are not affected.
> * CRAN (and probably r-hub) use R compiled with internal LAPACK and is
> therefore affected.
>


Thanks Ralf, now it makes more sense to me. I had misunderstood the
situation on CRAN and r-hub and thought they used an external Lapack on
linux.



> * I do not understand why Mac OS is not affected. The FAQ [1] implies
> that by default the internal BLAS/LAPACK is used. But then I do not see
> the mentioned alternative libRblas.vecLib.dylib on a test system.
>
> [1]
> https://cran.r-project.org/bin/macosx/RMacOSX-FAQ.html#Which
> -BLAS-is-used-and-how-can-it-be-changed_003f
>
>
> > Or, be brutal, and set '#define ARMA_CRIPPLED_LAPACK 1' everywhere.
> See
> > lines 67 to 95 of RcppArmadillo's configure.ac  >:
> > https://github.com/RcppCore/RcppArmadillo/blob/master/confi
> gure.ac#L67-L95
> >
> > while this might solve the CRAN problem, it doesn't feel right to
> > enforce the use of suboptimal routines throughout and on all platforms,
> > including those that do in fact provide a full-fledged external Lapack.
>
> You could use this as a first step to get the package back into CRAN.
> Later on you can try to only set the flag when an internal LAPACK is
> detected, similar to the way RcppArmadillo does it. If my understanding
> above is correct, the number of users with ARMA_CRIPPLED_LAPACK in your
> package but not in RcppArmadillo will be quite small.
>

It would make sense to test for internal vs external Lapack and decide
based on that (regardless of the OS); as you say, the results should be
essentially identical to what happens when the same user installs
RcppArmadillo on their machine. Unfortunately I don't know how to proceed.
I copied RcppArmadillo's configure.ac script and tried to extract just the
Lapack testing bits, but these macro and configure concepts are totally
foreign to me. I believe it would be helpful to have a minimal example of
this type of configuration for the dummy isolve package (
https://github.com/baptiste/isolve), if someone with such expertise and a
linux machine is willing to help.

Thanks,

baptiste


>
> Greetings
> Ralf
>
> --
> Ralf Stubner
> Senior Software Engineer / Trainer
>
> R Institute GmbH
> Dortustraße 48
> 14467 Potsdam
>
> T: +49 331 23 70 81 66
> F: +49 331 23 70 81 67
> M: +49 162 20 91 196
>
> Mail: ralf.stub...@r-institute.com
>
> Sitz: Potsdam
> Register: AG Potsdam HRB 27966 P
> Ust.-IdNr.: DE300072622
> Geschäftsführer: Prof. Dr. Dr. Karl-Kuno Kunze
>
>

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Solaris and ggplot2

[Kevin Ushey]

Hi,

Glancing at the R CMD check errors, available at:

https://www.r-project.org/nosvn/R.check/r-patched-solaris-x86/RJafroc-00install.html)

It seems like the issues relate to ambiguous calls to 'sqrt()'. This
particular issue is discussed in R-exts, at:

https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Portable-C-and-C_002b_002b-code

You would likely be able to resolve this by calling e.g. 'sqrt(2.0)'
instead of 'sqrt(2)'.

Best,
Kevin

On Tue, Feb 13, 2018 at 2:58 PM, Dev Chakraborty  wrote:
> My package RJafroc, which is currently on CRAN, passes all operating
> systems except solaris-x86-patched, and as a result has been flagged for
> removal. Using R-hub builder, I am unable to reproduce the log file because
> a required package, ggplot2, does not exist for Solaris. I found the
> following conversation on GitHub at the following URL:
> https://github.com/tidyverse/ggplot2/issues/2273 (the conversation is
> reproduced below).
>
> Could use any advice. Thanks.
>
> Dev
>
> **
> tdhock commented on Sep 23, 2017
> Hey there, it seems that ggplot2 on CRAN has an ERROR on solaris
> https://www.r-project.org/nosvn/R.check/r-patched-so
> laris-x86/ggplot2-00check.html because of a test about date scales that
> does not pass. Do you have any plan to fix?
>
> This is an issue for me because I have a package that imports ggplot2, and
> I would like to use rhub to check it on solaris before submitting it to
> CRAN. *However rhub can not perform the check because the ggplot2 package
> is not available on solaris*. Here is the related issue at rhub
> r-hub/rhub#83
>
>  @hadley
>  Owner
> hadley commented on Oct 30, 2017
> *Probably not, since solaris is going away.*
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Solaris and ggplot2

[Gábor Csárdi]

This is probably because stringi does not compile on r-hub, and
ggplot2 depends on stringi.
This is a known and as of yet unsolved issue:
https://github.com/gagolews/stringi/issues/275

Gabor

On Tue, Feb 13, 2018 at 10:58 PM, Dev Chakraborty  wrote:
> My package RJafroc, which is currently on CRAN, passes all operating
> systems except solaris-x86-patched, and as a result has been flagged for
> removal. Using R-hub builder, I am unable to reproduce the log file because
> a required package, ggplot2, does not exist for Solaris. I found the
> following conversation on GitHub at the following URL:
> https://github.com/tidyverse/ggplot2/issues/2273 (the conversation is
> reproduced below).
>
> Could use any advice. Thanks.
>
> Dev
>
> **
> tdhock commented on Sep 23, 2017
> Hey there, it seems that ggplot2 on CRAN has an ERROR on solaris
> https://www.r-project.org/nosvn/R.check/r-patched-so
> laris-x86/ggplot2-00check.html because of a test about date scales that
> does not pass. Do you have any plan to fix?
>
> This is an issue for me because I have a package that imports ggplot2, and
> I would like to use rhub to check it on solaris before submitting it to
> CRAN. *However rhub can not perform the check because the ggplot2 package
> is not available on solaris*. Here is the related issue at rhub
> r-hub/rhub#83
>
>  @hadley
>  Owner
> hadley commented on Oct 30, 2017
> *Probably not, since solaris is going away.*
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

[R-pkg-devel] Solaris and ggplot2

[Dev Chakraborty]

My package RJafroc, which is currently on CRAN, passes all operating
systems except solaris-x86-patched, and as a result has been flagged for
removal. Using R-hub builder, I am unable to reproduce the log file because
a required package, ggplot2, does not exist for Solaris. I found the
following conversation on GitHub at the following URL:
https://github.com/tidyverse/ggplot2/issues/2273 (the conversation is
reproduced below).

Could use any advice. Thanks.

Dev

**
tdhock commented on Sep 23, 2017
Hey there, it seems that ggplot2 on CRAN has an ERROR on solaris
https://www.r-project.org/nosvn/R.check/r-patched-so
laris-x86/ggplot2-00check.html because of a test about date scales that
does not pass. Do you have any plan to fix?

This is an issue for me because I have a package that imports ggplot2, and
I would like to use rhub to check it on solaris before submitting it to
CRAN. *However rhub can not perform the check because the ggplot2 package
is not available on solaris*. Here is the related issue at rhub
r-hub/rhub#83

 @hadley
 Owner
hadley commented on Oct 30, 2017
*Probably not, since solaris is going away.*

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] new package? - Sports data from transfermarkt.com using rvest

[Kehl Dániel]

Dear Peter and Thierry,

thank you for your answers. I indeed contacted transfermarkt.com and write this 
just to finish up this conversation.

Here is part of their answer:

"thank you for getting in touch with us. Basically our data is copyrighted 
under German law by Transfermarkt, so there is no license whatsoever. 
Therefore, we�re also no friends of data scraping and tend to block bots more 
and more.
Rather we support the scientific community by providing data sets for single 
purposes in a structured process."

Seems like this is a polite way of saying: do not create an R package with this 
purpose. My first package is going to be something else. :(

Thanks and have a great day,
Daniel


[http://wweb.ktk.pte.hu/info/email-alairas/Oktat%C3%B3k/Dr.%20KEHL%20D%C3%A1niel/magyar/image001.png]



Dr. KEHL D�niel
adjunktus

[http://wweb.ktk.pte.hu/info/email-alairas/Oktat%C3%B3k/Dr.%20KEHL%20D%C3%A1niel/magyar/image002.png]
P�CSI TUDOM�NYEGYETEM K�ZGAZDAS�GTUDOM�NYI KAR
K�zgazdas�gtan �s �konometria Int�zet
H-7622 P�cs, R�k�czi �t 80. | www.ktk.pte.hu
+36 72 501 599/ 23144 | ke...@ktk.pte.hu

Felad�: Peter Meissner [retep.meiss...@gmail.com]
K�ldve: 2018. janu�r 24. 18:59
C�mzett: Thierry Onkelinx
M�solatot kap: Kehl D�niel; r-package-devel@r-project.org
T�rgy: Re: [R-pkg-devel] new package? - Sports data from transfermarkt.com 
using rvest

Hey,

I am not a laywer but their terms are quite explicitly prohibiting 
redistribution of their data without written consent.

Now you might build a package that does not collect, store and redistributes 
the data but only allows to access the data provided there 'live' via some 
convenience functions. But I don't really know if that argument actually is 
valid in any legal sense.

To be on the safe side, you probably should contact them.

Best, Peter


Am 24.01.2018 12:13 nachm. schrieb "Thierry Onkelinx" 
>:
Dear Daniel,

First of all you need to make sure that the licence of
transfermarkt.com allows the usage that you have 
intended. If that is
not clear from their website, then you should contact them rather than
us.

CRAN has several packages to assists in downloading data from online
sources. But the source has to allow that kind of usage.

Best regards,

ir. Thierry Onkelinx
Statisticus / Statistician

Vlaamse Overheid / Government of Flanders
INSTITUUT VOOR NATUUR- EN BOSONDERZOEK / RESEARCH INSTITUTE FOR NATURE
AND FOREST
Team Biometrie & Kwaliteitszorg / Team Biometrics & Quality Assurance
thierry.onkel...@inbo.be
Havenlaan 88 bus 73, 1000 Brussel
www.inbo.be

///
To call in the statistician after the experiment is done may be no
more than asking him to perform a post-mortem examination: he may be
able to say what the experiment died of. ~ Sir Ronald Aylmer Fisher
The plural of anecdote is not data. ~ Roger Brinner
The combination of some data and an aching desire for an answer does
not ensure that a reasonable answer can be extracted from a given body
of data. ~ John Tukey
///




2018-01-23 16:27 GMT+01:00 Kehl D�niel 
>:
> Dear List members,
>
> maybe this is not the right place to ask, if that is the case, please forward 
> me to the right place.
> I developed some functions to download and transform football/soccer related 
> data from transfermarkt.com.
> There are plans to create my first package based on these functions and of 
> course develop them and add more later. As far as I know there is no API to 
> that page, so I am using the rvest package.
> My question is: is this an OK thing to do? Should I contact 
> transfermarkt.com? My german is not perfect (just 
> like my english), this is what I've found on thier webpage. Does that mean 
> one can not create a package related to that page? Or can't crawl at all? Or 
> just not allowed to sell the data? If it is allowed, can one post the package 
> on CRAN at the end?
>
> Please if any of you have experience in that or just show me where to ask, do 
> not hesitate!
>
> LEGAL NOTICE
> � Transfermarkt GmbH & Co. KG 2000-2018
>
> All rights reserved.
>
> Der Inhalt dieser Website ist urheberrechtlich gesch�tzt. Nachdruck, Aufnahme 
> in Online-Dienste, Internet und Vervielf�ltigung auf Datentr�ger wie CD-ROM, 
> DVD-ROM usw. d�rfen, auch auszugsweise, nur nach vorheriger schriftlicher 
> Zustimmung durch Transfermarkt erfolgen. Eine kommerzielle Weitervermarktung 
> des Inhalts ist untersagt.
>
> Transfermarkt haftet nicht f�r unverlangt eingesandte Inhalte, Manuskripte 
> und Fotos. F�r Inhalte externer 

Re: [R-pkg-devel] Lapack: undefined symbol: zgbsv_

[Ralf Stubner]

On 13.02.2018 05:49, Baptiste Auguie wrote:
> On 13 February 2018 at 01:05, Dirk Eddelbuettel  > wrote:
> Maybe we are setting a more global "no advanced lapack" for Windows that
> assures success when we assume that the other system will always
> have it.
> 
> 
> it sounds plausible, but it would be nice to know for sure.

It is the case, c.f.
https://github.com/RcppCore/RcppArmadillo/blob/master/inst/include/RcppArmadilloConfig.h#L96-L106

> In
> particular, it doesn't explain why the external Lapack on linux appears
> to be missing these symbols (they're not very recent, as far as I can
> tell). I don't really know how to figure this out, but it seems to be key.

My understanding:

* On Windows internal LAPACK is used but it is not affected due to the
defines quoted above.
* At least Debian & Co but probably also other Linux distributions
compile R with external LAPACK and are not affected.
* CRAN (and probably r-hub) use R compiled with internal LAPACK and is
therefore affected.
* I do not understand why Mac OS is not affected. The FAQ [1] implies
that by default the internal BLAS/LAPACK is used. But then I do not see
the mentioned alternative libRblas.vecLib.dylib on a test system.

[1]
https://cran.r-project.org/bin/macosx/RMacOSX-FAQ.html#Which-BLAS-is-used-and-how-can-it-be-changed_003f


> Or, be brutal, and set '#define ARMA_CRIPPLED_LAPACK 1' everywhere.  See
> lines 67 to 95 of RcppArmadillo's configure.ac :
> https://github.com/RcppCore/RcppArmadillo/blob/master/configure.ac#L67-L95
> 
> while this might solve the CRAN problem, it doesn't feel right to
> enforce the use of suboptimal routines throughout and on all platforms,
> including those that do in fact provide a full-fledged external Lapack. 

You could use this as a first step to get the package back into CRAN.
Later on you can try to only set the flag when an internal LAPACK is
detected, similar to the way RcppArmadillo does it. If my understanding
above is correct, the number of users with ARMA_CRIPPLED_LAPACK in your
package but not in RcppArmadillo will be quite small.

Greetings
Ralf

-- 
Ralf Stubner
Senior Software Engineer / Trainer

R Institute GmbH
Dortustraße 48
14467 Potsdam

T: +49 331 23 70 81 66
F: +49 331 23 70 81 67
M: +49 162 20 91 196

Mail: ralf.stub...@r-institute.com

Sitz: Potsdam
Register: AG Potsdam HRB 27966 P
Ust.-IdNr.: DE300072622
Geschäftsführer: Prof. Dr. Dr. Karl-Kuno Kunze

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel