Re: [Rd] update.packages(1)

[Duncan Murdoch]

On 25/03/2010 3:16 PM, Arni Magnusson wrote:

I'm relaying a question from my institute's sysadmin:

Would it be possible to modify update.packages() and related functions so 
that 'lib.loc' accepts integer values to specify a library from the 
.libPaths() vector?


Many Linux users want to update all user packages (inside the R_LIBS_USER 
directory, e.g. ~/r/library) and none of the system packages (inside the 
/usr directory, e.g. /usr/lib64/R/library), because they don't have write 
privileges to update the system packages.


Currently, this can be done by pressing 'y RET' for all the user packages 
and 'RET' for all the system packages. This hard work and careful reading 
when there dozens of packages. Another way is to run


   update.packages(Sys.getenv(R_LIBS_USER))

or:

   update.packages(.libPaths()[1])


You could also save some work by putting ask=FALSE, or ask=graphics in 
as another argument.  But isn't it easy enough to write your own 
function as a wrapper to update.packages, suiting your own local 
conventions?   It seems like a bad idea to make update.packages too 
friendly, when there are several different friendly front-ends for it 
already (e.g. the menu entries in Windows or MacOS GUIs).



But it would be nicer for the user to type

   update.packages(1)

using a 'pos' like notation to indicate the first element of the 
.libPaths() vector.


---

A separate but related issue is that it would be nice if the R_LIBS_USER 
library would be the first library by default. Currently, my sysadmin must 
use Rprofile.site to shuffle the .libPaths() to make R_LIBS_USER first, 
which seems like a sensible default when it comes to install.packages() 
and remove.packages().


This is R version 2.10.1 (2009-12-14) on x86_64-redhat-linux-gnu (Fedora 
11).


I didn't write it, but I suspect the current behaviour was intentional. 
 Without it, it would be hard to put the user library last, since 
.libPaths() adds things at the front.  Now you have a choice:  use the 
R_LIBS_USER environment variable to put it last, use a line in your 
Rprofile.site file to put something first.


Duncan Murdoch

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

Re: [Rd] update.packages(1)

[Duncan Murdoch]

On 27/03/2010 4:48 PM, Seth Falcon wrote:

On 3/27/10 1:43 PM, Duncan Murdoch wrote:

On 25/03/2010 3:16 PM, Arni Magnusson wrote:

I'm relaying a question from my institute's sysadmin:

Would it be possible to modify update.packages() and related functions
so that 'lib.loc' accepts integer values to specify a library from the
.libPaths() vector?

Many Linux users want to update all user packages (inside the
R_LIBS_USER directory, e.g. ~/r/library) and none of the system
packages (inside the /usr directory, e.g. /usr/lib64/R/library),
because they don't have write privileges to update the system packages.

Currently, this can be done by pressing 'y RET' for all the user
packages and 'RET' for all the system packages. This hard work and
careful reading when there dozens of packages. Another way is to run

   update.packages(Sys.getenv(R_LIBS_USER))

or:

   update.packages(.libPaths()[1])

You could also save some work by putting ask=FALSE, or ask=graphics in
as another argument.  But isn't it easy enough to write your own
function as a wrapper to update.packages, suiting your own local
conventions?   It seems like a bad idea to make update.packages too
friendly, when there are several different friendly front-ends for it
already (e.g. the menu entries in Windows or MacOS GUIs).


But it would be nicer for the user to type

   update.packages(1)

using a 'pos' like notation to indicate the first element of the
.libPaths() vector.

---

A separate but related issue is that it would be nice if the
R_LIBS_USER library would be the first library by default. Currently,
my sysadmin must use Rprofile.site to shuffle the .libPaths() to make
R_LIBS_USER first, which seems like a sensible default when it comes
to install.packages() and remove.packages().


I'm confused.  AFAICT, R_LIBS_USER _is_ put first.  Following the advice
in the Admin manual, I created a directory matching the default value of
R_LIBS_USER (Sys.getenv(R_LIBS_USER) to see it).  Then when I start R,
I get:


.libPaths()

[1] /home/sfalcon/R/x86_64-unknown-linux-gnu-library/2.11
[2] /home/sfalcon/build/rd/library

Isn't that what you want?


I didn't try it, I just read the documentation (in ?.libPaths).  As I 
read it it says the order is


R_LIBS, R_LIBS_USER, .Library.site, .Library

and some of those components can be missing.

So another way to put the user libs first is to specify the site libs in 
.Library.site rather than in the environment variable.


Duncan Murdoch

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

Re: [Rd] Setting up TortoiseSVN and PuTTY on Windows for r-forge.r-project.org (Was: Re: Using SVN + SSH on windows)

[Duncan Murdoch]

/KkcprOBzhXIpFKn15efRr86H2psQYeDDpAB5EOc=
rsa-key-20100328 in one line (without quotation marks).
10. Click 'Update' on the r-forge page.  In the 'Shell Account
Information' section you should now see that the there is one more key
at 'SSH Shared Authorized Keys'.
11. Close PuTTYgen and the r-forge page.

II.B. ADD THE PRIVATE KEY TO THE PAGEANT CLIENT
1. Start Pageant.  It will open as a small icon in the Windows System Tray.


I do this as part of each Windows logon, by putting the command

...\pageant.exe ...\foo.ppk

as a shortcut in my Startup folder.  (The ...'s are replaced with real 
paths, of course.)


This pops up a dialog where I need to enter the passphrase.  I get this 
every time I sign on to Windows which is a little irritating, but since 
I use svn+ssh for so many things, I probably make use of the key during 
almost every session.  I've become used to typing a Windows password to 
log on to Windows, then a Pageant passphrase to get access to various 
remote things.


Duncan Murdoch


2. Double click on the Pageant tray icon to open the 'Pageant Key List' window.
3. Click 'Add Key'.  Locate the *ppk file saved by PuTTYgen, e.g.
'henrikb,20100328.ppk'.  Open it.
4. In the 'Pageant Key List' window, the key should now be listed,
e.g. ssh-rsa  1024  ... rsa-key-20100328.  Note that the last part
rsa-key-20100328 is just a comment, but it should match the Key
comment you saw in PuTTYgen and also at the end of the line pasted
into r-forge, cf. Step II.A.9 above.
5. You can now Close the Pageant window.  Pageant will keep running
in the System tray.


II.C. COMMIT A CHANGE
1. Edit the r-oo,R-forge/README file again, e.g. add a line bar.
2. Follow the Steps I.B. above to commit.  The difference is that you
now do not have to enter the password.  Instead, Pageant will
communicate with r-forge in the background who will use the public and
private keys to exchange authentication information.


NOTE:
When I tried the above immediately after all the above steps, I was
still asked for the password.  This was at 12:40 UTC.  However, when
trying about 20 minutes later (13:01 UTC) the authentication works
automatically (no password needed).

