[Rd] X11 redraw events dropped? (PR#8250)
Full_Name: Keith Frost Version: 2.1.0 OS: Debian Sarge Submission from: (NULL) (66.162.141.10) This has actually been a problem for some time in R under Linux. (I noticed it under previous builds for Redhat 9 as well.) The graphics device windows produced by the x11() function do not always get redrawn when they should, sometimes leaving the device blank when there should be a graph on it. I do not know for sure that this is an R-specific problem (I suppose the window manager could be failing to pass along the correct redraw information), but I thought I'd try to find out if other people are experiencing it, and if it can be tracked down and fixed. To reproduce: Bring up a number of plots with the x11() function, and graph things on them. Move other windows to cover, and then reveal, the various plot windows, until -- one or more of your graphs disappears. Move the graphs over each other to get the graphs to come back. Etc. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] JRI and error message from R_isMethodsDispatchOn
Dear R users,
I have a small project written in Java and need some statical tools.
Therefore, I used JRI (in rJava package) as an interface between R and
Java to write some wrappers for my work. However, I received error
message from R while I have more than one java method which wraps R:
Error in .Call("R_isMethodsDispatchOn", onOff, PACKAGE = "base") :
Incorrect number of arguments (2), expecting 1 for R_isMethodsDispatchOn
The Java pseudo code would be like:
public class Test{
public static void main(String[] args){
...
objA.do;
objB.do;
...
}
}
Each do method actually calls R to do the job. I already know R is
single-treaded so I implemented end method in Rengine class to shutdown
R in each method. I thought this won't cause multi-thread problems in
this case because I terminate/destroy each R thread before I call
another one. But, it seems that it's still considered as 2 threads. Did
I miss something? or probably, I have to set-up JRI server for my
project? or other recommendations for my purpose?
R version: 2.11.1
rJava version: 0.8-4
OS: Arch Linux
Best,
Keith
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] JRI and error message from R_isMethodsDispatchOn
Hello Urbanek,
Simon Urbanek wrote:
Keith,
On Nov 19, 2010, at 7:40 PM, Keith wrote:
Dear R users,
I have a small project written in Java and need some statical tools. Therefore,
I used JRI (in rJava package) as an interface between R and Java to write some
wrappers for my work. However, I received error message from R while I have
more than one java method which wraps R:
Error in .Call("R_isMethodsDispatchOn", onOff, PACKAGE = "base") :
Incorrect number of arguments (2), expecting 1 for R_isMethodsDispatchOn
The Java pseudo code would be like:
public class Test{
public static void main(String[] args){
...
objA.do;
objB.do;
...
}
}
Each do method actually calls R to do the job. I already know R is
single-treaded so I implemented end method in Rengine class to shutdown R in
each method.
You cannot shutdown R short of closing the process and thus JVM, so that is not
an option. In fact NOT using end will likely solve your problem - simply used
one, shared instance of the REngine.
I thought this won't cause multi-thread problems in this case because I
terminate/destroy each R thread before I call another one. But, it seems that
it's still considered as 2 threads. Did I miss something? or probably, I have
to set-up JRI server for my project? or other recommendations for my purpose?
Simply use one instance of REngine continuously - that's the only approach
possible with JRI (note that the R access is synchronized so you can use the
instance from different threads). If you need multiple instances, you can use
Rserve - it uses the same REngine API but allows you to have arbitrarily many
parallel instances.
BTW: please use stats-rosuda-devel mailing list of questions related to rJava,
JRI or Rserve. It's also worth scanning the archives as those issues have been
raised before.
Cheers,
Simon
R version: 2.11.1
rJava version: 0.8-4
OS: Arch Linux
Best,
Keith
Thanks for the quick reply. It clears my confusion of using JRI. Now I
knew the stats-rosuda-devel mailing list, and I'll raise the related
questions/problems there next time.
Cheers,
Keith
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Ignoring .Rprofile when installing a package
Jon,
I have had a similar problem when installing librarys. I have written a
script which uses biocLite to install librarys.
I have included the following code which hides .Rprofile by renaming it
and then renaming it back again after it has finished.
#Hide .Rprofile whilst this script is running.
file.rename(paste(Sys.getenv("HOME"),".Rprofile",sep=.Platform$file.sep),paste(Sys.getenv("HOME"),".Rprofile_hiding",sep=.Platform$file.sep))
# ...
# ... install libraries code
# ...
#Put .Rprofile back
file.rename(paste(Sys.getenv("HOME"),".Rprofile_hiding",sep=.Platform$file.sep),paste(Sys.getenv("HOME"),".Rprofile",sep=.Platform$file.sep))
I think this should be platform independent, but have mainly tried it on
Windows and Unix.
cheers,
Keith Satterley,
On 18/02/2011 11:12 PM, Jon Clayden wrote:
I would also be interested in knowing what the rationale is for this.
Moreover, it seems that the "standard" (and documented) approach to
this of calling "options(defaultPackages=c(...))" in ~/.Rprofile does
not get ignored when installing. The environment variable approach may
work, but it seems to me that this requires some (educated) guesswork.
Could R CMD INSTALL not ignore the default packages option?
Regards,
Jon
On 16 February 2011 17:25, Brian G. Peterson wrote:
On 02/16/2011 10:57 AM, Prof Brian Ripley wrote:
The most obvious answer is not to do that. You have not used the
standard mechanism to to do that (which should work here as R CMD
INSTALL overrides that one). It's all in ?Startup (look for
R_DEFAULT_PACKAGES).
Note that R CMD INSTALL is not mentioned at all here.
The simplest way to ignore ~/.Rprofile is to set R_PROFILE_USER to
something else.
I've tried R --vanilla CMD INSTALL, but that seems to have no effect.
As documented.
Then let's try this from another angle...
Is there a rationale why --vanilla or --no-environ or --no-site-file or
--no-init-file are *NOT* supported by R CMD INSTALL ? I don't see any
reasoning for the inconsistency in the docs anywhere.
If not, would R-core entertain a patch that would handle these options?
This functionality is troublesome in a production installations where we
*want* our users to have specific packages and environment options set all
the time, and I need to edit the Rprofile.site file every time I upgrade one
of these 'production' packages.
Regards,
- Brian
__
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
__
The information in this email is confidential and intend...{{dropped:4}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] tcltk freezing using MS Windows for R-2.14+
I am the maintainer of a Bioconductor package (affylmGUI) which uses
tcltk. It freezes inconsistently on MS Windows, but not Mac or Unix. see
details below.
After considerable testing I have reduced the problem from a few
thousand lines of code to 30 lines!
If you paste the following lines of code into an R window:
testGUI <- function(){
require(tcltk)
MainWindow <- tktoplevel()
topMenu <- tkmenu(MainWindow)
tkconfigure(MainWindow,menu=topMenu)
normalizeMenu <- tkmenu(topMenu, tearoff=FALSE)
tkadd(normalizeMenu,"command",label="Normalize",command =
function() NormalizeNow(MainWindow))
tkadd(topMenu, "cascade", label="MainWindow", menu = normalizeMenu)
tkfocus(MainWindow)
#
}#end of testGUI <- function()
#
NormalizeNow <- function(MainWindow){
NMethod <- GetNMethod(MainWindow)
if (NMethod=="") return()
tkconfigure(MainWindow,cursor="watch")
tkfocus(MainWindow)
}#end of NormalizeNow <- function(){
#
GetNMethod <- function(MainWindow){
ReturnVal <- "RMA"
GNMethod <- tktoplevel(MainWindow)
tkwm.deiconify(GNMethod)
tkgrab.set(GNMethod)
tkfocus(GNMethod)
tkwm.title(GNMethod,"Get Method")
tkbind(GNMethod,"",function() {ReturnVal <-
"";tkgrab.release(GNMethod);tkfocus(MainWindow);})
tkwait.window(GNMethod)
return (ReturnVal)
}#end of GetNMethod <- function()
and then run the function testGUI()
A Main Window pops up with "Main Window" in the Menu bar. Click on "Main
Window" and the first (and only) item on the menu drops down and it is
called "Normalize". Clicking this opens another windows entitled "Get
Method". If there is a problem (it is intermittent), it is evidenced by
the fact that the "Get Method" window will not close.
It cannot be closed by clicking. The window is frozen open. It can be
moved but not closed. On MS Windows, the "Get Method" window can be
closed using the right button close window option on the task bar icon
Typically the problem occurs infrequently in the first 10 presses on the
"Normalize" item, but more frequently there after.
I have NOT had the problem on Mac OSX or Linux.
On MS Windows (I have tested on Win XP-32bit and Win7-64bit) the problem
occurs in R-2.16.0, R-2.15.2, R-2.15.1,R-2.14.0.
THERE IS NO PROBLEM WITH R-2.13.1 and R-2.13.0
I have run it using debug("GetNMethod"). Stepping through the GetNMethod
function results in freezing when asked to do the "tkgrab.set(GNMethod)"
instruction.
I would appreciate if others can confirm similar behaviour.
Can anyone suggest why it worked under R-2.13.x but not in later
versions of R.
Was there a change in R that impacts with this aspect of tcltk?
Is there a work around for this problem?
Any suggestions appreciated,
thanks
Keith Satterley
affylmGUI, limmaGUI maintainer.
Bioinformatics Division
The Walter and Eliza Hall Institute
Melbourne, Australia.
Some sessionInfo() outputs:
Win7-64bit-R-2.15.2 testGUI() fails intermittently.
> sessionInfo()
R version 2.15.2 (2012-10-26)
Platform: x86_64-w64-mingw32/x64 (64-bit)
locale:
[1] LC_COLLATE=English_Australia.1252 LC_CTYPE=C
[3] LC_MONETARY=English_Australia.1252 LC_NUMERIC=C
[5] LC_TIME=English_Australia.1252
attached base packages:
[1] tcltk stats graphics grDevices utils datasets methods
base
Linux x64-R-2.15.2. testGUI() works always
R version 2.15.2 (2012-10-26)
Platform: x86_64-unknown-linux-gnu (64-bit)
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=C LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] tcltk stats graphics grDevices utils datasets methods
[8] base
Mac OS X R-2.15.2. testGUI() works always
> sessionInfo()
R version 2.15.2 (2012-10-26)
Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit)
locale:
[1] en_AU.UTF-8/en_AU.UTF-8/en_AU.UTF-8/C/en_AU.UTF-8/en_AU.UTF-8
attached base packages:
[1] tcltk stats graphics grDevices utils datasets methods
base
WinXP-32bit--R-2.15.2. testGUI() fails intermittently
> sessionInfo()
R version 2.15.2 (2012-10-26)
Platform: i386-w64-mingw32/i386 (32-bit)
locale:
[1] LC_COLLATE=English_Australia.1252 LC_CTYPE=English_Australia.1252
LC_MONETARY=English_Australia.1252 LC_NUMERIC=C
[5] LC_TIME=English_Australia.1252
attached base packages:
[1] tcltk stats graphics grDevices utils datasets
methods base
Win7-R-2.13.1. testGUI() works always
> sessionInfo()
R version 2.13.1 (2011-07-08)
Platform: x86_64-pc-mingw32/x64 (64-bit)
locale
Re: [Rd] tcltk freezing using MS Windows for R-2.14+
Thanks Duncan for testing. I have installed the latest binary I could
find which is:
R Under development (unstable) (2012-11-16 r61126)
Platform: x86_64-w64-mingw32/x64 (64-bit)
I still have a problem.
I have shortened the code as you suggested - now it's only 6 lines!
could you try this please:
test2GUI <- function(){
require(tcltk)
MainWindow <- tktoplevel()
topMenu <- tkmenu(MainWindow)
tkconfigure(MainWindow,menu=topMenu)
tkgrab.set(MainWindow)
tkfocus(MainWindow)
}
When I run this function 40 times my record of success was as follows
010110101010110100011
where 1 means I could close the window, 0 means it froze.
I could actually run the function 20 times, displaying 20 windows and
then tried to close them one by one. I then repeated this after using
the mouse right click on the task bar to close those windows that were
frozen.
I haven't submitted it to R bug list yet. Should I now go ahead and do that?
cheers,
Keith Satterley
On 20/11/2012 8:20 AM, Duncan Murdoch wrote:
On 19/11/2012 12:05 AM, Keith wrote:
...
On MS Windows (I have tested on Win XP-32bit and Win7-64bit) the problem
occurs in R-2.16.0, R-2.15.2, R-2.15.1,R-2.14.0.
Of course, there is no 2.16.0 yet, but one more datapoint: I can't
reproduce the problem with a current build of R-devel (i.e. the one
that reports itself as 2012-11-19 r61131. What version were you trying?
Duncan Murdoch
__
The information in this email is confidential and intend...{{dropped:4}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] tcltk freezing using MS Windows for R-2.14+
Andreas,
thanks so much for this clue.
I have found that if I reduced the time in seconds from 0.1 to 0.01 to
0.001 to 0.0001 I only had problems with freezing on the 0.0001 time.
I tested on Win7(64 bit) on an Intel core i7 870 at 2.93GHz (16GB ram)(8
cores)
and a WinXP (32bit) Pentium 4 3.01GHz (2GB ram) using
R-2.15.2(2012-10-26) on both.
I had previously found that the tkgrab.set command seemed to be the one
actually freezing
so I placed the sleep command just before that with the same result as
it being just after the tktoplevel command.
I am now going to try it in my packages affylmGUI and limmaGUI, probably
with a sleep time of 0.1 to be on the safe side,
many thanks,
Keith Satterley
On 18/12/2012 9:38 PM, Moeltner, Andreas wrote:
R Version 2.15.0/Windows XP
Maybe this will help to identify the problem (I have similar problems with
other tcltk-windows, too.)
Inserting some time delay after tktoplevel helps (on my PC):
test2GUI <- function(){
require(tcltk)
MainWindow <- tktoplevel()
Sys.sleep(0.1)
topMenu <- tkmenu(MainWindow)
tkconfigure(MainWindow,menu=topMenu)
tkgrab.set(MainWindow)
tkfocus(MainWindow)
}
Cheers
Andreas
Andreas Möltner
__
The information in this email is confidential and intend...{{dropped:4}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] OpenBLAS in everyday R?
Do those issues still arise when OpenBLAS is compiled with USE_OPENMP=1 ? Keith > On Jan 9, 2018, at 6:03 PM, Benjamin Tyner wrote: > > Please pardon my ignorance, but doesn't OpenBLAS still not always play nicely > with multi-threaded OpenMP? (for example, don't race conditions sometimes > crop up)? If so, it might be nice to have the ability to temporarily disable > multi-threaded OpenMP (effectively: omp_set_num_threads(1)) for the duration > of operations using OpenBLAS. > > Regards > Ben > >> Julia using OpenBLAS is *very* reassuring. >> >> I agree that having it included as an options(...) feature should be OK. >> >> On Sun, Dec 17, 2017, 3:22 PM Juan Telleria > <https://stat.ethz.ch/mailman/listinfo/r-devel>> wrote: >> >> >/Julia Programming Language uses also OpenBlas, and it is actively >> >/>/maintained with bugs being fixed as I have checked it out: >> >/>//>/http://www.openblas.net/Changelog.txt />//>/So I still see it ok to >> >be included as an options(...) feature (by default />/off, just for >> >safety), over other Blas libraries. />//>/R could not use Intel MKL for >> >legal reasons (I think), because as long />/that R ships with GPL >> >libraries, shipping R by default with Non-GPL is />/illegal. />//>/Cheers, >> >/>/Juan />//>/El 17/12/2017 2:50 a. m., "Avraham Adler" > >gmail.com <https://stat.ethz.ch/mailman/listinfo/r-devel>> />/escribió: >> >/>//>>/On Sat, Dec 16, 2017 at 7:41 PM, Kenny Bell > ><https://stat.ethz.ch/mailman/listinfo/r-devel>> wrote: />>/> It seems like >> >many of the multi-threaded BLASes have some sort of />>/> fundamental >> >problem preventing use in the way Juan suggests: />>/> />>/> - Dirk's >> >vignette states that ATLAS "fixes the number of cores used at />>/> >> >compile-time and cannot vary this setting at run-time", so any />>/> >> >user-friendly implementation for R would have to compile ATLAS for 1-16 >> >/>>/> threads to allow the user to switch at run-time. This might >> >dramatically />>/> affect install times. />>/> />>/> - MKL seems like it's >> >been outright rejected in the past based on not />>/> being "free-enough". >> >/>>/> />>/> - OpenBLAS causes crashes. />>/> />>/> Has anyone tried ExBLAS >> >for use with R? />>/> />>/> On Sun, Dec 17, 2017 at 1:03 PM, Peter >> >Langfelder < />>/> peter.langfelder at gmail.com >> ><https://stat.ethz.ch/mailman/listinfo/r-devel>> wrote: />>/> />>/>> I >> >would be very cautious about OpenBLAS in particular... from time to />>/>> >> >time I get complains from users that compiled code calculations in my >> >/>>/>> WGCNA package crash or produce wrong answers with large data, and >> >they />>/>> all come from OpenBLAS users. I am yet to reproduce any of >> >their />>/>> crashes when using MKL and ATLAS BLAS implementations. />>/>> >> >/>>/>> Just my 2 cents... />>/>> />>/>> Peter />>//>>/I've been building R >> >on Windows 64 bit with OpenBLAS for years and my />>/builds pass >> >check-devel. For a while in the past it failed one check />>/as the >> >tolerance was 5e-5 and with my build of OpenBLAS the error was />>/5.4e-5 >> >or 5.7e-5, but that was changed around R 3.3, if I recall />>/correctly. I >> >provide descriptions here [1], but I haven't gone so far />>/as to post >> >compiled Rblas.dlls just yet. My personal build sets 4 />>/threads when >> >compiling OpenBLAS itself as I'm currently on a quad-core />>/SandyBridge. >> >In tests I ran a few years ago, both single and multi />>/threaded BLAS >> >compile and then can be compiled into R with no issues />>/(on my >> >platforms, at least). Most matrix operations performed better />>/with >> >multi-threaded except for R's eigenvalue decomposition, to the />>/nest of >> >my recollection. />>//>>/Avi />>//>>/[1] >> >https://www.avrahamadler.com/r-tips/build-openblas-for-windows-r64/ >> >/>>//>>/__ />>/R-devel at >> >r-project.org <https://stat.ethz.ch/mailman/listinfo/r-devel> mailing list >> >/>>/https://stat.ethz.ch/mailman/listinfo/r-devel />>//>// >> [[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] OpenBLAS in everyday R?
Check if libopenblas is linked against libomp or libgomp. I’d be curious to see any errors that arise when an OpenMP version of OpenBLAS is linked with R. Keith > On Jan 9, 2018, at 11:01 PM, Benjamin Tyner wrote: > > I didn't do the compile; is there a way to check whether that was used? If > not, I'll inquire with our sysadmin and report back. > > In any case, my suggestion was motivated by the fact that some parts of R use > OpenMP while others do not, in the hope that the former could have their > OpenBLAS omelet without breaking the OpenMP eggs, so to speak. > > > On 01/09/2018 06:41 PM, Keith O'Hara wrote: >> Do those issues still arise when OpenBLAS is compiled with USE_OPENMP=1 ? >> >> Keith >> >>> On Jan 9, 2018, at 6:03 PM, Benjamin Tyner wrote: >>> >>> Please pardon my ignorance, but doesn't OpenBLAS still not always play >>> nicely with multi-threaded OpenMP? (for example, don't race conditions >>> sometimes crop up)? If so, it might be nice to have the ability to >>> temporarily disable multi-threaded OpenMP (effectively: >>> omp_set_num_threads(1)) for the duration of operations using OpenBLAS. >>> >>> Regards >>> Ben >>> >>>> Julia using OpenBLAS is *very* reassuring. >>>> >>>> I agree that having it included as an options(...) feature should be OK. >>>> >>>> On Sun, Dec 17, 2017, 3:22 PM Juan Telleria >>> <https://stat.ethz.ch/mailman/listinfo/r-devel>> wrote: >>>> >>>>> /Julia Programming Language uses also OpenBlas, and it is actively >>>>> />/maintained with bugs being fixed as I have checked it out: >>>>> />//>/http://www.openblas.net/Changelog.txt />//>/So I still see it ok to >>>>> be included as an options(...) feature (by default />/off, just for >>>>> safety), over other Blas libraries. />//>/R could not use Intel MKL for >>>>> legal reasons (I think), because as long />/that R ships with GPL >>>>> libraries, shipping R by default with Non-GPL is />/illegal. >>>>> />//>/Cheers, />/Juan />//>/El 17/12/2017 2:50 a. m., "Avraham Adler" >>>>> >>>> <https://stat.ethz.ch/mailman/listinfo/r-devel>> />/escribió: />//>>/On >>>>> Sat, Dec 16, 2017 at 7:41 PM, Kenny Bell >>>> <https://stat.ethz.ch/mailman/listinfo/r-devel>> wrote: />>/> It seems >>>>> like many of the multi-threaded BLASes have some sort of />>/> >>>>> fundamental problem preventing use in the way Juan suggests: />>/> />>/> >>>>> - Dirk's vignette states that ATLAS "fixes the number of cores used at >>>>> />>/> compile-time and cannot vary this setting at run-time", so any >>>>> />>/> user-friendly implementation for R would have to compile ATLAS for >>>>> 1-16 />>/> threads to allow the user to switch at run-time. This might >>>>> dramatically />>/> affect install times. />>/> />>/> - MKL seems like >>>>> it's been outright rejected in the past based on not />>/> being >>>>> "free-enough". />>/> />>/> - OpenBLAS causes crashes. />>/> />>/> Has >>>>> anyone tried ExBLAS for use with R? />>/> />>/> On Sun, Dec 17, 2017 at >>>>> 1:03 PM, Peter Langfelder < />>/> peter.langfelder at gmail.com >>>>> <https://stat.ethz.ch/mailman/listinfo/r-devel>> wrote: />>/> />>/>> I >>>>> would be very cautious about OpenBLAS in particular... from time to >>>>> />>/>> time I get complains from users that compiled code calculations in >>>>> my />>/>> WGCNA package crash or produce wrong answers with large data, >>>>> and they />>/>> all come from OpenBLAS users. I am yet to reproduce any >>>>> of their />>/>> crashes when using MKL and ATLAS BLAS implementations. >>>>> />>/>> />>/>> Just my 2 cents... />>/>> />>/>> Peter />>//>>/I've been >>>>> building R on Windows 64 bit with OpenBLAS for years and my />>/builds >>>>> pass check-devel. For a while in the past it failed one check />>/as the >>>>> toler
Re: [Rd] OpenBLAS in everyday R?
I won’t play nicely with a package that combines omp pragmas with calls to BLAS routines, e.g. something you might get with source Armadillo/Eigen/Blaze code, for reasons that Benjamin mentioned in his initial email (pthreads vs omp). Keith > On Jan 10, 2018, at 1:28 AM, Avraham Adler wrote: > > On Wed, Jan 10, 2018 at 12:04 AM, Keith O'Hara wrote: >> >> Check if libopenblas is linked against libomp or libgomp. >> >> I’d be curious to see any errors that arise when an OpenMP version of >> OpenBLAS is linked with R. >> >> Keith >> > > The one time I tried compiling OpenBLAS for Windows 64 with USE OMP = > 1, I got an error. I don't recall if it was in the compilation of R or > in use. Regardless, I compile OpenBLAS without setting that flag and > it still plays nicely with all R packages, including those that use > OpenMP. > > Avi __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] OpenBLAS in everyday R?
I’m not really familiar with conda, but if they’re being packaged together then an omp build might be more appropriate. Perhaps another point for Juan’s list: whether OpenBLAS is the right choice to pair with. The library itself hasn’t produced optimized kernels for any of the Intel *Lake chips yet; might be worth considering its near- and long-term future (vs something else). Keith > On Jan 10, 2018, at 8:24 PM, Benjamin Tyner wrote: > > Thanks Keith. We checked, and indeed libopenblas is not linked against libomp > nor libgomp. We suspect this is because we used conda to install R and > OpenBLAS. So I guess we should be barking up the conda tree instead? > > By the way, I also noticed on my home machine (Ubuntu), > /usr/lib/libopenblas.so.0 is also not linked against those, for what that's > worth. > > Regards, > Ben > > On 01/10/2018 12:04 AM, Keith O'Hara wrote: >> Check if libopenblas is linked against libomp or libgomp. >> >> I’d be curious to see any errors that arise when an OpenMP version of >> OpenBLAS is linked with R. >> >> Keith >> >> >>> On Jan 9, 2018, at 11:01 PM, Benjamin Tyner wrote: >>> >>> I didn't do the compile; is there a way to check whether that was used? If >>> not, I'll inquire with our sysadmin and report back. >>> >>> In any case, my suggestion was motivated by the fact that some parts of R >>> use OpenMP while others do not, in the hope that the former could have >>> their OpenBLAS omelet without breaking the OpenMP eggs, so to speak. >>> >>> >>> On 01/09/2018 06:41 PM, Keith O'Hara wrote: >>>> Do those issues still arise when OpenBLAS is compiled with USE_OPENMP=1 ? >>>> >>>> Keith >>>> >>>>> On Jan 9, 2018, at 6:03 PM, Benjamin Tyner wrote: >>>>> >>>>> Please pardon my ignorance, but doesn't OpenBLAS still not always play >>>>> nicely with multi-threaded OpenMP? (for example, don't race conditions >>>>> sometimes crop up)? If so, it might be nice to have the ability to >>>>> temporarily disable multi-threaded OpenMP (effectively: >>>>> omp_set_num_threads(1)) for the duration of operations using OpenBLAS. >>>>> >>>>> Regards >>>>> Ben >>>>> >>>>>> Julia using OpenBLAS is *very* reassuring. >>>>>> >>>>>> I agree that having it included as an options(...) feature should be OK. >>>>>> >>>>>> On Sun, Dec 17, 2017, 3:22 PM Juan Telleria >>>>> <https://stat.ethz.ch/mailman/listinfo/r-devel>> wrote: >>>>>> >>>>>>> /Julia Programming Language uses also OpenBlas, and it is actively >>>>>>> />/maintained with bugs being fixed as I have checked it out: >>>>>>> />//>/http://www.openblas.net/Changelog.txt />//>/So I still see it ok >>>>>>> to be included as an options(...) feature (by default />/off, just for >>>>>>> safety), over other Blas libraries. />//>/R could not use Intel MKL for >>>>>>> legal reasons (I think), because as long />/that R ships with GPL >>>>>>> libraries, shipping R by default with Non-GPL is />/illegal. >>>>>>> />//>/Cheers, />/Juan />//>/El 17/12/2017 2:50 a. m., "Avraham Adler" >>>>>>> >>>>>> <https://stat.ethz.ch/mailman/listinfo/r-devel>> />/escribió: />//>>/On >>>>>>> Sat, Dec 16, 2017 at 7:41 PM, Kenny Bell >>>>>> <https://stat.ethz.ch/mailman/listinfo/r-devel>> wrote: />>/> It seems >>>>>>> like many of the multi-threaded BLASes have some sort of />>/> >>>>>>> fundamental problem preventing use in the way Juan suggests: />>/> >>>>>>> />>/> - Dirk's vignette states that ATLAS "fixes the number of cores >>>>>>> used at />>/> compile-time and cannot vary this setting at run-time", >>>>>>> so any />>/> user-friendly implementation for R would have to compile >>>>>>> ATLAS for 1-16 />>/> threads to allow the user to switch at run-time. >>>>>>> This might dramatically />>/> affect install times. />>/> />>/> - MKL >>>>>>> seems like it'
Re: [Rd] Inconsistent rank in qr()
This behavior is noted in the qr documentation, no? rank - the rank of x as computed by the decomposition(*): always full rank in the LAPACK case. > On Jan 22, 2018, at 11:21 AM, Serguei Sokol wrote: > > Hi, > > I have noticed different rank values calculated by qr() depending on > LAPACK parameter. When it is FALSE (default) a true rank is estimated and > returned. > Unfortunately, when LAPACK is set to TRUE, the min(nrow(A), ncol(A)) is > returned > which is only occasionally a true rank. > > Would not it be more consistent to replace the rank in the latter case by > something > based on the following pseudo code ? > > d=abs(diag(qr)) > rank=sum(d >= d[1]*tol) > > Here, we rely on the fact column pivoting is activated in the called lapack > routine (dgeqp3) > and diagonal term in qr matrix are put in decreasing order (according to > their absolute values). > > Serguei. > > How to reproduce: > > a=diag(2) > a[2,2]=0 > qaf=qr(a, LAPACK=FALSE) > qaf$rank # shows 1. OK it's the true rank value > qat=qr(a, LAPACK=TRUE) > qat$rank #shows 2. Bad, it's not the expected value. > > __ > 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] Inconsistent rank in qr()
I agree the result is a little confusing, but the behavior is in line with the documentation and so not ‘unexpected’ as such... I don’t think this is a matter of semantics, more of a ‘return the rank when we have it for free’ situation—when A is real-valued, qr(A,LAPACK=false) calls a modified version of Linpack’s dqrdc which computes the rank internally; see dqrdc2.f, output ‘k’. Lapack’s dqeqp3 doesn’t return the rank as is. Just my 2 cents on a potential fix: Matrix::rankMatrix follows the logic of your code, and I think this would be simpler to implement than modifying Lapack.c in two places (around lines 657 and 1175). Keith > On Jan 22, 2018, at 11:57 AM, Serguei Sokol wrote: > > Le 22/01/2018 à 17:40, Keith O'Hara a écrit : >> This behavior is noted in the qr documentation, no? >> >> rank - the rank of x as computed by the decomposition(*): always full rank >> in the LAPACK case. > For a me a "full rank matrix" is a matrix the rank of which is indeed > min(nrow(A), ncol(A)) > but here the meaning of "always is full rank" is somewhat confusing. Does it > mean > that only full rank matrices must be submitted to qr() when LAPACK=TRUE? > May be there is a jargon where "full rank" is a synonym of min(nrow(A), > ncol(A)) for any matrix > but the fix to stick with commonly admitted rank definition (i.e. the number > of linearly independent > columns in A) is so easy. Why to discard lapack case from it (even properly > documented)? > >> >> >> >>> On Jan 22, 2018, at 11:21 AM, Serguei Sokol wrote: >>> >>> Hi, >>> >>> I have noticed different rank values calculated by qr() depending on >>> LAPACK parameter. When it is FALSE (default) a true rank is estimated and >>> returned. >>> Unfortunately, when LAPACK is set to TRUE, the min(nrow(A), ncol(A)) is >>> returned >>> which is only occasionally a true rank. >>> >>> Would not it be more consistent to replace the rank in the latter case by >>> something >>> based on the following pseudo code ? >>> >>> d=abs(diag(qr)) >>> rank=sum(d >= d[1]*tol) >>> >>> Here, we rely on the fact column pivoting is activated in the called lapack >>> routine (dgeqp3) >>> and diagonal term in qr matrix are put in decreasing order (according to >>> their absolute values). >>> >>> Serguei. >>> >>> How to reproduce: >>> >>> a=diag(2) >>> a[2,2]=0 >>> qaf=qr(a, LAPACK=FALSE) >>> qaf$rank # shows 1. OK it's the true rank value >>> qat=qr(a, LAPACK=TRUE) >>> qat$rank #shows 2. Bad, it's not the expected value. >>> >>> __ >>> R-devel@r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/r-devel >> > > -- > Serguei Sokol > Ingenieur de recherche INRA > > Cellule mathématique > LISBP, INSA/INRA UMR 792, INSA/CNRS UMR 5504 > 135 Avenue de Rangueil > 31077 Toulouse Cedex 04 > > tel: +33 5 6155 9849 > email: so...@insa-toulouse.fr <mailto:so...@insa-toulouse.fr> > http://www.lisbp.fr <http://www.lisbp.fr/> [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Inconsistent rank in qr()
A simpler fix: return rank=NA when Lapack is used. Keith > On Jan 23, 2018, at 5:36 AM, Serguei Sokol wrote: > > Le 23/01/2018 à 08:47, Martin Maechler a écrit : >>>>>>> Serguei Sokol >>>>>>> on Mon, 22 Jan 2018 17:57:47 +0100 writes: >> > Le 22/01/2018 à 17:40, Keith O'Hara a écrit : >> >> This behavior is noted in the qr documentation, no? >> >> >> >> rank - the rank of x as computed by the decomposition(*): always full >> rank in the LAPACK case. >> > For a me a "full rank matrix" is a matrix the rank of which is indeed >> min(nrow(A), ncol(A)) >> > but here the meaning of "always is full rank" is somewhat confusing. >> Does it mean >> > that only full rank matrices must be submitted to qr() when >> LAPACK=TRUE? >> > May be there is a jargon where "full rank" is a synonym of >> min(nrow(A), ncol(A)) for any matrix >> > but the fix to stick with commonly admitted rank definition (i.e. the >> number of linearly independent >> > columns in A) is so easy. Why to discard lapack case from it (even >> properly documented)? >> >> Because 99.5% of caller to qr() never look at '$rank', >> so why should we compute it every time qr() is called? > 1. Because R already does it for linpack so it would be consistent to do so > for lapack too. > 2. Because R pretends that it is a part of a returned qr class. > 3. Because its calculation is a negligible fraction of QR itself. > >> >> ==> Matrix :: rankMatrix() does use "qr" as one of its several methods. >> >> -- >> >> As wiser people than me have said (I'm paraphrasing, don't find a nice >> citation): >> >> While the rank of a matrix is a very well defined concept in >> mathematics (theory), its practical computation on a finite >> precision computer is much more challenging. > True. It is indeed depending of round-off errors during QR calculations and > tolerance > setting but putting it just as min(nrow(A), ncol(A)) and still calling it > rank of "full rank" > is by far the most misleading choice to my mind. > > Once again, if we are already calculating it for linpack let do it in most > consistent > way for lapack too. I can propose a patch if you will. > > Serguei. > >> >> The ?rankMatrix help page (package Matrix, part of your R) >>https://stat.ethz.ch/R-manual/R-devel/library/Matrix/html/rankMatrix.html >> starts with the following 'Description' >> >> __ Compute ‘the’ matrix rank, a well-defined functional in theory(*), >> somewhat ambigous in practice. We provide several methods, the default >> corresponding to Matlab's definition. >> >> __ (*) The rank of a n x m matrix A, rk(A) is the maximal number of linearly >> independent columns (or rows); hence rk(A) <= min(n,m). >> >> >> >>> On Jan 22, 2018, at 11:21 AM, Serguei Sokol >> wrote: >> >>> >> >>> Hi, >> >>> >> >>> I have noticed different rank values calculated by qr() depending on >> >>> LAPACK parameter. When it is FALSE (default) a true rank is >> estimated and returned. >> >>> Unfortunately, when LAPACK is set to TRUE, the min(nrow(A), ncol(A)) >> is returned >> >>> which is only occasionally a true rank. >> >>> >> >>> Would not it be more consistent to replace the rank in the latter >> case by something >> >>> based on the following pseudo code ? >> >>> >> >>> d=abs(diag(qr)) >> >>> rank=sum(d >= d[1]*tol) >> >>> >> >>> Here, we rely on the fact column pivoting is activated in the called >> lapack routine (dgeqp3) >> >>> and diagonal term in qr matrix are put in decreasing order >> (according to their absolute values). >> >>> >> >>> Serguei. >> >>> >> >>> How to reproduce: >> >>> >> >>> a=diag(2) >> >>> a[2,2]=0 >> >>> qaf=qr(a, LAPACK=FALSE) >> >>> qaf$rank # shows 1. OK it's the true rank value >> >>> qat=qr(a, LAPACK=TRUE) >> >>> qat$rank #shows 2. Bad, it's not the expected value. >> >>> >> >> > -- >> > Serguei Sokol >> > Ingenieur de recherche INRA >> >> > Cellule mathématique >> > LISBP, INSA/INRA UMR 792, INSA/CNRS UMR 5504 >> > 135 Avenue de Rangueil >> > 31077 Toulouse Cedex 04 >> >> > tel: +33 5 6155 9849 >> > email: so...@insa-toulouse.fr >> > http://www.lisbp.fr [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R Lapack – why a subset?
Peter, Is there not already a significant maintenance burden from cherry-picking routines? From my own experience (https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16482 <https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16482>) this is a painful process. And while users may not call these complex routines directly, R is often used as a front-end for libraries that do, so Rlapack-related linking errors are arising more and more. Is the cost really so high as to preclude adding the remaining Lapack routines to Rlapack? Best, Keith > On Mar 26, 2018, at 10:24 AM, Peter Dalgaard via R-devel > wrote: > > I'm not too happy with this either, but I believe the reason is that there > would be a significant extra maintenance burden consisting of things that is > not being used by R itself. In particular, complex math routines are little > used and have historically caused a number of issues with correct argument > and return-value passing. > > Notice that it is a bit of a can of worms involving matching up C and Fortran > compilers, OS versions, routines being and not being present in current > LAPACK, which may differ from the system-supplied one, etc. > > -pd > >> On 26 Mar 2018, at 07:49 , Baptiste Auguie wrote: >> >> Hi, >> >> Why doesn't R include a full Lapack but only a subset? >> >> My cda package (now archived) relying on RcppArmadillo has broken multiple >> times on CRAN over the past few years following updates in the underlying >> Armadillo library, Every time it follows the same pattern: Armadillo adds a >> function to solve a specialised linear system more efficiently, and the >> corresponding Lapack routine is not included in the R Lapack subset used on >> CRAN, causing breakage. The workaround so far has been an unhappy >> compromise with Armadillo developers, adding a "crippled lapack" flag in >> the RcppArmadillo configure script, that triggers the use of alternative >> (suboptimal) routines and passes CRAN checks. Most RcppArmadillo-dependent >> packages don't see the problem; mine seems to be the only one using complex >> linear algebra. Two years ago a large number of Lapack routines were added* >> to R, and this nicely solved the issue for a while. Unfortunately the same >> problem resurfaced last year, with another missing Lapack routine, and my >> package is now archived (though it works fine with an external Lapack). >> More generally, this workaround is not satisfying for various reasons, and >> so I want to ask: why does R ship only a subset of Lapack in the first >> place? >> >> Best regards, >> >> baptiste >> >> * Relevant commit at >> https://github.com/wch/r-source/commit/98acd96f22eb795a933879c0d3f740e802855473 >> >> [[alternative HTML version deleted]] >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel > > -- > Peter Dalgaard, Professor, > Center for Statistics, Copenhagen Business School > Solbjerg Plads 3, 2000 Frederiksberg, Denmark > Phone: (+45)38153501 > Office: A 4.23 > Email: pd@cbs.dk Priv: pda...@gmail.com > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem with system2(), directing STDERR to a file
Looking at help for tempfile,
"tempfile" returns a vector of character strings which can be used as
names for temporary files.
and
For "tempfile" a character vector giving the names of possible
(temporary) files. Note that no files are generated by "tempfile".
try a file.create(t) after tempfile()
cheers,
Keith
Dan Tenenbaum wrote:
According to ?system2, I should be able to direct the output of STDERR to a
file by giving the filename as a character vector to the "stderr" argument.
But here is what happens.
Given a ruby script test.rb (with its executable bit set):
#!/usr/bin/env ruby
STDOUT.puts "stdout"
STDERR.puts "stderr"
And the following R code:
t <- tempfile()
res <- system2("./test.rb", stdout=TRUE, stderr=t)
stderr
res
[1] "stdout"
file.exists(t)
[1] FALSE
I would expect the file t to exist and contain "stderr", and I would expect
not to see "stderr" in the console.
Also, there is a typo in the man page - the command is listed as "system" in
the Description instead of "system2".
The reverse behavior does work correctly:
res <- system2("./test.rb", stdout=t, stderr="")
stderr
file.exists(t)
[1] TRUE
Thanks!
Dan
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
The information in this email is confidential and intend...{{dropped:4}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Windows Rdevel version - no Rgui.exe?
Hi Duncan,
just noticed that after installing the Windows R-2.13.0 build there is
no i386 directory in the R-2.13.0dev/bin directory and hence no
Rgui.exe. Is this intentional with the devel version?
I downloaded from http://cran.ms.unimelb.edu.au/, where it says:
"This is a combined Windows 32/64 bit binary build of the 2010-11-27
r53672 development snapshot of R (which will eventually become
R-2.13.0).". Do you think this is an error on my part or do you see the
same thing,
cheers,
Keith
====
Keith Satterley
Bioinformatics Division
The Walter and Eliza Hall Institute of Medical Research
Parkville, Melbourne,
Victoria, Australia
===
__
The information in this email is confidential and intend...{{dropped:4}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Finding inter-function dependencies within a package
Hi, I'd like to know which functions in a package call one specific function. I think I've seen a tool for identifying such dependencies, but now I can't find it :-( Searches of help and R site search for keywords like function, call, tree, depend haven't helped :-( Can anyone point me in the right direction? Thanks in advance, Keith Jewell __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Finding inter-function dependencies within a package
Thanks for the suggestions. Just to wrap up this thread...
Rainer Krug pointed out that Roxygen did have dependency graphs, although
Roxygen2 doesn't. But I guess (probably wrongly!) that I'd need to
process/modify the .R files to use that, and I'm not the package author.
Duncan Murdoch pointed out codetools::findGlobals which can be used to find
functions called by a target function. But I want to find functions calling
a target function.
Mark Bravington pointed out mvbutils::foodweb and callers.of which almost do
what I want (I think it was this I half remembered). But this works in the
namespace of the package, and my target function isn't exported so foodweb
doesn't see it!
Working from Duncan's suggestion I came up with this, not pretty or fast,
could certainly be improved, but it did my one-off job.:
# return a character vector of names of functions in 'tarPack' (character)
which directly call the function 'tarFunc' (character)
called.by <- function(tarFunc, tarPack){
require(codetools)
flist <- sapply(lsf.str(tarPack, all=TRUE), c)
names(flist) <- NULL
gotit <- sapply(flist, function(x) tarFunc %in% findGlobals(get(x, tarPack),
FALSE)$functions)
flist[gotit]
}
# e.g.
called.by("CreateMeanFizz", "package:sensory")
--
Thanks again for the input.
Keith Jewell
>> Hi,
>>
>> I'd like to know which functions in a package call one specific
>> function.
>> I think I've seen a tool for identifying such dependencies, but now I
>> can't find it :-( Searches of help and R site search for keywords
>> like function, call, tree, depend haven't helped :-(
>>
>> Can anyone point me in the right direction?
>>
>> Thanks in advance,
>>
>> Keith Jewell
>>
>> __
>> 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] Finding inter-function dependencies within a package
Following helpful correspondence with Mark Bravington, mvbutils::foodweb and
callers.of can do exactly what I wanted very neatly and easily.
The trick is to use base::asNamespace to see non-exported objects in the
package. base::asNamespace is described as "Internal name space support
functions. Not intended to be called directly" so I'll forgive myself for
not knowing about it previously, and keep an eye open for a more mainstream
way to do the same job. But given that, this does my job perfectly
-
> library(mvbutils)
> ff <- foodweb( funs=find.funs( asNamespace( 'sensory')), where=
> asNamespace( 'sensory'), prune='CreateMeanFizz')
> callers.of('CreateMeanFizz', ff)
---
where 'sensory' is the loaded package I want to search, and 'CreateMeanFizz'
is the non-exported function of which I want to find callers.
Very nice!
Thanks Mark!
Keith J
"Keith Jewell" wrote in message
news:j64058$unj$1...@dough.gmane.org...
> Thanks for the suggestions. Just to wrap up this thread...
>
> Rainer Krug pointed out that Roxygen did have dependency graphs, although
> Roxygen2 doesn't. But I guess (probably wrongly!) that I'd need to
> process/modify the .R files to use that, and I'm not the package author.
>
> Duncan Murdoch pointed out codetools::findGlobals which can be used to
> find functions called by a target function. But I want to find functions
> calling a target function.
>
> Mark Bravington pointed out mvbutils::foodweb and callers.of which almost
> do what I want (I think it was this I half remembered). But this works in
> the namespace of the package, and my target function isn't exported so
> foodweb doesn't see it!
>
> Working from Duncan's suggestion I came up with this, not pretty or fast,
> could certainly be improved, but it did my one-off job.:
>
> # return a character vector of names of functions in 'tarPack' (character)
> which directly call the function 'tarFunc' (character)
> called.by <- function(tarFunc, tarPack){
> require(codetools)
> flist <- sapply(lsf.str(tarPack, all=TRUE), c)
> names(flist) <- NULL
> gotit <- sapply(flist, function(x) tarFunc %in% findGlobals(get(x,
> tarPack), FALSE)$functions)
> flist[gotit]
> }
> # e.g.
> called.by("CreateMeanFizz", "package:sensory")
> --
>
> Thanks again for the input.
>
> Keith Jewell
>
>>> Hi,
>>>
>>> I'd like to know which functions in a package call one specific
>>> function.
>>> I think I've seen a tool for identifying such dependencies, but now I
>>> can't find it :-( Searches of help and R site search for keywords
>>> like function, call, tree, depend haven't helped :-(
>>>
>>> Can anyone point me in the right direction?
>>>
>>> Thanks in advance,
>>>
>>> Keith Jewell
>>>
>>> __
>>> 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] Latest R-devel build failing on OS X
Dear R-devel, The latest version of R-devel (05-17) is throwing an error for me when building on OS X (v 10.11.4): making Rembedded.d from Rembedded.c making dynload.d from dynload.c making system.d from system.c making sys-unix.d from sys-unix.c making sys-std.d from sys-std.c making X11.d from X11.c clang -I. -I../../src/include -I../../src/include -I/usr/local/include -DHAVE_CONFIG_H-fPIC -Wall -mtune=core2 -g -O2 -c Rembedded.c -o Rembedded.o clang -I. -I../../src/include -I../../src/include -I/usr/local/include -DHAVE_CONFIG_H-fPIC -Wall -mtune=core2 -g -O2 -c dynload.c -o dynload.o clang -I. -I../../src/include -I../../src/include -I/usr/local/include -DHAVE_CONFIG_H-fPIC -Wall -mtune=core2 -g -O2 -c system.c -o system.o clang -I. -I../../src/include -I../../src/include -I/usr/local/include -DHAVE_CONFIG_H-fPIC -Wall -mtune=core2 -g -O2 -c sys-unix.c -o sys-unix.o clang -I. -I../../src/include -I../../src/include -I/usr/local/include -DHAVE_CONFIG_H-fPIC -Wall -mtune=core2 -g -O2 -c sys-std.c -o sys-std.o sys-std.c:592:5: warning: implicit declaration of function 'RL_UNSETSTATE' is invalid in C99 [-Wimplicit-function-declaration] RL_UNSETSTATE(RL_STATE_ISEARCH | RL_STATE_NSEARCH | RL_STATE_VIMOTION | ^ sys-std.c:592:19: error: use of undeclared identifier 'RL_STATE_ISEARCH' RL_UNSETSTATE(RL_STATE_ISEARCH | RL_STATE_NSEARCH | RL_STATE_VIMOTION | ^ sys-std.c:592:38: error: use of undeclared identifier 'RL_STATE_NSEARCH' RL_UNSETSTATE(RL_STATE_ISEARCH | RL_STATE_NSEARCH | RL_STATE_VIMOTION | ^ sys-std.c:592:57: error: use of undeclared identifier 'RL_STATE_VIMOTION' RL_UNSETSTATE(RL_STATE_ISEARCH | RL_STATE_NSEARCH | RL_STATE_VIMOTION | ^ sys-std.c:593:5: error: use of undeclared identifier 'RL_STATE_NUMERICARG' RL_STATE_NUMERICARG | RL_STATE_MULTIKEY); ^ sys-std.c:593:27: error: use of undeclared identifier 'RL_STATE_MULTIKEY' RL_STATE_NUMERICARG | RL_STATE_MULTIKEY); ^ sys-std.c:596:40: error: use of undeclared identifier 'rl_mark' rl_line_buffer[rl_point = rl_end = rl_mark = 0] = 0; ^ sys-std.c:597:5: error: use of undeclared identifier 'rl_done' rl_done = 1; ^ sys-std.c:998:7: warning: implicit declaration of function 'rl_resize_terminal' is invalid in C99 [-Wimplicit-function-declaration] rl_resize_terminal(); ^ 2 warnings and 7 errors generated. make[3]: *** [sys-std.o] Error 1 make[2]: *** [R] Error 2 make[1]: *** [R] Error 1 make: *** [R] Error 1 My configuration information: R is now configured for x86_64-apple-darwin15.4.0 Source directory: . Installation directory:/Builds/R-devel C compiler:clang -Wall -mtune=core2 -g -O2 Fortran 77 compiler: gfortran-4.8 -g -O2 C++ compiler: clang++ -Wall -mtune=core2 -g -O2 C++11 compiler:clang++ -std=c++11 -Wall -mtune=core2 -g -O2 Fortran 90/95 compiler:gfortran-4.8 -Wall -g -O2 Obj-C compiler: clang -Wall -mtune=core2 -g -O2 -fobjc-exceptions Interfaces supported: aqua, tcltk External libraries:readline, BLAS(OpenBLAS), LAPACK(in blas), curl Additional capabilities: PNG, JPEG, TIFF, NLS, cairo, ICU Options enabled: shared R library, R profiling, memory profiling Capabilities skipped: Options not enabled: shared BLAS Recommended packages: yes Apologies in advance if I have incorrectly formatted the issue or omitted something important. Kind regards, Keith __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Latest R-devel build failing on OS X
Thanks for the fix, Martin. The build runs smoothly now, with just a warning remaining: sys-std.c:1002:7: warning: implicit declaration of function 'rl_resize_terminal' is invalid in C99 [-Wimplicit-function-declaration] rl_resize_terminal(); ^ 1 warning generated. Best, Keith > On May 18, 2016, at 12:54 PM, Martin Maechler > wrote: > > >> Yes, the nightly build is broken in a similar, but different way. See below. >> Both seem to be readline related, so Frederick Eaton's patches, which Martin >> committed yesterday are the likely culprit. I had actually tested them and >> things seemed to work, but it was on a different machine and not a >> completely clean build. > > Indeed a problem. I'm pretty sure that RL_UNSETSTATE() exists > in newer versions of readline but not in older ones (and hence is > declared in newer versions of readline.h, but not in older > ones). > > It seems people still do have older versions of readline.h > ... and it may be interesting why some versions of OSX (Peter's) > has a new readline and some (Keith') don't. > > I'm committing an experimental fix using #if ... s and the > readline version number. > It does keep fixing the bug on my platform (Fedora 22 Linux, > readline 6.3) > > and it may help in Keith' setup. Please do check it, Keith. > (svn rev >= 70631) > > Martin > > > >> -pd > >> . >> ranlib: file: libR.a(printf.o) has no symbols >> gcc -L/usr/X11R6/lib -o R.bin Rmain.o CommandLineArgs.o Rdynload.o >> Renviron.o RNG.o agrep.o apply.o arithmetic.o array.o attrib.o bind.o >> builtin.o character.o coerce.o colors.o complex.o connections.o context.o >> cum.o dcf.o datetime.o debug.o deparse.o devices.o dotcode.o dounzip.o >> dstruct.o duplicate.o edit.o engine.o envir.o errors.o eval.o format.o >> gevents.o gram.o gram-ex.o graphics.o grep.o identical.o inlined.o inspect.o >> internet.o iosupport.o lapack.o list.o localecharset.o logic.o main.o >> mapply.o match.o memory.o names.o objects.o options.o paste.o platform.o >> plot.o plot3d.o plotmath.o print.o printarray.o printvector.o printutils.o >> qsort.o radixsort.o random.o raw.o registration.o relop.o rlocale.o >> saveload.o scan.o seq.o serialize.o sort.o source.o split.o sprintf.o >> startup.o subassign.o subscript.o subset.o summary.o sysutils.o times.o >> unique.o util.o version.o g_alab_her.o g_cntrlify.o g_fontdb.o g_her_glyph.o >> xxxpr.o `ls ../unix/*.o ../appl/*.o ../nmath/*.! o` ../extra/ >> tre/libtre.a ../extra/intl/libintl.a ../extra/tzone/libtz.a >> -L../../lib/x86_64 -lRblas -L/usr/lib/gcc/i686-apple-darwin11/4.2.1/x86_64 >> -L/usr/lib/gcc/i686-apple-darwin11/4.2.1 -L/usr/lib -lgfortran >> -Wl,-framework -Wl,CoreFoundation -lreadline -lpcre -llzma -lbz2 -lz >> -licucore -lm -llzma -liconv >> Undefined symbols for architecture x86_64: >> "_rl_mark", referenced from: >> _popReadline in sys-std.o >> "_rl_readline_state", referenced from: >> _popReadline in sys-std.o >> "_rl_resize_terminal", referenced from: >> _Rstd_ReadConsole in sys-std.o >> ld: symbol(s) not found for architecture x86_64 >> clang: error: linker command failed with exit code 1 (use -v to see >> invocation) >> make[3]: *** [R.bin] Error 1 > >> On 18 May 2016, at 14:18 , Keith O'Hara wrote: > >>> Dear R-devel, >>> >>> The latest version of R-devel (05-17) is throwing an error for me when >>> building on OS X (v 10.11.4): >>> >>> making Rembedded.d from Rembedded.c >>> making dynload.d from dynload.c >>> making system.d from system.c >>> making sys-unix.d from sys-unix.c >>> making sys-std.d from sys-std.c >>> making X11.d from X11.c >>> clang -I. -I../../src/include -I../../src/include -I/usr/local/include >>> -DHAVE_CONFIG_H-fPIC -Wall -mtune=core2 -g -O2 -c Rembedded.c -o >>> Rembedded.o >>> clang -I. -I../../src/include -I../../src/include -I/usr/local/include >>> -DHAVE_CONFIG_H-fPIC -Wall -mtune=core2 -g -O2 -c dynload.c -o >>> dynload.o >>> clang -I. -I../../src/include -I../../src/include -I/usr/local/include >>> -DHAVE_CONFIG_H-fPIC -Wall -mtune=core2 -g -O2 -c system.c -o system.o >>> clang -I. -I../../src/include -I../../src/include -I/usr/local/include >>> -DHAVE_CONFIG_H-fPIC -Wall -mtune=core2 -g -O2 -c sys-unix.c -o >>> sys-unix.o >>> clang -I. -I../../src/inclu
Re: [Rd] Latest R-devel build failing on OS X
On my machine (iMac w/ El Capitan (10.11.4)), svn rev. 70662 builds without any errors (and the warning I mentioned before is now gone too). K > On May 24, 2016, at 6:55 AM, Martin Maechler > wrote: > > > Can you (Frederick, Peter, Keith, but ideally others, too) > confirm that you don't see any problems anymore, when building a > version of R-devel from sources that are newer > than (or equal to) svn revision 70632 (2016-05-19 10:59:51, see below)? > > I'm asking because the question is open if these should be > "back ported" to R 3.3.0 patched or not. > > Best regards, > Martin > >>>>>> Martin Maechler >>>>>>on Thu, 19 May 2016 11:02:48 +0200 writes: > >>>>>> >>>>>>on Wed, 18 May 2016 15:03:31 -0700 writes: > >>>> Readline <= 6.2 shouldn't require the SIGWINCH patch, so >>>> if older versions have trouble finding rl_resize_terminal >>>> then you could wrap a macro around that part. > >>> I find python related patches that use > >>> #ifdef HAVE_RL_RESIZE_TERMINAL > >>> so they must have configured for that. We could and >>> probably should do the same, but as a Linux_only guy >>> currently (even basically only one flavor of Linux), I'd >>> appreciate others to produce code for that. > >> Actually that was easy (in hindsight.. I took too long!) >> enough, so I've now committed > >> >> r70632 | maechler | 2016-05-19 10:59:51 +0200 (Thu, 19 May 2016) | 1 line >> Changed paths: >> M configure >> M configure.ac >> M src/include/config.h.in >> M src/unix/sys-std.c > >> check for rl_resize_terminal() now >> > >> ... and Keith should even not see the warning anymore >> (nor Peter the error, when compiling using readline 5.x instead of 6.[23]). > > >[...] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Latest R-devel build failing on OS X
svn checkout https://svn.r-project.org/R/trunk/ > On May 24, 2016, at 12:45 PM, frede...@ofb.net wrote: > > I agree with Martin's summary of the situation, and with the updated > NEWS entry. > > I'm not familiar with Subversion, can you tell me the command to use? > > (I tried "svn co https://svn.r-project.org/R/"; but it seems to be > downloading all branches) > > Frederick > > On Tue, May 24, 2016 at 04:30:11PM +0200, Martin Maechler wrote: >>>>>>> peter dalgaard >>>>>>>on Tue, 24 May 2016 13:47:27 +0200 writes: >> >>> I had a regression in config.site so the nightly build didn't. Retrying >>> Looks like it will build, but the ctl-R, ctl-C bug is still present on OSX >>> (w/Simon's libs). This _was_ fixed for a while, was it not? >> >> I thought it was never fixed, for readline versions 5.x (or all >> of readline_version < 6.3 ?) because the patch assumed features >> not available, e.g., for Frederik (who got compilation errors >> which I think you confirmed on pre-6 readline). >> >> I remember you having two different readlines installed on OSX >> but the standard Mac binary (from CRAN, i.e. Simon) would use >> the old readline version ? >> >> so that whole resetReadline() solution is now conditionalized inside >> >> #if defined(RL_READLINE_VERSION) && RL_READLINE_VERSION >= 0x0603 >> ... >> ... >> #endif >> >> and hence the previous code (which is buggy) is used for >> readline versions < 6.3. >> As a consequence the bug is only fixed for readline >= 6.3, >> because the current patch did not compile and hence seemed not >> appropriate for readline < 6.3 (and hence the above conditionalization). >> >> >>> (The NEWS entry is also wrong: The issue existed before readline 6.3) >> >> Aah.. you are right. The API change with 6.3 was for the other, the >> "SIGWINCH" bug. >> >> Here's a an update proposal for that NEWS entry : >> >> • The API for readline libraries >= 6.3 had changed such >> terminal window resizes where no longer properly signalled >> (PR#16604). Also, ‘Ctrl C’ in incremental search behaved >> confusingly in R (unix) consoles (PR#16603) also for older >> readline versions. These have been fixed (for readline >= >> 6.3 only), thanks to patches by Frederick Eaton. >> >> >> Martin >> >>> -pd >> >>> On 24 May 2016, at 12:55 , Martin Maechler >>> wrote: >> >>>> >>>> Can you (Frederick, Peter, Keith, but ideally others, too) >>>> confirm that you don't see any problems anymore, when building a >>>> version of R-devel from sources that are newer >>>> than (or equal to) svn revision 70632 (2016-05-19 10:59:51, see below)? >>>> >>>> I'm asking because the question is open if these should be >>>> "back ported" to R 3.3.0 patched or not. >>>> >>>> Best regards, >>>> Martin >>>> >>>>>>>>> Martin Maechler >>>>>>>>> on Thu, 19 May 2016 11:02:48 +0200 writes: >>>> >>>>>>>>> >>>>>>>>> on Wed, 18 May 2016 15:03:31 -0700 writes: >>>> >>>>>>> Readline <= 6.2 shouldn't require the SIGWINCH patch, so >>>>>>> if older versions have trouble finding rl_resize_terminal >>>>>>> then you could wrap a macro around that part. >>>> >>>>>> I find python related patches that use >>>> >>>>>> #ifdef HAVE_RL_RESIZE_TERMINAL >>>> >>>>>> so they must have configured for that. We could and >>>>>> probably should do the same, but as a Linux_only guy >>>>>> currently (even basically only one flavor of Linux), I'd >>>>>> appreciate others to produce code for that. >>>> >>>>> Actually that was easy (in hindsight.. I took too long!) >>>>> enough, so I've now committed >>>> >>>>> >>>>> r70632 | maechler | 2016-05-19 10:59:51 +0200 (Thu, 19 May 2016) | 1 line >>>>> Changed paths: >>>>> M configure >>>>> M configure.ac >>>>> M src/include/config.h.in >>>>> M src/unix/sys-std.c >>>> >>>>> check for rl_resize_terminal() now >>>>> >>>> >>>>> ... and Keith should even not see the warning anymore >>>>> (nor Peter the error, when compiling using readline 5.x instead of >>>>> 6.[23]). >>>> >>>> >>>> [...] >> >>> -- >>> Peter Dalgaard, Professor, >>> Center for Statistics, Copenhagen Business School >>> Solbjerg Plads 3, 2000 Frederiksberg, Denmark >>> Phone: (+45)38153501 >>> Office: A 4.23 >>> Email: pd@cbs.dk Priv: pda...@gmail.com >> __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] OpenBLAS in everyday R?
On point 1): The standard approach seems to favor the reference BLAS for reasons other than speed. For example, vecLib, Apple's multi-threaded BLAS library, is not the default choice for macOS binaries due to concerns about 'precision'. See: https://cloud.r-project.org/bin/macosx/RMacOSX-FAQ.html#Whic h-BLAS-is-used-and-how-can-it-be-changed_003f This doesn't appear to be Mac- or vecLib-specifc. R-Core seem wary of non-reference BLAS implementations for several reasons: 'External BLAS implementations often make less use of extended-precision floating-point registers and will almost certainly re-order computations. This can result in less accuracy than using the internal BLAS, and may result in different solutions, e.g. different signs in SVD and eigendecompositions.' https://cran.r-project.org/doc/manuals/r-devel/R-admin.html#BLAS I'm not sure how pervasive a problem this is, though. Keith On Sat, Dec 16, 2017 at 4:01 PM, Dirk Eddelbuettel wrote: > > Kenny, > > On 17 December 2017 at 09:28, Kenny Bell wrote: > | Hi R-devel list, > | > | OpenBLAS is readily available for unix-likes: > | > | https://cloud.r-project.org/web/packages/gcbd/vignettes/gcbd.pdf > > Please consider re-reading this vignette of mine. BLAS is an interface, > OpenBLAS is but one implementation. R has allowed you to switch between > different implementations for a long time (if you used a shared library > build), and illustrating / measuring the possible performance differences > is > the whole point of the gcbd benchmarking package. > > | However, my questions are: > | > | 1) Would R-devel consider using OpenBLAS for the main distribution of R > for > | all platforms including Windows? > | 2) If so, would R-devel set the default multi-thread level to the number > of > | (real) cores on a machine? > > It's complicated. If you fork at the process-level (with package parallel > or > one of the many other mechansim) and then also used multi-threaded BLAS you > can starve yourself for resources quickly. > > | My sense is there're a lot of wasted resources on laptops and personal > | desktops around the world that could be utilised by such a switch. I > | believe most unix-like users don't know about OpenBLAS and are blissfully > | ignorant of the available speed gains. It seems to be quite difficult > for a > | typical Windows user to get this done today. > > Many things a developer / power-user would do are very difficult on > Windows. It is one of the charms of the platform. On the other hand you do > get a few solitaire games so I guess everybody is happy. > > Dirk > > | Thanks heaps, > | Kenny > | > | [[alternative HTML version deleted]] > | > | __ > | R-devel@r-project.org mailing list > | https://stat.ethz.ch/mailman/listinfo/r-devel > > -- > http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Is the tcltk failure in affylmGUI related to R bug 15957
I maintain the package affylmGUI. It works when installed on many
previous versions of R. I have today tested exactly the same code under
R-2.15.3, R-3.0.2, R-3.1.0, R-3.1.1, R-3.1.2 and R-devel.
I have also tested the versions of affylmGUI downloaded by biocLite for
each version of R and the same result applies.
I have no errors under 2.15.3, 3.0.2, 3.1.0 and 3.1.1. The following
error occurs under 3.1.2 and R-devel.
I run affylmGUI and read a targets file which then causes affylmGUI to
read the specified cel files. On attempting to display the RNA targets
file in a Tk window using the "RNA Targets" option from the "RNA
Targets" Menu item and the following errors occur:
Error text box 1: Error in eval(substitute(expr),enclos):could not find
function "<-" - pressed OK
Following error text box: Error in paste("::RTcl",n,sep=""): object 'n'
not found - pressed OK
Following error text box: Error in assign(name, NULL, environ = I$env):
object 'name' not found - pressed OK
Following error text box: Error in paste("set",name, "(0,0)\"\"",sep=
""):object 'name' not found - pressed OK
This then results in an unfilled Tk window.
I am testing on a Windows 7, 64 bit environment. My sessionInfo is:
R version 3.1.2 (2014-10-31)
Platform: x86_64-w64-mingw32/x64 (64-bit)
locale:
[1] LC_COLLATE=English_Australia.1252 LC_CTYPE=English_Australia.1252
LC_MONETARY=English_Australia.1252
[4] LC_NUMERIC=C LC_TIME=English_Australia.1252
attached base packages:
[1] stats4parallel tcltk stats graphics grDevices
utils datasets methods base
other attached packages:
[1] affylmGUI_1.40.0 AnnotationDbi_1.28.1 GenomeInfoDb_1.2.4
IRanges_2.0.1 S4Vectors_0.4.0
[6] xtable_1.7-4 R2HTML_2.3.1 affyPLM_1.42.0
preprocessCore_1.28.0 gcrma_2.38.0
[11] tkrplot_0.0-23affyio_1.34.0 BiocInstaller_1.16.1
affy_1.44.0 Biobase_2.26.0
[16] BiocGenerics_0.12.1 limma_3.22.3
loaded via a namespace (and not attached):
[1] Biostrings_2.34.1 DBI_0.3.1 RSQLite_1.0.0 splines_3.1.2
XVector_0.6.0 zlibbioc_1.12.0
I think the relevant code that is resulting in the error is generated by
this function in main.R:
tclArrayVar <- function(){
Try(n <- evalq(TclVarCount <- TclVarCount + 1, .TkRoot$env))
Try(name <- paste("::RTcl", n,sep = ""))
Try(l <- list(env = new.env()))
Try(assign(name, NULL, envir = l$env))
Try(reg.finalizer(l$env, function(env) tcl("unset", ls(env
Try(class(l) <- "tclArrayVar")
Try(.Tcl(paste("set ",name,"(0,0) \"\"",sep="")))
l ### Investigate this line KS
} #end of tclArrayVar <- function()
This code is lines 877-886 in main.R
Despite the un-investigated last line in this function, it works fine in
earlier versions of R as described above.
The original programmer has left our division some years ago and I have
maintained the code since then. Consequently my understandings as to why
the code was written the way it was is somewhat limited, so I have not
touched anything unless it was broken.
My question is, do I need to do something with the affylmGUI code? I'd
appreciate some advice if so.
Is this failure related to bug 15957
(https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=15957) that Duncan
fixed on 2014-09-08.
cheers,
Keith
==
Keith Satterley
Bioinformatics Division
The Walter & Eliza Hall Institute of Medical Research
Melbourne, Victoria, Australia
==
__
The information in this email is confidential and intend...{{dropped:4}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Is the tcltk failure in affylmGUI related to R bug 15957
Thanks Peter and Dan for your replies.
After learning a bit more about tcltk and environments etc. I have replaced
Try(n <- evalq(TclVarCount <- TclVarCount + 1, .TkRoot$env))
with
Try(n <- .TkRoot$env$TclVarCount <- .TkRoot$env$TclVarCount +1L)
as you suggest.
It now works for both R-3.1.1 and R-3.1.2+
(My understanding is that the Try function is there to put a GUI box around the
error messages.)
I shall update affylmGUI versions accordingly soon.
cheers
Keith
PS> I have also changed the Depends in DESCRIPTION to Imports and added an
import statement to the NAMESPACE file which is independent of this problem.
Consequently removed Require("tkrplot") statements as no longer needed.
- peter dalgaard wrote:
> Seems unlikely that that particular bug is involved. I seem to recall some
> change related to inadvertent variable capture in .TkRoot$env (?). At any
> rate, we currently have
>
> > parent.env(.TkRoot$env)
>
>
> which used to be
>
> > parent.env(.TkRoot$env)
>
>
> as a result, this won't work any more because R_EmptyEnv has no operators and
> functions in it:
>
> > evalq(x <- 1, .TkRoot$env)
> Error in eval(substitute(expr), envir, enclos) :
> could not find function "<-"
>
> and consequently, you conk out at
>
>Try(n <- evalq(TclVarCount <- TclVarCount + 1, .TkRoot$env))
>
> which presumably needs to be recoded in the same way as the current code in
> tclVar():
>
> > tclVar
> function (init = "")
> {
> n <- .TkRoot$env$TclVarCount <- .TkRoot$env$TclVarCount +
> 1L
> name <- paste0("::RTcl", n)
> l <- list(env = new.env())
> assign(name, NULL, envir = l$env)
> reg.finalizer(l$env, function(env) tcl("unset", ls(env)))
> class(l) <- "tclVar"
> tclvalue(l) <- init
> l
> }
>
> (The whole thing looks a bit odd: Your function clones a fair bit of tclVar,
> wrapping each line in Try() for no apparent reason (or?), with the apparent
> purpose of doing something that seems quite similar to what tclArray()
> already does...)
>
> -pd
>
>
> > On 14 Jan 2015, at 06:50 , Keith Satterley wrote:
> >
> > I maintain the package affylmGUI. It works when installed on many previous
> > versions of R. I have today tested exactly the same code under R-2.15.3,
> > R-3.0.2, R-3.1.0, R-3.1.1, R-3.1.2 and R-devel.
> >
> > I have also tested the versions of affylmGUI downloaded by biocLite for
> > each version of R and the same result applies.
> >
> > I have no errors under 2.15.3, 3.0.2, 3.1.0 and 3.1.1. The following error
> > occurs under 3.1.2 and R-devel.
> >
> > I run affylmGUI and read a targets file which then causes affylmGUI to read
> > the specified cel files. On attempting to display the RNA targets file in a
> > Tk window using the "RNA Targets" option from the "RNA Targets" Menu item
> > and the following errors occur:
> >
> > Error text box 1: Error in eval(substitute(expr),enclos):could not find
> > function "<-" - pressed OK
> > Following error text box: Error in paste("::RTcl",n,sep=""): object 'n' not
> > found - pressed OK
> > Following error text box: Error in assign(name, NULL, environ = I$env):
> > object 'name' not found - pressed OK
> > Following error text box: Error in paste("set",name, "(0,0)\"\"",sep=
> > ""):object 'name' not found - pressed OK
> >
> > This then results in an unfilled Tk window.
> >
> > I am testing on a Windows 7, 64 bit environment. My sessionInfo is:
> >
> > R version 3.1.2 (2014-10-31)
> > Platform: x86_64-w64-mingw32/x64 (64-bit)
> > locale:
> > [1] LC_COLLATE=English_Australia.1252 LC_CTYPE=English_Australia.1252
> > LC_MONETARY=English_Australia.1252
> > [4] LC_NUMERIC=C LC_TIME=English_Australia.1252
> > attached base packages:
> > [1] stats4parallel tcltk stats graphics grDevices utils
> > datasets methods base
> > other attached packages:
> > [1] affylmGUI_1.40.0 AnnotationDbi_1.28.1 GenomeInfoDb_1.2.4
> > IRanges_2.0.1 S4Vectors_0.4.0
> > [6] xtable_1.7-4 R2HTML_2.3.1 affyPLM_1.42.0
> > preprocessCore_1.28.0 gcrma_2.38.0
> > [11] tkrplot_0.0-23affyio_1.34.0 BiocInstaller_1.16.1 affy_1.44.0
> > Biobase_2.26.0
> > [16] BiocGenerics_0.12.1 limma_3.22.3
> > loaded via a namespace (and not attached):
> > [
Re: [Rd] Error when comparing two variables within a dataframe and print relevant observations
On 15/05/2015 05:35, bw1984 wrote: I'm trying to use a nested ifelse condition to compare two lines. Input: Code: Expected Output: Actual Output: Any idea what might be causing this problem? -- View this message in context: http://r.789695.n4.nabble.com/Error-when-comparing-two-variables-within-a-dataframe-and-print-relevant-observations-tp4707240.html Sent from the R devel mailing list archive at Nabble.com. I had to look at Nabble to see the detail. Even that omitted an error message: > Transfers2 <- subset(Transfers, ChangeType != "No Change")) Error: unexpected ')' in "Transfers2 <- subset(Transfers, ChangeType != "No Change"))" When I omitted the extra closing bracket it worked. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] use() might take a list of packages
"Timothy Bates" wrote in message
news:1b5e1d00-397b-429b-b20c-0fba06084...@gmail.com...
I heard that a function called use() had been mooted as being more
intuitively named than library()
If so, it might be handy if this worked
use(c("MASS","car))
currently this fails
library(c("MASS","car"))
This seems to work, and doesn't seem much effort
> sapply(c("MASS","car"), library, character.only = TRUE)
KJ
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Rcmd_environ and R_LIBS_{USER,SITE}
No reply in a number of hours, so here is a suggestion from ignorance :-} ?Startup refers to a number of other "site and user files to process for setting environment variables" but not to Rcmd_environ. The contents of $R_HOME/etc/Rcmd_environ seem to reflect (some of) the contents of (some) other files. I have similar lines (defining library paths) in $R_HOME/etc/Renviron.site Is it correct to directly edit Rcmd_environ or should it be modified only via other files? (A genuine question). On 17/10/2012 15:59, Dirk Eddelbuettel wrote: Is there a fundamental reason why I cannot set either one of ## add local library path -- doesn't work either R_LIBS_USER="c:/opt/R-library" R_LIBS_SITE="c:/opt/R-library" in $R_HOME/etc/Rcmd_environ even though I can seemingly set other things here? It breaks "R CMD check" for me as I prefer NOT to install packages in a versioned path. FWIW, defaulting to a versioned path is (to this no-longer-bemused user) as much a permenent R bug (on Windoze) as the default installation into a path with spaces. Dirk __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Windows Laptop specification query
I've read some postings back in 2002/2006 about running R on multiple core CPUs. The answer was basically separate processes work fine, but parallelization needs to be implemented using snow/rmpi. Are the answers still the same? I ask because we are about to order a laptop running Windows for a new staff member. Some advice on the following would be helpful. It will be ordered with Vista, with a free upgrade to Windows 7. It will have 8GB of memory A quad core CPU costs about AUD$1100 more than the fastest (Intel T9900-6M Cache, 3.06 GHz) dual core CPU. I'm wondering if there is value in ordering the quad core. We are looking at a time frame of 3-4 years. Is anyone aware of near future plans to implement some form or parallelization that would more or less be hidden from the normal user? It is anticipated that analysis of Next Gen sequence data will be important. I've read the Windows FAQ about running R under Vista. We will probably start with Vista. I've read some posts in R-devel indicating people are running R under Windows 7. Is it safe to assume that R will run under Windows 7 after it is released? We are hoping to make use the 8GB of memory. Am I right in assuming that when the 64 bit version of Windows 7 is available, it will allow R users to make good use of the 8GB of memory. Does this happen under the current higher end versions of 64 bit Vista? cheers, Keith ==== Keith Satterley Bioinformatics Division The Walter and Eliza Hall Institute of Medical Research Parkville, Melbourne, Victoria, Australia __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Windows Laptop specification query
Thanks everyone for advice on this matter.
I've been asked to report our conclusion.
We have decide to order a duo processor(3.06GHz) Dell Precision 4400
laptop with 8GB memory and 500GB disk.
It will be running Vista 64 bit to begin with, moving over to Windows 7
once a little experience is gained with it elsewhere.
We will leave the multi CPU use of R to our larger unix servers.
cheers,
Keith
Prof Brian Ripley wrote:
The answer to (1) is in the rw-FAQ, so see
library(fortunes)
fortune('WTFM')
On Mon, 28 Sep 2009, Corrado wrote:
1) Would a package compiled for Windows 32bit run on Windows 64 bit
and use
the extended memory or not?
2) As for buying a performant laptop for R, I bought a Dell M6300 mobile
workstation which is actually portable, and installed Kubuntu 904 64 bit
alongside the standard windows installation. When I run R I only use
it in
Linux and access the data in Windows through the file system. If I
need to run
Office because some one else is sending me document to correct, I
have installed
Windows XP Pro SP3 in a virtual machine using Virtual Box, which runs
very
fairly on the M6300, and can switch it on and off whenever I need
(booting on
the virtual machine is matter of few seconds). This setup allows for
running
64 bit R on Linux (eventually compiled with -O3 -march=native by the
way, if
you feel like experimenting) which is more performant and used the
memory more
efficiently, without loosing the interacting with your windows based
colleagues.
The virtual machine can go full screen at the click of a mouse :D and
it looks
as if you were using a native Windows machine. You can install all
software
and network clients on the virtual machine. I have not booted Windows
for ages
I have been using this machine fort he last 18 months. The dual
core
works great (I chose the top processor to run simulations when I am
not in the
office), and in Linux you can control the CPU frequency. The new one
which
substitutes the M6300 is the M6400 and I would go for that possibly
(Linux
supported):
http://www1.euro.dell.com/uk/en/business/Laptops/workstation-precision-m6400-
cov/pd.aspx?refid=workstation-precision-m6400-cov&s=bsd&cs=ukbsdt1
PS: I apologise for the question on memory management but I have
never used R
on Windows but some free spirit decided to release a package only for
Windows
and only pre compiled (no sources) and I need to use it to compare
(Sorry
for the harsh comment and the rant , but I am not sure it is really
fair to
use an open source packages and programming languages for you daily
work and
make money out of it, and the first time you release something you
release it
crappy and closed source even if it is legal and allowed of
course :
( )
On Monday 28 September 2009 09:16:23 Prof Brian Ripley wrote:
On Mon, 28 Sep 2009, Sean O'Riordain wrote:
Good morning Keith,
Have a look at
http://cran.r-project.org/bin/windows/base/rw-FAQ.html#There-seems-to-be-
a-limit-on-the-memory-it-uses_0021
The short answer is that "it depends"...
a) memory is limited under windows
Yes, but 64-bit builds can be used on Windows -- that needs commercial
compilers and there are commercial vendors of such builds.
Even with the CRAN binary, a 64-bit version of Windows offers double
the memory over a (vanilla) 32-bit version.
b) R is essentially a serial program - HOWEVER it depends what you're
actually doing - if you're working with large matrices then there are
parallel versions of BLAS that can be used... On a multi-core windows
machine with lots of memory you can of course run up multiple
copies of R
and run each independently
There are several packages that parallelize their computations with
MPI etc, and others that help with parallelization (papply, foreach,
gputools, ). And apart from Rmpi/rpvm/snow there is also
'multicore', but not on Windows. See the R-sig-hpc list for follow up
on such issues.
As for Vista vs Windows 7, this is not the right list but Windows 7
behaves just like a version of Vista as far as we have explored it
(and the current rw-FAQ includes it and Server 2008 in the Vista
section).
Many of us have bought dual quad-core servers in the last year or so:
that includes Uwe Ligges' winbuilder machine. I suspect most of the
usage is separate R jobs running simultaneously: certainly that is the
case in my dept (where there are at least 6 8-core servers running R
jobs).
Kind regards,
Sean
On Mon, Sep 28, 2009 at 4:40 AM, Keith Satterley
wrote:
I've read some postings back in 2002/2006 about running R on multiple
core CPUs. The answer was basically separate processes work fine, but
parallelization needs to be implemented using snow/rmpi. Are the
answers
still the same?
I ask because we are about to order a laptop running Windows for a
new
staff member. Some advice on the following would be helpful.
It will be ordered
Re: [Rd] Lightweight 'package' idea.
e such file it opens a \code{file.choose} dialog
to choose a single file of any type. \cr
If the single file is of type \file{.Rd} it is translated to a
correspondingly named \file{.html} file in the same folder, which is opened
by the operating system's file associations. \cr
If the file chosen is of any other type it is opened by the operating
system's file associations.} }}
\value{ \describe{
\item{\code{loadDir}}{ \code{invisible(.Package)}, scalar, character}
\item{\code{reloadDir}}{ \code{invisible(.Package)}, scalar, character}
\item{\code{help.'.Package'}}{\code{invisible}, scalar, character; file
opened (the \file{.html} file if a \file{.Rd} file was chosen)}}
}
\references{
%% ~put references to the literature/web site here ~
}
\author{
%% ~~who you are~~
}
\note{
%% ~~further notes~~
}
%% ~Make other sections like Warning with \section{Warning }{} ~
\seealso{
%% ~~objects to See Also as \code{\link{help}}, ~~~
}
\examples{
\dontrun{
loadDir() navigating to 'Server02\\stats\\R\\CBRIutils' adds the
package CBRIutils
then
reload("CBRIutils") re-sources all '\\R\\*.R' files.
and
help.CBRIutils(item) converts '\\man\\item.Rd' to '\\man\\item.html' which
it opens in the default web browser.}}
% Add one or more standard keywords, see file 'KEYWORDS' in the
% R documentation directory.
\keyword{ ~kwd1 }
\keyword{ ~kwd2 }% __ONLY ONE__ keyword per line
---
No guarantees or warranties of any kind, but perhaps people will find it
useful.
I'm sure real R experts will be able to improve it
Regards,
Keith J
"Gabor Grothendieck" wrote in message
news:971536df0908210532k1152976al404b94a230f98...@mail.gmail.com...
That's nifty. Perhaps it could look into
/foo/bar/baz/lib1/*/R
in which case one could simply place source
packages in /foo/bar/baz/lib1
In fact it would be nice if R had built into it some way
of running code in source packages possibly with
degraded functionality to ease development, i.e.
if one added /foo/bar/baz/lib1 to .libPaths and if xx
were a source package in /foo/bar/baz/lib1 then
one could use library(xx) and use xx functions directly,
possibly with degraded functionality, e.g. no help files.
On Fri, Aug 21, 2009 at 8:03 AM, Barry
Rowlingson wrote:
> I'm often wanting to develop functions whilst manipulating data. But I
> don't want to end up with a .RData full of functions and data. It
> might be that I have functions that are re-usable but not worth
> sticking in a package.
>
> So I've tried to come up with a paradigm for function development
> that more closely follows the way Matlab and Python do it (partly
> inspired by a confused Matlab convert over on R-help).
>
> My requirements were thus:
>
> * .R files as the master source for R functions
> * Don't see the functions in ls()
> * After editing R, make it easy to update the definitions visible to
> R (unlike rebuilding and reloading a package).
>
> So I wrote these two in a few mins:
>
> loadDir <- function(dir){
> e = attach(NULL,name=dir)
> assign("__path__",dir,envir=e)
> reloadDir(e)
> e
> }
>
> reloadDir <- function(e){
> path = get("__path__",e)
> files =
> list.files(path,".R$",full.names=TRUE,recursive=TRUE,ignore.case=TRUE)
> for(f in files){
> sys.source(f,envir=e)
> }
> }
>
> Usage is something like:
>
> lib1 = loadDir("/foo/bar/baz/lib1/")
>
> - it creates a new environment on the search path and sources any .R
> it finds in there into that environment. If you edit anything in that
> directory, just do reloadDir(lib1) and the updated definitions are
> loaded. It's like python's "import foo" and "reload(foo)".
>
> Sourcing everything on any change seems a bit wasteful, but until R
> objects have timestamps I can't think of a better way. Hmm, maybe my
> environment could keep a __timestamp__ object... Okay, this is getting
> less simple now...
>
> So anyway, have I done anything wrong or stupid here, or is it a
> useful paradigm that seems so obvious someone else has probably done
> it (better)?
>
> Barry
>
> __
> 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] Lightweight 'package' idea.
Following up on my own post of 13th,
Someone pointed out that I was MS Windows dependent. I've tried to correct
that, but I'm in a Windows only environment so I can't check.
I've also tried to make a few other "improvements". The result is below.
No guarantees or warranties of any kind, but perhaps people will find it
useful.
It now reasonably meets my needs so I'm not planning to do any more work on
it. I'm sure real R experts will be able to improve it..
Regards,
Keith J
"Keith Jewell" wrote in message
news:hikudu$37...@ger.gmane.org...
> Going back a few months
> I also thought "it would be nice if R had built into it some way of
> running code in source packages possibly with degraded functionality to
> ease development"
> so building on Barry Rowlingsons start I came up with this:
> ---
## R code starts <<<<<<<<<<<<<<<<<<<<<<<
require(tools, quietly=TRUE) # for Rd2HTML
require(tcltk, quietly=TRUE) # for tk_choose.dir and tk_choose.files
# load an unbuilt package
loadDir <- function(Root = tk_choose.dir(getwd())){
Package = basename(Root) # package name defined by directory name
while(sum(search()==Package)>0) detach(pos=which(search()==Package)[1])
# if already attached, detach
attach(NULL, name=Package) # attach empty environment
assign(".Root.loadDir", Root, pos=Package) # insert Root into Package
assign(".Package.loadDir", Package, pos=Package) # insert package name
# use the reloadDir function to populate the environment
reloadDir(Package)
invisible(Package) # invisibly return .Package name
}
# reload a previously loaded package (by default the most recently loaded)
reloadDir <- function(Package = .GlobalEnv) {
Root <- get(".Root.loadDir", envir=as.environment(Package),
mode="character") # retrieve Root
Package <- get(".Package.loadDir", envir=as.environment(Package),
mode="character") # and package name
for (f in list.files(path=file.path(Root , "R"), # path is
.Root.loadDir/R/
pattern=".R$",full.names=TRUE,recursive=TRUE,ignore.case=TRUE)) #
file type = .R
sys.source(f, envir=as.environment(Package)) # source all such
files into .Package
invisible(Package)} # invisibly return package
# display help from previously loaded package (by default most recently
loaded)
help.loadDir <- function(subj="", Package=.GlobalEnv){# default subject
is blank, package is first found
.Root <- get(".Root.loadDir", envir=as.environment(Package),
mode="character") # get file path
.Package <- get(".Package.loadDir", envir=as.environment(Package),
mode="character") # get package name
if (substitute(subj)=="") subj = "*" else subj <- substitute(subj) # get
*subj*' as character
hfile <- list.files(path=file.path(.Root, "man"), # path is .Root/man/
pattern=paste(subj,"Rd$", sep="."), # file = subj.Rd
full.names=TRUE,recursive=TRUE,ignore.case=TRUE) # list of matching
files
if (length(hfile) != 1) # if not exactly one file, choose one
hfile <- tk_choose.files(file.path(.Root, "man", paste(subj,"Rd",
sep=".")), multi=FALSE)
if(hfile != "") { # if exactly one file, open it
if(length(grep(".Rd$", hfile, ignore.case=TRUE)) ==1) { # if it's an Rd
file,
outfile <- sub("Rd$", "html", hfile, ignore.case=TRUE) # name of
corresponding html
out.mod <- file.info(outfile)[,"mtime"] # if html absent or needs
updating
if (is.na(out.mod)||file.info(hfile)[,"mtime"] > out.mod)
tools::Rd2HTML(hfile, outfile, .Package) # do it
hfile <- outfile} # point to html
hfile <- file.path(dirname(hfile), basename(hfile)) # needed to handle
"//server" syntax on Windows
shell.exec(shQuote(hfile))} # use operating system to open file of any
type
invisible(hfile)}# invisibly return displayed file name
## R code ends >>>>>>>>>>>>>>>>>>>>>>>>>>
% File loadDir.Rd begins <<<<<<<<<<<<<<<<<<<<<
\name{loadDir}
\title{Load an unbuilt package}
\description{Loads code from a packages \file{\\R} subdirectory}
\usage{loadDir(Root = tk_choose.dir(getwd())}
\arguments{
\item{Root}{character, scalar. The package directory (containing
subdirectories \file{\\R} and \file{\\man}). The package name
(\code{.Package.loadDir}) is taken as \code{basename(Root)}.}
}
\details{Attaches an environment at the se
Re: [Rd] How to test if R is running on a Mac
I use Sys.info()["sysname"]. It returns "Darwin" on a Mac, "Windows" on MS Windows and "Linux" on my Linux box. Is this sufficient for your needs, I'm using R-2.6.0alpha on MS Windows and 2.5.0 on Mac and Linux at the moment. cheers, Keith Satterley Bioinformatics Division The Walter and Eliza Hall Institute of Medical Research [EMAIL PROTECTED] wrote: > Send R-devel mailing list submissions to > r-devel@r-project.org > Message: 1 > Date: Wed, 19 Sep 2007 15:41:22 +0200 > From: Gorjanc Gregor <[EMAIL PROTECTED]> > Subject: [Rd] How to test if R is running on a Mac > To: "r-devel@r-project.org" > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="us-ascii" > > Hi! > > Is there any way to test if R is running on a Mac? I usually use > value of .Platform$OS.type for windows or unix, but Mac falls in the > latter group. > > Thanks, Gregor __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] work-around for debugger broken (by changed behaviour of get under R 2.8?) when functions have ... arguments
Hello all,
Sorry to trouble you, but this is a follow-up with a work-around to the
problem I posted on R-help
(http://article.gmane.org/gmane.comp.lang.r.general/136515). Is it
possible to add the work-around or some equivalent to the utils package,
please?
I think this may be related to the changed behaviour of get under R 2.8
referred to in:
http://www.nabble.com/changed-behaviour-of-%27get%27-in-2.8.0:-request-f
or-unchange-td20143510.html
I am trying to use the debugger (to resolve a bug when running with
Rscript) and have a secondary problem when functions have unused ...
Arguments which can be reduced to the following sequence:
# A script with a bug in it
options(error=quote({dump.frames("debug.dump",to.file=TRUE)}))
silly <- function(x,...){
z <- list(...)
NONEXISTENT.FUNCTION()
}
silly(1)
# and to debug it:
load("debug.dump.rda")
debugger(debug.dump)
However when I execute the debugger as follows, I cannot actually debug
the stack:
> load("debug.dump.rda")
> debugger(debug.dump)
Message: Error in silly(1) : could not find function
"NONEXISTENT.FUNCTION"
Available environments had calls:
1: silly(1)
Enter an environment number, or 0 to exit Selection: 1
Error in get(.obj, envir = dump[[.selection]]) :
argument "..." is missing, with no default
get flags this error whether I enter the code to invoke silly directly,
source a .R file or invoke with Rscript, all under SuSe linux 10.3
(sessionInfo below). I also get it if I try the debugger under Windows
Vista with R version 2.8.1.
It all works perfectly happily under any of the following conditions:
1) I rewrite the function without the "..."
2) I execute the debugger lines under R 2.7.0 (linux)
3) I actually pass a value through "..."
Unfortunately 1 and 3 are not feasible for my real code - would it be
possible to add the try fix below (or some equivalent) to debugger in
the utils package?
> sessionInfo()
R version 2.8.1 (2008-12-22)
i686-pc-linux-gnu
locale:
LC_CTYPE=en_GB.UTF-8;LC_NUMERIC=C;LC_TIME=en_GB.UTF-8;LC_COLLATE=en_GB.U
TF-8;LC_MONETARY=C;LC_MESSAGES=en_GB.UTF-8;LC_PAPER=en_GB.UTF-8;LC_NAME=
C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_GB.UTF-8;LC_IDENTIFICATI
ON=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
Thankyou,
Keith Ponting
Keith Ponting
Aurix Ltd, Malvern WR14 3SZ UK
P.S. Wrapping a try around the offending assign in debugger.look means
that I still get the error message, but am able to browse the function
calls.
I would prefer not to blank out the error message completely, to avoid
surprises when I try to access ... in the debugger via list(...), which
works when a value was passed to ... but when nothing was passed to ...
gives the message "Error: '...' used in an incorrect context", which may
be true but initially led me to conclude that I could not see ...
contents via the debugger.
debug.kmp<-function (dump = last.dump)
{
debugger.look <- function(.selection) {
for (.obj in ls(envir = dump[[.selection]], all.names = TRUE))
try(assign(.obj,
get(.obj, envir = dump[[.selection]])))
cat(gettext("Browsing in the environment with call:\n "),
calls[.selection], "\n", sep = "")
rm(.obj, .selection)
browser()
}
if (class(dump) != "dump.frames") {
cat(gettext("'dump' is not an object of class 'dump.frames'\n"))
return(invisible())
}
err.action <- getOption("error")
on.exit(options(error = err.action))
if (length(msg <- attr(dump, "error.message")))
cat(gettext("Message: "), msg)
n <- length(dump)
calls <- names(dump)
repeat {
cat(gettext("Available environments had calls:\n"))
cat(paste(1:n, ": ", calls, sep = ""), sep = "\n")
cat(gettext("\nEnter an environment number, or 0 to exit "))
repeat {
ind <- .Internal(menu(as.character(calls)))
if (ind <= n)
break
}
if (ind == 0)
return(invisible())
debugger.look(ind)
}
}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] An inconsistency in docs for file.access(base)
I was chasing a "no permission to install to directory" error message. I was
looking in the code for /R/trunk/src/library/tools/R/install.R which pointed me
to the file.access function.
On reading the help for this function, it has the following in the Details
section:
The mode value can be the exclusive or of the following values
0 test for existence.
1 test for execute permission.
2 test for write permission.
4 test for read permission.
It has the following under the Examples section:
Examples
fa <- file.access(dir("."))
table(fa) # count successes & failures
d <- dir(file.path(R.home(), "bin"))
df <- dir(file.path(R.home(), "bin"), full.names = TRUE)
d[file.access(df, 0) == 0] # all exist
d[file.access(df, 1) == 0] # some are executable, some are not
d[file.access(df, 2) == 0] # hopefully all are readable
d[file.access(df, 4) == 0] # they may or may not be writable
I presume mode = 2 is a test for writing, so could someone change the comments
around in the Examples
> sessionInfo()
R version 2.9.0 Under development (unstable) (2009-01-15 r47607)
i386-pc-mingw32
locale:
LC_COLLATE=English_Australia.1252;LC_CTYPE=English_Australia.1252;LC_MONETARY=English_Australia.1252;LC_NUMERIC=C;LC_TIME=English_Australia.1252
attached base packages:
[1] stats graphics grDevices datasets utils methods base
loaded via a namespace (and not attached):
[1] tools_2.9.0
Same situation in R2.8.1
cheers,
Keith
Keith Satterley
Bioinformatics Division
The Walter and Eliza Hall Institute of Medical Research
Parkville, Melbourne,
Victoria, Australia
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] link in base help file fails.
I run R on MS Windows. In R2.9.0dev, I type ?base to get "R help for package base" to open. I then select ".First" from the list of contents, getting a page headed: "Initialization at Start of an R Session". About half way down there is a sentence: The command-line flag --vanilla implies --no-site-file, --no-init-file, --no-restore and --no-environ. Under Windows, it also implies --no-Rconsole, which prevents loading the ‘Rconsole’ file. The last occurrence of the word Rconsole is in blue text and underlined, a link. On clicking on this link, I get a page headed "This program cannot display the webpage" with advice on "Most likely causes:" and "What you can try". Other links work satisfactorily on that page. My internet connection is working. I presume there is a problem with this Rconsole link. > sessionInfo() R version 2.9.0 Under development (unstable) (2009-03-13 r48127) i386-pc-mingw32 locale: LC_COLLATE=English_Australia.1252;LC_CTYPE=English_Australia.1252;LC_MONETARY=English_Australia.1252;LC_NUMERIC=C;LC_TIME=English_Australia.1252 attached base packages: [1] stats graphics grDevices datasets utils methods base > cheers, Keith Keith Satterley Bioinformatics Division The Walter and Eliza Hall Institute of Medical Research Parkville, Melbourne, Victoria, Australia __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Set Repositories problem in R2.4.0
In R2.4.0 when I select Set Repositories from the menu I get
> setRepositories()
Error in read.table(file = file, header = header, sep = sep, quote = quote, :
more columns than column names
The reposotories file is as installed.
> sessionInfo()
R version 2.4.0 Under development (unstable) (2006-08-14 r38872)
i386-pc-mingw32
locale:
LC_COLLATE=English_Australia.1252;LC_CTYPE=English_Australia.1252;LC_MONETARY=English_Australia.1252;LC_NUMERIC=C;LC_TIME=English_Australia.1252
attached base packages:
[1] "methods" "stats" "graphics" "grDevices" "utils" "datasets"
"base"
>
In R2.3.1 it works fine.
On checking the code for setRepositories in 2.3.1 and 2.4.0, it is identical.
With Identical repositories files I still get the error in 2.4.0.
If I insert comment.char="#" in the read.table line 2.4.0 code works. See copy
of screen output below:
> p <- file.path(R.home("etc"), "repositories")
> p
[1] "C:\\R\\R-2.4.0/etc/repositories"
> a <- read.delim(p, header = TRUE, colClasses = c(rep("character",3),
rep("logical", 4)))
Error in read.table(file = file, header = header, sep = sep, quote = quote, :
more columns than column names
> a <- read.delim(p, header = TRUE, colClasses = c(rep("character",3),
rep("logical", 4)),comment.char="#")
> a
menu_nameURL default source
win.binary mac.binary
CRAN CRAN @CRAN@TRUE TRUE
TRUE TRUE
CRANextra CRAN (extras) http://www.stats.ox.ac.uk/pub/RWinTRUE FALSE
TRUE FALSE
BioC Bioconductorhttp://www.bioconductor.org FALSE TRUE
TRUE FALSE
Omegahat Omegahat http://www.omegahat.org/R FALSE TRUE
TRUE FALSE
>
Did I hear that there was a bug in read.table in R2.4.0?
Is this comment.char parameter the correct solution?
cheers,
Keith
Keith Satterley
Bioinformatics Division
The Walter and Eliza Hall Institute of Medical Research
Parkville, Melbourne,
Victoria, Australia
ph: +61 3 9345 2628
mob:+61 4 2570 0419
email:[EMAIL PROTECTED]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] CRAN task views work only once per session (PR#9330)
Thankyou to those who have replied to this thread.
I have now reproduced similar effects in a way which does not directly
involve CRAN task views. (I have also reproduced the original problem on
a different machine within
our site and using a different mirror.)
The following sequence of commands works repeatedly within plain Rterm
(actually running under XEmacs) on Windows XP:
x<-url("http://www.sourcekeg.co.uk/cran/src/contrib/Views.rds",open="rb";
);
showConnections()
.readRDS(x);
showConnections()
close(x)
showConnections()
However under RGui on the same system, second and subsequent attempts
time out in .readRDS (see session log below) and note that although the
connection is shown as open immediately before the second .readRDS call,
it is shown as closed immediately after that (failing) call.
I wonder whether something in RGui is holding on to connections after
they have been closed. Even while .readRDS is timing out in one RGui
session, I can run that sequence of calls in plain Rterm or (once!) in
another RGui session without problems, which I hope eliminates the
possibility that it is our company firewall or something else on my PC
holding on to the connection in some way.
-- session log starts
R version 2.4.0 (2006-10-03)
Copyright (C) 2006 The R Foundation for Statistical Computing
ISBN 3-900051-07-0
R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.
Natural language support but running in an English locale
R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.
Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.
>
x<-url("http://www.sourcekeg.co.uk/cran/src/contrib/Views.rds",open="rb";
);
> showConnections()
description class mode
text
3 "http://www.sourcekeg.co.uk/cran/src/contrib/Views.rds"; "url" "rb"
"binary"
isopen can read can write
3 "opened" "yes""no"
> .readRDS(x);
> showConnections()
descriptionclass
mode
3 "gzcon(http://www.sourcekeg.co.uk/cran/src/contrib/Views.rds)" "gzcon"
"rb"
text isopen can read can write
3 "binary" "opened" "yes""no"
> close(x)
> showConnections()
description class mode text isopen can read can write
>
x<-url("http://www.sourcekeg.co.uk/cran/src/contrib/Views.rds",open="rb";
);
> showConnections()
description class mode
text
3 "http://www.sourcekeg.co.uk/cran/src/contrib/Views.rds"; "url" "rb"
"binary"
isopen can read can write
3 "opened" "yes""no"
> .readRDS(x);
Error in .readRDS(x) : connection is not open
In addition: Warning message:
InternetOpenUrl failed: 'The operation timed out'
> showConnections()
description class mode text isopen can read can write
> close(x)
> showConnections()
description class mode text isopen can read can write
>
x<-url("http://www.sourcekeg.co.uk/cran/src/contrib/Views.rds",open="rb";
);
> showConnections()
description class mode
text
3 "http://www.sourcekeg.co.uk/cran/src/contrib/Views.rds"; "url" "rb"
"binary"
isopen can read can write
3 "opened" "yes""no"
> .readRDS(x);
Error in .readRDS(x) : connection is not open
In addition: Warning message:
InternetOpenUrl failed: 'The operation timed out'
> showConnections()
description class mode text isopen can read can write
> close(x)
> showConnections()
description class mode text isopen can read can write
>
> sessionInfo()
R version 2.4.0 (2006-10-03)
i386-pc-mingw32
locale:
LC_COLLATE=English_United Kingdom.1252;LC_CTYPE=English_United
Kingdom.1252;LC_MONETARY=English_United
Kingdom.1252;LC_NUMERIC=C;LC_TIME=English_United Kingdom.1252
attached base packages:
[1] "methods" "stats" "graphics" "grDevices" "utils"
"datasets"
[7] "base"
>
-- session log ends
If I remove the .readRDS(x) call, there is no problem - the following
command sequence does
Re: [Rd] CRAN task views work only once per session (PR#9330)
> -Original Message- > From: Prof Brian Ripley [mailto:[EMAIL PROTECTED] > Sent: 06 November 2006 11:42 > To: Keith Ponting > Cc: r-devel@r-project.org > Subject: Re: [Rd] CRAN task views work only once per session (PR#9330) > > I think the following item in NEWS for R-patched may be relevant: > > o load()ing from a connection had a logic bug in when it closed > the connection. (PR#9271) > > so please try R-patched. R-patched runs the offending code repeatedly without complaint (and my original problem with ctv available.views is also solved) so I will look forward to the next release. Thankyou for your time (and to you and all responsible for R itself!). Keith Ponting __ This email has been scanned by the MessageLabs Email Security System. For more information visit http://www.virtual-email.net/messagelabs.htm __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
