Re: [web2py] pulsar

[Massimo Di Pierro]

They say it runs on windows. If this is written in pure python could be 
used as a portable solution to tornado for websockets.

On Friday, 4 January 2013 16:18:31 UTC-6, Niphlod wrote:
>
> nodejs vs gevent+monkey_patching allows you to USE "EV" (please bear with 
> me, from now on "EV" means just a programming pattern - google for that): 
> apis, websockets, streaming, etc. usually are the best fit for that. 
> Everything that needs either: 
> - a lot of concurrent connections
> - a lot of opened connections streaming data
> usually works better with "EV". 
>
> That being said, my point was barely that having your traditional app 
> running on gevent might not be as fast as a traditional nodejs app..and 
> that's just because "traditional" in python doesn't - normally - mean EV 
> patterns, while node (javascript, to be fair) "forces" you to use that kind 
> of patterns (and so ALL libraries, modules, etc are optimized/engineered to 
> exploit all the possibilities of EV).
>
> Running python code engineered to be EV in the first place coupled with 
> gevent might be as fast as a nodejs app, but really, my point is *not* a 
> matter on what framework gives you the most speed (I'd bet an Erlang app 
> trumps nodejs).
>
> It's just stating that evented webservers in python are a nice thing to 
> have because without changing a single line of your "normal" code many 
> things are improved in speed terms (running on pypy, e.g. it's another 
> simple step to look to), but if you want to match performances of other 
> tools "more targeted to that job", your app code needs to change a lot too. 
>
>
> On Friday, January 4, 2013 7:37:26 PM UTC+1, Vasile Ermicioi wrote:
>>
>> thank you for your thoughts,
>>
>> may be there are scenarios where evented frameworks shine, but nodejs is 
>> a web framework, 
>> so in this scenario the main advantage is that requests don't block each 
>> other, 
>> so my question is regarding only this scenario: 
>> what advantage of using nodejs over gevent monkey patching for building 
>> websites?
>> any examples?
>>
>> On Fri, Jan 4, 2013 at 7:01 PM, Niphlod  wrote:
>>
>>> because for really exploiting evented frameworks you need to code 
>>> "evented-ly" also your app.
>>>
>>> Programming languages (also big frameworks like e.g. twisted) that "by 
>>> default" have strong support for actors, events, light threads, and so on 
>>> (and also for that reason, generally harder to grasp-create-maintain-adopt) 
>>> are a level up if confronted with "python+gevent monkeypatching", because 
>>> all code in apps and modules and libraries is tailored to that kind of 
>>> programming style (and requirements).
>>>
>>> Having wsgi frameworks that run "in the evented way" is the first step - 
>>> really nice one, but still one - down to the rabbit hole.they solve the 
>>> issue and the shortcomings of "communicating with the outside", but your 
>>> code needs to be refactored if you want to step up a level. 
>>>
>>>
>>> Il giorno venerdì 4 gennaio 2013 17:38:55 UTC+1, Vasile Ermicioi ha 
>>> scritto:
>>>
 a while ago I saw vert.x  (it is on top of jvm) , now that,
 and a question raised in my mind:
 why do I need nodejs or evented frameworks, if importing gevent and 
 monkey patching makes everything non blocking?

 celery and other goods are already in web2py frameworks, 
 so what are your thoughts?


>>>  -- 
>>>  
>>>  
>>>  
>>>
>>
>>

-- 

Re: [web2py] pulsar

[Niphlod]

nodejs vs gevent+monkey_patching allows you to USE "EV" (please bear with 
me, from now on "EV" means just a programming pattern - google for that): 
apis, websockets, streaming, etc. usually are the best fit for that. 
Everything that needs either: 
- a lot of concurrent connections
- a lot of opened connections streaming data
usually works better with "EV". 

That being said, my point was barely that having your traditional app 
running on gevent might not be as fast as a traditional nodejs app..and 
that's just because "traditional" in python doesn't - normally - mean EV 
patterns, while node (javascript, to be fair) "forces" you to use that kind 
of patterns (and so ALL libraries, modules, etc are optimized/engineered to 
exploit all the possibilities of EV).

Running python code engineered to be EV in the first place coupled with 
gevent might be as fast as a nodejs app, but really, my point is *not* a 
matter on what framework gives you the most speed (I'd bet an Erlang app 
trumps nodejs).

It's just stating that evented webservers in python are a nice thing to 
have because without changing a single line of your "normal" code many 
things are improved in speed terms (running on pypy, e.g. it's another 
simple step to look to), but if you want to match performances of other 
tools "more targeted to that job", your app code needs to change a lot too. 


On Friday, January 4, 2013 7:37:26 PM UTC+1, Vasile Ermicioi wrote:
>
> thank you for your thoughts,
>
> may be there are scenarios where evented frameworks shine, but nodejs is a 
> web framework, 
> so in this scenario the main advantage is that requests don't block each 
> other, 
> so my question is regarding only this scenario: 
> what advantage of using nodejs over gevent monkey patching for building 
> websites?
> any examples?
>
> On Fri, Jan 4, 2013 at 7:01 PM, Niphlod >wrote:
>
>> because for really exploiting evented frameworks you need to code 
>> "evented-ly" also your app.
>>
>> Programming languages (also big frameworks like e.g. twisted) that "by 
>> default" have strong support for actors, events, light threads, and so on 
>> (and also for that reason, generally harder to grasp-create-maintain-adopt) 
>> are a level up if confronted with "python+gevent monkeypatching", because 
>> all code in apps and modules and libraries is tailored to that kind of 
>> programming style (and requirements).
>>
>> Having wsgi frameworks that run "in the evented way" is the first step - 
>> really nice one, but still one - down to the rabbit hole.they solve the 
>> issue and the shortcomings of "communicating with the outside", but your 
>> code needs to be refactored if you want to step up a level. 
>>
>>
>> Il giorno venerdì 4 gennaio 2013 17:38:55 UTC+1, Vasile Ermicioi ha 
>> scritto:
>>
>>> a while ago I saw vert.x  (it is on top of jvm) , now that,
>>> and a question raised in my mind:
>>> why do I need nodejs or evented frameworks, if importing gevent and 
>>> monkey patching makes everything non blocking?
>>>
>>> celery and other goods are already in web2py frameworks, 
>>> so what are your thoughts?
>>>
>>>
>>  -- 
>>  
>>  
>>  
>>
>
>

