Re: WebAssembly target for Guix (Showcase)

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

On Tue, Sep 19 2023, zamfofex wrote:

> I’d love to know what y’all might think about it!

That's super exciting! I do not plan to run GNU Guix inside a WASM
runtime (or in a browser) but I would like to experiment with WASM
versions of some of our packages.

My interest was sparked by the extraordinary claims about the upcoming
Hoot, which generates WASM from GNU Guile. The resulting binaries are
extremely small ("970 bytes") and "the Hoot-compiled WebAssembly ... is
five times faster than native Guile!" [1]

In response, I contributed packages for the "micro runtime" [2] and for
WasmEdge [3] but neither has been accepted into Guix just yet.

Kind regards
Felix

[1]
https://spritely.institute/news/scheme-to-wasm-lambdas-recursion.html
[2] https://issues.guix.gnu.org/64179
[3] https://issues.guix.gnu.org/64319

WebAssembly target for Guix (Showcase)

[zamfofex]

Hello, Guix! I have recently worked on a WebAssembly target (for 
cross‐compilation) for Guix. It’s still in very early stages and thus fairly 
lacking, but it is enough to cross‐compile certain simple packages such as 
‘lolcat’.

Maybe people might find it useful and/or interesting in some way. I have shared 
it here: https://git.sr.ht/~zamfofex/guix-wasm

The WebAssembly changes are applied on top of https://issues.guix.gnu.org/63088 
(“Add Lc0”) because I had in my local Guix clone, and I didn’t bother to rebase.

I’d love to know what y’all might think about it!

[PATCH qa-frontpage WIP] Add a library to parse patchwork json data

[Vivien Kraus]

---
Hi!

Here is a small library that exports 3 types:
−  is the collection of metadata that is present
  in the square brackets in the patch names;
−  is an individual item of the patch series;
−  is a whole series of patches;

And a set of functions to parse and serialize these.

A fun experiment is to run the following script:

(use-modules (guix-qa-frontpage patchwork patch-series))
(use-modules (rnrs bytevectors))
(use-modules (web client))
(use-modules (ice-9 receive))
(use-modules (json))

(define patchwork-data
  (receive (r body)
  (http-get 
"https://patches.guix-patches.cbaines.net/api/patches/?order=-id;)
(json-string->scm (utf8->string body

(define patchwork-series
  (map scm->patch-series (vector->list patchwork-data)))

(for-each
 (lambda (correct-series)
   (display correct-series)
   (newline))
 (map patch-series->scm patchwork-series))

You will see that patchwork has quite a lot of creativity when it
comes to breaking my expectations. I made sure to add as much
information in exceptions so that we can understand what is happening.

Best regards,

Vivien

 Makefile.am  |   3 +
 guix-qa-frontpage/patchwork/patch-name.scm   | 117 +
 guix-qa-frontpage/patchwork/patch-series.scm | 165 +++
 guix-qa-frontpage/patchwork/patch.scm|  93 +++
 4 files changed, 378 insertions(+)
 create mode 100644 guix-qa-frontpage/patchwork/patch-name.scm
 create mode 100644 guix-qa-frontpage/patchwork/patch-series.scm
 create mode 100644 guix-qa-frontpage/patchwork/patch.scm

diff --git a/Makefile.am b/Makefile.am
index 79b7032..7b00ea9 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -32,6 +32,9 @@ SOURCES = 
\
   guix-qa-frontpage/server.scm 
\
   guix-qa-frontpage/database.scm   
\
   guix-qa-frontpage/patchwork.scm  
\
+  guix-qa-frontpage/patchwork/patch-name.scm   
\
+  guix-qa-frontpage/patchwork/patch.scm
\
+  guix-qa-frontpage/patchwork/patch-series.scm 
\
   guix-qa-frontpage/guix-data-service.scm  
\
   guix-qa-frontpage/branch.scm 
\
   guix-qa-frontpage/issue.scm  
\
diff --git a/guix-qa-frontpage/patchwork/patch-name.scm 
b/guix-qa-frontpage/patchwork/patch-name.scm
new file mode 100644
index 000..1b4cd97
--- /dev/null
+++ b/guix-qa-frontpage/patchwork/patch-name.scm
@@ -0,0 +1,117 @@
+(define-module (guix-qa-frontpage patchwork patch-name)
+  #:use-module (srfi srfi-9)
+  #:use-module (srfi srfi-9 gnu)
+  #:use-module (ice-9 match)
+  #:use-module (ice-9 exceptions)
+  #:export (
+make-patch-name-metadata
+patch-name-metadata?
+patch-name-metadata-bug-number
+patch-name-metadata-feature-branch
+patch-name-metadata-revision
+patch-name-metadata-index
+patch-name-metadata-total
+patch-name-metadata-set-index
+
+
+patch-name-parser-error?
+make-patch-name-parser-error
+
+parse-patch-name
+synthesize-patch-name
+))
+
+(define-record-type 
+  (make-patch-name-metadata bug-number feature-branch revision index total)
+  patch-name-metadata?
+  (bug-number patch-name-metadata-bug-number)
+  (feature-branch patch-name-metadata-feature-branch)
+  (revision patch-name-metadata-revision)
+  (index patch-name-metadata-index)
+  (total patch-name-metadata-total))
+
+(define (patch-name-metadata-set-index meta index)
+  (match meta
+(($  bug branch rev _ total)
+ (make-patch-name-metadata bug branch rev index total
+
+(set-record-type-printer!
+ 
+ (lambda (record port)
+   (match record
+ (($  bug feature revision index total)
+  (format port
+  "#< \
+bug-number=~s feature-branch=~s revision=~s \
+index=~s total=~s>"
+  bug feature revision index total)
+
+(define-exception-type 
+  
+  make-patch-name-parser-error
+  patch-name-parser-error?)
+
+(define (parse-patch-name name)
+  "Given a patch @var{name} obtained from Patchwork, infer the metadata
+from its name."
+  (define (raise-error message)
+(raise-exception
+ (make-exception
+  (make-error)
+  (make-patch-name-parser-error)
+  (make-exception-with-message message)
+  (make-exception-with-irritants (list name))
+  (make-exception-with-origin 'parse-patch-name
+  (define (as-bug-number arg)
+(and (string-prefix? "bug#" arg)
+ (string->number (substring arg (string-length "bug#")
+  (define (as-revision arg)
+(and (string-prefix? "v" arg)
+ 

Re: Guix pull speed

[Simon Tournier]

Hi,

On Thu, 14 Sep 2023 at 11:58, Ludovic Courtès  wrote:

>> What could be done about this?  Another solution would be to somehow
>> build Guix without any of the dependencies and then add them in later,
>> similar to what is done with build-aux/build-self.scm to be able to load
>> (guix self) in the first place.  That seems quite complex though.
>
> Most of the time is spent evaluating (gnu packages …) modules;
> evaluation is pretty slow, and from what I remember of previous
> profiling sessions, this is largely due to psyntax.  We should
> concentrate on that.

On my machine the step “Computing Guix derivation” is single-threaded.
Is it not possible to exploit multi-thread here?

Cheers,
simon

Re: bug#65866: [PATCH 0/8] Add built-in builder for Git checkouts

[Simon Tournier]

Hi Ludo,

On Tue, 19 Sep 2023 at 16:43, Ludovic Courtès  wrote:

>>>   1. Merge  with the hard Git
>>>  dependency.
>>
>> Is #65866 fixing bug#63331 (Guile-GnuTLS/Git circular dependency) [1]?
>
> Yes, as written in the cover letter.

[...]

>As I wrote in the cover letter, this patch
> series is the complete fix for .

Thanks for clarifying the cover letter:

This patch series is a first step towards getting Git out of
derivation graphs when it’s only used to fetch source code
(origins with ‘git-fetch’), with the goal of fixing:

  https://issues.guix.gnu.org/63331

Because I am not native, my dictionary says, Goal: Something that is
your goal is something that you hope to achieve, especially when much
time and effort will be needed.

Sorry if, from the cover letter and my vague understanding of the code,
it was not obvious for me that merging #65866 directly close #63331.
>From my understanding, #65866 was one step toward closing #63331 and not
the complete fix.

Anyway. :-)


> I suggest that we focus on the various sub-problems we’re trying to
> solve without losing sight of the big picture, yet without conflating
> them all.

The way we are trying to focus or solve these various sub-problems
depends on what we have at hand (the big picture).  Having an hard
dependency of Git means these immediate improvements by drop-in
replacements:

 + git clone => 3x faster for full Guix repository
 + shallow clone => 25% of improvements
 + git fetch => no worry much about gc
 + commit-relation => 35x faster

for an increase of the closure between 9% and 12%.  All these numbers
are for my machine and I guess they would be the order on average.

That said, I expressed my concerns about the “big picture” and
libgit2. :-)

Cheers,
simon

Re: guix QA "fails to process revision"

[Christopher Baines]

Andy Tai  writes:

> For a submitted patch, if Guix QA "fails to process revision" as in this log
> https://data.qa.guix.gnu.org/job/49399
>
> [ 32/ 40] compiling... 60.0% of 20 filesmadvise failed: Cannot allocate memory
> builder for `/gnu/store/j3hy5gymlfrdrhm8aj2brnsa2pix16n2-guix-home.drv'
> failed due to signal 11 (Segmentation fault)
> @ build-failed /gnu/store/j3hy5gymlfrdrhm8aj2brnsa2pix16n2-guix-home.drv
> - 1 builder for
> `/gnu/store/j3hy5gymlfrdrhm8aj2brnsa2pix16n2-guix-home.drv' failed due
> to signal 11 (Segmentation fault)
> cannot build derivation
> `/gnu/store/yh45c2z642xv2m752i3mj4lahj7q4qxm-guix-cli.drv': 1
> dependencies couldn't be built
> ...
>
> what can be done about it?

I think in this case the machine (beid) was short on memory, it has 32GB
of RAM and 16GB of swap.

I've reduced the max processes for the data service processing new
revisions which should help, but there's probably more that can be done.

There looks to be regular spikes in the memory used by the data service
process, so it would be good to look in to why that happens, and what
can be done to avoid it.


signature.asc
Description: PGP signature

Re: [workflow] Automatically close bug report when a patch is committed

[Giovanni Biscuolo]

Hi Vagrant,

Vagrant Cascadian  writes:

[...]

> This is why I think it is important for projects to have some sort of
> namespacing for this sort of thing; I am not really opinionated on the
> exact details, other than it not conflicting with Debian's terribly
> generic entirely un-namespaced historical "Closes:" syntax. :)

Noted and agreed!  At this point of discussion I also think there is
consensus (by the persons involved in this thread until now) to use a
namespaced URI (a full URL) for that upcoming feature (one of the two
discussed in the thread).

Thanks, Gio'

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature

The elephant in the room and the Guix Bang.

[Giovanni Biscuolo]

Hello,

...I'm talking about Emacs.

In <87bkdzssgm@gmail.com> [1] Simon Tournier  
writes:

[1] https://yhetil.org/guix/87bkdzssgm@gmail.com/

[...]

> people are already engaging for improving the accessibility of editors
> other than Emacs

Simon gave me the opportunity to realize (once again) that IMO there is
a foundamental misconception regarding Emacs.

What is Emacs, exacly: is it an editor?

I feel that a great deal of friction on the matter is due to the fact
that Emacs is usually defined as an /editor/ (OK text editor, but it
makes no difference)... **also** in its official page:

--8<---cut here---start->8---

 An extensible, customizable, free/libre text editor — and more.
 
 At its core is an interpreter for Emacs Lisp, a dialect of the Lisp
 programming language with extensions to support text editing.

--8<---cut here---end--->8---
(https://www.gnu.org/software/emacs/)

IMO to define Emacs as a sort of «text editor on steroids with batteries
included (Emacs Lisp)» does not represent the real nature of the
program; an /effective/ definition would be:

--8<---cut here---start->8---

 An extensible, customizable, free/libre user interface.
 
 At its core is an interpreter for Emacs Lisp, a dialect of the Lisp
 programming language, with extensions to use it as an interface to text
 editing functions and many, many more: MUA, web browser, task
 organizer...

--8<---cut here---end--->8---

To define Emacs as a /user interface/ it's not just a cool way to
"market it", it means to classify its /unique/ (?) user interface design
as one among all the historical instances of user interfaces:

--8<---cut here---start->8---

1. batch interface
2. command line interface
3. SAA User Interface or Text-Based User Interface
4. graphical user interface
5. (editor note) web user interface

--8<---cut here---end--->8---
(https://en.wikipedia.org/wiki/User_interface#History)

Someone may consider Emacs "just" a "text-based user interface (UI)"
(point 3. of the above mentioned list) like the ones using curses and
alike (e.g. vim, mutt, ranger, Norton Commander and so on) but IMO Emacs
implements a very different design, centered around a specific UI
element called "emacs buffer".

I consider Emacs as a 6th class of user interface :-D

Just to bring my limited personal experience: I was a mutt+vim user for
email management, ranger for file management... and so on, and since I
was was **very** happy with my vim user experience when editing text,
for a very long time I looked at Emacs as "just" another text editor I
didn't need, because **as text editors** both vim, Emacs and alike are
/very/ powerful and I was never ever interested for just a sec to the
funny "editor war" (and similar "wars").

Then, one day, moved by curiosity and the fact that the Emacs interface
is /integrated/ in the notmuch mail indexer I was already using, I
started using Emacs as my preferred /user interface/ for notmuch... and
some year later here I am, trying to use the Emacs interface for as much
computing activities I can.

Now I see Emacs in a very different way.

Incidentally (?), AFAIU Emacs was the Guile IDE (integrated development
environment, not text editor) used by Ludovic when he started
programming Guix; he and probably some (many?) of the contributors was
so happy with their tool that they started sharing their configuration
snippets, as usual amoung a community of enthusiastic users... after
many refinements and maybe some Emacs extentions progamming, they was so
proud that they decided to recommend the same (set of) tool /and/
configuration to other _collegues_, the famous "perfect setup" described
in the Guix manual.

I'm also suspecting that the spark that started the "Guix Bang" in
Ludovic's mind, the very moment he realized nix could be better
_extended_ using Guile in place of it's DSL, was /caused/ by the fact he
was a Lisp programmer, the specific /dialect/ probably did not matter.
But I'm just guessing.

Now I see Guix in a different way. :-)

In this context: is the Guix project biased in recommending using Emacs
(a Lisp interpreter and compiler for Emacs Lisp) to contributors?  I
don't think so.

I'd rather say that - as in many other organizations and all similar
projects - Guix adopts a "BYOT" (bring your own tool) organizational
policy... and the first contributors brought theirs. :-D

For sure vim/neovim - and other tools - can also be extended and *used*
to provide /user interface/s for various external tools (e.g. see
fugitive.vim/nvim-fugitive) that are useful when using and/or developing
Guix, everyone is free to use and extend them, and also to share with
the whole Guix community how their beloved BYOT are working well.

Please see a recent message of mine (id:87pm2e4flj@xelera.eu 

Re: ActtivityPub and Haunt

[Thompson, David]

Hi Jonathan,

On Tue, Sep 19, 2023 at 11:48 AM indieterminacy
 wrote:
>
> In wider fediverse news,
>
> The ActivityPub webpage is getting a rejig:
> https://socialhub.activitypub.rocks/t/activitypub-rocks-portal-from-standards-movement-to-grassroots-fedi/3577
>
> Im emailing, as within the technical discourse page is whether the tech
> stack should be moved away from (scheme based) Haunt (which powers
> Guix's website):
> https://socialhub.activitypub.rocks/t/activitypub-rocks-portal-technical-discussion/3578
>
> Naturally, Id be keen on continuing the furrow carved by Christine
> Lemmer-Webber and thought it would be worth seeing if there are any
> Lispers here who would be keen on volunteering, lest the platform goes
> Typescript.
>
> At my end, I consider the benefits to i18n to be a useful synergy:
> https://socialhub.activitypub.rocks/t/activitypub-rocks-portal-technical-discussion/3578/3
>
> If you agree, Id love you contribute your input there.

I'm the creator and maintainer of Haunt. I can't volunteer time to
maintain activitypub.rocks but I can help answer questions about Haunt
and help with bug fixes, patch review, etc. for Haunt itself. Haunt
posts can be written in Markdown, BTW.  You don't have to layer on the
obscurity by using a format like Skribe (even though Skribe is cool.)
I haven't integrated anything i18n related in Haunt itself because I
don't know a lot about it, but Guix being able to add in i18n on top
of what Haunt provides is a good sign that it's workable. I'm totally
open to include built-in i18n features in future releases.

I also understand and sympathize that keeping Haunt will probably be
swimming upstream against the pressure to be more mainstream.  I guess
a positive spin on things is that ActivityPub has succeeded enough to
call attention to all the Scheme that was cleverly snuck in when
Christine was the driving force of the project. It's been a small
point of pride that activitypub.rocks was built with Haunt, so it
would be a bit disappointing to see it go away, but I understand that
whatever is easiest for the volunteers actually doing the work is the
right thing. Scheme is *obviously* better than TypeScript, though. ;)

- Dave

guix QA "fails to process revision"

[Andy Tai]

For a submitted patch, if Guix QA "fails to process revision" as in this log
https://data.qa.guix.gnu.org/job/49399

[ 32/ 40] compiling... 60.0% of 20 filesmadvise failed: Cannot allocate memory
builder for `/gnu/store/j3hy5gymlfrdrhm8aj2brnsa2pix16n2-guix-home.drv'
failed due to signal 11 (Segmentation fault)
@ build-failed /gnu/store/j3hy5gymlfrdrhm8aj2brnsa2pix16n2-guix-home.drv
- 1 builder for
`/gnu/store/j3hy5gymlfrdrhm8aj2brnsa2pix16n2-guix-home.drv' failed due
to signal 11 (Segmentation fault)
cannot build derivation
`/gnu/store/yh45c2z642xv2m752i3mj4lahj7q4qxm-guix-cli.drv': 1
dependencies couldn't be built
...

what can be done about it?

ActtivityPub and Haunt

[indieterminacy]

In wider fediverse news,

The ActivityPub webpage is getting a rejig:
https://socialhub.activitypub.rocks/t/activitypub-rocks-portal-from-standards-movement-to-grassroots-fedi/3577

Im emailing, as within the technical discourse page is whether the tech 
stack should be moved away from (scheme based) Haunt (which powers 
Guix's website):

https://socialhub.activitypub.rocks/t/activitypub-rocks-portal-technical-discussion/3578

Naturally, Id be keen on continuing the furrow carved by Christine 
Lemmer-Webber and thought it would be worth seeing if there are any 
Lispers here who would be keen on volunteering, lest the platform goes 
Typescript.


At my end, I consider the benefits to i18n to be a useful synergy:
https://socialhub.activitypub.rocks/t/activitypub-rocks-portal-technical-discussion/3578/3

If you agree, Id love you contribute your input there.


--
Jonathan McHugh
indieterminacy@libre.brussels

Re: [PATCH qa-frontpage] Apply incoming patches onto the correct feature branch

[Christopher Baines]

Vivien Kraus  writes:

> It seems that the only available information of the feature branch is
> in the patch name.
> ---
>
> Hello guix!
>
> Thank you for making the QA tool. It seems to me that feature branches
> are ignored for patches. The patches seem to always be applied on top
> of master. I get that idea because the base-for-issue-* tag is always
> put on HEAD, and all my patches targetting gnome-team recently get
> applied to master. I understand that the latter could be a problem
> with me.
>
> If patches are indeed applied on top of master, then the question
> arises, what to do. The available information from patchwork is
> scarce: the base-commit is not available, and the optional feature
> branch only appears in the name of the patches of the series.
>
> I think it is possible to parse the patch names. This way, we get some
> useful information: the feature branch, the series revision, and the
> patch index. The patch index can be used to make sure the patches are
> in correct order (this can be the case if a server in the path
> re-orders the emails).
>
> What do you think?

Hi Vivien,

Thanks for trying to implement this and sending a patch, I think it's a
good feature to add but there's a few things needed to make this work.

Firstly, you need to actually change which branch the patch is applied
to, and the place to do that is here [1] in the call to
with-git-worktree. You can probably use get-commit from
(guix-qa-frontpage git-repository) to find the commit hash for a
branch. You'll also probably need to move around some of the code in
create-branch-for-issue so that you have the data about the patches to
work out what the desired branch is before you call with-git-worktree.

1: 
https://git.cbaines.net/guix/qa-frontpage/tree/guix-qa-frontpage/manage-patch-branches.scm#n250

The second thing is that there's other places in the codebase that
assume the patches have been applied to the master branch. In
start-manage-patch-branches-thread, there's
get-changes-compared-to-master which is used to decide if a branch needs
recreating if there's too many changes between the base revision and a
recent master branch revision. That'll need changing to at least skip
over any patches been applied to a non-master branch, or perform the
comparison against the tip of the relevant branch.

The third thing that will need to change to allow this to happen is
adding clear messaging on to the issue page to indicate where patches
have been applied to non-master branches. That'll help to avoid people
merging these patches in to the master branch rather than the branch
they were intended for.

Maybe what would be helpful is a procedure in (guix-qa-frontpage issue)
that takes the data for the issue from latest-patchwork-series-by-issue,
and gives you back the branch name that the patches should be applied
to. That can then be used to get the branch information for all the
above 3 use cases.

As for trying to order the patches, do you know of a case where the
ordering from Patchwork is wrong? I think it's only worth changing the
ordering in the qa-frontpage if we know we're doing it for a reason.

There's now a create-issue-branch command to the guix-qa-frontpage
script as well, which will be a good way of testing the code out for
applying patches to various branches. It'll fail when it comes to
pushing the branch, but it'll still be useful for testing the code up to
that point.

Would you be able to look at sending some revised patches?

Thanks,

Chris


signature.asc
Description: PGP signature

Re: Guix related things in Germany at the end of October/start of November

[Tobias Platen]

On Sat, 2023-09-09 at 08:23 +0200, Matt wrote:
> 
>   On Tue, 05 Sep 2023 19:28:09 +0200  Christopher Baines  wrote -
> -- 
> 
>  > Is anyone else planning to attend these events, or otherwise
> interested
>  > in meeting up in Germany around these dates?
> 
> I recently moved to Hamburg.  Thank you for informing the list (and
> particularly me) of these events!  I'd like to attend, if my schedule
> permits.
> 
I live in Göttingen and I am interested too.

Re: bug#65866: [PATCH 0/8] Add built-in builder for Git checkouts

[Ludovic Courtès]

Hi Simon,

Simon Tournier  skribis:

> On Mon, 18 Sept 2023 at 15:56, Ludovic Courtès  wrote:
>
>> Anyhow, how about this plan:
>>
>>   1. Merge  with the hard Git
>>  dependency.
>
> Is #65866 fixing bug#63331 (Guile-GnuTLS/Git circular dependency) [1]?

Yes, as written in the cover letter.

[...]

>>   2. When libgit2 1.7 with shallow clones is available in Guix, work on
>>  a patch to use Guile-Git for clones and evaluate it.
>
> ...we could also suggest to continue and have a complete fix of #63331
> before merging #65866.

Sorry, I don’t understand.  As I wrote in the cover letter, this patch
series is the complete fix for .

> It avoids to introduce a hard dependency which will be difficult to
> remove and let the time for this evaluation of libgit-2.1.7, no?

What this patch series sets in stone is “builtin:git-download” and its
semantics.

Its implementation can change over time though: it can switch to
libgit2, to OCaml-Git, or anything that pleases us.  These are
implementation details not visible from the outside.

>> As I wrote, as an example, I don’t think that there could be a practical
>> implementation of (guix git-authenticate) shelling out to ‘git’.
>
> [...]
>
>> PS: I don’t buy the “libgit2 will disappear from Guix” argument because
>> it’s not a natural phenomenon that we’re observing but a willful
>> construction.
>
> As I wrote elsewhere, Git-Annex (or Magit) are shelling out to 'git',
> IIRC.  Well, personally I do not consider that Git-Annex is slow or
> that Git-Annex does not implement features as complex as (guix
> git-authenticate).
>
> After reading [2],
>
>  I cannot imagine a viable implementation of things like ‘commit-closure’
>  and ‘commit-relation’ from (guix git) done by shelling out to ‘git’.
>  I’m quite confident this would be slow and brittle.
>
> wolf came 3 days later [3] with a first rough implementation for
> 'commit-relation' using Git plumbing which is much more faster than
> the one implemented with Guile-Git.

Yes, point taken.  It’s not so much about whether Git-Annex is “less
complex”, it’s about the level of integration needed.  But you don’t
have to take my word for it.

We’ve spent lots of words on the issue of a dependency on Git, and yet
this patch series doesn’t actually change much in that regard:
‘git-fetch’ already uses Git.

I suggest that we focus on the various sub-problems we’re trying to
solve without losing sight of the big picture, yet without conflating
them all.

Ludo’.

contribute with content in our official help pages?

[Giovanni Biscuolo]

Hi Simon and all readers,

I have some comments I cannot keep, just to try helping making this
thread harder to follow, if possible :-D.

Simon Tournier  writes:

[...]

> For instance, Vim [1] or VSCode [2].  The frame is not “what we should
> do” but “let me show you what I have”, IMHO.  Well, you are free to
> join the fun! :-)
>
[1] https://10years.guix.gnu.org/video/using-vim-for-guix-development/
[2] 
https://videos.univ-grenoble-alpes.fr/video/26660-cafe_guix_vscode_comme_outil_deditionmp4/

Thank you for the pointers, Simon, I already knew [1] since I have a
look to 10years Guix from time to time but I missed [2].  Although I
don't personally use that tools, I find that information useful when
Someone™ asks me how do Something™ using tool XYZ with Guix... but I'm
sure in 5 minutes I'll forget almost all, since I don't usualy use all
XYZ tools.

How can we decrease the effort needed by Someone™ like me to find useful
informations on "how to do X with/in Guix"?

1. The "quick and dirty" solution is to use a "smart" query in a web
search engine:

Example query "guix write packages using vim":
https://duckduckgo.com/?q=guix+write+packages+using+vim

It's not very efficient since the searcher have to do some _hard_ work
first to find a "smart" query and then to filter out what he really
needs; last but not least to understand if that information is still
relevant or someway outdated or not working for his use-case.

I'd call this quite a high cognitive overhead.

2. Search one of our _official_ "Guix - Help" resources:
https://guix.gnu.org/en/help/

As you can see, We™ have plenty of them, in (my personal) reverse order
of information discoverability efficacy (cognitive overhead?):

  - IRC (logs): http://logs.guix.gnu.org/guix/
  - mailing lists, see: https://guix.gnu.org/en/contact/
  - videos: https://guix.gnu.org/en/videos/
  - wiki: https://libreplanet.org/wiki/Group:Guix
  - GNU manuals: https://gnu.org/manual
  - Cookbook: https://guix.gnu.org/cookbook/
  - GNU Guix Manual 1.4.0: https://guix.gnu.org/manual/en
  - GNU Guix Manual (Latest): https://guix.gnu.org/manual/devel/

Someone™ could help integrating useful information in one of the above
listed resources, for example informations like [1] and [2] should go to
"videos".

Each of the above listed help channels have very different contribution
workflows, ranging from chatting on IRC to sending a patch to include
Something™ in the cookbook or in the manual; this means that the more
Someone™ would like that information to traverse that list "upward", the
more will be the effort for Someone™ (Else™?) to add it...

It's a path and it's /also/ fractally recursive! :-D

For example, I have a feeling that many useful informations discussed in
this thread have been shared in previous messages on this mailing list
or IRC, wiki, videos... probably Someone™ shoud find a way to integrate
them /at least/ as a blog post in https://guix.gnu.org/en/blog/, if
Someone™ (Else™?) find it would be helpful in reducing the overhead to
do XYZ with/for Guix due to hard discoverability of that piece of useful
information; sometimes that piece of information is also /very/ useful
in reducing the cognitive overhead for contributors, that's recursivity
(© Simon Tournier).

To be cristal clear: I find that also "externally managed assets" - a
blog post, a video, a tool specifically designed for "Guix integration"
of tool XYZ, a Guix channel - **are** useful _contributions_, but that
kind of contributions are even harder to find and/or use if not properly
"integrated in Guix".

Happy hacking! Gio'

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature