Re: New Perl 6 Advent Calendar: call for ideas
2010/11/6 Tadeusz Sośnierz : > As I accidentally volunteered for managing a list of topics and writers > for this year's Advent Calendar [1], I started to collect some ideas of > things it'd be nice to write about. There's a gist [2] with the list of > things from the top of my head. If you have any ideas, please post them, > bonus points if you could write about it. I found the Fibers implementation[1] recently posted on perl6-language really interesting, and it may be a good way to show off the power of lazy lists and gather/take. Leon [1] http://www.mail-archive.com/perl6-...@perl.org/msg90270.html
Re: questions about array references and captures
On Fri, Jul 30, 2010 at 6:21 PM, R. Dresens wrote: > Yes, but aren't captures somehow replacements for references in > general... and therefore also array references? The reason why I > assume that is that I (wrongly?) expected a "real" 'Array()' when I > used the `\` prefix in an expression such as `...@x`. �...@x` is an > array, but ` \...@x` has become a 'Capture()' in recent rakudo > releases, not an 'Array()' anymore. Hence my assumption. Captures in Perl 6 are needed much less than references in Perl 5. That's a feature, not a bug. References often make things more confusing that they should be. You shouldn't need captures in most Perl 6 code. > ...but an "anoymous array" (if I may call it that?) assigned to `$x` > is still an 'Array()'. So I'm really confused about the > intricate difference between... > > my $x = [1, 2, 3] > > ...and... > > my @y = (1, 2, 3); my $x = \...@y The latter should be written as my @y = (1, 2, 3); my $x = @y; Yeah, that requires some unlearning of Perl 5 idioms. $x and @Y are indeed mostly the same, except that @y acts listy and $x not. > ...apart from the question whether it has really an impact on > practical code. I'm more or less trying to create a model of perl 6 > in my mind right now, and I really wonder how to explain this > behavior. I think the crucial step it to stop thinking you need the \ operator for anything until you really need it. Leon
Re: questions about array references and captures
On Thu, Jul 29, 2010 at 8:30 PM, R. Dresens wrote: > And what about this?... > > my $x = [3, 4]; my @y = 1, 2, |$x, 5, 6; say @y.perl; > > ...I actually expected `[1, 2, 3, 4, 5, 6]`, since I was under the > impression that the '|' was some kind of "flatten" or > "interpolation" operator. > > But I got `[1, 2, \(3, 4), 5, 6]` instead. > > How can I do this? Is this normal behavior? I find this confusing, > but perhaps there is some deeper hidden meaning? I think that you meant to do is this: my $x = [3, 4]; my @y = 1, 2, @($x), 5, 6; say @y.perl; # untested Leon
Re: Something wrong with str.reverse
On Mon, Jun 21, 2010 at 3:37 PM, Patrick R. Michaud wrote: > On Mon, Jun 21, 2010 at 09:47:37AM +0100, Smylers wrote: > > On the other hand, many of our other list-y methods also work on > scalars (treating them as a list of 1 element -- essentially a no-op): > .join, .sort, .any, .all, .rotate, .max, .min, .pick, .reduce, .values, > etc. It might be inconsistent that .reverse on a scalar warns when > the others do not. > Personally I don't see the point of providing such methods and then making them warn. A scalar acting as a one element list is a useful abstraction for generic code. All abstractions are leaky, but this would be too leaky for my tastes. Leon
Re: How to speed up a grammar
On Sun, Jun 7, 2009 at 1:44 AM, Minimiscience wrote: > > This is just a wild, uneducated, possibly delusional guess, but I don't > think that vertical bar before the '/>' should be there. I think it might > be causing the grammar engine to check whether it can omit the ending of > each tag and attach it to the enclosing tag instead, which it can't confirm > without examining the whole file at least once for each tag. > In Perl 5 regexps that would be a problem, but in Perl 6 it shouldn't AFAIK. See "Nothing is illegal" in S05. Leon
Re: the file slurping is not working
>
> Then why is it that .get works fine for $*IN?
>
> while $*IN.get -> $line {
> say $line
> }
>
Because you're using a while loop instead of a for loop ;-)
Leon
Re: Converting a Perl 5 "pseudo-continuation" to Perl 6
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 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_server {
>my %options = @_;
>
># ...
>
># Do top (pre-daemonize) portion of PID file handling.
>my $handler = pid_file_handler($options{pid_file});
>
># Detach from parent session and get to clean state.
>become_daemon();
>
># Do bottom (post-daemonize) portion of PID file handling.
>$handler->();
>
># ...
> }
>
> sub pid_file_handler {
># Do top half (pre-daemonize) PID file handling ...
>my $filename = shift;
>my $basename = lc $BRAND;
>my $PID_FILE = $filename || "$PID_FILE_DIR/$basename.pid";
>my $pid_file = open_pid_file($PID_FILE);
>
># ... and return a "continuation" on the bottom half (post-daemonize).
>return sub {
>$MASTER_PID = $$;
>print $pid_file $$;
>close $pid_file;
>};
> }
> ##
>
> 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.
>
> pmichaud offered several possibilities (I've converted some of his
> suggestions expressed as prose into code, so the errors there are mine):
>
> 1. Take advantage of Perl 6 syntax reduction to turn 'return sub {...}'
> into 'return {...}' (or even just fall of the end with '{...}', I
> suppose). This is visually slightly better, but still leaves the
> bottom half inside a block that merely exists to satisfy Perl, not
> actually representing anything intrinsic about the problem.
>
> 2. Throw a resumable exception in the middle:
>
> sub init_server {
> # ...
> pid_file_handler($options{pid_file});
> become_daemon();
> pid_file_handler();
> # ...
> }
>
> sub pid_file_handler {
> # ... top half ...
> throw ResumableException;
> # ... bottom half ...
> }
>
> He also suggested a variant syntax with an adverb on return:
>
> sub pid_file_handler {
> # ... top half ...
> return :resumable;
> # ... bottom half ...
> }
>
> I suggested a naked yield syntax:
>
> sub pid_file_handler {
> # ... top half ...
> yield;
> # ... bottom half ...
> }
>
> These all desugar to the same thing, of course.
>
> 3. Make become_daemon a part of pid_file_handler, or vice-versa.
> I rejected both of these on the basis of separating different
> things into different subs. The two tasks are only tangentially
> related, and neither really seems like a subordinate op of the
> other.
>
> 4. In order to keep the sub separate, but still not split the
> pid_file_handler call, I came up with a variation of #3 in which
> pid_file_handler takes a callback parameter:
>
> sub init_server {
> # ...
> pid_file_handler($options{pid_file}, &become_daemon);
> # ...
> }
>
> sub pid_file_handler($pid_file, &callback) {
> # ... top half ...
> callback();
> # ... bottom half ...
> }
>
> That seems like a silly contortion to hide the problem, and
> doesn't represent my intent well -- the pid file handler doesn't
> need to send a message, it needs to yield control while waiting
> for something else to happen.
>
> 5. Make a new PidHandler class and address the problem in OO fashion:
>
> sub init_server {
> # ...
> my $pid_handler = PidHandler.new(file => $options{pid_file});
> $pid_handler.top();
> become_daemon();
> $pid_handler.bottom();
> #...
> }
>
> This is certainly workable, but again feels like a contrived
> workaround in the same way that gather/take and return {...} do.
> Plus, writing a new class and using OO/method call syntax just to
> allow a sub to be "split" seems like pointless busy work. Not
> as bad in Perl 6 as in Perl 5, but still.
>
> In the end, I think I like the 'naked yield' idea best of the ones we
> have so far. Any comments or other ideas? [1]
>
>
> -'f
>
> [1] Other than that I've used the word 'contrived' too many times. :-)
>
>
>
Re: Compile with ftree-parallelize-loops?
This is a list for users of the Perl 6 programming language. You're in the wrong place. I'd guess you should ask at the gentoo-perl mailing list. Regards, Leon Timmermans On Sat, Nov 29, 2008 at 6:16 PM, Ranguvar Foeseeker <[EMAIL PROTECTED]> wrote: > Hello, > > I recently ran into some trouble using the CFLAG > "ftree-parallelize-loops=4" to compile libperl 5.8.8-r2 (Gentoo > Linux): http://bugs.gentoo.org/show_bug.cgi?id=249234 > > I wanted to make sure this flag is at least semi-sane for libperl? > > Thanks! > > -- > Ranguvar Foeseeker > LLP Insanity FAEAA >
Re: the CGI.pm in Perl 6
Actually, I used them a few times. I agree the model used for html generation is inadequate for most any serious usage. However, if you need to dynamicaly generate forms CGI.pm is unmatched. A modernized equavalent for them would still be very usefull IMHO. Though I agree it might be better put in it's own module. On the other HTML outputting functions: They never really belonged in CGI in the first place I guess. There is no reason they cannot be generalized to XML outputting and be put in an appropriate library. In my experience, it is a very decent method of outputting XML content, specially when your program has a procedural or functional design. gr. Leon On 9/13/06, David Cantrell <[EMAIL PROTECTED]> wrote: On Tue, Sep 12, 2006 at 05:18:19PM +0300, Amir E. Aharoni wrote: > My 0.02 ???: CGI.pm will be better off redesigned and cleaned up, and > for those wanting compatibility a module called CGI5.pm can be > written. > > It will probably be very popular, like p5 regexes ... Hear hear! I wonder how many people really use the HTML-generating bits of CGI.pm? I know I never have, nor have they been used that I can remember anywhere that I've worked, or in any of the non-work projects I've collaborated in. It's always been 'print ""' or more recently using a templating language like TT. -- David Cantrell | top google result for "internet beard fetish club" Computer Science is about lofty design goals and careful algorithmic optimisation. Sysadminning is about cleaning up the resulting mess.
