Explore Projects

The platinum open access overlay neuroscience journal - Neurons, Behavior, Data Analysis, and Theory – NBDT is ready for inclusion in PubMed Central (PMC). However, PMC requires full-text machine-readable XML article file deposits. These files contain the complete article text in machine-readable language, with front-matter metadata. At the moment, final paper submissions to NBDT are in LaTeX format. While there are tools that provide LaTeX to XML conversion (as required by PMC), no single tool does it seamlessly without errors for the template corresponding to NBDT. The current project aims to build an application providing this functionality. The project will build over the LaTeXML tool to enhance custom bindings as required for NBDT submissions. The first step would be to enhance the bindings for body matter, as Scholastica (which hosts NBDT) already provides it for front-matter binding. In addition, to make the application platform-independent, it will be extended to provide custom front-matter and back-matter bindings. It shall also contribute verification engines to automate XML verification, JATS verification, and PMC-specific verification. The application shall make it convenient to bridge NBDT submissions and the PMC archival process.

<h4>Abstract</h4> <p>The actual Arduino IDE, was initially created with <a href="https://www.java.com" target="_blank">Java</a> and is still a simple IDE that does not provides autocompletion, sentence errors, assembly visualizer, field for compiling and linking flags, syntax highlighting and other features present in both <a href="https://www.kdevelop.org/" target="_blank">Kdevelop</a> and <a href="http://www.qt.io/ide/" target="_blank">Qt Creator</a></p> <p>Some developers and <a href="http://www.hackvandedam.nl/blog/?p=762" target="_blank">educators</a> say that Arduino IDE isn't as good and comfortable as a development ambient for higher education and development. In order to the to fix this situations, the development of Arduino plugins for KDevelop, Qt creator, Visual Studio and Eclipse began, but generally the setup for such plugins is complicated and it's necessary a good understanding of these IDEs and OS's ambient functionality.</p> <p>The main goal of this proposal is to add a native support to KDevelop with embedded systems, such as Arduino and ARM processors. Using <strong><em>avrdude</em></strong>, <strong><em>OpenOCD</em></strong>, <strong><em>GDB</em></strong> and other tools that are used in development of embedded systems.</p>

This project develops a high-precision, clinically viable pipeline for segmenting Coronary Artery Calcium (CAC) from non contrast cardiac CT scans using the Stanford COCA dataset. The core innovation is a Hybrid 3D U Net architecture that balances the local inductive bias of CNNs with the global context of Transformers, specifically optimized for the extreme sparsity of calcified lesions. The architecture integrates 3D Deformable Attention to bypass O(N^2) scaling and CoordConv for anatomical grounding, effectively suppressing false positives from osseous structures like ribs. A primary research contribution is the experimental Fourier Neural Operator (FNO) bottleneck, which tests the hypothesis that calcified plaques can be isolated as high-frequency signals in the spectral domain. To ensure clinical utility, the model is trained using Scoring-Driven Consistency (SDC) a differentiable volume score loss that aligns optimization with the Agatston metric. Deliverables include a MONAI based preprocessing pipeline, a rigorous benchmark against an nnUNet gold standard, and a fully automated Agatston scoring engine for risk categorization (0, 1–99, 100–399, ≥400). This work aims to bridge the gap between architectural novelty and real world diagnostic accuracy for cardiovascular risk stratification.

The current FreeBSD environment lacks robust automated testing for Rust kernel modules and officially maintained Rust drivers. Past projects for Rust in FreeBSD started with Johannes Lundberg's Master's Thesis, where he created a RustKPI, e1000 Rust Network Driver, and a Rust kmod Hello World Example. From this, we saw Anatol Ulrich create a Hello World kernel module and a research article about writing FreeBSD kernel modules in Rust by David Young. Outside these contributions, Rust's current progress in FreeBSD is very shallow. This lack of depth makes it difficult for others to learn and build upon. I propose to analyze and extend the past work of others to assist anyone wanting to further the development of Rust in the FreeBSD kernel. My project will focus on these primary goals: 1. Creating tests in /usr/tests tree using ATF & Kyua for an existing Rust Driver 2. Use these tests to find errors in the driver logic, repairing them when needed. 3. Create a updated environment where developers can easily code and compile Rust FreeBSD device drivers. 4. Create both a Hello World driver and an Echo character driver with this environment. 6. Publishing clean and effective Rust device driver documentation for future developers to expand and work with the environment.

