Explore Projects

Details xDS 官方说明 https://www.envoyproxy.io/docs/envoy/latest/api-docs/xds_protocol ● Listener Discovery Service (LDS): Returns Listener resources. Used basically as a convenient root for the gRPC client's configuration. Points to the RouteConfiguration. ● Route Discovery Service (RDS): Returns RouteConfiguration resources. Provides data used to populate the gRPC service config. Points to the Cluster. ● Cluster Discovery Service (CDS): Returns Cluster resources. Configures things like load balancing policy and load reporting. Points to the ClusterLoadAssignment. ● Endpoint Discovery Service (EDS): Returns ClusterLoadAssignment resources. Configures the set of endpoints (backend servers) to load balance across and may tell the client to drop requests. 协议基础：protobuf + gRPC 实现方案 1：使用 io.grpc 的依赖手动创建原生 gRPC 服务 实现方案 2：使用 Dubbo 3.0 的新协议 测试环境控制平面 mock Envoy 提供的 Java 实例控制平面 https://github.com/envoyproxy/java-control-plane Java 版协议支持 Envoy 提供的 Java 版控制平面 API https://search.maven.org/search?q=g:io.envoyproxy.controlplane

This project proposes integrating NVIDIA's Thrust parallel algorithms library with HPX to enable GPU acceleration while maintaining consistency with HPX's existing parallel algorithm interfaces. The solution involves creating a specialized Thrust executor that extends HPX's CUDA executor capabilities, implementing automatic memory management for data transfers between host and device, and developing a dispatching mechanism that selects the appropriate backend (CPU or GPU) based on execution policies. Key technical components include a version-aware API layer to handle Thrust compatibility, exception handling that bridges Thrust/CUDA errors with HPX's error system, and template-based algorithm overloads that transparently route calls to Thrust implementations when GPU execution is requested. The implementation will proceed through four phases: establishing core infrastructure (executor, memory management), integrating fundamental algorithms (transform, reduce, sort), adding HPX execution policy support, and concluding with comprehensive testing and optimization. The resulting system will allow developers to write single code paths that automatically leverage GPU acceleration through Thrust when available, all while maintaining HPX's asynchronous execution model through future-based interfaces.

HALO (Hierarchical Abstraction for Longform Optimization) is an MIT-licensed Python package for efficient large-scale video content analysis, installable via pip install halo-video. The system implements a hierarchical processing architecture that reduces computational complexity to O(n log n) using dynamic content-based segmentation. Key components include: a multi-modal fusion pipeline integrating visual (768-dimensional) and transcript (1024-dimensional) embeddings; a three-tier caching system utilizing in-memory hash tables, disk-based serialization, and compressed vector storage; and an optimization layer for API request batching. The architecture maintains content coherence through a sliding context window with 30% chunk overlap. Performance metrics show 93% reduced processing time, 85% lower computational costs, and 98% fewer API calls compared to baseline approaches. HALO supports cross-platform operation (Linux, macOS, Windows), implements error handling with exponential backoff, and provides standardized interfaces for integration with existing ML pipelines. The package processes video content with bounded memory requirements regardless of input length.

RNTuple is ROOT's next-generation columnar data format for High Energy Physics. Its storage layer is decoupled from its format layer, enabling new backends. This project implements a S3 storage backend for RNTuple, allowing datasets to be written to and read from S3-compatible object stores such as CERN's Ceph S3 and AWS S3. The approach introduces a new S3 locator type with two addressing modes: packed pages with multi-range GET for servers that support it, and one-page-per-object with concurrent GETs for those that do not. A JSON anchor at the base URL provides the entry point with a templated URL scheme for forward compatibility. The implementation adds RPageSinkS3 and RPageSourceS3 classes using the existing RCurlConnection as the transport layer, extended with PUT support and concurrent I/O via curl multi handles. Deliverables include the complete write path (Phase 1-2), complete read path with optimized cluster loading (Phase 3-4), RCurlConnection extensions for PUT and concurrent I/O, and a comprehensive test suite covering wire-level tests, locator round-trips, integration tests against MinIO and CERN Ceph S3, and performance benchmarks.

