This should be fixed, until early 2026.
On Fri, Jan 3, 2025 at 3:00 PM Han-Wen Nienhuys wrote:
>
> heads up - I suspect that the website update is currently broken due to an
> expired token. Hopefully I'll get to it this weekend.
--
Han-Wen Nienhuys - hanw...@gmail.com - http:/
image: GitLab]
Hi Han-Wen Nienhuys!
One or more of your personal access tokens will expire in 7 days or less:
- hanwen-read-2025
- lilypond.org-read-token
You can create a new one or check them in your personal access tokens
<https://gitlab.com/-/user_settings/personal_access_tokens&g
On Tue, Oct 1, 2024 at 5:26 PM Luca Fascione wrote:
>
> So this is completely mysterious.
> I wrote my own postscript EPR runner, and that one works just fine (see
> below)
FYI Lilypond has its own runners as well, have a look at
output-distance.py, eps_to_png() for inspiration.
, can I use Cairo in pdf
> mode?
You can use Cairo if you add
LOCAL_LILYPOND_FLAGS=-dbackend=cairo
local.make, and apply the following
commit e48daf754a323eca0c5b15f8677d4c9574c98ad4 (HEAD -> top)
Author: Han-Wen Nienhuys
Date: Sun Sep 29 10:56:46 2024 +0200
pdf
diff --git a/mak
gt;
> Which I also tried on cmdline with the same result.
>
> I see on this page
>
> https://lilypond.org/doc/v2.25/Documentation/contributor/requirements-for-running-lilypond
>
> that minimum GS is 9.03, though.
>
> Any clues?
> Cheers
> Luca
>
> --
> Luca Fascione
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
27;deb-src' URIs in your sources.list
>
> Does anyone have a quick breadcrumb or two to share with me about how to
> resolve this please?
There are dockerfiles under docker/ in the source tree.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
bjects (slurs, beams) have different sizes.
>
> BTW, I got an interesting reply on StackExchange; maybe you two (Luca
> and Han-Wen) want to comment on it.
>
>
> https://computergraphics.stackexchange.com/questions/14143/search-for-special-image-difference-metric/14145
AFAICT, this just d
On Mon, Jul 29, 2024 at 12:10 PM Luca Fascione wrote:
> I was actually thinking about this situation upside-down from how you're
> seeing it,
> details below
>
> On Mon, Jul 29, 2024 at 10:30 AM Han-Wen Nienhuys wrote:
>>
>> On Mon, Jul 29, 2024 at 8:56 AM Luca F
t be tested by a Cairo log/replay.
* Even if Cairo were the production code, then the log/replay is extra
code that is not used normally. How would you be sure it is free of
bugs?
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
nt locations, and sometimes variable objects (slurs,
beams) have different sizes.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
that exercises
the same feature where a symbol went missing (was it a Tablature
test?). If the test image has just a few symbols, a missing symbol
will be a comparatively larger change, and will stand out in the
current regression testing framework. It also provides a more granular
test for debugging purposes.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
27;ve posted a question on StackExchange, searching for a better
> regtest comparison algorithm
>
>
> https://computergraphics.stackexchange.com/questions/14143/search-for-special-image-difference-metric
>
>
> Werner
>
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
multiple versions 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
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
more cognitive 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
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
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/web
n
context for 2023. To note, a 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
/2023-01/msg00094.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
em 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 support
on during the build
> is not really 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
c.).
* it doesn't work with SVG output.
* 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'
> > ve
, 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
h
> has a size of 170MByte) need 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
ehead + stem + 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 - ha
e invasive than what we are discussing 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
what, if anything, is missing).
Some PDF 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
dered
> legacy and moved to a snippet. I am pretty sure this violates
> the GPL. 300 lines looks too much for fair use law to apply,
> doesn't it?
Why not ask Jan who wrote the chords snippet if is he OK to relicense
the snippet as public domain? (or, maybe he already did this when the
On Mon, Aug 8, 2022 at 11:06 PM Jean Abou Samra wrote:
> Also, speaking to Han-Wen, if we are to have a build system freeze
> around August 20, Cairo support for the official 2.24 binaries is
> now or never. Unless we consider there are very good reasons for
> bypassing the free
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
ve an intense (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/
like: O(1 hour)), so it would be impossible for day to
day development work.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
with two cached
> 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
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
> }
It's shorter, but is it easier to understand and 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
we prefix the
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
we could use 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
; because that
> cost can dominate the 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
r instant
> 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
rk we do isn'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; > * In the discussion, we've been treating "keeping GUB alive" and
> > "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
for
> x86_64-pc-linux-gnu, x86_64-w64-mingw32, powerpc64le-pc-linux-gnu).
I'm glad to hear that, 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
g to go out of sync, leading 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 N
g this for the source archives. For the
> binaries however, that are mostly downloaded by humans and not scripts,
> I think GitLab is equally good or bad (both are running on GCP), we can
> still directly link to the files, and I guess Han-Wen won't be too sad
> that he doesn't h
s.
One thought: 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
nding.
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 changed th
quisite to pick first.
I'd stick to 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
em on 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
> &
end (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
ing in System::derived_mark...)
IIRC, the whole business with grob-array skipping marking was an
attempt at cutting a corner for performance and/or limiting stack
depth when doing GC marking. It may very well not be relevant today,
especially for BGC, which has an explicitly allocated mark stack.
les. 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
l a GC 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
(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
e markup is
> handled by Pango, and we won'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
h's outline? A small
I can't remember any reason.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
fault because we never bothered 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
ings, and I'd rather 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
ride #'(font-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
-space?
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
pt, dumping 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
e the \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 jus
+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:
>
>
uild GS), and simplify our licensing story (no more potential AGPL
dependency).
Here 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
in the past
> year, so he might not want to take that blame. Before I buy
> a domain, how about lilypond.org? That would make it more
> of an official community space and more discoverable for
> newcomers.
>
> Han-Wen (administrator of lilypond.org if I understand
> correctly),
On Thu, Jul 29, 2021 at 11:32 AM Michael Käppler wrote:
> Hi Knut,
> thank you very much for your work!
>
> Am 29.07.2021 um 01:13 schrieb Knut Petersen:
> > Here are installers for lilypond with the cairo backend after a
> > significant remix by Han-Wen. GUB has bee
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
-outputter.cc).
For the prototype, I think 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
> >
es
> > for Windows.
>
> ... especially to support some 64bit architectures.
>
> > But given the reactions, I'll reduce activity on my work towards
> > Guile 2.2...
>
> Hopefully there is not a misunderstanding: I very much appreciate your
> activities (and I'm quite s
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 are fro
estimate how feasible that
> is and how long it would take)
>
How hard is it really to 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
; do git show $c ; 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
he: the separate byte compilation 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
> 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 bee
his split goes back to the very first
> module added in commit
>
> https://gitlab.com/lilypond/lilypond/-/commit/e11dc9a89c31b64615bcdcb8b536621ded30176b
> from 2001. I'm adding Han-Wen and Jan, do you happen to remember if
> that was an explicit choice or "just worked"?
&g
ower.
> Cheers
> Jonas
>
>
> 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
;s this?
https://github.com/hanwen/guile/commit/3bf5057232c35df155badfee9489081bdbbf4ecb
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
these
> symbols shouldn'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
as a tribute; 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.
--
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?
--
Ha
g the way with the release!
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
1 - 100 of 4595 matches
Mail list logo
