Re: [Rd] Building R from source with the PGI compiler

[Erin Hodgess]

Hello!

I’m working on a supercomputer and will be tying into some FORTRAN
programs.  Those programs use OpenACC, which must be compiled with PGI.

In case you are wondering, Why don’t I use C?  I actually started with C
and FORTRAN is faster.

Thanks for listening,
Erin

On Thu, Dec 21, 2017 at 6:58 PM Michael Hannon 
wrote:

> Hi, Erin.  Please feel free to ignore this, but I'm curious: what is
> the advantage to using the PGI compiler?
>
> -- Mike
>
>
> On Wed, Dec 20, 2017 at 5:03 PM, Erin Hodgess 
> wrote:
> > Hello
> >
> > I would like to build R from source and use the PGI compiler, rather than
> > the GCC compiler.
> >
> > I saw the instructions for the Intel compiler in the R Installation
> Manual,
> > but I didn't see the PGI.  I tried a few times without instructions, but
> > without success.
> >
> > Any suggestions would be most welcome.  Also, I hope this is the right
> > group for the question.
> >
> > Sincerely,
> > Erin
> >
> >
> >
> > --
> > Erin Hodgess
> > Associate Professor
> > Department of Mathematical and Statistics
> > University of Houston - Downtown
> > mailto: erinm.hodg...@gmail.com
> >
> > [[alternative HTML version deleted]]
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
-- 
Erin Hodgess
Associate Professor
Department of Mathematical and Statistics
University of Houston - Downtown
mailto: erinm.hodg...@gmail.com

[[alternative HTML version deleted]]

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

Re: [Rd] Building R from source with the PGI compiler

[Michael Hannon]

Hi, Erin.  Please feel free to ignore this, but I'm curious: what is
the advantage to using the PGI compiler?

-- Mike


On Wed, Dec 20, 2017 at 5:03 PM, Erin Hodgess  wrote:
> Hello
>
> I would like to build R from source and use the PGI compiler, rather than
> the GCC compiler.
>
> I saw the instructions for the Intel compiler in the R Installation Manual,
> but I didn't see the PGI.  I tried a few times without instructions, but
> without success.
>
> Any suggestions would be most welcome.  Also, I hope this is the right
> group for the question.
>
> Sincerely,
> Erin
>
>
>
> --
> Erin Hodgess
> Associate Professor
> Department of Mathematical and Statistics
> University of Houston - Downtown
> mailto: erinm.hodg...@gmail.com
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

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

Re: [Rd] R CMD check warning about compiler warning flags

[Martin Morgan]

On 12/21/2017 01:02 PM, Winston Chang wrote:

On recent builds of R-devel, R CMD check gives a WARNING when some
compiler warning flags are detected, such as -Werror, because they are
non-portable. This appears to have been added in this commit:
https://github.com/wch/r-source/commit/2e80059


That is not the canonical R sources.


Yes, that is obvious. The main page for that repository says it is a
mirror of the R sources, right at the top. I know that because I put
the message there, and because I see it every time I visit the
repository. If you have a good way of pointing people to the changes
made in a commit with the canonical R sources, please let us know. I
and many others would be happy to use it.


In case 'pointing to' is not to mean exclusively 'pointing a mouse at', 
'a good way' can include typing at the console and living with the 
merits and demerits of svn, and the question is not 
rhetorical(probably FALSE on all accounts, but one never knows...)


Check out or update the source (linux, mac, or Windows)

  svn co https://svn.r-project.org/R/trunk R-devel
  cd R-devel
  svn up

browse the commit history

  svn log | less

and review the change

  svn diff -c73909

Restrict by specifying a path

  svn diff -c73909 src/library/tools/R/check.R

(I don't think one gets finer resolution, other than referencing the 
line number in the diff)


View a range of revisions, e.g.,

  svn diff -r73908:73909

And find commits associated with lines of code

  svn annotate doc/manual/R-exts.texi | less

A quick google search (svn diff visual display) lead me to

  svn diff --diff-cmd meld -c73909

for my platform, which pops up the diffs in a visual context.

Martin Morgan




And your description seems wrong:
there is now an _optional_ check controlled by an environment variable,
primarily for CRAN checks.


The check is "optional", but not for packages submitted to CRAN.



I'm working on a package where these compiler warning flags are
present in a Makefile generated by a configure script -- that is, the
configure script detects whether the compiler supports these flags,
and if so, puts them in the Makefile. (The configure script is for a
third-party C library which is in a subdirectory of src/.)

Because the flags are added only if the system supports them, there
shouldn't be any worries about portability in practice.



Please read the explanation in the manual: there are serious concerns about
such flags which have bitten CRAN users several times.

To take your example, you cannot know what -Werror does on all compilers
(past, present or future) where it is supported (and -W flags do do
different things on different compilers).  On current gcc it does

-Werror
Make all warnings into errors.

and so its effect depends on what other flags are used (people typically use
-Wall, and most new versions of both gcc and clang add more warnings to
-Wall -- I read this week exactly such a discussion about the interaction of
-Werror with -Wtautological-constant-compare as part of -Wall in clang
trunk).


Is there a way to get R CMD check to not raise warnings in cases like
this? I know I could modify the C library's configure.ac (which is
used to generate the configure script) but I'd prefer to leave the
library's code untouched if possible.


You don't need to (and most likely should not) use the C[XX]FLAGS it
generates ... just use the flags which R passes to the package to use.


It turns out that there isn't even a risk of these compiler flags
being used -- I learned from of my colleagues that the troublesome
compiler flags, like -Werror, never actually appear in the Makefile.
The configure script prints out those compiler flags out when it
checks for them, but in the end it creates a Makefile with the CFLAGS
inherited from R. So there's no chance that the library would be
compiled using those flags (unless R passed them along).

