On 9/30/10 1:55 PM, Maciej Jaros wrote:
At 2010-09-30 20:35, Trevor Parscal wrote:
>> be useful to be able to match the line number of the error with
>> something meaningful.
> The usefulness of this is attached to the idea the most important part
> of the error message is the line number. In some browsers (such as many
> versions of IE) the line numbers aren't even correct. Besides, as I have
> said already, over and over, combination is going to throw off line
> numbers anyways, not just making them higher, but depending on the
> user's preferences they may be totally different from one user to
> another. Line numbers in production mode (debug=false) are useless no
> matter how much white-space is preserved.
To my experience something is better
then nothing. IE (old one that is)
is usually wrong when you have either long lines (ekhem ;-)) and have
code inside script tags (instead of outer files). Picture this:
1. A user says his browser reports an error.
2. I ask for the browser and other stuff...
3. I don't see the problem.
4. He tries out debug mode and it's fine.
5. I search through his code...
The problem with fully minified without any vertical white space code to
me is that you cannot read this. Well I can't and Firebug can't and any
other debugger AFAIK. If something comes up it will be almost impossible
There's this assumption here that when a bug is reported that a
experience is that when bugs are reported, the first step is
reproduction, and then investigation. If we shouldn't be relying on
users with little or no expertise to be participating in investigation.
Also, error reporting with Firebug and most browsers is much more
verbose than "error on line ##".
Since the cost
of adding line breaks is fairly small, the contention
was that it was a fair compromise between size and developer (and tech
supporter) sanity. So I took those comments on board and implemented
it shortly after the branch merge.
We should probably calculate just how small
that cost is before we start
making asumptions based on it being "fairly small". Also, as I have been
saying, the production mode (debug=false) is only going to become more
optimized in the future, further reducing the value of line numbers.
I've calculated it...
On a normal page view with the Vector skin and the Vector extension
turned on there's a 2KB difference. On an edit page with the Vector skin
and Vector and WikiEditor extensions there's a 4KB difference.
While adding 2KB to a request for a person in a remote corner of the
world on a 56k modem will only add about 0.3 seconds to the download,
sending 2,048 extra bytes to 350 million people each month increases our
bandwidth by about 668 gigabytes a month. I don't know what that kind of
bandwidth costs the foundation, but it's not free.
OK. It's not free, the
question is it worth the effort and are you
really calculating this correctly? I think it would be worth it as a
just-in-case thing. Also JS is usually cached and actually get stuck in
cache for days. And just to be sure - did you calculated gziped version
difference or plain?
Compressed of course. It would be 5-10 times that much without
Plus developers will probably stick to debug mode if
something in the middle. Yes, I can't speak for all, but personally I
work on code (small tweaks) from time to time while I'm not doing other
stuff in the minute. Always changing to debug mode to debug code will
not be very productive to me. That's why I wrote my loader and I was
hoping that you will add some stuff from it to the loader so I can use
it and so the RL can be useful to me (in non-wikimedia use cases too).
This is what debug mode is for. Developers. Developers should always use
debug mode while debugging. Switching back and forth is not necessary
for every tiny change, just a good thing to verify before checking in code.
Again I'm sure you are confident with your code
and code of your
colleagues and I'm not saying you screwed something up. I'm just saying
something will eventually get screwed up just because it always does.
That's why programmers are always needed isn't it ;-).
It's not a matter of me thinking our code is so good it won't break.
It's a matter of wanting to send fully optimized code to clients, not
partially optimized code.
I agree that something will always break - I just disagree that there's
much merit in your approach to solving this.
If we are talking about allowing the ResourceLoader to be configurable
with LocalSettings.php adjustments, then you are already assuming a
level of expertise about the developer debugging the problem that these
middle-ground approaches will be useless.
If we are talking about adding yet another URL parameter to be able to
turn minification off, or otherwise customize the processing of the
modules beyond turning debug on and off, I think you are adding
complexity without reasonable benefit.
Wikitech-l mailing list