Explore Projects

`cabal check` is a tool to check the correctness of a `.cabal` file and more generally to provide more useful output (warnings, especially related to uploading the package to Hackage). As now `cabal check` is an imprecise tool, outputting spurious warnings on well formed `.cabal` files. The mistakes become more and more annoying the more complex your package is (compilation flags, etc.). Picking up an AST, transforming it appropriately and *traversing* it is the only way to practically solve these problems. This proposal aim to do so.

<p>GHC builds up a wealth of information about Haskell source as it compiles it, but throws all of it away when it's done. Any external tools that need to work with Haskell source need to parse, typecheck and rename files all over again. This means Haskell tooling is slow and has to rely on hacks to extract information from GHC. Allowing GHC to dump this information to disk would simplify and speed up tooling significantly, leading to a much richer and productive Haskell developer experience.</p>

<p>GHC is an industry-strength compiler for Haskell. I am proposing to add primitives that allow more efficient operations involving immutable <code>(Small)Array#</code>s, the underlying primitive building blocks for many popular data structures, such as <code>unordered-containers</code> (the go-to hash map library). I will improve efficiency by removing unnecessary initialisation steps that are needed for safety when these operations are implemented in library code.</p>

<p>Testing software is essential. As a project gets bigger, the difficulty of testing the interactions of all its components increases. Property based testing, with libraries like QuickCheck and quickcheck-state-machine, seems to counter this problem. In this project we will use these libraries to test stateful code, with a main focus on parallel programs and programs with injected errors. The target is to benefit the whole Haskell community by providing guides, template examples and improving the api and functionality of these testing frameworks.</p>

<p>Stylish-haskell is a code prettifier that formats Haskell programs relying on the haskell-src-exts library to parse the Haskell code into an AST. Since this library is not actively maintained it needs to be replaced with another library that allows to keep up with the de-facto standard compiler: GHC. The parsing library ghc-lib-parser packages the parser from GHC itself, and as such, is always up to date. The project mainly aims to do the port to ghc-lib-parser, eventually also introducing improvements. The project will guarantee the continuity of the package stylish-haskell, allowing users to keep benefit from it.</p>

<p>This project aims to ensure that all the grammar rules defined are exposed to the AST(Abstract Syntax Tree) level.<br> ‣ Basically working on Lexical and Syntax Analysis (Two phases of the Compiler Design).<br> ‣ Some grammar rules were not defined in the parser. After adding them, created AST nodes related to those grammar rules, defined macros, used them in the parser to expose those nodes to the AST level.<br> ‣ Parse Comments, Semicolons, and Newlines in the Fortran code. Preserve them in the AST, and print them using fmt(Subcommand).<br> ‣ Add tests for each implementation to make sure everything works correctly as expected.</p>

<p>Hadrian seeks to replace GHC’s current Make-based build system some time around GHC 8.8, but since the main goal of Hadrian so far has been to achieve feature parity with the old build system, there hasn’t been as much of a focus on speed, which means there are likely many optimisations that would significantly and appreciatively increase performance. Right now the main problem is a lack of parallelism, with the primary bottlenecks being configure and compiling stage 0. This project aims to identify the causes of the bottleneck in stage 0, as well as looking for other sources of slowness in Hadrian and Shake using profiling, and deal with them to improve Hadrian’s performance as much as possible.</p>

<p>The goal is to continue on an ongoing work, utilising the Trees that Grow technique, to introduce native-metaprogramming in GHC. Native-metaprogramming is a form of metaprogramming where a metalanguage's own infrastructure is directly employed to generate and manipulate object programs. It begins by creating a single abstract syntax tree (AST) which can serve a purpose similar to what is currently served by Template Haskell (TH), and the front-end AST inside GHC (HsSyn). Meta-programs could then leverage, much more directly, the machinery implemented in GHC to process Haskell programs. This work can also possibly integrate with Alan Zimmerman’s work on compiler annotations in GHC, and enable a better IDE support.</p>

The problem we are trying to solve is, developers struggle to analyze massive CI test logs, especially for rare intermittent failures. This project tackles this by building a Haskell web tool. In phase 1, it leverages an existing service (spuriobot) to collect test log data and stores it in a full text search database. In Phase 2 we have three options to do, but we’ll try to work on all three. So Phase 2, focuses on improvements based in the web UI on user feedback. This UI will allow searching by keywords or test names, with clear results including timestamps and failure messages. Also, it will automatically insert logs from github workflows action. Last part includes spurious failure analysis, which utilizes the tool to analyze test log data in GHC to identify patterns and root causes of intermittent test failures (or characterizing spurious failures).

LiquidHaskell is a verification tool that allows Haskell developers to prove the correctness of their code through refinement types. This proposal aims to restore the support for type class elaboration: a feature that enables the verification of typeclasses laws and instances. The work that had been done previously to support typeclass elaboration is currently broken: typeclass methods produce "Unknown logic name" errors, hence the test suite for the feature has been disabled. The aim of this project is to restore this functionality, by fixing the elaboration mechanism responsible for making typeclass methods available during verification. I will trace the elaboration pipeline, implement the necessary fixes and extend test coverage. Additionally, the project will include an in-depth analysis of the features supported by the implementation and how they compare against the expected outcomes in the original paper. The deliverables will include successfully merged contributions on the LiquidHaskell GitHub repository, with its corresponding documentation, and a post with the solution on the Tweag blog.

<p>Practically speaking, in science, engineering, and statistics, most computations are done numerically. My project aims to implement a library that can solve for Chebyshev polynomials. For complex mathematical functions, Chebyshev polynomials allow us to compute perform operations such as differentiation, integration, and solutions of ODEs with both greater speed and the same numeric accuracy as when dealing with the original functions. In this project, I hope to implement a Chebyshev polynomials module, along with the appropriate documentation, residual functions to validate the approximations, and test cases. The functions associated with the Chebyshev polynomials will be able to be used alongside the rest of the existing hmatrix library. I will also integrate the Accelerate language, an embedded language built to allow high-performance parallel arrays for Haskell. This library naturally fits into this project, because it allows for quick computations on large multi-dimensional arrays. Numerical algorithms are often used to solve large systems of equations, that are easily converted into large matrices of data.</p>

This proposal describes the plan and research I have done to make the packages in Fortran Ecosystem FPM compatible. I have described in detail how I am going to take the help of Fortran Community on Discourse for helping me in decision making and the metrics on which I will prioritize which packages to make compatible with fpm first. I have also put forward in detail the packages that I have researched on Github, Gitlab and other code hosting platforms that interest me and that I think should be made fpm compatible by looking at what we currently have in Fpm Registry. So, for this, I have also created a tentative timeline with a brief overview of my plan during the pre-GSoC, Community Bonding, and Coding Period. It also describes in detail my commitment to the program and my programming background as well. Goals of Projects : 1. Made packages from different domains like Command-Line Parsing, General Purpose Libraries, Command Line Parsing, and much more compatible with Fortran Package Manager. 2. Collaborate with maintainers of the packages which are to be made available on the fpm registry. 3. Interact with Fortran's open source community on Discourse and ask for suggestions and feedback while working on the project.

<h3>Improvements to GHC's Code Generator</h3> <h4>Improved code layout</h4> <p>In the current approach there is no way to incorporate additional control flow information</p> <p>We improve on that by constructing a CFG, assigning weights to its edges via static analysis and finally using these weights for code layout.</p> <p>A more detailed description is available on the wiki page of the GHC project. At the time of writing the write up is <a href="https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/CodeLayout" target="_blank">here</a>.</p> <p>Initially not viewed as a major task evaluating this change took up most of this Project.</p> <h4>Support for conditional move instructions</h4> <p>This has been partially implemented but requires further work before it can be used.</p> <h4>Add support for lookup tables</h4> <p>Dropped in favour of code layout work.</p> <h4>Invert FP comparisons such that the parity check can be eliminated</h4> <p>By selectively inverting comparisons we avoid an explicit parity check.</p>

<p>Inevitably new and prospective Haskell users will attempt to obtain editor/IDE integration for Haskell but unfortunately they are much more likely to fail than to succeed due to the less than ideal state of the tools.</p> <p>Haskell downstream tooling is simply in a bit of a bad place at the moment. Things have always moved fast in GHC land but recently things got a lot worse for tools when the release frequency increased from every-two-years to every-six-months.</p> <p>As if that weren't enough, Cabal -- the main Haskell build tool -- is almost ready to switch over to the long awaited Nix-style new-build commands. This switch brings with it a major change to how tooling has to interact with the build system.</p> <p>Bad tooling is a major source of frustration for new and experienced Haskell users alike. This proposal will substantially improve the reliability, performance and maintainability of tooling efforts.</p> <p>This proposal consists of three main areas:</p> <ol> <li>Improvements in GHC to reduce friction for downstream tooling efforts</li> <li>Work on cabal-helper to enable easy new-build support</li> <li>Integration of the above into Haskell IDE Engine</li> </ol>

The hardware necessary to build networks, sensors and computers of quantum nature is at its infancy. Potential quantum memories, repeaters, and switches are being researched all over the world, and the quantum hardware race has started. Therefore, a need for efficient, functional, and accurate open-source quantum networking modelling tools has never been more imminent. Projects such as Julia’s QuantumClifford.jl enable researchers across the globe to research various aspects of quantum networking while anticipating the creation of the necessary hardware to produce laboratory experiments. They present cheap and efficient environments to start building potential switch, protocol, and network designs. In classical computing, if one wants to protect a bit against errors, it can often suffice to represent that bit by a logical bit by repeating the data bit. Nevertheless, in a quantum setting, that type measurement is much more complex. Quantum qubit theory along with quantum noise present one of the most challenging problems that the quantum information field must overcome to become scalable and profitable: How to account for the error correction, needed due to quantum noise, in quantum gates? Simulators, such as Julia's Clifford gate simulator, must mimic not only the behaviour of quantum noise, but also the effects of currently proposed quantum error correction codes. For this reason, this project proses a comprehensive library of frequently used quantum error correcting codes for Julia’s simulator of Quantum Clifford Circuits. These would include the Steane, Shor, and Toric codes, as well as other Surface and CSS quantum error correction codes.

<p>Implement game engine developed by S.K.I.F targeting original versions of Red Comrades 1: Save The Galaxy (1998) and Red Comrades 2 : For the Great Justice (1999).</p>

We have to adapt a copy of the rustc testsuite to make use of the error code framework implemented in gccrs as part of GSoC 2023. We need to develop a test case runner similar to rustc's one, in order to match error codes and line numbers to the output of gccrs. Specifically, we need to ensure that gccrs is emitting the correct error code consistent with rustc-1.49. This project requires investigating the current test framework of gcc/gccrs (dejagnu) and also the official rustc one. The main exact goal of this project is to have access to a tool which enables us to run gccrs on the rustc test cases and assert that we emit the correct error codes/messages w.r.t to their line numbers. Furthermore, the extended deliverable of this project is to integrate this tool in gccrs CI/CD pipeline.

QuantumClifford.jl provides a basic functionality for quantum error correction. Yet, some important classes of QECCs and their decoders remain to be implemented, particularly those developed recently, e.g., asymptotically good quantum low-density parity-check (QLDPC) and bivariate bicycle codes. During the GSoC, i.e., JSoC for Julia, we aim to incorporate them into the QuantumClifford.jl ecosystem. To this end, we will add the following new features: new QECCs (concatenated quantum code, random Clifford circuit code, and a selected set of QLDPC codes), new decoders (BP-OSD, mismatch decomposition decoder, and linear-time decoder for lifted product codes).

Create a simpler desktop application where there is a simple channels list on a little window and each chat will open in another separated window, making it possible to talk with people without opening a big window. Making the usage of Rocket.chat more seamless. This project will make extensive use of Rocket.Chat's In-App Chat APIs (REST APIs). The application will be deployable on all platforms supported by Electron - Windows, Mac, Linux, and more

The project aims to implement a High-level library for HTTP requests. The library would allow Fortran programmers to make all standard HTTP request methods (GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE, and PATCH). This project will use fortran-curl, a set of Fortran bindings to libcurl, under the hood. The outcome of this project is that consuming HTTP web services from Fortran applications would become significantly easier than ever before. Expected outcomes: Implemented a minimal but working capability to make HTTP requests from Fortran and parse data from the response body and headers

<p>The aim of the proposed project is to improve support for the Dhall language in mainstream editors via the Language Server Protocol standard.</p>

<p>This project attempts to improve the native code generator of GHC by adding support for Intel AVX and SSE SIMD instructions. This support would enable GHC to expose a bunch of vector primitive operations, which can be utilized to by various high performance and scientific computing libraries of the Haskell ecosystem to parallelize their code for free.</p>

<p>The Haskell Language Server is a popular, comprehensive Haskell IDE; however, it is yet to implement a core feature: symbol renaming. With the recent addition of HieDB (a database for references in Haskell code), there is sufficient infrastructure to implement this feature.</p> <h3>Problem Benefits</h3> <p>Having an accessible renaming feature could encourage improving names, leading to clearer naming across the Haskell community. Renaming is especially useful in Haskell since short names are common, meaning they are often reused and difficult to disambiguate when renaming manually.</p> <h3>Project Aims</h3> <pre><code> - To support workspace-wide renaming of all names, including type synonyms, data constructors, and functions. - To support renaming of qualified imports. </code></pre>