similar to: R (external ?) reference

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 <luke-tierney at uiowa.edu> wrote: > On Sat, 7 Sep 2019, Laurent Gautier wrote: > > > Hi, > > > > > > The function `Rf_findFun3` is declared in > > `$(R CMD CONFIG

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]]

Baring any unforeseen issues R-devel will switch in about a week from the NAMED mechanism to reference counting for determining when objects can be safely mutated in base C code. This is expected to have minimal impact on packages not using unsupported coding practices in their C code. The transition to reference counting has been in progress for a number of years. Some older notes on this are

This is very exciting news. Luke, thank you for all your work on this - I know it's been a long journey. All the best, Henrik On Tue, Dec 3, 2019 at 8:04 AM Tierney, Luke <luke-tierney at uiowa.edu> wrote: > > R-devel has been switched to use reference counting by default with > r77508. Building with -DSWITCH_TO_NAMED goes back to the NAMED > mechanism. > > Best,

Thank you Luke for prompt reply. Is it possible then to request a new function to R C API "message" that would equivalent to R "message" function? Similarly as we now have C "warning" and C "error" functions. Best, Jan On Sun, Sep 15, 2019 at 5:25 PM Tierney, Luke <luke-tierney at uiowa.edu> wrote: > > On Sun, 15 Sep 2019, Jan Gorecki wrote:

Thank you Luke. That is why I don't use Rf_inherits but INHERITS which does not allocate, provided in the email body. I cannot do similarly for S4 classes, thus asking for some API for that. On Fri, Nov 1, 2019 at 5:56 PM Tierney, Luke <luke-tierney at uiowa.edu> wrote: > > On Fri, 1 Nov 2019, Jan Gorecki wrote: > > > Dear R developers, > > > > Motivated by

This Index: src/main/altrep.c =================================================================== --- src/main/altrep.c (revision 79385) +++ src/main/altrep.c (working copy) @@ -275,10 +275,11 @@ SEXP psym = ALTREP_SERIALIZED_CLASS_PKGSYM(info); SEXP class = LookupClass(csym, psym); if (class == NULL) { - SEXP pname = ScalarString(PRINTNAME(psym)); + SEXP pname =

I noticed the recent commit to R-dev (r79434). Is this wise? I've often used get() in constructions like for (j in ls()) if (is.numeric(x <- get(j))) ... (and often interactively, rather than in a package) Am I to understand that get(j) will now be equivalent to `j` even if j is a string referring putatively to another object? On Sat, 14 Nov 2020 at 01:34, <luke-tierney at

I don't know, maybe it would make sense to keep the whole expression, that's the text of the tag after all. Also, if we don't keep the whole expression, then it is not a valid string literal any more, because it does not have quoting. I can try to look into a patch. This is for 4.1 I believe, so in some sense it is not urgent? Gabor On Wed, Apr 22, 2020 at 3:31 PM <luke-tierney

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

On Thu, 26 Jul 2018, G?bor Cs?rdi wrote: > On Thu, Jul 26, 2018 at 12:25 PM Barry Rowlingson > <b.rowlingson at lancaster.ac.uk> wrote: >> >> On Thu, Jul 26, 2018 at 12:22 AM, G?bor Cs?rdi <csardi.gabor at gmail.com> wrote: >>> I am trying to control a background R session, connected via a fifo / >>> named pipe. >> >> Is the fifo

Come on, folks. There is no NSE involved in calls to get(): it's standard evaluation all the way into the C code. Prior to the change a first argument that is anything other than a character vector would produce an error. After the change, passing in a symbol will do the obvious thing. Code that worked previously without error (i.e. called get() with string values) will continue to work

Would introducing the new frame, with the call to local(), cause problems when you use frame counting instead of <<- to modify variables outside the scope of lapply's FUN, I think the frame counts may have to change. E.g., here is code from actuar::simul() that might be affected: x <- unlist(lapply(nodes[[i]], seq)) lapply(nodes[(i + 1):(nlevels - 1)],

Redirecting to R-devel I don't recall how long the SUGUSR handlers have been in R -- you can check in svn if you like -- it's been a long time. The intention is for them to serve as an emergency break -- a chance of possibly saving the workspace when you get stuck in an infinite loop in C/Fortran code that cant be interrupted by a SIGINT. This can't be accomplished without doing

On Thu, Jan 22, 2015 at 11:44 AM, <luke-tierney at uiowa.edu> wrote: > I'm not convinced that how to make :: faster is the right question. If > you are finding foo::bar being called often enough to matter to your > overall performance then to me the question is: why are you calling > foo::bar more than once? Making :: a bit faster by making it a > primitive will remove

Same thing happens with S3 if you redefine print(). I thought that code was actually calculating the function to call rather than the symbol to use, but apparently not. Shouldn't be too hard to fix. luke On Tue, 30 Jun 2015, Hadley Wickham wrote: > On Tue, Jun 30, 2015 at 2:20 PM, Duncan Murdoch > <murdoch.duncan at gmail.com> wrote: >> On 30/06/2015 1:57 PM, Hadley

Dear all As far as I could trace, looking at the function C function numeric_deriv, this unwanted behavior comes from the inner most loop in, at the very end of the function, for(i = 0, start = 0; i < LENGTH(theta); i++) { for(j = 0; j < LENGTH(VECTOR_ELT(pars, i)); j++, start += LENGTH(ans)) { SEXP ans_del; double origPar, xx, delta; origPar = REAL(VECTOR_ELT(pars, i))[j];

On Thu, Jan 22, 2015 at 11:44 AM, <luke-tierney at uiowa.edu> wrote: > > For default methods there ought to be a way to create those so the > default method is computed at creation or load time and stored in an > environment. We had considered that, but we thought the definition of the function would be easier to interpret if it explicitly specified the namespace, instead of

I have committed a change to R-devel that addresses this. To be on the safe side I need to run some more extensive tests before deciding if this can be ported to the release branch for R 3.5.0. Should know in a day or two. Best, luke On Tue, 27 Mar 2018, luke-tierney at uiowa.edu wrote: > This has nothing to do with printing or dispatch per se. It is the > result of an internal register

On 30/06/2015 7:04 PM, Paul Gilbert wrote: > > > On 06/30/2015 11:33 AM, Duncan Murdoch wrote: >> On 30/06/2015 5:27 PM, Lorenz, David wrote: >>> There is something I'm really missing here. The function show is a >>> standardGeneric function, so the correct way to write it as method like >>> this: >> >> That describes methods::show. The