Explore Projects

Kolibri's current Windows installer is outdated, difficult to maintain, relies on the unsupported IE11 engine, and lacks parity with the modern kolibri-app used on macOS. This project aims to replace the legacy installer by enhancing the existing Python-based kolibri-app to provide a first-class experience on Windows. The solution involves integrating the Microsoft Edge WebView2 engine, implementing native Windows features such as background operation via a Windows Service (using pywin32) and a system tray icon (wxPython), and creating a new native installer using InnoSetup. The application architecture will separate the UI and server processes for robustness. An automated build pipeline using GitHub Actions will be developed to produce the application bundle (via PyInstaller) and the final installer package, including code signing for releases. Main deliverables include: a functional Kolibri Windows application built from the kolibri-app codebase, a native InnoSetup installer (.exe), system tray functionality for server management, reliable background operation via a Windows service, seamless WebView2 integration, and an automated GitHub Actions build workflow for Windows artifacts.

Linux profiling tool a.k.a perf is the home for analyzing the entire system. It provides the support to analyze the stacks end to end leading from hardware events such as instructions executed, cache-misses suffered, or branches mispredicted to software events such as CPU-clock, page-faults, task-CPU etc. The linux perf tools help us to point out exactly where the specific event is leading to performance downturn in kernel, BPF or userspace application. The increasing demand for consolidation due to the bloom in fields of AI and the cloud technology requires increased efforts to provide best performance for novel devices. As software systems become increasingly complex, identifying and resolving performance bottlenecks becomes more challenging. In an effort to address this issue, this project seeks to enhance the support for performance data analysis in various formats commonly used by software developers. Specifically, we aim to enable the export of performance data to formats such as Firefox's Gecko profile format and Chrome's trace event format, making it easier for developers to analyze and optimize their code for different platforms and environments. By doing so, we hope to improve the overall performance and user experience of software applications.

<p>Particle transport Monte Carlo simulations are a key tool for High Energy Physics experiments, including the LHC experiments at CERN. All Monte Carlo (MC) simulations depend vitally on Pseudo-Random Number Generators (PRNGs) used to sample many distributions. Each LHC experiments generates 5-10 Billion sampled physics events a year using around 10^18 sampled values from PRNGs. PRNGs take 1-5% of CPU time. PRNGs used must possess very large periods, fast execution, the ability to create a large number of streams, and very good correlation properties between streams and sampled values. It must be possible to reproduce a simulated event any time, for reexamination or debugging. The transition from event-level parallelism in Geant4 to dynamical multithreading in GeantV requires associating the random generator states not with the threads but with the tracks, which are shuffled between "baskets" based on their type and energy. Maintaining reproducibility after such transition requires a drastic change in the way the random generators are used. We suggest solutions based on Scalable Pseudo Random Number Generators and on pedigrees introduced in CilkPlus, which are first tested in Geant4.</p>

This project addresses critical gaps in Gemini API integration across leading agent frameworks (LangChain, LlamaIndex, CrewAI, Composio), where multimodal capabilities and function calling remain underdeveloped or inconsistent. By implementing standardized components for multimodal processing, function calling, and performance optimization, the project will democratize access to Gemini's advanced capabilities for developers building sophisticated AI agents. The implementation will follow a systematic approach, beginning with a comprehensive framework audit and gap analysis, followed by development of core multimodal support, function calling capabilities, and performance optimization layers. The solution will include a unified adapter layer that standardizes Gemini API access while respecting each framework's architectural patterns. Deliverables include: (1) enhanced framework integrations with full multimodal support, (2) standardized function calling implementations, (3) performance optimization components including token management and caching systems, (4) comprehensive documentation and examples, and (5) a benchmarking suite for performance analysis. This project will establish a new standard for Gemini integration in the agent ecosystem, enabling entirely new classes of multimodal AI applications.

<p>As the Koordinator scheduler grows additional plugins (NUMA, Device Sharing, Reservation, Coscheduling, ElasticQuota), the project needs a continuous, lightweight performance harness to detect regressions and validate scaling targets defined in the 2026 roadmap. This project will build a Kwok-based simulation framework that drives realistic workload mixes (LSR/LS/BE, gang, reservations, GPU sharing) at scale (target 10k-100k pods), captures throughput, queueing latency, and per-plugin profiling data, and publishes results from a scheduled GitHub Actions workflow.</p><p><br></p><p>Expected Outcome:</p><p>&nbsp;- Kwok-based simulation harness with reusable workload generators for the major Koordinator plugins</p><p>&nbsp;- Scheduled GitHub Actions workflow that runs the harness on each release branch and publishes Markdown reports</p><p>&nbsp;- Baseline performance metrics and regression-detection thresholds for the 2026 release line</p><p>&nbsp;- Profiling integration (pprof, scheduler_perf) and dashboards for triage</p><p>&nbsp;- Documentation for contributors on adding new scenarios</p><p><br></p>

