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 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
