Re: [Bioc-devel] BrowserViz build test times out, checks for web browser availability, apparently needs update
Thanks, Vince.
You can find the package here: https://github.com/paul-shannon/BrowserViz
- Paul
> On Aug 25, 2021, at 12:41 PM, Vincent Carey
> wrote:
>
> Sorry for delay in responding Paul. I had a look at BrowserViz and ran into
>
> > PORT_RANGE <- 12111:12120
> > if(BrowserViz::webBrowserAvailableForTesting()){
> +bvApp <- BrowserViz(browserFile=browserVizBrowserFile, quiet=TRUE)
> +data <- list(lowercase=letters, uppercase=LETTERS)
> +json.returned <- roundTripTest(bvApp, data)
> +data.returned <- fromJSON(json.returned)
> +message(sprintf("%5d bytes exchanged", nchar(json.returned)))
> +stopifnot(data == data.returned)
> +html <- sprintf("round trip of json-encoded data, %d chars",
> +nchar(json.returned))
> +displayHTMLInDiv(bvApp, html, "bvDemoDiv")
> +}
> attempting to open websocket connection on port 1
> BrowserViz websocket ready after 1.30 seconds
> 237 bytes exchanged
> Error in data == data.returned :
> comparison of these types is not implemented
>
> Maybe we can discuss this on issues in BrowserViz github ... where is that?
> Then
> we can bring back the solution to bioc-devel.
>
> On Wed, Dec 30, 2020 at 1:25 PM Paul Shannon
> wrote:
> The BrowserViz package - currently timing out on malbec1 and nebbiolo1,
> supports json messaging over websockets between R and most web browsers.
>
> The unit tests for BrowserViz only run if a web browser is available. In
> recent years, a (presumably headless) web browser was offered on the Linux
> build machines. Depending on that, and for a few years, the following
> conditional execution has worked. But maybe no longer?
>
> webBrowserAvailableForTesting <- function() {
> authorsDevelopmentMachine <- grepl("hagfish", Sys.info()["nodename"])
> bioconductorBuildSystem.linux <- with(as.list(Sys.info()), sysname ==
> "Linux")
> interactiveUse <- interactive()
> return(authorsDevelopmentMachine || bioconductorBuildSystem.linux ||
> interactiveUse)
> }
>
> Any suggestions?
>
> Thank you,
>
> - Paul
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
> The information in this e-mail is intended only for th...{{dropped:12}}
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] BrowserViz build test times out, checks for web browser availability, apparently needs update
Sorry for delay in responding Paul. I had a look at BrowserViz and ran into
> PORT_RANGE <- 12111:12120
> if(BrowserViz::webBrowserAvailableForTesting()){
+bvApp <- BrowserViz(browserFile=browserVizBrowserFile, quiet=TRUE)
+data <- list(lowercase=letters, uppercase=LETTERS)
+json.returned <- roundTripTest(bvApp, data)
+data.returned <- fromJSON(json.returned)
+message(sprintf("%5d bytes exchanged", nchar(json.returned)))
+stopifnot(data == data.returned)
+html <- sprintf("round trip of json-encoded data, %d chars",
+nchar(json.returned))
+displayHTMLInDiv(bvApp, html, "bvDemoDiv")
+}
attempting to open websocket connection on port 1
BrowserViz websocket ready after 1.30 seconds
237 bytes exchanged
Error in data == data.returned :
comparison of these types is not implemented
Maybe we can discuss this on issues in BrowserViz github ... where is
that? Then
we can bring back the solution to bioc-devel.
On Wed, Dec 30, 2020 at 1:25 PM Paul Shannon <
paul.thurmond.shan...@gmail.com> wrote:
> The BrowserViz package - currently timing out on malbec1 and nebbiolo1,
> supports json messaging over websockets between R and most web browsers.
>
> The unit tests for BrowserViz only run if a web browser is available. In
> recent years, a (presumably headless) web browser was offered on the Linux
> build machines. Depending on that, and for a few years, the following
> conditional execution has worked. But maybe no longer?
>
> webBrowserAvailableForTesting <- function() {
> authorsDevelopmentMachine <- grepl("hagfish", Sys.info()["nodename"])
> bioconductorBuildSystem.linux <- with(as.list(Sys.info()), sysname ==
> "Linux")
> interactiveUse <- interactive()
> return(authorsDevelopmentMachine || bioconductorBuildSystem.linux ||
> interactiveUse)
> }
>
> Any suggestions?
>
> Thank you,
>
> - Paul
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
--
The information in this e-mail is intended only for the ...{{dropped:18}}
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] lessons learned: negative experiences with git log
Hi Kasper, Is this what you are looking for? (My understanding of your question is you want to see which files changed as part of a ‘merge’ commit) The command below lists 5 commits -n : number of commits -m : This option makes diff output for merge commits to be shown in the default format. (More details here: https://git-scm.com/docs/git-show) -—name-only: will display only the names of the files Rgraphviz ❯❯❯ git log -m --name-only -n 5 commit 50a89903830505a1a686570825304f7a30e194f1 (HEAD -> master, origin/master, origin/HEAD) Author: kasperdanielhansen Date: Thu Aug 12 21:19:44 2021 -0400 fixing seg fault DESCRIPTION src/doLayout.c commit 43207afdc87afc04bbc8b2a1acbbdb3b531d25b3 Author: kasperdanielhansen Date: Thu Aug 12 21:18:02 2021 -0400 removing testing vignette vignettes/testing.Rmd commit 955e30b3ae316265b4f5f130ab6f12c33081da54 Author: Kasper Daniel Hansen Date: Wed Aug 11 08:52:11 2021 -0400 Fixing length condition error DESCRIPTION man/agopenSimple.Rd commit 15204d879d974de8d40b0342b2f853c88f4bf9a3 (from 7c1433d9f6025e3195f27ccc18a1439398221ffc) Merge: 7c1433d b01ad95 Author: Kasper Daniel Hansen Date: Wed Aug 11 08:26:09 2021 -0400 Merge remote-tracking branch 'upstream/master' DESCRIPTION commit 15204d879d974de8d40b0342b2f853c88f4bf9a3 (from b01ad9552737978b3b7db6815323a078ceafe041) Merge: 7c1433d b01ad95 Author: Kasper Daniel Hansen Date: Wed Aug 11 08:26:09 2021 -0400 Merge remote-tracking branch 'upstream/master' R/plotGraph.R src/doLayout.c vignettes/testing.Rmd As you can see above, the files which changed are listed. You can also see “only” merge commits and the files that change with this command, git log --merges -m --name-only -n 5 Hope this helps. Best regards, Nitesh Nitesh Turaga Scientist II, Department of Data Science, Bioconductor Core Team Member Dana Farber Cancer Institute > On Aug 13, 2021, at 9:34 AM, Kasper Daniel Hansen > wrote: > > Here are my experiences as a novice in git. > > Yesterday I was working on fixing a condition length error in Rgraphviz, a > package which has not been touched in years. After I fixed this, I got a > segmentation fault in examples / tests / vignettes; all over the place. > > This could have been related to a small git snafu I had on my laptop > because I had not synchronized laptop / Github / bioc git for a _long_ > time (read: years). > > No matter, I thought, git history will easily reveal this, and since there > has been no changes to the package in years, it should be really easy to > just list which file had changed. However, running > git log --name-status > I got this > > START git log == > commit 955e30b3ae316265b4f5f130ab6f12c33081da54 > Author: Kasper Daniel Hansen > Date: Wed Aug 11 08:52:11 2021 -0400 > >Fixing length condition error > > :100644 100644 25e24de 3aee690 MDESCRIPTION > :100644 100644 f8e077f b73b052 Mman/agopenSimple.Rd > > commit 15204d879d974de8d40b0342b2f853c88f4bf9a3 > Merge: 7c1433d b01ad95 > Author: Kasper Daniel Hansen > Date: Wed Aug 11 08:26:09 2021 -0400 > >Merge remote-tracking branch 'upstream/master' > > commit b01ad9552737978b3b7db6815323a078ceafe041 > Author: Nitesh Turaga > Date: Wed May 19 15:33:11 2021 + > >bump x.y.z version to odd y following creation of RELEASE_3_13 branch > > :100644 100644 78243eb 25e24de MDESCRIPTION > == END git log == > > This suggests that no files apart from DESCRIPTION and a man page were > touched recently (it looks the same if I go back longer). Look at the > second message with "Merge remote-tracking". No files are listed! > > It turns out that files were indeed touched as part of the "Merge > remote-tracking ..." commit. I can see this by a > git diff b01ad9552737978b3b7db6815323a078ceafe041 > but in reality I had given up on git and did a standard recursive diff on > the stable release tarball and my codebase. > > I have not been able to figure out what options I need to give git log to > display which files changed as part of that commit, and I find that > perplexing and -- frankly -- pretty worrying. > > Anyway, just some scary lessons on git log and merge. > > Best > > -- > Best, > Kasper > > [[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] Best practices for joint release/update of BioC packages
Webster lake. Has it been submitted yet? ;-D -Original Message- From: Bioc-devel On Behalf Of Steve Lianoglou Sent: Wednesday, August 25, 2021 12:02 PM To: Nitesh Turaga Cc: Russell Bainer ; Hervé Pagès Subject: Re: [Bioc-devel] Best practices for joint release/update of BioC packages Hello friends, I'm the derelict collaborator :-) I'll be submitting my package faster than you can (correctly) pronounce Lake Chargoggagoggmanchauggagoggchaubunagungamaugg https://en.wikipedia.org/wiki/Lake_Chaubunagungamaug -steve On Wed, Aug 25, 2021 at 8:48 AM Nitesh Turaga wrote: > Hi Russell, > > The deprecation usually occurs around the time of release (October > 2021, but I don't have an exact date yet). > > If your collaborator has submitted the package to Bioconductor or > CRAN, and it gets accepted, and you can make everything build and > check cleanly before the release time, I think you should be ok. It > might mean that he submits the package 'sparrow' soon for review. > > The best way to do this (IMHO) is, wait for your collaborator's code > to get into Bioconductor/CRAN and plan the major release around that. > If it happens after this release, then do a major version update for > the next release cycle (April 2022 - approx). This will add all the > significant updates in your package only in the major version update > to 2.0.0. In the meantime, you may consider fixing/hiding parts of the > code why are failing for October 2021 release. > > Another "non-traditional" way is to add your collaborator as an Author > on your package and ingest parts that improve your package > significantly as code within your package. So this will attribute the > authorship of the code to your collaborator appropriately. Of course, > this will not allow for modular and independent development of two > separate packages adding a lot of complexity. (We should not consider > this method for the sake of good software engineering practices) > > I’m hoping other members on the team / community can provide better > suggestions. > > Best, > > > Nitesh Turaga > Scientist II, Department of Data Science, Bioconductor Core Team > Member Dana Farber Cancer Institute > > > On Aug 24, 2021, at 7:07 PM, Russell Bainer > wrote: > > > > Hello All, > > > > I am planning a major update to my BioC package in the next release > > ( > > > https://www.bioconductor.org/packages/release/bioc/html/gCrisprTools.h > tml > ), > > and some of the new functionality depends on another package that is > being > > submitted for acceptance by a collaborator. > > > > All of the code in my package passes R/BioC check using the package > > in my collaborator's github repo, but as his code has not yet been > > incorporated into BioC my current build is failing. > > > > What is the recommended way to deal with a situation like this? > Obviously I > > want to avoid deprecation of my own package, and obviously I could > > just hide all of the parts of the update that depend on external > > code. But I also think that my collaborator's work adds > > significantly to the utility > of > > my package, and I want to ensure that their contributions are > > properly highlighted/celebrated in my 2.0 release. > > > > Thanks in advance for the input. > > > > -R > > > > [[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 > [[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] Best practices for joint release/update of BioC packages
Steve, I'll not have you malign my collaborators like that. :) Thanks Nitesh for your clear and sensible suggestions. As Steve has surely had time to speak the name of Webster lake by now, I'll plan to leave things as-is and will coordinate with him about sparrow's acceptance status to make sure that gCrisprTools continues to play nice with the final version. Best, -R On Wed, Aug 25, 2021 at 9:01 AM Steve Lianoglou wrote: > Hello friends, > > I'm the derelict collaborator :-) > > I'll be submitting my package faster than you can (correctly) pronounce > Lake Chargoggagoggmanchauggagoggchaubunagungamaugg > https://en.wikipedia.org/wiki/Lake_Chaubunagungamaug > > -steve > > > On Wed, Aug 25, 2021 at 8:48 AM Nitesh Turaga > wrote: > >> Hi Russell, >> >> The deprecation usually occurs around the time of release (October 2021, >> but I don't have an exact date yet). >> >> If your collaborator has submitted the package to Bioconductor or CRAN, >> and it gets accepted, and you can make everything build and check cleanly >> before the release time, I think you should be ok. It might mean that he >> submits the package 'sparrow' soon for review. >> >> The best way to do this (IMHO) is, wait for your collaborator's code to >> get into Bioconductor/CRAN and plan the major release around that. If it >> happens after this release, then do a major version update for the next >> release cycle (April 2022 - approx). This will add all the significant >> updates in your package only in the major version update to 2.0.0. In the >> meantime, you may consider fixing/hiding parts of the code why are failing >> for October 2021 release. >> >> Another "non-traditional" way is to add your collaborator as an Author on >> your package and ingest parts that improve your package significantly as >> code within your package. So this will attribute the authorship of the code >> to your collaborator appropriately. Of course, this will not allow for >> modular and independent development of two separate packages adding a lot >> of complexity. (We should not consider this method for the sake of good >> software engineering practices) >> >> I’m hoping other members on the team / community can provide better >> suggestions. >> >> Best, >> >> >> Nitesh Turaga >> Scientist II, Department of Data Science, >> Bioconductor Core Team Member >> Dana Farber Cancer Institute >> >> > On Aug 24, 2021, at 7:07 PM, Russell Bainer >> wrote: >> > >> > Hello All, >> > >> > I am planning a major update to my BioC package in the next release ( >> > >> https://www.bioconductor.org/packages/release/bioc/html/gCrisprTools.html >> ), >> > and some of the new functionality depends on another package that is >> being >> > submitted for acceptance by a collaborator. >> > >> > All of the code in my package passes R/BioC check using the package in >> my >> > collaborator's github repo, but as his code has not yet been >> incorporated >> > into BioC my current build is failing. >> > >> > What is the recommended way to deal with a situation like this? >> Obviously I >> > want to avoid deprecation of my own package, and obviously I could just >> > hide all of the parts of the update that depend on external code. But I >> > also think that my collaborator's work adds significantly to the >> utility of >> > my package, and I want to ensure that their contributions are properly >> > highlighted/celebrated in my 2.0 release. >> > >> > Thanks in advance for the input. >> > >> > -R >> > >> > [[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 >> > [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] Best practices for joint release/update of BioC packages
Hello friends, I'm the derelict collaborator :-) I'll be submitting my package faster than you can (correctly) pronounce Lake Chargoggagoggmanchauggagoggchaubunagungamaugg https://en.wikipedia.org/wiki/Lake_Chaubunagungamaug -steve On Wed, Aug 25, 2021 at 8:48 AM Nitesh Turaga wrote: > Hi Russell, > > The deprecation usually occurs around the time of release (October 2021, > but I don't have an exact date yet). > > If your collaborator has submitted the package to Bioconductor or CRAN, > and it gets accepted, and you can make everything build and check cleanly > before the release time, I think you should be ok. It might mean that he > submits the package 'sparrow' soon for review. > > The best way to do this (IMHO) is, wait for your collaborator's code to > get into Bioconductor/CRAN and plan the major release around that. If it > happens after this release, then do a major version update for the next > release cycle (April 2022 - approx). This will add all the significant > updates in your package only in the major version update to 2.0.0. In the > meantime, you may consider fixing/hiding parts of the code why are failing > for October 2021 release. > > Another "non-traditional" way is to add your collaborator as an Author on > your package and ingest parts that improve your package significantly as > code within your package. So this will attribute the authorship of the code > to your collaborator appropriately. Of course, this will not allow for > modular and independent development of two separate packages adding a lot > of complexity. (We should not consider this method for the sake of good > software engineering practices) > > I’m hoping other members on the team / community can provide better > suggestions. > > Best, > > > Nitesh Turaga > Scientist II, Department of Data Science, > Bioconductor Core Team Member > Dana Farber Cancer Institute > > > On Aug 24, 2021, at 7:07 PM, Russell Bainer > wrote: > > > > Hello All, > > > > I am planning a major update to my BioC package in the next release ( > > > https://www.bioconductor.org/packages/release/bioc/html/gCrisprTools.html > ), > > and some of the new functionality depends on another package that is > being > > submitted for acceptance by a collaborator. > > > > All of the code in my package passes R/BioC check using the package in my > > collaborator's github repo, but as his code has not yet been incorporated > > into BioC my current build is failing. > > > > What is the recommended way to deal with a situation like this? > Obviously I > > want to avoid deprecation of my own package, and obviously I could just > > hide all of the parts of the update that depend on external code. But I > > also think that my collaborator's work adds significantly to the utility > of > > my package, and I want to ensure that their contributions are properly > > highlighted/celebrated in my 2.0 release. > > > > Thanks in advance for the input. > > > > -R > > > > [[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 > [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] Best practices for joint release/update of BioC packages
Hi Russell, The deprecation usually occurs around the time of release (October 2021, but I don't have an exact date yet). If your collaborator has submitted the package to Bioconductor or CRAN, and it gets accepted, and you can make everything build and check cleanly before the release time, I think you should be ok. It might mean that he submits the package 'sparrow' soon for review. The best way to do this (IMHO) is, wait for your collaborator's code to get into Bioconductor/CRAN and plan the major release around that. If it happens after this release, then do a major version update for the next release cycle (April 2022 - approx). This will add all the significant updates in your package only in the major version update to 2.0.0. In the meantime, you may consider fixing/hiding parts of the code why are failing for October 2021 release. Another "non-traditional" way is to add your collaborator as an Author on your package and ingest parts that improve your package significantly as code within your package. So this will attribute the authorship of the code to your collaborator appropriately. Of course, this will not allow for modular and independent development of two separate packages adding a lot of complexity. (We should not consider this method for the sake of good software engineering practices) I’m hoping other members on the team / community can provide better suggestions. Best, Nitesh Turaga Scientist II, Department of Data Science, Bioconductor Core Team Member Dana Farber Cancer Institute > On Aug 24, 2021, at 7:07 PM, Russell Bainer wrote: > > Hello All, > > I am planning a major update to my BioC package in the next release ( > https://www.bioconductor.org/packages/release/bioc/html/gCrisprTools.html), > and some of the new functionality depends on another package that is being > submitted for acceptance by a collaborator. > > All of the code in my package passes R/BioC check using the package in my > collaborator's github repo, but as his code has not yet been incorporated > into BioC my current build is failing. > > What is the recommended way to deal with a situation like this? Obviously I > want to avoid deprecation of my own package, and obviously I could just > hide all of the parts of the update that depend on external code. But I > also think that my collaborator's work adds significantly to the utility of > my package, and I want to ensure that their contributions are properly > highlighted/celebrated in my 2.0 release. > > Thanks in advance for the input. > > -R > > [[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
