Re: [Rd] declaring package dependencies

[Matthew Dowle]

On Sep 16, 2013, at 01:46 PM, Brian Rowe wrote:


That reminds me: I once made a suggestion on how to automate some of the CRAN
deployment process, but it was shot down as not being useful to them. I do
recall a quote that was along the lines of "as long as you don't need help,
do whatever you want", so one thought is to just set up a build server that
does the building across the three versions of R, checks dependencies, rebuilds
when release, patch, or devel are updated, etc. This would ease the burden on
package maintainers and would just happen to make the CRAN folks' lives easier
by catching a lot of bad builds. A proof of concept on AWS connecting to github
or rforge could probably be finished on a six-pack. Speak up if anyone thinks
this would be useful.


Yes useful. But that includes a package build system (which is what breaks on
R-Forge). If you could do that on a six-pack then could you fix R-Forge on a
three-pack first please? The R-Forge build system is itself an open source
package on R-Forge. Anyone can look at it, understand it and change it to be
more stable. That build system is here :

https://r-forge.r-project.org/R/?group_id=34

(I only know this because Stefan told me once. So I suspect others don't know
either, or it hasn't sunk in that we're pushing on an open door.)

Matthew

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] declaring package dependencies

[Matthew Dowle]

Ben Bolker wrote :

Do you happen to remember what the technical difficulty was?


From memory I think it was that CRAN maintainers didn't have
access to Uwe's winbuilder machine. But often when I get OK
from winbuilder R-devel I don't want it to go to CRAN yet. So
procedures and software would have to be put in place to
handle that (unclear) logic which I didn't propose anything
for or offer any code to do. So time and effort to decide and
time and effort to implement. Just a guess. And maybe some
packages don't run on Windows, so what about those?  It's
all those edge cases that really take the time.

Matthew

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] FOSS licence with BuildVignettes: false

[Uwe Ligges]

On 16.09.2013 01:04, Ben Bolker wrote:

Uwe Ligges  statistik.tu-dortmund.de> writes:



Setting

BuildVignettes: false

is fine if it is possible to build the vignettes, and the latter is
checked in CRAN incoming checks (but not the daily checks).

Uwe Ligges


Hmmm.  I was told by the CRAN maintainers on Aug 7 that

CRAN> "FOSS licence with BuildVignettes: false" is not a false positive,
CRAN> is fixable, and is mentioned at
CRAN> http://cran.r-project.org/doc/manuals/r-devel/R-exts.html#
CRAN>The-DESCRIPTION-file as not to be used in an FOSS package.

   (I had said in my previous e-mail to CRAN that all NOTEs were
false positives, minor or not fixable.)  Admittedly this e-mail
nowhere said explicitly "you must fix this or we will not accept
it for CRAN", but that was certainly the impression I got.

TFM says

R-exts>   [BuildVignettes: false] should only be used exceptionally, for
R-exts> example if the PDFs include large figures which are not part of the
R-exts> package sources (and hence only in packages which do not have an
R-exts> Open Source license).

So either I'm confused (always a possibility!) or it seems
there are some inconsistencies here ...


Yes, and I could see really rare circumstances where vignette building 
takes a long time and the maintainer decides not to build vignettes as 
part of the daily checks.
If there were no possible (but typically rather rare) exceptions, this 
would be at least a Warning.


Best,
Uwe Ligges








On 15.09.2013 22:13, Viechtbauer Wolfgang (STAT) wrote:

Dear All,

I have been checking the metafor package against R-devel.

R CMD check --as-cran metafor

yields one note:

FOSS licence with BuildVignettes: false

Yes, I have 'BuildVignettes: FALSE' in my DESCRIPTION file.

I see at http://developer.r-project.org/blosxom.cgi/R-devel/NEWS:


Tue, 25 Jun 2013
CHANGES IN R-devel UTILITIES

  'R CMD check --as-cran' warns about a false value

of the 'DESCRIPTION' field 'BuildVignettes' for Open
Source packages, and ignores it (as an Open Source package
needs to have complete sources for its vignettes).


My questions are:

1) Is this going to be an issue if I submit a new

version of the metafor package to CRAN right now?


2) And if the answer to 1 is "Not right now": Is this going

