2010/9/30 Trevor Parscal <tpars...@wikimedia.org>: >> * Where it is suspected that, due to caching issues, the debug code >> may not be the same as the minified code. > Shift+refresh? Or change the URL in some way that doesn't alter the meaning of the URL. There's various ways to get around caching.
>> * To debug the minifier itself, which is far short of a full >> JavaScript parser and may well introduce functional differences. > If JSMin is causing the bug, then it will be best detected by seeing > that debug=true/false have different behavior, not that debug=true > contains line breaks. JSMin causing a bug sounds very unlikely to me, but I agree that we should be paranoid and account for the possibility anyway. Still, I think we can agree that JSMin breaking something should be a very, very rare occurrence (it's been around for a long time and has been used on a large body of code), and that debugging the minifier would be done locally anyway (to be sure caching is not to blame), so line breaks in production won't help. All you'd need to debug JSMin locally without going insane is to be able to preserve line breaks locally, which can be accommodated with a setting (off by default) or even just requiring commenting out of code (as long as it's clear how to do this and not cumbersome, this should be fine). > but depending on the > user's preferences they may be totally different from one user to > another. This is false in almost all cases. Because we make our requests as cacheable as possible, the vast majority of RL responses will *not* depend on user preferences, or in fact on anything not in the URL. For these requests, you'll be able to pull up the same URL that the user is pulling and see the exact same thing (provided you both clear your caches). User preferences and other factors may be used to *build* the URL, so whether you see the issue may depend on your preferences, but once you find out which URL the user is getting their stuff from you'll have a meaningful line number. There should only be one request whose contents depend on user preferences: the one getting the user's preferences plus the user scripts. The former is really just one call to a setter with a JSON-encoded preferences map, so it consists of one simple statement; inspecting that is doable. The rest is the user's own user JS, which can contain almost anything. This is the only thing you won't reasonably be able to debug based on just a line number, but then there's lots of other easy ways to nail down user JS as being the culprit. > Line numbers in production mode (debug=false) are useless no > matter how much white-space is preserved. Per the above this is not entirely true, but the one case in which they are useful (culprit is in user JS+prefs request and all you have is a line number) doesn't warrant preserving line breaks IMO. > We should probably calculate just how small that cost is before we start > making asumptions based on it being "fairly small". I agree that we should get our numbers first, but some preliminary playing around seems to indicate Tim's right about this one. Roan Kattouw (Catrope) _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
