similar to: How to write the same things as `opt` command in C++ API

Hi, I recently discovered this buglet in lattice: If lattice is _not_ attached, I get > lattice::dotplot(~1:10) Error in eval(expr, envir, enclos) : could not find function "bwplot" This happens because of this: > lattice:::dotplot.formula function (x, data = NULL, panel = "panel.dotplot", ...) { ocall <- ccall <- match.call() ccall$data <- data

Hi, The 2 man pages give inconsistent description of class(): Found in ?class: If the object does not have a class attribute, it has an implicit class, ?"matrix"?, ?"array"? or the result of ?mode(x)? (except that integer vectors have implicit class ?"integer"?). Found in ?UseMethod: Matrices and arrays have class ?"matrix"?

> You dropped some context... > A daemon program wouldn't be readonly. An infinite loop can be. Right. To prevent miscommunication, here is a quick analysis of a problematic (IMO) example: We start with ``` define void @infloop(i1 %c) { entry: br i1 %c, label %l, label %e l: br label %l e: ret void } define void @main_func() { entry: call void @infloop(i1 1) ret

The survival package, like many others, has several helper functions that are not declared in the namespace, since their only use is to be called by other "main" functions of the package.? This works well since the functions in the survival namespace can see them --- without ::: arguments --- and others don't. Until a situation I ran into this week, for which I solicit comments

On Sat, Jun 27, 2015 at 2:46 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > In C, dunno, but in LLVM, it means they aren't readonly :) In that case, -functionattrs needs to be fixed: define void @infloop() { entry: br label %l l: br label %l } == opt -functionattrs ==> ; Function Attrs: readnone define void @infloop() #0 { entry: br label %l l:

Hi all, I have a C function, say Cfun, that calls Lapack's DGEMM routine and I need to create a shared library to use Cfun inside R. The C file is the following #include<stdio.h> #include<R.h> #include<R_ext/Lapack.h> void Cfun(double *res, double *X, int *n, int *q) { char *ptr_TRANSA, TRANSA='T', *ptr_TRANSB, TRANSB='N'; ptr_TRANSA=&TRANSA;

Hey all, Below is the proposed format for the dump of the ThinLTO module summary in the llvm-dis utility: > ../build/bin/llvm-dis t.o && cat t.o.ll ; ModuleID = '2.o' source_filename = "2.ll" target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128" target triple = "x86_64-unknown-linux-gnu" @X = constant i32 42, section "foo", align

I have the following procedure which worked just fine for in R 2.2.0. Recently I upgraded to 2.6.1 and now get an error: > ScatterOutlier(pass_500_506[1:1000,6:12], marginal_500_506[,6:12]) Error in eval(expr, envir, enclos) : object "out" not found Note that I use the same workspace (and hence data) as in 2.2.0. When I make sure that the object "out" exists at

The code for ccall looks right. Sounds like you have a very small range of instructions where an uninitialized value appear. You could try debugging at asm level. Shadow for b should be passed at offset 0 in __msan_param_tls. MSan could propagate shadow through arithmetic and even some logic operations (like select). It could be that b is clean on function entry, but then something uninitialized

As you may not be surprised to hear, no sooner did I post the previous message than I realized I had a really dumb mistake. I've now gotten a bit farther but am still stuck. New code: graph <- function (x, data, groups, xlab) { pg <- function(x, y, group.number, ...) fnord body(pg) <- substitute({ panel.xyplot(x, y, ..., group.number=group.number) panel.text(2,

Looks like when you materialize the stores, you should check the size of the the store and emit an appropriate amount of stores to the origin shadow (or just a memset intrinsic?). On Wed, Feb 5, 2014 at 2:13 PM, Keno Fischer <kfischer at college.harvard.edu>wrote: > The @entry stuff is just a gdb artifact. I've been tracking this back a > little further, and it seems there's

How is ccall() implemented? If it manually sets up a stack frame, then it also needs to store argument shadow values in paramtls. I don't think there is an overflow, unless you have a _lot_ of arguments in a function call. On Sun, Feb 2, 2014 at 9:26 AM, Keno Fischer <kfischer at college.harvard.edu> wrote: > Also, I was looking at the instrumented LLVM code and I noticed that the

Yes, it would be great to get that fixed. On Wed, Feb 5, 2014 at 4:09 PM, Evgeniy Stepanov <eugeni.stepanov at gmail.com>wrote: > On Thu, Feb 6, 2014 at 12:21 AM, Keno Fischer > <kfischer at college.harvard.edu> wrote: > > Looks like when you materialize the stores, you should check the size of > the > > the store and emit an appropriate amount of stores to the

On Fri, Jun 2, 2017 at 12:18 PM, Peter Collingbourne via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Why do we need a custom dumping format for the summary? Since we already > need the YAML format anyway, wouldn't it be better to extend that to cover > the entire summary? > IMO it is useful/convenient to be able to see the summary in the llvm-dis output. Teresa >

An embedded and charset-unspecified text was scrubbed... Name: inte tillg?nglig URL: <https://stat.ethz.ch/pipermail/r-help/attachments/20110811/f20d8760/attachment.pl>

This is a seemingly simple problem - hopefully someone can help. Problem: we have two integers. We want (1) all the common factors, and (2) all the possible products of these factors. We know how to get (1), but can't figure out a general way to get (2). Example: 40 and 80 have these factors: c(1,2,2,2,5) and c(1,2,2,2,2,5). We can use match() to get the common factors c(1,2,2,2,5). What

I am trying to use the function "nlm" to find the mle. I want to use a generic function for the likelihood which would require me to use both the parameters and the data as arguments. But nlm requires the function to have only the parameters as arguments for this function (see example below). > testfun <- function(x,y) sum((x-y)^2) # x - parameters, y - data >

Mark, that's actually a fair statement, although your extra operator doesn't cause construction at parse time. You still call paste0(), but just add an extra layer on top of it. I also doubt that even in gigantic loops the benefit is going to be significant. Take following example: atestfun <- function(x){ y <- paste0("a very long", "string for

> 2. change cfun[[1]] <- quote(cord.work) to cfun[[1]] <- > quote(survival:::cord.work). You say this will mess up your test bed. > That suggests that your test bed is broken. This is a perfectly legal > and valid solution. Valid in a package, but forces code to call a loaded library version of a function rather than (say) a 'source'd user-space version that is under

Hi All, I have some questions regarding the R C API. Let's assume I have a function which is defined as follows: R file: myfunc <- function(a, b, ...) .External(Cfun, a, b, ...) C file: SEXP Cfun(SEXP args) { args = CDR(args); SEXP a = CAR(args); args = CDR(args); SEXP b = CAR(args); args = CDR(args); /* continue to do something with remaining arguments in "..."