similar to: Strict-prototypes definitions in R includes

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 2.1.0/src/include from 2005/04/18 download Naming inconsistent for guards as well but that's pedantic. Simple convention: file <foo.h> #ifndef R_FOO_H file <R_ext/bar.h> #ifndef R_EXT_BAR_H Missing guards: <IOStuff.h> <Internal.h> <Parse.h> <R_ext/GraphicsBase.h> <R_ext/GraphicsDevice.h> <R_ext/GraphicsEngine.h>

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

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

I noticed some undocumented and inconsistent behavior in device_Raster when a plot is produced with reflected axes such as: image(volcano, xlim = c(1,0), useRaster = TRUE) image(volcano, ylim = c(1,0), useRaster = TRUE) The `pdf` device will perform horizontal and vertical reflections, while `quartz` will ignore the transformations when plotting to the screen, but when plotting to a

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 int intptr_t; # define

> On Jan 1, 2017, at 5:12 PM, Laurent Gautier <lgautier at gmail.com> wrote: > > > > 2017-01-01 8:28 GMT-05:00 Prof Brian Ripley <ripley at 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

hi everyone is lxc driver missing from libvirt by omission or by an oversight, would you know? many thaks, L.

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

Thank you for the explanation, Ben! I realized I didn’t give enough context for my question: As you noted, the slow/fast unwinder can only do its work if there is enough (runtime) information. Otherwise stack printing usually does exactly what you suggested: printing the one frame corresponding to the recent pc. When I asked if “platforms are required to at least support one kind of unwinder” I

Hi, Various parts of LLVM seem to assume that the ABI for a varargs function is compatible with the ABI for a non-varargs function, so that code like this: define void @f(i32 %x) { ... } ... call void (...)* bitcast (void (i32)* @f to void (...)*)(i32 42) will work. (I don't think C guarantees that this will work, at least not in the version of the C99 standard I checked.) I'm

Most of the questions asked in the nut-user mailing list seem to me to be either erudite technical discussion of new and exotic UPS units, or n00b questions of the style "I have this old UPS so I installed NUT but it didn't work". NUT is thoroughly documented with man pages and User Manual, but from my own experience it is not easy for Joe N00b to know what a working setup

On Tue, 13 Jun 2017, Charles Lepple wrote: > On Jun 9, 2017, at 10:16 AM, Roger Price wrote: >> To address this, I propose a "NUT configuration for Noobs" which is >> called "Configuration Examples". > I am also curious whether you tried to edit any of the existing NUT > documentation before creating a new document. We chose AsciiDoc in part >

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

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("+"))

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

On Thu, 13 Sep 2007, Jay Foad wrote: > Various parts of LLVM seem to assume that the ABI for a varargs > function is compatible with the ABI for a non-varargs function, so This is due to 'K&R' C function handling. In K&R and ANSI C, you can do stuff like this: void foo(); void bar() { foo(1, 2, 3); } void foo(int a, int b, int c) {} and it needs to work. > (I

I've made some local commits that introduce TABs as indentation, and thus provoke a "make syntax-check" failure. This would have prevented it: >From 4740b66adc5985d9a72a7648aa60c5389ffc31af Mon Sep 17 00:00:00 2001 From: Jim Meyering <meyering at redhat.com> Date: Tue, 11 Aug 2009 09:53:16 +0200 Subject: [PATCH libguestfs] doc: improve emacs snippets * HACKING: Make (setq

I was trying to extend "VectorUtils.h", found all functions are defined as static. The common problem when we include this and only use few function, compiler throw warning for unused functions. i.e. > llvm/include/llvm/Transforms/Utils/VectorUtils.h:102:1: warning: > 'llvm::Intrinsic::ID llvm::getIntrinsicIDForCall(llvm::CallInst*, const llvm::TargetLibraryInfo*)' >

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