Explore Projects

pocketpy is a lightweight Python interpreter that can be embedded in C++ applications. Though pocketpy has provided low-level APIs for creating Python bindings, it requires a lot of boilerplate wrapper code to bind complex C++ classes. The community has long expected a high-level solution for creating bindings. pybind11 is a header-only library that exposes C++ types in Python and vice versa, which has been widely used to create Python bindings of existing C++ code. Inspired by pybind11, this project aims to implement a compatible binding solution for pocketpy. By utilizing the template metaprogramming technique in C++17, we can extract metadata from C++ classes and functions and generate wrapper code automatically. By the end of this summer, header files compatible with pybind11 will be implemented for pocketpy. Existing pybind11 users can seamlessly migrate their bindings into pocketpy. New users can also benefit from this high-level binding solution. Additionally, we will test and verify the deliverables of the project in Cave Engine, a real-world product built on top of standard pybind11 header files.

<p>My contributions majorly include the most crucial things for the <strong>CLI ( webpack-cli )</strong> like -</p> <p>allowing multiple types of same arguments e.g <strong>--stats (means stats: true)</strong> and <strong>--stats verbose (means stats: verbose)</strong>.</p> <p>Now webpack 5 provides API for CLI arguments so we will be taking arguments from the core itself.</p> <p>I Will add some negated boolean args like <strong>--no-hot</strong>, <strong>--no-stats</strong> and <strong>--no-colors</strong>.</p> <p>Writing unit tests and integration tests.</p> <p>Better Error handling when an invalid argument is passed.</p> <p>Added alias for version command <strong>(webpack -v )</strong> will be now supported.</p> <p>Also, support --version for external packages like <strong>webpack init --version</strong> will show the version of <strong>@webpack-cli/init</strong> as well.</p> <p>And many more general improvements.</p>

<p>Everyone accepts that strace is one the most useful program for developers. And to make the output more understandable, I want to improve the informativeness of syscalls. Well, it occurred to me that there are two main approaches:<br> 1) Improve the informativeness of the existing strace output<br> 2) Write the complementary static query tool<br> Let's see which one is more appropriate in the current state of affairs. Certainly, it seems like the first way is looking better, because just typing the following command<br> <code>$ strace %process_name% | asinfo</code><br> we will see the colorful and the informative output. However, parsing messages to make appearance more understandable is quite slow. Furthermore, an absence of the completed JSON output makes the task unsolvable optimally. In the second case, we do not care about these problems, just open one more terminal emulator and type the following command:<br> <code>$ asinfo [OPTIONS] write (just one example)</code><br> To sum up, the output is purposed for people and providing all information about syscall(syscall number, meaning of flags, etc) can significantly reduce the debug time.</p>

<p>Collision detection is essential in a game engine. It is the reason you go bonkers playing Flappy Bird. However, it would be difficult and expensive to represent each object using its exact geometry, so a better idea would be to put those objects in bounding volumes or CollisionSolids. These CollisionSolids are mathematically defined, so by using "some math", a collision system would be able to detect their intersections with each other.</p> <p>Currently, Panda3D is missing 3 collision tests: parabola into box, parabola into inverse sphere, box into capsule. Here are some use cases that we've probably seen before:</p> <p>1) An Angry Bird hitting a box (parabola into box)</p> <p>2) Protecting the audience from a football in a spherical stadium (parabola into inverse sphere)</p> <p>3) Some box object hitting a player (box into capsule)</p> <p>My first goal would be to add these collision tests.</p> <p>My second goal would be to add another CollisionSolid named CollisionHeightfield. The idea is that we can represent heightfields using a grayscale image, with lighter (taller) and darker (lower) pixels. We can use this concept to efficiently deal with collisions in uneven terrain.</p>

<p>A support for Lua-scriptable syscall tampering and filtering will be added. It will be possible to inspect syscall arguments (including structures/unions of arbitrary complexity, given that their definitions are provided), passed both by value and by pointer (and write modified values back in case of the latter) using LuaJIT's FFI library or a compatible one (there are currently <a href="https://github.com/jmckaskill/luaffi" target="_blank">a standalone implementation of FFI library abandoned since 2013</a> and <a href="https://github.com/facebook/luaffifb" target="_blank">its fork by Facebook</a>).</p> <p>It will also be possible to perform fault/success/signal injection.</p> <p>A pull-style C API, as <a href="http://luajit.org/ext_ffi_semantics.html#callback_performance" target="_blank">LuaJIT's FFI documentation suggests</a> for minimizing context switching between C and Lua and thus maximizing performance, will be implemented, but a helper library written in Lua will wrap it to provide a convenient push-style one.</p> <p>Of course, everything added will be documented and tested well.</p>

