date:20160416

Re: [Bioc-devel] Build error on Moscato2 for mzR

2016-04-16 Thread Kasper Daniel Hansen

And if not fixed on Sunday, surely Monday.  Everyone has been working hard
to get this to work; so just hang tight.

Best,
Kasper

On Sat, Apr 16, 2016 at 5:35 AM, Laurent Gatto  wrote:

>
> On 16 April 2016 09:42, Blattmann Peter wrote:
>
> > Dear all,
> >
> > I'm maintaining the SWATH2stats package and we just use the MSstats
> > package in the vignette for showing an example workflow. As MSstats
> > depends on MSnbase and this depends on mzR we receive an error to
> > build our SWATH2stats package now.
> >
> > In light of the release schedule (where packages should pass R cmd
> > build and check by April 15) how shall we proceed?  Is it no problem
> > that our package is included in the current release if we have install
> > and build errors only on moscato2 but it builds correctly on the other
> > operating systems? Or should we at one point take out the example
> > workflow from the vignette? Or will the problem in mzR be solved in
> > time and we don't have to worry?
>
> The problem has been fixed by Dan with help from Kasper and Jim and the
> Rcpp team. Confirmation on Bioc build servers on Sunday.
>
> Details here
>
>  https://github.com/sneumann/mzR/issues/36
>
> Best wishes,
>
> Laurent
>
> > Best
> >
> > Peter
> >
> > -Original Message-
> > From: Bioc-devel [mailto:bioc-devel-boun...@r-project.org] On Behalf Of
> Steffen Neumann
> > Sent: Thursday, April 07, 2016 11:03 AM
> > To: Samuel Wieczorek; mailman, bioc-devel
> > Subject: Re: [Bioc-devel] Build error on Moscato2 for mzR
> >
> > Hi Samuel,
> >
> > On Do, 2016-04-07 at 10:28 +0200, Samuel Wieczorek wrote:
> > [...]
> >>
> >> which needs the mzR package.
> >> The latter package has build error since a few days and this
> >> propagates errors on the other packages.
> > We're painfully aware of the build failure of mzR. I opened an issue for
> it onhttps://github.com/sneumann/mzR/issues/36
> >
> > I know one person who was able to build mzR on the new toolchainhttps://
> github.com/sneumann/mzR/issues/34#issuecomment-190231
> > 559
> >
> > Unfortunately none of us is a Windows wizard, and I even failed to
> install a working development environment on a virtual machine. If you or
> someone else would help out with a patch for issue #36, that would be
> awesome. I am currently unsure if we need to modify the CFLAGS so that only
> one of the files contains the std symbols, or the LDFLAGS so that the
> linker realises that it can chose one of the symbols.
> >
> > Please head over to the github issue and continue discussion for fixes
> there, I can also test and upload any suggested patches to the
> SinglePackageBuilder.
> >
> > Thanks for any help,
> > yours,
> > Steffen
>
>
> --
> Laurent Gatto | @lgatt0
> http://cpu.sysbiol.cam.ac.uk/
> http://lgatto.github.io/
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[[alternative HTML version deleted]]

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

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

2016-04-16 Thread 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

   - BiocRelease: snapshot from 2015-08-21 || package ver 1.0.0
   - BiocDevel: snapshot from 2015-11-01  || package ver 20151101.1.0





RTCGA.rnaseq

   - BiocRelease: snapshot from 2015-08-21 || package ver 1.0.0
   - BiocDevel: snapshot from 2015-11-01 || package ver 20151101.0.0

RTCGA.mutations

   - BiocRelease: snapshot from 2015-08-21 || package ver 1.0.0
   - BiocDevel: snapshot from 2015-11-01 || package ver 20151101.0.0

---

RTCGA.methylation

   - BiocRelease: NOT YET AVAILABLE
   - BiocDevel: snapshot from 2015-11-0 || package ver 0.99.1


RTCGA.CNV

   - BiocRelease: NOT YET AVAILABLE
   - BiocDevel: snapshot from 2015-11-0 || package ver 0.99.5


RTCGA.RPPA

   - BiocRelease: NOT YET AVAILABLE
   - BiocDevel: snapshot from 2015-11-0 || package ver 0.99.6


RTCGA.mRNA

   - BiocRelease: NOT YET AVAILABLE
   - BiocDevel: snapshot from 2015-11-0 || package ver 0.99.3


RTCGA.miRNASeq

   - 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.


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 interested in 
ovarian cancers, say, would need to download all data anyway.


Instead I think that these should be ExperimentHub resources. How to add 
resources is described in the vignette to the companion package 
ExperimentHubData


   http://bioconductor.org/packages/devel/bioc/html/ExperimentHubData.html

The data would be stored in Amazon S3 so globally accessible; it would 
not be under version control. The ExperimentHub / AnnotationHub cache 
would manage local versions, rather than R's package system.

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

2016-04-16 Thread Marcin Kosiński

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

  - BiocRelease: snapshot from 2015-08-21 || package ver 1.0.0
  - BiocDevel: snapshot from 2015-11-01  || package ver 20151101.1.0

RTCGA.rnaseq

  - BiocRelease: snapshot from 2015-08-21 || package ver 1.0.0
  - BiocDevel: snapshot from 2015-11-01 || package ver 20151101.0.0

RTCGA.mutations

  - BiocRelease: snapshot from 2015-08-21 || package ver 1.0.0
  - BiocDevel: snapshot from 2015-11-01 || package ver 20151101.0.0

---

RTCGA.methylation

  - BiocRelease: NOT YET AVAILABLE
  - BiocDevel: snapshot from 2015-11-0 || package ver 0.99.1


RTCGA.CNV

  - BiocRelease: NOT YET AVAILABLE
  - BiocDevel: snapshot from 2015-11-0 || package ver 0.99.5


RTCGA.RPPA

  - BiocRelease: NOT YET AVAILABLE
  - BiocDevel: snapshot from 2015-11-0 || package ver 0.99.6


RTCGA.mRNA

  - BiocRelease: NOT YET AVAILABLE
  - BiocDevel: snapshot from 2015-11-0 || package ver 0.99.3


RTCGA.miRNASeq

  - 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.

What do you think about such an issue? You can post advices here or on our
issue list: https://github.com/RTCGA/RTCGA/issues

Thanks for comments,
Marcin

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] OpenMP on OS X

2016-04-16 Thread Aaron Taudt

That did the trick! Thanks.


2016-04-15 17:28 GMT+02:00 Vincent Carey :

> other packages use
>
> #ifdef _OPENMP
>
> #include 
>
> #endif
>
>
> have you tried that?
>
> On Fri, Apr 15, 2016 at 11:21 AM, Aaron Taudt 
> wrote:
>
>> Hi,
>>
>> I am using openmp support in my C++ code and it builds just fine on
>> Windows
>> and Linux. The morelia build output for OS X however yields the following
>> error:
>>
>> In file included from ./R_interface.h:5:
>> ./scalehmm.h:16:10: fatal error: 'libiomp/omp.h' file not found
>> #include  // parallelization options on mac
>>  ^
>> 1 error generated.
>>
>> I use the following code to include the omp.h for OS X:
>>
>> #if defined TARGET_OS_MAC || defined __APPLE__
>> #include  // parallelization options on mac
>> #elif defined __linux__ || defined _WIN32 || defined _WIN64
>> #include  // parallelization options
>> #endif
>>
>> What is the correct way to enable the openMP support for OS X?
>>
>> Regards,
>> Aaron
>>
>> [[alternative HTML version deleted]]
>>
>> ___
>> Bioc-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>
>
>

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Build error on Moscato2 for mzR

2016-04-16 Thread Laurent Gatto


On 16 April 2016 09:42, Blattmann Peter wrote:

> Dear all, 
>
> I'm maintaining the SWATH2stats package and we just use the MSstats
> package in the vignette for showing an example workflow. As MSstats
> depends on MSnbase and this depends on mzR we receive an error to
> build our SWATH2stats package now.
>
> In light of the release schedule (where packages should pass R cmd
> build and check by April 15) how shall we proceed?  Is it no problem
> that our package is included in the current release if we have install
> and build errors only on moscato2 but it builds correctly on the other
> operating systems? Or should we at one point take out the example
> workflow from the vignette? Or will the problem in mzR be solved in
> time and we don't have to worry?

The problem has been fixed by Dan with help from Kasper and Jim and the
Rcpp team. Confirmation on Bioc build servers on Sunday.

Details here

 https://github.com/sneumann/mzR/issues/36

Best wishes,

Laurent

> Best
>
> Peter
>
> -Original Message-
> From: Bioc-devel [mailto:bioc-devel-boun...@r-project.org] On Behalf Of 
> Steffen Neumann
> Sent: Thursday, April 07, 2016 11:03 AM
> To: Samuel Wieczorek; mailman, bioc-devel
> Subject: Re: [Bioc-devel] Build error on Moscato2 for mzR
>
> Hi Samuel,
>
> On Do, 2016-04-07 at 10:28 +0200, Samuel Wieczorek wrote:
> [...]
>> 
>> which needs the mzR package.
>> The latter package has build error since a few days and this 
>> propagates errors on the other packages.
> We're painfully aware of the build failure of mzR. I opened an issue for it 
> onhttps://github.com/sneumann/mzR/issues/36
>
> I know one person who was able to build mzR on the new 
> toolchainhttps://github.com/sneumann/mzR/issues/34#issuecomment-190231
> 559
>
> Unfortunately none of us is a Windows wizard, and I even failed to install a 
> working development environment on a virtual machine. If you or someone else 
> would help out with a patch for issue #36, that would be awesome. I am 
> currently unsure if we need to modify the CFLAGS so that only one of the 
> files contains the std symbols, or the LDFLAGS so that the linker realises 
> that it can chose one of the symbols.
>
> Please head over to the github issue and continue discussion for fixes there, 
> I can also test and upload any suggested patches to the SinglePackageBuilder.
>
> Thanks for any help,
> yours,
> Steffen


-- 
Laurent Gatto | @lgatt0
http://cpu.sysbiol.cam.ac.uk/
http://lgatto.github.io/

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

Re: [Bioc-devel] Build error on Moscato2 for mzR

2016-04-16 Thread Blattmann Peter

Dear all, 

I'm maintaining the SWATH2stats package and we just use the MSstats package in 
the vignette for showing an example workflow. As MSstats depends on MSnbase and 
this depends on mzR we receive an error to build our SWATH2stats package now. 

In light of the release schedule (where packages should pass R cmd build and 
check by April 15) how shall we proceed? 
Is it no problem that our package is included in the current release if we have 
install and build errors only on moscato2 but it builds correctly on the other 
operating systems? Or should we at one point take out the example workflow from 
the vignette? Or will the problem in mzR be solved in time and we don't have to 
worry?

Best

Peter

-Original Message-
From: Bioc-devel [mailto:bioc-devel-boun...@r-project.org] On Behalf Of Steffen 
Neumann
Sent: Thursday, April 07, 2016 11:03 AM
To: Samuel Wieczorek; mailman, bioc-devel
Subject: Re: [Bioc-devel] Build error on Moscato2 for mzR

Hi Samuel, 

On Do, 2016-04-07 at 10:28 +0200, Samuel Wieczorek wrote:
[...]
> 
> which needs the mzR package.
> The latter package has build error since a few days and this 
> propagates errors on the other packages.
We're painfully aware of the build failure of mzR. I opened an issue for it on 
https://github.com/sneumann/mzR/issues/36

I know one person who was able to build mzR on the new toolchain 
https://github.com/sneumann/mzR/issues/34#issuecomment-190231
559

Unfortunately none of us is a Windows wizard, and I even failed to install a 
working development environment on a virtual machine. If you or someone else 
would help out with a patch for issue #36, that would be awesome. I am 
currently unsure if we need to modify the CFLAGS so that only one of the files 
contains the std symbols, or the LDFLAGS so that the linker realises that it 
can chose one of the symbols. 

Please head over to the github issue and continue discussion for fixes there, I 
can also test and upload any suggested patches to the SinglePackageBuilder.

Thanks for any help,
yours,
Steffen

-- 
IPB HalleAG Massenspektrometrie & Bioinformatik
Dr. Steffen Neumann  http://www.IPB-Halle.DE
Weinberg 3   http://msbi.bic-gh.de
06120 Halle  Tel. +49 (0) 345 5582 - 1470
  +49 (0) 345 5582 - 0
sneumann(at)IPB-Halle.DE Fax. +49 (0) 345 5582 - 1409

___
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] Build error on Moscato2 for mzR

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

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

Re: [Bioc-devel] OpenMP on OS X

Re: [Bioc-devel] Build error on Moscato2 for mzR

Re: [Bioc-devel] Build error on Moscato2 for mzR

6 matches

Site Navigation

Mail list logo

Footer information