On Friday, Aug 29, 2003, at 01:05 US/Eastern, Rocco Caputo wrote:
On Thu, Aug 28, 2003 at 05:27:22PM -0400, Dmitri Tikhonov wrote:
I was looking at POE::Kernel again to try to figure out this problem,
and
then I re-visited this thread. It hit me that because of semantic
differences between
On Friday, Aug 29, 2003, at 14:29 US/Eastern, Dmitri Tikhonov wrote:
It also uses alarm semantics rather than delay semantics, which means
it's susceptible to time shifts. Assuming different ST_ALARM and
ST_DELAY events, you can't make a delay that doesn't succumb to clock
drift.
I am not
Dmitri Tikhonov wrote:
On Mon, 1 Sep 2003, Peter Chen wrote:
wait (or be somewhere on a branch).
If you take a look at the postings dated back in April, you will find
that such API already exists, it's POSIX::times. There is no need to
reinvent the wheel.
Yeah, that's what I'd do
sungo wrote:
Peter Chen wrote:
Is there any particular advantage of replacing ST_TIME w/ ST_ALARM?
ST_TIME uses the old system time based semantic. Isn't what we are
trying to do here simply to add a delay based semantic? How about
keeping ST_TIME and adding ST_DELAY?
so, let me get
On Tuesday, Sep 2, 2003, at 17:28 US/Eastern, Rocco Caputo wrote:
I have heard conflicting stories about whether the time shift is
significant. Jeff Bisbee posted that systems based on UTC don't see
shifts in time() when DST/Standard arrive. Matt Cashner is convinced
that NTP prevents the
On Fri, 2002-11-08 at 15:16, [EMAIL PROTECTED] wrote:
I was trying to make it work with HTTPS, and after a few rounds
gave up on it. If turning non-blocking connects off does not help,
fork a process and run LWP or LWP::PUA in it. Or try PoCoCl::HTTP.
There may be a different way to create
On Thu, 2002-11-07 at 21:47, Rocco Caputo wrote:
On Thu, Nov 07, 2002 at 11:05:28AM -0800, Lenny Rachitsky wrote:
Has anyone gotten POE::Component::Client::UserAgent to work with
SSL/HTTPS pages? I've disabled nonblocking, and Net::SSL is being
used, but I still get a failure after a few
such as
internetworked financial markets, file systems, commerce and
application servers.
--=-=-=
* Wed Oct 23 2002 Lenny Cartier [EMAIL PROTECTED] 0.23-1mdk
- for Peter Chen [EMAIL PROTECTED] :
- 0.23
--
http://www.linux-mandrake.com/en/cookerdevel.php3
---End Message---
On Mon, 2002-09-09 at 15:42, Rocco Caputo wrote:
Here's a way to close files above $^F. It's not pretty, not tested,
and may not be very portable. The code would go into Wheel::Run, just
before the function is called in the child process.
# Assuming 255 open handles max.
use POSIX
On Sun, 2002-09-08 at 14:14, Rocco Caputo wrote:
Please try http://poe.dynodns.net/~troc/tmp/peter-chen-wheel-run.perl
(temporary URL on my dial-up machine), or you can use it as the base
for your own test case.
I still can't reproduce the problem here, even with that running for
almost 15
On Mon, 2002-09-09 at 12:07, Rocco Caputo wrote:
If DESTROY is being called, it's almost certain that the socket is
being destroyed from POE's point of view. Sockets still won't close
if something outside POE has copies of them. That includes child
processes, so this may be related to the
On Fri, 2002-08-30 at 18:19, Rocco Caputo wrote:
I opted against using option() for this right now. Moving trace to
_trace (and the others) is a public interface changes that will take
months to implement. Moving the component options to option() would
also take a long time. Rather than
On Sat, 2002-08-31 at 18:24, Rocco Caputo wrote:
I just received a similar problem report and suggested a solution that
might also work for you. Namely, sockets should have their
close-on-exec flags set to true so they don't bleed into child
processes.
If this sample code works for you,
On Thu, 2002-08-29 at 13:40, Rocco Caputo wrote:
I haven't, but I don't use POE::Wheel::Run as much as you do. Is it
possible that occasionally the SIGCHLD is being delivered before the
STDOUT/STDERR pipes close, so the wheel is being destroyed before it
can emit a CloseEvent?
I did check
Does POE::Wheel::Run always emit a CloseEvent?
I have encountered a strange situation where POE::Wheel::Run seems to
omit emitting a CloseEvent. This happens when I do a rpm -Uvv
--percent with a bunch of rpm's. Most of the time this works just
fine, but occasionally the CloseEvent never
On Tue, 2002-08-20 at 16:34, Rocco Caputo wrote:
On Mon, Jul 15, 2002 at 04:27:26PM -0400, Peter Chen wrote:
Thank you for confirming this, and fixing it. Please let me know when
you have a release, and I will roll out another RPM.
I seem to have fixed it, but I don't remember when
On Wed, 2002-08-21 at 13:52, Peter Chen wrote:
On Tue, 2002-08-20 at 16:34, Rocco Caputo wrote:
I seem to have fixed it, but I don't remember when. The fix isn't the
same as your code, but it seems equivalent. Could you test it to make
sure that it fixes your SOAP server and doesn't
On Fri, 2002-08-16 at 15:42, Rocco Caputo wrote:
August 15, 2002 marked the fourth anniversary of POE's first public
release. As lead designer and developer of the project, I would like
to thank the hundreds of people who have helped make POE as great as
it is today. Unfortunately, I cannot
On Sat, 2002-07-27 at 07:49, Rocco Caputo wrote:
The only reason I can think of to use POE_safe might be if you want
to support older versions of Perl. Otherwise the attributes sound
fine.
Yes, I am leaning toward using attributes as well.
You could do this a third way: PoCo::SOAP can emit
How does one shutdown a socket created by PoCo::TCP::Server?
I am noticing some SOAP::Lite client hangs. Netstat shows that the
server is at a close wait state, and the client is at fin wait state.
Saving the socket passed into the the handler session in $heap-{socket}
and later calling
FYI, POE 0.22 rpm for Mandrake has made it to rpmfind.net:
http://rpmfind.net/linux/rpm2html/search.php?query=perl-poe
Pete
On Thu, 2002-07-04 at 01:28, Rocco Caputo wrote:
Version 0.22 of the POE networking and multitasking framework has been
released. This is mainly a bugfix and minor feature update from 0.21.
Thank you. Incidentally, I have uploaded perl-POE-0.22 rpm to Mandrake
contrib. Hopefully, it will
On Tue, 2002-06-25 at 21:41, Rocco Caputo wrote:
You are correct. Children of a session will always receive
notification of a signal even though the parent session has handled
it.
Thank you.
I see. In that case, I guess the paradigm is for every session to keep
track of the pid's it is
On Wed, 2002-06-26 at 11:08, Rocco Caputo wrote:
The paradigm has recently shifted regarding POE::Wheel::Run. Its new
CloseEvent should now be a reliable and convenient way to tell when a
child has gone away.
So far I have been conservative by checking both CloseEvent and the
arrival of
On Wed, 2002-06-26 at 13:05, Rocco Caputo wrote:
This is an excellent point. If you've come up with a better interface
for child processes, we can do some harsh revising. I'd really like
to see Wheel::Run redone as a component anyway. Then it can manage
its own signal handlers.
We do seem
On Sat, 2002-06-08 at 02:15, Rocco Caputo wrote:
Version 0.20 of the POE networking and multitasking framework has been
released. Thanks to everyone who helped make this possible.
That's great.
I have submitted the corresponding RPM to Mandrake. It should show up
within the week.
I noticed
It seems that the typical Mandrake process for contributing a package to
the time it appears on rpmfind.net takes 2-3 days. The first POE
related rpm, perl-Filter-1.28 has appeared on rpmfind.net.
http://rpmfind.net//linux/RPM/cooker/contrib/RPMS/perl-Filter-1.28-3mdk.i586.html
Now I have the
FYI - I have started uploading source RPM's to Mandrake following its
process (yeah, there are a few steps). The first one is perl-Filter
which includes Filter::Util::Call that POE needs.
My plan is to upload POE-0.19, and other POE related modules in this
couple weeks, and eventually POE-0.20
On Tue, 2002-06-04 at 12:43, Rocco Caputo wrote:
On Tue, Jun 04, 2002 at 12:36:24PM -0400, Peter Chen wrote:
FYI - I have started uploading source RPM's to Mandrake following its
process (yeah, there are a few steps). The first one is perl-Filter
which includes Filter::Util::Call that POE
On Sat, 2002-06-01 at 11:24, Al Tobey wrote:
try out /usr/lib/rpm/cpanflute or /usr/lib/rpm/cpanflute2
Yeah, cpanflute and cpanflute2 are wonderful tools.
This should work for most any CPAN module.
The world is a happy place ...
There are some minor vendor specific idiosyncrasy though.
On Tue, 2002-05-28 at 18:11, [EMAIL PROTECTED] wrote:
I cannot give final POE code since I'm not quite sure about the syntax that
would be used to specify place types. The net could be described similar to
the small sum test (just list all the transitions together with their arcs,
the arcs'
On Fri, 2002-05-24 at 19:03, Matt Cashner wrote:
are you familiar with POE::Component::SubWrapper? if not, you might want
to become so. it seems like it would be a great win for you.
Thank you for pointing this out. I did.
What I find is that it requires many intermediate states in cases
On Fri, 2002-05-24 at 13:05, [EMAIL PROTECTED] wrote:
(event-listener) - [step1] - (step2 args) - [step2] ... - [step n]
using my coloured Petri net implementation you could either use the graph
editor or write a simple hash describing the net. So it either gives you
a good graphical
On Fri, 2002-05-24 at 13:14, [EMAIL PROTECTED] wrote:
On Fri, May 24, 2002 at 10:34:36AM -0400, Peter Chen wrote:
On Fri, 2002-05-24 at 00:02, Rocco Caputo wrote:
Postbacks are cumbersome for message passing in larger programs.
I also notice that postbacks decrease the transparency
On Thu, 2002-05-23 at 21:19, Matt Cashner wrote:
when you get done with this, would you be agreeable to it being included
in poed? (poed is the languishing project to rewrite the poe docs.) all
(well most) of our docs are under the bsd license. let me know what you
think :)
I am honored. :-)
On Fri, 2002-05-24 at 00:02, Rocco Caputo wrote:
Postbacks are cumbersome for message passing in larger programs.
I also notice that postbacks decrease the transparency of the messages
being passed. When posts are used, it's straight forward to tell what
messages are passed back to the sender.
On Fri, 2002-05-24 at 00:47, Rocco Caputo wrote:
I think after writing about two of those, I'd go slightly mad and
create a function that built these for me. If it turned out that I
was doing this a lot, I would probably assume it's a generic pattern
and write a new type of Session to do it.
On Wed, 2002-05-22 at 18:41, Rocco Caputo wrote:
Do you specifically need to know when STDOUT is closed, or is it more
important to know that the child is done sending information at all?
The later would be sufficient, even though it would be nice to have
finer grain control.
For example, I
On Thu, 2002-05-23 at 14:15, Rocco Caputo wrote:
It is slightly inaccurate.
CloseEvent indicates when the child process has closed its STDOUT and
STDERR handles. STDIN may still be available for input.
Thank you for the clarification. I see my misunderstanding regarding
how STDIN is
I would like to solicit your insight on the best practices in handling
responses/postbacks. Specifically, I am wondering what are the pro's
and con's of using a response event vs. a response postback. For
example,
$kernel-post($worker_session, $work_request_event,
I am working on a tutorial explaining how to poeize a procedural
program, in the hope of making it easier for my coworkers to pick up
POE.
Since I have not worked with POE for that long, I am wondering whether
there is an easier and more elegant way of doing this. This is what I
have so far,
On Wed, 2002-05-22 at 00:33, Chris Fedde wrote:
I saw behavior like this with 0.18 on FreeBSD 4.5 and Solaris 2.8.
After 0.19 the sigchld consistently arrives after two error events
marking failed nonblocking read on stderr and stdout.
Unfortunately, I don't share the same experience. I
On Tue, 2002-05-21 at 18:58, Chris Fedde wrote:
I have not had time to clean it up yet. But my test code now behaves
predictably: All the output arrives before sigchld. I can't tell
which file handles the errors are on. But all the data has been read
before the sigchld which was the big
On Thu, 2002-05-02 at 14:51, Tavin Cole wrote:
what is the advantage of self-daemonizing programs over solutions like
nohup and daemontools?
First of all, thank you for pointing out daemontools.
I guess daemontools takes care of daemonization. Most of the Linux
distributions I have
What is the convention for handling daemonization in a POE application?
In particular, what I am wondering is whether typically one daemonizes
before $poe_kernel-run() or do the daemonization in one of the
application manager sessions.
For example, I am considering using what I call a
On Wed, 2002-05-01 at 03:05, Andrew A. Chen wrote:
I am unsure how kosher this solution is, but it's functional as far as I
know. I jacked the daemonize() routine out of perlfaq and called it just
before $poe_kernel-run(); See below.
-a
daemonize();
$poe_kernel-run();
exit 0;
On Mon, 2002-04-22 at 21:25, Rocco Caputo wrote:
There's a good reason for this, I think. At least, it's a half-good
reason. Net::SSLeay requires sockets to be in blocking mode. I'm not
sure why, but it probably has something to do with the underlying
protocol.
Yes, I noticed that. In
On Mon, 2002-04-22 at 21:41, Rocco Caputo wrote:
On Thu, Apr 18, 2002 at 05:01:44PM -0400, Peter Chen wrote:
This may be fine depending on what handle($input) does. I wouldn't
worry about breaking up handle() if it's quick, for instance.
This thread actually ties into the other thread about
On Tue, 2002-04-23 at 13:58, Rocco Caputo wrote:
It can take a long time to build a TCP socket and even longer to
determine the socket can't be built. Connecting in non-blocking mode
will let other things happen while TCP works out the details. Once
the socket is built, it can be made to
Has anybody tested https with Pocol::UserAgent? When I turn on
LWP::Debug by
use LWP::Debug qw(+);
It shows that it's always using a IO::Socket::INET instead of Net::SSL.
LWP::Parallel::UserAgent::init_request
- (undef, [undef], LWP::Parallel::Protocol::https=HASH(0x84c1ef4),
180,
After digging deeper, I found out the issue stems from
LWP::Prallel::Protocol::http.
In LWP::Prallel::Protocol::http::connect, it explictly creates
IO::Socket::INET when it's in nonblocking mode, this overrides the
original https protocol, and effectively disable any https support in
nonblocking
I have been working with Fletch's POE::Component::SOAP. It's wonderful
to be able to get a SOAP server up and running with very little code.
I am tripping over some conceptual issues with the synchronouse calls.
Perhaps some of you who are more familiar with POE paradigm can
enlighten me.
52 matches
Mail list logo
