Re: [Rd] bindingIsLocked returns illogical logical
On Sun, 14 May 2006, Seth Falcon wrote:
> Martin Morgan <[EMAIL PROTECTED]> writes:
>
>> bindingIsLocked applied to a locked binding returns a 'logical' that
>> is niether true nor false.
>
> Is this a philosophical question? :-)
But there is such a value defined for R logical vectors.
> Here's what I think is going on:
>
> BINDING_IS_LOCKED does not return 0/1, but the result of a bit op that
> will be either 0 or some int where bit 14 is set.
>
> The behavior you describe is consistent with a logical value escaping
> to R where the underlying int is some x > 1.
>
> I wonder if ScalarLogical should force 0/1:
Not a good idea: what about the third value, NA?
> Index: include/Rinlinedfuns.h
> ===
> --- include/Rinlinedfuns.h (revision 38060)
> +++ include/Rinlinedfuns.h (working copy)
> @@ -494,7 +494,7 @@
> INLINE_FUN SEXP ScalarLogical(int x)
> {
> SEXP ans = allocVector(LGLSXP, 1);
> -INTEGER(ans)[0] = x;
> +INTEGER(ans)[0] = (x == 0) ? 0 : 1;
> return ans;
> }
>
> Otherwise, I think do_bndIsLocked needs to make a similar operation
> before calling ScalarLogical. But preventing these all purpose
> logicals from escaping would seem to be a good argument for changing
> ScalarLogical.
I think it needs to handle NAs.
--
Brian D. Ripley, [EMAIL PROTECTED]
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] Error Compiling RMySQL in Fedora Core 5 86x64
on fedora core 5, you'll need to install the mysql-devel package.
the "mysql.h" header is in /usr/include/mysql/ .
So you need:
export PKG_CPPFLAGS="-I/usr/include/mysql"
export PKG_LIBS="-L/usr/lib64/mysql -lmysqlclient"
Juan Santiago Ramseyer wrote:
> in download and automatic install the RMySQL, R show the error (look
> under session attach. MySQL is install and operational.
>
> Juan Santiago Ramseyer.
>
>
>
>> install.packages('RMySQL')
> --- Please select a CRAN mirror for use in this session ---
> Loading Tcl/Tk interface ... done
> tentando a URL
> 'http://cran.br.r-project.org/src/contrib/RMySQL_0.5-7.tar.gz'
> Content type 'application/x-tar' length 142507 bytes
> URL aberta
> ==
> downloaded 139Kb
>
> * Installing *source* package 'RMySQL' ...
> creating cache ./config.cache
> checking how to run the C preprocessor... cc -E
> checking for compress in -lz... yes
> checking for getopt_long in -lc... yes
> checking for mysql_init in -lmysqlclient... no
> checking for mysql.h... no
> checking for mysql_init in -lmysqlclient... no
> checking for mysql_init in -lmysqlclient... no
> checking for mysql_init in -lmysqlclient... no
> checking for mysql_init in -lmysqlclient... no
> checking for mysql_init in -lmysqlclient... no
> checking for /usr/local/include/mysql/mysql.h... no
> checking for /usr/include/mysql/mysql.h... yes
>
> Configuration error:
> could not find the MySQL installation include and/or library
> directories. Manually specify the location of the MySQL
> libraries and the header files and re-run R CMD INSTALL.
>
> INSTRUCTIONS:
>
> 1. Define and export the 2 shell variables PKG_CPPFLAGS and
>PKG_LIBS to include the directory for header files (*.h)
>and libraries, for example (using Bourne shell syntax):
>
> export PKG_CPPFLAGS="-I"
> export PKG_LIBS="-L -lmysqlclient"
>
>Re-run the R INSTALL command:
>
> R CMD INSTALL RMySQL_.tar.gz
>
> 2. Alternatively, you may pass the configure arguments
> --with-mysql-dir= (distribution directory)
>or
> --with-mysql-inc= (where MySQL header files reside)
> --with-mysql-lib= (where MySQL libraries reside)
>in the call to R INSTALL --configure-args='...'
>
>R CMD INSTALL --configure-args='--with-mysql-dir=DIR'
> RMySQL_.tar.gz
>
> ERROR: configuration failed for package 'RMySQL'
> ** Removing '/usr/lib64/R/library/RMySQL'
>
> The downloaded packages are in
> /tmp/RtmpLXIne5/downloaded_packages
> Warning message:
> installation of package 'RMySQL' had non-zero exit status in:
> install.packages("RMySQL")
>
> __
> 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] Memory allocation fails in R 2.2.1 and R 2.3.0 on SGI Irix, while plenty of memory available (PR#8861)
Dear R developers, We have a big SGI Origin computation server with 32 cpu's and 64 Gb of RAM. In R 2.0.0 we could run large jobs, allocating 8 Gb of RAM was not a problem, for example by running: > v1 <- seq(1,2^29) > v2 <- seq(1,2^29) > v3 <- seq(1,2^29) > v4 <- seq(1,2^29) This yields an R process, consuming about 8 Gb of RAM: PID PGRP USERNAME PRI SIZE RES STATETIME WCPU% CPU% COMMAND 177484 177484 mirjam20 8225M 8217M sleep1:18 29.3 0.00 R After upgrading from R 2.0.0 to R 2.2.1, we cannot allocate more than about 1300 M of memory, as shown below: > v1 <- seq(1,2^29) Error: cannot allocate vector of size 2097152 Kb > v1 <- seq(1,2^28) > v2 <- seq(1,2^27) Error: cannot allocate vector of size 524288 Kb > v2 <- seq(1,2^25) > v3 <- seq(1,2^24) > v4 <- seq(1,2^23) > v5 <- seq(1,2^22) Error: cannot allocate vector of size 16384 Kb > v5 <- seq(1,2^21) > v6 <- seq(1,2^20) > v7 <- seq(1,2^19) > v8 <- seq(1,2^18) > q() Save workspace image? [y/n/c]: n Upgrading to R 2.3.0 yields the same results. This yields an R executable taking 1284M of RAM, refusing to allocate more RAM, with about 30Gb free on the machine. Is there any special configuration option I should turn on to make it possible to use more memory? The OS memory limits (ulimit -a) are set appropriately: data seg size (kbytes, -d) unlimited max memory size (kbytes, -m) 63385824 stack size(kbytes, -s) 65536 virtual memory(kbytes, -v) unlimited If it is not some special (compile time) option that I should have set, I think this is a bug. With kind regards, Mirjam van Vroonhoven -- Dr. Mirjam van Vroonhoven system administrator/programmer, dept. of Bioinformatics Erasmus Medical Center, Rotterdam, The Netherlands Room Number Ee 15.32, phone +31-10-463 81 11 Web:http://www.erasmusmc.nl/bioinformatics/ E-mail: [EMAIL PROTECTED] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Memory allocation fails in R 2.2.1 and R 2.3.0 on SGI Irix, while plenty of memory available (PR#8861)
On Mon, 15 May 2006, [EMAIL PROTECTED] wrote: > Dear R developers, > > We have a big SGI Origin computation server with 32 cpu's and 64 Gb of > RAM. In R 2.0.0 we could run large jobs, allocating 8 Gb of RAM was not > a problem, for example by running: > > v1 <- seq(1,2^29) > > v2 <- seq(1,2^29) > > v3 <- seq(1,2^29) > > v4 <- seq(1,2^29) > This yields an R process, consuming about 8 Gb of RAM: > PID PGRP USERNAME PRI SIZE RES STATETIME WCPU% CPU% COMMAND >177484 177484 mirjam20 8225M 8217M sleep1:18 29.3 0.00 R > > After upgrading from R 2.0.0 to R 2.2.1, we cannot allocate more than > about 1300 M of memory, as shown below: > > v1 <- seq(1,2^29) > Error: cannot allocate vector of size 2097152 Kb > > v1 <- seq(1,2^28) > > v2 <- seq(1,2^27) > Error: cannot allocate vector of size 524288 Kb > > v2 <- seq(1,2^25) > > v3 <- seq(1,2^24) > > v4 <- seq(1,2^23) > > v5 <- seq(1,2^22) > Error: cannot allocate vector of size 16384 Kb > > v5 <- seq(1,2^21) > > v6 <- seq(1,2^20) > > v7 <- seq(1,2^19) > > v8 <- seq(1,2^18) > > q() > Save workspace image? [y/n/c]: n > Upgrading to R 2.3.0 yields the same results. > This yields an R executable taking 1284M of RAM, refusing to allocate > more RAM, with about 30Gb free on the machine. You can tell if you have a 64bit build of R by looking at .Machine$sizeof.pointer in R, which should be 8. If not, then you need to set whatever C and Fortran compilation flags give a 64bit system. It doesn't look to me as if R's configure script has any special handling for C compiler flags on SGI. If you have a 64bit build then something strange is happening. The message you quote happens only when malloc() returns NULL, so it is hard to see how R could be causing it, though. -thomas Thomas Lumley Assoc. Professor, Biostatistics [EMAIL PROTECTED] University of Washington, Seattle __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Memory allocation fails in R 2.2.1 and R 2.3.0 on SGI Irix, (PR#8862)
On Mon, 15 May 2006, [EMAIL PROTECTED] wrote: > Dear R developers, > > We have a big SGI Origin computation server with 32 cpu's and 64 Gb of > RAM. In R 2.0.0 we could run large jobs, allocating 8 Gb of RAM was not > a problem, for example by running: > > v1 <- seq(1,2^29) > > v2 <- seq(1,2^29) > > v3 <- seq(1,2^29) > > v4 <- seq(1,2^29) > This yields an R process, consuming about 8 Gb of RAM: > PID PGRP USERNAME PRI SIZE RES STATETIME WCPU% CPU% COMMAND >177484 177484 mirjam20 8225M 8217M sleep1:18 29.3 0.00 R > > After upgrading from R 2.0.0 to R 2.2.1, we cannot allocate more than > about 1300 M of memory, as shown below: > > v1 <- seq(1,2^29) > Error: cannot allocate vector of size 2097152 Kb > > v1 <- seq(1,2^28) > > v2 <- seq(1,2^27) > Error: cannot allocate vector of size 524288 Kb > > v2 <- seq(1,2^25) > > v3 <- seq(1,2^24) > > v4 <- seq(1,2^23) > > v5 <- seq(1,2^22) > Error: cannot allocate vector of size 16384 Kb > > v5 <- seq(1,2^21) > > v6 <- seq(1,2^20) > > v7 <- seq(1,2^19) > > v8 <- seq(1,2^18) > > q() > Save workspace image? [y/n/c]: n > Upgrading to R 2.3.0 yields the same results. > This yields an R executable taking 1284M of RAM, refusing to allocate > more RAM, with about 30Gb free on the machine. You can tell if you have a 64bit build of R by looking at .Machine$sizeof.pointer in R, which should be 8. If not, then you need to set whatever C and Fortran compilation flags give a 64bit system. It doesn't look to me as if R's configure script has any special handling for C compiler flags on SGI. If you have a 64bit build then something strange is happening. The message you quote happens only when malloc() returns NULL, so it is hard to see how R could be causing it, though. -thomas Thomas Lumley Assoc. Professor, Biostatistics [EMAIL PROTECTED] University of Washington, Seattle __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] (PR#8861) Memory allocation fails in R 2.2.1 and R 2.3.0 on SGI Irix, while plenty of memory available
(Your reply to R-bugs started a new report, so I am aiming to re-file it.)
On Mon, 15 May 2006, Thomas Lumley wrote:
> On Mon, 15 May 2006, [EMAIL PROTECTED] wrote:
>
>> Dear R developers,
>>
>> We have a big SGI Origin computation server with 32 cpu's and 64 Gb of
>> RAM. In R 2.0.0 we could run large jobs, allocating 8 Gb of RAM was not
>> a problem, for example by running:
>> > v1 <- seq(1,2^29)
>> > v2 <- seq(1,2^29)
>> > v3 <- seq(1,2^29)
>> > v4 <- seq(1,2^29)
>> This yields an R process, consuming about 8 Gb of RAM:
>> PID PGRP USERNAME PRI SIZE RES STATETIME WCPU% CPU%
>> COMMAND
>>177484 177484 mirjam20 8225M 8217M sleep1:18 29.3 0.00 R
>>
>> After upgrading from R 2.0.0 to R 2.2.1, we cannot allocate more than
>> about 1300 M of memory, as shown below:
>> > v1 <- seq(1,2^29)
>> Error: cannot allocate vector of size 2097152 Kb
>> > v1 <- seq(1,2^28)
>> > v2 <- seq(1,2^27)
>> Error: cannot allocate vector of size 524288 Kb
>> > v2 <- seq(1,2^25)
>> > v3 <- seq(1,2^24)
>> > v4 <- seq(1,2^23)
>> > v5 <- seq(1,2^22)
>> Error: cannot allocate vector of size 16384 Kb
>> > v5 <- seq(1,2^21)
>> > v6 <- seq(1,2^20)
>> > v7 <- seq(1,2^19)
>> > v8 <- seq(1,2^18)
>> > q()
>> Save workspace image? [y/n/c]: n
>> Upgrading to R 2.3.0 yields the same results.
>> This yields an R executable taking 1284M of RAM, refusing to allocate
>> more RAM, with about 30Gb free on the machine.
>
>
> You can tell if you have a 64bit build of R by looking at
> .Machine$sizeof.pointer in R, which should be 8.
And if this is a 32-bit build, it is working as expected given the limited
address space.
> If not, then you need to set whatever C and Fortran compilation flags give
> a 64bit system. It doesn't look to me as if R's configure script has any
> special handling for C compiler flags on SGI.
Well, the R-admin manual says (under IRIX)
@R{} 2.1.0 has been successfully built on IRIX64 6.5 using both
@command{gcc} and the native (MipsPro 7.4) compiler. However, neither
version has passed @command{make check} due to a problem with time
zones (see below). A 64-bit executable has not been successfully
built.
so we could not use special handling for a system we have not been told
how to build in 64-bit mode.
Here we don't know the OS, the compiler, the flags used and that
definitely is a bug.
> If you have a 64bit build then something strange is happening. The message
> you quote happens only when malloc() returns NULL, so it is hard to see
> how R could be causing it, though.
--
Brian D. Ripley, [EMAIL PROTECTED]
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] bindingIsLocked returns illogical logical
Prof Brian Ripley <[EMAIL PROTECTED]> writes:
> On Sun, 14 May 2006, Seth Falcon wrote:
>> I wonder if ScalarLogical should force 0/1:
>
> Not a good idea: what about the third value, NA?
Indeed, I should have been sleeping (or perhaps I was already :-)
Is it enough to check for NA_LOGICAL or should all NA_* values be
checked for? Is there an easier/better way to do this sort of check?
Index: Rinlinedfuns.h
===
--- Rinlinedfuns.h (revision 38060)
+++ Rinlinedfuns.h (working copy)
@@ -494,6 +494,8 @@
INLINE_FUN SEXP ScalarLogical(int x)
{
SEXP ans = allocVector(LGLSXP, 1);
+if ((x != NA_LOGICAL) && (x != 0))
+x = 1;
INTEGER(ans)[0] = x;
return ans;
}
Perhaps for completeness, even though at present they are identical,
NA_INTEGER should be in the checking...
INLINE_FUN SEXP ScalarLogical(int x)
{
SEXP ans = allocVector(LGLSXP, 1);
if ((x == NA_LOGICAL) || (x == NA_INTEGER))
x = NA_LOGICAL;
else if (x != 0)
x = 1;
INTEGER(ans)[0] = x;
return ans;
}
Or perhaps there is a better solution entirely.
+ seth
>
>> Index: include/Rinlinedfuns.h
>> ===
>> --- include/Rinlinedfuns.h (revision 38060)
>> +++ include/Rinlinedfuns.h (working copy)
>> @@ -494,7 +494,7 @@
>> INLINE_FUN SEXP ScalarLogical(int x)
>> {
>> SEXP ans = allocVector(LGLSXP, 1);
>> -INTEGER(ans)[0] = x;
>> +INTEGER(ans)[0] = (x == 0) ? 0 : 1;
>> return ans;
>> }
>>
>> Otherwise, I think do_bndIsLocked needs to make a similar operation
>> before calling ScalarLogical. But preventing these all purpose
>> logicals from escaping would seem to be a good argument for changing
>> ScalarLogical.
>
> I think it needs to handle NAs.
>
> --
> Brian D. Ripley, [EMAIL PROTECTED]
> 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] bindingIsLocked returns illogical logical
On Mon, 15 May 2006, Seth Falcon wrote:
> Prof Brian Ripley <[EMAIL PROTECTED]> writes:
>
>> On Sun, 14 May 2006, Seth Falcon wrote:
>>> I wonder if ScalarLogical should force 0/1:
>>
>> Not a good idea: what about the third value, NA?
>
> Indeed, I should have been sleeping (or perhaps I was already :-)
>
> Is it enough to check for NA_LOGICAL or should all NA_* values be
> checked for? Is there an easier/better way to do this sort of check?
NA_LOGICAL and NA_INTEGER are the same value, and only NA_LOGICAL should
occur here. I used
/* As from R 2.4.0 we check that the value is allowed. */
INLINE_FUN SEXP ScalarLogical(int x)
{
SEXP ans = allocVector(LGLSXP, 1);
if (x == NA_LOGICAL) INTEGER(ans)[0] = NA_LOGICAL;
else INTEGER(ans)[0] = (x != 0);
return ans;
}
mainly because its intentions are crystal clear.
>
> Index: Rinlinedfuns.h
> ===
> --- Rinlinedfuns.h (revision 38060)
> +++ Rinlinedfuns.h (working copy)
> @@ -494,6 +494,8 @@
> INLINE_FUN SEXP ScalarLogical(int x)
> {
> SEXP ans = allocVector(LGLSXP, 1);
> +if ((x != NA_LOGICAL) && (x != 0))
> +x = 1;
> INTEGER(ans)[0] = x;
> return ans;
> }
>
> Perhaps for completeness, even though at present they are identical,
> NA_INTEGER should be in the checking...
>
> INLINE_FUN SEXP ScalarLogical(int x)
> {
>SEXP ans = allocVector(LGLSXP, 1);
>if ((x == NA_LOGICAL) || (x == NA_INTEGER))
>x = NA_LOGICAL;
>else if (x != 0)
>x = 1;
> INTEGER(ans)[0] = x;
> return ans;
> }
>
> Or perhaps there is a better solution entirely.
>
> + seth
>
>
>
>>
>>> Index: include/Rinlinedfuns.h
>>> ===
>>> --- include/Rinlinedfuns.h (revision 38060)
>>> +++ include/Rinlinedfuns.h (working copy)
>>> @@ -494,7 +494,7 @@
>>> INLINE_FUN SEXP ScalarLogical(int x)
>>> {
>>> SEXP ans = allocVector(LGLSXP, 1);
>>> -INTEGER(ans)[0] = x;
>>> +INTEGER(ans)[0] = (x == 0) ? 0 : 1;
>>> return ans;
>>> }
>>>
>>> Otherwise, I think do_bndIsLocked needs to make a similar operation
>>> before calling ScalarLogical. But preventing these all purpose
>>> logicals from escaping would seem to be a good argument for changing
>>> ScalarLogical.
>>
>> I think it needs to handle NAs.
>>
>> --
>> Brian D. Ripley, [EMAIL PROTECTED]
>> 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
>
>
--
Brian D. Ripley, [EMAIL PROTECTED]
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] (PR#8861) Memory allocation fails in R 2.2.1 and R 2.3.0 on SGI Irix, while plenty of memory available
Prof Brian Ripley wrote on Mon, May 15, 2006 at 04:09:38PM +0100:
> >You can tell if you have a 64bit build of R by looking at
> >.Machine$sizeof.pointer in R, which should be 8.
>
> And if this is a 32-bit build, it is working as expected given the limited
> address space.
It is a 32 bit build. My R 2.0.0 is a 64bit build.
> >If not, then you need to set whatever C and Fortran compilation flags give
> >a 64bit system. It doesn't look to me as if R's configure script has any
> >special handling for C compiler flags on SGI.
>
> Well, the R-admin manual says (under IRIX)
>
> @R{} 2.1.0 has been successfully built on IRIX64 6.5 using both
> @command{gcc} and the native (MipsPro 7.4) compiler. However, neither
> version has passed @command{make check} due to a problem with time
> zones (see below). A 64-bit executable has not been successfully
> built.
>
> so we could not use special handling for a system we have not been told
> how to build in 64-bit mode.
>
> Here we don't know the OS, the compiler, the flags used and that
> definitely is a bug.
The OS is irix 6.5.27, compiler = gcc, no special flags.
But that is no different from what I recall to have done when building
R 2.0.0 a long time ago.
I'll try to find out how to build a 64 bit executable, and see wether it
works. Probably that is easier using the native mipspro compiler.
Will report back to you guys when I find out a way to build a working
64bit R 2.3.0 on SGI/irix64
Thanks for the time,
Mirjam
--
Dr. Mirjam van Vroonhoven
system administrator/programmer, dept. of Bioinformatics
Erasmus Medical Center, Rotterdam, The Netherlands
Room Number Ee 15.32, phone +31-10-463 81 11
Web:http://www.erasmusmc.nl/bioinformatics/
E-mail: [EMAIL PROTECTED]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] bindingIsLocked returns illogical logical
Prof Brian Ripley <[EMAIL PROTECTED]> writes:
> On Mon, 15 May 2006, Seth Falcon wrote:
>> Is it enough to check for NA_LOGICAL or should all NA_* values be
>> checked for? Is there an easier/better way to do this sort of check?
>
> NA_LOGICAL and NA_INTEGER are the same value, and only NA_LOGICAL
> should occur here.
Makes sense (I knew that NA_LOGICAL and NA_INTEGER are the same, but I
didn't know whether this was a convenience or to allow for them to be
different in the future).
> I used
>
> /* As from R 2.4.0 we check that the value is allowed. */
> INLINE_FUN SEXP ScalarLogical(int x)
> {
> SEXP ans = allocVector(LGLSXP, 1);
> if (x == NA_LOGICAL) INTEGER(ans)[0] = NA_LOGICAL;
> else INTEGER(ans)[0] = (x != 0);
> return ans;
> }
>
> mainly because its intentions are crystal clear.
Agreed. Thanks for fixing this so quickly and for the
reminders/answers regarding NA handling.
Best,
+ seth
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Truncated labels in hist (PR#8864)
Hi, people. Executing the following command: hist(rpois(100,5), labels=TRUE) yields a graphic in which some labels are truncated (on an X11 device). The truncated labels are those over the highest bars. The hist function should ideally manage enough room for the labels, automatically. (Specifying ylim solves my problem, but yet, hist could be frienlier.) --please do not edit the information below-- Version: platform = x86_64-unknown-linux-gnu arch = x86_64 os = linux-gnu system = x86_64, linux-gnu status = major = 2 minor = 3.0 year = 2006 month = 04 day = 24 svn rev = 37909 language = R version.string = Version 2.3.0 (2006-04-24) Locale: LC_CTYPE=fr_CA.UTF-8;LC_NUMERIC=C;LC_TIME=fr_CA.UTF-8;LC_COLLATE=fr_CA.UTF-8;LC_MONETARY=fr_CA.UTF-8;LC_MESSAGES=fr_CA.UTF-8;LC_PAPER=C;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=C;LC_IDENTIFICATION=C Search Path: .GlobalEnv, package:methods, package:stats, package:graphics, package:utils, package:datasets, fp.etc, package:grDevices, Autoloads, package:base -- François Pinard http://pinard.progiciels-bpi.ca __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R CMD check does not remove all S4 methods defined in examples
Methods for generics created in '\example{}' sections of Rd files are
not entirely removed at the end of the example. This is because the
methods package caches these (in the environment returned by
getGeneric("initialize"), for the example below) as well as storing
their definition in the global environment.
The following would be derived from example code in pkg/man/eg1.Rd and
pkg/man/eg2.Rd. 'initialize' created for the first example persists in
the second, leading eventually (during R CMD check) to
> a <- new("A")
Shouldn't be here
Error in initialize(value, ...) : initialize method returned an object of class
"NULL" instead of the required class "A"
[standard code and comments from pkg-Ex.R removed]
### * eg1
flush(stderr()); flush(stdout())
setClass("A", representation(x="numeric"))
setMethod("initialize", "A",
function(.Object, ...) cat("Shouldn't be here\n"))
cleanEx(); ..nameEx <- "eg2"
### * eg2
flush(stderr()); flush(stdout())
setClass("A", representation(x="numeric"))
a <- new("A")
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Truncated labels in hist (PR#8864)
On 5/15/2006 7:35 PM, [EMAIL PROTECTED] wrote: > Hi, people. Executing the following command: > >hist(rpois(100,5), labels=TRUE) > > yields a graphic in which some labels are truncated (on an X11 device). > The truncated labels are those over the highest bars. The hist function > should ideally manage enough room for the labels, automatically. > (Specifying ylim solves my problem, but yet, hist could be frienlier.) I don't see this on Windows using windows(), or Linux using X11(). I imagine it's a case that the device isn't reporting the size of fonts properly, and since my X server shows things properly, I would guess it's a problem with your X server, not with R. Duncan Murdoch > > --please do not edit the information below-- > > Version: > platform = x86_64-unknown-linux-gnu > arch = x86_64 > os = linux-gnu > system = x86_64, linux-gnu > status = > major = 2 > minor = 3.0 > year = 2006 > month = 04 > day = 24 > svn rev = 37909 > language = R > version.string = Version 2.3.0 (2006-04-24) > > Locale: > LC_CTYPE=fr_CA.UTF-8;LC_NUMERIC=C;LC_TIME=fr_CA.UTF-8;LC_COLLATE=fr_CA.UTF-8;LC_MONETARY=fr_CA.UTF-8;LC_MESSAGES=fr_CA.UTF-8;LC_PAPER=C;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=C;LC_IDENTIFICATION=C > > Search Path: > .GlobalEnv, package:methods, package:stats, package:graphics, package:utils, > package:datasets, fp.etc, package:grDevices, Autoloads, package:base > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