to become an issue in the future? In other words, is
it the goal to only allow packages with BuildVignettes=true
if they have an FOSS license at some point in
the future?


Best,
Wolfgang



__
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] declaring package dependencies

[Göran Broström]

On 09/15/2013 11:09 AM, Matthew Dowle wrote:


I'm a little surprised by this thread.

I subscribe to the RSS feeds of changes to NEWS (as Dirk mentioned) and
that's been pretty informative in the past :
http://developer.r-project.org/RSSfeeds.html

Mainly though, I submit to winbuilder before submitting to CRAN, as the
CRAN policies advise.


Right, but

"Please _do not_ upload BioConductor packages or CRAN packages."

from the winbuilder page.

Göran


winbuilder's R-devel seems to be built daily,
saving me the time. Since I don't have Windows it kills two birds with
one stone.  It has caught many problems for me before submitting to CRAN
and I can't remember it ever not responding in a reasonable time.
http://win-builder.r-project.org/upload.aspx

I've suggested before that winbuilder could be the mechanism to submit
to CRAN rather than an ftp upload to incoming.  Only if winbuilder
passed OK on R-devel could it then go to a human.   But iirc there was a
technical difficulty preventing this.

Matthew

__
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] declaring package dependencies

[Duncan Murdoch]

On 13-09-16 3:59 AM, Göran Broström wrote:



On 09/15/2013 11:09 AM, Matthew Dowle wrote:


I'm a little surprised by this thread.

I subscribe to the RSS feeds of changes to NEWS (as Dirk mentioned) and
that's been pretty informative in the past :
http://developer.r-project.org/RSSfeeds.html

Mainly though, I submit to winbuilder before submitting to CRAN, as the
CRAN policies advise.


Right, but

"Please _do not_ upload BioConductor packages or CRAN packages."

from the winbuilder page.


From the context, that message is about packages that are already on 
CRAN without Windows binaries already built.


Duncan Murdoch



Göran


winbuilder's R-devel seems to be built daily,
saving me the time. Since I don't have Windows it kills two birds with
one stone.  It has caught many problems for me before submitting to CRAN
and I can't remember it ever not responding in a reasonable time.
http://win-builder.r-project.org/upload.aspx

I've suggested before that winbuilder could be the mechanism to submit
to CRAN rather than an ftp upload to incoming.  Only if winbuilder
passed OK on R-devel could it then go to a human.   But iirc there was a
technical difficulty preventing this.

Matthew

__
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] declaring package dependencies

[Duncan Murdoch]

On 13-09-15 9:58 PM, Yihui Xie wrote:

I've been watching this thread closely and trying not to chime in,
because as Brian Rowe mentioned about CRAN's mysterious absence in a
previous reply.


It's no mystery that they don't discuss CRAN policies on this list. 
That's been stated many times.  I don't expect that to change because 
users on this list make stupid jokes about it.


Duncan Murdoch

CRAN is like a ghost in r-devel (or any other mailing

lists) -- everybody is discussing about it, and nobody has ever seen
it. Perhaps one day useRs will realize that the rings of Saturn are
actually composed of the lost discussions about CRAN. (Just kidding.
No offence. I swear I appreciate the great work of CRAN, and
rep("thank you, CRAN", 1e6).)

Although this discussion may also contribute to the rings of Saturn, I
want to emphasize one final point: requests from package authors do
not necessarily mean more work for CRAN.

Regards,
Yihui
--
Yihui Xie 
Web: http://yihui.name
Department of Statistics, Iowa State University
2215 Snedecor Hall, Ames, IA


On Sun, Sep 15, 2013 at 6:11 PM, Ben Bolker  wrote:

Matthew Dowle  mdowle.plus.com> writes:




I'm a little surprised by this thread.

I subscribe to the RSS feeds of changes to NEWS (as Dirk mentioned) and
that's been pretty informative in the past :
http://developer.r-project.org/RSSfeeds.html

Mainly though, I submit to winbuilder before submitting to CRAN, as the
CRAN policies advise.  winbuilder's R-devel seems to be built daily,
saving me the time. Since I don't have Windows it kills two birds with
one stone.  It has caught many problems for me before submitting to CRAN
and I can't remember it ever not responding in a reasonable time.
http://win-builder.r-project.org/upload.aspx

