similar to: memory.profile() messes up the vector heap on Alpha/Linux?

I am filing this as a bug report so it doesn't get lost. Martyn -----FW: <XFMail.000616094624.plummer@iarc.fr>----- Date: Fri, 16 Jun 2000 09:46:24 +0200 (CEST) Sender: owner-r-devel@stat.math.ethz.ch From: Martyn Plummer <plummer@iarc.fr> To: Naoki Takebayashi <ntakebay@bio.indiana.edu> Subject: RE: [Rd] [PATCH] ./configure fails to recognize alphapca56 (R-1. Cc:

°_§É§¿§¿ ----- Original Message ----- From: <r-help-request at stat.math.ethz.ch> To: <r-help at stat.math.ethz.ch> Sent: Sunday, December 08, 2002 7:00 PM Subject: R-help digest, Vol 1 #10 - 6 msgs > Send R-help mailing list submissions to > r-help at stat.math.ethz.ch > > To subscribe or unsubscribe via the World Wide Web, visit >

I think I reported this bug in the past. At that time, I was told that it is a bug of autoconf. ./configure does not recognize Linux on DEC Alpha 21164PC (a cheap version of Alpha EV56), so all the compilation flags were set incorrectly. I don't know the right way to fix it (I don't know how autoconf works yet ...), but the following patch fixes the problem. Thank you, Naoki Naoki

Hello, I was trying to compile R-base-0.64.1 on Linux/Alpha (RedHat 6.0). It compiled but it couldn't pass the make check (choked with tests/Examples/modreg-Ex.R). I used gdb, and it turned out that the src/library/modreg/src/sinerp.f was the problem. else if(j.eq.nk)then c1 = 0d0 c2 = 0d0 c3 = 0d0 endif > p1ip(1,j) = 0d0-

Full_Name: Naoki Takebayashi Version: 0.65.1 OS: Linux/Alpha Submission from: (NULL) (129.79.224.171) When I was reading a file with read.table("junk.data"), it seg-faulted. I found out that it seg-faulted when the last line of data file didn't have the newline char. For example, file like this: 23 3 31 2 24 1<EOF> Here is a fix. --- R-0.65.1/src/main/scan.c.orig

Full_Name: Naoki Takebayashi Version: 1.2.2 OS: Linux, RedHat 7.0/alpha Submission from: (NULL) (152.3.12.123) With RedHat 7.0/alpha (gcc 2.96-69), I encountered following error: gcc -I. -I../../src/include -I../../src/include -I/usr/local/include -DHAVE_CONFIG_H -mieee -O2 -mieee -c datetime.c -o datetime.o datetime.c: In function `do_systime': datetime.c:306: parse error before `ans'

I was trying to build llvm + clang with cmake cache PGO.cmake and ninja stage2. I used the 4.0.0 final tag vfrom svn. This seems to work for me. I added libcxx, libcxxabi, llld etc. And now I get the following cmake error. -- Performing Test LIBCXX_SUPPORTS_STD_EQ_CXX11_FLAG -- Performing Test LIBCXX_SUPPORTS_STD_EQ_CXX11_FLAG - Failed CMake Error at projects/libcxx/CMakeLists.txt:396

Assumes hypervisor interface headers have been sync-ed after the hypervisor side patch was applied. As usual, written and tested on 2.6.27.3 and made apply to the 2.6.18 tree without further testing. Signed-off-by: Jan Beulich <jbeulich@novell.com> Index: head-2008-10-24/arch/i386/mm/highmem-xen.c =================================================================== ---

> Subject: Re: [Rd] options(keep.source = TRUE) -- also for "library(.)" ? > From: Peter Dalgaard BSA <p.dalgaard@biostat.ku.dk> > Date: 27 Apr 2000 14:37:01 +0200 > > Martin Maechler <maechler@stat.math.ethz.ch> writes: > > > Can we [those of us who know how sys.source() works...] > > think of changing this? As it was possible for the base

