guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#63088] [PATCH v2] gnu: Add Lc0.


From: zamfofex
Subject: [bug#63088] [PATCH v2] gnu: Add Lc0.
Date: Mon, 11 Sep 2023 07:22:35 -0300 (BRT)

> recursive? #t is meh ._.
> Can we work around that?

Yes, presumably easily, but I don’t think it would be a good idea in this case, 
because it isn’t used to build bundled software, but rather just for a small 
project‐specific pair of source files (that are in a separate repo just because 
they are used by other repos of the project too).

> Can we use search-input-file or the like here?

Probably. Though would it be reasonable to package the network separately 
instead? Note that Lc0 is able to load various networks, and there is no 
canonical network, so maybe it would be useful to have it in a different 
package so that more can be potentially added in the future.

Then people could use them with something like ‘guix shell lc0 
lc0-NETWORK_NAME’.

> Is Lc0 = Leela Chess Zero?  What's the connection?

“Lc0”, “Leela Chess Zero”, “LCZero”, and sometimes just “Leela Chess” can be 
used roughly interchangeably to refer to the project as a whole. Though, 
occasionally, people will use the term “Lc0” (sometimes capitalised as “lc0”) 
to refer specifically to the ‘lc0’ executable, which can use the networks from 
the Leela Chess Zero project, but networks created by other people too, 
including those of e.g. the Maia project, see 
<https://github.com/CSSLab/maia-chess> and <https://maiachess.com>

At some point (very early on), the code for the executable was rewritten or 
otherwise largely refactored, and at the same time renamed from ‘lczero’ to the 
current ‘lc0’, so sometimes (very rarely nowadays), people will use the term 
“lc0” (or “Lc0”) to refer specifically to this new executable and code base, 
contrasting with the former ‘lczero’ executable and its code base.

Honestly, this all feels convoluted to me, so I usually like to use the terms 
interchangeably, and I don’t think using them differently in the package 
description is a good choice.

- - - - -

Hopefully this helps clarify things well enough! If there is interest, I can 
submit another patch with the requested changes and the appropriate path taken 
regarding the packaging for the networks.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]