Re: Lisp libraries: Other variants? (CCL, CLisp, etc.)

[Programmer]

>Have you looked at lisp-utils.scm?  I think it incorporates some of your ideas
>already.  It could perhaps be generalized following your ideas so that it works
>for all Lisps out of the box.
I've not.  I did a cursory search for this as well, but didn't find anything.  
Would you be so kind
as to link me to it so I can give a good idea of whether it's similar or not?

I was aiming for something specifically suited to Common Lisp, since many 
Schemes have their own way
of doing things, but if a general approach works best then that would be great. 
 It is important to
note, however, that I find it a very important quality that there be no need to 
load code into the
Common Lisp implementation for doing this, as that's inconvenient.  Ideally, 
the Common Lisp
implementation is just told what file to LOAD and everything else is handled 
nicely.

I'd also want to make my proposed method work across many different systems, 
ideally, with little
friction.

>Question: Are .fasl files compatible across Common Lisp implementations?  If
>not, then what's your suggestion?
FASLs aren't standardized in form, so even the same implementation across 
different versions may be
unable to use earlier or later FASLs.

My suggestion, if this becomes an issue, is to have FASLs deposited in a fasl 
subdirectory of the
Common Lisp directory with further subdirectories denoted by Lisp 
implementation name and it may be
a good idea to think ahead and also use the particular version in the 
subdirectory name.  This
provides a simple, perfectly portable, and rather foolproof way to get the 
proper behavior for this.

>By "system", do you mean a _build system_ or something else?
I meant something like ASDF, but more abstract and able to be compiled to 
representations including
ASDF and Guix declarations and whatnot, with the reasoning that ASDF is rather 
grotesquely large and
unwieldy, among other things.

>We want to install libraries in the store.  Why do you suggest we put it in the
>user's home?
You misunderstand.  The library would be in the store, but there would be a 
file placed in the
user's home directory, because Common Lisp has a USER-HOMEDIR-PATHNAME 
function, that would handle
loading dependencies and the actual library.

So, you'd LOAD the same file whether you're using Guix, Debian, etc. and so 
whether the actual
library is the store, /usr/lib/, or anywhere else, varying on how the system 
package manager does
it.

>Sorry, I don't understand how your proposal would eliminate the 
>POSIX-assumption
>issue.  Can you provide an example?
Sure I can.  It's been a while since I've tried this, but common Common Lisp 
tools to load code
don't actually know anything about the structure of the system, so under POSIX 
they simply check the
usual locations, instead.  This blows up miserably under Guix, since it does 
things differently.
With the idea of generating the code used to load things from a higher-level 
description, you can
adapt it to the particular system, rather than simply checking many directories 
like it's a
configure script or something.

Just let me know if anything else is still unclear.  I'd be very glad to help 
Guix have a pleasant
Common Lisp packaging method that works across systems.

Re: Missing code comments in guix source: 2 examples from gnu/services

[swedebugia]

On 2018-11-06 15:15, Ludovic Courtès wrote:

Hi,

Gábor Boskovits  skribis:


swedebugia  ezt írta (időpont: 2018. nov. 5., H, 9:33):

[...]