I've suggested before that winbuilder could be the mechanism to submit
to CRAN rather than an ftp upload to incoming.  Only if winbuilder
passed OK on R-devel could it then go to a human.   But iirc there was a
technical difficulty preventing this.

Matthew


   I was planning to write a careful e-mail to CRAN suggesting
essentially this, and I may yet do so, but for now I'll just chime in
and "+1" this.  Yihui Xie made a very similar suggestion sometime
last year (I think).  It would seem so much easier for everyone,
package maintainers *and* CRAN maintainers, to have an automatic
filter of this sort, and I can't figure out any downside other than
needing slightly more computer power (which surely must be a reasonable
tradeoff for fewer human resources!), *if* having the
auto-filter made people sloppier about checking before submitting.
Do you happen to remember what the technical difficulty was?
If I were a CRAN maintainer (thank goodness I'm not!), overcoming
it would be one of my top priorities ...

   Ben Bolker


__
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] Patch: fix segfault from empty raster

[QRD]

Hi,

A colleague recently came across an R crash, which I can boil down to
the following, running under Rgui on Windows 7:

library(ggplot2)
ggplot(data.frame(x=1, y=1, z=4.7), aes(x, y, z=z)) + stat_summary2d()

This reliably causes a segmentation fault.  sessionInfo() below.

What's happening is that (for reasons which I'll discuss with the
ggplot2 developers) the 'colorbar' guide is being built with a zero-size
source raster.

In L_raster() (grid.c), this raster is not a "nativeRaster", so we do

image = (unsigned int*) R_alloc(n, sizeof(unsigned int));

with n = 0, and R_alloc() gives us a NULL pointer.

The display of this raster requests interpolation, so we end up in
R_GE_rasterInterpolate(), where 'sraster' is NULL, and chaos ensues as
it tries to read source pixels.

It seems to me that it doesn't make sense to display an empty raster, so
I inserted a check in L_raster().  A proof-of-concept patch is attached.
With this patch, R gives an error message instead of a segfault.

Does this seem a sensible change?  If so, could something like it be
incorporated?

Thanks,

Ben.

- - - - 8< - - - -

> sessionInfo()
R version 3.0.1 (2013-05-16)
Platform: x86_64-w64-mingw32/x64 (64-bit)

locale:
[1] LC_COLLATE=English_Ireland.1252  LC_CTYPE=English_Ireland.1252
[3] LC_MONETARY=English_Ireland.1252 LC_NUMERIC=C
[5] LC_TIME=English_Ireland.1252

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base

other attached packages:
[1] ggplot2_0.9.3.1

loaded via a namespace (and not attached):
 [1] colorspace_1.2-2   compiler_3.0.1 dichromat_2.0-0digest_0.6.3
 [5] grid_3.0.1 gtable_0.1.2   labeling_0.2   MASS_7.3-26
 [9] munsell_0.4plyr_1.8   proto_0.3-10   RColorBrewer_1.0-5
[13] reshape2_1.2.2 scales_0.2.3   stringr_0.6.2  tools_3.0.1

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] declaring package dependencies

[Göran Broström]

On 09/16/2013 12:38 PM, Duncan Murdoch wrote:

On 13-09-16 3:59 AM, Göran Broström wrote:



On 09/15/2013 11:09 AM, Matthew Dowle wrote:


I'm a little surprised by this thread.

I subscribe to the RSS feeds of changes to NEWS (as Dirk mentioned) and
that's been pretty informative in the past :
http://developer.r-project.org/RSSfeeds.html

Mainly though, I submit to winbuilder before submitting to CRAN, as the
CRAN policies advise.


Right, but

"Please _do not_ upload BioConductor packages or CRAN packages."

from the winbuilder page.


  From the context, that message is about packages that are already on
CRAN without Windows binaries already built.


Maybe, but that is not what the page says.

Anyway, may I use this facility to check new versions of my CRAN 
packages or not?


Göran


Duncan Murdoch



Göran


winbuilder's R-devel seems to be built daily,
saving me the time. Since I don't have Windows it kills two birds with
one stone.  It has caught many problems for me before submitting to CRAN
and I can't remember it ever not responding in a reasonable time.
http://win-builder.r-project.org/upload.aspx