-- 

Re: [web2py] pulsar

[Vasile Ermicioi]

thank you for your thoughts,

may be there are scenarios where evented frameworks shine, but nodejs is a
web framework,
so in this scenario the main advantage is that requests don't block each
other,
so my question is regarding only this scenario:
what advantage of using nodejs over gevent monkey patching for building
websites?
any examples?

On Fri, Jan 4, 2013 at 7:01 PM, Niphlod  wrote:

> because for really exploiting evented frameworks you need to code
> "evented-ly" also your app.
>
> Programming languages (also big frameworks like e.g. twisted) that "by
> default" have strong support for actors, events, light threads, and so on
> (and also for that reason, generally harder to grasp-create-maintain-adopt)
> are a level up if confronted with "python+gevent monkeypatching", because
> all code in apps and modules and libraries is tailored to that kind of
> programming style (and requirements).
>
> Having wsgi frameworks that run "in the evented way" is the first step -
> really nice one, but still one - down to the rabbit hole.they solve the
> issue and the shortcomings of "communicating with the outside", but your
> code needs to be refactored if you want to step up a level.
>
>
> Il giorno venerdì 4 gennaio 2013 17:38:55 UTC+1, Vasile Ermicioi ha
> scritto:
>
>> a while ago I saw vert.x  (it is on top of jvm) , now that,
>> and a question raised in my mind:
>> why do I need nodejs or evented frameworks, if importing gevent and
>> monkey patching makes everything non blocking?
>>
>> celery and other goods are already in web2py frameworks,
>> so what are your thoughts?
>>
>>
>  --
>
>
>
>

-- 

Re: [web2py] pulsar

[Niphlod]

because for really exploiting evented frameworks you need to code 
"evented-ly" also your app.

Programming languages (also big frameworks like e.g. twisted) that "by 
default" have strong support for actors, events, light threads, and so on 
(and also for that reason, generally harder to grasp-create-maintain-adopt) 
are a level up if confronted with "python+gevent monkeypatching", because 
all code in apps and modules and libraries is tailored to that kind of 
programming style (and requirements).

Having wsgi frameworks that run "in the evented way" is the first step - 
really nice one, but still one - down to the rabbit hole.they solve the 
issue and the shortcomings of "communicating with the outside", but your 
code needs to be refactored if you want to step up a level. 


Il giorno venerdì 4 gennaio 2013 17:38:55 UTC+1, Vasile Ermicioi ha scritto:
>
> a while ago I saw vert.x  (it is on top of jvm) , now that,
> and a question raised in my mind:
> why do I need nodejs or evented frameworks, if importing gevent and monkey 
> patching makes everything non blocking?
>
> celery and other goods are already in web2py frameworks, 
> so what are your thoughts?
>
>

-- 

Re: [web2py] pulsar

[Vasile Ermicioi]

a while ago I saw vert.x  (it is on top of jvm) , now that,
and a question raised in my mind:
why do I need nodejs or evented frameworks, if importing gevent and monkey
patching makes everything non blocking?

celery and other goods are already in web2py frameworks,
so what are your thoughts?

-- 

Re: [web2py] pulsar

[Niphlod]

yep. Benchmarks apart, if "reacts" in an evented way could be the only 
thing working like that in Windows natively (a user a while ago posted in 
this list a repackage of tornado called motor that worked very well too. 
Sadly, not really largely supported).

I'm curious about the implications of running with multiprocessing in 
Windows, I'd bet that is available only on Linux (thanks to the fork() 
availability). But if this will be adopted by some percentage of 
peoples well, I'll definitely look into that.


Il giorno venerdì 4 gennaio 2013 15:31:07 UTC+1, Alec Taylor ha scritto:
>
> Interesting.
>
> Would be useful to also compare it with other similar—or subset 
> covering—functionality frameworks such as:
>
>- Tornado 
>- Twisted Matrix  
>
> Or any of these frameworks: 
> http://wiki.python.org/moin/Concurrency#Frameworks
> On Sat, Jan 5, 2013 at 1:21 AM, Massimo Di Pierro 
> 
> > wrote:
>
>> http://packages.python.org/pulsar/overview.html
>>
>> -- 
>>  
>>  
>>  
>>
>
>

-- 

Re: [web2py] pulsar

[Alec Taylor]

Interesting.

Would be useful to also compare it with other similar—or subset
covering—functionality frameworks such as:

   - Tornado 
   - Twisted Matrix 

Or any of these frameworks:
http://wiki.python.org/moin/Concurrency#Frameworks
On Sat, Jan 5, 2013 at 1:21 AM, Massimo Di Pierro <
massimo.dipie...@gmail.com> wrote:

> http://packages.python.org/pulsar/overview.html
>
> --
>
>
>
>

-- 

Re: [web2py] pulsar

[António Ramos]

Is this like nodejs?

2013/1/4 Massimo Di Pierro 

> http://packages.python.org/pulsar/overview.html
>
> --
>
>
>
>

--