Re: Welcome to Jorge Gomez (jgart) as a new Guix committer

[Blake Shaw]

Congratulations jgart! Glad to see you're plowing ahead :)

"jgart"  writes:

>> I'd like to welcome Jorge as a new Guix committer! Jorge has been
>> around for some time already, and is always very active around the Guix
>> community; I'm sure they'll know to use their new privilege in a way
>> that benefits the Guix community!
>
> Hi Maxim,
>
> Thanks for the warm welcome. It is much appreciated. I look forward to
> continuing to push our efforts forward as a group.
>
> I also want to thank everyone who has reviewed and merged my patches
> in the past and I look forward to now returning the help to others.
>
> all best,
>
> jgart
>
> ps
>
> I also made a statement about my commit access grant here:
>
> https://lists.gnu.org/archive/html/guix-devel/2023-05/msg00202.html

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

[Blake Shaw]

This has reminded me of Make's built-in support for guile[1].

I've assumed that the fact that we don't use it means that it
probably depends on an earlier guile, as many projects many
that support "guile scripting" typically depend on ~v1.8; but
that is just an assumption.

Does anyone know what its status is?

[1] https://www.gnu.org/software/make/manual/html_node/Guile-Integration.html

Pjotr Prins  writes:

> Hi jgart,
>
> zig as a build system is nice, but it is llvm bound and only targets
> zig and C/C++. It does not handle packages, and that is a feature in
> my book ;). Mind they are planning to go down the packaging route,
> from what I can tell.
>
> There have been some older discussions about creating our own
> replacement for autotools, cmake and others. I often fight these make
> make systems - and meson and/or language specific build systems. It is
> a time waster for programmers and none of these systems leverages the
> power of Guix itself. I kinda settled for cmake because, even though
> it is an effing dragon, at least I can make it work (pun intended).
>
> We need someone with deep experience in build systems to write a guile
> replacement - generating ninja is one idea. That is my opinion :). I
> would love a simple way to describe a project in guile. It should not
> be too hard actually (famously that is how these projects start and
> turn out to be a real time sink). Maybe someone wants to try with
> guidance from us, or maybe we can do it when we get bored some day.
>
> Pj.
>
> On Fri, Jan 27, 2023 at 02:03:06AM +, jgart wrote:
>> 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: (ice-9 base64)?

[Blake Shaw]

+1 for (ice-9 base64)

On Wed, Aug 17, 2022, 02:04 Maxime Devos  wrote:

>
> On 16-08-2022 19:21, Aleix Conchillo Flaqué wrote:
>
>
>
> On Tue, Aug 16, 2022 at 9:59 AM Maxime Devos 
> wrote:
>
>>
>> On 16-08-2022 18:10, Aleix Conchillo Flaqué wrote:
>>
>> Hi,
>>
>> In many projects I've been copying Göran Weinholt's base64
>> implementation and I've also seen it in other projects, would it make sense
>> to include it in Guile's standard library? [...]
>>
>> If we do this, we should contact the various other projects to make them
>> use (ice-9 base64).
>>
>
> I think they could switch whenever they want (i.e. whenever this was added
> to Guile) or even not switch at all.
>
> Sure, but they can't switch if they don't know about it. And if they don't
> know about it and hence don't switch, the proposal fails at its purpose of
> unbundling base64. Besides, we need them to switch (see Guix no-bundling
> policy and the reasons behind it) -- if upstream refuses to unbundle, then
> in our locally modified version for Guix.
>
> I think it would be simpler though to consider the base64 in guile-gcrypt
>> to be 'canonical', it would avoid problems with old versions of Guile not
>> having the base64 module and newer version having it, which would prevent
>> using the proposed (ice-9 base64) in Guile because it would break
>> build-aux/build-self.scm when pulling or time-machining from old Guix that
>> have an old Guile.
>>
>
> I've been waiting on a guile-gcrypt release for a while now (Ludo,
> Chrisitine... any help here? :-) ).  I ported guile-jwt to use guile-gcrypt
> but I need a release to have latest base64 changes:
>
>
> https://notabug.org/cwebber/guile-gcrypt/commit/f8934ec94df5868ee8baf1fb0f8ed0f24e7e91eb
>
> Right, it has some fixes that are presumably important.
>
>
> But you are right that this would cause a backward compatible problem, but
> I guess that would depend on each project. Can we do conditional module
> loading? I've done this in the past with Python... if we are in Python 2
> load this module, otherwise load this other one. So projects could do that.
>
> Yes, using resolve-module with #:ensure #f & module-ref. Or with syntax
> tricks and (version), to decide things at compile-time.  Still, if you do a
> conditional module loading, you still need a fallback, and the fallback
> would still be bundling.
>
> Whether we simply replace (guix base64) by (gcrypt base64) depends on how
>> old (gcrypt base64) is compared to the earliest 'supported' Guix for
>> pull/time-travel, but even if it is not present in the old gcrypt, we can
>> work-around that (we have a 'fake-gcrypt-hash' in build-aux/build-self.scm,
>> so we can easily have a (define gcrypt-base64 [some copy])).  Or simply
>> update the local guile-gcrypt in buid-aux/build-self.scm.
>>
> guile-gcrypt base64 is pretty new with the patch above (but no release
> after that), I have no idea if Guix has added anything else.
>
> base64 is available in at least 0.3.0, which is packaged in Debian
> bullseye (which is considered "stable"), so not too new, though we might
> need to change build-aux/build-self.scm if 0.1.0 doesn't have base64.  Guix
> appears to have the pre-quoted-patch version, without changes of its own
> except for a different module name.
>
> OTOH a similar replacement can be done for (ice-9 base64), but
>> transitioning to (ice-9 base64) would take much longer, at least until the
>> various distributions are updated to a Guile that has (ice-9 base64),
>> whereas (gcrypt base64) could be switched to immediately.
>>
> Maybe this could be handled by each project independently.
>
> They wouldn't have to if the base64 module is put in (guile gcrypt).
>
> Greetings,
> Maxime.
>

Re: Is Guix suitable for large monorepos?

[Blake Shaw]

Hiya guix,

I tried to reply to this quickly while I was travelling, but what started
with "sorry to brief" quickly became quite long -- nonetheless I think
theres some important insight into using Guix effectively in production I'd
still like to share, so will finish it off now that I'm back:

==
I'm traveling at the moment so excuse me for being brief but I saw
Katherine's message about long source rebuilds and want to try to chime in
quickly.

I had a difficult experience of using Guix in production against a
medium-large C++ repo (openFrameworks) in June when substitute availability
was failing a good deal of the time, along with several broken packages
"infecting" a decent area of oF's ~140 package dependency graph, to add to
the mayhem.

Considering it was a moment I needed to move fast, I created a hotfix
branch where I could disable tests, do quick gnarly fixes and keep moving.
Its worth noting that working like this you can really knock out a lot of
package "fixes" quickly, I was able to do 10 in a day, but also this was
while deploying a video mapping project so security wasn't a huge concern.

This initially worked decently, in terms of maintaining project momentum
while racing towards a delivery. But when it came to installing on the
servers and the laptop onsite, which came with their own difficulties, the
build times started weighing in more than I was able to handle.

I had been considering starting a Cuirass instance but was worried it would
be too difficult to figure out in constrained time. At some point I thought
"you know what lets try this just not sleep and see if cuirass can be a
solution, and if its immediately confusing shelve it and move on". But the
truth was...

...Cuirass was one of the quickest parts of the Guix system I've hit the
ground running with.

