Hi Andy,
Andy Wingo writes:
> On Wed 09 May 2018 02:32, Mark H Weaver writes:
>
>> However, I think it's _far_ more likely that the NULL argument on the
>> stack was copied from memory shared by multiple threads without proper
>> thread synchronization.
>
> I think this is unlikely on x86 given
Hello,
Marius Bakke skribis:
> I'm trying to update librsvg, which requires "rust".
Speaking of which, what are other distros doing? Are all of them
switching to the Rust implementation, or are some keeping the C
implementation?
Not that I’m fond of C, but adding Rust (which is not bootstrapp
Hi Mark,
Mark H Weaver skribis:
> Our 'ghc-case-insensitive' package contains two 'inputs' field
> initializers. If I'm not mistaken, the first one is being effectively
> ignored, so 'ghc-hunit' is not actually an input.
>
> It would be good to clean this up so that we can start raising errors
Gábor Boskovits writes:
> Yes, I have run into this already when doing the updates for java8. Debian
> seems to have a patch for this here:
> https://anonscm.debian.org/viewvc/pkg-java/trunk/libhamcrest-java/debian/patches/002-random-build-failure.patch?view=log
The patch would require adding j
2018-05-09 13:22 GMT+02:00 Ricardo Wurmus :
> Hi Guix,
>
> “java-hamcrest-all” fails to build with a curious error message. It
> first builds hamcrest-core-1.3.jar and then complains about being unable
> to access “org/hamcrest/Description.class” from that jar.
>
> --8<---cut here
Hello!
I'm trying to update librsvg, which requires "rust".
However adding this simple diff:
--- a/gnu/packages/gnome.scm
+++ b/gnu/packages/gnome.scm
@@ -114,6 +114,7 @@
#:use-module (gnu packages pulseaudio)
#:use-module (gnu packages python)
#:use-module (gnu packages rdesktop)
+ #:
Hi Guix,
“java-hamcrest-all” fails to build with a curious error message. It
first builds hamcrest-core-1.3.jar and then complains about being unable
to access “org/hamcrest/Description.class” from that jar.
--8<---cut here---start->8---
starting phase `build'
On Wed 09 May 2018 11:23, l...@gnu.org (Ludovic Courtès) writes:
>> Is the memoization you are referring to the "set!" in the "lazy" form in
>> ice-9/eval.scm ? Or something else? FWIW I would not think the "set!"
>> could be the issue, at least on x86, but who knows.
>
> Actually I’m not sure e
Hello Andy!
Andy Wingo skribis:
> On Mon 30 Apr 2018 23:39, l...@gnu.org (Ludovic Courtès) writes:
>
>> So the problem, AIUI, is that psyntax evaluates syntax parameters using
>> ‘primitive-eval’ (via ‘eval-local-transformer’), but memoization in
>> (ice-9 eval) is not thread-safe, hence the ran
Hey Chris,
Chris Marusich skribis:
> I've committed this as ede121de426f9c56820852888a0b370f0ccbce49 on the
> master branch. If anything breaks on Hydra or elsewhere, please don't
> hesitate to revert it.
Awesome, thank you!
Ludo’.
On Wed 09 May 2018 02:32, Mark H Weaver writes:
> However, I think it's _far_ more likely that the NULL argument on the
> stack was copied from memory shared by multiple threads without proper
> thread synchronization.
I think this is unlikely on x86 given its total-store-ordering memory
model.
Hi,
On Mon 30 Apr 2018 23:39, l...@gnu.org (Ludovic Courtès) writes:
> So the problem, AIUI, is that psyntax evaluates syntax parameters using
> ‘primitive-eval’ (via ‘eval-local-transformer’), but memoization in
> (ice-9 eval) is not thread-safe, hence the random crashes.
Sorry I've been a bit
Hi Mark,
Mark H Weaver skribis:
> l...@gnu.org (Ludovic Courtès) writes:
> [...]
>> Thread 1 (Thread 0x7f6fe6f5d700 (LWP 2856)):
>> #0 0x7f7019db0d79 in scm_is_pair (x=> Cannot access memory at address 0x0>0x0) at ../libguile/pairs.h:159
>> #1 scm_ilength (sx=) at list.c:190
> [...]
>> Wha
13 matches
Mail list logo
