Explore Projects

This project focuses on bridging the Seldon C++ engine with Python using Pybind11, enabling seamless interoperability between the two languages for Seldon. It involves creating Python bindings to expose the functionality of the C++ engine to Python to facilitate the integration of simulations with post-processing and visualisation tools in the Python ecosystem. Afterward, ensuring the integration is correctly configured by conducting comprehensive testing to validate its functionality using pytest. To facilitate broader adoption across diverse communities, our plan is to package the bindings into a format installable via pip for streamlined distribution and usage. We will utilise Python wheels to create the package, ensuring compatibility across various platforms. Additionally, we'll employ cibuildwheel to enhance compatibility and streamline the build process. The primary objective is to make the robust capabilities of the Seldon engine accessible to Python users through efficient bindings and packaging. Our goal is to empower Python users with the robust capabilities of the Seldon engine, revolutionising the field of Opinion Dynamics.

<p>The AeroGear UnifiedPush Server sends native push messages to different mobile operating systems, such as Android, iOS and others. It has already developed good logical structures for sending of push notifications using JMS. Moreover, its "sender" module is mainly constructed of different message queues and their producers and consumers. On the other hand, the server DB is currently based on MySQL/PostgreSQL and each data entry lies in one DB scheme. We need the process for sending of push notifications and the evaluation of message metrics to be as fast as possible and as scalable as possible. Therefore, with an increase of our data problems can be caused by slow writes/reads to DB and not scalable enough message queue usage. The idea of the project is to try to overcome these obstacles and rebuild some modules of the system in the way that they perform well even if the data volume they are operating over increases. For that two different approaches can be taken. To speed up the DB access a new distributed, scalable, big data store HBase can be integrated into the project. For more scalable processing of the data, Apache Kafka can be used instead of JMS.</p>

This project aims to overcome the limitations of the current Build Script system by allowing multiple, well-organised build scripts, that are optional and run only when required. This approach will require less auditing, will enhance the build transparency and reduce the compile-time overhead. Build scripts in Rust facilitate compiling and linking 3rd party code, such as existing C/C++ libraries, before building a package. They are immensely important for interoperability since it prevents replacing/rewriting the already existing tools that are well-optimized for their tasks. However, the current build system has certain limitations. Only one build script is allowed per package, and it must be run before building the package, often causing unnecessary computation (e.g., during unit tests). Single Large script needs extra auditing, increase compile-time, and reduce transparency for third-party build tools, especially while passing parameters. They also cannot run unit tests within themselves. This project aims to overcome the above limitations by allowing multiple, well-organized build scripts that can be run directly from the Cargo.toml. These scripts are optional and run only when required, avoiding unnecessary expensive logic. With this, only the shared build scripts will need auditing. This approach enhances build transparency, reduces compile-time overhead, and even enables unit testing of build scripts if they are treated as a dedicated package.

The Rust compiler is notorious for needing to be faster at its job. Enormous effort has been put into solving this problem, but there is still room for improvement. This project aims to implement a new register allocator for the Cranelift backend whose focus will be on optimizing the speed of compilation rather than optimizing the program's runtime performance. The ultimate aim is to make the Rust compiler faster.

<p>The Chapel compiler optionally can produce LLVM IR and use LLVM optimizations with –llvm. Going forward, Chapel will use LLVM more and more because the compiler can effectively communicate more important details to the optimization passes. This task is to improve the quality of the LLVM IR, the testing of Chapel with LLVM, and the performance of the Chapel compiler in –llvm mode.</p>

This medium-sized project aims to improve pattern matching support in gccrs, the GCC frontend for Rust, by implementing compilation for the currently unsupported patterns (StructPattern, SlicePattern, RestPattern, etc.). The successful implementation of these features will bring gccrs a step closer to becoming a production-ready alternative Rust compiler, while providing valuable experience in compiler frontend development.

<p>Chapel is a programming language that wants to make the development of parallel applications easier. This project wants to extend the Chapel runtime with the support to stack traces when an unrecoverable error is encountered. A stack trace is a list of functions in the call stack at the moment of the error: this can immensely help developers during the debugging phase since it permits to see where, in the source code, the error is generated.</p>

LPython is still in its pre-alpha stage of development. When it becomes functional, LPython aims to be an ahead-of-time (AOT) compiler for Python that can compile binaries and execute code interactively at blazing fast speed. At present, the frontend of the LPython compiler is very limited (and slow too). My project aims to improve the frontend by developing the tokenizer and the parser from scratch. For the tokenizer, we will be using re2c and GNU Bison for the parser generator.

