Explore Projects

The aim of this project is to implement an http4s Ember WebSocket client, a pure functional WebSocket client in Scala and integrate it with other libraries in the Typelevel ecosystem. WebSocket is a computer communication protocol that enables two-way communication between a client and a server, which is widely used in numerous applications including messaging and real-time notifications, as well as GraphQL subscriptions and executing commands in a Kubernetes Pod. An Ember implementation of the WebSocket client would benefit from the ability to cross-compile to multiple platforms (JVM, ScalaJS and Native). It would also potentially achieve high performance due to Ember being built on fs2 and thus can take advantage of highly optimized fs2 runtimes.

<p>The [OpenTelemetry Go Compile Instrumentation](https://github.com/open-telemetry/opentelemetry-go-compile-instrumentation) project provides `otelc`, a compile-time auto-instrumentation tool for Go applications. It injects OpenTelemetry instrumentation during the Go build process without requiring manual source-code changes in the target application. As the project moves toward its v1.0 release and continues feature-parity work with mature compile-time instrumentation efforts such as [Orchestrion](https://github.com/DataDog/orchestrion) and [Loongsuite](https://github.com/alibaba/loongsuite-go-agent), the next phase is to broaden real-world library coverage while hardening the tooling and contributor workflow needed to maintain those integrations over time. This mentorship focuses on adding several mentor-approved integrations from the project roadmap and backlog, such as messaging, database/cache, logging, Kubernetes client, or GenAI SDK libraries, while improving `otelc` whenever the integration work exposes gaps in rule authoring, hook implementation, testing, or debugging. The mentee will also document the science behind compile-time instrumentation: how Go symbols and versions are matched, how hooks are injected, how OpenTelemetry semantic conventions are applied, and how compatibility is verified across library releases.</p><p><br></p><p>Expected Outcome:</p><p> - Add `otelc` instrumentation support for 3-4 widely used Go libraries selected with mentors from the project roadmap/backlog, depending on complexity and project priorities.</p><p>&nbsp;- For each new integration, implement instrumentation rules and hook code, define supported version ranges, and follow the relevant OpenTelemetry semantic conventions.</p><p>&nbsp;- Add meaningful unit, integration, and/or end-to-end tests that verify the instrumented application builds and emits the expected telemetry.</p><p>&nbsp;- Improve the instrumentation tooling or contributor workflow as needed during the work, for example rule validation, hook scaffolding, latest-library compatibility checks, integration layout, or debugging output.</p><p>&nbsp;- Write documentation, examples, and demos that explain how to use the new integrations and how future contributors can build similar ones.</p><p><br></p>

Chaos Engineering is the discipline of experimenting on a system in order to build confidence in the system’s capability to withstand turbulent conditions in production, ref. https://principlesofchaos.org/, i.e. to induce errors on a system and see how it behaves. eBPF can be used to induce such errors on a system, it can change the return value of a kernel function, drop or modify network packets, etc. The goal of this mentorship is to implement a set of gadgets for Inspektor Gadget that helps causing system chaos. These are some ideas of the gadgets that should be implemented: - DNS: Drop/modify/add latency DNS requests and/or responses based on - The container or process performing it - The target URL - The DNS server - TCP/UDP: Drop network packets based on - Destination / Source IPs - Originating or destination pod or process - Simulate system call failures based on - Container or process performing the syscall - Syscall The gadgets should expose metrics with the number of times it induced failures, and possibly also provide notifications when those errors were induced. Expected Outcome: A set of gadgets with the above functionality should be implemented and merged on the upstream Inspektor Gadget repository. Those gadgets should include documentation and tests.

<p>WikiEduDashboard pulls huge data related to a wide range of WikiMedia projects via <strong>MediaWiki API</strong>, across groups of editors. This scales upwards when we go on to different courses and their types, then different campaigns. Currently, all the error logging done via <strong>Sentry-Raven</strong> is noisy (and not helpful for specific jobs) along with some error handling in the form of <strong>authentication errors</strong>, <strong>rescue development errors</strong>, <strong>rescue errors</strong> and some more typical error handling.</p> <p>My project will involve making a <strong>custom error mechanism</strong> for keeping track of a variety of <strong>data related errors</strong>, <strong>removing orphan locks in course update Sidekiq workers, jobs and queues</strong>. The tracked errors will displayed separately for a course along with course update process statistics, being visible everyone. Data related errors will include errors occuring due to unexpected formats of data, API errors, application errors, etc. Regarding the orphan locks, an additional mechanism to remove them will be made so that future unique jobs don't block forever due to the orphan locks and the course update process continues normally.</p>

Tool that allows the user to activate the capture of logs and errors. It should be possible to save the sequence of events in a text file. It will be necessary to add logging capture to all functions and functionalities and their respective levels (debug, info, warn, error or critical). Deliverables: 1) Graphic interface integrated to InVesalius that allows the user to activate the tool and save the logs. 2) Log support to all InVesalius functions and functionalities. A separate text window for console stream output. 3)Add provision/tools for error catching.

