Explore Projects

This project aims to introduce a new testing strategy so that we encourage Behaviour-driven Development here, at Phoenix — the official web event display of the ATLAS experiment. The whole testing setup of Phoenix needs a complete revamp. Currently, Phoenix as a project comprises 3 packages: phoenix-event-display, phoenix-ui-components, and phoenix-app. And, my goal is to set new benchmarks and coverage thresholds for these 3 packages that will essentially, enforce and encourage testing for the whole of the project with Behavior-driven Development as its sole motivation so that potential issues that may occur in a critical environment can be identified much before they happen. This can effectively help us to troubleshoot problems and bugs so that the changes that will be made in the future to the codebase can be deemed reliable.

CellBox is a model for predicting cell states under drug perturbations, whose code base was originally written in Tensorflow 1. Since Tensorflow 1 has been replaced by Tensorflow 2 and Pytorch, the aim of the project is to recreate CellBox in Pytorch. There are three main components of the model: the data processing pipeline, the model architecture, and the training process, all of which will be sequentially converted into Pytorch. After the conversion is complete, the new Pytorch model is trained using the same training configurations as the Tensorflow model. The following deliverables define the proposal’s success: the trained Pytorch model should reproduce the same results as the current Tensorflow model; the new Pytorch code base should be configured to be able to run on multiple platforms (Linux, Mac, …); and the github should have clear documentations for installing and running the model.

This project aims to extend the plot module by implementing the missing building blocks needed for end-to-end chart creation. The work will focus on improving how data is mapped to visual representations, adding support for a broader range of visual elements, and enabling better composition of charts. Additionally, the project will introduce features for interactivity, layout management, and common data processing operations, making the API more practical for real-world usage. Each component will be developed with proper testing, documentation, and performance considerations to ensure reliability and consistency with the stdlib ecosystem. By the end of the project, users will be able to programmatically generate complete and reusable visualization specifications using a modular JavaScript API, without relying on manually written JSON.

<p>DNSTool is a project that serves the purpose of rapid monitoring of DNS traffic over time. This system allows its users to create their seed lists for DNS monitoring or add given seed lists to their watch lists. DNSTool also allows its users to control the DNS resolution scopes over global scan endpoints. DNSTool-CLI is an extension of the DNSTool, which is designed to monitor the given set of internet resources like domains, IP, SOA, etc. This component allows the downloading of the DNS scan feed(s) automatically by integrating the CLI to their corn jobs or Airflow automation. This project is to develop high throughput and low latency data transferring pipeline with authentication for transferring the data from the system’s file store to the consumer environment.</p>

<p>The ROOT project is developing a JavaScript library for reading and rendering ROOT objects in modern web browsers. The rendering of 3D objects is done with the library THREE.js, and though much of the conversion has already been implemented, there are still many desirable features left to be added. These include interactively selecting particular model components, adjusting a cutting plane to view various cross sections, animation, camera tracks, and possibly an exploded view to more closely examine complex regions. In addition to creating these new features, the project will improve the rendering performance. The current implementation can handle several hundred volumes, but this figure will be increased as much as possible, and finally a method for pruning down geometries to manageable sizes will be devised.</p>

<p>There are many internet pages providing data sets for educational and academic purposes concerning various fields of science, and not only (astrophysics, statistics, medicine, etc.). Some tools used in the scientific field provide some "wrappers" for such online sources and allow the user to easily investigate these data sets and work with them in all kinds of applications, whilst the technical details and methodology like the fetching of data from the server and parsing are done completely transparent for the user. The user doesn’t even know what happens in the “background”. The goal of this project is to add similar functionality to LabPlot. This would make LabPlot more fit for educational purposes, students and teachers could use LabPlot for visualizing and analyzing data connected to the currently studied field. And also could bring LabPlot into the life of the average student.</p>

<p>Ipptool is a program that allows sending IPP requests to a specific printer or server in order to test it or to receive printer information in the form of responses. It is used by CUPS to pass requests like get-printer-attributes, get-jobs, print-job to the printer.</p> <p>Ipptool is also used by PWG’s IPP Everywhere self-certification program’s software, which is used by printer manufacturers to test if their printers satisfy IPP Everywhere standards. The IPP Everywhere Self-Certification program does not test the printers for some of the operations and attributes required by IPP Everywhere. This project involves writing scripts to cover these standards and new scripts for other IPP specifications. It also involves writing the program ippfuzz to fuzz-test printers.</p>

Calorimeter is one of the most important components of the Large Hadron Collider (LHC) experiments, detecting energy loss of particles after collision. However, current Geant4 simulation of showering process in the calorimeter is inherently slow for large amounts of events, especially after High Luminosity Upgrading in the future. Therefore, generative models and other machine learning techniques can be used to accelerate the Geant4 simulation. This project aims to improve the performances of the current VQ-VAE Transformer for particle showering and explore architectures beyond (VQ-)VAE and/or Transformer, including new position embedding, hierarchical attention, an-isotropic attention, Fourier Transform linear mixer, and etc. We expect to provide deliverables including notes of extended numeric experiment and integrating new models into the project code.

