Re: [Bioc-devel] xps build problem on veracruz2

[Hervé Pagès]

Hi Christian,

Thanks for the update. Glad it works for you.

One small thing is that, if CMAKE_INSTALL_PREFIX is specified
when configuring ROOT, the ROOT libs get installed under
/lib/root, not under /lib. I was surprised by
this, but that's what I got when I installed ROOT on veracruz2.
I configured with:

export CC=/usr/local/clang4/bin/clang
export CXX=/usr/local/clang4/bin/clang++
cmake -DCMAKE_INSTALL_PREFIX=/usr/local/root -Dgnuinstall=ON 
-Dfortran=OFF -Dmysql=OFF -Dsqlite=OFF ../root


Then built with:

cmake --build . -- -j4

Then installed with:

sudo cmake --build . --target install

And the libraries got installed under /usr/local/root/lib/root

So when trying to install the latest xps, loading xps.so failed for
me because the ROOT libraries were not found. The following change
to Makefile.arch fixed the problem:

$ svn diff Makefile.arch
Index: Makefile.arch
===
--- Makefile.arch   (revision 129046)
+++ Makefile.arch   (working copy)
@@ -261,7 +261,7 @@
 CXXFLAGS  = $(OPT2) -pipe -Wall -W -Woverloaded-virtual
 LD= $(MACOSXTARGET) g++
 #LDFLAGS   = $(OPT2)
-LDFLAGS   = $(OPT2) -rpath $(shell $(ROOTCONFIG) --prefix)/lib
+LDFLAGS   = $(OPT2) -rpath $(shell $(ROOTCONFIG) --prefix)/lib 
-rpath $(shell $(ROOTCONFIG) --prefix)/lib/root

 UNDEFOPT  = dynamic_lookup
 # The SOFLAGS will be used to create the .dylib,
 # the .so will be created separately

Also note that the rpaths specified at linking time get hardcoded in
xps.so:

veracruz2:src biocbuild$ otool -l xps.so | tail -n 18
Load command 31
  cmd LC_RPATH
  cmdsize 32
 path /usr/local/root/lib (offset 12)
Load command 32
  cmd LC_RPATH
  cmdsize 40
 path /usr/local/root/lib/root (offset 12)
Load command 33
  cmd LC_FUNCTION_STARTS
  cmdsize 16
  dataoff 4141784
 datasize 14336
Load command 34
  cmd LC_DATA_IN_CODE
  cmdsize 16
  dataoff 4156120
 datasize 904

So the end user will need to have the ROOT libraries at these locations
too (unless s/he installs from source of course). This would need to be
explained in xps README file (which BTW should preferably be named
INSTALL).

Thanks,
H.


On 04/22/2017 05:15 AM, cstrato wrote:

Dear Herve,

I am glad to inform you that I have just uploaded version xps_1.35.3 to
BioC-dev branch. I have followed your suggestion to use -rpath and have
eliminated the environment variables DYLD_LIBRARY_PATH and LD_LIBRARY_PATH.

I have tested the new version on both Yosemite and on Sierra with
csrutil enabled! Thus I assume that it will also run on El Capitan.

Best regards,
Christian

P.S.:
Please allow me to comment on your note on [DY]LD_LIBRARY_PATH.
As you know xps was uploaded to Bioc 10 years ago (with your kind help)
and is available on BioC since 9 years.
At that time the environment variables [DY]LD_LIBRARY_PATH were
necessary, and for many years required by ROOT. Since xps did run on the
Mac on all systems from Leopard till Yosemite w/o problems I had no need
to change it.
Furthermore, I had not heard that the use of these variables have been
discouraged, just like many other developers who only now realize that
they have to use rpath or simply disable csrutil (I have realized this
when googling around).



On 04/21/17 00:29, Hervé Pagès wrote:

Also relying on [DY]LD_LIBRARY_PATH is considered bad practice and
has been discouraged for years. xps is the only Bioconductor package
that relies on these variables for its configure/build process.

H.

On 04/20/2017 03:24 PM, Dan Tenenbaum wrote:

Disabling SIP should not be done anywhere. Every page I've read on
this topic strongly discourages doing this.


