Re: Possible useful guix package performance data

[Evan Cooney]

Hi,

This is amazingly helpful!! Thank you!

On Tue, Nov 5, 2024, 9:34 AM Efraim Flashner  wrote:

> On Mon, Nov 04, 2024 at 11:22:01PM +0100, Ludovic Courtès wrote:
> > Hi,
> >
> > "Thompson, David"  skribis:
> >
> > > What are you trying to measure, exactly? The data collected is about a
> > > single thread of a Guile process, but `guix package -i` involves
> > > interaction with the Guix build daemon, waiting for downloads, etc.
> > > These things are outside the scope of what statprof is tracing.
> > > Anything that involves reaching out to the internet is going to make
> > > for an unreliable benchmark. I'm not actively working on Guix tools
> > > but I don't see anything immediately actionable from the collected
> > > data. I think getting some more clarity around the goal is necessary
> > > in order to know what to profile and how.
> >
> > Unless you’re specifically looking at performance of substitutes, I
> > recommend looking at profiles when using ‘--no-substitutes’; I would
> > also pass ‘--no-grafts’, to make sure you’re really looking at the core
> > of the whole package-to-derivation mechanism.
> >
> > You may also want to check the ‘GUIX_PROFILING’ environment variable,
> > from the (guix profiling) module.  That can give a useful overview such
> > as the number of remote procedure calls (RPCs) made to guix-daemon and
> > the hit rate of the “object cache”:
> >
> > --8<---cut here---start->8---
> > $ GUIX_PROFILING="gc rpc object-cache" guix build hello -d --no-grafts
> --no-substitutes
> > /gnu/store/79dhya6sngg4rf53m1cyxlhn8y4pnw2n-hello-2.12.1.drv
> > Object Cache:
> >   fresh caches:16
> >   lookups:   5042
> >   hits:  4596 (91.2%)
> >   cache size: 445 entries
> > Remote procedure call summary: 382 RPCs
> >   built-in-builders  ... 1
> >   add-to-store/tree  ... 3
> >   add-to-store   ...48
> >   add-text-to-store  ...   330
> > Garbage collection statistics:
> >   heap size:72.27 MiB
> >   allocated:100.29 MiB
> >   GC times: 13
> >   time spent in GC: 0.42 seconds (45% of user time)
> > --8<---cut here---end--->8---
> >
> > Keep in mind that the figures we’re looking at here are largely
> > dependent of the package graph being processed (that of ‘hello’ here).
> > So it also makes sense to look at the size of the package graph in
> > question first (in the case of ‘hello’, it’s probably fine, but let’s
> > say when Rust packages are in the loop, the graph might be much bigger
> > than needed/expected).
>
> Did someone say rust?
>
> I made a manifest of the packages that use the cargo-build-system and
> aren't rust-* packages, or which have rust as an input. 102 packages:
>
> $ GUIX_PROFILING="gc rpc object-cache" ./pre-inst-env guix build \
> --no-grafts -m ./etc/teams/rust/rusty-packages.scm \
> --no-substitutes -d
>
> Object Cache:
>   fresh caches:20
>   lookups:  361239
>   hits: 351403 (97.3%)
>   cache size:9835 entries
> Remote procedure call summary: 11780 RPCs
>   built-in-builders  ... 1
>   add-to-store/tree  ...33
>   add-to-store   ...   329
>   add-text-to-store  ... 11417
> Garbage collection statistics:
>   heap size:223.68 MiB
>   allocated:1332.86 MiB
>   GC times: 34
>   time spent in GC: 7.10 seconds (33% of user time)
>
> I also did a run with hello to get a comparison on the same machine:
>
> $ GUIX_PROFILING="gc rpc object-cache" ./pre-inst-env guix build hello -d
> --no-grafts --no-substitutes
> /gnu/store/1y2k2jkb8w67mcwj42b8bxjv3yshk5kf-hello-2.12.1.drv
> Object Cache:
>   fresh caches:16
>   lookups:   5042
>   hits:  4596 (91.2%)
>   cache size: 445 entries
> Remote procedure call summary: 382 RPCs
>   built-in-builders  ... 1
>   add-to-store/tree  ... 3
>   add-to-store   ...48
>   add-text-to-store  ...   330
> Garbage collection statistics:
>   heap size:79.57 MiB
>   allocated:122.75 MiB
>   GC times: 14
>   time spent in GC: 0.94 seconds (69% of user time)
>
> --
> Efraim Flashner  אפרים פלשנר
> GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
> Confidentiality cannot be guaranteed on emails sent or received unencrypted
>