The reason for the delay is that r-forge needs several hours in order
to update its authentication servers; this is written on the
http://r-forge.r-project.org/account/editsshkeys.php page where you
can read This is done by a cron job, so it may not happen
immediately. Please allow for a one hour delay.  (maybe it happens at
every full hour - see above - but I don't know).  The exact time you
have to wait is unknown, and I do not know of a way to check when the
r-forge cron jobs have been run; there are no log files you check.
There are some information about r-forge cron jobs at
http://site.r-forge.r-project.org/, but they don't list the job for
the above.

Hope this helps some one

Henrik

On Sun, Mar 28, 2010 at 5:45 AM, David Scott d.sc...@auckland.ac.nz wrote:

Uwe Ligges wrote:

It is really not hard to set it up. I am using a vanilla ssh (rather than
putty) and that works fine all the time...

Uwe Ligges


Ditto here. I am using ssh non commercial version with tortoise on Vista,
and I don't recall any problems setting it up. R-forge works perfectly fine
with windows and tortoise in my experience.

Is your putty/ssh working? Can you access other machines with it? I do
recall ssh can be a bit fussy.

David Scott



On 27.03.2010 18:31, Gabor Grothendieck wrote:

s getting commits to R-Forge to work from
Windows.  The entire system is really geared to UNIX.  It took me a
couple of days of trial and error (since you have to wait 20 minutes
for each try) before I got it working.  Although I did get it to work,
I ultimately decided to host all my packages on googlecode.
googlecode is extremely easy to use from Windows and does not require
any public/private key, pageant, etc.  e.g.
http://sqldf.googlecode.com.  If you already have TortoiseSVN and know
how to use it then you can probably set up a googlecode site in
literally 5 minutes.

One other possibility.  I think there is a way to host your project on
googlecode but still have it mirrored on R-forge so from your users'
viewpoint its the same as if it were on R-Forge but you can use the
simpler googlecode site.  In that case you might not need to set up
commits on R-Forge since you would do all your commits through
googlecode (depending on how it works) but I have not seen good
documentation on how to do this.


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


--
_
David Scott Department of Statistics
   The University of Auckland, PB 92019
   Auckland 1142,NEW ZEALAND
Phone: +64 9 923 5055, or +64 9 373 7599 ext 85055
Email:  d.sc...@auckland.ac.nz,  Fax: +64 9 373 7018

Director of Consulting, Department of Statistics

Re: [Rd] .Call and .C arguments

[Duncan Murdoch]

On 29/03/2010 7:56 AM, Roger Bergande wrote:

-- Forwarded message --
From: roger.berga...@swisslife.ch
Date: Mon, 29 Mar 2010 13:51:12 +0200
Subject: .Call and .C arguments
To: berga...@gmail.com

Dear List



My question is about .C and .Call



I was experimenting with the .C and .Call interface as I came across the
following behaviour.

The passed values are not the same in C.  I 'm calling a function in C
with the argument as.double(1204.245) but in the debug mode in C the
value has changed to 1204.2449.
  


What makes you think those two numbers are different?  See FAQ 7.31.

Duncan Murdoch




Is there a way to pass the arguments differently?



I'm using Windows and Visual Studio C++ 2005 Express Edition and
R-2.10.1.





Please see the two simple examples to understand the issue.



# C call from R

.C(myroundC,as.double(1204.245))





// C Code



void myroundC(double *Amount){



*Amount = Rf_fround(*Amount,2);



}



#Return value in R

[[1]]

[1] 1204.24







# C call from R

.Call(myroundCall,as.double(1204.245))



// C Code

SEXP myroundCall(SEXP a){

double *ap = REAL(a), *ansp;

SEXP ans;

PROTECT(ans = allocVector(REALSXP, 1));

ansp = REAL(ans);

*ansp = Rf_fround(*ap,2);

UNPROTECT(1);

return(ans);

}



#Return value in R

[1] 1204.24



# expected value 1204.25





Thanks a lot for your help.

Best regards

Roger Bergande

__
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

[Rd] RSS feeds now link to bug reports

[Duncan Murdoch]

Sometime last year Hadley Wickham suggested that the R daily news feed 
(http://developer.r-project.org/RSSfeeds.html) should link to bug 
reports.  Now that Simon has moved the bug reporting system to Bugzilla, 
this is finally possible, and I've just rebuilt the news items with 
those links in place.  For example, see the item under 2.11.0 BUG FIXES in


http://developer.r-project.org/blosxom.cgi/R-devel/NEWS/2010/04/01#n2010-04-01

Duncan Murdoch

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

Re: [Rd] Difference Linux / Windows

[Duncan Murdoch]

On 31/03/2010 6:38 PM, Seth Falcon wrote:

On 3/31/10 1:12 PM, Christophe Genolini wrote:
 Hi the list,
 I am writing a package that happen to not be compatible with linux
 because I did not know that the function savePlot was available only
 on windows. Is there a list of incompatible function? How can I get
 this kind of information?

One way is to obtain a copy of the R sources and then grep the Rd files 
for '#ifdef'.


I don't claim this is convenient.

There has been discussion, and I believe general consensus, that we'd 
like to eliminate the conditional documentation.  This requires editing 
the Rd files to make the contents sensible (you can't just remove the 
#ifdef's).  Patches along these lines would be welcome.


Producing those patches would be a lot of work even to incorporate, let 
alone write.  Another possibility is some sort of markup in the display 
to indicate platform-specific bits.  That would be a lot easier to 
implement; the hard part is the design. 

We have to design for 4 different output formats:  LaTeX, HTML, plain 
text, and executable example code.  We need to design for help files 
that display differently on different platforms, and for help files that 
only exist on a subset of the platforms.


Duncan Murdoch

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

Re: [Rd] inject html code into Rd file

[Duncan Murdoch]

On 02/04/2010 7:13 AM, Romain Francois wrote:

Le 02/04/10 13:07, Duncan Murdoch a écrit :

On 02/04/2010 6:17 AM, Romain Francois wrote:

Hello,

I'm trying to inject html code into an Rd file. For example :

\name{test}
\alias{test}
\title{test}
\description{
\if{html}{
\Sexpr[stage=render,results=text,echo=FALSE]{
bhello/b
}
}
}

when this file is rendered, instead of having hello in bold, I get
bhello/b, i.e. characters  and  are replaced with html entities
: lt; and gt;

Is there a way to turn this off ?

Yes, if you wrap it in \out{}. The example in the manual is

\if{latex}{\out{\alpha}}\ifelse{html}{\out{alpha;}}{alpha}

Duncan Murdoch


yes, I saw that in WRE, I should have been more specific.


what if instead of a trivial string like bhello/b the text is to 
be computed by some function. For example:


print( xtable( iris), type = html )


I think this should do it:

\Sexpr[stage=render,results=rd,echo=FALSE]{
paste(\\out{, bhello/b, }, sep=)}

but this stuff hasn't been tested much, so there might be problems...

Duncan Murdoch

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

Re: [Rd] inject html code into Rd file

[Duncan Murdoch]

On 02/04/2010 8:06 AM, Duncan Murdoch wrote:

On 02/04/2010 7:13 AM, Romain Francois wrote:

Le 02/04/10 13:07, Duncan Murdoch a écrit :

On 02/04/2010 6:17 AM, Romain Francois wrote:

Hello,

I'm trying to inject html code into an Rd file. For example :

\name{test}
\alias{test}
\title{test}
\description{
\if{html}{
\Sexpr[stage=render,results=text,echo=FALSE]{
bhello/b
}
}
}

when this file is rendered, instead of having hello in bold, I get
bhello/b, i.e. characters  and  are replaced with html entities
: lt; and gt;

Is there a way to turn this off ?

Yes, if you wrap it in \out{}. The example in the manual is

\if{latex}{\out{\alpha}}\ifelse{html}{\out{alpha;}}{alpha}

Duncan Murdoch

yes, I saw that in WRE, I should have been more specific.


what if instead of a trivial string like bhello/b the text is to 
be computed by some function. For example:


print( xtable( iris), type = html )


I think this should do it:

\Sexpr[stage=render,results=rd,echo=FALSE]{
paste(\\out{, bhello/b, }, sep=)}

but this stuff hasn't been tested much, so there might be problems...


One problem is that the backslashes need to be escaped twice, so you'd want

 \Sexpr[stage=render,results=rd,echo=FALSE]{
 paste(out{, bhello/b, }, sep=)}

and you'd probably want it wrapped in \if or \ifelse so that it doesn't 
show up in text or latex output:


 \Sexpr[stage=render,results=rd, 
echo=FALSE]{if{html}{out{bhello/b}}}


Duncan Murdoch

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

Re: [Rd] full copy on assignment?

[Duncan Murdoch]

On 03/04/2010 6:34 PM, Norm Matloff wrote:

Here's a basic question that doesn't seem to be completely answered in
the docs, and which unfortunately I've not had time to figure out by
wading through the R source code:

In a vector (or array) element assignment such as 

   z[3] - 8 


is there in actuality a full rewriting of the entire vector pointed to
by z, as implied by

   z - [-(z,3,value=8)

Assume that an element of z has already being changed previously, so
that copy-on-change issues don't apply, with z being reassigned back to
the same memory address.

I seem to recall reading somewhere that recent R versions make some
attempt to avoid rewriting the entire vector, and my timing experiments
seem to suggest that it's true.  


So, is a full rewrite avoided?  And where in the source code is this
done?


It depends.  User-written assignment functions can't avoid the copy. 
They act like the expansion


z - [-(z,3,value=8)

and in that, R can't tell that the newly created result of 
[-(z,3,value=8) will later overwrite z.


However, if z is a regular vector without a class and you're using the 
built-in version of z[3] - 8, it can take some shortcuts.  This happens 
in multiple places; one is around line 488 of subassign.c another is 
around line 1336.  In each of these places copies are made in some 
circumstances, but not in general.


Duncan Murdoch

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

Re: [Rd] R CMD check tells me 'no visible binding for global variable ', what does it mean?

[Duncan Murdoch]

On 12/04/2010 10:51 AM, Michael Dewey wrote:
When I run R CMD check on a package I have recently started work on I 
get the following:


* checking R code for possible problems ... NOTE
addlinear: no visible binding for global variable 'x'

I appreciate that this is only a NOTE and so I assume is R's 
equivalent of 'This is perfectly legal but I wonder whether it is 
really what you intended' but I would like to understand it.


In the relevant function addlinear the following function is defined locally:

orfun - function(x, oddsratio) {1/(1+1/(oddsratio * (x/(1-x}

and then used later in curve

   curve(orfun(x, exp(estimate)), from = 0.001, to = 0.999, add = TRUE)

These are the only occurrences of 'x'.

Is it just telling me that I have never assigned a value to x? Or is 
it more sinister than that? As far as I can tell the function does 
what I intended.


The curve() function evaluates the first argument in a strange way, and 
this confuses the code checking.  (The variable name x is special to 
curve().)


I think you can avoid the warning by rewriting that call to curve() as

curve(function(x) orfun(x, exp(estimate)), from = 0.001, to = 0.999, add = TRUE)

Duncan Murdoch

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

Re: [Rd] tiny typo in ?prop.test: if for is

[Duncan Murdoch]

On 18/04/2010 12:53 PM, Ben Bolker wrote:
   from revision 51769:

 Index: prop.test.Rd
 ===
 --- prop.test.Rd(revision 51769)
 +++ prop.test.Rd(working copy)
 @@ -60,7 +60,7 @@

If there is only one group, then the null tested is that the
underlying probability of success is \code{p}, or .5 if \code{p} is
 -  not given.  The alternative is that the probability of success if less
 +  not given.  The alternative is that the probability of success is less
than, not equal to, or greater than \code{p} or 0.5, respectively, as
specified by \code{alternative}.  A confidence interval for the
underlying proportion with confidence level as specified by


Thanks, I've fixed it.

Duncan Murdoch

[[alternative HTML version deleted]]

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

Re: [Rd] Rtools for building 64 bit windows packages

[Duncan Murdoch]

On 22/04/2010 3:04 PM, Sharpie wrote:

Hello R developers,

I sincerely apologize if the answer to this question is clearly documented
somewhere, but I was unable to figure it out over my morning coffee.

I just downloaded today's release of R 2.11.0 and installed it on my Windows
7 64 bit VM.  I also downloaded the latest version of Rtools211 from
Professor Murdoch's site.   The first thing I attempted to do was build some
of my packages from source to check that they work with the new version.  I
got the following error message:

  making DLL ...
x86_64-w64-mingw32-gcc -IC:/PROGRA~1/R/R-211~1.0-X/include -O2
-Wall  -std=gnu99 -c tikzDevice.c -o tikzDevice.o
x86_64-w64-mingw32-gcc: not found

This does not surprise me, R 2.11.0 is hot out of the forge and Rtools
probably hasn't been repacked to support the 64 bit version.  I gathered
from the Windows FAQ and the list archives that the MinGW-w64 project
supplies the compilers and linkers used by the 64 bit version- I visited
their site and found the selection of packages available for download...
confusing.

I guess what I'm asking: 


  * Do I use the Cygwin binaries?
  


You can use the Rtools for the stuff other than the compilers.  You need 
the MinGW 64 bit versions of the compilers; they are not nicely packaged 
yet, but the instructions for finding them are in the new version of the 
R-admin manual, in the section 3.3, Building R for 64 bit Windows. 


Duncan Murdoch

  * If not, is there an officially blessed binary distribution of Windows
x86_64 compilers and binutils?
  
  * If not, do I build the x86_64 toolchain from the current HEAD, or is

there a specific revision that has been determined to be stable?


Thanks for your time and effort on maintaining and enhancing such a
wonderful language!

-Charlie

-
Charlie Sharpsteen
Undergraduate-- Environmental Resources Engineering
Humboldt State University



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

Re: [Rd] Question of R CMD check

[Duncan Murdoch]

On 21/04/2010 9:48 PM, rusers.sh wrote:

Hi all,
Today, i just installed the newest R version 2.10.1 and other necessary
tools for building R package under windows,e.g. Rtools, perl. All are the
newest version.
  After the correct configuration under windows (configuration should be
correct), i use it to re-check my old package. I found the following prolem
when checking EXAMPLEs in each function, which did not exist before this
re-installation.

* checking examples ... ERROR
 Running examples in 'stam-Ex.R' failed.

  I used \dontrun{} % enddontrun in all the examples of my functions that
should be no problem, i think. I checked my package before and did not find
errors. I also browsed the checking results in 'stam-Ex.R'. It listed all
the example codes in that file, something like this,
  cleanEx(); nameEx(stcdt)
  ### * stcdt
  flush(stderr()); flush(stdout())
  ###example codes

  I did not met this problem before.  Any ideas on solving this?
  Thanks a lot.

  
You need to show us the end of the stam-Ex.Rout file.  It will contain 
the error message.


Duncan Murdoch

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

Re: [Rd] segfault with format.POSIXct()

[Duncan Murdoch]

On 23/04/2010 7:31 AM, Uwe Ligges wrote:
Works for me, both under Windows (32 and 64 bit) and Linux, although I 
have not package slmisc attached.
  


I've just found that the bug 14267 is related to a POSIXlt formatting 
bug, so this is likely to be the same thing. 


Duncan Murdoch

Uwe Ligges



On 23.04.2010 01:32, Sebastian P. Luque wrote:
  

Hi,

I'm getting a segmentation fault as follows:

---cut here---start--
R  begt- as.POSIXct(strptime(10/01/2009 06:00:00, format=%d/%m/%Y 
%H:%M:%S),
+tz=GMT)
R  tser- seq(begt, by=5, length.out=91000)
R  tser.trunc- format(tser)
Error: segfault from C stack overflow
---cut here---end

With the following set up:

---cut here---start--
R  sessionInfo()
R version 2.11.0 RC (2010-04-19 r51778)
x86_64-pc-linux-gnu

locale:
  [1] LC_CTYPE=en_CA.UTF-8   LC_NUMERIC=C   LC_TIME=en_CA.UTF-8 
   LC_COLLATE=en_CA.UTF-8
  [5] LC_MONETARY=C  LC_MESSAGES=en_CA.UTF-8
LC_PAPER=en_CA.UTF-8   LC_NAME=C
  [9] LC_ADDRESS=C   LC_TELEPHONE=C 
LC_MEASUREMENT=en_CA.UTF-8 LC_IDENTIFICATION=C

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base

other attached packages:
[1] slmisc_0.7.3   lattice_0.18-3

loaded via a namespace (and not attached):
[1] grid_2.11.0
---cut here---end


Reducing the size of the sequence in seq.POSIXct() to 9 doesn't
cause a segfault, so it seems to be a memory issue.  Is this a bug?

Thanks,




__
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] segfault with format.POSIXct()

[Duncan Murdoch]

On 23/04/2010 10:03 AM, peter dalgaard wrote:

On Apr 23, 2010, at 2:50 PM, Sebastian P. Luque wrote:

 On Fri, 23 Apr 2010 13:31:14 +0200,
 Uwe Ligges lig...@statistik.tu-dortmund.de wrote:
 
 Works for me, both under Windows (32 and 64 bit) and Linux, although I

 have not package slmisc attached.
 
 Is this with 2.11.0 ?  Thanks.


I'm getting a bit further with bug 14267:

On OSX I am NOT seeing it with R-devel, although it is there with 2.11.0 
Patched.

Running with a non-optimized compile, I can get some more information

It is happening on the i-th iteration of the loop in do_formatPOSIXlt with 


(gdb) p i
$4 = 86870

Unfortunately, it looks like a bigger exercise to get valgrind running on Snow 
Leopard -- too big for Friday afternoon anyway. However, the alloca() call on 
line 774 of src/main/datetime.c does look suspect to me. I can see that it was 
introduced with r51353 and has since disappeared in R-devel (r51398).


I've just committed a patch for this on R-2-11-branch.  The problem was 
that the alloca() was within a loop, so it kept allocating more and more 
space until the end of the function call, and blew the stack. In 
R-devel, this was changed to the C99 construct of defining a variable 
sized array within a block, and that was fine, because it was released 
at the end of the block, not at the end of the function call.


Duncan Murdoch

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

Re: [Rd] Question of R CMD check

[Duncan Murdoch]

On 23/04/2010 1:19 PM, rusers.sh wrote:

Hi Duncan,
  Thanks for reminding me. See below for the error information from *.Rout
file
  It seems that 'pkgname' was not found. I am not sure whether there is some
problem with my functions or it is a little bug.
  Thanks a lot.
###
  

assign(ptime, proc.time(), pos = CheckExEnv)
## at least one package changes these via ps.options(), so do this
## before loading the package.
## Use postscript as incomplete files may be viewable, unlike PDF.
## Choose a size that is close to on-screen devices, fix paper
grDevices::ps.options(width = 7, height = 7, paper = a4, reset = TRUE)
grDevices::postscript(paste(pkgname, -Ex.ps, sep=))


Error in paste(pkgname, -Ex.ps, sep = ) : object 'pkgname' not found
Calls: Anonymous - checkIntFormat - gsub - paste
Execution halted
  


The very first line of stam-Ex.R should be

pkgname - stam

Is it?  If not, I'd like to see the package; could you send me a copy?  
If it is, then something in one of your examples is messing with it.  Do 
you have any calls to rm() or remove() in your examples?


Duncan Murdoch

2010/4/23 Duncan Murdoch murdoch.dun...@gmail.com

  

On 21/04/2010 9:48 PM, rusers.sh wrote:



Hi all,
   Today, i just installed the newest R version 2.10.1 and other necessary
tools for building R package under windows,e.g. Rtools, perl. All are the
newest version.
 After the correct configuration under windows (configuration should be
correct), i use it to re-check my old package. I found the following
prolem
when checking EXAMPLEs in each function, which did not exist before this
re-installation.

* checking examples ... ERROR
 Running examples in 'stam-Ex.R' failed.

 I used \dontrun{} % enddontrun in all the examples of my functions that
should be no problem, i think. I checked my package before and did not
find
errors. I also browsed the checking results in 'stam-Ex.R'. It listed all
the example codes in that file, something like this,
 cleanEx(); nameEx(stcdt)
 ### * stcdt
 flush(stderr()); flush(stdout())
 ###example codes

 I did not met this problem before.  Any ideas on solving this?
 Thanks a lot.



  

You need to show us the end of the stam-Ex.Rout file.  It will contain the
error message.

Duncan Murdoch









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

Re: [Rd] S4 Inheritance of environments

[Duncan Murdoch]

On 24/04/2010 1:15 PM, Christopher Brown wrote:

I looked through the documentation and the mailing lists and could not
find an answer to this.  My apologies if it has already been answered.
 If it has, a pointer to the relevant discussion would be greatly
appreciated.
  


Environments are unusual in that they are reference objects:  if e is an 
environment, and you assign f - e, then f refers to the same object as 
e does.  This is unusual in R, where most objects are copied on 
assignment (logically, not always physically).  It means that attributes 
on environments behave strangely:  if you put an attribute on e and 
remove the same attribute from f, it is gone from e too.  We've 
discussed removing the possibility of putting attributes on environments 
(just as you can't put attributes on NULL), but haven't done so yet.


What you should do if you want to use an environment in the way you're 
using it is to put it in a container.  For S4, that could mean using an 
environment as a slot, or inheriting from an object like list(e), rather 
than directly from e.


Duncan Murdoch

Creating S4 classes containing environments exhibits unexpected
behavior/features.  These have a different in two ways:

1) slotName for the data: .xData instead of .Data and do not respond to the
2) Response to the is.* function seems to indicate that the object
does not know of its inheritance.  ( Notably, the inherits function
works as expected. )

Here is a working illustration:

  

#  LIST
setClass( 'inheritList', contains='list')


[1] inheritList
  

inList - new( 'inheritList' )
class( inList )


[1] inheritList
attr(,package)
[1] .GlobalEnv
  

is.list( inList )  # TRUE


[1] TRUE
  

slotNames(inList)  # .Data


[1] .Data
  

inherits(inList, 'list' )  # TRUE


[1] TRUE
  

# ENVIRONMENT
setClass( 'inheritEnv', contains='environment' )


Defining type environment as a superclass via class .environment
[1] inheritEnv
  

inEnv - new( 'inheritEnv' )
class(inEnv)


[1] inheritEnv
attr(,package)
[1] .GlobalEnv
  

is.environment(inEnv) # FALSE


[1] FALSE
  

slotNames(inEnv)  # .xData


[1] .xData
  

inherits(inEnv, 'environment' )   # TRUE


[1] TRUE

My questions is whether this behavior is a bug? By design?  A work
around?  Etc.?

Thanks kindly for your reply,

Chris


the Open Data Group
 http://www.opendatagroup.com
 http://blog.opendatagroup.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] serial connection patch

[Duncan Murdoch]

On 27/04/2010 8:32 AM, Matt Shotwell wrote:
Simon, 


Thanks for reviewing it! All the modified files are under the GPL
version 2 (except the configure script). According to the GPLv2, I am
granted permission to modify and redistribute the code as long as I make
a notice in the files of their modification and the date (which I have
not done yet). As I understand (I'm not lawyer), the copyright is
necessary for, and does not alter the terms of the GPLv2. Is there
something specific you're thinking of that invalidates this?
  


I don't know what Simon noticed, but I saw that you had indicated a GPL 
v3 license on the web page.  GPL2 is not compatible with GPL3, so that 
makes your contribution unusable by us.


Duncan Murdoch


I updated the patch to open with O_NOCTTY to prevent opening the tty as
the controlling terminal. Looks like this is default in BSD and GNU but
maybe not in OS X. I'd like to hear how it goes if you try it again. 


I see the rationale for a tty (in scope) connection. As you observed,
there are lots of options. However, some of them are designed to be used
when the terminal IS the controlling terminal, for example, if you were
writing a program like getty, so barring the use of R as a job control
shell (which would be cool also, but probably not in the scope of R),
some of the options need not be exposed. For instance, canonical mode
may never be necessary/appropriate. But it would be cool to use RTS/CTS,
XON/XOFF, blocking, and some of the other stuff that is not there yet. I
have some ideas on how to expose these features concisely.

I'll continue to work on this as time permits (i.e. probably at
weekend), with consideration for your suggestions. Thanks again,

-Matt



On Mon, 2010-04-26 at 14:18 -0400, Simon Urbanek wrote: 
 Matt,
 
 thanks for you efforts. We cannot directly use your patch due to licensing issues (please note the licenses in the files you are modifying - I don't think anyone can currently use the patch and redistribute the resulting R; also/or we may possibly need to clarify that the work is either done on behalf of the R-foundation or the copyright is assigned to R-foundation or something similar so future licensing issues can be solved by the Foundation since that is the copyright holder of most of R).
 
 Apart from that, the overall structure looks good, but the devil is in the details. It does not quite work for me on OS X (any read/writes just hang in the same way that it would if you used a file connection on the tty device) - I don't think it is as simple (AFAIR you have to make sure you open it such that it doesn't become the controlling terminal). Also it would definitely need blocking argument like most other connections have.
 
 In general I don't think serial is the right name (and scope) here - what we're really looking for a is a tty connection (and serial just an application of it). What you have so far is a file connection with setserial functionality on it - and I think that may be more easily done by really using setserial on the already implemented file connection. The difference with tty is the other parts such as flow control, modes etc. It's much more work to expose those, but I think that is what the direction would be. In fact it could well be that tty is simply file connection + termio so you don't have to re-invent the wheel (under the hood). Also that would give you many aspects for free since you could inherit from file at the R level.
 
 I hope it helps. I was thinking about the above but in the end decided to back off once I was looking at the flood of parameters you have to take care of in tty. But it would be nice if someone did that ;).
 
 Cheers,

 Simon
 
 
 On Apr 26, 2010, at 12:28 PM, Matt Shotwell wrote:
 
  All,

 
  Our discussion of serial interfaces last week motivated me to dig into
  the R connections API. In short, I spent the weekend writing a patch for
  version 2.11.0 that adds a serial connection. I posted a blog entry that
  gives instructions for applying, configuring, and compiling the patched
  version http://biostatmatt.com/archives/112.
 
  The patch currently only enables a serial connection for POSIX compliant
  OSs. It should NOT be considered well tested, though I feel it is fairly
  safe. I would really like to hear from someone who can try it on Mac OS
  X (and Windows to ensure that it has the correct 'null' behavior).
 
  Briefly, the connection utilizes (and checks for) the termios.h header.
  I opted not to extend the 'file' connection in a manner similar to the
  'pipe' connection because this might not be suitable under Win32. Hence,
  there are new read, write, flush, open, and close methods and a struct
  serialconn for the serial connection. Opens are non-blocking and binary
  only. Serial parameters can be passed when the connection is created. I
  overloaded the summary method in order for the user to see the serial
  settings.
 
  I've done my best to be consistent and conforming

Re: [Rd] Most recent R manuals [Was: Likely disruption to R-devel builds on Windows]

[Duncan Murdoch]

On 30/04/2010 10:22 AM, hadley wickham wrote:

Maybe Duncan could apply the same script that's being used for RNEWS
to the manuals?  An RSS feed of changes to the manuals would be really
useful.
  


My script is very NEWS specific.  The manuals would be harder.  You 
could get the diffs from svn pretty easily, but displaying them would be 
trickier:  do you display the diffs in the .texi source, or convert to 
HTML and display the diffs there, or what?  How much context around 
them?  Not impossible, but not trivial.


Duncan



Hadley

On Fri, Apr 30, 2010 at 8:16 AM, Gabor Grothendieck
ggrothendi...@gmail.com wrote:
 Some easy way to find out what has changed would be desirable here.

 On Fri, Apr 30, 2010 at 9:03 AM, Simon Urbanek
 simon.urba...@r-project.org wrote:

 On Apr 30, 2010, at 4:20 AM, Prof Brian Ripley wrote:

 We are planning to phase in some major changes to the R build process on 
Windows shortly, so expect problems and temporary unavailability of binary builds of R 
and of packages, and if you are building from sources, check out the latest version of 
the R-admin manual (in the sources) for the current state.


 To make sure no one has an excuse for not reading the current manuals - they 
are available (built nightly) at

 http://r.research.att.com/man/

 Cheers,
 Simon


 The planned changes are

 - to move the 32-bit builds to MinGW's recent release of gcc 4.5.0 (but 
with static linking of the Fortran and C++ runtimes: dynamic linking of C++ in packages 
crashes R).

 - to merge the 32-bit and 64-bit builds into a single installer and (for at 
least 98% of CRAN) a single binary for each package.

 NB: R-devel is not due for release until ca October and changes such as 
this are done early in the development cycle to allow plenty of time for them to be 
bedded down.  Please do take seriously the description as

 R version 2.12.0 Under development (unstable) (2010-04-29 r51864)
 

 --
 Brian D. Ripley,  rip...@stats.ox.ac.uk
 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



 __
 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] Most recent R manuals [Was: Likely disruption to R-devel builds on Windows]

[Duncan Murdoch]

On 30/04/2010 10:48 AM, Gabor Grothendieck wrote:

On Fri, Apr 30, 2010 at 10:39 AM, Duncan Murdoch murd...@stats.uwo.ca wrote:
 On 30/04/2010 10:22 AM, hadley wickham wrote:

 Maybe Duncan could apply the same script that's being used for RNEWS
 to the manuals?  An RSS feed of changes to the manuals would be really
 useful.


 My script is very NEWS specific.  The manuals would be harder.  You could
 get the diffs from svn pretty easily, but displaying them would be trickier:
  do you display the diffs in the .texi source, or convert to HTML and
 display the diffs there, or what?  How much context around them?  Not
 impossible, but not trivial.


Just making the source diffs easily accessible would be sufficient IMHO.


That's already available, but not too pretty.  E.g.

svn log -v https://svn.r-project.org/R/trunk/doc/manual | less

will show something like


r51865 | ripley | 2010-04-30 00:56:00 -0400 (Fri, 30 Apr 2010) | 1 line
Changed paths:
  M /trunk/doc/manual/R-admin.texi
  M /trunk/src/gnuwin32/CHANGES
  M /trunk/src/library/tools/R/install.R

tests starssrc/library/tools/R/install.R

r51858 | ripley | 2010-04-29 00:51:01 -0400 (Thu, 29 Apr 2010) | 1 line
Changed paths:
  M /trunk/doc/manual/R-exts.texi

tweak wording

r51854 | ripley | 2010-04-28 10:41:26 -0400 (Wed, 28 Apr 2010) | 1 line
Changed paths:
  M /trunk/doc/manual/R-exts.texi

more on portability
(etc.)

and for particular details, you can do something like

svn diff -c 51858 https://svn.r-project.org/R/trunk/doc/manual

which will give

Index: R-exts.texi
===
--- R-exts.texi (revision 51857)
+++ R-exts.texi (revision 51858)
@@ -10813,10 +10813,10 @@

The @R{} for Windows installers have for a long time allowed the value
of @code{R_HOME} to be recorded in the Windows Registry: this is
-optional but the default. Where is it is recorded has changed over the
-years to allow for multiple versions of @R{} to be installed at once,
-and as from @R{} 2.11.0, to allow 32- and 64-bit versions of @R{} to be
-installed on the same machine.
+optional but selected by default.  @emph{Where} is it is recorded has
+changed over the years to allow for multiple versions of @R{} to be
+installed at once, and as from @R{} 2.11.0, to allow 32- and 64-bit
+versions of @R{} to be installed on the same machine.

The basic Registry location is @code{Software\R-core\R}.  For an
administrative install this is under @code{HKEY_LOCAL_MACHINE} and on a

The non-trivial part is converting it into a nice display like what you 
pointed out in the Wiki.


Duncan Murdoch

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

Re: [Rd] Most recent R manuals [Was: Likely disruption to R-devel builds on Windows]

[Duncan Murdoch]

On 30/04/2010 2:11 PM, Gabor Grothendieck wrote:

On Fri, Apr 30, 2010 at 11:01 AM, Duncan Murdoch murd...@stats.uwo.ca wrote:
 On 30/04/2010 10:48 AM, Gabor Grothendieck wrote:

 On Fri, Apr 30, 2010 at 10:39 AM, Duncan Murdoch murd...@stats.uwo.ca
 wrote:
  On 30/04/2010 10:22 AM, hadley wickham wrote:
 
  Maybe Duncan could apply the same script that's being used for RNEWS
  to the manuals?  An RSS feed of changes to the manuals would be really
  useful.
 
 
  My script is very NEWS specific.  The manuals would be harder.  You
  could
  get the diffs from svn pretty easily, but displaying them would be
  trickier:
   do you display the diffs in the .texi source, or convert to HTML and
  display the diffs there, or what?  How much context around them?  Not
  impossible, but not trivial.

If you could mirror the manuals to googlecode you would automatically
get an HTML interface to the diffs. e.g.

http://code.google.com/p/sqldf/source/list

Go for it.  You've got more experience with googlecode than I do.

Duncan Murdoch

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

Re: [Rd] as.character() crashes R 2.11 on Win2008 x64 and Win7 64

[Duncan Murdoch]

On 30/04/2010 6:23 PM, Nicholas Hirschey wrote:

Dear List,



I have a Date vector, and converting to character causes Rnbsp;2.11 
tonbsp;crash on one machine running Win2008 x64 and another running Win7 x64. The 
code runs fine on R 2.10.


For example,
x lt;-nbsp;as.Date(rep(1:15000, 10), '1970-01-01')
y lt;- as.character(x)


At this point, Rgui crashes.


I get this using both the 32 and 64 bit 2.11.0 R builds.


I'd appreciate any suggestions for how to eliminate these crashes (particularly 
with the x64 version).
  


Use R-patched.

Duncan Murdoch


Thanks,

Nick



The windows error log and session information is pasted below:



gt; sessionInfo()

R version 2.11.0 (2010-04-22) 

i386-pc-mingw32 




locale:

[1] LC_COLLATE=English_United States.1252 

[2] LC_CTYPE=English_United States.1252   


[3] LC_MONETARY=English_United States.1252

[4] LC_NUMERIC=C  

[5] LC_TIME=English_United States.1252




attached base packages:

[1] stats graphics  grDevices utils datasets  methods   base



Log Name:  Application

Source:Application Error

Date:  4/28/2010 3:00:23 PM

Event ID:  1000

Task Category: (100)

Level: Error

Keywords:  Classic

User:  N/A

Computer:  


Description:

Faulting application name: Rgui.exe, version: 2.110.51801.0, time stamp: 
0x4bd040ca

Faulting module name: msvcrt.dll, version: 7.0.7600.16385, time stamp: 
0x4a5bda6f

Exception code: 0xc0fd

Fault offset: 0xa514

Faulting process id: 0x29cc

Faulting application start time: 0x01cae704e41e3609

Faulting application path: C:\Users\hirschen\Documents\R\R-2.11.0\bin\Rgui.exe

Faulting module path: C:\Windows\syswow64\msvcrt.dll

Report Id: 4c17218f-52f8-11df-9214-0026b95eb365

Event Xml:

lt;Event xmlns=http://schemas.microsoft.com/win/2004/08/events/eventgt;

  lt;Systemgt;

lt;Provider Name=Application Error /gt;

lt;EventID Qualifiers=0gt;1000lt;/EventIDgt;

lt;Levelgt;2lt;/Levelgt;

lt;Taskgt;100lt;/Taskgt;

lt;Keywordsgt;0x80lt;/Keywordsgt;

lt;TimeCreated SystemTime=2010-04-28T19:00:23.0Z /gt;

lt;EventRecordIDgt;3586lt;/EventRecordIDgt;

lt;Channelgt;Applicationlt;/Channelgt;

lt;Computergt;lt;/Computergt;

lt;Security /gt;

  lt;/Systemgt;

  lt;EventDatagt;

lt;Datagt;Rgui.exelt;/Datagt;

lt;Datagt;2.110.51801.0lt;/Datagt;

lt;Datagt;4bd040calt;/Datagt;

lt;Datagt;msvcrt.dlllt;/Datagt;

lt;Datagt;7.0.7600.16385lt;/Datagt;

lt;Datagt;4a5bda6flt;/Datagt;

lt;Datagt;c0fdlt;/Datagt;

lt;Datagt;a514lt;/Datagt;

lt;Datagt;29cclt;/Datagt;

lt;Datagt;01cae704e41e3609lt;/Datagt;

lt;Datagt;C:\Users\hirschen\Documents\R\R-2.11.0\bin\Rgui.exelt;/Datagt;

lt;Datagt;C:\Windows\syswow64\msvcrt.dlllt;/Datagt;

lt;Datagt;4c17218f-52f8-11df-9214-0026b95eb365lt;/Datagt;

  lt;/EventDatagt;

lt;/Eventgt;





[[alternative HTML version deleted]]

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



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

Re: [Rd] Possible bug in POSIX classes for R 2.11.0?

[Duncan Murdoch]

On 30/04/2010 12:46 PM, Lester Wollman wrote:

To the R development team;

I found an unusual behavior in zoo when I upgraded to R 2.11.0 - it abruptly 
terminated when I performed certain operations on large zoo objects.  I sent an 
e-mail to Achim Zeileis and he said this was a potential bug that I should 
report to the R development team.  The details are given below in the thread 
below.  Basically, I can crash R with this code:

library(zoo)
x - runif(14, 2009, 2010)
x - as.yearmon(x)
table(x)

This will not crash with a vector of size 13.

Achim got it to crash with the following code that did not use zoo:

x - rep(as.Date(1970-01-01), 14)
y - as.POSIXlt(x)
z - format(y, %d)

I did find a work around, so this is no longer an immediate problem for me, but 
it would be better if the problem didn't exist in the first place.  Thank you 
for your help.
  


Have you tried R-patched?  This looks like a bug that was fixed there 
recently.  See


https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=14267

for details.

Duncan Murdoch


Lester Wollman
Corporate Statistician
Symmetricom, Inc.
lwoll...@symmetricom.com



-Original Message-
From: Achim Zeileis [mailto:achim.zeil...@uibk.ac.at] 
Sent: Thursday, April 29, 2010 1:16 PM

To: Lester Wollman
Subject: Re: Unusual behavior of zoo and R2.11.0 - simple operation on large 
zoo object crashes R

Lester,

thanks for the report. The problem does not seem to be in zoo but in the 
new POSIX classes and/or their their coercion from Date.


The following should reproduce your crash:

x - rep(as.Date(1970-01-01), 14)
y - as.POSIXlt(x)
z - format(y, %d)

The reason is probably that R-core changed the internals of all the POSIX 
stuff. Furthermore, this problem appears to be fixed in 2.12.0 (the 
current devel version). Maybe you can ask on R-devel whether this is a 
know issue (my guess is that it is).


Thanks for the report  best wishes,
Z

On Thu, 29 Apr 2010, Lester Wollman wrote:

  

Achim,

 


I found unusual behavior, or even possibly a bug,  in zoo.  When I run the
code below, R crashes.  There is no error message,  R simply exits with no
warning.

 

 


library(zoo)

x - runif(14, 2009, 2010) # Random days in 2009

x - as.yearmon(x) # This works

table(x)   #  This crashes. print(x) also crashes R. 
summary(x) does not


 

 


However, if I change the number of random dates to 13, there is no
problem.

 


I have been using zoo for a few years with no problems,  including using
code similar to the one above.  I did just upgrade to R 2.11.0 and this is
my first use of zoo for a large vector since the upgrade.

 


I cannot tell if the problem is with zoo or R or my machine.  I tried
installing zoo from CRAN instead of R-Forge, but that did not help. 
Increasing the memory limit to 3G did not help either.


 


I attached relevant (and irrelevant) system information below.  I am using R
with Tinn-R and Tinn-R loads some packages (Hmisc, R2HTML, etc.)

 


Thank you for your help.

 

 


Lester Wollman

Corporate Statistician

Symmetricom, Inc.

lwoll...@symmetricom.com

 

 

 

 



sessionInfo()
  
 


R version 2.11.0 (2010-04-22)

i386-pc-mingw32

 


locale:

[1] LC_COLLATE=English_United States.1252  LC_CTYPE=English_United
States.1252LC_MONETARY=English_United States.1252

[4] LC_NUMERIC=C   LC_TIME=English_United
States.1252   

 


attached base packages:

[1] grDevices datasets  splines   graphics  stats tcltk utils
methods   base

 


other attached packages:

[1] svSocket_0.9-48 TinnR_1.0.3 R2HTML_2.0.0Hmisc_3.7-0
survival_2.35-8


 


loaded via a namespace (and not attached):

[1] cluster_1.12.3 grid_2.11.0lattice_0.18-5 svMisc_0.9-57

 

 


System Information:

Windows XP Professional Version 2002 Service Pack 3

 


Computer Information:

Dell with Intel CPU

T2600 @ 2.16 GHz, 1G of RAM

 

 

 


zoo information



packageDescription(zoo)
  

Package: zoo

Version: 1.6-3

Date: 2010-02-22

Title: Z's ordered observations

Author: Achim Zeileis, Gabor Grothendieck, Felix Andrews

Maintainer: Achim Zeileis achim.zeil...@r-project.org

Description: An S3 class with methods for totally ordered indexed
observations. It is particularly aimed at irregular time series of numeric
vectors/matrices and factors. zoo's key design goals are independence of a
particular index/date/time class and consistency with ts and base R by
providing methods to extend standard generics.

Depends: R (= 2.10.0), stats

Suggests: coda, chron, DAAG, fCalendar, fSeries, fts, its, lattice,
strucchange, timeDate, timeSeries, tis, tseries, xts

Imports: stats, utils, graphics, grDevices, lattice (= 0.18-1)

LazyLoad: yes

License: GPL-2

URL: http://R-Forge.R-project.org/projects/zoo/

Repository: R-Forge

Repository/R-Forge/Project: zoo

Repository/R-Forge/Revision: 688

Date/Publication: 2010-03-20 02:29:04

Packaged

Re: [Rd] split() bug? Inconsistent Windows/Linux behavior.

[Duncan Murdoch]

On 04/05/2010 6:45 PM, Matt Shotwell wrote:

This is odd, I think it may have something to do with this
  


Yes, it's definitely a bug in interaction() rather than split() per se.  
I'll take a look and see if I can fix it.


Duncan Murdoch
  

f - interaction(list(iris[,1], iris[,2]))
f[16]


[1] NA
  

unclass(f)[16]


[1] 785
  

nlevels(f)


[1] 781

Maybe do_split dereferencing beyond allocated memory?

  

interaction(list(iris[,1], iris[,2]), sep=-)



does not produce NA at index 16

-Matt

On Tue, 2010-05-04 at 16:37 -0400, Jay Emerson wrote:
  

I didn't see anything on this in the bug reports, and a search of the
archives had lots of false positives when searching on split to be
helpful.

I don't view this as particularly interesting or useful, but wanted to
report it because I stumbled on it (and don't remember ever seeing
invalid permissions as part of a segfault).  Yes, I realize this is
a silly example that you wouldn't actually do, but... there may be
other more interesting cases with the same problem.  The following was
R-2.10.0 on Linux (with a Windows-64 2.11.0 difference to follow
below):



data(iris)
split(1:nrow(iris), list(iris[,1], iris[,2]))
  

 *** caught segfault ***
address 0x7fc806cd3d0c, cause 'invalid permissions'

Traceback:
 1: split.default(1:nrow(iris), list(iris[, 1], iris[, 2]))
 2: split(1:nrow(iris), list(iris[, 1], iris[, 2]))

Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace

In contrast, R-2.11.0 in Windows-64:



data(iris)
split(1:nrow(iris), list(iris[,1], iris[,2]))
  

Traceback:
 1: split.default(1:nrow(iris), list(iris[, 1], iris[, 2]))
 2: split(1:nrow(iris), list(iris[, 1], iris[, 2]))
Error in split.default(1:nrow(iris), list(iris[, 1], iris[, 2])) :
  caught access violation - continue with care

However, the same commands with drop=TRUE returns something, though
the answers differ.  In Linux:



a - split(1:nrow(iris), list(iris[,1], iris[,2]), drop=TRUE)
length(a)
  

[1] 116

And in Windows, differing only in the extra returned element, which I
don't think should probably be part of the answer (there are no
missing values in the iris data):



a - split(1:nrow(iris), list(iris[,1], iris[,2]), drop=TRUE)
length(a)
  

[1] 117


a[117]
  

$NA
[1] 16

--
John W. Emerson (Jay)
Associate Professor of Statistics
Department of Statistics
Yale University
http://www.stat.yale.edu/~jay

__
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] split() bug? Inconsistent Windows/Linux behavior.

[Duncan Murdoch]

This is now fixed in R-devel (revision 51908), and R-patched (r51909).  
Thanks Jay for the nice reproducible example, and thanks Matt for 
localizing it to the interaction() function.


Duncan Murdoch

On 04/05/2010 4:37 PM, Jay Emerson wrote:

I didn't see anything on this in the bug reports, and a search of the
archives had lots of false positives when searching on split to be
helpful.

I don't view this as particularly interesting or useful, but wanted to
report it because I stumbled on it (and don't remember ever seeing
invalid permissions as part of a segfault).  Yes, I realize this is
a silly example that you wouldn't actually do, but... there may be
other more interesting cases with the same problem.  The following was
R-2.10.0 on Linux (with a Windows-64 2.11.0 difference to follow
below):

  

data(iris)
split(1:nrow(iris), list(iris[,1], iris[,2]))



 *** caught segfault ***
address 0x7fc806cd3d0c, cause 'invalid permissions'

Traceback:
 1: split.default(1:nrow(iris), list(iris[, 1], iris[, 2]))
 2: split(1:nrow(iris), list(iris[, 1], iris[, 2]))

Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace

In contrast, R-2.11.0 in Windows-64:

  

data(iris)
split(1:nrow(iris), list(iris[,1], iris[,2]))



Traceback:
 1: split.default(1:nrow(iris), list(iris[, 1], iris[, 2]))
 2: split(1:nrow(iris), list(iris[, 1], iris[, 2]))
Error in split.default(1:nrow(iris), list(iris[, 1], iris[, 2])) :
  caught access violation - continue with care

However, the same commands with drop=TRUE returns something, though
the answers differ.  In Linux:

  

a - split(1:nrow(iris), list(iris[,1], iris[,2]), drop=TRUE)
length(a)


[1] 116

And in Windows, differing only in the extra returned element, which I
don't think should probably be part of the answer (there are no
missing values in the iris data):

  

a - split(1:nrow(iris), list(iris[,1], iris[,2]), drop=TRUE)
length(a)


[1] 117
  

a[117]


$NA
[1] 16

--
John W. Emerson (Jay)
Associate Professor of Statistics
Department of Statistics
Yale University
http://www.stat.yale.edu/~jay

__
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] Sweave Feature Requests and Questions

