Ludovic Courtès (2014-09-01 16:10 +0400) wrote:
> Alex Kost <alez...@gmail.com> skribis:
>
>> Ludovic Courtès (2014-08-31 18:59 +0400) wrote:
>
> [...]
>
>>> The key is ‘vhash-fold*’ (info "(guile) VHashes"). It allows you to
>>> traverse all the entries associated with a given key:
>>>
>>> scheme@(guile-user)> (vhash-cons '("guile" "2.0") 'foo
>>> (vhash-cons '("guile" "2.0") 'bar
>>> vlist-null))
>>> $12 = #<vhash 39240a0 2 pairs>
>>> scheme@(guile-user)> (vhash-fold* cons '() '("guile" "2.0") $12)
>>> $13 = (bar foo)
>>>
>>> I think that answers your question, right?
>>
>> Absolutely; sorry for missing that feature. But will it be a real
>> optimization? If I want to get information for all packages, I have to
>> perform ‘vhash-fold*’ on ‘manifest-name->entry’ vhash for each package
>> (to get installed outputs). With hash-table, I just need to use
>> ‘hash-ref’ for each package.
>
> ‘vhash-fold*’ iterates only on the values associated with the given key;
> it has time complexity linear in the number of values associated with
> that key. So no worries here (and again, 90% of the time there’ll be
> exactly one package corresponding to a name/version pair.)
Ah, OK then. (I still have some worries but it's just paranoia
apparently).
>> Also I need to fold over unique names (I use ‘fold-manifest-entries’
>> from “guix-main.scm” for that) and I have no idea how vhash can help
>> there.
>
> Would ‘vlist-fold’ work?
>
> scheme@(guile-user)> (vhash-cons 'a 1 (vhash-cons 'b 2 (vhash-cons 'a 3
> vlist-null)))
> $2 = #<vhash 26fd3a0 3 pairs>
> scheme@(guile-user)> (vlist-fold cons '() $2)
> $3 = ((a . 3) (b . 2) (a . 1))
Sorry, I don't see how it could work. Here is an example:
;; What I currently have is a hash-table like this one:
(define table (make-hash-table 3))
(hash-set! table 'a '(1 2 3))
(hash-set! table 'b '(4))
(hash-set! table 'c '(5 6))
;; And I can easily fold through unique keys like this:
(hash-fold (lambda (key entries res)
(cons (cons key (apply + entries)) res))
'()
table) ; => ((c . 11) (b . 4) (a . 6))
;; What you suggest is a vhash like this:
(define vhash
(vhash-cons
'a 1
(vhash-cons
'a 2
(vhash-cons
'a 3
(vhash-cons
'b 4
(vhash-cons
'c 5
(vhash-cons
'c 6 vlist-null)))))))
;; But how can I fold through unique keys there?
[...]
> I’ll check the doc later today, but it seems this is essentially ready
> for merging, no?
Yes, If you don't mind that I'm still using hash-tables, I think it can
be merged.
> When we merge, would you like to rewrite history and make the whole
> thing appear as a single “perfect” commit, or just merge ‘emacs-ui’ into
> ‘master’? (I often do the former, but I’m fine with the latter here.)
I don't have a preference here. I can do a single commit if it is more
appropriate. Would the following commit message be OK?
--8<---------------cut here---------------start------------->8---
Add Emacs user interface.
* configure.ac (emacsuidir): New variable.
(AC_CONFIG_FILES): Add 'emacs/guix-init.el', 'emacs/guix-helper.scm'.
* Makefile.am: Include 'emacs.am'.
* emacs.am: New file.
* doc/emacs.texi: New file.
* doc/guix.texi: Include 'emacs.texi'.
* emacs/guix-backend.el: New file.
* emacs/guix-base.el: New file.
* emacs/guix-helper.scm.in: New file.
* emacs/guix-history.el: New file.
* emacs/guix-info.el: New file.
* emacs/guix-init.el.in: New file.
* emacs/guix-list.el: New file.
* emacs/guix-main.scm: New file.
* emacs/guix-utils.el: New file.
* emacs/guix.el: New file.
--8<---------------cut here---------------end--------------->8---