His suggested workaround is to silence the output of the configure
script. That also hides some useful information, but it does work for
this issue.

-Winston

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




This email message may contain legally privileged and/or...{{dropped:2}}

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

[Bioc-devel] Submit data package or use AnnotationHub?

[Steve Lianoglou]

Hi all,

Briefly:

I'm looking to get guidance on how to handle data packages that
support a suite of software packages I'd like to submit to
bioconductor.

More Detail:

We (Genentech) have opened sourced some packages I've been developing
internally for the past few years that facilitate the execution and
exploration of gene set enrichment analyses.

https://github.com/lianos/multiGSEA
https://github.com/lianos/multiGSEA.shiny

I will submit them to bioc "in the normal way", however my question is
how I should do that because there are also data packages I have (that
are Suggest(ed) by multiGSEA) that need to go in as well.

Would these data go in as data packages or via AnnotationHub?

multiGSEA provides convenience wrappers to retrieve genesets from
different sources. One of these resources is the gene set collections
made available by MSigDB. Using multiGSEA, a user can get the hallmark
and c2 gene set collections like so:

```
library(multiGSEA)
gdb.human <- getMSigGeneSetDb(c("h", "c2"), "human")
gdb.mouse <- getMSigGeneSetDb(c("h", "c2"), "mouse")
```

These function calls check if the following data packages are
installed and retrieve the appropriate gene sets if so (otherwise they
raise an error):

https://github.com/lianos/GeneSetDb.MSigDB.Hsapiens.v61
https://github.com/lianos/GeneSetDb.MSigDB.Mmusculus.v61

I've created these data packages so that they approximate what I think
looks like something suitable for AnnotationHub (ie. with working
inst/scripts/make-data.R scripts). These data packages start with
MSigDB's gene set *xml files (ie. 'msigdb_v6.1.xml') and convert them
into multiGSEA::GeneSetDb *.rds objects which are then used by the
multiGSEA and multiGSEA.shiny packages.

I'm curious how to proceed from here?

Thanks,
-steve

ps: I know bioc looks down on not using "foundational" bioc classes,
so we can have this discussion during pkg review, but a GeneSetDb
object is a reimagined take on the GSEABase::GeneSetCollection.
Unfortunately the latter just wasn't providing the functionality I
wanted for how I felt like I wanted to interact with collections of
genesets ... mulitGSEA provides methods to convert a GeneSetCollection
to a GeneSetDb, and vice versa


-- 
Steve Lianoglou
Bioinformatics Scientist
Cancer Immunology
Genentech

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

Re: [Rd] R CMD check warning about compiler warning flags

[Duncan Murdoch]

On 21/12/2017 1:02 PM, Winston Chang wrote:

On recent builds of R-devel, R CMD check gives a WARNING when some
compiler warning flags are detected, such as -Werror, because they are
non-portable. This appears to have been added in this commit:
https://github.com/wch/r-source/commit/2e80059


That is not the canonical R sources.


Yes, that is obvious. The main page for that repository says it is a
mirror of the R sources, right at the top. I know that because I put
the message there, and because I see it every time I visit the
repository. If you have a good way of pointing people to the changes
made in a commit with the canonical R sources, please let us know. I
and many others would be happy to use it.


The usual way is just to refer to the revision number, i.e. "This 
appears to have been added in rev 73909".


People who don't have the sources checked out can see the diff on your 
Github mirror using


https://github.com/wch/r-source/search?q="trunk@73909"=Commits

and following the listed search hit. (Thanks to Thierry Onkelinx for 
helping me with this.) This only works for commits to the trunk.  I 
guessed that something like


https://github.com/wch/r-source/search?q="R-3-4-branch@73937"=Commits

would work if the commit was to the 3.4 branch, but apparently not.  I 
don't know how to find those commits.  Presumably there's a way, but I 
don't know it.


Another possibility is that someone could set up (or already has?) one 
of the web viewers (WebSVN, etc.) for the real repository.  That would 
be better for those of us who are SVN users, but probably harder for Git 
users.


Duncan Murdoch





And your description seems wrong:
there is now an _optional_ check controlled by an environment variable,
primarily for CRAN checks.


The check is "optional", but not for packages submitted to CRAN.



I'm working on a package where these compiler warning flags are
present in a Makefile generated by a configure script -- that is, the
configure script detects whether the compiler supports these flags,
and if so, puts them in the Makefile. (The configure script is for a
third-party C library which is in a subdirectory of src/.)

Because the flags are added only if the system supports them, there
shouldn't be any worries about portability in practice.



Please read the explanation in the manual: there are serious concerns about
such flags which have bitten CRAN users several times.

To take your example, you cannot know what -Werror does on all compilers
(past, present or future) where it is supported (and -W flags do do
different things on different compilers).  On current gcc it does

-Werror
Make all warnings into errors.

and so its effect depends on what other flags are used (people typically use
-Wall, and most new versions of both gcc and clang add more warnings to
-Wall -- I read this week exactly such a discussion about the interaction of
-Werror with -Wtautological-constant-compare as part of -Wall in clang
trunk).


Is there a way to get R CMD check to not raise warnings in cases like
this? I know I could modify the C library's configure.ac (which is
used to generate the configure script) but I'd prefer to leave the
library's code untouched if possible.


You don't need to (and most likely should not) use the C[XX]FLAGS it
generates ... just use the flags which R passes to the package to use.


It turns out that there isn't even a risk of these compiler flags
being used -- I learned from of my colleagues that the troublesome
compiler flags, like -Werror, never actually appear in the Makefile.
The configure script prints out those compiler flags out when it
checks for them, but in the end it creates a Makefile with the CFLAGS
inherited from R. So there's no chance that the library would be
compiled using those flags (unless R passed them along).

His suggested workaround is to silence the output of the configure
script. That also hides some useful information, but it does work for
this issue.

-Winston

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



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

Re: [Rd] R CMD check warning about compiler warning flags

[Winston Chang]

>> On recent builds of R-devel, R CMD check gives a WARNING when some
>> compiler warning flags are detected, such as -Werror, because they are
>> non-portable. This appears to have been added in this commit:
>>https://github.com/wch/r-source/commit/2e80059
>
> That is not the canonical R sources.

Yes, that is obvious. The main page for that repository says it is a
mirror of the R sources, right at the top. I know that because I put
the message there, and because I see it every time I visit the
repository. If you have a good way of pointing people to the changes
made in a commit with the canonical R sources, please let us know. I
and many others would be happy to use it.

> And your description seems wrong:
> there is now an _optional_ check controlled by an environment variable,
> primarily for CRAN checks.

The check is "optional", but not for packages submitted to CRAN.


>> I'm working on a package where these compiler warning flags are
>> present in a Makefile generated by a configure script -- that is, the
>> configure script detects whether the compiler supports these flags,
>> and if so, puts them in the Makefile. (The configure script is for a
>> third-party C library which is in a subdirectory of src/.)
>>
>> Because the flags are added only if the system supports them, there
>> shouldn't be any worries about portability in practice.
>
>
> Please read the explanation in the manual: there are serious concerns about
> such flags which have bitten CRAN users several times.
>
> To take your example, you cannot know what -Werror does on all compilers
> (past, present or future) where it is supported (and -W flags do do
> different things on different compilers).  On current gcc it does
>
>-Werror
>Make all warnings into errors.
>
> and so its effect depends on what other flags are used (people typically use
> -Wall, and most new versions of both gcc and clang add more warnings to
> -Wall -- I read this week exactly such a discussion about the interaction of
> -Werror with -Wtautological-constant-compare as part of -Wall in clang
> trunk).
>
>> Is there a way to get R CMD check to not raise warnings in cases like
>> this? I know I could modify the C library's configure.ac (which is
>> used to generate the configure script) but I'd prefer to leave the
>> library's code untouched if possible.
>
> You don't need to (and most likely should not) use the C[XX]FLAGS it
> generates ... just use the flags which R passes to the package to use.

It turns out that there isn't even a risk of these compiler flags
being used -- I learned from of my colleagues that the troublesome
compiler flags, like -Werror, never actually appear in the Makefile.
The configure script prints out those compiler flags out when it
checks for them, but in the end it creates a Makefile with the CFLAGS
inherited from R. So there's no chance that the library would be
compiled using those flags (unless R passed them along).

His suggested workaround is to silence the output of the configure
script. That also hides some useful information, but it does work for
this issue.

-Winston

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

Re: [Rd] Wish List: base::source() + Add Execution Time Argument

[Jim Hester]

R does provide the addTaskCallback / taskCallbackManager to run a
callback function after every top level command. However there is not
an equivalent interface that would be run _before_ each command, which
would make it possible to time of top level calls and provide other
execution measurements.

On Thu, Dec 21, 2017 at 11:31 AM, William Dunlap via R-devel
 wrote:
> Is source() the right place for this?  It may be, but we've had customers
> who would like
> this sort of thing done for commands entered by hand.  And there are those
> who want
> a description of any "non-triivial" objects created in .GlobalEnv by each
> expression, ...
> Do they need a way to wrap each expression evaluated in envir=.GlobalEnv
> with a
> function of their choice, one that would print times, datasets created,
> etc.?
>
> Bill Dunlap
> TIBCO Software
> wdunlap tibco.com
>
> On Thu, Dec 21, 2017 at 3:46 AM, Juan Telleria  wrote:
>
>> Dear R Developers,
>>
>> Adding to source() base function a Timer which indicates the execution time
>> of the source code would be a very well welcome feature, and in my opinion
>> not difficult to implement as an additional funtion argument.
>>
>> The source(timing = TRUE) function shall execute internally the following
>> code for each statement:
>>
>> old <- Sys.time() # get start time at the beginning of source()
>> # source code
>> # print elapsed time
>> new <- Sys.time() - old # calculate difference
>> print(new) # print in nice format
>>
>> Thank you.
>>
>> Kind regards,
>>
>> Juan Telleria
>>
>> [[alternative HTML version deleted]]
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

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

Re: [R-pkg-devel] File name error

[Henrik Bengtsson]

Uwe/Kurt, is this controlled by R itself or by the host system?  I
suspect one of my R.filesets tests(*) fails (since a few days) because
of this, but it might actually be a false positive.  I fail to
reproduce it on Ubuntu 16.04 with:

* using R Under development (unstable) (2017-12-20 r73933)
* using platform: x86_64-pc-linux-gnu (64-bit)

My test tries to verify that it can write to tempdir() using its
*relative* path (if such is possible) - a test that effectively does:

> abs <- tempfile()
> setwd(dirname(abs))
> getwd()
[1] "/tmp/Rtmpa9riPQ"
> rel <- file.path("..", "..", abs)
> rel <- gsub("//", "/", rel, fixed = TRUE)
> rel
[1] "../../tmp/Rtmpa9riPQ/file3251441e380d
> cat("hello", file = res)

and fails in that last write on 'r-devel-linux-x86_64-debian-gcc'.  It
could, of course, be a bug in my code that is now being revealed, but
these tests been in place for many years, possibly more than a decade.

(*) https://cran.r-project.org/web/checks/check_results_R.filesets.html

Thxs,

Henrik

On Thu, Dec 21, 2017 at 2:21 AM, Uwe Ligges
 wrote:
> This is a new check:
>
> You must not write into the user's filespace without explicit agreement by
> the user (by specifying path/name).
>
> Note that some users won't even have permissions to write into the package's
> installation directory if that is set up site wide by an admin, for example.
>
> So please use tempdir() in the examples.
>
> Best,
> Uwe Ligges
>
>
>
>
>
> On 21.12.2017 09:21, Blume Christine wrote:
>>
>> Hi Cathy,
>>
>> I also had troubles with debian (Fedora only gave warnings) and no
>> problems with other systems. Mine was related to me writing a file (or
>> rather trying to write) in a working directory other than tempdir (can be
>> retrieved by tempdir()). I now write it to tempdir and then set the old
>> working directory again at the end of the example. Perhaps that is somehow
>> helpful for your case too?
>>
>> I can highly recommend to test your tar.gz file with the check() function
>> of the rhub package. You can for example run check("pathtoyourpackage",
>> platform = "debian-gcc-devel") or
>> check_for_cran("pathtoyourpackage", platform = "debian-gcc-devel"), i.e.
>> test your package on debian without troubles.
>>
>> Best,
>> Christine
>>
>>
>> -Ursprüngliche Nachricht-
>> Von: R-package-devel [mailto:r-package-devel-boun...@r-project.org] Im
>> Auftrag von Cathy Lee Gierke
>> Gesendet: Donnerstag, 21. Dezember 2017 07:15
>> An: R Package Development
>> Betreff: [R-pkg-devel] File name error
>>
>> I am getting the following error from the auto-checks when trying to
>> submit a package to CRAN:
>> r-devel-linux-x86_64-debian-gcc
>>
>> 
>> 3.0.0.2 3.63 56.71 60.34 ERROR
>>
>> 
>>
>> Error in pdf(file = fileName4, width = 8, height = 10) :
>>cannot open file
>>
>> '/home/hornik/tmp/R.check/r-devel-gcc/Work/build/Packages/CATkit/extdata/activity-stress-c57-2-part.txt--20Dec2017--03-51-46CAToutput.pdf'
>>
>> Since this works for ALL other flavors, I am assuming it may be some file
>> name restrictions unique to debian-gcc???  I can't think what else would
>> cause it to fail only in the OS.
>>
>> debian doesn't like "--"?
>>
>> Cathy Lee Gierke
>>
>>
>> *“Darkness cannot drive out darkness: only light can do that. Hate cannot
>> drive out hate: only love can do that.” * *“The arc of the moral universe is
>> long, but it bends towards justice.”* *“Nothing in the world is more
>> dangerous than sincere ignorance and conscientious stupidity.” *
>> *“Never forget that everything Hitler did in Germany was legal.”   *
>> *“Forgiveness is not an occasional act, it is a constant attitude.” *
>> *“Injustice anywhere is a threat to justice everywhere.”  *
>>
>> ― Martin Luther King Jr.
>>
>> 
>>
>> [[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-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: [Rd] Wish List: base::source() + Add Execution Time Argument

[William Dunlap via R-devel]

Is source() the right place for this?  It may be, but we've had customers
who would like
this sort of thing done for commands entered by hand.  And there are those
who want
a description of any "non-triivial" objects created in .GlobalEnv by each
expression, ...
Do they need a way to wrap each expression evaluated in envir=.GlobalEnv
with a
function of their choice, one that would print times, datasets created,
etc.?

Bill Dunlap
TIBCO Software
wdunlap tibco.com

On Thu, Dec 21, 2017 at 3:46 AM, Juan Telleria  wrote:

> Dear R Developers,
>
> Adding to source() base function a Timer which indicates the execution time
> of the source code would be a very well welcome feature, and in my opinion
> not difficult to implement as an additional funtion argument.
>
> The source(timing = TRUE) function shall execute internally the following
> code for each statement:
>
> old <- Sys.time() # get start time at the beginning of source()
> # source code
> # print elapsed time
> new <- Sys.time() - old # calculate difference
> print(new) # print in nice format
>
> Thank you.
>
> Kind regards,
>
> Juan Telleria
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

[[alternative HTML version deleted]]

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

Re: [Rd] Wish List: base::source() + Add Execution Time Argument

[Juan Telleria]

I did not know "progress" package existed, thank you Iñaki.

However, something like that would be nice to have by default in source(),
just something to add to R's "wish list", so that everybody can benefit
from it without extra-packages, as most of us I suppose we will spend all
day simply doing Ctrl + Run :)

Thank you,
Juan

2017-12-21 15:20 GMT+01:00 Iñaki Úcar :

> 2017-12-21 15:05 GMT+01:00 Juan Telleria :
> > But by statement in the source file, I mean, for knowing during the
> > execution how much time is taking, without having to wait till the end.
>
> What's the ultimate purpose? Are you looking for a profiler (there are
> some of them on CRAN) or some kind of progress bar (something like the
> 'progress' package would be useful)?
>
> Iñaki
>

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] starting a build... but no result...

[Shepherd, Lori]

My apologizes. The single package builder machine needed updates which negated 
the build.  I will kick off a new build and you should have a report shortly.


Lori Shepherd

Bioconductor Core Team

Roswell Park Cancer Institute

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Bioc-devel  on behalf of Paul Brennan 

Sent: Thursday, December 21, 2017 9:46:58 AM
To: bioc-devel@r-project.org
Subject: [Bioc-devel] starting a build... but no result...

Hi,
 I did a version bump and got an email saying starting a build
https://github.com/Bioconductor/Contributions/issues/541
 However, a day later no result...
 Have I done something stupid?
 Sorry if this is a noobie question.
 Thanks,
Paul

[[alternative HTML version deleted]]

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


This email message may contain legally privileged and/or confidential 
information.  If you are not the intended recipient(s), or the employee or 
agent responsible for the delivery of this message to the intended 
recipient(s), you are hereby notified that any disclosure, copying, 
distribution, or use of this email message is prohibited.  If you have received 
this message in error, please notify the sender immediately by e-mail and 
delete this email message from your computer. Thank you.
[[alternative HTML version deleted]]

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

