bug#48368: thanks

[Andy Wingo]

Fixed in 17aab66e75136cf23c7f0d4942b61d6947f98f9b.  Thanks for the
report :)

bug#48368: reduced test case

[Andy Wingo]

Test case:

  (define (f a b)
(let ((c (if (and (eq? a 'foo)
  (eq? b 'bar))
 'ERROR
 a)))
  (pk c)))

If you run as (f 'not-foo 'bar), you get 'ERROR.  Yeeps!

bug#45131: guild fails to compile a Tree-IL file

[Andy Wingo]

Thanks for the patch; applied!

Andy

On Tue 29 Dec 2020 19:09, Leo Prikler  writes:

> This enables the compilation from "manually" written Tree-IL to
> bytecode.  See also .
>
> * system/base/compile.scm (read-and-compile)[(joint #f)]:
> Join exps using the default joiner for to.
> : Compute compiler for to.
> * test-suite/test/compiler.test ("read-and-compile tree-il"): New test.
> ---
>  module/system/base/compile.scm | 26 +++---
>  test-suite/tests/compiler.test | 22 ++
>  2 files changed, 37 insertions(+), 11 deletions(-)
>
> diff --git a/module/system/base/compile.scm b/module/system/base/compile.scm
> index 567765dc0..41ad0158a 100644
> --- a/module/system/base/compile.scm
> +++ b/module/system/base/compile.scm
> @@ -310,16 +310,20 @@
>  (match (read-and-parse (current-language) port cenv)
>((? eof-object?)
> (close-port port)
> -   (compile ((or (language-joiner joint)
> - (default-language-joiner joint))
> - (reverse exps)
> - env)
> -#:from joint #:to to
> -;; env can be false if no expressions were read.
> -#:env (or env (default-environment joint))
> -#:optimization-level optimization-level
> -#:warning-level warning-level
> -#:opts opts))
> +   (if joint
> +   (compile ((or (language-joiner joint)
> + (default-language-joiner joint))
> + (reverse exps)
> + env)
> +#:from joint #:to to
> +;; env can be false if no expressions were read.
> +#:env (or env (default-environment joint))
> +#:optimization-level optimization-level
> +#:warning-level warning-level
> +#:opts opts)
> +   ((default-language-joiner to)
> +(reverse exps)
> +env)))
>(exp
> (let with-compiler ((from from) (compile1 compile1))
>   (cond
> @@ -332,7 +336,7 @@
> (let ((from (current-language)))
>   (with-compiler
>from
> -  (compute-compiler from joint optimization-level
> +  (compute-compiler from (or joint to) optimization-level
>  warning-level opts
>  
>  (define* (compile x #:key
> diff --git a/test-suite/tests/compiler.test b/test-suite/tests/compiler.test
> index dc75d0ac7..cdc26c751 100644
> --- a/test-suite/tests/compiler.test
> +++ b/test-suite/tests/compiler.test
> @@ -337,3 +337,25 @@
>(pass-if-equal "test terminates without error" 42
>  (test-proc)))
>  
> +(with-test-prefix "read-and-compile tree-il"
> +  (let ((code
> + "\
> +(seq
> +  (define forty-two
> +(lambda ((name . forty-two))
> +(lambda-case ((() #f #f #f () ()) (const 42)
> +  (toplevel forty-two))")
> +(bytecode #f)
> +(proc #f))
> +(pass-if "compiling tree-il works"
> +  (begin
> +(set! bytecode
> +  (call-with-input-string code
> +(lambda (port)
> +  (read-and-compile port #:from 'tree-il
> +#t))
> +(pass-if "bytecode can be read"
> +  (begin
> +(set! proc ((load-thunk-from-memory bytecode)))
> +(procedure? proc)))
> +(pass-if-equal "proc executes" 42 (proc

bug#47538: ice-9 regex procedures not found when trying to use from r7rs-style defined library

[Andy Wingo]

Hi,

On Thu 01 Apr 2021 09:06, Arvydas Silanskas  
writes:

> foo.scm:
> (define-library (foo)
> (import 
>   (scheme base)
>   (ice-9 regex))
> (export bar)
>
> (begin
>   (define (bar)
> (make-regexp "a"

The issue AFAIU is that make-regexp is part of (guile), and not exported
by (ice-9 regex).  You would need to add (only (guile) make-regexp) to
your import set.  I know it's somewhat terrible but perhaps in the near
future we will be able to replace this regexp support with something
more consistent.

Please reopen if I misunderstood the bug.

Cheers,

Andy

bug#48098: let/ec compilation bug

[Andy Wingo]

Thanks for the report; fixed!

On Thu 29 Apr 2021 12:48, Stefan Israelsson Tampe  
writes:

> Here is an interesting test case that shows that fi we define
> (define-syntax-rule (letec-m f) (let/ec c (f c)))
> (define(letec-f f) (let/ec c (f c)))
>
> we can get two different behaviors with letec-m compiles wrongly. Obviously a 
> bug!
>
> This is important in casy you would like to make a loop macro effectively 
> with a continue directive.

bug#40252: Applied

[Andy Wingo]

Thanks for the report and fix, and apologies for the delay!

Andy

bug#48089: Guile 3.0.6 returns zero-indexed locations for ‘read-error’

[Andy Wingo]

Done :)

On Thu 29 Apr 2021 11:33, Ludovic Courtès  writes:

> Ludovic Courtès  skribis:
>
>> Guile 3.0.6 returns zero-indexed (instead of one-indexed) source code
>> locations for ‘read-error’.  Here’s a 3.0.6/3.0.5 comparison:
>>
>> $ /gnu/store/r2nr74rwhpqg16y1lyi6l0jn3lwx4yyz-guile-3.0.6/bin/guile  <(echo 
>> '(')
>> ice-9/read.scm:126:4: In procedure lp:
>> /dev/fd/63:1:0: unexpected end of input while searching for: )
>> $ guile  <(echo '(')
>> ERROR: In procedure primitive-load:
>> In procedure scm_i_lreadparen: /dev/fd/63:2:1: end of file
>
> Here’s a test case waiting to succeed!  :-)
>
> diff --git a/test-suite/tests/reader.test b/test-suite/tests/reader.test
> index fad531b39..231e69553 100644
> --- a/test-suite/tests/reader.test
> +++ b/test-suite/tests/reader.test
> @@ -212,6 +212,18 @@
>  
>
>  (with-test-prefix "mismatching parentheses"
> +  (pass-if-equal "read-error location"
> +  '("foo.scm:3:1: unexpected end of input while searching for: ~A" #\))
> +(catch 'read-error
> +  (lambda ()
> +;; The missing closing paren error should be located on line 3,
> +;; column 1 (one-indexed).
> +(call-with-input-string "\n(hi there!\n"
> +  (lambda (port)
> +(set-port-filename! port "foo.scm")
> +(read port
> +  (lambda (key proc message args . _)
> +(cons message args
>(pass-if-exception "opening parenthesis"
>  exception:eof
>  (read-string "("))
>
>
> Ludo’.

bug#48096: [3.0.6] ‘syntax-error’ exceptions include vectors instead of source location properties

[Andy Wingo]

Done!

On Thu 29 Apr 2021 11:41, Ludovic Courtès  writes:

> Hi!
>
> In 3.0.6, a slight incompatibility crept in: ‘syntax-error’ exceptions
> include vectors like #("example.scm" 1 2) instead of good’ol source
> property alists.
>
> Here is a test case that reproduces the problem:
>
> diff --git a/test-suite/tests/syntax.test b/test-suite/tests/syntax.test
> index 10bc7b080..c60a453aa 100644
> --- a/test-suite/tests/syntax.test
> +++ b/test-suite/tests/syntax.test
> @@ -1,7 +1,7 @@
>   syntax.test --- test suite for Guile's syntactic forms-*- scheme -*-
>  
>   Copyright (C) 2001, 2003, 2004, 2005, 2006, 2009, 2010,
> -   2011, 2012, 2013, 2014 Free Software Foundation, Inc.
> +   2011, 2012, 2013, 2014, 2021 Free Software Foundation, Inc.
>  
>   This library is free software; you can redistribute it and/or
>   modify it under the terms of the GNU Lesser General Public
> @@ -112,6 +112,18 @@
>  
>(with-test-prefix "Bad argument list"
>  
> +(pass-if-equal "syntax-error location"
> +'((line . 1) (column . 2) (filename . "example.scm"))
> +  (catch 'syntax-error
> +(lambda ()
> +  (eval (call-with-input-string "\n  (let foo bar)"
> +  (lambda (port)
> +(set-port-filename! port "example.scm")
> +(read port)))
> +(interaction-environment)))
> +(lambda (key proc message properties form subform . rest)
> +  properties)))
> +
>  (pass-if-syntax-error "improper argument list of length 1"
>exception:generic-syncase-error
>(eval '(let ((foo (lambda (x y) #t)))
>
>
> Ludo’.

bug#46175: Redefinable classes clobber custom slot options

[Andy Wingo]

On Fri 29 Jan 2021 17:43, "Thompson, David"  writes:

> The compute-slots method for  does a transformation
> of #:allocation #:instance slots to #:allocation #:virtual slots, but
> in doing so it discards all slot options besides the standard ones.
> This means that a metaclass that inherits from 
> won't work as expected if it relies upon custom slot options.

Thanks for the report; patch applied!

Andy

bug#41131: Bug in hash-table-merge! (and patch)

[Andy Wingo]

Applied, thanks!

On Fri 08 May 2020 01:50, "Ricardo G. Herdt"  writes:

> Hi,
>
> I just found this bug in the hash-table-merge! function
> (modul/srfi/srfi-69.scm). Instead of merging both hash tables, it was 
> ignoring one of them (other-ht). Attached is the fix, where it now folds
> over other-ht and store its data in ht.
>
> Cheers,
>
> Ricardo G. Herdt
>
> From 180a9e14b807295aa31966a52bfd732647458ef9 Mon Sep 17 00:00:00 2001
> From: "Ricardo G. Herdt" 
> Date: Fri, 8 May 2020 01:37:24 +0200
> Subject: [PATCH] Fix hash-table-merge! bug.
>
> * module/srfi/srfi-69.scm : fold over second hash table.
> ---
>  module/srfi/srfi-69.scm | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/module/srfi/srfi-69.scm b/module/srfi/srfi-69.scm
> index b9486c465..91bcc77db 100644
> --- a/module/srfi/srfi-69.scm
> +++ b/module/srfi/srfi-69.scm
> @@ -330,7 +330,7 @@ Answer the final F result."
>"Add all key/value pairs from OTHER-HT to HT, overriding HT's
>  mappings where present.  Return HT."
>(hash-table-fold
> -   ht (lambda (k v ign) (hash-table-set! ht k v)) #f)
> +   other-ht (lambda (k v ign) (hash-table-set! ht k v)) #f)
>ht)
>  
>  ;;; srfi-69.scm ends here

bug#40371: [R7RS] Guile does not accept library name parts that are non-negative exact integers

[Andy Wingo]

In the concrete case of the SRFI modules, importing e.g. (srfi 9) works
AFAIU.  Does this not work for you?

I think that allowing numbers as module name components, beyond the SRFI
modules, is not currently a good idea for Guile.  I had a look at it and
it's a bit too intrusive.

Andy

On Wed 01 Apr 2020 12:47, Marc Nieper-Wißkirchen  writes:

> An R7RS library name consists of parts, where each part is either a symbol or
> a non-negative exact integer. Guile doesn't support the latter ones.
>
> This is unfortunate as the implementation of a SRFI NNN is usually delivered
> in form of a library named (srfi NNN).
>
> When this is corrected, for interoperability, it would be great if Guile 
> offers
> the included SRFIs not only under the name (srfi srfi-NNN) but also under
> (srfi NNN).
>
> Thanks,
>
> Marc

bug#39634: All keyowrds hash to the same value

[Andy Wingo]

On Fri 06 Mar 2020 15:42, Ludovic Courtès  writes:

> Andy Wingo  skribis:
>
>>>   variable,
>>>   hashtable,
>>>   fluid,
>>>   dynamic_state,
>>>   frame,
>>>   atomic_box,
>>>   program,
>>>   vm_cont,
>>>   weak_set,
>>>   weak_table,
>>>   port
>>
>> No equal? implementation, so should hashq() instead.
>
> Here’s a patch for these, let me know what you think!

LGTM!

Andy

bug#39800: gnutls guile bug receiving https data

[Andy Wingo]

Thanks very much for the report!

I think this one may be a good one for Ludovic, if I may be so bold.
Apologies for the top-post but I couldn't clip your excellent report.

Cheers,

Andy

"franco@gmail.com"  writes:

> Hello,
> I installed gnutls for guile and checked the gnutls module with this
> simple code:
>
>
> ;;Guile version 3.0 and gnutls  from git
>
> ,show version
> GNU Guile 3.0.0.15-ff14b7
>
> (gnutls-version)
> $6 = "3.6.12"
>
> ;;Now, submitting this simple https request, you get an exception
> (http-request "https://www.google.com";)
> ice-9/boot-9.scm:1669:16: In procedure raise-exception:
> Throw to key `gnutls-error' with args `(# connessione TLS non è stata terminata in modo corretto.>
> read_from_session_record_port)'.
>
> ;;instead, without https there are no errors
> (http-request "http://www.google.com";) ;;works fine.
>
>
> The error happens only on https://www.google.com and does not throw with
> a lot of other https web sites.
> Furthermore the error is not throw if the method is HEAD, so it is
> related to the data part of the https answer.
> I tried to enter in the internal implementation of the http web client
> but after some tests I decided to do some simple tests at application
> level.
> I rewrote the get-bytevector-all, with a loop that reads one byte per
> time and the error was thrown anyway.
> I catched the error and I've got the complete answer from the google web
> server.
>
> In the following there is my applicative solution, where I rewrote the
> get-bytevector-all by adding the error checking and specifiyng to
> http-request that the data has to be returned as a port (#:streaming?
> #t).
>
>
> ;;A macro to catch errors
> (define-syntax my-noerr
>   (syntax-rules ()
>     ((_ __error-return exp ...)
>  (let
>  ((__st #f))
>    (catch #t
>  (lambda() exp ...)
>  (lambda (k . p) __error-return))
>
> ;;The rewriting of get-bytevector-all
> (defun get-bytevector-all (port)
>   (u8-list->bytevector (let loop ((port port))
>  (let ((v (my-noerr (eof-object) (get-u8 port
>    (if (eof-object? v)
>    #nil
>    (cons v (loop port)))
>
> ;;the piece of code that now gives the correct result
>   (let-values (((a b)(http-request "https://www.google.com"; #:streaming?
> #t)))
>     (bytevector->string (get-bytevector-all b) "ISO-8859-1"))
>
> As conclusion I can say that web modules read correctly the http answers
> and, with some (one for me, the google web site) https sites there is a
> misinterpretation of EOF in the layer between http and https.
>
> Franco.

bug#39811: Missing dynwind exit application

[Andy Wingo]

Stefan Israelsson Tampe  writes:

> Executing this code on guile-3.0.0:
>
> (dynamic-wind
>  (lambda () (pk 'enter))
>  (lambda () (catch #t
>   (lambda () (throw 1))
>   (lambda x (pk 'catch x) (apply throw x
>  (lambda () (pk 'leave)))
>
> Leads to the output:
>
> scheme@(guile-user)> (load "bug.scm") 
> ;;; (enter) 
> ;;; (catch (a)) 
>
> ice-9/boot-9.scm:1669:16: In procedure raise-exception: 
> Throw to key `a' with args `()'. 
>
> What, it does not execute the leave part of the dynamic wind.

That is because the REPL leaves you in the context of where the uncaught
error was thrown.  If you ,quit the REPL to go back to the outer REPL,
it will print "leave" as expected.  Please reopen if I have
misunderstood :)

Cheers,

Andy

bug#39855: PKG_GUILE does not find guile

[Andy Wingo]

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.
>
> Is this deprecated? Should I use something else to check for guile?

OMG I thought I had fixed this; just now pushed a patch.  In the
meantime you can use GUILE_PKG([3.0 2.2]) to look for 3.0 or 2.2 (in
that order).

Thanks for the report!

Andy

bug#39634: All keyowrds hash to the same value

[Andy Wingo]

On Thu 20 Feb 2020 17:19, Ludovic Courtès  writes:

> Of all the scm_tc7_ values listed in ‘scm.h’, the following are not
> explicitly listed (so they go to the default case that hashes the first
> word):

Reformatting your list so I can check one by one :)

>   variable,
>   hashtable,
>   fluid,
>   dynamic_state,
>   frame,
>   atomic_box,
>   program,
>   vm_cont,
>   weak_set,
>   weak_table,
>   port

No equal? implementation, so should hashq() instead.

>   bytevector,
>   array,
>   bitvector,

These have equal? implementations, and what's more, a bitvector can
equal? an array... I think we have another bug!

  ;; Project 2d array as 1d array (scm_tc7_array)
  (define x
(make-shared-array #2b((#t #t #t)) (lambda (i) (list 0 i)) '(0 2)))
  ;; scm_tc7_bitvector
  (define y #*111)

  (equal? x y) ;; => #t
  (equal? (hash x #x) (hash y #x)) ;; => #f

Similarly for 1-d scm_tc7_array versus regular vectors, bytevectors,
etc.

Fixing this will not be straightforward...  I think basically 1d arrays
need some special hashing logic so that e.g. vectors and 1d arrays hash
to the same thing.

>   stringbuf,
>   values,

These are never exposed to Scheme, and never compared using equal?
AFAIU.  No need for special cases.

Basically I think the tc7 case should default to hashq, and include
special cases for the ones that have equal? implementations or which
have read syntax.

Sound right to you?

Andy

bug#39651: /software/guile/docs/ lacks 3.0

[Andy Wingo]

Michael Shigorin  writes:

>   Hello,
> a forum commenter has brought my attention to the fact that
> https://www.gnu.org/software/guile/docs/ page mentions "Preview
> Reference Manual for unreleased Guile 2.2 (development branch)"
> and fails to mention 3.0 completely (even if it's been released
> recently).
>
> So please refer to Sergey if any kind of reference is due :-)

Thanks for the report!  Turns out that page was stale and AFAIU
unreachable; I have garbage-collected it and put in a forwarding pointer
to /learn :)

Cheers,

Andy

bug#39118: Segfault while building on 64-bit Cygwin

[Andy Wingo]

Aah, you all are amazing -- thank you!!  Applied and merged.

Cheers,

Andy

On Mon 17 Feb 2020 20:27, Charles Stanhope  writes:

> On 2/16/20, Charles Stanhope  wrote:
>> On 2/16/20, Mike Gran  wrote:
>>>
>>> I can confirm that Charles's patch, plus another one line patch
>>> to define CPU_SETSIZE, is enough to get Guile 3.0.x to build and run
>>> on my box.  All tests pass except strptime in French, and the absence
>>> of crypt.  This is a 64-bit build.
>>
>> Mike, thanks for going further with the Guile build. The CPU_SETSIZE
>> issue was what was hanging me up from compiling before Andy's comment
>> got me to look at lightening. I assumed I had some configuration,
>> package, or compiler issue. Good to know there's a simple fix.
>>
>> Just a further warning to anyone watching, that patch I posted is a
>> real hack job just to test my theory of the cause of the segfault. I
>> would expect it to fail when you have fewer than four arguments in a
>> JITed function call. I wouldn't try doing much else with that Guile
>> build besides run the tests. :)
>
> I had a little bit more time to look into the lightening
> implementation last night. I've attached a patch that is less horrible
> and more correct than my previous one. It reserves the stack space
> regardless of the number of parameters and appears to work. But I'm
> new to the lightening code base, so I'm not convinced it is the
> correct solution. It's just the solution I was left with after my time
> ran out. I wanted to post this patch as a replacement to the prior one
> in case people did want to do more testing with Guile 3.0 on Cygwin
> x64.
>
> With that, I will let more experienced people come up with the
> appropriate solution. Happy hacking, everybody!
>
> --
> Charles
>
> diff --git a/lightening/x86.c b/lightening/x86.c
> index 965191a..bdd26e1 100644
> --- a/lightening/x86.c
> +++ b/lightening/x86.c
> @@ -328,6 +328,10 @@ reset_abi_arg_iterator(struct abi_arg_iterator *iter, 
> size_t argc,
>memset(iter, 0, sizeof *iter);
>iter->argc = argc;
>iter->args = args;
> +#if __CYGWIN__ && __X64
> +  // Reserve slots on the stack for 4 register parameters (8 bytes each).
> +  iter->stack_size = 32;
> +#endif
>  }
>  
>  static void

bug#39573: [3.0.0] Compiler fails to optimize out side-effect-free expression

[Andy Wingo]

On Wed 12 Feb 2020 12:50, Ludovic Courtès  writes:

> Hello!
>
> Consider this loop:
>
>   (let loop ((n (expt 2 18))
>  (i 1))
> (unless (zero? n)
>   (loop (- n 1)
> (logior 0 (ash i 1)
>
> Guile 2.2 strips away the computation of ‘i’ (it cannot throw, has no
> side effects, and the result is unused):
>
[...]
> L1:
>   27(handle-interrupts)   at (unknown 
> file):21:11
>   28(sub/immediate 4 4 1)   
>   29(br-if-u64-=-scm 3 4 #t -2) ;; -> L1  at (unknown 
> file):18:11

Like specifically, it removes the logior call.

> However, 3.0.0 keeps the computation of ‘i’:
>
[...]
> L3:
>   53(instrument-loop 139)   
>   55(handle-interrupts) 
>   56(call-scm<-scm-uimm 5 5 1 3)  at (unknown 
> file):388:11
>   58(call-scm<-scm-uimm 3 3 1 34) at (unknown 
> file):389:21
>   60(call-scm<-scm-scm 3 4 3 10)  at (unknown 
> file):389:11
>   62(=? 5 4)  at (unknown 
> file):385:11
>   63(jne -10)   ;; -> L3

Hoo, we need to fix the disassembler to output something more sensible
than this :P  IP 56 appears to be the 1-, 58 is the lsh/immediate, and
60 is the logior.

> I’m not sure where the optimization should be taking place.  Perhaps
> it’s just a matter of amount-of-work threshold somewhere?

It's not an amount-of-work, that's only in peval which does nothing to
either of these (though it certainly could).

I took a look.  I just pushed something to make (logior 0 INT) reduce to
INT, but it doesn't remove the loop variable.

Then I thought it was surely dead code elimination that just wasn't
doing its thing.  The value is unused, so it must be that it thought
that the `ash' was effectful.  That `ash' gets compiled to
`lsh/immediate', which does indeed raise an exception if the operand
isn't an int; but here we prove that it is.  The problem was a missing
"type checker" implementation for lsh/immediate, a problem introduced in
the refactored compilation of `ash'.  So, fixed in git now:

L3:
  45(instrument-loop 135)   
  47(handle-interrupts) 
  48(call-scm<-scm-uimm 5 5 1 3)  at (unknown 
file):4:12
  50(=? 5 4)  at (unknown 
file):3:12
  51(jne -6);; -> L3

Cheers,

Andy

bug#39118: Segfault while building on 64-bit Cygwin

[Andy Wingo]

On Mon 20 Jan 2020 18:22, Mike Gran  writes:

> On Mon, Jan 20, 2020 at 11:38:35AM -0500, John Cowan wrote:
>> Yes, gladly, but I don't know how to get one in this context.  Do I need to
>> add some flags to the Makefile, and if so, where?  (It's a twisty maze of
>> passages, all different.) . Note that this *is* a build with JIT enabled;
>> when I disable it using the env variable, there are no errors and 3.0.0
>> works fine.
>> 
>> Also, it may take some time, as I have to rebuild my Windows system.
>
> I also tried building Guile 3.0.0 on Cygwin 3.1.x.  The failure comes from
> trying to parse compiled .go files.
>
> The last time that I had this sort of problem, it was because the
> O_BINARY flag was dropped or missing when writing .go files, leading
> to CR+LF characters in the compiled files.  And I diagnosed it by
> byte-comparing Linux-compiled .go files with Cygwin-compiled .go
> files, and by looking for CR+LF combinations in the compiled .go
> files.
>
> I don't know if that is what is happening here, but, I'll check that
> next time I have a chance.

Given that John said that compilation went fine with
GUILE_JIT_THRESHOLD=-1, I think perhaps this problem may have been fixed
in the past.  My suspicions are that this issue is an ABI issue with
lightening that could perhaps be reproduced by:

  git co https://gitlab.com/wingo/lightening
  cd lightening
  make -C tests test-native

Of course any additional confirmation is useful and welcome!

Cheers,

Andy

bug#36915: make-thread-local-fluid ignores the default value

[Andy Wingo]

On Sun 04 Aug 2019 00:46, Caleb Ristvedt  writes:

> In Guile 2.2.6 as packaged on Guix System (x86-64), the following
> happens:
>
> --
> (define some-fluid (make-thread-local-fluid 42))
>
> (display (fluid-ref some-fluid))
>
> => #f
> --

This is fixed in git, thanks to Rob Browning.

Thanks for the report,

Andy

bug#38263: Bug in srfi-11

[Andy Wingo]

Applied to both branches.  Thanks for the patch and thanks also to Mark
for the review and initial patch!

In the future, Tim, if you have larger patches, we should work out
copyright assignment paperwork.  But less-than-10-line patches are fine
without.  Let me know if this is of interest to you.  Cheers :)

Andy

On Tue 03 Dec 2019 19:15, Tim Gesthuizen via "Bug reports for GUILE, GNU's 
Ubiquitous Extension Language"  writes:

> Hello again,
>
> the attached patch also adds a unit test.
> I am not into how Guile is organized: Is there anything keeping us from
> adding the change?
>
> Tim.
>
> From 99d8fb795932eb92b7d5fb09115b6691f4bfe66d Mon Sep 17 00:00:00 2001
> From: Tim Gesthuizen 
> Date: Tue, 3 Dec 2019 18:50:37 +0100
> Subject: [PATCH] srfi-11: Do not expose variables to later clauses
>
> The current implementation of srfi-11s let-values allows later clauses
> to access and modify variables bound in earlier clauses when the clause
> is not a proper list.
>
> * module/srfi/srfi-11.scm (let-values): Fix switched variable names.
> * test-suite/tests/srfi-11.test (let-values): Add test checking that the
>   variable cannot be changed in later clauses.
> ---
>  module/srfi/srfi-11.scm   | 2 +-
>  test-suite/tests/srfi-11.test | 9 -
>  2 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/module/srfi/srfi-11.scm b/module/srfi/srfi-11.scm
> index 22bda21a2..7afac9c5f 100644
> --- a/module/srfi/srfi-11.scm
> +++ b/module/srfi/srfi-11.scm
> @@ -91,7 +91,7 @@
>  (syntax (call-with-values (lambda () exp)
>(lambda (new-tmp ...) inner))
> ((vars exp)
> -(with-syntax new-tmp . new-var) ...)
> +(with-syntax new-var . new-tmp) ...)
> (let lp ((vars (syntax vars)))
>   (syntax-case vars ()
> ((id . rest)
> diff --git a/test-suite/tests/srfi-11.test b/test-suite/tests/srfi-11.test
> index 40563dc18..9bfaa4300 100644
> --- a/test-suite/tests/srfi-11.test
> +++ b/test-suite/tests/srfi-11.test
> @@ -74,7 +74,14 @@
>   '(unbound-variable . ".*")
>(let-values (((x) (values 1))
>  ((y) (values (1+ x
> - #f
> + #f))
> +
> +(pass-if "first binding with rest invisible to second expr"
> +  (let* ((a 1)
> + (b (let-values (((a . b) (values 2 3))
> + (c (begin (set! a 9) 4)))
> +  (list a b c
> +(equal? (cons a b) '(9 2 (3) (4)))
>  
>  ;;
>  ;; let*-values

bug#38516: [guile-2.9.6] make failed on Solaris x86/x64

[Andy Wingo]

On Sat 07 Dec 2019 01:12, Kiyoshi KANAZAWA  writes:

> Hello,
>
> Trying guile-2.9.6.
> Make fails on Solaris x86/64 with 32 bit mode.
> It does not happen with 64 bit mode.
>
> $ make
>   :
>   CC   libguile_3.0_la-ioext.lo
>   CC   libguile_3.0_la-jit.lo
> jit.c: In function 'compile_s64_to_f64':
> jit.c:4293:27: error: incompatible type for argument 3 of 'emit_sp_ref_s64'
>    emit_sp_ref_s64 (j, T0, src);

Fixed in git.  Thanks for the report!

Andy

bug#38534: fluid-ref doesn't return defaults for thread local fluids

[Andy Wingo]

On Sun 08 Dec 2019 18:41, Rob Browning  writes:

> For example, in 2.2.6:
>
>   scheme@(guile-user)> (define x (make-thread-local-fluid 'default))
>   scheme@(guile-user)> (fluid-ref x)
>   $1 = #f

Applied your patch on both branches; thank you!

Andy

bug#38607: unable to build guile 2.9.7 on OS X 10.14.6

[Andy Wingo]

On Sat 14 Dec 2019 07:16, Aleix Conchillo Flaqué  writes:

>   BOOTSTRAP GUILEC system/vm/linker.go
> /bin/sh: line 1: 69110 Abort trap: 6   GUILE_AUTO_COMPILE=0 
> ../meta/build-env guild compile --target="x86_64-apple-darwin18.7.0" -O1 
> -Oresolve-primitives -L
> "/Users/aleix/guile-2.9.7/module" -L 
> "/Users/aleix/guile-2.9.7/guile-readline" -o "system/vm/linker.go" 
> "../module/system/vm/linker.scm"
> make[2]: *** [system/vm/linker.go] Error 134

Fixed in 2.9.8, I think.

Cheers,

Andy

bug#38672: Core records and R7RS records

[Andy Wingo]

On Thu 19 Dec 2019 17:24, Marc Nieper-Wißkirchen  
writes:

> I've read in the news that the upcoming Guile 3.0 will unify records.
>
> Core records type seem to support the procedure "record-accessor",
> which takes a field name as a symbol.
>
> In R7RS (based on SRFI 9), record field names are, however, (hygienic)
> identifiers and thus compile-time and not run-time identities. An R7RS
> record type can, therefore, not support "record-accessor" and similar
> procedures.
>
> How is this going to be solved in Guile 3?

See
https://git.savannah.gnu.org/cgit/guile.git/commit/?id=86a9f9a27176968bbae46aceed114634ca7c693e
(just landed).

Cheers,

Andy

bug#38611: Guile 2.9.7 regression: "duplicate" record field names

[Andy Wingo]

On Sat 14 Dec 2019 14:31, Göran Weinholt  writes:

> The following program works in Guile 2.2.6 (and other R6RS
> implementations), but raises an exception in Guile 2.9.7. A field called
> "name" exists in record type a and record type b, but there is no actual
> naming conflict as I understand it.
>
> (import (rnrs))
>
> (define-record-type a
>   (fields name))
>
> (define-record-type b
>   (parent a)
>   (fields name))
>
> (let ((x (make-b 'a 'b)))
>   (write (list (a-name x)
>(b-name x)))
>   (newline))

Fixed in master.  Thanks for the report!

Andy

bug#38617: should internal defines be callable with incorrect number of args?

[Andy Wingo]

On Sun 15 Dec 2019 02:02, Christopher Lam  writes:

> See snippet below. 
> IMHO the second call to add1 should fail. On guile-2.2.6 it does not error 
> out.
> On guile-2.0 it does throw error (as I think it should).
> Is this intentional?

OMG what an embarrassing bug!  Thank you for finding and reporting it!
Fixed on 2.2 and master.

Andy

bug#38895: Autoloads behave differently in Guile ≥ 2.9.7

[Andy Wingo]

On Fri 03 Jan 2020 16:56, Ludovic Courtès  writes:

> It seems that since 2.9.7, autoloads have to specify exactly all the
> bindings of the autoloaded module that the user will ever reference.
> Bindings that are omitted from the #:autoload clause remain unbound:

Indeed.  This was an unintentional change, in the sense that I thought
that the previous behavior was to only import the referenced bindings.
As discussed on IRC we decided to leave it with the new behavior, add a
NEWS entry, and we can roll back if it's really a pain to people.
Thanks for finding the issue!

Andy

bug#38760: R7RS define-library form is not supported

[Andy Wingo]

Thanks for the report; fixed!  Patches welcome if there are any bugs :)

Cheers,

Andy

bug#38388: [2.9.5] Inaccurate source location info for unbound variables

[Andy Wingo]

On Thu 28 Nov 2019 09:20, Ludovic Courtès  writes:

>>> I have a test that runs ‘guix system build’ on this file:
>>>
>>> (use-modules (gnu))   ; 1
>>> (use-service-modules networking)  ; 2
>>>
>>> (operating-system ; 4
>>>   (host-name "antelope")  ; 5
>>>   (timezone "Europe/Paris")   ; 6
>>>   (locale "en_US.UTF-8")  ; 7
>>>
>>>   (bootloader (GRUB-config (target "/dev/sdX")))  ; 9
>>>   (file-systems (cons (file-system
>>> (device (file-system-label "root"))
>>> (mount-point "/")
>>> (type "ext4"))
>>>   %base-file-systems)))
>>>
>>> Here, ‘GRUB-config’ is unbound, and the test expects to see a stack
>>> frame corresponding to line 9.
>>>
>>> However, the stack frame we get is for line 11, char 32, which
>>> corresponds to (file-system-label "root").
>
> Any idea where I should poke for debugging?

Sure would be nice to reduce the test case!  Once you have reduced it, I
would first look at the result of ,expand on this form.  If it looks the
same as in 2.2, then perhaps the CPS layer is at fault.  Could be we're
dropping an important source location somewher.

Andy

bug#38388: [2.9.5] Inaccurate source location info for unbound variables

[Andy Wingo]

Hi,

On Tue 26 Nov 2019 16:20, Ludovic Courtès  writes:

> I have a test that runs ‘guix system build’ on this file:
>
> (use-modules (gnu))   ; 1
> (use-service-modules networking)  ; 2
>
> (operating-system ; 4
>   (host-name "antelope")  ; 5
>   (timezone "Europe/Paris")   ; 6
>   (locale "en_US.UTF-8")  ; 7
>
>   (bootloader (GRUB-config (target "/dev/sdX")))  ; 9
>   (file-systems (cons (file-system
> (device (file-system-label "root"))
> (mount-point "/")
> (type "ext4"))
>   %base-file-systems)))
>
> Here, ‘GRUB-config’ is unbound, and the test expects to see a stack
> frame corresponding to line 9.
>
> However, the stack frame we get is for line 11, char 32, which
> corresponds to (file-system-label "root").
>
> So it would seem that the IP-to-source-location mapping is not quite
> working as expected.
>
> Thoughts?

What version is this with?

Unfortunately as you know, bare identifiers don't have good source
location information.  There are small improvements that can be made but
larger improvments are gnarly.  Could be this is a case for a small
improvement though!

Andy

bug#38348: [2.9.5] Stack overflow when stdout is closed

[Andy Wingo]

Hey :)

On Sat 23 Nov 2019 17:46, Ludovic Courtès  writes:

> Hello!
>
> Guile 2.9.5 segfaults from a C stack overflow when you start it with a
> closed stdout:
>
>   /gnu/store/7vwf3nhiacxc2jgcg43w22px4ds3rb36-guile-next-2.9.5/bin/guile -c 
> '(pk 1)' >&-

Fixed, thanks!

Cheers,

Andy

bug#38236: R7RS reader does not support datum labels

[Andy Wingo]

Hey!

On Mon 18 Nov 2019 16:10, Mark H Weaver  writes:

> Andy Wingo  writes:
>
>> R7RS defines a lexical feature called "datum labels"; see section 2.4 in
>> the report.  An example would be:
>>
>>#0=(a b c . #0#)
>>
>> Guile's reader doesn't support this feature and it's not clear if we
>> should, in general.
>
> FYI, I already implemented R7RS datum labels on the 'r7rs-wip' branch
> (not to be confused with your new 'wip-r7rs' branch):
>
>   
> https://git.savannah.gnu.org/cgit/guile.git/commit/?h=r7rs-wip&id=92408ac20e921583b8e4ee26463dc5805ef01153
>
> It depends on the preceding commit on the same branch:
>
>   
> https://git.savannah.gnu.org/cgit/guile.git/commit/?h=r7rs-wip&id=f687871eceb94bded109569880e696d8862d84fd
>
> There was also a later commit on that branch that enabled compilation of
> cyclic literals, but it's no longer applicable to the 'master' branch.

Neat!  I had entirely forgotten about this branch.

>> Note, datum literals appear to be incompatible with array literals.
>
> Can you elaborate on why you believe they're incompatible?  I haven't
> looked closely in a while, but I didn't see any incompatibility when I
> implemented this before.  Datum labels have '#' or '=' after the
> numeral, and I'm not aware of any Guile array syntax that does.

I was wrong.  Thanks for the correction!

> I'm also a bit puzzled why you're apparently planning to rewrite
> everything I already did on the 'r7rs-wip' branch.  The main issue on
> that branch is that the implementation of *writing* cyclic data turned
> out to be a mess, but it could be removed or replaced without affecting
> much else.

I had totally forgotten about it.  I am surprised no one on #guile
brought it up either when I was discussing this work!

As you can see, the the writing implementation currently uses srfi-38.

For what it's worth, I do not have future plans to work on R7RS -- I
just wanted --r7rs so that I could have an easy way to benchmark against
other Scheme systems.  A strange reason, admittedly!

Andy

bug#38239: hungry-eol-escapes reader option doesn't allow intraline whitespace

[Andy Wingo]

Guile supports the R7RS idiom whereby this:

  "foo\
  bar"

reads as

  "foobar"

In the R6RS, this syntax is specified as allowing intraline whitespace
(space, tab, and anything Unicode with category Zs) after the \ but
before the newline.  However in Guile we don't support this and signal
an error instead ("illegal character in escape sequence: #\space").

Probably we should relax this restriction and allow intraline whitespace
after the \ and before the newline.

bug#38238: (call-with-input-string "( . 42)" read) => 42

[Andy Wingo]

Guile has a strange syntax extension, as described in the bug title.
It's not explicitly documented AFAIU and it seems it may simply be a
mistake.  We should consider making ( . 42) a lexical error.

bug#38237: I/O errors do not currently have their own exception type

[Andy Wingo]

For R7RS, this should be true:

  (file-error? (guard (exn (else exn)) (open-input-file " no such file ")))

However currently an error during Guile's open-input-file doesn't raise
a specific-enough exception for file-error? to be implementable.
Something to fix.

bug#38236: R7RS reader does not support datum labels

[Andy Wingo]

R7RS defines a lexical feature called "datum labels"; see section 2.4 in
the report.  An example would be:

   #0=(a b c . #0#)

Guile's reader doesn't support this feature and it's not clear if we
should, in general.  Note, datum literals appear to be incompatible with
array literals.  But we could of course use the R7RS layer as a place to
experiment with a `read' implemented in Scheme.

bug#38235: string-foldcase bug for trailing sigma

[Andy Wingo]

Given the following example, using (rnrs unicode):

  (string-foldcase "ΜΈΛΟΣ")

The expected result is "μέλοσ"; see R6RS libraries section 1.2.  However
instead Guile's result is "μέλος".  Note that although Σ usually
downcases to σ, at the end of a string it's ς.  This test shows a
limitation of defining string-foldcase as simply (string-downcase
(string-upcase str)).

bug#33652: close thanks

[Andy Wingo]

close
thanks

Fixed in master.  Thanks very much for the report and patch!

bug#33036: Bug with the procedure nil? inside a specific code

[Andy Wingo]

Hi!

Thank you, Mark!  That looks great.

I note also that this is fixed in master, unless I made another bug.
See type-fold.scm:66-87 and types.scm:574-617.

Cheers!

Andy

On Sun 14 Oct 2018 06:05, Mark H Weaver  writes:

> Mark H Weaver  writes:
>
>> calcium  writes:
>>> Here is the bug that I found :
>>>
>>> ;;; -START- code with the bug -START- ;;;
>>>
>>> (define (strange lst)
>>>   (let loop ((lst lst)
>>>  (is-empty '()))
>>> (cond ((nil? lst)
>>>(if (nil? is-empty) 'works
>>>  (list 'should-not-occur is-empty)))
>>>   (else
>>>(loop (cdr lst)
>>>  is-empty)
>>>
>>> (strange '())
>>> => (should-not-occur ())
>>>
>>> (strange #nil)
>>> => (should-not-occur ())
>>
>> Indeed, this certainly indicates a bug.
>>
>> I believe the bug is in 'local-type-fold' in (language cps type-fold).
>> It contains a local procedure 'scalar-value' which, if I understand
>> correctly, seems to incorrectly assume that (nil? x) returns #t if and
>> only if X is 'eq?' to #nil.
>
> The bug actually wasn't in 'local-type-fold', but it's true that the
> type inferencer assumed in a few places that if (nil? X) returned #t
> that X must be #nil, and similarly for 'null?' and ().
>
> I've attached a proposed fix.
>
> Andy, does this fix look right to you?
>
>  Thanks,
>Mark
>
>
> From d904d5233582e51a4be06d2c08ccdd15a66b8d77 Mon Sep 17 00:00:00 2001
> From: Mark H Weaver 
> Date: Sat, 13 Oct 2018 23:02:05 -0400
> Subject: [PATCH] Fix type inferencing for 'nil?' and 'null?' predicates.
>
> Fixes .
> Reported by .
>
> * module/language/cps/types.scm (define-simple-type-inferrer):
> Apply (logand (&type val) <>) uniformly.  Previously, this was done only
> in the false branch.  Rename local variable to 'type*', to allow the
> macro operand 'type' to be an arbitrary expression.
> (*type-inferrers*): Add &nil to the set of possible types.
> (*type-inferrers*): Add &false and &null to the set the possible
> types.
> * module/language/cps/type-fold.scm (*branch-folders*): Add &nil
> to the set of possible types.
> (*branch-folders*): Add &false and &null to the set the possible
> types.
> * test-suite/tests/compiler.test: Add tests.
> ---
>  module/language/cps/type-fold.scm |  6 ++--
>  module/language/cps/types.scm | 13 
>  test-suite/tests/compiler.test| 51 ++-
>  3 files changed, 60 insertions(+), 10 deletions(-)
>
> diff --git a/module/language/cps/type-fold.scm 
> b/module/language/cps/type-fold.scm
> index fc37fac50..163ef659d 100644
> --- a/module/language/cps/type-fold.scm
> +++ b/module/language/cps/type-fold.scm
> @@ -1,5 +1,5 @@
>  ;;; Abstract constant folding on CPS
> -;;; Copyright (C) 2014, 2015 Free Software Foundation, Inc.
> +;;; Copyright (C) 2014, 2015, 2018 Free Software Foundation, Inc.
>  ;;;
>  ;;; This library is free software: you can redistribute it and/or modify
>  ;;; it under the terms of the GNU Lesser General Public License as
> @@ -69,8 +69,8 @@
>  
>  ;; All the cases that are in compile-bytecode.
>  (define-unary-type-predicate-folder pair? &pair)
> -(define-unary-type-predicate-folder null? &null)
> -(define-unary-type-predicate-folder nil? &nil)
> +(define-unary-type-predicate-folder null? (logior &nil &null))
> +(define-unary-type-predicate-folder nil? (logior &false &nil &null))
>  (define-unary-type-predicate-folder symbol? &symbol)
>  (define-unary-type-predicate-folder variable? &box)
>  (define-unary-type-predicate-folder vector? &vector)
> diff --git a/module/language/cps/types.scm b/module/language/cps/types.scm
> index 5c1d71299..61de971fe 100644
> --- a/module/language/cps/types.scm
> +++ b/module/language/cps/types.scm
> @@ -529,13 +529,14 @@ minimum, and maximum."
>  
>  (define-syntax-rule (define-simple-predicate-inferrer predicate type)
>(define-predicate-inferrer (predicate val true?)
> -(let ((type (if true?
> -type
> -(logand (&type val) (lognot type)
> -  (restrict! val type -inf.0 +inf.0
> +(let ((type* (logand (&type val)
> + (if true?
> + type
> + (lognot type)
> +  (restrict! val type* -inf.0 +inf.0
>  (define-simple-predicate-inferrer pair? &pair)
> -(define-simple-predicate-inferrer null? &null)
> -(define-simple-predicate-inferrer nil? &nil)
> +(define-simple-predicate-inferrer null? (logior &nil &null))
> +(define-simple-predicate-inferrer nil? (logior &false &nil &null))
>  (define-simple-predicate-inferrer symbol? &symbol)
>  (define-simple-predicate-inferrer variable? &box)
>  (define-simple-predicate-inferrer vector? &vector)
> diff --git a/test-suite/tests/compiler.test b/test-suite/tests/compiler.test
> index 4f644f339..64bb976fa 100644
> --- a/test-suite/tests/compiler.test
> +++ b/test-suite/tests/compiler.test
> @@ -1,5 +1,5 @@
>   compiler.test

bug#29669: repl-print - requet for iprovement

[Andy Wingo]

On Sun 01 Jul 2018 18:26, l...@gnu.org (Ludovic Courtès) writes:

> Hello,
>
> David Pirotte  skribis:
>
>> From d920d22efe3e77d23004122e21cec420c402f531 Mon Sep 17 00:00:00 2001
>> From: David Pirotte 
>> Date: Mon, 11 Dec 2017 21:28:24 -0200
>> Subject: [PATCH] Updating repl-print to use truncated-print
>>
>> * module/system/repl/common.scm (repl-print): Use (truncated-print val),
>>   not (write val).  With this update, repl-print becomes 'friendly' wrt
>>   large (huge) lists, arrays, srfi-4 butevoectors ...
>
> Note that it’s already possible to do this:
>
> scheme@(guile-user)> ,use (ice-9 pretty-print)
> scheme@(guile-user)> ,o print (lambda (repl obj) (truncated-print obj) 
> (newline))
> scheme@(guile-user)> (iota 500)
> $20 = (0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 
> 27 # …)
>
> So the question becomes: should we change the default?
>
> I have a slight preference for keeping the default as it is to avoid
> surprises, but no strong opinion.
>
> Andy, Mark, others, WDYT?

Hoo, I don't know.  If we were to do this it should be controllable by
REPL options, I think; we'd need the ability to go back and forth.  But
if we have the option I think it could make sense for it to be on by
default, like what GDB does.  Thing is, truncated-print does its job
only OK, not great, so it's a hard sell to standardize on it.  You
probably do want multi-line prints sometimes...

Andy

bug#30066: 'get-bytevector-some' returns only 1 byte from unbuffered ports

[Andy Wingo]

On Fri 12 Jan 2018 11:15, l...@gnu.org (Ludovic Courtès) writes:

> Andy Wingo  skribis:
>
>> On Thu 11 Jan 2018 22:55, Mark H Weaver  writes:
>
> [...]
>
>>>>> Out of curiosity, is there a reason why you're using an unbuffered port
>>>>> in your use case?
>>>>
>>>> It’s to implement redirect à la socat:
>>>>
>>>>   
>>>> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=17af5d51de7c40756a4a39d336f81681de2ba447
>>>
>>> Why is an unbuffered port being used here?  Can we change it to a
>>> buffered port?
>>
>> This was also a question I had!  If you make it a buffered port at 4096
>> bytes (for example), then get-bytevector-some works exactly like you
>> want it to, no?
>
> It might work, but that’s more by chance no?

No, it is reliable.  get-bytevector-some on a buffered port must either
return all the buffered bytes or perform exactly one read (up to the
buffer size) and either return those bytes or EOF.  As far as I
understand, that is exactly what you want.

Using buffered ports has two additional advantages: you get to specify
the read size, and returned bytevectors can be allocated to precisely
the right size (no need to overallocate then truncate).

Andy

bug#30066: 'get-bytevector-some' returns only 1 byte from unbuffered ports

[Andy Wingo]

On Thu 11 Jan 2018 22:55, Mark H Weaver  writes:

> l...@gnu.org (Ludovic Courtès) writes:
>
>> Mark H Weaver  skribis:
>>
>>> l...@gnu.org (Ludovic Courtès) writes:
>>
>> [...]
>>
 +  if (SCM_UNBUFFEREDP (port) && (avail < max_buffer_size))
 +{
 +  /* PORT is unbuffered.  Read as much as possible from PORT.  */
 +  size_t read;
 +
 +  bv = scm_c_make_bytevector (max_buffer_size);
 +  scm_port_buffer_take (buf, (scm_t_uint8 *) SCM_BYTEVECTOR_CONTENTS 
 (bv),
 +avail, cur, avail);
 +
 +  read = scm_i_read_bytes (port, bv, avail,
 +   SCM_BYTEVECTOR_LENGTH (bv) - avail);
>>>
>>> Here's the R6RS specification for 'get-bytevector-some':
>>>
>>>   "Reads from BINARY-INPUT-PORT, blocking as necessary, until bytes are
>>>available from BINARY-INPUT-PORT or until an end of file is reached.
>>>If bytes become available, 'get-bytevector-some' returns a freshly
>>>allocated bytevector containing the initial available bytes (at least
>>>one), and it updates BINARY-INPUT-PORT to point just past these
>>>bytes.  If no input bytes are seen before an end of file is reached,
>>>the end-of-file object is returned."
>>>
>>> By my reading of this, we should block only if necessary to ensure that
>>> we return at least one byte (or EOF).  In other words, if we can return
>>> at least one byte (or EOF), then we must not block, which means that we
>>> must not initiate another 'read'.
>>
>> Indeed.  So perhaps the condition above should be changed to:
>>
>>   if (SCM_UNBUFFEREDP (port) && (avail == 0))
>>
>> ?
>
> That won't work, because the earlier call to 'scm_fill_input' will have
> already initiated a 'read' if the buffer was empty.  The read buffer
> size will determine the maximum number of bytes read, which will be 1 in
> the case of an unbuffered port.  So, at the point of this condition,
> 'avail == 0' will occur only if EOF was encountered, in which case you
> must return EOF without attempting another 'read'.
>
> In order to avoid unnecessary blocking, there must be only one 'read'
> call, and it must be initiated only if the buffer was already empty.
>
> So, in order to accomplish your goal here, I don't see how you can use
> 'scm_fill_input', unless you temporarily increase the size of the read
> buffer beforehand.
>
> Instead, I think you need to first check if the read buffer contains any
> bytes.  If so, empty the buffer and return them.  If the buffer is
> empty, the next thing to check is 'scm_port_buffer_has_eof_p'.  If it's
> set, then clear that flag and return EOF.
>
> Otherwise, if the buffer is empty and 'scm_port_buffer_has_eof_p' is
> false, then you must do what 'scm_fill_input' would have done, except
> using your larger buffer instead of the port's internal read buffer.  In
> particular, you must first switch the port to "reading" mode, flushing
> the write buffer if 'rw_random' is set.
>
> Also, I'd prefer to move this code to ports.c in order to avoid adding
> more internal declarations to ports.h and changing more functions from
> 'static' to global functions.

I agree with Mark here -- thanks for the close review.

>>> Out of curiosity, is there a reason why you're using an unbuffered port
>>> in your use case?
>>
>> It’s to implement redirect à la socat:
>>
>>   
>> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=17af5d51de7c40756a4a39d336f81681de2ba447
>
> Why is an unbuffered port being used here?  Can we change it to a
> buffered port?

This was also a question I had!  If you make it a buffered port at 4096
bytes (for example), then get-bytevector-some works exactly like you
want it to, no?

Andy

bug#30066: 'get-bytevector-some' returns only 1 byte from unbuffered ports

[Andy Wingo]

On Wed 10 Jan 2018 17:58, Nala Ginrut  writes:

> hi Andy and Ludo!
>
> What if developers enabled suspendable-ports and set the port to non-blocking?
> For example, in the non-blocking asynchronous server, I registered
> read/write waiter for suspendable-ports. And save
> delimited-continuations then yield the current task.
> In this situation, get-bytevector-n! will read n bytes with several
> times yielding by the registered read-writer, from the caller's
> perspective, get-bytevector-n! will return n bytes finally no matter
> how many times it's yielded.
> But how about the get-bytevector-some? Should it block just once and
> return the first time read m bytes then return?

I think this is right.  At most one block.  FWIW we'd need to add
support for get-bytevector-some to (ice-9 suspendable-ports) to get this
to work.

Andy

bug#30066: 'get-bytevector-some' returns only 1 byte from unbuffered ports

[Andy Wingo]

On Wed 10 Jan 2018 16:59, l...@gnu.org (Ludovic Courtès) writes:

> l...@gnu.org (Ludovic Courtès) skribis:
>
>> As discussed on IRC, ‘get-bytevector-some’ returns only 1 byte from
>> unbuffered ports:
>
> Here’s a tentative fix.  WDYT?

Thanks!  Needs a little work though :)  Comments inline.

> --- a/libguile/ports.h
> +++ b/libguile/ports.h
> @@ -69,6 +69,7 @@ SCM_INTERNAL SCM scm_i_port_weak_set;
>  #define SCM_OPOUTPORTP(x) (SCM_OPPORTP (x) && SCM_OUTPUT_PORT_P (x))
>  #define SCM_OPENP(x) (SCM_OPPORTP (x))
>  #define SCM_CLOSEDP(x) (!SCM_OPENP (x))
> +#define SCM_UNBUFFEREDP(x) (SCM_PORTP (x) && (SCM_CELL_WORD_0 (x) & 
> SCM_BUF0))
>  #define SCM_CLR_PORT_OPEN_FLAG(p) \
>SCM_SET_CELL_WORD_0 ((p), SCM_CELL_WORD_0 (p) & ~SCM_OPN)
>  #ifdef BUILDING_LIBGUILE

Please guard this under #ifdef BUILDING_LIBGUILE.

> @@ -487,16 +487,33 @@ SCM_DEFINE (scm_get_bytevector_some, 
> "get-bytevector-some", 1, 0, 0,
>  
>SCM_VALIDATE_BINARY_INPUT_PORT (1, port);
>  
> -  buf = scm_fill_input (port, 0, &cur, &avail);
> -  if (avail == 0)
> +  if (SCM_UNBUFFEREDP (port))
>  {
> -  scm_port_buffer_set_has_eof_p (buf, SCM_BOOL_F);
> -  return SCM_EOF_VAL;
> +  size_t read;
> +
> +  bv = scm_c_make_bytevector (4096);
> +  read = scm_i_read_bytes (port, bv, 0, SCM_BYTEVECTOR_LENGTH (bv));
> +
> +  if (read == 0)
> + return SCM_EOF_VAL;
> +  else if (read < SCM_BYTEVECTOR_LENGTH (bv))
> + return scm_c_shrink_bytevector (bv, read);
> +  else
> + return bv;
>  }
> +  else
> +{
> +  buf = scm_fill_input (port, 0, &cur, &avail);
> +  if (avail == 0)
> + {
> +   scm_port_buffer_set_has_eof_p (buf, SCM_BOOL_F);
> +   return SCM_EOF_VAL;
> + }
>  
> -  bv = scm_c_make_bytevector (avail);
> -  scm_port_buffer_take (buf, (scm_t_uint8 *) SCM_BYTEVECTOR_CONTENTS (bv),
> -avail, cur, avail);
> +  bv = scm_c_make_bytevector (avail);
> +  scm_port_buffer_take (buf, (scm_t_uint8 *) SCM_BYTEVECTOR_CONTENTS 
> (bv),
> + avail, cur, avail);
> +}
>  
>return bv;
>  }

There are tabs in your code; would you mind doing only spaces?

A port being unbuffered doesn't mean that it has no bytes in its
buffer.  In particular, scm_unget_bytes may put bytes back into the
buffer.  Or, peek-u8 might fill this buffer with one byte.

Also, they port may have buffered write bytes (could be the port has
write buffering but no read buffering).  In that case (pt->rw_random)
you need to scm_flush().

I suggest taking the buffered bytes from the read buffer, if any.  Then
if the port is unbuffered, make a bytevector and call scm_i_read_bytes;
otherwise do the scm_fill_input path that's there already.

One more thing, if the port goes EOF, you need to
scm_port_buffer_set_has_eof_p.

Regards,

Andy

bug#19180: Weak tables harmful to GC?

[Andy Wingo]

On Tue 31 Oct 2017 00:13, l...@gnu.org (Ludovic Courtès) writes:

> I built libguile with the patch (I haven’t yet taken the time to rebuild
> all of Guile).  It works, but unfortunately it still shows quick growth
> of the heap on this example (<https://bugs.gnu.org/28590>):

Fixed in attached patches (on top of the other one).  This was a race
between the periodic vacuum process, which should run after GC via a
finalizer, and the mutator.  If the mutator had the weak table lock, the
vacuum would never be run.  Of course in the test below, the mutator
usually has the table lock, so we ended up often skipping the vacuum,
which causes the table size to grow, which causes the active heap size
to grow, which causes the bytes-allocated-before-GC to increase, and
which ultimately is a vicious circle.

In my tests this patch fixes the issue, though the level at which the
heap stabilizes can vary slightly as there's a bit of nondeterministic
concurrency as the mutator and the vacuum process still race a bit.
Right now for me it stabilizes at about 6.2M of heap.

>>weak_key_gc_kind =
>>  GC_new_kind (GC_new_free_list (),
>> - GC_MAKE_PROC (GC_new_proc (mark_weak_key_table), 0),
>> + GC_MAKE_PROC (GC_new_proc (mark_weak_key_entry), 0),
>>   0, 0);
>
> I think we should avoid custom mark procedures and use a bitmap here, as
> recommended in the libgc headers (like ‘wcar_pair_descr’ in weaks.c in
> 2.0.)

Good idea; fixed.

Andy

>From 098c4171ef53791d97b5c675218f302efc7bcf26 Mon Sep 17 00:00:00 2001
From: Andy Wingo 
Date: Tue, 31 Oct 2017 09:10:55 +0100
Subject: [PATCH 2/3] Refactor weak table to use bitmaps for weak entries

---
 libguile/weak-table.c | 107 --
 1 file changed, 25 insertions(+), 82 deletions(-)

diff --git a/libguile/weak-table.c b/libguile/weak-table.c
index ff8a01fb0..fab98149f 100644
--- a/libguile/weak-table.c
+++ b/libguile/weak-table.c
@@ -25,7 +25,7 @@
 #include 
 
 #include "libguile/bdw-gc.h"
-#include 
+#include 
 
 #include "libguile/_scm.h"
 #include "libguile/hash.h"
@@ -152,70 +152,10 @@ typedef struct {
 
 
 
-/* The GC "kinds" for singly-weak tables.  */
-static int weak_key_gc_kind;
-static int weak_value_gc_kind;
-static int doubly_weak_gc_kind;
-
-static struct GC_ms_entry *
-mark_weak_key_entry (GC_word *addr, struct GC_ms_entry *mark_stack_ptr,
- struct GC_ms_entry *mark_stack_limit, GC_word env)
-{
-  scm_t_weak_entry *entry = (scm_t_weak_entry*) addr;
-
-  if (entry->next)
-mark_stack_ptr = GC_MARK_AND_PUSH ((GC_word*) entry->next,
-   mark_stack_ptr, mark_stack_limit,
-   NULL);
-
-  if (entry->hash && entry->key)
-{
-  SCM value = SCM_PACK (entry->value);
-  if (SCM_HEAP_OBJECT_P (value))
-mark_stack_ptr = GC_MARK_AND_PUSH ((GC_word*) SCM2PTR (value),
-   mark_stack_ptr, mark_stack_limit,
-   NULL);
-}
-
-  return mark_stack_ptr;
-}
-
-static struct GC_ms_entry *
-mark_weak_value_entry (GC_word *addr, struct GC_ms_entry *mark_stack_ptr,
-   struct GC_ms_entry *mark_stack_limit, GC_word env)
-{
-  scm_t_weak_entry *entry = (scm_t_weak_entry*) addr;
-
-  if (entry->next)
-mark_stack_ptr = GC_MARK_AND_PUSH ((GC_word*) entry->next,
-   mark_stack_ptr, mark_stack_limit,
-   NULL);
-
-  if (entry->hash && entry->value)
-{
-  SCM key = SCM_PACK (entry->key);
-  if (SCM_HEAP_OBJECT_P (key))
-mark_stack_ptr = GC_MARK_AND_PUSH ((GC_word*) SCM2PTR (key),
-   mark_stack_ptr, mark_stack_limit,
-   NULL);
-}
-
-  return mark_stack_ptr;
-}
-
-static struct GC_ms_entry *
-mark_doubly_weak_entry (GC_word *addr, struct GC_ms_entry *mark_stack_ptr,
-struct GC_ms_entry *mark_stack_limit, GC_word env)
-{
-  scm_t_weak_entry *entry = (scm_t_weak_entry*) addr;
-
-  if (entry->next)
-mark_stack_ptr = GC_MARK_AND_PUSH ((GC_word*) entry->next,
-   mark_stack_ptr, mark_stack_limit,
-   NULL);
-
-  return mark_stack_ptr;
-}
+/* GC descriptors for the various kinds of scm_t_weak_entry.  */
+static GC_descr weak_key_descr;
+static GC_descr weak_value_descr;
+static GC_descr doubly_weak_descr;
 
 static scm_t_weak_entry *
 allocate_entry (scm_t_weak_table_kind kind)
@@ -225,20 +165,18 @@ allocate_entry (scm_t_weak_table_kind kind)
   switch (kind)
 {
 case SCM_WEAK_TABLE_KIND_KEY:
-  ret = GC_generic_malloc (sizeof (*ret), weak_key_gc_kind);
+  ret 

bug#19180: Weak tables harmful to GC?

[Andy Wingo]

Hi!

As discussed on IRC, what do you think of this patch?  It preserves the
thread-safety properties of weak tables and just adapts them to be
bucket-and-chain tables.  Let me know how it works for you.  If it
works, we'll need to adapt weak sets as well.

Andy

>From 6ec4642516eaabf7a63644463a7836eb3efbcd60 Mon Sep 17 00:00:00 2001
From: Andy Wingo 
Date: Mon, 30 Oct 2017 18:19:37 +0100
Subject: [PATCH] Weak tables are now bucket-and-chain tables

This change should make weak tables work better with libgc, as the weak
components that need mark functions are smaller, so they don't overflow
the mark queue.  Also this prevents the need to move disappearing
links.

* libguile/weak-table.c (scm_t_weak_entry): Change to be a hash table
  chain entry.
  (struct weak_entry_data, do_read_weak_entry, read_weak_entry): Read
  out the key and value directly.
  (GC_move_disappearing_link, move_disappearing_links, move_weak_entry):
  Remove.
  (scm_t_weak_table): Rename "entries" member to "buckets", and "size" to
  "n_buckets".
  (hash_to_index, entry_distance, rob_from_rich, give_to_poor): Remove.
  (mark_weak_key_entry, mark_weak_value_entry): Mark a single link, and
  the next link.
  (mark_doubly_weak_entry): New kind.
  (allocate_entry): Allocate a single entry.
  (add_entry): New helper.
  (resize_table): Reimplement more like normal hash tables.
  (vacuum_weak_table): Adapt to new implementation.
  (weak_table_ref, weak_table_put_x, weak_table_remove_x): Adapt.
  (make_weak_table): Adapt.
  (scm_weak_table_clear_x): Actually unregister the links to prevent a
  memory leak.
  (scm_c_weak_table_fold): Collect items in an alist, then fold outside
  the lock.
  (scm_weak_table_prehistory): Initialize doubly_weak_gc_kind.
---
 libguile/weak-table.c | 723 +++---
 1 file changed, 212 insertions(+), 511 deletions(-)

diff --git a/libguile/weak-table.c b/libguile/weak-table.c
index 599c4cf0e..ff8a01fb0 100644
--- a/libguile/weak-table.c
+++ b/libguile/weak-table.c
@@ -1,4 +1,4 @@
-/* Copyright (C) 2011, 2012, 2013, 2014 Free Software Foundation, Inc.
+/* Copyright (C) 2011, 2012, 2013, 2014, 2017 Free Software Foundation, Inc.
  * 
  * This library is free software; you can redistribute it and/or
  * modify it under the terms of the GNU Lesser General Public License
@@ -44,83 +44,62 @@
data, but when you don't have space to store the data in the object.
For example, procedure properties are implemented with weak tables.
 
-   Weak tables are implemented using an open-addressed hash table.
-   Basically this means that there is an array of entries, and the item
-   is expected to be found the slot corresponding to its hash code,
-   modulo the length of the array.
-
-   Collisions are handled using linear probing with the Robin Hood
-   technique.  See Pedro Celis' paper, "Robin Hood Hashing":
-
- http://www.cs.uwaterloo.ca/research/tr/1986/CS-86-14.pdf
-
-   The vector of entries is allocated in such a way that the GC doesn't
-   trace the weak values.  For doubly-weak tables, this means that the
-   entries are allocated as an "atomic" piece of memory.  Key-weak and
-   value-weak tables use a special GC kind with a custom mark procedure.
-   When items are added weakly into table, a disappearing link is
-   registered to their locations.  If the referent is collected, then
-   that link will be zeroed out.
+   This is a normal bucket-and-chain hash table, except that the chain
+   entries are allocated in such a way that the GC doesn't trace the
+   weak values.  For doubly-weak tables, this means that the entries are
+   allocated as an "atomic" piece of memory.  Key-weak and value-weak
+   tables use a special GC kind with a custom mark procedure.  When
+   items are added weakly into table, a disappearing link is registered
+   to their locations.  If the referent is collected, then that link
+   will be zeroed out.
 
An entry in the table consists of the key and the value, together
-   with the hash code of the key.  We munge hash codes so that they are
-   never 0.  In this way we can detect removed entries (key of zero but
-   nonzero hash code), and can then reshuffle elements as needed to
-   maintain the robin hood ordering.
-
-   Compared to buckets-and-chains hash tables, open addressing has the
-   advantage that it is very cache-friendly.  It also uses less memory.
-
-   Implementation-wise, there are two things to note.
-
- 1. We assume that hash codes are evenly distributed across the
-range of unsigned longs.  The actual hash code stored in the
-entry is left-shifted by 1 bit (losing 1 bit of hash precision),
-and then or'd with 1.  In this way we ensure that the hash field
-of an occupied entry is nonzero.  To map to an index, we
-right-shift the hash by one, divide by the siz

bug#12827: [PATCH] Tweak web modules, support relative URIs

[Andy Wingo]

On Tue 21 Jun 2016 15:22, l...@gnu.org (Ludovic Courtès) writes:

> Andy Wingo  skribis:
>
>> I would like to apply this patch, to master at least.  Any objections?
>> We need documentation for the new exports, is the only missing thing.
>
> On a quick glance that looks good.  My only concern would be
> incompatibilities; for instance, the ‘content-location’ can now be an
> object that doesn’t pass ‘uri?’, IIUC.  Not sure how much of a problem
> that is.

I have applied this patch with some modifications and added docs.
Notably, the behavior of uri? is unchanged relative to master (though
there's a deprecation note; see NEWS) and string->uri keeps its old
behavior of not throwing exceptions.  I also removed the "absolute-uri?"
stuff because it was unused and it seems silly to reserve that useful
name in that way -- RFC 3986 defines "absolute uri" simply as being a
URI without a fragment.  Weird definition.

Thank you for the patch, Daniel, and thanks to Ludo and Mark for working
through this bug.

Andy

bug#12207: repl and comments or tabs

[Andy Wingo]

On Thu 04 Aug 2016 22:55, Andy Wingo  writes:

> On Thu 28 Jul 2016 19:21, "helpful.user@discard.email" 
>  writes:
>
>> The following patch to readline should fix the tab issue:
>>
>> https://lists.gnu.org/archive/html/bug-bash/2014-10/msg00211.html
>>
>> (AFACT you need to put "set enable-bracketed-paste on" in your ~
>> /.inputrc too)
>
> Fascinating!  I guess from Guile's side we should do
>
>  rl_variable_bind ("enable-bracketed-paste", "on")
>
> in our readline code

Done.  Thanks for the tip.  See NEWS for details.

Andy

bug#26858: Cygwin port of Guile 2.2

[Andy Wingo]

Greets,

On Fri 12 May 2017 16:13, Derek Upham  writes:

> Andy Wingo  writes:
>
>> scm_join_thread isn't actually implemented in terms of
>> scm_i_pthread_join any more.  Probably that's what's going wrong here --
>> and probably that should be fixed to ensure that we actually join the
>> thread.  (Otherwise it would be a memory leak too AFAIU.)  Bcc'ing
>> bug-guile to create a bug for that.
>
> I noticed that scm_join_thread was calling back into Scheme-land.  Are these 
> statements all correct?
>
> - We are using call-with-new-thread underneath the hood.

Underneath the hood of what? :)

> - call-with-new-thread is documented to return a Scheme object from a
> thunk/handler.  Any underlying pthreads should be implementation
> details.

Correct.  In practice call-with-new-thread will create a pthread but I
can imagine circumstances in which it might (in the future) spawn an
auxiliary pthread for some reason, and I wouldn't want to rule that out.

> - The spawned thread sends the Scheme object to the condition variable
> as soon as the user thunk exits.  Any number of operations can happen
> afterwards; the thread is still running in Scheme-land at this point,
> in call-with-new-thread’s wrapping thunk.
> - join-thread waits on the condition variable only.

These are implementation details.  They are correct but probably the
implementation should change to do the scm_i_pthread_join and we should
guarantee that after the join, the thread is really dead.  This is bug
26858.

> So at the end of join-thread we need to add a call to
> scm_i_pthread_join (which we implement in threads.c) to ensure that
> the pthread is completely gone before that join-thread returns.  Is
> that accurate?

Well... yes, but we have to ensure that we call scm_i_pthread_join at
most once.  I think calling pthread_join twice on a thread is
undefined.  So there are some gnarlies here.  Need to fix this.

> Unfortunately, I think the GC threads are going to end up being
> immovable objects in the path to full process-form support.

You can disable marker threads with the GC_MARKERS environment variable,
and the finalization thread should come and go as needed.  Probably this
is not a blocker from your POV.  Signal handling is probably the most
serious issue; perhaps we can avoid the thread somehow, since we handle
signals asynchronously anyway..

Andy

bug#26675: guile-2.2.0 in GNU/Hurd

[Andy Wingo]

On Thu 27 Apr 2017 04:35, rennes  writes:

> We are testing guile-2.2.0 in GNU/Hurd, we have passed the build phase  
> setting "--disable-largefile" parameter to configure script.
> On the other hand in the check phase, get the error:
>
> wrote  
> `/tmp/guix-build-guile-2.2.0.drv-0/guile-2.2.0/cache/guile/ccache/2.2-LE-4-3.9/tmp/guix-build-guile-2.2.0.drv-0/guile-2.2.0/test-suite/standalone/test-out-of-memory.go'
> Backtrace:
> 7 (apply-smob/1 #)
> In ice-9/boot-9.scm:
>  710:2  6 (call-with-prompt _ _ #)
> In ice-9/eval.scm:
>  619:8  5 (_ #(#(#)))
> In ice-9/boot-9.scm:
> 2309:4  4 (save-module-excursion _)
>3816:12  3 (_)
> In ./test-out-of-memory:
>   53:0  2 (_)
> In ice-9/boot-9.scm:
>  834:9  1 (catch _ _ #  
> ?)
> In unknown file:
> 0 (scm-error misc-error #f "~A" ("should not be reached") #)
>
> ERROR: In procedure scm-error:
> ERROR: should not be reached
> FAIL: test-out-of-memory

This means that your "setrlimit" is incapable of limiting your memory
usage.  A Hurd bug?

Andy

bug#26151: date-year-day screws up leap days prior to AD 1

[Andy Wingo]

On Sat 18 Mar 2017 02:10, Zefram  writes:

> If I had implemented SRFI-19 myself, without reference to existing
> implementations, I would have implemented astronomical year numbering
> (consistent AD year numbering, extending linearly in both directions),
> as used in ISO 8601.  This is the most conventional year numbering,
> and at a stretch one could read SRFI-19 as implying it, by using some AD
> year numbering and not saying to deviate from that scheme.  But really the
> standard is silent on the issue.  Since the signification of date-year is
> an interoperability issue, this silence is a problem, and it is troubling
> that you and I have reached different interpretations of the standard
> on this point.
>
> Where did you get the idea to use a non-linear year numbering?  What's
> your opinion of SRFI-19's (lack of) text on this matter?  You should
> consider the possibility of changing your implementation to use the
> conventional astronomical year numbering in this slot.

For what it's worth the "you" in your message refers to "hackers of
yore" ;-) I mean, this code's core was last changed in 2001 by a Guile
maintainer a few generations back.  The fact that it's lasted this long
does indicates that it's generally acceptable, but the fact that you
have found so many bugs indicates that there are parts of it that aren't
so good.  And it's old old code that needs modernizing (proper data
structures, pattern matching, and so on).

What I mean to say is that if there's a more sensible thing to do, we
can do it.

To answer your specific question: would this be an ABI change in some
way, or can we make this change in 2.2?

Andy

bug#26149: SRFI-19 doc erroneously warns about Gregorian reform

[Andy Wingo]

On Wed 19 Apr 2017 18:11, Zefram  writes:

> Andy Wingo wrote:
>>This makes sense to me, FWIW.
>
> Patch attached.

Thank you!  Applied.  I adapted the change log message to follow Guile
conventions; it was:

> From 444703940983d559935c4dd2a2c89d7888c67119 Mon Sep 17 00:00:00 2001
> From: Zefram 
> Date: Wed, 19 Apr 2017 17:08:30 +0100
> Subject: [PATCH] correct note about Gregorian reform in SRFI-19
>
> SRFI-19 specifies proleptic use of the Gregorian calendar, so it was
> incorrect of the documentation to describe the code as erroneous in
> doing so.  Rewrite the caution more neutrally, and move it to the section
> about the "date" structure, where it seems most relevant.

As applied:

Correct note about Gregorian reform in SRFI-19

* doc/ref/srfi-modules.texi (SRFI-19): SRFI-19 specifies proleptic use
of the Gregorian calendar, so it was incorrect of the documentation to
describe the code as erroneous in doing so.  Rewrite the caution more
neutrally, and move it to the section about the "date" structure, where
it seems most relevant.

Note capitalization of the summary line and an inclusion of the file and
section/function in the commit message.  I know the file is redundant
but this is how we currently do it.  If you use Emacs and Magit,
pressing "C" (capital) in a Magit diff will add this info to the commit
log for you.

Andy

bug#26583: 2.2.1 syntax objects are not comparable

[Andy Wingo]

On Thu 20 Apr 2017 22:52, l...@gnu.org (Ludovic Courtès) writes:

> The “new” syntax objects in 2.2.1 cannot be compared with ‘equal?’,
> unlike the “old” ones, which were just vectors.

I think this is a bug.  We can roll another release today.

Andy

bug#26013: (srfi srfi-37) chokes on empty string parameter

[Andy Wingo]

On Wed 19 Apr 2017 18:32, Thomas Danckaert  writes:

>> On Tue 07 Mar 2017 16:34, Thomas Danckaert 
>> writes:
>>
>>> It looks like Guile's srfi-37 implementation doesn't process empty
>>> string arguments correctly.
> I don't fully understand the code in srfi-37.scm, but I think the fix
> can be as simple as the attached patch (i.e. first check if the argument
> is empty, otherwise check if it starts with \#-).

Applied, thanks :)

Andy

bug#26570: GC_is_heap_ptr() dep for 2.2.1

[Andy Wingo]

On Thu 20 Apr 2017 01:19, Zefram  writes:

> Compilation of 2.2.1 fails for me, producing a lot of warnings about
> implicit declaration of GC_is_heap_ptr(), and ultimately
>
>   CCLD guile
> ./.libs/libguile-2.2.so: undefined reference to `GC_is_heap_ptr'
> collect2: error: ld returned 1 exit status
> Makefile:2439: recipe for target 'guile' failed
> make[3]: *** [guile] Error 1
>
> At a guess, maybe this is supposed to be supplied by libgc.  But I have
> the version of libgc that README says is required (7.2), and configure
> was happy with it.  Maybe a higher version is now required, and README
> and configure need updating?

I think I fixed this in Git.  Please take a look.  Cheers :)

Andy

bug#26570: GC_is_heap_ptr() dep for 2.2.1

[Andy Wingo]

On Thu 20 Apr 2017 01:19, Zefram  writes:

> Compilation of 2.2.1 fails for me, producing a lot of warnings about
> implicit declaration of GC_is_heap_ptr(), and ultimately
>
>   CCLD guile
> ./.libs/libguile-2.2.so: undefined reference to `GC_is_heap_ptr'
> collect2: error: ld returned 1 exit status
> Makefile:2439: recipe for target 'guile' failed
> make[3]: *** [guile] Error 1
>
> At a guess, maybe this is supposed to be supplied by libgc.  But I have
> the version of libgc that README says is required (7.2), and configure
> was happy with it.  Maybe a higher version is now required, and README
> and configure need updating?

Thanks for the note.  It certainly wasn't my intention to require a
newer libgc.  I will look into what needs doing here.

Andy

bug#25509: FreeBSD 11.0

[Andy Wingo]

On Thu 16 Mar 2017 04:11, Matt Wette  writes:

> HI saffron,
>
> I have been able to get guile-2.1.8 to build on FreeBSD 11.0.
>
> I had to “pkg install” : pkgconf, gmake, boehm-gc-threaded
>
> Then to work around following config issue, I “pkg install autotools”
> Edit autoconf.ac and find “bdw-gc”, change to “bdw-gc-threaded”
> PKG_CHECK_MODULES([BDW_GC], [bdw-gc-threaded >= 7.2])
>
> Then run autoconf, then ./configure —prefix=/usr/local, then gmake (make did 
> not work for me), but takes hours.
>
> Then “make check”.  

Given this report, I'll close this bug.  Thanks all :)

Andy

bug#25803: [PATCH] guile-snarf: skip -g* arguments to avoid build failure

[Andy Wingo]

On Sun 19 Feb 2017 23:58, Sergei Trofimovich  writes:

> The fix is to ignore -g* flags. They should only affect debugging output.
>
> * libguile/guile-snarf.in: skip -g* arguments to avoid build failure

Applied.  Thanks :)

Andy

bug#25804: [PATCH] api-procedures.texi: typo: 'an' -> 'on'

[Andy Wingo]

On Mon 20 Feb 2017 00:02, Sergei Trofimovich  writes:

> * doc/ref/api-procedures.texi: fix typo 'an' -> 'on'

Applied.  Thanks :)

Andy

bug#25805: [PATCH] tweak 'u+0007' to 'U+0007' (as the rest of the table)

[Andy Wingo]

On Mon 20 Feb 2017 00:02, Sergei Trofimovich  writes:

> * doc/ref/api-data.texi: tweak codepoint notation

Applied; thanks!

Andy

bug#26013: (srfi srfi-37) chokes on empty string parameter

[Andy Wingo]

On Tue 07 Mar 2017 16:34, Thomas Danckaert  writes:

> It looks like Guile's srfi-37 implementation doesn't process empty
> string arguments correctly.  For example, here's a stacktrace I get when
> executing guix system list-generations "":
>
> $ guix system list-generations ""
> Backtrace:
> In ice-9/boot-9.scm:
>  160: 15 [catch #t # ...]
> In unknown file:
>?: 14 [apply-smob/1 #]
> In ice-9/boot-9.scm:
>   66: 13 [call-with-prompt prompt0 ...]
> In ice-9/eval.scm:
>  432: 12 [eval # #]
> In ice-9/boot-9.scm:
> 2404: 11 [save-module-excursion # ice-9/boot-9.scm:4051:3 ()>]
> 4056: 10 [#]
> 1727: 9 [%start-stack load-stack ...]
> 1732: 8 [#]
> In unknown file:
>?: 7 [primitive-load
> "/gnu/store/hnbqdmfh1bwma8nmpai6ci76h5j6bl7j-guix-0.12.0-4.d9da/bin/.guix-real"]
> In guix/ui.scm:
> 1228: 6 [run-guix-command system "list-generations" ""]
> In ice-9/boot-9.scm:
>  160: 5 [catch srfi-34 # ...]
>  160: 4 [catch system-error ...]
> In guix/scripts/system.scm:
>  947: 3 [#]
> In ice-9/boot-9.scm:
>  160: 2 [catch misc-error # ()> ...]
> In srfi/srfi-37.scm:
>  220: 1 [next-arg]
> In unknown file:
>?: 0 [string-ref "" 0]
>
> ERROR: In procedure string-ref:
> ERROR: Value out of range: 0

Sounds like the right diagnosis to me.  Want to submit a patch? :)

Andy

bug#26026: Defining a method named zero? breaks primitive zero?

[Andy Wingo]

On Wed 08 Mar 2017 12:07, Alejandro Sanchez  writes:

> If I define a ‘zero?’ predicate method for a custom class the primitive 
> ‘zero?’ is lost. Here is a simple vector module:
>
>   ;;; File vector2.scm
>   (define-module (vector2)
> #:use-module (oop goops)
> #:export ( get-x get-y zero?))
>   
>   (define-class  ()
> (x #:init-value 0 #:getter get-x #:init-keyword #:x)
> (y #:init-value 0 #:getter get-y #:init-keyword #:y) )
>
>   (define-generic zero?)
>   (define-method (zero? (v ))
> (and (zero? (get-x v))
>  (zero? (get-y v
>
> In the Guile REPL try executing the following code:
>
>   scheme@(guile-user)> (use-modules (oop goops) (vector2))
>   scheme@(guile-user)> (zero? (make ))
>
> This will display 
>
>   WARNING: (guile-user): `zero?' imported from both (ice-9 r5rs) and 
> (vector2)
>   ERROR: In procedure scm-error:
>   ERROR: No applicable method for #< zero? (1)> in call (zero? 0)
>   
>   Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
>   scheme@(guile-user) [1]> ,bt
>   In vector2.scm:
>11:7  2 (_ #< 105e87e00>)
>   In oop/goops.scm:
>  1438:4  1 (cache-miss 0)
>   In unknown file:
>  0 (scm-error goops-error #f "No applicable method for ~S in 
> call ~S" (#< …) …)
>
> Apparently the problem is that ‘zero?’ is defined in two modules and
> the vector2 definition overrides it. This isn’t the case with other
> primitives like ‘+’ or ‘*’, so this seems like a bug? I had built
> Guile from HEAD a few days ago, my package manager shows 6fff84d as
> the version number, so I guess that must be the hash of the commit
> HEAD was pointing to at that time.

Actually the (vector2) module makes a fresh definition for zero?.  You
can tell because zero? is in its export list.  So instead of extending
the primitive-generic that is zero?, you are making a new definition.
See:

  scheme@(guile-user)> (define-module (foo) #:export (zero?))
  $1 = #
  scheme@(foo)> (zero? 0)
  :4:0: :4:0: Unbound variable: zero?

  Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.

If you want to extend a primitive-generic, then do that by not exporting
zero?.  In a way it's like mutating the primitive in place, giving it
additional powers.

Andy

bug#26027: (system vm trace) creates no output

[Andy Wingo]

On Wed 08 Mar 2017 18:01, Mike Gran  writes:

> Hi-
> I created the following file, which I ran under guile-2.0 and master.
> There is no tracing output. What am I misunderstanding?
> (use-modules 
> (system vm trace)) 
>
> (define (write-hi) 
> (write "hi")) 
>
> (define (outer) 
> (write-hi)) 
>
> (trace-calls-to-procedure write-hi) 
> (trace-calls-in-procedure write-hi) 
> (trace-instructions-in-procedure write-hi) 
> (outer) 

Weird.  From an initial glance I don't know why this isn't working.
Irritating!

Andy

bug#26106: Defining a method named '-' with one parameter

[Andy Wingo]

On Wed 15 Mar 2017 14:35, Alejandro Sanchez  writes:

> If I define a method named ‘-‘ which only takes in one parameter, the 
> expression ‘(- v)’ gets rewritten to ‘(- 0 v)’. Here is a minimal example:
>
>   (use-modules (oop goops))
>   
>   (define-class  ()
> (x #:init-value 0 #:getter get-x #:init-keyword #:x)
> (y #:init-value 0 #:getter get-y #:init-keyword #:y))
>   
>   (define-method (* (n ) (v ))
> (make  #:x (* n (get-x v)) #:y (* n (get-y v
>   
>   (define-method (- (v ))
> (* -1 v))
>   
>   (define v (make  #:x 1 #:y 2))
>   (* -1 v)  ; Works fine
>   (- v)  ; Throws error
>
> Here is the error message:
>
>   scheme@(guile-user)> (- v)
>   ERROR: In procedure scm-error:
>   ERROR: No applicable method for #< - (2)> in call (- 0 
> #< 10a8e4020>)
>   
>   Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
>   scheme@(guile-user) [1]> ,bt
>   In current input:
>23:0  2 (_)
>   In oop/goops.scm:
>  1438:4  1 (cache-miss 0 #< 10a8e4020>)
>   In unknown file:
>  0 (scm-error goops-error #f "No applicable method for ~S in 
> call ~S" (#< - (2)> (- 0 #<)) #)

Is (- x) equivalent to (* x -1) ?

Right now there are a few things happening.  The "primitive expansion"
phase in an early part of the compiler turns (- x) to (- 0 x), where
obviously it should not be doing that.  But can it turn it into (* x -1)
?  Note that somewhat confusingly, a later part of the compiler that can
detect when X is a real number will undo that transformation, turning it
to (- 0 x) when X is real.  So that sounds OK from an optimization point
of view but is the (* x -1) tranformation correct from the math point of
view?

Andy

bug#26123: guile-2.2.0: AI_ADDRCONFIG

[Andy Wingo]

On Fri 17 Mar 2017 14:11,  writes:

>  Thomas Klausner  wrote: 
>> 
>>   SNARF  net_db.doc
>> net_db.c:468:***Missing or erroneous `#define FUNC_NAME s_AI_ADDRCONFIG);'
>> net_db.c:488:***Missing or erroneous #undef for AI_ADDRCONFIG);:
>> 
>> Compilation continues even though this looks like an error.
>
> Yeah,  while annoying, this is harmless.
>
> The proper fix in my opinion is to limit the regular expression on line
> 28 in libguile/guile-func-name-check to only match function definition
> macros.  Currently, it matches other macros that define things other
> than functions, and so erroneously looks for a function body.
>
> For example, adding a space like /^SCM_DEFINE / would probably be 
> appropriate.  However, that would prevent it from matching any other function 
> defining macros, if they exist.

Good idea, done.  Thanks :)

ANdy

bug#26128: 1 of 1 test failed

[Andy Wingo]

On Thu 16 Mar 2017 16:45, Jean Louis  writes:

> Hello,
>
> This may help you, it failed on 2.2. Maybe not serious.
>
> Jean
>
> Running peval.test
> Running poe.test
> Running popen.test
> Running ports.test
> warning: call to primitive-fork while multiple threads are running;
>  further behavior unspecified.  See "Processes" in the
>  manual, for more information.
> Running posix.test
> In execvp of something-that-does-not-exist: No such file or directory
> Running print.test
> Running procprop.test
> Running procs.test
> Running q.test
> Running r4rs.test
> Backtrace:
>4 (primitive-load "/sources/guile-2.2.0/test-suite/tests/\u2026")
> In ice-9/boot-9.scm:
> 152:2  3 (with-fluid* _ _ _)
> In ice-9/eval.scm:
> 163:9  2 (_ #(#(# # \u2026)))
> In ice-9/ports.scm:
> 549:4  1 (call-with-output-string _)
> In unknown file:
>0 Exception thrown while printing backtrace:
> ERROR: In procedure ttyname: Success
>
> ERROR: In procedure write:
> ERROR: In procedure ttyname: Success
> FAIL: check-guile

What platform is this?

Andy

bug#26149: SRFI-19 doc erroneously warns about Gregorian reform

[Andy Wingo]

On Sat 18 Mar 2017 00:53, Zefram  writes:

> The documentation, near the start of the section on SRFI-19, says
>
> !*Caution*: The current code in this module incorrectly extends the
> ! Gregorian calendar leap year rule back prior to the introduction of
> ! those reforms in 1582 (or the appropriate year in various countries).
> ! The Julian calendar was used prior to 1582, and there were 10 days
> ! skipped for the reform, but the code doesn't implement that.
> !
> !This will be fixed some time.  Until then calculations for 1583
> ! onwards are correct, but prior to that any day/month/year and day of the
> ! week calculations are wrong.
>
> The statements that the code is incorrect in this behaviour are erroneous.
> SRFI-19 itself says
>
> # A Date object, which is distinct from all existing types, represents a
> # point in time as represented by the Gregorian calendar as well as by a
> # time zone.
>
> The code is thus correct in always using the Gregorian calendar in
> date structures.  Per ISO 8601 it is also correct in always using
> the Gregorian calendar in string output in that standard's formats.
> SRFI-19 isn't explicit about the calendar used as the basis for the
> other string output formats, but since the formatting proceeds from a
> date structure it seems implied that they should use the same basis as
> the date structure.  For string input it is explicit that the parseable
> numeric formats correspond directly to fields of the date structure.
> There is no part of SRFI-19 that looks like it is ever intended to use
> the Julian calendar.
>
> So the code should not be `fixed', and the statements about that and about
> incorrectness should be removed from the documentation.  It is sensible to
> keep an explicit statement about the treatment of the Gregorian reform,
> but the decision to use the Gregorian calendar proleptically should be
> credited to SRFI-19 (the standard), not to the code.

This makes sense to me, FWIW.

Andy

bug#26164: time-difference mishandles leap seconds

[Andy Wingo]

On Sat 18 Mar 2017 23:41, Zefram  writes:

> Computing the duration of the period between two UTC times, using
> SRFI-19 mechanisms:
>
> scheme@(guile-user)> (use-modules (srfi srfi-19))
> scheme@(guile-user)> (define t0 (date->time-utc (make-date 0 59 59 23 30 6 
> 2012 0))) 
> scheme@(guile-user)> (define t1 (date->time-utc (make-date 0 1 0 0 1 7 2012 
> 0)))
> scheme@(guile-user)> (time-difference t1 t0)
> $1 = #
>
> The two times are 2012-06-30T23:59:59 and 2012-07-01T00:00:01, so at
> first glance one would expect the duration to be 2 s as shown above,
> the two seconds being 23:59:59 and 00:00:00.  But in fact there was
> a leap second 2012-06-30T23:59:60, so the duration of this period is
> actually 3 s.  The SRFI-19 library is aware of this leap second, and
> will compute the duration correctly if it's translated into TAI:
>
> scheme@(guile-user)> (time-difference (time-utc->time-tai t1) 
> (time-utc->time-tai t0))
> $2 = #
>
> The original computation in UTC space should yield a result of 3 s,
> not the 2 s that it did.  Since 1972, the seconds of UTC are of exactly
> the same duration as the seconds of TAI.  (They're also phase-locked to
> TAI seconds.)  Thus the period of three TAI seconds is also a period of
> three UTC seconds.  It is not somehow squeezed into two UTC seconds.

Makes sense to me.  Would you like to submit a patch and test case?  I
would be happy to apply it.

Andy

bug#26172: [PATCH] bug: statprof flat display writes summary lines to current-output-port instead of the provided port

[Andy Wingo]

On Sun 19 Mar 2017 16:26, Freja Nordsiek  writes:

> Small bug I found when using the statprof module when using the
> statprof procedure with a flat display. The summary lines at the end
> are not written to the port provided as an argument and are instead
> written to (current-output-port). A patch is attached, which just
> makes the format statements use port instead of #t.

Applied; thanks!

bug#26182: cond-expand doc omits guile-2.2 feature

[Andy Wingo]

On Mon 20 Mar 2017 02:22, Zefram  writes:

> As implemented in Guile 2.2.0, the unlisted feature guile-2.2 is also
> recognised by cond-expand.

Added to doc; tx for report.

Andy

bug#26183: patch for guile-2.2.0 on FreeBSD 11.0

[Andy Wingo]

On Mon 20 Mar 2017 02:39, Matt Wette  writes:

> Attached is a patch to apply to guile-2.2.0 to compile on FreeBSD 11.0
> Changes
> 1) updated README to indicate which extra FreeBSD packages need to be 
> installed
> 2) minor change to configure.ac (implies autoconf needs to run) to use 
> bdw-gc-threaded instead of bdw-gc
> With this, I had successful configure, gmake, and gmake check.

Applied with some adaptations.  Please see git master and test.  Thanks!

Andy

bug#26188: Minor typo in manual (7.20.5 SXML Tree Fold)

[Andy Wingo]

Hi,

On Mon 20 Mar 2017 07:10, Arun Isaac  writes:

> In the second line of the argument specification of scheme procedure
> `fold-layout', "handler-pair" is misspelt as "bandler-pair".

Thanks, fixed.  Patches welcome in the future too :)

Andy

bug#26240: Guile doesn't search for libraries installed in /usr/lib64

[Andy Wingo]

On Fri 24 Mar 2017 17:59, "Stewart, Adam James"  writes:

> $ ls -l /usr/lib64/libltdl.so.7*
> lrwxrwxrwx 1 root root 16 Feb 27 11:19 /usr/lib64/libltdl.so.7 -> 
> libltdl.so.7.3.0
> -rwxr-xr-x 1 root root 41248 Feb 16 2016 /usr/lib64/libltdl.so.7.3.0
>
> Do you have any suggestions as to how I can get Guile to pick up libraries 
> installed in /usr/lib64?

I believe this indicates that you don't have libltdl development
packages installed.  Check on your distro for "ltdl-dev" or similar
packages.  Normally if your distro installs things to /usr/lib64, then
it adds it to all the normal search paths.

Andy

bug#26259: ~f SRFI-19 format broken for small nanoseconds values

[Andy Wingo]

On Sun 26 Mar 2017 04:00, Zefram  writes:

> scheme@(guile-user)> (date->string (make-date 55 56 34 12 26 3 2017 0) 
> "~f")
> $2 = "56.5e-4"

Thanks for the report.  Fixed in the the fix for #26260; added the test
case anyway.  Cheers.

Andy

bug#26260: ~f SRFI-19 format specifier mishandles one-digit seconds value

[Andy Wingo]

thanks

bug#26260: ~f SRFI-19 format specifier mishandles one-digit seconds value

[Andy Wingo]

On Sun 26 Mar 2017 04:09, Zefram  writes:

> The ~f format specifier for SRFI-19's date->string is documented as:
>
> #~f seconds and fractional seconds, with locale
> #   decimal point, eg. `5.2'
>
> Let's test that example:
>
> scheme@(guile-user)> (use-modules (srfi srfi-19))
> scheme@(guile-user)> (date->string (make-date 2 5 34 12 26 3 2017 0) 
> "~f")
> $1 = "05.2"
>
> That's not the documented format: the doc and the SRFI itself show "5.2"
> with no leading padding, but actual behaviour is to zero pad.  There is
> much that is ambiguous in the SRFI's specification of ~f, but with that
> example it does at least seem clear that there should be no padding there.

Fixed in git; thanks for the report :)

Andy

bug#26261: ~N mishandles small nanoseconds value

[Andy Wingo]

On Mon 27 Mar 2017 18:06, Andrew Moss  writes:

> I believe I have fixed this bug, but I'm not sure if I put the test
> case in the right place within the file. Please see the attached
> patch.
>
> From e975f8ae8d494985a51faed5b15c5664a557e0e2 Mon Sep 17 00:00:00 2001
> From: Andrew Moss 
> Date: Mon, 27 Mar 2017 11:58:29 -0400
> Subject: [PATCH] Fixed bug: ~N mishandles small nanoseconds value
>
> Fixes .
> Reported by Zefram .
>
> * module/srfi/srfi-19.scm ("define directives"): N padding increased from 7 
> to 9
>
> * test-suite/tests/srfi-19.test ("date->string"): New test.

Applied.  Thank you very very much for the fix!

Andy

bug#26329: monotonic time not supplied by current-time

[Andy Wingo]

On Sat 01 Apr 2017 13:18, Zefram  writes:

> The SRFI-19 current-time function can return several flavours of the
> current time:
>
> scheme@(guile-user)> (use-modules (srfi srfi-19))
> scheme@(guile-user)> (current-time time-utc)
> $1 = #
> scheme@(guile-user)> (current-time time-tai)
> $2 = #
> scheme@(guile-user)> (current-time time-monotonic)
> $3 = #
>
> The last of these three is erroneous: a time structure of type
> time-monotonic was requested and must be returned, but instead the
> type is time-tai.

Thanks for the report; fixed.  Patches welcome too.

Andy

bug#26351: Out of Memory tests failing on i686 and Power64

[Andy Wingo]

On Mon 03 Apr 2017 18:04, John Dulaney  writes:

> I am consistently getting the out of memory test to fail on i686 and 64 bit
> Power.
>
> Build logs are as follows:
>
> i686 on Fedora Rawhide (what will be F27):
> https://kojipkgs.fedoraproject.org//work/tasks/4744/18694744/build.log
>
> 64 bit Power, also Rawhide:
> https://kojipkgs.fedoraproject.org//work/tasks/4743/18694743/build.log
>
> 64 bit Power for RHEL/CENTOS 7:
> https://kojipkgs.fedoraproject.org//work/tasks/4805/18694805/build.log
>
> I should note that Little Endian 64 bit Power does, in fact, pass the test:
> https://kojipkgs.fedoraproject.org//work/tasks/4740/18694740/build.log

Unfortunately these logs are no longer available.  Are there any more
recent ones?

Andy

bug#26476: Help for C primitives not found

[Andy Wingo]

On Thu 13 Apr 2017 13:25,  writes:

> So.  (help cons) is no longer working for me with 2.2.
>
> The output of
>
>  echo '(help cons)' | strace guile
>
> shows
>
> stat("/usr/local/share/guile/guile-procedures.txt", 0x7ffd5f923330) = -1 
> ENOENT (No such file or directory)
> stat("/usr/local/share/guile/site/2.2/guile-procedures.txt", 0x7ffd5f923330) 
> = -1 ENOENT (No such file or directory)
> stat("./guile-procedures.txt", 0x7ffd5f923330) = -1 ENOENT (No such file or 
> directory)
> write(1, "No documentation found for:\n", 28No documentation found for:

I believe you miss a line previously that looks for
/usr/local/share/guile/2.2/guile-procedures.txt and succeeds.  I think
there is no general problem, only a specific problem that "cons" doesn't
have documentation any more, I guess related to inline function
definition things.

Andy

bug#26503: Local variables reclaimed early vs. finalizers

[Andy Wingo]

On Wed 19 Apr 2017 11:50, l...@gnu.org (Ludovic Courtès) writes:

> I need to chew a bit more on this, but the conclusion is probably that
> my expectations were incorrect, indeed.  :-)

OK I close this bug in the meantime then :)  Feel free to reopen if
there is a thing to do!

Andy

bug#26542: guile 2.0.13

[Andy Wingo]

Hi,

ro...@web.de writes:

> Hello,
>
> The attached simple test calls free functions with bad smob_tag.
> I see the same stuff with 2.2.0
> There are no errors using the stable 2.0.11 version.
>
> static size_t
> free_box (SCM box_smob)
> {
>   if (SCM_TYP16(box_smob) != scm_tc16_box) {
>   // bad type, do not free it
>   fprintf (stderr, "[free] error: bad smob 0x%x\n", 
> (int)SCM_TYP16(box_smob));
>   exit (-1);
>   }
>   return 0;
> }

I believe this is fallout from this bug fix in which markers and
finalizers could race each other:

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=19883

The basic issue is that finalizers run asynchronously on values that are
still live, yet they can invalidate invariants on those live values.
Concurrent markers can then see objects which are being concurrently
finalized, causing intermittent hard-to-debug crashes that couldn't be
properly fixed.

The fix was to "null out" the SMOB tag before calling the finalizer, in
such a way to prevent future GCs from invoking the SMOB mark function on
an object that was being finalized.  So the new expectation is that
finalizers see the SMOB tag as being scm_tc7_smob + SMOB number 0,
indicating the "finalized" smob type.

I guess we weren't aware of how this might affect other users that check
the SMOB tag during the free function.  Apologies for that undocumented
change.  It was necessary though to fix 19883.

Andy

bug#26503: Local variables reclaimed early vs. finalizers

[Andy Wingo]

l...@gnu.org (Ludovic Courtès) writes:

> Consider this code:
>
> (use-modules (system foreign))
>
> (define %abort
>   (dynamic-func "abort" (dynamic-link)))
>
> (let ((ptr (make-pointer 123 %abort)))
>   (display "hello\n")
>   (gc))
>
> Guile is free to collect ‘ptr’ when ‘gc’ is called since it has become
> unreachable at that point; that’s what 2.2.0 does, as explained in
> ‘NEWS’.
>
> However, there’s a finalizer here so collecting ‘ptr’ has an observable
> side effect.  This side effect makes the semantic change visible: the
> “expected” semantics would be that ‘ptr’ is not subject to GC while it’s
> in scope.

This would indicate that the user has erroneous expectations ;-)

Note that here since (gc) is in tail position, ptr is in fact not
protected in any way, even given this mental model, though with a single
thread it may be that the collection actually happens later in 2.0 given
that finalizers are run by asyncs.  Also ptr is not protected during the
"display" either, in 2.0; in 2.0 this "let" reduces to "begin" under
peval since the ptr is not used.

> (In 2.0 the finalizer is not called until ‘ptr’ is no longer in scope.)
>
> I’m not sure this counts as a bug, but it’s certainly a pitfall when
> working with finalizers and the FFI.
>
> Thoughts?

For me, I don't think this is a bug.  Rather the contrary, as it's more
in spirit with safe-for-space principle that a continuation should only
keep alive those values that it uses; any other data should be available
for the GC to reclaim.

In any case, I think this manual section treats the problem adequately,
for me at least:

  
https://www.gnu.org/software/guile/manual/html_node/Foreign-Object-Memory-Management.html

Would you like to add something there?

Andy

bug#26058: utf16->string and utf32->string don't conform to R6RS

[Andy Wingo]

On Tue 14 Mar 2017 16:03, taylanbayi...@gmail.com (Taylan Ulrich 
"Bayırlı/Kammer") writes:

> Andy Wingo  writes:
>
>> On Mon 13 Mar 2017 19:10, taylanbayi...@gmail.com (Taylan Ulrich 
>> "Bayırlı/Kammer") writes:
>>
>>> If I do binary I/O, the following situations are possible:
>>>
>>> 1. I'm guaranteed to get any possible bytes that happen to form a valid
>>>BOM at the start of the stream as-is in the returned bytevector; the
>>>binary I/O interface doesn't see such bytes as anything special, as
>>>it could simply be coincidence that the stream starts with such
>>>bytes.
>>
>> (1).  But I thought this bug was about using a bytevector as a source
>> and then doing textual I/O on it, no?
>
> I have a feeling we're somehow talking past each other. :-) As far as
> I'm concerned, the bug is just that the procedures don't conform to the
> specification.
>
> It would of course be good if the behavior of these procedures was
> somehow in harmony with the behavior of I/O operations, but I don't see
> any issues arising from adopting the R6RS behavior of the procedures
> utf16->string and utf32->string.  Do you?

Adopting the behavior is more or less fine.  If it can be done while
relying on the existing behavior, that is better than something ad-hoc
in a module.

Andy

bug#24657: Autoconf macro GUILE_PROGS only looks for guile without version suffix even if given version - patch included

[Andy Wingo]

On Tue 14 Mar 2017 15:25, Freja Nordsiek  writes:

> Found a bug in the modifications you made. Sorry for not catching this
> before it got included into the Guile 2.1.8 release.

Thank you!  Applied.  Note that in the gnu coding standards you need an
entry in the commit log for every file you modify.  Blah, I know, but
that's how it is.

Andy

bug#25791: address argument to atomic operation must be a pointer to _Atomic type with 2.1.7 on macOS

[Andy Wingo]

On Wed 01 Mar 2017 17:43, Andy Wingo  writes:

> On Sun 19 Feb 2017 09:41, ilove zfs  writes:
>
>> On macOS 10.11 and 10.12 building with Xcode 8, guile 2.1.7 fails to
>> compile with several errors saying "address argument to atomic
>> operation must be a pointer to _Atomic type." I
>> can avoid this by setting ac_cv_header_stdatomic_h=no.
>>
>> Build logs here:
>> https://gist.github.com/ilovezfs/b18b7e6160e0a4c5da297cc430961f63
>> https://gist.github.com/57e1513e03ede26dc97c0f63eaad3a98
>>
>> Build failure is
>> ```
>>   CC   libguile_2.2_la-arrays.lo
>>   CC   libguile_2.2_la-async.lo
>> In file included from async.c:27:
>> ../libguile/atomics-internal.h:37:10: error: address argument to
>> atomic operation must be a pointer to _Atomic type ('gl_uint32_t *'
>> (aka 'unsigned int *') invalid)
>>   return atomic_fetch_sub (loc, arg);
>>  ^ ~~~
>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/8.0.0/include/stdatomic.h:149:43:
>> note: expanded from macro 'atomic_fetch_sub'
>> #define atomic_fetch_sub(object, operand) __c11_atomic_fetch_sub(object, 
>> operand, __ATOMIC_SEQ_CST)
>> ```
>> and several similar errors.
>>
>> Previously (as of guile 2.1.4) I had been able to work around the issue 
>> without setting ac_cv_header_stdatomic_h=no with this patch:
>> https://raw.githubusercontent.com/ilovezfs/formula-patches/d2798a468346a7a28fbcd1c8aa3c1ccd5627b03f/guile/guile-atomic-type.patch
>>
>> However, the patch is no longer sufficient since now void** is one the types 
>> needing _Atomic, which isn't allowed.
>
> Any ideas here?  Sure would be nice to release a Guile with atomics that
> compiles with clang.

Fixed in 2.1.8 I think.

Andy

bug#25912: 2.1.7 segfaults on cygwin

[Andy Wingo]

On Fri 03 Mar 2017 15:32, Mike Gran  writes:

> I also can replicate the Cygwin problem as originally described.

I understand that with the fix in 2.1.8, that things are working
correctly now; closing the report.  Thanks for the sleuthing, szgyg and
Mike!

Andy

bug#25923: pkgsrc patches: improve mkostemp support

[Andy Wingo]

On Wed 01 Mar 2017 21:29, Thomas Klausner  writes:

> --- libguile/filesys.c.orig   2016-12-15 00:03:33.0 +
> +++ libguile/filesys.c
> @@ -1486,6 +1486,15 @@ SCM_DEFINE (scm_i_mkstemp, "mkstemp!", 1
>mode_bits = scm_i_mode_bits (mode);
>  }
>  
> +#ifdef __APPLE__
> +  /* https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24862#23 */
> +  open_flags &= O_APPEND|O_SHLOCK|O_EXLOCK|O_CLOEXEC;
> +#endif
> +#ifdef __NetBSD__
> +  /* Restrict to list of flags documented in man page. */
> +  open_flags &= O_APPEND|O_DIRECT|O_SHLOCK|O_EXLOCK|O_SYNC|O_CLOEXEC;
> +#endif
> +
>SCM_SYSCALL (rv = mkostemp (c_tmpl, open_flags));
>if (rv == -1)
>  SCM_SYSERROR;

I believe this was fixed in 2.1.6 as well so you can drop this one too.

Cheers,

Andy

bug#25922: pkgsrc patches: older Darwin support

[Andy Wingo]

On Wed 01 Mar 2017 21:28, Thomas Klausner  writes:

> Another pkgsrc patch concerns itself with supporting older Darwin
> releases, attached. Can you please merge it?
>  Thomas
>
> $NetBSD: patch-libguile_stime.c,v 1.1 2016/10/19 14:56:17 adam Exp $
>
> Fix building on Darwin.
>
> --- libguile/stime.c.orig 2016-10-19 07:55:02.0 +
> +++ libguile/stime.c
> @@ -828,7 +828,7 @@ scm_init_stime()
>if (clock_gettime (CLOCK_REALTIME, &posix_real_time_base) == 0)
>  get_internal_real_time = get_internal_real_time_posix_timer;
>  
> -#ifdef HAVE_POSIX_CPUTIME
> +#if defined(HAVE_POSIX_CPUTIME) && defined(HAVE_CLOCK_GETCPUCLOCKID)
>{
>  clockid_t dummy;
>  

I believe this was fixed in 2.1.6, so I think you can drop this one.

Andy

bug#25921: pkgsrc patches: Dragonfly support

[Andy Wingo]

On Wed 01 Mar 2017 21:27, Thomas Klausner  writes:

> $NetBSD: patch-lib_signal.in.h,v 1.1 2016/12/03 03:15:33 marino Exp $
>
> DragonFly support.
>
> --- lib/signal.in.h.orig  2016-06-29 09:12:27 UTC
> +++ lib/signal.in.h
> @@ -61,6 +61,7 @@
>  #if (@GNULIB_PTHREAD_SIGMASK@ || defined GNULIB_POSIXCHECK) \
>  && ((defined __APPLE__ && defined __MACH__) \
>  || defined __FreeBSD__ || defined __OpenBSD__ || defined __osf__ \
> +|| defined __DragonFly__ \
>  || defined __sun || defined __ANDROID__) \
>  && ! defined __GLIBC__
>  # include 
>

This file comes from gnulib.  Can you send this patch there?
bug-gnu...@gnu.org.  That way you will fix it once and reap the benefits
many places.

> $NetBSD: patch-libguile_threads.c,v 1.1 2016/12/03 03:15:33 marino Exp $
>
> DragonFly support.
>
> --- libguile/threads.c.orig   2016-06-20 20:35:06 UTC
> +++ libguile/threads.c
> @@ -2252,7 +2252,7 @@ scm_ia64_ar_bsp (const void *opaque)
>return (void *) ctx->uc_mcontext.sc_ar_bsp;
>  }
>  # endif /* linux */
> -# ifdef __FreeBSD__
> +# if defined __FreeBSD__ || defined __DragonFly__
>  #  include 
>  void *

This is for ia64 support which AFAIU DragonFly doesn't do; I think you
can drop this one.

Closing this one as I think there's nothing for me to do here.

Andy

bug#26058: utf16->string and utf32->string don't conform to R6RS

[Andy Wingo]

On Mon 13 Mar 2017 19:10, taylanbayi...@gmail.com (Taylan Ulrich 
"Bayırlı/Kammer") writes:

> If I do binary I/O, the following situations are possible:
>
> 1. I'm guaranteed to get any possible bytes that happen to form a valid
>BOM at the start of the stream as-is in the returned bytevector; the
>binary I/O interface doesn't see such bytes as anything special, as
>it could simply be coincidence that the stream starts with such
>bytes.
>
> 2. I'm guaranteed *not* to get bytes that form a BOM at the start of the
>stream; instead they're consumed to set the port encoding for any
>future text I/O.
>
> 3. The behavior is unspecified and either of the above may happen.

(1).  But I thought this bug was about using a bytevector as a source
and then doing textual I/O on it, no?

Andy

bug#26058: utf16->string and utf32->string don't conform to R6RS

[Andy Wingo]

On Sat 11 Mar 2017 13:19, taylanbayi...@gmail.com ("Taylan Ulrich 
"Bayırlı/Kammer"") writes:

> See the R6RS Libraries document page 10.  The differences:
>
> - R6RS supports reading a BOM.
>
> - R6RS mandates an endianness argument to specify the behavior at the
>   absence of a BOM.
>
> - R6RS allows an optional third argument 'endianness-mandatory' to
>   explicitly ignore any possible BOM.
>
> Here's a quick patch on top of master.  I didn't test it thoroughly...

Hi,

this is a tricky area that is not so amenable to quick patches :) Have
you looked into what Guile already does for byte-order marks?  Can you
explain how the R6RS specification relates to this?

  https://www.gnu.org/software/guile/manual/html_node/BOM-Handling.html

Andy

bug#26059: Sorry about the duplicate.

[Andy Wingo]

On Sat 11 Mar 2017 19:30, taylanbayi...@gmail.com (Taylan Ulrich 
"Bayırlı/Kammer") writes:

> Please ignore this, as it's a duplicate of #26058.

bug#24544: 2.1.4 tarball install fails on GuixSD

[Andy Wingo]

On Sat 11 Mar 2017 12:33, l...@gnu.org (Ludovic Courtès) writes:

> Andy Wingo  skribis:
>
>> On Sun 25 Sep 2016 21:22, Jan Nieuwenhuizen  writes:
>>
>>> ld-wrapper: error: attempt to use impure library 
>>> "/home/janneke/guile-2.1.4/lib/libguile-2.2.so"
>>> collect2: error: ld returned 1 exit status
>>> libtool:   error: error: relink 'guile-readline.la' with the above 
>>> command before installing it
>>
>> This is because Guix is silly and thinks that even when you are
>> installing to /rando/prefix/that/you/like that it's bad to link to
>> thinks outside /gnu/store.
>>
>> The workaround is to export GUIX_LD_WRAPPER_ALLOW_IMPURITIES=yesplease.
>> (Actually any value.)
>>
>> The real fix is to prevent ld-wrapper from carping for normal installs
>> to non-store prefixen!
>
> Do you mean we should change the default?  That is,
> GUIX_LD_WRAPPER_ALLOW_IMPURITIES=yes by default, and gnu-build-system
> would set it to “no”.

I think I didn't know precisely what I meant :) However!  That sounds
like a good idea -- the benefits of the check are only intended for Guix
builds, so builds outside Guix should probably not go through that
check.

Andy

bug#26040: Guile tests that cannot work on MS-Windows and should be disabled

[Andy Wingo]

Forwarded bug report from Eli on guile-devel.

On Sat 23 Jul 2016 13:49, Eli Zaretskii  writes:

> These tests are:
>
>  . ftw.test, which fails because ftw is not available:
>
>  FAIL: ftw.test: file-system-fold: test-suite
>  ERROR: ftw.test: file-system-fold: EACCES - arguments: 
> ((unbound-variable #f "Unbound variable: ~S" (getuid) #f))
>  ERROR: ftw.test: file-system-fold: dangling symlink and lstat - 
> arguments: ((system-error "mkdir" "~A" ("File exists") (17)))
>  ERROR: ftw.test: file-system-fold: dangling symlink and stat - 
> arguments: ((system-error "mkdir" "~A" ("File exists") (17)))
>  FAIL: ftw.test: file-system-tree: test-suite/*
>  FAIL: ftw.test: file-system-tree: test-suite (recursive)
>  FAIL: ftw.test: scandir: top-srcdir
>  ERROR: ftw.test: scandir: symlink to directory - arguments: 
> ((system-error "mkdir" "~A" ("File exists") (17)))
>
>  . several net_db tests:
>
>  Running net-db.test
>  ERROR: net-db.test: getaddrinfo: 127.0.0.1, any service - arguments: 
> ((unbound-variable #f "Unbound variable: ~S" (AI_NUMERICHOST) #f))
>  ERROR: net-db.test: getaddrinfo: 127.0.0.1:80 - arguments: 
> ((unbound-variable #f "Unbound variable: ~S" (AI_NUMERICHOST) #f))
>  ERROR: net-db.test: getaddrinfo: port 80 - arguments: ((unbound-variable 
> #f "Unbound variable: ~S" (AI_ADDRCONFIG) #f))
>  ERROR: net-db.test: getaddrinfo: port 80 with family and socket type - 
> arguments: ((unbound-variable #f "Unbound variable: ~S" (AI_ADDRCONFIG) #f))
>  ERROR: net-db.test: getaddrinfo: no name - arguments: ((unbound-variable 
> #f "Unbound variable: ~S" (EAI_NONAME) #f))
>  ERROR: net-db.test: getaddrinfo: wrong service name - arguments: 
> ((unbound-variable #f "Unbound variable: ~S" (AI_NUMERICHOST) #f))
>
>  . two "no duplicates" tests in popen.test: these require a Posix
>shell, and simply hang on MS-Windows.
>
>  . ports.test, because it needs 'fcntl', which is not available:
>
>  Running ports.test
>  FAIL: ports.test: file: binary mode ignores port encoding
>  FAIL: ports.test: file: binary mode ignores file coding declaration
>  Backtrace:
>  In unknown file:
>   ?:  0 [memoize-variable-access! # # 2f5fca8>]
>  In ice-9/eval.scm:
>   393:  1 [eval # (# # . #)]
>   386:  2 [eval # #]
>   432:  3 [eval # #]
>  In unknown file:
>   ?:  4 [primitive-load "d:/gnu/guile-2.0.12/test-suite/tests/ports.test"]
>  In ice-9/boot-9.scm:
>  1732:  5 [#]
>  1727:  6 [%start-stack load-stack ...]
>  4056:  7 [#]
>  2404:  8 [save-module-excursion # ice-9/boot-9.scm:4051:3 (
>  )>]
>  In ice-9/eval.scm:
>   481:  9 [lp (#) (("ports.test"))]
>  In ice-9/boot-9.scm:
>   778: 10 [for-each # #]
>  In ice-9/eval.scm:
>   432: 11 [eval # #]
>   432: 12 [eval # #]
>  In ice-9/boot-9.scm:
>66: 13 [call-with-prompt prompt0 ...]
>  In unknown file:
>   ?: 14 [apply-smob/1 #]
>  In ice-9/boot-9.scm:
>   160: 15 [catch #t # ...]
>
>  ERROR: In procedure memoize-variable-access!:
>  ERROR: Unbound variable: fcntl
>
>  . ttyname posix.test ('ttyname' is not available):
>
>  Running posix.test
>  ERROR: posix.test: ttyname: non-tty argument - arguments: 
> ((unbound-variable #f "Unbound variable: ~S" (ttyname) #f))
>
>  . statprof.test, because SIGPROF is not available:
>
>  Running statprof.test
>  ERROR: statprof.test: return values - arguments: ((unbound-variable 
> "module-lookup" "Unbound variable: ~S" (SIGPROF) #f))
>  ERROR: statprof.test: statistical sample counts within expected range - 
> arguments: ((unbound-variable "module-lookup" "Unbound variable: ~S" 
> (SIGPROF) #f))
>  ERROR: statprof.test: accurate call counting - arguments: 
> ((unbound-variable "module-lookup" "Unbound variable: ~S" (SIGPROF) #f))
>
> For the record, here's the statistics of the test suite:
>
>   Totals for this test run:
>   passes: 39066
>   failures:   12
>   unexpected passes:  0
>   expected failures:  9
>   unresolved test cases:  571
>   untested test cases:1
>   unsupported test cases: 18
>   errors: 14

bug#20938: make-dynamic-state, with-dynamic-state & exceptions

[Andy Wingo]

On Fri 03 Mar 2017 23:15, Josep Portella Florit  writes:

> On 03/01/2017 06:30 PM, Andy Wingo wrote:
>> On Wed 01 Mar 2017 16:11, Josep Portella Florit  writes:
>>> (Today I've tested it with 2.1.7.22-fcebf and it still crashed.)
>> 
>> Ack, I didn't actually test it!  I thought a related fix in 2.1.7 would
>> have caught it.  I will have a look.
>
> OK, can you reopen the bug?

Fixed in master now.  Thanks again for the report :)

Andy

bug#20272: Support reproducible builds

[Andy Wingo]

Hi,

On Sun 05 Mar 2017 21:49, l...@gnu.org (Ludovic Courtès) writes:

> Andy Wingo  skribis:
>
>> On Thu 22 Dec 2016 00:53, l...@gnu.org (Ludovic Courtès) writes:
>>
>>> +(define (module-generate-unique-id! m)
>>> +  (let ((i (module-next-unique-id m)))
>>> +(set-module-next-unique-id! m (+ i 1))
>>> +i))
>>
>> This introduces a race condition when expanding from multiple threads at
>> once.  Any plan here?
>
> Good point!  We could grab a per-module mutex for that, though that’s
> again a fat mutex.
>
> Thoughts?

I would use atomic boxes if possible, but they are in another module :/
Even mutexes aren't directly available in boot-9 any more... Alternately
we can make a new primitive for module-generate-unique-id! which can
obviously use C.  That's probably the easiest option, sadly!

Andy

bug#20938: make-dynamic-state, with-dynamic-state & exceptions

[Andy Wingo]

reopen
thanks

(Hopefully the above commands will reopen the bug, if not I will do it
via the other address; I am not very good with debbugs :)

On Fri 03 Mar 2017 23:15, Josep Portella Florit  writes:

> On 03/01/2017 06:30 PM, Andy Wingo wrote:
>> On Wed 01 Mar 2017 16:11, Josep Portella Florit  writes:
>>> (Today I've tested it with 2.1.7.22-fcebf and it still crashed.)
>> 
>> Ack, I didn't actually test it!  I thought a related fix in 2.1.7 would
>> have caught it.  I will have a look.
>
> OK, can you reopen the bug?