Urs On 19/11/15 14:09, Urs Liska wrote: > Hi James, > > thanks for the explanations. > > No, I don't know about an Allura account. Or were they automatically > copied over from the Google tracker, the Rietveld tool or the LilyPond > Git repository? > > Thanks > Urs
Send an email to Trevor or Phil, they can set you up with one. James > > Am 19.11.2015 um 15:06 schrieb James: >> Urs, >> >> run git-cl config again (make sure you have recently pulled as there >> were some fixes). >> >> The Allura Server URL is >> >> https://sourceforge.net/p/testlilyissues/issues/] >> >> You then need to set up a token in your Allura Login 'account settings' >> (you have a login to that site right?), select the Oauth tab and create >> your own 'Bearer token' - it should be obvious how to do that. Then you >> can use that value as the final entry for your git-cl config when it >> asks you for it. >> >> Now it should all work, >> >> James >> >> >> >> >> >> The Allura Server URL is >> >> On 19/11/15 13:57, Urs Liska wrote: >>> I've implemented a fix for this (hey, my first working C++ patch :-) ) >>> but now I'm stumbling over the new git-cl workflow (sorry, when that was >>> set up I didn't have the time to follow closely enough, and the CG >>> section on uploading patches doesn't seem to be updated yet). >>> >>> I manage to do the web authentication and upload the patch to Rietveld, >>> but got stuck at >>> >>> ``` >>> Issue created. URL: http://codereview.appspot.com/278060043 >>> Uploading base file for lily/beaming-pattern.cc >>> This has been identified with issue 4355. >>> Is this correct? [y/n (y)]n >>> 4355 will not be used as a google tracker number. >>> Please enter a valid google tracker issue number >>> (or enter nothing to create a new issue): >>> Command "git config allura.token" failed. >>> You must configure your review setup by running "git cl config". >>> uliska@uliska-lmde-laptop:~/git/lilypond/source$ git cl config >>> Rietveld server (host[:port]) [codereview.appspot.com]: >>> Allura server []: >>> You must provide the address of the Allura tracker server: >>> ``` >>> >>> What should I do now? >>> >>> Urs >>> >>> >>> Am 19.11.2015 um 10:43 schrieb Urs Liska: >>>> Since the fix for #4355, respectively commits 8fa2d858 and 0382ed88, it >>>> is not possible anymore to subdivide beams that are longer than a >>>> quarter note. >>>> >>>> \version "2.19.32" >>>> >>>> { >>>> \set subdivideBeams = ##t >>>> % This is correctly subdivided >>>> \set baseMoment = #(ly:make-moment 1 8) >>>> \repeat unfold 16 c'16 >>>> >>>> % This should always keep one beam >>>> \set baseMoment = #(ly:make-moment 1 4) >>>> c' 16 [ \repeat unfold 14 c' c' ] >>>> >>>> } >>>> >>>> The behaviour is consistent with the feature request for #4355, namely: >>>> the dividing beam should reflect the length of the following group, >>>> which is 1/4 and results in no beam. >>>> >>>> However, I think that this behaviour should be changed once more in that >>>> subdivideBeam leaves *at least* one beam. >>>> >>>> I admit I don't understand the modified code as per 0382ed88: >>>> >>>> // Set the count on each side of the stem >>>> // We need to run this code twice to make both the >>>> // left and the right counts work properly >>>> for (int i = 0; i < 2; i++) >>>> for (vsize i = 1; i < infos_.size () - 1; i++) >>>> { >>>> Direction non_flag_dir = other_dir (flag_directions[i]); >>>> if (non_flag_dir) >>>> { >>>> int importance = infos_[i + 1].rhythmic_importance_; >>>> int count = (importance < 0 && options.subdivide_beams_) >>>> ? subdivide_beam_count >>>> : min (min (infos_[i].count (non_flag_dir), >>>> infos_[i + non_flag_dir].count >>>> (-non_flag_dir)), >>>> infos_[i - non_flag_dir].count >>>> (non_flag_dir)); >>>> >>>> infos_[i].beam_count_drul_[non_flag_dir] = count; >>>> } >>>> } >>>> >>>> so I don't know whether it would be better to >>>> - only consider values smaller than 1/4 in the calculation or >>>> - ensure (in the last line?) that at least one beam is left. >>>> >>>> I hope this is an easy fix. >>>> >>>> Urs >>>> >>>> _______________________________________________ >>>> bug-lilypond mailing list >>>> bug-lilyp...@gnu.org >>>> https://lists.gnu.org/mailman/listinfo/bug-lilypond >>> _______________________________________________ >>> bug-lilypond mailing list >>> bug-lilyp...@gnu.org >>> https://lists.gnu.org/mailman/listinfo/bug-lilypond >>> >>> > > _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
