Re: [Bioc-devel] as.list of a GRanges

[Hervé Pagès]

Hi Bernat,

On 02/15/2018 11:57 PM, Bernat Gel wrote:

Hi Hervé and others,

Thanks for the responses.

I woudn't call as.list() of a GRanges an "obscure behaviour" but more a 
"works as expected, even if not clearly documented" behaviour.


Most users/developers will probably agree that as.list() worked
as expected on a GRanges object. But then they'll be surprised
and confused when they use it on an IRanges object and discover
that it does something completely different. The current effort
is to bring more consistency between GRanges and IRanges objects
and to have their list-like semantics aligned and documented so
there will be no more such surprise.



In any case I can change the code to as(gr, "GRangesList") as suggested.


I went ahead and fixed karyoploteR. This is karyoploteR 1.5.2. Make
sure to resync your GitHub repo by following the instructions here:


https://bioconductor.org/developers/how-to/git/sync-existing-repositories/

Note that the loop on the GRanges object (via the call to Map())
was not needed and could be replaced with a solution that uses
proper vectorization.

Best,
H.



Thanks again for the responses and discussion :)

Bernat


*Bernat Gel Moreno*
Bioinformatician

Hereditary Cancer Program
Program of Predictive and Personalized Medicine of Cancer (PMPPC)
Germans Trias i Pujol Research Institute (IGTP)

Campus Can Ruti
Carretera de Can Ruti, Camí de les Escoles s/n
08916 Badalona, Barcelona, Spain

Tel: (+34) 93 554 3068
Fax: (+34) 93 497 8654
08916 Badalona, Barcelona, Spain
b...@igtp.cat 
www.germanstrias.org 
 



 









El 02/15/2018 a las 11:19 PM, Hervé Pagès escribió:

On 02/15/2018 01:57 PM, Michael Lawrence wrote:



On Thu, Feb 15, 2018 at 1:45 PM, Hervé Pagès > wrote:


    On 02/15/2018 11:53 AM, Cook, Malcolm wrote:

    Hi,

    Can I ask, is this change under discussion in current release or
    so far in Bioconductor devel only (my assumption)?


    Bioconductor devel only.


   > On 02/15/2018 08:37 AM, Michael Lawrence wrote:
   > > So is as.list() no longer supported for GRanges objects?
    I have found it
   > > useful in places.
   >
   > Very few places. I found a dozen of them in the entire
    software repo.

    However there are probably more in the wild...


    What as.list() was doing on a GRanges object was not documented. 
Relying

    on some kind of obscure undocumented feature is never a good idea.


There's just too much that is documented implicitly through inherited 
behaviors, or where we say things like "this data structure behaves 
as one would expect given base R". It's not fair to claim that those 
features are undocumented. Our documentation is not complete enough 
to use it as an excuse.


It's not fair to suggest that this is a widely used feature either.

I've identified all the places in the 1500 software packages where
this was used, and, as I said, there were very few places. BTW I
fixed most of them but my plan is to fix all of them. Some of the
code that is outside the Bioc package corpus might be affected but
it's fair to assume that this will be a very rare occurence. This can
be mitigated by temporary restoring as.list() on GRanges, with a
deprecation message, and wait 1 more devel cycle to replace it with
the new behavior. I chose to disable it for now, on purpose, so I can
identify packages that break (the build report is a great tool for
that) and fix them.

I'm not using the fact that as.list() on a GRanges is not documented
as an excuse for anything. Only to help those with concerns to
relativize and relax.

H.




   > Now you should use as.list(as(gr, "GRangesList")) instead.
   > as.list() was behaving inconsistently on IRanges and
    GRanges objects,
   > which is blocking new developments. It will come back with
    a consistent
   > behavior. More generally speaking IRanges and GRanges will
    behave
   > consistently as far as their "list interpretation" is
    concerned.

    Can we please be assured to be reminded of this prominently in
    release notes?


    The changes will be announced and described on this list and in the
    NEWS files of the IRanges and GenomicRanges packages.

    H.


    Thanks!

    ~malcolm


    --     Hervé Pagès

    Program in Computational Biology
    Division of Public Health Sciences
    

Re: [Rd] Duplicate column names created by base::merge() when by.x has the same name as a column in y

[Scott Ritchie]

Hi Frederick,

I would expect that any duplicate names in the resulting data.frame would
have the suffixes appended to them, regardless of whether or not they are
used as the join key. So in my example I would expect "names.x" and
"names.y" to indicate their source data.frame.

While careful reading of the documentation reveals this is not the case, I
would argue the intent of the suffixes functionality should equally be
applied to this type of case.

If you agree this would be useful, I'm happy to write a patch for
merge.data.frame that will add suffixes in this case - I intend to do the
same for merge.data.table in the data.table package where I initially
encountered the edge case.

Best,

Scott

On 17 February 2018 at 03:53,  wrote:

> Hi Scott,
>
> It seems like reasonable behavior to me. What result would you expect?
> That the second "name" should be called "name.y"?
>
> The "merge" documentation says:
>
> If the columns in the data frames not used in merging have any
> common names, these have ‘suffixes’ (‘".x"’ and ‘".y"’ by default)
> appended to try to make the names of the result unique.
>
> Since the first "name" column was used in merging, leaving both
> without a suffix seems consistent with the documentation...
>
> Frederick
>
> On Fri, Feb 16, 2018 at 09:08:29AM +1100, Scott Ritchie wrote:
> > Hi,
> >
> > I was unable to find a bug report for this with a cursory search, but
> would
> > like clarification if this is intended or unavoidable behaviour:
> >
> > ```{r}
> > # Create example data.frames
> > parents <- data.frame(name=c("Sarah", "Max", "Qin", "Lex"),
> >   sex=c("F", "M", "F", "M"),
> >   age=c(41, 43, 36, 51))
> > children <- data.frame(parent=c("Sarah", "Max", "Qin"),
> >name=c("Oliver", "Sebastian", "Kai-lee"),
> >sex=c("M", "M", "F"),
> >age=c(5,8,7))
> >
> > # Merge() creates a duplicated "name" column:
> > merge(parents, children, by.x = "name", by.y = "parent")
> > ```
> >
> > Output:
> > ```
> >name sex.x age.x  name sex.y age.y
> > 1   Max M43 Sebastian M 8
> > 2   Qin F36   Kai-lee F 7
> > 3 Sarah F41Oliver M 5
> > Warning message:
> > In merge.data.frame(parents, children, by.x = "name", by.y = "parent") :
> >   column name ‘name’ is duplicated in the result
> > ```
> >
> > Kind Regards,
> >
> > Scott Ritchie
> >
> >   [[alternative HTML version deleted]]
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] R package CRAN check error

[Hadley Wickham]

Or even better, devtools::release(): it walks you through a checklist
of activities designed to make your submission as successful as
possible.

Hadley

On Fri, Feb 16, 2018 at 2:46 PM, Georgi Boshnakov
 wrote:
> You get a source package suitable for submission by running `R CMD check 
> namepackage'  or the equivalent devtools::build()
>
> Georgi
>
> -Original Message-
> From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On 
> Behalf Of Ilaria Amerise
> Sent: 16 February 2018 11:35
> To: r-package-devel
> Subject: [R-pkg-devel] R package CRAN check error
>
> Hi everybody,
>
> on submitting a new version of a package I got a rejection because of the 
> following Error in the CRAN-check.
>
> Any help would be highly appreciated.
>
> * using R version 3.4.3 (2017-11-30)
> * using platform: x86_64-apple-darwin15.6.0 (64-bit)
> * using session charset: UTF-8
> * using option ‘--as-cran’
> * checking for file ‘namepackage/DESCRIPTION’ ... OK
> * checking extension type ... Package
> * this is package ‘namepackage’ version ‘1.1.2’
> * checking CRAN incoming feasibility ... Note_to_CRAN_maintainers
> * checking package namespace information ... OK
> * checking package dependencies ... OK
> * checking if this is a source package ... ERROR Only *source* packages can 
> be checked.
> * DONE
> Status: 1 ERROR
>
> Best regards,
> Ilaria
>
> __
> R-package-devel@r-project.org mailing list 
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel



-- 
http://hadley.nz

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

Re: [R-pkg-devel] R package CRAN check error

[Dirk Eddelbuettel]

On 16 February 2018 at 20:46, Georgi Boshnakov wrote:
| You get a source package suitable for submission by running `R CMD check 
namepackage'  or the equivalent devtools::build() 

Close: "R CMD build namepackage" creates the tar.gz file.
And "R CMD check --as-cran namepackage_*.tar.gz" checks it.

Dirk

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

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

Re: [R-pkg-devel] R package CRAN check error

[Georgi Boshnakov]

You get a source package suitable for submission by running `R CMD check 
namepackage'  or the equivalent devtools::build() 

Georgi

-Original Message-
From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On Behalf 
Of Ilaria Amerise
Sent: 16 February 2018 11:35
To: r-package-devel
Subject: [R-pkg-devel] R package CRAN check error

Hi everybody,

on submitting a new version of a package I got a rejection because of the 
following Error in the CRAN-check.

Any help would be highly appreciated.

* using R version 3.4.3 (2017-11-30)
* using platform: x86_64-apple-darwin15.6.0 (64-bit)
* using session charset: UTF-8
* using option ‘--as-cran’
* checking for file ‘namepackage/DESCRIPTION’ ... OK
* checking extension type ... Package
* this is package ‘namepackage’ version ‘1.1.2’
* checking CRAN incoming feasibility ... Note_to_CRAN_maintainers
* checking package namespace information ... OK
* checking package dependencies ... OK
* checking if this is a source package ... ERROR Only *source* packages can be 
checked.
* DONE
Status: 1 ERROR

Best regards,
Ilaria

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

Re: [R-pkg-devel] R package CRAN check error

[Dirk Eddelbuettel]

Ilaria,

On 16 February 2018 at 12:34, Ilaria Amerise wrote:
| on submitting a new version of a package I got a rejection because of
| the following Error in the CRAN-check.
| 
| Any help would be highly appreciated.
| 
| * using R version 3.4.3 (2017-11-30)
| * using platform: x86_64-apple-darwin15.6.0 (64-bit)
| * using session charset: UTF-8
| * using option ‘--as-cran’
| * checking for file ‘namepackage/DESCRIPTION’ ... OK
| * checking extension type ... Package
| * this is package ‘namepackage’ version ‘1.1.2’
| * checking CRAN incoming feasibility ... Note_to_CRAN_maintainers
| * checking package namespace information ... OK
| * checking package dependencies ... OK
| * checking if this is a source package ... ERROR
| Only *source* packages can be checked.

That would be your error. You did not upload a source package.

Dirk

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

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

Re: [R-pkg-devel] CRAN submission: Packages accepted if they run on two major R platforms

[Dirk Eddelbuettel]

Carmen,

On 16 February 2018 at 17:59, Carmen M. Livi wrote:
| I am new here and have a question regarding package submissions:
| 
| "CRAN Repository Policy" states that "packages will not be accepted that 
| do not run on at least two major R platforms".
| 
| My package runs on MAC and Linux. So I assume that I can submit my 
| package without configuring it for Windows.
| 
| - Can I therefore ignore the "R CMD check" results from winbuilder after 
| submitting the package?
| - Or is there a way to force the submission just on MAC and Linux machines?

There is, via OS_type. Again, see "Writing R Extensions". But methinks that
you could (and should) fix your package to build in Windows if there is no
structural reason for it not to build.

Dirk

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

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

Re: [R-pkg-devel] configuration failed on win-builder

[Dirk Eddelbuettel]

Hi Carmen,

On 15 February 2018 at 19:45, Carmen M. Livi wrote:
| when submiting my R-package to CRAN I get the following error from the 
| windows machine:
| 
| * installing *source* package 'spp' ...
| ./configure.win: 2: Syntax error: word unexpected (expecting ")")
| ERROR: configuration failed for package 'spp'
| * removing 'd:/RCompile/CRANguest/R-devel/lib/spp'
| In R CMD INSTALL
| 
| The package I am submitting is using a configure file.
| I have a "configure" script generated with autoconf that reads 
| configure.ac (for linux) and configure.win (for windows).

"That reads" ?  Normaly, the autoconf tools _create_ configure from
configure.ac.  For Windows, configure.win is usually completely different and
hand-written.

The are literally hundreds of examples at CRAN which you could study.

| It works fine on linux.
| 
| Looking at the error it seems (to me) that win-builder tries to execute 
| configure.win instead of configure.

Yes. As documented.  See "Writing R Extensions"

Dirk

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

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

[R-pkg-devel] R package CRAN check error

[Ilaria Amerise]

Hi everybody,

on submitting a new version of a package I got a rejection because of
the following Error in the CRAN-check.

Any help would be highly appreciated.

* using R version 3.4.3 (2017-11-30)
* using platform: x86_64-apple-darwin15.6.0 (64-bit)
* using session charset: UTF-8
* using option ‘--as-cran’
* checking for file ‘namepackage/DESCRIPTION’ ... OK
* checking extension type ... Package
* this is package ‘namepackage’ version ‘1.1.2’
* checking CRAN incoming feasibility ... Note_to_CRAN_maintainers
* checking package namespace information ... OK
* checking package dependencies ... OK
* checking if this is a source package ... ERROR
Only *source* packages can be checked.
* DONE
Status: 1 ERROR

Best regards,
Ilaria

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

[R-pkg-devel] configuration failed on win-builder

[Carmen M. Livi]

Hi all,

when submiting my R-package to CRAN I get the following error from the 
windows machine:


* installing *source* package 'spp' ...
./configure.win: 2: Syntax error: word unexpected (expecting ")")
ERROR: configuration failed for package 'spp'
* removing 'd:/RCompile/CRANguest/R-devel/lib/spp'
In R CMD INSTALL

The package I am submitting is using a configure file.
I have a "configure" script generated with autoconf that reads 
configure.ac (for linux) and configure.win (for windows).

It works fine on linux.

Looking at the error it seems (to me) that win-builder tries to execute 
configure.win instead of configure.

Has anyone faced a similar issue? Any idea what is going on?

Thanks,
Carmen

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

Re: [Bioc-devel] as.list of a GRanges

[Kasper Daniel Hansen]

This is one reason why I strongly advocate keeping NEWS up to date on the
devel branch. Not that it would necessarily be easy for Nathan to track it
down based on NEWS on all the packages he depends on.

On Fri, Feb 16, 2018 at 10:25 AM, Nathan Sheffield 
wrote:

> For what it's worth, my package (LOLA) was one that used as.list on a
> GRanges or GRangesList, and those calls were broken by changes to devel.
> Since I was also pushing changes at the time, I assumed the devel build
> errors were due to my updates -- I spent quite a bit of time trying to
> figure out what was wrong before I realized this breakage was not caused by
> my updates, but by upstream changes in GRanges...eventually I tracked down
> errors to as.list (and ultimately, found other errors, which we discussed
> earlier on this list), but my conclusion from this was that, from my
> perspective, using the deployed bioc devel as a way to test for what
> refactoring will break doesn't seem like the ideal way to go -- I assumed
> that generally, other package changes wouldn't typically be pushed that
> would break my package's build, so it devalued the role of the dev builds
> and reduced my confidence in using that (now when I see error I may assume
> it's something else, and wait a few days, instead of diving right in to try
> to solve the problem).
>
> I like the idea of temporarily restoring as.list with a deprecation
> message -- also, as a general development philosophy going forward in terms
> of testing on devel. This would have saved me a lot of time troubleshooting
> in this instance.
>
> Just my 2 cents.
>
> -Nathan
>
>
>
> On 02/16/2018 02:57 AM, Bernat Gel wrote:
>
>> Hi Hervé and others,
>>
>> Thanks for the responses.
>>
>> I woudn't call as.list() of a GRanges an "obscure behaviour" but more a
>> "works as expected, even if not clearly documented" behaviour.
>>
>> In any case I can change the code to as(gr, "GRangesList") as suggested.
>>
>> Thanks again for the responses and discussion :)
>>
>> Bernat
>>
>>
>> *Bernat Gel Moreno*
>> Bioinformatician
>>
>> Hereditary Cancer Program
>> Program of Predictive and Personalized Medicine of Cancer (PMPPC)
>> Germans Trias i Pujol Research Institute (IGTP)
>>
>> Campus Can Ruti
>> Carretera de Can Ruti, Camí de les Escoles s/n
>> 08916 Badalona, Barcelona, Spain
>>
>> Tel: (+34) 93 554 3068
>> Fax: (+34) 93 497 8654
>> 08916 Badalona, Barcelona, Spain
>> b...@igtp.cat 
>> www.germanstrias.org 
>>
>> 
>>
>>
>>
>>
>>
>>
>>
>> El 02/15/2018 a las 11:19 PM, Hervé Pagès escribió:
>>
>>> On 02/15/2018 01:57 PM, Michael Lawrence wrote:
>>>


 On Thu, Feb 15, 2018 at 1:45 PM, Hervé Pagès > wrote:

 On 02/15/2018 11:53 AM, Cook, Malcolm wrote:

 Hi,

 Can I ask, is this change under discussion in current release or
 so far in Bioconductor devel only (my assumption)?


 Bioconductor devel only.


> On 02/15/2018 08:37 AM, Michael Lawrence wrote:
> > So is as.list() no longer supported for GRanges objects?
 I have found it
> > useful in places.
>
> Very few places. I found a dozen of them in the entire
 software repo.

 However there are probably more in the wild...


 What as.list() was doing on a GRanges object was not documented.
 Relying
 on some kind of obscure undocumented feature is never a good idea.


 There's just too much that is documented implicitly through inherited
 behaviors, or where we say things like "this data structure behaves as one
 would expect given base R". It's not fair to claim that those features are
 undocumented. Our documentation is not complete enough to use it as an
 excuse.

>>>
>>> It's not fair to suggest that this is a widely used feature either.
>>>
>>> I've identified all the places in the 1500 software packages where
>>> this was used, and, as I said, there were very few places. BTW I
>>> fixed most of them but my plan is to fix all of them. Some of the
>>> code that is outside the Bioc package corpus might be affected but
>>> it's fair to assume that this will be a very rare occurence. This can
>>> be mitigated by temporary restoring as.list() on GRanges, with a
>>> deprecation message, and wait 1 more devel cycle to replace it with
>>> the new behavior. I chose to disable it for now, on purpose, so I can
>>> identify packages that break (the build report is a great tool for
>>> that) and fix them.
>>>
>>> I'm not using the fact that as.list() on a GRanges is not documented
>>> as an excuse for anything. Only to help those with concerns to
>>> relativize and relax.
>>>
>>> H.
>>>
>>>

> Now you should use 

Re: [Rd] [R-win] Bug 17159 - recursive dir.create() fails on windows shares due to permissions (MMaechler: Resending to R-windows@R-pr..)

[Thompson, Pete]

Wonderful ( - thanks!

Cheers
Pete

On 16/02/2018, 16:29, "Tomas Kalibera"  wrote:

Bug 17159 has been fixed (in R-devel), but there may be more issues left
with UNC paths.
Tomas

On 01/17/2018 01:37 PM, Joris Meys wrote:
> Hi Peter,
>
> I share your experience with trying to help IT departments setting things
> up. The network directory of the students is mapped to a drive, but R 
still
> uses the unc path instead of the drive when attempting to create that user
> library. Unless I do it manually of course. The only solution I see right
> now is to set the HOME or R_LIBS_USER environment variable in Renviron, 
but
> that should be done each time a new student logs into the computer. Or is
> there a way to ensure R uses the mapped drive instead of the network unc
> path, either using an R setting or by messing with Windows itself?
>
> Cheers
> Joris
>
>
>
> On Wed, Jan 17, 2018 at 1:21 PM, Peter Dalgaard  wrote:
>
>> I can easily believe that. It was maily for Joris, that it might not be
>> necessary to reinstall.
>>
>> -pd
>>
>>> On 17 Jan 2018, at 11:55 , Thompson, Pete 
>> wrote:
>>> That solution works fine for the use case where each user has a network
>> based home directory and needs to run R from there, but doesn’t help with
>> my situation. I need to be able to support arbitrary network based paths 
in
>> arbitrary numbers – so mapping drives isn’t an option. I have found a
>> workaround using symbolic links to the network share created within the
>> temporary folder, but would much prefer that R support UNC paths – it 
seems
>> a reasonably simple fix.
>>> Cheers
>>> Pete
>>>
>>>
>>> On 17/01/2018, 10:52, "Peter Dalgaard"  wrote:
>>>
>>> I usually draw a complete blank if  I try to assist our IT 
department
>> with such issues (we really need better documentation than the Admin 
manual
>> for large-system installs by non-experts in R).
>>> However, it is my impression that there are also options involving
>> environment variables and LFS naming. E.g., map the networked user
>> directory to, say, a P: "drive" and make sure that the environment is set
>> up to reflect this.
>>> -pd
>>>
 On 16 Jan 2018, at 17:52 , Joris Meys  wrote:

 Hi all,

 I ran into this exact issue yesterday during the exam of statistical
 computing. Users can install packages in a user library that R tries to
 create automatically on the network drive of the student. But that
>> doesn't
 happen as the unc path is not read correctly, leading to R attempting 
to
 create a local directory and being told it has no right to do so.

 That is an older version of R though (3.3), but I'm wondering whether I
 would ask our IT department to just update R on all these computers to
>> the
 latest version, or if we have to look for another solution.

 Cheers
 Joris

 On Mon, Jan 8, 2018 at 1:43 PM, Thompson, Pete  Hi, I’d like to ask about bug 17159:
>
> https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17159
>
> I can confirm that I see exactly this bug when using dir.create on
>> paths
> of UNC form (\\server\share\xxx), with the recursive flag set. I’m
>> seeing
> this when attempting to use install.packages with such a path (which I
>> know
> isn’t supported, but would be great if it was!). I can see that a
>> patch has
> been suggested for the problem and from looking at the source code I
> believe it’s a correct fix. Is there a possibility of getting this
>> patch
> included?
>
> The existing logic for Windows recursive dir.create (platform.c lines
> 2209-22203) appears to be:
> - Skip over any \\share at the start of the directory name
> - Loop while there are pieces of directory name left (i.e. we haven’t
>> hit
> the last \ character)
> = Find the next portion of the directory name (up to the next \
> character)
> = Attempt to create the directory (unless it is of the form x: - i.e. 
a
> drive name)
> = Ignore any ‘already exists’ errors, otherwise throw an error
>
> This logic appears flawed in that it skips \\share which isn’t a valid
> path format (according to https://msdn.microsoft.com/en-
> us/library/windows/desktop/aa365247(v=vs.85).aspx ). Dredging my
>> memory,
> it’s possible that \\share was a supported format in very old versions
>> of
> Windows, but 

Re: [Bioc-devel] as.list of a GRanges

[Renan Valieris]

FWIW, this change also affects code that don't call as.list() explicitly.

such as calling Reduce(union, granges), Reduce is implemented on base, and
will call as.list() if the predicate isn't a vector already.

I understand it wasn't intended to be used this way, but with this in mind
there are more packages potentially affected by the change.

On Fri, Feb 16, 2018 at 1:25 PM, Nathan Sheffield 
wrote:

> For what it's worth, my package (LOLA) was one that used as.list on a
> GRanges or GRangesList, and those calls were broken by changes to devel.
> Since I was also pushing changes at the time, I assumed the devel build
> errors were due to my updates -- I spent quite a bit of time trying to
> figure out what was wrong before I realized this breakage was not caused by
> my updates, but by upstream changes in GRanges...eventually I tracked down
> errors to as.list (and ultimately, found other errors, which we discussed
> earlier on this list), but my conclusion from this was that, from my
> perspective, using the deployed bioc devel as a way to test for what
> refactoring will break doesn't seem like the ideal way to go -- I assumed
> that generally, other package changes wouldn't typically be pushed that
> would break my package's build, so it devalued the role of the dev builds
> and reduced my confidence in using that (now when I see error I may assume
> it's something else, and wait a few days, instead of diving right in to try
> to solve the problem).
>
> I like the idea of temporarily restoring as.list with a deprecation
> message -- also, as a general development philosophy going forward in terms
> of testing on devel. This would have saved me a lot of time troubleshooting
> in this instance.
>
> Just my 2 cents.
>
> -Nathan
>
>
>
> On 02/16/2018 02:57 AM, Bernat Gel wrote:
>
>> Hi Hervé and others,
>>
>> Thanks for the responses.
>>
>> I woudn't call as.list() of a GRanges an "obscure behaviour" but more a
>> "works as expected, even if not clearly documented" behaviour.
>>
>> In any case I can change the code to as(gr, "GRangesList") as suggested.
>>
>> Thanks again for the responses and discussion :)
>>
>> Bernat
>>
>>
>> *Bernat Gel Moreno*
>> Bioinformatician
>>
>> Hereditary Cancer Program
>> Program of Predictive and Personalized Medicine of Cancer (PMPPC)
>> Germans Trias i Pujol Research Institute (IGTP)
>>
>> Campus Can Ruti
>> Carretera de Can Ruti, Camí de les Escoles s/n
>> 08916 Badalona, Barcelona, Spain
>>
>> Tel: (+34) 93 554 3068
>> Fax: (+34) 93 497 8654
>> 08916 Badalona, Barcelona, Spain
>> b...@igtp.cat 
>> www.germanstrias.org 
>>
>> 
>>
>>
>>
>>
>>
>>
>>
>> El 02/15/2018 a las 11:19 PM, Hervé Pagès escribió:
>>
>>> On 02/15/2018 01:57 PM, Michael Lawrence wrote:
>>>


 On Thu, Feb 15, 2018 at 1:45 PM, Hervé Pagès > wrote:

 On 02/15/2018 11:53 AM, Cook, Malcolm wrote:

 Hi,

 Can I ask, is this change under discussion in current release or
 so far in Bioconductor devel only (my assumption)?


 Bioconductor devel only.


> On 02/15/2018 08:37 AM, Michael Lawrence wrote:
> > So is as.list() no longer supported for GRanges objects?
 I have found it
> > useful in places.
>
> Very few places. I found a dozen of them in the entire
 software repo.

 However there are probably more in the wild...


 What as.list() was doing on a GRanges object was not documented.
 Relying
 on some kind of obscure undocumented feature is never a good idea.


 There's just too much that is documented implicitly through inherited
 behaviors, or where we say things like "this data structure behaves as one
 would expect given base R". It's not fair to claim that those features are
 undocumented. Our documentation is not complete enough to use it as an
 excuse.

>>>
>>> It's not fair to suggest that this is a widely used feature either.
>>>
>>> I've identified all the places in the 1500 software packages where
>>> this was used, and, as I said, there were very few places. BTW I
>>> fixed most of them but my plan is to fix all of them. Some of the
>>> code that is outside the Bioc package corpus might be affected but
>>> it's fair to assume that this will be a very rare occurence. This can
>>> be mitigated by temporary restoring as.list() on GRanges, with a
>>> deprecation message, and wait 1 more devel cycle to replace it with
>>> the new behavior. I chose to disable it for now, on purpose, so I can
>>> identify packages that break (the build report is a great tool for
>>> that) and fix them.
>>>
>>> I'm not using the fact that as.list() on a GRanges is not documented
>>> as an 

Re: [Rd] Duplicate column names created by base::merge() when by.x has the same name as a column in y

[frederik]

Hi Scott,

It seems like reasonable behavior to me. What result would you expect?
That the second "name" should be called "name.y"?

The "merge" documentation says:

If the columns in the data frames not used in merging have any
common names, these have ‘suffixes’ (‘".x"’ and ‘".y"’ by default)
appended to try to make the names of the result unique.

Since the first "name" column was used in merging, leaving both
without a suffix seems consistent with the documentation...

Frederick

On Fri, Feb 16, 2018 at 09:08:29AM +1100, Scott Ritchie wrote:
> Hi,
> 
> I was unable to find a bug report for this with a cursory search, but would
> like clarification if this is intended or unavoidable behaviour:
> 
> ```{r}
> # Create example data.frames
> parents <- data.frame(name=c("Sarah", "Max", "Qin", "Lex"),
>   sex=c("F", "M", "F", "M"),
>   age=c(41, 43, 36, 51))
> children <- data.frame(parent=c("Sarah", "Max", "Qin"),
>name=c("Oliver", "Sebastian", "Kai-lee"),
>sex=c("M", "M", "F"),
>age=c(5,8,7))
> 
> # Merge() creates a duplicated "name" column:
> merge(parents, children, by.x = "name", by.y = "parent")
> ```
> 
> Output:
> ```
>name sex.x age.x  name sex.y age.y
> 1   Max M43 Sebastian M 8
> 2   Qin F36   Kai-lee F 7
> 3 Sarah F41Oliver M 5
> Warning message:
> In merge.data.frame(parents, children, by.x = "name", by.y = "parent") :
>   column name ‘name’ is duplicated in the result
> ```
> 
> Kind Regards,
> 
> Scott Ritchie
> 
>   [[alternative HTML version deleted]]
> 
> __
> 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] [R-win] Bug 17159 - recursive dir.create() fails on windows shares due to permissions (MMaechler: Resending to R-windows@R-pr..)

[Tomas Kalibera]

Bug 17159 has been fixed (in R-devel), but there may be more issues left 
with UNC paths.

Tomas

On 01/17/2018 01:37 PM, Joris Meys wrote:

Hi Peter,

I share your experience with trying to help IT departments setting things
up. The network directory of the students is mapped to a drive, but R still
uses the unc path instead of the drive when attempting to create that user
library. Unless I do it manually of course. The only solution I see right
now is to set the HOME or R_LIBS_USER environment variable in Renviron, but
that should be done each time a new student logs into the computer. Or is
there a way to ensure R uses the mapped drive instead of the network unc
path, either using an R setting or by messing with Windows itself?

Cheers
Joris



On Wed, Jan 17, 2018 at 1:21 PM, Peter Dalgaard  wrote:


I can easily believe that. It was maily for Joris, that it might not be
necessary to reinstall.

-pd


On 17 Jan 2018, at 11:55 , Thompson, Pete 

wrote:

That solution works fine for the use case where each user has a network

based home directory and needs to run R from there, but doesn’t help with
my situation. I need to be able to support arbitrary network based paths in
arbitrary numbers – so mapping drives isn’t an option. I have found a
workaround using symbolic links to the network share created within the
temporary folder, but would much prefer that R support UNC paths – it seems
a reasonably simple fix.

Cheers
Pete


On 17/01/2018, 10:52, "Peter Dalgaard"  wrote:

I usually draw a complete blank if  I try to assist our IT department

with such issues (we really need better documentation than the Admin manual
for large-system installs by non-experts in R).

However, it is my impression that there are also options involving

environment variables and LFS naming. E.g., map the networked user
directory to, say, a P: "drive" and make sure that the environment is set
up to reflect this.

-pd


On 16 Jan 2018, at 17:52 , Joris Meys  wrote:

Hi all,

I ran into this exact issue yesterday during the exam of statistical
computing. Users can install packages in a user library that R tries to
create automatically on the network drive of the student. But that

doesn't

happen as the unc path is not read correctly, leading to R attempting to
create a local directory and being told it has no right to do so.

That is an older version of R though (3.3), but I'm wondering whether I
would ask our IT department to just update R on all these computers to

the

latest version, or if we have to look for another solution.

Cheers
Joris

On Mon, Jan 8, 2018 at 1:43 PM, Thompson, Pete 

Re: [Bioc-devel] as.list of a GRanges

[Nathan Sheffield]

For what it's worth, my package (LOLA) was one that used as.list on a 
GRanges or GRangesList, and those calls were broken by changes to devel. 
Since I was also pushing changes at the time, I assumed the devel build 
errors were due to my updates -- I spent quite a bit of time trying to 
figure out what was wrong before I realized this breakage was not caused 
by my updates, but by upstream changes in GRanges...eventually I tracked 
down errors to as.list (and ultimately, found other errors, which we 
discussed earlier on this list), but my conclusion from this was that, 
from my perspective, using the deployed bioc devel as a way to test for 
what refactoring will break doesn't seem like the ideal way to go -- I 
assumed that generally, other package changes wouldn't typically be 
pushed that would break my package's build, so it devalued the role of 
the dev builds and reduced my confidence in using that (now when I see 
error I may assume it's something else, and wait a few days, instead of 
diving right in to try to solve the problem).


I like the idea of temporarily restoring as.list with a deprecation 
message -- also, as a general development philosophy going forward in 
terms of testing on devel. This would have saved me a lot of time 
troubleshooting in this instance.


Just my 2 cents.

-Nathan


On 02/16/2018 02:57 AM, Bernat Gel wrote:

Hi Hervé and others,

Thanks for the responses.

I woudn't call as.list() of a GRanges an "obscure behaviour" but more 
a "works as expected, even if not clearly documented" behaviour.


In any case I can change the code to as(gr, "GRangesList") as suggested.

Thanks again for the responses and discussion :)

Bernat


*Bernat Gel Moreno*
Bioinformatician

Hereditary Cancer Program
Program of Predictive and Personalized Medicine of Cancer (PMPPC)
Germans Trias i Pujol Research Institute (IGTP)

Campus Can Ruti
Carretera de Can Ruti, Camí de les Escoles s/n
08916 Badalona, Barcelona, Spain

Tel: (+34) 93 554 3068
Fax: (+34) 93 497 8654
08916 Badalona, Barcelona, Spain
b...@igtp.cat 
www.germanstrias.org 









El 02/15/2018 a las 11:19 PM, Hervé Pagès escribió:

On 02/15/2018 01:57 PM, Michael Lawrence wrote:



On Thu, Feb 15, 2018 at 1:45 PM, Hervé Pagès > wrote:


    On 02/15/2018 11:53 AM, Cook, Malcolm wrote:

    Hi,

    Can I ask, is this change under discussion in current 
release or

    so far in Bioconductor devel only (my assumption)?


    Bioconductor devel only.


   > On 02/15/2018 08:37 AM, Michael Lawrence wrote:
   > > So is as.list() no longer supported for GRanges objects?
    I have found it
   > > useful in places.
   >
   > Very few places. I found a dozen of them in the entire
    software repo.

    However there are probably more in the wild...


    What as.list() was doing on a GRanges object was not documented. 
Relying

    on some kind of obscure undocumented feature is never a good idea.


There's just too much that is documented implicitly through 
inherited behaviors, or where we say things like "this data 
structure behaves as one would expect given base R". It's not fair 
to claim that those features are undocumented. Our documentation is 
not complete enough to use it as an excuse.


It's not fair to suggest that this is a widely used feature either.

I've identified all the places in the 1500 software packages where
this was used, and, as I said, there were very few places. BTW I
fixed most of them but my plan is to fix all of them. Some of the
code that is outside the Bioc package corpus might be affected but
it's fair to assume that this will be a very rare occurence. This can
be mitigated by temporary restoring as.list() on GRanges, with a
deprecation message, and wait 1 more devel cycle to replace it with
the new behavior. I chose to disable it for now, on purpose, so I can
identify packages that break (the build report is a great tool for
that) and fix them.

I'm not using the fact that as.list() on a GRanges is not documented
as an excuse for anything. Only to help those with concerns to
relativize and relax.

H.




   > Now you should use as.list(as(gr, "GRangesList")) instead.
   > as.list() was behaving inconsistently on IRanges and
    GRanges objects,
   > which is blocking new developments. It will come back with
    a consistent
   > behavior. More generally speaking IRanges and GRanges will
    behave
   > consistently as far as their "list interpretation" is
    concerned.

    Can we please be assured to be reminded of this prominently in
    release notes?


    The changes will be announced and described on this list and in the
    NEWS files of the IRanges and GenomicRanges packages.

    H.


    Thanks!

    ~malcolm


    --