Is PyJs still alive?

[Sarvi Shanmugham]

The activity level seems to have gone way down. 

Most of the Demo sections seem to unusable. 

I was trying to convince a friend that Pyjamas is a good tool to use for web development, tried to show of the demos which fell flat.

Ended up looking the fool.:-(

I came back home and tried out the demo and realized there is a bug that has been filed 

https://github.com/pyjs/pyjs/issues/800

and has been untouched for about a month.

There hasn't been much response on the email alias either.

The last commit has been over 4 months ago.

Anyone one know whats going on?

Sarvi

[Glyph]

It seems like the original maintainers are quite busy, although they occasionally pop up and answer questions.

It seems like if every time someone asked a hand-wringing question about whether the project was "dying", or linked to a long-standing bug, they instead just went to submit a pull request to fix a bug, PyJS would be a super active, vibrant project :-). It's open source, if it's struggling, just pitch in a little bit and it will be struggling a bit less.

(And it seems to me that there are _plenty_ of people out there who might contribute a little if only there were more signs of life, so it's not like someone has to maintain the whole project. Just put in a little effort and I predict many more people will crawl out of the woodwork to help out...)

-glyph

[Sarvi Shanmugham]

Well, most successfull open source projects, there is always a lead or group of leads that are passionate about the project that drive things and then a whole bunch of fanboys who both use it and make occasional contribution of bugs they might find.

Can't think of one successfull open source project that did not have a passionate and active leads or group of leads maintaining and driving things.

And then I saw this http://technogems.blogspot.com/2013/08/can-pyjamas-rise-from-its-ashes.html blog post and I noticed that the git repo there was more active with commits.

And it looks like Pyjamas, a really wonderfull piece of work, that has so much potential, seems stuck between a rock and hard place. 

So much so that much inferier alternatives to this approach are gaining more steam than pyjamas. 

It saddens me to see it. Thats all.

Sarvi

 

-glyph

[Lex Berezhny]

I spent quite a bit of time with pyjs and built a fully functioning app. But now I'm slowly migrating to CoffeeScript with Backbone/Marionette because it's less restrictive, less buggy, easy to integration with other JS libraries, runs much faster and I've come to the conclusion that the initial benefit of being able to write once run anywhere of pyjs wasn't as beneficial - people prefer native clients for professional apps.

The other problem with pyjs is that we have too much scope creep. Pyjs is really a huge project: it's a compiler, a widget library and a platform that runs on linux, windows and mac. It's a lot to maintain without a clear direction or use case.

The effort to make pyjs a great project is just too overwhelming as it is.

We need to come up with a narrower scope and make a good argument for Pyjs of where it shines instead of trying to make it do everything and anything.

Glyph has pointed this out recently and I've mentioned it before as well: the biggest advantage of Pyjs is being able to share server side and client side code.

I think if we reduced the scope of the project significantly to just that specific use case it might stand a chance.

Here is my two cent recommendation/suggestion to save the project:

1. Compiler should become an independent core of pyjs.

1a. Support only python 3 class system/syntax.

1b. Use the built-in python parser instead of our own, this would eliminate a good chunk of the compiler code.

1c. Build the python runtime ontop of an existing JavaScript OOP runtime instead of having our own. Taking something that works and add the python semantics. Hopefuly this would also make integrating with other libs easier.

1d. Make 100% Python support mandatory and not just a goal. There were too many times that I was bitten by the conversion process where features either weren't supported or didn't behave as expected. I think if this project is going to become popular then 100% compatibility is absolutely critical, specifically MRO needs to work properly, if you add an attribute on a parent class, it should be visible in instances - right now basic things like that are broken.

2. Rip out the widget library. It should be a 3rd party project altogether outside of the pyjs repo. It's nice but not necessary to be productive. Pyjs is a web technology first and foremost.

3. Rip out the desktop-runtime components as independent projects within the pyjs repo. I think the concept is really cool but I just don't think the amount of effort that needs to go into this is available. Only a small percentage of people would use it this way.

3. Provide very close integration with popular server side technologies. I vote for Django and Twisted.

As it is, there is just too much code and it doesn't handle the common use case very well. I think the core pyjs project should only deal with the common use case and all of the extra stuff (widget libraries, desktop runtime, etc) could be add-ons.

What do you guys think? Should pyjs core be reduced to just a compiler, runtime and good integration with server side technologies? I'm thinking along the lines of Meteor but for Pyjs+Twisted and Pyjs+Django.

 - lex

[Łukasz Mach]

I think that most important in "list of things to save project" is:

0. make it installable by "pip install pyjs". I know so many developers,
which don't consider using library which they are not able to install
via pip.

W dniu 07.10.2013 22:02, Lex Berezhny pisze:

> Here is my two cent recommendation/suggestion to save the project:
>
> 1. Compiler should become an independent core of pyjs.
> 1a. Support only python 3 class system/syntax.
> 1b. Use the built-in python parser instead of our own, this would
> eliminate a good chunk of the compiler code.
> 1c. Build the python runtime ontop of an existing JavaScript OOP runtime
> instead of having our own. Taking something that works and add the
> python semantics. Hopefuly this would also make integrating with other
> libs easier.
> 1d. Make 100% Python support mandatory and not just a goal. There were
> too many times that I was bitten by the conversion process where
> features either weren't supported or didn't behave as expected. I think
> if this project is going to become popular then 100% compatibility is
> absolutely critical, specifically MRO needs to work properly, if you add
> an attribute on a parent class, it should be visible in instances -
> right now basic things like that are broken.

Won't it make runtime slower?

>
> 2. Rip out the widget library. It should be a 3rd party project
> altogether outside of the pyjs repo. It's nice but not necessary to be
> productive. Pyjs is a web technology first and foremost.

From other side - widget library is thing which can bring more users.
Of course, if it's fancy, glowy sparkling and working in examples :).

>
> 3. Rip out the desktop-runtime components as independent projects within
> the pyjs repo. I think the concept is really cool but I just don't think
> the amount of effort that needs to go into this is available. Only a
> small percentage of people would use it this way.
>
> 3. Provide very close integration with popular server side technologies.
> I vote for Django and Twisted.

Yep. It's very important IMHO - I just wrote small project django+pyjs
and it was big pain to make it working together (BTW - I want to make
pyjs+django bootstrap project in free time, problem is that there is no
free time last days ... :) ).


