pyjaco Vs pyjamas compiler

[Sarvi Shanmugham]

What s the difference between the pyjaco and the pyjs compilers.

From what I can read on the various blogs, the pyjs compiler is more full featured but I hear has whole laundry list of problems one of the bloggers had posted. He had also compared other alternatives as well.

I also notice that pyjaco was listed as much better than the pyjs compiler in these areas.

Plus pyjaco seems to be active development.

I understand pyjamas is much more than just the pyjs compiler.

Questions:
    1. Does pyjaco generate more efficient in speed and size?
    2. Can the pyjaco compiler replace the pyjs compiler and if not what would be missing. That would leave pyjamas to focus on the gwt widget sets in python as well as pyjd. Does this make sense.
    3. As of now the pyjs tool and widgets set produces very large JavaScript code. Someone mentioned 30M for hello world program uncompressed. What are the root causes for this bloat and is there any work happening in this area. And there was a thread on the Pyjs newsgroup that claimed that the latest gwt compiler produced java script code that was 200kb of javascript while the an equivalently features application using pyjamas generated 5Mb of javascript.  Is this a problem with the python-to-javascript compiler OR is it python translation of the GWT code that causes this difference in size.

Why do I ask. 
   1. I plan to use pyjamas and/or pyjaco and find this approach to development exciting.
    2. I have a very small budget that I plan to use for improvements to the toolset. In my opinion on things like efficiency of the generated code as well as gwt version upgrade. And have junior a engineer from India that I am funding that I was thinking of assigning to this task. Don't expect magic from him, he is no Luke or Kees Bos but I expect him to learn and contribute in whatever way possible.

    3. I know I want the GWT widget set in python. But I am trying to decide which python-to-javascript compiler is the better bet going forward.

Thanks
Sarvi

[Dexter]

On Fri, Dec 21, 2012 at 12:32 PM, Sarvi Shanmugham <sarv...@gmail.com> wrote:

What s the difference between the pyjaco and the pyjs compilers.

What I take, (Christian or Samuel should correct me here) is that pyjaco is a fork of pyjs. Currently Im working on a new codebase which tries to replace the current compiler.

 

From what I can read on the various blogs, the pyjs compiler is more full featured but I hear has whole laundry list of problems one of the bloggers had posted. He had also compared other alternatives as well.

I also notice that pyjaco was listed as much better than the pyjs compiler in these areas.

That could be because pyjaco is newer. 

Plus pyjaco seems to be active development.

I understand pyjamas is much more than just the pyjs compiler.

I have no experience with pyjamas, but it is a gwt port as I view it. pyjamas has a compiler, but I've never looked into it. Pyjamas on itself is an entire framework. 

Questions:
    1. Does pyjaco generate more efficient in speed and size?

I have no reference between the two, I cant say anything about the speed. I would think that pyjaco is smaller, because we focus on bringing javascript as close to python as possible. With the help of a library. 

    2. Can the pyjaco compiler replace the pyjs compiler and if not what would be missing. That would leave pyjamas to focus on the gwt widget sets in python as well as pyjd. Does this make sense.

I dont know what you try to achieve here? 

    3. As of now the pyjs tool and widgets set produces very large JavaScript code. Someone mentioned 30M for hello world program uncompressed. What are the root causes for this bloat and is there any work happening in this area. And there was a thread on the Pyjs newsgroup that claimed that the latest gwt compiler produced java script code that was 200kb of javascript while the an equivalently features application using pyjamas generated 5Mb of javascript.  Is this a problem with the python-to-javascript compiler OR is it python translation of the GWT code that causes this difference in size.

I cant say anything other than 5 million characters is a lot. It must be a big codebase that is compiled. 

Why do I ask. 
   1. I plan to use pyjamas and/or pyjaco and find this approach to development exciting.
    2. I have a very small budget that I plan to use for improvements to the toolset. In my opinion on things like efficiency of the generated code as well as gwt version upgrade. And have junior a engineer from India that I am funding that I was thinking of assigning to this task. Don't expect magic from him, he is no Luke or Kees Bos but I expect him to learn and contribute in whatever way possible.

    3. I know I want the GWT widget set in python. But I am trying to decide which python-to-javascript compiler is the better bet going forward.

