Explore Projects

The EGI-MFF reader in MNE-Python uses an old internal parser that’s pretty hard to maintain and often runs into timing drifts or memory issues. My plan for GSoC is to completely modernize this by switching the backend over to the 'mffpy' library. I’m going to build a wrapper that keeps everything backward-compatible while fixing those annoying 1-sample errors and array mismatches that have been blocking users for years. By the end of the summer, I’ll have delivered a refactored read_raw_egi module that supports O(1) memory mapping, so researchers can stream huge files without crashing. I'm also making sure we get proper support for PNS channel mapping and automated bad-channel detection. Most importantly, I’ll be building a solid regression test suite to make sure the event timing stays microsecond-accurate, which is crucial for the neuroscience work this library supports.

<p>Amahi android offers the ability to stream your HDA over your Android phone and Android TV, support for Chromecast and auto upload of images to HDA. The idea behind this project is to add new features to Amahi Android App which includes browsing files on Amahi servers, storing them for offline access and streaming multimedia. The app currently lacks the following features:</p> <p>(1) Secondary user login support.</p> <p>(2) Module to Auto Backup files on phone to HDA over Local Connection.</p> <p>(3) Sharing files with other servers.</p> <p>(4) Support for VPN proxy.</p> <p>(5) Expresso based automated UI testing protocol.</p> <p>(6) New theme corresponding to Amahi website.</p> <p>(7) Storage and display of last opened details of each file.</p>

<p>For the purpose of High Energy Physics (HEP) Experiments, the framework required should be able to support the scale and complexity of HEP codes. cppyy is such a framework that provides a fully automated, run time, language bridge between Python and C++. For cppyy, both the implementations - CPython (the default byte-code Python interpreter written in C) and PyPy (a Python interpreter written in Python language) - support CINT, an interpreter for C/C++ for rapid development. Moreover, the CPython version also supports Cling. Cling is an interactive C++ interpreter, built on the top of Clang/LLVM that provides a high-performance alternative to the C++ interpreter in ROOT called CINT.</p> <p>The purpose of this project is (1) to integrate the Cling back-end into PyPy implementation; while (2) ensuring maximum reuse of existing code on both CPython/cppyy and PyPy/cppyy implementations for better compatibility and maintenance; and (3) implement a method for distribution of Clang modules with the standard Python distribution tools using pip, the Python Packaging Authority recommended tool for managing and installing packages.</p>

<p>As seen on Blog Posts on Planet KDE support for High-DPI monitors has come a long way since Plasma 5.0. And thanks to the work by many dedicated people the situation in Plasma is now almost ideal. But unfortunately, this is not the case for all KDE applications. Support for HiDPI seems to be more of a hit-and-miss for some of them, many crucial for day-to-day workflows (like Okular and Gwenview). Competing desktop environments have nowadays a nearly perfect HiDPI support, so I think it is time to face the remaining problems once and for all.</p> <p>Therefore I suggest the following approach: My Google Summer of Code project will find HiDPI rendering issues in KDE applications and fix them in a coordinated approach. I will look at applications, which are usually installed on the users desktop, like the Plasma Workspace, Systemsettings and utilities from the kdegraphics module (gwenview, okular, spectacle).</p> <p>This will also require working together with KDE community members, which report bugs, and application maintainers, to get the submitted patches on the KDE reviewboard in a state that allows them to be committed in their respective repositories.</p>

MAVProxy is a powerful command-line based “developer” ground station software. It can be extended via add-on modules, this project is about Chat module, which enables user to query or control the vehicle by giving audio or chat prompts. The proposal is to enhance AI chat module by 1. Adding chat streaming support, which enables users to see response as soon as it starts generating which makes the wait time less annoying and also saves user's time as user can start reading the chats as soon as they are generated, 2. Audio recording enhancements i.e. implementing a push button to record feature in which recording will start when button is pushed and will stop when button is released, currently it is hard coded to 3seconds i.e. it automatically stops recording after 5 seconds 3. adding cancel feature to cancel current run with chat-bot, currently if user prompts something then it will not cancel or stop before it completes the run. 4. Experimentation with local llms 5. Moreover will experiment with the assistant prompts for better results and reduced latency.

The erddapy package provides a Python interface to the ERDDAP data server API. Currently, most of erddapy's functionality is concentrated into a single class, and the URL building features are implemented in that class along with the data transformation methods that process server responses into Python objects, such as Pandas DataFrames. This project proposes to separate erddapy into core and object (or opinionated) layers. The former will hold the URL building and data transformation functionality, which will be reused by the rest of the library. The latter layer will provide high-level objects that will support a functional API that does not depend on the state of the underlying object (which is the case for the current version of erddapy). This functional API will provide cleaner iterative usage when querying multiple servers and datasets, and new classes implemented in the object layer will support serialization so that they can be pickled and passed on to other processes or machines. To execute this project, I delineate two separate aims: refactoring the URL building and data transformation functionality into a new module containing minimal, standalone functions and reusing those functions in the existing primary class; and implementing an additional layer containing the high-level objects that will provide the basis for the functional API. Overall, this will greatly improve the flexibility and scalability of the package, and will help support its wide spectrum of users.