[Bioc-devel] starting a build... but no result...

[Paul Brennan]

Hi,
 I did a version bump and got an email saying starting a build
https://github.com/Bioconductor/Contributions/issues/541
 However, a day later no result...
 Have I done something stupid?
 Sorry if this is a noobie question.
 Thanks,
Paul

[[alternative HTML version deleted]]

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

[Bioc-devel] ensembl 91 gtfs and fasta twobits have been added to AnnotationHub

[Shepherd, Lori]

Hello all,

The ensembl 91 gtf (converted to GRanges on the fly) and fasta (twobit files)
been added to AnnotationHub and are currently available in Bioc 3.6 (release)
and Bioc3.7 (development)


Bioconductor version 3.6 (BiocInstaller 1.28.0), ?biocLite for help
> library(AnnotationHub)
> hub = AnnotationHub()
snapshotDate(): 2017-10-27
> length(query(hub, c("ensembl", "gtf", "release-91")))
[1] 279

> length(query(hub, c("fasta", "release-91", "twobit")))
[1] 462



Bioconductor version 3.7 (BiocInstaller 1.29.2), ?biocLite for help
> library(AnnotationHub)
> hub = AnnotationHub()
snapshotDate(): 2017-12-20
> length(query(hub, c("ensembl", "gtf", "release-91")))
[1] 279

> length(query(hub, c("fasta", "release-91", "twobit")))
[1] 462


Thank you




Lori Shepherd

Bioconductor Core Team

Roswell Park Cancer Institute

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


This email message may contain legally privileged and/or confidential 
information.  If you are not the intended recipient(s), or the employee or 
agent responsible for the delivery of this message to the intended 
recipient(s), you are hereby notified that any disclosure, copying, 
distribution, or use of this email message is prohibited.  If you have received 
this message in error, please notify the sender immediately by e-mail and 
delete this email message from your computer. Thank you.
[[alternative HTML version deleted]]

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

Re: [Rd] Wish List: base::source() + Add Execution Time Argument

[Iñaki Úcar]

2017-12-21 15:05 GMT+01:00 Juan Telleria :
> But by statement in the source file, I mean, for knowing during the
> execution how much time is taking, without having to wait till the end.

What's the ultimate purpose? Are you looking for a profiler (there are
some of them on CRAN) or some kind of progress bar (something like the
'progress' package would be useful)?

Iñaki

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

Re: [Rd] Wish List: base::source() + Add Execution Time Argument

[Juan Telleria]

But by statement in the source file, I mean, for knowing during the
execution how much time is taking, without having to wait till the end.

2017-12-21 13:06 GMT+01:00 Iñaki Úcar :

> 2017-12-21 12:46 GMT+01:00 Juan Telleria :
> > Dear R Developers,
> >
> > Adding to source() base function a Timer which indicates the execution
> time
> > of the source code would be a very well welcome feature, and in my
> opinion
> > not difficult to implement as an additional funtion argument.
> >
> > The source(timing = TRUE) function shall execute internally the following
> > code for each statement:
> >
> > old <- Sys.time() # get start time at the beginning of source()
> > # source code
> > # print elapsed time
> > new <- Sys.time() - old # calculate difference
> > print(new) # print in nice format
>
> system.time(source(...)) does what you want.
>
> Iñaki
>

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Incrimental writing to HDF5 / DelayedMatrix

[Francesco Napolitano]

That seems to solve my problem, I will try this way, thak you very much.
Francesco

On Thu, Dec 21, 2017 at 1:16 PM, Martin Morgan
 wrote:
> On 12/21/2017 06:22 AM, Francesco Napolitano wrote:
>>
>> Hi,
>>
>> I need to deal with very large matrices and I was thinking of using
>> HDF5-based data models. However, from the documentation and examples
>> that I have been looking at, I'm not quite sure how to do this.
>>
>> My use case is as follows.
>> I want to build a very large matrix one column at a time, and I need
>> to write columns directly to disk since I would otherwise run out of
>> memory. I need a format that, afterwards, will allow me to extract
>> subsets of rows or columns and rank them. The subsets will be small
>> enough to be loaded in memory. Can I achieve this with current HDF5
>> support in R?
>
>
> this is basically straight-forward in rhdf5. The idea is to create a dataset
> of the size to contain your total data
>
>   library(rhdf5)
>   fl <- tempfile()
>   h5createFile(fl)
>
>   nrow <- 1
>   ncol <- 100
>   h5createDataset(fl, "big", c(nrow, ncol), showWarnings = FALSE)
>
> then to fill it in chunks by specifying which start row / column you'd like
> to write to and the 'count' of the number data points in each direction
> you'd like to write to
>
>   chunk_ncol <- ncol / 10
>   j <- 1   # which column to start writing?
>
>   while (j < ncol) {
> m <- matrix(seq(1, length.out = nrow * chunk_ncol), nrow)
> h5write(m, fl, "big", start = c(1, j), count = c(nrow, chunk_ncol))
> j <- j + chunk_ncol
>   }
>
> You can read arbitrary  'slabs'
>
>   h5read(fl, "big", start = c(1, 1), count = c(5, 5))
>   h5read(fl, "big", start = c(1, 9), count = c(5, 2))
>
> Probably you don't want to write 1 column at a time, but as many columns as
> comfortably fit into memory. This minimizes the number of R function calls
> needed to write / read the data.
>
> The HDF5Array package provides an easy abstraction for reading (probably
> writing is possible too, but it might be easier to understand the building
> blocks first).
>
>> library(HDF5Array)
>> hdf <- HDF5Array(fl, "big")
>> hdf
> HDF5Matrix object of 1 x 100 doubles:
>[,1]   [,2]   [,3] ...  [,99] [,100]
> [1,]  1  10001  20001   .  80001  90001
> [2,]  2  10002  20002   .  80002  90002
> [3,]  3  10003  20003   .  80003  90003
> [4,]  4  10004  20004   .  80004  90004
> [5,]  5  10005  20005   .  80005  90005
>  ...  .  .  .   .  .  .
>  [9996,]   9996  19996  29996   .  89996  6
>  [9997,]   9997  19997  29997   .  89997  7
>  [9998,]   9998  19998  29998   .  89998  8
>  [,]     1  2   .  8  9
> [1,]  1  2  3   .  9 10
>> hdf[1:5, 1:5]
> DelayedMatrix object of 5 x 5 doubles:
>   [,1]  [,2]  [,3]  [,4]  [,5]
> [1,] 1 10001 20001 30001 40001
> [2,] 2 10002 20002 30002 40002
> [3,] 3 10003 20003 30003 40003
> [4,] 4 10004 20004 30004 40004
> [5,] 5 10005 20005 30005 40005
>> as.matrix(hdf[1:5, 1:5])
>  [,1]  [,2]  [,3]  [,4]  [,5]
> [1,]1 10001 20001 30001 40001
> [2,]2 10002 20002 30002 40002
> [3,]3 10003 20003 30003 40003
> [4,]4 10004 20004 30004 40004
> [5,]5 10005 20005 30005 40005
>> rowSums(hdf[1:5, 1:5])
> [1] 15 100010 100015 100020 100025
>
> Martin
>
>>
>> Any help greatly appreciated.
>>
>> than you,
>> Francesco
>>
>> ___
>> Bioc-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>
>
>
> This email message may contain legally privileged and/or confidential
> information.  If you are not the intended recipient(s), or the employee or
> agent responsible for the delivery of this message to the intended
> recipient(s), you are hereby notified that any disclosure, copying,
> distribution, or use of this email message is prohibited.  If you have
> received this message in error, please notify the sender immediately by
> e-mail and delete this email message from your computer. Thank you.

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

Re: [Bioc-devel] Incrimental writing to HDF5 / DelayedMatrix

[Martin Morgan]

On 12/21/2017 06:22 AM, Francesco Napolitano wrote:

Hi,

I need to deal with very large matrices and I was thinking of using
HDF5-based data models. However, from the documentation and examples
that I have been looking at, I'm not quite sure how to do this.

My use case is as follows.
I want to build a very large matrix one column at a time, and I need
to write columns directly to disk since I would otherwise run out of
memory. I need a format that, afterwards, will allow me to extract
subsets of rows or columns and rank them. The subsets will be small
enough to be loaded in memory. Can I achieve this with current HDF5
support in R?


this is basically straight-forward in rhdf5. The idea is to create a 
dataset of the size to contain your total data


  library(rhdf5)
  fl <- tempfile()
  h5createFile(fl)

  nrow <- 1
  ncol <- 100
  h5createDataset(fl, "big", c(nrow, ncol), showWarnings = FALSE)

then to fill it in chunks by specifying which start row / column you'd 
like to write to and the 'count' of the number data points in each 
direction you'd like to write to


  chunk_ncol <- ncol / 10
  j <- 1   # which column to start writing?

  while (j < ncol) {
m <- matrix(seq(1, length.out = nrow * chunk_ncol), nrow)
h5write(m, fl, "big", start = c(1, j), count = c(nrow, chunk_ncol))
j <- j + chunk_ncol
  }

You can read arbitrary  'slabs'

  h5read(fl, "big", start = c(1, 1), count = c(5, 5))
  h5read(fl, "big", start = c(1, 9), count = c(5, 2))

Probably you don't want to write 1 column at a time, but as many columns 
as comfortably fit into memory. This minimizes the number of R function 
calls needed to write / read the data.


The HDF5Array package provides an easy abstraction for reading (probably 
writing is possible too, but it might be easier to understand the 
building blocks first).


> library(HDF5Array)
> hdf <- HDF5Array(fl, "big")
> hdf
HDF5Matrix object of 1 x 100 doubles:
   [,1]   [,2]   [,3] ...  [,99] [,100]
[1,]  1  10001  20001   .  80001  90001
[2,]  2  10002  20002   .  80002  90002
[3,]  3  10003  20003   .  80003  90003
[4,]  4  10004  20004   .  80004  90004
[5,]  5  10005  20005   .  80005  90005
 ...  .  .  .   .  .  .
 [9996,]   9996  19996  29996   .  89996  6
 [9997,]   9997  19997  29997   .  89997  7
 [9998,]   9998  19998  29998   .  89998  8
 [,]     1  2   .  8  9
[1,]  1  2  3   .  9 10
> hdf[1:5, 1:5]
DelayedMatrix object of 5 x 5 doubles:
  [,1]  [,2]  [,3]  [,4]  [,5]
[1,] 1 10001 20001 30001 40001
[2,] 2 10002 20002 30002 40002
[3,] 3 10003 20003 30003 40003
[4,] 4 10004 20004 30004 40004
[5,] 5 10005 20005 30005 40005
> as.matrix(hdf[1:5, 1:5])
 [,1]  [,2]  [,3]  [,4]  [,5]
[1,]1 10001 20001 30001 40001
[2,]2 10002 20002 30002 40002
[3,]3 10003 20003 30003 40003
[4,]4 10004 20004 30004 40004
[5,]5 10005 20005 30005 40005
> rowSums(hdf[1:5, 1:5])
[1] 15 100010 100015 100020 100025

Martin



Any help greatly appreciated.

than you,
Francesco

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




This email message may contain legally privileged and/or...{{dropped:2}}

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

Re: [Bioc-devel] Incrimental writing to HDF5 / DelayedMatrix

