Re: A Forum for Guix Users

[Csepp]

Pjotr Prins  writes:

> On Fri, Jul 14, 2023 at 02:10:49PM -0700, Felix Lechner via Development of 
> GNU Guix and the GNU System distribution. wrote:
...
>> 1. Our community is small, and possibly shrinking.
>
> I doubt that is true in absolute terms. You should see where we were
> 10 years ago :). Guile and Racket made impressive gains the last
> years.
>
> In relative terms we can't compete and should not aim
> to do so with either Guix or Guile.
>
>> 2. Scheme is a niche language that is not being promoted enough.
>
> Lisp will always be niche. Why would it change in half a century? The
> power of Lisp comes from its syntax - but it is a barrier to entry at
> the same time. I am always amazed they came up with that early in CS
> history.

Like I've mentioned on fedi before, advocates of Lispy languages tend to
talk a lot about what's *possible* with the language, but the truth is
that the actual tooling that matters simply isn't very good, and having
an S-expression based syntax doesn't magically make writing the kinds of
refactoring tools that Java developers have been enjoying for 10+ years
significantly easier.
For that we need good *static analysis*, and unbounded dynamism and too
much syntax magic makes that *more* difficult.
At the very least I want to be able to rename variables across the whole
project and jump to definitions reliably.

Before trying to convince me otherwise in replies, please go and try
Eclipse, or even JetBrains if you have access to it (I think it has an
open source version??), just so you know what you are up against as a
free software advocate trying to convince developers to use Scheme.
I was set out to hate JetBrains when I had to use it in uni this
semester, but I was pleasantly surprised by how easy it was to use.
I'm not saying this to advertise Java tools, I'm saying this to snap
Lispers out of the reality distortion bubble some of them seem to be
stuck in.

TLDR: instead of looking for excuses for why no one gets Lisp, we should
be actually addressing the complaints.  Then maybe people will start
getting Lisp.

ps.: As far as I can tell, the Lisps with good IDEs are image based, not
source based, that's why they have an easier time doing metaprogramming,
because the runtime helps a lot.  But an image based system is not
exactly in line with Guix's goal of reproducibility.

Re: Development repositories as Guix channels

[Arun Isaac]

> Another person reported that missing bit to me and I’ve now fixed the
> blog post.  Apologies for the waste of time!

No worries! It's been a very enlightening blog post. Thanks for writing
it!

Re: News from Cuirass

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

Hi Ludovic,

On Sun, Jul 16, 2023 at 6:53 AM Ludovic Courtès  wrote:
>
> Cuirass now uses a database
> connection pool

That is super exciting! In another implementation the pooling code
comes with the database interface [1] which makes it available more
broadly. Could the pooling code, which presumably lives here, [2]
perhaps become part of Guile-Squee?

Also, Kudos on your dive into ZeroMQ! I hope you find the experience
as rewarding as I did.

Kind regards & thanks,
Felix

[1] https://node-postgres.com/features/pooling
[2] 
https://git.savannah.gnu.org/cgit/guix/guix-cuirass.git/tree/src/cuirass/database.scm#n269

Re: Adding GNAT/GCC-Ada to Guix

[Denis 'GNUtoo' Carikli]

On Sun, 16 Jul 2023 08:47:41 +
Fernando Oleo Blanco  wrote:

> Dear Guix community,
Hi,

> Why did I tell all of this?
> Because I would like to add GCC-Ada to Guix and I am fully aware of
> the work that the Guix and the #bootstrappable people are doing
> towards a fully transparent compilation history. Opaque binaries are
> not allowed for that purpose. Sadly that is not currently possible
> with Ada. Therefore, I would like to get permission to add GCC-Ada as
> a binary up until there is a bootstrapping path available. I am aware
> that some languages/tools have received this treatment before.
I don't know well the exact policies with that regard (I'm not a Guix
maintainer, just an occasional contributor) but I found the following
compilers in Guix source code:

- The haskell is not and was never bootstrapped from source. Though
  the binaries used to bootstrap it changed over time.

- There are also other compilers like vala and nim that convert vala
  and nim source code to C. The issue is that they are written in vala
  and nim, and Guix uses generated "source code" (generated C that is
  very hard to read) to build the compilers. People usually don't
  modify nor audit that kind of generated source unless it is for
  debugging purposes.

