similar to: Fwd: [Rd] Warning: you may need to use R-patched with recent R distros

Two things have emerged in testing on x86_64 Fedora 14 which mean that a recent R-patched is probably needed. 1) That OS uses zlib 1.2.5: that claims to be binary-compatible with zlib 1.2.3 but is not, as we found (painfully) on Windows. The remedy was to remap _all_ the symbols in R's own copy of zlib (not just those zlib arranged to remap). The symptoms were crashes using packages XML

Dear All, I am having trouble getting an R package to build and install correctly under Windows. In this package, which builds and checks OK under Linux, I use zlib (among other functions, gzprintf). As mentioned by Prof. Ripley a while back, the file "CHANGES" under src/gnuwin32 says explains that to, to use zlib, one has to set $(ZLIB_LIBS) in PKG_LIBS. I have a Makefile.win with

On 4/4/23 04:27, Michael Milton wrote: > Hi Tomas, > > Thanks for this explanation. As you can probably tell I'm not much of > a C person, so I didn't realise this change would be invisible to C > users. I suppose R's stability contract only applies to C, and > therefore changes that break other languages such as Rust are out of > scope. You are right that this

On 4/3/23 15:50, Michael Milton wrote: > Okay, but I'm afraid this will only mean something to Rust users. The > reason being that we encountered this issue in extendr: a Rust > extension library for R. The specific compiler errors we encounter > happen because bindgen (the Rust code generation library) read the > changed R header files, and generated a new type definition

Hi Tomas, Thanks for this explanation. As you can probably tell I'm not much of a C person, so I didn't realise this change would be invisible to C users. I suppose R's stability contract only applies to C, and therefore changes that break other languages such as Rust are out of scope. You are right that this error is confused by bindgen's inability to handle anonymous types, but

Hello, I am trying to call the BLAS Level1 function zdotc from R via a .C call like this: #include "R.h" #include "R_ext/BLAS.h" void testzdotc() { Rcomplex zx[3], zy[3], ret_val; zx[0].r = 1.0; zx[0].i = 0.0; zx[1].r = 2.0; zx[0].i = 0.0; zx[2].r = 3.0; zx[0].i = 0.0; zy[0].r = 1.0; zy[0].i = 0.0; zy[1].r = 2.0; zy[0].i = 0.0; zy[2].r = 3.0;

o `Rcomplex' is preferred to `complex' (a future reserved word in C) for R complex objects passed to C. I'm a bit confused here. Is "complex" or "Rcomplex" the future reserved word in C (I thought "complex" already was, but I'm not a C programmer) and is this because R storage modes should or should not have names corresponding to C reserved

Dear Oscar,   Thanks for your help.It's so nice of you to explain this package to me.   Best Regards,   James LAN 发件人： Oscar Rueda [via R] <ml-node+s789695n4431468h14@n4.nabble.com> 收件人： monkeylan <lanjinchi@yahoo.com.cn> 发送日期： 2012年2月29日, 星期三, 下午 9:21 主题: Re: Bayesian Hidden Markov Models Dear James, The distances are normalized between zero and 1, so in your case all of

Full_Name: Christian Marquardt Version: 2.2.1 OS: Linux Submission from: (NULL) (84.167.229.240) Hello, I believe this is a bug in the configuration / installation: When configuring R-2.2.1 using the Intel v9 Fortran compiler as default Fortran compiler and g++ as C++ compiler on a Suse 9.3 Linux, the configuration script finds that the C and Fortran idea of double comples disagree. I have

Function factor() in the current development version (2009-05-22) guarantees that levels are different character strings. However, they may represent the same decimal number. The following example is derived from a posting by Stavros Macrakis in thread "Match .3 in a sequence" in March nums <- 0.3 + 2e-16 * c(-2,-1,1,2) f <- factor(nums) levels(f) # [1]

Full_Name: Peter Fortini Version: 2.0.1 OS: Windows 2000 Submission from: (NULL) (65.246.187.164) When the imaginary part of the argument is very large, the complex tangent function returns 0+NaNi. For example, tan(1+1000i)=0+NaNi; it should be 0+1i Easy to fix in complex.c, as the original NaN came from division of sinh and cosh that had reached machine infinity. static void z_tan(Rcomplex

On 4/3/23 14:07, Michael Milton wrote: > Hi all, > > There seems to have been a breaking change in the R trunk caused by a fix > to bug 18430 <https://bugs.r-project.org/show_bug.cgi?id=18430> that > relates to the layout of the Rcomplex typedef. Previously it was a struct, > but now it's a union by default >

Hi all, There seems to have been a breaking change in the R trunk caused by a fix to bug 18430 <https://bugs.r-project.org/show_bug.cgi?id=18430> that relates to the layout of the Rcomplex typedef. Previously it was a struct, but now it's a union by default

If you set the "digits17" control option in deparse, you get a lot of unnecessary space in the representation of complex numbers. > deparse(0 + 0i) [1] "0+0i" > deparse(0 + 0i, control = "digits17") [1] "0 + 0i" As far as I can tell, the logic for this comes from this piece of /src/main/deparse.c: if (TYPEOF(vector) == CPLXSXP

Hello, All: What references exist on how to link to C? I'm familiar with sections 5.2 and 5.6 of the "Writing R Extension" manual plus chapter 6 of Venables and Ripley (2000) S Programming (Springer). From these, I get the following: R storage mode C type logical int * integer int * double double * complex Rcomplex *

All in libguestfs >= 1.23.19. - The location of the javadoc has moved from: /usr/share/javadoc/libguestfs-java-$version to: /usr/share/javadoc/libguestfs. - Compressed cpio images are used, if possible. You will see two *.gz files appearing in appliance/supermin.d during the build and copied to /usr/lib/guestfs/supermin.d: $ ls -lh appliance/supermin.d/ total 1.3M -rw-rw-r--. 1 rjones

The build system rolled up R-4.3.0.tar.gz (codename "Already Tomorrow") this morning. This is a major update, containing many new features and bug fixes. The list below details the changes in this release. You can get the source code from https://cran.r-project.org/src/base/R-4/R-4.3.0.tar.gz or wait for it to be mirrored at a CRAN site nearer to you. Binaries for various

The build system rolled up R-4.3.0.tar.gz (codename "Already Tomorrow") this morning. This is a major update, containing many new features and bug fixes. The list below details the changes in this release. You can get the source code from https://cran.r-project.org/src/base/R-4/R-4.3.0.tar.gz or wait for it to be mirrored at a CRAN site nearer to you. Binaries for various

Thank you for the patch. To clarify: this is not a bug. ?.C says The mapping of the types of R arguments to C or Fortran arguments in '.C' or '.Fortran' is R C Fortran integer int * integer numeric double * double precision - or - float * real complex Rcomplex * double complex

Linux users are used to all compilers using the same linkage conventions (those of pcc) whereas users of other platforms are used to the idea that code from different compilers cannot in general be mixed. This is no longer true for gfortran on AMD64. Given a double complex function like double complex function zdotc(n,zx,incx,zy,incy) gfortran returns the result in a 128-bit XMM SSE