Table 1 or demographic tables are used to set the baseline characteristics in medical research. They are often the first table in the papers indicating the study population. While Table 1 is necessary for an article, the traditional generation methods are tedious and time-consuming. The D4CG platform serves as an independent data source for medical research. If the platform can provide self-generated Table 1 based on the users' preferences, it will support the researchers and help to get a deeper insight into the data as well. This project aims to provide a new component for the PCDC portal enabling the users to get Table 1 in various layouts with selected data. The project will involve user interface design and data analysis to make the tool best suit the users' requirements.

Modernize the Sample Platform with 8 targeted improvements: (1) a unified AI-friendly endpoint that serves all test artifacts — binaries, logs, inputs, outputs from a single URL with signed download links; (2) a has_ever_passed flag to distinguish regressions from tests that never worked; (3) a React-based test management dashboard replacing raw SQL workflows; and (4) a smarter diff algorithm using difflib. SequenceMatcher with subtitle-aware parsing to eliminate cascading mismatches; (5) automated git bisect to pinpoint the exact commit that introduced a failure; (6) cross-platform comparison views for Linux, Windows, and macOS results; and (7) macOS testing support via GitHub Actions runners. (8) Test Suite Expansion

This project aims to add a livepatch subsystem to dynamically update kernel code. Having a way to patch bugs or security vulnerabilities without restarting the whole machine would be very useful, especially on servers, which make up the majority of FreeBSD usage. Patches will be delivered via kernel modules, utilizing ELF headers and CTF/DWARF metadata to accurately resolve internal symbols. The patching mechanism will redirect control flow by inserting trampolines at the prologue of target functions. To ensure system stability, patches will be safely applied using a stop-the-world consistency model via smp_rendezvous, with safeguards to prevent the modification of critical routines like the SYSINIT routines. Stack trace analysis will also be explored to more accurately detect function quiescence.

The proposal aims to enhance the BRL-CAD experience through a new GUI. Leveraging my software development background, including projects like Website Buddy and an Inventory Management System, I'll tackle Arbalest's limitations. Familiar with BRL-CAD components and ongoing codebase exploration, I'll fix bugs, add navigation, resize primitives, create a toolbar, and extend the C++ Geometry API. Four milestones with specific deliverables and a development timeline will ensure progress. With a commitment of 21 hours per week and flexibility for academic commitments, I'm dedicated to the project's success. My passion for open-source development and positive experiences within the BRL-CAD community drive my involvement. With proficiency in C++ and Qt, I'm prepared to contribute effectively to enhance the BRL-CAD user experience.

<p>The current GNSS-SDR platform is a software defined receiver that supports GPS, GLONASS, and GALILEO GNSS signals. It also partially supports Beidou signals, but this is limited to the Beidou B1l signal. This proposal will expand the software receiver to accommodate acquisition and tracking of Beidou B2a signals that would further expand the receiver's capabilities in facilitating research on multi-constellation and multi-frequency receivers working with real signals. In addition, the demodulation of the navigation messages will open the door to innovation in multi-constellation receivers, addressing topics such as integrity, reliability, robustness, enhanced coverage, and high-accuracy positioning. Furthermore, the integration of Beidou observables into the position velocity time solution will allow the achievement of the aforementioned diverse range of applications and components.</p>

<p>All the GPU drivers have a scheduler component that schedules the job received from the applications on the GPU hardware. Recently the amdgpu’s (AMD’s graphics driver) scheduler was shifted to a common space (now called DRM GPU scheduler) so that the other drivers can reuse the code. The GPU scheduler is now used by amdgpu and etnaviv (graphics driver for Vivante GPUs). It provides entities which allow userspace to push jobs into queues which are then executed by a hardware run queue. Now amdgpu has multiple identical hardware queues and we currently map round robin to the software queues provided by the GPU scheduler when those are created. To better balance the load we could extend the scheduler to feed multiple hardware queues from just one software queue provided by the GPU scheduler.</p>

I am proposing an improvement to the observability capabilities of Apache Dubbo-go, a Dubbo implementation written in Golang used to solve communication and governance problems under the microservice architecture. The current implementation of the observability feature is not comprehensive enough and not aligned with Dubbo-java's implementation. My proposal consists of two major improvements, one for metrics and another for tracing. For metrics, the proposed improvements include adding metric instrumentation for the consumer side of RPC calls, as well as for the registry, configuration, metadata centers, and RPC exception handling. For tracing, the proposed improvements include enhancing the configuration loading and component initialization for tracing, adding support for the B3 standard, aligning the configuration with Dubbo-java, and adding support for other observability backends. The deliverables include feature implementation, tests, samples, and documentation.

Nowadays, more and more researchers and students choose OpenOffice as an alternative to MS Office. JabRef already provides OpenOffice integration to support reference management, but several important limitations remain: a) JabRef does not properly support footnote citation for CSL style. b) Citations inserted by other reference management tools are not compatible with JabRef. c) Several issues regarding LibreOffice have remained unsolved for years. To address these problems, this project intend to introduce a unified citation representation and a shared global ordering component to ensure consistent behavior across in-text citations, footnotes, and bibliographies. In addition, it enables smoother switching between citation styles and improves compatibility with other reference management tools. Overall, this project will enhance the reliability and usability of JabRef's OpenOffice integration for academic writing.

