[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

GSoC proposal last-minute double-check

From: Caleb Ristvedt
Subject: GSoC proposal last-minute double-check
Date: Mon, 3 Apr 2017 02:25:02 -0500

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, 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

* 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
** 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
  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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]