I really wish I had deployed it from the outset, and I surely will on all
future projects. Within a day of fiddling with it I had my linode providing
substitutes of not only my dependency graph, but also generations of three
different systems, as well as VMs. After the first night of building i
suddenly had lightning fast substitutes available and problems upstream
faded away. In short, had I used Cuirass from the get-go I would have saved
myself from a massive amount of difficulty.

The difficulty with reproducibility in production is that it you're
constrained for time, building back to a month old generation can be out of
the question. I think there is a "reproducibility ideal" that we and the
Nix folks often allude to as our reality, where "you just roll back", but
the conditions of production can often make this unfeasible. Before my next
gig I plan to automate things so that I can easily tag commits in git that
will trigger system generations to be built and stored as QEMU images that
I can quickly access as need, which I think will bring me closer to this
ideal. I'll be sure to share when it comes time (but currently taking a
little break from being deep in the weeds).

Also, my apologies that I haven't been contributing much... an experiment
with self-hosting my email earlier this year ended with a borked email
server and I have yet to setup gnus & git with this email address. Will be
rolling up my sleeves in the coming weeks :)

Happy hacking!
b



On Fri, Jul 22, 2022, 21:26 Katherine Cox-Buday 
wrote:

> jgart  writes:
>
> > Is Guix suitable for large monorepos?
>
> I use Guix against a large mono-repo, and there are a few
> difficulties.
>
> I should mention that I am not using Guix in the typical fashion with
> fixed commits (packages are pointed at HEAD and I don't use checksums).
> For my purposes, it's useful for me to build HEAD, although sometimes I
> use transformation options if I'm interested in a specific branch or
> commit.
>
> I've defined a package for the entire repo and then individual packages
> for the constituent projects which inherit from the repo package.
>
> For new commits:
>
> - Updating the source take a long time.
> - Indexing the entire repo takes a long time.
> - Copying over the entire tree to the build directory is unnecessary and
>   takes time.
>
> Sometimes I want to build a local change I haven't committed anywhere,
> so I use the --with-source option. The problems are the same, but
> they're exacerbated.
>
> A happy medium I've landed on is to build some binaries outside of Guix
> and then use packages that are defined in terms of the binaries. These
> packages use patchelf to get everything linked correctly. This allows me
> to reify these packages into Guix while keeping the standard workflow
> from a programming language.
>
> I've also considered a phase that, after checkout, deletes all files not
> relevant to the project to lessen the burden of copying things over for
> building.
>
> So, in my opinion, these issues are not really Guix's fault, and it does
> a pretty good job all things considered. I think Guix used in a CI/CD
> pipeline (which I guess means cuirass) would 

Re: [WIP Patch] Adding an FHS container to guix shell

[Blake Shaw]

hi John!

I think it sounds like a swell addition to Guix, something that I would
definitely reach for time to time.

good stuff.

ez,
b

On Wed, Jul 13, 2022 at 2:26 AM Dominic Martinez  wrote:

>
> John Kehayias  writes:
>
> > First, I wanted to ask how people feel about such a feature. Obviously,
> one use
> > is to run pre-built binaries (isolated!), but this is also handy for
> setting up
> > development environments when not able (or wanting) to with Guix
> packages only.
> > For example, using the rustup [0] scripts, pretty much anything JS, or
> just
> > following typical Readme instructions to try out something new before
> packaging.
> > I won't debate the details here other than to say this topic comes up
> with Guix
> > and I think it is yet another useful tool for guix shell and containers.
>
> Absolutely! I usually have to resort to Docker containers when building
> something that doesn't support GuixSD, so being able to work with them
> through Guix would be amazing.
>
> > What about other uses for this container, like providing an isolated
> environment
> > to build and run software we can't do fully with bootstrap and sources
> (like
> > JS)? Could this become some stop-gap to allow people to work with these
> > ecosystems in a more controlled way within Guix? Or an alternative build
> > environment? Not entirely sure what this could mean, just thinking out
> loud.
>
> I think an interesting idea would be to allow packages to transparently
> run in the FHS container (i.e. a shim that turns 'x' into 'guix shell
> --fhs-container x -- x'). That way software incompatible with GuixSD in
> a way too difficult to patch could be still be packaged and used
> transparently, albeit with a significant performance cost.
>
> Even if packages in Guix proper don't use it, it could be useful for
> third-party channels or end-users to whip up packages.
>
> Thanks so much for this; I've been thinking about getting around to this
> feature for quite a while.
>

Wiki && Re: [feature request] merge sxml->html from (haunt html) into guile?

[Blake Shaw]

Hi Luis,

(copying in Guix as I digress into the subject of a Wiki for Guix & Guile
communities)

Thanks for this! It's cool and I would not have found it without your help.

Which brings up another thing I've been considering working on thats been
discussed in the Guix community: the need for click-to-edit wiki, written
in Guile.

If we had a wiki up, there could be an "HTML" stub, for instance, that
collects links to all projects using HTML in guile. Finding out whats
available would be streamlined, and relatively painless to update and
moderate.

I have some free time for the next month, and should be able to knock out a
basic wiki system in this time (I found what looks like a nice book about
wikis that I could read and use as a guide for implementing it).

Since getting feedback on my presentation for Guix Days, where I think a
lot of good criticism was raised, I've been thinking about ways to organize
contributions to the docs. An idea I've had is to create a wiki that has a
basic system of tags that can link with Mumi so that while folks are
looking things up they can also get a sense if there are "TODOs" concerning
a subject they reading up on, even beyond contributing to the docs. Many
folks have expressed that they want to start chipping in, but aren't quite
sure where to start. Perhaps something like this could help ease that
process, and make updating information more dynamic and less critical than
in the main docs.

Any thoughts?

ez,
b

On Tue, Jun 28, 2022, 20:26 Luis Felipe 
wrote:

> Hi Blake,
>
> On Monday, June 27th, 2022 at 06:57, Blake Shaw 
> wrote:
>
> > Finally I caved and decided to look at the Bootstrappable source code,
> and
> > voila! (haunt html) provides sxml->html... the piece of the puzzle I was
> > missing. Massive, near comical, relief.
>
> Just to mention that there is also htmlprag, from guile-lib (
> https://www.nongnu.org/guile-lib/doc/ref/htmlprag/).

Re: Teams: first draft list

[Blake Shaw]

Hi y'all,

This looks great, thanks for putting in the work!

Im getting back into the Guile + Guix documentation, and realize its a
subject the @whereiseveryone and others are also working on, and thus it
could probably use a concentrated team of its own. What do others think?


Best,
Blake

On Wed, Jun 22, 2022, 20:51 Ludovic Courtès  wrote:

> Hi,
>
> Ricardo Wurmus  skribis:
>
> > Now the question is merely how to represent and present this.  It’s not
> > a bad idea to have the team associations in the repository so that we
> > can present the data on the website and also use it with our tools to
> > notify the right people.
>
> Mathieu suggested that we have a team file in guix.git, which would
> allow us to eventually write tools like ‘get-tutors.scm’ as Mathieu
> calls it.
>
> The web site could fetch that file and present one tile per team on a
> page.
>
> > It wouldn’t help with keeping mailing aliases on fencepost up to date,
> > though.
>
> Argh, yes.  Maybe this can be addressed later?  Having a list of teams a
> name would already help, even if there are no email aliases.
>
> Then perhaps we could automate alias creation with @guix.gnu.org
> addresses?  Not sure what it would take…
>
> > I also wonder about how / if we should notify teams about relevant
> > patches.  Will contributors Cc the relevant teams or will we have team
> > predicates, e.g. a procedure that spits out the appropriate teams when
> > given a patch?
>
> I think we can start small and build up automation incrementally.
>
> Thanks,
> Ludo’.
>
>

Re: how to write services (was: Re: Teams)

[Blake Shaw]

Thanks for the feedback, abelian groups are a good example because so many
groups are abelian (fields etc).

But, perhaps it's just getting late and the matters are now & the details
are slipping my mind, but im starting to realize im unsure of many examples
of file-like objects that aren't a file? The email where you responded re:
packages was cut short, but it seemed to be that you were saying that
record-types *aren't* file-like, when I had thought they are; I thought
anything with simple means of serialization could be considered file-like,
and that pseudofiles (/devs, /procs, etc) were also in the file-like
category (which is apparently a misnomer on my part).

Would anyone care to share an explanation of what is/is not a file-like
object in Guix? Are fluids not considered file-like? I had thought that
would be a use case where this geneticity becomes important.

I remember when I first encountered gexps I thought, as FLOs didn't seem to
be files, they were either records or fluids. It took me a good while to
realize a file-like object is usually just a file, haha

On Thu, Jun 16, 2022, 05:28 Maxime Devos  wrote:

> Blake Shaw schreef op wo 15-06-2022 om 21:40 [+]:
> > On the contrary, lets say I'm writing an intro book on CT. If I'm
> > demonstrating something trivial, say the initial object, I'm not
> > going to refer to it as "an initial-like object" for the sake of
> > generality.
>
> Neither does Guix?  If you're in a context where only the basic object
> (in this case, your demonstration the initial object) is used, just
> talk about the basic object.  But in a later section where you
> generalize things to ‘initial-like objects’ (whatever that would be in
> CT, I don't know any CT), you talk about ‘initial-like objects’, not
> ‘initial object and initial-like objects’.
>
> For an example from another domain, consider groups in algebra.
> In group theory, we have e.g. the fundamental theorem on homomorphisms.
> Wikipedia formulates this as:
>
> Given two groups G and H and a group homomorphism f : G → H, let K be a
> normal subgroup in G and φ the natural surjective homomorphism G → G/K
> (where G/K is the quotient group of G by K). If K is a subset of ker(f)
> then there exists a unique homomorphism h: G/K → H such that f = h∘φ.
>
> An equivalent statement could be made by replacing ‘given a group’ by
> ‘given an Abelian group or a group’:
>
> Given two Abelian groups or groups G and H and a group homomorphism f :
> G → H, let K be an Abelian normal subgroup or normal subgroup in G and
> φ the natural surjective homomorphism G → G/K (where G/K is the
> quotient group of G by K). If K is a subset of ker(f) then there exists
> a unique homomorphism h: G/K → H such that f = h∘φ.’
>
> But why do such a pointless thing, wouldn't just talking about groups
> instead of ‘Abelian groups or groups’ be much simpler?
>
> TBC: here ‘file-like object’ ≃ ‘group’ and ‘file’ = ‘Abelian group’.
>
> Greetings,
> Maxime.
>

Re: how to write services (was: Re: Teams)

[Blake Shaw]

Ricardo:
Thats very good advice and will be a useful guide in refactoring the parts
of the system services documentation. I think in general, we need to find a
nice middle ground between the extremely general and the immediately
sensible, as I remember when I first got into guix 1.5 years ago, arriving
at services left me very confused. While as a recent PhD candidate in
philosophy of mathematics I'm a fellow appreciator of the power of
generality (the extreme genericity of scheme and guix is why I'm here!), I
also think if it doesn't obey strict linguistic rules it can antithetical
to its original purpose. For example, I remember being very confused about
"file-like objects", for the simple reason that it wasn't "a file or
file-like object". While this might come from a GNU terminological lineage
i'm unaware of, my immediate reaction to trying to understand file-likeness
is the simple rule that a semblance is strictly not what it resembles, and
likeness qualifies semblance. It would be improper to place phones in a
category of "phone-like objects", because the likeness assumes a
distinction from the thing itself. Perhaps it could be justified if we dive
into the minutiae of paraconsistent logic, but I think then we are going to
far (also, isn't 'everything a file' a motto of Unix, even if gnu is
strictly not?). But I've digressed; I think your straightforward
description above communicates many of the ideas better than the docs, but
I think this is a situation where we can have our cake and eat it too, so
to speak; usually, an appendage such as "file AND file-like objects" will
accomplish much of the work for us.

Catonano:
I think writing a home-service is much easier given that you don't need to
do produce an entire system generation before you find out what you did
wrong; it just depends on if you need your service initialized at startup
(system-services, globally defined and available prior to login) rather
than at login (home-services, per-user/locally defined).

I'm not on Mastodon but feel free to send your service my way for some
help, I'm still a beginner but a second pair of eyes is always nice to have.

ez,
b


---
Blake Shaw
Director, SWEATSHOPPE
sweatshoppe.org
---


On Wed, Jun 15, 2022 at 2:04 PM Ricardo Wurmus  wrote:

>
> caton...@gmail.com writes:
>
> > Il giorno mer, 15/06/2022 alle 01.52 +0700, Blake Shaw ha scritto:
> >>
> >> I found the documentation to be a bit confusing (understandably, as
> >> its new), but once the workflow snapped together its been amazing to
> >> see how easy it is to create new services.
> >
> > This is something I'm specifically interested in
> >
> > In fact, I wrote this toot that got several boosts and likes but NO
> > answer
> > https://floss.social/web/@abbienormal/108378060174601402
>
> I don’t know Odoo, but the general process is this:
>
> - look up the relevant documentation of your application to figure out
>   what commands must be executed.  Take note of any way to pass a
>   configuration file.
>
> - copy an existing shepherd service.  Maybe start with
>   gnu/services/audio.scm, because it’s pretty simple while not completely
>   trivial.
>
> - adjust the commands and names.
>
> In gnu/services/audio.scm you see the definition of mpd-service-type,
> which is a *system* service that 1) adds a user account, 2) does some
> one-shot preparation work, and 3) registers the mpd-shepherd-service.
>
> mpd-shepherd-service is a procedure returning a shepherd service.  The
> service has a start and stop command.  Adjust this for your service.
>
> mpd-shepherd-service refers to its argument “config”, which is supposed
> to be a Scheme configuration value.  It’s just a record defined higher
> up as .  mpd-config->file turns that Scheme value
> into a string that can live in a file as the mpd configuration file.
>
> This is pretty much all there is to it.  Some services are simpler and
> don’t need any one-shot setup, nor do they need system user accounts, so
> they would just boil down to a shepherd service definition.
>
> --
> Ricardo
>

Re: Teams

[Blake Shaw]

I think I could join the Home team as well, at least for now, as I started
using it a month ago and have been having a blast. I also have some
home-services to upstream after a bit of polish (Guile EDSL for
Herbstluftwm configuration if anyone is interested), and some plans to work
on the documentation.

I found the documentation to be a bit confusing (understandably, as its
new), but once the workflow snapped together its been amazing to see how
easy it is to create new services. And I now I have my entire desktop
environment contained in a single text file! Being able to ftp a text file
to a fresh Debian linode and get to work with all my tools ready within 10
minutes has been magic.

It also demonstrates a lot of Guile's strengths in one place: you can
easily wrap interfaces in Guile, and the expressive power it adds (at least
in the case of a window manager) is immediately evident.

Very excited about it, great work :)

On Tue, Jun 14, 2022, 18:31 Andrew Tropin  wrote:

> On 2022-06-05 10:19, Josselin Poiret wrote:
>
> > Hello everyone,
> >
> > Ricardo Wurmus  writes:
> >
> >> As a first step I’d suggest collecting teams, setting up the email
> >> aliases, and updating the website to show the existing teams.
> >
> > I think an installer team would be good too (which I would gladly join).
> > WDYT of the following teams:
> > * Installer (which I'd gladly join);
> > * System;
> > * Home;
> > * Internals?
> >
> > Maybe that would add too many teams, but I think the first three could
> > be pretty useful.
> >
> > How do we automatically make Mumi understand which team a patch should
> > notify?  I've just started using public-inbox/lei and the `dfn:` search
> > term is pretty useful, it lets you select only patches that change
> > specific files.  For example, `dfn:gnu/installer*` would match all
> > patches that touch the installer.
> >
> > Best,
>
> I'm not in a guix-maintainers yet, but I would like to join Home team.
>
> --
> Best regards,
> Andrew Tropin
>

Re: Teams

[Blake Shaw]

Hi folks,

I'm just getting back to the list after finishing a gig, but want to raise
my hand to join both the scheme team and perhaps something like an A/V team
if folks think that would be a desirable team to put together. I think an
A/V team would look after:

#+begin_example scheme
 (gnu packages gstreamer)
 (gnu packages gl) ;; Maybe games could handle this?
 (gnu packages video)
 (gnu packages graphics)
 (gnu packages music)
#+end_example

Which is quite a lot! So maybe some of this should be split up with the
"games" team.

On another note, I'll be getting back to the Guile Docs soon, and before
that I plan on taking a stab at refactoring the patch submission criteria,
which I think could use some work. As it is currently, it personally
becomes a hurdle of a checklist when I want to quickly submit a patch,
which has lead me to running a hotfix branch so that I can quickly fix an
issue and move on, therefore contributing what I should be. I think it
could express all the same requirements in less rules, making it easier to
ensure what you're handing in is in order. But I still need to take a stab
at it and see.

Best,

On Fri, Jun 10, 2022, 03:29 Arun Isaac  wrote:

>
> Hi Guix,
>
> I like the idea of teams. And, it's nice to see so many volunteers raise
> their hands!
>
> > * Rust team
> > Efraim Flashner
> > Aleksandr Vityazev
> > Arun Isaac
> > John Soo
> > Maxim Cournoyer
> > Nicolas Goaziou
> > Tobias Geerinckx-Rice
>
> However, I know very little about Rust, and I'm not a good fit for this
> team. I could easily be a part of the python, emacs lisp, common lisp,
> scheme teams, etc if necessary.
>
> But, what I'd really like is to be part of a mumi+tooling team. Maybe we
> should have such a team?
>
> Also, since we have so many ideas for teams, can we have some structured
> way to suggest teams, and add or remove them as needs change?
>
> Regards,
> Arun
>
>

Re: Cuirass and SQL

[Blake Shaw]

For any cuirass-curious readers, I want to say I deployed it on Linode a
week ago and its been one of the most "just works" out-of-the-box tools in
the guix arsenal that I've encountered. It was really easy and painless to
get going, and makes "pinning" milestone system & profile generations a
breeze so that you always have substitutes available for them. This has
sped up my guix workflow tremendously, as I'm able to just commit push,
branch off, try other ideas, push, review past results and keep moving,
instead of getting distracted by checking the news or what have you.

 The remote-server sometimes stops allocating builds to workers though, but
I just restart the server and its fine.

Feels like proper boutique gear, too ;)

On Fri, May 27, 2022, 16:41 zimoun  wrote:

> Hi,
>
> On jeu., 26 mai 2022 at 00:24, Arun Isaac 
> wrote:
>
> >> Quick question about guix-forge.  Why laminar instead of cuirass as
> >> the CI?
> >
> > Two reasons:
> >
> > - Cuirass requires a PostgreSQL database, but I wanted guix-forge to be
> >   as stateless as possible and definitely not require a complex database
> >   server like PostgreSQL. Laminar just uses sqlite.
>
> Initially, Cuirass was using SQLite but then switched [1] to
> PostgreSQL.  The main reason is scalability.
>
> I do not know if it is a technically doable to have two SQL backends and
> let the user pick the one they prefer.  For sure, it is not doable from
> a maintenance point of view.
>
> About the complexity of PostgreSQL, I think the Guix services [2,3] help
> here.
>
>
>
> 1: <
> http://git.savannah.gnu.org/cgit/guix/guix-cuirass.git/commit/?id=cbc462679d2647ecc897231cc78781a90fa2441a
> >
> 2: <
> https://guix.gnu.org/en/manual/devel/en/guix.html#Continuous-Integration>
> 3: 
>
>
> Cheers,
> simon
>
>

Re: Arun Isaac Presentation on guix-forge this Saturday

[Blake Shaw]

Wow this is incredible, can't wait to hear about it!

On Wed, May 25, 2022, 13:50 Pjotr Prins  wrote:

> Guix-forge aims to replace github and gitlab. I don't know how much
> Arun will show, but I would like to note that under their guidance we
> have replaced the github issue trackers, kanban boards, and CI for the
> genenetwork project.
>
> https://ci.genenetwork.org/
>
> https://issues.genenetwork.org/
>
> In all it is *much* nicer to work with.
>
> We still have github as a backend for most git repos, but the main
> thing is that we are not delivered to github functionality and may
> move off to gitea or cgit any time:
>
> https://git.genenetwork.org/
>
> Important stuff!
>
> Pj.
>
> On Tue, May 24, 2022 at 06:26:56PM -0500, jgart wrote:
> > hi guixers!
> >
> > I'd like to invite you this Saturday to a presentation on guix-forge by
> Arun Isaac:
> >
> > https://guix-forge.systemreboot.net/
> >
> > guix-forge empowers users to bring their own forge (BYOF). It's a much
> > needed project with an design focus on statelessness and minimalism.
> >
> > Arun will be presenting on guix-forge this Saturday at 16:00 UTC.
> >
> > Here's the room invite link:
> >
> > https://meet.nixnet.services/b/jga-nze-hgu-1qg
> >
> > hope to see ya there,
> >
> > jgart
> >
> > https://whereis.みんな/ 
> > https://litterbox.whereis.みんな/ 
> >
> >
>
>

A corner case of broken reproducibility

[Blake Shaw]

Hiya Guix,

I imagine many folks are aware of this outcome, but from a quick search of
the archive I didnt find a discussion.

I decided to create a new user for building the lighter profile to deploy
in Singapore. Not knowing beyond the surface of how user profiles operate
at the Linux level, I changed my user name in my config without adding a
new user, thinking that only building a system with one profile will be
faster (with the servers having problems I'm having to fallback quite a
bit, so every bit of time saved helps)

But when I run $guix system roll-back, the account is broken. If I set the
password again as root and then try to log back in, it crashes during
loggin and in returned to the login menu. If I try to login with $sudo su
blake2b, I get the error: Permission denied: /home/blake2b/.bashrc. if I
remove  bashrc and then try to continue, the error happens again. And its
the same if I reconfigure with the new user.

So it seems this is a corner case of somewhat severe non-reproducibity (you
can't even access the environment). I'm guessing it has something to do
with setuid, perhaps the access rights are given to a strictly different
user even if the name is the same.

Is there any fix to this?

Ez,
Blake

Re: Test US mirror for bordeaux.guix.gnu.org and slow downloading of substitutes

[Blake Shaw]

Hi Christopher,

So its strange, I do:

wget 
https://bordeaux.guix.gnu.org/nar/lzip/078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0
--2022-05-25 05:32:12--
https://bordeaux.guix.gnu.org/nar/lzip/078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0
Resolving bordeaux.guix.gnu.org (bordeaux.guix.gnu.org)...
185.233.100.56, 2a0c:e300::58
Connecting to bordeaux.guix.gnu.org
(bordeaux.guix.gnu.org)|185.233.100.56|:443... connected.

...and then it just remains stalled there. wget appears to work fine
in generat though, just not with guix.

Any idea why this might be happening? Could bordeaux be blocking IPs
in Singapore?

Best,
Blake

---
Blake Shaw
Director, SWEATSHOPPE
sweatshoppe.org
---

On Tue, May 24, 2022 at 5:52 AM Blake Shaw  wrote:
>
> Hi Christopher,
>
> Here in Singapore download speed has gone from bad to worse over the
> last two weeks, so bad that I was having to --fallback often and wound
> up setting up a cuirass instance to continuously build a collection of
> manifests I'm working with (which solved the issue). Not at my machine
> atm but will wget stellarium and send the results when I am.
>
> Best,
> Blake
>
> ---
> Blake Shaw
> Director, SWEATSHOPPE
> sweatshoppe.org
> ---
>
> On Fri, May 20, 2022 at 11:09 PM Christopher Baines  wrote:
> >
> > Hey!
> >
> > So the nar-herder came in to existence at the end of last year (2021)
> > and while the main use at the time was addressing the lack of storage on
> > bayfront, I also hoped to improve the situation regarding mirrors for
> > substitutes.
> >
> > I'm not in a great situation to test this though, as my usual internet
> > connection is slow enough that a closer mirror probably won't make much
> > difference.
> >
> > So, one thing that I'd be interested in, is hearing from anyone who
> > thinks they get worse download performance from bordeaux.guix.gnu.org or
> > ci.guix.gnu.org than they get when downloading other
> > things. Importantly, it would be good to know roughly where
> > (geographically) the machine doing the downloading is, and some data to
> > show the difference.
> >
> > For example, I'm in the United Kingdom in Europe, and this is the output
> > from wget downloading a ~200M file from bordeaux.guix.gnu.org:
> >
> >   → wget 
> > https://bordeaux.guix.gnu.org/nar/lzip/078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0
> >   --2022-05-20 16:49:56--  
> > https://bordeaux.guix.gnu.org/nar/lzip/078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0
> >   Resolving bordeaux.guix.gnu.org (bordeaux.guix.gnu.org)... 2a0c:e300::58, 
> > 185.233.100.56
> >   Connecting to bordeaux.guix.gnu.org 
> > (bordeaux.guix.gnu.org)|2a0c:e300::58|:443... connected.
> >   HTTP request sent, awaiting response... 200 OK
> >   Length: 208615205 (199M) [text/plain]
> >   Saving to: ‘078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0.6’
> >
> >   078vr3r8mn3yrwzwxw64 100%[==>] 198.95M  4.24MB/s
> > in 46s
> >
> >   2022-05-20 16:50:43 (4.31 MB/s) - 
> > ‘078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0.6’ saved 
> > [208615205/208615205]
> >
> >
> > Also, I've setup a US based (Hetzner data center, east coast) mirror of
> > bordeaux.guix.gnu.org:
> >
> >   https://bordeaux-us-east-mirror.cbaines.net/
> >
> > So, I'd also be interested in seeing how that performs for people, and
> > how it compares against bordeaux.guix.gnu.org, which is hosted in France
> > in Europe.
> >
> > Here's my output from wget:
> >
> >   → wget 
> > https://bordeaux-us-east-mirror.cbaines.net/nar/lzip/078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0
> >   --2022-05-20 16:50:44--  
> > https://bordeaux-us-east-mirror.cbaines.net/nar/lzip/078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0
> >   Resolving bordeaux-us-east-mirror.cbaines.net 
> > (bordeaux-us-east-mirror.cbaines.net)... 5.161.49.48
> >   Connecting to bordeaux-us-east-mirror.cbaines.net 
> > (bordeaux-us-east-mirror.cbaines.net)|5.161.49.48|:443... connected.
> >   HTTP request sent, awaiting response... 200 OK
> >   Length: 208615205 (199M) [text/plain]
> >   Saving to: ‘078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0.7’
> >
> >   078vr3r8mn3yrwzwxw64 100%[==>] 198.95M  4.17MB/s
> > in 47s
> >
> >   2022-05-20 16:51:32 (4.22 MB/s) - 
> > ‘078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0.7’ saved 
> > [208615205/208615205]
> >
> >
> > Now, performance is probably a bit more complicated than just download
> > speed. The US mirror holds the narinfo information locally, which should
> > enable it to respond to requests more quickly, reducing latency, but
> > this is a little harder to test.
> >
> > Thanks,
> >
> > Chris

Re: Test US mirror for bordeaux.guix.gnu.org and slow downloading of substitutes

[Blake Shaw]

Hi Christopher,

Here in Singapore download speed has gone from bad to worse over the
last two weeks, so bad that I was having to --fallback often and wound
up setting up a cuirass instance to continuously build a collection of
manifests I'm working with (which solved the issue). Not at my machine
atm but will wget stellarium and send the results when I am.

Best,
Blake

---
Blake Shaw
Director, SWEATSHOPPE
sweatshoppe.org
---

On Fri, May 20, 2022 at 11:09 PM Christopher Baines  wrote:
>
> Hey!
>
> So the nar-herder came in to existence at the end of last year (2021)
> and while the main use at the time was addressing the lack of storage on
> bayfront, I also hoped to improve the situation regarding mirrors for
> substitutes.
>
> I'm not in a great situation to test this though, as my usual internet
> connection is slow enough that a closer mirror probably won't make much
> difference.
>
> So, one thing that I'd be interested in, is hearing from anyone who
> thinks they get worse download performance from bordeaux.guix.gnu.org or
> ci.guix.gnu.org than they get when downloading other
> things. Importantly, it would be good to know roughly where
> (geographically) the machine doing the downloading is, and some data to
> show the difference.
>
> For example, I'm in the United Kingdom in Europe, and this is the output
> from wget downloading a ~200M file from bordeaux.guix.gnu.org:
>
>   → wget 
> https://bordeaux.guix.gnu.org/nar/lzip/078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0
>   --2022-05-20 16:49:56--  
> https://bordeaux.guix.gnu.org/nar/lzip/078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0
>   Resolving bordeaux.guix.gnu.org (bordeaux.guix.gnu.org)... 2a0c:e300::58, 
> 185.233.100.56
>   Connecting to bordeaux.guix.gnu.org 
> (bordeaux.guix.gnu.org)|2a0c:e300::58|:443... connected.
>   HTTP request sent, awaiting response... 200 OK
>   Length: 208615205 (199M) [text/plain]
>   Saving to: ‘078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0.6’
>
>   078vr3r8mn3yrwzwxw64 100%[==>] 198.95M  4.24MB/sin 
> 46s
>
>   2022-05-20 16:50:43 (4.31 MB/s) - 
> ‘078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0.6’ saved 
> [208615205/208615205]
>
>
> Also, I've setup a US based (Hetzner data center, east coast) mirror of
> bordeaux.guix.gnu.org:
>
>   https://bordeaux-us-east-mirror.cbaines.net/
>
> So, I'd also be interested in seeing how that performs for people, and
> how it compares against bordeaux.guix.gnu.org, which is hosted in France
> in Europe.
>
> Here's my output from wget:
>
>   → wget 
> https://bordeaux-us-east-mirror.cbaines.net/nar/lzip/078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0
>   --2022-05-20 16:50:44--  
> https://bordeaux-us-east-mirror.cbaines.net/nar/lzip/078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0
>   Resolving bordeaux-us-east-mirror.cbaines.net 
> (bordeaux-us-east-mirror.cbaines.net)... 5.161.49.48
>   Connecting to bordeaux-us-east-mirror.cbaines.net 
> (bordeaux-us-east-mirror.cbaines.net)|5.161.49.48|:443... connected.
>   HTTP request sent, awaiting response... 200 OK
>   Length: 208615205 (199M) [text/plain]
>   Saving to: ‘078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0.7’
>
>   078vr3r8mn3yrwzwxw64 100%[==>] 198.95M  4.17MB/sin 
> 47s
>
>   2022-05-20 16:51:32 (4.22 MB/s) - 
> ‘078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0.7’ saved 
> [208615205/208615205]
>
>
> Now, performance is probably a bit more complicated than just download
> speed. The US mirror holds the narinfo information locally, which should
> enable it to respond to requests more quickly, reducing latency, but
> this is a little harder to test.
>
> Thanks,
>
> Chris

Re: Windows Subsystem for Linux

[Blake Shaw]

Hi,
Ludovic Courtès  writes:

> Hi,
>
> zimoun  skribis:
>
>> About FSDG, the arguments are exactly the same as GNU Emacs on
>> Windows. :-) No?  I mean, GNU Emacs provides a full port on Windows and
>> such port is available on the same side as other platforms on their
>> website [1].  The rationale [2]:
>>
>> The purpose of the GNU system is to give users the freedom that
>> proprietary software takes away from its users. Proprietary
>> operating systems (like other proprietary programs) are an
>> injustice, and we aim for a world in which they do not exist.
>>
>> To improve the use of proprietary systems is a misguided
>> goal. Our aim, rather, is to eliminate them. We include support
>> for some proprietary systems in GNU Emacs in the hope that
>> running Emacs on them will give users a taste of freedom and
>> thus lead them to free themselves.
>>
>> would also make sense for GNU Guix, no?
>
> Just like the Emacs manual has an appendix on Windows support, I think
> the cookbook could have a section on setting up Guix on WSL2.
>
> Cc’ing maintainers for their thoughts!
>
> Thanks,
> Ludo’.
>

I just had a client inquire about deploying to WSL2, so it's great news
to hear that this is working!

Hopefully it will mean that as the Guix tentacles extend, the
obsolescence, redundance, inconvenience & expense of proprietary
"middleware" like Windows will become clear to users.

May Guix/Guile march forward on the path of ubiquitous extensionality! 

ez,
b

-- 
“In girum imus nocte et consumimur igni”

Re: Creating subtitles for the Guix Days videos!

[Blake Shaw]

Hi Matt,
Matt  writes:

>   On Tue, 01 Mar 2022 22:44:18 -0500 Matt  wrote 
>  > 
>  >   On Tue, 01 Mar 2022 18:18:42 -0500 Matt  wrote 
> 
>  > 
>  >  > I've started working on the "Dreaming of better patch review".  This is 
> great steno practice!
>
> I'm (finally) done!
>
> There were some things he said that I couldn't understand. I notated
> all of them using square brackets and three question marks, [like
> this???]. You should be able to search on "???" to find them.
>
> It was an interesting talk with good points and some smart ideas.  I'm happy 
> to have been able to make it more accessible to others.  :)
>
>
Thank you so much! Thats awesome work. I'll take a look at the parts
that were difficult... but I'm not sure what software I need to use this
file format. Lmk and I'll get you the corrections.