[Paul Theodor Pyl]

Hi Francesco,

this is certainly achievable with currently available HDF5 support in 
R/Bioconductor. For example the rhdf5 package gives you access to this 
functionality (https://bioconductor.org/packages/release/bioc/html/rhdf5.html 
(https://bioconductor.org/packages/release/bioc/html/rhdf5.html)).

rhdf5 is relatively 'low-level', in the sense that it is really close to the 
HDF5 library it exposes to R (i.e. you get h5read an h5write functions). For 
what you are describing I typically use a small wrapper to make my life a bit 
easier, I have something like that on github here: 
https://github.com/PaulPyl/h5array (https://github.com/PaulPyl/h5array)

Please note that this is not an official Bioconductor package so it doesn't 
fulfill the strict standards of documentation etc., since it is just a small 
wrapper to give you an array-like object that writes/reads its data from disk 
though, it should be fairly straightforward to use.

Best,
Paul

On Thu, Dec 21, 2017 at 12:22, Francesco Napolitano  wrote:
Hi,

I need to deal with very large matrices and I was thinking of using
HDF5-based data models. However, from the documentation and examples
that I have been looking at, I'm not quite sure how to do this.

My use case is as follows.
I want to build a very large matrix one column at a time, and I need
to write columns directly to disk since I would otherwise run out of
memory. I need a format that, afterwards, will allow me to extract
subsets of rows or columns and rank them. The subsets will be small
enough to be loaded in memory. Can I achieve this with current HDF5
support in R?

Any help greatly appreciated.

than you,
Francesco

___
Bioc-devel@r-project.org (mailto:Bioc-devel@r-project.org) mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel 
(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

Re: [Rd] Wish List: base::source() + Add Execution Time Argument

[Iñaki Úcar]

2017-12-21 12:46 GMT+01:00 Juan Telleria :
> Dear R Developers,
>
> Adding to source() base function a Timer which indicates the execution time
> of the source code would be a very well welcome feature, and in my opinion
> not difficult to implement as an additional funtion argument.
>
> The source(timing = TRUE) function shall execute internally the following
> code for each statement:
>
> old <- Sys.time() # get start time at the beginning of source()
> # source code
> # print elapsed time
> new <- Sys.time() - old # calculate difference
> print(new) # print in nice format

system.time(source(...)) does what you want.

Iñaki

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

Re: [R-pkg-devel] File name error

[Dirk Eddelbuettel]

Cristine,

On 21 December 2017 at 08:21, Blume Christine wrote:
| I also had troubles with debian (Fedora only gave warnings)

May I ask you to be a little more careful in your attribution?   Yes, it is
too that the instance labeleb 'r-devel-debian' gave you an error.  But that
was not because of Debian, but because _that r-devel instance_ carried a new
test.

So please don't leave sentences hanging (as you now have in several emails)
"failed on Debian" implying a particular flavour (as shipped by Debian)
failed.  It didn't. A [very recent] build of r-devel, instrumented with a new
test, failed for you. It happens to be running on a Debian platform. So
please refer to the failing test platform by its name. Preferably with the
compiler added because there are two each for Debian and Fedora. See eg
https://cloud.r-project.org/web/checks/check_results_digest.html

Thanks,  Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [Rd] R CMD check warning about compiler warning flags

[Duncan Murdoch]

On 20/12/2017 6:52 PM, Duncan Murdoch wrote:

On 20/12/2017 5:48 PM, Hadley Wickham wrote:

On Wed, Dec 20, 2017 at 4:26 PM, Prof Brian Ripley
 wrote:

On 20/12/2017 17:42, Winston Chang wrote:


On recent builds of R-devel, R CMD check gives a WARNING when some
compiler warning flags are detected, such as -Werror, because they are
non-portable. This appears to have been added in this commit:
 https://github.com/wch/r-source/commit/2e80059



That is not the canonical R sources.  And your description seems wrong:
there is now an _optional_ check controlled by an environment variable,
primarily for CRAN checks.


Are the canonical R sources made available in such a way that one can
link to them?


Yes, the sources are available.  To link to revision 73909 of R on the
trunk branch (which I think is the one referred to above), use

https://svn.r-project.org/R/trunk/?r=73909

I'm not sure if there's an easy way to see the diff between that and
73908 (which is what the github link showed).  


After checking a bit online, it appears there are projects WebSVN, USVN 
and ViewVC that should do this. I don't know if anyone has set up views 
of the R repository with any of those.  I've never used them, I just use 
local tools.  In the past I used Windows-only TortoiseSVN (and it is 
still one of the most attractive features of Windows); now I use RStudio 
or command line svn.  As you know, RStudio's interface is somewhat 
limited, and as far as I know it can't display features of remote 
repositories.


I also don't know if

there's a way to show the diff between commit N and N-1 in github if I
only know N.


I still don't know this.

Duncan Murdoch

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

[Rd] Wish List: base::source() + Add Execution Time Argument

[Juan Telleria]

Dear R Developers,

Adding to source() base function a Timer which indicates the execution time
of the source code would be a very well welcome feature, and in my opinion
not difficult to implement as an additional funtion argument.

The source(timing = TRUE) function shall execute internally the following
code for each statement:

old <- Sys.time() # get start time at the beginning of source()
# source code
# print elapsed time
new <- Sys.time() - old # calculate difference
print(new) # print in nice format

Thank you.

Kind regards,

Juan Telleria

[[alternative HTML version deleted]]

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

Re: [Rd] Building R from source with the PGI compiler

[Prof Brian Ripley]

On 21/12/2017 01:03, Erin Hodgess wrote:

Hello

I would like to build R from source and use the PGI compiler, rather than
the GCC compiler.


On what platform?  AFAIK we have only ever had reports on Linux.


I saw the instructions for the Intel compiler in the R Installation Manual,
but I didn't see the PGI.  I tried a few times without instructions, but
without success.

Any suggestions would be most welcome.  Also, I hope this is the right
group for the question.


It is.  Earlier versions of the  manual did contain info on using the 
PG(I) Linux compilers but as we had no reports for a long time, the 
probably-stale info was removed.  It looks like the info was added in 
late 2005, so you could try grabbing R sources from, say, 2007.




Sincerely,
Erin



--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

[Rd] Building R from source with the PGI compiler

[Erin Hodgess]

Hello

I would like to build R from source and use the PGI compiler, rather than
the GCC compiler.

I saw the instructions for the Intel compiler in the R Installation Manual,
but I didn't see the PGI.  I tried a few times without instructions, but
without success.

Any suggestions would be most welcome.  Also, I hope this is the right
group for the question.

Sincerely,
Erin



-- 
Erin Hodgess
Associate Professor
Department of Mathematical and Statistics
University of Houston - Downtown
mailto: erinm.hodg...@gmail.com

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] File name error

[Uwe Ligges]

This is a new check:

You must not write into the user's filespace without explicit agreement 
by the user (by specifying path/name).


Note that some users won't even have permissions to write into the 
package's installation directory if that is set up site wide by an 
admin, for example.


So please use tempdir() in the examples.

Best,
Uwe Ligges




On 21.12.2017 09:21, Blume Christine wrote:

Hi Cathy,

I also had troubles with debian (Fedora only gave warnings) and no problems 
with other systems. Mine was related to me writing a file (or rather trying to 
write) in a working directory other than tempdir (can be retrieved by 
tempdir()). I now write it to tempdir and then set the old working directory 
again at the end of the example. Perhaps that is somehow helpful for your case 
too?

I can highly recommend to test your tar.gz file with the check() function of the rhub package. You 
can for example run check("pathtoyourpackage", platform = "debian-gcc-devel") or
check_for_cran("pathtoyourpackage", platform = "debian-gcc-devel"), i.e. test 
your package on debian without troubles.

Best,
Christine


-Ursprüngliche Nachricht-
Von: R-package-devel [mailto:r-package-devel-boun...@r-project.org] Im Auftrag 
von Cathy Lee Gierke
Gesendet: Donnerstag, 21. Dezember 2017 07:15
An: R Package Development
Betreff: [R-pkg-devel] File name error

I am getting the following error from the auto-checks when trying to submit a 
package to CRAN:
r-devel-linux-x86_64-debian-gcc

3.0.0.2 3.63 56.71 60.34 ERROR


Error in pdf(file = fileName4, width = 8, height = 10) :
   cannot open file
'/home/hornik/tmp/R.check/r-devel-gcc/Work/build/Packages/CATkit/extdata/activity-stress-c57-2-part.txt--20Dec2017--03-51-46CAToutput.pdf'

Since this works for ALL other flavors, I am assuming it may be some file name 
restrictions unique to debian-gcc???  I can't think what else would cause it to 
fail only in the OS.

debian doesn't like "--"?

Cathy Lee Gierke


*“Darkness cannot drive out darkness: only light can do that. Hate cannot drive 
out hate: only love can do that.” * *“The arc of the moral universe is long, 
but it bends towards justice.”* *“Nothing in the world is more dangerous than 
sincere ignorance and conscientious stupidity.” *
*“Never forget that everything Hitler did in Germany was legal.”   *
*“Forgiveness is not an occasional act, it is a constant attitude.” * 
*“Injustice anywhere is a threat to justice everywhere.”  *

― Martin Luther King Jr.



[[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-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] File name error

[Blume Christine]

Hi Cathy,

I also had troubles with debian (Fedora only gave warnings) and no problems 
with other systems. Mine was related to me writing a file (or rather trying to 
write) in a working directory other than tempdir (can be retrieved by 
tempdir()). I now write it to tempdir and then set the old working directory 
again at the end of the example. Perhaps that is somehow helpful for your case 
too?

I can highly recommend to test your tar.gz file with the check() function of 
the rhub package. You can for example run check("pathtoyourpackage", platform = 
"debian-gcc-devel") or 
check_for_cran("pathtoyourpackage", platform = "debian-gcc-devel"), i.e. test 
your package on debian without troubles.

Best,
Christine


-Ursprüngliche Nachricht-
Von: R-package-devel [mailto:r-package-devel-boun...@r-project.org] Im Auftrag 
von Cathy Lee Gierke
Gesendet: Donnerstag, 21. Dezember 2017 07:15
An: R Package Development
Betreff: [R-pkg-devel] File name error

I am getting the following error from the auto-checks when trying to submit a 
package to CRAN:
r-devel-linux-x86_64-debian-gcc

3.0.0.2 3.63 56.71 60.34 ERROR


Error in pdf(file = fileName4, width = 8, height = 10) :
  cannot open file
'/home/hornik/tmp/R.check/r-devel-gcc/Work/build/Packages/CATkit/extdata/activity-stress-c57-2-part.txt--20Dec2017--03-51-46CAToutput.pdf'

Since this works for ALL other flavors, I am assuming it may be some file name 
restrictions unique to debian-gcc???  I can't think what else would cause it to 
fail only in the OS.

debian doesn't like "--"?

Cathy Lee Gierke


*“Darkness cannot drive out darkness: only light can do that. Hate cannot drive 
out hate: only love can do that.” * *“The arc of the moral universe is long, 
but it bends towards justice.”* *“Nothing in the world is more dangerous than 
sincere ignorance and conscientious stupidity.” *
*“Never forget that everything Hitler did in Germany was legal.”   *
*“Forgiveness is not an occasional act, it is a constant attitude.” * 
*“Injustice anywhere is a threat to justice everywhere.”  *

― Martin Luther King Jr.



[[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