- Original Message -

From: "Hervé Pagès" 
To: "cstrato" , "Dan Tenenbaum"

Cc: "bioc-devel" 
Sent: Thursday, April 20, 2017 3:17:23 PM
Subject: Re: [Bioc-devel] xps build problem on veracruz2



On 04/20/2017 03:01 PM, cstrato wrote:

Dear Herve,

Doing 'csrutil disable' does indeed solve the problem, since:

1, in this way I was able to build xps on Mac OS Sierra

2, in this way I could already help one user of xps, see:
https://urldefense.proofpoint.com/v2/url?u=https-3A__support.bioconductor.org_p_90056_-2390247=DwIDaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=q0hKDI_veZEYmjrYbsK1Xqu--fGdfl_JmfSKLygl_dg=GfzgU1Ibm_scFWO58Mv_ZfxKtn-FSJgkxMW1ZBYK1Vs=



This means, that users of xps seem to be willing to disable csrutil.


I'm not a statistician but I wouldn't draw conclusions from a sample
of size 1. Mac users who cannot install xps on their machine will
use something else, or, if they desperately need xps, they will
grab a Linux box.

Sorry but disabling SIP on our Mac builders is not an option.





However, I just realized that there may be an even greater problem,
namely, which version of ROOT should a user 

Re: [Bioc-devel] xps build problem on veracruz2

[cstrato]

Dear Herve,

I am glad to inform you that I have just uploaded version xps_1.35.3 to 
BioC-dev branch. I have followed your suggestion to use -rpath and have 
eliminated the environment variables DYLD_LIBRARY_PATH and LD_LIBRARY_PATH.


I have tested the new version on both Yosemite and on Sierra with 
csrutil enabled! Thus I assume that it will also run on El Capitan.


Best regards,
Christian

P.S.:
Please allow me to comment on your note on [DY]LD_LIBRARY_PATH.
As you know xps was uploaded to Bioc 10 years ago (with your kind help) 
and is available on BioC since 9 years.
At that time the environment variables [DY]LD_LIBRARY_PATH were 
necessary, and for many years required by ROOT. Since xps did run on the 
Mac on all systems from Leopard till Yosemite w/o problems I had no need 
to change it.
Furthermore, I had not heard that the use of these variables have been 
discouraged, just like many other developers who only now realize that 
they have to use rpath or simply disable csrutil (I have realized this 
when googling around).




On 04/21/17 00:29, Hervé Pagès wrote:

Also relying on [DY]LD_LIBRARY_PATH is considered bad practice and
has been discouraged for years. xps is the only Bioconductor package
that relies on these variables for its configure/build process.

H.

On 04/20/2017 03:24 PM, Dan Tenenbaum wrote:

Disabling SIP should not be done anywhere. Every page I've read on
this topic strongly discourages doing this.


- Original Message -

From: "Hervé Pagès" 
To: "cstrato" , "Dan Tenenbaum" 
Cc: "bioc-devel" 
Sent: Thursday, April 20, 2017 3:17:23 PM
Subject: Re: [Bioc-devel] xps build problem on veracruz2



On 04/20/2017 03:01 PM, cstrato wrote:

Dear Herve,

Doing 'csrutil disable' does indeed solve the problem, since:

1, in this way I was able to build xps on Mac OS Sierra

2, in this way I could already help one user of xps, see:
https://urldefense.proofpoint.com/v2/url?u=https-3A__support.bioconductor.org_p_90056_-2390247=DwIDaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=q0hKDI_veZEYmjrYbsK1Xqu--fGdfl_JmfSKLygl_dg=GfzgU1Ibm_scFWO58Mv_ZfxKtn-FSJgkxMW1ZBYK1Vs=


This means, that users of xps seem to be willing to disable csrutil.


I'm not a statistician but I wouldn't draw conclusions from a sample
of size 1. Mac users who cannot install xps on their machine will
use something else, or, if they desperately need xps, they will
grab a Linux box.

Sorry but disabling SIP on our Mac builders is not an option.





However, I just realized that there may be an even greater problem,
namely, which version of ROOT should a user install?

