├── README.md └── submissions ├── AhmedIhab.md ├── creatoon.md ├── gpt-deploy.md └── windows-ci-pkspyder007.md /README.md: -------------------------------------------------------------------------------- 1 | # Google Summer of Code 2023 2 | List of project ideas for contributors applying to the Google Summer of Code program in 2023 (GSoC 2023). 3 | 4 | ## Timeline/milestones 5 | 6 | Please always refer to the [official timeline](https://developers.google.com/open-source/gsoc/timeline). 7 | 8 | ## Application Process 9 | 10 | #### 0. Get familiar with GSoC 11 | 12 | First of all, and if you have not done that yet, read [the contributor guide](https://google.github.io/gsocguides/student/) which will allow you to understand all this process and how the program works overall. Refer to its left side menu to quick access sections that may interest you the most, although we recommend you to read everything. 13 | 14 | #### 1. Discuss the project idea with the mentor(s) 15 | 16 | This is a required step unless you have dived in into the existing codebase and understood everything perfectly (very hard) and the idea you prefer is on the list below. 17 | 18 | If your idea is not listed, please discuss it with the mentors in the available [contact channels](https://github.com/metacall/gsoc-2023#find-us). We're always open to new ideas and won't hesitate on choosing them if you demonstrate to be a good candidate! 19 | 20 | #### 2. Understand that 21 | 22 | - You're committing to a project and we may ask you to publicly publish your weekly progress on it. 23 | - It's the third year Metacall is joining the GSoC program and we will ask you to give feedback on our mentorship and management continuously. 24 | - You wholeheartedly agree with the [code of conduct](https://github.com/metacall/core/blob/develop/.github/CODE_OF_CONDUCT.md). 25 | - You must tell us if there's any proposed idea that you don't think would fit the timeline or could be boring (yes, we're asking for feedback). 26 | 27 | #### 3. Fill out the application form 28 | 29 | We recommend you to follow [Google's guide to Writing a Proposal](https://google.github.io/gsocguides/student/writing-a-proposal) as we won't be too harsh on the format and we won't give any template. But hey, we're giving you a starting point! 30 | 31 | You can send the proposal link to any readable format you wish: Google Docs, plain text, in markdown... and preferably hosted online, accessible with a common browser **without downloading anything**. 32 | 33 | You can also ask for a review anytime to the community or mentor candidates before the contributor application deadline. It's much easier if you get feedback early than to wait for the last moment. 34 | 35 | 36 | ## Project Ideas 37 | 38 | You can also propose your own. 39 | 40 | ### Improve CI/CD for MetaCall Core 41 | 42 | **Skills**: C/C++, CMake, Bash, Batch, PowerShell, DevOps 43 | 44 | **Expected size of the project**: Large (350 hours) 45 | 46 | **Difficulty rating**: Medium 47 | 48 | **Description**: 49 | MetaCall Core has a intensive test case which is mainly focused on Linux (including Sanitizers in order to detect memory, address, undefined behavior or threading bugs). Currently we are improving the Windows CI/CD support with MSVC but it is not finished yet and it will need to further work. In another hand, it will be interesting to also implement MacOS support with Clang. The main idea is to support multiple platforms and architectures with multiple compilers but the current baseline (Linux with GCC, Windows with MSVC and MacOS with Clang; all on amd64 architecture) should be enough for the scope of the project. The complexity of this relies in the dependencies of the Core itself because they have to be pre-installed before the Core is built and it must be automated in such a way that can be later on moved to a different CI or environment and work out of the box. Also while implementing the tests, it is possible that some CMake bugs or Core bugs are shown, and those must be addressed too. For this task you can get assistance from the MetaCall Team itself, so do not be afraid, you can still raise an issue pointing out the problem and we can solve it eventually. 50 | 51 | For more information, review the current state of the CI/CD and tools for installing dependencies and configuring & building MetaCall on different platforms. 52 | 53 | - MetaCall Core CI/CD: https://github.com/metacall/core/tree/develop/.github/workflows 54 | - MetaCall Core Tools: https://github.com/metacall/core/tree/develop/tools 55 | 56 | **Expected outcomes**: To implement and complete testing CI/CD for Windows, Linux and MacOS in order to provide cross-platform testing for multiple platforms, compilers and architectures. Also solve the problems that will appear in platforms during the implementation of the CI/CD. 57 | 58 | **Possible mentors**: Gil Arasa Verge, Vicente Eduardo Ferrer Garcia 59 | 60 | ### FaaS TypeScript Reimplementation 61 | 62 | **Skills**: TypeScript 63 | 64 | **Expected size of the project**: Large (350 hours) 65 | 66 | **Difficulty rating**: Medium 67 | 68 | **Description**: 69 | This project offers a reimplementation of [MetaCall FaaS](https://dashboard.metacall.io) but with a simpler and less performant implementation. The objective of this FaaS reimplementation is to provide a simple and portable FaaS that can be run from the CLI in order to locally test the functions and complete projects that can be deployed into MetaCall FaaS. This is a very important part of the project because it is needed in order to fullfill the developer workflow when developing distributed polyglot applications. 70 | 71 | It should mimick the [MetaCall FaaS REST API](https://github.com/metacall/protocol/blob/8367aee106128a5bfae13ba613bcfdc2793b6dcf/src/protocol.ts) but without need of authentication and with only the required capabilities for development. This repository will share parts with MetaCall FaaS through [MetaCall Protocol](https://github.com/metacall/protocol) so code can be reused between the repositories. 72 | 73 | For better deployment, the MetaCall FaaS should be integrable with MetaCall CLI, providing a self contained distributable with all the compiled code which can be launched or invoked from an external CLI via API. 74 | 75 | **Expected outcomes**: An embeddable library that can be used for locally testing MetaCall projects as if they were hosted on the FaaS. 76 | 77 | **Possible mentors**: Thomas Rory Gummerson, Jose Antonio Dominguez, Alexandre Gimenez Fernandez 78 | 79 | **Resources**: 80 | - MetaCall FaaS TypeScript reimplementation repository: https://github.com/metacall/faas 81 | - MetaCall FaaS: https://dashboard.metacall.io 82 | - Video Deploying a hundred functions into MetaCall FaaS using the Dashboard: https://www.youtube.com/watch?v=2RAqTmQAWEc 83 | - MetaCall Protocol: https://github.com/metacall/protocol 84 | - MetaCall Deploy: https://github.com/metacall/deploy 85 | 86 | ### Builder 87 | 88 | **Skills**: Go, Docker, BuildKit, Sandboxing, Kubernetes 89 | 90 | **Expected size of the project**: Medium (175 hours) 91 | 92 | **Difficulty rating**: Medium 93 | 94 | **Description**: 95 | Currently MetaCall is offered as Docker image on [Docker Hub](https://hub.docker.com/r/metacall/core). It includes 4 tags (`deps`, `dev`, `runtime` and `cli`) with only one architecture (`amd64`). Right now all the languages are packaged at once into the image, producing a big sized image, specially on the `dev` tag. The idea of this project is to implement a CLI with a separated API which provides a way to generate compact Docker images with MetaCall runtime. Docker does not allow to selectively choose from multiple layers merging them into one with efficient caching, we could do this by means of templating the Dockerfile itself but using the Buildkit API will make the solution much more robust and with the benefit of all the features from Buildkit like caching. 96 | 97 | Another main requirement for this project is that it must be run under rootless and daemonless, inside a Dockerized environment (i.e this must be able to be run inside Docker without permissions and without a Docker daemon, so it can be run in a Kubernetes cluster, pushing and pulling the resulting images from a private registry). 98 | 99 | This project has to be efficient and sandboxed, focused on FaaS development and producing compact images in terms of size and dependencies, so the bandwidth and attack surface is reduced. 100 | 101 | **Expected outcomes**: A command line interface and library that is able to selectively compose docker images and run inside Docker/Kubernetes for MetaCall with efficient caching and compact size. 102 | 103 | **Possible mentors**: Fernando Vaño Garcia, Vicente Eduardo Ferrer Garcia, Gil Arasa Verge 104 | 105 | ### MacOS Distributable 106 | 107 | **Skills**: C/C++ Dependency Management, CMake, Bash, DevOps 108 | 109 | **Expected size of the project**: Large (350 hours) 110 | 111 | **Difficulty rating**: Hard 112 | 113 | **Description**: 114 | 115 | MetaCall has multiple runtimes embedded on it and one of its objectives is to be as cross platform as possible. Each runtime has its own dependencies which create a huge dependency tree sometimes. This is a big complexity that is difficult to handle. Currently we are using Guix as our build system in Linux and we achieved to compile MetaCall and make it completely self-contained (in Linux for amd64 at the moment of writting). This allows MetaCall to be installed even in a BusyBox and work properly without any other system dependency. Current implementation of the build system consist of 3 repositories: 116 | 117 | - Distributable Linux: https://github.com/metacall/distributable-linux 118 | - Distributable Windows: https://github.com/metacall/distributable-windows 119 | - Distributable MacOs: https://github.com/metacall/distributable-macos 120 | 121 | The objective of this idea is to improve the MacOS support: 122 | - Implementing the build script for MacOs with portable dependencies on the automated CI, in a similar way to how Windows distributable has been done. 123 | - Add tests in order to verify the MacOs portable installation. 124 | - Improve the install script for Linux [by adding support to MacOs](https://github.com/metacall/install/blob/0f145d4ee5a60b58f7c48f043ed7d0b7d6268609/install.sh#L210) so it can support both platforms at the same time, this will require testing with MacOs too, so another CI with MacOs as runner should be implemented in order to test it through the install script. 125 | 126 | **Expected outcomes**: To implement and complete CI/CD builds for MacOS in order to provide cross-platform binary distributions of MetaCall with the maximum amount of languages possible. Extend the current install script for taking into account MacOs and provide testing environment for the MacOs distributable itself and the install script for MacOs. 127 | 128 | **Possible mentors**: Vicente Eduardo Ferrer Garcia, Gil Arasa Verge 129 | 130 | ### Windows Distributable 131 | 132 | **Skills**: C/C++ Depependency Management, CMake, PowerShell, DevOps 133 | 134 | **Expected size of the project**: Medium (175 hours) 135 | 136 | **Difficulty rating**: Medium 137 | 138 | **Description**: 139 | 140 | At the moment of writing, Windows distributable has a base already implemented. It provides support for portable installation of MetaCall Core with tests and install script. But it is incomplete, it only supports Python and NodeJS. The main objective of this project will be to extend the support and make it more complete and stable. The requirements are: 141 | 142 | - Improving the language support[[1]](https://github.com/metacall/distributable-windows/issues/14)[[2]](https://github.com/metacall/distributable-windows/issues/13), improving the existing ones that do not work and adding new ones. 143 | - Improve the [respective tests](https://github.com/metacall/distributable-windows/blob/master/test.bat) for the new languages added. 144 | - Improve the [install script](https://github.com/metacall/install/blob/master/install.ps1) with its [respective tests](https://github.com/metacall/install/blob/master/.github/workflows/test-windows.yml). 145 | 146 | **Expected outcomes**: To implement and complete CI/CD builds for Windows in order to provide cross-platform binary distributions of MetaCall with the maximum amount of languages possible. Extend the current Windows install script and extend the testing environment for the Windows distributable itself and the install script for Windows. 147 | 148 | **Possible mentors**: Fernando Vaño Garcia, Thomas Rory Gummerson, Gil Arasa Verge 149 | 150 | **Resources**: 151 | - MetaCall Core Windows Environment Install Script: https://github.com/metacall/core/blob/develop/tools/metacall-environment.ps1 152 | 153 | ### Linux Distributable 154 | 155 | **Skills**: C/C++ Depependency Management, CMake, Guix, Guile, Bash, Docker, BuildKit, DevOps 156 | 157 | **Expected size of the project**: Medium (175 hours) 158 | 159 | **Difficulty rating**: Hard 160 | 161 | **Description**: 162 | 163 | At the moment of writing, Linux distributable is one of the best suited distributions that we have right now. But it is not completed and it has [some issues](https://github.com/metacall/distributable-linux/issues). The main objective of this project will be to solve those issues, either focused on the user experience or the development of other applications by means of using MetaCall Core embedded into them. Here's the list of the objectives: 164 | 165 | - Solve issues related to environment variables[[1]](https://github.com/metacall/distributable-linux/issues/5)[[2]](https://github.com/metacall/distributable-linux/issues/14), this will require generate an environment variable file based on `guix shell` and it will let us remove [the current approach used in the install script](https://github.com/metacall/install/blob/0f145d4ee5a60b58f7c48f043ed7d0b7d6268609/install.sh#L376). 166 | - Solve problems with [existing languages not working](https://github.com/metacall/distributable-linux/issues/1), and extend it in order to support more languages, including extending support for [additional features](https://github.com/metacall/distributable-linux/issues/11). 167 | - Improve support for embedders in order to have portable binaries that can be embedded easily into other languages like C/C++/Zig/Rust[[1]](https://github.com/metacall/distributable-linux/issues/15)[[2]](https://github.com/metacall/zig-example). 168 | - Adding [new architectures](https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.70/html_node/Specifying-Target-Triplets.html#Specifying-Target-Triplets) to Linux with their respective tests (for this it is possible to use Docker multi-architecture for supporting those tests) and the install script support for those architectures. 169 | 170 | **Expected outcomes**: A better and more stable version of MetaCall Linux Distributable which addresses the current errors and user experience problems. 171 | 172 | **Possible mentors**: Vicente Eduardo Ferrer Garcia, Gil Arasa Verge 173 | 174 | **Resources**: 175 | - Guix Shell: https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix-shell.html 176 | - Guix Build System options: https://guix.gnu.org/manual/en/html_node/Additional-Build-Options.html 177 | - Docker Multi-Arch support: https://docs.docker.com/desktop/multi-arch/ 178 | 179 | ### MetaCall Deploy Integrations 180 | 181 | **Skills**: TypeScript, JavaScript 182 | 183 | **Expected size of the project**: Medium (175 hours) 184 | 185 | **Difficulty rating**: Medium 186 | 187 | **Description**: 188 | 189 | We have implemented support for [deployments through CLI](https://github.com/metacall/deploy) and now we require to integrate this CLI/Library into more environments in order to improve the development and adoption of MetaCall FaaS. For this there is a list of required tasks to do: 190 | - Visual Studio Extension 191 | - Github CI action 192 | - OpenAPI integration 193 | 194 | **Expected outcomes**: 195 | 196 | - Create a Visual Studio Extension for one click deployment so you don't even need to use the command line for deploying MetaCall projects. 197 | - Create a GitHub action for integrating MetaCall deployments with your own CI if required. 198 | - Create a library for exporting the current MetaCall Inspect format into OpenAPI format, so it can be used easily on other projects. 199 | 200 | **Possible mentors**: Jose Antonio Dominguez, Alexandre Gimenez Fernandez 201 | 202 | **Resources**: 203 | - Visual Code Extension: https://code.visualstudio.com/api/get-started/your-first-extension 204 | - GitHub Action: https://docs.github.com/en/actions/creating-actions/publishing-actions-in-github-marketplace 205 | 206 | ### Rust Actix + TypeScript React Server Side Rendering (tsx) Framework 207 | 208 | **Skills**: Rust, TypeScript, React 209 | 210 | **Expected size of the project**: Medium (175 hours) 211 | 212 | **Difficulty rating**: Medium 213 | 214 | **Description**: 215 | 216 | For this project there are two approaches that can offer different user experiences but having in mind a similar result which is to develop TSX on top of Rust, or basically having an ergonomic and high performance server side rendering for TypeScript written in Rust. The two approaches are the following: 217 | 218 | 1) Recently MetaCall has provided support for [inlining other languages into Rust](https://github.com/metacall/core/blob/adcc50496d53797011b87f42131cb857d0009ffb/source/ports/rs_port/tests/inline_test.rs#L13) through its macro system. This allows adding languages like Python or TypeScript into Rust easily. The main idea of this project is to create a Proof of Concept of an Actix server that easily embeds Server Side Rendering with TypeScript. This should be like a small framework which uses MetaCall and allows writing endpoint handlers where you can embed TypeScript directly with simplicity. In order to achieve this, the Rust Port will need to be extended, adding extra functionality required. 219 | 2) If the first approach becomes problematic because Rust macros are limited for this *hacky* task, we may also provide an alternate and simpler approach which fullfills the objective. Basically we should provide a server that is able to load TSX lambdas and render them out of the box. Those lamdas would be written in a separate file a part from Rust, in a folder. A similar approach that [Granian HTTP Server](https://github.com/emmett-framework/granian) has followed but mainly focused on TSX Server Side Rendering. 220 | 221 | Either using one or another approach, we should also support building static files and offer them with the Rust server, so we can have the complete lifecicle of development. For this we can embed [SWC](https://swc.rs/) which has great performance and it is written in Rust too. 222 | 223 | The Proof of Concept should also contain benchmarks, in order to compare it to other server side rendering solutions or in order to be the baseline for future optimizations in MetaCall TypeScript support. Adding documentation and examples is needed too, so it can be reused in the future by other users and the functionality and utility of the framework is shown. Finally some complete examples should be provided so other users can learn by example how to use the framework and how to extend it. It does not require to have full support for production development but at least our objective is to have a minimal Proof of Concept that works. 224 | 225 | **Expected outcomes**: A small framework based on Actix implementing server side rendering with React (TypeScript). 226 | 227 | **Possible mentors**: Thomas Rory Gummerson, Jose Antonio Dominguez, Alexandre Gimenez Fernandez 228 | 229 | **Resources**: 230 | - MetaCall Rust Port Crate: https://docs.rs/metacall/latest/metacall/ 231 | - MetaCall Rust Port Source: https://github.com/metacall/core/tree/develop/source/ports/rs_port 232 | - MetaCall FaaS SSR Example: https://github.com/metacall/basic-react-SSR-example 233 | 234 | ### MetaCall ChatGPT Example Tutorial 235 | 236 | **Skills**: Python, TypeScript, JavaScript 237 | 238 | **Expected size of the project**: Medium (175 hours) 239 | 240 | **Difficulty rating**: Medium 241 | 242 | **Description**: 243 | 244 | Its well known that ChatGPT is here to stay, 245 | it represents a great tool for writing - and writing code is not the exception. 246 | 247 | Unexpert users can ask the AI to generate code for them in seconds, thats really cool! 248 | Imagine they nail a big one and the code generated is exactly what they needed... 249 | Now what? Where should I put this code? 250 | 251 | Only a few would know where to put this code in order to make it available to the world. 252 | At MetaCall we believe that the simplest way is through MetaCall Deploy platform (Hub), 253 | where your code does not need any boilerplate in order to be transformed into a service. 254 | 255 | **Expected outcomes**: 256 | 257 | A clear blog post of the above is needed. Using chatGPT as the code generator, for making it available on the Hub. 258 | 259 | The example can be a full working service API or a Web App. 260 | We wanted to leave `the what` open to choose, so it will be talked with the mentors. 261 | 262 | **Possible mentors**: Jose Antonio Dominguez, Alexandre Gimenez Fernandez 263 | 264 | **Resources**: 265 | - https://chat.openai.com/ 266 | - https://github.com/metacall/deploy 267 | 268 | ### MetaCall examples' CI 269 | 270 | **Skills**: GitHub Actions, Bash, Devops 271 | 272 | **Expected size of the project**: Large (350 hours) 273 | 274 | **Difficulty rating**: Medium 275 | 276 | **Description**: 277 | 278 | Currently there is no way to test all the examples and deployable examples of Metacall. The goal is to create a comprehensive CI system for all the examples of the core and Metacall FaaS, you would need to create a single repository for each Metacall version. Each repository would download the distributables for all supported operating systems, clone the example repositories from the Metacall's GitHub account, and run each example to test it. This would ensure that all examples are working correctly on all supported platforms for new releases. 279 | Similarly, the same process would be followed for the [@metacall/deploy](https://github.com/metacall/deploy) package, where deployable examples would be cloned and deployed to a FaaS website using Deploy CLI to ensure that they are working as expected. 280 | 281 | **Expected outcomes**: 282 | 283 | The expected outcome will be a comprehensive testing and deployment system that ensures all examples for the Metacall and FaaS are working correctly on all supported platforms. This will provide confidence to users that the software is functioning as expected and will reduce the likelihood of issues arising in production. Additionally, this system could be used to automate future updates and releases, further streamlining the development process. 284 | 285 | Possible mentors: Vicente Eduardo Ferrer Garcia, Gil Arasa Verge 286 | 287 | **Resources**: 288 | - Distributable Linux: https://github.com/metacall/distributable-linux 289 | - Distributable Windows: https://github.com/metacall/distributable-windows 290 | - Distributable MacOs: https://github.com/metacall/distributable-macos 291 | - MetaCall Protocol: https://github.com/metacall/protocol 292 | - MetaCall Deploy: https://github.com/metacall/deploy 293 | - MetaCall FaaS: https://dashboard.metacall.io 294 | - Video Deploying a hundred functions into MetaCall FaaS using the Dashboard: https://www.youtube.com/watch?v=2RAqTmQAWEc 295 | 296 | ## Find Us 297 | 298 | The three chats are bridged by Matrix (messages sent from one, on the main room/channel, can be seen from all). 299 | 300 | - Telegram: 301 | 302 | 303 | - Discord: 304 | 305 | 306 | - Matrix: 307 | 308 | -------------------------------------------------------------------------------- /submissions/AhmedIhab.md: -------------------------------------------------------------------------------- 1 | 2 | ![MetaCall-macOS](https://drive.google.com/uc?export=view&id=1eO4kG8yueHQMMt4y7ESMPpQVeYDggiH2) 3 | 4 | # Google Summer of Code 2023: Improve CI/CD for MetaCall Core MacOS 5 | 6 | ## About MetaCall 7 | 8 | MetaCall is a **polyglot** runtime environment, which allows you to run **multiple programming languages** in the same project. 9 | For example, you can have a Node.js application that uses a Python script and a Ruby script, all in the same project. 10 | You can view more example and use cases from [here](https://github.com/metacall/examples). 11 | 12 | Furthermore, MetaCall represents a serverless runtime environment, also known as Function as a Service (FaaS), enabling you to execute your code within the cloud without the need to concern yourself with the underlying infrastructure. [Give it a try](https://metacall.io/). 13 | 14 | ## Idea Motivation 15 | 16 | MetaCall Core has an intensive test case that is mainly focused on Linux (including Sanitizers in order to detect memory, address, undefined behavior, or threading bugs). The main idea is to support multiple platforms and architectures with multiple compilers but with the current baseline: Linux with GCC, Windows with MSVC, and MacOS with Clang, all on amd64 architecture. So, we are going to implement full CI/CD for macOS with the maximum amount of language support possible for now MetaCall has one for Linux and Windows. 17 | 18 | ## Work done 19 | 20 | ### 1. Setup CI/CD for MacOS on Github Actions 21 | 22 | The CI file is responsible for setting up the environment and configuring any needed dependencies for MetaCall to be built correctly on MacOS. It also removes any pre-installed dependencies that came with Github Runner that may cause conflicts with the build process. Furthermore it creates a matrix with Debug & Release and No sanitizers, Address sanitizer and Thread Sanitizer to test it with different configurations. 23 | 24 | ### 2. Extend MetaCall Scripts 25 | 26 | Make metacall-environment.sh script support macOS besides Linux. It checks if the OS is Linux or macOS and installs the dependencies accordingly. Also, it configures any needed CMAKE flags for the build process. 27 | 28 | ### 3. Fix MacOS build issues 29 | 30 | With help of ORG mentors we were able to fix all MacOS build issues. 31 | 32 | ## Pull Requests 33 | 34 | | PR | Description | Status | 35 | |----------|----------|----------| 36 | | [#383](https://github.com/metacall/core/pull/383) | Add initial macos pipeline and scripts | Merged | 37 | | [#391](https://github.com/metacall/core/pull/391) | Build with Python support for MacOS | Merged | 38 | | [#405](https://github.com/metacall/core/pull/405) | Build with Java support for MacOS | Merged | 39 | | [#428](https://github.com/metacall/core/pull/428) | Build with Ruby and Pass cmake options using env file macOS | Merged | 40 | | [#433](https://github.com/metacall/core/pull/433) | Enable Wasm support in macOS | Merged | 41 | | [#435](https://github.com/metacall/core/pull/435) | Use Pre-built Node for macOS | Merged | 42 | | [#436](https://github.com/metacall/core/pull/436) | Build MetaCall with TypeScript Support | Merged | 43 | | [#437](https://github.com/metacall/core/pull/437) | Build MetaCall with rpc and file support for macOS| Merged | 44 | | [#439](https://github.com/metacall/core/pull/439) | Build MetaCall with Cobol Support for macOS | Merged | 45 | | [#446](https://github.com/metacall/core/pull/446) | Some improvements to macOS CI | Merged | 46 | | [#454](https://github.com/metacall/core/pull/454) | Enable Backtracing in macOS CI | Merged | 47 | | [#455](https://github.com/metacall/core/pull/455) | Enable GO ports in macOS CI | Merged | 48 | 49 | ## Raise Issues 50 | 51 | | Issue | Description | Status | 52 | |----------|----------|----------| 53 | | [#401](https://github.com/metacall/core/issues/401) | MacOS CI goes into deadlock while testing with nodeJS | Closed | 54 | | [#408](https://github.com/metacall/core/issues/408) | Ruby fails on macOS CI | Closed | 55 | | [#426](https://github.com/metacall/core/issues/426) | Sanitizer Fails on macOS | Closed | 56 | | [#427](https://github.com/metacall/core/issues/427) | Clang Warning on macOS | Closed | 57 | | [#440](https://github.com/metacall/core/issues/440) | Build fails in macOS after adding C support | Closed | 58 | | [#447](https://github.com/metacall/core/issues/447) | macOS build CI fails with netcore7 | Open | 59 | 60 | ## Future Work 61 | 62 | - [ ] Add more languages support for macOS (Rust, NetCore) 63 | - [ ] Fork nodejs library build 64 | 65 | -------------------------------------------------------------------------------- /submissions/creatoon.md: -------------------------------------------------------------------------------- 1 |