ez,
b
-- 
“In girum imus nocte et consumimur igni”

Re: Update CoC adapted from upstream 2.1 (instead of 1.4)

[Blake Shaw]

Taylan Kammer  writes:


> The inclusion of 'sex' in the CoC would be to recognize the issues
> faced by female-born people.  As far as I'm aware, no female-born
> person has taken part in the discussion at all, because none seem
> to exist in the community.  (What a coincidence.)

Actually there are cis women in the community. There voices have
just been absent since this discourse began (what a coincidence)

but really, can finally lay this to rest???


-- 
“In girum imus nocte et consumimur igni”

Re: Update CoC adapted from upstream 2.1 (instead of 1.4)

[Blake Shaw]

zimoun  writes:

My position remains unchanged: our codes of conduct should do everything
possible to be as inclusive as and open to peoples of marginalized
groups that are discriminated against. White cis men shouldn't be in
charge of deciding whats best for these people. 

As far as I can see, not a single woman has come forward to say that
proposed CoC amendments would benefit or protect them in any way. In
fact the opposite is the case: two have come forward to say that this
appears as ploy by men to debate their gender and experience.

Why are white men so insistent on making changes that would supposedly
increase inclusivity, despite those from marginalized backgrounds saying
the opposite is the case here?

Until a fem contributor comes forward to say that they feel changes
to the current CoC would bring about some tangible protection to them,
it seems to me that this discourse is a case of the dominant white cis
males making changes to "protect women" without the consent of women,
which has never fared well in history.

