Whether the returned object needs to be cleared or not depends on a
couple things:
- Whether the embedder actually needs the object to be cleared.
- Whether the collector allocated the object from memory that was all
zeroes already.
The goal of course would be to prevent clearing memory if the mutator
was just going to write all over it. But it's hard to know statically
if the memory would have been all zeroes anyway, and in that case if you
did clear it you'd be doing double work. In the end it's simpler to
just require collectors to clear memory in bulk. We can revisit this
later if it is an issue.
The tests share a "log" for custom port events and didn't always
explicitly close the test ports, so the close might come later, during
another test. Change the tests to always close their ports immediately,
and clear the log after checking for expected "inter-test" events.
test-suite/tests/r6rs-ports.test: don't race with gc close in custom
port tests.
Without -ffat-lto-objects libguile.a ends up with no symbols, visible
via "nm t libguile.a".
cf. https://lintian.debian.org/tags/no-code-sections.html
* configure.ac: enable -ffat-lto-objects with -flto when available.
doc/ref/posix.texi: note setlocale raises a system-error when locale
doesn't exist
Thanks to Francesco P. Lovergine for suggesting the
addition (https://bugs.debian.org/1078681).
This is an amendment to 84bf840322.
The warning was only emitted for calling `environ', even if only reading
and no mutation occurred.
However, it is correct to read the environment in a multi-threaded
process. It is however unsafe to mutate it.
The same logic also applies to `putenv'.
* libguile/posix.c
(maybe_warn_about_environ_mutation): New private procedure ...
(scm_environ): ... called here when mutating the environment ...
(scm_putenv): ... and here.
* NEWS: Update.
Signed-off-by: Ludovic Courtès <ludo@gnu.org>
Fixes <https://bugs.gnu.org/76343>.
Fixes a bug whereby “echo '(environ)' | guile” would wrongfully trigger
the multiple-thread warning.
* libguile/finalizers.c (finalizer_thread): New variable.
(finalization_thread_proc): Set it.
(scm_i_is_finalizer_thread): New function.
(run_finalization_thread): Clear FINALIZER_THREAD.
* libguile/finalizers.h (scm_i_is_finalizer_thread): New declaration.
* libguile/threads.c (scm_all_threads): Use it.
* NEWS: Update.
Reported-by: Simon Josefsson <simon@josefsson.org>
The tutorial was removed in commit f75c5849cd.
* doc/README: Remove reference to a tutorial that no longer exists
Signed-off-by: Ludovic Courtès <ludo@gnu.org>
* libguile/scm.h: BUILDING_LIBGUILE is not always defined. This is
signaled by -Werror=undef in code using libguile. This patch fixes
commit dc3a3a84f9
* NEWS: Update.
Signed-off-by: Ludovic Courtès <ludo@gnu.org>
* module/ice-9/custom-ports.scm (make-custom-port): Code fails if
(fluid-ref %default-port-encoding) returns #f. In fact this was the
case why readline support on MSYS2 failed for guile 3.0.10, ref.
https://github.com/msys2/MSYS2-packages/issues/5079
But later used canonicalize-encoding is prepared to handle #f for
encoding. So allow encoding to also handle this case.
Co-authored-by: Ludovic Courtès <ludo@gnu.org>
The omission was discovered while cross-compiling LilyPond with mingw
11.0.1: without this addition, linking with libguile causes the error
undefined reference to `BCryptGenRandom'
* meta/Makefile.am (dependency_substitutions): Add ‘LIB_GETRANDOM’.
* meta/guile-3.0-uninstalled.pc.in (Libs.private): Likewise.
* meta/guile-3.0.pc.in (Libs.private): Likewise.
* NEWS: Update.
Signed-off-by: Ludovic Courtès <ludo@gnu.org>
The ~V is supposed to print ISO week number, not a week number. This
commit fixes that.
* module/srfi/srfi-19.scm (date-week-number-iso): New procedure taken
from the reference implementation.
(directives)<#\V>: Use it.
* test-suite/tests/srfi-19.test ("date->string ~V"): Add tests taken
from the reference test suite.
* doc/ref/srfi-modules.texi (SRFI-19 Date to string): Mention ISO-8601
in description for ~V.
Fixes <https://bugs.gnu.org/74841>.
Edited by lloda <lloda@sarc.name>.
RISC-V uses a0-a7 registers for argument passing. Float/double arguments
use f0-f7 first and continue in a0-a7 if needed.
Once registers are consumed, stack is used.
This commit changes how lightening passes arguments in order to allow
this behavior.