2 | 3 |

4 | 5 |

GSOC 2023 with Metacall

6 | 7 | ## What the heck is metacall? 8 | 9 |

MetaCall is a polyglot runtime environment that lets developers call functions and methods between different programming languages. For example, we can call a Python function from a Node.js file. It supports languages like NodeJS, C++, C, Ruby, Python, C# & Typescript.

10 | 11 | ## Metacall FaaS 12 | 13 |

The Metacall FaaS, which lets you deploy your functions into the Metacall dashboard, is another tool that Metacall offers.

14 | 15 |

For those who don't understand what FaaS is, let me explain :-

16 | 17 | ``` 18 | In simple words, as a developer, you don't need to worry about managing servers, devops, or anything else, all you need is your functions (the application's entity), and Metacall FaaS will turn it into an API endpoint so you can use it in any way you like. So you can see how intriguing it is and how much time it will save you. Applications that previously took months to develop may now be created in as little as 4-5 hours because of the reduction in complex/unnecessary work. 19 | ``` 20 | 21 | Visit metacall.io for more information on Metacall FaaS. 22 | 23 | So, earlier the graphical interface of dashboard.metacall.io can be used to access the Faas service from Metacall in which you have to buy the plans to test the Faas, therefore as part of Google Summer of Code 2023, I set out to develop the whole Faas service which mimics the real Faas and developers can now easily test the behaviour of real Faas in their local environments (localhost). 24 | 25 | 26 | You can find our work on github Metacall Faas. 27 | 28 | ## How it works? 29 | 30 | ``` 31 | MetaCall deployments takes your code package, being inside a repository or zip, loads it into metacall's runtime and runs selected modules, exposing to the local ports that are opened, it also exposes exported functions from modules as serverless functions, and static files. 32 | ``` 33 | 34 |

