Explore Projects

<p>Pointer Authentication is a software security primitive that makes it much harder for an attacker to aggravate attacks targeting arbitrary code execution through malicious manipulation of code and data pointers. This project aims at doing a proof-of-concept integration of pointer authentication into Ibex.</p> <p>The focus lies on integrating pointer authentication into Ibex's processor pipeline. To this end, new custom instructions need to be added to generate and authenticate pointers. In addition, the Ibex system is 32-bit, so we will need to figure out where to store PAC (Pointer Authentication Codes) and how to load them.</p>

<p>The Heavy Flavour AVeraging (HFLAV) group is responsible for collecting and combining measurements made at different High Energy Physics (HEP) experiments, at CERN and other particle physics laboratories, and combining them using robust statistical procedures.</p> <p>The HFLAV website provides a live snapshot of the latest data obtained from these latest publications. This project aims to improve the experience of users using the HFLAV website. These averages could be of greater value to the particle physics community if the accessibility, interactivity and visibility of the current website can be improved. Thus this project seeks to transform user interaction with HFLAV’s ‘Beauty to Charm’ averages.</p> <p>The plan to increase the accessibility is by redesigning the whole user interface, making it easier to find a relevant data point ( branching fraction) by the use of filters. As the old website is static, thus in order to make the site responsive to the user's input, the website will be refactored and the framework will be changed to Django. The application would be hosted using CERN's OpenShift service instead of the older EOS filesystem it was using.</p>

<p>The Human Genetics Clinic of the faculty of Medicine, University of Colombo plays a valuable role in caring for patients. Currently, contributors have finalized requirements for collecting data from patients, and developed appropriate forms to do so. However, the forms would benefit from being upgraded to be more user friendly, and become comparable to the functionality seen on the 'collect vitals' form.</p>

Antibody-Drug Conjugates (ADCs) represent a promising class of cancer therapeutics designed to selectively target cancer cells while minimizing damage to healthy cells. Unlike conventional chemotherapeutic agents, which often cause off-target effects and severe side effects, ADCs combine the specificity of monoclonal antibodies with the potency of cytotoxic payloads. This project focuses on integrating ADC research tools into DeepChem to facilitate computational exploration for researchers. My contributions include developing tutorials and implementing ADCNet, a deep learning framework tailored for ADCs, to bridge the gap between ongoing ADC research and accessible computational tools.

<p>The project will aim to enhance the existing annotation capability and add another type of annotations like dimensions , labels and single or multiple lines notes the idea is to make all kinds of annotation share the same logic in entering the properties of annotation and the graphical representations and taking advantage of the existing primitives like lines and fonts to represent the annotation this will help to exploit the existing capabilities of these primitives like rotation and positioning .</p>

<p>BRL-CAD uses Constructive Solid Geometry (CSG) to create complex objects by combining two or more primitives, with the help of Boolean operators. I propose to improve the performance of Boolean evaluation, by utilizing GPU's to perform the required operations. The challenge is to restructure the code to facilitate parallel implementation.</p>

Currently KubeArmor depends on kernel headers to use various kernel structures. This creates difficulty in having portability. Linux Kernel versions with BTF (BPF Type Format) information available allows us to write portable BPF CO-RE (or Compile Once - Run Everywhere) applications that can run on multiple kernel versions and configurations without any modification or runtime compilation on the target machine. But there is a restriction that CO-RE requires to have the BTF information of the target kernel, which is provided by the kernel itself when it's compiled with CONFIG_DEBUG_INFO_BTF=y. This option was introduced in Linux 5.2. For kernels < 5.2 we can use BTFGen to ship BTF information with KubeArmor code or use pahole to generate BTF information from the vmlinux image (with DWARF information) at runtime. The project aims to make KubeArmor truly portable across all kernel versions by reducing host environment dependencies.

<p>The micro:bit is a small computer for educational use that is also suitable for embedded and Internet of Things (IoT) projects. The micro:bit ecosystems offers various staggered ways of creating programs that run on the computer, including a javascript block editor, a python editor and a c/c++ runtime. This way it enables students and other users to gradually develop and enhance their knowledge about computing. The micro:bit consists of a single pcb which features many I/O capabilities including a 5x5 LED display, 2 buttons, Bluetooth and Nordic Gazell radio communications, an accelerometer, a compass, temperature and light sensing, UART, and GPIO pins for external devices, all connected to the ARM Cortex-M0 based Nordic nRF51822 at its center. Currently there are no means of running programs targeted to the microbit in a emulated environment. The goal of this project is to enhance QEMUs capabilities to being able to load and run code targeted to the micro:bit computer and emulating the aforementioned peripherals.</p>

