Explore Projects

<p>So as to handle huge volumes of data generated due to distributed and scalable nature of PCP, Redis an in-memory NoSQL data cache is being used in PCP for search and serving time series performance data. Since PCP metadata and data keys are distributed across potentially many Redis servers, Redis nodes need to communicate with one another for data access/transfer. Communication between Redis nodes (Redis clients with the Redis servers) is carried out by protocol called RESP (REdis Serialization Protocol). As Redis protocol (RESP) and the pmproxy'd PCP protocol can co-exist, the main goal of this project is extending pmproxy to support RESP such that an arbitrary Redis client can access the distributed key store using the direct key-to-server mapping mechanism used by the existing PCP time series code. Sub-goals include integrating libuv library with pmproxy. libuv is a multi-platform support library with a focus on asynchronous I/O.</p>

This project will evolve the Audit module into a comprehensive security and compliance tool by implementing three new, non-blocking auditing categories: a . Read Auditing: Logs who viewed patient records using a non-blocking, asynchronous mechanism with Spring AOP interception, a Caffeine cache for 5-minute event deduplication, and a background thread for batched database inserts. b. Security Events: Tracks critical user actions like successful/failed logins, account lockouts, logouts, session timeouts, and password resets by hooking into core OpenMRS authentication and service methods. c. Administrative Events: Logs changes to system configuration, such as global property modifications, module installations/uninstalls, and user/role management. Deliverables: The final product will include the three new log types stored in dedicated database tables (audit_read_log, audit_security_event, audit_admin_event), a complete REST API for querying and filtering these logs, a log export feature (CSV, Excel, PDF), and a Legacy UI viewer page.

<p>My plan is to add a new backend by enabling WebGPU in OpenCV.js. There have been many sophisticated GPU backends including Cuda,OpenCL,Vulkan and Halide, these GPU backends can provide reference for porting some kernels' shader code of OpenCV GPU backend to WebGPU. The concepts of pipeline and buffer of OpenCV Vulkan backend have many functions that are similar to WebGPU API, so I will try to write a library to enable emscripten to convert the used Vulkan API to WebGPU API. Specifically, the mapping from OpenCV Vulkan backend to OpenCV.js using WebGPU can be roughly divided into three parts. First of all, mapping Vulkan buffer to WebGPU buffer to access the storage of WebGPU.Secondly, mapping Vulkan API calls for pipeline and command buffer to WebGPU API. Thirdly I’ll reuse Vulkan's shaders. It’s feasible to reuse Vulkan’s shader directly in Chrome. Another possible approach is using SPIRV-Cross to convert SPIR-V in Vulkan shader to readable, usable and efficient GLSL/HLSL.</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.

<p>In this project we focus on package manager for Lua modules, LuaRocks. Our main goal is to increase quality of test suite, because it's implemented as a big shell script that only does black-box testing. So we write new test suite with Lua unit testing framework busted.This will allow us to extend the test suite by writing smarter tests that check its behavior, write white-box tests of the internals, and also port the test suite to other platforms. Next step is to improve code coverage, by adding white-box tests for parts that are hard-to reach via black-box testing. Make tests cross-platform could be a challenge for Windows operating system. At the end we integrated code coverage results, merging the Linux and Windows runs.</p>

<p>gopy is an excellent tool which generates (and compiles) a CPython extension module from a go package. And I hope more developers could make full use of gopy to migrate their go code into python code. To make gopy more advanced, It is necessary to provide APIs for various Python compiler versions, such as CPython 2/3 and PyPy. This can be improved with CFFI or ctypes. Moreover, many go’s implementations/features are not yet implemented in gopy. So we need to implement implementations such as slices, interfaces, and maps in the go.</p> <p>My goal is to update gopy by using CFFI to support Python3 and PyPy and write detailed documents.</p> <p>Github: <a href="https://github.com/go-python/gopy" target="_blank">https://github.com/go-python/gopy</a></p>