I dont know how the gwt widget set would work with python, maybe you can expand on this. Any help on the pyjaco is always welcome ofcourse. 

Thanks
Sarvi

--
You are subscribed to the Google Group pyj...@googlegroups.com
To unsubscribe from this group, send email to
pyjaco+un...@googlegroups.com

[Samuel Ytterbrink]

When you say pyjs, do you meen the compiler in pyjamas or the pyjs project?

2012/12/21 Dexter <a.ess...@gmail.com>

--
//Samuel Ytterbrink

[Sarvi Shanmugham]

Sorry for the confustion. Everywhere I mention pyjs in this thread I mean the python to java compiler in the pyjamas project.

Also, I think Pyjamas goes by the name pyjs now

pyjs.org

In my understand pyjamas/pyjs.org consists of 2 pieces

  1. a python translation of the GWT widget set

  2. a python to javascript compiler

Its 2 above that I am comparing with pyjaco. And considering 2 above is more full featured. Why not invest more in optimizing that. 

From what I can tell yall are optimzing/rewriting pyjaco now. Wouldn't this effort be better spent improving 2 above.

I ask because I see this python to javascript compiler works already fragmented enough. I see a lot of interest. But everyone has their implementation. none of which is very optimized, user frields or great. If only we could regroup around one compiler implementation.

Sarvi 

Note: I have posted this same question on the pyjs-users group as well.. Do look to see what they are saying on this topic.

[Sarvi Shanmugham]

Long question short

I am trying to understand what drove pyjaco to fork off and not build on the compiler that comes with pyjamas??

Specially considering yall are reworking the entire pyjaco compiler now.

Sarvi

[Samuel Ytterbrink]

We are no fork of pyjamas.

Pyjamas and its compiler are quite different, it's more of a wrapper then a python translator. Where you need to inline JavaScript to make the program work.

 We are however a fork of py2js. And this rework have been planed for about 1 year (Ivers, am I correct?). And there are a lot of reasons for it.

I however are more or less in a completely different camp then both you and the average pyjaco developer. Learn javascript! A good JavaScript programmer is the best python to JavaScript compiler there is.

--

You are subscribed to the Google Group pyj...@googlegroups.com
To unsubscribe from this group, send email to
pyjaco+un...@googlegroups.com

--
//Samuel Ytterbrink

[Sarvi Shanmugham]

Ok. It good to know that its not a fork.

That said, Not sure what you mean by " it's more of a wrapper then a python translator. Where you need to inline JavaScript to make the program work"

From the little I have played around with, I didn't have to inline any java script code. The entire sample programs I coded were pure python. 

So is their kitchensink demo which showcases all of their python GUI widgets(translated to python from java)

This demo was also fully python from what I can tell.

From what I hear its a more complete python implementation than py2js or pyjaco at present. Hence my question of why aren't we investing in improving/optimizing it than starting from scratch? Just trying to understand the reasoning behind the choices.

Does pyjaco plan on being a close to full python implementation as the pyjamas compiler is, or does it aim to be a more limited  implementation?

Sarvi

pyjaco+unsubscribe@googlegroups.com

--
//Samuel Ytterbrink

[Samuel Ytterbrink]

If you dig into the source code of the classes you use in those examples you will find JavaScript.

That's why pyjamas needs a framework. Since its in the framework you have the compatibility layer for the JavaScript env.

My personal experience with Pyjamas is that it's not feature compleat and that it's hard to debug  when things don't work. I was at that time trying to help but got into a not so nice discussion  with Luke. I have heard however that the community have improved the renascent 2 years.

--
//Samuel Ytterbrink

[Sarvi Shanmugham]

Cool. So does that mean

   1. pyjaco plans/intends to be a more feature complete python to javascript compiler?

   2. I can use pyjaco to compile the python based GWT widget set?

Sarvi

[Samuel Ytterbrink]

1. in a way, We want to as much as possible fully support the "__" methods and other cools stuffs from python. This was atleast 2 years ago quite limited in Pyjamas.

2. no you cant since you have javascript in the Pyjamas widgets and you have no javascript in the code you compie with pyjaco.

2012/12/21 Sarvi Shanmugham <sarv...@gmail.com>

--

You are subscribed to the Google Group pyj...@googlegroups.com
To unsubscribe from this group, send email to

pyjaco+un...@googlegroups.com

--
//Samuel Ytterbrink

[Samuel Ytterbrink]

Then a lot of things have changed, when i last heard of pyjd it was done by using a javascript motor with python bindings... and was far from javascript clean.

2012/12/21 <eukr...@gmail.com>

pyjd

--
//Samuel Ytterbrink

[Samuel Ytterbrink]

can you enlighten me on how the DOM api is used from pyjs?

2012/12/21 <eukr...@gmail.com>

On Friday, December 21, 2012 10:49:28 AM UTC-5, Neppord wrote:

1. in a way, We want to as much as possible fully support the "__" methods and other cools stuffs from python. This was atleast 2 years ago quite limited in Pyjamas.

Here is the available compile time configuration options (we have discussed the idea of using decorators to apply some of these options on specific functions, for example if you use get/set attribute overloading on object but have some complex computational function and you want to avoid the extra attribute lookup calls you would be able to decorate that function to avoid wrapping each get/set operating in a function call and instead resort to native javascript attribute access, eg: obj.attr (cant tie in python machinery) insead of obj.get(attr) (ties into python machinery but now includes extra function call):

$ ./pyjscompile --help

Usage: 

  usage: pyjscompile [options] file...

Options:

  -h, --help            show this help message and exit

  -o OUTPUT, --output=OUTPUT

                        Place the output into <output>

  -m MODULE_NAME, --module-name=MODULE_NAME

                        Module name of output

  -i, --list-imports    List import dependencies (without compiling)

  -D, --enable-default  (group) enable DEFAULT options

  -d, --enable-debug    (group) enable DEBUG options

  -O, --enable-speed    (group) enable SPEED options, degrade STRICT

  -S, --enable-strict   (group) enable STRICT options, degrade SPEED

  --enable-wrap-calls   enable call site debugging [False]

  --enable-print-statements

                        enable printing to console [True]

  --enable-check-args   enable function argument validation [False]

  --enable-check-attrs  enable attribute validation [False]

  --enable-accessor-proto

                        enable __get/set/delattr__() accessor protocol [True]

  --enable-bound-methods

                        enable proper method binding [True]

  --enable-descriptor-proto

                        enable __get/set/del__ descriptor protocol [False]

  --enable-track-sources

                        enable tracking original sources [False]

  --enable-track-lines  enable tracking original sources: every line [False]

  --enable-store-sources

                        enable storing original sources in javascript [False]

  --enable-inline-code  enable bool/eq/len inlining [False]

  --enable-operator-funcs

                        enable operators-as-functions [True]

  --enable-number-classes

                        enable float/int/long as classes [False]

  --enable-locals       enable locals() [False]

  --enable-stupid-mode  enable minimalism by relying on javascript-isms

                        [False]

  --use-translator=TRANSLATOR

                        override translator [proto]

--
You are subscribed to the Google Group pyj...@googlegroups.com
To unsubscribe from this group, send email to
pyjaco+un...@googlegroups.com

--
//Samuel Ytterbrink

[Sarvi Shanmugham]

In light of this better understanding of the pyjs compiler, does it still make sense to have a split community?

Wouldn't it be better to have a joint javascript compiler development effort. 

Specially since there is talk of completely redesigning the pyjaco compiler. Seem the right to time to take stock and change course.

Personally it doesn't matter which compiler stays, pyjaco or the pyjs compiler.

But from what I am hearing so far the pyjs compiler is more feature complete in all respects. While it can still recieve some more love and improvements.

I've read a very good blog post that analyses and differentiates the python-javascript tooling landscape.

Though it lists what is lacking in pyjs, it doesn't claim any architectural limitations from what I can understand.

So unless there is some really bad technical or architectural issues with the pyjs compiler, wouldn't it make sense that the community coalesce around the pyjs compiler and make it better instead of starting with a fresh design?

If there are could someone talk about it?

We could even organize a separate development track and code base for the pyjs compiler separate from the pyjs framework development which should be independent anyway.

What do yall think?

 

Sarvi

[Sarvi Shanmugham]

I just read one of the blog posts where Alexander Tsepkov talks about the issues with Pyjamas and also notice Christian Iversons comments on the blog.

So if its true that the pyjs compiler generates a lot more code bloat and the pyjaco compiler does not.

Do we know roughly what the LOC difference is between the 2 compilers?

What would it take for the pyjaco compiler to compile the pyjamas python code base? Has anyone tried?

Sarvi

[Samuel Ytterbrink]

Don't you think you are a little bit rude? And what about diversity?

A project I would spend my time on if I had any would be the pypy JavaScript backend. There's a project which could become speedy! Also it has an even larger community! And you would get python 2.x and 3.x. It also already have lots of funding, not in the JavaScript area, but it will not go dead.

//Samuel Ytterbink

--
//Samuel Ytterbrink

[Sarvi Shanmugham]

I didn't mean to be rude here nor do I think asking meaningful questions can be considered rude.
I notice there is a lot interest in a good implementation of a python to JavaScript compiler so trying to communicate across multiple different groups trying to address the same problem, trying to understand the differences, and trying to bridge the communication gap between these different efforts was my intention.

I am going with the assumption people don't choose reinvent the wheel intentionally. It usually happens due to the lack of proper information or communication.

I am aware of the pypy project and its toy JavaScript backend. Now that you mention it that would be an excellent way to achieve this goal. Do you know anyone who is working on that backend.

Have you suggested this to either the pyjaco team or one of the other teams working on python to JavaScript?

Sarvi

[Samuel Ytterbrink]

What is rude is to ask people that have worked hard to leave there progress to work one something for your own benefit. Especially it's rude to not think that there is reasons for them to start some thing they have put a lot of effort. 

Any ways. The javascript backend on pypy have been dead for long time. No one is working on it. It has died for 2 reasons that i know of. 

1. It is old and at the time the project was moving to fast for it to keep up. As a backend it could not continue to support the front end. 

2. It has never been able to compile pypy completely and was only intended to compile   Rpython. So it whas never widely used. 

And I have not suggested it to any other team than my own. I think that it's quite rude to assume that people don't care about there own projects.  That they haven't done the research them self, and there for have no good reasons for what they do. 

Don't get me wrong askinq what's the difference is one thing, and totally normal. but asking that we should abandon this project for another.

You need to be a little bit more diplomatic then that. Otherwise you might get the opposite effect. 

Also don't belive every thing you read on blogs. They might have been lazy. 

Sorry for any miss spellings, writing on a phone and I'm about the miss a train.

(And I forgot to switch to English keayboard)

Have a nice Holliday every one.

--
You are subscribed to the Google Group pyj...@googlegroups.com
To unsubscribe from this group, send email to
pyjaco+un...@googlegroups.com

--
//Samuel Ytterbrink

[Sarvi Shanmugham]

I presumed I was making this suggestion for the benefit of the whole community working towards a good python to jacascript compiler. Not my own.

People don't choose to reinvent the wheel just for fun, but because they feel a need for it or they feel something is missing or if its not convenient.

At least based on this thread, my understanding was that there were some misconceptions of the pyjamas compiler that was just clarified. Plus some changes have happenned in leadership as well that might be considered more favourable as well. So I felt people might want to rethink their strategy.

Me personally was trying understand the reasons for the community split but more importantly to understand where to put additional effort and why?

Sorry if I came as rude. That wasn't my intention

Sarvi