> 3. What can Ada provide to Guix?
> 
> Apart from being an official language of the GCC toolsuite, it is
> also used in some important and unique places. For example, the
> graphics stack of Coreboot/Libreboot among other drivers are written
> in Ada [3] (you can find more by running `find . -type f -name
> "*.ad*"` on Coreboot's root folder).
Nowadays Libreboot includes nonfree software in its releases, so
because of that me and Adrien 'Neox' Bourmault started working to
continue the original spirit of the old Libreboot that didn't contain
any nonfree software.

And while we don't have a release yet, in the longer run we're
interested in using Guix for building it because Guix is FSDG compliant
and it can be installed on top of most GNU/Linux distributions.

It would also make the maintenance easier and shared with other users of
Guix, enable to easily rebuild older releases, have faster build
times, etc.

Since it's also possible to inherit packages, in the long run it
would probably makes sense for us to move most of our work in Guix.

So having some ways to build software written in Ada with Guix would
make a big difference here as without that we would probably only be
able to use Guix only for some parts (like for building GRUB, SeaBIOS
etc for Coreboot).

Without that, Guix users would also need to use another distribution
with Guix inside to be able to build it.

> It is also the base programming
> language of SPARK [4], a verifiable, GPLv3 licensed, programming
> language, used for the ARIANE rockets and the Rosetta space probe for
> example. And of course, there are plenty of libraries, tools and
> programs written in Ada! Without a compiler, none of this can be
> packaged in Guix...
At the last FOSDEM, I was also shown at the ADA table that it was
also possible to build software for micro-controllers with it.

Though I've no idea if there are interesting free software firmwares
written in Ada worth packaging in Guix.

Anyway, Thanks a lot for all your work on this.

Denis.


pgpr70fbsNZug.pgp
Description: OpenPGP digital signature

News from Cuirass

[Ludovic Courtès]

Hello Guix!

A couple of months ago, I found myself working on hot fixes for Cuirass,
whose repository had been gathering dust for months.  One thing leads to
another, and I’ve worked on a few improvements recently:

  • Guile-Squee (interface to PostgreSQL) now cooperates with Fibers,
meaning that ‘exec-query’ is suspendable.

  • Thanks to advice from Chris Baines, Cuirass now uses a database
connection pool instead of the database service thread it used to
have.

  • ‘cuirass remote-server’ and ‘cuirass remote-worker’, the processes
in charge of distributing builds remotely and that communicate over
ZeroMQ, are now single fiberized processes (this was made possible
by making the ‘receive-message’ procedure, built upon
Guile-Simple-ZMQ, cooperative).  These commands used to spawn a
bunch of processes and threads.

  • Assorted improvements to the web interface and to logging.

I’m regularly deploying the latest revision at
 using the Cuirass channel (I’m
purposefully postponing an update of the ‘cuirass’ package until I’ve
acquired more experience and confidence.)  If you’re running an instance
of Cuirass and feeling adventurous, you can try it as well:

  (cons* (channel
  (name 'cuirass)
  (url "https://git.savannah.gnu.org/git/guix/guix-cuirass.git;)
  (introduction
   (make-channel-introduction
"c75620777c33273fcd14261660288ec1b2dc8123"
(openpgp-fingerprint
 "3CE4 6455 8A84 FDC6 9DB4  0CFB 090B 1199 3D9A EBB5"
 %default-channels)

With these architectural changes, we should be able to make more visible
improvements such as adding web hooks (so a Git repo can trigger a new
evaluation), replacing polling with notifications in many cases, adding
a Build Coordinator backend (convergence!), etc.  See
.

Contributions welcome!  :-)

Ludo’.

Re: First line should describe the file, not Guix

[Ludovic Courtès]

Hi,

"McSinyx" via "Development of GNU Guix and the GNU System distribution."
 skribis:

> I suggest changing the first line into describing the source file,
> which goes in hand with

I agree in principle (this is what many GNU packages would traditionally
do), but there are many files in Guix these days…  Maybe a good exercise
for someone who’s taken a guided tour of the code such as
?

Thanks,
Ludo’.

Re: Development repositories as Guix channels

[Ludovic Courtès]

Hi!

Arun Isaac  skribis:

>> You have to replace the relative path in the local-file form with
>> "../.." as that gives you the root of your source tree relative to the
>> new location of the Scheme file. Then everything works nicely.
>
> Thank you! That's all I was missing. Now everything works perfectly!

Another person reported that missing bit to me and I’ve now fixed the
blog post.  Apologies for the waste of time!

Ludo’.

Re: Transformations Shell Syntax

[Ludovic Courtès]

Hi,

"jgart"  skribis:

> In other words being able to specify workers with shepherd:
>
> Starting multiple workers:
>
> $ herd start microblog-tasks@{1..4}
> $ herd status microblog-tasks@{1..4}
>
> Restarting a particular worker:
>
> $ herd restart microblog-tasks@3
>
> WDYT

I’ve never felt the need for this, and I’m typically not a “syntax
person” so to speak ;-), but *if* there is an actual need for this, then
we can thing about it.

(We might want to be more general though, like essentially allowing
users to apply an action such as ‘start’ to a set of services regardless
of their naming scheme.)

Ludo’.

Adding GNAT/GCC-Ada to Guix

[Fernando Oleo Blanco]

Dear Guix community,

I would like to bring once again [1] the discussion regarding the 
addition of a modern Ada compiler to Guix. In this case, GCC-Ada, aka GNAT.

TL;DR: GCC-Ada/GNAT cannot be bootstrapped. I would like to package a 
binary up until a bootstrap path is available; which is already under 
discussion.

As far as I know, GCC-Ada has not been added to Guix for two major 
reasons. The first one is the lack of bootstrappability and the second 
one is that no one has given it a thorough try. This emails hopes to 
shed some light on both of these topics.

1. Bootstrapping Ada

GCC-Ada (originally known as GNAT) has always required a previous GNAT 
version to compile newer releases. Ada was made an official language of 
the GCC stack with the GCC 3.1 release. Before this release, GNAT was 
distributed as a set of patches that had to be applied to GCC's src and 
it required a previous GNAT compiler to be available. I could not find 
"the original binary", but I have found ancient GNAT patch sets. The 
first (non-public) binaries were created using an Ada 83 compiler, 
potentially with Ada-Ed, an Ada 83 interpreter written in C (already 
available in Guix). However, the first publicly available patches dating 
from (GCC 2) already used Ada 95 features and required the Ada 95 
compiler based on GCC. What does this wall of text mean?

There was never a publicly available GNAT/GCC-Ada compiler that could be 
bootstrapped. The bootstrapping path was never made available and has 
been lost to history.

Why did I tell all of this?
Because I would like to add GCC-Ada to Guix and I am fully aware of the 
work that the Guix and the #bootstrappable people are doing towards a 
fully transparent compilation history. Opaque binaries are not allowed 
for that purpose. Sadly that is not currently possible with Ada. 
Therefore, I would like to get permission to add GCC-Ada as a binary up 
until there is a bootstrapping path available. I am aware that some 
languages/tools have received this treatment before.

2. A path towards bootstrapping GCC-Ada

As I said, some of us are aware of the issue mentioned above. We have 
already talked about a solution. I will not explain it here. Please, 
read the forum posts available in [2]. However, a bootstrapping compiler 
is years into the future.

3. What can Ada provide to Guix?

Apart from being an official language of the GCC toolsuite, it is also 
used in some important and unique places. For example, the graphics 
stack of Coreboot/Libreboot among other drivers are written in Ada [3] 
(you can find more by running `find . -type f -name "*.ad*"` on 
Coreboot's root folder). It is also the base programming language of 
SPARK [4], a verifiable, GPLv3 licensed, programming language, used for 
the ARIANE rockets and the Rosetta space probe for example. And of 
course, there are plenty of libraries, tools and programs written in 
Ada! Without a compiler, none of this can be packaged in Guix...

4. The dreaded binaries

As I said, I would like to package GCC-Ada, but it would initially be a 
binary blob (a semi-trusted one, maybe one from the Alire [5,6] project 
or Debian [7]). Are the Guix maintainers okay with this? Would you 
accept such a commit?

4.5 Some technical data about the proposed binaries

The Debian binary is just the GNAT/GCC-Ada compiler, meaning it has as 
dependencies gcc-12, libc6, libgmp10, libgnat-12 (Ada STL), etc. The 
compressed size of the package is ~18 MB, uncompressed it weighs ~91 MB. 
This indicates that it is not a high entropy package. However, as I said 
before, this is a very barebones Ada installation and it may make the 
package creation quite complex as other binaries may be required.

The Alire installation [6] weighs 296 MB compressed. Uncompressed it 
becomes a 837 MB folder. The reason for the much larger weight (but 
still relatively low entropy) is that the Alire binary comes with the 
entire compilation suit. It has a C/C++ compiler, Ada, binutils, GDB, 
some runtime environments, etc. It is a full, self-contained 
installation that is designed to be a drop-in deployment to get started 
compiling Ada. The compilation of this package is done using this python 
script [8], so the process is transparent.

5. Closing up

I personally would like the Alire installation media to be allowed as a 
binary if this proposal is accepted. This is because it is much easier 
to package (as the package would not need to link to other compilers or 
libraries) and it is the standard tooling used in the Alire project 
(think of Rust's Cargo but for Ada), which makes it fairly standard 
within the community.

What do you think? Is this a good idea? Should Guix accept this? Should 
Guix not provide an Ada compiler unless it can be bootstrapped, which 
will take years?
Of course, I would like to see this accepted, but I believe an initial 
discussion is required.

[1] https://lists.gnu.org/archive/html/guix-devel/2017-01/msg01568.html
[2] 

Re: A Forum for Guix Users

[Pjotr Prins]

On Fri, Jul 14, 2023 at 02:10:49PM -0700, Felix Lechner via Development of GNU 
Guix and the GNU System distribution. wrote:
> Hi Robby and Sarthak,
> 
> On Thu, Jul 13, 2023 at 7:17 AM Robby Zambito  wrote:
> >
> > I personally think that it would be wiser to improve the documentation
> > relating to the mailing lists and IRC logs
> 
> I'm technically one of the administrators of forums.debian.net and
> would not recommend web-based "forums" to projects that do not have
> them. They are hard to search and even harder to police. Also, the
> software tends to be based on dated technologies. There are better
> ways to help people in need.
 
Thanks to Arun we rolled our own issue tracker and knowledge base with

https://issues.genenetwork.org/

Written in Guile the interface is simple, the backend is simply a git
repo (can be hosted anywhere), and it uses a xapian search indexer.
Personally I think this is an awesome way of tracking information and
allows reorganising information and rewriting history. The tags are
arbitrary - though we clearly focussed on an issue tracker here.

If the xapian indexer also analysed mailing list output (through
publicinbox, for example) and maybe debbugs and IRC logs it would be
complete. 

https://public-inbox.org/README.html

Key thing is that people can post, answer questions, track issues etc.
and make it all findable. Fun - but probably useless - fact is that we
can also serve it over gemini.

> The points that were mentioned resonate with me, but I actually find
> Guix's documentation quite good already (possibly even second after
> Arch).

+1. 

> We have five broad issues, however:
> 
> 1. Our community is small, and possibly shrinking.

I doubt that is true in absolute terms. You should see where we were
10 years ago :). Guile and Racket made impressive gains the last
years.

In relative terms we can't compete and should not aim
to do so with either Guix or Guile.

> 2. Scheme is a niche language that is not being promoted enough.

Lisp will always be niche. Why would it change in half a century? The
power of Lisp comes from its syntax - but it is a barrier to entry at
the same time. I am always amazed they came up with that early in CS
history.

> 3. Guix uses a complex file layout that's different from most other
> distributions.

We have the fhs bindings. But yeah, that is another barrier.

> 4. Our master branch often suffers from small defects that prevent
> declared systems (and home configurations) from being updated in full.

I think the stable releases try to address that. But I agree, Guix is
a moving target. I don't see that changing much. 

> 5. Substitute availability is good, but download speeds can be poor
> due to peering issues.

That is a matter of money, I guess.

> Personally, I think that promoting GNU Guile in other settings has
> perhaps the best potential to lower our barriers to entry. People
> should not be writing shell scripts in 2023.

They always will, including me. I am, however, giving Guile talks and
promote rash and gash. I am submitting a talk to ICFP Seattle.

https://icfp23.sigplan.org/home/declmed-2023

You can still do that too. I know they have slots.

> Other than that, everyone can make themselves available to help folks
> with difficulties on the existing mailing lists.
> 
> Everyone writes something silly from time to time. It's not a big
> deal. The helping hand is what counts!

Thanks!

Pj.