So with that said, I think decisions concerning women should be left to
women (all women!) to decide.

ez,
b

-- 
“In girum imus nocte et consumimur igni”

Re: [minor patch] Amend CoC

[Blake Shaw]

Oliver Propst  writes:

> On 2022-02-23 10:48, Andy Wingo wrote:
>> On Tue 22 Feb 2022 18:16, Taylan Kammer 
>> writes:
>> 
>>> If anyone's annoyed by this thread, please tell, and let us move it
>>> off-list.
>> I am annoyed by it I think it should be off-list :)
> Me to :)

Me as well, and I would add that at this point, now that two women who
are active in this community have come forward with reasonable requests
to not accept the patch and politely asked us to "get back to hacking",
yet the committer has persisted, the following two CoC seem to be in breech:

  * Trolling, insulting/derogatory comments, and personal or political attacks
  * Public or private harassment

If you're part of a discriminated minority and express unease with the
way folks from the dominant group are discussing your identity, yet they
persist, I think that qualifies as harassment.

With that being said, let's keep the following guideline in mind:

 * Showing empathy towards other community members

and get back to hacking :)

-- 
“In girum imus nocte et consumimur igni”

Re: [minor patch] Amend CoC

[Blake Shaw]

Liliana Marie Prikler  writes:

>> To me, this seems a rather contrived scenario though ...
> In this "contrived" scenario Harold would still (intentionally or
> otherwise) be discriminating Victor·ia over their gender by publicly
> pointing out the disconnect between the two.  In the daily experience
> of trans people, such remarks typically serve to invalidate their
> identities.
>