--
pozdrawiam

Łukasz Mach - lukas...@pagema.net

[Lex Berezhny]

On Mon, Oct 7, 2013 at 4:37 PM, Łukasz Mach <lukas...@pagema.net> wrote:

1d. Make 100% Python support mandatory and not just a goal. There were
too many times that I was bitten by the conversion process where
features either weren't supported or didn't behave as expected. I think
if this project is going to become popular then 100% compatibility is
absolutely critical, specifically MRO needs to work properly, if you add
an attribute on a parent class, it should be visible in instances -
right now basic things like that are broken.

Won't it make runtime slower?

For 100% compatibility I think a little slowness is worth it. We can also find ways to optimize it over time. As long as the code is modular and easy to do that with.

My original complaint about slowness was that it's slow right now *despite* not being 100% compatible. If it was compatible and slow at least there is an obvious/tangible compromise, you're giving something up to gain something. If it's not compatible but still slow, that just sucks in my opinion :-)

 

2. Rip out the widget library. It should be a 3rd party project
altogether outside of the pyjs repo. It's nice but not necessary to be
productive. Pyjs is a web technology first and foremost.

From other side - widget library is thing which can bring more users. Of course, if it's fancy, glowy sparkling and working in examples :).

Meteor has no widget library and it is a lot more popular than Pyjs.

jQuery became popular way before the jQuery UI project. Even still, lots of people use jQuery today without the UI module.

