FWIW, here’s what `make test-clean; time make-test’ returns:
Without the patch:
real10m5.239s
user17m3.656s
sys 1m2.055s
With the patch:
real9m27.001s
user17m5.396s
sys 1m0.880s
(Note that I’m not saying it has any meaning.)
V.
On 2019/02/08 09:49:58, lemzwerg wrote:
On 2019/02/08 09:42:27, dak wrote:
> https://codereview.appspot.com/347070043/diff/1/lily/relocate.cc
> File lily/relocate.cc (right):
>
>
https://codereview.appspot.com/347070043/diff/1/lily/relocate.cc#newcode128
> lily/relocate.cc:128:
> Where is the output name constructed for the MIDI file? To be more
> precise, where is the string
>
>
> /home/wl/git/lilypond/input/regression/midi/crescendo-gap-compatible-target.ly
>
> converted to the basename of the MIDI file? Right now, in function
> `write-performance-midis' (file
https://codereview.appspot.com/347070043/diff/1/lily/relocate.cc
File lily/relocate.cc (right):
https://codereview.appspot.com/347070043/diff/1/lily/relocate.cc#newcode128
lily/relocate.cc:128: TOPLEVEL_VERSION, package_datadir));
Why no .c_str () here (and lots of other places)?
Reviewers: dak,
Message:
On 2019/02/08 09:42:27, dak wrote:
https://codereview.appspot.com/347070043/diff/1/lily/relocate.cc
File lily/relocate.cc (right):
https://codereview.appspot.com/347070043/diff/1/lily/relocate.cc#newcode128
lily/relocate.cc:128: TOPLEVEL_VERSION, package_datadir));
Can you give any reason why it _should_ work rather than "I tried"?
flower/include/international.hh:46
https://codereview.appspot.com/347070043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
Frankly, my approach would be to throw that function out. It just
obfuscates what will and what will not work and keeps GCC from issuing
warnings when number and uses of %s don't match.
Hmm. Having a C++ version of `_f' is actually quite nice, since
appending `c_str' again and again is a
On 2019/02/08 11:51:37, dak wrote:
Frankly, I don't like it. The relevant metric here is the user time
and it's
_increased_ in your benchmark (not that it's likely significant).
Agreed.
Throwing code in that the compiler does not know about is
not likely to be much of an advantage.
In
On 08.02.19 04:51, Carl Sorensen wrote:
On 2/6/19, 3:42 PM, "lilypond-devel on behalf of Knut Petersen"
wrote:
>> - the need to make sure that `python` calls a python2 interpreter.
> No idea how this could be solved elegantly. I guess it can't, so we
> have again
On 08.02.19 14:12, Knut Petersen wrote:
Hi everybody!
Use /usr/bin/env python2? Does every python 2.x installation
really contain a python2 executable?
OSX 10.12 Sierra has python 2.7 but does not have a python2
executable. Only python.
At least this is the case on my machine.
On 2019/02/08 11:41:45, lemzwerg wrote:
> Can you give any reason why it _should_ work rather than "I tried"?
flower/include/international.hh:46
Oh good grief.
string _f (char const *format, ...)
__attribute__ ((format (printf, 1, 2)));
string _f (char const *format, const string , const
Hi everybody!
Use /usr/bin/env python2? Does every python 2.x installation really
contain a python2 executable?
OSX 10.12 Sierra has python 2.7 but does not have a python2 executable.
Only python.
At least this is the case on my machine.
Gosh, didn't expect that.
In that case,
On 2019/02/08 09:46:17, Valentin Villenave wrote:
FWIW, here’s what `make test-clean; time make-test’ returns:
Without the patch:
real10m5.239s
user17m3.656s
sys 1m2.055s
With the patch:
real9m27.001s
user17m5.396s
sys 1m0.880s
(Note that I’m not saying it has
On 2/8/19, 10:17 AM, "lilypond-devel on behalf of d...@gnu.org"
wrote:
On 2019/02/08 17:05:46, Valentin Villenave wrote:
> On 2019/02/08 16:41:06, dak wrote:
> > For what?
> Since you’re complaining about LilyPond-specific functions not handled
by Guile,
> what
On 2019/02/08 16:41:06, dak wrote:
For what?
For making some functions ever so slightly less cumbersome to type and
to read. But I’m gathering from your question that you’ve never felt
any need for it :-)
Since you’re complaining about LilyPond-specific functions not handled
by Guile, what
On 2019/02/08 17:05:46, Valentin Villenave wrote:
On 2019/02/08 16:41:06, dak wrote:
> For what?
For making some functions ever so slightly less cumbersome to type and
to read.
But I’m gathering from your question that you’ve never felt any need
for it :-)
(not (null? xxx)) vs (not-null?
On 2019/02/08 12:45:43, Valentin Villenave wrote:
On 2019/02/08 11:51:37, dak wrote:
> Frankly, I don't like it. The relevant metric here is the user time
and it's
> _increased_ in your benchmark (not that it's likely significant).
Agreed.
> Throwing code in that the compiler does not
> - addition of texinfo/txi-pt.tex from Texinfo sources, as Portuguese
> translation has been added and I don't have Texinfo installed in GUB
> host system;
??? What exactly needs Portuguese? Lilypond doesn't, AFAICS.
> - update of texinfo.tex (not necessary, but I did it together with
>
On Feb 8, 2019, at 07:05, d...@gnu.org wrote:
>
> string
> _f (char const *format, const string , const string , const string
> )
> {
> return String_convert::form_string (gettext (format), s.c_str (),
> s2.c_str (),
> s3.c_str ());
> }
>
> anyway. Frankly,
Hi everybody!
I think with the attached test-patch on top of the patch I already sent to you
'make lilypond' (not only bin/gub xxx::lilypond) should succeed after you put
the newly created wrapper directory in front of PATH.
I see; this wrapper directory is more convenient than asking the
20 matches
Mail list logo
