ion of practicality than philosophy what to
use here, and it could even be something else like EnharmonicTie with
both slur-interface and tie-interface.
Tie endpoints tend to be different from slur endpoints since they
connect noteheads more than note columns (in-chord slurs are not really
a good reference since they currently suck with regard to their
positioning).
--
David Kastrup
le manual. A slur even across the same pitch will be
executed with a separate keypress as opposed to a tie.
I seem to remember that even in Bach's B minor mass (where E12 was not
yet a thing) there is an enharmonic tie (or at least tonal repetition?)
in the transition from "Confiteor" to "Et expecto". I mean, that
transition is a tonal center nightmare anyway.
I'd have to consult my score to pick out the details.
--
David Kastrup
chieve some leverage. I doubt that they
would be terribly upset if they were challenged on that position and
lost in good faith in court as that would create a case of precedence
that would be helpful in other regards. Basically, those with the means
to call their bluff stand to lose more than they do.
In the mean time, I don't think it makes sense to diverge too far from
sanity for making stipulations.
--
David Kastrup
occurs _after_ the general
start-translation-timestep phase. For _explicitly_ instantiated
contexts (like \new Voice ...) I think it is being called.
No guarantees, but that's the way I remember.
--
David Kastrup
language selection; afterwards
all links should stick with the selected language.
Of course the problem with that is that this should not be the case for
an English-language fallback. Strictly speaking, those should not be
the same as the normal English-language pages but rather be per-language
co
nd.
>
> I see the value of faster builds, but I think being correct is more
> important than being fast.
>
> What annoys me is that the default build creates the info docs, which
> aren't necessary for developing lilypond.
This checks, for example, music function comments for correct Texinfo
syntax (even if it does not test embedded LilyPond for validity).
--
David Kastrup
think about this? Having a
> large silent mass is not really helpful for this kind of discussion (as
> it wasn't for the switch to GitLab).
Frankly I don't see the point in repeating points I already made and
call that "discussion".
I don't see that in the current stage of upheaval of both internals and
build system and infrastructure, there is a point in freezing off some
half-baked intermediate state that hasn't seen significant exposure to
extensive testing.
--
David Kastrup
sort of freeze
> 3) Branch off stable/2.22 and cherry-pick only fixes
I think that "some sort of freeze" makes sense only in light of defining
goals to achieve for the next stable release. As long as those goals
still necessitate disruptive/extensive changes, there is not much of a
point in branching.
--
David Kastrup
Christopher Heckman writes:
> On Sun, Aug 30, 2020 at 11:59 AM David Kastrup wrote:
>>
>> Christopher Heckman writes:
>>
>> > How about allowing modifying the syntax of \alternative to include the
>> > possibility of a number, which means to repeat
0"
\version "2.6.0"
\version "2.6.0"
\version "2.6.2"
\version "2.6.3"
\version "2.6.3"
\version "2.6.3" % necessary for upgrading to future LilyPond versions.
\version "2.6.4"
\version "2.6.4"
\version "2.6.4"
and so on. Stuff like that will not likely convert nicely, but at least
having a start seems like common courtesy.
--
David Kastrup
uld be interpretted as: the 1st, 2nd, and 4th endings are c,
> and the 3nd ending is d.
That is already valid syntax and makes the first and second alternative
c1 and the third and fourth alternative d1 .
Extending LilyPond syntax is not really a matter of arbitrarily
inventing something: a lo
al_ number list if we are
reasonably sure that this is all we need.
Usually prettier alternatives can come with a backward compatibility
hook (though their lifetime tends to be semi-eternal). But in this case
the ugliness does not just extend to the input, but also to the input
processing.
--
David Kastrup
Dan Eble writes:
> On Aug 29, 2020, at 14:52, David Kastrup wrote:
>>
>> My own take on it is that \alternative syntax is an abomination and it
>> should likely be more like
>>
>> \repeat volta 40 {
>> ...
>> \alternative { ..
e like
\repeat volta 40 {
...
\alternative { ... }
\alternative { ... }
\alternative { ... }
}
since that would avoid several syntactical problems and would allow to
produce alternatives by music functions.
So if we are going to start phantasizing, that would be an approach I'd
prefer to start out from.
--
David Kastrup
h moderate success.
However, as release stoppers were accumulating and the release process
got stuck up, the "don't do development" appeals stopped making a whole
lot of sense.
> Just trying to understand what might have worked in the past...
I sure wished I had been able to get an understanding about what might
have worked...
--
David Kastrup
release would
be "outdated from the start" with regard to some "must-have" features
that would be expected to be common in suggested code on the mailing
lists.
So 2.20's history in some way reflects how to muddle through in a
situation that became a lot different from planning. It's not really a
template for how things should work.
--
David Kastrup
le moniker. The stable branch tends to
see only rather superficial testing, and a large divergence from master
would make its stability more a matter of wishful thinking than release
engineering.
--
David Kastrup
Jean Abou Samra writes:
> Le 6 août 2020 à 12:21, David Kastrup < d...@gnu.org> a écrit :
>
> Changing
>
> \override NoteHead.id = #note-id
>
> to
>
> \override Score.NoteHead.output-attributes.id = #note-id
>
> only works if note-id
rrect. I may change that eventually, but that's basically a
possibility at the bottom of a stack of rather extensive purportive
changes, so don't hold your breath for it.
--
David Kastrup
ill make them
unusable.
I'm not saying that those two reasons should be enough, just mention
them for consideration. I find the former more useful than the latter,
but then I do use Emacs as Info reader.
--
David Kastrup
orrection, and
the result does not work.
> \override Score.NoteHead.output-attributes.id = #'((id . "foo"))
>
> I get the error:
>
> Unsupported SCM value for format: ((id . foo))
Because you set output-attributes to ((id . ((id . "foo" rather than
to ((i
> I'm not…”.
>
> Hope humor helps things progress,
> Jean
Frankly, never mind the Latin. I get the shakes when many native
English speakers try their hands at Early Modern English, the variant
often used by Shakespeare and also typical for the KJV Bible
translation, and completely mess up things like speaketh, speakest,
thou, thee, thine; basically picking between older forms randomly.
--
David Kastrup
s-tube. One case
where unfortunately someone who does not know history is not bound to
repeat it.
--
David Kastrup
-lilypond.git-release-unstable'
>
> And that's where it stops doing anything.
>
> Anyone any ideas?
Sounds like tar (or some other program?) got nonsensical options and is
now waiting for input from the terminal instead of some program or file.
You can try to see what happe
Han-Wen Nienhuys writes:
> On Wed, Jul 15, 2020 at 10:48 PM David Kastrup wrote:
>
>> Well ok. But only 100 random numbers are being used (there is
>> another call using 1000 instead, the choice appearing random).
>> Let's assume we have 10 processes going
David Kastrup writes:
> Jonas Hahnfeld writes:
>
>> Am Mittwoch, den 15.07.2020, 21:35 +0200 schrieb David Kastrup:
>>> Jonas Hahnfeld writes:
>>> > Am Mittwoch, den 15.07.2020, 17:31 +0100 schrieb Phil Holmes:
>>> > > Here's the logfile a
Jonas Hahnfeld writes:
> Am Mittwoch, den 15.07.2020, 21:35 +0200 schrieb David Kastrup:
>> Jonas Hahnfeld writes:
>> > Am Mittwoch, den 15.07.2020, 17:31 +0100 schrieb Phil Holmes:
>> > > Here's the logfile and the ly file.
>> >
>> > Could
reate-file-exclusive which returns #f if the file already exists
> (or could not be created).
I had commented on the respective issue without response that the
parallel processes, without taking additional measures, will generate
the same "random" sequence, making this no better than ju
Thomas Morley writes:
> Am Mi., 15. Juli 2020 um 00:15 Uhr schrieb David Kastrup :
>>
>> Thomas Morley writes:
>>
>> > Am Di., 14. Juli 2020 um 22:14 Uhr schrieb Thomas Morley
>> > :
>> >>
>> >> Am Di., 14. Juli 2020 um 22:03 Uhr s
way, when not using
merge_request.title, the title is just picked off the headline of the
commit) to the same branch. Since you likely have amended your commit
instead of adding one on top, this will not be a fast forward push, so
you'll need the -f option or use +HEAD:my-proposed-branch-name as
source:target description. It's the same requirement as you'd have
after rebasing.
--
David Kastrup
I think that my original
> idea was to just produce the html, while the person(s) who wanted
> to have all docs available offline where you, Jan, John Mandereau,
> and/or David Kastrup. (It was definitely an emacs user!)
I am frequently using the Info files to look up stuff in the index
an
classes and context () for others. Or
get_parent_context () for some and get_daddy_context () for others.
Generally the get_ prefix seems a bit spurious: given that we use the
naming convention field_ for data members, calling the read accessor
field () seems like it should always be workable.
--
David Kastrup
hed to say that the beginner's mistake would have been
running something with a registry as host system, but then with the
advent of systemd as a Linux system component, the comparison has become
lots murkier. Managing conflicts has become black magic. Linux tends
to work more reliable magic, but either way there is too much happening
behind the scenes.
--
David Kastrup
f in deval (x=0x7f01bed86010, x@entry=0x7f01bed818a0,
> env=0x7f01b13c9130, env@entry=0x7f01b13c92c0) at eval.c:3469
> #16 0x7f01cbb4bba4 in scm_dapply (proc=0x7f01beb47ff0, arg1= out>, args=0x7f01b13c92c0) at eval.c:5012
> #17 0x7f01c1096c1a in scm_srfi1_map (proc=0x7f01b13c9b70,
> arg1=0x7f01b13c9be0, args=) at srfi-1.c:1443
Huh. Maybe the file is renamed before Guile lets go of it? Or it may
be a buffer overflow in Guile's input handling.
--
David Kastrup
of 'Verified' but for newly entered issues.
>
> A LP developer who created an issue with a patch/fix would simply jump
> to 'started'.
>
> This was something else that a 'non-developer' could contribute to the
> LP project so developers could get on with fixing issues.
>
> Regards
>
> James
>
>
>
>
>
--
David Kastrup
; is kind of the extended C++ STL).
Not that I know of.
--
David Kastrup
Han-Wen Nienhuys writes:
> On Fri, Jun 19, 2020 at 3:13 PM David Kastrup wrote:
>>
>> Han-Wen Nienhuys writes:
>>
>> > On Fri, Jun 19, 2020 at 12:50 PM Jonas Hahnfeld wrote:
>> >> No changes for me. Please also keep in mind that the same command
>
ts. Returning it to
the _Scheme_ layer should never be done.
For functions not returning a specific value, return SCM_UNSPECIFIED; is
the right course.
--
David Kastrup
ay where that comes from.
>
> No, this is the only smallest possible EPS file that shows the problem.
> I'm attaching the real file from LilyPond to this message, but the
> important part is probably that it contains no graphical objects.
That triggers some memory: this may not have anything to do with
autorotation? That GhostScript decides on landscape orientation
unexpectedly or so?
--
David Kastrup
i`
> files.
>
> David, would you do that and fast-track this mechanical change?
No idea what makes me the go-to here, but anyway.
<https://gitlab.com/lilypond/lilypond/-/merge_requests/173>
--
David Kastrup
i`
> files.
>
> David, would you do that and fast-track this mechanical change?
We don't use camelcase elsewhere in Texinfo.
@morerefs
maybe?
--
David Kastrup
/?id=aa18f519e091b6ada0fb2b0a65a51880031d5014
Uh oh. This looks like it introduces (modifies?) a command named
@seealso but it would appear that we define our own version of it.
--
David Kastrup
getting fresh warnings _reported_ for changes seems like a
good idea. Making it a no-go to have them, however, seems too
restrictive to me.
--
David Kastrup
from the
> recursive call which the check relies on. Funnily enough, a comment
> says: "If the code could be inlined, that might cause the test to give
> an incorrect answer." - indeed.)
It's easy enough to write a recursive call that cannot be tail-call
optimised. It may be old code, but it was trouble waiting to happen.
--
David Kastrup
ith your GCC 10 problem: I don't remember anything related to that. If
it doesn't, you might want to ask Thien-Thi Nguyen (who has made this
branch tip work so far) to take a look.
--
David Kastrup
quency of build system changes, it seems like
any such change should be done in a manner where it does not require
more than the flip of a switch to change back temporarily.
--
David Kastrup
> so I could submit 7 MRs in one go. This worked satisfactorily for me,
> so I retract my criticism.
It's a manually done technique, and will still lead to competing
pipelines from different users.
--
David Kastrup
, the tool being standard or not.
But I agree that a custom GUI tool is likely not helpful. Not least of
all since it just isn't a useful resource for people who actually
already have their own rapport working with Git, and those are a
significant part of the developer base.
--
David Kastrup
mean that you can usually rebase and forget without waiting
for pipeline completions. And you get the liberty of bypassing most CI
and rebases if you don't want to.
I may be wrong about the possibility to do this with a reasonable amount
of effort: I don't want to get hopes up unnecessarily.
--
David Kastrup
venue (-user list, -devel, bugtracker,
> code reviewing, doc editing or merge requests) and, personally
> speaking, the more we see of you the better. But of course, that’s
> entirely up to you and may vary from time to time depending on your
> free time and motivation; these are, after all, the only two
> ingredients Free Software is made of.
--
David Kastrup
Dan Eble writes:
> On May 27, 2020, at 07:16, David Kastrup wrote:
>>
>> Now that we have the first "please get in line" merge that isn't
>> actually to any degree unusual, I get the suspicion that my previous
>> alternative proposal of pushing to a C
ly manual (with "merge when pipeline succeeds"
> being automatic). This has been clearly communicated, sorry if you
> missed that.
Well, the point of a working mechanism is that nothing needs to get
communicated by side channels. Of course, we aren't there yet since we
are still figuring out our usage patterns for Gitlab.
> Jonas
>
--
David Kastrup
Jonas Hahnfeld writes:
> Am Sonntag, den 24.05.2020, 16:28 +0200 schrieb David Kastrup:
>> Jonas Hahnfeld writes:
>> > Am Sonntag, den 24.05.2020, 13:19 +0100 schrieb James Lowe:
>> > > So, and you didn't answer this specific question, if I set the label to
e submitter to not follow up with
an actual merge.
--
David Kastrup
Jonas Hahnfeld writes:
> Am Sonntag, den 24.05.2020, 10:18 +0200 schrieb Jonas Hahnfeld:
>> Am Sonntag, den 24.05.2020, 00:21 +0200 schrieb David Kastrup:
>> > I think configure options should likely point to Guile-1.8 (for now) and
>> > use --enable-checking and (to s
Han-Wen Nienhuys writes:
> thanks, I'll take this as an OK to drop grammar from the manual.
I am actually unhappier about seeing the mechanism for generating it
disappear rather than the grammar itself. But for LilyPond, it really
does no longer provide a reasonable value.
--
David Kastrup
figure out how to track this. I think our
> runners are prioritized, but this should become clear soon.
I think configure options should likely point to Guile-1.8 (for now) and
use --enable-checking and (to save CI minutes) --enable-gs-api .
Reasonable?
--
David Kastrup
David Kastrup writes:
> Han-Wen Nienhuys writes:
>
>> We have a dump of the bison grammar in the contributor guide (see
>> http://lilypond.org/doc/v2.19/Documentation/contributor/lilypond-grammar).
>>
>> Is there any value in keeping this? It complicates the g
e likely in a capacity of
interpreting the respective traces of Bison.
--
David Kastrup
ower by a
> factor of 2, I'd call that a regression in general.
If it is by the translation team doubling the number of supported
languages... Actually, if translations were all kept up to date, we'd
probably need less time for "make doc" since then most of the
translations would work with the same code examples.
--
David Kastrup
Jonas Hahnfeld writes:
> Am Donnerstag, den 21.05.2020, 17:10 +0200 schrieb David Kastrup:
>> Jonas Hahnfeld writes:
>> > Am Donnerstag, den 21.05.2020, 15:19 +0200 schrieb David Kastrup:
>> > > Jonas Hahnfeld writes:
>> > > > Am Donnerstag, den
Jonas Hahnfeld writes:
> Am Donnerstag, den 21.05.2020, 15:19 +0200 schrieb David Kastrup:
>> Jonas Hahnfeld writes:
>> > Am Donnerstag, den 21.05.2020, 14:29 +0200 schrieb David Kastrup:
>> > > The "traffic jam" problem could be avoided by retaining
Jonas Hahnfeld writes:
> Am Donnerstag, den 21.05.2020, 14:29 +0200 schrieb David Kastrup:
>> Jonas Hahnfeld writes:
>> > Am Dienstag, den 19.05.2020, 08:08 -0400 schrieb Dan Eble:
>> > > On May 17, 2020, at 15:27, Jonas Hahnfeld wrote:
>> > > >
e
experienced people desiring to bunch their work before testing, the
triggering could also happen manually by whoever thinks he has pushed
enough stuff to staging to give it a whirl.
--
David Kastrup
before \hspace #0 and once
behind it.
--
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
; 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
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
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
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
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
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
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
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
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
est, such as cvs/master and some of the dev/* branches.)
I think it was just seen as an opportunity for cleanup.
--
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.
>>
>
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
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
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
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
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
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
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, 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
>> > > &
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
to switch to GitLab (or edit your .git/config manually if preferred).
Wouldn't that just be readonly access?
--
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
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
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
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: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
repository instead, or am I
misunderstanding anything here?
--
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
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
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
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
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
401 - 500 of 6184 matches
Mail list logo
