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
