Re: [Bioc-devel] svn repository for data experiment packages now having branches too
Dear Hervé, just to make sure: is the the same x.y.z versioning scheme as for software packages already implemented for experiment data packages, i.e. will there be an automatic version bump for experiment packages with the upcoming BioC release? Cheers, Andrzej On Tue, Feb 11, 2014 at 7:18 AM, Hervé Pagès hpa...@fhcrc.org wrote: Hi Bernd and other developers, On 02/07/2014 04:57 AM, Bernd Fischer wrote: Dear Herve! Please start using the same x.y.z versioning scheme as for software packages with the new release for data experiment packages, with even y for release and odd y for devel. Thanks for your feedback! Can anyone think of a reason why we should not do that? If nobody objects then we'll start using the same x.y.z versioning scheme as for software for the next BioC release (in April). Thanks, H. I just copied code from devel to the release version of my package and asked myself which version number to use. Automatic version bumping -- Bernd Fischer EMBL Heidelberg Meyerhofstraße 1 69117 Heidelberg Tel: +49 [0] 6221 387-8131 E-Mail: bernd.fisc...@embl.de mailto:bernd.fisc...@embl.de Homepage: http://www-huber.embl.de/users/befische/ On 22.01.2014, at 23:30, Hervé Pagès hpa...@fhcrc.org mailto:hpa...@fhcrc.org wrote: Hi developers, Taking advantage of this particularly calm week on Bioc-devel, I'd like to formally announce that we're now using branches in the svn repo for data experiment packages. The trunk/branches layout is similar to what we already do in the software repo. That is: - URL for packages in trunk: https://hedgehog.fhcrc.org/bioc-data/trunk/experiment/pkgs/ - URLs for packages in the branches: https://hedgehog.fhcrc.org/bioc-data/branches/RELEASE_2_13/experiment/pkgs https://hedgehog.fhcrc.org/bioc-data/branches/RELEASE_2_14/experiment/pkgs https://hedgehog.fhcrc.org/bioc-data/branches/RELEASE_2_15/experiment/pkgs Only the RELEASE_2_13 branch exists right now. This is where the packages that are in the current release version of BioC (2.13) are living. Like for software packages, a new branch will be created for each new BioC release. For example the RELEASE_2_14 branch will be created in April one day or so before the BioC 2.14 release, the RELEASE_2_15 branch in October, etc... More precisely, at any given time, you only have access to 2 versions of your data experiment package: the release and devel versions. The release version of your package is always in the latest branch (RELEASE_2_13 at the moment) and accessible at: https://hedgehog.fhcrc.org/bioc-data/branches/RELEASE_2_13/experiment/pkgs/PKGNAME Only bug fixes and documentation improvements should go here. The devel version of your package is always available at: https://hedgehog.fhcrc.org/bioc-data/trunk/experiment/pkgs/PKGNAME One important difference with the svn software repository still remains though. For data experiment, the recommended way to checkout a package is: 1. Checkout a shallow working copy of the pkgs/ folder: svn co https://hedgehog.fhcrc.org/bioc-data/trunk/experiment/pkgs --depth=files Use the URL to the current branch if you need to checkout a release package. 2. cd to the pkg/ folder 3. Fetch the working copy of a particular package: svn up PKGNAME (You can list all the folders in pkgs/ with 'svn ls') IMPORTANT: This doesn't fetch the data. But most of the time you don't need them e.g. if you only need to make a change to a man page, the vignette, the DESCRIPTION file, the NAMESPACE etc... you can do so and commit. But of course, if you didn't fetch the data, it's very likely that you won't be able to test your changes with 'R CMD check'. 4. If you need to fetch the data: (from the pkgs/ folder) ./add_data.py PKGNAME This will populate the PKGNAME folder with the data. Note that you need to be in a data folder in order to commit any change to the data. Any commit you do from the top level folder of the package won't include any change you could have made to the data. We're also wondering whether we should start to use the same x.y.z versioning scheme as for software packages, that is, an even y in release, an odd y in devel, with y bump (and z reset to 0) at each new release. Feedback welcome. Please let me know if you have questions or concerns about this. Cheers, H. -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fhcrc.org Phone: (206) 667-5791 Fax:(206) 667-1319 ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred
Re: [Rd] CXX_STD and configure.ac in packages
Hi,
My advice would be to use SystemRequirements: C++11
As unordered_map is definitely a part of C++11, assuming this version of the
standard gives it to you. Your package may not compile on platforms where a
C++11 compiler is not available, but perhaps if this becomes a pattern, then
such compilers will start to be available, as in the current version of OSX and
recent enough versions of various linux distributions.
The subset of feature that the version of gcc gives you with Rtools might be
enough.
Alternatively, if you use Rcpp, you can use the RCPP_UNORDERED_MAP macro which
will expand to either unordered_map or tr1::unordered_map, all the condition
compiling is done in Rcpp.
Romain
Le 30 mars 2014 à 21:50, Martin Morgan mtmor...@fhcrc.org a écrit :
In C++ code for use in a R-3.1.0 package, my specific problem is that I would
like to use unordered_map if it is available, or tr1/unordered_map if
not, or map if all else fails.
I (think I) can accomplish this with configure.ac as
AC_INIT(DESCRIPTION)
CXX=`${R_HOME}/bin/R CMD config CXX`
CXXFLAGS=`${R_HOME}/bin/R CMD config CXXFLAGS`
AC_CONFIG_HEADERS([src/config.h])
AC_LANG(C++)
AC_CHECK_HEADERS([unordered_map tr1/unordered_map])
AC_OUTPUT
Use of configure.ac does not seem to be entirely consistent with section
1.2.4 of Writing R Extensions, where one is advised that to use C++(11? see
below) code one should
CXX_STD = CXX11
in Makevars(.win). My code does not require a compiler that supports the full
C++11 feature set. In addition, I do not understand the logic of setting a
variable that influences compiler flags in Makevars -- configure.ac will see
a compiler with inaccurate flags.
Is use of configure.ac orthogonal to setting CXX_STD=CXX11?
Some minor typos:
/R-3-1-branch$ svn diff
Index: doc/manual/R-exts.texi
===
--- doc/manual/R-exts.texi(revision 65339)
+++ doc/manual/R-exts.texi(working copy)
@@ -2250,7 +2250,7 @@
@subsection Using C++11 code
@R{} can be built without a C++ compiler although one is available
-(but not necessarily installed) or all known @R{} platforms.
+(but not necessarily installed) on all known @R{} platforms.
For full portability across platforms, all
that can be assumed is approximate support for the C++98 standard (the
widely used @command{g++} deviates considerably from the standard).
@@ -2272,7 +2272,7 @@
support a flag @option{-std=c++0x}, but the latter only provides partial
support for the C++11 standard.
-In order to use C++ code in a package, the package's @file{Makevars}
+In order to use C++11 code in a package, the package's @file{Makevars}
file (or @file{Makevars.win} on Windows) should include the line
@example
@@ -2329,7 +2329,7 @@
anything other than the GNU version of C++98 and GNU extensions (which
include TR1). The default compiler on Windows is GCC 4.6.x and supports
the @option{-std=c++0x} flag and some C++11 features (see
-@uref{http://gcc.gnu.org/gcc-4.6/cxx0x_status.html}. On these
+@uref{http://gcc.gnu.org/gcc-4.6/cxx0x_status.html}). On these
platforms, it is necessary to select a different compiler for C++11, as
described above, @emph{via} personal @file{Makevars} files. For
example, on OS X 10.7 or later one could select @command{clang++}.
--
Computational Biology / Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109
Location: Arnold Building M1 B861
Phone: (206) 667-2793
__
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] CXX_STD and configure.ac in packages
Hi Martin,
Thanks for the patch. I have applied it. I also added CXX1X and friends to the
list of approved variables for R CMD config.
So you can now query the existence of C++11 support with `R CMD config CXX1X`
(It is empty if C++11 support is not available)
and then take appropriate action in your configure script if, in Dirk's words,
you want to do the configure dance.
The philosophy underlying C++ support in R is that there are only two standards
- C++98 and C++11 - and that
you should write to one of those standards. Nobody should be writing new code
that uses TR1 extensions now: they are
superseded by the new standard.
The map and unordered_map classes are a corner case, as they offer the same
functionality but latter has much better
complexity guarantees, so it is tempting to use it when available. But from a
global perspective you should think of
C++98 and C++11 as two different languages.
Martyn
From: r-devel-boun...@r-project.org [r-devel-boun...@r-project.org] on behalf
of Romain Francois [rom...@r-enthusiasts.com]
Sent: 31 March 2014 08:22
To: Martin Morgan
Cc: R-devel
Subject: Re: [Rd] CXX_STD and configure.ac in packages
Hi,
My advice would be to use SystemRequirements: C++11
As unordered_map is definitely a part of C++11, assuming this version of the
standard gives it to you. Your package may not compile on platforms where a
C++11 compiler is not available, but perhaps if this becomes a pattern, then
such compilers will start to be available, as in the current version of OSX and
recent enough versions of various linux distributions.
The subset of feature that the version of gcc gives you with Rtools might be
enough.
Alternatively, if you use Rcpp, you can use the RCPP_UNORDERED_MAP macro which
will expand to either unordered_map or tr1::unordered_map, all the condition
compiling is done in Rcpp.
Romain
Le 30 mars 2014 à 21:50, Martin Morgan mtmor...@fhcrc.org a écrit :
In C++ code for use in a R-3.1.0 package, my specific problem is that I would
like to use unordered_map if it is available, or tr1/unordered_map if
not, or map if all else fails.
I (think I) can accomplish this with configure.ac as
AC_INIT(DESCRIPTION)
CXX=`${R_HOME}/bin/R CMD config CXX`
CXXFLAGS=`${R_HOME}/bin/R CMD config CXXFLAGS`
AC_CONFIG_HEADERS([src/config.h])
AC_LANG(C++)
AC_CHECK_HEADERS([unordered_map tr1/unordered_map])
AC_OUTPUT
Use of configure.ac does not seem to be entirely consistent with section
1.2.4 of Writing R Extensions, where one is advised that to use C++(11? see
below) code one should
CXX_STD = CXX11
in Makevars(.win). My code does not require a compiler that supports the full
C++11 feature set. In addition, I do not understand the logic of setting a
variable that influences compiler flags in Makevars -- configure.ac will see
a compiler with inaccurate flags.
Is use of configure.ac orthogonal to setting CXX_STD=CXX11?
Some minor typos:
/R-3-1-branch$ svn diff
Index: doc/manual/R-exts.texi
===
--- doc/manual/R-exts.texi(revision 65339)
+++ doc/manual/R-exts.texi(working copy)
@@ -2250,7 +2250,7 @@
@subsection Using C++11 code
@R{} can be built without a C++ compiler although one is available
-(but not necessarily installed) or all known @R{} platforms.
+(but not necessarily installed) on all known @R{} platforms.
For full portability across platforms, all
that can be assumed is approximate support for the C++98 standard (the
widely used @command{g++} deviates considerably from the standard).
@@ -2272,7 +2272,7 @@
support a flag @option{-std=c++0x}, but the latter only provides partial
support for the C++11 standard.
-In order to use C++ code in a package, the package's @file{Makevars}
+In order to use C++11 code in a package, the package's @file{Makevars}
file (or @file{Makevars.win} on Windows) should include the line
@example
@@ -2329,7 +2329,7 @@
anything other than the GNU version of C++98 and GNU extensions (which
include TR1). The default compiler on Windows is GCC 4.6.x and supports
the @option{-std=c++0x} flag and some C++11 features (see
-@uref{http://gcc.gnu.org/gcc-4.6/cxx0x_status.html}. On these
+@uref{http://gcc.gnu.org/gcc-4.6/cxx0x_status.html}). On these
platforms, it is necessary to select a different compiler for C++11, as
described above, @emph{via} personal @file{Makevars} files. For
example, on OS X 10.7 or later one could select @command{clang++}.
--
Computational Biology / Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109
Location: Arnold Building M1 B861
Phone: (206) 667-2793
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
Re: [Rd] rgl question
On 30/03/2014, 9:20 PM, Dominick Samperi wrote: Hello, If I call lines3d(x,y,z) I get lines connecting each point, but when I call rgl.lines(x,y,z) I get dashed lines, and adding something like type='l' leads to an error message. The docs seem to suggest that rgl.lines() calls lines3d(), so I would expect the result to be the same. Any tips would be appreciated. The difference is in how they use the material properties: rgl.lines sets them permanently, lines3d restores the original value after the call. So I'd guess your call to rgl.lines followed a call to another rgl.* function that set the lty property to dashed. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] CXX_STD and configure.ac in packages
On Mon, 2014-03-31 at 07:09 +, Martyn Plummer wrote:
Hi Martin,
Thanks for the patch. I have applied it. I also added CXX1X and friends to
the list of approved variables for R CMD config.
So you can now query the existence of C++11 support with `R CMD config CXX1X`
(It is empty if C++11 support is not available)
and then take appropriate action in your configure script if, in Dirk's
words, you want to do the configure dance.
The philosophy underlying C++ support in R is that there are only two
standards - C++98 and C++11 - and that
you should write to one of those standards.
A should add a clarification. The way I wrote this makes it sound like
an even-handed choice, but only C++98 has cross-platform support. If you
use C++11 then many users will not currently be able to use your code.
Nobody should be writing new code that uses TR1 extensions now: they are
superseded by the new standard.
The map and unordered_map classes are a corner case, as they offer the same
functionality but latter has much better
complexity guarantees, so it is tempting to use it when available. But from
a global perspective you should think of
C++98 and C++11 as two different languages.
Martyn
From: r-devel-boun...@r-project.org [r-devel-boun...@r-project.org] on behalf
of Romain Francois [rom...@r-enthusiasts.com]
Sent: 31 March 2014 08:22
To: Martin Morgan
Cc: R-devel
Subject: Re: [Rd] CXX_STD and configure.ac in packages
Hi,
My advice would be to use SystemRequirements: C++11
As unordered_map is definitely a part of C++11, assuming this version of
the standard gives it to you. Your package may not compile on platforms where
a C++11 compiler is not available, but perhaps if this becomes a pattern,
then such compilers will start to be available, as in the current version of
OSX and recent enough versions of various linux distributions.
The subset of feature that the version of gcc gives you with Rtools might be
enough.
Alternatively, if you use Rcpp, you can use the RCPP_UNORDERED_MAP macro
which will expand to either unordered_map or tr1::unordered_map, all the
condition compiling is done in Rcpp.
Romain
Le 30 mars 2014 à 21:50, Martin Morgan mtmor...@fhcrc.org a écrit :
In C++ code for use in a R-3.1.0 package, my specific problem is that I
would like to use unordered_map if it is available, or
tr1/unordered_map if not, or map if all else fails.
I (think I) can accomplish this with configure.ac as
AC_INIT(DESCRIPTION)
CXX=`${R_HOME}/bin/R CMD config CXX`
CXXFLAGS=`${R_HOME}/bin/R CMD config CXXFLAGS`
AC_CONFIG_HEADERS([src/config.h])
AC_LANG(C++)
AC_CHECK_HEADERS([unordered_map tr1/unordered_map])
AC_OUTPUT
Use of configure.ac does not seem to be entirely consistent with section
1.2.4 of Writing R Extensions, where one is advised that to use C++(11? see
below) code one should
CXX_STD = CXX11
in Makevars(.win). My code does not require a compiler that supports the
full C++11 feature set. In addition, I do not understand the logic of
setting a variable that influences compiler flags in Makevars --
configure.ac will see a compiler with inaccurate flags.
Is use of configure.ac orthogonal to setting CXX_STD=CXX11?
Some minor typos:
/R-3-1-branch$ svn diff
Index: doc/manual/R-exts.texi
===
--- doc/manual/R-exts.texi(revision 65339)
+++ doc/manual/R-exts.texi(working copy)
@@ -2250,7 +2250,7 @@
@subsection Using C++11 code
@R{} can be built without a C++ compiler although one is available
-(but not necessarily installed) or all known @R{} platforms.
+(but not necessarily installed) on all known @R{} platforms.
For full portability across platforms, all
that can be assumed is approximate support for the C++98 standard (the
widely used @command{g++} deviates considerably from the standard).
@@ -2272,7 +2272,7 @@
support a flag @option{-std=c++0x}, but the latter only provides partial
support for the C++11 standard.
-In order to use C++ code in a package, the package's @file{Makevars}
+In order to use C++11 code in a package, the package's @file{Makevars}
file (or @file{Makevars.win} on Windows) should include the line
@example
@@ -2329,7 +2329,7 @@
anything other than the GNU version of C++98 and GNU extensions (which
include TR1). The default compiler on Windows is GCC 4.6.x and supports
the @option{-std=c++0x} flag and some C++11 features (see
-@uref{http://gcc.gnu.org/gcc-4.6/cxx0x_status.html}. On these
+@uref{http://gcc.gnu.org/gcc-4.6/cxx0x_status.html}). On these
platforms, it is necessary to select a different compiler for C++11, as
described above, @emph{via} personal @file{Makevars} files. For
example, on OS X 10.7 or later one could select @command{clang++}.
--
Computational Biology
Re: [Rd] CXX_STD and configure.ac in packages
Le 31 mars 2014 à 12:20, Martyn Plummer plumm...@iarc.fr a écrit :
On Mon, 2014-03-31 at 07:09 +, Martyn Plummer wrote:
Hi Martin,
Thanks for the patch. I have applied it. I also added CXX1X and friends to
the list of approved variables for R CMD config.
So you can now query the existence of C++11 support with `R CMD config
CXX1X` (It is empty if C++11 support is not available)
and then take appropriate action in your configure script if, in Dirk's
words, you want to do the configure dance.
The philosophy underlying C++ support in R is that there are only two
standards - C++98 and C++11 - and that
you should write to one of those standards.
A should add a clarification. The way I wrote this makes it sound like
an even-handed choice, but only C++98 has cross-platform support. If you
use C++11 then many users will not currently be able to use your code.
OTOH, if nobody goes there, the need for C++11 might not be perceived as
important by people who take care of cross platform support.
Probably not Martin’s fight. One can do the gymnastics to get an unordered_map
with C++98 (through boost, tr1, etc ...), but C++11 brings a great combination
of new features that make it a better language, and I agree that it is almost a
new language. And once you start using it, it is hard to look back.
Nobody should be writing new code that uses TR1 extensions now: they are
superseded by the new standard.
The map and unordered_map classes are a corner case, as they offer the same
functionality but latter has much better
complexity guarantees, so it is tempting to use it when available. But from
a global perspective you should think of
C++98 and C++11 as two different languages.
Martyn
From: r-devel-boun...@r-project.org [r-devel-boun...@r-project.org] on
behalf of Romain Francois [rom...@r-enthusiasts.com]
Sent: 31 March 2014 08:22
To: Martin Morgan
Cc: R-devel
Subject: Re: [Rd] CXX_STD and configure.ac in packages
Hi,
My advice would be to use SystemRequirements: C++11
As unordered_map is definitely a part of C++11, assuming this version of
the standard gives it to you. Your package may not compile on platforms
where a C++11 compiler is not available, but perhaps if this becomes a
pattern, then such compilers will start to be available, as in the current
version of OSX and recent enough versions of various linux distributions.
The subset of feature that the version of gcc gives you with Rtools might be
enough.
Alternatively, if you use Rcpp, you can use the RCPP_UNORDERED_MAP macro
which will expand to either unordered_map or tr1::unordered_map, all the
condition compiling is done in Rcpp.
Romain
Le 30 mars 2014 à 21:50, Martin Morgan mtmor...@fhcrc.org a écrit :
In C++ code for use in a R-3.1.0 package, my specific problem is that I
would like to use unordered_map if it is available, or
tr1/unordered_map if not, or map if all else fails.
I (think I) can accomplish this with configure.ac as
AC_INIT(DESCRIPTION)
CXX=`${R_HOME}/bin/R CMD config CXX`
CXXFLAGS=`${R_HOME}/bin/R CMD config CXXFLAGS`
AC_CONFIG_HEADERS([src/config.h])
AC_LANG(C++)
AC_CHECK_HEADERS([unordered_map tr1/unordered_map])
AC_OUTPUT
Use of configure.ac does not seem to be entirely consistent with section
1.2.4 of Writing R Extensions, where one is advised that to use C++(11? see
below) code one should
CXX_STD = CXX11
in Makevars(.win). My code does not require a compiler that supports the
full C++11 feature set. In addition, I do not understand the logic of
setting a variable that influences compiler flags in Makevars --
configure.ac will see a compiler with inaccurate flags.
Is use of configure.ac orthogonal to setting CXX_STD=CXX11?
Some minor typos:
/R-3-1-branch$ svn diff
Index: doc/manual/R-exts.texi
===
--- doc/manual/R-exts.texi(revision 65339)
+++ doc/manual/R-exts.texi(working copy)
@@ -2250,7 +2250,7 @@
@subsection Using C++11 code
@R{} can be built without a C++ compiler although one is available
-(but not necessarily installed) or all known @R{} platforms.
+(but not necessarily installed) on all known @R{} platforms.
For full portability across platforms, all
that can be assumed is approximate support for the C++98 standard (the
widely used @command{g++} deviates considerably from the standard).
@@ -2272,7 +2272,7 @@
support a flag @option{-std=c++0x}, but the latter only provides partial
support for the C++11 standard.
-In order to use C++ code in a package, the package's @file{Makevars}
+In order to use C++11 code in a package, the package's @file{Makevars}
file (or @file{Makevars.win} on Windows) should include the line
@example
@@ -2329,7 +2329,7 @@
anything other than the GNU version of C++98 and GNU extensions (which
include TR1). The default
Re: [Rd] CXX_STD and configure.ac in packages
On 03/31/2014 04:30 AM, Romain François wrote:
Le 31 mars 2014 à 12:20, Martyn Plummer plumm...@iarc.fr a écrit :
On Mon, 2014-03-31 at 07:09 +, Martyn Plummer wrote:
Hi Martin,
Thanks for the patch. I have applied it. I also added CXX1X and friends to the
list of approved variables for R CMD config.
So you can now query the existence of C++11 support with `R CMD config CXX1X`
(It is empty if C++11 support is not available)
and then take appropriate action in your configure script if, in Dirk's words,
you want to do the configure dance.
Thanks, this is what I was looking for.
The philosophy underlying C++ support in R is that there are only two standards
- C++98 and C++11 - and that
you should write to one of those standards.
A should add a clarification. The way I wrote this makes it sound like
an even-handed choice, but only C++98 has cross-platform support. If you
use C++11 then many users will not currently be able to use your code.
Yes, the Writing R Extensions section at first seduced me into thinking that I
could get broad support for C++11 with a simple macro, but obviously that can
only come from the underlying compilers and R is making no guarantees about these.
OTOH, if nobody goes there, the need for C++11 might not be perceived as
important by people who take care of cross platform support.
Probably not Martin’s fight. One can do the gymnastics to get an unordered_map
with C++98 (through boost, tr1, etc ...), but C++11 brings a great combination
of new features that make it a better language, and I agree that it is almost a
new language. And once you start using it, it is hard to look back.
Nobody should be writing new code that uses TR1 extensions now: they are
superseded by the new standard.
For me unordered_map is a small part of a large mostly C code base; using it
instead of map has substantial benefits, but restricting package use to C++11
isn't really on the table in this particular case.
I'll take Martyn's philosophical statement that for R there are only two
standards -- C++98 and C++11, with attendant trade-offs -- as a guiding
principle and as a pragmatic solution avoid my complicated unordered_map
configure dance for now.
Thanks all for the various inputs.
Martin Morgan
The map and unordered_map classes are a corner case, as they offer the same
functionality but latter has much better
complexity guarantees, so it is tempting to use it when available. But from a
global perspective you should think of
C++98 and C++11 as two different languages.
Martyn
From: r-devel-boun...@r-project.org [r-devel-boun...@r-project.org] on behalf
of Romain Francois [rom...@r-enthusiasts.com]
Sent: 31 March 2014 08:22
To: Martin Morgan
Cc: R-devel
Subject: Re: [Rd] CXX_STD and configure.ac in packages
Hi,
My advice would be to use SystemRequirements: C++11
As unordered_map is definitely a part of C++11, assuming this version of the
standard gives it to you. Your package may not compile on platforms where a C++11
compiler is not available, but perhaps if this becomes a pattern, then such compilers
will start to be available, as in the current version of OSX and recent enough
versions of various linux distributions.
The subset of feature that the version of gcc gives you with Rtools might be
enough.
Alternatively, if you use Rcpp, you can use the RCPP_UNORDERED_MAP macro which
will expand to either unordered_map or tr1::unordered_map, all the condition
compiling is done in Rcpp.
Romain
Le 30 mars 2014 à 21:50, Martin Morgan mtmor...@fhcrc.org a écrit :
In C++ code for use in a R-3.1.0 package, my specific problem is that I would like to use
unordered_map if it is available, or tr1/unordered_map if not, or map if
all else fails.
I (think I) can accomplish this with configure.ac as
AC_INIT(DESCRIPTION)
CXX=`${R_HOME}/bin/R CMD config CXX`
CXXFLAGS=`${R_HOME}/bin/R CMD config CXXFLAGS`
AC_CONFIG_HEADERS([src/config.h])
AC_LANG(C++)
AC_CHECK_HEADERS([unordered_map tr1/unordered_map])
AC_OUTPUT
Use of configure.ac does not seem to be entirely consistent with section 1.2.4
of Writing R Extensions, where one is advised that to use C++(11? see below)
code one should
CXX_STD = CXX11
in Makevars(.win). My code does not require a compiler that supports the full
C++11 feature set. In addition, I do not understand the logic of setting a
variable that influences compiler flags in Makevars -- configure.ac will see a
compiler with inaccurate flags.
Is use of configure.ac orthogonal to setting CXX_STD=CXX11?
Some minor typos:
/R-3-1-branch$ svn diff
Index: doc/manual/R-exts.texi
===
--- doc/manual/R-exts.texi(revision 65339)
+++ doc/manual/R-exts.texi(working copy)
@@ -2250,7 +2250,7 @@
@subsection Using C++11 code
@R{} can be built without a C++ compiler although one is available
-(but not necessarily installed) or
Re: [Rd] internal string comparison (Scollate)
Hello, The use case I have might involve sorting many small such STRSXP vectors. If I have Scollate, I don’t need to materialize the vectors and I can use the sorting algorithm I choose. Here is some made up data: df - data.frame( x = sample( 1:10, 1000, replace = TRUE), y = sample( 1:100, 100, replace = TRUE), z = replicate( 1, paste( sample(letters, sample(1:100, size = 1), replace = TRUE ), collapse = ) ), stringsAsFactors = FALSE ) For which I’d like something like what order( df$x, df$y, df$z ) gives me. For example: system.time( res1 - order( df$x, df$y, df$z) ) utilisateur système écoulé 0.017 0.000 0.017 system.time( res2 - dplyr::order_( df$x, df$y, df$z ) ) utilisateur système écoulé 0.005 0.000 0.005 identical( res1, res2 ) [1] TRUE The way dplyr::order_ is implemented I don’t need to materialize 500 STRSXP vectors and call order or sort on them ( 492 == nrow( unique( df[, c(x, y ) ] ) ) ) I just need to be able to compare two scalars together (either two ints, two doubles, or two CHARSXP SEXP). We already have special code to handle what it means to compare int, double etc in the R world with NA and NaN, etc ... Scollate would give a way to compare two CHARSXP SEXP, the way R would. Of course one has to be careful how it is called, I have read the source. Materialising temporary values into an R vector may be the R way of doing things, but sometimes it is a waste of both memory and time. Yes, this is about performance. We are often asked to choose between performance and correctness when in fact we can have both. Romain Le 27 mars 2014 à 22:12, Duncan Murdoch murdoch.dun...@gmail.com a écrit : On 14-03-27 3:01 PM, Kevin Ushey wrote: I too think it would be useful if R exported some version of its string sorting routines, since sorting strings while respecting locale, and doing so in a portable fashion while respecting the user's environment, is not trivial. R holds a fast, portable, well-tested solution, and I think package developers would be very appreciative if some portion of this was exposed at the C level. It does. You can put your strings in an R STRSXP vector, and call the R sort function on it. The usual objection to constructing an R expression and evaluating it is that it is slow, but if you are talking about sorting, the time spent in the sort is likely to dominate the time spent in the setup. If not `Scollate`, then perhaps other candidates could be the more generic `sortVector`, or the more string-specific (and NA-respecting) `scmp`. Evaluating an R expression gives you sortVector. I can see an argument for Scollate being useful (sorting isn't the only reason to compare strings), but I can see arguments against exposing it too. Take a look at the source: it needs to be used carefully. In particular, it can return a 0 for unequal strings, and users are likely to get messed up by that, or to submit bogus bug reports. And it's not impossible to work around: if you can collect the universe of strings to compare in advance, then just use order() to convert them to integer values, and compare those. Duncan Murdoch I understand that the volunteers at R Core have limited time and resources, and exposing an API imposes additional maintenance burdens on an already thinly stretched team, but this is a situation where the R users and package authors alike could benefit. Or, if there are other reasons why exporting such routines is not possible nor recommended, it would be very informative to know why. Thanks, Kevin On Thu, Mar 27, 2014 at 11:08 AM, Dirk Eddelbuettel e...@debian.org wrote: On 26 March 2014 at 19:09, Romain François wrote: | That's one part of the problem. Indeed I'd rather use something rather than | copy and paste it and run the risk of being outdated. The answer to that is We all would. But they won't let us by refusing to create more API access points. | testing though. I can develop a test suite that can let me know I'm out of Correct. | date and I need to copy and paste some new code, etc ... Done that before, this | is tedious, but so what. | | The other part of the problem (the real part of the problem actually) is that, | at least when R is built with ICU support, Scollate will depend on a the | collator pointer in util.c | https://github.com/wch/r-source/blob/trunk/src/main/util.c#L1777 | | And this can be controlled by the base::icuSetCollate function. Of course the | collator pointer is not public. So the next (and even less pleasant) answer is to build a new package which links to, (or worse yet, embeds) libicu. As you want ICU behaviour, you will need ICU code. Dirk -- Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com __ R-devel@r-project.org mailing list
Re: [Rd] rgl question
Thanks for the comment. No, there were no such prior calls, unless rgl.lines() itself sets lty to dashed? Here is a simple session run under Windows: library(rgl) x - 1:20 y - 1:20 z - 1:20 rgl.lines(x,y,z) # displays dashed line lines3d(x,y,z) # displays solid line I'm using R 3.1.0 alpha On Mon, Mar 31, 2014 at 5:44 AM, Duncan Murdoch murdoch.dun...@gmail.com wrote: On 30/03/2014, 9:20 PM, Dominick Samperi wrote: Hello, If I call lines3d(x,y,z) I get lines connecting each point, but when I call rgl.lines(x,y,z) I get dashed lines, and adding something like type='l' leads to an error message. The docs seem to suggest that rgl.lines() calls lines3d(), so I would expect the result to be the same. Any tips would be appreciated. The difference is in how they use the material properties: rgl.lines sets them permanently, lines3d restores the original value after the call. So I'd guess your call to rgl.lines followed a call to another rgl.* function that set the lty property to dashed. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] rgl question
On 31/03/2014 12:56 PM, Dominick Samperi wrote: Thanks for the comment. No, there were no such prior calls, unless rgl.lines() itself sets lty to dashed? Here is a simple session run under Windows: library(rgl) x - 1:20 y - 1:20 z - 1:20 rgl.lines(x,y,z) # displays dashed line lines3d(x,y,z) # displays solid line Sorry, what I said was true, but wasn't helpful. The real explanation is that rgl.lines corresponds to segments3d, not to lines3d. It pairs up the points and draws line segments, it doesn't join the points. Use rgl.linestrips (the OpenGL terminology) if you want the equivalent of lines3d but with the persistant material properties. I had forgotten that, because I never use the rgl.* functions. I would say neither should you, but there might be some good reason to do so. Duncan Murdoch I'm using R 3.1.0 alpha On Mon, Mar 31, 2014 at 5:44 AM, Duncan Murdoch murdoch.dun...@gmail.com wrote: On 30/03/2014, 9:20 PM, Dominick Samperi wrote: Hello, If I call lines3d(x,y,z) I get lines connecting each point, but when I call rgl.lines(x,y,z) I get dashed lines, and adding something like type='l' leads to an error message. The docs seem to suggest that rgl.lines() calls lines3d(), so I would expect the result to be the same. Any tips would be appreciated. The difference is in how they use the material properties: rgl.lines sets them permanently, lines3d restores the original value after the call. So I'd guess your call to rgl.lines followed a call to another rgl.* function that set the lty property to dashed. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] C API to get numrow of data frame
Hi ,
Is there any C API to the R API nrow of dataframe ?
x- data.frame()
n- nrow(x)
print(n)
0
Example :
My C function which deals with data frame looks like and I don't to send
the number of rows of data frame .I want to detect it from the function
itself, my function take data frame as argument and do some on it. I want
API equivalent to nrow. I tried Rf_nrows,Rf_ncols . No much help.
SEXP writeRR(SEXP dataframe) {
}
Any help is very appreciated.
Thanks,
Sandip
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] C API to get numrow of data frame
The simplest case would be:
int num_rows = Rf_length(VECTOR_ELT(dataframe, 0));
int num_columns = Rf_length(dataframe);
There may be edge cases for which this doesn't work; would need to
look into how the dim primitive is implemented to be sure.
- Murray
On Mon, Mar 31, 2014 at 4:40 PM, Sandip Nandi sanna...@umail.iu.edu wrote:
Hi ,
Is there any C API to the R API nrow of dataframe ?
x- data.frame()
n- nrow(x)
print(n)
0
Example :
My C function which deals with data frame looks like and I don't to send
the number of rows of data frame .I want to detect it from the function
itself, my function take data frame as argument and do some on it. I want
API equivalent to nrow. I tried Rf_nrows,Rf_ncols . No much help.
SEXP writeRR(SEXP dataframe) {
}
Any help is very appreciated.
Thanks,
Sandip
[[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] C API to get numrow of data frame
I think it is actually better to check the length of the row names. In case
the data frame has zero columns. (FIXME, of course.)
Gabor
On Mon, Mar 31, 2014 at 8:04 PM, Murray Stokely mur...@stokely.org wrote:
The simplest case would be:
int num_rows = Rf_length(VECTOR_ELT(dataframe, 0));
int num_columns = Rf_length(dataframe);
There may be edge cases for which this doesn't work; would need to
look into how the dim primitive is implemented to be sure.
- Murray
On Mon, Mar 31, 2014 at 4:40 PM, Sandip Nandi sanna...@umail.iu.edu
wrote:
Hi ,
Is there any C API to the R API nrow of dataframe ?
x- data.frame()
n- nrow(x)
print(n)
0
Example :
My C function which deals with data frame looks like and I don't to send
the number of rows of data frame .I want to detect it from the function
itself, my function take data frame as argument and do some on it. I want
API equivalent to nrow. I tried Rf_nrows,Rf_ncols . No much help.
SEXP writeRR(SEXP dataframe) {
}
Any help is very appreciated.
Thanks,
Sandip
[[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
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] C API to get numrow of data frame
The Rf_length(dataframe) will provide the length of row names . So it
should be checked first. I found one edge case now
My dataframe has 0 rows and 0 columns
int num_rows = Rf_length(VECTOR_ELT(dataframe, 0)); returns 1
,in stead of 0 . Not sure why.
Thanks
On Mon, Mar 31, 2014 at 6:12 PM, Gábor Csárdi csardi.ga...@gmail.comwrote:
I think it is actually better to check the length of the row names. In
case the data frame has zero columns. (FIXME, of course.)
Gabor
On Mon, Mar 31, 2014 at 8:04 PM, Murray Stokely mur...@stokely.orgwrote:
The simplest case would be:
int num_rows = Rf_length(VECTOR_ELT(dataframe, 0));
int num_columns = Rf_length(dataframe);
There may be edge cases for which this doesn't work; would need to
look into how the dim primitive is implemented to be sure.
- Murray
On Mon, Mar 31, 2014 at 4:40 PM, Sandip Nandi sanna...@umail.iu.edu
wrote:
Hi ,
Is there any C API to the R API nrow of dataframe ?
x- data.frame()
n- nrow(x)
print(n)
0
Example :
My C function which deals with data frame looks like and I don't to send
the number of rows of data frame .I want to detect it from the function
itself, my function take data frame as argument and do some on it. I
want
API equivalent to nrow. I tried Rf_nrows,Rf_ncols . No much help.
SEXP writeRR(SEXP dataframe) {
}
Any help is very appreciated.
Thanks,
Sandip
[[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
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] C API to get numrow of data frame
I didn't look at the names because I believe that would be incorrect
if the row names were stored internally in the compact form.
See ?.set_row_names (hat tip, Tim Hesterberg who showed me this years ago) :
'row.names' can be stored internally in compact form.
'.set_row_names(n)' generates that form for automatic row names of
length 'n', to be assigned to 'attr(a data frame, row.names)'.
'.row_names_info' gives information on the internal form of the
row names for a data frame: for details of what information see
the argument 'type'.
The function I wrote obviously doesn't work for 0 row or 0 column
data.frames, you need to check for that.
On Mon, Mar 31, 2014 at 6:12 PM, Gábor Csárdi csardi.ga...@gmail.com wrote:
I think it is actually better to check the length of the row names. In case
the data frame has zero columns. (FIXME, of course.)
Gabor
On Mon, Mar 31, 2014 at 8:04 PM, Murray Stokely mur...@stokely.org wrote:
The simplest case would be:
int num_rows = Rf_length(VECTOR_ELT(dataframe, 0));
int num_columns = Rf_length(dataframe);
There may be edge cases for which this doesn't work; would need to
look into how the dim primitive is implemented to be sure.
- Murray
On Mon, Mar 31, 2014 at 4:40 PM, Sandip Nandi sanna...@umail.iu.edu
wrote:
Hi ,
Is there any C API to the R API nrow of dataframe ?
x- data.frame()
n- nrow(x)
print(n)
0
Example :
My C function which deals with data frame looks like and I don't to send
the number of rows of data frame .I want to detect it from the function
itself, my function take data frame as argument and do some on it. I
want
API equivalent to nrow. I tried Rf_nrows,Rf_ncols . No much help.
SEXP writeRR(SEXP dataframe) {
}
Any help is very appreciated.
Thanks,
Sandip
[[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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] C API to get numrow of data frame
The safest way is to check the length of the row.names attribute, e.g.
length(getAttrib(df, R_RowNamesSymbol)).
This protects you from both data.frames with zero columns, as well as
corrupted data.frames containing columns with different lengths, since
by definition the number of rows in a data.frame is defined by its
row.names attribute. However, R will internally un-collapse a
collapsed row.names on this getAttrib call, which is probably
undesired for very large data.frames.
One way of getting around this is calling .row_names_info from R, e.g.
(modulo my errors):
int df_nrows(SEXP s) {
if (!Rf_inherits(s, data.frame)) Rf_error(expecting a data.frame);
SEXP two = PROTECT(Rf_ScalarInteger(2));
SEXP call = PROTECT( Rf_lang3(
Rf_install(.row_names_info),
s,
two
) );
SEXP result = PROTECT(Rf_eval(call, R_BaseEnv));
int output = INTEGER(result)[0];
UNPROTECT(3);
return output;
}
More ideally (?), such a function could be added to util.c and
exported by R, e.g. (again, modulo my errors):
int df_nrows(SEXP s) {
if (!inherits(s, data.frame)) error(expecting a data.frame);
SEXP t = getAttrib0(s, R_RowNamesSymbol);
if (isInteger(t) INTEGER(t)[0] == NA_INTEGER LENGTH(t) == 2)
return abs(INTEGER(t)[1]);
else
return LENGTH(t);
}
or even incorporated into the already available 'nrows' function.
Although there is probably someone out there depending on 'nrows'
returning the number of columns for their data.frame...
Cheers,
Kevin
On Mon, Mar 31, 2014 at 6:27 PM, Murray Stokely mur...@stokely.org wrote:
I didn't look at the names because I believe that would be incorrect
if the row names were stored internally in the compact form.
See ?.set_row_names (hat tip, Tim Hesterberg who showed me this years ago) :
'row.names' can be stored internally in compact form.
'.set_row_names(n)' generates that form for automatic row names of
length 'n', to be assigned to 'attr(a data frame, row.names)'.
'.row_names_info' gives information on the internal form of the
row names for a data frame: for details of what information see
the argument 'type'.
The function I wrote obviously doesn't work for 0 row or 0 column
data.frames, you need to check for that.
On Mon, Mar 31, 2014 at 6:12 PM, Gábor Csárdi csardi.ga...@gmail.com wrote:
I think it is actually better to check the length of the row names. In case
the data frame has zero columns. (FIXME, of course.)
Gabor
On Mon, Mar 31, 2014 at 8:04 PM, Murray Stokely mur...@stokely.org wrote:
The simplest case would be:
int num_rows = Rf_length(VECTOR_ELT(dataframe, 0));
int num_columns = Rf_length(dataframe);
There may be edge cases for which this doesn't work; would need to
look into how the dim primitive is implemented to be sure.
- Murray
On Mon, Mar 31, 2014 at 4:40 PM, Sandip Nandi sanna...@umail.iu.edu
wrote:
Hi ,
Is there any C API to the R API nrow of dataframe ?
x- data.frame()
n- nrow(x)
print(n)
0
Example :
My C function which deals with data frame looks like and I don't to send
the number of rows of data frame .I want to detect it from the function
itself, my function take data frame as argument and do some on it. I
want
API equivalent to nrow. I tried Rf_nrows,Rf_ncols . No much help.
SEXP writeRR(SEXP dataframe) {
}
Any help is very appreciated.
Thanks,
Sandip
[[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
__
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
