The website should be fully functional, but it appears the server is down.
Try again later. :/
On Mon, Apr 7, 2008 at 9:51 AM, Ian Docherty <[EMAIL PROTECTED]> wrote:
> Apologies if this has already been asked, I have only just joined the
> mailing list.
>
>
>
> Am I correct in thinking the offic
I too thought this was a joke, then I realized the timestamp was last night.
[virutal] BEERS for all involved! Great Job everyone!
On Tue, Apr 1, 2008 at 10:26 AM, Randal L. Schwartz <[EMAIL PROTECTED]>
wrote:
> > ""John" == "John R " <[EMAIL PROTECTED]> writes:
>
> "John> Rocco Caputo wrot
Go right ahead. run() doesn't return until the POE loop completely
shutsdown, so its somewhat pointless.
IIRC, the wiki has an example where it does make sense.
On Fri, Mar 14, 2008 at 3:54 PM, Yuri Shtil <[EMAIL PROTECTED]> wrote:
> What will happen if $poe_kernel->run called more than once?
>
Also, ClientInput is a callback specific to the POE::Session that handles a
single connection.
POE is a multitasking environment, not a threaded one - so you are going to
only be processing one line of code at a time anyway.
On Wed, Feb 13, 2008 at 5:28 PM, vidals <[EMAIL PROTECTED]> wrote:
> I h
Your toolkit doesn't even have to be in the POE[::Component]
namespace. IMO, if its a completely selfsustained toolkit (and it
uses POE under the hood or even exposes some POE stuff) it should
probably go in its own namespace (ie Toolkit::Integration:: playing on
Integration Patterns Toolkit).
On
Not even that!
Components are very generic, high level abstract concepts. You can
implement any interface you want [as long as its documented].
Some will return POE::Session objects, some will return objects, some
return Session ID's to post() to, etc.
It depends on the implementation and the requ
Probably the easiest method would be to modify the Filter::HTTPD that
the PoCo uses.
On 10/12/07, Ashley Pond <[EMAIL PROTECTED]> wrote:
> Hi. (Long time casual fan, occasional user of POE, first time wisdom
> seeker.)
>
> I have a POE app I'm working on/with which uses PoCo::HTTP::Client. I
> wan
o run forever and then call a
> shutdown routine when some predetermined event happens?
>
>
> On 9/18/07, Matt Sickler <[EMAIL PROTECTED]> wrote:
> > Zack,
> > The best way would be to clean up all of the things keeping the POE
> > Kernel alive.
> > In t
Zack,
The best way would be to clean up all of the things keeping the POE
Kernel alive.
In the client case, its the POE::Component::IKC::Client session. Send
it a shutdown event, and the program will clean itself up.
See the updated example I put online (
http://poe.perl.org/?POE_Cookbook/Inter_K
I havn't used IKC before, but it seems that the client session closes
itself before getting any data from the server.
The
$kernel->yield('_stop');
causes the kernel to fire the current session's _stop handler. This
is bad for two reasons:
1) With this model, the client probably stops before eve
I like the idea of having a wiki / online book like what the
subversion project does. POE changes way too fast for a book to keep
up. The wiki is already in place, it just needs more lovin', maybe
even HTML versions of the POD put up too.
On 9/8/07, Rocco Caputo <[EMAIL PROTECTED]> wrote:
> Neve
;
> > return shift @$self;
> > }
> >
> > # Return a list rather than a list reference.
> > # The problem here is that we may be returning
> > # many different types of things, each requiring
> > # its own envelope.
> >
> > sub get_pend
How is adding that error mechanism binding the filter to the wheel any
more than the current get_one() and put() API is?
I don't care how many API's we have to break, Filters should have
proper error checking.
Sure there are alot of third party filters, but 90% of the devs are on
#poe, and the oth
I second this method. It provides a simple API, and simple Filters
wouldn't have to be modified much.
On 8/14/07, Nicholas Perez <[EMAIL PROTECTED]> wrote:
> I second this.
>
> And I think something like POE::Filter::Error would be a good place to
> encapsulate something like that. But like what
The Client* Interface doesnt have a method to expose the socket. A
simple patch to the module should allow it though.
On 8/9/07, Kevin Scaldeferri <[EMAIL PROTECTED]> wrote:
>
> On Aug 7, 2007, at 5:07 PM, Joel Bernstein wrote:
>
> > On Tue, Aug 07, 2007 at 11:10:16AM -0700, Kevin Scaldeferri wro
For some reason EasyDBI does not work when spawned directly inside an
irssi script.
use strict;
use Glib;
use POE qw(Loop::Glib);
use POE::Component::EasyDBI;
use POE::Session::Irssi;
POE::Component::EasyDBI->spawn(
alias => 'edbi',
dsn => "DBI:mysql:database=mylog2;host=192.168.24.11;port=33
You could store the current byte position in another file. This would
only work as long as the file is only appended, if it is removed,
moved, or replaced, this would fail.
On 7/30/07, Tom Lanyon <[EMAIL PROTECTED]> wrote:
> Hi All,
>
> Does anyone have a tricky way of using Wheel::FollowTail to
thirdlobe, talk to dngor
awesome and free
On 6/14/07, Matt Cashner <[EMAIL PROTECTED]> wrote:
I'm looking for new homes for my POE modules. If you have any
interest, please email me privately at [EMAIL PROTECTED] and we'll talk.
Thanks all.
--
Matt Cashner
[EMAIL PROTECTED]
http://mattcashner.c
I just committed a change that adds get_input_handle and
get_output_handle methods to Wheel::ReadWrite. :)
On 5/23/07, Rohan Almeida <[EMAIL PROTECTED]> wrote:
Matt Sickler wrote:
> Perhaps a better way would be to have methods that do the getsockopt
> calls themselves?
There wou
es (ie, yanked out via accessor), but it keeps the end developer
from holding onto a reference to the handles when building the wheel
in the first place.
On 5/23/07, Matt Sickler <[EMAIL PROTECTED]> wrote:
> The component wouldnt be the one to provide access to it.
> You would need t
don't have any problems with using SocketFactory and
Wheels for my server. Just though it would be nice if
PoCo::Server::TCP does provide access to the socket.
Thanks,
Rohan
Matt Sickler wrote:
> There arent any documented ways to get at a ReadWrite wheel's handle.
> The non-P
There arent any documented ways to get at a ReadWrite wheel's handle.
The non-POE way you could do it (and breaking encapsulation) would be to use
$heap->{client}->[ POE::Wheel::ReadWrite::HANDLE_INPUT ] and
$heap->{client}->[ POE::Wheel::ReadWrite::HANDLE_OUTPUT ]
( those would be the same in man
First off, download the svn source from source forge. Maybe Rocco
(dngor) will give you commit access if you have a SF account,
otherwise paste the changes here and one of us will commit your
change.
Also, dont forget to add tests to make sure your changes work and dont
break anything else.
On 5
It really depends on what the session does.
If its a really OO-centric module and uses all object states (like PoCo-IRC)
then you could use OBJECT exclusively (like PoCo-IRC).
If there are no object states, then OBJECT doesnt apply.
It really depends on what you are doing and how you want to accom
okay, heres the story
I am developing a messenger app for my school (win32), currently I am using
POE + Tk
Then I wanted a GUI GUI-maker. someone pointed me to Glade (which is Gtk,
Glib, etc)
i found http://gladewin32.sourceforge.net which installed glib, glade, gtk,
etc or whatever, and now
The InlineStates, PackageStates, and ObjectStates for PoCoServerTCP are for
the client sessions:
when you spawn() a PCST, it makes a master session that sits around
listening for connections, when one arrives, it spawns a new session which
get InlineStates, PackageStates, and ObjectStates.
On 3/2
I do not believe there is any mandatory review for anything except core POE
(which Rocco releases himself anyway).
Go ahead and submit it to CPAN - it will be tested and reviewed by many, and
thats the best way to get feedback.
On 3/21/07, Chris Cobb <[EMAIL PROTECTED]> wrote:
Greetings,
I'd li
A better fix would be a patch to the source that fixes the leak
On 3/21/07, Eric Busto <[EMAIL PROTECTED]> wrote:
Firefox seems to keep them alive as well. Unfortunately, since the app
I am writing uses a meta refresh every few seconds to have the browser
reload it, a browser left up overnight
The best bet would be to modify an existing Wheel to do your evil bidding..
using others and POE::Wheel as reference
On 3/19/07, flw <[EMAIL PROTECTED]> wrote:
Because the POE::Wheel::ReadLine module can't work on Win32 platform.
So I want to write a new wheel like POE::Wheel::ReadLine to suppo
as maybe a catcher, you could add a
warn '$/ is not default' if $/ != "\n";
local $/ = "\n";
just before the read
On 3/16/07, Eric Busto <[EMAIL PROTECTED]> wrote:
Last e-mail, I promise.
I found the source of the problem. I was setting $/ to undef, without
declaring it as a local change (
I once wrote a POE::API module that had a do_events_until and wait_until
methods that would let the kernel do other things until a variable was set
or a time passed - they both used run_one_timeslice but I found that that
method didnt have the granularity that my methods needed. ie. they would
ru
i believe 'event chain' would be appropriate
On 3/1/07, Michael Collins <[EMAIL PROTECTED]> wrote:
POE Gang,
I have a nomenclature question. Let's say you have one or more POE
sessions. When you have an 'event flow' - the flow of control moves
from session to session (or to different events
select_read( $socket, "event to fire") tells the kernel to fire the event
"event to fire" to the current session whenever there is data that can be
read from $socket
yield("event") tells the kernel to queue the signal, event, whatever you
want to call it, to the current session
On 2/23/07, Fei L
select_read and select_write tell POE::Kernel to watch a filehandle for
those states
$poe_kernel->yield() its NOT like Thread's yield(). NOT AT ALL.
read the perldoc on POE::Kernel to see what yield() does (ditto on the other
two)
POE is quite well documented
On 2/22/07, Fei Liu <[EMAIL PROTE
in any case the post() would fail because no session can message another
session within _stop states
On 2/21/07, Kevin Scaldeferri <[EMAIL PROTECTED]> wrote:
I'm trying to figure out how to schedule an action to happen after my
PoCo::Server::TCP shuts down. I.e., after all the pending requests
yes, DBI and PoCoEasyDBI work just fine on windows
On 2/21/07, Bill Nash <[EMAIL PROTECTED]> wrote:
Well...
A better question would be: Do Perl and DBI work with windows?
- billn
On Wed, 21 Feb 2007, Mathieu Longtin wrote:
> Do any of them work with windows?
>
> On 2/21/0
POE::Component::EasyDBI is what I use - quite simple and can be powerful
On 2/20/07, Kevin Scaldeferri <[EMAIL PROTECTED]> wrote:
Anyone want to strongly advocate for one of the four or so components
that comes up on a CPAN search for "POE DBI"?
-kevin
at hard to do,
but I can't find anything published on CPAN that does it.
-kevin
On Jan 19, 2007, at 11:02 PM, Matt Sickler wrote:
> I believe you can use Wheel::Run and theres a CloseEvent or the like
>
> On 1/20/07, Kevin Scaldeferri <[EMAIL PROTECTED]> wrote:
>>
&
I believe you can use Wheel::Run and theres a CloseEvent or the like
On 1/20/07, Kevin Scaldeferri <[EMAIL PROTECTED]> wrote:
I figure I can write this myself easily enough, but I'm wondering if
there's a module already for this task. I want to run command-line
functions which I know to be non
and even if it doesnt, you can use Wheel::Run or Wheel::Generic to fork it
away
On 12/8/06, Michael Erskine <[EMAIL PROTECTED]> wrote:
On Friday 08 December 2006 05:20, Rocco Caputo wrote:
> The poor Win32 users have bigger problems. Namely that perl's select
> () is written in terms of winsoc
isnt serial comms done with readwrite on /dev/serialdevice or something?
although that is a good idea to write a Driver for serial comms.
On 12/5/06, Nicholas Perez <[EMAIL PROTECTED]> wrote:
I guess it would help if I copied the list...
-- Forwarded message --
From: Nicholas
run() only returns when all sessions have died.
A session dies when there is nothing left for it to process; an alias doesnt
keep it alive when the only thing keeping every session alive is an alias.
On 10/25/06, Tom Lanyon <[EMAIL PROTECTED]> wrote:
Hi All,
Having a problem with a small app I
you can also use refcount_increment() - which is more work, but at least you
get to decide whether watching for a signal keeps you alive
On 19 Sep 2006 08:18:59 -0700, Randal L. Schwartz
wrote:
> "Rocco" == Rocco Caputo <[EMAIL PROTECTED]> writes:
Rocco> + The sig() reference count has be
use POE::API::Peek;
my $api = POE::API::Peek->new();
my @sessions = $api->session_list();
# cheers
On 9/10/06, Maciej Pijanka <[EMAIL PROTECTED]> wrote:
On 10/09/06, Rocco Caputo <[EMAIL PROTECTED]> wrote:
> The sig() reference count rollback went easier than planned. It's
> done, tested, and
I dont use signals all that much or POE, but I thought Id put in my 2 cents.
IMO, signals should mirror UNIX signals - they dont keep a session alive. I
hear that this can cause problems with certain signals, so someone suggested
adding a sig() that keeps a session alive. Rocco didnt like havin
Hello dazjorz,
I looked over your code from the ticket and I found your problem.
When you set the kill_after_flush, you set it globally for all connections
created.
To get a per-connection flag access the kill_after_flush flag with:
$_[HEAP]->{kill_after_flush}->{$wheel_id}
-- OR --
Use POE::Comp
What is it that your trying to accomplish? This will help us suggest
what to use.
On 2/25/06, lanas <[EMAIL PROTECTED]> wrote:
> Rocco Caputo <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> > {Inline,Object,Package}States apply to each connection session, not
> > the main server session for the component.
47 matches
Mail list logo