<p>The performance issue, or bundle time speed-up, is a common challenge for modern JavaScript/web bundler. As one of the most powerful module bundlers in recent year, Webpack team endeavors to enhance the bundling performance. In the latest version of Webpack 4, several improvements like new plugin system and parallelization with cache with UglifyJs have been implemented and accomplish a considerable performance enhancement. In this project, some cores and dependencies of Webpack are re-implemented in Rust, a low-level language, and WebAssembly binary is generated from them with the corresponding compilers. Some automation tools are used to help to convert existing JavaScript sources as well as future works to other languages. At the same time, backward compatibility of earlier Node.js versions will be maintained. It can be considered to be a significant performance enhancement with this project in the future Webpack release.</p>

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.

<p>AirSim is an open-source, cross-platform simulator for drones and cars, built on Unreal 3D Engine. It provides physically and visually realistic simulations with popular flight controllers such as PX4 using either Software-In-The-Loop (SITL) or Hardware-In-The-Loop (HITL). It is generally used for testing software &amp; for generating large amounts of visual data which is essential for tasks such as Deep Learning &amp; Reinforcement Learning for autonomous drones &amp; vehicles.</p> <p>Over the next few months, in Google Summer of Code, I will add support for Airsim simulator for Ardupilot’s SITL and increase the scope and applicability of Ardupilot in today's emerging fields of autonomous vehicles. This will involve creating the required backend for the communication between Airsim &amp; Ardupilot, implementing lock-step scheduling for accurate simulation and creating documentation, demo videos &amp; sample programs for the same.</p>

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.

<p><strong>Objective</strong> : This project will involve building a complete module for Drupal 8 site to make it a zero-knowledge system using front-end JS encryption so that the users can rely on the site when uploading sensitive files, including images on confidential posts, not having to worry about data being stolen in case the server gets compromised.<br> <strong>Project Introduction and why this project is important</strong> : The implementation of a zero knowledge system is very essential for the user as they would want to rely on the CMS that their data is not being stolen and they are not being spied upon. Using client side encryption, sensitive data is already being encrypted before being stored on the server.<br> In a confidential post/article sharing sensitive information, the embedded illustrative images and attached files might contain more detailed information than the plain-text article that only provide an overview to the actual in-depth data in the document. Hence, having only the fields encrypted is of no use if the images and other files related to that secret article are leaked by the attackers, possibly posing a higher threat than leak of regular article field text.</p>

<p>Currently, pgmpy deals with only discrete random variables. In many situations, some variables are best modeled as taking values in some continuous space. Examples include variables such as position, velocity etc.</p> <p>The first part of the project creates a module to represent nodes having a continuous domain representation. These nodes would be used in hybrid networks comprising both continuous as well as discrete random variables. The two important features in this part would be -</p> <ul> <li>Representation of User Defined Continuous Random Variables</li> <li>Methods to convert continuous distributions into discrete factors.</li> </ul> <p>The second part of the project will deal with Gaussian distributions. Gaussians are a particularly simple subclass of distributions that make very strong assumptions, such as the exponential decay of the distribution away from its mean, and the linearity of interactions between variables. Gaussians are a surprisingly good approximation for many real world distributions.</p> <p>There will be support for variables comprising the most popular forms of representation in Gaussian distributions -</p> <ul> <li>Linear Gaussian Distribution</li> <li>Joint Gaussian Distribution</li> <li>Canonical Forms</li> </ul>

OpenMRS has historically operated as a single-instance application, creating a "hard ceiling" for scaling and a single point of failure. As global healthcare networks grow, there is an urgent need for High Availability (HA). While foundational work on distributed caching and storage was introduced in version 2.8.x, several critical gaps remain: lack of distributed session management, race conditions during cluster startup, duplicate execution of scheduled tasks, and inconsistent search indexes across nodes. This project aims to complete the "Cluster-Ready" roadmap for OpenMRS 3.x. Drawing inspiration from proven architectures like Confluence Data Center, I will implement a Zero-Footprint, Multi-Replica framework. I hope to do this by Implementing a formal "Local Home vs. Shared Home" split to manage node-specific vs. cluster-wide data. I want to make use of distributed State Introducing Redis and MySQL-backed session management so users remain logged in even if routed to different replicas. Leveraging Infinispan to implement distributed task locking (preventing duplicate background jobs) and a "Cluster Safety" mechanism to detect and mitigate split-brain scenarios. Transitioning Hibernate Search to a shared OpenSearch/Elasticsearch backend to ensure search consistency across the entire cluster. Project Deliverables: A safe startup sequence for containerized environments (Kubernetes/Helm). Configuration-driven support for Redis (Redisson) and JDBC session persistence. A wrapper for the OpenMRS SchedulerService to ensure tasks run on exactly one node. Audit and migration of O3 modules (FHIR2, Webservices.rest) to the distributed cache manager. Application-level wiring for shared full-text search indexes. A robust integration testing framework using Testcontainers to validate cluster behavior in CI/CD.

Summary: The project aims to extend istSOS to support the dataArray extension, which is commonly used in SensorThings for managing Observation entities. Currently, istSOS lacks support for dataArray, limiting its compatibility with SensorThings. By incorporating dataArray support, istSOS will become more versatile and user-friendly, allowing for efficient retrieval and creation of Observation entities. This extension is expected to enhance istSOS's performance by reducing the size of requests and responses, ultimately improving the user experience. The project's expected outcome is the successful integration of dataArray support into istSOS.

The protocols supported by Transport Next Generation are limited to TCP and UDP. I will implement a new communicator plugin to transport data using QUIC. This adds more redundancy to the new communicators. I will conduct research into the QUIC protocol and keep in contact with my mentor and other GNUnet developers to create a detailed plan to build a QUIC plugin. I will develop a plugin that allows peers to connect over QUIC and continue supporting GNUnet by fixing bugs, writing documentation, and working on other plugins such as HTTPS.

JPEG XL is an image format that allows for lossy and lossless compression, and is generally better than JPEG at this. LibreOffice currently supports many image file formats, but JPEG XL is not one of them. This project would add such support. The potential for storage savings that support for this image format would bring will mean a better experience for experienced and newer LibreOffice users alike. In addition, web browsers are increasingly supporting JPEG XL (it is available in nightly Firefox builds), so this project will also help LibreOffice users by improving compatibility.

LPython is a Python compiler in heavy development. It is currently in the pre-alpha stage. The project includes discussing which modules will be needed for LPython (from a scientific computing perspective, in the beginning), creating a priority list, and then implementing each module properly. The aim of this project is to make LPython work for any Python code down the road. My prime focus during the project period would be on: - Implementing priority modules needed for Lpython - Creating extensive integration tests for respective functions in modules - Zero bugs - Fix the currently identified bugs - Make the documentation more user and developer-friendly

WasmEdge is a WebAssembly runtime that supports both interpreter and ahead-of-time modes. For proxy-wasm support, WasmEdge only provides the interpreter mode currently. Such as the other runtimes, WasmEdge should be able to support the AOT mode for better performance. In this mentorship, the mentees will help the WasmEdge project to complete the AOT mode in proxy-wasm proposal and write the docs for examples of running with proxy-wasm. - Expected Outcome: - Modify the Bazel file to include the LLVM dependency. - Modify the code to support running WASM in AOT mode. - Add the documentation of proxy-wasm in the WasmEdge docs repo.

The Integrating 5G NR module with ns-3-ai project aims to create a high-performance, zero-serialization bridge between the 5G-LENA NR MAC scheduler and Python ML frameworks using the ns-3-ai Message Interface, enabling richer observations, lower latency, and framework-independent ML integration beyond what the current OpenGym-based approach supports. While the NR scheduler is the target use case, the integration patterns, bindings, and agent framework built here serve as a reusable reference for any ns-3 module looking to adopt ML.