Let me tell you how you can convert your JavaScript functions into an API endpoints although it supports many languages.

35 | 36 |

Steps to be followed :-

37 | 38 | `Step 1` :- Initialize NodeJS using `npm init -y`. 39 | 40 | `Step 2` :- Create any .js extension file (ex - `sum.js`) and write functions and export them. 41 | 42 | ```js 43 | export const sum = (a, b) => a + b; 44 | ``` 45 | 46 | Now that you are almost finished, all that is left to do is generate the `metacall.json` file, which you can do manually or on the fly as if you like. Below is an example of how to manually construct this file. 47 | 48 | ```json 49 | { 50 | "language_id": "node", 51 | "path": ".", 52 | "scripts": ["sum.js"] 53 | } 54 | ``` 55 | 56 | `Step 3` :- Install metacall-deploy package using `npm install --global @metacall/deploy` 57 | 58 | `Step 4` :- Clone metacall-faas package using `git clone https://github.com/metacall/faas.git` 59 | 60 | `Step 5` :- 61 | 62 | ```sh 63 | 64 | # Currently you have to use the cloned version, soon we will ship this project as an npm package 65 | 66 | $ cd /faas && npm start 67 | 68 | ``` 69 | 70 | `Step 4` :- In your terminal, execute - `metacall-deploy --workdir=PATH-TO-YOUR-APP-DIRECTORY --dev` 71 | 72 |

