Issue 4312057: shortened flags affair, part 8: choosing appropriate flag (Closed)
|
Created:
13 years, 1 month ago by Janek Warchol Modified:
12 years, 11 months ago Reviewers:
Visibility:
Public. |
Descriptionshortened flags affair, part 8: choosing appropriate flag
This is a first draft of the code that will choose appropriate flag and attach it to stem.
feta-flags.mf has changed structure - eventually there will be many (5-10) lengths of each flag.
I've added one shortened version of each flags; these are by no means ultimate
(their shape will depend on 'shortening' parameter much more) and their only purpose
is to test how c++ code works.
Patch Set 1 #Patch Set 2 : fix one indent #Patch Set 3 : font-size influenced flag variant chosen #Patch Set 4 : fix line width #Patch Set 5 : extracting flag lengths from font #
Total comments: 1
Patch Set 6 : fixed flag info extractor (array is now initialized!) #Patch Set 7 : some vectors. #Patch Set 8 : cleaning some trash #
Total comments: 1
MessagesTotal messages: 23
Hi, here comes the main part: code that chooses flags. I'm aware that it's quite imperfect. I'm working on it, however some problems are perhaps beyond my skills. Since i'll be busy after the weekend, it would be great if we were able to discuss and polish this as quickly as possible :) Opinions and pointers are much welcome! cheers, Janek PS The exact shapes of the shortened flags are yet to be discussed. I'll post them separately after this part is finished.
Sign in to reply to this message.
New patch set uploaded. Font size is now taken into account when calculating flag variants (one TODO eliminated). cheers, Janek
Sign in to reply to this message.
http://codereview.appspot.com/4312057/diff/10001/lily/stem.cc File lily/stem.cc (right): http://codereview.appspot.com/4312057/diff/10001/lily/stem.cc#newcode744 lily/stem.cc:744: flag_style = "standard"; Of course this will be properly encoded like other flag variants, as soon as i fint out how. The question is: should we use word "standard" or maybe "default" or "normal"? "standard" has one problem: it blends with direction ("standardu" looks acceptable, but "standardd" can be confusing at first sight.)
Sign in to reply to this message.
Sorry, i clicked "publish" button too fast. New patch set uploaded, 1 TODO partly eliminated. cheers, Janek
Sign in to reply to this message.
New patch set uploaded, minor bugfix.
Sign in to reply to this message.
New patch set uploaded. After a week of trying, there is probably nothing more that i can do. The code works, but could be easily improved by someone skillful. Any comments and help are welcome. cheers, Janek
Sign in to reply to this message.
Hey all, I don't have time for a few days to check this out in depth, but it definitely deserves to be read over & commented upon. Please review it if you can! Cheers, Mike
Sign in to reply to this message.
This patch loses flags! is that deliberate?! stem-tremolo.ly flags-default.ly beam-collision-beamcount.ly ... etc... Have you tried a regtest comparison? Please read this: http://lilypond.org/doc/v2.13/Documentation/contributor/regtest-comparison and let me know if you need help with any of these steps. (if this patch is still in the "gathering information" mode, then ok... but I would like that to be much more explicit that I should not be evaluating the patch for potential inclusion) http://codereview.appspot.com/4312057/diff/19001/lily/stem.cc File lily/stem.cc (right): http://codereview.appspot.com/4312057/diff/19001/lily/stem.cc#newcode615 lily/stem.cc:615: return (a>b); indent
Sign in to reply to this message.
2011/4/4 <percival.music.ca@gmail.com> > > This patch loses flags! is that deliberate?! > stem-tremolo.ly > flags-default.ly > beam-collision-beamcount.ly > ... etc... Did you "make clean" before building? There are some missing dependancies in the fonts, so "make clean" must be called at least in /mf directory, otherwise glyph names would not match what stem.cc expects. However, if you did this, and still some of the normal flags disappear, then i suppose it's a bug related to adding "standard" to the flag name (i.e. "flags.standardu5" instead of "flags.u5"). I will investigate and fix it, however i'd like to know what word should we use (maybe my comment in which i asked about it was lost?). The question is: should we use word "standard" or maybe "default" or "normal" (for regular flags)? Word "standard" has one problem: it blends with direction ("standardu" looks acceptable, but "standardd" can be confusing at first sight.). Also, i'm not sure which one has the best-fitting meaning. Maybe "regular"? > Have you tried a regtest comparison? Ooops! Sorry, i forgot about it. > Please read this: > http://lilypond.org/doc/v2.13/Documentation/contributor/regtest-comparison > and let me know if you need help with any of these steps. Regtests exit with an error, here's what i tried: git checkout master (a clone of origin/master, updated and without differencies) /build make clean /build make all /build make test-baseline (it ran without errors) changed branch to the one containing patches, also updated with git pull -r /build make clean /build make all /build make check It returned (...) Processing a2/lily-47d720ec Processing ed/lily-26c56735 Processing 6c/lily-1839e4ca Processing bc/liKilled command failed: /home/janek/lilypond-git/build/out/bin/lilypond -I /home/janek/lilypond-git/input/regression/ -I ./out-test -I /home/janek/lilypond-git/input -I /home/janek/lilypond-git/Documentation -I /home/janek/lilypond-git/Documentation/snippets -I /home/janek/lilypond-git/input/regression/ -I /home/janek/lilypond-git/Documentation/included/ -I /home/janek/lilypond-git/build/mf/out/ -I /home/janek/lilypond-git/build/mf/out/ -I /home/janek/lilypond-git/Documentation/pictures -I /home/janek/lilypond-git/build/Documentation/pictures/./out-test -dbackend=eps --formats=ps -dseparate-log-files -dinclude-eps-fonts -dgs-load-lily-fonts --header=texidoc -I /home/janek/lilypond-git/Documentation/included/ -ddump-profile -dcheck-internal-types -ddump-signatures -danti-alias-factor=1 -I "/home/janek/lilypond-git/build/out/lybook-testdb" -I "/home/janek/lilypond-git/build/input/regression" -I "/home/janek/lilypond-git/input/regression" -I "/home/janek/lilypond-git/build/input/regression/out-test" -I "/home/janek/lilypond-git/input" -I "/home/janek/lilypond-git/Documentation" -I "/home/janek/lilypond-git/Documentation/snippets" -I "/home/janek/lilypond-git/input/regression" -I "/home/janek/lilypond-git/Documentation/included" -I "/home/janek/lilypond-git/build/mf/out" -I "/home/janek/lilypond-git/build/mf/out" -I "/home/janek/lilypond-git/Documentation/pictures" -I "/home/janek/lilypond-git/build/Documentation/pictures/out-test" --formats=eps -deps-box-padding=3.000000 -dread-file-list -dno-strip-output-dir "/home/janek/lilypond-git/build/out/lybook-testdb/snippet-names-1446493823.ly" Child returned 137 make[2]: *** [out-test/collated-files.texi] Error 1 make[2]: Leaving directory `/home/janek/lilypond-git/build/input/regression' make[1]: *** [local-test] Error 2 make[1]: Leaving directory `/home/janek/lilypond-git/build/input/regression' make: *** [test] Error 2 I don't see anything special in lily-1839e4ca (if i understand correctly, it contains a regtest named grace-nest5.ly). When i tried compiling grace-nest5.ly separately, there were no problems. > (if this patch is still in the "gathering information" mode, then ok... > but I would like that to be much more explicit that I should not be > evaluating the patch for potential inclusion) Sorry for that. I though that patch_review meant that it's time that other people see this and give their opinions, not necessarily that the patch is ready for including. I was puzzled and worried why there were no reviews for a whole week and thought that maybe needs_work label was the cause. > http://codereview.appspot.com/4312057/diff/19001/lily/stem.cc > File lily/stem.cc (right): > > http://codereview.appspot.com/4312057/diff/19001/lily/stem.cc#newcode615 > lily/stem.cc:615: return (a>b); > indent Fixed. > http://codereview.appspot.com/4312057/ thanks, Janek
Sign in to reply to this message.
On Mon, Apr 04, 2011 at 10:51:16AM +0200, Janek Warchoł wrote: > 2011/4/4 <percival.music.ca@gmail.com> > > > > This patch loses flags! is that deliberate?! > > stem-tremolo.ly > > flags-default.ly > > beam-collision-beamcount.ly > > ... etc... > > Did you "make clean" before building? No, sorry! My fault. I'll check this again. > The > question is: should we use word "standard" or maybe "default" or > "normal" (for regular flags)? Word "standard" has one problem: it > blends with direction ("standardu" looks acceptable, but "standardd" > can be confusing at first sight.). Also, i'm not sure which one has > the best-fitting meaning. Maybe "regular"? I'd go with "normal". > Sorry for that. I though that patch_review meant that it's time that > other people see this and give their opinions, not necessarily that > the patch is ready for including. > I was puzzled and worried why there were no reviews for a whole week > and thought that maybe needs_work label was the cause. Ah. Well, unfortunately we (as a developer community) do not tend to review patches very often. Think about it this way: how many times have you reviewed my build system patches, or Colin's documentation patches? The same reasons why you don't review those patches apply to people looking at your patches. I have some plans to improve this, but like all our "social problems", I'm waiting until 2.14 is out first. Cheers, - Graham
Sign in to reply to this message.
The latest patch dies badly when trying to compile flags-in-scheme.ly programming error: ignoring weird minimum distance continuing, cross fingers ... repeated tons and tons of times... terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc Aborted I think this means that with this patch, lilypond uses up more memory than my machine has? Since I've got 4gigs RAM, plus 8 gigs of swap, that's a problem. :) Try compiling input/regression/flags-in-scheme.ly yourself. Once you've fixed that problem, try: make test to compile all the regtests. If that succeeds, then try the regtest comparison.
Sign in to reply to this message.
2011/4/4 Graham Percival <graham@percival-music.ca> > Ah. Well, unfortunately we (as a developer community) do not tend > to review patches very often. > > Think about it this way: how many times have you reviewed my build > system patches, or Colin's documentation patches? The same > reasons why you don't review those patches apply to people looking > at your patches. Perhaps... However seasoned developers can understand my patches while i (mostly) cannot understand their patches, so i quite cannot review them. > I have some plans to improve this, but like all our "social > problems", I'm waiting until 2.14 is out first. ok. 2011/4/5 <percival.music.ca@gmail.com> > > The latest patch dies badly when trying to compile flags-in-scheme.ly > > programming error: ignoring weird minimum distance > continuing, cross fingers > ... repeated tons and tons of times... > > Try compiling input/regression/flags-in-scheme.ly yourself. Yes, i see it too. I tried to fix it by proper implementation of "normal" as the default flag-style. However, i failed (perhaps because i don't understand scheme). I attach my attempt - it doesn't work at all and i don't know why. May i ask for some help with this? Did i at least found all files that need changes? As a last resort, i can drop using "normal" prefix for default flags, but this would mean less elegant and flexible code. thanks, Janek
Sign in to reply to this message.
On Wed, Apr 06, 2011 at 10:36:15AM +0200, Janek Warchoł wrote: > 2011/4/4 Graham Percival <graham@percival-music.ca> > > Think about it this way: how many times have you reviewed my build > > system patches, or Colin's documentation patches? The same > > reasons why you don't review those patches apply to people looking > > at your patches. > > Perhaps... However seasoned developers can understand my patches while > i (mostly) cannot understand their patches, so i quite cannot review > them. You severely over-estimate either the number of "seasoned developers", or the skill of most people on this mailing list. There are between 3 and 7 people in the world who know this flag stuff as well as you do. The same goes for virtually every aspect of lilypond. There are very few actual "seasoned" developers, and most of those are very busy with other things in their lives. We all need to collectively stop feeling inferior, and start giving each other whatever support we can give. If that means spending a few minutes reading a patch and saying "wow, looks complicated" or asking "silly" questions, then that's fine! Any feedback on a patch is better than none. > May i ask for some help with this? I can give general advice on programming, not anything specific to this: find the smallest change which produces this problem. If you try to compile that file with git master, it should work with no problems. Great! Now try making *one* change to the C++ file. Did that change break it? If so, then you've found the suspicious line. If that change didn't break it, then undo that change and make a different one. Or, if the change actually does any useful functionality, then get that really-small-but-working change accepted and pushed, before working on the rest of the changes. Cheers, - Graham
Sign in to reply to this message.
Hi all, 2011/4/7 Graham Percival <graham@percival-music.ca> > > On Wed, Apr 06, 2011 at 10:36:15AM +0200, Janek Warchoł wrote: > > 2011/4/4 Graham Percival <graham@percival-music.ca> > > > Think about it this way: how many times have you reviewed my build > > > system patches, or Colin's documentation patches? The same > > > reasons why you don't review those patches apply to people looking > > > at your patches. > > > > Perhaps... However seasoned developers can understand my patches while > > i (mostly) cannot understand their patches, so i quite cannot review > > them. > > You severely over-estimate either the number of "seasoned > developers", or the skill of most people on this mailing list. > There are between 3 and 7 people in the world who know this flag > stuff as well as you do. > > The same goes for virtually every aspect of lilypond. There are > very few actual "seasoned" developers, and most of those are very > busy with other things in their lives. We all need to > collectively stop feeling inferior, and start giving each other > whatever support we can give. If that means spending a few > minutes reading a patch and saying "wow, looks complicated" or > asking "silly" questions, then that's fine! Any feedback on a > patch is better than none. Ok, i'll start reviewing other people's patches right after this shortened flags stuff is finished. > > May i ask for some help with this? > > I can give general advice on programming, not anything specific to > this: find the smallest change which produces this problem. > > If you try to compile that file with git master, it should work > with no problems. Great! Now try making *one* change to the C++ > file. Did that change break it? If so, then you've found the > suspicious line. If that change didn't break it, then undo that > change and make a different one. Or, if the change actually does > any useful functionality, then get that really-small-but-working > change accepted and pushed, before working on the rest of the > changes. Thanks, however the problem is that i don't know what i'm doing at all. I don't know scheme. Trying to modify scheme code is to me like trying to translate a sentence from one language i don't know into another language i don't know. I had tried to do this nevertheless, because it might have worked by luck. It didn't. I've send that patch to show that i did try to do this myself. We are a team. Teamwork doesn't just mean having many people at work, it means helping each other - i don't have to remind you, you surely know this. I know there are people here who could have written all the stuff i did in an hour (maybe two) and have it pushed before Lent started, while for me it required days of work over 3-months period. Nevertheless i did what i could, because you're not here to fulfill my wishes. But i know my limits: now i've reached the limit of my skill and, more importantly, the limit of my psychical stength. I'm too tired to continue trying to do things that i don't know how to do. I ask for help and i hope that someone would take 15 minutes necessary to get things going here. I've done some fixes and the code passes the regtests. I'll open a new Rietveld issue with it in a few minutes; issue 4312057 becomes obsolete now. cheers, Janek
Sign in to reply to this message.
On Fri, Apr 15, 2011 at 01:07:02AM +0200, Janek Warchoł wrote: > Hi all, > > 2011/4/7 Graham Percival <graham@percival-music.ca> > > You severely over-estimate either the number of "seasoned > > developers", or the skill of most people on this mailing list. ... > > The same goes for virtually every aspect of lilypond. There are > > very few actual "seasoned" developers, and most of those are very > > busy with other things in their lives. > We are a team. Teamwork doesn't just mean having many people at work, > it means helping each other - i don't have to remind you, you surely > know this. Absolutely! But the development community has a very huge problem: - the very skilled members generally have full-time jobs and familes. - it takes about 5 hours a week simply to keep "up to date" with the various lilypond mailing lists. - lilypond is a hobby, and some people only want to spend 2 or 3 hours a week on such a hobby. I am allocating almost all of my 10 hours a week to reducing the amount of time that it takes to keep informed. We can do much better in this regard. Main points are: - bug squad + issue tracker, so that programmers don't need to look at user emails. Also updating issues with discussions on -devel, so that in case nothing gets finished for months, a programmer can quickly get "up to date" by reading the material in (or linked from) the issue tracker - organizing patches, including the "patch countdown" annoucements. Note that both of these points require little or no technical ability. Non-technically-skilled users can help tremendously with these points. And if we can reduce the time it takes to read emails from 5 hours a week to 3 hours a week, that allows programmers to spend more time programming or helping each other. > But i know my limits: now i've reached the limit of my skill > and, more importantly, the limit of my psychical stength. I'm too > tired to continue trying to do things that i don't know how to do. > I ask for help and i hope that someone would take 15 minutes necessary > to get things going here. Right. The main problem for you is: - you need a mentor. Somebody who can guide you through the steps, encourage you, and investigate if you get truly stuck. Unfortunately, Mike Solomon is the only programmer who has offered to mentor people, and IIRC he's paired up with Benko Pal. There is no simple solution to these problems. Cheers, - Graham
Sign in to reply to this message.
2011/4/15 Graham Percival <graham@percival-music.ca>: > On Fri, Apr 15, 2011 at 01:07:02AM +0200, Janek Warchoł wrote: >> Hi all, >> >> 2011/4/7 Graham Percival <graham@percival-music.ca> >> > You severely over-estimate either the number of "seasoned >> > developers", or the skill of most people on this mailing list. > ... >> > The same goes for virtually every aspect of lilypond. There are >> > very few actual "seasoned" developers, and most of those are very >> > busy with other things in their lives. > >> We are a team. Teamwork doesn't just mean having many people at work, >> it means helping each other - i don't have to remind you, you surely >> know this. > > Absolutely! > > But the development community has a very huge problem: > - the very skilled members generally have full-time jobs and > familes. > - it takes about 5 hours a week simply to keep "up to date" > with the various lilypond mailing lists. > - lilypond is a hobby, and some people only want to spend 2 or 3 > hours a week on such a hobby. > > I am allocating almost all of my 10 hours a week to reducing the > amount of time that it takes to keep informed. We can do much > better in this regard. Main points are: > - bug squad + issue tracker, so that programmers don't need to > look at user emails. Also updating issues with discussions > on -devel, so that in case nothing gets finished for months, > a programmer can quickly get "up to date" by reading the > material in (or linked from) the issue tracker > - organizing patches, including the "patch countdown" > annoucements. I can help with this as soon as i regain my Lilypond enthusiasm (estimated to happen after finishing shortened flags). > Note that both of these points require little or no technical > ability. Non-technically-skilled users can help tremendously with > these points. And if we can reduce the time it takes to read > emails from 5 hours a week to 3 hours a week, that allows > programmers to spend more time programming or helping each other. I have an idea concerning this, should i wait for GOP or start a discussion? >> But i know my limits: now i've reached the limit of my skill >> and, more importantly, the limit of my psychical stength. I'm too >> tired to continue trying to do things that i don't know how to do. >> I ask for help and i hope that someone would take 15 minutes necessary >> to get things going here. > > Right. The main problem for you is: > - you need a mentor. Somebody who can guide you through the > steps, encourage you, and investigate if you get truly stuck. > > Unfortunately, Mike Solomon is the only programmer who has offered > to mentor people, and IIRC he's paired up with Benko Pal. Mike is also my mentor, see your mail "contributors / mentors" from 22 II. Unfortunately, he has been busy since April 3rd and said he will remain busy until next thursday. Nevertheless, without his help i would be much farther form finishing than i am now. Since my new patch passes regtests, can you change http://code.google.com/p/lilypond/issues/detail?id=1582 status to patch_review? Janek
Sign in to reply to this message.
On Fri, Apr 15, 2011 at 11:17:23PM +0200, Janek Warchoł wrote: > 2011/4/15 Graham Percival <graham@percival-music.ca>: > > Note that both of these points require little or no technical > > ability. Non-technically-skilled users can help tremendously with > > these points. And if we can reduce the time it takes to read > > emails from 5 hours a week to 3 hours a week, that allows > > programmers to spend more time programming or helping each other. > > I have an idea concerning this, should i wait for GOP or start a discussion? Send it to me privately, and I'll add it to the GOP list. With this branching, we have more than enough vague policy discussions on -devel at the moment. > > Right. The main problem for you is: > > - you need a mentor. Somebody who can guide you through the > > steps, encourage you, and investigate if you get truly stuck. > > > > Unfortunately, Mike Solomon is the only programmer who has offered > > to mentor people, and IIRC he's paired up with Benko Pal. > > Mike is also my mentor, see your mail "contributors / mentors" from 22 > II. Unfortunately, he has been busy since April 3rd and said he will > remain busy until next thursday. In that case, I think that you're guilty of not following the contributor's responsibilities: http://lilypond.org/doc/v2.13/Documentation/contributor/mentors Namely, points 2 and 3. I agree that it's unfortunate that you need to wait until he's not busy, but those guidelines are there to protect you. At the moment, you're disappointed, frustrated, and you feel like you've wasted a lot of time and effort. I would rather have new contributors feeling impatient to hear back from their mentors, rather than wasting a lot of effort. There are lots of tasks that need to be done, so if you *are* stuck waiting for a week or two for your mentor, you could try doing some other task? Cheers, - Graham
Sign in to reply to this message.
2011/4/16 Graham Percival <graham@percival-music.ca> > > On Fri, Apr 15, 2011 at 11:17:23PM +0200, Janek Warchoł wrote: > > 2011/4/15 Graham Percival <graham@percival-music.ca>: > > > Note that both of these points require little or no technical > > > ability. Non-technically-skilled users can help tremendously with > > > these points. And if we can reduce the time it takes to read > > > emails from 5 hours a week to 3 hours a week, that allows > > > programmers to spend more time programming or helping each other. > > > > I have an idea concerning this, should i wait for GOP or start a discussion? > > Send it to me privately, and I'll add it to the GOP list. With > this branching, we have more than enough vague policy discussions > on -devel at the moment. ok. > > > Right. The main problem for you is: > > > - you need a mentor. Somebody who can guide you through the > > > steps, encourage you, and investigate if you get truly stuck. > > > > > > Unfortunately, Mike Solomon is the only programmer who has offered > > > to mentor people, and IIRC he's paired up with Benko Pal. > > > > Mike is also my mentor, see your mail "contributors / mentors" from 22 > > II. Unfortunately, he has been busy since April 3rd and said he will > > remain busy until next thursday. > > In that case, I think that you're guilty of not following the > contributor's responsibilities: > http://lilypond.org/doc/v2.13/Documentation/contributor/mentors > Namely, points 2 Poor Mike, i'd flood him totally if i obeyed this rule. > and 3. I'm not sure if this would really help. However, i could have tried. > I agree that it's unfortunate that you need to wait until he's not > busy, but those guidelines are there to protect you. At the > moment, you're disappointed, frustrated, and you feel like you've > wasted a lot of time and effort. I would rather have new > contributors feeling impatient to hear back from their mentors, > rather than wasting a lot of effort. > > There are lots of tasks that need to be done, so if you *are* > stuck waiting for a week or two for your mentor, you could try > doing some other task? Like attached one? cheers, Janek
Sign in to reply to this message.
2011/4/16 Janek Warchoł <lemniskata.bernoullego@gmail.com>: > 2011/4/16 Graham Percival <graham@percival-music.ca> >> There are lots of tasks that need to be done, so if you *are* >> stuck waiting for a week or two for your mentor, you could try >> doing some other task? > > Like attached one? Oh wait! it was already added as CG 12.6 building an Ubuntu distro - not in unsorted policies. So issue 1453 is invalid/fixed. That rings a bell. Since my patch had slightly better style, maybe let's not waste it completely and instead change it into attached one. What say you? cheers, Janek
Sign in to reply to this message.
On Sat, Apr 16, 2011 at 10:26:03PM +0200, Janek Warchoł wrote: > 2011/4/16 Janek Warchoł <lemniskata.bernoullego@gmail.com>: > > Like attached one? > > Oh wait! it was already added as CG 12.6 building an Ubuntu distro - > not in unsorted policies. So issue 1453 is invalid/fixed. > That rings a bell. ouch, Phil should have known better. Sorry about this. :( > Since my patch had slightly better style, maybe let's not waste it > completely and instead change it into attached one. Sure, thanks. Pushed. Cheers, - Graham
Sign in to reply to this message.
2011/4/17 Graham Percival <graham@percival-music.ca> > > On Sat, Apr 16, 2011 at 10:26:03PM +0200, Janek Warchoł wrote: > > 2011/4/16 Janek Warchoł <lemniskata.bernoullego@gmail.com>: > > > Like attached one? > > > > Oh wait! it was already added as CG 12.6 building an Ubuntu distro - > > not in unsorted policies. So issue 1453 is invalid/fixed. > > That rings a bell. > > ouch, Phil should have known better. Sorry about this. :( meh... If you are curious about why i twice did try to pick up and fix an issue without any questions and discussion, it was partly because of http://percival-music.ca/blogfiles/sustainable.pdf (page 24, "net gain to the project"). Unfortunately i was unlucky and now i don't trust our issue tracker (i'm just stating a fact). This is also the reason why i didn't ask questions "every 10 minutes": i didn't want to spend advanced developers' precious time until i really got stuck and really required help to proceed - hoping that developers would be grateful for not wasting their time and express this by responsing promptly when i finally asked for help. As we have seen, this didn't work... > > Since my patch had slightly better style, maybe let's not waste it > > completely and instead change it into attached one. > > Sure, thanks. Pushed. some success at last. cheers, Janek
Sign in to reply to this message.
I believe that this particular issue has been pushed -- could you officially close it? Click on "edit" in on the left-hand side of the codereview interface.
Sign in to reply to this message.
2011/6/8 <percival.music.ca@gmail.com>: > I believe that this particular issue has been pushed No, it wasn't. Actually, it was discarded (because of mess and/or my problems with git, i don't remember now); http://codereview.appspot.com/4410049/ is what matters now in the topic of shortened flags. > -- could you > officially close it? Click on "edit" in on the left-hand side of the > codereview interface. Done.
Sign in to reply to this message.
|