This project focused on making patient-level prediction (PLP) more practical within the JuliaHealth ecosystem by building some of the missing foundations around OMOP CDM data. The main challenges were around data preprocessing and consistent cohort construction, which are essential before any prediction pipeline can be reliable. To address this, the project delivered two key pieces: first, a standardized Tables.jl interface in HealthBase.jl to make OMOP CDM data easier to work with and preprocess; and second, a new package, OMOPCDMFeasibility.jl, which adds tools for checking cohort feasibility and data readiness. Both were designed to work hand-in-hand with existing JuliaHealth packages like OMOPCDMCohortCreator.jl and OHDSICohortExpressions.jl. Together, these contributions provide a more reproducible, end-to-end path for building PLP models directly on OMOP CDM datasets.

The goal of my project is to add OGC standard of Sensor Things API(STA) to istSOS project. The OGC SensorThings API provides an open, geospatial-enabled and unified way to interconnect the Internet of Things (IoT) devices, data, and applications over the Web. The project aims to extend interoperability and implement some of the basic APIs from STA that could be adopted in a new revised version of istSOS. FastAPI can be used for the request and response of the istSOS STA services. As PostgreSQL is used as the primary data store or data warehouse in istSOS project, data can be managed using postGIS which is a spatial database extender for PostgreSQL object-relational database. PostgREST is a standalone web server that could be used to turn the PostgreSQL database of STA data directly into a RESTful API. Finally the STA service can be integrated with the istSOS project.

Develop distributed edge caching strategies using Web Standard Cache API for sub-50ms storefront responses.

My proposal involves expanding Arti's state management subcommands: hss and hsc (very limited in functionalities at the moment). These new features will be added after the completion of GSoC: a subcommand for listing keys and certificates from the configured keystores; a subcommand for listing keystores by their identifier; a subcommand for performing consistency, validity, and integrity checks on the specified stores; an arti hss destroy subcommand, for removing the persistent state and all the keys of a onion service; an arti hss destroy-and-recreate subcommand, for generating a new identity for an existing onion service; miscellaneous low-level "plumbing" subcommands, which deal with individual files from the keystore and state directories; a C Tor to Arti key migration tool, which will enable onion service operators to seamlessly migrate from C Tor to Arti; field-formatted output to be easily parseable by other programs. These objectives will be achieved mostly by extending already existing facilities, like InertTorClient and OnionService, and by creating new ones.

LLMs rely on floating-point arithmetic for inference, but the Logarithmic Number System (LNS) offers a compelling alternative: multiplication becomes integer addition in the log domain, and 16-bit LNS (xlns16) uses only 2 bytes per element, half the memory bandwidth of float32. This project integrates the open-source xlnscpp C++ LNS library into ggml (the compute backend of llama.cpp) as a proper ggml_backend, enabling LLM inference to run entirely in xlns16 arithmetic as a proof of concept. The implementation introduces GGML_TYPE_LNS16 as a native ggml datatype and implements the 13 operations required for a complete transformer inference pass (matrix multiply, softmax, RMS norm, RoPE, SiLU, residual add, along with some others), all using xlns16 kernels. Activations stay in xlns16 format throughout inference; weights are converted dynamically from their stored quantised formats (Q4_K_M, etc.) per kernel invocation using O(1) lookup tables. The backend is validated at two levels: a unit test confirms sub-0.6% relative error on matrix multiply, and an end-to-end run on SmolLM2-135M-Instruct confirms the full transformer executes without crashing. Deliverables: (1) GGML_TYPE_LNS16 datatype registered in ggml; (2) a complete ggml_backend for xlns16 arithmetic covering all ops needed for LLM inference; (3) integration with llama.cpp; (4) a validation test suite; (5) an accuracy analysis comparing LNS and FP output across model layers

Devfiles are YAML files that define remote development environments. The main part of a Devfile is the `components` section and that's where the containers required to code, build and test an application are specified. The Devfile can either include those containers defintions or reference external files such as Dockerfiles or Kubernetes manifests. [The Compose file](https://github.com/compose-spec/compose-spec/blob/master/spec.md) is a popular format in open source development projects to define runtime environments for testing the application but those cannot be referenced by a Devfile yet. The goal is to continue the work that has been started a couple of months ago to allow referencing a Compose file from a Devfile. The expected outcome is to create a PoC written in go that parses a Compose file such as [this one](https://github.com/microservices-demo/microservices-demo/blob/master/deploy/docker-compose/docker-compose.yml) using [kompose](https://github.com/kubernetes/kompose) (as a library, not as an executable) and that creates the objects corresponding to the Compose file services in a Kubernetes cluster.

Kata Containers is an open source community working to build a secure container runtime with lightweight virtual machines that feel and perform like containers, but provide stronger workload isolation using hardware virtualization technology as a second layer of defense. Expected Outcome: KubeArmor natively protecting Kata containers with required Integration.

