On 20 January 2011 22:13, Trevor Parscal <tparscal(a)wikimedia.org> wrote: On behalf of all aspiring Dark Lords, may I thank the Wikimedia Foundation for protecting our freedom to use MediaWiki for evil. BABY MULCHING WIKI IS GO!

Yes, I know I'm stubborn, but 6 bytes (0.6%)? Seriously? Doesn't seem convincing to me and seems like it could at least use $wgResourceLoaderMinifyJSHorizontalSpace (even if true by default).

On 21/01/11 09:13, Trevor Parscal wrote: You're talking about the "good not evil" joke clause? -- Tim Starling _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Joke or not, it's in there, and it's a violation of the GPL.

Plus the alternative is better anyway.

Sure, but Trevor is claiming that he wrote it because of the license issue. Since he has publically ranted three times: <http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/50082> <http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/50910> <http://www.mediawiki.org/wiki/Special:Code/MediaWiki/73196#c13027> about how terrible my changes to JSMin.php were, in September, December and January, I can't help but think that there was another motive for this rewrite. I have no problem with Trevor reverting that change, I said so the second time this came up, so I think it's amusing that Trevor needed the excuse of license incompatibility before he actually did something. I'm glad that he's finally found the motivation from somewhere, so that he can stop bothering me with his periodic rants.

On Fri, Jan 21, 2011 at 10:49 AM, Andrew Garrett &lt;agarrett(a)wikimedia.org&gt; wrote: Agreed.  Or better yet, not said at all.  Since we evidently no longer have a benevolent dictator whose word we all accept without question, we need to work amicably to resolve disputes, and getting into fights about <1% size savings vs. dubious increases in readability is really not useful.  At least get into fights about something *significant*.

On 01/21/2011 08:21 AM, Chad wrote: Ideally we will be using closures by then and since it rewrites functions, variable names and sometimes collapses multi-line functionality, new line preservation will be a mute point. Furthermore, Google even has a nice add-on to firebug [1] for source code mapping. Making the dead horse even more dead. I feel like we are suck back in time, arguing about optimising code that came out eons ago in net time ( more than 7 years ago ) There are more modern solutions that take into consideration these concerns and do a better job at it. ( ie not just a readable line but a pointer back to the line of source code that is of concern ) [1] http://code.google.com/closure/compiler/docs/inspector.html

Debugging JavaScript in today's browsers can at least pop up the live code in context for you, and by sticking '?debug=false' on your URL, all our minification will be conveniently gone from view, and the individual modules easier to identify by hand.

On Fri, Jan 21, 2011 at 10:49 AM, Andrew Garrett &lt;agarrett(a)wikimedia.org&gt; wrote: Agreed. Or better yet, not said at all. Since we evidently no longer have a benevolent dictator whose word we all accept without question, we need to work amicably to resolve disputes, and getting into fights about <1% size savings vs. dubious increases in readability is really not useful. At least get into fights about something *significant*.

This sounds like "thinking out loud" (not to say whether it's true or false). It seems like there "just has" to be some better, more private, means to discuss things like this...

As mentioned in the bug, it would be nice to have configurable support for the closure-compiler as well ;) ( I assume Apache licence is compatible? ) Has anyone done any tests to see if there are any compatibility issues with SIMPLE_OPTIMIZATIONS with a google closure minification hook? --michael On 01/20/2011 04:13 PM, Trevor Parscal wrote: > For those of you who didn't see bug 26791, our use of JSMin has been > found to conflict with our GPL license. After assessing other options ( > https://bugzilla.wikimedia.org/show_bug.cgi?id=26791#c8 ) Roan and I > decided to try and use the minification from JavaScriptPacker, but not > its overly clever but generally useless packing techniques. The result > is a minifier that outperforms our current minifier in both how quickly > it can minify data and how small the minified output is. > JavaScriptDistiller, as I sort of randomly named it, minifies JavaScript > code at about 2x the speed of Tim's optimized version of JSMin, and 4x > the speed of the next fastest PHP port of JSMin (which is generally > considered the standard distribution). > > Similar to Tim's modified version of JSMin, we chose to retain vertical > whitespace by default. However we chose not to retain multiple > consecutive empty new lines, which are primarily seen where a large > comment block has been removed. We feel there is merit to the argument > that appx. 1% bloat is a reasonable price to pay for making it easier to > read production code, since leaving each statement on a line by itself > improves readability and users will be more likely to be able to report > problems that are actionable. We do not however find the preservation of > line numbers of any value, since in production mode most requests are > for many modules which are concatenated, making line numbers for most of > the code useless anyways. > > This is a breakdown based on "ext.vector.simpleSearch" > > * 3217 bytes (1300 compressed) > * 2178 bytes (944) after running it through the version of JSMin that > was in our repository. Tim modified JSMin to be faster and preserve line > numbers by leaving behind all vertical whitespace. > * 2160 bytes (938 compressed) after running it through > JavaScriptDistiller, which applies aggressive horizontal minification > plus collapsing multiple consecutive new lines into a single new line. > * 2077 bytes (923 compressed) after running it through > JavaScriptDistiller with the vertical space option set to true, which > applies aggressive horizontal minification as well as some basic > vertical minification. This option is activated through > $wgResourceLoaderMinifyJSVerticalSpace, which is false by default. > > The code was committed in r80656. > > - Trevor (and Roan) > > > _______________________________________________ > Wikitech-l mailing list > Wikitech-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l

I noticed a regression in the JS minification with a bit of sloppy third-party code being imported through ResourceLoader in SVGEdit: https://bugzilla.wikimedia.org/show_bug.cgi?id=27046

I can work around it in the extension, but we should watch out and make sure we've got regression tests covering any cases we find.

On 31/01/11 13:51, Roan Kattouw wrote: Isn't this an upstream issue? If so we could send them our patches. -- Ashar Voultoiz _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

There are 2 components to the JavaScriptDistiller library. One of them (the ParseMaster class) is 100% in sync with the official distribution. The other (the JavaScriptDistiller class) was originally based on the JavaScriptPacker::_basicCompression function. That function had some issues that we have worked out, and in the process of doing that we've gotten really far away from the original source. It appears that our version is just about stable, so I plan to offer the code in JavaScriptDistiller to the JavaScriptPacker author to try and help make his library better as well. In the former case, any changes should be strictly passed upstream. In the latter case, I think we should offer them upstream but realize that we have deviated from the original author's structure and possibly intentions enough that they may or may not be wanted. - Trevor