After Kathrin and I talked this over, it's become clear that we simply don't have time to do 1-based counting, correctly, everywhere. Importantly, there is symbolMaps code in google3 that absolutely depends on 0-based counting. Looking at the whole situation, I think the wisest course of action at this point is to simply converge on 0-based perm counting everywhere. Here's why:
What needs to change: - Compiler log messages What doesn't need to change: - Numbering of SOYC artifacts - Numbering of symbolMaps artifacts - Code in google3 that excepts symbolMaps to be 0-based - Compiler internals that track perms as 0-based - The "-perms" argument to the CompilePerms entry point, which is zero based - Blaze code that calls the "-perms" argument to the CompilePerms entry point and expects it to be zero based Any dissenting opinions? :) Scott On Fri, Nov 20, 2009 at 11:52 AM, Katharina Probst <[email protected]>wrote: > > > On Fri, Nov 20, 2009 at 11:45 AM, Scott Blum <[email protected]> wrote: > >> Strawman proposal: how about we internally continue to count permutations >> from 0; but any time we produce a user facing message, we add 1 to make it >> 1-based instead? > > > This already happens when it comes to compiler logging output. > > >> I'm not attached to this idea. I'd be just as happy making permutations >> 0-based in all cases and updating the log messages to not add 1. We could >> also make them internally start from 1, but that's more likely to break >> code, including google3 code that expects symbolMaps to be 0-based. >> >> Lex was right that there are only a few places in the compiler that would > need to change, but Scott also makes a good point. Additionally, I'm afraid > that there are places inside the compiler that implicitly rely on 1-based > counting (without referring to permutationId or basePermutation) that I > didn't catch. I'm attaching a patch anyway, although I am still worried > about actually submitting this (especially today with everything else going > on). > > kathrin > > > >> On Fri, Nov 20, 2009 at 11:13 AM, Katharina Probst <[email protected]>wrote: >> >>> Hi Lex, >>> >>> you make a good point. There are a couple of counter-arguments, however: >>> the logging output already uses 1-based counting, and for end users 1-based >>> counting is probably more intuitive. >>> >>> Are permutation IDs used in any other artifacts produced by the compiler >>> (other than symbol maps) that I'm not aware of? Would it make sense to >>> change everything publicly facing (and this, by the way, will include our >>> stories[permutationId].xml.gz files, etc.) to 1-based counting? >>> >>> My concern with changing everything to 1-based counting inside the >>> compiler is also that it will touch a lot of files. A quick look confirmed >>> that there are, for example, counters that count down the iterations to 0. >>> >>> kathrin >>> >>> >>> >>> On Fri, Nov 20, 2009 at 9:46 AM, Lex Spoon <[email protected]> wrote: >>> >>>> Consistency is good, but this patch breaks a different consistency! >>>> Specifically, the symbolMaps files count permutations from 0. So >>>> permutation 3 in the compile report would be permutation 2 in the >>>> symbolMaps files. I think that consistency is more important than >>>> that the permutation counting and split point counting use the same >>>> numbering. If someone reads about permutation 3 in their compile >>>> report, they should be able to safely look at permutation 3 in the >>>> symbol information and in any other files the compiler emits. >>>> >>>> The easier of the two numberings to change is the permutation >>>> numbering. The symbol maps numbering must be coming from some >>>> PermutationResult or something. We could trace backward to find out >>>> where that number originally comes from, and shift them all to be >>>> 1-based. >>>> >>>> Making the split point numbers 0-based is certainly possible but could >>>> touch a lot of code. The biggest issue is that CodeSplitter already >>>> uses split point 0, which doesn't really exist, as a convention >>>> indicating the initial download. If split point 0 was a real split >>>> point, then some other number would have to be used. >>>> >>>> Lex >>>> >>> >>> -- >>> http://groups.google.com/group/Google-Web-Toolkit-Contributors >>> >> >> -- >> http://groups.google.com/group/Google-Web-Toolkit-Contributors >> > > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