I agree, and given that so-called "men's rights activist" types have
time and time again used this type of argumentation to veil attacks on
trans women under the guise of feminism, it should be rejected. people's
sexual identities are already addressed as protected, and this is meant to
protect all women, not only some of them.

also I think when a man suggests making a changing to conduct regarding
women, and a woman says "hold up thats not protecting me", and no other
women come forward to defend the proposal, it should be obvious that
the "debate" need not move forward. 

-- 
“In girum imus nocte et consumimur igni”

Re: Organising Guix Days

[Blake Shaw]

Hi folks,

Regarding the presentation I'm putting together on the Guile
Documentation, while I have enough material right now to send out a
basic presentation that covers what I believe to be the dominant,
glaring issues of the composition and organization of the docs as well
as how I would go about restructuring them if everyone agrees with the
proposed edits, I'm also starting to uncover some more nuanced
issues with some of the pedagogical folly that appears throughout the
text, and so a few more weeks would probably result in a more
comprehensive study.

So I was thinking, in that case, should I just make the presentation for
Guix Days? That way it could also be presented at a time when other,
perhaps related projects and issues are coming to the fore.

-- 
“In girum imus nocte et consumimur igni”

Re: guix system reconfigure after more than a year

[Blake Shaw]

right on, i've had similar experiences where what was before dreaded
eases into comfortable relief. great work everyone!
-- 
“In girum imus nocte et consumimur igni”

Re: Formalizing teams

[Blake Shaw]

Ludovic Courtès  writes:

> One idea that I like is to bring structure to the group, or rather to
> make structure visible, so that newcomers know who they can talk to to
> get started on a topic, know who to ping for reviews, and so that each
> one of us can see where they fit.  Rust has well-defined teams:
>
>   https://www.rust-lang.org/governance
>
Definitely! Perhaps this an aesthetic matter, but keeping-with the
community spirit of Guix, and the existing nomenclature where the
'core' maintainers are called a "collective", perhaps we should avoid
some of the more corporate "team" language of Rust/Mozilla and stick to
"collectives"?
> In Rust, teams are responsible for overseeing discussions and changes in
> their area, but also ultimately for making decisions.  I think that’s
> pretty much the case with the informal teams that exist today in Guix,
> but that responsibility could be made more explicit here.  They
> distinguish teams from “working groups”, where working groups work on
> actually implementing what the team decided.
>
> How about starting with a web page listing these teams, their work,
> their members, and ways to contact them?  Teams would be the primary
> contact point and for things that fall into their area and would be
> responsible for channeling proposals and advancing issues in their area.
>
> What do people think?

I think it sounds great. The question remains what is the medium-space
where through which the teams interact? How do we prevent teams from
becoming silo'd off from one another? Do we have an "assembly" or an
"assembler"?

Should this become a matter for Guix Days?

-- 
“In girum imus nocte et consumimur igni”

Re: Guile documentation

[Blake Shaw]

Hi Ludo,

(replying to this email from my other email address because I can't seem to
find it in gnus, which I only recently switched to)

For sure. I'm preparing a little document that provides an analysis of pain
points in the docs, which I'll hopefully have done by the end of this week
and can send to the group. I'll be mostly focused on the general
organizational structure of the docs and will offer solutions that if
everyone agrees to I'll go ahead and start putting to work.

Ez,
Blake

On Tue, Dec 21, 2021, 01:57 Ludovic Courtès  wrote:

> Hi Blake,
>
> Blake Shaw  skribis:
>
> > While I've come to love Guile, compared to my experience with Racket its
> > been quite burdensome for me to get in the hang of, something I attribute
> > primarily to the structure of the docs, and not due to it being in any
> > way more difficult than Racket. While with Racket I was writing
> > useful programs in the standard #lang within my first week, with Guile
> > I often find that what should be almost trivial winds up with a lot of
> > time lost just trying to navigate and understand the docs. When I do
> > figure things out, it turns out to be no more difficult than the
> equivalent
> > in Racket, but a lack of consistency in the path that leads there in the
> > docs cause hangups, which has made trivial scripts that should take an
> hour
> > become weekend projects.
>
> IWBN if we could take advantage of your fresh eye to restructure the
> Guile manual in a way that makes it more convenient.
>
> Guile has changed a lot since the manual was initially written, a lot of
> sections were added, some removed, but we probably didn’t take the time
> to sit down and see how to restructure it accordingly.
>
> So if you have a specific structure in mind, or if you remember
> precisely what was hard to find and located in a unexpected section,
> please let’s take advantage of that!
>
> Thanks,
> Ludo’.
>
>

Re: Solstice infrastructure hackathon

[Blake Shaw]

This sounds great! I'm in, marking it off in my calendar :)
-- 
“In girum imus nocte et consumimur igni”

Re: Guix Documentation Meetup

[Blake Shaw]

Blake Shaw  writes:

Simon, just peeped your monad tutorial, and gotta say its one of the
clearest presentations of the subject I've seen. Great work!

>> I agree.  For what it is worth, I tried once to quickly explain monad,
>> with the aim of “Store Monad“ in mind,
>>
>> https://guix.gnu.org/manual/devel/en/guix.html#The-Store-Monad
>>
>> After several discussions with strong Guix hackers, it appears to me
>> that they missed the general concept of monad, at least it was vague.
>> Therefore, I tried to write a simple explanation,
>>
>> https://simon.tournier.info/posts/2021-02-03-monad.html
>
-- 
“In girum imus nocte et consumimur igni”

Re: Guix Documentation Meetup

[Blake Shaw]

Katherine Cox-Buday  writes:

Katherine, reading a big deeper into your user experience report,
its really so so helpful to have this concrete sort of step-by-step
user experience report. Would you mind if I solicit the list
for more reports like this for anyone who might feel like offering them?
And would you mind if I cite this in the presentation I'm gathering?

-- 
“In girum imus nocte et consumimur igni”

Re: Guix Documentation Meetup

[Blake Shaw]

Katherine Cox-Buday  writes:

Katherine this is great material to chew on, much of which I can relate
to!  

-- 
“In girum imus nocte et consumimur igni”

Re: Guix Documentation Meetup

[Blake Shaw]

zimoun  writes:

Hi Simon, thanks for the input,
> Hi,
>
> On Sat, 11 Dec 2021 at 05:40, Blake Shaw 
> wrote:
>
>> --
>> tldr: is there also room to discuss contributing -- and possibly
>> doing a
>> sizeable makeover to -- the *Guile* documentation? If so, I could
>> give a
>> short 5 - 10 minutes presentation of what I think should be done (and
>> would volunteer to do).
>> --
>
> Cool!
>
> Minor comments trying to feed this worth proposal.
>
>> I don't know if this is the correct forum for it, but I personally
>> think
>> the biggest documentation obstacle in Guix at the moment isn't so much
>> in Guix, but instead in Guile. I found Guix via SICP & Racket about a
>> year ago, and I remained a happy Racket hacker until a couple months
>> ago
>> when I decided to devote my free time to learning Guile in hopes of
>> graduating to a Guix sensei one day.
>
> I agree that the learning path in Guile land is not always smooth.
> However, I do not think mastering Guile and/or its specificity is a
> requirement to be a “Guix sensei”.  Obviously, better Guile
> documentation improves the ecosystem, then it is an overall better. :-)

I mostly agree, and I used Guix for probably half a year before recently
deciding to dive into Guile seriously. But I still won't be able to,
say, write a `guix import` for a different package manager without
needing to spend ample time consulting the docs, bumping up against
confusions, etc. I want to get to the point that I'm able to take
on such matters with confidence, and so learning Guile seems important.   

>
>> While I've come to love Guile, compared to my experience with Racket
>> its
>> been quite burdensome for me to get in the hang of, something I
>> attribute
>> primarily to the structure of the docs, and not due to it being in any
>> way more difficult than Racket. While with Racket I was writing
>> useful programs in the standard #lang within my first week, with Guile
>> I often find that what should be almost trivial winds up with a lot of
>> time lost just trying to navigate and understand the docs. When I do
>> figure things out, it turns out to be no more difficult than the
>> equivalent
>> in Racket, but a lack of consistency in the path that leads there in
>> the
>> docs cause hangups, which has made trivial scripts that should take
>> an hour
>> become weekend projects.
>
> Well, I am not convinced it is because the structure of the docs.
> Instead, I think it is because it is missing docs. :-)
>
> If we compare apple to apple, here are the entry points:
>
> https://docs.racket-lang.org/
> https://www.gnu.org/software/guile/learn/
>
> and so the Guile manual
>
> https://www.gnu.org/software/guile/manual/guile.html
>
> is a reference manual, which correspond to, mainly
>
> https://docs.racket-lang.org/reference/
>
> and also,
>
> https://docs.racket-lang.org/guide/
>

