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 pyjs-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