I've suggested before that winbuilder could be the mechanism to submit
to CRAN rather than an ftp upload to incoming.  Only if winbuilder
passed OK on R-devel could it then go to a human.   But iirc there was a
technical difficulty preventing this.

Matthew

__
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] declaring package dependencies

[Brian Lee Yung Rowe]

I haven't used rforge, but I will look check out the scripts. The reason it 
would be a six-pack of work is that there are generic build systems that handle 
most of this work. What they don't do is act as a repository, so rforge could 
remain that while separating out the build process. 


On Sep 16, 2013, at 4:58 AM, Matthew Dowle  wrote:

> On Sep 16, 2013, at 01:46 PM, Brian Rowe wrote:
> 
>> That reminds me: I once made a suggestion on how to automate some of the CRAN
>> deployment process, but it was shot down as not being useful to them. I do
>> recall a quote that was along the lines of "as long as you don't need help,
>> do whatever you want", so one thought is to just set up a build server that
>> does the building across the three versions of R, checks dependencies, 
>> rebuilds
>> when release, patch, or devel are updated, etc. This would ease the burden on
>> package maintainers and would just happen to make the CRAN folks' lives 
>> easier
>> by catching a lot of bad builds. A proof of concept on AWS connecting to 
>> github
>> or rforge could probably be finished on a six-pack. Speak up if anyone thinks
>> this would be useful.
> 
> Yes useful. But that includes a package build system (which is what breaks on
> R-Forge). If you could do that on a six-pack then could you fix R-Forge on a
> three-pack first please? The R-Forge build system is itself an open source
> package on R-Forge. Anyone can look at it, understand it and change it to be
> more stable. That build system is here :
> 
> https://r-forge.r-project.org/R/?group_id=34
> 
> (I only know this because Stefan told me once. So I suspect others don't know
> either, or it hasn't sunk in that we're pushing on an open door.)
> 
> Matthew
> 
> __
> 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] declaring package dependencies

[Uwe Ligges]

On 16.09.2013 13:52, Göran Broström wrote:



On 09/16/2013 12:38 PM, Duncan Murdoch wrote:

On 13-09-16 3:59 AM, Göran Broström wrote:



On 09/15/2013 11:09 AM, Matthew Dowle wrote:


I'm a little surprised by this thread.

I subscribe to the RSS feeds of changes to NEWS (as Dirk mentioned) and
that's been pretty informative in the past :
http://developer.r-project.org/RSSfeeds.html

Mainly though, I submit to winbuilder before submitting to CRAN, as the
CRAN policies advise.


Right, but

"Please _do not_ upload BioConductor packages or CRAN packages."

from the winbuilder page.


  From the context, that message is about packages that are already on
CRAN without Windows binaries already built.


Maybe, but that is not what the page says.

Anyway, may I use this facility to check new versions of my CRAN
packages or not?


Yes, before submission, but not if the version is on CRAN already (i.e. 
if the version became a CRAN package).


Best,
Uwe Ligges





Göran


Duncan Murdoch



Göran


winbuilder's R-devel seems to be built daily,
saving me the time. Since I don't have Windows it kills two birds with
one stone.  It has caught many problems for me before submitting to
CRAN
and I can't remember it ever not responding in a reasonable time.
http://win-builder.r-project.org/upload.aspx

I've suggested before that winbuilder could be the mechanism to submit
to CRAN rather than an ftp upload to incoming.  Only if winbuilder
passed OK on R-devel could it then go to a human.   But iirc there
was a
technical difficulty preventing this.

Matthew

__
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

[Rd] Rcpp modules

[Stefan Boehringer]

Dear all,

my apologies for posting here instead of rcpp-devel (registration for
which did not seem to work). I try to use a Rcpp module outside a
package using the following code which should work according to posts on
this list/rcpp-devel.

library('Rcpp');
dlr = dyn.load('build/libtestlib.so');
mod = Module('testclass', PACKAGE = dlr);
cl = new(mod$testclass);

This results in the error message:
Failed to initialize module pointer: Error in
FUN("_rcpp_module_boot_testclass"[[1L]], ...): no such symbol
_rcpp_module_boot_testclass in package
/home/pingu/src/2013-rcpp-test/rcpptest/build/libtestlib.so

