Pathway to becoming an effective contributor

Hi,

I would like to start a discussion about getting started with the
Swift Compiler. The end goal is to see if there are ways we can help
newcomers to the compiler get started and more quickly grow into a
more effective contributor.

Hi,

As someone who also recently started contributing, I was surprised to discover
how much computing power was needed to build Swift. My first few build attempts
on a mid-2014 rMBP took more than an hour with 100% CPU utilization which is
unsustainable for future participation.

Contributors with commit access granted can make use of computing resources made
available through Swift's Continuous Integration system. In the meantime, I'm
looking at cloud offerings to alleviate my building and testing time.

I just wished I knew this earlier. Hopefully, someone else can offer a better
solution to this problem. (No, I do not plan to spend money getting a Mac Pro :)

Also, after I'm able to get my starter bug merged, I have no idea
where to go from there. I don't want to take another starter bug and
deprive someone else of the opportunity to contribute (although maybe
that's an unnecessary restriction I'm placing on myself), but I'm also
not in a place where I could take on something much larger.

Personally, I do some code reading while waiting for a starter bug with which I
am willing to work on, e.g. the hackers at OpenBSD are having a daily code read
on the #openbsd-daily IRC channel
(https://blog.tintagel.pl/2017/06/09/openbsd-daily.html\).
They have found bugs and submitted patches with this approach
(mulander: "Today on #OpenBSD-daily DuClare tracks down our @…" - Mastodon).

I am unable to provide guidance on how to take on something much larger atm.

Cheers,

Nate
github.com/contraultra
mastodon.social/@contraultra

···

On Jun 20, 2017, at 12:37 PM, Halen Wooten via swift-dev <swift-dev at swift.org> wrote:

A clean build of LLVM, swift, and the standard library takes a while, but most of the time you shouldn’t have to rebuild everything from scratch.

For example if I’m just iterating on the compiler, I can edit a couple of source files and run ‘ninja swift’ and have a new compiler binary ready to test in a few seconds. I only rebuild the standard library if absolutely necessary, since that takes longer, but even then ‘ninja swift-stdlib’ is only a few minutes.

Also I always do release builds during normal development, only doing a debug build if I have to run the debugger which isn’t very often. Release builds produce a faster swiftc, so the standard library is built faster, and also they link faster.

Finally, it is possible to run only a subset of the validation tests while you’re iterating on a specific feature, instead of having to wait the ~15 minutes for ‘ninja check-swift-validation’, by directly invoking lit.

Slava

···

On Jun 21, 2017, at 2:12 PM, Natthan Leong via swift-dev <swift-dev@swift.org> wrote:

Hi,

As someone who also recently started contributing, I was surprised to discover
how much computing power was needed to build Swift. My first few build attempts
on a mid-2014 rMBP took more than an hour with 100% CPU utilization which is
unsustainable for future participation.

I was not aware of the 'ninja' commands as I have always been using the
documented utils/build-script. Thank you for sharing tips from your development
workflow too. I will try it out!

Cheers,

Nate
github.com/contraultra
mastodon.social/@contraultra

···

On Jun 21, 2017, at 2:25 PM, Slava Pestov <spestov@apple.com> wrote:

On Jun 21, 2017, at 2:12 PM, Natthan Leong via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:

Hi,

As someone who also recently started contributing, I was surprised to discover
how much computing power was needed to build Swift. My first few build attempts
on a mid-2014 rMBP took more than an hour with 100% CPU utilization which is
unsustainable for future participation.

A clean build of LLVM, swift, and the standard library takes a while, but most of the time you shouldn’t have to rebuild everything from scratch.

For example if I’m just iterating on the compiler, I can edit a couple of source files and run ‘ninja swift’ and have a new compiler binary ready to test in a few seconds. I only rebuild the standard library if absolutely necessary, since that takes longer, but even then ‘ninja swift-stdlib’ is only a few minutes.

Also I always do release builds during normal development, only doing a debug build if I have to run the debugger which isn’t very often. Release builds produce a faster swiftc, so the standard library is built faster, and also they link faster.

Finally, it is possible to run only a subset of the validation tests while you’re iterating on a specific feature, instead of having to wait the ~15 minutes for ‘ninja check-swift-validation’, by directly invoking lit.

Slava