Explore Projects

Ruqola, a Qt-based Rocket.Chat client, currently lacks a robust implementation of end-to-end encryption (E2EE), making user communications vulnerable to interception. This project aims to design, implement, and integrate a complete E2EE workflow into Ruqola, ensuring secure messaging through strong cryptographic techniques. The project consists of two phases: Phase 1: Encryption Sandbox Develop a standalone Encryption Test GUI to prototype and validate E2EE workflows. Implement Master Key derivation (PBKDF2), RSA key pair generation, AES message encryption, and session key exchange. Create unit tests for core encryption processes. Phase 2: Ruqola Integration Integrate encryption into Ruqola’s communication system. Encrypt outgoing messages with session keys and decrypt incoming ones. Provide a user-friendly UI for encryption settings. By the end of the project, Ruqola will have a fully functional E2EE system, securing user messages with cryptographic best practices while maintaining an intuitive user experience.

<p>An engine in C++ to run the Mission Supernova 2 game on ScummVM.</p>

<p>ScummVM contains a port of the Wintermute lite engine, which is only capable of 2d graphics. The original Wintermute engine also offered some 3d graphics features using DirectX 8/9. The main goal of this project is to add the Wintermute port to ResidualVM and reintegrate the missing 3d features by providing a OpenGL backend. As a result, ResidualVM will be able to provide support for the Wintermute games which are not already handled by ScummVM, because they use 3d graphics. As a concrete example the Wintermute game Alpha Polaris shall be playable with ResidualVM at the end of GSoC.</p>

<p>The ScummVM project currently does not support the original MacVenture games developed for the Macintosh 128k. However, there is already a modern implementation of these games that supports the original game files, the WebVenture engine.</p> <p>Most of the reverse engineering work for the MacVenture games is <a href="http://seancode.com/webventure/formats.html" target="_blank">already done</a> in the WebVenture engine, but since it is written in JavaScript, a direct port is necessary for it's integration with ScummVM. In addition, the WebVenture engine already supports the Apple II versions of the games, making it possible for them to be added to the same engine in the respective ScummVM implementation.</p> <p>Therefore, the goals of this project are:</p> <ul> <li>To write an engine in C++ to support these games, with a base in the existing JavaScript implementation.</li> <li>To integrate the engine with the existing ScummVM framework, so that it can support MacVenture games in the many platforms that ScummVM supports.</li> </ul> <p>Most of the MacVenture games were pioneers in their respective genres, so the ScummVM community would benefit greatly from having access to these games as classics of their genres, for academic and nostalgic value.</p>

<p>Haskell tooling has improved considerably over the last year. Haskell IDE Engine was able to build a user-base that is happy with the feature set. Moreover, competing projects have been created to explore different design spaces. With the rise of these tools, certain limitations became apparent in the GHC API. For example, it is complicated to propagate updates between dependent packages.</p> <p>In this proposal, I intend to enable GHC and GHCi to work with multiple packages at once. Most importantly to the end user, this allows development of multiple packages in GHCi. There are other workflows which can benefit from such functionality, such as incremental compilation and Haskell Language Server.</p>

<p>The Haskell developer tool ecosystem, while greatly improving in recent years, has a performance problem. Haskell IDE Engine (HIE), the most popular implementation of the language server protocol for Haskell, is a great example of this. While it is an incredibly useful tool, its variable performance interferes with the productivity of Haskell developers.</p> <p>Profiling tools is another area where the Haskell ecosystem is lacking. While some tools do exist (for example ThreadScope), they are not as polished as similar tools for other languages, and do not allow for remote monitoring, which can be incredibly useful in distributed applications.</p> <p>I believe these two problems have a common solution: OpenTelemetry is a set of APIs and protocols made for instrumenting code, gathering traces and metrics, and analysing all that data, in a language-agnostic way, on a variety of independent clients.</p> <p>As my Google Summer of Code Project, I would like to first improve the newly-created haskell-opentelemetry library, use that to instrument HIE, and then optimise it based on my findings.</p>

<p>A long-standing issue with Haskell’s documentation tool Haddock is that it needs to effectively re-perform a large part of the parse/template-haskell/typecheck compilation pipeline in order to extract the necessary information from Haskell source for generating rendered Haddock documentation. This makes Haddock generation a costly operation, and makes for a poor developer experience.</p> <p>An equally long-standing suggestion to address this issue is to have GHC include enough information in the generated <code>.hi</code> interface files in order to avoid Haddock having to duplicate that work. This would pave the way for following use-cases and/or have the following benefits:</p> <p>1) Significantly speed up Haddock generation by avoiding redundant work.</p> <p>2) On-the-fly/lazy after-the-fact Haddock generation in cabal new-haddock and stack haddock for already built/installed Cabal library packages.</p> <p>3) Add native support for a <code>:doc</code> command in GHCi’s REPL and editor tooling (ghc-mod/HIE) similar to the one available in other languages (c.f. the Idris REPL or the Python REPL)</p> <p>4) Allow downstream tooling like Hoogle or Hayoo! to index documentation right from interface files.</p> <p>5) Simplify Haddock’s code base.</p>

<p>Chapel is an emerging parallel programming language developed with the aim of providing better performance in High-Performance Computing as well as accessibility to the newcomer programmers in order to provide a relatively smoother learning curve in Parallel Computing.</p> <p>Polly, a polyhedral compilation based optimization tool, performs data-locality based optimizations and automatic parallelization of LLVM IR represented in Polyhedral format. The resultant polyhedra are exposed to a number of loop optimizations like tiling, vectorization and strip mining.</p> <p>I propose to integrate Polly’s Optimization passes in Chapel. In today’s world, it is well known that High-Performance Computing involves nested loops as one of their most compute intensive parts which are efficiently handled by Polly-based optimizations, hereby making HPC more productive and going towards more compute-intensive problems which are currently unfeasible.</p>

<p>Addition of <strong>deferred length variables</strong> in <strong>Fortran 2003</strong> provides a user with an utility to leave the responsibility of allocating the required space to a variable on the compiler. A deferred length variable is either <code>pointer</code> or <code>allocatable</code>. Compiler during execution allocates space based upon the value to be assigned to a variable.<br> <em>For eg:</em> If the value to be assigned to a character variable is <code>"spiderman"</code>, then the compiler will automatically allocate a space required to store this character sequence of length 9 and a reference to this space will be stored in the variable. Similarly, if a new character sequence, let’s say, <code>"batman"</code>(which is of length 6) is assigned to this same variable then the compiler will allocate a space required to store <code>"batman"</code> and a reference to this space will overwrite the previously stored reference in the variable. Thus, space required by the variable is constant as it is not storing the actual character sequence and is rather storing the reference to the space where the character sequence is actually stored.</p> <p><em>Goals of the project:</em><br> 1). Conceptualize and add new functionalities to strings<br> 2). Designing and implementing list of variable-length strings</p>

<p>Escape analysis is a classic problem in compiler analysis. Julia compiler has an existing AbstractInterpreter framework for managing inter-procedural analysis of type through data-flow analysis. But the existing framework has very limited support for escape information.</p> <p>In this project, we are implementing escape analysis via extending the current framework or via implementing a new framework and integrating it into the compiler. With better escape information collected, we are able do more kinds of optimizations including converting heap objects to stack objects and scalar optimizations.</p>

Cmm is the intermediate representation and code generation layer used by the Glasgow Haskell Compiler (GHC). It is written in Haskell and sits between GHC's high-level STG output and low-level native or LLVM code generation. Cmm enables multiple backends: a fast native code generator and a more sophisticated LLVM backend. In principle, this design allows users to choose between faster compilation or better runtime performance. However, like other parts of GHC, the documentation for Cmm is sparse, fragmented, and in many places outdated. For example, references to Static Single Assignment (SSA) form often describe it as "future work," even though there has been a prior attempt at implementing it. There is no cohesive documentation to explain what was done, how the backend currently works, or how one might extend it. This is an obstacle to contributors, researchers, and users alike. In practice, the LLVM backend suffers from long compile times and a fragile implementation. It depends on a custom LLVM AST that is hard to maintain, and requires users to install a specific, outdated version of LLVM. Meanwhile, the native backend is fast but unable to fully optimize performance-critical code. This project proposes to address these issues in stages: 1. Document the Cmm pipeline, the backend interfaces, and existing SSA infrastructure. 2. Then, depending on the mentor's and community's feedback, pursue one of two improvement paths:

This project aims to implement full coarray support in the LFortran compiler, enabling native parallel programming capabilities based on the Partitioned Global Address Space (PGAS) model defined in the Fortran 2008/2018 standards. Currently, while LFortran’s parser supports coarray syntax, the feature is not implemented beyond basic stubs, preventing execution of even minimal coarray programs. The project will bridge this gap by extending LFortran’s Abstract Semantic Representation (ASR) to model coarrays, implementing semantic analysis for coarray constructs, and introducing a dedicated coarray runtime library. A key component is an ASR-to-ASR lowering pass that translates high-level coarray operations (such as coindexed access, synchronization, and collective intrinsics) into runtime calls. This design follows LFortran’s existing OpenMP architecture, ensuring backend-agnostic support across LLVM, C, and other targets. The implementation will proceed in two phases: first, establishing a fully functional single-image mode with correct semantics and runtime integration; second, enabling multi-image execution using an MPI-based runtime backend. By the end of the project, LFortran will be capable of compiling and executing coarray programs in both single-node and distributed environments. This work lays the foundation for supporting real-world coarray-based HPC applications and positions LFortran as a leading LLVM-based Fortran compiler with modern parallel programming support.

This project is to implement an engine for the game The Immortal. The implementation will be based on the Apple IIGS version of the game. To do this, I will complete these deliverables: 1. ProDOS file system is implemented as a Common::Archive 2. Top level engine skeleton consisting of Driver, Kernal, and Logic is implemented 3. Each subsystem is implemented: a. Palettes b. Text printing c. Screen drawing d. Sprite drawing e. Logic processing f. Level loading g. Object processing h. Monster processing i. Story processing j. Combat processing k. Input handling l. Sound and Music playback 4. All remaining code is translated 5. The Immortal is playable in ScummVM

<p>CodeMirror 6 is an editor which supports many programming languages. However, it lacks first-class language support for Haskell. The Abstract Syntax Tree is missing, because a compatibility shim is used, instead of a proper parser. Also, there are several problems with recovering from source code errors.</p> <p>The idea of this project is to add first-class Haskell language support. The primary objective is to ensure full functionality, having any syntactic or semantic error detected and handled. Another aim is to make the code as modular as possible, such that it would be easily extended.</p>

<p>The overarching goal of the project is to have a minimum viable project which can compile the <a href="https://github.com/certik/dftatom" target="_blank">dftatom project</a> which is of personal interest to me as a computational chemist. Following through with <a href="https://gitlab.com/lfortran/lfortran/-/merge_requests/717" target="_blank">the initial contributions I made</a> fulfilling the patch requirement, I shall work towards the <a href="https://gitlab.com/lfortran/lfortran/-/wikis/GSoC-2021-Ideas" target="_blank">completion of the math library</a>. In particular, I intend to complete the tasks for the new Fortran runtime library. To be pragmatic and get an MVP, I shall work on allowing LFortran to <a href="https://gitlab.com/lfortran/lfortran/-/issues/52" target="_blank">use externally compiled modules</a>. Subsequently, I shall work on the implementation of arrays and their intrinsics and round out the project by enumerating all remaining corner-cases required for the dftatom project.</p>

<p>After a busy couple of days at the Bristol Hackathon, the developers behind ghcide and haskell-ide-engine merged efforts resulting in an exciting new, unified language server. Building upon ghcide's snappy shake based build system and with the extensible plugin support from haskell-ide-engine, it aims to be the de-facto language server for newcomers to Haskell. It is still new and there is plenty of work to be done throughout the ecosystem to get it ready for users:</p> <h3>Implicit cradle configuration</h3> <p>Improve how hie-bios implicitly detects and sets up cradles (sessions) without the need for a hie.yaml file</p> <h3>Update haskell-lsp with new LSP features</h3> <p>The LSP specification moves quickly, and the latest version 3.15 has lots of new features that many language servers, not just Haskell ones, would love to take support of in haskell-lsp.</p> <h3>Get haskell-language-server ready</h3> <p>Now that the ghcide base and plugin architecture is mostly in place, plugins and tests need to be moved over. Continuous integration and distribution also need to be set up.</p>

The architecture of the GHC compiler in its current state is anti-modular. Designed with GHC-the-program as the sole consumer in mind, it is very difficult for newer tooling to reuse its components. These problems extend to the inclusion of new backends such that implementations for various target platforms forked GHC frequently. The first step to improving the current design is the isolation of the different components and separation the codebase in layers for different purposes, described in the classic book "Domain Driven Design". This is already partly done, and in this project I join the existing effort by working on the next remaining subsystem: GHC's Core pipeline. In order to achieve my goal, I will proceed by using an incremental bottom-up approach: Starting at the bottom of the module hierarchy, I will push references to upper layers module-by-module up in the callstack until they are completely removed from each component. For the entry points of each in-scope component, I will then provide component-specific configuration types and corresponding initialization functions. The in-scope components are specific configurable tasks of the optimizer, and the optimizer as a whole. With this work completed, there will be significantly less references to the ubiquitous global states used throughout the whole compiler, namely the DynFlags and the HscEnv type, and significantly fewer imports of modules from upper layers, e.g. the driver.

Rocket.Chat's current message parser uses PeggyJS, which adds bundle size overhead and performance bottlenecks. This project replaces it with a fully hand-written TypeScript recursive-descent parser that produces an identical AST, passes all existing tests, and ships with zero external dependencies. Deliverables include a complete lexer and parser implementation, 100% test suite parity, property-based fuzz testing with fast-check, and a benchmark suite demonstrating measurable performance improvements and reduced bundle size.

<p>TTS is an important accessibility function to compensate for gaming experience for those who have trouble reading text, yet the technology is not widely available to ScummVM engines. This project aims to provide the service by tackling engines one-by-one. It identifies four main scenarios of using TTS: Opening Menu, Story Narrator, Gaming Menu, RPG dialogue, and selects games that have at least one area of the TTS scenario as the target of improvement.</p>

<p>The way I see MIDI working in godot would be to create another type of bus which handles MIDI data. It would probably work similarly to a sampler, by loading a sample library and assigning different sounds to corresponding MIDI messages. The user would be able to assign the midi messages to certain events in their game and when they get triggered the corresponding sample/sound will play. The sampler will essentially be creating something similar an audio bus for each sample and that bus will only play when a corresponding midi message is triggered. All of this will be contained in one track, which will also have all the signal processing features a standard audio bus.</p>

<p>Improve the Stark engine on ResidualVM to make the game menus and character’s shadows working on the game <em>The Longest Journey</em>.</p>

The goal of the project is to integrate the HLP1 engine and Penumbra: Overture in ScummVM. The deliverables for the project are the following: Replace file handling and implement game detection. This step includes integrating the save system and loading assets. Replace graphics functionality. Integrate external libraries. Replace input system and get the game in a working state (without audio). Replace audio libraries. Remove standard library usage.

<p>Currently, re-compiling a Chapel program would mean re-compiling the parts that haven’t changed, including the functions that haven’t been altered since the last compilation. The idea behind this project is to utilise the already existing information that compiler already has to speed up re-compilation. The main steps in the project would be to start away with restructuring the way currently elements with same name are distinguished. The main goal would be to create a code cache which can be stored in as a part of the object file. We would like to utilise our code cache to avoid re-instantiation and recompilation for functions that are already present as a part of the code cache, and finally we want to be able to re-link the correct functions and symbols from the cache during the building of the executable.</p>