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.
Providing excellent tooling for Swift often involves operating on Swift syntax trees directly. The swift-syntax library serves this purpose by providing a Swift representation of syntax trees, along with facilities to parse and generate Swift code. To make code generation especially convenient, the library includes a Domain-Specific Language (DSL) for building syntax trees that, however, currently relies on external tooling to generate a large part of its own definitions. To test the DSL on a non-trivial codebase and to make it production-ready, we will rewrite the syntax builder in itself, generating its sources using its own DSL and thereby bootstrapping its implementation.
<p>This project will focus on a current problem in the Hardware community: The speed of RTL Simulations. These types of simulations are a necessary step in any hardware design. It is intrinsically a hard problem, and even commercial simulators run slow compared to the real hardware, which can be several orders of magnitude faster. On the open-source side, Verilator is one of the most famous players and offers a competitive simulation speed time compared to the closed-source ones. We will base our work on this tool. This project will consider that modern processors rely on Network-On-Chip (NoC) to communicate several cores in the same chip. The idea would be to use this hardware partition into consideration and make a stand-alone simulation per core and communicate through OpenMPI. This could potentially enable the simulation of a 1000-core processor, something currently unmanageable.</p>
Considering the performance, instead of reparsing the entire file every time, we could speed up the parsing procedure with the information provided by old AST, which is an ability provided by the old parser. In the old implementation, this feature was only applied to CodeBlockList and MemberDeclList. In the new implementation, It would be nice to apply node reusing to other syntax collections e.g. exprList, functionParameterList, etc. Also, It would be good to allow more fine-grained reusable nodes via expanding the definition of nodeAtCursorCanBeReused to allow reusing nodes such as FunctionDeclSyntax where only identifier is changed.
<p>QEMU is a free and open virtual machine software that can be useful for the OpenRISC community for testing and teaching software development on the platform.</p> <p>The idea is to provide full support of the OpenRISC platform with some software already (the Linux operating system) and other devices, all running efficiently on the host system.</p> <p>Alongside with the software, documentation should be provided, to guide the community and (especially) beginners on how to use the platform to development and testing.</p>
This project aims to enhance the OpenPiton+Ariane architecture to progress toward RISC-V RVA23 profile compliance. The primary focus will be implementing the Svnapot extension, which allows for Naturally Aligned Power-Of-Two regions in memory to improve TLB efficiency. I will modify the CVA6 Memory Management Unit (MMU), specifically the Page Table Walker (PTW) and Translation Lookaside Buffer (TLB), to support this extension. As stretch goals, I plan to implement additional supervisor extensions required for RVA23 compliance, such as Svpbmt (Page-Based Memory Types) and Svadu (Hardware Updating of A/D Bits). The project will include comprehensive testing and documentation, ensuring all implementations conform to RISC-V specifications while integrating seamlessly with the existing architecture.
<p>Debuggers are essential tools in aiding developers to do their work more efficiently. They are inherently tied to the target operating system, and therefore require platform-specific work in order to deliver functional parity between different platforms. Swift is a multi-platform programming language, and having a good debugging experience in all platforms is beneficial for the language. With that in mind, I propose to improve LLDB’s support on the Linux operating system by: fixing Swift type metadata parsing for ELF objects; unifying queries of dynamic type resolution under the RemoteMirrors API; and, finally, enabling tests which currently do not run on Linux, or are marked as expected to fail.</p>
TinyParrot is a BlackParrot RISC-V multi-core variant that aims to be small enough to fit onto educational FPGA development boards like the Pynq Z2. In order to get there, the TinyParrot variant needs to optimize and constrain itself in order to meet the physical device constraints (such as LUTs, BRAMs, and flip-flops) provided by development boards like the Pynq Z2 FPGA development board. This project will implement size optimizations that ultimately decrease the amount of resources required by TinyParrot, enabling TinyParrot to fit on the Pynq Z2. At a high level, this will be accomplished by first parameterizing the FMUL/FDIV instructions as part of an MFD parameterization effort. Then, hardware primitives will be re-mapping using the BaseJump STL library in order to standardize and optimize the existing RTL. The ultimate goal of these optimization efforts is to implement TinyParrot on the Pynq Z2.
<p>Building hardware requires access to costly tools and hardware, furthermore complexity in hardware design remains a deterrent force. FPGAs in the cloud solved the high upfront cost of the hardware, and some aspects of tool availability, but not the complexity and scale yet. Moreover, reuse of the already existing IPs is extremely difficult.</p> <p>For this Summer of Code project, an extension to the FPGA-Webserver project (<a href="https://github.com/alessandrocomodi/fpga-webserver" target="_blank">https://github.com/alessandrocomodi/fpga-webserver</a>) is proposed to provide an end-to-end solution for accelerating web applications and developing hardware using cloud FPGAs.</p> <p>A ready-to-use environment like this could potentially accelerate compute-intensive tasks in web applications and could appear in online HW design tools as backend.</p>
<p>Update riscv-sodor currently implemented in Chisel2 to Chisel3 along with that also update Privilege ISA Spec it complies to from 1.7 to 1.10 and then later port sodor to an FPGA using an AXI wrapper eventually allowing others to use Sodor (a librecore) in their projects. Updating sodor an educational microarchitecture to latest tools and specifications would help teach/convey latest standards.</p>
<p>Block-Based Circuit Design is a solution to counter the complexity of Circuit Design. We aim to develop and deploy a Block-Based TL-Verilog solution for developers and new entrants to the sphere. Powered by Blockly from Google, it will deliver a simple, concise, and intuitive gateway to Circuit Design.</p>
Configurable linter for Concerto (used in the Accord Project) validates syntax and the JSON AST of Concerto models against a curated set of Spectral rules. Rules enforce best practices : such as naming conventions (e.g., camelCase properties, PascalCase declarations) and feature restrictions (e.g., reserved keywords), while remaining fully configurable per project. Lint results surface in the concerto CLI. The tool is designed to be lightweight and performant; it integrates seamlessly with existing concerto tooling and supports extensible rulesets packaged as npm modules. Overall, the project advances Concerto by reducing manual checks, improving model quality, and providing practical rules informed by real user needs, backed by comprehensive testing and easy configuration.
<p>The project aims at developing a feature wherein the template developers can sign the templates (to authenticate the source) they developed. The contracts derived from the templates can be then signed by the parties involved in the agreement (to authenticate the signatories).</p>
My proposal aims to make Sootty, a CLI waveform viewer, a more utilitarian and intuitive tool to use, by adding features that I believe it would benefit from. I propose to implement new features like flags for saving previously used queries and multiple trigger expressions to help make the tool more user friendly.
Template Playground is a web-based tool that allows users to create, edit, and test smart legal contract templates. Currently, the application relies on Ant Design for its UI components, which increases bundle size, and limits customization. This project aims to migrate the entire UI from Ant Design to Tailwind CSS, making the platform more lightweight, efficient, and maintainable. Along with the migration, I propose a new layout design. This new design will be introduced to enhance usability, responsiveness, and overall user experience. The goal is to create a modern, intuitive, and visually appealing interface that improves workflow efficiency for users interacting with contract templates.
This project enhances the console output experience for the Swift Testing framework by designing and implementing a new, two-phase console reporter. This architecture provides both real-time feedback during test execution (the "Live Phase") and concludes with a comprehensive, structured report (the "Summary Phase"). The primary focus during this GSoC project was the implementation of the Summary Phase, which includes: - A rich Hierarchical Summary that visualizes the relationship between test suites and individual tests. - A dedicated Detailed Failure Report providing clear, actionable information for debugging. - Intelligent cross-platform support, with an ASCII fallback for terminals with limited Unicode compatibility. Architecturally, the reporter was refactored to consume a serialization-based event stream (ABI.EncodedEvent). This was a significant technical pivot that decouples the reporter from the test runner, preparing it for future integration into an out-of-process "harness". The final deliverable is a robust, experimental implementation available behind a feature flag, with a clear roadmap for completing the Live Phase post-GSoC.
Since CVA6/Ariane is highly modular by design, it is relatively easy to develop and integrate multiple L1 caches. Additionally, because CVA6/Ariane is open source, users can develop L1 caches customized for their needs. The primary technological feature of HPDC is its L1 Dcache, which supports Multi-Requester, Multi-Issue, and Out-of-Order operations. This capability is especially valuable for HPC systems striving for high memory throughput. However, HPDC is still under development, and various functional enhancements are being implemented or planned to make it more useful for HPC systems by providing a variety of functions for diverse cores. In this year's GSoC, the objective is to first expand the functionality of the L1 cache for the CVA6/Ariane core, and then to make it scalable to accommodate many cores, laying the groundwork for making HPDC an even more significant entity for HPC systems. By exploring the appropriate scale and structure, it's possible to enhance HPDC's functions to be used as an instruction cache with scalability in mind. Furthermore, by connecting with OpenPiton, it becomes extremely easy to scale to large systems with many cores. This aligns with the goals of the GSoC project.
This project aims to shrink BlackParrot multicore to have a minimal variant called TinyParrot multicore. The main goal of this project is to get very low resource ASIC tapeouts. The deliverables of this project are: **Provide Minimal ISA support: This will be done by parameterizing the FPU logic (all the FP pipes, register file, and bypass paths). **Shrink the size of caches: The cache size will be reduced to 1kb of data. **Logic saving optimizations: The optimizations are planned to be done through Yosys. Yosys supports optimization passes and runs them while synthesis.
This project aims to improve the way Scautable handles CSV files by making structured data parsing in Scala more robust, flexible, and user-friendly — especially for data exploration and quick scripting tasks. Key problems being addressed include poor handling of row/column mismatches, limited support for malformed or missing headers and lack of custom delimiter options. Inspired by the usability of Pandas, this proposal introduces enhancements such as configurable error-handling modes (e.g., skip or autofill bad lines), support for automatic or custom headers, smarter handling of duplicate or malformed columns, and flexible delimiter parsing. For large files, methods to access specific columns will be distributed across implicit classes to avoid JVM method count limitations, improving scalability. Additionally, clear error messages and diagnostics will guide users through common issues and edge cases. By addressing these aspects, the project will significantly improve Scautable’s reliability and make it a more powerful tool for developers working with structured data in Scala.
<p>The Tainted Checker Overhaul aims to be an extension of the Tainted Checker Framework, extending the concept of tainted data and upgrading its functionalities. Often, programs need to deal with input values outside of their domain, which can sometimes allow the entry of invalidated and corrupt data. Such corrupt inputs can cause numerous errors and, therefore, must be handled carefully. This Overhaul aims to deal with such dilemmas and aid the programmer in a significant way.</p>
<p>Traditionally, java programs use null to represent the absence of value. Java 8 introduced Optional class, a container that contains a reference to T (non null) or is empty. Using Optional Class solves the problem of null pointer exceptions but creates new problems that may crash your program. The goal of this project is to create a new type system that warns programmers who have misused Optional and expose latent errors, which would ultimately lead to proper use of Optional class.</p>
<p>Checker framework is a great lightweight tool which could easily type check code having a dependency on a library if the library has already been annotated. Google Gson is a widely used library written in java to transform the Java objects to JSON (JavaScript Object Notation) and vice versa. This library has a total of 143 directories and 255 files out of which 208 are java files. This project could be an overall evaluation of the type-checkers on real code and can also help detect bugs or suggest improvements to the library being annotated. The main goal of the project</p> <ol> <li>Adding annotations to the Google Gson library for Nullness, Index and Interning checker.</li> <li>Adding missing annotations in JDK and reporting bugs if found any in the process.</li> </ol>
<p>Checker Framework provides a collection of type systems to prevent bugs on Java programs at development time. Although a type system might be useful to prevent certain types of errors, it requires the effort to write all the types, which might be an annoying task for developers. In order to tackle such problem, developers might use a type inference tool to write the types for a program. Particularly, to determine what type should be written for a procedure’s formal parameter, a type inference tool must examine the type of the argument at every call to that procedure. Thus, the type inference process requires a whole-program analysis. In conclusion, the main goal of this project is to create a single type inference tool that will work for any type system available in Checker Framework (e.g., Nullness and Interning Checker).</p>
JSON Schema validation errors are often cryptic and difficult to understand, making debugging frustrating for developers and end users. This project aims to develop a JavaScript library that transforms raw JSON Schema validation outputs into clear, concise, and human-friendly error messages. It will maintain compatibility with the standard format while improving error readability, supporting multiple languages, and allowing customization. By the end of the project, developers using standard-compliant JSON Schema validators will have access to a high-quality, user-centric Better JSON Schema errors—enhancing the developer experience and making debugging more intuitive for end users.
<p>The Rails website and welcome page was redesigned. However, the current design of error pages doesn't follow the new style. The new styling can be made more consistent.</p> <p>Moreover, some pages display errors that require action from the user like when the migrations are pending. I would like to propose a mechanism for users to act on the errors straight from the error page. A new module for ActionableError can be designed and integrated with the new error pages to give greater control to the user. It should also be extendable by other gems for them to customize their own course of actions when an actionable error is hit.</p> <p>A Web Console integration will also be done to update the console style to fit the look and feel of the new redesign.</p> <p>In addition to these ideas, we can also attempt a series of opinionated rails generators that will create a suite of default error pages (404 and 500s for example), based on the new styling rules, or from a set of styles obtained from the application's implemented stylesheets.</p>