Just a bit of statistic I calculated based on this hacking
cat test1.py | wc -l # The python testcase
24
../../pyjsold/lpython/bin/pyjscompile test1.py | wc -l # As is today
131
cat t.js | wc -l
39
I understand it may not extrapolate exactly for everything.
Just shows there is much that can be improved in that direction.
Sarvi
On Tuesday, October 22, 2013 8:29:27 PM UTC-7, 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
> 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]>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.
