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
reduced some of the repetitive code into functions that do the same code.
>From what I tested of inlining, JITs should take care of inlining these
with no performance impact.
and it was relatively simple, repetitive but sizable changes to the
translate_proto.py code to do this.
/* start module: test1 */
$pyjs.loaded_modules.test1 = function (__mod_name__) {
if ($pymdecorate(this,'test1',__mod_name__)) return $m
$m.hello = function(i) {
return multiply(multiply(multiply(i,i),2),25);
};
$pyfdecorate($m.hello,'hello',0,[null,null,['i']]);
return this;
}; /* end test1 */
/* end module: test1 */
The result would from what I can see would be much simpler, readable and a
lot less code
Would something like this be accepted if I work on finishing this?
Sarvi
On Monday, October 21, 2013 7:42:52 AM UTC-7, Lex Berezhny wrote:
>
> On Mon, Oct 21, 2013 at 1:40 AM, Sarvi Shanmugham
> <[email protected]<javascript:>
> > wrote:
>
>> I get this.
>> But considering Javascript is JITed and highly optimized including
>> unrolling static loops and function calls if I understand right,
>> wouldn't the following
>> i=p.op_mul(i,2)
>> be faster than the current
>> i = (typeof ($mul1=i)==typeof ($mul2=2) && typeof $mul1=='number'?
>> $mul1*$mul2:
>> $p['op_mul']($mul1,$mul2));
>> as long as op_mul() can handle numbers as well?
>> And much more readable too?
>>
>
>
> Unrolling requires work. If you have a lot of equations that means for
> every operator you will need the JS engine to unroll. There is no way
> "unrolling" something would be faster than var1*var2, especially not on the
> first pass. Also, with unrolling a function there is some book keeping
> required: what if $op.op_mul is changed to a different function at runtime
> (not that it would be) but the JS engine has to take that possibility into
> account.
>
> I'm not necessarily against what you are suggesting. I think in the grand
> scheme of things readability is more important. If you truly need something
> to be very performant than you can always just write that part in pure JS.
>
>
>
>> Yeah, thats sorta why I asked the question. Just a beginnner but this how
>> I understood java script objects and classes
>> and I thought this entire generated code segmented would have a been much
>> more readable as objects instead of dictionary objects.
>>
>
>
> There may have been a reason for doing it that way but I do not know.
>
>
>
>> And whats with the $ notation. From what I am reading this is just jQuery
>> convention and not required.
>>
>
>
> This has nothing to do with jQuery or conventions.
>
> $ allows you to have private implementation related variables. Since in
> Python you cannot have variables that start with $ that means we can prefix
> generated/implementation specific variables with a $ and never worry about
> clashing.
>
> Think of stuff like:
>
> a, b = (b, a)
>
> Above is not possible in JavaScript without a temporary variable. In pyjs
> this temporary variable would have a $ prefixed.
>
>
> I presume we do pyjamas because we love python and hence readable code.
>> Yet the generated Javascript seems less so, though from what I understand
>> there more readable alternatives.
>> So was just trying to understand what the thinking was.
>>
>
>
> I think a lot of attention wasn't paid to this because there are a lot of
> other more important things missing from pyjs that need attention.
>
>
>
>> Sarvi:
>> PS: Has this blog post been discussed on the list. Did any changes/action
>> items come out of it?
>>
>
>
> I don't remember if we discussed it or not but I can give you my take on a
> few of the bullet points:
>
> Browser Detection: He's right about the gwt/pyjamas stuff but this is
> irrelevant to pyjs core. As far as I know only one version of the compiled
> Python is generated. The Pyjamas/GWT library does have multiple versions
> per browser. Given that we plan to rip that out of pyjs core into it's own
> repository it will be for somebody else to deal with :-)
>
> Bloat and Boilerplate Hell: Without specifics this can't really be
> addressed. But my preference would be to rewrite pyjs from scratch with an
> eye on less boilerplate. I've started this to some degree and can send you
> what I have so far if you're interested.
>
> Debugging: Theoretically if it works in Python it should work in compiled
> JS too - if it doesn't, that's a bug in pyjs and not in your code. I've
> actually had very few issues with this (as long as I stayed within the
> limitation of pyjs). So I can't relate to Mr. Tsepkov on that point.
>
> Python is not Java, DOM is not a Desktop: We are taking the pyjamas/gwt
> stuff out of pyjs repository. This will encourage people to write their own
> frameworks/widget libraries for pyjs.
>
> JavaScript has its Strengths: Complaining mostly about the GWT stuff in
> pyjs.
>
>
> My impression from his article is that he relied too much on the widget
> library/gwt framework that comes with pyjs.
>
> I think pyjs can hit the sweet spot if you're willing to experiment with
> it and not relying too much on the gwt framework.
>
> You have access to the DOM and events in pyjs just as you do in
> JavaScript. In the article he implied that this was not the case.
>
> - lex
>
--
---
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.
