similar to: [R-pkgs] Introducing pedgene 1.2 on CRAN

Dear useRs: We would like to introduce the "pedgene" package, version 1.2, available now on CRAN, with a brief manual available as a vignette: http://cran.r-project.org/web/packages/pedgene/index.html The pedgene package performs gene-level kernel and burden association tests with disease status and continuous response for pedigree data, as described in our recent paper: Schaid, D.

Dear useRs, Please find the new package ibdreg version 0.1.0 on CRAN. The package contains a method for analysis of genetic linkage with covariates by regression methods that use identity by descent (IBD) sharing probabilities for relative pairs. The methods account for correlations of IBD statistics for relative pairs within the same pedigree. The reference is: Schaid DJ, Sinnwell JP,

Dear useRs, Please find the new package ibdreg version 0.1.0 on CRAN. The package contains a method for analysis of genetic linkage with covariates by regression methods that use identity by descent (IBD) sharing probabilities for relative pairs. The methods account for correlations of IBD statistics for relative pairs within the same pedigree. The reference is: Schaid DJ, Sinnwell JP,

haplo.stats, version 1.5.2, is now available on CRAN. Below I provide the description and link to our software page where you can also find the updated user manual. The most notable updates for this version were to make the haplo.glm fitted object work more like the glm object; other changes are listed in the NEWS file entries pasted below. DESCRIPTION: haplo.stats: Statistical Analysis of

haplo.stats, version 1.5.2, is now available on CRAN. Below I provide the description and link to our software page where you can also find the updated user manual. The most notable updates for this version were to make the haplo.glm fitted object work more like the glm object; other changes are listed in the NEWS file entries pasted below. DESCRIPTION: haplo.stats: Statistical Analysis of

We have R 2.2.1 installed on a Linux cluster that seems to have problems loading either of our shared object libraries for packages. This seems to be happening on both local and global versions of packages that we install. However, we have only noticed this problem in the past 3 months on this R installation, whereas some users had success before then. It could be that something on our system

The enlosed patch for IndVarSimplify.cpp works even when the pointer increment is deeply nested wrt pointer initialization, but note that it needs to have loop structures preserved, as in the following: int A[3000000], B[20000], C[100], Z; volatile int I, J, K; int main() { int i, j, k, *a, *b, *c; for ( a = &A[0], i = 0; i != 300; i++ ) { I++;

I am on Solaris 7, using R_1.7.1 developing packages for both Splus and R. We have a working R-package for haplo.score and now converting to haplo.stats. R CMD INSTALL -l /people/biostat3/sinnwell/Rdir/library haplo.stats_1.1.0.tar.gz works like a charm-- as comparable to our working version of haplo.score. But problems are when I'm loading the library within R. Within my package I have

Re-sending this from 10/7. Please help! I'm really clueless how to fix this: System: Solaris 7, Software: R_1.7.1 for unix > R CMD INSTALL -l /Rdir/library haplo.stats_1.1.0.tar.gz -works like a charm-- no syntax errors, etc But problems are when I'm loading the library within R. > library(haplo.stats, lib.loc="/people/biostat3/sinnwell/Rdir/library") > Error

I now understand that IndVarSimplify.cpp is capable of reproducing array references when the pointer initialization from the array address is found inside the immediately enclosing loop, such that in the following code: int A[20000], B[100], Z; int main() { int i, j, *a, *b; for ( a = &A[0], i = 0; i != 200; i++ ) for ( b = &B[0], j = 0; j != 100; j++

On Thu, 28 Jul 2005, Naftali Schwartz wrote: > I now understand that IndVarSimplify.cpp is capable of reproducing array > references when the pointer initialization from the array address is found > inside the immediately enclosing loop, such that in the following code: Ok. > int A[20000], B[100], Z; > int main() > { > int i, j, *a, *b; > for ( a =

I am new to LLVM and couldn't find any llvm-user list, so I am posting my user question here, sorry. I am trying to create a simple "puts" call accepting the static string, with the code below. The last line (CallInst::Create) fails with an assert: "Calling a function with a bad signature!" Because the type of function is void(u8*) and the argument supplied is:

On Apr 29, 2008, at 1:27 AM, Gabor Greif wrote: > Hi all, > > I have reported more than enough about the space savings achieved > and the associated costs, here comes the current patch for review. > > Since this one is substantially smaller than the previous one, I did > not cut it in pieces. The front part is about headers and the rest > the .cpp and other files. Hi

Hi, >>> I see. Is there a quick answer to the questions why you need inbounds >>> GEPs in that case? Can't you just use non-inbounds GEPs if you know you >>> might not have a valid base ptr and "optimize" it to inbounds once that >>> is proven? >> >> You mean on the Rust side? We emit GEPi for field accesses and array indexing.

Hi Johannes, > Now that reasoning works from a conceptual standpoint only for > non-inbounds GEPs, I think. From a practical standpoint my above > description will probably make sure everything works out just fine (see > also my rephrased answer down below!). I say this because I think the > following lang-ref passage makes sure everything, not only memory > accesses, involving

Morten, I've applied these patches. Thanks for the updates! Reid. On Mon, 2004-11-15 at 01:26, Morten Ofstad wrote: > Hi, > > when I updated the sources today there were several small problems that > stopped the windows version from compiling, here are the patches > > m. > > > ______________________________________________________________________ > Index:

I am confused by this bit of code in instcombine: 09789 if (GetElementPtrInst *GEPI = dyn_cast<GetElementPtrInst>(Op)) { 09790 const Value *GEPI0 = GEPI->getOperand(0); 09791 // TODO: Consider a target hook for valid address spaces for this xform. 09792 if (isa<ConstantPointerNull>(GEPI0) && 09793

> On Dec 8, 2014, at 5:12 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > > Partially answering my own question, in general these are not > equivalent because LLVM allows for pointers in different address > spaces to have different sizes. However, are they equivalent if > pointers in addrspace(1) have the same size as pointers in > addrspace(0)? > >

Hi Johannes, > From the Lang-Ref statement > > "With the inbounds keyword, the result value of the GEP is undefined > if the address is outside the actual underlying allocated object and > not the address one-past-the-end." > > I'd argue that the actual offset value (here 0) is irrelevant. The GEP > value is undefined if inbounds is present and the

Hi, Is there any standard pass or something that can fuse chained GEPIs? I.e. turning b = getelementptr a, 10, 1 c = getelementptr b, 0, 3 d = getelementptr c, 0, 5 into: d = getelementptr a, 10, 1, 3, 5 In our case this would greatly simplify some analysis passes, at the moment we have to trace back a gepi-chain and extract all the indices manually (the original object is available