On Tue, Jan 27, 2009 at 12:27:56AM +0100, Aristotle Pagaltzis wrote:
: * Aristotle Pagaltzis [2009-01-02 23:00]:
: > That way, you get this combination:
: >
: > sub pid_file_handler ( $filename ) {
: > # ... top half ...
: > yield;
: > # ... bottom half ...
: > }
:
* Aristotle Pagaltzis [2009-01-02 23:00]:
> That way, you get this combination:
>
> sub pid_file_handler ( $filename ) {
> # ... top half ...
> yield;
> # ... bottom half ...
> }
>
> sub init_server {
> # ...
> my $write_pid = pid_file_handler( $
On Fri, Jan 02, 2009 at 06:06:31PM -0800, Geoffrey Broadwell wrote:
: Meaning, the gather/take syntax doesn't make much sense, because we're
: not "gathering" anything; the PID file handler has nothing to return.
: We'd only be using it for the "side effect" of being able to pause the
: callee's ex
On Fri, Jan 2, 2009 at 9:06 PM, Geoffrey Broadwell wrote:
> It does bring up a question, though. What if pid_file_handler() needed
> to be broken into three or more pieces, thus containing multiple yield
> statements? Does only the first one return a continuation object, which
> can be called re
On Fri, 2009-01-02 at 22:56 +0100, Aristotle Pagaltzis wrote:
> > When I asked this question on #perl6, pmurias suggested using
> > gather/take syntax, but that didn't feel right to me either --
> > it's contrived in a similar way to using a one-off closure.
>
> Contrived how?
Meaning, the gather
* Geoffrey Broadwell [2009-01-01 21:40]:
> In the below Perl 5 code, I refactored to pull the two halves of the PID
> file handling out of init_server(), but to do so, I had to return a sub
> from pid_file_handler() that acted as a "continuation". The syntax is a
> bit ugly, though. Is there a c
On Fri, 2009-01-02 at 14:19 +0200, Leon Timmermans wrote:
> When going OO, I'd say an augment()/inner() approach would be
> cleanest. See
> http://search.cpan.org/~drolsky/Moose/lib/Moose/Cookbook/Basics/Recipe6.pod
> for an example. I don't know how to express that in Perl 6 though.
There's no d
When going OO, I'd say an augment()/inner() approach would be
cleanest. See
http://search.cpan.org/~drolsky/Moose/lib/Moose/Cookbook/Basics/Recipe6.pod
for an example. I don't know how to express that in Perl 6 though.
Regards,
Leon
On Fri, Jan 2, 2009 at 2:08 AM, Steve Lukas wrote:
> Hello,
>
Em Sex, 2009-01-02 às 08:34 -0300, Daniel Ruoso escreveu:
> token routine_def: {...}
Actually, I was just looking at STD, and the correct token would be
token routine_declarator:coro { }
I was also looking at the spec files, and I realized that DRAFT S17
mentions coroutines, but its defini
Em Qui, 2009-01-01 às 12:34 -0800, Geoffrey Broadwell escreveu:
> In the below Perl 5 code, I refactored to pull the two halves of the PID
> file handling out of init_server(), but to do so, I had to return a sub
> from pid_file_handler() that acted as a "continuation". The syntax is a
> bit ugly,
Hello,
I'd vote for the OO-style.
My reason is that the major criteria should be the reader perspective.
It should be as clear as possible what's going on in the main code
even if the reader doesn't know the hottest p6 tricks!
What you are doing here is: two operations on the same thing (the pidf
On Fri, 2009-01-02 at 00:30 +0200, Leon Timmermans wrote:
> I can't help wondering "why does pid_file_handler need to be split up
> in the first place?" Why wouldn't it be possible to simply call
> pid_file_handler after become_daemon?
Two answers:
1. If an error occurs that will not allow the PI
I can't help wondering "why does pid_file_handler need to be split up
in the first place?" Why wouldn't it be possible to simply call
pid_file_handler after become_daemon?
Regards,
Leon Timmermans
On Thu, Jan 1, 2009 at 10:34 PM, Geoffrey Broadwell wrote:
> In the below Perl 5 code, I refactore
13 matches
Mail list logo