[rust-team] gnome-authenticator

[paul]

Hi Guix,

I am probably becoming rust-team's worst nightmare after this but I just 
sent ~100 new Rust packages required to build gnome-authenticator . I 
divided them somewhat arbitrarily in these 4 issues with ~30 new patches 
each:


1. https://issues.guix.gnu.org/73956
2. https://issues.guix.gnu.org/74232
3. https://issues.guix.gnu.org/74233
4. https://issues.guix.gnu.org/74234

They are a huge amount, I know. And timing couldn't be worst I guess 
since if I understand correctly the rust-team branch is about to be 
merged (or at least queued to do so soon) *but* they are all new 
variables so I expect the number of failures introduced with merging 
these to be zero, and most of them is adding a new version for a package 
that was already in Guix, so reviewing those would hopefully take less 
effort.


Efraim, if you deem this too much effort to be integrated before merging 
the rust-team into master, please let me know. If you think we can get 
this in the rust-team branch before it gets merged into master, I'm 
willing to try and fix anything that could be needed as soon as possible.


Thank you for all your work,

cheers

giacomo

[bug#73462][PATCH] emacs-guix: shell commands broken

[Christopher Howard]

>From 282aea01d0212e3a9a2acac52d76a6a7325cf7e7 Mon Sep 17 00:00:00 2001
From: Christopher Howard 
Date: Wed, 6 Nov 2024 05:53:45 -0900
Subject: [PATCH] Provides work-around for
 https://issues.guix.gnu.org/issue/73462

---
 elisp/guix-repl.el | 5 +
 1 file changed, 5 insertions(+)

diff --git a/elisp/guix-repl.el b/elisp/guix-repl.el
index bf1dc82..3d75ac6 100644
--- a/elisp/guix-repl.el
+++ b/elisp/guix-repl.el
@@ -1,6 +1,7 @@
 ;;; guix-repl.el --- Making and using Guix REPL
 
 ;; Copyright © 2014–2019 Alex Kost 
+;; Copyright © 2024 Christopher Howard 
 
 ;; This file is part of Emacs-Guix.
 
@@ -290,6 +291,10 @@ display messages."
(guix-get-repl-buffer-name internal
 (guix-start-repl repl (and internal guix-repl-current-socket))
 (set repl-var repl)
+;; work-around for https://issues.guix.gnu.org/issue/73462
+(if internal
+(guix-geiser-eval-in-repl-synchronously
+ ",re (guix gexp)" repl t t))
 ;; Wait until switching to (emacs-guix) module finishes.
 (guix-geiser-eval-in-repl-synchronously
  ",m (emacs-guix)" repl t t)
-- 
2.46.0

I've attached a patch for the emacs-guix source which works around this issue. 
It modifies the REPL starting process for the Internal REPL, so that the (guix 
gexp) module is explicitly (re)loaded, which allows to reader syntax to work 
when the other modules load. I do not know why this should be necessary.

I wondered if there is some subtle difference here when dealing with a REPL 
that is accessed over a socket, as is the case with the Internal REPL. But I 
can't reproduce the problem on the command-line, outside of emacs-guix, using 
sockets.

With this patch, the "guix shell command" popup opens, though I see there is 
something wrong with the popup itself. It does not ask for a command to run, 
and the popup options only attempt to run an empty command. But I could 
investigate that in a separate bug.

Troubleshooting/testing was done with GNU Emacs 30.0.92 (build 2, 
x86_64-pc-linux-gnu, GTK+ Version 3.24.41, cairo version 1.18.0) of 2024-10-29.

-- 
Christopher Howard

Re: Unofficial channel 'whispers' with services and packages

[Development of GNU Guix and the GNU System distribution.]

Ludovic Courtès  writes:

> Hello Runciter,
>
> Lots of interesting things in there!
>
> If I could have a wish list of things to integrate in Guix proper, it
> would be this:
>
>> * dictd: the original programs for the DICT protocol. Includes the dict
>>   client and dictd server, which dico and dicod know how to
>>   emulate. Also includes the dictfmt utility, which is useful to express
>>   DICT dictionaries from human-written sources or other dictionary
>>   formats, for which GNU dico has no equivalent to my knowledge. I'm
>>   just the packager not an author.
>>
>> * freedict-tools: I packaged helper tools to compile the freedict
>>   multilingual dictionaries. I'm just the packager not an author.
>>
>> * freedict-dictionaries: package containing a subset of the
>>   freedict-dictionaries, intended for a local installation on a Guix
>>   system. I think the subset which I packaged corresponds exactly to the
>>   Freedict bilingual dictionaries which are human-written. The Freedict
>>   project also has a system which copulates 2 bilingual dictionaries
>>   sharing a common language into a third new automatically generated
>>   bilingual dictionary, I don't think my package outputs any of the many
>>   dictionaries which are expressed by this system. I'm just the packager
>>   not an author.
>
> :-)
>
> Thanks,
> Ludo’.

Hello Ludo,

Very well, I'll be glad to contribute those 3 packages.

I'm frequently busy and away from my main computer these days, I'll be
able to work conveniently with the Guix source-tree on Sunday, and then
should be able to submit a patch or three next week.

As a first step, I'll just submit a patch or a series with only the packages.

As a second step, it might be helpful to make a short addition to the
relevant section of the info manual, and/or to export working default
bindings from the (gnu services dict) module, for ease of configuration.

Regards,
Runciter

Re: revert Guix French translation: bootable ?

[Julien Lepiller]

Hi Léane,

« chargeur d'amorçage » is used consistently across many projects. It's even 
the title of the wikipedia page 
.

The English term is also mentionned, so it is correct, but not preferred. I 
would revert the change, but also mass edit « chargeur de démarrage » to « 
chargeur d'amorçage », and add it to the glossary.

Le 6 novembre 2024 23:28:48 GMT+01:00, "Léane GRASSER" 
 a écrit :
>Hi,
>
>Sorry for the confusion, I should've explained and proposed this change before 
>going ahead and mass-editing.
>
>The gist is that "amorçage" is not used in everyday French as a computer 
>science term. I usually encounter the words "démarrage" or "boot" in 
>conversations and texts written in French (France)—"amorçage" and "amorçable" 
>are much less common words.
>The same logic also applies to "bootable" and "bootloader", I believe they are 
>way more likely to be easily understood.
>
>Hopefully this clarifies the situation. I am fairly confident in this change, 
>but I would appreciate hearing other people's opinions on this nevertheless.
>
>Thanks,
>Léane
>
> Message d'origine 
>Le 06/11/2024 22:41, pelzflorian (Florian Pelz)  a 
>écrit :
>
>>  Hello.  I have a question on what term should be used in the French
>>  translation.  I am not proficient in French myself, but I wonder if we
>>  should revert a translation change.
>>  
>>  In the French translation, Léane Grasser (harmful-breeze) [1] today in
>>  guix-translations commit [2] changed occurrences of
>>  « chargeur d'amorçage »
>>  as well as
>>  « chargeur de démarrage »
>>  to the English term
>>  « bootloader ».
>>  Some uses of amorçage in other contexts are still unchanged, some are not.
>>  
>>  Amorçage and démarrage are not mentioned in the glossary [3].
>>  
>>  I see mention of « amorçable » on Wikipedia [4], giving the impression
>>  that French terms are preferred by the Académie Française. (?)
>>  
>>  Regards,
>>  Florian
>>  
>>  [1] Léane’s self-introduction:
>>  
>> https://lists.fedoraproject.org/archives/list/tr...@lists.fedoraproject.org/message/VK2PVXARJEAD36L4ZVYZXYZ6B2LIRXIG/
>>  [2] commit:
>>  
>> https://framagit.org/tyreunom/guix-translations/-/commit/c06978310eb9cc0ee992289314ba42ddf16db9cc
>>  [3] glossary:
>>  https://translate.fedoraproject.org/zen/guix/glossary/fr/
>>  [4] Wikipedia:
>>  https://en.wikipedia.org/wiki/English_in_computing#French
>>

Re: bug#73502: Request for merging "go-team" branch

[Ludovic Courtès]

Hello,

Sharlatan Hellseher  skribis:

> After a few weeks of working on go-team it's ready for the final review
> and merge to master.

This is next in queue for a merge:

  https://qa.guix.gnu.org/

Anyone who can help Sharlatan and Katherine get this past the finish
line and possibly join them on the Go team, now’s the time!

See .

Ludo’.

Re: home-environment + local git development

[Christopher Howard]

For posterity, this gave me what I needed:

``` guile scheme
(map cadr (package-propagated-inputs emacs-guix))
```

So I could do

``` guile scheme
(home-environment
  ;; Below is the list of packages that will show up in your
  ;; Home profile, under ~/.guix-home/profile.
 (packages (append
(map cadr (package-propagated-inputs emacs-guix))
emacs-packages
(specifications->packages
 (list "abook"
   "anki"
   ...etc...
```

I imagine a package transformation is also possible, to install emacs-guix 
straight from my local clone, but I haven't looked into this yet.

-- 
Christopher Howard

home-environment + local git development

[Christopher Howard]

Hi, I'm wanting to hack on emacs-guix from a local git checkout. Also, I use 
guix home with a home-environment file. emacs-guix includes related 
instructions for using emacs-guix from a local git checkout, but I'm having 
some issues trying to integrate that into my home environment. This leads me to 
two separate, but loosely related questions:

(1) in a home-environment file, is there a way I can specify to install the 
dependencies of a package (emacs-guix) but not the package itself?

(2) in a home-environment file, is there a way to specify that I want to 
install a package from a local guix.scm file (i.e., the one included in the 
emacs-guix repo)?

-- 
📛 Christopher Howard
🚀 gemini://gem.librehacker.com
🌐 http://gem.librehacker.com

בראשית ברא אלהים את השמים ואת הארץ

revert Guix French translation: bootable ?

[pelzflorian (Florian Pelz)]

Hello.  I have a question on what term should be used in the French
translation.  I am not proficient in French myself, but I wonder if we
should revert a translation change.

In the French translation, Léane Grasser (harmful-breeze) [1] today in
guix-translations commit [2] changed occurrences of
« chargeur d'amorçage »
as well as
« chargeur de démarrage »
to the English term
« bootloader ».
Some uses of amorçage in other contexts are still unchanged, some are not.

Amorçage and démarrage are not mentioned in the glossary [3].

I see mention of « amorçable » on Wikipedia [4], giving the impression
that French terms are preferred by the Académie Française. (?)

Regards,
Florian

[1] Léane’s self-introduction:
https://lists.fedoraproject.org/archives/list/tr...@lists.fedoraproject.org/message/VK2PVXARJEAD36L4ZVYZXYZ6B2LIRXIG/
[2] commit:
https://framagit.org/tyreunom/guix-translations/-/commit/c06978310eb9cc0ee992289314ba42ddf16db9cc
[3] glossary:
https://translate.fedoraproject.org/zen/guix/glossary/fr/
[4] Wikipedia:
https://en.wikipedia.org/wiki/English_in_computing#French