bug#68350: Segmentation fault using list-head with negative k

[Ricardo Wurmus]

Hi,

Tomas Nordin  writes:

> $ 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)> (list-head '(1 2 3) -1)
> Segmentation fault

I cannot reproduce this with Guile 3.0.9 on Guix:

--8<---cut here---start->8---
$ guile
GNU Guile 3.0.9
Copyright (C) 1995-2023 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)> (list-head '(1 2 3) -1)
ice-9/boot-9.scm:1685:16: In procedure raise-exception:
Value out of range 0 to< 18446744073709551615: -1

Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
scheme@(guile-user) [1]> 
--8<---cut here---end--->8---


-- 
Ricardo

bug#43364: with-output-to-port works with file ports

[Ricardo Wurmus]

Felix Lechner via "Bug reports for GUILE, GNU's Ubiquitous Extension Language" 
 writes:

> Hi,
>
> In an interesting (or perhaps maddening) inconsistency,
> 'with-output-to-port' captures stdout from system* here
>
> (call-with-output-file "/tmp/test.log"
>   (lambda (port)
> (with-output-to-port
>   port
>   (lambda ()
> (system* "mktemp" "-d")
>
> but 'with-output-to-string' does not do so here
>
> (with-output-to-string
>   (lambda ()
> (system* "mktemp" "-d")))
>
> According to lloda on #guile, system* handles the redirection only
> when the current ports are file ports. Thanks for that pointer!

That’s correct.  I’ve been using the following monstrosity to capture
and process output.  Perhaps someone finds a prettier way?

--8<---cut here---start->8---
(define* (call-with-output-processor command proc #:optional capture-stderr?)
  "Silently execute COMMAND, a list of strings representing an
executable with its arguments, and apply PROC to every line printed to
standard output and, optionally when CAPTURE-STDERR? is #T, standard
error.  Return the exit status of COMMAND."
  ;; We can only capture a program's standard error by parameterizing
  ;; current-error-port to a *file* port before using system* or
  ;; open-pipe*.  The process will write its standard error stream to
  ;; the provided file descriptor.  Meanwhile we read from the file
  ;; descriptor (blocking) for new lines until the process exits.
  (match (socketpair PF_UNIX SOCK_STREAM 0)
((in . out)
 (let ((err (if capture-stderr?
(dup out)
(%make-void-port "w"
   (catch #true
 (lambda ()
   (let ((thread
  (parameterize ((current-error-port err)
 (current-output-port out))
(call-with-new-thread
 (lambda ()
   (let ((status
  (status:exit-val
   (apply system* command
 (close-port err)
 (close-port out)
 status))
 (let loop ()
   (match (read-line in 'concat)
 ((? eof-object?)
  (for-each
   (lambda (port)
 (false-if-exception (close-port port)))
   (list err out in))
  (join-thread thread))
 (line
  (proc line)
  (loop))
 (lambda (key . args)
   (for-each
(lambda (port)
  (false-if-exception (close-port port)))
(list err out in))
   (apply throw key args)))
--8<---cut here---end--->8---


-- 
Ricardo

bug#60799: Bogus 'Error while printing exception' message when raising srfi-35 exception

[Ricardo Wurmus]

Hi Maxim,

> When raising a srfi-35 defined exception type like in the following, a
> generic (and unhelpful) "Error while printing exception" message is
> shown, with not even the exception type mentioned:
>
> (use-modules (srfi srfi-35))
>
> (define-condition-type  
>   platform-not-found-error?)
>
> (raise-exception )
>
>
> Produces:
>
> Backtrace:
> In ice-9/boot-9.scm:
>   1752:10  5 (with-exception-handler _ _ #:unwind? _ # _)
> In unknown file:
>4 (apply-smob/0 #)
> In ice-9/boot-9.scm:
> 724:2  3 (call-with-prompt _ _ #)
> In ice-9/eval.scm:
> 619:8  2 (_ #(#(#)))
> In ice-9/boot-9.scm:
>2836:4  1 (save-module-excursion _)
>   4388:12  0 (_)
>
> ice-9/boot-9.scm:4388:12: Error while printing exception.
>
> This is probably not by design, right?

Perhaps not, but conditions are expected to be raised with “raise”:

--8<---cut here---start->8---
(use-modules (srfi srfi-34) (srfi srfi-35))

(define-condition-type  
  platform-not-found-error?)

(raise (condition ()))
ice-9/boot-9.scm:1685:16: In procedure raise-exception:
ERROR:
  1. 
--8<---cut here---end--->8---

-- 
Ricardo

bug#59874: Segfault from string-ref with negative 'k'

[Ricardo Wurmus]

Thank you for reporting this bug.

> i noticed that if i, on my system, run "guile" from a shell and then type 
> into the command prompt that appears,
>
> (string-ref "a string" -1)
>
> guile appears to hang for a few seconds or so, and then prints the message 
> "Segmentation fault (core dumped)".

I can reproduce this on Guix System with guile 3.0.8:

--8<---cut here---start->8---
guile --no-auto-compile --debug
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)> (string-ref "a string" -1)
Segmentation fault
--8<---cut here---end--->8---

But:

--8<---cut here---start->8---
$ guile -c '(string-ref "a string" -1)'
Backtrace:
In ice-9/boot-9.scm:
  1752:10  6 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _)
In unknown file:
   5 (apply-smob/0 #)
In ice-9/boot-9.scm:
724:2  4 (call-with-prompt ("prompt") # #)
In ice-9/eval.scm:
619:8  3 (_ #(#(#)))
In ice-9/command-line.scm:
   185:19  2 (_ #)
In unknown file:
   1 (eval (string-ref "a string" -1) #)
   0 (string-ref "a string" -1)

ERROR: In procedure string-ref:
Value out of range 0 to< 7: -1
--8<---cut here---end--->8---

-- 
Ricardo

bug#57379: GUI toolkit for Guile 3.0?

[Ricardo Wurmus]

David Pirotte  writes:

> I hope Ricardo, possibly with the help of other guix contributor's will
> find a solution so that g-golf may also run 'out of the box' on guix.

Turns out that it all works fine when you disable grafts:

  guix shell --pure --no-grafts \
guile guile-g-golf gtk@4

This echoes a discussion here:

  https://github.com/spk121/guile-gi/issues/96

The immediate lessons from the observations detailed in this issue are
also why guile-gi works without disabling grafts.

-- 
Ricardo

bug#57379: GUI toolkit for Guile 3.0?

[Ricardo Wurmus]

Lee Thomas  writes:

> Thanks again, David. I was able to use a solution from Ricardo to get
> guile-gi to run under guix, but it didn't work for g-golf. :-(

For the record: what fixed the remaining problems with guile-gi was
running the code under dbus-launch.

-- 
Ricardo

bug#57379: GUI toolkit for Guile 3.0?

[Ricardo Wurmus]

Lee Thomas  writes:

> I'm not entirely sure that packages installed by guix won't
> interfere, and I don't yet know how to uninstall guix, but I'll give it my 
> best shot for you.

Guix doesn’t install anything globally where other libraries would look
for stuff, so it doesn’t interfere with anything on the system.

-- 
Ricardo

bug#57379: GUI toolkit for Guile 3.0?

[Ricardo Wurmus]

Hi,

Lee Thomas  writes:

> Thank you for responding, Ricardo! I have tried several permutations
> of packages, but currently I have this: […]

This looks all right to me.

I can reproduce this.  I also tried the latest commit of g-golf:

guix shell --pure guile \
  guile-g-golf \
  gtk@4 \
  coreutils \
  grep \
   
--with-commit=guile-g-golf=b9956e6e4c60d6be5424290e4366f3d3f46b2c31 \
   --cores=1

No difference.

My first guess was that perhaps it gets confused because GTK 3 stuff
also exists on my machine, so I used “--pure” to overwrite the
environment variables.  I also tried “--container” to be sure it doesn’t
accidentally pick up incompatible stuff.

But I can’t get it to work.  It would be helpful if g-golf were to print
more diagnostic information.  As it is I cannot think of anything to
make it work.

I only ever used guile-gi successfully.  This is the Guix shell:

   guix shell --pure guile guile-gi gtk@4 -- guile gi-test.scm

And here’s the code in gi-test.scm:

--8<---cut here---start->8---
(use-modules (gi) (gi repository))

(require "Gio" "2.0")
(require "Gtk" "4.0")

(load-by-name "Gio" "Application") ;activate, run
(load-by-name "Gtk" "Application")
(load-by-name "Gtk" "ApplicationWindow")
(load-by-name "Gtk" "Button")
(load-by-name "Gtk" "Box")
(load-by-name "Gtk" "Window")
(load-by-name "Gtk" "Widget") ;present

(define (print-hello widget)
  (display "Hello World\n"))

(define (on-activate app)
  (let* ((window (make 
   #:application app
   #:default-height 200
   #:default-width 200
   #:title "Window"))
 (box (make ))
 (button (make 
   #:label "Hello world")))
(set-child window box)
(append box button)
(connect button clicked print-hello)
(present window)))

(define (main)
  (let ((app (make  #:application-id "org.gtk.example")))
(connect app activate on-activate)
(run app (command-line

(main)
--8<---cut here---end--->8---

Clicking the button prints “Hello World” to the terminal.

-- 
Ricardo

bug#57379: GUI toolkit for Guile 3.0?

[Ricardo Wurmus]

Lee Thomas  writes:

> So I assume I haven't fixed the guix environment completely yet, but
> I'm still working on that. The guix toolset is advertised to manage
> all the interdependencies, but I'm not certain that it works in every
> situation. I'll keep trying, though. Thanks again.

Could you please show us how to reproduce this?  We would need to see
the Guix command, the code you run, and ideally the output of “guix
describe”.

-- 
Ricardo

bug#56665: Segfault in SRFI-37 when raising ERROR in ARGS-FOLD.

[Ricardo Wurmus]

Hi,

I got Guile to segfault in srfi-37.

Here’s a Guile script:

--8<---cut here---start->8---
#!/run/current-system/profile/bin/guile \
--no-auto-compile
!#

(use-modules (srfi srfi-1) (srfi srfi-37) (ice-9 match))

(define %options
  (list (option '("greet") #t #f
(lambda (opt name arg result)
  (alist-cons 'greet arg
  (alist-delete 'greet result))

(define %default-options
  `((greet . "hello")))

(define (parse-options args)
  (args-fold
   args %options
   (lambda (opt name arg result)
 (pk 'unrecognized)
 (error "unrecognized option" name))
   (lambda (arg result)
 (pk 'extraneous)
 (error "extraneous argument" arg))
   %default-options))

(match (pk 'args (program-arguments))
  ((_ . rest)
   (let ((config (parse-options rest)))
 (pk 'no-segfault)))
  (_
   (pk 'usage)))
--8<---cut here---end--->8---

And here is how to make it segfault:

--8<---cut here---start->8---
./segfault.scm --greet=no --oh=crud

;;; (args ("./segfault.scm" "--greet=no" "--oh=crud"))

;;; (unrecognized)
Backtrace:
   4 (primitive-load "/path/to/./segfault.scm")
In ice-9/eval.scm:
   293:34  3 (_ #(#(#(#(# 
("./segfault.scm" "--greet=no" "--oh=crud")) #) 
"./segfault.scm" …) …))
In srfi/srfi-37.scm:
   113:18  2 (next-arg)
In unknown file:
   1 Segmentation fault
--8<---cut here---end--->8---

Looks like using ERROR in ARGS-FOLD leads to a segfault.

-- 
Ricardo

bug#46447: segfault with bugnum

[Ricardo Wurmus]

This program sometimes causes Guile 3.0.5 to segfault:

  (define a (expt 2 (expt 3 (expt 4 2
  (display (remainder a 10))
  (display "\n")

And sometimes this program doesn’t terminate.  Here’s an example
session with the program saved to foo.scm:

--8<---cut here---start->8---
$ guile -s foo.scm
;;; note: source file /home/rekado/dev/gx/branches/master/foo.scm
;;;   newer than compiled 
/home/rekado/.cache/guile/ccache/3.0-LE-8-4.4/home/rekado/dev/gx/branches/master/foo.scm.go
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;;   or pass the --no-auto-compile argument to disable.
;;; compiling /home/rekado/dev/gx/branches/master/foo.scm
;;; compiled 
/home/rekado/.cache/guile/ccache/3.0-LE-8-4.4/home/rekado/dev/gx/branches/master/foo.scm.go
176561152
$ [env] guile -s foo.scm
176561152
$ [env] guile -s foo.scm
Segmentation fault
$ [env] guile -s foo.scm
  C-c C-c # after more than 6 seconds
$ [env]   C-c C-c
$ [env] guile -s foo.scm
Segmentation fault
$ [env] guile -s foo.scm
176561152
$ [env] guile -s foo.scm
  C-c C-c
$ [env] guile -s foo.scm
176561152
--8<---cut here---end--->8---

-- 
Ricardo

bug#46403: SIGINT ignored when using system*

[Ricardo Wurmus]

I execute commands in a loop and wish to be able to interrupt the loop
with SIGINT.  Here’s the first attempt:

guile -c \
  '(for-each (lambda (n)
  (display n)
  (system* "sleep" "3"))
 (list 1 2 3 4))'

At no point will this program be interrupted by SIGINT.  Strace reveals
that SIGINT is in fact received and the sleep is interrupted, but the
wait is restarted immediately afterward.

This program on the other hand *can* be interrupted at any point:

guile -c \
  '(for-each (lambda (n)
  (if (zero? (primitive-fork))
   (begin (display n)
  (execlp "sleep" "sleep" "3"))
   (waitpid WAIT_ANY)))
 (list 1 2 3 4))'

Is this by design?

-- 
Ricardo

bug#46014: (define (thunk) (lambda (x) x)) should be a compile error?

[Ricardo Wurmus]

Joshua Branson  writes:

> Feel free to close this bug report.  I don't believe I was able to
> demonstrate any examples of the compiler misbehaving.

Okay, closing!

-- 
Ricardo

bug#46014: (define (thunk) (lambda (x) x)) should be a compile error?

[Ricardo Wurmus]

Hi Joshua,

> Interestingly, I had wrongly assumed that
>
> #+BEGIN_SRC scheme
> (thunk "test\n")  ;; I assumed program execution would stop here
> (display "Hello World\n")
> #+END_SRC
>
> program execution would stop at (thunk "test\n").  But it actually
> caries on with execution of the program:
>
> #+BEGIN_SRC scheme
> :5:0: warning: possibly wrong number of arguments to `thunk'
> ice-9/boot-9.scm:1669:16: In procedure raise-exception:
> Wrong number of arguments to #
>
> Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
> Hello World
> #+END_SRC

It doesn’t actually carry on.  From those Org-mode blocks I cannot tell
how you’re feeding the expressions to Guile.  If you’re doing this in a
file or in a REPL session manually you’ll see this:

--8<---cut here---start->8---
scheme@(guile-user)> (define (thunk) (lambda (x) x))
scheme@(guile-user)> (thunk "test\n")
;;; :3640:0: warning: possibly wrong number of arguments to `thunk'
ice-9/boot-9.scm:1669:16: In procedure raise-exception:
Wrong number of arguments to #

Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
scheme@(guile-user) [1]> (display "Hello World\n")
Hello World
scheme@(guile-user) [1]> 
--8<---cut here---end--->8---

“Entering a new prompt” is what happens.  Consider it a special debug
mode in which you’re given the option to inspect the current state of
the environment.  Granted, you won’t see much when you type “,bt” or
“,bt #:full? 'yup”, because the error isn’t all that complicated; the
error didn’t happen in some deeply nested callee, it happened right
there when you called “thunk” with an argument.

> For fun I also thought about how else I could write thunk.  Continue
> reading at your own peril.

I feel the need to point out that the name “thunk” has a conventional
meaning, but your examples (here and before) don’t correspond to that
meaning.  A thunk is a procedure of no arguments.  When called it
returns a value — it does not matter whether that value is another
procedure, a record, or a primitive value.

What you seem to be calling “thunk” is really just a higher order
procedure, i.e. a procedure that returns another procedure.  Note that
this may or may not be a thunk as everybody else calls it.  It is a
thunk when it is a procedure that takes exactly zero arguments.

> ;; This procedure doesn't work the way I thought it would.  The way to
> ;; print a string with this procedure is to do this:
> ;; ((thunk "the") "the")
> (define (thunk x)
>(lambda (x) x))

You’re making things difficult for you here, because you’re using “x”
three times, but it means two different things dependent on where you
look at the value you bound to “x”.  This is also not a thunk (neither
the procedure “thunk” nor the value it returns), so let’s rewrite this:

  (define (moo x)
(peek 'moo-x x)
(lambda (x)
  (peek 'lambda-x x)))

Nobody cares about the value you pass to “moo”.  It is bound to the name
“x”, but nobody uses it.  Then comes along a lambda and it takes an
argument that is also known as “x” inside the body of that lambda.  They
are *not* the same “x”.  The “x” bound by the lambda shadows the outer
“x”.  You could even have yet another “x”:

  (define x 100)
  (peek 'top-level-x x)
  
  (define (moo x)
(peek 'moo-x x)
(lambda (x)
  (peek 'lambda-x x)))

Excess xes!

> ;; obvious. This is equivalent to
> ;; (define (thunk x) x)
> (define thunk
>(lambda (x)
>   x))

Correct.  Not a thunk, though.  It’s just the identity function.

> ;; This ones nice because neither (thunk) nor (thunk "the") result in a
> ;; runtime error.
> (define* (thunk #:optional x)
>x)

This is a procedure that will return #false (when no argument is
provided) or the value of the argument it was given.

> (define* (thunk #:optional x)
>(lambda* (#:optional x)
>   x))

This is again like the “moo” example earlier.  Two different values are
bound to variables that are known as “x” in their own scope, with the
later “x” shadowing the earlier “x”.

> Are there some other really weird and convoluted ways of writing thunk
> that I'm missing?  I'm guessing so.

I don’t know what you mean because your definitions above are not all
doing the same thing.  A giraffe is not a convoluted variant of a lion.

> […] Now I realize that ((thunk "the") "the")
> works.

((thunk 124) "the") has the same return value, because you’re ignoring
the first “x”.

> I suppose the moral of the story is that scheme is so expressive and
> flexible that there are ways of creating programs that can fail in weird
> ways.  And it's really hard if not impossible to catch all possible
> runtime errors at compile time.  This is because scheme values are only
> know at run-time AND NOT compile time.

This is not 100% correct, but perhaps that doesn’t matter.  Some types
are in fact known at compile time.

> I was actually listening to a scheme talk 

bug#46014: (define (thunk) (lambda (x) x)) should be a compile error?

[Ricardo Wurmus]

Hi Joshua,

> When I look at
>
> #+BEGIN_SRC scheme
> (define (thunk)
>(lambda (x)
>  x))
> #+END_SRC

[…]

> My thought is, this is clearly a mistake.  This person needs to change
> the above code.

How is this clearly a mistake?  The definition of “thunk” above is
perfectly fine and also common.

The above is equivalent to

   (define thunk
 (lambda ()
   (lambda (x) x)))

And that’s really okay and can be desired.   The problem is not with
this definition.  If someone calls this wrongly, well, that’s a problem
with the caller.  And Guile’s compiler does tell you that you are
probably wrong in calling “thunk” with an argument.

Do I understand you correctly that you would like this warning to be an
error instead?

> Gotcha.  Thanks for explaining!  I suppose what I meant to say is,
> should guile refuse to compile the above?  In other languages, like C I
> suppose, writing a function simultaneous with one and two arguments
> would refuse to compile.  The compiler would make you fix the code.

Let me address this separately.  In Scheme you *can* define a procedure
that takes a different number of arguments.  Here’s one example from the
manual:

 (define (make-accum n)
   (case-lambda
 (() n)
 ((m) (set! n (+ n m)) n)))

 (define a (make-accum 20))
 (a) ⇒ 20
 (a 10) ⇒ 30
 (a) ⇒ 30

“case-lambda” specifies a procedure that can take arguments in as many
different shapes as there are clauses.  Here there are two clauses: one
for the case where no arguments are provided and another where one
argument (bound to “m”) is provided.

Furthermore, you can see here that this is a higher order procedure, as
“make-accum” takes an argument and returns a procedure (the
case-lambda).

Another example, also from the manual, is this:

(lambda* (start #:optional (end (+ 10 start)))
  (do ((i start (1+ i)))
  ((> i end))
(display i)))

This procedure takes one or two arguments.

-- 
Ricardo

bug#46014: (define (thunk) (lambda (x) x)) should be a compile error?

[Ricardo Wurmus]

Hi,

> Consider this bit of simple code:
>
> #+BEGIN_SRC scheme
>
> (define (thunk)
>(lambda (x)
>  x))
>
> (thunk) ;; works ok, I guess.
> (thunk "hello world!\n")  ;; runtime error
>
> ;;; :1074:0: warning: possibly wrong number of arguments to `thunk'
> ice-9/boot-9.scm:1669:16: In procedure raise-exception:
> Wrong number of arguments to #
>
> Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
> #+END_SRC
>
> Guile will compile this program seemingly with no error.  Guile will
> correctly report at runtime that procedure '(thunk "hello world!\n")'
> takes no arguments, but it's lambda accepts 1 argument.  Would it be
> possible to report this error at compile time?  Would that be
> advantageous?

This is not a bug.  What you call “thunk” here is a procedure that
returns a procedure.  That’s very common and is often done to delay
evaluation.

It is in fact an error to call the procedure “thunk” with an argument.
It doesn’t matter that it happens to return a procedure that *can* take
an argument.  The procedure it returns is just like any other value,
though, and isn’t inspected any further.

That said, it is not true that Guile will compile this without a
complaint.  I dumped your code snippet in a file foo.scm and
compiled it:

--8<---cut here---start->8---
guild compile foo.scm
foo.scm:6:0: warning: wrong number of arguments to `thunk'
wrote 
`/home/rekado/.cache/guile/ccache/3.0-LE-8-4.4/home/rekado/dev/gx/gwl/foo.scm.go'
--8<---cut here---end--->8---

Isn’t that exactly what you’re asking for?

-- 
Ricardo

bug#45923: Hot to intall Guile without Make

[Ricardo Wurmus]

to...@tuxteam.de writes:

> On Sun, Jan 17, 2021 at 09:18:59PM +0100, Dr. Arne Babenhauserheide wrote:
>> 
>> paul.eb...@mail.de writes:
>> 
>> > is there a way to install Guile or Make on Manjaro without an internet
>> > connection and without having already installed one of them?
>> 
>> You’ll need to build and install make once without guile support (see
>> ./configure --help), then install Guile with that reduced make and
>> finally build and install make again with Guile support.
>
> I took the problem off-thread with paul. I think the "bug" can be closed
> now :)
>
> I'd do if I knew how.

Send email to n-d...@debbugs.gnu.org like I’m doing with this email.

-- 
Ricardo

bug#45914: read skips space after colon when prefix keywords are enabled

[Ricardo Wurmus]

When prefix keywords are enabled with (read-set! keywords 'prefix) the
characters “: hello” are read as “#:hello” instead of two separate
symbols.  It seems to me that only “:hello” should be read as “#:hello”.

There is no such problem with postfix keywords.

-- 
Ricardo

bug#44186: Recursive mkdir

[Ricardo Wurmus]

Bengt Richter  writes:

> Hi divoplade,
>
> On +2020-10-24 08:17:47 +0200, divoplade wrote:
>> Hello,
>> 
>> Le samedi 24 octobre 2020 à 01:32 +0200, Bengt Richter a écrit :
>> > An alternate solution could be programmed using ffi, as documented in
>> > [1], n'est-ce pas?
>> To be clear, you would rather have that function as guile code rather
>> than extending the C function? I'm OK with that, but in which file
>> should I put that function? My instinct was to put the code near the
>> mkdir function, and that happened to be in a C file, so I went C.

We should all be writing fewer lines of C code and more Scheme :)

> Seems logical, and probably where I'd go, but please be careful!
> Don't make a C version of this hack:
> ┌───┐
> │ (define (my-mkdir-p path . ignore) (system (string-append "mkdir -p " 
> path))) │
> └───┘
> You can then write (my-mkdir-p "foo-dir/bar-dir") and it'll do the job.
>
> But it's definitely safer to skip the hack and write
> ┌─┐
> │ (system "mkdir -p foo-dir/bar-dir") │
> └─┘
> and not give anything a chance to inject something bad via unsanitized
> parameters.

Use “system*” instead of “system” when you need to work with
user-provided values.  For mkdir-p, however, using any variant of
“system” is inelegant.

-- 
Ricardo

bug#41956: [PATCH] ice-9: exceptions: Properly format the error message.

[Ricardo Wurmus]

Hi Maxim,

>> here’s what I did in the REPL:
>>
>> scheme@(guile-user)> ,m (ice-9 exceptions)
>> scheme@(ice-9 exceptions)> (define (my/guile-system-error-converter key args)
>>   (apply (case-lambda
>>   ((subr msg-args msg errno . rest)

Here I changed the order: “msg-args” appears before “msg”.  I don’t know
why the converter that’s currently in Guile assumes that the message
comes first.

>> scheme@(ice-9 exceptions)> (set! guile-exception-converters (acons 
>> 'system-error my/guile-system-error-converter guile-exception-converters))

guile-exception-converters is a lookup table in (ice-9 exceptions).  It
associates error keys with converter procedures.  Since
canonicalize-path throws a 'system-error I chose to only update the
'system-error association.  I didn’t want to affect all the other
converter procedures that end up using the common converter; maybe they
should be affected — I don’t know because I don’t have any test cases
other than canonicalize-path.

> This brings embeds the definition of `guile-common-exceptions' into
> `guile-system-error-converter', with a single change:
>
> (make-exception-with-message msg) --> (apply make-exception-with-message
> msg msg-args)
>
> What is the magic I fail to see?

I cannot parse your sentence, so I’m not sure what you mean.

> Is this fix proper to be merged into the original
> guile-common-exceptions procedure?

I think we should add tests of different exceptions with different keys
to be sure that modifying the common handler doesn’t have any unexpected
side-effects.

-- 
Ricardo

bug#41956: [PATCH] ice-9: exceptions: Properly format the error message.

[Ricardo Wurmus]

Hi Maxim,

here’s what I did in the REPL:

--8<---cut here---start->8---
scheme@(guile-user)> ,m (ice-9 exceptions)
scheme@(ice-9 exceptions)> (define (my/guile-system-error-converter key args)
  (apply (case-lambda
  ((subr msg-args msg errno . rest)
   ;; XXX TODO we should return a more specific error
   ;; (usually an I/O error) as expected by R6RS programs.
   ;; Unfortunately this often requires the 'filename' (or
   ;; other?) which is not currently provided by the native
   ;; Guile exceptions.
   (make-exception
(make-external-error)
(make-exception-with-origin subr)
(apply make-exception-with-message msg)
(make-exception-with-irritants msg-args)))
  (_ (guile-external-error-converter key args)))
 args))
scheme@(ice-9 exceptions)> (set! guile-exception-converters (acons 
'system-error my/guile-system-error-converter guile-exception-converters))
scheme@(ice-9 exceptions)> ,m (guile-user)
scheme@(guile-user)> (guard (c ((message-condition? c)
  (format #t "message: ~a~%" (condition-message c
  (canonicalize-path "/doesntexist"))
message: No such file or directory
$11 = #t
scheme@(guile-user)> 
--8<---cut here---end--->8---

-- 
Ricardo

bug#41404: Crash "Too many root sets" when executing code from stdin in elisp mode

[Ricardo Wurmus]

Vasilij Schneidermann  writes:

> The attached reproducer script requires Emacs and Guile.  When running it, the
> REPL prints out many lines, the last ones being:
>
> $1884 = #f
> $1885 = #f
> $1886 = #f
> $1887 = #f
> $1888 = #f
> $1889 = #f
> $1890 = #f
> $1891 = #f
> $1892 = #f
> Too many root sets
> ./repro.sh: line 11:  2014 Aborted (core dumped) guile --language=elisp < 
> elisp-spec.el
>
> This happens both for Guile 2.2.6 on Arch and Guile 3.0.2 on Debian Sid,
> launched with `docker run --rm -i -t debian:sid bash`.

I can reproduce this on the wip-elisp branch as well.

-- 
Ricardo

bug#39855: PKG_GUILE does not find guile

[Ricardo Wurmus]

Julien Lepiller  writes:

> I have a project I used to build with guile 2.2. I use the PKG_GUILE
> m4 macro in my configure.ac. However, guile 3 comes with a guile.m4
> whose PKG_GUILE only checks for 2.2, 2.0 and 1.8, so configure fails.

I use “GUILE_PKG([3.0 2.2])” in my code.

--
Ricardo

bug#39210: Guile 3.0: undefined in (rnrs conditions (6))

[Ricardo Wurmus]

The module (rnrs conditions (6)) exports  but renames the
imported  to  (not ).
Programs using  from (rnrs conditions) fail with an unbound
variable error.

Using  instead of  works.

--
Ricardo

bug#36806: guix package -i guile-emacs takes Build too slow

[Ricardo Wurmus]

Rostislav Svoboda  writes:

> Hi, I'm trying to install guile-emacs using:
> guix package -i guile-emacs
> It's been running for almost 20 hours, most of the time at the step:
> building 
> /gnu/store/h8n0z0ihpykz076paavfcp4ply3qx6q0-guile-emacs-0.0.0-0.41120e0.drv...
> \ 'build' phase
> Is it hanging or not? If not:
> - is there a way to show some progress bar?

Yes, you can pass “--verbosity=2” to see details.

> - 20+ hours isn't it a bit too long anyway?

We have little to no control over build times.  When a package is slow
to be compiled (such as a full bootstrap build of Guile) then it’s going
to take a long time.

I think, though, that Guile Emacs cannot actually be built at all, so
I’m expecting your 20+ hour build to eventually fail.  That’s why Guix
tries to build it locally in the first place instead of downloading a
ready-made binary from our build farm — because the build farm doesn’t
have a binary to offer (because it failed to build it).

This is the view from our build farm:


https://ci.guix.gnu.org/search?query=guile-emacs+spec%3Aguix-master+system%3Ax86_64-linux

Doesn’t look good.

-- 
Ricardo

bug#36079: unhelpful error message

[Ricardo Wurmus]

Hi Robert,

> Working on Guix, I encountered the following:
>
> Within a guix checkout, I edited gnu/packages/haskell.scm, accidentally
> making a Haskell comment:
>
> (arguments
>  `(#:tests? #f)) -- sporadic failure: 
> https://github.com/fpco/streaming-commons/issues/49
>
> Then I tried to keep working on my in-development package, and was able to 
> trace
> the `guix build` error back to the following:
>
> $ ./pre-inst-env guild compile ../modules/postgrest.scm
> ;;; note: source file /home/rob/guix/gnu/packages/haskell.scm
> ;;;   newer than compiled /home/rob/guix/gnu/packages/haskell.go
> ;;; note: source file /home/rob/guix/gnu/packages/haskell.scm
> ;;;   newer than compiled 
> /run/current-system/profile/lib/guile/2.2/site-ccache/gnu/packages/haskell.go
> ice-9/boot-9.scm:752:25: In procedure dispatch-exception:
> Syntax error:
> unknown location: package: invalid field specifier in form —-

This error is produced by the “package” macro, which is of this form:

  (package
   (field value)
   (another-field its-value)
   …)

The macro has a number of valid field names and it tries to do some
simple validation.  That’s where the error comes from.  When “--” is
encountered it is in the position of a field, so the macro tries to be
helpful and reports that “--” is not a valid way to specify a field.

This error message is not produced by Guile.

> There are number of ways the error output could be improved. Ideally, I’d
> like to see the offending line of gnu/packages/haskell.scm pin-pointed,
> and/or the start of the enclosing package definition.

I agree that this would be nice.  Let’s move this to the Guix bug
tracker.

--
Ricardo

bug#35398: http-get request fails for github.com

[Ricardo Wurmus]

Hi Brian,

> System is —> Linux guix 4.20.10-gnu #1 SMP 1 x86_64 GNU/Linux
>
> I am running guile (GNU Guile) 2.2.4.
>
> http-get request is failing for “https://github.com ”
>
> The steps to reproduce are as follows:
>
> scheme@(guile-user)> (use-modules (web client))
> scheme@(guile-user)> (http-get "https://github.com;)
> ERROR: In procedure get-bytevector-some:
> Throw to key `gnutls-error' with args `(# temporarily unavailable, try again.> read_from_session_record_port)'.
>
> Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
> scheme@(guile-user) [1]> ,bt
> In web/client.scm:
>386:24  6 (http-request _ #:body _ #:port _ #:method _ #:version _ 
> #:keep-alive? _ #:headers _ #:decode-body? _ #:streaming? _ #:request _)
> In web/response.scm:
>198:31  5 (read-response #)
> In web/http.scm:
>   1186:15  4 (read-response-line _)
> 159:2  3 (read-header-line _)
> In unknown file:
>2 (%read-line #)
> In web/client.scm:
>142:24  1 (read! #vu8(1 17 1 37 14 19 5 17 1 18 11 16 23 0 0 2 46 0 17 1 
> 18 11 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 …) …)
> In unknown file:
>0 (get-bytevector-some #)

I can reproduce this.  (http-get "https://gnu.org;) works though.

-- 
Ricardo

bug#20339: sxml simple: sxml->xml mishandles namespaces?

[Ricardo Wurmus]

to...@tuxteam.de writes:

> As John has noted, the namespace mappings (i.e. the prefix -> namespace
> URI binding) are kind of lexically scoped (I'd call it subtree scoped,
> but structurally it is the same). While parsing is "easy" (assuming
> well-formed XML), serializing is not unambiguous.

The “fup” handler of the parser visits every element and has a list of
namespaces that are in scope at this point.  Its purpose is to return
the SXML representation of that element.  At this point we can record
the namespaces as attributes.  (That’s what the patch does.)

When baking XML from SXML we don’t need to do anything special — we only
need to convert everything to text, including the recorded namespace
attributes.  This isn’t pretty SXML (nor is it pretty XML), but it
appears to be correct as none of the namespace information is lost.

To get a better serialized representation the parser needs to do a
better job of identifying “new” namespaces.

> In a way, the library might want to be prepared to take hints from the
> application (as far as the XML is to be read by humans, there might be
> "better" and "worse" serializations).

The XML produced when this patch is applied will not be pretty.  To
generate minimal/pretty XML knowledge of the parent elements’ namespaces
is required — knowledge that the parser’s “fup” handler does not have.

We could try to alter the parser so that it not only passes the list of
namespaces that are currently in scope, but also a list of namespaces
that are in scope for the parent node.  This would allow us to determine
the list of *new* namespaces that absolutely must be declared for the
current node.  If there are no new namespaces we can simply ignore them
and produce minimal SXML (and thus minimal XML later when the SXML is
serialized).

--
Ricardo

bug#20339: sxml simple: sxml->xml mishandles namespaces?

[Ricardo Wurmus]

Ricardo Wurmus  writes:

> In that case we coud have FINISH-ELEMENT add all namespace declarations
> that are in scope to the current node that is about to be returned.  It
> would be a little verbose, but more correct.

Like this:

>From d44c702718baea4c4557d12ca8dd7dab724c7fb6 Mon Sep 17 00:00:00 2001
From: Ricardo Wurmus 
Date: Mon, 4 Feb 2019 21:39:06 +0100
Subject: [PATCH] sxml: xml->sxml: Record and use namespace abbreviations.

* module/sxml/simple.scm (xml->sxml)
[name->sxml]: Accept namespaces argument to look up abbreviation.
Return name with abbreviation prefix.
[parser]: Let FINISH-ELEMENT procedure return namespaces in addition to
the SXML tree's attributes.
---
 module/sxml/simple.scm | 34 +-
 1 file changed, 25 insertions(+), 9 deletions(-)

diff --git a/module/sxml/simple.scm b/module/sxml/simple.scm
index 703ad9137..2bb332c83 100644
--- a/module/sxml/simple.scm
+++ b/module/sxml/simple.scm
@@ -1,7 +1,8 @@
  (sxml simple) -- a simple interface to the SSAX parser
 
- 	Copyright (C) 2009, 2010, 2013  Free Software Foundation, Inc.
+ 	Copyright (C) 2009, 2010, 2013, 2019  Free Software Foundation, Inc.
 Modified 2004 by Andy Wingo .
+Modified 2019 by Ricardo Wurmus .
 Originally written by Oleg Kiselyov  as SXML-to-HTML.scm.
  
  This library is free software; you can redistribute it and/or
@@ -30,6 +31,7 @@
   #:use-module (sxml ssax)
   #:use-module (sxml transform)
   #:use-module (ice-9 match)
+  #:use-module (srfi srfi-1)
   #:use-module (srfi srfi-13)
   #:export (xml->sxml sxml->xml sxml->string))
 
@@ -123,10 +125,15 @@ port."
 (acons '*DEFAULT* default-entity-handler entities)
 entities))
 
-  (define (name->sxml name)
+  (define (name->sxml name namespaces)
 (match name
   ((prefix . local-part)
-   (symbol-append prefix (string->symbol ":") local-part))
+   (let ((abbrev (and=> (find (match-lambda
+((abbrev uri . rest)
+ (and (eq? uri prefix) abbrev)))
+  namespaces)
+first)))
+ (symbol-append abbrev (string->symbol ":") local-part)))
   (_ name)))
 
   (define (doctype-continuation seed)
@@ -150,12 +157,21 @@ port."
(let ((seed (if trim-whitespace?
(ssax:reverse-collect-str-drop-ws seed)
(ssax:reverse-collect-str seed)))
- (attrs (attlist-fold
- (lambda (attr accum)
-   (cons (list (name->sxml (car attr)) (cdr attr))
- accum))
- '() attributes)))
- (acons (name->sxml elem-gi)
+ (attrs (append
+ ;; Namespace declarations
+ (filter-map (match-lambda
+   (('*DEFAULT* . _) #f)
+   ((abbrev uri . _)
+(list (symbol-append 'xmlns: abbrev)
+  (symbol->string uri
+ namespaces)
+ (attlist-fold
+  (lambda (attr accum)
+(cons (list (name->sxml (car attr) namespaces)
+(cdr attr))
+  accum))
+  '() attributes
+ (acons (name->sxml elem-gi namespaces)
 (if (null? attrs)
 seed
 (cons (cons '@ attrs) seed))
-- 
2.20.1


It’s quite verbose because it doesn’t check if a namespace declaration
is the same in a parent.

--
Ricardo

bug#20339: sxml simple: sxml->xml mishandles namespaces?

[Ricardo Wurmus]

Hi John,

> The trouble with that is that XML rnamespaces are lexically scoped, like
> Scheme
> local variables.  It is perfectly valid to map a prefix to more than one
> URL,
> as long as the namespace declarations are in either disjoint or nested
> elements.  So you don't know what the absolute name of the element
> or attribute is from just the prefix and the local part.
>
> Furthermore, it is also legal to define more than one prefix for
> the same URL, in which case names using either prefix are normally
> treated as equivalent (however, you can't have elements like
> ...
> even if a and b map to the same namespace).
>
> * Is the value for “namespaces” that’s passed in to the
>>   FINISH-ELEMENT procedure always the same?
>>
>> * Will the second return value of the final call to FINISH-ELEMENT
>>   really always be the complete list of *all* namespaces that have been
>>   encountered?
>>
>
> Definitely not, only the namespaces that are currently in scope.

Thanks for the clarifications!

In that case we coud have FINISH-ELEMENT add all namespace declarations
that are in scope to the current node that is about to be returned.  It
would be a little verbose, but more correct.

What do you think?

-- 
Ricardo

bug#20339: sxml simple: sxml->xml mishandles namespaces?

[Ricardo Wurmus]

Hello!

I just looked at this again and I think I came with something useful.
Here’s some context:

Andy Wingo  writes:

> Hi :)
>
> On Wed 13 Jul 2016 15:24, to...@tuxteam.de writes:
>
>> Referring to Oleg Kiseliov's paper [1], there are actually three
>> things involved:
>
> This summary is helpful, thanks.
>> What is missing? From my point of view:
>>
>>  - At xml->sxml time, the user doesn't know which namespaces
>>are in the xml. So it would be nice if the XML parser
>>could provide that.
>
> For some documents you do know, of course.
>
> And for larger perspective, I think that SSAX gives you all the tools
> you need to build specialist and very flexible XML parsers.  So to an
> extent solving the general problem isn't necessary -- we can always
> point people to SSAX.  But that's a bit rude ;) so if there are common
> patterns we should try to capture them in xml->sxml.  I see this bug as
> being a search for those patterns, but without the requirement of
> solving the problem in its most general form.
>
>>  - It would be super-nice if the XML parser could put that
>>into the same nodes it found it, as described in [1]
>>(i.e. in the (*NAMESPACES* ...) pseudo-attribute).
>>This way we wouldn't have a global mapping, but one
>>that resembles the original XML, even with the same
>>prefixes. Less surprises overall. The round trip
>>xml -> sxml -> xml would be (nearly) the identity.
>>
>>With Ricardo's patch it would lump all the namespace
>>declarations up in the top node, which formally is
>>correct, but might scare XML people a bit :-)
>
> ACK.
>
>>  - At sxml->xml time there should be a way to somehow
>>generate prefixex for "new" namespaces. I don't know
>>at the moment how this would work, that depends on
>>how the user is supposed to insert new nodes in the
>>SXML. Does she specify the namespace? Both prefix
>>(aka namespace-id, under my current assumption) *and*
>>namespace? (note that the namespace-id/prefix alone
>>wouldn't be sufficient).
>
> ACK.
>
> What do you think the next step is?  I am happy to wait FWIW, dunno if
> Ricardo has any feelings here.

Attached is a patch that does the requested things.  The parser
procedures like FINISH-ELEMENT have access to all the namespaces, so we
I changed the FINISH-ELEMENT procedure to return the list of namespaces
in addition to its SXML tree return value.

I changed name->sxml to use only the namespace aliases / abbreviations
instead of the namespace URIs.  (This is not very efficient because we
need to traverse the list of namespaces every time.  Maybe we could
memoize this.  On the other hand, the length of the namespaces list may
not be large enough to affect performance too much.)

In the end we get both namespace list and SXML tree from running the
parser.  Before wrapping this up in *TOP* we generate xmlns attributes
for all abbreviations and “patch” the first proper element’s attribute
list (i.e. we skip over a *PI* element if it exists).

The result is an SXML tree that begins with namespace declarations,
mapping abbreviations to URIs.  Within the SXML tree we’re only using
abbreviations, so there are no more invalid characters when converting
SXML to a string.

I would be happy if you could test this as I’m not 100% confident that
this is correct.  Here are questions I wasn’t able to answer
conclusively:

* Is the value for “namespaces” that’s passed in to the
  FINISH-ELEMENT procedure always the same?

* Will the second return value of the final call to FINISH-ELEMENT
  really always be the complete list of *all* namespaces that have been
  encountered?

* Are there valid XML documents for which the match patterns to inject
  namespace declarations would not apply?  (e.g. documents with a PI
  element and two separate XML trees)

--
Ricardo


>From 83ee9de18a0ecaa237eb73e1b75d0b21e3e8d321 Mon Sep 17 00:00:00 2001
From: Ricardo Wurmus 
Date: Mon, 4 Feb 2019 21:39:06 +0100
Subject: [PATCH] sxml: xml->sxml: Record and use namespace abbreviations.

* module/sxml/simple.scm (xml->sxml): Add namespace declarations to the
attribute list of the first XML element.
[name->sxml]: Accept namespaces argument to look up abbreviation.
Return name with abbreviation prefix.
[parser]: Let FINISH-ELEMENT procedure return namespaces in addition to
SXML tree.
---
 module/sxml/simple.scm | 50 +-
 1 file changed, 40 insertions(+), 10 deletions(-)

diff --git a/module/sxml/simple.scm b/module/sxml/simple.scm
index 703ad9137..52dd9af12 100644
--- a/module/sxml/simple.scm
+++ b/module/sxml/simple.scm
@@ -1,7 +1,8 @@
  (sxml simple) -- a simple interface to the SSAX parser
 
-

bug#32677: Installation of guile-debbugs fails

[Ricardo Wurmus]

Arun Isaac  writes:

>> --8<---cut here---start->8---
>> detlef:~/src/guile-debbugs> ./configure
>> checking for a BSD-compatible install... /usr/bin/install -c
>> checking whether build environment is sane... yes
>> checking for a thread-safe mkdir -p... /bin/mkdir -p
>> checking for gawk... gawk
>> checking whether make sets $(MAKE)... yes
>> checking whether make supports nested variables... yes
>> checking whether make supports nested variables... (cached) yes
>> ./configure: line 2364: syntax error near unexpected token `2.2'
>> ./configure: line 2364: `GUILE_PKG(2.2)'
>> --8<---cut here---end--->8---
>
> A minor update. I was able to reproduce this problem in a Guix
> environment. If I install guile in the environment, this problem does
> not manifest. If I don't have guile in the environment, this problem
> manifests.
>
> In other words, with
>
> guix environment --ad-hoc guile autoconf automake pkg-config
>
> this problem does not manifest. But, with
>
> guix environment --ad-hoc autoconf automake pkg-config
>
> this problem manifests. I have no idea why this is the case, but perhaps
> this could be a lead worth investigating.

The macros (such as GUILE_PKK) are provided by the Guile package, so I
think that’s expected.

--
Ricardo

bug#32677: Installation of guile-debbugs fails

[Ricardo Wurmus]

Hi Michael,

thanks for taking a look at guile-debbugs!

> Arun Isaac  writes:
>
>>> [albinus@BRONB4NHFYN1 guile-debbugs]$ ./configure
>>> checking for a BSD-compatible install... /usr/bin/install -c
>>> checking whether build environment is sane... yes
>>> checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
>>> checking for gawk... gawk
>>> checking whether make sets $(MAKE)... yes
>>> checking whether make supports nested variables... yes
>>> checking whether make supports nested variables... (cached) yes
>>> ./configure: line 2352: syntax error near unexpected token `2.2'
>>> ./configure: line 2352: `GUILE_PKG(2.2)'
>>
>> ./configure has failed. I think you are missing guile-2.2. Could you try
>> again with guile installed?
>
> --8<---cut here---start->8---
> [albinus@BRONB4NHFYN1 ~]$ which guile
> /usr/bin/guile
> [albinus@BRONB4NHFYN1 ~]$ guile --version
> guile (GNU Guile) 2.0.14
> --8<---cut here---end--->8---
>
> Furthermore, a syntax error seems to tell something different. If it is
> really true that guile 2.2 is missing, I would expect a respective error
> message.

Do you have pkg-config installed?  GUILE_PKG is a macro that depends on
macros provided by pkg-config.

--
Ricardo

bug#32528: http-post breaks with XML response payload containing boundary

[Ricardo Wurmus]

Hi Mark,

> Ricardo Wurmus  writes:
>
[…]
>> The reason why it fails is that Guile processes the response and treats
>> the *payload* contained in the XML response as HTTP.
>
> No, this was a good guess, but it's not actually the problem.

You are right.  I also ended up trying with “wget --save-headers” after
sending the bug report and noticed the offending header like you did:

>   Content-Type: multipart/related; type="text/xml"; start=""; 
> boundary="=-=-="
>
>The problem is simply that our Content-Type header parser is broken.
> It's very simplistic and merely splits the string wherever ';' is found,
> and then checks to make sure there's only one '=' in each parameter,
> without taking into account that quoted strings in the parameters might
> include those characters.

Right.  I worked around this in guile-debbugs simply by replacing the
Content-Type header parser with one that lacks the check for the unique
“=” in the string part.

> I'll work on a proper parser for Content-Type headers.

Thanks!

--
Ricardo

bug#32528: http-post breaks with XML response payload containing boundary

[Ricardo Wurmus]

Hi Guilers,

I’m having a problem with http-post and I think it might be a bug.  I’m
talking to a Debbugs SOAP service over HTTP by sending (via POST) an XML
request.  The Debbugs SOAP service responds with a string of XML.

Here’s a simplified version of what I do:

  (use-module (web http))
  (let ((req-xml ""))
(receive (response body)
(http-post uri
   #:body req-xml
   #:headers
   `((content-type . (text/xml))
 (content-length . ,(string-length req-xml
 ;; Do something with the response body
 (xml->sxml body #:trim-whitespace? #t)))

This fails for some requests with an error like this:

web/http.scm:1609:23: Bad Content-Type header: multipart/related; 
type="text/xml"; start=""; boundary="=-=-="

Here’s a backtrace:

--8<---cut here---start->8---
In debbugs/soap.scm:
101:8  9 (soap-invoke "https://debbugs.gnu.org/cgi/soap.cgi; _ . _)
In web/client.scm:
   386:24  8 (http-request _ #:body _ #:port _ #:method _ #:version _ 
#:keep-alive? _ #:headers _ #:decode-body? _ #:streaming? _ #:request _)
In web/response.scm:
   200:48  7 (read-response #)
In web/http.scm:
   225:33  6 (read-headers #)
   195:11  5 (read-header #)
  1606:12  4 (_ "multipart/related; type=\"text/xml\"; 
start=\"\"; boundary=\"=-=-=\"")
In ice-9/boot-9.scm:
   222:29  3 (map1 (" type=\"text/xml\"" " start=\"\"" " 
boundary=\"=-=-=\""))
   222:29  2 (map1 (" start=\"\"" " boundary=\"=-=-=\""))
   222:17  1 (map1 (" boundary=\"=-=-=\""))
In web/http.scm:
  1609:23  0 (_ " boundary=\"=-=-=\"")
--8<---cut here---end--->8---

The reason why it fails is that Guile processes the response and treats
the *payload* contained in the XML response as HTTP.  In this case it
processes the response and stumbles upon a multipart email that contains
a Content-type header specifying a boundary string.

The Content-type handler in (web http) doesn’t like that the boundary
string contains “=” and aborts.

The point is, though, that it shouldn’t even try to parse the payload of
the XML response.  If you want to see the full XML response you can use
wget:

wget --post-data="http://schemas.xmlsoap.org/soap/envelope/\; 
xmlns:xsi=\"http://www.w3.org/1999/XMLSchema-instance\; 
xmlns:xsd=\"http://www.w3.org/1999/XMLSchema\; 
xmlns:soapenc=\"http://schemas.xmlsoap.org/soap/encoding/\; 
soapenc:encodingStyle=\"http://schemas.xmlsoap.org/soap/encoding/\;>http://schemas.xmlsoap.org/soap/encoding/\;>32514"
 --header "Content-type: text/xml" -qO - "https://debbugs.gnu.org/cgi/soap.cgi;

Is this a problem with Guile when a response with Content-type text/xml
is received?

--
Ricardo

bug#30094: [wishlist] better support for alternative languages

[Ricardo Wurmus]

Hi Guilers,

since Guile supports alternative language implementations like Wisp it
would be nice if it could interpret files that contain code written in
other languages, without having to specially cater to them.

If GUILE_LOAD_PATH contains a file “foo.wisp” written in Wisp it would
be nice if Guile would automatically read it with the Wisp language.

The same applies to “load”, which only supports Scheme code.

Another idea might be to adopt the “#lang” macro from Racket to inform
Guile about the language that is used in the current file.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

bug#19180: Weak tables harmful to GC?

[Ricardo Wurmus]

Hi again,

previously I wrote:

> The “guile-awesome” package finished compiling (after about 46 minutes).
> I’m now testing “guix pull” with a version of Guix that uses
> “guile-awesome”.

I’m sure I’m doing something wrong (see below for guesses).  Here’s what
I get:

--8<---cut here---start->8---
./pre-inst-env guix pull
loading...   26.0% of 645 filesrandom seed for tests: 1509382171
compiling... 18.9% of 645 filesIn thread:
ERROR: In procedure return: return used outside of 'with-monad'Error while 
printing exception.
compiling... 54.7% of 645 files^C
--8<---cut here---end--->8---

I modified build-self.scm to use the modified Guile:

--8<---cut here---start->8---
diff --git a/build-aux/build-self.scm b/build-aux/build-self.scm
index ed8ff5f..9af6504 100644
--- a/build-aux/build-self.scm
+++ b/build-aux/build-self.scm
@@ -126,7 +126,7 @@ running Guile."
   (package->derivation (cond-expand
  (guile-2.2
   (canonical-package
-   (specification->package "guile@2.2")))
+   (specification->package "guile-awesome@2.2")))
  (else
   (canonical-package
(specification->package "guile@2.0"))
--8<---cut here---end--->8---

I also confirmed that the Guile process that is spawned as “bin/guile
--no-auto-compile /home/rwurmus/guix/scripts/guix pull” is indeed the
modified Guile, but I noticed that it spawns yet another Guile process
to load and compile Guix.

I guess that comes from the daemon?  If that’s the case I can’t really
test this on this big server, because the daemon is currently in use, so
I can’t just reconfigure it to use the modified Guile.

When compiling Guix from source with “make -j 32” using that version of
Guile I got a segfault.

--
Ricardo

bug#19180: Weak tables harmful to GC?

[Ricardo Wurmus]

Hi Ludo,

> I’m attaching updated patches.  I’ve let the Guix build run to
> completion this time.  Let me know if it works for you!

The “guile-awesome” package finished compiling (after about 46 minutes).
I’m now testing “guix pull” with a version of Guix that uses
“guile-awesome”.

I’m very hopeful :)

--
Ricardo

bug#19180: Weak tables harmful to GC?

[Ricardo Wurmus]

Hi Ludo,

the bootstrap phase now succeeds but the build crashes:

--8<---cut here---start->8---
…
make[2]: Leaving directory 
'/tmp/guix-build-guile-awesome-2.2.2.drv-0/guile-2.2.2/bootstrap'
Making all in module
make[2]: Entering directory 
'/tmp/guix-build-guile-awesome-2.2.2.drv-0/guile-2.2.2/module'
…
wrote `language/tree-il/spec.go'
  GUILEC srfi/srfi-37.go
wrote `ice-9/textual-ports.go'
wrote `ice-9/time.go'
wrote `ice-9/q.go'
  GUILEC srfi/srfi-38.go
wrote `ice-9/hash-table.go'
wrote `rnrs/r5rs.go'
Backtrace:
In ice-9/eval.scm:
163:9 19 (_ _)
In ice-9/boot-9.scm:
152:2 18 (with-fluid* _ _ _)
In system/base/target.scm:
 57:6 17 (with-target _ _)
In system/base/compile.scm:
152:6 16 (compile-file _ #:output-file _ #:from _ #:to _ #:env _ ?)
 43:4 15 (call-once _)
In ice-9/boot-9.scm:
849:4 14 (with-throw-handler _ _ _)
In system/base/compile.scm:
59:11 13 (_)
   155:11 12 (_ #)
219:8 11 (read-and-compile _ #:from _ #:to _ #:env _ #:opts _)
255:6 10 (compile _ #:from _ #:to _ #:env _ #:opts _)
   183:32  9 (lp (# #) ?)
In language/tree-il/compile-cps.scm:
  1084:25  8 (compile-cps # ?)
974:4  7 (optimize-tree-il # ?)
In language/tree-il/analyze.scm:
563:4  6 (analyze-tree (#< down: # ?) ?)
In srfi/srfi-1.scm:
   656:11  5 (for-each2 (#< down: # ?) ?)
In ice-9/vlist.scm:
   267:16  4 (loop _ _ _)
In language/tree-il/analyze.scm:
  1053:33  3 Exception thrown while printing backtrace:
ERROR: In procedure assq: Wrong type argument in position 2 (expecting 
association list): ((system base pmatch) car . #f)

ice-9/boot-9.scm:760:25: In procedure dispatch-exception:
ice-9/boot-9.scm:760:25: In procedure assq: Wrong type argument in position 2 
(expecting association list): ((system base pmatch) car . #f)
make[2]: *** [Makefile:2258: rnrs/records/procedural.go] Error 1
make[2]: *** Waiting for unfinished jobs
  GUILEC srfi/srfi-41.go
wrote `rnrs/programs.go'
wrote `ice-9/history.go'
wrote `language/elisp/spec.go'
wrote `language/tree-il/optimize.go'
Backtrace:
In ice-9/eval.scm:
163:9 19 (_ _)
In ice-9/boot-9.scm:
152:2 18 (with-fluid* _ _ _)
In system/base/target.scm:
 57:6 17 (with-target _ _)
In system/base/compile.scm:
152:6 16 (compile-file _ #:output-file _ #:from _ #:to _ #:env _ ?)
 43:4 15 (call-once _)
In ice-9/boot-9.scm:
849:4 14 (with-throw-handler _ _ _)
In system/base/compile.scm:
59:11 13 (_)
   155:11 12 (_ #)
219:8 11 (read-and-compile _ #:from _ #:to _ #:env _ #:opts _)
255:6 10 (compile _ #:from _ #:to _ #:env _ #:opts _)
   183:32  9 (lp (# #) ?)
In language/tree-il/compile-cps.scm:
  1084:25  8 (compile-cps _ # _)
974:4  7 (optimize-tree-il # ?)
In language/tree-il/analyze.scm:
563:4  6 (analyze-tree (#< down: # ?) ?)
In srfi/srfi-1.scm:
   656:11  5 (for-each2 (#< down: # ?) ?)
In ice-9/vlist.scm:
   267:16  4 (loop _ _ #t)
In language/tree-il/analyze.scm:
  1053:33  3 Exception thrown while printing backtrace:
ERROR: In procedure assq: Wrong type argument in position 2 (expecting 
association list): 36
wrote `rnrs/unicode.go'

ice-9/boot-9.scm:760:25: In procedure dispatch-exception:
ice-9/boot-9.scm:760:25: In procedure assq: Wrong type argument in position 2 
(expecting association list): 36
wrote `ice-9/curried-definitions.go'
make[2]: *** [Makefile:2258: ice-9/eval.go] Error 1
…
--8<---cut here---end--->8---

This is on the machine with 1.5TB RAM with the same package definition
but using your new patches.

[I’m sending this from my work address, because zoho.com currently has
problems delivering mail to gnu.org.]

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

bug#19180: Weak tables harmful to GC?

[Ricardo Wurmus]

Hi again,

I tried building this on my workstation with 32GB RAM and the bootstrap
compilation got killed after consuming too much memory.

--8<---cut here---start->8---
…
Making all in bootstrap
make[2]: Entering directory 
'/tmp/guix-build-guile-awesome-2.2.2.drv-0/guile-2.2.2/bootstrap'
  BOOTSTRAP GUILEC ice-9/eval.go
wrote `ice-9/eval.go'
  BOOTSTRAP GUILEC ice-9/psyntax-pp.go
  BOOTSTRAP GUILEC language/cps/intmap.go
  BOOTSTRAP GUILEC language/cps/intset.go
  BOOTSTRAP GUILEC language/cps/utils.go
  BOOTSTRAP GUILEC ice-9/vlist.go
  BOOTSTRAP GUILEC srfi/srfi-1.go
  BOOTSTRAP GUILEC language/tree-il.go
  BOOTSTRAP GUILEC language/tree-il/analyze.go
  BOOTSTRAP GUILEC language/tree-il/compile-cps.go
  BOOTSTRAP GUILEC language/tree-il/canonicalize.go
  BOOTSTRAP GUILEC language/tree-il/debug.go
  BOOTSTRAP GUILEC language/tree-il/effects.go
  BOOTSTRAP GUILEC language/tree-il/fix-letrec.go
  BOOTSTRAP GUILEC language/tree-il/optimize.go
  BOOTSTRAP GUILEC language/tree-il/peval.go
  BOOTSTRAP GUILEC language/tree-il/primitives.go
/gnu/store/kpxi8h3669afr9r1bgvaf9ij3y4wdyyn-bash-minimal-4.4.12/bin/bash: line 
6: 30173 Killed  GUILE_AUTO_COMPILE=0 ../meta/build-env guild 
compile --target="x86_64-unknown-linux-gnu" -O1 -L 
"/tmp/guix-build-guile-awesome-2.2.2.drv-0/guile-2.2.2/module" -L 
"/tmp/guix-build-guile-awesome-2.2.2.drv-0/guile-2.2.2/guile-readline" -o 
"ice-9/vlist.go" "../module/ice-9/vlist.scm"
make[2]: *** [Makefile:1928: ice-9/vlist.go] Error 137
make[2]: *** Waiting for unfinished jobs
…
--8<---cut here---end--->8---

This is still with the same Guix package definition as before:

--8<---cut here---start->8---
(define-public guile-2.2-awesome
  (package (inherit guile-2.2)
(name "guile-awesome")
(source (origin (inherit (package-source guile-2.2))
   (patches (list 
"/home/rwurmus/0001-Remove-weak-tables-and-revert-to-weak-hash-tables.patch"
  
"/home/rwurmus/0002-Keep-weak-hash-table-item-count-consistent.patch"
(arguments
  (substitute-keyword-arguments (package-arguments guile-2.2)
((#:phases phases)
 `(modify-phases ,phases
(add-before 'pre-configure 'bootstrap
  (lambda _
(zero? (system* "autoreconf" "-vif"
(native-inputs
 `(("autoconf" ,autoconf)
   ("automake" ,automake)
   ("libtool" ,libtool)
   ("flex" ,flex)
   ("texinfo" ,texinfo)
   ("gettext" ,gettext-minimal)
   ,@(package-native-inputs guile-2.2)
--8<---cut here---end--->8---


--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

bug#19180: Weak tables harmful to GC?

[Ricardo Wurmus]

Hi Ludo,

I tried building Guile with the following Guix package definition:

--8<---cut here---start->8---
(define-public guile-2.2-awesome
  (package (inherit guile-2.2)
(name "guile-awesome")
(source (origin (inherit (package-source guile-2.2))
   (patches (list 
"/home/rwurmus/0001-Remove-weak-tables-and-revert-to-weak-hash-tables.patch"
  
"/home/rwurmus/0002-Keep-weak-hash-table-item-count-consistent.patch"
(arguments
  (substitute-keyword-arguments (package-arguments guile-2.2)
((#:phases phases)
 `(modify-phases ,phases
(add-before 'pre-configure 'bootstrap
  (lambda _
(zero? (system* "autoreconf" "-vif"
(native-inputs
 `(("autoconf" ,autoconf)
   ("automake" ,automake)
   ("libtool" ,libtool)
   ("flex" ,flex)
   ("texinfo" ,texinfo)
   ("gettext" ,gettext-minimal)
   ,@(package-native-inputs guile-2.2)
--8<---cut here---end--->8---

Unfortunately, I cannot bootstrap Guile on this 1.5 TB RAM server:

--8<---cut here---start->8---
…
  BOOTSTRAP GUILEC system/vm/program.go
  BOOTSTRAP GUILEC system/vm/vm.go
  BOOTSTRAP GUILEC system/foreign.go
GC Warning: Repeated allocation of very large block (appr. size 230096896):
May lead to memory leak and poor performance
GC Warning: Repeated allocation of very large block (appr. size 230096896):
May lead to memory leak and poor performance
GC Warning: Repeated allocation of very large block (appr. size 230096896):
May lead to memory leak and poor performance
GC Warning: Repeated allocation of very large block (appr. size 230096896):
May lead to memory leak and poor performance
GC Warning: Repeated allocation of very large block (appr. size 230096896):
May lead to memory leak and poor performance
GC Warning: Repeated allocation of very large block (appr. size 230096896):
May lead to memory leak and poor performance
GC Warning: Repeated allocation of very large block (appr. size 230096896):
May lead to memory leak and poor performance
Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS
/gnu/store/kpxi8h3669afr9r1bgvaf9ij3y4wdyyn-bash-minimal-4.4.12/bin/bash: line 
6: 30796 Aborted GUILE_AUTO_COMPILE=0 ../meta/build-env guild 
compile --target="x86_64-unknown-linux-gnu" -O1 -L 
"/tmp/guix-build-guile-awesome-2.2.2.drv-0/guile-2.2.2/module" -L 
"/tmp/guix-build-guile-awesome-2.2.2.drv-0/guile-2.2.2/guile-readline" -o 
"language/scheme/compile-tree-il.go" 
"../module/language/scheme/compile-tree-il.scm"
make[2]: *** [Makefile:1928: language/scheme/compile-tree-il.go] Error 134
make[2]: *** Waiting for unfinished jobs
^GGC Warning: Repeated allocation of very large block (appr. size 230096896):
May lead to memory leak and poor performance
Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS
/gnu/store/kpxi8h3669afr9r1bgvaf9ij3y4wdyyn-bash-minimal-4.4.12/bin/bash: line 
6: 30386 Aborted GUILE_AUTO_COMPILE=0 ../meta/build-env guild 
compile --target="x86_64-unknown-linux-gnu" -O1 -L 
"/tmp/guix-build-guile-awesome-2.2.2.drv-0/guile-2.2.2/module" -L 
"/tmp/guix-build-guile-awesome-2.2.2.drv-0/guile-2.2.2/guile-readline" -o 
"language/tree-il/fix-letrec.go" "../module/language/tree-il/fix-letrec.scm"
make[2]: *** [Makefile:1928: language/tree-il/fix-letrec.go] Error 134
GC Warning: Repeated allocation of very large block (appr. size 230096896):
May lead to memory leak and poor performance
GC Warning: Repeated allocation of very large block (appr. size 230096896):
May lead to memory leak and poor performance
Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS
Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS
/gnu/store/kpxi8h3669afr9r1bgvaf9ij3y4wdyyn-bash-minimal-4.4.12/bin/bash: line 
6: 30839 Aborted GUILE_AUTO_COMPILE=0 ../meta/build-env guild 
compile --target="x86_64-unknown-linux-gnu" -O1 -L 
"/tmp/guix-build-guile-awesome-2.2.2.drv-0/guile-2.2.2/module" -L 
"/tmp/guix-build-guile-awesome-2.2.2.drv-0/guile-2.2.2/guile-readline" -o 
"language/value/spec.go" "../module/language/value/spec.scm"
make[2]: *** [Makefile:1928: language/value/spec.go] Error 134
/gnu/store/kpxi8h3669afr9r1bgvaf9ij3y4wdyyn-bash-minimal-4.4.12/bin/bash: line 
6: 30917 Aborted GUILE_AUTO_COMPILE=0 ../meta/build-env guild 
compile --target="x86_64-unknown-linux-gnu" -O1 -L 
"/tmp/guix-build-guile-awesome-2.2.2.drv-0/guile-2.2.2/module" -L 
"/tmp/guix-build-guile-awesome-2.2.2.drv-0/guile-2.2.2/guile-readline" -o 
"system/base/syntax.go" "../module/system/base/syntax.scm"
make[2]: *** [Makefile:1928: system/base/syntax.go] Error 134
GC Warning: Repeated allocation of very large block (appr. size 230096896):
May lead to memory leak and poor performance
Too 

bug#19180: Weak tables harmful to GC?

[Ricardo Wurmus]

[resending this because it may not have arrived]

Ricardo Wurmus <rek...@elephly.net> writes:

> Hi Ludo,
>
> does this apply to the latest release of Guile 2.2.2?  I’ve created this
> package definition:
>
> --8<---cut here---start->8---
> (define-public guile-2.2-awesome
>   (package (inherit guile-2.2)
> (name "guile-awesome")
> (source (origin (inherit (package-source guile-2.2))
>(patches (list 
> "0001-Remove-weak-tables-and-revert-to-weak-hash-tables.patch"
>   
> "0002-Keep-weak-hash-table-item-count-consistent.patch"))
>
> --8<---cut here---end--->8---
>
> But the build fails:
>
> --8<---cut here---start->8---
> In file included from weak-table.c:37:0:
> ../libguile/weak-table.h:34:3: error: redeclaration of enumerator 
> 'SCM_WEAK_TABLE_KIND_KEY'
>SCM_WEAK_TABLE_KIND_KEY,
>^
> In file included from ../libguile.h:65:0,
>  from ../libguile/programs.h:22,
>  from ../libguile/_scm.h:85,
>  from weak-table.c:30:
> ../libguile/hashtab.h:36:3: note: previous definition of 
> 'SCM_WEAK_TABLE_KIND_KEY' was here
>SCM_WEAK_TABLE_KIND_KEY = 1,
>^
> In file included from weak-table.c:37:0:
> ../libguile/weak-table.h:35:3: error: redeclaration of enumerator 
> 'SCM_WEAK_TABLE_KIND_VALUE'
>SCM_WEAK_TABLE_KIND_VALUE,
>^
> In file included from ../libguile.h:65:0,
>  from ../libguile/programs.h:22,
>  from ../libguile/_scm.h:85,
>  from weak-table.c:30:
> ../libguile/hashtab.h:37:3: note: previous definition of 
> 'SCM_WEAK_TABLE_KIND_VALUE' was here
>SCM_WEAK_TABLE_KIND_VALUE = 2,
>^
> In file included from weak-table.c:37:0:
> ../libguile/weak-table.h:36:3: error: redeclaration of enumerator 
> 'SCM_WEAK_TABLE_KIND_BOTH'
>SCM_WEAK_TABLE_KIND_BOTH,
>^
> In file included from ../libguile.h:65:0,
>  from ../libguile/programs.h:22,
>  from ../libguile/_scm.h:85,
>  from weak-table.c:30:
> ../libguile/hashtab.h:38:3: note: previous definition of 
> 'SCM_WEAK_TABLE_KIND_BOTH' was here
>SCM_WEAK_TABLE_KIND_BOTH = 1 | 2
>^
> In file included from weak-table.c:37:0:
> ../libguile/weak-table.h:37:3: error: conflicting types for 
> 'scm_t_weak_table_kind'
>  } scm_t_weak_table_kind;
>^
> In file included from ../libguile.h:65:0,
>  from ../libguile/programs.h:22,
>  from ../libguile/_scm.h:85,
>  from weak-table.c:30:
> ../libguile/hashtab.h:39:3: note: previous declaration of 
> 'scm_t_weak_table_kind' was here
>  } scm_t_weak_table_kind;
>^
> In file included from weak-table.c:37:0:
> ../libguile/weak-table.h:46:18: error: conflicting types for 
> 'scm_c_make_weak_table'
>  SCM_INTERNAL SCM scm_c_make_weak_table (unsigned long k,
>   ^
> In file included from ../libguile.h:65:0,
>  from ../libguile/programs.h:22,
>  from ../libguile/_scm.h:85,
>  from weak-table.c:30:
> ../libguile/hashtab.h:179:18: note: previous declaration of 
> 'scm_c_make_weak_table' was here
>  SCM_INTERNAL SCM scm_c_make_weak_table (unsigned long k,
>   ^
> weak-table.c: In function 'make_weak_table':
> weak-table.c:798:20: error: 'scm_tc7_weak_table' undeclared (first use in 
> this function)
>return scm_cell (scm_tc7_weak_table, (scm_t_bits)table);
> ^
> weak-table.c:798:20: note: each undeclared identifier is reported only once 
> for each function it appears in
> weak-table.c: At top level:
> weak-table.c:848:1: error: conflicting types for 'scm_c_make_weak_table'
>  scm_c_make_weak_table (unsigned long k, scm_t_weak_table_kind kind)
>  ^
> In file included from ../libguile.h:65:0,
>  from ../libguile/programs.h:22,
>  from ../libguile/_scm.h:85,
>  from weak-table.c:30:
> ../libguile/hashtab.h:179:18: note: previous declaration of 
> 'scm_c_make_weak_table' was here
>  SCM_INTERNAL SCM scm_c_make_weak_table (unsigned long k,
>   ^
> In file included from ../libguile/_scm.h:81:0,
>  from weak-table.c:30:
> weak-table.c: In function 'scm_weak_table_p':
> weak-table.c:216:47: error: 'scm_tc7_weak_table' undeclared (first use in 
> this function)
>  #define SCM_WEAK_TABLE_P(x) (SCM_HAS_TYP7 (x, scm_tc7_weak_table))
>^
> ../libguile/boo

bug#28295: better error messages: missing closing parenthesis

[Ricardo Wurmus]

A person who does not use paredit can easily create a source file that
does not have matching parentheses.  Loading a broken file currently
produces an error like this:

--8<---cut here---start->8---
$ guile -e '(hello'
ERROR: In procedure read:
ERROR: In procedure scm_i_lreadparen: #:1:7: end of file
--8<---cut here---end--->8---

For new users it is not obvious that this error message means that a
closing parenthesis is missing.

Can the message be improved?

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

bug#23421: parse-rfc-822-date is too strict

[Ricardo Wurmus]

The procedure “parse-rfc-822-date” in the module (web http) is a bit too
strict as it rejects dates in which the hour field is a single digit
without zero-padding.

A date like this will be rejected:

Sun, 06 Nov 1994  8:49:37 GMT

Whereas a date like this is accepted:

Sun, 06 Nov 1994 08:49:37 GMT

The only difference is the leading zero in the timestamp.

Dates like the former are produced by maven (see “Last-Modified”
header):


rwurmus in guix: wget -S  
http://central.maven.org/maven2/org/osgi/org.osgi.core/6.0.0/org.osgi.core-6.0.0-sources.jar
--2016-05-02 11:21:06--  
http://central.maven.org/maven2/org/osgi/org.osgi.core/6.0.0/org.osgi.core-6.0.0-sources.jar
Resolving central.maven.org (central.maven.org)... 185.31.17.209
Connecting to central.maven.org (central.maven.org)|185.31.17.209|:80... 
connected.
HTTP request sent, awaiting response... 
  HTTP/1.1 200 OK
  x-amz-meta-last-modified-epoch: 1406692062000
  ETag: "470145ab68a6738780bd86e1c4b53d4b"
  Content-Type: application/java-archive
  Last-Modified: Wed, 30 Jul 2014  3:47:42 GMT
  X-Checksum-MD5: 470145ab68a6738780bd86e1c4b53d4b
  X-Checksum-SHA1: 347531f45363ed10e222b03231d49bb7df016a4d
  Via: 1.1 varnish
  Fastly-Debug-Digest: 
843a9842225e10fdcdc029bcd46bfe2a74c8b74a8a748e971d9779296cd6405f
  Content-Length: 296717
  Accept-Ranges: bytes
  Date: Mon, 02 May 2016 09:21:06 GMT
  Via: 1.1 varnish
  Age: 185269
  Connection: keep-alive
  X-Served-By: cache-iad2131-IAD, cache-fra1242-FRA
  X-Cache: HIT, HIT
  X-Cache-Hits: 1, 1
  X-Timer: S1462180866.617726,VS0,VE5
Length: 296717 (290K) [application/java-archive]
Saving to: ‘org.osgi.core-6.0.0-sources.jar’

org.osgi.core-6.0.0 100%[=>] 289.76K  --.-KB/s   in 0.08s  

2016-05-02 11:21:06 (3.54 MB/s) - ‘org.osgi.core-6.0.0-sources.jar’ saved 
[296717/296717]


~~ Ricardo

bug#19478: [PATCH] Improve SXPath documentation

[Ricardo Wurmus]

Hi Ludo,

my apologies for not responding to your comments for so long.

 Some superficial comments follow.  I realize some of these may be
 present in the original SXPath source, but it seems best to fix them
 anyway.

 BTW, I think we should add a sentence at the beginning of the “SXPath”
 section saying that the material is taken from the SXPath source by Oleg
 et al.

  mechanically expanded into the full form by simple rewriting rules.  In
 -case of SXPath the corresponding rules are given as comments to a sxpath
 -function, below.  The regression test suite at the end of this file shows
 -a representative sample of SXPaths in both notations, juxtaposed with
 -the corresponding XPath expressions.  Most of the samples are borrowed
 +case of SXPath the corresponding rules are given in the documentation of

 Missing “the” (“In the case of SXPath”.)

Fixed.

 +The regression test suite at the end of the file SXPATH-old.scm shows a

 @file{SXPATH-old.scm}

Ok.

 +representative sample of SXPaths in both notations, juxtaposed with the
 +corresponding XPath expressions.  Most of the samples are borrowed
  literally from the XPath specification, while the others are adjusted
 -for our running example, tree1.
 +for our running example, @code{tree1}.

 The issue was already there, but apparently ‘tree1’ is not used
 elsewhere in the documentation.  Perhaps it’s best to remove it?

I removed the last sentence as it doesn’t make any sense unless the
example is added to the documentation.  Maybe I’ll add additional
examples in a later patch.

 +@subsubsection Basic converters and applicators

 Capital C and capital A.

Oh, I forgot that the default is American English.  I also changed the
other headings I added.

 +A converter is a function mapping a nodeset (or a single node) to another
 +nodeset.  Its type can be represented like this:
 +
 +@smallexample
 +  type Converter = Node|Nodeset - Nodeset
 +@end smallexample

 Rather @example (@smallexample means small typeface) and no space before
 ‘type’ (same for the other examples below.)

Good to know.  I fixed all of these type summaries to use “@example” and
without indentation.

  @deffn {Scheme Procedure} node-typeof? crit
 +This function implements a 'Node test' as defined in Sec. 2.3 of XPath
 +document.  A node test is one of the components of a location step.  It

 Missing “the” (“of the XPath document”.)

Added.

 +Combinators are higher-order functions that transmogrify a converter or
 +glue a sequence of converters into a single, non-trivial converter.  The
 +goal is to arrive at converters that correspond to XPath location paths.
 +
 +From a different point of view, a combinator is a fixed, named
 +@emph{pattern} of applying converters.  Given below is a complete set of

 When introducing a term, use @dfn; so @dfn{pattern}.

Okay.

 +@smallexample
 +(define (node-closure f)
 + (node-or
 +   (select-kids f)
 +   (node-reduce (select-kids (node-typeof? '*)) (node-closure f

 Align below the ‘e’ of ‘define’.

Done.

 Could you send an updated patch?

Attached is an updated patch.

After all this time I noticed that even after this patch, the SXPath
documentation is still not clear enough.  I again found myself looking
up the sources to see actual examples.  In a later patch I’d like to add
general examples as well as some examples for specific functions, if
that’s okay.

~~ Ricardo

From 302fd7dd9d293ca1e88a39c255704ccd173caed4 Mon Sep 17 00:00:00 2001
From: Ricardo Wurmus rek...@elephly.net
Date: Sun, 30 Aug 2015 10:58:42 +0200
Subject: [PATCH] doc: Add SXPath documentation from sources

* doc/ref/sxml.texi (SXPath): Add procedure documentation from sources.
---
 doc/ref/sxml.texi | 298 +++---
 1 file changed, 263 insertions(+), 35 deletions(-)

diff --git a/doc/ref/sxml.texi b/doc/ref/sxml.texi
index 75867f3..75ebedc 100644
--- a/doc/ref/sxml.texi
+++ b/doc/ref/sxml.texi
@@ -250,8 +250,8 @@ internal and external parsed entities, user-controlled handling of
 whitespace, and validation.  This module therefore is intended to be a
 framework, a set of ``Lego blocks'' you can use to build a parser
 following any discipline and performing validation to any degree.  As an
-example of the parser construction, this file includes a semi-validating
-SXML parser.
+example of the parser construction, the source file includes a
+semi-validating SXML parser.
 
 SSAX has a ``sequential'' feel of SAX yet a ``functional style'' of DOM.
 Like a SAX parser, the framework scans the document only once and
@@ -725,95 +725,323 @@ location path is a relative path applied to the root node.
 Similarly to XPath, SXPath defines full and abbreviated notations for
 location paths.  In both cases, the abbreviated notation can be
 mechanically expanded into the full form by simple rewriting rules.  In
-case of SXPath the corresponding rules are given as comments to a sxpath
-function, below.  The regression test suite