lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: scm_local_eval is not available in Guile V2.


From: David Kastrup
Subject: Re: scm_local_eval is not available in Guile V2.
Date: Wed, 16 Nov 2011 12:01:11 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.90 (gnu/linux)

David Kastrup <address@hidden> writes:

> David Kastrup <address@hidden> writes:
>
>> Ian Hulin <address@hidden> writes:
>>
>>> Hi all,
>>>
>>> The latest git now dies on my V2 Guile system with
>>> .../lily/parse-scm.cc:59:64: error 'scm_local_eval' was not declared in
>>> this scope.
>>
>> Related.  #{ ... #} is evaluated in the lexical context of the
>> surrounding function.  Is there anything that made Guile a flexible
>> tool left in Guile V2?  "compilation" gives us all the disadvantages
>> and rigidity of C at a fraction of its speed, it seems.
>>
>> I'll have to see whether I can come up with something working even
>> half as nicely.  Probably will have to be rather close to the kludge
>> we had before.
>
> Ok, I have a scheme for doing this in a likely V2-compatible way.  Not
> really pretty, though.  I just compile all # and $ expressions in #{ #}
> into anonymous lambda functions at compile time of #{ ... #}, and when
> the content of #{ ... #} is actually parsed for real, I call the lambda
> functions in sequence for getting the corresponding values.  There may
> be a possible alternative implementation using continuations, but I have
> my doubts about the efficiency or even viability of doing this with V2.
>
> But it does not make sense to do this change on current master before
> some additional changes now in countdown are in.  So you'll be a few
> more days without working setup.  Sorry for that.

<URL:http://code.google.com/p/lilypond/issues/detail?id=2043>

Accompanying patch is relative to staging currently.  This should get
you going again.  I don't particularly like this approach, and it is
more complex and error-prone, and likely slower than the original
version.  But without access to procedure-environments, I see no simpler
way out here.

-- 
David Kastrup




reply via email to

[Prev in Thread] Current Thread [Next in Thread]