Cacti enables two blockchain or DLT networks to transfer digital assets between each other using different mechanisms and modules, inherited from the older Cactus and Weaver projects. The Node Server acts as a container for business logic to orchestrate (or trigger) transactions across multiple networks toward achieving some desired simultaneous state change in those networks. The Relay acts as a gateway, or an ingress/egress appliance, for a given network to send communication to, and receive communication from, another network. Using the Relay or the Node Server or both, one can effect a digital asset transfer from one network to another, sample protocols for which have already been implemented in Cacti with samples for demonstration. Parallelly, there is an ongoing effort to standardize blockchain/DLT interoperation protocols through consultation and brainstorming among experts within the field under the IETF's aegis. The goal of this project is to implement the more current SATP draft specification in Cacti, in the process augmenting the Cacti Relay to be a gateway that provides a reference or template for any other standardized implementation. Using other Cacti modules and sample apps, secure transfers of digital assets using SATP must also be demonstrated. If time permits, performance measurements may also be conducted to benchmark the protocol, and specifically the Relay.

<p>Mission Support Collaboration(mscolab) is a part of the MSS application which allows real-time collaboration and editing of flight paths of a project. However, there are some key features which are currently missing from mscolab. I propose to work on the following features and improvements to mscolab:</p> <h3>Local Flight Path Editing:</h3> <p>There are many instances where a user might want to test out his/her own changes to the flight path locally without changing the path on the server. Another scenario is that the user has a slow network connection at the flight campaign location which is a common problem. Both these situations require a method for the users to be able to make changes to the flight path locally and then be able to compare and merge it with the flight path on the server later.</p> <h3>Chat Service Improvements:</h3> <p>Improve the communication between users by adding features like - markdown support, ability to send images, searching through messages, ability to delete messages and replying to a specific message.</p> <h3>Admin Dashboard:</h3> <p>Develop an admin dashboard window to allow mscolab project admins to manage users efficiently, giving them options to add/modify/delete user permissions in bulk.</p>

<p>QEMU's emulator allows running operating systems and binaries compiled against one architecture (e.g. Linux ARM) on a host with a different architecture (e.g. Linux x86_64). This process involves a JIT compiler that translates the target CPU instructions to the host's. In this process, some targets outperform others, and some targets have performance bottlenecks in QEMU functions that other targets don't.</p> <p>In this project, the performance of QEMU's emulation will be deeply analyzed using major profiling tools across all of its targets for both of its user mode (executables) and system mode (operating systems).</p> <ul> <li>Custom written benchmark programs will be used to activate the desired QEMU functionalities and locate the target bottlenecks and profile its execution and runtime.</li> <li>Automation tools will be written that detects runtime performance degradation across different versions and targets of QEMU. They will also be used to find how different targets perform compared to each other.</li> <li>Past major releases of QEMU will be examined to identify performance regressions from the past.</li> </ul> <p>All of the findings and conclusions will be regularly presented to the QEMU developers to act upon.</p>

Establish a lightweight, scalable design system that brings visual consistency, reusable components, and clear UX guidance across the full scope of KubeStellar. The system will support multiple user-facing surfaces, including websites, software interfaces, and CLI-based tools. This mentorship will serve as the foundational design phase, setting the stage for a future front-end development and implementation effort planned for later this year. Special emphasis will be placed on the documentation site and contributor-facing tooling to ensure immediate impact and long-term scalability. Expected Outcome: The mentorship will deliver a scalable yet lightweight design system tailored to KubeStellar's needs. It will include a component inventory, reusable UI patterns, a full CSS specification, and visual guidelines to ensure consistency and usability across the project's five active areas. While this phase focuses on foundational design work, it will directly support a future implementation phase—enabling contributors to efficiently apply the system to KubeStellar's interfaces, including UI, Docs, and CLI-based tooling. Special emphasis will be placed on ensuring the documentation site benefits immediately from this structure.

