Tim,
First off, thank you for taking the time to respond here, I know you
have a lot on your plate right now, and I hope things are going well for
you. I did not mean to call you out as having made a mistake as much as
I wanted to point to examples of what kinds of changes have been made
bas
2010/9/30 Trevor Parscal :
>> * 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 min
On 9/30/10 10:11 AM, Roan Kattouw wrote:
> 2010/9/30 Trevor Parscal:
>>> * 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
Hi everyone,
You all probably have noticed more people getting involved in code
review (and of course saw Brion's mail). This is partly in
anticipation of Tim being afk, and partly because we're long overdue
for distributing the load.
Here's who we have available for code review, and what they'l
Rob Lanphier wrote:
> I imagine we will want to give the code review pages on mediawiki.org
> some love in the coming days and weeks, starting here:
> http://www.mediawiki.org/wiki/Code_review
> ...and:
> http://www.mediawiki.org/wiki/Requests_for_review
>
> We have a number of related pages that
On 9/30/10 9:31 AM, Trevor Parscal wrote:
>Tim,
>
> First off, thank you for taking the time to respond here, I know you
> have a lot on your plate right now, and I hope things are going well for
> you. I did not mean to call you out as having made a mistake as much as
> I wanted to point to
Early on in the requirements stage of ResourceLoader development we
decided to use ISO8601 as the format for representing timestamps in
URLs. This was chosen for it's legibility, conformance to a standard and
ease of generation. However this was somewhat of an oversight since the
timestamp "1
ISO 8601 does not mandate the use of separators within date and time.
The following are equivalent.
"basic" format: 19850412T101530Z
"extended" format: 1985-04-12T10:15:30Z
On 9/30/10 12:30 PM, Trevor Parscal wrote:
>Early on in the requirements stage of ResourceLoader development we
> d
Neil Kandalgaonkar wrote:
> ISO 8601 does not mandate the use of separators within date and time.
> The following are equivalent.
>
> "basic" format: 19850412T101530Z
> "extended" format: 1985-04-12T10:15:30Z
I'm not sure I'd call the "basic" format very readable.
Internally, MediaWiki largely
Well, the MediaWiki timestamp string ("19850412101530") is very
similar to the "basic" ISO8601 format ("19850412T101530Z"), the
difference being the use of T as a separator and the Z at the end to
indicate GMT.
I guess I'm a little confused why someone would find "19850412101530" to
be "fair
At 2010-09-30 20:35, Trevor Parscal wrote:
>>> [...]
>>> * Where end users report platform-specific JavaScript errors, it may
>>> 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
>>
2010/9/30 Neil Kandalgaonkar :
> ISO 8601 does not mandate the use of separators within date and time.
> The following are equivalent.
>
> "basic" format: 19850412T101530Z
> "extended" format: 1985-04-12T10:15:30Z
>
Does it also allow replacing the separators with whatever you want?
Colons get url
On 9/30/10 1:55 PM, Maciej Jaros wrote:
>At 2010-09-30 20:35, Trevor Parscal wrote:
[...]
* Where end users report platform-specific JavaScript errors, it may
be useful to be able to match the line number of the error with
something meaningful.
>>> The usefulness of this i
As of r74042 a new format is supported by wfTimestamp called
TS_ISO8601_BASIC. This is being used by ResourceLoader now.
Thank you to everyone for contributing your ideas.
- Trevor
On 9/30/10 2:12 PM, Roan Kattouw wrote:
> 2010/9/30 Neil Kandalgaonkar:
>> ISO 8601 does not mandate the use of
2010/9/30 Maciej Jaros :
> 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.
Minified code does not contain zero line breaks. Some line breaks are
left in, although I don't under
On 9/30/10 2:12 PM, Roan Kattouw wrote:
> Does it also allow replacing the separators with whatever you want?
If you use a separator for time, ISO 8601:2004 section 3.4.4 says it has
to be hyphen for year, month, day, and colon for hour, minute, and second.
--
Neil Kandalgaonkar (|
At 2010-09-30 23:13, Trevor Parscal wrote:
>On 9/30/10 1:55 PM, Maciej Jaros wrote:
>> At 2010-09-30 20:35, Trevor Parscal wrote:
> [...]
> * Where end users report platform-specific JavaScript errors, it may
> be useful to be able to match the line number of the error with
>>
On 9/30/10 4:31 PM, Maciej Jaros wrote:
>At 2010-09-30 23:13, Trevor Parscal wrote:
>> On 9/30/10 1:55 PM, Maciej Jaros wrote:
>>> At 2010-09-30 20:35, Trevor Parscal wrote:
>> [...]
>> * Where end users report platform-specific JavaScript errors, it may
>> be useful to b
At 2010-10-01 01:50, Trevor Parscal wrote:
>On 9/30/10 4:31 PM, Maciej Jaros wrote:
>> At 2010-09-30 23:13, Trevor Parscal wrote:
>>> On 9/30/10 1:55 PM, Maciej Jaros wrote:
At 2010-09-30 20:35, Trevor Parscal wrote:
>>> [...]
>>> * Where end users report platform-
Trevor Parscal wrote:
> I think that our outgoing HTML *should* be minified, and those comments
> should be stripped, I just have yet to get to that as of yet. Go to
> www.google.com and view source. Tell me what you see. Why are we so
> different from them? They are taking advantage of aggressive
On 9/30/10 6:04 PM, MZMcBride wrote:
> You're getting friction because of three different issues.
>
> The first issue is that the front-end is currently pretty damn fast for
> _most_ people.
The front end that we have *now* is fast for some people. The point of
writing a new platform is to be ab
On 01/10/10 07:27, Roan Kattouw wrote:
> Minified code does not contain zero line breaks. Some line breaks are
> left in, although I don't understand exactly what the logic is there.
The logic is that line breaks can have functional significance in two
cases. One is where statement-ending semicolo
On 9/30/2010 10:03 PM, Neil Kandalgaonkar wrote:
> Here's how they do it: Google guarantees that certain Javascript
> functions or DOM objects are reliably available for use and
> modification, and others are not. So they use minification for
> efficiency while explicitly preventing some things
Neil Kandalgaonkar wrote:
> The front end that we have *now* is fast for some people. The point of
> writing a new platform is to be able to do more, if we want.
Do more, such as?
If there's a broader outlook here, a roadmap for the future, what is it and
where is it posted? I think there's a rea
On 01/10/10 04:35, Trevor Parscal wrote:
> OK, now 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
I was hardly making a case for how amazingly expensive it was. I was
running some basic calculations that seemed to support your concept of
"fairly cheap", but chose to mention that it's still "not free".
- Trevor
On 9/30/10 9:30 PM, Tim Starling wrote:
> On 01/10/10 04:35, Trevor Parscal wro
This is getting a little out of hand? People are going to spend more
time talking about the potential for minification errors or sub
optimisation cost criteria then we will ever actually be running into
real minification errors or any real readability issue. Reasonable
efforts are being made to ma
On Thu, Sep 30, 2010 at 8:27 AM, Trevor Parscal wrote:
> ...
> When debug mode is off:
>
> * Modules are requested in batches
> * Resources are combined into modules
> * Modules are combined into a response
> * The response is minified
>
> When debug mode is on:
>
> * Modules are re
Thank you. +1.
- Trevor
On 9/30/10 10:04 PM, Michael Dale wrote:
> This is getting a little out of hand? People are going to spend more
> time talking about the potential for minification errors or sub
> optimisation cost criteria then we will ever actually be running into
> real minification
29 matches
Mail list logo
