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