Graham Percival writes:
> On Thu, Nov 26, 2009 at 11:12:26PM +0100, David Kastrup wrote:
>> We are not talking about explaining concepts to potential contributors
>> in private. We are talking about explanations happening on the
>> developer list. Those can be skimmed o
when looking at the different
committed file tree snapshots. Just how much time and energy git will
will spend for detecting renames depends on the options you call it
with.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
't assume you know how people are supposed to be taught.
A lot of highly skilled programmers have what amounts to personality
disorders of one kind or the other. They may be wired completely
different from what you would expect from normal people, without making
them less suitable for helping t
Francisco Vila writes:
> 2009/11/27 David Kastrup :
>> I have what amounts to severe attention disorder syndrome. I can't
>> focus on easy tasks. I can only work effectively on hard or
>> impossible things, mostly until 95% are done. When learning or
>&g
de, that's not playable on a
standard bassoon."
Maybe that would be workable in the context of performers? On the other
hand, where mapping a chord to the available range is required, this has
to happen quite a bit earlier.
--
David Kastrup
__
Graham Percival writes:
> On Sun, Nov 29, 2009 at 09:06:32PM +0100, David Kastrup wrote:
>> If you transpose music, Lilypond could warn if notes become unplayable
>> on a baroque soprano recorder. Because the range is left, or because a
>> particular semitone is not on the
the support for ambitus,
In that case it would be sufficient to display ambitus messages on the
console output. The existing ambitus support is intended more for
performers and conductors.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-d
" "d")
In that manner, the baroque numbering does not need an exception.
Converting a number to string (if necessary) and calculating successor
of either number or string might be a bit of a hassle. But I think that
the resulting interface would be quite generic and convenient.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
our EDITOR environment variable
properly. I don't remember offhand whether VISUAL or EDITOR is used
preferentially.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
the CC recipients as well. But let's leave it and
> see if it catches anyone else out :)
Certainly did me. The ultimate solution, of course, would be to have
git-cl ask more verbosely. Namely complain to its author.
Everything else is not go
y
person apparently testing it, I don't get any design feedback, I don't
get any review of the current code, and the code _is_ left rotting on
Rietveld after all, a choice of word that I was chastised for as well.
--
David Kastrup
___
lilypond-
Graham Percival writes:
> On Thu, Dec 03, 2009 at 10:00:13AM +0100, David Kastrup wrote:
>> the current version of the patch set
>> http://codereview.appspot.com/160048> has been sitting there on
>> Rietveld for about a week.
>
> Marek: I guess it's time to add
Carl Sorensen writes:
> On 12/3/09 9:12 AM, "David Kastrup" wrote:
>
>> Graham Percival writes:
>>> Are you aware that the world does not revolve around you? For the
>>> past few days, the git tree has been broken -- I cannot compile
>>> the
Carl Sorensen writes:
> On 12/3/09 10:54 AM, "David Kastrup" wrote:
>
>> Carl Sorensen writes:
>>
>>> A (slightly different) fix has already been pushed.
>>
>> I might add, a fix that is much more complex, uses more variables, uses
>
Graham Percival writes:
> On Thu, Dec 03, 2009 at 07:35:49PM +0100, David Kastrup wrote:
>> I have been told by Graham that the segfault from script-column.cc was
>> what precluded reviews of my older patch set.
>
> To clarify, I was giving a good explanation of what oth
Carl Sorensen writes:
> On 12/3/09 11:35 AM, "David Kastrup" wrote:
>>
>> But I certainly will not invest a lot of work, upload, branch creation,
>> discussion whatever because you are not interested in making your fix
>> cleaner after being told how.
>
Graham Percival writes:
> On Thu, Dec 03, 2009 at 09:57:39PM +0100, David Kastrup wrote:
>
>> Are you suggesting that this incident should show that newcomers are
>> to jump through even higher hoops while the regulars continue to work
>> efficiently?
>
> No. It
Graham Percival writes:
> On Thu, Dec 03, 2009 at 09:57:39PM +0100, David Kastrup wrote:
>> Graham Percival writes:
>>
>> > Yes, Carl made a mistake. That's unfortunate, but he's human.
>>
>> So what do you think I am?
>
> I think you'
Carl Sorensen writes:
> On 12/3/09 2:47 PM, "David Kastrup" wrote:
>
>> There are patches that are "obviously right" and a direct
>> improvement. If I had been in his place, I'd likely have committed a
>> fix as well. I'd likely have use
Neil Puttock writes:
> 2009/12/3 David Kastrup :
>
>> I keep asking for the testing, with little success so far. I still
>> don't know whether the changes from a week ago solve the memory
>> leak/corruption problem reported with a previous version.
>
> Tha
hance to manipulate the properties and get predictable results.
Thanks
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
"Trevor Daniels" writes:
> David Kastrup wrote Friday, December 04, 2009 4:24 PM
>>
>> I've unwrapped a bit of code of the form
>>
>> for (a;b;c) {
>> if (condition)
>>short something
>> else {
>>Large something
&
estions, I'll make sure it gets commented.
I just came home and have to go to bed now. I'll write code tomorrow
that reflects the logic of your description and embeds it as well. And
some part of it probably will have to go into CG or similar, too.
--
David Kastrup
___
"Trevor Daniels" writes:
> Carl Sorensen wrote Friday, December 04, 2009 6:53 PM
>
>> On 12/4/09 9:24 AM, "David Kastrup" wrote:
>>
>>
>>> Could you describe in simple words what the behavior is supposed to
>>> achieve? If y
http://codereview.appspot.com/164096>
> If nobody objects I'll commit it within a few days.
Maybe there should be a common strategy with \parallelMusic in
connection with \relative? Possibly there is some overlap in the
problems.
--
David Kastrup
___
lse can guess.
So a smart engine that does a lot of "memoization" sounds like
overengineering. Diminuishing returns. A shortcut syntax for \repeat
unfold would be likely better parseable.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
d.
The editor needs to be suitably clever to have this work properly in
\relative mode. Ok, should be sufficient to remove octave indicators
from the first chord note, so this is probably not overly hard.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
stablish how long this memoization is supposed to
hold. But at least there would be a clear indication _what_ is
remembered, and one could with reasonable accuracy run the stuff through
a preprocessor that removes those marks.
--
David Kastrup
t; starts with a "c".
You'll see where the confusion about blackletter "c" being either r or
gamma arises.
> The omission of j will be curious to anyone writing analytical
> software, but that is enough strangeness (gotta have at least one
> point of strang
looking really professional.
>
> But if nobody is working on fixing them, who cares what the label
> is?!?!
Huh? Who cares about the label of a bug that is already being fixed?
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
ot; and similarly //| would also be nice in that application.
I am not sure whether coupling repetition without explicit label to
notational repetition without explicit note names is the optimum, but it
feels like a reasonable way to express this.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
q
effectively does change the meaning of the input, I don't think it all
too far off to actually let it affect parser syntax to get a more
readable entry.
I am afraid that these are about half a dozen somewhat overlapping
concerns, so it is probably not overly
Nicolas Sceaux writes:
> Le 12 déc. 2009 à 14:01, David Kastrup a écrit :
>>
>> { G4 g D // | /// // / // | \time 3/4 G g / | D // // | /// // // | }
>
> Memorizing more than one chord/note (e.g. 3 chords/notes), and accessing
> them using q, qq, qqq, would do it?
Sure
"Trevor Daniels" writes:
> Nicolas Sceaux wrote Saturday, December 12, 2009 3:39 PM
>>
>
>> Le 12 déc. 2009 à 14:01, David Kastrup a écrit :
>>>
>>> { G4 g D // | /// // / // | \time 3/4 G g / | D // // | /// // // |
>>> }
>>
>
becomes quite useless. Spent days on hunting down
an "impossible bug" more than once.
** When you are trying to analyze failed assertions, it will be
essential to compile Emacs either completely without optimizations or
at least (when using GCC) with the -fno-crossjumping option. Failu
Karlin High writes:
> On 2/6/2020 2:45 PM, David Kastrup wrote:
>> I am working on an Email signature that might be helping to convey the
>> message.
>
> Nice idea, but sometimes drawing attention to a problem only makes
> things worse. How about focusing on the suc
requiring maximum permissions and
having pervasive logging. That seems to only make business sense in the
data gathering business, for internal or external use.
Sorry, this is all not much more than banter right now. Basically I
don't see any obvious red flags.
--
David Kastrup
the purpose of self-hosting. That gives an
escape hatch that either users or competing services can pick up in the
case of contingency.
This may seem academical, but even the academical possibility reins in
corporate decision makers from performing wholesale changes on a whim.
--
David Kastrup
ce the Rietveld part of our
workflow, but not the SourceForge part.
--
David Kastrup
d a change and often giving extensive
other information like problem images. That's something we cannot
attach to commits (or at least, this has not been attempted so far).
--
David Kastrup
w if I’m just talking nonsense.
> If not, let me know how I can help make this "fix" a reality.
Well, the problem is that there is no "grace event" but a grace iterator.
Now this this characterization is not entirely true any more since
commit 99a85ca39f3a7a6f717ba06a48ef0b
Han-Wen Nienhuys writes:
> On Fri, Feb 7, 2020 at 3:36 PM David Kastrup wrote:
>
>> Han-Wen Nienhuys writes:
>>
>> > n the spirit for providing competing options, I hereby offer a Gerrit
>> > RFC. Note that I'm an obvious fan of Gerrit, but Gitlab se
desirable end point for Guilev2 migration but a migration
strategy designed for getting back something working as before. Which
is a starting point from which one can then explore the task of getting
to an environment that looks like Unicode rather than bytes from the
Scheme side.
--
David Kastrup
already previously turned into non-showstoppers although not necessarily
in the cleanest manner. But it would seem that even if part of them is
likely to eventually be superseded, giving Han-Wen a better starting
place would make him work and plan more effectively.
--
David Kastrup
My replie
cheme-containing data structures
instead of being in a state where only parts are operative.
--
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".
Han-Wen Nienhuys writes:
> On Fri, Feb 7, 2020 at 6:54 PM David Kastrup wrote:
>
>> I propose that I am going to pick up the pieces of
>> not-actually-formally-reviewed patches making up the bulk of them and
>> put them, Guilev2-guarded (so that they don't affect
shly but definitely sincerely) an eventually gratifying work/life
balance.
--
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".
Han-Wen Nienhuys writes:
> On Fri, Feb 7, 2020 at 6:54 PM David Kastrup wrote:
>
>> I propose that I am going to pick up the pieces of
>> not-actually-formally-reviewed patches making up the bulk of them and
>> put them, Guilev2-guarded (so that they don't affect
Han-Wen Nienhuys writes:
> On Fri, Feb 7, 2020 at 6:54 PM David Kastrup wrote:
>
>> I propose that I am going to pick up the pieces of
>> not-actually-formally-reviewed patches making up the bulk of them and
>> put them, Guilev2-guarded (so that they don't affect
Karlin High writes:
> On 2/6/2020 2:45 PM, David Kastrup wrote:
>> I am working on an Email signature that might be helping to convey the
>> message.
>
> Nice idea, but sometimes drawing attention to a problem only makes
> things worse. How about focusing on the suc
David Kastrup writes:
> Han-Wen Nienhuys writes:
>
>> On Fri, Feb 7, 2020 at 6:54 PM David Kastrup wrote:
>>
>>> I propose that I am going to pick up the pieces of
>>> not-actually-formally-reviewed patches making up the bulk of them and
>>> put the
facets of who I am.
> I'm borderline on the spectrum myself, and yes it can make life
> difficult with people who don't know you ...
But the point is they have to know you, not your medical folder.
--
David Kastrup
My replies have a tendency to cause friction. To help mitig
ng, that
would be really a thing. Especially if the translators should get a
chance at picking those up yet.
--
David Kastrup
David Kastrup writes:
> David Kastrup writes:
>> Han-Wen Nienhuys writes:
>>
>>> On Fri, Feb 7, 2020 at 6:54 PM David Kastrup wrote:
>>>
>>>> I propose that I am going to pick up the pieces of
>>>> not-actually-formally-reviewed patc
7;t touch
> any header file). But what's then the point of using ccache, we can
> just trigger a full build?
Full builds are slower. But I really don't trust our dependencies all
too much, and for example Clang builds don't get a working set of
dependencies anyway (which is sort of curious since it is the modular
Clang that should be able to parse for them easily).
--
David Kastrup
olution that talks to the user in composer terms, and to the program in
LilyPond terms.
End of pontification. Just something that tends to lurk in the back of
my mind and sometimes might give a different outlook on a problem.
--
David Kastrup
My replies have a tendency to cause friction. To help
pened to the SQLite project.
>
> In the spirit of the recent "RFC" posts that explore different future
> directions, I think I could soon propose something for a Code of
> Conduct. (It draws on some centuries-old traditions of community
> conflict resolution.)
>
> How
eeds?
> Jonas
It's worth pointing out that almost _all_ of our Scheme-level
allocations are routed through the Smob_core class, so doing the heap
extension _there_ when one passes there next should be workable. While
the code certainly does allocate non-Smob SCM objects a lot as well (by
calling things like scm_cons), the smobbed ones should be worked often
enough that extending the heap then should not cause too much churn.
--
David Kastrup
abandon the markup macro. Not that I am the least bit fond of it,
but it's almost omnipresent.
--
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".
x27;s a patch. Review showed there are too many objections. Thus it
>> should be set to 'needs work' or 'waiting'.
>> Otoh, there are suggestions to replace this proposal. Why not focus on
>> those proposals?
>
> Excellent suggestion.
Unsurprisingly I am
think about what to do here.
--
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".
Urs Liska writes:
> Am Samstag, den 08.02.2020, 17:31 +0100 schrieb David Kastrup:
>> Thomas Morley writes:
>>
>> > P.S. that 'make test-baseline' failed, I'll need to investigate
>> > after
>> > sending this.
>> >
>> &
Han-Wen Nienhuys writes:
> On Sat, Feb 8, 2020 at 4:23 PM David Kastrup wrote:
>
>>
>> > Does this already solve your needs?
>>
>
> I found a way, using pthread_create. Unfortunately, it's doesn't really
> work, because there is no way to dis
Werner LEMBERG writes:
>>> However, I'd like to hear from David Kastrup and James Lowe
>>> first. To me, their opposition registered as the strongest.
>>
>> I remain strongly opposed to a CoC.
>
> Hmm. What about simply using the GNU Kind Communication
ead
> after all.
Frankly, the state of the automatation is pitiful, but we were also
partly laboring from a dearth of API documentation IIRC as well as a
lack of people versed in the respective programming
languages/systems/frameworks.
Lame excuses, I know. At any rate, things on my plate
s pkx starts with p which
means that it is James. Seriously: I suspect that as silly as it
sounds, that may be one of the larger hurdles for developing two
different mental images for people one only identifies by their names
and Email addresses.
--
David Kastrup
My replies have a tendency to cause
Trevor writes:
> Phil Holmes wrote 08/02/2020 17:24:56
> Subject: Re: Add Code of Conduct [Another RFC or not now?]
>
>>- Original Message - From: "Karlin High" >>However, I'd like to hear from David Kastrup and James Lowe
>> first. To me, th
Graham Percival writes:
> On Sat, Feb 08, 2020 at 07:21:30PM +, Trevor wrote:
>> Phil Holmes wrote 08/02/2020 17:24:56
>> Subject: Re: Add Code of Conduct [Another RFC or not now?]
>>
>> > - Original Message - From: "Karlin High" > >
ynchronized way. I don't if that exists in practice, but it is one of
> the reasons for the current approach.
I don't think grace notes are usually synchronized optically. I may be wrong.
--
David Kastrup
a challenge to find a time that will work for people from
> different timezones, but I'll figure somethig out (have some ideas already).
>
> Thumbs up or thumbs down?
What kind of meeting were you thinking of? IRC/Chat? Voice? And/or
video?
--
David Kastrup
\new Voice { \applyContext #(lambda (ctx) (display ctx)) b4 }
> which is nice again and the same as in 2.19.84 with guile-1.8
>
> Does anybody knows whether it's a guile- or lily-improvement?
No idea. It might be a different compilation option or environment or
eval setting that is at
Janek Warchoł writes:
> sob., 8 lut 2020 o 23:56 David Kastrup napisał(a):
>
>> Janek Warchoł writes:
>> > I'd be willing to organize and moderate the meetings (take care of
>> > preparing the agenda and sharing the take-aways with the devel list). I
>>
Thomas Morley writes:
> Am Sa., 8. Feb. 2020 um 23:59 Uhr schrieb David Kastrup :
>>
>> Thomas Morley writes:
>>
>> > Hi,
>> >
>> > one problem with guilev2 are anonymous procedures. Like how to get
>> > nice output for
>> >
>
ssion toward or disparagement of classes of individuals.
**Consequence**: A permanent ban from any sort of public interaction within
the community.
--
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".
David Kastrup writes:
> Janek Warchoł writes:
>
>> Elaine,
>>
>> pt., 7 lut 2020 o 02:28 Flaming Hakama by Elaine
>> napisał(a):
>>
>>> 1) "Adopt this CoC or I will leave the community" Such threats amount to a
>>> my-way-or
quot;Emacs" and "LilyPond" were not really suitable as
projects showcasing a "Code of Conduct". Which was sort of the point.
Nobody reads abstracts anymore.
So maybe I'm responsible for bringing up the idea in the first place
because of being too confusing in my choice
scussion of just where the overkill starts.
> 1:
> https://github.com/torvalds/linux/blob/master/Documentation/process/submitting-patches.rst#2-describe-your-changes
>
--
David Kastrup
My replies have a tendency to cause friction. To help mitigating
damage, feel free to forward proble
irritating about grace time is what it does graphically
and in midi to an appoggiatura. Those are usually supposed to come
on-time, have at _least_ the nominal duration and steal time from the
_next_ rather than the previous note.
--
David Kastrup
My replies have a tendency to cause friction. To help
Thomas Morley writes:
> Am So., 9. Feb. 2020 um 00:23 Uhr schrieb David Kastrup :
>>
>> Thomas Morley writes:
>>
>> > Am Sa., 8. Feb. 2020 um 23:59 Uhr schrieb David Kastrup :
>> >>
>> >> Thomas Morley writes:
>> >>
>> &g
tepmake/generic-targets.make:6:
> recipe for target 'all' failed
> make: *** [all] Error 2
>
> --
>
> I pushed a doc change but it doesn't look like that so either it's
> Han-Wen's or Jean-Charle's cherry picks.
Sounds like a full disk to me. Sure that that isn't the case? Our
whole test setup can take a silly amount of disk space while it is
running (last time I checked, and that was some while ago, something
like 4GB or a bit less).
--
David Kastrup
Thomas Morley writes:
> Bringing some offlist-discussion back to the list because it may
> interest more people
>
> Am So., 9. Feb. 2020 um 12:44 Uhr schrieb David Kastrup :
>
>> The output of "make test" starts with a line "for tracing crashes, run
>&g
mari+lilyp...@mailbox.org writes:
>> On 2/9/20 1:49 PM, David Kastrup wrote:
>>> mari+lilyp...@mailbox.org writes:
>>>
>>>> when converting a mxl file with "musicxml2ly --language=deutsch" the
>>>> note "beses" is converted to
nd it fails, if compiled directly, I've checked that.
Differences to what I do: I use
CPU_COUNT=9 make -j9 test
Namely more than one CPU, and I first make test rather than
test-baseline. I have no idea why that would make a difference.
--
David Kastrup
en.
I have 4 pretending to be 8, so that's what the 9 is about. The next
generation Thinkpad would have allowed getting a processor doing that
without exceeding thermal design power. But then I don't have a
discrete GPU and don't do a lot of video processing. I still have th
t that as
an independent vote that this might be the sanest extension into
quarternote territory.
> On 2/9/20 5:52 PM, David Kastrup wrote:
>> mari+lilyp...@mailbox.org writes:
>>
>>>> On 2/9/20 1:49 PM, David Kastrup wrote:
>>>>> mari+lilyp...@mailbox
think
there is a reasonable chance of either me or some other reader on this
list having retired something that would help in cases where 5 threads
of compilation are already too much.
--
David Kastrup
My replies have a tendency to cause friction. To help mitigating
damage, feel free to forward proble
en migrated from Google Code). Another
> shortcoming is that I could not reproduce the threaded structure on SF,
> so all comments are sorted chronologically.
>
> Please all take a look and let me know what you think!
For a first pitch certainly impressive. It's nice that the SHA1 ids
have become live.
--
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".
Han-Wen Nienhuys writes:
> On Sat, Feb 8, 2020 at 11:43 AM David Kastrup wrote:
>
>> Ok, there are still 3 unmerged patches marked XXX in the (now rebased)
>> branch dev/guile-v2-work . They are unmerged because they are marked
>> XXX . Here is the list:
>>
s related to the
locale fiddling in the remaining two patches from the dev/guile-v2-work
branch, so I cannot rule out that you may have already rendered the last
two remaining awkward-looking patches for the build system unnecessary.
But I don't think we have a test case readily available fo
hings like #'bla and #7 so I don't really have an
idea how this could apply here. Just throwing it out in case it could
prove related.
--
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".
er hand few documents don't have even a single # since
it is used for banal things like number entry. And not having a few
thousand port openings is possibly advantageous. Usually a port should
be easier to reposition than to open, though our way of repositioning,
if I am not mistaken, is not particularly efficient.
--
David Kastrup
David Kastrup writes:
> Han-Wen Nienhuys writes:
>
>> On Sat, Feb 8, 2020 at 11:43 AM David Kastrup wrote:
>>
>>> Ok, there are still 3 unmerged patches marked XXX in the (now rebased)
>>> branch dev/guile-v2-work . They are unmerged because they are marked
t; <http://xn--filename_-3j3fv107b1jsa.ly>' is approx shocking x16 (with a
>> huge halt at 'Layout output to ...'-stage)
>> Both compared to 2.19.84
>>
>> Any way to improve?
>>
>>
> How are filenames encoded on Windows? What does GUILE do when you ask it to
> open a file with a unicode name? (does it know to encode as utf8?)
--
David Kastrup
Han-Wen Nienhuys writes:
> On Mon, Feb 10, 2020 at 2:40 PM David Kastrup wrote:
>
>>
>> > Short repro:
>> >
>> > fail-func =
>> > #(define-music-function (name)
>> >(string?)
>> > #{
>> > \new Staff = #(str
People
will still have to look at the source code afterwards without throwing
up, so what is your preference?
--
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".
Dan Eble writes:
> On Feb 10, 2020, at 17:47, David Kastrup wrote:
>> It will look a bit redundant either way with
>>
>> grob->Get (Grob, "color");
>> or
>> grob->grob_set ("stencil", SCM_BOOL_F);
>
> "Yuck" either way
David Kastrup writes:
> Dan Eble writes:
>
>> On Feb 10, 2020, at 17:47, David Kastrup wrote:
>>> It will look a bit redundant either way with
>>>
>>> grob->Get (Grob, "color");
>>> or
>>> grob->grob_set ("stenc
volunteer, so we should make sure that what is expected
to be a net win for the average contributor does not yet make things
harder for him.
We don't want to be in the situation that should he one day decide to
spend more time working with LilyPond than working for LilyPond, we have
to close shop
Jonas Hahnfeld writes:
> Am Dienstag, den 11.02.2020, 13:48 +0100 schrieb Federico Bruni:
>> Il giorno mar 11 feb 2020 alle 13:18, Jonas Hahnfeld <
>> hah...@hahnjo.de
>> >
>> ha scritto:
>> > > > Another shortcoming is that links to other issues are broken
>> > > > (transformed in links to no
Dan Eble writes:
> On Feb 10, 2020, at 20:48, David Kastrup wrote:
>>
>> Templating on a string constant is, unfortunately, not a thing at least
>> in C++11 (don't know whether they managed since then). Or one could go
>> that route rather than GCC-specif
201 - 300 of 6220 matches
Mail list logo