Linux Kernel Livepatching is the process of replacing functions in the kernel code affected by CVEs with the patch-applied functions during system runtime. It's basically a method to apply security kernel patches to a running system such as a server without rebooting it. Such a feature is crucial for servers running crucial computational tasks 24/7 which cannot afford a reboot. Livepatch module is already provided by the Linux kernel but it's upto the distributions as to how they will be handled. As of 2026, only a few handful amount of distributions like SUSE, Ubuntu and RedHat offer Linux livepatches, which means no community maintained distribution at the moment offers Linux livepatches. There has been a way to utilise Linux livepatching in Debian in the past using kpatch but after the release of Debian 13 Trixie, the support for the kernel in kpatch has been dropped which halted the progress of supporting livepatching in Debian. klp-build is a promising approach to this problem but it only supports SUSE kernels which are only accessible by internal SUSE employees. Debian also lacks a release plan or mechanism to distribute livepatches for kernels. The goal of this proposal is to introduce Linux livepatching in Debian by studying how livepatches can be integrated into Debian and if existing technologies like clang-extract can be integrated into the workflow, forking klp-build to develop dlp-build which will serve as a tool to create livepatches for Debian kernels, as well as proposing a binary format for livepatches and designing a release cycle for the same.

The goal of this project is to get syzkaller, a coverage-guided OS kernel fuzzer, working under FreeBSD/RISC-V. As syzkaller is written mostly in Go, the first step is to ensure that Go is able to compile syzkaller. Previous work can be harnessed from two projects to make this tractable. First, Go has a RISC-V port targeting GNU/Linux, and second, the CHERI project has a FreeBSD/mips port of Go. The next step is to add FreeBSD/RISC-V support to syzkaller itself. A work-in-progress patch for FreeBSD/arm64 support can be used as a template. Two bonus tasks are: 1. upstream Go support for FreeBSD/RISC-V to the Go Project, and 2. begin fuzzing system calls under FreeBSD/RISC-V. Syzkaller is flexible enough to target OS interfaces other than system calls. For example, it has been used to fuzz the Linux USB stack and has found dozens of bugs in the USB subsystem alone. The details are complicated, but the idea is simple. 1. Generate a program, which invokes one or more system calls. 2. Run the generated program. 3. Check to see if the system diagnosed an error. - If not, collect kernel code coverage information and decide whether to try iterating upon the previous test program, or start anew. - If so, collect information about the crash and try to discover a minimal test case that triggers the crash. The mentors will have weekly meetings with the mentee to discuss progress and strategies for overcoming any challenges.

The application of Network Control Theory to medical neuroimaging consistently faces the approximation crisis. Current tools rely on infinite-horizon continuous models, binary structural masking and statistically inaccurate harmonization. They fail to capture the discrete, finite time and stochastic truth of brain dynamics grounded in biology. This limits their use in computational psychiatry and biomarker discovery. NeuroSim is intended as a Python model built from scratch to resolve these problems. It aims to simulate in-silico brain stimulation with rigorous physics-based constraints. Over the 350 hour period, the three prime modules will be made available to the community:- 1. Discrete Finite Horizon Physics: A transition from standard iterative summations to discrete time Van Loan Doubling algorithm, significantly reducing computational load for large scale neural networks. 2. GraphNet based Laplacian Regularization: Implementation of a proximal gradient descent module to generate soft-prior connectivity matrices. This resolves the problem of structural blindness in binary DTI-based masking. 3. Bias-less Harmonization and Ground-truthing: Deployment of a NeuroCombat protocol to ensure data security in multi-site studies. Validation to be done against non-linear Wilson-Cowan neural mass simulations. Using the above modules, NeuroSim positions itself as a highly scalable, diagnostic-adjacent toolset capable of modelling complex neural mass transitions. It establishes a standard for next generation non invasive neuromodulation and macro-scale brain stimulation.

