Explore Projects

The swift-java interoperability library provides the jextract-swift tool, which extracts Java sources that are used to call Swift code from Java. However, the tool uses the Foreign Function and Memory API (FFM), which requires JDK 22+, making it unavailable on platforms such as Android. The goal of this proposal is to extend the jextract-swift tool, such that it is able to generate Java sources using JNI instead of FFM and thereby allowing more platforms to utilize Swift/Java interoperability. The solution will modify the code generation to support multiple modes through a protocol. Thereby, allowing us to generate JNI Java wrappers that that utilize the JNI functionality already defined in the library. We will modify the current Arena implementations to support memory management for JNI as well, through calls to the Swift runtime. The library will also generate Swift thunks that implement the native methods defined in Java and handle JNI/Swift conversion and object initialization. The project will achieve feature parity with the current FFM mode and explore more complex language features, if time permits.

For this project, we would design and implement an interactive mode for command-line tools built using ArgumentParser that prompts for any required arguments not given in the initial command. In the past, users would get lengthy error messages and help text when the command is incomplete. Interactive mode will reduce duplication and provide a conversational CLI which is both easier to write and easier to read.

SW360 currently imports license and obligation data through five disconnected paths with no coordination between them, meaning multiple instances can hold different obligation text for the same license with no way to detect the gap. This project makes LicenseDB the single authoritative source by implementing scheduled REST based synchronization. It covers paginated license and obligation sync, incremental daily updates via the audit log, field-level mapping that preserves SW360-specific compliance fields, read-only gating of legacy import paths, and CouchDB-first lookup for CLI attachment processing. Deliverables include JWT authentication, automated daily scheduling via ScheduleHandler, admin REST endpoints for sync control and health monitoring, encrypted credentials, circuit breaker and rate limiting, a migration guide, and test coverage.

Deploying AWS Lambda functions using AWS SAM (Serverless Application Model) requires manual creation of a deployment descriptor, posing challenges for Swift developers due to learning a new DSL and adopting new tools like SAM CLI and Docker. To simplify this process, the community proposed a Swift-based DSL and a Swift package plugin. However, these solutions rely heavily on accurately mimicking the evolving SAM AWS deployment descriptor. To address this, this project proposes to automatically generate the AWSLambdaDeploymentDescriptor library based on the SAM template definition. That generated code is used by the Swift-based DSL to create SAM YAML templates required to deploy Lambda functions and their dependencies to AWS.

<p>This proposal aims to bring scripting support to SwiftPM. The goal for GSoC is some kind of proof-of-concept and is expected to be the foundation of a full implementation of this feature. The outcome is expected to be a prototype of the new <code>swift-script</code> tool, which has a limited set of basic operations implemented like <code>run</code> and <code>reset</code>. There will also be a new flag for Swift Driver which enables a shortcut to the feature through <code>swift</code> command.</p>

I propose reimplementing the compiler’s qualified name lookup in the Swift-only "swift-syntax" package. I will add a new API to the SwiftLexicalLookup module that accepts a declaration group, such as a type, and returns its members —commonly properties and functions. Lifting this API into the higher-level SwiftSyntax package exposes essential semantic information, enabling build tools that perform more intricate code transformations and offer more precise diagnostics. The library will find a declaration group's members through the package's SyntaxVisitor API and optionally cache results in a new SymbolTable type. I will deliver the updated SwiftLexicalLookup library with helpful docstrings and comments, extensive unit testing, and unqualified-lookup integration, along with two dedicated documentation articles.

This project aims to extend SourceKit LSP to add DocC Language features like go-to-definition and diagnostic support for missing or broken symbol links. It also enhances the documentation preview by making it interactive with clickable symbol links and web URLs, along with syntax highlighting for .tutorial and .md files.

<p>Debuggers are essential tools in aiding developers to do their work more efficiently. They are inherently tied to the target operating system, and therefore require platform-specific work in order to deliver functional parity between different platforms. Swift is a multi-platform programming language, and having a good debugging experience in all platforms is beneficial for the language. With that in mind, I propose to improve LLDB’s support on the Linux operating system by: fixing Swift type metadata parsing for ELF objects; unifying queries of dynamic type resolution under the RemoteMirrors API; and, finally, enabling tests which currently do not run on Linux, or are marked as expected to fail.</p>