<p>SUSI.AI CMS is the web client for SUSI.AI ( An intelligent open source personal assistant) which showcases the skills that SUSI.AI has to offer, along with multiple other functionalities. The aim of the project is to :</p> <ul> <li>Implement five star skill rating system.</li> <li>Implement skill feedback system.</li> <li>Implement feature to report a skill.</li> <li>Add functionality to directly test the skill examples on SUSI Web-chat.</li> <li>Feature to upload/get avatar of a user.</li> <li>Add functionalities to the SUSI Admin Panel.</li> <li>Display skills based on standard metrics on the home screen.</li> <li>Display various statistics like skill usage and skill ratings on the skill details screen. </li> <li>Revamp the entire UI/UX of the Skills CMS web client.</li> <li>Improve code quality and refactor the components.</li> <li>Improve existing project documentation.</li> </ul> <p>Link - <a href="https://skills.susi.ai" target="_blank">https://skills.susi.ai</a></p>

<p>ABioTrans is a bio-statistical/informatics tool, developed in R for gene expression analysis. The tool allows the user to directly read RNA-Seq data files deposited in the Gene Expression Omnibus or GEO database. It provides easy options for performing very commonly used statistical techniques, namely, Pearson and Spearman rank correlations, Principal Component Analysis (PCA), k-means and hierarchical clustering, Shannon entropy, Noise (square of the coefficient of variation), differential expression (DE) analysis, and gene ontology classifications</p> <p>This project aims to develop the 2nd version of ABioTrans. ABioTrans version-2 will be web-based and will provide extensive analysis options to the gene expression analysis results such as pathway enrichment analysis, gene function, t-SNE, Protein Protein Interaction, SOM , SVM as well as publication-ready visualization options including network visualization using Cytoscape.JS As the current version of Abiotrans is not online, it gets very difficult and time consuming process for the biologist who want to perform few analysis. As it's a very time consuming &amp; tedious process. So, taking it online will solve a huge problem.</p>

<p>The aim is to enable multiple web-apps generations by implementing <strong> queue data structure</strong> for the series of requests triggered by users from the open-event platform. This would prevent loss of requests from the user and enable the creation of event for every request and provide a web-service for direct generation of event sites from the orga-server(eventyay). In the present implementation, we have transformed websites generated through open-event-webapp to be <strong>Progressive Web App(PWA)</strong>, due to which service workers are already enabled. Therefore we can now move to further enhancement like push-notifications of bookmarked events by any user, also we need to improve the user interface for the <strong>dark theme</strong> enabled recently to project. The present testing suite requires some more tests for the functionalities like direct linking of tracks and rooms so the aim is to write <strong>mocha unit tests</strong> with selenium webdriver for the recently added features and the proposed ones. The travis build for the selenium tests run for around 20 minutes, which is quite large so the aim is to <strong>parallelize the build</strong> so that multiple builds can be performed at the same time and runtime can be decreased significantly.</p>

Developing a scalable and reproducible research pipeline within SeqTrainer for bacterial DNA sequence modelling and annotation using SBOL-based datasets. The project addresses a key challenge in synthetic biology: the lack of accessible, machine learning–ready datasets and standardized workflows for genomic modelling. The primary focus is on E. coli and Gram-negative bacteria, with applications in promoter classification and sequence annotation. The work involves reproducing and benchmarking existing CNN-based baselines, followed by integrating and evaluating foundation models such as DNABERT2 and Evo 2 within structured experiment pipelines. Experiments explore challenges including overfitting and class imbalance through methods such as weighted loss functions, undersampling, learning-rate tuning, and early stopping. A major component of the project is the development of a modular and reproducible experiment framework within SeqTrainer, including configuration-driven workflows, reproducible dataset splitting, evaluation utilities, metric logging, and improved SBOL-to-dataset conversion pipelines with validation and provenance tracking. The final outcome aims to transform SeqTrainer into a more experiment-friendly framework for genomic ML research, enabling accessible, extensible, and reproducible machine learning workflows for synthetic biology researchers.

