Explore Projects

<p>Firefox Profiler is a tool which visualizes performance data recorded from various performance analysis tools, which helps us to have an insight into our app’s responsiveness, Javascript and layout performance. By using it efficiently we can optimize our app in terms of performance. Currently, it supports Gecko, chrome, and perf(Linux) profile formats. This project will provide support for visualizing profiles from Instruments which is a powerful and flexible performance-analysis and testing tool that’s part of the Xcode toolset.</p>

JITLink is LLVM’s new JIT linker designed to support a variety of new features, which includes full static initializer, thread local storage, and small code model, that were not possible in RuntimeDyld, the old JIT linker API. JITLink’s generic linker algorithm needs to be specialized to support the target object format (COFF, ELF, MachO), and architecture (arm, arm64, i386, x86-64). This project aims to implement the JITLink specialization for ELF/aarch64 and COFF/x86-64.

<p>This Google Summer of Code 2020 project aims to increase support for circular and discrete variables in the ArviZ library. ArviZ currently provides tools and diagnosis for Bayesian data analysis and it is very well supported for continuous variables. However, there is plenty of space for new developments when it comes to discrete and circular variables. As a result of this project, several new plots will be incorporated into ArviZ, for example: mosaic plot, agreement plot, circular KDE, circular histogram. On the other hand, ArviZ current implementations will be revised and extended for the circular and discrete variable setting.</p>

When it comes to modern baremetal environments as well as second generation Virtual Machines, Unikraft's ability to print debugging logs to the screen is limited. The aim of this project is to support the modern UEFI GOP interface in Unikraft, which allows drawing fonts directly to the screen, thus enabling the printing of logs. UEFI GOP supports multiple rendering resolutions and color depths, ensuring close compatibility with all hardware systems. Implementing logging with UEFI GOP will greatly improve the development experience of Unikraft on UEFI-enabled targets, particularly targets where serial port consoles are unavailable.

<p><strong>Linux kernel Networking API and selftest improvements</strong></p><p>The deadline to create an initial application has passed for the May 2022 Outreachy internship cohort. We are no longer accepting initial applications for internships. We encourage you to sign up for the announcements mailing list to get an email when the next round opens. Why apply to Outreachy? &gt; Start your initial application &gt; May 2022 Outreachy internship cohort &gt; Linux Kernel Community details are hidden until you are approved to participate as a mentor or coordinator.</p><p><br></p><p><strong>Mentorship Cohort:</strong> 2022</p>

<p>The most frequently used Ruby Core APIs <code>Kernel::require</code> and <code>Kernel::require_relative</code> are doing the same work: it’s to resolve the file path, read the file, compile ruby source to bytecode or load a shared object, evaluate and add an entry to <code>$LOADED_FEATURES</code> . But if using Ruby stdlib benchmark to profile their performance, we can figure out a fact: <code>require</code> a relative path is almost 10 times slower than <code>require</code> an absolute path and about 4 times slower than <code>require_relative</code> the same path. This proposal aims to figure out the reason and optimize it.</p>

LibreMesh relies on continuous testing to ensure its robustness across various network conditions and hardware setups. Currently, testing new firmware images lacks a standardized method to include Wi-Fi simulations within a virtualized environment. This project aims to add Wi-Fi support to existing QEMU simulations for LibreMesh, allowing near-realistic network testing using virtual Wi-Fi interfaces. By leveraging the mac80211_hwsim module and integrating existing OpenWrt-friendly virtual Wi-Fi tools, we can enhance testing automation and reproducibility. Benefits to the Community - Improved Testing Framework: This project will enable LibreMesh developers to run “almost real” tests in a virtualized environment, improving debugging and validation before deploying changes to physical hardware. - Enhanced Automation: By integrating virtual Wi-Fi support into QEMU, developers can automate complex test scenarios without requiring physical routers. - A set of scripted tests that can be run on real hardware: Currently, real tests on physical hardware are performed manually at each release. With this new set of test scripts for QEMU and Wi-Fi, many tests will be automated and easily adapted to real hardware. - Collaboration with OpenWrt: Given that OpenWrt is also working on virtual Wi-Fi support, this project can align efforts with the broader open-source networking community, benefiting multiple projects. - Lower Barrier to Entry: New contributors will find it easier to test their changes without needing specialized hardware.

