Re: [Rd] Warnings created during R_eval or R_tryEval not shown before R ending or R error.
Thanks Ivan. I did not know about ` .Internal(printDeferredWarnings())`. It does provide a solution for what I need. Best, Laurent Le mer. 26 avr. 2023 à 06:23, Ivan Krylov a écrit : > В Sun, 23 Apr 2023 13:33:16 -0400 > Laurent Gautier пишет: > > > When tracing what happens during an error I found that > > verrorcall_dflt() in src/main/errors.c calls PrintWarnings(). That > > function is not part of R's C-API though. > > I've tried reading the source code and came to a similar conclusion. > > PrintWarnings() is required for warnings() to work because it creates > the last.warning variable for warnings() to access. When driving an > embedded R, R_ReplDLLdo1() will call it for you between expressions it > processes, but there doesn't seem to be a way to call it yourself. > > Interestingly, there is .Internal(printDeferredWarnings()) which > eventually calls PrintWarnings(), but it's not exported as an API, only > used in a few places like try(). > > Would it help to run with options(warn = 1)? I think that a different > code path is taken in this case, which should emit warnings even > without a working REPL. warnings() would still be empty, unfortunately. > > -- > Best regards, > Ivan > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Warnings created during R_eval or R_tryEval not shown before R ending or R error.
Hi, I have an embedded R, with the evaluation of expressions happening over time during the lifespan of the process. I tried either `R_eval()` and `R_tryEval()` for the evaluation. The issue I have is that the processing of warnings does not happen until the process exits and/or R is shut down. Evaluating `warnings()` returns NULL (NILSXP). It seems like the warnings are stuck in a list out of `warnings()`'s reach, waiting to be processed. I cannot seem to find why or how to force that to happen. The embedded R is interactive (R_Interactive is 1). Moreover, when the evaluation of another R expression after the warnings results in an R error I get the error message shown followed by pending warnings. When tracing what happens during an error I found that verrorcall_dflt() in src/main/errors.c calls PrintWarnings(). That function is not part of R's C-API though. Would anyone have a suggestion about what I am missing? Best, Laurent [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Inconsistent behavior for the C AP's R_ParseVector() ?
Hi Simon,
Widespread errors would have caught my earlier as the way that code is
using only one initialization of the embedded R, is used quite a bit, and
is covered by quite a few unit tests. This is the only situation I am aware
of in which an error occurs.
What is a "correct context", or initial context, the code should from ?
Searching for "context" in the R-exts manual does not return much.
Best,
Laurent
Le sam. 14 déc. 2019 à 12:20, Simon Urbanek a
écrit :
> Laurent,
>
> the main point here is that ParseVector() just like any other R API has to
> be called in a correct context since it can raise errors so the issue was
> that your C code has a bug of not setting R correctly (my guess would be
> your'e not creating the initial context necessary in embedded R). There are
> many different errors, your is just one of many that can occur - any R API
> call that does allocation (and parsing obviously does) can cause errors.
> Note that this is true for pretty much all R API functions.
>
> Cheers,
> Simon
>
>
>
> > On Dec 14, 2019, at 11:25 AM, Laurent Gautier
> wrote:
> >
> > Le lun. 9 déc. 2019 à 09:57, Tomas Kalibera a
> > écrit :
> >
> >> On 12/9/19 2:54 PM, Laurent Gautier wrote:
> >>
> >>
> >>
> >> Le lun. 9 déc. 2019 à 05:43, Tomas Kalibera
> a
> >> écrit :
> >>
> >>> On 12/7/19 10:32 PM, Laurent Gautier wrote:
> >>>
> >>> Thanks for the quick response Tomas.
> >>>
> >>> The same error is indeed happening when trying to have a zero-length
> >>> variable name in an environment. The surprising bit is then "why is
> this
> >>> happening during parsing" (that is why are variables assigned to an
> >>> environment) ?
> >>>
> >>> The emitted R error (in the R console) is not a parse (syntax) error,
> but
> >>> an error emitted during parsing when the parser tries to intern a name
> -
> >>> look it up in a symbol table. Empty string is not allowed as a symbol
> name,
> >>> and hence the error. In the call "list(''=1)" , the empty name is what
> >>> could eventually become a name of a local variable inside list(), even
> >>> though not yet during parsing.
> >>>
> >>
> >> Thanks Tomas.
> >>
> >> I guess this has do with R expressions being lazily evaluated, and names
> >> of arguments in a call are also part of the expression. Now the puzzling
> >> part is why is that at all part of the parsing: I would have expected
> >> R_ParseVector() to be restricted to parsing... Now it feels like
> >> R_ParseVector() is performing parsing, and a first level of evalution
> for
> >> expressions that "should never work" (the empty name).
> >>
> >> Think of it as an exception in say Python. Some failures during parsing
> >> result in an exception (called error in R and implemented using a long
> >> jump). Any time you are calling into R you can get an error; out of
> memory
> >> is also signalled as R error.
> >>
> >
> >
> > The surprising bit for me was that I had expected the function to solely
> > perform parsing. I did expect an exception (and a jmp smashing the stack)
> > when the function concerned is in the C-API, is parsing a string, and is
> > using a parameter (pointer) to store whether parsing was a failure or a
> > success.
> >
> > Since you are making a comparison with Python, the distinction I am
> making
> > between parsing and evaluation seem to apply there. For example:
> >
> > ```
> >>>> import parser
> >>>> parser.expr('1+')
> > Traceback (most recent call last):
> > File "", line 1, in
> > File "", line 1
> >1+
> > ^
> > SyntaxError: unexpected EOF while parsing
> >>>> p = parser.expr('list(""=1)')
> >>>> p
> >
> >>>> eval(p)
> > Traceback (most recent call last):
> > File "", line 1, in
> > TypeError: eval() arg 1 must be a string, bytes or code object
> >
> >>>> list(""=1)
> > File "", line 1
> > SyntaxError: keyword can't be an expression
> > ```
> >
> >
> >> There is probably some error in how the external code is handling R
> >>> errors (Fatal error: unable to initialize the JIT, stack smashing,
> etc)
> >>> and possibly also how R is initialized before calling ParseVector.
> Probably
&
Re: [Rd] Inconsistent behavior for the C AP's R_ParseVector() ?
Le lun. 9 déc. 2019 à 09:57, Tomas Kalibera a
écrit :
> On 12/9/19 2:54 PM, Laurent Gautier wrote:
>
>
>
> Le lun. 9 déc. 2019 à 05:43, Tomas Kalibera a
> écrit :
>
>> On 12/7/19 10:32 PM, Laurent Gautier wrote:
>>
>> Thanks for the quick response Tomas.
>>
>> The same error is indeed happening when trying to have a zero-length
>> variable name in an environment. The surprising bit is then "why is this
>> happening during parsing" (that is why are variables assigned to an
>> environment) ?
>>
>> The emitted R error (in the R console) is not a parse (syntax) error, but
>> an error emitted during parsing when the parser tries to intern a name -
>> look it up in a symbol table. Empty string is not allowed as a symbol name,
>> and hence the error. In the call "list(''=1)" , the empty name is what
>> could eventually become a name of a local variable inside list(), even
>> though not yet during parsing.
>>
>
> Thanks Tomas.
>
> I guess this has do with R expressions being lazily evaluated, and names
> of arguments in a call are also part of the expression. Now the puzzling
> part is why is that at all part of the parsing: I would have expected
> R_ParseVector() to be restricted to parsing... Now it feels like
> R_ParseVector() is performing parsing, and a first level of evalution for
> expressions that "should never work" (the empty name).
>
> Think of it as an exception in say Python. Some failures during parsing
> result in an exception (called error in R and implemented using a long
> jump). Any time you are calling into R you can get an error; out of memory
> is also signalled as R error.
>
The surprising bit for me was that I had expected the function to solely
perform parsing. I did expect an exception (and a jmp smashing the stack)
when the function concerned is in the C-API, is parsing a string, and is
using a parameter (pointer) to store whether parsing was a failure or a
success.
Since you are making a comparison with Python, the distinction I am making
between parsing and evaluation seem to apply there. For example:
```
>>> import parser
>>> parser.expr('1+')
Traceback (most recent call last):
File "", line 1, in
File "", line 1
1+
^
SyntaxError: unexpected EOF while parsing
>>> p = parser.expr('list(""=1)')
>>> p
>>> eval(p)
Traceback (most recent call last):
File "", line 1, in
TypeError: eval() arg 1 must be a string, bytes or code object
>>> list(""=1)
File "", line 1
SyntaxError: keyword can't be an expression
```
> There is probably some error in how the external code is handling R
>> errors (Fatal error: unable to initialize the JIT, stack smashing, etc)
>> and possibly also how R is initialized before calling ParseVector. Probably
>> you would get the same problem when running say "stop('myerror')". Please
>> note R errors are implemented as long-jumps, so care has to be taken when
>> calling into R, Writing R Extensions has more details (and section 8
>> specifically about embedding R). This is unlike parse (syntax) errors
>> signaled via return value to ParseVector()
>>
>
> The issue is that the segfault (because of stack smashing, therefore
> because of what also suspected to be an incontrolled jump) is happening
> within the execution of R_ParseVector(). I would think that an issue with
> the initialization of R is less likely because the project is otherwise
> used a fair bit and is well covered by automated continuous tests.
>
> After looking more into R's gram.c I suspect that an execution context is
> required for R_ParseVector() to know to properly work (know where to jump
> in case of error) when the parsing code decides to fail outside what it
> thinks is a syntax error. If the case, this would make R_ParseVector()
> function well when called from say, a C-extension to an R package, but fail
> the way I am seeing it fail when called from an embedded R.
>
> Yes, contexts are used internally to handle errors. For external use
> please see Writing R Extensions, section 6.12.
>
I have wrapped my call to R_ParseVector() in a R_tryCatchError(), and this
is seems to help me overcome the issue. Thanks for the pointer.
Best,
Laurent
> Best
> Tomas
>
>
> Best,
>
> Laurent
>
>> Best,
>> Tomas
>>
>>
>> We are otherwise aware that the error is not occurring in the R console,
>> but can be traced to a call to R_ParseVector() in R's C API:(
>> https://github.com/rpy2/rpy2/blob/master/rpy2/rinterface_lib/_rinterface_capi.py#L509
>> ).
>>
Re: [Rd] Inconsistent behavior for the C AP's R_ParseVector() ?
Le lun. 9 déc. 2019 à 05:43, Tomas Kalibera a
écrit :
> On 12/7/19 10:32 PM, Laurent Gautier wrote:
>
> Thanks for the quick response Tomas.
>
> The same error is indeed happening when trying to have a zero-length
> variable name in an environment. The surprising bit is then "why is this
> happening during parsing" (that is why are variables assigned to an
> environment) ?
>
> The emitted R error (in the R console) is not a parse (syntax) error, but
> an error emitted during parsing when the parser tries to intern a name -
> look it up in a symbol table. Empty string is not allowed as a symbol name,
> and hence the error. In the call "list(''=1)" , the empty name is what
> could eventually become a name of a local variable inside list(), even
> though not yet during parsing.
>
Thanks Tomas.
I guess this has do with R expressions being lazily evaluated, and names of
arguments in a call are also part of the expression. Now the puzzling part
is why is that at all part of the parsing: I would have expected
R_ParseVector() to be restricted to parsing... Now it feels like
R_ParseVector() is performing parsing, and a first level of evalution for
expressions that "should never work" (the empty name).
There is probably some error in how the external code is handling R errors
> (Fatal error: unable to initialize the JIT, stack smashing, etc) and
> possibly also how R is initialized before calling ParseVector. Probably you
> would get the same problem when running say "stop('myerror')". Please note
> R errors are implemented as long-jumps, so care has to be taken when
> calling into R, Writing R Extensions has more details (and section 8
> specifically about embedding R). This is unlike parse (syntax) errors
> signaled via return value to ParseVector()
>
The issue is that the segfault (because of stack smashing, therefore
because of what also suspected to be an incontrolled jump) is happening
within the execution of R_ParseVector(). I would think that an issue with
the initialization of R is less likely because the project is otherwise
used a fair bit and is well covered by automated continuous tests.
After looking more into R's gram.c I suspect that an execution context is
required for R_ParseVector() to know to properly work (know where to jump
in case of error) when the parsing code decides to fail outside what it
thinks is a syntax error. If the case, this would make R_ParseVector()
function well when called from say, a C-extension to an R package, but fail
the way I am seeing it fail when called from an embedded R.
Best,
Laurent
> Best,
> Tomas
>
>
> We are otherwise aware that the error is not occurring in the R console,
> but can be traced to a call to R_ParseVector() in R's C API:(
> https://github.com/rpy2/rpy2/blob/master/rpy2/rinterface_lib/_rinterface_capi.py#L509
> ).
>
> Our specific setup is calling an embedded R from Python, using the cffi
> library. An error on end was the first possibility considered, but the
> puzzling specificity of the error (as shown below other parsing errors are
> handled properly) and the difficulty tracing what is in happening in
> R_ParseVector() made me ask whether someone on this list had a suggestion
> about the possible issue"
>
> ```
>
> >>> import rpy2.rinterface as ri>>> ri.initr()>>> e = ri.parse("list(''=1+")
> >>> ---RParsingError
> >>> Traceback (most recent call last)>>> e =
> >>> ri.parse("list(''=123") R[write to console]: Error: attempt to use
> >>> zero-length variable name
> R[write to console]: Fatal error: unable to initialize the JIT
>
> *** stack smashing detected ***: terminated
> ```
>
>
> Le lun. 2 déc. 2019 à 06:37, Tomas Kalibera a
> écrit :
>
>> Dear Laurent,
>>
>> could you please provide a complete reproducible example where parsing
>> results in a crash of R? Calling parse(text="list(''=123") from R works
>> fine for me (gives Error: attempt to use zero-length variable name).
>>
>> I don't think the problem you observed could be related to the memory
>> leak. The leak is on the heap, not stack.
>>
>> Zero-length names of elements in a list are allowed. They are not the
>> same thing as zero-length variables in an environment. If you try to
>> convert "lst" from your example to an environment, you would get the
>> error (attempt to use zero-length variable name).
>>
>> Best
>> Tomas
>>
>>
>> On 11/30/19 11:55 PM, Laurent Gautier wrote:
>> > Hi again,
>> >
>> > Beside R_Par
Re: [Rd] Inconsistent behavior for the C AP's R_ParseVector() ?
Thanks for the quick response Tomas.
The same error is indeed happening when trying to have a zero-length
variable name in an environment. The surprising bit is then "why is this
happening during parsing" (that is why are variables assigned to an
environment) ?
We are otherwise aware that the error is not occurring in the R console,
but can be traced to a call to R_ParseVector() in R's C API:(
https://github.com/rpy2/rpy2/blob/master/rpy2/rinterface_lib/_rinterface_capi.py#L509
).
Our specific setup is calling an embedded R from Python, using the cffi
library. An error on end was the first possibility considered, but the
puzzling specificity of the error (as shown below other parsing errors are
handled properly) and the difficulty tracing what is in happening in
R_ParseVector() made me ask whether someone on this list had a suggestion
about the possible issue"
```
>>> import rpy2.rinterface as ri>>> ri.initr()>>> e = ri.parse("list(''=1+")
>>> ---RParsingError
>>> Traceback (most recent call last)
>>> e = ri.parse("list(''=123") R[write to console]: Error: attempt to use
>>> zero-length variable name
R[write to console]: Fatal error: unable to initialize the JIT
*** stack smashing detected ***: terminated
```
Le lun. 2 déc. 2019 à 06:37, Tomas Kalibera a
écrit :
> Dear Laurent,
>
> could you please provide a complete reproducible example where parsing
> results in a crash of R? Calling parse(text="list(''=123") from R works
> fine for me (gives Error: attempt to use zero-length variable name).
>
> I don't think the problem you observed could be related to the memory
> leak. The leak is on the heap, not stack.
>
> Zero-length names of elements in a list are allowed. They are not the
> same thing as zero-length variables in an environment. If you try to
> convert "lst" from your example to an environment, you would get the
> error (attempt to use zero-length variable name).
>
> Best
> Tomas
>
>
> On 11/30/19 11:55 PM, Laurent Gautier wrote:
> > Hi again,
> >
> > Beside R_ParseVector()'s possible inconsistent behavior, R's handling of
> > zero-length named elements does not seem consistent either:
> >
> > ```
> >> lst <- list()
> >> lst[[""]] <- 1
> >> names(lst)
> > [1] ""
> >> list("" = 1)
> > Error: attempt to use zero-length variable name
> > ```
> >
> > Should the parser be made to accept as valid what is otherwise possible
> > when using `[[<` ?
> >
> >
> > Best,
> >
> > Laurent
> >
> >
> >
> > Le sam. 30 nov. 2019 à 17:33, Laurent Gautier a
> écrit :
> >
> >> I found the following code comment in `src/main/gram.c`:
> >>
> >> ```
> >>
> >> /* Memory leak
> >>
> >> yyparse(), as generated by bison, allocates extra space for the parser
> >> stack using malloc(). Unfortunately this means that there is a memory
> >> leak in case of an R error (long-jump). In principle, we could define
> >> yyoverflow() to relocate the parser stacks for bison and allocate say on
> >> the R heap, but yyoverflow() is undocumented and somewhat complicated
> >> (we would have to replicate some macros from the generated parser here).
> >> The same problem exists at least in the Rd and LaTeX parsers in tools.
> >> */
> >>
> >> ```
> >>
> >> Could this be related to be issue ?
> >>
> >> Le sam. 30 nov. 2019 à 14:04, Laurent Gautier a
> >> écrit :
> >>
> >>> Hi,
> >>>
> >>> The behavior of
> >>> ```
> >>> SEXP R_ParseVector(SEXP, int, ParseStatus *, SEXP);
> >>> ```
> >>> defined in `src/include/R_ext/Parse.h` appears to be inconsistent
> >>> depending on the string to be parsed.
> >>>
> >>> Trying to parse a string such as `"list(''=1+"` sets the
> >>> `ParseStatus` to incomplete parsing error but trying to parse
> >>> `"list(''=123"` will result in R sending a message to the console
> (followed but a crash):
> >>>
> >>> ```
> >>> R[write to console]: Error: attempt to use zero-length variable
> nameR[write to console]: Fatal error: unable to initialize the JIT*** stack
> smashing detected ***: terminated
> >>> ```
> >>>
> >>> Is there a reason for the difference in behavior, and is there a
> workaround ?
> >>>
> >>> Thanks,
> >>>
> >>>
> >>> Laurent
> >>>
> >>>
> > [[alternative HTML version deleted]]
> >
> > __
> > 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] Inconsistent behavior for the C AP's R_ParseVector() ?
Hi again,
Beside R_ParseVector()'s possible inconsistent behavior, R's handling of
zero-length named elements does not seem consistent either:
```
> lst <- list()
> lst[[""]] <- 1
> names(lst)
[1] ""
> list("" = 1)
Error: attempt to use zero-length variable name
```
Should the parser be made to accept as valid what is otherwise possible
when using `[[<` ?
Best,
Laurent
Le sam. 30 nov. 2019 à 17:33, Laurent Gautier a écrit :
> I found the following code comment in `src/main/gram.c`:
>
> ```
>
> /* Memory leak
>
> yyparse(), as generated by bison, allocates extra space for the parser
> stack using malloc(). Unfortunately this means that there is a memory
> leak in case of an R error (long-jump). In principle, we could define
> yyoverflow() to relocate the parser stacks for bison and allocate say on
> the R heap, but yyoverflow() is undocumented and somewhat complicated
> (we would have to replicate some macros from the generated parser here).
> The same problem exists at least in the Rd and LaTeX parsers in tools.
> */
>
> ```
>
> Could this be related to be issue ?
>
> Le sam. 30 nov. 2019 à 14:04, Laurent Gautier a
> écrit :
>
>> Hi,
>>
>> The behavior of
>> ```
>> SEXP R_ParseVector(SEXP, int, ParseStatus *, SEXP);
>> ```
>> defined in `src/include/R_ext/Parse.h` appears to be inconsistent
>> depending on the string to be parsed.
>>
>> Trying to parse a string such as `"list(''=1+"` sets the
>> `ParseStatus` to incomplete parsing error but trying to parse
>> `"list(''=123"` will result in R sending a message to the console (followed
>> but a crash):
>>
>> ```
>> R[write to console]: Error: attempt to use zero-length variable nameR[write
>> to console]: Fatal error: unable to initialize the JIT*** stack smashing
>> detected ***: terminated
>> ```
>>
>> Is there a reason for the difference in behavior, and is there a workaround ?
>>
>> Thanks,
>>
>>
>> Laurent
>>
>>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Inconsistent behavior for the C AP's R_ParseVector() ?
I found the following code comment in `src/main/gram.c`:
```
/* Memory leak
yyparse(), as generated by bison, allocates extra space for the parser
stack using malloc(). Unfortunately this means that there is a memory
leak in case of an R error (long-jump). In principle, we could define
yyoverflow() to relocate the parser stacks for bison and allocate say on
the R heap, but yyoverflow() is undocumented and somewhat complicated
(we would have to replicate some macros from the generated parser here).
The same problem exists at least in the Rd and LaTeX parsers in tools.
*/
```
Could this be related to be issue ?
Le sam. 30 nov. 2019 à 14:04, Laurent Gautier a écrit :
> Hi,
>
> The behavior of
> ```
> SEXP R_ParseVector(SEXP, int, ParseStatus *, SEXP);
> ```
> defined in `src/include/R_ext/Parse.h` appears to be inconsistent
> depending on the string to be parsed.
>
> Trying to parse a string such as `"list(''=1+"` sets the
> `ParseStatus` to incomplete parsing error but trying to parse
> `"list(''=123"` will result in R sending a message to the console (followed
> but a crash):
>
> ```
> R[write to console]: Error: attempt to use zero-length variable nameR[write
> to console]: Fatal error: unable to initialize the JIT*** stack smashing
> detected ***: terminated
> ```
>
> Is there a reason for the difference in behavior, and is there a workaround ?
>
> Thanks,
>
>
> Laurent
>
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Inconsistent behavior for the C AP's R_ParseVector() ?
Hi,
The behavior of
```
SEXP R_ParseVector(SEXP, int, ParseStatus *, SEXP);
```
defined in `src/include/R_ext/Parse.h` appears to be inconsistent depending
on the string to be parsed.
Trying to parse a string such as `"list(''=1+"` sets the
`ParseStatus` to incomplete parsing error but trying to parse
`"list(''=123"` will result in R sending a message to the console
(followed but a crash):
```
R[write to console]: Error: attempt to use zero-length variable
nameR[write to console]: Fatal error: unable to initialize the JIT***
stack smashing detected ***: terminated
```
Is there a reason for the difference in behavior, and is there a workaround ?
Thanks,
Laurent
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Error: package or namespace load failed for ‘utils
Thanks to all that looked at it and tried to answer.
I am reporting here what I found in the end, in the hope it helps someone
with a similar issue solve it quicker than I solved the one I had:
Having
int R_NaInt;
rather than
extern int R_NaInt;
in the header / C definitions of the cffi interface (part of the header
definitions have to be copied/prepared to be digestable by the C parser
used Python's cffi interface) was enough to send R into a confused state at
initialization (but without an obvious error message).
Le lun. 16 sept. 2019 à 03:55, Martin Maechler
a écrit :
> >>>>> Laurent Gautier
> >>>>> on Sun, 15 Sep 2019 15:01:09 -0400 writes:
>
> > In case a search engine leads someone with the same issue
> > here, I am documenting the point I reached:
>
> > I can reproduce the issue with a small example when
> > forcing R to not load any package at startup time (using
> > an Renviron file): ``` package <- "utils" lib.loc <-
> > "" ns <-
> > loadNamespace(package, lib.loc) ```
>
> > The code path goes through
> > `registerS3methods(nsInfo$S3methods, package, env)` and
> > there to:
>
> > ``` if (methods::is(genfun, "genericFunction")) ```
>
> > The evaluation of `methods::is` reaches the line
> > triggering the error as `.identC(class1, class2)` and
> > `.identC(class2, "ANY")` both return `NA` and `NA || NA`
> > is not defined:
>
> > ```
> >> if (NA || NA) { cat("here\n") }
> > Error in if (NA || NA) { : missing value where TRUE/FALSE
> > needed ```
>
> > As I understand it `.identC()` should never return `NA`,
>
> that understanding is correct, it should return TRUE or FALSE,
> nothing else.
>
> > and if the case this would mean that R itself is an
> > unstable state (something at the C level that should not
> > have happened has happened) but this was not caught
> > earlier.
>
> yes.. something like that...
> My current diagnosis would be that something in your embedding of R
> happened
> in a way that "broke R entirely" ...
> but note that I know almost nothing about embedding R.
>
> Martin
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Error: package or namespace load failed for ‘utils
In case a search engine leads someone with the same issue here, I am
documenting the point I reached:
I can reproduce the issue with a small example when forcing R to not load
any package at startup time (using an Renviron file):
```
package <- "utils"
lib.loc <- ""
ns <- loadNamespace(package, lib.loc)
```
The code path goes through `registerS3methods(nsInfo$S3methods, package,
env)` and there to:
```
if (methods::is(genfun, "genericFunction"))
```
The evaluation of `methods::is` reaches the line triggering the error as
`.identC(class1, class2)` and `.identC(class2, "ANY")` both return `NA` and
`NA || NA` is not defined:
```
> if (NA || NA) { cat("here\n") }
Error in if (NA || NA) { : missing value where TRUE/FALSE needed
```
As I understand it `.identC()` should never return `NA`, and if the case
this would mean that R itself is an unstable state (something at the C
level that should not have happened has happened) but this was not caught
earlier.
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Error: package or namespace load failed for ‘utils
R_HOME is not the issue, and I believe that R_LIBS is not involved with
packages such as "datasets", "utils", etc...
I suspect that the issue is around dynamic loading of C libraries, as
depending on the way the R shared library is called the issue is absent or
present, but the error reporting from R makes tracking this easy.
Le dim. 8 sept. 2019 à 13:22, William Dunlap a écrit :
> Also, check the settings of R_HOME and/or R_LIBS.
> Bill Dunlap
> TIBCO Software
> wdunlap tibco.com
>
>
> On Sun, Sep 8, 2019 at 9:58 AM William Dunlap wrote:
>
>> Look at section 6.1 of the R Installation and Admin manual.
>>
>> 6.1 Default packages
>>
>> The set of packages loaded on startup is by default
>>
>> > getOption("defaultPackages")
>> [1] "datasets" "utils" "grDevices" "graphics" "stats" "methods"
>>
>> (plus, of course, *base*) and this can be changed by setting the option
>> in startup code (e.g. in ~/.Rprofile). It is initially set to the value
>> of the environment variable R_DEFAULT_PACKAGES if set (as a
>> comma-separated list). Setting R_DEFAULT_PACKAGES=NULL ensures that only
>> package *base* is loaded.
>>
>> Changing the set of default packages is normally used to reduce the set
>> for speed when scripting: in particular not using *methods*will reduce
>> the start-up time by a factor of up to two. But it can also be used to
>> customize R, e.g. for class use. Rscript also checks the environment
>> variable R_SCRIPT_DEFAULT_PACKAGES; if set, this takes precedence over
>> R_DEFAULT_PACKAGES.
>> Bill Dunlap
>> TIBCO Software
>> wdunlap tibco.com
>>
>>
>> On Sun, Sep 8, 2019 at 8:42 AM Laurent Gautier
>> wrote:
>>
>>> Hi,
>>>
>>> When starting an embedded R I encounter the following issue under certain
>>> conditions:
>>>
>>> ```
>>> Error: package or namespace load failed for ‘utils’ in if
>>> (.identC(class1,
>>> class2) || .identC(class2, "ANY")) TRUE else {:
>>> missing value where TRUE/FALSE needed
>>> ```
>>> (more such errors for grDevices, graphics, and stats)
>>>
>>> And in the end:
>>>
>>> ```
>>> Warning messages:
>>> 1: package ‘utils’ in options("defaultPackages") was not found
>>> 2: package ‘grDevices’ in options("defaultPackages") was not found
>>> 3: package ‘graphics’ in options("defaultPackages") was not found
>>> 4: package ‘stats’ in options("defaultPackages") was not found
>>> ```
>>>
>>> While the embedded R appears functional, no package can be loaded.
>>>
>>> The erorr message from R (`missing value where TRUE/FALSE needed`)
>>> suggests
>>> that R should be able to catch the underlying issue (I am yet to find
>>> what
>>> it is) earlier and with this make the task of troubleshooting easier.
>>>
>>> Best,
>>>
>>>
>>> Laurent
>>>
>>> [[alternative HTML version deleted]]
>>>
>>> __
>>> 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] Error: package or namespace load failed for ‘utils
Hi,
Thanks, but I am unsure this helps.
The point I am making is that an R error (about a missing value where a
boolean would be expected), originating from the package methods, is not
informative. This is indicating that a core R function involved in the
loading of an R packages may receive invalid arguments, and rather than the
current situation I believe that such invalid arguments should be
identified earlier with a more meaningful error message (as in an error
message leading to the root of the issue) produced.
L.
Le dim. 8 sept. 2019 à 12:58, William Dunlap a écrit :
> Look at section 6.1 of the R Installation and Admin manual.
>
> 6.1 Default packages
>
> The set of packages loaded on startup is by default
>
> > getOption("defaultPackages")
> [1] "datasets" "utils" "grDevices" "graphics" "stats" "methods"
>
> (plus, of course, *base*) and this can be changed by setting the option
> in startup code (e.g. in ~/.Rprofile). It is initially set to the value
> of the environment variable R_DEFAULT_PACKAGES if set (as a
> comma-separated list). Setting R_DEFAULT_PACKAGES=NULL ensures that only
> package *base* is loaded.
>
> Changing the set of default packages is normally used to reduce the set
> for speed when scripting: in particular not using *methods*will reduce
> the start-up time by a factor of up to two. But it can also be used to
> customize R, e.g. for class use. Rscript also checks the environment
> variable R_SCRIPT_DEFAULT_PACKAGES; if set, this takes precedence over
> R_DEFAULT_PACKAGES.
> Bill Dunlap
> TIBCO Software
> wdunlap tibco.com
>
>
> On Sun, Sep 8, 2019 at 8:42 AM Laurent Gautier wrote:
>
>> Hi,
>>
>> When starting an embedded R I encounter the following issue under certain
>> conditions:
>>
>> ```
>> Error: package or namespace load failed for ‘utils’ in if (.identC(class1,
>> class2) || .identC(class2, "ANY")) TRUE else {:
>> missing value where TRUE/FALSE needed
>> ```
>> (more such errors for grDevices, graphics, and stats)
>>
>> And in the end:
>>
>> ```
>> Warning messages:
>> 1: package ‘utils’ in options("defaultPackages") was not found
>> 2: package ‘grDevices’ in options("defaultPackages") was not found
>> 3: package ‘graphics’ in options("defaultPackages") was not found
>> 4: package ‘stats’ in options("defaultPackages") was not found
>> ```
>>
>> While the embedded R appears functional, no package can be loaded.
>>
>> The erorr message from R (`missing value where TRUE/FALSE needed`)
>> suggests
>> that R should be able to catch the underlying issue (I am yet to find what
>> it is) earlier and with this make the task of troubleshooting easier.
>>
>> Best,
>>
>>
>> Laurent
>>
>> [[alternative HTML version deleted]]
>>
>> __
>> 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] Error: package or namespace load failed for ‘utils
Hi,
When starting an embedded R I encounter the following issue under certain
conditions:
```
Error: package or namespace load failed for ‘utils’ in if (.identC(class1,
class2) || .identC(class2, "ANY")) TRUE else {:
missing value where TRUE/FALSE needed
```
(more such errors for grDevices, graphics, and stats)
And in the end:
```
Warning messages:
1: package ‘utils’ in options("defaultPackages") was not found
2: package ‘grDevices’ in options("defaultPackages") was not found
3: package ‘graphics’ in options("defaultPackages") was not found
4: package ‘stats’ in options("defaultPackages") was not found
```
While the embedded R appears functional, no package can be loaded.
The erorr message from R (`missing value where TRUE/FALSE needed`) suggests
that R should be able to catch the underlying issue (I am yet to find what
it is) earlier and with this make the task of troubleshooting easier.
Best,
Laurent
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [External] Missing function Rf_findFun3
I am not using the C API from a package but with an embedded R. Why have it declared in the include/ if it cannot be accessed then? Best, Laurent On Sun, Sep 8, 2019, 8:27 AM Tierney, Luke wrote: > On Sat, 7 Sep 2019, Laurent Gautier wrote: > > > Hi, > > > > > > The function `Rf_findFun3` is declared in > > `$(R CMD CONFIG HOME)/lib/R/include/Rinternals.h` > > but appears to be missing from R's shared library (R.so). > > > > Is this an oversight? > > No. This is not part of the API supported for use in packages. > > Best, > > luke > > > > > Best, > > > > Laurent > > > > [[alternative HTML version deleted]] > > > > __ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > -- > Luke Tierney > Ralph E. Wareham Professor of Mathematical Sciences > University of Iowa Phone: 319-335-3386 > Department of Statistics andFax: 319-335-3017 > Actuarial Science > 241 Schaeffer Hall email: luke-tier...@uiowa.edu > Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Missing function Rf_findFun3
Hi, The function `Rf_findFun3` is declared in `$(R CMD CONFIG HOME)/lib/R/include/Rinternals.h` but appears to be missing from R's shared library (R.so). Is this an oversight? Best, Laurent [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Warning when calling formals() for `[`.
Note that having "function" in its class attribute does not make an object
a primitive.
For example:
> class(`[`)
[1] "function"
> is.primitive(`[`)
[1] TRUE
> class(`rnorm`)
[1] "function"
> is.primitive(`rnorm`)
[1] FALSE
Le dim. 7 oct. 2018 à 10:04, Rui Barradas a écrit :
> Hello,
>
> I don't see why you say that the documentation seems to be wrong:
>
>
> class(args(`+`))
> #[1] "function"
>
>
> args() on a primitive does return a closure. At least in this case it does.
>
>
> Rui Barradas
>
> Às 14:05 de 07/10/2018, Peter Dalgaard escreveu:
> > There is more "fun" afoot here, but I don't recall what the point may be:
> >
> >> args(get("+"))
> > function (e1, e2)
> > NULL
> >> args(get("["))
> > NULL
> >> get("[")
> > .Primitive("[")
> >> get("+")
> > function (e1, e2) .Primitive("+")
> >
> > The other index operators, "[[", "[<-", "[[<-" are similar
> >
> > The docs are pretty clear that args() on a primitive should yield a
> closure, so at least the documentation seems to be wrong.
> >
> > -pd
> >
> >
> >> On 6 Oct 2018, at 19:26 , Laurent Gautier wrote:
> >>
> >> Hi,
> >>
> >> A short code example showing the warning might the only thing needed
> here:
> >>
> >> ```
> >>> formals(args(`[`))
> >> NULL
> >>
> >> *Warning message:In formals(fun) : argument is not a function*
> >>> is.function(`[`)
> >> [1] TRUE
> >>> is.primitive(`[`)
> >> [1] TRUE
> >> ```
> >>
> >> Now with an other primitive:
> >>
> >> ```
> >>> formals(args(`sum`))
> >> $...
> >>
> >>
> >> $na.rm
> >> [1] FALSE
> >>
> >>> is.function(`sum`)
> >> [1] TRUE
> >>> is.primitive(`sum`)
> >> [1] TRUE
> >>> class(`[`)
> >> [1] "function"
> >> ```
> >>
> >> Is this a feature ?
> >>
> >>
> >> Laurent
> >>
> >> [[alternative HTML version deleted]]
> >>
> >> __
> >> 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] Warning when calling formals() for `[`.
Hi, Thanks for the note. How would explain the following snippet taken from `formals` doc page (the code comment is also from that doc) ? ## formals returns NULL for primitive functions. Use it in combination with ## args for this case. is.primitive(`+`) formals(`+`) formals(args(`+`)) Le sam. 6 oct. 2018 à 13:42, Rui Barradas a écrit : > Hello, > > I believe that this is maybe not a *feature* but at least expected > behaviour. > > The call formals(args(`[`)) breaks down to > > > > args(`[`) > NULL > > formals(NULL) > NULL > Warning message: > In formals(fun) : argument is not a function > > > Hope this helps, > > Rui Barradas > > > Às 18:26 de 06/10/2018, Laurent Gautier escreveu: > > Hi, > > > > A short code example showing the warning might the only thing needed > here: > > > > ``` > >> formals(args(`[`)) > > NULL > > > > *Warning message:In formals(fun) : argument is not a function* > >> is.function(`[`) > > [1] TRUE > >> is.primitive(`[`) > > [1] TRUE > > ``` > > > > Now with an other primitive: > > > > ``` > >> formals(args(`sum`)) > > $... > > > > > > $na.rm > > [1] FALSE > > > >> is.function(`sum`) > > [1] TRUE > >> is.primitive(`sum`) > > [1] TRUE > >> class(`[`) > > [1] "function" > > ``` > > > > Is this a feature ? > > > > > > Laurent > > > > [[alternative HTML version deleted]] > > > > __ > > 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] Warning when calling formals() for `[`.
Hi, A short code example showing the warning might the only thing needed here: ``` > formals(args(`[`)) NULL *Warning message:In formals(fun) : argument is not a function* > is.function(`[`) [1] TRUE > is.primitive(`[`) [1] TRUE ``` Now with an other primitive: ``` > formals(args(`sum`)) $... $na.rm [1] FALSE > is.function(`sum`) [1] TRUE > is.primitive(`sum`) [1] TRUE > class(`[`) [1] "function" ``` Is this a feature ? Laurent [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Definition of uintptr_t in Rinterface.h
My comment is about the definition of HAVE_UINTPTR_T in Rconfig.h. stdint.h is coming with (g)libc, therefore unlikely to change/appear/disappear (unless kernel and a bit of the OS changes), therefore may not be a realistic concern. On the other hand mixing compilers is frequent, but this is not doing much to prevent it. 2017-01-01 19:42 GMT-05:00 Simon Urbanek <simon.urba...@r-project.org>: > > > On Jan 1, 2017, at 5:12 PM, Laurent Gautier <lgaut...@gmail.com> wrote: > > > > > > > > 2017-01-01 8:28 GMT-05:00 Prof Brian Ripley <rip...@stats.ox.ac.uk>: > > On 29/12/2016 15:55, Simon Urbanek wrote: > > The problem is elsewhere - Rinterface.h guards the ultima-ratio fallback > with HAVE_UINTPTR_T but that config flag is not exported in Rconfig.h. > Should be now fixed in R-devel - please check if that works for you. > > > > Rconfig.h would be appropriate if Rinterface.h is being included from C > code using the same compiler as used for R. But as Rinterface.h is > intended for use by alternative front ends there is no guarantee that they > use the same compiler (and some use C++). > > > > Isn't the changing libc/glibc not recommended anyway (without also > changing to a matching kernel) ? If so, is this a realistic concern > compared to the compiler version issues (mentioned by Dirk) ? In that case, > what about simplifying the documentation and usage to "use the same > compiler or undefined behaviour may occur" > > > > Unfortunately people often mix up different compilers (note this has > nothing to do with glibc or the kernel!) - mixing up C and C++ is very > common. Also there are specialized compilers for some applications (MPI > etc.). So, yes, it is a realistic concern that I've seen more often than > you'd think. > > > > > > This was documented in the manual: > > > > 'Note that uintptr_t is a C99 type for which a substitute is defined in > R, so your code needs to define HAVE_UINTPTR_T appropriately.' > > > > AFAICS if you comply, there will not be a conflict. > > > > Also note that is only an issue if CSTACK_DEFNS is defined, not the > default and not mentioned here. > > > > > > > > > > Thanks, > > Simon > > > > > > > > On Dec 26, 2016, at 11:25 PM, Laurent Gautier <lgaut...@gmail.com> > wrote: > > (...) > > > > Is this expected ? Shouldn't R rely on the definition in stdint.h > > > > But there need not be one in stdint.h, as the type is optional in > C99/C11/C++11 and likely not present in C++98. > > > > AFAIUI stdin.h is part of C99: https://en.wikipedia.org/wiki/ > C_standard_library#Header_files > > > > While at it, it is not exactly like C99 is the latest thing in town. > Wouldn't relying on it give an opportunity to simplify the code base ? > > > > > > > > > > Laurent > > > > > > > > > > rather than define its own ? > > > > > > (report for the issue: > > https://bitbucket.org/rpy2/rpy2/issues/389/failed-to- > compile-with-python-360-on-32 > > ) > > > > > > Laurent > > > > > > > > -- > > Brian D. Ripley, rip...@stats.ox.ac.uk > > Emeritus Professor of Applied Statistics, University of Oxford > > > > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Definition of uintptr_t in Rinterface.h
2017-01-01 8:28 GMT-05:00 Prof Brian Ripley <rip...@stats.ox.ac.uk>: > On 29/12/2016 15:55, Simon Urbanek wrote: > >> The problem is elsewhere - Rinterface.h guards the ultima-ratio fallback >> with HAVE_UINTPTR_T but that config flag is not exported in Rconfig.h. >> Should be now fixed in R-devel - please check if that works for you. >> > > Rconfig.h would be appropriate if Rinterface.h is being included from C > code using the same compiler as used for R. But as Rinterface.h is > intended for use by alternative front ends there is no guarantee that they > use the same compiler (and some use C++). > Isn't the changing libc/glibc not recommended anyway (without also changing to a matching kernel) ? If so, is this a realistic concern compared to the compiler version issues (mentioned by Dirk) ? In that case, what about simplifying the documentation and usage to "use the same compiler or undefined behaviour may occur" > This was documented in the manual: > > 'Note that uintptr_t is a C99 type for which a substitute is defined in R, > so your code needs to define HAVE_UINTPTR_T appropriately.' > > AFAICS if you comply, there will not be a conflict. > > Also note that is only an issue if CSTACK_DEFNS is defined, not the > default and not mentioned here. > > > > > Thanks, >> Simon >> >> >> >> On Dec 26, 2016, at 11:25 PM, Laurent Gautier <lgaut...@gmail.com> wrote: >>> (...) >>> >>> Is this expected ? Shouldn't R rely on the definition in stdint.h >>> >> > But there need not be one in stdint.h, as the type is optional in > C99/C11/C++11 and likely not present in C++98. AFAIUI stdin.h is part of C99: https://en.wikipedia.org/wiki/C_standard_library#Header_files While at it, it is not exactly like C99 is the latest thing in town. Wouldn't relying on it give an opportunity to simplify the code base ? Laurent > > rather than define its own ? >>> >>> >>> (report for the issue: >>> https://bitbucket.org/rpy2/rpy2/issues/389/failed-to-compile >>> -with-python-360-on-32 >>> ) >>> >>> >>> Laurent >>> >>> > > -- > Brian D. Ripley, rip...@stats.ox.ac.uk > Emeritus Professor of Applied Statistics, University of Oxford > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Definition of uintptr_t in Rinterface.h
Thanks for looking at it. Having HAVE_UINTPTR_T defined in Rconfig.h should fix the issue. Will the fix make it to R-3.3.3 (if that point release is planned, or R-3.3.2-patched), or will it only be with R-3.4 ? L. PS: I am forwarding a thank you note to the reporter of the problem on the rpy2 issue tracker. 2016-12-29 10:55 GMT-05:00 Simon Urbanek <simon.urba...@r-project.org>: > The problem is elsewhere - Rinterface.h guards the ultima-ratio fallback > with HAVE_UINTPTR_T but that config flag is not exported in Rconfig.h. > Should be now fixed in R-devel - please check if that works for you. > > Thanks, > Simon > > > > > On Dec 26, 2016, at 11:25 PM, Laurent Gautier <lgaut...@gmail.com> > wrote: > > > > Hi, > > > > I was recently pointed out that a definition in Rinterface.h can be > conflicting > > with a definition in stdint.h: > > > > /usr/include/R/Rinterface.h has: > > typedef unsigned long uintptr_t; > > > > /usr/include/stdint.h has: > > typedef unsigned int uintptr_t; > > (when 32bit platform complete definition is: > > > > #if __WORDSIZE == 64 > > # ifndef __intptr_t_defined > > typedef long intintptr_t; > > # define __intptr_t_defined > > # endif > > typedef unsigned long int uintptr_t; > > #else > > # ifndef __intptr_t_defined > > typedef int intptr_t; > > # define __intptr_t_defined > > # endif > > typedef unsigned intuintptr_t; > > #endif > > > > ) > > > > Is this expected ? Shouldn't R rely on the definition in stdint.h > > rather than define its own ? > > > > > > (report for the issue: > > https://bitbucket.org/rpy2/rpy2/issues/389/failed-to- > compile-with-python-360-on-32 > > ) > > > > > > Laurent > > > > [[alternative HTML version deleted]] > > > > __ > > 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] Definition of uintptr_t in Rinterface.h
Hi, I was recently pointed out that a definition in Rinterface.h can be conflicting with a definition in stdint.h: /usr/include/R/Rinterface.h has: typedef unsigned long uintptr_t; /usr/include/stdint.h has: typedef unsigned int uintptr_t; (when 32bit platform complete definition is: #if __WORDSIZE == 64 # ifndef __intptr_t_defined typedef long intintptr_t; # define __intptr_t_defined # endif typedef unsigned long int uintptr_t; #else # ifndef __intptr_t_defined typedef int intptr_t; # define __intptr_t_defined # endif typedef unsigned intuintptr_t; #endif ) Is this expected ? Shouldn't R rely on the definition in stdint.h rather than define its own ? (report for the issue: https://bitbucket.org/rpy2/rpy2/issues/389/failed-to-compile-with-python-360-on-32 ) Laurent [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] C-API: check whether R has been initialized ?
On May 4, 2015 12:06 AM, Simon Urbanek simon.urba...@r-project.org
wrote:
Laurent,
On May 3, 2015, at 8:07 PM, Laurent Gautier lgaut...@gmail.com wrote:
rPython appears to provide an interface from R to Python by embedding
Python and I'd think that it can safely assume that R has been
initialized,
but might not be the point here.
The issue is that a Python package embedding itself R (here rpy2)
appears
to have no way to know that earlier in the life of the process R was
initialized.
Duncan's point was that it has - since it would have to embed R itself
and thus record the initialization. I suppose you're asking about a case
where you want to detect that something else already started R so you can't
embed it yourself anymore and thus have to abort -- one side-effect check
is to see if R_NilValue is NULL since that would only be the case if R was
not started yet.
The nesting of embedded Rs is obviously conceptual since the R C library
will only be found once in a process address space. The testing would allow
to keep that coherence (as far as rpy2 is concerned R is embedded, although
if coming from say rPython R has already been started).
If checking R_NilValue is the way to test whether R has been initialized,
why isn't R using it rather than have its own variable (and that variable
jealously made unreadable from this thread) ?
Also, I would necessarily want to abort if R has already been initialized.
One can think about it as a stateful library, and I should be able to just
skip the initialization and go on.
Note, however, that if you didn't initialize it you can't embed it.
Cheers,
Simon
PS: there are much better interfaces to Python than rPython (which is
mostly dysfunctional) - see
http://www.omegahat.org/RSPython
https://github.com/s-u/rpython
I am seeing rpy2 as way to run R code from Python, and while I may have
preferences about how and what to run I am trying to make running any R
code possible.
PPS: I wish you didn't hide the capsulling in rpy2 since that prevents us
from having common references that rpy2 can use (please contact me off the
list).
The way it is generally working is that you contact me about wishes for
rpy2.
Think of the precedent it would make and the rather entertaining replies to
posts such as I wish feature X in R was different, please contact me at
your earliest convenience with a proposal and an aggressive timeline
blooming on R-dev would trigger.
;-)
Joke aside, personal email is fine but unless there is a reason not to I
like to use the issue tracker on bitbucket so the discussion and reason for
a decision can be consulted by all.
PS: I have unpublished code playing with R's internals from Python were the
opacity of the capsule made me provide access to pointers. May be I should
clean that up and try to integrate it.
2015-05-03 19:48 GMT-04:00 Duncan Murdoch murdoch.dun...@gmail.com:
On 03/05/2015 7:02 PM, Laurent Gautier wrote:
Beside the possible argumentation that with an API elegance and
convenience might sometimes be superior to necessity, the suggested
pattern (every program, including R itself, keeping its own flag)
does
no work too well when the nested embedding of R is involved.
A concrete example is:
```
$ R -q
library('rPython'); python.exec('import rpy2.robjects')
R is already initialized
```
I don't know rPython at all, but surely this is an rPython bug. When
the package is loaded by library('rPython'), R is obviously
initialized. You don't need to query it to ask that.
The standard R front-ends don't need a flag to know if it is
initialized. They initialize, then go into the read-eval-print loop.
If they are in that loop, R is initialized. If it failed to
initialize,
they would never get to that loop.
Other front-ends may do other things besides run R, so they do need to
know if it is initialized, but surely they can keep a flag telling them
whether they've succeeded in initializing it.
Duncan Murdoch
[[alternative HTML version deleted]]
__
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] C-API: check whether R has been initialized ?
Hi, There appear to be no way to check whether R has already been initialized. Could a function like Rf_isinitialized be added to the API ? Best, Laurent [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] C-API: check whether R has been initialized ?
Beside the possible argumentation that with an API elegance and convenience
might sometimes be superior to necessity, the suggested pattern (every
program, including R itself, keeping its own flag) does no work too well
when the nested embedding of R is involved.
A concrete example is:
```
$ R -q
library('rPython'); python.exec('import rpy2.robjects')
R is already initialized
```
https://bitbucket.org/rpy2/rpy2/issue/278/r-in-python-via-rpy2-in-r-via-rpython#comment-17843761
2015-05-03 18:12 GMT-04:00 Duncan Murdoch murdoch.dun...@gmail.com:
On 03/05/2015 4:34 PM, Laurent Gautier wrote:
Hi,
There appear to be no way to check whether R has already been
initialized.
Could a function like Rf_isinitialized be added to the API ?
Surely any program that needs to know that could keep its own flag.
You'll need to give a much longer argument about why this is necessary
for what you're doing.
Duncan Murdoch
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] C-API: check whether R has been initialized ?
rPython appears to provide an interface from R to Python by embedding
Python and I'd think that it can safely assume that R has been initialized,
but might not be the point here.
The issue is that a Python package embedding itself R (here rpy2) appears
to have no way to know that earlier in the life of the process R was
initialized.
2015-05-03 19:48 GMT-04:00 Duncan Murdoch murdoch.dun...@gmail.com:
On 03/05/2015 7:02 PM, Laurent Gautier wrote:
Beside the possible argumentation that with an API elegance and
convenience might sometimes be superior to necessity, the suggested
pattern (every program, including R itself, keeping its own flag) does
no work too well when the nested embedding of R is involved.
A concrete example is:
```
$ R -q
library('rPython'); python.exec('import rpy2.robjects')
R is already initialized
```
I don't know rPython at all, but surely this is an rPython bug. When
the package is loaded by library('rPython'), R is obviously
initialized. You don't need to query it to ask that.
The standard R front-ends don't need a flag to know if it is
initialized. They initialize, then go into the read-eval-print loop.
If they are in that loop, R is initialized. If it failed to initialize,
they would never get to that loop.
Other front-ends may do other things besides run R, so they do need to
know if it is initialized, but surely they can keep a flag telling them
whether they've succeeded in initializing it.
Duncan Murdoch
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Bioc-devel] PPA with built bioconductor packages (for continuous integration)
On Nov 9, 2014 8:06 PM, Dan Tenenbaum dtene...@fredhutch.org wrote: - Original Message - From: Martin Morgan mtmor...@fredhutch.org To: Laurent Gautier lgaut...@gmail.com, bioc-devel@r-project.org Sent: Sunday, November 9, 2014 8:26:48 AM Subject: Re: [Bioc-devel] PPA with built bioconductor packages (for continuous integration) On 11/09/2014 07:23 AM, Laurent Gautier wrote: Hi, Continuous integration is a convenient way to automate some of the steps necessary to ensure quality software. Popular ways to do it create a vanilla virtual machine 9VM) with a Linux distribution, and scripts prepares the VM with 3rd-party dependencies required by the software. For example, the popular CI system Travis for github creates by default a VM running ubuntu, and dependencies can be installed with `apt-get install`. When developing software that requires CRAN/bioconductor, the latest R is available precompiled but the R packages must be downloaded installed from source. This can take a relatively long time. On a recent project over 80% of the time is spent downloading/installing the R/BioC packages. The remaining is building the code and running the unit tests. Having a Personal Package Archive (PPA) with bioconductor packages already compiled would both speed up the process and make the use of continuous integration by projects relying on bioconductor packages easier. Is this something others would like to have, and is this something that bioconductor would see to its mission to provide / help provide quality software and be able to host ? It would be interesting to catalogue objectives (e.g., development vs. reproducibility) and available alternatives (e.g., PPA, docker / Rocker, AMI, existing or possible cloud services [such as the Bioc 'single package builder' used to build and check new package submissions, or travis itself], the Becker repository management scheme Michael and Gabe mention, ...); Just to add to the mix of options, it's possible to run R CMD INSTALL --build on a source tarball on Linux and it will create a 'binary' version that is already compiled. The problem with this is (AFAIK) there is no corresponding package type that can be used with install.packages(); otherwise the simplest solution would be to add a CRAN-style repos containing these binaries. Maybe R could be patched to allow this? This would be a solution to the problem, and more general one ( a PPA would be possibly restricted to Ubuntu or Debian. For some similar situations with python packages I am using Python wheels, which are the same as the proposed binary R packages. Laurent But it's possible that the requirements for Linux binaries could vary depending on many things: cpu type (intel or solaris, or...), architecture (i386, x64), presence/absence of BLAS/LAPACK, etc etc etc. This suggests that a vm or container-based approach might be better. Dan if there is a clear path forward satisfying some plurality of users without too many technical obstacles then it might fall within the Bioc purview; my initial sense is that there is not a consensus on use cases or viable implementations, but I can be convinced otherwise... In terms of Tim's post, getting your colleague to use a PPA / existing alternative (e.g., the Bioc AMI, http://bioconductor.org/help/bioconductor-cloud-ami/ which comes with Rstudio server installed...) is not likely to be easier / faster than getting them to download / install relevant R / Bioc packages. One interesting possibility is a 'hosted' bioconductor with sufficient computational resources on the back-end and Rstudio server on the front end; this is not impossible to imaging seeking funding for. Martin Best, Laurent [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel -- Computational Biology / Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N. PO Box 19024 Seattle, WA 98109 Location: Arnold Building M1 B861 Phone: (206) 667-2793 ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] PPA with built bioconductor packages (for continuous integration)
They would work in the context of well defined system such as the VM used by popular continuous integration providers (Travis or Drone for example). Then it would be easy as having the binaries built as artifacts by continuous integration and made available to other continuous integration processes. On Nov 10, 2014 6:19 PM, Martin Morgan mtmor...@fredhutch.org wrote: On 11/09/2014 11:06 AM, Dan Tenenbaum wrote: - Original Message - From: Martin Morgan mtmor...@fredhutch.org To: Laurent Gautier lgaut...@gmail.com, bioc-devel@r-project.org Sent: Sunday, November 9, 2014 8:26:48 AM Subject: Re: [Bioc-devel] PPA with built bioconductor packages (for continuous integration) On 11/09/2014 07:23 AM, Laurent Gautier wrote: Hi, Continuous integration is a convenient way to automate some of the steps necessary to ensure quality software. Popular ways to do it create a vanilla virtual machine 9VM) with a Linux distribution, and scripts prepares the VM with 3rd-party dependencies required by the software. For example, the popular CI system Travis for github creates by default a VM running ubuntu, and dependencies can be installed with `apt-get install`. When developing software that requires CRAN/bioconductor, the latest R is available precompiled but the R packages must be downloaded installed from source. This can take a relatively long time. On a recent project over 80% of the time is spent downloading/installing the R/BioC packages. The remaining is building the code and running the unit tests. Having a Personal Package Archive (PPA) with bioconductor packages already compiled would both speed up the process and make the use of continuous integration by projects relying on bioconductor packages easier. Is this something others would like to have, and is this something that bioconductor would see to its mission to provide / help provide quality software and be able to host ? It would be interesting to catalogue objectives (e.g., development vs. reproducibility) and available alternatives (e.g., PPA, docker / Rocker, AMI, existing or possible cloud services [such as the Bioc 'single package builder' used to build and check new package submissions, or travis itself], the Becker repository management scheme Michael and Gabe mention, ...); Just to add to the mix of options, it's possible to run R CMD INSTALL --build on a source tarball on Linux and it will create a 'binary' version that is already compiled. These binaries are in general not portable, either within or between distributions, e.g., because the user has a different version of a system dependency than the one the binary was built against. Martin The problem with this is (AFAIK) there is no corresponding package type that can be used with install.packages(); otherwise the simplest solution would be to add a CRAN-style repos containing these binaries. Maybe R could be patched to allow this? But it's possible that the requirements for Linux binaries could vary depending on many things: cpu type (intel or solaris, or...), architecture (i386, x64), presence/absence of BLAS/LAPACK, etc etc etc. This suggests that a vm or container-based approach might be better. Dan if there is a clear path forward satisfying some plurality of users without too many technical obstacles then it might fall within the Bioc purview; my initial sense is that there is not a consensus on use cases or viable implementations, but I can be convinced otherwise... In terms of Tim's post, getting your colleague to use a PPA / existing alternative (e.g., the Bioc AMI, http://bioconductor.org/help/bioconductor-cloud-ami/ which comes with Rstudio server installed...) is not likely to be easier / faster than getting them to download / install relevant R / Bioc packages. One interesting possibility is a 'hosted' bioconductor with sufficient computational resources on the back-end and Rstudio server on the front end; this is not impossible to imaging seeking funding for. Martin Best, Laurent [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel -- Computational Biology / Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N. PO Box 19024 Seattle, WA 98109 Location: Arnold Building M1 B861 Phone: (206) 667-2793 ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel -- Computational Biology / Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N. PO Box 19024 Seattle, WA 98109 Location: Arnold Building M1 B861 Phone: (206) 667-2793 [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
[Bioc-devel] PPA with built bioconductor packages (for continuous integration)
Hi, Continuous integration is a convenient way to automate some of the steps necessary to ensure quality software. Popular ways to do it create a vanilla virtual machine 9VM) with a Linux distribution, and scripts prepares the VM with 3rd-party dependencies required by the software. For example, the popular CI system Travis for github creates by default a VM running ubuntu, and dependencies can be installed with `apt-get install`. When developing software that requires CRAN/bioconductor, the latest R is available precompiled but the R packages must be downloaded installed from source. This can take a relatively long time. On a recent project over 80% of the time is spent downloading/installing the R/BioC packages. The remaining is building the code and running the unit tests. Having a Personal Package Archive (PPA) with bioconductor packages already compiled would both speed up the process and make the use of continuous integration by projects relying on bioconductor packages easier. Is this something others would like to have, and is this something that bioconductor would see to its mission to provide / help provide quality software and be able to host ? Best, Laurent [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
[Rd] C-API: removing key-value pairs in an environment
Hi, I am trying to remove key-value pairs from an environments (using C). While adding seems straightforward with `Rf_defineVar()`, I cannot find a function to remove objects from a given environment. Would anyone know if there is such a function ? Best, Laurent __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] C-API: removing key-value pairs in an environment
Thanks. I was hoping that there was an alternative since last time I looked (I was calling R's rm() - I am seeing with the example that I can narrow it down to the .Internal remove). L. On 07/15/2014 10:43 PM, Gábor Csárdi wrote: It seems that this is not part of the C API, and you need to call back to R. Here is how Rcpp does it: https://github.com/RcppCore/Rcpp/blob/e2fcecad4533301d12e1ba19e94ab9f0fa3eb423/inst/include/Rcpp/Environment.h#L194 Best, Gabor On Tue, Jul 15, 2014 at 10:24 PM, Laurent Gautier lgaut...@gmail.com wrote: Hi, I am trying to remove key-value pairs from an environments (using C). While adding seems straightforward with `Rf_defineVar()`, I cannot find a function to remove objects from a given environment. Would anyone know if there is such a function ? Best, Laurent __ 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] RFC: R_data_class as part of the C-API
Hi, In src/attrib.c, the comment for the function R_data_class is: ``` /* the S4-style class: for dispatch required to be a single string; for the new class() function; if(!singleString) , keeps S3-style multiple classes. Called from the methods package, so exposed. */ SEXP R_data_class(SEXP obj, Rboolean singleString) ``` I am obviously writing this because I'd wish to see it in the API, and I think that the above (a package shipped with R does need this as part of the API) is a pretty good case for having it. Best, Laurent PS: I have found a similar request made some time in the past (one of the points in https://stat.ethz.ch/pipermail/r-devel/2007-October/047070.html ). __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Mirroring R on a DVCS
Hi again, The branch R-3-0-branch appears to be missing from the mirror. Best, Laurent On 2013-03-16 21:38, Winston Chang wrote: The Github mirror isn't affiliated with R-core developers -- it just fetches the changes from the R SVN repository periodically. Changes won't go upstream to the main SVN repository, and that's probably why there aren't very many forks of the Github repo. -Winston On Sat, Mar 16, 2013 at 1:44 PM, Laurent Gautier lgaut...@gmail.com mailto:lgaut...@gmail.com wrote: Thanks. I missed it, I guess. I am surprised by the relatively low number of forks... L. On 2013-03-16 11:28, Peter Meilstrup wrote: There is already a mirror on GitHub at https://github.com/wch/r-source . Peter On Mar 16, 2013, at 11:17, Laurent Gautier lgaut...@gmail.com mailto:lgaut...@gmail.com mailto:lgaut...@gmail.com mailto:lgaut...@gmail.com wrote: Hi, I have been looking at mirroring the SVN R repository into a DVCS (Mercurial, Git, bzr, etc...). The idea would be to have that as an always up-to-date untouched master (a mirror) but having it in a DVCS would make forks easier to make and maintain, and possibly ease up the process of having patches included upstream. Would anyone else be interested ? Laurent __ R-devel@r-project.org mailto:R-devel@r-project.org mailto:R-devel@r-project.org mailto:R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel [[alternative HTML version deleted]] __ R-devel@r-project.org mailto: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] Mirroring R on a DVCS
Hi, I have been looking at mirroring the SVN R repository into a DVCS (Mercurial, Git, bzr, etc...). The idea would be to have that as an always up-to-date untouched master (a mirror) but having it in a DVCS would make forks easier to make and maintain, and possibly ease up the process of having patches included upstream. Would anyone else be interested ? Laurent __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Printing warning messages around R_tryEval
We are having a similar issue with rpy2 and R-devel. I would also vote for having back a C-level solution to the problem. I cannot find an explicit explanation for the change in the SVN logs, and traced the change to rev 61771: r61771 | ripley | 2013-01-29 12:09:45 +0100 (Tue, 29 Jan 2013) | 1 line more hiding Could this mean that the change could reverted and Rf_PrintWarnings just be added to the C API ? Laurent On 2013-03-07 12:00, r-devel-requ...@r-project.org wrote: Hi! In RKWard we use R_tryEval() at a number places to run R commands. In order to make sure that any generated warnings become visible close to the problem, we were following up (most of) these calls with Rf_PrintWarnings(). Rf_PrintWarnings() was never available in the headers (as far as I know), and in r61771 the symbol has been hidden from libR.so. So this solution is no longer available. Could you give advice on the best way to print warnings before returning to the top level? Some available options, I am aware of: 1. Call R function warnings(). However, this will always print the latest warning, even if it was generate by some earlier command. I would need a way to print new warnings, only. 2. Use options(warn=1) where applicable. However, in some cases, collecting warnings until some procedure is complete, and printing them then, would be preferrable. 3. I see there is an internal call printDeferredWarnings(), which seems to be almost exactly what I want. However, using an .Internal() does not look like a terribly stable solution, either. Also, having direct access to a similar function from the C-API would be very comfortable. Thanks! Thomas __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Bioc-devel] Request to add 'normalize' to BiocGenerics
() poney or not. Maybe some of them won't and they'll pick up another name. Not something we can really decide for them... H. On 02/20/2013 09:47 AM, Laurent Gautier wrote: On 2013-02-20 17:32, Schalkwyk, Leonard wrote: Is this not just an indication that normalize is now a poor choice of a function name? If the package authors called the functions normalize, this means either: 1- at least some of the package authors have named a function performing an action that is inappropriately described as normalize 2- all functions normalize do perform an action that can be described with that verb Without more details, I'd vote for 2. (more below) LEo On 20 Feb 2013, at 16:14, Wolfgang Huber wrote: Hi is it clear that all these different functions (methods) share similar semantics and enough (conceptually) of their interface? Playing the semantic and concept police would come after defining things like ontologies of data processing; I am not sure this should be a priority. I'd see working out a minimal common signature that keeps everyone going with a minimal fuss come first. Wouldn't the implication be that preemptively every possible string of characters should already be defined as a generic function in BiocGenerics? No. Otherwise this would probably also mean that R's S4 system should in fact define all possible strings as generics, which by extension would also mean that generic functions do not need to be explicitly declared: since all possible generics would be declared, it is more practical to implicitly assume any given function has already generic declared. S4 has notions about implicit generic functions; a starting point is the man page for setGeneric(). Best wishes Wolfgang Il giorno Feb 20, 2013, alle ore 11:04 AM, Laurent Gatto lg...@cam.ac.uk ha scritto: On 19 February 2013 22:44, Hervé Pagès hpa...@fhcrc.org wrote: Hi Laurent, and maintainers of packages with a normalize() function, On 02/15/2013 04:28 AM, Laurent Gatto wrote: A quick (and incomplete) manual search using http://search.bioconductor.jp/ suggest the following usage of normalize: As a function: xps::normalize codelink::normalize EBImage::normalize diffGeneAnalysis::normalize Defining a generic and methods: oligo::normalize flowCore::normalize MSnbase::normalize isobar::normalize and several normalize\.[*+] functions Would it be reasonable to add a normalize generic definition to BiocGenerics? The generic definitions in the above packages differ, however. Sounds good to me. However, since the various normalize() functions have different signatures, we need to agree on what the signature of the generic in BiocGenerics should be. Here is a summary of the situation: ** xps package: normalize() is an ordinary function with the following arg list: normalize(xps.data, filename=character(0), filedir=getwd(), tmpdir=, update=FALSE, select=all, method=mean, option=transcript:all, logbase=0, exonlevel=, refindex=0, refmethod=mean, params=list(0.02, 0), add.data=TRUE, verbose=TRUE) The package also defines normalize.constant(), normalize.lowess(), normalize.quantiles(), normalize.supsmu(), which are also ordinary functions (not S3 methods), and have similar but slightly different arg lists. ** codelink package: Ordinary function with the following args: normalize(object, method=quantiles, log.it=TRUE, preserve=FALSE, weights=NULL, verbose=FALSE) ** EBImage package: Ordinary function with the following args: normalize(x, separate=TRUE, ft=c(0, 1)) ** diffGeneAnalysis package: Ordinary function with the following args: normalize(rawdata, numSlides, ctrl, expm, ctrlbg=0.30, expmbg=0.30) ** deepSNV package: S4 generic with the following args: normalize(test, control, ...) ** isobar package: S4 generic with the following args: normalize(x, f=median, target=intensity, exclude.protein=NULL, use.protein=NULL, f.doapply=TRUE, log=TRUE, channels=NULL, na.rm=FALSE, per.file=TRUE, ...) ** affy package: S4 generic with the following args: normalize(object, ...) ** flowCore package: S4 generic with the following args: normalize(data, x, ...) ** MSnbase package: S4 generic with the following args: normalize(object, method, ...) ** oligo package: S4 generic with the following args: normalize(object, method=normalizationMethods(), copy=TRUE, subset=NULL, target='core', verbose=TRUE, ...) So it looks like the greatest common factor is normalize(x, ...). Not too surprising for a generic that covers such a wide range of related but slightly different concepts / algorithms. One technical difficulty though is that, even though almost all these functions seem to take an S4 object
Re: [Rd] Bug: C-level and _set_rl_word_breaks
On 2013-01-31 21:52, Laurent Gautier wrote: On 2013-01-31 21:09, Duncan Murdoch wrote: On 13-01-30 9:48 PM, Laurent Gautier wrote: Hi, I filed a bug report in the tracker (id #15169) a short while ago, along with a patch, but I came back to it to see that there is relatively little movement or participation on the tracker so I thought I'd pitch it here (patch attached). The function `set_rl_word_breaks` in src/unix/sys-std.c relies on statically-allocated strings local to the function, making other C code using the readline library, such as a program embedding R and using readline as well, at risk of creating a segfault when trying to free `rl_basic_word_break_characters` or `rl_completer_word_break_characters` when changing them. The issue was noticed when embedding R in Python (rpy2); I had an ugly hack for a long time (less work than champion the inclusion of a patch in R) but the iPython developers pushed what could be demanded from the rpy2 with their R magic extension and so I wrote a patch (and they have made a brittle workaround in the meantime). The fix would be of interest to anyone embedding R in C and using readline (e.g., language interface developers if the language either has a console using readline - and chances are that it does - or an interface to readline). The patch attached is against today's R-dev and will likely apply to current R-2.15 branch. With the patch applied, R is building and is passing `make check`. It could be slightly expanded by handling cases where the calloc() or realloc() faills, although not an absolute priority (if allocating 200 bytes fails, the system might have bigger worries than keeping R from crashing). I suspect the reason your bug hasn't been dealt with in the 2 weeks since you posted it is that you don't show any code that illustrates the problem it causes. It is much easier to run some code and see that code that should be valid is causing a crash, than it is to develop code to illustrate it. Fair enough. Now I realize that this might be a part of R codebase that is hardly touched; while the problem makes sense to me after spending time on it, a demonstrating what it causes in a minimal example might be best). Easily illustrated bugs get solved before hard ones. I guess I had a free pass since I provide a solution to the bug. Your post here gives a lot more detail, but still no code. This isn't an area I'd work on (it seems to be a Unix-only bug), but you might attract someone else to look at it if you include a minimal self-contained trigger for it. I'll work on that. A minimal example to demonstrate the problem is now in the bug tracker. It shows that either a C-extension or a part of a application in which R is embedded crash R (segfault) by trying to change break delimiters. Best, Laurent Thanks, L. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug: C-level and _set_rl_word_breaks
On 2013-01-31 21:09, Duncan Murdoch wrote: On 13-01-30 9:48 PM, Laurent Gautier wrote: Hi, I filed a bug report in the tracker (id #15169) a short while ago, along with a patch, but I came back to it to see that there is relatively little movement or participation on the tracker so I thought I'd pitch it here (patch attached). The function `set_rl_word_breaks` in src/unix/sys-std.c relies on statically-allocated strings local to the function, making other C code using the readline library, such as a program embedding R and using readline as well, at risk of creating a segfault when trying to free `rl_basic_word_break_characters` or `rl_completer_word_break_characters` when changing them. The issue was noticed when embedding R in Python (rpy2); I had an ugly hack for a long time (less work than champion the inclusion of a patch in R) but the iPython developers pushed what could be demanded from the rpy2 with their R magic extension and so I wrote a patch (and they have made a brittle workaround in the meantime). The fix would be of interest to anyone embedding R in C and using readline (e.g., language interface developers if the language either has a console using readline - and chances are that it does - or an interface to readline). The patch attached is against today's R-dev and will likely apply to current R-2.15 branch. With the patch applied, R is building and is passing `make check`. It could be slightly expanded by handling cases where the calloc() or realloc() faills, although not an absolute priority (if allocating 200 bytes fails, the system might have bigger worries than keeping R from crashing). I suspect the reason your bug hasn't been dealt with in the 2 weeks since you posted it is that you don't show any code that illustrates the problem it causes. It is much easier to run some code and see that code that should be valid is causing a crash, than it is to develop code to illustrate it. Fair enough. Now I realize that this might be a part of R codebase that is hardly touched; while the problem makes sense to me after spending time on it, a demonstrating what it causes in a minimal example might be best). Easily illustrated bugs get solved before hard ones. I guess I had a free pass since I provide a solution to the bug. Your post here gives a lot more detail, but still no code. This isn't an area I'd work on (it seems to be a Unix-only bug), but you might attract someone else to look at it if you include a minimal self-contained trigger for it. I'll work on that. Thanks, L. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Bug: C-level and _set_rl_word_breaks
Hi,
I filed a bug report in the tracker (id #15169) a short while ago,
along with a patch, but I came back to it to see that there is
relatively little movement or participation on the tracker so I
thought I'd pitch it here (patch attached).
The function `set_rl_word_breaks` in src/unix/sys-std.c relies on
statically-allocated strings local to the function, making other C
code using the readline library, such as a program embedding
R and using readline as well, at risk of creating a segfault when
trying to free `rl_basic_word_break_characters` or
`rl_completer_word_break_characters` when changing them.
The issue was noticed when embedding R in Python (rpy2); I had an
ugly hack for a long time (less work than champion the inclusion
of a patch in R) but the iPython developers pushed what could be
demanded from the rpy2 with their R magic extension and
so I wrote a patch (and they have made a brittle workaround in
the meantime).
The fix would be of interest to anyone embedding R in C and using
readline (e.g., language interface developers if the language either
has a console using readline - and chances are that it does - or
an interface to readline).
The patch attached is against today's R-dev and will likely apply to
current R-2.15 branch. With the patch applied, R is building and is
passing `make check`. It could be slightly expanded by handling
cases where the calloc() or realloc() faills, although not an absolute
priority (if allocating 200 bytes fails, the system might have
bigger worries than keeping R from crashing).
Laurent
Index: src/unix/sys-std.c
===
--- src/unix/sys-std.c (revision 61791)
+++ src/unix/sys-std.c (working copy)
@@ -619,12 +619,31 @@
attribute_hidden
void set_rl_word_breaks(const char *str)
{
-static char p1[201], p2[203];
-strncpy(p1, str, 200); p1[200]= '\0';
-strncpy(p2, p1, 200); p2[200] = '\0';
-strcat(p2, []);
-rl_basic_word_break_characters = p2;
-rl_completer_word_break_characters = p1;
+ static char *completer_word_break_characters = NULL;
+ static char *basic_word_break_characters = NULL;
+
+ if (completer_word_break_characters == NULL) {
+completer_word_break_characters = calloc(201, sizeof(char));
+ } else {
+completer_word_break_characters = realloc(completer_word_break_characters,
+ 201 * sizeof(char));
+ }
+ strncpy(completer_word_break_characters, str, 200);
+ completer_word_break_characters[200]= '\0';
+
+ if (basic_word_break_characters == NULL) {
+basic_word_break_characters = calloc(203, sizeof(char));
+ } else {
+basic_word_break_characters = realloc(basic_word_break_characters,
+ 203 * sizeof(char));
+ }
+ strncpy(basic_word_break_characters,
+ completer_word_break_characters, 200);
+ basic_word_break_characters[200] = '\0';
+ strcat(basic_word_break_characters, []);
+
+ rl_completer_word_break_characters = completer_word_break_characters;
+ rl_basic_word_break_characters = basic_word_break_characters;
}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bounty on Error Checking
On 2013-01-04 12:00, r-devel-requ...@r-project.org wrote: Message: 16 Date: Thu, 3 Jan 2013 22:52:44 + From: Ben Bolker bbol...@gmail.com To: r-de...@stat.math.ethz.ch Subject: Re: [Rd] Bounty on Error Checking Message-ID: loom.20130103t234406-...@post.gmane.org Content-Type: text/plain; charset=us-ascii ivo welch ivo.welch at anderson.ucla.edu writes: Dear R developers---I just spent half a day debugging an R program, which had two bugs---I selected the wrongly named variable, which turns out to have been a scalar, which then happily multiplied as if it was a matrix; and another wrongly named variable from a data frame, that triggered no error when used as a[[name]] or a$name . there should be an option to turn on that throws an error inside R when one does this. I cannot imagine that there is much code that wants to reference non-existing columns in data frames. I know you guys are saints for developing without financial support. but maybe we non-insider end-users can help by putting up a bounty list on R-project for us end-users to contribute to? I would pledge $500 to a $10,000 fund that funds a project to comprehensively enhance the programming and debugging aspects of R. it would only take 20 of us to make this possible. personally, I think basic nudgeware is the way to go. when a user starts R in interactive mode, there should be a note that says, please donate $20 to the R foundation to support the development. press enter to continue or enter your contribution number to avoid this message in the future . you can even accept the same string if need be. it's a nudge only, not a requirement. I did bring this idea up briefly 5 years ago (for whatever that's worth)Lhttp://tolstoy.newcastle.edu.au/R/e2/devel/07/05/3202.html. I very much doubt R-core will go for this, but there's nothing stopping some private citizen with time and energy on their hands from setting up their own private bounty system. As I see it the challenges would be: * setting up and administering the web site and the bounty system (i.e. figuring out rules for deciding when a bounty should be paid) * convincing the R community that their money is safe with you; * figuring out an appropriate payment/escrow system (Paypal?) * dealing with any tax and reporting issues relevant to your locality of receiving and disbursing money It's conceivable that some existing R-oriented entity (Mango Solutions, Revolution, RStudio?) would want/be willing to partner. This won't take care of getting stuff into core R, but (1) well-worked out proofs of concept would go a long way to convincing R-core; (2) a lot can be done outside of core R if (for example) you moved over to using data.table everywhere instead of data frames (only translating to data frames where absolutely necessary). (I would love a scalar data type for R, but I don't think that can be done without a near-complete rewrite ...) Ben Bolker The Pypy project is funding the developments of new features this way (http://pypy.org/ - right side of the page, there are proposals, how much they cost to implement, and how much was donated). There must be others, I am just more aware of that one. A potential difficulty is that all of R-core is possibly already funded (tenure positions in the academia, I'd guess) and might be moderately sensitive to the fact that a given feature should be implemented because people are paying to see it appear. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] documentation for legend(): possible missing info for pch.
In the documentation for graphics::legend(), the entry for pch is: pch: the plotting symbols appearing in the legend, either as vector of 1-character strings, or one (multi character) string. _Must_ be specified for symbol drawing. If I did not misread them, examples in the same documentation page suggest that it is also possible to pass integers. Best, Laurent __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Package datasets not exporting anything on a recent R-2.15.1-patched
On 2012-08-27 11:32, Uwe Ligges wrote:
On 26.08.2012 20:01, Laurent Gautier wrote:
On 2012-08-26 19:27, Prof Brian Ripley wrote:
On 26/08/2012 18:20, Laurent Gautier wrote:
On 2012-08-26 19:03, Prof Brian Ripley wrote:
On 26/08/2012 17:25, Laurent Gautier wrote:
Hi,
I just stumbled on the following apparent oddity: the package
datasets
does not appear to export anything out of its namespace:
ns_datasets - getNamespace('datasets')
getNamespaceExports(ns_datasets)
character(0)
Not the case with other packages (example here with utils):
ns_utils - getNamespace('utils')
head(getNamespaceExports(ns_utils))
[1] ?.DollarNames adistalarm apropos
[6] aregexec
Is this a temporary glitch, or is there something new and
specific to
datasets ?
Not new, been so since R 2.14.0.
The package contains no R code: the only reason it has a namespace is
that since 2.14.0 all packages must have one.
There are other data-only packages, but not in base R.
Lazy-loaded data has not been part of the namespace for a long time:
they are directly in the package's environment. The reason is the
namespace scoping rules: if the package's datasets were in its
namespace, they would be found before any other dataset of that name
by the package's R functions.
Thanks for the quick answer and explanations. The last paragraph above
is leaving me with the wish to understand more before I comment on it.
Would you have an example of finding a dataset in a package's
namespace
(before a dataset with the same name in an other package further
down in
the search path) being a problem ?
It does not happen now, but for example MASS contains both datasets
and analysis functions and when the datasets were in the namespace you
got them before other datasets (e.g. modified versions) of the same
name.
I am seeing two ways for datasets to be used:
A- as internal data for necessary to a function in a package (e.g,
conversion tables). Not very frequent, from my limited experience.
B- as example data, used in the documentation. The most frequent usage.
For A/, the user is not expected to modify the data.
In that case, you can provide the data as an object defined within the
/R directory, for example.
Exactly. This is making us agree that datasets are indeed just objects
in a package.
For B/, the data are typically passed to functions (to use an example
from MASS, huber(chem)).
In that case, you do not want to have it in your NAMESPACE, since you
just pass those data in a function call.
Yet having it in a namespace would not cause any harm, wouldn't it ?
Having it in a namespace would also have the added benefits:
- loading up a dataset will not overwrite silently any existing dataset
currently in .GlobalEnv
- should an identical name for a dataset be found in several packages,
one could refer to it with the :: operator. I am aware of the argument
package to the function data(), but regret the apparent lack of
general rule.
- should one wish to list the objects defined (and eventually exported)
by a package the use of one function would be sufficient.
May be I am missing a fundamental point, but if my memory is correct the
package datasets used to list its data objects when
getNamespaceExports() was called.
Uwe Ligges
I thought a bit about it, but still do no see where exactly this would
be a problem.
An other example available in R is the vector letters (in base). It
can be thought of as a dataset, yet it is
- in a namespace
letters %in% getNamespaceExports(getNamespace(base))
[1] TRUE
- probably used in the two situations A/ and B/ above.
Best,
Laurent
__
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] Package datasets not exporting anything on a recent R-2.15.1-patched
Hi,
I just stumbled on the following apparent oddity: the package datasets
does not appear to export anything out of its namespace:
ns_datasets - getNamespace('datasets')
getNamespaceExports(ns_datasets)
character(0)
Not the case with other packages (example here with utils):
ns_utils - getNamespace('utils')
head(getNamespaceExports(ns_utils))
[1] ?.DollarNames adistalarm apropos
[6] aregexec
Is this a temporary glitch, or is there something new and specific to
datasets ?
Best,
Laurent
PS: Obligatory sessionInfo:
sessionInfo()
R version 2.15.1 Patched (2012-08-24 r60412)
Platform: x86_64-unknown-linux-gnu (64-bit)
locale:
[1] LC_CTYPE=en_DK.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_DK.UTF-8LC_COLLATE=en_DK.UTF-8
[5] LC_MONETARY=en_DK.UTF-8LC_MESSAGES=en_DK.UTF-8
[7] LC_PAPER=C LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_DK.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] tcltk_2.15.1 tools_2.15.1
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Package datasets not exporting anything on a recent R-2.15.1-patched
On 2012-08-26 18:32, Dirk Eddelbuettel wrote:
On 26 August 2012 at 18:25, Laurent Gautier wrote:
| Hi,
|
| I just stumbled on the following apparent oddity: the package datasets
| does not appear to export anything out of its namespace:
|
| ns_datasets - getNamespace('datasets')
| getNamespaceExports(ns_datasets)
| character(0)
|
| Not the case with other packages (example here with utils):
| ns_utils - getNamespace('utils')
| head(getNamespaceExports(ns_utils))
| [1] ?.DollarNames adistalarm apropos
| [6] aregexec
|
| Is this a temporary glitch, or is there something new and specific to
| datasets ?
Seems to be on purpose -- here is its NAMESPACE file
# This package exports nothing (it uses lazydata)
# exportPattern(.)
ie nuttin' gets exported. It also has no R/ directory.
It is a pity that things are not a little more unified and objects in
packages can be either in R/ (be in a namespace, exported or not, always
loaded) or in data/ (always exported, optional lazy loading).
Dirk
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Package datasets not exporting anything on a recent R-2.15.1-patched
On 2012-08-26 19:03, Prof Brian Ripley wrote:
On 26/08/2012 17:25, Laurent Gautier wrote:
Hi,
I just stumbled on the following apparent oddity: the package datasets
does not appear to export anything out of its namespace:
ns_datasets - getNamespace('datasets')
getNamespaceExports(ns_datasets)
character(0)
Not the case with other packages (example here with utils):
ns_utils - getNamespace('utils')
head(getNamespaceExports(ns_utils))
[1] ?.DollarNames adistalarm apropos
[6] aregexec
Is this a temporary glitch, or is there something new and specific to
datasets ?
Not new, been so since R 2.14.0.
The package contains no R code: the only reason it has a namespace is
that since 2.14.0 all packages must have one.
There are other data-only packages, but not in base R.
Lazy-loaded data has not been part of the namespace for a long time:
they are directly in the package's environment. The reason is the
namespace scoping rules: if the package's datasets were in its
namespace, they would be found before any other dataset of that name
by the package's R functions.
Thanks for the quick answer and explanations. The last paragraph above
is leaving me with the wish to understand more before I comment on it.
Would you have an example of finding a dataset in a package's namespace
(before a dataset with the same name in an other package further down in
the search path) being a problem ?
Best,
Laurent
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Package datasets not exporting anything on a recent R-2.15.1-patched
On 2012-08-26 19:27, Prof Brian Ripley wrote:
On 26/08/2012 18:20, Laurent Gautier wrote:
On 2012-08-26 19:03, Prof Brian Ripley wrote:
On 26/08/2012 17:25, Laurent Gautier wrote:
Hi,
I just stumbled on the following apparent oddity: the package
datasets
does not appear to export anything out of its namespace:
ns_datasets - getNamespace('datasets')
getNamespaceExports(ns_datasets)
character(0)
Not the case with other packages (example here with utils):
ns_utils - getNamespace('utils')
head(getNamespaceExports(ns_utils))
[1] ?.DollarNames adistalarm apropos
[6] aregexec
Is this a temporary glitch, or is there something new and specific to
datasets ?
Not new, been so since R 2.14.0.
The package contains no R code: the only reason it has a namespace is
that since 2.14.0 all packages must have one.
There are other data-only packages, but not in base R.
Lazy-loaded data has not been part of the namespace for a long time:
they are directly in the package's environment. The reason is the
namespace scoping rules: if the package's datasets were in its
namespace, they would be found before any other dataset of that name
by the package's R functions.
Thanks for the quick answer and explanations. The last paragraph above
is leaving me with the wish to understand more before I comment on it.
Would you have an example of finding a dataset in a package's namespace
(before a dataset with the same name in an other package further down in
the search path) being a problem ?
It does not happen now, but for example MASS contains both datasets
and analysis functions and when the datasets were in the namespace you
got them before other datasets (e.g. modified versions) of the same name.
I am seeing two ways for datasets to be used:
A- as internal data for necessary to a function in a package (e.g,
conversion tables). Not very frequent, from my limited experience.
B- as example data, used in the documentation. The most frequent usage.
For A/, the user is not expected to modify the data.
For B/, the data are typically passed to functions (to use an example
from MASS, huber(chem)).
I thought a bit about it, but still do no see where exactly this would
be a problem.
An other example available in R is the vector letters (in base). It
can be thought of as a dataset, yet it is
- in a namespace
letters %in% getNamespaceExports(getNamespace(base))
[1] TRUE
- probably used in the two situations A/ and B/ above.
Best,
Laurent
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Rserve graphics output [Was: R-devel Digest, Vol 90, Issue 20]
On 22/08/10 17:55, Simon Urbanek wrote: On Aug 22, 2010, at 3:32 AM, Laurent wrote: On 21/08/10 23:31, Simon Urbanek wrote: On Aug 21, 2010, at 8:46 AM, Laurent wrote: On 21/08/10 12:00, r-devel-requ...@r-project.org wrote: On Aug 20, 2010, at 1:59 PM, Matt Shotwell wrote: On Fri, 2010-08-20 at 12:58 -0400, Sharpie wrote: Donald Paul Winston wrote: (...) Donald Paul Winston wrote: It appears R insists on directing plot output to a file. Is their a graphics device that keeps the output in memory so it can be returned to my java app as a stream of bytes? If I have to wait for it to write to a unique file and then read it back again then I don't think that's going to work. My web app needs to support hundreds of concurrent clients. As far as I know all R graphics output that does not go to a screen device, such as an X window, must be directed to some sort of file. I am not aware of a graphics device that provides output to something other than a screen or a file, but there very well may be such a device in existence. For experimentation purpose, the rpy2 project is finalizing a system to allow Python-written graphical devices (no C-level R extensions, just Python). Beside other niceties, it will allow working around the lack of connection API in R for graphics. Since Python makes the use of file-like objects straightforward, we plan providing devices that are streams (nice for serving graphics from web applications without having to worry about temp files). Well, that doesn't help with the issue we raised since you still cannot use R connections. I do think it will in the use-case proposed: have R serve graphics without having to worry about writing temp files. Actually I have completely forgotten that I have implemented that in Cairo already -- you can fetch the current image from any image Cairo device (without even closing it) using the .image() function. So for example you could use something like: Cairo(640, 480, /dev/null, png) ## the file is actually not used in this case at all so you can use anything plot(...) ## get the image (as a reference) i=Cairo:::.image(dev.cur()) ## if your code can take direct pointer (RGBA), you're done. If you want to further convert it to RAW and more, then: r=Cairo:::.ptr.to.raw(i$ref,0,i$width*i$height*4) dim(r) = c(4, i$width, i$height) p=writePNG(r, raw()) ## p is now the raw PNG content - ready to be served to the client as image/png -- no files involved That's handy for serving graphics. (But Yuk ! Hack ! about having to open a device in /dev/null). Python is somewhat used in the web applications world, and what is proposed allows serving graphics without a temp file in sight. Somewhat is the key word ;) but nonetheless I'm not sure I understand how you plan to do that because you'd have to embed R for this which will cause you to have to initialize R which is simply too slow for any serious web processing .. If considering R to serve graphics, there are two main strategies: fire up an R process each time, or keep an R process alive to answer request. Both will likely have to be done by something else than R (put your language of choice for web development here), and if R can be embedded in that language this will likely be easier (no need to work out a communication interface) and possibly faster (depends on the language discussed and of the quality of the embedding). If you go the other way round (like starting with Rserve) then you don't have Python as a starting point so you'd have to load Python for that in the first place which seems like an overkill. In that scenario, you do not need RServe at all: Python is handling everything. For example, the combo Django (web framework in Python) + rpy2 has been used to deliver R results (including graphics) through the web. Fancy strategies such as managing a pool of R instances if talking heavy web traffic, persistent sessions, etc... can also be implemented. Best, Laurent Cheers, Simon It's trivial to modify any of the existing devices (e.g. Cairo as I said) to support in-memory storage as they already support that internally - certainly much easier that to mess with Python etc. I have been neck-deep in R C-level code for devices when working on that, and ended up with the exact opposite opinion. Nonetheless, yes, it is another way along the lines of xGD, JavaGD etc. Thanks for the pointer. I did not know about them. JavaGD might well be the most helpful thing then (if Donald had in mind to do the web handling made in Java). Best, Laurent Cheers, Simon This was essentially the conclusion of Donald's earlier thread... The functionality you could describe could be
Re: [Rd] how to call a function from C
Hi,
In Rcpp, we now have a Function class to encapsulate functions
(they cover all three kinds, but this may change).
Just a note on that: there is probably no hurry to do so.
rpy2 is also having CLOSXP, BUILTINSXP, and SPECIALSXP represented as
one function-like class and seems to be behave reasonably while a lot of
other things seem more urgent to sort out.
To call the function, what we do is generate a call with the function
as the first node and then evaluate the call.
SEXP stats = PROTECT( R_FindNamespace( mkString( stats) ) ); SEXP
rnorm = PROTECT( findVarInFrame( stats, install( rnorm) ) ) ; SEXP
call = PROTECT( LCONS( rnorm, CONS( ScalarInteger(10),
CONS(ScalarReal(0), R_NilValue ) ) ) ); SEXP res = PROTECT( eval(
call , R_GlobalEnv ) ); UNPROTECT(4) ; return res ;
It works, but I was wondering if there was another way. I've seen
applyClosure, but I'm not sure I should attempt to use it or if using
a call like above is good enough.
Using R_tryEval() will let you evaluate an expression in a given
environment, as well as capture an eventual error occurring during its
evaluation (and translate it as an exception).
Romain
PS: using Rcpp's C++ classes you would express the code above as :
Environment stats(package:stats) ; Function rnorm = stats.get(
rnorm ) return rnorm( 10, 0.0 ) ;
Feel free to snoop in rpy2's rpy/rinterface/rinterface.c and look for
do_try_eval. The behavior looks very similar, the above snippet in
rpy2 would write like:
from rpy2.robjects.packages import importr
stats = importr('stats')
stats.rnorm(10, 0.0)
-- Romain Francois Professional R Enthusiast +33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr |- http://tr.im/KfKn : Rcpp 0.7.2
|- http://tr.im/JOlc : External pointers with Rcpp `-
http://tr.im/JFqa : R Journal, Volume 1/2, December 2009
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] how to call a function from C
On 1/14/10 1:16 PM, Romain Francois wrote:
On 01/14/2010 12:42 PM, Laurent Gautier wrote:
Hi,
In Rcpp, we now have a Function class to encapsulate functions
(they cover all three kinds, but this may change).
Just a note on that: there is probably no hurry to do so.
rpy2 is also having CLOSXP, BUILTINSXP, and SPECIALSXP represented as
one function-like class and seems to be behave reasonably while a lot of
other things seem more urgent to sort out.
To call the function, what we do is generate a call with the function
as the first node and then evaluate the call.
SEXP stats = PROTECT( R_FindNamespace( mkString( stats) ) ); SEXP
rnorm = PROTECT( findVarInFrame( stats, install( rnorm) ) ) ; SEXP
call = PROTECT( LCONS( rnorm, CONS( ScalarInteger(10),
CONS(ScalarReal(0), R_NilValue ) ) ) ); SEXP res = PROTECT( eval(
call , R_GlobalEnv ) ); UNPROTECT(4) ; return res ;
It works, but I was wondering if there was another way. I've seen
applyClosure, but I'm not sure I should attempt to use it or if using
a call like above is good enough.
Using R_tryEval() will let you evaluate an expression in a given
environment, as well as capture an eventual error occurring during its
evaluation (and translate it as an exception).
Sure. I did not want to over-complicate the question.
I'm currently reviewing tryEval and its underlying R_TopLevelExec which
does not give me enough : when the error occurs, it'd be useful that the
function returns the condition object instead of NULL.
I possibly went the same path, and ended with R_tryEval. When looking at
it, I could not figure out any way to get what I wanted outside using
geterrmessage in base.
The error string is in the variable errbuf (in src/main/error.c), with
no obvious route to access it (and if truly no route, this might be
something missing from the R C-API).
Romain
PS: using Rcpp's C++ classes you would express the code above as :
Environment stats(package:stats) ; Function rnorm = stats.get(
rnorm ) return rnorm( 10, 0.0 ) ;
Feel free to snoop in rpy2's rpy/rinterface/rinterface.c and look for
do_try_eval. The behavior looks very similar, the above snippet in
rpy2 would write like:p/
I meant do_eval_expr.
from rpy2.robjects.packages import importr
stats = importr('stats')
stats.rnorm(10, 0.0)
nice
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-devel Digest, Vol 83, Issue 2
[Disclaimer: what is below reflects my understanding from reading the R
source, others will correct where deemed necessary]
On 1/2/10 12:00 PM, r-devel-requ...@r-project.org wrote:
Hello,
We are currently making lots of changes to Rcpp (see the open Rcpp
mailing list if interested [1] in the details).
We are now using [2] R_PreserveObject and R_ReleaseObject to manage
garbage collection instead of the PROTECT/UNPROTECT dance. This seems to
work well, but I was wondering if there was documentation about it.
The most precise technical documentation is in memory.c
PROTECT is an alias for Rf_protect, itself an alias for
SEXP protect(SEXP s);
and uses a stack (R_PPStack) to store protected objects.
In particular, if we preserve the same SEXP twice (or more), should we
implement some sort of reference counting ?
This depends on the requirements for your system.
For example, in rpy2 I added a reference counting layer(*) because I
wanted to allow several Python objects to share the same underlying R
object, but that's not currently(*) counting how many times an object
should be freed.
(*: imperfect, but currently doing a very decent job - details upon
request).
That kind of feature could be provided by R's C-level API, since this
could be seen of general use as well as give an opportunity to improve
the performances of the R_PreservedObject/R_ReleaseObject duo whenever a
lot of objects are protected and/or external code is
protecting/releasing objects through a FIFO proxy.
Reading the source (below, from memory.c) I think not, but some
confirmation would help.
I understand the code in memory.c like an object preserved twice needs
to be freed twice: R_PreciousList is just a (linked) list, and
R_PreserveObject(object) adds the object to the beginning of the list
while R_ReleaseObject(object) removes the first object found from
the list.
void R_PreserveObject(SEXP object)
{
R_PreciousList = CONS(object, R_PreciousList);
}
static SEXP RecursiveRelease(SEXP object, SEXP list)
{
if (!isNull(list)) {
if (object == CAR(list))
return CDR(list);
else
CDR(list) = RecursiveRelease(object, CDR(list));
}
return list;
}
void R_ReleaseObject(SEXP object)
{
R_PreciousList = RecursiveRelease(object, R_PreciousList);
}
I'd also be interested if there is some ideas on the relative efficiency
of the preserve/release mechanism compared to PROTECT/UNPROTECT.
PROTECT/UNPROTECT is trading granularity for speed. It is a stack with
only tow operations possible:
- push 1 object into the stack
- pull (unprotect) N last objects from the stack
HTH,
L.
Thanks,
Romain
[1]http://lists.r-forge.r-project.org/pipermail/rcpp-devel/
[2]
http://r-forge.r-project.org/plugins/scmsvn/viewcvs.php/pkg/src/RObject.cpp?rev=255root=rcppview=markup
-- Romain Francois Professional R Enthusiast +33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr |- http://tr.im/IW9B : C++ exceptions
at the R level |- http://tr.im/IlMh : CPP package: exposing C++ objects
`- http://tr.im/HlX9 : new package : bibtex
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-devel Digest, Vol 83, Issue 2
On 1/2/10 5:56 PM, Duncan Murdoch wrote: On 02/01/2010 11:36 AM, Laurent Gautier wrote: [Disclaimer: what is below reflects my understanding from reading the R source, others will correct where deemed necessary] On 1/2/10 12:00 PM, r-devel-requ...@r-project.org wrote: (...) I'd also be interested if there is some ideas on the relative efficiency of the preserve/release mechanism compared to PROTECT/UNPROTECT. PROTECT/UNPROTECT is trading granularity for speed. It is a stack with only tow operations possible: - push 1 object into the stack - pull (unprotect) N last objects from the stack UNPROTECT_PTR is also possible, which does a linear search through the stack and unprotects something possibly deep within it. There is also REPROTECT which allows you to replace an entry within the stack. I would guess that UNPROTECT_PTR is more efficient than RecursiveRelease because it doesn't use so much stack space when it needs to go deep into the stack to release, but it is possible the compiler recognizes the tail recursion and RecursiveRelease is implemented efficiently. In that case it could be more efficient than UNPROTECT_PTR, which has to move all the other entries down to fill the newly vacated space. Really the only reliable way to answer efficiency questions like this is to try both ways and see which works better in your application. Thanks. I did not know about UNPROTECT_PTR. I had concerns over the stack usage, but so far it did not prove too much of a problem. Still, why isn't the tail recursion explicitly made an iteration then ? This would take the may be the compiler figures it out, may be not variable out of the equation. Another possibility is to maintain your own list or environment of objects, and just protect/preserve the list as a whole. Interesting idea, this would let one perform his/her own bookkeeping on the list/environment. How is R garbage collection checking contained objects ? (I am thinking performances here, and may be cyclic references). L. Duncan Murdoch HTH, L. Thanks, Romain [1]http://lists.r-forge.r-project.org/pipermail/rcpp-devel/ [2] http://r-forge.r-project.org/plugins/scmsvn/viewcvs.php/pkg/src/RObject.cpp?rev=255root=rcppview=markup -- Romain Francois Professional R Enthusiast +33(0) 6 28 91 30 30 http://romainfrancois.blog.free.fr |- http://tr.im/IW9B : C++ exceptions at the R level |- http://tr.im/IlMh : CPP package: exposing C++ objects `- http://tr.im/HlX9 : new package : bibtex __ 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] R_PreserveObject, R_ReleaseObject : reference counting needed ?
On 1/2/10 5:50 PM, Romain Francois wrote: Thanks. On 01/02/2010 05:36 PM, Laurent Gautier wrote: [Disclaimer: what is below reflects my understanding from reading the R source, others will correct where deemed necessary] On 1/2/10 12:00 PM, r-devel-requ...@r-project.org wrote: (...) In particular, if we preserve the same SEXP twice (or more), should we implement some sort of reference counting ? This depends on the requirements for your system. We wrap up SEXP into a C++ class that in particular manages itself preserving and releasing the object to garbage collection. If you do not allow several C++ instances to share the same SEXP, you should not need reference counting. In the case of rpy2, this was made necessary for allowing inheritance (as nested calls to constructors can cause a transient sharing of the given SEXP across several Python objects). (...) L. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-devel Digest, Vol 83, Issue 2
On 1/2/10 8:53 PM, Duncan Murdoch wrote: Simon Urbanek wrote: On Jan 2, 2010, at 12:17 PM, Laurent Gautier wrote: On 1/2/10 5:56 PM, Duncan Murdoch wrote: On 02/01/2010 11:36 AM, Laurent Gautier wrote: [Disclaimer: what is below reflects my understanding from reading the R source, others will correct where deemed necessary] On 1/2/10 12:00 PM, r-devel-requ...@r-project.org wrote: (...) I'd also be interested if there is some ideas on the relative efficiency of the preserve/release mechanism compared to PROTECT/UNPROTECT. PROTECT/UNPROTECT is trading granularity for speed. It is a stack with only tow operations possible: - push 1 object into the stack - pull (unprotect) N last objects from the stack UNPROTECT_PTR is also possible, which does a linear search through the stack and unprotects something possibly deep within it. There is also REPROTECT which allows you to replace an entry within the stack. I would guess that UNPROTECT_PTR is more efficient than RecursiveRelease because it doesn't use so much stack space when it needs to go deep into the stack to release, but it is possible the compiler recognizes the tail recursion and RecursiveRelease is implemented efficiently. In that case it could be more efficient than UNPROTECT_PTR, which has to move all the other entries down to fill the newly vacated space. Really the only reliable way to answer efficiency questions like this is to try both ways and see which works better in your application. Thanks. I did not know about UNPROTECT_PTR. I had concerns over the stack usage, but so far it did not prove too much of a problem. Still, why isn't the tail recursion explicitly made an iteration then ? This would take the may be the compiler figures it out, may be not variable out of the equation. Careful - the protection stack (bookkeeping by R) has nothing to do with the C function call stack hence it has nothing to do with the compiler. The protection stack is global so usually you don't run out of it unless something goes horribly wrong (=infinite loop). I think Laurent was referring to RecursiveRelease, which could use a lot of C stack if you choose to release something that is deep in the list, since it checks the head, and if that doesn't match, calls itself again on the rest of the list. (I checked, and at least one version of gcc doesn't recognize the tail recursion: it really does generate a recursive call.) Laurent asked why it isn't optimized to avoid the recursion: I think the answer is simply because it is so rarely used that nobody has bothered. Yes, I was referring to RecursiveRelease. Sorry if this was not clear. What are the chances for a patch to be accepted ? At first sight(*), making that tail recursion an iterative function is not a major undertaking, and reviewing the patch be fairly straightforward... but I can always use that time otherwise if the answer to the question is nil. L. Duncan Murdoch Another possibility is to maintain your own list or environment of objects, and just protect/preserve the list as a whole. Interesting idea, this would let one perform his/her own bookkeeping on the list/environment. How is R garbage collection checking contained objects ? (I am thinking performances here, and may be cyclic references). You don't really want to care because the GC is global for all objects (and cycles are supported by the GC in R) - so whether you keep it yourself or Preserve/Release is practically irrelevant (the protection stack is handled separately). As for keeping your own list -- if you really care about performance that much (to be honest in vast majority of cases it doesn't matter) you have to be careful how you implement it. Technically the fastest way is preallocated generic vector but it really depends on how you deal with the access so you can easily perform worse than Preserve/Release if you're not careful. As a side note - the best way (IMHO) to deal with all those issues is to use external pointers because a) you get very efficient C finalizers b) you can directly (and very efficiently) tie lifespan of other objects to the same SEXP and c) as guardians they can nicely track other objects that hold them. Cheers, Simon L. Duncan Murdoch HTH, L. Thanks, Romain [1]http://lists.r-forge.r-project.org/pipermail/rcpp-devel/ [2] http://r-forge.r-project.org/plugins/scmsvn/viewcvs.php/pkg/src/RObject.cpp?rev=255root=rcppview=markup -- Romain Francois Professional R Enthusiast +33(0) 6 28 91 30 30 http://romainfrancois.blog.free.fr |- http://tr.im/IW9B : C++ exceptions at the R level |- http://tr.im/IlMh : CPP package: exposing C++ objects `- http://tr.im/HlX9 : new package : bibtex __ 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] R-devel Digest, Vol 83, Issue 2
On 1/2/10 8:28 PM, Simon Urbanek wrote: On Jan 2, 2010, at 12:17 PM, Laurent Gautier wrote: On 1/2/10 5:56 PM, Duncan Murdoch wrote: On 02/01/2010 11:36 AM, Laurent Gautier wrote: [Disclaimer: what is below reflects my understanding from reading the R source, others will correct where deemed necessary] On 1/2/10 12:00 PM, r-devel-requ...@r-project.org wrote: (...) Another possibility is to maintain your own list or environment of objects, and just protect/preserve the list as a whole. Interesting idea, this would let one perform his/her own bookkeeping on the list/environment. How is R garbage collection checking contained objects ? (I am thinking performances here, and may be cyclic references). You don't really want to care because the GC is global for all objects (and cycles are supported by the GC in R) - so whether you keep it yourself or Preserve/Release is practically irrelevant (the protection stack is handled separately). I guess that I'll have to know in order to understand that I don't really want to care. ;-) The garbage collector must somehow know if an object is available for collection (and will have to check whether an object is PROTECTed or not, or Preserved or not). I suppose that upon being called the garbage collector will first look into the PROTECTed and Preserved objects, mark them as unavailble for collection, then recursively mark objects contained in them. As for keeping your own list -- if you really care about performance that much (to be honest in vast majority of cases it doesn't matter) you have to be careful how you implement it. Technically the fastest way is preallocated generic vector but it really depends on how you deal with the access so you can easily perform worse than Preserve/Release if you're not careful. Releasing being of linear complexity, having few thousands of Preserved objects not being anticipated as an extraordinary situation, and Preserve/Release cycles being quite frequent, I start minding a bit about the performance. Keeping my own list would let me experiment with various strategies (and eventually offer As a side note - the best way (IMHO) to deal with all those issues is to use external pointers because a) you get very efficient C finalizers b) you can directly (and very efficiently) tie lifespan of other objects to the same SEXP and c) as guardians they can nicely track other objects that hold them. Thanks. I am not certain to follow everything. Are you suggesting that rather than Preserve-ing/Release-ing a list/environment that would act as a guardian for several objects, one should use an external pointer (to an arbitrary C pointer) ? In that case, how does one indicate that an external pointer acts as a container ? Or are you suggesting that rather than Preserve-in/Release-ing R objects one should use an external pointer acting as a proxy for a SEXP (argument prot in R_MakeExternalPtr(void *p, SEXP tag, SEXP prot) ) ? (but in that case the external pointer will itself have to go through Preserve/Release cycles...) Cheers, Laurent Cheers, Simon L. Duncan Murdoch HTH, L. Thanks, Romain [1]http://lists.r-forge.r-project.org/pipermail/rcpp-devel/ [2] http://r-forge.r-project.org/plugins/scmsvn/viewcvs.php/pkg/src/RObject.cpp?rev=255root=rcppview=markup -- Romain Francois Professional R Enthusiast +33(0) 6 28 91 30 30 http://romainfrancois.blog.free.fr |- http://tr.im/IW9B : C++ exceptions at the R level |- http://tr.im/IlMh : CPP package: exposing C++ objects `- http://tr.im/HlX9 : new package : bibtex __ 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] R-devel Digest, Vol 83, Issue 2
On 1/2/10 11:41 PM, Romain Francois wrote:
On 01/02/2010 11:12 PM, Duncan Murdoch wrote:
On 02/01/2010 3:16 PM, Laurent Gautier wrote:
On 1/2/10 8:53 PM, Duncan Murdoch wrote:
Simon Urbanek wrote:
On Jan 2, 2010, at 12:17 PM, Laurent Gautier wrote:
On 1/2/10 5:56 PM, Duncan Murdoch wrote:
On 02/01/2010 11:36 AM, Laurent Gautier wrote:
[Disclaimer: what is below reflects my understanding from reading
the
R source, others will correct where deemed necessary]
On 1/2/10 12:00 PM, r-devel-requ...@r-project.org wrote:
(...)
(...)
I don't think I would want to review such a patch (I don't know the
memory manager well, I don't know that there is really a case where it
matters enough to be worth doing), so I'd say if you don't get a message
from a core member volunteering to do so, you should assume it won't be
accepted. But that doesn't mean you shouldn't write the code for your
own internal use and edification, and if you can put together a demo
that shows it really makes a big difference in a realistic situation,
you might get a different response.
Duncan Murdoch
From what I understand, this has little to do with the memory manager,
and resumes to the simple problem how to remove an object from a list.
I would generalize even further, up to: how to make a tail recursion
into an interation (and that often boils down to writing a for loop -
little edification to get from it, I suppose... one probably wants to
write it to see it included).
I see below that you are living up to the enthusiasm claimed, and had a
shot at it (and even did benchmark to demonstrate the expected benefit -
impressive).
Let's see what happens with it...
L.
Something like this, using the amazing inline and inspect packages:
require( inline )
require( inspect )
remover - cfunction(signature( list = language, object =
environment ), '
if( !isNull( list ) ){
SEXP x = list ;
SEXP y ;
while( CAR(x) != object CADR(x) != R_NilValue ){
y = x ;
x = CDR(x) ;
}
if( CAR(x) == object ) SETCDR(y, CDR(x) ) ;
}
return list ;
', Rcpp=FALSE, verbose=FALSE )
e - new.env()
call - call( foo, e, e, 1:10, 3 )
call
# inspect( call )
result - remover( call ,e )
result
# inspect( result )
gives this :
foo(10, environment, 0, environment, 1)
@0x9f4e0d0 06 LANGSXP [NAM(2)]
@0x9f4e204 01 SYMSXP [] foo
@0xa907b78 14 REALSXP [NAM(2)] (len=1, tl=1763713056)
@0x9f4d564 04 ENVSXP [NAM(1)]
FRAME:
@0x9e94a10 00 NILSXP [MARK,NAM(2)]
ENCLOS:
@0x9eb7b4c 04 ENVSXP [MARK,NAM(2),GP(0x8000)]
HASHTAB:
@0x9e94a10 00 NILSXP [MARK,NAM(2)]
@0xa907b58 14 REALSXP [NAM(2)] (len=1, tl=1936941344)
@0x9f4d564 04 ENVSXP [NAM(1)]
FRAME:
@0x9e94a10 00 NILSXP [MARK,NAM(2)]
ENCLOS:
@0x9eb7b4c 04 ENVSXP [MARK,NAM(2),GP(0x8000)]
HASHTAB:
@0x9e94a10 00 NILSXP [MARK,NAM(2)]
@0xa907b38 14 REALSXP [NAM(2)] (len=1, tl=543908709)
NULL
==
foo(10, 0, environment, 1)
@0x9f4e0d0 06 LANGSXP [NAM(2)]
@0x9f4e204 01 SYMSXP [] foo
@0xa907b78 14 REALSXP [NAM(2)] (len=1, tl=1763713056)
@0xa907b58 14 REALSXP [NAM(2)] (len=1, tl=1936941344)
@0x9f4d564 04 ENVSXP [NAM(2)]
FRAME:
@0x9e94a10 00 NILSXP [MARK,NAM(2)]
ENCLOS:
@0x9eb7b4c 04 ENVSXP [MARK,NAM(2),GP(0x8000)]
HASHTAB:
@0x9e94a10 00 NILSXP [MARK,NAM(2)]
@0xa907b38 14 REALSXP [NAM(2)] (len=1, tl=543908709)
NULL
so it boils down to this as a replacement to RecursiveRelease :
/**
* Removes the first instance of object with the list
*/
static SEXP RemoveFromList( SEXP object, SEXP list){
if( !isNull( list ) ){
SEXP x = list ;
SEXP y ;
while( CAR(x) != object CADR(x) != R_NilValue ){
y = x ;
x = CDR(x) ;
}
if( CAR(x) == object ) SETCDR(y, CDR(x) ) ;
}
return list ;
}
Romain
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] raster support in graphics devices
I can confirm. Last time I checked (that is recently), there was no way to do it at the C level (beside possibly extreme hacks trying to work around what R does not want to expose, or go for patched source trees and builds). What is the status of this patch (accepted ? rejected ? else ?) This subject keeps appearing on the list, with the existence of a patch once contributed (3 years ago) acknowledged: http://www.mail-archive.com/r-h...@r-project.org/msg67172.html L. -- On Dec 5, 2009, at 4:11 PM, Romain Francois wrote: I agree too, I was just trying to put on the balance the amount of work that would require graphics supporting connections. Who's willing to do it ? The issue is not the will nor complexity on the GD side, but connections are not exposed outside of R (or at the C level), so there is currently no way to do it (AFAIR). Jeff Horner has proposed a patch long ago and Cairo works with connections if you patch R, but connections are to date still not part of the API. So I suspect the real issue is to create a connection API so packages (and devices) can use it. Cheers, Simon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] :Re: PROTECT and OCaml GC.
On Nov 28, 2009, at 7:50 PM, Guillaume Yziquel wrote: FWIW what I think you should be really looking at is R_PreserveObject/R_ReleaseObject. OK. Thanks. I would suggest looking at the many other R embeddings in other languages that already exist since I don't think you approach is very viable (but I think I expressed that already before). Lisp - the only thing I've seen is a translator: http://dan.corlan.net/R_to_common_lisp_translator/ I haven't found a binding for Haskell. Nor for Scheme. Do you know of any bindings of R to functional languages? It does not have to be a functional language. To see it in use within a some-language-to-R bridge, you can check the source in JRI, rpy2. I can mostly speak for rpy2, and the way it is done there relies on both R and Python's GC. Creating a anonymous R object presented to the Python world is first R_preserved (from garbage collection from R) then using Python's reference counting mechanism, calling an R_Release whenever the Python wrapper is available for garbage collection (in fact there is a twist, but this is roughly the way it is working). In your case, you'll use the OCaml GC system (and R_release the R object when its OCaml representation is going for garbage collection). since I don't think you approach is very viable (but I think I expressed that already before). You expressed the sentiment that it would be a very bad idea to bypass the current API. I would be happy to hear why you would think that a low-level binding is not possible, or not very viable. By low-level, I mean a binding that takes hold of R objects without using symbols all over to reference them. (Using symbols in the formals, the body or the environment of a closure is fine, for instance, but I'd like to execute a closure directly, and eventually be able to construct R closure from OCaml functions). Rpy2 can do a lot of that, and probably so can JRI. Please elaborate on the difficulties you perceive. That would be helpful. Symbols are used in various places in R, checking the outcome of deparse(substitute()) on an anonymous variable of large size could tell you that some things will not work out of the box nicely. HTH, L. Cheers, Simon All the best, Guillaume. -- Guillaume Yziquel http://yziquel.homelinux.org/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] :Re: PROTECT and OCaml GC.
Guillaume Yziquel wrote: Laurent Gautier a écrit : It does not have to be a functional language. To see it in use within a some-language-to-R bridge, you can check the source in JRI, rpy2. I can mostly speak for rpy2, and the way it is done there relies on both R and Python's GC. Creating a anonymous R object presented to the Python world is first R_preserved (from garbage collection from R) then using Python's reference counting mechanism, calling an R_Release whenever the Python wrapper is available for garbage collection (in fact there is a twist, but this is roughly the way it is working). In your case, you'll use the OCaml GC system (and R_release the R object when its OCaml representation is going for garbage collection). For now, garbage collection is a secondary issue. I would have been interested in a binding to a functional language to see exactly where you get a closure to closure mapping. That's why I was asking since that's what I'm foremost interested in. By low-level, I mean a binding that takes hold of R objects without using symbols all over to reference them. (Using symbols in the formals, the body or the environment of a closure is fine, for instance, but I'd like to execute a closure directly, and eventually be able to construct R closure from OCaml functions). Rpy2 can do a lot of that, and probably so can JRI. An anonymous closure to anonymous closure mapping? Could you point out where this is done exactly? Anonymous R objects, that is without an associated symbol in R, can be passed to functions (and in that way makes a binding take hold of R objects without using symbols). For example, building R code made of anonymous objects can be achieved by making a LANGSXP object and tweaking it. Example in R itself: x - call(round, 2.3) eval(x) [1] 2 x[[1]] - function(x) x^2 eval(x) [1] 5.29 Getting more complex constructs may need a little more trickery. ...or do you mean something else ? L. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] :Re: PROTECT and OCaml GC.
Guillaume Yziquel wrote: Laurent Gautier a écrit : Anonymous R objects, that is without an associated symbol in R, can be passed to functions (and in that way makes a binding take hold of R objects without using symbols). For example, building R code made of anonymous objects can be achieved by making a LANGSXP object and tweaking it. Example in R itself: x - call(round, 2.3) eval(x) [1] 2 x[[1]] - function(x) x^2 eval(x) [1] 5.29 Getting more complex constructs may need a little more trickery. ...or do you mean something else ? L. You're saying anonymous R objects can be passed to functions. My question is: can you construct a LANGSXP in C/Python/rpy from R objects and an anonymous R closure, the closure being available from C as a SEXP closure. Can you write a function SEXP my_langsxp (SEXP closure, SEXP arglist); with only the API? If this can be done from R itself, it can be done from the C level. I have not looked into making sure that this can precisely and effortlessly be done with rpy2, as ironing other parts of the bridge caught my attention and seemed more urgently needed, but I remember contemplating the idea of having it working at some point... (I went as far as getting LANGSXP objects exposed as Python list-like objects, I think). __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Issue when calling deparse(substitute(x)) from C with anonymous R vectors ?
Thanks to you and Peter for the quick answer.
I should definitely have tried I R. It just seemed to me so unlikely
that no one ever reported that anonymous vectors would fail with
chisq.test().
Having a label that would be x or y is along the lines of something I
was thinking of, and this not only for chisq.test(). It would be helpful
for functions such as plot() for example.
The idea would be to replace an anonymous object by its variable name,
unless the anonymous variable is coming from a function call.
Example:
foo - function(x) {
xlabel - deparse(substitute(x))
# do things
}
foo(y) # xlabel is 'y'
foo(log(y)) # xlabel is 'log(y)'
foo(c(1,2,3)) # xlabel is 'x'
foo(log(c(1,2,3)) # xlabel is 'x'
This would likely require looking at the parse tree for the argument,
and have a switch such as if any leave is an anonymous object, use the
parameter name.
L.
Prof Brian Ripley wrote:
This is easy to reproduce in R:
chisq.test(c(1000, 1001, 1002, 1003, 1004, 1005, 1006, 1007, 1008, 1009,
1010, 1011),
c(1000, 1001, 1002, 1003, 1004, 1005, 1006, 1007, 1008, 1009, 1010, 1011))
The simple answer is: don't do that.
It is unclear what is a reasonable label to give in such a case: maybe
simply 'x' and 'y'?
On Thu, 19 Nov 2009, Laurent Gautier wrote:
Dear list,
When calling R from C, what appears like a spurious error can be
triggered during the execution of chisq.test(x, y).
This is happening when the following conditions are met:
- x and y are anonymous C-level R vectors (they do not have a symbol),
but they are protected from garbage collection
- x and y are not too small (it was experienced as soon as they are
longer than 17 elements).
The error is
Error in names(dimnames(x)) - DNAME :
'names' attribute [4] must be the same length as the vector [2]
and can be traced to the use of deparse(substitute(x)) and
deparse(substitute(y)) in the R code.
What seems to be happening is that the deparse(substitute(x)) call
gives a character vector of length 1 as soon as x is not so small.
To demonstrate this, I am using rpy2 (as the problem was found when
using it
http://sourceforge.net/mailarchive/forum.php?thread_name=4B043CA1.9050500%40salilab.orgforum_name=rpy-list
), but it will likely be present in other bridges to R as well.
#using R-2.10 and rpy2-2.1.dev
import rpy2.robjects as robjects
f = robjects.r('''function(x) return(deparse(substitute(x)))''')
tuple(f(robjects.FloatVector(range(17
('c(0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16)',)
# length 1
tuple(f(robjects.FloatVector(range(18
('c(0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17', ')')
# length 2 !!
Does it seem to others like an issue present in other bridges as well ?
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] Issue when calling deparse(substitute(x)) from C with anonymous R vectors ?
Dear list,
When calling R from C, what appears like a spurious error can be
triggered during the execution of chisq.test(x, y).
This is happening when the following conditions are met:
- x and y are anonymous C-level R vectors (they do not have a symbol),
but they are protected from garbage collection
- x and y are not too small (it was experienced as soon as they are
longer than 17 elements).
The error is
Error in names(dimnames(x)) - DNAME :
'names' attribute [4] must be the same length as the vector [2]
and can be traced to the use of deparse(substitute(x)) and
deparse(substitute(y)) in the R code.
What seems to be happening is that the deparse(substitute(x)) call
gives a character vector of length 1 as soon as x is not so small.
To demonstrate this, I am using rpy2 (as the problem was found when using it
http://sourceforge.net/mailarchive/forum.php?thread_name=4B043CA1.9050500%40salilab.orgforum_name=rpy-list
), but it will likely be present in other bridges to R as well.
#using R-2.10 and rpy2-2.1.dev
import rpy2.robjects as robjects
f = robjects.r('''function(x) return(deparse(substitute(x)))''')
tuple(f(robjects.FloatVector(range(17
('c(0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16)',)
# length 1
tuple(f(robjects.FloatVector(range(18
('c(0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17', ')')
# length 2 !!
Does it seem to others like an issue present in other bridges as well ?
L.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Suggestion: Dimension-sensitive attributes
) # return the list if i is NULL ). Other standard generics to be affected would be: * rbind cbind for 2-dim arrays/matrices: they should combine the metadata, and for dimension-sensitive metadata can be modelled upon what is done with dimnames: use rowmeta (colmeta) of the first object with them in cbind (rbind), and combine colmeta (rowmeta) of all objects with them, filling with NAs/NULLs/.. for non metadata-sensitive objects being combined. An issue of coercing dimmeta of different classes may arise. May be good to be trigger-happy for a first pass ( stop(mismatching meta data - sorry) )... and mix-and-match use cases might be fewer. * `dim-`, but this may raise the same problem of coercing dimmeta of different classes. Disabling dim- is, I think, choosing sanity for now. ...and I agree with the rest of your comments. Same for me (about your comments). This thread seems to be leading to something great. L. Best, Enrique -Original Message- From: Laurent Gautier [mailto:lgaut...@gmail.com] Sent: jueves, 09 de julio de 2009 14:15 Cc: Heinz Tuechler; Bengoechea Bartolomé Enrique (SIES 73); Tony Plate; Henrik Bengtsson; r-devel@r-project.org Subject: Re: [Rd] Suggestion: Dimension-sensitive attributes Starting by working on an interface for such object(s) is probably the first step toward a unified solution, and this before about if and how R attributes are used. It would also help to ensure a smooth transition from the existing classes implementing a similar solution (first the interface is added to those classes, then after a grace period the classes are eventually refactored). Dimension-level is what seems to the be most needed... but I am not convinced of the practicality of the object-level, and cell-level scheme s proposed: - Object-level, if not linked to any dimension-attribute is such saying that one want to attach anything to any object. That's what attr() is already doing. - Cell-level, is may be out-of-scope for one first trial (but may be I missed the use-cases for it) If starting with behaviour, it seems to boil to having [/[- and dimmeta()/dimmeta-(), : - extract [ / replace [- : * keeps working the way it already does * extracts a subset of the object as well as a subset of the dimension-associated metadata. * departing too much from the way [ is working and add behind-the-curtain name matching will only compromise the chances of adoption. * forget about the bit about which metadata is kept and which one isn't when using [. Make a function unmeta() (similar behavior to unname()) to drop them all, or work it out with something like dimmeta(x, 1) - NULL # drop the metadata associated with dimension 1 - access the dimension-associated metadata: * may be a function called dimmeta() (for consistency with dimnames()) ? The signature could be dimmeta(x, i), with x the object, and i the dimension requested. A replace function dimmeta-(x, i, value) would be provided. In the abstract the names associated with a given dimension is just one of possible metadata, but I'd keep away from meddling with it for a start. It would seem natural that metadata associated with one dimension: would a table-like object (data.frame seems natural in R, and unfortunately there is no data.frame-like structure in R). L. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Suggestion: Dimension-sensitive attributes
Starting by working on an interface for such object(s) is probably the first step toward a unified solution, and this before about if and how R attributes are used. It would also help to ensure a smooth transition from the existing classes implementing a similar solution (first the interface is added to those classes, then after a grace period the classes are eventually refactored). Dimension-level is what seems to the be most needed... but I am not convinced of the practicality of the object-level, and cell-level scheme s proposed: - Object-level, if not linked to any dimension-attribute is such saying that one want to attach anything to any object. That's what attr() is already doing. - Cell-level, is may be out-of-scope for one first trial (but may be I missed the use-cases for it) If starting with behaviour, it seems to boil to having [/[- and dimmeta()/dimmeta-(), : - extract [ / replace [- : * keeps working the way it already does * extracts a subset of the object as well as a subset of the dimension-associated metadata. * departing too much from the way [ is working and add behind-the-curtain name matching will only compromise the chances of adoption. * forget about the bit about which metadata is kept and which one isn't when using [. Make a function unmeta() (similar behavior to unname()) to drop them all, or work it out with something like dimmeta(x, 1) - NULL # drop the metadata associated with dimension 1 - access the dimension-associated metadata: * may be a function called dimmeta() (for consistency with dimnames()) ? The signature could be dimmeta(x, i), with x the object, and i the dimension requested. A replace function dimmeta-(x, i, value) would be provided. In the abstract the names associated with a given dimension is just one of possible metadata, but I'd keep away from meddling with it for a start. It would seem natural that metadata associated with one dimension: would a table-like object (data.frame seems natural in R, and unfortunately there is no data.frame-like structure in R). L. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Suggestion: Dimension-sensitive attributes
Bengoechea Bartolomé Enrique (SIES 73) wrote: Forgot to answer this one: It would seem natural that metadata associated with one dimension: would a table-like object [thanks for reading through what seems much like a telescoped sentences] Right. A data frame has the problem that for most use cases one would want that each dimension length matches the *rows* of the data frame instead of the columns, but it is the columns what we would have for free when allowing dimmeta elements to be lists... Think of one data.frame per dimension and each data.frame having its rows aligned along that dimension. In the case of a matrix, the dim-1 data.frame would have as many rows as rows in the matrix and the dim-2 data.frame would have as many rows as columns in the matrix. When thinking in terms of generalization, one can also note that the one-dimension case can already be modelled by a data.frame. L. Enrique -Original Message- From: Laurent Gautier [mailto:lgaut...@gmail.com] Sent: jueves, 09 de julio de 2009 14:15 Cc: Heinz Tuechler; Bengoechea Bartolomé Enrique (SIES 73); Tony Plate; Henrik Bengtsson; r-devel@r-project.org Subject: Re: [Rd] Suggestion: Dimension-sensitive attributes Starting by working on an interface for such object(s) is probably the first step toward a unified solution, and this before about if and how R attributes are used. It would also help to ensure a smooth transition from the existing classes implementing a similar solution (first the interface is added to those classes, then after a grace period the classes are eventually refactored). Dimension-level is what seems to the be most needed... but I am not convinced of the practicality of the object-level, and cell-level scheme s proposed: - Object-level, if not linked to any dimension-attribute is such saying that one want to attach anything to any object. That's what attr() is already doing. - Cell-level, is may be out-of-scope for one first trial (but may be I missed the use-cases for it) If starting with behaviour, it seems to boil to having [/[- and dimmeta()/dimmeta-(), : - extract [ / replace [- : * keeps working the way it already does * extracts a subset of the object as well as a subset of the dimension-associated metadata. * departing too much from the way [ is working and add behind-the-curtain name matching will only compromise the chances of adoption. * forget about the bit about which metadata is kept and which one isn't when using [. Make a function unmeta() (similar behavior to unname()) to drop them all, or work it out with something like dimmeta(x, 1) - NULL # drop the metadata associated with dimension 1 - access the dimension-associated metadata: * may be a function called dimmeta() (for consistency with dimnames()) ? The signature could be dimmeta(x, i), with x the object, and i the dimension requested. A replace function dimmeta-(x, i, value) would be provided. In the abstract the names associated with a given dimension is just one of possible metadata, but I'd keep away from meddling with it for a start. It would seem natural that metadata associated with one dimension: would a table-like object (data.frame seems natural in R, and unfortunately there is no data.frame-like structure in R). L. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] In C, a fast way to slice a vector?
r-devel-requ...@r-project.org wrote: Impressive stuff. Nice to see people giving some though to this. I will explore the packages you mentioned. Thank you Saptarshi Guha On Mon, May 11, 2009 at 12:37 AM, Patrick Aboyoun paboy...@fhcrc.org wrote: Saptarshi, I know of two alternatives you can use to do fast extraction of consecutive subsequences of a vector: 1) Fast copy: ?The method you mentioned of creating a memcpy'd vector 2) Pointer management: Creating an externalptr object in R and manage the start and end of your data If you are looking for a prototyping environment to try, I recommend using the IRanges and Biostrings packages from the Bioconductor project. The IRanges package contains a function called subseq for performing 1) on all basic vector types (raw, logical, integer, etc.) and Biostrings package contains a subseq method on an externalptr based class that implements 2. I was going to lobby R core members quietly about adding something akin to subseq from IRanges into base R since it is extremely useful for all long vectors and could replace all a:b calls with a = b in R code, but this publicity can't hurt. The Python development team has been developing something similar for python 3.0 (Buffer and Memoryview), and they are backporting it to the latest 2.x releases. I have just started toying with it, and it seems looking very nice. There might be good ideas to take from there into a possible R built-in capability. L. Here is an example: source(http://bioconductor.org/biocLite.R;) biocLite(c(IRanges, Biostrings)) download output omitted suppressMessages(library(Biostrings)) x - rep(charToRaw(a), 1e7) y - BString(rawToChar(x)) suppressMessages(library(Biostrings)) x - rep(charToRaw(a), 1e7) y - BString(rawToChar(x)) system.time(x[13:1e7]) ? user ?system elapsed ?0.304 ? 0.073 ? 0.378 system.time(subseq(x, 13)) ? user ?system elapsed ?0.011 ? 0.007 ? 0.019 system.time(subseq(y, 13)) ? user ?system elapsed ?0.003 ? 0.000 ? 0.004 identical(x[13:1e7], subseq(x, 13)) [1] TRUE identical(x[13:1e7], charToRaw(as.character(subseq(y, 13 [1] TRUE sessionInfo() R version 2.10.0 Under development (unstable) (2009-05-08 r48504) i386-apple-darwin9.6.0 locale: [1] en_US.UTF-8/en_US.UTF-8/C/C/en_US.UTF-8/en_US.UTF-8 attached base packages: [1] stats ? ? graphics ?grDevices utils ? ? datasets ?methods ? base other attached packages: [1] Biostrings_2.13.5 IRanges_1.3.5 loaded via a namespace (and not attached): [1] Biobase_2.5.2 Quoting Saptarshi Guha saptarshi.g...@gmail.com: Hello, Suppose in the following code, PROTECT(sr = R_tryEval( )) sr is a RAWSXP vector. I wish to return another RAWSXP starting at position 13 onwards (base=0). I could create another RAWSXP of the correct length and then memcpy the required bytes and length to this new one. However is there a more efficient method? Regards Saptarshi Guha __ 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] Follow-up on the wish for a visibility flag with tryEval ?
I guess that I should have been reminding that the thread referred to is mostly about C API-level utilities (and the subject for this thread should be mentioning more precisely *R_tryEval()* ). Wrapping evaluation from C-level in an R-level withVisible() call is certainly possible if this is the only way to do it: - a C-level utility function is probably becoming handy (and that's mostly what the wish is about, AFAIUI). - the traceback has at least one added layer from the call to withVisible(); this is something supplementary to take care of when writing a GUI for example. Those are possible reasons why the threads tells that withVisible() [R-level] is a temporary option, waiting for something like R_tryEvalWithVis() [C-level]. Can't I find any such C-level because there isn't any, or because I just missed it ? Thanks, L. Duncan Murdoch wrote: On 07/03/2009 9:51 AM, Laurent Gautier wrote: Dear list, Did the wish for an official API for evaluating expressions while keeping an eye on the R_Visible flag (see: https://stat.ethz.ch/pipermail/r-devel/2007-April/045258.html ) lead to something ? I could not find a sign of it the current (R-2.8.1 and R-2.9-dev) R defines. You should read the NEWS file, where you'll find withVisible mentioned. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Follow-up on the wish for a visibility flag with tryEval ?
Dear list, Did the wish for an official API for evaluating expressions while keeping an eye on the R_Visible flag (see: https://stat.ethz.ch/pipermail/r-devel/2007-April/045258.html ) lead to something ? I could not find a sign of it the current (R-2.8.1 and R-2.9-dev) R defines. Thanks, L. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Sending an interrupt signal to an embedded R
Dear List, I am working on a Python-R interface in which an embedded R is used (rpy project on sourceforge). I would like to allow the interruption of R computation through signals, that is handle signals sent to the embedded R process while computing, but I am unsure regarding what is currently the most appropriate approach. I have found threads on this list from up to two years ago, but there appeared to be some debating... making it difficult to choose on which end to start (platform-specific variability in the examples is also making it for a steep start). Is there a documentation on the topic I would have missed ? Thanks, Laurent __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] unrelated software install triggering an error from R's install script on Mac OS X 10.5
Simon Urbanek wrote: On Dec 1, 2008, at 6:11 AM, Laurent Gautier wrote: Stefan Evert wrote: The steps needed to generate the error are: - install a binary distribution of R (default location) - add R to the PATH Did you actually add /Library/Frameworks/R.framework/Resources/bin/ to your PATH? You're not supposed to do that! What made you think so? Coming from an UNIX background, adding a directory like bin/ to the PATH does not appear unreasonable. ... if you really want those files to prepend your PATH. You get what you deserve ;) I this case you don't want that and this is true for all unix platforms. The point seems to be slightly missed here: the result of installing R is that there is no R executable in the path, and that adding the only bin/ directory coming with the install to be path results in a broken system. This directory contains a range of support scripts for R which are not intended for direct use from the command line or other programs. In my installation, there's just a symlink from /usr/bin/R to the R binary in the directory above, which AFAIK is the only program you need to invoke directly. I am relatively new to OS X, so I cannot tell whether this is an R specificity, or the way things are usually done on OS X are somewhat very different from the UNIX way. Then you seem to be very unfamiliar with the unix way as it appears... Ah ! the flourishing pronouncements on the R-lists... I am surprised by this cherry pick one executable in bin/ / don't touch the PATH. You are apparently unaware of the way R is setup ... Note that on most unix systems this is exactly what you get - the R_HOME/bin directory is tucked away in /usr/local/lib/R/bin which is never on your PATH since R installs the user-visible scripts to /usr/local/bin. The same happens here. I guess that we this comparing apples with oranges here: a default R install is leaving binaries in the path when performing a default install, which does not seem to be the case here (therefore forcing a hunt for the executable for the R console and resulting in the present thread). The point here is that there is no user-exposed bin/ directory (or copying of the right executables by default to a place commonly agreed by some UNIX audiences as proper for binaries), and that the only bin/ found contains executables one should not get in his/her PATH. In your case, R's INSTALL script, which implements the R CMD INSTALL functionality masks the standard install program in /usr/bin/install, so Python's installer now picks up a completely wrong program. Even if you edit R's INSTALL script, it'll do something entirely different from what you expect. To my great dismay I am hearing here that Mac OS X is not case-sensitive. Mac OS X is case-sensitive. Case-sensitivity is an option of the mounted file system and you can choose either. It is common to use case-insensitive fs for historical reasons (compatibility with older software), but you don't have to. BTW, putting the R binary directory ahead of system directories such as /usr/bin in your PATH is an even worse idea than including it there in the first place. ;-) I am used to the fact that adding a bin/ directory in the PATH (and *ahead* of all other components in the PATH) is the way to add custom binaries. If you want to override the system ones, yes. But you better know what you're doing ;). I cannot exclude that I am missing some specificities of Mac OS X, but that idea seems to be at least shared by the fink project (their default install puts /sw/bin ahead of all the rest). .. which leads to quite a few problems on its own. That's why you're entirely on your own if you do so (and likely to run into problems where Fink replaces systems parts with non-standard binaries). I suppose that there is a documentation for R-on-OS-X and that I overlooked it. You overlooked quite a bit of documentation of unix and R - pretty much none of it is OS X - specific. Cheers, S __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] unrelated software install triggering an error from R's install script on Mac OS X 10.5
Stefan Evert wrote: The steps needed to generate the error are: - install a binary distribution of R (default location) - add R to the PATH Did you actually add /Library/Frameworks/R.framework/Resources/bin/ to your PATH? You're not supposed to do that! What made you think so? Coming from an UNIX background, adding a directory like bin/ to the PATH does not appear unreasonable. This directory contains a range of support scripts for R which are not intended for direct use from the command line or other programs. In my installation, there's just a symlink from /usr/bin/R to the R binary in the directory above, which AFAIK is the only program you need to invoke directly. I am relatively new to OS X, so I cannot tell whether this is an R specificity, or the way things are usually done on OS X are somewhat very different from the UNIX way. I am surprised by this cherry pick one executable in bin/ / don't touch the PATH. In your case, R's INSTALL script, which implements the R CMD INSTALL functionality masks the standard install program in /usr/bin/install, so Python's installer now picks up a completely wrong program. Even if you edit R's INSTALL script, it'll do something entirely different from what you expect. To my great dismay I am hearing here that Mac OS X is not case-sensitive. BTW, putting the R binary directory ahead of system directories such as /usr/bin in your PATH is an even worse idea than including it there in the first place. ;-) I am used to the fact that adding a bin/ directory in the PATH (and *ahead* of all other components in the PATH) is the way to add custom binaries. I cannot exclude that I am missing some specificities of Mac OS X, but that idea seems to be at least shared by the fink project (their default install puts /sw/bin ahead of all the rest). I suppose that there is a documentation for R-on-OS-X and that I overlooked it. Laurent Best regards, Stefan Evert [ [EMAIL PROTECTED] | http://purl.org/stefan.evert ] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] unrelated software install triggering an error from R's install script on Mac OS X 10.5
Dear List, I am having a problem triggered by having R-2.8 (R version 2.8.0 Patched (2008-11-15 r46953)) installed on Mac OS X 10.5. The steps needed to generate the error are: - install a binary distribution of R (default location) - add R to the PATH - install the python module pycairo (http://www.cairographics.org/releases/pycairo-1.4.12.tar.gz) That last step results in an error, and the error message point in the direction of the R installation (see below): Making install in cairo test -z /sw/lib/python2.5/site-packages/cairo || .././install-sh -c -d /sw/lib/python2.5/site-packages/cairo /bin/sh ../libtool --mode=install /Library/Frameworks/R.framework/Resources/bin/install -c '_cairo.la' '/sw/lib/python2.5/site-packages/cairo/_cairo.la' /Library/Frameworks/R.framework/Resources/bin/install -c .libs/_cairo.so /sw/lib/python2.5/site-packages/cairo/_cairo.so /Library/Frameworks/R.framework/Resources/bin/install: line 113: /sh/dcf.sh: No such file or directory make[2]: *** [install-pycairoexecLTLIBRARIES] Error 1 make[1]: *** [install-am] Error 2 make: *** [install-recursive] Error 1 Editing /Library/Frameworks/R.framework/Resources/bin/install, and hard-code the right path to R_SHARE_DIR is obviously an option, but I would like to hear that something more elegant is possible. Laurent __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] cairo device and pch=+
Dear list, I have spotted what could be a memory leak somewhere. The example below shows how to quickly use up RAM on a linux machine (the example is taylored for a 2Gb machine, change the size of the matrix m is needed). # --- m - matrix(rnorm(130), nrow=6000, 6) X11(type=cairo) pairs(m) # --- here the trouble starts (monitor the memory usage as the plot goes). pairs(m, pch=+) # this does not seem to act on memory usage of the R process dev.off() gc() # the only way to get back some memory is to kill the R process. L. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] garbage collection, preserved variables, and different outcome depending on --verbose or not
I just tried with R-devel (2.8.0 Under development (unstable)
(2008-07-20 r46088),
the problem does not appear with that version.
Thanks,
L.
2008/7/20 Laurent Gautier [EMAIL PROTECTED]:
2008/7/20 Duncan Murdoch [EMAIL PROTECTED]:
On 20/07/2008 10:02 AM, Laurent Gautier wrote:
I tripped on that while crafting the example.
The problem still exists when moving the releases in the middle,
and removing the last release.
I also see that the C code contains old/irrelevant comments at the top
of the function
lostobject. Sorry about that, the bug I am chasing is elusive...
I can't spot any problems in the new version of your code, but I can't
reproduce the problem, either. So it appears to be system specific -- I was
using the identical revision as you, but on Windows, not
x86_64-unknown-linux-gnu. What exact Linux is that?
Ubuntu (hardy heron).
gcc is 4.2.3
The R source was built with make clean; ./configure --enable-R-shlib
before running make; make install
Can others using that system (or similar ones) reproduce it?
Duncan Murdoch
#include R.h
#include Rdefines.h
SEXP createObject(void)
{
SEXP x_R;
int len_x = 100;
PROTECT(x_R = allocVector(REALSXP, len_x));
Rprintf(Created 'x' at %p\n, x_R);
Rprintf( (mode is %i, length is %i)\n, TYPEOF(x_R), LENGTH(x_R));
Rprintf( (first element is %d)\n, REAL(x_R)[0]);
R_PreserveObject(x_R);
UNPROTECT(1);
return x_R;
}
void printObject(SEXP sexp)
{
Rprintf(object at %p\n, sexp);
Rprintf( (mode is %i, length is %i, named is %i)\n,
TYPEOF(sexp), LENGTH(sexp), NAMED(sexp));
}
SEXP lostobject(SEXP n_R)
{
/*
* This function will:
* 1- create a numerical vector x and preserve it
* 2- make call list(x)
* 3- return x to R
*/
SEXP x_R;
int i;
int n = INTEGER(n_R)[0];
/* Create a numerical vector x_R */
for (i=0; in; i++) {
x_R = createObject();
printObject(x_R);
R_ReleaseObject(x_R);
R_gc();
}
x_R = createObject();
printObject(x_R);
R_gc();
Rprintf(Returning 'x' at %p\n, x_R);
Rprintf( (first element is %d)\n, REAL(x_R)[0]);
return x_R;
}
2008/7/20 Duncan Murdoch [EMAIL PROTECTED]:
On 20/07/2008 9:01 AM, Laurent Gautier wrote:
Dear list,
While trying to identify the root of a problem I am having with
garbage collected variables,
I have come across the following oddity: depending on whether --verbose
is
set
or not, I obtain different results.
You are working with variables without protecting them, so you just get
lucky whenever the code works.
More below...
I have made a small standalone example to demonstrate it.
The example is very artificial, but I had a hard time reproducing
reliably the problem.
So when I do: (the content of test.R is at the end of this email)
R --no-save test.R
[The two last lines of the output are:]
x[1:3]
[1] 0 0 0
while with
R --verbose --no-save test.R
[The two last lines of the output are:]
x[1:3]
[1] 3.733188e-317 3.137345e-317 3.137345e-317
The C code is compiled with:
R CMD SHLIB test_lostobject.c
sessionInfo()
R version 2.7.1 Patched (2008-07-19 r46081)
x86_64-unknown-linux-gnu
locale:
LC_CTYPE=en_US.UTF-8;LC_NUMERIC=C;LC_TIME=en_US.UTF-8;LC_COLLATE=en_US.UTF-8;LC_MONETARY=C;LC_MESSAGES=en_US.UTF-8;LC_PAPER=en_US.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US.UTF-8;LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
### -- file test.R
dyn.load(test_lostobject.so)
x = .Call(lostobject, as.integer(5))
x[1:3]
### ---
###--- file lostobject.c
#include R.h
#include Rdefines.h
SEXP createObject(void)
{
SEXP x_R;
int len_x = 100;
PROTECT(x_R = allocVector(REALSXP, len_x));
Rprintf(Created 'x' at %p\n, x_R);
Rprintf( (mode is %i, length is %i)\n, TYPEOF(x_R), LENGTH(x_R));
Rprintf( (first element is %d)\n, REAL(x_R)[0]);
R_PreserveObject(x_R);
UNPROTECT(1);
return x_R;
}
void printObject(SEXP sexp)
{
Rprintf(object at %p\n, sexp);
Rprintf( (mode is %i, length is %i, named is %i)\n,
TYPEOF(sexp), LENGTH(sexp), NAMED(sexp));
}
SEXP lostobject(SEXP n_R)
{
/*
* This function will:
* 1- create a numerical vector x and preserve it
* 2- make call list(x)
* 3- return x to R
*/
SEXP x_R;
int i;
int n = INTEGER(n_R)[0];
/* Create a numerical vector x_R */
for (i=0; in; i++) {
x_R = createObject();
R_ReleaseObject(x_R);
At this point, the variable is unprotected, i.e. you have declared that
its
memory is free for the taking. You should not try to do anything with
it.
printObject calls several functions, and one of those may have
overwritten
the memory. It's not surprising that different flags (--verbose or not)
result in different behaviour.
printObject(x_R);
R_gc();
}
x_R = createObject();
printObject(x_R);
R_gc();
R_ReleaseObject(x_R);
Same
[Rd] garbage collection, preserved variables, and different outcome depending on --verbose or not
Dear list,
While trying to identify the root of a problem I am having with
garbage collected variables,
I have come across the following oddity: depending on whether --verbose is set
or not, I obtain different results.
I have made a small standalone example to demonstrate it.
The example is very artificial, but I had a hard time reproducing
reliably the problem.
So when I do: (the content of test.R is at the end of this email)
R --no-save test.R
[The two last lines of the output are:]
x[1:3]
[1] 0 0 0
while with
R --verbose --no-save test.R
[The two last lines of the output are:]
x[1:3]
[1] 3.733188e-317 3.137345e-317 3.137345e-317
The C code is compiled with:
R CMD SHLIB test_lostobject.c
sessionInfo()
R version 2.7.1 Patched (2008-07-19 r46081)
x86_64-unknown-linux-gnu
locale:
LC_CTYPE=en_US.UTF-8;LC_NUMERIC=C;LC_TIME=en_US.UTF-8;LC_COLLATE=en_US.UTF-8;LC_MONETARY=C;LC_MESSAGES=en_US.UTF-8;LC_PAPER=en_US.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US.UTF-8;LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
### -- file test.R
dyn.load(test_lostobject.so)
x = .Call(lostobject, as.integer(5))
x[1:3]
### ---
###--- file lostobject.c
#include R.h
#include Rdefines.h
SEXP createObject(void)
{
SEXP x_R;
int len_x = 100;
PROTECT(x_R = allocVector(REALSXP, len_x));
Rprintf(Created 'x' at %p\n, x_R);
Rprintf( (mode is %i, length is %i)\n, TYPEOF(x_R), LENGTH(x_R));
Rprintf( (first element is %d)\n, REAL(x_R)[0]);
R_PreserveObject(x_R);
UNPROTECT(1);
return x_R;
}
void printObject(SEXP sexp)
{
Rprintf(object at %p\n, sexp);
Rprintf( (mode is %i, length is %i, named is %i)\n,
TYPEOF(sexp), LENGTH(sexp), NAMED(sexp));
}
SEXP lostobject(SEXP n_R)
{
/*
* This function will:
* 1- create a numerical vector x and preserve it
* 2- make call list(x)
* 3- return x to R
*/
SEXP x_R;
int i;
int n = INTEGER(n_R)[0];
/* Create a numerical vector x_R */
for (i=0; in; i++) {
x_R = createObject();
R_ReleaseObject(x_R);
printObject(x_R);
R_gc();
}
x_R = createObject();
printObject(x_R);
R_gc();
R_ReleaseObject(x_R);
Rprintf(Returning 'x' at %p\n, x_R);
Rprintf( (first element is %d)\n, REAL(x_R)[0]);
return x_R;
}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] garbage collection, preserved variables, and different outcome depending on --verbose or not
I tripped on that while crafting the example.
The problem still exists when moving the releases in the middle,
and removing the last release.
#include R.h
#include Rdefines.h
SEXP createObject(void)
{
SEXP x_R;
int len_x = 100;
PROTECT(x_R = allocVector(REALSXP, len_x));
Rprintf(Created 'x' at %p\n, x_R);
Rprintf( (mode is %i, length is %i)\n, TYPEOF(x_R), LENGTH(x_R));
Rprintf( (first element is %d)\n, REAL(x_R)[0]);
R_PreserveObject(x_R);
UNPROTECT(1);
return x_R;
}
void printObject(SEXP sexp)
{
Rprintf(object at %p\n, sexp);
Rprintf( (mode is %i, length is %i, named is %i)\n,
TYPEOF(sexp), LENGTH(sexp), NAMED(sexp));
}
SEXP lostobject(SEXP n_R)
{
/*
* This function will:
* 1- create a numerical vector x and preserve it
* 2- make call list(x)
* 3- return x to R
*/
SEXP x_R;
int i;
int n = INTEGER(n_R)[0];
/* Create a numerical vector x_R */
for (i=0; in; i++) {
x_R = createObject();
printObject(x_R);
R_ReleaseObject(x_R);
R_gc();
}
x_R = createObject();
printObject(x_R);
R_gc();
Rprintf(Returning 'x' at %p\n, x_R);
Rprintf( (first element is %d)\n, REAL(x_R)[0]);
return x_R;
}
2008/7/20 Duncan Murdoch [EMAIL PROTECTED]:
On 20/07/2008 9:01 AM, Laurent Gautier wrote:
Dear list,
While trying to identify the root of a problem I am having with
garbage collected variables,
I have come across the following oddity: depending on whether --verbose is
set
or not, I obtain different results.
You are working with variables without protecting them, so you just get
lucky whenever the code works.
More below...
I have made a small standalone example to demonstrate it.
The example is very artificial, but I had a hard time reproducing
reliably the problem.
So when I do: (the content of test.R is at the end of this email)
R --no-save test.R
[The two last lines of the output are:]
x[1:3]
[1] 0 0 0
while with
R --verbose --no-save test.R
[The two last lines of the output are:]
x[1:3]
[1] 3.733188e-317 3.137345e-317 3.137345e-317
The C code is compiled with:
R CMD SHLIB test_lostobject.c
sessionInfo()
R version 2.7.1 Patched (2008-07-19 r46081)
x86_64-unknown-linux-gnu
locale:
LC_CTYPE=en_US.UTF-8;LC_NUMERIC=C;LC_TIME=en_US.UTF-8;LC_COLLATE=en_US.UTF-8;LC_MONETARY=C;LC_MESSAGES=en_US.UTF-8;LC_PAPER=en_US.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US.UTF-8;LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
### -- file test.R
dyn.load(test_lostobject.so)
x = .Call(lostobject, as.integer(5))
x[1:3]
### ---
###--- file lostobject.c
#include R.h
#include Rdefines.h
SEXP createObject(void)
{
SEXP x_R;
int len_x = 100;
PROTECT(x_R = allocVector(REALSXP, len_x));
Rprintf(Created 'x' at %p\n, x_R);
Rprintf( (mode is %i, length is %i)\n, TYPEOF(x_R), LENGTH(x_R));
Rprintf( (first element is %d)\n, REAL(x_R)[0]);
R_PreserveObject(x_R);
UNPROTECT(1);
return x_R;
}
void printObject(SEXP sexp)
{
Rprintf(object at %p\n, sexp);
Rprintf( (mode is %i, length is %i, named is %i)\n,
TYPEOF(sexp), LENGTH(sexp), NAMED(sexp));
}
SEXP lostobject(SEXP n_R)
{
/*
* This function will:
* 1- create a numerical vector x and preserve it
* 2- make call list(x)
* 3- return x to R
*/
SEXP x_R;
int i;
int n = INTEGER(n_R)[0];
/* Create a numerical vector x_R */
for (i=0; in; i++) {
x_R = createObject();
R_ReleaseObject(x_R);
At this point, the variable is unprotected, i.e. you have declared that its
memory is free for the taking. You should not try to do anything with it.
printObject calls several functions, and one of those may have overwritten
the memory. It's not surprising that different flags (--verbose or not)
result in different behaviour.
printObject(x_R);
R_gc();
}
x_R = createObject();
printObject(x_R);
R_gc();
R_ReleaseObject(x_R);
Same thing here. x_R is unprotected now, so you shouldn't use it.
Duncan Murdoch
Rprintf(Returning 'x' at %p\n, x_R);
Rprintf( (first element is %d)\n, REAL(x_R)[0]);
return x_R;
}
__
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] garbage collection, preserved variables, and different outcome depending on --verbose or not
2008/7/20 Duncan Murdoch [EMAIL PROTECTED]:
On 20/07/2008 10:02 AM, Laurent Gautier wrote:
I tripped on that while crafting the example.
The problem still exists when moving the releases in the middle,
and removing the last release.
I also see that the C code contains old/irrelevant comments at the top
of the function
lostobject. Sorry about that, the bug I am chasing is elusive...
I can't spot any problems in the new version of your code, but I can't
reproduce the problem, either. So it appears to be system specific -- I was
using the identical revision as you, but on Windows, not
x86_64-unknown-linux-gnu. What exact Linux is that?
Ubuntu (hardy heron).
gcc is 4.2.3
The R source was built with make clean; ./configure --enable-R-shlib
before running make; make install
Can others using that system (or similar ones) reproduce it?
Duncan Murdoch
#include R.h
#include Rdefines.h
SEXP createObject(void)
{
SEXP x_R;
int len_x = 100;
PROTECT(x_R = allocVector(REALSXP, len_x));
Rprintf(Created 'x' at %p\n, x_R);
Rprintf( (mode is %i, length is %i)\n, TYPEOF(x_R), LENGTH(x_R));
Rprintf( (first element is %d)\n, REAL(x_R)[0]);
R_PreserveObject(x_R);
UNPROTECT(1);
return x_R;
}
void printObject(SEXP sexp)
{
Rprintf(object at %p\n, sexp);
Rprintf( (mode is %i, length is %i, named is %i)\n,
TYPEOF(sexp), LENGTH(sexp), NAMED(sexp));
}
SEXP lostobject(SEXP n_R)
{
/*
* This function will:
* 1- create a numerical vector x and preserve it
* 2- make call list(x)
* 3- return x to R
*/
SEXP x_R;
int i;
int n = INTEGER(n_R)[0];
/* Create a numerical vector x_R */
for (i=0; in; i++) {
x_R = createObject();
printObject(x_R);
R_ReleaseObject(x_R);
R_gc();
}
x_R = createObject();
printObject(x_R);
R_gc();
Rprintf(Returning 'x' at %p\n, x_R);
Rprintf( (first element is %d)\n, REAL(x_R)[0]);
return x_R;
}
2008/7/20 Duncan Murdoch [EMAIL PROTECTED]:
On 20/07/2008 9:01 AM, Laurent Gautier wrote:
Dear list,
While trying to identify the root of a problem I am having with
garbage collected variables,
I have come across the following oddity: depending on whether --verbose
is
set
or not, I obtain different results.
You are working with variables without protecting them, so you just get
lucky whenever the code works.
More below...
I have made a small standalone example to demonstrate it.
The example is very artificial, but I had a hard time reproducing
reliably the problem.
So when I do: (the content of test.R is at the end of this email)
R --no-save test.R
[The two last lines of the output are:]
x[1:3]
[1] 0 0 0
while with
R --verbose --no-save test.R
[The two last lines of the output are:]
x[1:3]
[1] 3.733188e-317 3.137345e-317 3.137345e-317
The C code is compiled with:
R CMD SHLIB test_lostobject.c
sessionInfo()
R version 2.7.1 Patched (2008-07-19 r46081)
x86_64-unknown-linux-gnu
locale:
LC_CTYPE=en_US.UTF-8;LC_NUMERIC=C;LC_TIME=en_US.UTF-8;LC_COLLATE=en_US.UTF-8;LC_MONETARY=C;LC_MESSAGES=en_US.UTF-8;LC_PAPER=en_US.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US.UTF-8;LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
### -- file test.R
dyn.load(test_lostobject.so)
x = .Call(lostobject, as.integer(5))
x[1:3]
### ---
###--- file lostobject.c
#include R.h
#include Rdefines.h
SEXP createObject(void)
{
SEXP x_R;
int len_x = 100;
PROTECT(x_R = allocVector(REALSXP, len_x));
Rprintf(Created 'x' at %p\n, x_R);
Rprintf( (mode is %i, length is %i)\n, TYPEOF(x_R), LENGTH(x_R));
Rprintf( (first element is %d)\n, REAL(x_R)[0]);
R_PreserveObject(x_R);
UNPROTECT(1);
return x_R;
}
void printObject(SEXP sexp)
{
Rprintf(object at %p\n, sexp);
Rprintf( (mode is %i, length is %i, named is %i)\n,
TYPEOF(sexp), LENGTH(sexp), NAMED(sexp));
}
SEXP lostobject(SEXP n_R)
{
/*
* This function will:
* 1- create a numerical vector x and preserve it
* 2- make call list(x)
* 3- return x to R
*/
SEXP x_R;
int i;
int n = INTEGER(n_R)[0];
/* Create a numerical vector x_R */
for (i=0; in; i++) {
x_R = createObject();
R_ReleaseObject(x_R);
At this point, the variable is unprotected, i.e. you have declared that
its
memory is free for the taking. You should not try to do anything with
it.
printObject calls several functions, and one of those may have
overwritten
the memory. It's not surprising that different flags (--verbose or not)
result in different behaviour.
printObject(x_R);
R_gc();
}
x_R = createObject();
printObject(x_R);
R_gc();
R_ReleaseObject(x_R);
Same thing here. x_R is unprotected now, so you shouldn't use it.
Duncan Murdoch
Rprintf(Returning 'x' at %p\n, x_R);
Rprintf( (first element is %d)\n, REAL(x_R)[0]);
return x_R
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
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] Embedded R, last errormessage, and stack smashing
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] Error in getClass when calling the function show
2008/6/10 Prof Brian Ripley [EMAIL PROTECTED]:
showDefault has
clDef - getClass(class(object))
Looks like the showDefault code intended
clDef - getClass(class(object), .force=TRUE)
However, why are you calling show() on a non-S4 object? I cannot see any
advtanges in doing so.
I'd like *one* printing method for all objects, and the generic show
is registered as working for ANYthing (see below) ?
Or is defining one's own function currently recommended ?
myPrint - function(x, ...)
{
if (isS4(x)) {
show(x, ...)
} else {
print(x, ...)
}
}
showMethods(show)
Function: show (package methods)
object=ANY
object=classRepresentation
object=derivedDefaultMethod
(inherited from: object=MethodDefinition)
object=function
(inherited from: object=ANY)
object=genericFunction
object=MethodDefinition
object=MethodsList
(inherited from: object=ANY)
object=MethodWithNext
object=ObjectsWithPackage
object=signature
object=traceable
showMethods(print)
Function print:
not a generic function
getMethod(show, ANY)
Method Definition (Class derivedDefaultMethod):
function (object)
showDefault(object, FALSE)
environment: namespace:methods
Signatures:
object
target ANY
defined ANY
On Tue, 10 Jun 2008, Laurent Gautier wrote:
Dear List,
Calling show on an object of class summary.lm gives:
Error in getClass(class(object)) : summary.lm is not a defined class
Is this a miss on my end ?
x - seq(1, 10)
show(x)
[1] 1 2 3 4 5 6 7 8 9 10
y - runif(10)
fit - lm(y ~ x)
show(fit)
Call:
lm(formula = y ~ x)
Coefficients:
(Intercept)x
1.04938 -0.08869
show(summary(fit))
Error in getClass(class(object)) : summary.lm is not a defined class
class(summary(fit))
[1] summary.lm
class((fit))
[1] lm
getClass(lm)
Virtual Class
No Slots, prototype of class S4
Extends: oldClass
Known Subclasses:
Class mlm, directly
Class aov, directly
Class glm, directly
Class maov, by class mlm, distance 2
Class glm.null, by class glm, distance 2
getClass(summary.lm)
Error in getClass(summary.lm) : summary.lm is not a defined class
sessionInfo()
R version 2.7.0 Patched (2008-06-07 r45877)
i686-pc-linux-gnu
locale:
LC_CTYPE=en_US.UTF-8;LC_NUMERIC=C;LC_TIME=en_US.UTF-8;LC_COLLATE=en_US.UTF-8;LC_MONETARY=C;LC_MESSAGES=en_US.UTF-8;LC_PAPER=en_US.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US.UTF-8;LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
Laurent
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Error in getClass when calling the function show
Dear List, Calling show on an object of class summary.lm gives: Error in getClass(class(object)) : summary.lm is not a defined class Is this a miss on my end ? x - seq(1, 10) show(x) [1] 1 2 3 4 5 6 7 8 9 10 y - runif(10) fit - lm(y ~ x) show(fit) Call: lm(formula = y ~ x) Coefficients: (Intercept)x 1.04938 -0.08869 show(summary(fit)) Error in getClass(class(object)) : summary.lm is not a defined class class(summary(fit)) [1] summary.lm class((fit)) [1] lm getClass(lm) Virtual Class No Slots, prototype of class S4 Extends: oldClass Known Subclasses: Class mlm, directly Class aov, directly Class glm, directly Class maov, by class mlm, distance 2 Class glm.null, by class glm, distance 2 getClass(summary.lm) Error in getClass(summary.lm) : summary.lm is not a defined class sessionInfo() R version 2.7.0 Patched (2008-06-07 r45877) i686-pc-linux-gnu locale: LC_CTYPE=en_US.UTF-8;LC_NUMERIC=C;LC_TIME=en_US.UTF-8;LC_COLLATE=en_US.UTF-8;LC_MONETARY=C;LC_MESSAGES=en_US.UTF-8;LC_PAPER=en_US.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US.UTF-8;LC_IDENTIFICATION=C attached base packages: [1] stats graphics grDevices utils datasets methods base Laurent __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Makevars or congiure for multi platforms
2008/6/7 [EMAIL PROTECTED]: Message: 11 Date: Sat, 7 Jun 2008 03:38:23 +0900 From: Tadashi Kadowaki [EMAIL PROTECTED] Subject: [Rd] Makevars or congiure for multi platforms To: r-devel@r-project.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1 Dear all, As previously submitted, I wrote an extending pdf device to embed pop up text and web links. (Patches are available at http://pdf2.r-forge.r-project.org/patches) Now, I'm making a library version of the pdf device. However, with my skill, I'm not sure about writing Makevars or configure file for multi platforms. A following line in Makevars works on my mac, - PKG_CFLAGS=-I/Library/Frameworks/R.framework/PrivateHeaders -DHAVE_CONFIG_H - (Note that the PrivateHeaders directory contains Fileio.h and Defn.h) My question is, How do I write Makevars or congiure for Unix/Linux and Windows? I would like to support those platforms in my library. You could try looking into a package that has configure, configure.win and has built binaries for macosX and windows. Try the package 'rgl' on CRAN, for example. Hoping this helps, L. Regards, Tadashi Kadowaki __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] value returned by findFun when the name cannot be found.
Dear list, I have been using findVar (defined in src/main/envir.c) happily and would like to use findFun. However I have trouble when the name searched cannot be found: while findVar returns R_UnboundValue, findFun does not (the 4 last lines of findFun are copied below). error(_(could not find function \%s\), CHAR(PRINTNAME(symbol))); /* NOT REACHED */ return R_UnboundValue; } I assume that the comment /* NOT REACHED */ means that R_UnboundValue is not returned... and my question is: what is returned then ? (I am a little lost in the nested calls within error). Thanks, Laurent __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Experimental R_has_slot() utility
Dear list, The utility R_has_slot mentioned in the file NEWS (Experimental R_has_slot() utility supplementing R_do_slot()) appears to be missing from a fresh checkout of the development branch. $ svn up At revision 44759. $ grep -i has_slot `find include -name '*.h'` $ grep -i _slot `find include -name '*.h'` include/Rdefines.h:#define GET_SLOT(x, what) R_do_slot(x, what) include/Rdefines.h:#define SET_SLOT(x, what, value) R_do_slot_assign(x, what, value) include/Rinternals.h:SEXP R_do_slot(SEXP obj, SEXP name); include/Rinternals.h:SEXP R_do_slot_assign(SEXP obj, SEXP name, SEXP value); ..or did I miss it ? Thanks, L. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] extract function [ and empty index
Dear list, I am having a question regarding the extract function [. The man page says that one usage with k-dimensional arrays is to specify k indices to [, with an empty index indicating that all entries in that dimension are selected. The question is the following: is there an R object qualifying as an empty index ? I understand that the lazy evaluation of parameters allows one to have genuinely missing parameters, but I would like to have an object instead. I understand that one can always have an if/else workaround, but I thought should ask, just in case. I tried with NULL but with little success, as it appears to give the same results as an empty vector. m = matrix(1, 2, 2) m[1, NULL] numeric(0) m[1, integer(0)] numeric(0) Since I was at it, I noted that the result obtained with numeric(0) definitely makes sense but could as well be seen as challenging the concept of an empty index presented in the man page (One could somehow expect the presence of an object meaning everything rather than missingness meaning it). Thanks, Laurent __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] extract function [ and empty index
Thanks, I was forgetting the recycling rule. L. 2008/3/9, Gabor Grothendieck [EMAIL PROTECTED]: Use TRUE. On Sun, Mar 9, 2008 at 5:05 AM, Laurent Gautier [EMAIL PROTECTED] wrote: Dear list, I am having a question regarding the extract function [. The man page says that one usage with k-dimensional arrays is to specify k indices to [, with an empty index indicating that all entries in that dimension are selected. The question is the following: is there an R object qualifying as an empty index ? I understand that the lazy evaluation of parameters allows one to have genuinely missing parameters, but I would like to have an object instead. I understand that one can always have an if/else workaround, but I thought should ask, just in case. I tried with NULL but with little success, as it appears to give the same results as an empty vector. m = matrix(1, 2, 2) m[1, NULL] numeric(0) m[1, integer(0)] numeric(0) Since I was at it, I noted that the result obtained with numeric(0) definitely makes sense but could as well be seen as challenging the concept of an empty index presented in the man page (One could somehow expect the presence of an object meaning everything rather than missingness meaning it). Thanks, Laurent __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iEYEARECAAYFAkYgwJ4ACgkQB/w/MLoyRDeQlgCeMp8v69/Wy24Q4IaBVhoG1M5R 2h4AoIOTvKbrFpTklRDjV7u8tEOeSQqt =JPph -END PGP SIGNATURE- __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Calling R_PreserveObject from embedded R
Hello. This is my first post to the list, so first I'd like to thank everybody for making and mantaining such a great product as R. I'm writting a native binding to R from Dolphin Smalltalk. I've followed up the examples of the documentation showing how to run R embedded, and I got it partially working. However, I have a problem with the reference handling of the R objects. I've followed this strategy: every time I call a function in R and it answers me a SEXP, I called R_PreserveObject(sexp), and wrap it with a Smalltalk object. Whenever the Smalltalk object dies, I release the R object by calling R_ReleaseObject(sexp). This seems to handle well the life cycle, but makes the running process to use a growing and a never ending amount of memory. Actually, after experimenting a while, I isolated the problem to iterate over a loop which all it does is create an expresion for a number, call PreserveObject and call ReleaseObject, and that alone makes the memory to grow indefinitely. I couldn't find any comment about this behaviour. Is there something I'm missing ? Martin, I am working with code taking a similar approach (from Python), and I do not seem to observe what you are experiencing. When I initialize the embeded R with the --verbose flag, and initialize disposable objects from a loop in Python, R outputs lines such as the ones below: 11.8 Mbytes of vectors used (40%) Garbage collection 536 = 307+159+70 (level 0) ... 7.1 Mbytes of cons cells used (38%) 19.4 Mbytes of vectors used (65%) Garbage collection 537 = 307+160+70 (level 1) ... 7.1 Mbytes of cons cells used (38%) 11.8 Mbytes of vectors used (40%) I'm running the embedded R-2.6.2 binaries for Windows in a WindowsXP sp2 environment. I am currently working on Linux. I've also implemented another strategy, which keeps a global list in R, and instead of calling R_PreserveObject, it inserts the SEXP in the list. This made the memory usage problem to go away, but the performance is noticeably worst compared with the other strategy, and is not as elegant as the first one neither, so I was hoping to be able to use the first strategy. The first strategy appears is something similar, if I understood it right (there is a global SEXP object called R_PreciousList in memory.c). I'll appreciate any comment about what might be going on. May be try the --verbose flag ? Thanks in advance. Best regards. martin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] level of mutability for the type of a SEXP
2008/2/22, Prof Brian Ripley [EMAIL PROTECTED]: On Tue, 19 Feb 2008, Laurent Gautier wrote: Dear list, I am writing C code to interface with R, and I would like to know the level of mutability for the type of a SEXP. I see that there is a macro/function TYPEOF(), and that it can be used as an l-value, as well as a macro/function SET_TYPEOF(). The macros are not available to user code, so TYPEOF is not available to use as an l-value. Is the general rule that no macro is available to user code ? My question is should the type be considered immutable, or it can it change after the SEXP has been created and used for a while ?. I understand that a call to TYPEOF will not perform any conversion, and my question is only about being sure that once the type of a given SEXP is set it cannot change. It is SEXPRECs that have types, and their type can be changed and in a few cases is in R's internal code. You should only change type between SEXPREC types with the same structure, e.g. from VECSXP to EXPRSXP or DOTSXP to LISTSXP. I am unaware of any examples where this happens that involve a SEXPREC pointed to by a SEXP not in the internal code concerned. Thanks for your answer. As you point it out, I overlooked the fact that a SEXP is merely a pointer, and therefore will not change type. I systematically looked for usages of TYPEOF/SET_TYPEOF in the base code, and I could only find use of the macros beyond shortly after the instantiation of a new object. Since a SEXP is a pointer, the type of the SEXPREC it points to can change (as which SEXPREC it is can) and frequently does -- that is one way arguments are coerced. The R Internals manual has the details of the SEXPRECs and their structure. I will read more about them. I don't see the value of knowing though. Anyone who needs to ask about R internals should regard the arguments passed to .Call/.External calls as read-only and also assume that there is no simultaneous evaluation going on that might change them. My purpose is not to write C code called from R, but to make an interface between a scripting language and an embedded R. The reason for my question is that I would like to type a little R objects accessed from that foreign language, and would not like to see their type change along the evaluation of R code, and without the pointer from the scripting language knowing. The pass-by-value paradigm should not make such things possible, but I was considering that C-level memory optimization tricks could be recycling part of object structures (I may or may not be worth the effort, my little knowledge of SEXPRECs did not give any hint). Thanks, Laurent -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Strict-prototypes definitions in R includes
Thanks the answer. Would submitted patches with strict post-KR prototypes definition, for the void cases and for the includes likely to be used by writers of R extensions, be accepted ? Laurent 2008/1/27, Prof Brian Ripley [EMAIL PROTECTED]: I think the answer is 'it depends'. - such prototypes are not required by C99. - using (void) is part of some authors' style and not of others. For the latter, this is not an 'oversight' but an uglification. - in some cases the omission is deliberate as the function is used for variable sets of arguments (e.g, in GraphicsDevice.h). - in others the omission is because it seemed safer to leave the prototype out than to get it wrong (when passing functions, for example). - some code is taken from other projects and still has KR style declarations. On Sun, 27 Jan 2008, Laurent Gautier wrote: Dear list, Whenever the flag -Wstrict-prototypes is set in gcc, compiling code that includes headers in lib/R/include generates often warnings (example with R-2.6.1: Rinternals.h:560: warning: function declaration isn't a prototype ). All such warnings I looked at were about functions with empty signatures declared as bar foo(); rather than bar foo(void);. Is there a reason, or is this just an oversight in the include files ? It seems you were rather selective in your looking. Thanks, Laurent -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Strict-prototypes definitions in R includes
Dear list, Whenever the flag -Wstrict-prototypes is set in gcc, compiling code that includes headers in lib/R/include generates often warnings (example with R-2.6.1: Rinternals.h:560: warning: function declaration isn't a prototype ). All such warnings I looked at were about functions with empty signatures declared as bar foo(); rather than bar foo(void);. Is there a reason, or is this just an oversight in the include files ? Thanks, Laurent __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
