On Wed, Feb 11, 2004 at 12:42:31AM -0800, Scott wrote:
>
> Ooops, I forgot to attach the POE::Kernel->call() patch.
Applied! Woo-hoo!
--
Rocco Caputo - [EMAIL PROTECTED] - http://poe.perl.org/
On Wed, Feb 11, 2004 at 07:24:58PM -0800, Scott wrote:
> Rocco Caputo wrote:
> >
> >4. The Session->call() syntax, whether it's call() or invoke() or do()
> >or something else, does not prohibit inter-session call() anyway. It
> >does, however, imply that inter-process call() is not available, sin
inter-session calling, and in
addition, it also not an arguement against POE::Session->call(). Just
because you /can/ make everything an event, doesn't neccesarily mean it
should be given or even encouraged that you should make things which
rely on a synchronous state and then shoe-horn
Scott wrote:
[...]
I mean this in the nicest way possible, because I honestly can't think
of a nicer way to say it without being unclear of my opinion.
I really don't think that anyone should be so pretentious as to say
"you don't need this [feature]" to a programming community, doing so
leads
his still isn't an arguement for inter-session calling, and in
> addition, it also not an arguement against POE::Session->call(). Just
> because you /can/ make everything an event, doesn't neccesarily mean it
> should be given or even encouraged that you should make
lled?
> Aside from that, there was a second rational behind
> POE::Session->call(), and that is, to provide an interface for a higher
> level of event routing. One that bypasses the POE::Kernel entirely, but
> still respects ->state() changes. Its a middle ground between
Nick Williams wrote:
Scott wrote:
Nick Williams wrote:
Scott wrote:
[...]
If you're really only storing data, you really should use an object
OR package in the ways I mentioned above. Atleast, if you have any
desire to maintain efficiency.
Now here I must note, that I didn't come up with th
Scott wrote:
Nick Williams wrote:
Scott wrote:
[...]
If you're really only storing data, you really should use an object
OR package in the ways I mentioned above. Atleast, if you have any
desire to maintain efficiency.
Now here I must note, that I didn't come up with the idea of
removing in
Not everything needs to be an event, or so Rocco once told me.
True, but POE is nice because you /can/ make everything an event, if
you so desire.
Yes but this still isn't an arguement for inter-session calling, and in
addition, it also not an arguement against POE::Session->call(
*nods*
My applications do the exact same thing and absolutely thrive on
intersession calls. No touchie. :) Thanks.
On Wed, 11 Feb 2004, Nick Williams wrote:
> I have a fairly complex system that runs various background monitoring
> tasks (using Wheel::Run) and also takes in requests from the
; rv:1.6b)
Gecko/20031205 Thunderbird/0.4
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Scott <[EMAIL PROTECTED]>
Subject: Re: POE::Session->call()
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
<[EM
mail_out_v36_r4.12.) id f.1ef.18cbb617 (4238) for <[EMAIL PROTECTED]>; Wed,
11 Feb 2004 12:41:01 -0500 (EST)
From: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
Date: Wed, 11 Feb 2004 12:41:01 EST
Subject: Re: POE::Session->call()
To: [EMAIL PROTECTED]
MIME-Version:
[...]
I mean this in the nicest way possible, because I honestly can't think
of a nicer way to say it without being unclear of my opinion.
I really don't think that anyone should be so pretentious as to say
"you don't need this [feature]" to a programming community, doing so
leads to people com
Scott wrote:
Only two, relatively minor things.
First being that I wanted to deprecate the interface for Kernel->call(),
ommiting the session parameter as it should be unneccesary.
'should be unnecessary' is not quite 'unnecessary', you can't just
depricate something out of existance when _you_
Nick Williams wrote:
Scott wrote:
[...]
If you're really only storing data, you really should use an object
OR package in the ways I mentioned above. Atleast, if you have any
desire to maintain efficiency.
Now here I must note, that I didn't come up with the idea of removing
inter-session ca
Scott wrote:
[...]
If you're really only storing data, you really should use an object OR
package in the ways I mentioned above. Atleast, if you have any
desire to maintain efficiency.
Now here I must note, that I didn't come up with the idea of removing
inter-session calling all together. I
Nicholas Perez wrote:
Okay, I am no POE internal genius, and perhaps I am using call()
inappropriately (inter-session), but I find a lot of convenience in
using a separate Session to hold data that needs to be
synchronized/serialized.
You should be using an object or global structure, or the he
the Session->call method did:
(Optimized) POE::Kernel->call(): 34 wallclock secs (33.82 usr + 0.01
sys = 33.83 CPU) @ 29559.56/s (n=100)
(Old) POE::Kernel->call(): 48 wallclock secs (46.80 usr + 0.35 sys =
47.15 CPU) @ 21208.91/s (n=100)
POE::Session->call(): 22 wallcloc
Scott wrote:
Rocco Caputo wrote:
On Tue, Feb 10, 2004 at 09:00:01PM -0800, Scott wrote:
Rocco Caputo wrote:
I'm glad you don't support inter-session calling. You really can't do
that without at least setting POE::Kernel's notion of the active
session. Otherwise a callee's alarms (and oth
orming this optimization only provides 1/2 the
speed increase
the Session->call method did:
(Optimized) POE::Kernel->call(): 34 wallclock secs (33.82 usr + 0.01
sys = 33.83 CPU) @ 29559.56/s (n=1000000)
(Old) POE::Kernel->call(): 48 wallclock secs (46.80 usr + 0.35 sys =
47.15 CPU)
Rocco Caputo wrote:
On Tue, Feb 10, 2004 at 09:00:01PM -0800, Scott wrote:
Rocco Caputo wrote:
I'm glad you don't support inter-session calling. You really can't do
that without at least setting POE::Kernel's notion of the active
session. Otherwise a callee's alarms (and other resources)
On Tue, Feb 10, 2004 at 09:00:01PM -0800, Scott wrote:
> Rocco Caputo wrote:
> >
> >I'm glad you don't support inter-session calling. You really can't do
> >that without at least setting POE::Kernel's notion of the active
> >session. Otherwise a callee's alarms (and other resources) will be
> >as
Rocco Caputo wrote:
On Tue, Feb 10, 2004 at 04:23:44PM -0800, Scott wrote:
However, I just want to know if anyone applied the patch, had problems
applying the patch or running the tests afterwards, or any such thing.
I think a $_[SESSION]->call() is a great idea for a number of reasons,
offers
On Tue, Feb 10, 2004 at 04:23:44PM -0800, Scott wrote:
>
> However, I just want to know if anyone applied the patch, had problems
> applying the patch or running the tests afterwards, or any such thing.
>
> I think a $_[SESSION]->call() is a great idea for a number of reasons,
> offers an interfa
Rocco Caputo wrote:
On Mon, Feb 09, 2004 at 06:02:27PM -0800, Scott wrote:
There was a problem with this patch, which unlikely got noticed due
to the fact that it would not have caused an error until you used the
ReadWrite wheel with a depricated filter object. The test suite does
not chec
On Mon, Feb 09, 2004 at 06:02:27PM -0800, Scott wrote:
> There was a problem with this patch, which unlikely got noticed due
> to the fact that it would not have caused an error until you used the
> ReadWrite wheel with a depricated filter object. The test suite does
> not check this behavior
would be apprecicated.
- Scott
Scott wrote:
Hello POEple.
http://poe.perl.org/?POE_RFCs/Revise_call mentions adding a
POE::Session->call() method, in part of the revision of call. This
new session method is intended to deny cross-session calls, which as a
side effect allows extended op
Hello POEple.
http://poe.perl.org/?POE_RFCs/Revise_call mentions adding a
POE::Session->call() method, in part of the revision of call. This new
session method is intended to deny cross-session calls, which as a side
effect allows extended optimization of call() bypassing garb
28 matches
Mail list logo
