Bioconductor centric hackathons!
A general bioconductor-centric hackathon is being planned for June 1st and 2nd before EuroBioc2026 in Turku, Finland. A few projects are already planned, but participants are welcome to bring their own as long as those ideas have been communicated to organizers beforehand. General bug hunting or feature additions in existing packages that are willing to accept pull requests will also be supported.
Participants will be expected to adhere to the Bioconductor code of conduct.
A brief set of introductory slides are also can also be found here
This README page will serve as a hub for documents, repos, and links associated with the event.
General microsoft teams links for hackathon wide introductions, announcements, and presentations:
- June 1st:
- Join: https://teams.microsoft.com/meet/360196994824944?p=fNRlY6l55f25xJuYiw
- Meeting ID: 360 196 994 824 944
- Passcode: zU3Ct3oj
- June 2nd:
- Join: https://teams.microsoft.com/meet/348074563111143?p=dCO6hXKAPVjoVOmEGj
- Meeting ID: 348 074 563 111 143
- Passcode: wz7sg6PS
These will be up throughout both days, so i will be able to respond to some messages in the calls, but zulip will likely be the most reasonable way to communicate.
Outside of hackathon-wide communications, groups themselves are welcome to choose whichever virtual meeting platforms they prefer. A Hackathon channel has been created on the Bioconductor zulip, and contains general topics for each project. Participants are welcome to use these to communicate, or create additional topics as they decide they need.
The event will take place at BioCity Turku, the same venue as EuroBioc2026. See the conference travel information for details. Signs for rooms and locations will posted at the venue.
Monday June 1st:
- 09:00 - 10:30 = Project introductions, team formation, and planning
- 10:30 - 11:00 = Break
- 11:00 - 12:30 = Hacking
- 12:30 - 13:30 = Lunch
- 13:30 - 15:00 = Hacking
- 15:00 - 15:30 = Break
- 15:30 - 17:00 = Hacking
Tuesday June 2nd:
- 09:00 - 10:30 = Update on progress from the previous day, discussion if necessary
- 10:30 - 11:00 = Break
- 11:00 - 12:30 = Hacking
- 12:30 - 13:30 = Lunch
- 13:30 - 15:00 = Hacking
- 15:00 - 15:30 = Break
- 15:30 - 17:00 = Presentations on projects
- R CUDA bindings project github repo
- Commandline executables github repo
- Lightweight container generation github repo
- Tidyomics project github repo
Access to repositories hosted in the BiocCodingCollaborations org will be initially managed by Bioc staff, but once projects start project leads will be given admin access to just those repos. Some of these already have some work associated with them, others may have less.
The inaccessibility of alternative compute devices in the R language has been a missing feature that most R users have been content to live without. The rugged landscape of alternative compute frameworks and hardware providers have also made it difficult for the R community to coalesce on a paradigm for access that would fit well within R as a language and R as a research ecosystem. Bringing alternative compute access into R, particularly with CUDA and NVIDIA devices would improve the value of R as a skill for graduates leaving academia, increase the throughput and efficiency of research computing in R, and expand the versatility of R generally.
The goal of this project is to build infrastructure for developers who want their computational tools to be able to leverage available CUDA devices on systems where they are present. Examples of programmatic access to OpenCL and Metal in R already exist and contain lessons in terms of design paradigms, reasonable expectations for users / developers, and maintainability. Ideally this package will be submitted to CRAN upon completion.
This is not untrodden ground. Attempts have been made at providing GPU support in R before, and of those only Simon Urbanek’s OpenCL R package seems to have survived the test of time as R specific infrastructure. Several existing packages allow GPU support through tools they wrap around, but do not facilitate development in R. Therefore this project will likely be as much about planning and design as it will be about writing code.
Key considerations:
- What infrastructure is necessary for developers to be able call CUDA code in a function when a device is available?
- When should kernel functions be compiled? Package installation? Package loading? On request by the user?
- If the end goal is for developers to be able to enable alternative compute use through a function argument, what do users supply to that argument, and what do users need to know - or have done - ahead of time for this kind of behavior to be reliable.
- The underlying structure of the package must be both maintainable.
- Implementations within the package must also be flexible. We
realistically shouldn’t expect to find NVIDIA hardware on an Apple OS,
so developers should be able to rely on tooling within this package
exiting or warning gracefully in cases where a user asks for resources
that don’t exist. Developers should also be comfortable having their
own packages rely on this package, most likely through the
Suggestsfield in the description file.
This project was originally envisioned as a package or function for converting package maintainer or user supplied scripts into commandline executables. The R and Bioconductor paradigms of interactivity through a responsive and informative REPL have been a formula for success for academic users for a long time. But as computational biology becomes increasingly interdisciplinary and increasingly relies on high performance compute, high throughput compute and experimentation, and cloud compute, formalizing portable and flexible implementations of R and Bioconductor tooling is an imperative to ensure that that work, and Bioconductor itself maintain relevancy.
There already exist at least two tools that do ‘app’ style script conversion; R2G2 - Galaxy specifc integration and Rapp - commandline executables. So developing a package for this project may not be necessary. Long term, the goal of this project is to lay the groundwork for programmatic generation of tooling within Bioconductor packages that can be slotted into modern workflow management systems, or other interactive platforms like Galaxy.
Key Considerations:
- Where is the right place for ‘app-ification’ of a script to take place? Should it happen upon package installation?
- Overhead checking of things like package versions or argument types are mostly cheap, how much of those checks should we enforce?
- What do graceful failures for these scripts look like?
Containerization of workflow components has become a popular and successful tool for managing moving parts within complex research pipelines. When performed appropriately it improves portability, reliability, and reproducibility. Bioconductor currently supplies a small set of interactive containers, however that only covers some container use cases. Being able to offer simple and automatic container generation for workflow management would help easy the scale up transitions from small scale and exploratory analyses to large-scale analytical workflows.
Key considerations:
- How would / should users call on these containers?
- Its likely that containers built on specific r-base versions won’t need to be maintained in perpetuity as long as the construction path and components remain exposed.
The Tidyomics community has supplied guidance for contributing to their list of known bugs and open issues here, and have a github project board to help with these contributions.
Bring your own bugs and fixes.
If you have further questions, please contact Nick Cooley at Nicholas(dot)cooley(at)ul(dot)ie.