<p>Parsing current strace output is not an ideal solution, because:</p> <ul> <li>this is excessively difficult: the output is intended to humans, not robots;</li> <li>because of the way the syscall info is printed, particularly, by printf'ing it with all of the braces and commas by hand in every syscall parser, the output can contain inaccuracies, making the task of parsing even more difficult. </li> </ul> <p>A more correct way would be for parsers to store parsed data in memory in a more abstract representation, which then could be used by various outputting engines, for example, a JSON engine or an engine for the traditional strace output.</p>

Pallene is a statically typed companion language to Lua, designed to write performance sensitive part of it. Pallene has a very similar syntax as Lua, sharing its runtime as well. Pallene is Ahead-of-Time compiled language, compiling into C before getting compiled into a Lua module. As the situation stands for Lua stack trace, it does not store any line number information for any native C call, which Pallene eventually ends up using. There are also missing traces when a Pallene function calls another Pallene function as the call is in Pallene environment and completely oblivious to Lua. This proposal aims to fix that issue in Pallene, improving its overall debugging support.

<p>Fault injection is something that could be really usefull in many ways for developpers and testers. It could be used in test suites context to assert that an application behave correctly on errors. By errors we don't necessarely mean that something went wrong, in fact an asynchroneous application may want to have some tests for the code path when getting an EAGAIN value on a read for example. Normally the tester have to setup a complex environment to create artificial errors or simply assert that the code works the way it should. strace would definetly get rid of that easily. On another hand if we considere the high proportion of bugs found by fuzzers nowadays it's pretty clear that tampering with the underneath of applications, that is with syscalls, looks promising.</p>

<p>I’d like to add a lambda support in Immediate Pad. There are roughly 2 tasks:</p> <p> Task1. Compile lambda expression locally using Roslyn API along with the current context of debuggee  Task2. Add a new wire protocol command type for bytecode for the lambda expression. The debugger agent registers the bytecode in Mono Runtime and sends back its handle to the debugger.</p> <p>We have to compile the body of a lambda expression and resolve some difficulties such as variable references and substitutions in the body. Then, compiled bytecode should be sent to the debugger agent with the protocol for lambda. A challenging thing of this project would be injecting new bytecode which either refer or change variables in the debuggee’s context.</p>

The std::arch in the standard library provides architecture-specific intrinsic functions, which directly map to a single machine instruction. The ultimate goal is to inline stdarch into rustc completely and archive the stdarch repository making stdarch tests reliable and maintainable inside rustc infrastructure. Which we will achieve by incrementally investigating the CI test suite of stdarch and port as much of it into rust-lang/rust. The clear set of deliverables for this project are Map stdarch CI to rustc, land x.py steps for verify + stdarch tests, enable core_arch (plain then assert_instr on Linux), port intrinsic-test in phases (host, then cross if feasible), minimal stdarch-gen checks, wire CI, document, final report.

<p>Both Link Time Optimization (LTO) and C++20 Modules will benefit from a closer interaction between build system and compiler. LTO benefits from parallelizing the LTO step by spawning separate compilations and Modules can discover new dependencies during compilation. Both of these task are traditionally under control of a build system.</p> <p>Currently, GCC's LTO can use GNUMake's jobserver protocol to control its direct spawning subjobs. C++20 modules can make use of a proposed protocol[*], or use pre-scanning. This project aims to unify these approaches providing (a) client/server librar{y,ies} to manage communication (b) extend the proposed protocol to cover LTO requirements (c) provide a sample implementation for GCC/GNUmake.</p> <p>[*] <a href="https://wg21.link/p1184" target="_blank">https://wg21.link/p1184</a></p>

<p>Panda3D is a mature 3D rendering engine both in age and functionality, addressing the need for the rapid prototyping of games while still providing stability for large projects. As a result of this maturity, however, Panda has been slow to take advantage of newer platforms and devices, with no support for iOS and only experimental support for Android. Adding support for iOS will make the engine much more appealing to new developers, while also creating the opportunity to update more antiquated areas of the engine. Many of these features will aid in future work on Android support as well.</p> <p>Goals for this project include:</p> <ul> <li>iOS build support using CMake</li> <li>A flexible system that allows Panda to either run in a dedicated app or run alongside other UIKit elements</li> <li>Improved multi-touch support</li> <li>Documentation and unit testing</li> </ul>

<p>Pallene is a statically typed, ahead-of-time-compiled sister language to Lua, with a focus on performance. Programmers can use Pallene instead of C modules and LuaJIT to improve and gain a predictable run-time performance. Pallene achieves this by translating a statically typed compilation unit into a C source file, which is implicitly compiled in the background.</p> <p>However, there are situations where removal of type annotations are useful.</p> <ul> <li>The main premise of Pallene is that it is compatible with Lua. This compatibility is defined as removing type annotations from a Pallene program results in transforming it into a Lua program. A Pallene to Lua translator will allow us to check whether this property is still valid. </li> <li>Provides greater portability, interoperability and integration with existing Lua codebase and tools.</li> <li>The Pallene developers could check if the unit tests are obeying the "gradual guarantee".</li> <li>In the benchmarks that do not use LuaJIT features, we could generate the Lua version of the code from the Pallene version.</li> </ul> <p>With the help of the Pallene to Lua translator, users can remove Pallene type annotations to generate plain Lua.</p>

