similar to: R-beta: R62.3 crash

Thomas Lumley writes: > > > I've been trying to get Matt Calder's S compiler to work in R using R > COMPILE and R SHLIB so it will be fairly platform-independent. > > I'm sure someone has claimed in the past that it is possible/easy to > dyn.load() two dynamic libraries and have one call functions in the other. > I can't get it to work (Red Hat

A non-text attachment was scrubbed... Name: not available Type: text Size: 845 bytes Desc: not available Url : https://stat.ethz.ch/pipermail/r-help/attachments/19980924/4819002f/attachment.pl

A non-text attachment was scrubbed... Name: not available Type: text Size: 845 bytes Desc: not available Url : https://stat.ethz.ch/pipermail/r-help/attachments/19980924/4819002f/attachment.pl

Hi, I have recently upgraded hardware and now have a run-time error with R62.3 when I have built it from scratch with EGCS 1.1 (Guido's original binaries run OK). (333MHzK2, 64MBRam, 1.5GBHD, Win95b). Anyone any ideas ? R : Copyright 1998, The R Development Core Team Version 0.62.3 Beta (Sept 8, 1998) R is free software and comes with ABSOLUTELY NO WARRANTY. You are welcome to

In versions of R prior to 3.0, by default .C and .Call would find the requested C function regardless of which shared library it was located in. You could use the PACKAGE argument to restrict the search to a specific library, but doing so was not necessary for it to work. R 3.0 introduced a significant change to that behavior; from the NEWS file: CHANGES IN R 3.0.0: PERFORMANCE

I get an error: Error in dyn.load(file) : unable to load shared library "D:\R_CODA\RW0613\library\eda\libs\eda.dll" with almost all the packages. I tried to use "require" and tried also to copy the dll's to the bin directory and nothing helped. Any ideas ? Thanks for your efforts Troels -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-help

Dear all, I have some difficulty getting R-1.3.0 to run on the alpha, with osf4.0e (Tru64, or whatever they call it... :-) ). configure reports the following configuration: R is now configured for alphaev6-dec-osf4.0e Source directory: . Installation directory: /astro/local C compiler: gcc -mieee -g -O2 C++ compiler: c++ -g -O2 FORTRAN

Dear all, I have some difficulty getting R-1.3.0 to run on the alpha, with osf4.0e (Tru64, or whatever they call it... :-) ). configure reports the following configuration: R is now configured for alphaev6-dec-osf4.0e Source directory: . Installation directory: /astro/local C compiler: gcc -mieee -g -O2 C++ compiler: c++ -g -O2 FORTRAN

I have written a function that uses LSODA from NETLIB to solve initial value problems, given a system of ODEs written as an R function. There are times when it would be convenient to use the code with an ode system written in a compiled language. Certainly, that can be done using .C or .Fortran within an R function, but that seems inefficient (indeed, it does not enormously speed up the

I am trying to make R-1.5.0 from source on a new G4 system with the apple developer tools and X11 installed and with ATLAS. Running ./configure appears to end normally, but running make yields: gcc -no-cpp-precomp -I. -I../../src/include -I../../src/include -I/usr/local/include -DHAVE_CONFIG_H -g -O2 -c Rdynload.c -o Rdynload.o Rdynload.c: In function `R_FindSymbol': Rdynload.c:942:

Hello, I am trying to build R-1.3.1 on hpux10.20 with gcc and HP's fort77. here is my configure: ./configure --prefix=/home/absd00t/local --with-readline --with-gnome=no --with-f77=fort77 I also set CXXFLAGS= -I/usr/include/Motif1.2 -I/usr/include/X11R6 -I/home/absd00t/local/include and LIBS= -L/home/absd00t/local/lib so that readline.h and libs would be found. I have parts of gnome libs so

I'm having trouble compiling the latest version of R (1.7.0) under OS (10.2.5), after running ./configure then make, building fails on the file main/Rdynload.c with the following error message. gcc -I../../src/extra/pcre -no-cpp-precomp -I. -I../../src/include -I../../src/include -I/sw/include -DHAVE_CONFIG_H -g -O2 -c Rdynload.c -o Rdynload.o Rdynload.c: In function

Hi everyone, I'm thinking about breaking up a large package I have to avoid loading some of the more specialised parts when it isn't necessary. The package is dependent on shared libraries. The base one will keep all of the core stuff like constructors etc and the specialised parts will need to access these. It is obviously possible to set the "local" flag to false, however

Hi all, I've noticed some peculiarities in the tools:::funAPI output that complicate its programmatic use a bit. - Is it for remapped symbol names (with Rf_ or the Fortran underscore), or for unmapped names (without Rf_ or the underscore)? I see that the functions marked in WRE are almost all (except Rf_installChar and Rf_installTrChar) unmapped. This makes a lot of sense because some

> Yes, the nightly build is broken in a similar, but different way. See below. > Both seem to be readline related, so Frederick Eaton's patches, which Martin committed yesterday are the likely culprit. I had actually tested them and things seemed to work, but it was on a different machine and not a completely clean build. Indeed a problem. I'm pretty sure that RL_UNSETSTATE()

> Date: Fri, 20 Nov 1998 15:58:07 +0100 > To: r-help at stat.math.ethz.ch > Subject: [R] installing R packages in Windows? > From: 320098218774-0001 at t-online.de (Pablo E. Verde) > > I am a Windows user of R. Could somebody give me a concrete > example of how to install a package in R? I have tried to > follow the Appendix C of "R complements to Modern Applied >

> Date: Fri, 20 Nov 1998 15:58:07 +0100 > To: r-help at stat.math.ethz.ch > Subject: [R] installing R packages in Windows? > From: 320098218774-0001 at t-online.de (Pablo E. Verde) > > I am a Windows user of R. Could somebody give me a concrete > example of how to install a package in R? I have tried to > follow the Appendix C of "R complements to Modern Applied >

I have a use case with tcltk-package where I need to repeatedly call Tcl/Tk functions very quickly. For such purpose, the standard R-interface turned out to be too slow, and better option has been to call package's C-function dotTcl directly from my own C-code. Before R 4.4.0 it was possible to use getNativeSymbolInfo("dotTcl","tcltk")$address (or

Dear R-devel, The latest version of R-devel (05-17) is throwing an error for me when building on OS X (v 10.11.4): making Rembedded.d from Rembedded.c making dynload.d from dynload.c making system.d from system.c making sys-unix.d from sys-unix.c making sys-std.d from sys-std.c making X11.d from X11.c clang -I. -I../../src/include -I../../src/include -I/usr/local/include -DHAVE_CONFIG_H

I have a package that solves systems of ordinary differential equations coded as an R function (odesolve, on CRAN). The function is passed to R code, and c and Fortran code called by it uses lang4() and eval() to evaluate the R function inside a compiled c function to use in a compiled ODE solver. This works quite well, but can be slow. I'd like to be able to supply the name of a compiled