similar to: Sun's make "almost" works

In some contexts, I find the current behavior of rank() very `suboptimal'. We have the argument na.last = {TRUE | FALSE | NA } where the first two cases treating NAs (almost) as if they were == +Inf or == -Inf whereas the 3rd case just drops NAs. For the typical ``Rank Transformation'' that is recommended in EDA in several contexts, I would however want something else, namely keep

In current versions of R, pretty(333) gives an infinite loop (due to a silent integer overflow in src/appl/pretty.c). I've looked at this problem and also at what S-plus does, (no code there to inspect, just experiments), and then I have fixed pretty.c. I think that it now behaves much more reasonably (both than before and than S / S-plus). The only problem: pretty(.) is not

--- bash/Makefile.am | 54 +++++++++++++++--------------------------------------- 1 file changed, 15 insertions(+), 39 deletions(-) diff --git a/bash/Makefile.am b/bash/Makefile.am index 10f0861..780da64 100644 --- a/bash/Makefile.am +++ b/bash/Makefile.am @@ -21,6 +21,10 @@ scripts = \ guestfish \ guestmount \ virt-alignment-scan \ + virt-rescue \ + virt-resize + +symlinks = \

Use CLEANFILES to remove the generated symlinks, and just ignore the errors when copying the scripts in srcdir!=builddir situations. Followup of commit 40ac54829d4e71b1bac76343872a2674a40c7ac0. --- bash/Makefile.am | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/bash/Makefile.am b/bash/Makefile.am index 780da64..ee9c10c 100644 --- a/bash/Makefile.am +++

Here are three patches that fix issues with out-of-tree building and one that uses Ruby's own autoconf stuff for determining how Ruby bindings should be built. Cheers, -Hilko

This just fixes 'make'. 'make check' is still broken. Further patches for that to follow tomorrow. Rich.

--- configure.ac | 2 +- golang/Makefile.am | 2 ++ 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 4e2bc65..9abec95 100644 --- a/configure.ac +++ b/configure.ac @@ -1530,7 +1530,7 @@ AS_IF([test "x$enable_golang" != "xno"],[ AC_CHECK_PROG([GOLANG],[go],[go],[no]) AS_IF([test "x$GOLANG" !=

--- cat/Makefile.am | 6 +++--- df/Makefile.am | 2 +- edit/Makefile.am | 2 +- examples/Makefile.am | 12 ++++++------ fish/Makefile.am | 18 +++++++++--------- fuse/Makefile.am | 2 +- inspector/Makefile.am | 2 +- java/examples/Makefile.am | 6 +++--- ocaml/examples/Makefile.am | 6 +++---

Thank you Bendix, {I hope it's okay if I CC my answer to your private mail to R-devel ..} >>>>> On Wed, 27 Oct 1999 08:55:28 +0200, BXC@novo.dk (Bendix Carstensen) said: >> -----Original Message----- >> From: Martin Maechler [mailto:maechler@stat.math.ethz.ch] >> Sent: 25. oktober 1999 14:58 To:Gregory R. Warnes >> Cc:

MM> I've sent two bug reports that both haven't been forwarded to R-devel MM> and haven't should up at the jitterbug repository. MM> ?? MM> Martin Well, actually only one [the other went to R-core alone] Here it is : From: Martin Maechler <maechler@sophie> To: R-bugs Subject: plot math - segfault and "frac", "^" bug(s).. Date: 8

>>>>> "MM" == Martin Maechler <maechler@stat.math.ethz.ch> writes: MM> This is not a bug in the very strict sense, MM> but for consistency, MM> I feel that MM> abline() MM> should obey par("xpd") setting, even by ...-argument. MM> The following code shows how lines() ``works'' and abline() does not :

>>>>> "MM" == Martin Maechler <maechler@stat.math.ethz.ch> writes: >>>>> "TL" == Thomas Lumley <thomas@biostat.washington.edu> writes: TL> On Thu, 24 Aug 2000, Troels Ring wrote: >>> Dear friends. >>> >>> Is this as expected ? Is alpha and beta too large simply ? >>>

>>>>> "MM" == Martin Maechler <maechler@stat.math.ethz.ch> writes: >>>>> "TL" == Thomas Lumley <thomas@biostat.washington.edu> writes: TL> On Thu, 24 Aug 2000, Troels Ring wrote: >>> Dear friends. >>> >>> Is this as expected ? Is alpha and beta too large simply ? >>>

>>>>> "MM" == Martin Maechler <maechler@stat.math.ethz.ch> writes: >>>>> "david" == david <david@orion-10.cs.byu.edu> writes: david> When I issue the command: if ( c(2.8,3)[1] < pretty david> (c(2.8,3))[1]) print ("problem") david> the result is "problem" prints. I have traced it to bits

>>>>> "FrSa" == SABIDO =?iso-8859-1?Q?MART=CDN?= <SABIDO> writes: FrSa> Hello. I am a student from Spain. We are working on 'R' (a FrSa> programming environment for data analysis and graphics). Our FrSa> teacher has told as to make a job about tests in non complet rank FrSa> linear regresion models (I hope you could understand

Our sys.admin fixed one important (NIS) problem and accidentally simultaneously badly broke part of sendmail's functioning. Unfortunately, this lasted ~ 40 minutes, and somehow sendmail just "thought" it had to resend these messages several times (up to 8 x) that came in during that 40 minutes' period. Accept our (math.ethz.ch)'s apologies... Martin Maechler <maechler

(as the subject says) It makes sense to add (say k) boxplots to a given plot, using the given coordinate system. Currently, the calling sequence boxplot -> boxplot.default() -> bxp() [modeled after S] doesn't allow this, since bxp() explicitly sets up the coordinate system. One way would be to add an "add = TRUE" argument to boxplot(.) and bxp(.) and then additionally

This is something between a question and a bug report. {sometimes one should first ask on R-help before sending to R-bugs....} I wanted to plot (.) a formula with "..." ## Works : e0 <- expression(T(x[1],...x[n])*", "*N[1] == 101) # works ok plot(1, main = e0) ## Now, need substitute, to replace with value of variableThis works nn <- 102 (e1 <-

>>>>> "TL" == Thomas Lumley <thomas at biostat.washington.edu> writes: TL> I'm receiving duplicates of a number of old r-help messages, all with TL> headers having the rly-mx2.maxis.net.my section in the message below. Is TL> this at your end? Do you know about it? Doug Bates has averted me; and I have since stopped these to be propagated

Not many of you will use grid() widely, probably. Also, two months ago, Paul Murrell said on R-help (topic "grid command") PM>> i think the abline() solution is the best for doing what grid() won't. PM>> like you say, grid() is just a simple front-end to abline(). grid() *is* too simple to be of practical use. I propose the following which is of some practical