This project aims to implement a Visual Attribute Mapping System that enables users to automatically map node and edge attributes to visual properties within the GraphSpace interface. This system will allow users to generate meaningful graph visualizations where the appearance of graph elements directly reflects underlying attribute data — turning raw data into visual insight. There are two main components in this project: User Interface for Visual Attribute Mapping — A new Visual Attribute Mapping panel integrated into the GraphSpace Layout Editor. This interface will allow users to select graph attributes and map them to visual properties through an interactive configuration panel. Users will choose between Discrete Mapping (categorical attributes) and Continuous Mapping (numerical attributes). The interface will dynamically display configuration options based on the selected mapping type and visual property. Backend Support for Attribute Mapping — Backend services that read graph attributes, validate mapping configurations sent by the frontend, compute Cytoscape-compatible style rules, and store them via the existing layout update API. This component integrates with the existing update_layout controller and the style_json storage mechanism — requiring no new database tables.

This project aims to enable many authentication frameworks and add support for an authentication layer to Glee. This will give developers the ability to use Glee to create secure online applications with a variety of authentication choices. To accommodate future additions of new authentication frameworks, the authentication layer will be created to be modular and adaptable. After this project, when using Glee to build a server, the developer should be able to specify the authentication strategy they wish to support. Token-based authentication: This could be done using the jsonwebtoken npm package, provision will be made for both refresh and access tokens. Access tokens will be short-lived tokens, while refresh tokens will have longer life spans and allow for renewal of the access tokens. Basic authentication: This authentication strategy would be implemented from scratch. Certificate-based authentication: certificate-based authentication will be implemented from scratch. OAuth 2.0 authentication: OAuth 2.0 authentication will be achieved using the node-oauth2-server npm package. Session-based authentication: The viable option here will be to build the session-based authentication from scratch, as many of the options available such as passport-session, express-session, and fastify/session are all framework dependent.

The Mifos Payment Hub EE (PH-EE) is a massive ecosystem with about 42 Java repositories that run the open-source DPI payment infrastructure. But there’s a problem: over the years, these components have drifted apart. We have a mix of everything: Java 8 to 17, Spring Boot 2.1 to 3.2, and the old javax.* namespace. This mess makes the platform hard to maintain, full of security risks (CVEs), and prone to dependency hell where one tiny conflict can break the whole stack. My goal for this GSoC is to fix this once and for all. I will lead a systematic migration to a modern, unified baseline: Java 21, Spring Boot 3.4, Apache Camel 4, and Jakarta EE 10. To be sure that everything is perfect, the project introduces a three-level test framework: a BOM verification step (classpath purity check that fails on any javax.* artifact), WireMock + Cucumber integration tests for behavioral equivalence validation, and an end-to-end smoke test via Mifos Gazelle against a live k3s deployment. A platform BOM and a connector starter template standardize dependency governance and build configuration across all components, so the unified baseline remains enforceable after GSoC ends.

<h3>TumorComparer, updated version</h3> <p>The TumorComparer is a computational method for the comparison of different cancer types with cancer cell lines by their cellular profile. This comparison allows finding the closest cell lines for a selected cancer type by molecular profile as well as to detect outliers.</p> <p>The main objectives of the project are:</p> <ul> <li>Expand the package to include new data types</li> <li>Create patient to patient similarity examples on R shiny based platform</li> <li>Provide a network visualization for correlated samples and cell lines</li> </ul> <p>Further updates for the package are:</p> <ul> <li>Implement a function to perform comparison for separate gene sets and make the graphical interface of the function for shiny application</li> <li>Update R shiny application to have better error handling, improved event observers for optimal app performance, and interactive documentation</li> </ul> <p>Finally, an updated version of the package will be capable to analyze new omics data types as well as perform comparisons for separate gene sets. R shiny application will be more optimized and user-friendly.</p>

The Mifos X WebApp is a powerful tool but it can be hard for people to use every day. A lot of institutions have a tough time with it because it is complicated and not easy to navigate, which slows down the people who work there. This project wants to make that better by putting an AI Assistant right into the Mifos X WebApp. The Mifos X WebApp will have an AI Assistant. You can think of the AI Assistant as a place where users can type what they need in language like finding a client making a loan or looking at a transaction and the AI Assistant will take care of the rest. The AI Assistant is powered by a kind of computer program and it talks to Apache Fineract through the Mifos MCP server. The AI Assistant also works with both cloud-based and on-premise models using Ollama so institutions that need to keep their data in their buildings can do that too. The main things we want to achieve with this project are an Angular chat interface built into the Mifos X WebApp, the Mifos MCP server integration, for calling Apache Fineract APIs in a way, an LLM layer that works with both cloud and local models, answers that are based on the current client, loan or user role, and good documentation and tests to go with the Mifos X WebApp and the AI Assistant.

