Explore Projects

<p>For decades CPUs did not have hardware floating point support. Floating point was implemented using using bit twiddling operations and integer math. This applied to both single and double precision. Starting with GLSL 1.30, GPUs have all of the necessary bit twiddling operator and integer math to do the same thing. GPUs natively support single precision, but only OpenGL 4.0 class GPUs have hardware support for double precision. The goal of this project is to implement a library of double precision operations in pure GLSL 1.30.</p>

<p>The Apache open-source-project <a href="https://brooklyn.apache.org/" target="_blank">Brooklyn</a> is a multi- cloud application management platform. Brooklyn can manage the provisioning and deployment of cloud applications, can monitor applications’ health and metrics, and handle the dependencies between components. It enables cross-computing features through a unified API built over <a href="https://jclouds.apache.org/" target="_blank">jClouds</a> to manage IaaS services offered by various providers. The tool offers a REST API and a GUI that enables a single-click deployment of applications across multiple machines, locations and clouds.</p> <p>As it was aforementioned, Brooklyn provides an API for the management of IaaS cloud services and ssh resources for a great number of providers and establishes a lifecycle for the management of services and applications. This project propose to extend this API with facilities for the management of PaaS offerings such as <a href="https://cloud.google.com/appengine/docs" target="_blank">Google App Engine</a>, <a href="http://aws.amazon.com/" target="_blank">AWS services</a>, <a href="https://www.heroku.com/" target="_blank">Heroku</a>, <a href="https://www.cloudfoundry.org/" target="_blank">CloudFoundry</a> (such as <a href="https://run.pivotal.io/" target="_blank">Pivotal</a> or <a href="https://console.ng.bluemix.net/" target="_blank">Bluemix</a>) , <a href="https://www.openshift.com/" target="_blank">Openshift</a>, etc., providing an homogeneous access to IaaS and PaaS services. Moreover, it opens up some interesting proposal such as adding new technologies support, e.g., Python, PHP and adding new management policies in order to take advantage of PaaS features.</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>XaoS currently cannot support very deep zooms because the 80-bit floating-point arithmetic used runs out of precision before too long. It should be possible to add arbitrary precision to XaoS using the MPFR library ( <a href="https://www.mpfr.org/" target="_blank">https://www.mpfr.org/</a>), or a different one if it is not fast enough to support real-time zooming. The second part of the project focuses on rendering very large size images to support high-quality output. Support for various colour profiles, batch output, cropping, and the cartesian grid will be added along with this. Additional improvements to XaoSjs and support for web compilation of XaoS will also be carried out.</p>

<p>Cytoscape.js is a graph theory and networks library focused on providing built-in, rich and performant graph models for analysis and data visualization. This project aims at expanding Cytoscape.js’s data analysis functionalities by offering several of the most commonly used clustering algorithms, including the k-means, hierarchical, affinity propagation, Markov cluster algorithms and more, via extensions that can be easily incorporated into the default library. Such extensions, written in a user friendly and accessible manner, will help expand the usage of Cytoscape.js, as clustering algorithms are applicable in a wide variety of fields, from bioinformatics to machine learning, data science, etc.</p>

<p>This project aims at adding support for Redis to be used as a caching backend with Django. As redis is the most popular caching backend according to the django developer survey of 2020, adding it to django.core.cache module would be a great addition for the developers who previously had to rely on third party packages for this functionality.</p>

GnuCOBOL currently has no support for the Object-Oriented Programming (OOP) features defined by the ISO standards ISO/IEC 1989:2002 through ISO/IEC 1989:2023. Object-Oriented (OO) code currently leads to syntax errors due to lack of parsing support. The project aims to build support for parsing all OO syntax, and for a subset, also implement AST and codegen support to get a minimal working prototype of calling class methods through objects. Support for complex OOP features like method overriding and single inheritance will also be implemented. Multiple inheritance, method prototypes and parameterised classes are excluded for now. As a result, future releases of GnuCOBOL 3 will be able to parse OO code and report a simple error message about the pending feature. GnuCOBOL 4 will introduce the new paradigm to users. It will be able to generate working binaries for OO code and handle complex features like method overriding and single inheritance. The project will help bring GnuCOBOL closer to being compliant with ISO standards for OO COBOL and establish it as a significant choice among institutions looking for a free COBOL compiler with OOP support.

Currently, during an IKEv2 negotiation in Libreswan, each peer independently selects its authentication method without knowing what the other side supports, which can lead to SA establishment failures when peers are configured with multiple credentials. The goal of this project is to implement RFC 9593, which introduces the SUPPORTED_AUTH_METHODS notification to allow peers to announce their supported authentication methods during SA establishment, enabling Libreswan to adjust its authentication selection to a method both sides support. The deliverables include: New ipsec.conf configuration option. Modifications to emit and parse SUPPORTED_AUTH_METHODS notification across IKE_SA_INIT, IKE_INTERMEDIATE, and IKE_AUTH exchanges. Modifications to select the applicable authentication method based on the peer's announced capabilities. Additions to the test-suite.

<p>Currently CritiqueBrainz’ users can review release groups, events, and places. This will be expanded on by implementing reviews for other MusicBrainz entities (works, artists, recordings, labels). This metadata will be retrieved from MusicBrainz through the mbdata module, and the CritiqueBrainz back-end and the front-end will be extended to support reviews for these entities.</p>

This proposal aims to address the lack of support for histogram charts and other advanced chart types introduced in Microsoft Office 2016 within LibreOffice. Histograms are essential for data analysis, scientific research, and machine learning, providing valuable insights into data distribution. Currently, LibreOffice users rely on some clunky workarounds to create histograms, limiting productivity and compatibility with industry standards. The goal is to implement native histogram chart support in LibreOffice, eliminating the need for workarounds and enhancing the user experience. By leveraging the existing column chart implementation as a starting point, the project will gradually transform and extend the code-base to support histogram-specific functionality. This approach minimizes disruption to the stable code-base while introducing new capabilities.

<p>Due to increasingly complex coupling problems in engineer fields, it is significant to provide supports for co-simulation with other software in MBDyn. In this project, to achieve co-simulation with another open-source multibody software, Chrono::Engine (C::E), which has advantages in dealing with non-smooth multibody dynamics, a user-defined run-time loadable module is provided as a template. The template includes a module, applied to one or a cluster of nodes in MBDyn and receive forces resulting from objects in Chrono::Engine.</p>

This proposal is about adding IPP-Scan support to go-mfp, OpenPrinting’s Go toolkit for multi-function printers and scanners maintained by Alexander Pevzner. Right now, go-mfp has solid IPP support for printing and a full eSCL implementation for scanning (WS-Scan is also being added). But there’s no IPP-Scan support yet, and that’s a gap. IPP-Scan (defined in PWG 5100.17) is the open standard for driverless scanning over IPP. It’s what Scanner Applications need to move away from the current eSCL-based approach. I’m proposing to build both a client and a server for IPP-Scan - the client for testing PAPPL scanner apps, and the server as a reference implementation that will also help with developing a future SANE backend for IPP-Scan.

Kmesh, as a high-performance service mesh data plane, is now only supported for use in a single cluster. However, now that multi-cluster support for istiod has been realized, we are able to move forward with the multi-cluster adaptation of Kmesh to support the use of Kmesh in multi-cluster environments. Adaptation to the current multi-cluster production environment with LLM and large data. - Expected Outcome: - 1.Code for implementing the Kmesh multi-cluster feature - 1.1. Adapting to the Istio Multi-Cluster Function API - 1.2. Traffic Management in multi-cluster scenarios - 1.3. Use IPsec to ensure the security of node communication. - 2.userguide doc - 2.1. proposal - 2.2. userguide - 3.e2e test - 3.1. Unit Test of Feature Function - 3.2. E2E test code

<p>This proposal aims to add call hierarchy support in Haskell Language Server(HLS).</p> <p>Language Server Protocol(LSP) has <a href="https://microsoft.github.io/language-server-protocol/specifications/specification-current/#textDocument_prepareCallHierarchy" target="_blank">supported</a> call hierarchy in 3.16, which make us implement it in HLS possible.</p> <p>Inspired by <a href="https://github.com/haskell/haskell-language-server/issues/738" target="_blank">this issue</a>, my proposal involves the following steps this summer to contribute to call hierarchy:</p> <ol> <li><a href="https://github.com/haskell/lsp" target="_blank">LSP</a> spec support.</li> <li><code>prepareCallhierarchy</code> implementation.</li> <li><code>incomingCalls</code> implementation.</li> <li><code>outgoingCalls</code> implementation.</li> <li>Test</li> </ol> <p>I hope I can contribute to HLS to go further this summer.</p>

<p>The “Affiliates Connects” module provides an interface to easily integrate with affiliate APIs or product advertising APIs provided by different e-commerce platforms like Flipkart, Amazon, eBay etc to fetch data easily from their database and import them into Drupal to monetize your website by advertising their products.There are some functionalities this module is going to provide like : 1. It provides developers to leverage its functionalities by providing their own plugins e.g. affiliate_connect_example module to fetch data from example website. 2. It provides scraper as a fallback fetcher 3. An inline browser to choose products from different e-commerce sites and help them to embed the selected products to the field. 4. Handling Affiliate URLs by adding Affiliate-tracking Id to products URL. 5. Cloaking Affiliate URLs to hide the user’s Affiliate-Id. 6. Count and record the hits on the Cloak links. 7. Generate the report based on the count of cloak links. 8. Provide an option to open affiliate links in new tab or not.</p>

My proposal is to resolve a number of outstanding bugs with WebGL functionality in p5.js, as well as expand on the documentation and tests for that functionality. While the WebGL components of p5.js are increasingly robust, there are a number of open issues that point towards some unexpected behavior and a lack of documentation around certain features. There is also the challenge of structuring the WebGL functions in a way that achieves parity with the p5.js approach to 2d rendering. There are a number of bugs that I would like to resolve, including #5455, #5631, and #5440. For documentation, it seems necessary to make certain additions to better orient developers who are new to 3D graphics and shaders, including graphics quirks that go beyond p5.js, such as the depth sorting challenges mentioned in issue #5420. I would also like to contribute documentation that helps users better understand the structure of WebGL in p5.js, information that is currently only available within the contributor documents. Additional examples would also be helpful for topics like setting up an effects chain or for achieving certain effects such as feedback.

<p>Despite being the go-to library for point cloud based computation, PCL can cause some friction to users due to its old-fashioned and sometimes inconsistent API and the lack of certain features. This proposal aims to introduce the following new features to the PCL library;</p> <ul> <li>GPU implementation of Iterative Closest Point (ICP) algorithm</li> <li>Implementation of Fast Resampling of 3D Point Clouds via Graphs</li> </ul> <p>As well as to refactor and modernize the library by means of;</p> <ul> <li>Introducing better type for point indices, thereby providing support for larger point clouds</li> <li>Introducing a fluent API for algorithms</li> <li>Modernising the GPU Octree module to align with the it’s CPU counterpart</li> </ul>

The Mission Support System (MSS) client currently lacks the ability to save and restore view configurations, requiring users to manually recreate complex window layouts each time they reopen the application. Additionally, collaborative operations do not support sharing view configurations among participants, hindering real-time coordination. To enhance the user experience and collaboration in the Mission Support System (MSS), this project will introduce two major improvements. First, it will implement a local and server-side view restoration system, allowing users to save and reload their window layouts automatically. This will be achieved through JSON-based storage for local configurations and database integration for server-side persistence. Users will have the option to enable or disable view restoration via a new setting, ensuring flexibility. Second, the project will introduce a collaborative view-sharing feature through a dedicated "Manage View" widget. This will enable participants in an operation to share, browse, and load predefined layouts, ensuring consistency during joint missions. The widget will integrate with MSS’s existing operation system, allowing real-time updates via WebSocket notifications. Backend APIs will handle secure storage and retrieval of shared views, while the frontend will provide an intuitive interface for managing layouts. Together, these enhancements will eliminate the need for manual reconfiguration and streamline teamwork in mission planning and analysis.

Modernize fs_filepicker: The fs_filepicker is a GUI used for selecting files in the msui_settings.json configuration file. Currently, the GUI only offers a basic set of navigation elements for selecting a file and returns the fs URL for accessing it. The goal of this project is to modernize the GUI using the Pyfilesystem module to make it more user-friendly and efficient. Pyfilesystem is a Python module used for accessing different types of file systems. It provides a common API for working with various file systems, such as local, remote, and cloud-based storage systems. The Pyfilesystem module is easy to use and has many features that can be used to improve the functionality of the fs_filepicker. View Layout and Restoring:: The mscolab project is a collaborative software platform that enables multiple users to work together on a shared project in real-time. The project is written in Python and uses the PyQT GUI library for the user interface. Currently, the PyQT Gui of the MSS client can handle different views by one flight path. However, once a new flight path is loaded and activated, all views change to this flight path. This is inconvenient for users who want to work on multiple flight paths simultaneously. Additionally, the view configuration consists of many windows with a complex set of configuration options that are tedious to re-create after shutting down the application. This proposal aims to improve the mscolab user interface by adding the ability to store and restore the view configuration of multiple windows for the user. Additionally, the proposal seeks to add a layout option for any participant on the same flight path, as well as the ability for the creator of an operation to set the layout of all participants.

This project aims to deliver comprehensive, end-to-end non-uniform grid support for MethodOfLines.jl. Currently, basic advection schemes lack graceful error handling for ill-posed boundary conditions, and advanced high-order schemes (specifically WENOScheme) completely lack non-uniform method dispatch, leading to fatal compilation errors on irregular domains. The proposed solution utilizes Julia's multiple dispatch to route non-uniform grids to a newly developed, isolated mathematical weight calculator within the WENO module, ensuring zero breaking changes for existing uniform grid users. Key deliverables include refactored basic advection schemes with robust well-posedness validation, a native non-uniform WENO implementation featuring dynamic smoothness indicators and negative weight regularization, rigorous L₂ convergence tests, performance benchmarking, and comprehensive documentation to enable highly precise real-world physics simulations.

ARM64 is becoming increasingly common with the rise of Apple Silicon and cloud instances like AWS Graviton, but Kubeflow still doesn’t run consistently on ARM-based systems. Right now, different components behave differently — some work partially, some require manual fixes, and others don’t work at all. This makes it difficult to use Kubeflow reliably outside of traditional x86 environments . The goal of this project is to make ARM64 a properly supported architecture across the Kubeflow ecosystem. Instead of partial or experimental support, the idea is to make sure Kubeflow works the same way on ARM as it does on AMD64. To achieve this, I plan to start by auditing the container images used in Kubeflow and identifying gaps in ARM64 support. Based on that, I will enable multi-architecture builds using Docker Buildx and integrate them into existing CI/CD pipelines so that ARM64 images are built and published automatically. I will also update manifests to remove architecture-specific references and ensure they work across both architectures without requiring changes. A major part of the work will be validation. I will deploy Kubeflow on ARM-based environments (OCI Ampere) and run end-to-end tests to catch issues that only appear at runtime. Any failures related to dependencies, builds, or configuration will be debugged and fixed incrementally. By the end of the project, Kubeflow should be able to run end-to-end on ARM systems without manual workarounds. The final output will include working multi-architecture builds, improved CI/CD pipelines, updated manifests, and a clear “golden setup” guide for running Kubeflow on ARM. Overall, this project is about making Kubeflow more consistent and usable across modern infrastructure, especially as ARM adoption continues to grow.

This project aims to create OOT module, that uses CyberEther's GPU-accelerated framework which uses low-level graphics APIs to create high-performance sinks to visualize GNU Radio data streams in a normal GRC workflow. current implementations of these sinks rely on `gr-qtgui` which is fine but it would be a better to have the option of choosing CyberEther sinks which would be more optimized for maximum throughput and low latency along with a modern design. Main challenges are: minimizing data movement from the GR scheduler to CyberEther tensors, as in high sampling rates unnecessary copying would be expensive and undermine whole native performance edge. Also, CyberEther's current public plotting path internally manages a shared runtime built around `Jetstream::Instance`, and a normal GNU Radio flowgraph can have multiple sinks which would be tricky to manage safely. My core implementation target is a robust first sink family around lineplot and waterfall, with spectrogram support in the second half of the project if the lower-level CyberEther path is needed. These challenges(and other) can be resolved by architecting new solutions which borrow from past implementations namely `gr-cuda` for custom buffers, `gr-cyber` (an earlier prototype from Luigi, the creator of CyberEther) and `gr-fosphor` for relevant challenges.

This projects aims to complete the support for Constant Folding in GCC Rust frontend. It will do so by finishing the already started constant folding port from GCC C++ frontend. It will help gccrs to: - Evaluate const functions. - Specify static array size using const expressions. - Check for overflows. - Support const generics in Rust >= 1.50.0. The current port in gccrs has the following issues which will be fixed as milestones for this project: - Evaluation of non-const expressions inside const expression is not handled properly. - Argument binding for const functions is not supported. - Arithmetic Overflows are not detected. - Constant functions with complex bodies containing conditions and loops are not handled properly. Fixing these issues above will complete the support for constant folding and help the areas which need it in gccrs.