Re: Is this a bug?

Thank you. Silly me, thinking "this is so simple I don't need to run it through the command-line to test it." :-) Anway, yeah, say $_ for reverse lines Aaron Sherman, M.: P: 617-440-4332 Google Talk, Email and Google Plus: a...@ajs.com Toolsmith, developer, gamer and life-long student.

Re: Is this a bug?

It may make it clearer if I explain the broader objective. I'm trying to learn P6 thoroughly by developing training courses to teach it from scratch. (Fans of Gerald Weinberg may recognise the idea.) Obviously, while doing so, I want to explore pathological cases, both to clarify the concepts and

Re: Is this a bug?

On 19/09/16 16:02, Aaron Sherman wrote: > I'm guessing that what you meant was "say as a function was what I > meant to > use there." In which case: > > say for reverse lines > > or > > for reverse lines { say } > > These are both valid ways of asking for each element of the iterable > thing

Re: Is this a bug?

I'm guessing that what you meant was "say as a function was what I meant to use there." In which case: say for reverse lines or for reverse lines { say } These are both valid ways of asking for each element of the iterable thing returned from lines to be printed with a newline. But remember

Re: Is this a bug?

On Sun, Sep 18, 2016 at 16:49 Parrot Raiser <1parr...@gmail.com> wrote: say { $_ } was the correct thing to use there. (I'm trying to avoid > any mention of O-O for the moment.) > “Trying to avoid any mention of O-O” seems like a Perl 6 obfuscation or golf constraint, not a desirable development

Re: Is this a bug?

On Sun, Sep 18, 2016 at 4:49 PM, Parrot Raiser <1parr...@gmail.com> wrote: > What is this -> ;; $_? is raw { #`(Block|170303864) … } output? It's the gist of a Block, which is what you asked for when you did a `say` on an executable block. Why do you believe `say { $_ }` is the right thing

Re: Is this a bug?

It is the .perl representation of a Block. > On 18 Sep 2016, at 22:49, Parrot Raiser <1parr...@gmail.com> wrote: > > say { $_ } was the correct thing to use there. (I'm trying to avoid > any mention of O-O for the moment.) > say {} was a "what happens if I do this" exercise. > > What is this

Re: Is this a bug?

Remember you can call a block with parentheses: > say { 11 + 31 }; -> ;; $_? is raw { #`(Block|140268472711224) ... } > say { 11 + 31 }(); 42 On Sun, Sep 18, 2016 at 12:58 PM, Elizabeth Mattijsen wrote: > I think you want: > > .say for reverse lines; > > not sure what you

Re: Is this a bug?

I think you want: .say for reverse lines; not sure what you are trying to achieve otherwise, but: say { } producing something like -> ;; $_? is raw { #`(Block|170303864) … } feels entirely correct to me. :-) Liz > On 18 Sep 2016, at 21:52, Parrot Raiser <1parr...@gmail.com>

Is this a bug?

This code: 1 #! /home/guru/bin/perl6 2 3 # Ask for some lines and output them in reverse 4 # Work out the appropriate EOF symbol for the OS 5 6 my $EOF = "CTRL-" ~ ($*DISTRO.is-win ?? "Z" !! "D"); 7 8 say "Please enter some lines and end them with $EOF"; 9 10 say { for reverse lines() {} }; 11 12

[perl6/specs] 2d1c74: fixed my own bug s/=dATA/=data/

) Changed paths: M S28-special-names.pod Log Message: --- fixed my own bug s/=dATA/=data/

Re: Bug?

On 07/14/2011 11:47 PM, Parrot Raiser wrote: When a subroutine is invoked with an empty parameter list, as follows: run_stuff(); sub run_stuff { my ($parm) = @_; say Parameter is $parm; } @_[0] contains Any(). Not Any(), but Any (which say() prints as Any() to ease

Re: Bug?

On Sun, Jul 17, 2011 at 10:40:01AM +0200, Moritz Lenz wrote: On 07/14/2011 11:47 PM, Parrot Raiser wrote: When a subroutine is invoked with an empty parameter list, as follows: run_stuff(); sub run_stuff { my ($parm) = @_; say Parameter is $parm; } @_[0] contains

Re: Bug?

On Jul 14, 2011, at 4:47 PM, Parrot Raiser wrote: When a subroutine is invoked with an empty parameter list, as follows: run_stuff(); sub run_stuff { my ($parm) = @_; say Parameter is $parm; } @_[0] contains Any(). Should it? Yes, but only because of the way you are inspecting it.

Bug?

When a subroutine is invoked with an empty parameter list, as follows: run_stuff(); sub run_stuff { my ($parm) = @_; say Parameter is $parm; } @_[0] contains Any(). Should it?

[perl #81548] [BUG] Can't do 'handles' on a type in Rakudo

FWIW 'has $!a handles TypeObject' is now implemented, and works fine for roles. It doesn't work for classes, because they have a .new method. So the standard .new is overridden, trying to call the .new on an attribute, but since there's no instance yet, the access to the attribute fails. That's

Re: [perl #76442] [BUG} say ?1..2 # prints ones indefinitively

cognominal stef (): Currently the Range creator method does not coerce its parameters. I think Range should be a role so as to impose some constraint. I think  Bool..2  should fail. For what it's worth, I disagree. I think Bool..2 should be equivalent to 0..2 (since Bool is a type object,

[perl #72972] [BUG] False ~~ True in Rakudo

On Sat Feb 20 13:31:33 2010, masak wrote: spinclad rakudo: say False ~~ True p6eval rakudo ec47f3: OUTPUT«1␤» masak o.O spinclad (which is Worng) colomon alpha: say False ~~ True p6eval alpha 30e0ed: OUTPUT«1␤» lue pugs: say False ~~ True p6eval pugs: OUTPUT«␤» * masak submits rakudobug

Re: [perl #72972] [BUG] False ~~ True in Rakudo

On 2010-Feb-22, at 2:08 am, Moritz Lenz wrote: At least I'd find it more intuitive if smart-matching against Bool would coerce the the LHS to Bool and then do a comparison, much like smart-matching against strings and numbers work. The downside is that then: given $thing { when

Re: [perl #72914] [BUG] Rakudo doesn't treat ^$n at the end of an infix:... right

On Wed, Feb 17, 2010 at 7:32 PM, Carl Mäsak perl6-bugs-follo...@perl.org wrote: my @a = (4...^5); say @a.perl # should be 4 3 2 1 0 1 2 3 4, according to TimToady That's 4 ... ^5, right? If so, I don't see how you get that. I'd expect (4,0,1,2,3,4), without the countdown between 4 and 0.

Re: [perl #72914] [BUG] Rakudo doesn't treat ^$n at the end of an infix:... right

On Thu, Feb 18, 2010 at 12:45:23PM -0500, Mark J. Reed wrote: : On Wed, Feb 17, 2010 at 7:32 PM, Carl Mäsak : perl6-bugs-follo...@perl.org wrote: : my @a = (4...^5); say @a.perl # should be 4 3 2 1 0 1 2 3 4, according to TimToady : : : That's 4 ... ^5, right? If so, I don't see how you get

Re: [perl #71536] [BUG] Rakudo allows two multi variants with the exact same signature to be defined

On 22/12/2009 10:22, Moritz Lenz wrote: Carl MXXsak (via RT) wrote: This be Rakudo 8dc189. $ perl6 -e 'multi sub f($a) {}; multi sub f($a) {}; f(42)' Ambiguous dispatch to multi 'f'. Ambiguous candidates had signatures: :(Any $a) :(Any $a) The definition of two variants with equivalent

MMD bug or what?

Hi there, I `m looking into MMD, example: multi t (@a) {1} multi t (Array $a) {2} multi t (Positional $a) {3} multi t (Positional[Array] $a) {4} say t(a b c) 1 say t(Array.new) 2 my $foo does Positional; say t($foo) 1 my @a; say t(@a) 2 I am expected some sort of ambiguous there. Thank

Re: Not a bug?

Ovid (): $ perl6 -e 'my $foo = foo;say { ~ $foo ~ }' ~ foo ~ Easy solution: only use double quotes when you want to interpolate. :) This is not really an option when running 'perl6 -e' under bash, though. // Carl

Re: Not a bug?

On Mon, Jan 12, 2009 at 2:15 AM, Carl Mäsak cma...@gmail.com wrote: Ovid (): $ perl6 -e 'my $foo = foo;say { ~ $foo ~ }' ~ foo ~ Easy solution: only use double quotes when you want to interpolate. :) This is not really an option when running 'perl6 -e' under bash, though. $ perl6 -e 'my

Re: Not a bug?

On Sun, Jan 11, 2009 at 04:41:12PM -0800, Ovid wrote: I really don't think this is a bug, but it did confuse the heck out of me at first. This *is* expected behavior due to how {} is interpolated in strings, yes? $ perl6 -e 'my $foo = foo;say ~ $foo ~ ' foo $ perl6 -e 'my $foo

Re: Not a bug?

On Mon, Jan 12, 2009 at 03:43:47AM -0800, Jon Lang wrote: : On Mon, Jan 12, 2009 at 2:15 AM, Carl Mäsak cma...@gmail.com wrote: : Ovid (): : $ perl6 -e 'my $foo = foo;say { ~ $foo ~ }' :~ foo ~ : : Easy solution: only use double quotes when you want to interpolate. :) : : This is not

Re: Not a bug?

On Mon, Jan 12, 2009 at 1:08 PM, Larry Wall la...@wall.org wrote: On Mon, Jan 12, 2009 at 03:43:47AM -0800, Jon Lang wrote: : On Mon, Jan 12, 2009 at 2:15 AM, Carl Mäsak cma...@gmail.com wrote: : Ovid (): : $ perl6 -e 'my $foo = foo;say { ~ $foo ~ }' :~ foo ~ : : Easy solution:

Re: Not a bug?

On Mon, Jan 12, 2009 at 01:19:12PM -0800, Jon Lang wrote: : As well, isn't there a way to escape a character that would otherwise : be interpolated? If the intent were as you suppose, the original : could be rewritten as: : : $ perl6 -e 'my $foo = foo;say \{ ~ $foo ~ }' Sure, though in any

Re: Not a bug?

On Mon, Jan 12, 2009 at 3:54 PM, Larry Wall la...@wall.org wrote: On Mon, Jan 12, 2009 at 01:19:12PM -0800, Jon Lang wrote: : As well, isn't there a way to escape a character that would otherwise : be interpolated? If the intent were as you suppose, the original : could be rewritten as: :

Not a bug?

I really don't think this is a bug, but it did confuse the heck out of me at first. This *is* expected behavior due to how {} is interpolated in strings, yes? $ perl6 -e 'my $foo = foo;say ~ $foo ~ ' foo $ perl6 -e 'my $foo = foo;say { ~ $foo ~ }' ~ foo ~ Cheers, Ovid -- Buy

Re: Not a bug?

On Sun, Jan 11, 2009 at 04:41:12PM -0800, Ovid wrote: : I really don't think this is a bug, but it did confuse the heck out of me at first. This *is* expected behavior due to how {} is interpolated in strings, yes? : : $ perl6 -e 'my $foo = foo;say ~ $foo ~ ' : foo : $ perl6 -e 'my $foo

Re: Bug or feature? Hash autovivification

On Wed, Dec 31, 2008 at 08:06:48AM -0800, Ovid wrote: Just stumbled across this, but I can't tell from S09 if this is a bug or feature: $ ./perl6 -e 'my %foo; if %fooa {}; say %foo.perl' {a = undef} It's a bug. In order to simplify the slicing implementation Rakudo currently

Bug or feature? Hash autovivification

Just stumbled across this, but I can't tell from S09 if this is a bug or feature: $ ./perl6 -e 'my %foo; if %fooa {}; say %foo.perl' {a = undef} I wasn't expecting auto-vivification there. The examples in S09 use HoH instead of a flat hash: But these bindings do autovivify

Re: Bug or feature? Hash autovivification

On Wed, Dec 31, 2008 at 08:06:48AM -0800, Ovid wrote: : Just stumbled across this, but I can't tell from S09 if this is a bug or feature: : : $ ./perl6 -e 'my %foo; if %fooa {}; say %foo.perl' : {a = undef} Definitely bug. Rvalues aren't supposed to autovivify. Larry

Re: [perl #60828] [BUG] [EMAIL PROTECTED] returns ridicously long lists

Patrick R. Michaud wrote: Currently Rakudo is treating [EMAIL PROTECTED] as though it's prefix:^ on a List, which S03 says If [prefix:^ is] applied to a list, it generates a multidimensional set of subscripts. for ^(3,3) { ... } #

Re: [perl #60828] [BUG] [EMAIL PROTECTED] returns ridicously long lists

On Wed, Nov 26, 2008 at 08:54:50AM +0100, Moritz Lenz wrote: : : : Patrick R. Michaud wrote: : Currently Rakudo is treating [EMAIL PROTECTED] as though it's : prefix:^ on a List, which S03 says : : If [prefix:^ is] applied to a list, it generates a : multidimensional set of

Re: [perl #60828] [BUG] [EMAIL PROTECTED] returns ridicously long lists

On Wed, Nov 26, 2008 at 06:21:22PM -0800, Larry Wall wrote: On Wed, Nov 26, 2008 at 08:54:50AM +0100, Moritz Lenz wrote: : Patrick R. Michaud wrote: : Currently Rakudo is treating [EMAIL PROTECTED] as though it's : prefix:^ on a List, which S03 says : for ^(3,3) { ... } #

Rakudo bug reports still go to [EMAIL PROTECTED]

Some of you may have seen the announcements on the Parrot lists that Parrot will be starting to use trac.parrot.org for its issue tracking and bug reporting system. This is just a note that Rakudo's bug reports will continue to be hosted on the rt.perl.org server, and we will continue to use

Re: [perl #58302] [BUG] binary junctions of undefs in boolean context fails (21/37)

Patrick R. Michaud wrote: On Mon, Aug 25, 2008 at 12:15:05AM +0200, Moritz Lenz wrote: Larry Wall wrote: I think it would be best if all boolean contexts collapse consistently, and I would consider all of those to be boolean contexts. More precisely, and || are boolean on the left, but

Re: [perl #58302] [BUG] binary junctions of undefs in boolean context fails (21/37)

Moritz Lenz wrote: Tests 34 to 36 were a bit overcritical: (0|undef say not ok 34) || say not ok 34; (0undef say not ok 35) || say not ok 35; (0^undef say not ok 36) || say not ok 36; but are easily corrected. The rest seem fine to me. Easier said than done. Question to p6l: do and

Re: [perl #58302] [BUG] binary junctions of undefs in boolean context fails (21/37)

On Sun, Aug 24, 2008 at 09:22:25PM +0200, Moritz Lenz wrote: : Moritz Lenz wrote: : Tests 34 to 36 were a bit overcritical: : : (0|undef say not ok 34) || say not ok 34; : (0undef say not ok 35) || say not ok 35; : (0^undef say not ok 36) || say not ok 36; : : but are easily corrected.

Re: [perl #58302] [BUG] binary junctions of undefs in boolean context fails (21/37)

On Sun, Aug 24, 2008 at 03:00:54PM -0700, Larry Wall wrote: : Question to p6l: do and || autothread? Or do they collapse the : junction prior to evaluation? (I hope the latter, since I think it's : more dwimmy). : : Also do prefix:? and prefix:! collapse the junction? I think it would be

Re: [perl #58302] [BUG] binary junctions of undefs in boolean context fails (21/37)

Larry Wall wrote: On Sun, Aug 24, 2008 at 09:22:25PM +0200, Moritz Lenz wrote: : Moritz Lenz wrote: : Tests 34 to 36 were a bit overcritical: : : (0|undef say not ok 34) || say not ok 34; : (0undef say not ok 35) || say not ok 35; : (0^undef say not ok 36) || say not ok 36; : :

Re: [perl #58302] [BUG] binary junctions of undefs in boolean context fails (21/37)

On Sun, Aug 24, 2008 at 05:05:46PM -0500, Patrick R. Michaud wrote: : On Sun, Aug 24, 2008 at 03:00:54PM -0700, Larry Wall wrote: : : Question to p6l: do and || autothread? Or do they collapse the : : junction prior to evaluation? (I hope the latter, since I think it's : : more dwimmy). : :

Re: [perl #58302] [BUG] binary junctions of undefs in boolean context fails (21/37)

On Mon, Aug 25, 2008 at 12:15:05AM +0200, Moritz Lenz wrote: Larry Wall wrote: I think it would be best if all boolean contexts collapse consistently, and I would consider all of those to be boolean contexts. More precisely, and || are boolean on the left, but not on the right. Very

Re: .perl, nested arrays, parens and a bug with .perl after hyperop

在 May 21, 2007 8:45 AM 時，Juerd Waalboer 寫到： Steffen Schwigon skribis 2007-05-21 1:28 (+0200): That's ARRAY := ARRAY there, so the following should dwym: my @foo := [ 1, 2, 3 ]; However, this does not work with pugs, so I don't know if I am wrong, or pugs is wrong. Pugs is wrong

.perl, nested arrays, parens and a bug with .perl after hyperop

Hi! Yesterday we discussed a strange behaviour of .perl on the result of a hyperoperator. The basic bug is that my @hyp = -« ([1, 2], 3); say @hyp.perl; outputs [(-1, -2), -3] which are strange inner parens inside the brackets that would get flattened after eval. I committed a :todo

Re: Junctions as arguments (Pugs bug)

Ovid wrote: (reversed the message a bit) is 'b', any('a' .. 'h'), 'junctions should work'; This looks like a Test bug; it's doing something like: is 'b', 'a' # not ok is 'b', 'b' # ok is 'b', 'c' # not ok ... If you write: ok 'b' === any('a'..'h') The result is one passing

Re: Junctions as arguments (Pugs bug)

On Wed, Dec 20, 2006 at 10:26:41AM -0600, Jonathan Rockway wrote: : Ovid wrote: : (reversed the message a bit) :is 'b', any('a' .. 'h'), 'junctions should work'; : : This looks like a Test bug; it's doing something like: : :is 'b', 'a' # not ok :is 'b', 'b' # ok :is 'b', 'c

Re: S04 default { } bug?

On Mon, Oct 24, 2005 at 07:39:23AM +0300, Ilmari Vacklin wrote: : Hi, : : S04 says thus: : : The default case: : : default {...} : : is exactly equivalent to : : when true {...} : : However, that parses to: : : if $_ ~~ bool::true { ...; leave } : : Which is not

S04 default { } bug?

Hi, S04 says thus: The default case: default {...} is exactly equivalent to when true {...} However, that parses to: if $_ ~~ bool::true { ...; leave } Which is not executed if $_ is false, unless ~~ bool::true does something special. Perhaps default should be

Re: Pugs Bug

(Replying to p6l instead of p6c as requested.) On Mon, Apr 04, 2005 at 10:39:16AM -0700, Larry Wall wrote: (Now that builtins are just functions out in * space, we can probably afford to throw a few more convenience functions out there for common operations like word splitting and whitespace

Re: Pugs Bug

Shouldn't these be just methods? I guess not. This is Perl and OO is not mandatory, or even desirable all the time. Adriano.

Re: Pugs Bug

On Tue, Apr 05, 2005 at 09:36:18AM +0300, wolverian wrote: : (Replying to p6l instead of p6c as requested.) : : On Mon, Apr 04, 2005 at 10:39:16AM -0700, Larry Wall wrote: : (Now that builtins are just functions out in * space, we can probably : afford to throw a few more convenience functions

Re: Pugs Bug

On Tue, Apr 05, 2005 at 09:21:41AM -0700, Larry Wall wrote: Plus you really don't want to clutter the Str type with every little thing you might want to do with a string. foo.open() will probably work, but only because it doesn't find a Str.open and fails over to MMD dispatch, which ends up

Re: Pugs Bug

wolverian skribis 2005-04-05 19:31 (+0300): Does [EMAIL PROTECTED] DWIM, by the way? I'm not sure about the precedence. Yes, . is supertight. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html

Re: Pugs Bug

On Tue, Apr 05, 2005 at 07:31:40PM +0300, wolverian wrote: : Does [EMAIL PROTECTED] DWIM, by the way? I'm not sure about the precedence. That depends on whether you mean ([EMAIL PROTECTED]).words or ~(@array.words) It happens to mean the latter. A . binds tighter than a symbolic

[POST-RELEASE] parrot-0.0.8.1.tgz fixes a slight MANIFEST bug...

The 'DEVELOPING' file accidentally made its way into the MANIFEST, but doesn't actually exist in the tarball. It's not a problem, as you can delete the appropriate line in the MANIFEST and continue, but given the large file size I thought I should alert you. 0.0.8.1 is being uploaded at the