[Duncan Murdoch]

Charlotte Maia wrote:

Hi everyone,

I would like to request the following features for Sweave:
1. The keep.source option, to respect empty lines in input.
  


I think it's too late for that one.  keep.source was introduced in 2006, 
and there were a large number of unreasonable complaints about it -- so 
many that I'm not going near that again.



2. The prefix.string option, to apply to all generated files, e.g. no
Rplots.pdf.
  


Why do you want to keep Rplots.pdf?  I think a more reasonable request 
is not to produce it at all.



3. That Sweave, doesn't change the graphics settings for the entire
Latex Document. By default including a pdf image, should use it's
actual size, rather than making it a fixed proportion of the text
width.
  


I think this is an option.  Use something like

\usepackage[nogin]{Sweave}

to turn it off.


4. A new option to allow generation of Serror chunks, where the R code
generates an error or a warning.
  


That's a good idea that has been suggested before.  I think it's just a 
matter of someone doing it (or it may have been done in one of the 
Sweave add-on packages).

Furthermore, any help appreciated here:
1. Does anyone know how to build Sweave documents, using Make, without
starting a new instance (or multiple instances) of R, every time Make
is called?
  


I think the generic answer here is that you shouldn't be using an OS 
where starting new instances is so time consuming.  Make is designed for 
OS's where it's rather cheap to start the same program many times.   So 
maybe you should suggest to Microsoft (I'm assuming you're on Windows) 
about that fact that it is so slow at this common task?



2. Does anyone know a simple workaround to problem 3, without killing
the entire Sweave.sty file?
  


Besides the one above, you can use \setkeys{Gin}  to change the default 
size of graphics.

Furthermore, I'm temped to stop Sweave from generating all the eps
files (I saw an option for this in the Sweave documentation), however
I'm concerned it may stop others from building the document, if they
use postscript.

Then again, do enough people use postscript, to warrant such consideration?
  


I think this depends on your audience, but probably most users of a 
document written using Sweave are just going to read the PDF that you 
produced, they aren't going to process it themselves.  On the other 
hand, those eps files are handy because they allow you to work with .dvi 
files, and .dvi previewers are still smarter than .pdf previewers, for 
things like reverse search.  (Use patchDVI so reverse searches go to the 
.Rnw file, not the intermediate .tex file.)  So I leave Sweave producing 
both pdf and eps.  Disk space is cheap.


Duncan Murdoch

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

Re: [Rd] update.packages fails with directory not found

[Duncan Murdoch]

Mike Prager wrote:

Windows XP.  I have just updated to R 2.11.0 and then run
update.packages. In the series of updates, a few will succeed, then I
get a failure like


package 'mvtnorm' successfully unpacked and MD5 sums checked
package 'party' successfully unpacked and MD5 sums checked
package 'PBSmodelling' successfully unpacked and MD5 sums checked
Error in normalizePath(path) : 
  path[1]=c:\Program Files\R\Library/PBSmodelling: The system cannot

find the file specified
  


Is that a cut and paste of the error message?  Normally R would double 
the backslashes when displaying a string, so it looks as though you've 
somehow got a path containing the control characters \P, \R, and \L.  
Did you set the lib.loc argument when you called update.packages?


Duncan Murdoch


Indeed, the path is missing, though it was there when I issued the
update.packages command.

???

--
Mike Prager, NC, USA

__
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] update.packages fails with directory not found

[Duncan Murdoch]

On 10/05/2010 8:28 AM, Mike Prager wrote:

On Mon, 10 May 2010 06:33:54 -0400, Duncan Murdoch
murdoch.dun...@gmail.com wrote:

Mike Prager wrote:
 Windows XP.  I have just updated to R 2.11.0 and then run
 update.packages. In the series of updates, a few will succeed, then I
 get a failure like


 package 'mvtnorm' successfully unpacked and MD5 sums checked
 package 'party' successfully unpacked and MD5 sums checked
 package 'PBSmodelling' successfully unpacked and MD5 sums checked
 Error in normalizePath(path) : 
   path[1]=c:\Program Files\R\Library/PBSmodelling: The system cannot

 find the file specified
   

Is that a cut and paste of the error message?  Normally R would double 
the backslashes when displaying a string, so it looks as though you've 
somehow got a path containing the control characters \P, \R, and \L.  
Did you set the lib.loc argument when you called update.packages?


Thank you!  Yes, it's cut and paste.  I did not set lib.loc in the
call (made through the Rgui.exe menu system), but I have the library
location defined in the environment:

R_LIBS=c:/Program Files/R/Library

I've been using this approach for several years, and it's worked
without problem until now.
  
I can't seem to reproduce this.  If it happens reproducibly on your 
system, could you please do the following:
print the result of installed.packages()[PBSmodelling,], .libPaths() 
and sessionInfo()?


A possible workaround is to get the names of all of your packages in the 
Library folder and install them, rather than using the update.packages() 
function.  This may fail if some of them aren't on CRAN or the other 
repositories.


Duncan Murdoch

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

Re: [Rd] update.packages fails with directory not found

[Duncan Murdoch]

On 11/05/2010 6:35 AM, Georgi Boshnakov wrote:

I posted a similar problem to this list but had no response.
The full email is copied below.
  


Thanks for reposting this.  I didn't see the original (I was travelling 
at the time).

In a nutshell, I traced the message to normalizePath,
which issues it. The directory does not exist because a move/rename  
directory command, issued at the end of the installation, failed. The  
directory you see would have been renamed to the eventual one otherwise.
  


I'll change normalizePath to generate a warning rather than an error.  
This may allow processing to continue.
Since it is the move/rename command which fails on otherwise  
(seemingly) successful installation, is it possible to try to copy the  
directory when renaming fails and, if successful, inform the user that  
a temporary directory has been left behind?
  


It was just a warning message about not moving the directory.  But the 
warning message itself triggered an error, which stopped the install.  
So maybe things will be okay if we just stop the error.


The big problem with this particular bug is that it is not reproducible 
on demand.  So I can make changes, but I have no idea if they are effective.


Duncan Murdoch


Georgi Boshnakov
Univeristy of Manchester


--

Message: 1
Date: Mon, 10 May 2010 00:07:50 -0400
From: Mike Prager mike.pra...@mhprager.com
To: r-de...@stat.math.ethz.ch
Subject: [Rd] update.packages fails with directory not found
Message-ID: t81fu5t8gg8crt5nm3h3d3rg6bcg7lr...@4ax.com
Content-Type: text/plain; charset=us-ascii

Windows XP.  I have just updated to R 2.11.0 and then run
update.packages. In the series of updates, a few will succeed, then I
get a failure like


package 'mvtnorm' successfully unpacked and MD5 sums checked
package 'party' successfully unpacked and MD5 sums checked
package 'PBSmodelling' successfully unpacked and MD5 sums checked
Error in normalizePath(path) :
   path[1]=c:\Program Files\R\Library/PBSmodelling: The system cannot
find the file specified


Indeed, the path is missing, though it was there when I issued the
update.packages command.

???

--
Mike Prager, NC, USA



--



- Forwarded message from georgi.boshna...@manchester.ac.uk -
 Date: Thu, 18 Feb 2010 10:43:11 +
 From: Georgi Boshnakov georgi.boshna...@manchester.ac.uk
  Subject: install.packages, normalizePath, file permissions
   To: r-devel@r-project.org

Dear developers,

I have a small but more or less well defined inquiry. Another, more  
general one for which I was not able to find information is towards  
the end of this messages. The question seems to be too technical for  
R-help, that is why I post it here.


When installing packages (Windows XP), occasionally the installation  
does not complete because, it seems, Windows locks some files. I  
normally ignore this as a minor annoyance but now I wish to ask  
students to install a number of often used packages by sourcing an R  
file and this becomes a problem.


Here is an example:

  

install.packages( file.path(fp,fgui_1.0-0.zip ), repos=NULL)


Warning in install.packages(file.path(fp, fgui_1.0-0.zip), repos = NULL) :
   argument 'lib' is missing: using 'p:/Rpack'
package 'fgui' successfully unpacked and MD5 sums checked
Error in normalizePath(path) :
   path[1]=p:\Rpack/fgui: The system cannot find the file specified


The circumstances are difficult to reproduce. For some reason, the  
system does not like fgui and maybe other packages. The p: drive  
above is network attached and and I have read/write access. Here is  
the result of traceback.


  

traceback()


7: normalizePath(instPath)
6: sprintf(gettext(fmt, domain = domain), ...)
5: gettextf(unable to move temporary installation '%s' to '%s',
normalizePath(file.path(tmpDir, curPkg)), normalizePath(instPath))
4: warning(gettextf(unable to move temporary installation '%s' to '%s',
normalizePath(file.path(tmpDir, curPkg)), normalizePath(instPath)),
domain = NA, call. = FALSE, immediate. = TRUE)
3: unpackPkg(pkgs[i], pkgnames[i], lib)
2: .install.winbinary(pkgs = pkgs, lib = lib, contriburl = contriburl,
method = method, available = available, destdir = destdir,
dependencies = dependencies, ...)
1: install.packages(file.path(fp, fgui_1.0-0.zip), repos = NULL)

The error seems to be thrown by the folloing chunk towards the end of  
.install.winbinary():


   ret - file.rename(file.path(tmpDir, curPkg), instPath)
   if(!ret)
 warning(gettextf(unable to move temporary installation '%s' to '%s',
  normalizePath(file.path(tmpDir, curPkg)),
  normalizePath(instPath)),
  domain = NA, call. = FALSE, immediate. = TRUE)
   ...

Apparently, renaming failed and a message is displayed.
The failure of rename.file may have left the directory specified

Re: [Rd] update.packages fails with directory not found

[Duncan Murdoch]

I've now also committed a change to the file.rename code (on Windows) so 
that it waits for the file copy to complete before returning.  It seems 
possible that it was returning too early, so the next step of the 
install failed.


I'd appreciate it if you could check whether the problems remain in 
R-devel, revision 51980 or later.  (A build of this revision should be 
on CRAN by tomorrow, at 
http://cran.r-project.org/bin/windows/base/rdevel.html .)


Duncan Murdoch


On 11/05/2010 7:47 AM, Duncan Murdoch wrote:

On 11/05/2010 6:35 AM, Georgi Boshnakov wrote:
 I posted a similar problem to this list but had no response.
 The full email is copied below.
   

Thanks for reposting this.  I didn't see the original (I was travelling 
at the time).

 In a nutshell, I traced the message to normalizePath,
 which issues it. The directory does not exist because a move/rename  
 directory command, issued at the end of the installation, failed. The  
 directory you see would have been renamed to the eventual one otherwise.
   

I'll change normalizePath to generate a warning rather than an error.  
This may allow processing to continue.
 Since it is the move/rename command which fails on otherwise  
 (seemingly) successful installation, is it possible to try to copy the  
 directory when renaming fails and, if successful, inform the user that  
 a temporary directory has been left behind?
   

It was just a warning message about not moving the directory.  But the 
warning message itself triggered an error, which stopped the install.  
So maybe things will be okay if we just stop the error.


The big problem with this particular bug is that it is not reproducible 
on demand.  So I can make changes, but I have no idea if they are effective.


Duncan Murdoch

 Georgi Boshnakov
 Univeristy of Manchester


 --

 Message: 1
 Date: Mon, 10 May 2010 00:07:50 -0400
 From: Mike Prager mike.pra...@mhprager.com
 To: r-de...@stat.math.ethz.ch
 Subject: [Rd] update.packages fails with directory not found
 Message-ID: t81fu5t8gg8crt5nm3h3d3rg6bcg7lr...@4ax.com
 Content-Type: text/plain; charset=us-ascii

 Windows XP.  I have just updated to R 2.11.0 and then run
 update.packages. In the series of updates, a few will succeed, then I
 get a failure like


 package 'mvtnorm' successfully unpacked and MD5 sums checked
 package 'party' successfully unpacked and MD5 sums checked
 package 'PBSmodelling' successfully unpacked and MD5 sums checked
 Error in normalizePath(path) :
path[1]=c:\Program Files\R\Library/PBSmodelling: The system cannot
 find the file specified


 Indeed, the path is missing, though it was there when I issued the
 update.packages command.

 ???

 --
 Mike Prager, NC, USA



 --



 - Forwarded message from georgi.boshna...@manchester.ac.uk -
  Date: Thu, 18 Feb 2010 10:43:11 +
  From: Georgi Boshnakov georgi.boshna...@manchester.ac.uk
   Subject: install.packages, normalizePath, file permissions
To: r-devel@r-project.org

 Dear developers,

 I have a small but more or less well defined inquiry. Another, more  
 general one for which I was not able to find information is towards  
 the end of this messages. The question seems to be too technical for  
 R-help, that is why I post it here.


 When installing packages (Windows XP), occasionally the installation  
 does not complete because, it seems, Windows locks some files. I  
 normally ignore this as a minor annoyance but now I wish to ask  
 students to install a number of often used packages by sourcing an R  
 file and this becomes a problem.


 Here is an example:

   
 install.packages( file.path(fp,fgui_1.0-0.zip ), repos=NULL)
 
 Warning in install.packages(file.path(fp, fgui_1.0-0.zip), repos = NULL) :

argument 'lib' is missing: using 'p:/Rpack'
 package 'fgui' successfully unpacked and MD5 sums checked
 Error in normalizePath(path) :
path[1]=p:\Rpack/fgui: The system cannot find the file specified


 The circumstances are difficult to reproduce. For some reason, the  
 system does not like fgui and maybe other packages. The p: drive  
 above is network attached and and I have read/write access. Here is  
 the result of traceback.


   
 traceback()
 
 7: normalizePath(instPath)

 6: sprintf(gettext(fmt, domain = domain), ...)
 5: gettextf(unable to move temporary installation '%s' to '%s',
 normalizePath(file.path(tmpDir, curPkg)), normalizePath(instPath))
 4: warning(gettextf(unable to move temporary installation '%s' to '%s',
 normalizePath(file.path(tmpDir, curPkg)), normalizePath(instPath)),
 domain = NA, call. = FALSE, immediate. = TRUE)
 3: unpackPkg(pkgs[i], pkgnames[i], lib)
 2: .install.winbinary(pkgs = pkgs, lib = lib, contriburl = contriburl,
 method = method, available = available, destdir = destdir,
 dependencies = dependencies, ...)
 1: install.packages

Re: [Rd] update.packages fails with directory not found

[Duncan Murdoch]

On 11/05/2010 6:21 PM, Mike Prager wrote:

On Tue, 11 May 2010 11:05:45 -0400, Duncan Murdoch
murdoch.dun...@gmail.com wrote:

  
I'd appreciate it if you could check whether the problems remain in 
R-devel, revision 51980 or later.  (A build of this revision should be 
on CRAN by tomorrow, at 
http://cran.r-project.org/bin/windows/base/rdevel.html .)




Thanks for trying to fix this. Here is a cut-and-paste [...edited]
from Rgui.exe.  Hope it helps.  MHP


R version 2.12.0 Under development (unstable) (2010-05-11 r51980)
Copyright (C) 2010 The R Foundation for Statistical Computing
ISBN 3-900051-07-0  [...]

  Natural language support but running in an English locale

[...]
Loading required package: survival
Loading required package: stats
Loading required package: utils
Loading required package: graphics
Loading required package: splines

Attaching package: 'Hmisc'
[...]

  


Was rJava among the packages loaded at the time you tried this?

update.packages(ask='graphics')


trying URL [...]
downloaded 1.0 Mb

package 'maps' successfully unpacked and MD5 sums checked
package 'rgl' successfully unpacked and MD5 sums checked
package 'rJava' successfully unpacked and MD5 sums checked
Warning: unable to move temporary installation 'c:\Program
Files\R\Library\file390c7e87\rJava' to 'c:\Program
Files\R\Library\rJava'
  


After the install was complete, was rJava present in Library?  Was it 
updated?  Was the temporary directory file390c7e87 still present?


Duncan Murdoch


package 'strucchange' successfully unpacked and MD5 sums checked
package 'svMisc' successfully unpacked and MD5 sums checked
package 'tkrplot' successfully unpacked and MD5 sums checked
package 'vcd' successfully unpacked and MD5 sums checked
package 'XML' successfully unpacked and MD5 sums checked
package 'zoo' successfully unpacked and MD5 sums checked

The downloaded packages are in
C:\Documents and Settings\mike.prager\Local
Settings\Temp\RtmpyrBgXD\downloaded_packages
Warning message:
In normalizePath(path) :
  path[1]=c:\Program Files\R\Library/rJava: The system cannot find
the file specified
  

traceback()

No traceback available 
  


__
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] update.packages fails with directory not found

[Duncan Murdoch]

On 12/05/2010 12:42 PM, Mike Prager wrote:

Shortened a bit further. Answers to queries are at the end.  MHP

Duncan Murdoch wrote on 5/11/2010 7:03 PM:
 On 11/05/2010 6:21 PM, Mike Prager wrote:
 On Tue, 11 May 2010 11:05:45 -0400, Duncan Murdoch
 murdoch.dun...@gmail.com wrote:
 I'd appreciate it if you could check whether the problems remain in 
 R-devel, revision 51980 or later.

 Thanks for trying to fix this. Here is a cut-and-paste [...edited]
 from Rgui.exe.  Hope it helps.  MHP

 R version 2.12.0 Under development (unstable) (2010-05-11 r51980)
 Copyright (C) 2010 The R Foundation for Statistical Computing
 ISBN 3-900051-07-0  [...]
 Was rJava among the packages loaded at the time you tried this?
 update.packages(ask='graphics')
 trying URL [...]
 downloaded 1.0 Mb

 package 'rJava' successfully unpacked and MD5 sums checked
 Warning: unable to move temporary installation 'c:\Program
 Files\R\Library\file390c7e87\rJava' to 'c:\Program
 Files\R\Library\rJava'
 After the install was complete, was rJava present in Library?  Was it 
 updated?  Was the temporary directory file390c7e87 still present?

[...]
 The downloaded packages are in
 C:\Documents and Settings\mike.prager\Local
 Settings\Temp\RtmpyrBgXD\downloaded_packages
 Warning message:
 In normalizePath(path) :
   path[1]=c:\Program Files\R\Library/rJava: The system cannot find
 the file specified

Answers:

rJava was not loaded when the update started.
After the install, rJava was no longer present in the library.
The temporary directory file390c7e87 was not present.  Checking my 
undelete program, the temp directory had existed and had contained the 
rJava package but was (and is) deleted.


  


I don't know what the problem is.  My current guesses:

 - Antivirus bugs.  Are you running some AV program?  Sometimes they 
interfere with other programs.
 - Permissions problems.  I don't know why rJava would have had 
different permissions than the other packages you successfully updated, 
but if it did, that could be a cause.
 - Windows bug.  R uses Windows services to move the temporary 
directory into place, and that's failing for no apparent reason. 

If you can follow Bill Dunlap's advice and monitor the process as it's 
taking place, you might be able to diagnose this, but I don't see a way 
to make any progress otherwise.


Duncan Murdoch

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

Re: [Rd] ranges and contiguity checking

[Duncan Murdoch]

On 12/05/2010 2:18 PM, James Bullard wrote:

Hi All,

I am interfacing to some C libraries (hdf5) and I have methods defined for
'[', these methods do hyperslab selection, however, currently I am
limiting slab selection to contiguous blocks, i.e., things defined like:
i:(i+k). I don't do any contiguity checking at this point, I just grab the
max and min of the range and them potentially do an in-memory subselection
which is what I am definitely trying to avoid. Besides using deparse, I
can't see anyway to figure out that these things (i:(i+k) and c(i, i+1,
..., i+k)) are different.

I have always liked how 1:10 was a valid expression in R (as opposed to
python where it is not by itself.), however I'd somehow like to know that
the thing was contiguous range without examining the un-evaluated
expression or worse, all(diff(i:(i+k)) == 1)


You can implement all(diff(x) == 1) more efficiently in C, but I don't 
see how you could hope to do any better than that without putting very 
un-R-like restrictions on your code.  Do you really want to say that


A[i:(i+k)]

is legal, but

x - i:(i+k)
A[x]

is not?  That will be very confusing for your users.  The problem is 
that objects don't remember where they came from, only arguments to 
functions do, and functions that make use of this fact mainly do it for 
decorating the output (nice labels in plots) or making error messages 
more intelligible. 


Duncan Murdoch

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

[Rd] Using Sweave in hostile environments

[Duncan Murdoch]

I'm trying to put together a poster using the LaTeX a0poster package and 
including some things from pstricks to get gradient shading, etc.


The problem is that the default environments used by Sweave don't work 
where I need them.  A simple code chunk like


eval=FALSE=
x - 1
@

buried in a minipage within a psshadowbox gives the error

Runaway argument?
 x - 1 \end {Sinput} \end {Schunk} and the resulting variable would\ETC.
D:/test.tex:302: Paragraph ended before \FV@
BeginScanning was complete


Has anyone solved this problem?  One way I see that might work is to put 
the code chunk outside the environment and use SaveVerbatim to save it, 
then just put \BUseVerbatim or \LUseVerbatim in place where I need it.  
But because I'm using Sweave, I somehow need to redefine the Sinput, 
Soutput and maybe the Schunk environments to do that, and I don't see 
how to do so. 


