he enclosing ‘{...}’
sequence.
You can either enclose your Staff in << ... >> or you can end its visual
impact using \stopStaff .
--
David Kastrup
n virtually all environements
> that colour/embolden keywords.
Frankly, syntax highlighting that doesn't highlight syntax but merely
lexemes does not seem all that helpful to me.
--
David Kastrup
Immanuel Litzroth writes:
>> On Wed, Sep 7, 2022 at 12:02 PM David Kastrup wrote:
>>>
>>> But "is this a good idea?" is something people should really consider
>>> when coining terms that other people will have to use as a reference.
>
> In this
tool (that ended up quite elaborate partly due to a host of
contributors) dominates the search space.
But "is this a good idea?" is something people should really consider
when coining terms that other people will have to use as a reference.
--
David Kastrup
Jean Abou Samra writes:
> I believe these not to be useful anymore as well:
>
> dev/dak/badregex
>
> (fix was later done differently by Jonas)
Will remove, but am unable to reach the repo right now.
--
David Kastrup
ngle note, I'd guess). It would
make some sense to make <...> exhibit the same behavior in chordmode and
in notemode, but I am somewhat fuzzy about that.
--
David Kastrup
c2:8 d: |
e: f: |
}
I think that is short enough for practical purposes to not require
remembering like a duration. Also leaving off the tremolo unit for
successive tremoli is practical when the duration changes: a drum roll
is rolled the same whatever the underlying base rhythm may be. Even
though our MIDI is pretty bad at understanding that point.
--
David Kastrup
Jean Abou Samra writes:
> We could also introduce a music function. I don't think
> tremoli are used frequently enough that having the most
> concise syntax for them is very important.
Drum roll... Let me guess: you don't write percussion parts frequently?
--
David Kastrup
Jean Abou Samra writes:
> Le 14/08/2022 à 09:48, David Kastrup a écrit :
>> Jean Abou Samra writes:
>>
>>> Le 14/08/2022 à 01:15, David Kastrup a écrit :
>>>
>>> If it becomes one, I will have to remember that I need
>>> to use chord brac
Jean Abou Samra writes:
> Le 14/08/2022 à 01:15, David Kastrup a écrit :
>> Jean Abou Samra writes:
>>
>>> Le 13/08/2022 à 23:11, David Kastrup a écrit :
>>>
>>>> Well, we are currently in the position where both
>>>>
>>>
Jean Abou Samra writes:
> Le 13/08/2022 à 23:11, David Kastrup a écrit :
>
>> Well, we are currently in the position where both
>>
>> and c:8
>>
>> are accepted syntactically and create a music expression, but the
>> former is garbage that is not getti
Jean Abou Samra writes:
> Le 13/08/2022 à 22:04, David Kastrup a écrit :
>> Does that sound reasonable/useful/whatever ?
>
>
>
> I don't want to make my opinion sound too strong, but to be
> honest, I'm not fond of it. I would find it confusing if
> both stuff and
2 4 >>
since
<< c2-1 e4-2 g4-3 >>
would produce per-chord articulations.
But entry-wise, this is already supported well enough. The typesetter
messes it up and I am not sure about the MIDI rendition.
But it shouldn't require new syntax, even if it seems tricky for people
to understand how << ... >> is something totally different from
the shorthand << ... \\ ... >> .
--
David Kastrup
This is just a handwaving sketch about entry; conveying information to
the chord namer would remain an open issue at first and may possibly be
better tackled in the context of integrating the pending GSoC chord
work.
Does that sound reasonable/useful/whatever ?
--
David Kastrup
t it should be user-settable, but
> we need to pick a default.
\markup \line \etc
--
David Kastrup
by
a particular Patch Meister depending on actual weekly other
obligations).
I would also underwrite the proposal to ameliorate the procedures for
flattening end-grain cutting boards in order to ensure that the
flattening remains confined to the end-grain cutting boards.
--
David Kastrup
t/scm/lily/document-context-mods.scm:
> 47:31 0 (document-mod-list (assign segnoBarType "S-||"))
>
> /home/jean/repos/lilypond/build/out/share/lilypond/current/scm/lily/document-context-mods.scm:47:31:
> In procedure document-mod-list:
> Unbound variable: value
>
>
>
> Apparently, document-mod-list in document-context-mods.scm reads
> an unbound variable.
Well, yes.
((assign)
(string-append
(format #f "@item Sets translator property @code{~a} to" name-sym)
(if (pretty-printable? value)
(format #f ":~a\n" (scm->texi (car args)))
(format #f " ~a.\n" (scm->texi (car args))
Here (pretty-printable? value) should likely be (pretty-printable? (car
args)) .
--
David Kastrup
continue to exist on
> one system or another? Does the battle-tested algorithm sort out all
> the consequences of creating those grobs?
You mean, battle-tested like with
\score {
{
\set Score.skipTypesetting = ##t
\skip 1
}
\midi { }
}
?
--
David Kastrup
he piece if
> it's going to end anyway?
Unmatched events are a problem in MIDI. MIDI processors and sequencers
working with files may to some degree try to repair such problems,
partly because they need to do so when cutting and pasting regions as
well. But you don't get guarantees.
--
David Kastrup
have the shell variable do_compare set and to a value other
than "" before doing so. Does it help to put do_compare="" at the top
of the script?
--
David Kastrup
it may
just be that you are running the script in a directory completely
unsuitable for it. I'll take a look at the instructions.
--
David Kastrup
o expect
useful information from source file comments, but those may have been
phrased a bit more diligently than average.
While the CG should certainly not be quiet here, those comments may at
least be a reasonable starting point.
--
David Kastrup
e_requests?sort=label_priority
>
>
> Push:
>
> !1374 configure.ac: Fix test ... == ... bashism - David Kastrup
> https://gitlab.com/lilypond/lilypond/-/merge_requests/1374
Ok, what did I do wrong here to have this still on the list? This was
pushed 4 weeks ago.
Thanks
--
David Kastrup
and then plot what that whole should
entail.
Basically try to aim for something making sense as a whole and not just
for supporting your particular application that is so specialised that
it does not make sense as a MR.
--
David Kastrup
Jean Abou Samra writes:
> Le 21/06/2022 à 13:21, David Kastrup a écrit :
>> Jean Abou Samra writes:
>>
>>> To check that, I applied
>>>
>>> diff --git a/lily/duration-scheme.cc b/lily/duration-scheme.cc
>>> index 5d9b4447f1..6a09253adf 1006
ion
of SCM types at the moment, nor whether there may be different ones
depending on platforms and/or options.
--
David Kastrup
Jean Abou Samra writes:
> Le 17/06/2022 à 23:49, David Kastrup a écrit :
>> Jean Abou Samra writes:
>>
>>> By the way, I have a side question. Suppose I have determined
>>> that I need to mark the local variable scm_obj with
>>> scm_remember_u
Jean Abou Samra writes:
> Le 17/06/2022 à 23:46, David Kastrup a écrit :
>> Nope. They are on the stack. They may either be immediate SCM values
>> with nothing on the heap (like SCM_EOL or small integers), or they may
>> point to a heap cell. In that case, scannin
d pattern unless the
returned value itself is an SCM that will cover scm_obj in its GC scope.
--
David Kastrup
At least I think that is the rationale also
covering a lot of Guile-internal code.
> This pattern looks somewhat frequent, so I hope I am wrong. If so,
> where is my mistake?
Hopefully above.
--
David Kastrup
he symbol LEFT rather than the value -1 in the first case. Also it
uses eqv? so it doesn't work for strings, not even literal ones.
It's a syntax construct that is less useful than it looks at first sight.
--
David Kastrup
Aaron Hill writes:
> On 2022-06-06 5:24 pm, David Kastrup wrote:
>> Putting a bit more meat on what this may mean:
>> <https://gitlab.com/lilypond/lilypond/-/merge_requests/1404>
>
> This certainly lends some brevity being able to use operators rather
> than na
David Kastrup writes:
> GOOPS was supposed to cause quite a performance hit with Guile 1.8 when
> used extensively. It wasn't supposed to do this with Guile 2+ so
> something like this should be feasible, also for other types:
>
> #(use-modules (oop goops))
>
> #(defin
Christopher Heckman writes:
> David Kastrup wrote:
>
>> Frankly, that's academic. It reminds me of the excessive amount of
>> energy placed into keeping the mathematics(!) of location vectors and
>> difference vectors separate.
>
> When you ask the question, &qu
Jean Abou Samra writes:
> Le 05/06/2022 à 14:36, David Kastrup a écrit :
>> Something like ly:moment-add has fewer implied semantics than + . Not
>> just for humans (who expect + to be more-or-less commutative and
>> associative even though the latter is only a
Dan Eble writes:
> On Jun 5, 2022, at 08:36, David Kastrup wrote:
>>
>> While I agree with Dan that at the current point of time Moment is
>> definitely overloaded too much (this has historical reasons since it had
>> been the _only_ Scheme-accessible v
fer in musical accent from identically timed triplets).
--
David Kastrup
to be "weak associativity" in that (((a+b)-b)+b)-b tends to
be the same as ((a+b)-b)+(b-b) in IEEE FP arithmetic using
"round-to-even" which helps a bit constraining progressive error
accumulation.
But algebraically that isn't a lot of help, of course.
--
David Kastrup
Jean Abou Samra writes:
> Le 05/06/2022 à 14:13, David Kastrup a écrit :
>> git grep 'ly:moment-\(add\|sub\|mul\|div\|mod\)'
>> puts out a good page or so, much of it in articulate.ly and swing.ly.
>> Admittedly, both of those files are of the kind we would want to
>>
Jean Abou Samra writes:
> Le 04/06/2022 à 13:16, Luca Fascione a écrit :
>> On Sat, Jun 4, 2022 at 12:47 PM David Kastrup wrote:
>>
>>> LilyPond uses precise arithmetic.
>>>
>> Thanks David, just out of curiosity, where's a reference to the specific
&
urations. Paris
> is not a distance and a week is not a time point.
> Immanuel
Algebra exists. Numbers obey laws regardless of what meaning you assign
to them.
--
David Kastrup
Luca Fascione writes:
> On Sat, Jun 4, 2022 at 12:47 PM David Kastrup wrote:
>
>> LilyPond uses precise arithmetic.
>>
>
> Thanks David, just out of curiosity, where's a reference to the specific
> implementation we're using?
>
> Further, besides the floating
gt;- first things first: when using floats you can't rely on (a+b)+c ==
>a+(b+c):
I prefer to discuss things as they relate to LilyPond. It uses precise
arithmetic.
--
David Kastrup
need
to check how much it affects the performance of LilyPond to add to the
overloads of operators such as + .
--
David Kastrup
Jean Abou Samra writes:
> Le 03/06/2022 à 02:32, David Kastrup a écrit :
>> GOOPS was supposed to cause quite a performance hit with Guile 1.8 when
>> used extensively. It wasn't supposed to do this with Guile 2+ so
>> something like this should be feasible, also for oth
Dan Eble writes:
> On Jun 3, 2022, at 11:48, David Kastrup wrote:
>>
>> Programming languages don't offer different types for distances,
>> positions, weights, forces, whatnot. When I equate various amounts of
>
> Bringing the conversation back to a Moment ver
hether
absolute or relative. Forcefully assigning some meaning to them in
order to prohibit any operation that does not match the meaning is not
going to end up in anything more useful.
--
David Kastrup
Carl Sorensen writes:
> On Fri, Jun 3, 2022 at 7:21 AM David Kastrup wrote:
>
>> Dan Eble writes:
>>
>> > On Jun 2, 2022, at 20:32, David Kastrup wrote:
>> >>
>> >> #(define-method (+ (a ) (b )) (ly:moment-add a b))
>> >> #(defi
Dan Eble writes:
> On Jun 2, 2022, at 20:32, David Kastrup wrote:
>>
>> #(define-method (+ (a ) (b )) (ly:moment-add a b))
>> #(define-method (- (a ) (b )) (ly:moment-sub a b))
>
> Could we also introduce a distinction in type between points and spans
> of time
functions
in C++, there may be some point in doing the same in Scheme with
generics.
--
David Kastrup
Thomas Morley writes:
> Alas I can't checkout v2.23.7:
> $ git checkout v23.7
> error: pathspec 'v23.7' did not match any file(s) known to git
I really hate that damn machine
I wish that they would sell it
It never does that what I mean
But only what I tell it
--
David Kastrup
giving marriage advice. I cannot do much
more than express my gratitude that I see people willing to work on
addressing one another's concerns and wish them success doing it without
wasting unnecessary amounts of their energy.
Sorry for that heap of platitudes in lieu of an opinion.
--
David Kastrup
wn
"stable release" and cherry-pick actual fixes instead of the entirety of
what is stable more in the Augeas sense.
--
David Kastrup
t would have made some sense with Guile 1.8. I don't
think it makes sense with stuff that is supposed to be up to date with
current versions.
--
David Kastrup
Jean Abou Samra writes:
> Le 22/05/2022 à 17:04, David Kastrup a écrit :
>> [...]
>>> Also see
>>>
>>> guile$ git shortlog -ns --since="2 months ago"
>>> 2 Timothy Sample
>>> 1 Ludovic Courtès
>>> 1 M
they are going to ship for their whole
distro, it would be good if that does not end up in making LilyPond
disappear. That's all.
What we _recommend_ and use ourselves is an entirely different matter.
--
David Kastrup
> that we want to remove in LilyPond 3.0 (the details should be discussed
> in a separate thread, I think)
I am sort of fuzzy on the plans because my own plans tend not to work
out well enough to coordinate them with other software releases.
--
David Kastrup
n't let LilyPond exit
with nonzero status anymore. That may be the reason and in want of
fixing.
--
David Kastrup
d be a symbol or #f I think.
--
David Kastrup
'. Is -ddump-tags a command line option
> to the lilypond executable?
Not yet. That's what "and then implement ..." is about, even if it's
worded a bit unfortunately in a manner suggesting that the LilyPond part
may already be there.
--
David Kastrup
David Kastrup writes:
> Jonas Hahnfeld via Discussions on LilyPond development
> writes:
>
>> On Fri, 2022-05-06 at 20:42 -0500, John Wheeler wrote:
>>> Please forgive this second attempt to reply:
>>>
>>> Jean,
>>>
>>> On 4/28
uld vote *not* to include it.
I cannot follow the characterisation as a "convenience script" here:
making Emacs properly cross-reference functions is IDE support. We
similarly have IDE support in `.dir-locals.el`. There is no real point
in doing this in a separate repository since the only use is in
connection with working in the LilyPond source tree.
--
David Kastrup
;
>
> Otherwise it exents the workload of the LSR-updater, not pretty for my
> motivation... LSR has currently already 896 files to be maintained!
>
> We should make this a policy, even more prominent as currently.
"even more prominent"? How is this prominent at all right now?
--
David Kastrup
turn
this into a roadblock for using LilyPond for them.
So you certainly did highlight that we may be relying on an
overabundance of technobabble fluency on our download pages.
There might be a point in trying to sort and rephrase our points of
first contact pages in a manner where installing LilyPond is not going
to be an uphill battle already because of language problems.
--
David Kastrup
Freeman Gilmore writes:
> On Tue, Apr 26, 2022 at 7:58 PM David Kastrup wrote:
>
>> Freeman Gilmore writes:
>>
>> > Is there going to be a non binary version for windows coming soon?
>>
>> The source code is the same independent of operating system, so yo
Freeman Gilmore writes:
> On Mon, Apr 25, 2022 at 3:50 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 ver
Kevin Cole writes:
> 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 o
reduce the amount of remaining problems for the Guile 2
migration after having started working on them in 2010, making the goal
that we finally reached now more tangible for others to work on after he
left us in 2015.
--
David Kastrup
al in
most circumstances: essentially you can use quote marks to have things
interpreted as a single word that would otherwise be split into several
syntactic entities or be considered a notename (for example).
--
David Kastrup
s somehow wrong to see stuff without quotes
that has not previously been defined.
On the other hand, we don't write
"variable" = 20
either.
--
David Kastrup
Jean Abou Samra writes:
> Le 24/04/2022 à 16:09, David Kastrup a écrit :
>> I think we had this discussion at one time, possibly resulting in making
>> this have a unique style at least in documentation.
>
>
>
> The previous discussion I could find is
>
> https
change appears to be the aesthetics of currently active
developers. That could change again, so some more persuasive rationale
would be nice to have this end up more lasting.
--
David Kastrup
constituent. That does not necessarily make them as visually cohesive
(and treated as word parts) in source code and editors.
I think we had this discussion at one time, possibly resulting in making
this have a unique style at least in documentation.
--
David Kastrup
ow" I had to revert to is
map-markup-commands even if it does not go to the depths of restarting
continuations but "only" throws parts of a solution.
--
David Kastrup
t;
> Well, I find it better if it doesn't require reworking the control
> flow logic to introduce assumptions in existing code. Also, that
> should facilitate the refactoring of unpure/pure containers into
> assumptions.
Properties will be coded a lot in Scheme. So the interface needs to map
natu
m David:
> https://lists.gnu.org/archive/html/lilypond-devel/2015-05/msg00397.html
I probably repeat myself...
--
David Kastrup
Jean Abou Samra writes:
>> Le 21/04/2022 11:05, David Kastrup a écrit :
>> Just for the record, your usage would not fit with the existing
>> lily/include/fluid.hh ,
>
>
> The existing code in fluid.hh is concerned with retrieving
> fluids. I'm asking about sett
dynwind_fluid (fluid, value);
> ...
> scm_dynwind_end ();
Just for the record, your usage would not fit with the existing
lily/include/fluid.hh , and scm_c_with_fluid does not suffice?
--
David Kastrup
ou are talking about different things. Syntactic sugar says the same
thing but in a more cohesive manner. That is not the same as assembling
dedicated functionality from suitable components.
Syntactic sugar saves clutter which is not the same as hiding internals.
--
David Kastrup
system? Reproducible on a system with the same versions of software?
--
David Kastrup
request.
Accordion editions of this age did not really have standardised symbols:
I suppose there is a synopsis in the first (editorial) pages of the
publication?
It would be really interesting to know how much use this symbol might
have seen, and whether it was from more than one publisher.
--
David Kastrup
gt; executable, and the second path indicates the source path of the
>> compiled file.
>
> ... it is a complete madness to *concatenate* these details into a
> crazy, long string that resembles a path but shows wrong directories.
How does it show wrong directories after resolving symbolic links?
> I'm sure there is a bug somewhere (or I'm doing something wrong).
--
David Kastrup
y, the `.go` files are put into
> `/home/wl/lilypond/scm/out`
>
> * `make install` doesn't install `.go` files. I seem to remember that
> this was discussed... I now wonder how to proceed with an installed
> LilyPond version.
I don't even want to venture a guess here but someone else might.
--
David Kastrup
ully but leaving a faulty markup definition that blows up at the
time interpret-markup tries instantiating the markup in the current
output definition. Since the macro has already executed successfully,
substituting different code for the original code, its connection to the
code that is now blowing up is no longer there.
--
David Kastrup
not really on-board with the
same regarding \partial/\pickup : the overlap in semantics is different
in character.
--
David Kastrup
be issued whenever a user applies the older syntax;
> this would inform the user of the impending breaking change while
> still allowing existing code to compile. When it is convenient, a
> future release would only support music as the argument.
4. _is_ valid music.
--
David Kastrup
you have to enclose the respective code (which you call "Solution
by...") in \makeatletter ... \makeatother in order to make @ ("at") a
letter for the purpose of reading the definitions in the middle.
--
David Kastrup
}
.[image src="lilypond/69/lily-bd030652.png" alt="[image of music]".]
The footnote will not be annotated automatically.
Again, flip-flopping between \footnote and \auto-footnote (apart from
which the footnotes do not actually appear in the documentation pages,
at least not in the Info version).
--
David Kastrup
pecial-cased within #{ #} passages already to avoid having to form
closures for it).
Of course your timings are quite encouraging here for seeing a path
forward but working out the details of what combinations make best sense
both in the short and the long run is likely going to need quite more
experimentation.
--
David Kastrup
t's still a lot slower than
> Guile 1.8 without bytecode. Whether it will be faster than Guile 2.2
> for our use-cases afterwards, I don't know.
I seem to remember that 3.0 vs 2.2 is not all that much of a difference:
the large jump was 2.0 to 2.2 due to a different byte code machine.
--
David Kastrup
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.
>
> My understanding of Guile's development is that certain developers
> have ideas in their mind, and they eventually end up fully implemented
> in the repository. There is no such thing as (public) plans.
And that's the polite version of putting it.
--
David Kastrup
stead of lambda and the generated callback could be smarter.
Yes, this is a lot of hand-waving for a simple question...
--
David Kastrup
ou don't get this by default, hence no problems.
If you are prepared to call "severe performance degradation of default
installations" no problem.
--
David Kastrup
Jonas Hahnfeld writes:
> Am Samstag, dem 19.02.2022 um 21:08 +0100 schrieb David Kastrup:
>> Jonas Hahnfeld writes:
>>
>> > Am Samstag, dem 19.02.2022 um 18:14 +0100 schrieb David Kastrup:
>> > > That is not as much a speed issue as an stability issue.
Jonas Hahnfeld writes:
> Am Samstag, dem 19.02.2022 um 18:14 +0100 schrieb David Kastrup:
>> That is not as much a speed issue as an stability issue. The byte
>> compilation caches are not robust across updates and downgrades since
>> they are based on file names.
&
om LilyPond never end up in the user's cache,
> they always go to the versioned directory in share/ (as you write in
> your other reply).
How would that work without the user having write permission there?
--
David Kastrup
n stability issue. The byte
compilation caches are not robust across updates and downgrades since
they are based on file names. If our own scm files are not installing
with their individual set of .go files, the installations bleed over
into the user domain and remnants may cause problems.
--
David Kastrup
to new infrastructure,
including setting up test servers for self-hosting (we did end up stuck
on the hosted Sourceforge instance anyway, but he put a lot of work in
to try and make a variant of our own work). And he kept up doing the
manually driven part of the "Patchy" workload for more than a decade if
I remember correctly.
--
David Kastrup
or (for literals which is the majority of cases) #\x4d2 (where 4d2 is
> the hex representation for the number that has the decimal
> representation 1234).
Again, a char is not a string. ly:wide-char->utf-8 generates a string.
--
David Kastrup
ng the paper block would not work for
this?
--
David Kastrup
101 - 200 of 6030 matches
Mail list logo