I'm covering all this in a presentation I'll be putting together over
the coming weeks, including some visualization of the structure that I
think is helpful. I'd argue that `Hello Guix`, `Hello Scheme`,
`Programming in Scheme` and `Programming in C` serve a similar function
to `Quick`, `Continue` and `More` in the Racket docs.

> I am not convinced you started Racket by these ones. ;-)
>

I started with the Racket Guide! or really, with SICP and `#lang
sicp`, doing little bits of the Racket Guide along the way and that got
me interested in racket more generally.

But probably more importantly, I think like many programmers I
started writing little projects in Racket and read the docs along the
way. And thats where my analysis focuses: the documents should, and can,
be easier to navigate, allowing one to get in-and-out as needed, but
currently there are many related functions buried in disparate areas
usually without examples. Why FTW and POSIX in disparate parts of the
manual, things its obviously desirable to use in tandem? Why are there
multiple ways to do IO without a disclaimer as to which is prefered? If
there are 30 documented SRFIs, and most have only 1 or two sentences
written for most, but some contain a treasure trove of knowledge, many 
people will move on after linking into one or two SRFI entries and
forgoe the rest, and won't realize there are tranducers in guile.

All of this adds up to a fair amount of overhead imo, and I'm planning
to put together a report covering a structural analysis of it before the
end of the month.

> Indeed, one document on the Guile side vs two documents on Racket side;
> the Guile manual could be split, I do not know if the core issue here.
> Instead, IMHO, what is missing are all the others. :-) For instance,
>
>

Re: Guix Documentation Meetup

[Blake Shaw]

Ryan Prior  writes:

> Absolutely. The Guile docs are unusable and make Guile a pain to work
> with. I say this as an experienced lisp & scheme user with decades of
> experience now in elisp, racket, and clojure. 

oh good, I'm glad to hear that I'm not alone! to be honest I don't think
its *so* bad, but it certainly demands a the user of suffers a bit, which
makes Guix in general a more difficult sell. And Guile is a truly
impressive programming language; its docs are just in need of some
remodeling I think. 

> I've found the Guile IRC channel to be polite and encouraging, but
> also very self-satisfied, which makes it hard to feel heard as a Guile
> hacker who's struggling. I hesitate to tackle any kind of nontrivial

I first checked it out when I began learning about guix, and it
seemed quite friendly. but unfortunately since I started studying Guile
I haven't had any of my questions there responded to. hopefully all is
ok. 

> problem with Guile because I have no confidence I will find tools that
> save me time; I'm proficient with a half dozen other languages,
> including multiple lisps, which provide much better support. So even
> though I really want to learn Guile,because of Guix, Shepherd and
> other cool software written in it, I'm no more likely to choose Guile
> for a software project today than I was 3 years ago when I just
> started learning it.

As long as it doesn't stall out into bikeshedding and the community is
supportive I'm dedicated to this project of working on Guile's docs
while I become acquainted with its depths. As a media artist theres
really a lot it offers. But like you say, it can suck up time with little
return; trying to figure out certain basic things in Guile has made C
feel like Python at times. Luckily, the C interface is decently
documented.

>
> When I talk to experienced hackers in the Guile community I get the
> sense they've just accepted that yeah, the only way to get anywhere is
> to cold memorize the most popular ~80 SRFIs or implement everything
> you need yourself. One person I talked to was like "oh yeah Guile's
> great, you just have to implement your own standard library like I
> did."

I'd be interested to hear any anecdotes regarding whether restructuring
the docs was attempted in the past, and what problems it incurred.
Considering my background in academia, writing is second nature, and
this has been the only thing in Guix that has appeared to me as a
serious pain point, so if I'm the only one who doesn't find writing docs
insufferable, I'm happy to take on that task for the time being.

But again, it depends on whether the community will grant me their
confidence. 

> I'd love to hear your talk, if you're up to present at the Guix meetup
> I'll definitely come and listen. I'm also happy to do what I can to
> help drive Guile adoption, create a great learning experience around
> it, and finally start to build the language community that Guile is
> lacking.

Awesome! Me too! It's seriously an incredible language -- it's just lacking
a consistent, ergonomic presentation atm. But even without that, it's
the fastest-booting lisp I've tried, and already thats enough to keep me
from crawling back to Racket (which might boot fast now with CS, but I
haven't checked in lately)

As it currently stands, its better to ditch the docs and just browse
the code base. And while for some that might be like reading email,
for the vast majority thats demanding some serious overhead from users
who are likely to pick up Guile for their personal, off-hours, creative
work.

It won't be a talk, just a 5-10min presentation of some notes where I'll
try to provide a light analysis of a few problems, along with how I
would go about fixing them, and then if all agree I'll get to work on
it.

Thanks for the encouragement!

ez,
b
-- 
“In girum imus nocte et consumimur igni”

Re: Guix Documentation Meetup

[Blake Shaw]

hiya guix,

@cybersyn from IRC here, I recently contributed my first package, [notcurses]

--
tldr: is there also room to discuss contributing -- and possibly doing a
sizeable makeover to -- the *Guile* documentation? If so, I could give a
short 5 - 10 minutes presentation of what I think should be done (and
would volunteer to do).
--

I think I can personally offer a lot in terms of contributing to
documentation. While I don't serious experience w/technical writing,
prior to the pandemic I was doing my PhD in philosophy of mathematics,
so I come from a cross-disciplinary background that involves the often
difficult area of communicating new, formal ideas to previously
unexposed readers. I've also made a living as a new media artist since
2009, working mostly in C and C++ based frameworks, so I also have some
knowledge of the difficulties "crafters" have when learning new
development systems.

I don't know if this is the correct forum for it, but I personally think
the biggest documentation obstacle in Guix at the moment isn't so much
in Guix, but instead in Guile. I found Guix via SICP & Racket about a
year ago, and I remained a happy Racket hacker until a couple months ago
when I decided to devote my free time to learning Guile in hopes of
graduating to a Guix sensei one day.

While I've come to love Guile, compared to my experience with Racket its
been quite burdensome for me to get in the hang of, something I attribute
primarily to the structure of the docs, and not due to it being in any
way more difficult than Racket. While with Racket I was writing
useful programs in the standard #lang within my first week, with Guile
I often find that what should be almost trivial winds up with a lot of
time lost just trying to navigate and understand the docs. When I do
figure things out, it turns out to be no more difficult than the equivalent
in Racket, but a lack of consistency in the path that leads there in the
docs cause hangups, which has made trivial scripts that should take an hour
become weekend projects.

I know this isn't the Guile list, but when I've written on this topic in
the IRC I've had no response, which make me think docs could be a
bit of a bikeshedding topic in the community. But as Guile is
fundamental to Guix and theres a lot of crossover btwn the communities,
it seems like this could be a good time to raise these suggestions.

I've jotted down some notes on several concrete examples of where the docs
diverge from stylistic consistency, as well as some light analysis as to
why such seemingly small inconsistencies can lead to such hangups in the 
learning
process. If folks would be interested in me presenting a short 5-10min
presentation of these notes, I'd be happy to share.

Sorry for such a long-winded message! Personally, good documentation is
absolutely essential, and I feel like I could give Guile's docs a
serious makeover while I'm still at the early stage of my plunge and
have a perspective on the psychology of not-understanding -- something
that won't last long!

ez,
blake

-- 
“In girum imus nocte et consumimur igni”