Fetching the latest programs, projects, and workspace data.
Find open source projects actively accepting contributors. Search repositories, filter by program milestones, difficulty tags, or tech stack.
Use our Orbit AI Matcher to find out! Get instant matching scores based on your developer skills, preferred frameworks, and contribution experience.
Convert your selected open-source project into a winning GSoC, LFX, or Outreachy application using Proposal Studio.
The primary objective of this project is to enhance the user experience of MIT App Inventor by providing users with information about the availability of components on iOS or Android platforms. To achieve this, proposed changes will be made to the Designer editor code to enable users to determine whether a component is accessible on a particular platform or both. The coverage.json file will be utilized to extract information about the availability of components, which will be represented by iOS or Android icons displayed on the palette items and a text displaying if the component is exclusive to any of the platforms(Android or iOS) on palette Help Popup dialog box. Furthermore, a dialog box will inform users about unsupported components when they connect their devices through the AI companion. The proposed modifications will empower users to make informed decisions when creating their applications, resulting in higher-quality apps that cater to user needs and expectations.
The main point is to create an abstract class in both Swift and Java, shared among all AI components, which will contain all the necessary functions for such components. This abstract class will then be inherited by the ImageClassifier and AudioClassifier classes, allowing them to perform correct classification, especially thanks to asynchronous operations, utilizing AsyncTask in Java and GCD in Swift, respectively.
Functional programming is a programming paradigm where programs are constructed by composing pure functions, avoiding shared state, mutable data, and side effects. Many operators in functional programming are commonly used to make code more concise, and less complex. This proposal hopes to expand the operations in the block editor of MIT App Inventor by implementing new blocks commonly found in functional programming, such as map, reduce, fold, etc.
<p>Right now, MIT App Inventor is short of components that allow to visualize data using charts. This project aims to implement entirely new components that allow displaying the data visually, such as through pie charts, bar charts, scatter charts or radar charts, while also providing various customization functionality to allow the user to adapt the components to their needs.</p>
This project aims to introduce a scalable and maintainable internationalization (i18n) system for applications built using MIT App Inventor. Currently, App Inventor does not provide a structured approach for handling multi-language support, making it difficult for developers to create globally accessible apps. The proposed solution introduces a key-based translation system that decouples user-visible text from UI components. The system integrates across multiple layers of App Inventor, including the Designer, Blockly, runtime, and build system, enabling automatic translation handling in generated applications. Key features include: - Automatic detection of user-visible text from component properties and Blockly blocks - A centralized translation editor for managing multi-language content - Context-based key generation to ensure stability and avoid ambiguity - Runtime translation using JSON for flexibility during development (Companion) - Build-time generation of native Android/iOS resources for efficient production builds The system is designed to be fully backward compatible and supports progressive adoption, allowing existing projects to continue working while enabling developers to gradually migrate to the new translation model. Deliverables include: - A working runtime translation system for App Inventor apps - Integration with Blockly for key-based text handling - Designer-level synchronization and key management - Build-time resource generation for native localization - End-to-end tested implementation with documentation
<p>Modernising and modularising the App Inventor Projects View by introducing shortcuts for project actions and integrating markup UI declarations with standardised design systems</p>
<p>This document proposes an addition to Boost <code>C++</code> Libraries — <code>Static_views</code> library. The library focuses on working with compile-time (i.e. <code>constexpr</code>) homogeneous data. Its applications range from converting bitmaps from 8-bit to 24-bit representations to implementing efficient enumeration to string conversions and custom error categories.</p>
The aim of this project is to lift one of the last high priority instruction sets to RzIL, namely the RISC-V instruction set. This instruction set, along with the MIPS instruction set, is one of the two remaining high-priority instruction sets that still don’t have a RzIL lifter. This project aims to rectify that. RzIL is a common intermediate language that serves as an executable description of several real-world instruction sets and bytecode formats. This has multiple benefits, like enabling a human reverse-engineering professional to audit and read code written in a machine language which the professional isn’t familiar with and - more importantly - enabling the execution of a code format even if no "native" interpreter or VM or emulator is available for it, by first compiling it to RzIL (a per-architecture work) and then executing it on the RzIL VM (which is write-once).
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.
RocksDB is an embeddable persistent key-value store for fast storage. MariaDB has integrated this engine into the database since version 10.2.5. However, the ported engine, MariaRocks, is currently lagging behind the main branch of RocksDB. The goal of this project is to update MariaRocks to the latest release of RocksDB by incorporating changes from Facebook’s MyRocks. This update will include API changes, bug fixes, and improvements.
The proposal outlines a project to improve the debug information handling in Rizin, an open-source reverse engineering framework. The project aims to enhance the parsing support for DWARF and PDB formats, enable loading of DWARF information from separate files and debuginfod, and integrate source line and types/variables information with analysis, printing, and breakpoint commands in debug mode. The end goal is to provide a smoother debugging experience for reverse engineers using Rizin.
<p>This project intends to improve the overall functionality of <a href="https://poez.io/en/" target="_blank">Poezio</a> by implementing “Infinite scrolling using Message Archive Management (<a href="https://xmpp.org/extensions/xep-0313.html" target="_blank">MAM</a>)” and adding important features linked with it for general improvement. Some of the features planned for this project along with infinite scrolling of messages are:</p> <ul> <li>Implementation of scrollback command</li> <li>Work on lastlog plugin</li> </ul>
<p>Function is considered to be the basic code construction block. However, Radare2 is not good at detecting anything beyond basic functions. Things like structures, OS specific data types, function names are mostly unrecognized by Radare2 (with exceptions). Adding support for this very feature will make Radare typical for static analysis for malware , and reverse engineering. In general it will attract more users and build concrete alternative to other commercial Software reverse engineering tools like HexRays’s IDA pro, Hopper.</p>
<p>First project is about creating unique indexes for blob and varchar in Aria, MyISAM storage engine. It will provide user a direct interface for creating index for blobs , varchars .By this way user can also have unique constraint for blobs and very long strings.Second project will optimize it further by reducing time complexity of equal query from O(log b n) to O(1). By doing this we can also reduce time complexity of distinct query for any storage engine from O(n*log(n)) to O(n).So innodb will also benefit from this project because it internally uses maria for finding distinct blob.</p>
This project aims to improve the thread safety of the Rizin reverse engineering framework by eliminating global static variables and encapsulating shared state within dedicated context structures. The goal is to prepare Rizin for safe, reliable multi-threaded and asynchronous operation, enabling seamless future integrations with tools like Cutter Desktop. Key areas of focus include refactoring utility modules (RzUtil), core components (RzCore, AGraph), IO plugins, libmagic integration, the console interface (RzCons), the Terminal UI, and SDB. By the end of the project, Rizin will be structurally equipped for multi-threaded workloads, enhancing its performance, stability, and extensibility for the reverse engineering and security communities.
<p>This document proposes an addition to <code>Boost C++ Libraries</code> -- a <em>compile-time</em> hash table. There are multiple good implementations of unordered associate containers (e.g. <code>std::unordered_map</code>, <code>Google</code>'s <code>sparsehash</code>). These implementations provide both lookup and insertion/deletion functionality. They are, however, not the perfect fit for the case when the contents of the container are fixed upon construction or even known at compile time. <code>std::vector</code> vs. <code>std::array</code> is a good analogy here. We propose a <code>static_map</code> -- an associate container with focus on <code>constexpr</code> usage.</p>
This project enhances MariaDB’s SQL engine by introducing native bitwise operations for binary and bit types and implementing the JSON MEMBER OF operator. Currently, bitwise operations are limited to 64-bit integers, restricting flexibility for large binary data, and JSON membership queries require complex workarounds. The project will extend the Type_handler framework and Item expression system to support byte-wise binary operations and integrate MEMBER OF into the SQL parser and execution engine. Deliverables include a new Func_handler_bit_bin for binary operations, full implementation of Item_func_json_member_of, parser extensions, and comprehensive MTR test coverage. These improvements will increase SQL expressiveness, performance, and compatibility with modern database workloads.
<p>In the history of Computer Science, real numbers representation and data structures do not have a simple solution, numerical errors can be carried from one operation to the next and after several steps, the error may significantly increase. Also, irrational numbers representation as the number π or e^π are not handled by the native number data types and causing limitations when calculations are based on those numbers. The problem can be summarized as: there are an infinite amount of different numbers and a finite representation system. Even if there are some existing solutions, there is not a modern C++ open source library to attack the problem and Boost C++ could be the appropriated place.</p> <p>Following the Real number representation introduced in chapter 2 of Oliver Aberth. Computable Calculus. Academic Press, 2001. I propose to implement a data type to represent Real numbers and to define the operators (+, -, *, /, !=, <, >, =). This data type attacks the introduced problem and allows to represent some calculable real numbers as π</p>
<p>Rizin currently relies upon manually writing code for adding a new CPU or an IO port. This implementation is unfit as the vast and growing ecology of hardware components such as CPUs and SoCs regularly implement a part of architecture with custom instructions, registers, and address configurations with trivial differences, making it infeasible to maintain all of them inside Rizin.</p> <p>Providing a level of abstraction in handling this entropy in embedded systems, by supporting editable CPU and platform profiles is the goal of this project. This will also make adding and maintaining these ports easier with less interaction with Rizin’s core. This project also aims to add more flexibility in having a way of importing existing hardware data description documents so that reverse engineering on particular chipsets is easier. This will also help us to memory map the peripheral accesses and registers to provide a better reverse engineering experience. This, in turn, could also be extended to benefit Rizin in terms of compatibility and the end users in terms of user experience.</p>
GNU Radio’s current CI system relies on software-based testing, which cannot capture real-world SDR behavior and hardware-specific issues that arise under actual RF conditions. This limits the reliability of validating signal processing blocks before deployment. This project proposes a Hardware-in-the-Loop (HIL) Continuous Integration framework using CortexLab to extend GNU Radio’s CI pipeline with automated hardware validation. The system detects hardware-relevant changes in pull requests, maps modified blocks to predefined test configurations via a registry, and generates experiment artifacts (tx.py, rx.py, analyze.py, scenario.yaml) dynamically. To ensure efficient resource usage, the pipeline introduces a maintainer-controlled HIL execution step, allowing prioritization of critical PRs instead of fully automatic triggering. After reserving SDR nodes, a lightweight validation test is executed to verify hardware readiness before running full experiments. Each experiment is executed iteratively across multiple input configurations, and results are analyzed using block-specific metrics such as frequency error, amplitude deviation, SNR, BER, and stability. The system produces structured outputs that determine a final PASS/FAIL decision integrated into the CI workflow. Robust error handling mechanisms are included to manage failures in node allocation, execution, and result analysis.
The purpose of this project is to extract BTF information for eBPF maps, process it in a human-readable manner, and improve decoding for the bpf() syscall's map manipulation sub-calls.
<p>This project covers the development of a Tango Control’s Device Server(s) for the purpose of reading and configuring biometric signal sensors.</p> <ul> <li>Phase I of the project consists of selecting which biometrics are to be measured. Eg: Pulsioximetry, Accelerometry, etc. The next step would be to survey the commercial sensors available, and select one, or more, according to criteria like: Budget, Programming libraries available, Documentation, Signal Preprocessing capability, etc. Multi-sensor devices should be preferred over several single-sensor devices.</li> <li>Phase II consists of writing the Device Servers for the chosen devices, in Python, with abstraction and decoupling in mind. It would also entail looking into the possibility of interfacing these device servers to the existing Habitat Monitor and Health Monitor GUI.</li> <li>Phase III covers improving the signal quality and, if time allows, performing some signal analysis. This phase is slightly flexible in that if sufficient preprocessing on the signals is done by the chosen devices themselves, more work can be done on the GUI and interfacing.</li> </ul> <p>The project is part of the current studies on the simulation of an Astronaut’s Health Monitor system.</p>