Re: Creates a MIDI note length formatter (issue 5576062)
On Jan 31, 2012, at 8:48 AM, Marc Hohl wrote: > Am 29.01.2012 10:35, schrieb mts...@gmail.com: >> Reviewers: , >> >> Message: >> The idea here is to create a generic framework that allows for >> modifications to note lengths (i.e. swing) in the MIDI without having a >> typographical impact on the score. > Brilliant idea, from my rather amatheurish point of view! > > Regards, > > Marc > I nixed the patch because Xavier informed me that one could just create two separate score blocks, one for layout and one for midi. This makes it possible to feed different music to the two blocks, which solves the problem, so it's not necessary to touch the C++ code. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Creates a MIDI note length formatter (issue 5576062)
Am 29.01.2012 10:35, schrieb mts...@gmail.com: Reviewers: , Message: The idea here is to create a generic framework that allows for modifications to note lengths (i.e. swing) in the MIDI without having a typographical impact on the score. Brilliant idea, from my rather amatheurish point of view! Regards, Marc ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: wiki
On Mon, Jan 30, 2012 at 1:28 PM, Francisco Vila wrote: > Hello, > wiki.lilynet.net is up but looks tabula rasa. Yes, this is one of those things I've been procrastinating about for quite some time. I've been trying to upgrade the MediaWiki engine **and** the database format, and it turns out doing both at the same time is pretty tricky. But thanks for the push, I'm getting on it right now! Cheers, Valentin. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: @rlsrnamed{Name,Translation} translates also the name in the URI
Hello,
On 30 January 2012 21:27, Ralph Palmer wrote:
> On Sun, Jan 29, 2012 at 9:38 AM, Federico Bruni wrote:
>>
>> Got no answers on -devel, so I forward here (probably more appropriate
>> place).
>>
>> Thanks,
>> Federico
>>
>> Il 05/01/2012 13:44, Federico Bruni ha scritto:
>>>
>>> Issue 1721 reported that @rlsr{Name} keeps the text in english but
>>> translates the link in the translated manuals (no idea where the
>>> translation comes from).
>>> So it recommends to use @rlsrnamed{Name,Translation} instead.
>>>
>>> But it looks like @rlsrnamed is affected by the same bug.
>>>
>>> Looking through the log file of make doc I've found a lot of errors like
>>> this:
>>>
>>> WARNING: Unable to find node 'Hauteurs' in book snippets.
>>>
>>> (look at NR 1.1, you'll find a lot of these broken links)
>>>
>>> In general, go to the french NR and search for "Morceaux choisis :":
>>> you'll see that most of the links are broken.
>>>
>>> There are some exceptions, for example this works:
>>> http://lilypond.org/doc/v2.15/Documentation/notation/piano.fr.html
>>>
>>> (Claviers link down on the page)
>>>
>>> The syntax used is the same: @rlsrnamed{Name,Translation}.
>>> Putting a space after the comma makes any difference.
>>>
>>> I can't understand the reason of this weird behaviour.
>>> Can you please explain what's happening?
>>>
>>> Thanks,
>>> Federico
>
>
> Greetings, Federico and list members -
>
> This has been submitted as issue 2266 :
> http://code.google.com/p/lilypond/issues/detail?id=2266
>
> Ralph
>
>
So where does this leave
http://code.google.com/p/lilypond/issues/detail?id=1721?
Should we merge the two into this?
--
--
James
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: @rlsrnamed{Name,Translation} translates also the name in the URI
On Sun, Jan 29, 2012 at 9:38 AM, Federico Bruni wrote:
> Got no answers on -devel, so I forward here (probably more appropriate
> place).
>
> Thanks,
> Federico
>
> Il 05/01/2012 13:44, Federico Bruni ha scritto:
>
>> Issue 1721 reported that @rlsr{Name} keeps the text in english but
>> translates the link in the translated manuals (no idea where the
>> translation comes from).
>> So it recommends to use @rlsrnamed{Name,Translation} instead.
>>
>> But it looks like @rlsrnamed is affected by the same bug.
>>
>> Looking through the log file of make doc I've found a lot of errors like
>> this:
>>
>> WARNING: Unable to find node 'Hauteurs' in book snippets.
>>
>> (look at NR 1.1, you'll find a lot of these broken links)
>>
>> In general, go to the french NR and search for "Morceaux choisis :":
>> you'll see that most of the links are broken.
>>
>> There are some exceptions, for example this works:
>> http://lilypond.org/doc/v2.15/**Documentation/notation/piano.**fr.html
>>
>> (Claviers link down on the page)
>>
>> The syntax used is the same: @rlsrnamed{Name,Translation}.
>> Putting a space after the comma makes any difference.
>>
>> I can't understand the reason of this weird behaviour.
>> Can you please explain what's happening?
>>
>> Thanks,
>> Federico
>>
>
Greetings, Federico and list members -
This has been submitted as issue 2266 :
http://code.google.com/p/lilypond/issues/detail?id=2266
Ralph
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: a beaming regression?
2012/1/26 Janek Warchoł > Hi, > > i think the output of beam-shortened-lengths.ly doesn't look good, see > in current regtests > http://www.lilypond.org/doc/v2.15/input/regression/collated-files.html > . Am i missing something? > > cheers, > Janek > Thanks, Janek. I agree. It took me awhile to see : it took over 5 minutes to load the page. This has been submitted as issue 2265 : http://code.google.com/p/lilypond/issues/detail?id=2265 Ralph ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
2012/1/30 Graham Percival : > I think there's confusion between Patchy staging-merge and Patchy > test-patches. I don't feel confused at all, don't worry about it. >> i decided to pause my other Lily work and focus on improving >> Patchy and our development workflow. I took the approach of solving >> problem causes instead of symptoms: it takes more time, but its better >> in the long run. > > Yes, and that's valuable for the future. Had you added a "thank you", you'd have made me happy. (just stating a fact) >> I've spent about 30 hours on Patchy in the previous >> week despite exam season. Now i feel like a noob because i haven't >> finished a simple python script till Jan 29, and my 30 hours of work >> seem to be worthless. Great. > > I think you were working on the wrong problem -- a problem which > *will* be important in the future. I haven't yet set a date for > when I refuse to run test-patches yet, but I'm thinking about Feb > 14. since 90% of the code is shared, it doesn't make much sense to me to work on one part of Patchy at a time. > The time to panic about not knowing how to do those tasks is NOW, I assure that i'm panicking the most i can. A!, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
On Mon, Jan 30, 2012 at 06:56:08PM +0100, Janek Warchoł wrote: > 2012/1/30 Graham Percival : > > that's ALREADY how it works for the staging-merge. > > I guess i mean something different than you do when i say "everything > gets done automatically". I think there's confusion between Patchy staging-merge and Patchy test-patches. They share the "Patchy" name because 90% of the code is the same, but the staging-merge is a much easier, and much better-tested, task. > > I refuse. Jan 29 was the deadline; that deadline has passed. I > > will not be running the staging-merge. > > As you wish, but please note that this gets me very unmotivated to do > anything and continue my work. Following your plea for more > automation, and knowing about problems with Patchy that showed on > 2240, That's a problem with test-patches, not staging-merge. > i decided to pause my other Lily work and focus on improving > Patchy and our development workflow. I took the approach of solving > problem causes instead of symptoms: it takes more time, but its better > in the long run. Yes, and that's valuable for the future. > I've spent about 30 hours on Patchy in the previous > week despite exam season. Now i feel like a noob because i haven't > finished a simple python script till Jan 29, and my 30 hours of work > seem to be worthless. Great. I think you were working on the wrong problem -- a problem which *will* be important in the future. I haven't yet set a date for when I refuse to run test-patches yet, but I'm thinking about Feb 14. Why am I doing this? Because yelling about our bus factor and the problems of not automating things has not resulted in enough attention. If you doubt my yelling, check the email archives. I am very serious about potentially leaving for good at the end of March. That would leave a lot of "maintenance" tasks not getting done. And if I officially leave lilypond and somebody asks for help doing some maintenance task, I may not bother to reply. I make no guarantees. The time to panic about not knowing how to do those tasks is NOW, while I'm still available to give some guidance. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
> I reworded the text and changed the example. It should now be > clearer from both text and picture. Yes, thanks. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
- Original Message - From: "Janek Warchoł" To: "Graham Percival" Cc: "David Kastrup" ; Sent: Monday, January 30, 2012 5:56 PM Subject: Re: somebody needs to run staging before 29 Jan 2012/1/30 Graham Percival : On Mon, Jan 30, 2012 at 12:37:58PM +0100, Janek Warchoł wrote: 2012/1/29 David Kastrup : > So seriously: this needs to move to a different computer if LilyPond > development is of concern to you all. My work on Patchy (to make it more foolproof and more operator-friendly, i.e. 'run-a-script-and-everything-gets-done-automatically') that's ALREADY how it works for the staging-merge. I guess i mean something different than you do when i say "everything gets done automatically". will unfortunately take some more time; it's harder than i thought and i have to focus on my exams again. I estimate to finish it until 5 Feb - Graham, it would be great if you decided to run Patchy yourself a week longer. I refuse. Jan 29 was the deadline; that deadline has passed. I will not be running the staging-merge. As you wish, but please note that this gets me very unmotivated to do anything and continue my work. Following your plea for more automation, and knowing about problems with Patchy that showed on 2240, i decided to pause my other Lily work and focus on improving Patchy and our development workflow. I took the approach of solving problem causes instead of symptoms: it takes more time, but its better in the long run. I've spent about 30 hours on Patchy in the previous week despite exam season. Now i feel like a noob because i haven't finished a simple python script till Jan 29, and my 30 hours of work seem to be worthless. Great. Janek Keep going. I hope to have the current version working soon, and we then need to improve and document it. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
2012/1/30 Graham Percival : > On Mon, Jan 30, 2012 at 12:37:58PM +0100, Janek Warchoł wrote: >> 2012/1/29 David Kastrup : >> > So seriously: this needs to move to a different computer if LilyPond >> > development is of concern to you all. >> >> My work on Patchy (to make it more foolproof and more >> operator-friendly, i.e. >> 'run-a-script-and-everything-gets-done-automatically') > > that's ALREADY how it works for the staging-merge. I guess i mean something different than you do when i say "everything gets done automatically". >> will >> unfortunately take some more time; it's harder than i thought and i >> have to focus on my exams again. I estimate to finish it until 5 Feb >> - Graham, it would be great if you decided to run Patchy yourself a >> week longer. > > I refuse. Jan 29 was the deadline; that deadline has passed. I > will not be running the staging-merge. As you wish, but please note that this gets me very unmotivated to do anything and continue my work. Following your plea for more automation, and knowing about problems with Patchy that showed on 2240, i decided to pause my other Lily work and focus on improving Patchy and our development workflow. I took the approach of solving problem causes instead of symptoms: it takes more time, but its better in the long run. I've spent about 30 hours on Patchy in the previous week despite exam season. Now i feel like a noob because i haven't finished a simple python script till Jan 29, and my 30 hours of work seem to be worthless. Great. Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
Werner LEMBERG writes: >> Let me just quote one item by screenshot [...] > > This looks excellent. However, I don't understand the last sentence. > What do you mean with `not transferred'? I reworded the text and changed the example. It should now be clearer from both text and picture. <> -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
> Let me just quote one item by screenshot [...] This looks excellent. However, I don't understand the last sentence. What do you mean with `not transferred'? Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
On Mon, Jan 30, 2012 at 04:39:31PM +0100, David Kastrup wrote: > "Phil Holmes" writes: > > > My other current concern is to wonder whether lots of people trying to > > get patchy running might not collide with each other. I don't think so; once the first set of commits were pushed to master, I would expect that other people will just get a "non-fast-forwarding" reply when Patchy attempts to push to master. > > As I understand > > it, the key patchy function is to pull patches from staging, > > The current state of staging. It does not test individually. > > run make and make test, and check the regtest output. No regtest examination. It builds make, make test, and make doc, and if nothing fails -- using the make(1) definition of fails -- then it merges and pushes to master. > > If this is OK > > it sends a message saying "LGTM". Is this correct? > > Nope, it bounces master to staging (or recommends doing it, depending on > what Graham did). It bounces master to staging directly. It sends a personal mail saying it's done; if it fails, it sends a personal mail CC'd to -devel. But the mail can be dispensed with for the first few tests. > > Does it actually do any of the merging of patches from staging into > > master? I wouldn't want to do that without knowing I was doing > > it... (although my new user would presumably fail anyway, since I've > > not yet set it up for push access). Yes, but the whole point is that you don't need to know what you're doing. The script handles it (as long as your new user has git push access). - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
"Phil Holmes" writes: > My other current concern is to wonder whether lots of people trying to > get patchy running might not collide with each other. As I understand > it, the key patchy function is to pull patches from staging, The current state of staging. It does not test individually. > run make and make test, and check the regtest output. If this is OK > it sends a message saying "LGTM". Is this correct? Nope, it bounces master to staging (or recommends doing it, depending on what Graham did). > Does it actually do any of the merging of patches from staging into > master? I wouldn't want to do that without knowing I was doing > it... (although my new user would presumably fail anyway, since I've > not yet set it up for push access). It tries doing so. If parallel users try that, it will succeed for every one of them unless someone is trying to push something older than something that already got pushed. Or if his version of staging has been, in the mean time, replaced by something else that has been pushed instead. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
- Original Message - From: "Graham Percival" To: "Phil Holmes" Cc: ; "David Kastrup" Sent: Monday, January 30, 2012 1:40 PM Subject: Re: somebody needs to run staging before 29 Jan On Mon, Jan 30, 2012 at 01:35:24PM -, Phil Holmes wrote: Original Message - From: "David Kastrup" To: Sent: Monday, January 30, 2012 1:07 PM Subject: Re: somebody needs to run staging before 29 Jan >Nope. It uses whatever repository you specify in the LILYPOND_GIT >environment variable. But if I rely on other uses for the LILYPOND_GIT environment variable, then it must use my normal git stash. Strikes me it would be safer to have a duplicate stash just for patchy, and a different variable. Yes, I have patchy on a completely separate user. OK - just set one up and trying a test build. My other current concern is to wonder whether lots of people trying to get patchy running might not collide with each other. As I understand it, the key patchy function is to pull patches from staging, run make and make test, and check the regtest output. If this is OK it sends a message saying "LGTM". Is this correct? Does it actually do any of the merging of patches from staging into master? I wouldn't want to do that without knowing I was doing it... (although my new user would presumably fail anyway, since I've not yet set it up for push access). -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
Werner LEMBERG writes: >> [Applying rietveld 5595043 to git afb4c5fb] >> >>> It means running your own files that use this feature, and reading >>> the docs to see whether the docs as well as the new incarnation of >>> the feature make sense to you. >> >> It was really good that you have been a pain in the neck, since your >> patch causes rhythmic problems. [...] > > My piece looks fine now, thanks! Triplets are OK. No time to check > your documentation, though. Let me just quote one item by screenshot <> and suggest looking at input/regression/tablature-chord-repetition-finger.ly as this may save you some time afterwards. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
> [Applying rietveld 5595043 to git afb4c5fb] > >> It means running your own files that use this feature, and reading >> the docs to see whether the docs as well as the new incarnation of >> the feature make sense to you. > > It was really good that you have been a pain in the neck, since your > patch causes rhythmic problems. [...] My piece looks fine now, thanks! Triplets are OK. No time to check your documentation, though. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: avoiding forward declarations in stencil.hh
David Kastrup writes: > "m...@apollinemike.com" writes: > >> On Jan 30, 2012, at 2:49 PM, David Kastrup wrote: >> >>> logical impossibility >> >> This is all I needed to know - thanks! > > Well, it forces > sizeof(x) <= 2*sizeof(x) sizeof(x) >= 2*sizeof(x) of course. > and we know sizeof(x)>= 0, so it is not logically impossible as long as > the structure does not contain anything else beside two structures of > its own kind. > > But there won't be room for payload then. > > Using a pointer is ok, and SCM is kind of a pointer. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: avoiding forward declarations in stencil.hh
"m...@apollinemike.com" writes: > On Jan 30, 2012, at 2:49 PM, David Kastrup wrote: > >> logical impossibility > > This is all I needed to know - thanks! Well, it forces sizeof(x) <= 2*sizeof(x) and we know sizeof(x)>= 0, so it is not logically impossible as long as the structure does not contain anything else beside two structures of its own kind. But there won't be room for payload then. Using a pointer is ok, and SCM is kind of a pointer. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: avoiding forward declarations in stencil.hh
On Jan 30, 2012, at 2:49 PM, David Kastrup wrote: > logical impossibility This is all I needed to know - thanks! Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: avoiding forward declarations in stencil.hh
Graham Percival writes: > On Mon, Jan 30, 2012 at 12:56:50PM +0100, m...@apollinemike.com wrote: >> The problem is that the file in question is stencil.hh. >> I got around it by using Drul_array and having the drul >> arrayed populated with smobified stencils. > > I hope that my > 6e2e1d6a13aba88a3a8eecc0d46f96ad245c152a > didn't mess up anything? It would appear to me that Mike would have wanted to have each stencil contain as a part an array with two stencils (rather than pointers to them) in it. How the compiler chooses to object to this logical impossibility will depend on the exact code, but I don't think that this problem should be cause to worry. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
"Phil Holmes" writes: > Original Message - > From: "David Kastrup" > To: > Sent: Monday, January 30, 2012 1:07 PM > Subject: Re: somebody needs to run staging before 29 Jan > > >> "Phil Holmes" writes: >> >>> I assume it uses the "normal" git cache on my computer >> >> Nope. It uses whatever repository you specify in the LILYPOND_GIT >> environment variable. > > But if I rely on other uses for the LILYPOND_GIT environment variable, > then it must use my normal git stash. Strikes me it would be safer to > have a duplicate stash just for patchy, and a different variable. I have had my fingers on the respective code in the past. It uses the repository as a read-only resource, with the exception of a) running "git fetch" to get up-to-date branches b) creating and deleting branches called something like test-staging (so that you can reference later which "staging" was actually being tested) and something like test-master-lock which is both used as a lock to stop parallel instances of patchy to run, as well as a reference to the master at the start of the test run. Those separate branches are created right after running git fetch and are later used for pushing the results upstream if the results are ok. So no, there is little point in not using your main git "stash" for this. Apart from it being more up-to-date in its remote branches than you remember, and from two mysterious branches coming and going, it will not be affected. Most particularly your work directory and your checkouts are not being touched. This is for the staging patchy; the Rietveld patchy is a different beast yet. > In the scripts or in a config file? config file as well as LILYPOND_GIT environment variable. The scripts themselves do not appear to need changes. >> That is command for mailing the completion message somewhere. I have no >> idea what msmtp is supposed to be, but I replaced it with >> >>mail dak >> >> on my system. Which is not really what was intended, I guess, because >> it mailed a mail to me addressed to Graham and the developer list. >> msmtp would likely have bypassed me doing that. > > I don't have a mail account on that machine, so would need to > configure it to use my normal SMTP provider, but don't know how to do > that. I presume any old command taking standard input should to. Something like cat >> /tmp/patchy-completion-mails or so should likely work. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: avoiding forward declarations in stencil.hh
On Mon, Jan 30, 2012 at 12:56:50PM +0100, m...@apollinemike.com wrote:
> The problem is that the file in question is stencil.hh.
> I got around it by using Drul_array and having the drul
> arrayed populated with smobified stencils.
I hope that my
6e2e1d6a13aba88a3a8eecc0d46f96ad245c152a
didn't mess up anything?
Avoid deprecated access declarations
"According the ANSI/ISO Standard, the use of access
declarations
is considered deprecated. Instead, you should use a using
declaration for that purpose"
http://www.devx.com/tips/Tip/5707
-- flower/include/interval.hh
--
index 1ce6ac2..02bc791 100644
@@ -31,7 +31,7 @@
template
struct Interval_t : public Drul_array
{
- Drul_array::at;
+ using Drul_array::at;
static T infinity ();
static string T_to_string (T arg);
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
On Mon, Jan 30, 2012 at 01:35:24PM -, Phil Holmes wrote: > Original Message - From: "David Kastrup" > To: > Sent: Monday, January 30, 2012 1:07 PM > Subject: Re: somebody needs to run staging before 29 Jan > > >Nope. It uses whatever repository you specify in the LILYPOND_GIT > >environment variable. > > But if I rely on other uses for the LILYPOND_GIT environment > variable, then it must use my normal git stash. Strikes me it would > be safer to have a duplicate stash just for patchy, and a different > variable. Yes, I have patchy on a completely separate user. > >Configuration of the respective paths. > > In the scripts or in a config file? config file. > >>"smtp_command: msmtp -C ~/.msmtp-patchy -t" means nothing to me. > > > >on my system. Which is not really what was intended, I guess, because > >it mailed a mail to me addressed to Graham and the developer list. > >msmtp would likely have bypassed me doing that. > > I don't have a mail account on that machine, so would need to > configure it to use my normal SMTP provider, but don't know how to > do that. I happened to send instructions for this about 60 seconds ago. :) - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
On Mon, Jan 30, 2012 at 02:07:44PM +0100, David Kastrup wrote: > "Phil Holmes" writes: > > > "smtp_command: msmtp -C ~/.msmtp-patchy -t" means nothing to me. > > That is command for mailing the completion message somewhere. I have no > idea what msmtp is supposed to be, ah yes, I forgot about that. It's a replacement of smtp, specifically aimed at mutt users, but the mutt part is irrelevant. > on my system. Which is not really what was intended, I guess, because > it mailed a mail to me addressed to Graham and the developer list. > msmtp would likely have bypassed me doing that. err, yeah; I guess that part should be configurable, so staging-merge isn't completely finished. But at a pinch, one could just leave the smtp_command: blank, and then it won't do any mailing at all. I mean, that's sufficient to have the merge happening. For relevance, I have this: lily@gperciva-desktop:~$ more .msmtp-patchy account gmail host smtp.gmail.com port 587 auth on user lilypond.patchy.gra...@gmail.com password hunter2 tls on tls_trust_file /usr/share/ca-certificates/mozilla/Equifax_Secure_CA.crt from lilypond.patchy.gra...@gmail.com account default: gmail ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
Original Message - From: "David Kastrup" To: Sent: Monday, January 30, 2012 1:07 PM Subject: Re: somebody needs to run staging before 29 Jan "Phil Holmes" writes: I assume it uses the "normal" git cache on my computer Nope. It uses whatever repository you specify in the LILYPOND_GIT environment variable. But if I rely on other uses for the LILYPOND_GIT environment variable, then it must use my normal git stash. Strikes me it would be safer to have a duplicate stash just for patchy, and a different variable. - is there any danger if this is also my dev machine with other changed files in the git filesystem (e.g. the LSR copies, for example). Depends on what you specify in LILYPOND_GIT and the configuration file. My brief look at one of the scripts showed an expectation of using a RAMdisk. I'd rather use my SSD. Does this involve any changes? Configuration of the respective paths. In the scripts or in a config file? Please confirm which script should be the main "master" and what to look for when it's running. I don't quite understand what you are asking here, but presumably you mean lilypond-extra/patches/lilypond-patchy-staging.py or so. I think that's what I meant. "smtp_command: msmtp -C ~/.msmtp-patchy -t" means nothing to me. That is command for mailing the completion message somewhere. I have no idea what msmtp is supposed to be, but I replaced it with mail dak on my system. Which is not really what was intended, I guess, because it mailed a mail to me addressed to Graham and the developer list. msmtp would likely have bypassed me doing that. I don't have a mail account on that machine, so would need to configure it to use my normal SMTP provider, but don't know how to do that. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
On 2012-01-30 12:59, David Kastrup wrote: Graham Percival writes: On Mon, Jan 30, 2012 at 12:47:11PM +0100, David Kastrup wrote: The test-patches.py script can likely make use of the techniques in lilypond-patchy-staging.ly with regard to doing an offside build with a defined starting point not relying on whatever happens to be checked out in the main repository. Don't get confused here. Don't scare people away from doing the staging-merge by talking about test-patches.py. test-patches.py is a completely different problem than the staging merge. I agree that a solution for test-patches.py should be found, but that's not as urgent, nor as TRIVIALLY easy to fix, as the fact that you are the only person running the staging-merge at the moment. I am not sure what the problem is with anybody else running it. You call it, and it complains about LILYPOND_GIT not being set. Then you call LILYPOND_GIT=/usr/local/tmp/lilypond /usr/local/tmp/lilypond-extra/patches/lilypond-patchy-staging.py (assuming that your full repository copy is in /usr/local/tmp/lilypond) and it complains that the configuration in ~/.lilypond-patchy-config is wrong. You call a text editor and insert directories and paths suitable to your system in that file, and that is about it. I can run it regularly (i.e. a cron job) on my office machine (recently got a really fast quad-core system), which is up 24/7 and doesn't have too much load otherwise. I don't know how much time I'll have to set it up, though. Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial& Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
"Phil Holmes" writes: > I assume it uses the "normal" git cache on my computer Nope. It uses whatever repository you specify in the LILYPOND_GIT environment variable. > - is there any danger if this is also my dev machine with other > changed files in the git filesystem (e.g. the LSR copies, for > example). Depends on what you specify in LILYPOND_GIT and the configuration file. > My brief look at one of the scripts showed an expectation of using a > RAMdisk. I'd rather use my SSD. Does this involve any changes? Configuration of the respective paths. > Please confirm which script should be the main "master" and what to > look for when it's running. I don't quite understand what you are asking here, but presumably you mean lilypond-extra/patches/lilypond-patchy-staging.py or so. > "smtp_command: msmtp -C ~/.msmtp-patchy -t" means nothing to me. That is command for mailing the completion message somewhere. I have no idea what msmtp is supposed to be, but I replaced it with mail dak on my system. Which is not really what was intended, I guess, because it mailed a mail to me addressed to Graham and the developer list. msmtp would likely have bypassed me doing that. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
- Original Message - From: "Graham Percival" To: "David Kastrup" Cc: Sent: Monday, January 30, 2012 12:08 PM Subject: Re: somebody needs to run staging before 29 Jan On Mon, Jan 30, 2012 at 12:59:57PM +0100, David Kastrup wrote: Graham Percival writes: > Don't get confused here. Don't scare people away from doing the > staging-merge by talking about test-patches.py. I am not sure what the problem is with anybody else running it. ditto, other than the sheer "it's something I haven't done before" factor. Don't underestimate that: unix people have no problem running an unknown program and skimming the man page if necessary, but other people are reluctant to do this. You call it, and it complains about LILYPOND_GIT not being set. That's covered in the beginning of the CG now, and it's built-in to lilydev 2.0. (assuming that your full repository copy is in /usr/local/tmp/lilypond) and it complains that the configuration in ~/.lilypond-patchy-config is wrong. Yep. You call a text editor and insert directories and paths suitable to your system in that file, and that is about it. Yep. There is not much to make this easier or better discoverable short of adding a complete configuration program that will write the respective data. Yep. I have to admit to not even reading the CG here. Admittedly, none of the above is in the CG (other than the LILYPOND_GIT environment variable stuff). But really, it's just as you say: the instructions are pretty clear. I just ran the script that had a title suggesting it would do the right thing, and it apparently did after I addressed its rather clear complaints. Great! Hopefully somebody will see these emails and realize there's nothing to fear. - Graham I'll have a look later. But. I assume it uses the "normal" git cache on my computer - is there any danger if this is also my dev machine with other changed files in the git filesystem (e.g. the LSR copies, for example). My brief look at one of the scripts showed an expectation of using a RAMdisk. I'd rather use my SSD. Does this involve any changes? Please confirm which script should be the main "master" and what to look for when it's running. "smtp_command: msmtp -C ~/.msmtp-patchy -t" means nothing to me. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
wiki
Hello, wiki.lilynet.net is up but looks tabula rasa. -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Doc: NR @knownissues for margins w/paper-size (issue 5576063)
I'm not certain that these need to be inside @knownissues rather than the main portion of the doc, but it's not worth quibbling. Looks good enough to me. http://codereview.appspot.com/5576063/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: NR Section on Upbeats made clearer (issue 5520056)
LGTM http://codereview.appspot.com/5520056/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: NR added @knownissue for beam properties (issue 5504100)
LGTM http://codereview.appspot.com/5504100/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: NR 5.5.5 Adv tweaks - Unpure-pure containers (issue 5569050)
LGTM, although I don't understand any of the pure/unpure stuff. http://codereview.appspot.com/5569050/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
On Mon, Jan 30, 2012 at 12:59:57PM +0100, David Kastrup wrote: > Graham Percival writes: > > > Don't get confused here. Don't scare people away from doing the > > staging-merge by talking about test-patches.py. > > I am not sure what the problem is with anybody else running it. ditto, other than the sheer "it's something I haven't done before" factor. Don't underestimate that: unix people have no problem running an unknown program and skimming the man page if necessary, but other people are reluctant to do this. > You call it, and it complains about LILYPOND_GIT not being set. That's covered in the beginning of the CG now, and it's built-in to lilydev 2.0. > (assuming that your full repository copy is in /usr/local/tmp/lilypond) > and it complains that the configuration in ~/.lilypond-patchy-config is > wrong. Yep. > You call a text editor and insert directories and paths suitable > to your system in that file, and that is about it. Yep. > There is not much to make this easier or better discoverable short of > adding a complete configuration program that will write the respective > data. Yep. > I have to admit to not even reading the CG here. Admittedly, none of the above is in the CG (other than the LILYPOND_GIT environment variable stuff). But really, it's just as you say: the instructions are pretty clear. > I just ran the script > that had a title suggesting it would do the right thing, and it > apparently did after I addressed its rather clear complaints. Great! Hopefully somebody will see these emails and realize there's nothing to fear. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
Graham Percival writes: > On Mon, Jan 30, 2012 at 12:47:11PM +0100, David Kastrup wrote: >> The test-patches.py script can likely make use of the techniques in >> lilypond-patchy-staging.ly with regard to doing an offside build with a >> defined starting point not relying on whatever happens to be checked out >> in the main repository. > > Don't get confused here. Don't scare people away from doing the > staging-merge by talking about test-patches.py. > > test-patches.py is a completely different problem than the staging > merge. I agree that a solution for test-patches.py should be > found, but that's not as urgent, nor as TRIVIALLY easy to fix, as > the fact that you are the only person running the staging-merge at > the moment. I am not sure what the problem is with anybody else running it. You call it, and it complains about LILYPOND_GIT not being set. Then you call LILYPOND_GIT=/usr/local/tmp/lilypond /usr/local/tmp/lilypond-extra/patches/lilypond-patchy-staging.py (assuming that your full repository copy is in /usr/local/tmp/lilypond) and it complains that the configuration in ~/.lilypond-patchy-config is wrong. You call a text editor and insert directories and paths suitable to your system in that file, and that is about it. There is not much to make this easier or better discoverable short of adding a complete configuration program that will write the respective data. I have to admit to not even reading the CG here. I just ran the script that had a title suggesting it would do the right thing, and it apparently did after I addressed its rather clear complaints. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: avoiding forward declarations in stencil.hh
On Jan 30, 2012, at 12:39 PM, Han-Wen Nienhuys wrote:
> On Mon, Jan 30, 2012 at 6:54 AM, m...@apollinemike.com
> wrote:
>> Hey all,
>>
>> I'm doing some work on the stencil class and I have a programming question.
>>
>> I'm experimenting with the following code:
>>
>> class Stencil
>> {
>> Box dim_;
>> SCM expr_;
>> Drul_array children_;
>
>> ../flower/include/drul-array.hh: In instantiation of 'Drul_array':
>> ./include/stencil.hh:63: instantiated from here
>> ../flower/include/drul-array.hh:32: error: 'Drul_array::array_' has
>> incomplete type
>> ./include/stencil.hh:60: error: forward declaration of 'class Stencil'
>> make: *** [out/articulations.o] Error 1
>>
>> When I change the Drul_array to a vector, this problem goes away. I would,
>> however, like it to be a Drul_array (or even better, a pair, but pair gives
>> me the same forward declaration error as Drul_array). Does anyone know a
>> way to declare this thing correctly so that I don't get the forward
>> declaration error?
>
> It's not possible. A vector internally creates a pointer to X,
> which is why it doesn't need to know about X, but drul_array doesn't
> work like that.
>
> Just include stencil.hh and be done with it.
Thanks for the quick reply!
The problem is that the file in question is stencil.hh.
I got around it by using Drul_array and having the drul arrayed populated
with smobified stencils.
Cheers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
On Mon, Jan 30, 2012 at 12:47:11PM +0100, David Kastrup wrote: > The test-patches.py script can likely make use of the techniques in > lilypond-patchy-staging.ly with regard to doing an offside build with a > defined starting point not relying on whatever happens to be checked out > in the main repository. Don't get confused here. Don't scare people away from doing the staging-merge by talking about test-patches.py. test-patches.py is a completely different problem than the staging merge. I agree that a solution for test-patches.py should be found, but that's not as urgent, nor as TRIVIALLY easy to fix, as the fact that you are the only person running the staging-merge at the moment. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
On Mon, Jan 30, 2012 at 12:37:58PM +0100, Janek Warchoł wrote: > 2012/1/29 David Kastrup : > > So seriously: this needs to move to a different computer if LilyPond > > development is of concern to you all. > > My work on Patchy (to make it more foolproof and more > operator-friendly, i.e. > 'run-a-script-and-everything-gets-done-automatically') ... that's ALREADY how it works for the staging-merge. > will > unfortunately take some more time; it's harder than i thought and i > have to focus on my exams again. I estimate to finish it until 5 Feb > - Graham, it would be great if you decided to run Patchy yourself a > week longer. I refuse. Jan 29 was the deadline; that deadline has passed. I will not be running the staging-merge. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
Janek Warchoł writes: > 2012/1/29 David Kastrup : >> So seriously: this needs to move to a different computer if LilyPond >> development is of concern to you all. > > My work on Patchy (to make it more foolproof and more > operator-friendly, i.e. > 'run-a-script-and-everything-gets-done-automatically') will > unfortunately take some more time; it's harder than i thought and i > have to focus on my exams again. I estimate to finish it until 5 Feb > - Graham, it would be great if you decided to run Patchy yourself a > week longer. The test-patches.py script can likely make use of the techniques in lilypond-patchy-staging.ly with regard to doing an offside build with a defined starting point not relying on whatever happens to be checked out in the main repository. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: avoiding forward declarations in stencil.hh
On Mon, Jan 30, 2012 at 6:54 AM, m...@apollinemike.com
wrote:
> Hey all,
>
> I'm doing some work on the stencil class and I have a programming question.
>
> I'm experimenting with the following code:
>
> class Stencil
> {
> Box dim_;
> SCM expr_;
> Drul_array children_;
> ../flower/include/drul-array.hh: In instantiation of 'Drul_array':
> ./include/stencil.hh:63: instantiated from here
> ../flower/include/drul-array.hh:32: error: 'Drul_array::array_' has
> incomplete type
> ./include/stencil.hh:60: error: forward declaration of 'class Stencil'
> make: *** [out/articulations.o] Error 1
>
> When I change the Drul_array to a vector, this problem goes away. I would,
> however, like it to be a Drul_array (or even better, a pair, but pair gives
> me the same forward declaration error as Drul_array). Does anyone know a way
> to declare this thing correctly so that I don't get the forward declaration
> error?
It's not possible. A vector internally creates a pointer to X,
which is why it doesn't need to know about X, but drul_array doesn't
work like that.
Just include stencil.hh and be done with it.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
2012/1/29 David Kastrup : > So seriously: this needs to move to a different computer if LilyPond > development is of concern to you all. My work on Patchy (to make it more foolproof and more operator-friendly, i.e. 'run-a-script-and-everything-gets-done-automatically') will unfortunately take some more time; it's harder than i thought and i have to focus on my exams again. I estimate to finish it until 5 Feb - Graham, it would be great if you decided to run Patchy yourself a week longer. thanks, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reimplement ChordRepetition facility. (issue 5595043)
Reviewers: , http://codereview.appspot.com/5595043/diff/4020/input/regression/tablature-chord-repetition.ly File input/regression/tablature-chord-repetition.ly (right): http://codereview.appspot.com/5595043/diff/4020/input/regression/tablature-chord-repetition.ly#newcode5 input/regression/tablature-chord-repetition.ly:5: to save the string information. This setting is set as default with Ok, I am not happy about this showing up as a change in regtests because, uh, it is a changed regtest. So I'll retain the old copy, mentioning that it uses a deprecated interface, and create a new one under a different name that shows the new functionality/interface. Is that the way to do it? Description: Remove basically all configurability. Reduce parser and lexer support to hardwired minimum. Don't track the last chord in the lexer/parser. Instead establish it at toplevel-music-functions level if the user has not already called \chordRepeats to do so himself. Addresses issue 1110 and my sense of aesthetics. Please review this at http://codereview.appspot.com/5595043/ Affected files: M Documentation/changes.tely M Documentation/notation/fretted-strings.itely M Documentation/notation/simultaneous.itely A input/regression/chord-repetition-times.ly M input/regression/display-lily-tests.ly M input/regression/tablature-chord-repetition.ly M lily/include/lily-lexer.hh M lily/include/music-sequence.hh M lily/lexer.ll M lily/lily-lexer.cc M lily/lily-parser-scheme.cc M lily/music-sequence.cc M lily/parser.yy M ly/chord-repetition-init.ly M ly/music-functions-init.ly M scm/define-music-display-methods.scm M scm/define-music-types.scm M scm/ly-syntax-constructors.scm M scm/music-functions.scm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
avoiding forward declarations in stencil.hh
Hey all,
I'm doing some work on the stencil class and I have a programming question.
I'm experimenting with the following code:
class Stencil
{
Box dim_;
SCM expr_;
Drul_array children_;
etc...
}
and g++ gives me:
rm -f ./out/articulations.dep; DEPENDENCIES_OUTPUT="./out/articulations.dep
./out/articulations.o" g++ -c -Woverloaded-virtual -I/usr/include/python2.6
-I/usr/include/python2.6 -fno-strict-aliasing -g -fwrapv -DHAVE_CONFIG_H
-I./include -I./out -I../flower/include -I../flower/./out -I../flower/include
-g -pipe -pthread -I/usr/include/freetype2 -pthread -I/usr/include/pango-1.0
-I/usr/include/freetype2 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
-Wno-pmf-conversions -W -Wall -Wconversion -o out/articulations.o
articulations.cc
In file included from ../flower/include/interval.hh:26,
from ./include/lily-guile.hh:38,
from ./include/grob-info.hh:23,
from ./include/engraver.hh:23,
from articulations.cc:19:
../flower/include/drul-array.hh: In instantiation of 'Drul_array':
./include/stencil.hh:63: instantiated from here
../flower/include/drul-array.hh:32: error: 'Drul_array::array_' has
incomplete type
./include/stencil.hh:60: error: forward declaration of 'class Stencil'
make: *** [out/articulations.o] Error 1
When I change the Drul_array to a vector, this problem goes away. I would,
however, like it to be a Drul_array (or even better, a pair, but pair gives me
the same forward declaration error as Drul_array). Does anyone know a way to
declare this thing correctly so that I don't get the forward declaration error?
Cheers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
