Dear Aris, Thank you for your interest in our project. We do have a communication channel named Apothesis in Element X where we can discuss all your questions. Please join the channel and we will discuss all your questions. Best regards, Nikos > 13 Μαρ 2026, 18:51, ο χρήστης «Άρης Σκυλλάς <arisskyllas2004 [ at ] gmail [ dot ] com>» έγραψε: > > Dear Nikolaos and Vissarion, > > My name is Aristeidis Skyllas and I am a 4th year Computer Science student at the National and Kapodistrian University of Athens. I am writing this mail to express my strong interest in contributing to the project "Python bindings for Apothesis" for GSoC 2026. > > My technical background consists of strong C/C++ knowledge, moderate experience in Python through university work in Machine Learning, SQL and frontend development with React. My most recent work is a university project based on the SIGMOD 2025 programming contest, where we built a parallel hash join pipeline using advanced techniques in C++ such as unchained hash table with bloom filtering, multi-threading and work stealing, late-materialization, column-store and zero-copy to achieve high performance executions. > > In the past few days I have cloned the repository of "Apothesis", explored it in depth, as well as building and running the simulation with the input given. So far I have a general idea of the approach I would follow to create the bindings. I plan using a binding tool such as pybind11 or nanobind to create two layers. The first will consist of raw bindings, wrapping the C++ classes and exposing them to Python. The second layer will be a pure Python wrapper providing a user-friendly API for direct usage. On top of that , there would be unit tests, documentation and usage examples. > > I would really like to hear how you envision the project with these questions: > > 1) How deep do you think the bindings should go? Obviously the user will have bindings for initializing and executing the simulation and getting the results. Beyond that, how deep should the python interface go? Should users also be able to inspect and modify sites of the lattices, change parameters or define processes? > > 2) While studying the code I realized that only the "SimpleCubic" lattice type has been fully implemented. FCC, HCP and Diamond are missing features like readHeightsFromFile(), buildSteps() and computeCoverages(). Are completing these inside the project scope or the bindings are supposed to wrap only the existing functionality? > > If there is another preferred communication channel I would love to join and discuss more ideas. Any answers on the above questions or guidance on how to move forward from here would be greatly appreciated. > > Best Regards, > Aris Skyllas > Github: ArisS44 > ---- > Λαμβάνετε αυτό το μήνυμα απο την λίστα: Λίστα αλληλογραφίας και συζητήσεων που απευθύνεται σε φοιτητές developers \& mentors έργων του Google Summer of Code - A discussion list for student developers and mentors of Google Summer of Code projects., > https://lists.ellak.gr/gsoc-developers/listinfo.html > Μπορείτε να απεγγραφείτε από τη λίστα στέλνοντας κενό μήνυμα ηλ. ταχυδρομείου στη διεύθυνση <gsoc-developers+unsubscribe [ at ] ellak [ dot ] gr>.
---- Λαμβάνετε αυτό το μήνυμα απο την λίστα: Λίστα αλληλογραφίας και συζητήσεων που απευθύνεται σε φοιτητές developers \& mentors έργων του Google Summer of Code - A discussion list for student developers and mentors of Google Summer of Code projects., https://lists.ellak.gr/gsoc-developers/listinfo.html Μπορείτε να απεγγραφείτε από τη λίστα στέλνοντας κενό μήνυμα ηλ. ταχυδρομείου στη διεύθυνση <gsoc-developers+unsubscribe [ at ] ellak [ dot ] gr>.