bug#20907: [PATCH] Manual bug for scm_gc_protect_object

[Andy Wingo]

On Wed 02 Sep 2015 20:34, Mike Gran  writes:

> On Wednesday, September 2, 2015 11:06 AM, Mark H Weaver  
> wrote:
>  
>>Would it help to replace all uses of the term "scan" with "mark", in
>>connection with garbage collection?  In the papers I've read on GC,
>>"mark" is the word I usually see, and it seems much clearer to me,
>>because anyone who knows the basics of GC knows that "marking" is needed
>>to prevent an object from being freed, whereas "scanning" could mean
>>anything.
>
> That would help, I think.  I guess I was associating "scan" with
> the "sweep" part of mark and sweep.
>  
> Thanks very much for the clarification.

I think "scanning" is a term that is used sometimes, like tracing or
visiting.  But it's true that in the case of the manual it was used
without much context.  I made some tweaks that hopefully clarify things,
enough to close this bug anyway :)

Andy

>From f84006c5644997ce9854df9070ec2f1fb8acd420 Mon Sep 17 00:00:00 2001
From: Andy Wingo 
Date: Fri, 24 Jun 2016 08:56:21 +0200
Subject: [PATCH] Clarify use of the term "scanning" in the manual

* doc/ref/api-memory.texi (Garbage Collection Functions):
* doc/ref/libguile-concepts.texi (Garbage Collection): Attempt to be
  clear that scanning is a thing that happens in the mark phase.  Fixes
  #20907 I think.
---
 doc/ref/api-memory.texi| 42 
 doc/ref/libguile-concepts.texi | 48 --
 2 files changed, 56 insertions(+), 34 deletions(-)

diff --git a/doc/ref/api-memory.texi b/doc/ref/api-memory.texi
index 142eb01..ce0187b 100644
--- a/doc/ref/api-memory.texi
+++ b/doc/ref/api-memory.texi
@@ -27,9 +27,10 @@ collection relates to using Guile from C.
 
 @deffn {Scheme Procedure} gc
 @deffnx {C Function} scm_gc ()
-Scans all of SCM objects and reclaims for further use those that are
-no longer accessible.  You normally don't need to call this function
-explicitly.  It is called automatically when appropriate.
+Finds all of the ``live'' @code{SCM} objects and reclaims for further
+use those that are no longer accessible.  You normally don't need to
+call this function explicitly.  Its functionality is invoked
+automatically as needed.
 @end deffn
 
 @deftypefn {C Function} SCM scm_gc_protect_object (SCM @var{obj})
@@ -43,8 +44,9 @@ than it has been protected. Returns the SCM object it was 
passed.
 
 Note that storing @var{obj} in a C global variable has the same
 effect@footnote{In Guile up to version 1.8, C global variables were not
-scanned by the garbage collector; hence, @code{scm_gc_protect_object}
-was the only way in C to prevent a Scheme object from being freed.}.
+visited by the garbage collector in the mark phase; hence,
+@code{scm_gc_protect_object} was the only way in C to prevent a Scheme
+object from being freed.}.
 @end deftypefn
 
 @deftypefn {C Function} SCM scm_gc_unprotect_object (SCM @var{obj})
@@ -123,16 +125,18 @@ live reference to it@footnote{In Guile up to version 1.8, 
memory
 allocated with @code{scm_gc_malloc} @emph{had} to be freed with
 @code{scm_gc_free}.}.
 
-Memory allocated with @code{scm_gc_malloc} is scanned for live pointers.
-This means that if @code{scm_gc_malloc}-allocated memory contains a
-pointer to some other part of the memory, the garbage collector notices
-it and prevents it from being reclaimed@footnote{In Guile up to 1.8,
-memory allocated with @code{scm_gc_malloc} was @emph{not} scanned.
-Consequently, the GC had to be told explicitly about pointers to live
-objects contained in the memory block, e.g., @i{via} SMOB mark functions
-(@pxref{Smobs, @code{scm_set_smob_mark}})}.  Conversely, memory
-allocated with @code{scm_gc_malloc_pointerless} is assumed to be
-``pointer-less'' and is not scanned.
+When garbage collection occurs, Guile will visit the words in memory
+allocated with @code{scm_gc_malloc}, looking for live pointers.  This
+means that if @code{scm_gc_malloc}-allocated memory contains a pointer
+to some other part of the memory, the garbage collector notices it and
+prevents it from being reclaimed@footnote{In Guile up to 1.8, memory
+allocated with @code{scm_gc_malloc} was @emph{not} visited by the
+collector in the mark phase.  Consequently, the GC had to be told
+explicitly about pointers to live objects contained in the memory block,
+e.g., @i{via} SMOB mark functions (@pxref{Smobs,
+@code{scm_set_smob_mark}})}.  Conversely, memory allocated with
+@code{scm_gc_malloc_pointerless} is assumed to be ``pointer-less'' and
+is not scanned for pointers.
 
 For memory that is not associated with a Scheme object, you can use
 @code{scm_malloc} instead of @code{malloc}.  Like
@@ -193,9 +197,11 @@ Allocate @var{size} bytes of automatically-managed memory. 
 The memory
 is automatically freed when no longer referenced from any live memory
 block.
 
-Memory allocated with @code{scm_gc_malloc} or @code{scm_gc_calloc} is
-scanned for pointers.  Memory allocated by
-@code{scm_gc_malloc_pointerless} is not scann

bug#20919: missing from manual: with-input-from-port

[Andy Wingo]

On Sun 28 Jun 2015 15:59, "Wette, Matthew R (3441)" 
 writes:

> In the guile reference manual, 
> in API Reference, 
> in Input and Output, 
> in Ports?, 
> might be a nice place to provide documentation for 
> the procedure with-input-from-port.

Done in master, thanks for the note.

Andy

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

[Andy Wingo]

On Tue 30 Jun 2015 15:50, Josep Portella Florit  writes:

> This code crashes Guile 2.0.11:
>
> (define x (make-dynamic-state))
> (with-dynamic-state x (lambda () (/ 1 0)))

Related: http://thread.gmane.org/gmane.lisp.guile.devel/16953

How are you using dynamic states?

Andy

bug#20945: One guile test failed

[Andy Wingo]

Thanks for the report.

On Tue 30 Jun 2015 21:43, Christopher White  writes:

> For your information, make check produced one error, on OS X Yosemite.
>
> FAIL: numbers.test: string->number: valid complex number strings

Does this still happen for you?

If so, can you paste this at a REPL or in a file and see what it prints
out?

