similar to: hitting ^C breaks readline history (PR#1606)

Is it a way to make plots with vertical lines, like plot(x, y, type="h"), but starting from a different value than y=0. For example, with x=1:3, y=-(1:3), y.orig=-3 : -1 | | y -2 | | | | -3 | | | 1 2 3 x Thanks -- Cyril Humbert -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-help mailing list --

Martin Maechler wrote: > >>>>> "humbertc" == humbertc <humbertc@univ-mlv.fr> > >>>>> on Tue, 22 Jun 2004 13:16:58 +0200 (CEST) writes: > > humbertc> Full_Name: Cyril Humbert > humbertc> Version: 1.9.1 > humbertc> OS: Debian GNU/Linux (i386) > humbertc> Submission from: (NULL) (193.50.159.2) >

>>>>> "humbertc" == humbertc <humbertc@univ-mlv.fr> >>>>> on Tue, 22 Jun 2004 13:16:58 +0200 (CEST) writes: humbertc> Full_Name: Cyril Humbert humbertc> Version: 1.9.1 humbertc> OS: Debian GNU/Linux (i386) humbertc> Submission from: (NULL) (193.50.159.2) humbertc> Hello, humbertc> For the X11 graphic

With the function plot(x, y, type="l") points are not connected when x or y contain a missing value (NA). Is it possible to do the same with the lattice function xyplot() ? For example: library(lattice) x <- c(1, 2, NA, 4, 5) y <- x plot(x, y, type="l") xyplot(y~x, type="l") In the first plot, the point 2 is not connected to the point 4 whereas there are

Several folks have previously written that valgrind notices a memory leak in R's readline code. It looks like it leaks a copy of every input line. % ~/R-svn/r-devel/R/bin/R --debugger=valgrind --debugger-args=--leak-check=full --vanilla ==10725== Memcheck, a memory error detector. ==10725== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al. ==10725== Using LibVEX rev 1658, a

the built version of R (built using shared libraries) doesn't appear to find tcl/tk: Please help. Details: SGI configuration: 7.3.1.3m compilers from SGI uname -aR = IRIX64 mendel 6.5 6.5.16f 04101930 IP35 We built R on an SGI system using the following configure script: # explicitly choose vendor compilers for R rather than GNU # optimise output to support highest level of performance

Hi folks, syslinux-3.11 squashfs2.2-r2 Just join this list. I have built a LFS LiveCD on BLSF 6.1 and burned on CD-RW. On booting following warning popup; ..... VFS : Mounted root (ext2 filesystem readonly) Freeing unused kernel memory : 216K freed Warning unable to open an initial console Kernel panic - not syncing : No init found Trying passing init = option to kernel (It hung here) I have

Should I be worried? The installation seems to go through fine and apparently nothing is broken. The errors I repeatedly get are like this: g++ -no-cpp-precomp -I/Library/Frameworks/R.framework/Resources/include -I/usr/ local/include -DUNIX -DOPTIM -DNONR -fno-common -g -O2 -c unif.cpp -o unif.o g++ -bundle -flat_namespace -undefined suppress -L/usr/local/lib -o rgenoud.so c hange_order.o

I have a question about the function of line feeds/carriage returns in an all linux (R, vi to write scripts) environment. In my scripts I have a few functions, using { or ( to wrap commands on the next line. Usually this is fine, but sometimes R appears confused by line wrappings (more likely of course it is me who is confused). I tried ';' to explictly break the line, but no dice. An

================================================= 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 Mon, Feb 15, 2010 at 03:40:56PM +0300, Dan Carpenter wrote: > This is the results from: > make C=1 CHECK="/path/to/smatch -p=kernel" bzImage modules | tee warns.txt > grep -w overflow warns.txt | uniq -f 3 | tee err-list > > I hacked on the buffer overflow check last weekend and these are the > results. It has way more false positives than the other bug

Dear R-masters, I tried to compile this simpel C-code: //----------------- #include<R.h> int main() { GetRNGstate(); return 0; } //----------------- Compiling: ~> gcc -o a a.c -I/usr/lib/R/include/ -L/usr/lib/R/bin/ -lR ~> ldd a libR.so => /usr/lib/libR.so (0x40018000) libc.so.6 => /lib/libc.so.6 (0x401a8000) libblas.so.2 =>

Prof Brian Ripley wrote: > This is intentional: it aligns the numbers. E.g. > > >options(width=12) > >print(c(1+1i, 1-10i, 1+100i)) > [1] 1+ 1i > [2] 1- 10i > [3] 1+100i > > Neat, eh? > > What made you think this was a bug? Ah ok, I've misunderstood this feature probably perhaps because, at first sight, I found the display looks "strange"

Hy Jan, I'll put a copy on cran today. Thanks. stefano > > Get it from ftp://gifi.stat.ucla.edu in pub. > > This contains the base files plus the recommended packages (except > rpart, > which does not compile yet). > > It is compiled under MacOS X 10.1.2 with the December 2001 version > of > the Developer Tools, and with g77 from fink.sourceforge net.

This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --27464147-733928972-1114633091=:27258 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE I've managed to solve this, but the major problem I had was not R but that= =20 printf was not

These patches first make src/ warning free, and then turn on the strict warning options. 75 0001-build-suppress-an-ignored-write-return-value-warning.patch 38 0002-build-suppress-an-ignored-dup-return-value-warning.patch 27 0003-generator.ml-suppress-signed-unsigned-compare-warnin.patch 48 0004-build-don-t-perform-arithmetic-on-void-pointers.patch 30

================================================= 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

I just upgraded to R 2.7.2 (from 2.7.1) this morning (Ubuntu amd64 platform). Shortly afterwards, I ran into a problem loading the odesolve library, it could not find libRblas.so. I was able to fix this by rebuilding odesolve. Now, KernSmooth gives me the same problem... R> library(KernSmooth) Error in dyn.load(file, DLLpath = DLLpath, ...) : unable to load shared library

================================================= 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

I'm running R Version 2.1.0 (2005-04-18), ISBN 3-900051-07-0 on Machine Model: Power Mac G5 CPU Type: PowerPC 970 (2.2) Number Of CPUs: 2 CPU Speed: 2 GHz L2 Cache (per CPU): 512 KB Memory: 2 GB with software: System Version: Mac OS X 10.3.9 (7W98) Kernel Version: Darwin 7.9.0 Here is what happened when I tried to update the "foreign" package (similar