Don't hardcode a limited set of markup signatures. (issue969046)

just a quick look http://codereview.appspot.com/969046/diff/2001/3002 File lily/lexer.ll (right): http://codereview.appspot.com/969046/diff/2001/3002#newcode542 lily/lexer.ll:542: yylval.scm = scm_car(s); can you document the contents of s in a comment here, for old farts like me that forgot ho

Re: Don't hardcode a limited set of markup signatures. (issue969046)

Reviewers: hanwenn, http://codereview.appspot.com/969046/diff/2001/3002 File lily/lexer.ll (right): http://codereview.appspot.com/969046/diff/2001/3002#newcode542 lily/lexer.ll:542: yylval.scm = scm_car(s); On 2010/05/01 17:13:32, hanwenn wrote: can you document the contents of s in a comment

Re: Don't hardcode a limited set of markup signatures. (issue969046)

http://codereview.appspot.com/969046/diff/7001/8002 File lily/lexer.ll (right): http://codereview.appspot.com/969046/diff/7001/8002#newcode545 lily/lexer.ll:545: // loop will be EXPECT_NO_MORE_ARGS. wouldnt it be clearer to have a function void translate_markup_signature(SCM predicate_list,

Re: Don't hardcode a limited set of markup signatures. (issue969046)

http://codereview.appspot.com/969046/diff/7001/8002 File lily/lexer.ll (right): http://codereview.appspot.com/969046/diff/7001/8002#newcode545 lily/lexer.ll:545: // loop will be EXPECT_NO_MORE_ARGS. On 2010/05/01 19:56:08, hanwenn wrote: wouldnt it be clearer to have a function void trans

Re: Don't hardcode a limited set of markup signatures. (issue969046)

On Sun, May 2, 2010 at 8:04 AM, wrote: > > http://codereview.appspot.com/969046/diff/7001/8002 > File lily/lexer.ll (right): > > http://codereview.appspot.com/969046/diff/7001/8002#newcode545 > lily/lexer.ll:545: // loop will be EXPECT_NO_MORE_ARGS. > On 2010/05/01 19:56:08, hanwenn wrote: >> >>

Re: Don't hardcode a limited set of markup signatures. (issue969046)

Han-Wen Nienhuys writes: > On Sun, May 2, 2010 at 8:04 AM, wrote: >> >> The tokens _are_ pushed one by one in the desired order.  So it makes >> no sense to allocate additional storage just to do the same job. > > This is not about saving storage. This block of code does 2 things: > > - transla

Re: Don't hardcode a limited set of markup signatures. (issue969046)