prometheus-node-exporter-shepherd-service is just as little documented in the 
same file. From the file I have no idea what this does as its only 
documentation is:

  (shepherd-service
   (documentation "Prometheus node exporter.")

---


Thanks for pointing this out, I will fix this in prometheus-node-exporter.
Can you point me to a service where the documentation is statisfactory?

Note that the ‘documentation’ field that you see above is what “herd doc
prometheus-node-exporter” shows.  It should be terse compared to the
‘documentation’ field of ‘service-type’.

Ok, thanks.

--
Cheers Swedebugia

Re: CLI reorganization revisited

[swedebugia]

On 2018-11-08 23:46, Amirouche Boubekki wrote:


I do not understand how args work. Is this documented somewhere?

Also I do not understand this form:

(define (guix-describe . args)
   ^
What is the role of the dot?



The dot serve as a separator between 'required' argument and 'rest' 
arguments which is always a list that might be empty.
In the above case everything passed to the procedure guix-describe is 
considered part of args.

Thank you!

I just saw that GNU Scheme implemented that as keyword: #optional!

This is more clear for the reader/beginner actually. ;-)

--
Cheers Swedebugia

Re: New detailed troubleshooting section in the manual

[alex sassmannshausen]

Hello,

On Thu, 8 Nov 2018, 20:54 Laura Lazzati  Hi Ludo
>
> Following these instructions should make the warnings go away,
>> doesn’t it?
>>
> No they don't. I installed the package, exported the path, added it to my
> .profile file but the message still appears.
> And if I check `env | sort`, even after rebooting or shutting down, the
> GUIX_LOCPATH is set.
> I also tried installing glibc-locales but the same happens.
>

I may have missed this earlier, but have you tried installing glibc-locales
in the root profile too?

I've found in the past that I needed the full glibc-locales, in root and
user profile. I also needed the path configuration in both. You may need to
restart the deamon after... I don't remember.

If I only did the user install, then the locpath warning message disappears
for the user side, but not for the deamon side.

Hope this is helpful!

Alex


> Regards!
> Laura
>
>

Re: CLI reorganization revisited

[Amirouche Boubekki]

>
> I do not understand how args work. Is this documented somewhere?
>
> Also I do not understand this form:
>
> (define (guix-describe . args)
>^
> What is the role of the dot?
>


The dot serve as a separator between 'required' argument and 'rest'
arguments which is always a list that might be empty.
In the above case everything passed to the procedure guix-describe is
considered part of args.

HTH

Re: CLI reorganization revisited

[swedebugia]

Hi :)


On 2018-11-06 15:24, Ludovic Courtès wrote:

Hello,

swedebugia  skribis:


I would like to go ahead preparing a patch for the aliases for ‘guix install’, 
‘guix remove’, and ‘guix upgrade’.

That would be sweet!


I gave it a go but did not get that far. :p

This patch errors out with:

$ ./pre-inst-env guix install
ice-9/boot-9.scm:3356:22: Syntax error:
/home/sdb/guix-tree/guix/scripts/install.scm:31:2: define-module: 
expected keyword arg in subform (guix-install) of (define-module (guix 
scripts install) #:use-module ((guix ui) #:hide 
(display-profile-content)) #:use-module (guix scripts) #:use-module 
(guix scripts package) (guix-install))


I do not understand how args work. Is this documented somewhere?

Also I do not understand this form:

(define (guix-describe . args)
  ^
What is the role of the dot?

I'm probably in way over my head here :D

Cheers
Swedebugia
>From 82a844c8c37b9a969e332ff19a87aa857881b039 Mon Sep 17 00:00:00 2001
From: swedebugia 
Date: Thu, 8 Nov 2018 22:57:49 +0100
Subject: [PATCH] WIP: 'Add guix install'.

---
 Makefile.am  |  2 ++
 guix/scripts/install.scm | 41 
 2 files changed, 43 insertions(+)
 create mode 100644 guix/scripts/install.scm

diff --git a/Makefile.am b/Makefile.am
index c63b65ba5..2dfbef006 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -12,6 +12,7 @@
 # Copyright © 2018 Nils Gillmann 
 # Copyright © 2018 Julien Lepiller 
 # Copyright © 2018 Oleg Pykhalov 
+# Copyright © 2018 swedebugia 
 #
 # This file is part of GNU Guix.
 #
@@ -196,6 +197,7 @@ MODULES =	\
   guix/scripts/build.scm			\
   guix/scripts/archive.scm			\
   guix/scripts/import.scm			\
+  guix/scripts/install.scm			\
   guix/scripts/package.scm			\
   guix/scripts/gc.scm\
   guix/scripts/hash.scm\
diff --git a/guix/scripts/install.scm b/guix/scripts/install.scm
new file mode 100644
index 0..ebfa819a7
--- /dev/null
+++ b/guix/scripts/install.scm
@@ -0,0 +1,41 @@
+
+;;; GNU Guix --- Functional package management for GNU
+;;; Copyright © 2018 swedebugia 
+
+;;;
+;;; This file is part of GNU Guix.
+;;;
+;;; GNU Guix is free software; you can redistribute it and/or modify it
+;;; under the terms of the GNU General Public License as published by
+;;; the Free Software Foundation; either version 3 of the License, or (at
+;;; your option) any later version.
+;;;
+;;; GNU Guix is distributed in the hope that it will be useful, but
+;;; WITHOUT ANY WARRANTY; without even the implied warranty of
+;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;;; GNU General Public License for more details.
+;;;
+;;; You should have received a copy of the GNU General Public License
+;;; along with GNU Guix.  If not, see .
+
+;;; Commentary:
+;;;
+;;; Alias for "guix package -i"
+;;; Needs to be in its own file because of (command-files) in guix/ui.scm
+;;;
+
+(define-module (guix scripts install)
+  #:use-module ((guix ui) #:hide (display-profile-content))
+  #:use-module (guix scripts)
+  #:use-module (guix scripts package)
+  (guix-install))
+
+;;;
+;;; Entry point.
+;;;
+
+(define (guix-install . args)
+;; How do we pass everything over to (guix scripts package)?
+  (display args)
+  (newline)
+  (display "swedebugia was here"))
-- 
2.18.0

Re: New detailed troubleshooting section in the manual

[Laura Lazzati]

Hi Ludo

Following these instructions should make the warnings go away,
> doesn’t it?
>
No they don't. I installed the package, exported the path, added it to my
.profile file but the message still appears.
And if I check `env | sort`, even after rebooting or shutting down, the
GUIX_LOCPATH is set.
I also tried installing glibc-locales but the same happens.

Regards!
Laura

Re: Review of pros and cons of package managers including Guix

[swedebugia]

Hi

On 2018-11-08 16:31, Adam Van Ymeren wrote:

On November 8, 2018 4:43:23 AM EST, Thorsten Wilms  wrote:

On 08/11/2018 10.09, swedebugia wrote:

https://www.slant.co/topics/344/~best-linux-package-managers

Insights from the Guix-section:

4 pros: (missing the roll-back feature) see link.

1 cons:

"Cannot handle filetypes that have different semantics across

different

versions
While the functional approach that Guix takes is great for sandboxing
binary artifacts of packages, it seriously lacks any power in

handling

configuration files or user data. It's difficult to upgrade and
downgrade files where semantics and syntax can change between

versions."

Do you agree with this critique?


The best handling of configuration files I got to know is offered by
Debian, which, if a package comes with a new configuration file, asks
what to do about it. Better than nothing, but still not exactly a good
user experience. There quite simply isn't the right level of
granularity
and encoding of intentions given with plain text configuration files.

Guix is in a position to do better than most in this area.  I love how most 
services in Guix are configured via s-expressions which then generate the 
appropriate plain text config from that.  Don't have to learn a new syntax for 
every service.

It also means that configurations are usable data in the Guix world, allowing 
us to automatically upgrade configs to new syntax if a package decides to 
change it.


I totally agree!

The Scheme s-expressions was a somewhat steep learning curve but now 
having passed it and beginning to understand the error messages from the 
Guile IT IS AWESOME.


1 powerful extension language to rule all the packages and configuration 
files :D


I keep track of my config.scm with git and it is simple to see the 
changes over time as I customize and tweak things.


I wish Guix had existed when I started with GNU/Linux 15 years ago. I 
began with Xandros and then moved on to Debian, Ubuntu and then Parabola.


--
Cheers
Swedebugia

Re: Review of pros and cons of package managers including Guix

[Adam Van Ymeren]

On November 8, 2018 4:43:23 AM EST, Thorsten Wilms  wrote:
>On 08/11/2018 10.09, swedebugia wrote:
>> 
>> https://www.slant.co/topics/344/~best-linux-package-managers
>> 
>> Insights from the Guix-section:
>> 
>> 4 pros: (missing the roll-back feature) see link.
>> 
>> 1 cons:
>> 
>> "Cannot handle filetypes that have different semantics across
>different 
>> versions
>> While the functional approach that Guix takes is great for sandboxing
>
>> binary artifacts of packages, it seriously lacks any power in
>handling 
>> configuration files or user data. It's difficult to upgrade and 
>> downgrade files where semantics and syntax can change between
>versions."
>> 
>> Do you agree with this critique?
>
>The whole page is far from a worthwhile comparison, because the "cons" 
>and "pros" are all over the place. Characteristics that are listed  as 
>either for one manager do not appear for all others that have them,
>too.
>
>This specific con could be listed for most, if not all others, too, 
>right? Curious, if anyone knows an exception.
>
>The best handling of configuration files I got to know is offered by 
>Debian, which, if a package comes with a new configuration file, asks 
>what to do about it. Better than nothing, but still not exactly a good 
>user experience. There quite simply isn't the right level of
>granularity 
>and encoding of intentions given with plain text configuration files.

Guix is in a position to do better than most in this area.  I love how most 
services in Guix are configured via s-expressions which then generate the 
appropriate plain text config from that.  Don't have to learn a new syntax for 
every service.

It also means that configurations are usable data in the Guix world, allowing 
us to automatically upgrade configs to new syntax if a package decides to 
change it.

Re: Review of pros and cons of package managers including Guix

[Thorsten Wilms]

On 08/11/2018 10.09, swedebugia wrote:


https://www.slant.co/topics/344/~best-linux-package-managers

Insights from the Guix-section:

4 pros: (missing the roll-back feature) see link.

1 cons:

"Cannot handle filetypes that have different semantics across different 
versions
While the functional approach that Guix takes is great for sandboxing 
binary artifacts of packages, it seriously lacks any power in handling 
configuration files or user data. It's difficult to upgrade and 
downgrade files where semantics and syntax can change between versions."


Do you agree with this critique?


The whole page is far from a worthwhile comparison, because the "cons" 
and "pros" are all over the place. Characteristics that are listed  as 
either for one manager do not appear for all others that have them, too.


This specific con could be listed for most, if not all others, too, 
right? Curious, if anyone knows an exception.


The best handling of configuration files I got to know is offered by 
Debian, which, if a package comes with a new configuration file, asks 
what to do about it. Better than nothing, but still not exactly a good 
user experience. There quite simply isn't the right level of granularity 
and encoding of intentions given with plain text configuration files.



--
Thorsten Wilms

thorwil's design for free software:
http://thorwil.wordpress.com/

Re: Annotated guix source folder tree

[swedebugia]

On 2018-11-07 18:53, Pierre Neidhardt wrote:

Neat!  Maybe align the "; "-prefixed comments to the same column?

I tried but Thunderbird did not enable me to do that :-\

--
Cheers
Swedebugia

Review of pros and cons of package managers including Guix

[swedebugia]

Hi

I stumpled upon this today:

https://www.slant.co/topics/344/~best-linux-package-managers

Insights from the Guix-section:

4 pros: (missing the roll-back feature) see link.

1 cons:

"Cannot handle filetypes that have different semantics across different 
versions
While the functional approach that Guix takes is great for sandboxing 
binary artifacts of packages, it seriously lacks any power in handling 
configuration files or user data. It's difficult to upgrade and 
downgrade files where semantics and syntax can change between versions."


Do you agree with this critique?

Should we ask the author to give an example of this?

--
Cheers
Swedebugia