s message.
For the catalan language, something is off. It tries to find
contribuïdor.ca.pdf (note the i with " ).
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
/d4a36739fbf2b85e3a6c85fdf76b482b8c07b656
from May 2010. This means that the support for internationalized
snippets through gettext on variables and comments hasn't worked in
over 10 years (and nobody noticed?). To me this seems like a strong
signal that we should get rid of this feature.
thoughts?
--
Han-Wen Nienhuys - hanw
ng fast.
What annoys me is that the default build creates the info docs, which
aren't necessary for developing lilypond.
> Jonas
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
> I wouldn't add a milestone to this.
What is the idea behind milestones?
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
not my proposal anymore to just branch, but Han-Wen's idea of
> > having a freeze of 3-4 weeks before branching.
>
> For me, a freeze can only start if we agree that nothing fundamental
> has to be changed or added. IMHO, we are far away from such a state.
Could you enumerate the issues you think are fundamental?
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
Hi folks,
there is a doc Documentation/en/contributor/administration.itexi,
which is full of discussion of issues that were pressing in ~2012 or
so. In particular, the GOP. Some of it seems quite outdated. Which
parts of this doc should we keep around?
--
Han-Wen Nienhuys - hanw...@gmail.com
On Sun, Sep 6, 2020 at 1:40 PM Jonas Hahnfeld wrote:
>
> Am Sonntag, den 06.09.2020, 12:33 +0200 schrieb Han-Wen Nienhuys:
> > On Sat, Sep 5, 2020 at 10:52 AM Jonas Hahnfeld wrote:
> > > > I think the real problem is that we don't know exactly how many
> > >
weeks seems long enough to
gather some feedback, but short enough that experimental/feature work
should not be affected.
The objective of the freeze is to focus developer energy on fixing
regressions rather than causing new regressions.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
On Thu, Sep 3, 2020 at 11:16 AM Jonas Hahnfeld wrote:
>
> Am Mittwoch, den 26.08.2020, 00:05 +0200 schrieb Han-Wen Nienhuys:
> > On Tue, Aug 25, 2020 at 11:17 PM Jonas Hahnfeld wrote:
> > > > I think the stabilization effort could be a joint effort by the entire
>
t; out-of-date information.
>
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
hile 03b is correct only *before *my commit is applied (i.e. on the
> baseline commit).
I have seen this too. I suspect there is some hash table randomization
in the xml2ly code that makes the result unpredictable. It's not
related to the fonts, so I'd just ignore it for now.
--
Han-
features and
invasive changes for a period of time (say, 1 to 2 months).
BTW- aside from GUILE 2 and Python 3 support, I think users will also
be happy with the speedups that I've been working on in this cycle.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
ing a build that is no longer recursive, but that work
could be paused for a bit while we prepare for releasing a 2.22.
Is there a list of problems in the current master that have to be resolved?
We could also consider a freeze for some time period (eg. 1-2 months),
to allow the master branch t
t include them at all?
> Best regards,
> Rafael Fontenelle
>
> On Sat, Aug 22, 2020 at 10:30 AM Han-Wen Nienhuys wrote:
> >
> > Opa, beleza?
> >
> > There is something odd going on with the portuguese doc translations
> > in lilypond,
> >
> >
>
On Sat, Aug 22, 2020 at 3:52 PM Jonas Hahnfeld wrote:
>
> Am Samstag, den 22.08.2020, 14:53 +0200 schrieb Han-Wen Nienhuys:
> > what do you think about including git onto the docker image?
>
> No objection, it just wasn't necessary so far (gitlab-runner does all
> git ope
?). I also some other
weird translations (look for "infringimento").
Could you check what is going on here?
thanks!
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
/-/merge_requests/341>
> Don't crash if one of the gittxt files is missing
> Commit Author
> Han-Wen Nienhuys <https://gitlab.com/hanwenn>
>
> Pipeline #180832599
> <https://gitlab.com/lilypond/lilypond/-/pipelines/180832599> triggered by
> Han-Wen
> Nienhuys
s of
historical cruft in /var/www/lilypond, but I think we could just add the
above .htaccess to the website.zip file, and do the same for the
documentation tarball.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
k.py: error: file not found:
> > single-staff-template-with-notes-and-lyrics.ly
> > This file _is_ present, I checked this!
> > Without changing anything I did `make -j5 CPU_COUNT=5` again.
> > Success!
> >
> > What's going on?
>
see https://gitlab.com/lilypond/
; of current master.
> It failed with
> lilypond-book.py: error: file not found:
> single-staff-template-with-notes-and-lyrics.ly
> This file _is_ present, I checked this!
> Without changing anything I did `make -j5 CPU_COUNT=5` again.
> Success!
>
> What's going on?
>
>
On Sun, Aug 9, 2020 at 12:44 PM Han-Wen Nienhuys wrote:
> make translation-status
>> translations-status.py
>> Reading documents...
>> Generating status pages...
>> translations-status.py:717: warning: using markup = TexiMarkup (): ugly
>> HTML
>> o
o 2] No such file or directory:
> 'ca/en/translations.itexi'
> make: *** [GNUmakefile:483: translation-status] Error 1
>
>
> Sorry that I haven't participated enough with it.
>
> Cheers,
> --
> Jean-Charles
>
>
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
I fixed it up manually for now.
On Sat, Aug 8, 2020 at 2:05 PM Han-Wen Nienhuys wrote:
> It looks like there has to be a index.en.html -> index.html symlink, which
> went awol in the new website.
>
> On Sat, Aug 8, 2020 at 1:57 PM Han-Wen Nienhuys wrote:
>
>&g
It looks like there has to be a index.en.html -> index.html symlink, which
went awol in the new website.
On Sat, Aug 8, 2020 at 1:57 PM Han-Wen Nienhuys wrote:
> It looks like catalan.
>
> On Sat, Aug 8, 2020 at 1:57 PM Andrew Bernard
> wrote:
>
>> Or perhaps that is
It looks like catalan.
On Sat, Aug 8, 2020 at 1:57 PM Andrew Bernard
wrote:
> Or perhaps that is Portuguese?
>
> On Sat, 8 Aug 2020 at 21:53, Andrew Bernard
> wrote:
>
> > All my browsers now show lilypond.org in Spanish all of a sudden this
> > evening.
>
Not sure; maybe one of my horn study books by Mueller. But it was an early
glyph, so it may need tweaking.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
gt; interesting to see what lily thinks the skylines look like.
>
> Here it is.
>
>
>
these are the skylines for vertical spacing. You need the ones for
horizontal spacing. Look at the commented out stencil callback for
PaperColumn in define-grobs.scm.
> Werner
>
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
with accidentals. Looks like a bug. If you agree I'll add it to the
> tracker.
>
> Any idea how to circumvent that?
>
the breathing sign is non-musical, and the accidental is musical, so this
should be prevented by the skyline distancing. It would be interesting to
see what lily thin
understand you personally want to build some info files quickly for
browsing, but what use are info files without images to users that actually
want to understand how to write music notation?
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
vert this decision. Otherwise,
> please fix it
>
Not intentional, see
https://gitlab.com/lilypond/lilypond/-/merge_requests/306
May I ask what you use the image-less info files for? Supporting them is
one of the warts in the doc build, and I suspect they cater to a just small
minority of
lated to `extractpdfmark`.
>
See https://gitlab.com/lilypond/lilypond/-/merge_requests/305
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
did you get started on (title) ? If not I can start.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
d embedded-svg in -dsafe mode - Han-Wen
> Nienhuys
> https://gitlab.com/lilypond/lilypond/-/merge_requests/265
>
>
this was already on push last Sunday, and I merged it then.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
On Mon, Jul 27, 2020 at 11:22 PM Han-Wen Nienhuys wrote:
>
>
> On Sun, Jul 26, 2020 at 10:57 AM Jonas Hahnfeld wrote:
>
>>
>> Other ideas?
>>
>
> I have some alternate ideas on how to redo the backend, but likely can
> only make time to try it on F
On Sun, Jul 26, 2020 at 10:57 AM Jonas Hahnfeld wrote:
>
> Other ideas?
>
I have some alternate ideas on how to redo the backend, but likely can only
make time to try it on Friday.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
e recent discussion around making --safe the default are also relevant:
if we split lilypond in two parts (the untrusted renderer and the trusted
part that handles PDF/PNG conversion), we'd likely have to reorganize how
Stencil expressions end up in PS files.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
oc/latest/ still
> points to 2.19. Is this expected?
>
> Best,
> Jean
>
>
>
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
uld anybody
> > > object to dropping this for Guile v1.8 already? That would potentially
> > > also simplify the introduction of automated regression test comparison
> > > in the CI pipeline...
> >
> > I'm also in favor of dropping this.
>
> Good, I'
an appropriate reflection as well? What do you all
> think?)
I don't understand why we need 2 properties here. What benefit do we
get relative to a single property?
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
at statprof.scm:251:4
6.7% #x2212b88
Is there a way to get insight into what these hex addresses (?) mean?
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
ance
measurements.
> Moreover, cell counts won't be available with Guile v2.x (at least the
> property 'total-cells-allocated doesn't exist anymore). Would anybody
> object to dropping this for Guile v1.8 already? That would potentially
> also simplify the introduction of automated regression
On Fri, Jul 17, 2020 at 5:05 PM Han-Wen Nienhuys wrote:
>
> On Fri, Jul 17, 2020 at 4:47 PM Han-Wen Nienhuys wrote:
> > Maybe something is off with the init after fork, but GUILE's random
> > initialization also doesn't look very reliable:
> >
> > https://git.sava
On Fri, Jul 17, 2020 at 4:47 PM Han-Wen Nienhuys wrote:
> Maybe something is off with the init after fork, but GUILE's random
> initialization also doesn't look very reliable:
>
> https://git.savannah.nongnu.org/cgit/guile.git//tree/libguile/random.c/?id=5f22d1090bef72639f2744402c04
On Thu, Jul 16, 2020 at 10:58 AM David Kastrup wrote:
>
> Han-Wen Nienhuys writes:
>
> > On Wed, Jul 15, 2020 at 10:48 PM David Kastrup wrote:
> >
> >> Well ok. But only 100 random numbers are being used (there is
> >> another call using 10
is?
See
https://gitlab.com/lilypond/lilypond/-/merge_requests/252
you can apply this fix locally by overwriting the .scm file with the
ones in the attached zipfile.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
<>
> > Does anyone have the same issue?
>
> Phil reported the same problem when trying another release build.
> Han-Wen, are you looking into this?
>
> Thanks
> Jonas
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
d
> of 9 possibilities for collision. That would raise the probability of a
> collision to about 1 in 40 runs.
I think you misremember. The command
make -jN CPU_COUNT=N
will potentially spawn 2*N -1 processes: 1 x lilypond-book with N
children and N- 1 other processes.
--
Han-Wen Nienhuys
fallout of the recent texi2html work?
should we install texi2html 5.0 on lilypond.org ?
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
g up a style sheet (see
> http://lilypond.org/doc/v2.21/Documentation/contributor/index_1#Introduction-to-contributing
> as a simple example) - they're certainly not presented correctly. Could
> anyone say what has gone wrong and what needs to be done to fix it?
>
>
> --
> Phil Ho
On Sun, Jul 5, 2020 at 11:54 PM Graham Percival
wrote:
>
> On Sun, Jul 05, 2020 at 10:38:50PM +0200, Han-Wen Nienhuys wrote:
> > is there any other function of web.texi besides producing the
> > lilypond.org website? I would like to get rid of the "-D web_version"
>
Hi there,
is there any other function of web.texi besides producing the
lilypond.org website? I would like to get rid of the "-D web_version"
distinction, that is making web_version always be true for the web
document. Is there any reason to not do this?
--
Han-Wen Nienhuys - hanw...
y other details.
Thanks. I could go on asking questions, but I am really looking for
data rather than opinions.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
on development
happening with Gonville as a standard font?
> Hope this can help.
I think the most practical solution is to wait for Smufl support for
LilyPond, which should make it easier to use a wide array of music
fonts.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
hat would reformat diffs, I can integrate that in my
pre-commit hook, so all new code is compliant.
You can also do a global cleanup. We have done this in the past, but
it has the disadvantage that it makes history (eg. git-blame) harder
to read.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
tely to unblock
> further work.
yes, LGTM.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
On Sun, Jun 28, 2020 at 2:43 PM Jonas Hahnfeld wrote:
> > commit 99ee305b37d5804cd215cd8a222ec8a1eccb8caf
> > Author: Han-Wen Nienhuys
> > Date: Wed Jun 17 23:12:27 2020 +0200
> >
> > Write output files atomically
> >
> > or more precisely afte
urrent time
> > in its log output [...]
>
> AFAIK, Metafont and Metapost (among many other TeXLive binaries)
> support the `SOURCE_DATE_EPOCH` environment variable to allow
> reproducible builds. I suggest that we set this variable.
I tried setting it in mf/GNUmakefile, but it did
On Sat, Jun 27, 2020 at 6:29 PM Han-Wen Nienhuys wrote:
>
> On Fri, Jun 26, 2020 at 11:37 PM Jonas Hahnfeld wrote:
> >
> > Hi all,
> >
> > at least the following two MRs experience strange failures in CI:
> > https://gitlab.com/lilypond/lilypond/-/merge
producible and the container image is for
> sure, so it has to be something else.
>
> Jonas
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
gt; When comparing the build artifacts, I noticed that the output files in
> mf/ are not reproducible. I'm not sure if that is related, but the
> lilypond binary itself is reproducible and the container image is for
> sure, so it has to be something else.
--
Han-Wen Nienhuys - hanw...@gmail
project to transition from Feta names to Smufl names.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
if I change the
> extensions to .cc and .hh to match the rest of the files?
>
> Thanks,
> Owen
>
> On Tue, Jun 23, 2020 at 12:39 PM Han-Wen Nienhuys
> wrote:
>
>> On Tue, Jun 23, 2020 at 9:55 AM Jonas Hahnfeld via Discussions on
>> LilyPond development wrote:
>> >
rrent split between flower/ and lily/. Please get
> opinions from other developers that have been involved longer than me.
How many files are they?
If there are many of them, we should have a separate subdirectory. If
it's just a few, flower/ would be a good place.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
ow I use version 9.52; I guess this is the
> culprit since I don't think that any other program in my environment
> has changed.
>
> Can anyone confirm my observations? Masamichi-san?
I can see the 44M number here, but I have extractpdfmark disabled. Can
you confiirm it is being run?
--
H
On Sun, Jun 21, 2020 at 12:07 PM Jonas Hahnfeld wrote:
>
> Am Samstag, den 20.06.2020, 20:25 +0200 schrieb Han-Wen Nienhuys:
> > What is the status of our lilypond binary on windows?
> >
> > The GUB based binary used to include a hacked-together Python
> > interpre
> access.
> If you want, you can now press 'Merge' button for the MR above or just
> push the commit to translation manually.
>
> Jonas
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
What is the status of our lilypond binary on windows?
The GUB based binary used to include a hacked-together Python
interpreter, which -due to being cross-compiled- had some serious
limitations. Is this still the binary we recommend to use ?
--
Han-Wen Nienhuys - hanw...@gmail.com - http
lab.com:lilypond/lilypond.git
On a slight tangent: it would also be nice if we could use gitlab for
hosting the release artifacts. The bill for lilypond.org is dominated
by egress bandwidth (which is surprisingly expensive).
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
On Sat, Jun 20, 2020 at 11:00 AM Jonas Hahnfeld wrote:
>
> Am Samstag, den 20.06.2020, 10:52 +0200 schrieb Han-Wen Nienhuys:
> > On Sat, Jun 20, 2020 at 1:30 AM Owen Lamb wrote:
> > > Hi all,
> > >
> > > I need to be able to expose the contents of
or guile 2.x, so you'd
have to check if it works at all with GUILE 1.8. The dynamic nature of
JSON may be a better fit to GUILE, but I think we'll be accessing the
data from C++ mainly, so it's probably better to pick a C(++) library.
> Thanks,
> Owen
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
hnfeld:
> > Am Freitag, den 19.06.2020, 15:11 +0200 schrieb Jonas Hahnfeld:
> > > Am Freitag, den 19.06.2020, 14:49 +0200 schrieb Han-Wen Nienhuys:
> > > > [hanwen@t460-wlan lilypond]$ qpdf --qdf --object-streams=disable
> > > > broken2.pdf /dev/std
On Fri, Jun 19, 2020 at 3:13 PM David Kastrup wrote:
>
> Han-Wen Nienhuys writes:
>
> > On Fri, Jun 19, 2020 at 12:50 PM Jonas Hahnfeld wrote:
> >> No changes for me. Please also keep in mind that the same command
> >> string works via the API interpreter.
On Fri, Jun 19, 2020 at 2:49 PM Han-Wen Nienhuys wrote:
> This does present a quandary, because we'd either have to find
> configuration that causes the problem to go away, or we have to modify
> the string we're executing if we're not using the API.
>
> But the latter und
df /dev/stdout | grep Contents
This does present a quandary, because we'd either have to find
configuration that causes the problem to go away, or we have to modify
the string we're executing if we're not using the API.
But the latter undoes the benefit of unifying the API and CLI.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
On Fri, Jun 19, 2020 at 1:01 PM Han-Wen Nienhuys wrote:
>
> It looks like this was discussed here:
>
> https://github.com/CTeX-org/forum/issues/29
>
> (it's in Chinese, but google translate does a good job on the text.)
>
> According to the report, it's a bug in xdvi
On Fri, Jun 19, 2020 at 12:50 PM Jonas Hahnfeld wrote:
>
> Am Freitag, den 19.06.2020, 12:18 +0200 schrieb Han-Wen Nienhuys:
> > On Fri, Jun 19, 2020 at 12:11 PM David Kastrup wrote:
> > > Jonas Hahnfeld via Discussions on LilyPond development
> > > writes:
e static linking as much as possible.
>
>
> Werner
>
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
On Fri, Jun 19, 2020 at 12:11 PM David Kastrup wrote:
>
> Jonas Hahnfeld via Discussions on LilyPond development
> writes:
>
> > Am Freitag, den 19.06.2020, 11:47 +0200 schrieb Han-Wen Nienhuys:
> >> On Thu, Jun 18, 2020 at 7:45 PM Jonas Hahnfeld wrote:
> >>
gt; > > xdvipdfmx:fatal: typecheck: Invalid object type: -1 7 (line 2161)
> > > >
> > > > Git bisect actually tells me that xdvipdfmx started misbehaving from
> > > > the same commit that caused gs issues:
> > > >
> > > > 017927b4d63c3
d to be done
sequentially, reducing the amount of parallelism.
The comparison is not 1-to-1 though. The current doc build doesn't
build the snippet document in multiple languages, even though there
are translations in german, spanish and french, and until now, I've
been building PDF files in cs too.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
on my runner).
>
> Where do you get that 25% from, with no version of the MR passing
> automated CI testing?
You can run it locally. There is a significant speedup for parallel builds.
Another things to consider (if you build docs locally) if to remove
extractpdfmark. It is extrem
nting.
My proposal is to use -Werror only in CI, so we can keep code free of warnings.
For CI upgrades, we could adapt the flags to switch off individual
warnings that trigger newly after an upgrade (we already do this for
-Wsequence-point, for example.)
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
On Wed, Jun 17, 2020 at 5:26 AM Owen Lamb wrote:
>
> On Tue, Jun 16, 2020 at 12:16 AM Han-Wen Nienhuys wrote:
>>
>> On Tue, Jun 16, 2020 at 9:06 AM Werner LEMBERG wrote:
>>
>> [...] Now we have external
>> > metadata files again – not a single one, but a
is .. not the brightest idea. Maybe
we can just standardize on an embedded table ("ZIP " or something)
that holds a zip file with all files we want access to?
Isn't Smufl a standard proposed by the Dorico folks? We could try to
agree on a mechanism with them?
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
f it doesn't. (Thanks, Werner, for guiding me through that
> business!)
if we're doing JSON anyway, you might want see if you can migrate the
existing Scheme based table to JSON too. The Scheme format is
convenient because we already have a Scheme parser, but JSON is more
fitting to the tas
c-build>
Commit
47b263b1
<https://gitlab.com/lilypond/lilypond/-/commit/47b263b199e56122a3d02e9e6fb47c354c97a99c>
in !84 <https://gitlab.com/lilypond/lilypond/-/merge_requests/84>
Move all doc building logic to Documentation/GN...
Commit Author
Han-Wen Nienhuys <https://gitlab.com/han
On Fri, May 29, 2020 at 7:22 PM Han-Wen Nienhuys wrote:
> > On 5/27/20, Jonas Hahnfeld wrote:
> > > No, "rebase" is currently manual (with "merge when pipeline succeeds"
> > > being automatic). This has been clearly communicated, sorry if you
> &g
we
> now want
> contributions to be turned into merge requests instead of patches. Finally,
> GitLab has documentation targeted at beginners, and there are plenty of
> external tutorials available, too. So, my opinion is to simply drop it.
> What do you think?
>
> Best,
>
> Jean
re
using strings, you can also use magic code (eg. "undef") which is
easier to grep for afterwards.
2) set the smuflcode to "undef" in the fet_beginchar() macro, and
provide a set_smufl_code() macro that allows an override. You only
insert the override in the chars for w
t? At any rate, I plan on
> thinking harder about what to call my commits the first time from now on!
If you are building a multi-commit series, you should get familiar
with rebase -i. This lets you edit commits in the middle of a
sequence.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
gh the process, which was
additionally complicated by David and Valentin doing the same.
Could we increase parallelism on the runners, so they complete more
quickly? If we dial up the build speed, so they take only 10 minutes
instead of 40 minutes, merging will be much less painful. I have
several changes ou
gs, clefs, scripts, etc. You can do this is in follow up changes,
so we don't have to do a big-bang conversion.
beyond making lilypond load glyphs through smufl, this scheme also has
the benefit of rearranging Emmentaler in Smufl layout, so it can be
used in other places.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
merge_requests/84
It currently gets 313% CPU time on my 4 core system. I'd be curious to
hear how it scales for higher core counts. It parallelizes the all of
the documents across all languages, so it should scale up to about 55
threads.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
thanks, I'll take this as an OK to drop grammar from the manual.
On Sun, May 24, 2020 at 12:19 AM David Kastrup wrote:
>
> David Kastrup writes:
>
> > Han-Wen Nienhuys writes:
> >
> >> We have a dump of the bison grammar in the contributor guide (see
>
We have a dump of the bison grammar in the contributor guide (see
http://lilypond.org/doc/v2.19/Documentation/contributor/lilypond-grammar).
Is there any value in keeping this? It complicates the generation, as
it is a cross-directory dependency.
--
Han-Wen Nienhuys - hanw...@gmail.com - http
Are the scorio folks on this list?
Is scorio still being worked on? Does anyone know how it makes
stencils appear on their web interface? I am looking into cleaning up
how we generate PS and SVG files, and I don't want to make their lives
harder than necessary.
--
Han-Wen Nienhuys - hanw
On Thu, May 21, 2020 at 1:17 PM James wrote:
>
>
> On 21/05/2020 12:02, Han-Wen Nienhuys wrote:
> > so a next step might be making the countdown process more
> > continuous.
>
> What does that mean - even conceptually?
My idea is that patches could enter 'countdow
nitial setup I can
> start writing documentation.
Let's try it.
I think the FF requirement might lead to traffic jams on countdown
days, so a next step might be making the countdown process more
continuous. But we don't have to address that problem right now.
> Jonas
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
scussions leading to a certain outcome.
So, how about we add the MR URL to the commit message? That provides
an easy pointer to the discussion if that is needed afterwards.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
t; such a thing automatically in GitLab, I think we should do it by
> policy. As you say, it's very hard to track merge requests without a
> tie to the issue tracker.
what does "track" mean in this context?
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
101 - 200 of 3768 matches
Mail list logo
