similar to: 'library' documentation

Hi, Is there any docs on R.dll? Or is it "use the source Luke" time? (The NT 0.63.1) Can anyone give me pointers on where to look? I am trying to wrap it under a GUI. The bdr release has examples, but it seems to be limited in scope. Has anyone compiled R under VC++. I see that the older version has been compiled under VC++ at some point. Is this best place to start to see how to

On Thu, Mar 28, 2013 at 1:46 PM, Anton Korobeynikov <asl at math.spbu.ru> wrote: >> Sounds fine to me. I just wanted some convenient and consistent naming. >> I think it conflicts a bit with the triples (-win32 currently means >> msvc I think), > Right. But this is again a historical (and LLVM-specific) artifact, > because I doubt anyone uses such triplet outside to

> Sounds fine to me. I just wanted some convenient and consistent naming. > I think it conflicts a bit with the triples (-win32 currently means > msvc I think), Right. But this is again a historical (and LLVM-specific) artifact, because I doubt anyone uses such triplet outside to mean msvc compatibility. > but that'll probably be ok ultimately - internal function names are easy to

On Thu, Mar 28, 2013 at 1:49 PM, Eric Christopher <echristo at gmail.com>wrote: > On Thu, Mar 28, 2013 at 1:46 PM, Anton Korobeynikov <asl at math.spbu.ru> > wrote: > >> Sounds fine to me. I just wanted some convenient and consistent naming. > >> I think it conflicts a bit with the triples (-win32 currently means > >> msvc I think), > > Right.

On Thu, Mar 28, 2013 at 1:15 PM, Anton Korobeynikov <asl at math.spbu.ru> wrote: >> How can having an MSVC compatible compiler be to the detriment of clang and >> llvm? No one is trying to break mingw here, merely add support for something > Just to make stuff clear: I just wanted proper naming which will be > non-confusing. Right now we have: > - isTargetWindows()

1) 'par' doesn't seem to be called from 'plot', as it is in S. I was able to get the plot to work with: par(mar=c(5,5,5,5)) plot(a,b) axis(4,labels=F,tck=0.1) mtext("blabla",side=4,line=3,cex=1.5) NOTE: I tried this on the x11() display, which seemed to reproduce the problem you described. 2) ?? I was unable to get either x or y logarithmic axes using

Michael Young <mikado_282 at hotmail.com> writes: > When I configure and build LLVM (on Linux - Ubuntu 12.04) with the > "--enable-shared" option, I get a shared library named "libLLVM-3.2svn.so", > regardless of whether I build from sources pulled from the repository > (even when pulling from "tags/RELEASE_32/final") or from the release tarballs.

On Dec 1, 2008, at 8:53 AM, Matthijs Kooijman wrote: > Hi All, > > when looking through all the existing targets, I see that each of > them defines > <Target>ISelLowering.{cpp,h} files. However, they define a class > called > "<Target>TargetLowering" (though the comments in [at least some of] > those > files stay the define

> ISTM that eliminateCallFramePseudoInstr belongs in > TargerFrameLowering, since it's being used during prolog/epilog > insertion. Moving it there would avoid the code duplication and > possibly other layering problems. > What do you think Go ahead and move. It's s historical artifact why it is inside TRI. -- With best regards, Anton Korobeynikov Faculty of Mathematics

Hi all, While compiling R to RISC-V64 architecture and debugging in R's C source codes, I think I have found a small bug. Can anyone please verify whether it is a real bug? The possible bug lies in the file `R-4.2.2/src/library/stats/src/approx.c` in function `R_approxfun` around line 148: #ifdef DEBUG_approx REprintf("R_approxfun(x,y, nxy = %.0f, .., nout = %.0f, method = %d,

Hi Richard, We've added zero and flush functionality to imageio-daemon. You can download and test the latest build (for el7/fc) from: - http://jenkins.ovirt.org/job/ovirt-imageio_master_build-artifacts-el7-x86_64/200/artifact/exported-artifacts/ - http://jenkins.ovirt.org/job/ovirt-imageio_master_build-artifacts-fc27-x86_64/53/artifact/exported-artifacts/ -

When I configure and build LLVM (on Linux - Ubuntu 12.04) with the "--enable-shared" option, I get a shared library named "libLLVM-3.2svn.so", regardless of whether I build from sources pulled from the repository (even when pulling from "tags/RELEASE_32/final") or from the release tarballs. Is this correct behavior? Even if this odd naming is what is expected, why

> How can having an MSVC compatible compiler be to the detriment of clang and > llvm? No one is trying to break mingw here, merely add support for something Just to make stuff clear: I just wanted proper naming which will be non-confusing. Right now we have: - isTargetWindows() which really means "msvc-compabile" - isTargetWin32() which means "everything on windows", so

2013/3/28 Anton Korobeynikov <asl at math.spbu.ru>: >> How can having an MSVC compatible compiler be to the detriment of clang and >> llvm? No one is trying to break mingw here, merely add support for something > Just to make stuff clear: I just wanted proper naming which will be > non-confusing. Right now we have: > - isTargetWindows() which really means

On 8 May 2017 at 15:39, Vaidotas Zemlys wrote: | Hi, | | Dirk Eddelbuettel advised me to write here. Here is my original letter to him: | | I would like to enquire about package r-cran-rjava on Debian jesse. It seems that if default-jre package is not installed, but openjdk-7-jre is installed, then library(rJava) in R fails. I?ve been bitten by this today and I wonder whether this an issue of

The builtins are for internal compiler use in the context of SjLj exception handling. Any other use, including any direct calls of the builtins in user code, are a bad idea with no guaranteed behaviour. That they're exposed at all is, again, for historical purposes. Don't use them. -Jim On Apr 27, 2011, at 3:45 PM, Akira Hatanaka wrote: > Okay. I understand builtin functions do not

On Feb 27, 2009, at 12:56, Mark Shannon wrote: > Gordon Henriksen wrote: > >> The ultimate endgoal is to support schemes with still-lower >> execution overhead. The next step for LLVM GC would be elimination >> of the reload penalty for using GC intrinsics with a copying >> collector. This, again, requires that the code generator perform >> bookkeeping

On 17 May 2017 at 08:46, Vaidotas Zemlys wrote: | Hi, | | > Le 17 mai 2017 ? 00:42, Dirk Eddelbuettel <edd at debian.org> a ?crit : | > | > | > On 8 May 2017 at 15:39, Vaidotas Zemlys wrote: | > | Hi, | > | | > | Dirk Eddelbuettel advised me to write here. Here is my original letter to him: | > | | > | I would like to enquire about package r-cran-rjava on

Okay. Are you saying that you shouldn't use __builtin functions in general in your program or just __builtin_setjmp/longjmp? Also, are there any warnings issued by either clang or llvm if they are used in your program? On Wed, Apr 27, 2011 at 3:55 PM, Jim Grosbach <grosbach at apple.com> wrote: > The builtins are for internal compiler use in the context of SjLj exception >

On Oct 4, 2011, at 4:56 PM, Talin wrote: > > LLVM isn't actually a virtual machine. It's widely acknoledged that the > > name "LLVM" is a historical artifact which doesn't reliably connote what > > LLVM actually grew to be. LLVM IR is a compiler IR. > > It sounds like you're picking a very specific definition of what a VM is. LLVM certainly