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'? > 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;} > 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.
