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.

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.  

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

Can be either a short or a long-term project, depending on the scope and the technologies tackled.

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)

SciDavis data Analysis and Visualization Program

Brief Explanation

SciDAVis is a free interactive application aimed at data analysis and publication-quality plotting. It combines a shallow learning curve and an intuitive, easy-to-use graphical user interface with powerful features such as scriptability and extensibility. SciDAVis runs on GNU/Linux, Windows and MacOS X; possibly also on other platforms like *BSD, although this is untested. SciDAVis is similar in its field of application to proprietary Windows applications like Origin and SigmaPlot as well as free applications like QtiPlot, Labplot and Gnuplot. What sets SciDAVis apart from the above is its emphasis on providing a friendly and open environment (in the software as well as the project) for new and experienced users alike. Particularly, this means that we will try to provide good documentation on all levels, ranging from user’s manual over tutorials down to and including documentation of the internal APIs We encourage users to share their experiences on our forums and on our mailing lists.More information, including screenshots, reviews, current contributers can be found on the SourceForge project webpage.

SciDAVis has been started as a fork off of QtiPlot with the aim of introducing some changes in design and establishing an open and friendly community. The versions labelled SciDAVis 0.1.0 to 0.1.4 are still very close to QtiPlot 0.9.×. But many new features and a revision of existing ones have been introduced in release 0.2.0. This is especially true for tables and matrices which have internally been rewritten almost completely.

At some time in 2008, the developer teams of LabPlot and SciDAVis found their project goals to be very similar (and since LabPlot 2.x is based on the same library as SciDAVis, i.e., Qt4.x) decided to start a close cooperation. The current plans are to use a common backend with two frontends, one with full KDE4 integration (called LabPlot 2.x) and one with no KDE dependencies (pure Qt so to say) for easier cross-platform use (called SciDAVis). This promises a faster development speed for both projects while focussing on slightly different audiences. From the user's point of view, there will still be two different applications.

At the time of writing, SciDAVis is completely independent of LabPlot, whether the collaboration mentioned in the previous paragraph will ever happen is a moot point.

By 2011, the original development team had moved on to other things, and development of SciDAVis stalled. Stewardship of SciDAVis has passed over to Russell Standish, aka High Performance Coder, an experienced SourceForge project manager. The immediate plan is to focus on bug fixes reported in the SourceForge ticket system, and creating regression tests, whilst the new development team get up to speed with the code base. Russell uses the Aegis source code repository system for managing the releases, so this has meant bumping the version number to 1. Releases within a version number are denoted by the delta number assigned to the code when it is successfully committed to Aegis. At the time of writing the current version is 1.D4, and the plans are for roughly 6 monthly releases, unless a critical bug is found and fixed to bring the release forward, or no development activity has taken place since the last release.

Duration of the Project

Depending on the scope and the technologies tackled

Expected Results

Extending the features of Scidavis open software to adapt the needs of scientific community , creating useful tutorial for the community, contributing to program documentation and translating program features and documentation in Greek

Related repositories

http://scidavis.sourceforge.net/

Knowledge Prerequisites

C/C++, Python, Latex

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

Depending on the scope and the technologies tackled

Expected Results

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

Related repositories

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

https://youtu.be/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

Depending on the scope and the technologies tackled

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 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.

Duration of the Project

Large Size Project

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 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++.

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

The aim of the project will be to develop all the designs, guidelines and sample code for a starter DIY robot kit that can be 3d-printed, assembled and operated using basic electronics and sensors. This is expected to create a low-cost alternative to commercial robot kits (e.g. Lego Mindstorms) that does not require expert staff in robotics, electronics or IoT programming (e.g. using Arduino/Raspberry kits). The ability to 3D-print everything and combine it with low-cost basic electronics and sensors will allow regional open technologies initiatives to provide schools with starter kits and a full 'Robotic 101' introductory course.

The kit that will be developed and opened must comprise 3D-designs for all the necessary parts of a modular robot that can be printed and assembled following the assemble guidelines. The target audience of the project can be educators (e.g. high school ICT teachers), with minimum expertise in robotics, electronics, and programming. So the print and assembly guidelines must be detailed and simple. In addition, the project must have a modular structure that allows educators to guide their students to the step-by-step development of the robot and to the implementation of simple navigation or sensing scenarios, that require basic programming skills.

Deliverables of the project, apart from the robot parts' designs, include a detailed list of the necessary electronics and sensors and the specifications for a Raspberry pi or similar single board computer (SBG).

Detailed assembly instructions, images, and videos from the assembly process are desirable.

The open source code that will be installed and run on the SBG and will allow controlling the robot through a simple programming interface, along with installation guidelines must be developed.

The robot will be operated either manually using a browser that wirelessly connects with the robot, or automatically by uploading robot control scripts through the same environment.

Some sample control scripts and robot programming scenarios will also be developed.