similar to: R's capaability of dealing with multiple requests

Hi, I am considering using R to integrate with a Java application. However, before deciding upon R I need to understand if R is capable of dealing with multiple requests simulataneously. Is a single instance of R capable of dealing with multiple simulataneous requests or does a new instance of R have to be started for each request? I have read Luke Tierney's 2001 notes on threading at

Luke, Thank you for sharing the benchmark results. The improvement is very substantial, I am looking forward to the release of the byte compiler! The arithmetic shows that x[i]<- is still the bottleneck. I suspect that this is due to a very involved dispatching/search for the appropriate function on the C level. There might be significant gain if loops somehow cached the result of the initial

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

If we are on the subject of byte compilation, let me bring a couple of examples which have been puzzling me for some time. I'd like to know a) if the compilation will likely to improve the performance for this type of computations, and b) at least roughly understand the reasons for the observed numbers, specifically why x[i]<- assignment is so much slower than x[i] extraction. The loops

You can file it as a wishlist item in the bug trackign system. Without a compelling case or a complete and well tested patch or both I doubt it will rise to the top of anyone's priority list. Best, luke On Sun, 15 Sep 2019, Jan Gorecki wrote: > Thank you Luke for prompt reply. > Is it possible then to request a new function to R C API "message" > that would equivalent to

I found that also; fixed in r79386 in the trunk. Will port to R-patched shortly. Best, luke On Thu, 29 Oct 2020, Martin Morgan wrote: > This > > Index: src/main/altrep.c > =================================================================== > --- src/main/altrep.c (revision 79385) > +++ src/main/altrep.c (working copy) > @@ -275,10 +275,11 @@ > SEXP psym =

On Fri, 1 Nov 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. Your definition can allocate because STING_ELT can allocate. getAttrib can GC in general. Currently it would not GC or allocate in this case, but this could change. You can't assume thread-safety for calls into the R

On Mon, 6 Apr 2020, Abby Spurdle wrote: >> (1) Create a top-level help page with a title like "Date and Time >> Classes" to give a brief but general overview. This would mean the >> existing DateTimeClasses would need a new title. > > I wanted to modify my first suggestion. > Perhaps a better idea would be to reference an external document > giving an

On Thu, 26 Jul 2018, G?bor Cs?rdi wrote: > On Thu, Jul 26, 2018 at 1:43 PM <luke-tierney at uiowa.edu> wrote: >> >> 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

This has nothing to do with printing or dispatch per se. It is the result of an internal register (R_ReturnedValue) being protected. It gets rewritten whenever there is a jump, e.g. by an explicit return call. So a simplified example is new_foo <- function() { e <- new.env() reg.finalizer(e, function(e) message("Finalizer called")) e } bar <- function(x)

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,

On Thu, 22 Jan 2015, Michael Lawrence wrote: > 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 >

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

Dear R-devel, Some time ago I started a thread that boiled down to clean-up actions after non-local exits in R, see below. I wonder if there has been any progress on this? R-ext 2.6.1 doesn't say much on the subject. How, for example, do people deal with a situation where their C (C++) function opens a file and then receives a signal or longjump-s on error(), how do they make sure the

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

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 Mon, 7 Oct 2019, Lionel Henry wrote: > > >> On 7 Oct 2019, at 17:04, Tierney, Luke <luke-tierney at uiowa.edu> wrote: >> >> Think about what happens if an >> argument in a pipe stage contains a pipe. (Not completely >> unreasonable, e.g. for a left_join). > > It should work exactly as it does in a local environment. > > ``` > `%foo%`

Thanks - I'll find another way to send messages to the main thread for printing. -Winston On Tue, Nov 21, 2017 at 12:42 PM, <luke-tierney at uiowa.edu> wrote: > On Tue, 21 Nov 2017, Winston Chang wrote: > >> Is it safe to call Rprintf and REprintf from a background thread? I'm >> working on a package that makes calls to fprintf(stderr, ...) on a >>

For now you can use R_altrep_inherits(x, R_compact_intseq_class) The variable R_compact_intseq_class should currently be visible to packages on all platforms, though that may change if we eventually provide a string-based lookup mechanism, e.g. somehting like R_find_altrep_class("compact_intseq", "base") Best, luke On Tue, 4 Jun 2019, Mark Klik wrote: > Hi Gabriel,

Ah, I see it now: The remapping of free() to Rm_free() and calloc() to Rm_calloc() happens in memory.c, but not in tcltk.c; the macro Calloc in R_ext/RS.h maps to a call to R_chk_alloc which is defined in memory.h; RS.h is included in tcltk.c, so tcltk.c winds up calling Rm_calloc() via Calloc(), but then the NON-remapped free(), and the walls come tumbling down. If the "#if