And your application will be deployed within no time.

73 | 74 | ## Here is the quick video explanation for the whole process. 75 | 76 | [![Click to Play](https://i.ibb.co/Cm104BN/Screenshot-2023-08-27-201811.png)](https://youtu.be/UUPjUFgWmns) 77 | 78 | 79 | ## Work done for achieving all the things I mentioned above 80 | 81 |

The major goals of my GSoC with Metacall were completed. These goals were -

82 | 83 | ### 1. Implementing all the handlers for the flags that can be expected from Metacall Deploy - 84 | 85 | Metacall deploy provides 15 CLI flags to consume API endpoints provided in Metacall Protocol. A list of all supported options can be found here. 86 | 87 | So the handlers for above flags are mentioned below 88 | 89 | ### 2. Support for all the flags I added 90 | 91 | | Flag | 92 | | ---------------------- | 93 | | `--validate` | | 94 | | `--workdir` | 95 | | `--addRepo` | 96 | | `--delete` | 97 | | `--inspect` | 98 | | `--force` | 99 | | `--logout` | 100 | | And a lot More | 101 | 102 | 103 | 104 | ### 3. Other Works 105 | So till the end of GSOC 2023, I managed to make more than 17 commits and more than 5500 lines of code, not only I contributed to this project, my work doesn't end here and I will be contributing and maintaining this repository completely till the end, I also contributed to other projects like ```Metacall Deploy``` & ```Metacall Protocol```, I was considered as one of the most autonomous devs of Metacall, I always believed only code contributions are not only the way to support open source communities that's why I tried to collaborate with others and arranged meetups and tech talks for metacall. 106 | 107 | ## Conclusion 108 | 109 | The ability to quickly and efficiently deploy your raw functions to the metacall faas via metacall deploy is a game-changer. 110 | 111 | There are a lot of learnings that come along with experience and familiarity with the core team and community. Collaboration and team effort are key for the success of any large-scale project. 112 | 113 | Community is really important. Never lose sight of the problem we're trying to solve, and constantly pay attention to the needs and worries community. 114 | 115 | Following design patterns and modifying pre-existing code help keep the application's consistency. Always create code that is easy to scale, manageable, and loosely connected. 116 | 117 | The most significant development in my career has definitely been GSoC and Metacall. I am really grateful to Google and Metacall for providing me with this fantastic platform. This opportunity has unquestionably had a profound effect on me. I've been able to advance from being an open-source contributor to an open-source maintainer because of it. 118 | -------------------------------------------------------------------------------- /submissions/gpt-deploy.md: -------------------------------------------------------------------------------- 1 |

