[Rd] Checking package vignettes: WARNING
Hi, I want to have a "vignette" in one of my R packages. Hence, I added an Sweave file into the /inst/doc subdirectory of this package. Unfortunately, 'R CMD check' gives a warning: == [...] * checking tests ... OK * checking package vignettes in 'inst/doc' ... WARNING --- führe texi2dvi auf Vignetten aus * creating sampleSelection-manual.tex ... OK * checking sampleSelection-manual.tex using pdflatex ... OK WARNING: There was 1 warning, see /home/suapm095/Documents/Econometrics/R/micEcon/micEcon/sampleSelection.Rcheck/00check.log for details == Since the line below "WARNING" is in German, I ran 'LC_ALL="C" R CMD check' to get an English message (which I could use in a Google search). However, the warning does NOT occur if I run 'R CMD check' in the 'C' locale. I tried a lot of different things and I figured out that 'führe texi2dvi auf Vignetten aus' is the translation of 'running texi2dvi on vignettes', but I did not find the reason for the warning message that occurs if 'R CMD check' is run in the German locale. If I run Sweave and texi2dvi by hand with both locales, the only possibly relevant difference I noticed is that Sweave uses straight single quotation marks in the 'C' locale but (italicized) primes in the German locale: 'C' locale: Signif. codes: 0 '***' 0.001 '**' 0.01 '*' 0.05 '.' 0.1 ' ' 1 German locale: Signif. codes: 0 ‘***’ 0.001 ‘**’ 0.01 ‘*’ 0.05 ‘.’ 0.1 ‘ ’ 1 System Information: R 2.7.1 i486-pc-linux-gnu Kubuntu 8.04 Any hints are welcome! Thanks, Arne -- Arne Henningsen http://www.arne-henningsen.name __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Problems with snowfall
Guys,
Is anyone using snowfall? It seems that the last version is broken. sfinit
contains test code:
data("config", package = "snowfall")
configM <- as.matrix(t(config))
config <- as.list(configM)
names(config) <- dimnames(configM)[[2]]
.sfOption$SERVER <<- as.character(config[["SERVER"]])
.sfOption$PORT <<- as.numeric(config[["PORT"]])
.sfOption$MAXNODES <<- as.numeric(config[["MAXNODES"]])
Which tries to set up the environment with the test data from "config"
On top of that is assumes the existence in the environment of a variable
"sfOption", without that it doesn't get past the first few lines of code...
I wonder if the package is used by anyone around here?
Cheers,
// Giuseppe
HSBC Bank plc may be solicited in the course of its placement efforts for a
new issue, by investment clients of the firm for whom the Bank as a firm
already provides other services. It may equally decide to allocate to its
own proprietary book or with an associate of HSBC Group. This represents a
potential conflict of interest. HSBC Bank plc has internal arrangements
designed to ensure that the firm would give unbiased and full advice to the
corporate finance client about the valuation and pricing of the offering as
well as internal systems, controls and procedures to identify and manage
conflicts of interest.
HSBC Bank plc
Registered Office: 8 Canada Square, London E14 5HQ, United Kingdom
Registered in England - Number 14259
Authorised and regulated by the Financial Services Authority.
-
SAVE PAPER - THINK BEFORE YOU PRINT!
This transmission has been issued by a member of the HSBC Group
"HSBC" for the information of the addressee only and should not be
reproduced and/or distributed to any other person. Each page
attached hereto must be read in conjunction with any disclaimer
which forms part of it. Unless otherwise stated, this transmission
is neither an offer nor the solicitation of an offer to sell or
purchase any investment. Its contents are based on information
obtained from sources believed to be reliable but HSBC makes no
representation and accepts no responsibility or liability as to its
completeness or accuracy.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Checking package vignettes: WARNING
Hello Arne,
I do not know if this matters, but have you used 'results = verbatim' in your R
code chunk? See page 13 in:
http://www.statistik.lmu.de/~leisch/Sweave/Sweave-manual.pdf
Best,
Bernhard
>
>Hi,
>
>I want to have a "vignette" in one of my R packages. Hence, I
>added an Sweave
>file into the /inst/doc subdirectory of this package.
>Unfortunately, 'R CMD
>check' gives a warning:
>
>==
>[...]
>* checking tests ... OK
>* checking package vignettes in 'inst/doc' ... WARNING
>--- führe texi2dvi auf Vignetten aus
>* creating sampleSelection-manual.tex ... OK
>* checking sampleSelection-manual.tex using pdflatex ... OK
>
>WARNING: There was 1 warning, see
>
>/home/suapm095/Documents/Econometrics/R/micEcon/micEcon/sampleS
>election.Rcheck/00check.log
>for details
>==
>
>Since the line below "WARNING" is in German, I ran 'LC_ALL="C"
>R CMD check'
>to get an English message (which I could use in a Google
>search). However, the
>warning does NOT occur if I run 'R CMD check' in the 'C'
>locale. I tried a
>lot of different things and I figured out that 'führe texi2dvi
>auf Vignetten
>aus' is the translation of 'running texi2dvi on vignettes',
>but I did not
>find the reason for the warning message that occurs if 'R CMD
>check' is run
>in the German locale. If I run Sweave and texi2dvi by hand
>with both locales,
>the only possibly relevant difference I noticed is that Sweave
>uses straight
>single quotation marks in the 'C' locale but (italicized)
>primes in the
>German locale:
>
>'C' locale:
> Signif. codes: 0 '***' 0.001 '**' 0.01 '*' 0.05 '.' 0.1 ' ' 1
>
>German locale:
> Signif. codes: 0 '***' 0.001 '**' 0.01 '*' 0.05 '.' 0.1 ' ' 1
>
>System Information:
>R 2.7.1
>i486-pc-linux-gnu
>Kubuntu 8.04
>
>Any hints are welcome!
>Thanks,
>Arne
>
>--
>Arne Henningsen
>http://www.arne-henningsen.name
>
>__
>R-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-devel
>
*
Confidentiality Note: The information contained in this ...{{dropped:10}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] spss long labels
Hi Kurt, I have committed your patch and your new spss_long.sav example file, tested things and uploaded a new version of 'foreign', namely 0.8-27 to CRAN. I vaguely remember that other useRs have asked for long-label support in the past, so if you are (or know of) such a user, we'd be glad if you'd test the new foreign package, once it will be available for update.packages(). Martin Maechler __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Checking package vignettes: WARNING
Hi Bernhard! On Wednesday 16 July 2008 14:16:05, you wrote: > I do not know if this matters, but have you used 'results = verbatim' in > your R code chunk? See page 13 in: > http://www.statistik.lmu.de/~leisch/Sweave/Sweave-manual.pdf Thank you for this hint. I have tried this option, but it seems to have no effect on the quotation marks. Hence, I still do not know whether the quotation marks or something else causes the warning. Arne > >Hi, > > > >I want to have a "vignette" in one of my R packages. Hence, I > >added an Sweave > >file into the /inst/doc subdirectory of this package. > >Unfortunately, 'R CMD > >check' gives a warning: > > > >== > >[...] > >* checking tests ... OK > >* checking package vignettes in 'inst/doc' ... WARNING > >--- führe texi2dvi auf Vignetten aus > >* creating sampleSelection-manual.tex ... OK > >* checking sampleSelection-manual.tex using pdflatex ... OK > > > >WARNING: There was 1 warning, see > > > >/home/suapm095/Documents/Econometrics/R/micEcon/micEcon/sampleS > >election.Rcheck/00check.log > >for details > >== > > > >Since the line below "WARNING" is in German, I ran 'LC_ALL="C" > >R CMD check' > >to get an English message (which I could use in a Google > >search). However, the > >warning does NOT occur if I run 'R CMD check' in the 'C' > >locale. I tried a > >lot of different things and I figured out that 'führe texi2dvi > >auf Vignetten > >aus' is the translation of 'running texi2dvi on vignettes', > >but I did not > >find the reason for the warning message that occurs if 'R CMD > >check' is run > >in the German locale. If I run Sweave and texi2dvi by hand > >with both locales, > >the only possibly relevant difference I noticed is that Sweave > >uses straight > >single quotation marks in the 'C' locale but (italicized) > >primes in the > >German locale: > > > >'C' locale: > > Signif. codes: 0 '***' 0.001 '**' 0.01 '*' 0.05 '.' 0.1 ' ' 1 > > > >German locale: > > Signif. codes: 0 '***' 0.001 '**' 0.01 '*' 0.05 '.' 0.1 ' ' 1 > > > >System Information: > >R 2.7.1 > >i486-pc-linux-gnu > >Kubuntu 8.04 > > > >Any hints are welcome! > >Thanks, > >Arne > > > >-- > >Arne Henningsen > >http://www.arne-henningsen.name > > > >__ > >R-devel@r-project.org mailing list > >https://stat.ethz.ch/mailman/listinfo/r-devel > > * > Confidentiality Note: The information contained in this message, > and any attachments, may contain confidential and/or privileged > material. It is intended solely for the person(s) or entity to > which it is addressed. Any review, retransmission, dissemination, > or taking of any action in reliance upon this information by > persons or entities other than the intended recipient(s) is > prohibited. If you received this in error, please contact the > sender and delete the material from any computer. > * -- Arne Henningsen http://www.arne-henningsen.name __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Embedded R, last errormessage, and stack smashing
The only way to overcome the problem I can find is to tweak the
R_CStackLimit with:
R_CStackLimit = (uintptr_t) -1;
The question I am having now is: what are the implications of doing
so, that is what are the potential problems ?
The R-extensions manual says:
" Stack-checking can be disabled by seting R_CStackLimit =
(uintptr_t)-1, but it is better to
if possible set appropriate values. (What these are and how to
determine them are OS-specific,
and the stack size limit may differ for secondary threads. If you have
a choice of stack size, at
least 8Mb is recommended.)"
I am not very sure of how an appropriate value can be determined.
I looked around, and the JRI (Java/R Interface) is just disabling
stack checking for example.
Thanks,
Laurent
2008/6/30 Laurent Gautier <[EMAIL PROTECTED]>:
> Dear list,
>
> I am having an embedded R, dying with
> *** stack smashing detected *** in one specific case.
>
> My code is such as I evaluate R expression with C code like
>
> res = R_tryEval(expr, env, &error);
>
> and in case of error, get the error message (usually sucessfully) with
> code like below:
>
> SEXP geterrmessage = findVar(install("geterrmessage"), R_BaseNamespace);
> PROTECT(expr = allocVector(LANGSXP, 1));
> SETCAR(expr, geterrmessage);
> PROTECT(res = Rf_eval(expr, R_GlobalEnv));
> // ---> *** stack smashing detected ***
>
> The call to Rf_eval does not return as the stack smashing error stops the
> show.
>
> Tracing with gdb where the problem occurs, I follow the path:
> eval -> R_CheckStack in main/error.c -> errorcall in main/error.c
>
>
> In errorcall, I narrow down the origin of the problem around the lines:
> 658va_start(ap, format);
> 659verrorcall_dflt(call, format, ap);
> 660va_end(ap);
> and add a breakpoint on each one of those lines.
>
>
> My gdb session till the stack smashing crashing is then looking like:
>
> Breakpoint 7, Rf_errorcall (call=0x828ef8, format=0x7f4dbdc87698 "C
> stack usage is too close to the limit")
>at errors.c:658
> 658 va_start(ap, format);
> (gdb) p ap
> $2 = {{gp_offset = 16, fp_offset = 48, overflow_arg_area = 0x41c22f60,
> reg_save_area = 0x41c22e70}}
> (gdb) p format
> $3 = 0x7f4dbdc87698 "C stack usage is too close to the limit"
> (gdb) continue
> Continuing.
>
> Breakpoint 8, Rf_errorcall (call=0x828ef8, format=0x7f4dbdc87698 "C
> stack usage is too close to the limit")
>at errors.c:659
> 659 verrorcall_dflt(call, format, ap);
> (gdb) continue
> Continuing.
>
> Breakpoint 6, Rf_errorcall (call=0x828ef8, format=0x7f4dbdc87406 "%s")
> at errors.c:648
> 648 if (R_ErrorHook != NULL) {
> (gdb) continue
> Continuing.
>
> Breakpoint 7, Rf_errorcall (call=0x828ef8, format=0x7f4dbdc87406 "%s")
> at errors.c:658
> 658 va_start(ap, format);
> (gdb) continue
> Continuing.
>
> Breakpoint 8, Rf_errorcall (call=0x828ef8, format=0x7f4dbdc87406 "%s")
> at errors.c:659
> 659 verrorcall_dflt(call, format, ap);
> (gdb) continue
> Continuing.
> *** stack smashing detected ***: /usr/bin/python terminated
>
>
> My understanding is that there is a C stack problem about to happen R
> tries to report, but in the process of reporting it
> causes a C stack-related crash. Is there something odd with R handling
> the situation, or should I look for the cause
> of the problem elsewhere ?
>
> Thanks,
>
>
> L.
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Embedded R, last errormessage, and stack smashing
Laurent,
On Jul 16, 2008, at 9:02 AM, Laurent Gautier wrote:
The only way to overcome the problem I can find is to tweak the
R_CStackLimit with:
R_CStackLimit = (uintptr_t) -1;
The question I am having now is: what are the implications of doing
so, that is what are the potential problems ?
The implications are that you are disabling stack checks, i.e. R won't
be able to detect stack overflows.
The R-extensions manual says: " Stack-checking can be disabled by
seting R_CStackLimit = (uintptr_t)-1, but it is better to if
possible set appropriate values. (What these are and how to
determine them are OS-specific, and the stack size limit may differ
for secondary threads. If you have a choice of stack size, at least
8Mb is recommended.)"
I am not very sure of how an appropriate value can be determined.
You can have a look at R sources which do this - the basic idea (if no
OS-specific method exists) is to fetch an address of a local variable
which will be on the stack and then add as much space as the size of
the stack is. On some systems there is an API to find the stack of the
current thread. However, this works only if you guarantee that you'll
be calling R from a specific thread (which is generally a good idea,
though).
I looked around, and the JRI (Java/R Interface) is just disabling
stack checking for example.
JRI is quite general and supports different use models - one allows R
to be called from different threads (with appropriate care and
synchronization), so it has no choice but to disable the check because
the stack will change across threads.
Cheers,
Simon
2008/6/30 Laurent Gautier <[EMAIL PROTECTED]>:
Dear list,
I am having an embedded R, dying with
*** stack smashing detected *** in one specific case.
My code is such as I evaluate R expression with C code like
res = R_tryEval(expr, env, &error);
and in case of error, get the error message (usually sucessfully)
with
code like below:
SEXP geterrmessage = findVar(install("geterrmessage"),
R_BaseNamespace);
PROTECT(expr = allocVector(LANGSXP, 1));
SETCAR(expr, geterrmessage);
PROTECT(res = Rf_eval(expr, R_GlobalEnv));
// ---> *** stack smashing detected ***
The call to Rf_eval does not return as the stack smashing error
stops the show.
Tracing with gdb where the problem occurs, I follow the path:
eval -> R_CheckStack in main/error.c -> errorcall in main/error.c
In errorcall, I narrow down the origin of the problem around the
lines:
658va_start(ap, format);
659verrorcall_dflt(call, format, ap);
660va_end(ap);
and add a breakpoint on each one of those lines.
My gdb session till the stack smashing crashing is then looking like:
Breakpoint 7, Rf_errorcall (call=0x828ef8, format=0x7f4dbdc87698 "C
stack usage is too close to the limit")
at errors.c:658
658 va_start(ap, format);
(gdb) p ap
$2 = {{gp_offset = 16, fp_offset = 48, overflow_arg_area =
0x41c22f60,
reg_save_area = 0x41c22e70}}
(gdb) p format
$3 = 0x7f4dbdc87698 "C stack usage is too close to the limit"
(gdb) continue
Continuing.
Breakpoint 8, Rf_errorcall (call=0x828ef8, format=0x7f4dbdc87698 "C
stack usage is too close to the limit")
at errors.c:659
659 verrorcall_dflt(call, format, ap);
(gdb) continue
Continuing.
Breakpoint 6, Rf_errorcall (call=0x828ef8, format=0x7f4dbdc87406
"%s")
at errors.c:648
648 if (R_ErrorHook != NULL) {
(gdb) continue
Continuing.
Breakpoint 7, Rf_errorcall (call=0x828ef8, format=0x7f4dbdc87406
"%s")
at errors.c:658
658 va_start(ap, format);
(gdb) continue
Continuing.
Breakpoint 8, Rf_errorcall (call=0x828ef8, format=0x7f4dbdc87406
"%s")
at errors.c:659
659 verrorcall_dflt(call, format, ap);
(gdb) continue
Continuing.
*** stack smashing detected ***: /usr/bin/python terminated
My understanding is that there is a C stack problem about to happen R
tries to report, but in the process of reporting it
causes a C stack-related crash. Is there something odd with R
handling
the situation, or should I look for the cause
of the problem elsewhere ?
Thanks,
L.
__
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] Snow or alternative MPI packages on Windows
Guys, I'm running R on both Windows & Linux. I'm looking at a number of packages for parallel execution. It seems that the most used packages are "snow" and "Rmpi". snow seems more user friendly, but it doesn't run on windows. I see from searching the mailing list that I'm not the first one to try it on Windows. There was a message that kind of shed some hope on the subject, but nothing else. Rmpi works well on windows (with DeinoMPI) but it's kind of low level, so before I embark in writing code similar to snow to have some high level constructs I though I'd ask here about other peoples experiences... Is anyone around here doing parallel R on Windows? If so could you share your experience? Cheers, // Giuseppe HSBC Bank plc may be solicited in the course of its placement efforts for a new issue, by investment clients of the firm for whom the Bank as a firm already provides other services. It may equally decide to allocate to its own proprietary book or with an associate of HSBC Group. This represents a potential conflict of interest. HSBC Bank plc has internal arrangements designed to ensure that the firm would give unbiased and full advice to the corporate finance client about the valuation and pricing of the offering as well as internal systems, controls and procedures to identify and manage conflicts of interest. HSBC Bank plc Registered Office: 8 Canada Square, London E14 5HQ, United Kingdom Registered in England - Number 14259 Authorised and regulated by the Financial Services Authority. - SAVE PAPER - THINK BEFORE YOU PRINT! This transmission has been issued by a member of the HSBC Group "HSBC" for the information of the addressee only and should not be reproduced and/or distributed to any other person. Each page attached hereto must be read in conjunction with any disclaimer which forms part of it. Unless otherwise stated, this transmission is neither an offer nor the solicitation of an offer to sell or purchase any investment. Its contents are based on information obtained from sources believed to be reliable but HSBC makes no representation and accepts no responsibility or liability as to its completeness or accuracy. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Snow or alternative MPI packages on Windows
[EMAIL PROTECTED] writes: > Guys, > > I'm running R on both Windows & Linux. I'm looking at a number of packages > for parallel execution. It seems that the most used packages are "snow" and > "Rmpi". > > snow seems more user friendly, but it doesn't run on windows. I see from > searching the mailing list that I'm not the first one to try it on Windows. > There was a message that kind of shed some hope on the subject, but nothing > else. > > Rmpi works well on windows (with DeinoMPI) but it's kind of low level, so > before I embark in writing code similar to snow to have some high level > constructs I though I'd ask here about other peoples experiences... Rmpi has low-level facilities, but things like mpi.spawn.Rslaves, mpi.parLapply and mpi.bcast.cmd are high-level in the same way that snow is. Hopefully others will comment with windows-specific input. Martin > Is anyone around here doing parallel R on Windows? If so could you share > your experience? > > Cheers, > > // Giuseppe > > > HSBC Bank plc may be solicited in the course of its placement efforts for a > new issue, by investment clients of the firm for whom the Bank as a firm > already provides other services. It may equally decide to allocate to its > own proprietary book or with an associate of HSBC Group. This represents a > potential conflict of interest. HSBC Bank plc has internal arrangements > designed to ensure that the firm would give unbiased and full advice to the > corporate finance client about the valuation and pricing of the offering as > well as internal systems, controls and procedures to identify and manage > conflicts of interest. > > HSBC Bank plc > Registered Office: 8 Canada Square, London E14 5HQ, United Kingdom > Registered in England - Number 14259 > Authorised and regulated by the Financial Services Authority. > > > > - > SAVE PAPER - THINK BEFORE YOU PRINT! > > This transmission has been issued by a member of the HSBC Group > "HSBC" for the information of the addressee only and should not be > reproduced and/or distributed to any other person. Each page > attached hereto must be read in conjunction with any disclaimer > which forms part of it. Unless otherwise stated, this transmission > is neither an offer nor the solicitation of an offer to sell or > purchase any investment. Its contents are based on information > obtained from sources believed to be reliable but HSBC makes no > representation and accepts no responsibility or liability as to its > completeness or accuracy. > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Martin Morgan Computational Biology / Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N. PO Box 19024 Seattle, WA 98109 Location: Arnold Building M2 B169 Phone: (206) 667-2793 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Snow or alternative MPI packages on Windows
Hello, we are using Rmpi and snow on windows. It is working very well. We are using Windows Server 2003 and *MPICH2. I probably will manage to have some tests with the new snow (*snow_0.3-3)* version this week. Best Markus Martin Morgan schrieb: [EMAIL PROTECTED] writes: Guys, I'm running R on both Windows & Linux. I'm looking at a number of packages for parallel execution. It seems that the most used packages are "snow" and "Rmpi". snow seems more user friendly, but it doesn't run on windows. I see from searching the mailing list that I'm not the first one to try it on Windows. There was a message that kind of shed some hope on the subject, but nothing else. Rmpi works well on windows (with DeinoMPI) but it's kind of low level, so before I embark in writing code similar to snow to have some high level constructs I though I'd ask here about other peoples experiences... Rmpi has low-level facilities, but things like mpi.spawn.Rslaves, mpi.parLapply and mpi.bcast.cmd are high-level in the same way that snow is. Hopefully others will comment with windows-specific input. Martin Is anyone around here doing parallel R on Windows? If so could you share your experience? Cheers, // Giuseppe HSBC Bank plc may be solicited in the course of its placement efforts for a new issue, by investment clients of the firm for whom the Bank as a firm already provides other services. It may equally decide to allocate to its own proprietary book or with an associate of HSBC Group. This represents a potential conflict of interest. HSBC Bank plc has internal arrangements designed to ensure that the firm would give unbiased and full advice to the corporate finance client about the valuation and pricing of the offering as well as internal systems, controls and procedures to identify and manage conflicts of interest. HSBC Bank plc Registered Office: 8 Canada Square, London E14 5HQ, United Kingdom Registered in England - Number 14259 Authorised and regulated by the Financial Services Authority. - SAVE PAPER - THINK BEFORE YOU PRINT! This transmission has been issued by a member of the HSBC Group "HSBC" for the information of the addressee only and should not be reproduced and/or distributed to any other person. Each page attached hereto must be read in conjunction with any disclaimer which forms part of it. Unless otherwise stated, this transmission is neither an offer nor the solicitation of an offer to sell or purchase any investment. Its contents are based on information obtained from sources believed to be reliable but HSBC makes no representation and accepts no responsibility or liability as to its completeness or accuracy. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Dipl.-Tech. Math. Markus Schmidberger Ludwig-Maximilians-Universität München IBE - Institut für medizinische Informationsverarbeitung, Biometrie und Epidemiologie Marchioninistr. 15, D-81377 Muenchen URL: http://ibe.web.med.uni-muenchen.de Mail: Markus.Schmidberger [at] ibe.med.uni-muenchen.de Tel: +49 (089) 7095 - 4599 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Rinterfaces.h
Dear List, Is there a reason that Rinterfaces.h is not contained in include directory of the official distribution on Windows? thx, Peter [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Embedded R, last errormessage, and stack smashing
Laurent Gautier wrote on 07/16/2008 08:02 AM:
The only way to overcome the problem I can find is to tweak the
R_CStackLimit with:
R_CStackLimit = (uintptr_t) -1;
The question I am having now is: what are the implications of doing
so, that is what are the potential problems ?
The problem is a program crash without saving data. Stack overflow is
usually caused by either infinite recursion or very large stack (i.e.
local) variables.
I've always disabled stack checking in rapache, and I never knew why the
checking was added to R, but again wikipedia has merit:
http://en.wikipedia.org/wiki/Stack_overflow
Jeff
The R-extensions manual says:
" Stack-checking can be disabled by seting R_CStackLimit =
(uintptr_t)-1, but it is better to
if possible set appropriate values. (What these are and how to
determine them are OS-specific,
and the stack size limit may differ for secondary threads. If you have
a choice of stack size, at
least 8Mb is recommended.)"
I am not very sure of how an appropriate value can be determined.
I looked around, and the JRI (Java/R Interface) is just disabling
stack checking for example.
Thanks,
Laurent
2008/6/30 Laurent Gautier <[EMAIL PROTECTED]>:
Dear list,
I am having an embedded R, dying with
*** stack smashing detected *** in one specific case.
My code is such as I evaluate R expression with C code like
res = R_tryEval(expr, env, &error);
and in case of error, get the error message (usually sucessfully) with
code like below:
SEXP geterrmessage = findVar(install("geterrmessage"), R_BaseNamespace);
PROTECT(expr = allocVector(LANGSXP, 1));
SETCAR(expr, geterrmessage);
PROTECT(res = Rf_eval(expr, R_GlobalEnv));
// ---> *** stack smashing detected ***
The call to Rf_eval does not return as the stack smashing error stops the show.
Tracing with gdb where the problem occurs, I follow the path:
eval -> R_CheckStack in main/error.c -> errorcall in main/error.c
In errorcall, I narrow down the origin of the problem around the lines:
658va_start(ap, format);
659verrorcall_dflt(call, format, ap);
660va_end(ap);
and add a breakpoint on each one of those lines.
My gdb session till the stack smashing crashing is then looking like:
Breakpoint 7, Rf_errorcall (call=0x828ef8, format=0x7f4dbdc87698 "C
stack usage is too close to the limit")
at errors.c:658
658 va_start(ap, format);
(gdb) p ap
$2 = {{gp_offset = 16, fp_offset = 48, overflow_arg_area = 0x41c22f60,
reg_save_area = 0x41c22e70}}
(gdb) p format
$3 = 0x7f4dbdc87698 "C stack usage is too close to the limit"
(gdb) continue
Continuing.
Breakpoint 8, Rf_errorcall (call=0x828ef8, format=0x7f4dbdc87698 "C
stack usage is too close to the limit")
at errors.c:659
659 verrorcall_dflt(call, format, ap);
(gdb) continue
Continuing.
Breakpoint 6, Rf_errorcall (call=0x828ef8, format=0x7f4dbdc87406 "%s")
at errors.c:648
648 if (R_ErrorHook != NULL) {
(gdb) continue
Continuing.
Breakpoint 7, Rf_errorcall (call=0x828ef8, format=0x7f4dbdc87406 "%s")
at errors.c:658
658 va_start(ap, format);
(gdb) continue
Continuing.
Breakpoint 8, Rf_errorcall (call=0x828ef8, format=0x7f4dbdc87406 "%s")
at errors.c:659
659 verrorcall_dflt(call, format, ap);
(gdb) continue
Continuing.
*** stack smashing detected ***: /usr/bin/python terminated
My understanding is that there is a C stack problem about to happen R
tries to report, but in the process of reporting it
causes a C stack-related crash. Is there something odd with R handling
the situation, or should I look for the cause
of the problem elsewhere ?
Thanks,
L.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
http://biostat.mc.vanderbilt.edu/JeffreyHorner
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Snow or alternative MPI packages on Windows
Markus, That's interesting. I'm using snow_0.3-0 that's the version on CRAN. I see that on the maintainer's website newer versions are available... I just tried snow_0.3-3 and as you said it actually works fine! Thanks a lot for the help, that's exactly what I was looking for! // Giuseppe Markus Schmidberger <[EMAIL PROTECTED] To uni-muenchen.de> Martin Morgan <[EMAIL PROTECTED]>, Giuseppe1 MILICIA/IBEU/[EMAIL PROTECTED] 16/07/2008 15:44 cc Mail Size: 7121 r-devel@r-project.org Subject Please respond to Re: [Rd] Snow or alternative MPI [EMAIL PROTECTED] packages on Windows ni-muenchen.deEntity Investment Banking Europe - IBEU Hello, we are using Rmpi and snow on windows. It is working very well. We are using Windows Server 2003 and *MPICH2. I probably will manage to have some tests with the new snow (*snow_0.3-3)* version this week. Best Markus Martin Morgan schrieb: > [EMAIL PROTECTED] writes: > > >> Guys, >> >> I'm running R on both Windows & Linux. I'm looking at a number of packages >> for parallel execution. It seems that the most used packages are "snow" and >> "Rmpi". >> >> snow seems more user friendly, but it doesn't run on windows. I see from >> searching the mailing list that I'm not the first one to try it on Windows. >> There was a message that kind of shed some hope on the subject, but nothing >> else. >> >> Rmpi works well on windows (with DeinoMPI) but it's kind of low level, so >> before I embark in writing code similar to snow to have some high level >> constructs I though I'd ask here about other peoples experiences... >> > > Rmpi has low-level facilities, but things like mpi.spawn.Rslaves, > mpi.parLapply and mpi.bcast.cmd are high-level in the same way that > snow is. > > Hopefully others will comment with windows-specific input. > > Martin > > >> Is anyone around here doing parallel R on Windows? If so could you share >> your experience? >> >> Cheers, >> >> // Giuseppe >> >> >> HSBC Bank plc may be solicited in the course of its placement efforts for a >> new issue, by investment clients of the firm for whom the Bank as a firm >> already provides other services. It may equally decide to allocate to its >> own proprietary book or with an associate of HSBC Group. This represents a >> potential conflict of interest. HSBC Bank plc has internal arrangements >> designed to ensure that the firm would give unbiased and full advice to the >> corporate finance client about the valuation and pricing of the offering as >> well as internal systems, controls and procedures to identify and manage >> conflicts of interest. >> >> HSBC Bank plc >> Registered Office: 8 Canada Square, London E14 5HQ, United Kingdom >> Registered in England - Number 14259 >> Authorised and regulated by the Financial Services Authority. >> >> >> >> - >> SAVE PAPER - THINK BEFORE YOU PRINT! >> >> This transmission has been issued by a member of the HSBC Group >> "HSBC" for the information of the addressee only and should not be >> reproduced and/or distributed to any other person. Each page >> attached hereto must be read in conjunction with any disclaimer >> which forms part of it. Unless otherwise stated, this transmission >> is neither an offer nor the solicitation of an offer to sell or >> purchase any investment. Its contents are based on information >> obtained from sources believed to be reliable but HSBC makes no >> representation and accepts no responsibility or liability as to its >> completeness or accuracy. >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > > -- Dipl.-Tech. Math. Markus Schmidberger Ludwig-Maximilians-Universität München IBE - Institut f
Re: [Rd] split.Date
> McGehee, Robert writes:
> Hello,
> I wanted to suggest that the below method for split.Date be added to the
> base library to significantly speed up splits with values of class Date.
> In the below example I show a speed improvement of 175x for 1000 data
> points. On a vector of size 1e6, the time difference was 22 minutes for
> split.default versus 0.3 seconds for the split.Date function below (!).
> Note that this improvement will also substantially improve performance
> for the tapply function on class Date as well.
Thanks for the suggestion. Looks good to me, so I've just added this to
r-devel.
Best
-k
> Thanks,
> Robert
> split.Date <- function(x, f, drop=FALSE) {
> x <- split.default(as.integer(x), f, drop=drop)
> for (i in seq(along=x)) class(x[[i]]) <- "Date"
> x
> }
>> vals <- round(1000*rnorm(1e4))
>> date <- rep(Sys.Date() + -1:1, length.out=1e4)
>> system.time(x1 <- split.default(date, vals))
>user system elapsed
> 7.718 0.042 7.761
>> system.time(x2 <- split.Date(date, vals))
>user system elapsed
> 0.044 0.000 0.044
>> all.equal(x1, x2)
> [1] TRUE
> Robert McGehee, CFA
> Geode Capital Management, LLC
> One Post Office Square, 28th Floor | Boston, MA | 02109
> Tel: 617/392-8396Fax:617/476-6389
> mailto:[EMAIL PROTECTED]
> This e-mail, and any attachments hereto, are intended fo...{{dropped:12}}
> __
> 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] Checking package vignettes: WARNING
> On Wed, 16 Jul 2008 14:57:39 +0200,
> Arne Henningsen (AH) wrote:
> Hi Bernhard!
> On Wednesday 16 July 2008 14:16:05, you wrote:
>> I do not know if this matters, but have you used 'results = verbatim' in
>> your R code chunk? See page 13 in:
>> http://www.statistik.lmu.de/~leisch/Sweave/Sweave-manual.pdf
> Thank you for this hint. I have tried this option, but it seems to have no
> effect on the quotation marks. Hence, I still do not know whether the
> quotation marks or something else causes the warning.
verbatim is the default, so adding changes nothing if you had no
results=xxx before.
>> >German locale:
>> >
>> >'C' locale:
>> > Signif. codes: 0 '***' 0.001 '**' 0.01 '*' 0.05 '.' 0.1 ' ' 1
>> >
>> >German locale:
>> > Signif. codes: 0 '***' 0.001 '**' 0.01 '*' 0.05 '.' 0.1 ' ' 1
>> >
>> >System Information:
>> >R 2.7.1
>> >i486-pc-linux-gnu
>> >Kubuntu 8.04
>> >
In whiche locale are you running? On Debian Linux with de_AT.UTF-8
everything is fine for me.
Of course you also need something like
\usepackage[utf8]{inputenc}
to handle the special characters, but you need that anyway because
every textual output of R may contain Umlaute ...
Hth,
Fritz
--
---
Prof. Dr. Friedrich Leisch
Institut für Statistik Tel: (+49 89) 2180 3165
Ludwig-Maximilians-Universität Fax: (+49 89) 2180 5308
Ludwigstraße 33
D-80539 München http://www.statistik.lmu.de/~leisch
---
Journal Computational Statistics --- http://www.springer.com/180
Münchner R Kurse --- http://www.statistik.lmu.de/R
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Embedded R, last errormessage, and stack smashing
2008/7/16 Jeffrey Horner <[EMAIL PROTECTED]>:
> Laurent Gautier wrote on 07/16/2008 08:02 AM:
>>
>> The only way to overcome the problem I can find is to tweak the
>> R_CStackLimit with:
>>
>> R_CStackLimit = (uintptr_t) -1;
>>
>> The question I am having now is: what are the implications of doing
>> so, that is what are the potential problems ?
>
> The problem is a program crash without saving data. Stack overflow is
> usually caused by either infinite recursion or very large stack (i.e. local)
> variables.
I think that R limits the number of recursions by checking how nested
an evaluation is.
> I've always disabled stack checking in rapache, and I never knew why the
> checking was added to R, but again wikipedia has merit:
>
> http://en.wikipedia.org/wiki/Stack_overflow
>
> Jeff
>
>>
>> The R-extensions manual says:
>> " Stack-checking can be disabled by seting R_CStackLimit =
>> (uintptr_t)-1, but it is better to
>> if possible set appropriate values. (What these are and how to
>> determine them are OS-specific,
>> and the stack size limit may differ for secondary threads. If you have
>> a choice of stack size, at
>> least 8Mb is recommended.)"
>> I am not very sure of how an appropriate value can be determined.
>>
>> I looked around, and the JRI (Java/R Interface) is just disabling
>> stack checking for example.
>>
>>
>> Thanks,
>>
>>
>> Laurent
>>
>>
>> 2008/6/30 Laurent Gautier <[EMAIL PROTECTED]>:
>>>
>>> Dear list,
>>>
>>> I am having an embedded R, dying with
>>> *** stack smashing detected *** in one specific case.
>>>
>>> My code is such as I evaluate R expression with C code like
>>>
>>> res = R_tryEval(expr, env, &error);
>>>
>>> and in case of error, get the error message (usually sucessfully) with
>>> code like below:
>>>
>>> SEXP geterrmessage = findVar(install("geterrmessage"), R_BaseNamespace);
>>> PROTECT(expr = allocVector(LANGSXP, 1));
>>> SETCAR(expr, geterrmessage);
>>> PROTECT(res = Rf_eval(expr, R_GlobalEnv));
>>> // ---> *** stack smashing detected ***
>>>
>>> The call to Rf_eval does not return as the stack smashing error stops the
>>> show.
>>>
>>> Tracing with gdb where the problem occurs, I follow the path:
>>> eval -> R_CheckStack in main/error.c -> errorcall in main/error.c
>>>
>>>
>>> In errorcall, I narrow down the origin of the problem around the lines:
>>> 658va_start(ap, format);
>>> 659verrorcall_dflt(call, format, ap);
>>> 660va_end(ap);
>>> and add a breakpoint on each one of those lines.
>>>
>>>
>>> My gdb session till the stack smashing crashing is then looking like:
>>>
>>> Breakpoint 7, Rf_errorcall (call=0x828ef8, format=0x7f4dbdc87698 "C
>>> stack usage is too close to the limit")
>>> at errors.c:658
>>> 658 va_start(ap, format);
>>> (gdb) p ap
>>> $2 = {{gp_offset = 16, fp_offset = 48, overflow_arg_area = 0x41c22f60,
>>> reg_save_area = 0x41c22e70}}
>>> (gdb) p format
>>> $3 = 0x7f4dbdc87698 "C stack usage is too close to the limit"
>>> (gdb) continue
>>> Continuing.
>>>
>>> Breakpoint 8, Rf_errorcall (call=0x828ef8, format=0x7f4dbdc87698 "C
>>> stack usage is too close to the limit")
>>> at errors.c:659
>>> 659 verrorcall_dflt(call, format, ap);
>>> (gdb) continue
>>> Continuing.
>>>
>>> Breakpoint 6, Rf_errorcall (call=0x828ef8, format=0x7f4dbdc87406 "%s")
>>> at errors.c:648
>>> 648 if (R_ErrorHook != NULL) {
>>> (gdb) continue
>>> Continuing.
>>>
>>> Breakpoint 7, Rf_errorcall (call=0x828ef8, format=0x7f4dbdc87406 "%s")
>>> at errors.c:658
>>> 658 va_start(ap, format);
>>> (gdb) continue
>>> Continuing.
>>>
>>> Breakpoint 8, Rf_errorcall (call=0x828ef8, format=0x7f4dbdc87406 "%s")
>>> at errors.c:659
>>> 659 verrorcall_dflt(call, format, ap);
>>> (gdb) continue
>>> Continuing.
>>> *** stack smashing detected ***: /usr/bin/python terminated
>>>
>>>
>>> My understanding is that there is a C stack problem about to happen R
>>> tries to report, but in the process of reporting it
>>> causes a C stack-related crash. Is there something odd with R handling
>>> the situation, or should I look for the cause
>>> of the problem elsewhere ?
>>>
>>> Thanks,
>>>
>>>
>>> L.
>>>
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
> --
> http://biostat.mc.vanderbilt.edu/JeffreyHorner
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] rowSums()/colSums() don't preserve the 'integer' storage mode
Hi, Wouldn't that make sense to have rowSums()/colSums() to preserve the storage mode? m <- matrix(1:15, nrow=5) > storage.mode(m) [1] "integer" > storage.mode(sum(m)) [1] "integer" > storage.mode(rowSums(m)) [1] "double" <--- surprising! Cheers, H. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] rowSums()/colSums() don't preserve the 'integer' storage mode
I don't see the cost of doing so paying off. storage.mode is really only important if you are passing arguments to compiled code. If you are passing to compiled code, you really need to ensure the storage mode is what you think it is, anyway. Bill Venables. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Herve Pages Sent: Thursday, 17 July 2008 3:48 PM To: R-devel@r-project.org Subject: [Rd] rowSums()/colSums() don't preserve the 'integer' storage mode Hi, Wouldn't that make sense to have rowSums()/colSums() to preserve the storage mode? m <- matrix(1:15, nrow=5) > storage.mode(m) [1] "integer" > storage.mode(sum(m)) [1] "integer" > storage.mode(rowSums(m)) [1] "double" <--- surprising! Cheers, H. __ 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