================================================= This is an automated summary of the status of the R-bugs repository. Note that this may be neither complete nor perfectly correct at any given instance: Not all bugs are reported, and some reported bugs may have been fixed, but the repository not yet updated. Some bug fixes are difficult to verify because they pertain to specific hardware or

On Tue, Mar 12, 2019 at 03:02:54PM -0700, James Bottomley wrote: > I'm sure there must be workarounds elsewhere in the other arch code > otherwise things like this, which appear all over drivers/, wouldn't > work: > > drivers/scsi/isci/request.c:1430 > > kaddr = kmap_atomic(page); > memcpy(kaddr + sg->offset, src_addr, copy_len); > kunmap_atomic(kaddr);

Full_Name: Naoki Takebayashi Version: 0.65.0+R-release.diff (Oct 6, 1999) OS: Linux/Alpha Submission from: (NULL) (129.79.224.171) This will fix the "problem 2 (crash in fft)" in Bug ID #277 On Linux/Alpha, make check failed because R could not handle the following example in base-Ex.R ##___ Examples ___: # The Old Faithful geyser data data(faithful) : : ## Missing values: x <-

Has anyone succeeded in compiling R-1.1.0 on a Digital (Compaq) Alpha running OSF4.0F (or E)? Everything seems to compile OK (except the frequent "Warning: Unresolved:" at link time - this threw me off the scent for a while!), but then at run time I get: Fatal error: The X11 shared library could not be loaded. The error was dlopen: cannot load

Is it possible to see the source code of the open-sourced SVML? The diff file does not include the library. I searched the Internet but I could not find. Regards, Naoki Shibata On 2016/07/15 13:55, Tian, Xinmin wrote: > Naoki, > > Intel is planning open-source SVML library (most of them if it not 100%), 6 functions of SVML are open sourced for GCC and LLVM already. But, Intel SVML

Hi everyone, I think that everyone is on the same page. We'll put together a patch for review. One remaining question: There seem two potential homes for this library: parallel_libs and compiler-rt. Opinions on where the vectorized math functions should live? My inclination is to target it for the new parallel_libs project, in part because I feel like compiler-rt has too many things grouped

I should keep quiet and leave well enough alone, but playing devil's advocate for a moment - I see you didn't bundle this with compiler-rt, which I guess is good? In the end what was the reasoning for that? Do you see this being sufficiently independent and running a different development track that it made sense? 1) Why rename C files to C++ (consistency?) 2) It seems your

Hello. Thanks to the help from Prof. Ripley, I can now run R under my Solaris 2.6 machine! I should have include the correct library path in LD_LIBRARY_PATH variable. However, I still get the following problem. I configured the R system with --with-tcltk option. In fact, I ran the following: /configure --prefix=/opt/local --with-f77 --with-tcltk --with-tcl-config=/opt/local/lib/tclConfig.sh

Hi, Xenmon does not work correctlly after xentrace changes in cs 17000. Attached patch fixes this problem. This patch modifies access to trace buffer same as tools/xentrace. Signed-off-by: Naoki Nishiguchi <nisiguti@jp.fujitsu.com> Regards, Naoki Nishiguchi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com

Sorry to be such a nuisance but after asking for help with compiling R-1.1.0 on an Intel-based machine I now have another problem on the Alpha DS-10 server which my students use. Compilation and instalation proceed perfectly, but when I invoke R I get: [etdx01:bin]$ ./R Fatal error: The X11 shared library could not be loaded. The error was /home/etptupaf/R/lib/R/bin/R_X11.so: undefined

On Tue, Mar 12, 2019 at 10:59:09AM +0800, Jason Wang wrote: > > On 2019/3/12 ??2:14, David Miller wrote: > > From: "Michael S. Tsirkin" <mst at redhat.com> > > Date: Mon, 11 Mar 2019 09:59:28 -0400 > > > > > On Mon, Mar 11, 2019 at 03:13:17PM +0800, Jason Wang wrote: > > > > On 2019/3/8 ??10:12, Christoph Hellwig wrote: > > >