<p>INCF is using EEG event-related potential signal processing and machine learning methods for building assistive systems for motor impaired people. Their system collects human brain data of audio/video stimulated subject and uses customized classifiers to provide a feedback leading to an action like turning on a TV, opening a window etc. The team had previously developed a client-server architecture to execute some signal processing methods onto data stored on a distributed file system.</p> <p>This project aims at building an easy to use graphical interface that can assist designing the workflow of these methods. This web-based toolkit will also assist the configuration of the parameters that control individual signal processing routines thus making it easy to design complicated signal flows and execute them. The entire workflow will be exportable and reusable as a JSON file. The GUI will use the Java implementation in a way that the user will be free to implement his own methods and use them in the workflow designer. The GUI will host each signal processing method as a block and will allow users to draw data channels between them. This can then be directly be exported as a job to Spark.</p>

The goal of this project is to create a developer-friendly Postman Workspace for interacting with the Gemini API. This workspace will serve as a central hub for exploring, integrating, and troubleshooting the Gemini API, providing developers with pre-built collections, test scripts, and documentation to streamline their workflow and reduce the learning curve. The workspace will feature well-documented API requests for key Gemini functionalities like text generation, chat, image generation, and code generation. It will also include pre-configured environments for testing and production, secure management of API keys, and a GitHub Action for automated updates. The key deliverables for this project include: 1. A comprehensive Postman Workspace with collections for various Gemini API features. 2. Pre-configured environments for testing and production. 3. Integrated, self-contained documentation and tutorials. 4. Test scripts to validate API responses and handle edge cases. 5. Mock servers to simulate API responses during local development. 6. A GitHub Action to automate workspace updates based on API changes. This solution will simplify the process for developers, improve productivity, and ensure the Postman Workspace remains up-to-date and reliable.

This project focuses on improving the TaskWarrior Flutter mobile application by reducing technical debt, improving the Rust–Flutter integration, and expanding core TaskWarrior functionality on mobile platforms. The current codebase contains legacy synchronization components, incomplete Rust FFI features, and an unstructured project layout that makes maintenance and feature development difficult. The project will remove the deprecated CCSync synchronization layer and unify synchronization through the TaskChampion Rust backend. The tc_helper Rust library will be refactored to improve build configuration, modular structure, cross-compilation, and to expose missing task attributes to the Flutter application. The Flutter project will also be reorganized into clear modules separating legacy Taskwarrior 2.x code from the TaskChampion implementation. Additionally, a mobile reporting engine will be implemented to support Taskwarrior-style filtered reports and user-defined configurations. A GitHub Pages website with automated nightly build tracking will also be created, along with targeted UI and UX improvements based on community feedback. Deliverables include synchronization refactoring, Rust library improvements, Flutter project restructuring, a reporting engine, project website, and UI/UX enhancements.

<p>As of now Marble supports rendering of OpenStreetMap vector data for higher tile levels. In order to make the vector OSM theme complete and end - user ready, support for medium and lower tile levels must be added.</p> <p>For supporting low level rendering( levels 1, 3, 5, 7, 9), Marble should render using the Natural Earth vector dataset instead of the OSM vector dataset. The reason for this is that Natural Earth dataset has categorically arranged data which is required for step by step rendering of lower levels. Apart from this the rendered data should be styled so as to match the OSM theme and tiling support must be added on the server and client side.</p> <p>For the medium level tiles, rendering must be performed using the OSM dataset. OSM dataset gives us many small chunks and nodes for a particular geographic data item. These chunks and nodes need to be filtered and reduced to a manageable size for each specific level so as to get optimal performance and less screen clutter.</p> <p>Rendering of higher level tiles can be improved by adding rendering support for roof-types and textures tags of buildings.</p>

