Re: GSoC proposal last-minute double-check

[Ludovic Courtès]

Hi Caleb,

Thank you for your proposal.

Caleb Ristvedt <address@hidden> skribis:

> * Plan
> (I can't find any mention of mid-term evaluations in the 2017 GSoC timeline,
> so I'm guessing that https://www.gnu.org/software/soc-projects/guidelines.html
> is outdated?)
>
> The missing pieces according to the suggestion description include the garbage
> collector, scanner, and scheduler. Presumably those are either the only
> missing pieces or the only non-trivial missing pieces. 
>
> I will read through the current C++ code implementing garbage collection and
> scanning during the "Community Bonding Period" to learn how it works. 
>
> The first step should be to implement the missing pieces. I will be on
> schedule if I have the garbage collector and scanner working ("working" here
> means that given sufficient time, all packages lacking references will be
> deleted or otherwise noticed by a program I wrote in Guile Scheme) by the end
> of the first work period, and if the scheduler is working by the end of the
> second work period ("working" here means that a program I wrote in Guile
> Scheme can order derivations topologically and schedule their building with
> the same characteristics as the current guix-daemon can). By the end of the
> third work period I will be on schedule if a complete executable,
> functioning in the same way as the current guix-daemon and written by me in
> Guile Scheme, exists.
>
> The results from the first two work periods should be usable by themselves in
> the event that I am unable to complete the entire project.

Cool!  I think you should first start playing with Guix and get a good
understanding of what derivations are, what happens when a client asks
the daemon to build them, and what happens when one runs ‘guix gc’; as a
first approach you don’t need into the details of how garbage-collection
works.

Only once you have experience with this and a good understanding does it
make sense to go look at the C++ code IMO.  Of course people on the
mailing lists and on IRC will be happy to help you find your way in the
code.  The manual also contains introductory material about these
concepts (see “The Store”, “Derivations”, “Setting Up the Daemon”, and
“Invoking guix gc”.)  You can also take a look at
<https://arxiv.org/abs/1305.4584>, which gives an overview.

> ** Other commitments
> During the summer I will be unable to work from 1300 to 1800 UTC on Sundays
> and 0030 to 0400 UTC on Mondays (Sunday morning and evening for me), and from
> 0030 to 0400 UTC on Fridays (Thursday evening for me). I currently don't
> anticipate any extended time of unavailability, but should it arise it will
> either be an emergency or communicated several weeks in advance.

As long as you don’t have other commitments (studies, etc.), that should
be fine!

> * Communication
> I will communicate using email (individually and/or via the guix-devel mailing
> list, as seems appropriate) and irc in #guix on freenode. My progress can be
> monitored via a public github repository to be set up at a later date. I will
> seek my mentor's input regarding the quality and content of my code at least
> once a week.

Awesome.  Communication is really important for a project like this, so
we’d expect you to make sure we hear from you, both about the good
things and things that don’t work well.  Sometimes just coming on IRC
and saying “how does this work?” can save you a lot of time.

> * Qualification
> This project appealed to me for a number of reasons:
> - It is a GNU project
> - It uses a Lisp, a family of languages I appreciate
> - It is clearly-defined (you can't get much clearer than "there is already
> working code that does what you are trying to do")
> - I have some experience with Guix and GuixSD before, from the user side (the
> only one silly enough to accidentally cause a kernel panic in Shepherd by
> using incorrect command-line syntax!). The idea of a .emacs-style
> configuration file for the entire operating system especially appeals to me
> a lot.

If everything goes well you’d be fluent in Scheme by the end of the
GSoC.  :-)

I’d expect you to try out the Guix both from the command line and via
its Scheme interface so you get a feel of how it works.  The (guix
store) module in particular contains the client remote procedure call
(RPC) stubs that talk to the daemon; the corresponding side is
implemented in nix-daemon.cc.

Make sure to take advantage of the “Community Bonding Period” to try
things out and to ask any questions you may have!

Thanks,
Ludo’.