gnu in summer-of-code: more projects needed

gnu in summer-of-code: more projects needed

[Andy Wingo]

Hello Guilers,

GNU was accepted into the Google Summer of Code.  Sweet!

The timeline, again, is here:

  http://www.google-melange.com/document/show/gsoc_program/google/gsoc2011/timeline

In particular:

    March 18:

      List of accepted mentoring organizations published on the Google
      Summer of Code 2011 site.

    March 18-27:

      Would-be student participants discuss application ideas with
      mentoring organizations.

    March 28:

      Student application period opens.

    April 8:

      Student application deadline.

If you are a Guile committer, think for a while about SoC-sized projects
that you would like to mentor: things that you would like someone to do,
about which you have ideas, and mail the ideas to the list.  

Please only propose projects which you are willing to mentor.  There are
loads of things to do, we are only lacking organization and time to do
so :)

Regards,

Andy
-- 
http://wingolog.org/

Re: gnu in summer-of-code: more projects needed

[BT Templeton]

Andy Wingo <wingo@pobox.com> writes:

> If you are a Guile committer, think for a while about SoC-sized projects
> that you would like to mentor: things that you would like someone to do,
> about which you have ideas, and mail the ideas to the list.  

I'd like to continue my work on the Emacs Lisp compiler. Some areas that
could use improvement:

 * Implement Emacs-compatible lexical binding support

 * Many Elisp subrs are not implemented in Guile-Elisp; some don't make
   sense outside of Emacs, but the rest should be provided. I wrote
   simple versions of many subrs in Elisp (using guile-ref, etc.), but
   only just enough for subr.el to load more or less correctly.

 * A more comprehensive testing framework would be nice. For example,
   I'd like to be able to run Elisp tests in both Guile and Emacs.

 * "Big variables," as proposed in
   <http://article.gmane.org/gmane.lisp.guile.devel/10750>, would
   simplify the implementation, and would also be useful if anyone wants
   to implement support for other Lisp-2 dialects in the future.

 * Nil needs to be a list, a boolean, *and* a symbol, not just a list
   and a boolean.

 * Guile-Elisp needs to support aliases and buffer-local variables.

 * Guile-Elisp could be a bit faster (Emacs is still faster for the
   Gabriel benchmarks), though I assume Guile will do better with code
   that uses lexical binding.

Suggestions welcome; I'll be submitting the final application on 7 or 8
April.

dankon,
BT
-- 
Inteligenta persono lernas la lingvon Esperanton rapide kaj facile.
Esperanto estas moderna, kultura lingvo por la mondo. Simpla, fleksebla,
belsona, Esperanto estas la praktika solvo de la problemo de universala
interkompreno. Lernu la interlingvon Esperanton! http://lernu.net/

Re: gnu in summer-of-code: more projects needed

[Ludovic Courtès]

Saluton Brian,

BT Templeton <bpt@hcoop.net> writes:

> I'd like to continue my work on the Emacs Lisp compiler.

Would be great!

> Some areas that could use improvement:
>
>  * Implement Emacs-compatible lexical binding support

In what way is the current elisp implementation in Guile not
Emacs-compatible?

>  * Many Elisp subrs are not implemented in Guile-Elisp; some don't make
>    sense outside of Emacs, but the rest should be provided. I wrote
>    simple versions of many subrs in Elisp (using guile-ref, etc.), but
>    only just enough for subr.el to load more or less correctly.
>
>  * A more comprehensive testing framework would be nice. For example,
>    I'd like to be able to run Elisp tests in both Guile and Emacs.
>
>  * "Big variables," as proposed in
>    <http://article.gmane.org/gmane.lisp.guile.devel/10750>, would
>    simplify the implementation, and would also be useful if anyone wants
>    to implement support for other Lisp-2 dialects in the future.
>
>  * Nil needs to be a list, a boolean, *and* a symbol, not just a list
>    and a boolean.
>
>  * Guile-Elisp needs to support aliases and buffer-local variables.
>
>  * Guile-Elisp could be a bit faster (Emacs is still faster for the
>    Gabriel benchmarks), though I assume Guile will do better with code
>    that uses lexical binding.

