Dan Eble writes:
> On Mar 29, 2020, at 11:54, David Kastrup wrote:
>>
>> Anybody can think of a holdup?
>
> convert-ly is broken:
>
> find . -name '*.ly' -print0 | xargs -0 convert-ly -d -e -l WARN
> Traceback (most recent call last):
> File &q
Dan Eble writes:
> On Mar 29, 2020, at 14:46, David Kastrup wrote:
>>
>> Dan Eble writes:
>>
>>> On Mar 29, 2020, at 11:54, David Kastrup wrote:
>>>>
>>>> Anybody can think of a holdup?
>>>
>>> convert-ly is broken:
Simon Albrecht writes:
> Let's be honest, they really had to get their stuff together to keep
> any ground all against Dorico.
I think they may still have the higher ground. But Dorico is moving
much faster.
LilyPond is like Switzerland. High ground, but nobody goes there.
--
Da
commit f5f907599ce88d3d610483fa42fa78be12f53d2e (origin/staging, origin/master,
origin/HEAD, test-staging)
Author: Valentin Villenave
Date: Thu Apr 2 11:53:37 2020 +0200
Web: update CG instructions, `attic’ page and THANKS for 2.18
I'll start mine now to get another data point.
--
David Kastrup
David Kastrup writes:
> pkx166h writes:
>
>> Hello,
>>
>> I cannot run a make check from current master.
>>
>> --snip..
>>
>> no source for input/regression/midi/out-test/sequence-name-scoping-1.midi
>> no source for input/regression/midi/
David Kastrup writes:
> David Kastrup writes:
>
>> pkx166h writes:
>>
>>> Hello,
>>>
>>> I cannot run a make check from current master.
>>>
>>> --snip..
>>>
>>> no source for input/regression/midi/out-test/seque
Valentin Villenave writes:
> On 4/3/20, David Kastrup wrote:
>> Anybody have an idea whose Patchy pushed the following:
>> commit f5f907599ce88d3d610483fa42fa78be12f53d2e
>
> Uh, I did push it onto staging after the usual review process. Could
> that really be what b
David Kastrup writes:
> Valentin Villenave writes:
>
>> On 4/3/20, David Kastrup wrote:
>>> Anybody have an idea whose Patchy pushed the following:
>>> commit f5f907599ce88d3d610483fa42fa78be12f53d2e
>>
>> Uh, I did push it onto staging after the usua
special chars
> once in a while in case it allows to verify that it doesn’t trigger
> any weird behavior?)
I think the names of committers will sometimes make sure of that.
--
David Kastrup
do
git reset --hard HEAD~1
to remove the commit. It's also likely that some setting of
export LANG=en_US.UTF-8
or similar might work, but that's not a given. The particular
invocation that should do the trick is system dependent.
--
David Kastrup
pattern *-midi.ly which applies here. So perhaps
changing the name of that snippet in the LSR would be a good idea. Just
swapping "layout" and "midi" in the name would be sufficient, but maybe
a somewhat more concise name would be possible?
--
David Kastrup
Valentin Villenave writes:
> On 4/5/20, David Kastrup wrote:
>> So perhaps changing the name of that snippet
>> in the LSR would be a good idea.
>
> Hi, I just changed it to
> customized-drum-notation-in-printed-and-MIDI-output.ly (and I reworded
> the doc string
e
was planning to do tomorrow afternoon), but he'll likely run into this
road block tomorrow.
Pity.
--
David Kastrup
Valentin Villenave writes:
> On 4/5/20, David Kastrup wrote:
>> Valentin Villenave writes:
>>> It should be available in the next LSR database dump (but there’s at
>>> least one file in the Japanese version that depends on it, so the name
>>> w
llow suggestions for how to upgrade distributions. There is also
the more explicit
sudo update-manager -d
but it tends to offer updates to the newest release (possibly
prerelease) rather than the latest stable.
--
David Kastrup
p issue to fix the problem,
or just revert the problematic commit for now. I lean towards the
latter, to be honest.
--
David Kastrup
1 (one)
> translator. According to the description, Timing_translator is an
> engraver despite the name.
No, it's also used in \midi .
--
David Kastrup
Jonas Hahnfeld writes:
> Hi David,
>
> I think these have gone via translation to master, so safe to delete?
I think so.
--
David Kastrup
Han-Wen Nienhuys writes:
> On Thu, Apr 9, 2020 at 9:36 AM wrote:
>> Waiting:
>>
>> 5874 Remove all uses of markup macro from scm/*.scm - David Kastrup
>> https://sourceforge.net/p/testlilyissues/issues/5874
>> http://codereview.appspot.com/575930043
>
able prerelease phase, this will hopefully
settle comparatively fast into something more amenable.
--
David Kastrup
ivil liability, but I am not sure about the criminal
one.
--
David Kastrup
ing (partially) unwritten code based on an incomplete
understanding in a handwaving discussion.
It is more efficient to discuss objections of the "you haven't thought
this through" kind on working code.
Nothing in this patch here enforces picking a particular route. It is
just paving
riting any of it in-place.
I'll readily agree that there is a disconcerting large set of other
apparently semi-dead branches by living people, most of them likely
unaware of what they left lying there. There may be some point in going
through and mailing them about what they think best to do here.
--
David Kastrup
Han-Wen Nienhuys writes:
> On Fri, Apr 10, 2020 at 1:07 PM David Kastrup wrote:
>> > * memory use: each SCM value takes 8 bytes, and there are 416 grob
>> > properties today, for a total of 3328 bytes. Morgenlied is single page
>> > of music and has 3704 grobs. So
no
qualms mixing up print forms to be read back into Python and actual uses
of strings in a manner that luckily happens to work in Python2" kind of
diagnosis, though it's completely out of my region of expertise. Could
be that the designers of Python rather than its users deserve part of
the blame here. No idea.
--
David Kastrup
David Kastrup writes:
> Han-Wen Nienhuys writes:
>
>> On Tue, Feb 11, 2020 at 10:17 PM David Kastrup wrote:
>>
>>> > the reason being that it is better if the source code looks like plain
>>> C++,
>>> > even though they might actually be
here is what more or less came out as the
best-liked alternative with least impact on code readability serving
this purpose. So a different resolution requires a different proposal,
and general agreement that this is also an acceptable way of writing
things.
--
David Kastrup
ccess of such experiments before they are done, but there is
no point in blocking them either.
--
David Kastrup
My replies have a tendency to cause friction. To help mitigating
damage, feel free to forward problematic posts to me adding a subject
like "timeout 1d" (for a suggested timeout of 1 day) or "offensive".
Carl Sorensen writes:
> On 4/13/20, 6:17 AM, "lilypond-devel on behalf of David Kastrup"
> d...@gnu.org> wrote:
>
> It looks to me like we have only two people who have weighed in on the patch:
> the author (David K.) and one reviewer (Han-Wen). Since we have
y a
> macro for performance reasons.
That is a red herring since nobody complains about macro calls looking
like function calls: they always do. The problem for understanding is
that this macro call looks like a member function call.
> For thinking about the readability of the source code at the caller
> side, it is better that it remains as a method.
But it isn't a method. It is a macro.
--
David Kastrup
into
> stable.
Without editing. We aren't going to pick large-scale code passages from
master into stable, and frankly, the ability to cherry-pick into stable
has not exactly governed development in master recently a whole lot.
--
David Kastrup
Jonas Hahnfeld writes:
> Am Samstag, den 11.04.2020, 15:33 +0200 schrieb David Kastrup:
>> Jonas Hahnfeld writes:
>>
>> > Hi all,
>> >
>> > following removal of dev/translation-* branches, I took a closer look
>> > at stale branches. I think
> 3: https://lists.gnu.org/archive/html/lilypond-devel/2020-02/msg00249.html
> 4: https://lists.gnu.org/archive/html/lilypond-devel/2020-02/msg01114.html
> 5: https://lists.gnu.org/archive/html/lilypond-devel/2020-02/msg01134.html
> 6: https://libreplanet.org/wiki/Fsf_2019_forge_evaluation
> 7: https://communityblog.fedoraproject.org/making-a-git-forge-decision/
>
--
David Kastrup
to downgrade Gitlab's
evaluation because Gitlab is not overly interested in addressing a
number of issues for people bothered above average about software
freedom aspects.
It still seems that at the current point of time our attempt at
balancing priorities would lean towards using Gitlab as a hosted
instance.
--
David Kastrup
spot.com/557640051/
Breaks my patchy again. Whose patchy was comfortable moving it from
staging to master?
--
David Kastrup
> File
> "/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py",
> line 266, in runner
> raise FailedCommand ("Failed runner: %s\nSee the log file %s" % (command,
> this_logfilename))
> FailedCommand: Failed runner: nice make test -j9 CPU_COUNT=9
> See the log file log-staging-nice-make-test--j9-CPU_COUNT=9.txt
That's again font-name-add-files.ly .
--
David Kastrup
Jonas Hahnfeld writes:
> Am Sonntag, den 19.04.2020, 18:59 +0200 schrieb David Kastrup:
>> pat...@gnu.org
>> writes:
>>
>> > 16:36:18 (UTC) Begin LilyPond compile, previous commit at
>> > 12bf65758f33510e6b8e6e4d4a91bb1ebb459248
>> > 16:
Jonas Hahnfeld writes:
> Am Sonntag, den 19.04.2020, 19:07 +0200 schrieb David Kastrup:
>> Jonas Hahnfeld <
>> hah...@hahnjo.de
>> > writes:
>>
>> > Am Sonntag, den 19.04.2020, 18:59 +0200 schrieb David Kastrup:
>> > > pat...@gnu.org
>>
Valentin Villenave writes:
> On 4/19/20, David Kastrup wrote:
>> Note that the delete-file instructions are executed while the book is
>> being read in while markup is typeset when the books are being processed
>> at the end of the input file.
>
> Yes, it looked compl
Valentin Villenave writes:
> On 4/19/20, David Kastrup wrote:
>> ERROR: In procedure mkstemp!:
>> string is read-only: "kaka-XX"
>
> Could the following help?
>
> diff --git a/input/regression/font-name-add-files.ly
> b/input/regression/font-name-add
David Kastrup writes:
> Valentin Villenave writes:
>
>> On 4/19/20, David Kastrup wrote:
>>> Note that the delete-file instructions are executed while the book is
>>> being read in while markup is typeset when the books are being processed
>>> at the end
David Kastrup writes:
> David Kastrup writes:
>
>> Valentin Villenave writes:
>>
>>> On 4/19/20, David Kastrup wrote:
>>>> Note that the delete-file instructions are executed while the book is
>>>> being read in while markup is typeset when t
David Kastrup writes:
> David Kastrup writes:
>
>> David Kastrup writes:
>>
>>> Valentin Villenave writes:
>>>
>>>> On 4/19/20, David Kastrup wrote:
>>>>> Note that the delete-file instructions are executed while the book is
Valentin Villenave writes:
> On 4/19/20, David Kastrup wrote:
>> You need (mkstemp! (string-copy "...
>> because mkstemp! overrides the string.
>
> Why, yes. What I want to copy is precisely the mkstemp-generated
> string. What did I miss?
mkstemp! does not generat
Valentin Villenave writes:
> On 4/19/20, David Kastrup wrote:
>> mkstemp! does not generate a string. It overwrites an existing string
>> in-place, and that's bad news for a literal string.
>
> Yes, it overwrite the string,
You can/must not override a literal string.
Jonas Hahnfeld writes:
> Am Sonntag, den 19.04.2020, 20:03 +0200 schrieb David Kastrup:
>> David Kastrup <
>> d...@gnu.org
>> > writes:
>>
>> > David Kastrup <
>> > d...@gnu.org
>> > > writes:
>> >
>> > > D
pkx1...@posteo.net writes:
> Hello,
>
> On 19/04/2020 17:53, David Kastrup wrote:
>> v.villen...@gmail.com writes:
>>
>>> On 2020/04/11 09:44:26, Valentin Villenave wrote:
>>>> What could be the cause?
>>> So, pushed as
>>&g
Jonas Hahnfeld writes:
> Am Sonntag, den 19.04.2020, 22:16 +0200 schrieb David Kastrup:
>> pkx1...@posteo.net
>> writes:
>>
>> > Hello,
>> >
>> > On 19/04/2020 17:53, David Kastrup wrote:
>> > > v.villen...@gmail.com
>> > &
Valentin Villenave writes:
> On 4/19/20, David Kastrup wrote:
>> At that day I was having one patchy run after the other and I did go
>> through the log files to indicate the failed file and the error message.
>
> Yep, and I asked for additional info both on the tracker a
effect known from
Quicksort.
Now that's not at issue with this patch. What I point out here is that
moving from one STL container to another STL container is a standard
programming technique that is _exactly_ why the STL library has
iterators, and C++11 has for loops that can easily iterate through
containers in sequence without even requiring convoluted iterator
declarations. So there is just no point in not doing this in a manner
where it isn't hardcoding one container type throughout.
--
David Kastrup
ugh the
code that is important. Humans are worth consideration as well.
> If you want me to use "auto" instead of
> "vector::const_iterator", can you just point to the line in
> the code and say "could you use auto instead of an iterator here"?
Wouldn't "everywhere" be sort of obvious?
> https://codereview.appspot.com/583750043/
--
David Kastrup
Han-Wen Nienhuys writes:
> On Fri, Apr 24, 2020 at 3:15 PM David Kastrup wrote:
>>
>
>> > If you want me to use "auto" instead of
>> > "vector::const_iterator", can you just point to the line in
>> > the code and say "could you u
ages also depend on
individuals' environments.
--
David Kastrup
days is SCM. And for looking up a token ID from
an SCM symbol, Guile has hashtables, and we also habe Scm_hashtable.
--
David Kastrup
745, apparently.
>From 2013. It's sobering that 2.18 does not yet contain it.
--
David Kastrup
ose is here.
I don't see that it is frequent. You'll find it mostly in scm/midi.scm
and if you use git blame on that, you'll find that this style in this
file significantly precedes the introduction of define-session.
You'd have to ask Han-Wen and Jan for their respective motivations here.
--
David Kastrup
nd keeping it work would be
robust and dependable (and efficient) enough to make this a really good
idea.
--
David Kastrup
Jonas Hahnfeld writes:
> Am Dienstag, den 05.05.2020, 17:09 +0200 schrieb David Kastrup:
>> I am currently digging back and forth regarding implementation of our
>> Smobs (Scheme objects) and garbage collection and STL, and I think I am
>> converging on the realisation that
Hans Åberg writes:
>> On 5 May 2020, at 17:09, David Kastrup wrote:
>>
>> One reason is that we want to get rid of finalisers particularly in
>> connection with the Boehm GC. Finalisers are called when garbage is
>> collected, the collection of garbage
Dan Eble writes:
> On May 5, 2020, at 11:09, David Kastrup wrote:
>> I'd like to come up with an allocator/container programming model
>> comparatively similar to the STL one so that one could mostly steal the
>> implementations and "just" add the required S
r decision of the tools we use.
>
> Due to lack of other responses, I went ahead and created the repository
> (see above). I'll still wait a few days for others to voice their
> opinions before posting some final questions and proposing the actual
> migration.
I think that
Dan Eble writes:
> On May 5, 2020, at 13:37, David Kastrup wrote:
>>
>> What I have ready-to-use is something that stores like an SCM value but
>> behaves like a Smob pointer with regard to -> and * usage.
>
> Oh. I believe I have some of that too. Excerpt:
>
David Kastrup writes:
> Dan Eble writes:
>
>> On May 5, 2020, at 13:37, David Kastrup wrote:
>>>
>>> What I have ready-to-use is something that stores like an SCM value but
>>> behaves like a Smob pointer with regard to -> and * usage.
>>
>
Han-Wen Nienhuys writes:
> On Tue, May 5, 2020 at 5:49 PM Jonas Hahnfeld wrote:
>>
>> Am Dienstag, den 05.05.2020, 17:09 +0200 schrieb David Kastrup:
>> > I am currently digging back and forth regarding implementation of our
>> > Smobs (Scheme objects) and
David Kastrup writes:
> Han-Wen Nienhuys writes:
>
>> On Tue, May 5, 2020 at 5:49 PM Jonas Hahnfeld wrote:
>>>
>>> Am Dienstag, den 05.05.2020, 17:09 +0200 schrieb David Kastrup:
>>> > I am currently digging back and forth regarding implementati
on your proposed alternative to
>> https://codereview.appspot.com/577720043/ . Or did I miss an update on
>> that topic?
>
> https://sourceforge.net/p/testlilyissues/issues/5895/
> https://codereview.appspot.com/547920045
> ?
Thanks.
--
David Kastrup
My replies have a tend
David Kastrup writes:
> David Kastrup writes:
>
>> Han-Wen Nienhuys writes:
>>
>>> On Tue, May 5, 2020 at 5:49 PM Jonas Hahnfeld wrote:
>>>>
>>>> Am Dienstag, den 05.05.2020, 17:09 +0200 schrieb David Kastrup:
>>>> > I a
ng options are there? I think it makes sense for
the non-developer access to keep referring/pointing to Savannah since I
consider it a resource with more long-term dependable availability.
--
David Kastrup
to have all that before,
it increases the workload for those preparing the migration and they
have to guess.
I totally agree that the CG should reflect the new workflows. But at
the time we do the switch, those new workflows are still in flux.
--
David Kastrup
Jonas Hahnfeld writes:
> Am Samstag, den 09.05.2020, 16:11 -0400 schrieb Dan Eble:
>> On May 9, 2020, at 15:13, David Kastrup wrote:
>> > Carl Sorensen writes:
>> > > ->CS At any rate, I think that we should have appropriate CG
>> > > instruction
repository instead, or am I
misunderstanding anything here?
--
David Kastrup
Han-Wen Nienhuys writes:
> On Sun, May 10, 2020 at 11:37 AM David Kastrup wrote:
>>
>> Han-Wen Nienhuys writes:
>>
>> > Sorry. I'm fine with the migration going through today.
>> >
>> > We'll all be confused for a few days, but given
Han-Wen Nienhuys writes:
> On Sun, May 10, 2020 at 11:37 AM David Kastrup wrote:
>>
>> Han-Wen Nienhuys writes:
>>
>> > Sorry. I'm fine with the migration going through today.
>> >
>> > We'll all be confused for a few days, but given
David Kastrup writes:
> Han-Wen Nienhuys writes:
>
>> On Sun, May 10, 2020 at 11:37 AM David Kastrup wrote:
>>>
>>> Han-Wen Nienhuys writes:
>>>
>>> > Sorry. I'm fine with the migration going through today.
>>> >
>&
Han-Wen Nienhuys writes:
> On Sun, May 10, 2020 at 11:57 AM David Kastrup wrote:
>
>> output-distance: set device properties in batch driver file
>>
>> This fixes the output quality of the regtest results.
>>
>> Previously, the code sets
lear to me just when
.setpdfwrite became unnecessary(?). So I have no idea if just removing
it won't cause trouble with earlier versions of Ghostscript still in use
with LilyPond (not least of all because we may be using them in GUB).
Any ideas?
--
David Kastrup
re being ignored here: we are
right now in the process of using to Gitlab as our development platform
and so the work in picking up patches and entering them in the tracker
is likely to take some days before we settle into new routines. It's
likely that your patches will then be taken up.
--
David Kastrup
to switch to GitLab (or edit your .git/config manually if preferred).
Wouldn't that just be readonly access?
--
David Kastrup
Jonas Hahnfeld writes:
> Am Montag, den 11.05.2020, 11:42 +0200 schrieb David Kastrup:
>> Jonas Hahnfeld writes:
>> > Everything went pretty much as expected, so here's the repo:
>> > https://gitlab.com/lilypond/lilypond
>> > If you already hav
Jonas Hahnfeld writes:
> Am Montag, den 11.05.2020, 11:42 +0200 schrieb David Kastrup:
>> Jonas Hahnfeld writes:
>> > Everything went pretty much as expected, so here's the repo:
>> > https://gitlab.com/lilypond/lilypond
>> > If you already hav
Jonas Hahnfeld writes:
> Am Montag, den 11.05.2020, 12:44 +0200 schrieb David Kastrup:
>> Jonas Hahnfeld writes:
>> > Am Montag, den 11.05.2020, 11:42 +0200 schrieb David Kastrup:
>> > > Jonas Hahnfeld <
>> > > hah...@hahnjo.de
>> > > &
David Kastrup writes:
> Jonas Hahnfeld writes:
>
>> Am Montag, den 11.05.2020, 12:44 +0200 schrieb David Kastrup:
>>> Jonas Hahnfeld writes:
>>> > Am Montag, den 11.05.2020, 11:42 +0200 schrieb David Kastrup:
>>> > > Jonas Hahn
Jonas Hahnfeld writes:
> Am Montag, den 11.05.2020, 14:22 +0200 schrieb David Kastrup:
>> David Kastrup writes:
>> > Jonas Hahnfeld writes:
>> > > Am Montag, den 11.05.2020, 12:44 +0200 schrieb David Kastrup:
>> > > > dak@lola:/usr/local/t
Jonas Hahnfeld writes:
> Am Montag, den 11.05.2020, 14:54 +0200 schrieb David Kastrup:
>> Jonas Hahnfeld writes:
>> > Yes, I think pushing existing reviews as a merge request is the easiest
>> > solution. For the beginning we could of course also live with a mixture
asically asked to do the verification (I know, I know:
I've not exactly been great at keeping our infrastructure workers
recruited and dedicated).
--
David Kastrup
advantage of being "more standard". What do
> you think about this? (To be honest, I'm not even sure if I like
> it. But I do like the prospect of having automated testing.)
At the current point of time, our pipeline does not tend to be all that
full I think. We are not at Linux kernel levels of participation...
--
David Kastrup
Jonas Hahnfeld writes:
> Am Mittwoch, den 13.05.2020, 21:54 +0200 schrieb David Kastrup:
>> Jonas Hahnfeld writes:
>> > Hi all,
>> >
>> > as discussed before the migration, we might want to look into using a
>> > CI system. Foremost this would h
s ahead of master, but rather when staging is ahead of its last
tested version.
That means that even if the migration to master may proceed with the
vote of one Patchy, _every_ instance of Patchy will look at whether it
is satisfied with the current state in a timely manner.
So the diversity of our Patchy setups may not keep something working
only on some platforms from getting into master, but it will still not
stay under the radar indefinitely.
--
David Kastrup
Carl Sorensen writes:
>> On 5/14/20, 8:04 AM, "David Kastrup" wrote:
>>
>> Patchy, however, is set up in a manner where it picks up work not when
>> staging is ahead of master, but rather when staging is ahead of its last
>> tested version.
>>
>
est, such as cvs/master and some of the dev/* branches.)
I think it was just seen as an opportunity for cleanup.
--
David Kastrup
he web server pulls from is not really public.
So giving this have one hop less to work with is reasonable in my book
for the sake of ongoing operations.
--
David Kastrup
x27;t there. We have no timetable for a replacement or its
viability, and so I don't see the point in discouraging contributors
from making fixes to what will continue for an indeterminate time to be
part of the tool set useful for achieving objectives.
--
David Kastrup
ibly caused some regressions (but
there are no hard verifiable statements in this report itself?) but were
kept in. I don't really have a good idea here.
--
David Kastrup
er having an actual issue number for the details for anything of
non-trivial nature.
But there is no point in being discouraged as long as we haven't even
decided on particular workflows: instead one should bring up problems
one sees.
--
David Kastrup
countdown.
>
> It starts here
>
> https://lists.gnu.org/archive/html/lilypond-devel/2020-05/msg00359.html
I think for now it's pushing to staging. Either from the command line,
or because you have set staging as your destination branch in the GUI,
in which case you can use a button (usually starting by rebase).
--
David Kastrup
cbook?) for creating md. While that may sound like
overkill just for the README, the tools would also permit washing things
like the Changes document into the Wiki(?).
--
David Kastrup
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?
Figuring out what discussions and decisions led to a certain approach
being implemented. In a colloborative development environment, you
don't want every developer inventing the wheel new while deflating
wheels other developers have installed.
--
David Kastrup
h
conventions for branch/tag naming, there is a lot of potential to
achieve similar functionality to what we once did with git-cl with much
much less code and work since basically all of the transport of
information can be done using the git command line.
--
David Kastrup
; integrating CI which I'm preparing right now.
It is much more direct to manage one's commits/issues on the command
line. We should not lightly forego that possibility.
--
David Kastrup
ue.
> Every problematic commit I've seen as I've worked on verifying issues
> for 2.20, 2.21, and 2.19 has resulted from adding comments after an
> issue is closed. I think we should have a policy asking that we
> implement either 1 or 2 above.
New issue + crossreference would be my suggestion.
--
David Kastrup
501 - 600 of 6220 matches
Mail list logo
