Now I see the problem. The properties you are using are those created
in a pre-engraving step, done separately on each of the inputs to
\partcombine. Using properties of those separate contexts for the
force-part-combine state is a bad idea.
Right now, \partCombineApartOnce, etc., affects the
On 2014/10/28 07:00:33, Keith wrote:
In order to make a \once\partcombineApart work like most other
\once\override
commands, you would have to do something like delay the forced
part-combine
decisions until the real engraving, write a real Part_combine_engraver
that
lives in the Staff,
Phil Holmes writes:
https://github.com/gperciva/gub
I don't think librestrict has changed in years, works for me [on 14.10].
Jan
$ ./bin/gub tools::librestrict
calculating dependencies
Checking for gcc ... /usr/bin/gcc
must rebuild[tools]: system::gcc librestrict make libtool file tar m4 perl
Jan Nieuwenhuizen jann...@gnu.org writes:
Phil Holmes writes:
https://github.com/gperciva/gub
I don't think librestrict has changed in years, works for me [on 14.10].
Huh. Both of you on the same side of 32/64 bit?
--
David Kastrup
___
- Original Message -
From: David Kastrup d...@gnu.org
To: Jan Nieuwenhuizen jann...@gnu.org
Cc: Phil Holmes m...@philholmes.net; Federico Bruni
fedel...@gmail.com; lilypond-devel@gnu.org
Sent: Tuesday, October 28, 2014 10:58 AM
Subject: Re: GUB and mpfr/mpc
Jan Nieuwenhuizen
I get:
calculating dependencies
Checking for gcc ... /usr/bin/gcc
must rebuild[tools]: system::gcc librestrict make libtool file tar m4 perl
autoconf patch zlib
building package: tools::librestrict
*** Stage: download (librestrict, tools)
*** Stage: untar (librestrict, tools)
*** Stage: patch
On Oct 28, 2014, at 03:00 , k-ohara5...@oco.net wrote:
Now I see the problem. The properties you are using are those created
in a pre-engraving step, done separately on each of the inputs to
\partcombine. Using properties of those separate contexts for the
force-part-combine state is a bad
On Oct 28, 2014, at 07:25 , Phil Holmes m...@philholmes.net wrote:
Tail of target/tools/log/librestrict.log
./xstatconv.c:269:5: error: 'struct stat' has no member named '__unused5'
buf-__unused5 = 0;
^
What *is* in the structure? Could there be something ridiculous like #define
unused
Phil Holmes writes:
If there's nothing in the log file, you'll have to investigate by hand.
Go to the build directory and see
cd /home/gub/gub/target/tools/build/librestrict-1.9.a
gcc -W -Wall -fno-stack-protector -I. -fPIC -shared -o librestrict-stat.so
restrict-stat.c
(eg, doing
Phil Holmes writes:
Mine is 32 bit in a VM.
I'm on 64 bit iron -- however, this hasn't changed in years. Possibly
a weird include path that does not use the local kernel_stat.h but
takes it fro somewhere else?
Jan
--
Jan Nieuwenhuizen jann...@gnu.org | GNU LilyPond http://lilypond.org
I get:
~/gub/target/tools/build/librestrict-1.9.a$
gcc -W -Wall -fno-stack-protector -I. -fPIC -shared -o librestrict-stat.so
restrict-stat.c
In file included from restrict-stat.c:106:0:
./xstatconv.c: In function ‘__xstat_conv’:
./xstatconv.c:90:5: error: ‘struct stat’ has no member named
On 2014/10/28 12:35:08, dan_faithful.be wrote:
On Oct 28, 2014, at 03:00 , mailto:k-ohara5...@oco.net wrote:
Now I see the problem. The properties you are using are those
created
in a pre-engraving step, done separately on each of the inputs to
\partcombine. Using properties of those
This seems to allow the style of partcombine where unisons are
double-stemmed which would be very nice.
You can, if you like, put a small image (like a 2kB png) on the lilypond
issue tracker showing the desired output; then people can understand the
purpose of the patch.
I see that
LGTM
https://codereview.appspot.com/163520043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
14 matches
Mail list logo
