GSOC draft

GSOC draft

[Alex Vong]

Hi,

First, sorry for being late. I only realized GSOC application period had
started on Sunday. Here is my proposal: (please note I can only work on
it after the final (after 9/5), I think I will work on it even if
proposal not accepted, just not working full time, some idea may looks
silly to experienced developers since I am still a novince)

Name:
  Alex Vong
Email:
  alexvong1995@gmail.com
Project:
  GNU Guix (Guile based build-tool)
Summary (rationale):
  Free-software is about having freedom to study, distribute, modify
  and re-distribute modified version of software.
  Free-software licenses explicitly grants us these freedom
  under current legal system.
  Internet and code hosting facilities makes it easy to study, dist
  and re-distribute modified version of software to everyone.
  However, it remains hard to modify software.
  One of the reasons is that build systems are complex.
  Consider compiling web browser from source.
  Guix uses the syntactic abstraction capability of scheme
  to make distribution packaging easier.
  We attempt to extend this idea to build system --- starting with a
  conceptually simple make-like build tool implemented in Scheme
  and extends it handles the general case.
Benefits:
  better build system
  ==> easier to build from source / more hack-able software
  ==> attract new contributors
Deliverable:
  An extensible working bare-bone build system in Guile
Plan:
  Idea:
    Autotool separates the configure phase and the build phase,
    in which the configure phase is responsible of probing feature
    provided by system, while the build phase actually does dependency tracking
    and performs the build. This is not optimal since global variables has to
    pass to another phase, one has to make sure to perform the probing
    in the right order. Also, many probing are done regardless whether they
    are needed. This causes performance issue when the result is not cached.
    So, the idea is to integrate the 2 phases,
    so that every declaration is approximately:
      (target (input ...) rule-to-make-target-from-input)
    and rule-to-make-target-from-input should return a Boolean indicates
    if the build succeed.
    For instance we can probe the C compiler using the following rule:
      (gcc () (and=> (return-path-of-gcc-if-exist-else-return-false)
                     (lambda (path) (make-c-compiler path))))
  Proof of concept:
    Incomplete port of Chicken port of PLT (now Racket) make module in Guile.
    See build instruction of <https://gitlab.com/alexvong1995/calc>,
    it uses that incomplete port to build.
  1. Port the Chicken port of PLT (now Racket) make module to Guile.
  2. Rewrite the make macro using syntax-rules.
  3. Add support for feature probing.
  4. Add support for multiple targets. (mid-term?)
  5. Add support for parallel build and opportunistic execution.
  6. Discuss with mentor to proceed.
Communication:
  alexvong1995@gmail.com (personal)
  guix-devel@gnu.org (pubic)
  IRC(?)
  Gitlab repo
Qualification:
  Experience:
    Debian user since Dec 2014
    convert mlucas to use autotool and introduce it to Debian last summer
    basic skill of using dev tools, i.e. git, debbugs, mailing list
    basic skill of programming, i.e. sh, C, autotool, scheme, perl, python
  Need to learn:
   Familiar myself with Guix's internals,
   such as g-exps, bags and store-monad.
   Familiar myself with Guile's macro system,
   i.e. syntax-rules and syntax-case.
   Familiar myself with cmake build system, i.e. the cmake OO features.

Cheers,
Alex

Re: GSOC draft

[Ludovic Courtès]

Hi, Alex!

Alex Vong <alexvong1995@gmail.com> skribis:

> Deliverable:
>   An extensible working bare-bone build system in Guile
> Plan:
>   Idea:
>     Autotool separates the configure phase and the build phase,
>     in which the configure phase is responsible of probing feature
>     provided by system, while the build phase actually does dependency tracking
>     and performs the build. This is not optimal since global variables has to
>     pass to another phase, one has to make sure to perform the probing
>     in the right order. Also, many probing are done regardless whether they
>     are needed. This causes performance issue when the result is not cached.
>     So, the idea is to integrate the 2 phases,
>     so that every declaration is approximately:
>       (target (input ...) rule-to-make-target-from-input)
>     and rule-to-make-target-from-input should return a Boolean indicates
>     if the build succeed.
>     For instance we can probe the C compiler using the following rule:
>       (gcc () (and=> (return-path-of-gcc-if-exist-else-return-false)
>                      (lambda (path) (make-c-compiler path))))
>   Proof of concept:
>     Incomplete port of Chicken port of PLT (now Racket) make module in Guile.
>     See build instruction of <https://gitlab.com/alexvong1995/calc>,
>     it uses that incomplete port to build.
>   1. Port the Chicken port of PLT (now Racket) make module to Guile.
>   2. Rewrite the make macro using syntax-rules.
>   3. Add support for feature probing.
>   4. Add support for multiple targets. (mid-term?)
>   5. Add support for parallel build and opportunistic execution.
>   6. Discuss with mentor to proceed.

From this message it is not entirely clear to me whether Guix would be
used at all, and how things would fit together.  I believe it would make
a lot of sense to use Guix to build such a thing but then of course, it
would only work for users would have a running guix-daemon.

WDYT?

I would suggest looking at the prototype Make replacement that Eelco
Dolstra wrote as part of his PhD thesis on Nix:

  http://nixos.org/~eelco/pubs/phd-thesis.pdf (Chapter 10)

There’s also this defunct project about a Make replacement in Guile (not
connected to Guix and Nix):

  http://home.gna.org/conjure/

Maybe Pjotr has other comments.

Thanks,
Ludo’.

Re: GSOC draft