Han-Wen Nienhuys writes: > ideally, this would be broken up in two separate blocks of code, so we > dont have one 70 line block of code, which suggests that something > much more complicated is going on. There were _37_ lines of code (please don't count comment lines _against_ me) that do a more

Re: Don't hardcode a limited set of markup signatures. (issue969046)

On Sun, May 2, 2010 at 2:14 PM, David Kastrup wrote: > Han-Wen Nienhuys writes: > >> On Sun, May 2, 2010 at 8:04 AM,   wrote: >>> >>> The tokens _are_ pushed one by one in the desired order.  So it makes >>> no sense to allocate additional storage just to do the same job. >> >> This is not about

Re: Don't hardcode a limited set of markup signatures. (issue969046)

Han-Wen Nienhuys writes: > I apologise - I opened the page again, and expected it to always show > the latest patch set, which it didn't obviously. That, coupled with a > lengthy explanation of about using state machines made assume > erroneously that you did not change the .ll code The explanat

Re: Don't hardcode a limited set of markup signatures. (issue969046)

On Sun, May 2, 2010 at 6:19 PM, David Kastrup wrote: >> For one reason or another, whenever I review code from you it degrades >> into a fight. I am not quite sure why this always happens. > > Because you don't bother taking the contributions of other people > seriously.  You don't read the code

Re: Don't hardcode a limited set of markup signatures. (issue969046)

Han-Wen Nienhuys writes: > On Sun, May 2, 2010 at 6:19 PM, David Kastrup wrote: > >>> For one reason or another, whenever I review code from you it degrades >>> into a fight. I am not quite sure why this always happens. >> >> Because you don't bother taking the contributions of other people >> s

Re: Don't hardcode a limited set of markup signatures. (issue969046)

On 2010/05/02 16:34:12, hanwenn wrote: On Sun, May 2, 2010 at 8:04 AM, wrote: > > http://codereview.appspot.com/969046/diff/7001/8002 > File lily/lexer.ll (right): > > http://codereview.appspot.com/969046/diff/7001/8002#newcode545 > lily/lexer.ll:545: // loop will be EXPECT

Re: Don't hardcode a limited set of markup signatures. (issue969046)

On Mon, May 3, 2010 at 4:22 AM, David Kastrup wrote: For one reason or another, whenever I review code from you it degrades into a fight. I am not quite sure why this always happens. >>> >>> Because you don't bother taking the contributions of other people >>> seriously.  You don't read

Re: Don't hardcode a limited set of markup signatures. (issue969046)

Hi Han-Wen, > I take issue with the way you interact with me on the mailing-list, > and I have had enough of it. For the record, I am appalled at David's etiquette -- which is to say, complete lack thereof -- and understand your reaction completely. While I appreciate and (at a basic level) val

Re: Don't hardcode a limited set of markup signatures. (issue969046)

On 5/3/10 5:01 AM, "Han-Wen Nienhuys" wrote: > > Just for the record: I am ok with the current form of the patch. > Would anybody else care to review this before it gets pushed? http://codereview.appspot.com/969046/show Thanks, Carl ___ lilypon

Re: Don't hardcode a limited set of markup signatures. (issue969046)

Another patch set has been made that removes the order restrictions on the markup function arguments and consequently throws out all the code for which change suggestions or commenting or refactoring requests have been made. Most changes in the patch set provide a significant reduction in (quite

Re: Don't hardcode a limited set of markup signatures. (issue969046)

Looks good! http://codereview.appspot.com/969046/show ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Don't hardcode a limited set of markup signatures. (issue969046)

Han-Wen Nienhuys writes: > On Mon, May 3, 2010 at 4:22 AM, David Kastrup wrote: > > For one reason or another, whenever I review code from you it degrades > into a fight. I am not quite sure why this always happens. Because you don't bother taking the contributions of other peo

Re: Don't hardcode a limited set of markup signatures. (issue969046)

Am Mittwoch, 19. Mai 2010, um 11:42:59 schrieb David Kastrup: > Han-Wen Nienhuys writes: > > On Mon, May 3, 2010 at 4:22 AM, David Kastrup wrote: > >> Nice touch, but it's not your work going in the bin. > > > > Just for the record: I am ok with the current form of the patch. > > As you can see

Re: Don't hardcode a limited set of markup signatures. (issue969046)

On Sun, Jun 13, 2010 at 6:21 PM, Reinhold Kainhofer wrote: > Can't we finally give commit access to David? Yes, a week or two ago: http://savannah.gnu.org/project/memberlist.php?group=lilypond Cheers, - Graham ___ lilypond-devel mailing list lilypond-

Re: Don't hardcode a limited set of markup signatures. (issue969046)

Reinhold Kainhofer writes: > Am Mittwoch, 19. Mai 2010, um 11:42:59 schrieb David Kastrup: >> Han-Wen Nienhuys writes: >> > On Mon, May 3, 2010 at 4:22 AM, David Kastrup wrote: >> >> Nice touch, but it's not your work going in the bin. >> > >> > Just for the record: I am ok with the current fo

Ousting bad people (was: Don't hardcode a limited set of markup signatures. (issue969046))

Kieren MacMillan writes: > Hi Han-Wen, > >> I take issue with the way you interact with me on the mailing-list, >> and I have had enough of it. > > For the record, I am appalled at David's etiquette -- which is to say, > complete lack thereof Thanks for that important observation. It is likely

Re: Ousting bad people (was: Don't hardcode a limited set of markup signatures. (issue969046))

Hi David, >> For the record, I am appalled at David's etiquette -- which is to say, >> complete lack thereof > > Thanks for that important observation. > It is likely to improve the quality of contributions. Choose your own response here: #1 if [by some fluke of mao] you're not being your usual