Duncan Murdoch

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

Re: [Rd] Using Sweave in hostile environments

[Duncan Murdoch]

Just for the archives, a partial answer to my question:

I was unable to find a definition for the Sinput environment that would 
work, but relatively minor changes to some of the RweaveLatex functions 
cause Sweave to generate SaveVerbatim environments rather than Sinput 
environments, and that's enough to get things to work.  So the example 
below would be handled using


chunkname, eval=FALSE, saveVerbatim=TRUE=
x - 1
@

somewhere safe, and then

\BUseVerbatim[fontshape=sl]{chunkname.in.1}

in the box.  Each piece of input or output will be saved in a separate 
verbatim piece, and they each need to be used explicitly:  you'll 
probably want to look at the .tex file to figure out the names.


This is pretty rough and I won't commit it to R, but I've attached the 
patch file (against R trunk rev 51988) in case anyone else wants to use it.


Duncan Murdoch

On 13/05/2010 10:19 AM, Duncan Murdoch wrote:
I'm trying to put together a poster using the LaTeX a0poster package and 
including some things from pstricks to get gradient shading, etc.


The problem is that the default environments used by Sweave don't work 
where I need them.  A simple code chunk like


eval=FALSE=
x - 1
@

buried in a minipage within a psshadowbox gives the error

Runaway argument?
  x - 1 \end {Sinput} \end {Schunk} and the resulting variable would\ETC.
D:/test.tex:302: Paragraph ended before \FV@
BeginScanning was complete


Has anyone solved this problem?  One way I see that might work is to put 
the code chunk outside the environment and use SaveVerbatim to save it, 
then just put \BUseVerbatim or \LUseVerbatim in place where I need it.  
But because I'm using Sweave, I somehow need to redefine the Sinput, 
Soutput and maybe the Schunk environments to do that, and I don't see 
how to do so. 


Duncan Murdoch

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


Index: Sweave.R
===
--- Sweave.R(revision 51988)
+++ Sweave.R(working copy)
@@ -368,7 +368,8 @@
 split=FALSE, strip.white=true, include=TRUE,
 pdf.version=grDevices::pdf.options()$version,
 pdf.encoding=grDevices::pdf.options()$encoding,
-concordance=FALSE, expand=TRUE)
+concordance=FALSE, expand=TRUE,
+saveVerbatim=FALSE)
 options[names(dots)] - dots
 
 ## to be on the safe side: see if defaults pass the check
@@ -482,8 +483,12 @@
 thisline - thisline + 1
 openSchunk - TRUE
 }
-cat(\\begin{Sinput},
-file=chunkout, append=TRUE)
+if (options$saveVerbatim) 
+cat(\\begin{SaveVerbatim}{, options$label, 
.in., nce, }, sep=, 
+file=chunkout, append=TRUE)

+else
+cat(\\begin{Sinput},
+   file=chunkout, append=TRUE)
 openSinput - TRUE
 }