Symbolic integration is one of the central capabilities of any advanced calculator system e.g. Mathematica. SymPy currently provides several integration strategies including heuristic methods, algorithmic approaches such as the Risch algorithm, and a rule-based integrator implemented in sympy.integrals.manualintegrate. The manualintegrate module performs integration by recursively applying pattern-based rules similar to how integrals are solved manually. While this approach produces readable step-by-step results and supports a wide range of expressions, its current rule coverage is limited and many integrals involving special functions or structured products are not recognized. The goal of this project is to extend the rule-based integration system in manualintegrate, focusing on improving support for special functions, structured products, and rule prioritization. The project will expand the set of integration rules, improve heuristics for rule selection, and ensure better compatibility with SymPy's symbolic simplification system. The approach is to first analyze the gaps between manualintegrate and more comprehensive rule-based systems such as RUBI in order to identify missing classes of integrals and structural weaknesses. Based on this analysis, the project will design SymPy-compatible rule representations using its existing pattern-matching framework, ensuring consistency with the current architecture. New rules will then be implemented incrementally, with each addition accompanied by rigorous testing and validation to guarantee correctness and stability. Throughout this process, particular attention will be given to preserving and extending SymPy’s step-by-step explanation capability, ensuring that all newly supported integrals remain interpretable and aligned with human-style symbolic reasoning. The end goal is to make SymPy’s integrator more complete, explainable, and closer to human-style symbolic reasoning, while maintaining correctness.

<p>Kuadrant's MCP Gateway uses an Envoy external processor (ext_proc) to parse MCP JSON-RPC requests, extract metadata, rewrite request bodies, and route tool calls to backend MCP servers. This works but adds latency via a gRPC hop per request and requires maintaining custom MCP protocol parsing logic. Envoy has been rapidly adding native MCP support, as of v1.38, the Envoy MCP filter can parse MCP messages, populate dynamic metadata for downstream RBAC/ext_authz filters, handle session management, support SSE and Streamable HTTP transport, and aggregate multiple backend MCP servers. A previous investigation rejected the Envoy MCP filter due to missing body modification support, limited method coverage, and no aggregation, but the filter has since evolved considerably. This project will perform a fresh evaluation, produce a design document mapping each ext_proc responsibility to native Envoy capabilities, identify gaps (particularly around request body rewriting for tool prefix stripping and dynamic metadata consumption by Authorino), build a proof-of-concept demonstrating the native filter approach, and propose an incremental migration path. The mentee will work closely with mentors on the design, validate assumptions through prototyping with standalone Envoy, and engage with both the Kuadrant and Envoy communities.</p><p><br></p><p>Expected Outcome:</p><p>&nbsp;- Design document covering capability mapping of each ext_proc responsibility to Envoy MCP filter features, body modification strategy, dynamic metadata vs header trade-offs for Authorino integration, federation/aggregation comparison, session management analysis, and Istio version dependency chain</p><p>&nbsp;- Proof-of-concept demonstrating Envoy MCP filter parsing requests and populating metadata, downstream authorization consuming that metadata, and tool routing to multiple backends</p><p>&nbsp;- Clear identification of what still requires custom code after migration</p><p>&nbsp;- Proposed target architecture and incremental migration plan</p><p>&nbsp;- E2E tests validating the prototype against existing test scenarios</p><p>&nbsp;- Documentation of Istio version requirements and feature gates needed</p><p><br></p>

<p>The Hiero ecosystem includes a growing number of diverse contributors, repositories, junior committers/committers/maintainers, pull requests, issues, discussions, and quality requirements.</p><p><br></p><p>To build a diverse ecosystem which generates high-quality code, maintainers need to spend a significant amount of time on repetitive coordination tasks such as checking contributor qualifications, validating pull request quality, un-assigning inactive contributors, closing stale issues, creating issues at different difficulties, and ensuring that repository processes are followed consistently.</p><p><br></p><p>We have demonstrated in some SDK repositories many of these maintainer tasks can be automated using custom GitHub action workflows and templates. However, the current setup is fragmented, difficult to customize and scale, and inconsistent across repositories. Different repositories may require different rules, but maintainers still need support to ensure they are working on the most important tasks, and developers need support to help them progress quickly and qualify to gain more responsibilities.</p><p><br></p><p>This mentorship project aims to design and build an automation framework and application for Hiero end-to-end maintainer workflows. The system should support configurable repository automation features that maintainers can turn on or off, depending on the repository context.</p><p><br></p><p>Example user on-boarding workflows:</p><ul><li>Checking contributors are humans</li><li>Checking whether contributors meet contribution requirements before assigning issues</li><li>Offering automatic issue assignment</li><li>Automatically assigning mentors for new contributors</li><li>Issue templates and documentations</li></ul><p>Example pull request review and quality workflows:</p><ul><li>AI issue planning</li><li>AI initial reviewing</li><li>Automated code quality, DCO, GPG, etc checks based on configurable quality requirements</li><li>Automatic review based on configurable quality requirements</li></ul><p>Example developer progression workflows:</p><ul><li>Automatic issue recommendations after a merged pull request to next available issues</li><li>Checking whether advanced contributors meet requirements to progress to JC/committer/maintainer</li></ul><p>Example issue management workflows:</p><ul><li>Managing stale issues or pull requests</li><li>Requesting help or feedback from specified teams based on labels</li></ul><p><br></p><p>A core requirement of the project is to ensure that this automation is reliable, consistent, secure, and scalable enough to be used across a variety of repositories inside Hiero (and one day optionally across LFDT).</p><p><br></p><p>The project should also define clear boundaries for what the automation is allowed to do, how maintainers configure it, and how users can understand or override automated actions when necessary.</p><p>The result should not just be a prototype for a single repository, but a hardened and reusable solution that can serve multiple Hiero repositories with different policies and maintenance needs. </p><p><br></p><p>Lean more at <a href="https://github.com/LF-Decentralized-Trust-Mentorships/mentorship-program/issues/73" rel="noopener noreferrer" target="_blank">https://github.com/LF-Decentralized-Trust-Mentorships/mentorship-program/issues/73</a></p>

