[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Commit 4778c7326d726f50f6ac541322006d6b90795945
From: |
David Kastrup |
Subject: |
Re: Commit 4778c7326d726f50f6ac541322006d6b90795945 |
Date: |
Tue, 06 Dec 2011 18:08:39 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.0.90 (gnu/linux) |
"address@hidden" <address@hidden> writes:
> Le Dec 6, 2011 à 2:01 PM, David Kastrup a écrit :
>
>> "address@hidden" <address@hidden> writes:
>>
>>> Hey all,
>>>
>>> I believe that the variable `clone' needs to be unquoted in commit
>>> 4778c7326d726f50f6ac541322006d6b90795945 (it is part of a quasi-quoted
>>> list). I haven't tested it thoroughly, but please give it a look and
>>> lemme know if this is indeed the case.
>>
>> How about reporting the problem you are actually seeing?
>>
>
> If one defines a music function incorrectly and then tries to use it, i.e. :
>
> foo =
> #(define-music-function (parser location)
> #{ a #})
>
> \foo
>
> One gets the following warning message:
>
> Parsing...
> foo.ly:4:1: error: GUILE signaled an error for the expression beginning here
> #
> (define-music-function (parser location)
> Unbound variable: clone
> fatal error: failed files: "foo.ly"
Pushed a few patches to staging making this blow up sooner more reliably
with symptoms easier associated with #{ #} and music lists.
Also I like the output of
#(write '#{ this $is #(it!) #})
better than previously.
It's not the same as an error handtailored to the mistake, but that is
actually astonishingly hard to do.
--
David Kastrup