People can download ROOT binaries built with XCode 7.x from:
https://urldefense.proofpoint.com/v2/url?u=https-3A__root.cern.ch_content_release-2D53436=DwIDaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=q0hKDI_veZEYmjrYbsK1Xqu--fGdfl_JmfSKLygl_dg=LByiYPyOfsHnRc9oOqXOs9xMcfltktXgkTQ3sh5hKFc=

for OS X 10.10 and 10.11.

Thus for El Capitan they can download the following binaries:
- root_v5.34.36.macosx64-10.11-clang70.dmg
- root_v5.34.36.macosx64-10.11-clang70.tar.gz

Did you install one of those binaries or did you compile ROOT from
source?


As I said earlier, I compiled ROOT 5 from source on veracruz2.



With the help of my README file people could compile ROOT from source
for XCode 8.x.


However, you have mentioned that the CRAN people are using clang 4.0.0
for producing the Mac binaries of R and CRAN packages and thus you are
using the same on veracruz2.


Yes.



Did you compile ROOT with XCode 7 or 8 or did you use clang 4.0.0,
which
is not officially supported by Apple?


With clang 4.0.0.



The question is whether xps built with this version of ROOT will work
with the ROOT binaries which people can download from ROOT?


I guess someone will need to figure this out.

Note that if people need to compile their own ROOT anyway in order to
be able to use the xps binary we distribute, then they should also be
able to install xps from source. So that defeats the purpose of
providing a binary in the first place.

Cheers,
H.



Best regards,
Christian



On 04/20/17 20:00, Hervé Pagès wrote:

On 04/20/2017 10:59 AM, Hervé Pagès wrote:

Hi Christian,

Disabling 'csrutil disable' might help xps on veracruz2 but that

  ^^
oops, no double negative intended here. I meant, doing 'csrutil
disable'
might help... etc

H.


won't help your end users.

I'm no expert in developing a package on Mac but other people on
this list are. Also R-SIG-Mac might be a good place to seek help
for this.

Cheers,
H.


On 04/20/2017 10:53 AM, cstrato wrote:

Dear Herve,

Thank you for your efforts to try to install xps. I am glad to hear
that
you could build ROOT 5 from source.

It's a pity that Apple does no longer allow the use of
DYLD_LIBRARY_PATH. This seems to break the code of a lot of people
(when
googling 

Re: [Bioc-devel] test coverage of a shiny app

[Marcel Ramos]

Hi Sam,
This is a pertinent issue to shiny app development and there are continuing
efforts to create unit tests for shiny applications.

At the moment, there is a package dedicated to providing tests for shiny
applications but it has not been published.
See: https://github.com/rstudio/shinytest

This link may also provide some testing examples:
https://cran.r-project.org/web/packages/RSelenium/vignettes/shinytesting.html

In the meantime, I would advise to simply test the functions and
manipulations that generate the data for your shiny application.
I'm eager to hear other developer's inputs on this subject.

Best regards,
Marcel

On Tue, Apr 11, 2017 at 2:46 AM Samuel Wieczorek 
wrote:

> Hi
>
> I am the developer of the packages Prostar ad DAPAR and I would like to
> write some unit test for Prostar which contains a Shiny application. I
> wrote a test script in the 'test' directory where I am using functions
> from the shiytest package but I don't know how to really test my app
> (Prostar()). And then, the result of packages_coverage is still equal to
> 0%.
>
> Is there anyone who has already developed a Shiny app with unit tests ?
> I would appreciate some examples.
>
>
> Thanks in advance
>
>
> Sam
>
>
> --
> *Samuel Wieczorek
>
> Etude de la Dynamique des Protéomes (EDyP)*
> *Laboratoire Biologie à Grande Echelle (BGE)*
> *U1038 INSERM / CEA / UGA*
> *Biosciences and Biotechnology Institute of Grenoble (BIG)*
> *CEA / Grenoble*
> *17 avenue des Martyrs*
> *F-38054 Grenoble Cedex 9*
> */Tél. : 04.38.78.44.14/*
> */Fax : 04.38.78.50.51/*
>
> http://www.edyp.fr/
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel