Re: [Bioc-devel] Confusion with how to maintain release/devel files on local computer.

[Martin Morgan]

On 11/01/2017 07:53 PM, Arman Shahrisa wrote:
I cloned the package into a clean directory. 


It helps to be more precise here. Were did you clone the package from? 
In the simplest case it would be


  git clone g...@git.bioconductor.org:packages/your-package

and you'd have a single remote named 'origin'

  git remote -v

You can add or rename remotes, e.g.,

  git remote rename origin upstream
  git remote add origin g...@github.com:your-name/your-package

and you can pull (or fetch and then merge) from each

  git pull upstream  # pull changes from 'upstream' remote
  git pull origin# pull changes from 'origin'

Study the how-to documents for different scenarios, and be precise as 
possible with what you are trying to do. Also, when learning, it can be 
comforting to know that removing your local repository from your disk is 
not the end of the world, you can just start over with a new clone from 
git.bioconductor.org or from github.



Then I followed �New package workflow� strategy. By checking Description file 
while switching between branches, I can easily see the version change which is 
correct. If I understand it correctly, GitHub can only contain changes I make 
to master branch. If I want to push changes to GitHub as well, what should I do?


You can do whatever you want with your local clone, and with github. The 
Bioconductor git repository allows you to push only to 'master' and the 
current release, RELEASE_3_6. Suppose you'd made changes to master, and 
you named the remotes 'origin' (for github) and 'upstream' (for 
bioconductor). Then after after adding (git add ...) and committing (git 
commit ...) to the local repository, you'd push to bioconductor with


  git push upstream master

and to github with

  git push origin master

Martin



Best regards,
Arman


From: Stephanie M. Gogarten
Sent: Thursday, November 2, 2017 02:19
To: Arman Shahrisa
Cc: bioc-devel
Subject: Re: [Bioc-devel] Confusion with how to maintain release/devel files on 
local computer.

One possible point of confusion: Laurent's workflow includes maintaining
separate branches "master" and "devel", which he syncs to his own Github
repo and Bioconductor's git repo respectively. However, the
documentation on the bioc website
(https://bioconductor.org/developers/how-to/git/) assumes that you have
only one "master" branch that you push to both remotes.

On 11/1/17 2:33 PM, Laurent Gatto wrote:


On  1 November 2017 20:36, Arman Shahrisa wrote:


I'm confused with development process.

At first, I need to have a folder with accepted packaged. Then I need to pull
origion RELEASE_3_6?

Then in another folder, I need to pull origion master?


No, it all happens in the same folder, but switching between branches
using git. Here's an example of one of my own packages. The first
command list all available branches (all, using -a, means also
remote-only branches). My current branch is noted with an *, and I also
have a feature branch called writeMSData, which also lives on GitHub
(https://github.com/lgatto/MSnbase/, but that's optional).

$ git branch -a
devel
* master
writeMSData
remotes/origin/HEAD -> origin/master
remotes/origin/centroiding
remotes/origin/fixBracketSubset
remotes/origin/issue82
remotes/origin/master
remotes/origin/orbifilter
remotes/origin/processingData
remotes/origin/removePrecMz
remotes/origin/writeMSData
remotes/upstream/RELEASE_2_10
remotes/upstream/RELEASE_2_11
remotes/upstream/RELEASE_2_12
remotes/upstream/RELEASE_2_13
remotes/upstream/RELEASE_2_14
remotes/upstream/RELEASE_2_8
remotes/upstream/RELEASE_2_9
remotes/upstream/RELEASE_3_0
remotes/upstream/RELEASE_3_1
remotes/upstream/RELEASE_3_2
remotes/upstream/RELEASE_3_3
remotes/upstream/RELEASE_3_4
remotes/upstream/RELEASE_3_5
remotes/upstream/master

As you can see (and as specified by Gabe in his earlier reply), I
haven't have pulled all Bioconductor releases. master points to GitHub's
origin/master branch, and devel points to Bioconductor's
upstream/master. As you can see above, I haven't got the latest release
references yet. I can do this with

$ git fetch --all
Fetching origin
Fetching upstream
remote: Counting objects: 6, done.
remote: Compressing objects: 100% (6/6), done.
remote: Total 6 (delta 4), reused 0 (delta 0)
Unpacking objects: 100% (6/6), done.
  From git.bioconductor.org:packages/MSnbase
   * [new branch]  RELEASE_3_6 -> upstream/RELEASE_3_6
 b680678..a98138c  master -> upstream/master

And now

$ git branch -a
devel
* master
writeMSData
remotes/origin/HEAD -> origin/master
remotes/origin/centroiding
remotes/origin/fixBracketSubset
remotes/origin/issue82
remotes/origin/master
remotes/origin/orbifilter
remotes/origin/processingData
remotes/origin/removePrecMz
remotes/origin/writeMSData
  

Re: [Bioc-devel] Confusion with how to maintain release/devel files on local computer.

[Vincent Carey]

As I plan to "fix a bug" in release version of BiocSklearn, I tried

%vjcair> git checkout remotes/upstream/RELEASE_3_6

Here is the result; what would I do to make some changes, alter DESCRIPTION
version to 1.0.1, commit and push so that the build system

has 1.0.1?

Note: checking out 'remotes/upstream/RELEASE_3_6'.


You are in 'detached HEAD' state. You can look around, make experimental

changes and commit them, and you can discard any commits you make in this

state without impacting any branches by performing another checkout.


If you want to create a new branch to retain commits you create, you may

do so (now or later) by using -b with the checkout command again. Example:


  git checkout -b 


HEAD is now at 98fabcd... bump x.y.z versions to even y prior to creation
of RELEASE_3_6 branch

On Wed, Nov 1, 2017 at 8:19 PM, Arman Shahrisa 
wrote:

> I found how I can create another remote with GitHub using Rstudio. How can
> I merge master and GitHub?
>
> Best regards,
> Arman
>
> From: Arman Shahrisa
> Sent: Thursday, November 2, 2017 03:23
> To: Stephanie M. Gogarten; bioc-devel bioc-devel@r-project.org>
> Subject: RE: [Bioc-devel] Confusion with how to maintain release/devel
> files on local computer.
>
> I cloned the package into a clean directory. Then I followed “New package
> workflow” strategy. By checking Description file while switching between
> branches, I can easily see the version change which is correct. If I
> understand it correctly, GitHub can only contain changes I make to master
> branch. If I want to push changes to GitHub as well, what should I do?
>
> Best regards,
> Arman
>
>
> From: Stephanie M. Gogarten
> Sent: Thursday, November 2, 2017 02:19
> To: Arman Shahrisa
> Cc: bioc-devel
> Subject: Re: [Bioc-devel] Confusion with how to maintain release/devel
> files on local computer.
>
> One possible point of confusion: Laurent's workflow includes maintaining
> separate branches "master" and "devel", which he syncs to his own Github
> repo and Bioconductor's git repo respectively. However, the
> documentation on the bioc website
> (https://bioconductor.org/developers/how-to/git/) assumes that you have
> only one "master" branch that you push to both remotes.
>
> On 11/1/17 2:33 PM, Laurent Gatto wrote:
> >
> > On  1 November 2017 20:36, Arman Shahrisa wrote:
> >
> >> I'm confused with development process.
> >>
> >> At first, I need to have a folder with accepted packaged. Then I need
> to pull
> >> origion RELEASE_3_6?
> >>
> >> Then in another folder, I need to pull origion master?
> >
> > No, it all happens in the same folder, but switching between branches
> > using git. Here's an example of one of my own packages. The first
> > command list all available branches (all, using -a, means also
> > remote-only branches). My current branch is noted with an *, and I also
> > have a feature branch called writeMSData, which also lives on GitHub
> > (https://github.com/lgatto/MSnbase/, but that's optional).
> >
> > $ git branch -a
> >devel
> > * master
> >writeMSData
> >remotes/origin/HEAD -> origin/master
> >remotes/origin/centroiding
> >remotes/origin/fixBracketSubset
> >remotes/origin/issue82
> >remotes/origin/master
> >remotes/origin/orbifilter
> >remotes/origin/processingData
> >remotes/origin/removePrecMz
> >remotes/origin/writeMSData
> >remotes/upstream/RELEASE_2_10
> >remotes/upstream/RELEASE_2_11
> >remotes/upstream/RELEASE_2_12
> >remotes/upstream/RELEASE_2_13
> >remotes/upstream/RELEASE_2_14
> >remotes/upstream/RELEASE_2_8
> >remotes/upstream/RELEASE_2_9
> >remotes/upstream/RELEASE_3_0
> >remotes/upstream/RELEASE_3_1
> >remotes/upstream/RELEASE_3_2
> >remotes/upstream/RELEASE_3_3
> >remotes/upstream/RELEASE_3_4
> >remotes/upstream/RELEASE_3_5
> >remotes/upstream/master
> >
> > As you can see (and as specified by Gabe in his earlier reply), I
> > haven't have pulled all Bioconductor releases. master points to GitHub's
> > origin/master branch, and devel points to Bioconductor's
> > upstream/master. As you can see above, I haven't got the latest release
> > references yet. I can do this with
> >
> > $ git fetch --all
> > Fetching origin
> > Fetching upstream
> > remote: Counting objects: 6, done.
> > remote: Compressing objects: 100% (6/6), done.
> > remote: Total 6 (delta 4), reused 0 (delta 0)
> > Unpacking objects: 100% (6/6), done.
> >  From git.bioconductor.org:packages/MSnbase
> >   * [new branch]  RELEASE_3_6 -> upstream/RELEASE_3_6
> > b680678..a98138c  master -> upstream/master
> >
> > And now
> >
> > $ git branch -a
> >devel
> > * master
> >writeMSData
> >remotes/origin/HEAD -> origin/master
> >remotes/origin/centroiding
> >remotes/origin/fixBracketSubset
> >  

Re: [Bioc-devel] Confusion with how to maintain release/devel files on local computer.

[Arman Shahrisa]

I cloned the package into a clean directory. Then I followed �New package 
workflow� strategy. By checking Description file while switching between 
branches, I can easily see the version change which is correct. If I understand 
it correctly, GitHub can only contain changes I make to master branch. If I 
want to push changes to GitHub as well, what should I do?

Best regards,
Arman


From: Stephanie M. Gogarten
Sent: Thursday, November 2, 2017 02:19
To: Arman Shahrisa
Cc: bioc-devel
Subject: Re: [Bioc-devel] Confusion with how to maintain release/devel files on 
local computer.

One possible point of confusion: Laurent's workflow includes maintaining
separate branches "master" and "devel", which he syncs to his own Github
repo and Bioconductor's git repo respectively. However, the
documentation on the bioc website
(https://bioconductor.org/developers/how-to/git/) assumes that you have
only one "master" branch that you push to both remotes.

On 11/1/17 2:33 PM, Laurent Gatto wrote:
>
> On  1 November 2017 20:36, Arman Shahrisa wrote:
>
>> I'm confused with development process.
>>
>> At first, I need to have a folder with accepted packaged. Then I need to pull
>> origion RELEASE_3_6?
>>
>> Then in another folder, I need to pull origion master?
>
> No, it all happens in the same folder, but switching between branches
> using git. Here's an example of one of my own packages. The first
> command list all available branches (all, using -a, means also
> remote-only branches). My current branch is noted with an *, and I also
> have a feature branch called writeMSData, which also lives on GitHub
> (https://github.com/lgatto/MSnbase/, but that's optional).
>
> $ git branch -a
>devel
> * master
>writeMSData
>remotes/origin/HEAD -> origin/master
>remotes/origin/centroiding
>remotes/origin/fixBracketSubset
>remotes/origin/issue82
>remotes/origin/master
>remotes/origin/orbifilter
>remotes/origin/processingData
>remotes/origin/removePrecMz
>remotes/origin/writeMSData
>remotes/upstream/RELEASE_2_10
>remotes/upstream/RELEASE_2_11
>remotes/upstream/RELEASE_2_12
>remotes/upstream/RELEASE_2_13
>remotes/upstream/RELEASE_2_14
>remotes/upstream/RELEASE_2_8
>remotes/upstream/RELEASE_2_9
>remotes/upstream/RELEASE_3_0
>remotes/upstream/RELEASE_3_1
>remotes/upstream/RELEASE_3_2
>remotes/upstream/RELEASE_3_3
>remotes/upstream/RELEASE_3_4
>remotes/upstream/RELEASE_3_5
>remotes/upstream/master
>
> As you can see (and as specified by Gabe in his earlier reply), I
> haven't have pulled all Bioconductor releases. master points to GitHub's
> origin/master branch, and devel points to Bioconductor's
> upstream/master. As you can see above, I haven't got the latest release
> references yet. I can do this with
>
> $ git fetch --all
> Fetching origin
> Fetching upstream
> remote: Counting objects: 6, done.
> remote: Compressing objects: 100% (6/6), done.
> remote: Total 6 (delta 4), reused 0 (delta 0)
> Unpacking objects: 100% (6/6), done.
>  From git.bioconductor.org:packages/MSnbase
>   * [new branch]  RELEASE_3_6 -> upstream/RELEASE_3_6
> b680678..a98138c  master -> upstream/master
>
> And now
>
> $ git branch -a
>devel
> * master
>writeMSData
>remotes/origin/HEAD -> origin/master
>remotes/origin/centroiding
>remotes/origin/fixBracketSubset
>remotes/origin/issue82
>remotes/origin/master
>remotes/origin/orbifilter
>remotes/origin/processingData
>remotes/origin/removePrecMz
>remotes/origin/writeMSData
>remotes/upstream/RELEASE_2_10
>remotes/upstream/RELEASE_2_11
>remotes/upstream/RELEASE_2_12
>remotes/upstream/RELEASE_2_13
>remotes/upstream/RELEASE_2_14
>remotes/upstream/RELEASE_2_8
>remotes/upstream/RELEASE_2_9
>remotes/upstream/RELEASE_3_0
>remotes/upstream/RELEASE_3_1
>remotes/upstream/RELEASE_3_2
>remotes/upstream/RELEASE_3_3
>remotes/upstream/RELEASE_3_4
>remotes/upstream/RELEASE_3_5
>remotes/upstream/RELEASE_3_6
>remotes/upstream/master
>
> If I want to modify the development branch (i.e. Bioconductor's
> upstreams/master), then I checkout devel (that's how I named it
> locally), do changes and push.
>
> $ git checkout devel
> ## do stuff
> $ git push
>
> Same principle for other branches.
>
>> So that by opening each folder, I know what I'm editing.
>> Also during push, I need to be careful about where I'm pushing changes.
>> Origion is bioc's git address of my package whereas master is the package 
>> directory in GitHub?
>
> No - I suggest you read a bit about git (GitHub is a web interface using
> git) to familiarise yourself with the concepts and vocabulary.
>
>> Am I getting it correct?
>> Is there anywhere that contains whole the process and codes in steps?
>
> All the setup and more details are provided in
>
>

Re: [Bioc-devel] Confusion with how to maintain release/devel files on local computer.

[Stephanie M. Gogarten]

One possible point of confusion: Laurent's workflow includes maintaining 
separate branches "master" and "devel", which he syncs to his own Github 
repo and Bioconductor's git repo respectively. However, the 
documentation on the bioc website 
(https://bioconductor.org/developers/how-to/git/) assumes that you have 
only one "master" branch that you push to both remotes.


On 11/1/17 2:33 PM, Laurent Gatto wrote:


On  1 November 2017 20:36, Arman Shahrisa wrote:


I'm confused with development process.

At first, I need to have a folder with accepted packaged. Then I need to pull
origion RELEASE_3_6?

Then in another folder, I need to pull origion master?


No, it all happens in the same folder, but switching between branches
using git. Here's an example of one of my own packages. The first
command list all available branches (all, using -a, means also
remote-only branches). My current branch is noted with an *, and I also
have a feature branch called writeMSData, which also lives on GitHub
(https://github.com/lgatto/MSnbase/, but that's optional).

$ git branch -a
   devel
* master
   writeMSData
   remotes/origin/HEAD -> origin/master
   remotes/origin/centroiding
   remotes/origin/fixBracketSubset
   remotes/origin/issue82
   remotes/origin/master
   remotes/origin/orbifilter
   remotes/origin/processingData
   remotes/origin/removePrecMz
   remotes/origin/writeMSData
   remotes/upstream/RELEASE_2_10
   remotes/upstream/RELEASE_2_11
   remotes/upstream/RELEASE_2_12
   remotes/upstream/RELEASE_2_13
   remotes/upstream/RELEASE_2_14
   remotes/upstream/RELEASE_2_8
   remotes/upstream/RELEASE_2_9
   remotes/upstream/RELEASE_3_0
   remotes/upstream/RELEASE_3_1
   remotes/upstream/RELEASE_3_2
   remotes/upstream/RELEASE_3_3
   remotes/upstream/RELEASE_3_4
   remotes/upstream/RELEASE_3_5
   remotes/upstream/master

As you can see (and as specified by Gabe in his earlier reply), I
haven't have pulled all Bioconductor releases. master points to GitHub's
origin/master branch, and devel points to Bioconductor's
upstream/master. As you can see above, I haven't got the latest release
references yet. I can do this with

$ git fetch --all
Fetching origin
Fetching upstream
remote: Counting objects: 6, done.
remote: Compressing objects: 100% (6/6), done.
remote: Total 6 (delta 4), reused 0 (delta 0)
Unpacking objects: 100% (6/6), done.
 From git.bioconductor.org:packages/MSnbase
  * [new branch]  RELEASE_3_6 -> upstream/RELEASE_3_6
b680678..a98138c  master -> upstream/master

And now

$ git branch -a
   devel
* master
   writeMSData
   remotes/origin/HEAD -> origin/master
   remotes/origin/centroiding
   remotes/origin/fixBracketSubset
   remotes/origin/issue82
   remotes/origin/master
   remotes/origin/orbifilter
   remotes/origin/processingData
   remotes/origin/removePrecMz
   remotes/origin/writeMSData
   remotes/upstream/RELEASE_2_10
   remotes/upstream/RELEASE_2_11
   remotes/upstream/RELEASE_2_12
   remotes/upstream/RELEASE_2_13
   remotes/upstream/RELEASE_2_14
   remotes/upstream/RELEASE_2_8
   remotes/upstream/RELEASE_2_9
   remotes/upstream/RELEASE_3_0
   remotes/upstream/RELEASE_3_1
   remotes/upstream/RELEASE_3_2
   remotes/upstream/RELEASE_3_3
   remotes/upstream/RELEASE_3_4
   remotes/upstream/RELEASE_3_5
   remotes/upstream/RELEASE_3_6
   remotes/upstream/master

If I want to modify the development branch (i.e. Bioconductor's
upstreams/master), then I checkout devel (that's how I named it
locally), do changes and push.

$ git checkout devel
## do stuff
$ git push

Same principle for other branches.


So that by opening each folder, I know what I'm editing.
Also during push, I need to be careful about where I'm pushing changes.
Origion is bioc's git address of my package whereas master is the package 
directory in GitHub?


No - I suggest you read a bit about git (GitHub is a web interface using
git) to familiarise yourself with the concepts and vocabulary.


Am I getting it correct?
Is there anywhere that contains whole the process and codes in steps?


All the setup and more details are provided in

   https://github.com/bioconductor/bioc_git_transition/

in particular the FAQ and all the scenarios at the bottom

   https://github.com/Bioconductor/bioc_git_transition/blob/master/doc/faq.md

Best wishes,

Laurent


Best regards,
Arman



[[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] Accepted packages can't find each other and fail build

[Hervé Pagès]

FYI today's data-experiment builds completed and pcxnData is
green:


https://bioconductor.org/checkResults/3.6/data-experiment-LATEST/pcxnData/

and propagated:

  https://bioconductor.org/packages/3.6/data/experiment/html/pcxnData.html

Now the next step is that the software builds will be able
to install pcxnData on tokay1 (Windows) and veracruz1 (Mac)
from the public data-experiment repo so the results for
pcxn should get cleared tomorrow:

  https://bioconductor.org/checkResults/3.6/bioc-LATEST/pcxn/

It's a long (and admittedly confusing) ping-pong game between the
software and data-expriment builds ;-)

Thanks for your patience,
H.

On 11/01/2017 08:21 AM, Hervé Pagès wrote:

Hi Sokratis,

Not sure why but it seems that for some reason the build machines
didn't manage to install pcxn so far. Until only now. I went on
build machine malbec1 to check whether it managed to install pcxn,
and it seems that it did:

   > "pcxn" %in% rownames(installed.packages())
   [1] TRUE

According to the log, it looks like this is the 1st time that it
gets installed on malbec1 (the data experiment builds just started
today and did the installation).

So, if everything goes as expected, pcxnData should build successfully
today and pcxnData should propagate (granted of course that it also
passes CHECK). The build/check report for data-experiment packages
should update today around 5pm EST. It will take about 1 hour after
the report is updated for pcxnData to propagate to the public repo
and for its landing page to show up.

Sorry for the inconvenience,

H.

On 11/01/2017 01:36 AM, Sokratis Kariotis wrote:

Hey all,

After the release I can see the release page of the pcxn package but not
pcxnData package. In the build page it says it cannot find the pcxn
package and fails.

Regards,
Sokratis

On 31 October 2017 at 16:33, Shepherd, Lori
>
wrote:

It should be the same and you should be able to see the RELEASE_3_6
branch


git fetch --all

git branch -a


Lori Shepherd

Bioconductor Core Team

Roswell Park Cancer Institute

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263



*From:* Sokratis Kariotis >
*Sent:* Tuesday, October 31, 2017 11:20:39 AM
*To:* Shepherd, Lori
*Cc:* Hervé Pagès; Obenchain, Valerie; bioc-devel

*Subject:* Re: [Bioc-devel] Accepted packages can't find each other
and fail build
Does the same hold for the pcxnData package? I can't see the
RELEASE_3_6 as in pcxn.

-Sokratis

On 31 October 2017 at 11:38, Shepherd, Lori
> wrote:

The latest version bump change you made to 0.99.27 was yesterday
Oct 30 right before we said to stop committing so we could make
the release branch.  That change did make it into both the
RELEASE_3_6 and the master branch and should appear in the next
build report for both versions.


Note:  It can take 12-24 hours to see version bumps and changes
on the build report. The daily builders runs once per day to
build all the packages; while a version bump is absolutely
required, it is not built instantaneously on a version bump.


Please be sure to pull from upstream before making further
changes as we have bumped the versions in both the release and
devel versions of packages for the release.



Lori Shepherd

Bioconductor Core Team

Roswell Park Cancer Institute

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263



*From:* Sokratis Kariotis >
*Sent:* Tuesday, October 31, 2017 5:21:21 AM
*To:* Hervé Pagès
*Cc:* Obenchain, Valerie; Shepherd, Lori; bioc-devel
*Subject:* Re: [Bioc-devel] Accepted packages can't find each
other and fail build
Hi all,

There was an error in the pcxn package (and pcxnData as a resut
of not finding pcxn since it didnt build) which I fixed
yesterday morning, but it doesnt seem to accept my changes as
the version in the build report is not the last one I created
but the erroneous one (2 days ago). I checked the upstream of my
package and it has my latest changes.

Regards,
Sokratis

On 27 October 2017 at 16:57, Hervé Pagès > wrote:

Hi guys,

On 10/27/2017 05:50 AM, Obenchain, Valerie wrote:

Hi Sokratis,

  

Re: [Bioc-devel] Package update not showing on Bioc 3.6 webpage

[kushal kumar dey]

Thanks so much for the help.  I did manage to push with the SSH protocol.
Will wait till the next build to see if it went through.

Best

Kushal

On 1 November 2017 at 16:18, Turaga, Nitesh 
wrote:

> Hi Kushal,
>
> You also need to use the “SSH” protocol, and not the “HTTPS” protocol.
>
> Your upstream should be g...@git.bioconductor.org:packages/CountClust
>
> Best,
>
> Nitesh
>
> > On Nov 1, 2017, at 5:06 PM, Turaga, Nitesh 
> wrote:
> >
> > Hi Kushal,
> >
> > Can you please try,
> >
> >   ssh -T g...@git.bioconductor.org -v
> >
> >
> > Are you using the correct private key to your corresponding public key
> on our machine?
> >
> > If not, please check the FAQ section bioconductor.org/developers/
> how-to/git/faq/ point#15. You can set up a config file to use the correct
> private key.
> >
> > A snippet of your public key on our machine is,
> >
> > ssh-rsa B3NzaC1yc2EDAQABAAACAQC8EgObkc/
> OI4nc8NE0sL4COb6uNaBIURhJoSyisz8i8/KWum0xFhav7ouDpMoZz0lgnlRaIYIR
> quJx0R44ojDcsN45TBR8Rna4PNBscVJEsbonD0k3wi2OBySgwxTzL5aZl99H
> zuAzthAPzFuskZDHahws9sPUtWMxioI6D5ZktVOb/QJbDJdFHFPXcd8l90wRJN0eGJXX9ex
> cJBDU57ufEgDBx9vGv85GTwJjP4UQYLyjDIap2CbrdC+7nJ95fa7YcNUj2znVFcrNnkW9
> >
> > Best,
> >
> > Nitesh
> >
> >
> >> On Nov 1, 2017, at 2:23 PM, kushal kumar dey  wrote:
> >>
> >> Hi Herve,
> >>
> >> Thanks for clarifying on the matter. I followed your instructions and
> did *git
> >> cherry-pick* to make the following changes
> >>
> >> - fix a bug in one of the functions
> >> - add a citation
> >> - fix the readme
> >>
> >> I bumped the version number from 1.4.0 to 1.4.1 and tried to push to the
> >> release branch, but I when I run the command,
> >>
> >> git push upstream RELEASE_3_6
> >>
> >> I meet with the following error
> >>
> >> *fatal: remote error: FATAL: W any packages/CountClust nobody DENIED by
> >> fallthru*
> >>
> >> *(or you mis-spelled the reponame)*
> >>
> >>
> >> You can check the branch I want to push on my Github
> >>
> >>
> >>
> >> *https://github.com/kkdey/CountClust/tree/RELEASE_3_6
> >> *
> >>
> >>
> >> This is my output from *git remote -v *
> >>
> >> *origin https://github.com/kkdey/CountClust.git
> >>  (fetch)*
> >>
> >> *origin https://github.com/kkdey/CountClust.git
> >>  (push)*
> >>
> >> *upstream https://git.bioconductor.org/packages/CountClust
> >>  (fetch)*
> >>
> >> *upstream https://git.bioconductor.org/packages/CountClust
> >>  (push)*
> >>
> >>
> >> Can you please let me know what I am doing wrong here and how I can
> update
> >> the release version?
> >>
> >>
> >> Thank you so much!
> >>
> >>
> >> Kushal
> >>
> >>
> >>
> >>
> >>
> >> On 30 October 2017 at 17:50, Hervé Pagès  wrote:
> >>
> >>> Hi Kushal,
> >>>
> >>> If you push changes without bumping the version of your package,
> >>> the update won't propagate.
> >>>
> >>> You only bumped the version to 1.5.1 today so you need to wait
> >>> about 24 hours before seeing this reflected on the landing page
> >>> for CountClust.
> >>>
> >>> Also please note that you did the version bump plus a few other
> >>> commits (6 commits in total) in master today **after** we created
> >>> the RELEASE_3_6 branch so these changes will only propagate to
> >>> BioC 3.7 (the new devel version of BioC, starting tomorrow).
> >>> If you want these changes to also propagate to the BioC 3.6 release
> >>> you'll need to push them to the RELEASE_3_6 branch. This is
> >>> typically done with 'git cherry-pick' as documented here:
> >>>
> >>>
> >>> https://bioconductor.org/developers/how-to/git/bug-fix-in-
> >>> release-and-devel/
> >>>
> >>> Cheers,
> >>> H.
> >>>
> >>>
> >>> On 10/30/2017 02:41 PM, kushal kumar dey wrote:
> >>>
>  Hi all,
> 
>  I am the author and maintainer of the CountClust package. I recently
>  submitted an update (version 1.5.1) to the package through
>  Bioconductor Git  and I can access this updated version when I clone
> the
>  source repository
> 
>  git clone https://urldefense.proofpoint.
> com/v2/url?u=https-3A__git.bio
>  conductor.org_packages_CountClust=DwICAg=eRAMFD45gAfqt84
>  VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=-x3S
>  8Sl0fsASITg_-ULMYIykoPk6Y0PqK2NoRjC43iA=YBM0DldFbCkrEBnHaB
>  n5X8-jb1yhm_GmSUWL6SIGLmo=
> 
>  However, the updated version is not available in the official
> Bioconductor
>  3.6 page, which still shows the version 1.3.0.
> 
>  https://urldefense.proofpoint.com/v2/url?u=https-3A__www.bio
>  conductor.org_packages_3.6_bioc_html_CountClust.html=DwICA
>  g=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvS
>  XAJJKaaPhzWA=-x3S8Sl0fsASITg_-ULMYIykoPk6Y0PqK2NoRjC43iA&
> 

Re: [Bioc-devel] Confusion with how to maintain release/devel files on local computer.

[Laurent Gatto]

On  1 November 2017 20:36, Arman Shahrisa wrote:

> I'm confused with development process.
>
> At first, I need to have a folder with accepted packaged. Then I need to pull
> origion RELEASE_3_6?
>
> Then in another folder, I need to pull origion master?

No, it all happens in the same folder, but switching between branches
using git. Here's an example of one of my own packages. The first
command list all available branches (all, using -a, means also
remote-only branches). My current branch is noted with an *, and I also
have a feature branch called writeMSData, which also lives on GitHub
(https://github.com/lgatto/MSnbase/, but that's optional).

$ git branch -a
  devel
* master
  writeMSData
  remotes/origin/HEAD -> origin/master
  remotes/origin/centroiding
  remotes/origin/fixBracketSubset
  remotes/origin/issue82
  remotes/origin/master
  remotes/origin/orbifilter
  remotes/origin/processingData
  remotes/origin/removePrecMz
  remotes/origin/writeMSData
  remotes/upstream/RELEASE_2_10
  remotes/upstream/RELEASE_2_11
  remotes/upstream/RELEASE_2_12
  remotes/upstream/RELEASE_2_13
  remotes/upstream/RELEASE_2_14
  remotes/upstream/RELEASE_2_8
  remotes/upstream/RELEASE_2_9
  remotes/upstream/RELEASE_3_0
  remotes/upstream/RELEASE_3_1
  remotes/upstream/RELEASE_3_2
  remotes/upstream/RELEASE_3_3
  remotes/upstream/RELEASE_3_4
  remotes/upstream/RELEASE_3_5
  remotes/upstream/master

As you can see (and as specified by Gabe in his earlier reply), I
haven't have pulled all Bioconductor releases. master points to GitHub's
origin/master branch, and devel points to Bioconductor's
upstream/master. As you can see above, I haven't got the latest release
references yet. I can do this with

$ git fetch --all
Fetching origin
Fetching upstream
remote: Counting objects: 6, done.
remote: Compressing objects: 100% (6/6), done.
remote: Total 6 (delta 4), reused 0 (delta 0)
Unpacking objects: 100% (6/6), done.
>From git.bioconductor.org:packages/MSnbase
 * [new branch]  RELEASE_3_6 -> upstream/RELEASE_3_6
   b680678..a98138c  master -> upstream/master

And now

$ git branch -a  
  devel
* master
  writeMSData
  remotes/origin/HEAD -> origin/master
  remotes/origin/centroiding
  remotes/origin/fixBracketSubset
  remotes/origin/issue82
  remotes/origin/master
  remotes/origin/orbifilter
  remotes/origin/processingData
  remotes/origin/removePrecMz
  remotes/origin/writeMSData
  remotes/upstream/RELEASE_2_10
  remotes/upstream/RELEASE_2_11
  remotes/upstream/RELEASE_2_12
  remotes/upstream/RELEASE_2_13
  remotes/upstream/RELEASE_2_14
  remotes/upstream/RELEASE_2_8
  remotes/upstream/RELEASE_2_9
  remotes/upstream/RELEASE_3_0
  remotes/upstream/RELEASE_3_1
  remotes/upstream/RELEASE_3_2
  remotes/upstream/RELEASE_3_3
  remotes/upstream/RELEASE_3_4
  remotes/upstream/RELEASE_3_5
  remotes/upstream/RELEASE_3_6
  remotes/upstream/master

If I want to modify the development branch (i.e. Bioconductor's
upstreams/master), then I checkout devel (that's how I named it
locally), do changes and push.

$ git checkout devel
## do stuff
$ git push

Same principle for other branches.

> So that by opening each folder, I know what I'm editing.
> Also during push, I need to be careful about where I'm pushing changes.
> Origion is bioc's git address of my package whereas master is the package 
> directory in GitHub?

No - I suggest you read a bit about git (GitHub is a web interface using
git) to familiarise yourself with the concepts and vocabulary.

> Am I getting it correct?
> Is there anywhere that contains whole the process and codes in steps?

All the setup and more details are provided in 

  https://github.com/bioconductor/bioc_git_transition/

in particular the FAQ and all the scenarios at the bottom

  https://github.com/Bioconductor/bioc_git_transition/blob/master/doc/faq.md

Best wishes,

Laurent

> Best regards,
> Arman
>
>
>
>   [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel


-- 
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] any interest in a BiocMatrix core package?

[Martin Morgan]

On 11/01/2017 05:15 PM, Bemis, Kylie wrote:

Yes, the ideal solution seems rather unlikely, but I feel like there must be a 
solution better than the current situation.

I’d like to implement some more of the functionality from matrixStats for 
‘matter’ matrices, but importing DelayedArray and DelayedMatrixStats solely for 
the generic functions seems like a bit much. Is that the best thing to do 
though?


It would be very helpful to have this on CRAN, and for matrixStats (and 
Matrix) to play along.


Martin




Any suggestions?

-Kylie


On Nov 1, 2017, at 4:59 PM, Hervé Pagès  wrote:

That's probably a good idea but a clean solution would need to
involve all players, including the Matrix package. Right now there
are conflicts for some S4 generics defined in Matrix and in
BiocGenerics (e.g. rowSums). I'm not sure that moving rowSums from
BiocGenerics to a new MatrixGenerics package would address this.
Unless MatrixGenerics is on CRAN and Matrix depends on it ;-)

How likely is this to happen?

H.

On 11/01/2017 01:44 PM, Peter Hickey wrote:

I think that's a good idea, Kylie.
Pete (DelayedMatrixStats developer)

On Thu., 2 Nov. 2017, 6:09 am Kasper Daniel Hansen, <
kasperdanielhan...@gmail.com> wrote:


I think it makes sense. A lot of sense. Might be useful to involve Henrik
(matrixStats) as well.

Who are the players, apart from DelayedArray/DelayedMatrixStats and matter?
(and some very old stuff in Biobase which should really be deprecated in
favor of matrixStats).

Best,
Kasper

On Wed, Nov 1, 2017 at 3:03 PM, Bemis, Kylie 
wrote:


Hi all,

To continue a variant of this conversation, with the latest BioC release,
we now have quite a few packages that are implementing various
matrix-related S4 generic functions, many of them relying on matrixStats

as

a template.

I was wondering if there is any interest or intention to create a common
MatrixGenerics/ArrayGenerics package on which we can depend to import the
relevant S4 generic functions. Although BiocGeneric has a few like
‘rowSums()’ and ‘colMeans()’, etc., there are many more that are
implemented across ‘DelayedArray', ‘DelayedMatrixStats', my own package
‘matter', etc., including ‘apply()’, ‘rowSds()’, ‘colVars()’, and so

forth.


It would be nice to have a single package with minimal additional
dependencies (a la BiocGenerics) where we could import the various S4
generics and avoid unwanted namespace collisions.

Have there been any thoughts on this?

Many thanks,
Kylie

~~~
Kylie Ariel Bemis
Future Faculty Fellow
College of Computer and Information Science
Northeastern University
kuwisdelu.github.io




On Mar 3, 2017, at 11:27 AM, Kasper Daniel Hansen <
kasperdanielhan...@gmail.com>

wrote:




On Fri, Mar 3, 2017 at 10:22 AM, Vincent Carey <

st...@channing.harvard.edu

> wrote:


On Fri, Mar 3, 2017 at 10:07 AM, Kasper Daniel Hansen <
kasperdanielhan...@gmail.com>

wrote:

Some comment on Aaron's stuff

One possibility for doing things like this is if your code can be done in
C++ using a subset of rows or columns.  That can sometimes give the
necessary speed up.  What I mean is this

Say you can safely process 1000 cells (not matrix cells, but biological
cells, aka columns) at a time in RAM

iterate in R:
   get chunk i containing 1000 cells from the backend data storage
   do something on this sub matrix where everything is in a normal matrix
and you just use C++
   write results out to whatever backend you're using

Then, with a million cells you iterate over 1000 chunks in R.  And you
don't need to "touch" the full dataset which can be stored on an

arbitrary

backend.

you "touch" it, but you never ingest the whole thing at any time, is that
what you mean?

Yes, you load the chunk into RAM and then just deal with it.

Think of doing 10^10 linear models.  If this was 10^6 I would just use
lmFit.  But 10^10 doesn't fit into memory.  So I load 10^7 into memory,

run

lmFit, store results, redo.  This is bound to be much more efficient than
loading a single row into memory and doing lm 10^10 times, because lmFit

is

written to do many linear models at the same time.

I am suggesting that this is a potential general strategy.


And this approach could be run even (potentially) with different chunks

on

different nodes.

that seems to me to be an important if not essential desideratum.

what then is the role of C++?  extracting a chunk?  preexisting

utilities?


When I say C++ I just mean write an efficient implementation that works

on

a chunk, like lmFit.  It is true that anything that works on a chunk will
work on a single row/column (like 

Re: [Bioc-devel] any interest in a BiocMatrix core package?

[Douglas Bates]

I suggest that you cc Martin Maechler on this discussion.  I happen to be
on the Bioc-devel list but I'm not sure if he is.  Although both of us are
still listed as maintainers of the Matrix package, he is, and has been for
several years, the de facto maintainer.

On Wed, Nov 1, 2017 at 4:15 PM Bemis, Kylie 
wrote:

> Yes, the ideal solution seems rather unlikely, but I feel like there must
> be a solution better than the current situation.
>
> I’d like to implement some more of the functionality from matrixStats for
> ‘matter’ matrices, but importing DelayedArray and DelayedMatrixStats solely
> for the generic functions seems like a bit much. Is that the best thing to
> do though?
>
> Any suggestions?
>
> -Kylie
>
> > On Nov 1, 2017, at 4:59 PM, Hervé Pagès  wrote:
> >
> > That's probably a good idea but a clean solution would need to
> > involve all players, including the Matrix package. Right now there
> > are conflicts for some S4 generics defined in Matrix and in
> > BiocGenerics (e.g. rowSums). I'm not sure that moving rowSums from
> > BiocGenerics to a new MatrixGenerics package would address this.
> > Unless MatrixGenerics is on CRAN and Matrix depends on it ;-)
> >
> > How likely is this to happen?
> >
> > H.
> >
> > On 11/01/2017 01:44 PM, Peter Hickey wrote:
> >> I think that's a good idea, Kylie.
> >> Pete (DelayedMatrixStats developer)
> >>
> >> On Thu., 2 Nov. 2017, 6:09 am Kasper Daniel Hansen, <
> >> kasperdanielhan...@gmail.com> wrote:
> >>
> >>> I think it makes sense. A lot of sense. Might be useful to involve
> Henrik
> >>> (matrixStats) as well.
> >>>
> >>> Who are the players, apart from DelayedArray/DelayedMatrixStats and
> matter?
> >>> (and some very old stuff in Biobase which should really be deprecated
> in
> >>> favor of matrixStats).
> >>>
> >>> Best,
> >>> Kasper
> >>>
> >>> On Wed, Nov 1, 2017 at 3:03 PM, Bemis, Kylie  >
> >>> wrote:
> >>>
>  Hi all,
> 
>  To continue a variant of this conversation, with the latest BioC
> release,
>  we now have quite a few packages that are implementing various
>  matrix-related S4 generic functions, many of them relying on
> matrixStats
> >>> as
>  a template.
> 
>  I was wondering if there is any interest or intention to create a
> common
>  MatrixGenerics/ArrayGenerics package on which we can depend to import
> the
>  relevant S4 generic functions. Although BiocGeneric has a few like
>  ‘rowSums()’ and ‘colMeans()’, etc., there are many more that are
>  implemented across ‘DelayedArray', ‘DelayedMatrixStats', my own
> package
>  ‘matter', etc., including ‘apply()’, ‘rowSds()’, ‘colVars()’, and so
> >>> forth.
> 
>  It would be nice to have a single package with minimal additional
>  dependencies (a la BiocGenerics) where we could import the various S4
>  generics and avoid unwanted namespace collisions.
> 
>  Have there been any thoughts on this?
> 
>  Many thanks,
>  Kylie
> 
>  ~~~
>  Kylie Ariel Bemis
>  Future Faculty Fellow
>  College of Computer and Information Science
>  Northeastern University
>  kuwisdelu.github.io<
> https://urldefense.proofpoint.com/v2/url?u=https-3A__kuwisdelu.github.io=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=rB5bgdmBaBGWPSNktamrt-mzOZWaJ649FWWr_wCcCEs=jvekQlr-c1DbU0g-P5b_FApuAd33vBk3IMDG5F_slQo=
> >
> 
> 
> 
> 
>  On Mar 3, 2017, at 11:27 AM, Kasper Daniel Hansen <
>  kasperdanielhan...@gmail.com>
> >>> wrote:
> 
> 
> 
>  On Fri, Mar 3, 2017 at 10:22 AM, Vincent Carey <
> >>> st...@channing.harvard.edu
>  > wrote:
> 
> 
>  On Fri, Mar 3, 2017 at 10:07 AM, Kasper Daniel Hansen <
>  kasperdanielhan...@gmail.com>
> >>> wrote:
>  Some comment on Aaron's stuff
> 
>  One possibility for doing things like this is if your code can be
> done in
>  C++ using a subset of rows or columns.  That can sometimes give the
>  necessary speed up.  What I mean is this
> 
>  Say you can safely process 1000 cells (not matrix cells, but
> biological
>  cells, aka columns) at a time in RAM
> 
>  iterate in R:
>    get chunk i containing 1000 cells from the backend data storage
>    do something on this sub matrix where everything is in a normal
> matrix
>  and you just use C++
>    write results out to whatever backend you're using
> 
>  Then, with a million cells you iterate over 1000 chunks in R.  And you
>  don't need to "touch" the full dataset which can be stored on an
> >>> arbitrary
>  backend.
> 
>  you "touch" it, but you never ingest the whole thing at any time, is
> that
>  what you mean?
> 
>  Yes, you load the chunk into RAM and then just 

Re: [Bioc-devel] Confusion with how to maintain release/devel files on local computer.

[Martin Morgan]

On 11/01/2017 04:42 PM, Gabe Becker wrote:

Arman,

Not on the Bioc team per se, but I would say only have a checkout of the
release branch when you need it, ie a bug is reported, you have fixed it in
devel, and you are ready to push the very narrow bugfix to release. I only
keep "master" checkouts of my packages on a permanent basis.


In case Arman is not aware, the basic scenarios are at

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

the most straight-forward of which (a clone of the Bioconductor git 
repository, no GitHub mirror) is


  https://bioconductor.org/developers/how-to/git/maintain-bioc-only/

Generally, one has only a single local git repository, switching between 
branches within that repository.


Martin



You generally shouldn't need a checkout of release, imho, because no
development should be happening there with exception of the case above.

Hope that helps,
~G

On Wed, Nov 1, 2017 at 1:36 PM, Arman Shahrisa 
wrote:


I’m confused with development process.

At first, I need to have a folder with accepted packaged. Then I need to
pull
origion RELEASE_3_6?

Then in another folder, I need to pull origion master?

So that by opening each folder, I know what I’m editing.
Also during push, I need to be careful about where I’m pushing changes.
Origion is bioc’s git address of my package whereas master is the package
directory in GitHub?

Am I getting it correct?
Is there anywhere that contains whole the process and codes in steps?

Best regards,
Arman



 [[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...{{dropped:2}}

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

Re: [Bioc-devel] Package update not showing on Bioc 3.6 webpage

[Turaga, Nitesh]

Hi Kushal,

You also need to use the “SSH” protocol, and not the “HTTPS” protocol.

Your upstream should be g...@git.bioconductor.org:packages/CountClust

Best,

Nitesh 

> On Nov 1, 2017, at 5:06 PM, Turaga, Nitesh  
> wrote:
> 
> Hi Kushal,
> 
> Can you please try,
> 
>   ssh -T g...@git.bioconductor.org -v
> 
> 
> Are you using the correct private key to your corresponding public key on our 
> machine?
> 
> If not, please check the FAQ section 
> bioconductor.org/developers/how-to/git/faq/ point#15. You can set up a config 
> file to use the correct private key.
> 
> A snippet of your public key on our machine is,
> 
> ssh-rsa 
> B3NzaC1yc2EDAQABAAACAQC8EgObkc/OI4nc8NE0sL4COb6uNaBIURhJoSyisz8i8/KWum0xFhav7ouDpMoZz0lgnlRaIYIRquJx0R44ojDcsN45TBR8Rna4PNBscVJEsbonD0k3wi2OBySgwxTzL5aZl99HzuAzthAPzFuskZDHahws9sPUtWMxioI6D5ZktVOb/QJbDJdFHFPXcd8l90wRJN0eGJXX9excJBDU57ufEgDBx9vGv85GTwJjP4UQYLyjDIap2CbrdC+7nJ95fa7YcNUj2znVFcrNnkW9
> 
> Best,
> 
> Nitesh 
> 
> 
>> On Nov 1, 2017, at 2:23 PM, kushal kumar dey  wrote:
>> 
>> Hi Herve,
>> 
>> Thanks for clarifying on the matter. I followed your instructions and did 
>> *git
>> cherry-pick* to make the following changes
>> 
>> - fix a bug in one of the functions
>> - add a citation
>> - fix the readme
>> 
>> I bumped the version number from 1.4.0 to 1.4.1 and tried to push to the
>> release branch, but I when I run the command,
>> 
>> git push upstream RELEASE_3_6
>> 
>> I meet with the following error
>> 
>> *fatal: remote error: FATAL: W any packages/CountClust nobody DENIED by
>> fallthru*
>> 
>> *(or you mis-spelled the reponame)*
>> 
>> 
>> You can check the branch I want to push on my Github
>> 
>> 
>> 
>> *https://github.com/kkdey/CountClust/tree/RELEASE_3_6
>> *
>> 
>> 
>> This is my output from *git remote -v *
>> 
>> *origin https://github.com/kkdey/CountClust.git
>>  (fetch)*
>> 
>> *origin https://github.com/kkdey/CountClust.git
>>  (push)*
>> 
>> *upstream https://git.bioconductor.org/packages/CountClust
>>  (fetch)*
>> 
>> *upstream https://git.bioconductor.org/packages/CountClust
>>  (push)*
>> 
>> 
>> Can you please let me know what I am doing wrong here and how I can update
>> the release version?
>> 
>> 
>> Thank you so much!
>> 
>> 
>> Kushal
>> 
>> 
>> 
>> 
>> 
>> On 30 October 2017 at 17:50, Hervé Pagès  wrote:
>> 
>>> Hi Kushal,
>>> 
>>> If you push changes without bumping the version of your package,
>>> the update won't propagate.
>>> 
>>> You only bumped the version to 1.5.1 today so you need to wait
>>> about 24 hours before seeing this reflected on the landing page
>>> for CountClust.
>>> 
>>> Also please note that you did the version bump plus a few other
>>> commits (6 commits in total) in master today **after** we created
>>> the RELEASE_3_6 branch so these changes will only propagate to
>>> BioC 3.7 (the new devel version of BioC, starting tomorrow).
>>> If you want these changes to also propagate to the BioC 3.6 release
>>> you'll need to push them to the RELEASE_3_6 branch. This is
>>> typically done with 'git cherry-pick' as documented here:
>>> 
>>> 
>>> https://bioconductor.org/developers/how-to/git/bug-fix-in-
>>> release-and-devel/
>>> 
>>> Cheers,
>>> H.
>>> 
>>> 
>>> On 10/30/2017 02:41 PM, kushal kumar dey wrote:
>>> 
 Hi all,
 
 I am the author and maintainer of the CountClust package. I recently
 submitted an update (version 1.5.1) to the package through
 Bioconductor Git  and I can access this updated version when I clone the
 source repository
 
 git clone https://urldefense.proofpoint.com/v2/url?u=https-3A__git.bio
 conductor.org_packages_CountClust=DwICAg=eRAMFD45gAfqt84
 VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=-x3S
 8Sl0fsASITg_-ULMYIykoPk6Y0PqK2NoRjC43iA=YBM0DldFbCkrEBnHaB
 n5X8-jb1yhm_GmSUWL6SIGLmo=
 
 However, the updated version is not available in the official Bioconductor
 3.6 page, which still shows the version 1.3.0.
 
 https://urldefense.proofpoint.com/v2/url?u=https-3A__www.bio
 conductor.org_packages_3.6_bioc_html_CountClust.html=DwICA
 g=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvS
 XAJJKaaPhzWA=-x3S8Sl0fsASITg_-ULMYIykoPk6Y0PqK2NoRjC43iA&
 s=UfPX4T5l4JBfXBumCcQ-5YOm59i_xfX2OEILrQ3I2u0=
 
 Can you please let me know if the page has not been updated for the
 packages yet or if I would need to do something at my end to update the
 version reported on the page?
 
 Thanks so much
 
 
>>> --
>>> Hervé Pagès
>>> 
>>> Program in Computational Biology
>>> Division of Public Health Sciences
>>> Fred Hutchinson Cancer Research Ce
>>> 

Re: [Bioc-devel] any interest in a BiocMatrix core package?

[Bemis, Kylie]

Yes, the ideal solution seems rather unlikely, but I feel like there must be a 
solution better than the current situation.

I’d like to implement some more of the functionality from matrixStats for 
‘matter’ matrices, but importing DelayedArray and DelayedMatrixStats solely for 
the generic functions seems like a bit much. Is that the best thing to do 
though?

Any suggestions?

-Kylie

> On Nov 1, 2017, at 4:59 PM, Hervé Pagès  wrote:
> 
> That's probably a good idea but a clean solution would need to
> involve all players, including the Matrix package. Right now there
> are conflicts for some S4 generics defined in Matrix and in
> BiocGenerics (e.g. rowSums). I'm not sure that moving rowSums from
> BiocGenerics to a new MatrixGenerics package would address this.
> Unless MatrixGenerics is on CRAN and Matrix depends on it ;-)
> 
> How likely is this to happen?
> 
> H.
> 
> On 11/01/2017 01:44 PM, Peter Hickey wrote:
>> I think that's a good idea, Kylie.
>> Pete (DelayedMatrixStats developer)
>> 
>> On Thu., 2 Nov. 2017, 6:09 am Kasper Daniel Hansen, <
>> kasperdanielhan...@gmail.com> wrote:
>> 
>>> I think it makes sense. A lot of sense. Might be useful to involve Henrik
>>> (matrixStats) as well.
>>> 
>>> Who are the players, apart from DelayedArray/DelayedMatrixStats and matter?
>>> (and some very old stuff in Biobase which should really be deprecated in
>>> favor of matrixStats).
>>> 
>>> Best,
>>> Kasper
>>> 
>>> On Wed, Nov 1, 2017 at 3:03 PM, Bemis, Kylie 
>>> wrote:
>>> 
 Hi all,
 
 To continue a variant of this conversation, with the latest BioC release,
 we now have quite a few packages that are implementing various
 matrix-related S4 generic functions, many of them relying on matrixStats
>>> as
 a template.
 
 I was wondering if there is any interest or intention to create a common
 MatrixGenerics/ArrayGenerics package on which we can depend to import the
 relevant S4 generic functions. Although BiocGeneric has a few like
 ‘rowSums()’ and ‘colMeans()’, etc., there are many more that are
 implemented across ‘DelayedArray', ‘DelayedMatrixStats', my own package
 ‘matter', etc., including ‘apply()’, ‘rowSds()’, ‘colVars()’, and so
>>> forth.
 
 It would be nice to have a single package with minimal additional
 dependencies (a la BiocGenerics) where we could import the various S4
 generics and avoid unwanted namespace collisions.
 
 Have there been any thoughts on this?
 
 Many thanks,
 Kylie
 
 ~~~
 Kylie Ariel Bemis
 Future Faculty Fellow
 College of Computer and Information Science
 Northeastern University
 kuwisdelu.github.io
 
 
 
 
 On Mar 3, 2017, at 11:27 AM, Kasper Daniel Hansen <
 kasperdanielhan...@gmail.com>
>>> wrote:
 
 
 
 On Fri, Mar 3, 2017 at 10:22 AM, Vincent Carey <
>>> st...@channing.harvard.edu
 > wrote:
 
 
 On Fri, Mar 3, 2017 at 10:07 AM, Kasper Daniel Hansen <
 kasperdanielhan...@gmail.com>
>>> wrote:
 Some comment on Aaron's stuff
 
 One possibility for doing things like this is if your code can be done in
 C++ using a subset of rows or columns.  That can sometimes give the
 necessary speed up.  What I mean is this
 
 Say you can safely process 1000 cells (not matrix cells, but biological
 cells, aka columns) at a time in RAM
 
 iterate in R:
   get chunk i containing 1000 cells from the backend data storage
   do something on this sub matrix where everything is in a normal matrix
 and you just use C++
   write results out to whatever backend you're using
 
 Then, with a million cells you iterate over 1000 chunks in R.  And you
 don't need to "touch" the full dataset which can be stored on an
>>> arbitrary
 backend.
 
 you "touch" it, but you never ingest the whole thing at any time, is that
 what you mean?
 
 Yes, you load the chunk into RAM and then just deal with it.
 
 Think of doing 10^10 linear models.  If this was 10^6 I would just use
 lmFit.  But 10^10 doesn't fit into memory.  So I load 10^7 into memory,
>>> run
 lmFit, store results, redo.  This is bound to be much more efficient than
 loading a single row into memory and doing lm 10^10 times, because lmFit
>>> is
 written to do many linear models at the same time.
 
 I am suggesting that this is a potential general strategy.
 
 
 And this approach could be run even (potentially) with different chunks
>>> on
 

Re: [Bioc-devel] any interest in a BiocMatrix core package?

[Michael Lawrence]

Probably way easier to add the generics to the Matrix package and everyone
just depends on that.

On Wed, Nov 1, 2017 at 1:59 PM, Hervé Pagès  wrote:

> That's probably a good idea but a clean solution would need to
> involve all players, including the Matrix package. Right now there
> are conflicts for some S4 generics defined in Matrix and in
> BiocGenerics (e.g. rowSums). I'm not sure that moving rowSums from
> BiocGenerics to a new MatrixGenerics package would address this.
> Unless MatrixGenerics is on CRAN and Matrix depends on it ;-)
>
> How likely is this to happen?
>
> H.
>
>
> On 11/01/2017 01:44 PM, Peter Hickey wrote:
>
>> I think that's a good idea, Kylie.
>> Pete (DelayedMatrixStats developer)
>>
>> On Thu., 2 Nov. 2017, 6:09 am Kasper Daniel Hansen, <
>> kasperdanielhan...@gmail.com> wrote:
>>
>> I think it makes sense. A lot of sense. Might be useful to involve Henrik
>>> (matrixStats) as well.
>>>
>>> Who are the players, apart from DelayedArray/DelayedMatrixStats and
>>> matter?
>>> (and some very old stuff in Biobase which should really be deprecated in
>>> favor of matrixStats).
>>>
>>> Best,
>>> Kasper
>>>
>>> On Wed, Nov 1, 2017 at 3:03 PM, Bemis, Kylie 
>>> wrote:
>>>
>>> Hi all,

 To continue a variant of this conversation, with the latest BioC
 release,
 we now have quite a few packages that are implementing various
 matrix-related S4 generic functions, many of them relying on matrixStats

>>> as
>>>
 a template.

 I was wondering if there is any interest or intention to create a common
 MatrixGenerics/ArrayGenerics package on which we can depend to import
 the
 relevant S4 generic functions. Although BiocGeneric has a few like
 ‘rowSums()’ and ‘colMeans()’, etc., there are many more that are
 implemented across ‘DelayedArray', ‘DelayedMatrixStats', my own package
 ‘matter', etc., including ‘apply()’, ‘rowSds()’, ‘colVars()’, and so

>>> forth.
>>>

 It would be nice to have a single package with minimal additional
 dependencies (a la BiocGenerics) where we could import the various S4
 generics and avoid unwanted namespace collisions.

 Have there been any thoughts on this?

 Many thanks,
 Kylie

 ~~~
 Kylie Ariel Bemis
 Future Faculty Fellow
 College of Computer and Information Science
 Northeastern University
 kuwisdelu.github.io





 On Mar 3, 2017, at 11:27 AM, Kasper Daniel Hansen <
 kasperdanielhan...@gmail.com>

>>> wrote:
>>>



 On Fri, Mar 3, 2017 at 10:22 AM, Vincent Carey <

>>> st...@channing.harvard.edu
>>>
 > wrote:


 On Fri, Mar 3, 2017 at 10:07 AM, Kasper Daniel Hansen <
 kasperdanielhan...@gmail.com>

>>> wrote:
>>>
 Some comment on Aaron's stuff

 One possibility for doing things like this is if your code can be done
 in
 C++ using a subset of rows or columns.  That can sometimes give the
 necessary speed up.  What I mean is this

 Say you can safely process 1000 cells (not matrix cells, but biological
 cells, aka columns) at a time in RAM

 iterate in R:
get chunk i containing 1000 cells from the backend data storage
do something on this sub matrix where everything is in a normal
 matrix
 and you just use C++
write results out to whatever backend you're using

 Then, with a million cells you iterate over 1000 chunks in R.  And you
 don't need to "touch" the full dataset which can be stored on an

>>> arbitrary
>>>
 backend.

 you "touch" it, but you never ingest the whole thing at any time, is
 that
 what you mean?

 Yes, you load the chunk into RAM and then just deal with it.

 Think of doing 10^10 linear models.  If this was 10^6 I would just use
 lmFit.  But 10^10 doesn't fit into memory.  So I load 10^7 into memory,

>>> run
>>>
 lmFit, store results, redo.  This is bound to be much more efficient
 than
 loading a single row into memory and doing lm 10^10 times, because lmFit

>>> is
>>>
 written to do many linear models at the same time.

 I am suggesting that this is a potential general strategy.


 And this approach could be run even (potentially) with different chunks

>>> on
>>>
 different nodes.

 that seems to me to be an important if not essential desideratum.

 what then is the role of C++?  extracting a chunk?  preexisting

>>> 

Re: [Bioc-devel] Package update not showing on Bioc 3.6 webpage

[Turaga, Nitesh]

Hi Kushal,

Can you please try,

ssh -T g...@git.bioconductor.org -v


Are you using the correct private key to your corresponding public key on our 
machine?

If not, please check the FAQ section 
bioconductor.org/developers/how-to/git/faq/ point#15. You can set up a config 
file to use the correct private key.

A snippet of your public key on our machine is,

ssh-rsa 
B3NzaC1yc2EDAQABAAACAQC8EgObkc/OI4nc8NE0sL4COb6uNaBIURhJoSyisz8i8/KWum0xFhav7ouDpMoZz0lgnlRaIYIRquJx0R44ojDcsN45TBR8Rna4PNBscVJEsbonD0k3wi2OBySgwxTzL5aZl99HzuAzthAPzFuskZDHahws9sPUtWMxioI6D5ZktVOb/QJbDJdFHFPXcd8l90wRJN0eGJXX9excJBDU57ufEgDBx9vGv85GTwJjP4UQYLyjDIap2CbrdC+7nJ95fa7YcNUj2znVFcrNnkW9

Best,

Nitesh 


> On Nov 1, 2017, at 2:23 PM, kushal kumar dey  wrote:
> 
> Hi Herve,
> 
> Thanks for clarifying on the matter. I followed your instructions and did *git
> cherry-pick* to make the following changes
> 
> - fix a bug in one of the functions
> - add a citation
> - fix the readme
> 
> I bumped the version number from 1.4.0 to 1.4.1 and tried to push to the
> release branch, but I when I run the command,
> 
> git push upstream RELEASE_3_6
> 
> I meet with the following error
> 
> *fatal: remote error: FATAL: W any packages/CountClust nobody DENIED by
> fallthru*
> 
> *(or you mis-spelled the reponame)*
> 
> 
> You can check the branch I want to push on my Github
> 
> 
> 
> *https://github.com/kkdey/CountClust/tree/RELEASE_3_6
> *
> 
> 
> This is my output from *git remote -v *
> 
> *origin https://github.com/kkdey/CountClust.git
>  (fetch)*
> 
> *origin https://github.com/kkdey/CountClust.git
>  (push)*
> 
> *upstream https://git.bioconductor.org/packages/CountClust
>  (fetch)*
> 
> *upstream https://git.bioconductor.org/packages/CountClust
>  (push)*
> 
> 
> Can you please let me know what I am doing wrong here and how I can update
> the release version?
> 
> 
> Thank you so much!
> 
> 
> Kushal
> 
> 
> 
> 
> 
> On 30 October 2017 at 17:50, Hervé Pagès  wrote:
> 
>> Hi Kushal,
>> 
>> If you push changes without bumping the version of your package,
>> the update won't propagate.
>> 
>> You only bumped the version to 1.5.1 today so you need to wait
>> about 24 hours before seeing this reflected on the landing page
>> for CountClust.
>> 
>> Also please note that you did the version bump plus a few other
>> commits (6 commits in total) in master today **after** we created
>> the RELEASE_3_6 branch so these changes will only propagate to
>> BioC 3.7 (the new devel version of BioC, starting tomorrow).
>> If you want these changes to also propagate to the BioC 3.6 release
>> you'll need to push them to the RELEASE_3_6 branch. This is
>> typically done with 'git cherry-pick' as documented here:
>> 
>> 
>> https://bioconductor.org/developers/how-to/git/bug-fix-in-
>> release-and-devel/
>> 
>> Cheers,
>> H.
>> 
>> 
>> On 10/30/2017 02:41 PM, kushal kumar dey wrote:
>> 
>>> Hi all,
>>> 
>>> I am the author and maintainer of the CountClust package. I recently
>>> submitted an update (version 1.5.1) to the package through
>>> Bioconductor Git  and I can access this updated version when I clone the
>>> source repository
>>> 
>>> git clone https://urldefense.proofpoint.com/v2/url?u=https-3A__git.bio
>>> conductor.org_packages_CountClust=DwICAg=eRAMFD45gAfqt84
>>> VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=-x3S
>>> 8Sl0fsASITg_-ULMYIykoPk6Y0PqK2NoRjC43iA=YBM0DldFbCkrEBnHaB
>>> n5X8-jb1yhm_GmSUWL6SIGLmo=
>>> 
>>> However, the updated version is not available in the official Bioconductor
>>> 3.6 page, which still shows the version 1.3.0.
>>> 
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.bio
>>> conductor.org_packages_3.6_bioc_html_CountClust.html=DwICA
>>> g=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvS
>>> XAJJKaaPhzWA=-x3S8Sl0fsASITg_-ULMYIykoPk6Y0PqK2NoRjC43iA&
>>> s=UfPX4T5l4JBfXBumCcQ-5YOm59i_xfX2OEILrQ3I2u0=
>>> 
>>> Can you please let me know if the page has not been updated for the
>>> packages yet or if I would need to do something at my end to update the
>>> version reported on the page?
>>> 
>>> Thanks so much
>>> 
>>> 
>> --
>> Hervé Pagès
>> 
>> Program in Computational Biology
>> Division of Public Health Sciences
>> Fred Hutchinson Cancer Research Ce
>> nter
>> 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
>> 
> 
> 
> 
> -- 
> Kushal K. Dey
> Graduate Student
> 5 th Year, Department of Statistics
> University of Chicago
> Contact: +1 312-709-0680 | kk...@uchicago.edu
> 
>   [[alternative HTML version deleted]]
> 
> 

Re: [Bioc-devel] any interest in a BiocMatrix core package?

[Hervé Pagès]

That's probably a good idea but a clean solution would need to
involve all players, including the Matrix package. Right now there
are conflicts for some S4 generics defined in Matrix and in
BiocGenerics (e.g. rowSums). I'm not sure that moving rowSums from
BiocGenerics to a new MatrixGenerics package would address this.
Unless MatrixGenerics is on CRAN and Matrix depends on it ;-)

How likely is this to happen?

H.

On 11/01/2017 01:44 PM, Peter Hickey wrote:

I think that's a good idea, Kylie.
Pete (DelayedMatrixStats developer)

On Thu., 2 Nov. 2017, 6:09 am Kasper Daniel Hansen, <
kasperdanielhan...@gmail.com> wrote:


I think it makes sense. A lot of sense. Might be useful to involve Henrik
(matrixStats) as well.

Who are the players, apart from DelayedArray/DelayedMatrixStats and matter?
(and some very old stuff in Biobase which should really be deprecated in
favor of matrixStats).

Best,
Kasper

On Wed, Nov 1, 2017 at 3:03 PM, Bemis, Kylie 
wrote:


Hi all,

To continue a variant of this conversation, with the latest BioC release,
we now have quite a few packages that are implementing various
matrix-related S4 generic functions, many of them relying on matrixStats

as

a template.

I was wondering if there is any interest or intention to create a common
MatrixGenerics/ArrayGenerics package on which we can depend to import the
relevant S4 generic functions. Although BiocGeneric has a few like
‘rowSums()’ and ‘colMeans()’, etc., there are many more that are
implemented across ‘DelayedArray', ‘DelayedMatrixStats', my own package
‘matter', etc., including ‘apply()’, ‘rowSds()’, ‘colVars()’, and so

forth.


It would be nice to have a single package with minimal additional
dependencies (a la BiocGenerics) where we could import the various S4
generics and avoid unwanted namespace collisions.

Have there been any thoughts on this?

Many thanks,
Kylie

~~~
Kylie Ariel Bemis
Future Faculty Fellow
College of Computer and Information Science
Northeastern University
kuwisdelu.github.io




On Mar 3, 2017, at 11:27 AM, Kasper Daniel Hansen <
kasperdanielhan...@gmail.com>

wrote:




On Fri, Mar 3, 2017 at 10:22 AM, Vincent Carey <

st...@channing.harvard.edu

> wrote:


On Fri, Mar 3, 2017 at 10:07 AM, Kasper Daniel Hansen <
kasperdanielhan...@gmail.com>

wrote:

Some comment on Aaron's stuff

One possibility for doing things like this is if your code can be done in
C++ using a subset of rows or columns.  That can sometimes give the
necessary speed up.  What I mean is this

Say you can safely process 1000 cells (not matrix cells, but biological
cells, aka columns) at a time in RAM

iterate in R:
   get chunk i containing 1000 cells from the backend data storage
   do something on this sub matrix where everything is in a normal matrix
and you just use C++
   write results out to whatever backend you're using

Then, with a million cells you iterate over 1000 chunks in R.  And you
don't need to "touch" the full dataset which can be stored on an

arbitrary

backend.

you "touch" it, but you never ingest the whole thing at any time, is that
what you mean?

Yes, you load the chunk into RAM and then just deal with it.

Think of doing 10^10 linear models.  If this was 10^6 I would just use
lmFit.  But 10^10 doesn't fit into memory.  So I load 10^7 into memory,

run

lmFit, store results, redo.  This is bound to be much more efficient than
loading a single row into memory and doing lm 10^10 times, because lmFit

is

written to do many linear models at the same time.

I am suggesting that this is a potential general strategy.


And this approach could be run even (potentially) with different chunks

on

different nodes.

that seems to me to be an important if not essential desideratum.

what then is the role of C++?  extracting a chunk?  preexisting

utilities?


When I say C++ I just mean write an efficient implementation that works

on

a chunk, like lmFit.  It is true that anything that works on a chunk will
work on a single row/column (like lmFit) but there are possibilities for
optimization when you work at the chunk level.

Obviously not all computations can be done chunkwise.  But for those that
can, this is a strategy which is independent of the data backend.

I wonder whether this "obviously not" needs to be rethought.  Algorithms
that are implemented to work with data holistically may need
to be reexpressed so that they can succeed with chunkwise access.  Is

this

a new mindset needed for holist developers, or can the
effective data decompositions occur autonomously?

Well, I would say it is obvious that not all computations can be done

Re: [Bioc-devel] any interest in a BiocMatrix core package?

[Peter Hickey]

I think that's a good idea, Kylie.
Pete (DelayedMatrixStats developer)

On Thu., 2 Nov. 2017, 6:09 am Kasper Daniel Hansen, <
kasperdanielhan...@gmail.com> wrote:

> I think it makes sense. A lot of sense. Might be useful to involve Henrik
> (matrixStats) as well.
>
> Who are the players, apart from DelayedArray/DelayedMatrixStats and matter?
> (and some very old stuff in Biobase which should really be deprecated in
> favor of matrixStats).
>
> Best,
> Kasper
>
> On Wed, Nov 1, 2017 at 3:03 PM, Bemis, Kylie 
> wrote:
>
> > Hi all,
> >
> > To continue a variant of this conversation, with the latest BioC release,
> > we now have quite a few packages that are implementing various
> > matrix-related S4 generic functions, many of them relying on matrixStats
> as
> > a template.
> >
> > I was wondering if there is any interest or intention to create a common
> > MatrixGenerics/ArrayGenerics package on which we can depend to import the
> > relevant S4 generic functions. Although BiocGeneric has a few like
> > ‘rowSums()’ and ‘colMeans()’, etc., there are many more that are
> > implemented across ‘DelayedArray', ‘DelayedMatrixStats', my own package
> > ‘matter', etc., including ‘apply()’, ‘rowSds()’, ‘colVars()’, and so
> forth.
> >
> > It would be nice to have a single package with minimal additional
> > dependencies (a la BiocGenerics) where we could import the various S4
> > generics and avoid unwanted namespace collisions.
> >
> > Have there been any thoughts on this?
> >
> > Many thanks,
> > Kylie
> >
> > ~~~
> > Kylie Ariel Bemis
> > Future Faculty Fellow
> > College of Computer and Information Science
> > Northeastern University
> > kuwisdelu.github.io
> >
> >
> >
> >
> > On Mar 3, 2017, at 11:27 AM, Kasper Daniel Hansen <
> > kasperdanielhan...@gmail.com>
> wrote:
> >
> >
> >
> > On Fri, Mar 3, 2017 at 10:22 AM, Vincent Carey <
> st...@channing.harvard.edu
> > > wrote:
> >
> >
> > On Fri, Mar 3, 2017 at 10:07 AM, Kasper Daniel Hansen <
> > kasperdanielhan...@gmail.com>
> wrote:
> > Some comment on Aaron's stuff
> >
> > One possibility for doing things like this is if your code can be done in
> > C++ using a subset of rows or columns.  That can sometimes give the
> > necessary speed up.  What I mean is this
> >
> > Say you can safely process 1000 cells (not matrix cells, but biological
> > cells, aka columns) at a time in RAM
> >
> > iterate in R:
> >   get chunk i containing 1000 cells from the backend data storage
> >   do something on this sub matrix where everything is in a normal matrix
> > and you just use C++
> >   write results out to whatever backend you're using
> >
> > Then, with a million cells you iterate over 1000 chunks in R.  And you
> > don't need to "touch" the full dataset which can be stored on an
> arbitrary
> > backend.
> >
> > you "touch" it, but you never ingest the whole thing at any time, is that
> > what you mean?
> >
> > Yes, you load the chunk into RAM and then just deal with it.
> >
> > Think of doing 10^10 linear models.  If this was 10^6 I would just use
> > lmFit.  But 10^10 doesn't fit into memory.  So I load 10^7 into memory,
> run
> > lmFit, store results, redo.  This is bound to be much more efficient than
> > loading a single row into memory and doing lm 10^10 times, because lmFit
> is
> > written to do many linear models at the same time.
> >
> > I am suggesting that this is a potential general strategy.
> >
> >
> > And this approach could be run even (potentially) with different chunks
> on
> > different nodes.
> >
> > that seems to me to be an important if not essential desideratum.
> >
> > what then is the role of C++?  extracting a chunk?  preexisting
> utilities?
> >
> > When I say C++ I just mean write an efficient implementation that works
> on
> > a chunk, like lmFit.  It is true that anything that works on a chunk will
> > work on a single row/column (like lmFit) but there are possibilities for
> > optimization when you work at the chunk level.
> >
> > Obviously not all computations can be done chunkwise.  But for those that
> > can, this is a strategy which is independent of the data backend.
> >
> > I wonder whether this "obviously not" needs to be rethought.  Algorithms
> > that are implemented to work with data holistically may need
> > to be reexpressed so that they can succeed with chunkwise access.  Is
> this
> > a new mindset needed for holist developers, or can the
> > effective data decompositions occur autonomously?
> >
> > Well, I would say it is obvious that not all computations can be done
> > chunkwise.  But of course, in the limit of extremely large data,
> algorithms
> > which needs to cycle over everything no longer scale.  So in that case
> all
> > practical computations can be done chunkwise, out of necessity.  For
> single
> > cell right now where it is just millions of cells 

Re: [Bioc-devel] Confusion with how to maintain release/devel files on local computer.

[Gabe Becker]

Arman,

Not on the Bioc team per se, but I would say only have a checkout of the
release branch when you need it, ie a bug is reported, you have fixed it in
devel, and you are ready to push the very narrow bugfix to release. I only
keep "master" checkouts of my packages on a permanent basis.

You generally shouldn't need a checkout of release, imho, because no
development should be happening there with exception of the case above.

Hope that helps,
~G

On Wed, Nov 1, 2017 at 1:36 PM, Arman Shahrisa 
wrote:

> I’m confused with development process.
>
> At first, I need to have a folder with accepted packaged. Then I need to
> pull
> origion RELEASE_3_6?
>
> Then in another folder, I need to pull origion master?
>
> So that by opening each folder, I know what I’m editing.
> Also during push, I need to be careful about where I’m pushing changes.
> Origion is bioc’s git address of my package whereas master is the package
> directory in GitHub?
>
> Am I getting it correct?
> Is there anywhere that contains whole the process and codes in steps?
>
> Best regards,
> Arman
>
>
>
> [[alternative HTML version deleted]]
>
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>



-- 
Gabriel Becker, Ph.D
Scientist
Bioinformatics and Computational Biology
Genentech Research

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Package update not showing on Bioc 3.6 webpage

[kushal kumar dey]

Hi Herve,

Thanks for clarifying on the matter. I followed your instructions and did *git
cherry-pick* to make the following changes

- fix a bug in one of the functions
- add a citation
- fix the readme

I bumped the version number from 1.4.0 to 1.4.1 and tried to push to the
release branch, but I when I run the command,

git push upstream RELEASE_3_6

I meet with the following error

*fatal: remote error: FATAL: W any packages/CountClust nobody DENIED by
fallthru*

*(or you mis-spelled the reponame)*


You can check the branch I want to push on my Github



*https://github.com/kkdey/CountClust/tree/RELEASE_3_6
*


This is my output from *git remote -v *

*origin https://github.com/kkdey/CountClust.git
 (fetch)*

*origin https://github.com/kkdey/CountClust.git
 (push)*

*upstream https://git.bioconductor.org/packages/CountClust
 (fetch)*

*upstream https://git.bioconductor.org/packages/CountClust
 (push)*


Can you please let me know what I am doing wrong here and how I can update
the release version?


Thank you so much!


Kushal





On 30 October 2017 at 17:50, Hervé Pagès  wrote:

> Hi Kushal,
>
> If you push changes without bumping the version of your package,
> the update won't propagate.
>
> You only bumped the version to 1.5.1 today so you need to wait
> about 24 hours before seeing this reflected on the landing page
> for CountClust.
>
> Also please note that you did the version bump plus a few other
> commits (6 commits in total) in master today **after** we created
> the RELEASE_3_6 branch so these changes will only propagate to
> BioC 3.7 (the new devel version of BioC, starting tomorrow).
> If you want these changes to also propagate to the BioC 3.6 release
> you'll need to push them to the RELEASE_3_6 branch. This is
> typically done with 'git cherry-pick' as documented here:
>
>
> https://bioconductor.org/developers/how-to/git/bug-fix-in-
> release-and-devel/
>
> Cheers,
> H.
>
>
> On 10/30/2017 02:41 PM, kushal kumar dey wrote:
>
>> Hi all,
>>
>> I am the author and maintainer of the CountClust package. I recently
>> submitted an update (version 1.5.1) to the package through
>> Bioconductor Git  and I can access this updated version when I clone the
>> source repository
>>
>> git clone https://urldefense.proofpoint.com/v2/url?u=https-3A__git.bio
>> conductor.org_packages_CountClust=DwICAg=eRAMFD45gAfqt84
>> VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=-x3S
>> 8Sl0fsASITg_-ULMYIykoPk6Y0PqK2NoRjC43iA=YBM0DldFbCkrEBnHaB
>> n5X8-jb1yhm_GmSUWL6SIGLmo=
>>
>> However, the updated version is not available in the official Bioconductor
>> 3.6 page, which still shows the version 1.3.0.
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.bio
>> conductor.org_packages_3.6_bioc_html_CountClust.html=DwICA
>> g=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvS
>> XAJJKaaPhzWA=-x3S8Sl0fsASITg_-ULMYIykoPk6Y0PqK2NoRjC43iA&
>> s=UfPX4T5l4JBfXBumCcQ-5YOm59i_xfX2OEILrQ3I2u0=
>>
>> Can you please let me know if the page has not been updated for the
>> packages yet or if I would need to do something at my end to update the
>> version reported on the page?
>>
>> Thanks so much
>>
>>
> --
> Hervé Pagès
>
> Program in Computational Biology
> Division of Public Health Sciences
> Fred Hutchinson Cancer Research Ce
> nter
> 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
>



-- 
Kushal K. Dey
Graduate Student
5 th Year, Department of Statistics
University of Chicago
Contact: +1 312-709-0680 | kk...@uchicago.edu

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Is version 1.1.0 correct for a new released package?

[Hervé Pagès]

On 11/01/2017 11:14 AM, Arman Shahrisa wrote:


Hi,

There are two GitHub commits for my package �cbaf� by Bioconductor on 30 
October.
The interesting thing is the first commit changes version in description file 
from
0.99.8 to 1.0.0 while the second one changes 1.0.0 to 1.1.0. Is it correct?


Yes, this is correct. This is part of the release process. What's
important do understand here is that between those 2 version bumps we
created the RELEASE_3_6 branch so the version of your package that is
in the branch is 1.0.0 and is the version that gets released as part
of BioC 3.6 The version in master is 1.1.0 and is part of BioC devel
which will be released in 6 months as BioC 3.7.

Hope this helps,
H.


In Bioconductor.org the version of published package is 1.0.0. The same thing 
has happened
for Bioconductor git repository as well (After pulling the changes made by bioc 
team).

Best regards,
Arman


[[alternative HTML version deleted]]



___
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=QULS0llSDUyFo3Zb5ThfvU-dYxMcP7cQh3g8fyVLnDI=NuaZmiUZRMLhZCgqcNGl4CLnDogeyO3QDAVCyPsVMTU=



--
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] Is version 1.1.0 correct for a new released package?

[Shepherd, Lori]

Yes this is correct -  Pkg_version x.y.z


We do a version bump on the devel version of the package to make the versioning 
consistent with release( y even in release)  - hence the first version bump to 
1.0.0 -  this is now the current release version of your package


The second version bump is to make the versioning consistent in devel (y odd in 
devel) - hence the 1.1.0 - this is now the current devel version of your 
package.


We do this on our end when we make our Bioconductor release branches.



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 Arman Shahrisa 

Sent: Wednesday, November 1, 2017 2:14:54 PM
To: bioc-devel
Subject: [Bioc-devel] Is version 1.1.0 correct for a new released package?


Hi,

There are two GitHub commits for my package �cbaf� by Bioconductor on 30 
October.
The interesting thing is the first commit changes version in description file 
from
0.99.8 to 1.0.0 while the second one changes 1.0.0 to 1.1.0. Is it correct?
In Bioconductor.org the version of published package is 1.0.0. The same thing 
has happened
for Bioconductor git repository as well (After pulling the changes made by bioc 
team).

Best regards,
Arman


[[alternative HTML version deleted]]



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] package access GitHub

[Turaga, Nitesh]

There are no updates given from that google form.

Did you try to access your package? 

> On Nov 1, 2017, at 1:45 PM, Valeriia Sherina  wrote:
> 
> Dear Bioconductor,
> 
> I am a maintainer of the package "nondetecs" on Bioconductor. I know that
> Bioconcuctor transitioned to GitHub submittions. I filled up a form "git /
> svn transition: ssh keys"  to get access to my package, but since last
> Wednesday have not gotten any updates on that.
> 
> I am hoping you might be able to help me.
> Thank you for your time.
> 
> With best regards,
> Valeriia Sherina
> 
>   [[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.
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Bioc-devel] package access GitHub

[Valeriia Sherina]

Dear Bioconductor,

I am a maintainer of the package "nondetecs" on Bioconductor. I know that
Bioconcuctor transitioned to GitHub submittions. I filled up a form "git /
svn transition: ssh keys"  to get access to my package, but since last
Wednesday have not gotten any updates on that.

I am hoping you might be able to help me.
Thank you for your time.

With best regards,
Valeriia Sherina

[[alternative HTML version deleted]]

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

[Bioc-devel] BioC 3.7 devel builds

[Obenchain, Valerie]

Hi all,

You may have noticed the devel builds have a lot of red.  Part of the problem 
is that we currently have no CRAN binaries for Windows or OS X El Capitan built 
against R 3.5.

In the BBS code, we are attempting to install CRAN dependencies from "source" 
where possible but some packages are difficult to install, e.g., RCurl and 
still fail. Bioconductor packages that depend on CRAN packages will fail until 
these binaries become available.

Valerie


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] Vignette rebuild for MutationalPatterns

[Ludwig Geistlinger]

Yes, I am experiencing the same problem for the EnrichmentBrowser package.

The release package landing page holds all the new stuff, but the vignette
is still the one of the old release.

Best,
Ludwig

-- 
Dr. Ludwig Geistlinger
eMail: ludwig.geistlin...@bio.ifi.lmu.de

> Dear,
>
> It seems that the 3.6 release contains an old version of the vignette of
> MutationalPatterns.
> In commit d1c4e14 I pushed updates of the corresponding bioRxiv paper, but
> the changes in the vignette haven't made it in.
>
> Should I now bump the release number without making any further changes?
>
> Kind regards,
> Roel Janssen
> --
>
> De informatie opgenomen in dit bericht kan vertrouwelijk zijn en is
> uitsluitend bestemd voor de geadresseerde. Indien u dit bericht onterecht
> ontvangt, wordt u verzocht de inhoud niet te gebruiken en de afzender
> direct
> te informeren door het bericht te retourneren. Het Universitair Medisch
> Centrum Utrecht is een publiekrechtelijke rechtspersoon in de zin van de
> W.H.W.
> (Wet Hoger Onderwijs en Wetenschappelijk Onderzoek) en staat geregistreerd
> bij
> de Kamer van Koophandel voor Midden-Nederland onder nr. 30244197.
>
> Denk s.v.p aan het milieu voor u deze e-mail afdrukt.
>
> --
>
> This message may contain confidential information and ...{{dropped:10}}

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

Re: [Bioc-devel] Can't reproduce build error from OS X server for pwOmics package

[Hervé Pagès]

Hi Maren,

pwOmics/vignettes/ contains a pwOmics.bcf file which is
likely to be contamination (looks like an intermediate biber
file). It's never a good idea to put this kind of intermediate
file in git. Please remove and let's see if that solves the problem.

Cheers,
H.

On 11/01/2017 12:33 AM, Sitte, Maren wrote:

Dear Bioconductor developers,

I can't reproduce the error from the OS X server which is

/usr/local/bin/texi2dvi: biber failed



for the pwOmics build report.
Do you have any advice for me, how to fix this?

Additionally, I wan't to point out that the maintenance changed and that I'm the
new maintainer for the pwOmics package.

Kind regards,
Maren Sitte
--
University Medical Center Göttingen
Institute of Medical Statistics
Humboldtallee 32
37073 Göttingen
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ams.med.uni-2Dgoettingen.de=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=ujz3ALv3DsR47gfGDApsFZkTzCVs4uM-t4X1R5oBv68=g088n_cubhteMfPpcrSWTm0PLqClbJtT0OnZScT57oM=
E-Mail: 
maren.si...@med.uni-goettingen.de
Phone: +49 (0) 551-39-10710

[[alternative HTML version deleted]]

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



--
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] Accepted packages can't find each other and fail build

[Hervé Pagès]

Hi Sokratis,

Not sure why but it seems that for some reason the build machines
didn't manage to install pcxn so far. Until only now. I went on
build machine malbec1 to check whether it managed to install pcxn,
and it seems that it did:

  > "pcxn" %in% rownames(installed.packages())
  [1] TRUE

According to the log, it looks like this is the 1st time that it
gets installed on malbec1 (the data experiment builds just started
today and did the installation).

So, if everything goes as expected, pcxnData should build successfully
today and pcxnData should propagate (granted of course that it also
passes CHECK). The build/check report for data-experiment packages
should update today around 5pm EST. It will take about 1 hour after
the report is updated for pcxnData to propagate to the public repo
and for its landing page to show up.

Sorry for the inconvenience,

H.

On 11/01/2017 01:36 AM, Sokratis Kariotis wrote:

Hey all,

After the release I can see the release page of the pcxn package but not
pcxnData package. In the build page it says it cannot find the pcxn
package and fails.

Regards,
Sokratis

On 31 October 2017 at 16:33, Shepherd, Lori
>
wrote:

It should be the same and you should be able to see the RELEASE_3_6
branch


git fetch --all

git branch -a


Lori Shepherd

Bioconductor Core Team

Roswell Park Cancer Institute

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


*From:* Sokratis Kariotis >
*Sent:* Tuesday, October 31, 2017 11:20:39 AM
*To:* Shepherd, Lori
*Cc:* Hervé Pagès; Obenchain, Valerie; bioc-devel

*Subject:* Re: [Bioc-devel] Accepted packages can't find each other
and fail build
Does the same hold for the pcxnData package? I can't see the
RELEASE_3_6 as in pcxn.

-Sokratis

On 31 October 2017 at 11:38, Shepherd, Lori
> wrote:

The latest version bump change you made to 0.99.27 was yesterday
Oct 30 right before we said to stop committing so we could make
the release branch.  That change did make it into both the
RELEASE_3_6 and the master branch and should appear in the next
build report for both versions.


Note:  It can take 12-24 hours to see version bumps and changes
on the build report. The daily builders runs once per day to
build all the packages; while a version bump is absolutely
required, it is not built instantaneously on a version bump.


Please be sure to pull from upstream before making further
changes as we have bumped the versions in both the release and
devel versions of packages for the release.



Lori Shepherd

Bioconductor Core Team

Roswell Park Cancer Institute

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


*From:* Sokratis Kariotis >
*Sent:* Tuesday, October 31, 2017 5:21:21 AM
*To:* Hervé Pagès
*Cc:* Obenchain, Valerie; Shepherd, Lori; bioc-devel
*Subject:* Re: [Bioc-devel] Accepted packages can't find each
other and fail build
Hi all,

There was an error in the pcxn package (and pcxnData as a resut
of not finding pcxn since it didnt build) which I fixed
yesterday morning, but it doesnt seem to accept my changes as
the version in the build report is not the last one I created
but the erroneous one (2 days ago). I checked the upstream of my
package and it has my latest changes.

Regards,
Sokratis

On 27 October 2017 at 16:57, Hervé Pagès > wrote:

Hi guys,

On 10/27/2017 05:50 AM, Obenchain, Valerie wrote:

Hi Sokratis,

I added the .BBSoptions file to pcxn when it should have
been added to pcxnData. The .BBSoptions file should be
put in the package that 'Suggests' (not 'Depends') on
the other. In this case it's pcxnData that needs the
.BBSoptions. Sorry for the mix up, this has been fixed.

The data package should install with today's builds and
be clean on the Saturday report. The software package
should then install with the Saturday builds and be
clean on the Sunday report.


This is what should happen:

   - pcxnData should 

Re: [Bioc-devel] I can't merge the changes by bioc team with my accepted package

[Turaga, Nitesh]

You submitted your key very recently. We process the keys every 24 hours, at 
12pm EST.

Please be patient.

Nitesh 

> On Oct 31, 2017, at 5:54 PM, Arman Shahrisa  
> wrote:
> 
> Hi,
> 
> I�m the maintainer of the package �cbaf�. It�s a new package for bioc v 3.6.
> 
> I�m trying to pull changes that are created during package publication.
> 
> I�m doing according to
> 
> https://bioconductor.org/developers/how-to/git/new-package-workflow/
> 
> and
> 
> https://bioconductor.org/developers/how-to/git/pull-upstream-changes/
> 
> When I run the following command
> 
>> git merge upstream/master
> 
> This message appears:
> 
>> merge: upstream/master � not something we can merge
> 
> Why?
> 
> Best regards,
> Arman
> 
>   [[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.
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Accepted packages can't find each other and fail build

[Sokratis Kariotis]

Hey all,

After the release I can see the release page of the pcxn package but not
pcxnData package. In the build page it says it cannot find the pcxn package
and fails.

Regards,
Sokratis

On 31 October 2017 at 16:33, Shepherd, Lori 
wrote:

> It should be the same and you should be able to see the RELEASE_3_6 branch
>
>
> git fetch --all
>
> git branch -a
>
>
> Lori Shepherd
>
> Bioconductor Core Team
>
> Roswell Park Cancer Institute
>
> Department of Biostatistics & Bioinformatics
>
> Elm & Carlton Streets
>
> Buffalo, New York 14263
> --
> *From:* Sokratis Kariotis 
> *Sent:* Tuesday, October 31, 2017 11:20:39 AM
> *To:* Shepherd, Lori
> *Cc:* Hervé Pagès; Obenchain, Valerie; bioc-devel
>
> *Subject:* Re: [Bioc-devel] Accepted packages can't find each other and
> fail build
>
> Does the same hold for the pcxnData package? I can't see the RELEASE_3_6
> as in pcxn.
>
> -Sokratis
>
> On 31 October 2017 at 11:38, Shepherd, Lori  > wrote:
>
>> The latest version bump change you made to 0.99.27 was yesterday Oct 30
>> right before we said to stop committing so we could make the release
>> branch.  That change did make it into both the RELEASE_3_6 and the master
>> branch and should appear in  the next build report for both versions.
>>
>>
>> Note:  It can take 12-24 hours to see version bumps and changes on the
>> build report. The daily builders runs once per day to build all the
>> packages; while a version bump is absolutely required, it is not built
>> instantaneously on a version bump.
>>
>>
>> Please be sure to pull from upstream before making further changes as we
>> have bumped the versions in both the release and devel versions of packages
>> for the release.
>>
>>
>>
>> Lori Shepherd
>>
>> Bioconductor Core Team
>>
>> Roswell Park Cancer Institute
>>
>> Department of Biostatistics & Bioinformatics
>>
>> Elm & Carlton Streets
>>
>> Buffalo, New York 14263
>> --
>> *From:* Sokratis Kariotis 
>> *Sent:* Tuesday, October 31, 2017 5:21:21 AM
>> *To:* Hervé Pagès
>> *Cc:* Obenchain, Valerie; Shepherd, Lori; bioc-devel
>> *Subject:* Re: [Bioc-devel] Accepted packages can't find each other and
>> fail build
>>
>> Hi all,
>>
>> There was an error in the pcxn package (and pcxnData as a resut of not
>> finding pcxn since it didnt build) which I fixed yesterday morning, but it
>> doesnt seem to accept my changes as the version in the build report is not
>> the last one I created but the erroneous one (2 days ago). I checked the
>> upstream of my package and it has my latest changes.
>>
>> Regards,
>> Sokratis
>>
>> On 27 October 2017 at 16:57, Hervé Pagès  wrote:
>>
>>> Hi guys,
>>>
>>> On 10/27/2017 05:50 AM, Obenchain, Valerie wrote:
>>>
 Hi Sokratis,

 I added the .BBSoptions file to pcxn when it should have been added to
 pcxnData. The .BBSoptions file should be put in the package that 'Suggests'
 (not 'Depends') on the other. In this case it's pcxnData that needs the
 .BBSoptions. Sorry for the mix up, this has been fixed.

 The data package should install with today's builds and be clean on the
 Saturday report. The software package should then install with the Saturday
 builds and be clean on the Sunday report.


>>> This is what should happen:
>>>
>>>   - pcxnData should install with today's data-exp builds (they
>>> started this morning) but vignette will still fail (pcxn still
>>> missing)
>>>
>>>   - pcxn won't install (will be back to NotNeeded) but should pass
>>> build/check and propagate on Saturday afternoon
>>>
>>>   - on Sunday morning, the data exp builds will find pcxn **on line**
>>> (because now it propagated) so will be able to install it so
>>> vignette will finally build and the package will propagate
>>>
>>> Thanks for taking care of this,
>>>
>>> H.
>>>
>>> Valerie


 On 10/26/2017 04:26 AM, Shepherd, Lori wrote:

 We have already taken care of this on our end and you shouldn't need to
 do anything else.  As always changes reflected may take a few days to
 reflect in the build reports.


 The solution is to add a .BBSoptions file with ForceInstall: TRUE to
 the software package.  Since there is a circular dependency this will force
 install the software package even though there will be ERRORs because of
 the missing data package.  On the next build of the data packages, the data
 package will then successfully build finding the software package. Then
 following, the software package will also build finding the data package.


 Cheers,


 Lori Shepherd

 Bioconductor Core Team

 Roswell Park Cancer Institute

 Department of Biostatistics & Bioinformatics

 Elm & Carlton Streets

 Buffalo, New York