press.js - yet another javascript compressor
in [JavaScript]
|
From: nick on 23 May 2010 15:20 On May 23, 3:07 pm, David Mark <dmark.cins...(a)gmail.com> wrote: > nick wrote: > > Is [modem compression] usually enabled by default, or do modem users > > have to jump through a bunch of hoops to set it up? I also found a lot > > of instructions for enabling modem compression. > It typically works right out of the box. Has for decades. Skip the > articles about modem init strings. They haven't been a concern for the > average user in decades. I was seeing stuff like this: http://technet.microsoft.com/en-us/library/cc754722(WS.10).aspx It doesn't mention what the default setting might be, of course. > Even if [packer] worked flawlessly, it would still be a waste of time. > The fact that it introduces an additional point of failure is just a > "bonus". ;) Hopefully press.js will remain bonus-free, and prove to be an interesting time-waster. > >>> [...] the processing overhead is negligible. > >> Define negligible. > > I don't notice any time going by at all [...] > No. "Show me where it's slow!" ;)
From: Sean Kinsey on 23 May 2010 15:26 On May 23, 7:41 pm, nick <nick...(a)fastmail.fm> wrote: > On May 23, 9:53 am, Johannes Baagoe <baa...(a)baagoe.com> wrote: .... > > Fromhttp://code.google.com/p/pressjs/source/browse/trunk/src/compdict.js: > > > // Populate table with all possible character codes. > > for(var i = 0; i < 256; ++i) { > > var str = String.fromCharCode(i); > > this.hashtable[str] = this.nextcode++; > > } > > > What about character codes >= 256? > > I'm pretty sure those characters aren't allowed in a javascript > document? I'm not really sure what's going on there though, I was > puzzled by that bit as well. See my next paragraph. I'm pretty sure UTF-8 is supported quite well by most javascript parsers :)
From: David Mark on 23 May 2010 15:28 nick wrote: > On May 23, 3:07 pm, David Mark <dmark.cins...(a)gmail.com> wrote: >> nick wrote: >>> Is [modem compression] usually enabled by default, or do modem users >>> have to jump through a bunch of hoops to set it up? I also found a lot >>> of instructions for enabling modem compression. > >> It typically works right out of the box. Has for decades. Skip the >> articles about modem init strings. They haven't been a concern for the >> average user in decades. > > I was seeing stuff like this: > > http://technet.microsoft.com/en-us/library/cc754722(WS.10).aspx That's simply an instruction on how to enable/disable hardware-based compression in Windows for installed modems. > > It doesn't mention what the default setting might be, of course. On. > >> Even if [packer] worked flawlessly, it would still be a waste of time. >> The fact that it introduces an additional point of failure is just a >> "bonus". ;) > > Hopefully press.js will remain bonus-free, and prove to be an > interesting time-waster. Godspeed. :) > >>>>> [...] the processing overhead is negligible. > >>>> Define negligible. > >>> I don't notice any time going by at all [...] > >> No. > > "Show me where it's slow!" ;) Try counting one-one thousand, two-one thousand... Or perhaps a stopwatch. :)
From: Johannes Baagoe on 23 May 2010 15:45 nick : > Johannes Baagoe : >> What about character codes >= 256? > I'm pretty sure those characters aren't allowed in a javascript > document? They are. Obviously in string literals and property names, but also in identifiers. See the specs, 7.6 Identifier Names and Identifiers. There is no way you can assume that String.prototype.charCodeAt returns a byte - the specs say "a nonnegative integer less than 2^16". > I've been going through and making it more object-based, Why? It seems to me that two straightforward functions is all that is needed. A bit like those : http://stackoverflow.com/questions/294297/javascript-implementation-of-gzip#answer-294421 (Except that they don't work - they fail my "French taxpayers" test string much worse than your implementation.) > and trying to learn the algorithm at the same time. Now, *that* I understand :) > Eventually I'd like to replace all of that code, but for now I just > wanted to see if this whole idea was viable. I think it is. I am not sure that it will earn or save anybody a cent, but that is not always the point. > Server-side gzip is obviously the better alternative if it's > available; however that's not always the case (see my response to > Sean) and so we have things like "packer" and maybe this thing. If your shared server uses Apache, the SetOutputFilter DEFLATE directive can be set in the .htaccess file on your directory. It won't work if the deflate module hasn't been enabled globally, but if it hasn't and the sysadmin refuses to do so even when you ask, you may try and see if one of his competitors will. -- Johannes
From: Johannes Baagoe on 23 May 2010 16:29
nick : > Hmm... so I wonder how this passes the "Où qu'il réside" test? I don't understand it either :) > Were all of those char codes <= 256? No: "Où qu'il réside".charCodeAt(1) == 65533 -- Johannes |