DRA (https://kubernetes.io/docs/concepts/scheduling-eviction/dynamic-resource-allocation/) is a new generation device management mechanism for kubernetes. It introduces a new resource request API `ResourceClaim`, which requires kubelet, kube-controller-manager, scheduler, and third-party device management controllers to cooperate with each other to work. The kube-scheduler has implemented corresponding scheduling capabilities, Volcano also needs to implement the DRA scheduling plug-in to integrate the DRA function. Expected Outcome: - A design document describing how to integrate DRA into volcano. - Implement DRA plugin in volcano.

Description: Vitess is a distributed database system built around MySQL. VReplication is core technology built into Vitess that is used to enable many features like vertical and horizontal sharding, change data capture and materialized views. The project involves designing and implementing a customizable framework that enables us to test different VReplication workflows at scale and to obtain benchmarks that can be used to monitor performance improvements and regression from code changes. The framework will consist of a custom DSL (Domain Specific Language) which will be used to define each test case and a driver which will read the DSLs and execute the tests. The DSL will be based on the Hashicorp Configuration Language (https://github.com/hashicorp/hcl). The driver will be written in Golang and target AWS using Terraform for provisioning and Ansible for automation. The results and benchmarks will be stored in PlanetScale (https://planetscale.com/) in the existing vitess benchmark database. Expected Outcome: The test framework with at least one working test and stored benchmark metrics for a MoveTables workflow.

In this project, you will incorporate WasmEdge’s NN (Neural Network) extensions into the Python interpreter. WasmEdge provides C and Rust APIs for guest applications to access host functions in the underlying Tensorflow and PyTorch libraries. You will make those functions accessible from the CPython-based interpreter as Python wrappers. This way, Python applications can do lightweight AI inference on the WasmEdge container. - Expected outcome: * Investigate and list all C-based host function APIs for Tensorflow and PyTorch inference in WasmEdge NN. * Create CPython wrappers for those host functions. * Create high-level Python wrapper functions that are ergonomic for Python developers. * Create CI and demo apps to validate the Python wrapper API. * Create detailed documentation and tutorials.

<p>Apitrace is an open source program that allows tracing, replaying, inspecting and profiling OpenGL/Direct3D calls made by any application. Last summer during GSoC 2015 there was developed an abstract interface that allows to use various profiling backends in Apitrace, also several backends (that use OpenGL extensions) were implemented then. The goal of this task is to provide a convenient interface to the new feature in qapitrace. There already exists a version of profiling view in qapitrace. It has only a limited set of old metrics and it might lack some usability features. This GUI project plans to add new metrics, as well as improving the interface overall.</p>

<p>The aim of the project is to code the linear time algorithm for partitioning a graph into 3-connected components and constructing the corresponding SPQR-tree of the graph. Further, this algorithm can be used as a subroutine for several other graph problems such as recognition of chordless graphs, hamiltonian cycle etc.</p>

This project implements key components of KEP-2170, introducing the Kubeflow Training V2 API. Specifically, it focuses on creating the TrainingRuntime and ClusterTrainingRuntime for the JAX and TensorFlow frameworks, built upon the Kubernetes JobSet API. These runtimes will serve as blueprints for model training (including LLMs) within cloud-native ML pipelines. This abstraction allows Data Scientists and MLOps Engineers to easily reuse standardized runtimes and launch training jobs, particularly via the SDK, without needing deep knowledge of underlying Kubernetes complexities.

The Oppia Android app is missing three features that the web platform already has. Learners have no idea how far they are in a lesson, revision cards are a flat wall of text with no structure, and worked examples in concept cards are completely invisible. This project adds all three. First, a checkpoint based lesson progress indicator that uses the is_checkpoint state property to show learners their progress as X of N through an exploration, with correct behavior during backward navigation, flashbacks, and checkpoint restoring. Second, structured study guides that replace the flat revision card with a sectioned RecyclerView showing headings and content blocks. Third, a worked example tag handler that parses nested HTML inside oppia-noninteractive-workedexample tags and renders inline Question and Answer blocks using styled spannables. All three features are independently gated behind feature flags and built on top of existing infrastructure.

Jaeger UI is built on React. While we are seemingly already on v18.x of React, the upgrade was not done across the board and some other dependencies are still lagging behind, e.g. `"@types/react": "16.8.7"`. It's also blocking upgrades of other dependencies. This project is likely to involve a substantial amount of code contribution, as certain upgrade require fixing the code to use the new APIs, and sometimes we may run into dependencies that are EOL and need to be replaced altogether. - Expected Outcome: Ideal outcome is to have _all_ dependencies upgraded to the latest versions (with the help of @dependabot) and fix all deprecation warnings during the build. But incremental progress towards that goal is also acceptable.