Sorry, I always start thinking only when far too late in the game.
Anyway, here is a musing:
should't the _main_ interface to accidental modifications be context
mods? You won't need to set them in midcontext except in unusual
situations, and then \applyContext (?) is available.
Or does that mak
On Wed, Oct 19, 2011 at 10:00:26PM -0600, Colin Campbell wrote:
> >Command barfed: cd /home/colin/gub/target/tools/build/curl-7.19.0
> >&& make -j4
> >
> >Tail of target/tools/log/curl.log
> >make[1]: *** [all] Error 2
> >make[1]: Leaving directory
> >`/home/colin/gub/target/tools/
Neil, don't forget to push this.
I've been looking forward to it.
http://codereview.appspot.com/4819064/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On 11-10-08 10:38 AM, Graham Percival wrote:
On Sat, Oct 08, 2011 at 04:03:02PM +0100, Phil Holmes wrote:
Patch for GUB git to update locations of relevant files that were missing.
Thanks, pushed.
Cheers,
- Graham
After doing a git pull -r in ~/gub, then make bootstrap -dB, I get:
must
On 10/19/11 3:14 PM, "David Kastrup" wrote:
>
>>
>> I am not enthused about this particular consequence of auto-exporting
>> Scheme expressions. I currently don't see a better way of handling it,
>> and it has flagged more bad code than false positives when I tried it.
>> But I would be quite
On Wed, Oct 19, 2011 at 11:14:26PM +0200, David Kastrup wrote:
> An afterthought, however: we do have an inordinate amount of user-level
> commands that need to be called from Scheme rather than with Lilypond
> syntax. That does not make sense. Void music functions have been
> around for eterniti
David Kastrup writes:
> Carl Sorensen writes:
>
>> On 10/19/11 3:26 AM, "David Kastrup" wrote:
>>>
>>>\void #(hashq-set! ...)
>>>\void #(hashq-set! ...)
>>>
>>>rather than
>>>
>>>\ignore #(hashq-set! ...)
>>>\ignore #(hashq-set! ...)
>>>
>>>It's a bit C-ish, but not all that bad, and it fits wi
Carl Sorensen writes:
> On 10/19/11 3:26 AM, "David Kastrup" wrote:
>>
>>\void #(hashq-set! ...)
>>\void #(hashq-set! ...)
>>
>>rather than
>>
>>\ignore #(hashq-set! ...)
>>\ignore #(hashq-set! ...)
>>
>>It's a bit C-ish, but not all that bad, and it fits with
>>define-void-function.
>
> \return
On 10/19/11 3:26 AM, "David Kastrup" wrote:
>Štěpán Němec writes:
>
>> On Wed, 19 Oct 2011 10:22:09 +0200
>> David Kastrup wrote:
>>
>>> What would people prefer for creating a Lilypond function that returns
>>> an "unspecified" value (what the Guile read-eval-print loop takes as a
>>> hint to p
David Kastrup writes:
>> David Kastrup writes:
>>
>>> It might make sense to introduce a syntax change like that in two
>>> stages: in the first stage, one just complains about embedded Scheme
>>> that could be mistaken for something useful. Only in the second
>>> stage, one does not complain b
Štěpán Němec writes:
> On Wed, 19 Oct 2011 11:26:18 +0200
> David Kastrup wrote:
>
>> Ok. Now unfortunately, Guile has a number of functions that one would
>> expect to return SCM_UNSPECIFIED, but which return something else.
>> hashq-set!, set-object-property! and a few others. So I need a nic
Štěpán Němec writes:
> On Wed, 19 Oct 2011 10:22:09 +0200
> David Kastrup wrote:
>
>> What would people prefer for creating a Lilypond function that returns
>> an "unspecified" value (what the Guile read-eval-print loop takes as a
>> hint to print nothing at all) and is called for its side effect
You're right... So I vote for define-void-function.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Bertrand Bordage writes:
> "define-procedure" sounds too generic to me. Why not
> "define-void-procedure" ?
That's two distinctions from define-*-function and we need just one as
far as I can see. If we have define-void-procedure, what would be a
non-void procedure? If there is no such thing
"define-procedure" sounds too generic to me. Why not
"define-void-procedure" ?
Bertrand
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
What would people prefer for creating a Lilypond function that returns
an "unspecified" value (what the Guile read-eval-print loop takes as a
hint to print nothing at all) and is called for its side effect?
define-void-function or define-procedure? The first is a bit more
C-ish, the second more
On Oct 18, 2011, at 3:56 PM, n.putt...@gmail.com wrote:
>
> http://codereview.appspot.com/5235052/diff/17001/lily/script-engraver.cc
> File lily/script-engraver.cc (right):
>
> http://codereview.appspot.com/5235052/diff/17001/lily/script-engraver.cc#newcode206
> lily/script-engraver.cc:206:
> Sc
17 matches
Mail list logo