<p>The work proposed is to extend the already available, but limited SymEngine's Ruby interface. This project will greatly increase the computational capacities of the SymEngine ruby gem and add interfacing with other ruby gems for mathematical programming.</p> <p>Some of the proposed work are:</p> <ul> <li>Extending the C interface of SymEngine library.</li> <li>Wrapping up the C interface for Ruby using Ruby C API, including error handling.</li> <li>Designing the Ruby interface.</li> <li>Integrating IRuby with symengine gem for better printing and writing IRuby notebooks.</li> <li>Integrating the gem with existing gems like gmp, mpfr and mpc.</li> </ul> <p>At the end of the project, added features will include:</p> <ul> <li>Complex Numbers</li> <li>Floating Points</li> <li>Derivatives</li> <li>Substitutions</li> <li>Abs</li> <li>Series</li> <li>Polynomials</li> <li>Matrices</li> <li>Lambdify</li> <li>Parser</li> <li>LaTex printer</li> </ul>

In Rust, trait visibility currently implies implementability. If a trait is visible within a given scope, it can also be implemented in that same scope. However, we do not always want everyone to be able to implement it. To address this, the so-called “sealed trait” pattern is used, which allows a trait to be used while restricting its implementation. This is typically achieved by defining a public trait in a private module. Similarly, field visibility implies mutability. However, we do not always want readable fields to be writable as well. As a result, developers often use private fields together with public getter methods. The Restrictions RFC extends the Rust syntax to be able to explicitly restrict the implementability of traits and mutability of fields. For example, `pub(super) impl(self) trait Trait {}` means that `Trait` can be used within the parent module, while its implementation is restricted to the current module. `pub(super) struct Struct { pub mut(self) field: u8 }` means that `Struct.field` is readable within the parent module, while its mutation is restricted to the current module. These impl and mut restrictions are optional. Although the RFC was accepted in 2022, implementation efforts have stalled. Our goal for this project is to implement both impl and mut restrictions in the Rust compiler.

This project aims to develop a Cables.gl plugin that compiles Faust DSP code into a WASM AudioWorklet in real-time. The plugin’s features will be focused on composability, modular I/O, and integration with Cables.gl’s WebGL backend. This is in addition to foundational development goals such as creating a pleasant UX, robustness, and elegance. This plugin would allow users to create DSP programs without boilerplate and have those programs integrate on a signal flow level with Cables.gl WebGL functionality. There are currently no tools that allow for this to my knowledge, this plugin would offer a unique opportunity for creative coding in both the audio and visual realms including simultaneously live-coding audio and visuals on one platform. This signal flow level integration would allow for passing arbitrary data to both the WebGL and WebAudio portions of Cables.gl programs, as well as between these different portions. This includes using shader buffers as audio input, enabling GPGPU for massively parallel audio computations, or audio output as sources for visual effects such as vertex displacement, SDF distortion, and other audio-reactive visual effects. This is in addition to simpler modulation schemes such as passing MIDI or OSC to both audio and graphics portions of programs in parallel or doing the same with Javascript sequencing.

<p>Addin system of MonoDevelop/Xamarin Studio (<a href="http://www.monodevelop.com/download" target="_blank">http://www.monodevelop.com/download</a>) is very flexible and allow the developers to add or extend any feature in the IDE .CBinding addin allow the developers to use C/C++ for writing the solution. However, there are still many features that are missing, some of them are :-</p> <p>1) Ability of the CBinding to use compilers present on Windows (GCC/MSVC/MinGW32), this will also require support for CMake as that's the only project format CBinding currently has .</p> <p>2) Implement support and switching between various Toolchains available in CMake.</p> <p>3) Detect missing dependencies (libclang, CMake etc) and prompt the user to install them.</p> <p>4) Adding various refactoring features .</p> <p>There are many other things that can be done to make it even more better like improving project and file templates, improving code completion, adding a test suite etc . Since old "MD1" project system is no longer supported so it can also be removed.</p> <p>Main purpose of this proposal is to come up with an idea to implement some of these features and make changes to the existing ones.</p>

<p>Implementing an <strong>in-proxy authorization cache for envoy proxy using web assembly and proxy-WASM rust SDK</strong>. The cache will be in synchronization with 3scale Service Management API by periodically flushing the local cache snapshot and updating the local cache with a new cache snapshot provided by 3scale Service Management API. When a HTTP request is received by the proxy, it will do a look up in the cache to check whether a cache record exist for that particular request. If a record exist, then perform authorization logic based on that request <strong>(cache hit)</strong> . If a cache record does not exist<strong>(cache miss)</strong>, do a HTTP call to 3scale Service Management API to fetch relevant authorization data, add the records to the local cache for any subsequent requests and perform authorization based on the received data. For the project, <strong>a request intercepting HTTP filter</strong> and a <strong>singleton service that runs independently from request life cycle</strong> will be implemented using proxy-wasm-rust-sdk and will compile them as web assembly modules to extend envoy proxy with the HTTP filter and singleton. <strong>Web assembly modules allow us to extend envoy without building the envoy static binary using bazel build system.</strong></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.

The project aims to modernize and enhance the functionality and performance of DIPY (Diffusion Imaging in Python), a library for the analysis of diffusion magnetic resonance imaging (dMRI) data. The focus is on making key improvements across several areas to ensure the tool remains a cutting-edge resource for scientific visualization within the Python community. Here's a concise overview: Problem Addressed: The project addresses the need for improved code robustness, performance optimization, and user experience in DIPY. Specific challenges include the current lack of keyword-only arguments in functions, inefficient resource loading, bulky website management, and the need for better documentation and learning resources. Deliverable with approach: 1. Keyword-Only Arguments: Audit and refactor functions to use keyword-only arguments for clearer, more robust code. 2. Lazy Loading: Implement lazy loading to optimize performance by loading resources on-demand. 3. Website Management Improvement: Work with mentors to identify and implement enhancements for easier website management. 4. GitHub Actions Integration: Automate development workflows with GitHub Actions to improve efficiency and reduce errors. 5. Issues and Pull Requests Triage Automation: Enhance and automate the triage process for better project management. 6. Refactoring and Documentation: Refactor DIPY packages for improved readability and maintainability, and enhance docstrings for better documentation. 7. Tutorials Addition: Create new tutorials based on community feedback and identified learning gaps to facilitate user adoption and learning.

The Borg Collective offers essential Python-based backup tools like Borg, Borgmatic, and Vorta, which help users with secure, efficient, and reliable data backups. Vorta provides a user-friendly desktop GUI for Borg, while Borgmatic serves as a command-line interface for managing backups. This proposal outlines four projects designed to improve the functionality, security, and usability of both Vorta and Borgmatic. For the first project aims to add a new feature to the Vorta GUI that lets users change their repository passphrase. Changing a Borg repository passphrase is a feature that’s often requested but hasn’t been fully implemented yet within Vorta. This would make security management more accessible and eliminate the need for users to use Borg directly for such tasks. The second project aims to develop a custom file selector with PyQt6 FileDialog, which will handle multiple file and directory selections in one window. At the moment, Vorta has separate dialogs for selecting files and directories. This allows users to select both files and directories in a single window. The third project aims to introduce a much-needed improvement by adding a file selector dialog that allows users to pick files and directories to exclude directly through the UI. Right now, users who want to exclude certain files or directories from their backup have to manually type in paths or use patterns. This will allow users to eliminate the need for manual match expressions and reducing errors. These enhancements will make Vorta and user-friendly and feature-complete, ultimately improving the quality of backup process for users across different platforms.

This project aims to build ChatPharo, an intelligent, AI-powered assistant that integrates Large Language Models (LLMs) directly into the Pharo development environment. Despite Pharo’s strengths as a live programming platform, it currently lacks a native and user-friendly interface for interacting with LLMs to assist with code explanation, generation, documentation, and debugging. To address this, the project proposes a seamless, modular, and extensible system that connects Pharo with both online (OpenAI, DeepSeek) and offline (TinyLLaMA, Mistral-7B via Ollama) models. A multi-tab chat interface will allow users to manage multiple contextual conversations, while intelligent AI commands (e.g., /explain, /generate tests, /refactor) will directly support day-to-day coding workflows. Memory optimization techniques—including smart caching, chat pruning, and lazy model loading—will ensure smooth performance even in long sessions. A key innovation includes experimenting with pseudo-parallelism in Pharo’s single-threaded architecture by spawning secondary images to offload heavy LLM processing. This enables parallel task handling without compromising the responsiveness of the main Pharo image. By midterm, users will have access to a working chat UI, multi-LLM switching, and foundational coding actions. By the final evaluation, ChatPharo will evolve into a context-aware assistant capable of inline suggestions, AI-driven debugging, and scalable architecture for future extensions. Through full documentation, tutorials, and community engagement, this project will not only enhance developer productivity but also showcase Pharo as a capable, modern AI-enhanced development platform.

Currently, the properties for the screen1 form contains a number of project project-wide properties such as App Name, Theme and many more. We want these properties separated from the component and maintained on a separate dialog on the designer view.

App Inventor, a versatile tool for mobile app development, currently lacks consistent keyboard navigation and hotkey functionalities, presenting accessibility challenges for users with disabilities and who rely on keyboard-based interaction. The objective is to implement a systematic approach to keyboard navigation and introduce intuitive hotkeys throughout the platform. By doing so, the project aims to enhance the user experience, making app development more accessible and efficient for all users, including those with disabilities.

<p>The animation portion of the MIT App Inventor, that includes the Canvas, ImageSprite and Ball components, currently has a lot of room for improvement. This project improves the following aspects of the animation portion of MIT App Inventor.</p> <ol> <li>Enabling users to choose a custom origin for image sprites using a drag-able marker. The origin of a sprite is the root of the sprite's coordinate system. All of the interactions of the sprite that may include collisions, positioning etc. is with respect to the origin. This project implements the desired functionality of custom origin in the appinventor system and adds an interactive way, via a drag-able marker, for selecting this origin easily. </li> <li>Improving the algorithm used to detect collisions among sprites. Right now appinventor uses a naive algorithm to detect collisions between sprites. This collision detection does not work correctly for rotated image sprites and they are treated as if they were unrotated. This projects implements the SAT collision detection algorithm that replaces the naive implementation. This helps detect collisions in rotated image sprites and is more extensible.</li> </ol>

This project is to enable the selection of multiple blocks at the same time and allow moving and doing actions on multiple blocks on Blockly. This behaviour is pretty much the same as when you try to manage your files on your Operating System, and you can drag a rectangle to select multiple files, then moving them around, copying, deleting. The design is that the Blocks multi-select feature will be only functional when you hold the Shift key, so that users can still drag the workspace when not. Users can simply click on the blocks to select or unselect them, or drag a rectangle to select a set of them at the same time. A button would also be added to enable multi-selection feature in case users are unable to access the keyboard. It sounds like a little bit easy, but actually, I would say that it's not. Multiple selections can become a crazy-complex feature when you start thinking about the details. When dragging two blocks, you have to think about how the connections will work. When you right-click on multiple selections, you also have to make sure that those options apply to all blocks. And the touch screen problem would also need to be addressed. The feature request (https://github.com/google/blockly-samples/issues/267) has remained open on the GitHub Issues for 6 years, but it's still in the discussion phase and far from the beginning of Implementation there. So I hope we can implement that during GSoC 2022 if possible.

<p>A new component of App Inventor for users to display charts on Android device. I discussed the general idea as well as some details of implementation in this proposal.</p>

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>An approach to enhance the functionality of the MIT App Inventor by adding support for <strong>Custom Font Typeface</strong> that enhances the flexibility of user-interface design.</p>

While developing apps using MIT App Inventor, students often need help. For this MIT App Inventor has a community where students can reach out for help. While the community is very helpful and makes development easier, it would be even more convenient and time-saving to have a user interface on the app inventor website itself from which users can directly ask questions in the community and project files can be automatically uploaded on community website along with that .

<p>This project aims to improvise ListView in App Inventor. It was one of the most demanded improvements from users. Idea - Adding custom layouts to ListView. Expected Outcome - 1) Users will be able to select one of the pre-defined ListView layouts and use it in their applications. 2) Users will be able to create any custom row of ListView if it is not present in the pre-defined set of layouts.</p>