**Pwndbg** is a debugger extension that enhances the debugging experience. It currently supports only GDB and LLDB on Linux and macOS. This project introduces Windows support for Pwndbg. Initially, only WinDbg will be supported, but a generic interface could enable support for other debuggers (GDB, LLDB, x64dbg, etc.). The goal is to bring Pwndbg enhancements to the WinDbg console — providing a similar experience to using it with GDB or LLDB. End users should be able to access all native WinDbg features while also using Pwndbg commands and context windows. The project leverages WinDbg’s `wdbgexts` or `DbgEng` to interface with Pwndbg. This requires either an RPC client-server protocol or native integration of Pwndbg on Windows. Pwndbg needs to hook into WinDbg states (registers, memory, etc.) and respond to all command calls from WinDbg.

This project focuses on optimizing and deploying EduAid, an AI-powered tool that generates interactive quizzes from educational content. Key deliverables include: - Adaptive Difficulty Control: NLP-driven question generation targeting overlooked concepts using TF-IDF scoring and synonym replacement. - Multilingual Integration: Leveraging the T5 model to enable question translation into German, French, and Romanian. - Scalable Infrastructure: Deployment via Electron.js, Celery-Redis task queues for scaling by the factor of 10x. - Performance Enhancements: Model quantization (25% size reduction), ONNX runtime acceleration (65% latency improvement), and service workers for background processing. - Unified UI/UX: Revamped frontend with reusable components and IndexedDB migration for efficient data handling.

<p>Eclipse 4diac is an open source environment for programming distributed industrial automation solutions and control systems based on the IEC 61499 standard. One of the components of Eclipse 4diac is the 4diac IDE which is an integrated development environment for modeling distributed control applications compliant to the IEC 61499 standard. The current version of 4diac IDE does not support the validation of the models, which makes it difficult for users to get design-time feedback on inconsistencies regarding the models developed in 4diac. The Object Constraint Language (OCL) could be a solution to find issues in 4diac models since it provides capabilities for specifying generic constraints a model has to fulfill. The aim of this project is to develop OCL constraints and well-formedness rules to the metamodels of 4diac in order to improve the usability of the IDE.</p>

Pwndbg delivers a powerful debugging experience on traditional Linux systems, but its support for Android environments remains limited. This is largely due to fundamental differences between GNU libc and Android’s Bionic, as well as the lack of tooling for Android-specific components such as Binder. As a result, many existing features either do not work as expected or provide limited insight when analyzing Android binaries. This project aims to address these limitations by introducing structured and practical support for Android within Pwndbg. It will extend existing features to correctly handle Bionic internals, particularly in memory inspection and heap analysis, and improve Binder support by enabling meaningful userspace inspection. Additionally, the project will refine internal abstractions to ensure consistent behavior across LLDB and GDB.

The proposed project aims to bridge a critical gap in the Kubeflow ecosystem by introducing robust Helm-based deployment support. While Kustomize has been the default configuration tool, many organizations have standardized on Helm for managing Kubernetes applications due to its templating capabilities and ecosystem support. This mismatch has led to significant maintenance burdens, with adopters often resorting to maintaining custom Kustomize forks to support essential components such as Istio and OAuth2. These customizations introduce complexity in upgrades and contribute to version drift, undermining reliability. By enabling Helm-based deployment, the project will align Kubeflow with mainstream Kubernetes practices, simplify maintenance, and foster broader community adoption. This initiative also supports the CNCF’s goal of interoperability and standardization across cloud-native projects.

Karmada would like to improve the UT coverage of the code to better maintain the quality of the code and reduce the introduction of defects. Increase the UT coverage rate to 50% to 60% (currently, the UT coverage rate is [28.26%](https://app.codecov.io/gh/karmada-io/karmada) ). The entire Karmada repository is a bit large for one project, so we will split it into two projects. The current parts mainly target the `karmada-controller-manager` and `karmada-scheduler` components. Expected Outcome: - Increase the UT (Unit Test) coverage by more than 25% and add more than 4000 lines of code coverage in the following directories: pkg/controllers pkg/dependenciesdistributor pkg/descheduler pkg/detector pkg/estimator pkg/scheduler pkg/resourceinterpreter pkg/util

The Jenkins Repository Permission Updater is used to distribute the permissions on Github for the Jenkins plugins. Currently this work is partly done manually by the hosting team of Jenkins or by the existing code of the Repository Permission Updater which is still based on, partly Groovy. By using YAML files, it should be possible to set the permissions automatically with pull requests through various components such as GitHub API, Jira and Artifactory, so that removal and update is also possible. By integrating official interfaces such as JIRA, GitHub, Artifactory and revising the structure, it will be possible in the future to update, set and remove rights more easily and without manual effort. Manual implementations will be replaced by interfaces with better structures, i.e. Github, Jira and Artifactory. By replacing Groovy code, it will be possible to use Java 21 in the future.