Hey there everyone! I am Suprit S J from India and I am interested in contributing to Fortran as part of GSOC 2025, the topics I am interested in are File system library and Working with OS processes but before that a little bit about myself.
I am currently a sophomore at BITS Pilani pursuing MSc Physics (although it has masters in it’s name it’s still an undergrad program) and a B.E in Mechanical Engineering, I have been an admirer of Fortran for a few months now, I was first introduced to it by my Physics Professor as quite a simple and intuitive language and which is used a lot in heavy weight computations required by his work in the field of particle physics, I was quite intrigued by this as someone knowing C and C++ and thought that they would be a better candidates for such tasks. So I started learning it and it really had a different style to it much similar to python and even more simpler in many cases, with it’s huge collection of intrinsic functions and the computational libraries surrounding it.
So I learnt the basics of the language in a couple of days and found out about the community maintained stdlib and I wanted to contribute to it, and so I submitted a Pull Request, It wasn’t addressing a great issue and might as well not be in the scope of stdlib in hindsight, but nevertheless I made it and it didn’t get much feedback after some time (maybe my timing was wrong), I was a bit disappointed by it and hence didn’t think about doing anything further related to the same. But I am quite happy with how it turned out, as it helped me get started with open source development and I have contributed to a few repos here and there after that.
So I’d like to get back to stdlib and try again here haha, I am experienced in languages such as C, C++, basic x86 assembly, go, dart, javascript, python and have a keen interest in learning about low level stuff such as operating systems etc and apart from Programming in Physics, Math and logic.
Regarding the patch requirement I am a bit confused with what to do as there have been attempts at partially adding a file system library such as pull#874, the latest pull#904 and I don’t think a wide agreement has been reached regarding the API etc and also with the sub-processing module that was merged recently… I Would really appreciate guidance in this matter and about which topic I should go with if you have any suggestions.
Really Looking forward to engage with the community and learn a lot!
Thank you.
4 Likes
Hi @suprit05 welcome to the community and thanks for your interest in stdlib!
Regarding the 2 PRs you mentioned, 904 was splitted into several smaller PRs, you might have seen that several were already merged and system: OS type query by perazz · Pull Request #942 · fortran-lang/stdlib · GitHub is coming along. 874 stalled, I would guess because of me insisting on having the path separator as a compile time constant instead of a runtime dynamic function. The complexity is coming from the preprocessing. In one of the recent PRs by @FedericoPerini a small amount of C was added, this could enable completing this PR as the C preprocessing would work by default instead of hacking away the compile process.
I will let @FedericoPerini complete on how you could help on other tasks regarding File system interaction as it is coming along quite well but of course, there’s still much to be done 
Regarding your open PR, I wouldn’t say it is not in the scope, I would just say it is not in the priority of the people currently using stdlib (just a wild guess)… but hey, talking about it here in the forum might reveal otherwise as github issues have less visibility compared to discussions here. I would encourage you to open a separate thread to discuss your PR
Given you are following a Physics and Mechanical engineering program, would you be interested in the linear algebra enhancement topics? It might come in handy if you follow up on scientific side of your program. There’s a bit of intersection with the file system topic as we are looking forward adding IO for standard formats Support for I/O of standard formats · Issue #763 · fortran-lang/stdlib · GitHub
1 Like
Thanks for sharing your background and welcome to the forum @suprit05!
I believe the patch requirement is a way to start engaging with the community and the package maintainers, which you’ve already started to do well.
stdlib is a standard library after all, the review process tends to be slower because the APIs are discussed in detail, they may change a bit over time, but we try to minimize that.
So for the patch you may want to look at some of the open issues - skimming through the open issues I see some i.e. #848, #941, that are relatively straightforward to get started from. If you want to contribute to the system API, that’s also a good option and as @hkvzjal is suggesting, you may want to take a look at some of the recent PRs to see how they are usually structured (documentation, examples, tests, etc.)
1 Like
Thank you @hkvzjal for your advice 
and for clarifying the situation of the PR’s in my initial post, I will keep those in mind. I think I do have an understanding of linear algebra technically but I am not really well versed with the algorithmic side of the computations, if you think that the prerequisites are not too high please let me know how you’d like me to get started on the same.
@suprit05 great!
On the Lineal algebra topics not all require a deep understanding of linalg. In some cases it is just a matter of extending APIs or including facility functions around the actual implementations. So there is enough “vagueness” to adapt the topics depending on the expertise level.
Regarding your first PR as requirement for your application. As @FedericoPerini mentioned, you have started quite well with your open PR, lets say you tackle a couple easy ones that could be merged fast as for the application at least 1 PR should be merged, but you could have open ones as well listed GSoC 2025 Contributor Instructions · fortran-lang/webpage Wiki · GitHub. I agree that #941 and #898 are very easy and straight forward. You could take a look and propose the fixes.
Coming back to the linalg topic:
- On the IO facilities, 2 of the formats we would like to support are “simple” text files Matrix Market: File Formats. Since this files are very interesting for Sparse matrices, one simple way to start would be to propose an API to do IO between a file and the COO matrix format sparse – Fortran-lang/stdlib
- 931 might be an interesting one if the max number of matrices is limited an simple ordering strategies are chosen from the literature, you can then build on top of
gemm to do the heavy lifting.
- 910 would be an easy one, there’s a bit more of “house-keeping” and “light” refactoring’s for reusing constant values from within stdlib.
- 934 is very interesting and has a lot of potential in terms of performance… Now, it would require quite some tedious parts on build system and pre-processing.
- While not in the list of issues within the description of the project we have discussed about unifying and extending a matrix-vector procedure that would use the LAPACK backend as well as integrating the Sparse SpMV kernels into a single interface.
I think there’s already enough content for you to start thinking about it and sketch an action plan . Now, I have diverted you from your main interest on File system interaction. Would you preferer to stick to that, there is one topic which would be very useful as well base64 · Issue #916 · fortran-lang/stdlib · GitHub and of course you could try to help with Add filesystem interaction by minhqdao · Pull Request #874 · fortran-lang/stdlib · GitHub
2 Likes
Thank you very much for the detailed answer @hkvzjal, I will keep those in mind and I’ll try to pick up some of the issues you mentioned regarding linalg as they do seem interesting to me. In the meantime I hope It is okay to ping you, @FedericoPerini and continue this thread (until the deadline) regarding the patches I want to submit, I submitted one just now regarding the gamma function, let me know what you think about it.
1 Like
@FedericoPerini @hkvzjal
I submitted a PR proposing a send_signal subroutine to the system module here
Do let me know what you think about it.
4 Likes
Hello everyone! As some of you may be aware that GSoC’s contributor application period has started. During my (short) time of contributing to stdlib I got to learn a lot of things… From writing proper Fortran style code to how to design user friendly API’s to how to properly propose API’s to stdlib to writing good documentation and so on (many thanks to @hkvzjal @FedericoPerini @Arjen and many others on the forum too!). Having tried contributing to the linalg side of stdlib I noticed that I didn’t require the daily use of such procedures and hence I was not really good at proposing user-friendly API’s and error messages etc for such cases.
Hence I’d like to stick to my original topic of file system library and OS processes (and keep the linalg side as a hobby contribution that sometimes I’d like to do as I am still interested in it).
As recently the ground work for both these projects has been laid, I’d like to propose the merging of these two projects into one bigger umbrella project… and since the ideas page GSoC 2025 Project ideas · fortran-lang/webpage Wiki · GitHub doesn’t go into much detail about the outcome of the project, I’d like to ask what would be the desired outcome of the project ? what should the users be capable of doing after the project is done?
Any ideas, help on the above mentioned merger and in general how to go about making a solid proposal would be very much appreciated.
Thank you!