On Wednesday, October 23, 2013 1:20:24 AM UTC-7, Kees Bos wrote: > > On Wed, 2013-10-23 at 00:51 -0700, Sarvi Shanmugham wrote: > > > > > > On Tuesday, October 22, 2013 11:36:54 PM UTC-7, Kees Bos wrote: > > On Tue, 2013-10-22 at 22:21 -0700, Sarvi Shanmugham wrote: > > > > > > > > > On Tuesday, October 22, 2013 9:42:19 PM UTC-7, Kees Bos > > wrote: > > > On Tue, 2013-10-22 at 20:29 -0700, Sarvi Shanmugham > > wrote: > > > > I tried to hack a bit to simplify the generated > > code to see > > > how it can > > > > be done and this is what I got. > > > > I left the $ alone for the reasons Lex mentioned. > > Turned > > > the > > > > dictionary accesses into object notation and > > > > > > That looks cleaner, but inhibits the use of closure > > compiler, > > > since that > > > will mangle object attributes (at high > > optimization). > > > would you refering me to something that explains this? I am > > relative > > > noob with this stuff. > > > > > It's somewhere in the docs or command line help. This is the > > issue (from > > memory) after running closure compiler: > > foo.something gets compressed to foo.XX > > foo['something'] becomes foo.something > > > > Thanks for the pointer. I did a little bit more reading at > > https://developers.google.com/closure/compiler/docs/api-tutorial3 > > > > > > > > A couple of things. > > 1. Is foo.something --> foo.XX really a problem. From what I can > > tell as long as its usage is consistent across the code we should be > > fine. > > Nope. It's a blocking issue. How does hasattr(foo, 'something') now that > 'something' should in fact be 'XX'? > Checked some of the things you raise. >From what I read and experimented as long as 'something' is stored in a global dictionary it is not optmized window['hello'] = hello; this can be avoided by simply generating an extern.js file with these and using them during compilation. Here is closure generated code I got after doing it var pyjs={apple:{}};pyjs.apple.test=5;pyjs.o range={};pyjs.orange.test=10;pyjs.name=" apple";pyjs.b="test";window.a=pyjs;function c(d){var b;b=10;b="number"==typeof b&&"number"==typeof b?20*b:20*b+1*pyjs[pyjs.name][pyjs.tname];alert("Hello, "+d+b)}window.hello=c;c("New user"); This required // @js_externs var pyjs;pyjs.apple;pyjs.orange;function hello(name){};
> > > Also does all the other javascript frameworks use > > foo['something'] to avoid this issue? > > Infact the compiler advanced optimization documentation > > suggests suggests the opposite of what you are suggesting. > > Consistent dot notation Vs quoted strings as a solution here > > > > > https://developers.google.com/closure/compiler/docs/api-tutorial3#propnames > > 2. Closure advanced optimization does the inlining during > > compilation and hence the performance should be comparable on all > > browsers. > > I tried the following code at > > > > > > function dumult(x,y) { > > return x*y; > > } > > > > > > function multiply(x,y) { > > return (typeof x == typeof y && typeof > > x=='number')?x*y:dumult(x,y); > > } > > > > > > function hello(name) { > > var i; > > var j; > > i=10; > > j=20; > > i=multiply(i,j); > > alert('Hello, ' + name + i); > > } > > hello('New user'); > > > > > > It got optimized to, Wow!! :-)) > > var a;a=10;a*=20;alert("Hello, New user"+a); > > Impressive, but probably only possible since the compiler knows > _beforehand_ that i = 10 and j = 20 and dumult(x,y) _is_ x*y. Try > changing dumult to: > function dumult(x,y) {return x*y+1;} > Well I did and got the following. This included the js_externs and so specifying hello() as an extern did not impact inlining. var a;a=10;a="number"==typeof a&&"number"==typeof a?20*a:20*a+1;alert("Hello, New user"+a); > > Another complaint I've read about pyjamas is size of generated code > > https://blogs-pyjeon.rhcloud.com/?p=302 > > For him. Indeed. He doesn't need python, but something with the syntax > like python, that remotely behaves like python, but is primarily > javascript. BTW. I think that speed was his most important issue with > pyjamas. (Graphpad is a highly interactive app and needs very fast > response times, which is quite different from a standard > form-based-lookalike app). > > > > > And I am reading about closure tool doing dead code removal > > Shouldn't that be trimming simple applications to the minimum code? > > I am guessing people have tried this. What is the feedback? > > It saves primarily space. It didn't speed-up the code execution (much). > Well, a year ago or something like that. Might be different now. > > > Should closure be integrated into the pyjs compile/build process? > > Yes. But optionally, and needs lots of testing (since all modules will > be compiled separately, doing all-in-one-run would make it easier to > have consistent code compression). > > > > -- --- You received this message because you are subscribed to the Google Groups "Pyjs.org Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
