Re: GSoC final update

[ludo@gnu.org (Ludovic Courtès)]

Hi reepca!

Caleb Ristvedt <caleb.ristvedt@cune.org> skribis:

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

Thanks for the status update!  I think you don’t have to be so negative
about what you did, though.  The things that you implemented look
well-thought-out to me, which to me suggests that maybe you worked
“depth-first” rather than “breadth-first”.  It does mean that some of
the things initially planned for are missing, but it also means that
existing bits are more polished than one would expect for a GSoC.

> Maybe I should describe my experience a bit. Reading the C++ source was
> extremely tedious.

I can sympathize with this.  This code base is rather good and
well-commented, but yeah, C++ scoping rules and the fully imperative
style make it hard to follow.

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

[...]

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

Communication is hard, but I think it’s crucial on short-term projects
like this one, as I think I said when you got started.  For example,
asking “do we have a reference scanner?” on IRC could have saved you
quite a bit of time.  In general, it’s often better to ask than to
remain stuck on something for ages—we’re here to help.

It seems to me that GSoC’s mentor-student relationship is sometimes seen
as boss-subordinate.  That’s really not the way I see it; I think the
student is just another person learning about the project and willing to
help, and they shouldn’t be any more afraid of asking for help than
anyone else.  I hope I didn’t give you the wrong impression.

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

It can’t be merged as-is, but most of the bits look solid enough as a
foundation.  I hope we can keep you on board in the coming months to
pursue this endeavor!

Thanks for the update, thanks for the code!

Ludo’.