[Rd] compiling packages without Framework and CoreFoundation options on OSX
I've been trying to get R+PostgreSQL+PL/R to work together on a OSX
machine without the Framework and CoreFoundation options and have
noticed some suspicious switches when compiling packages.
I've installed R (on OSX) with the following ./configure:
./configure \
CC="gcc -arch i386" \
CXX="g++ -arch i386" \
OBJC="gcc -arch i386" \
F77="gfortran -arch i386" \
FC="gfortran -arch i386" \
--enable-R-framework=no \
--enable-R-shlib \
--without-blas \
--x-includes=/usr/X11/include \
--x-libraries=/usr/X11/lib
Notice the
--enable-R-framework=no \
--enable-R-shlib \
No flames please.I'm sure I'm breaking lot's of R purist-isms. There's
a bigger picture here than trying to get R and packages to build by
themselves.
When I build packages, using sudo R, for example:
> install.packages(c("rconifers"),
+ lib="/usr/local/lib/R/library",
+ repos="http://cran.r-project.org";,
+ dependencies=TRUE )
the package seems to get built with the "-Wl,-framework -
Wl,CoreFoundation" switches, even when R isn't built with the
framework (and CoreFoundation) options. For example:
gcc -arch i386 -std=gnu99 -dynamiclib -Wl,-headerpad_max_install_names
-undefined dynamic_lookup -single_module -multiply_defined suppress -L/
usr/local/lib -o rconifers.so coeffs.o file_io.o grow.o mortality.o
plot.o rconifers.o sample.o smc_coeffs.o smc_model.o stats.o
swo_coeffs.o swo_model.o thin.o -L/usr/local/lib/R/lib -lR -Wl,-
framework -Wl,CoreFoundation
I would like to build packages without the "-Wl,-framework -
Wl,CoreFoundation" options because I'm going to install it on other OS
(FreeBSD, Linux, whatever)
Does this cause a problem? Will this cause a problem? I'm guessing the
CoreFoundations are an artifact of the XCode compiler. What's with the
-Wl,-framework stuff? Can I make it stop? Will I be okay?
Thanks,
Jeff.
Jeff Hamann, PhD
PO Box 1421
Corvallis, Oregon 97339-1421
541-754-2457
jeff.hamann[at]forestinformatics[dot]com
http://www.forestinformatics.com
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Improved Function Information with Key
Hello,
Pressing the key when typing a function into an R terminal does not
produce the expected output. Currently, R will order all of the available
function inputs into alphabetical order and present them as options, whereas
it should display the inputs in the order they appear in the function.
For example:
> test = function(b,a,c){
print(b)
a*c
}
> test(
a= b= c=
where indicates pressing the Tab key.
It's easy to see that if the function were designed to accept 'b' as a
string, and 'a' and 'c' as numerics that this function would fail if the
user made the assumption that the output is in the correct order, and
input 'a' as a string.
This is a simple example, however I have several functions that I use often
and each has many possible inputs. It would be useful to not have to
remember the order the inputs are in for each function, or have to use
args(function) beforehand. It is also on occasion useful not to have to
explicitly name each input in your function.
Im using Ubuntu Linux 9.04 and a standard install of R 2.9.2 (unfortunately
not the polished R.app available on Macs - which coincidentally do display
function inputs in the correct order).
I welcome any thoughts, disagreements or tips any of you may have,
Thanks in advance,
Lee Kelvin
--
Lee Kelvin
School of Physics & Astronomy
University of St Andrews
North Haugh
St Andrews KY16 9SS
United Kingdom
Phone (+44) [0]1334461668
Email l...@st-andrews.ac.uk
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] how to document stuff most users don't want to see
If help was only displayed in the form of html pages, one could perhaps mimic the javascript trick sometimes found in wikipedia, e.g. "http://en.wikipedia.org/wiki/Mathematical_induction#Example"; (see the "show/hide" toggle at the bottom). I don't see how this could work with plain text or pdf output. Regards, baptiste __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] how to document stuff most users don't want to see
> -Original Message- > From: Patrick Burns [mailto:pbu...@pburns.seanet.com] > Sent: Tuesday, October 06, 2009 12:53 AM > To: spencerg > Cc: William Dunlap; char...@stat.umn.edu; r-devel@r-project.org > Subject: Re: [Rd] how to document stuff most users don't want to see > > I think the problem is more subtle > than Spencer implies. It is good > to have as much documentation as > possible. However, if a help file > is long and complex, then people > get intimidated and don't read it > at all. > > It would be nice to have a feature > so that help files can be displayed > with different levels of detail. Using a link to another help file is an established way of doing this. Help file writers know how to put in links and readers know how use them. Charlie's question was how to describe the debugging output that few people would want to know about. I don't think he wanted to write a narrative vignette that told how to use the debug output to solve problems but he wanted to make the format of the output available. Why not have help(myFunction) say debug: a logical scalar saying whether to enable [debugging output] or not just as help(grep) says pattern: character string containing a [regular expression] (or character string for fixed = TRUE) to be matched or help(title) says quite a bit of mathematical notation is available such as sub- and superscripts, greek letters, fractions, etc: see [plotmath] ? (The [] indicates a link to another Rd file that gives more detail about the matter.) Bill Dunlap Spotfire, TIBCO Software wdunlap tibco.com > A > sophisticated version of this scheme > might even assume different levels of > knowledge of the user so that the least > detailed level might be longer (but > easier) than a more detailed level. > > > > Patrick Burns > patr...@burns-stat.com > +44 (0)20 8525 0696 > http://www.burns-stat.com > (home of "The R Inferno" and "A Guide for the Unwilling S User") > > > spencerg wrote: > > There are many arguments in many functions that are rarely used. I > > prefer to see it all documented in the help pages. If they are not > > documented in the help pages (and sometimes even if they > are), a user > > who wants them can invent other ways to get similar > information with > > much greater effort, and do so for years only to eventually > find a much > > easier way buried in the documentation. Example: I was > frustrated for > > years that "nls" would refuse to produce output if it did > not converge. > > I often used "optim" instead of "nls" for that reason. > However, the > > list returned by "optim" does not have the nice methods > that one can use > > with an "nls" object. Eventually, I found the "warnOnly" option > > documented under "nls.control", which has made "nls" easier > for me to use. > > Spencer Graves > > > > > > William Dunlap wrote: > >> There are several help files in the R sources that > >> describe concepts and not particular R objects. > >> E.g., help(Methods), help(Syntax), and help(regex). > >> They don't have a docType entry and their alias > >> entries do not refer to functions. Perhaps your > >> debugging documentation could go into a similar > >> *.Rd file. > >> > >> Does check balk at such help files in a package? Should it? > >> Should there be a special docType for such help files? > >> > >> Bill Dunlap > >> Spotfire, TIBCO Software > >> wdunlap tibco.com > >> > >>> -Original Message- > >>> From: r-devel-boun...@r-project.org > >>> [mailto:r-devel-boun...@r-project.org] On Behalf Of Charles Geyer > >>> Sent: Monday, October 05, 2009 10:51 AM > >>> To: r-devel@r-project.org > >>> Subject: [Rd] how to document stuff most users don't want to see > >>> > >>> The functions metrop and temper in the mcmc package have > a debug = FALSE > >>> argument that when TRUE adds a lot of debugging > information to the > >>> returned > >>> list. This is absolutely necessary to test the > functions, because one > >>> generally knows nothing about the simulated distribution > except what > >>> what > >>> one learns from MCMC samples. Hence you must expose all > details of the > >>> simulation to have any hope of checking that it is doing > what it is > >>> supposed > >>> to do. However, this information is of interested mostly > (perhaps > >>> solely) > >>> to developers. So I didn't document it in the Rd files for these > >>> functions. > >>> > >>> But it has ocurred to me that people might be interested > in how these > >>> functions > >>> are validated, and I would like to document the debug output > >>> somewhere, but I > >>> don't want to clutter up the documentation that ordinary > users see. > >>> That > >>> suggests a separate help page for debugging. Looking at > "Writing R > >>> Extensions" > >>> it doesn't seem like there is a type of Rd file for this > purpose. I > >>> suppose > >>> it could be added in (fairly long) sections tit
Re: [Rd] Buglet in qbeta?
> "JL" == Josef Leydold > on Wed, 7 Oct 2009 14:48:26 +0200 writes: JL> Hi, JL> I sometimes play around with extreme parameters for distributions and JL> found that qbeta is not always monotone as the following example shows. JL> I don't know whether this is serious enough to submit a bug report (as JL> this example is near to the limitations of floating point arithmetic). well, it's not near enough the limits to *not* warrant a bug report! I "know" (I have saved a collection of ..) about several accuracy problems of pbeta() / qbeta(), most cases indeed "borderline" (at the limits of FP arithmetic) but this one may well be a new one. A bit more succint than the dump of your numbers is a simple graphic p <- (1:100)/100; qp <- qbeta(p, 0.01,5) plot(p,qp, type="o", log = "y") ## or, already suggesting a fix to the bug: plot(p,qp, type="o", log = "xy") which is definitely a bug... though not a terrible one. @ R-core: please leave me a bit of time before touching qbeta.c, as I already have a modified local version of that. Thanks for the report, Josef! -- Martin Maechler, ETH Zurich >> x <- qbeta((0:100)/100,0.01,5) >> x JL> [1] 0.00e+00 1.253990e-201 1.589622e-171 6.462785e-154 2.015085e-141 JL> [6] 9.892240e-132 8.192553e-124 4.056003e-117 2.554424e-111 3.330774e-106 JL> [11] 1.253990e-101 1.728076e-97 1.038529e-93 3.109063e-90 5.141594e-87 JL> [16] 5.098238e-84 3.238117e-81 1.390549e-78 4.58e-76 9.411402e-74 JL> [21] 1.589622e-71 2.090373e-69 2.190596e-67 1.866714e-65 1.316493e-63 JL> [26] 7.803602e-62 3.941205e-60 1.716606e-58 6.517745e-57 2.178181e-55 JL> [31] 6.462785e-54 1.715788e-52 4.104801e-51 8.906113e-50 1.762731e-48 JL> [36] 3.199622e-47 5.352348e-46 8.288322e-45 1.193037e-43 1.602341e-42 JL> [41] 2.015085e-41 2.380564e-40 2.649862e-39 2.787018e-38 2.776910e-37 JL> [46] 2.627517e-36 2.366341e-35 2.032732e-34 1.668853e-33 1.311905e-32 JL> [51] 9.892240e-32 2.220446e-15 2.331468e-15 2.553513e-15 1.110223e-16 JL> [56] 3.330669e-16 9.992007e-16 8.881784e-16 4.440892e-16 7.771561e-16 JL> [61] 1.554312e-15 8.881784e-16 9.992007e-16 2.109424e-15 2.331468e-15 JL> [66] 2.553513e-15 2.553513e-15 1.110223e-16 6.661338e-16 1.221245e-15 JL> [71] 1.443290e-15 2.220446e-16 6.661338e-16 2.664535e-15 1.054712e-14 JL> [76] 4.019007e-14 1.512124e-13 5.589973e-13 2.031153e-12 7.261081e-12 JL> [81] 2.554423e-11 8.847001e-11 3.017724e-10 1.014153e-09 3.359099e-09 JL> [86] 1.096950e-08 3.532966e-08 1.122586e-07 3.520157e-07 1.089674e-06 JL> [91] 3.330818e-06 1.005659e-05 3.50e-05 8.845884e-05 2.579427e-04 JL> [96] 7.446202e-04 2.133444e-03 6.108393e-03 1.783085e-02 5.699554e-02 JL> [101] 1.00e+00 >> order(x) JL> [1] 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 JL> [19] 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 JL> [37] 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 55 68 72 JL> [55] 56 59 69 73 60 58 62 57 63 70 71 61 64 52 53 65 54 66 JL> [73] 67 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 JL> [91] 91 92 93 94 95 96 97 98 99 100 101 >> pbeta(x,0.01,5) JL> [1] 0.000 0.010 0.020 0.030 0.040 0.050 0.060 JL> [8] 0.070 0.080 0.090 0.100 0.110 0.120 0.130 JL> [15] 0.140 0.150 0.160 0.170 0.180 0.190 0.200 JL> [22] 0.210 0.220 0.230 0.240 0.250 0.260 0.270 JL> [29] 0.280 0.290 0.300 0.310 0.320 0.330 0.340 JL> [36] 0.350 0.360 0.370 0.380 0.390 0.400 0.410 JL> [43] 0.420 0.430 0.440 0.450 0.460 0.470 0.480 JL> [50] 0.490 0.500 0.7285871 0.7289426 0.7296061 0.7070842 0.7148952 JL> [57] 0.7227924 0.7219416 0.7169548 0.7209782 0.7259930 0.7219416 0.7227924 JL> [64] 0.7282134 0.7289426 0.7296061 0.7296061 0.7070842 0.7198677 0.7242443 JL> [71] 0.7254552 0.7120024 0.7198677 0.7299167 0.7400284 0.7499948 0.7599988 JL> [78] 0.778 0.778 0.790 0.800 0.810 0.820 0.830 JL> [85] 0.840 0.850 0.860 0.870 0.880 0.890 0.900 JL> [92] 0.910 0.920 0.930 0.940 0.950 0.960 0.970 JL> [99] 0.980 0.990 1.000 >> version JL> _ JL> platform x86_64-unknown-linux-gnu JL> arch x86_64 JL> os linux-gnu J
[Rd] Buglet in qbeta?
Hi, I sometimes play around with extreme parameters for distributions and found that qbeta is not always monotone as the following example shows. I don't know whether this is serious enough to submit a bug report (as this example is near to the limitations of floating point arithmetic). Josef > x <- qbeta((0:100)/100,0.01,5) > x [1] 0.00e+00 1.253990e-201 1.589622e-171 6.462785e-154 2.015085e-141 [6] 9.892240e-132 8.192553e-124 4.056003e-117 2.554424e-111 3.330774e-106 [11] 1.253990e-101 1.728076e-97 1.038529e-93 3.109063e-90 5.141594e-87 [16] 5.098238e-84 3.238117e-81 1.390549e-78 4.58e-76 9.411402e-74 [21] 1.589622e-71 2.090373e-69 2.190596e-67 1.866714e-65 1.316493e-63 [26] 7.803602e-62 3.941205e-60 1.716606e-58 6.517745e-57 2.178181e-55 [31] 6.462785e-54 1.715788e-52 4.104801e-51 8.906113e-50 1.762731e-48 [36] 3.199622e-47 5.352348e-46 8.288322e-45 1.193037e-43 1.602341e-42 [41] 2.015085e-41 2.380564e-40 2.649862e-39 2.787018e-38 2.776910e-37 [46] 2.627517e-36 2.366341e-35 2.032732e-34 1.668853e-33 1.311905e-32 [51] 9.892240e-32 2.220446e-15 2.331468e-15 2.553513e-15 1.110223e-16 [56] 3.330669e-16 9.992007e-16 8.881784e-16 4.440892e-16 7.771561e-16 [61] 1.554312e-15 8.881784e-16 9.992007e-16 2.109424e-15 2.331468e-15 [66] 2.553513e-15 2.553513e-15 1.110223e-16 6.661338e-16 1.221245e-15 [71] 1.443290e-15 2.220446e-16 6.661338e-16 2.664535e-15 1.054712e-14 [76] 4.019007e-14 1.512124e-13 5.589973e-13 2.031153e-12 7.261081e-12 [81] 2.554423e-11 8.847001e-11 3.017724e-10 1.014153e-09 3.359099e-09 [86] 1.096950e-08 3.532966e-08 1.122586e-07 3.520157e-07 1.089674e-06 [91] 3.330818e-06 1.005659e-05 3.50e-05 8.845884e-05 2.579427e-04 [96] 7.446202e-04 2.133444e-03 6.108393e-03 1.783085e-02 5.699554e-02 [101] 1.00e+00 > order(x) [1] 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 [19] 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 [37] 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 55 68 72 [55] 56 59 69 73 60 58 62 57 63 70 71 61 64 52 53 65 54 66 [73] 67 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 [91] 91 92 93 94 95 96 97 98 99 100 101 > pbeta(x,0.01,5) [1] 0.000 0.010 0.020 0.030 0.040 0.050 0.060 [8] 0.070 0.080 0.090 0.100 0.110 0.120 0.130 [15] 0.140 0.150 0.160 0.170 0.180 0.190 0.200 [22] 0.210 0.220 0.230 0.240 0.250 0.260 0.270 [29] 0.280 0.290 0.300 0.310 0.320 0.330 0.340 [36] 0.350 0.360 0.370 0.380 0.390 0.400 0.410 [43] 0.420 0.430 0.440 0.450 0.460 0.470 0.480 [50] 0.490 0.500 0.7285871 0.7289426 0.7296061 0.7070842 0.7148952 [57] 0.7227924 0.7219416 0.7169548 0.7209782 0.7259930 0.7219416 0.7227924 [64] 0.7282134 0.7289426 0.7296061 0.7296061 0.7070842 0.7198677 0.7242443 [71] 0.7254552 0.7120024 0.7198677 0.7299167 0.7400284 0.7499948 0.7599988 [78] 0.778 0.778 0.790 0.800 0.810 0.820 0.830 [85] 0.840 0.850 0.860 0.870 0.880 0.890 0.900 [92] 0.910 0.920 0.930 0.940 0.950 0.960 0.970 [99] 0.980 0.990 1.000 > version _ platform x86_64-unknown-linux-gnu arch x86_64 os linux-gnu system x86_64, linux-gnu status Under development (unstable) major 2 minor 11.0 year 2009 month 10 day07 svn rev49963 language R version.string R version 2.11.0 Under development (unstable) (2009-10-07 r49963) p.s. there are similar results for R-2.9.2 in Windows (with different round-off errors). -- - Josef Leydold | WU (Vienna University of Economics and Business) | Department of Statistics and Mathematics - Augasse 2-6 | Tel. +43 1 31336 4695 A-109
Re: [Rd] inconsistency in return value of peaks() {splus2R} (PR#13988)
vi...@phil.uu.nl wrote: Full_Name: Benny van der Vijgh Version: 2.7.2 OS: Windows Vista Submission from: (NULL) (194.171.252.108) The return value of peaks() in package splus2R is not consistent. This is not an R bug. Please contact the author of that package. Duncan Murdoch This is because of the call to max.col() without additional parameters which peaks() makes. max.col() has a parameter 'ties.method' which specifies how ties are handled, with "random" by default. This means that when peaks() is called on a vector with two (or more) neighbouring elements in a tie for the local maximum, these end up in the same row in the embedded matrix after which max.col() at random chooses which will be considered the maximum, thereby yielding inconsistent results, for example: a <- c(3,5,5,3) peaks(a) [1] FALSE FALSE FALSE FALSE peaks(a) [1] FALSE TRUE FALSE FALSE this can be easily fixed by setting the parameter 'ties.method' for max.col() to "first" or "last", which is a matter of application and taste I think, perhaps it can even be considered to make this parameter also a parameter of peaks() and pass it to max.col() in the execution. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] inconsistency in return value of peaks() {splus2R} (PR#13988)
Full_Name: Benny van der Vijgh Version: 2.7.2 OS: Windows Vista Submission from: (NULL) (194.171.252.108) The return value of peaks() in package splus2R is not consistent. This is because of the call to max.col() without additional parameters which peaks() makes. max.col() has a parameter 'ties.method' which specifies how ties are handled, with "random" by default. This means that when peaks() is called on a vector with two (or more) neighbouring elements in a tie for the local maximum, these end up in the same row in the embedded matrix after which max.col() at random chooses which will be considered the maximum, thereby yielding inconsistent results, for example: > a <- c(3,5,5,3) > peaks(a) [1] FALSE FALSE FALSE FALSE > peaks(a) [1] FALSE TRUE FALSE FALSE this can be easily fixed by setting the parameter 'ties.method' for max.col() to "first" or "last", which is a matter of application and taste I think, perhaps it can even be considered to make this parameter also a parameter of peaks() and pass it to max.col() in the execution. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] how to document stuff most users don't want to see
Patrick Burns wrote: I think the problem is more subtle than Spencer implies. It is good to have as much documentation as possible. However, if a help file is long and complex, then people get intimidated and don't read it at all. It would be nice to have a feature so that help files can be displayed with different levels of detail. A sophisticated version of this scheme might even assume different levels of knowledge of the user so that the least detailed level might be longer (but easier) than a more detailed level. We do have that. Vignettes can be linked to help, and they can be arbitrarily complex, including examples with graphs, etc. Duncan Murdoch Patrick Burns patr...@burns-stat.com +44 (0)20 8525 0696 http://www.burns-stat.com (home of "The R Inferno" and "A Guide for the Unwilling S User") spencerg wrote: There are many arguments in many functions that are rarely used. I prefer to see it all documented in the help pages. If they are not documented in the help pages (and sometimes even if they are), a user who wants them can invent other ways to get similar information with much greater effort, and do so for years only to eventually find a much easier way buried in the documentation. Example: I was frustrated for years that "nls" would refuse to produce output if it did not converge. I often used "optim" instead of "nls" for that reason. However, the list returned by "optim" does not have the nice methods that one can use with an "nls" object. Eventually, I found the "warnOnly" option documented under "nls.control", which has made "nls" easier for me to use. Spencer Graves William Dunlap wrote: There are several help files in the R sources that describe concepts and not particular R objects. E.g., help(Methods), help(Syntax), and help(regex). They don't have a docType entry and their alias entries do not refer to functions. Perhaps your debugging documentation could go into a similar *.Rd file. Does check balk at such help files in a package? Should it? Should there be a special docType for such help files? Bill Dunlap Spotfire, TIBCO Software wdunlap tibco.com -Original Message- From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org] On Behalf Of Charles Geyer Sent: Monday, October 05, 2009 10:51 AM To: r-devel@r-project.org Subject: [Rd] how to document stuff most users don't want to see The functions metrop and temper in the mcmc package have a debug = FALSE argument that when TRUE adds a lot of debugging information to the returned list. This is absolutely necessary to test the functions, because one generally knows nothing about the simulated distribution except what what one learns from MCMC samples. Hence you must expose all details of the simulation to have any hope of checking that it is doing what it is supposed to do. However, this information is of interested mostly (perhaps solely) to developers. So I didn't document it in the Rd files for these functions. But it has ocurred to me that people might be interested in how these functions are validated, and I would like to document the debug output somewhere, but I don't want to clutter up the documentation that ordinary users see. That suggests a separate help page for debugging. Looking at "Writing R Extensions" it doesn't seem like there is a type of Rd file for this purpose. I suppose it could be added in (fairly long) sections titled "Debug Output" in metrop.Rd and temper.Rd or it could be put in a package help page (although that's not what that kind of page is really for). Any other possibilities to consider? -- Charles Geyer Professor, School of Statistics University of Minnesota char...@stat.umn.edu __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug (PR#13987)
Please do read the FAQ and R posting guide. (i) You were asked not to report on obselete versions of R (2.9.2 and 2.10.0 alpha are current). (ii) There is no reproducible code here, but the error is almost certainly not in R but in a contributed package or in 'BRB Array tools' (whatever that is, and if you mean 'BRB-Array Tools', that is not freely distributable). 'Finally, check carefully whether the bug is with R, or a contributed package. Bug reports on contributed packages should be sent first to the package maintainer, and only submitted to the R-bugs repository by package maintainers, mentioning the package in the subject line.' (iii) R-bugs is explicitly not a place to ask questions. On Wed, 7 Oct 2009, bockme...@gmail.com wrote: Full_Name: Clemens Bockmeyer Version: 2.9.0 OS: Hmm, 'Always include the version of R, machine, and operating system that you are using; type `version' in R to print this.' Submission from: (NULL) (193.174.111.250) Dear helpdesk, the following bug occurs when working with BRB Array tools trying to generate a heat map: Error in rgb (bitAnd(Max color 255), bit and Max color %/%256, 255 bit And Max color... could not find function "bitAnd". Error occured while executing the following R command: myplot.image.array (TRUE). Error may be memory related or due to size of graphic file. Try again with fewer genes or... My question is: What to do, that R works? I am sure that I do NOT have to much genes! Thank you in advance. -- Brian D. Ripley, rip...@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] how to document stuff most users don't want to see
Under the system of development we now have, I agreee with Seth's assertion. But if there were people dedicated to documentation, then I think something like what I described could be workable. Pat Seth Falcon wrote: Writing good documentation is hard. I can appreciate the desire to find technological solutions that improve documentation. However, the benefit of a help system that allows for varying degrees of verbosity is very likely to be overshadowed by the additional complexity imposed on the help system. Users would need to learn how to tune the help system. Developers would need to learn and follow the system of variable verbosity. This time would be better spent by developers simply improving the documentation and by users by simply reading the improved documentation. My $0.02. + seth __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Bug (PR#13987)
Full_Name: Clemens Bockmeyer Version: 2.9.0 OS: Submission from: (NULL) (193.174.111.250) Dear helpdesk, the following bug occurs when working with BRB Array tools trying to generate a heat map: Error in rgb (bitAnd(Max color 255), bit and Max color %/%256, 255 bit And Max color... could not find function "bitAnd". Error occured while executing the following R command: myplot.image.array (TRUE). Error may be memory related or due to size of graphic file. Try again with fewer genes or... My question is: What to do, that R works? I am sure that I do NOT have to much genes! Thank you in advance. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
