I'd need someone to take this sketch and integrate it into the build
system (I just don't really understand the build system).
It is shown how to place a request for file size into
Documentation/web.texi and there is a script that will convert such
requests found in HTML files into user-readable
I see they reviewed SourceHut, which seems to be actively trying to
comply with FSF's repository expectations. I'd come across SourceHut
earlier, and its minimalist design and a few other things reminded me a
little of LilyPond's culture.
--
Karlin High
Missouri, USA
Pierre-Luc Gauthier writes:
> Le mar. 25 févr. 2020 à 04:54, David Kastrup a écrit :
>> ./configure CXXFLAGS=-DNDEBUG
>
> Thanks David.
> It compiles fine.
>
> Now engraving hangs at the same place but a bit differently :
>
> Calculating page and line breaks (8 possible page
> breaks)...[1][2][3
Le mar. 25 févr. 2020 à 04:54, David Kastrup a écrit :
> ./configure CXXFLAGS=-DNDEBUG
Thanks David.
It compiles fine.
Now engraving hangs at the same place but a bit differently :
Calculating page and line breaks (8 possible page
breaks)...[1][2][3][4][5][6][7][8]
Drawing systems...
programmin
Jonas Hahnfeld writes:
> Hi all,
>
> I was meaning to write on the next steps of switching to new tooling
> when I came across this:
> https://lwn.net/Articles/813254/rss
> https://www.fsf.org/blogs/sysadmin/coming-soon-a-new-site-for-fully-free-collaboration
> https://libreplanet.org/wiki/Fsf_20
Hi all,
I was meaning to write on the next steps of switching to new tooling
when I came across this:
https://lwn.net/Articles/813254/rss
https://www.fsf.org/blogs/sysadmin/coming-soon-a-new-site-for-fully-free-collaboration
https://libreplanet.org/wiki/Fsf_2019_forge_evaluation
In particular the
So I can see a consistent improvement by ~40s for 'make -j4 CPU_COUNT=4
test', going down from ~4m to 3m30s. The patch at
https://codereview.appspot.com/547680043 explains that this is due to
parallelism in input/regression/lilypond-book/. I see no influence on
'make -j4 CPU_COUNT=4 doc', staying f
On 2020/02/25 19:50:34, lemzwerg wrote:
> > Do we really want that many "no"s in the output
>
> Currently, you get this (in one long line):
>
> checking for guile-1.8 >= 1.8.2... checking for guile-2.2 >=
2.2.0... checking
> for guile-2.0 >= 2.0.7... Package guile-2.0 was not found in the
pkg-c
Reviewers: hahnjo,
Message:
> Do we really want that many "no"s in the output
Currently, you get this (in one long line):
checking for guile-1.8 >= 1.8.2... checking for guile-2.2 >= 2.2.0...
checking for guile-2.0 >= 2.0.7... Package guile-2.0 was not found in
the pkg-config search path. Perh
https://codereview.appspot.com/573570044/diff/559570043/aclocal.m4
File aclocal.m4 (right):
https://codereview.appspot.com/573570044/diff/559570043/aclocal.m4#newcode683
aclocal.m4:683: AC_MSG_RESULT([no])
Do we really want that many "no"s in the output
https://codereview.appspot.com/573570044/
https://codereview.appspot.com/581700043/diff/569410044/lily/ttf.cc
File lily/ttf.cc (right):
https://codereview.appspot.com/581700043/diff/569410044/lily/ttf.cc#newcode95
lily/ttf.cc:95:
On 2020/02/25 17:53:20, lemzwerg wrote:
> I think the second empty line can be removed.
Done.
https://cod
>> PS: I've cleaned up `configure.ac` and `aclocal.m4` in the staging
>> branch.
>
> Ugh, that's giving me a nice set of conflicts.
Sorry for that.
Werner
> It sounds like actual manipulation of that property
> by the user would interfere with the implementation
> of french-beaming. So maybe just mark/sort it as an
> internal property and only regtest french-beaming as
> such?
If this is the intention, yes.
https://codereview.appspot.com/557500043
LGTM
https://codereview.appspot.com/551510043/
LGTM, thanks!
https://codereview.appspot.com/581700043/diff/569410044/lily/ttf.cc
File lily/ttf.cc (right):
https://codereview.appspot.com/581700043/diff/569410044/lily/ttf.cc#newcode95
lily/ttf.cc:95:
I think the second empty line can be removed.
https://codereview.appspot.com/581700043/diff/
Hi,
just so that nobody thinks we have forgotten it: the translators have
not yet completely caught up to the state of last-minute documentation
cherry-picks. Anybody who tried translating single chapters/sections of
the various manuals should know what a humongous task maintaining a full
docum
On 2020/02/25 13:33:13, lemzwerg wrote:
> > > Please add one or more test cases for your 'french-correction'
property.
> >
> > What specific French beaming examples are you missing?
>
> I was probably unclear. What I want is an example that shows how the
> 'french-correction' *property* changes
Am Dienstag, den 25.02.2020, 11:13 +0100 schrieb Werner LEMBERG:
> Folks,
>
>
> something that can be easily missed while doing reviews with Rietveld:
> Since a long time we avoid tabs if possible.
>
>
> Werner
>
>
> PS: I've cleaned up `configure.ac` and `aclocal.m4` in the staging
>
On 2020/02/25 13:33:13, lemzwerg wrote:
> If you really wanted 'i.e.' without a trailing comma, it would be
necessary to
> write 'i.e.@:'. Otherwise makeinfo inserts two spaces in the '.info'
file
> because we don't use '@frenchspacing' in the English docs.
Thanks for the valuable explanation.
> > s/i.e./i.e.,/
>
> Ah, then I suppose the changes.tely language is American English...
Yes, for the whole documentation we use (more or less) American spelling
rules. If you really wanted 'i.e.' without a trailing comma, it would
be necessary to write 'i.e.@:'. Otherwise makeinfo inserts tw
On 2020/02/25 13:06:31, Be-3 wrote:
> On 2020/02/24 06:44:39, hanwenn wrote:
> > One thing to consider: since the mechanics are now very predictable,
maybe we
> > can name the property in after its mechanics? ie. french-correction
->
> > stem-end-shorten or something?
>
> After having thought abou
On Feb 25, 2020, at 05:29, Werner LEMBERG wrote:
>
> What do you think about converting all tabs in the .mf files to
> spaces? If you agree, I would apply this to the staging.
I don't usually work in that domain, so SGTM.
—
Dan
Proposed changes applied to my local branch (most of them), see
comments.
Ta,
Torsten
https://codereview.appspot.com/557500043/diff/551490044/Documentation/changes.tely
File Documentation/changes.tely (right):
https://codereview.appspot.com/557500043/diff/551490044/Documentation/changes.tely#ne
> It's not urgent, is it?
No, not at all. It just appeared to be a trivial change.
https://codereview.appspot.com/545640044/
On 2020/02/24 06:44:39, hanwenn wrote:
> One thing to consider: since the mechanics are now very predictable,
maybe we
> can name the property in after its mechanics? ie. french-correction ->
> stem-end-shorten or something?
After having thought about it for quite a while I'm not too happy with
"s
Reviewers: lemzwerg,
Message:
On 2020/02/25 11:29:35, lemzwerg wrote:
> LGTM. Please directly push.
I think the reason I could answer this more or less off-the-cuff was
that it confused the heck out of me until I figured out the reason. So
my fear is that when people now use M-x add-directory-l
Werner LEMBERG wrote
> What do you think about converting all tabs in the .mf files to
> spaces?
I consider this a good idea.
On the one hand, we are encouraged /not/ to use tabs. On the other hand,
however, especially mf files are full of them and I've often wondered how to
behave when modifying
On 25/02/2020 11:26, David Kastrup wrote:
pkx1...@posteo.net writes:
Hello,
(replying to my own email)
On 25/02/2020 10:59, pkx1...@posteo.net wrote:
Hello,
I reported this last week (and to be fair I did get replies) but
didn't get the chance to follow up.
I have a few hours spare this we
LGTM. Please directly push.
https://codereview.appspot.com/545640044/
> I know it says
>
> /usr/bin/ld: final link failed: No space left on device
> collect2: error: ld returned 1 exit status
>
> but I have plenty. I moved the build dir to a place I know I have
> plenty of space (just to be sure) and still get the same problem.
>
> Could this be some permission is
pkx1...@posteo.net writes:
> Hello,
>
> (replying to my own email)
>
> On 25/02/2020 10:59, pkx1...@posteo.net wrote:
>> Hello,
>>
>> I reported this last week (and to be fair I did get replies) but
>> didn't get the chance to follow up.
>>
>> I have a few hours spare this week and I just tried to
Hello,
(replying to my own email)
On 25/02/2020 10:59, pkx1...@posteo.net wrote:
Hello,
I reported this last week (and to be fair I did get replies) but
didn't get the chance to follow up.
I have a few hours spare this week and I just tried to run
patchy-staging from the lilypond-extra dir
> /usr/bin/ld: final link failed: No space left on device
This looks suspicious. Have you verified that you have enough free
disk space?
Werner
>> PPS: I see that we have a file `.dir-locals.el` in the git
>> repository; doesn't its contents contradict our tabs policy?
>
> No, it implements it.
Ah, ok. Thanks for the explanation.
> Yes, does not read well to human readers. Maybe one should tack on
> the redundant . nil here, but
Hello,
I reported this last week (and to be fair I did get replies) but didn't
get the chance to follow up.
I have a few hours spare this week and I just tried to run
patchy-staging from the lilypond-extra dir based (and I have just
recloned by lilypond-got repo) and it fails on the very fir
Werner LEMBERG writes:
> Folks,
>
>
> something that can be easily missed while doing reviews with Rietveld:
> Since a long time we avoid tabs if possible.
>
>
> Werner
>
>
> PS: I've cleaned up `configure.ac` and `aclocal.m4` in the staging
> branch.
>
> PPS: I see that we have a file `.
On 2020/02/25 08:07:14, hanwenn wrote:
> LGTM
>
> (I wonder if we should bite the bullet and use uint64_t iso. U64.)
Just for the record: the big bullet would be a Simple_smob wrapper class
around Guile's rational data type. Showstopper in the current setup:
Moments in data structures contain ra
What do you think about converting all tabs in the .mf files to
spaces? If you agree, I would apply this to the staging.
Werner
Folks,
something that can be easily missed while doing reviews with Rietveld:
Since a long time we avoid tabs if possible.
Werner
PS: I've cleaned up `configure.ac` and `aclocal.m4` in the staging
branch.
PPS: I see that we have a file `.dir-locals.el` in the git repository;
d
Pierre-Luc Gauthier writes:
> Hi David,
>
> Thanks for your answer.
>
> Le lun. 24 févr. 2020 à 17:25, David Kastrup a écrit :
>> -DNDEBUG
>
> Sadly, I'm not a programmer although I compile LilyPond weekly. I
> tried adding the -DNDEBUG flag in many places to no avail. I'm using
> Arch Linux and
On 2020/02/25 08:09:21, hanwenn wrote:
> Jonas, did you want to have another look?
Yes, hopefully later today, no guarantee though
https://codereview.appspot.com/555360043/
https://codereview.appspot.com/545630044/diff/579320044/make/ly-rules.make
File make/ly-rules.make (right):
https://codereview.appspot.com/545630044/diff/579320044/make/ly-rules.make#newcode64
make/ly-rules.make:64: $(call ly_progress,Making,$@,< texi)
You should delete these lines completely.
On Mon, Feb 24, 2020 at 11:19 PM Pierre-Luc Gauthier
wrote:
> Is there anyone on this list who would be willing to help this bug
> along? I will gladly pay for this feature to be working again might
> any of you be interested. I have 9 full orchestra+chorus projects to
> render by… well its alread
Jonas, did you want to have another look?
https://codereview.appspot.com/555360043/
LGTM
(I wonder if we should bite the bullet and use uint64_t iso. U64.)
https://codereview.appspot.com/573570043/
On Mon, Feb 24, 2020 at 10:44 PM David Kastrup wrote:
> > The result is 25 minutes of purely CPU bound grinding (this is with
> > Guile 2.2). Then building the remaining docs takes about 15 minutes.
> > In this last phase, there is some inefficiency: we process the
> > documents per language direc
46 matches
Mail list logo