The truth is that Pyjs is a web technology first and foremost. If you know HTML/CSS sufficiently you can be as or even more productive than the folks trying to pigeon hole desktop style widget based technologies onto HTML.

Widgets are nice for prototyping but at the end of the day you should really learn HTML5/CSS.

For demo apps, we can just use Bootstrap. It's popular and has the bare bones essentials.

 

3. Provide very close integration with popular server side technologies.
I vote for Django and Twisted.

Yep. It's very important IMHO - I just wrote small project django+pyjs and it was big pain to make it working together (BTW - I want to make pyjs+django bootstrap project in free time, problem is that there is no free time last days ... :) ).

I'm willing to put my time towards Pyjs+Django+Bootstrap as well.

I think the first steps is to break the project up and then have people volunteer to pick up the pieces that are important to them.

I think it's easier to get the momentum going if you know others are working on different pieces and there is a common goal.

Anthony, can we create a plan of action, specifically agree/vote on a common use case and specific/practical mission statement so that we are all on the same page.

I think having a mission statement and core goals will help to make the project feel less overwhelming and if someone agrees with the philosophy of the project it will be easier for them to get behind it.

I'd be willing to put some effort into the Pyjs+Django integration if someone else seriously picked up the compiler/runtime.

Any takers to dive head first into compiler refactoring? I have a prototype of a runtime I did a while back that supported much better python MRO. The basic concept was to chain prototypes together to match the linear shape of the MRO. This meant that you could set an attribute on a super class and it was instantly available in an instance of a subclass (a simple use case that is not possible with current pyjs runtime). For most users this is not necessary but if you are building a framework it's critical to be able to do this kind of plumbing modification.

In fact, my advice would be to just do the compiler/runtime from scratch. If you base it on the built-in python parser lib you'd already eliminate probably half of the code in Pyjs. The bulk of the effort will then be the JS code generator and the runtime.

 - lex

[Steve Waterbury]

On 10/07/2013 05:30 PM, Lex Berezhny wrote:
> The truth is that Pyjs is a web technology first and foremost. If you
> know HTML/CSS sufficiently you can be as or even more productive than
> the folks trying to pigeon hole desktop style widget based technologies
> onto HTML.
>
> Widgets are nice for prototyping but at the end of the day you should
> really learn HTML5/CSS.

I think your "HTML5" == "the latest HTML stuff":
http://clubajax.org/html5-is-dead/
http://www.whatwg.org/specs/web-apps/current-work/multipage/
... or just "what the newest browsers actually do". ;)
The best summary of the current state I've seen is here:
https://rawgithub.com/whatwg/html-differences/master/Overview.html
The "Abstract" has it all in 6 sentences. But the whole document is
great for old-timers like me who need to catch up.

My Django/Pyjamas app makes full use of the widget libraries, along
with lots of CSS and almost zero HTML (I have an HTML index page that
loads a 4.5 MB script, period), but I'll grant that might not
be the best paradigm -- I *do* need to come up to speed on the latest
HTML stuff.

I've also done some little experiments with Django/REST using tastypie
that worked well, but there might be better REST libraries.

> Yep. It's very important IMHO - I just wrote small project
> django+pyjs and it was big pain to make it working together (BTW - I
> want to make pyjs+django bootstrap project in free time, problem is
> that there is no free time last days ... :) ).
>
> I'm willing to put my time towards Pyjs+Django+Bootstrap as well.

I did Pyjs+Django integration using json-rpc with
a slightly hacked version of Pimentech's "network.py" module from
libcommonDjango (referred to in the original Pyjamas docs). I would
be happy to contribute my hacks. I believe Pimentech released
libcommonDjango to the public domain.

> I think the first steps is to break the project up and then have people
> volunteer to pick up the pieces that are important to them.
>
> I think it's easier to get the momentum going if you know others are
> working on different pieces and there is a common goal.

IMO this is essential to the survival of pyjs.

Steve

