David Kastrup writes:
[Bisection]
>> Commit c1d7bc2217462a63bf5c5c6d6f6df5cb00099180
>> Author: David Kastrup
>> Date: Tue May 3 19:11:15 2016 +0200
>>
>> Issue 4842/6: Don't special-case Scheme_engraver's acknowledgers
>>
>>
>&
David Kastrup writes:
> David Kastrup writes:
>
> [Bisection]
>
>>> Commit c1d7bc2217462a63bf5c5c6d6f6df5cb00099180
>>> Author: David Kastrup
>>> Date: Tue May 3 19:11:15 2016 +0200
>>>
>>> Issue 4842/6: Don't special-case Sc
nippet (or when exiting)
later on.
That is, if we can show that the Scheme_engraver code actually gets
exercised during the runs that crash.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/li
James Lowe writes:
> David,
>
> On 20/05/16 17:38, David Kastrup wrote:
>> James writes:
>>
>>> I don;t know what the lilypond.pot stuff does but could that have been
>>> the problem?
>> Unlikely. I think it may be the distribution of files acro
somewhat less inclined to create
issues/patches for trivial stuff.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
(Voice ,(make-accidental-rule 'same-octave 0))
>(Staff ,(make-accidental-rule 'same-octave 0))
>Staff
accidental-styles.hymnbook-cautionary =
#`(#f (Voice ,(make-accidental-rule 'same-octave 0))
Dan Eble writes:
> [I dropped lilypond-devel when I replied. Sending David’s reply to the list.]
>
> From: David Kastrup
> Subject: Re: Custom accidental styles
> Date: May 21, 2016 at 12:29:05 EDT
> To: Dan Eble
>
> Dan Eble writes:
>
>>> On May 21, 2
David Kastrup writes:
> Dan Eble writes:
>
>> From the Guile docs:
>>
>> `define' (when it occurs at top level), `scm_define' and
>>`scm_c_define' all create or set the value of a variable in the top
>>level environment
er ground checking what it happening with make doc.
There are a few other commits in that area, so reverting is not all that
easy.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
d -name core
in your LilyPond directory.
Then you do
gdb out/bin/lilypond Documentation/ly-examples/core
and should be able to tell gdb to
backtrace
Be sure that you don't have an old core file lying around: I think that
Linux does not overwrite preexis
David Kastrup writes:
> David Kastrup writes:
>
>> Dan Eble writes:
>>
>>> From the Guile docs:
>>>
>>> `define' (when it occurs at top level), `scm_define' and
>>>`scm_c_define' all create or set the value of a va
have put them in a branch
of their own).
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
, things are even muddier than I thought.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
James writes:
> David
>
> On 24/05/16 18:20, David Kastrup wrote:
>> James Lowe writes:
>>
>>> No core file was generated, I also upped the ulimit to 1GB.
>>>
>>> So perhaps it isn't the type of 'assertion' or crash you thought it
&
David Kastrup writes:
> James writes:
>
>> David
>>
>> On 24/05/16 18:20, David Kastrup wrote:
>>> James Lowe writes:
>>>
>>>> No core file was generated, I also upped the ulimit to 1GB.
>>>>
>>>> So perha
Knut Petersen writes:
> Am 20.05.2016 um 17:27 schrieb David Kastrup:
>> David Kastrup writes:
>>
>>> Can you run this under a debugger and place a breakpoint on
>>> Scheme_engraver::init_from_scheme or just write abort(); as its first
>>> line? I wan
Knut Petersen writes:
>>>> Knut, did you use any options to ./configure ? config.log should
>>>> mention how configure was called.
> doit "../configure --prefix=$MYROOT"
Ok, so no options at all.
--
David Kastrup
__
s.
If you need to access them as a set anyway, it's faster to get them once
and go from there.
There may be properties in some "details" that are named identically to
properties in some other "details" or at top level.
That's what I can currently think of.
I'm not
tisimst writes:
> On Thu, May 26, 2016 at 12:50 AM, David Kastrup [via Lilypond] <
> ml-node+s1069038n190980...@n5.nabble.com> wrote:
>>
>> I'm not particularly enamored with the details either, but if you
>> take a look at stuff like the harp diagram details,
gets seen only on certain systems likely
depending on GCC version and/or machine architecture) because the
changes of the incriminated patch do not introduce markedly different
code from before. If anything, it removes code.
--
David Kastrup
___
li
you to run Patchy Merge on your system
> and see if you can get this to work.
I've started one just now on my laptop. It just takes significantly
North of one hour to complete.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gn
Thomas Morley writes:
> 2016-05-27 16:22 GMT+02:00 David Kastrup :
>> James writes:
>>
>>> Hello,
>>>
>>> I still cannot make doc and so cannot merge staging - and for those
>>> waiting on me to test new patches, I cannot do that with any great
tion of key release since this leads to shorter Midi messages
and faster transmission than the "proper" key release event.
You need at least 1 to make a distinctive event.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
el running on a 32bit userland and the
free drivers did not work reasonably. Maybe the situation has improved.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
David Kastrup writes:
> I have to see whether I have a chance to run a 64 bit kernel on my
> system: I used to for a few years (and consequently was able to look
> at 64 bit code), but the current laptop has an Nvidia card and
> Ubuntu's kernel/library setup did not manage
David Kastrup writes:
> David Kastrup writes:
>
>> I have to see whether I have a chance to run a 64 bit kernel on my
>> system: I used to for a few years (and consequently was able to look
>> at 64 bit code), but the current laptop has an Nvidia card and
>> Ubu
stem to a degree where I will not be able to run it
with a 32bit kernel or GNOME any time soon again. On the plus side,
I've been able to hibernate a few times (not possible before).
But I should be good for testing 64bit compilation now. Not so sure
about 32bit.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
isted in the log compiles on its own without
>> problem. They all deal with fonts in some way, though.
I think make doc uses --bigpdf and some sort of PDF postprocessing.
Maybe one needs that to reproduce?
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
David Kastrup writes:
> Thomas Morley writes:
>
>>> Processing `./c0/lily-c236818d.ly'
>>> Parsing...
>>> Renaming input to: `/home/hermann/lilypond-git/input/regression/utf-8.ly'
>>> Interpreting music...
>>> Preprocessing graphical
s listen to events and acknowledgments only in their
dedicated context but can announce anywhere. It's possible to move the
listeners around independently if that opens a viable solution. Of
course, the lifetime of an engraver is tied to its hosting context,
however.
--
David Kastrup
Knut Petersen writes:
> Am 29.05.2016 um 13:52 schrieb David Kastrup:
>> I have to see whether I have a chance to run a 64 bit kernel on my
>> system: I used to for a few years (and consequently was able to look
>> at 64 bit code), but the current laptop has an Nvidia card a
oblems.
It may or may not be the blocker for James, either. At any rate, I am
currently going through the C++ standard with respect of initialization
orders and stuff, and I hope to get to tackle the problem Knut has been
focusing on eventually.
It does seem utterly strange that both failures sh
David Kastrup writes:
> Thomas Morley writes:
>
>> 2016-05-29 21:03 GMT+02:00 Thomas Morley :
>>
>>> I'll now checkout a fresh branch from master, apply Hosoda-san's patch from
>>> https://codereview.appspot.com/298320043/
>>> change orche
ues in stack allocations. That's perfectly to be
expected with a conservative garbage collector, however. I'm taking a
look at the heap-related complaints though since on the heap, GC should
not occur conservatively (not in Guile-1 at least).
--
David Kastrup
__
James writes:
> Hello
>
> On 30/05/16 15:06, David Kastrup wrote:
>> James writes:
>>
>>> Zipped Valgrind output of both OSes is attached to this email or can
>>> be obtained here:
>>>
>>> https://drive.google.com/file/d/0B9nZ5LHV2Ds6d
have to be kept from
proliferating within the meadows. Somewhat annoyingly, when scything on
an active meadow, some horses will indeed get behind you and start short
work on the results. Apparently detaching them from the ground is the
most tedious part of eating them
ush origin translation:/dev/fede/doc-it
>
> Not a big deal.. but I'd be curious to know what's the mistake.
/dev/fede/doc-it is an absolute path.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
staging then not just gets past the ly-examples
but also the rest of the docs. If it does, for whatever misbegotten
reason, at least we'll stop wasting your time with regular work and I
can get this crap analyzed without time pressure.
--
David Kastrup
_
led runner: %s\nSee the log file %s" % (command,
> this_logfilename))
> FailedCommand: Failed runner: /tmp/lilypond-autobuild/configure
> --disable-optimising
> See the log file log-staging-configure.txt
Ugh, sorry for that. I need to tell my patchy to compile for 64bit or
it
()
> File "/home/patchy/patchybuild/autobuild/scripts/midi2ly.py", line
> 441, in parse
> if (e[1][0] == midi.NOTE_OFF
> NameError: global name 'midi' is not defined
> make[2]: *** [out-test/key-initial-midi.ly] Error 1
> make[2]: *** Waiting fo
ython2.7. And half the desktop environment
depends on that so I don't want to swap that out.
I have to see whether I can make a clean 64/32 split along the necessary
lines here.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
e.in: Remove.
* lily/main.cc (setup_paths): Fix and document build-dir hack.
).
As I want to have 64bit compilation with C++ and 32bit with C on my
personal computer (don't ask), it's important to have the linker
distinguished properly.
--
David Kastrup
James writes:
> On 31/05/16 13:37, David Kastrup wrote:
>> "Phil Holmes" writes:
>>
>>> Patchy-staging running now.
>>>> https://codereview.appspot.com/297420043/
>> Well, hooray! master has been pushed. Now let's see whether this helps
James writes:
> On 31/05/16 13:56, James wrote:
>>
>>
>> On 31/05/16 13:37, David Kastrup wrote:
>>> "Phil Holmes" writes:
>>>
>>>> Patchy-staging running now.
>>>>> https://codereview.appspot.com/297420043/
>>&g
James writes:
> On 31/05/16 16:52, David Kastrup wrote:
>
>> That sounds like Lilydev and 32bit. I'd be interested to know whether
>> 64bit has improved.
>
> This was 64 bit.
Great.
> It is just that I still had default setting of the
> lilypond-patchy-confi
j3 CPU_COUNT=3
18:32:37Success:nice make doc -j3 CPU_COUNT=3
18:32:54 To ssh://git.sv.gnu.org/srv/git/lilypond.git
905109e..1b6d6de test-staging -> master
18:32:54Success:pushed to master
--
David Kastrup
ent size I have is 120GB.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
David Kastrup writes:
> Hi,
>
> my current development SSD, graciously donated by James, currently has
> the following readings:
>
> Vendor Specific SMART Attributes with Thresholds:
> ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED
> WHE
Michael Hendry writes:
>> On 1 Jun 2016, at 10:07, David Kastrup wrote:
>>
>> David Kastrup writes:
>>
>>> Hi,
>>>
>>> my current development SSD, graciously donated by James, currently has
>>> the following readings:
>&
ybe I just need to keep
making backups in sane intervals and otherwise am still fine.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
alking about two separate
problems here. Have you tried the recent patches by Hosoda-san? They
would appear to concern Japanese font problems, and there are two on
countdown.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http
efore-initialization. Guilev2 might be affected worse, so making
things airtight is not a waste of time. Still, I'd want to get a hold
on the actual culprit.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
for particularly large PDF files, don't they?
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
early (cross fingers). So you should
particularly update your "New" list in order to avoid testing patches
that are already in.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Accepted". Changed that right now.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Dan Eble writes:
> On Jun 6, 2016, at 08:39 , David Kastrup wrote:
>>
>> Dan Eble writes:
>>
>>> Also, I submitted a couple patches that do not appear in your list.
>>> Did I miss a step somewhere?
>>>
>>> https://sourceforge.net/p/
Dan Eble writes:
>> On Jun 6, 2016, at 16:52 , David Kastrup wrote:
>>
>> Dan Eble writes:
>>
>>> On Jun 6, 2016, at 08:39 , David Kastrup wrote:
>>>>
>>>> Dan Eble writes:
>>>>
>>>>> Also, I submitted
Dr Nicholas Bailey writes:
> On Wednesday, 1 June 2016 12:36:02 BST David Kastrup wrote:
>> Alexander Kobel writes:
>> ...
>>
>> Sure, it would be nice to keep in mind. I'm not really sure what the
>> expected lifetime of the disk I have is. Maybe I
#x27;,
needed by `out/pango-font.o'. Stop.
make[1]: *** Waiting for unfinished jobs
The "unfinished jobs" create so much more output afterwards that you
probably overlooked this problem.
--
David Kastrup
___
lilypond-deve
a
lot of trouble by just doing some change on our side. Blame-shifting
tends up to be a lot of work and hassle with _our_ users, never mind
that technically we are not at fault at all.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Richard Shann writes:
> On Thu, 2016-06-09 at 12:57 +0200, David Kastrup wrote:
>> Werner LEMBERG writes:
>>
>> >>> >> However, there's still a nasty scaling bug that completely ruins
>> >>> >> text positioning at larger magn
Richard Shann writes:
> On Thu, 2016-06-09 at 13:23 +0200, David Kastrup wrote:
>> Richard Shann writes:
>>
>> > I don't know about *this* bug, but I did test out replacing
>> > currentColor with "black" (in quotes) in the LilyPond source code
&g
results is not going to mitigate the damage.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
age".
> The current default of Lilypond is not wrong, as far as I can see.
Shrug. It doesn't matter whether we can nominally justify calling this
"somebody else's problem". The fallout still piles up in our backyard.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
ote
_itself_ two times. So \relative is applied to the same music two times
in succession.
Use #(music-clone note) or #(ly:music-deep-copy note) or $note for your
two uses, and the note will get placed in two separate _copies_ of the
original rather than using the note object itself in two places.
--
David Kastrup writes:
> Phil Holmes writes:
>
>> Can anyone explain why the f in the attached code is 2 octaves above where
>> I would expect them?
>>
>> testy = #(define-music-function (note)
>> (ly:music?)
>> #{
>> \tag #'a
tion
>> [-Wuninitialized]
>> /home/dan/lilypond-git/lily/protected-scm.cc:75:56: note:
>> '' was declared here
That's current staging/master? It would likely be issue 4873 that
caused the change. I don't remember seeing a similar message on my
compute
verride AccidentalSuggestion.glyph-name-alist =
#alteration-mensural-glyph-name-alist }
{
\new MensuralVoice { \mus }
}
}
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
for something related in default context/grob
properties in the Scheme files.
Approaches that don't work without specialist handholding and/or code
archaeology don't really scale well.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
hy lilypond-patchy-staging is able to
get through with its documentation building.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
ber of elements that might be involved here will
definitely be helpful.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
then
> nobody touched it.
>
> Strange enough, the last commit I've found tackling paper-system.scm is
Cf.
https://lists.gnu.org/archive/html/lilypond-devel/2015-06/msg00068.html>
and Trevor's answer.
Not that this is overly conclusive about what we should do here.
--
D
in master happened to be reverts which
did not apply cleanly but had to be significantly edited.
Adding merge resolution on top might lead to problems.
Can you try rebasing on master/origin and see whether that helps?
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
technique has been used for acknowledgers for quite a while now,
recently reversed, and later reinstated.
So it does not make a whole lot of sense to be that it fails with
listeners, and only with some compilers. The responsible commit would
likely be
commit f7013d65b51f1372dc31973b78bb
it has to inherit overloaded template functions with a single
"using" instruction. I propose the following patch (to current
master). Does it change something for you?
>From fa45edd4db3d49817425fa7833559f20697c3c74 Mon Sep 17 00:00:00 2001
From: David Kastrup
Date: Fri, 24 Jun 2016
ist? and if it has two members
(more would be an error) the first should be a context type symbol
indicating the context the separate engravers choose to share their data
over.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Knut Petersen writes:
> Am 24.06.2016 um 15:13 schrieb David Kastrup:
>> At any rate, this implies that TRANSLATOR_INHERIT fails doing its job
>> when it has to inherit overloaded template functions with a single
>> "using" instruction. I propose the follow
Ok, next try.
>From 664bdeb25a2ece31bd42774e1c0c7cadb790ebf1 Mon Sep 17 00:00:00 2001
From: David Kastrup
Date: Fri, 24 Jun 2016 15:10:44 +0200
Subject: [PATCH] TRANSLATOR_INHERIT -> ENGRAVER_INHERIT
In order to accommodate older g++ compilers, inheriting
methods/listeners/acknowledg
Marc Hohl writes:
> Am 24.06.2016 um 10:33 schrieb David Kastrup:
> [...]
>>
>> Well, it got through patchy-staging. So obviously something is
>> different with your setup, and you don't give any information about your
>> setup. What does g++ --version say
Knut Petersen writes:
> Am 24.06.2016 um 16:43 schrieb David Kastrup:
>> Ok, next try.
>>
>
> On top of HEAD:
>
> In file included from /home/knut/sources/lily/lily/slur-engraver.cc:32:0:
> /home/knut/sources/lily/lily/slur-engraver.cc: In static member function
Knut Petersen writes:
> Am 24.06.2016 um 18:15 schrieb David Kastrup:
>> Knut Petersen writes:
>>
>>> Am 24.06.2016 um 16:43 schrieb David Kastrup:
>>>> Ok, next try.
>>>>
>>> On top of HEAD:
>>>
>>> In file inclu
David Kastrup writes:
>> autogen.sh --noconfigure
>> configure --prefix=/home/knut/sources/lilybisect/
>> make -k -j 1 CPU_COUNT=1 all
>>
>> Logfile attached.
>
> I see a single error. That's ... curious. Have to go to rehearsal now,
> will investiga
David Kastrup writes:
> David Kastrup writes:
>
>>> autogen.sh --noconfigure
>>> configure --prefix=/home/knut/sources/lilybisect/
>>> make -k -j 1 CPU_COUNT=1 all
>>>
>>> Logfile attached.
>>
>> I see a single error. That's
David Kastrup writes:
> David Kastrup writes:
>
>> David Kastrup writes:
>>
>>>> autogen.sh --noconfigure
>>>> configure --prefix=/home/knut/sources/lilybisect/
>>>> make -k -j 1 CPU_COUNT=1 all
>>>>
>>>> Logfi
Knut Petersen writes:
> Am 25.06.2016 um 10:36 schrieb David Kastrup:
>> Ok, issue 4903 is now in master. What's the news on make -k output
>> now? Does applying the last patch (the one with ENGRAVER_INHERIT in
>> its title) make any difference in the amount of report
David Kastrup writes:
> Not with my current patch-in-progress. g++-4.8 seems to do some kind
> of "overloading resolution" by just randomly picking a candidate from
> several it fails to distinguish and then complaining when it does not
> fit. The errors I am getting
ke that?
Anything following the progress of typesetting has to run through
engraver-local variables and context properties.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
t runs like a complete drain, taking about two
> minutes to move between photos. The VM on 10.04 was instantaneous.
> No idea why this should be, but I got so p**sed of with it that I've
> ordered a new PC just for my photography.
Hope that someone els
27;ll likely go
after the problem if it persists. At the current point of time,
particularly with my somewhat weird 32/64-bit setup, that would be a lot
of effort.
I do think that GCC6 is rather bleeding-edge right now and I doubt you'd
find it in RedHat (which uses Fedora as sor
is by setting a property of the span
> event to the indicated context symbol; is that a reasonable approach?
Probably.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Urs Liska writes:
> Am 30.06.2016 um 11:52 schrieb David Kastrup:
>>> There is a detail I would like to clarify. David suggested allowing \=
>>> > to optionally specify the parent context in which a cross-voice
>>> > spanner's information is shared (altho
Urs Liska writes:
> Am 30.06.2016 um 14:05 schrieb David Kastrup:
>> Urs Liska writes:
>>
>>> Am 30.06.2016 um 11:52 schrieb David Kastrup:
>>>>> There is a detail I would like to clarify. David suggested allowing \=
>>>>>> to opt
Urs Liska writes:
> Am 30.06.2016 um 14:37 schrieb David Kastrup:
>
>> How does that differ from symbols?
>
> Ah, not in the Scheme domain, of course. But you can't *enter* them as
> LilyPond code, isn't it?
Can you give an example for symbols "entered as
Urs Liska writes:
> Am 30.06.2016 um 14:47 schrieb David Kastrup:
>> Urs Liska writes:
>>
>>> Am 30.06.2016 um 14:37 schrieb David Kastrup:
>>>
>>>> How does that differ from symbols?
>>> Ah, not in the Scheme domain, of course. But you can
ount of success here, I might be of little
availability in the next days.
Sorry for that.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
David Kastrup writes:
> Hi folks,
>
> it would appear that the graphics card on my laptop died on me. After
> an hour of black screen, it now managed to shut down and reboot in some
> low-resolution mode. I don't know how often I'll manage that however.
> I
somewhat cumbersome. I think that the expected
frequency of occurence is low enough that the overall balance between
obviousness and convenience looks favorable to me.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
d to be unique at some level. And
which level is better? Staff or Score?
Lots and lots of decisions which are actually best made in connection
with an actual score. And when they are written into the score, you
don't need to look them up or second-guess them.
--
David Kastrup
___
Nathan Chou writes:
> On Fri, Jul 1, 2016 at 12:48 AM, David Kastrup wrote:
>> But that means that you can no longer let people write individual parts
>> with several spanner ids independently even when there never is even
>> going to be any cross-Voice spanner. Spanner
Nathan Chou writes:
> On Tue, Jul 5, 2016 at 1:54 AM, David Kastrup wrote:
>> Nathan Chou writes:
>>> That is a good point; I might agree with spanner id's not being shared
>>> across voices if nothing has been indicated. To make this less
>>> tedious,
901 - 1000 of 1137 matches
Mail list logo
