About Gsoc 2014

About Gsoc 2014

[Manolis Ragkousis]

[-- Attachment #1: Type: text/plain, Size: 252 bytes --]

With less than 12 hours for GNU to submit ideas for this year's Gsoc, I am
wondering if porting guix to hurd and creating a guix hurd system, which I
am currently working on, is worthy for a Gsoc idea. I am an eligible
student, so that could be great!

[-- Attachment #2: Type: text/html, Size: 284 bytes --]

Re: About Gsoc 2014

[Cyril Roelandt]

On 02/19/2014 06:46 PM, Manolis Ragkousis wrote:
> With less than 12 hours for GNU to submit ideas for this year's Gsoc, I am
> wondering if porting guix to hurd and creating a guix hurd system, which I
> am currently working on, is worthy for a Gsoc idea. I am an eligible
> student, so that could be great!
>

I haven't followed the GSoC discussions, so please excuse the dumb 
question: is this the Google deadline, or just an 'internal' GNU deadline ?

That is definitely something I'd like to see for GSoC, but I don't think 
I qualify as a mentor. Who would be willing to do this ?

Cyril.

Re: About Gsoc 2014

[Andreas Enge]

On Wed, Feb 19, 2014 at 05:46:17PM +0000, Manolis Ragkousis wrote:
> With less than 12 hours for GNU to submit ideas for this year's Gsoc, I am
> wondering if porting guix to hurd and creating a guix hurd system, which I am
> currently working on, is worthy for a Gsoc idea. I am an eligible student, so
> that could be great!

The goal is definitely interesting. However, I am not sure what there is
to do now except for packaging the hurd. As long as we do not have a running
system, what do we do with the kernel? Or would there be enough interesting
work in creating a hurd qemu image?

Andreas

Re: About Gsoc 2014

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> On Wed, Feb 19, 2014 at 05:46:17PM +0000, Manolis Ragkousis wrote:
>> With less than 12 hours for GNU to submit ideas for this year's Gsoc, I am
>> wondering if porting guix to hurd and creating a guix hurd system, which I am
>> currently working on, is worthy for a Gsoc idea. I am an eligible student, so
>> that could be great!
>
> The goal is definitely interesting. However, I am not sure what there is
> to do now except for packaging the hurd. As long as we do not have a running
> system, what do we do with the kernel? Or would there be enough interesting
> work in creating a hurd qemu image?

The things to do would be packaging Mach/Hurd/MiG/libc, adjusting
cross-base.scm to allow cross-compilation to GNU/Hurd,
cross-bootstrapping, adjusting ‘glibc’ in base.scm, and then working
towards a GNU VM image (or non VM) based on (gnu system) stuff.

I think it’s OK as a GSoC project.

Ludo’.

About GSoC 2014

[Xue Fuqiao]

Hi list,

Having used Emacs for 4 years, I am a Chinese student and an Emacs
developer.  I'd like to work on Guix under the GNU umbrella for GSoC
2014, especially this project:

  * Package management from Emacs
    The goal of this project is to write a complete package management
    user interface for use in GNU Emacs. The UI would provide the same
    functionality as the `guix package' command, but using an interface
    similar to that of package.el.

I have write access to Emacs repo, so it isn't hard for me to add this
package to GNU ELPA or Emacs proper.

I'm not quite familiar with Scheme/Guix (yet), but I like them and am
willing to learn.  Currently, I'm learning Geiser and reading
README/HACKING/ROADMAP/TODO/guix.texi now.
-- 
http://www.gnu.org/software/emacs/

Re: About GSoC 2014

[Ludovic Courtès]

Hello,

Xue Fuqiao <xfq@gnu.org> skribis:

> Having used Emacs for 4 years, I am a Chinese student and an Emacs
> developer.  I'd like to work on Guix under the GNU umbrella for GSoC
> 2014, especially this project:
>
>   * Package management from Emacs
>     The goal of this project is to write a complete package management
>     user interface for use in GNU Emacs. The UI would provide the same
>     functionality as the `guix package' command, but using an interface
>     similar to that of package.el.
>
> I have write access to Emacs repo, so it isn't hard for me to add this
> package to GNU ELPA or Emacs proper.
>
> I'm not quite familiar with Scheme/Guix (yet), but I like them and am
> willing to learn.  Currently, I'm learning Geiser and reading
> README/HACKING/ROADMAP/TODO/guix.texi now.

Sounds great!  I remember you showed interest last year.  Yagnesh
Raghava Yakkala wrote a few days ago saying they’d be interested too.

Are you applying for other projects as well for this year?

Please familiarize yourself with the tools, and report any issues or
questions you may have.  It would be great also to start discussing more
precisely what the UI should look like, and sketch a road map.

Also make sure to come on #guix to discuss!

Thanks,
Ludo’.

Re: About GSoC 2014

[Xue Fuqiao]

Hi Ludovic,

ludo@gnu.org (Ludovic Courtès) writes:
> Are you applying for other projects as well for this year?

I'm also interested in the emacs-xwidget project, but my to be honest,
my C level isn't high.  I'm not sure if I'm competent at that job.

> Please familiarize yourself with the tools, and report any issues or
> questions you may have.  It would be great also to start discussing more
> precisely what the UI should look like, and sketch a road map.

OK, I will.

-- 
http://www.gnu.org/software/emacs/

Re: [GSoC] Package management from Emacs

[Xue Fuqiao]

[-- Attachment #1: Type: text/plain, Size: 2947 bytes --]

Here's my (tentative) plan of this project:

This package (guix.el) will include a facility that lets you easily
install (by name or by expression), remove, upgrade, and roll back
packages.  Of course, guix.el can also list the available and/or
installed packages.

The command `guix-describe-package' (I haven't come up with a good key
binding yet) can prompt for the name of a package, and display a help
buffer describing the package.  The buffer includes the name, version,
source, dependencies, home page, license(s) and other descriptions of
the package.

`M-x guix-list-packages' will bring up a buffer named `*Guix Packages*'
with a list of all packages.  You can install or uninstall packages via
this buffer.  *Note my attached image for the prototype of this buffer.

The `*Guix Packages*' buffer will list all the packages that Guix knows
about, one on each line, with the following information:

   * The package name (e.g., `emacs').

   * The package's version number (e.g., `24.3').

   * The package's status (installed/available).

   * A short description of the package.

The following commands will be available in the `*Guix Packages*' buffer:

`h'
     Print a short message summarizing how to use guix.el
     (`guix-quick-help').

`?'
`<RET>'
     Display a help buffer for the package on the current line
     (`guix-describe-package'), similar to the help window
     displayed by the `C-h P' command.

`i'
     Mark the package on the current line for installation
     (`guix-mark-install').  If the package status is `available', this
     adds an `I' character to the start of the line; typing `x' (see
     below) will download and install the package.

`d'
     Mark the package on the current line for deletion
     (`guix-mark-delete').  If the package status is `installed', this
     adds a `D' character to the start of the line; typing `x' (see
     below) will delete the package.

`u'
     Remove any installation or deletion mark previously added to the
     current line by an `i' or `d' command.

`U'
     Mark all package with a newer available version for “upgrading”
     (`guix-mark-upgrades').  This places an installation mark on the
     new available versions, and a deletion mark on the old installed
     versions.

`x'
     Download and install all packages marked with `i', and their
     dependencies; also, delete all packages marked with `d'
     (`guix-execute').  This also removes the marks.

`r'
     Refresh the package list (`guix-refresh').  This recomputes the
     package list.

`R'
     Roll back to the previous generation of the profile
     (`guix-roll-back').  This undo the last transaction.  (Do we need a
     "roll back" mark?)

For example, you can install a package by typing `i' on the line listing
that package, followed by `x'.

One can also use the command `M-x guix-package-install' and `M-x
guix-package-remove' to install/remove a package.

Any comments?


[-- Attachment #2: guix.el --]
[-- Type: image/png, Size: 75455 bytes --]

[-- Attachment #3: Type: text/plain, Size: 40 bytes --]


-- 
http://www.gnu.org/software/emacs/

Re: [GSoC] Package management from Emacs

[Ludovic Courtès]

Xue Fuqiao <xfq@gnu.org> skribis:

> Here's my (tentative) plan of this project:

Thanks for sharing your thoughts!

> This package (guix.el) will include a facility that lets you easily
> install (by name or by expression), remove, upgrade, and roll back
> packages.  Of course, guix.el can also list the available and/or
> installed packages.
>
> The command `guix-describe-package' (I haven't come up with a good key
> binding yet) can prompt for the name of a package, and display a help
> buffer describing the package.  The buffer includes the name, version,
> source, dependencies, home page, license(s) and other descriptions of
> the package.

There should also be a link to jump to the package definition, pretty
much like that of Emacs’ and Geiser’s docstring buffers.

Optionally, the package’s logo could be displayed too (see
build-aux/list-packages.scm, which does that for the HTML output.)

Also, I think there should be a search facility, with incremental search
fashion.  For instance, you could type ‘S’, enter a “C lib”, and that
would restrict the package list to the packages that show up in ‘guix
package -S "C lib"’.

> `M-x guix-list-packages' will bring up a buffer named `*Guix Packages*'
> with a list of all packages.  You can install or uninstall packages via
> this buffer.  *Note my attached image for the prototype of this buffer.

Perfect.

Ideally, new packages (obtained via ‘guix pull’) would show up first,
highlighted, as with package.el.  That requires support from ‘guix
pull’, but that’s on the to-do list.

> The `*Guix Packages*' buffer will list all the packages that Guix knows
> about, one on each line, with the following information:
>
>    * The package name (e.g., `emacs').
>
>    * The package's version number (e.g., `24.3').
>
>    * The package's status (installed/available).
>
>    * A short description of the package.
>
> The following commands will be available in the `*Guix Packages*' buffer:

[...]

Yes, perfect.

> `r'
>      Refresh the package list (`guix-refresh').  This recomputes the
>      package list.

Perhaps there should be something that runs ‘guix pull’ too (it’s like
‘apt-get update’)?

> `R'
>      Roll back to the previous generation of the profile
>      (`guix-roll-back').  This undo the last transaction.  (Do we need a
>      "roll back" mark?)

OK for ‘R’.

We don’t need a roll-back mark, I think, because you’re rolling back to
the previous generation; it’s not a per-package operation.

I was thinking it would also be neat to have a way to visualize
generations, basically a “graphical” and interactive representation of
what ‘guix package --list-generations’ provides.  That would show, for
instance, the date of the generations and the changes compared to the
previous one, and would make it easy to roll back to a specific
generation.

Perhaps we can keep that last thing as an bonus work item.  How do you
feel about it?

Thanks!

Ludo’.

Re: [GSoC] Package management from Emacs

[Grim Schjetne]

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

> Xue Fuqiao <xfq@gnu.org> skribis:
>> `r'
>>      Refresh the package list (`guix-refresh').  This recomputes the
>>      package list.
>
> Perhaps there should be something that runs ‘guix pull’ too (it’s like
> ‘apt-get update’)?

Isn't this type of operation usually bound to ‘g’? Or perhaps it would
be appropriate to have both, where one of them also runs ‘guix pull’?

--
GS

Re: [GSoC] Package management from Emacs

[Xue Fuqiao]

Hi Ludovic,

ludo@gnu.org (Ludovic Courtès) writes:
>> The command `guix-describe-package' (I haven't come up with a good key
>> binding yet) can prompt for the name of a package, and display a help
>> buffer describing the package.  The buffer includes the name, version,
>> source, dependencies, home page, license(s) and other descriptions of
>> the package.
>
> There should also be a link to jump to the package definition, pretty
> much like that of Emacs’ and Geiser’s docstring buffers.
>
> Optionally, the package’s logo could be displayed too (see
> build-aux/list-packages.scm, which does that for the HTML output.)

Good suggestions.

> Also, I think there should be a search facility, with incremental search
> fashion.  For instance, you could type ‘S’, enter a “C lib”, and that
> would restrict the package list to the packages that show up in ‘guix
> package -S "C lib"’.

Fair enough.  (Although it should be in the `*Guix Packages*' buffer
described below instead of in the package describe buffer :-)

>> `M-x guix-list-packages' will bring up a buffer named `*Guix Packages*'
>> with a list of all packages.  You can install or uninstall packages via
>> this buffer.  See my attached image for the prototype of this buffer.
>
> Perfect.

Thanks.

> Ideally, new packages (obtained via ‘guix pull’) would show up first,
> highlighted, as with package.el.  That requires support from ‘guix
> pull’, but that’s on the to-do list.

Fine with me.

>> `r'
>>      Refresh the package list (`guix-refresh').  This recomputes the
>>      package list.
>
> Perhaps there should be something that runs ‘guix pull’ too (it’s like
> ‘apt-get update’)?

Right.  And that's exactly what this command do, I think.

>> `R'
>>      Roll back to the previous generation of the profile
>>      (`guix-roll-back').  This undo the last transaction.  (Do we need a
>>      "roll back" mark?)
>
> OK for ‘R’.
>
> We don’t need a roll-back mark, I think, because you’re rolling back to
> the previous generation; it’s not a per-package operation.

Fair enough.

> I was thinking it would also be neat to have a way to visualize
> generations, basically a “graphical” and interactive representation of
> what ‘guix package --list-generations’ provides.  That would show, for
> instance, the date of the generations and the changes compared to the
> previous one, and would make it easy to roll back to a specific
> generation.
>
> Perhaps we can keep that last thing as an bonus work item.  How do you
> feel about it?

Cool.  Fine with me as an bonus work item.  Thanks for your attention
and suggestions.  I'll continue learning the tools.

-- 
http://www.gnu.org/software/emacs/

Re: [GSoC] Package management from Emacs

[Xue Fuqiao]

Grim Schjetne <gs@schjetne.se> writes:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Xue Fuqiao <xfq@gnu.org> skribis:
>>> `r'
>>>      Refresh the package list (`guix-refresh').  This recomputes the
>>>      package list.
>>
>> Perhaps there should be something that runs ‘guix pull’ too (it’s like
>> ‘apt-get update’)?
>
> Isn't this type of operation usually bound to ‘g’? Or perhaps it would
> be appropriate to have both, where one of them also runs ‘guix pull’?

In Package Menu mode, `package-menu-refresh' is bound to `r', and
`revert-buffer' (which uses `revert-buffer-function') is bind to `g'
(since it is derived from `special-mode').  ISTM their funcions are the
same, but I'm not sure.  I'll look into them later.

-- 
http://www.gnu.org/software/emacs/

Re: [GSoC] Package management from Emacs

[Ludovic Courtès]

Grim Schjetne <gs@schjetne.se> skribis:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Xue Fuqiao <xfq@gnu.org> skribis:
>>> `r'
>>>      Refresh the package list (`guix-refresh').  This recomputes the
>>>      package list.
>>
>> Perhaps there should be something that runs ‘guix pull’ too (it’s like
>> ‘apt-get update’)?
>
> Isn't this type of operation usually bound to ‘g’?

Yes.

> Or perhaps it would be appropriate to have both, where one of them
> also runs ‘guix pull’?

Probably yes, both ‘refresh’ (in case something goes wrong) and ‘pull’.

Ludo’.

Re: [GSoC] Package management from Emacs

[Xue Fuqiao]

In Package Menu mode, `r' will download the archive contents again,
whereas `g' only rebuilds the tabulated list of packages that have been
downloaded previously.

So we can use `r' (guix pull) to check if there is any updated packages,
and use `g' for example to revert the install/delete marks in the buffer.
-- 
http://www.gnu.org/software/emacs/

Re: [GSoC] Package management from Emacs

[Ludovic Courtès]

Xue Fuqiao <xfq@gnu.org> skribis:

> In Package Menu mode, `r' will download the archive contents again,
> whereas `g' only rebuilds the tabulated list of packages that have been
> downloaded previously.
>
> So we can use `r' (guix pull) to check if there is any updated packages,
> and use `g' for example to revert the install/delete marks in the buffer.

Sounds good.

Ludo’.