Explore Projects

Description: Cluster API Provider GCP (CAPG) enables the creation of Kubernetes clusters in GCP with Cluster API. With increasing adoption of Cluster API (CAPI) in general and of CAPG we want to improve the supportability of CAPG, especially for production environments. The first part of this is to add telemetry/tracing using OpenTelemetry so that we can understand and visualize the flow of reconciliation within the provider. The next part is to add a **pprof** endpoint that can be optionally enabled to enable operations/support users to collect profiling information from a running instances of CAPG. Expected Outcome: This work will enable tracing and profiling of a running instance of CAPG (along with supporting docs) to supports operations/support engineers.

The Inspektor Gadget gadgets are heavily coupled to the kernel version as they need to access internal kernel data and use different eBPF features. One key feature for Inspektor Gadget is to hide all this complexity from its users: the gadgets should work the same regardless the kernel version they’re running in. To be sure our gadgets (and Inspektor Gadget too) are working fine, we need to run tests on different kernel versions we want to support. The purpose of this mentorship is to develop a framework that allows gadget developers to (1) implement unit tests for their gadgets (2) and run them on different kernel versions. A previous mentorship successfully implemented a framework for running integration tests (https://github.com/inspektor-gadget/inspektor-gadget/pull/2607), now it’s time to extend that framework to allow running unit tests as well. Some preliminary investigation done in (https://github.com/inspektor-gadget/inspektor-gadget/pull/2638) explored the possibility to use https://github.com/lmb/vimto, it seems it’s the right tool for the job. Expected Outcome: Gadget developers have a way to run unit tests in different kernel versions for their gadgets in their CI platform Upstream Issues: - https://github.com/inspektor-gadget/inspektor-gadget/issues/3195 - https://github.com/inspektor-gadget/inspektor-gadget/issues/1343

<p>In many fields of science and engineering (such as electrodynamics, acoustics, and quantum mechanics), the partial differential equations (PDEs) can be complex-valued. Currently, the finite element solver of the FEniCS Project, DOLFIN, supports only real floating-point arithmetic limiting the scope of application on these fields. The primary goal of this project is to extend the capabilities of DOLFIN to support complex numbers, and thus to directly represent complex-valued fields, opening up the possibility of the solution of large-scale complex-valued PDEs using FEniCS.</p>

This project aims to develop quantum transformer architectures for high energy physics (HEP) analysis at the Large Hadron Collider (LHC). The focus will be on creating hybrid and fully quantum transformer and vision transformer models. Transformers have proven to be extremely powerful, revolutionizing the field of artificial intelligence and significantly impacting the world with their wide range of applications. By merging the remarkable capabilities of transformers with the emerging field of quantum machine learning, this project aims to make significant advancements in both areas. To ensure accessibility, an engaging visual guide will be provided, helping a wider audience understand the subject and fostering interest in quantum machine learning. The outcomes of the project are expected to benefit the open-source community and contribute to scientific advancements, inspiring further research and innovation in these exciting fields.

Generics are a common functionality found in statically typed programming languages, allowing easier maintenance of programs which differ only in their types. However, generics are not yet supported in the statically-typed LPython. Generics in LPython can be implemented similar to the approach taken by C++ templates. We can regard generic functions as functions with type parameters, whose parameters are made concrete and checked by function calls on AST level. The end result of the project would be generic function support for LPython with option for specialization, along with sufficient integration tests and documentations.

This project aims to enhance OpenMP support in LFortran by developing a unified ASR node, that encapsulates all core and advanced OpenMP directives and clauses. The new design will enable robust handling of constructs like Parallel, Do, Teams, Tasks, Distribute, and Target offloading, ensuring systematic lowering to runtime calls. Key deliverables includes modifying the current design of representing OpenMp directives in ASR and implementing it's features via runtime calls and explore Target Offloading support. This will make LFortran a more powerful and extensible tool for HPC applications.

This project aims to add support for Multi-Channel Imaging in caMicroscope, a platform used for visualizing and analyzing medical imaging data. Currently, the platform only supports datasets with a spatial representation for up to three channels. This project aims to create a function that can take in numerical data in CSV format with an arbitrary number of channels and select three fields to assign to red, green, and blue channels to generate an image. This project will allow Researchers and Deep Learning partitioners to make sense of higher-dimensional data and improve their analysis of medical imaging data.

This proposal outlines integrating debugging into the xeus-cpp kernel for Jupyter using LLDB and its Debug Adapter Protocol (lldb-dap). Modeled after xeus-python, it leverages LLDB’s Clang and JIT debugging support to enable breakpoints, variable inspection, and step-through execution. The modular design ensures compatibility with Jupyter’s frontend, enhancing interactive C++ development in notebooks.

DocArray is a library for representing, sending, and storing multi-modal data, with a focus on applications in ML and Neural Search. It currently supports several deep learning frameworks, including PyTorch and TensorFlow. Jax is becoming increasingly popular for deep learning, so we want to integrate it into DocArray. The project we propose is to add Jax as a backend for DocArray, alongside PyTorch and TensorFlow. The first part would involve rewriting and translating all of the computational backend functions of DocArray with the Jax framework. Then, we would battle-test the implementation against a real Jax use case, such as integrating DocArray with Jax support for model training and serving.

As a tool aiming to deliver database assets for non-technical personnel, Mathesar should support more data types for the purpose of straightforward operation and easy understanding to meet the different requirements of users. Currently, the data types that Mathesar can support are limited and do not include JSON. Allowing users to read and manipulate data in JSON format can significantly improve the practical value of Mathesar and meet various application scenarios. In this project, we will suport importing, adding, change a database field to a JSON object and enable data validation, modification, and browsing. Also, it will allow the grouping, filtering, and sorting operations based on JSON keys.

Currently, the Newt editor supports Systems Biological Graphical Notation (SBGN) and Simple Interactive Format (SIF) formats while also allowing importing/exporting data in Systems Biology Markup Language (SBML) format. Conversion to SBML format from SBGN or SIF is lossy since the data models are not fully compatible. Information may be lost during conversion to SBML format. This is why supporting the SBML format in Newt is crucial. The main feature proposed to be implemented is for users to create SBML models from scratch in Newt without the need to convert them to other data formats. An additional palette will be added with the corresponding notation to the existing palette for the user to create new SBML models or edit an existing one by dragging elements from the palette.

Pocket Code currently lacks a scalable way for projects to communicate beyond a single device, which limits its ability to support real-time multiplayer features and IoT use cases. While Bluetooth-based communication exists, it is limited in range and flexibility, and does not support internet-based interaction or integration with modern systems like smart home platforms. This project solves this by adding MQTT-based communication to Pocket Code through simple visual bricks for sending and receiving messages. A shared connection manager handles communication efficiently, with support for secure connections, message routing, and reliability through offline queuing and retries. It also introduces a standard topic structure for IoT integration (e.g., Home Assistant) and enables multiplayer synchronization over Wi-Fi, making Pocket Code a more connected and powerful platform. Key Deliverables: 1. MQTT connection manager with lazy initialization and connection reuse 2. Publish and Receive MQTT bricks integrated into Pocket Code 3. Wildcard topic support and event-driven message handling 4. Offline message queue with automatic retry on reconnect 5. Secure communication using TLS and authentication 6. Standardized MQTT topic conventions for IoT and Home Assistant integration 7. MQTT-based multiplayer synchronization layer 8. Comprehensive automated tests (TDD-based development) This project transforms Pocket Code into a connected programming platform, enabling users to build real-time multiplayer applications and interact with IoT devices using an intuitive visual interface.

After WasmEdge provides an experimental API, WASI Socket, for supporting Berkeley Sockets API in Wasm. WasmEdge enabled a new way to open a new socket, listen to an existed socket, and send and receive data. Moreover, it will be nice if we can do more things in the related features such as SSL support. To achieve this feature, one possible way is to compile the OpenSSL library to Wasm and link it as a library. However, the performance may be not good, because all the computation jobs are done at the wasm level. Here is an alternative way, instead of the previous one, we can wrap the OpenSSL library to Wasm external functions. For example, binding `ssl_connect` to `(import "openssl" "ssl_connect" ... )`. Unfortunately, this is not an easy way to do it. To simply the workload, we decide to implement the WASI-crypto proposal first, and then use this proposal to make the above things happen.

<p>LLVM offers 2 useful YAML tools, yaml2obj and obj2yaml. The former one reads YAML files and emits object files, e.g., ELF, COFF and MachO. The latter one does the reverse, reads object files and emits YAML files. We use these tools to write unit tests for binary tools, e.g., llvm-objdump, llvm-nm, llvm-readelf, as YAML is easier to read and edit than raw assembly codes and pre-built binaries. More importantly, YAML keeps our tests code base maintainable. However, yaml2obj currently doesn’t support generating DWARF sections very well (we have to hardcode the Content field of DWARF sections and it is not intuitive). This project aims to add DWARF support for yaml2obj (ELF part), which will ease our pain crafting DWARF tests.</p>

<p>Pywikibot is a popular framework for writing MediaWiki bots. Thanks is an extension for MediaWiki wikis which is designed to allow users to send quick "thank you" messages to other users for edits or Flow comments. Pywikibot does not currently have support for Thanks, meaning that bots using Pywikibot cannot send thanks, use the log of thanks on a wiki, or compile statistics on thanks.</p> <p>This project proposes to implement Pywikibot support for Thanks by:</p> <ul> <li>Implementing functionality to send thanks for revisions and Flow posts.</li> <li>Using existing classes to do useful things with metadata related to thanking.</li> <li>Creating a script to compile statistics of frequent thankers on a particular wiki.</li> <li>Modifying the Thanks extension code where necessary to achieve proper integration.</li> </ul> <p>Also included in the proposal is at least one to-be-determined contribution to the PHP extension code not directly related to the new Pywikibot functionality.</p>

<p>This proposal is for adding MPI support to GeNN. GeNN is known as a GPU-enhanced Neuronal Network simulation environment based on code generation for Nvidia CUDA. However, the limitation of GeNN is that it can only support running on a single GPU or a single shared-memory machine. This proposal is to plan for expanding GeNN to multiple machine clusters. MPI is common message passing interface and infrastructure to communicate across multiple hosts and it is natural to expand GeNN with MPI interface to achieve parallel execution on multiple hosts. The key point of this project is to balance GeNN computation simulations across MPI hierarchy between hosts and block/thread on individual GPU. Furthermore, This proposal shows potential tuning directions basing on MPI-CUDA hierarchy. To bridge the gap between the destination and implementation, this proposal also describes feasible stages for the MPI-GeNN project and narrates the candidate’s motivation, background and progressive approach. Curriculum vitae is attached to the last pages for reference. The candidate is welcome to any questions, comments or suggestions through any of the contacts, such as email, telephone, and skype.</p>

This project aims to bring GraalVM native-image support to JabRef, starting with JabKit and its core dependency JabLib, and then extending to JabGui, JabLS, and JabSrv based on feasibility. Currently, JabKit is distributed using JPackage and JBang, which leads to relatively slow startup time for a CLI tool. Native-image can compile Java applications into standalone executables with faster startup, but applying it to a large modular project like JabRef is challenging, especially due to runtime issues. Based on preliminary experiments, the main difficulty is not compilation but runtime compatibility. Dependencies such as Lucene, PDFBox, and JGit can compile successfully but fail at runtime due to dynamic class loading, reflection, or native library requirements. This project follows an incremental approach. First, it establishes a minimal native-image build and testing setup. Then, it enables a subset of JabKit functionality and gradually expands support by resolving dependency issues. Finally, it investigates feasibility for JabGui, JabLS, and JabSrv. Expected deliverables include a working JabKit native executable, feasibility results for other components, and documentation on dependency compatibility and native-image configuration.

Scaladex, the central index for open-source Scala libraries, currently does not have dedicated support for Scala compiler plugins—special artifacts used to extend or modify compiler behavior. These plugins are vital tools in the Scala ecosystem but are difficult to discover due to lack of indexing and classification. This project proposes adding full support for Scala compiler plugins in Scaladex. The implementation includes extending the binary version parser to recognize plugin naming conventions, adding a new platform type (CompilerPlugin), and integrating plugin-specific metadata into the indexing pipeline. The user interface will be updated to allow filtering and discovery of compiler plugins, and best practices for plugin authors will be documented. The key deliverables of this project include: Parsing and indexing improvements to recognize compiler plugin artifacts. UI enhancements for discoverability, including tags and platform filters. Updated documentation and contribution guidelines for plugin maintainers. A technical blog post summarizing design decisions, edge cases handled, and outcomes. By implementing these features, this project will significantly improve the visibility, discoverability, and usability of compiler plugins in the Scala community.

Fablo is a tool mostly used for local development and in CI. Is starts a Hyperledger Fabric network from a single configuration file, and supports various features that makes the development easier (REST API, network snapshots, advanced topology configuration, hooks, etc). Currently it supports Hyperledger Fabric in versions since 1.3 to 2.5. With the new upcoming release of Hyperledger Fabric (version 3): - We want Fablo to support Hyperledger Fabric v3, along with BFT consensus - We want to drop support for Hyperledger Fabric v1.3 and v1.4. - Optionally, we want to approach support for Fablo on ARM architecture (Apple M; running ARM Docker images for Fabric). Mentee will work with Bash scripts that are used for calling Fabric, TypeScript code for validation and normalization of config, and template engine to generate parametrized configs. Also mentee will be responsible for creating automated tests (both TS unit tests and e2e tests in Bash), covering implemented features, and updating Fablo documentation.

The goal of this project is to enable support for the High-Level Shading Language (HLSL) in clangd, allowing shader developers to benefit from modern language-server features such as code completion, diagnostics, semantic highlighting, and symbol navigation. Although HLSL is largely based on the C++11 standard and can already be parsed by Clang, clangd’s support remains incomplete due to missing handling of HLSL-specific constructs, semantics, and resource types. Additionally, shader development introduces unique challenges, such as multiple entry points within a single file (e.g., vertex and pixel shaders), which are not fully addressed by clangd’s current architecture. The project will begin with an evaluation of clangd’s behavior on HLSL code to identify gaps, followed by the design of appropriate extensions. An RFC will be proposed to the LLVM community to validate the design and gather feedback. Based on this, the project will implement key improvements to clangd, focusing on built-in function completion, semantic analysis of shader constructs, improved diagnostics, and better handling of shader-specific configurations. The final deliverables include a documented analysis of current limitations, an RFC describing the proposed design, a structured set of implementation issues, and upstreamed improvements to clangd, along with test coverage and documentation.

GCC currently supports most OpenACC directives for GPU offloading, but several features remain unimplemented or incomplete. This project targets four concrete gaps in the OpenACC implementation within GCC: - init, shutdown, and set directives (OpenACC 2.5+): Implementing the directive-form equivalents of the already-available runtime API routines, following the pattern of the existing #pragma acc wait infrastructure. - bind clause: Extending full support to C, C++, and Fortran by mapping the clause to OpenMP declare target and declare variant directives at the middle-end level or implementing OpenACC specific code. - device_type clause: Filtering clauses in the GIMPLE IR linked list based on the target device type at compile time using the ACCEL_COMPILER variable. - cache directive: Moving beyond the current no-op behavior by emitting prefetch instructions and/or placing data in low-latency memory using existing GCC prefetch infrastructure and OpenMP memory traits for certain use cases. Additionally, once core tasks are complete, the project will survey newer OpenACC specification features, producing a structured list of unimplemented functionality with prioritized implementations and documentation to ease future contributions. Deliverables include upstream patches for each directive/clause with test suite additions for C, C++, and Fortran, and documentation updates to the relevant documentation files.

<p>Python is, originally, a specification for a programming language. This specification has been implemented differently in different implementations of the <a href="https://docs.python.org/3/reference/" target="_blank">language specification</a>.</p> <p>A small, and by no means exhaustive, list of some major python implementations is:</p> <ul> <li><a href="https://www.python.org/" target="_blank">CPython</a>: The reference implementation</li> <li><a href="http://www.jython.org/" target="_blank">Jython</a>: Python implemented in Java</li> <li><a href="http://pythonnet.sourceforge.net/" target="_blank">Python for .NET</a>: CPython implementation that enables .NET library usage</li> <li><a href="http://ironpython.net/" target="_blank">IronPython</a>: Python implemented in .NET</li> <li><a href="http://pypy.org/" target="_blank">PyPy</a>: Python implemented completely in Python</li> <li><a href="https://bitbucket.org/stackless-dev/stackless/wiki/Home" target="_blank">Stackless</a>: Replaces the dependency for the C call stack with it's own stack</li> </ul> <p>The project intends to add support for latest CPython versions (3.4, 3.5, and 3.6) and latest PyPy version (5.3) to the GRPC Python library as well as pave way for supporting other Python variants down the line.</p>

The Mifos community has grown significantly over the years, along with the increasing number of projects and discussions happening across its platforms. Newcomers, as well as contributors unfamiliar with specific parts of the ecosystem, often struggle to navigate and understand the breadth of information shared. While the general Slack channels host a wealth of discussions, support is inconsistent and depends on the availability and responsiveness of community members. Similarly, valuable insights are often scattered across community blogs, mailing lists, and Jira tickets, making it challenging to locate relevant information quickly. To address these challenges, this project proposes the development of an AI-powered chatbot that leverages messages from Slack channels, posts from community blogs, updates from Jira, and other conversational and announcement platforms used by the Mifos Initiative. The chatbot will be capable of answering queries related to project updates, community decisions, usage guidance, and more—based on real-time information and past conversations. The core system will utilize a Retrieval-Augmented Generation (RAG) pipeline to dynamically pull relevant data from these sources and serve accurate responses to user questions. The system will also evaluate different vector stores and embedding strategies to optimize retrieval from unstructured conversational data. By the end of the project, the Mifos Initiative will have an intelligent AI assistant that significantly improves community support, provides instant clarity on ongoing discussions, and makes the ecosystem more approachable for contributors at all levels.