Passing the PACKAGE argument above reportedly should solve this error
but does not seem to do so in my setup. Any suggestion appreciated. The
mentioned symbol exists in the shared object file which is linked agains
libR and libRcpp. Both a build with R CMD SHLIB and/or standard cmake
gives the same result.

Environment:
Linux
R 3.0.1
Rcpp_0.10.4
Freshly compiled from source.

Thanks in advance,

Stefan

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Rcpp modules

[Dirk Eddelbuettel]

On 16 September 2013 at 16:12, Stefan Boehringer wrote:
| my apologies for posting here instead of rcpp-devel (registration for
| which did not seem to work). 

It is using the standard Python mailman software, as do lots of other lists.
Your From: field _must_ match you registration. That is the sole requirement.

| I try to use a Rcpp module outside a

Please post Rcpp questions on rcpp-devel.

Dirk

-- 
Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] helping R-forge build

[Paul Gilbert]

(subject changed from Re: [Rd] declaring package dependencies )
...

Yes useful. But that includes a package build system (which is what
breaks on
R-Forge). If you could do that on a six-pack then could you fix R-Forge
on a
three-pack first please? The R-Forge build system is itself an open source
package on R-Forge. Anyone can look at it, understand it and change it
to be
more stable. That build system is here :

https://r-forge.r-project.org/R/?group_id=34

(I only know this because Stefan told me once. So I suspect others don't
know
either, or it hasn't sunk in that we're pushing on an open door.)

Matthew


Open code is necessary, but to debug one needs access to logs, etc, to 
see where it is breaking.  Do you know how to find that information?


(And, BTW, there are also tools to help automatically build R and test 
packages at http://automater.r-forge.r-project.org/ .)


Paul

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] helping R-forge build

[Matthew Dowle]

On 16/09/13 16:11, Paul Gilbert wrote:

(subject changed from Re: [Rd] declaring package dependencies )
...

Yes useful. But that includes a package build system (which is what
breaks on
R-Forge). If you could do that on a six-pack then could you fix R-Forge
on a
three-pack first please? The R-Forge build system is itself an open
source
package on R-Forge. Anyone can look at it, understand it and change it
to be
more stable. That build system is here :

https://r-forge.r-project.org/R/?group_id=34

(I only know this because Stefan told me once. So I suspect others don't
know
either, or it hasn't sunk in that we're pushing on an open door.)

Matthew


Open code is necessary, but to debug one needs access to logs, etc, to
see where it is breaking.  Do you know how to find that information?


There's a link at the bottom of the R-Forge page to :
  http://download.r-forge.r-project.org/STATUS
I don't know if that's enough but it's a start maybe. I've copied Stefan 
in case there are more logs somewhere else.



(And, BTW, there are also tools to help automatically build R and test
packages at http://automater.r-forge.r-project.org/ .)


automater looks good! What's the next step?



Paul



__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] FOSS licence with BuildVignettes: false

[Paul Gilbert]

On 13-09-16 05:19 AM, Uwe Ligges wrote:
...

Yes, and I could see really rare circumstances where vignette building
takes a long time and the maintainer decides not to build vignettes as
part of the daily checks.

...

I thought 'BuildVignettes: FALSE' only turns of assembling the pdf, all 
the code is still run.  I don't think that would affect the time very 
much. Am I wrong (again)?


Paul


Uwe Ligges



__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] a fast table() for the 1D case

[Hervé Pagès]

Any chance some improvements can be made on table()?

table() is probably one of the most used R functions when working
interactively. Unfortunately it can be incredibly slow, especially
on a logical vector where a simple sum() is hundred times faster
(I actually got into the habit of using sum() instead of table()).
The table1D() proposal below doesn't go as far as using sum() on a
logical vector but it already provides significant speedups for most
use cases.

Thanks,
H.


On 08/09/2013 01:19 AM, Hervé Pagès wrote:

Hi,

