Re: Remove lash
Hi, Ludovic Courtès writes: > Hi, > > Ricardo Wurmus skribis: > >> on a modern Guix System with Gnome we’re pulling in Python 2. That’s >> because gtk uses lash, and lash (last commit was 14 years ago) comes >> with Python bindings — for Python 2. >> >> I’d like to propose one of the following steps: > > s/steps/options/ ? > >> - remove lash completely >> - build lash without Python bindings, removing python2 >> - remove lash from fluidsynth, thereby removing it from the gtk closure >> >> What do you think? > > I’m not familiar with Lash, but based on your description, I’d be in > favor of removing it entirely, and definitely for removing it from GTK. +1. Thanks for taking care of that, it had bothered me as well. -- Thanks, Maxim
Guix status for RISC-V summit
Hello Guix, For the purpose of reporting at the RISC-V summit, the RISC-V Foundation is collecting information about the status of software project support for RISC-V. See the spreadsheet link at: https://lists.riscv.org/g/tech-announce/message/190 I see that Guix is not currently listed there alongside other Operating Systems, so I think it would be cool if a "project leader" or someone more in the know about our current riscv status could fill out the form at https://forms.gle/sGZTJHJEQuCGTEJc8 That way we can get some additional exposure for everyone who's putting in work on our riscv port. Cheers, `~Eric signature.asc Description: This is a digitally signed message part
Re: Licence of the Guix blog posts
Ludovic Courtès writes: > Therefore, I propose to apply the following patch, which leaves out a Yes! The patch looks good. I‘m fine with that license. Regards, Florian
Re: Licence of the Guix blog posts
On 2022-11-28, Ludovic Courtès wrote: > You might remember that I started long ago asking people who had > contributed to the blog whether they would agree to licensing their work > under CC-BY-SA 4.0 and GFDL version 1.3 or later, with no Invariant > Sections, no Front-Cover Texts, and no Back-Cover Texts¹. ... > Simon, what do you think about emailing the authors of the “10 years of > stories” post asking if they agree with the licensing? :-) No rush, > though the sooner the more likely we are to get an answer. Happy for my contribution to be under those licensing terms! live well, vagrant signature.asc Description: PGP signature
Potential minor API change notice
Hello, This is a heads up to let you know that the %BASE-PACKAGES-DISK-UTILITIES public variable exported from (gnu system) may be removed in the near future. For the rationale and more details, see the proposed change [0]. [0] https://issues.guix.gnu.org/59661#1 Thanks, Maxim
Re: Licence of the Guix blog posts
Am Mon, Nov 28, 2022 at 06:22:15PM +0100 schrieb Ludovic Courtès: > contributed to the blog whether they would agree to licensing their work > under CC-BY-SA 4.0 and GFDL version 1.3 or later, with no Invariant > Sections, no Front-Cover Texts, and no Back-Cover Texts¹. > > Simon, what do you think about emailing the authors of the “10 years of > stories” post asking if they agree with the licensing? Fine for me, of course. Andreas
Re: Licence of the Guix blog posts
Hi, Ludovic Courtès writes: > Hello Guix! > > You might remember that I started long ago asking people who had > contributed to the blog whether they would agree to licensing their work > under CC-BY-SA 4.0 and GFDL version 1.3 or later, with no Invariant > Sections, no Front-Cover Texts, and no Back-Cover Texts¹. > > I did not get replies from Danny Milosavljevic and Laura Lazzati²; > everyone else agreed publicly. Perhaps try one last time; Danny is still around, I think. > In the meantime, we got a new blog post³ with lots of contributors, > thanks to Simon’s work. Unfortunately I think we did not discuss the > licensing terms. > > Therefore, I propose to apply the following patch, which leaves out a > couple of posts as “unlicensed”. From there on, we’ll have consistent > free licensing by default. > > Thoughts? LGTM. -- Thanks, Maxim
Re: advanced?
Hi, On Mon, 28 Nov 2022 at 15:44, Simon Josefsson via "Development of GNU Guix and the GNU System distribution." wrote: > Yes, that makes sense. I'm not the best person to summarize it, but > starting pointers if someone wants to take it further: Well, it is somehow part of, * Transactional upgrades and roll-backs * Reproducible build environments I would also add Inferiors and Time-machine, especially working in tandem with Software Heritage. AFAIU, it is unique to be able to jump to (almost) any point back in time and just rebuild (or almost), with one command-line, whatever the state of the world (or almost). It pushes far beyond features such as https://snapshot.debian.org/ IMHO. Cheers, simon
Re: Licence of the Guix blog posts
Hi, > > Simon, what do you think about emailing the authors of the “10 years of > stories” post asking if they agree with the licensing? :-) No rush, > though the sooner the more likely we are to get an answer. I'm one of them. You can use what I wrote with the license you prefer. Consider it yours. Cheers, Ekaitz
Licence of the Guix blog posts
Hello Guix!
You might remember that I started long ago asking people who had
contributed to the blog whether they would agree to licensing their work
under CC-BY-SA 4.0 and GFDL version 1.3 or later, with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts¹.
I did not get replies from Danny Milosavljevic and Laura Lazzati²;
everyone else agreed publicly.
In the meantime, we got a new blog post³ with lots of contributors,
thanks to Simon’s work. Unfortunately I think we did not discuss the
licensing terms.
Therefore, I propose to apply the following patch, which leaves out a
couple of posts as “unlicensed”. From there on, we’ll have consistent
free licensing by default.
Thoughts?
Simon, what do you think about emailing the authors of the “10 years of
stories” post asking if they agree with the licensing? :-) No rush,
though the sooner the more likely we are to get an answer.
Ludo’.
¹ https://lists.gnu.org/archive/html/guix-devel/2022-02/msg00059.html
² https://lists.gnu.org/archive/html/guix-devel/2022-07/msg00059.html
³ https://guix.gnu.org/en/blog/2022/10-years-of-stories-behind-guix/
diff --git a/website/apps/blog/templates/post.scm b/website/apps/blog/templates/post.scm
index de02c6c..0d6b08e 100644
--- a/website/apps/blog/templates/post.scm
+++ b/website/apps/blog/templates/post.scm
@@ -60,4 +60,19 @@
#:label tag
#:url (guix-url (tag-url-path tag)))
" ")) ; NOTE: Force space for readability in non-CSS browsers.
- (sort tags tag-first?
+ (sort tags tag-first?)))
+
+(div
+ (@ (class "license"))
+ ,(G_ `(p "Unless otherwise stated, blog posts on this site are
+copyrighted by their respective authors and published under the terms of
+the " ,(G_
+`(a (@ (href "https://creativecommons.org/licenses/by-sa/4.0/;))
+"CC-BY-SA 4.0"))
+ " license and those of the "
+ ,(G_
+`(a (@ (href
+"https://www.gnu.org/licenses/fdl-1.3.html;))
+"GNU Free Documentation License"))
+ " (version 1.3 or later, with no Invariant Sections, no
+Front-Cover Texts, and no Back-Cover Texts)."
diff --git a/website/posts/10y-birthday-stories.md b/website/posts/10y-birthday-stories.md
index 40f6eaf..1c64982 100644
--- a/website/posts/10y-birthday-stories.md
+++ b/website/posts/10y-birthday-stories.md
@@ -809,3 +809,5 @@ operating system configuration management. Guix is highly customizable
and hackable through [Guile](https://www.gnu.org/software/guile)
programming interfaces and extensions to the
[Scheme](http://schemers.org) language.
+
+> _This post does not yet carry an agreed-upon license._
diff --git a/website/posts/bootstrapping-rust.md b/website/posts/bootstrapping-rust.md
index 6cb9b40..a44a271 100644
--- a/website/posts/bootstrapping-rust.md
+++ b/website/posts/bootstrapping-rust.md
@@ -104,3 +104,5 @@ management, and is highly customizable and hackable.
GuixSD can be used on an i686, x86_64, ARMv7, and AArch64 machines. It
is also possible to use Guix on top of an already installed GNU/Linux
system, including on mips64el and aarch64.
+
+> _This post does not yet carry an agreed-upon license._
diff --git a/website/posts/documentation-video-creation-2019.md b/website/posts/documentation-video-creation-2019.md
index 1217399..61bd853 100644
--- a/website/posts/documentation-video-creation-2019.md
+++ b/website/posts/documentation-video-creation-2019.md
@@ -92,3 +92,5 @@ operating system configuration management. Guix is highly customizable
and hackable through [Guile](https://www.gnu.org/software/guile)
programming interfaces and extensions to the
[Scheme](http://schemers.org) language.
+
+> _This post does not yet carry an agreed-upon license._
diff --git a/website/static/blog/css/post.css b/website/static/blog/css/post.css
index 57d7f0d..95035ba 100644
--- a/website/static/blog/css/post.css
+++ b/website/static/blog/css/post.css
@@ -38,3 +38,8 @@ article {
article.limit-width {
max-width: 720px;
}
+
+.license {
+font-size: 0.8em;
+line-height: 1.4em;
+}
signature.asc
Description: PGP signature
Re: advanced?
On Sun, 27 Nov 2022 10:35:13 -0800 Vagrant Cascadian wrote: > It also makes me wonder if "advanced" will stand the test of > time. Someday Guix-style systems might just be status quo, and thus no > longer advanced. Guix of course will likely evolve over time... maybe > it will still hold qualities worthy of being called "advanced", [...] Something interesting would be to convey what users need to know or learn for using Guix. In "1.1 Managing Software the Guix Way" we already have hints that it might require to know the command line and scheme. Though maybe it could be clarified for less technical users. For instance it "provides" [a command line interface], but that is not clear that it's the only way to interact with some of Guix features. If we compare Guix with other FSDG compliant distributions: - Trisquel is usable by users that don't know the command line but less technical users might need a bit of help for upgrading from a version to another (in install parties for instance). Sometimes they just need somebody to be there just in case something goes wrong though. - Parabola x86_64 can probably be used by users without command line knowledge (for a desktop/laptop usage) but the boot sometimes break, so less technical users also need to plan ahead and know how to reinstall it if needed (that could be done by having a separate home for instance). A server usage does require to know the command line and also to know how to edit configuration files (like Apache configuration file). - Once installed, LibreCMC (and OpenWRT) are probably also relatively easy to configure for people that know what an IP address is, what is DHCP, what is an SSID, etc. Guix has the potential to be similar. - Freedombox (available in PureOS, Debian, etc) looks way easier but it is also way less configurable. Guix has the potential to have the same kind of balance between easiness and empowerment/configurability than LibreCMC (if graphical interfaces are written). Making the current status more clear can probably help users. On my side I've already taken that into account on the documentation I wrote on FSDG compliant distributions on the Libreplanet wiki, but I'm not sure how to improve the text in that manual section, or how to promote more that information. Denis. pgptBDqM3kKVK.pgp Description: OpenPGP digital signature
Re: Guile debugger workgroup?
Hi, Attila Lendvai writes: >> The scenario you describe above should be possible above (there is a >> debugger that supports breakpoints and single stepping). Now, it may >> be, as you wrote, that inlining can lead breakpoints to never be hit, or >> that there are bugs in this area. These things should be fixed, I agree. > > > i'm sure there's a way to globally override the > debug/optimization/inlining level in guile to make sure the code > compiles in a way that no breakpoints are missed (and/or backtraces > remain more intact, etc). The Guile documentation itself doesn't seem to be covered for that. It'd be a good place to start in my opinion. > this should also be added to the documentation, especially in the guix > context, where it's very much not as trivial as to change a command > line argument to e.g. start the guix daemon, or shepherd, in a > configuration that makes things more debuggable. That'd be nice yes. I think we should add the nice ideas/things noted here in a "Improve debbuging experience" section of the maintenance/doc/ROADMAP.org TODO. I'll get to it if no-one beats me to it. -- Thanks, Maxim
Re: advanced?
Thanks Liliana, zimoun, Ryan and Vagrant for feedback! Ludovic Courtès writes: > Or if we do want to explain more, then perhaps we need a list of > features that would also include things like Docker/VM image generation, > declarative home environments, etc. But that’s broader topic. Yes, that makes sense. I'm not the best person to summarize it, but starting pointers if someone wants to take it further: * Dedication to free software goals and the GNU community * Shepherd init system written in Guile * Declarative stateless system configurations * Transactional upgrades and roll-backs * Reproducible build environments * Designed towards bootstrappable builds Maybe this fits better directly in the Introduction section of the manual? https://guix.gnu.org/manual/en/html_node/Introduction.html > PS: For the record, the phrase “advanced distribution of the GNU system” > was coined by RMS at a time where he insisted that this thing cannot > be called “the GNU system”. All this makes little sense, even less > so today, but if you’re curious you may enjoy Andreas’ entertaining > talk: https://10years.guix.gnu.org/video/ten-years-of-failures/ Ah, thanks, the wording of that paragraph is more understandable now! I can see how that wording came about, and also how it clarify compared to the GNU system. I think this knowledge was the missing piece I didn't have. As an introduction to what Guix is for someone without earlier understanding of GNU etc, I still believe that the word 'advanced' does not contribute though. /Simon signature.asc Description: PGP signature
Re: Guile debugger workgroup?
> Do you have examples in mind of things you’d like to log and that would > have helped you on a debugging journey? the first thing that pops to my mind is the service start gexp's in shepherd: they felt impossible to debug. i often was pretty much resorting to staring at the code, and then trying ad-hoc changes (with a minute+ long edit-compile-test cycle). there are multiple issues here. the first one is that there's no proper error handling in shepherd. but if there was at least a semi-global error handler, that logged a full backtrace into a log file, then it would have been immensely helpful. for inspiration, this is what we developed in common lisp: https://hub.darcs.net/hu.dwim/hu.dwim.util/browse/source/error-handling.lisp#10 WITH-LAYERED-ERROR-HANDLERS is a macro for which you can provide a "level 1" error handler hook that does whatever it wants. if any errors happen within this hook, then a level2 error handler kicks in, turns off several things (e.g. custom PRINT-OBJECT methods), and tries to log a backtrace in a defensive way (e.g. there are error handlers installed while printing each backtrace level). if even level2 errors out, then a super conservative level3 error handler logs this fact, so that there's *some* sign of an error. note that the logging library must also be smart about how it deals with errors. the default level1 handler has fancy features like "backtrace decorators", which is a registry of dinamically bound thunks that are called when a backtrace is printed. they can decorate the end of the backtrace with dynamic information from the context that is not captured by the backtrace (e.g. the web session, the user logged in, etc). this error handler mechanism is installed at strategic points, like the handling of a http request, or a great candidate would be when calling the user code in the start gexp of a shpeherd service. let me know if anything like this is available in scheme. i know about these in guix and guile: /guix/ui.scm: (define (call-with-error-handling /module/system/repl/error-handling.scm: (define* (call-with-error-handling the longer i work on/in guix, the higher the chance that i'll port parts of our CL debugging stuff to scheme. i think i was just procractinating it until i develop a deep enough understanding of scheme to do it properly. HTH, -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “We are caged by our cultural programming. Culture is a mass hallucination, and when you step outside the mass hallucination you see it for what it's worth.” — Terence McKenna (1946–2000), from the lecture 'Eros and the Eschaton' (1994)
Re: Guile debugger workgroup?
> The scenario you describe above should be possible above (there is a > debugger that supports breakpoints and single stepping). Now, it may > be, as you wrote, that inlining can lead breakpoints to never be hit, or > that there are bugs in this area. These things should be fixed, I agree. i'm sure there's a way to globally override the debug/optimization/inlining level in guile to make sure the code compiles in a way that no breakpoints are missed (and/or backtraces remain more intact, etc). this should also be added to the documentation, especially in the guix context, where it's very much not as trivial as to change a command line argument to e.g. start the guix daemon, or shepherd, in a configuration that makes things more debuggable. -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “Knowledge makes a man unfit to be a slave.” — Frederick Douglass (1818–1895), a former slave.
Re: Guile debugger workgroup?
Hi, On Mon, 28 Nov 2022 at 12:06, Ludovic Courtès wrote: > Why doesn’t it work in ‘guix repl’? Because auto-compilation is > disabled: Ah, thanks. Well, maybe we could have an option to start “guix repl” with debug mode available… even if it is really slow. > I think we should identify scenarios where things don’t work as > expected, and then turn them into bug reports, documentation issues, or > any other concrete action we should take. The example I provided is, IMHO, a good scenario for starting. :-) For instance, ,step by ,step works, --8<---cut here---start->8--- $ guix shell guile -- guile -q GNU Guile 3.0.8 Copyright (C) 1995-2021 Free Software Foundation, Inc. Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'. This program is free software, and you are welcome to redistribute it under certain conditions; type `,show c' for details. Enter `,help' for help. scheme@(guile-user)> (load "/tmp/my-target.scm") scheme@(guile-user)> ,break example Trap 0: Breakpoint at #. scheme@(guile-user)> (example #t) Trap 0: Breakpoint at # Entering a new prompt. Type `,bt' for a backtrace or `,q' to continue. scheme@(guile-user) [1]> ,bt In /tmp/my-target.scm: 17:0 0 (example #t) scheme@(guile-user) [1]> ,s Step into # scheme@(guile-user) [1]> ,bt In /tmp/my-target.scm: 19:21 0 (example _) scheme@(guile-user) [1]> ,s Step into # scheme@(guile-user) [1]> ,s Step into # scheme@(guile-user) [1]> ,s Step into # scheme@(guile-user) [1]> ,bt In /tmp/my-target.scm: 19:20 1 (example _) 3:0 0 (mutate-once "something") scheme@(guile-user) [1]> --8<---cut here---end--->8--- but then I do not know how many steps are required to reach the other ’mutate-twice’. --8<---cut here---start->8--- Step into # Step into # 4x Step into # 5x Step into # 4x Step into # Step into # 10x Step into # 4x Step into # Step into # 6x Step into # 3x Step into # 5x Step into # Step into # … --8<---cut here---end--->8--- And I do not know if ,break-at-source works correctly. --8<---cut here---start->8--- $ cat -n /tmp/my-target.scm | grep 20 20 (my-target (mutate-twice my-target))) $ guix shell guile -- guile -q GNU Guile 3.0.8 Copyright (C) 1995-2021 Free Software Foundation, Inc. Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'. This program is free software, and you are welcome to redistribute it under certain conditions; type `,show c' for details. Enter `,help' for help. scheme@(guile-user)> (load "/tmp/my-target.scm") scheme@(guile-user)> ,break example Trap 0: Breakpoint at #. scheme@(guile-user)> (example #t) Trap 0: Breakpoint at # Entering a new prompt. Type `,bt' for a backtrace or `,q' to continue. scheme@(guile-user) [1]> ,bt In /tmp/my-target.scm: 17:0 0 (example #t) scheme@(guile-user) [1]> ,break-at-source "/tmp/my-target.scm" 20 Trap 1: Breakpoint at /tmp/my-target.scm:20. scheme@(guile-user) [1]> ,bt In /tmp/my-target.scm: 17:0 0 (example #t) scheme@(guile-user) [1]> ,next Step into # scheme@(guile-user) [1]> ,bt In /tmp/my-target.scm: 19:21 0 (example _) scheme@(guile-user) [1]> ,locals No local variables. scheme@(guile-user) [1]> --8<---cut here---end--->8--- Cheers, simon
Re: how to customize mirror list used in custom channels?
Hi, On Mon, 28 Nov 2022 at 11:49, Ludovic Courtès wrote: > Hi, > > zimoun skribis: > >> On Sat, 26 Nov 2022 at 12:11, Ludovic Courtès wrote: > > [...] > >>> Now, if you really want to extend the set of things recognized, you >>> could write variant of ‘url-fetch’ that passes a different #:mirrors >>> argument to ‘built-in-download’. Maybe ‘url-fetch’ could have a >>> #:mirrors parameter to simplify it. >> >> Why is it not possible to extend ’%mirrors? > > What I described above is one way to extend it, just not via ‘set!’. Just to be sure, one way is this extension mechanism, --8<---cut here---start->8--- (define (qt-urls component version) "Return a list of URLs for VERSION of the Qt5 COMPONENT." ;; We can't use a mirror:// scheme because these URLs are not exact copies: ;; the layout differs between them. (list (string-append "https://download.qt.io/official_releases/qt/; (version-major+minor version) "/" version "/submodules/" component "-everywhere-opensource-src-" version ".tar.xz") (string-append "https://download.qt.io/official_releases/qt/; (version-major+minor version) "/" version "/submodules/" component "-everywhere-src-" version ".tar.xz") (string-append "https://download.qt.io/archive/qt/; (version-major+minor version) "/" version "/submodules/" component "-everywhere-opensource-src-" version ".tar.xz") (let ((directory (string-append "qt5" (string-drop component 2 (string-append "http://sources.buildroot.net/; directory "/" component "-everywhere-opensource-src-" version ".tar.xz")) (string-append "https://distfiles.macports.org/qt5/; component "-everywhere-opensource-src-" version ".tar.xz"))) --8<---cut here---end--->8--- then, (uri (qt-urls name version)) Right? Well, for what it is worth, it does not appear to me consistent with the rest. We could do the same for everything, and remove "mirror://" after all. :-) The other one way is to implement a variant of url-fetch method. What would be the interface? Where the extended list of mirrors would be provided? Cheers, simon
Re: Guile debugger workgroup? (was: Coding style: similarly-named variables)
Maxim Cournoyer writes: > Hi Simon, > > zimoun writes: > >> Hi Maxim, >> >> On Mon, 21 Nov 2022 at 15:55, Maxim Cournoyer >> wrote: >> >>> In practice since using breakpoints/a debugger to debug Guile code >>> rarely works as intended (in my experience hacking on Guix!), we >>> typically sprinkle the source with 'pk', and that point becomes moot. >> >> I totally agree! Preparing some materials for introducing Guile to >> GuixHPC folk, I am trying to collect some tips and, if I am honest, the >> debugging experience with Guile is really poor; compared to others (as >> Python). For example, DrRacket provides an easy and nice user >> experience [1] – where it is easy to compare each intermediary result in >> the debugger. For what it is worth, I have not been able to have some >> similar inspections as in [1]. Maybe, I am missing something… >> >> Well, IMHO, we are somehow suffering from some Guile limitations and >> improvements in this area are an hard task. > > I also agree! It's hard to convince people to pick Guile for their > project when there is: > > 1. Lack of a debugger that can break and step anywhere in your source > code > 2. Lack of debugger integration to an IDE (it's not even integrated into > Emacs) > > Perhaps we should assemble a Guile debugger workgroup that'd review > what's broken, what's missing, what can be borrowed from other Scheme or > languages for inspiration, and hopefully improve the Guile debugging > experience? :-) Can we also get a profiler like Python's Scalene? I'm pretty sure there are some performance bottlenecks it could help identify, both in Guix and in Guile itself.
Re: advanced?
Hello! Vagrant Cascadian skribis: > On 2022-11-26, Simon Josefsson via "Development of GNU Guix and the GNU > System distribution." wrote: >> I find use of the term 'advanced' wrt Guix confusing and even mildly >> excluding, even though it is wide-spread. What is advanced about Guix? >> Can I use it even if I'm not an advanced user? What do others think? >> Is there some historical background for this description of Guix? > > Thanks for bringing this up! > > It does seem consistent with the guix manual section on package synopsis > and descriptions: > > https://guix.gnu.org/en/manual/devel/en/guix.html#Synopses-and-Descriptions Indeed. :-) I’m fine with the patch Simon submitted and agree with the rationale. [...] >> If we want to use the term, I think it would be better to rephrase >> things as 'Guix supports advanced features such as X, Y and Z' if we >> really want to drive home that we are advanced. > > This works for me... describe *why* it is advanced rather than just > proclaiming it. The second and third points (dependable and hackable) give an idea of what makes it advanced, so maybe we don’t need to add much? Or if we do want to explain more, then perhaps we need a list of features that would also include things like Docker/VM image generation, declarative home environments, etc. But that’s broader topic. Thanks, Ludo’. PS: For the record, the phrase “advanced distribution of the GNU system” was coined by RMS at a time where he insisted that this thing cannot be called “the GNU system”. All this makes little sense, even less so today, but if you’re curious you may enjoy Andreas’ entertaining talk: https://10years.guix.gnu.org/video/ten-years-of-failures/
Re: Guile debugger workgroup?
Hi, Attila Lendvai skribis: > which reminds me that a project-wide logging infrastructure would also > greatly elevate the guix debugging experience. Do you have examples in mind of things you’d like to log and that would have helped you on a debugging journey? Ludo’.
Re: Guile debugger workgroup?
Hi, zimoun skribis: > scheme@(guix-user)> ,break example > Trap 2: Breakpoint at #. > scheme@(guix-user)> (example #t) > $2 = 20 I get this: --8<---cut here---start->8--- $ guile GNU Guile 3.0.8 Copyright (C) 1995-2021 Free Software Foundation, Inc. Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'. This program is free software, and you are welcome to redistribute it under certain conditions; type `,show c' for details. Enter `,help' for help. scheme@(guile-user)> (load "/tmp/example.scm") ;;; note: source file /tmp/example.scm ;;; newer than compiled /home/ludo/.cache/guile/ccache/3.0-LE-8-4.6/tmp/example.scm.go ;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0 ;;; or pass the --no-auto-compile argument to disable. ;;; compiling /tmp/example.scm ;;; : warning: possibly unused local top-level variable `mutate-once' ;;; : warning: possibly unused local top-level variable `mutate-twice' ;;; : warning: possibly unused local top-level variable `do-something-with' ;;; : warning: possibly unused local top-level variable `example' ;;; compiled /home/ludo/.cache/guile/ccache/3.0-LE-8-4.6/tmp/example.scm.go scheme@(guile-user)> ,break example Trap 0: Breakpoint at #. scheme@(guile-user)> (example #t) Trap 0: Breakpoint at # Entering a new prompt. Type `,bt' for a backtrace or `,q' to continue. scheme@(guile-user) [1]> ,bt In /tmp/example.scm: 17:0 0 (example #t) scheme@(guile-user) [1]> ,locals No local variables. --8<---cut here---end--->8--- and then: --8<---cut here---start->8--- scheme@(guile-user) [1]> ,q $1 = 20 scheme@(guile-user)> ,break /tmp/example.scm 17 While executing meta-command: Wrong number of arguments to # scheme@(guile-user)> ,break-at /tmp/example.scm 17 Trap 1: Breakpoint at /tmp/example.scm:17. scheme@(guile-user)> (example #t) Trap 1: Breakpoint at /tmp/example.scm:17 Entering a new prompt. Type `,bt' for a backtrace or `,q' to continue. scheme@(guile-user) [1]> ,q Trap 0: Breakpoint at # Entering a new prompt. Type `,bt' for a backtrace or `,q' to continue. --8<---cut here---end--->8--- Why doesn’t it work in ‘guix repl’? Because auto-compilation is disabled: --8<---cut here---start->8--- $ head -1 $(type -P guix) #!/gnu/store/805g934pgy3955g87ld6qixny6biwmj3-guile-wrapper/bin/guile --no-auto-compile --8<---cut here---end--->8--- … which in turn causes ‘load’ to evaluate code. I think we should identify scenarios where things don’t work as expected, and then turn them into bug reports, documentation issues, or any other concrete action we should take. And I guess that brings us back to Maxim’s suggestion of starting a debugger workgroup. :-) Ludo’.
Re: Guile debugger workgroup?
Hi, Maxim Cournoyer skribis: > Ludovic Courtès writes: [...] >> Also, I think I mentioned before that I almost never use breakpoints on >> Guile code—not because of some deficiency of the debugger, not (just) >> because I’m silly or inexperienced, but because it’s rarely the right >> tool for the job. >> >> I believe this is largely due to (1) writing functional code, and (2) >> doing live programming at the REPL. Why would you use breakpoints when >> you can just call the relevant procedures on some input to see how they >> behave? > > And I've probably countered that before by saying that while it's true > that functional programming helps, there are still times where the > inputs or the lexical environment I need to understand are complex > enough that reproducing them at the global level (REPL) is a pain. Just > breaking at the right place and typing ,locals would be a much more > efficient way to proceed to see what the environment in scope looks > like. Agreed, I didn’t mean to suggest that breakpoints are never useful. The scenario you describe above should be possible above (there *is* a debugger that supports breakpoints and single stepping). Now, it may be, as you wrote, that inlining can lead breakpoints to never be hit, or that there are bugs in this area. These things should be fixed, I agree. Ludo’.
Re: how to customize mirror list used in custom channels?
Hi, zimoun skribis: > On Sat, 26 Nov 2022 at 12:11, Ludovic Courtès wrote: [...] >> Now, if you really want to extend the set of things recognized, you >> could write variant of ‘url-fetch’ that passes a different #:mirrors >> argument to ‘built-in-download’. Maybe ‘url-fetch’ could have a >> #:mirrors parameter to simplify it. > > Why is it not possible to extend ’%mirrors? What I described above is one way to extend it, just not via ‘set!’. Ludo’.
