Re: [Rd] value returned by by()
It returns a list with athe class attribut set to by, just use:
x - by(.)
unclass(x)
Uwe Ligges
On 14.09.2010 00:11, Seb wrote:
Hi,
I noticed that by() returns an object of class 'by', regardless of what
its argument 'simplify' is. ?by says that it always returns a list if
simplify=FALSE, yet by.data.frame shows:
---cut here---start--
function (data, INDICES, FUN, ..., simplify = TRUE)
{
if (!is.list(INDICES)) {
IND- vector(list, 1L)
IND[[1L]]- INDICES
names(IND)- deparse(substitute(INDICES))[1L]
}
else IND- INDICES
FUNx- function(x) FUN(data[x, , drop = FALSE], ...)
nd- nrow(data)
ans- eval(substitute(tapply(1L:nd, IND, FUNx, simplify = simplify)),
data)
attr(ans, call)- match.call()
class(ans)- by
ans
}
environment: namespace:base
---cut here---end
One could force a list by wrapping it around an lapply(by.object, [),
but this is not possible if the object contains S4 objects. How does
one force a list in those cases?
Cheers,
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] More strange R CMD build/check errors on Windows
On 12.09.2010 12:10, Hervé Pagès wrote: Hi Peter, On 09/12/2010 01:51 AM, Peter Dalgaard wrote: On 09/12/2010 08:10 AM, Hervé Pagès wrote: ... AFAICT those problems were never seen before (i.e. with R 2.12). They show up randomly everyday for a small number of packages (between 10 and 20 out of 400). The set of victims changes everyday and any package seems to be a potential victim (I've not been able to observe any obvious pattern so far). Does anyone have any idea what could make 'R CMD build' and 'R CMD check' so confused/unreliable on Windows? Brian had some ideas that the problems are related to the shell that is used. Is the problem still apparent in a very recent R-devel from few days ago? I am just back from vacations and have not updated yet. I experienced the same problems and I am just iterating automatically if typical problems are apparent from the log files. I hope some if not all parts are solved now and will do some new test runs shortly. Best, Uwe Thanks, H. Antivirus software? I suspect you already ruled that out, but it has been the culprit for problems with mysteriously disappearing intermediate files in several cases, so I thought I'd mention it. Actually I didn't try that yet because we still build BioC release (using R-2.11.1) on these 2 Windows boxes and we don't see any of those problems for the release builds. But I will. Could it be that the fact that 'R CMD build' and 'R CMD check' are R-based in R-2.12 (and not Perl-based anymore) make them more fragile when something like an antivirus is messing around with the filesystem? Thanks for the suggestion, H. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Best way to manage configuration for openMP support
On 14 September 2010 at 11:06, Karl Forner wrote:
| I've written a package that may use OpenMP to speed up computations. OpenMP
| is supported in recent Gcc versions by using the -fopenmp flag.
| The problem is that flag crashed gcc versions that do not support OpenMP.
| So what is the best way for a package to handle this issue. Has someone a
| configure script that deals with this ?
I don't know off-hand of any CRAN packages that do that, but you could look
at Luke Tierney's pnmath package which uses Open MP. It may have a test.
Else, you can query gcc for minimum versions. I have some configure code from
way back when then tested for a minimum version of 3.0 (!!):
# We are using C++
AC_LANG(C++)
AC_REQUIRE_CPP
AC_PROG_CXX
if test ${GXX} = yes; then
gxx_version=`${CXX} -v 21 | grep ^.*g.. version | \\
sed -e 's/^.*g.. version *//'`
case ${gxx_version} in
1.*|2.*)
AC_MSG_WARN([Only g++ version 3.0 or greater can be used with
RQuantib.])
AC_MSG_ERROR([Please use a different compiler.])
;;
esac
fi
You could do the same for gcc and strip out major version (4) and minor (0 or
1) and then complain. With 4.2 you should be fine.
Dirk
--
Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] doc bug in ?residuals.gls
Under the description of the 'type' argument, ?residuals.gls says
'Defaults to ‘pearson’.'
But residuals.gls starts
residuals.gls -
function(object, type = c(response, pearson, normalized), ...)
{
type - match.arg(type)
...
which sure looks to me like it defaults to response, not pearson
(and it behaves that way in tests).
It would seem to make more sense to change the documentation rather than
the code
since anyone who looked at the docs would have been confused already,
whereas someone who had
been happily using the code without looking at the docs would see a
sudden change in the results ...
This is in nlme 3.1-96, from a fresh tools/rsync-recommended. Sending it
to r-devel for comment because r-core is listed as the maintainer.
sincerely
Ben Bolker
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Best way to manage configuration for openMP support
Please do NOT use version checks on compilers and other tools - those are the
wrong way to go! You want to use actual functionality check as that is the only
reliable way to find out that something works or not*. For example there are
issues on certain Linux systems with the gomp library that prevents it from
loading into packages so regardless of the compiler version it won't work. Also
other compilers also support OMP so checking specific compiler's version will
be simply wrong.
In fact autoconf has AC_OPENMP macro that does all the heavy-lifting for you.
This is a sample configure.ac that does the job:
# Process this file with autoconf to produce a configure script.
AC_INIT(OpenMPpackage, 0.8, simon.urba...@r-project.org)
AC_CONFIG_SRCDIR([src/test.c])
# find R home and set CC/CFLAGS
: ${R_HOME=`R RHOME`}
if test -z ${R_HOME}; then
echo could not determine R_HOME
exit 1
fi
RBIN=${R_HOME}/bin/R
CC=`${RBIN} CMD config CC`;
CFLAGS=`${RBIN} CMD config CFLAGS`
LIBS=${PKG_LIBS}
# Checks for programs.
AC_PROG_CC
# Check for OpenMP
AC_OPENMP
# since some systems have broken OMP libraries
# we also check that the actual package will work
ac_pkg_openmp=no
if test -n ${OPENMP_CFLAGS}; then
AC_MSG_CHECKING([whether OpenMP will work in a package])
AC_LANG_CONFTEST(
[AC_LANG_PROGRAM([[#include omp.h]], [[ return omp_get_num_threads (); ]])])
PKG_CFLAGS=${OPENMP_CFLAGS} PKG_LIBS=${OPENMP_CFLAGS} $RBIN CMD SHLIB
conftest.c 1AS_MESSAGE_LOG_FD 2AS_MESSAGE_LOG_FD $RBIN --vanilla -q -e
dyn.load(paste('conftest',.Platform\$dynlib.ext,sep='')) 1AS_MESSAGE_LOG_FD
2AS_MESSAGE_LOG_FD ac_pkg_openmp=yes
AC_MSG_RESULT([${ac_pkg_openmp}])
fi
# if ${ac_pkg_openmp} = yes then we have OMP, otherwise it will be no
if test ${ac_pkg_openmp} = no; then
OPENMP_CFLAGS=''
# you could put AC_MSG_ERROR here is OpenMP is required
fi
AC_SUBST(OPENMP_CFLAGS)
AC_CONFIG_FILES([src/Makevars])
AC_OUTPUT
And your Makevars.in will probably look something like:
pkg_cppfla...@openmp_cflags@
pkg_li...@openmp_cflags@ @LIBS@
Cheers,
Simon
* - compiler version checks are sometime used directly in the source files as a
work-around if autoconf cannot be used. But since autoconf provides an easy way
to test functionality you should do that instead if available.
On Sep 14, 2010, at 7:40 AM, Dirk Eddelbuettel wrote:
On 14 September 2010 at 11:06, Karl Forner wrote:
| I've written a package that may use OpenMP to speed up computations. OpenMP
| is supported in recent Gcc versions by using the -fopenmp flag.
| The problem is that flag crashed gcc versions that do not support OpenMP.
| So what is the best way for a package to handle this issue. Has someone a
| configure script that deals with this ?
I don't know off-hand of any CRAN packages that do that, but you could look
at Luke Tierney's pnmath package which uses Open MP. It may have a test.
Else, you can query gcc for minimum versions. I have some configure code from
way back when then tested for a minimum version of 3.0 (!!):
# We are using C++
AC_LANG(C++)
AC_REQUIRE_CPP
AC_PROG_CXX
if test ${GXX} = yes; then
gxx_version=`${CXX} -v 21 | grep ^.*g.. version | \\
sed -e 's/^.*g.. version *//'`
case ${gxx_version} in
1.*|2.*)
AC_MSG_WARN([Only g++ version 3.0 or greater can be used with
RQuantib.])
AC_MSG_ERROR([Please use a different compiler.])
;;
esac
fi
You could do the same for gcc and strip out major version (4) and minor (0 or
1) and then complain. With 4.2 you should be fine.
Dirk
--
Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com
__
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] Best way to manage configuration for openMP support
On 14 September 2010 at 13:01, Simon Urbanek wrote:
| Please do NOT use version checks on compilers and other tools - those are the
wrong way to go! You want to use actual functionality check as that is the only
reliable way to find out that something works or not*. For example there are
issues on certain Linux systems with the gomp library that prevents it from
loading into packages so regardless of the compiler version it won't work. Also
other compilers also support OMP so checking specific compiler's version will
be simply wrong.
|
| In fact autoconf has AC_OPENMP macro that does all the heavy-lifting for you.
This is a sample configure.ac that does the job:
Seconded. This is the proper way. I had meant to add the hint for a
autoconf-wrapped test program but had to dash out earlier.
Thanks for posting a full example, Simon. Much appreciated.
Dirk
| # Process this file with autoconf to produce a configure script.
| AC_INIT(OpenMPpackage, 0.8, simon.urba...@r-project.org)
| AC_CONFIG_SRCDIR([src/test.c])
|
| # find R home and set CC/CFLAGS
| : ${R_HOME=`R RHOME`}
| if test -z ${R_HOME}; then
| echo could not determine R_HOME
| exit 1
| fi
| RBIN=${R_HOME}/bin/R
| CC=`${RBIN} CMD config CC`;
| CFLAGS=`${RBIN} CMD config CFLAGS`
| LIBS=${PKG_LIBS}
|
| # Checks for programs.
| AC_PROG_CC
| # Check for OpenMP
| AC_OPENMP
|
| # since some systems have broken OMP libraries
| # we also check that the actual package will work
| ac_pkg_openmp=no
| if test -n ${OPENMP_CFLAGS}; then
| AC_MSG_CHECKING([whether OpenMP will work in a package])
| AC_LANG_CONFTEST(
| [AC_LANG_PROGRAM([[#include omp.h]], [[ return omp_get_num_threads ();
]])])
| PKG_CFLAGS=${OPENMP_CFLAGS} PKG_LIBS=${OPENMP_CFLAGS} $RBIN CMD SHLIB
conftest.c 1AS_MESSAGE_LOG_FD 2AS_MESSAGE_LOG_FD $RBIN --vanilla -q -e
dyn.load(paste('conftest',.Platform\$dynlib.ext,sep='')) 1AS_MESSAGE_LOG_FD
2AS_MESSAGE_LOG_FD ac_pkg_openmp=yes
| AC_MSG_RESULT([${ac_pkg_openmp}])
| fi
|
| # if ${ac_pkg_openmp} = yes then we have OMP, otherwise it will be no
| if test ${ac_pkg_openmp} = no; then
| OPENMP_CFLAGS=''
| # you could put AC_MSG_ERROR here is OpenMP is required
| fi
|
| AC_SUBST(OPENMP_CFLAGS)
|
| AC_CONFIG_FILES([src/Makevars])
| AC_OUTPUT
|
| And your Makevars.in will probably look something like:
|
| pkg_cppfla...@openmp_cflags@
| pkg_li...@openmp_cflags@ @LIBS@
|
| Cheers,
| Simon
|
|
| * - compiler version checks are sometime used directly in the source files as
a work-around if autoconf cannot be used. But since autoconf provides an easy
way to test functionality you should do that instead if available.
|
| On Sep 14, 2010, at 7:40 AM, Dirk Eddelbuettel wrote:
|
|
| On 14 September 2010 at 11:06, Karl Forner wrote:
| | I've written a package that may use OpenMP to speed up computations.
OpenMP
| | is supported in recent Gcc versions by using the -fopenmp flag.
| | The problem is that flag crashed gcc versions that do not support OpenMP.
| | So what is the best way for a package to handle this issue. Has someone a
| | configure script that deals with this ?
|
| I don't know off-hand of any CRAN packages that do that, but you could look
| at Luke Tierney's pnmath package which uses Open MP. It may have a test.
|
| Else, you can query gcc for minimum versions. I have some configure code
from
| way back when then tested for a minimum version of 3.0 (!!):
|
| # We are using C++
| AC_LANG(C++)
| AC_REQUIRE_CPP
|
| AC_PROG_CXX
| if test ${GXX} = yes; then
| gxx_version=`${CXX} -v 21 | grep ^.*g.. version | \\
| sed -e 's/^.*g.. version *//'`
| case ${gxx_version} in
| 1.*|2.*)
| AC_MSG_WARN([Only g++ version 3.0 or greater can be used with
RQuantib.])
| AC_MSG_ERROR([Please use a different compiler.])
| ;;
| esac
| fi
|
| You could do the same for gcc and strip out major version (4) and minor (0
or
| 1) and then complain. With 4.2 you should be fine.
|
| Dirk
|
| --
| Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com
|
| __
| R-devel@r-project.org mailing list
| https://stat.ethz.ch/mailman/listinfo/r-devel
|
|
|
--
Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] More strange R CMD build/check errors on Windows
Hi Uwe, On 09/14/2010 04:49 AM, Uwe Ligges wrote: On 12.09.2010 12:10, Hervé Pagès wrote: Hi Peter, On 09/12/2010 01:51 AM, Peter Dalgaard wrote: On 09/12/2010 08:10 AM, Hervé Pagès wrote: ... AFAICT those problems were never seen before (i.e. with R 2.12). They show up randomly everyday for a small number of packages (between 10 and 20 out of 400). The set of victims changes everyday and any package seems to be a potential victim (I've not been able to observe any obvious pattern so far). Does anyone have any idea what could make 'R CMD build' and 'R CMD check' so confused/unreliable on Windows? Brian had some ideas that the problems are related to the shell that is used. Is the problem still apparent in a very recent R-devel from few days ago? I am just back from vacations and have not updated yet. I experienced the same problems and I am just iterating automatically if typical problems are apparent from the log files. I hope some if not all parts are solved now and will do some new test runs shortly. Sounds good. I just upgraded to R-2.12 (2010-09-13 r52905) on our 32-bit Windows machine and I'll report here tomorrow after the next build run has completed. I can already see that this new R solves the issue I reported here: https://stat.ethz.ch/pipermail/r-devel/2010-September/058460.html Thanks! H. Best, Uwe Thanks, H. Antivirus software? I suspect you already ruled that out, but it has been the culprit for problems with mysteriously disappearing intermediate files in several cases, so I thought I'd mention it. Actually I didn't try that yet because we still build BioC release (using R-2.11.1) on these 2 Windows boxes and we don't see any of those problems for the release builds. But I will. Could it be that the fact that 'R CMD build' and 'R CMD check' are R-based in R-2.12 (and not Perl-based anymore) make them more fragile when something like an antivirus is messing around with the filesystem? Thanks for the suggestion, H. -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M2-B876 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fhcrc.org Phone: (206) 667-5791 Fax:(206) 667-1319 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem with WARNING...headers with CRLF line endings
Dear Bill, It would be great if this warning message could at least be suppressed on Windows. Best regards Christian On 9/14/10 2:06 AM, William Dunlap wrote: -Original Message- From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org] On Behalf Of cstrato Sent: Monday, September 13, 2010 2:08 PM To: r-devel@r-project.org Subject: [Rd] Problem with WARNING...headers with CRLF line endings Dear all, When running R CMD check on Windows XP to test my package I get the following warning message: * checking line endings in C/C++/Fortran sources/headers ... WARNING Found the following sources/headers with CR or CRLF line endings: src/xpsDict.h The problem is that this file is created by the compiler AUTOMATICALLY during the compilation process, and since the file is created by VC++ on WinXP, it will always have CRLF line endings. Thus my question is: - Is it really necessary to issues this warning message? - If yes, could it be suppressed on Windows XP, since there it should obviously be no problem. Older versions of Sun C compilers would refuse to compile code with Windows-style line endings. I don't know if that is still the case. One reason to run check is to see if there are any platform-dependencies in code on CRAN so the warning should not be suppressed. (The S+ package system tries to avoid the problem by changing line endings on text files when it compiles the package. It is not trivial to reliably figure out which files are meant to be text files.) Bill Dunlap Spotfire, TIBCO Software wdunlap tibco.com One more issue: While I have always received this warning on my WinXP installation, for some lucky reason the warning did until now not appear on the Bioconductor Windows server, see BioC 2.6 with R-2.11.1: http://bioconductor.org/checkResults/2.6/bioc-LATEST/xps/liver pool-checksrc.html However, for some reason on BioC 2.7 running R-2.12.0 this warning does appear, see: http://bioconductor.org/checkResults/2.7/bioc-LATEST/xps/liver pool-checksrc.html For this reason I would appreciate if there would be a possibility to suppress this warning message. Thank you in advance. Best regards Christian _._._._._._._._._._._._._._._._._._ C.h.r.i.s.t.i.a.n S.t.r.a.t.o.w.a V.i.e.n.n.a A.u.s.t.r.i.a e.m.a.i.l:cstrato at aon.at _._._._._._._._._._._._._._._._._._ __ 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] Problem with WARNING...headers with CRLF line endings
Dear Dirk, Thank you for this suggestion, however I have no idea where this code could be used. As I have said, this file is created automatically during the compilation by the compiler, and I have no idea at which point R CMD check does check for CRLF line endings, and how to interfere with this step. Do you have any ideas? Best regards Christian On 9/13/10 11:31 PM, Dirk Eddelbuettel wrote: On 13 September 2010 at 23:07, cstrato wrote: | Dear all, | | When running R CMD check on Windows XP to test my package I get the | following warning message: | | * checking line endings in C/C++/Fortran sources/headers ... WARNING | Found the following sources/headers with CR or CRLF line endings: |src/xpsDict.h | | The problem is that this file is created by the compiler AUTOMATICALLY | during the compilation process, and since the file is created by VC++ on | WinXP, it will always have CRLF line endings. | | Thus my question is: | - Is it really necessary to issues this warning message? | - If yes, could it be suppressed on Windows XP, since there it should | obviously be no problem. | | One more issue: | While I have always received this warning on my WinXP installation, for | some lucky reason the warning did until now not appear on the | Bioconductor Windows server, see BioC 2.6 with R-2.11.1: | http://bioconductor.org/checkResults/2.6/bioc-LATEST/xps/liverpool-checksrc.html | | However, for some reason on BioC 2.7 running R-2.12.0 this warning does | appear, see: | http://bioconductor.org/checkResults/2.7/bioc-LATEST/xps/liverpool-checksrc.html | For this reason I would appreciate if there would be a possibility to | suppress this warning message. I once had the warning to in project and just added another filtering step using this ## simple 0d 0a - 0a converter to suppress a warning on Windows filename- commandArgs(trailingOnly=TRUE)[1] if (!file.exists(filename)) q() con- file(filename, rb) bin- readBin(con, raw(), 10) bin- bin[ which(bin != 0d) ] close(con) Sys.sleep(1) con- file(filename, wb) writeBin(bin, con) close(con) Maybe you can use something like this and have the generated file transformed. Dirk __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build cannot create vignettes on Windows if Makefile is used
Duncan, On 09/13/2010 11:47 AM, Duncan Murdoch wrote: On 13/09/2010 2:38 PM, Hervé Pagès wrote: [...] Thanks for suggesting workarounds but don't you think there is a real problem? As I said, we don't use TEXINPUTS on Windows, we use the command line version. I didn't write the code, so I don't know why there's the difference, but I assume there's a reason for it, and presumably the reason is that relying on TEXINPUTS doesn't work. This is fixed in current R-devel. Cheers, H. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build cannot create vignettes on Windows if Makefile is used
On 14/09/2010 2:46 PM, Hervé Pagès wrote: Duncan, On 09/13/2010 11:47 AM, Duncan Murdoch wrote: On 13/09/2010 2:38 PM, Hervé Pagès wrote: [...] Thanks for suggesting workarounds but don't you think there is a real problem? As I said, we don't use TEXINPUTS on Windows, we use the command line version. I didn't write the code, so I don't know why there's the difference, but I assume there's a reason for it, and presumably the reason is that relying on TEXINPUTS doesn't work. This is fixed in current R-devel. That explains my confusion. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] value returned by by()
On Tue, 14 Sep 2010 12:02:04 +0200, Uwe Ligges lig...@statistik.tu-dortmund.de wrote: It returns a list with athe class attribut set to by, just use: x - by(.) unclass(x) Thanks Uwe, however, that still returns an array when using the data.frame method for by(): R class(unclass(with(warpbreaks, by(warpbreaks[, 1:2], tension, summary [1] array It seems as if the only way to really ensure a list: R class(lapply(unclass(with(warpbreaks, by(warpbreaks[, 1:2], tension, summary))), function(x) x)) [1] list but it seems like a waste to call another function just to do this. -- Seb __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem with WARNING...headers with CRLF line endings
On Sep 14, 2010, at 2:27 PM, cstrato wrote: Dear Bill, It would be great if this warning message could at least be suppressed on Windows. I think you're missing the point - you should be fixing that file instead - it doesn't matter whether you're on Windows or not. If the file is created automatically then it has no business being in the package. Otherwise you should simply post-process it (e.g., as Dirk suggested) after it has been generated but before you create the package - that is the common practice with generated files that need to be part of the distribution. Cheers, Simon On 9/14/10 2:06 AM, William Dunlap wrote: -Original Message- From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org] On Behalf Of cstrato Sent: Monday, September 13, 2010 2:08 PM To: r-devel@r-project.org Subject: [Rd] Problem with WARNING...headers with CRLF line endings Dear all, When running R CMD check on Windows XP to test my package I get the following warning message: * checking line endings in C/C++/Fortran sources/headers ... WARNING Found the following sources/headers with CR or CRLF line endings: src/xpsDict.h The problem is that this file is created by the compiler AUTOMATICALLY during the compilation process, and since the file is created by VC++ on WinXP, it will always have CRLF line endings. Thus my question is: - Is it really necessary to issues this warning message? - If yes, could it be suppressed on Windows XP, since there it should obviously be no problem. Older versions of Sun C compilers would refuse to compile code with Windows-style line endings. I don't know if that is still the case. One reason to run check is to see if there are any platform-dependencies in code on CRAN so the warning should not be suppressed. (The S+ package system tries to avoid the problem by changing line endings on text files when it compiles the package. It is not trivial to reliably figure out which files are meant to be text files.) Bill Dunlap Spotfire, TIBCO Software wdunlap tibco.com One more issue: While I have always received this warning on my WinXP installation, for some lucky reason the warning did until now not appear on the Bioconductor Windows server, see BioC 2.6 with R-2.11.1: http://bioconductor.org/checkResults/2.6/bioc-LATEST/xps/liver pool-checksrc.html However, for some reason on BioC 2.7 running R-2.12.0 this warning does appear, see: http://bioconductor.org/checkResults/2.7/bioc-LATEST/xps/liver pool-checksrc.html For this reason I would appreciate if there would be a possibility to suppress this warning message. Thank you in advance. Best regards Christian _._._._._._._._._._._._._._._._._._ C.h.r.i.s.t.i.a.n S.t.r.a.t.o.w.a V.i.e.n.n.a A.u.s.t.r.i.a e.m.a.i.l:cstrato at aon.at _._._._._._._._._._._._._._._._._._ __ 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] Problem with WARNING...headers with CRLF line endings
Dear Simon, Thank you for this clarification/suggestion, however I am confused. What do you mean with If the file is created automatically then it has no business being in the package.? If you download the source code of my package from: http://bioconductor.org/packages/2.7/bioc/html/xps.html you will see that this file is not in the package. However, I could indeed add the corrected files xpsDict.h and xpsDict.cxx to the source code of my package. There is only one problem. Currently the source code xps_1.9.6.tar.gz has a total size of 4MB. Adding the corrected files will add another 4MB to the source code. Best regards Christian On 9/14/10 9:59 PM, Simon Urbanek wrote: On Sep 14, 2010, at 2:27 PM, cstrato wrote: Dear Bill, It would be great if this warning message could at least be suppressed on Windows. I think you're missing the point - you should be fixing that file instead - it doesn't matter whether you're on Windows or not. If the file is created automatically then it has no business being in the package. Otherwise you should simply post-process it (e.g., as Dirk suggested) after it has been generated but before you create the package - that is the common practice with generated files that need to be part of the distribution. Cheers, Simon On 9/14/10 2:06 AM, William Dunlap wrote: -Original Message- From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org] On Behalf Of cstrato Sent: Monday, September 13, 2010 2:08 PM To: r-devel@r-project.org Subject: [Rd] Problem with WARNING...headers with CRLF line endings Dear all, When running R CMD check on Windows XP to test my package I get the following warning message: * checking line endings in C/C++/Fortran sources/headers ... WARNING Found the following sources/headers with CR or CRLF line endings: src/xpsDict.h The problem is that this file is created by the compiler AUTOMATICALLY during the compilation process, and since the file is created by VC++ on WinXP, it will always have CRLF line endings. Thus my question is: - Is it really necessary to issues this warning message? - If yes, could it be suppressed on Windows XP, since there it should obviously be no problem. Older versions of Sun C compilers would refuse to compile code with Windows-style line endings. I don't know if that is still the case. One reason to run check is to see if there are any platform-dependencies in code on CRAN so the warning should not be suppressed. (The S+ package system tries to avoid the problem by changing line endings on text files when it compiles the package. It is not trivial to reliably figure out which files are meant to be text files.) Bill Dunlap Spotfire, TIBCO Software wdunlap tibco.com One more issue: While I have always received this warning on my WinXP installation, for some lucky reason the warning did until now not appear on the Bioconductor Windows server, see BioC 2.6 with R-2.11.1: http://bioconductor.org/checkResults/2.6/bioc-LATEST/xps/liver pool-checksrc.html However, for some reason on BioC 2.7 running R-2.12.0 this warning does appear, see: http://bioconductor.org/checkResults/2.7/bioc-LATEST/xps/liver pool-checksrc.html For this reason I would appreciate if there would be a possibility to suppress this warning message. Thank you in advance. Best regards Christian _._._._._._._._._._._._._._._._._._ C.h.r.i.s.t.i.a.n S.t.r.a.t.o.w.a V.i.e.n.n.a A.u.s.t.r.i.a e.m.a.i.l:cstrato at aon.at _._._._._._._._._._._._._._._._._._ __ 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] Problem with WARNING...headers with CRLF line endings
Hi Christian, On 09/14/2010 02:12 PM, cstrato wrote: Dear Simon, Thank you for this clarification/suggestion, however I am confused. What do you mean with If the file is created automatically then it has no business being in the package.? He means it shouldn't be in the source tarball. We run 'R CMD check' on source trees or source tarballs. Source tarballs are platform independent. If I understand correctly when you run 'R CMD build' on your source tree, you use some trick to generate this src/xpsDict.h file on Windows and this file ends up in the source tarball. But the source tarball created on Linux won't have this file. That doesn't sound like a good thing to me to have the content of the source tarball depending on the machine you've run 'R CMD build'. In other words, you should try to generate this src/xpsDict.h file at installation time but it shouldn't end up in the source tarball. My 2 cents... Cheers, H. If you download the source code of my package from: http://bioconductor.org/packages/2.7/bioc/html/xps.html you will see that this file is not in the package. However, I could indeed add the corrected files xpsDict.h and xpsDict.cxx to the source code of my package. There is only one problem. Currently the source code xps_1.9.6.tar.gz has a total size of 4MB. Adding the corrected files will add another 4MB to the source code. Best regards Christian On 9/14/10 9:59 PM, Simon Urbanek wrote: On Sep 14, 2010, at 2:27 PM, cstrato wrote: Dear Bill, It would be great if this warning message could at least be suppressed on Windows. I think you're missing the point - you should be fixing that file instead - it doesn't matter whether you're on Windows or not. If the file is created automatically then it has no business being in the package. Otherwise you should simply post-process it (e.g., as Dirk suggested) after it has been generated but before you create the package - that is the common practice with generated files that need to be part of the distribution. Cheers, Simon On 9/14/10 2:06 AM, William Dunlap wrote: -Original Message- From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org] On Behalf Of cstrato Sent: Monday, September 13, 2010 2:08 PM To: r-devel@r-project.org Subject: [Rd] Problem with WARNING...headers with CRLF line endings Dear all, When running R CMD check on Windows XP to test my package I get the following warning message: * checking line endings in C/C++/Fortran sources/headers ... WARNING Found the following sources/headers with CR or CRLF line endings: src/xpsDict.h The problem is that this file is created by the compiler AUTOMATICALLY during the compilation process, and since the file is created by VC++ on WinXP, it will always have CRLF line endings. Thus my question is: - Is it really necessary to issues this warning message? - If yes, could it be suppressed on Windows XP, since there it should obviously be no problem. Older versions of Sun C compilers would refuse to compile code with Windows-style line endings. I don't know if that is still the case. One reason to run check is to see if there are any platform-dependencies in code on CRAN so the warning should not be suppressed. (The S+ package system tries to avoid the problem by changing line endings on text files when it compiles the package. It is not trivial to reliably figure out which files are meant to be text files.) Bill Dunlap Spotfire, TIBCO Software wdunlap tibco.com One more issue: While I have always received this warning on my WinXP installation, for some lucky reason the warning did until now not appear on the Bioconductor Windows server, see BioC 2.6 with R-2.11.1: http://bioconductor.org/checkResults/2.6/bioc-LATEST/xps/liver pool-checksrc.html However, for some reason on BioC 2.7 running R-2.12.0 this warning does appear, see: http://bioconductor.org/checkResults/2.7/bioc-LATEST/xps/liver pool-checksrc.html For this reason I would appreciate if there would be a possibility to suppress this warning message. Thank you in advance. Best regards Christian _._._._._._._._._._._._._._._._._._ C.h.r.i.s.t.i.a.n S.t.r.a.t.o.w.a V.i.e.n.n.a A.u.s.t.r.i.a e.m.a.i.l: cstrato at aon.at _._._._._._._._._._._._._._._._._._ __ 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 -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M2-B876 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fhcrc.org Phone: (206) 667-5791 Fax:(206) 667-1319 __ R-devel@r-project.org
Re: [Rd] Problem with WARNING...headers with CRLF line endings
Dear Herve, Thank you for your reply, however maybe I was not quite clear. The files xpsDict.h and xpsDict.cxx are automatically created by the ROOT framework during compilation on every architecture. This means they are created on Linux and Mac with LF line endings, but on Windows with CRLF line endings. However, they are created only if they do not already exist, and thus are not in the source tarball. For testing purposes I have just added both files with LF line endings to the source tarball and compiled it on Windows w/o problems. Furthermore, the size of xps_1.9.6.tar.gz increases only from 4MB to 4.3MB. Thus in principle I could upload both files to SVN for BioC 2.7, and this should eliminate the warning message. What is your opinion? Best regards Christian On 9/14/10 11:32 PM, Hervé Pagès wrote: Hi Christian, On 09/14/2010 02:12 PM, cstrato wrote: Dear Simon, Thank you for this clarification/suggestion, however I am confused. What do you mean with If the file is created automatically then it has no business being in the package.? He means it shouldn't be in the source tarball. We run 'R CMD check' on source trees or source tarballs. Source tarballs are platform independent. If I understand correctly when you run 'R CMD build' on your source tree, you use some trick to generate this src/xpsDict.h file on Windows and this file ends up in the source tarball. But the source tarball created on Linux won't have this file. That doesn't sound like a good thing to me to have the content of the source tarball depending on the machine you've run 'R CMD build'. In other words, you should try to generate this src/xpsDict.h file at installation time but it shouldn't end up in the source tarball. My 2 cents... Cheers, H. If you download the source code of my package from: http://bioconductor.org/packages/2.7/bioc/html/xps.html you will see that this file is not in the package. However, I could indeed add the corrected files xpsDict.h and xpsDict.cxx to the source code of my package. There is only one problem. Currently the source code xps_1.9.6.tar.gz has a total size of 4MB. Adding the corrected files will add another 4MB to the source code. Best regards Christian On 9/14/10 9:59 PM, Simon Urbanek wrote: On Sep 14, 2010, at 2:27 PM, cstrato wrote: Dear Bill, It would be great if this warning message could at least be suppressed on Windows. I think you're missing the point - you should be fixing that file instead - it doesn't matter whether you're on Windows or not. If the file is created automatically then it has no business being in the package. Otherwise you should simply post-process it (e.g., as Dirk suggested) after it has been generated but before you create the package - that is the common practice with generated files that need to be part of the distribution. Cheers, Simon On 9/14/10 2:06 AM, William Dunlap wrote: -Original Message- From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org] On Behalf Of cstrato Sent: Monday, September 13, 2010 2:08 PM To: r-devel@r-project.org Subject: [Rd] Problem with WARNING...headers with CRLF line endings Dear all, When running R CMD check on Windows XP to test my package I get the following warning message: * checking line endings in C/C++/Fortran sources/headers ... WARNING Found the following sources/headers with CR or CRLF line endings: src/xpsDict.h The problem is that this file is created by the compiler AUTOMATICALLY during the compilation process, and since the file is created by VC++ on WinXP, it will always have CRLF line endings. Thus my question is: - Is it really necessary to issues this warning message? - If yes, could it be suppressed on Windows XP, since there it should obviously be no problem. Older versions of Sun C compilers would refuse to compile code with Windows-style line endings. I don't know if that is still the case. One reason to run check is to see if there are any platform-dependencies in code on CRAN so the warning should not be suppressed. (The S+ package system tries to avoid the problem by changing line endings on text files when it compiles the package. It is not trivial to reliably figure out which files are meant to be text files.) Bill Dunlap Spotfire, TIBCO Software wdunlap tibco.com One more issue: While I have always received this warning on my WinXP installation, for some lucky reason the warning did until now not appear on the Bioconductor Windows server, see BioC 2.6 with R-2.11.1: http://bioconductor.org/checkResults/2.6/bioc-LATEST/xps/liver pool-checksrc.html However, for some reason on BioC 2.7 running R-2.12.0 this warning does appear, see: http://bioconductor.org/checkResults/2.7/bioc-LATEST/xps/liver pool-checksrc.html For this reason I would appreciate if there would be a possibility to suppress this warning message. Thank you in advance. Best regards Christian _._._._._._._._._._._._._._._._._._ C.h.r.i.s.t.i.a.n
Re: [Rd] Problem with WARNING...headers with CRLF line endings
On 09/14/2010 02:58 PM, cstrato wrote: Dear Herve, Thank you for your reply, however maybe I was not quite clear. The files xpsDict.h and xpsDict.cxx are automatically created by the ROOT framework during compilation on every architecture. on every architecture... ok But if they are created during compilation, why do they need to be included in the source tarball? They are just temporary files right? Or I'm missing something... This means they are created on Linux and Mac with LF line endings, but on Windows with CRLF line endings. However, they are created only if they do not already exist, and thus are not in the source tarball. I guess you mean they are not part of the source *tree*. For testing purposes I have just added both files with LF line endings to the source tarball and compiled it on Windows w/o problems. Furthermore, the size of xps_1.9.6.tar.gz increases only from 4MB to 4.3MB. Thus in principle I could upload both files to SVN for BioC 2.7, and this should eliminate the warning message. What is your opinion? I still don't understand why you want to have them in the source tarball. H. Best regards Christian On 9/14/10 11:32 PM, Hervé Pagès wrote: Hi Christian, On 09/14/2010 02:12 PM, cstrato wrote: Dear Simon, Thank you for this clarification/suggestion, however I am confused. What do you mean with If the file is created automatically then it has no business being in the package.? He means it shouldn't be in the source tarball. We run 'R CMD check' on source trees or source tarballs. Source tarballs are platform independent. If I understand correctly when you run 'R CMD build' on your source tree, you use some trick to generate this src/xpsDict.h file on Windows and this file ends up in the source tarball. But the source tarball created on Linux won't have this file. That doesn't sound like a good thing to me to have the content of the source tarball depending on the machine you've run 'R CMD build'. In other words, you should try to generate this src/xpsDict.h file at installation time but it shouldn't end up in the source tarball. My 2 cents... Cheers, H. If you download the source code of my package from: http://bioconductor.org/packages/2.7/bioc/html/xps.html you will see that this file is not in the package. However, I could indeed add the corrected files xpsDict.h and xpsDict.cxx to the source code of my package. There is only one problem. Currently the source code xps_1.9.6.tar.gz has a total size of 4MB. Adding the corrected files will add another 4MB to the source code. Best regards Christian On 9/14/10 9:59 PM, Simon Urbanek wrote: On Sep 14, 2010, at 2:27 PM, cstrato wrote: Dear Bill, It would be great if this warning message could at least be suppressed on Windows. I think you're missing the point - you should be fixing that file instead - it doesn't matter whether you're on Windows or not. If the file is created automatically then it has no business being in the package. Otherwise you should simply post-process it (e.g., as Dirk suggested) after it has been generated but before you create the package - that is the common practice with generated files that need to be part of the distribution. Cheers, Simon On 9/14/10 2:06 AM, William Dunlap wrote: -Original Message- From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org] On Behalf Of cstrato Sent: Monday, September 13, 2010 2:08 PM To: r-devel@r-project.org Subject: [Rd] Problem with WARNING...headers with CRLF line endings Dear all, When running R CMD check on Windows XP to test my package I get the following warning message: * checking line endings in C/C++/Fortran sources/headers ... WARNING Found the following sources/headers with CR or CRLF line endings: src/xpsDict.h The problem is that this file is created by the compiler AUTOMATICALLY during the compilation process, and since the file is created by VC++ on WinXP, it will always have CRLF line endings. Thus my question is: - Is it really necessary to issues this warning message? - If yes, could it be suppressed on Windows XP, since there it should obviously be no problem. Older versions of Sun C compilers would refuse to compile code with Windows-style line endings. I don't know if that is still the case. One reason to run check is to see if there are any platform-dependencies in code on CRAN so the warning should not be suppressed. (The S+ package system tries to avoid the problem by changing line endings on text files when it compiles the package. It is not trivial to reliably figure out which files are meant to be text files.) Bill Dunlap Spotfire, TIBCO Software wdunlap tibco.com One more issue: While I have always received this warning on my WinXP installation, for some lucky reason the warning did until now not appear on the Bioconductor Windows server, see BioC 2.6 with R-2.11.1: http://bioconductor.org/checkResults/2.6/bioc-LATEST/xps/liver pool-checksrc.html However, for
Re: [Rd] Problem with WARNING...headers with CRLF line endings
On 14/09/2010 6:08 PM, Hervé Pagès wrote: On 09/14/2010 02:58 PM, cstrato wrote: Dear Herve, Thank you for your reply, however maybe I was not quite clear. The files xpsDict.h and xpsDict.cxx are automatically created by the ROOT framework during compilation on every architecture. on every architecture... ok But if they are created during compilation, why do they need to be included in the source tarball? They are just temporary files right? Or I'm missing something... This means they are created on Linux and Mac with LF line endings, but on Windows with CRLF line endings. However, they are created only if they do not already exist, and thus are not in the source tarball. I guess you mean they are not part of the source *tree*. For testing purposes I have just added both files with LF line endings to the source tarball and compiled it on Windows w/o problems. Furthermore, the size of xps_1.9.6.tar.gz increases only from 4MB to 4.3MB. Thus in principle I could upload both files to SVN for BioC 2.7, and this should eliminate the warning message. What is your opinion? I still don't understand why you want to have them in the source tarball. I think he doesn't want to put them in the source tarball, but because of the way R CMD check works, he may have to. It appears that R CMD check builds those files, and then checks for CRLF endings on all files. If it did the CRLF check first, it wouldn't see them and complain. The problem with this change is that some packages might create files with CRLF endings on all platforms, and then check *should* complain about them. My advice would be not to put them in the tarball, and ignore the warning. Or write a Makevars.win that fixes the line endings so that check is happy. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem with WARNING...headers with CRLF line endings
On 09/14/2010 03:30 PM, Duncan Murdoch wrote: On 14/09/2010 6:08 PM, Hervé Pagès wrote: On 09/14/2010 02:58 PM, cstrato wrote: Dear Herve, Thank you for your reply, however maybe I was not quite clear. The files xpsDict.h and xpsDict.cxx are automatically created by the ROOT framework during compilation on every architecture. on every architecture... ok But if they are created during compilation, why do they need to be included in the source tarball? They are just temporary files right? Or I'm missing something... This means they are created on Linux and Mac with LF line endings, but on Windows with CRLF line endings. However, they are created only if they do not already exist, and thus are not in the source tarball. I guess you mean they are not part of the source *tree*. For testing purposes I have just added both files with LF line endings to the source tarball and compiled it on Windows w/o problems. Furthermore, the size of xps_1.9.6.tar.gz increases only from 4MB to 4.3MB. Thus in principle I could upload both files to SVN for BioC 2.7, and this should eliminate the warning message. What is your opinion? I still don't understand why you want to have them in the source tarball. I think he doesn't want to put them in the source tarball, but because of the way R CMD check works, he may have to. It appears that R CMD check builds those files, and then checks for CRLF endings on all files. If it did the CRLF check first, it wouldn't see them and complain. The problem with this change is that some packages might create files with CRLF endings on all platforms, and then check *should* complain about them. I see your point but, on the other hand, and more generally speaking, you expect 'R CMD check' to check the source files i.e. the files that belong to the source tarball, and not temporary compilation/installation products that 'R CMD INSTALL' didn't remove (for whatever reason). It's weird to get a message like: * checking line endings in C/C++/Fortran sources/headers ... WARNING Found the following sources/headers with CR or CRLF line endings: src/xpsDict.h if there is no such file in the source tarball. My advice would be not to put them in the tarball, and ignore the warning. Or write a Makevars.win that fixes the line endings so that check is happy. Yes and since he already uses a Makefile, it should be easy to remove those files at the end of installation so they don't end up in the tarball anymore. Wouldn't that also be enough to silent 'R CMD check'? Perhaps package authors should really make sure that src/ gets cleaned after the installation step of 'R CMD build' (this step is performed only if the package has vignettes). Then it shouldn't matter whether 'R CMD check' checks for CRLF endings after or before installing the package. Cheers, H. Duncan Murdoch -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M2-B876 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fhcrc.org Phone: (206) 667-5791 Fax:(206) 667-1319 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] warning or error upon type/storage mode coercion?
Hi, I'm aware that the language definition states R objects are often coerced to different types during computations. Two questions: 1. Is it possible to configure the R environment so that, for example, coercion from (say) numeric to integer will throw a warning or an error? I realize that in the base R code alone, there are thousands of calls to as.integer() which would trigger such an event, so this would not be a very practical configuration... 2. So, assuming the answer to (1) is a resounding no, does anyone care to state an opinion regarding the philosophical or historical rationale for why this is the case in R/S, whereas certain other interpreted languages offer the option to perform strict type checking? Basically, I'm trying to explain to someone from a perl background why the (apparent) lack of a use strict; use warnings; equivalent is not a hindrance to writing bullet-proof R code. Thanks, Ben __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Suggestion: Add DESCRIPTION 'Date' to R CMD check log header
Hi,
in R CMD check, the version of the package being checked is reported, e.g.
Thu Sep 9 05:02:30 2010: Checking package R.utils (SVN revision 399) ...
* using log directory ‘/srv/R/R.check/R-devel/PKGS/R.utils.Rcheck’
* using R version 2.12.0 Under development (unstable) (2010-09-07 r52876)
* using platform: x86_64-unknown-linux-gnu (64-bit)
* using session charset: UTF-8
* checking for file ‘R.utils/DESCRIPTION’ ... OK
* this is package ‘R.utils’ version ‘1.5.2’
...
I'd like to request/suggest that the 'Date' in the DESCRIPTION file is
also added, e.g.
* this is package ‘R.utils’ version ‘1.5.2’ ('2010-09-14')
WHY?
This would be particular useful when you work toward sites like
R-forge and Bioconductor when you may commit your day's work on
package when you update the 'Date' but you do not really want to
update the 'Version' because you're going to put in more work
tomorrow. With the 'Date' information you'll be able to see what
version of your updates have been checked by the servers. I
understand that this may be an odd process to follow even for devel
branches and you may argue that you should always bump the version
number whenever you do an SVN commit (e.g. '1.5.2.1' for temporary
commits). Either way, I find it useful to see the date as well.
Thxs
Henrik
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] warning or error upon type/storage mode coercion?
On Tue, Sep 14, 2010 at 6:23 PM, Benjamin Tyner bty...@gmail.com wrote: Hi, I'm aware that the language definition states R objects are often coerced to different types during computations. Two questions: 1. Is it possible to configure the R environment so that, for example, coercion from (say) numeric to integer will throw a warning or an error? I realize that in the base R code alone, there are thousands of calls to as.integer() which would trigger such an event, so this would not be a very practical configuration... 2. So, assuming the answer to (1) is a resounding no, does anyone care to state an opinion regarding the philosophical or historical rationale for why this is the case in R/S, whereas certain other interpreted languages offer the option to perform strict type checking? Basically, I'm trying to explain to someone from a perl background why the (apparent) lack of a use strict; use warnings; equivalent is not a hindrance to writing bullet-proof R code. For what's it's worth: it is only recently (only some R releases ago) that the language/parser gained the syntax for specifying an integer, e.g. 2L. I guess, before this the only option you had to get an integer was through coercion, e.g. as.integer(2), storage.mode(), but also tricks such as 2:2. So in some sense from the parsers point of view, everything was doubles in the beginning. (disclaimer: I might be missing something). My $.02 /Henrik PS. OT, but reading help(:) I just learned that a:b is not always the same as rev(b:a). Thanks, Ben __ 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
