as I have already announced in previous posts, the Ada community could participate in the Google Summer of Code, aka GSoC. I think this could be a wonderful opportunity to grow the open ecosystem of Ada and make it better. Plus, someone would be getting paid for that, which I and other people find it to be quite important.
The reason I am announcing the possibility to participate in the 2025 edition is because in the last couple of years, while some people showed interest in helping out, it was too late when discussions started… So, I am opening this point soonish. It is not too soon considering that GSoC applications start early in the year and are only open for a few weeks for participating projects. Actually, the GSoC 2025 timeline is already set and publisized!
In order to participate we need to submit an application with projects that would be looking for students and mentors willing to help them.
If we fail to participate or if we are not accepted as a project, we can always lend a hand in third-party projects, such as GCC, where an student and mentor could work on GNAT.
The information about the requirements and how GSoC works can be found here.
Some projects that could be potentially be worked on are:
Improving GNAT support in *BSDs. There are patches in their ports trees, but they would neet to be updated, upstreamed and tested. This could be done within GCC.
Adding parallel to GNAT. This could be done within GCC.
Maybe working on improving GHDL, a VHDL compiler written in Ada.
Improving GNAT-LLVM by updating it to newer LLVM versions, maybe fixing things that are yet not supported (?)
Etc.
I would also like to remind people here that one does no longer need to be a student in order to participate as a working participant! Young people here or people that would like to get more into programming (or come back) are also quite sought after!
I would be happy to mentor anyone interested in implementing some of the Ada 2022 features that have not yet made it into GNAT. Parallel blocks and loops, and the procedural iterator come to mind. These are all really just syntactic sugar on top of some runtime that has already been built – no new code generation required.
That is great to hear. Both of your proposals could be done within the GCC GSoC in case we do not get accepted. I need to read how to make a formal proposal for a GSoC project. Stay tuned.
I can do mentoring.
I notice there’s a LOT of GCC-projects on your list; why is this?
Another thing, a lot of these options are improving on the tooling.
So, secondarily, should we perhaps add to the list something like BATTS? (A bootstrap compiler using Truffle/Graal — because one of the persistent complaints against GNAT is the bootstrapping is painful.)
Hm.
What is the scope of something like this? And, if we’re going with maximizing improving the Ada ecosystem, would it be profitable to have a “project of projects”, where the subprojects themselves are useful in themselves?
If so, perhaps such a project would be a combined Ada+VHDL+PL/SQL IDE, as described here — the whole thing could be done in such a was as to produce immediate benefit for every subproject. (e.g. if a Graph-DB is implemented, then packaging the graph-algorithms [and structures] as libraries; or presenting out a common & proved unification-engine which could be used in SPARK and in the PL/SQL engine, etc.)
One thing that could be added is an easy way to use a different llvm repo for custom targets which have not been added into mainline and specifying what target to build.
Good question. I think I should have given a bit more context as to why
From my point of view, I wanted to focus on “low level” Ada tooling and major improvements. I did not want to mention specific projects from individuals so as to not give preference to someone while detracting from anybody else.
From what I know, the projects that can be presented to GSoC have to have a clear goal and be realistic within the time and resources provided. So one cannot say “work on BATTS”. What specific idea or improvement would you like to see done in BATTS?
Also, keep in mind that the goal is to spread and improve Ada. It would be best to have people writing in Ada. I am saying this as from what I have seen BATTS is written in Java
Afaik, for GSoC one can only propose “simple” tasks within the chosen organisation and projects. Ideally, they should go towards already existing and important projects within the community/language/ecosystem.
While this sounds great, I think greenfield projects are not allowed in GSoC… And again, the scope needs to be quite limited. Generally “students” are paid for 2-3 months of work.
That is somewhat my covert question… Would someone have an idea or need to improve something there? I was more or less asking for concrete ideas by giving some examples
Yes! Me too! That way we could get WASM and all other LLVM targets within Alire!
Though I do not know if packaging “projects” would be approved by GSoC… Maybe improving the packageability of GNAT-LLVM and then having a subtask of adding it to Alire?
It is (Truffle/GrallVM, specifically), for the reason that it is intended to be a bootstrap.
Byron is the Ada-in-Ada compiler project.
This is quite sensible: you can’t evaluate progress-on/achievement-of a goal if there’s no goal.
Right: and that’s where taking a step back and evaluating things on the meta-level for where we get “the most bang for your buck” comes in… and much of that evaluation is predicated on what values you’re targetting.
Hm, honestly, I think the biggest “bang-for-buck” here would be production of a SPARK-proved unification-engine with intent to interface/implement the (1) a SMT, w/ SMT-LIB interface, (2) a SPARK theorem-prover, (3) a database engine. (Also interesting are SAT and automatic theorem-proving, ala TPTP. / Also interesting: this paper uses graph neural nets to aid SAT solving.)
That, however, might be considered a greenfield project, as no such project actually exists currently — therefore, perhaps taking a step back and working the data-storage side of that and working on Mneson such that:
Refactor to not be generic at the top-level, Note: This sets up the ability to SPARK-prove the implementation, as currently a big SPARK weakness is it does not operate on generic constructs directly.
[Possible] refactor not to use Charles containers [AI-302], but Ada.Containers,
(Actually setting up for future development: allowing the Ada.Containers objects to interface implementation/be-backed-by the database.)
Update codebase to use SPARK,
Better unit-tests.
(This should be a trivial/forgone-conclusion after being SPARK-proved, but gives a second “check your work” checklist.)
Future development could be the implementation of: (1) data-structure/-container “views”, (2) relational- and object-DB “views” (Mneson is a graph-DB), and (3) the unification-/solver-/DB-engine.
TL;DR — A opensource, 100% native Ada database, with SPARK-proving sounds like an excellent investment.
Easy answer : Convince the project leaders not to switch to Rust. They already started the switch because “nobody nows Ada so nobody contributes to the project”.
The management people like using the acronym S.M.A.R.T
Exactly. I do not want to be the one saying “lets do this or that!” I am in no position to do so… I threw some ideas that I think are valued by most of the community or that would benefit the community the most. But all ideas are welcomed and I want them to be heard
AFAIK, SPARK already uses the Why3 lingua-franca/framework. Though your proposal would be more wide-encompasing
I like the idea! I will write it down
I would say that marketing and a lower barrier of entry should be top priority for that goal ^^ I am trying to do my part
I can mentor anything related to Alire. In fact, I intended to come up with suitable tasks for GsoC, but maybe the community can identify some sticking points worth prioritizing.
I still have not had much time to read about GSoC. I am a bit overloaded with a few other things, so it will take me a while to summarize my findings here…