<p>Scala Native is a new target for Scala. It uses llvm to compile Scala to native assembly code, instead of compiling it to JVM bytecode. However, as compiling Java to llvm is not supported, there is a need to reimplement parts of the JDK. As it is currently work in progress, I could help contributors to achieve this goal. One of the most important milestones is implementing JDK API to support concurrency in Scala Native. This would be the core part of coding during the GSOC program. If finished before the end of the program, together with my mentor and the rest of contributors, I would look for other parts of the JDK API to implement.</p>

<p>Tarantool's SQLite-derivative VM code for SQL engine known as 'vdbe' is creating a performance bottleneck: self-execution of the main part of the VM's opcode dispatcher is mostly half of total CPU time.</p> <p>My proposal is to implement an embedded LLVM JIT engine solution which would replace part of vdbe responsible for DQL. In the future perspective, vdbe could be completely migrated to this engine. This solution is anticipated to give 20% performance boost for DQL compared to vdbe.</p> <p>The goal of this project is to develop the solution described in the proposal, making it scalable, and integrate it with vdbe, afterwards benchmark it and compare its performance to that of original vdbe.</p>

ArduPilot flight logs are currently analyzed manually, making it difficult to understand why crashes or unexpected behavior occur. Users have to inspect multiple signals across time, which requires experience and is not reliable for most people. A Python tool that runs locally and takes a .BIN log as input. The data is aligned across time and processed to extract signals such as attitude error, battery behavior, GPS error and other signals. Physics-based checks detect sustained issues based on flight behavior, while a Hidden Markov Model observes patterns over time to filter out short disturbances. Results are treated as reliable when both agree over a consistent duration. An LLM based agent coordinates the workflow by running the analysis steps and combining their outputs into a clear explanation, while all calculations follow rule-based logic. The analyser adapts to different firmware versions by reading parameters and detecting configuration related issues by comparing them with expected ranges from the ArduPilot codebase. It outputs what happened, when it happened, and why, along with linked telemetry evidence and possible fixes. Deliverables include a complete Copter focused diagnostic pipeline, ML integration, dynamic parameter lookup, structured output generation, and a packaged command line tool with documentation.

Seata Go currently lags behind the Java version in registry support and operational diagnostics. This proposal introduces a shared multi registry foundation for Seata Go, implements Nacos, ZooKeeper, Consul, and Redis support in a phased and reviewable way, addresses NamingServer and path compatibility issues needed by the Go SDK baseline, and extends seata ctl with server and config self checks, transaction and lock diagnostics, and structured output. The project deliverables include the shared registry layer, four registry adapters with tests, a bounded diagnostic command set, and follow up TUI, sample, and documentation polish.

Currently, devfile validation only occurs after the user submits the form to create a workspace. This means users only discover invalid devfiles after waiting for form submission. Implement just-in-time (JIT) validation for devfiles in the workspace creation form: When a user selects a devfile from the dropdown, validate it immediately in the background, Display a visual indicator (icon/label) next to the selected devfile showing its validity status, Provide clear, actionable error messages for invalid devfiles before form submission

