Gathering ideas for GSoC 2021!

Development Announcements
#1

Hi everyone,
Swift is applying to participate in Google Summer of Code this year again.

We had some great projects last year (4 out of 4 completed successfully), and this year we wanted to give the community a little bit of a heads up, so you can also come up with your own ideas in case you have some you would like to propose and find a mentor for early.

We are currently collecting ideas, matching them with mentors and slowly putting them up on the (work in progress) Swift.org - Project Ideas for GSoC 2021 site.

If you have other project ideas please feel free to post them here or message me directly and we'll work on polishing them up and try to find a suitable mentor for them.

A project idea should follow a similar structure as the ones on the linked site (i.e. include title, description, expected outcomes, etc).

If and when Swift is accepted as a project for GSoC 2021 we will post another update announcing this here.

Timeline

To understand the timeline of GSoC this year it is best to read the Google Summer of Code: How it Works: Timeline page, but here are a few of the key dates to keep in mind:

  • March 10 - Organizations Announced (hopefully, including Swift :slight_smile:)
  • March 30 - April 13 - Student Application Period
  • May 18 - Student Projects Announced
  • May 18 - June 8 - Community Bonding
  • June 8 - August 17 - Coding (note the shorter than usual coding period (around 21 days)

Keep in mind that currently we are pretty early in the process, and accepted organizations have not been announced yet. We wanted to give the community a heads up though in case you have some project ideas what might need some longer time to prepare and flesh out before the official Student Application Period begins.

Thanks!

10 Likes
Swift ArgumentParser: Interactive mode Proposal
Shrinking toolchain install size
GSoC proposal requirements
#2

This came up on another thread; maybe someone wants to tackle it?

1 Like
#3

I think that implementing some of Foundation's missing APIs could be a very interesting project, with a very high impact on Swift outside macOS.

10 Likes
#4

Hello everyone,
I am Abhik, currently in my final year pursuing a BTech in the field of Computer Science at IIT Roorkee, and want to apply for GSoC this time under Swift. I had accomplished past projects involving C, C++, and Java. I have some knowledge of Swift programming language (worked upon an iOS app). It will be great if someone can guide me through the next steps.

#5

Hi Abhik,
Please read the "how it works" on the GSoC page: https://summerofcode.withgoogle.com/

and refer to the timeline shown above:

Applying to specific topics will begin March 30th. Until then you can make yourself familiar with the proposed topics or think of something on your own and attempt to find a mentor for it. Generally speaking sticking to the existing proposals is better if you don't already have a strong project idea and mentor in mind though.

1 Like
#6

Okay, then I can start working on the existing proposals. Where can I find the link to existing project proposals?

#7

Maybe a richer plug-in infrastructure as outlined in Swift dynamic loading API would fit? It’d help expand the utility of swift-on-server.

2 Likes
#8

@Abhik1998 existing proposals are listed and linked to in the first post here.

#9

There's an idea I'd personally love to tackle, and I'm curious if I could find a mentor for it here.

I would want to improve the documentation of several lower-level and runtime features. Many things are fairly opaque to language users now, but they quite affect the performance and/or semantics of the language and are important to learn. Currently, however, the best way to learn about them is to either read the compiler documentation or inspect the SIL output, which are both fairly inaccessible or (in case of compiler docs) might be outdated. In particular, here are the topics that often make the wider community confused:

  • existential containers and why they don't work for protocols with Self or associated types;
  • stack vs. heap allocation of value types — it is believed by many that "structs are allocated on the stack", which is generally not true;
  • overload resolution and dynamic dispatch of default implementations on protocols vs. implementing types;
  • capture by-value vs. capture by-reference in closures;
  • type layout;
  • runtime behaviour of weak/unowned references;
  • runtime type metadata generation;
  • runtime behaviour of generic functions and various thunks

— and possibly other topics. Some of these features might be intentionally opaque, but given the ABI stability a lot of this stuff is very unlikely to change, while still being important to be aware of to write performant code. Especially that Swift positions itself as a good first programming language, I believe it is important that the documentation provides educational value by unveiling the inner workings of the features users sometimes might take for granted.

Please let me know what you think!

6 Likes
On improving communication between proposal authors and reviewers
#10

I like this idea! I think it would better to post it in swift.org, not buried deep in the github repository with other unrelated documents.

#11

Yep, that would be ideal. I could imagine this being a whole separate section alongside the language guide and the language reference, titled something like "language internals" — basically, a full overview of the runtime. However, since the community does not control the website, I cannot really propose this as a modification to swift.org itself; most likely the outcome will be just a stack of markdown files that will get incorporated into the website if the maintainers are satisfied with the result.

#12

To perhaps facilitate finding a mentor interested in helping me in that endeavour, I wrote a more formal draft.

CC @ktoso

#14

Hmm... thanks for the writeup, @wtedst. I don’t mean to let you down, but have to be honest that I (personally) don’t think that this is a good summer of code project.

Documenting such internals requires a lot of knowledge about them and it does not really feel like a right kind of task for someone to “learn and document as they go”, i.e. a student during the summer of code. It would have to very heavily rely on the mentor providing much of the information I feel, making the project somewhat less of an independent project of the student which they are intended to be.

The outcome of a project also should be pretty tangible and well defined. With such documentation tasks it is hard to do so because “they never end” quite often. And making a complete in depth and future proof swift compiler hacker guide seems to me like it would take much more time than available in the GSoC period (it's almost like a book project in some way).

To give it a chance though, I will ask around if someone would be interested in mentoring such idea. Thanks for the writeup again, and perhaps if this idea does not make it you could pick up and focus on one of the proposed ones?

1 Like
#15

Thanks for your answer! I totally understand your conecrns, so let me try to allay them.

First, I actually expect the demand on the mentor to be quite minimal. All the things we would want to write about are already "documented" — but just in terms of the compiler code or tests and comments therein. I would really only need the mentor to point me at these places ("here's where it happens in SILGen, here are the optimizer passes, here is where it happens in IRGen, here are the tests") so that I don't miss anything and then simply proofread the thing afterwards and maybe suggest some remarks. In other words, I do not expect the potential mentor to explain me anything major or themselves provide a verbatim copy-pasta, since I either already have a mental model for this stuff or am confident enough to close the gaps with relative ease.

Though this is, of course, hard for me to prove just on words, which is why I asked elsewhere if a draft implementation (or in this case, a "chapter") should be provided since this way it would be possible to actually see what the potential outcome could be. At the very least, I totally have enough time before the end of the application period to write an example thing. I also could restrict myself to the topics that are already partially covered: either by the existing docs such as the one on calling conventions or by videos from the LLVM dev meeting such as this one, so that there's reference information I could base the text off and "translate" it from the style intended for compiler developers into a more user-friendly educational format.

Second, about this being a good fit for GSoC: if we generally do agree that such a writeup is desirable for the community to have, then having it started as part of GSoC actually achieves several things: it offloads the bulk of the work (writing and illustrations) off people who simply have more important or interesting things to do, while legitimizing the result quite a bit, as something like this being written in a blog elsewhere will likely not receive the proofreading that we can expect from the more formal engagement of a mentor.

And quite frankly, I just have a personal itch that makes me really want to accomplish this, having spent so much money and time on various courses by authors that are themselves misinformed or under-educated and regretting it quite a bit. I think overall that it is absolutely necessary for people to have accessible knowledge on how their language actually works — but I myself am an even larger noname as of now to be able to make the impact alone.

The project volume is indeed quite vague, so we could restrict ourselves to a more well-defined "table of contents" at first to formalize it for GSoC. However, I don't see anything negative in this eventually becoming a full-blown book, as it would be very nice to have our own Swiftonomicon at some point past GSoC :upside_down_face:

I understand still that this may not get accepted, but since I'm quite passionate about the idea, I think it won't hurt if I apply with this proposal alongside another one I've been working on already, as GSoC allows for three applications, right? That way, we would not need to discard the idea completely and let the team ultimately decide at proposal evaluation.

1 Like
#16

A rough idea: Is setting up Windows CI and building a functional build-script for Windows suitable for GSoC? It’s a very specific area, and we need it to make Windows really first-class supported.

1 Like
#17

Thanks for the idea, I have a feeling that work on CI infrastructure may be hard because it involves access to servers/credentials and in the case of Windows I suppose also includes licensing etc.

@mishal_shah can comment more though if there is any help that would be welcome and enough for a summer of code project to help with windows CI.

#18

Currently, we are using swift/build-windows.bat at main · apple/swift · GitHub in Swift Community-Hosted CI. It would be great to have consistency between all of the platforms (build-script).

@compnerd would be the right person to provide more information about the Windows build system.

If I understand it correctly, the focus for the GSoC project would be to migrate build-windows.bat over to build-script, which can be done without access to the CI servers. Once the build-script is updated to support Windows build, I can update the CI job to use the new build-script preset.

#19

It’s certainly better to use the same build-script across all the platforms if possible. What I originally intend is that the participant may write a more powerful build script for Windows which can support features like cache, test and smoke tests. We can then:

  • Make toolchain development on Windows far more efficient;
  • Require tests and smoke tests on Windows for future patches, making sure that a change won’t break Windows build;
  • Get the Windows toolchain as an artifact of CI, which doesn’t rely on @compnerd ‘s Azure CI any more.

If we can finally use build-script on Windows, another benefit we’ll get is that toolchains on all platforms would share the same layout, though the current layout may be significantly changed on Windows.

Terms of Service

Privacy Policy

Cookie Policy