GSOC 2023 with Metacall - GPT-Deploy

2 | 3 | ## What is metacall? 4 | 5 |

MetaCall is a polyglot runtime environment that lets developers call functions and methods between different programming languages. For example, we can call a Python function from a Node.js file. It supports languages like NodeJS, C++, C, Ruby, Python, C# & Typescript.

6 | 7 | ## Metacall GPT-FaaS 8 | 9 | Metacall aims to provide a multi-language and multi-platform FaaS solution. It allows you to write functions in different programming languages and then deploy and execute those functions in a serverless environment. This can help simplify development and deployment processes, as you can choose the best-suited programming language for specific tasks without being limited to a single language. 10 | 11 | Metacall FaaS essentially acts as a bridge between different programming languages, allowing them to communicate and be executed seamlessly in a serverless context. This can be particularly useful in scenarios where different parts of an application are written in different languages or when developers want to leverage the strengths of various languages within the same project. 12 | 13 | 14 | More about metacall FaaS at metacall.io 15 | 16 | 17 | ## Now What is GPT-Deploy 18 | 19 | - Although Metacall FaaS is great way to deploy. But in the era of AI, metacall needs to upgrade itself. So I created a intelligent deployer leveraging ChatGpt which on prompting gives us functions. 20 | - The Function generated can be in any language based on selected options. It generates function in multiple language and is trained to use previously generated functions . It automatically generates necessary menifest files like metacall.json to entry point. 21 | - Not only it automatically imports function from same language it also does for different language too using metacall api. 22 | - It is not only for automatically generating and co-piloting function generataion but also includes several more features. 23 | - Getting ready made function from AI with gpt-deploy, user can download generated function files as zip or simply can deploy in 1 click on provided UI. 24 | - User can drag and drop files, folder or zip files to either deploy directly to metacall faas or create prompt which can be edited intelligently. 25 | - User can track his deployed files, remove deployments and do many manipulations to the deployments 26 | - UI has been provided to run the function-api that gets created without and POSTMAN client. 27 | 28 | ## Work done for achieving all the things I mentioned on proposal 29 | 30 |