[Łukasz Mach]

W dniu 08.10.2013 01:29, Steve Waterbury pisze:

> On 10/07/2013 05:30 PM, Lex Berezhny wrote:
>> The truth is that Pyjs is a web technology first and foremost. If you
>> know HTML/CSS sufficiently you can be as or even more productive than
>> the folks trying to pigeon hole desktop style widget based technologies
>> onto HTML.
>>
>> Widgets are nice for prototyping but at the end of the day you should
>> really learn HTML5/CSS.
>
> I think your "HTML5" == "the latest HTML stuff":
> http://clubajax.org/html5-is-dead/
> http://www.whatwg.org/specs/web-apps/current-work/multipage/
> ... or just "what the newest browsers actually do". ;)
> The best summary of the current state I've seen is here:
> https://rawgithub.com/whatwg/html-differences/master/Overview.html
> The "Abstract" has it all in 6 sentences. But the whole document is
> great for old-timers like me who need to catch up.
>
> My Django/Pyjamas app makes full use of the widget libraries, along
> with lots of CSS and almost zero HTML (

I agree with Lex that maybe pyjs (compiler) should be separated from
pyjamas (widget library), but I also believe that widget library is
essential, and is thing which will attract more users and more developers.

Simply, "look, you can write in python and it will run javascript" will
be never as sexy as "look, you can write nice app with dialogbox just
simple as that <simple example>".

And additional thought: I think that pyjd is dead end. Thing which:
works on Windows, but doesn't work on Debian, works on Ubuntu but
requires downloading some library and compiling it yourself, I don't
believe any of my app users would do such things ...

Having ability to run application cross browser/desktop is very useful,
but I think it should use toolkits like Qt or wxPython (so some of
pyjamas classes would be wrappers on qt/wx classes, in desktop mode).

[Steve Waterbury]

On 10/08/2013 05:23 AM, Łukasz Mach wrote:
> I agree with Lex that maybe pyjs (compiler) should be separated from
> pyjamas (widget library), but I also believe that widget library is
> essential, and is thing which will attract more users and more developers.

I agree that a separation might be a good idea. That said,
the widget library, while useful as it is, needs work.

> And additional thought: I think that pyjd is dead end. Thing which:
> works on Windows, but doesn't work on Debian, works on Ubuntu but
> requires downloading some library and compiling it yourself, I don't
> believe any of my app users would do such things ...
>
> Having ability to run application cross browser/desktop is very useful,
> but I think it should use toolkits like Qt or wxPython (so some of
> pyjamas classes would be wrappers on qt/wx classes, in desktop mode).

I completely agree with all this (had it in my message but edited it ;).
To me pyjd has been something of an "emperor's new clothes" thing --
like ... really??

Steve

[Glyph]

On Oct 7, 2013, at 1:02 PM, Lex Berezhny <l...@berezhny.com> wrote:

Here is my two cent recommendation/suggestion to save the project:

Here are my recommendations to save the project:

1. Fix bugs.
2. Add features.

:-)

I think the list of things you've proposed are all possibly good ideas (particularly, I think "100% compatibility with Python" is really important).  However, changing project structure around and setting project policy are not going to increase the amount of work done if nobody is available to do the work or interested in doing it.  If there is any lesson from the recent "hijacking" (as the blog post so dramatically put it) it is that just adopting new development tools or practices will not necessarily fix any problems.

The important thing is to just keep actually writing code, submitting pull requests, commenting on bugs and generally moving things forward one little piece at a time.  Form should follow function: if the project structure impedes that happening, then it should be changed, but otherwise it is probably fine.

Narrowing the focus is only useful if there are lots of people doing work but the effort is dissipating because it's not being concentrated in a useful / exciting area, and they're getting demotivated.  Setting goals is only useful if people are going to do some work but don't know what to work on.

It's tempting to try to sketch some Big Ideas (and it can provide some motivation, so I wouldn't say not to do it at all!) but I would definitely caution against trying to debate these back and forth endlessly rather than just submitting one or two small pull requests to try to move things forward.

