Re: [Rd] Suggestion: help()
Kurt Hornik wrote: >>>>>>Duncan Murdoch writes: > > >>>>>On Tue, 7 Jun 2005, Duncan Murdoch wrote: >>>>> >>>>>[...] >>>>> >>>>> >>>>> >>>>>>My proposal (modified following the suggestions I've heard so far) is as >>>>>>follows: >>>>>> >>>>>> - to check that a couple of help topic aliases exist (.package >>>>>>and ) >>>>>> - to recommend that .package contain general information about >>>>>>the package, and that be an alias for it, if it isn't used for >>>>>>some other purpose. >>>>>> - to write promptPackage() to help create an initial version of >>>>>>.package.Rd. It can get some information from the DESCRIPTION >>>>>>file; perhaps it could go looking for a vignette, or the INDEX, or >>>>>> - to modify the other help system tools to make use of this (e.g. the >>>>>>package: heading on a page would become a link to the .package >>>>>>alias, etc.) > > >>I've now committed some of this to R-devel, and I invite comments. I've >>abandoned the idea of the check, which seems too controversial. I've >>done the second and third items, but not the 4th. > > >>I wrote about a dozen of these files this afternoon as I was refining >>promptPackage. It is very quick to generate a basic man page using >>promptPackage with an option saying you want a final version. Manually >>editing this file, running it through checks, etc. took me around 10-20 >>minutes per package. > > >>I only did the base packages, and they probably have less in their >>overview than most contributors would want, so someone starting from >>nothing would probably take longer --- but many packages already have >>the text written somewhere, and they just need to add an alias to an Rd >>file, or perhaps reformat an INDEX file. > > > Duncan, > > I am not sure why you went ahead on this. It seemed to me that most of the discussion focussed on one point (forcing extra work on people); this seems to be the only way to get discussion on any other aspect of the proposal. > My understanding was that > there was considerable opposition to introducing a convention for > package documentation intermediate between providing package meta data > in the DESCRIPTION file and providing vignettes, given in particular > that we already have such an additional mechanism (INDEX files) for > historic reasons. The reason I went ahead was that I think this implementation is an improvement on INDEX files, though it is backwards compatible. In several of the overviews I wrote I refer to the automatically generated INDEX file. In cases where the INDEX was manually edited I recommend putting the content into the overview topic instead (but do not force this). I did it for the boot package (and I'll send the work to Brian if he's interested in incorporating it, since boot isn't a base package, and he's the maintainer); it wasn't that hard, but I think it was an improvement, in that the function names can be links to the function man pages, not just names to be copied and pasted. In at least one case (the stats4 package) I think the INDEX file is almost completely useless, so I wrote the overview completely from scratch. I'm not sure I got it right, comments or corrections to the content would of course be welcome too. However, I'd really like to hear a clear explanation of why you think the current system is superior. So far all that I've heard are messages like "this forces too much work on package writers", "we did this three years ago, why do it again?" I've explained why I think this solution is better, and I've modified it to allow it to be anywhere from "zero cost" (ignore it) to "very low cost" (use the automatically generated overview), on up as far as a package writer wants to take it. > I also object particularly to the naming convention. Rd documentation > objects are identified by their NAME (as indicated in their \name meta > data), not the name of the file used for their serialization into Rd > format. IF we want to have such a mechanism, then at least let it work > on a topic-style alias of the form PACKAGE-package, which would be > consistent with what we do for S4 classes and methods. The problem with that style is that it doesn't parse to a name, so it needs quotes to work with the help system. For example, ?boot-PACKAGE doesn't do what you'd guess at all. (It g
Re: [Rd] Suggestion: help()
On 6/10/2005 8:00 AM, Gabor Grothendieck wrote: > On 6/10/05, Duncan Murdoch <[EMAIL PROTECTED]> wrote: >> Kurt Hornik wrote: >> >>>>>>Duncan Murdoch writes: >> > >> > >> >>>>>On Tue, 7 Jun 2005, Duncan Murdoch wrote: >> >>>>> >> >>>>>[...] >> >>>>> >> >>>>> >> >>>>> >> >>>>>>My proposal (modified following the suggestions I've heard so far) is >> >>>>>>as >> >>>>>>follows: >> >>>>>> >> >>>>>> - to check that a couple of help topic aliases exist (.package >> >>>>>>and ) >> >>>>>> - to recommend that .package contain general information about >> >>>>>>the package, and that be an alias for it, if it isn't used for >> >>>>>>some other purpose. >> >>>>>> - to write promptPackage() to help create an initial version of >> >>>>>>.package.Rd. It can get some information from the DESCRIPTION >> >>>>>>file; perhaps it could go looking for a vignette, or the INDEX, or >> >>>>>> - to modify the other help system tools to make use of this (e.g. the >> >>>>>>package: heading on a page would become a link to the >> >>>>>>.package >> >>>>>>alias, etc.) >> > >> > >> >>I've now committed some of this to R-devel, and I invite comments. I've >> >>abandoned the idea of the check, which seems too controversial. I've >> >>done the second and third items, but not the 4th. >> > >> > >> >>I wrote about a dozen of these files this afternoon as I was refining >> >>promptPackage. It is very quick to generate a basic man page using >> >>promptPackage with an option saying you want a final version. Manually >> >>editing this file, running it through checks, etc. took me around 10-20 >> >>minutes per package. >> > >> > >> >>I only did the base packages, and they probably have less in their >> >>overview than most contributors would want, so someone starting from >> >>nothing would probably take longer --- but many packages already have >> >>the text written somewhere, and they just need to add an alias to an Rd >> >>file, or perhaps reformat an INDEX file. >> > >> > >> > Duncan, >> > >> > I am not sure why you went ahead on this. >> >> It seemed to me that most of the discussion focussed on one point >> (forcing extra work on people); this seems to be the only way to get >> discussion on any other aspect of the proposal. >> >> > My understanding was that >> > there was considerable opposition to introducing a convention for >> > package documentation intermediate between providing package meta data >> > in the DESCRIPTION file and providing vignettes, given in particular >> > that we already have such an additional mechanism (INDEX files) for >> > historic reasons. >> >> The reason I went ahead was that I think this implementation is an >> improvement on INDEX files, though it is backwards compatible. In >> several of the overviews I wrote I refer to the automatically generated >> INDEX file. In cases where the INDEX was manually edited I recommend >> putting the content into the overview topic instead (but do not force >> this). I did it for the boot package (and I'll send the work to Brian if >> he's interested in incorporating it, since boot isn't a base package, >> and he's the maintainer); it wasn't that hard, but I think it was an >> improvement, in that the function names can be links to the function man >> pages, not just names to be copied and pasted. >> >> In at least one case (the stats4 package) I think the INDEX file is >> almost completely useless, so I wrote the overview completely from >> scratch. I'm not sure I got it right, comments or corrections to the >> content would of course be welcome too. >> >> However, I'd really like to hear a clear explanation of why you think >> the current system is superior. So far all that I've heard are messages >> like "this forces too much work on package writers", "we did this three >> years ago, why do it again?" I've explained why I think this solution >> i
Re: [Rd] Suggestion: help()
On 6/10/2005 8:17 AM, Duncan Murdoch wrote: > On 6/10/2005 8:00 AM, Gabor Grothendieck wrote: >> It would be invoked like this: >> >>package?boot >> >> with the effect of giving help on boot-package. > > Okay, I get it. That's a good change. I'll put it in unless I hear > objections very soon. (I'm going to be away from tomorrow through > Thursday, so I might appear to be ignoring objections if I don't see > them in time.) I've committed this change now. Package overviews are in -package now (in R-devel). As Gabor said, this is already supported by the help system, so there's nothing to stop someone from creating such an alias in their package before that version is released in the fall. Duncan __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] typo in ?lowess
Tobias Verbeke wrote: > In the `See Also' section of ?lowess, I read > > 'loess'), a newer formula based version [...] Fixed, thanks. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] hist.default documentation
On 6/17/2005 8:58 AM, Deepayan Sarkar wrote:
> I think there are a couple of things in ?hist that are not quite as
> clear as they could be.
>
> (1)
>
> freq: logical; if 'TRUE', the histogram graphic is a representation
> of frequencies, the 'counts' component of the result; if
> 'FALSE', _relative_ frequencies ("probabilities"), component
> 'density', are plotted. Defaults to 'TRUE' _iff_ 'breaks'
> are equidistant (and 'probability' is not specified).
>
> Unless I'm missing something, the 'density' component is NOT relative
> frequency or 'probability' in any reasonable sense, country-specific
> biases notwithstanding, except in the very special case where
> all(diff(breaks) == 1). Thus, the above description is confusing and
> probably even wrong.
I agree.
> Also, it seems to me that hist cannot draw a relative frequency
> histogram at all (which is not a bad thing, but it's of course very
> important to the undergrads we're teaching intro stats and R to). This
> should be explicitly mentioned.
I'm not sure about this. Is it really worth mentioning something if you
can't do it? Are you thinking of just giving a reference to barplot?
> (2)
>
> breaks: one of:
>
> ...
> * a single number giving the number of cells for the
> histogram,
> ...
>
> This is not quite true. 'breaks' is used in 'pretty', so it's more a
> suggestion than an exact specification. I'm not sure whether or not
> the behaviour should be changed (what's the point of having ``pretty''
> breakpoints anyway?), but if not, the documentation should be
> clarified.
I like the pretty breakpoints. It is good to label the breakpoints, and
ugly to have labels at other than pretty points. I'd clarify by
changing "giving" to "suggesting".
> I'll be happy to provide a patch if these changes are considered reasonable.
Please do.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] hist.default documentation
Thanks, I've committed the change.
Duncan Murdoch
On 6/17/2005 10:30 AM, Deepayan Sarkar wrote:
> On 6/17/05, Duncan Murdoch <[EMAIL PROTECTED]> wrote:
>> On 6/17/2005 8:58 AM, Deepayan Sarkar wrote:
>> > I think there are a couple of things in ?hist that are not quite as
>> > clear as they could be.
>> >
>> > (1)
>> >
>> > freq: logical; if 'TRUE', the histogram graphic is a representation
>> > of frequencies, the 'counts' component of the result; if
>> > 'FALSE', _relative_ frequencies ("probabilities"), component
>> > 'density', are plotted. Defaults to 'TRUE' _iff_ 'breaks'
>> > are equidistant (and 'probability' is not specified).
>> >
>> > Unless I'm missing something, the 'density' component is NOT relative
>> > frequency or 'probability' in any reasonable sense, country-specific
>> > biases notwithstanding, except in the very special case where
>> > all(diff(breaks) == 1). Thus, the above description is confusing and
>> > probably even wrong.
>>
>> I agree.
>>
>> > Also, it seems to me that hist cannot draw a relative frequency
>> > histogram at all (which is not a bad thing, but it's of course very
>> > important to the undergrads we're teaching intro stats and R to). This
>> > should be explicitly mentioned.
>>
>> I'm not sure about this. Is it really worth mentioning something if you
>> can't do it? Are you thinking of just giving a reference to barplot?
>
> Not mentioning it is fine.
>
>> > (2)
>> >
>> > breaks: one of:
>> >
>> > ...
>> > * a single number giving the number of cells for the
>> > histogram,
>> > ...
>> >
>> > This is not quite true. 'breaks' is used in 'pretty', so it's more a
>> > suggestion than an exact specification. I'm not sure whether or not
>> > the behaviour should be changed (what's the point of having ``pretty''
>> > breakpoints anyway?), but if not, the documentation should be
>> > clarified.
>>
>> I like the pretty breakpoints. It is good to label the breakpoints, and
>> ugly to have labels at other than pretty points. I'd clarify by
>> changing "giving" to "suggesting".
>
> Actually, I missed the remark just below this:
>
> In the last three cases the number is a suggestion only.
>
> so this is fine as it is.
>
>> > I'll be happy to provide a patch if these changes are considered
>> > reasonable.
>>
>> Please do.
>
> Here's the output of svn diff. Is this a reasonable way of providing a patch?
>
> Index: hist.Rd
> ===
> --- hist.Rd (revision 34748)
> +++ hist.Rd (working copy)
> @@ -28,9 +28,9 @@
>}
>\item{freq}{logical; if \code{TRUE}, the histogram graphic is a
> representation of frequencies, the \code{counts} component of
> -the result; if \code{FALSE}, \emph{relative} frequencies
> -(\dQuote{probabilities}), component \code{density},
> -are plotted. Defaults to \code{TRUE} \emph{iff} \code{breaks} are
> +the result; if \code{FALSE}, probability densities, component
> +\code{density}, are plotted (so that the histogram has a total area
> +of one). Defaults to \code{TRUE} \emph{iff} \code{breaks} are
> equidistant (and \code{probability} is not specified).}
>\item{probability}{an \emph{alias} for \code{!freq}, for S compatibility.}
>\item{include.lowest}{logical; if \code{TRUE}, an \code{x[i]} equal to
>
> Deepayan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Rgui bug in Windows: leftover download dialog (PR#7964)
On 6/23/2005 1:23 PM, Prof Brian Ripley wrote: > On Thu, 23 Jun 2005 [EMAIL PROTECTED] wrote: > >> On 6/22/2005 4:15 PM, [EMAIL PROTECTED] wrote: >>> In Windows, if a download is interrupted (by switching to the console >>> window and hitting ESC), the download status dialog can be left >>> onscreen, with no apparent way to get rid of it (other than stopping and >>> restarting R). >>> >>> To duplicate: >>> >>> Run this: >>> >>> a <- available.packages() >>> download.packages(a, 'c:/temp') >>> >>> Then, during a particularly long download, switch to the console window >>> and hit ESC. >>> >>> This affects R-devel, as well as 2.1.1. >> >> Now fixed in R-devel and R-patched. I also set it so the dialog retains >> its position if you move it out of the way; it was pretty irritating to >> have it pop up in the middle of the screen every time in a multiple file >> download. > > I don't think you can do simultaneous downloads, and is not the `it' > different progress bar windows? Right, simultaneous downloads are not possible. > Do you mean that the next instance of a progress bar will come up where > the last one was? Yes, but see below. > That seems not the standard ergonomics on GUI systems, > in which a new window is treated as a new window and not the same as an > old one. It would be good ergonomics if there was just one progress bar window when multiple files were selected for download, but I think that's too much trouble to do, since the C function called by download.file doesn't get told it's part of a multiple download sequence. The changes I made make just one progress bar window for the whole session, and make it visible when downloading and invisible otherwise. It's a change to the UI (one long-lived window instead of many short-lived ones). > I hate it when Windows puts Firefox up where I dragged the last > Firefox window (or even where another user dragged it). I think that's really Firefox moving itself to where it last was when you closed it; as far as I know Windows doesn't remember such things unless asked. There's probably some Mozilla option to control that behaviour. The retention I put in is entirely within an R session. Each download just makes the same progress window visible where you last left it, instead of creating a new one. This way if you're doing something like installing all of CRAN, you can push the progress bar out of the way while the downloads are going on, and it will stay out of the way. It does seem to have an annoying habit of grabbing the focus away from some programs, but not all; I'm not sure what's going on there or whether this can be fixed. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] list.files() reorders files in R CMD INSALL
On 6/23/2005 4:18 PM, Vadim Ogranovich wrote:
> Hi,
>
> The list.files() function seems to order its result vector differently
> when is run during R CMD INSTALL. Here is an example:
>
> ~% mkdir ~/FOO
> ~% cd ~/FOO/
> ~/FOO% touch a A b B
> ~/FOO% ls
> a A b B
>
>
> Put foo.R in the vor package. The foo.R just prints the files in ~/FOO:
> print(list.files("~/FOO"))
>
> Now install the package:
> ~/FOO% R CMD INSTALL -l ~/R/library/ ~/src/vor/
> * Installing *source* package 'vor' ...
> ** libs
> make: `vor.so' is up to date.
> ** R
> ** preparing package for lazy loading
> [1] "A" "B" "a" "b"
>
> ** help
> >>> Building/Updating help pages for package 'vor'
> Formats: text html latex example
> * DONE (vor)
>
>
> Note that the files are listed as: [1] "A" "B" "a" "b"
>
> Now start an R session
>> list.files("~/FOO")
> [1] "a" "A" "b" "B"
>
> which differs in order from that in R CMD INSTALL.
Looks like the sorting is being done in the C locale in the first case,
and in a different one in the second. See ?locales for how to set the
locale to what you want.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] list.files() reorders files in R CMD INSALL
On 6/23/2005 4:38 PM, Duncan Murdoch wrote:
> On 6/23/2005 4:18 PM, Vadim Ogranovich wrote:
>> Hi,
>>
>> The list.files() function seems to order its result vector differently
>> when is run during R CMD INSTALL. Here is an example:
>>
>> ~% mkdir ~/FOO
>> ~% cd ~/FOO/
>> ~/FOO% touch a A b B
>> ~/FOO% ls
>> a A b B
>>
>>
>> Put foo.R in the vor package. The foo.R just prints the files in ~/FOO:
>> print(list.files("~/FOO"))
>>
>> Now install the package:
>> ~/FOO% R CMD INSTALL -l ~/R/library/ ~/src/vor/
>> * Installing *source* package 'vor' ...
>> ** libs
>> make: `vor.so' is up to date.
>> ** R
>> ** preparing package for lazy loading
>> [1] "A" "B" "a" "b"
>>
>> ** help
>> >>> Building/Updating help pages for package 'vor'
>> Formats: text html latex example
>> * DONE (vor)
>>
>>
>> Note that the files are listed as: [1] "A" "B" "a" "b"
>>
>> Now start an R session
>>> list.files("~/FOO")
>> [1] "a" "A" "b" "B"
>>
>> which differs in order from that in R CMD INSTALL.
>
> Looks like the sorting is being done in the C locale in the first case,
> and in a different one in the second. See ?locales for how to set the
> locale to what you want.
... when in R, and see the R Extensions manual for setting it during the
INSTALL.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Embedding R in C application
On 6/24/2005 9:18 AM, [EMAIL PROTECTED] wrote: > To whom it may concern, > I am very interested in embedding the R functionality in our > application. This is a C application that currently runs on Win32, but > will also run on Linux in the future. From the material that I have > seen, I need R compiled as a shared library to evaluate R expressions > from C. Is this correct? If so, can I download this shared library from > somewhere? Is there any API document pertaining to this shared library? You want to look at the "Writing R Extensions" manual, in particular the chapters on the R API (for access to the underlying computational routines) and the one on linking GUIs or other front-ends (which sounds more like what you want to do). Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R v2.1.1 for Windows and "non-reproducible" crashes
On 6/27/2005 10:44 AM, Henrik Bengtsson wrote:
> Henrik Bengtsson wrote:
>> Hi,
>>
>> R v2.1.1 patched (2005-05-26) for Windows crashes. The sympotoms are
>> like "memory leakage". The patched version from two days ago crashes at
>> a different position in R CMD check compared to todays version.
>
> Sorry for being unclear; the "R CMD check" refers to R CMD check for my
> R.oo package and is just an example.
>
>> A "REPRODUCIBLE" EXAMPLE:
>> Unfortunately, I cannot create a minimal code example reproducing the
>> crash, but here is at least a simple way to reproduce it:
>>
>> 1. Make sure you run R v2.1.1 patched
>> 2. Start R
>> 3. install.packages("R.oo", contriburl="http://www.maths.lth.se/help/R";)
>> [This is a version built with R v2.1.0, because I cannot make the
>> package pass R CMD check on v2.1.1 because of the crashes]
>> 4. Cut'n'paste the following example from ?Rdoc to the R prompt:
>> library(R.oo)
>> author <- "Henrik Bengtsson, \url{http://www.braju.com/R/}";
>> rdocFile <- system.file("misc", "Exception.R", package="R.oo")
>> file.show(rdocFile)
>> destPath <- tempdir()
>> Rdoc$compile(rdocFile, destPath=destPath)
>> rdFiles <- list.files(destPath, full.names=TRUE)
>> print(rdFiles)
>> file.show(rdFiles[1])
>> file.remove(rdFiles)
>>
>> For me it crashes when it gets to the Rdoc$compile() line and Dr. Mingw
>> reports:
>>
>> Rterm.exe caused an Access Violation at location 7c911e58 in module
>> ntdll.dll Reading from location 52474f52.
I get a crash there too. I'll take a look.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Viewing R objects in gdb
I'm trying to track down a bug in some experimental code, where an object's attribute is getting messed up. This means I'd like to examine R objects while within gdb. One of the things I'd like to do is to examine the names of all the attributes. This is exactly what an example in the R Extensions manual section 4.11.2 "Inspecting R objects when debugging" does, but the code there doesn't work, presumably because the R internals have changed since it was written. Specifically, I get (gdb) p $a->u.listsxp.tagval->u.symsxp.pname->u.vecsxp.type.c Error: There is no member named vecsxp. where $a was set to be the attrib member of an SEXP. Could someone let me know what needs to be fixed for this to work? I imagine it's a typecast, but I haven't been able to put it together. (An example using R_PV to print the attributes of an SEXP would also be welcome, but I can probably figure that one out once I get this...) Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Viewing R objects in gdb
On 6/29/2005 2:06 PM, Luke Tierney wrote:
> On Wed, 29 Jun 2005, Duncan Murdoch wrote:
>
>> I'm trying to track down a bug in some experimental code, where an
>> object's attribute is getting messed up. This means I'd like to examine
>> R objects while within gdb.
>>
>> One of the things I'd like to do is to examine the names of all the
>> attributes. This is exactly what an example in the R Extensions manual
>> section 4.11.2 "Inspecting R objects when debugging" does, but the code
>> there doesn't work, presumably because the R internals have changed
>> since it was written.
>>
>> Specifically, I get
>>
>> (gdb) p $a->u.listsxp.tagval->u.symsxp.pname->u.vecsxp.type.c
>> Error: There is no member named vecsxp.
>>
>
> Something like this I think (untested):
>
> p ((VECSEXP)$a->u.listsxp.tagval->u.symsxp.pname)->vecsxp.type.c
That gets the typecast right, but now I have the problem that currently
vecsxp doesn't have a type member:
(gdb) p ((VECSEXP)$a->u.listsxp.tagval->u.symsxp.pname)->vecsxp.type.c
Error: There is no member named type.
(gdb) p ((VECSEXP)$a->u.listsxp.tagval->u.symsxp.pname)->vecsxp
$1 = {length = 5, truelength = 6957219}
I guess I need to write a function that uses the macros to extract the
data (since gdb doesn't see the macros). Or do we already have one?
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] upgrading an R installation to next versoin
On 6/30/2005 8:10 AM, Gabor Grothendieck wrote: > When I install a new version of R (Windows XP) I have to: > > 1. copy my rw\etc\Rprofile.site file to the new installation > > 2. copy the rw\share\texmf files to the tex subfolder of the >miktex root directory and then refresh the miktex name database >(I have a batch file that does this for me which I run >whenever I install a new version of R.) > > 3. setup the shortcut key using 'properties' on my R desktop icon so >that ctrl-alt-R brings up the new rather than the old R. (This one >really had me confused once since I did not realize I was still >using the old version of R after installing the new one.) > > 4. reinstall the packages I use or else setup etc\Renviron.site with >an R_LIBS to point to include the old library or perhaps one can >copy the libraries over being careful not to overwrite new versions >of the standard libraries. > > Many other windows program automatically transfer the settings when > you upgrade them. > > I wonder if the installation process could optionally transfer > such settings from an old installation to a new one to make it > easier to install R. I think a couple of these could be handled by not applying so many modifications to the R installation, do more locally. For example, #1 needn't be copied, you can just use the R_ENVIRON environment variable to point to it and both versions will see it. I'd call #2 a bug in MikTeX, but it's probably one we'll have to work around one of these days. (The bug is dropping support for the environment variable specification of extra include directories.) #3 might be something we could do, but I don't see how. The installer could know what hotkey you used the last time you installed R, but if you changed it in the meantime, how would it know about that? And how would it remove the hotkey from the old shortcut? (A little experimentation suggests that XP is buggy in handling multiple shortcuts with the same hotkey. I'd rather stay away from this.) #4 is another case where you can put your libraries outside R_HOME. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Building R v2.1.1 for Windows
Erich Neuwirth wrote: > Recently, I notice strange things when I try to build R 2.1.1 on Windows XP. > I downloaded and unpacked. R-2.1.1.tar.gz. > All the tools are in place. > > I get as far as building the installer, and then the following happens: > > perl JRins.pl rw2011 rw2011 > "C:/Program Files/Inno Setup 5/iscc" R.iss > rw2011.log 2>&1 > make[2]: Leaving directory > `/cygdrive/c/devel/R/R-2.1.1/src/gnuwin32/installer' > make[2]: Entering directory > `/cygdrive/c/devel/R/R-2.1.1/src/gnuwin32/installer' > > rm -rf R.iss Rsmall.iss *.log rw2011 > rm: cannot remove directory `rw2011/library/base/html': Directory not empty > rm: cannot remove directory `rw2011/library/tcltk/Meta': Directory not empty > make[2]: *** [clean] Error 1 > make[2]: Leaving directory > `/cygdrive/c/devel/R/R-2.1.1/src/gnuwin32/installer' > make[1]: *** [rinstaller] Error 2 > make[1]: Leaving directory `/cygdrive/c/devel/R/R-2.1.1/src/gnuwin32' > make: *** [distribution] Error 2 > > Looking into the two supposedly nonempty directories > I see that in fact that are empty. > Of course, I only can look a little bit later, so this might be a timing > issue. > Has anyone experienced similar problems? > This effect is somewhat random. The supposedly nonempty directories > change from build attempt to build attempt. > > So far, this has not happened when I build R-patched and R-devel which > I update from SVN. I haven't seen that error so far during an R build, but I believe you'll get it if the directory is busy because it is the current directory for some process. Did you have another window open that was looking at it? Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] How difficult is it to wrap a large C++ library with R?
On 7/4/2005 1:01 PM, Bo Peng wrote: > Dear list, > > I have developed a forward-time population genetics simulation > environment simuPOP, which is a set of C++ (template) > classes/functions wrapped by SWIG as Python libraries. R is used > extensively as plotting and statistical analysis engine through RPy > package. > > I use Python to wrap simuPOP since most the following can be easily > done using SWIG or Python C API. However, since Python is less used by > bioinformaticists and geneticists, I am asked again and again why I do > not wrap simuPOP with R (R is also OOP etc...). Although I am a long > time R user, I am not familiar with package writing in R. From what I > read from R website, it is easy to wrap individual C/C++ functions but > not C++ classes. Can anyone take the time to review the following and > tell me if they can be done (easily or need effort) using R? If most > of the answers are yes, it may be a good idea to switch to R. > > * Wrap C++ class hierarchy. Virtual functions need to be supported. > (SWIG can generate Python shadow classes that behave almost exactly > like the underlying C++ classes) This is hard to do in R, because the R object model is quite different from that of C++ (whereas Python's is more similar). > * Be able to do this: > evolve(ops=c(obj1, obj2, obj3)) > Internally, evolve will call virtual function fun() of obj1, obj2, .etc. > obj1, obj2, ... are objects derived from the same base class. This wouldn't be hard, assuming that the 3 objects have classes, and there's a generic function fun() which owns methods supporting those classes. (In R, objects don't have virtual functions, generic functions do.) > * Direct access to C++ data structure. For example, an object may keep > a C array internally. I will need a method (maybe wrap this data into > a R object) to read/write this array directly. That's not too hard provided you use C++ code to do the actual access. That is, you write an R function that calls C++ code to do the work. It's a lot harder if you want to keep it all in R, because it doesn't understand C++ type definitions, alignment conventions, etc. > * create and read/write a R list at C++ level. (Need API for R/list > read/write) That's not too hard. There are lots of examples in contributed libraries, and it's documented in the R Extensions manual. > > * pass a user defined R function to C++ function. Call it and obtain result. Ditto. > > * evaluate an R expression (passed as string) from within C++ function > and obtain result. Ditto. > > * pass C++ exceptions to R That's hard, because R won't know what to do with them. There are ways to turn C++ exceptions into R errors, but they are not well documented, and I suspect you'll need to do most of the work (i.e. have an exception handler that calls an internal R function). > * be able to use C++ features like template, STL. In your own C++ code? If gcc supports them, it'll be easy. If you need a special compiler, it'll be harder. In R code? Forget it. > * organize manual by objects, not functions. (I notice that manuals of > R libraries are simple function references.) You can write a vignette organized any way you like. The code that shows up in the printed manuals is just a collection of Rd man pages, organized more or less alphabetically. > Many thanks in advance. > > -- > Bo Peng > Department of Statistics > Rice University > http://bp6.stat.rice.edu:8080/ > > __ > 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] .Rbuildignore {was: ... upgrading an R (WINDOWS) installation ..}
Uwe Ligges wrote:
> Gabor Grothendieck wrote:
>
>
>>On 7/6/05, Uwe Ligges <[EMAIL PROTECTED]> wrote:
>>
>>
>>>Gabor Grothendieck wrote:
>>>
>>>
>>>
>>>>On 7/6/05, Martin Maechler <[EMAIL PROTECTED]> wrote:
>>>>
>>>>
>>>>
>>>>>>>>>>"Gabor" == Gabor Grothendieck <[EMAIL PROTECTED]>
>>>>>>>>>> on Wed, 6 Jul 2005 08:24:49 -0400 writes:
>>>>>
>>>>>...
>>>>>...
>>>>>
>>>>> Gabor> I have cleaned up my batch files (somewhat) and posted them to
>>>>> Gabor> CRAN. See my recent post:
>>>>> Gabor>
>>>>> https://www.stat.math.ethz.ch/pipermail/r-help/2005-July/073400.html
>>>>>
>>>>> Gabor> If any of this functionality could migrate to R
>>>>> Gabor> itself that would be great.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Gabor> 2. Also if Rcmd CHECK and Rcmd INSTALL were to
>>>>> Gabor> process .Rbuildignore like Rcmd BUILD does then
>>>>> Gabor> makepkg.bat would not have to do a build first.
>>>>>
>>>>>No! {We have been here before, and I had explained before that}
>>>>>this is really undesired: ".Rbuildignore" should contain what is
>>>>>ignored by build, but not by "check".
>>>>>It does make sense to have extra code and / or checks for 'R CMD check'
>>>>>that I as package developer want to run, but that are
>>>>>-- too time consuming
>>>>>-- too platform specific
>>>>>-- ..
>>>>>to be run during the daily checks on CRAN (e.g.) /
>>>>>to be run by others at all.
>>>>>
>>>>>{And BTW, AFAIK, 'Rcmd' is now `somewhat deprecated' in favor
>>>>>of "R CMD" since the latter is portable }
>>>>>
>>>>>--
>>>>>Martin
>>>>>
>>>>
>>>>
>>>>I think its too heavy handed an approach. This should be up to the package
>>>>developer via a switch. I like to put partially written code and other
>>>>things
>>>>not intended for distribution in .Rbuildignore and don't want them checked
>>>>or
>>>>installed until I move them out of .Rbuildignore. That makes it
>>>>possible to keep
>>>>everything together. Without this one must 1. keep them elsewhere
>>>>(which I am considering as an alternate approach to what I do now although
>>>>it would be a shame) or else 2. write batch files (which I have
>>>>written for XP) to do
>>>>a prebuild every time one does a check or install.
>>>>
>>>>One annoying aspect of R CMD is the requirement for capitalization. Maybe
>>>>that's ok on UNIX but on Windows one is used to using upper and lower
>>>>case interchangeably. Its also annoying to have to write two words instead
>>>>of
>>>>one for a frequently issued command. At any rate I always call it through
>>>
>>>Gabor, honestly, this is nonsense.
>>>
>>>1. Do you expect that R also changes under Windows because you are used
>>>to mix upper and lower case and want to say SUMMARY() or rowsums()?
>>>2. Do you really thing it is annoying to type "R CMD" rather than
>>>"Rcmd"? Hmm, anybody else has a space bar left for Gabor?
>>>
>>>Best,
>>>Uwe
>>>
>>>
>>>
>>>>my Rcmd.bat batch file so its not really an issue for me.
>>
>>
>>It was claimed its portable and that is true in the strictest sense that it
>>works on both UNIX and Windows but it would be even more
>>desirable if it were not just portable but also worked the way the target
>>system worked rather than just acting like a UNIX utility does
>>on Windows. Ideally it would work as other Windows utilities work,
>>e.g. note that we run the following using upper and lower case and
>>get the same result:
>>
>>C:> net use ?
>>The syntax of this command is:
>>NET USE
>>[devicename | *] [\\computername\sharename[\volume] [password | *]]
>>...
>>
>>C:> NET USE ?
>>The syntax of this command is:
>>NET USE
>>[devicename | *] [\\computername\sharename[\volume] [password | *]]
>>...
>
>
> No! That something completely different: If Windows allows to use "net
> use" and "NET USE" even if only the latter is the documeted way, OK.
> These are, as you mentioned yourself, *Windows utilities* and you don't
> want to port this syntax.
>
> But if you type "R cmd", it is no longer portable, and "Rcmd" for sure
> is not. "R CMD" is an R utility --- and R behaves case senstive.
>
> Uwe Ligges
In fact, on Windows R is not case sensitive in the 1st or 3rd word on
the line "R CMD install", only in the 2nd, so I can see Gabor's point.
However, I have to admit I always use "Rcmd install"; I put the "R CMD
..." version in place to help Unix refugees.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem with dyn.load...or else...
On 7/7/2005 10:16 AM, Marie-Hélène Ouellette wrote:
> At 19:46 2005-07-06, you wrote:
>>Marie-Hélène Ouellette wrote:
>>>Hi everybody,
>>>I'm working on Mac OS X and R-2.1.0 (by the way, sorry for the multiple
>>>emails last time, had a technical problem, and thanks for the
>>>constructive comments.)
>>>I have a .R function which calls a .C function. The R function's name is
>>>K_MEANSR.R and the other is K_MEANSC.C.
>>>I compile it with 'R CMD SHLIB K_MEANSC.C' in the terminal. I get both
>>>.so and .o files.
>>>I use the function
>>> > dyn.load ('K_MEANSC.so')
>>>with no error. We can, I believe, see here that it is loaded:
>>>
>>> > getLoadedDLLs()
>>>
>>>Filename
>>>base base
>>>grDevices
>>>/Library/Frameworks/R.framework/Resources/library/grDevices/libs/grDevices.so
>>>stats /Library/Frameworks/R.framework/Resources/library/stats/libs/stats.so
>>>methods
>>>/Library/Frameworks/R.framework/Resources/library/methods/libs/methods.so
>>>K_MEANSC
>>>/Users/admin/Desktop/Marie/Marie_labo_29_juin/K-means_versions/MAC/K_MEANSC.so
>>>R_X11 /Library/Frameworks/R.framework/Resources/modules/R_X11.so
>>>Dynamic.Lookup
>>>base FALSE
>>>grDevices FALSE
>>>stats FALSE
>>>methodsFALSE
>>>K_MEANSCTRUE
>>>R_X11 TRUE
>>>
>>>I then source the R code:
>>> > source(file.choose())
>>>Construct a matrix that I will use for the analysis:
>>> > tab<-c(1,1,3,4,6,6,3,5,7,67,5,6,65,3,5,1,5,42,3,567,6,4,7,7)
>>> > tab<-matrix(tab,6,4)
>>>And try to use the function:
>>> > K_MEANSR(tab,centers=c(2,4))
>>>[1] "AA"
>>>[1] "AAA"
>>>[1] "A"
>>>[1] "B"
>>>Error in .C("K_MEANSC", xrows = as.integer(xrows), xcols =
>>>as.integer(xcols), :
>>> "C" function name not in load table
>>>Everything that is printed on the screen is correct, but why does it says
>>>that 'K_MEANSC' function is not in load table??? It then just stops at
>>>that stage of the .R function.
>>
>>What does your declaration of the function look like in the K_MEANSC.C
>>file? R needs to know the name of the exported function, not the name of
>>the .so file.
>>
>>Duncan Murdoch
>
>
> It's in the form:
>
> K_MEANSC<- function(arguments...)
> {
>
> }
> So the name of my .C function is also K_MEANSC...
No, you misunderstood. That's R code; I was asking about the C language
code that you want .C("K_MEANSC", xrows = as.integer(xrows) ... to call.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] write.csv (PR#7992)
On 7/7/2005 12:38 PM, Gabor Grothendieck wrote:
> This may not be inconsistent with the documentation but it is
> inconsistent with good practice. Wrappers should, in general,
> set the default values, as the poster rightly indicated, and not the
> values themselves. Its not a coincidence that multiple people
> have mentioned this.
The old header (which teasingly displayed some parameters and then
ignored them) was clearly wrong, but the new one doesn't display the
parameters.
This is pretty reasonable practice. It's a wrapper that provides a
subset of the functionality, but is guaranteed to produce a legal file
of the type it claims to produce. I don't see anything wrong with it.
Duncan Murdoch
>
> On 7/7/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>> This topic already came up about a week ago on R-devel
>> Subject: write.csv suggestion
>>
>> [ too bad that "R-devel" is not available via RSiteSearch() ...
>>{I could send you the back archives, Jon, if you are interested} ]
>>
>> There, Brian Ripley, explained why this is not a bug, since
>> it works as documented, "CSV" files are well defined entities
>> and you can always use write.table() if you want to be flexible.
>>
>> Brian also changed things for R-devel {to be R 2.2.x} such that
>> its help page, see
>> http://stat.ethz.ch/R-manual/R-devel/library/base/html/write.table.html ,
>> now has
>>
>> > Usage:
>> >. . . .
>> >
>> > write.csv(...)
>> > write.csv2(...)
>> >
>> > . . . .
>> >
>> >
>> > Arguments:
>> >. . . .
>> >
>> > ...: arguments to 'write.table': 'col.names', 'sep', 'dec' and
>> > 'qmethod' cannot be altered.
>>
>> which should make the intention of the write.csv*() wrapper
>> functions a bit more clear.
>>
>> Regards,
>> Martin Maechler, ETH Zurich
>>
>> >>>>> "arnima" == arnima <[EMAIL PROTECTED]>
>> >>>>> on Thu, 7 Jul 2005 05:21:43 +0200 (CEST) writes:
>>
>>arnima> The write.csv() function is currently implemented as
>>arnima> function (..., col.names=NA, sep=",", qmethod="double")
>>arnima> {
>>arnima> write.table(..., col.names=NA, sep=",", qmethod="double")
>>arnima> }
>>
>>arnima> Surely, it should be
>>
>>arnima> function (..., col.names=NA, sep=",", qmethod="double")
>>arnima> {
>>arnima> write.table(..., col.names=col.names, sep=sep, qmethod=qmethod)
>>arnima> }
>>
>>arnima> so that the user arguments serve a purpose. This notion is
>> reflected in
>>arnima> the implementation of read.csv(), for example, where sep=sep,
>> quote=quote,
>>arnima> etc.
>>
>>
>>arnima> Arni
>>
>>arnima> R 2.1.1pat 2005-07-04 on WinXP
>>
>> __
>> 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] Interpretting R profiling output (was More efficient code?)
Gavin Simpson wrote: > On Wed, 2005-07-06 at 19:54 +0100, Gavin Simpson wrote: > >>Dear List, >> > > > I fixed up the code in coinertiaI to only return the bits I needed from > La.svd() within the permutations - thus producing a 10% speed up. I am > still a little unclear about the results from Rprof() (below). > > Do the timings under self time for .Call and .Fortran include the time > spent actually running the called compiled code or are they the overhead > of setting up the calls to the compiled code? They include both. The profiler only sees R calls, it doesn't know what goes on within functions. .Call() is an R call which internally calls some C function, but the profiler just sees the call to .Call. Duncan Murdoch > > Many thanks, > > Gav > > >>summaryRprof(filename = "Rprof.out") >>$by.self >> self.time self.pct total.time total.pct >>".Call" 50.40 59.6 50.40 59.6 >>"%*%"10.50 12.4 10.50 12.4 >>".Fortran"2.78 3.3 2.78 3.3 >>"La.svd" 2.52 3.0 57.98 68.6 >>"^" 2.48 2.9 2.48 2.9 >>"t.default" 2.30 2.7 2.30 2.7 >>"matrix" 1.92 2.3 1.98 2.3 >>"as.double" 1.78 2.1 2.70 3.2 >>"list"0.88 1.0 0.88 1.0 >>"as.double.default" 0.86 1.0 0.86 1.0 >>"rep.default" 0.74 0.9 0.86 1.0 >>"sum" 0.72 0.9 2.58 3.1 >>"!" 0.50 0.6 0.50 0.6 >>"diag"0.44 0.5 1.46 1.7 >>"qr.coef" 0.42 0.5 6.26 7.4 >>"permtest"0.38 0.4 83.60 98.9 >>"is.finite" 0.38 0.4 0.38 0.4 >>"storage.mode<-" 0.36 0.4 3.26 3.9 >>"as.integer" 0.34 0.4 0.40 0.5 >>"t" 0.32 0.4 2.62 3.1 >>"$" 0.32 0.4 0.32 0.4 >>"paste" 0.28 0.3 0.54 0.6 >>"teststat"0.24 0.3 83.10 98.3 >>"residualMatrix" 0.22 0.3 10.32 12.2 >>"qr" 0.20 0.2 1.24 1.5 >>... >> >>$by.total >> total.time total.pct self.time self.pct >>"predcoca.perm" 84.50 100.0 0.00 0.0 >>"permtest"83.60 98.9 0.38 0.4 >>"teststat"83.10 98.3 0.24 0.3 >>"coinertiaI" 73.24 86.7 0.18 0.2 >>"La.svd" 57.98 68.6 2.52 3.0 >>".Call" 50.40 59.6 50.40 59.6 >>"%*%" 10.50 12.4 10.50 12.4 >>"residualMatrix" 10.32 12.2 0.22 0.3 >>"qr.coef" 6.26 7.4 0.42 0.5 >>"storage.mode<-" 3.26 3.9 0.36 0.4 >>".Fortran" 2.78 3.3 2.78 3.3 >>"as.double"2.70 3.2 1.78 2.1 >>"t"2.62 3.1 0.32 0.4 >>"eval" 2.62 3.1 0.14 0.2 >>"sum" 2.58 3.1 0.72 0.9 >>... >> __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Sweave resource leak: leftover temp files
On 7/8/2005 9:36 AM, Doran, Harold wrote:
> This is great. Thank you for your help, but let me make sure I fully
> understand. Here is the looping file I use to subset the data frame,
> create a tex file, and Sweave it. This results in N number of tex files
> where N is equal to the number of rows in the data frame.
>
> list <- unique(wide$stuid)
> master = "master.tex"
> for (i in list){
> tmp1 <- subset(wide, stuid==i)
> tmp2 <- paste(i, "tex", sep=".")
> Sweave("fam_template.Rnw", output=tmp2)
> file.append("fam_master.tex", tmp2)
> }
>
> If I follow correctly, I would need to place these commands inside the
> loop as follows:
>
> list <- unique(wide$stuid)
> master = "master.tex"
> for (i in list){
> tmp1 <- subset(wide, stuid==i)
> tmp2 <- paste(i, "tex", sep=".")
> keep <- list.files(tempdir(), full=TRUE) # keep previous temp
> files
> Sweave("fam_template.Rnw", output=tmp2)
> file.append("fam_master.tex", tmp2)
> temps <- list.files(tempdir(), full=TRUE) unlink(temps[!(temps %in%
> keep)]) # delete the newly created ones
> }
There's a wordwrapping error there: the temps <- list.files(...) and
unlink(temps...) should be on separate lines.
I'd also put them immediately after the Sweave call, but they should be
fine where you have them. (The advantage of putting them immediately
after Sweave is that you don't need to think about the next line. If it
created a temp file and you wanted to keep it, you'd need the extra
lines first. But it doesn't, so it doesn't really matter.)
Duncan Murdoch
>
>
> Thank you for taking the time to look at this.
>
> Harold
>
> -Original Message-
> From: Duncan Murdoch [mailto:[EMAIL PROTECTED]
> Sent: Friday, July 08, 2005 9:28 AM
> To: Duncan Murdoch
> Cc: Doran, Harold; [EMAIL PROTECTED]; Uwe Ligges; Sean O'Riordain
> Subject: Sweave resource leak: leftover temp files
>
> Harold, I've taken a closer look at your example and I'd call this an
> Sweave bug. It creates tempfiles each time you run it, and doesn't
> delete them at the end. For example:
>
> > list.files(tempdir())
> character(0)
> > testfile <- system.file("Sweave", "Sweave-test-1.Rnw", package =
> "utils") > Sweave(testfile, out="junk.tex") Writing to file junk.tex
> Processing code chunks ...
> 1 : print term verbatim
> 2 : term hide
> 3 : echo print term verbatim
> 4 : term verbatim
> 5 : echo term verbatim
> 6 : echo term verbatim eps pdf
> 7 : echo term verbatim eps pdf
>
> You can now run LaTeX on 'junk.tex'
> > list.files(tempdir())
> [1] "Rf10523" "Rf13872" "Rf17129" "Rf2055" "Rf2203" "Rf2403"
> "Rf27095"
> [8] "Rf2892" "Rf31415" "Rf5290" "Rf6251" "Rf6482" "Rf7055"
> "Rf724"
> > Sweave(testfile, out="C:/temp/junk.tex") Writing to file
> C:/temp/junk.tex Processing code chunks ...
> 1 : print term verbatim
> 2 : term hide
> 3 : echo print term verbatim
> 4 : term verbatim
> 5 : echo term verbatim
> 6 : echo term verbatim eps pdf
> 7 : echo term verbatim eps pdf
>
> You can now run LaTeX on 'C:/temp/junk.tex'
> > list.files(tempdir())
> [1] "Rf10523" "Rf12679" "Rf1311" "Rf13484" "Rf13872" "Rf17129"
> "Rf17288"
> [8] "Rf2055" "Rf21774" "Rf2203" "Rf23417" "Rf2403" "Rf27095"
> "Rf2892"
> [15] "Rf29444" "Rf31128" "Rf31415" "Rf32520" "Rf3338" "Rf5290"
> "Rf5551"
> [22] "Rf6251" "Rf6482" "Rf7055" "Rf724" "Rf7543" "Rf758"
> "Rf7673"
> > unlink(list.files(tempdir(),full=T))
> > list.files(tempdir())
> character(0)
>
> Harold: a workaround for this would be to wrap your Sweave call in
> something like this:
>
> keep <- list.files(tempdir(), full=TRUE) # keep previous temp files
>
> ... Call Sweave here ...
>
> temps <- list.files(tempdir(), full=TRUE) unlink(temps[!(temps %in%
> keep)]) # delete the newly created ones
>
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Sweave resource leak: leftover temp files (PR#7999)
One additional note: followups should only go to R-bugs if they have
the bug number on them (like this message does). Otherwise you end up
generating a separate bug report (PR#7999 was created in your reply to
my submission of PR#7998). Usually it's best just to cc R-devel, unless
you really have additional information to add to the bug report.
We're planning (or in the process of?) changing the bug reporting
system, so this is only a temporary inconvenience.
Duncan Murdoch
On 7/8/2005 9:36 AM, [EMAIL PROTECTED] wrote:
> This is great. Thank you for your help, but let me make sure I fully
> understand. Here is the looping file I use to subset the data frame,
> create a tex file, and Sweave it. This results in N number of tex files
> where N is equal to the number of rows in the data frame.
>
> list <- unique(wide$stuid)
> master = "master.tex"
> for (i in list){
> tmp1 <- subset(wide, stuid==i)
> tmp2 <- paste(i, "tex", sep=".")
> Sweave("fam_template.Rnw", output=tmp2)
> file.append("fam_master.tex", tmp2)
> }
>
> If I follow correctly, I would need to place these commands inside the
> loop as follows:
>
> list <- unique(wide$stuid)
> master = "master.tex"
> for (i in list){
> tmp1 <- subset(wide, stuid==i)
> tmp2 <- paste(i, "tex", sep=".")
> keep <- list.files(tempdir(), full=TRUE) # keep previous temp
> files
> Sweave("fam_template.Rnw", output=tmp2)
> file.append("fam_master.tex", tmp2)
> temps <- list.files(tempdir(), full=TRUE) unlink(temps[!(temps %in%
> keep)]) # delete the newly created ones
> }
>
>
> Thank you for taking the time to look at this.
>
> Harold
>
> -Original Message-
> From: Duncan Murdoch [mailto:[EMAIL PROTECTED]
> Sent: Friday, July 08, 2005 9:28 AM
> To: Duncan Murdoch
> Cc: Doran, Harold; [EMAIL PROTECTED]; Uwe Ligges; Sean O'Riordain
> Subject: Sweave resource leak: leftover temp files
>
> Harold, I've taken a closer look at your example and I'd call this an
> Sweave bug. It creates tempfiles each time you run it, and doesn't
> delete them at the end. For example:
>
> > list.files(tempdir())
> character(0)
> > testfile <- system.file("Sweave", "Sweave-test-1.Rnw", package =
> "utils") > Sweave(testfile, out="junk.tex") Writing to file junk.tex
> Processing code chunks ...
> 1 : print term verbatim
> 2 : term hide
> 3 : echo print term verbatim
> 4 : term verbatim
> 5 : echo term verbatim
> 6 : echo term verbatim eps pdf
> 7 : echo term verbatim eps pdf
>
> You can now run LaTeX on 'junk.tex'
> > list.files(tempdir())
> [1] "Rf10523" "Rf13872" "Rf17129" "Rf2055" "Rf2203" "Rf2403"
> "Rf27095"
> [8] "Rf2892" "Rf31415" "Rf5290" "Rf6251" "Rf6482" "Rf7055"
> "Rf724"
> > Sweave(testfile, out="C:/temp/junk.tex") Writing to file
> C:/temp/junk.tex Processing code chunks ...
> 1 : print term verbatim
> 2 : term hide
> 3 : echo print term verbatim
> 4 : term verbatim
> 5 : echo term verbatim
> 6 : echo term verbatim eps pdf
> 7 : echo term verbatim eps pdf
>
> You can now run LaTeX on 'C:/temp/junk.tex'
> > list.files(tempdir())
> [1] "Rf10523" "Rf12679" "Rf1311" "Rf13484" "Rf13872" "Rf17129"
> "Rf17288"
> [8] "Rf2055" "Rf21774" "Rf2203" "Rf23417" "Rf2403" "Rf27095"
> "Rf2892"
> [15] "Rf29444" "Rf31128" "Rf31415" "Rf32520" "Rf3338" "Rf5290"
> "Rf5551"
> [22] "Rf6251" "Rf6482" "Rf7055" "Rf724" "Rf7543" "Rf758"
> "Rf7673"
> > unlink(list.files(tempdir(),full=T))
> > list.files(tempdir())
> character(0)
>
> Harold: a workaround for this would be to wrap your Sweave call in
> something like this:
>
> keep <- list.files(tempdir(), full=TRUE) # keep previous temp files
>
> ... Call Sweave here ...
>
> temps <- list.files(tempdir(), full=TRUE) unlink(temps[!(temps %in%
> keep)]) # delete the newly created ones
>
> __
> 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] pairs() uses col argument for axes coloring
On 7/8/2005 8:52 AM, Olaf Mersmann wrote: > Hi Duncan, > > On 7/8/05, Duncan Murdoch <[EMAIL PROTECTED]> wrote: >> Olaf Mersmann wrote: > *snip* >> > Looking at the source for pairs() suggests, that this is the case >> > because col is part of the ... argument list which is passed on to >> > localAxis (and from there to axis). Wouldn't it be more approptiate to >> > use the same color box() uses to draw the border around each >> > scatterplot? If yes, should I open a bug for this or how would such a >> > feature request be handled? >> >> The best way is to get the source to pairs() (from the SVN repository >> in https://svn.r-project.org/R/trunk/src/library/graphics/R/pairs.R not >> from looking at it in R), work out what changes are needed, and submit >> them as a patch. You can post the patch in the R-bugs list, or just >> send it to me. Thanks! > > I attached my patch to pairs.R to fix the problem. They way I 'solved' > the issue is by simply ignoring any col argument that is passed to > localAxis and from there to axis. At first I had thought about adding > col explicitly to the argument list of pairs() and then only passing > it on to the panel functions, but that would possibly break existing > code (for example the example panel.cor() in the pairs() man page). I like your fix. It makes pairs() act like plot() in its treatment of col and col.axis parameters. I do find the col.axis treatment a little weird (affecting the labels, but not the axis), but that's a different issue. I'll commit your patch to R-devel and R-patched. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Error message using Packages | Install | Cancel
On 7/8/2005 8:56 AM, Gabor Grothendieck wrote: > If we click on the Cancel button after the Packages | Install menu items in > Windows 2.1.1 (dated 2005-06-23) it gives an error message. There > really should > be no error here since we intended not to install anything -- that is why > we pressed Cancel. This is what appears on the console: > >> utils:::menuInstallPkgs() > Error in install.packages(NULL, .libPaths()[1], dependencies = TRUE, > type = type) : > no packages were specified I'd consider a patch to fix this, but it doesn't look serious enough to make it onto my list of things to do myself. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] ActiveState Perl, cygwin and R (was: cygwin tar?)
On 7/11/2005 8:30 AM, Gorjanc Gregor wrote: > Hello! > > I have just read mails in thread > > <http://tolstoy.newcastle.edu.au/R/devel/04a/0583.html> > > about problems with Cygwin and Rtools. I had the same problems and kept > just the newest cygwin1.dll and things seem OK now. However I > currently hit the problem with Perl (I have ActiveState and Cygwin Perl > installed). When I tried to work with 'Rdconv' in Cygwin I get the following: > > $ R CMD Rdconv --help > Can't locate R/Rdconv.pm in @INC (@INC contains: > c \Programs\R\rw2011beta\share\perl; /usr/lib/perl5/5.8/cygwin > /usr/lib/perl5/5.8 /usr/lib/perl5/site_perl/5.8/cygwin > /usr/lib/perl5/site_perl/5.8 /usr/lib/perl5/site_perl/5.8 > /usr/lib/perl5/vendor_perl/5.8/cygwin /usr/lib/perl5/vendor_perl/5.8 > /usr/lib/perl5/vendor_perl/5.8 .) at c:\Programs\R\rw2011beta/bin/Rdconv > line 25. > BEGIN failed--compilation aborted at c:\Programs\R\rw2011beta/bin/Rdconv line > 25. > > As far as I understand there is a problem since Cygwins perl does not > have things properly setup. I did not touch anything yet. But I can see the > problem in first entry of @INC. There should be /cygdrive/c/.. or c:/ (I do > not know if the last one actually works with Cygwins perl) and therefore > things are broken. > > If I modified PATH such that ActiveState Perl was before Cygwins Perl, > everyting was as expected. > > Is there a way to overcome this with Cygwins Perl? I think you need to ask on a Cygwin list, but my guess is that it won't be easy. Rcmd puts $R_HOME\share\perl in the PERL5LIB environment variable. Cygwin programs tend not to understand Windows paths like that. There may be a way to write a wrapper to convert the variable so that Cygwin's perl understands it, or a configuration flag, but I'd say it's easier to use the ActiveState perl. Rgui is a Windows program, not a Cygwin one. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Computer algebra in R - would that be an idea??
On 7/12/2005 10:57 AM, Gabor Grothendieck wrote: > On 7/12/05, Søren Højsgaard <[EMAIL PROTECTED]> wrote: >> >From time to time people request symbolic computations beyond what D() and >> >deriv() etc can provide. A brief look at the internet shows that there are >> >many more or less developed computer algebra packages freely available. >> >Therefore, I wondered if it would be an idea to try to 'integrate' one of >> >these packages in R, which I guess can be done in more or less elegant >> >ways... I do not know any of the computer algebra people around the World, >> >but perhaps some other people from the R-community do and would be able >> >to/interested in establishing such a connection... > > > Coincidentally I asked the yacas developer about this just yesterday: > http://sourceforge.net/mailarchive/forum.php?thread_id=7711431&forum_id=2216 It sounds like developing an R package to act as a wrapper would be the best approach. I didn't see documentation for their API (the exports of their DLL), but I didn't spend long looking. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R v2.1.0 patched (>2005-05-09) for Windows?
On 7/15/2005 4:01 AM, Henrik Bengtsson wrote:
> I'm trying to troubleshoot a case where R crashes on Windows. It does
> not occur at all with my R v2.1.0 patched (2005-05-09), but happens on R
> v2.1.1 (patched or non-patched) in many different cases. The R
> v2.2.0dev (2005-07-15) also got this problem (although it won't crash on
> the below example). I previously reported this
> (https://stat.ethz.ch/pipermail/r-devel/2005-June/033772.html) and
> Duncan Murdoch kindly offered to look into the problem, but it is
> tricky. Now I would like to track down in what patched R v2.1.0 the
> problem first occurs and are now looking for reports from newer version,
> but pre-Rv2.1.1.
>
> If you've got R v2.1.0 patched for Windows *after 2005-05-09*, could you
> please try the following in that version of R?
>
> install.packages("R.oo")
> library(R.oo)
> author <- "dummy"
> rdocFile <- system.file("misc", "Exception.R", package="R.oo")
> cat("# Empty example code\n", file="Exception.Rex")
> Rdoc$compile(rdocFile, destPath=tempdir())
> print("successful!")
>
> If you see "successful!", that version is "ok", otherwise R will crash
> (or alternatively incorrectly complain about an invalid regular
> expression; rerun and it will crash the 2nd time). I would appreciate a
> lot if you report to me what you get and what is your version of R?
> Thanks a lot!
>
> Note that this is most likely *not* due to R.oo (no native code) - my
> wild guess is that it has to do with a memory leak in the code for
> environments or regular expressions.
I'll do a series of builds to try this out and determine the date.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Most accurate timing?
For a graphics display, I'd like a high resolution timer, something like Sys.time(), but it is only accurate to a second. Is there a clock in R that gives a finer value? Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Most accurate timing?
On 8/1/2005 9:09 AM, Martin Maechler wrote: >>>>>> "Duncan" == Duncan Murdoch <[EMAIL PROTECTED]> >>>>>> on Mon, 01 Aug 2005 08:48:39 -0400 writes: > > Duncan> For a graphics display, I'd like a high resolution > Duncan> timer, something like Sys.time(), but it is only > Duncan> accurate to a second. Is there a clock in R that > Duncan> gives a finer value? > > Why can't use proc.time() ? > > It's help file says > > The resolution of the times will be system-specific; it is > common for them to be recorded to of the order of 1/100 > second, and elapsed time is rounded to the nearest 1/100. > proc.time()[3] is what I want; I had forgotten about it. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] fifo on Windows
Gabor Grothendieck wrote:
> Are there any plans to support fifo on Windows? On my XP
> system ("R version 2.1.1, 2005-06-23")
>
>R> capabilities("fifo")
>
> gives FALSE.
>
> Note that Windows does support named pipes as shown
> in the utility:
>
>http://gearbox.maem.umr.edu/fwu/pipeslot.zip
I think named pipes are only supported on the NT descendants. We will
need to drop support for Win9x soon, but I think we still have a number
of users using Win98 and maybe WinME.
I guess we could add support for features that only work on some Windows
platforms, but I'd rather not do that until we're not officially saying
that R runs on Win9x.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] valgrind complains about regex.c (PR#8043)
Prof Brian Ripley wrote: > Did you compile R without optimization? Such reads are often the result > of read-aheads produced by the optimizer in an attempt to keep > pipelines full (and are harmless). There were both a read and a write. I can see the read being harmless, but is the write harmless? I suspect this may be the bug I fixed on July 16, since it had to do with character classes including ranges (like Charlie's "[a-pr-z]"). Charlie, have you tried a recent version of R-patched? Duncan Murdoch > > On an un-optimized build of R I am unable to reproduce this. (I also was > unable to reproduce it on my optimized build of 2.1.1 using gcc 3.4.4, > although I did get a report on other read-aheads.) > > On Mon, 1 Aug 2005 [EMAIL PROTECTED] wrote: > > >>I think I am using objects according to the man page. >>This seems to be a valid regular expression. But whether >>I know what I'm doing or no, it still shouldn't be doing >>what valgrind seems to be saying it's doing. (IMHO) > > > I think you need to take that up with compiler designers: it is common > practice. > > >>-- start of script -- >>Script started on Mon 01 Aug 2005 02:09:00 PM PDT >>linux$ printenv VALGRIND_OPTS >>--tool=3Dmemcheck >>linux$ cat bar.R >> >>foo <- 1 >>bar <- 2:3 >>baz <- 4:6 >>qux <- matrix(7:10, 2) >> >>ls() >>rm(list =3D objects(pattern =3D "^[a-pr-z]")) >>ls() >> >>linux$ R --version >>R 2.1.1 (2005-06-20). >>Copyright (C) 2005 R Development Core Team >> >>R is free software and comes with ABSOLUTELY NO WARRANTY. >>You are welcome to redistribute it under the terms of the GNU >>General Public License. For more information about these matters, >>see http://www.gnu.org/copyleft/gpl.html. >>linux$ gcc --version >>=1B[0mgcc (GCC) 3.3.5 20050117 (prerelease) (SUSE Linux) >>=1B[0mCopyright (C) 2003 Free Software Foundation, Inc. >>=1B[0mThis is free software; see the source for copying conditions. There = >>is NO >>=1B[0mwarranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PU= >>RPOSE. >>=1B[0m >>linux$ cat /etc/SuSE-release=20 >>SuSE Linux 9.3 (i586) >>VERSION =3D 9.3 >>linux$ R --vanilla --debugger=3Dvalgrind < bar.R >| bar.Rout >>=3D=3D22324=3D=3D Memcheck, a memory error detector for x86-linux. >>=3D=3D22324=3D=3D Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward = >>et al. >>=3D=3D22324=3D=3D Using valgrind-2.2.0, a program supervision framework for= >>x86-linux. >>=3D=3D22324=3D=3D Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward = >>et al. >>=3D=3D22324=3D=3D For more details, rerun with: -v >>=3D=3D22324=3D=3D=20 >>=3D=3D22324=3D=3D Invalid read of size 4 >>=3D=3D22324=3D=3Dat 0x81255AD: parse_expression (regex.c:5045) >>=3D=3D22324=3D=3Dby 0x8125868: parse_branch (regex.c:4475) >>=3D=3D22324=3D=3Dby 0x8125913: parse_reg_exp (regex.c:4420) >>=3D=3D22324=3D=3Dby 0x81261B3: Rf_regcomp (regex.c:4384) >>=3D=3D22324=3D=3D Address 0x1C1E23A8 is 0 bytes after a block of size 32 a= >>lloc'd >>=3D=3D22324=3D=3Dat 0x1B90650D: calloc (in /usr/lib/valgrind/vgpreload_= >>memcheck.so) >>=3D=3D22324=3D=3Dby 0x81247B5: parse_expression (regex.c:5406) >>=3D=3D22324=3D=3Dby 0x8125868: parse_branch (regex.c:4475) >>=3D=3D22324=3D=3Dby 0x8125913: parse_reg_exp (regex.c:4420) >>=3D=3D22324=3D=3D=20 >>=3D=3D22324=3D=3D Invalid write of size 4 >>=3D=3D22324=3D=3Dat 0x81255B2: parse_expression (regex.c:5045) >>=3D=3D22324=3D=3Dby 0x8125868: parse_branch (regex.c:4475) >>=3D=3D22324=3D=3Dby 0x8125913: parse_reg_exp (regex.c:4420) >>=3D=3D22324=3D=3Dby 0x81261B3: Rf_regcomp (regex.c:4384) >>=3D=3D22324=3D=3D Address 0x1C1E23A8 is 0 bytes after a block of size 32 a= >>lloc'd >>=3D=3D22324=3D=3Dat 0x1B90650D: calloc (in /usr/lib/valgrind/vgpreload_= >>memcheck.so) >>=3D=3D22324=3D=3Dby 0x81247B5: parse_expression (regex.c:5406) >>=3D=3D22324=3D=3Dby 0x8125868: parse_branch (regex.c:4475) >>=3D=3D22324=3D=3Dby 0x8125913: parse_reg_exp (regex.c:4420) >>=3D=3D22324=3D=3D=20 >>=3D=3D22324=3D=3D ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 39 f= >>rom 2) >>=3D=3D22324=3D=3D malloc/free: in use at exit: 12691882 bytes in 6426 block= >>s. >>=3D=3D22324=3D=3D malloc/free: 32534 allocs, 26108 frees, 33105500 bytes al= >>located. >>=3D=3D22324=3D=3D For a detailed leak analysis, rerun with: --leak-check= >>=3Dyes >>=3D=3D22324=3D=3D For counts of detected errors, rerun with: -v >>linux$ exit >> >>Script done on Mon 01 Aug 2005 02:10:42 PM PDT >>-- end of script -- >>--=20 >>Charles Geyer >>Professor, School of Statistics >>University of Minnesota >>[EMAIL PROTECTED] >> >>__ >>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] call fortran in R
Sébastien Durand wrote:
> Thanks for your help,
>
> I had read those web pages already, and the post you referred to
> already.
>
> So I will try to give more details to what I have done till now
>
> First I must mention again that I am using a mac under tiger. So I
> am using .so files.
>
> My fortran file is called kmeans.f, and my subroutine or wrapper I
> named it "wrapper"
>
> There is my first line of code
>
> subroutine wrapper(n, p, nran, mat, ishort, w, z, ntran, istand,
> k1, k2, iassign, iseed)
>
> In the terminal:
> R CMD SHLIB ~/Desktop/Fortan_kmeans/kmeans3.fg77
> -fno-common -g -O2 -c /Users/sebas/Desktop/Fortan_kmeans/
> kmeans3.f -o /Users/sebas/Desktop/Fortan_kmeans/kmeans3.o
> gcc-3.3 -bundle -flat_namespace -undefined suppress -L/usr/
> local/lib -o
> /Users/sebas/Desktop/Fortan_kmeans/kmeans3.so /Users/sebas/
> Desktop/Fortan_kmeans/kmeans3.o
> -L/usr/local/lib/gcc/powerpc-apple-darwin6.8/3.4.2 -lg2c -
> lSystem -framework R
>
> The files append to compile without any warnings.
>
> In R:
>
> > dyn.load("/Users/sebas/Desktop/Fortan_kmeans/kmeans3.so")
> > getLoadedDLLs()
>
> Filename
> base
> base
> grDevices /Library/Frameworks/R.framework/Resources/library/grDevices/
> libs/grDevices.so
> stats /Library/Frameworks/R.framework/Resources/library/
> stats/libs/stats.so
> methods /Library/Frameworks/R.framework/Resources/library/
> methods/libs/methods.so
> kmeans3 /Users/sebas/Desktop/
> Fortan_kmeans/kmeans3.so
>Dynamic.Lookup
> base FALSE
> grDevices FALSE
> stats FALSE
> methodsFALSE
> kmeans3 TRUE
>
>
> Dyn.load seems to work since if I type in getLoadedDLLs() I can see
> the link.
>
> > zozo=.Fortran(symbol.For("wrapper"),n=as.integer(n), p=as.integer
> (p), nran=as.integer(nran), mat=as.matrix(mat), ishort=as.vector
> (ishort), w=as.vector(w),ntran=as.integer(ntran), istand=as.integer
> (istand), k1=as.integer(k1), k2=as.integer(k2), iassign=as.integer
> (iassign), iseed=as.integer(iseed))
> Erreur dans .Fortran(symbol.For("wrapper"), n = as.integer(n), p =
> as.integer(p), :
> nom de fonction "Fortran" absent de la table d'allocation
>
> Even so I am using in the name parameter of the .Fortran function,
> "wrapper", "kmeans3", "wrapper_" or "kmeans3_"
>
> I always get the same error call telling me that the fonction
> "Fortran" is not in the allocation table
That message could be more useful, couldn't it?
I think your problem is using symbol.For(). .Fortran uses that (or some
internal equivalent), so it will end up being used twice, and R is
probably looking for wrapper__, when the real name is wrapper_.
Duncan Murdoch
>
> That is where I am at now, it has been 4 days I am digging into docs
> but I haven't been able to find what I am doing wrong.
>
> R is so great, I got tons of Fortran lines and subroutine to
> implement in R but I guess I am missing a little thing to make it
> work and now I really don't have a cue how to solve that problem.
>
> Cheers
>
> I will be anxiously waiting for any reply
>
> Sébastien
>
>
>
>>If I understand correctly, you used
>>.Fortran("wrapper",)
>>
>>The problem might be that the function name ("wrapper") was changed
>>in the
>>compilation of the code! See the mail bellow for clues (a previous
>>post on
>>R-help by Duncan Murdoch)
>>
>>Natalie Hawkins wrote:
>>
>>>Using R 2.0.1 on Windows XP, I am getting an error
>>>msg:
>>>
>>>Error in .Fortran("conic", nxy = nxy, npt = npt, CP =
>>>cp, EP1 = ep1, EP2 = ep2, :
>>>
>>>Fortran function name not in load table
>>>
>>>I am wondering if there is a way to see what function
>>>names are in the load table? Maybe the function name
>>>has been altered?
>>
>>You need to look at the DLL to see what name it is exporting. I
>>believe
>>R would be looking for "conic_". If your Fortran compiler doesn't
>>append underscores, you'll get this error.
>>
>>You might want to look at this page
>>
>>http://www.stats.uwo.ca/faculty/murdoch/software/compilingDLLs/
>>index.html#badname
>>
>>or this one
>>
>>http://www.stats.uwo.ca/faculty/murdoch/software/compilingDLLs/
>>fortran.html
>>
>>for more help.
>>
>>Duncan Murdoch
>
>
> [[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] call fortran in R
Sébastien Durand wrote:
> At the beginning I was not using symbol.For(), and whatever I add a
> "_" or not
>
> e.g.:
>
> .Fortran("wrapper",...
>
> I get the same error
You could look at symbol.For("wrapper"), and see if the name it prints
is exported from your .so. I don't know how to see the exports of a
.so, I use Windows.
Alternatively (and probably better overall), you could get your DLL to
register its exports with R. This is explained in the "Writing R
Extensions" manual. It should help to prevent any odd naming
conventions of your compiler from causing trouble, and you'll only have
to worry about odd parameter passing conventions (and how to create the
C language registration function).
Duncan Murdoch
>
> Sebastien
>
>
>
>
>>You want to just say:
>>
>>.Fortran("wrapper", ...
>>
>>not
>>
>>.Fortran(symbol.For("wrapper"), ...
>>
>>Patrick Burns
>>[EMAIL PROTECTED]
>>+44 (0)20 8525 0696
>>http://www.burns-stat.com
>>(home of S Poetry and "A Guide for the Unwilling S User")
>>
>>Sébastien Durand wrote:
>>
>>
>>
>>>Thanks for your help,
>>>
>>>I had read those web pages already, and the post you referred to
>>>already.
>>>
>>>So I will try to give more details to what I have done till now
>>>
>>>First I must mention again that I am using a mac under tiger. So
>>>I am using .so files.
>>>
>>>My fortran file is called kmeans.f, and my subroutine or wrapper
>>>I named it "wrapper"
>>>
>>>There is my first line of code
>>>
>>>subroutine wrapper(n, p, nran, mat, ishort, w, z, ntran,
>>>istand, k1, k2, iassign, iseed)
>>>
>>>In the terminal:
>>>R CMD SHLIB ~/Desktop/Fortan_kmeans/kmeans3.fg77
>>>-fno-common -g -O2 -c /Users/sebas/Desktop/Fortan_kmeans/
>>>kmeans3.f -o /Users/sebas/Desktop/Fortan_kmeans/kmeans3.o
>>>gcc-3.3 -bundle -flat_namespace -undefined suppress -L/
>>>usr/ local/lib -o
>>>/Users/sebas/Desktop/Fortan_kmeans/kmeans3.so /Users/
>>>sebas/ Desktop/Fortan_kmeans/kmeans3.o
>>>-L/usr/local/lib/gcc/powerpc-apple-darwin6.8/3.4.2 -lg2c -
>>>lSystem -framework R
>>>
>>>The files append to compile without any warnings.
>>>
>>>In R:
>>>
>>>
>>>>dyn.load("/Users/sebas/Desktop/Fortan_kmeans/kmeans3.so")
>>>>getLoadedDLLs()
>>>
>>>Filename
>>>base
>>> base
>>>grDevices /Library/Frameworks/R.framework/Resources/library/
>>>grDevices/ libs/grDevices.so
>>>stats /Library/Frameworks/R.framework/Resources/
>>>library/ stats/libs/stats.so
>>>methods /Library/Frameworks/R.framework/Resources/library/
>>>methods/libs/methods.so
>>>kmeans3 /Users/sebas/Desktop/
>>>Fortan_kmeans/kmeans3.so
>>> Dynamic.Lookup
>>>base FALSE
>>>grDevices FALSE
>>>stats FALSE
>>>methodsFALSE
>>>kmeans3 TRUE
>>>
>>>
>>>Dyn.load seems to work since if I type in getLoadedDLLs() I can
>>>see the link.
>>>
>>>
>>>>zozo=.Fortran(symbol.For("wrapper"),n=as.integer(n),
>>>
>>>p=as.integer (p), nran=as.integer(nran), mat=as.matrix(mat),
>>>ishort=as.vector (ishort), w=as.vector(w),ntran=as.integer(ntran),
>>>istand=as.integer (istand), k1=as.integer(k1), k2=as.integer(k2),
>>>iassign=as.integer (iassign), iseed=as.integer(iseed))
>>>Erreur dans .Fortran(symbol.For("wrapper"), n = as.integer(n), p
>>>= as.integer(p), :
>>>nom de fonction "Fortran" absent de la table d'allocation
>>>
>>>Even so I am using in the name parameter of the .Fortran
>>>function, "wrapper", "kmeans3", "wrapper_" or "kmeans3_"
>>>
>>>I always get the same error call telling me that the fonction
>>>"Fortran" is not in the allocation table
>>>
>>>That is where I am at now, it has been 4 days I am digging into
>>>docs but I haven't been able to find what I am doing wrong.
>>>
>>>R is so great, I got tons o
Re: [Rd] object.size() bug?
On 8/5/2005 8:39 AM, Roger D. Peng wrote:
> Would it make sense for 'object.size()' to do the same thing for
> external pointers as it does for environments?
I would think so. For those who haven't looked, this returns the size
of the SEXP for the environment and its attributes, but does not attempt
to work out the size of the contents of the environment. This makes
sense, because environments are references. External pointers are also
references, so their object size should be the size of the pointer
(which is probably 28 bytes; R pointers carry a lot of baggage!), with
no attempt to say anything about the external thing they point to.
Duncan Murdoch
> -roger
>
> Martin Maechler wrote:
>>>>>>>"Paul" == Paul Roebuck <[EMAIL PROTECTED]>
>>>>>>>on Thu, 4 Aug 2005 00:29:03 -0500 (CDT) writes:
>>
>>
>> Paul> Can someone confirm the following as a problem:
>>
>> Yes, I can. No promiss for a fix in the very near future
>> though.
>>
>> Martin Maechler, ETH Zurich
>>
>>
>>>>Can someone confirm the following as a problem:
>>>>
>>>>R> setClass("Foo", representation(.handle = "externalptr"))
>>>>R> object.size(new("Foo"))
>>>>Error in object.size(new("Foo")) : object.size: unknown type 22
>>>>R> R.version.string
>>>>[1] "R version 2.1.1, 2005-06-20"
>>>>
>>>>R-2.1.1/src/include/Rinternals.h
>>>>#define EXTPTRSXP 22/* external pointer */
>>>>
>>>>R-2.1.1/src/main/size.c:
>>>>objectsize(SEXP s) has no case for external pointers
>>
>>
>> __
>> 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 sh.exe file when running "R CMD INSTALL test" (PR#8068)
[EMAIL PROTECTED] wrote: > I am trying to learn how to make a simple package that contains no C > or Fortran code. I used package.skeleton(...) to make a package > called "test". The directory and files look good. I downloaded and > installed Rtools (www.murdoch-sutherland.com/Rtools/tools.zip). I > added the path and from the dos prompt I can verify that make.exe and > sh.exe both exist, but when I try to run "R CMD INSTALL test" I get an > error "make: sh.exe: Command not found" and "make: *** [pkg-test] > Error 127". I get the same error message if a try the command "make > pkg-test". You need to make sure the tools directory (wherever you put it) is on your path. Type PATH at a command prompt to see the current path; type PATH= blah blah blah to set a new one. See the R Admin manual for advice on what to put in it. Duncan Murdoch > > I saw in an old FAQ a suggestion to move sh.eve to the C:\bin\ folder, > but my C: root does not have a "bin" folder. Nonetheless, I created > one and put sh.exe there and it provided no help (I didn't expect it > too). > > Can anyone help me? > > > [[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] Questions about calls and formulas
Erich Neuwirth wrote:
>>Try do.call like this:
>>
>>ff <- x ~ g*h
>>do.call("substitute", list(ff, list(x = as.name("weight"
>>
>
>
> It is even more complicated.
> All I know is that ff is a formula with an expression on the left hand
> side. This expression needs to be replaced by "weights".
> According to the documentation, substitute only handles
> replacement of variables by something else,
> and that is not enough in my case.
That may make it simpler. For example:
> ff <- x ~ g*h
> ff[[2]]
x
> ff[[2]] <- as.name("weights")
> ff
weights ~ g * h
If you know that ff is a formula with an expression on the left that you
want to replace with "weights", then ff[[2]] <- as.name("weights")
will work. (ff[[1]] is the tilde, ff[[3]] is the RHS. You'll probably
want some sanity checks in your code to confirm this.)
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Functions with the same name: best practices
hadley wickham wrote: > Ok, here's another best practices question - let's say I'm writing a > package and I want to use a function name that is already claimed by a > function in the base R packages. For the sake of argument, let's > pretend this function is for profiling the performance of a function > (like Rprof for example), and so an obvious name that comes to mind is > profile. This, of course, clashes with the built in profile for > "investigating behavior of objective function near the solution > represented by fitted." > > A little thinking and a quick survey of other packages reveal some > possible solutions: > > * capitalise the function differently (eg. Profile) > * use a prefix/suffic (eg. Rprof) > * use a thesaurus > * use namespaces (and rely on others to use namespaces correctly in > their code/packages) > > What would you suggest? You should use a namespace. It will protect your code against someone else using one of your function names. If the function is for internal use only, that's sufficient. If you want to export the function, you should try to avoid conflicting with existing functions that you expect users to have installed, because it becomes quite inconvenient to users: their scripts depend on the load order of packages unless they put :: in front of each call. I think using a thesaurus would be best (if by that you mean choosing a different name that still describes the function), but will often fail, in which case I'd use the prefix/suffix decoration. Changing only capitalization makes it nearly impossible to talk about your function without confusion. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] TCITex and R
[EMAIL PROTECTED] wrote: > Several times my packages have fallen foul of the latex check at the > uploading-to-CRAN stage, creating extra work for Kurt Hornik. I've never > bothered trying to get latex working on my own packages (happy with > vanilla help) but am told that "latex is the closest thing to a syntax > checker for Rd files" and that I should set it up. Now, there is already > a latex on my (Windows XP) system thanks to the program Scientific Word, > which comes with TCITex. However, RCMD etc don't recognize this latex at > the moment. Does anyone have any advice on what might be needed to make > RCMD use SciWord's installation of TCITex-- paths, environment > variables, etc etc? I have no experience with TCITex, but what you need to do is make sure the commands that R needs are on your path. Those include "latex", "pdflatex", and possibly others I've forgotten: try building a binary copy of your package and you'll get errors if you haven't got them in place. You also need that TCITex follows the usual practice of using an environment variable to accept additional directories to search. MikTex doesn't, and it causes lots of trouble for people. This is the main reason I haven't recommended MikTex over fptex even though I use it; MikTex seems less stable about its interface. Duncan Murdoch > > Various R docs recommend fptex or MikTex implementations of latex, but > I'm a bit reluctant to put these on, primarily in case doing so somehow > stuffs up the workings of Scientific Word in a way that I don't know > enough to fix. In case it's not obvious already, I should add that I am > blissfully ignorant about how latex works-- that's one of my reasons for > using Scientific Word. > > Thanks for any advice > > Mark > > Mark Bravington > CSIRO Mathematical & Information Sciences > Marine Laboratory > Castray Esplanade > Hobart 7001 > TAS > > ph (+61) 3 6232 5118 > fax (+61) 3 6232 5012 > mob (+61) 438 315 623 > > __ > 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] doesn't recognise ~ (PR#8096)
On 8/25/2005 10:56 AM, [EMAIL PROTECTED] wrote: > Full_Name: Leo van Romunde > Version: 2, 1, 0 > OS: Win XP prof. sp1 > Submission from: (NULL) (81.58.34.90) > > > When we type the following R gives an error: > >> a = c(1, 2) >> b = c(1, 2) >> boxplot (a ~ b) > Error in list(a, b) : invalid 'envir' argument > > When we do exactly the same on another machine (Win2000) it works correctly. > Any suggestions? You probably have overwritten boxplot() or something with your own object. This works fine for me in 2.1.0 (but you should upgrade to 2.1.1 for other bug fixes). Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 64 bit R for Windows
Milton Lopez wrote: > I am assisting in the purchase of 64-bit Windows XP system for researchers > who run R. These systems will have AMD Opteron processors and at least 4GB of > RAM. I'd appreciate advice on whether there is a working version of R that > can take full advantage of such systems. No, there are no 64 bit Windows versions yet. You'll need to install some 64 bit version of Linux on those machines to take full advantage of the chips. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 64 bit R for Windows
Milton Lopez wrote: > Duncan: > > Thanks for your reply. Not being a part of the R world and having to assist > with these purchases, I have to ask what "not yet" means. I realize that this > is a difficult question to answer even for commercial software, but I am > hoping you or someone else on the list may shed some additional light on the > subject. I would say it will be at least a year, and most likely longer. The tools used to build R haven't been ported to 64 bit Windows yet. After those are done (by the MinGW project, not us), we'll need someone with a 64 bit Windows machine to handle builds there. Duncan Murdoch > Thanks in advance. > > Milton F. López > IT Guy > Inter-American Tuna Commission (IATTC) > 8604 La Jolla Shores Drive > La Jolla, CA 92037 > Tel: (858) 546-7041, Fax: (858) 546-7133 > [EMAIL PROTECTED] > http://www.iattc.org > > -Original Message- > From: Duncan Murdoch [mailto:[EMAIL PROTECTED] > Sent: Tuesday, August 30, 2005 5:39 PM > To: Milton Lopez > Cc: r-devel@r-project.org > Subject: Re: [Rd] 64 bit R for Windows > > Milton Lopez wrote: > >>I am assisting in the purchase of 64-bit Windows XP system for researchers >>who run R. These systems will have AMD Opteron processors and at least 4GB of >>RAM. I'd appreciate advice on whether there is a working version of R that >>can take full advantage of such systems. > > > No, there are no 64 bit Windows versions yet. You'll need to install > some 64 bit version of Linux on those machines to take full advantage of > the chips. > > Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RFC: "loop connections"
[EMAIL PROTECTED] wrote:
> Martin Maechler <[EMAIL PROTECTED]> wrote:
>
>
>>I think the main point of David's proposal is still worth
>>consideration: One way to see text connections is as a way to
>>treat some kind of R objects as "generalized files" i.e., connections.
>
>
> To summarize the motivation for the proposal, again:
>
> - There are two modes of connections: text and binary. The operations
> supported on text and binary connections are mostly disjoint. Most
> connection classes (socket, file, etc) support both modes.
>
> - textConnection() binds a character vector to a text connection.
> There is no equivalent for a binary connection. there are
> workarounds (i.e. anonymous connections, equivalent to temporary
> files), but these have substantial performance penalties.
>
> - Both connection modes have useful applications. textConnection() is
> useful, or it would not exist. Orthogonality is good, special cases
> are bad.
>
> - Only about 50 lines of code are required to implement a binary form
> of textConnection() in the R core. Implementing this functionality
> in a separate package requires substantially more code.
>
> - I need it, and in at least one case, another R package developer has
> implemented it using temporary files (caTools). I also just noticed
> that Duncon Murdoch recently proposed the EXACT SAME feature on
> r-help:
>
> https://stat.ethz.ch/pipermail/r-help/2005-April/067651.html
Since you quote me:
I would implement it differently from the way you did. I'd call it a
rawConnection, taking a raw variable (or converting something else using
as.raw) as the input, and providing both text and binary read/write
modes (using the same conventions for text mode as a file connection
would). It *should* support seek, at least in binary mode.
I would like an implementation that didn't necessarily duplicate the
whole raw vector into a buffer (it might be big, and people who deal
with big objects are always short of memory), but this isn't essential,
it would just be a nice feature.
Now, it would be nice to have something like this, but I'm not likely to
have time to do it in the near future. If you are interested in doing
this (and documenting it), I'd be willing to take a look at your code
and commit it when it looked okay.
The deadline for this to make it into 2.2.0 is that I'd want to commit
it by Sept 6, so there's not a lot of time left.
Duncan Murdoch
>
> I think that just about sums it up. I've attached a smaller patch
> that makes fewer changes to R source, doesn't change any existing
> function names, etc. The feature adds 400 bytes to the size of R.dll.
>
> -- Dave
>
>
>
> --- src/main/connections.c.orig 2005-06-17 19:05:02.0 -0700
> +++ src/main/connections.c2005-08-31 15:26:19.947195100 -0700
> @@ -1644,7 +1644,7 @@
> return ans;
> }
>
> -/* --- text connections - */
> +/* --- text and raw connections - */
>
> /* read a R character vector into a buffer */
> static void text_init(Rconnection con, SEXP text)
> @@ -1668,6 +1668,22 @@
> this->cur = this->save = 0;
> }
>
> +/* read a R raw vector into a buffer */
> +static void raw_init(Rconnection con, SEXP raw)
> +{
> +int nbytes = length(raw);
> +Rtextconn this = (Rtextconn)con->private;
> +
> +this->data = (char *) malloc(nbytes);
> +if(!this->data) {
> + free(this); free(con->description); free(con->class); free(con);
> + error(_("cannot allocate memory for raw connection"));
> +}
> +memcpy(this->data, RAW(raw), nbytes);
> +this->nchars = nbytes;
> +this->cur = this->save = 0;
> +}
> +
> static Rboolean text_open(Rconnection con)
> {
> con->save = -1000;
> @@ -1702,41 +1718,60 @@
>
> static double text_seek(Rconnection con, double where, int origin, int rw)
> {
> -if(where >= 0) error(_("seek is not relevant for text connection"));
> +if(where >= 0) error(_("seek is not relevant for this connection"));
> return 0; /* if just asking, always at the beginning */
> }
>
> -static Rconnection newtext(char *description, SEXP text)
> +static size_t raw_read(void *ptr, size_t size, size_t nitems,
> +Rconnection con)
> +{
> +Rtextconn this = (Rtextconn)con->private;
> +if (this->cur + size*nitems > this->nchars) {
> + nitems = (this->nchars - this->cur)/size;
> + memcpy(ptr, this->data+this->cur, size*nitems);
>
Re: [Rd] RFC: rawConnection (was "loop connections")
[EMAIL PROTECTED] wrote: > Duncan Murdoch <[EMAIL PROTECTED]> wrote: > > >>I would implement it differently from the way you did. I'd call it >>a rawConnection, taking a raw variable (or converting something else >>using as.raw) as the input, and providing both text and binary >>read/write modes (using the same conventions for text mode as a file >>connection would). It *should* support seek, at least in binary >>mode. > > > I was trying to reuse as much of the textConnection semantics and > underlying code as possible... > > Having a rawConnection() entry point is simple enough. Seeking also > seems straightforward. I'm not so sure about using as.raw(). I > wondered about that, but also thought that rather than coercing to > raw, it might make more sense to cast atomic vector types to raw, > byte-for-byte. I'd prefer as.raw, so that we don't end up with two incompatible ways to convert other objects to raw objects. > Can you given an example of where a text-mode raw connection would be > a useful thing? No, but someone else might. Why unnecessarily let the source of the bytes determine the mode of the connection? In the case of textConnection, there are natural line breaks, so a text mode connection makes sense. A raw object can contain anything, so why wouldn't someone want to put text in it some day? Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RFC: rawConnection (was "loop connections")
[EMAIL PROTECTED] wrote: > Duncan Murdoch <[EMAIL PROTECTED]> wrote: > >>>Having a rawConnection() entry point is simple enough. Seeking also >>>seems straightforward. I'm not so sure about using as.raw(). I >>>wondered about that, but also thought that rather than coercing to >>>raw, it might make more sense to cast atomic vector types to raw, >>>byte-for-byte. > > >>I'd prefer as.raw, so that we don't end up with two incompatible ways to >>convert other objects to raw objects. > > > An advantage of no as.raw() would be that you could create a raw > connection on an object without making an extra copy, which was > another of your requests. But there would be a lack of symmetry, > because you could "r" from an arbitrary R object, but only "w" to raw, > unless there was also a way of specifying a type for the result > vector. I think the cost of duplicating as.raw is worse than the cost of using extra memory. If the lack of symmetry bothers you, a solution is to require a raw object as input. > Having the backing store be an R object with no copy does seem tricky, > however. In that case I wouldn't bother. It's important to get it right; being maximally efficient is a second priority. > Currently, textConnection() makes a copy for "r" connections > but writes directly to an R object for "w" connections. The "w" case > is buggy; you can crash R by removing the target object while the > connection is being used. I'm not familiar enough with R internals to > know how to fix that. Maybe the object has to be searched for every > time the connection is used, to avoid potentially stale pointers? I've been having an argument with some other people about something related to this. I think they would say that the language doesn't support writing to a variable. I don't know the right way to fix this. > > >>>Can you given an example of where a text-mode raw connection would be >>>a useful thing? > > >>No, but someone else might. Why unnecessarily let the source of the >>bytes determine the mode of the connection? In the case of >>textConnection, there are natural line breaks, so a text mode connection >>makes sense. A raw object can contain anything, so why wouldn't someone >>want to put text in it some day? > > > It seems that that a text-mode raw connection would be equivalent to a > textConnection on the result of rawToChar(), no? If so, then a binary mode rawConnection (with mention of the way to convert in the Rd file) would be good enough for me. > > While some of these possibilities seem like they might be useful, I'm > not sure that all need to be implemented immediately. If we can agree > on the basic interface and semantics, then we could implement a basic > version now, and relax restrictions on the arguments later as needed? I'd rather get it right now, but that doesn't have to mean including every bell and whistle someone (even me!) has suggested. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RFC: rawConnection (was "loop connections")
[EMAIL PROTECTED] wrote: > Duncan Murdoch <[EMAIL PROTECTED]> wrote: > > >>I think the cost of duplicating as.raw is worse than the cost of using >>extra memory. If the lack of symmetry bothers you, a solution is to >>require a raw object as input. > > > It wouldn't exactly be duplicating as.raw since this way of converting > to raw is actually to do nothing at all, just to treat the object as > if it is already raw. But, I don't have a strong opinion. I haven't looked at as.raw, but I think it does something other than that. For example, rawToChar(as.raw(1:10)) gives "\001\002\003\004\005\006\a\b\t\n" I don't know if there's a way to do exactly what you're proposing. One argument against it is that the bytes for an object may vary from platform to platform (big versus little endian, maybe 32 vs 64 bit), whereas we try to make R code platform independent when we can. >> > Currently, textConnection() makes a copy for "r" connections >> >>>but writes directly to an R object for "w" connections. The "w" case >>>is buggy; you can crash R by removing the target object while the >>>connection is being used. I'm not familiar enough with R internals to >>>know how to fix that. Maybe the object has to be searched for every >>>time the connection is used, to avoid potentially stale pointers? > > >>I've been having an argument with some other people about something >>related to this. I think they would say that the language doesn't >>support writing to a variable. > > > I tried changing textConnection output connections to look up the > destination object on every access and that seems to solve the problem > without being terribly expensive. > > >>If so, then a binary mode rawConnection (with mention of the way to >>convert in the Rd file) would be good enough for me. > > > It seems we are coming back to something close to what I had > originally implemented? Probably! The differences I still know about are: - I'd like the name to reflect the data source, so rawConnection or something similar rather than overloading textConnection. - It needs a man page, or to be included on the textConnection man page. Duncan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 64 bit R for Windows
On 9/2/2005 11:59 AM, Milton Lopez wrote: > I appreciate the update. We will consider using Linux, which leads me to > one more question: what is the maximum RAM that R can use on each > platform (Linux and Windows)? On 32 bit Windows, I believe the limit is normally 2 G total for all user processes, but can be raised to 3 G with some work. (If you have a 4 G machine, the OS reserves 1 or 2 G for itself.) R can use as much memory as Windows will give it, but may not be able to make large allocations if memory is fragmented, or reserved by other processes. The limit under 64 bit Linux is much larger, but I don't know exactly what. Duncan Murdoch > > Thanks again for your prompt responses. > > > M. > > -Original Message- > From: Luke Tierney [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 31, 2005 6:04 PM > To: Duncan Murdoch > Cc: Milton Lopez; r-devel@r-project.org > Subject: Re: [Rd] 64 bit R for Windows > > On Wed, 31 Aug 2005, Duncan Murdoch wrote: > >> I would say it will be at least a year, and most likely longer. The >> tools used to build R haven't been ported to 64 bit Windows yet. > After >> those are done (by the MinGW project, not us), we'll need someone with > a >> 64 bit Windows machine to handle builds there. >> >> Duncan Murdoch > > An additional factor is that MinGW will almost certainly follow the MS > idea that long's are 4 bytes even under Win64, unlike what every other > 64-bit OS does. It will take a fair bit of time and someonw with the > motivation to do so to sort out the consequences (which may not be > very great but even establishing that may be non-trivial). > > luke > > > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] bash help please
I'd like to make MikTeX the default TeX package in 2.2.0, but we still
need to let people use other packages. The problem is that MikTeX wants
a command line option --include-directory $R_HOME/share/texmf, while
other packages specify includes via environment variables, and barf when
they see the unexpected option.
The choice should be controlled by the user's settings in the MkRules
file. For example, I'll put something like this there:
ifneq ($(strip $(BUILD)),CROSS)
# Define to use MikTeX
#
PDFLATEX = pdflatex --include-directory=$(RHOME)/share/texmf
LATEX = latex --include-directory=$(RHOME)/share/texmf
PDFTEX = pdftex --include-directory=$(RHOME)/share/texmf
TEX = tex --include-directory=$(RHOME)/share/texmf
#
# Define to use other TeX
#
# PDFLATEX = pdflatex
# LATEX = latex
# PDFTEX = pdftex
# TEX = tex
else
PDFLATEX = pdflatex
LATEX = latex
PDFTEX = pdftex
TEX = tex
endif
My problem is that I don't know enough about Bourne shell scripting and
GNU make to have this affect Rd2dvi (and possibly other Rcmd commands, I
haven't looked yet).
Specifically, we need to have Rd2dvi.sh import these definitions from
src/gnuwin32/MkRules, which may have been edited by the user since
Rd2dvi.sh was built. A complication is that if the user has already
defined environment variables named PDFLATEX, LATEX, etc, we don't want
to overwrite them.
One way would be to tell users to rebuild Rd2dvi.sh. However, it would
be easier if Rd2dvi.sh could import the changes automatically.
I was thinking of putting something like this into Rd2dvi.sh:
if test ${R_HOME}/src/gnuwin32/MkRules -nt ${R_HOME}/bin/setTeXenv.sh; then
make -f ${R_HOME}/src/gnuwin32/Makefile ${R_HOME}/bin/setTeXenv.sh
fi
sh setTeXenv.sh
and then have the Makefile build the setTeXenv.sh script--but what
should it contain? Alternatively, can GNU make export environtment
variables directly, and skip creating this new script?
Advice from shell hackers is welcomed!
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] bash help please
On 9/6/2005 10:56 AM, Duncan Murdoch wrote:
> I'd like to make MikTeX the default TeX package in 2.2.0, but we still
I forgot to say "in Windows". Sorry.
> need to let people use other packages. The problem is that MikTeX wants
> a command line option --include-directory $R_HOME/share/texmf, while
> other packages specify includes via environment variables, and barf when
> they see the unexpected option.
>
> The choice should be controlled by the user's settings in the MkRules
> file. For example, I'll put something like this there:
>
> ifneq ($(strip $(BUILD)),CROSS)
> # Define to use MikTeX
> #
> PDFLATEX = pdflatex --include-directory=$(RHOME)/share/texmf
> LATEX = latex --include-directory=$(RHOME)/share/texmf
> PDFTEX = pdftex --include-directory=$(RHOME)/share/texmf
> TEX = tex --include-directory=$(RHOME)/share/texmf
> #
> # Define to use other TeX
> #
> # PDFLATEX = pdflatex
> # LATEX = latex
> # PDFTEX = pdftex
> # TEX = tex
> else
> PDFLATEX = pdflatex
> LATEX = latex
> PDFTEX = pdftex
> TEX = tex
> endif
>
> My problem is that I don't know enough about Bourne shell scripting and
> GNU make to have this affect Rd2dvi (and possibly other Rcmd commands, I
> haven't looked yet).
>
> Specifically, we need to have Rd2dvi.sh import these definitions from
> src/gnuwin32/MkRules, which may have been edited by the user since
> Rd2dvi.sh was built. A complication is that if the user has already
> defined environment variables named PDFLATEX, LATEX, etc, we don't want
> to overwrite them.
>
> One way would be to tell users to rebuild Rd2dvi.sh. However, it would
> be easier if Rd2dvi.sh could import the changes automatically.
>
> I was thinking of putting something like this into Rd2dvi.sh:
>
> if test ${R_HOME}/src/gnuwin32/MkRules -nt ${R_HOME}/bin/setTeXenv.sh; then
>make -f ${R_HOME}/src/gnuwin32/Makefile ${R_HOME}/bin/setTeXenv.sh
> fi
> sh setTeXenv.sh
>
> and then have the Makefile build the setTeXenv.sh script--but what
> should it contain? Alternatively, can GNU make export environtment
> variables directly, and skip creating this new script?
>
> Advice from shell hackers is welcomed!
>
> Duncan Murdoch
>
> __
> 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] Install packages to non-default lib on Windows
Seth Falcon wrote: > We are trying to setup a Windows server that will allow any of our > users to build a binary R package given a source package. > > The idea is to have a central R installation and allow users to > install packages to their own package library for the purposes of > binary package building. > > It seems, however, that write access to $R_HOME is required as part of > the install step even when -l is used to specify an alternate package > library. > > here's an example of what we're seeing: > > C:\rlibdir\hpages>set R_LIBS=c:\rlibdir\hpages > > C:\rlibdir\hpages>d:\biocbld\R-devel\bin\R CMD INSTALL -l=%R_LIBS% --build > Biobase_1.6.7.tar.gz > > Using auto-selected zip options 'Biobase-ZIPDATA=zip Biobase-HELP=ziponly' > > -- Making package Biobase > adding build stamp to DESCRIPTION > installing NAMESPACE file and metadata > making DLL ... > ... DLL made > installing DLL > installing R files > save image > Loading required package: tools > Creating a new generic function for 'ncol' in 'Biobase' > > installing inst files > installing data files > installing man source files > installing indices > cannot create d:/biocbld/R-devel/doc/html/search/index.txt: permission denied > make[2]: *** [indices] Error 2 > make[1]: *** [all] Error 2 > make: *** [pkg-Biobase] Error 2 > *** Installation of Biobase failed *** > > Removing 'c:/rlibdir/hpages/Biobase' > > > Questions: > > - Is it possible to build a binary package on Windows without write > access to the $R_HOME tree? > > - Is it still the case that a side-effect of building a binary package > is having that package be installed? My understanding is that R CMD > INSTALL --build is the way to get zips on Windows, but maybe this > changed? There are two ways: R CMD INSTALL --build, and R CMD build --binary. The latter doesn't do an install, so the links in help pages don't get generated properly, but it may do a good enough job for what you need. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] Debugging R/Fortran in Windows
[Moved from R-help] James Wettenhall wrote: > Hi, > > I'm trying to debug an R interface to a Fortran subroutine from Windows. > (Yes, I know I should try Unix/Linux as well, but a quick attempt > suggested that the (MinGW g77) Fortran compiler I have installed on my > Windows laptop works better on this Fortran code.) > > I'm trying to follow the instructions in the "Writing R Extensions" Manual: > > Start R under the debugger after setting a breakpoint for WinMain. > gdb .../bin/Rgui.exe > (gdb) break WinMain > (gdb) run > > But when I run gdb on Rgui.exe, I get the message: > "no debugging symbols found" > and then when I try "break WinMain", I get: > "No symbol table is loaded. use the 'file' command." You can also start R normally, load your dll by attaching the package, then click on Misc | Break to debugger. This assumes you have debugging symbols in your DLL, and have gdb set up properly; see http://www.stats.uwo.ca/faculty/murdoch/software/debuggingR for more details. Duncan Murdoch > > I'm using R 2.1.1 on Windows 2000 and gdb 5.2.1 from MSys's MinGW. > > I'm calling a Fortran function (several times) from R. And I seem to have > the basic two-way data communication working - I appear to have > succesfully passed all required data types (integer, real, double > precision) to and from Fortran with sensible results both from within R > and from using WRITE(FILENUM,*) from within Fortran. But unfortunately > there is still evidence of memory leakage. > > Any suggestions would be greatly appreciated. > > Regards, > James > > __ > R-help@stat.math.ethz.ch mailing list > https://stat.ethz.ch/mailman/listinfo/r-help > PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] A question on R memory management in .Fortran() calls under Windows
On 9/9/2005 1:04 PM, Simone Giannerini wrote:
> Dear R community,
>
> I have a question on how R manages memory allocation in .Fortran()
> calls under Windows.
> In brief, apparently, it is not possible to allocate large matrices
> inside a Fortran subroutine
> unless you pass them as arguments. If you do not act in this way
> RGUI crashes with a stack overflow error and acting on memory through
> vsize nsize ppsize and memory.limit does not help at all.
It looks as though your Fortran compiler is allocating the new matrix on
the stack. R doesn't give you a huge stack, and that's causing the
overflow. When you get R to do the allocation, it does it on the heap,
which has no artificial limits. Only a pointer to the object ends up on
the stack.
I'd say your only reasonable workarounds are to tell your compiler to
use the heap for the local matrix allocation (if that's possible), or do
your allocations in R.
There might be some utility somewhere which can modify Rgui.exe to tell
it to start with a larger stack, and there is probably some linker
option to put one in place, but it's not really reasonable to increase
R's stack, because in almost all other situations, writing that much
data to the stack is a sign of an infinite recursion.
Duncan Murdoch
>
>
> Details of the configurations on which I performed testing follow:
> R 2.1.1 on WinXP Pro SP2 ITA
> PC1: AMD 64 3700+ 1GB RAM
> PC2: AMD AthlonXP 2400+ 512Mb RAM
> Compaq Visual Fortran pro 6.6C
>
>
> To give an idea I attach a brief example on how to reproduce this:
> Create two simple subroutines 'foo' and 'foobis' that, say, give the
> sum of the elements of a matrix:
>
> *** file foo.f90 starts
> ***
> SUBROUTINE foo(X,M,N,S)
> !DEC$ ATTRIBUTES DLLEXPORT,C,REFERENCE,ALIAS:'foo_' :: FOO
>
> IMPLICIT NONE
> integer:: M,N
> real*8:: X(M,N),S
>
> S = sum(X);
>
> END SUBROUTINE foo
>
> SUBROUTINE foobis(M,N,S)
> !DEC$ ATTRIBUTES DLLEXPORT,C,REFERENCE,ALIAS:'foobis_' :: FOOBIS
>
> IMPLICIT NONE
> integer:: M,N
> real*8:: X(M,N),S
> X = 1;
> S = sum(X);
>
> END SUBROUTINE foobis
>
> *** file foo.f90 ends
> ***
>
> Notice that the matrix X is an input argument in foo and an internal
> variable in foobis.
> After compiling and linking turn to R:
> **
>> dyn.load("foo.dll");
>> is.loaded(symbol.For("foo"));
> [1] TRUE
>> is.loaded(symbol.For("foobis"));
> [1] TRUE
>> M <- 10;
>> N <- 10;
>> X <- matrix(1,M,N);
>> .Fortran("foo",X,as.integer(M),as.integer(N),S=as.double(0))$S;
> [1] 100
>> .Fortran("foobis",as.integer(M),as.integer(N),S=as.double(0))$S;
> [1] 100
>
> ## no problem here with small matrices, let's increase the size
>
>> M <- 3000;
>> N <- 100;
>> X <- matrix(1,M,N);
>> .Fortran("foo",X,as.integer(M),as.integer(N),S=as.double(0))$S;
> [1] 3e+05 ## OK
>
>
> .Fortran("foobis",as.integer(M),as.integer(N),S=as.double(0))$S;
> ## *** R GUI CRASHES WITH A STACK OVERFLOW ERROR ***
>
> Any suggestion would be greatly appreciated, I apologize if this
> problem has already been addressed previously, I did not notice it.
> Many thanks in advance,
>
> Simone
> __
>
> Simone Giannerini
> Dipartimento di Scienze Statistiche "Paolo Fortunati"
> Universita' di Bologna
> Via delle belle arti 41 - 40126 Bologna, ITALY
> Tel: +39 051 2098248 Fax: +39 051 232153
> E-mail: [EMAIL PROTECTED]
>
> __
> 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] MikTeX will be assumed in R 2.2.0 in Windows
I've just committed some changes to allow R to be built and to use MikTeX without needing the Rd.sty files to be installed to localtexmf. Unfortunately, the changes are not compatible with other TeX packages, so if you're not using MikTeX you'll need to edit a couple of the config files (or set an environment variable). I'd appreciate hearing of any problems during the alpha or beta test period. A binary build containing the changes should be on CRAN tomorrow or the next day. Look for revision 35546 or higher. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] MikTeX will be assumed in R 2.2.0 in Windows
Gabor Grothendieck wrote: > Great. What specifically is the change? There are a number of changes to make use of the --include-directory command line option that Miktex supports. It needed to be done in several places because tex is called from makefiles, Perl and shell scripts. Duncan Murdoch > > On 9/9/05, Duncan Murdoch <[EMAIL PROTECTED]> wrote: > >>I've just committed some changes to allow R to be built and to use >>MikTeX without needing the Rd.sty files to be installed to localtexmf. >>Unfortunately, the changes are not compatible with other TeX packages, >>so if you're not using MikTeX you'll need to edit a couple of the config >>files (or set an environment variable). >> >>I'd appreciate hearing of any problems during the alpha or beta test period. >> >>A binary build containing the changes should be on CRAN tomorrow or the >>next day. Look for revision 35546 or higher. >> >>Duncan Murdoch >> >>__ >>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.version.string (Re: MikTeX will be assumed in R 2.2.0 in Windows)
Gabor Grothendieck wrote: > On 9/9/05, Duncan Murdoch <[EMAIL PROTECTED]> wrote: > >>I've just committed some changes to allow R to be built and to use >>MikTeX without needing the Rd.sty files to be installed to localtexmf. >>Unfortunately, the changes are not compatible with other TeX packages, >>so if you're not using MikTeX you'll need to edit a couple of the config >>files (or set an environment variable). >> >>I'd appreciate hearing of any problems during the alpha or beta test period. >> >>A binary build containing the changes should be on CRAN tomorrow or the >>next day. Look for revision 35546 or higher. > > > Note that R.version.string in R 2.2.0 2005-09-03 does not give > this sort of version information. If we are going to use this style > I suggest we modify R.version.string accordingly. You can get the revision number from the startup banner if you download a binary build. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] Debugging R/Fortran in Windows
James Wettenhall wrote: > Thanks very much to Uwe, Duncan and Seth (who replied off the list). > > Uwe - That section of the R for Windows FAQ was very useful - thanks! > Sorry I posted a question involving C/Fortran to R-Help. > > Duncan - Thanks for all the useful info. I've bookmarked the pages you > sent me. > > Seth - Thanks for suggesting valgrind. I tried it out, and it correctly > told me that memory leakage was not the problem (although I didn't believe > it at first). Is there a version of valgrind that works in Windows now, or did you do this test somewhere else? Duncan Murdoch > > It turned out that the reason my variables were being overwritten was not > because of memory leakage, but because of my own stupidity - using the > same variable name for a function I was estimating and for my current > estimate of that function. Sorry I didn't spend more time checking this > myself! > > Thanks again for your help, > James > > __ > 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.version.string (Re: MikTeX will be assumed in R 2.2.0 in Windows)
Gabor Grothendieck wrote: > On 9/10/05, Duncan Murdoch <[EMAIL PROTECTED]> wrote: > >>Gabor Grothendieck wrote: >> >>>On 9/9/05, Duncan Murdoch <[EMAIL PROTECTED]> wrote: >>> >>> >>>>I've just committed some changes to allow R to be built and to use >>>>MikTeX without needing the Rd.sty files to be installed to localtexmf. >>>>Unfortunately, the changes are not compatible with other TeX packages, >>>>so if you're not using MikTeX you'll need to edit a couple of the config >>>>files (or set an environment variable). >>>> >>>>I'd appreciate hearing of any problems during the alpha or beta test period. >>>> >>>>A binary build containing the changes should be on CRAN tomorrow or the >>>>next day. Look for revision 35546 or higher. >>> >>> >>>Note that R.version.string in R 2.2.0 2005-09-03 does not give >>>this sort of version information. If we are going to use this style >>>I suggest we modify R.version.string accordingly. >> >>You can get the revision number from the startup banner if you download >>a binary build. >> >>Duncan Murdoch >> >> > > > I normally document what version I am using by displaying R.version.string. > If R.version.string is no longer definitive under 2.2.0 then it either needs > to > be modified so that it is or we need some other way of getting that > capability. R.version$"svn rev" will give you the svn revision in 2.2.0 and up. Normally you won't need this; there is only one release of R per x.y.z version number. You only need to go to svn revision when you are looking at unreleased snapshot builds. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] A question on R memory management in .Fortran() calls under Windows
Simone Giannerini wrote: > Dear Duncan and Simon, > > many thanks for your helpful reply. > > >>Duncan Murdoch wrote: >>It looks as though your Fortran compiler is allocating the new matrix on >>the stack. R doesn't give you a huge stack, and that's causing the >>overflow. When you get R to do the allocation, it does it on the heap, >>which has no artificial limits. Only a pointer to the object ends up on >>the stack. > > > yes, CVF allocates automatic objects on the stack and apparently there > is no way of changing it. By the way, increasing the stack of the > fortran process when linking does not solve the problem > > >>I'd say your only reasonable workarounds are to tell your compiler to >>use the heap for the local matrix allocation (if that's possible), or do >>your allocations in R. > > > I might follow the second way, in any case, I am considering switching > to Linux, I have also considered changing compiler under Win, any > suggestions on the choice would be welcomed. I think it's far from the best optimizing compiler, but the Fortran that comes with MinGW (g77 currently in Windows) is the one used to build R, so it's the one that will is most likely to work with it without fiddling. But I don't use Fortran, so I don't know what else is available. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Copying libraries from one version of R to another (was Re: MikTeX will be assumed in R 2.2.0 in Windows)
On 9/9/2005 10:11 PM, Gabor Grothendieck wrote: > On 9/9/05, Duncan Murdoch <[EMAIL PROTECTED]> wrote: >> I've just committed some changes to allow R to be built and to use >> MikTeX without needing the Rd.sty files to be installed to localtexmf. >> Unfortunately, the changes are not compatible with other TeX packages, >> so if you're not using MikTeX you'll need to edit a couple of the config >> files (or set an environment variable). >> >> I'd appreciate hearing of any problems during the alpha or beta test period. >> >> A binary build containing the changes should be on CRAN tomorrow or the >> next day. Look for revision 35546 or higher. > > The above improvement was one of the key things one had to look out > for in installing R that was not already covered in the R setup procedure. > > The other one is to copy the libraries from your old R version to your > new one (unless you want to share libraries among versions). I have > a batch file in the devel version of batchfiles to do that but if this were > made part of the installation procedure I could eliminate it or if it > were included it would be much less necessary. I've just committed a change to the installer that partially addresses this. Now, when a user does an install, the installer records the version number and path in the registry. This way you can have multiple versions installed at once and there's a well-defined way to find them. (Well, there will be as soon as we've had time to release multiple versions that do this.) There's also a bit more help for non-admins to do installs. So an admin who installs just one copy of R will have something like this in their registry: [HKEY_LOCAL_MACHINE\SOFTWARE\R-core] [HKEY_LOCAL_MACHINE\SOFTWARE\R-core\R] "InstallPath"="F:\\R\\R-2.2.0alpha" "Current Version"="2.2.0 alpha" [HKEY_LOCAL_MACHINE\SOFTWARE\R-core\R\2.2.0 alpha] "InstallPath"="F:\\R\\R-2.2.0alpha" while a non-admin will get just this: [HKEY_CURRENT_USER\Software\R-core] [HKEY_CURRENT_USER\Software\R-core\R] [HKEY_CURRENT_USER\Software\R-core\R\2.2.0 alpha] "InstallPath"="C:\\Documents and Settings\\test\\My Documents\\R\\R-2.2.0alpha" If you want to see previously installed versions, you should search through HKEY_CURRENT_USER\Software\R-core\R and HKEY_LOCAL_MACHINE\SOFTWARE\R-core\R to see what's there. This went in to revision 35562 a few minutes ago; I'm not sure how long it will take to propagate to the alpha tarball and to the build on CRAN. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Copying libraries from one version of R to another (was Re: MikTeX will be assumed in R 2.2.0 in Windows)
On 9/13/2005 1:55 PM, Gabor Grothendieck wrote: > Thanks. That's great. If I understand correctly, versions that > are as of the one you just uploaded will have this facility and for older > versions I need to search in the old, existing, way. Thus once 2.3, say, > comes out we will have 2.2. and 2.3 in the registry. > > That means that as of 2.3 it will be possible to have an R program > that checks for the older versions via the registry and redownloads everything > from CRAN to the new version. Probably even sooner than that -- 2.2.1 will be recorded as a different version than 2.2.0. > It would be important that that > program is distributed with R and possibly invoked automatically > as part of the installation process since its best not to have > to install a package in order to install package. I assume you > will be doing that by that time so I can probably don't need to > provide anything in batchfiles. Maybe I > should just hold off on this area since it hardly seems worthwihle to do > development whose lifespan is just one version. It's probably not a good idea to assume that I'll do it :-). Putting together a simple package that does this would be nice, and would be available sooner than 2.3.0. Duncan Murdoch > By the way I did find a tool, sigcheck.exe, on sysinternals.com > that will find the file and product versions and running it on RGui.exe > it does work. I am considering whether to use that or not to > Rversions.hta. > > Regards. > > > On 9/13/05, Duncan Murdoch <[EMAIL PROTECTED]> wrote: >> On 9/9/2005 10:11 PM, Gabor Grothendieck wrote: >> > On 9/9/05, Duncan Murdoch <[EMAIL PROTECTED]> wrote: >> >> I've just committed some changes to allow R to be built and to use >> >> MikTeX without needing the Rd.sty files to be installed to localtexmf. >> >> Unfortunately, the changes are not compatible with other TeX packages, >> >> so if you're not using MikTeX you'll need to edit a couple of the config >> >> files (or set an environment variable). >> >> >> >> I'd appreciate hearing of any problems during the alpha or beta test >> >> period. >> >> >> >> A binary build containing the changes should be on CRAN tomorrow or the >> >> next day. Look for revision 35546 or higher. >> > >> > The above improvement was one of the key things one had to look out >> > for in installing R that was not already covered in the R setup procedure. >> > >> > The other one is to copy the libraries from your old R version to your >> > new one (unless you want to share libraries among versions). I have >> > a batch file in the devel version of batchfiles to do that but if this were >> > made part of the installation procedure I could eliminate it or if it >> > were included it would be much less necessary. >> >> I've just committed a change to the installer that partially addresses >> this. Now, when a user does an install, the installer records the >> version number and path in the registry. This way you can have multiple >> versions installed at once and there's a well-defined way to find them. >> (Well, there will be as soon as we've had time to release multiple >> versions that do this.) >> >> There's also a bit more help for non-admins to do >> installs. So an admin who installs just one copy of R will have >> something like this in their registry: >> >> [HKEY_LOCAL_MACHINE\SOFTWARE\R-core] >> >> [HKEY_LOCAL_MACHINE\SOFTWARE\R-core\R] >> "InstallPath"="F:\\R\\R-2.2.0alpha" >> "Current Version"="2.2.0 alpha" >> >> [HKEY_LOCAL_MACHINE\SOFTWARE\R-core\R\2.2.0 alpha] >> "InstallPath"="F:\\R\\R-2.2.0alpha" >> >> while a non-admin will get just this: >> >> [HKEY_CURRENT_USER\Software\R-core] >> >> [HKEY_CURRENT_USER\Software\R-core\R] >> >> [HKEY_CURRENT_USER\Software\R-core\R\2.2.0 alpha] >> "InstallPath"="C:\\Documents and Settings\\test\\My >> Documents\\R\\R-2.2.0alpha" >> >> If you want to see previously installed versions, you should search >> through HKEY_CURRENT_USER\Software\R-core\R and >> HKEY_LOCAL_MACHINE\SOFTWARE\R-core\R to see what's there. >> >> This went in to revision 35562 a few minutes ago; I'm not sure how long >> it will take to propagate to the alpha tarball and to the build on CRAN. >> >> Duncan Murdoch >> __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD check
jing hua zhao wrote: > Dear r-devel members, > > I tried to build R packages on a PC running Windows XP but experience > problems. However, it is ok when there is no inst directory in a package. > > Any help would be appreciated. > > The following is an example, > > C:\work>R CMD check VR_7.2-19.tar.gz > * checking for working latex ... OK > * using log directory 'C:/work/VR.Rcheck' > * using R version 2.1.1, 2005-06-20 > * checking for file 'VR/DESCRIPTION' ... OK > * looks like 'VR' is a package bundle > * this is bundle 'VR' version '7.2-19' > * checking if this is a source bundle ... OK > > installing R.css in C:/work/VR.Rcheck > > Looks like `C:/work/VR.Rcheck/00_pkg_src/VR' is a package bundle > > > -- Making package MASS > adding build stamp to DESCRIPTION > installing NAMESPACE file and metadata > making DLL ... > making MASS.d from MASS.c > making lqs.d from lqs.c > gcc -Ic:/PROGRA~1/r/rw2011/include -Wall -O2 -c MASS.c -o MASS.o > gcc -Ic:/PROGRA~1/r/rw2011/include -Wall -O2 -c lqs.c -o lqs.o > ar cr MASS.a MASS.o lqs.o > ranlib MASS.a > windres --include-dir c:/PROGRA~1/r/rw2011/include -i MASS_res.rc -o > MASS_res. > > gcc --shared -s -o MASS.dll MASS.def MASS.a MASS_res.o > -c:/PROGRA~1/r/rw201/src/gnuwin32 -lg2c -lR > ... DLL made > installing DLL > installing R files > installing inst files > FIND: Parameter format not correct Looks like a path problem. There's a find command in the R tools, and a completely different one in Windows. You need to set your path to find the R one first. Duncan Murdoch > make[2]: *** [C:/work/VR.Rcheck/MASS/inst] Error 2 > make[1]: *** [all] Error 2 > make: *** [pkg-MASS] Error 2 > *** Installation of MASS failed *** > > ERROR > Installation failed. > > C:\work> path > > PATH=C:\texmf\miktex\bin;C:\Perl\bin\;C:\Program > Files\Insightful\splus62\;C:\WI > NDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program > Files\Hummingbird\ > Connectivity\9.00\Accessories\;C:\Program Files\Common > Files\GTK\2.0\bin;C:\Prog > ram Files\WinSCP3\;C:\Program Files\PC-Pine > > > > Jing Hua Zhao > > __ > 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] Rd and guillemots
On 9/15/2005 7:51 PM, [EMAIL PROTECTED] wrote:
> First of all, thanks to those who've set up R to work so smoothly with
> Miktex-- even a total Latex bunny like me got it to work instantly, so
> that for the first time I'm able to run my Rd files through the Latex
> side of RCMD CHECK.
>
> Now the question/buglet. One of my Rd files contains the following:
>
> \code{mlazy( <>, <>, <>)}
>
> When I run the file through RCMD (either RCMD CHECK or Rcmd Rd2dvi
> --pdf) the first << and >> are left alone, but the second and third
> pairs are converted to single guillemot characters (i.e. European
> quotation marks). This inconsistency seems a bit odd.
Yes, this is the tex that gets output:
\code{mlazy( <{}{}>, <>, <>)}
This seems to happen in Rdconv.pm, around here:
## avoid conversion to guillemots
$c =~ s/<>/>\{\}>/;
But I don't know enough Perl syntax to tell it to replace all << by
<{}<, instead of just the first. (I would have guessed appending a g
would work, but didn't in a quick test, i.e. $c =~ s/<
> Also, is there any way of getting RCMD to leave << and >> alone-- i.e.
> not to guillemotize them? They cause unrecognized characters on my
> (Windows XP, newly-installed Miktex, R-alpha of 10/9/2005) system when I
> run the dvi files through dvips.
>
> Thanks
>
> Mark Bravington
> CSIRO Mathematical & Information Sciences
> Marine Laboratory
> Castray Esplanade
> Hobart 7001
> TAS
>
> ph (+61) 3 6232 5118
> fax (+61) 3 6232 5012
> mob (+61) 438 315 623
>
> __
> 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] Rd and guillemots
On 9/16/2005 4:16 PM, Prof Brian Ripley wrote:
> There are two instances of this. If I add 'go' to both it works for me.
> I guess you only had the first one (the second is used here).
Yes, that's it. Thanks!
Duncan Murdoch
>
> On Fri, 16 Sep 2005, Duncan Murdoch wrote:
>
>> On 9/15/2005 7:51 PM, [EMAIL PROTECTED] wrote:
>>> First of all, thanks to those who've set up R to work so smoothly with
>>> Miktex-- even a total Latex bunny like me got it to work instantly, so
>>> that for the first time I'm able to run my Rd files through the Latex
>>> side of RCMD CHECK.
>>>
>>> Now the question/buglet. One of my Rd files contains the following:
>>>
>>> \code{mlazy( <>, <>, <>)}
>>>
>>> When I run the file through RCMD (either RCMD CHECK or Rcmd Rd2dvi
>>> --pdf) the first << and >> are left alone, but the second and third
>>> pairs are converted to single guillemot characters (i.e. European
>>> quotation marks). This inconsistency seems a bit odd.
>>
>> Yes, this is the tex that gets output:
>>
>> \code{mlazy( <{}{}>, <>, <>)}
>>
>> This seems to happen in Rdconv.pm, around here:
>>
>> ## avoid conversion to guillemots
>> $c =~ s/<> $c =~ s/>>/>\{\}>/;
>>
>>
>> But I don't know enough Perl syntax to tell it to replace all << by
>> <{}<, instead of just the first. (I would have guessed appending a g
>> would work, but didn't in a quick test, i.e. $c =~ s/<> work.)
>>
>> Duncan Murdoch
>>
>>>
>>> Also, is there any way of getting RCMD to leave << and >> alone-- i.e.
>>> not to guillemotize them? They cause unrecognized characters on my
>>> (Windows XP, newly-installed Miktex, R-alpha of 10/9/2005) system when I
>>> run the dvi files through dvips.
>>>
>>> Thanks
>>>
>>> Mark Bravington
>>> CSIRO Mathematical & Information Sciences
>>> Marine Laboratory
>>> Castray Esplanade
>>> Hobart 7001
>>> TAS
>>>
>>> ph (+61) 3 6232 5118
>>> fax (+61) 3 6232 5012
>>> mob (+61) 438 315 623
>>>
>>> __
>>> 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] automatically adding smooth to plot: options("plot.add.smooth")
On 9/19/2005 8:18 AM, Martin Maechler wrote:
> I've changed the subject in the hope some more people would
> voice an opinion...
>
>>>>>> "MM" == Martin Maechler <[EMAIL PROTECTED]>
>>>>>> on Sat, 17 Sep 2005 17:29:20 +0200 writes:
>
>>>>>> "Wst" == Werner Stahel <[EMAIL PROTECTED]>
>>>>>> on Fri, 16 Sep 2005 09:37:02 +0200 writes:
>
>
> Wst>
> Wst>
> Wst>
>
> Wst> For most plots, I like to see a smoother along with the
> Wst> points. I suggest to add the option to include
> Wst> smoothers, not only as an argument to plot.lm, but even
> Wst> as an option(). I have heared of the intense
> Wst> discussions about options(). With Martin, we arrived
> Wst> at the conclusion that options() should never influence
> Wst> calculations and results, but is suitable to adjust
> Wst> outputs (numerical: digits=, graphical: smooth=) to the
> Wst> user's taste.
>
> MM> {and John Fox agreed, `in general'}
>
> MM> That could be a possibility, for 2.2.0 only applied to
> MM> plot.lm() in any case, where plot.lm() would get a new
> MM> argument
>
> MM> add.smooth = getOption("plot.add.smooth")
>
> MM> What do people think about the name? it would ``stick
> MM> with us'' -- so we better choose it well..
>
> No reaction so far
>
>
> I've realized that I can introduce this very easily into
> plot.lm():
>
> Instead of the former argument
>
>panel = points
>
> I use the new ones
>
>panel = if(add.smooth) panel.smooth else points,
>
> add.smooth = isTRUE(getOption("plot.add.smooth")),
>
> - - -
>
> Now I even propose to have
>
> options(add.smooth = TRUE)
>
> as a new default.
>
> Do I get a reaction now?
I like the name "add.smooth" (as used at the bottom) better than
"plot.add.smooth" (as used a few lines up).
With that choice, I think it's a good idea.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] automatically adding smooth to plot: options("plot.add.smooth")
On 9/19/2005 10:01 AM, Paul Gilbert wrote: > Martin Maechler wrote: > >> I've changed the subject in the hope some more people would >> voice an opinion... > > ... > >> Now I even propose to have >> >> options(add.smooth = TRUE) >> >> as a new default. >> >> Do I get a reaction now? >> Martin > > I think you may break a lot of things if you make this the default for > plot. Plot gets used by other things (like matplot) where this default > may not make much sense. (But I may have missed too much of the earlier > discussion under some other subject.) This was going to affect only plot.lm, as far as I know. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wishlist - access non-text from clipboard in Windows
On 9/22/2005 11:13 AM, Gabor Grothendieck wrote: > Just wanted to post this wishlist item. > > Currently one can read text from the Windows clipboard but the Windows > clipboard can hold all sorts of objects, not just text, and it can > hold them simultaneously. For example, if one selects some cells in > Excel and then copies them to the clipboard, the clipboard will have > all the cell boundary information but R can only read the text and > will have to figure it out if it can. > > It would be nice if the user could use R to access all the information on > the clipboard, not just the text. This looks like something someone should write a package to do. It needs lots of support (e.g. what do all the possible clipboard format constants mean, what binary format corresponds to each, etc.), but it would only be useful on the Windows platform. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wishlist - access non-text from clipboard in Windows
On 9/22/2005 1:12 PM, Gabor Grothendieck wrote: > There is an open source clipboard extender CLCL that handles all > clipboard formats. I think this code could be leveraged to simplify > it substantially. Run CLCL and copy something from IE or Excel, > say, so that you have a complex object in the clipboard. > Now expand Clipboard in the left pane and the various components > in the clipboard are shown in the tree as children. You can right click > and save any of them. > > If this code could be followed it might be simple to just have a new > argument to clipboard() which specified which component to return > or one could optionally return a list of all of them. We'd need to write clipboard() first. This might be a good idea, but it's not at the top of my priority list. I think a better thing for R to do is to make sure it's easy for package writers to write connections. Then a package writer could write clipboard(), and it would fit into the rest of the R machinery. Duncan Murdoch > > On 9/22/05, Duncan Murdoch <[EMAIL PROTECTED]> wrote: >> On 9/22/2005 11:13 AM, Gabor Grothendieck wrote: >> > Just wanted to post this wishlist item. >> > >> > Currently one can read text from the Windows clipboard but the Windows >> > clipboard can hold all sorts of objects, not just text, and it can >> > hold them simultaneously. For example, if one selects some cells in >> > Excel and then copies them to the clipboard, the clipboard will have >> > all the cell boundary information but R can only read the text and >> > will have to figure it out if it can. >> > >> > It would be nice if the user could use R to access all the information on >> > the clipboard, not just the text. >> >> This looks like something someone should write a package to do. It >> needs lots of support (e.g. what do all the possible clipboard format >> constants mean, what binary format corresponds to each, etc.), but it >> would only be useful on the Windows platform. >> >> Duncan Murdoch >> > > __ > 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] Wishlist - access non-text from clipboard in Windows
On 9/22/2005 2:50 PM, Gabor Grothendieck wrote: > On 9/22/05, Duncan Murdoch <[EMAIL PROTECTED]> wrote: >> On 9/22/2005 1:12 PM, Gabor Grothendieck wrote: >> > There is an open source clipboard extender CLCL that handles all >> > clipboard formats. I think this code could be leveraged to simplify >> > it substantially. Run CLCL and copy something from IE or Excel, >> > say, so that you have a complex object in the clipboard. >> > Now expand Clipboard in the left pane and the various components >> > in the clipboard are shown in the tree as children. You can right click >> > and save any of them. >> > >> > If this code could be followed it might be simple to just have a new >> > argument to clipboard() which specified which component to return >> > or one could optionally return a list of all of them. >> >> We'd need to write clipboard() first. This might be a good idea, but >> it's not at the top of my priority list. > > Sorry, its readClipboard() rather than clipboard(). See ?readClipboard I don't think I ever noticed that function. It looks tricky to determine how much data is there. For text it goes to the first NULL character, but what do you do for other formats? Can you see how the package you mentioned does it? Duncan Murdoch > >> >> I think a better thing for R to do is to make sure it's easy for package >> writers to write connections. Then a package writer could write >> clipboard(), and it would fit into the rest of the R machinery. >> >> Duncan Murdoch >> >> > >> > On 9/22/05, Duncan Murdoch <[EMAIL PROTECTED]> wrote: >> >> On 9/22/2005 11:13 AM, Gabor Grothendieck wrote: >> >> > Just wanted to post this wishlist item. >> >> > >> >> > Currently one can read text from the Windows clipboard but the Windows >> >> > clipboard can hold all sorts of objects, not just text, and it can >> >> > hold them simultaneously. For example, if one selects some cells in >> >> > Excel and then copies them to the clipboard, the clipboard will have >> >> > all the cell boundary information but R can only read the text and >> >> > will have to figure it out if it can. >> >> > >> >> > It would be nice if the user could use R to access all the information >> >> > on >> >> > the clipboard, not just the text. >> >> >> >> This looks like something someone should write a package to do. It >> >> needs lots of support (e.g. what do all the possible clipboard format >> >> constants mean, what binary format corresponds to each, etc.), but it >> >> would only be useful on the Windows platform. >> >> >> >> Duncan Murdoch >> >> >> > >> > __ >> > 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] [R] warning.expression?
I'm sending this reply to r-devel instead of r-help, since it has moved
into talking about changes to R internals now.
On 9/23/2005 7:36 AM, Barry Rowlingson wrote:
> Thomas Friedrichsmeier wrote:
>
>> Yes, thanks for pointing it out. However, I'm actually looking for a way to
>> catch all warnings in a whole (interactive) session. Can warning.expression
>> be used for that?
>
> I've just been nosing around the source code in errors.c, and it
> doesn't look good.
>
> In this function:
>
> static void vwarningcall_dflt(SEXP call, const char *format, va_list ap)
>
> the warning.expression 's' is called here:
>
> cptr = R_GlobalContext;
> while ( !(cptr->callflag & CTXT_FUNCTION) && cptr->callflag )
> cptr = cptr->nextcontext;
> eval(s, cptr->cloenv);
> return;
>
> but when the expression is null/nil the code goes on to the default
> case, in which it gets the warning message from the 'call' parameter:
>
>
> dcall = CHAR(STRING_ELT(deparse1(call, 0, SIMPLEDEPARSE), 0));
> REprintf(_("Warning in %s : "), dcall);
>
> So I don't see how this parameter can be available to the
> warning.expression call. There may be a way, but I don't see it.
>
> It seems a bit dumb that warning.expression functions can only say
> "Hey, something a bit iffy may have ocurred, but I dont know what and I
> dont know where!". Maybe there's something in that cptr->cloenv that can
> tell you...
>
> Otherwise it requires patching.
That's old code (mostly from 1999/2000), and that method of handling
warnings is not used in any of the base code, which may explain why it
isn't all that useful. I don't know of any GUIs that do what Thomas is
attempting (which I think is to have his GUI divert warnings and errors
from the output stream to some other display), so there might not
currently be a good way to do what he wants other than pattern matching
on the output.
It would probably be a good idea to deprecate warning.expression in the
next release, rather than beefing it up. If we don't have a good method
to do what Thomas wants, we should add it, but warning.expression
doesn't look like the right way to do it.
Does anyone know of any uses of it in current code on CRAN,
Bioconductor, or elsewhere?
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Assigning a zero length vector to a list (PR#8157)
On 9/26/2005 7:34 AM, [EMAIL PROTECTED] wrote: > Full_Name: Jussi Jousimo > Version: 2.2.0 beta > OS: Windows XP > Submission from: (NULL) (193.167.195.60) > > > I'm trying to assign a zero length vector to a list: > > x<-numeric() > length(x) > foo<-list() > foo$bar[[1]]<-x > length(foo$bar[[1]]) > foo > > But in the list this vector turns out to be length one with random content. > x<-character() makes R to crash. After foo<-list(), foo$bar is NULL, so we can simplify this. Here's a simpler version: # These work, which is a bit of a surprise, but there is some inconsistency: one x becomes a list, the other is numeric: > x <- NULL > x[[1]] <- 1:10 > x [[1]] [1] 1 2 3 4 5 6 7 8 9 10 > x <- NULL > x[[1]] <- 1 > x [1] 1 # This generates the same bug as the above: > x <- NULL > x[[1]] <- numeric(0) > x [1] 4.250083e-314 It looks like we're trying to be too clever with handling assignments to components of NULL. Wouldn't it make more sense for those to generate an error? Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Assigning a zero length vector to a list (PR#8157)
On 9/26/2005 10:29 AM, Peter Dalgaard wrote: > Duncan Murdoch <[EMAIL PROTECTED]> writes: > >> After foo<-list(), foo$bar is NULL, so we can simplify this. >> >> Here's a simpler version: >> >> # These work, which is a bit of a surprise, but there is some >> inconsistency: one x becomes a list, the other is numeric: >> > x <- NULL >> > x[[1]] <- 1:10 >> > x >> [[1]] >> [1] 1 2 3 4 5 6 7 8 9 10 >> >> > x <- NULL >> > x[[1]] <- 1 >> > x >> [1] 1 >> >> >> # This generates the same bug as the above: >> > x <- NULL >> > x[[1]] <- numeric(0) >> > x >> [1] 4.250083e-314 >> >> It looks like we're trying to be too clever with handling assignments to >> components of NULL. Wouldn't it make more sense for those to generate >> an error? > > Once upon a time, we had pairlists, and NULL was the empty list. This > looks like it might be a relic. If so, it likely also predates > consistent handling of zero-length vectors, so something is getting > confused. I think it would be reasonable to expect similar results to > this: > >> x<-list() >> x[[1]] <- numeric(0) >> x > [[1]] > numeric(0) I agree. I think I see where the problem is (a test "length(y) <= 1" in do_subassign2_dflt in subassign.c should be "length(y) == 1"; I'll try to fix it. Duncan Murdoch > > > > S-PLUS also tries to handle NULL as a zero length list, with some > anomalies: > >> x <- NULL >> x[[1]] <- numeric(0) >> x > $value: > numeric(0) > > >> x <- list() >> x[[1]] <- numeric(0) >> x > [[1]]: > numeric(0) > > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] constrOptim (PR#8158)
On 9/26/2005 6:19 PM, [EMAIL PROTECTED] wrote: > Full_Name: Haobo Ren > Version: 2.1.1 > OS: Windows 2000 > Submission from: (NULL) (192.11.226.116) > > > When running constrOptim, there is error message > > Error: subscript out of bounds > Please test this in the latest beta version, (available from http://cran.r-project.org/bin/windows/base/rdevel.html) and if you still see the problem, put together a reproducible example. (If you are unable to install the beta, please do post the example.) Make it as simple as you can, so you're sure it's not an error in your own code. If you need to use simulated data, call set.seed() first so we can reproduce the results. Thursday is code freeze; if you can post the relevant information enough before that there's a good chance this could be fixed before the next release. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Summary of translation status
On 9/28/2005 11:50 PM, Fernando Henrique Ferraz P. da Rosa wrote: > Dear R-devel & Translation Teams, > > In order to monitor the progress of the translation for the > pt_BR team I wrote a script to summarize the status of the translations. > It wasn't difficult to extend it to the other languages so I decided to > set up a page with the summaries of the translation for all languages > for which currently exist a translation. > > http://www.ime.usp.br/~feferraz/en/rtransstat.html > > If any of you find it useful I can keep it updated on a regular basis > (daily or weekly). > > > Thank you, > > > (PS: I'm resending this message because it didn't get through the > filter the first time. Sorry for the inconvenience for those that > are receiving it more than one time). Hi Fernando. That's a nice page. I'd add an explicit statement about which branch the statistics apply to. You say "Statistics based on SVN: 35706", presumably on the trunk, but soon interest will shift to the R-2-2-patches branch. (If this is automated and you have the disk space for both, perhaps both trunk and the current patch branch could be listed, but I expect the statistics will be very similar.) Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] by() processing on a dataframe
I want to calculate a statistic on a number of subgroups of a dataframe,
then put the results into a dataframe. (What SAS PROC MEANS does, I
think, though it's been years since I used it.)
This is possible using by(), but it seems cumbersome and fragile. Is
there a more straightforward way than this?
Here's a simple example showing my current strategy:
> dataset <- data.frame(gp1 = rep(1:2, c(4,4)), gp2 = rep(1:4,
c(2,2,2,2)), value = rnorm(8))
> dataset
gp1 gp2 value
1 1 1 0.9493232
2 1 1 -0.0474712
3 1 2 -0.6808021
4 1 2 1.9894999
5 2 3 2.0154786
6 2 3 0.4333056
7 2 4 -0.4746228
8 2 4 0.6017522
>
> handleonegroup <- function(subset) data.frame(gp1 = subset$gp1[1],
+ gp2 = subset$gp2[1], statistic = mean(subset$value))
>
> bylist <- by(dataset, list(dataset$gp1, dataset$gp2), handleonegroup)
>
> result <- do.call('rbind', bylist)
> result
gp1 gp2 statistic
11 1 0.45092598
11 1 2 0.65434890
12 2 3 1.22439210
13 2 4 0.06356469
tapply() is inappropriate because I don't have all possible combinations
of gp1 and gp2 values, only some of them:
> tapply(dataset$value, list(dataset$gp1, dataset$gp2), mean)
1 23 4
1 0.450926 0.6543489 NA NA
2 NANA 1.224392 0.06356469
In the real case, I only have a very sparse subset of all the
combinations, and tapply() and by() both die for lack of memory.
Any suggestions on how to do what I want, without using SAS?
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] by() processing on a dataframe
On 9/30/2005 1:41 PM, Peter Dalgaard wrote:
> Duncan Murdoch <[EMAIL PROTECTED]> writes:
>
>> I want to calculate a statistic on a number of subgroups of a dataframe,
>> then put the results into a dataframe. (What SAS PROC MEANS does, I
>> think, though it's been years since I used it.)
>>
>> This is possible using by(), but it seems cumbersome and fragile. Is
>> there a more straightforward way than this?
>>
>> Here's a simple example showing my current strategy:
>>
>> > dataset <- data.frame(gp1 = rep(1:2, c(4,4)), gp2 = rep(1:4,
>> c(2,2,2,2)), value = rnorm(8))
>> > dataset
>>gp1 gp2 value
>> 1 1 1 0.9493232
>> 2 1 1 -0.0474712
>> 3 1 2 -0.6808021
>> 4 1 2 1.9894999
>> 5 2 3 2.0154786
>> 6 2 3 0.4333056
>> 7 2 4 -0.4746228
>> 8 2 4 0.6017522
>> >
>> > handleonegroup <- function(subset) data.frame(gp1 = subset$gp1[1],
>> + gp2 = subset$gp2[1], statistic = mean(subset$value))
>> >
>> > bylist <- by(dataset, list(dataset$gp1, dataset$gp2), handleonegroup)
>> >
>> > result <- do.call('rbind', bylist)
>> > result
>> gp1 gp2 statistic
>> 11 1 0.45092598
>> 11 1 2 0.65434890
>> 12 2 3 1.22439210
>> 13 2 4 0.06356469
>>
>> tapply() is inappropriate because I don't have all possible combinations
>> of gp1 and gp2 values, only some of them:
>>
>> > tapply(dataset$value, list(dataset$gp1, dataset$gp2), mean)
>> 1 23 4
>> 1 0.450926 0.6543489 NA NA
>> 2 NANA 1.224392 0.06356469
>>
>>
>>
>> In the real case, I only have a very sparse subset of all the
>> combinations, and tapply() and by() both die for lack of memory.
>>
>> Any suggestions on how to do what I want, without using SAS?
>
> Have you tried aggregate()?
aggregate() has a few problems:
- it applies the function to every column in the dataframe. In my
case it only makes sense to apply it to some of them. (This may not be
a killer, but it certainly makes things inefficient and tricky.)
- I'd like to look at the whole subset to figure out the function (but
I can probably work around this)
- It uses too much memory. E.g. try
> df <- data.frame(x=rnorm(1000), y=rnorm(1000), z=rnorm(1000),
w=rnorm(1000))
> aggregate(df, list(df$x,df$y,df$z), mean)
Error: cannot allocate vector of size 3906250 Kb
In addition: Warning messages:
1: Reached total allocation of 1007Mb: see help(memory.size)
2: Reached total allocation of 1007Mb: see help(memory.size)
This should have returned the same dataframe (there are 1000 subsets),
but it tried to construct a billion of them.
On 9/30/2005 1:48 PM, Don MacQueen wrote:
> Look at the summarize() function in the Hmisc package.
It seems to want a matrix, not a data.frame. The real situation has
mixed types (character, factors, numeric) so it can't be a matrix.
> (and I this is an r-help question, not an r-devel question, I would
think)
Yes, that's where I should have posted. Sorry. However, this is
starting to look like a development problem...
Peter again:
> Alternatively, you migth split on interaction(, drop=TRUE)
Looking at the code, it appears that will construct the full product
interaction, then subset to the non-empty cases... Yes, it does that.
Looks like I'll have to write my own.
Duncan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] by() processing on a dataframe
On 9/30/2005 1:41 PM, hadley wickham wrote:
> I'm not entirely sure what you want, but maybe this does the trick?
>
> data.frame.by <- function(data, variables, fun, ...) {
> if (length(variables) == 0 ) {
> df <- data.frame(results = 0)
> df$results <- list(fun(data$value, ...))
> return(df)
> }
>
> sorted <- sort.df(data, variables)[,c(variables), drop=FALSE]
> duplicates <- duplicated(sorted[,variables, drop=FALSE])
> index <- cumsum(!duplicates)
>
> results <- by(data, index, fun, ...)
>
> cols <- sorted[!duplicates,variables, drop=FALSE]
> cols$results <- array(results)
> cols
> }
>
>
> sort.df <- function(data, vars) {
> data[do.call("order", data[,vars, drop=FALSE]), ,drop=FALSE]
> }
>
>
> dataset <- data.frame(gp1 = rep(1:2, c(4,4)), gp2 = rep(1:4,
> c(2,2,2,2)), value = rnorm(8))
>
> data.frame.by(dataset, c("gp1", "gp2"), function(data) mean(data$value))
> data.frame.by(dataset, "gp1", function(data) tapply(data$value, data$gp2,
> mean))
> data.frame.by(dataset, "gp1", function(data) lm(gp2 ~ value, data)) #
> doesn't print, but everything is there ok
>
> (note that the results column will be a list if necessary - this may
> be a serious abuse of data frames, but I'm not sure and no one replied
> when I queried the list)
I think this should work. Thanks!
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] access to R parse tree for Lisp-style macros?
On 10/3/2005 3:25 AM, Andrew Piskorski wrote: > R folks, I'm curious about possible support for Lisp-style macros in > R. I'm aware of the "defmacro" support for S-Plus and R discussed > here: > > http://www.biostat.wustl.edu/archives/html/s-news/2002-10/msg00064.html > > but that's really just a syntactic short-cut to the run-time use of > substitute() and eval(), which you could manually put into a function > yourself if you cared too. (AKA, not at all equivalent to Lisp > macros.) The mlocal() function in mvbutils also has seemingly similar > macro-using-eval properties: > > http://cran.r-project.org/src/contrib/Descriptions/mvbutils.html > http://www.maths.lth.se/help/R/.R/library/mvbutils/html/mlocal.html > > I could of course pre-process R source code, either using a custom > script or something like M5: > > http://www.soe.ucsc.edu/~brucem/samples.html > > http://groups.google.com/group/comp.compilers/browse_thread/thread/8ece2f34620f7957/000475ab31140327 > > But that's not what I'm asking about here. As I understand it, > Lisp-style macros manipulate the already-parsed syntax tree. This > seems very uncommon in non-Lisp languages and environments, but some - > like Python - do have such support. (I don't use Python, but I'm told > that its standard parser APIs are as powerful as Lisp macros, although > clunkier to use.) > > Is implementing Lisp-style macros feasible in R? Has anyone > investigated this or tried to do it? > > What internal representation does R use for its parse tree, and how > could I go about manipulating it in some fashion, either at package > build time or at run time, in order to support true Lisp-style macros? It is like a list of lists, with modes attached that say how they are to be interpreted. parse() gives a list of mode "expression", containing a list of function calls or atomic objects. Function calls are stored as a list whose head is the function name with subsequent entries being the arguments. The mode may be "expression", or "call", or others, depending on what you are actually dealing with. > > Whenever I try something like this in R: > > > dput(parse(text="1+2")) > expression(1 + 2) > > what I see looks exactly like R code - that '1 + 2' expression doesn't > look very "parsed" to me. Is that really it, or is there some sort of > Scheme-like parse tree hiding underneath? I see that the interactive > Read-Eval-Print loop basically calls R_Parse1() in "src/main/gram.c", > but from there I'm pretty much lost. There's a parse tree underneath. R is being helpful and deparsing it for you for display purposes. To see it as a list, use "as.list" to strip off the mode, e.g. > as.list(parse(text="1+2")) [[1]] 1 + 2 # A list containing one expression. Expand it: > as.list(parse(text="1+2")[[1]]) [[1]] `+` [[2]] [1] 1 [[3]] [1] 2 # A function call to `+` with two arguments. The arguments are atomic. Use "mode" to work out how these are interpreted: > mode(parse(text="1+2")) [1] "expression" > mode(parse(text="1+2")[[1]]) [1] "call" > > Also, what happens at package build time? I know that R CMD INSTALL > generates binary *.rdb and *.rdx files for my package, but what do > those do exactly, and how do they relate to the REPL and R_Parse1()? > > Finally, are there any docs describing the design and implementation > of the R internals? Should I be looking anywhere other than the R > developer page here?: The source code is sometimes the best place for low level details like this. The R Language manual sometimes gives low level details, but is is uneven in its coverage; I forget if it covers this. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Building packages on Windows fails
On Fri, 7 Oct 2005, Peter Kleiweg wrote: > > What has changed in R for Windows from version 1.7.1 to > 2.2.0 that won't allow me to build binary packages? Many things have changed; I don't know which is causing the failure you see. One change is that instructions are now collected in the Installation and Administration manual. Try following the setup instructions there and see if it still fails. Duncan Murdoch > > On 1.7.1 I built a packge with this command: > >Rcmd build --force --binary iL04 > > On 2.2.0 this fails. First I had to copy sh.exe from d:\bin to > c:\bin. This got me over the first hurdle. But then I got stuck > at a later point. Here are the last lines of output: > > -- Making package iL04 > latex: not found > adding build stamp to DESCRIPTION > latex: not found > latex: not found > latex: not found > installing R files > latex: not found > installing demos > installing data files > latex: not found > installing man source files > installing indices > cat: d:/R-2.2.0/library/*/CONTENTS: No such file or directory > make[2]: *** [indices] Error 1 > make[1]: *** [all] Error 2 > make: *** [pkg-iL04] Error 2 > *** Installation of iL04 failed *** > > -- > Peter Kleiweg > > __ > 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] Subscripting fails if name of element is "" (PR#8161)
I haven't been following this conversation in order, but I think there's
another bug here besides the one(s?) you identified:
Jens had this example:
> x <- 1:4
> names(x) <- c(NA, "NA", "a", "")
> x[names(x)]
a
113 NA
Shouldn't the second entry in the result be 2, with name "NA"? It seems
the string "NA" has been converted to here.
Duncan Murdoch
Prof Brian Ripley wrote:
> On Thu, 6 Oct 2005, "Jens Oehlschlägel" wrote:
>
>
>>Dear Thomas,
>>
>>
>>>This looks deliberate (there is a function NonNullStringMatch that does
>>>the matching). I assume this is because there is no other way to
>>>indicate that an element has no name.
>>
>>>If so, it is a documentation bug -- help(names) and FAQ 7.14 should
>>>specify this behaviour. Too late for 2.2.0, unfortunately.
>>
>>I respectfully disagree: the element has a name, its an empty string. Of
>>course "" is a doubtful name for an element, but as long as we allow this
>>name when assigning names()<- we also should handle it like a name in
>>subscripting. The alternative would be to disallow "" in names at all.
>>However, both alternatives rather look like code changes, not only
>>documentation.
>
>
> I think Thomas is right as to how S interprets this: "" is no name on
> assignment, wheread NA as a name is a different thing (there probably is a
> name, we just do not know what it is).
>
> Here is the crux of the example.
>
> p <- c(a=1, 2)
>
>>p <- c(a=1, 2)
>>names(p)
>
> [1] "a" ""
>
>>p
>
> a
> 1 2
>
>>p2 <- c(1,2)
>>names(p2) <- c("a", "")
>>identical(p, p2)
>
> [1] TRUE
>
> so giving the name is "" really is the same as giving no name.
>
> `Error 1' is said to be
>
>
>>p[""]
>
>
>NA
>
> You haven't given a name, so I think that is right. S (which has no
> character NAs) uses "" as the name, but here there may be a name or not.
>
>
>>P <- list(a=1, 2)
>
>
> I think Jens then meant as `error 2' that
>
>
>>P
>
> $a
> [1] 1
>
> [[2]]
> [1] 2
>
> shows no name for the second element, and that seems right to me (although
> S shows "" here).
>
> Finally (`error 3')
>
>
>>P[""]
>
> $"NA"
> NULL
>
> is a length-one list with name character-NA. (S has no name here.) That
> seems the right answer but if so is printed inconsistently.
>
> I would say that
>
>
>>Q <- list(1, 2)
>>names(Q) <- c("a", NA)
>>Q
>
> $a
> [1] 1
>
> $"NA"
> [1] 2
>
> was the only bug here (the name should be printed as ). Now that
> comes from this bit of code
>
> if( isValidName(CHAR(PRINTNAME(TAG(s )
> sprintf(ptag, "$%s", CHAR(PRINTNAME(TAG(s;
> else
> sprintf(ptag, "$\"%s\"", CHAR(PRINTNAME(TAG(s;
>
> so non-syntactic names are printed surrounded by "". Nowadays I think we
> would prefer ``, as in
>
>
>>A <- list("a+b"=1)
>>A
>
> $"a+b"
> [1] 1
>
>
>>A$"a+b"
>
> [1] 1
>
>>A$`a+b`
>
> [1] 1
>
> but NA needs to be a special case as in
>
>
>>A <- list(1, 2)
>>names(A) <- c("NA", NA)
>>A
>
> $"NA"
> [1] 1
>
> $"NA"
> [1] 2
>
>
>>is.na(names(A))
>
> [1] FALSE TRUE
>
>
>
>
>
>
> __
> 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] Building packages on Windows fails
Peter Kleiweg wrote: > Prof Brian Ripley schreef op de 7e dag van de wijnmaand van het jaar 2005: > > >>On Fri, 7 Oct 2005, Peter Kleiweg wrote: >> >> >>>Duncan Murdoch schreef op de 6e dag van de wijnmaand van het jaar 2005: >>> >>> >>>>On Fri, 7 Oct 2005, Peter Kleiweg wrote: >>>> >>>> >>>>>What has changed in R for Windows from version 1.7.1 to >>>>>2.2.0 that won't allow me to build binary packages? >>>> >>>>Many things have changed; I don't know which is causing >>>>the failure you see. One change is that instructions are >>>>now collected in the Installation and Administration >>>>manual. Try following the setup instructions there and see >>>>if it still fails. >>> >>>I can't find anything on building packages for Windows in >>>that manual. >> >>Your problems was installing, so the section on `Installing >>Packages' should help you. > > > Installing worked fine. Building a binary distribution (with > compiled help files) is what didn't work. > > This worked fine: > > Rcmd build iL04 > > But that just gave a gzip'ed tarfile, not a zip-file, and > without the compiled helpfiles. > > This didn't work: > > Rcmd build --force --binary iL04 > > > >>>I did find a solution to the problem. On a Linux install, >>>each package has a file CONTENTS. These are missing from the >>>Windows install. I copied those files from my Linux install >>>to my Windows install, and then I could build my own >>>package. So I guess, these CONTENTS files should be included >>>in the Windows install. >> >>And indeed they are, as the presence of 500+ packages on CRAN >>for Windows will show you. > > > Well, I just ran the install program for Windows, with compiled > html help, but without the ordinary html help files. In that > case, no CONTENTS files get installed. > > >>The recommended way to build a binary package on Windows is >> >>R CMD INSTALL --build > > > Yes, that works. Even without the CONTENTS files. And this is > recommended in the manual "Creating R packages", another manual > than Duncan Murdoch was referring to. > > I was using a method that was recommended in earlier versions. > Perhaps that method should just be disabled, with a > message about the current method, instead of having it fail for > obscure reasons. I agree there should be only one method, and it should work. The problem is: - Users with limited permissions can't run INSTALL, because it needs write access to R_HOME/library. - Because Windows doesn't have soft links, the only way we have to get cross references in the help files to work is to install to R_HOME/library. I'd prefer to fix "Rcmd build --binary" so that it got the help links right and then have "Rcmd INSTALL --build" use it first, then install the .zip file, but I haven't taken the time to do this. I don't like having two parallel tracks of very similar code (because of problems like yours, where the one I don't personnally use falls out of date and stops working). Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] svn version number
Gabor Grothendieck wrote: > Is there some way of automatically including the svn version number > of a package in the DESCRIPTION file or otherwise so that one > can check from within R which svn version number one has? You could do this by writing it into your Makefile, but there's no other existing support for it. I'd recommend combining the URL reported by "svn info" with the result of svnversion to get the most informative version. Watch out for cases of people who are trying to make your package from a tarfile, rather than an svn checkout. We have ended up with some fairly tricky Makefile programming to get what we want into the R banner. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] svn version number
Gabor Grothendieck wrote: > On 10/7/05, Duncan Murdoch <[EMAIL PROTECTED]> wrote: > >>Gabor Grothendieck wrote: >> >>>Is there some way of automatically including the svn version number >>>of a package in the DESCRIPTION file or otherwise so that one >>>can check from within R which svn version number one has? >> >>You could do this by writing it into your Makefile, but there's no other >>existing support for it. I'd recommend combining the URL reported by >>"svn info" with the result of svnversion to get the most informative >>version. Watch out for cases of people who are trying to make your >>package from a tarfile, rather than an svn checkout. We have ended up >>with some fairly tricky Makefile programming to get what we want into >>the R banner. > > > There is no makefile at all currently as my package is all R. Also, I > currently use TortoiseSVN. Probably the simplest option is to set an svn:keywords property on one of your source files, and get Subversion to put the revision number into the source when you check out. This won't tell you if you've got a mixed or modified revision, but as long as you are careful not to do this, it might give you what you want. I've got no idea how to do this in TortoiseSVN (I use command line svn), but presumably the documentation will talk about it. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] windows/g95 peculiarity
On Sat, 8 Oct 2005, Joel Bremson wrote:
> I'm not looking for an answer here, this is just a report of a
> peculiar event I've observed
> and can reproduce.
>
> I'm developing a g95 (20050129) compiled package on windows xp pro
> using R-2.1.1, and gcc-3.4.2 (mingw special). An older version of the
> F95 package compiled and ran without problems. The new version of the
> package includes extensive changes in the code.
>
> The package has a test function, rtest(), which sets up a testing
> scenario and runs it.
>
> If I try to immediately load the library after starting up R and
> running rtest(), the following
> occurs:
>
>> library("bpkg")
> .onLoad: running R_g95_init
>> o = rtest()
> Testing cm.estimate...
> Using short data set (testing)...
> 25500.00 2499.000 11.0 300.
> ...
> 5 0.000
> 6 0.000
> Operating system error: Not enough space
> Memory allocation failed
>
> (R exits in terminal, or freezes as GUI)
>
> However, if I import a data element the rtest runs fine. I know
> rtest() doesn't need the extra data import because it runs without
> problems on our OS X version.
I would guess your package (or something it is calling) is corrupting the
heap, or has another error in it. I'd suggest running under gdb and
identifying where the error message is coming from, and seeing at that
point what is causing it.
I have some instructions for debugging R packages in Windows on
http://www.stats.uwo.ca/faculty/murdoch/software/debuggingR/.
Duncan Murdoch
>
>> library("bpkg")
> .onLoad: running R_g95_init
>> data(yij)
>> o = rtest()
> Testing cm.estimate...
> Using short data set (testing)...
> 25500.00 2499.000 11.0 300.
> ...
> 6 0.000
> Done
>
>>
> (R continues to run without problems)
>
> The default rtest runs a short data set because the full test data set
> takes about
> 30 seconds to compute. When I start off by running the full rtest data
> set I also
> don't have any problems with R.
>
> This package runs without problems on a G4/Tiger OS X mac with R-2.1.1,
> although
> we do compile it with gfortran on that platform.
>
> This is just a report. If anyone has any questions let me know.
>
> Best,
>
> Joel
>
> --
> Joel Bremson
> Graduate Student
> Institute for Transportation Studies - UC Davis
> http://etrans.blogspot.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] error compiling R-code
[EMAIL PROTECTED] wrote: > Hi, > > I have been compiling R from source code with regularity (both R-patched > and R-devel) for several months now. About two/three weeks ago I noticed a > compilation error in R-devel (see below). I thought that the error will go > away in "due course" so I did not investigate it further. Then I left on > vacation. > > I just downloaded both versions of R sources (i.e., 2.2.0 patched and > 2.3.0). They both give me the same error, so my suspicion is that it is > just me having this problem. Here is what I get: > > ... > gcc -O2 -Wall -pedantic --std=gnu99 -DLEA_MALLOC -I../include > -DHAVE_CONFIG_H -DR_DLL_BUILD -c arithmetic.c -o arithmetic.o > arithmetic.c: In function `do_math1': > arithmetic.c:886: error: `expm1' undeclared (first use in this function) > arithmetic.c:886: error: (Each undeclared identifier is reported only once > arithmetic.c:886: error: for each function it appears in.) > make[4]: *** [arithmetic.o] Error 1 > make[3]: *** [rlibs] Error 2 > make[2]: *** [../../bin/R.dll] Error 2 > make[1]: *** [rbuild-no-mbcs] Error 2 > make[1]: Leaving directory `/home/andyj/R-devel/src/gnuwin32' > make: *** [distribution] Error 2 > > I apologize if this was already asked. I came back after about > week-an-a-half and I did not have time to go through hundreds of R > messages. Hopefully this is something simple for somebody who is familiar > with the code. > > I am on a Win2000 machine with all the necessary tools installed. I have > not changed my setup in at least 2 months and, as I said above, I was able > to compile R with no problems until about 2/3 weeks ago, so perhaps I > missed some subtle change in the tools. You may not have the latest versions of the MinGW tools. Check the Admin and installation manual, or http://www.murdoch-sutherland.com/Rtools/. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] GUI error. (PR#8204)
[EMAIL PROTECTED] wrote: > Full_Name: Ian G > Version: latest Please tell us which version. There are at least three versions which might be called "latest", and by tomorrow two of them may well be different. > OS: win xp pro sp1 > Submission from: (NULL) (193.1.209.251) > > > step one > start the r project any way you like > step two > type "demo()" and press return > step three > press then shortcut button to open file 'just under the file menu' > while then demp screen is up > the program seem not to like to open a new file when the window demo window is > active. > the error can be reproduce easly. Not reproducible for me in 2.2.0. Things worked just as I'd expect. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] SPSS I/O dll was: 8 char labels in read.spss
Knut Krueger wrote: > > Thomas Lumley schrieb: > > >>On Tue, 11 Oct 2005, Knut Krueger wrote: >> >> >> >>>I found a definition of the SPSS files. >>>http://www.wotsit.org/download.asp?f=spssdata >>>but they recommend to use the spss input/output dll to ensure upward >>>compatbility >>> >>> >>> >> >>"Well, they would say that, wouldn't they" (Rice-Davis 1963) >> >>Unfortunately, that document is an old file format. It doesn't describe >>record 7 subtype 13, which is where the long variable names live. >> > > What about using the SPSS input dll for those R users which would like to use > their old SPSS files. If you have that file, then presumably you have SPSS, and can ask it to output a documented file format. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Building R on Windows
Jennifer Lai wrote: > Prof Brian Ripley wrote: > > >>On Thu, 13 Oct 2005, Jennifer Lai wrote: >> >> >>>Prof Brian Ripley wrote: >>> >>> >>>>On Thu, 13 Oct 2005, Jennifer Lai wrote: >>>> >>>> >>>> >>>>>Hi, >>>>> I"m a newbie on building R on Windows. I followed the instructions >>>>>cited here, >>>>>http://www.murdoch-sutherland.com/Rtools/ to build R-2.2.0. >>>>>Everything works fine up till when package base needs to be compiled. >>>>>here is the error message, >>>>> >>>>>-- Making package base >>>>>adding build stamp to DESCRIPTION >>>>>Error in library.dynam(lib, package, package.lib) : >>>>> shared library 'tools' not found >>>>>Execution halted >>>>>make[4]: *** [frontmatter] Error 1 >>>>>make[3]: *** [all] Error 2 >>>>>make[2]: *** [pkg-base] Error 2 >>>>>make[1]: *** [rpackage] Error 2 >>>>>make: *** [all] Error 2 >>>>> >>>>>Has anyone seen this error message before? Where can I find shared >>>>>library tools? >>>>> >>>> >>>>It was built at the bootstrapping phase, or should have been. >>>> >>>> >>> >>>Is there something like config.log for Windows port? >> >> >>No. You will need to start again and show us what happens around the >>boot it says it is bootstrapping. >> >> >> >>>I didn't see anything suspcicious that helped me in finding where >>>shared library tools should be built. >>>There were couple of warning messges related to dlapack, but these >>>are not related to tools, right? >>> >>>In file included from dlapack0.f:0: >>>dlapack0.f:203: warning: 'ipv' might be used uninitialized in this >>>function >>>dlapack0.f:203: warning: 'jpv' might be used uninitialized in this >>>function >>>dlapack0.f:204: warning: 'smin' might be used uninitialized in this >>>function >> >> >>You will get many of those. >> >> > > I was able to build R for Windows successfully with a clean copy of > R-2.2.0, rather than using "make clean" to remove all object files. Generally to start over after important changes you'll need "make distclean". "make clean" is intended to be used at the end of a build, to remove unnecessary files, but to leave all the important parts in place. Since some of those parts are used in the build process (and in your case one of them was not built correctly), make clean wasn't enough. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R in Spanish?
Kenneth Cabrera wrote: > Hi R developers: > > I want to ask if there is a Spanish R installation, > if not, why not, and how can I help to > make the Spanish version, if you tell me how > I am willing to help with it. There isn't currently a Spanish translation. Instructions on how to do translations are on the web page <http://developer.r-project.org/Translations.html>. If you want to organize a Spanish translation team, I could list your name and contact information on <http://developer.r-project.org/TranslationTeams.html>. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R-gui] R GUI considerations
Gabor Grothendieck wrote: > I notice that there is some discussion on this at > http://developer.r-project.org/ under the links involving the > word threading. Thus using the facilities of another language > seems to be one approach and building such facilities into > R itself another. > > On 10/15/05, Philippe Grosjean <[EMAIL PROTECTED]> wrote: > >>Gabor Grothendieck wrote: >> >>>The preferred solutions in the post all seem to involve another language: >>> >>>- tcl to use tk >>>- Python to use wxWidgets >>> >>>and other solutions mentioned also seem to involve other languages: >>> >>>- Visual Basic >>>- Java (Swing?) >>> >>>Is there some key missing feature in R with regards to GUIs >>>that requires interposing another language? I think the Java/C++ style of object oriented programming is particularly well suited to writing GUIs. GUIs contain a lot of objects that need to maintain their state, and that need to respond to messages. The different kinds of objects have a lot in common with one another, and also some specific differences. You don't need an OOP language to write a GUI (the Windows Rgui is written in C, for example), but it makes things easier. You can write R in that style, but it's not the standard style to use, so it's not particularly easy. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] on ptr_R_WriteErrConsole
I'll volunteer to do your testing on Windows, provided nobody suggests a
way to do what you want without your patches. That is, if there's a way
for a custom front-end to separate the streams of text coming to
ptr_R_WriteConsole through REvprintf from that coming through Rvprintf,
then your changes are not needed. If there is currently no way to do
that, then I think there should be.
The justification for this change is to facilitate experimentation with
different front ends, as you describe below. That's something I think
we should support.
Forcing both streams through ptr_R_WriteConsole without giving
information about their origin is a decision about a particular kind of
user interface. Decisions like that should be made by the writer of the
front-end.
I agree with Luke and Brian that your second suggestion (which would
allow separation of text into regular output, warnings, and errors)
would tie us down too much in the internal details.
Duncan Murdoch
Thomas Friedrichsmeier wrote:
>>I second the point about not having made a case, and also that (from the
>>part deleted below) about needing to understand the internals before
>>proposing changes.
>
>
> I'll try to make the case below point d). I fully accept rejection of the
> more
> daring part of my proposal, but the part about ptr_R_WriteErrConsole is
> really straightforward, and I have really made sure to understand the
> internal going ons, here.
> My reply will be lengthy, because this really is important to me.
>
>
>>a) I took a quick look at the patch, and it seems to be only half the
>>story. R_WriteConsole is also supported under Windows, in a different
>>(and more flexible) way. I think the part not covered is a lot more
>>problematic, as I don't see how to introduce R_WriteErrConsole in a
>>backwards compatible way.
>
>
> I admit I've been neglectant to the Windows code. I don't have a windows
> machine to compile and test any changes I make in my local sources, and that
> lead me to be careless. so probably the patch is not correct.
> Do I believe there is still a backwards compatible way to introduce
> ptr_R_WriteErrConsole / R_WriteErrConsole?
>
> void R_WriteErrConsole(char *buf, int len) {ptr_R_WriteErrConsole(buf, len);}
> ...
> /* standard initialization: */
> ptr_R_WriteErrConsole = R_WriteConsole;
>
> *R_WriteConsole*. This ensures that if you do not touch the new
> ptr_R_WriteErrConsole, you get *exactly* the old behavior. I can't be much
> easier than that.
>
>
>>b) There are several inaccuracies in the account. First, `channels' are
>>not what we are talking about here. sink() allow output and messages to
>>be sent to different connections, but the console is connected to fixed
>>terminal connections stdout() and stderr(). There is a long-standing
>>design for R consoles (sketched in src/unix/system.txt) that has all the
>>output going to the console. This is even true of the standard Unix
>>terminal front end. The only circumstances in which stdout() and stderr()
>>are separated are when R is used for scripting. Part of the motivation
>>for this is to ensure that stdout() and stderr() appear in an integrated
>>way (in particular, interleaved in the correct order) on a console.
>
>
> Ok, so I have been simplifying, and using my own terminology. What I'm saying
> is, output generally goes two routes *throughout* R sources:
>
> "message":
> [warnings]->...->REprintf->REvprintf
> [errors]->...->REprintf->REvprintf
> REprintf->REvprintf
>
> "output":
> [print]->...->Rprintf->Rvprintf
> Rprintf->Rvprintf
>
> So it is not like I'm making up any new distinction, here. I'm referring to
> an
> existing one, avaible via already public API. See also this comment from
> printutils.c:
>
> /* =
> * Printing:
> * =
> *
> * All printing in R is done via the functions Rprintf and REprintf
> * or their (v) versions Rvprintf and REvprintf.
> * These routines work exactly like (v)printf(3). Rprintf writes to
> * ``standard output''.It is redirected by the sink() function,
> * and is suitable for ordinary output.REprintf writes to
> * ``standard error'' and is useful for error messages and warnings.
> * It is not redirected by sink().
>
> All I'm dealing with is, what should happen in REvprintf, the last station in
> what I call the "message route":
>
> Currently it is basically (and yes, I'm simplifying again):
> void REvprintf(const char *format, va_list arg)
> {
> /* A: if there is a s
Re: [Rd] Inconsistency with matrix indexing (PR#8214)
[EMAIL PROTECTED] wrote:
> Full_Name: Stefan Albrecht
> Version: 2.2.0
> OS: Windows XP
> Submission from: (NULL) (194.127.2.74)
>
>
> Dear all,
>
> in the new R 2.2.0, the matrix indexing has been changed.
I just tried your code in R 2.0.1 and 2.1.1, and got the same output as
you did. Which version are you comparing to?
Duncan Murdoch
In my opinion, this
> leads to an inconsistency when indexing one-row matrices.
> Take
>
>>(mat <- matrix(1:9, nrow = 3, dimnames = list(paste("r", 1:3, sep = ""),
>
> paste("c", 1:3, sep = ""
>c1 c2 c3
> r1 1 4 7
> r2 2 5 8
> r3 3 6 9
>
> Now taking the first row of the first-row of mat preserves the column names
>
>>mat[1, , drop = FALSE][1, ]
>
> c1 c2 c3
> 1 4 7
>
> This is not true for the first column of the first-row of mat
>
>>mat[1, , drop = FALSE][, 1]
>
> [1] 1
>
> However, for the first column of the first two rows of mat the row names are
> retained
>
>>mat[1:2, , drop = FALSE][, 1]
>
> r1 r2
> 1 2
>
> This feature can lead to problems when indexing matrixes of different row
> numbers, since the row names are not preserved in all cases.
>
> I suggest to preseve the row names also for
>
>>mat[1, , drop = FALSE][, 1]
>
>
> Would it be possible to implement this feature? Many thanks.
>
> With best regards,
>
> Stefan Albrecht
>
> __
> 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] on ptr_R_WriteErrConsole
On 10/18/2005 8:51 AM, Thomas Friedrichsmeier wrote: >> I'll volunteer to do your testing on Windows, provided nobody suggests a >> way to do what you want without your patches. That is, if there's a way >> for a custom front-end to separate the streams of text coming to >> ptr_R_WriteConsole through REvprintf from that coming through Rvprintf, >> then your changes are not needed. If there is currently no way to do >> that, then I think there should be. > > That would be great. Thank you. I have created a new version of the diff > (still against R 2.2.0). This only contains the R_WriteErrConsole part, and > the other part is stripped. Also, I have elaborated the windows version of > the handling. I hope I have not overlooked anything: > > http://rkward.sourceforge.net/temp/r_writeerrconsole.diff > > If in addition you would like me to create a test case, that would be > slightly > more difficult for me to do, but I'd be happy to give it a try. Just send me > a mail in this case. Probably, however, I would not be able to do this before > tomorrow. Thanks. I don't think I'll need a test case. I'll check that it compiles and doesn't change the behaviour, then see how easy it is to change the colour of error messages in the Windows GUI. Duncan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Antwort: Re: Inconsistency with matrix indexing (PR#8214)
On 10/18/2005 9:32 AM, [EMAIL PROTECTED] wrote:
> Dear Duncan,
>
> you are right. In both R 2.2.0 and 2.1.1 you get the same result. What has
> actually changed is the following:
> In R 2.1.1
>> mat[1, , drop = FALSE][1]
> r1
> 1
>
> While in R 2.2.0
>> mat[1, , drop = FALSE][1]
> [1] 1
I don't agree with your suggestion. mat[1, , drop = FALSE] is a 1x3
matrix, with both row and column names. Indexing it by [1] says that
you want to treat it as a vector, and give the first element. How could
R know whether to keep the row or column name for that [1,1] element?
What should it do with the expression
mat[1,1 , drop = FALSE][1]
?
If you are really concerned about the names, you should use matrix
indexing in both places with drop = FALSE:
> mat[1, , drop = FALSE][1,1,drop=FALSE]
c1
r1 1
Duncan Murdoch
>
> In both cases
>> mat[1, , drop = FALSE]
>c1 c2 c3
> r1 1 4 7
>
> I would strongly prefer to retain the row index r1 above.
> Of course, you could argue that mat[1, , drop = FALSE][1] relates to the
> column name c1. However, I think the lower dimension is a vector and this
> typically a column with row names. Most likely, a wiser and more concise
> interpretation than the mine is necessary, but the problem of dropping and
> loosing information is quite evident in any case.
>
> Still, I believe, my suggestion below is justified. Things like this
> happen quite often to me and it regularly takes time and effort to rectify
> the problem.
> Retaining the matrix features in sames could really be an advantage and
> avoid many if's and other workarounds.
>
> Many thanks and best regards,
> Stefan
>
>
>
> Duncan Murdoch <[EMAIL PROTECTED]>
> 2005-10-18 14:33
>
> An
> [EMAIL PROTECTED]
> Kopie
> r-devel@stat.math.ethz.ch, [EMAIL PROTECTED]
> Thema
> Re: [Rd] Inconsistency with matrix indexing (PR#8214)
>
>
>
>
>
>
> [EMAIL PROTECTED] wrote:
>> Full_Name: Stefan Albrecht
>> Version: 2.2.0
>> OS: Windows XP
>> Submission from: (NULL) (194.127.2.74)
>>
>>
>> Dear all,
>>
>> in the new R 2.2.0, the matrix indexing has been changed.
>
> I just tried your code in R 2.0.1 and 2.1.1, and got the same output as
> you did. Which version are you comparing to?
>
> Duncan Murdoch
>
>
> In my opinion, this
>> leads to an inconsistency when indexing one-row matrices.
>> Take
>>
>>>(mat <- matrix(1:9, nrow = 3, dimnames = list(paste("r", 1:3, sep = ""),
>>
>> paste("c", 1:3, sep = ""
>>c1 c2 c3
>> r1 1 4 7
>> r2 2 5 8
>> r3 3 6 9
>>
>> Now taking the first row of the first-row of mat preserves the column
> names
>>
>>>mat[1, , drop = FALSE][1, ]
>>
>> c1 c2 c3
>> 1 4 7
>>
>> This is not true for the first column of the first-row of mat
>>
>>>mat[1, , drop = FALSE][, 1]
>>
>> [1] 1
>>
>> However, for the first column of the first two rows of mat the row names
> are
>> retained
>>
>>>mat[1:2, , drop = FALSE][, 1]
>>
>> r1 r2
>> 1 2
>>
>> This feature can lead to problems when indexing matrixes of different
> row
>> numbers, since the row names are not preserved in all cases.
>>
>> I suggest to preseve the row names also for
>>
>>>mat[1, , drop = FALSE][, 1]
>>
>>
>> Would it be possible to implement this feature? Many thanks.
>>
>> With best regards,
>>
>> Stefan Albrecht
>>
>> __
>> 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-gui] R GUI considerations (was: R, Wine, and multi-threadedness)
On 10/20/2005 12:21 PM, Walter Johnston wrote: > And the question: > > Is there a "simple" way (e.g. some socket based mechanism) to > feed commands into R and retrieve the results of those commands? > This would require that I program the sequence of commands I > want to use (or a means to generate them) and then be able parse > the resulting structure - I understand. But it would also allow > separation of the computation, the "statistical reasoning", and > the UI into (potentially) separate units which would not even > need to be on the same machine to inter-operate. If there is a > reasonable way to do this, please tell me. Take a look at the Writing R Extensions manual. There are several levels at which you can interact with R. The simplest is to act as a console, feeding text in and getting text out. If you actually want to work with things as binary objects you'll need lower level access. It's not that bad if you just want to write a function that gets passed R objects. I don't think it be called "simple" if you want to do away with the console completely, and start working directly with the evaluator. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] md5sum for R-2.2.0-win32.exe ??
On 10/20/2005 3:44 PM, Charles C. Berry wrote: > I get > > c1279b77fcccf40379f59a83523a440e *R-2.2.0-win32.exe > > but I see > > e8bdf765fe8013129045314c8e2605fd *rw2011.exe > > on several USA mirrors. > > I hope the latter is merely in need of a replacement and not an > indication of a problem with the web sites. No, that was my error. It's fixed now, and my md5sum agrees with yours. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] image() with all NAs fails (PR#8228)
Prof Brian Ripley wrote:
> On Thu, 20 Oct 2005 [EMAIL PROTECTED] wrote:
>
>
>>On 10/20/2005 12:41 PM, [EMAIL PROTECTED] wrote:
>>
>>>Full_Name: Barry Rowlingson
>>>Version: 2.2.0
>>>OS: Linux
>>>Submission from: (NULL) (194.80.32.8)
>>>
>>>
>>>The image function with a matrix of all NA values fails with:
>>>
>>>
>>>>xyz=list(x=1:3,y=1:4,z=matrix(NA,3,4))
>>>>image(xyz)
>>>
>>>Error in image.default(xyz) : invalid z limits
>>>In addition: Warning messages:
>>>1: no finite arguments to min; returning Inf
>>>2: no finite arguments to max; returning -Inf
>>>
>>>Image can handle any number of NAs as long as there is at least one data
>>>value:
>>>
>>>
>>>>xyz=list(x=1:3,y=1:4,z=matrix(c(1,rep(NA,11)),3,4))
>>>>image(xyz)
>>>
>>> and shows NAs as transparent. However if it is all NAs then the z-limit
>>>calculation breaks down as above.
>>>
>>> It seems reasonable to me that image() with all NAs should produce a
>>>completely transparent/empty image (after displaying the axes if add!=TRUE)
>>>and
>>>not fail with an error.
>>
>>I agree, though I think the warnings are reasonable and a fix shouldn't
>>remove them. However, I'm not sure what the fix should be. There's a
>>test in image.default
>>
>>if (any(!is.finite(zlim)) || diff(zlim) < 0)
>>stop("invalid z limits")
>>
>>
>>that is throwing the error. We want the error if a user specifies
>>diff(zlim) < 0 or non-finite z limits, we just don't want it if all the
>>z's are NA. But a test all(is.na(z)) looks a bit expensive for such a
>>rare case.
>
>
> It is not actually documented that zlim can be omitted (something we need
> to fix too). Why not just add a check for zlim not being missing to that
> test?
Works fine, thanks for the suggestion. I'll commit if you haven't already.
Duncan Murdoch
Duncan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] md5sum for R-2.2.0-win32.exe ??
Peter Dalgaard wrote: > "Charles C. Berry" <[EMAIL PROTECTED]> writes: > > >>I get >> >> c1279b77fcccf40379f59a83523a440e *R-2.2.0-win32.exe >> >>but I see >> >> e8bdf765fe8013129045314c8e2605fd *rw2011.exe >> >>on several USA mirrors. >> >>I hope the latter is merely in need of a replacement and not an >>indication of a problem with the web sites. > > > Are you saying that you'd expect different versions of R to have the > same md5sum?... ;-) > > CRAN master has the old md5sum.txt as well, so I guess that the > Windows maintainer just forgot to update it. That was part of it. However, the md5sum.txt wasn't being built properly either. > Incidentally, I don't think it's all that smart to have the md5sum > in the same location as the binary. If one is tampered with, the other > one could be too. For the main release, I always send the md5sums via > the mailing lists. Well, the bad file was online for two weeks before anyone noticed, so I'm not sure everyone is being diligent in checking it. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] download problem: Windows binaries - patched/devel versions
P Ehlers wrote: > Lately, I get a "page cannot be found" error (IE 6.0, Windows XP) > when I try to download the following: > > http://cran.us.r-project.org/R-2.2.0pat-win32.exe > http://cran.us.r-project.org/R-2.3.0dev-win32.exe > > (Same for all other mirrors (about 6) that I've tried. > Could someone please check if these files are accessible to them? > I'm guessing there's something haywire in my setup. > > Note that I can ftp the files without problem. The files are where they have always been (in /bin/windows/base), but the mirroring software has started playing around with the URLs, adding in lots of ".."'s to the path. If you manually edit the path you'll find them. We're working on fixing the mirroring. To be explicit: get them from http://cran.us.r-project.org/bin/windows/base/R-2.2.0pat-win32.exe http://cran.us.r-project.org/bin/windows/base/R-2.3.0dev-win32.exe Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R patched for Windows missing
Peter Dalgaard wrote: > Gabor Grothendieck <[EMAIL PROTECTED]> writes: > > >>R patched for Windows seems to be missing. If one clicks on >>R-2.2.0pat-win32.exe at, say, >> >> http://stat.ethz.ch/CRAN/bin/windows/base/rpatched.html >> >>then an error occurs. I tried it at several mirror sites with the same >>result. The web page in question says: >> >>This directory contains a Windows binary build of R including patches >>up to 2005-10-24. > > > Looks like an HTML issue. Almost all links on that page go to files in > the server root, and likewise for r-devel. The .exe files themselves > seem to be quite happily sitting alongside the release binary at e.g. > > http://cran.r-project.org/bin/windows/base/R-2.2.0pat-win32.exe > > > The source for the link table in r-patched.html is currently looking like > this: See the thread on this with subject "Re: [Rd] download problem: Windows binaries - patched/devel versions". We know about it and are working on it. It's caused by the mirroring software being a little too helpful. Duncan Murdoch > > > > > HREF="../../../../../../../../../README.R-2.2.0pat">README.R-2.2.0pat > Installation and other instructions. > > > HREF="../../../../../../../../../CHANGES.R-2.2.0pat">CHANGES > > New features of this Windows version. > > > HREF="../../../../../../../../../NEWS.R-2.2.0pat">NEWS > New features of all versions. > > > > HREF="../../../../../../../../../R-2.2.0pat-win32.exe">R-2.2.0pat-win32.exe > Setup program (about 25 megabytes). Please download this > from a http://cran.r-project.org/mirrors.html";>mirror near > you. > This corresponds to the file named SetupR.exe or > rw.exe in pre-2.2.0 releases. > > > > > > < > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Critical Bug in type conversions: as.integer, trunc, ... (PR#8255)
On 10/27/2005 9:24 AM, [EMAIL PROTECTED] wrote: > Full_Name: Grischa Tödt > Version: 2.1.1 > OS: windows XP > Submission from: (NULL) (192.108.25.32) > > > I have a strange behaviour in R, looks like type conversions are messed up. This is not a bug, it's normal behaviour for floating point values, discussed in the FAQ item on "7.31 Why doesn't R think these numbers are equal?" Duncan Murdoch > > To reproduce: > > expected: >> typeof(3) > [1] "double" > >> as.integer(3) > [1] 3 > > strange: >> typeof((0.3/0.1)) > [1] "double" > >> as.integer((0.3/0.1)) > [1] 2 > > also for trunc: >>trunc(c(5,7)) >>c(0.5,0.7)/c(0.1,0.1) > > and now watch the amazing: >>trunc((c(0.5,0.7)/c(0.1,0.1))) > > > > > My R-Version: > platform i386-pc-mingw32 > arch i386 > os mingw32 > system i386, mingw32 > status > major2 > minor1.1 > year 2005 > month06 > day 20 > language R > > __ > 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] unvectorized option for outer()
On 10/31/2005 2:15 PM, Tony Plate wrote:
> When I read the preface to The Blue Book (The New S Language, Becker,
> Chambers & Wilks) I see comments along the lines of "high-level
> language", "primary goal of the S environment is to enable and encourage
> good data analysis", etc. While vectorization is a great feature of S
> (and R), I don't see it, or programming efficiency, mentioned there at all.
>
> Nonetheless, Peter's suggestion of a general Vectorize() function is
> intriguing, and could be useful with other functions that trip users up
> in the same way. (Also, I do apprecicate Peter pointing out that not
> all functions vectorize naturally, as in his example density
> calculations over grids of parameters).
>
> So, here's a first pass at a general Vectorize() function:
>
> Vectorize <- function(FUN, vectorize.args) {
> if (!all(is.element(vectorize.args, names(formals(FUN)
> stop("some args to vectorize are not args of FUN")
> FUNV <- eval(substitute(function(x, ...) mapply(FUN, x,
> MoreArgs=list(...)), list(FUN=FUN)))
> formals(FUNV) <- formals(FUNV)[c(rep(1, length(vectorize.args)), 2)]
> names(formals(FUNV))[seq(along=vectorize.args)] <- vectorize.args
> body(FUNV) <- body(FUNV)[c(1, 2, rep(3, length(vectorize.args)), 4)]
> body(FUNV)[seq(3,len=length(vectorize.args))] <-
> lapply(vectorize.args, as.name)
> FUNV
> }
I'd think the formals of the result should be identical to the formals
of the input.
Regarding the environment of the result: it is used to determine the
meaning of symbols that aren't defined within the function, e.g. things
like "eval", "substitute", etc. So I'd say that you don't want anything
special there, as long as you make sure that FUN is always evaluated in
its original environment.
Generally I don't like the look of that manipulation of the body of your
result; it looks pretty fragile to me. But I haven't worked out exactly
what you're doing, or whether it's possible to avoid it.
Duncan Murdoch
> ssd <- function(A,alpha,Y,t) sum((Y - A*exp(-alpha*t))2)
> # SSD is a vectorized version of ssd
> SSD <- function(Avec, alphavec, ...) mapply(ssd, Avec, alphavec,
> MoreArgs=list(...))
> # Vectorize(ssd, c("A", "alpha")) should produce
> # function(A, alpha, ...) mapply(ssd, A, alpha, MoreArgs=list(...))
> Y <- 1:5; t <- 3
> outer(1:3, 1:2, SSD, Y, t)
> outer(1:3, 1:2, Vectorize(ssd, c("A", "alpha")), Y, t)
>
> > # transcript of running the above commands
> > Vectorize(ssd, c("A", "alpha"))
> function (A, alpha, ...)
> mapply(function (A, alpha, Y, t)
> sum((Y - A * exp(-alpha * t))^2), A, alpha, MoreArgs = list(...))
>
> > Y <- 1:5; t <- 3
> > outer(1:3, 1:2, SSD, Y, t)
> [,1] [,2]
> [1,] 53.51878 54.92567
> [2,] 52.06235 54.85140
> [3,] 50.63071 54.77719
> > outer(1:3, 1:2, Vectorize(ssd, c("A", "alpha")), Y, t)
> [,1] [,2]
> [1,] 53.51878 54.92567
> [2,] 52.06235 54.85140
> [3,] 50.63071 54.77719
> >
>
> [There are a couple of minor design issues around syntax -- what is the
> best way of specifying the arguments to vectorize? (e.g., what about an
> interface that allowed Vectorize(ssd ~ A * alpha)?), and should the
> function name rather than the definition appear in the result of
> Vectorize()? But those are issues of secondary importance.]
>
> I have to confess I don't really understand how environments work with
> functions, so I don't know if this Vectorize() function will work in
> general. What is the appropriate environment for returned value of
> Vectorize()? Is this approach to creating a Vectorize() function on the
> right tack at all? Any other improvements or fixes?
>
> -- Tony Plate
>
>
> Peter Dalgaard wrote:
>> Thomas Lumley <[EMAIL PROTECTED]> writes:
>>
>>
>>>On Sun, 30 Oct 2005, Jonathan Rougier wrote:
>>>
>>>
>>>>I'm not sure about this. Perhaps I am a dinosaur, but my feeling is
>>>>that if people are writing functions in R that might be subject to
>>>>simple operations like outer products, then they ought to be writing
>>>>vectorised functions!
>>>
>>>I would agree. How about an oapply() function that does multiway (rather
>>>than just two-way) outer products. Basing the name on "apply" would
>>>emphasize the similarity to other flexible, not particularly optimized
>>>second-order functions.
>&g
