Google Summer of Code 2022 proposed ideas

Contributors interested to participate should check which of the following projects fits their interests and skills.

Τo communicate with the mentors and ask questions about the projects, students should subscribe to this list and post relevant questions. Please follow the Proposal Template

For practical information, developers should visit this page.

Workflow and Parallelization patterns for Node-RED

Brief Explanation

Node-RED (https://nodered.org/) is a popular low code programming environment for event driven applications, particularly in the IoT world. It is based on a visual, browser based editor in which developers can write functions, wire them together to form a workflow, group a subset of functions into reusable and parametric subflows etc. Node-RED can interact with any API or service, thus its usage can be extended to be used in collaboration with other services, e.g. Function as a Service platforms, as an orchestrator.

The project revolves around the idea of using Node-RED as an orchestrator for FaaS functions. For a first look and feel of the scope you can visit this technical report: https://arxiv.org/pdf/2202.09683.pdf

Initial flows that have been created on this scope and can be used as examples can be found here: https://flows.nodered.org/flow/7a5acfc999b1ad47bb32b5d37419c777/in/G33TNU6z-Qia

Points for contribution around the proposal include: - Adaptation of a coordinating logic on the node-red environment by creating a relevant flow that implements it. This flow may regulate how Openwhisk functions are invoked, results gathered and forwarded to new functions etc. Coordinating logic can be inspired by: workflow constructs or primitives (e.g. https://www.researchgate.net/figure/Basic-workflow-constructs_fig1_226149698) parallel or distributed computing primitives (e.g. MPI-related patterns for distributing work http://www.mathcs.emory.edu/~cheung/Courses/355/Syllabus/92-MPI/group-comm.html) Cloud design patterns rationale (https://docs.microsoft.com/en-us/azure/architecture/patterns/), for which a relevant flow can be implemented to support them

-Packaging of that flow as a subflow and adding parameters of operation and configuration (from the UI or through the incoming message fields)

Expected Results

The purpose of the work is to exploit Node-RED's subflow and workflow features in order to implement reusable flows that can be shared through Node-RED's repository. The initial scope of the flows is around workflow primitives for easier workflow creation, parallelization patterns (e.g. migrating logic and patterns from MPI to node-red, implementation of orchestration logic for parallel AI operations and learning etc). This can be coupled with function creation for executing the workflows in state of the art function as a service environments like Openwhisk, for actual computational parallelism.  

Duration of the Project

350 hours

Related repositories

https://flows.nodered.org/,

https://github.com/node-red,

https://flows.nodered.org/flow/7a5acfc999b1ad47bb32b5d37419c777,

https://gist.github.com/gkousiouris/7a5acfc999b1ad47bb32b5d37419c777

Knowledge Prerequisites

Javascript,  Knowledge of Node-RED or FaaS is a plus

Mentors:

George Kousiouris, Christos Diou

Build recorder: A system to record what goes on when a software is being built.

Brief Explanation

The purpose of a project is to fully record the interactions between assets (files and tools) when a software component is being built (compiled). For example, when compiling a software written in C,the system will record the source files being compiled, the generated object files being linked, the final executable, as well as the compiler used, the options given, and the environment.

Duration of the Project

350 hours

Related repositories

New project, no existing repo available.

Knowledge Prerequisites

one or (preferably) more of compiled languages: C, C++, Go, Rust, Java, ...

Mentors:

Alexios Zavras

Flexbench

Brief Explanation

Flexbench is a benchmarking tool used mostly for stress and performance testing of web application servers. It is a forked project from the http-traffic-simulator npm package, which was developed to provide simulated throttled http traffic for testing purposes, towards specific http endpoints. It utilizes the nodejs cluster module to generate http requests, by spawning multiple workers (balanced over the system cores) in the cluster, responsible to create clients that generate requests. This architecture enables the simulator to scale in really big throughputs. The main supported features are:

Duration of the Project

Depending on the scope and the technologies tackled

Expected Results

- Create a GUI using flutter - Offer it as desktop app (package it and make it run as a standalone app in Windows, macOS and Linux) - Offer it as a web server exposing REST APIs - Support authentication and authorization for REST APIs, preferably with OpenIDC. - Support GraphQL - Migrate to typescript - Dockerize, produce the required artifacts to deploy to kubernetes. - Integrate Nginx proxy - Implement a DSL language to describe scenarios that can be executed by flexbench (eg. store a scenario under a .flxb file ) - Implement an editor for .flxb files with syntax highlighting support

Related repositories

https://github.com/flexivian/flexbench https://www.npmjs.com/package/http-traffic-simulator, https://github.com/iskitsas/http-traffic-simulator

Knowledge Prerequisites

NodeJS, js, typescript, Html, Css, flutter, docker

Mentors:

Ilias Kyrannas (iliaskyrannas@gmail.com), Giannis Skitsas (iskitsas@gmail.com)

Interoperability of GitLab boards with Nextcloud Decks

Brief Explanation

Nextcloud is free software for cloud collaboration. Nextcloud consists of core functionality plus installable apps. One of the apps is "Deck", that provides Kanban boards. GitLab also provides Kanban boards.

There exists a Nextcloud "GitLab" app which provides some integration of GitLab with Nextcloud, but it does very little. Its only substantial functionality is to show a panel with "GitLab todos" in the Nextcloud dashboard (which serves as the user's home page). That is, it provides a list in the user's Nextcloud dashboard that shows the next things the user has to do in GitLab. Each "todo" is just a title and a link to GitLab.

This project is about extending the GitLab-Nextcloud integration so that a user can see and manage the GitLab boards in Nextcloud's Deck application.

Duration of the Project

350 hours

Expected Results

Some organizations use both Nextcloud and GitLab. Some of their kanban boards tend to be on GitLab and some other on Nextcloud. Developers tend to use more GitLab, while non-developers tend to use Nextcloud. This project is expected to reduce duplication and help developers and non-developers co-operate better.

Related repositories

<https://github.com/nextcloud/deck/>

<https://github.com/nextcloud/integration\_gitlab>

Knowledge Prerequisites

JavaScript, PHP, Vue, Web APIs

Mentors:

Antonis Christofides

Label Buddy 2.0: Automated audio-tagging using transfer learning

Brief Explanation

Label Buddy is an open-source audio annotation tool created during GSoC 2021. It aims to make the annotation process easy, simple and at the same time offer a well-defined manager-annotator-reviewer system. The purpose of this project is to integrate Transfer Learning (TL) techniques (taking advantage of knowledge gained for one problem and applying it to this problem) to make the annotation process less tedious by providing label predictions for the user. This approach will allow us to do more with less data and effort.

Duration of the Project

350 hours

Expected Results

1. Machine Learning
   • Conduct research for the appropriate model architecture
   • Modify the annotation process by integrating the model
   • Test the model by providing evaluation metrics
2. Django
   • Add lazy loading for the audio files: load segments of the file when needed (i.e., YouTube). This will lead to better performance when the audio file is too big.
   • Add Django Testing
   • Dockerization
   • Add documentation
   • Add rar file upload functionality - currently, users can only upload zip files (optional)
   • UI improvements (optional)

Related repositories

https://labelbuddy.io/ (username: demo, password: labelbuddy123)

https://github.com/eellak/gsoc2021-audio-annotation-tool

https://www.youtube.com/watch?v=SdbGhrad-GQ

https://github.com/jordipons/sklearn-audio-transfer-learning

https://github.com/jordipons/musicnn

https://prodi.gy/docs/audio-video#model

Knowledge Prerequisites

Machine Learning (ML) frameworks, Python, Django, VanillaJS, HTML

Mentors:

Ioannis Sina (sinaioannis@gmail.com), Agisilaos Kounelis (kounelisagis@gmail.com), Pantelis Vikatos (pantelis@orfium.com)

Development of a backend management system for NodeRed instances

Brief Explanation

NodeRed is one of the most well known low-code IoT programming tools, offering a large number of ready-to-use libraries. Nevertheless, it lacks modern aspects of system deployments, like multi-user server functionalities, since one NodeRed deployment can support only one user. In this context we propose a backend system written in Python or NodeJs, that will provide a web-based API (e.g. REST), via which the management (creation, deletion and deployment) of NodeRed instances will be performed. Each NodeRed instance will be deployed either on-system, or even better using containers (e.g. Docker). Furthermore, the system will support saving annotated NodeRed deployments which contain specific nodes (or flows), so as to easily create new deployments that offer personalized/aggregated functionality. E.g. if a user creates flows annotated as "Raspberry Pi GPIO" and another creates "Google Firebase", the system should be able to create a new NodeRed instance that contains one of these flow sets or both, according to what the end user needs.

Duration of the Project

350 hours

Expected Results

Creation of a backend system, able to manage annotated NodeRed instances

Related repositories

https://github.com/node-red/node-red

Knowledge Prerequisites

Required: Python or NodeJS, JavaScript, OpenAPI, Containers. Desired: NoSQL databases, Full Stack development

Mentors:

Emmanouil Tsardoulias (etsardou@gmail.com), Konstantinos Panayiotou (klpanagi@issel.ee.auth.gr), Andreas Symeonidis (asymeon@eng.auth.gr)

Testing the type checker of TypeScript

Brief Explanation

Despite the substantial progress in compiler testing, research endeavors have mainly focused on detecting compiler crashes and subtle miscompilations caused by bugs in the implementation of compiler optimizations. Surprisingly, this growing body of work neglects other compiler components, most notably the front-end. In statically-typed programming languages with rich and expressive type systems and modern features, such as type inference or a mix of object-oriented with functional programming features, the process of static typing (i.e., type checking) in compiler front-ends is complicated by a high-density of bugs. As a recent study has shown [1], such bugs can lead to the acceptance of incorrect programs (breaking code portability or the type system’s soundness), the rejection of correct (e.g. well-typed) programs, and the reporting of misleading errors and warnings.

Hephaestus is a testing framework for validating compilers' type checkers, which is based on both program generation and transformation-based compiler testing. Hephaestus' program generator yield well-typed programs that are more likely to trigger typing bugs. Hephaestus reports a bug when the compiler under test is unable to compile the given program. Note that the programs generated by Hephaestus are written in an intermediate language (IR). Then, Hephaestus employs language-specific translators to convert an "abstract" program into a program written in the target language. This feature enables Hephaestus to test compilers of different programming languages. Finally, Hephaestus also supports two testing approaches based on transformation-based testing, which are used to find type inference and soundness bugs respectively.

Currently, Hephaestus is used for testing the compilers of three popular programming languages, namely, Java, Kotlin, and Groovy. Hephaestus has found over 150 bugs in these compilers. Most of these bugs have been fixed by developers, and lie in many critical components related to static typing, such as type inference.

In this project, the student has to extend Hephaestus to test the compiler of TypeScript. TypeScript is the statically-typed variant of JavaScript; an object-oriented language supporting advanced type system features, such as type inference, parametric polymorphism, structural typing, and more. As part of the project, the student is expected to use the extended version of Hephaestus to find and report real bugs in the TypeScript compiler.

[1] https://dl.acm.org/doi/pdf/10.1145/3485500

Duration of the Project

350 hours

Expected Results

It is expected that the project will deliver an extended version of Hephaestus that is capable of finding real bugs in the compiler of TypeScript

Related repositories

https://github.com/theosotr/hephaestus

Knowledge Prerequisites

Good programming skills (in particular Python), good knowledge of object-oriented programming, familiarity with Java generics

Mentors:

Thodoris Sotiropoulos, Stefanos Chaliasos, Dimitris Mitropoulos, Diomidis Spinellis

Real-time Graph-Clustering and Visualization for Architecture Recovery from Class-Dependency Analysis on Very Large Source-Code Bases

Brief Explanation

We have already developed the first generation of a tool for architecture recovery from C++ sources by: (i) tracking dependencies, (ii) preparing a global dependency graph; and (iii) applying graph clustering to compute and visualize likely architectural modules. The tool uses Clang (open source, C++) for the frontend and Go.JS (2d) for the backend (graph rendering and GUI). Numerous practical shortcomings were identified when processing very large projects, above the magnitude of many hundreds of source files and classes.

This project concerns the implementation of the second generation of our tool, still involving Clang, but with the extension to allow incremental analysis of large projects with progress monitoring. Users will be capable to suspend the analysis process at any point, possibly exit the system, and resume it latter or restart it, even on a different machine.

Concerning the backend, we will adopt Ogre 3d (open source, C++) and fully implement from scratch the visualizer for improved (visually rich) and faster (GPU accelerated) rendering, while fully exploring with alternative implementations of layouts and topologies in 3d for the graph itself and for the architectural clusters denoting components. The GUI will be implemented using wxWidgets, and all clustering algorithms will be implemented in C++.

Expected Results

This project concerns the implementation of the second generation of our tool, still involving Clang, but with the extension to allow incremental analysis of large projects with progress monitoring. Users will be capable to suspend the analysis process at any point, possibly exit the system, and resume it latter or restart it, even on a different machine.

Concerning the backend, we will adopt Expected ResultsOgre 3d (open source, C++) and fully implement from scratch the visualizer for improved (visually rich) and faster (GPU accelerated) rendering, while fully exploring with alternative implementations of layouts and topologies in 3d for the graph itself and for the architectural clusters denoting components. The GUI will be implemented using wxWidgets, and all clustering algorithms will be implemented in C++.

Duration of the Project

350 hours

Related repositories

Clang (https://clang.llvm.org/)

Ogre 3d (https://www.ogre3d.org/)

wxWidgets (https://www.wxwidgets.org/)

Knowledge Prerequisites

Clang, Go.JS ,Ogre 3d, wxWidgets

Mentors:

Antonios Savidis

Development of a DIY robot kit for educators

Brief Explanation

In GSoC 2019, one of the final projects was “A DIY robot kit for educators”. In this project, the contributor, Christos Chronis, designed and implemented a 3D printable robot for educational purposes from scratch. Electronic parts, such as cables, sensors, buttons, camera, accelerometer, LED set, as well as 3D printed parts were used to assemble the robot alongside with the code written in order to program it. Two years later, in GSoC 2021, the contributor developed another version of “A DIY robot kit for educators” with a Node-Red integration, based on the project of GSoC 2019.

As the contributor of GSOC 2019 mentioned in his wiki page there is still a lot of work to be done, so that the original project (Proteas robot) can be improved and maybe be a direct competitor to any commercial alternative on educational robotics. Based on the work of the two previous contributors, I would like to propose my idea for GSOC 2022, which includes the robotic designs, the guidelines, the integration of the robot with Google Blockly and improvement of the back end code with a custom library for special control of every electronic part and sensor.

All of the parts of the modular robot are gonna be designed this way so that they are 3D-printable. The 3D-printed parts together with basic low-cost electronics and sensors can be  easily combined to assemble the robot following the guidelines. Extensive and simple guidelines of how to print and assemble the robot will be provided, so that non-expert staff in robotics, electronics or IoT programming, will be able to follow them successfully. Alongside with the guidelines, the staff will also be provided with a number of demo scenarios for the class, e.g. simple navigation or sensing scenarios, that require basic programming skills.

The development of a desktop application will mainly consist of the open-source Google Blockly. Blockly is a free, open source web-based, visual programming editor, developed by Google. Users can drag blocks together to build programs. It is similar to Scratch, that the contributor of GSoC 2019 proposed, but it can be a lot easier configured, as it is open source and offers a lot more possibilities, such as custom creation of Google Blockly blocks or preferred language selection of the environment. In the GsoC 2021, the contributor made a first approach using Node-red, but Node-red demands specialized knowledge in its usage and it is not suitable for younger ages. So, the kids and adolescents can use our application for learning visual programming by using the custom blocks to build programs and then the robot can execute them in real time. The application and the robot can be used in STEM education for different experiments. Educators already know Scratch, so adjusting to Google Blockly will be an easy process. The desktop application will be wirelessly connected to the robot, so that the robot can execute the programs built and run by the students. The desktop application will be implemented in such a way, so that it is suitable for students, e.g. colorful and interactive design, pop ups for extra information or to notify the student if an action was successful or not. There will also be the option to save or import Blockly code. The already implemented code can be saved/ extracted into an xml file that will be downloaded in a preferred folder in the computer. Such an xml file can be imported into the application for later use.

In order for the Blockly integration to be possible, it is going to be essential for some parts of the existing code of the GSoC 2019-2021 robot to be rewritten. This means that back end code that runs in the Raspberry Pi and controls all the movements of the robot, will be improved. For that reason, I will create a custom functionality library (e.x. PID Controller) for special control of every electronic part and sensor. Based on the fact that the GSoC 2021 contributor introduced for the first time the logic of microservices, microservices and dockerization can be utilized so that different services run for controlling the robot movements as well as the communication between the Blockly desktop application and the Raspberry Pi.

Expected Results

Within the months of the project the expected results are:

• Understanding previous work
• Rewrite core library ( Backend code )
• Create microsreliable communication between Frontend - Backend code
• Frontend implementation
• Educational scenarios for the class

Duration of the Project

350 hours

Related Repositories

https://hackaday.io/project/26007-versatile-educational-2wd-robot

https://gist.github.com/yiorgosynkl/914e75d0f9ae98bb31f4d8da66ec9908

https://gist.github.com/chronis10/9d069c56b3df9c92693ac8d24270a62a

https://github.com/isl-org/OpenBot

Mentors:

Iraklis Varlamis, Christos Chronis

Greek glyphs in Open Source Fonts: additions and redesign

Brief Explanation

Many of the Open Source fonts (e.g., available at https://fonts.google.com), do not include glyphs for Greek letters and are therefore useless for using in a Greek environment. The aim of this project is to improve this situation and add the missing glyphs in the correct Unicode codepoints. The exact set of fonts to be completed will be determined in discussions between the student and the mentor(s).

This is not a typical programming project. If you have never designed fonts before, it is probably not for you.

Duration of the Project

350 hours

Expected Results

Full support for Greek text in a number of Open Source fonts.

Related repositories

Addition of Greek glyphs in:

- Merriweather (12 upright +12 italics) https://github.com/EbenSorkin/Merriweather
- Spectral (3 upright +3 italics) https://github.com/productiontype/Spectral
- WorkSans  (3 upright +3 italics) https://github.com/weiweihuanghuang/Work-Sans

Redesign of existing Greek glyphs in:

- Fira (all styles) https://github.com/mozilla/Fira
- Vollkorn (all styles) https://github.com/FAlthausen/Vollkorn-Typeface

Knowledge Prerequisites

Type design, font technologies. Please note that this is a special project, where coding, in the traditional sense, will not be enough.

Mentors:

Irene Vlachou, Εmilios Τheofanous, Alexios Zavras

Apothesis

Brief Explanation

Apothesis is an open source software for simulating deposition processes via the kinetic Monte Carlo method. This is the first step for creating a generalized kinetic Monte Carlo code for studying surface growth phenomena.  Apothesis currently lucks generalized I/O operations. The goal is to develop the I/O part of the software in order to be easy to use by many researchers. For kMC codes this is far from trivial since the I/O depends on the underlying physical system. That said, the input can be different when studying 2D materials compared to 3D systems. Regarding the output, this is defined by the properties of that a researcher wants to study.  

Expected Results

The necessary classes and infrastructure for the I/O operations of Apothesis.

Duration of the Project

350 hours

Related repositories

https://github.com/nixeimar/Apothesis

Knowledge Prerequisites

C++, JSON

Mentors:

Nikos Cheimarios, Vissarion Fisikopoulos

HELP

Brief Explanation

Brief explanation=HELP is a location based mobile application (LBMA) with integrated emergency communications service, which includes an inbound and an outbound component similar to 112 or 911. You may use it with or without dialing 112 or 911 for free in any emergency anywhere (within available mobile network reception). The inbound component allows you to receive warnings or assistance of any kind and possibly allowing remote usage for the phone to light the flashlight for example or send a voice message. The outbound component will sent automatically location and other data if they are available (from any connected device like smartwatches or other health / sport devices) via multiple technologies and communication channels in case of imminent or occurring incident or dangerous situation constituting an immediate threat to your health and safety, so that you can report the incident and be reached and receive any kind of assistance. This application uses location to provide products or services based on information obtained from one or more smart devices. However, implementation and execution of these services may raise users privacy concerns related to sensitive information being handled so it has to be a FLOSS core application with possible plugins / add-ons for medical or other kind of assistance. On a later phase this application can be installed by default in any smartphone or similar device and will be available on any emergency even without SIM like 112/911.

Expected Results

A location based mobile application (LBMA) with integrated emergency communications service

Duration of the Project

175 hours

Related repositories

New project, no existing repo available.

Knowledge Prerequisites

Native iOS app and / or native Android app development skills.

Mentors:

Christos Iossifidis