[Alex Vong]

ludo@gnu.org (Ludovic Courtès) writes:

> Hi, Alex!
>
> Alex Vong <alexvong1995@gmail.com> skribis:
>
>> Deliverable:
>>   An extensible working bare-bone build system in Guile
>> Plan:
>>   Idea:
>>     Autotool separates the configure phase and the build phase,
>>     in which the configure phase is responsible of probing feature
>>     provided by system, while the build phase actually does dependency tracking
>>     and performs the build. This is not optimal since global variables has to
>>     pass to another phase, one has to make sure to perform the probing
>>     in the right order. Also, many probing are done regardless whether they
>>     are needed. This causes performance issue when the result is not cached.
>>     So, the idea is to integrate the 2 phases,
>>     so that every declaration is approximately:
>>       (target (input ...) rule-to-make-target-from-input)
>>     and rule-to-make-target-from-input should return a Boolean indicates
>>     if the build succeed.
>>     For instance we can probe the C compiler using the following rule:
>>       (gcc () (and=> (return-path-of-gcc-if-exist-else-return-false)
>>                      (lambda (path) (make-c-compiler path))))
>>   Proof of concept:
>>     Incomplete port of Chicken port of PLT (now Racket) make module in Guile.
>>     See build instruction of <https://gitlab.com/alexvong1995/calc>,
>>     it uses that incomplete port to build.
>>   1. Port the Chicken port of PLT (now Racket) make module to Guile.
>>   2. Rewrite the make macro using syntax-rules.
>>   3. Add support for feature probing.
>>   4. Add support for multiple targets. (mid-term?)
>>   5. Add support for parallel build and opportunistic execution.
>>   6. Discuss with mentor to proceed.
>
> From this message it is not entirely clear to me whether Guix would be
> used at all, and how things would fit together.  I believe it would make
> a lot of sense to use Guix to build such a thing but then of course, it
> would only work for users would have a running guix-daemon.
>
> WDYT?

First, I have withdrawn my proposal since I think it is not good enough.
Of course I will be exploring guix during summer, since it is a fun
thing to do. My original thought is to first port a working make-like
tool and then change it to output g-exps instead of actually performing
the build.

>
> I would suggest looking at the prototype Make replacement that Eelco
> Dolstra wrote as part of his PhD thesis on Nix:
>
>   http://nixos.org/~eelco/pubs/phd-thesis.pdf (Chapter 10)
>
Thanks for the link to the paper. The paper mentioned nix expression. Is
that what g-exp based on? I recently learnt monad by reading
`You Could Have Invented Monads! (And Maybe You Already Have.)'.
I followed the examples and worked them out in Guile. I highly recommend
it to anyone who want to learn monad. I want to ask is the store-monad
comparable to the state monad? In the article mentioned above, it
introduces >>=, unit and lift, which always satisfy the following:

let f, g be normal procedure
and f* be monadic procedure
1. (>>= unit f*) === (>>= f* unit) === f*
2. (lift (compose f g)) === (>>= (lift f) (lift g))
3. >>= is associative

What are their name in the case of store-monad?
I see there is >>= in store-monad, but how about the other ones?

> There’s also this defunct project about a Make replacement in Guile (not
> connected to Guix and Nix):
>
>   http://home.gna.org/conjure/
>
The homepage does not mention guile, is conjure written in guile?
Also, the all links in `Getting the Code' section are dead. Should it be
fixed?

> Maybe Pjotr has other comments.
>
> Thanks,
> Ludo’.

Finally, I suggest talking about the monad in the next Guix talks,
I "assert" people will love it!

Thanks for your feedback!

Re: GSOC draft

[Ludovic Courtès]

Alex Vong <alexvong1995@gmail.com> skribis:

> First, I have withdrawn my proposal since I think it is not good enough.
> Of course I will be exploring guix during summer, since it is a fun
> thing to do. My original thought is to first port a working make-like
> tool and then change it to output g-exps instead of actually performing
> the build.

OK.

>> I would suggest looking at the prototype Make replacement that Eelco
>> Dolstra wrote as part of his PhD thesis on Nix:
>>
>>   http://nixos.org/~eelco/pubs/phd-thesis.pdf (Chapter 10)
>>
> Thanks for the link to the paper. The paper mentioned nix expression. Is
> that what g-exp based on?

G-exps borrow from s-exps (obviously), client-side expression quoting in
HOP¹ (~ and $ come right from there; HOP implements things using
built-in compiler tricks whereas g-exps simply rely on macros, and of
course HOP and g-exps both implement staging but with different
constraints/goals), and string interpolation in Nix.

> What are their name in the case of store-monad?

(guix monads) provides ‘>>=’ and ‘return’.  There’s additional syntactic
sugar such as ‘mlet’, and helpers such as ‘lift’, ‘foldm’, ‘mapm’, etc.
This is partly covered in:

  https://www.gnu.org/software/guix/manual/html_node/The-Store-Monad.html

(Most of the section is not specific to ‘%store-monad’.)

>> There’s also this defunct project about a Make replacement in Guile (not
>> connected to Guix and Nix):
>>
>>   http://home.gna.org/conjure/
>>
> The homepage does not mention guile, is conjure written in guile?

It’s written in Guile I think.  Just mentioned it as a possible source
of inspiration for the EDSLs or APIs it provides.

> Finally, I suggest talking about the monad in the next Guix talks,
> I "assert" people will love it!

Heh, noted.  :-)

Thanks,
Ludo’.

¹ http://hop.inria.fr