ersions alongside each other, which forced
distributions to choose whether to ship LilyPond or a recent version of
Guile. With 2.2 and later, that dilemma disappeared.
I quickly grepped over the source (grepping for SCM_MAJOR_VERSION), but the
bifurcations look very modest.
--
Han-Wen Nienhuys
On Wed, May 31, 2023 at 3:56 PM David Kastrup wrote:
> Han-Wen Nienhuys writes:
>
> > On Wed, May 31, 2023 at 5:12 AM Carl Sorensen >
> > wrote:
> >
> >> After reading all of this, I believe I should recommend to Jason that he
> >> not have his gso
ognitive overhead,
but it's not prohibitive, and if GSOC wants a permanent home for work that
is not merged, then the fork is the right place.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
nch is that
> there is an array of possible beam slopes generated which Lilypond then
> calculates the least squares regression line. Is there any way to get
> Lilypond to spit out this number? I can't figure out how the number -0.63
> was arrived at.
>
> C
>
> On Sat, May 27, 2023
uild/fix-docsize.sh` is not executed while building the
> website on 'lilypond.org'?
note that the website isn't built on lilypond.org anymore. Rather,
there is a cronjob that downloads an artifact from gitlab, see
https://gitlab.com/hahnjo/lilypond-infrastructure/-/blob/master/website/main.go
-
lot of modern music engravers have taken
inspiration from the LilyPond attitude to engraving. The Dorico blog
posts have been quite explicit about it, and maybe we could ask the
MuseScore folks for comments too.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
sg00094.html
You could only use this tool if you did some serious refactoring of
the Cairo PDF generation.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
On Mon, Feb 13, 2023 at 11:53 AM Jean Abou Samra wrote:
>
> Le lundi 13 février 2023 à 11:07 +0100, Han-Wen Nienhuys a écrit :
>
> Hi there,
>
> Every year, we go over the source code to update the copyright years
> that are found in the source headers. I propose to stop
to survive just fine
without yearly exercise like this. Also, at $dayjob, there are no
instructions to do this, despite open source work being carefully
overseen by lawyers.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
On Tue, Jan 10, 2023 at 11:32 PM Jean Abou Samra wrote:
>
> Le 10/01/2023 à 23:25, Han-Wen Nienhuys a écrit :
> > On Mon, Jan 9, 2023 at 7:45 PM Jonas Hahnfeld wrote:
> >> On Sun, 2023-01-08 at 23:18 +0100, Jean Abou Samra wrote:
> >>> In order to keep
lly possible. I don't know about Poppler, maybe it doesn't
> have any such problems.
we'd have to look. I was surprised at
https://www.linuxfromscratch.org/blfs/view/svn/general/poppler.html ;
the required dependencies are modest.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
put.
* it's also a "specialist" command as writing postscript isn't for the
faint of heart.
However removing the rabbit-hole doesn't actually help users that have
already used it in their .ly files.
I am arguing that we should do what is in definition 2 (but I usually
don't call this deprecate)
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
On Fri, Jan 6, 2023 at 10:19 AM Jonas Hahnfeld wrote:
>
> On Wed, 2023-01-04 at 12:52 +0100, Han-Wen Nienhuys wrote:
> > Regarding versioning: the 1.x to 2.x transition was motivated by
> > radical syntax changes that necessitated converting and 'manually'
> > verifying th
, alpha transparency is not going
> to work.
transparency doesn't work today either in the PS backend, the
stencil-expressions.ly regtest looks different in Cairo and the
classic backend. See commit 103ca4c38061754f612880bcc7c29b4fd5acb8f6.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
144MByte in total (uncompressed).
> Multiply the latter by four...
Do people actually download this a lot? Unfortunately Gitlab doesn't
provide this data
(https://gitlab.com/gitlab-org/gitlab/-/issues/327317). I looked on
lilypond.org as well, but we only have 2 weeks of data and the doc
tarballs there are outdated (there were no downloads.)
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
em + flag) has been usurped by various
more sophisticated mechanisms.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
user manual isn't materially different from
working with a 10mb user manual. Both take a while to download. I also
wonder how people actually use the PDF manual. It's very big to print
out, and compared to the HTML manual, unwieldy to use on screen.
--
Han-Wen Nienhuys - hanw...@gmai
here.
> I ask this because we are at an early point in the
> 2.26 release cycle, which could potentially be ideal
> to get testing for "Cairo by default" if it were
> ready, but it isn't yet.
>
> Best,
> Jean
>
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
F metadata features are missing, IIRC. Also, raw PostScript
only works if you export to PS, but not for PDF/PNG/SVG.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
pet was submitted)
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
ze for Cairo?
I'll have a look this week.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
mant this script
can't be removed (I disagree with him) because it caters for a very
specific type of validation. What are you trying to validate?
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
to test this?
You could add a callback in the System grob (or in a similar grouping
Grob at staff level) that counts the number of bar lines included in
the 'elements property.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
and very exhausting) discussion where to
> add kerning data. I want to hear more opinions whether I should go
> 'route one' (which I prefer) or 'route two' (which Jonas prefers).
>
> Please have a look at MR 1368
>
> https://gitlab.com/lilypond/lilypond/-/merge_requests/1368
>
it would be impossible for day to
day development work.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
; value, prebreak and postbreak), but not if the callback uses
> *prebreak-estimate-start* or *prebreak-estimate-end*. I'll have to
> experiment with caching strategies, but this is the current idea.
OK. I'm curious to see how that turns out. Does every call to
get_property() will have to c
On Thu, Apr 21, 2022 at 12:04 AM Jean Abou Samra wrote:
> I am working on code that pervasively utilizes Guile fluids. They should
> be set in dynamic scopes.
That sounds scary. Care to tell more?
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
nd discover? Is the
former code (which is somewhat verbose) a real barrier to getting
coding/typesetting done?
Over the years, I've become extremely wary of syntactic sugar: it adds
an extra barrier to usage/development because everyone not only has to
learn Scheme, they also have to learn the (lilypond specific) idioms
involved.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
version with a non-digit, eg.
refs/tags/v2.23.6
the leading digit always has me do a double take to check it's not a
number of a hex commit hash.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
se a hack
like -djob-count to split lilypond into N jobs where each one does a
part of the job.
https://www.gnu.org/software/guile/manual/html_node/Compilation.html
suggests that one can call the compiler explicitly.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
execution of their code. I'm not sure what word is used
> in Guile for this
> concept.
For integers, floats and booleans, the CPU native representation
involves some bit operations. Intermediate conversions could be
short-cut if you have full type information, and have a sequence of
those in a row.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
> for one file). Would that address your concern with
> compilation speed?
Thanks a ton for your investigation into this. This is a game changer:
MSDM-reduced
1.8: real 0m14.788s
2.2: real 0m14.648s
les-nereides:
1.8: real 0m1.376s
2.2: real 0m1.224s
Let's kill 1.8 support.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
sn't actually about Guile anyway,
$ git log --since 2022/01/01 | grep ^commit|wc
257 514 12336
$ git log --grep=[Gg]uile --since 2022/01/01 | grep ^commit|wc
7 14 336
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
gt; > "supporting GUILE 1.8" as equivalent, but is that really the case? We
> > can't have GUILE 1.8 for 64-bit windows, but for OSX/Linux, it would
> > be an option with the new release scripts too?
>
> No, Guile 1.8 has mandatory shared libraries for some srfi modules.
> There are tricks you can play to make it work with an otherwise static
> build, but they are really ugly and certainly not something I think
> should be done for production.
ack.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
, but do we know about the GUILE team's plans in
this space? It would suck if they want to move to CPU dependent
bytecode.
> properly solve the setup for "downstreams" that apparently is now a
> requirement, but at least doesn't require additional effort. I wrote
I read over thi
to 'input clusters do not
represent the accompanying text and glyph arrays'
Is there a standard way to specify an invisible glyph to
cairo_show_text_glyphs? I'd rather not have to edit the UTF-8 string
to filter out the invisible chars.
--
Han-Wen Nienhuys - hanw...@gmail.com - http
egress traffic for all the binaries.
A big +1 to all of this.
I don't care about the source archives, as downloading and building
from Git directly has become much more practical over the last years,
but they take up little space, so either way is fine.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
: maybe we could rotate the patch meister between different
volunteers? That would also help with the impartiality: if one is this
week's patch meister, you could simply leave your own MRs alone.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
.
Thanks for your tireless work over the many years! Your persistent
shepherding certainly has helped many contributions land that would
have otherwise languished.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
On Tue, Jan 11, 2022 at 11:35 PM Han-Wen Nienhuys wrote:
> > So please let me know if you have anything that you think would be good
> > to include and that I haven't backported yet. I hope wrote a comment on
> > all MRs that I cherry-picked commits from, and chan
o infrastructure fixes (eg. avoid crashes), and avoid
cherry-picking changes to the formatting engine
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
part
Converting them to breakable items adds 3 grobs per break-point, so it
has a certain cost. Since these items don't participate much in the
formatting process, there is little benefit to compensate for the
cost.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
Fedora 35, with Guile 2.2.7 and libgc 8.0.4)
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
On Sat, Nov 27, 2021 at 11:27 PM Han-Wen Nienhuys wrote:
>
> On Fri, Nov 26, 2021 at 12:54 PM Jonas Hahnfeld wrote:
> > A build without optimizations crashed more or less immediately upon
> > compiling the regression tests. That said, I'm not really interested in
> > d
d (shouldn't be too hard) and try them.
I tried both ideas, and it doesn't help.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
help if you mark X/Y parents in Grob::mark_smob?
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
So we likely
> have to re-think the entire layering of the scm/ directory...
semi related - in order to fix the --safe mode, we'll probably have to
reorganize how things depend on each other anyway (with potential
incompatibilities).
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
C related issue causing
> (very rare) crashes with Guile 2.2
can you say more about this?
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
sizing
scheme? (could we make it so emmentaler 20pt matches with Times New
Roman 20pt?)
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
2.23.5 (running Guile 1.8)". As
> such, the build process seems to be pretty close to working. But by the
> time help2man needs to run, the library path information is lost.
have you tried setting LD_LIBRARY_PATH to the directory containing the
.so for the locally built guile?
--
Han-We
't change the horizontal advance width),
> the risk of unwanted effects like text reflow is quite low IMHO.
my worry would be alignment of accidental clusters. If you tweak
vertical sizes, can you still have accidentals at an octave distance
without colliding?
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
mber any reason.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
d to invest time in
improving it. It's not obvious to me that a principled approach to
MIDI rendering would use a broadcast/acknowledge type architecture
like the typography part does.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
ather avoid
refactoring up the SVG backend if I can
(https://gitlab.com/lilypond/lilypond/-/issues/6172#note_675122487 for
background).
This would be predicated on getting Cairo to compile on CI, in GUB and
in the new compile scripts, obviously.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
ood thing to use (of course one can use that internally, but I’m talking
> > about a Lilypond friendly interface).
>
> Just from comparing those statements: Would it be reasonable (and maybe
> generally useful) to make global_path.find (used in gulp_file_to_string,
> lily-guile.cc) available at scheme level?
see ly:find-file.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
O.html
?
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
alone?
Where does the OTF file say it is using encoding Adobe-Japan1-UCS
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
On Sat, Sep 4, 2021 at 9:12 AM Han-Wen Nienhuys wrote:
> >find ~/.fonts -name "HaranoAjiMincho-*.otf"
>
> I cloned https://github.com/trueroad/HaranoAjiFontsCN
>
> I didn´t reallize you had many repos named HaranoAjiFontsSomething. I
> installed the right ones
-name "HaranoAjiMincho-*.otf"
I cloned https://github.com/trueroad/HaranoAjiFontsCN
I didn´t reallize you had many repos named HaranoAjiFontsSomething. I
installed the right ones, and can reproduce the problem.
I'll have a look now.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
nt-features . ("jp90"))
> { 辻井 逗子 飴玉 } }
> ```
I installed your Harano fonts in ~/.fonts. Fontconfig sees them, but I
still get DroidSans when I compile the snippet. How do I reproduce the
problem?
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
e?
This is normally 1.0, but if you have a book where some scores have a
differently sized staff, they will have a smaller number there.
IIRC, we scale up/down the units so they are expressed in staff space,
so if you do
(ly:output-def-lookup paper 'mm)
you'd get 1mm expressed in staff space
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
umping to PDF and then somehow translate the PDF
back in to lilypond commands. It's not completely impossible, but a
lot of work.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
path command is speaking in staff spaces while the border
> box needs to be drawn within the edges of the page ...
The standard staff size is 20pt, so 5pt to a staffspace, which is 1.757mm
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
On Mon, Aug 30, 2021 at 6:31 PM Jonas Hahnfeld wrote:
>
> Am Montag, dem 30.08.2021 um 10:16 +0200 schrieb Han-Wen Nienhuys:
> > With MR 897, I have been able to run the doc build through
> > Cairo. Results are very encouraging: the build is faster, while the
> > resul
On Tue, Aug 31, 2021 at 7:13 AM Jan Nieuwenhuizen wrote:
>
> Han-Wen Nienhuys writes:
>
> Hi,
>
> > Also: apologies to reviewers for the large Merge-Request.
> > Unfortunately, the backend code was quite convoluted, and I didn't see
> > a way except to just sla
+jan for real now.
Also: apologies to reviewers for the large Merge-Request.
Unfortunately, the backend code was quite convoluted, and I didn't see
a way except to just slash my way through it. refactoring along the
way.
On Mon, Aug 30, 2021 at 10:16 AM Han-Wen Nienhuys wrote:
>
> With
are my questions:
* when could/would we drop the SVG backend?
* when could/would we switch the default PS/PDF/PNG backend to cairo?
* when could/would we drop the PS backend altogether?
Thoughts?
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
fault.
at some point, Ghostscript moved from the GPL to the AGPL license, but
I can't discover the exact version. AFAICT, 9.20 is still available
under GPL though.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
ts at running
messaging platforms. Should we really spend precious developer time on
running a message board? I know I won't.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
ot occur.
> Other files also work fine under both architectures.
> Unfortunately I do not have time to cook a minimal failing example.
>
> The following observations are tied to the mingw installer.
>
> A small nit: SVG files are the only ones having no additional 'cairo'
> file ex
On Sun, Jun 27, 2021 at 8:11 PM Knut Petersen wrote:
>
> Is the char stencil really an unused artifact that might be removed
looks like it.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
ink it would be better to insert the Cairo data
(Cairo::Context etc.) into Paper_outputter itself. Then, you can
intercept the Stencils directly in Paper_outputter::output_scheme.
Once that works, we can figure out something with inheritance to
factor out the cairo-specific code.
Hope this helps,
Han-Wen
>
> Jonas
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
On Mon, Apr 12, 2021 at 9:36 AM Jonas Hahnfeld wrote:
>
> Am Montag, dem 12.04.2021 um 09:28 +0200 schrieb Han-Wen Nienhuys:
> > Not being able to use 64-bit addressing on Windows with GUILE 1.8 is
> > an extremely serious problem. What is the reason for this? Is it
> >
On Sun, Apr 11, 2021 at 7:55 PM Werner LEMBERG wrote:
> > Guile 2.2 also makes binary distribution much nicer (because there
> > no more shared srfi libraries, so lilypond can be linked as one
> > static executable) and makes it possible to offer 64 bit executables
> > for Windows.
>
> ...
On Sun, Apr 11, 2021 at 4:24 PM Jonas Hahnfeld wrote:
>
> Am Sonntag, dem 11.04.2021 um 16:04 +0200 schrieb Han-Wen Nienhuys:
> > On Sun, Apr 11, 2021 at 3:42 PM Jonas Hahnfeld via Discussions on
> > LilyPond development wrote:
> > >
> > > All numbers a
o byte-compile the files during the build? Could we
run lilypond during the compile and collect the .go files? Are they
architecture independent (could we still cross-compile to windows?)
Sorry for the long and densely packed message, and thanks for reading
> to the end!
>
no worries, thanks for taking the effort to sort this out!
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
; done | grep -i doc
to look for documentation, but couldn't find it. The module has one
exported symbol, which is compile-bytecode.
Could you give some practical tips on how we'd use this?
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
pilation is
extremely slow, and it is hard to manage (where should the .go files
be stored/installed, how/when are they generated etc.). It also
doesn't match our use case, because a lot of the code that we have
comes from .ly files, so it cannot be precompiled.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
On Fri, Mar 12, 2021 at 12:39 PM Han-Wen Nienhuys wrote:
> > there’s a Guile 3.0.6 release planned that includes a rewrite of the
> > reader in Scheme. It has speed in the same order of magnitude as the
> > previous reader but might have different performance characteris
ial,
making this kind of thing annoying to check.
You say "same order of magnitude". Do you have benchmarks so we know
what to expect?
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
t; more than they used to.
>
> This stands out:
>
> commit d1be5ec60a058e363835bee60ece6fc61a67c5a9
> Author: Han-Wen Nienhuys
> Date: Sun Jan 24 16:50:19 2021 +0100
>
> Introduce 'debug-gc-lifetimes option
>
> The debug-gc-assert-parsed-dead feature has been docu
pond-specific
prefix. Maybe "(lily framework-ps)" ?
Are you trying to create a setup where the byte-compiled files are
preinstalled?
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
t;
> 1: Overlay_string_port relies on scm_c_make_port_with_encoding which
> doesn't exist in Guile 2.0. I haven't looked if there's a replacement,
> but I find it unlikely and think the time would be better spent on a
> working version with Guile 2.2.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
is?
https://github.com/hanwen/guile/commit/3bf5057232c35df155badfee9489081bdbbf4ecb
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
houldn't be public), but it's the current situation and the
> bugfix would require relinking all objects depending on the library.
I can probably trim down the fix to be more backward compatible.
Do you know of documentation that details what is and is not allowed
in an ABI-compatible change?
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
te; it was just
never cleaned up. We did dedicate a release to him (
https://lilypond.org/website/misc/announce-v2.12)
> I believe that at this time, it would be appropriate to remove Rune'
> branch. But I am only one person.
>
I think it's OK too.
--
Han-Wen Nienhuys -
On Sun, Jan 3, 2021 at 12:06 PM Jonas Hahnfeld wrote:
> There were no bug reports for 2.21.82 and no other Critical issue that
> I'm aware of. While there are a few changes that could be backported (I
> tried to label the MRs at GitLab),
What is the label to look for?
--
Han-Wen
g the way with the release!
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
bit compilation.
>
> Is this an objective that is desirable by the rest of the team? Was it
> attempted before?
I think LilyPond already works well on 64-bit architectures. (I'm using it
on a x86_64 laptop currently). What makes you think it needs more work?
--
Han-Wen Nienhuys -
merge_requests/582
> >
> https://lilypond.gitlab.io/-/lilypond/-/jobs/938180873/artifacts/test-results/index.html
>
> Hm... there are no *.signature files for that case.
>
Looks like the known issue that \book (used for testing page breaking)
doesn't generate .signature files.
ile path. It must be
> considered that different values will prevent reuse of the GS API
> instance, but I'd argue that a constant value should be fine in this
> case.
>
the man for DocumentUUID says
Note that Ghostscript has no assess to the host node ID due to a
minimization of platform d
n't and this wasn't me. Does anybody have plans to use Travis?
>
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
be happy to assert in some way that stencil representations coming from
> Scheme are not altered, but I can't think of a good way to do this...
>
We'd have to make unsmob return a Stencil const *. Maybe that is
appropriate for more simple smobs?
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
ly and skyline-point-extent.ly (in that order!) with an
> added '\include "lilypond-book-preamble.ly"' (attached). If I run
> $ ./out/bin/lilypond footnote-volta-spanner.ly skyline-point-extent.ly
> the skyline-point-extent.pdf has some added whitespace that vanishes
> when passing -djob
it would make sense to enable this
> first implementation in lilypond/lilypond. What do you think?
>
yes, +1 . I am especially happy that this will likely have no extra
overhead.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
't know how we can contribute until we are made aware of the
> challenges here.
>
> Carl
>
>
> On 10/15/20, 4:14 PM, "lilypond-devel on behalf of Daniel Benjamin Miller"
> behalf of dbmil...@dbmiller.org> wrote:
>
> Not of direct relevance to us as end users, but can someone shed light
> on this and/or resolve the concern of the Wikimedia people? In the
> meantime Lilypond support has been disabled on Wikipedia.
> https://phabricator.wikimedia.org/T257066
>
>
>
>
>
>
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
>
I don't have plans for large scale changes (or any changes, actually) in
the coming 1-2 months: I have been pretty busy at work last month, and I am
moving apartments next week.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
On Wed, Sep 30, 2020 at 10:11 PM Han-Wen Nienhuys wrote:
>
>
> On Wed, Sep 30, 2020 at 8:05 PM Werner LEMBERG wrote:
>
>>
>> [git 9c3803fba4960b4afa63baeb50201a0cfa48f8f1]
>>
>> I've just built the whole documentation, and I get a strange string
>> repl
changes the state of lilypond while lilypond-book now processes more
> files in one run?
>
Yes, very likely. See commit 9f16e2962ac71e6a30526012e314d55cec6b7e01.
For some reason the check for replacement_cache_alist_key_ is not
working as intended.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
either tool but I'm against switching back and
> forth multiple times, that'll just cause churn in the code.
>
IIRC I think the option used was -aa (2x -a = aggressive.)
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
1 - 100 of 3768 matches
Mail list logo