<p>Systems Biology Markup Language (SBML) is a standard format for the representation and exchange of biological models between computers. The information in an SBML model file is organized as a list of components encapsulated within the model (e.g. compartments, species, parameters, reactions, etc.). However, SBML is difficult to read, comprehend and interpret by humans directly, and tools are required to provide an abstraction layer to interact with SBML objects and the relationships between them. The objective of the project SBML4Humans is to address this issue by providing an interactive and reactive report for SBML models which will allow humans (experts as well as beginners) to easily comprehend the content of a model. The key features introduced in the interactive report are:</p> <p>i) interactive SBML report with navigation between SBML objects</p> <p>ii) search and filter functionality</p> <p>iii) web application with REST API</p> <p>iv) downloadable standalone reports</p> <p>v) support for hierarchical models</p> <p>vi) support for distributions and uncertainties</p> <p>vii) support for COMBINE archives</p> <p>Such an interactive report will thus significantly enhance the process of reading and exchanging SBML models.</p>

Being a privacy enthusiast and an end user, the idea proposed by LEAP group for implementing Client-side Tracking-, Malware and Ad-Blocker really caught my attention. In this digital era, most important thing whenever surfing the internet; is protecting yourself and your loved ones from the malwares, trackers and adwares. Implementing features like filtering DNS requests and blocking the particulars would help in maintaining privacy and protection. In this project, I would be working on the client-side approach for creating the blocker. The blocker would work across different platforms including- Desktop, Android, Linux and Mac. For developing the UI Components of the blocker, I will go with QT5 as the LEAP projects use the same. And for the Android implementation, I will be using Java and Android-specific XML. Firstly, in the main desktop client- the features of blockers would be included in the settings menu along with a simple feature switch. Pre-configured blocking lists would be shipped with each release. This would help us in filtering out the DNS requests and blocking the IPs in our target blocking list. I will package the entire solution in a self-contained Go Library that will be able to read packages from a given file descriptor and work accordingly. Future Scope includes implementation in iOS environment and implementing update mechanism.

This project aims to enhance the SANTE search API of DBpedia, a popular knowledge graph that provides structured data extracted from Wikipedia. The SANTE search API is an important component of DBpedia that enables users to search and retrieve information from the knowledge graph using natural language queries. However, like any search engine, the performance of the API can be improved by optimising the underlying technology, data quality, and user experience. Therefore, this project will focus on enhancing the search API by incorporating various techniques such as data quality improvement, indexing optimisation, query parsing enhancement, incorporation of external knowledge sources, relevance feedback, and the use of machine learning techniques. These enhancements will improve the accuracy, efficiency, and usability of the SANTE search API, making it a more valuable tool for knowledge discovery and information retrieval. There are several knowledge bases currently published in RDF format and exploring this information is still challenging for non-RDF neither SPARQL users. DBpedia-Search aims at facilitating information navigation, exploration, and seeking through DBpedia Knowledge base with natural language queries. This GSoC project consists of enhancing DBpedia Search APIs by including tests, benchmarks, and additional functionalities.

Wikimedia Commons is an Android app that enables users to upload and view pictures from their Android phone/tablet on the Commons server. This project aims to fix uploads related issues and deal with location metadata loss. I plan to solve each issue by following various hints provided by the mentors and figuring out the potential points of failure in each of them. Deliverables: Report/Blog on findings, fix bugs, write/modify corresponding unit tests Issue #5196: Picture location is sometimes lost despite being present in EXIF Possible Implementation Strategy: Based on the hints provided, a number of scenarios can be analysed and the location loss may be fixed depending on the case. Issue #5128: Upload often fails, especially when uploading 5 or more pictures over a slow Internet connection. Possible Implementation Strategy: As described in the issue, the network parameters need to be experimented upon, and a retry loop may be incorporated. Issue #5136 (if time allows): Retried uploads stuck in queued state Possible Implementation Strategy: As observed by some users, the uploading process gets resumed when a new upload is performed. This means that the STATE_QUEUED needs to be updated appropriately to the same state as that of a new upload once the internet connectivity resumes/the paused uploads are started again.

