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
#x27;s not pointless.
>
> I would suggest a locally visible class to bring out the
> local, one time usage of that class. Btw. what is the best way to do so?
>
> Kind regards
> Stefan
>
>
> --- On Thu, 1/1/09, Geoffrey Broadwell wrote:
> From: Geoffrey Broadwell
> Su
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,
le class to bring out the
local, one time usage of that class. Btw. what is the best way to do so?
Kind regards
Stefan
--- On Thu, 1/1/09, Geoffrey Broadwell wrote:
From: Geoffrey Broadwell
Subject: Converting a Perl 5 "pseudo-continuation" to Perl 6
To: perl6-us...@perl.org, per
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
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 cleaner way to this in Perl 6?
##
sub init_ser
14 matches
Mail list logo