This proposal aims to improve the testing framework for SW360’s REST API endpoints by addressing limited test coverage, insufficient integration tests, and outdated testing workflows. The project will focus on writing comprehensive unit tests for CRUD operations and edge cases, developing integration tests for multi-endpoint workflows, and creating reusable utilities for database mocking and error simulation. Additionally, CI/CD pipelines will be automated with tools like JaCoCo for test coverage tracking and regression prevention. Deliverables include a robust test suite, enhanced testing infrastructure, automated pipelines, and detailed documentation to simplify onboarding and contributions. These improvements will make SW360's APIs more reliable, scalable, and maintainable for the developer community.

Considering the performance, instead of reparsing the entire file every time, we could speed up the parsing procedure with the information provided by old AST, which is an ability provided by the old parser. In the old implementation, this feature was only applied to CodeBlockList and MemberDeclList. In the new implementation, It would be nice to apply node reusing to other syntax collections e.g. exprList, functionParameterList, etc. Also, It would be good to allow more fine-grained reusable nodes via expanding the definition of nodeAtCursorCanBeReused to allow reusing nodes such as FunctionDeclSyntax where only identifier is changed.

<p>Over the last couple of years, the Swift compiler has gained a new library called libSyntax. Its purpose is to represent the syntax of Swift source code with full fidelity (including white-space), enable structured editing and provide immutable, thread-safe data structures.</p> <p>This paper proposes that the Swift parser fully embraces the new libSyntax library in its parser and stops emitting ASTs. This will allow more parts of the compiler pipeline to eventually leverage the capabilities of the new library.</p>

This proposal describes how we can implement Lexical scopes library for swift-syntax. The library would describe what declarations are available in what scopes, would enable looking up declarations of particular references as well as finding what scopes that keywords refer to. The functionality would be beneficial especially from the compiler and IDE perspective. This approach focuses on creating a tree structure under a common protocol that would enable a bottom-up recursive reference lookup. In order to directly access scope information, AST nodes would be extended with additional scope-related properties.

This project is proposed because of the need for a fully-integrated HTTP server in Zephyr that can replace the deprecated CivetWeb module. The proposed solution is to prototype a basic HTTP 2.0 server using POSIX APIs and then port it to Zephyr. The server will take advantage of Zephyr's existing building blocks, including the ZTest Framework, mbedTLS libraries, Kconfig ... The project's deliverables include a basic HTTP server, porting the server to Zephyr, and creating a Test Plan to demonstrate mandatory features such as REST API, TLS, and Compressed Resources in Memory (CRiMe). Additionally, we will demonstrate HTTP server functionality with one of Zephyr's supported boards and Qemu.

<h3>Improving the VM Profiler</h3> <p>The current VM profiler is a sampling profiler cadenced at 1.3GHz tracking down where the time is spent in the C code of the VM (for the interpreter and the GC) and in the machine code zone (for the code generated by the JIT). The VM profiler cannot track down precisely where the time is spent when executing the code generated by the JIT. It can track down in which methods the time is spent, but it cannot track down in which part of those methods the time is spent.</p> <h3>Goals</h3> <ul> <li><strong>Port the VM Profiler to Pharo</strong> (it only works in Squeak for the moment) </li> </ul> <p>By making sure the UI stays independent and by patching all the uses of the library OSProcess to make it work in both Squeak and Pharo</p> <ul> <li><strong>Get a more detailed profiling</strong> </li> </ul> <p>By using the JIT API to map machine code instruction pointer to bytecode program counter, to be able in the end to show in which bytecode range of methods the time is spent instead of only in which methods the time is spent</p>

<p>Components are the building blocks of app inventor. They can be visible i.e. they are part of UI interface or they can be non visible i.e they are not part of the UI screen but provide access to built-in functions of the device. All components in app inventor are part of some screen or activity which means that if the screen is not visible or the screen is destroyed by the Android system, the components stop running. An example of this is the Pedometer component which stops running when the phone screen is off. Ideally, a pedometer app would want to keep running once started in the background until the user of the app explicitly stops it. To enable such behavior it is necessary to run such components in a background process and re-start the process every time the system kills it.</p>

<p>Currently, extensions are limited to just non-visible components. Due to this, extensions can't be dragged into the screen designer. To work around this, extension developers have to get a reference to a visible component as parent under which they create UI views. This, however, defeats the idea of App Inventor, which allows the users to create their UI of their apps using the concept of WYSIWYG. My proposal to solve this problem is to have a generic <code>MockVisibleComponentExtension</code> which can be dragged into the designer. The extension will be just a visible component as opposed to non-visible component. This allows the extension to be placed under a <code>ComponentContainer</code> under which the extension can create its views. This allows the users to view a clear hierarchy of their app's UI when using "visible" extension. Then, there will also be a need for <code>MockComponentContainerExtension</code> into which any visible component/extension can be placed.</p>

