bug#41929: backtrace when building os on a foreign distro
$ cat guix-os.scm (use-modules (gnu bootloader) (gnu bootloader grub) (gnu system file-systems)) (operating-system (host-name "jsynacek-guix-os") (timezone "Europe/Prague") (locale "en_US.utf8") (bootloader (bootloader-configuration (bootloader grub-efi-bootloader) (target "/dev/sdx"))) (file-systems (list (file-system (mount-point "/home") (device "/dev/sda33") (type "ext4") $ guix system build guix-os.scm Backtrace: In ice-9/boot-9.scm: 1736:10 4 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _) In unknown file: 3 (apply-smob/0 #) In ice-9/boot-9.scm: 718:2 2 (call-with-prompt _ _ #) In ice-9/eval.scm: 619:8 1 (_ #(#(#))) In guix/ui.scm: 1936:12 0 (run-guix-command _ . _) guix/ui.scm:1936:12: In procedure run-guix-command: In procedure struct-vtable: Wrong type argument in position 1 (expecting struct): #f Note that 'guix system init ...' and maybe other commands don't work too. 'guix system vm' with the above config file works without a backtrace. This is on guix 1.1.0 running on Fedora 32. I also tried to 'guix pull' but the result is the same. -- Jan Synacek Software Engineer, Red Hat
bug#41353: (thunk? (const 1))
On Sun, May 17, 2020 at 4:09 PM David Kastrup wrote: > I think this is more a matter of the documentation being not quite right: > > -- Scheme Procedure: thunk? obj > -- C Function: scm_thunk_p (obj) > Return ‘#t’ if OBJ is a thunk—a procedure that does not accept > arguments. > > "if OBJ can serve as a thunk—a procedure called without arguments." > > Note that (thunk? (lambda x x)) also returns #t and that ((const 1)) > returns 1. But both (lambda x ...) and (const whatever) are still a procedure that accepts an argument, aren't they? My understanding of thunk is (lambda () ...), because that's a procedure that takes zero arguments.
bug#41353: (const x) is a thunk
With guile-3.0.2: scheme@(guile-user)> (thunk? (const 1)) $1 = #t Since thunk is a procedure that does not accept arguments (section 6.9.7, documentation for 'thunk?'), the result of the above evaluation should be #f.
bug#41352: incomprehensible paragraph in info pages
In guile-3.0.2 manual, section 6.9.3 Compiled Procedures, there is: Compiled procedures, also known as “programs”, respond all procedures that operate on procedures. In addition, there are a few more accessors for low-level details on programs. The first compound sentence doesn't make much sense. There seems to be a word missing, but it's really hard to tell.
bug#41320: sxml attributes of some elements are in reverse order
On Sat, May 16, 2020 at 2:36 PM Linus Björnstam wrote: > > > On Sat, 16 May 2020, at 14:27, Jan Synacek wrote: > > > I don't really have a strong opinion. I simply thought that the order > > in XML->SXML should be the same. Otherwise, I don't see how sxml-match > > is actually useful in such a case. > > Attributes ordering should not matter in sxml-match, as per the manual: > https://www.gnu.org/software/guile/manual/html_node/sxml_002dmatch.html I totally missed that. Thank you for pointing it out! -- Jan Synacek Software Engineer, Red Hat
bug#41320: sxml attributes of some elements are in reverse order
On Sat, May 16, 2020 at 1:35 PM wrote: > > On Sat, May 16, 2020 at 12:29:54PM +0200, Jan Synacek wrote: > > Consider the following code snippet running on Guile-3.0.2: > > [...] > > > > > [...] > > > (event (@ (number 2) (name KeyPress)) > > > Attributes 'number' and 'name' are in reverse compared to the original > > xml. On the other hand, 'type' and 'name' of the 'field' element are in > > correct order. > > According to the XML spec, attribute order is irrelevant [1] Sure, but I was under the impression that XML->SXML should map 1:1. Is it not so? > "Note that the order of attribute specifications in > a start-tag or empty-element tag is not significant." > > Now one could argue that we might want to be stricter in the > XML->SXML processor, which would be fine, but OTOH there's a > price to pay. The question is whether we want to go there -- > just imagine another XML processor in the middle changing > attribute order. It would be spec compliant. What now? > > Tough question. In the middle of the first processor reading the file? IMO there should be a lock of some sort and such race shouldn't happen in the first place. Or does that mean that there is a composition of processors? Then it shouldn't matter too, since I'm most likely the one controlling the composition. Or am I misunderstanding something? I don't really have a strong opinion. I simply thought that the order in XML->SXML should be the same. Otherwise, I don't see how sxml-match is actually useful in such a case. Regards, -- Jan Synacek Software Engineer, Red Hat
bug#41320: sxml attributes of some elements are in reverse order
Consider the following code snippet running on Guile-3.0.2: (use-modules (sxml simple) (sxml xpath)) (define doc (call-with-input-file "/home/jsynacek/src/xcb-proto-1.13/src/xproto.xml" (lambda (port) (xml->sxml port (define events ((sxpath '(// event)) doc)) (display (car events)) (newline) Now, attributes of *some* elements are generated in reverse order, which makes the output pretty much undeterministic and using sxml-match unreliable. This is from the original xml: ... And the resulting sxml: (event (@ (number 2) (name KeyPress)) (field (@ (type KEYCODE) (name detail))) (field (@ (type TIMESTAMP) (name time))) (field (@ (type WINDOW) (name root))) ... Attributes 'number' and 'name' are in reverse compared to the original xml. On the other hand, 'type' and 'name' of the 'field' element are in correct order. The xproto.xml file comes from xcb-proto [1]. [1] https://lists.freedesktop.org/archives/xcb/2018-March/011090.html
bug#40486: http-get doesn't respect #:verify-certificate?
When I run the following piece of code: (use-modules (web client)) (http-get "https://bugzilla.redhat.com/rest/bug/1; #:verify-certificate? #f) I get: ... In web/client.scm: 563:0 1 (http-get "https://bugzilla.redhat.com/rest/bug/1; # _ # …) 231:6 0 (tls-wrap # _ # _) web/client.scm:231:6: In procedure tls-wrap: X.509 certificate of 'bugzilla.redhat.com' could not be verified: signer-not-found invalid If I use http-request instead of http-get, the keyword argument is correctly taken into account and the certificate is not verified. I use v3.0.2.
bug#40014: [PATCH] typo in api-debug.texi
See attached patch. -- Jan Synacek Software Engineer, Red Hat From 8617b6a94054aafc4a58cd1e5581154e1e9ea353 Mon Sep 17 00:00:00 2001 From: Jan Synacek Date: Tue, 10 Mar 2020 15:36:03 +0100 Subject: [PATCH] texinfo: Fix typo in api-debug.texi --- doc/ref/api-debug.texi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/ref/api-debug.texi b/doc/ref/api-debug.texi index d7d0412f7..6718752fa 100644 --- a/doc/ref/api-debug.texi +++ b/doc/ref/api-debug.texi @@ -9,7 +9,7 @@ @cindex Debugging In order to understand Guile's debugging facilities, you first need to -understand a little about how Guile represent the Scheme control stack. +understand a little about how Guile represents the Scheme control stack. With that in place we explain the low level trap calls that the virtual machine can be configured to make, and the trap and breakpoint infrastructure that builds on top of those calls. -- 2.21.1
bug#40008: Backtraces can contain very long strings
I have the following backtrace: Backtrace: In ice-9/boot-9.scm: 1736:10 9 (with-exception-handler _ _ #:unwind? _ # _) In unknown file: 8 (apply-smob/0 #) In ice-9/boot-9.scm: 718:2 7 (call-with-prompt _ _ #) In ice-9/eval.scm: 619:8 6 (_ #(#(#))) In ice-9/boot-9.scm: 2806:4 5 (save-module-excursion _) 4351:12 4 (_) In /home/jsynacek/./git.scm: 72:0 3 (_) 61:16 2 (change-spec _ _ "66.33" _ #) 48:12 1 (change-release "# We ship a .pc file but don't want t…" …) In unknown file: 0 (make-regexp "^Release:(\\s*).*$" "# We ship a .pc fil…" …) ERROR: In procedure make-regexp: Wrong type (expecting exact integer): " " While this is probably not considered an error, I guess it might be better to ellipsize strings in errors such is mine that are over a certain length long. The important part of the backtrace was scrolled away and I got confused about the string, as I thought it was part of the output and started wondering why (display ...) keeps the escaped newlines in the string. If this is not considered a bug, please, at least consider it an RFE. -- Jan Synacek Software Engineer, Red Hat