Things like splitting out the widget library into a separate project from the language translator might be more useful later, especially if PRs that fix language things end up being blocked on widget-library things.  Doing that by itself, though, definitely won't fix anything by itself, and I can prove it, because someone already did that and it didn't work: <https://pypi.python.org/pypi/pyjsmin/>.  You can see it's been twice as long since someone has committed to that: <https://github.com/nathants/pyjsmin>.  Splitting out the code in such a way that both things still work is itself a bunch of effort, and only worth doing if it is really holding things back.

So, initially at least, rather than a general, negative focus (let's rip out the widget library! let's simplify the project!) I think these discussions should center around a specific, positive focus (let's make the language runtime more python-compliant by fixing <https://github.com/pyjs/pyjs/issues/799> and <https://github.com/pyjs/pyjs/issues/787>!  let's make it more accessible by fixing <https://github.com/pyjs/pyjs/issues/742>!).

If those just happen to be the bugs I've filed, it's because they're totally the most important bugs that should be fixed immediately ;-).

-glyph

[Glyph]

On Oct 7, 2013, at 4:29 PM, Steve Waterbury <wate...@pangalactic.us> wrote:

I think it's easier to get the momentum going if you know others are
working on different pieces and there is a common goal.

IMO this is essential to the survival of pyjs.

Well it sounds like several people are interested in working on things, so I am optimistic about the survival of PyJS :-).

