I realize this is very last-minute indeed, but thought I'd see if I could get some feedback before I submit. I'm looking at working on the Guile Scheme guix-daemon - it seems much more concrete in scope than the build tool. I wrote my proposal based on
https://www.gnu.org/software/soc-projects/guidelines.html, but I think that might be a bit outdated - it's still got links to 2013 stuff and talks about mid-semester evaluations even though the schedule currently is to divide the summer in to 3 work periods. I'm least confident about the timeline of my proposal - is the time for those goals reasonable, evenly spaced, etc?
Here's the full proposal as I have it now:
* Name
Caleb Ristvedt (irc nickname: reepca)
* email address
address@hidden* name of project
Guix Rewrite build daemon in Guile Scheme
* Summary
Currently the build daemon of Guix is written in C++, inherited from Nix. It
works fine but is not as hackable as we'd like, and has poor integration with
the rest of Guix. For instance, the daemon calls out to the 'guix substitute',
'guix authenticate', and 'guix offload' commands, but its interface to these
commands is very limited. Furthermore, a large part of the daemon's code is
already implemented in Scheme: container functionality is available with
'call-with-container', archive creation is implemented in (guix nar), writing
derivation files (.drv) is done in (guix derivations), and so on.
The goal of this project would be to rewrite the daemon in Guile Scheme using
the building blocks already available. Important missing bits include the
garbage collector and its scanner (which scans files for references to
/gnu/store items), the scheduler, which schedules derivation builds in
topological order, using the specified number of cores, etc.
* Benefits
This would benefit users indirectly by benefiting developers. The easier it is
to understand and modify the code, the better the quality of the resulting
software (I leave this as an axiom). Better-quality software benefits
users. So this project will benefit users.
** Better hackability
By "hackability", I mean ease of modifying. Where more than one language
needs to be known to make changes, the code is more difficult to
change. Where one of those languages is C++, it's even more difficult to
change. Where multiple languages need to talk to each other, changing the
interface is more difficult than if the interface involves only one
language.
** Reduce duplication of code
Duplicated code is more code than if there is not duplication. It's easier to
understand less code. If we can replace the C++ implementation with one in
Guile Scheme, there won't be duplication (we can get rid of the C++
implementation). So replacing the C++ implementation with one in Guile Scheme
will make the code easier to understand.
* Deliverables
A program which, when run, will perform the same function as the current
guix-daemon, and is written by me solely in Guile Scheme. Additionally,
documentation explaining how the garbage collector and scheduler work and
analyzing the time and space requirements of the algorithms used as well as
profiling the real-world performance of the daemon.
* 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.
** 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.
* 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.
* 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.
This project will benefit me by teaching me about garbage collection and at
least some of the algorithms used for it. It will also teach me a lot about
developing larger-scale programs, and especially about developing programs
meant to be used by others, which I expect will involve a lot more input
validation than anything I've written before.
I'm not /especially/ qualified to work on this. I haven't devoted much time to
studying garbage collection, and I haven't looked at the guix-daemon code
yet. But I've been told that I am an effective independent learner, and this
/does/ interest me. I have learned Common Lisp on my own time over the past
two years, so Scheme shouldn't be too far off. I don't have C++ experience,
but do have C and Java experience, and the union of concepts from those two
should cover most of the C++ concepts. That just leaves the syntax to learn.
* Background
I am a sophomore computer science major at Concordia University, Nebraska. I
started learning programming in high school with Java (specifically,
Processing). I learned some Python when my older brother had to use it in his
first year of college, then more last year when I arrived. I don't remember
exactly when I learned C, but I did. Over the last two years I learned Forth
and Common Lisp. I've been using emacs since right before I started at
college, and using GNU/Linux for about two years before that.