<p>Git has historically had many components implemented in the form of shell scripts. This was less than ideal for several reasons:</p> <ul> <li>Portability: Non-POSIX systems like Windows don’t play nice with shell script commands like grep, cd and printf, to name a few, and these commands have to be reimplemented for the system. There are also POSIX to Windows path conversion issues.</li> <li>No direct access to plumbing: Shell commands do not have direct access to the low level Git API, and a separate shell is spawned to just to carry out their operations.</li> <li>Performance: Shell scripts tend to create a lot of child processes which slows down the functioning of these commands, especially with large repositories.</li> </ul> <p>The goal of this project is to complete the conversion of the remaining parts of <code>git submodule</code> to C, namely, the <code>add</code> and <code>update</code> commands. If possible, I intend to even get rid of the shell script called <code>git-submodule.sh</code> entirely, which currently calls <code>submodule--helper</code> to perform most of the business logic, and instead make <code>submodule</code> a proper builtin in pure C.</p>

The goal of the project is to develop reusable building blocks for visual exploration of Internet data. The building blocks will be developed in the ObservableHQ platform, which uses the popular visualization library D3.js. The building blocks will be open-source code, published as templates in the ObservableHQ platform. Any user would be able to fork/copy a template and plug their own data, and/or modify it according to their needs. Since the code will be in D3.js, the building blocks can be re-usable by any javascript component, not only in ObservableHQ. The targeted users mainly are Internet researchers and network. There exist various types of Internet data, mainly, tabular data (e.g., ASN or latency value), timeseries (e.g., AS hegemony per day), graphs (e.g., routing graph), paths (e.g., traceroutes, BGP paths). We will create at least one building block that can visualize each type of data. Different types of data need different types of visualizations. We will consider a range of visualizations, such as, sankey diagrams (very useful to visualize relations, paths, etc. in Internet data), graphs, geo-maps, distribution plots (e.g., histograms, violin plots), dendrograms, heatmaps.

Open Source tools, such as those developed by SAT, have been widely used for a variety of applications by academics and independent users. The tools benefit users a lot and make their work easier, more efficient, and less stressful, but most of them need lengthy setups and installations, which are not very user-friendly. This GSoC project attempts to integrate tools like SATIE and LivePose into a bespoke WebUI and make them accessible. The UI will be responsible for software configuration, deploying an audio synthesizer on the back-end, etc. The WebUI will be capable of deploying the tools (start/stop LivePose and SATIE, control Jack Audio parameters, and request reboot/service restart) and basically remotely launching (and possibly integrating and mapping) SAT tools in embedded systems based on the Raspberry Pi generic computer running Linux. Any program or product's goal is to provide users with a rich and interactive experience; similarly, our WebUI will serve as an entry point to those tools with simple customizations that will make users' life much easier. Deliverables: 1. Create the Server ( Embedded system ) backend with the tools set up and operational. 2. Create a backend for the WebUI. 3. Connect both the backends with a suitable bridge. 4. Develop the Frontend UI for launching and configuring the tools.