table1D() below can be up to 60x faster than base::table() for the 1D
case. Here are the detailed speedups compared to base::table().

   o With a logical vector of length 5M: 11x faster
 (or more if 'useNA="always"')

   o With factor/integer/numeric/character of length 1M and 9 levels
 (or 9 distinct values for non-factors):
  - factor:  60x faster
  - integer/numeric vector:  12x faster
  - character vector:   2.4x faster

   o With factor/integer/numeric/character of length 1M and no
 duplicates:
   - factor:  5x faster
   - integer vector:  2x faster
   - numeric vector:1.7x faster
   - character vector:   no significant speedup

Would be great if this improvement could make it into base::table().

Thanks,
H.

   ## A fast table() implementation for the 1D case (replacing the '...'
   ## arg with 'x' and omitting the 'dnn' and 'deparse.level' arguments
   ## which are unrelated to performance).

   table1D <- function(x, exclude = if (useNA == "no") c(NA, NaN),
   useNA = c("no", "ifany", "always"))
   {
 if (!missing(exclude) && is.null(exclude)) {
 useNA <- "always"
 } else {
 useNA <- match.arg(useNA)
 }
 if (useNA == "always" && !missing(exclude))
 exclude <- setdiff(exclude, NA)
 if (is.factor(x)) {
 x2 <- levels(x)
 append_NA <- (useNA == "always" ||
   useNA == "ifany" && any(is.na(x))) &&
  !any(is.na(x2))
 if (append_NA) {
 x2 <- c(x2, NA)
 x <- factor(x, levels=x2, exclude=NULL)
 }
 t2 <- tabulate(x, nbins=length(x2))
 if (!is.null(exclude)) {
 keep_idx <- which(!(x2 %in% exclude))
 x2 <- x2[keep_idx]
 t2 <- t2[keep_idx]
 }
 } else {
 xx <- match(x, x)
 t <- tabulate(xx, nbins=length(xx))
 keep_idx <- which(t != 0L)
 x2 <- x[keep_idx]
 t2 <- t[keep_idx]
 if (!is.null(exclude)) {
 exclude <- as.vector(exclude, typeof(x))
 keep_idx <- which(!(x2 %in% exclude))
 x2 <- x2[keep_idx]
 t2 <- t2[keep_idx]
 }
 oo <- order(x2)
 x2 <- x2[oo]
 t2 <- t2[oo]
 append_NA <- useNA == "always" && !any(is.na(x2))
 if (append_NA) {
 x2 <- c(x2, NA)
 t2 <- c(t2, 0L)
 }
 }
 ans <- array(t2)
 dimnames(ans) <- list(as.character(x2))
 names(dimnames(ans)) <- "x"  # always set to 'x'
 class(ans) <- "table"
 ans
   }

