Re: [Rd] S3 dispatch for S4 subclasses only works if variable "extends" is accessible from global environment

[Michael Lawrence]

Right, the methods package is not attached by default when running R
with Rscript. We should probably remove that special case, as it
mostly just leads to confusion, but that won't happen immediately.

For now, the S4_extends() should probably throw an error when the
methods namespace is not loaded. And the check should be changed to
directly check whether R_MethodsNamespace has been set to something
other than the default (R_GlobalEnv). Agreed?

On Mon, Apr 18, 2016 at 4:35 PM, Kirill Müller
 wrote:
> Scenario: An S3 method is declared for an S4 base class but called for an
> instance of a derived class.
>
> Steps to reproduce:
>
>> Rscript -e "test <- function(x) UseMethod('test', x); test.Matrix <-
>> function(x) 'Hi'; MatrixDispatchTest::test(Matrix::Matrix())"
> Error in UseMethod("test", x) :
>   no applicable method for 'test' applied to an object of class "lsyMatrix"
> Calls: 
> 1: MatrixDispatchTest::test(Matrix::Matrix())
>
>> Rscript -e "extends <- 42; test <- function(x) UseMethod('test', x);
>> test.Matrix <- function(x) 'Hi'; MatrixDispatchTest::test(Matrix::Matrix())"
> [1] "Hi"
>
> To me, it looks like a sanity check in line 655 of src/main/attrib.c is
> making wrong assumptions, but there might be other reasons.
> (https://github.com/wch/r-source/blob/780021752eb83a71e2198019acf069ba8741103b/src/main/attrib.c#L655-L656)
>
> Same behavior in R 3.2.4, R 3.2.5 and R-devel r70420.
>
>
> Best regards
>
> Kirill
>
> __
> 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: [R-pkg-devel] Submitting CRAN packages with hard-to-meet dependencies

[Dirk Eddelbuettel]

My $0.02:

On 18 April 2016 at 20:23, boB Rudis wrote:
| I would hope CRAN would let this in with some validation (even to the
| point of it possibly adding a new field to DESCRIPTION). It may never
| run on Slolaris or Plan 9, and I - who now runs a CRAN mirror in the
| hopes to eventually have a MacBuilder equivalent service at some point
| in the near future - would also appreciate not having to support large
| scale library & database dependencies, even for a potentially useful
| package like this. The inclusion in CRAN make packages like it usable
| in situations where (for example) github packages would not be (my
| previous employer did not allow non-CRAN packages to be used in
| sensitive data applications).

Won't fly. Wishing and praying alone doesn't make it happen.  You are putting
the burden on CRAN, and the two of them already have 8270+ packages to look 
after.

Suggestion below.
 
| On Mon, Apr 18, 2016 at 5:16 PM, Oliver Keyes  wrote:
| > Good day,
| >
| > I've written an Rcpp-backed R package
| > (https://github.com/Ironholds/poster) that interfaces with the
| > libpostal (https://github.com/openvenues/libpostal) library, written
| > in C.
| >
| > While the two play together perfectly nicely, the problem is
| > submitting the package to CRAN: libpostal is not a common dependency
| > and isn't available in a debianised form for CRAN's testing: the
| > alternative approach, including libpostal *in* the R package, is made
| > impossible since it downloads gigabyte-sized databases for internal
| > use.

How about this:

 -- insert a new layer between poster and libpostal which satisfies the
build requirements for poster and lets it be installed

 -- the layer intercepts calls, and with libpostal not present alerts the
user

So now postal has a wrapper which may come with its own installer support.

| > What's the approach or guidance on submitting packages in this state?
| > The package includes a configuration script that recognises (in a
| > user-friendly way) when dependencies aren't met, and warns the user
| > appropriately, but it is still ultimately an R package that will not
| > compile on CRAN. Can it be submitted, albeit with installation
| > skipped, or is this unacceptable?

No because it won't build so it cannot be tested.  You can do this, but not
on CRAN.  There is drat ...

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] Submitting CRAN packages with hard-to-meet dependencies

[boB Rudis]

I would hope CRAN would let this in with some validation (even to the
point of it possibly adding a new field to DESCRIPTION). It may never
run on Slolaris or Plan 9, and I - who now runs a CRAN mirror in the
hopes to eventually have a MacBuilder equivalent service at some point
in the near future - would also appreciate not having to support large
scale library & database dependencies, even for a potentially useful
package like this. The inclusion in CRAN make packages like it usable
in situations where (for example) github packages would not be (my
previous employer did not allow non-CRAN packages to be used in
sensitive data applications).

On Mon, Apr 18, 2016 at 5:16 PM, Oliver Keyes  wrote:
> Good day,
>
> I've written an Rcpp-backed R package
> (https://github.com/Ironholds/poster) that interfaces with the
> libpostal (https://github.com/openvenues/libpostal) library, written
> in C.
>
> While the two play together perfectly nicely, the problem is
> submitting the package to CRAN: libpostal is not a common dependency
> and isn't available in a debianised form for CRAN's testing: the
> alternative approach, including libpostal *in* the R package, is made
> impossible since it downloads gigabyte-sized databases for internal
> use.
>
> What's the approach or guidance on submitting packages in this state?
> The package includes a configuration script that recognises (in a
> user-friendly way) when dependencies aren't met, and warns the user
> appropriately, but it is still ultimately an R package that will not
> compile on CRAN. Can it be submitted, albeit with installation
> skipped, or is this unacceptable?
>
> Best,
> Oliver
>
> __
> 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: [Rd] S3 dispatch for S4 subclasses only works if variable "extends" is accessible from global environment

[Kirill Müller]

Please omit "MatrixDispatchTest::" from the test scripts:

Rscript -e "test <- function(x) UseMethod('test', x); test.Matrix <- 
function(x) 'Hi'; test(Matrix::Matrix())"


Rscript -e "extends <- 42; test <- function(x) UseMethod('test', x); 
test.Matrix <- function(x) 'Hi'; test(Matrix::Matrix())"



-Kirill


On 19.04.2016 01:35, Kirill Müller wrote:
Scenario: An S3 method is declared for an S4 base class but called for 
an instance of a derived class.


Steps to reproduce:

> Rscript -e "test <- function(x) UseMethod('test', x); test.Matrix <- 
function(x) 'Hi'; MatrixDispatchTest::test(Matrix::Matrix())"

Error in UseMethod("test", x) :
  no applicable method for 'test' applied to an object of class 
"lsyMatrix"

Calls: 
1: MatrixDispatchTest::test(Matrix::Matrix())

> Rscript -e "extends <- 42; test <- function(x) UseMethod('test', x); 
test.Matrix <- function(x) 'Hi'; 
MatrixDispatchTest::test(Matrix::Matrix())"

[1] "Hi"

To me, it looks like a sanity check in line 655 of src/main/attrib.c 
is making wrong assumptions, but there might be other reasons. 
(https://github.com/wch/r-source/blob/780021752eb83a71e2198019acf069ba8741103b/src/main/attrib.c#L655-L656)


Same behavior in R 3.2.4, R 3.2.5 and R-devel r70420.


Best regards

Kirill

__
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] S3 dispatch for S4 subclasses only works if variable "extends" is accessible from global environment

[Kirill Müller]

Scenario: An S3 method is declared for an S4 base class but called for 
an instance of a derived class.


Steps to reproduce:

> Rscript -e "test <- function(x) UseMethod('test', x); test.Matrix <- 
function(x) 'Hi'; MatrixDispatchTest::test(Matrix::Matrix())"

Error in UseMethod("test", x) :
  no applicable method for 'test' applied to an object of class "lsyMatrix"
Calls: 
1: MatrixDispatchTest::test(Matrix::Matrix())

> Rscript -e "extends <- 42; test <- function(x) UseMethod('test', x); 
test.Matrix <- function(x) 'Hi'; MatrixDispatchTest::test(Matrix::Matrix())"

[1] "Hi"

To me, it looks like a sanity check in line 655 of src/main/attrib.c is 
making wrong assumptions, but there might be other reasons. 
(https://github.com/wch/r-source/blob/780021752eb83a71e2198019acf069ba8741103b/src/main/attrib.c#L655-L656)


Same behavior in R 3.2.4, R 3.2.5 and R-devel r70420.


Best regards

Kirill

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

[R-pkg-devel] Submitting CRAN packages with hard-to-meet dependencies

[Oliver Keyes]

Good day,

I've written an Rcpp-backed R package
(https://github.com/Ironholds/poster) that interfaces with the
libpostal (https://github.com/openvenues/libpostal) library, written
in C.

While the two play together perfectly nicely, the problem is
submitting the package to CRAN: libpostal is not a common dependency
and isn't available in a debianised form for CRAN's testing: the
alternative approach, including libpostal *in* the R package, is made
impossible since it downloads gigabyte-sized databases for internal
use.

What's the approach or guidance on submitting packages in this state?
The package includes a configuration script that recognises (in a
user-friendly way) when dependencies aren't met, and warns the user
appropriately, but it is still ultimately an R package that will not
compile on CRAN. Can it be submitted, albeit with installation
skipped, or is this unacceptable?

Best,
Oliver

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

Re: [Rd] Understanding POSIXct creation on different OSes.

[Dirk Eddelbuettel]

On 11 April 2016 at 14:48, Dirk Eddelbuettel wrote:
| 
| Bumping this up to the front again ... because it exhibits a difference in
| behaviour of R across OSs.  Such a 'feature' may not be desirable.

And bumping it a second time.  If nobody replies I will carry it over to 
Bugzilla.

It is still a "misfeature" with behaviour which varies across OSs which is
rarely the desired outcome.  I'd still love to hear some comments.

Dirk

| 
| On 4 April 2016 at 18:00, Arunkumar Srinivasan wrote:
| | Hello,
| | 
| | Following Dirk's post here: 
https://github.com/Rdatatable/data.table/issues/1619
| | we would like to clarify if this is the right behaviour, and if so,
| | the rationale behind it.
| | 
| | Here's the summary (thanks to Dirk and Joshua):
| | 
| | Sys.setenv("TZ"="America/Chicago")
| | dates = as.Date("2016-03-02") + (0:3)*7 # four Wednesdays
| | # [1] "2016-03-02" "2016-03-09" "2016-03-16" "2016-03-23"
| | 
| | # on OS X and Windows 10 -- expected result
| | as.POSIXct(as.POSIXlt(dates), tz = "America/Chicago")
| | # [1] "2016-03-02 CST" "2016-03-09 CST" "2016-03-16 CDT" "2016-03-23 CDT"
| | 
| | # On Linux (tested on Ubuntu 14.04) -- not as expected
| | as.POSIXct(as.POSIXlt(dates), tz = "America/Chicago")
| | # [1] "2016-03-02 00:00:00 CST" "2016-03-09 00:00:00 CST" "2016-03-16
| | 01:00:00 CDT" "2016-03-23 01:00:00 CDT"
| |
| | # 'isdst' attribute is identical on OS X / Windows / Ubuntu, as expected
| | # since dates don't have timezones, as pointed out by @JoshuaUlrich under
| | # issue #1619.
| | lt = as.POSIXlt(dates)
| | lt$isdst
| | # [1] 0 0 0 0
| | 
| | # However, as Dirk points out, setting isdst to -1 on Ubuntu returns
| | expected results
| | lt$isdst = -1
| | as.POSIXct(lt, tz = "America/Chicago")
| | # [1] "2016-03-02 CST" "2016-03-09 CST" "2016-03-16 CDT" "2016-03-23 CDT"
| | 
| | # Note that setting isdst to -1 on OS X / Windows has no effect, i.e.,
| | the result is always as expected.
| | 
| | As Dirk points out, from ?POSIXlt:
| | "Where possible the platform limits are detected, and outside the
| | limits we use our own C code. This uses the offset from GMT in
| | use either for 1902 (when there was no DST) or that predicted for
| | one of 2030 to 2037 (chosen so that the likely DST transition days
| | are Sundays), and uses the alternate (daylight-saving) time zone
| | only if ‘isdst’ is positive or (if ‘-1’) if DST was predicted to
| | be in operation in the 2030s on that day."
| | 
| | It's not clear what this exactly means, and if it is related to the
| | behaviour shown above. It'd be nice to know if a) this behaviour of
| | non-identical result is as expected, and if so, b) can we rely on
| | setting 'isdst' to -1 returning the expected result always?
| 
| Could someone from R Core please comment, or would you prefer us to file a
| bug report?
| 
| Thanks!
| 
| Dirk
| 
| 
| 
| | Thank you,
| | Arun.
| | 
| | __
| | R-devel@r-project.org mailing list
| | https://stat.ethz.ch/mailman/listinfo/r-devel
| -- 
| http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
| 
| __
| R-devel@r-project.org mailing list
| https://stat.ethz.ch/mailman/listinfo/r-devel
-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [Bioc-devel] Update of data packages in RTCGA Family/Factory of R Packages

[Marcin Kosiński]

2016-04-16 22:55 GMT+02:00 Martin Morgan :

>
>
> On 04/16/2016 01:09 PM, Marcin Kosiński wrote:
>
>> Hello,
>>
>> I would like to ask you all for an advice in the following issue.
>>
>> Last year I have started working with data from The Cancer Genome Atlas.
>> During that work out team (https://github.com/orgs/RTCGA/people) have
>> prepared some tools for downloading and integrating datasets from TCGA
>> study and provided them in the R package called RTCGA
>> , which
>> is
>> available on Bioconductor.
>>
>> Later on we were working on tools for visualizing and analyzing the most
>> popular datasets from TCGA so we have prepared data packages with those
>> datasets and submitted them to Bioconductor in 8 separate packages. You
>> can
>> read more about them here http://rtcga.github.io/RTCGA/
>>
>> *I have a question about updating those data packages.* TCGA release
>> datasets snapshots over time. In the RTCGA family of R packages there are
>> available datasets from the release date 2015-11-01 but currently one can
>> check that there was newer release 2016-01-28
>>
>> tail(RTCGA::checkTCGA('Dates'))
>>>
>> [1] "2015-02-04" "2015-04-02" "2015-06-01" "2015-08-21" "2015-11-01"
>> "2016-01-28"
>>
>> I am wondering whether should we upload newer datasets to those data
>> packages. We have found that there are great differences in results of
>> data
>> analysis depending on from which release date one has took datasets. More
>> about this issue can be found here:
>> http://rtcga.github.io/RTCGA/Usecases.html#tcga-and-the-curse-of-bigdata
>>
>> The current state of RTCGA family of R packages is listed below
>>
>> RTCGA.clinical
>> <
>> http://www.bioconductor.org/packages/3.3/data/experiment/html/RTCGA.clinical.html
>> >
>>- BiocRelease: snapshot from 2015-08-21 || package ver 1.0.0
>>- BiocDevel: snapshot from 2015-11-01  || package ver 20151101.1.0
>>
>
>
>
>> RTCGA.rnaseq
>> <
>> http://www.bioconductor.org/packages/3.3/data/experiment/html/RTCGA.rnaseq.html
>> >
>>- BiocRelease: snapshot from 2015-08-21 || package ver 1.0.0
>>- BiocDevel: snapshot from 2015-11-01 || package ver 20151101.0.0
>>
>> RTCGA.mutations
>> <
>> http://www.bioconductor.org/packages/3.3/data/experiment/html/RTCGA.mutations.html
>> >
>>- BiocRelease: snapshot from 2015-08-21 || package ver 1.0.0
>>- BiocDevel: snapshot from 2015-11-01 || package ver 20151101.0.0
>>
>> ---
>>
>> RTCGA.methylation
>> <
>> http://www.bioconductor.org/packages/3.3/data/experiment/html/RTCGA.methylation.html
>> >
>>- BiocRelease: NOT YET AVAILABLE
>>- BiocDevel: snapshot from 2015-11-0 || package ver 0.99.1
>>
>>
>> RTCGA.CNV
>> <
>> http://www.bioconductor.org/packages/3.3/data/experiment/html/RTCGA.CNV.html
>> >
>>- BiocRelease: NOT YET AVAILABLE
>>- BiocDevel: snapshot from 2015-11-0 || package ver 0.99.5
>>
>>
>> RTCGA.RPPA
>> <
>> http://www.bioconductor.org/packages/3.3/data/experiment/html/RTCGA.RPPA.html
>> >
>>- BiocRelease: NOT YET AVAILABLE
>>- BiocDevel: snapshot from 2015-11-0 || package ver 0.99.6
>>
>>
>> RTCGA.mRNA
>> <
>> http://www.bioconductor.org/packages/3.3/data/experiment/html/RTCGA.mRNA.html
>> >
>>- BiocRelease: NOT YET AVAILABLE
>>- BiocDevel: snapshot from 2015-11-0 || package ver 0.99.3
>>
>>
>> RTCGA.miRNASeq
>> <
>> http://www.bioconductor.org/packages/3.3/data/experiment/html/RTCGA.miRNASeq.html
>> >
>>- BiocRelease: NOT YET AVAILABLE
>>- BiocDevel: snapshot from 2015-11-0 || package ver 0.99.4
>>
>>
>> I think that having datasets from the newest snapshot date is vital for
>> data analysis, but I wouldn't like to create situations in which 2
>> separate
>> analysts use RTCGA.clinical and got different results because they used
>> different data versions. That's why I have started versioning data
>> packages
>> with the number that corresponds to the release date.
>>
>
> This isn't very helpful. There is only ever one version of
> 'RTCGA.clinical' available per Bioc version, so whether its version is
> 20151101.1.0 or 1.1.0 wouldn't make a difference to the end user.
>
> Probably you want to include the TCGA release in the package _name_,
> 'RTCGA.clinical.20151101'. Probably you want to have multiple versions
> available at any one time.
>

Thanks for comments. I haven't considered making separate packages for
separate data releases.


>
> I don't think the experiment data archive is the best solution for
> distributing large collections of curated data. It places a burden on our
> mirrors to sync the repository and on  the svn repository to store it. The
> packages are built twice weekly even though the data is very static and in
> your case based on unchanging base R data structures. The data are not very
> 'granular', even though you've done a good job of making the individual
> data sets accessible, so a user 

Re: [Bioc-devel] git-svn-mirror problem committing

[Dan Tenenbaum]

- Original Message -
> From: "Hector Corrada Bravo" 
> To: "bioc-devel" 
> Sent: Monday, April 18, 2016 7:56:06 AM
> Subject: [Bioc-devel] git-svn-mirror problem committing

> I am having issues committing to new package 'epivizrServer'. The error
> reported by 'git svn dcommit' is printed below. Links to github repos below
> as well. Help appreciated!
> 
> Cheers,
> Hector
> 
> Github repos:
> https://github.com/epiviz/epivizrServer
> https://github.com/Bioconductor-mirror/epivizrServer
> 
> git-svn error:
> 
> MacBook-Pro:epivizrServer hcorrada$ git svn dcommit --add-author-from
> Committing to
> https://hedgehog.fhcrc.org/bioconductor/trunk/madman/Rpacks/epivizrServer
> ...
> A .Rbuildignore
> 
> ERROR from SVN:
> URL access forbidden for unknown reason: Access to
> '/bioconductor/!svn/txr/116455-1/trunk/madman/Rpacks/epivizrServer/.Rbuildignore'
> forbidden


Looks like an authentication problem. Have you tried it with the --username 
option?

Sometimes it helps to 'seed' the svn authentication first, so do something like:


svn log --limit 1 --username XXX 
https://hedgehog.fhcrc.org/bioconductor/trunk/madman/Rpacks/epivizrServer

Where XXX is your username, then enter the password when prompted. Then try git 
svn dcommit again.

Dan


> W: 938ecad892524e86792329e8d8766686bb1a087f and refs/remotes/git-svn-devel
> differ, using rebase:
> :100644 00 6148565133db357a9890af714348d2e4794c3621
>  D .Rbuildignore
> :100644 00 47a9b8e270f369afab79beeebe32d21901d0ef72
>  D .gitignore
> :100644 100644 2853b00474deb4958f4fbabc63497fcad87fb5f9
> 47e7f18877bb374cb50a1e07ef66da5b4b55de43 M DESCRIPTION
> :04 04 ce9e12e2cac7f4afb237941b7a9a8b2d0f056e71
> 157860d339673d6bc8f68520e1910308b7287648 M R
> :100644 00 9f964990f3272399c497e7e227c082eaf58c6cb3
>  D epivizrServer.Rproj
> :04 04 ecf32c9ff0527398545309b15a04a1bcd93cb9b9
> 34b7a3e62b88729128c8c5fe855a03c8650e22e8 M man
> :04 04 3a49548f078dafd069dfc91ee044b17fcd4c0ba5
> ae055d2e89a3c01789e94cea703b9047a1343bfb M tests
> Current branch devel is up to date.
> ERROR: Not all changes have been committed into SVN, however the committed
> ones (if any) seem to be successfully integrated into the working tree.
> Please see the above messages for details.
> 
>   [[alternative HTML version deleted]]
> 
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel

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

Re: [Bioc-devel] SVN and GitHub mirror out-of-sync

[Dan Tenenbaum]

Should be caught up now.
Dan


- Original Message -
> From: "Peter Hickey" 
> To: "bioc-devel" 
> Sent: Monday, April 18, 2016 7:00:29 AM
> Subject: Re: [Bioc-devel] SVN and GitHub mirror out-of-sync

> Typo - github version is 1.5.23
> 
> On Mon, 18 Apr 2016 at 09:26 Peter Hickey  wrote:
> 
>> Hi,
>>
>> The current version of GenomicTuples on the official SVN is 1.5.24
>> (
>> https://hedgehog.fhcrc.org/bioconductor/trunk/madman/Rpacks/GenomicTuples/DESCRIPTION
>> ),
>> however, the version available via the GitHub mirror is only 1.5.21
>> (
>> https://github.com/Bioconductor-mirror/GenomicTuples/blob/master/DESCRIPTION
>> ).
>> Shouldn't the latest version be automatically propagated to the GitHub
>> mirror?
>>
>> Thanks,
>> Pete
>>
> 
>   [[alternative HTML version deleted]]
> 
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel

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

[Bioc-devel] git-svn-mirror problem committing

[Hector Corrada Bravo]

I am having issues committing to new package 'epivizrServer'. The error
reported by 'git svn dcommit' is printed below. Links to github repos below
as well. Help appreciated!

Cheers,
Hector

Github repos:
https://github.com/epiviz/epivizrServer
https://github.com/Bioconductor-mirror/epivizrServer

git-svn error:

MacBook-Pro:epivizrServer hcorrada$ git svn dcommit --add-author-from
Committing to
https://hedgehog.fhcrc.org/bioconductor/trunk/madman/Rpacks/epivizrServer
...
A .Rbuildignore

ERROR from SVN:
URL access forbidden for unknown reason: Access to
'/bioconductor/!svn/txr/116455-1/trunk/madman/Rpacks/epivizrServer/.Rbuildignore'
forbidden
W: 938ecad892524e86792329e8d8766686bb1a087f and refs/remotes/git-svn-devel
differ, using rebase:
:100644 00 6148565133db357a9890af714348d2e4794c3621
 D .Rbuildignore
:100644 00 47a9b8e270f369afab79beeebe32d21901d0ef72
 D .gitignore
:100644 100644 2853b00474deb4958f4fbabc63497fcad87fb5f9
47e7f18877bb374cb50a1e07ef66da5b4b55de43 M DESCRIPTION
:04 04 ce9e12e2cac7f4afb237941b7a9a8b2d0f056e71
157860d339673d6bc8f68520e1910308b7287648 M R
:100644 00 9f964990f3272399c497e7e227c082eaf58c6cb3
 D epivizrServer.Rproj
:04 04 ecf32c9ff0527398545309b15a04a1bcd93cb9b9
34b7a3e62b88729128c8c5fe855a03c8650e22e8 M man
:04 04 3a49548f078dafd069dfc91ee044b17fcd4c0ba5
ae055d2e89a3c01789e94cea703b9047a1343bfb M tests
Current branch devel is up to date.
ERROR: Not all changes have been committed into SVN, however the committed
ones (if any) seem to be successfully integrated into the working tree.
Please see the above messages for details.

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] SVN and GitHub mirror out-of-sync

[Peter Hickey]

Typo - github version is 1.5.23

On Mon, 18 Apr 2016 at 09:26 Peter Hickey  wrote:

> Hi,
>
> The current version of GenomicTuples on the official SVN is 1.5.24
> (
> https://hedgehog.fhcrc.org/bioconductor/trunk/madman/Rpacks/GenomicTuples/DESCRIPTION
> ),
> however, the version available via the GitHub mirror is only 1.5.21
> (
> https://github.com/Bioconductor-mirror/GenomicTuples/blob/master/DESCRIPTION
> ).
> Shouldn't the latest version be automatically propagated to the GitHub
> mirror?
>
> Thanks,
> Pete
>

[[alternative HTML version deleted]]

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

[Bioc-devel] SVN and GitHub mirror out-of-sync

[Peter Hickey]

Hi,

The current version of GenomicTuples on the official SVN is 1.5.24
(https://hedgehog.fhcrc.org/bioconductor/trunk/madman/Rpacks/GenomicTuples/DESCRIPTION),
however, the version available via the GitHub mirror is only 1.5.21
(https://github.com/Bioconductor-mirror/GenomicTuples/blob/master/DESCRIPTION).
Shouldn't the latest version be automatically propagated to the GitHub
mirror?

Thanks,
Pete

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

Re: [Rd] Building R-patched and R-devel fails

[peter dalgaard]

On 17 Apr 2016, at 17:09 , Uwe Ligges  wrote:

> 
> 
> On 17.04.2016 11:01, Prof Brian Ripley wrote:
>> On 17/04/2016 07:25, Berwin A Turlach wrote:
>>> G'day all,
>>> 
>>> probably you have noticed this by now, but I thought I ought to report
>>> it. :)
>> 
>> Already fixed for Unix by the time this reached me.  Since that version
>> of Survival has been put into 3.2 patched, that also needed its
>> Makefile.in updated.
>> 
>> I've left Windows changes to those with a Windows build system.
> 
> 
> Done for R-devel and the 3.3 branch just in case something happens on other 
> machines. At least on my machine the build happened in an appropriate order 
> anyway.

Great.

In case you missed Terry's note: This dependency transpires to be due to a very 
recent addition addition to survival, which explains why we were never bitten 
by it in the past. And since M comes before s in most collations, it probably 
only affected parallel builds anyway. And even in that case, the outcome of 
race conditions is undetermined.

-pd


> 
> Best,
> Uwe
> 
>>> 
>>> My scripts that update the SVN sources for R-patched and R-devel, run
>>> `tools/rsync-recommended' (for both) and then install both these
>>> versions from scratch failed this morning.  Apparently the new version
>>> of the recommended package `survival' depends on the recommended
>>> package `Matrix', but the makefile does not ensure that Matrix is build
>>> before survival.  So my log files had entries:
>>> 
>>>   [...]
>>>   ERROR: dependency ‘Matrix’ is not available for package ‘survival’
>>>   * removing ‘/opt/src/R-devel-build/library/survival’
>>>   Makefile:51: recipe for target 'survival.ts' failed
>>>   make[2]: *** [survival.ts] Error 1
>>>   make[2]: *** Waiting for unfinished jobs
>>>   [...]
>>> 
>>> Presumably, in both branches, the files Makefile.in and Makefile.win in
>>> src/library/Recommended have to be adapted to contain the following
>>> line at the end among the "Hardcoded dependencies":
>>> 
>>>survival.ts: Matrix.ts
>>> 
>>> Cheers,
>>> 
>>>Berwin
>>> 
>>> __
>>> 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

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk  Priv: pda...@gmail.com

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

[Rd] Survival package (was Building R-patched and R-devel fails)

[Therneau, Terry M., Ph.D.]

Just a note FYI:  The survival package can now create predicted "probability in state" 
curves from a multi-state model, and that computation uses the exponential of a matrix.


Hence the new NAMESPACE line of "importFrom(Matrix, expm)", and the resulting dependency 
of 'survival' on 'Matrix'.  It is the only part of the package used.


Terry T.

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

[Bioc-devel] Bioconductor Core Team: Web / System Administrator

[Martin Morgan]

Developers!

Looking to make a difference in scientific computing, enabling 
leading-edge analysis by your peers and colleagues? The Bioconductor 
Core Team is looking for a Senior Programmer / Analyst to expand and 
help with challenging and creative opportunities related to cloud-based 
computing resources, our daily build system, as well as trouble-shooting 
and management of user-contributed packages. There is considerable 
opportunity to develop innovative modern, containerized (e.g. Docker, 
AMI) and cloud-based (commercial and in-house) solutions to enable use 
of our software, and to employ modern automation software to develop, 
deploy and manage in-house computational resources.


job: https://support.bioconductor.org/p/80884/
official posting: 
https://www.roswellpark.org/careers/administrative/senior-programmeranalyst-4446


Direct questions to martin.morgan at roswellpark dot org.


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.

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