Hi Ian,
Ian Hulin writes:
> ian@nanny-ogg ~/src/lilypond (T2026-1)>> guild compile
> --load-path="/home/ian/src/lilypond:/home/ian/src/lilypond/scm"
According to both the Guile manual and the output of "guile compile -h":
-L, --load-path=DIR add DIR to the front of the module load path
In
> From: Andy Wingo
> Cc: l...@gnu.org (Ludovic Courtès), 10...@debbugs.gnu.org,
> commander.si...@googlemail.com
> Date: Thu, 02 Feb 2012 01:59:21 +0100
>
> I would like to take this task off his back, assuming he's OK with it:
> the release process was terribly long, and Ludo deserves a rest ;
Hi Eli,
Ludovic said it already, but it bears repeating: thank you very much for
this investigation!
I would like to take this task off his back, assuming he's OK with it:
the release process was terribly long, and Ludo deserves a rest ;)
I will assume that the canonicalize_file_name issues will
Using this small test file load-path-test.scm using
meta/uninstalled-env bash with V2.0.5:
(eval-when (compile load eval)
(format #t "version: ~s\n" (version) )
(format #t "%load-path: ~s\n" %load-path)
(format #t "(access? (%search-load-path \"c++.scm\"): ~s\n"
(%search-load-path "c++.scm")))
On Fri 27 Jan 2012 19:36, Andy Wingo writes:
> On Wed 25 Jan 2012 17:10, l...@gnu.org (Ludovic Courtès) writes:
>
>> Second thing, it suffices to insert a function call like
>> ((lambda (x) #f) #f) just before calls to ‘gc’ to solve the problem.
>>
>> So I’m thinking we may have a real bug here.
On Wed 01 Feb 2012 17:13, Andreas Schwab writes:
> Andy Wingo writes:
>
>> But threads.test passes?
>
> Due to the nature of these tests the absense of a failure doesn't tell
> you much.
Indeed. As much as I would like for there to be certainty...
>> Which gc.test fails?
>
> FAIL: gc.test: gc
Hi David,
David Fang skribis:
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
This mos
Hi David,
David Fang skribis:
> 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
Thi
Andy Wingo writes:
> But threads.test passes?
Due to the nature of these tests the absense of a failure doesn't tell
you much.
> Which gc.test fails?
FAIL: gc.test: gc: Unused modules are removed
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 175
On Wed 01 Feb 2012 16:16, Andreas Schwab writes:
> Andy Wingo writes:
>
>> On Sat 03 Dec 2011 01:26, Andreas Schwab writes:
>>
>>> threads.test has the same problem: the test "mutex with owner not
>>> retained (bug #27450)" can fail because of a spurious stack reference to
>>> the mutex object.
Andy Wingo writes:
> On Sat 03 Dec 2011 01:26, Andreas Schwab writes:
>
>> threads.test has the same problem: the test "mutex with owner not
>> retained (bug #27450)" can fail because of a spurious stack reference to
>> the mutex object.
>
> Thanks for the note. We have a patch that didn't make
On 1 Feb 2012, at 15:53, Andy Wingo wrote:
>> There is no issue with libffi from latest GIT compiled with
>> llvm-gcc-4.2, and guile-2.0.5 compiled with SVN gcc-4.7.
>
> But there is an issue with libffi from git compiled with llvm-gcc-4.2,
> and guile-2.0.5 compiled with llvm-gcc-4.2?
Right, on
On Wed 01 Feb 2012 14:36, Hans Aberg writes:
> There is no issue with libffi from latest GIT compiled with
> llvm-gcc-4.2, and guile-2.0.5 compiled with SVN gcc-4.7.
But there is an issue with libffi from git compiled with llvm-gcc-4.2,
and guile-2.0.5 compiled with llvm-gcc-4.2?
Can you try co
On 1 Feb 2012, at 02:42, Mark H Weaver wrote:
>> Running bytevectors.test
>> FAIL: bytevectors.test: 2.3 Operations on Bytes and Octets:
>> bytevector-sint-ref [small] (eval)
>> FAIL: bytevectors.test: 2.3 Operations on Bytes and Octets:
>> bytevector-sint-ref [small] (compile)
>
> In the direc
On 1 Feb 2012, at 12:50, Andy Wingo wrote:
>> It suggests that problem is with llvm-gcc (an clang), I think. With
>> gcc-4.7 there is no libffi failure.
>
> Is it correct to say that you experience this issue if libffi is
> compiled with llvm-gcc / clang, …
Yes, and also guile-2.0.5 (see below f
On Wed 01 Feb 2012 10:18, Hans Aberg writes:
> It suggests that problem is with llvm-gcc (an clang), I think. With
> gcc-4.7 there is no libffi failure.
Is it correct to say that you experience this issue if libffi is
compiled with llvm-gcc / clang, but do not experience this issue if
libffi is
On 1 Feb 2012, at 02:42, Mark H Weaver wrote:
> Hans Aberg writes:
>> With gcc-4.7.0 (from SVN), the test-ffi test now passes (libffi from
>> GIT)
>
> Excellent! I guess that this was a libffi bug.
No, I think it is with llvm-gcc, in view of that it remained in that compile
(as described in a
On 1 Feb 2012, at 02:49, Mark H Weaver wrote:
>> After doing this, the same failure with the LLVM-GCC compiler:
>> /usr/bin/cc -> llvm-gcc-4.2
>> /usr/bin/gcc -> llvm-gcc-4.2
>> i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1
>>
>> This is the compiler that one will use on OS X 10.7 if one instal
18 matches
Mail list logo