cat(\n, paste(getOption(prompt), dce[1L:leading], 
sep=, collapse=\n),
@@ -516,7 +521,10 @@
 if(length(output)  (options$results != hide)){
 
 if(openSinput){
-cat(\n\\end{Sinput}\n, file=chunkout, append=TRUE)
+   if (options$saveVerbatim) 
+   cat(\n\\end{SaveVerbatim}\n, file=chunkout, 
append=TRUE)
+   else
+cat(\n\\end{Sinput}\n, file=chunkout, 
append=TRUE)
 linesout[thisline + 1L:2L] - srcline
 thisline - thisline + 2L
 openSinput - FALSE
@@ -529,8 +537,12 @@
 thisline - thisline + 1L
 openSchunk - TRUE
 }
-cat(\\begin{Soutput}\n,
-file=chunkout, append=TRUE)
+if(options$saveVerbatim)
+cat(\\begin{SaveVerbatim}{, options$label, 
.out., nce, }\n,
+   sep=, file=chunkout, append=TRUE)
+else
+cat(\\begin{Soutput}\n,
+   file=chunkout, append=TRUE)
 linesout[thisline + 1L] - srcline
 thisline - thisline + 1L
 }
@@ -552,7 +564,10 @@
 remove(output)
 
 if(options$results==verbatim){
-cat(\n\\end{Soutput}\n, file=chunkout, append=TRUE)
+   if (options$saveVerbatim)
+   cat(\n\\end{SaveVerbatim}\n, file=chunkout

Re: [Rd] Restrict access to variables in parent environment

[Duncan Murdoch]

On 14/05/2010 10:14 AM, thmsfuller...@gmail.com wrote:

Hello All,

By default, a reference of a variable in a function cause R to look
for the variable in the parent environment if it is not available in
the current environment (without generating any errors or warnings).
I'm wondering if there is a way to revert this behaviors, such that it
will not look for the parent environment and will generate an error if
the variable is not available in the current environment. Is this
tuning has to be done at the C level?


You could do that by setting the environment of the function to 
emptyenv(), but it will not be pretty.  Remember that everything in R is 
an object, so you won't have access to the base level objects like +, or 
mean, or any other function.


Duncan Murdoch

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

Re: [Rd] where is libRmath.a libRmath.so

[Duncan Murdoch]

On 14/05/2010 4:52 PM, Dave Lubbers wrote:
R 2.7.2 -   the manual says 
configure

make

Which is what I did.  So I did read the manual and followed the directions. 
The manual is too terse to get me there.
  


You used the wrong tense.  In referring to R 2.7.2, only past tenses are 
grammatically correct.


If you want to say the manual *is* too terse, then you need to install 
R 2.11.0.


Duncan Murdoch

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

Re: [Rd] R in sandbox/jail (long question)

[Duncan Murdoch]

On 18/05/2010 10:38 PM, Assaf Gordon wrote:

Hello,

I have a setup similar to Rweb (  http://www.math.montana.edu/Rweb/ ):
I get R scripts from users and need to execute them in in a safe manner (they 
are executed automatically, without human inspection).

I would like to limit the user's script to reading from STDIN and writing to 
STDOUT/ERR.
Specifically, preventing any kind of interaction with the underlying operating 
system (files, sockets, system(), etc.).

I've found this old thread:
http://r.789695.n4.nabble.com/R-in-a-sandbox-jail-td921991.html
But for technical reasons I'd prefer not to setup a chroot jail.

I have written a patch that adds a --sandbox parameter.
When this parameter is used, the user's script can't create any kind of connection object 
or run system().
  


That sounds too restrictive.  R uses connections internally in various 
places, with no reference to the file system.  It also uses them when 
reading its own files.  So if you stop a user from creating connections, 
you'll somehow need to distinguish between user-created ones and 
internally necessary ones:  not easy.



My plan is to run R like this:

cat INPUT | R --vanila --slave --sandbox --file SCRIPT.R  OUTPUT

Where 'INPUT' is my chosen input and 'SCRIPT.R' is the script submitted by the 
user.
If the script tries to create a conncetion or run a disabled function, an error 
is printed.

This is the patch:
http://cancan.cshl.edu/labmembers/gordon/files/R_2.11.0_sandbox.patch

So my questions are:
1. Would you be willing to consider this feature for inclusion ?
2. Are there any other 'dangerous' functions I need to intercept ( .Internal 
perhaps ?)
  


.Internal is needed by tons of base functions.  So again, you'll need to 
distinguish where the call is coming from, and that's not easy.


Duncan Murdoch

All comments and suggestions are welcomed,
thanks,
   -gordon

__
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] Is it possible to generate an error when a function is reassigned?

[Duncan Murdoch]

thmsfuller...@gmail.com wrote:

Hello All,

length() is a function. If I accidentally assign something else to
length, it will give me some unexpected results.

Although the freedom to redefine any funcion maybe good in sometime,
it may be unwanted in many other cases. Is there a way to forbidden
such changes on functions?

  
You aren't changing length(), you're creating a new function with the 
same name that hides the original one.  The distinction is important 
because packages with namespaces will not be affected by your error, 
it's not really as serious as you might think.


The general advice to protect yourself from mistakes like this is to 
limit how much of your code you keep in the global environment.  Keep 
your code in scripts and source them into an empty environment, or 
(better) put your code into a package and use a namespace.  If you make 
a mistake and hide an important function you'll still cause local 
problems, but you may find it easier to fix them.


Duncan Murdoch

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

[Rd] Indexing bug?

[Duncan Murdoch]

Is this expected behaviour?

x - factor(c(c, b, a,c))
results - c(c=4, b=5)
results[x]

giving

 results[x]
NAbc NA
 NA54   NA

(i.e. it appears to give results[levels(x)]


whereas results[as.character(x)] does what I expected:

as.character(x)
results[as.character(x)]

 as.character(x)
[1] c b a c
 results[as.character(x)]
  cb NAc
  45   NA4

Duncan Murdoch

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

Re: [Rd] Indexing bug?

[Duncan Murdoch]

Duncan Murdoch wrote:

Is this expected behaviour?

x - factor(c(c, b, a,c))
results - c(c=4, b=5)
results[x]

giving

  results[x]
NAbc NA
  NA54   NA

(i.e. it appears to give results[levels(x)]
  


Thanks to all for pointing out my misinterpretation.It's clearly not 
a bug.


Duncan Murdoch


whereas results[as.character(x)] does what I expected:

as.character(x)
results[as.character(x)]

  as.character(x)
[1] c b a c
  results[as.character(x)]
   cb NAc
   45   NA4

Duncan Murdoch



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

Re: [Rd] segfault on 2.11.0 with large POSIXct vector using as.character

[Duncan Murdoch]

Jeff Ryan wrote:

Running as.character on a large POSIXct causes a segfault on my 2.11
(2010-04-22) install.  Seems to crash at around 9e4 ... on OSX and Ubuntu at
least.
  


This has been fixed for a while in R-patched.  The 2.11.1 release on 
Monday should be fine. 

Apparently people aren't running the betas/release candidates.  You 
really should run the test versions to flush out bugs.  If you'd run the 
pre-release versions of 2.11.0, this bug would likely have been found 
before release.  The standard tests can miss things; the advantage of 
open source is there are many eyes looking for bugs.  But if those eyes 
are closed, the model doesn't work.


Duncan Murdoch
  

invisible(as.character(Sys.time()+1:7e4))
invisible(as.character(Sys.time()+1:8e4))
invisible(as.character(Sys.time()+1:9e4))


Error: segfault from C stack overflow


  

invisible(as.character(Sys.time()+1:5e5))


Error: segfault from C stack overflow

Thanks,
Jeff

  

sessionInfo()


R version 2.11.0 (2010-04-22)
x86_64-apple-darwin10.2.0

locale:
[1] en_US.UTF-8/en_US.UTF-8/C/C/en_US.UTF-8/en_US.UTF-8

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base


  

sessionInfo()


R version 2.11.0 (2010-04-22)
i486-pc-linux-gnu

locale:
 [1] LC_CTYPE=en_US.utf8   LC_NUMERIC=C
 [3] LC_TIME=en_US.utf8LC_COLLATE=en_US.utf8
 [5] LC_MONETARY=C LC_MESSAGES=en_US.utf8
 [7] LC_PAPER=en_US.utf8   LC_NAME=C
 [9] LC_ADDRESS=C  LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.utf8 LC_IDENTIFICATION=C

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base
  





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

Re: [Rd] Bug with ..0

[Duncan Murdoch]

On 30/05/2010 3:13 PM, Gabor Grothendieck wrote:

This function call returns 3 but should return 32.  ..0 has no special
significance in R as far I know yet it seems to be acting as if it
were ..1 .  Comments?
  


Actually, ..0 is a reserved symbol.  (This is just barely documented in 
the R Language Defn, with more detail in R Internals.)  It stands for 
the zeroth element of ...  That definition makes no sense (indexing of 
... starts at 1), so we should probably generate an error when you use 
it, and perhaps when you try to redefine it by using it as an argument.  
But this is really a case of you doing something you shouldn't, and the 
error handling not slapping you on the wrist.


Duncan Murdoch
  

ff - function(..0, ...) ..0
ff(32, 3)


[1] 3

  

R.version.string


[1] R version 2.11.0 Patched (2010-04-26 r51822)
  

win.version()


[1] Windows Vista (build 6002) Service Pack 2

__
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] Bug with ..0

[Duncan Murdoch]

On 30/05/2010 3:44 PM, Gabor Grothendieck wrote:

Note that ?Reserved lists ..1, ..2, to ..9 but does not list ..0.
  


Which version are you looking at? Mine says ‘..1’, ‘..2’ etc, In fact, 
the code just looks for the pattern of two dots followed by something 
that can be converted to a long; see isDDName in src/main/dstruct.c.

Also, why is it reserved?  What is the future intended use?
  


As far as I know, there is none. It is reserved simply because it 
follows the pattern of ..n. It would not be hard to make ..0 specially 
unreserved, but what would be the point?


Duncan Murdoch

On Sun, May 30, 2010 at 3:40 PM, Duncan Murdoch
murdoch.dun...@gmail.com wrote:
  

On 30/05/2010 3:13 PM, Gabor Grothendieck wrote:


This function call returns 3 but should return 32.  ..0 has no special
significance in R as far I know yet it seems to be acting as if it
were ..1 .  Comments?

  

Actually, ..0 is a reserved symbol.  (This is just barely documented in the
R Language Defn, with more detail in R Internals.)  It stands for the
zeroth element of ...  That definition makes no sense (indexing of ...
starts at 1), so we should probably generate an error when you use it, and
perhaps when you try to redefine it by using it as an argument.  But this is
really a case of you doing something you shouldn't, and the error handling
not slapping you on the wrist.

Duncan Murdoch

  

ff - function(..0, ...) ..0
ff(32, 3)



[1] 3


  

R.version.string



[1] R version 2.11.0 Patched (2010-04-26 r51822)

  

win.version()



[1] Windows Vista (build 6002) Service Pack 2

__
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] GUI's and R background processes

[Duncan Murdoch]

Anne George wrote:

Hello,

I am new to R and have created an application using R 2.10, with a graphical UI 
using TclTk 8.5, running on windows 7, quad core machine.
The intention of the application is to launch calculations and display results 
on a graphical dashboard.

I've reached a roadblock, and I need to confirm that the following CANNOT be 
done. I've been trying to find a mechanism for doing the following:

1. From the dashboard, start a huge calculation (i.e. call a function) that 
take at least 30 seconds to run, but without tying up the other dashboard 
features
2. Dashboard can detect when the calculation is finished
3. Dashboard can display incremental results as the calculation runs (i.e. 
status/progress)

The requirement is to kickoff 4 calculations (#1), but I don't want the user to 
wait for the others to finish.
The calculations are not dependent. I just need to display results.

I've been reading that threading in R is not an option. I tried using the 
multicore package, but that is still synchronous. I looked at multicore, 
fork(), addTaskCallback(), and TclTk threading, and none of these seem like an 
option.

Is there a way to launch multiple R scripts from controller that can 
communicate back and forth? I believe this means that the separate processes 
are able to communicate.

I certainly appreciate any direction you can provide. I really want to find 
some good news to tell the boss, though, since we went down this path before 
realizing the limitations.


This is possible, but not easy.  You need to work at the C level.

The key is that the long running processes need to periodically tell R 
to check for user events by calling


R_ProcessEvents();
R_CheckUserInterrupt();

at the C level.  This works in Windows in current versions, and I 
believe on all platforms in R-devel.


The code should be prepared for R to call it again during 
R_ProcessEvents, so if it is not re-entrant, it should arrange to signal 
an error.  It should be prepared for the R_CheckUserInterrupt call to 
never return if the user happened to interrupt the calculation.


You probably only want one processor to do this, and let it check on the 
other cores to see if there are any results ready.



Duncan Murdoch

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

Re: [Rd] with(x, Recall()) Crash

[Duncan Murdoch]

On 06/07/2010 5:38 PM, McGehee, Robert wrote:

R-devel,
I discovered a segfault in my R code that boiled down to my incorrect
use of the Recall() function embedded within a with() function. Since
segfaults are generally bad things, even when it's the user's fault for
writing nonsense code, I thought I'd pass along the offending code. I've
tested the crash on R 2.11.1 (on Linux and Mac), but not in devel
versions of R. 
  


Thanks for posting that.  It does still exist on R-devel, and as you 
say, it shouldn't.  I'll fix it.


Duncan Murdoch

HTH, Robert

  

x - 1
with(x, Recall())


*** caught segfault ***
address 0x1db, cause 'memory not mapped'

Traceback:
 1: eval(expr, envir, enclos)
 2: Recall()
 3: eval(expr, envir, enclos)
 4: eval(substitute(expr), data, enclos = parent.frame())
 5: with.default(x, Recall())
 6: with(x, Recall())

  

R.version


   _
platform   x86_64-unknown-linux-gnu
arch   x86_64
os linux-gnu
system x86_64, linux-gnu
status
major  2
minor  11.1
year   2010
month  05
day31
svn rev52157
language   R
version.string R version 2.11.1 (2010-05-31)

Robert McGehee, CFA
Geode Capital Management, LLC
One Post Office Square, 28th Floor | Boston, MA | 02109
Tel: 617/392-8396Fax:617/476-6389
mailto:robert.mcge...@geodecapital.com


  

This e-mail, and any attachments hereto, are intended for use by the


addressee(s) only and may contain information that is (i) confidential
information of Geode Capital Management, LLC and/or its affiliates,
and/or (ii) proprietary information of Geode Capital Management, LLC
and/or its affiliates. If you are not the intended recipient of this
e-mail, or if you have otherwise received this e-mail in error, please
immediately notify me by telephone (you may call collect), or by e-mail,
and please permanently delete the original, any print outs and any
copies of the foregoing. Any dissemination, distribution or copying of
this e-mail is strictly prohibited. 


__
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] Large discrepancies in the same object being saved to .RData

[Duncan Murdoch]

On 06/07/2010 9:04 PM, julian.tay...@csiro.au wrote:

Hi developers,



After some investigation I have found there can be large discrepancies in the same object 
being saved as an external xx.RData file. The immediate repercussion of this 
is the possible increased size of your .RData workspace for no apparent reason.



The function and its three scenarios below highlight these discrepancies. Note that the object 
being returned is exactly the same in each circumstance. The first scenario simply loops over a set 
of lm() models from a simulated set of data. The second adds a reasonably large matrix calculation 
within the loop. The third highlights exactly where the discrepancy lies. It appears that when the 
object is saved to an xx.RData it is still burdened, in some capacity, with the objects 
created in the function. Only deleting these objects at the end of the function ensures the 
realistic size of the returned object. Performing gc() after each of these short simulations shows 
that the Vcells that are accumulated in the function environment appear to remain after 
the function returns. These cached remains are then transferred to the .RData upon saving of the 
object(s). This is occurring quite broadly across the Windows 7 (R 2.10.1) and 64 Bit Ubuntu Linux 
(R 2.9.0) systems that I us!

e.




A similar problem was partially pointed out four years ago



http://tolstoy.newcastle.edu.au/R/help/06/03/24060.html



and has been made more obvious in the scenarios given below.



Admittedly I have had many problems with workspace .RData sizes over the years 
and it has taken me some time to realise what is actually occurring. Can 
someone enlighten myself and my colleagues as to why the objects created and 
evaluated in a function call stack are saved, in some capacity, with the 
returned object?
  


I haven't worked through your example, but in general the way that local 
objects get captured is when part of the return value includes an 
environment.  Examples of things that include an environment are locally 
created functions and formulas.  It's probably the latter that you're 
seeing.  When R computes the result of y ~ . or a similar formula, it 
attaches a pointer to the environment in which the calculation took 
place, so that later when the formula is used, it can look up y there.  
For example, in your line


lm(y ~ ., data = dat)


from your code, the formula y ~ . needs to be computed before R knows 
that you've explicitly listed a dataframe holding the data, and before 
it knows whether the variable y is in that dataframe or is just a local 
variable in the current function.


Since these are just pointers to the environment, this doesn't take up 
much space in memory, but when you save the object to disk, a copy of 
the whole environment will be made, and that can end up wasting up a lot 
of space if the environment contains a lot of things that aren't needed 
by the formula.


Duncan Murdoch


Cheers,

Julian



### small simulation from a clean directory



lmfunc - function(loop = 20, add = FALSE, gr = FALSE){

  lmlist - rmlist - list()

  set.seed(100)

  dat - data.frame(matrix(rnorm(100*100), ncol = 100))

  rm - matrix(rnorm(10), ncol = 1000)

  names(dat)[1] - y

  i - 1

  for(i in 1:loop) {

lmlist[[i]] - lm(y ~ ., data = dat)

if(add)

rmlist[[i]] - rm

  }

  fm - lmlist[[loop]]

  if(gr) {

print(what - ls(envir = sys.frame(which = 1)))

remove(list = setdiff(what, fm))

  }

  fm

}



# baseline gc()



  

gc()



  used (Mb) gc trigger (Mb) max used (Mb)

Ncells 153325  4.1 35  9.4   35  9.4

Vcells  99228  0.8 786432  6.0   386446  3.0



## 1. simple lm() simulation



  

lmtest1 - lmfunc()



  

gc()



  used (Mb) gc trigger (Mb) max used (Mb)

Ncells 184470  5.0 407500 10.9   35  9.4

Vcells 842169  6.51300721 10.0  1162577  8.9



  

save(lmtest1, file = lm1.RData)



  

system(ls -s lm1.RData)



4312 lm1.RData



## A moderate increase in Vcells; .RData object around 4.5 Mb



## 2. add matrix calculation to loop



  

lmtest2 - lmfunc(add = TRUE)



  

gc()



   used (Mb) gc trigger (Mb) max used (Mb)

Ncells  209316  5.6 407500 10.9   405340 10.9

Vcells 3584244 27.44175939 31.9  3900869 29.8



  

save(lmtest2, file = lm2.RData)



  

system(ls -s lm2.RData)



19324 lm2.RData



## A enormous increase in Vcells; .RData object is now 19Mb+



## 3. delete all objects in function call stack



  

lmtest3 - lmfunc(add = TRUE, gr = TRUE)



  

gc()



   used (Mb) gc trigger (Mb) max used (Mb)

Ncells  210766  5.7 467875 12.5   467875 12.5

Vcells 3615863 27.66933688 52.9  6898609 52.7



  

save(lmtest3, file = lm3.RData)



  

system(ls -s lm3.RData)



320 lm3.RData



## A minimal increase in Vcells; .RData object is now 320Kb



  

sapply(ls(pattern

Re: [Rd] Telling Windows how to find DLL's from R?

[Duncan Murdoch]

On 09/07/2010 2:38 PM, Dominick Samperi wrote:

Is it possible to set Windows' search path from within R, or
to tell Windows how to find a DLL in some other way from
R? Specifically, if a package DLL depends on another DLL
the normal requirement is that the second DLL be in the
search path so Windows can find it (there are other tricks,
but they apply at the Windows level, not at the R level).
  



I haven't tried this, but can't you use Sys.setenv() to change the PATH 
to what you want?  Presumably you'll want to change it back afterwards.


Duncan Murdoch

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

Re: [Rd] Large discrepancies in the same object being saved to .RData

[Duncan Murdoch]

On 10/07/2010 2:33 PM, Paul Johnson wrote:

On Wed, Jul 7, 2010 at 7:12 AM, Duncan Murdoch murdoch.dun...@gmail.com wrote:
  

On 06/07/2010 9:04 PM, julian.tay...@csiro.au wrote:


Hi developers,



After some investigation I have found there can be large discrepancies in
the same object being saved as an external xx.RData file. The immediate
repercussion of this is the possible increased size of your .RData workspace
for no apparent reason.



  

I haven't worked through your example, but in general the way that local
objects get captured is when part of the return value includes an
environment.



Hi, can I ask a follow up question?

Is there a tool to browse *.Rdata files without loading them into R?
  


I don't know of one.  You can load the whole file into an empty 
environment, but then you lose information about where did it come from?


Duncan Murdoch

In HDF5 (a data storage format we use sometimes), there is a CLI
program h5dump that will spit out line-by-line all the contents of a
storage entity.  It will literally track through all the metadata, all
the vectors of scores, etc.  I've found that handy to see what's
really  in there in cases like the one that OP asked about.
Sometimes, we find that there are things that are in there by
mistake, as Duncan describes, and then we can try to figure why they
are in there.

pj





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

Re: [Rd] Large discrepancies in the same object being saved to .RData

[Duncan Murdoch]

On 10/07/2010 10:10 PM, bill.venab...@csiro.au wrote:

Well, I have answered one of my questions below.  The hidden
environment is attached to the 'terms' component of v1.

To see this 

  

lapply(v1, environment)


$coefficients
NULL

$residuals
NULL

$effects
NULL

$rank
NULL

$fitted.values
NULL

$assign
NULL

$qr
NULL

$df.residual
NULL

$xlevels
NULL

$call
NULL

$terms
environment: 0x021b9e18

$model
NULL

  

rm(junk, envir = with(v1, environment(terms)))
usedVcells()


[1] 96532
  
 



This is still a bit of a trap for young (and old!) players...

I think the main point in my mind is why is it that object.size()
excludes enclosing environments in its reckonings?
  


I think the idea is that the environment is not part of the object, it 
is just referenced by the object. In fact, there are at least two 
references to the environment in your second example:


environment(v1$terms)

and

attr(v1$terms, .Environment)

both refer to it. So you can't just add the size of an environment every 
time you come across it, you would need to keep track of whether it had 
already been counted or not. So as ?object.size says,


Associated space (e.g. the environment of a function and what the
pointer in a ‘EXTPTRSXP’ points to) is not included in the
calculation.

If you really want to know how much space an object will take when saved, 
probably the only reliable way is to save the object and look at how much space 
the file takes.
  


Duncan Murdoch


Bill Venables.

-Original Message-
From: Venables, Bill (CMIS, Cleveland) 
Sent: Sunday, 11 July 2010 11:40 AM

To: 'Duncan Murdoch'; 'Paul Johnson'
Cc: 'r-devel@r-project.org'; Taylor, Julian (CMIS, Waite Campus)
Subject: RE: [Rd] Large discrepancies in the same object being saved to .RData

I'm still a bit puzzled by the original question.  I don't think it
has much to do with .RData files and their sizes.  For me the puzzle
comes much earlier.  Here is an example of what I mean using a little
session

  

usedVcells - function() gc()[Vcells, used]
usedVcells()### the base load


[1] 96345

### Now look at what happens when a function returns a formula as the
### value, with a big item floating around in the function closure:

  

f0 - function() {


+ junk - rnorm(1000)
+ y ~ x
+ }
  

v0 - f0()
usedVcells()   ### much bigger than base, why?


[1] 10096355
  

v0 ### no obvious envirnoment


y ~ x
  

object.size(v0)  ### so far, no clue given where


   ### the extra Vcells are located.
372 bytes

### Does v0 have an enclosing environment?

  

environment(v0) ### yep.


environment: 0x021cc538
  

ls(envir = environment(v0)) ### as expected, there's the junk


[1] junk
  

rm(junk, envir = environment(v0))  ### this does the trick.
usedVcells()


[1] 96355

### Now consider a second example where the object
### is not a formula, but contains one.

  

f1 - function() {


+ junk - rnorm(1000)
+ x - 1:3
+ y - rnorm(3)
+ lm(y ~ x)
+ }

  

v1 - f1()
usedVcells()  ### as might have been expected.


[1] 10096455

### in this case, though, there is no 
### (obvious) enclosing environment


  
environment(v1)  


NULL
  

object.size(v1)  ### so where are the junk Vcells located?


7744 bytes
  

ls(envir = environment(v1))  ### clearly wil not work


Error in ls(envir = environment(v1)) : invalid 'envir' argument

  

rm(v1) ### removing the object does clear out the junk.
usedVcells()


[1] 96366
  


And in this second case, as noted by Julian Taylor, if you save() the
object the .RData file is also huge.  There is an environment attached
to the object somewhere, but it appears to be occluded and entirely
inaccessible.  (I have poked around the object components trying to
find the thing but without success.)

Have I missed something?

Bill Venables.

-Original Message-
From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org] On 
Behalf Of Duncan Murdoch
Sent: Sunday, 11 July 2010 10:36 AM
To: Paul Johnson
Cc: r-devel@r-project.org
Subject: Re: [Rd] Large discrepancies in the same object being saved to .RData

On 10/07/2010 2:33 PM, Paul Johnson wrote:
  

On Wed, Jul 7, 2010 at 7:12 AM, Duncan Murdoch murdoch.dun...@gmail.com wrote:
  


On 06/07/2010 9:04 PM, julian.tay...@csiro.au wrote:

  

Hi developers,



After some investigation I have found there can be large discrepancies in
the same object being saved as an external xx.RData file. The immediate
repercussion of this is the possible increased size of your .RData workspace
for no apparent reason.



  


I haven't worked through your example, but in general the way that local
objects get captured is when part of the return value includes an
environment.

  

Hi, can I ask a follow up question?

Is there a tool to browse *.Rdata files without loading them into R?
  



I don't know of one.  You can load

Re: [Rd] Large discrepancies in the same object being saved to .RData

[Duncan Murdoch]

On 11/07/2010 1:30 PM, Prof Brian Ripley wrote:

On Sun, 11 Jul 2010, Tony Plate wrote:

Another way of seeing the environments referenced in an object is using 
str(), e.g.:



f1 - function() {

+ junk - rnorm(1000)
+ x - 1:3
+ y - rnorm(3)
+ lm(y ~ x)
+ }

v1 - f1()
object.size(f1)

1636 bytes

grep(Environment, capture.output(str(v1)), value=TRUE)

[1]   .. ..- attr(*, \.Environment\)=environment: 0x01f11a30 
[2]   .. .. ..- attr(*, \.Environment\)=environment: 0x01f11a30 


'Some of the environments in a few cases': remember environments have 
environments (and so on), and that namespaces and packages are also 
environments.  So we need to know about the environment of 
environment(v1$terms), which also gets saved (either as a reference or 
as an environment, depending on what it is).


And this approach does not work for many of the commonest cases:


f - function() {

+ x - pi
+ g - function() print(x)
+ return(g)
+ }

g - f()
str(g)

function ()
  - attr(*, source)= chr function() print(x)

ls(environment(g))

[1] g x

In fact I think it works only for formulae.


-- Tony Plate

On 7/10/2010 10:10 PM, bill.venab...@csiro.au wrote:

Well, I have answered one of my questions below.  The hidden
environment is attached to the 'terms' component of v1.


Well, not really hidden.  A terms component is a formula (see 
?terms.object), and a formula has an environment just as a closure 
does.  In neither case does the print() method tell you about it -- 
but ?formula does.




I've just changed the default print method for formulas to display the 
environment if it is not globalenv(), which is the rule used for 
closures as well.  So now in R-devel:


 as.formula(y ~ x)
y ~ x

as before, but

 as.formula(y ~ x, env=new.env())
y ~ x
environment: 01f83400

Duncan Murdoch

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

Re: [Rd] R.exe crashes on R v2.12.0dev (Windows Vista)

[Duncan Murdoch]

On 26/07/2010 5:15 AM, Henrik Bengtsson wrote:

Just FYI: Problem remains (on same system) with R version 2.12.0
Under development (unstable) (2010-07-21 r52590):

Problem signature:
  Problem Event Name:   APPCRASH
  Application Name: R.exe
  Application Version:  2.120.52590.0
  Application Timestamp:4c471362
  Fault Module Name:R.exe
  Fault Module Version: 2.120.52590.0
  Fault Module Timestamp:   4c471362
  Exception Code:   c005
  Exception Offset: 240e
  OS Version:   6.0.6002.2.2.0.256.6


What is your OS? I don't know the MS numbering scheme...

Duncan Murdoch


  Locale ID:1033
  Additional Information 1: 8772
  Additional Information 2: 9431192a7274b0ee769861df31ecee58
  Additional Information 3: f768
  Additional Information 4: 930d06d3f6aed4162dca7601993082f5

Anyone knows if there anything else I can do to provide more debug
information on this?

/Henrik

On Sat, May 22, 2010 at 10:37 AM, Henrik Bengtsson h...@stat.berkeley.edu 
wrote:

Using the latest developers version of R [2.12.0 Under development
(unstable) (2010-05-21 r52061)], R.exe crashes:

%ProgramFiles%/R/R-2.12.0dev/bin/i386/R.exe

with Windows reporting:

Problem signature:
 Problem Event Name:   APPCRASH
 Application Name: R.exe
 Application Version:  2.120.52061.0
 Application Timestamp:4bf638bd
 Fault Module Name:R.exe
 Fault Module Version: 2.120.52061.0
 Fault Module Timestamp:   4bf638bd
 Exception Code:   c005
 Exception Offset: 1d94
 OS Version:   6.0.6002.2.2.0.256.6
 Locale ID:1033
 Additional Information 1: 1c1d
 Additional Information 2: e064c795479179a5f08d19e37de8915e
 Additional Information 3: 50ea
 Additional Information 4: 02a385f4f3dc3301c3a9d270f946

same occurs when calling:

%ProgramFiles%/R/R-2.12.0dev/bin/R.exe

However,

C:\Users\hb\braju.com.R\R.matlab,R-forge%ProgramFiles%/R/R-2.12.0dev/bin/i386/Rterm.exe
-e sessionInfo()

R version 2.12.0 Under development (unstable) (2010-05-21 r52061)
Copyright (C) 2010 The R Foundation for Statistical Computing
ISBN 3-900051-07-0
Platform: i386-pc-mingw32/i386 (32-bit)

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.


sessionInfo()

R version 2.12.0 Under development (unstable) (2010-05-21 r52061)
i386-pc-mingw32

locale:
[1] LC_COLLATE=English_United States.1252
[2] LC_CTYPE=English_United States.1252
[3] LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C
[5] LC_TIME=English_United States.1252

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base



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


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

Re: [Rd] R.exe crashes on R v2.12.0dev (Windows Vista)

[Duncan Murdoch]

On 26/07/2010 10:25 AM, Henrik Bengtsson wrote:

Shame on me; I put important only in the subject line.

It's Windows Vista Business 32-bit (Service Pack 2) English with the
latest updates.
  


Oops, didn't notice that.  I don't have a Vista machine to test on.  I 
don't see the crash on a slightly newer build of R on XP SP3 or Windows 7.


If you know of a debugger that can dump a stack trace at the time of the 
crash, that would be helpful information.  (We used to use Dr. Watson 
for this, but I don't think it works in Vista/Win 7.  I've heard of 
something called userdump, but never tried it.)


Duncan Murdoch

/Henrik

On Mon, Jul 26, 2010 at 1:30 PM, Duncan Murdoch
murdoch.dun...@gmail.com wrote:
 On 26/07/2010 5:15 AM, Henrik Bengtsson wrote:

 Just FYI: Problem remains (on same system) with R version 2.12.0
 Under development (unstable) (2010-07-21 r52590):

 Problem signature:
  Problem Event Name:   APPCRASH
  Application Name: R.exe
  Application Version:  2.120.52590.0
  Application Timestamp:4c471362
  Fault Module Name:R.exe
  Fault Module Version: 2.120.52590.0
  Fault Module Timestamp:   4c471362
  Exception Code:   c005
  Exception Offset: 240e
  OS Version:   6.0.6002.2.2.0.256.6

 What is your OS? I don't know the MS numbering scheme...

 Duncan Murdoch

  Locale ID:1033
  Additional Information 1: 8772
  Additional Information 2: 9431192a7274b0ee769861df31ecee58
  Additional Information 3: f768
  Additional Information 4: 930d06d3f6aed4162dca7601993082f5

 Anyone knows if there anything else I can do to provide more debug
 information on this?

 /Henrik

 On Sat, May 22, 2010 at 10:37 AM, Henrik Bengtsson h...@stat.berkeley.edu
 wrote:

 Using the latest developers version of R [2.12.0 Under development
 (unstable) (2010-05-21 r52061)], R.exe crashes:

 %ProgramFiles%/R/R-2.12.0dev/bin/i386/R.exe

 with Windows reporting:

 Problem signature:
  Problem Event Name:   APPCRASH
  Application Name: R.exe
  Application Version:  2.120.52061.0
  Application Timestamp:4bf638bd
  Fault Module Name:R.exe
  Fault Module Version: 2.120.52061.0
  Fault Module Timestamp:   4bf638bd
  Exception Code:   c005
  Exception Offset: 1d94
  OS Version:   6.0.6002.2.2.0.256.6
  Locale ID:1033
  Additional Information 1: 1c1d
  Additional Information 2: e064c795479179a5f08d19e37de8915e
  Additional Information 3: 50ea
  Additional Information 4: 02a385f4f3dc3301c3a9d270f946

 same occurs when calling:

 %ProgramFiles%/R/R-2.12.0dev/bin/R.exe

 However,


 
C:\Users\hb\braju.com.R\R.matlab,R-forge%ProgramFiles%/R/R-2.12.0dev/bin/i386/Rterm.exe
 -e sessionInfo()

 R version 2.12.0 Under development (unstable) (2010-05-21 r52061)
 Copyright (C) 2010 The R Foundation for Statistical Computing
 ISBN 3-900051-07-0
 Platform: i386-pc-mingw32/i386 (32-bit)

 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.

 sessionInfo()

 R version 2.12.0 Under development (unstable) (2010-05-21 r52061)
 i386-pc-mingw32

 locale:
 [1] LC_COLLATE=English_United States.1252
 [2] LC_CTYPE=English_United States.1252
 [3] LC_MONETARY=English_United States.1252
 [4] LC_NUMERIC=C
 [5] LC_TIME=English_United States.1252

 attached base packages:
 [1] stats graphics  grDevices utils datasets  methods   base


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





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

Re: [Rd] R CMD build wiped my computer (from R-help)

[Duncan Murdoch]

On 28/07/2010 8:10 PM, Ray Brownrigg wrote:

NOTE: Now submitted to R-devel, as this seems more appropriate.

I may have spoken too soon about this having been fixed. (see below).

If I create another unusual but not 'invalid' filename in the R subdirectory, the 
behaviour is different from that reported below, and is similar to the original poster's 
output (the third unlink command, where xyz was ~):


circa  ls -al RColorBrewer/R
total 140
-rwxr-xr-x  1 ray  ecs  43988 Apr 17  2005ColorBrewer.R~*
-rw-r--r--  1 ray  ecs  0 Jul 29 09:57residuals.MCMCglmm.R?xyz


Ray clarified to me that this filename was residuals.MCMCglmm.R 
preceded by 3 spaces and followed by a carriage return and xyz.



drwxr-xr-x  2 ray  ecs   4096 Jul 29 12:02 ./
drwxr-xr-x  5 ray  ecs   4096 Jul 29 11:49 ../
-rwxr-xr-x  1 ray  ecs  43988 Jul 29 09:57 ColorBrewer.R*
-rwxr-xr-x  1 ray  ecs  43988 Apr 17  2005 ColorBrewer.R~*
-rw-r--r--  1 ray  ecs  0 Jul 29 09:58 residuals.MCMCglmm.R
circa
circa
circa  R CMD build RColorBrewer
* checking for file 'RColorBrewer/DESCRIPTION' ... OK
* preparing 'RColorBrewer':
* checking DESCRIPTION meta-information ... OK
* checking whether 'INDEX' is up-to-date ... NO
* use '--force' to overwrite the existing 'INDEX'
* removing junk files
unlink RColorBrewer/R/   ColorBrewer.R~
unlink RColorBrewer/R/ColorBrewer.R
unlink RColorBrewer/R/   residuals.MCMCglmm.R
xyz


That certainly looks bad.  I can't reproduce it on Windows; it doesn't 
allow that filename.  So I'll have to leave this for a Unix-alike user.


Duncan Murdoch


unlink RColorBrewer/R/residuals.MCMCglmm.R
unlink RColorBrewer/R/ColorBrewer.R~
rmdir RColorBrewer/R
* checking for LF line-endings in source and make files
* checking for empty or unneeded directories
* building 'RColorBrewer_1.0-3.tar.gz'

circa

Ray Brownrigg

On Thu, 29 Jul 2010, Ray Brownrigg wrote:

On Thu, 29 Jul 2010, Duncan Murdoch wrote:

On 28/07/2010 10:01 AM, Jarrod Hadfield wrote:

Hi Marc,

Thanks for the info on recovery - most of it can pieced together from
backups but a quick, cheap and easy method of recovery would have been
nicer.

My main concern is that this could happen again and that the bug is
not limited to R 2.9. I would think that an accidental carriage return
at the end of a file name (even a temporary one) would be a reasonably
common phenomenon (I'm surprised I hadn't done it before).

If you can put together a recipe to reproduce the problem (or a less
extreme version of R deleting files it shouldn't), we'll certainly fix
it.  But so far all we've got are guesses about what might have gone
wrong, and I don't think anyone has been able to reproduce the problem
on current R.

Duncan:

It looks to me like it has already been fixed, if indeed that was the
problem.  In R-2.10.1, I tried to reproduce the problem (using
RColorBrewer, since that was the smallest package I have a local copy of),
and the build produced this:

* removing junk files
* excluding invalid files from 'RColorBrewer'
Subdirectory 'R' contains invalid file names:
  residuals.MCMCglmm.R xyz

where the space shown between the R and the xyz was a newline
character. [I didn't dare try using a ~ :-)]

Ray Brownrigg


Duncan Murdoch


Cheers,

Jarrod

On 28 Jul 2010, at 14:04, Marc Schwartz wrote:

Jarrod,

Noting your exchange with Martin, Martin brings up a point that
certainly I missed, which is that somehow the tilde ('~') character
got into the chain of events. As Martin noted, on Linuxen/Unixen
(including OSX), the tilde, when used in the context of file name
globbing, refers to your home directory. Thus, a command such as:

 ls ~

will list the files in your home directory. Similarly:

 rm ~

will remove the files there as well. If the -rf argument is added,
then the deletion becomes recursive through that directory tree,
which appears to be the case here.

I am unclear, as Martin appears to be, as to the steps that caused
this to happen. That may yet be related in some fashion to Duncan's
hypothesis.

That being said, the use of the tilde character as a suffix to
denote that a file is a backup version, is not limited to Fedora or
Linux, for that matter. It is quite common for many text editors
(eg. Emacs) to use this. As a result, it is also common for many
applications to ignore files that have a tilde suffix.

Based upon your follow up posts to the original thread, it would
seem that you do not have any backups. The default ext3 file system
that is used on modern Linuxen, by design, makes it a bit more
difficult to recover deleted files. This is due to the unlinking of
file metadata at the file system data structure level, as opposed to
simply marking the file as deleted in the directory structures, as
happens on Windows.

There is a utility called ext3undel
(http://projects.izzysoft.de/trac/ext3undel ), which is a wrapper of
sorts to other undelete utilities such as PhotoRec and foremost. I
have not used it/them, so cannot speak from personal experience. Thus

Re: [Rd] transpose of complex matrices in R

[Duncan Murdoch]

Robin Hankin wrote:

Hello everybody

When one is working with complex matrices, transpose  very nearly 
always means

*Hermitian* transpose, that is, A[i,j] - Conj(A[j,i]).
One often writes A^* for the Hermitian transpose.

I have only once seen a  real-life case
where transposition does not occur simultaneously with complex conjugation.
And I'm not 100% sure that that wasn't a mistake.

Matlab and Octave sort of recognize this, as A' means the  Hermitian 
transpose of A.


In R, this issue makes t(), crossprod(), and tcrossprod() pretty much 
useless to me.


OK, so what to do?  I have several options:

1.  define functions myt(), and mycrossprod() to get round the problem:
myt - function(x){t(Conj(x))}

2.  Try to redefine t.default():

  t.default - function(x){if(is.complex(x)){return(base::t(Conj(x)))} 
else {return(base::t(x))}}
(This fails because of infinite recursion, but I don't quite understand 
why).
  


You should call base::t.default, not base::t.  Then this will work.  The 
same solution fixes the one below, though you won't even need the base:: 
prefix on t.default.


Duncan Murdoch


3.  Try to define a t.complex() function:
t.complex - function(x){t(Conj(x))}
(also fails because of recursion)

4. Try a kludgy workaround:
   t.complex - function(x){t(Re(x)) - 1i*t(Im(x))}


Solution 1 is not good because it's easy to forget to use myt() rather 
than t()

and it does not seem to be  good OO practice.

As Martin Maechler points out, solution 2 (even if it worked as desired)
would break the code of everyone who writes a myt() function.

Solution 3 fails and solution 4 is kludgy and inefficient.

Does anyone have any better ideas?







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

Re: [Rd] Disappearance of the file quot;NEWSquot;

[Duncan Murdoch]

On 01/08/2010 2:02 PM, Ben Bolker wrote:

Laurent lgautier at gmail.com writes:


Dear R-developpers,

The file NEWS disappeared in r5243, and the authoritative source of 
information for what has changed in R is in ./doc/NEWS.Rd.


A quick glance at NEWS was extremely helpful for knowing what has 
changed, and whether building a (more) recent development version was 
needed to test changes, or verify that they would not break existing code.


 [snip to make Gmane happy]

  Agreed.  This change also breaks the link on the R developers
page:

https://svn.r-project.org/R/trunk/NEWS

although one can still, sort of, get to the information via

http://developer.r-project.org/RSSfeeds.html


I'll fix the link.  In the meantime you can still see the processed news 
online at


http://stat.ethz.ch/R-manual/R-devel/NEWS (plain text)

or

http://stat.ethz.ch/R-manual/R-devel/doc/html/NEWS.html (HTML)

I think it would not be a good idea to put a stub in place of the NEWS 
file.  Sometimes the stub would be newer than the source NEWS.Rd file 
(depending on how the source had been obtained), and make would skip it: 
 so we'd have to force it to be made every time, necessary or not.


Duncan Murdoch

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

Re: [Rd] problem with dl tag in tools::Rd2HTML

[Duncan Murdoch]

On 05/08/2010 5:18 PM, Michael Lachmann wrote:


Duncan Murdoch-2 wrote:


What version are you using?  I don't see that in current R patched.




I see this in version 2.11.1.
This is the code I ran to generate it:
page - utils:::.getHelpFile(?options)
tools::Rd2HTML(page,out=t.html)

in the generated file, t.html, the first dl tag is such a case.


Thanks.  It is still there after all.  I'll take a look...

Duncan Murdoch

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

Re: [Rd] [R-SIG-Mac] Question about line type in contour() function (R 2.11.1)

[Duncan Murdoch]

On 05/08/2010 8:46 PM, David B. Thompson, Ph.D., P.E., D.WRE, CFM wrote:

On Aug 5, 2010, at 5:20 PM, Duncan Murdoch wrote:


On 05/08/2010 7:18 PM, David B. Thompson, Ph.D., P.E., D.WRE, CFM wrote:

I'm running R 2.11.1 (MacBook Pro and OS X 10.6.4) and am trying to set a line 
type in the contour() function. What I did was:


 u-seq(0.005,0.995,0.005)
 v-u
 p-rep(0,length(u)*length(u))
 dim(p)-c(length(v),length(v))
 for (i in 1:length(u)) for (j in 1:length(v)) p[i,j]-u[i]^2+v[j]^2
 contour(u,v,p)


This produces a nice contour plot, as expected. However, if I execute:


contour(u,v,p,lty=2)

I still get a solid line drawn.


snip
A partial workaround:
x - contourLines(u, v, p)
plot(range(u), range(v), type=n)
lapply(x, function(c) lines(c, lty=2)




Thanks for the quick response. I wondered about the grid size, but what I used 
is about what it takes to get a nice-looking curve. I could play with the grid 
size a bit to see if I can get a decent curve and a dashed line.

I wondered if it might be grid size. That was the only thing I could think of 
that was different between the two datasets. I should have followed my instinct 
and test it. Good call.

I can use the workaround, I think. I'll give that a go in the morning and 
hopefully get over my hump and deliver the analyses.


I've moved this from r-sig-mac to r-devel; it's not a Mac problem.  I've 
also added back a bit of the context for readers here.


A little bit more on this:  the problem only affects contour() when 
labels are being drawn, and only if method is set to flattest (the 
default) or edge.  If you set drawLabels=FALSE or method=simple you 
won't see it.  I think I should be able to fix this after all.


Duncan Murdoch

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

Re: [Rd] [R-SIG-Mac] Question about line type in contour() function (R 2.11.1)

[Duncan Murdoch]

On 06/08/2010 7:52 AM, Duncan Murdoch wrote:

On 05/08/2010 8:46 PM, David B. Thompson, Ph.D., P.E., D.WRE, CFM wrote:

On Aug 5, 2010, at 5:20 PM, Duncan Murdoch wrote:


On 05/08/2010 7:18 PM, David B. Thompson, Ph.D., P.E., D.WRE, CFM wrote:

I'm running R 2.11.1 (MacBook Pro and OS X 10.6.4) and am trying to set a line 
type in the contour() function. What I did was:


u-seq(0.005,0.995,0.005)
v-u
p-rep(0,length(u)*length(u))
dim(p)-c(length(v),length(v))
for (i in 1:length(u)) for (j in 1:length(v)) p[i,j]-u[i]^2+v[j]^2
contour(u,v,p)

This produces a nice contour plot, as expected. However, if I execute:


contour(u,v,p,lty=2)

I still get a solid line drawn.


snip
A partial workaround:
x - contourLines(u, v, p)
plot(range(u), range(v), type=n)
lapply(x, function(c) lines(c, lty=2)



Thanks for the quick response. I wondered about the grid size, but what I used 
is about what it takes to get a nice-looking curve. I could play with the grid 
size a bit to see if I can get a decent curve and a dashed line.

I wondered if it might be grid size. That was the only thing I could think of 
that was different between the two datasets. I should have followed my instinct 
and test it. Good call.

I can use the workaround, I think. I'll give that a go in the morning and 
hopefully get over my hump and deliver the analyses.


I've moved this from r-sig-mac to r-devel; it's not a Mac problem.  I've 
also added back a bit of the context for readers here.


A little bit more on this:  the problem only affects contour() when 
labels are being drawn, and only if method is set to flattest (the 
default) or edge.  If you set drawLabels=FALSE or method=simple you 
won't see it.  I think I should be able to fix this after all.



Fixed now in R-patched and R-devel.

Duncan Murdoch

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

Re: [Rd] parent.frame(1) of a S4 method is not a calling environment.

[Duncan Murdoch]

Vitaly S. wrote:

Martin Morgan mtmor...@fhcrc.org writes:
  

So,  can I be sure that for such functions parent.frame(2) will always work?
What are the additional rules?
  

callNextMethod() will cause additional problems; the idea that you'll
grab things from somewhere other than function arguments doesn't seem
like a robust design, even if it's used in some important parts of R.

Martin




That make it difficult to handle unevaluated expressions in methods. A solution
would be to explicitly require the users to use quote() or expression(),  and
then to use the expression in the signature. Slightly unpleasant, though.

  


You could use formulas for that.  If you pass in

formula = ~ x + y*z

then environment(formula) will be the right evaluation environment, and 
formula[[2]] will be the unevaluated x + y*z.


Duncan Murdoch


Standardised, simpler syntax like .() in  ggplot and plyr,  would be handy here.
Hopefully .() is not grabbed for something else in meanwhile:).

Vitaly.

__
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

[Rd] Does anyone use Sweave (RweaveLatex) option expand=FALSE?

[Duncan Murdoch]

I am trying to improve the error reporting in Sweave documents, so that 
if you have a syntax error in a code chunk, it will tell you which line 
of your input file contained the error.


For example, currently you get this:

Error:  chunk 1 (label=named)
Error in parse(text = chunk) : unexpected symbol in x - foo bar
Execution halted

and I'd like errors to be more like this:

Error:  chunk 1 (label=named)
Error in parse(text = chunk, srcfile = srcfile) :
 test.Rnw:9:10: unexpected symbol
9: x - foo bar
   ^
Execution halted

It turns out that this requires changes that make the expand=FALSE 
option quite hard to implement.  Is anyone using it?  For those who 
don't know it, expand=FALSE means that a code chunk like


echo=TRUE, keep.source=TRUE,expand=FALSE=
z - 3
named
@

will be displayed as

 z - 3
 named

rather than expanding the named chunk.  I'd like to drop the option, so 
that the default behaviour (which has always been equivalent to expand 
= TRUE) would be the only behaviour.


Duncan Murdoch

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

Re: [Rd] Does anyone use Sweave (RweaveLatex) option expand=FALSE?

[Duncan Murdoch]

On 19/08/2010 3:17 PM, Marc Schwartz wrote:

On Aug 19, 2010, at 2:07 PM, Duncan Murdoch wrote:

 I am trying to improve the error reporting in Sweave documents, so that if 
you have a syntax error in a code chunk, it will tell you which line of your input 
file contained the error.
 
 For example, currently you get this:
 
 Error:  chunk 1 (label=named)

 Error in parse(text = chunk) : unexpected symbol in x - foo bar
 Execution halted
 
 and I'd like errors to be more like this:
 
 Error:  chunk 1 (label=named)

 Error in parse(text = chunk, srcfile = srcfile) :
 test.Rnw:9:10: unexpected symbol
 9: x - foo bar
   ^
 Execution halted
 
 It turns out that this requires changes that make the expand=FALSE option quite hard to implement.  Is anyone using it?  For those who don't know it, expand=FALSE means that a code chunk like
 
 echo=TRUE, keep.source=TRUE,expand=FALSE=

 z - 3
 named
 @
 
 will be displayed as
 
  z - 3

  named
 
 rather than expanding the named chunk.  I'd like to drop the option, so that the default behaviour (which has always been equivalent to expand = TRUE) would be the only behaviour.
 
 Duncan Murdoch



I don't. So 1 go ahead and drop it vote...

You may want to post this to R-Help though Duncan, as I suspect there may be 
more Sweave users there than here...
  


I probably will before I go ahead with this, but I may as well start on 
this group.


Duncan

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

Re: [Rd] Does anyone use Sweave (RweaveLatex) option expand=FALSE?

[Duncan Murdoch]

On 19/08/2010 4:29 PM, Claudia Beleites wrote:

I never used it.

I got curious, though. What would be a situation that benefits of this option?
  


When I put it in, I thought it would be for people who were writing 
about Sweave.


Duncan Murdoch

Maybe a use case could be found by brute force (grep all .Rnw files on CRAN 
for the option?


Claudia




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

Re: [Rd] Does anyone use Sweave (RweaveLatex) option expand=FALSE?

[Duncan Murdoch]

On 19/08/2010 5:07 PM, Kevin Coombes wrote:
I use it, frequently. The idea for it goes back to some of Knuth's 
original literate programming ideas for developing weave and tangle when 
he was writing TeX (the program).  I want to be able to document the 
pieces of some complex algorithm without having to see all of the gory 
details.  For instance, I have code that looks like the following.  
(Note that this is typed on the fly rather than copied from actual 
source, so there may be typos.)


Okay, thanks.  I'll keep it in.  So now I have a question:  suppose
you have an error (syntax error at this point, maybe some other kinds of 
error in the future) in the getInfoAboutThisSample chunk, but that 
chunk wasn't eval'd, mainloop was eval'd.  So the error is going to be 
reported as occurring in chunk mainloop, but with a line number from 
somewhere else in the file.  Is that a problem?


Duncan Murdoch




mainloop,keep.source=TRUE,expand=FALSE=
for (i in 1:nSamples) {
getInfoAboutThisSample
 for (j in 1:nChromosomes) {
getChromosomeDataForCurrentSample
normalizeChromosomeData
findSegments
computeSignificance
writeResults
 }
}
@

Each of the chunks is itself a fairly long piece of code defined and 
documented somewhere else.  (Some of them may themselves be written in 
the same form to reduce the final size of a chunk to something a human 
has a chance of understanding. That's the difference between weave and 
tangle in the original implementation.)   By blocking expansion, I can 
focus on the main steps without having them lost in pages and pages of code.


So I vote strongly for retaining expand=FALSE.

Best,
Kevin

Duncan Murdoch wrote:

On 19/08/2010 4:29 PM, Claudia Beleites wrote:

I never used it.

I got curious, though. What would be a situation that benefits of 
this option?
  
When I put it in, I thought it would be for people who were writing 
about Sweave.


Duncan Murdoch

Maybe a use case could be found by brute force (grep all .Rnw files 
on CRAN for the option?


Claudia



__
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] Sweave *, showWarnings=TRUE ?

[Duncan Murdoch]

Martin Maechler wrote:

Thank you Duncan, for expanding Sweave functionality,
notably considering error handling.

Related to that is the topic of handling warning messages.
  


I thought someone (Fritz?  One of the Sweave support package writers?) 
was working on the issue of including error and warning messages in 
Sweave output.  My changes don't address that problem.


The changes I'm going to make will only be visible in syntax errors.  R 
currently has the underlying support to allow it to report source file 
line numbers in execution time error messages, but it isn't taken 
advantage of in many places.  If that is expanded, my Sweave changes 
should take advantage of it automatically.


Duncan Murdoch

In a course on using R (for beginners),
I would really like to show warnings that code chunks produce.
Currently, the warnings are printed to the console when I run
 'R CMD Sweave ..' and do not appear in the resulting *.tex file.

Of course   ---   fortune(Yoda)   ---
I can always fudge what I want,
but it would be quite desirable to have simple Sweave option
which would deal with warnings()  
{ and maybe message(), stop(), and general exception handling; 
  but for all practical purposes, it's the warnings that I'd

  like to be handled automatically.}

Martin Maechler, ETH Zurich



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

Re: [Rd] Does anyone use Sweave (RweaveLatex) option expand=FALSE?

[Duncan Murdoch]

On 19/08/2010 5:25 PM, Duncan Murdoch wrote:

On 19/08/2010 5:07 PM, Kevin Coombes wrote:
 I use it, frequently. The idea for it goes back to some of Knuth's 
 original literate programming ideas for developing weave and tangle when 
 he was writing TeX (the program).  I want to be able to document the 
 pieces of some complex algorithm without having to see all of the gory 
 details.  For instance, I have code that looks like the following.  
 (Note that this is typed on the fly rather than copied from actual 
 source, so there may be typos.)


Okay, thanks.  I'll keep it in.  So now I have a question:  suppose
you have an error (syntax error at this point, maybe some other kinds of 
error in the future) in the getInfoAboutThisSample chunk, but that 
chunk wasn't eval'd, mainloop was eval'd.  So the error is going to be 
reported as occurring in chunk mainloop, but with a line number from 
somewhere else in the file.  Is that a problem?
  


I was out of town for a week, but I'm back now, and have just committed 
these changes.  Hopefully the reports of syntax errors will be a little 
more helpful now.  I don't think I'll have time to make the reports of 
execution time errors better before the 2.12.0 release.


Duncan Murdoch


Duncan Murdoch


 
 mainloop,keep.source=TRUE,expand=FALSE=

 for (i in 1:nSamples) {
 getInfoAboutThisSample
  for (j in 1:nChromosomes) {
 getChromosomeDataForCurrentSample
 normalizeChromosomeData
 findSegments
 computeSignificance
 writeResults
  }
 }
 @
 
 Each of the chunks is itself a fairly long piece of code defined and 
 documented somewhere else.  (Some of them may themselves be written in 
 the same form to reduce the final size of a chunk to something a human 
 has a chance of understanding. That's the difference between weave and 
 tangle in the original implementation.)   By blocking expansion, I can 
 focus on the main steps without having them lost in pages and pages of code.
 
 So I vote strongly for retaining expand=FALSE.
 
 Best,

 Kevin
 
 Duncan Murdoch wrote:

 On 19/08/2010 4:29 PM, Claudia Beleites wrote:
 I never used it.

 I got curious, though. What would be a situation that benefits of 
 this option?
   
 When I put it in, I thought it would be for people who were writing 
 about Sweave.


 Duncan Murdoch

 Maybe a use case could be found by brute force (grep all .Rnw files 
 on CRAN for the option?


 Claudia


 __
 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] introspective capabilities

[Duncan Murdoch]

On 27/08/2010 7:52 AM, Christophe Rhodes wrote:

Hi,

Is there any way, from R code, to perform introspection as to where
certain names acquired their values?  The specific functionality I'm
looking for in this case is to be able to request my editor to view the
definition corresponding to a name in its original source location
(presuming for the moment that that location exists).  Other
functionality that I'm looking for is to identify where in the current
image a particular name is used -- what functions use the value bound
to a particular name?

The context for these questions, in case anyone is interested, is that I
am usually a Common Lisp programmer, and my programming environment for
that (SLIME) is what I'm used to.  R is sufficiently close to CL (the
discovery of withCallingHandlers/withRestarts was a pleasant surprise)
that I decided to experiment with implementing a SLIME backend for R --
and enough of it seems to work that I'm motivated to make it more
complete.  (The current state of the project is summarised at
http://common-lisp.net/~crhodes/swankr/).

  
There's the keep.source option to source() and the optional srcfile 
argument to parse() that tell R to keep this information.  If you 
haven't changed the default
getOption(keep.source) from TRUE, then source will default to keeping 
it, and you can find the original location of a function definition for 
function f by looking in attr(body(f), srcref).  See ?srcref for the 
format; there aren't a lot of user-level utility functions for working 
with this.


For packages, the relevant option is keep.source.pkgs at the time the 
package is installed.


Duncan Murdoch

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

Re: [Rd] introspective capabilities

[Duncan Murdoch]

On 01/09/2010 9:27 AM, Christophe Rhodes wrote:

Duncan Murdoch murdoch.dun...@gmail.com writes:

 On 27/08/2010 7:52 AM, Christophe Rhodes wrote:
 Hi,

 Is there any way, from R code, to perform introspection as to where
 certain names acquired their values?

 There's the keep.source option to source() and the optional
 srcfile argument to parse() that tell R to keep this information.
 If you haven't changed the default
 getOption(keep.source) from TRUE, then source will default to
 keeping it, and you can find the original location of a function
 definition for function f by looking in attr(body(f), srcref).  See
 ?srcref for the format; there aren't a lot of user-level utility
 functions for working with this.

Thanks.  This is enough for my immediate purposes: supporting
single-keystroke (M-.) jumping to source locations of functions.

 For packages, the relevant option is keep.source.pkgs at the time
 the package is installed.

Thank you.

Is there anything like a cross-referencing database within R?  The
functionality I'm looking for here is to be able to name a function, and
come back with a list of functions (or srcrefs) where that name is
used.  (I realise that this is not in general possible; just the
lexically-apparent cases would be enough).



There is no such database already built, but I imagine the functions in 
the codetools package could construct one. 


Duncan Murdoch

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

Re: [Rd] Weird erratic error and illogical error message, could someone explain this?

[Duncan Murdoch]

Philippe Grosjean wrote:

Hello,

It's several days I try to track this bug, and even cannot cook a 
reproducible example. Yet, it occurs consistently in a long-running task 
after a variable period of time. Here is an example:
  


I would look closely at the other software that is running in your long 
example.  Does it include C (or other external) code?  Look closely at 
that, it might be writing outside it's own allocated memory.  Also check 
for correct protection of intermediate results, if you're producing 
SEXPs in the external code.  (Running under gctorture might flush out 
the bug more quickly if the latter is the problem.)


If you're only running R code, then this looks like a bug in R, but it 
might still be worth trying gctorture to make it reproducible.  We won't 
be able to fix it if we can't reproduce it.


Duncan Murdoch

... my long-running code [as I said, cannot give something simple
that produces this bug in a reproducible manner]

Error in match(x, table, nomatch = 0L) :
 formal argument nomatch matched by multiple actual arguments
  traceback()
6: match(x, table, nomatch = 0L)
5: factor %in% attrib[[class, exact = TRUE]]
4: structure(.Internal(Sys.time()), class = c(POSIXt, POSIXct))
3: Sys.time()
2: chemTrigger() at chemostat_1.0-1.R#1132
1: chemRun()

So, the culprid is a call inside `%in%` (from within structure() in 
Sys.time()). But I can run millions times `%in%`, or structure(), or 
Sys.time() on my machine without producing this bug. Arguments at 5: are 
simple character strings. They don't hurt!


Also, I am lost because the message is totally illogical in the context 
where it appears: I can understand this message here:


  match(1, 2, nomatch = 0L, nomatch = NA)
Error in match(1, 2, nomatch = 0L, nomatch = NA) :
   formal argument nomatch matched by multiple actual arguments

or here:

  test - function (...) match(1, ..., nomatch = 0L)
  test(2, nomatch = NA)
Error in match(1, ..., nomatch = 0L) :
   formal argument nomatch matched by multiple actual arguments

but in the call match(x, table, nomatch = 0L) where x is the character 
string factor and table is another character string (numeric) 
extracted from a list, I don't understand why it produces this error 
message. '.Internal(Sys.time())' uses do_systime c code that returns a 
one-element double... not something that can hurt here?!


Can someone explain me, or give me an example where an argument is NOT 
duplicated in the call (well, as I understand it here) and where one 
gets such an error message? And why?


Many thanks, I am desperate :-(

I got this error on R 2.11.1 on Mac OS X 10.6.4, and on R 2.10.1 on 
Windows XP SP3 (but it does not matter, since I cannot cook a 
reproducible example).


Philippe

P.S.: seems related to this: 
http://finzi.psych.upenn.edu/Rhelp10/2008-June/165101.html




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

Re: [Rd] Stats not loaded? Method for as.ts() results in error

[Duncan Murdoch]

Janko Thyson wrote:

Dear list,

 


I've got the following problem:

 


In a package I'm trying to build, there exists a method for the function
as.ts(). When checking the package, R always throws the error that it
cannot find a function called as.ts. To me it seems that the package
stats (home of as.ts()) is not loaded during the checking process even
though it's a base package. For testing, I've written a method for plot()
to see if it's a general problem with base-functions, but this one passes
just fine.
  


Are you using a NAMESPACE, and declaring your method as a method?  If 
you don't, R will have to guess what the methods are, and it might be 
getting mixed up because of the unusual name of the generic.


Duncan Murdoch


 


Did anyone of encounter a similar problem or could help me out with a hint?

 


Thank you very much,

Janko

 

  



__
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] Development environment for R extentions on Windows

[Duncan Murdoch]

 On 08/09/2010 1:21 PM, Jeffrey Horner wrote:

Hi all,

I'm setting up a development environment on Windows as the subject
implies. I've downloaded and installed Rtools211.exe (will upgrade
later when necessary) and I've also downloaded and installed mingw
with the help of mingw-get.exe.

I come from a UNIX development background, so I'm at the bash shell
prompt for just about every step in R extenstion development. Question
is what is an appropriate environment for Windows development. What
shell do you use? Do you use cmd.exe with the PATH variable set up by
Rtools? Do you use the sh.exe that comes with Rtools? I've found the
bash shell from MinGW to be a pretty close equivalent to bash on UNIX.
Do you use something else?



I've used the bash shell in Cygwin for quite a few years, but I've been 
planning a switch to MSYS sometime.  Cygwin seems to have made some bad 
decisions lately that make it harder and harder to work with.


Duncan Murdoch

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

Re: [Rd] CMD check: checking data for non-ASCII characters is very time consuming

[Duncan Murdoch]

 On 02/09/2010 6:27 AM, Vincent Carey wrote:

Checking data for non-ASCII characters takes a very long time for
packages with substantial data components.
Could the check be done manually by the developer, and a switch
introduced to optionally skip this during check?



I'll add an environment variable to skip this check.  For the full list 
of check configuration variables, see the Tools section of the R 
Internals manual.


Duncan Murdoch

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

Re: [Rd] Development environment for R extentions on Windows

[Duncan Murdoch]

On 08/09/2010 5:37 PM, Jeffrey Horner wrote:

On Wed, Sep 8, 2010 at 1:01 PM, Jeffrey Horner jeffrey.hor...@gmail.com wrote:

On Wed, Sep 8, 2010 at 12:37 PM, Duncan Murdoch
murdoch.dun...@gmail.com wrote:

 On 08/09/2010 1:21 PM, Jeffrey Horner wrote:

Hi all,

I'm setting up a development environment on Windows as the subject
implies. I've downloaded and installed Rtools211.exe (will upgrade
later when necessary) and I've also downloaded and installed mingw
with the help of mingw-get.exe.

I come from a UNIX development background, so I'm at the bash shell
prompt for just about every step in R extenstion development. Question
is what is an appropriate environment for Windows development. What
shell do you use? Do you use cmd.exe with the PATH variable set up by
Rtools? Do you use the sh.exe that comes with Rtools? I've found the
bash shell from MinGW to be a pretty close equivalent to bash on UNIX.
Do you use something else?


I've used the bash shell in Cygwin for quite a few years, but I've been
planning a switch to MSYS sometime.  Cygwin seems to have made some bad
decisions lately that make it harder and harder to work with.

This is great news! I don't know how I could survive without bash's vi
style editing and command completion...

Here's my PATH variable which sets the Rtools paths first, then MinGW:

horn...@hornerj-win ~
$ echo $PATH
/c/Rtools/bin:/c/Rtools/perl/bin:/c/Rtools/MinGW/bin:/c/localbin:/mingw/bin:/bin:/usr/bin:/usr/lo
cal/bin:/c/Program Files (x86)/R/R-2.11.1/bin:/c/Program Files
(x86)/CollabNet/Subversion Client:
/c/Windows/system32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.
0/:/c/Program Files (x86)/MiKTeX 2.8/miktex/bin

I'm going to follow the R Installation ... manual to compile R on
Windows and learn a bit about the build process. From there, I intend
to port some open source libraries that have support for being
compiled with MS VC++ over to MinGW.


From the MinGW bash shell, the R build went quite smoothly. However, I
did run into trouble with temporary files. I got around it by
specifying TMPDIR like so:

$ cd R_HOME/src/gnuwin32
$ TMPDIR=. /c/Rtools/bin/make all


I don't know if anything would go wrong, but I'd avoid putting your temp 
dir into the source tree.  On my home machine I normally set R_USER to a 
Windows-style path (with backslashes), and that seems to work.  On my 
work machine I think I set TMPDIR explicitly, but I forget what value I 
used.




If I didn't set TMPDIR, it would default to /tmp and the failure would
occur within the mkR target of R_HOME/share/make/basepkg.mk. For
reasons beyond me, the shell environment that's entered within the mkR
target has no notion of a root directory. Anyone else seen this?


I'm not sure you're using the write make procedure.  Are you running 
make from within src/gnuwin32, so you get the Makefile there?  It 
shouldn't try to use /tmp (but things might have changed recently).


Duncan Murdoch



Jeff


Aside from my PATH variable, are there other things about my
development environment I should be aware of?

Jeff







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

Re: [Rd] An ls error which is not an error...

[Duncan Murdoch]

On 09/09/2010 5:57 AM, Barry Rowlingson wrote:

If I try ls with an unquoted version of something in my search list, I
get an error message but the ls completes successfully. For example:

  attach(x.RData)
  ls(file:x.RData)
 Error in try(name) : object 'x.RData' not found
 [1] x

which seems to be because ls first does: nameValue - try(name) which
raises the error, and then goes on to do some
substitute(deparse(magic)) to get the name and carries on as if I'd
done ls(file:x.RData)

Documentation says (with my enumeration):

The ‘name’ argument can specify the environment from which object
 names are taken in one of several forms:

1. as an integer (the position in the ‘search’ list);
2. as the character string name of an element in the search list;
3.  or as an explicit ‘environment’

Either ls(file:x.RData) is none of these in which case there should be
an error and exit, or it's (2), in which case the error is misleading.
I think try(name,silent=TRUE) might be a better option?


This is old code, so I don't think converting it to an error is a good 
idea.  I don't like the idea of silently eating the error:  it might 
have been a typo, that just coincidentally looks like the name of 
something on the search list.  So I will try to change the error to an 
informative warning.


Duncan Murdoch

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

Re: [Rd] Windows build

[Duncan Murdoch]

On 10/09/2010 5:05 PM, pooja varshneya wrote:

Hi Folks,

I am trying to build R-2.11.1 from source code on Windows 2003. I am
able to build it, but when i run 'make check', it fails as follows:
Does the tests produce a log somewhere that i can use for
troubleshooting the problem ?

-
C:\R\R-2.11.1\src\gnuwin32make check

Collecting examples for package 'base'
  Extracting from parsed Rd's 
Running examples in package 'base'

Collecting examples for package 'tools'
  Extracting from parsed Rd's 
Running examples in package 'tools'

Collecting examples for package 'utils'
  Extracting from parsed Rd's .
Running examples in package 'utils'
Error: testing 'utils' failed
Execution halted
make[3]: *** [test-Examples-Base] Error 1
make[2]: *** [test-Examples] Error 2
make[1]: *** [test-all-basics] Error 1
make: *** [check] Error 2


Yes, if you look in the R_HOME/tests directory, you'll see a 
subdirectory named Examples; that's where the logs of all the tests of 
examples are saved.  But I can guess at the problem:  you don't have the 
recommended packages installed.  They're needed to run the tests.  In 
Windows you get them by


make rsync-recommended
make recommended

Getting them in other OS's is slightly different, but I forget the 
details.  See the R Installation and Administration manual.


Duncan Murdoch

__
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 Murdoch]

On 11/09/2010 12:52 AM, Hervé Pagès wrote:

Hi,

I found the following problem with recent R-devel
(2010-08-26 r52817) on Windows (32-bit and 64-bit):
'R CMD build pkg' gets stalled during vignette
creation for packages that have a Makefile in pkg/inst/doc.

It seems that the problem is that the commands used in the
Makefile for converting .tex to .pdf are not able to locate
the Sweave.sty file anymore (if I drop this file to
pkg/inst/doc, then the problem goes away).


This sounds like a problem that only the package maintainer could 
address.  Presumably it will be temporary:  once they adjust to the new 
organization of the share/texmf directory, things will be fine again.


The reorg is described in this NEWS item:

* Directory R_HOME/share/texmf now follows the TDS conventions, so
  can be set as a texmf tree ('root directory' in MiKTeX parlance).

Duncan Murdoch



I noticed that the location of Sweave.sty shipped with
R has changed recently (moved from ${R_HOME}/share/texmf
to ${R_HOME}/share/texmf/tex/latex/). Could that be related
to the problem?

I don't see that problem on platforms other than Windows or
with R  2.12

Thanks,
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

[Duncan Murdoch]

On 12/09/2010 12:49 AM, Hervé Pagès wrote:

Hi Duncan,

On 09/11/2010 03:56 AM, Duncan Murdoch wrote:

On 11/09/2010 12:52 AM, Hervé Pagès wrote:

Hi,

I found the following problem with recent R-devel
(2010-08-26 r52817) on Windows (32-bit and 64-bit):
'R CMD build pkg' gets stalled during vignett
creation for packages that have a Makefile in pkg/inst/doc.

It seems that the problem is that the commands used in the
Makefile for converting .tex to .pdf are not able to locate
the Sweave.sty file anymore (if I drop this file to
pkg/inst/doc, then the problem goes away).

This sounds like a problem that only the package maintainer could
address. Presumably it will be temporary: once they adjust to the new
organization of the share/texmf directory, things will be fine again.

The reorg is described in this NEWS item:

* Directory R_HOME/share/texmf now follows the TDS conventions, so
can be set as a texmf tree ('root directory' in MiKTeX parlance).


Before this reorg, the package maintainer didn't have to care about
where to find things in R_HOME/share/texmf. 'R CMD build' would just
find them by setting the TEXINPUTS envir variable appropriately (and
then commands in the inst/doc/Makefile file would find them too).

This reorg was checked in svn as rev 52256. I see the following
adjustments to TEXINPUTS:

   ** On Unix (src/scripts/Rcmd.in file):

-## Append 'share/texmf' to TeX's input search path.
-if test -z $TEXINPUTS}; then
-  TEXINPUTS=.:${R_SHARE_DIR}/texmf:
+## Append 'share/texmf/...' to TeX's input search path.
+if test -z ${TEXINPUTS}; then
+  TEXINPUTS=.:${R_SHARE_DIR}/texmf/tex/latex:
  else
-  TEXINPUTS=.:${TEXINPUTS}:${R_SHARE_DIR}/texmf:
+  TEXINPUTS=.:${TEXINPUTS}:${R_SHARE_DIR}/texmf/tex/latex:
  fi
  export TEXINPUTS

   ** On Windows (src/gnuwin32/fixed/etc/Rcmd_environ file):

-TEXINPUTS=.;${TEXINPUTS};${R_SHARE_DIR}/texmf;
+TEXINPUTS=.;${TEXINPUTS};${R_SHARE_DIR}/texmf/tex/latex;

The path seems to have been adjusted correctly. So my question is:
why isn't this working on Windows for packages that use a Makefile?


I don't know.  My first assumption would that something in the Makefile 
is wrong, but since you don't give any examples, I can't check.


Duncan Murdoch

__
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 Murdoch]

On 12/09/2010 12:04 PM, Wolfgang Huber wrote:

Hi Duncan

wouldn't it be possible that by default the Sweave.sty in share/texmf is 
found by 'R CMD build' for use by package vignettes without manual 
intervention?


Yes, it does work that way.  What Hervé is talking about are cases where 
people use Makefiles to bypass the normal process.


Duncan Murdoch



AfaIcs this is also how it worked in the past.

Best wishes
  Wolfgang

On Sep/11/10 12:56 PM, Duncan Murdoch wrote:

On 11/09/2010 12:52 AM, Hervé Pagès wrote:

Hi,

I found the following problem with recent R-devel
(2010-08-26 r52817) on Windows (32-bit and 64-bit):
'R CMD build pkg' gets stalled during vignette
creation for packages that have a Makefile in pkg/inst/doc.

It seems that the problem is that the commands used in the
Makefile for converting .tex to .pdf are not able to locate
the Sweave.sty file anymore (if I drop this file to
pkg/inst/doc, then the problem goes away).

This sounds like a problem that only the package maintainer could
address. Presumably it will be temporary: once they adjust to the new
organization of the share/texmf directory, things will be fine again.

The reorg is described in this NEWS item:

* Directory R_HOME/share/texmf now follows the TDS conventions, so
can be set as a texmf tree ('root directory' in MiKTeX parlance).

Duncan Murdoch


I noticed that the location of Sweave.sty shipped with
R has changed recently (moved from ${R_HOME}/share/texmf
to ${R_HOME}/share/texmf/tex/latex/). Could that be related
to the problem?

I don't see that problem on platforms other than Windows or
with R  2.12

Thanks,
H.


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




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

Re: [Rd] R CMD build cannot create vignettes on Windows if Makefile is used

[Duncan Murdoch]

Hervé Pagès wrote:

Hi Duncan,

On 09/12/2010 05:07 AM, Duncan Murdoch wrote:
  

On 12/09/2010 12:49 AM, Hervé Pagès wrote:


Hi Duncan,

On 09/11/2010 03:56 AM, Duncan Murdoch wrote:
  

On 11/09/2010 12:52 AM, Hervé Pagès wrote:


Hi,

I found the following problem with recent R-devel
(2010-08-26 r52817) on Windows (32-bit and 64-bit):
'R CMD build pkg' gets stalled during vignett
creation for packages that have a Makefile in pkg/inst/doc.

It seems that the problem is that the commands used in the
Makefile for converting .tex to .pdf are not able to locate
the Sweave.sty file anymore (if I drop this file to
pkg/inst/doc, then the problem goes away).
  

This sounds like a problem that only the package maintainer could
address. Presumably it will be temporary: once they adjust to the new
organization of the share/texmf directory, things will be fine again.

The reorg is described in this NEWS item:

* Directory R_HOME/share/texmf now follows the TDS conventions, so
can be set as a texmf tree ('root directory' in MiKTeX parlance).


Before this reorg, the package maintainer didn't have to care about
where to find things in R_HOME/share/texmf. 'R CMD build' would just
find them by setting the TEXINPUTS envir variable appropriately (and
then commands in the inst/doc/Makefile file would find them too).

This reorg was checked in svn as rev 52256. I see the following
adjustments to TEXINPUTS:

** On Unix (src/scripts/Rcmd.in file):

-## Append 'share/texmf' to TeX's input search path.
-if test -z $TEXINPUTS}; then
- TEXINPUTS=.:${R_SHARE_DIR}/texmf:
+## Append 'share/texmf/...' to TeX's input search path.
+if test -z ${TEXINPUTS}; then
+ TEXINPUTS=.:${R_SHARE_DIR}/texmf/tex/latex:
else
- TEXINPUTS=.:${TEXINPUTS}:${R_SHARE_DIR}/texmf:
+ TEXINPUTS=.:${TEXINPUTS}:${R_SHARE_DIR}/texmf/tex/latex:
fi
export TEXINPUTS

** On Windows (src/gnuwin32/fixed/etc/Rcmd_environ file):

-TEXINPUTS=.;${TEXINPUTS};${R_SHARE_DIR}/texmf;
+TEXINPUTS=.;${TEXINPUTS};${R_SHARE_DIR}/texmf/tex/latex;

The path seems to have been adjusted correctly. So my question is:
why isn't this working on Windows for packages that use a Makefile?
  

I don't know. My first assumption would that something in the Makefile
is wrong, but since you don't give any examples, I can't check.



There are 8 Bioconductor packages failing to build on Windows
because of this problem. They have a Makefile in inst/doc/ that
calls 'pdflatex' or 'texi2dvi --pdf' on some_vignette to convert
some_vignette.tex into some_vignette.pdf. They don't
have Sweave.sty in inst/doc/ (other packages use the same kind of
Makefile and are building ok because they have a copy of Sweave.sty
in inst/doc/).

For example, here is the content of adSplit/inst/doc/Makefile:

all:pdf clean

pdf:tr_2005_02.tex
epstopdf splitSet.eps
pdflatex tr_2005_02
pdflatex tr_2005_02
pdflatex tr_2005_02

clean:
rm -f *.aux *.eps *.log *.out *.tex *.toc
rm -f Rplots.ps splitSet.pdf tr_2005_02-*

The 7 other packages use similar Makefile. As I said before, they
all used to build ok before the R_HOME/share/texmf reorg. They still
build ok on non-Windows machines. Thanks!

H.
  


On Windows using MikTeX, we put a -I option on the command line to point 
to the input directory.  If you don't want to do that, you can use R 
CMD texify --pdf instead of pdflatex; it will try to determine the 
appropriate command line based on the platform.


Duncan Murdoch

__
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 Murdoch]

 On 13/09/2010 2:38 PM, Hervé Pagès wrote:

On 09/13/2010 03:34 AM, Duncan Murdoch wrote:
  Hervé Pagès wrote:
  Hi Duncan,

  On 09/12/2010 05:07 AM, Duncan Murdoch wrote:
  On 12/09/2010 12:49 AM, Hervé Pagès wrote:
  Hi Duncan,

  On 09/11/2010 03:56 AM, Duncan Murdoch wrote:
  On 11/09/2010 12:52 AM, Hervé Pagès wrote:
  Hi,

  I found the following problem with recent R-devel
  (2010-08-26 r52817) on Windows (32-bit and 64-bit):
  'R CMD buildpkg' gets stalled during vignett
  creation for packages that have a Makefile inpkg/inst/doc.

  It seems that the problem is that the commands used in the
  Makefile for converting .tex to .pdf are not able to locate
  the Sweave.sty file anymore (if I drop this file to
  pkg/inst/doc, then the problem goes away).
  This sounds like a problem that only the package maintainer could
  address. Presumably it will be temporary: once they adjust to the new
  organization of the share/texmf directory, things will be fine again.

  The reorg is described in this NEWS item:

  * Directory R_HOME/share/texmf now follows the TDS conventions, so
  can be set as a texmf tree ('root directory' in MiKTeX parlance).
  Before this reorg, the package maintainer didn't have to care about
  where to find things in R_HOME/share/texmf. 'R CMD build' would just
  find them by setting the TEXINPUTS envir variable appropriately (and
  then commands in the inst/doc/Makefile file would find them too).

  This reorg was checked in svn as rev 52256. I see the following
  adjustments to TEXINPUTS:

  ** On Unix (src/scripts/Rcmd.in file):

  -## Append 'share/texmf' to TeX's input search path.
  -if test -z $TEXINPUTS}; then
  - TEXINPUTS=.:${R_SHARE_DIR}/texmf:
  +## Append 'share/texmf/...' to TeX's input search path.
  +if test -z ${TEXINPUTS}; then
  + TEXINPUTS=.:${R_SHARE_DIR}/texmf/tex/latex:
  else
  - TEXINPUTS=.:${TEXINPUTS}:${R_SHARE_DIR}/texmf:
  + TEXINPUTS=.:${TEXINPUTS}:${R_SHARE_DIR}/texmf/tex/latex:
  fi
  export TEXINPUTS

  ** On Windows (src/gnuwin32/fixed/etc/Rcmd_environ file):

  -TEXINPUTS=.;${TEXINPUTS};${R_SHARE_DIR}/texmf;
  +TEXINPUTS=.;${TEXINPUTS};${R_SHARE_DIR}/texmf/tex/latex;

  The path seems to have been adjusted correctly. So my question is:
  why isn't this working on Windows for packages that use a Makefile?
  I don't know. My first assumption would that something in the Makefile
  is wrong, but since you don't give any examples, I can't check.

  There are 8 Bioconductor packages failing to build on Windows
  because of this problem. They have a Makefile in inst/doc/ that
  calls 'pdflatex' or 'texi2dvi --pdf' onsome_vignette  to convert
  some_vignette.tex intosome_vignette.pdf. They don't
  have Sweave.sty in inst/doc/ (other packages use the same kind of
  Makefile and are building ok because they have a copy of Sweave.sty
  in inst/doc/).

  For example, here is the content of adSplit/inst/doc/Makefile:

  all: pdf clean

  pdf: tr_2005_02.tex
  epstopdf splitSet.eps
  pdflatex tr_2005_02
  pdflatex tr_2005_02
  pdflatex tr_2005_02

  clean:
  rm -f *.aux *.eps *.log *.out *.tex *.toc
  rm -f Rplots.ps splitSet.pdf tr_2005_02-*

  The 7 other packages use similar Makefile. As I said before, they
  all used to build ok before the R_HOME/share/texmf reorg. They still
  build ok on non-Windows machines. Thanks!

  H.

  On Windows using MikTeX, we put a -I option on the command line to point
  to the input directory. If you don't want to do that, you can use R CMD
  texify --pdf instead of pdflatex; it will try to determine the
  appropriate command line based on the platform.

Yes I can use 'R CMD some_command' instead of just 'some_command' in the
Makefile so 'some_command' sees the TEXINPUTS variable and that solves
the problem. But when I call 'R CMD build', shouldn't 'make' and its
child processes ('pdflatex', 'texify', etc...) already see TEXINPUTS?
Why do I need to call the commands in the Makefile thru R CMD again
in order to see TEXINPUTS?

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.


Duncan Murdoch

__
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 Murdoch]

 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] Problem with WARNING...headers with CRLF line endings

[Duncan Murdoch]

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] a small suggestion for improving the building of packages

[Duncan Murdoch]

 On 16/09/2010 2:43 PM, Uwe Ligges wrote:


On 16.09.2010 20:18, Janko Thyson wrote:
  From: Uwe Liggesligges_at_statistik.tu-dortmund.de
  Date: Wed, 15 Sep 2010 15:23:01 +0200
  On 29.08.2010 22:34, Kyle Matoba wrote:
  All,

  I just finished the process of build a package for the first time and
  found
  it characteristically (for R) very straightforward and well
  documented.

  Whenever I deal with open source software I always endeavor to finish
  the
  task I have in mind, and upon completing this, I then revisit all of
  the
  configurations, customizing as necessary to achieve my goals more
  fully.
  The ability to achieve some minimal level of functionality without
  the
  need
  for much filling in of configuration files, etc., is, I feel,
  important to

  not scaring off the less technically inclined such as myself.

  Based on this heuristic, it is my understanding that a few small
  suggestions
  could make building a warning-free package as easy as running
  package.skeleton(), then R CMD check, R CMD build:

  - Fill in default titles for each of the '*.Rd' files in /man
  - Take out the tildes in the 'examples' section of the '*-package.Rd'
  main

  documentation file for the package (it seems to confuse the latex
  compiler)
  - Put the lines '~~ Optionally other standard keywords, one per line,
  from

  file KEYWORDS in ~~
  ~~ the R documentation directory ~~' into the \references{} section,
  there

  is presently a warning about all text needing to be in a section.
  Dear Kyle,
  thanks for the suggestions. Actually, it is intended to generate
  warnings /
  Errors in R CMD check: We want to force package developers to document
  their
  packages probably. This way, package maintainers / developers have to
  touch
  each Rd file and cannot use them as is in order to pass the checks.
  Best wishes,
  uwe

  Dear Uwe,
  in principle, I totally agree with your point of politely forcing developers
  to write well documented packages. However, when you're trying to put
  together a package, you (or at least I) never get it completely right on the
  first, say, 20 tries ;-) Yet, by running package.skelleton() over and over
  to keep track of changes you made during the process, you overwrite all Rd
  files each time - including the ones that you might already have put a lot
  of effort into. And delaying documentation to the very end of the process is
  probably not the best idea either ;-) IMHO the community should favor the
  approaches taken by packages such as roxygen or inlinedocs as at least it
  provides some sort of direct synchronization between code and documentation.
  Maybe one could agree on rejecting code that is missing roxygen or inlinedoc
  code, which would ensure that code is documented properly. In fact, isn't
  programming all about automating unnecessary manual procedures? I would
  count starting from scratch with all help files time and time again to be
  one of those unnecessary procedures. This time could better be invested in
  increasing the package's functionality.