table1D() also fixes some issues with base::table() that can be exposed
by running the tests below.

   test_table <- function(FUN_NAME)
   {
 FUN <- match.fun(FUN_NAME)

 .make_target <- function(target_names, target_data)
 {
 ans <- array(target_data)
 dimnames(ans) <- list(as.character(target_names))
 names(dimnames(ans)) <- "x"
 class(ans) <- "table"
 ans
 }

 .check_identical <- function(target, current, varname, extra_args)
 {
 if (identical(target, current))
 return()
 if (extra_args != "")
 extra_args <- paste0(", ", extra_args)
 cat("unexpected result for '", FUN_NAME,
 "(x=", varname, extra_args, ")'\n", sep="")
 }

 .test_exclude <- function(x, varname, target_names0, target_data0,
exclude)
 {
 extra_args <- paste0("exclude=", deparse(exclude))
 current <- FUN(x=x, exclude=exclude)
 target_names <- target_names0
 target_data <- target_data0
 if (is.null(exclude)) {
 if (!any(is.na(target_names))) {
 target_names <- c(target_names, NA)
 target_data <- c(target_data, 0L)
 }
 } else {
 if (!is.factor(x)) {
 exclude <- as.vector(exclude, typeof(x))
 } else if (!any(is.na(levels(x {
 exclude <- union(exclude, NA)
 }
 exclude_idx <- match(exclude, target_names, nomatch=0L)
 if (any(exclude_idx != 0L)) {
 target_names <- target_names[-exclude_idx]
 target_data <- target_data[-exclude_idx]
 }

[Rd] strange behavior for RcmdrPlugin.qual

[Hodgess, Erin]

Hello!

Over the weekend, I updated my RcmdrPlugin.qual package.

It works fine on a 64 bit Windows machine but not a 32 bit.  This is very 
strange.  The new menu with all of the Quality Control stuff does not appear.

Have any of you run into this sort of thing before, please?

Thanks,
Sincerely,
Erin


Erin M. Hodgess, Ph.D.
Associate Professor
Department of Computer and Mathematical Sciences
University of Houston - Downtown
mailto: hodge...@uhd.edu


[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] strange behavior for RcmdrPlugin.qual

[John Fox]

Dear Erin,

I noticed that your RcmdrPlugin.qual package declares qcc under Suggests, and 
thus qcc isn't necessarily installed along with the plug-in. The menu file for 
your plug-in requires the presence of qcc to install most of the menu items 
under the Quality Control menu.

I installed your plug-in via install.packages() on a 64-bit Windows 8 machine, 
with R 3.0-1 and Rcmdr 2.0-0. When I first loaded the plug-in, both in 64-bit 
and 32-bit Windows, most of the items under the Quality Control menu didn't 
appear, because qcc wasn't installed. The menu itself, along with a couple of 
items, did appear, and so this may not be the same problem as you described. 
Also, I don't have a 32-bit machine but, as I said, saw identical behaviour 
under 32- and 64-bit R on a 64-bit machine.

I hope this helps,
 John

On Tue, 17 Sep 2013 00:06:09 +
 "Hodgess, Erin"  wrote:
> Hello!
> 
> Over the weekend, I updated my RcmdrPlugin.qual package.
> 
> It works fine on a 64 bit Windows machine but not a 32 bit.  This is very 
> strange.  The new menu with all of the Quality Control stuff does not appear.
> 
> Have any of you run into this sort of thing before, please?
> 
> Thanks,
> Sincerely,
> Erin
> 
> 
> Erin M. Hodgess, Ph.D.
> Associate Professor
> Department of Computer and Mathematical Sciences
> University of Houston - Downtown
> mailto: hodge...@uhd.edu
> 
> 
>   [[alternative HTML version deleted]]
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel


John Fox
McMaster University
Hamilton, Ontario, Canada
http://socserv.mcmaster.ca/jfox/

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] JDK not registered

[crunch]

Given:
$JAVA_HOME=~/jdk1.7.0_40
$R_SHELL=/bin/sh
$PATH=$R_HOME/bin:$JAVA_HOME/bin:...

which jar --> ~/jdk1.7.0_40/bin/jar
which javac --> ~/jdk1.7.0_40/bin/javac
which javah --> ~/jdk1.7.0_40/bin/javah
which java --> '', even though there is one in $JAVA_HOME/bin
whereis java -->
java: /bin/java /usr/bin/java /sbin/java /usr/sbin/java /lib/java
/usr/lib/java /usr/local/bin/java /usr/share/java
   obviously missing the 1.7.0_40 version in $JAVA_HOME/bin as well as the
1.5 version in /usr/bin

If I push into the Rserve package directory and run ./configure, I get:
...
checking Java support in R... present:
interpreter : ''
archiver: ''
compiler: ''
header prep.: ''
cpp flags   : ''
java libs   : ''
configure: error: Java Development Kit (JDK) is missing or not registered.

Of course that may be because I have not yet successfully completed a make
of R

if I run R CMD javareconf -e
I get:
Java interpreter : /home1/optimal1/jdk1.7.0_40/jre/bin/java   (why
not the one in the jdk/bin?)
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
Error occurred during initialization of VM
Could not reserve enough space for object heap

*** Java interpreter doesn't work properly.

I have found that $JAVA_HOME/bin/java (and the one in the jre/bin directory)
each complain 
Error occurred during initialization of VM
Could not reserve enough space for object heap
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

but, if I define:
alias java='$JAVA_HOME/bin/java -Xmx668m -XX:MaxPermSize=128m'
I can run java in SSH, though R CMD javareconf -e
still fails to initialize the VM.

What can I do to get javareconf to run java with those memory limits?




--
View this message in context: 
http://r.789695.n4.nabble.com/R-build-issues-tp4676149p4676286.html
Sent from the R devel mailing list archive at Nabble.com.

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel