Re: Stratification of GNU Guix into Independent Channels

[Giovanni Biscuolo]

Hi,

just a quick comment

zimoun  writes:

[...]

> Moreover, many channels would be dependant from one to the other.

and this would be **a nightmare** to maintain (as already clearly stated
by others much more competent than me in Guix-things)

to recap: all PROS that you jgart mentioned in his original message does
not apply (or are "reversed" to CONS) and users would not benefit of
this kind of modularity in terms of speed (likely speed would be much
worse with more than 4 channels to pull in, and 4 channels would be too
few for a complete system)

as far as I can understand from my journey in Guix, it has the **great**
advantage to /expose/ the weaknesses of some (some?) upstream packages
not so... diligent with dependency hygiene, leading to the **big**
problem of dependency hell or dependency confusion, that sooner or later
/someone/ (distro mainatienrs often) have to solve *before* including
that package in the distribution (unlike what is happening with PyPI,
npm and alike: good luck users!)

as Liliana said:

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

 What does work is convincing upstreams to pull in less dependencies and
 drop the outdated ones, because that makes it so that eventually Guix
 has to ship less packages.

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

Unfortunately I have the impression that not so many upstream developers
are really aware of the problem and when they are they think it's a
problem of someone else, not their.

Minimalism at (Guix) System level, one package at a time.

Happy hacking! Gio'

[...]

P.S.: the elevator pitch of all this thread could be: «yes, software
systems are way too /complicated/... but please don't blame Guix for it
(instead "git blame" and bless it!)» :-D

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature

Can zig-build-system be an alternative to the gnu-build-system?

[jgart]

Can `zig-build-system` be an alternative to the `gnu-build-system`? 

https://ziglang.org/learn/why\_zig\_rust\_d\_cpp/#a-package-manager-and-build-system-for-existing-projects

> Not only can you write Zig code instead of C or C++ code, but you can use Zig 
> as a replacement for autotools, cmake, make, scons, ninja, etc. And on top of 
> this, it (will) provide a package manager for native dependencies. This build 
> system is intended to be appropriate even if the entirety of a project’s 
> codebase is in C or C++.

WDYT

Re: Struggling to write Dissecting Guix, Part 2

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

Hi,

On Tue, Jan 24, 2023 at 11:13 PM (  wrote:
>
> I've been struggling to write Part 2 of Dissecting Guix

If it's a matter of explanatory power, I might suggest switching to an
integrative approach and perspective for part 2—i.e. "Putting the
parts of Guix back together". After all, the motivation behind monads
is to combine purely functional components into a larger, effectful,
and more useful sequence of completed tasks.

Kind regards
Felix

Re: Struggling to write Dissecting Guix, Part 2

[bokr]

Hi Simon,

On +2023-01-26 12:17:27 +0100, Simon Tournier wrote:
> Hi,
> 
> On Wed, 25 Jan 2023 at 16:54, Wojtek Kosior via "Development of GNU Guix and 
> the GNU System distribution."  wrote:
> 
> >   here[1] is
> > the paper (written by someone at Microsoft, lol) where I found this
> > approach.
> 
> > [1] https://www.cs.tufts.edu/comp/150PLD/Papers/awkward.pdf
> 
> The author of [1] is Simon Peyton Jones [2].  One of the designers of
> the Haskell programming language and one of the main implementer of the
> Haskell compiler GHC.  And a great speaker and author. :-)
> 
> 2: 
> 
> Cheers,
> simon
> 

Indeed, Simon Peyton Jones is tops.
You may be interested in this[3], if you have not seen it:

3: 

>From the introduction:
--8<---cut here---start->8---
Functional logic languages have a rich literature, but it is
tricky to give them a satisfying semantics. In this paper we
describe the Verse calculus, VC, a new core calculus for
functional logical programming. Our main contribution is to
equip VC with a small-step rewrite semantics, so that we can
reason about a VC program in the same way as one does with
lambda calculus; that is, by applying successive rewrites to
it.

This draft paper describes our current thinking about Verse.
It is very much a work in progress, not a finished product.
The broad outlines of the design are stable. However, the
details of the rewrite rules may well change; we think that
the current rules are not confluent, in tiresome ways. (If
you are knowledgeable about confluence proofs, please talk
to us!) We are eager to enagage in a dialogue with the
community. Please do write to us.
--8<---cut here---end--->8---
Some ideas to enrich guix or the guile language pagoda?

It is interesting that Epic Games has apparently funded quite a
collection of heavies to do some deep abstract thinking.
I imagine SPJ is enjoying discussions. Check the author list!

I got the link at [4] which is much snappier serving than it was
before. (It's a place to go if you are in the mood for something chewy ;)

It also has interesting programming language historical genealogy diagrams.

4: 

(I hope they get https going ;-)

--
Regards,
Bengt Richter

Re: Translation files .gmo and packaging

[Andy Tai]

Hi, I wonder how is this different from the common practice of
projects using GNU autotools, which the project in question is also
one, that the Makefile.in was generated from Makefile.am, but the
tarball may contain the "generated" Makefile.in and configure and Guix
won't bother to re-generate these two files.

In addition, git is a late comer to the free software world and tar
ball releases have been the preferred form of "sources" from the days
before git; whether git repo for the sources exists would not have
mattered, if the canonical source of the project source code is the
official release tarball.


> Date: Thu, 26 Jan 2023 12:39:30 +0100
> From: Simon Tournier 
> To: guix-devel@gnu.org
> Subject: Translation files .gmo and packaging
> Message-ID: <86h6wdsex9@gmail.com>
> Content-Type: text/plain
>
> Hi,
>
> The submission patch#61010 [1] relies on the release archive:
>
> https://github.com/ice-wm/icewm/releases/download/3.3.0/icewm-3.3.0.tar.lz
>
> and this archive contains the generated .gmo files.  However, these
> files are not in the archive:
>
> https://github.com/ice-wm/icewm/archive/refs/tags/3.3.1.tar.gz
>
> neither in the Git repository:
>
> https://github.com/ice-wm/icewm/tree/3.3.0/po
>
>
> The question is:
>
> What is the usual way to deal with these generated files?  Can we
> distribute them although it is not the Guix project that generates them
> from source?
>
> >From my understanding, the package should generate these files if
> possible and not rely on already generated ones.
>
> 1: 
>
> Cheers,
> simon
>
>

Re: tree-sitter grammars for emacs memo

[Simon Tournier]

Hi,

Thanks for the tricks. :-)

On Sun, 04 Dec 2022 at 19:04, Murad Mamedov  wrote:

>  create mode 100644 src/emacs-module.h
>  create mode 100644 src/tree-sitter-lang.in
>
> diff --git a/src/emacs-module.h b/src/emacs-module.h
> new file mode 100644
> index 000..1185c06
> --- /dev/null
> +++ b/src/emacs-module.h

[...]

> diff --git a/src/tree-sitter-lang.in b/src/tree-sitter-lang.in
> new file mode 100644
> index 000..4d27421
> --- /dev/null
> +++ b/src/tree-sitter-lang.in

What does Emacs upstream think about this?  Discussion on emacs-devel
about tree-sitter are really lengthy. :-)  Maybe it could be nice if
that fix would be in Emacs proper.  Well, I do not know.


Cheers,
simon

Re: purpose of GnuTLS versions

[Simon Tournier]

Hi,

On Thu, 26 Jan 2023 at 00:12, Jack Hill  wrote:

> It seems to me that the `gnutls` variable should refer to the latest
> "stable" release, and the `gnutls-latest` variable to latest "next"
> release. Does that make sense? What am I missing?

This means a core-updates change – so next core-updates merge cycle? :-)

If I read correctly, core-updates already uses 3.7.7 for the variable
’gnutls’ and note that the variable ’gnutls-latest’ also uses 3.7.7. :-)

Cheers,
simon

01/02: packages: Adjust 'generate-package-cache' for Guile 3.0.9.

[Simon Tournier]

Hi,

Commit ba1b61a72d56600e7c6f9c490129e95ab9ba0c9e reads:

--8<---cut here---start->8---
packages: Adjust 'generate-package-cache' for Guile 3.0.9.

* gnu/packages.scm (generate-package-cache): Adjust for Guile 3.0.9.

[...]

@@ -442,10 +443,15 @@ (define exp
 (lambda (port)
   ;; Store the cache as a '.go' file.  This makes loading fast and reduces
   ;; heap usage since some of the static data is directly mmapped.
-  (put-bytevector port
-  (compile `'(,@exp)
-   #:to 'bytecode
-   #:opts '(#:to-file? #t)
+  (match (compile `'(,@exp)
+  #:to 'bytecode
+  #:opts '(#:to-file? #t))
+((? bytevector? bv)
+ (put-bytevector port bv))
+(proc
+ ;; In Guile 3.0.9, the linker can return a procedure instead of a
+ ;; bytevector.  Adjust to that.
+ (proc port)
   cache-file)
--8<---cut here---end--->8---

Cool!

What are the performances about this change?  Does it improve the
generation of the cache?  Faster or slower?

Or the resulting cache, is it larger or smaller?


Cheers,
simon

Translation files .gmo and packaging

[Simon Tournier]

Hi,

The submission patch#61010 [1] relies on the release archive:

https://github.com/ice-wm/icewm/releases/download/3.3.0/icewm-3.3.0.tar.lz

and this archive contains the generated .gmo files.  However, these
files are not in the archive:

https://github.com/ice-wm/icewm/archive/refs/tags/3.3.1.tar.gz

neither in the Git repository:

https://github.com/ice-wm/icewm/tree/3.3.0/po


The question is:

What is the usual way to deal with these generated files?  Can we
distribute them although it is not the Guix project that generates them
from source?

>From my understanding, the package should generate these files if
possible and not rely on already generated ones.

1: 

Cheers,
simon

Re: Struggling to write Dissecting Guix, Part 2

[Simon Tournier]

Hi,

On Wed, 25 Jan 2023 at 16:54, Wojtek Kosior via "Development of GNU Guix and 
the GNU System distribution."  wrote:

>   here[1] is
> the paper (written by someone at Microsoft, lol) where I found this
> approach.

> [1] https://www.cs.tufts.edu/comp/150PLD/Papers/awkward.pdf

The author of [1] is Simon Peyton Jones [2].  One of the designers of
the Haskell programming language and one of the main implementer of the
Haskell compiler GHC.  And a great speaker and author. :-)

2: 

Cheers,
simon