Re: [Rd] X11.options().
Hi Rolf,
please excuse a short "top-reply":
As I see you are using an operating system (instead of Win..),
can you try in the shell
echo 'X11.options()$type' | R --vanilla --slave
and does that really *not* report
[1] "cairo"
??
(and BTW: Your subject had tolower("LL") instead of "11" )
> Rolf Turner
> on Mon, 8 Aug 2011 12:49:44 +1200 writes:
> This question seemed to me to be more appropriate for
> r-devel than for r-help. My apologies if this is not the
> case.
> Recently I installed ``cairo'' on my lap-top so that I
> could make use of the (newish) polypath() function, with
> on-screen graphics. (The polypath() function does not
> work with X11(type="Xlib").)
> The installation went smoothly, X11(type="cairo") works
> just fine, and polypath() works just fine.
> However the default "type" for X11() remains "Xlib" rather
> than "cairo".
> The help for X11.options() says (in respect of "type"):
> Default "cairo" where available and reliable,
> otherwise "Xlib".
> Now "cairo" is definitely available:
>> capabilities()["cairo"]
> cairo TRUE
> and moreover it works (just fine!) when I do
> X11(type="cairo") explicitly.
> I know that I can set the default to be "cairo" in my
> .Rprofile, but I am curious as to why "cairo" does not
> become the default automatically.
> Is it the case that "cairo" is ``not reliable'' under my
> system? It ***seems*** to be reliable.
>> sessionInfo()
> R version 2.13.1 Patched (2011-07-17 r56404) Platform:
> i686-pc-linux-gnu (32-bit)
> locale: [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C [3]
> LC_TIME=en_US.UTF-8 LC_COLLATE=en_US.UTF-8 [5]
> LC_MONETARY=C LC_MESSAGES=en_US.UTF-8 [7]
> LC_PAPER=en_US.UTF-8 LC_NAME=C [9] LC_ADDRESS=C
> LC_TELEPHONE=C [11] LC_MEASUREMENT=en_US.UTF-8
> LC_IDENTIFICATION=C
> attached base packages: [1] datasets utils stats graphics
> grDevices methods base
> other attached packages: [1] misc_0.0-13 gtools_2.6.2
> spatstat_1.23-1 deldir_0.0-15 [5] mgcv_1.7-6
> fortunes_1.4-2 MASS_7.3-13
> loaded via a namespace (and not attached): [1] grid_2.13.1
> lattice_0.19-30 Matrix_0.999375-50 nlme_3.1-101
> cheers,
> Rolf Turner
> __
> 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] X11.options().
On 08/08/11 20:20, Martin Maechler wrote:
Hi Rolf,
please excuse a short "top-reply":
No problema. Thanks for replying.
As I see you are using an operating system (instead of Win..),
can you try in the shell
echo 'X11.options()$type' | R --vanilla --slave
and does that really *not* report
[1] "cairo"
Sure.
It really does *not* report "cairo"!!!:
~> echo 'X11.options()$type' | R --vanilla --slave
[1] "Xlib"
??
(and BTW: Your subject had tolower("LL") instead of "11" )
Whoops. Oh dear. Blame it on senility. :-(
cheers,
Rolf
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Overwriting imported function in another package
I am running into a limitation of the grid::grid.newpage function, for
which I would like to overwrite this function with a slightly modified
one. Hopefully this is a temporary working solution until the package
gets updated. I found a way to overwrite the function in the
package:grid namespace. However, lattice imports grid rather than
depending on it. So I need a way to overwrite this imported version as
well. The code below shows the fix which works for ggplot (because it
depends on grid), but it doesn't work for lattice, because it imports
grid. Is there any way to overwrite grid.newpage for all
instantiations of it?
#packages
library(grid);
library(lattice);
library(ggplot2);
#create the modified function.
hookfun <- deparse(body(plot.new))[1:6]
oldfun <- deparse(body(grid::grid.newpage))[-1];
newfun <- grid::grid.newpage;
body(newfun) <- parse(text=c(hookfun, oldfun));
#overwrite it in the package
unlockBinding("grid.newpage", as.environment("package:grid"))
assign("grid.newpage", newfun, pos="package:grid")
#this seems ok:
get('grid.newpage', as.environment("package:grid"));
get('grid.newpage', as.environment("package:lattice"));
#but this is still the old one
get('grid.newpage', environment(histogram));
#test if it worked:
setHook("before.plot.new", function() {message("Yay! A new plot.");});
qplot(rnorm(100)); #it worked for ggplot2
histogram(rnorm(100)); #didn't work for lattice
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Overwriting imported function in another package
On 08/08/2011 7:02 AM, Jeroen Ooms wrote:
I am running into a limitation of the grid::grid.newpage function, for
which I would like to overwrite this function with a slightly modified
one. Hopefully this is a temporary working solution until the package
gets updated. I found a way to overwrite the function in the
package:grid namespace. However, lattice imports grid rather than
depending on it. So I need a way to overwrite this imported version as
well. The code below shows the fix which works for ggplot (because it
depends on grid), but it doesn't work for lattice, because it imports
grid. Is there any way to overwrite grid.newpage for all
instantiations of it?
Yes, modify the source and recompile R.
Duncan Murdoch
#packages
library(grid);
library(lattice);
library(ggplot2);
#create the modified function.
hookfun<- deparse(body(plot.new))[1:6]
oldfun<- deparse(body(grid::grid.newpage))[-1];
newfun<- grid::grid.newpage;
body(newfun)<- parse(text=c(hookfun, oldfun));
#overwrite it in the package
unlockBinding("grid.newpage", as.environment("package:grid"))
assign("grid.newpage", newfun, pos="package:grid")
#this seems ok:
get('grid.newpage', as.environment("package:grid"));
get('grid.newpage', as.environment("package:lattice"));
#but this is still the old one
get('grid.newpage', environment(histogram));
#test if it worked:
setHook("before.plot.new", function() {message("Yay! A new plot.");});
qplot(rnorm(100)); #it worked for ggplot2
histogram(rnorm(100)); #didn't work for lattice
__
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] Overwriting imported function in another package
> Yes, modify the source and recompile R. That is what I am doing now, but can't expect that everyone who uses my code is willing to recompile R from src... __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Overwriting imported function in another package
On 08/08/2011 8:40 AM, Jeroen Ooms wrote: > Yes, modify the source and recompile R. That is what I am doing now, but can't expect that everyone who uses my code is willing to recompile R from src... But everyone who uses your code has a right to expect that other packages are not affected by it. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] OpenCL [Was: Tesla GPUs]
I have created a small package called OpenCL which allows the use of OpenCL kernels in R. It supports both single and double precision and arbitrary number of input arguments. The kernel in the ?oclRun example is very close to what I used for the testing below (obviously you won't be able to run fair single-precision tests, because R needs to convert both input and output vectors to/from double precision). Its home is at http://rforge.net/OpenCL and CRAN deo volente it may appear on CRAN soon. Cheers, Simon On Aug 5, 2011, at 2:36 PM, Simon Urbanek wrote: > > On Jul 19, 2011, at 12:56 PM, Simon Urbanek wrote: > >> >> On Jul 19, 2011, at 2:26 AM, Prof Brian Ripley wrote: >> >>> On Mon, 18 Jul 2011, Alireza Mahani wrote: >>> Simon, Thank you for elaborating on the limitations of R in handling float types. I think I'm pretty much there with you. As for the insufficiency of single-precision math (and hence limitations of GPU), my personal take so far has been that double-precision becomes crucial when some sort of error accumulation occurs. For example, in differential equations where boundary values are integrated to arrive at interior values, etc. On the other hand, in my personal line of work (Hierarchical Bayesian models for quantitative marketing), we have so much inherent uncertainty and noise at so many levels in the problem (and no significant error accumulation sources) that single vs double precision issue is often inconsequential for us. So I think it really depends on the field as well as the nature of the problem. >>> >>> The main reason to use only double precision in R was that on modern CPUs >>> double precision calculations are as fast as single-precision ones, and >>> with 64-bit CPUs they are a single access. So the extra precision comes >>> more-or-less for free. You also under-estimate the extent to which >>> stability of commonly used algorithms relies on double precision. (There >>> are stable single-precision versions, but they are no longer commonly used. >>> And as Simon said, in some cases stability is ensured by using extra >>> precision where available.) >>> >>> I disagree slightly with Simon on GPUs: I am told by local experts that the >>> double-precision on the latest GPUs (those from the last year or so) is >>> perfectly usable. See the performance claims on >>> http://en.wikipedia.org/wiki/Nvidia_Tesla of about 50% of the SP >>> performance in DP. >>> >> >> That would be good news. Unfortunately those seem to be still targeted at a >> specialized market and are not really graphics cards in traditional sense. >> Although this is sort of required for the purpose it removes the benefit of >> ubiquity. So, yes, I agree with you that it may be an interesting way >> forward, but I fear it's too much of a niche to be widely supported. I may >> want to ask our GPU specialists here to see if they have any around so I >> could re-visit our OpenCL R benchmarks. Last time we abandoned our OpenCL R >> plans exactly due to the lack of speed in double precision. >> > > A quick update - it turns out we have a few Tesla/Fermi machines here, so I > ran some very quick benchmarks on them. The test case was the same as for the > original OpenCL comparisons posted here a while ago when Apple introduced it: > dnorm on long vectors: > > 64M, single: > -- GPU -- total: 4894.1 ms, compute: 234.5 ms, compile: 4565.7 ms, real: > 328.3 ms > -- CPU -- total: 2290.8 ms > > 64M, double: > -- GPU -- total: 5448.4 ms, compute: 634.1 ms, compile: 4636.4 ms, real: > 812.0 ms > -- CPU -- total: 2415.8 ms > > 128M, single: > -- GPU -- total: 5843.7 ms, compute: 469.2 ms, compile: 5040.5 ms, real: > 803.1 ms > -- CPU -- total: 4568.9 ms > > 128M, double: > -- GPU -- total: 6042.8 ms, compute: 1093.9 ms, compile: 4583.3 ms, real: > 1459.5 ms > -- CPU -- total: 4946.8 ms > > The CPU times are based on a dual Xeon X5690 machine (12 cores @ 3.47GHz) > using OpenMP, but are very approximate, because there were two other jobs > running on machine -- still, it should be a good ballpark figure. The GPU > times are run on Tesla S2050 using OpenCL, addressed as one device so > presumably comparable to the performance of one Tesla M2050. > The figures to compare are GPU.real (which is computation + host memory I/O) > and CPU.total, because we can assume that we can compile the kernel in > advance, but you can't save on the memory transfer (unless you find a good > way to chain calls which is not realistic in R). > > So the good news is that the new GPUs fulfill their promise : double > precision is only twice as slow as single precision. Also they scale > approximately linearly - see the real time of 64M double is almost the same > as 128M single. They also outperform the CPUs as well, although not by an > order of magnitude. > > The double precision su
[Rd] Adressing Problems: R with Fortran and OpenMP
Hello,
I am programming an R program with nested Fortran calls for
calculations and OpenMP for parallelization. I am getting a changing
error corresponding to memory addressing problems, when using a 64-bit
system. Using a 32-bit System the application runs without problems.
The errors on 64-bit range from null-pointer failures, over
segmentation faults, over stack imbalances (changing differences and I
am not using C/C++) to finishing without exception but with wrong
values. Sometimes it even works correctly on 64-bit, mostly when
executing a second time within the same R session. Sometimes an
endless loop "Error: bad target context--should NEVER happen; please
bug.report() [R_run_onexits]" appears.
The problem seems to be platform independent. I have tried windows 7,
windows vista and open suse 11.3. (x86-64). Evaluation with valgrid
reveals a major possible memory leak, though the leak appears on
32-bit systems as well, just no errors. I am using a gfortran 4.5.0
x86-64 compiler and R version 2.12.
valgrid log extract:
==22989== 25,559,200 bytes in 4 blocks are possibly lost in loss
record 5,678 of 5,678
==22989==at 0x4C26C3A: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==22989==by 0x4F39907: Rf_allocVector (in /usr/lib64/R/lib/libR.so)
==22989==by 0x4EDAF96: duplicate1 (in /usr/lib64/R/lib/libR.so)
==22989==by 0x4FC204E: R_subassign3_dflt (in /usr/lib64/R/lib/libR.so)
==22989==by 0x4FC24A2: do_subassign3 (in /usr/lib64/R/lib/libR.so)
==22989==by 0x4F00B4A: Rf_eval (in /usr/lib64/R/lib/libR.so)
==22989==by 0x4F0346F: do_set (in /usr/lib64/R/lib/libR.so)
==22989==by 0x4F00B4A: Rf_eval (in /usr/lib64/R/lib/libR.so)
==22989==by 0x4F02EB1: applydefine (in /usr/lib64/R/lib/libR.so)
==22989==by 0x4F00B4A: Rf_eval (in /usr/lib64/R/lib/libR.so)
==22989==by 0x4F035EB: do_begin (in /usr/lib64/R/lib/libR.so)
==22989==by 0x4F00B4A: Rf_eval (in /usr/lib64/R/lib/libR.so)
==22989==
==22989== LEAK SUMMARY:
==22989==definitely lost: 82 bytes in 1 blocks
==22989==indirectly lost: 0 bytes in 0 blocks
==22989== possibly lost: 109,720,966 bytes in 26,330 blocks
==22989==still reachable: 23,101,045 bytes in 5,105 blocks
==22989== suppressed: 0 bytes in 0 blocks
All pointers in Fortran are explicitly defined with integer*4 and
real*8 as double.
I am really lost in this, because i just dont know where to start and
stop looking. It is obvious to me, that there is some kind of memory
adressing problem related to 64-bit architecture but since I dont know
if its related to R or Fortran or OpenMp or a combination of those, it
is very hard to find. Also the program is part of a library with 40+
files which interact, so I it would be really hard and time consuming
to cut the program down to a size, where the error will be reproduced
and still managable.
Any help, ideas, suggestions as to what to do, where to look and what
to try would be very welcome. I have been trying to solve this problem
for nearly two weeks and read everything I could find regarding
x86-64, R, Fortran, OpenMP and memory issues. I could post more and
more specific information regarding the errors, but then the
description would get even bigger. So if I need to supply more
information, please tell me and I will do so.
Regards
Lars
Following are the code snippets for the Fortran call and the entrance
to the Fortran program with OpenMp definition. If the program fails
with an statement about where it failed (i.e. segmentation fault),
then it gives this call as place. But since I only get R errors and
not Fortran errors, the error might actually occur anywhere in
Fortran.
z <- .Fortran("nlrdtirg",
as.integer(si),
as.integer(ngrad),
as.integer(ddim[1]),
as.integer(ddim[2]),
as.integer(ddim[3]),
as.logical(mask),
as.double(object@btb),
as.double(sdcoef),
th0=as.double(s0),
D=double(6*prod(ddim)),
as.integer(200),
as.double(1e-6),
res=double(ngrad*prod(ddim)),
rss=double(prod(ddim)),
double(ngrad*num_threads),
as.integer(num_threads),
PACKAGE="dti",DUP=TRUE)
subroutine nlrdtirg(s,nb,n1,n2,n3,mask,b,sdcoef,th0,D,niter,eps,
1res,rss,varinv,nt)
use omp_lib
implicit logical*4 (a-z)
integer*4 nb,n1,n2,n3,s(nb,n1,n2,n3),niter,nt,tid
logical mask(n1,n2,n3)
real*8 D(6,n1,n2,n3),b(6,nb),res(nb,n1,n2,n3),
1th0(n1,n2,n3),eps,rss(n1,n2,n3),sdcoef(4),varinv(nt*nb)
integer*4 i1,i2,i3,j
DO i3=1,n3
DO i2=1,n2
C$OMP PARALLEL DEFAULT(NONE)
C$OMP& SHARED(mask,s,b,sdcoef,th0,D,res,rss,varinv,nb,niter,eps)
C$OMP& FIRSTPRIVATE(i2,i3,n1)
C$OMP& PRIVATE(i1,j,tid)
C$OMP DO SCHEDULE(DYNAMIC,1)
___
Re: [Rd] X11.options().
On 08.08.2011 10:20, Martin Maechler wrote:
Hi Rolf,
please excuse a short "top-reply":
As I see you are using an operating system (instead of Win..),
can you try in the shell
echo 'X11.options()$type' | R --vanilla --slave
Martin,
given the R on my non-OS had X11.options, I'd rather written:
R --slave --vanilla -e "X11.options()$type"
Don't know why you have to type more on your OS.
Uwe
and does that really *not* report
[1] "cairo"
??
(and BTW: Your subject had tolower("LL") instead of "11" )
Rolf Turner
on Mon, 8 Aug 2011 12:49:44 +1200 writes:
> This question seemed to me to be more appropriate for
> r-devel than for r-help. My apologies if this is not the
> case.
> Recently I installed ``cairo'' on my lap-top so that I
> could make use of the (newish) polypath() function, with
> on-screen graphics. (The polypath() function does not
> work with X11(type="Xlib").)
> The installation went smoothly, X11(type="cairo") works
> just fine, and polypath() works just fine.
> However the default "type" for X11() remains "Xlib" rather
> than "cairo".
> The help for X11.options() says (in respect of "type"):
> Default "cairo" where available and reliable,
> otherwise "Xlib".
> Now "cairo" is definitely available:
>> capabilities()["cairo"]
> cairo TRUE
> and moreover it works (just fine!) when I do
> X11(type="cairo") explicitly.
> I know that I can set the default to be "cairo" in my
> .Rprofile, but I am curious as to why "cairo" does not
> become the default automatically.
> Is it the case that "cairo" is ``not reliable'' under my
> system? It ***seems*** to be reliable.
>> sessionInfo()
> R version 2.13.1 Patched (2011-07-17 r56404) Platform:
> i686-pc-linux-gnu (32-bit)
> locale: [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C [3]
> LC_TIME=en_US.UTF-8 LC_COLLATE=en_US.UTF-8 [5]
> LC_MONETARY=C LC_MESSAGES=en_US.UTF-8 [7]
> LC_PAPER=en_US.UTF-8 LC_NAME=C [9] LC_ADDRESS=C
> LC_TELEPHONE=C [11] LC_MEASUREMENT=en_US.UTF-8
> LC_IDENTIFICATION=C
> attached base packages: [1] datasets utils stats graphics
> grDevices methods base
> other attached packages: [1] misc_0.0-13 gtools_2.6.2
> spatstat_1.23-1 deldir_0.0-15 [5] mgcv_1.7-6
> fortunes_1.4-2 MASS_7.3-13
> loaded via a namespace (and not attached): [1] grid_2.13.1
> lattice_0.19-30 Matrix_0.999375-50 nlme_3.1-101
> cheers,
> Rolf Turner
> __
> 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
[Rd] Making rmath.dll (or equivalent)
I currently have R 2.12.1 installed, both 32 and 64 bit. I also have a file that was passed to me named rmath.dll. I do not know what version of R it was created from, but I do know it is 32-bit only. I am developing an application in C# that uses this library as a reference but I have to downgrade it to 32-bit in order to use the DLL file. I wish to make a rmath.dll from the version of R I have on my computer. I have looked for instructions online for this, but all I can find reference folders/files not in my install, I am guessing these instructions are for older versions of R. Can anyone point me to how I can accomplish this, creating a 64-bit DLL for R's math functonality? Thanks in advance. -- View this message in context: http://r.789695.n4.nabble.com/Making-rmath-dll-or-equivalent-tp3727906p3727906.html Sent from the R devel mailing list archive at Nabble.com. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] X11.options().
> Uwe Ligges > on Mon, 8 Aug 2011 21:38:06 +0200 writes: > On 08.08.2011 10:20, Martin Maechler wrote: >> Hi Rolf, >> >> please excuse a short "top-reply": >> >> As I see you are using an operating system (instead of >> Win..), can you try in the shell >> >> echo 'X11.options()$type' | R --vanilla --slave > Martin, > given the R on my non-OS had X11.options, I'd rather > written: > R --slave --vanilla -e "X11.options()$type" > Don't know why you have to type more on your OS. :-) touché, Uwe! Martin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] NAMESPACE imports
Is there some functionality for NAMSPACE files where I can import a package, except a couple of functions, something like importExcept The situation is that I import from two different packages, A and B . A (Biobase) is quite big and I essentially want to import all of the package. B (matrixStats) is very small and I also want to import the whole package, However, there is a name conflict (rowMedians and anyMissing exists in both packages) and I prefer to keep the version from the small package B. As I understand it, this means I need to change my current import(Biobase) import(matrixStats) to something like importFrom(Biobase, ***) import(matrixStats) where *** is a list of all functions in Biobase except rowMedians (and anyMissing), because right now R CMD check complains. Is there a better way? If not, I would like to put in a request for something like importFromExcept() Thanks, Kasper __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] X11.options().
Uh, to get back to the (my) point --- anybody have any ideas as to why X11.options()$type is defaulting to "Xlib" rather than "cairo" even though cairo is available and apparently (???) ``reliable''? cheers, Rolf __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Overwriting imported function in another package
[Jeroen Ooms wrote:]
> > I am running into a limitation of the grid::grid.newpage function, for
> > which I would like to overwrite this function
> > with a slightly modified one. Hopefully this is a temporary working
> > solution until the package gets updated. I found a
> > way to overwrite the function in the package:grid namespace. However,
> > lattice imports grid rather than depending on it.
> > So I need a way to overwrite this imported version as well. The code below
> > shows the fix which works for ggplot (because
> > it depends on grid), but it doesn't work for lattice, because it imports
> > grid. Is there any way to overwrite
> > grid.newpage for all instantiations of it?
[Duncan Murdoch wrote:]
> But everyone who uses your code has a right to expect that other
> packages are not affected by it.
One should of course only do such things reluctantly and responsibly, as Duncan
points out; any changes shouldn't modify *expectable* behaviour of existing
functions! But if it's just a bug-fix or innocuous extension of functionality,
and/or just in one's own work, then I can see two approaches that might help.
First is to set a load hook something like this (assuming 'newpage' isn't an S3
method, which would entail a tweak):
setHook( packageEvent( 'grid', 'onLoad'), function( ...) {
ns <- asNamespace( 'grid')
unlockBinding( 'grid.newpage', ns)
assign( 'grid.newpage', << patched version >>, envir=ns)
lockBinding( 'grid.newpage', ns)
cat( "Patched grid.newpage\n")
invisible( NULL)
})
This must be done before the offending package gets loaded, so it won't work eg
as an "autopatch" strategy if you want to put it into a package you're writing.
But it works fine if you put it in your own .First or other startup mechanism;
if you are just helping out some mates, give them this code & tell them how to
use it. I've used it for exactly the case mentioned: to "auto-patch" buggy code
pending a new release of a buggy package.
Second: *after* loading the offending package, (e.g. in the '.onLoad' of your
own package, if you're putting this into a package) you could use 'fun.locator'
in 'mvbutils' to find all instances of the offending function including
imports, and then change each copy manually. An example is 'mtrace' in 'debug',
which deliberately tries to find and change all copies of a function. (Whether
'fun.locator' finds absolutely every copy, I'm not sure, but it does try; NB it
won't work as-is for S4, and needs to be used differently for ref classes.)
This is uglier, but should be automatic (and should also ensure that any
subsequent imports of the offender pick up the patched version, though I
haven't checked).
Note that this won't work retrospectively for copies that are imported into a
package namespace under an alias, which I think used to be a theoretical
possibility but may not be any more.
HTH
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
--
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
Duncan Murdoch wrote:
> On 08/08/2011 8:40 AM, Jeroen Ooms wrote:
>>> Yes, modify the source and recompile R.
>>
>> That is what I am doing now, but can't expect that everyone who uses
>> my code is willing to recompile R from src...
>
> But everyone who uses your code has a right to expect that other
> packages are not affected by it.
>
> 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] Making rmath.dll (or equivalent)
It is Rmath.dll: case often matters in searching. You should look in the obvious manual in your (old) installation, the 'R Installation and Administration' manual. The current version is at http://cran.r-project.org/doc/manuals/R-admin.html#The-standalone-Rmath-library On Mon, 8 Aug 2011, sgomori wrote: I currently have R 2.12.1 installed, both 32 and 64 bit. I also have a file that was passed to me named rmath.dll. I do not know what version of R it was created from, but I do know it is 32-bit only. I am developing an application in C# that uses this library as a reference but I have to downgrade it to 32-bit in order to use the DLL file. I wish to make a rmath.dll from the version of R I have on my computer. I have looked for instructions online for this, but all I can find reference folders/files not in my install, I am guessing these instructions are for older versions of R. If you have a binary install, you cannot build R from it. Can anyone point me to how I can accomplish this, creating a 64-bit DLL for R's math functonality? Thanks in advance. -- View this message in context: http://r.789695.n4.nabble.com/Making-rmath-dll-or-equivalent-tp3727906p3727906.html Sent from the R devel mailing list archive at Nabble.com. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Brian D. Ripley, rip...@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Overwriting imported function in another package
> [Jeroen Ooms wrote:] >> > I am running into a limitation of the grid::grid.newpage function, for >> > which I would like to overwrite this function >> > with a slightly modified one. Hopefully this is a temporary working >> > solution until the package gets updated. I found a >> > way to overwrite the function in the package:grid namespace. However, >> > lattice imports grid rather than depending on it. >> > So I need a way to overwrite this imported version as well. The code below >> > shows the fix which works for ggplot (because >> > it depends on grid), but it doesn't work for lattice, because it imports >> > grid. Is there any way to overwrite >> > grid.newpage for all instantiations of it? > > [Duncan Murdoch wrote:] >> But everyone who uses your code has a right to expect that other >> packages are not affected by it. wrote: > One should of course only do such things reluctantly and responsibly, as > Duncan points out; any changes shouldn't modify *expectable* behaviour of > existing functions! But if it's just a bug-fix or innocuous extension of > functionality, and/or just in one's own work, then I can see two approaches > that might help. As a user, I would be strongly opposed to this, even for "buggy" code. > Second: *after* loading the offending package, (e.g. in the '.onLoad' of your > own package, if you're putting this into a package) you could use > 'fun.locator' in 'mvbutils' to find all instances of the offending function > including imports, and then change each copy manually. An example is 'mtrace' > in 'debug', which deliberately tries to find and change all copies of a > function. (Whether 'fun.locator' finds absolutely every copy, I'm not sure, > but it does try; NB it won't work as-is for S4, and needs to be used > differently for ref classes.) This is uglier, but should be automatic (and > should also ensure that any subsequent imports of the offender pick up the > patched version, though I haven't checked). > > Note that this won't work retrospectively for copies that are imported into a > package namespace under an alias, which I think used to be a theoretical > possibility but may not be any more. This strikes me as essentially as a package that, when installed/loaded "infects" other packages and software. R and CRAN are open source. If you need something different than what you have, make something different. You could make: JOsggplot2, JOslattice, etc. and have your package depend on those. User's do not need to compile from source, and rather than hijacking other packages, it is clear that a package similar to but different from ggplot2 and lattice is being used. Josh __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
