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
compilerUsesOneBasedCounting.patch
Description: Binary data
