> We need to be able to resist Google. You may observe in real time how
> ready they are to comply with an authoritarian regime: It has long been
> extremely dangerous how much of a chokehold they have on digital
> ecosystems. Being complacent with “everyone uses Google, so let’s have
> it their wa
it seems to me like YAGNI.
My preference would be to leave things as they are (and update the
documentation), or, if not that, then follow Werner's suggestion. I
have sometimes needed to reprint a time signature even if it wasn't
different.
Kevin
On Sun, 2 Apr 2023 at 19:31, Jean Abou Samra wrote:
> I can do
>
> (define-public grob-interpret-markup ly:grob-interpret-markup)
>
> like we already have for assoc-get aka ly:assoc-get, but it seems
> clumsy.
That is what I would do.
Kevin
o the same rationale applies.
I think it's premature to preemptively object to all potential
solutions. Maybe let's see if Dan has a suggestion.
Kevin
ent/easy to use. I don't think it will add a significant
burden. I'm not particularly knowledgeable about rust, but I'm happy
to help with it.
Kevin
previous stable release:
SGTM; thank you for doing it.
Kevin
etails
> of the transition are discussed, including how sure we are
> that it works. For example, to switch to Guile 2.2, there was
> a dual release and we removed Guile 1.8 support once it had
> seen some use without major problems.
Yes I suppose you're right. We can always save this conversation for
when it happens.
Kevin
On Thu, Nov 24, 2022 at 12:26:57PM +0100, Jean Abou Samra wrote:
> Le 24/11/2022 à 12:12, Kevin Barry a écrit :
>
> GC is definitely not the kind of thing where "passes the
> regtests" means there is no problem. As we have seen in the
> past, the most infuriating a
omated testing wouldn't have caught them anyway.
Perhaps we could describe some manual tests that get run on new releases
of Guile? (It's probably less work than rewriting LilyPond from scratch
with a different embedded language :D.)
Kevin
>
> There is quite a bit of chat about it on
>
> https://wingolog.org/
>
> Jean
>
cf. texi2html
and texi2any). Either way, since he principally takes care of this part
of the codebase I don't think we should use maintainability as an
objection. This is not a drive-by patch.
And we should care about improvements in typography.
Kevin
orkaround when it's no longer needed
- wait for the patch to be released
My personal preference is for the latter option, but I think either
option is OK. I don't like the idea of a stable release built from an
unreleased version of BDWGC.
Kevin
length of the output
> of convert-ly relative to the input. There is no complex logic
> at all.
Well yes, but for many users it would be replacing something short or
simple with something they are not familiar with.
The merge request you raised to address it looks good (especially
because it only warns for anything more complex than
`(markup->string )`
Kevin
duties
because I wouldn't particularly be in favour of adding that
responsibility to the LSR maintainers (but I won't object either).
Kevin
LSR editors. As Thomas said, it's not mentioned in the
CG. I guess we have to add it?
Kevin
n't really a problem except in someone's
imagination.
Kevin
idn't end up including
that. I'll see about preparing a patch for it.
To summarise what's there: it should be an improvement over ghostscript,
but it's still experimental and doesn't implement all of the features of
the other backends (I can't remember what, if anything, is missing).
Kevin
ion
-dbackend=cairo (which should avoid calling ghostscript) also fails (you
may need libcairo or some such installed on your system for this).
Kevin
We will see how this will work out...
Thank you for doing this. It looks good.
Kevin
; be a team effort, that's not something a single person should or want
> to decide...
I think I already weighed in in support of the idea. I don't know how
else I might contribute, but I would like to help if there is anything I
can do.
Kevin
he Windows crashes on a "normal"
score.
Kevin
I have no issues when I Google it. Did you search for tlasm or t1asm?
Kevin
On Wed 7 Sept 2022, 09:51 Andrew Bernard,
wrote:
> I cant find out what tlasm is. It's a missing dependency for the build.
> Google's indexing of billions of pages produces nothing, unless I am
&
behaviour.
I'm not sure if it should be socialised or not. The previous way of
doing it didn't make any more sense.
Kevin
On Wed, 17 Aug 2022 at 17:14, Kevin Barry wrote:
>
> Thank you that definitely looks related! I have posted a comment there.
>
> On Mon, 15 Aug 2022 at
Thank you that definitely looks related! I have posted a comment there.
On Mon, 15 Aug 2022 at 21:35, Jean Abou Samra wrote:
> Le 15/08/2022 à 18:12, Kevin Barry a écrit :
> > Hi all,
> >
> > I used to have a style file for creating musical examples (typically, for
>
to
exactly replicate the behaviour. The crop option does not preserve the
space between systems so it's no good. Is there another way to get the old
behaviour?
Kevin
> Also technically I cannot "block contributions", nobody in the
> community has the power to do so.
>
This might be true technically, but in practice your objections are usually
enough.
hand at a follow-up MR.
>
I agree with this. We should accept Werner's change.
And, more generally, I think we should err on the side of accepting
contributions.
Kevin
Hi,
The problem is that I am using the version of Lilypond supported by the OS
package manager. I'm running Pop! OS which is basically an Ubuntu
derivative. They JUST today announced their next LTS release (22.04) is
ready.
So, the OS maintained version is currently at 2.20 (to be precise, lilypo
>
>
> There have been problems with the version in the search box
> going out of sync with the current LilyPond version, but I
> think these days we are careful to update it timely. It won't
> help with older versions though.
>
> Jean
>
Alas, more's the pity. Well, now that 22.04 LTS is out, I'll
On Mon, Apr 25, 2022 at 3:49 PM David Kastrup wrote:
>
> We are happy to announce the release of LilyPond 2.23.8. This is termed
> a development release, but these are usually reliable. If you want to
> use the current stable version of LilyPond, we recommend using the
> 2.22.2 version.
>
> In th
still plan to contribute patches.
Kevin
> This use case continues to be supported with
> Cairo. Just convert \postscript to \path, wich
> works both in the current PS backend and with Cairo.
Is this something that can be done automatically with convert-ly? If
not then does it justify a major version bump?
Kevin
t may not be necessary. Will the loss of the ps-command affect
users?
Kevin
> I'd be grateful if someone could merge this one (on a phone, and GitLab seems
> to heavy for it...).
>
> Thanks,
> Jean
Done
it can
revive it from. I wasted a lot of time troubleshooting thanks to that.
Kevin
ilyPond more
or less unhindered (until I checked again recently). If you have a
Linux system there's no reason to use WSL (IMO).
Kevin
>
> Oh well. So much for compiling on WSL.
>
> James
>
>
>
>
> >
> > Thanks for taking the time. I cannot recall what error
: error: file not found: version.itexi
I'm running Ubuntu 20.04 on WSL 2. My normal Linux system doesn't have
the same problem.
Kevin
On Wed, 9 Jun 2021 at 10:49, Kevin Barry wrote:
>
> Hi James,
>
> I'm pretty sure that I managed this, but I may not have gone as
Hi James,
I'm pretty sure that I managed this, but I may not have gone as far as
a full doc build, but I think I managed install-info. I will try to
make time to verify and get back to you.
Kevin
On Wed, 9 Jun 2021 at 07:37, James wrote:
>
> Hello,
>
> Has anyone on this list
Do Debian package LilyPond for aarch64? If they do, their build
scripts are probably available somewhere.
On Thu, 20 May 2021 at 07:26, Jonas Hahnfeld via Discussions on
LilyPond development wrote:
>
> Am Mittwoch, dem 19.05.2021 um 22:54 +0200 schrieb Federico Bruni:
> > On Thu, May 13 2021 at 2
ering system
(ghostscript) with an alternative (e.g. libcairo). That sounds like a
significant change.
I would like to hear what other developers think.
Kevin
On Tue, Apr 27, 2021 at 09:38:58AM +1000, Tim Starling wrote:
> I'm looking for a developer who would like take on a contract
performance so maybe we should give it serious thought.
(But again: if there is agreement that this is not the right course then
I see no reason not to immediately abandon 1.8.)
Kevin
reproduce old reports with the then-current unstable release and close
> issues that are no longer relevant. Let me know if this sounds
> interesting and you'd be prepared to participate.
I would be willing to participate in something like this.
Kevin
build/.././Documentation/GNUmakefile:246:
recipe for target 'out-www/cs/web-big-page.html' failed
Does that point you in the right direction?
Kevin
On Fri, 18 Dec 2020 at 20:27, Federico Bruni wrote:
>
> I've just submitted a MR:
> https://gitlab.com/lilypond/lilypond/-/
e given a nuanced response. Practically
speaking, the vast majority of scores only have bar numbers at the
beginning of a line, so I will simplistically categorise your response
as in favour of keeping LilyPond's current behaviour.
Kevin
ss.
Gould has nothing to say about such bar numbers and I would surprised if
any scores included them.
Kevin
On Sun, Nov 15, 2020 at 11:02:52AM +, Kevin Barry wrote:
> - if you have a preference for one of the four, please indicate which
I will be the first responder and say that, of the options in the pdf, I
think Gould is the most appropriate.
Kevin
> Both cases were discussed. For an orchestra they are not the same pitch, thus
> formally a slur.
You cannot make this assumption. It is exceptional to distinguish D
sharp and E flat since most performed orchestral music is equally
tempered. It is common, for example, for a composer to write D s
ross clef changes should be avoided (I
personally wouldn't even do it in the Liszt example posted), but I
think LilyPond needs to handle it. I think it's quite acceptable to
detect this situation and switch to using a slur (but I haven't looked
at the code).
Kevin
> I concur with the idea that a properly functioning full conversion to
> Python 3 and workable (though not required) Guile 2 constitutes sufficient
> change for the next stable version. No other features are needed.
I agree with this.
Kevin
s an improvement, and making something smaller is less
likely to have a negative impact on older documents than making
something bigger would be.
Kevin
50 stack
frames between where I think the problem starts to where the error
happens. I'll try diving in again and see if I can come up with a better
suggestion than my last one.
Kevin
ere are two columns of them, a glissando that runs
into the accidental that is farther away from the note head will stop
for the accidental and start again afterwards to fill the gap).
She also says the lines should be parallel for parallel glissandos.
Kevin
ions fixed (and maybe I'll learn something from it that
means I won't need help next time). Feel free to reply on or off list.
I'll be very grateful!
Kevin
he fault of the font.
Regarding the attachments: in my opinion the lines in the sharp symbol
in Gonville are too thin and too close together - I have to squint at
it to see the gap properly. And for the clef test I actually don't
perceive any real difference other than the "C" for the time signature
(and again, I prefer the thicker version).
Kevin
rowing the idea out there.)
Kevin
> >
> > I’m not knowledgeable enough to discuss the benefits and downsides of
> > merge commits vs fast-foward rebase, so I’ll leave it to others. But
> > I think you make a valid point in that our current linear
> > mandatory-rebas
On Mon, May 18, 2020 at 11:29:35AM +0100, James Lowe wrote:
> Countdown.py (which is Jonas' great cli tool) it's what you see when I do
> the countdown (that's literally cut/paste).
I haven't seen that script, but the gitlab API exposes pipeline
information. It should be enough to correlate a merg
On Mon, May 18, 2020 at 12:17:53PM +0200, Urs Liska wrote:
> No, at least not at the time I looked.
> What James needs is additionally an icon that states that MR is
> *currently* being tested.
There is an icon for that (it's blue and looks like a half-filled pie
chart) - I just couldn't find a me
request
page for inkscape:
https://gitlab.com/groups/inkscape/-/merge_requests
Is the information you would like to be able to see visible there?
It will only show a pass if all stages pass, as far as I know.
Kevin
On Sun, May 17, 2020 at 10:08:12AM +0200, Urs Liska wrote:
> Do I understand you correctly that README.txt is generated upon
> compiling LilyPond? So where does it end up, I couldn't find a
> README.txt neither in the source repository nor in the installation
> directory. Does it only end up in the
On Fri, May 15, 2020 at 04:25:52PM +0200, Jonas Hahnfeld wrote:
> That the script is doing exactly what I told it to do: The diff between
> the previous and the rebased commit is not empty. Therefore it adds the
> Patch::new label, removing Patch::push.
Shouldn't `diff staging...HEAD` be the same
ay to verify that a certain id has been included
> in the release tag label used in the issue is using Github. Start from this
> URL:
Another handy way to do this is to run git tag --contains .
(For me this is faster than github.)
Kevin
ALLBACK ?)
makes c++ procedures like aligned_on_x_parent available to scheme works
without including the header files in the c++ files that use scm_call_X.
This is just a guess though...
Kevin
1.0 --export-background=white
> --export-type="png" svg.cropped.svg
>
> and then do imagemagick diffs on the result.
>
> On Sat, May 2, 2020 at 10:53 AM Kevin Barry wrote:
> >
> > On Sat, May 02, 2020 at 09:59:18AM +0200, Han-Wen Nienhuys wrote:
> > > No
On Sat, May 02, 2020 at 09:59:18AM +0200, Han-Wen Nienhuys wrote:
> Not necessarily, but the refactoring means I'll likely have to
> overwrite the fix wholesale. Because there is no regtest, it willl
> depend on my diligence anyway to fix this again.
OK, so what should we do? I am happy to take re
On Sat, May 02, 2020 at 01:16:30AM -0700, beauleetien...@gmail.com wrote:
> On 2020/05/02 07:38:58, hanwenn wrote:
> > I don't completely understand, though: if we put the "utf-8-string"
> directly
> > into the SVG output, the SVG browser might make other font choices,
> making the
> > outline pote
On Sat, May 02, 2020 at 12:25:15AM -0700, hanw...@gmail.com wrote:
> please don't submit; I'm rearranging this file completely.
>
> Can you add your regression test + instructions on how to reproduce the
> problem?
I did add a regression test in the first patch set, but it breaks
testing. It seem
Hi Jonas,
> Done (hopefully).
Thank you very much; it looks like it worked!
Kevin
en can someone please arrange that for me? My username is
barrykp.
Kevin
n't mean to circumvent the review process or
anything. If there's a better way to go about this then I'm happy to
follow a process.
Kevin
Patch is attached to this mail as a file if that is more convenient.
Kevin
>From 1c5715ad52139aab936ee7dffb2cdef3d123b369 Mon Sep 17 00:00:00 2001
From: Kevin Barry
Date: Fri, 24 Apr 2020 19:26:26 +0100
Subject: [PATCH v1] Issue 3778: Use bounding box as skylines for markup in svg
backend
As there is no routine for determining skylines for utf-8-string
stencils, they normally fall back to the grob's bounding box, which is
fine. However, when there is a mixture of utf-8-string and other types
of stencil (which have associated skyline functions) in a single grob,
the entire grob gets
e done this
wrong. A revised patch will follow with an added regression test.
Kevin
On Fri, Apr 24, 2020 at 09:18:10PM +0200, Han-Wen Nienhuys wrote:
> Can you add a regression test that shows the problem?
Yes. I'll go read the docs to see how to do that and do one up (but feel
free to point me in the right direction...)
Kevin
As there is no routine for determining skylines for utf-8-string
stencils, they normally fall back to the grob's bounding box, which is
fine. However, when there is a mixture of utf-8-string and other types
of stencil (which have associated skyline functions) in a single grob,
the entire grob gets
't know
if it's frequent or not, but I saw it happen with many discussions
that arose after the recent in-person meet (they died in standoffs).
It seems to be the norm. Is it only a problem now that it is holding
up something you are advocating?
Kevin
On Wed, 25 Mar 2020 at 20:06, David Nalesnik wrote:
>
> I'm getting some spurious characters at
> http://lilypond.org/manuals.html. Screenshot attached.
looks python2 vs python3 related: b'' is how python3 prints byte
strings (which were the default string type in python2, but not in
python3).
>
>
> The direction of this statement is correct, but the magnitude is not. The
> kernel is still provided by the host. Getting a crash report can be
> frustrating when the guest's behavior hinges on /proc features that the
> host OS has configured appropriately for the host, not the guest.
> Co
time now. It has seen some use,
> but not overwhelmingly much, and the reasons for that are pretty much
> the same for newer virtualisation methods.
>
I disagree. The docker image specification could be a simple text file that
is kept in the LilyPond repo, and people can build it if they want. Tests
could build it and use that image for testing, etc, etc.
Kevin
>
g an image is much easier than setting up a
working build environment for LilyPond now. I think it would be a win for
both devs and users.
Kevin
there, but not on someone's
personalised distribution then it would be on that person to figure it
out (or just use the docker container). And developers would have a
single target for testing.
Kevin
>
>
> Would docker give us this 'proverbial canary' or would it turn into
> 'worksforme' when someone tried to build their own version of LP on a
> vanilla base of Linux?
>
Docker would eliminate 'worksforme' type issues yes.
>
"no space left on device"
Is that a full disk or something?
On Sun, Feb 9, 2020, 13:10 wrote:
> Hello,
>
> ..
>
> Making lily/out/metronome-engraver.o < cc
> Making lily/out/warn-scheme.o < cc
> Making lily/out/lexer.o < cc
> Making lily/out/parser.o < cc
> ./out/parser.cc: In function 'int yypa
having a
containerised build environment means it can be as portable as a single
dockerfile (or one for each version of guile, if that is what you were
thinking).
Kevin
P.S. I think I have seen a dockerfile for creating a build environment
for LilyPond somewhere. I wonder whether an official docke
> (CC to Kevin Barry, who mentioned GitLab experience in a separate
> thread. My info here is more based on research than experience, so
> please call out any misunderstandings I have.)
Thank you for the CC. I have read through the messages, and the previous
discussion from 2018.
My
I don't know if lurkers' opinions count, but on the subject of potential
replacements for Savannah/Sourceforge: I am part of a team that administer
both Gerrit and Gitlab in-house deployments. If choosing between them I
would advocate for Gitlab because it includes issue tracking and CI/CD so
perha
On Sat, Jan 25, 2020 at 09:27:07AM +0100, Thomas Morley wrote:
> Am Sa., 25. Jan. 2020 um 08:58 Uhr schrieb Kevin Barry :
> >
> > The minimum length of the stem of the middle note is forcing the beams down.
>
> Not here. It's more the relevant value of
> beamed-extr
The minimum length of the stem of the middle note is forcing the beams down.
On Mon, Jan 20, 2020 at 10:05:23PM +, Carl Sorensen wrote:
>
> Wouldn't it be much more simple to build lilypond as a Docker application?
>
> I don't know anything about building lilypond as a Docker application. If it
> were possible to execute a docker application from the command
our development and leadership.
I am sorry that I was never in a position to help out financially, so
I am happy to hear about your new job. I wish you all the best!
Kevin
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/m
t will make a
> difference.
> Please tell me (privately, I assume) where to direct the support.
> (You
> probably know that I live in Germany.)
>
> Yours sincerely, Simon
>
> ___
> lilypond-user mailing list
lil
I have some unexpected free time and would like to do this. Should I
contact you off list?
Kevin
On Sun, Jul 19, 2015 at 4:31 PM, Graham Percival
wrote:
> Add weight to your opinions by showing that you're not afraid of
> getting your hands dirty.
>
> texi2html is a
ly'
/home/pi/src/lilypond-2.18.2/stepmake/stepmake/toplevel-targets.make:30:
recipe for target 'install' failed
make: *** [install] Error 2
Can anyone shed any light on this? Is it something I can fix?
Kevin
___
lilypond-devel mailing list
lily
For sure the voice context limitations are a pain, and if I knew how, I
would write a function for starting and finishing slurs without the need
for creating a hidden voice, but I don't even know if it is possible. In my
own head, I imagine that LilyPond `thinks' in voices and there isn't much
that
On Tue, Mar 24, 2015 at 2:38 PM, Mark Knoop wrote:
> { \time 2/4 c'4 c'1 c'4 } % 3 bars, 2nd of which is empty
>
> { \time 2/4 c'4 c'2 c'4 } % 2 bars, neither of which is empty
>
At best I would consider these to be non-standard notation. At worst I'd
say it's incorrect. It's possible to write a
3G looks best to me.
K.
On Sun, Mar 1, 2015 at 8:22 PM, Joram wrote:
> Hi Paul,
>
> Am 01.03.2015 um 20:22 schrieb Paul Morris:
> > Joram Berger wrote
> >> all versions have the green background fading in on the top right edge.
> >> I do not like that.
> >
> > Hi Joram, Based on previous feedb
On Sat, Feb 28, 2015 at 11:17 AM, wrote:
> Barry if you make a git formatted patch, I can push it for you.
>
> James
>
I'm still getting used to git, so I hope I've done it right. It should be
attached to this email, assuming that's w
On Fri, Feb 20, 2015 at 5:57 PM, Paul Morris wrote:
> So I look forward to hearing from others on the list!
LGTM
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On Sat, Feb 21, 2015 at 5:45 PM, wrote:
> This issue also says it is blocked by
>
> https://code.google.com/p/lilypond/issues/detail?id=777
>
> But I am not sure if what Barry has done so far is relevant to this.
>
> https://codereview.appspot.com/206770044/
>
I did first try using the ly-python
On Thu, Feb 19, 2015 at 4:46 PM, wrote:
> This is not just replacing tabs with spaces. You also reformat here and
> remove empty lines at the end of the file. So the issue description is
> somewhat misleading. Any other changes?
>
Yes, sorry. I wasn't really sure how detailed to be. Where I f
>
> Can someone point to a well engraved example (Bärenreiter, UE, etc.)
> of a similar ossia staff that shows clef and key signature? My gut
> feeling is that both clef and key signature should be *before* the
> barline, not after.
Not off the top of my head, but Gould says `When the /ossia/ st
lp any way
that might be needed. I don't have any specific goals other than
contributing somehow and maybe learning more about programming along the
way.
Kevin
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
1 - 100 of 126 matches
Mail list logo