All the goals proposed has been completed. I have created more features than I proposed.

31 | 32 | ### 3. My Works 33 | - Uptill the end of GSOC'23, I commited more than 150 commits and it includes several commits that were removed due to copying to metacall repo. 34 | - Project Creation 35 | - CI/CD pipeline for auto deployments. 36 | - While doing So, I founded many issues which I reported to respected admins like vicente sir. 37 | - I have done all backend , frontend and most part of UI designing. 38 | - I myself have developed the architecture. 39 | - I have created it flexible and scalable for more language addition. 40 | - For now it only supports Python and Node.js. 41 | 42 | ### Future Prospect 43 | - Although my work includes all the basic to mid level functionalities but in order to maximize its potential we have to upgrade gpt-deploy. 44 | - New langauge like C#, C/C++, java , rust and many more has to be added. I have created it scalable so it won't be hard though for new comers. 45 | - Several modification in UI could be done for smooth user experience based of clients feedback. 46 | - datatype integration in GUI for meaningful output on api call 47 | 48 | ### Screenshots 49 | 50 | ![image](https://github.com/metacall/gsoc-2023/assets/66236446/8f4c9a52-c75b-4cb4-9767-5e33694a0864) 51 | ![image](https://github.com/metacall/gsoc-2023/assets/66236446/15a9f0bd-119f-4914-b7ed-d667f2d6f433) 52 | ![image](https://github.com/metacall/gsoc-2023/assets/66236446/d6742395-2013-43bb-84b6-a767a6144c9d) 53 | ![image](https://github.com/metacall/gsoc-2023/assets/66236446/0d204b01-a789-4c50-8f7e-d8d20c9a7a8c) 54 | ![image](https://github.com/metacall/gsoc-2023/assets/66236446/f8c2e982-f862-468e-b6ff-dca000f396bd) 55 | ![image](https://github.com/metacall/gsoc-2023/assets/66236446/a26335d1-ee2c-45cb-8fa6-d64687de8a6a) 56 | ![image](https://github.com/metacall/gsoc-2023/assets/66236446/aacf9e5f-18c0-4caf-8d6f-dc5c9033f196) 57 | 58 | ## Learnings 59 | 60 | - A user-friendly interface enhances the potential for altering clients' perspectives on Metacall through its various features. 61 | - Profound insights come hand in hand with experience and getting well-acquainted with the core team and the community. Collaborative efforts and teamwork stand as vital components in ensuring the success of any large-scale project. 62 | - The community holds immense significance. It's crucial to always keep the problem we're addressing in focus and consistently address the needs and concerns of the community. 63 | - By adhering to established design patterns and making adjustments to existing code, we can maintain a consistent user experience throughout the application. Strive to create code that is easily scalable, manageable, and loosely interconnected. 64 | - Reflecting on my career journey, participating in GSoC and my involvement with Metacall stand out as the most pivotal developments. I hold deep gratitude towards Google and the Metacall team for offering me such an exceptional platform. This opportunity has undoubtedly had a profound influence on me, propelling my progression from being an open-source contributor to an open-source maintainer. 65 | -------------------------------------------------------------------------------- /submissions/windows-ci-pkspyder007.md: -------------------------------------------------------------------------------- 1 | 2 | ![MetaCall-windows](https://github.com/metacall/gsoc-2023/assets/98312397/5461aca3-79c2-467c-81ba-5af0a3b83168) 3 | # Google Summer of Code 2023: Improve CI/CD for MetaCall Core Windows 4 | 5 | ## Table of Contents 6 | - [Introduction](#introduction) 7 | - [Objectives](#objectives) 8 | - [Technologies Used](#technologies-used) 9 | - [Implementation](#implementation) 10 | - [Phase 1: Setup and Configuration](#phase-1-setup-and-configuration) 11 | - [Phase 2: Integrating with CMAKE variables](#phase-2-integrating-with-cmake-variables) 12 | - [Phase 3: Adding new languages and bugfixes](#phase-3-adding-new-languages-and-bugfixes) 13 | - [Results and Outcomes](#results-and-outcomes) 14 | - [Future Work](#future-work) 15 | - [Work Done](#list-of-prs-raised-during-the-project) 16 | 17 | ## Introduction 18 | MetaCall Core has an intensive test case which is mainly focused on Linux (including Sanitizers in order to detect memory, address, undefined behavior or threading bugs). Currently, we are improving the Windows CI/CD support with MSVC. 19 | 20 | ## Objectives 21 | - To implement and complete testing CI/CD for Windows to run with different compilers (MSVC for now). 22 | - Packaging dependencies of `metacall/core` in an efficient and scalable manner. 23 | - Easy updates and new language addition to CI pipeline for windows setup. 24 | - Remove vendor lock-in for pipeline. 25 | 26 | ## Technologies Used 27 | A non-exhaustive list of the tools, platforms, and technologies used in the project: 28 | C/C++, CMake, Bash, Batch, PowerShell, Github, etc. 29 | 30 | ## Implementation 31 | 32 | ### Phase 1: Setup and Configuration 33 | The biggest blocker for starting the development of the project was to have the build running locally for windows to test changes since changes code and waiting for the CI to run was not efficient and consistent. 34 | 35 | I created a local environment that mimics the CI pipeline by updating the tools (scripts) that are responsible to build Metacall core. 36 | 37 | I have written an article on [How to seetup Metacall development environment on windows](https://www.codu.co/articles/setting-up-metacall-development-environment-on-windows-jxk6iltl) to make it easier for new contributors to get up and running soon with the project. 38 | 39 | 40 | ### Phase 2: Integrating with cmake variables 41 | Metacall heavily depended upon patching environment variables for CI pipleline which was hard to maintain and keep track of. 42 | We are working on migrating the existing dependencies to use `CMAKE` variables to configure the project instead of patching the env. 43 | 44 | Here is the PR for the required instrumentation [#394](https://github.com/metacall/core/pull/394). 45 | Example implementation PR for Ruby integration [#415](https://github.com/metacall/core/pull/415). 46 | 47 | ### Phase 3: Adding new languages and bugfixes 48 | At the time of writing we are having support for the following languages in windows CI - `python, nodejs, java, ruby, typescript, wasm, rpc`. 49 | 50 | PRs for adding support for `file and C` loader are in progress, requiring investigation bug causes in the `core` itself. 51 | 52 | Remaining major languages which are not supported in windows CI are the following: 53 | ```C / .Net / Rust``` 54 | 55 | 56 | ## Results and Outcomes 57 | - Higher test coverage on windows. 58 | - Improved core due to bugfixes discovered during CI implementation. 59 | - No more patching required for CI 60 | - Closer to no vendor lock-in state. 61 | 62 | ## Future Work 63 | The project still has some major languages missing from the CI like `C, Rust`. In the future it would be great to support these languages as well, although the complexity of their implementation is substantial. Also we should look into a windows distribution system for metacall. 64 | 65 | 66 | --- 67 | 68 | ### List of PRs raised during the project 69 | 70 | | PR | Description | Status | 71 | |----------|----------|----------| 72 | [#363](https://github.com/metacall/core/pull/363) | Fix missing headers in node loader port | Closed 73 | [#364](https://github.com/metacall/core/pull/364) | Fix NodeJS tests in GitHub CI | Merged 74 | [#365](https://github.com/metacall/core/pull/365) | Ruby win ci tests setup | Closed 75 | [#367](https://github.com/metacall/core/pull/367) | Add Java tests to Windows CI | Merged 76 | [#394](https://github.com/metacall/core/pull/394) | Remove patching from ci | Merged 77 | [#396](https://github.com/metacall/core/pull/396) | TS loader dependency copying CMAKE | Closed 78 | [#402](https://github.com/metacall/core/pull/402) | Add npm exec path to cmake vars | Merged 79 | [#415](https://github.com/metacall/core/pull/415) | Add ruby support to windows CI tests | Merged 80 | [#431](https://github.com/metacall/core/pull/431) | Wasm Windows CI setup | Closed 81 | [#432](https://github.com/metacall/core/pull/432) | Add typescript tests to windows CI | Merged 82 | [#452](https://github.com/metacall/core/pull/452) | Add rpc support on win ci | Open 83 | [#458](https://github.com/metacall/core/pull/458) | C windows CI setup | Draft 84 | 85 | --- 86 | --------------------------------------------------------------------------------