- I don't think package.skeleton overwrites files unless you ask for it.

- I think once you got started with your package, it is not required to
call package skeleton again. I tend to add files manually since I am
working on the package hierarchy itself using some editor...


Hi Uwe.  This message is mostly for Janko and others.

You can add them manually, but I would usually use prompt(), a generic 
function that produces just one .Rd file.


It's really one of the prompt methods that package.skeleton is calling 
to produce the bad man pages.  My own feeling is that package.skeleton 
should produce a package that is installable, but it shouldn't pass R 
CMD check unless there's some manual intervention to fill in the details.
I think that is the current state of affairs, but if we're producing 
something that causes R CMD build or R CMD INSTALL to fail, please 
let us know.


By the way, I don't think the title can be filled in automatically 
unless a user has roxygen style documentation, so we don't.  But doesn't 
the roxygen package do that?


Duncan Murdoch


- Last time I used package.skeleton is probably more than 2 years ago
(except for presentations in courses about package creation).

Best,
Uwe





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

Re: [Rd] a small suggestion for improving the building of packages

[Duncan Murdoch]

 On 16/09/2010 2:45 PM, William Dunlap wrote:

  From: r-devel-boun...@r-project.org
  [mailto:r-devel-boun...@r-project.org] On Behalf Of Janko Thyson
  Sent: Thursday, September 16, 2010 11:19 AM
  To: r-de...@r-project. org
  Subject: Re: [Rd] a small suggestion for improving the
  building of packages
...
  Dear Uwe,
  in principle, I totally agree with your point of politely
  forcing developers
  to write well documented packages. However, when you're trying to put
  together a package, you (or at least I) never get it
  completely right on the
  first, say, 20 tries ;-) Yet, by running package.skelleton()
  over and over
  to keep track of changes you made during the process, you
  overwrite all Rd
  files each time - including the ones that you might already
  have put a lot
  of effort into.

Running package.skeleton more than once is destructive.
Perhaps it needs an update=TRUE/FALSE sort of option
to let you add functions and Rd templates.


Yes, that would be a nice addition.  I think good default behaviour 
would be to only create new files if none of the same name already exist 
(and warn that's what you did), but with an option to completely 
overwrite what was there.



When I start a package I don't use package.skeleton,
mainly because it won't make all the usual directories
that I expect to eventually use: src, data, inst, test
(or it is tests?), etc.  I'd rather that it made all
the usual directories (with the proper spelling) so
I could delete them if they ended up being empty.
Do other package writers use package.skeleton routinely?


I don't make a lot of new packages, but I do use it for quick little 
ones.  I'm not so sure we should create all the directories:  it's 
mainly aimed at beginners, who might find that intimidating.  Advanced 
users can do what you do.  Perhaps an option (default off) to create 
everything

would be a good compromise.

Duncan Murdoch


I copy a template package directory, edit the template
DESCRIPTION file, copy my code into the appropriate
subdirectories, and run prompt(func, filename=pkg/man/func.Rd)
on each function or dataset.   The last step is a pain:
it would be nice if prompt had a dir= or destdir= argument
so that
prompt(func, destdir=pkg/man)
would make the file pkg/man/func.Rd.

Bill Dunlap
Spotfire, TIBCO Software
wdunlap tibco.com

  And delaying documentation to the very end of
  the process is
  probably not the best idea either ;-) IMHO the community
  should favor the
  approaches taken by packages such as roxygen or inlinedocs as
  at least it
  provides some sort of direct synchronization between code and
  documentation.
  Maybe one could agree on rejecting code that is missing
  roxygen or inlinedoc
  code, which would ensure that code is documented properly. In
  fact, isn't
  programming all about automating unnecessary manual
  procedures? I would
  count starting from scratch with all help files time and time
  again to be
  one of those unnecessary procedures. This time could better
  be invested in
  increasing the package's functionality.

  Best regards, my thanks go out to everyone as well,
  Janko

  Thanks, as always, to everyone for their hard work to keep my
statistical
  computing free and easy.

  Best,

  Kyle

  [[alternative HTML version deleted]]

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

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


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


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

Re: [Rd] Possible bug or annoyance with library.dynam.unload()

[Duncan Murdoch]

 On 21/09/2010 10:38 AM, Karl Forner wrote:

Hello,

I got no reply on this issue.
It is not critical and I could think of work-around, but it really looks
like a bug to me.
Should I file a bug-report instead of posting in this list ?


I'd probably post instructions for a reproducible example first.  Pick 
some CRAN package, tell us what to do with it to trigger the error, and 
then we can see if it's something special about your package or Roxygen 
or a general problem.


Duncan Murdoch


Thanks,

Karl

On Thu, Sep 16, 2010 at 6:11 PM, Karl Fornerkarl.for...@gmail.com  wrote:

  Hello,

  I have a package with a namespace. Because I use Roxygen that overwrites
  the NAMESPACE file each time it is run, I use a R/zzz.R file with
  an .onLoad() and .onUnload() functions to take care of loading and
  unloading my shared library.

  The problem: if I load my library from a local directory, then the
  unloading of the package fails, e.g:

  # loads fine
  library(Foo, lib.loc=.Rcheck)

  unloadNamespace(Foo)
  Warning message:
  .onUnload failed in unloadNamespace() for 'Foo', details:
call: library.dynam.unload(Foo, libpath)
error: shared library 'Foo' was not loaded

  # I traced it a little:
  library.dynam.unload(Foo, .Rcheck/Foo)
  Error in library.dynam.unload(Foo, .Rcheck/Foo) :
shared library 'Foo' was not loaded

  # using an absolute path works
  library.dynam.unload(Foo, /home/toto/.Rcheck/Foo)


  So from what I understand, the problem is either that the relative libpath
  is sent to the .onUnload() function instead of the absolute one,
  or that library.dynam.unload() should be modified to handle the relative
  paths.

  Am I missing something ? What should I do ?

  Thanks,


  Karl


[[alternative HTML version deleted]]

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


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

Re: [Rd] Possible bug or annoyance with library.dynam.unload()

[Duncan Murdoch]

 On 22/09/2010 11:22 AM, Karl Forner wrote:

Thanks Duncan for your suggestion.

I could not find any package using dynamic library, namespaces and not the
useDynLib pragma so
I created a minimalistic package to demonstrate the problem.
Please find attached a very small package foo (8.8k)


Your package depends on Rcpp, so I didn't try it in the alpha version of 
2.12.0 (Rcpp isn't available there in a Windows binary at the moment), 
but I did try it in R-patched.  With one minor change to your script 
(the lib.loc needs to be local, not local/ on Windows), I can 
reproduce the problem, and it looks like a bug to me.  Thanks for the 
report, I'll put it on the bugs page, and hopefully it will be fixed 
before the 2.12.0 release.


Duncan Murdoch


Steps to reproduce the problem:

* unarchive it ( tar zxvf foo_0.1.tar.gz )
* cd foo
* install it locally ( mkdir local; R CMD INSTALL -l local . )
* R
  library(foo, lib.loc=local/)
.dynLibs()
# there you should be able to see the foo.so lib, in my case
/x05/people/m160508/workspace/foo/local/foo/libs/foo.so

  unloadNamespace(foo)
.onUnload, libpath= local/fooWarning message:
.onUnload failed in unloadNamespace() for 'foo', details:
   call: library.dynam.unload(foo, libpath)
   error: shared library 'foo' was not loaded

#The libpath that the .onUnload() gets is local/foo.

#This fails:
library.dynam.unload(foo, local/foo)
Error in library.dynam.unload(foo, local/foo) :
   shared library 'foo' was not loaded

# but if you use the absolute path it works:
library.dynam.unload(foo, /x05/people/m160508/workspace/foo/local/foo)

Karl

On Tue, Sep 21, 2010 at 5:33 PM, Duncan Murdochmurdoch.dun...@gmail.comwrote:

   On 21/09/2010 10:38 AM, Karl Forner wrote:

  Hello,

  I got no reply on this issue.
  It is not critical and I could think of work-around, but it really looks
  like a bug to me.
  Should I file a bug-report instead of posting in this list ?


  I'd probably post instructions for a reproducible example first.  Pick some
  CRAN package, tell us what to do with it to trigger the error, and then we
  can see if it's something special about your package or Roxygen or a general
  problem.

  Duncan Murdoch

   Thanks,

  Karl

  On Thu, Sep 16, 2010 at 6:11 PM, Karl Fornerkarl.for...@gmail.com
   wrote:

 Hello,
  
 I have a package with a namespace. Because I use Roxygen that
  overwrites
 the NAMESPACE file each time it is run, I use a R/zzz.R file with
 an .onLoad() and .onUnload() functions to take care of loading and
 unloading my shared library.
  
 The problem: if I load my library from a local directory, then the
 unloading of the package fails, e.g:
  
 # loads fine
 library(Foo, lib.loc=.Rcheck)
  
 unloadNamespace(Foo)
 Warning message:
 .onUnload failed in unloadNamespace() for 'Foo', details:
   call: library.dynam.unload(Foo, libpath)
   error: shared library 'Foo' was not loaded
  
 # I traced it a little:
 library.dynam.unload(Foo, .Rcheck/Foo)
 Error in library.dynam.unload(Foo, .Rcheck/Foo) :
   shared library 'Foo' was not loaded
  
 # using an absolute path works
 library.dynam.unload(Foo, /home/toto/.Rcheck/Foo)
  
  
 So from what I understand, the problem is either that the relative
  libpath
 is sent to the .onUnload() function instead of the absolute one,
 or that library.dynam.unload() should be modified to handle the
  relative
 paths.
  
 Am I missing something ? What should I do ?
  
 Thanks,
  
  
 Karl
  

 [[alternative HTML version deleted]]

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






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

Re: [Rd] Incorporate graphic files into R-package

[Duncan Murdoch]

 On 27/09/2010 10:44 AM, elgorgonzola wrote:

Hi,

I am working on a package which will be used to generate reports using
Sweave. The createReport() function should create a folder and Rnw/tex-files
automatically. The reports should, however, also feature the company logo. I
don't want to have to manually copy the image file into the folder each time
a report is created. I don't know if it is possible or not but I would like
to somehow store the graphic-file within the package and have the
createReport() automatically copy it to the appropriate folder. Does anyone
have an idea how this could be achieved?
I'm thinking of something similar to the way data is stored as a RData-file
in the data-path of a package and is accessed via load() once the package is
loaded.

Thanks in advance and hava a great day.


Read about the inst directory in Writing R Extensions.  You can put 
your logo there, it will be installed when your package is installed, 
and your Sweave document can find it using system.file(path within 
package, package=yourpackage) to copy to the output directory.


Duncan Murdoch

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

Re: [Rd] bulding a package for Windows (path problem?)

[Duncan Murdoch]

jgar...@ija.csic.es wrote:

Hi,

I am working on a package with several hydrological functions which
builds/checks/INSTALLs gracefully for a Linux box. However, for a
Microsoft Windows XP [Versión 5.1.2600] I have the error:

C:\Archivos de programa\R\R-2.9.2\binR CMD build
C:\home\javier\Documents\hydrology\development\hydrosim
  


Are you really using version 2.9.2?  If so, I think you're on your own.  
The current release is 2.11.1, and our efforts are concentrated on 
testing the alpha/beta of 2.12.0 now.


Duncan Murdoch


Can't locate R/Dcf.pm in @INC (@INC contains: C
/ARCHIV~1/R/R-29~1.2/share/perl; /usr/lib/perl5/5.10/i686-cygwin
/usr/lib/per
l5/5.10 /usr/lib/perl5/site_perl/5.10/i686-cygwin
/usr/lib/perl5/site_perl/5.10 /usr/lib/perl5/vendor_perl/5.10/i686-cygwin
/
usr/lib/perl5/vendor_perl/5.10 /usr/lib/perl5/vendor_perl/5.10
/usr/lib/perl5/site_perl/5.8 /usr/lib/perl5/vendor_perl/5.8 .)
 at C:\ARCHIV~1\R\R-29~1.2/bin/build line 28.