<p>Mission Support Collaboration(mscolab) is a part of the MSS application which allows real-time collaboration and editing of flight paths of a project. However, there are some key features which are currently missing from mscolab. I propose to work on the following features and improvements to mscolab:</p> <h3>Local Flight Path Editing:</h3> <p>There are many instances where a user might want to test out his/her own changes to the flight path locally without changing the path on the server. Another scenario is that the user has a slow network connection at the flight campaign location which is a common problem. Both these situations require a method for the users to be able to make changes to the flight path locally and then be able to compare and merge it with the flight path on the server later.</p> <h3>Chat Service Improvements:</h3> <p>Improve the communication between users by adding features like - markdown support, ability to send images, searching through messages, ability to delete messages and replying to a specific message.</p> <h3>Admin Dashboard:</h3> <p>Develop an admin dashboard window to allow mscolab project admins to manage users efficiently, giving them options to add/modify/delete user permissions in bulk.</p>

My proposal aims to increase the level of context that Pwndbg provides when stepping through a binary by “annotating” the results of instructions. Alongside the disassembled machine instructions in the dashboard, there would be text to indicate the action that each instruction takes, such as moving values between CPU registers, writing data to memory, or doing a mathematical operation. We would resolve the concrete values that memory and CPU registers take on after each instruction, providing relevant information that the user would otherwise have to fish out manually using a GDB command that varies depending on the context. Pwndbg is starting to support this annotation feature for the x86 architecture. My project would add these annotations to other architectures supported by Pwndbg, namely 32-bit Arm, 64-bit Arm, RISC-V, and MIPS. This not only aids in debugging and reverse engineering, as you would gain much-needed context as to the results of instructions, but there is also an educational benefit in that you can visually see what each instruction is doing while stepping through a binary. We would additionally create annotations for future instructions in the disassembly view using emulation. By combining the Unicorn Engine, a CPU emulator framework, with the Capstone Engine, a disassembly framework, we can provide the user with insight into the next handful of instructions, providing more context and increasing debugging efficiency. Deliverable - A series of pull requests which add annotations for instructions for Arm, AArch64, RISC-V, and MIPS inside the “disassembly” view of the Pwndbg dashboard - A rewrite of the parent class API to make adding annotations to new architectures more simple - Add the ability for the recursive printing of pointers inside the annotations to provide enhanced information on pointers inside heap memory, such as internal heap manager metadata - Documentation and tests to aid future contributors and reduce chance of regressions

Teachers cannot assign, collect, or grade App Inventor projects through their LMS. They share project links manually, collect screenshots, and enter grades by hand. This project builds a Google Classroom integration so teachers can create assignments linked to template projects, students can submit completed projects to Classroom, and teachers can return grades without leaving their normal workflow. The backend introduces an LmsService interface so that adding Canvas or Moodle support later requires only a new provider class. Deliverables are tiered: minimum (OAuth2 plus course listing plus assignment creation), target (full create-distribute-submit lifecycle with error handling), and stretch (GWT UI plus grade passback plus integration tests).

This GSoC proposal aims to create an Assets Library for MIT App Inventor, addressing the challenge of managing assets (images and sounds) across multiple projects. The solution involves developing a responsive Designer panel, distinct from the AssetListBox, to upload, organize, and import assets. I’ll leverage the UserFileData structure for user-specific storage, integrate with Google Cloud Storage (GCS), and refactor existing UploadServlet logic for robust validation. Deliverables include a drag-and-drop UI, folder-based organization, batch import functionality, and UX enhancements like search and error handling. This 175-hour project, spanning June 2 to August 25, 2025, will enhance workflow efficiency for educators, students, and developers, aligning with App Inventor’s mission to simplify app creation.

This project in Lpython and LPython is a Python compiler. It is in heavy development, currently in pre-alpha stage. Some of the goals of LPython, my project will add three features in compiler.

<p>GCC alone is unable to compile a single large file in parallel, causing parallelization bottlenecks in some projects such as GCC itself. Here we propose a fix for this issue by parallelizing the GIMPLE part of the compilation using threads.</p>

<p>Make <code>gccrs</code> usable under the cargo build system in order to bridge the gap between <code>rustc</code> and <code>gccrs</code>. The project aims to create a base upon which to expand, in order for <code>gccrs</code> to become a more viable alternative to <code>rustc</code></p>