(for-each (lambda (triple)
(apply
 (lambda (str re im)
   (let ((z (string->number str)))
 (if (or (eq? z #f)
 (not (and (eqv? (real-part z) re)
   (eqv? (imag-part z) im
 (begin 
   (pk str re im)
   (throw 'fail)
 triple))
  `(("1@0" 1 0) ("1@+0" 1 0) ("1@-0" 1 0) ("1/2@0" 1/2 0)
("1.0@0" 1.0 0) ("1.0@-0" 1.0 0)
("#e1@0" 1 0) ("#e1@+0" 1 0) ("#e1@-0" 1 0) ("#e0.5@0.0" 1/2 0)
("#e1.0@0" 1 0) ("#e1.0@-0" 1 0)
("#i1@0" 1.0 0.0) ("#i1@+0" 1.0 0.0) ("#i1@-0" 1.0 -0.0) 
("#i1/2@0" 0.5 0.0)
("#i1.0@0" 1.0 0.0) ("#i1.0@-0" 1.0 -0.0)
("1@+0.0" 1.0 0.0) ("1.0@-0.0" 1.0 -0.0)
("2+3i" 2.0 3.0) ("4-5i" 4.0 -5.0)
("1+i" 1.0 1.0) ("1-i" 1.0 -1.0) ("+1i" 0.0 1.0) ("-1i" 0.0 
-1.0)
("+i" 0.0 1.0) ("-i" 0.0 -1.0)
("1.0+.1i" 1.0 0.1) ("1.0-.1i" 1.0 -0.1)
(".1+.0i" 0.1 0.0) ("1.+.0i" 1.0 0.0) (".1+.1i" 0.1 0.1)
("1e1+.1i" 10.0 0.1)
("0@+nan.0" 0 0) ("0@+inf.0" 0 0) ("0@-inf.0" 0 0)
("0.0@+nan.0" 0.0 0.0) ("0.0@+inf.0" 0.0 0.0) ("0.0@-inf.0" 0.0 
0.0)
("#i0@+nan.0" 0.0 0.0) ("#i0@+inf.0" 0.0 0.0) ("#i0@-inf.0" 0.0 
0.0)
("0.0@1" 0.0 0.0) ("0.0@2" -0.0 0.0) ("0.0@4" -0.0 -0.0) 
("0.0@5" 0.0 -0.0)
))

Cheers,

Andy

bug#21013: Evaluation expression from C assumes that lambda is present

[Andy Wingo]

On Wed 08 Jul 2015 20:48, Stefan Israelsson Tampe  
writes:

> When using the profiler in a pure module ,profile does not work
>
> The reason is that in 
> scmsigs.c, 
>
> At an evaluation occurs from C e.g.
>
> static SCM
> close_1 (SCM proc, SCM arg)
> {
> return scm_primitive_eval_x (scm_list_3 (scm_sym_lambda, SCM_EOL,
> scm_list_2 (proc, arg)));
> }

Amusing!  I tried to work around this use of `eval' but I can't because
there's too much C sclerosis.  Instead I switched to use scm_eval and
specified a module; should fix the issue.

Andy

bug#21064: Typo in (guile.info.gz)Keyword Read Syntax: `keyword' read option

[Andy Wingo]

Fixed in git.  Thanks!

Andy

On Wed 15 Jul 2015 13:27, "Glenn Michaels"  writes:

> The following patch fixes a typo in the guile texinfo docs,
> see https://bugs.debian.org/765286 for more info.
>
> --- a/doc/ref/api-data.texi
> +++ b/doc/ref/api-data.texi
> @@ -5849,7 +5849,7 @@ of the form @code{:NAME} are read as symbols, as 
> required by R5RS.
>  
>  @cindex SRFI-88 keyword syntax
>  
> -If the @code{keyword} read option is set to @code{'postfix}, Guile
> +If the @code{keywords} read option is set to @code{'postfix}, Guile
>  recognizes the SRFI-88 read syntax @code{NAME:} (@pxref{SRFI-88}).
>  Otherwise, tokens of this form are read as symbols.

bug#19235: make-fresh-user-module procedure leaks memory

[Ludovic Courtès]

Mark H Weaver  skribis:

> Andy Wingo  writes:
>
>> In many ways I think Ludovic was right in #15602 -- we should allow
>> excursions to isolate changes to the module tree.  Sometimes you want an
>> excursion to never add a module to the tree.  Sometimes you do, but
>> maybe all in one go and with a mutex, to avoid races -- like, you could
>> load a file or evaluate some code in a private fork of the module tree,
>> but then commit it to the main tree afterwards.  Is that a sensible
>> thing?
>
> Yes, I agree.  In fact, I'd been thinking of something along those lines
> to enable thread-safe module loading.  More specifically, I was thinking
> that there should be a fluid variable that contains some additional
> modules that are not yet committed to the global module tree.
>
> Briefly, when a module is auto-loaded by a thread, the new module would
> initially be visible only to that thread, and also to any threads
> spawned by that thread during the auto-load.  Any attempts to access the
> module from other threads would block until the module is either fully
> loaded.

That sounds like a nice idea.

In the current state of things, perhaps this behavior could be emulated
by running ‘compile-file’ in a module excursion, and passing it a root
module that’s a copy of ‘the-root-module’, something like that (though
that would probably perform badly.)

> One potential issue that has been troubling me is that in Guile's model,
> there's no guarantee that a module will _ever_ finish loading.

I think the fact that we evaluate all the top-level forms is
problematic.  The R6RS phases were a great idea.  :-)

> The main program itself could simply run from the auto-load.  That's
> why I think it's important to propagate permission to threads created
> during the auto-load, but maybe there will still be problems.

I’m not sure what you mean by “propagate permission”?

Ludo’.

bug#21076: dynamic-link often fails to load libraries

[Andy Wingo]

On Fri 17 Jul 2015 01:00, Andreas Rottmann  writes:

>> Alternatively, the (system foreign) module in guile could provide a
>> simple low-level wrapper around lt_dlopen, and possibly implement
>> the higher level functionality of `dynamic-link' (additional search
>> paths, guessing extensions etc.) in scheme.
>>
> +1

Either one of yall want to give a shot at this or something like it?  I
think in an ideal world we could lose the ltdl dependency.  I gave a
first crack at it but got mired in C; I never considered implementing it
in Scheme, which seems like a nice idea.

Andy

bug#21093: Web server: response bodies systematically loaded in memory

[Andy Wingo]

On Mon 20 Jul 2015 00:10, l...@gnu.org (Ludovic Courtès) writes:

> The ‘sanitize-response’ procedure systematically loads the whole
> response body in memory, which causes obvious scalability issues (this
> is in 2.0.11.)
>
> In particular, when a request handler returns a port-taking procedure as
> its second return value, ‘sanitize-request’ will just call that
> procedure passing it a string output port.
>
> This procedure should instead be called from the server implementation’s
> ‘write’ hook, but that would necessitate an API change.
>
> Thoughts?

How would you set the Content-Length?  Just leave it off and set
Connection: close ?  Set it in the headers perhaps?  Then you have to
verify later, which I dunno how nice that is.  Maybe it is OK.

I would be happy to review patches :)  Cc guile-devel.

Andy

bug#21147: readline history is stifled early so (readline-set! history-length nn) has no effect

[Andy Wingo]

thanks

bug#19540: repeated ./././ in compiled modules

[Ludovic Courtès]

Hello!

Andy Wingo  skribis:

> On Thu 23 Jun 2016 15:06, l...@gnu.org (Ludovic Courtès) writes:
>
>> Andy Wingo  skribis:
>>
>>> commit 9a951678713557b548415d32eae6d63d039bf652
>>> Author: Andy Wingo 
>>> Date:   Thu Jun 23 10:03:10 2016 +0200
>>>
>>> Fix relative file name canonicalization on paths with "."
>>> 
>>> * libguile/filesys.c (scm_i_relativize_path): Canonicalize the file
>>>   names elements that we will be using as prefixes.  Fixes the case
>>>   where a load path contains a relative file name: #19540.
>>> * test-suite/tests/ports.test ("%file-port-name-canonicalization"): Add
>>>   tests that elements of the load path are canonicalized.
>>>
>> ‘canonicalize_file_name’ is costly: roughly one syscall per file name
>> component.
>>
>> IIUC, ‘canonicalize_file_name’ is now called once for each ‘%load-path’
>> entry and file name that we canonicalize.  Is this correct?
>
> That's correct, but only for relative canonicalization, which is in
> practive only when loading Scheme files from source.  Seems out of the
> hot path; what do you think?

I think it’s likely to have a noticeable impact on startup time for
projects with a large number of modules like Guix.

For instance, commands like ‘guix package -A’ or ‘guix build foo’ load
all the modules.  The impact will be smaller on a laptop with an SSD
than on an NFS mount, where it’s likely going to be terrrible (this
could be tested using the ‘delay’ device mapper.)

WDYT?

Ludo’.

bug#21181: Possible bug in test-group

[Andy Wingo]

Mark, do you have any thoughts on this one?

A

On Mon 03 Aug 2015 06:29, Rob Browning  writes:

> Rob Browning  writes:
>
>> To follow up, it does look like it might be broken, but you can ignore
>> my suggested fix.
>
> I'm not that familiar with srfi-64, but it looks like the problem (if
> it's not expected) is that test-group doesn't handle the case where it's
> creating the first group, i.e. no prior test-begin.
>
> In that situation it appears that test-runner-current returns #f,
> causing test-result-alist! to fail.
>
> Hope this helps

bug#21147: readline history is stifled early so (readline-set! history-length nn) has no effect

[Andy Wingo]

On Tue 28 Jul 2015 10:06, Daniel Llorens  writes:

> The default history-length is 200. When one imports (ice-9 readline),
> history is stifled to this value, so it doesn't matter if you set
> history-length to a larger value later on. I'm surprised that this has
> gone unnoticed up to now, since 200 is really small. I may be missing
> something...
>
> The patch changes scm_readline_options() so that history is only
> stiffled when the options are actually set. This is rather clumsy
> since it means that if one doesn't set the options, history will never
> be stifled.
>
> An alternative would be to add an optional readline-options argument
> to activate-readline. That way one would be able to increase
> history-length before the first time history is stifled, and otherwise
> things would work as they do now.

Thanks for the patch!  Well why not.  It's not perfect but it's an
improvement.  Thanks for giving this a poke; applied to master.

Andy

bug#20823: argv mangled by locale

[Zefram]

Andy Wingo wrote:
>I also don't
>know whether to supply an optional "encoding" argument, and use that
>encoding to decode the command line arguments.

That, or something that just retrieves octets, is necessary.  Decoding via
the selected locale does not suffice, because there's no guarantee that
there'll be a locale with a cooperative encoding.

-zefram

bug#21347: include-from-path and relative paths in load-path

[Andy Wingo]

On Tue 25 Aug 2015 21:42, taylanbayi...@gmail.com (Taylan Ulrich 
"Bayırlı/Kammer") writes:

> When there are relative paths in the load-path, `include-from-path'
> seems to always interpret them relative to the directory of the file in
> which the `include-from-path' is called, instead of relative to the
> current working directory in effect when Guile is started.

Indeed, good catch.  Fixed in master.  I don't know if we can fix in
2.0.

Andy

bug#19540: repeated ./././ in compiled modules

[Andy Wingo]

Hi :)

On Fri 24 Jun 2016 10:28, l...@gnu.org (Ludovic Courtès) writes:

> Hello!
>
> Andy Wingo  skribis:
>
>> On Thu 23 Jun 2016 15:06, l...@gnu.org (Ludovic Courtès) writes:
>>
>>> ‘canonicalize_file_name’ is costly: roughly one syscall per file name
>>> component.
>>>
>>> IIUC, ‘canonicalize_file_name’ is now called once for each ‘%load-path’
>>> entry and file name that we canonicalize.  Is this correct?
>>
>> That's correct, but only for relative canonicalization, which is in
>> practive only when loading Scheme files from source.  Seems out of the
>> hot path; what do you think?
>
> I think it’s likely to have a noticeable impact on startup time for
> projects with a large number of modules like Guix.

Aren't they usually compiled?  Loading compiled files will not
go through this path AFAIU.

> For instance, commands like ‘guix package -A’ or ‘guix build foo’ load
> all the modules.  The impact will be smaller on a laptop with an SSD
> than on an NFS mount, where it’s likely going to be terrrible (this
> could be tested using the ‘delay’ device mapper.)

Oh I'm with you that we need to be careful here.  I am under the
impression though that there's no additional impact here because this is
just something that happens at compile-time.  Or if you load a source
file, but in that case you're evaluating and expecting a perf loss is
not the end of the world.

Andy

bug#21093: Web server: response bodies systematically loaded in memory

[Ludovic Courtès]

Andy Wingo  skribis:

> On Mon 20 Jul 2015 00:10, l...@gnu.org (Ludovic Courtès) writes:
>
>> The ‘sanitize-response’ procedure systematically loads the whole
>> response body in memory, which causes obvious scalability issues (this
>> is in 2.0.11.)
>>
>> In particular, when a request handler returns a port-taking procedure as
>> its second return value, ‘sanitize-request’ will just call that
>> procedure passing it a string output port.
>>
>> This procedure should instead be called from the server implementation’s
>> ‘write’ hook, but that would necessitate an API change.
>>
>> Thoughts?
>
> How would you set the Content-Length?  Just leave it off and set
> Connection: close ?  Set it in the headers perhaps?  Then you have to
> verify later, which I dunno how nice that is.  Maybe it is OK.

I think it could work this way:

  1. By default, provide no ‘Content-Length’ and force chunked encoding
 (so that the recipient can make sure it received everything.)

 This is useful for data generated on the fly.

  2. Provide an optional mechanism allowing the user to specify the
 content length upfront.

 Useful for statically-generated data that cannot fit in memory.

I haven’t thought yet about the actual API (I’ll be happy to do so as
time permits; to be clear, I don’t consider it a 2.0.12 blocker.)

Ludo’.

bug#21424: Bug#685919: guile-1.6: SIGALRM signal handler does not get called when guile blocks on I/O

[Andy Wingo]

It does seem clear that we have a bug here; evidently signals do not
wake up the reader, neither with readline nor without.

Andy

On Sun 06 Sep 2015 19:18, Rob Browning  writes:

> [If possible, please preserve the -forwarded address in any replies.]
>
> Reference: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765497
>
> Panu Kalliokoski  writes:
>
>> While playing with guile on my system, I discovered a weird anomaly
>> which I could not reproduce on other systems running guile.  If I
>> install a signal handler for SIGALRM, it won't get called while guile is
>> making an I/O system call.  To demonstrate:
>>
>> [atehwa@karaihin ~/proj/psyk]$ guile
>> guile> (alarm 2)
>> 0
>> guile> Herätyskello
>> [atehwa@karaihin ~/proj/psyk]$ guile
>> guile> (sigaction SIGALRM (lambda (x) (display "now!") (newline)))
>> (0 . 335544320)
>> guile> (alarm 2)
>> 0
>> guile> now a lot more than two seconds has passed, while I wrote this
>> now!
>> : In expression now:
>> : Unbound variable: now
>> ABORT: (unbound-variable)
>> [...]
>>
>> As you can see, the signal handler gets called as soon as guile returns
>> from read(2), already before calling (eval).
>>
>> I can't get to understand what causes this on my system, because another
>> Debian system with exact same versions of guile-1.6, libc6 and
>> libguile-ltdl-1 seems to work fine, and interrupts the read(2) call with
>> the signal handler.
>
> This appears to still be the case with at least Debian's 2.0.11+1-10
> package, and setting the handler to something that doesn't perform IO
> has the same effect (i.e. no alarm until you hit return):
>
>   (sigaction SIGALRM (lambda (x) (exit 1)))
>
> Thanks

bug#19540: repeated ./././ in compiled modules

[Ludovic Courtès]

Andy Wingo  skribis:

> On Fri 24 Jun 2016 10:28, l...@gnu.org (Ludovic Courtès) writes:
>
>> Hello!
>>
>> Andy Wingo  skribis:
>>
>>> On Thu 23 Jun 2016 15:06, l...@gnu.org (Ludovic Courtès) writes:
>>>
 ‘canonicalize_file_name’ is costly: roughly one syscall per file name
 component.

 IIUC, ‘canonicalize_file_name’ is now called once for each ‘%load-path’
 entry and file name that we canonicalize.  Is this correct?
>>>
>>> That's correct, but only for relative canonicalization, which is in
>>> practive only when loading Scheme files from source.  Seems out of the
>>> hot path; what do you think?
>>
>> I think it’s likely to have a noticeable impact on startup time for
>> projects with a large number of modules like Guix.
>
> Aren't they usually compiled?  Loading compiled files will not
> go through this path AFAIU.

Good point, I had overlooked that.

>> For instance, commands like ‘guix package -A’ or ‘guix build foo’ load
>> all the modules.  The impact will be smaller on a laptop with an SSD
>> than on an NFS mount, where it’s likely going to be terrrible (this
>> could be tested using the ‘delay’ device mapper.)
>
> Oh I'm with you that we need to be careful here.  I am under the
> impression though that there's no additional impact here because this is
> just something that happens at compile-time.  Or if you load a source
> file, but in that case you're evaluating and expecting a perf loss is
> not the end of the world.

Indeed, this makes sense to me now; sorry for the confusion!

Ludo’.

bug#14361: Building guile 2.0.9 under mingw + msys

[Eli Zaretskii]

> From: Andy Wingo 
> Cc: 14...@debbugs.gnu.org,  l...@gnu.org
> Date: Tue, 21 Jun 2016 22:52:37 +0200
> 
> On Tue 21 Jun 2016 17:42, Eli Zaretskii  writes:
> 
> >> From: Andy Wingo 
> >> Cc: 14...@debbugs.gnu.org,  l...@gnu.org
> >> Date: Tue, 21 Jun 2016 17:06:05 +0200
> >> 
> >> Let's give it a go!  I understand that you do not want to work with
> >> gnulib.  That's a negative from a Guile POV -- but it's not a
> >> deal-breaker.
> >
> > I have nothing against Gnulib, but in this case their solution is
> > simply not up to speed.
> >
> >> To that end I hesitate about including a bunch more stuff in
> >> posix.c.  Must it all be there, or would it be possible to move some
> >> of it out to our own gnulib-like mingw-w32.[ch] or something?
> >
> > Most of it is already on a separate file, w32-proc.c (see the diffs).
> > I could take the macros at the beginning of posix.c and put them on a
> > separate .h file, if that would be better.
> 
> That would be great, if you'd be amenable.  Thanks!

Done and posted on guile-devel.

Thanks.

bug#21514: Guile 2.2: Sluggish elf calls, esp around arity / promises / statprof

[Andy Wingo]

I'm happy with this fix!  However I think I would like to see if I can
just speed up thunk? and other arity accessors.  Do you have a test
case that you can use to show the speed problem?

Andy

On Sat 14 Nov 2015 03:54, Christopher Allan Webber  
writes:

> Here's a fix to this bug.  Tests pass, and performance appears to be
> back here.
>
> I've assigned copyright to the FSF for Guile so it should be fine to
> commit!
>
>
>>From 79e3b5286a2699f9b302bd3abf8a6b884b13a4f4 Mon Sep 17 00:00:00 2001
> From: Christopher Allan Webber 
> Date: Fri, 13 Nov 2015 20:42:31 -0600
> Subject: [PATCH] Remove thunk / arity check in make-promise
>
> * libguile/promises.c (s_scm_make_promise): Remove arity check in
>   make-promise.  This was causing considerably slowdown with the new elf
>   code, causing considerable number of bytevector reading calls on
>   every call to (make-promise).  Removing this check fixes a performance
>   regression in the new compiler.
> ---
>  libguile/promises.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/libguile/promises.c b/libguile/promises.c
> index dcd0ac3..858b6f3 100644
> --- a/libguile/promises.c
> +++ b/libguile/promises.c
> @@ -1,4 +1,4 @@
> -/* Copyright (C) 
> 1995,1996,1997,1998,1999,2000,2001,2002,2003,2004,2005,2006,2007,2008,2009,2010,2011
> +/* Copyright (C) 
> 1995,1996,1997,1998,1999,2000,2001,2002,2003,2004,2005,2006,2007,2008,2009,2010,2011,2015
>   * Free Software Foundation, Inc.
>   * 
>   * This library is free software; you can redistribute it and/or
> @@ -77,7 +77,6 @@ SCM_DEFINE (scm_make_promise, "make-promise", 1, 0, 0,
>  "@end lisp\n")
>  #define FUNC_NAME s_scm_make_promise
>  {
> -  SCM_VALIDATE_THUNK (1, thunk);
>SCM_RETURN_NEWSMOB2 (scm_tc16_promise,
>  SCM_UNPACK (thunk),
>  SCM_UNPACK (scm_make_recursive_mutex ()));

bug#21514: Guile 2.2: Sluggish elf calls, esp around arity / promises / statprof

[Andy Wingo]

On Fri 18 Sep 2015 17:19, Christopher Allan Webber  
writes:

> I was testing a program of mine under Guile 2.2, and was surprised to
> find things slower than in Guile 2.0, surprising given all the various
> optimizations I've heard about!  However, I think I've found good clues
> as to what's going on.

(Summary: procedure-minimum-arity, called via `thunk?' when making
promises, was doing a lot of work, grovelling debuginfo to answer simple
questions.)

I fixed procedure-minimum-arity to be quicker, which should fix this
bug.  Please let me know if you see thunk? as a perf problem in your use
case.

In the meantime I seem to have broken ,trace :/  I'll see what the deal
is there.

Andy

bug#21587: Mac: Segfault when unloading shared object linked to libguile

[Andy Wingo]

On Tue 29 Sep 2015 20:21, Wilhelm Schuster  writes:

> The basic run down: When I try to unload (using dlclose() ) a shared
> object that is linked to libguile after calling scm_init_guile() OR
> scm_with_guile(), a Segfault is triggered.

Hu!  Well, so this is quite tricky.  Loading Guile loads
Guile which might start threads (some helper threads behind the scenes
for finalization (see section on scm_set_automatic_finalization_enabled
in tha manual), perhaps a thread to listen for signals, and then the
garbage collector that we use (libgc) might start parallel marking
threads (though you can control that parameter too).

Guile doesn't really provide an interface to allow it to shut down
cleanly and I don't know if it can.  (I guess it could.)  However it
would take quite some amount of work and I don't see us doing it any
time soon.  In any case simply trying to dlclose() is never likely to
work, as you aren't synchronizing with Guile itself.

Sorry for the bad news!

Andy

bug#21613: Include messes up when compiling file in load path

[Andy Wingo]

On Sun 04 Oct 2015 16:36, taylanbayi...@gmail.com (Taylan Ulrich 
"Bayırlı/Kammer") writes:

> $ mkdir test
> $ echo '(include "test2.scm")' > test/test1.scm
> $ echo '(display "foo\n")' > test/test2.scm
> $ pwd
> /home/taylan
> $ export GUILE_LOAD_PATH=/home/taylan/test
> $ unset GUILE_LOAD_COMPILED_PATH
> $ guile -L test test/test1.scm
...
> ERROR: In procedure open-file:
> ERROR: In procedure open-file: No such file or directory: "./test2.scm"

The way this works is that test/test1.scm is opened.  To set the
port-filename of the port, Guile uses "relative" canonicalization of the
path, which will result in "test1.scm" being the port-filename, as we
found test1.scm in test/.  After that it all breaks down -- the
intention is for `include' of a relative path to look for it relative to
the dirname of the file doing the including, but (dirname "test1.scm")
is ".", so it looks for "./test2.scm"... bogus.

The intention of relative canonicalization is to allow for errors to be
signalled relative to a path-relative file name.  For example in a
recent backtrace:

In ice-9/psyntax.scm:
  1200:36  5 (expand-top-sequence ((include "test2.scm")) _ _ #f e # #)

The fact that it's ice-9/psyntax.scm comes from there.  You can build
the file locally and install it and it the debugging information doesn't
embed the full dirname of the build tree.

But, for that to work well, you really need `include-from-path' and not
`include'.  All of the uses of `include' in Guile itself are really
`include-from-path'.  And if you use `include' in a file which is in a
path... well I guess that's not working.

Clearly going backwards from a relative path to an absolute path is not
going to work.  I guess my only proposal would be to include the
absolute path of a file port, in addition to the relative path.  I guess
that would be somewhere around the call to fport_canonicalize_filename
in fports.c.

Thoughts?

Andy

bug#21698: accessing multiple flagged values with (ice-9 getopt-long)

[Andy Wingo]

Hi Matt,

Thanks for the patch.  My instinct however is to point you towards
SRFI-37, which in addition to supporting multiple argument values can
also be used to fold over the precise argument order.  I just don't know
that we should be expanding (ice-9 getopt-long); it has its use case and
if your needs go beyond it, then probably your needs go way beyond it.

  https://www.gnu.org/software/guile/manual/html_node/SRFI_002d37.html

Ludovic, second opinions?

Andy

On Sat 17 Oct 2015 19:05, Matt Wette  writes:

> This is in reference to guile-2.0.11.
>
> The (ice-9 getopt-long) module does not provide a process for
> accessing multiple command line arguments.
>
> A patch for ice-9/getopt-long.scm is attached which adds the procedure
> getopt-ref/many to access multiple argument values.
>
> The following program and results illustrate the use of the current
> getopt-ref and the proposed getopt-ref/many:
>
> mwette$ ./gotest.scm -f foo1 -b bar1 -f foo2 baz1 baz2
>
> program arguments:
>
> ("./gotest.scm" "-f" "foo1" "-b" "bar1" "-f" "foo2" "baz1" "baz2")
>
> getopt using option-ref:
>
> foo: "foo2"
>
> bar: "bar1"
>
> getopt using option-ref/many:
>
> foo: ("foo1" "foo2")
>
> bar: "bar1"
>
> where
>
> mwette$ cat gotest.scm 
>
> #!/opt/local/bin/guile
>
> !#
>
> (use-modules (ice-9 getopt-long))
>
> (define spec
>
> '((foo (single-char #\f) (value #t))
>
> (bar (single-char #\b) (value #t
>
> (let* ((args (program-arguments))
>
> (opts (getopt-long args spec)))
>
> (simple-format #t "program arguments:\n")
>
> (simple-format #t "~S\n" args)
>
> (simple-format #t "\ngetopt using option-ref:\n")
>
> (simple-format #t "foo: ~S\n" (option-ref opts 'foo #f))
>
> (simple-format #t "bar: ~S\n" (option-ref opts 'bar #f))
>
> (simple-format #t "\ngetopt using option-ref/many:\n")
>
> (simple-format #t "foo: ~S\n" (option-ref/many opts 'foo #f))
>
> (simple-format #t "bar: ~S\n" (option-ref/many opts 'bar #f))
>
> )
>
>
>
> *** getopt-long.scm-orig  2015-10-15 06:40:29.0 -0700
> --- getopt-long.scm   2015-10-17 09:42:41.0 -0700
> ***
> *** 154,159 
> --- 154,173 
>   ;;; (option-ref (getopt-long ...) 'x-includes 42) => "/usr/include"
>   ;;; (option-ref (getopt-long ...) 'not-a-key! 31) => 31
>   
> + ;;; (option-ref/many OPTIONS KEY DEFAULT)
> + ;;; Return value in alist OPTIONS using KEY, a symbol; or DEFAULT if not
> + ;;; found.  If multiple arg-options provided a list is returned.  The value
> + ;;; is either a string, a list or `#t'.
> + ;;;
> + ;;; For example, if the above was executed with multiple x-includes flags,
> + ;;; then all will be returned in a list:
> + ;;;
> + ;;; (getopt-long '("my-prog" "-vk" "/tmp" "foo1" "--x-includes=/usr/include"
> + ;;;"--x-includes=/opt/includd" "--" "-fred" "foo2" "foo3")
> + ;;;grammar)
> + ;;; (option-ref/many (getopt-long ...) 'x-includes 42)
> + ;;; => ("/usr/include" "/opt/include")
> + 
>   ;;; Code:
>   
>   (define-module (ice-9 getopt-long)
> ***
> *** 162,168 
> #:use-module (ice-9 match)
> #:use-module (ice-9 regex)
> #:use-module (ice-9 optargs)
> !   #:export (getopt-long option-ref))
>   
>   (define %program-name (make-fluid "guile"))
>   (define (program-name)
> --- 176,182 
> #:use-module (ice-9 match)
> #:use-module (ice-9 regex)
> #:use-module (ice-9 optargs)
> !   #:export (getopt-long option-ref option-ref/many))
>   
>   (define %program-name (make-fluid "guile"))
>   (define (program-name)
> ***
> *** 368,371 
> --- 382,397 
>   The value is either a string or `#t'."
> (or (assq-ref options key) default))
>   
> + (define (option-ref/many options key default)
> +   "Return value, or values, in alist OPTIONS using KEY, a symbol; or 
> DEFAULT if not found.
> + The value is either a string, a list or `#t'."
> +   (let loop ((rez #f) (opts options))
> + (if (null? opts) (or rez default)
> + (if (eq? key (caar opts))
> + (cond
> +  ((pair? rez) (loop (cons (cdar opts) res) (cdr opts)))
> +  (rez (loop (list (cdar opts) rez) (cdr opts)))
> +  (else (loop (cdar opts) (cdr opts
> + (loop rez (cdr opts))
> + 
>   ;;; getopt-long.scm ends here

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

[Josep Portella Florit]

El 24/06/16 a les 09:11, Andy Wingo ha escrit:
> On Tue 30 Jun 2015 15:50, Josep Portella Florit  writes:
> 
>> This code crashes Guile 2.0.11:
>>
>> (define x (make-dynamic-state))
>> (with-dynamic-state x (lambda () (/ 1 0)))
> 
> Related: http://thread.gmane.org/gmane.lisp.guile.devel/16953
> 
> How are you using dynamic states?

I have code[1] written in Racket which uses what I think are the
equivalent to Guile's dynamic states: parameterizations.

My code raises exceptions that contain the result of
`(current-parameterization)`[2].  It later handles those exceptions
and passes the parameterization to `call-with-parameterization`[3] in
order to access the value several parameters had before the exception
was raised.

It also accumulates different results of `(current-parameterization)`,
reorders them and for each one it passes the parameterization to
`call-with-parameterization` and calls other code[4].


1: 
   

2: File `pinaret/runtime.rkt`, procedure `raise-error/params`.

3: File `pinaret/system.rkt`, procedure `generate`.
   File `pinaret/runtime.rkt`, procedure `print-error/params`.

4: File `pinaret/base.rkt`, there are many examples here, look for
   `(current-parameterization)`.

bug#21772: 'stexi->shtml' produces invalid SXML for @itemize

[Andy Wingo]

Fixed in master.

Cheers,

Andy

On Sat 19 Mar 2016 14:40, l...@gnu.org (Ludovic Courtès) writes:

> l...@gnu.org (Ludovic Courtès) skribis:
>
>> As of 2.0.11, we get this:
>>
>> scheme@(guile-user)> ,use(texinfo html)
>> scheme@(guile-user)> ,use(texinfo)
>> scheme@(guile-user)> (stexi->shtml (texi-fragment->stexi
>> "@itemize\n@item foo\n@end itemize\n"))
>> $3 = (div (ul (% (bullet (bullet))) (li (p "foo"
>> scheme@(guile-user)> ,use(sxml simple)
>> scheme@(guile-user)> (sxml->xml $3)
>> ERROR: In procedure scm-error:
>> ERROR: Invalid name starting character "%" %
>
> Same with @acronym:
>
> scheme@(guile-user)> (stexi->shtml (texi-fragment->stexi "@acronym{GNU}"))
>
> ;;; WARNING (Don't know how to convert acronym to HTML)
> $2 = (div (p ((% (acronym "GNU")
>
> Ludo’.

bug#21698: accessing multiple flagged values with (ice-9 getopt-long)

[Matt Wette]

Thanks for the pointer.  I can work with SRFI-37.  I am OK w/ rejection of the 
patch.  — Matt

> On Jun 24, 2016, at 7:53 AM, Andy Wingo  wrote:
> 
> Hi Matt,
> 
> Thanks for the patch.  My instinct however is to point you towards
> SRFI-37, which in addition to supporting multiple argument values can
> also be used to fold over the precise argument order.  I just don't know
> that we should be expanding (ice-9 getopt-long); it has its use case and
> if your needs go beyond it, then probably your needs go way beyond it.
> 
>  https://www.gnu.org/software/guile/manual/html_node/SRFI_002d37.html
> 
> Ludovic, second opinions?
> 
> Andy
> 
> On Sat 17 Oct 2015 19:05, Matt Wette  writes:
> 
>> This is in reference to guile-2.0.11.
>> 
>> The (ice-9 getopt-long) module does not provide a process for
>> accessing multiple command line arguments.
>> 
>> A patch for ice-9/getopt-long.scm is attached which adds the procedure
>> getopt-ref/many to access multiple argument values.
>> 
>> The following program and results illustrate the use of the current
>> getopt-ref and the proposed getopt-ref/many:
>> 
>> mwette$ ./gotest.scm -f foo1 -b bar1 -f foo2 baz1 baz2
>> 
>> program arguments:
>> 
>> ("./gotest.scm" "-f" "foo1" "-b" "bar1" "-f" "foo2" "baz1" "baz2")
>> 
>> getopt using option-ref:
>> 
>> foo: "foo2"
>> 
>> bar: "bar1"
>> 
>> getopt using option-ref/many:
>> 
>> foo: ("foo1" "foo2")
>> 
>> bar: "bar1"
>> 
>> where
>> 
>> mwette$ cat gotest.scm 
>> 
>> #!/opt/local/bin/guile
>> 
>> !#
>> 
>> (use-modules (ice-9 getopt-long))
>> 
>> (define spec
>> 
>> '((foo (single-char #\f) (value #t))
>> 
>> (bar (single-char #\b) (value #t
>> 
>> (let* ((args (program-arguments))
>> 
>> (opts (getopt-long args spec)))
>> 
>> (simple-format #t "program arguments:\n")
>> 
>> (simple-format #t "~S\n" args)
>> 
>> (simple-format #t "\ngetopt using option-ref:\n")
>> 
>> (simple-format #t "foo: ~S\n" (option-ref opts 'foo #f))
>> 
>> (simple-format #t "bar: ~S\n" (option-ref opts 'bar #f))
>> 
>> (simple-format #t "\ngetopt using option-ref/many:\n")
>> 
>> (simple-format #t "foo: ~S\n" (option-ref/many opts 'foo #f))
>> 
>> (simple-format #t "bar: ~S\n" (option-ref/many opts 'bar #f))
>> 
>> )
>> 
>> 
>> 
>> *** getopt-long.scm-orig 2015-10-15 06:40:29.0 -0700
>> --- getopt-long.scm  2015-10-17 09:42:41.0 -0700
>> ***
>> *** 154,159 
>> --- 154,173 
>>  ;;; (option-ref (getopt-long ...) 'x-includes 42) => "/usr/include"
>>  ;;; (option-ref (getopt-long ...) 'not-a-key! 31) => 31
>> 
>> + ;;; (option-ref/many OPTIONS KEY DEFAULT)
>> + ;;; Return value in alist OPTIONS using KEY, a symbol; or DEFAULT if not
>> + ;;; found.  If multiple arg-options provided a list is returned.  The value
>> + ;;; is either a string, a list or `#t'.
>> + ;;;
>> + ;;; For example, if the above was executed with multiple x-includes flags,
>> + ;;; then all will be returned in a list:
>> + ;;;
>> + ;;; (getopt-long '("my-prog" "-vk" "/tmp" "foo1" 
>> "--x-includes=/usr/include"
>> + ;;;"--x-includes=/opt/includd" "--" "-fred" "foo2" "foo3")
>> + ;;;grammar)
>> + ;;; (option-ref/many (getopt-long ...) 'x-includes 42)
>> + ;;; => ("/usr/include" "/opt/include")
>> + 
>>  ;;; Code:
>> 
>>  (define-module (ice-9 getopt-long)
>> ***
>> *** 162,168 
>>#:use-module (ice-9 match)
>>#:use-module (ice-9 regex)
>>#:use-module (ice-9 optargs)
>> !   #:export (getopt-long option-ref))
>> 
>>  (define %program-name (make-fluid "guile"))
>>  (define (program-name)
>> --- 176,182 
>>#:use-module (ice-9 match)
>>#:use-module (ice-9 regex)
>>#:use-module (ice-9 optargs)
>> !   #:export (getopt-long option-ref option-ref/many))
>> 
>>  (define %program-name (make-fluid "guile"))
>>  (define (program-name)
>> ***
>> *** 368,371 
>> --- 382,397 
>>  The value is either a string or `#t'."
>>(or (assq-ref options key) default))
>> 
>> + (define (option-ref/many options key default)
>> +   "Return value, or values, in alist OPTIONS using KEY, a symbol; or 
>> DEFAULT if not found.
>> + The value is either a string, a list or `#t'."
>> +   (let loop ((rez #f) (opts options))
>> + (if (null? opts) (or rez default)
>> +(if (eq? key (caar opts))
>> +(cond
>> + ((pair? rez) (loop (cons (cdar opts) res) (cdr opts)))
>> + (rez (loop (list (cdar opts) rez) (cdr opts)))
>> + (else (loop (cdar opts) (cdr opts
>> +(loop rez (cdr opts))
>> + 
>>  ;;; getopt-long.scm ends here

bug#21801: (@ (ice-9 boot-9) x) kills guile 2.0

[Andy Wingo]

On Sat 31 Oct 2015 17:57, Rob Browning  writes:

> $ guile
> GNU Guile 2.0.11
> Copyright (C) 1995-2014 Free Software Foundation, Inc.
>
> Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
> This program is free software, and you are welcome to redistribute it
> under certain conditions; type `,show c' for details.
>
> Enter `,help' for help.
> scheme@(guile-user)> (@ (ice-9 boot-9) x)
> guile: uncaught throw to wrong-type-arg: (set-current-module Wrong
> type argument in position ~A (expecting ~A): ~S (1 module # (guile) 1d79090>) (#))
>
> Some deprecated features have been used.  Set the environment
> variable GUILE_WARN_DEPRECATED to "detailed" and rerun the
> program to get more information.  Set it to "no" to suppress
> this message.
> $

Tx for report, fixed in master:

  scheme@(guile-user)> (@ (ice-9 boot-9) x)
  While compiling expression:
  ERROR: re-loading ice-9/boot-9.scm not allowed

bug#21698: accessing multiple flagged values with (ice-9 getopt-long)

[Ludovic Courtès]

Hello,

Andy Wingo  skribis:

> Thanks for the patch.  My instinct however is to point you towards
> SRFI-37, which in addition to supporting multiple argument values can
> also be used to fold over the precise argument order.  I just don't know
> that we should be expanding (ice-9 getopt-long); it has its use case and
> if your needs go beyond it, then probably your needs go way beyond it.
>
>   https://www.gnu.org/software/guile/manual/html_node/SRFI_002d37.html
>
> Ludovic, second opinions?

Seconded.  I think we should probably “freeze” (ice-9 getopt-long) and
recommend SRFI-37.

Ludo’.

bug#21855: eq?

[Andy Wingo]

On Sun 08 Nov 2015 11:23,  writes:

> On Sat, Nov 07, 2015 at 01:58:48PM +0100, Atticus wrote:
>> So I wanted to try out gnu guix and thus make myself more familiar with
>> guile first. While running some tests I encountered a problem/bug with eq?:
>> 
>> $ guile -v
>> guile (GNU Guile) 2.1.1
>> 
>> $ guile
>> scheme@(guile-user)>
>> (define (multirember a lat)
>>   (cond
>>((null? lat) '())
>>((eq? (car lat) a) (multirember a (cdr lat)))
>>(else (cons (car lat) (multirember a (cdr lat))
>>
>> scheme@(guile-user)> (multirember '(a b) '(x y (a b) z (a b)))
>> $1 = (x y z)
>> 
>> So why does guile return (x y z)? I expected (x y (a b) z (a b)). I know
>> eq? should only be used with symbols (and thus this example is more
>> theoretical) but nevertheless the return value is not right, since (eq?
>> '(a b) '(a b)) returns #f (Btw same in guile 2.0.11).
>
> Hm. As far as I know (eq? '(a b) '(a b)) is not *guaranteed* to evaluate
> to #f. The implementation might be free to re-use things it "knows" to be
> constant (I might be wrong, though).

Tomas is correct; within one compilation unit, constant literals will be
deduplicated.  That means that within one compilation unit, (eq? '(a b)
'(a b)) will indeed be #t yarggg but:

  scheme@(guile-user)> (eq? '(a b) '(a b))
  $1 = #f
  scheme@(guile-user)> ,optimize (eq? '(a b) '(a b))
  $2 = #f

Evidently the optimizer is doing the compare at compile-time, which it
is allowed to do, and at compile-time the values are actually distinct.
I will see if I can fix that.  However Tomas' logic is impeccable :)

Closing as things are all working fine, I think.

Cheers,

Andy

bug#21863: gcc 5 (5.2.1) breaks guile 1.8.7

[Andy Wingo]

On Sun 08 Nov 2015 18:16, Sergey  writes:

> I attempt to build GNU Mailutis (current git) by gcc
> 5.2.1 but it is failed with
>
> ===
> cat mu_address.doc mu_body.doc mu_debug.doc mu_mailbox.doc mu_message.doc 
> mu_mime.doc mu_logger.doc mu_port.doc mu_scm.doc mu_util.doc  | \
>  /usr/bin/guile-tools snarf-check-and-output-texi > 
> guile-procedures.texi
> ERROR: unknown doc attribute: (cname (hash . hash) (id . 
> scm_mu_address_get_personal) (hash . hash))
> make[2]: *** [guile-procedures.texi] Error 1
> ===
>
> gcc 4.7 can build this.
>
> It reminds https://savannah.gnu.org/bugs/?29583

My understanding is that Guile 2.0.11 fixed this problem.  Are you still
seeing this with 2.0.11 ?

Regards,,

Andy

bug#21872: [PATCH] guile fails to build on illumos

[Andy Wingo]

Fixed in git; thanks :)

Andy

On Tue 10 Nov 2015 17:16, Andy Stormont  writes:

> The patch below allows Guile to build on illumos, which does not have full 
> support for the GNU locale extensions.  For more information on what’s 
> missing see here: https://www.illumos.org/issues/5346
>
> diff --git a/configure.ac b/configure.ac
> index 9e639d6..408643b 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -765,8 +765,8 @@ AC_CHECK_FUNCS([DINFINITY DQNAN cexp chsize clog clog10 
> ctermid \
>strdup system usleep atexit on_exit chown link fcntl ttyname getpwent  
>   \
>getgrent kill getppid getpgrp fork setitimer getitimer strchr strcmp \
>index bcopy memcpy rindex truncate unsetenv isblank _NSGetEnviron\
> -  strcoll strcoll_l newlocale uselocale utimensat sched_getaffinity\
> -  sched_setaffinity sendfile])
> +  strcoll strcoll_l strtod_l strtol_l newlocale uselocale utimensat\
> +  sched_getaffinity sched_setaffinity sendfile])
>  
>  # Reasons for testing:
>  #   netdb.h - not in mingw
> diff --git a/libguile/i18n.c b/libguile/i18n.c
> index f0e3443..bd0b5a2 100644
> --- a/libguile/i18n.c
> +++ b/libguile/i18n.c
> @@ -1373,7 +1373,7 @@ SCM_DEFINE (scm_locale_string_to_integer, 
> "locale-string->integer",
>  
>if (c_locale != NULL)
>  {
> -#ifdef USE_GNU_LOCALE_API
> +#if defined USE_GNU_LOCALE_API && defined HAVE_STRTOL_L
>c_result = strtol_l (c_str, &c_endptr, c_base, c_locale);
>  #else
>RUN_IN_LOCALE_SECTION (c_locale,
> @@ -1417,7 +1417,7 @@ SCM_DEFINE (scm_locale_string_to_inexact, 
> "locale-string->inexact",
>  
>if (c_locale != NULL)
>  {
> -#ifdef USE_GNU_LOCALE_API
> +#if defined USE_GNU_LOCALE_API && defined HAVE_STRTOD_L
>c_result = strtod_l (c_str, &c_endptr, c_locale);
>  #else
>RUN_IN_LOCALE_SECTION (c_locale,
>
> - Andy.

bug#21891: Guile 2.1.1: 5 Test failures on OpenBSD/amd64 5.8

[Andy Wingo]

On Thu 12 Nov 2015 18:10, "Alexander Shendi"  writes:

> I have built guile-2.1.1 on OpenBSD/amd64 5.8. I did the following:
>  
> The build itself went smoothly and the system seems to work, but the 
> generated "check-guile.log" shows
> 5 errors. I do not have enough guile-foo to deceide if the failures are 
> serious or not.

Cool, thank you very much for testing the release!

These are the five failures, for what it's worth:

FAIL: i18n.test: locale objects: make-locale with unknown locale
FAIL: i18n.test: character mapping: char-locale-upcase Turkish
FAIL: i18n.test: character mapping: char-locale-downcase Turkish
FAIL: i18n.test: string mapping: string-locale-upcase Turkish
FAIL: i18n.test: string mapping: string-locale-downcase Turkish

They are not terribly serious.  I guess that you get them on Guile
2.0.11 as well.  Is that the case?

The last 4 could a problem with OpenBSD's iconv for turkish locales; not
sure.  I don't know about the first one.

Andy

bug#21887: 'monitor' form broken

[Andy Wingo]

Hi Taylan,

On Thu 12 Nov 2015 16:29, taylanbayi...@gmail.com (Taylan Ulrich 
"Bayırlı/Kammer") writes:

> It seems that the 'monitor' form is currently a no-op.  The form
>
> (par-for-each (lambda (x)
> (monitor
>   (foo)))
>   xs)
>
> should be functionally equivalent to
>
> (let ((mutex (make-mutex)))
>   (par-for-each (lambda (x)
>   (with-mutex mutex
> (foo)))
> xs))
>
> but currently becomes
>
> (par-for-each (lambda (x)
> (let ((mutex (make-mutex)))
>   (with-mutex mutex
> (foo
>   xs)
>
> which is ineffective.
>
> I don't know what's the best way to fix this.  The simplest thing that
> comes to my mind is something along the lines of:
>
> (define-syntax monitor
>   (lambda (stx)
> (syntax-case stx ()
>   ((_ body body* ...)
>(let ((uuid (generate-uuid)))
>  #`(with-mutex (mutex-with-uuid #,uuid)
>  body body* ...))
>
> where mutex-with-uuid looks it up from a hash table at run-time and
> instantiates it when it doesn't exist, this operation also being
> synchronized across threads, like:
>
> (define mutex-table (make-hash-table))
>
> (define mutex-table-mutex (make-mutex))
>
> (define (mutex-with-uuid uuid)
>   (with-mutex mutex-table-mutex
> (or (hash-ref mutex-table uuid)
> (let ((mutex (make-mutex)))
>   (hash-set! mutex-table uuid mutex)
>   mutex
>
> If that looks OK, I can try to make a proper patch from it.  I'm not
> sure what I'd use in place of `generate-uuid' though.  Would `gensym' be
> good enough?

You're totally right on all points.  Please do prepare a patch :)  I
wish we could do something faster for the "embedded" mutex but
correctness should come first.

Cheers,

Andy

bug#21899: let/ec continuations not distinct under compiler

[Andy Wingo]

On Fri 13 Nov 2015 08:57, Zefram  writes:

> With guile 2.0.11:
>
> scheme@(guile-user)> (use-modules (ice-9 control))
> scheme@(guile-user)> (list 'a (let/ec ae (list 'b (let/ec be (be 2)
> $1 = (a (b 2))
> scheme@(guile-user)> (list 'a (let/ec ae (list 'b (let/ec be (ae 2)
> $2 = (a (b 2))
> scheme@(guile-user)> (list 'a (let/ec ae (list 'b (ae 2
> $3 = (a 2)
>
> The middle of these three cases is wrong: it attempts to invoke the outer
> escape continuation, but only goes as far as the target of the inner one,
> which it isn't using.  It therefore produces the same result as the first
> case, which invokes the inner escape continuation.  It ought to behave
> like the third case, which shows that the outer escape continuation can
> be successfully invoked when the unused inner continuation is not present.

This is a compiler bug in 2.0:

scheme@(guile-user)> ,optimize (list 'a (let/ec ae (list 'b (let/ec be (ae 
2)
$2 = (list 'a
  (let ((tag (list 'let/ec)))
(call-with-prompt
  tag
  (lambda ()
(list 'b
  (let ((tag-1 tag))  ;;  here is the bug
(call-with-prompt
  tag-1
  (lambda () (abort-to-prompt tag 2))
  (lambda (_ . results) (@apply values results))
  (lambda (_ . results) (@apply values results)

In master:

scheme@(guile-user)> ,optimize (list 'a (let/ec ae (list 'b (let/ec be (ae 
2)
$1 = (list 'a
  (let ((tag (list 'let/ec)))
(call-with-prompt
  tag
  (lambda ()
(list 'b
  (let ((tag-1 (list 'let/ec)))
(call-with-prompt
  tag-1
  (lambda () (apply abort tag 2 '()))
  (lambda (_ . results) (apply values results))
  (lambda (_ . results) (apply values results)

Weird stuff!

Andy

bug#21897: escape continuation passes barrier

[Andy Wingo]

On Fri 13 Nov 2015 04:31, Zefram  writes:

> scheme@(guile-user)> (use-modules (ice-9 control))
> scheme@(guile-user)> (call/ec (lambda (c) (with-continuation-barrier (lambda 
> () (c "through continuation"))) "c-w-b returned"))
> $1 = "through continuation"
>
> The continuation barrier works fine on call/cc continuations and
> on throw/catch, but doesn't block call/ec continuations.  The manual
> doesn't mention any difference in behaviour for this case, nor can I
> see any obvious justification for it.  The manual's statement that
>
> #  Thus, `with-continuation-barrier' returns exactly once.
>
> is false in this case.  I think a continuation barrier should block the
> use of the call/ec continuation.

I agree, good catch.

Andy

bug#21894: escape continuation doc wrong about reinvokability

[Andy Wingo]

On Fri 13 Nov 2015 00:27, Zefram  writes:

> #  Escape continuations are delimited continuations whose
> # only use is to make a non-local exit--i.e., to escape from the current
> # continuation.  Such continuations are invoked only once, and for this
> # reason they are sometimes called "one-shot continuations".
>
> O RLY?

:)

I removed that last sentence.  By saying less it will be less possible
to enter into this kind of error :)

Thanks for the report,

Andy

BTW: You have submitted some really nice reports!  If you would like to
assign copyright to the FSF so that you can get patches into Guile, let
me know and I can send you the docs.  Cheers :)

bug#21899: let/ec continuations not distinct under compiler

[Andy Wingo]

On Fri 24 Jun 2016 18:29, Andy Wingo  writes:

> On Fri 13 Nov 2015 08:57, Zefram  writes:
>
>> With guile 2.0.11:
>>
>> scheme@(guile-user)> (use-modules (ice-9 control))
>> scheme@(guile-user)> (list 'a (let/ec ae (list 'b (let/ec be (be 2)
>> $1 = (a (b 2))
>> scheme@(guile-user)> (list 'a (let/ec ae (list 'b (let/ec be (ae 2)
>> $2 = (a (b 2))
>> scheme@(guile-user)> (list 'a (let/ec ae (list 'b (ae 2
>> $3 = (a 2)
>>
>> The middle of these three cases is wrong: it attempts to invoke the outer
>> escape continuation, but only goes as far as the target of the inner one,
>> which it isn't using.  It therefore produces the same result as the first
>> case, which invokes the inner escape continuation.  It ought to behave
>> like the third case, which shows that the outer escape continuation can
>> be successfully invoked when the unused inner continuation is not present.
>
> This is a compiler bug in 2.0:
>
> scheme@(guile-user)> ,optimize (list 'a (let/ec ae (list 'b (let/ec be (ae 
> 2)
> $2 = (list 'a
>   (let ((tag (list 'let/ec)))
> (call-with-prompt
>   tag
>   (lambda ()
> (list 'b
>   (let ((tag-1 tag))  ;;  here is the bug
> (call-with-prompt
>   tag-1
>   (lambda () (abort-to-prompt tag 2))
>   (lambda (_ . results) (@apply values results))
>   (lambda (_ . results) (@apply values results)

Narrowed down:

  ,opt (let* ((x (list 'a))
  (y (list 'a)))
 (list x y))
  ;; ->
  (let* ((x (list 'a)) (y x)) (list x y))

It's a bug in 2.0's CSE pass somehow.

Andy

bug#21899: let/ec continuations not distinct under compiler

[Zefram]

Andy Wingo wrote:
>  ,opt (let* ((x (list 'a))
>  (y (list 'a)))
> (list x y))
>  ;; ->
>  (let* ((x (list 'a)) (y x)) (list x y))

Wow, that's a scary level of wrongitude.  It's specific to let* (or
equivalent nested let forms), but really easy to trigger within that:

scheme@(guile-user)> (let ((x (list 'a)) (y (list 'a))) (eq? x y))
$1 = #f
scheme@(guile-user)> (let* ((x (list 'a)) (y (list 'a))) (eq? x y))
$2 = #t
scheme@(guile-user)> (let ((x (list 'a))) (let ((y (list 'a))) (eq? x y)))
$3 = #t

-zefram

bug#21899: let/ec continuations not distinct under compiler

[Zefram]

One more variant:

scheme@(guile-user)> (let ((x (list 'a))) (eq? x (list 'a)))
$1 = #t
scheme@(guile-user)> ,opt (let ((x (list 'a))) (eq? x (list 'a)))
$2 = (let ((x (list 'a))) (eq? x x))

-zefram

bug#21899: let/ec continuations not distinct under compiler

[Andy Wingo]

On Fri 24 Jun 2016 19:00, Zefram  writes:

> Andy Wingo wrote:
>>  ,opt (let* ((x (list 'a))
>>  (y (list 'a)))
>> (list x y))
>>  ;; ->
>>  (let* ((x (list 'a)) (y x)) (list x y))
>
> Wow, that's a scary level of wrongitude.

Indeed :/

Fixed in git with this patch:

>From ea352d9e54793783a8272863748ea6d31b3f7295 Mon Sep 17 00:00:00 2001
From: Andy Wingo 
Date: Fri, 24 Jun 2016 19:03:36 +0200
Subject: [PATCH] Fix bug that exposed `list' invocations to CSE

* module/language/tree-il/effects.scm (make-effects-analyzer):
  Fix analysis for list, cons, make-prompt-tage, and vector; &allocation
  is a `cause' effect.  Fixes #21899.
* test-suite/tests/cse.test ("cse"): Add test case.
---
 module/language/tree-il/effects.scm | 8 
 test-suite/tests/cse.test   | 9 +
 2 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/module/language/tree-il/effects.scm 
b/module/language/tree-il/effects.scm
index 1fe4aeb..6db4d47 100644
--- a/module/language/tree-il/effects.scm
+++ b/module/language/tree-il/effects.scm
@@ -278,16 +278,16 @@ of an expression."
   ;; Primitives that allocate memory.
   (($  _ ($  _ 'cons) (x y))
(logior (compute-effects x) (compute-effects y)
-   &allocation))
+   (cause &allocation)))
 
   (($  _ ($  _ (or 'list 'vector)) args)
-   (logior (accumulate-effects args) &allocation))
+   (logior (accumulate-effects args) (cause &allocation)))
 
   (($  _ ($  _ 'make-prompt-tag) ())
-   &allocation)
+   (cause &allocation))
 
   (($  _ ($  _ 'make-prompt-tag) (arg))
-   (logior (compute-effects arg) &allocation))
+   (logior (compute-effects arg) (cause &allocation)))
 
   ;; Primitives that are normally effect-free, but which might
   ;; cause type checks, allocate memory, or access mutable
diff --git a/test-suite/tests/cse.test b/test-suite/tests/cse.test
index e0219e8..ca7dbc2 100644
--- a/test-suite/tests/cse.test
+++ b/test-suite/tests/cse.test
@@ -294,6 +294,15 @@
  (apply (primitive cons) (const 1) (const 2) (const 3))
  (const 4)))
 
+  ;; The (list 'a) does not propagate.
+  (pass-if-cse
+   (let* ((x (list 'a))
+  (y (list 'a)))
+ (list x y))
+   (let (x) (_) ((apply (primitive list) (const a)))
+(let (y) (_) ((apply (primitive list) (const a)))
+ (apply (primitive list) (lexical x _) (lexical y _)
+
   (pass-if "http://bugs.gnu.org/12883";
 ;; In 2.0.6, compiling this code would trigger an out-of-bounds
 ;; vlist access in CSE's traversal of its "database".
-- 
2.8.3

bug#21698: accessing multiple flagged values with (ice-9 getopt-long)

[Andy Wingo]

On Fri 24 Jun 2016 17:30, l...@gnu.org (Ludovic Courtès) writes:

> Andy Wingo  skribis:
>
>> Thanks for the patch.  My instinct however is to point you towards
>> SRFI-37, which in addition to supporting multiple argument values can
>> also be used to fold over the precise argument order.  I just don't know
>> that we should be expanding (ice-9 getopt-long); it has its use case and
>> if your needs go beyond it, then probably your needs go way beyond it.
>>
>>   https://www.gnu.org/software/guile/manual/html_node/SRFI_002d37.html
>>
>> Ludovic, second opinions?
>
> Seconded.  I think we should probably “freeze” (ice-9 getopt-long) and
> recommend SRFI-37.

Okeydoke, closing.  Thanks!

Andy

bug#21902: doc incorrectly describes Julian Date

[Andy Wingo]

Greets,

Time is not my area of expertise :)  Cc'ing guile-devel to see if
someone can review the ideas.

Would you like to propose a specific patch to the documentation?  The
file is in doc/ref/srfi-modules.texi.

Regards,

Andy

On Fri 13 Nov 2015 13:58, Zefram  writes:

> The manual says, in the section "SRFI-19 Introduction",
>
> #Also, for those not familiar with the terminology, a "Julian Day" is
> # a real number which is a count of days and fraction of a day, in UTC,
> # starting from -4713-01-01T12:00:00Z, ie. midday Monday 1 Jan 4713 B.C.
>
> There are two errors in the first statement of the epoch for Julian Date,
> in ISO 8601 format.  The JD epoch is noon on 1 January 4713 BC *in the
> proleptic Julian calendar*.  The ISO 8601 format is properly never used on
> the Julian calendar: ISO 8601 specifies the use of the Gregorian calendar,
> including proleptically where necessary (as it most certainly is here).
> On the proleptic Gregorian calendar, the JD epoch is noon on 24 November
> 4714 BC, and so the ISO 8601 expression should have some "-11-24".
>
> The second error is in how the year is expressed in ISO 8601.  The initial
> "-" does not mean the BC era, it means that the year number is negative.
> ISO 8601 specifies that the AD era is always used, with year numbers
> going negative where necessary; this arrangement is commonly known as
> "astronomical year numbering".  So "" means 1 BC, "-0001" means 2
> BC, and "-4713" means 4714 BC.  So the "-4713" is not correct for the
> attempted expression of the Julian calendar date, but happens to be
> correct for the Gregorian calendar date.
>
> Putting it together, a correct ISO 8601 expression for the Julian Date
> epoch is "-4713-11-24T12:00:00Z".
>
> The word-based statement of the JD epoch is correct as far as it goes,
> but would benefit considerably by the addition of a clause stating that
> it is in the proleptic Julian calendar.  (Generally, a clarification
> of which calendar is being used is helpful with the statement of any
> date prior to the UK's switch of calendar in 1752.)  The description of
> Modified Julian Date is essentially correct.
>
> However, there's a third problem: misuse of the term "UTC" for historical
> times.  The description of Julian Date says it's counted "in UTC",
> and the statement of the MJD epoch describes its 1858 time as being
> specified in UTC.  UTC is defined entirely by its relationship to TAI,
> which is defined by the operation of atomic clocks.  TAI is therefore
> only defined for the period since the operation of the first caesium
> atomic clock in the middle of 1955.  The UTC<->TAI relationship isn't
> actually defined even that far back: UTC begins at the beginning of
> 1961 (and that was not in the modern form with leap seconds).  It is
> therefore incorrect to apply the term "UTC" to any time prior to 1961.
> These two references to UTC should instead be to "UT", the wider class
> of closely-matching time scales of which UTC is one representative.
> Also, in the first sentence of this doc section, the phrase "universal
> time (UTC)" should be either "universal time (UT)" or (more likely)
> "coordinated universal time (UTC)".
>
> -zefram

bug#22141: guile-2.1.1 fails with error 134 in ice-9/psyntax-pp.go on cygwin x86_64

[Andy Wingo]

On Fri 11 Dec 2015 17:50, "Arnaud Gardelein"  writes:

> Platform: cygwin / x86_64
> Attached config.log
>
> Error message:
>   BOOTSTRAP GUILEC ice-9/psyntax-pp.go
> Uncaught exception:
> Throw to key system-error with args ("load-thunk-from-memory" "~A"
> ("Invalid argument") (22))Threads explicit registering is not previously
> enabled
> /bin/sh: line 6: 42916 Aborted (core dumped)

This sounds like either a limitation in BDW-GC or a misconfiguration of
BDW-GC, or some strange interaction with the pthreads library on
cygwin.  Have you been able to build 2.0.11?  (I ask about 2.0.11
because it has seen wider and deeper testing.)

Andy

bug#21902: doc incorrectly describes Julian Date

[Zefram]

Andy Wingo wrote:
>Would you like to propose a specific patch to the documentation?

Sure.  Patch attached.

-zefram
--- a/doc/ref/srfi-modules.texi 2014-03-20 20:21:21.0 +
+++ b/doc/ref/srfi-modules.texi 2016-06-24 18:57:59.088243245 +0100
@@ -2461,8 +2461,8 @@
 @cindex UTC
 @cindex TAI
 This module implements time and date representations and calculations,
-in various time systems, including universal time (UTC) and atomic
-time (TAI).
+in various time systems, including Coordinated Universal Time (UTC)
+and International Atomic Time (TAI).
 
 For those not familiar with these time systems, TAI is based on a
 fixed length second derived from oscillations of certain atoms.  UTC
@@ -2494,18 +2494,12 @@
 @cindex julian day
 @cindex modified julian day
 Also, for those not familiar with the terminology, a @dfn{Julian Day}
-is a real number which is a count of days and fraction of a day, in
-UTC, starting from -4713-01-01T12:00:00Z, ie.@: midday Monday 1 Jan
-4713 B.C.  A @dfn{Modified Julian Day} is the same, but starting from
-1858-11-17T00:00:00Z, ie.@: midnight 17 November 1858 UTC.  That time
-is julian day 240.5.
-
-@c  The SRFI-1 spec says -4714-11-24T12:00:00Z (November 24, -4714 at
-@c  noon, UTC), but this is incorrect.  It looks like it might have
-@c  arisen from the code incorrectly treating years a multiple of 100
-@c  but not 400 prior to 1582 as non-leap years, where instead the Julian
-@c  calendar should be used so all multiples of 4 before 1582 are leap
-@c  years.
+is a real number which is a count of days and fraction of a day, in UT,
+starting from -4713-11-24T12:00:00Z, ie.@: midday UT on Monday 24 November
+4714 BC in the proleptic Gregorian calendar (1 January 4713 BC in the
+proleptic Julian calendar).  A @dfn{Modified Julian Day} is the same,
+but starting from 1858-11-17T00:00:00Z, ie.@: midnight UT on Wednesday
+17 November AD 1858.  That time is julian day 240.5.
 
 
 @node SRFI-19 Time

bug#21698: accessing multiple flagged values with (ice-9 getopt-long)

[Matt Wette]

> On Jun 24, 2016, at 8:30 AM, Ludovic Courtès  wrote:
> 
> Hello,
> 
> Andy Wingo  skribis:
> 
>> Thanks for the patch.  My instinct however is to point you towards
>> SRFI-37, which in addition to supporting multiple argument values can
>> also be used to fold over the precise argument order.  I just don't know
>> that we should be expanding (ice-9 getopt-long); it has its use case and
>> if your needs go beyond it, then probably your needs go way beyond it.
>> 
>>  https://www.gnu.org/software/guile/manual/html_node/SRFI_002d37.html
>> 
>> Ludovic, second opinions?
> 
> Seconded.  I think we should probably “freeze” (ice-9 getopt-long) and
> recommend SRFI-37.

Agree.  Could you at the least add a reference to SRFI-37 in the section on 
(ice-9 getopt-long), in case you don’t go further — e.g., replace it?

Matt