[Rd] Changing HTTP proxy configurations at run time
DeaR developers,
I was recently moving with my laptop between two environments with and without
a HTTP proxy server. As the internal proxy configuration is read only once from
the environment variables http_proxy/HTTP_PROXY at the first call of
download.file(), the proxy configurations couldn't be adjusted at a later
stage. (See also the comment in ?download.file). This caused some frustration
as I wasn't able to use http functionality in a running R session after moving
to an environment with a different/no proxy server.
After some digging I found that this behaviour was caused by RxmlNanoHTTPInit()
in src/modules/internet/nanohttp.c, which after its first call refuses to
reinitialise the proxy configuration. It does so by setting a variable
'initialized' to 1, and checking whether the string 'proxy' is non-NULL.
I have made a small modification to have RxmlNanoHTTPInit() ignore these
variables and to read in the proxy configuration at each call.
$ svn diff
Index: src/modules/internet/nanohttp.c
===
--- src/modules/internet/nanohttp.c (revision 62488)
+++ src/modules/internet/nanohttp.c (working copy)
@@ -255,15 +255,12 @@
WSADATA wsaData;
#endif
-if (initialized)
- return;
-
#ifdef _WINSOCKAPI_
if (WSAStartup(MAKEWORD(1, 1), &wsaData) != 0)
return;
#endif
-if (proxy == NULL) {
+proxy = NULL;
proxyPort = 80;
env = getenv("no_proxy");
if (env && ((env[0] == '*') && (env[1] == 0)))
@@ -287,7 +284,7 @@
#endif
proxyUser = xmlMemStrdup(env);
}
-}
+
done:
initialized = 1;
}
This works fine for me (on a Mac) and I can simply use Sys.setenv(http_proxy=)
to adjust the proxy server at run time.
I think this doesn't really cause overhead as the number of calls do
download.file() is typically small and parsing the environment variables is
simple. On the other hand, if a user alters the proxy environment variables,
he/she probably does so for a reason. Googling around I found a few posts of R
users demanding this.
A cleaner solution would of course be to write a function that resets the
internal proxy configuration, but this would be a bit of an effort to make it
user visible.
What are your thoughts?
Best wishes,
Moritz
--
The Wellcome Trust Sanger Institute is operated by Genome Research
Limited, a charity registered in England with number 1021457 and a
company registered in England with number 2742969, whose registered
office is 215 Euston Road, London, NW1 2BE.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Non-vignette sweave file in package
Dear Duncan,
Thanks a lot for the advice.
When I place the Rnw file in inst/doc it is treated as a vignette, which I
don't want. Placing it in inst/sweave works fine. I can compile it either as
you suggested in R or from the command line with R CMD Sweave --pdf
path.to.R.library/mypkg/sweave/mydoc.rnw
Best regards,
ir. Thierry Onkelinx
Instituut voor natuur- en bosonderzoek / Research Institute for Nature and
Forest
team Biometrie & Kwaliteitszorg / team Biometrics & Quality Assurance
Kliniekstraat 25
1070 Anderlecht
Belgium
+ 32 2 525 02 51
+ 32 54 43 61 85
thierry.onkel...@inbo.be
www.inbo.be
To call in the statistician after the experiment is done may be no more than
asking him to perform a post-mortem examination: he may be able to say what the
experiment died of.
~ Sir Ronald Aylmer Fisher
The plural of anecdote is not data.
~ Roger Brinner
The combination of some data and an aching desire for an answer does not ensure
that a reasonable answer can be extracted from a given body of data.
~ John Tukey
-Oorspronkelijk bericht-
Van: Duncan Murdoch [mailto:murdoch.dun...@gmail.com]
Verzonden: donderdag 4 april 2013 19:04
Aan: ONKELINX, Thierry
CC: r-devel@r-project.org
Onderwerp: Re: [Rd] Non-vignette sweave file in package
On 04/04/2013 10:55 AM, ONKELINX, Thierry wrote:
> Dear all,
>
> I'm documenting an elaborate analysis as a private package. The package
> writes all required output to a database. I use a Sweave file to transform
> all the results from the database into a report.
>
> Now I would like to add this Sweave to my package. I'm a bit puzzled on how
> to do that. It is not a vignette: the data is not available when the package
> is build and I need to recompile the Sweave file on demand (after the
> analysis was run).
>
> So I have two questions.
> 1) Where to put a non-vignette Sweave file in a package.
> 2) How do I compile that Sweave file.
1) You can put it anywhere you like in the inst directory, but "doc"
might make sense (if it doesn't trigger warnings about a badly formed vignette,
I haven't checked). When installed, it moves up one level.
So ".../inst/doc/mydoc.Rnw"
will be retrievable as system.file("doc/mydoc.Rnw", package="mypkg").
2) Use Sweave() and tools::texi2pdf(). You might want to write your own
function that calls those, after saving the data in the appropriate place.
Duncan Murdoch
>
> Best regards,
>
> Thierry
>
> ir. Thierry Onkelinx
> Instituut voor natuur- en bosonderzoek / Research Institute for Nature
> and Forest team Biometrie & Kwaliteitszorg / team Biometrics & Quality
> Assurance Kliniekstraat 25
> 1070 Anderlecht
> Belgium
> + 32 2 525 02 51
> + 32 54 43 61 85
> thierry.onkel...@inbo.be
> www.inbo.be
>
> To call in the statistician after the experiment is done may be no more than
> asking him to perform a post-mortem examination: he may be able to say what
> the experiment died of.
> ~ Sir Ronald Aylmer Fisher
>
> The plural of anecdote is not data.
> ~ Roger Brinner
>
> The combination of some data and an aching desire for an answer does not
> ensure that a reasonable answer can be extracted from a given body of data.
> ~ John Tukey
>
> * * * * * * * * * * * * * D I S C L A I M E R * * * * * * * * * * * *
> * Dit bericht en eventuele bijlagen geven enkel de visie van de schrijver
> weer en binden het INBO onder geen enkel beding, zolang dit bericht niet
> bevestigd is door een geldig ondertekend document.
> The views expressed in this message and any annex are purely those of the
> writer and may not be regarded as stating an official position of INBO, as
> long as the message is not confirmed by a duly signed document.
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
* * * * * * * * * * * * * D I S C L A I M E R * * * * * * * * * * * * *
Dit bericht en eventuele bijlagen geven enkel de visie van de schrijver weer en
binden het INBO onder geen enkel beding, zolang dit bericht niet bevestigd is
door een geldig ondertekend document.
The views expressed in this message and any annex are purely those of the
writer and may not be regarded as stating an official position of INBO, as long
as the message is not confirmed by a duly signed document.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R 3.0 in newsticker of German computer magazine c't
Hi, just a short notice for the record that the long vectors of R 3.0 have been recognized by the news ticker of the leading German computer magazine publisher 'Heise Verlag': http://www.heise.de/newsticker/meldung/Programmiersprache-R-3-0-fuehrt-Lang-Vektoren-ein-1835822.html Thanks to you all for your great work! Thomas Petzoldt __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] parallel: Race-condition concern regarding graphics devices in a multi-thread environment
Hi,
I'm trying to figure out how to safely make sure that I close the same
graphics device that I opened earlier in a thread (and not one opened
by a parallel thread). In a *single-thread* environment, one can do
the following to open and close a device:
makePlot <- function(i) {
filename <- sprintf("foo%d.png", i);
png(filename);
idx <- dev.cur();
on.exit(dev.off(idx));
plot(1:10, col=i);
title(main=i);
filename;
} # makePlot()
However, in a *multi-thread* environment, e.g.
res <- mclapply(1:4, FUN=makePlot, mc.cores=4);
the following race-condition problem may occur, because of the
non-atomicity(?) of (i) png() and (ii) dev.cur():
1. Thread #1: png("foo1.png")
2. Thread #2: png("foo2.png")
3. Thread #1: idx <- dev.cur(); # idx == 3
4. Thread #2: idx <- dev.cur(); # idx == 3 (same device!)
...
5. Thread #1: dev.off(idx); # Closes device #3
6. Thread #2: plot(1:10, col=2); # Trying to plot, which opens a new
on-screen device (or to another active device) since device #3 is
closed.
7. Thread #2: dev.off(idx) # Trying to close device #3, which is already closed.
On this topic, there are some clues/notes on concern in the vignette
of the 'parallel' package, but not enough to answer my concerns/solve
my problems. Any other references/discussion on this (other that
source code)?
Q1. Is there already a built-in protection against the above race condition?
Q2. If not on Q1, is there a way/strategy to get hold of the device
(index) for the graphics devices that was opened by png() without
using dev.cur()?
If not on Q2, what about transitioning to have graphics device
functions return the opened device (index) (cf. connections), e.g. idx
<- png(...). A quick look at ?png and ?x11 show that those functions
does not return anything (although code inspections show that they may
return something, but always NULL when I try).
Comments?
Henrik
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] parallel: Race-condition concern regarding graphics devices in a multi-thread environment
Henrik,
there are no threads. Hence you're on the wrong track there, it has nothing to
do with device numbers/devices.The device number will be the same in all
processes and that's ok. The issue here really is which png() pack-end are you
using? (You didn't say). Some back-ends (like X11) cannot be run in forked
environment, so you can't use them. I don't use png() myself, but I do know
that CairoPNG() from the Cairo package works when forked.
Cheers,
Simon
On Apr 5, 2013, at 12:23 PM, Henrik Bengtsson wrote:
> Hi,
>
> I'm trying to figure out how to safely make sure that I close the same
> graphics device that I opened earlier in a thread (and not one opened
> by a parallel thread). In a *single-thread* environment, one can do
> the following to open and close a device:
>
> makePlot <- function(i) {
> filename <- sprintf("foo%d.png", i);
> png(filename);
> idx <- dev.cur();
> on.exit(dev.off(idx));
> plot(1:10, col=i);
> title(main=i);
> filename;
> } # makePlot()
>
> However, in a *multi-thread* environment, e.g.
>
> res <- mclapply(1:4, FUN=makePlot, mc.cores=4);
>
> the following race-condition problem may occur, because of the
> non-atomicity(?) of (i) png() and (ii) dev.cur():
>
> 1. Thread #1: png("foo1.png")
> 2. Thread #2: png("foo2.png")
> 3. Thread #1: idx <- dev.cur(); # idx == 3
> 4. Thread #2: idx <- dev.cur(); # idx == 3 (same device!)
> ...
> 5. Thread #1: dev.off(idx); # Closes device #3
> 6. Thread #2: plot(1:10, col=2); # Trying to plot, which opens a new
> on-screen device (or to another active device) since device #3 is
> closed.
> 7. Thread #2: dev.off(idx) # Trying to close device #3, which is already
> closed.
>
> On this topic, there are some clues/notes on concern in the vignette
> of the 'parallel' package, but not enough to answer my concerns/solve
> my problems. Any other references/discussion on this (other that
> source code)?
>
>
> Q1. Is there already a built-in protection against the above race condition?
>
> Q2. If not on Q1, is there a way/strategy to get hold of the device
> (index) for the graphics devices that was opened by png() without
> using dev.cur()?
>
> If not on Q2, what about transitioning to have graphics device
> functions return the opened device (index) (cf. connections), e.g. idx
> <- png(...). A quick look at ?png and ?x11 show that those functions
> does not return anything (although code inspections show that they may
> return something, but always NULL when I try).
>
>
> Comments?
>
> Henrik
>
> __
> 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