Vitess is a database clustering system for horizontal scaling of MySQL. One of the key goals of Vitess is to emulate MySQL behavior even while running multiple MySQL instances so that ORMs and frameworks work seamlessly. Vitess has its own in-built SQL-parser which it uses to understand the query and represent as structs for further processing. As of now, a lot of MySQL constructs are not parsed and result in syntax errors. For example, we do not have complete support to parse [partition constructs](https://dev.mysql.com/doc/refman/5.7/en/partitioning-overview.html). Parsing for a lot of the newer features in MySQL 8.0 is also missing. The task of the mentee would be to add parsing support for such constructs.

<p>Through this project, I wish to improve the chat-ops capabilities of Zulip by adding support for slash commands and outgoing webhooks. Outgoing webhooks are integrations which send data to third party services from Zulip on being triggered. Slash commands enable users to make use of services through chat messages. Example: change topic, archive messages, etc. I wish to build an outgoing webhook system which will enable users to easily add outgoing webhooks into their Zulip realm through UI. Users can also use their own code by adding it to the codebase for complex uses. I also wish to add support for slash commands which can be enabled, disabled and managed by users.</p>

Inkscape’s support for Adobe Illustrator (.ai) files is limited, especially for files that include raster images, masks, filters, and other advanced features. This project aims to improve Inkscape’s .ai import by handling more of the format’s structure and content. Key focus areas include support for clips and masks, stroke styles, symbols, filters, text on path, and live shapes with multiple radii. Some optional goals are reading metadata and object properties. The solution involves parsing PDF-compatible data and extending Inkscape’s import logic to produce accurate SVGs. Progress will be measured using a set of .ai test files that render correctly in Inkscape.

The project aims to extend API Dash with Git-backed collections, a visual workflow builder, and a collection dashboard. This will enable developers to version and share API collections, design and execute multi-step API flows, and monitor API health and performance within a single unified tool. Problem Being Solved: API Dash currently stores requests in a flat local structure without version control or collaboration support. The existing load-all/manual-save model limits reliable syncing, introduces risk of data loss, and prevents building higher-level features like analytics and workflows. Additionally, users lack visibility into API performance and have no structured way to define multi-step API interactions. Proposed Solution: 1. A refactored persistence layer using request-level autosave (Hive LazyBox) for reliable and granular data storage. 2. A GitHub integration layer to enable version control, sharing, and collaboration on collections. 3. A visual workflow builder with a node-based interface to define and execute multi-step API flows. 4. An execution engine to handle request chaining, conditions, and shared data flow between steps. 5. A dashboard system to aggregate and visualize API and workflow performance metrics. Key Deliverables: 1. Request-level autosave system replacing the current bulk-save model. 2. Git support for collections (connect, import/export, push/pull, commit history, rollback). 3. Visual workflow builder with execution support, run history, and DashBot-assisted workflow generation from natural-language prompts. 4. Collection and workflow dashboards showing success rates, failures, and latency signals. 5. Production-ready documentation, testing, and UX polish for real-world usage.

In this project, I propose to create NLP examples using transformer implementations from the Hugging Face Library; by developing easy-to-use and easy-to-understand Deep Learning pipelines for solving various NLP tasks. In the recent past, transformers have achieved state-of-the-art results in tasks like Question Answering, Machine Translation, etc. and the goal of my finished result is to develop additional code examples and Jupyter notebooks similar to Keras Examples that can be used by new-comers and other people at various stages of their learning journey to easily understand various deep learning workflows for complicated tasks. My proposed tasks include Speech Commands Classification, Abstractive, and Extractive text summarization, and Automatic Speech Recognition.

<p>I am going to work on improvement of NSE brute-force performance and add additional support of such protocols like ssh and rdp. Currently there are more than 60 brute-forcing scripts but there is still room for improvement of NSE's parallelism, performance and protocol support.</p> <p>Main tasks:</p> <ul> <li>Improve NSE brute force performance to match Ncrack as close as possible</li> <li>Develop ssh-brute script for brute forcing SHH credentials</li> <li>Develop rdp-brute script for Remote Desktop Protocol</li> <li>Improve internals of NSE for better parallelism</li> </ul> <p>Possible mini projects:</p> <ul> <li>SSH key acceptance checker</li> <li>Remote ssh commands from within NSE scripts</li> </ul>

The aim of this project is to add support for an LLM (large language model) based on tools such as GPT-4 to support AI-based programming support for our users. This support could range from proposing code from text prompts, help in correcting bugs or other issues, finding a good architecture or meaningful names, writing Catrobat language tests for one's code, proposing extensions, proposing project ideas, explaining downloaded code, providing translations of variable or message names etc from downloaded projects of other users, proposing image and sound resources based on the context and text prompts, explaining basic or more advanced concepts needed to realize projects, e.g., simple concepts such as variables and loops, or more complex ones such as software design patterns or testing strategies. Overall, the proposed project aims to provide a more comprehensive and tailored solution for Catrobat users, with a broader range of features and a more user-friendly interface compared to existing products.

<p>The end goal of this project is to make the entire Sugar Code compatible with both the major versions of Python.</p> <h5>Importance:</h5> <p>The project is critical since libraries like GStreamer are drawing their support from Python 2 and support for Python 2 is also about to end.</p> <h5>Description:</h5> <p>The project involves the following milestones:</p> <ul> <li>Port the static bindings of Telepathy to their PyGI counterpart</li> <li>Port the automake files to install the toolkit for both Python 2 and Python 3</li> <li>Port the C extensions of Python to be compatible with Python 3</li> <li>Port the Sugar toolkit to make it Python 2 and Python 3 compatible</li> <li>Port the Sugar OS and Activities to Python 3</li> <li>Release the corresponding new versions and Debian and Fedora Packages</li> <li>Rewrite the entire documentation</li> </ul>

Java Path Finder (JPF), a specialized Java Virtual Machine for software verification, excels with Java 8 but faces challenges with modern features in Java 11 and 17, such as bootstrap methods (e.g., lambdas and string concatenation) and internal functions like toString() and hashCode() for records. My project seeks to address this by enhancing JPF to fully support Java 11 and 17. I will upgrade BootstrapMethodInfo to manage string concatenation effectively, refine INVOKEDYNAMIC execution to mirror the host JVM’s dynamic call site generation, and ensure internal functions operate correctly for new Java features. Drawing on OpenJDK research, I’ll implement these changes and validate them with thorough testing. Deliverables include full Java 17 support in JPF’s default branch, a comprehensive test suite for string concatenation and records and updated documentation. This work will modernize JPF, enabling it to verify advanced Java programs and strengthening its value to the verification community.

Scrum Helper currently supports only GitHub and a partially-integrated GitLab, with all platform logic tightly coupled in a 2,190-line monolithic file. This makes adding new SCM platforms nearly impossible without duplicating the entire data-fetching flow. This project refactors Scrum Helper's core into an extensible Provider Pattern architecture by defining a standardized SCMProvider interface that decouples platform-specific API calls from the report generation engine. I will then implement native providers for GitLab (including self-hosted instances), Gitea, and Bitbucket, each returning normalized data through a unified schema. Deliverables: (1) SCMProvider interface with normalized data models, (2) Refactored GitHubProvider with full regression coverage, (3) GitLabProvider with self-hosted baseUrl support, (4) GiteaProvider tested against Codeberg, (5) BitbucketProvider with OAuth 2.0 auth, (6) unified caching and cross-provider error handling, and (7) architecture guide and contributor docs for adding future providers. All 4 platforms will generate identical scrum reports by project end.

Currently, there is uncompression support for .svgz format, which is a Z compressed .svg file. The goal of this project is to extend support for Z compressed graphic formats, namely .wmz and .emz, which currently can't be opened by LibreOffice. The second goal of this project is to implement saving functionality for .svgz, .wmz and .emz. While .svgz is an option in the save dialog, it is incorrectly implemented (no compression actually happens, it's just an svg with a different extension). The plan is to create a new and extensible way that uncompresses the file buffer after determining if its compressed from its header,and try to open the uncompressed file buffer. The plan for the second goal would be to find a way to determine whether the file we're saving needs to be compressed (either by checking the extension or by creating a new option in the file saving dialog) and compress the file buffer before saving. This is not as easy as it sounds, as we need to factor in various pitfalls such as what happens when there's not enough RAM to hold the temporary compressed buffer for example. Deliverables would be an extensible way to load and save Z compressed files, an exhaustive unit test suite, which will test file detection, graphic loading, pitfall handling behavior and ready made test files.

<p>Sequential Monte Carlo (SMC) methods are a general class of Monte Carlo procedures for sampling from sequences of probability distributions. Basic examples of these algorithms, termed particle filters, are frequently used in a variety of fields including signal processing, economics, and systems biology.</p> <p>Recent methodological developments, one example being Particle MCMC and Particle Gibbs methods, have gained considerable popularity. However, they require algorithmic extensions and are particularly computationally expensive. Hence, software support for these procedures is currently in high demand.</p> <p>This project aims at providing straightforward implementation of modern SMC/Particle MCMC methods by extending the C++ template class library of RcppSMC which is currently not supporting these methods.</p> <p>Benefits for the R community are expected, firstly, as SMC practitioners who already use R can reduce execution time as well as time necessary for implementation in their everyday work. SMC developers, currently not using R as their first programming language of choice, hopefully see the benefits of this package and thus might consider using R more often in this domain in the future.</p>

Eye-tracking devices are widely used in neuroscience research. Studies of visual perception and attention in particular are increasingly integrating eye-tracking and EEG/MEG devices, in order to gain a better understanding of these processes and their neural correlates. However, the Python community has yet to coalesce around a well-supported package for analyzing eye-tracking signals. This project proposes to integrate support for reading, visualizing, and analyzing eye-tracking signals in MNE-Python. By incorporating the ability to analyze eye-tracking data into MNE-Python, researchers would be able to analyze both neural and eye movement data within the same software environment, making MNE-Python more versatile and useful for a wider range of research questions. Finally, MNE-Python has a large community of developers and users, making it likely that eye-tracking integration will prove useful for many in the scientific Python community. This project will focus on building a robust I/O routine for eye-tracking data and developing functions for preprocessing, visualization, and analytical routines that are commonly required in eye-tracking research. This includes the ability to interpolate eye-position data during blinks, produce heatmap plots of eye-position across trials, and estimate the deconvolved pupil response.

<h4>GitMate for all!</h4> <p>This time with user configurable plugins!</p> <h3>About the product</h3> <p><strong>GitHub</strong>, <strong>GitLab</strong> and <strong>BitBucket</strong> support webhooks for common events like opening/closing/commenting on Merge Requests, creating Issues, etc. These webhooks could be configured for automated response using their own API's for comments, tests/integrations, etc. <strong>GitMate</strong> merely acts as a tunnel for these events and responds accordingly. The interface for these API's is held by its wrapper library, IGitt.</p> <h3>Aim of the project</h3> <p>This project is aimed at extending the support for <strong>GitMate</strong> to <strong>GitLab</strong> and <strong>BitBucket</strong> repositories. This adds up to unified and automated code analysis and maintenance on the big three code hosting platforms.</p> <h3>Implementation</h3> <p>This project consists of implementing <strong>GitLab</strong> and <strong>BitBucket</strong> interfaces in <strong>IGitt</strong>, following the already implemented <strong>GitHub</strong>'s convention, while simultaneously creating webhook responders and tasks for the same on <strong>gitmate-2</strong>.</p> <p>Extending plugins is quite easy on <strong>gitmate-2</strong> following <code>gitmate_testplugin</code> as an example, thanks to its plugin-based architecture.</p>

The Vala compiler and the Vala API generator currently have no support for the latest GObject Introspection attributes. This proposal plans to add this support to both the Vala compiler and the Vala API generator. It also seeks to add GI-Docgen format support to Valadoc. I plan to make the Vala compiler support these attributes by making Vala.GIRWriter insert these attributes in the generation of GIR files. Similarly, Vala API generator can support these attributes if we make Vala.GirParser parse them from GIR files and add them to the Vala AST. Finally, the plan is to make libvaladoc parse comments in the GI-Docgen format. Upon the completion of this project, the Vala compiler and Vala API generator will be able to use these latest attributes in the generation and parsing of GIR files. It will also result in Valadoc being able to support the GI-Docgen documentation format so that it can be used with Vala GIR files. In addition, Valadoc documentation pages will have a modernized appearance and they will be able to render working GI-Docgen links.

The Shmdata library provides a layer to share streams of framed data between processes via shared memory. It supports any kind of data stream: it has been used with multichannel audio, video frames, 3D models, OSC messages, and various others types of data. Shmdata is server-less, but requires applications to link data streams using socket path (e.g. "/tmp/my-shmdata-stream"). Shmdata is very fast and allows processes to access data streams without the need for extra copies. However, permissions are not supported, and any stream shared on the system with Shmdata is accessible system-wide. The project will enable the possibility for a Shmdata user to configure streams permission using shared memory right setting at the API level. When sharing data between processes via shared memory, not all components of the data need to be visible to everyone. Different groups might need to access different data, furthermore, some data might only be needed to be visible to the owner of the files. In such cases, the permissions that would have to be implemented are combinations of 'read', 'write' and 'execute' permissions that would be given to the owner, group or common user(i.e. everyone else). Permissions would be 'none', 'execute only', 'write only', 'write and execute', 'read only', 'read and execute', 'read and write', 'read, write and execute' with corresponding values of 0-7 respectively. DELIVERABLES * Providing an option for users to restrict or openly share data streams via these file/ directory access modes: read, write and execute/traverse. * Changing data access permissions. * Documentation for the improvements made. * Incorporation of ACL to assist with Unix file permissions. (optional/if time allows).