Background: Current flows from RISC-V Sail specification to downstream implementations have manual steps which are time-consuming and can introduce errors.A lack of familiarity with Sail and OCaml presents a barrier to adoption of Sail as the basis for automated downstream implementations: emulators, simulators, compilers, assemblers, disassemblers, instruction stream tools, documentation, etc. Proposal: - Create an accessible Sail backend. - Extract salient information. - Transform it into an accessible database (JSON). - Survey projects dependent on RISC-V ISA for how that dependency is realized. - Utilize JSON to directly and automatically generate downstream source that is currently generated by hand. - Create a React-based interactive RISC-V ISA reference by directly importing the JSON database. Benefits: The backend can serve as a model for creation of additional Sail backends. The JSON database itself may be sufficient for many downstream uses. Creating downstream source shows feasibility, and a process for a fully-automated downstream flow. Additional collaboration with the effort to transform Sail into documentation is warranted. Much of the effort to transform Sail into JSON is complete, but there is still significant effort ahead: - enhanced parsing - enhancing the RISC-V Sail specification itself with more required content Much of the effort in creating an interactive web site is complete, but there is work to support the incorporation, display, and filtering.

Current Frontier LLMs are really bad at assisting with writing JAX code due to the sparse resources spread across multiple different forums and platforms which are often inacessible/unscrapeable (such as discord) by conventional search engine indexers or web scrapers. Thus they usually do not make it into the final pretraining datasets, hurting frontier models' performance on those frameworks. I want to fine-tune OSS models on JAX code, where the data is manually scraped/collected by hand from diverse sources like YT talks, GitHub discussions, Books & Papers and even XLA HLO dumps to enhance the models' understanding of the compiler internals and improve debugging capabilities as well as better guide the developers when dealing with the internals. Another key focus would be incorporating commonly-used popular libraries like Equinox, Optax and Scalax as well because current SOTA LLMs are not familiar with these (relatively) niche but handy libraries and thus prove to be less helpful and prone to hallucinating components of the ecosystem that don't exist. This pretrained model will be available externally through an API or a CLI interface like Aider/Claude Code styled wherein it'd be accessible to everyone regardless of their development environment or IDE/Editor. I would also experiment with new ideas such as integrating type-annotations, Array and PyTree shape annotations and packaging other auxiliary information embedded in the AST to provide further context to the model apart from the raw code itself.

<p>The main focus will be on frontend-related issues particularly, compose features, message area, user interface. Besides that, I’ll work on fixing the issues labeled as bugs. I’m also interested in making the CSS more organized.</p> <p>The plan is to make the user experience more user-friendly and bug-free. Here is the current list of issues and features that I plan to complete in this project.</p> <ul> <li>Easy drag and drop of files so that users can instantly share files.</li> <li>Easily quote and reply "some selected small part of a message".</li> <li>Making the compose box a full-fledged editor with tools for easily writing messages using markdown.</li> <li>Making the experience of message failures easy to handle.</li> <li>Adding some more features and fixing various old-time bugs.</li> </ul> <p>It is highly unpredictable to guess what issues might come up later. So, the main outline will be to solve any new issue that might get opened later which is related to the frontend, compose box, message area with the ultimate goal of making Zulip much better than before.</p>

