[Rd] Compatibility issues between Matrix and kml
Hi the list,
I am the maintainer of the package kml. I quite often receive some email
about a specific bug. The answer is always the same, I tell people to remove
the package Matrix, and then kml works fine.
I wonder what my code is not compatible with the Matrix package. Here is a
(simplified) version of the kml code :
--- 8<
library(longitudinalData)
setClass(Class="CLD", contains=c("LongData","ListPartition"))
myCld <- new("CLD",
idAll=as.character(c(100,102,103,109,115,123)),
idFewNA=as.character(c(100,102,103,109,115,123)),
time=c(1,2,4,8,15), varNames="P",
traj=matrix(c(1,2,3,1,4, 3,6,1,8,10, 1,2,1,3,2, 4,2,5,6,3,
4,3,4,4,4, 7,6,5,5,4),6),
dimTraj=c(6,5), maxNA=3, reverse=matrix(c(0,1),2,1)
)
setMethod("[",
signature=signature(x="CLD", i="character", j="ANY",drop="ANY"),
definition=function (x, i, j="missing", ..., drop = TRUE){
x <- as(x, "LongData")
return(x[i, j])
}
)
# [1] "["
myCld["idAll"]
# [1] "100" "102" "103" "109" "115" "123"
--- 8< ---
This code works just fine, there is no error.
But if I load the package Matrix and I run the same code, I get:
--- 8<
library(Matrix)
library(longitudinalData)
setClass(Class="CLD", contains=c("LongData","ListPartition"))
myCld <- new("CLD",
idAll=as.character(c(100,102,103,109,115,123)),
idFewNA=as.character(c(100,102,103,109,115,123)),
time=c(1,2,4,8,15), varNames="P",
traj=matrix(c(1,2,3,1,4, 3,6,1,8,10, 1,2,1,3,2, 4,2,5,6,3,
4,3,4,4,4, 7,6,5,5,4),6),
dimTraj=c(6,5), maxNA=3, reverse=matrix(c(0,1),2,1)
)
setMethod("[",
signature=signature(x="CLD", i="character", j="ANY",drop="ANY"),
definition=function (x, i, j="missing", ..., drop = TRUE){
x <- as(x, "LongData")
return(x[i, j])
}
)
# [1] "["
myCld["idAll"]
# Error in myCld["idAll"]:
# Argument "j" is missing, with no default value
--- 8<
Any idea of what is going wrong?
Christophe
--
View this message in context:
http://r.789695.n4.nabble.com/Compatibility-issues-between-Matrix-and-kml-tp4696885.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
[Rd] requireNamespace() questions
I am trying to follow directions at
http://cran.r-project.org/doc/manuals/r-patched/R-exts.html#Suggested-packages
regarding handling suggested packages with requireNamespace() rather
than require(), and I have some questions.
1/ When I do requireNamespace() in a function is the loading of the
namespace only effective within the function?
2/ At the link above in the manual it says "Note the use of rgl:: as
that object would not necessarily be visible...". When the required
package is loading methods, will the method be found when I reference
the generic, which is not in the package, or do I need to do something
different?
3/ In some packages I have functions that return an object defined in
the suggested package being required. For example, a function does
require("zoo") and then returns a zoo object. So, to work with the
returned object I am really expecting that zoo will be available in the
session afterwards. Is it recommended that I just check if the package
is available on the search path the user has set rather than use
require() or requireNamespace()?.
Regarding checking the path without actually attaching the package to
the search path, is there something better than "package:zoo" %in%
search() or is that the best way?
4/ I have a function in a package that Depends on DBI and suggests
RMySQL, RPostgreSQL, RSQLite. The function uses dbDriver() in DBI which
uses do.call(). If I use requireNamespace() in place of require() I get
> requireNamespace("RMySQL")
Loading required namespace: RMySQL
> m <- dbDriver("MySQL")
Error in do.call(as.character(drvName), list(...)) :
could not find function "MySQL"
> require("RMySQL")
Loading required package: RMySQL
> m <- dbDriver("MySQL")
>
Is there a different way to handle this without altering the search path?
The function do.call() does not seem to work with an argument like
do.call("RMySQL::MySQL", list())
even at the top level, and this situation may be more complicated when
it is in a required package. What am I missing?
Thanks,
Paul
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] requireNamespace() questions
On Fri, Sep 12, 2014 at 3:13 PM, Paul Gilbert wrote:
>
> I am trying to follow directions at
> http://cran.r-project.org/doc/manuals/r-patched/R-exts.html#Suggested-packages
> regarding handling suggested packages with requireNamespace() rather than
> require(), and I have some questions.
>
> 1/ When I do requireNamespace() in a function is the loading of the
> namespace only effective within the function?
Loading the namespace is (effectively) permanent. But the only thing
loading the namespace does is trigger the .onLoad() if present; it
does not affect the search path.
> 2/ At the link above in the manual it says "Note the use of rgl:: as that
> object would not necessarily be visible...". When the required package is
> loading methods, will the method be found when I reference the generic,
> which is not in the package, or do I need to do something different?
Method should be found correctly.
> 3/ In some packages I have functions that return an object defined in the
> suggested package being required. For example, a function does
> require("zoo") and then returns a zoo object. So, to work with the returned
> object I am really expecting that zoo will be available in the session
> afterwards. Is it recommended that I just check if the package is available
> on the search path the user has set rather than use require() or
> requireNamespace()?.
That may be a reasonable place to require(), in my opinion.
> 4/ I have a function in a package that Depends on DBI and suggests RMySQL,
> RPostgreSQL, RSQLite. The function uses dbDriver() in DBI which uses
> do.call(). If I use requireNamespace() in place of require() I get
>
>> requireNamespace("RMySQL")
> Loading required namespace: RMySQL
>> m <- dbDriver("MySQL")
> Error in do.call(as.character(drvName), list(...)) :
> could not find function "MySQL"
>
>> require("RMySQL")
> Loading required package: RMySQL
>> m <- dbDriver("MySQL")
>>
>
> Is there a different way to handle this without altering the search path?
I think it's best to do
m <- dbConnect(RMySQL::MySQL, ...)
and avoid do.call() where possible. (I'm pretty sure it is possible,
but it may require changes to the DBI backends), many of which assume
the package to be on the search path.
do.call() probably doesn't do what you think it does:
http://rpubs.com/hadley/do-call2
Hadley
--
http://had.co.nz/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] vegan moved to GitHub and vegan 2.2-0 is coming (are you ready?)
Dear vegan team, Vegan development happens now completely in github. R-Forge repository is no more in sync with github. I tried to commit all github changes to R-Forge, but a week ago I got a conflict in file and I haven't had time to resolve that conflict. You can follow vegan development and vegan discussion also without signing to github. The system seems to be completely open and does not require any user credentials (and this is good to remember when we discuss about things). The developer front page is https://github.com/vegandevs We have prepared for the vegan 2.2-0 release. This would be a major release that would close the gap between current development version and CRAN. I haven't set any firm date for the release, but I think R 3.2.0 will be out in October, and we should try to be concurrent with that -- in particular as the 2.0-10 in CRAN will give warnings in R check for that version. We have now solved a couple of major issues. - on technical side: the next R release will spit out tens of warnings for namespace issues (visibility of functions). These were solved in https://github.com/vegandevs/vegan/pull/28 - all vegan functions doing permutation are now based on Gav's permute package. This means that they can use any constrained permutation scheme of the permute package. This also concerns functions that earlier only had simple permutation. Of course, you do not need to use fancy permutation schemes, but the default is still simple permutation and this can be expressed by giving just the number of permutations on the command line. The functions using the new permutation scheme are adonis, anosim, anova.cca for CCA/RDA/dbRDA and hence also for ordistep etc., CCorA, envfit, mantel & mantel.partial, mrpp, mso, permutest.betadisper, permutest.cca, protest and simper. The change for functions is now complete, but same clean up and updating of documentation is still to be done. This is discussed in https://github.com/vegandevs/vegan/issues/31 - vegan 2.2-0 will also use parallel processing in several functions. This was already done in several functions in vegan development. The discussion on extending parallel processing to other functions was just opened in https://github.com/vegandevs/vegan/issues/36 . Currently the following functions can use parallel processing: adonis, anosim, anova.cca, mantel, mantel.partial, mrpp and simper can use it permutations, bioenv can asses several competing models in parallel, metaMDS can launch several random starts in parallel and oecosimu can use parallel processing in evaluating the statistics for null communities. If you compare this to the previous list of permutation functions, you see that the following permutation methods do not use parallel procesing: CCorA, envfit, mso, permutest.betadisper and protest. The question is if these also should be parallelized or can we leave them like they are, at least for the next release. - A more controversial issue is that Gav suggested moving rgl-based functions away from vegan to a separate package (https://github.com/vegandevs/vegan/issues/29 ). The main reason was that rgl can cause problems in several platforms and even prevent installing vegan. Indeed, when I tested these functions, they crashed in this Mac laptop. We have now a separate vegan3d package for these functions https://github.com/vegandevs/vegan3d . In addition to ordirgl + friends, rgl.isomap and rgl.renyiaccum it also has oriplot3d package. This package has now the same functionality as these functions had in vegan, and our purpose is to release that concurrently with vegan 2.2-0. I recently suggested to remove these functions from vegan, but we haven't made that change yet so that you can express your opinion on the move. See https://github.com/vegandevs/vegan/pull/37 There are some simpler and smaller things, but you can see those if you follow github. I have now mainly worked with my private fork of vegan and "pushed to vegan upstream" changes when they have looked more or less finished. At this stage, I have made a "pull request", and normally waited for possible comments. To get a second opinion, I have usually waited that Gav has a look at the functions and let him merge them to vegan. Sometimes there has been a long discussion before merge and we have edited the functions before the merge (e.g., https://github.com/vegandevs/vegan/pull/34 ). If changes are small and isolated bug fixes, I have pushed them directly to the vegan upstream, though. I have found this pretty good way of working in github. Cheers, Jari Oksanen __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