<p>Curry is a functional logic programming language that combines the most appealing features of the functional and logic programming paradigms. There are various implementations for Curry such as PAKCS, mcc and KiCS2 which differ in the target language used for object code generation. In this project, we propose to develop a compiler of Curry in which Ruby is the target language. Ruby is not efficient but simplifies the compiler for its high-level features including dynamic typing and reflection. The end-product of this project will be an ideal tool that can be used by students and researchers to understand compilation techniques for functional logic programming languages, and to experiment with and prototype specific aspects of the language and the compiler, in particular parallelism, security, optimizations and language extensions.</p>

<p>The project proposes idea to implement peephole optimization in NetLogo Compiler codebase and perform cross-platform compiler optimization on both platforms Desktop (NLD) and Web (NLW) thus benefiting both the projects.</p>

Solidity is a language for Smart Contracts used by the Ethereum Solidity compiler. Solang is a new implementation of the Solidity compiler, which can target wasm on more blockchains. Solang is written in rust and uses a generated Solidity parser. Modern IDEs provide syntax highlighting, symbol definition, errors, warnings etc. This is often done via the Language Server Protocol. There are no good implementations of a language server for Solidity, however using the parser and resolver of Solang, this can change. The idea of this mentorship is to extend the Solang Compiler project so it can run as a language server, that implements the Language Server Protocol.

<p>Automated Program Repair (APR) has been showing a high capability recently of fixing software bugs automatically. Despite the recent advancements, there are only a few APR techniques specifically addressing regression errors. These techniques yet, however, have not fully exploited the information available in software evolution history, e.g., bug-inducing commits, etc, for repairing regression errors. Moreover, the techniques either work on a specific language (e.g., C language) or do not provide their implementations for public access.</p> <p>This project aims to empower automatic repair of regression errors for Java programs by implementing and extending recent interesting findings of regression errors, e.g., the correlation between bug-inducing and bug-fixing commits. We aim to build a system, namely LyFix, that enables users to fix Java regression bugs automatically by leveraging fix ingredients and specific repair operators learned from the software development history.</p>

This project aims to create a ROS2 package that automatically converts C/C++ structs into ROS2 messages and generates the corresponding TypeAdapters. This removes the need for developers to manually define message files or boilerplate conversion logic, making it easier to use C/C++ structures directly in ROS2. The package uses castxml to generate an abstract syntax tree, parse it with pygccxml, and extract c/c++ structs definations. Then, Jinja templates are used to generate ROS2 msg files and the corresponding Type Adapter from the parsed data. For opaque or external library types (e.g., Eigen), the system will support a mechanism to register custom TypeAdapters, allowing users to define conversion logic manually that can be included by other ROS2 packages. Deliverables: - Parser using castxml + pygccxml to extract struct definitions and a Jinja-based generator to produce ROS2 Message files and Type Adapters. - CMake macros/functions that can be used in ROS2 packages to register generated msg files to rosidl and install the type adapters. - Examples demonstrating usage of CMake functions/macros, auto-generated messages and type adapters in other packages.

The goals of the project is to : ●Develop an O3 UI, aimed at system administrators, to facilitate configuration of Message Services - create new ones, upload SQL queries, configure configuration options. ●Develop an O3 UI patient-based visualization of a schedule, showing when a message from a particular Message Service is going to be sent to the Patient.

<p>Mypyc is a compiler from type-annotated Python to CPython C extension modules. It uses type information and restrictions to certain dynamic language features to speed up code, often significantly.</p> <p>This project speeds up compiling three string formatting methods (printf-style, str.format, f-string) and frequently used conversion operations. It also adds the bytes primitive and supports related operations.</p>

Tremor uses its own language for pluggable user defined functionality. The language interconnects internal operators via the connect statement and the select statement. Currently, neither select nor connect verifies that the operator port of the receiving or the sending part is correct ( exists, and is an expected type ) - this can lead to silent or confusing errors. User experience is super important to tremor, so that is a solution state we’re not happy with. The goal of this mentorship is to add validation and provide targeted hygienic errors to users that are trivial to diagnose and resolve as this will massively improve user experience.

<p>This project aims to extend diagnostic statistics in the R package <code>quokar</code>. Currently in this package we have several methods such as absolute residual and robust distance, general Cook's distance, Q-function distance , mean posterior probability and Kullback-Leibler divergence to detect outliers in the framework of quantile regression models. Recently, the research on sensitivity analysis of quantile regression has attracted more and more attention. Improved methods have been introduced in the literature, which have not yet been implemented in R. This project aims to extend diagnostic statistics in <code>quokar</code>. It will provide users with the much needed methodology to diagnose outliers in quantile regression, thereby reducing the risk of a detrimental estimation impact that outliers may have.</p>

<p>Ahmia is a working search engine that indexes, searches, and catalogs content published on Tor Hidden Services. Furthermore, it is an environment to share meaningful insights, statistics and news about the Tor network itself. In this context, there is a lot of work to do.</p> <p>During GSoC, I plan to work on several aspects of this search engine from fixing bugs to improving search results.</p> <p>First I’m going to start working on bugs and automation so users and developers can see immediate results and so I can learn my way around the codebase quickly.</p> <p>Then I will start developing new features like search commands, additional search results information (like screenshots). I will also work a lot on improving the search results.</p> <p>Finally I will work on statistics which is not an easy problem when you also want to respect privacy.</p> <p>I also have a couple ideas for optional goals or additional projects I could make after GSoC is done.</p>

I improved GNOME Crossword Editor's word suggestion algorithm, by re-implementing it as a forward-checking algorithm. Previously, our word suggestion algorithm only considered the constraints imposed by the intersection where the cursor is. This resulted in frequent dead-end word suggestions, which led to user frustration. To fix this problem, I re-implemented our word suggestion algorithm to consider the constraints imposed by every intersection in the current slot. This significantly reduces the number of dead-end word suggestions and leads to a better user experience. As part of this project, I also researched the field of constraint satisfaction problems and wrote a report on how we can use the AC-3 algorithm to further improve our word suggestion algorithm in the future. I also performed a competitive analysis of other crossword editors on the market and wrote a detailed report, to help identify missing features and guide future development.

<p>Radiator valves have become increasingly important in recent years, especially in some countries where they have been made mandatory by law. This led to the production of various models programmable using a smartphone application coupled with the BLE (Bluetooth Low Energy) protocol. At the moment all the products on the market use proprietary communication protocols to exchange essential data with the application, making it difficult to integrate this devices into external open-source projects. For this reason the University of Milan has successfully reverse-engineered a protocol and <a href="http://sl-lab.it/dokuwiki/doku.php/tesi:reveng-termovalvole" target="_blank">released</a> the necessary code to use it with a <em>GPL</em> license.</p> <p>The project aims to use what has already been produced to:</p> <ul> <li>write a <strong>reverse-engineering guide for BLE devices</strong> as general as possible</li> <li>design a mechanical device to test the valves without a radiator</li> <li>port the library to a more modern language in an attempt to integrate it into projects such as <em>openhab</em> or <em>home-assistant</em> and create a Debian package</li> </ul>

<p>QEMU's emulator allows running operating systems and binaries compiled against one architecture (e.g. Linux ARM) on a host with a different architecture (e.g. Linux x86_64). This process involves a JIT compiler that translates the target CPU instructions to the host's. In this process, some targets outperform others, and some targets have performance bottlenecks in QEMU functions that other targets don't.</p> <p>In this project, the performance of QEMU's emulation will be deeply analyzed using major profiling tools across all of its targets for both of its user mode (executables) and system mode (operating systems).</p> <ul> <li>Custom written benchmark programs will be used to activate the desired QEMU functionalities and locate the target bottlenecks and profile its execution and runtime.</li> <li>Automation tools will be written that detects runtime performance degradation across different versions and targets of QEMU. They will also be used to find how different targets perform compared to each other.</li> <li>Past major releases of QEMU will be examined to identify performance regressions from the past.</li> </ul> <p>All of the findings and conclusions will be regularly presented to the QEMU developers to act upon.</p>