openPIP is an open-source platform for hosting and visualizing protein-protein interaction (PPI) data. The current version is built on a PHP 5.6 / Symfony 2.8 stack that has reached end-of-life, making it difficult to maintain and extend. This project performs a complete rewrite of openPIP using modern web frameworks: a React single-page application frontend with Cytoscape.js for network visualization, a REST API backend (Python/Django REST Framework or Node.js/Express, to be finalized with the mentor), and a PostgreSQL database, all containerized with Docker. Key deliverables include: (1) a clean REST API replacing the 27 monolithic PHP controllers, (2) an enhanced data upload pipeline supporting PSI-MI TAB and CSV formats with drag-and-drop, real-time validation, and async processing, (3) a responsive React frontend with interactive search, network visualization, and an admin panel, (4) production-ready Docker Compose deployment, and (5) a data migration script for existing openPIP deployments (HuRI, YeRI). I have direct experience with the openPIP codebase, having created its deployment guide and migrated the platform from openpip.baderlab.org to openpip.usask.ca.

Problem: Git's "partial clone" is a lifesaver for huge repos because it lets you download only the files you actually need. But once you download a file (a "blob"), it stays on your disk forever. Currently, Git has no way to "un-fetch" these files. Over time, your "partial" clone starts looking like a massive full clone, and the only fix is to delete everything and start over. Solution: I want to build a "reverse gear" for partial clones. My project will add a safe way for Git to drop large, local files you no longer need, while keeping a "promise" that it can get them back from the server later. I’ll be focusing on three main things: Safety: Ensuring Git double-checks that the server still has the file before we delete it locally. "Promise" Contract: Updating Git’s internal records so it knows a deleted file isn't missing, just stored remotely. User Control: Adding this to git maintenance so users can easily reclaim space without being C experts. By the end of the summer, Git will have a new capability to prune local blobs safely. This includes the core C logic for identifying and removing objects, integration with the git maintenance command, and a full suite of tests to ensure no data is ever lost.

<p>TensorFlow is one of the most popular machine learning frameworks and is widely used in fields beyond machine learning and data science. The architecture of TensorFlow has been elegantly designed such that it is possible to be extended in big data, medical imaging, and physical sciences. Supporting different format of data is the necessary step for communities beyond machine learning to adopt TensorFlow, as data is always as the entry point or edge node of the TensorFlow’s graph. Importing data with different formats natively in TensorFlow allows users to build their systems or applications without the need of additional conversion infrastructure.</p> <p>TensorFlow I/O focuses on providing various data format supports for TensorFlow, and many data formats are already supported, like Apache Kafka stream-processing, Amazon Kinesis data streams and also LMDB format and MNIST format, etc. However, the generic JSON format hasn’t been supported yet. It is quite necessary to support JSON format since JSON files are widely used in machine learning and data science.</p> <p>I will be working on providing JSON support in the TensorFlow I/O so that it will be possible to read JSON files into Tensorflow.</p>

Modern printer testing remains heavily dependent on physical hardware, making it slow, expensive, and difficult to scale for regression testing. While OpenPrinting already provides a Go-based MFP simulator and a Python-based image evaluation framework, these components are not yet integrated into a unified, automated testing system. This project proposes to build an end-to-end, hardware-free print testing pipeline that bridges this gap. The system will be implemented as a Go-based orchestration tool that directly leverages the simulator’s internal libraries for efficient control, while embedding Python to execute advanced image evaluation. It will automatically load printer models, create CUPS queues, enumerate all supported print modes, execute print jobs, capture simulator outputs, and evaluate them against expected results. The pipeline will support both single and batch testing modes, enabling scalable regression testing and seamless CI/CD integration. It will generate detailed, structured reports with quality metrics (e.g., SSIM, PSNR) and pass/fail analysis. By transforming isolated components into a cohesive, automated system, this project will significantly enhance reliability, reproducibility, and scalability of printer testing in the OpenPrinting ecosystem.