(By the way I'm idling on #pyjs on Freenode, and the channel is pretty empty.  If any of you are on IRC, it might be good to hang out there just to provide a sense of someone "being there" for the ongoing project...)

-glyph

[Kees Bos]

Thanks Glyph. That's exactly what I was waiting for. I'd like to add one other important thing for keeping pyjs going:

3 Some people willing to answer (dumb or not so dumb) questions. Preferably a native speaker, but not necessarily.

I've been extremely busy, as I know others will have been too (not just at work but also in my spare-time). Didn't use pyjs for a while (personally, though we're using it in our company and depend on it).

There's a different translator available, which is in principle way more pythonic in accessing attributes. The default translator is 'proto'. It depends on the javascript way of creating classes (using 'prototype'), which binds attributes on defining the class. The other translator is 'dict' (--use-translator=dict), which resolves the attributes runtime. (Note, I just committed a fix to get this translator going again). This is in most cases somewhat slower. It lacks the support of generators (i.e. yield statement) and is a total re-implementation. If this is something people are waiting for, I'll pick this up again and implement yield (will probably take 16 to 24 hours of work). So, maybe you (Glyph) and Lex (and others if they need this) can have a look if it is worthwhile or not.

BTW dropping support for old-style classes is impossible. We don't support them currently. The syntax is supported, but they are handled as subclasses of object (new-style classes).

- Kees

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

[Glyph]

On Oct 9, 2013, at 12:00 AM, Kees Bos <cornel...@gmail.com> wrote:

Thanks Glyph. That's exactly what I was waiting for.

Thanks for saying so!  I feel bad about not having much time to help, so it's nice to know that my small contribution on the list was useful.

I'd like to add one other important thing for keeping pyjs going:

Some people willing to answer (dumb or not so dumb) questions. Preferably a native speaker, but not necessarily.

I've tried to help out with a couple of such questions on this list.  I still don't know a whole lot about PyJS though.  It seems there is more activity lately, both with people asking and with others answering.  So that's a good sign.

(Note, I just committed a fix to get this translator going again).

Yay!  So now PyJS is down from a couple of months to a couple of hours since the last commit :-).

-glyph

P.S.: I just wrote something on ThoughtStreams that mentioned PyJS: <https://thoughtstreams.io/glyph/why-is-nodejs-popular/>.

[Kees Bos]

On Sun, 2013-10-06 at 15:33 -0700, Sarvi Shanmugham wrote:
>
> The activity level seems to have gone way down.
> Most of the Demo sections seem to unusable.
> I was trying to convince a friend that Pyjamas is a good tool to use
> for web development, tried to show of the demos which fell flat.
> Ended up looking the fool.:-(
>
>
> I came back home and tried out the demo and realized there is a bug
> that has been filed
> https://github.com/pyjs/pyjs/issues/800
>

Just to be sure. You tested with chromium for windows?

I think we hit a bug in chromium for windows here (linux version is OK).

The helloworld example throws an maximum call stack size exceeded,
unless the patch below is applied. It just adds a debugger statement,
which should have no effect...


diff --git a/pyjs/src/pyjs/builtin/pyjslib.py b/pyjs/src/pyjs/builtin/pyjslib.py
index f1ba055..0825a79 100644
--- a/pyjs/src/pyjs/builtin/pyjslib.py
+++ b/pyjs/src/pyjs/builtin/pyjslib.py
@@ -2089,7 +2089,12 @@ var $radix_regex = [
}
radix = null;
}
- if (typeof this != 'object' || this['__number__'] != 0x02) return new $int(value, radix);
+ if (typeof this != 'object' || this['__number__'] != 0x02) {
+ // The debugger statement seems to be needed for chromium
+ // for windows...
+ debugger;
+ return new $int(value, radix);
+ }
if (value['__number__']) {
if (radix !== null) throw @{{TypeError}}("int() can't convert non-string with explicit base");
v = value['valueOf']();

[C Anthony Risinger]

On Thu, Oct 10, 2013 at 7:08 AM, Kees Bos <cornel...@gmail.com> wrote:

On Sun, 2013-10-06 at 15:33 -0700, Sarvi Shanmugham wrote:
>
> The activity level seems to have gone way down.
> Most of the Demo sections seem to unusable.
> I was trying to convince a friend that Pyjamas is a good tool to use
> for web development, tried to show of the demos which fell flat.
> Ended up looking the fool.:-(
>
>
> I came back home and tried out the demo and realized there is a bug
> that has been filed
> https://github.com/pyjs/pyjs/issues/800
>

Just to be sure. You tested with chromium for windows?

I think we hit a bug in chromium for windows here (linux version is OK).

i actually get the same error when i try to visit pyj.be on linux, so it may not be windows only, or possible more than one issue throwing the same exception.

--

C Anthony

[Kees Bos]

Which version of chromium? (chrome://version)

I'm using 28.0.1500.71 (Developer Build 28.0.1500.71-0ubuntu1.12.10.1)
Ubuntu 12.10

[C Anthony Risinger]

interestingly, it just worked once(?), then stopped working again for every refresh (10+) after that with:

website RangeError: Maximum call stack size exceeded

i using "30.0.1599.66 (Developer Build 225456)" on Arch Linux.

[C Anthony Risinger]

i forgot to mention the guy in bug report is also using version 30+ ...not sure when chromium switched over to Blink vs. Webkit, but maybe it's blink only, or v29+/v30+ issue (as you implied v28 works fine)

--

C Anthony

[Sarvi Shanmugham]

Mine is Chrome(Version 30.0.1599.69) on MacOS 10.8.3

Yes I noticed it on pyj.be as well. 

[Sarvi Shanmugham]

Yes I much as I agree with some of the sentiment that we shouldn't be wasting our time on reorganizing/splitting to some extend.

I am drawn to the example of Flask Vs Django. Both are great projects.

But I like flask for its simplicity and the option to pull and use what I want.

It also allows different people to focus on what they want, say just the pyjs compiler, just the gwt widget set, or a different widget set or pyjd etc

The ones that don't get too much love will die on their own without leaving much dead code, like I see now.

And the ones that survive and thrive, can always be organized together using pip install dependencies to work as a single pull for convenience

My 2 c,

Sarvi

[Lex Berezhny]

My sentiment exactly! :-D