[Rd] read.table() causes segfault with incorrect data (PR#11627)
Full_Name: Juho Vuori Version: 2.7.0 (2008-04-22) OS: Linux poseidon.fimr.fi 2.6.23.17-88.fc7PAE #1 SMP Thu May 15 00:22:53 EDT 2008 i686 i686 i386 GNU/Linux Submission from: (NULL) (193.166.188.194) Calling read.table() twice the following way causes a segmentation fault in R. Run R and type the following commands: > read.table(stdin()) 0: 1 2 3 1: 3 2: Error in scan(file, what, nmax, sep, dec, quote, skip, nlines, na.strings, : line 2 did not have 3 elements > read.table(stdin()) *** caught segfault *** address 0x64616572, cause 'memory not mapped' Traceback: 1: read.table(stdin()) Segmentation fault only occurs if the first call failed due to incorrect data. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] write.table (PR#11625)
Hi,=20
=20
I am writing to suggest a change in write.table(). Currently one
feature of this function is so counter-intuitive that it could be
considered to be a bug. I use R 2.6.1 under Windows XP.=20=20
=20
When appending to a file, write.table() automatically writes the column
names first, even though this means writing the variable names in the
middle of a column of numeric values. The function gives a warning but
if you have the function in a loop then usually all you will see is a
non-specific message ("there were 50 or more warnings") which can be
easy to miss. In almost all cases it would make more sense for
"col.names=3DTRUE" to be interpreted to mean that the function should
print the column names if it has created the file but not otherwise, I
think.=20=20
=20
James.=20=20
=20
=20
=20
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Rmpi segfault after install on Ubuntu Hardy Heron
Does Rmpi work with OpenMPI at all? It calls lamboot on load from LAM
MPI. I would think that mpi_initialize calls a shared library function
from LAM MPI which simply does not exist in OpenMPI or which does
something different from what it expects. If you ever make Rmpi working
with OpenMPI I would be thankful for the solution. It does compile
against OpenMPI though because the header seems to be matching.
Dr Oleg Sklyar
Technology Group
Man Investments Ltd
+44 (0)20 7144 3803
[EMAIL PROTECTED]
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Mark Kimpel
> Sent: 11 June 2008 05:47
> To: [EMAIL PROTECTED]; Dirk Eddelbuettel
> Subject: [Rd] Rmpi segfault after install on Ubuntu Hardy Heron
>
> I just installed Rmpi on my 64-bit Ubuntu Hardy Heron OS and
> using the following without errors:
> "R CMD INSTALL Rmpi_0.5-5.tar.gz
> --configure-args=--with-mpi=/usr/lib64/openmpi"
>
> Immediately at library(Rmpi) I get the segfault displayed in
> my complete output below. My first thought is that perhaps I
> used the wrong library for openmpi, but with my 64 bit
> install it seemed like a logical choice and the install went
> without a hitch.
>
> Two other general comments:
> 1. Am I addressing this to the correct list or should I use
> R-help? As I read the posting guide, I'm not sure.
> 2. Has anyone considered an R-SIG-HPC list? Anyone besides me
> interested?
>
> Mark
>
>
> R version 2.7.0 Patched (2008-05-18 r45728) Copyright (C)
> 2008 The R Foundation for Statistical Computing ISBN 3-900051-07-0
>
> R is free software and comes with ABSOLUTELY NO WARRANTY.
> You are welcome to redistribute it under certain conditions.
> Type 'license()' or 'licence()' for distribution details.
>
> Natural language support but running in an English locale
>
> R is a collaborative project with many contributors.
> Type 'contributors()' for more information and 'citation()'
> on how to cite R or R packages in publications.
>
> Type 'demo()' for some demos, 'help()' for on-line help, or
> 'help.start()' for an HTML browser interface to help.
> Type 'q()' to quit R.
>
> Loading required package: datasets
> Loading required package: utils
> Loading required package: grDevices
> Loading required package: graphics
> Loading required package: stats
> Loading required package: graph
> [1] "packages do not need updated"
> > options(STERM='iESS', editor='emacsclient')
> > library("Rmpi")
>
> *** caught segfault ***
> address 0x2104008, cause 'memory not mapped'
>
> Traceback:
> 1: .Call("mpi_initialize", PACKAGE = "Rmpi")
> 2: f(libname, pkgname)
> 3: firstlib(which.lib.loc, package)
> 4: doTryCatch(return(expr), name, parentenv, handler)
> 5: tryCatchOne(expr, names, parentenv, handlers[[1]])
> 6: tryCatchList(expr, classes, parentenv, handlers)
> 7: tryCatch(expr, error = function(e) {call <- conditionCall(e)
> if (!is.null(call)) {if (identical(call[[1]],
> quote(doTryCatch))) call <- sys.call(-4)dcall <-
> deparse(call)[1]prefix <- paste("Error in", dcall, ": ")
> LONG <- 75msg <- conditionMessage(e)sm <-
> strsplit(msg, "\n")[[1]]if (14 + nchar(dcall, type = "w") +
> nchar(sm[1], type = "w") > LONG) prefix <-
> paste(prefix, "\n ", sep = "")}else prefix <- "Error : "
> msg <- paste(prefix, conditionMessage(e), "\n", sep = "")
> .Internal(seterrmessage(msg[1]))if (!silent &&
> identical(getOption("show.error.messages"), TRUE)) {
> cat(msg, file = stderr()).Internal(printDeferredWarnings())
> }invisible(structure(msg, class = "try-error"))})
> 8: try(firstlib(which.lib.loc, package))
> 9: library("Rmpi")
>
> Possible actions:
> 1: abort (with core dump, if enabled)
> 2: normal R exit
> 3: exit R without saving workspace
> 4: exit R saving workspace
> Selection:
>
> --
> Mark W. Kimpel MD ** Neuroinformatics ** Dept. of Psychiatry
> Indiana University School of Medicine
>
> 15032 Hunter Court, Westfield, IN 46074
>
> (317) 490-5129 Work, & Mobile & VoiceMail
> (317) 663-0513 Home (no voice mail please)
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
**
The contents of this email are for the named addressee(s...{{dropped:22}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Rmpi segfault after install on Ubuntu Hardy Heron
On 11 June 2008 at 10:38, Sklyar, Oleg \(MI London\) wrote: | Does Rmpi work with OpenMPI at all? It calls lamboot on load from LAM Yes. | MPI. I would think that mpi_initialize calls a shared library function | from LAM MPI which simply does not exist in OpenMPI or which does | something different from what it expects. If you ever make Rmpi working | with OpenMPI I would be thankful for the solution. It does compile | against OpenMPI though because the header seems to be matching. Debian switched in October 2007 and with Rmpi 0.5-4. Rmpi 0.5-5 definitely supports it, Hao Yu made some upstream changes. I have been using it on Ubuntu/x86 at work all that time (but then I was also testing the newer Open MPI code). You may want Open MPI 1.2.* though it may work with 1.1.* as well. Dirk -- Three out of two people have difficulties with fractions. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Posting Guide - help.request() function?
Okay, here's the update.
I've created a new function create.post() (with Windows and Unix
versions) which would be the internal function that creates the post
template ready to edit and optionally send. In the Windows version I've
added an experimental method == "mailto" option, which will open the
post template in the default mailer (e.g. Outlook) ready to edit and
post. Maybe a Unix version would also be nice, e.g.
browseURL("mailto:[EMAIL PROTECTED] bug&body=%0A>%0A%0A%0A%0A--please do not edit the information
below--%0A%0AVersion:%0A platform = x86_64-unknown-linux-gnu%0A ...")
would open the post template in e.g. Thunderbird, but has the side
effect of opening an empty page in the web browser. I don't know if
there's a neater solution?
The create.post() function is basically the old bug.report() with two
extra arguments: 'description' (e.g. "bug report") and 'instructions'
(e.g. "\\n<>\\n") for customization. It could be
used directly e.g to post to R-devel with session information.
The new bug.report() simply calls create.post() with the appropriate
arguments.
The improved help-request() function calls create.post() after running
through the checks described before.
In response to Gabor's comments, help.request():
- now checks packages are up-to-date and gives option to update
on-the-fly (user may not know whether involved in query, so check all)
- keeps default mailing options as in old bug.report() but
create.post() gives clearer message ("Email the post now?\n (yes/no)")
requiring definite response ("yes" vs "y")
- still uses online documents because some are only available online
(R Site Search, posting guide), it ensures the most up-to-date
documentation is used, and it allows direction to global FAQ page,
avoiding need to check whether user is on Windows/Mac
- uses more robust method of checking R version is up-to-date
I've also written a help file for help.request() which includes the
method="mailto" option. The help file for bug.report would need updating
if this option was kept.
Best wishes,
Heather
Martin Maechler wrote:
> "HT" == Heather Turner <[EMAIL PROTECTED]>
> on Mon, 09 Jun 2008 17:21:17 +0100 writes:
HT> Thanks for the helpful tips and suggestions, I'll work
HT> them in. You get local versions of the documents on Unix
HT> too - RShowDoc() will do the trick.
HT> I'll post an updated version in due course,
Thank you, Heather and Gabor (and the other contributors).
Indeed, I too like the idea of providing a new R function for
this.
Ideally, Heather, you'd try to "factor out" some of the common
functionality of bug.report() and help.request() into a few
utils-namespace hidden auxiliary functions.
Ideally, you'd attach text/plain attachments (base64 encoded) so
there won't be line wrap arounds.
Martin
HT> Gabor Grothendieck wrote:
>> That's an excellent idea.
>>
>> One other item that could be checkable would be if the
>> user has the most recent versions of the packages
>> involved in the query. Perhaps it could display the
>> unupdated packages and ask the user if any of those are
>> involved in the query.
>>
>> Probably needs to give fair warning that it is sending
>> off an email so people don't wind up sending out emails
>> when they are really just trying out the system.
>> Probably "none" should be the default for email so that
>> its not regarded as obnoxious.
>>
>> Might be nice if it used local versions of documents if
>> they exist locally. On Windows they do.
>>
>> Check out ?getRversion
>>
>> On Mon, Jun 9, 2008 at 10:35 AM, Dr Heather Turner
>> <[EMAIL PROTECTED]> wrote:
>>> Whilst it is a good idea to improve the posting guide,
>>> it seems to me that it would be useful to have a
>>> function along the lines of bug.report(), to help a
>>> potential questioner make sure they have done their
>>> homework and have the relevant information to put into a
>>> post to R-help.
>>>
>>> Even those of us who know what ought to go into a post
>>> can sometimes forget to check something obvious - I
>>> recently got caught out by not checking an error was
>>> reproducible in the patched version for example.
>>>
>>> So I have written a help.request() function (see below),
>>> which - prompts the user to check the relevant
>>> resources, stopping and opening the relevant url where
>>> necessary - checks their R version is up-to-date (in a
>>> rather messy way - please suggest improvements!) -
>>> prompts them to prepare appropriate example code and
>>> test it in a fresh R session - prompts them to give a
>>> meaningful subject line - automatically adds system info
>>> to the post (as in bug.report) - sends the message for
>>> them (ensuring a fresh thread is started)
>>>
>>> Is this an idea worth
Re: [Rd] Rmpi segfault after install on Ubuntu Hardy Heron
Hello,
I can confirm that Rmpi 0.5.5 works fine with openmpi 1.1
But if (a) the cluster you are running on is set up to allow spawning and (b)
you have lam-mpi installed, there is a function within zzz.R which will spawn a
lam-mpi process as well which you might need to prevent.
The package README tells you what to do to prevent lam-mpi starting up. You
either hack at the zzz.R, or you set up a file called lamnodes (I think) as a
shell script which contains echo lamnodes NULL (or similar) and put this
somewhere on your path. That tells Rmpi not to fire up lammpi, you can run it
under mpirun -np 1 -hostfile myhosts R --vanilla --slave CMD BATCH
diddlededoo.R &
Best
Paul
-=-=-==-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Paul Hewson
Lecturer in Statistics
University of Plymouth
Drake Circus
Plymouth PL4 8AA
tel ++44(0)1752 232778
email [EMAIL PROTECTED]
web http://www.plymouth.ac.uk/staff/phewson
From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Sklyar, Oleg (MI London)
[EMAIL PROTECTED]
Sent: 11 June 2008 10:38
To: Mark Kimpel; [EMAIL PROTECTED]; Dirk Eddelbuettel
Subject: Re: [Rd] Rmpi segfault after install on Ubuntu Hardy Heron
Does Rmpi work with OpenMPI at all? It calls lamboot on load from LAM
MPI. I would think that mpi_initialize calls a shared library function
from LAM MPI which simply does not exist in OpenMPI or which does
something different from what it expects. If you ever make Rmpi working
with OpenMPI I would be thankful for the solution. It does compile
against OpenMPI though because the header seems to be matching.
Dr Oleg Sklyar
Technology Group
Man Investments Ltd
+44 (0)20 7144 3803
[EMAIL PROTECTED]
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Mark Kimpel
> Sent: 11 June 2008 05:47
> To: [EMAIL PROTECTED]; Dirk Eddelbuettel
> Subject: [Rd] Rmpi segfault after install on Ubuntu Hardy Heron
>
> I just installed Rmpi on my 64-bit Ubuntu Hardy Heron OS and
> using the following without errors:
> "R CMD INSTALL Rmpi_0.5-5.tar.gz
> --configure-args=--with-mpi=/usr/lib64/openmpi"
>
> Immediately at library(Rmpi) I get the segfault displayed in
> my complete output below. My first thought is that perhaps I
> used the wrong library for openmpi, but with my 64 bit
> install it seemed like a logical choice and the install went
> without a hitch.
>
> Two other general comments:
> 1. Am I addressing this to the correct list or should I use
> R-help? As I read the posting guide, I'm not sure.
> 2. Has anyone considered an R-SIG-HPC list? Anyone besides me
> interested?
>
> Mark
>
>
> R version 2.7.0 Patched (2008-05-18 r45728) Copyright (C)
> 2008 The R Foundation for Statistical Computing ISBN 3-900051-07-0
>
> R is free software and comes with ABSOLUTELY NO WARRANTY.
> You are welcome to redistribute it under certain conditions.
> Type 'license()' or 'licence()' for distribution details.
>
> Natural language support but running in an English locale
>
> R is a collaborative project with many contributors.
> Type 'contributors()' for more information and 'citation()'
> on how to cite R or R packages in publications.
>
> Type 'demo()' for some demos, 'help()' for on-line help, or
> 'help.start()' for an HTML browser interface to help.
> Type 'q()' to quit R.
>
> Loading required package: datasets
> Loading required package: utils
> Loading required package: grDevices
> Loading required package: graphics
> Loading required package: stats
> Loading required package: graph
> [1] "packages do not need updated"
> > options(STERM='iESS', editor='emacsclient')
> > library("Rmpi")
>
> *** caught segfault ***
> address 0x2104008, cause 'memory not mapped'
>
> Traceback:
> 1: .Call("mpi_initialize", PACKAGE = "Rmpi")
> 2: f(libname, pkgname)
> 3: firstlib(which.lib.loc, package)
> 4: doTryCatch(return(expr), name, parentenv, handler)
> 5: tryCatchOne(expr, names, parentenv, handlers[[1]])
> 6: tryCatchList(expr, classes, parentenv, handlers)
> 7: tryCatch(expr, error = function(e) {call <- conditionCall(e)
> if (!is.null(call)) {if (identical(call[[1]],
> quote(doTryCatch))) call <- sys.call(-4)dcall <-
> deparse(call)[1]prefix <- paste("Error in", dcall, ": ")
> LONG <- 75msg <- conditionMessage(e)sm <-
> strsplit(msg, "\n")[[1]]if (14 + nchar(dcall, type = "w") +
> nchar(sm[1], type = "w") > LONG) prefix <-
> paste(prefix, "\n ", sep = "")}else prefix <- "Error : "
> msg <- paste(prefix, conditionMessage(e), "\n", sep = "")
> .Internal(seterrmessage(msg[1]))if (!silent &&
> identical(getOption("show.error.messages"), TRUE)) {
> cat(msg, file = stderr()).Internal(printDeferredWarnings())
> }invisible(structure(msg, class = "try-error"))})
> 8: try(firstlib(which.lib.loc, package))
> 9: library("Rmpi")
>
> Possible actions:
> 1: abort (with core dump, if enabled)
> 2: nor
Re: [Rd] Rmpi segfault after install on Ubuntu Hardy Heron
On 11 June 2008 at 00:46, Mark Kimpel wrote: | I just installed Rmpi on my 64-bit Ubuntu Hardy Heron OS and using the | following without errors: | "R CMD INSTALL Rmpi_0.5-5.tar.gz --configure-args=--with-mpi=/usr/lib64/openmpi" And it concluded without warnings or errors? Configure found all the right files? As Paul suggested, make sure you're not getting it mixed with exisiting LAM headers or MPICH2 headers or, say, that you're getting your gcc and icc experiemenst mixed up or ... ? I control this by locally re-building the Debian packages for Open MPI. That way I only keep one -dev package for MPI and can ensure that I do not get mixups with other MPI installation. But then I do buy into the Package Management mantra, but not everybody does... | Immediately at library(Rmpi) I get the segfault displayed in my | complete output below. My first thought is that perhaps I used the | wrong library for openmpi, but with my 64 bit install it seemed like a | logical choice and the install went without a hitch. Check ldd on Rmpi.so to ensure that you linked against what you thought you should link against. And if everything else fails, debug the compiled code and run R under the debuggger. See the 'R Extensions' manual. | Two other general comments: | 1. Am I addressing this to the correct list or should I use R-help? As | I read the posting guide, I'm not sure. | 2. Has anyone considered an R-SIG-HPC list? Anyone besides me interested? I'd join. Dirk -- Three out of two people have difficulties with fractions. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Posting Guide - help.request() function?
> "HT" == Heather Turner <[EMAIL PROTECTED]>
> on Wed, 11 Jun 2008 12:50:49 +0100 writes:
HT> Okay, here's the update.
HT> I've created a new function create.post() (with Windows and Unix
HT> versions) which would be the internal function that creates the post
HT> template ready to edit and optionally send. In the Windows version I've
HT> added an experimental method == "mailto" option, which will open the
HT> post template in the default mailer (e.g. Outlook) ready to edit and
HT> post. Maybe a Unix version would also be nice, e.g.
HT> browseURL("mailto:[EMAIL PROTECTED] bug&body=%0A< bug report here>>%0A%0A%0A%0A--please do not edit the information
HT> below--%0A%0AVersion:%0A platform = x86_64-unknown-linux-gnu%0A ...")
HT> would open the post template in e.g. Thunderbird, but has the side
HT> effect of opening an empty page in the web browser. I don't know if
HT> there's a neater solution?
Well, the current solution {for bug.report()} seems quite
desirable to me on unix.
HT> The create.post() function is basically the old bug.report() with two
HT> extra arguments: 'description' (e.g. "bug report") and 'instructions'
HT> (e.g. "\\n<>\\n") for customization. It could
be
HT> used directly e.g to post to R-devel with session information.
HT> The new bug.report() simply calls create.post() with the appropriate
HT> arguments.
Thank you; that's a really nice example of code reuse!
HT> The improved help-request() function calls create.post() after running
HT> through the checks described before.
HT> In response to Gabor's comments, help.request():
HT> - now checks packages are up-to-date and gives option to update
HT> on-the-fly (user may not know whether involved in query, so check all)
This is a bit problematic as now.
E.g., we have about 1500 packages installed, and inspite of automatic
updating, never all are current, and the updating should typically
not happen on a user (but a site-wide) level anyway.
Also, the call to old.packages() takes minutes (the
first time in an R session) if you have so many packages in a
dozen libraries.
This should really not interfere with an e-mail for help,
rather I think that the "packages-up-to-date check"
should only happen for those non-standard packages that are
currently in use as from sessionInfo().
Unfortunately, that functionality to do that is not yet there
in old.packages(), but I am about to add that option to R-devel
as well.
No need to send me a new version of your code, BTW, since I have
already worked on it in several places.
HT> - keeps default mailing options as in old bug.report() but
HT> create.post() gives clearer message ("Email the post now?\n (yes/no)")
HT> requiring definite response ("yes" vs "y")
ok.
HT> - still uses online documents because some are only available online
HT> (R Site Search, posting guide), it ensures the most up-to-date
HT> documentation is used, and it allows direction to global FAQ page,
HT> avoiding need to check whether user is on Windows/Mac
HT> - uses more robust method of checking R version is up-to-date
HT> I've also written a help file for help.request() which includes the
HT> method="mailto" option.
ok {it did need some correction}.
HT> The help file for bug.report would need updating
HT> if this option was kept.
I think this is mainly a windows feature (but maybe not).
I'd definitely like to get some feedback from Windows users
about this.
HT> Best wishes,
HT> Heather
Thanks again, Heather, for this.
This is becoming a very nice new feature!
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Makevars or congiure for multi platforms
Prof. Ripley, >>> Which entries were you wanting to use? In this case, I would use the followings in Rconfig.h, then I don't have to add extra settings in congure.ac #define HAVE_ERRNO_H 1 #define HAVE_ICONV 1 #define HAVE_INTPTR_T 1 #define HAVE_UINTPTR_T 1 #define ICONV_LATIN1 1 #define RETSIGTYPE void #define Unix 1 (or #define Win 1) But, I would say that If Rconfig.h contains all entries in config.h, I don't have to use congure at all. Just write #include . Regards, Tadashi Kadowaki 2008/6/11 Prof Brian Ripley <[EMAIL PROTECTED]>: > On Wed, 11 Jun 2008, Tadashi Kadowaki wrote: > >> Prof. Ripley, >> >> Yes, I can configure when I write configure.ac correctly. >> But, If you provide all settings in Rconfig.h, I don't have to >> write configure.ac. That is a big benefit for package developers. > > Well, unlikely as no one else has requested it and I don't see configure > scripts in packages repeating that in R. So let me repeat > >>> Which entries were you wanting to use? > > >> Actually I haven't written correct configure.ac yet. >> >> Regards, >> >> Tadashi Kadowaki >> >> 2008/6/10 Prof Brian Ripley <[EMAIL PROTECTED]>: >>> >>> On Tue, 10 Jun 2008, Tadashi Kadowaki wrote: >>> Prof Ripley, I fixed and uploaded. However, it is still useful for development of a package that is close to R core, if Rconfig.h contains all definitions in config.h. If Rconfig contained all information, I didn't have to refer the private header directory. >>> >>> But your package can run its own configure to find such things itself. >>> Which >>> entries were you wanting to use? >>> Regards, Tadashi Kadowaki 2008/6/9 Prof Brian Ripley <[EMAIL PROTECTED]>: > > Private headers are just that, private. They are not intended to be > available to packages, and not installed by the standard R makefiles on > either Unix-alikes or Windows. > > I don't see it documented that they are available on MacOS X, and will > leave > it to that platform's maintainers as to why they have been installed on > that > platform. > > You need to rewrite your code to use only documented headers and entry > points if you intend to distribute it. > > > On Mon, 9 Jun 2008, Tadashi Kadowaki wrote: > >> Hi, Laurent and Tobias >> >> Thanks a lot. >> >> I could make configure script and upload it to r-forge. >> https://r-forge.r-project.org/projects/pdf2/ >> It still works only on mac by default. >> For Linux and Windows, it needs additional option like >> - >> R CMD INSTALL >> --configure-vars="R_INTERNAL_HEADER_DIR=/path/to/src/include" >> pdf2/pkg >> - >> ,where /path/to/src/include is the directory in the R source. >> I didn't check it for Linux and Windows... >> >> Regards, >> >> Tadashi Kadowaki >> >> 2008/6/8 Laurent Gautier <[EMAIL PROTECTED]>: >>> >>> 2008/6/7 <[EMAIL PROTECTED]>: Message: 11 Date: Sat, 7 Jun 2008 03:38:23 +0900 From: "Tadashi Kadowaki" <[EMAIL PROTECTED]> Subject: [Rd] Makevars or congiure for multi platforms To: r-devel@r-project.org Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=ISO-8859-1 Dear all, As previously submitted, I wrote an extending pdf device to embed pop up text and web links. (Patches are available at http://pdf2.r-forge.r-project.org/patches) Now, I'm making a library version of the pdf device. However, with my skill, I'm not sure about writing Makevars or configure file for multi platforms. A following line in Makevars works on my mac, - PKG_CFLAGS=-I/Library/Frameworks/R.framework/PrivateHeaders -DHAVE_CONFIG_H - (Note that the PrivateHeaders directory contains Fileio.h and Defn.h) My question is, How do I write Makevars or congiure for Unix/Linux and Windows? I would like to support those platforms in my library. >>> >>> You could try looking into a package that has configure, >>> configure.win >>> and has built binaries for macosX and windows. Try the package 'rgl' >>> on CRAN, for example. >>> >>> >>> Hoping this helps, >>> >>> >>> L. >>> >>> >>> Regards, Tadashi Kadowaki >>> >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > > -- > Brian D. Ripley, [EMAIL PROTECTED] > Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ > University of Oxford, Tel: +44 1865 272861 (self)
Re: [Rd] [ESS] browser() exits when not desired, in three different scenarios (PR#11634)
Tim, I have reported some similar issues a while back and there was
some discussion on this topic:
http://tolstoy.newcastle.edu.au/R/devel/06/03/4609.html
Good luck,
Kevin
On Tue, Jun 10, 2008 at 6:47 PM, Tim Hesterberg <[EMAIL PROTECTED]> wrote:
> Here are three different scenarios in which the browser() exits
> when I don't want it to. These are all related to the browser
> accepting either c or (return) to exit. I would like an option
> to turn off the (return) behavior in order to avoid these problems.
>
>
>
> # Case 1 - when calling help
> # Note, I am using ESS in emacs; this is probably an interaction
> # with ESS handling of ? help.
>> f <- function(x){
> + browser()
> + length(x)
> + }
>> f(1:4)
> Called from: f(1:4)
> Browse[1]> ?rep
> [1] 4
>>
> # The help was given, but the browser exits.
>
>
> # Case 2 - when pasting in a command that stretches over
> # two lines.
> # With f defined as above, call f, select the following two lines in
> # an emacs buffer (using c-w clipboard-kill-ring-save) and yank them
> into the *R* buffer:
> mean(x,
> trim = .2)
> # The result:
>> f(1:4)
> Called from: f(1:4)
> Browse[1]> mean(x,
> trim = .2)
>
> mean(x,
> + trim = .2)
> [1] 2.5
> Browse[1]>
> [1] 4
>>
> # The multi-line command was echoed (twice--this is probably an ESS
> problem or misconfiguration), ran, and the browser exits.
>
>
> # Case 3 - when pasting in a line at a time, including blank lines.
> I like to include blank lines in my code for readability.
> When I paste in multiple lines, the blank lines cause the browser
> to exit.
>
> I reported case 3 before; it is the single thing that bothers
> me most about R. Someone suggested using
> ess-eval-line-and-step in ESS; this is nice for one line, but does not
> support C-u for sending multiple lines, and doesn't apply when
> I'm not using ESS.
>
> Tim Hesterberg
>
> --please do not edit the information below--
>
> Version:
> platform = i486-pc-linux-gnu
> arch = i486
> os = linux-gnu
> system = i486, linux-gnu
> status =
> major = 2
> minor = 7.0
> year = 2008
> month = 04
> day = 22
> svn rev = 45424
> language = R
> version.string = R version 2.7.0 (2008-04-22)
>
> Locale:
> LC_CTYPE=en_US;LC_NUMERIC=C;LC_TIME=C;LC_COLLATE=C;LC_MONETARY=C;LC_MESSAGES=en_US;LC_PAPER=en_US;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US;LC_IDENTIFICATION=C
>
> Search Path:
> .GlobalEnv, package:stats, package:graphics, package:grDevices,
> package:utils, package:datasets, package:showStructure, package:Rcode,
> package:splus2R, package:methods, Autoloads, package:base
>
>[[alternative HTML version deleted]]
>
> __
> [EMAIL PROTECTED] mailing list
> https://stat.ethz.ch/mailman/listinfo/ess-help
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Routine and Deep testing with R CMD check
Hi, I recently provoked some discussion over on the BioConductor developer list about testing and R CMD check. In brief, the salient points that arose from the discussion are: [1] Because of the need for a nightly build of BioConductor, the tests (in the ./tests directory) of a package that run routinely as part of "R CMD check" must complete in five minutes. [2] Nontrivial regression testing of complex algorithms on real data can easily take longer than five minutes. [3] Maintaining and improving code that works on various kinds of "omics" data is greatly facilitated by the inclusion of nontrivial regression tests. Of course, points [1] and [3] are incompatible in the current setup. Both could, however, be accommodated by changing the way "R CMD check" runs test scripts. There are at least two ways this could be accomplished. One possibility would be to define a separate directory as part of the package structure to store the more complex, longer, "deep" tests. That is, one might have package/R package/man package/tests package/deeptests [or some better name] Then the default for "R CMD check" would be to run all the .R scripts in tests but none of the .R scripts in deep tests. However, one would also have to add an option, perhaps something like R CMD check --run-deeptests [package] to run the more elaborate test scripts. The second possibility would be to keep all the tests in the same (existing ./tests) directory but include a standard file in that directory to indicate which scripts are more complex. This would be a little trickier to design, since it would be nice to keep the existing behavior for someone who ignores the new structure. One, could however, allow for something like ## CONTROLTESTS complex: test1.R, test3.R simple: test2.R, test4.R - The default (in the absence of A CONTROLTESTS file or for scripts in the directory that are not listed in the file) is to assume "simple", which would then get the existing behavior without changes to existing packages. How hard would it be to implement one of these approaches for R CMD check? -- Kevin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Routine and Deep testing with R CMD check
A combination of RUnit from CRAN and .Rbuildignore provide a workable solution for the 'xts' package I work on, though this obviously removes the tests from the distributed code. http://cran.r-project.org/web/packages/RUnit/index.html --and-- http://wiki.r-project.org/rwiki/doku.php?id=developers:runit Jeff On Wed, Jun 11, 2008 at 10:05 AM, Kevin R. Coombes <[EMAIL PROTECTED]> wrote: > Hi, > > I recently provoked some discussion over on the BioConductor developer list > about testing and R CMD check. In brief, the salient points that arose from > the discussion are: > > [1] Because of the need for a nightly build of BioConductor, the tests (in > the ./tests directory) of a package that run routinely as part of "R CMD > check" must complete in five minutes. > [2] Nontrivial regression testing of complex algorithms on real data can > easily take longer than five minutes. > [3] Maintaining and improving code that works on various kinds of "omics" > data is greatly facilitated by the inclusion of nontrivial regression tests. > > Of course, points [1] and [3] are incompatible in the current setup. Both > could, however, be accommodated by changing the way "R CMD check" runs test > scripts. There are at least two ways this could be accomplished. > > One possibility would be to define a separate directory as part of the > package structure to store the more complex, longer, "deep" tests. That is, > one might have >package/R >package/man >package/tests >package/deeptests [or some better name] > Then the default for "R CMD check" would be to run all the .R scripts in > tests but none of the .R scripts in deep tests. However, one would also have > to add an option, perhaps something like >R CMD check --run-deeptests [package] > to run the more elaborate test scripts. > > The second possibility would be to keep all the tests in the same (existing > ./tests) directory but include a standard file in that directory to indicate > which scripts are more complex. This would be a little trickier to design, > since it would be nice to keep the existing behavior for someone who ignores > the new structure. One, could however, allow for something like > > > ## CONTROLTESTS > > complex: test1.R, test3.R > simple: test2.R, test4.R > - > > The default (in the absence of A CONTROLTESTS file or for scripts in the > directory that are not listed in the file) is to assume "simple", which > would then get the existing behavior without changes to existing packages. > > How hard would it be to implement one of these approaches for R CMD check? > > -- Kevin > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- There's a way to do it better - find it. Thomas A. Edison __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Routine and Deep testing with R CMD check
On Wed, 11 Jun 2008, Kevin R. Coombes wrote: > [1] Because of the need for a nightly build of BioConductor, the tests > (in the ./tests directory) of a package that run routinely as part of "R > CMD check" must complete in five minutes. > [2] Nontrivial regression testing of complex algorithms on real data can > easily take longer than five minutes. > [3] Maintaining and improving code that works on various kinds of > "omics" data is greatly facilitated by the inclusion of nontrivial > regression tests. > > Of course, points [1] and [3] are incompatible in the current setup. > Both could, however, be accommodated by changing the way "R CMD check" > runs test scripts. There are at least two ways this could be accomplished. Another approach is to have check use the new-to-2.8.0 function setSessionTimeLimit() to let the checker put a time limit on the tests. In a time-constrained environment you could ask check to spend no more than 5 minutes running the tests but you could also set the limit to 3 hours or Inf or anything else. This would only be useful if the quicker tests were done first, so you'd have to alphabetize your test files. It might be nice if check could print the time it took to do each test. Bill Dunlap Insightful Corporation bill at insightful dot com "All statements in this message represent the opinions of the author and do not necessarily reflect Insightful Corporation policy or position." __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] read.table() causes segfault with incorrect data (PR#11627)
On Wed, 11 Jun 2008 [EMAIL PROTECTED] wrote:
> Full_Name: Juho Vuori
> Version: 2.7.0 (2008-04-22)
> OS: Linux poseidon.fimr.fi 2.6.23.17-88.fc7PAE #1 SMP Thu May 15 00:22:53 EDT
> 2008 i686 i686 i386 GNU/Linux
> Submission from: (NULL) (193.166.188.194)
>
>
> Calling read.table() twice the following way causes a segmentation fault in R.
> Run R and type the following commands:
>
> > read.table(stdin())
> 0: 1 2 3
> 1: 3
> 2:
> Error in scan(file, what, nmax, sep, dec, quote, skip, nlines, na.strings, :
> line 2 did not have 3 elements
> > read.table(stdin())
>
> *** caught segfault ***
> address 0x64616572, cause 'memory not mapped'
>
valgrind shows that con->nPushBack>0 but con->PushBack
has already been freed by do_clearpushback:
> read.table(stdin())
0: 1 2 3
1: 3
2:
Error in scan(file, what, nmax, sep, dec, quote, skip, nlines, na.strings,
:
line 2 did not have 3 elements
> read.table(stdin())
==11631== Invalid read of size 4
==11631==at 0x80B3281: ConsoleGetcharWithPushBack (scan.c:130)
==11631==by 0x80B348E: scanchar (scan.c:214)
==11631==by 0x80B7E24: do_readtablehead (scan.c:1568)
==11631==by 0x80653E0: do_internal (names.c:1129)
...
==11631== Address 0x443E638 is 0 bytes inside a block of size 20 free'd
==11631==at 0x40052A3: free (vg_replace_malloc.c:233)
==11631==by 0x8128A41: do_clearpushback (connections.c:3671)
==11631==by 0x80653E0: do_internal (names.c:1129)
==11631==by 0x815EA27: Rf_eval (eval.c:461)
==11631==by 0x812B133: R_run_onexits (context.c:147)
0x080b3281 in ConsoleGetcharWithPushBack (con=0x4067c50) at scan.c:130
130 curLine = con->PushBack[con->nPushBack-1];
(gdb) print con
$1 = 0x4067c50
(gdb) print con->PushBack
$2 = (char **) 0x443e638
The following change to connections.c:do_clearpushback() seems to fix it.
Index: connections.c
===
--- connections.c (revision 45893)
+++ connections.c (working copy)
@@ -3669,6 +3669,7 @@
if(con->nPushBack > 0) {
for(j = 0; j < con->nPushBack; j++) free(con->PushBack[j]);
free(con->PushBack);
+con->nPushBack = 0 ;
}
return R_NilValue;
}
Bill Dunlap
Insightful Corporation
bill at insightful dot com
"All statements in this message represent the opinions of the author and do
not necessarily reflect Insightful Corporation policy or position."
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Routine and Deep testing with R CMD check
On Wed, 11 Jun 2008, Bill Dunlap wrote: On Wed, 11 Jun 2008, Kevin R. Coombes wrote: [1] Because of the need for a nightly build of BioConductor, the tests (in the ./tests directory) of a package that run routinely as part of "R CMD check" must complete in five minutes. [2] Nontrivial regression testing of complex algorithms on real data can easily take longer than five minutes. [3] Maintaining and improving code that works on various kinds of "omics" data is greatly facilitated by the inclusion of nontrivial regression tests. Of course, points [1] and [3] are incompatible in the current setup. Both could, however, be accommodated by changing the way "R CMD check" runs test scripts. There are at least two ways this could be accomplished. Another approach is to have check use the new-to-2.8.0 function setSessionTimeLimit() to let the checker put a time limit on the tests. In a time-constrained environment you could ask check to spend no more than 5 minutes running the tests but you could also set the limit to 3 hours or Inf or anything else. This would only be useful if the quicker tests were done first, so you'd have to alphabetize your test files. Or to use environment variable(s) to select which tests to do (which is what I had started to write a reply to suggest when I got diverted to something more urgent). E.g. 'foreign' has a slow test that needs Internet access, and it will become optional via an environment variable in the next release. BTW, some of us run checks with a Unix-level time limit set: there are a few CRAN packages that infinite-loop on 64-bit systems so it is a necessary precaution. It might be nice if check could print the time it took to do each test. That's an existing request for various parts of the checking procedure. When the time to run a package check jumps up, it is sometimes tedious to find out where the time went. But the tests are currently scripted by make, so difficult to produce timings portably. Bill Dunlap -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Routine and Deep testing with R CMD check
On Wed, 11 Jun 2008, Prof Brian Ripley wrote:
> Bill Dunlap wrote:
> > It might be nice if check could print the time it took to do
> > each test.
>
> That's an existing request for various parts of the checking procedure.
> When the time to run a package check jumps up, it is sometimes tedious to
> find out where the time went. But the tests are currently scripted by
> make, so difficult to produce timings portably.
In Splus, if you set options(verbose=TRUE), then the time
for each top level expression is printed to stdout (or
to a log file, depending on other options). The Time:
line tells which top level expression it refers to and
whether the expression succeeded or failed. E.g.,
> options(verbose=TRUE)
Time: Task #2 succeeded (Seconds = 0.01 CPU, 0.01 elapsed)
> for(i in 1:1e5)log(i)
Time: Task #3 succeeded (Seconds = 1.49 CPU, 1.5 elapsed)
> for(i in 1:1e5) if (i==1e5) stop("i is too big") else log(i)
Error: Problem: i is too big
Problem: i is too big
Use traceback() to see the call stack
Time: Task #4 failed (Seconds = 3.18 CPU, 3.2 elapsed)
If R had this sort of logging then check could turn it on
when desired.
Splus also uses this logging mechanism to log calls to
read.table() and inputData(), to record the initial
value of .Random.seed, etc., so one can run a perl script
over the log file for a batch run to see if there were
significant problems and have enough information to
reproduce the problems found.
Bill Dunlap
Insightful Corporation
bill at insightful dot com
"All statements in this message represent the opinions of the author and do
not necessarily reflect Insightful Corporation policy or position."
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] arima() bug
I guess this is more r-devel than r-help. Note, I am just the messenger - I have no idea what the user is trying to model here. arima() crashes R (segfault) with Linux R-2.7.0, Solaris R-2.6.0: *** caught segfault *** address 4240, cause 'memory not mapped' Traceback: 1: .Call(R_getQ0, phi, theta) 2: makeARIMA(trarma[[1]], trarma[[2]], Delta, kappa) 3: arima(x, c(1, 0, 1), c(1, 0, 1)) Under rw-2.7.0 or R version 2.8.0 Under development (unstable) (2008-06-10 r45893) it gets: Error: cannot allocate vector of size 1010.9 Mb In addition: Warning messages: 1: In makeARIMA(trarma[[1]], trarma[[2]], Delta, kappa) : Reached total allocation of 447Mb: see help(memory.size) 2: In makeARIMA(trarma[[1]], trarma[[2]], Delta, kappa) : Reached total allocation of 447Mb: see help(memory.size) 3: In makeARIMA(trarma[[1]], trarma[[2]], Delta, kappa) : Reached total allocation of 447Mb: see help(memory.size) 4: In makeARIMA(trarma[[1]], trarma[[2]], Delta, kappa) : Reached total allocation of 447Mb: see help(memory.size) Reproduce by: # 2 years of daily temperature data set.seed(1); x <- ts(20*sin((1:731)*2*pi/365) + 10 + rnorm(731, 0, 4), freq=365) arima(x, c(1, 0, 1), c(1, 0, 1)) Ray Brownrigg __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