<p>The main goal of this project is to create a component that has a clear API that can provide autocomplete feature for the jupyter kernel - mariadb_kernel. And also I hope that component can be easily integrated with not just jupyter, but also VSCode and Atom … etc popular editor. The main feature has two:</p> <ol> <li>can get the latest MariaDB keywords and functions for autocompletion. (implement new table in MariaDB's information schema, and can use SQL command to get the information)</li> <li>provide an introspection feature that can inspect the word's info and some real data.</li> </ol> <p>And this project autocompletion feature is based on mycli's autocompletion engine. Then do some enhancement on that. Such as:</p> <ol> <li>Database suggestion before 「.」. Ex: 「insert into db_name_to_be_completed.table_name VALUES (...) 」</li> <li>add global and session variable suggestions</li> <li>can suggest system default database, table, column. Ex: add column suggest for system table like mysql.user.</li> <li>Autocompletion about database_name.table_name_to_be_completed could suggest the table, which not in the currently selected database</li> <li>fix some bugs related to the word of the user is the column name and also is the keyword</li> </ol>

This is the tentative proposal submission for the Geant4-FastSim - Building an ML pipeline for fast shower simulation. This proposal discusses a detailed approach to implementing the Kubeflow End to End Pipeline for the existing framework. The proposal consists of a synopsis discussing how the proposed approach was thought and what were the key insights that motivated the steps mentioned. It further discusses the task that will be encountered throughout the Project timeline and the Major Deliverables that would mark the completion of the project. The Major tasks have been visited in detail in the proposal and these are used to determine the objectives for the weekly progress timeline in the project. The proposal tries to cover up all the adopted methodology's significant detail and come up with the most ideal way to tackle each and every task. Deliverables: End to End Deployed ML Pipeline on Kubeflow Meta Logger component throughout the pipeline to store and analyze the results Experimenting with existing and new algorithmic approaches that might improve the performance, throughput of the modeling pipeline Creation of a connector component for the transition from training phase into the inference phase. Iterative development of the Pipeline into a generalized workflow that is capable of scaling to newer versions of data as well support the integration of newer algorithmic experimentation Well documented results and analysis for motivating additional focus on the pipeline as well motivating the use of this pipeline for different projects \

<p><em>The aim of this project is to implement a backend for museums &amp; exhibits that utilizes Physical Web technology. </em>The backend will allow visitors to access information about exhibit pieces without the need to install any apps. Physically, this will be accomplished using Eddystone beacons located near each piece. We focus on developing the software used with the beacons.</p> <p>To achieve this, we will create an Android App that allows museum curators to configure Physical Web beacons they want to deploy and upload the content that will be served. The app will support combinations of text, images, audio and video - it will use Google Drive for its storage backend. The app will also allow the curators to create a map of the exhibition &amp; beacons - also stored on Drive.</p> <p>Once activated, the beacons will direct visitors to the URI of a webapp that we will also develop. The webapp will run on a server that connects to the Google Drive folder created by the Android app. This webapp, run on the museum’s servers, will use the map along with Web Bluetooth technology to learn the user’s location (by listing nearby beacons and their signal strength) and display to the user the content most relevant.</p>

Software acceleration utilizing specifically designed hardware components is a widely used technique for speeding up different kinds of kernels found in the targeted applications. An example of such kernels in High-Performance Computing (HPC) are algorithms involving the computation of sparse data structures. Sparse applications are difficult to accelerate due to their memory-bound nature, which means that the data is not accessed contiguously in memory. That implies many scatter and gather accesses to the comparatively slow memory. Consequently, dedicated hardware components capable of accelerating the scatter/gather instructions, are a key to improve the performance of sparse applications. The goal of this project is to achieve an FPGA-based acceleration of the vrgather RISC-V vector instruction (RISC-V ISA vector extension v1.0) using a bitonic network. The bitonic network is originally a sorting network that implements the merge-sort algorithm (add reference here). A number of inputs of the network can end up in any output after traversing it. When this concept is applied to a Vector Register File, the bitonic network can be used not only to sort a set of vector elements, but also to move data internally from one register to any other register. The scope of this project is limited to the execution and acceleration of the gather vector instruction, in which the variability of the vector length needs to be considered.

Performance evaluation of DLTs is a complex process stemming from the inherent complexity of distributed systems. One way to mitigate such complexity is the separation of concerns: use task-oriented solutions for different aspects of the process: - The System Under Test (SUT) is deployed in a representative operating environment. - A dedicated, purpose-specific load generator tool submits representative requests to the SUT. - The SUT is closely monitored during the load generation process, and the measured data is typically stored for post-mortem analysis. - A detailed analysis is performed on the measured data using dedicated data analysis techniques. A summarizing report is the typical final output of the process, containing insights about the SUT. Hyperledger Caliper provides capabilities to integrate lightweight components that can retrieve aggregated results from external components and incorporate them into the generated report. The goal of the project is to provide a single entry/exit point to the performance analysis (once the SUT and its monitoring are configured) by: Providing an open, well-designed, and thoroughly documented side-car service for the detailed performance analysis of distributed Fabric transaction traces. And integrating it into the Caliper load generation and response measurement process as part of the final report. The project will heavily build on the PSWG's Performance Sandbox, aiming to "standardize" its flow and methodologies independently