<p>Android WebView is an Android framework component that is developed under the Chromium Project. WebView is embedded inside other Android apps but it has its own standalone DevTools Android app that is bundled with the APK.</p> <p>The project aims to implement a Components UI to the aforementioned.</p> <p>This will make the dynamically installed components more easily accessible to developers and testers in comparison to the adb shell. This UI will be similar to chrome://components page in the Chrome Browser.</p>

<p>Processing Language Server focuses on creating a Language Server Protocol (LSP) implementation for Processing Programming Language. PDE is currently built using Java and using custom components of the Swing Framework, which is ~ deprecated. The long term goal of Processing is to replace this with a JS based IDE to bring in more contributors and to make building UIs simple. While planning on building such IDE, LSP is of significant importance for any language that the IDE relays on. Since Processing is the targeted Programming language, it’s quite important to build a Language Server Protocol for the same. This shall act as a benchmark for all the crucial activities of the IDE such as auto-completion, go-to-definition, hover-insights and so on. LSP will also help in easy and seamless integration of the above functionalities in any editor such as Atom, VScode, etc.</p>

<p>Integrated script editor in Godot lacks features found in editors like VS Code, Sublime, Emacs, etc. These editors are also more popular among developers and therefore are better to switch for usability. However, to implement core functionalities such as - Diagnosis, Registering custom symbols, jump to definition, etc a Language Server structure has to be adopted. For example, the client (say vs code) will communicate the godot language server to give desired result.</p> <p>Microsoft's Language Server Protocol (LSP) is flexible and powerful to implement these functionalities. It also supports many editors - VS Code, Atom, Sublime, etc. Hence, instead of writing complete extensions for each editor (client) using LSP servers can be reused while the client which is an editor extension has to be only re-written.</p>

This proposal aims to implement the Menu, Sidebar, and Floating Action Button (FAB) components in iOS for MIT App Inventor, ensuring feature parity with Android as introduced in PR #2299. The Menu Component will introduce a dropdown-style menu supporting nested items, icons, and keyboard navigation. The Sidebar Component will provide a sliding navigation panel with swipe gestures, tap-to-close functionality, and essential navigation links like Home, Profile, Settings, and Logout. The Floating Action Button (FAB) will be a circular, floating button positioned at the bottom-right, supporting custom actions, animations, and a shadow effect for a modern UI experience. A key aspect of this project is ensuring feature parity with Android, maintaining UI/UX consistency across both platforms. I chose this project because it bridges the gap between iOS and Android, ensuring that MIT App Inventor provides a seamless cross-platform experience. It also enhances user experience by introducing smooth, intuitive navigation and interactions, making iOS-built apps more functional and engaging. Additionally, this project will expand MIT App Inventor’s capabilities by adding essential missing features, making the platform more versatile and user-friendly. The estimated timeline for this project is 175 hours, covering implementation, testing, and final integration. Upon completion, this update will significantly enhance MIT App Inventor’s iOS version, making it a fully-featured, cross-platform development tool that aligns with modern app-building standards.

<p>Right now, MIT App Inventor is short of components that allow to visualize data using charts. This project aims to implement entirely new components that allow displaying the data visually, such as through pie charts, bar charts, scatter charts or radar charts, while also providing various customization functionality to allow the user to adapt the components to their needs.</p>

I will implement stream processing support for FasTensor library. Stream processing enables online processing of live data as it arrives on the File System from various data producers. Th Big Plan: 1. A directory monitoring service will monitor file addition or removals of specified pattern. 2. A dynamic stream object which provides iterators that return file in a stream in specified order and also combine multiple streams. 3. A rich set of stream handling components, each with a unique set of concerns and guarantees, that enables stream-specific functions like read and write in a fault-tolerant and robust manner. Deliverables: 1. A rich interface to compose streams from various data producers. 2. A fault-tolerant and robust mechanism to read, write, and manage streams in a big data environment.

<p>Icecast Server is used as a streaming server to broadcast to various listeners. A return channel allows for possibility of receiving feedback from listeners. This will make the streams interactive for conducting polls etc. The project aims to develop this return channel from listeners to source.</p>