unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Caleb Ristvedt <caleb.ristvedt@cune.org>
To: guix-devel@gnu.org
Subject: GSoC final update
Date: Tue, 29 Aug 2017 02:44:56 -0500	[thread overview]
Message-ID: <87lgm224xz.fsf@cune.org> (raw)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

As the official work time for GSoC draws to a close, it seems fitting to
summarize where the project is at right now. *deep breath*

What works: building hello. I tried building SBCL as well, but building
one of the dependencies caused hanging (but the same thing happened when
I tried building it with the C++ daemon). In short, for at least simple
derivations, building derivations works.

What doesn't: Way too much. RPCs aren't implemented (for testing
building I've been manually running builds from a REPL within test-env),
scheduling of multiple concurrent derivations isn't implemented, garbage
collection isn't implemented, and a lot of features even of
derivation-building aren't implemented (substitutes, offloading,
etc). call-with-container is also in a semi-broken state, though the big
issues could be fixed by going back to the way it was and bind-mounting
a store directory to collect output in (bind-mounts mess with my head
for some reason... thanks for mentioning that, Ricardo). The list goes
on.

Maybe I should describe my experience a bit. Reading the C++ source was
extremely tedious. The only way to know what a value is at any point is
to follow the entire execution of the program up to that point. A
slightly faster heuristic is to rgrep for anything that might change
that value, and consider only those statements. This, however, is
confused by C++'s scoping rules. For example, there are 3 "settings"
variables visible in globals.cc: a global variable from globals.hh, a
private variable from globals.hh, and a namespace-local (I think? The
scoping rules still aren't completely clear to me) variable from
globals.cc. As a side-note, in the future I will consider any code that
repeats four of the same names in a row when read aloud ("Settings
settings; Settings::Settings()") to be something to run far away from.

The scheme side of things was nice. The most frustrating part was not
knowing what was already implemented, especially what was implemented
but used an RPC for a low-level task. I also didn't know that a scanner
already existed (in hindsight it should have been obvious - how else
would grafts work?) and so ended up writing my own inefficient version
(though I intuitively think for some reason that it could be made fast).

<Digression> I found myself checking the guile reference quite
frequently. One time I happened upon a part describing the ECMAScript
implementation (curiosity and all that), and noticed that several times
it was mentioned how irresponsible the implementor was. That scared me
probably more than it should have. By all objective criteria, I have
failed in this project, and it frightens me to think that, nice as the
community is, I could screw up badly enough to end up a footnote
somewhere as an example of what not to be. That fear pretty much sums up
my mental state during the second half of the summer.</Digression>

In short, I've failed to achieve the goals I set out in my
proposal. Worst of all is that I failed to regularly communicate. I
specifically said that I would regularly communicate, and then I failed
to do so, especially during the second half of the summer. It seems that
the less I communicated, the more afraid of communicating I
became.

Currently nothing has been merged - I don't think it's in a fit state to
be merged presently. I intend to continue working on this as time
allows.  School started last week, though, and it's kept me quite busy
so far.

The code so far can be found at the guile-daemon branch on Savannah.

tl;dr - I did not achieve the goals I set out to achieve. That makes me
sad. I plan on working on it more.

- - reepca

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEdNapMPRLm4SepVYGwWaqSV9/GJwFAlmlGwUACgkQwWaqSV9/
GJybxwf/ZYtcANxxfaeS2YQFO3IQOlz+eI5cESvlzjyeQUZ6OgBm7sRTkSg67b2S
W4i3TvPKeEC/H1skFnYeh+ltlpQQo06ifgrh9ZUGNWbMeMTMq1Aqop6ZP97WQEtx
xihPCkjDve45zR4BwdqR6EB162c9Q16SJ3297g4SpcMKfoAKjnIv7T49tWCd2wCm
qp8Ia9D29DDYb8WAvD7ZyDo5g0fvB+qsHXpkNm5Lgic2m7XB0eRoWx/PzvtDNPzb
4z3OWN4vVvj1NZStyEgOkifuciY+Pn+W7RjcaQS0vrfkIcGFM7yZBm19nmBZAyrD
sz/vNcOfauVsMx3cI1MEZ7QAHIZfpg==
=GYqh
-----END PGP SIGNATURE-----

             reply	other threads:[~2017-08-29  7:45 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-29  7:44 Caleb Ristvedt [this message]
2017-08-29  8:32 ` GSoC final update Andy Wingo
2017-08-29 10:59 ` Efraim Flashner
2017-08-29 22:52 ` Leo Famulari
2017-08-30  9:50 ` Ludovic Courtès
2017-08-30 12:03 ` Ricardo Wurmus
2017-08-30 16:04 ` Andreas Enge
2017-08-31 14:49   ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87lgm224xz.fsf@cune.org \
    --to=caleb.ristvedt@cune.org \
    --cc=guix-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).