1. Understanding the Flow and Discussion: Make a clear understanding of the flow of data between the mobile and the server, Including how the app loads the data. In the process of doing so, it will be much more clear and more precise to figure out ways for implementing a fast offline experience. 2. Implementing the offline save mechanism: With proper knowledge about the exact workflow how the data flow is, the first step I think of storing the data for the already scanned and opened products. This in turn will facilitate the users to look up the already scanned products without the need for an Internet connection. 3. Offline Edit Mode: After being done with the above two works, the 3rd and most important phase will be Carried out. A clean and working mechanism to store the changes locally will be Discussed with the mentors and start the work on the same to store the changes and sync those changes when online and delete the offline changes so as to keep the app as lightweight as possible. 4. Preloading Data: If time persists and the above work is done(which I am sure will be done), add a mechanism to preload the data as cache (as step 2) so as to let the users use the app for popular food items in their country out of the box 5. Testing: After the whole work is done, a clean throughout the testing of the implemented features is to be carried out so as to ensure a steady smooth experience.

The 2010s decade marked a beginning for widespread compiler testing with the release of programs like Csmith, a C program generator that since its release has found and reported over 400 compiler bugs. However, as highlighted by a recent study, the research on compiler testing has critically neglected the front-end component of compilers, leaving unfound bugs in the type checking procedure of compilers. More specifically, this could lead to the compilers of statically-typed languages, which utilize features such as type inference, both accepting erroneous programs and rejecting correct ones. Hephaestus is a tool designed to test the compilers of three languages, namely Java, Kotlin, and Groovy. It has already successfully detected over 150 bugs in the compilers of these languages. I propose a way to extend Hephaestus for it to be able to successfully test and detect bugs in the compiler of TypeScript. This can be a great contribution to the user-base and community of TypeScript, a language that has risen in popularity and usage in the past years. Hephaestus detects bugs by: 1. generating semantically-valid programs that (a) utilize parametric polymorphism and (b) are abstract 2. generating these programs in an intermediate representation (IR), an OOP language that supports parametric polymorphism and type inference 3. using translators to convert the abstract IR program to the desired language.

Prerequisites: Ubuntu and ROS 2 development environment, no need for specialized hardware. Necessary programming skills: Familiarity with C/C++/Python, CMake, ABI/API. Difficulty level: Medium. Potential mentors: Tomoya Fujita Expected size: 100 hours to 150 hours. Expected outcome: A ROS 2 command line interface ros2cli with doctor sub-command and ros2_documentation. Detailed description: Currently, the ROS 2 doctor subcommand, ros2 doctor, is lacking a lot of useful information, such as ROS environment variables, RMW-specific environment variables, and configuration and service information (number of endpoints, QoS compatibility status, etc). This information is really important and useful for debugging issues with ROS 2, and would greatly improve our ability to support issues reported by our user community. In other words, adding this new information to our existing ROS 2 Doctor command would accelerate community communication and make bug reports much more precise! Aligned with ros2cli development, this project also targets the implementation of improved documentation on how to create an issue report with a new issue template. Reference pull requests: Add default github issue templates, add: get clients, servers info

One of the key use cases of blockchain integration is asset bridging: in essence, "locking" an asset (typically, a native coin or token) in a smart contract on its authoritative ledger and making available corresponding, newly minted (wrapped/shadow/...) assets on another. By now, bridging is supported by quite mature solutions in the cryptoworld; however, the same is not true for "consortial" distributed ledger technologies. At the same time, such functionality can be expected to become an important requirement in the not too distant future - Analysing the implementation approaches of standard "token models" (ERC20, ERC-721, ... - as far as this has been already done) in native Fabric chaincode and creating conceptual mappings between standard Ethereum token types and Fabric-native assets (including, but not limited to, the different authentication and authorization approaches). - Creating a brief review of the bridging approaches and mature technologies widely used in the cryptoworld. - Performing a requirement analysis for bridging assets from Fabric to Ethereum-based networks (and back), taking into account that the parties performing the bridging have to be explicitly given permission to do so by an authority and may be subject to regulatory requirements. - Based on the available open-source components, designing and prototyping a Fabric-Ethereum bridge fulfilling the requirements As the proposed project bridges multiple fields, creating a centralized solution.