BEGIN failed--compilation aborted at C:\ARCHIV~1\R\R-29~1.2/bin/build line
28.

However, the content of the first mentioned folder is:

C:\ARCHIV~1\R\R-29~1.2\share\perl\Rls
Dcf.pm Logfile.pm Rd.pm Rdconv.pm Rdlist.pm Rdtools.pm Utils.pm Vars.pm

Is there a problem with the way windows abbreviates folder names for long
names of names withs spaces? Or the problem is elsewhere?

Please, could you help?

Thanks and best regards,
Javier
---

__
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] scoping goes wrong when some functions are used within others.

[Duncan Murdoch]

 On 01/10/2010 12:00 PM, Joris Meys wrote:

Dear,

I'm following the r tag on stackoverflow.com, and couldn't but notice
there are quite some questions popping up that deal with scoping in
relation to custom functions. I grinded my teeth on it already, and I
have absolutely no clue what goes wrong. The general pattern is as
follows :


I think each of the reports is really a separate bug, mostly in the 
implementation of some_function. As far as I could see, only the last one


|y- new.env()
with(y, x- 1)
f- function(env,z) {
with(env, x+z)
}
f(y,z=1)
|

involves base R functions, and there I think the problem is with your 
reading of the documentation, not with the function. The documentation 
may suggest that should work by saying The environment has the caller's 
environment as its parent, but there's no way it possibly could. 
Environments only have one parent. If you read carefully you'll see that 
this is documented correctly in (Note: if ‘data’ is already an 
environment then this is used with its existing parent.)


Duncan Murdoch


ff- function(x){
 y- some_value
 some_function(y)
}

  ff(x)
Error in eval(expr, envir, enclos) : object 'y' not found

I tried to report this as a bug earlier, but got the message I used
the wrong channel. I also don't know how to formalize it into a bug
report on the report site. That's why I bring it to your attention
this way, and want to ask you whether this is by design and we're all
doing something wrong, whether these are problems within certain
packages/situations, ...

I solve these problems now by adding an environment to my global
environment, and delete it after the function finished running. But
this can't be the correct way.

The problem is described here :
http://stackoverflow.com/questions/3840769/scoping-and-functions-in-r-2-11-1-whats-going-wrong

Links to different reports, all having that same pattern but with
different functions :

http://stackoverflow.com/questions/3742415/r-statistical-scoping-error-using-transformby-part-of-the-doby-package
http://stackoverflow.com/questions/3768417/how-to-use-acast-reshape2-within-a-function-in-r
http://stackoverflow.com/questions/3661500/why-cant-i-pass-a-dataset-to-a-function
http://stackoverflow.com/questions/3574858/values-not-being-copied-to-the-next-local-environment
http://stackoverflow.com/questions/2646402/using-functions-and-environments




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

Re: [Rd] Eval and the enclos argument

[Duncan Murdoch]

On 02/10/2010 7:57 AM, Hadley Wickham wrote:

Hi all,

I'm trying to understand the default value of the enclos argument of eval:

  enclos = if(is.list(envir) || is.pairlist(envir)) parent.frame()
else baseenv()

Why isn't it just

  enclos = parent.frame()

given that enclos is only meaningful (given my reading of the
documentation) when envir is not an environment already.

Hadley




I think that handles the case of envir=NULL.

Duncan Murdoch

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

Re: [Rd] Eval and the enclos argument

[Duncan Murdoch]

On 02/10/2010 10:40 AM, Hadley Wickham wrote:

On Sat, Oct 2, 2010 at 8:18 AM, Duncan Murdoch murdoch.dun...@gmail.com wrote:

On 02/10/2010 7:57 AM, Hadley Wickham wrote:

Hi all,

I'm trying to understand the default value of the enclos argument of eval:

 enclos = if(is.list(envir) || is.pairlist(envir)) parent.frame()
else baseenv()

Why isn't it just

 enclos = parent.frame()

given that enclos is only meaningful (given my reading of the
documentation) when envir is not an environment already.

Hadley



I think that handles the case of envir=NULL.


So that makes eval(expr, NULL) equivalent to eval(expr, baseenv()), right?


I think so.

Duncan

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

Re: [Rd] Encoding problem in Rd file

[Duncan Murdoch]

On 03/10/2010 12:23 PM, Renaud Lancelot wrote:

Dear all,

I have a problem with an Rd file containing French accentuated
characters. I have uploaded the file at
http://filex.cirad.fr/get?k=cjW7lImMaNC6Ci2vX0H

I have declared
Encoding: latin1
in the package DESCRIPTION file

and I have added
\encoding{latin1}
in the header of the Rd file.

When I compile the package manual, I have LaTeX errors:

! Package inputenc Error: Unicode char \u8:ÃF not set up for use with LaTeX.

See the inputenc package documentation for explanation.
Type  H return  for immediate help.
 ...

l.579 ...ain. Aspects méthodologiques.} Rev. à F
  augère, O., Dockès, A.-C...


R converts everything to UTF-8 and declares it that way for LaTeX. It 
looks as though your LaTeX installation isn't prepared to handle that, 
or something has gone wrong in the conversion on your system.  The 
letter following Rev.  above is a capital E with an acute accent, 
which is encoded as C3 89 in UTF-8.  Interpreted as Latin1, that looks 
like Ã, because the 89 is unprintable, but it shouldn't come out as ÃF.


I'd suggest updating your LaTeX inputenc package.  If that doesn't work, 
you can see if the problem is in the conversion, by running


R CMD Rd2dvi --no-clean dja.Rd

and look in the Rd2.tex file that was produced.

Duncan Murdoch



Your command was ignored.
Type  I command return  to replace it with another command,
or  return  to continue without it.


! Package inputenc Error: Unicode char \u8:ÃF not set up for use with LaTeX.

See the inputenc package documentation for explanation.
Type  H return  for immediate help.
 ...

l.581 Ã  F
  augère, O., Tillard, E., Faugère, B., 1992. \emph{Prophylaxie ch...

Your command was ignored.
Type  I command return  to replace it with another command,
or  return  to continue without it.


! Package inputenc Error: Unicode char \u8:Ã\end not set up for use with LaTeX.


See the inputenc package documentation for explanation.
Type  H return  for immediate help.
 ...

l.587 \end
  {References}
Your command was ignored.
Type  I command return  to replace it with another command,
or  return  to continue without it.

***
I can easily find the offending lines using
showNonASCII(readLines(file)). However, I don't know what to do to
solve the problem. The strange thing (to me!) is that the pdf is
actually built with appropriate accentuated characters, at least when
I look at it with my pdf viewer (Acrobat reader).

My config is:


sessionInfo()

R version 2.11.1 Patched (2010-09-30 r53117)
Platform: i386-pc-mingw32 (32-bit)

locale:
[1] LC_COLLATE=French_France.1252  LC_CTYPE=French_France.1252
[3] LC_MONETARY=French_France.1252 LC_NUMERIC=C
[5] LC_TIME=French_France.1252

attached base packages:
[1] tools stats graphics  grDevices utils datasets  methods
[8] base

other attached packages:
[1] fortunes_1.4-0






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

Re: [Rd] Encoding problem in Rd file

[Duncan Murdoch]

On 03/10/2010 1:14 PM, Renaud Lancelot wrote:

Thank you very much. My LaTeX installation is up to date (very
recently updated with MIKTeK update facility).
I have run R CMD Rd2dvi --no-clean dja.Rd and the result looks OK. I
have put the resulting TeX file at
http://filex.cirad.fr/get?k=K1cBpKr3UBUmdOJFMlx

Do you have another suggestion?


Not really, other than trying a LaTeX expert.  When I run your file 
through latex using


R CMD latex Rd2.tex

it compiles fine with no errors (only an underfull hbox warning).

One thought:  some people install copies of Rd.sty into their local tex 
installation.  If that version isn't compatible with the current macros 
generated by R, you could have problems.  You should see something like


(F:/R/svn/r-devel/R/share/texmf/tex/latex\Rd.sty
Package: Rd

in the Rd2.log file.  If you see that it finds Rd.sty outside of the 
current R version, delete the old file.


Duncan Murdoch




Renaud

2010/10/3 Duncan Murdoch murdoch.dun...@gmail.com:

On 03/10/2010 12:23 PM, Renaud Lancelot wrote:

Dear all,

I have a problem with an Rd file containing French accentuated
characters. I have uploaded the file at
http://filex.cirad.fr/get?k=cjW7lImMaNC6Ci2vX0H

I have declared
Encoding: latin1
in the package DESCRIPTION file

and I have added
\encoding{latin1}
in the header of the Rd file.

When I compile the package manual, I have LaTeX errors:

! Package inputenc Error: Unicode char \u8:ÃF not set up for use with
LaTeX.

See the inputenc package documentation for explanation.
Type  H return  for immediate help.
 ...

l.579 ...ain. Aspects méthodologiques.} Rev. à F
 augère, O., Dockès,
A.-C...

R converts everything to UTF-8 and declares it that way for LaTeX. It looks
as though your LaTeX installation isn't prepared to handle that, or
something has gone wrong in the conversion on your system.  The letter
following Rev.  above is a capital E with an acute accent, which is
encoded as C3 89 in UTF-8.  Interpreted as Latin1, that looks like Ã,
because the 89 is unprintable, but it shouldn't come out as ÃF.

I'd suggest updating your LaTeX inputenc package.  If that doesn't work, you
can see if the problem is in the conversion, by running

R CMD Rd2dvi --no-clean dja.Rd

and look in the Rd2.tex file that was produced.

Duncan Murdoch


Your command was ignored.
Type  I command return  to replace it with another command,
or  return  to continue without it.


! Package inputenc Error: Unicode char \u8:ÃF not set up for use with
LaTeX.

See the inputenc package documentation for explanation.
Type  H return  for immediate help.
 ...

l.581 Ã  F
 augère, O., Tillard, E., Faugère, B., 1992. \emph{Prophylaxie
ch...

Your command was ignored.
Type  I command return  to replace it with another command,
or  return  to continue without it.


! Package inputenc Error: Unicode char \u8:Ã\end not set up for use with
LaTeX.


See the inputenc package documentation for explanation.
Type  H return  for immediate help.
 ...

l.587 \end
 {References}
Your command was ignored.
Type  I command return  to replace it with another command,
or  return  to continue without it.

***
I can easily find the offending lines using
showNonASCII(readLines(file)). However, I don't know what to do to
solve the problem. The strange thing (to me!) is that the pdf is
actually built with appropriate accentuated characters, at least when
I look at it with my pdf viewer (Acrobat reader).

My config is:


sessionInfo()

R version 2.11.1 Patched (2010-09-30 r53117)
Platform: i386-pc-mingw32 (32-bit)

locale:
[1] LC_COLLATE=French_France.1252  LC_CTYPE=French_France.1252
[3] LC_MONETARY=French_France.1252 LC_NUMERIC=C
[5] LC_TIME=French_France.1252

attached base packages:
[1] tools stats graphics  grDevices utils datasets  methods
[8] base

other attached packages:
[1] fortunes_1.4-0












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

Re: [Rd] S4 class help pages [Sec=Unclassified]

[Duncan Murdoch]

 On 04/10/2010 12:14 AM, Troy Robertson wrote:

Hi,

I am working on producing an R package containing mostly S4 classes and methods.
I have generated and filled out all the necessary .Rd files but find that once installed 
I am unable to access help pages for the classes using the ?package::classname-class 
syntax that is suggested when using the ?? apropos search.  This lists my package classes 
and the class help pages.  Instead, the Arithmetic Operators help page is 
always loaded.  I can load the pages I want via links like \linkS4class{classname} in my 
package help page.

I have played with a couple of other packages and see the same problem.  Is 
there a different syntax to access these S4 class help pages rather than 
?package::classname-class?


The problem is the parsing:  that is parsed as `?`(stats4::mle - class), 
i.e. there's a subtraction there, not a name with a hyphen in it.  So 
you're seeing help on subtraction.


You can get what you want with class?stats4::mle.

I'll see if I can fix the advice from ??.

Duncan Murdoch


Thanks

Troy


___

 Australian Antarctic Division - Commonwealth of Australia
IMPORTANT: This transmission is intended for the addressee only. If you are not 
the
intended recipient, you are notified that use or dissemination of this 
communication is
strictly prohibited by Commonwealth law. If you have received this transmission 
in error,
please notify the sender immediately by e-mail or by telephoning +61 3 6232 
3209 and
DELETE the message.
 Visit our web site at http://www.antarctica.gov.au/
___

[[alternative HTML version deleted]]

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


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

Re: [Rd] SweaveInput + keep.source = TRUE trouble

[Duncan Murdoch]

On 05/10/2010 5:38 AM, Claudia Beleites wrote:

Dear all,

I have trouble with R-beta sweaving files that include definitions with
\SweaveInput in combination with keep.source = TRUE


Thanks for the report.  I'll take a look.

Duncan Murdoch



Symptom:
SInput is taken from too far down the input file (the shift is the number of
lines of the included file). Is that known? Searching didn't turn up anything, 
yet I think there are more people than just me using keep.source.


Example:
$ ~/tmp/R-beta/bin/R CMD Sweave baseline.Rnw 
mv baseline.tex baseline.devel.tex 
R CMD Sweave baseline.Rnw 
mv baseline.tex baseline.2.11.tex 
diff -u baseline.2.11.tex baseline.devel.tex

gives:
--- baseline.2.11.tex   2010-10-05 11:33:49.0 +0200
+++ baseline.devel.tex  2010-10-05 11:33:49.0 +0200
@@ -83,7 +83,7 @@
  \verb+\SweaveOpts{keep.source = TRUE}+
  \begin{Schunk}
  \begin{Sinput}
- 12
+ line 54
  \end{Sinput}
  \begin{Soutput}
  [1] 12
@@ -106,7 +106,7 @@
  line 63 chunk option keep.source = TRUE
  \begin{Schunk}
  \begin{Sinput}
- 14
+ line 67
  \end{Sinput}
  \begin{Soutput}
  [1] 14

I used yesterday's R-beta, and my system is Ubuntu 9.10 64 bit (though that 
probably doesn't matter).


Building the example file I also found that \SweaveInput{} cannot be followed by 
anything else on the line(not even a LaTeX comment).


\SweaveInput{x}y
complains that file xy is not found.

Best regards,

Claudia Beleites





__
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] SweaveInput + keep.source = TRUE trouble

[Duncan Murdoch]

 This is fixed now in R-devel and the beta version.  The fix isn't 
perfect:  if you use \SweaveInput, you lose the error reporting that 
gives line numbers from the original file.  It should be possible to 
have both, but I think the changes to implement that are too large to 
consider in a beta.


Duncan Murdoch

On 05/10/2010 5:38 AM, Claudia Beleites wrote:

Dear all,

I have trouble with R-beta sweaving files that include definitions with
\SweaveInput in combination with keep.source = TRUE

Symptom:
SInput is taken from too far down the input file (the shift is the number of
lines of the included file). Is that known? Searching didn't turn up anything,
yet I think there are more people than just me using keep.source.

Example:
$ ~/tmp/R-beta/bin/R CMD Sweave baseline.Rnw
mv baseline.tex baseline.devel.tex
R CMD Sweave baseline.Rnw
mv baseline.tex baseline.2.11.tex
diff -u baseline.2.11.tex baseline.devel.tex

gives:
--- baseline.2.11.tex   2010-10-05 11:33:49.0 +0200
+++ baseline.devel.tex  2010-10-05 11:33:49.0 +0200
@@ -83,7 +83,7 @@
   \verb+\SweaveOpts{keep.source = TRUE}+
   \begin{Schunk}
   \begin{Sinput}
-  12
+  line 54
   \end{Sinput}
   \begin{Soutput}
   [1] 12
@@ -106,7 +106,7 @@
   line 63 chunk option keep.source = TRUE
   \begin{Schunk}
   \begin{Sinput}
-  14
+  line 67
   \end{Sinput}
   \begin{Soutput}
   [1] 14

I used yesterday's R-beta, and my system is Ubuntu 9.10 64 bit (though that
probably doesn't matter).

Building the example file I also found that \SweaveInput{} cannot be followed by
anything else on the line(not even a LaTeX comment).

\SweaveInput{x}y
complains that file xy is not found.

Best regards,

Claudia Beleites



__
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] NULL assignment will change the expression's class into list

[Duncan Murdoch]

Vitalie Spinu wrote:

Hello Everyone!

NULL replacement will change expression object into list:

  

te - expression(a=23*4, b=33-2)
te


expression(a = 23 * 4, b = 33 - 2)

  

te[[a]] - quote(blabla) #ok
te


expression(a = blabla, b = 33 - 2)

  

te[[a]] - NULL #change to list
te


$b
33 - 2

I am on w32, version 2.11.1 (2010-05-31)
  


That's certainly an inconsistency, still present in a recent R-devel 
(but I haven't checked the latest beta).  I don't know if it's a bug:  
NULL assignments are handled specially in other situations (e.g. if te 
was a list to start, the NULL assignment would remove the a entry).


A simple workaround is to use

te[a] - expression(NULL)

or te - te[-1]

instead, depending on what you expected to happen.

Duncan Murdoch


Regards,
Vitally.

[[alternative HTML version deleted]]

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



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

Re: [Rd] NULL assignment will change the expression's class into list

[Duncan Murdoch]

 On 08/10/2010 12:24 PM, Vitalie Spinu wrote:

On Fri, Oct 8, 2010 at 12:14 PM, Duncan Murdochmurdoch.dun...@gmail.comwrote:

  Vitalie Spinu wrote:

  Hello Everyone!

  NULL replacement will change expression object into list:



  te- expression(a=23*4, b=33-2)
  te


  expression(a = 23 * 4, b = 33 - 2)



  te[[a]]- quote(blabla) #ok
  te


  expression(a = blabla, b = 33 - 2)



  te[[a]]- NULL #change to list
  te


  $b
  33 - 2

  I am on w32, version 2.11.1 (2010-05-31)



  That's certainly an inconsistency, still present in a recent R-devel (but I
  haven't checked the latest beta).  I don't know if it's a bug:  NULL
  assignments are handled specially in other situations (e.g. if te was a list
  to start, the NULL assignment would remove the a entry).

  A simple workaround is to use

  te[a]- expression(NULL)

  or te- te[-1]

  instead, depending on what you expected to happen.


As ussual with NULL assignment in recursive structures, I would expect to
remove the elements altogether. And this is exactly what I need.

I would say it's a bug, because NULL assignment in data.frames would not
convert them to lists, for example.


I think you're probably right.

Thanks for looking into it. It's quite inconvenient when you have to
manipulate named expression. Have to use constructs like
et-et[!names(et)%in%a].


Or simply follow te[a] - NULL

with

te - as.expression(te)

This is a pretty fast operation if te is an expression or a list formed 
by mistaken conversion from one.


Duncan Murdoch


Vitally.


  Duncan Murdoch

   Regards,
  Vitally.

 [[alternative HTML version deleted]]

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







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

Re: [Rd] NULL assignment will change the expression's class into list

[Duncan Murdoch]

Vitalie Spinu wrote:

On Fri, Oct 8, 2010 at 7:49 PM, Duncan Murdoch murdoch.dun...@gmail.comwrote:

  

 On 08/10/2010 12:24 PM, Vitalie Spinu wrote:



On Fri, Oct 8, 2010 at 12:14 PM, Duncan Murdochmurdoch.dun...@gmail.com
  

wrote:

 Vitalie Spinu wrote:




 Hello Everyone!

 NULL replacement will change expression object into list:



  

 te- expression(a=23*4, b=33-2)
 te




 expression(a = 23 * 4, b = 33 - 2)



  

 te[[a]]- quote(blabla) #ok
 te




 expression(a = blabla, b = 33 - 2)



  

 te[[a]]- NULL #change to list
 te




 $b
 33 - 2

 I am on w32, version 2.11.1 (2010-05-31)


  

 That's certainly an inconsistency, still present in a recent R-devel


(but I
  

 haven't checked the latest beta).  I don't know if it's a bug:  NULL
 assignments are handled specially in other situations (e.g. if te was a


list
  

 to start, the NULL assignment would remove the a entry).

 A simple workaround is to use

 te[a]- expression(NULL)

 or te- te[-1]

 instead, depending on what you expected to happen.



As ussual with NULL assignment in recursive structures, I would expect to
remove the elements altogether. And this is exactly what I need.

I would say it's a bug, because NULL assignment in data.frames would not
convert them to lists, for example.

  

I think you're probably right.

 Thanks for looking into it. It's quite inconvenient when you have to


manipulate named expression. Have to use constructs like
et-et[!names(et)%in%a].

  

Or simply follow te[a] - NULL

with

te - as.expression(te)

This is a pretty fast operation if te is an expression or a list formed by
mistaken conversion from one.

D



But is this a reliable way to do it? I have been struggling some time ago
with this type of conversion.
Can not thing of an example now. But as far as I could remember, the
conversion to list of an expression is not always reversible with
as.expression. Am I wrong?
  


I don't know of any examples, but this is your construction.  I think 
it's very unlikely this will be fixed for 2.12.0, but it will probably 
be fixed for 2.12.1, if


1.  There is a 2.12.1

and

2.  It really isn't intentional behaviour.


Duncan Murdoch


  

uncan Murdoch


 Vitally.


 Duncan Murdoch

  Regards,


 Vitally.

[[alternative HTML version deleted]]

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


  

  





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

Re: [Rd] Missing libpthread in RTools

[Duncan Murdoch]

On 15/10/2010 4:53 PM, Davor Cubranic wrote:

It appears that Mingw gcc included in RTools is missing a dependent
library. If I compile a program with '-lgomp' switch (for OpenMP
support), I get a errors about undefined references to functions like
'_imp__pthread_mutex_destroy'. Adding the '-static' switch, I get the
following error:

 
c:/rtools/mingw/bin/../lib/gcc/mingw32/4.5.0/../../../../mingw32/bin/ld.exe:
cannot find -lpthread

Sure enough, there is neither libpthread.a nor libpthread.dll under
RTools' installation directory. I think these library are standard in
Cygwin. Is there any chance to include them in RTools, too?


Rtools is for building R, and that library isn't needed in R.  If you 
want it for some particular purpose, can't you just install a copy on 
your machine?


Duncan Murdoch



Davor

__
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