This all sounds useful, but I was hoping for something that would get
the project closer to Emacs integration.  Do you think anything can
realistically be done in that respect, or is the above already enough
work?

If the latter, would you be around after the summer to work on Emacs
integration?  :-)

Thanks,
Ludo’.

Re: gnu in summer-of-code: more projects needed

[BT Templeton]

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

> Saluton Brian,
>
> BT Templeton <bpt@hcoop.net> writes:
>
>> I'd like to continue my work on the Emacs Lisp compiler.
>
> Would be great!
>
>> Some areas that could use improvement:
>>
>>  * Implement Emacs-compatible lexical binding support
>
> In what way is the current elisp implementation in Guile not
> Emacs-compatible?

This is a trivial change; Emacs uses the `lexical-binding' variable to
determine the default scope rules on a per-file basis, while Guile-Elisp
provides a `lexical-let' special form.

>>  * Many Elisp subrs are not implemented in Guile-Elisp; some don't make
>>    sense outside of Emacs, but the rest should be provided. I wrote
>>    simple versions of many subrs in Elisp (using guile-ref, etc.), but
>>    only just enough for subr.el to load more or less correctly.
>>
>>  * A more comprehensive testing framework would be nice. For example,
>>    I'd like to be able to run Elisp tests in both Guile and Emacs.
>>
>>  * "Big variables," as proposed in
>>    <http://article.gmane.org/gmane.lisp.guile.devel/10750>, would
>>    simplify the implementation, and would also be useful if anyone wants
>>    to implement support for other Lisp-2 dialects in the future.
>>
>>  * Nil needs to be a list, a boolean, *and* a symbol, not just a list
>>    and a boolean.
>>
>>  * Guile-Elisp needs to support aliases and buffer-local variables.
>>
>>  * Guile-Elisp could be a bit faster (Emacs is still faster for the
>>    Gabriel benchmarks), though I assume Guile will do better with code
>>    that uses lexical binding.
>
> This all sounds useful, but I was hoping for something that would get
> the project closer to Emacs integration.  Do you think anything can
> realistically be done in that respect, or is the above already enough
> work?

I think a logical next step would be to update Ken Raeburn's Guilemacs
patches to work with Emacs 24 and Guile 2.0, perhaps in parallel with
the above tasks. I'll include that in my proposal

> If the latter, would you be around after the summer to work on Emacs
> integration?  :-)

Yes. Porting the Generic Window Manager to Guile has been good practice
for that (:

amike,
BT
-- 
Inteligenta persono lernas la lingvon Esperanton rapide kaj facile.
Esperanto estas moderna, kultura lingvo por la mondo. Simpla, fleksebla,
belsona, Esperanto estas la praktika solvo de la problemo de universala
interkompreno. Lernu la interlingvon Esperanton! http://lernu.net/

Re: gnu in summer-of-code: more projects needed

[Ludovic Courtès]

Hello!

BT Templeton <bpt@hcoop.net> writes:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> BT Templeton <bpt@hcoop.net> writes:

[...]

>>>  * Implement Emacs-compatible lexical binding support
>>
>> In what way is the current elisp implementation in Guile not
>> Emacs-compatible?
>
> This is a trivial change; Emacs uses the `lexical-binding' variable to
> determine the default scope rules on a per-file basis, while Guile-Elisp
> provides a `lexical-let' special form.

OK.

BTW, it appears that the Emacs ‘lexbind’ branch has been merged:
<http://comments.gmane.org/gmane.emacs.devel/138010>.

> I think a logical next step would be to update Ken Raeburn's Guilemacs
> patches to work with Emacs 24 and Guile 2.0, perhaps in parallel with
> the above tasks. I'll include that in my proposal

Cool.  I guess you’d have to define priorities, because all this can be
a lot of work.

>> If the latter, would you be around after the summer to work on Emacs
>> integration?  :-)
>
> Yes.

Great.  :-)

Ĝis,
Ludo’.