The goal of this project is to get syzkaller, a coverage-guided OS kernel fuzzer, working under FreeBSD/RISC-V. As syzkaller is written mostly in Go, the first step is to ensure that Go is able to compile syzkaller. Previous work can be harnessed from two projects to make this tractable. First, Go has a RISC-V port targeting GNU/Linux, and second, the CHERI project has a FreeBSD/mips port of Go. The next step is to add FreeBSD/RISC-V support to syzkaller itself. A work-in-progress patch for FreeBSD/arm64 support can be used as a template. Two bonus tasks are: 1. upstream Go support for FreeBSD/RISC-V to the Go Project, and 2. begin fuzzing system calls under FreeBSD/RISC-V. Syzkaller is flexible enough to target OS interfaces other than system calls. For example, it has been used to fuzz the Linux USB stack and has found dozens of bugs in the USB subsystem alone. The details are complicated, but the idea is simple. 1. Generate a program, which invokes one or more system calls. 2. Run the generated program. 3. Check to see if the system diagnosed an error. - If not, collect kernel code coverage information and decide whether to try iterating upon the previous test program, or start anew. - If so, collect information about the crash and try to discover a minimal test case that triggers the crash. The mentors will have weekly meetings with the mentee to discuss progress and strategies for overcoming any challenges.

SATIE(Spatial Audio Toolkit for Immersive Environments) can be used for audio spatialization. It is an audio spatialization engine programmed in SuperCollider that can render dense audio scenes to large multi-channel loudspeaker systems in real time. This lower-level audio rendering process maintains a dynamic DSP graph created and controlled via OSC messages from the external process. SATIE can be used not only for sound object control (location, propagation, etc.) but it can also be used for Haptic Floor dedicated to large immersive spaces. In this project, however, we focus on a function of SATIE is that implementing geometry understanding at a spatializer level. In this case, we usually apply the current version of SATIE mappers plugin to perform this function. A mapper plugin does not process audio, it can be used for provide for non-generic control and geometric computation of lower-level spatialization parameters. However, it still has limitations that need to be programmed for each use case. In order to perfect it and improve its efficiency, we need to design and implement the generalizable SATIE mappers that could get all loaded spatializers and set them at a relative distance concerning each other. In other words, it is necessary to make each different spatializer in different positions recognize the relative position of each other. The proposed mappers will be designed to overcome these limitations and will be tested with different spatializer configurations. This project will provide SATIE with a powerful and flexible tool that will enable users to create rich and diverse sound spatial effects in different scenarios.

