Re: [Rd] Is this a bug in `[`?

[Rui Barradas]

Hello,

Thanks for the pointer.
Inline.

On 29/08/2018 04:17, Henrik Bengtsson wrote:

FYI, this behavior is documented in Section 3.4.1 'Indexing by
vectors' of 'R Language Definition' (accessible for instance via
help.start()):

"*Integer* [...] A special case is the zero index, which has null
effects: x[0] is an empty vector and otherwise including zeros among
positive or negative indices has the same effect as if they were
omitted."



So I was in part right, the zero index is handled as a special case.
My use case was an operation in a function. I wasn't testing whether the 
result was of length zero, I was just using seq_len(result) to avoid the 
test. And found the error surprising.


Thanks again,

Rui Barradas



The rest of that section is very useful and well written. I used it as
the go-to reference to implement support for all those indexing
alternatives in matrixStats.

/Henrik
On Sun, Aug 5, 2018 at 3:42 AM Iñaki Úcar  wrote:


El dom., 5 ago. 2018 a las 6:27, Kenny Bell () escribió:


This should more clearly illustrate the issue:

c(1, 2, 3, 4)[-seq_len(4)]
#> numeric(0)
c(1, 2, 3, 4)[-seq_len(3)]
#> [1] 4
c(1, 2, 3, 4)[-seq_len(2)]
#> [1] 3 4
c(1, 2, 3, 4)[-seq_len(1)]
#> [1] 2 3 4
c(1, 2, 3, 4)[-seq_len(0)]
#> numeric(0)
Created on 2018-08-05 by the reprex package (v0.2.0.9000).


IMO, the problem is that you are reading it sequentially: "-" remove
"seq_" a sequence "len(0)" of length zero. But that's not how R works
(how programming languages work in general). Instead, the sequence is
evaluated in the first place, and then the sign may apply as long as
you provided something that can hold a sign. And an empty element has
no sign, so the sign is lost.

Iñaki



On Sun, Aug 5, 2018 at 3:58 AM Rui Barradas  wrote:




Às 15:51 de 04/08/2018, Iñaki Úcar escreveu:

El sáb., 4 ago. 2018 a las 15:32, Rui Barradas
() escribió:


Hello,

Maybe I am not understanding how negative indexing works but

1) This is right.

(1:10)[-1]
#[1]  2  3  4  5  6  7  8  9 10

2) Are these right? They are at least surprising to me.

(1:10)[-0]
#integer(0)

(1:10)[-seq_len(0)]
#integer(0)


It was the last example that made me ask, seq_len(0) whould avoid an
if/else or something similar.


I think it's ok, because there is no negative zero integer, so -0 is 0.


Ok, this makes sense, I should have thought about that.



1.0/-0L # Inf
1.0/-0.0 # - Inf

And the same can be said for integer(0), which is the result of
seq_len(0): there is no negative empty integer.


I'm not completely convinced about this one, though.
I would expect -seq_len(n) to remove the first n elements from the
vector, therefore, when n == 0, it would remove none.

And integer(0) is not the same as 0.

(1:10)[-0] == (1:10)[0] == integer(0) # empty

(1:10)[-seq_len(0)] == (1:10)[-integer(0)]


And I have just reminded myself to run

identical(-integer(0), integer(0))

It returns TRUE so my intuition is wrong, R is right.
End of story.

Thanks for the help,

Rui Barradas



Iñaki




Thanks in advance,

Rui Barradas

__
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



---
This email has been checked for viruses by AVG.
https://www.avg.com

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

Re: [Rd] Is this a bug in `[`?

[Henrik Bengtsson]

FYI, this behavior is documented in Section 3.4.1 'Indexing by
vectors' of 'R Language Definition' (accessible for instance via
help.start()):

"*Integer* [...] A special case is the zero index, which has null
effects: x[0] is an empty vector and otherwise including zeros among
positive or negative indices has the same effect as if they were
omitted."

The rest of that section is very useful and well written. I used it as
the go-to reference to implement support for all those indexing
alternatives in matrixStats.

/Henrik
On Sun, Aug 5, 2018 at 3:42 AM Iñaki Úcar  wrote:
>
> El dom., 5 ago. 2018 a las 6:27, Kenny Bell () escribió:
> >
> > This should more clearly illustrate the issue:
> >
> > c(1, 2, 3, 4)[-seq_len(4)]
> > #> numeric(0)
> > c(1, 2, 3, 4)[-seq_len(3)]
> > #> [1] 4
> > c(1, 2, 3, 4)[-seq_len(2)]
> > #> [1] 3 4
> > c(1, 2, 3, 4)[-seq_len(1)]
> > #> [1] 2 3 4
> > c(1, 2, 3, 4)[-seq_len(0)]
> > #> numeric(0)
> > Created on 2018-08-05 by the reprex package (v0.2.0.9000).
>
> IMO, the problem is that you are reading it sequentially: "-" remove
> "seq_" a sequence "len(0)" of length zero. But that's not how R works
> (how programming languages work in general). Instead, the sequence is
> evaluated in the first place, and then the sign may apply as long as
> you provided something that can hold a sign. And an empty element has
> no sign, so the sign is lost.
>
> Iñaki
>
> >
> > On Sun, Aug 5, 2018 at 3:58 AM Rui Barradas  wrote:
> >>
> >>
> >>
> >> Às 15:51 de 04/08/2018, Iñaki Úcar escreveu:
> >> > El sáb., 4 ago. 2018 a las 15:32, Rui Barradas
> >> > () escribió:
> >> >>
> >> >> Hello,
> >> >>
> >> >> Maybe I am not understanding how negative indexing works but
> >> >>
> >> >> 1) This is right.
> >> >>
> >> >> (1:10)[-1]
> >> >> #[1]  2  3  4  5  6  7  8  9 10
> >> >>
> >> >> 2) Are these right? They are at least surprising to me.
> >> >>
> >> >> (1:10)[-0]
> >> >> #integer(0)
> >> >>
> >> >> (1:10)[-seq_len(0)]
> >> >> #integer(0)
> >> >>
> >> >>
> >> >> It was the last example that made me ask, seq_len(0) whould avoid an
> >> >> if/else or something similar.
> >> >
> >> > I think it's ok, because there is no negative zero integer, so -0 is 0.
> >>
> >> Ok, this makes sense, I should have thought about that.
> >>
> >> >
> >> > 1.0/-0L # Inf
> >> > 1.0/-0.0 # - Inf
> >> >
> >> > And the same can be said for integer(0), which is the result of
> >> > seq_len(0): there is no negative empty integer.
> >>
> >> I'm not completely convinced about this one, though.
> >> I would expect -seq_len(n) to remove the first n elements from the
> >> vector, therefore, when n == 0, it would remove none.
> >>
> >> And integer(0) is not the same as 0.
> >>
> >> (1:10)[-0] == (1:10)[0] == integer(0) # empty
> >>
> >> (1:10)[-seq_len(0)] == (1:10)[-integer(0)]
> >>
> >>
> >> And I have just reminded myself to run
> >>
> >> identical(-integer(0), integer(0))
> >>
> >> It returns TRUE so my intuition is wrong, R is right.
> >> End of story.
> >>
> >> Thanks for the help,
> >>
> >> Rui Barradas
> >>
> >> >
> >> > Iñaki
> >> >
> >> >>
> >> >>
> >> >> Thanks in advance,
> >> >>
> >> >> Rui Barradas
> >> >>
> >> >> __
> >> >> 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] ROBUSTNESS: x || y and x && y to give warning/error if length(x) != 1 or length(y) != 1

[Henrik Bengtsson]

# Issue

'x || y' performs 'x[1] || y' for length(x) > 1.  For instance (here
using R 3.5.1),

> c(TRUE, TRUE) || FALSE
[1] TRUE
> c(TRUE, FALSE) || FALSE
[1] TRUE
> c(TRUE, NA) || FALSE
[1] TRUE
> c(FALSE, TRUE) || FALSE
[1] FALSE

This property is symmetric in LHS and RHS (i.e. 'y || x' behaves the
same) and it also applies to 'x && y'.

Note also how the above truncation of 'x' is completely silent -
there's neither an error nor a warning being produced.


# Discussion/Suggestion

Using 'x || y' and 'x && y' with a non-scalar 'x' or 'y' is likely a
mistake.  Either the code is written assuming 'x' and 'y' are scalars,
or there is a coding error and vectorized versions 'x | y' and 'x & y'
were intended.  Should 'x || y' always be considered an mistake if
'length(x) != 1' or 'length(y) != 1'?  If so, should it be a warning
or an error?  For instance,
'''r
> x <- c(TRUE, TRUE)
> y <- FALSE
> x || y

Error in x || y : applying scalar operator || to non-scalar elements
Execution halted

What about the case where 'length(x) == 0' or 'length(y) == 0'?  Today
'x || y' returns 'NA' in such cases, e.g.

> logical(0) || c(FALSE, NA)
[1] NA
> logical(0) || logical(0)
[1] NA
> logical(0) && logical(0)
[1] NA

I don't know the background for this behavior, but I'm sure there is
an argument behind that one.  Maybe it's simply that '||' and '&&'
should always return a scalar logical and neither TRUE nor FALSE can
be returned.

/Henrik

PS. This is in the same vein as
https://mailman.stat.ethz.ch/pipermail/r-devel/2017-March/073817.html
- in R (>=3.4.0) we now get that if (1:2 == 1) ... is an error if
_R_CHECK_LENGTH_1_CONDITION_=true

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

Re: [R-pkg-devel] New test in R-devel causes existing packages to fail: "Error: connections left open"

[David B. Dahl]

Okay, Uwe, I will close the connection between examples.  Thanks Henrik,
Duncan, Gabor, and Uwe for participating in the discussion.

-- David

On Mon, Aug 27, 2018 at 4:47 PM Uwe Ligges 
wrote:
>
> I still do not undertsand why you cannot stop scala and related
> connections at the end of each example. You can insert a comment that
> this is not needed if you have follow up tasks for scala.
>
> Best,
> Uwe
>
> On 27.08.2018 07:14, David B. Dahl wrote:
> > Henrik,
> >
> > Thanks for the suggest.  Yes, definitely, I think your more nuanced
> > test would be a big improvement.  The only wrinkle is that the
> > connection is established *not* when the package is *loaded* but
> > rather when the connection is *first needed* (using delayedAssign when
> > the package is loaded).  That way, loading the package doesn't block
> > the REPL for ~5 seconds while Scala and the JVM first start.
> >
> > -- David
> >
> > On Thu, Aug 23, 2018 at 11:19 PM Henrik Bengtsson
> >  wrote:
> >>
> >> Does R CMD check --as-cran test for newly opened connections or any
> >> open connections?  Could the check for stray connection in
> >> examples/vignettes be:
> >>
> >> 1. Record what connections are open
> >> 2. Attach the package
> >> 3. Record what connections are open
> >> 4. Run the example
> >> 5. Assert that no *new* connections in addition to what's recorded in
> >> Step 3 are open
> >> 6. Unload the package
> >> 7. Assert that no *new* connections in addition to what's recorded in
> >> Step 1 are open
> >>
> >> Step 5 asserts that the code in the example does not leave stray
> >> connections behind, and Step 7 that the package itself does not leave
> >> stray connections behind.
> >>
> >> /Henrik
> >> On Thu, Aug 23, 2018 at 1:25 PM David B. Dahl 
wrote:
> >>>
> >>> Oops, I accidentally did not "reply-all" Here is my message:
> >>>
> >>> Thanks Uwe, Duncan, and Gabor for the response, advise, and
flexibility.
> >>>
> >>> Regarding Uwe's suggestion:  "... there should be a function that
> >>> creates the connction and one that closes the connection," I should
> >>> clarify.  The rscala package does just that.  There is a function
> >>> (named "scala") that creates the connection (using delayedAssign) and
> >>> another the closes the function (namely an S3 close method).  The
> >>> examples for the rscala package do this full open/close semantics,
> >>> but...
> >>>
> >>> The problem comes when authors of another package, let's call it the
> >>> "FooBar" package, want to implement an algorithm in Scala based on
> >>> functionality provided by the rscala package.  Let's say they write a
> >>> function called "neatAlgorithm" based on Scala.  Yes, the FooBar
> >>> package author could require that, before the user calls the
> >>> "neatAlgorithm" function, they first call a function to set up the
> >>> connection (which itself would call the "rscala::scala" function) and
> >>> then, after calling the "neatAlgorithm" function, they call a function
> >>> to close the connection.
> >>>
> >>> But that is not very user friendly and exposes the user to
> >>> implementation details of the algorithm.  The user of the FooBar
> >>> package don't really care whether the "neatAlgorithm" is implemented
> >>> in pure R, C++, Scala, or whatever, much like the users of the 'lm'
> >>> function don't need to know the implementation details or do any setup
> >>> before and after calling the function.
> >>>
> >>> The current approach is that the connection to Scala is transparent to
> >>> the end user of a package.  Behind the scenes, the package author
> >>> establish the connection once it is needed and the rscala package
> >>> manages the connection and explicitly closes it when 1. the package is
> >>> unloaded or 2. the R session ends.  This approach does not leave
> >>> dangling connections  --- which I believe is the point of the new test
> >>> --- yet my package is caught up in the test.
> >>>
> >>> I hope that this approach is still valid.  Perhaps the test could
> >>> result in a warning (instead of an error) and CRAN could accept
> >>> packages with such a warning.
> >>>
> >>> If not, a work-around is to have a \dontshow section in the examples
> >>> that will close the connection (but leave the Scala process running)
> >>> and then automatically reestablish the connection as needed.  This
> >>> would not be very efficient but, as Duncan mentioned, it mostly only
> >>> effects the package examples themselves.  Plus, it would not be too
> >>> burdensome for package developers.
> >>>
> >>> Again, thanks for considering my situation.
> >>>
> >>> Best regards,
> >>>
> >>> -- David
> >>>
> >>> On Mon, Aug 20, 2018 at 11:11 PM Uwe Ligges
> >>>  wrote:
> 
>  My advise:
> 
>  Apparently you want to have communication via sockets to scala.
> 
>  So there should be a function that creates the connction and one tha
>  closes the connection.
>  Comparable to starting some parallel cluster and stopping it again.
> 

Re: [R-pkg-devel] Trying to work around missing functionality

[J C Nash]

Thanks for this. Also Duncan's description of how code in the R directory is 
executed.

I've more or less figured out a workaround. Unfortunately Georgi's solution 
doesn't quite
do the trick. Here is my current understanding and solution.

Issue: I want to get root of a function of 1 parameter x, but there may be 
exogenous data Xdata.
   I also want to count the evaluations.
   Some rootfinders don't have counter and some don't allow "..."

Initial solution: Create global envroot with counters and such. Put name of 
function and
gradient in there, then use a dummy FnTrace (and possibly grTrace). This gave 
various
check complaints about globals etc. However, does appear to work.

Present approach: Slightly less flexible, but no complaints.
   Within rootwrap() which calls different rootfinders according to 
method="name", define
   FnTrace and grTrace, set up a list glist for the items I want to share, then
   envroot <- list2env(glist)

The FnTrace and grTrace are defined before the calls to rootfinders, so envroot 
can be found.
No globals. R CMD check is happy. However, I must call rootfinders via the 
wrapper, which is
actually simpler from point of view of syntax.

I've still some testing and tweaking, but I think main issues resolved by this.

Thanks to all who responded.

JN







On 2018-08-28 12:27 PM, Georgi Boshnakov wrote:
> If you don't insist on putting the variable in the global environment, 
> variations of the following give a cleaner solution:
> 
> TraceSetup_1 <- local({
> ifn = 0
> igr = 0
> ftrace = FALSE
> fn = NA
> gr = NA
> 
> function(ifn=0, igr=0, ftrace=FALSE, fn=NA, gr=NA){
> ifn<<- ifn
> igr<<- igr
> ftrace <<- ftrace
> fn <<- fn
> gr <<- gr
> parent.env(environment())
> }
> })
> 
> For example,
> 
> TraceSetup_1 <- local({
> + ifn = 0
> + igr = 0
> + ftrace = FALSE
> + fn = NA
> + gr = NA
> + function(ifn=0, igr=0, ftrace=FALSE, fn=NA, gr=NA){
> + ifn<<- ifn
> + igr<<- igr
> + ftrace <<- ftrace
> + fn <<- fn
> + gr <<- gr
> + parent.env(environment())
> + }
> + })
>>
>> e <- TraceSetup_1(fn = function(x) x^2)
>> ls(e)
> [1] "fn" "ftrace" "gr" "ifn""igr"   
>> e$fn
> function(x) x^2
> 
> ## let's change 'fn':
>> e$fn <- function(x) x^4
>> e$fn
> function(x) x^4
> 
> 
> Note that the environment is always the same, so can be accessed from 
> anywhere in your code:
> 
>> e2 <- environment(TraceSetup_1)
>> e2
> 
>> identical(e2, e)
> [1] TRUE
>>
> 
> If you need a new environment every time, a basic setup might be:
> 
> TraceSetup_2 <- local({
> staticVar1 <- NULL
> ## other variables here
> 
> function(ifn=0, igr=0, ftrace=FALSE, fn=NA, gr=NA){
> ## force evaluation of the arguments
> ifn
> igr
> ftrace 
> fn 
> gr 
> environment()
> }
> })
> 
> There is no need for local() here but usually one needs also some static 
> variables.
> Now every call gives a different environment  (but all have the same parent):
> 
> ea <- TraceSetup_2(fn = function(x) x^2 - 2*x + 1)
>> ls(ea)
> [1] "fn" "ftrace" "gr" "ifn""igr"   
>> ea$fn
> function(x) x^2 - 2*x + 1
>>
>> eb <- TraceSetup_2(fn = function(x) x^2 + 1)
>> eb$fn
> function(x) x^2 + 1
>>
>> ## ea$fn is still the same:
>> ea$fn
> function(x) x^2 - 2*x + 1
>>
> 
> Obviously, in this case some further arrangements are  needed for the 
> environments to be made available to the external world.
> 
> Hope this helps,
> Georgi Boshnakov
> 
> 
> -Original Message-
> From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On 
> Behalf Of J C Nash
> Sent: 28 August 2018 14:18
> To: Fox, John; Richard M. Heiberger
> Cc: List r-package-devel
> Subject: Re: [R-pkg-devel] Trying to work around missing functionality
> 
> Indeed, it appears that globalVariables must be outside the function. 
> However, I had quite a bit of
> fiddle to get things to work without errors or warnings or notes. While I now 
> have a package that
> does not complain with R CMD check, I am far from satisfied that I can give a 
> prescription. I had
> to remove lines in the rootfinder like
>envroot$fn <- fn
> that were used to set the function to be used inside my instrumented 
> function, and instead
> call TraceSetup(fn=fn, ...) where a similar statement was given. Why that 
> worked while the direct
> assignment (note, not a <<- one) did not, I do not understand. However, I 
> will work with this for
> a while and try to get a better handle on it.
> 
> Thanks for the pointer. As an old-time programmer from days when you even set 
> the add table, I'm
> still uncomfortable just putting code in a directory and assuming it will be 
> executed, i.e., the
> globals.R file. However, I now have this set to establish the global 
> structure as 

Re: [Bioc-devel] Help with class lost after subsetting.

[Hervé Pagès]

On 08/28/2018 11:46 AM, Hervé Pagès wrote:

On 08/27/2018 11:01 PM, Martin Morgan wrote:



On 08/28/2018 12:19 AM, Charles Plessy wrote:

Dear Bioconductor developers,

In the CAGEr package, I created a "CAGEexp" class that extends
"MultiAssayExperiment" without adding new slots, in order to define 
generic

functions that require CAGEr-specific contents in the colData slot.

Unfortunately, when run in the development branch of Bioconductor,
the CAGEexp objects lose their class when they are subsetted.  Here
is an example:


CAGEr::exampleCAGEexp

A CAGEexp object of 4 listed
(...)


CAGEr::exampleCAGEexp[,1]

A MultiAssayExperiment object of 4 listed
(...)

This breaks examples in the package, as well as existing code.

I am lost on how to troubleshoot this.  May I ask for your help ?


I debugged this using first `selectMethod("[", 
"MultiAssayExperiment")` and then `showMethod()` / `selectMethod()` to 
arrive at `subsetByColData,MultiAssayExperiment,ANY-method`.


The problem is that this line

https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_waldronlab_MultiAssayExperiment_blob_master_R_subsetBy-2Dmethods.R-23L261=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=BFHgkPpGkkRZx_me9V6pN2aTIxXYDgkUBG5jJTKLugc=6XrUMqkUrT5cepxjwAwSXVXdjOeyRdWAjdpGaasVqc0= 



returns a MultiAssayExperiment; what it should do is probably closer 
to the 'copy constructor' functionality of `initialize()`, along the 
lines of


   initialize(x, ExperimentList = ..., )

This could be opened as an issue on the MultiAssayExperiment github 
repository; maybe Herve or Michael or others might comment on the best 
implementation.


Yep. Personally I tend to prefer BiocGenerics:::replaceSlots()
over initialize() because the former can be called with check=FALSE
in order to skip a possibly expensive validation. So:

     BiocGenerics:::replaceSlots(x
     ExperimentList = harmon[["experiments"]],
     colData = harmon[["colData"]],
     sampleMap = harmon[["sampleMap"]],
     metadata = metadata(x),
     check = FALSE)

If you know that the replacement values are valid (because of the way
you prepared them), then validation should not be needed.

Also when only **some** of the slots are updated (which is not the
case in the above example where all the slots are being replaced),


ERRATA: It seems that MultiAssayExperiment have one more slot,
the "drops" slot, that the code above does not modify so this would
be one more reason IMO to use BiocGenerics:::replaceSlots() instead
of something like initialize(x, ExperimentList = ..., ) or
new(class(x),ExperimentList = ..., ).

H.


I find that the use of initialize() is misleading from a readability
point of view.

See 
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_pipermail_bioc-2Ddevel_2017-2DSeptember_011496.html=DwIFaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=OlbCmHfOSsvIe5QU8cUQjnV7NeLHnJ9GndGatxMWmXQ=fV9PeZDYz9qEIxeLk00LcjpNNgzQy_kzi6aFEKBvlds= 


for a discussion about this about 1 year ago.

H.



Martin



Best regards,



___
Bioc-devel@r-project.org mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=BFHgkPpGkkRZx_me9V6pN2aTIxXYDgkUBG5jJTKLugc=Xa6tx2WwH603kmeR7WiV1PLMBM3myI5fUfjLL6WkMmU= 





--
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://stat.ethz.ch/mailman/listinfo/bioc-devel

[Rd] "utils::file.edit" does not understand "editor" with additional arguments

[Randy Lai]

I am using Sublime Text as my editor. If I run `subl -n .Rprofile` in bash, a 
file would be opened in a new window.

Back in R, if I run this

> file.edit(".Rprofile", editor="'subl -n'")
sh: 'subl -n': command not found
Warning message:
error in running command

However, the interesting bit happens when I run

edit(1:10, editor="'subl -n’")

It does open Sublime Text. It seems that `file.edit` and `edit` are behaving 
differently when “editor” has additional arguments.

Randy


signature.asc
Description: Message signed with OpenPGP
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Bioc-devel] Help with class lost after subsetting.

[Hervé Pagès]

On 08/27/2018 11:01 PM, Martin Morgan wrote:



On 08/28/2018 12:19 AM, Charles Plessy wrote:

Dear Bioconductor developers,

In the CAGEr package, I created a "CAGEexp" class that extends
"MultiAssayExperiment" without adding new slots, in order to define 
generic

functions that require CAGEr-specific contents in the colData slot.

Unfortunately, when run in the development branch of Bioconductor,
the CAGEexp objects lose their class when they are subsetted.  Here
is an example:


CAGEr::exampleCAGEexp

A CAGEexp object of 4 listed
(...)


CAGEr::exampleCAGEexp[,1]

A MultiAssayExperiment object of 4 listed
(...)

This breaks examples in the package, as well as existing code.

I am lost on how to troubleshoot this.  May I ask for your help ?


I debugged this using first `selectMethod("[", "MultiAssayExperiment")` 
and then `showMethod()` / `selectMethod()` to arrive at 
`subsetByColData,MultiAssayExperiment,ANY-method`.


The problem is that this line

https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_waldronlab_MultiAssayExperiment_blob_master_R_subsetBy-2Dmethods.R-23L261=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=BFHgkPpGkkRZx_me9V6pN2aTIxXYDgkUBG5jJTKLugc=6XrUMqkUrT5cepxjwAwSXVXdjOeyRdWAjdpGaasVqc0= 



returns a MultiAssayExperiment; what it should do is probably closer to 
the 'copy constructor' functionality of `initialize()`, along the lines of


   initialize(x, ExperimentList = ..., )

This could be opened as an issue on the MultiAssayExperiment github 
repository; maybe Herve or Michael or others might comment on the best 
implementation.


Yep. Personally I tend to prefer BiocGenerics:::replaceSlots()
over initialize() because the former can be called with check=FALSE
in order to skip a possibly expensive validation. So:

BiocGenerics:::replaceSlots(x
ExperimentList = harmon[["experiments"]],
colData = harmon[["colData"]],
sampleMap = harmon[["sampleMap"]],
metadata = metadata(x),
check = FALSE)

If you know that the replacement values are valid (because of the way
you prepared them), then validation should not be needed.

Also when only **some** of the slots are updated (which is not the
case in the above example where all the slots are being replaced),
I find that the use of initialize() is misleading from a readability
point of view.

See https://stat.ethz.ch/pipermail/bioc-devel/2017-September/011496.html
for a discussion about this about 1 year ago.

H.



Martin



Best regards,



___
Bioc-devel@r-project.org mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=BFHgkPpGkkRZx_me9V6pN2aTIxXYDgkUBG5jJTKLugc=Xa6tx2WwH603kmeR7WiV1PLMBM3myI5fUfjLL6WkMmU= 



--
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://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Logolas package broken for R (3.4) users

[Obenchain, Valerie]

You could use an AMI with R 3.4 installed. See the 'AMI IDs' section:

https://www.bioconductor.org/help/bioconductor-cloud-ami/#ami_ids

Valerie


On 08/27/2018 11:48 AM, kushal kumar dey wrote:

Hi,

I just found based on user reports that the old version of my package
Logolas for R 3.4 and Bioc 3.6 is broken. It does install fine but the main
function does not run. Everything seems to be fine however for R 3.5 and
Bioc 3.7. I would like to produce either an error message if someone < R
3.5 tries to install Logolas, or to mend the old version. Can you please
let me know what is the procedure for either of these cases?

Thanks so much.

Kushal





This email message may contain legally privileged and/or confidential 
information.  If you are not the intended recipient(s), or the employee or 
agent responsible for the delivery of this message to the intended 
recipient(s), you are hereby notified that any disclosure, copying, 
distribution, or use of this email message is prohibited.  If you have received 
this message in error, please notify the sender immediately by e-mail and 
delete this email message from your computer. Thank you.
[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] updating development version package

[Shepherd, Lori]

You need to push any associated changes to the Bioconductor git server.

See the help pages found here:

http://bioconductor.org/developers/how-to/git/



Lori Shepherd

Bioconductor Core Team

Roswell Park Cancer Institute

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Bioc-devel  on behalf of 
zzric...@gmail.com 
Sent: Tuesday, August 28, 2018 12:46:03 PM
To: bioc-devel@r-project.org
Subject: [Bioc-devel] updating development version package

Hi There,

I need to make a few minor change to my INDEED package, which has already
been accepted. I want to know if I need to do anything other than modify
the codes and bump up the version number.

Thanks
ZL

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel


This email message may contain legally privileged and/or confidential 
information.  If you are not the intended recipient(s), or the employee or 
agent responsible for the delivery of this message to the intended 
recipient(s), you are hereby notified that any disclosure, copying, 
distribution, or use of this email message is prohibited.  If you have received 
this message in error, please notify the sender immediately by e-mail and 
delete this email message from your computer. Thank you.
[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Bioc-devel] updating development version package

[zzrickli]

Hi There,

I need to make a few minor change to my INDEED package, which has already
been accepted. I want to know if I need to do anything other than modify
the codes and bump up the version number.

Thanks
ZL

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [R-pkg-devel] Trying to work around missing functionality

[Duncan Murdoch]

On 28/08/2018 9:17 AM, J C Nash wrote:

Indeed, it appears that globalVariables must be outside the function. However, 
I had quite a bit of
fiddle to get things to work without errors or warnings or notes. While I now 
have a package that
does not complain with R CMD check, I am far from satisfied that I can give a 
prescription. I had
to remove lines in the rootfinder like
envroot$fn <- fn
that were used to set the function to be used inside my instrumented function, 
and instead
call TraceSetup(fn=fn, ...) where a similar statement was given. Why that 
worked while the direct
assignment (note, not a <<- one) did not, I do not understand. However, I will 
work with this for
a while and try to get a better handle on it.

Thanks for the pointer. As an old-time programmer from days when you even set 
the add table, I'm
still uncomfortable just putting code in a directory and assuming it will be 
executed, i.e., the
globals.R file. However, I now have this set to establish the global structure 
as follows


The code in the R directory in a package is all executed once when the 
package is installed, to produce the functions and other objects in the 
package.  But that execution can do other things too, and that's what 
the call to globalVariables() does.


(The order of execution of the files in the R directory usually doesn't 
matter, but it is well defined:  alphabetical order by filename in the C 
locale unless overridden by the Collate field in DESCRIPTION.)


Duncan Murdoch




## Put in R directory.
if(getRversion() >= "2.15.1") { utils::globalVariables(c('envroot')) } # Try 
declaring here
groot<-list(ifn=0, igr=0, ftrace=FALSE, fn=NA, gr=NA, label="none")
envroot <- list2env(groot) # Note globals in FnTrace


Then TraceSetup() is


TraceSetup <- function(ifn=0, igr=0, ftrace=FALSE, fn=NA, gr=NA){
envroot$ifn <- ifn
envroot$igr <- igr
envroot$ftrace <- ftrace
envroot$fn <- fn
envroot$gr <- gr
return()
}


and it is called at the start of the rootfinder routine.

Thus I am establishing a global, then (re-)setting values in TraceSetup(), then
incrementing counters etc. in the instrumented FnTrace() that is the function 
for which I find
the root, which calls fn() given by the "user". Messy, but I can now track 
progress and measure
effort.

I'm sure there are cleaner solutions. I suggest offline discussion would be 
better until such
options are clearer.

Thanks again.

JN



On 2018-08-28 12:01 AM, Fox, John wrote:

Hi John,

It's possible that I didn’t follow what you did, but it appears as if you call 
globalVariables() *inside* the function. Instead try to do as Richard Heiberger 
suggested and place the call outside of the function, e.g., in a source file in 
the package R directory named globals.R. (Of course, the name of the source 
file containing the command isn’t important.)

I hope this helps,
  John

-
John Fox
Professor Emeritus
McMaster University
Hamilton, Ontario, Canada
Web: https://socialsciences.mcmaster.ca/jfox/




-Original Message-
From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On
Behalf Of J C Nash
Sent: Monday, August 27, 2018 8:44 PM
To: Richard M. Heiberger 
Cc: List r-package-devel 
Subject: Re: [R-pkg-devel] Trying to work around missing functionality

Unfortunately, makes things much worse. I'd tried something like this already.


* checking examples ... ERROR
Running examples in ‘rootoned-Ex.R’ failed The error most likely
occurred in:


### Name: rootwrap
### Title: zeroin: Find a single root of a function of one variable within
###   a specified interval.
### Aliases: rootwrap
### Keywords: root-finding

### ** Examples

# Dekker example
# require(rootoned)
dek <- function(x){ 1/(x-3) - 6 }
r1 <- rootwrap(dek, ri=c(3.001, 6), ftrace=TRUE,
method="uniroot")

Error in registerNames(names, package, ".__global__", add) :
   The namespace for package "rootoned" is locked; no changes in the global

variables list may be made.

Calls: rootwrap -> TraceSetup ->  -> registerNames
Execution halted


Also had to use utils::globalVariables( ...

JN


On 2018-08-27 08:40 PM, Richard M. Heiberger wrote:

Does this solve the problem?

if (getRversion() >= '2.15.1')
   globalVariables(c('envroot'))

I keep this in file R/globals.R

I learned of this from John Fox's use in Rcmdr.

On Mon, Aug 27, 2018 at 8:28 PM, J C Nash 

wrote:

In order to track progress of a variety of rootfinding or
optimization routines that don't report some information I want, I'm
using the following setup (this one for rootfinding).

TraceSetup <- function(ifn=0, igr=0, ftrace=FALSE, fn=NA, gr=NA){ #
JN: Define globals here
groot<-list(ifn=ifn, igr=igr, ftrace=ftrace, fn=fn, gr=gr, label="none")
envroot <<- list2env(groot) # Note globals in FnTrace
## This generates a NOTE that
## TraceSetup: no visible binding for '<<-' assignment to ‘envroot’
##   

Re: [R-pkg-devel] Trying to work around missing functionality

[Georgi Boshnakov]

If you don't insist on putting the variable in the global environment, 
variations of the following give a cleaner solution:

TraceSetup_1 <- local({
ifn = 0
igr = 0
ftrace = FALSE
fn = NA
gr = NA

function(ifn=0, igr=0, ftrace=FALSE, fn=NA, gr=NA){
ifn<<- ifn
igr<<- igr
ftrace <<- ftrace
fn <<- fn
gr <<- gr
parent.env(environment())
}
})

For example,

TraceSetup_1 <- local({
+ ifn = 0
+ igr = 0
+ ftrace = FALSE
+ fn = NA
+ gr = NA
+ function(ifn=0, igr=0, ftrace=FALSE, fn=NA, gr=NA){
+ ifn<<- ifn
+ igr<<- igr
+ ftrace <<- ftrace
+ fn <<- fn
+ gr <<- gr
+ parent.env(environment())
+ }
+ })
> 
> e <- TraceSetup_1(fn = function(x) x^2)
> ls(e)
[1] "fn" "ftrace" "gr" "ifn""igr"   
> e$fn
function(x) x^2

## let's change 'fn':
> e$fn <- function(x) x^4
> e$fn
function(x) x^4


Note that the environment is always the same, so can be accessed from anywhere 
in your code:

> e2 <- environment(TraceSetup_1)
> e2

> identical(e2, e)
[1] TRUE
> 

If you need a new environment every time, a basic setup might be:

TraceSetup_2 <- local({
staticVar1 <- NULL
## other variables here

function(ifn=0, igr=0, ftrace=FALSE, fn=NA, gr=NA){
## force evaluation of the arguments
ifn
igr
ftrace 
fn 
gr 
environment()
}
})

There is no need for local() here but usually one needs also some static 
variables.
Now every call gives a different environment  (but all have the same parent):

ea <- TraceSetup_2(fn = function(x) x^2 - 2*x + 1)
> ls(ea)
[1] "fn" "ftrace" "gr" "ifn""igr"   
> ea$fn
function(x) x^2 - 2*x + 1
> 
> eb <- TraceSetup_2(fn = function(x) x^2 + 1)
> eb$fn
function(x) x^2 + 1
> 
> ## ea$fn is still the same:
> ea$fn
function(x) x^2 - 2*x + 1
>

Obviously, in this case some further arrangements are  needed for the 
environments to be made available to the external world.

Hope this helps,
Georgi Boshnakov


-Original Message-
From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On Behalf 
Of J C Nash
Sent: 28 August 2018 14:18
To: Fox, John; Richard M. Heiberger
Cc: List r-package-devel
Subject: Re: [R-pkg-devel] Trying to work around missing functionality

Indeed, it appears that globalVariables must be outside the function. However, 
I had quite a bit of
fiddle to get things to work without errors or warnings or notes. While I now 
have a package that
does not complain with R CMD check, I am far from satisfied that I can give a 
prescription. I had
to remove lines in the rootfinder like
   envroot$fn <- fn
that were used to set the function to be used inside my instrumented function, 
and instead
call TraceSetup(fn=fn, ...) where a similar statement was given. Why that 
worked while the direct
assignment (note, not a <<- one) did not, I do not understand. However, I will 
work with this for
a while and try to get a better handle on it.

Thanks for the pointer. As an old-time programmer from days when you even set 
the add table, I'm
still uncomfortable just putting code in a directory and assuming it will be 
executed, i.e., the
globals.R file. However, I now have this set to establish the global structure 
as follows

> ## Put in R directory. 
> if(getRversion() >= "2.15.1") { utils::globalVariables(c('envroot')) } # Try 
> declaring here 
> groot<-list(ifn=0, igr=0, ftrace=FALSE, fn=NA, gr=NA, label="none")
> envroot <- list2env(groot) # Note globals in FnTrace

Then TraceSetup() is

> TraceSetup <- function(ifn=0, igr=0, ftrace=FALSE, fn=NA, gr=NA){
>envroot$ifn <- ifn
>envroot$igr <- igr
>envroot$ftrace <- ftrace
>envroot$fn <- fn
>envroot$gr <- gr
>return()
> }

and it is called at the start of the rootfinder routine.

Thus I am establishing a global, then (re-)setting values in TraceSetup(), then
incrementing counters etc. in the instrumented FnTrace() that is the function 
for which I find
the root, which calls fn() given by the "user". Messy, but I can now track 
progress and measure
effort.

I'm sure there are cleaner solutions. I suggest offline discussion would be 
better until such
options are clearer.

Thanks again.

JN



On 2018-08-28 12:01 AM, Fox, John wrote:
> Hi John,
> 
> It's possible that I didn’t follow what you did, but it appears as if you 
> call globalVariables() *inside* the function. Instead try to do as Richard 
> Heiberger suggested and place the call outside of the function, e.g., in a 
> source file in the package R directory named globals.R. (Of course, the name 
> of the source file containing the command isn’t important.)
> 
> I hope this helps,
>  John
> 
> -
> John Fox
> Professor Emeritus
> McMaster University
> Hamilton, Ontario, Canada
> Web: 

Re: [Bioc-devel] Don't have access to new package

[Obenchain, Valerie]

Hi John,

The error was on our end. I've cleaned this up and you should now have access 
to multiHiCcompare and HiCcompare.

Valerie


On 08/27/2018 11:13 PM, John Stansfield wrote:

I recently had a new package accepted to Bioconductor, however when I try
to push changes upstream I get the following error:

FATAL: W any packages/multiHiCcompare j.stansfield DENIED by fallthru
(or you mis-spelled the reponame)

I also checked on the bioconductor git credentials and under packages I
have access to, only my first Bioconductor package is listed. My new
package, multiHiCcompare, does not show up and when checking my read write
privileges I only have read access to multiHiCcompare. I added my SSH key
to my github account and I can push to my other package, it is only the new
package that I cannot access.

What do I need to do gain write access to my new package?

Thank you,
John Stansfield

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel





This email message may contain legally privileged and/or confidential 
information.  If you are not the intended recipient(s), or the employee or 
agent responsible for the delivery of this message to the intended 
recipient(s), you are hereby notified that any disclosure, copying, 
distribution, or use of this email message is prohibited.  If you have received 
this message in error, please notify the sender immediately by e-mail and 
delete this email message from your computer. Thank you.
[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [R-pkg-devel] Trying to work around missing functionality

[J C Nash]

Indeed, it appears that globalVariables must be outside the function. However, 
I had quite a bit of
fiddle to get things to work without errors or warnings or notes. While I now 
have a package that
does not complain with R CMD check, I am far from satisfied that I can give a 
prescription. I had
to remove lines in the rootfinder like
   envroot$fn <- fn
that were used to set the function to be used inside my instrumented function, 
and instead
call TraceSetup(fn=fn, ...) where a similar statement was given. Why that 
worked while the direct
assignment (note, not a <<- one) did not, I do not understand. However, I will 
work with this for
a while and try to get a better handle on it.

Thanks for the pointer. As an old-time programmer from days when you even set 
the add table, I'm
still uncomfortable just putting code in a directory and assuming it will be 
executed, i.e., the
globals.R file. However, I now have this set to establish the global structure 
as follows

> ## Put in R directory. 
> if(getRversion() >= "2.15.1") { utils::globalVariables(c('envroot')) } # Try 
> declaring here 
> groot<-list(ifn=0, igr=0, ftrace=FALSE, fn=NA, gr=NA, label="none")
> envroot <- list2env(groot) # Note globals in FnTrace

Then TraceSetup() is

> TraceSetup <- function(ifn=0, igr=0, ftrace=FALSE, fn=NA, gr=NA){
>envroot$ifn <- ifn
>envroot$igr <- igr
>envroot$ftrace <- ftrace
>envroot$fn <- fn
>envroot$gr <- gr
>return()
> }

and it is called at the start of the rootfinder routine.

Thus I am establishing a global, then (re-)setting values in TraceSetup(), then
incrementing counters etc. in the instrumented FnTrace() that is the function 
for which I find
the root, which calls fn() given by the "user". Messy, but I can now track 
progress and measure
effort.

I'm sure there are cleaner solutions. I suggest offline discussion would be 
better until such
options are clearer.

Thanks again.

JN



On 2018-08-28 12:01 AM, Fox, John wrote:
> Hi John,
> 
> It's possible that I didn’t follow what you did, but it appears as if you 
> call globalVariables() *inside* the function. Instead try to do as Richard 
> Heiberger suggested and place the call outside of the function, e.g., in a 
> source file in the package R directory named globals.R. (Of course, the name 
> of the source file containing the command isn’t important.)
> 
> I hope this helps,
>  John
> 
> -
> John Fox
> Professor Emeritus
> McMaster University
> Hamilton, Ontario, Canada
> Web: https://socialsciences.mcmaster.ca/jfox/
> 
> 
> 
>> -Original Message-
>> From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On
>> Behalf Of J C Nash
>> Sent: Monday, August 27, 2018 8:44 PM
>> To: Richard M. Heiberger 
>> Cc: List r-package-devel 
>> Subject: Re: [R-pkg-devel] Trying to work around missing functionality
>>
>> Unfortunately, makes things much worse. I'd tried something like this 
>> already.
>>
>>> * checking examples ... ERROR
>>> Running examples in ‘rootoned-Ex.R’ failed The error most likely
>>> occurred in:
>>>
 ### Name: rootwrap
 ### Title: zeroin: Find a single root of a function of one variable within
 ###   a specified interval.
 ### Aliases: rootwrap
 ### Keywords: root-finding

 ### ** Examples

 # Dekker example
 # require(rootoned)
 dek <- function(x){ 1/(x-3) - 6 }
 r1 <- rootwrap(dek, ri=c(3.001, 6), ftrace=TRUE,
 method="uniroot")
>>> Error in registerNames(names, package, ".__global__", add) :
>>>   The namespace for package "rootoned" is locked; no changes in the global
>> variables list may be made.
>>> Calls: rootwrap -> TraceSetup ->  -> registerNames
>>> Execution halted
>>
>> Also had to use utils::globalVariables( ...
>>
>> JN
>>
>>
>> On 2018-08-27 08:40 PM, Richard M. Heiberger wrote:
>>> Does this solve the problem?
>>>
>>> if (getRversion() >= '2.15.1')
>>>   globalVariables(c('envroot'))
>>>
>>> I keep this in file R/globals.R
>>>
>>> I learned of this from John Fox's use in Rcmdr.
>>>
>>> On Mon, Aug 27, 2018 at 8:28 PM, J C Nash 
>> wrote:
 In order to track progress of a variety of rootfinding or
 optimization routines that don't report some information I want, I'm
 using the following setup (this one for rootfinding).

 TraceSetup <- function(ifn=0, igr=0, ftrace=FALSE, fn=NA, gr=NA){ #
 JN: Define globals here
groot<-list(ifn=ifn, igr=igr, ftrace=ftrace, fn=fn, gr=gr, label="none")
envroot <<- list2env(groot) # Note globals in FnTrace
## This generates a NOTE that
## TraceSetup: no visible binding for '<<-' assignment to ‘envroot’
 ##   envroot<-list2env(groot, parent=.GlobalEnv) # Note globals in FnTrace 
 -
>> - this does NOT work
## utils::globalVariables("envroot") # Try declaring here --
 causes errors # end globals
envroot
 }

 FnTrace <- function(x,...) {

[Bioc-devel] Don't have access to new package

[John Stansfield]

I recently had a new package accepted to Bioconductor, however when I try
to push changes upstream I get the following error:

FATAL: W any packages/multiHiCcompare j.stansfield DENIED by fallthru
(or you mis-spelled the reponame)

I also checked on the bioconductor git credentials and under packages I
have access to, only my first Bioconductor package is listed. My new
package, multiHiCcompare, does not show up and when checking my read write
privileges I only have read access to multiHiCcompare. I added my SSH key
to my github account and I can push to my other package, it is only the new
package that I cannot access.

What do I need to do gain write access to my new package?

Thank you,
John Stansfield

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Help with class lost after subsetting.

[Martin Morgan]

On 08/28/2018 12:19 AM, Charles Plessy wrote:

Dear Bioconductor developers,

In the CAGEr package, I created a "CAGEexp" class that extends
"MultiAssayExperiment" without adding new slots, in order to define generic
functions that require CAGEr-specific contents in the colData slot.

Unfortunately, when run in the development branch of Bioconductor,
the CAGEexp objects lose their class when they are subsetted.  Here
is an example:


CAGEr::exampleCAGEexp

A CAGEexp object of 4 listed
(...)


CAGEr::exampleCAGEexp[,1]

A MultiAssayExperiment object of 4 listed
(...)

This breaks examples in the package, as well as existing code.

I am lost on how to troubleshoot this.  May I ask for your help ?


I debugged this using first `selectMethod("[", "MultiAssayExperiment")` 
and then `showMethod()` / `selectMethod()` to arrive at 
`subsetByColData,MultiAssayExperiment,ANY-method`.


The problem is that this line

https://github.com/waldronlab/MultiAssayExperiment/blob/master/R/subsetBy-methods.R#L261

returns a MultiAssayExperiment; what it should do is probably closer to 
the 'copy constructor' functionality of `initialize()`, along the lines of


  initialize(x, ExperimentList = ..., )

This could be opened as an issue on the MultiAssayExperiment github 
repository; maybe Herve or Michael or others might comment on the best 
implementation.


Martin



Best regards,



___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel