similar to: Re: (PR#7005) X11 , plot(...expression(...)): missing parentheses

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

Full_Name: Cyril Humbert Version: 1.5.0 OS: linux Submission from: (NULL) (193.50.159.2) Hitting ^C breaks readline history (when R is stared in an xterm). xterm -e R ^C -> arrow key and history stop working. For example, up-arrow gives "^[[A". ldd ./R.bin [../..] libreadline.so.4.1 => /usr/lib/libreadline.so.4.1 (0x40020000) libncurses.so.5 =>

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

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"

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

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

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

Hello everyone, Hope it is the good place for this (I discuss the question of the right place below). Most of the time, warnings are more than 1000 characters long and thus are truncated. Most of the time, this generates printouts with unbalanced parentheses. Intelligent text editors which do parentheses highlighting get very confused with this. After too many warnings, they give errors, and

Commit-ID: c970d7573aa382c89d3c71b88cd10f4c6a464264 Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=c970d7573aa382c89d3c71b88cd10f4c6a464264 Author: Antonio Ospite <ao2 at ao2.it> AuthorDate: Tue, 16 Oct 2018 18:42:20 +0200 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Fri, 25 Jan 2019 02:57:21 +0000 [klibc] [PATCH] eval: Silence compiler

Commit-ID: e3da328217a1fbfaad2ae617dbc26746adf63f8f Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=e3da328217a1fbfaad2ae617dbc26746adf63f8f Author: Antonio Ospite <ao2 at ao2.it> AuthorDate: Tue, 16 Oct 2018 18:42:20 +0200 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Sat, 28 Mar 2020 21:42:55 +0000 [klibc] dash: eval: Silence compiler

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

http://bugzilla.netfilter.org/show_bug.cgi?id=574 Summary: nf_conntrack_ftp.c ignores RFC 1123 regarding parentheses in FTP passive mode message 227 Product: netfilter/iptables Version: linux-2.6.x Platform: All OS/Version: All Status: NEW Severity: normal Priority: P3 Component:

Dear list, I am importing data consisting of numbers into dataframes. Some of the numbers are flanked by parentheses or square brackets. Thus, they are not recognized as numeric and the corresponding column is of class "factor" which makes it hard/impossible use in plotting functions. Is there a way to remove brackets from numbers in a column/row/dataframe? Kind regards, Stefan --

Is there any way to maintain spaces, slashes, and parentheses in variable names when reading these into R? Of course, read.table converts these to periods. However, I know that it's not strictly illegal to have these characters in variable names as I am able to add them using the "variable editor" portion of the "data editor." I need to batch produce dozens of histograms

For what it's worth: running R CMD check on a package when the outdir has parentheses in the pathname fails with the following error: * checking PDF version of manual ...sh: Syntax error: "(" unexpected WARNING LaTeX errors when creating PDF version. This typically indicates Rd problems. * checking PDF version of manual without hyperrefs or index ...sh: Syntax error: "("

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

Simple Case: 1.int main() 2.{ 3. int i = 0; 4. return 0; 5.} compile command: clang -g a.c In LLVM IR, we have one attribute named "scopeLine" to indicate the left parentheses. But we don't have one attribute to indicate the right parentheses (line 5 in this example). So if we use gdb to debug it: (gdb) b main Breakpoint 1 at 0x100005c8: file a.c, line 3. (gdb) r Breakpoint

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

I''m not sure whether this is a bug or whether I''m simply expecting Ferret queries to work in a way other than they''re intended. I notice that if use a query like: (other_text:"Collaborative tools") AND NOT other_text:podcasts I''ll get correct search results. However, if I put parentheses around the second part, like:

I have implemented this exact behavior in an out of tree LLVM fork I maintain, where one of my users needed this behavior, and it seems to work well. What we have done is extend the definition of DISubprogram to contain a new field "endLine" which holds the line number of the closing brace. A pass late in our backend uses this information to set the DebugLoc of return instructions in our