Re: [Rd] url, readLines, source behind a proxy
Thanks Henrik for the work around. It worked perfectly and save me lots of check time. Renaud -- Renaud Gaujoux Computational Biology - University of Cape Town South Africa On 24/04/2012 17:57, Henrik Bengtsson wrote: Looking at the source code (src/library/tools/R/check.R and src/library/tools/R/QC.R), I found that... WORKAROUND: You can trick 'R CMD check' to quickly skip the "check_package_CRAN_incoming" test by providing it with invalid URLs to repositories by setting system environment '_R_CHECK_XREFS_REPOSITORIES_' to a non-empty URL. For example: % export _R_CHECK_XREFS_REPOSITORIES_="invalidURL" % R CMD check --as-cran ... gives: * checking CRAN incoming feasibility ...NB: need Internet access to use CRAN incoming checks OK /Henrik On Tue, Apr 24, 2012 at 5:46 AM, Renaud Gaujoux wrote: On 23/04/2012 17:39, Prof Brian Ripley wrote: On 18/04/2012 16:04, Joshua Ulrich wrote: Hi Renaud, On Wed, Apr 18, 2012 at 12:22 AM, Renaud Gaujoux wrote: Hi Henrik, Could anybody behind a proxy check if the issue can be reproduced? My proxy is in fact provided by cntml, which acts as a local proxy that takes care of tricky authentication protocols with the actual university proxy, not natively supported by my system (Ubuntu). Anybody in this case? I can replicate this on a WinXP system, where I normally have to use the --internet2 flag to get internet access through a proxy. ?download.file has a section on "Setting Proxies", which describes how to use environment variables to set proxy information. Setting http_proxy='http://my.proxy.com/' was enough for me to get R CMD check to run successfully with the --as-cran flag. I guess that the simplest way on Windows is to ensure that --internet2 is set. In R-patched there is a new environment variable R_WIN_INTERNET2 which lets you do that (set it in ~/.R/check.Renviron). [Setting proxies is so 20th century -- even moderately competent sysadmins worked out how to use transparent caching proxies ca 1995. Which is why the R developers give it a low priority.] I completely understand the low priority -- fast-illimited-internet based -- point of view. I wish I could live without such a fussy proxy, but I have not much choice. I like to understand why things work and do not work though. Is there any special feature my proxy should have to allow readLines/source to correctly read remote data? What makes its access different from wget? Thank you for your insights on this. Thanks. Renaud Best, -- Joshua Ulrich | FOSS Trading: www.fosstrading.com R/Finance 2012: Applied Finance with R www.RinFinance.com On Tue, 17 Apr 2012, Henrik Bengtsson wrote: On Tue, Apr 17, 2012 at 1:01 AM, Renaud Gaujoux wrote: Hi, when I run R CMD check with flag --as-cran, the process hangs at stage: * checking CRAN incoming feasibility ... Doesn't it time-out eventually? I'm not behind a proxy but when I've been running 'R CMD check' whenon very poor 3G connection, it had eventually timed out. /Henrik I am pretty sure it is a proxy issue. I looked at the check code in the tools package and it seems that the issue is in the local function `.repository_db()` (defined in `tools:::.check_package_CRAN_incoming()`), which eventually calls `url()` with argument open="rb", that hangs probably because it does not use the proxy settings. I had a similar issue with `source()`, which apparently uses internal network functions (not as download.file), but is supposed to work behind a proxy (correct?). Does anybody else have this problem? I was wondering if there is a way around, as I would like to be able to use --as-cran for my checks. Thank you. Renaud -- Renaud Gaujoux Computational Biology - University of Cape Town South Africa __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Compiling R on Windows XP - Rgui crashes yet Rterm works
Hello.
I am trying to build R on Windows. It appears that my build passes the various
"make checks" (unless I missed some error) and running Rterm seems to work fine
whereas Rgui has an immediate error stating "
AppName: rgui.exe AppVer: 2.150.58871.0 ModName: rzlib.dll
ModVer: 0.0.0.0 Offset: a9e5
The taskbar still works, but the console window has nothing in it, and trying
to open a script drops me back to Windows.
Even though it seemingly passing make check-all, I ran 'testInstalledBasic
("both")' in the terminal and received the same error that was addressed here
in 2010 and was
not addressed here in 2011
: that primitives
fail on >=.
I'm not certain if this affects anything, as in Rterm, the >= comparison works
fine (4 >= 5 returns FALSE and 4 >= 1 returns TRUE).
Be that as it may, it would be very helpful to find out what would cause the
compiled R to have Rgui not work properly yet pass all the checks? I'd rather
use the gui than the terminal, for what it is worth.
If it helps, I have been using the following:
Tarball - R-2.15.0.tar.gz
Rtools - 2.15
CYGWIN 1.7 already installed (for ATLAS) so Rtools CYGWIN dlls NOT
installed
Tcl/tk, libjpeg, libpng, libtiff all installed
cairo-current-win.tar.gz
The only other change I made was to set EOPTS=-march=corei7 as the GCC included
in the toolchain in 4.6.3 which recognizes the i7 (as opposed to Cygwin which
is using 4.5.3 and only recognizes the core2).
My computer is a Lenovo W520 with a Core i7 2760QM running Windows XP
Professional.
If there is any other information that would be helpful in uncovering why this
is happening, please let me know.
Thank you very much,
Avraham Adler
PS: Copying the compiled Rblas.dll over to my regular R install (binary from
the CRAN) seems to work just fine and provides a significant speedup in matrix
operations in the few tests that I have done.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Can two RConnection's interact with one another ?
Hi , Can two R connections(may be instantiated on the same Rserve Server or on different servers) communicate with each other ? is something like JAVA RMI is possible between two R sessions thanks sanre6 -- View this message in context: http://r.789695.n4.nabble.com/Can-two-RConnection-s-interact-with-one-another-tp4622951.html Sent from the R devel mailing list archive at Nabble.com. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] file 2 is not in sorted order error building unsuffered consequences
On Tue, May 8, 2012 at 9:35 AM, Duncan Murdoch wrote: > This time it was a similar error on a different file. Now fixed. Works wonderfully now, thank you so much, Duncan! > > Duncan Murdoch > > > On 08/05/2012 11:20 AM, Joshua Wiley wrote: >> >> On Tue, May 8, 2012 at 3:48 AM, Duncan Murdoch >> wrote: >> > On 12-05-08 1:46 AM, Joshua Wiley wrote: >> >> >> >> Hi All, >> >> >> >> I just downloaded the source tar ball (Revision: 59324 Last Changed >> >> Date: 2012-05-07) and tried to compile on a Win x64 system. I am >> >> using Rtools version 2.15.0.1919. The only change I make is changing >> >> MkRules.dist -> MkRules.local and setting Multi=64 I have >> >> previously >> >> compiled unsuffered consquences without issue, but on the current >> >> version, I get this error >> >> >> >> >> >> windres -F pe-x86-64 -I../include -i dllversion.rc -o dllversion.o >> >> comm: file 2 is not in sorted order >> >> make[3]: *** [R.dll] Error 1 >> >> make[2]: *** [../../bin/x64/R.dll] Error 2 >> >> make[1]: *** [rbuild] Error 2 >> >> make: *** [all] Error 2 >> >> >> >> I did not note any other errors or warnings earlier on, though I may >> >> have missed some. I can provide the full log if requested. Any >> >> ideas? >> > >> > >> > I believe that message is about the file src/gnuwin32/Rdll.hide. It is >> > supposed to be sorted, using ASCII collation order. I believe the >> > version >> > in the repository is sorted properly; can you check yours? >> >> Thanks for your reply. It looks sorted correctly and explicitly >> sorting prior to running make does not change the error. here is a >> bit of output: >> >> BZ2_bzBuffToBuffCompress@28 >> BZ2_bzBuffToBuffDecompress@24 >> BZ2_bzCompress@8 >> BZ2_bzCompressEnd@4 >> BZ2_bzCompressInit@16 >> BZ2_bzDecompress@4 >> BZ2_bzDecompressEnd@4 >> BZ2_bzDecompressInit@12 >> BZ2_bzRead@16 >> BZ2_bzReadClose@8 >> BZ2_bzReadGetUnused@16 >> BZ2_bzReadOpen@24 >> BZ2_bzWrite@16 >> BZ2_bzWriteClose64@28 >> BZ2_bzWriteClose@20 >> >> > >> > We've had some problems with recent versions of Cygwin not sorting >> > properly. >> > The last instance had it put names in the order >> > >> > BZ2_bzWriteClose@20 >> > BZ2_bzWriteClose64@28 >> > >> > but ASCII order should put @ after 6. Are you using the comm and >> > Cygwin >> > dlls from Rtools, or have you got newer ones? >> >> As far as I know I should only be using the dlls from Rtools. It is >> the first thing on my path environment variable, and although cygwin >> is installed, I do not even have it on my path. Interestingly, there >> are no problems if set MULTI=32 instead of 64 in MkRules. >> >> Thanks again, >> >> Josh >> >> > >> > Duncan Murdoch >> >> >> > -- Joshua Wiley Ph.D. Student, Health Psychology Programmer Analyst II, Statistical Consulting Group University of California, Los Angeles https://joshuawiley.com/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] setting global options for a package
This may be elementary, but I can't find an answer: How can I set up
global options for
some specific arguments to functions in a package which can be easily
changed by the user?
This question relates to the selection of colors used in functions in
several packages (heplots,
genridge), where I want to provide reasonable default values for plots,
but allow users to
change those defaults globally for all plots produced with my functions.
One solution is to use palette() for the default, as in
foo <- function(x, col=palette(), ...) {}
but the standard palette is not appropriate for my use, and I'd rather
not hijack more typical uses
Another is to use an explicit list of colors for default, as in
bar <- function(x, col=c('red', 'blue', 'brown', 'darkgreen', ...), ...) {}
but this must be overridden each time by someone to wants to change the
defaults.
options() seems like the way to go, but I'm not sure how to implement
this. If I use
a .onLoad function to set some options, will these be created in the
global environment?
If not, how to make them so?
.onLoad <- function() {
options(heplot.colors =
c("red", "blue", "black", "darkgreen", "darkcyan","magenta",
"brown","darkgray"))
}
My function could then use
foo <- function(x, getOption("heplot.colors"), ...) {}
--
Michael Friendly Email: friendly AT yorku DOT ca
Professor, Psychology Dept.
York University Voice: 416 736-5115 x66249 Fax: 416 736-5814
4700 Keele StreetWeb: http://www.datavis.ca
Toronto, ONT M3J 1P3 CANADA
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] setting global options for a package
Have you considered the lattice package? The defaults can be
accessed/changed via trellis.par.get(), but also passed as arguments
into the functions.
Kevin
On Thu, May 10, 2012 at 8:59 AM, Michael Friendly wrote:
> This may be elementary, but I can't find an answer: How can I set up global
> options for
> some specific arguments to functions in a package which can be easily
> changed by the user?
>
> This question relates to the selection of colors used in functions in
> several packages (heplots,
> genridge), where I want to provide reasonable default values for plots, but
> allow users to
> change those defaults globally for all plots produced with my functions.
>
> One solution is to use palette() for the default, as in
>
> foo <- function(x, col=palette(), ...) {}
> but the standard palette is not appropriate for my use, and I'd rather not
> hijack more typical uses
>
> Another is to use an explicit list of colors for default, as in
>
> bar <- function(x, col=c('red', 'blue', 'brown', 'darkgreen', ...), ...) {}
> but this must be overridden each time by someone to wants to change the
> defaults.
>
> options() seems like the way to go, but I'm not sure how to implement this.
> If I use
> a .onLoad function to set some options, will these be created in the global
> environment?
> If not, how to make them so?
>
> .onLoad <- function() {
> options(heplot.colors =
> c("red", "blue", "black", "darkgreen", "darkcyan","magenta",
> "brown","darkgray"))
> }
>
> My function could then use
>
> foo <- function(x, getOption("heplot.colors"), ...) {}
>
>
> --
> Michael Friendly Email: friendly AT yorku DOT ca
> Professor, Psychology Dept.
> York University Voice: 416 736-5115 x66249 Fax: 416 736-5814
> 4700 Keele Street Web: http://www.datavis.ca
> Toronto, ONT M3J 1P3 CANADA
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Kevin Wright
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] setting global options for a package
On May 10, 2012, at 9:59 AM, Michael Friendly wrote:
> This may be elementary, but I can't find an answer: How can I set up global
> options for
> some specific arguments to functions in a package which can be easily changed
> by the user?
>
> This question relates to the selection of colors used in functions in several
> packages (heplots,
> genridge), where I want to provide reasonable default values for plots, but
> allow users to
> change those defaults globally for all plots produced with my functions.
>
> One solution is to use palette() for the default, as in
>
> foo <- function(x, col=palette(), ...) {}
> but the standard palette is not appropriate for my use, and I'd rather not
> hijack more typical uses
>
> Another is to use an explicit list of colors for default, as in
>
> bar <- function(x, col=c('red', 'blue', 'brown', 'darkgreen', ...), ...) {}
> but this must be overridden each time by someone to wants to change the
> defaults.
>
> options() seems like the way to go, but I'm not sure how to implement this.
> If I use
> a .onLoad function to set some options, will these be created in the global
> environment?
> If not, how to make them so?
>
> .onLoad <- function() {
> options(heplot.colors =
> c("red", "blue", "black", "darkgreen", "darkcyan","magenta",
> "brown","darkgray"))
You certainly don't want to do that - it would override user's setting and thus
defeat the whole purpose of options.
> }
>
> My function could then use
>
> foo <- function(x, getOption("heplot.colors"), ...) {}
>
You can always do that:
foo <- function(x, heplot.colors = getOption("heplot.colors"), ...) {
if (is.null(heplot.colors)) heplot.colors <- c("red", "blue", "black",
"darkgreen", "darkcyan","magenta", "brown","darkgray")
Cheers,
Simon
>
> --
> Michael Friendly Email: friendly AT yorku DOT ca
> Professor, Psychology Dept.
> York University Voice: 416 736-5115 x66249 Fax: 416 736-5814
> 4700 Keele StreetWeb: http://www.datavis.ca
> Toronto, ONT M3J 1P3 CANADA
>
> __
> 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] setting global options for a package
Or slightly more conveniently, use the default value of getOption() to return
the vector
of color names if the option is not set, e.g.
foo <- function(x, heplot.colors = getOption("heplot.colors",
c("red", "blue", "black",
"darkgreen", "brown", "darkgray")), ...) {
D.
On 5/10/12 10:09 AM, Simon Urbanek wrote:
>
> On May 10, 2012, at 9:59 AM, Michael Friendly wrote:
>
>> This may be elementary, but I can't find an answer: How can I set up global
>> options for
>> some specific arguments to functions in a package which can be easily
>> changed by the user?
>>
>> This question relates to the selection of colors used in functions in
>> several packages (heplots,
>> genridge), where I want to provide reasonable default values for plots, but
>> allow users to
>> change those defaults globally for all plots produced with my functions.
>>
>> One solution is to use palette() for the default, as in
>>
>> foo <- function(x, col=palette(), ...) {}
>> but the standard palette is not appropriate for my use, and I'd rather not
>> hijack more typical uses
>>
>> Another is to use an explicit list of colors for default, as in
>>
>> bar <- function(x, col=c('red', 'blue', 'brown', 'darkgreen', ...), ...) {}
>> but this must be overridden each time by someone to wants to change the
>> defaults.
>>
>> options() seems like the way to go, but I'm not sure how to implement this.
>> If I use
>> a .onLoad function to set some options, will these be created in the global
>> environment?
>> If not, how to make them so?
>>
>> .onLoad <- function() {
>> options(heplot.colors =
>> c("red", "blue", "black", "darkgreen", "darkcyan","magenta",
>> "brown","darkgray"))
>
> You certainly don't want to do that - it would override user's setting and
> thus defeat the whole purpose of options.
>
>
>> }
>>
>> My function could then use
>>
>> foo <- function(x, getOption("heplot.colors"), ...) {}
>>
>
> You can always do that:
>
> foo <- function(x, heplot.colors = getOption("heplot.colors"), ...) {
> if (is.null(heplot.colors)) heplot.colors <- c("red", "blue", "black",
> "darkgreen", "darkcyan","magenta", "brown","darkgray")
>
> Cheers,
> Simon
>
>
>>
>> --
>> Michael Friendly Email: friendly AT yorku DOT ca
>> Professor, Psychology Dept.
>> York University Voice: 416 736-5115 x66249 Fax: 416 736-5814
>> 4700 Keele StreetWeb: http://www.datavis.ca
>> Toronto, ONT M3J 1P3 CANADA
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] setting global options for a package
On 10/05/2012 1:53 PM, Duncan Temple Lang wrote:
Or slightly more conveniently, use the default value of getOption() to return
the vector
of color names if the option is not set, e.g.
foo<- function(x, heplot.colors = getOption("heplot.colors",
c("red", "blue", "black", "darkgreen",
"brown", "darkgray")), ...) {
If each option is only used in a small number of places, that's the
easiest solution. If they are used more widely, you have the problem of
keeping the defaults consistent. Several packages do their own
home-brewed solutions to this. In rgl it's done by having a package
global variable r3dDefaults. If a user changes it, they get their own
copy in the global environment. This means functions within rgl
need to use
get("r3dDefaults", envir=.GlobalEnv)
to do the lookups in the right place.
The igraph package also handles defaults for graph colors; I haven't
really looked into how they did it.
You can do it using lexical scoping: something like
myOptions <- local({
opt1 <- default1
opt2 <- default2
function(...) {
# If ... has no names, it's asking for values; if it has names,
then change
# the parents. Or just create two functions, one for setting,
one for getting.
}
)
Duncan Murdoch
D.
On 5/10/12 10:09 AM, Simon Urbanek wrote:
>
> On May 10, 2012, at 9:59 AM, Michael Friendly wrote:
>
>> This may be elementary, but I can't find an answer: How can I set up global
options for
>> some specific arguments to functions in a package which can be easily
changed by the user?
>>
>> This question relates to the selection of colors used in functions in
several packages (heplots,
>> genridge), where I want to provide reasonable default values for plots, but
allow users to
>> change those defaults globally for all plots produced with my functions.
>>
>> One solution is to use palette() for the default, as in
>>
>> foo<- function(x, col=palette(), ...) {}
>> but the standard palette is not appropriate for my use, and I'd rather not
hijack more typical uses
>>
>> Another is to use an explicit list of colors for default, as in
>>
>> bar<- function(x, col=c('red', 'blue', 'brown', 'darkgreen', ...), ...) {}
>> but this must be overridden each time by someone to wants to change the
defaults.
>>
>> options() seems like the way to go, but I'm not sure how to implement this.
If I use
>> a .onLoad function to set some options, will these be created in the global
environment?
>> If not, how to make them so?
>>
>> .onLoad<- function() {
>> options(heplot.colors =
>> c("red", "blue", "black", "darkgreen", "darkcyan","magenta",
"brown","darkgray"))
>
> You certainly don't want to do that - it would override user's setting and
thus defeat the whole purpose of options.
>
>
>> }
>>
>> My function could then use
>>
>> foo<- function(x, getOption("heplot.colors"), ...) {}
>>
>
> You can always do that:
>
> foo<- function(x, heplot.colors = getOption("heplot.colors"), ...) {
>if (is.null(heplot.colors)) heplot.colors<- c("red", "blue", "black", "darkgreen",
"darkcyan","magenta", "brown","darkgray")
>
> Cheers,
> Simon
>
>
>>
>> --
>> Michael Friendly Email: friendly AT yorku DOT ca
>> Professor, Psychology Dept.
>> York University Voice: 416 736-5115 x66249 Fax: 416 736-5814
>> 4700 Keele StreetWeb: http://www.datavis.ca
>> Toronto, ONT M3J 1P3 CANADA
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