<p>My project aims at making the internationalisation process of the p5.js website easier and more accessible to contributors, while also simplifying the maintenance of the translation. I then intend to put these changes into use while adding Italian to the languages supported by the p5.js website.</p>

<p>This project revolves around making the xapian-letor and xapian-evaluation module releasable. It includes writing extensive tests for various High-level API's and low-level pieces, the addition of new rankers and scorer metrics and adding binding support for letor module in various languages.</p>

<p>By playing around with the 2D Arrangement demo, users can have a visual and direct experience on what functionalities to expect from this module before diving into official documentations.</p> <p>The present demo program supports several geometric objects such as line segments. The main goal is to add the support of Bezier and algebraic curves, which enriches the functionalities of the demo.</p>

During the 2018 GSoC period, web components of FHIR Resource using Polymer.js were written. This project is to use those web components to completely re-write the UI of LibreHealth Radiology and LibreHealth Toolkit and make them Open Web App modules. The result would be a complete Open Web App with Spring Data on the backend and Polymer.js web components as the frontend

<p>Bindaas acts as a unified interface to various data sources like Apache Drill, MySQL and MongoDB. The aim of this project is to add new modules that support standard industry authentication and authorization grant flows. This will be achieved by integrating an identity management system that will grant access tokens (in the form of JSON Web Tokens) to be used for the endpoints supported by Bindaas.</p>

1.Adding support animation encoding/decoding to OpenCV library. ( according to result of meetings which file types will be supported.) 2.zlib-ng integration to OpenCV library for accelerating png codec. 3. Writing tests, documentation and sample codes to newly added functionality. 4.There are many issues related to imgcodecs module. After completing main tasks i am planning to work on proper issues to solve.

<p>KDE's Neverland is able to build full themes from a set of template files. The designer needs to only care about the css/js files and the correct nesting of the layout (html). Once satisfied, complete themes for any supported CMS can be outputted and then used accordingly. The project is based on node.js.<br> TL;DR: you give Neverland a Html theme, it gives you WP theme, Drupal Theme, WikiToLearn theme ...</p>

<p>In Jenkins, we have a Remoting module, which implements a communication layer in the Jenkins automation server. It’s being primarily used for controller ⇔ agent interaction. The purpose of this project is to develop software to support the monitoring and troubleshooting of the Remoting system. To achieve this purpose, we will collect telemetry data (metrics, traces, logs) of the Remoting module with OpenTelemetry and send the data to the OpenTelemetry Protocol endpoint. Which OpenTelemetry endpoint to use and how to visualize the data are up to users.</p>

Apache Seata's current service discovery relies on registries like Nacos and Zookeeper, which lack support for custom metadata. This limits the flexibility of client-side load balancing. This project enhances Seata by adding metadata support to the registry module, enabling advanced load balancing strategies based on server-side attributes like weight and region. The result is improved resource utilization, enhanced scalability, and better overall system performance for Seata deployments .

<p>NodeCloud is Node.js based API for open cloud. It works as a standalone core and depends on the cohesive plugins that extends its support onto different cloud providers. Currently, NodeCloud supports AWS, Google Cloud Platform and Azure and houses a handy plugin for all the three providers.</p> <p>With <em>GSoC ‘19</em>, I aim to extend the provider paradigm of NodeCloud, by expanding to <strong>DigitalOcean</strong> &amp; <strong>AliCloud</strong></p>

netboxr is an R package for the automated discovery of biological process modules by network analysis. The project involves updating netboxr functionality. The proposed updates include the addition of new analysis features (more specifically, the ability to support weighted nodes in community detection and to parameterize the sizes of returned modules), and making netboxr more widely available to researchers via the Galaxy platform. Additionally, time-permitting, a pipeline for processing datasets from the cBioPortal using netboxr will also be created.