You need R 3.4 for right now.
On Tue, Apr 5, 2016 at 1:16 PM, Karim Mezhoud <kmezh...@gmail.com> wrote:
==> R CMD INSTALL --no-multiarch --with-keep.source bioCancer
* installing to library
‘/Library/Frameworks/R.framework/Versions/3.3/Resources/library’
* installing *source* package ‘bioCancer’ ...
** R
** inst
** preparing package for lazy loading
Error in loadNamespace(i, c(lib.loc, .libPaths()), versionCheck =
vI[[i]]) :
there is no package called ‘c("dataTableOutput", "renderDataTable")’
ERROR: lazy loading failed for package ‘bioCancer’
* removing
‘/Library/Frameworks/R.framework/Versions/3.3/Resources/library/bioCancer’
* restoring previous
‘/Library/Frameworks/R.framework/Versions/3.3/Resources/library/bioCancer’
Exited with status 1
On Tue, Apr 5, 2016 at 8:58 PM, Michael Lawrence <
lawrence.mich...@gene.com>
wrote:
Yea, with the closing )
On Tue, Apr 5, 2016 at 12:37 PM, Karim Mezhoud <kmezh...@gmail.com>
wrote:
If I include manually the exception, I hve to write this?
import(shiny, except=c('dataTableOutput','renderDataTable')
Thanks
Karim
On Tue, Apr 5, 2016 at 7:28 PM, Michael Lawrence
<lawrence.mich...@gene.com>
wrote:
Roxygen does not yet support the feature. For now you'll have to live
with the warning or just importFrom(shiny, ...). Maybe there is some
way to manually patch the NAMESPACE with Roxygen?
Honestly, I would recommend against using Roxygen to manage your
NAMESPACE. Just write the thing...
On Tue, Apr 5, 2016 at 11:07 AM, Karim Mezhoud <kmezh...@gmail.com>
wrote:
Hi,
Actually I have conflict between DT and shiny
Warning: replacing previous import ‘shiny::dataTableOutput’ by
‘DT::dataTableOutput’ when loading ‘bioCancer’
Warning: replacing previous import ‘shiny::renderDataTable’ by
‘DT::renderDataTable’ when loading ‘bioCancer’
I would like to import shiny except dataTableOutput and
renderDataTable.
#'@import shiny except dataTableOutput renderDataTable
I am using roxygen2
R Under development (unstable) (2016-03-11 r70310)
Which package Can I update to get the new import argument.
Thanks
Karim
On Tue, Apr 5, 2016 at 6:50 PM, Michael Lawrence
<lawrence.mich...@gene.com>
wrote:
I will try to sneak that in since it seems to work and it would be
nice to use it before this Fall.
On Tue, Apr 5, 2016 at 10:32 AM, Dan Tenenbaum
<dtene...@fredhutch.org>
wrote:
Michael, do you know if this change will be (or has already
been)
backported into R-3.3.0?
Thanks.
Dan
----- Original Message -----
From: "Lihua Zhu" <julie....@umassmed.edu>
To: "Dan Tenenbaum" <dtene...@fredhutch.org>, "Michael
Lawrence"
<lawrence.mich...@gene.com>
Cc: "bioc-devel" <bioc-devel@r-project.org>
Sent: Tuesday, April 5, 2016 9:49:26 AM
Subject: Re: [Bioc-devel] namespace question
Dan,
That is great! Thanks for letting us know!
Michael, thank for making it happen so quickly! It works like a
charm!
Best,
Julie
On 4/2/16 1:58 PM, "Bioc-devel on behalf of Dan Tenenbaum"
<bioc-devel-boun...@r-project.org on behalf of
dtene...@fredhutch.org>
wrote:
BTW, looks like the change has been made to R-devel:
#### CHANGES IN R-devel NEW FEATURES
* The Œimport()¹ namespace directive now accepts an argument
Œexcept¹
which names symbols to exclude from the imports. The Œexcept¹
expression
should evaluate to a character vector (after substituting
symbols
for
strings). See Writing R Extensions.
URL:
https://urldefense.proofpoint.com/v2/url?u=http-3A__developer.r-2Dproject.
org_blosxom.cgi_R-2Ddevel_NEWS_2016_04_02-23n2016-2D04-2D02&d=BQIGaQ&c=WJB
j9sUF1mbpVIAf3biu3CPHX4MeRjY_w4DerPlOmhQ&r=3IbW-yoIQpGZOKgd4i2bgmPHhwHHF5g
JMlij5cC5bLU&m=HCJuUKMo50mOyjfD0AtQzV69c0SnACXTGdX_iHcWRfo&s=MbBj5lNGwkIfP
hrHI2clfQd1aq1yPyROa3utKrCP4ug&e=
----- Original Message -----
From: "Michael Lawrence" <lawrence.mich...@gene.com>
To: "Hervé Pagès" <hpa...@fredhutch.org>
Cc: "Michael Lawrence" <lawrence.mich...@gene.com>,
"bioc-devel"
<bioc-devel@r-project.org>
Sent: Saturday, April 2, 2016 4:10:10 AM
Subject: Re: [Bioc-devel] namespace question
Also, just btw, there are two other places where arbitrary R
code
can
be evaluated in the NAMESPACE, but no one has abused them
yet.
as
far
as I know. The first argument to if() and the .fixes argument
to
useDynLib(). The latter sets the precedent for the except=
behavior.
Although someone forgot to document it, you can do
.fixes=c("prefix",
"suffix") to both prefix and suffix incoming native symbols.
Currently, the documentation only mentions prefixing. Not
sure
when
suffixing would be desirable.
On Fri, Apr 1, 2016 at 4:14 PM, Hervé Pagès
<hpa...@fredhutch.org>
wrote:
On 04/01/2016 01:39 PM, Michael Lawrence wrote:
Yes, it's arbitrary R code that is evaluated, so paste0()
would
work.
You're right that it's a big door and could let people do
weird
things. Do you foresee a problem with that?
Opening such a big door raises many questions. In addition
to
allowing
people do weird/crazy things (like putting calls to
library()
or requireNamespace() etc... in them), NAMESPACE files with
arbitrary
R code in them become more complicated to maintain and the
tools
for
parsing/processing them also become more complicated to
write
and
maintain.
Now we have a new category of errors that can happen at
package
installation time: errors triggered by the evaluation of
the R
expressions embedded in the NAMESPACE file. Hopefully 'R CMD
INSTALL'
will report something that can be understood by mere mortals
when
this
happens.
Once you create the feeling that a NAMESPACE file is just a
file
that contains arbitrary R code then people expect import(),
export()
etc.. to be ordinary R functions with a man page (being able
to
do
?import would not hurt actually) and they'll naturally try
to
do
things like
unwanted_foo_symbols <- ... long and complicated
expression
eventually calling
user-defined
helper
functions located in the
NAMESPACE
file
...
import(foo, except=unwanted_foo_symbols)
Can't blame them for that. But is this the kind of things
that
we're
ready to see in NAMESPACE files?
Also once you've open that door, people will naturally
wonder
why
they
can use an R expression in the 'except' part of import( ,
except=)
but
not elsewhere e.g. in
import(foo, only=paste0("bar", 1:10))
as a more elegant way of doing importFrom(foo, bar1, bar2,
...,
bar10).
This dissymmetry between the syntax of "import only this"
and
"import
all except this" feels very arbitrary. If you don't support
the
import( , only=) syntax, people might legitimately ask
things
like
do.call(importFrom, c(list("foo"), as.list(paste0("bar",
1:10))))
to work. Again, can't blame them for that. But do we want
this
kind
of
things to work? I'm worried debugging NAMESPACE files would
become a
full-time job...
I guess one could have implemented NAMESPACE parsing by
evaluating
the
code in an environment (inheriting from the base namespace)
where
import(), export(), etc, were defined. Maybe there's a good
reason
why
it was not implemented that way.
I'm sure there is ;-)
H.
On Fri, Apr 1, 2016 at 12:55 PM, Hervé Pagès
<hpa...@fredhutch.org>
wrote:
On 03/31/2016 04:07 PM, Michael Lawrence wrote:
I agree. The importExcept idea also works that way:
importExcept(foo,
bar,
baz)
But import(foo, except=c(bar, baz)) reads better.
mmh... so R expressions with calls to base functions like
base::c()
are
making their way in the NAMESPACE file. That's opening a
big
door.
Does
that mean that we'll be able to do things like:
import(foo, except=paste0("bar", 1:10))
Or maybe c(bar, baz) in your above example is just an
arbitrary
syntax
that just happens to look like an R expression but won't
be
evaluated
as such?
H.
On Thu, Mar 31, 2016 at 4:00 PM, <
luke-tier...@uiowa.edu>
wrote:
I don't think you want to separate it from the import.
Better
to
allow
something like
import(foo, exclude=bar)
or
import(foo, exclude=c("bar", "baz"))
This seems reasonably natural and shouldn't be too hard
to
implement. (But is has been a while since I've worked on
this
code).
Best,
luke
On Thu, 31 Mar 2016, Karim Mezhoud wrote:
I think "From" is needed to specify which package we
want
to
exlude
functions.
I think excludeFrom (package, function) seems to be
intuitive.
thanks,
Karim
On Thu, Mar 31, 2016 at 9:54 PM, Hervé Pagès
<hpa...@fredhutch.org>
wrote:
On 03/31/2016 12:55 PM, Michael Lawrence wrote:
Probably should just stick to exact symbols for now.
If
there
is a
case where a pattern is actually useful, rather than
just
an
obfuscation, we can extend the feature set.
Fair enough. Not really intuitive that excludeImport
uses
the
same
syntax as (but does the opposite of) importFrom
though.
Maybe
having
the name of the directive start with "import" would
help
e.g.
importExcept(hash, values) # opposite of
importFrom(hash,
values)
Thanks,
H.
On Thu, Mar 31, 2016 at 12:11 PM, Zhu, Lihua (Julie)
<julie....@umassmed.edu> wrote:
Herve,
That is a very interesting idea and works for me!
Thanks!
importPatternFrom(IRanges, "^values$")
Best,
Julie
On 3/31/16 2:51 PM, "Bioc-devel on behalf of Hervé
Pagès"
<bioc-devel-boun...@r-project.org on behalf of
hpa...@fredhutch.org>
wrote:
On 03/30/2016 08:35 PM, Michael Lawrence wrote:
That would work, but R is not going to be happy
about
redundant
imports. Interactively, users would balk at symbol
qualification.
There are two classes of conflict:
1) Same semantics, where a common generic would
arbitrate,
or one
package could depend on the other, and
2) Different semantics, in which case one of the
functions
should
probably be renamed, although that might not be
practical
or
easy
to
agree upon.
When those approaches fail, qualification is the
only
recourse.
I will think about adding an excludeImport() or
importAs().
What about having something like an
importPatternFrom()
directive
similar to the exportPattern() directive and have
these
directives
support some of the grep() toggles like
'ignore.case',
'fixed',
'invert' etc... ?
Then Julie could just do:
importPatternFrom(hash, "^values$", invert=TRUE)
H.
On Wed, Mar 30, 2016 at 8:20 PM, Robert M. Flight
<rfligh...@gmail.com
wrote:
In the cases of having conflicting names, is it
not
appropriate
then
to use
the "package::function" form for calling a
particular
function?
On Wed, Mar 30, 2016 at 11:14 PM Michael Lawrence
<lawrence.mich...@gene.com>
wrote:
I can't find the hash function in IRanges. Are
you
sure
it
has
one?
On Wed, Mar 30, 2016 at 8:07 PM, Zhu, Lihua
(Julie)
<julie....@umassmed.edu> wrote:
Michael,
I have the same user case as Kasper. Another
example
is
that
both
IRanges
and hash packages have hash. I need to use the
hash
from
the
hash
package
instead of the one from IRanges.
Best,
Julie
On Mar 30, 2016, at 7:57 PM, Kasper Daniel
Hansen
<kasperdanielhan...@gmail.com> wrote:
My usecase is when I import() two packages who
has a
conflict
in
a
name.
For example, both Biobase and matrixStats has
both
anyMissing
and
rowMedians. I am happy to get all of these two
packages,
but I
need
to
resolve the conflict. Since I want to keep the
ones
from
matrixStats I
know
need to figure out how to import Biobase
selectively.
Which I
can,
using
the tools from codetoolsBioC, but I would also
be
happy
with
an
importFromExcept(), which would make my life
much
easier.
Best,
Kasper
On Wed, Mar 30, 2016 at 4:47 PM, Michael
Lawrence
<lawrence.mich...@gene.com> wrote:
I'm curious about which symbols you wouldn't
want
to
import,
and
why.
On Wed, Mar 30, 2016 at 12:19 PM, Zhu, Lihua
(Julie)
<julie....@umassmed.edu> wrote:
Hi,
Is there a function to import all the
exported
objects
from
a
package
except a few named ones in NAMESPACE file?
For example, I would like to import all the
functions
in
S4Vectors
except fold. Is there a way to specify this
without
listing
all
other
functions using importFrom?
Many thanks for your help!
Best regards,
Julie
********************************************
Lihua Julie Zhu, Ph.D
Research Professor
Department of Molecular, Cell and Cancer
Biology
(MCCB)
Head of MCCB Bioinformatics Core
Program in Molecular Medicine
Program in Bioinformatics and Integrative
Biology
University of Massachusetts Medical School
364 Plantation Street, Room 613
Worcester, MA 01605
508-856-5256 phone
(508) 856 5460 fax
http://profiles.umassmed.edu/profiles/ProfileDetails.aspx?Fr
om=SE&Perso
n=1134
[[alternative HTML version
deleted]]
_______________________________________________
Bioc-devel@r-project.org mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat
.ethz.ch_ma
ilman_listinfo_bioc-2Ddevel&d=BQIF-g&c=WJBj9sUF1mbpVIAf3b
iu3CPHX4MeR
jY_w4DerPlOmhQ&r=3IbW-yoIQpGZOKgd4i2bgmPHhwHHF5gJMlij5cC5
bLU&m=Rxzbh
vEdYoq-VrN42rfiK5-UIIwjUIHLTQjy9s7-pzs&s=TmgPkRkAcsTjcIVv
zaBFADs-tx8
CzeHHAAJ5kmgmJxQ&e=
_______________________________________________
Bioc-devel@r-project.org mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.
ethz.ch_mai
lman_listinfo_bioc-2Ddevel&d=BQIF-g&c=WJBj9sUF1mbpVIAf3biu
3CPHX4MeRjY
_w4DerPlOmhQ&r=3IbW-yoIQpGZOKgd4i2bgmPHhwHHF5gJMlij5cC5bLU
&m=RxzbhvEd
Yoq-VrN42rfiK5-UIIwjUIHLTQjy9s7-pzs&s=TmgPkRkAcsTjcIVvzaBF
ADs-tx8CzeH
HAAJ5kmgmJxQ&e=
_______________________________________________
Bioc-devel@r-project.org mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.et
hz.ch_mailm
an_listinfo_bioc-2Ddevel&d=BQIF-g&c=WJBj9sUF1mbpVIAf3biu3CPH
X4MeRjY_w4D
erPlOmhQ&r=3IbW-yoIQpGZOKgd4i2bgmPHhwHHF5gJMlij5cC5bLU&m=Rxz
bhvEdYoq-Vr
N42rfiK5-UIIwjUIHLTQjy9s7-pzs&s=TmgPkRkAcsTjcIVvzaBFADs-tx8C
zeHHAAJ5kmg
mJxQ&e=
[[alternative HTML version deleted]]
_______________________________________________
Bioc-devel@r-project.org mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.eth
z.ch_mailma
n_listinfo_bioc-2Ddevel&d=BQIF-g&c=WJBj9sUF1mbpVIAf3biu3CPHX4
MeRjY_w4Der
PlOmhQ&r=3IbW-yoIQpGZOKgd4i2bgmPHhwHHF5gJMlij5cC5bLU&m=Rxzbhv
EdYoq-VrN42
rfiK5-UIIwjUIHLTQjy9s7-pzs&s=TmgPkRkAcsTjcIVvzaBFADs-tx8CzeHH
AAJ5kmgmJxQ
&e=
_______________________________________________
Bioc-devel@r-project.org mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz
.ch_mailman
_listinfo_bioc-2Ddevel&d=BQIF-g&c=WJBj9sUF1mbpVIAf3biu3CPHX4Me
RjY_w4DerPl
OmhQ&r=3IbW-yoIQpGZOKgd4i2bgmPHhwHHF5gJMlij5cC5bLU&m=RxzbhvEdY
oq-VrN42rfi
K5-UIIwjUIHLTQjy9s7-pzs&s=TmgPkRkAcsTjcIVvzaBFADs-tx8CzeHHAAJ5
kmgmJxQ&e=
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fredhutch.org
Phone: (206) 667-5791
Fax: (206) 667-1319
_______________________________________________
Bioc-devel@r-project.org mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.
ch_mailman_
listinfo_bioc-2Ddevel&d=BQIF-g&c=WJBj9sUF1mbpVIAf3biu3CPHX4MeRj
Y_w4DerPlOm
hQ&r=3IbW-yoIQpGZOKgd4i2bgmPHhwHHF5gJMlij5cC5bLU&m=RxzbhvEdYoq-
VrN42rfiK5-
UIIwjUIHLTQjy9s7-pzs&s=TmgPkRkAcsTjcIVvzaBFADs-tx8CzeHHAAJ5kmgm
JxQ&e=
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fredhutch.org
Phone: (206) 667-5791
Fax: (206) 667-1319
_______________________________________________
Bioc-devel@r-project.org mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_
mailman_listinfo_bioc-2Ddevel&d=BQIGaQ&c=WJBj9sUF1mbpVIAf3biu3CPHX
4MeRjY_w4DerPlOmhQ&r=3IbW-yoIQpGZOKgd4i2bgmPHhwHHF5gJMlij5cC5bLU&m
=HCJuUKMo50mOyjfD0AtQzV69c0SnACXTGdX_iHcWRfo&s=p71c2AdbK9otl8LEvj9
xsiK9LzQrQsm-onyqG3WBgMI&e=
[[alternative HTML version deleted]]
_______________________________________________
Bioc-devel@r-project.org mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_m
ailman_listinfo_bioc-2Ddevel&d=BQIGaQ&c=WJBj9sUF1mbpVIAf3biu3CPHX4M
eRjY_w4DerPlOmhQ&r=3IbW-yoIQpGZOKgd4i2bgmPHhwHHF5gJMlij5cC5bLU&m=HC
JuUKMo50mOyjfD0AtQzV69c0SnACXTGdX_iHcWRfo&s=p71c2AdbK9otl8LEvj9xsiK
9LzQrQsm-onyqG3WBgMI&e=
--
Luke Tierney
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa Phone:
319-335-3386
Department of Statistics and Fax:
319-335-3017
Actuarial Science
241 Schaeffer Hall email:
luke-tier...@uiowa.edu
Iowa City, IA 52242 WWW:
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.stat.uiowa.e
du&d=BQIGaQ&c=WJBj9sUF1mbpVIAf3biu3CPHX4MeRjY_w4DerPlOmhQ&r=3IbW-yoI
QpGZOKgd4i2bgmPHhwHHF5gJMlij5cC5bLU&m=HCJuUKMo50mOyjfD0AtQzV69c0SnAC
XTGdX_iHcWRfo&s=sdr2IWlza633ZolLOZbEolvEybKmaHQFU5gIt8R8A7A&e=
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fredhutch.org
Phone: (206) 667-5791
Fax: (206) 667-1319
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fredhutch.org
Phone: (206) 667-5791
Fax: (206) 667-1319
_______________________________________________
Bioc-devel@r-project.org mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman
_listinfo_bioc-2Ddevel&d=BQIGaQ&c=WJBj9sUF1mbpVIAf3biu3CPHX4MeRjY_w4DerPl
OmhQ&r=3IbW-yoIQpGZOKgd4i2bgmPHhwHHF5gJMlij5cC5bLU&m=HCJuUKMo50mOyjfD0AtQ
zV69c0SnACXTGdX_iHcWRfo&s=p71c2AdbK9otl8LEvj9xsiK9LzQrQsm-onyqG3WBgMI&e=
_______________________________________________
Bioc-devel@r-project.org mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_
listinfo_bioc-2Ddevel&d=BQIGaQ&c=WJBj9sUF1mbpVIAf3biu3CPHX4MeRjY_w4DerPlOm
hQ&r=3IbW-yoIQpGZOKgd4i2bgmPHhwHHF5gJMlij5cC5bLU&m=HCJuUKMo50mOyjfD0AtQzV6
9c0SnACXTGdX_iHcWRfo&s=p71c2AdbK9otl8LEvj9xsiK9LzQrQsm-onyqG3WBgMI&e=
_______________________________________________
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