VLC’s 4.0 redesign on the Mac has clearly seen many of the same changes as its counterpart for Linux and Windows, but with a more native-feeling UI on macOS. However, there are also hints that this UI requires some additional work before the release and that this proposal could assist with. VLC on macOS, for example, does not quite look like other macOS applications yet, though it’s obvious that this is an objective of the Mac team. Navigation does not work the same way as other AppKit applications and is structured in an unconventional manner. Additionally, there are visual divergences from the Apple HIG. The proposal contains visual examples of this. This proposal therefore seeks to assist in the redesign of the macOS UI for VLC by altering the aspects of the current implementation that clash with established human interface guidelines in macOS applications. Specifically, this proposal suggests: 1. A redesign of the playlist to resemble collapsible sidebars used in other macOS applications (such as the Music app’s playlist sidebar) 2. Changes to navigation elements within main views, such as the aforementioned double tab bar 3. Attention to detail and ensuring visual polish (correct alignment of elements, proper use of separators and view coloration to distinguish between parts of the app Lastly, the current nightly version of the VLC player lacks the ability to control playback, volume, etc. from the video reproduction window. A set of playback controls such as QuickTime’s, which are inconspicuous and relocatable, would be a great addition to VLC and would make the transition for QuickTime users seamless. There would still be opportunities here for VLC’s branding to come through, mainly with the use of accent colours.

Summary: The OBA project aims to develop official OneBusAway REST API client libraries in TypeScript and Python, enhancing accessibility and user experience for developers interacting with OneBusAway servers. These libraries will support all REST API methods, handle diverse data types, include comprehensive tests, and provide helpful examples for new users. About Me: I am Ahmed Hossam, a senior information technology student with a passion for technology and problem-solving. With experience in backend engineering and competitive programming, I am excited to contribute to the OBA project and make a positive impact. Investigations: I have familiarized myself with OneBusAway endpoints, built a beta version of the TypeScript package, and experimented with different structures for scalability and maintainability. Detailed Design: The API client follows a modular structure, with each endpoint encapsulated within its own module. It employs a combination of factory and dependency injection patterns and includes a base class for foundational HTTP request functionality. Implementation Plan: I will collaborate closely with mentors to understand API client requirements and plan implementation details. Error handling and unit testing will be prioritized, followed by thorough testing and the publishing of final packages. Proposal Timeline: The timeline spans 14 weeks, beginning with communication and research in the first three weeks, followed by official coding in TypeScript. Python implementation will commence in week 9, with completion and finalization in week 14. Why Me: I find joy in making OBA APIs accessible to everyone and am dedicated to contributing positively to the project. My experience in API development, along with continuous learning, makes me well-suited for this role.

The currently used styling system has a number of major shortcomings: its over-complicated and full of nuances, which often leads to unpredictable behavior; the current style files structure and absence of validation tools makes it easy to do mistakes and hard to debug them / hard to notice undesired side-effects; the current inheritance mechanism doesn’t work well for “sub-styling” (adding new styles by specifying only changes over the base style). A major refactoring of the current system will speed up development of the current and planned map styles, increase their robustness and hence save time on maintenance / bug fixing, open up possibilities for perspective style enhancements. Requirements for a new better system: - predictable and easily debuggable, makes it hard to break things - style files are nice, clean and compact - promotes stylistic standards, e.g. standard font and icon sizes for various zoom levels - supports easy and efficient sub-styling - simple enough to be used by enthusiastic users, so that they could create custom styles - powerful/flexible enough to describe the styles without much repetition - future-proof, i.e. it should be easy to add support of dynamic styling, svg icons or other perspective styling features planned by the Organic Maps team As a result, Organic Maps will run on a new styling system, which includes - a new styling language syntax specification, including its documentation - current main and vehicle style files migrated into a new format - a compiler of new format style files into the binary Google protobuf format used by the rendering engine

<p>AI agentic workflows (multi-agent collaboration frameworks, automated evaluation systems such as SWE-bench) frequently spawn and tear down large numbers of short-lived sandboxes (gVisor, Wasm, Kata Containers) to execute skills or tools. Current Kubernetes scheduling models are too heavy for these transient workloads, causing high latency, weak isolation, and APIServer pressure. This project will extend Koordinator to provide first-class support for AI agent scenarios by integrating sandbox runtimes with Koordinator QoS classes, implementing equivalence-class scheduling for near-identical sandbox requests, and introducing a dedicated Sandbox Pipeline that handles pre-warming, capacity reservation, and actionable scheduling feedback to enable agent self-healing.</p><p><br></p><p>Expected Outcome:</p><p>&nbsp;- Native integration of agent sandbox runtimes (gVisor/Wasm/Kata) with Koordinator QoS classes (LSR, LS, BE) and resource hardening templates</p><p>&nbsp;- Equivalence-class scheduling logic in the Koordinator scheduler that skips redundant Predicate/Priority calculations for batches of similar sandbox pods</p><p>&nbsp;- A Sandbox Pipeline mechanism with pre-warming, automated environment provisioning, and reservation hooks</p><p>&nbsp;- Annotation/Status-based scheduling diagnostics that surface actionable next-step suggestions to upstream agents</p><p>&nbsp;- End-to-end tests and benchmarks demonstrating throughput and latency improvements for high-concurrency sandbox workloads</p><p><br></p>

This project focuses on solving a real gap in the current research workflow that is the disconnect between running experiments and turning those results into clean, publication-ready outputs. Right now, tools like Visdom are great for live experiment visualization, but the moment a researcher wants to use those results in a paper, everything becomes manual. Plots are exported as screenshots or loosely formatted images, experiment configurations are tracked separately (often in notes or notebooks), and comparisons across differnent runs are done by hand. This makes the process slow, error-prone, and difficult to reproduce. The proposed solution is to extend Visdom into a complete “experiment-to-publication” pipeline. Instead of stopping at visualization, the system will allow researchers to directly generate structured, reproducible, and publication-quality outputs from Visdom itself. The project introduces four tightly connected components: A publication-quality export engine that allows plots to be exported in formats like SVG, PNG, and PDF with proper resolution and formatting suitable for academic journals. An experiment metadata tracker that automatically records configurations, parameters, environment details, and results for every run, ensuring full reproducibility. A LaTeX generation system that converts plots into ready-to-use LaTeX figure blocks, eliminating the need for manual formatting in Overleaf or similar tools. A multi-experiment comparison suite that enables researchers to compare different runs with statistical summaries and generate both plots and tables for inclusion in papers. By building this system, Visdom evolves from a visualization tool into a full research workflow assistant. The end result is simple: what currently takes days of manual effort can be reduced to minutes, while also improving the reproducibility and consistency across various experiments.

The primary goal of this project is to refactor Akonadi’s agents and resources by decoupling their configuration dialogs from their underlying logic. This change will allow us to remove the inclusion of heavy QtWidgets header files, which currently lead to unnecessary memory usage. Reducing this overhead is essential for making the Merkuro suite fully usable on mobile devices, where resource constraints are critical. At present, many components load their GUI elements by default, unnecessarily increasing the memory footprint and hindering performance on resource-constrained platforms. By refactoring these configuration dialogs into separate, dynamically loaded plugins, the agents and resources can run leaner and more efficiently (it would save around 15-20 Mib of RAM per agent/resource) while still providing full-featured configuration interfaces when needed by host applications. Project Deliverables ● Refactor as many as reasonably possible of the selected Akonadi agents and resources within the GSoC timeframe. The goal is not necessarily to port all agents, but to make meaningful progress and establish a repeatable pattern for others to follow, ensuring the project is successful even if not every target is completed. ● Eliminate embedded QtWidgets dependencies—such as replacing QApplication with QCoreApplication—in their primary functionality. ● Identify and replace additional usages of QtWidgets beyond the configuration dialogs—such as QMessageBox instances used to show error messages. ● Modify build configurations (CMake files) to strip out unnecessary UI files and reduce dependencies, thereby lowering memory usage. ● Create dedicated configuration plugins that encapsulate the GUI functionality previously embedded within agents and resources. ● Test and document all changes to verify that memory usage is indeed reduced and that the new plugin-based configuration system functions correctly across both desktop and mobile environments.

Proposal Summary: Interaction to Next Paint (INP) Subparts Problem Statement: The recently introduced Interaction to Next Paint (INP) metric, integrated into the Core Web Vitals (CWV) system in 2024, aims at measuring user interaction performance. However, INP lacks granularity, making it difficult for developers to diagnose and address specific latency issues within different stages of event processing and rendering. Solution Approach: To enhance the diagnostic capabilities of INP, this proposal suggests breaking down the INP metric into its sub-dimensions—input delay, processing time, and presentation delay—by leveraging modifications to Chromium’s Event Timing API. These fine-grained timestamps will be transmitted from the Renderer process to the Browser process via Mojo IPC, eventually integrating these metrics into the UKM metric system and CrUX experimental dataset. The project will involve updating the PageLoadMetricsSender to include detailed timing data for each event, as well as enhancing the UkmPageLoadMetricsObserver to handle both old and new data formats seamlessly. Deliverables: 1. Prototype Verification: Establish a proof-of-concept for collecting sub-dimension data using Chromium’s debugging environment. 2. Mojo Protocol Modification: Extend existing IPC interfaces to support new subpart timings. 3. UKM Integration: Implement new UKM metrics reporting and update relevant configurations. 4. Test Suite Development: Develop comprehensive tests including Web Platform Tests/WPT cases and unit test coverage. 5. Performance Regression Testing: Analyze benchmark reports and memory usage to ensure no negative impact on performance. 6. Documentation & Wrap-up: Provide detailed design documentation and outline plans for integrating improvements into CrUX.

The project aims to extend API Dash with Git-backed collections, a visual workflow builder, and a collection dashboard. This will enable developers to version and share API collections, design and execute multi-step API flows, and monitor API health and performance within a single unified tool. Problem Being Solved: API Dash currently stores requests in a flat local structure without version control or collaboration support. The existing load-all/manual-save model limits reliable syncing, introduces risk of data loss, and prevents building higher-level features like analytics and workflows. Additionally, users lack visibility into API performance and have no structured way to define multi-step API interactions. Proposed Solution: 1. A refactored persistence layer using request-level autosave (Hive LazyBox) for reliable and granular data storage. 2. A GitHub integration layer to enable version control, sharing, and collaboration on collections. 3. A visual workflow builder with a node-based interface to define and execute multi-step API flows. 4. An execution engine to handle request chaining, conditions, and shared data flow between steps. 5. A dashboard system to aggregate and visualize API and workflow performance metrics. Key Deliverables: 1. Request-level autosave system replacing the current bulk-save model. 2. Git support for collections (connect, import/export, push/pull, commit history, rollback). 3. Visual workflow builder with execution support, run history, and DashBot-assisted workflow generation from natural-language prompts. 4. Collection and workflow dashboards showing success rates, failures, and latency signals. 5. Production-ready documentation, testing, and UX polish for real-world usage.

The current macOS app bundle creation process for Synfig relies on an outdated Bash script that is slow, error-prone with incorrect paths, and lacks code signing, hindering efficient distribution and user trust. This project aims to replace the script with a robust, automated solution to streamline bundle generation, ensure macOS security compliance, and enhance the native user experience. By leveraging Python for dependency collection, C++ for environment setup, and CMake/CPack for packaging, the project will deliver a signed, distributable SynfigStudio.app bundle. Key improvements include faster dependency gathering, proper code signing, embedded environment setup, Python/lxml integration, and macOS-native interface enhancements. Approach: • Develop a Python script to efficiently collect and stage dependencies, optimizing with caching and parallelization. • Implement code signing in reverse dependency order using codesign, including Python and lxml binaries. • Remove the external launcher script by embedding environment setup in the C++ entry point. • Package Python and lxml into the bundle, ensuring compatibility and signing. • Integrate CPack into CMake to generate a polished .dmg installer. • Enhance the UI with macOS-native menu bar and window behaviours using GTK. Deliverables: • A CMake/CPack-based build system producing a signed SynfigStudio.app bundle. • A Python script for automated dependency collection and path rewriting. • Code signing support for all binaries, including Python and lxml. • Embedded environment setup within SynfigStudio, eliminating the launcher script. • A bundled Python runtime with lxml, fully signed and functional. • A distributable .dmg installer generated via CPack. • macOS-native UI improvements (e.g., menu bar, shortcuts, dialogs boxes). • Comprehensive documentation covering installation, usage, and build instructions.

<p>The [Ecosystem Explorer](<a href="https://explorer.opentelemetry.io" rel="noopener noreferrer" target="_blank">https://explorer.opentelemetry.io</a>) helps users discover and get detailed documentation around various OpenTelemetry components. As the project expands to more ecosystems (Python, JavaScript, GenAI), information density will increase significantly, requiring patterns and approaches tailored to more than just the initial Java Agent use case. This mentorship involves conducting UX research to understand how users actually want to consume and use this information, covering: how users currently find information about components or instrumentation (LLMs, GitHub, docs, vendor sites, trial and error); what questions they are trying to answer (what telemetry will I get, how do I configure it, what changed between versions); what personas exist (app developers instrumenting code, platform engineers running collectors, SREs debugging production); how similar tools present dense technical information (npm registry, crates.io, Go pkg site, Docker Hub); and how LLMs are being used in this area and what the experience has been with them. The research will inform how we structure information, what features to prioritize, and how to present complex telemetry data in an accessible way.</p><p><br></p><p>Expected Outcome:</p><p><br></p><ul><li>User Interviews Report: Summarized findings from 3-5 user interviews covering different user types and key tasks</li><li>Competitive Analysis Report: Findings from reviewing 2-3 similar tools (e.g., package registries, API documentation sites) on how they present component information</li><li>Information Architecture Recommendations: Proposed structure for presenting a specific type of component data (e.g., "instrumentation" or "collector components")</li><li>Wireframes/mockups (stretch goal): Visual concepts for key user flows</li></ul>

Problem: VLC’s macOS interface has fallen behind modern design standards, creating a disjointed experience compared to its intuitive iOS/tvOS counterparts. The current AppKit-based UI lacks macOS Sequoia's visual polish, struggles with libvlc’s newer playback features (e.g., frame-accurate seeking), and suffers from inefficient media library management. This outdated design hinders usability and fails to make use of macOS’s native capabilities. Solution: Redesign VLC’s macOS interface using AppKit to implement a pre-approved, user-tested design that integrates into macOS visual aesthetics and libvlc’s advanced APIs. The overhaul will: 1. Replace legacy Carbon-era UI components with modern NSCollectionView and NSSplitViewController layouts. 2. Integrate libvlc’s latest playback controls (frame stepping, HDR metadata) into native transport UIs. 3. Rebuild the media library using Core Data for performance and NSDiffableDataSource for real-time updates. 4. Prioritize system consistency with SF Symbols, vibrant materials, and macOS accessibility standards. Deliverables: 1. Modern UI Components: - Unified toolbar with adaptive controls (NSToolbarItemGroup) - Redesigned media library with thumbnail grid (NSCollectionView) and smart filters (NSPredicateEditor) 2. Enhanced Playback: - Frame-accurate seekbar with NSSlider tick marks synced to libvlc’s next_frame() API - HDR tone mapping toggle using CAMetalLayer integration 3. Optimized Media Management: - Rules-based playlists backed by Core Data - Spotlight-like search using NSFetchRequest 4. Developer Documentation: - Migration guide for plugin developers - NSAccessibility implementation notes By collaborating closely with VLC’s core team and iterating on the existing codebase, this project will deliver a performant, native macOS experience that bridges the gap between VLC’s powerful engine and modern user expectations.

ROOT is a framework for data processing, born at CERN, at the heart of the research on high-energy, molecular and laser physics, as well as in astronomy. ROOT has plenty of built-in components. Because of a variety of features, ROOT is a very large software which takes a very long time to compile. Currently ROOT compiles all of the components available within the source code distribution. The goal of the project is to speed up the compilation process by letting users specify which components of the ROOT will be needed. This can be done by converting ROOT’s CMake configuration into a set of “CMake External Projects” (superbuilds). Superbuilds can remove all of this cruft from the project’s source repository, and enable you to more directly use the upstream project’s build system as an independently built software component. It is basically a simple package manager that you make consistently work across your target build platforms, and if your target platforms have a common package manager you might consider using that instead. Also, during the configuration process it could be possible to identify if ROOT is already installed in the destination folder, the components which are already installed and offer an option to skip their compilation and use these already installed components for current compilation. We are not going to change the build system of ROOT, but to optimize it and offer users an option to select only the parts of the ROOT to be built. Partial builds for ROOT can allow the creation of “edition” builds if necessary.

<p>Projects like jQuery and Angular JS are written primarily with javascript and make extensive use of git as their version control system. Using git means that developers write commit messages. Nice and clean commit messages that adhere to an agreed-upon style are very common. So, implementing a way to validate these messages, like the commitplease project, makes a lot of sense. Currently, the commitplease project supports the jQuery style commit messages. Extending its support to the Angular-style ones (and possibly others) is a logical goal.</p>

Neutralinojs has a test system but currently, it only checks for functional breakdowns. The test suite throws an error on a Windows CI Instance and it also fails to run on ARM-based CI Instances. This project aims at enhancing the test suite and fixing these issues by adding edge test cases, Performance tests, tests for proper functioning of Global Variables, tests for making sure that each function returns the expected Error Code and resolve the errors encountered when running the test suite on different CI Instances. After this project is completed, changes made to the code base will be tested thoroughly to ensure that the code does not introduce any errors.