[perl #127064] [PERF] Variable interpolation in regex very slow

2018-05-13 Thread Daniel Green via RT 
On Tue, 07 Nov 2017 17:14:15 -0800, ddgr...@gmail.com wrote:
> On Tue, 07 Nov 2017 17:10:29 -0800, ddgr...@gmail.com wrote:
> > On Sun, 15 Oct 2017 05:19:54 -0700, ddgr...@gmail.com wrote:
> > > On Thu, 31 Dec 2015 05:39:24 -0800, ju...@jules.uk wrote:
> > > >
> > > >
> > > > On 29/12/2015 23:05, Timo Paulssen via RT wrote:
> > > > > On 12/29/2015 12:46 AM, Jules Field (via RT) wrote:
> > > > >> # New Ticket Created by  Jules Field
> > > > >> # Please include the string:  [perl #127064]
> > > > >> # in the subject line of all future correspondence about this
> > > > >> issue.
> > > > >> # https://rt.perl.org/Ticket/Display.html?id=127064 >
> > > > >>
> > > > >>
> > > > >> Given
> > > > >> my @lines = "some-text.txt".IO.lines;
> > > > >> my $s = 'Jules';
> > > > >> (some-text.txt is about 43k lines)
> > > > >>
> > > > >> Doing
> > > > >> my @matching = @lines.grep(/ $s /);
> > > > >> is about 50 times slower than
> > > > >> my @matching = @lines.grep(/ Jules /);
> > > > >>
> > > > >> And if $s happened to contain anything other than literals, so
> > > > >> I
> > > > >> had
> > > > >> to us
> > > > >> my @matching = @lines.grep(/ <$s> /);
> > > > >> then it's nearly 150 times slower.
> > > > >>
> > > > >> my @matching = @lines.grep($s);
> > > > >> doesn't appear to work. It matches 0 lines but doesn't die.
> > > > >>
> > > > >> The lack of Perl5's straightforward variable interpolation in
> > > > >> regexs
> > > > >> is crippling the speed.
> > > > >> Is there a faster alternative? (other than EVAL to build the
> > > > >> regex)
> > > > >>
> > > > > For now, you can use @lines.grep(*.contains($s)), which will be
> > > > > sufficiently fast.
> > > > >
> > > > > Ideally, our regex optimizer would turn this simple regex into
> > > > > a
> > > > > code
> > > > > that uses .index to find a literal string and construct a match
> > > > > object
> > > > > for that. Or even - if you put a literal "so" in front - turn
> > > > > it
> > > > > into
> > > > > .contains($literal) if it knows that the match object will only
> > > > > be
> > > > > inspected for true/false.
> > > > >
> > > > > Until then, we ought to be able to make interpolation a bit
> > > > > faster.
> > > > >- Timo
> > > > Many thanks for that. I hadn't thought to use Whatever.
> > > >
> > > > I would ideally also be doing case-insensitive regexps, but they
> > > > are
> > > > 50
> > > > times slower than case-sensitive ones, even in trivial cases.
> > > > Maybe a :adverb for rx// that says "give me static (i.e. Perl5-
> > > > style)
> > > > interpolation in this regex"?
> > > > I can see the advantage of passing the variables to the regex
> > > > engine,
> > > > as
> > > > then they can change over time.
> > > >
> > > > But that's not something I want to do very often, far more
> > > > frequently
> > > > I
> > > > just need to construct the regex at run-time and have it go as
> > > > fast
> > > > as
> > > > possible.
> > > >
> > > > Just thoughts from a big Perl5 user (e.g. MailScanner is 50k
> > > > lines
> > > > of
> > > > it!).
> > > >
> > > > Jules
> > >
> > >
> > > I recently attempted to make interpolating into regexes a little
> > > faster. This is what I was using for a benchmark:
> > > perl6 -e 'my @l = "sm.sql".IO.lines; my $s = "Perl6"; my $t = now;
> > > my
> > > @m = @l.grep(/ $s /); say @m.elems; say now - $t'
> > > sm.sql is 10k lines, of which 1283 contain the text "Perl6".
> > >
> > > This is Rakudo version 2017.09 built on MoarVM version 2017.09.1:
> > > / $s / took 5.3s and / <$s> / took 16.5s.
> > >
> > > This is Rakudo version 2017.09-427-gd23a9ba9d built on MoarVM
> > > version
> > > 2017.09.1-595-g716f2277f:
> > > / $s / took 3.2s and / <$s> / took 14.5s.
> > >
> > > However, if you type the string to interpolate it is *much* faster
> > > for
> > > literal interpolation.
> > > perl6 -e 'my @l = "sm.sql".IO.lines; my Str $s = "Perl6"; my $t =
> > > now;
> > > my @m = @l.grep(/ $s /); say @m.elems; say now - $t'
> > > This takes only 0.33s.
> > >
> > > This is still nowhere near as fast as grep(*.contains($s)) though,
> > > which only takes 0.037s.
> >
> >
> > This is Rakudo version 2017.10-143-g0e50993f4 built on MoarVM version
> > 2017.10-58-gad8618468:
> > / $s / took 2.7s and / <$s> / took 7.0s.
> 
> 
> Adding :i (case insensitive adverb), /:i $s / took 3.0s and /:i <$s> /
> took 7.7s.


This is Rakudo version 2018.04.1-76-g9b915f09d built on MoarVM version 
2018.04.1-98-g1aa02fe45
implementing Perl 6.c.
/ $s / took 1.8s and / <$s> / took 2.6s

[perl #123953] Coercion type applied via role parameter fails to multi-dispatch

2017-12-03 Thread Daniel Green via RT 
On Sat, 28 Feb 2015 07:45:31 -0800, b...@abrij.org wrote:
> (10:19:08 AM) skids: m: role g[::T $t] { multi method foo (T $a) {
> "OHAI".say }; multi method foo($a) { "ONOES".say }; };
> g[Int(Str)].new.foo("100")
> (10:19:09 AM) camelia: rakudo-moar 35de75: OUTPUT«ONOES␤»
> (10:20:59 AM) jnthn: Bah, I knew somebody would try that :P
> (10:21:03 AM) vendethiel: *g*
> (10:21:31 AM) jnthn: I only did coercion types so far sufficient that
> we could migrate away from the deprecated "as" in sigs.
> (10:21:50 AM) jnthn: That one should be possible to make work,
> anyways. :)
> (10:22:08 AM) jnthn: It's just a bit fiddly.


Still the same:
$ perl6 -e 'role g[::T $t] { multi method foo (T $a) { "OHAI".say }; multi 
method foo($a) { "ONOES".say }; }; g[Int(Str)].new.foo("100")'
ONOES
$ perl6 --version
This is Rakudo version 2017.11-44-g4a32089fd built on MoarVM version 
2017.11-20-gd23f5ca16
implementing Perl 6.c.:

[perl #130982] [PERF] "for $a..$b -> $i { ... }" loops are sometimes much slower than c-style loops

2017-11-18 Thread Daniel Green via RT 
On Sun, 12 Mar 2017 07:27:37 -0700, allber...@gmail.com wrote:
> On Sun, Mar 12, 2017 at 12:48 AM, Lloyd Fournier 
> wrote:
> 
> > perl6-loop: 84.8739988
> > c-loop: 67.65849241 (1.25 times faster)
> > native-loop: 0.4981954 (135.81 times faster)
> >
> 
> Still quite a lot of optimization to be done on that front. WRT native int,
> one of the issues is needing to track when boxing is/isn't needed,
> otherwise nativizing can be a pessimization because of constant reboxing.
> The optimizer isn't up to tracking boxing like that yet.
> 

FWIW.

$ perl6 native-int-perf.p6 
perl6-loop: 117.55178620 
c-loop: 156.7308145 (0.75 times faster)
native-loop: 1.2542871 (124.96 times faster)

$ perl6 --version
This is Rakudo version 2017.10-211-g2f0da94c3 built on MoarVM version 
2017.10-82-ge876f1484

[perl #131774] [PERF] Simple, if artificial, string concatenation example hogs memory and time

2017-11-10 Thread Daniel Green via RT 
On Sun, 30 Jul 2017 09:49:39 -0700, ronaldxs wrote:
> On Thu, 20 Jul 2017 20:32:12 -0700, lloyd.fo...@gmail.com wrote:
> > I did an experiment a while ago and found that string concatenation
> > in a
> > loop was Ο(n²) in rakudo. I asked about it on irc and jnthn explained
> > to me
> > that this was expected because strings are immutable (and therefore
> > wasn't
> > worth RTing):
> > https://irclog.perlgeek.de/perl6/2015-12-15#i_11720228
> >
> 
> If the string is represented by an array and is immutable then each
> append allocates a new array, copies in the existing prefix string and
> copies the new appended string at the end, which is the sum of an
> arithmetic sequence and so O(n ** 2).  Other languages have immutable
> strings including Java, JavaScript and Python, and each has found ways
> around the problem.  Perl 6 Str objects perform somewhat faster than
> Java String objects (on my system – Java 8?) but Java has mutable
> StringBuffer and StringBuilder classes.  Python v2.7 cheats by making
> strings mutable for the case where a string has a reference count of 1
> (http://blog.mclemon.io/python-efficient-string-concatenation-in-
> python-2016-edition and see the comment in source stringobject.c for
> _PyString_Resize).  For JavaScript FireFox/SpiderMonkey ropes seem to
> solve the problem (https://stackoverflow.com/questions/7299010/why-is-
> string-concatenation-faster-than-array-join) which is also solved in
> other ways by V8 (Node JS) etc.  As noted on IRC the Perl 6 native
> “str” also has an optimization for this case
> (https://irclog.perlgeek.de/perl6-dev/2017-07-27#i_14930258 – sorry
> about any confusion on ropes and V8).
> 
> The memory situation has improved since the ticket was open but at
> 150_000 iterations or 15 million characters there is still a MoarVM
> memory panic with ulimit of 4Gb.


The numbers seem a little better now (though still non-linear):
$ /usr/bin/time perl6 -e 'for (1, 10, 100, 1_000, 10_000, 100_000) -> $limit 
{my $x; my $y = "x" x 100; $x ~= $y for (1..$limit); say "$limit: ", now - 
ENTER now}'
1: 0.0045150
10: 0.0004916
100: 0.00096704
1000: 0.0077635
1: 0.4149077
10: 40.1284791
37.36user 3.66system 0:41.02elapsed 100%CPU (0avgtext+0avgdata 
3776812maxresident)k

$ perl6 --version
This is Rakudo version 2017.10-146-gf8e1a5faa built on MoarVM version 
2017.10-64-g2ca7e8587

[perl #78200] [BUG] LTA error message when using attributes on type objects

2017-11-09 Thread Daniel Green via RT 
On Sun, 05 Nov 2017 07:54:01 -0800, alex.jakime...@gmail.com wrote:
> FWIW the error message seems to be coming from MoarVM:
> https://github.com/MoarVM/MoarVM/blob/ad86184681590c81fc25b9e90b406e5163098796/src/6model/reprconv.c#L607
> (many similar lines like this in that file)
> 
> On 2017-11-05 07:46:17, alex.jakime...@gmail.com wrote:
> > Hey Tobias, it looks like you've been working on this ticket for over
> > two
> > years. How is it going?
> > On 2015-04-09 12:09:55, FROGGS.de wrote:
> > > How about:
> > >
> > > (before)
> > > $ perl6-m -e 'class A { has $!x; method foo { say $!x } }; A.foo'
> > > Cannot look up attributes in a type object
> > > in method foo at -e:1
> > > in block  at -e:1
> > >
> > > (after)
> > > $ perl6-m -e 'class A { has $!x; method foo { say $!x } }; A.foo'
> > > Cannot look up attributes in a type object. Perhaps you need to
> > > instanciate first?
> > > in method foo at -e:1
> > > in block  at -e:1


The error message was recently improved in 
https://github.com/MoarVM/MoarVM/commit/68a18b4f22553bfd96c47c8d7453af881772b3d4#diff-be9fec83f5b58ba42962ded7b65de075

$ perl6-m -e 'class A { has $!x; method foo { say $!x } }; A.foo'
Cannot look up attributes in a A type object
  in method foo at -e line 1
  in block  at -e line 1

[perl #127064] [PERF] Variable interpolation in regex very slow

2017-11-07 Thread Daniel Green via RT 
On Tue, 07 Nov 2017 17:10:29 -0800, ddgr...@gmail.com wrote:
> On Sun, 15 Oct 2017 05:19:54 -0700, ddgr...@gmail.com wrote:
> > On Thu, 31 Dec 2015 05:39:24 -0800, ju...@jules.uk wrote:
> > >
> > >
> > > On 29/12/2015 23:05, Timo Paulssen via RT wrote:
> > > > On 12/29/2015 12:46 AM, Jules Field (via RT) wrote:
> > > >> # New Ticket Created by  Jules Field
> > > >> # Please include the string:  [perl #127064]
> > > >> # in the subject line of all future correspondence about this
> > > >> issue.
> > > >> # https://rt.perl.org/Ticket/Display.html?id=127064 >
> > > >>
> > > >>
> > > >> Given
> > > >> my @lines = "some-text.txt".IO.lines;
> > > >> my $s = 'Jules';
> > > >> (some-text.txt is about 43k lines)
> > > >>
> > > >> Doing
> > > >> my @matching = @lines.grep(/ $s /);
> > > >> is about 50 times slower than
> > > >> my @matching = @lines.grep(/ Jules /);
> > > >>
> > > >> And if $s happened to contain anything other than literals, so I
> > > >> had
> > > >> to us
> > > >> my @matching = @lines.grep(/ <$s> /);
> > > >> then it's nearly 150 times slower.
> > > >>
> > > >> my @matching = @lines.grep($s);
> > > >> doesn't appear to work. It matches 0 lines but doesn't die.
> > > >>
> > > >> The lack of Perl5's straightforward variable interpolation in
> > > >> regexs
> > > >> is crippling the speed.
> > > >> Is there a faster alternative? (other than EVAL to build the
> > > >> regex)
> > > >>
> > > > For now, you can use @lines.grep(*.contains($s)), which will be
> > > > sufficiently fast.
> > > >
> > > > Ideally, our regex optimizer would turn this simple regex into a
> > > > code
> > > > that uses .index to find a literal string and construct a match
> > > > object
> > > > for that. Or even - if you put a literal "so" in front - turn it
> > > > into
> > > > .contains($literal) if it knows that the match object will only
> > > > be
> > > > inspected for true/false.
> > > >
> > > > Until then, we ought to be able to make interpolation a bit
> > > > faster.
> > > >- Timo
> > > Many thanks for that. I hadn't thought to use Whatever.
> > >
> > > I would ideally also be doing case-insensitive regexps, but they
> > > are
> > > 50
> > > times slower than case-sensitive ones, even in trivial cases.
> > > Maybe a :adverb for rx// that says "give me static (i.e. Perl5-
> > > style)
> > > interpolation in this regex"?
> > > I can see the advantage of passing the variables to the regex
> > > engine,
> > > as
> > > then they can change over time.
> > >
> > > But that's not something I want to do very often, far more
> > > frequently
> > > I
> > > just need to construct the regex at run-time and have it go as fast
> > > as
> > > possible.
> > >
> > > Just thoughts from a big Perl5 user (e.g. MailScanner is 50k lines
> > > of
> > > it!).
> > >
> > > Jules
> >
> >
> > I recently attempted to make interpolating into regexes a little
> > faster. This is what I was using for a benchmark:
> > perl6 -e 'my @l = "sm.sql".IO.lines; my $s = "Perl6"; my $t = now; my
> > @m = @l.grep(/ $s /); say @m.elems; say now - $t'
> > sm.sql is 10k lines, of which 1283 contain the text "Perl6".
> >
> > This is Rakudo version 2017.09 built on MoarVM version 2017.09.1:
> > / $s / took 5.3s and / <$s> / took 16.5s.
> >
> > This is Rakudo version 2017.09-427-gd23a9ba9d built on MoarVM version
> > 2017.09.1-595-g716f2277f:
> > / $s / took 3.2s and / <$s> / took 14.5s.
> >
> > However, if you type the string to interpolate it is *much* faster
> > for
> > literal interpolation.
> > perl6 -e 'my @l = "sm.sql".IO.lines; my Str $s = "Perl6"; my $t =
> > now;
> > my @m = @l.grep(/ $s /); say @m.elems; say now - $t'
> > This takes only 0.33s.
> >
> > This is still nowhere near as fast as grep(*.contains($s)) though,
> > which only takes 0.037s.
> 
> 
> This is Rakudo version 2017.10-143-g0e50993f4 built on MoarVM version
> 2017.10-58-gad8618468:
> / $s / took 2.7s and / <$s> / took 7.0s.


Adding :i (case insensitive adverb), /:i $s / took 3.0s and /:i <$s> / took 
7.7s.

[perl #127064] [PERF] Variable interpolation in regex very slow

2017-11-07 Thread Daniel Green via RT 
On Sun, 15 Oct 2017 05:19:54 -0700, ddgr...@gmail.com wrote:
> On Thu, 31 Dec 2015 05:39:24 -0800, ju...@jules.uk wrote:
> >
> >
> > On 29/12/2015 23:05, Timo Paulssen via RT wrote:
> > > On 12/29/2015 12:46 AM, Jules Field (via RT) wrote:
> > >> # New Ticket Created by  Jules Field
> > >> # Please include the string:  [perl #127064]
> > >> # in the subject line of all future correspondence about this
> > >> issue.
> > >> # https://rt.perl.org/Ticket/Display.html?id=127064 >
> > >>
> > >>
> > >> Given
> > >> my @lines = "some-text.txt".IO.lines;
> > >> my $s = 'Jules';
> > >> (some-text.txt is about 43k lines)
> > >>
> > >> Doing
> > >> my @matching = @lines.grep(/ $s /);
> > >> is about 50 times slower than
> > >> my @matching = @lines.grep(/ Jules /);
> > >>
> > >> And if $s happened to contain anything other than literals, so I
> > >> had
> > >> to us
> > >> my @matching = @lines.grep(/ <$s> /);
> > >> then it's nearly 150 times slower.
> > >>
> > >> my @matching = @lines.grep($s);
> > >> doesn't appear to work. It matches 0 lines but doesn't die.
> > >>
> > >> The lack of Perl5's straightforward variable interpolation in
> > >> regexs
> > >> is crippling the speed.
> > >> Is there a faster alternative? (other than EVAL to build the
> > >> regex)
> > >>
> > > For now, you can use @lines.grep(*.contains($s)), which will be
> > > sufficiently fast.
> > >
> > > Ideally, our regex optimizer would turn this simple regex into a
> > > code
> > > that uses .index to find a literal string and construct a match
> > > object
> > > for that. Or even - if you put a literal "so" in front - turn it
> > > into
> > > .contains($literal) if it knows that the match object will only be
> > > inspected for true/false.
> > >
> > > Until then, we ought to be able to make interpolation a bit faster.
> > >- Timo
> > Many thanks for that. I hadn't thought to use Whatever.
> >
> > I would ideally also be doing case-insensitive regexps, but they are
> > 50
> > times slower than case-sensitive ones, even in trivial cases.
> > Maybe a :adverb for rx// that says "give me static (i.e. Perl5-style)
> > interpolation in this regex"?
> > I can see the advantage of passing the variables to the regex engine,
> > as
> > then they can change over time.
> >
> > But that's not something I want to do very often, far more frequently
> > I
> > just need to construct the regex at run-time and have it go as fast
> > as
> > possible.
> >
> > Just thoughts from a big Perl5 user (e.g. MailScanner is 50k lines of
> > it!).
> >
> > Jules
> 
> 
> I recently attempted to make interpolating into regexes a little
> faster. This is what I was using for a benchmark:
> perl6 -e 'my @l = "sm.sql".IO.lines; my $s = "Perl6"; my $t = now; my
> @m = @l.grep(/ $s /); say @m.elems; say now - $t'
> sm.sql is 10k lines, of which 1283 contain the text "Perl6".
> 
> This is Rakudo version 2017.09 built on MoarVM version 2017.09.1:
> / $s / took 5.3s and / <$s> / took 16.5s.
> 
> This is Rakudo version 2017.09-427-gd23a9ba9d built on MoarVM version
> 2017.09.1-595-g716f2277f:
> / $s / took 3.2s and / <$s> / took 14.5s.
> 
> However, if you type the string to interpolate it is *much* faster for
> literal interpolation.
> perl6 -e 'my @l = "sm.sql".IO.lines; my Str $s = "Perl6"; my $t = now;
> my @m = @l.grep(/ $s /); say @m.elems; say now - $t'
> This takes only 0.33s.
> 
> This is still nowhere near as fast as grep(*.contains($s)) though,
> which only takes 0.037s.


This is Rakudo version 2017.10-143-g0e50993f4 built on MoarVM version 
2017.10-58-gad8618468:
/ $s / took 2.7s and / <$s> / took 7.0s.

[perl #127064] [PERF] Variable interpolation in regex very slow

2017-10-15 Thread Daniel Green via RT 
On Thu, 31 Dec 2015 05:39:24 -0800, ju...@jules.uk wrote:
> 
> 
> On 29/12/2015 23:05, Timo Paulssen via RT wrote:
> > On 12/29/2015 12:46 AM, Jules Field (via RT) wrote:
> >> # New Ticket Created by  Jules Field
> >> # Please include the string:  [perl #127064]
> >> # in the subject line of all future correspondence about this issue.
> >> # https://rt.perl.org/Ticket/Display.html?id=127064 >
> >>
> >>
> >> Given
> >> my @lines = "some-text.txt".IO.lines;
> >> my $s = 'Jules';
> >> (some-text.txt is about 43k lines)
> >>
> >> Doing
> >> my @matching = @lines.grep(/ $s /);
> >> is about 50 times slower than
> >> my @matching = @lines.grep(/ Jules /);
> >>
> >> And if $s happened to contain anything other than literals, so I had
> >> to us
> >> my @matching = @lines.grep(/ <$s> /);
> >> then it's nearly 150 times slower.
> >>
> >> my @matching = @lines.grep($s);
> >> doesn't appear to work. It matches 0 lines but doesn't die.
> >>
> >> The lack of Perl5's straightforward variable interpolation in regexs
> >> is crippling the speed.
> >> Is there a faster alternative? (other than EVAL to build the regex)
> >>
> > For now, you can use @lines.grep(*.contains($s)), which will be
> > sufficiently fast.
> >
> > Ideally, our regex optimizer would turn this simple regex into a code
> > that uses .index to find a literal string and construct a match
> > object
> > for that. Or even - if you put a literal "so" in front - turn it into
> > .contains($literal) if it knows that the match object will only be
> > inspected for true/false.
> >
> > Until then, we ought to be able to make interpolation a bit faster.
> >- Timo
> Many thanks for that. I hadn't thought to use Whatever.
> 
> I would ideally also be doing case-insensitive regexps, but they are
> 50
> times slower than case-sensitive ones, even in trivial cases.
> Maybe a :adverb for rx// that says "give me static (i.e. Perl5-style)
> interpolation in this regex"?
> I can see the advantage of passing the variables to the regex engine,
> as
> then they can change over time.
> 
> But that's not something I want to do very often, far more frequently
> I
> just need to construct the regex at run-time and have it go as fast as
> possible.
> 
> Just thoughts from a big Perl5 user (e.g. MailScanner is 50k lines of
> it!).
> 
> Jules


I recently attempted to make interpolating into regexes a little faster. This 
is what I was using for a benchmark:
perl6 -e 'my @l = "sm.sql".IO.lines; my $s = "Perl6"; my $t = now; my @m = 
@l.grep(/ $s /); say @m.elems; say now - $t'
sm.sql is 10k lines, of which 1283 contain the text "Perl6".

This is Rakudo version 2017.09 built on MoarVM version 2017.09.1:
/ $s / took 5.3s and / <$s> / took 16.5s.

This is Rakudo version 2017.09-427-gd23a9ba9d built on MoarVM version 
2017.09.1-595-g716f2277f:
/ $s / took 3.2s and / <$s> / took 14.5s.

However, if you type the string to interpolate it is *much* faster for literal 
interpolation.
perl6 -e 'my @l = "sm.sql".IO.lines; my Str $s = "Perl6"; my $t = now; my @m = 
@l.grep(/ $s /); say @m.elems; say now - $t'
This takes only 0.33s.

This is still nowhere near as fast as grep(*.contains($s)) though, which only 
takes 0.037s.

[perl #132285] [REGRESSION] Error message talks about null strings when trying to create a num32 Blob (Blob[num32].new(2e0))

2017-10-13 Thread Daniel Green via RT 
Fixed in https://github.com/rakudo/rakudo/pull/1189

Not sure where tests should go, roast or rakudo?

[perl #131961] Built-in decoder is dropping bytes on the floor

2017-08-25 Thread Daniel Green via RT 
On Fri, 25 Aug 2017 19:48:51 -0700, ddgr...@gmail.com wrote:
> On Fri, 25 Aug 2017 18:56:37 -0700, alex.jakime...@gmail.com wrote:
> > The input file for this problem is ≈15 MB so please bear with
> > external
> > link:
> > https://files.progarm.org/golfed.gz (1.6 MB compressed)
> >
> > Command:
> > perl6 -ne 'say $++' golfed
> > # or
> > perl6 -ne 'say $++' < golfed
> >
> > Result:
> > 0
> > 1
> > 2
> > … … …
> > 257568
> > 257569
> > 257570
> > Malformed UTF-8
> >   in block  at -e line 1
> >
> >
> > There's no malformed UTF-8 in the file. And if you don't believe me,
> > try this:
> >
> > cat golfed | perl6 -ne 'say $++'
> >
> > There are at least three possible outcomes (it is not as stable as
> > previous examples):
> > (*) Fails after 257570, just like in the previous example
> > (*) Fails after 121712
> > (*) No error, goes through the whole file just fine
> >
> >
> >  sounds more likely to be I/O related than unicode related
> >  like it's dropping bytes on the floor and if the utf8
> > decoder was in (or lands in) the middle of a sequence, boom
> >
> >
> > IRC log: https://irclog.perlgeek.de/perl6-dev/2017-08-26#i_15071860
> >
> > This issue may be related:
> > https://gist.github.com/coke/3feef738886b1e5af79a1ca636146075
> 
> 
> Some gdb output:
> (gdb) break MVM_exception_throw_adhoc
> ...
> (gdb) bt
> #0  MVM_exception_throw_adhoc (tc=tc@entry=0x55758960,
> messageFormat=messageFormat@entry=0x7787053a "Malformed UTF-8") at
> src/core/exceptions.c:721
> #1  0x77808833 in MVM_string_utf8_decodestream
> (tc=tc@entry=0x55758960, ds=ds@entry=0x580cfb70,
> stopper_chars=stopper_chars@entry=0x0, seps=seps@entry=0x580cfc90)
> at src/strings/utf8.c:496
> #2  0x77804720 in run_decode (eof=0, sep_spec=0x580cfc90,
> stopper_chars=0x0, ds=0x580cfb70, tc=0x55758960) at
> src/strings/decode_stream.c:115
> #3  MVM_string_decodestream_get_until_sep (tc=tc@entry=0x55758960,
> ds=ds@entry=0x580cfb70, sep_spec=sep_spec@entry=0x580cfc90,
> chomp=1) at src/strings/decode_stream.c:373
> #4  0x777cbc9f in MVM_decoder_take_line (tc=0x55758960,
> decoder=, chomp=,
> incomplete_ok=) at src/6model/reprs/Decoder.c:259
> #5  0x742434f9 in ?? ()
> #6  0x006e005b in ?? ()
> #7  0x55837010 in ?? ()
> #8  0x55758960 in ?? ()
> #9  0x560f9c98 in ?? ()
> #10 0x70253bc0 in ?? ()
> #11 0x7786ff38 in ?? () from
> //home/dan/Source/perl6/install/lib/libmoar.so
> #12 0x58079ba0 in ?? ()
> #13 0x7777860e in MVM_frame_invoke (tc=0x7fffd6c0,
> static_frame=, callsite=0x55de1938,
> args=0x560f9c58, outer=, code_ref=,
> spesh_cand=) at src/core/frame.c:551
> #14 0x55758960 in ?? ()
> #15 0x560f9c98 in ?? ()
> #16 0x7780398c in MVM_jit_enter_code (tc=,
> cu=, code=) at src/jit/compile.c:146
> #17 0x777652fe in MVM_interp_run (tc=tc@entry=0x55758960,
> initial_invoke=0x0, invoke_data=0x1) at src/core/interp.c:5690
> #18 0x77835322 in MVM_vm_run_file (instance=0x55758010,
> filename=) at src/moar.c:356
> #19 0x541f in main (argc=9, argv=0x7fffdd28) at
> src/main.c:255
> (gdb) call MVM_dump_backtrace(tc)
>at SETTING::src/core/Encoding/Decoder/Builtin.pm:32
> (/home/dan/Source/perl6/install/share/perl6/runtime/CORE.setting.moarvm:consume-
> line-chars)
>  from SETTING::src/core/IO/Handle.pm:235
> (/home/dan/Source/perl6/install/share/perl6/runtime/CORE.setting.moarvm:)
>  from SETTING::src/core/IO/Handle.pm:231
> (/home/dan/Source/perl6/install/share/perl6/runtime/CORE.setting.moarvm:get-
> line-slow-path)
>  from SETTING::src/core/IO/Handle.pm:226
> (/home/dan/Source/perl6/install/share/perl6/runtime/CORE.setting.moarvm:get)
>  from SETTING::src/core/IO/Handle.pm:388
> (/home/dan/Source/perl6/install/share/perl6/runtime/CORE.setting.moarvm:pull-
> one)
>  from SETTING::src/core/Iterable.pm:27
> (/home/dan/Source/perl6/install/share/perl6/runtime/CORE.setting.moarvm:pull-
> one)
>  from SETTING::src/core/Iterable.pm:27
> (/home/dan/Source/perl6/install/share/perl6/runtime/CORE.setting.moarvm:pull-
> one)
>  from SETTING::src/core/Any-iterable-methods.pm:453
> (/home/dan/Source/perl6/install/share/perl6/runtime/CORE.setting.moarvm:sink-
> all)
>  from SETTING::src/core/Seq.pm:188
> (/home/dan/Source/perl6/install/share/perl6/runtime/CORE.setting.moarvm:sink)
>  from -e:1  (:)
>  from -e:1  (:)
>  from gen/moar/stage2/NQPHLL.nqp:1608
> (/home/dan/Source/perl6/install/share/nqp/lib/NQPHLL.moarvm:eval)
>  from gen/moar/stage2/NQPHLL.nqp:1715
> (/home/dan/Source/perl6/install/share/nqp/lib/NQPHLL.moarvm:)
>  from gen/moar/stage2/NQPHLL.nqp:1712
> (/home/dan/Source/perl6/install/share/nqp/lib/NQPHLL.moarvm:command_eval)
>  from src/Perl6/Compiler.nqp:42
> (/home/dan/Source/perl6/install/share/nqp/lib/Perl6/Compiler.moarvm:command_eval)
>  from gen/moar/stage2/NQPHLL.nqp:1696
>

[perl #131961] Built-in decoder is dropping bytes on the floor

2017-08-25 Thread Daniel Green via RT 
On Fri, 25 Aug 2017 18:56:37 -0700, alex.jakime...@gmail.com wrote:
> The input file for this problem is ≈15 MB so please bear with external
> link:
> https://files.progarm.org/golfed.gz (1.6 MB compressed)
> 
> Command:
> perl6 -ne 'say $++' golfed
> # or
> perl6 -ne 'say $++' < golfed
> 
> Result:
> 0
> 1
> 2
> … … …
> 257568
> 257569
> 257570
> Malformed UTF-8
>   in block  at -e line 1
> 
> 
> There's no malformed UTF-8 in the file. And if you don't believe me,
> try this:
> 
> cat golfed | perl6 -ne 'say $++'
> 
> There are at least three possible outcomes (it is not as stable as
> previous examples):
> (*) Fails after 257570, just like in the previous example
> (*) Fails after 121712
> (*) No error, goes through the whole file just fine
> 
> 
>  sounds more likely to be I/O related than unicode related
>  like it's dropping bytes on the floor and if the utf8
> decoder was in (or lands in) the middle of a sequence, boom
> 
> 
> IRC log: https://irclog.perlgeek.de/perl6-dev/2017-08-26#i_15071860
> 
> This issue may be related:
> https://gist.github.com/coke/3feef738886b1e5af79a1ca636146075


Some gdb output:
(gdb) break MVM_exception_throw_adhoc
...
(gdb) bt
#0  MVM_exception_throw_adhoc (tc=tc@entry=0x55758960, 
messageFormat=messageFormat@entry=0x7787053a "Malformed UTF-8") at 
src/core/exceptions.c:721
#1  0x77808833 in MVM_string_utf8_decodestream 
(tc=tc@entry=0x55758960, ds=ds@entry=0x580cfb70, 
stopper_chars=stopper_chars@entry=0x0, seps=seps@entry=0x580cfc90) at 
src/strings/utf8.c:496
#2  0x77804720 in run_decode (eof=0, sep_spec=0x580cfc90, 
stopper_chars=0x0, ds=0x580cfb70, tc=0x55758960) at 
src/strings/decode_stream.c:115
#3  MVM_string_decodestream_get_until_sep (tc=tc@entry=0x55758960, 
ds=ds@entry=0x580cfb70, sep_spec=sep_spec@entry=0x580cfc90, chomp=1) at 
src/strings/decode_stream.c:373
#4  0x777cbc9f in MVM_decoder_take_line (tc=0x55758960, 
decoder=, chomp=, incomplete_ok=) 
at src/6model/reprs/Decoder.c:259
#5  0x742434f9 in ?? ()
#6  0x006e005b in ?? ()
#7  0x55837010 in ?? ()
#8  0x55758960 in ?? ()
#9  0x560f9c98 in ?? ()
#10 0x70253bc0 in ?? ()
#11 0x7786ff38 in ?? () from 
//home/dan/Source/perl6/install/lib/libmoar.so
#12 0x58079ba0 in ?? ()
#13 0x7777860e in MVM_frame_invoke (tc=0x7fffd6c0, 
static_frame=, callsite=0x55de1938, args=0x560f9c58, 
outer=, code_ref=, spesh_cand=) at 
src/core/frame.c:551
#14 0x55758960 in ?? ()
#15 0x560f9c98 in ?? ()
#16 0x7780398c in MVM_jit_enter_code (tc=, cu=, code=) at src/jit/compile.c:146
#17 0x777652fe in MVM_interp_run (tc=tc@entry=0x55758960, 
initial_invoke=0x0, invoke_data=0x1) at src/core/interp.c:5690
#18 0x77835322 in MVM_vm_run_file (instance=0x55758010, 
filename=) at src/moar.c:356
#19 0x541f in main (argc=9, argv=0x7fffdd28) at src/main.c:255
(gdb) call MVM_dump_backtrace(tc)
   at SETTING::src/core/Encoding/Decoder/Builtin.pm:32  
(/home/dan/Source/perl6/install/share/perl6/runtime/CORE.setting.moarvm:consume-line-chars)
 from SETTING::src/core/IO/Handle.pm:235  
(/home/dan/Source/perl6/install/share/perl6/runtime/CORE.setting.moarvm:)
 from SETTING::src/core/IO/Handle.pm:231  
(/home/dan/Source/perl6/install/share/perl6/runtime/CORE.setting.moarvm:get-line-slow-path)
 from SETTING::src/core/IO/Handle.pm:226  
(/home/dan/Source/perl6/install/share/perl6/runtime/CORE.setting.moarvm:get)
 from SETTING::src/core/IO/Handle.pm:388  
(/home/dan/Source/perl6/install/share/perl6/runtime/CORE.setting.moarvm:pull-one)
 from SETTING::src/core/Iterable.pm:27  
(/home/dan/Source/perl6/install/share/perl6/runtime/CORE.setting.moarvm:pull-one)
 from SETTING::src/core/Iterable.pm:27  
(/home/dan/Source/perl6/install/share/perl6/runtime/CORE.setting.moarvm:pull-one)
 from SETTING::src/core/Any-iterable-methods.pm:453  
(/home/dan/Source/perl6/install/share/perl6/runtime/CORE.setting.moarvm:sink-all)
 from SETTING::src/core/Seq.pm:188  
(/home/dan/Source/perl6/install/share/perl6/runtime/CORE.setting.moarvm:sink)
 from -e:1  (:)
 from -e:1  (:)
 from gen/moar/stage2/NQPHLL.nqp:1608  
(/home/dan/Source/perl6/install/share/nqp/lib/NQPHLL.moarvm:eval)
 from gen/moar/stage2/NQPHLL.nqp:1715  
(/home/dan/Source/perl6/install/share/nqp/lib/NQPHLL.moarvm:)
 from gen/moar/stage2/NQPHLL.nqp:1712  
(/home/dan/Source/perl6/install/share/nqp/lib/NQPHLL.moarvm:command_eval)
 from src/Perl6/Compiler.nqp:42  
(/home/dan/Source/perl6/install/share/nqp/lib/Perl6/Compiler.moarvm:command_eval)
 from gen/moar/stage2/NQPHLL.nqp:1696  
(/home/dan/Source/perl6/install/share/nqp/lib/NQPHLL.moarvm:command_line)
 from gen/moar/main.nqp:47  
(/home/dan/Source/perl6/install/share/perl6/runtime/perl6.moarvm:MAIN)
 from gen/moar/main.nqp:38  
(/home/dan/Source/perl6/install/share/perl6/runtime/perl6.moarvm:)
 from :1

[perl #122990] [BUG] Matching an integer capture against a signature with a native integer coercing to Str fails (when it should succeed) in Rakudo

2017-05-13 Thread Daniel Green via RT 
On Thu, 16 Oct 2014 10:43:27 -0700, masak wrote:
>  I'm about to close
> https://rt.perl.org/Ticket/Display.html?id=118581 (because it no
> longer segfaults).
>  just curious: what *should* this return?
>  m: say \(1) ~~ :(1)
>  rakudo-moar 329ed9: OUTPUT«True␤»
>  m: say \(1) ~~ :(Int)
>  rakudo-moar 329ed9: OUTPUT«True␤»
>  m: say \(1) ~~ :(int)
>  rakudo-moar 329ed9: OUTPUT«True␤»
>  m: say \(1) ~~ :(int $x)
>  rakudo-moar 329ed9: OUTPUT«True␤»
>   m: say \(1) ~~ :($x as Str)
>  rakudo-moar 329ed9: OUTPUT«True␤»
>  m: say \(1) ~~ :(int $x as Str)
>  rakudo-moar 329ed9: OUTPUT«False␤»
>  m: say \(1) ~~ :(int as Str)
>  rakudo-moar 329ed9: OUTPUT«False␤»
>  yeah, that feels wrong. :)
> * masak closes the old ticket and opens a new one
>  sounds good, masak++
> 
> I'd expect the two "False" results above to be "True", for consistency
> with the ones that *are* True.


The `as` syntax is now invalid, but the replacement coercion syntax `say \(1) 
~~ :(Str(Int))` still gives inconsistent results:

 m: say \(1) ~~ :(Str(Int))
<+camelia> rakudo-moar b43ed1: OUTPUT: «True␤»
 m: say \(1) ~~ :(Str(int))
<+camelia> rakudo-moar b43ed1: OUTPUT: «False␤»
 m: say \(1) ~~ :(Int(int))
<+camelia> rakudo-moar b43ed1: OUTPUT: «False␤»
 m: say \(1) ~~ :(Int(Int))
<+camelia> rakudo-moar b43ed1: OUTPUT: «True␤»
 m: say \(1) ~~ :(int(int))
<+camelia> rakudo-moar b43ed1: OUTPUT: «False␤»
 m: say \(1) ~~ :(int(Int))
<+camelia> rakudo-moar b43ed1: OUTPUT: «False␤»
 m: say \(1) ~~ :(int)
<+camelia> rakudo-moar b43ed1: OUTPUT: «True␤»
 m: say \(1) ~~ :(Int)
<+camelia> rakudo-moar b43ed1: OUTPUT: «True␤»

[perl #120930] [BUG] LTA error message for ::bar() when such a sub isn't found in Rakudo

2017-05-09 Thread Daniel Green via RT 
On Mon, 07 Jul 2014 13:35:26 -0700, coke wrote:
> On Sat Jan 04 06:24:21 2014, masak wrote:
> >  p: say ::bar()
> >  rakudo-parrot e32249: OUTPUT«No such method 'Any' for
> > invocant of type 'Parcel' [...]
> >  anyway, that error mesage is LTA
> > * masak submits LTA error message
> 
> Even more LTAs:
> 
> 16:34 < [Coke]> r: say ::bar() # RT #120930
> 16:34 <+camelia> rakudo-jvm 25c511: OUTPUT«No such method 'Any' for
> invocant of
>  type 'Parcel'␤  in any  at
> gen/jvm/BOOTSTRAP.nqp:1661␤  in
>  block  at /tmp/tmpfile:1␤␤»
> 16:34 <+camelia> ..rakudo-parrot 25c511: OUTPUT«No such method 'Any'
> for
>  invocant of type 'Parcel'␤  in any  at
>  gen/parrot/BOOTSTRAP.nqp:1673␤  in block  at
> /tmp/tmpfile:1␤␤»
> 16:34 <+camelia> ..rakudo-moar 25c511: OUTPUT«Cannot find method
> 'Any'␤  in
>  block  at /tmp/tmpfile:1␤␤»


It now says:

[22:44]  m: say ::bar()
[22:44] <+camelia> rakudo-moar 643593: OUTPUT: «Cannot find method 'Any' on 
object of type List␤  in block  at  line 1␤␤»

[perl #122475] [BUG] reduce metaop of hyper metaop only works with two or more elements in Rakudo

2017-05-09 Thread Daniel Green via RT 
On Tue, 05 Aug 2014 14:27:17 -0700, masak wrote:
>  m: my @a = $(1, 2, 3); say [>>+<<] @a;
>  rakudo-moar 3ad15f: OUTPUT«Not enough positional parameters
> passed; got 1 but expected 2 [...]
>  m: my @a = $(1, 2, 3), $(0, 0, 0); say [>>+<<] @a;
>  rakudo-moar 3ad15f: OUTPUT«1 2 3␤»
>  ^- i don't know how to formulate the bug report for this
>  "[BUG] instance of the reduce metaop which should work with
> one-element list only works with two or more elements in Rakudo"
>  perfect
>  would you do the honors? :)
> * masak submits rakudobug
>  thank you :)
> 
> I think I agree that this is a bug, with the following reasoning: [+]
> accepts a list of zero, one, or many elements. The zero and one cases
> are special-cased, to be sure, because addition usually involves two
> things. But here it essentially means "sum", which can have any number
> of things.
> 
> Similarly, [>>+<<] is also a kind of sum: in this case, it is summing
> the internal structures of the items in the list (which have to be of
> the same shape, because the >> << are pointing inwards). So the >> <<
> restrict the shape of the items themselves, but not the number of
> items. So this kind of sum of one item should work, and just return
> that item.
> 
> In that vein, the 0-elem case should also work:
> 
>  m: my @a; say [>>+<<] @a
>  rakudo-moar 3ad15f: OUTPUT«Not enough positional parameters
> passed; got 0 but expected 2 [...]


The 1-element case was fixed in  
https://github.com/rakudo/rakudo/commit/6b3930e92714375a96851b058e6e0d1fd27eae61.

The 0-element case doesn't die on rakudo-j, but doesn't return anything at all.

[21:25]  j: my @a; dd [>>+<<] @a
[21:25] <+camelia> rakudo-jvm fb4f16: ( no output )
[21:26]  m: my @a; dd [>>+<<] @a
[21:26] <+camelia> rakudo-moar 643593: OUTPUT: «Too few positionals passed; 
expected 2 arguments but got 0␤  in block  at  line 1␤␤»

Tests added in https://github.com/perl6/roast/commit/1244df8c4a

Re: [perl #128969] AutoReply: [RFC] Proposal to move grammar related part of error messages behind a runtime flag

2016-08-18 Thread Daniel Green 
Another suggestion would be to leave them as is unless you're running with
'-e' (though again with an option to turn them on in that case if you so
desire).

On Tue, Aug 16, 2016 at 9:25 PM, perl6 via RT 
wrote:

> Greetings,
>
> This message has been automatically generated in response to the
> creation of a trouble ticket regarding:
> "[RFC] Proposal to move grammar related part of error messages
> behind a runtime flag",
> a summary of which appears below.
>
> There is no need to reply to this message right now.  Your ticket has been
> assigned an ID of [perl #128969].
>
> Please include the string:
>
>  [perl #128969]
>
> in the subject line of all future correspondence about this issue. To do
> so,
> you may reply to this message.
>
> Thank you,
> perl6-bugs-follo...@perl.org
>
> -
> Paraphrasing from IRC where my first comment starts here:
> http://irclog.perlgeek.de/perl6/2016-08-17#i_13035789
>
> My feeling has always been that Perl 6's errors are good, but I'm
> sympathetic to whoever it was that complained that the list of "expecting
> any of" things wasn't all that helpful in the general case. Personally, I
> have never once gotten any useful information out of them, but the messages
> that precede them are very helpful. E.g., perl6 -ne '.say if /asdf \s+ \/'
> gives the error message:
>
> ===SORRY!===
> Regex not terminated.
> at -e:1
> --> .say if /asdf \s+ \/⏏
> Unable to parse regex; couldn't find final '/'
> at -e:1
> --> .say if /asdf \s+ \/⏏
> expecting any of:
> infix stopper
>
> The first two parts are really helpful, but the "expecting any of" I
> ignore. I understand that people doing fancy grammar related things
> probably do find them very useful. However, my impression is that most
> people "in the wild" writing Perl (5 or 6) are frequently doing command
> line text manipulation and things like that (akin to my example). And for
> them, the first part of the error message is extremely useful and the
> second part isn't (IMHO).
>
> So I propose turning the second part (i.e, "expecting any of" and things
> like that) off in the general case and adding a flag to turn it on
> (--grammar-errors?), like we already have for --ll-exceptions.
>

Re: [perl #127973] [BUG] native strings not allowed to be as big as regular strings

2016-07-09 Thread Daniel Green 
Yeah, I filed the slowness as a bug (127972) a while ago.

On Sat, Jul 9, 2016 at 6:23 PM, Zoffix Znet via RT <
perl6-bugs-follo...@perl.org> wrote:

> Oh, my bad. I didn't wait long enough. Takes over a minute:
>
> zoffix@VirtualBox:~$ time perl6 -e 'my str $a = "a" x 2**30;say $a.chars'
> ===SORRY!===
> String too long for string constants segment
>
> real1m15.794s
> user0m7.408s
> sys 0m9.432s
> zoffix@VirtualBox:~$
>
>

Re: [perl #127973] [BUG] native strings not allowed to be as big as regular strings

2016-07-09 Thread Daniel Green 
I still get the exact same error, it just takes 10+ seconds.

This is Rakudo version 2016.06-204-g959cd3b built on MoarVM version
2016.06-11-gf9dad06

On Sat, Jul 9, 2016 at 4:55 PM, Zoffix Znet via RT <
perl6-bugs-follo...@perl.org> wrote:

> This appears to hang now:
>
> zoffix@VirtualBox:~$ perl6 -e 'my $a = "a" x 2**30;say $a.chars'
> 1073741824
> zoffix@VirtualBox:~$ perl6 -e 'my str $a = "a" x 2**30;say $a.chars'
> ^C
> zoffix@VirtualBox:~$ perl6 -v
> This is Rakudo version 2016.06-154-g55c359e built on MoarVM version
> 2016.06-9-g8fc21d5
> implementing Perl 6.c.
>
>

[perl #125489]

2016-06-17 Thread Daniel Green 
Implemented in Rakudo PR #773 (https://github.com/rakudo/rakudo/pull/773).

Re: [perl #128280] core dump while profiling with a '.race'

2016-06-16 Thread Daniel Green 
Also, the Kubuntu system Rakudo was built with --gen-moar, on the Arch
Linux system MoarMV, NQP, and Rakudo were all built separately with the
same --prefix.

On Wed, Jun 15, 2016 at 12:01 AM, Daniel Green <ddgr...@gmail.com> wrote:

> Doesn't happen every time, seem to be about 1 in 5. Here are the results
> for two different system.
>
> This is an up-to-date Arch Linux
>
> uname -a
> Linux  4.5.3-1-ARCH #1 SMP PREEMPT Sat May 7 20:43:57 CEST 2016
> x86_64 GNU/Linux
>
> p6 --version
> This is Rakudo version 2016.05-145-gac0dcdd built on MoarVM version
> 2016.05-34-gfbe9e24
> implementing Perl 6.c.
>
> p6 --profile --profile-filename=race1.json -e 'say
> (^10).race(batch=>1, degree=>4).map({$_}).grep(* > 12345).elems'
> Segmentation fault (core dumped)
>
>
> This is Kubuntu 16.04, on an Intel(R) Core(TM) i5-4200U
>
> uname -a
> Linux  4.4.0-22-generic #40-Ubuntu SMP Thu May 12 22:03:46 UTC
> 2016 x86_64 x86_64 x86_64 GNU/Linux
>
> ./perl6 --version
> This is Rakudo version 2016.05-145-gac0dcdd built on MoarVM version
> 2016.05-17-g6075599
> implementing Perl 6.c.
>
> ./perl6 --profile --profile-filename=race1.json -e 'say
> (^10).race(batch=>1, degree=>4).map({$_}).grep(* > 12345).elems'
> *** Error in `/home/dan/Source/perl6/rakudo/install/bin/moar': double free
> or corruption (fasttop): 0x7fdaa8328e90 ***
> === Backtrace: =
> /lib/x86_64-linux-gnu/libc.so.6(+0x77725)[0x7fdabdce5725]
> /lib/x86_64-linux-gnu/libc.so.6(+0x7ff4a)[0x7fdabdcedf4a]
> /lib/x86_64-linux-gnu/libc.so.6(cfree+0x4c)[0x7fdabdcf1abc]
>
> //home/dan/Source/perl6/rakudo/install/lib/libmoar.so(MVM_spesh_graph_destroy+0x5f)[0x7fdabe213f1f]
>
> //home/dan/Source/perl6/rakudo/install/lib/libmoar.so(MVM_profile_instrument+0x2e3)[0x7fdabe24fb23]
>
> //home/dan/Source/perl6/rakudo/install/lib/libmoar.so(MVM_frame_invoke+0xdc)[0x7fdabe1a2fbc]
>
> //home/dan/Source/perl6/rakudo/install/lib/libmoar.so(+0x1ad3f3)[0x7fdabe1e43f3]
>
> //home/dan/Source/perl6/rakudo/install/lib/libmoar.so(MVM_interp_run+0x114a9)[0x7fdabe19b069]
>
> //home/dan/Source/perl6/rakudo/install/lib/libmoar.so(+0x1749fe)[0x7fdabe1ab9fe]
>
> //home/dan/Source/perl6/rakudo/install/lib/libmoar.so(+0x23ddf7)[0x7fdabe274df7]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x76fa)[0x7fdabd74f6fa]
> /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7fdabdd74b5d]
> === Memory map: 
> 0040-00402000 r-xp  08:01 6954054
> /home/dan/Source/perl6/rakudo/install/bin/moar
> 00601000-00602000 r--p 1000 08:01 6954054
> /home/dan/Source/perl6/rakudo/install/bin/moar
> 00602000-00603000 rw-p 2000 08:01 6954054
> /home/dan/Source/perl6/rakudo/install/bin/moar
> 00cde000-057bd000 rw-p  00:00 0
> [heap]
> 7fdaa000-7fdaa0021000 rw-p  00:00 0
> 7fdaa0021000-7fdaa400 ---p  00:00 0
> 7fdaa71e7000-7fdaa71fd000 r-xp  08:01 4199293
> /lib/x86_64-linux-gnu/libgcc_s.so.1
> 7fdaa71fd000-7fdaa73fc000 ---p 00016000 08:01 4199293
> /lib/x86_64-linux-gnu/libgcc_s.so.1
> 7fdaa73fc000-7fdaa73fd000 rw-p 00015000 08:01 4199293
> /lib/x86_64-linux-gnu/libgcc_s.so.1
> 7fdaa73fd000-7fdaa800 rw-p  00:00 0
> 7fdaa800-7fdaa8444000 rw-p  00:00 0
> 7fdaa8444000-7fdaac00 ---p  00:00 0
> 7fdaac00-7fdaac4ad000 rw-p  00:00 0
> 7fdaac4ad000-7fdab000 ---p  00:00 0
> 7fdab000-7fdab04da000 rw-p  00:00 0
> 7fdab04da000-7fdab400 ---p  00:00 0
> 7fdab400-7fdab4567000 rw-p  00:00 0
> 7fdab4567000-7fdab800 ---p  00:00 0
> 7fdab81a8000-7fdab8239000 rw-p  00:00 0
> 7fdab8271000-7fdab8272000 rw-p  00:00 0
> 7fdab8272000-7fdab8283000 r-xp  00:00 0
> 7fdab8283000-7fdab8a85000 rw-p  00:00 0
> 7fdab8a85000-7fdab8ab6000 r-xp  00:00 0
> 7fdab8ab6000-7fdab8ab7000 ---p  00:00 0
> 7fdab8ab7000-7fdab92b7000 rwxp  00:00 0
> 7fdab92b7000-7fdab96b8000 rw-p  00:00 0
> 7fdab96b8000-7fdab96b9000 ---p  00:00 0
> 7fdab96b9000-7fdab9eb9000 rwxp  00:00 0
> 7fdab9eb9000-7fdaba2ba000 rw-p  00:00 0
> 7fdaba2ba000-7fdaba2bb000 ---p  00:00 0
> 7fdaba2bb000-7fdabaabb000 rwxp  00:00 0
> 7fdabaabb000-7fdabaebc000 rw-p  00:00 0
> 7fdabaebc000-7fdabaebd000 ---p  00:00 0
> 7fdabaebd000-7fdabb6bd000 rwxp  00:00 0
> 7fdabb6bd000-7fdabbabe000 rw-p  00:00 0
> 7fdabbabe000-7fdabbaf r-xp  00:00 0
> 7fdabbaf-7fdabbc4b000 rw-p  00:00 0
> 7fdabbc4b000-7fdabbc92000 r--p  08:01 6816489
> /home/dan/Source/perl6/rakudo/blib/Perl6/Metamodel.moarvm
> 7fdabbc92000-7fdabbcbe000 r--p 0

Re: [perl #128280] core dump while profiling with a '.race'

2016-06-16 Thread Daniel Green 
Doesn't happen every time, seem to be about 1 in 5. Here are the results
for two different system.

This is an up-to-date Arch Linux

uname -a
Linux  4.5.3-1-ARCH #1 SMP PREEMPT Sat May 7 20:43:57 CEST 2016
x86_64 GNU/Linux

p6 --version
This is Rakudo version 2016.05-145-gac0dcdd built on MoarVM version
2016.05-34-gfbe9e24
implementing Perl 6.c.

p6 --profile --profile-filename=race1.json -e 'say (^10).race(batch=>1,
degree=>4).map({$_}).grep(* > 12345).elems'
Segmentation fault (core dumped)


This is Kubuntu 16.04, on an Intel(R) Core(TM) i5-4200U

uname -a
Linux  4.4.0-22-generic #40-Ubuntu SMP Thu May 12 22:03:46 UTC
2016 x86_64 x86_64 x86_64 GNU/Linux

./perl6 --version
This is Rakudo version 2016.05-145-gac0dcdd built on MoarVM version
2016.05-17-g6075599
implementing Perl 6.c.

./perl6 --profile --profile-filename=race1.json -e 'say
(^10).race(batch=>1, degree=>4).map({$_}).grep(* > 12345).elems'
*** Error in `/home/dan/Source/perl6/rakudo/install/bin/moar': double free
or corruption (fasttop): 0x7fdaa8328e90 ***
=== Backtrace: =
/lib/x86_64-linux-gnu/libc.so.6(+0x77725)[0x7fdabdce5725]
/lib/x86_64-linux-gnu/libc.so.6(+0x7ff4a)[0x7fdabdcedf4a]
/lib/x86_64-linux-gnu/libc.so.6(cfree+0x4c)[0x7fdabdcf1abc]
//home/dan/Source/perl6/rakudo/install/lib/libmoar.so(MVM_spesh_graph_destroy+0x5f)[0x7fdabe213f1f]
//home/dan/Source/perl6/rakudo/install/lib/libmoar.so(MVM_profile_instrument+0x2e3)[0x7fdabe24fb23]
//home/dan/Source/perl6/rakudo/install/lib/libmoar.so(MVM_frame_invoke+0xdc)[0x7fdabe1a2fbc]
//home/dan/Source/perl6/rakudo/install/lib/libmoar.so(+0x1ad3f3)[0x7fdabe1e43f3]
//home/dan/Source/perl6/rakudo/install/lib/libmoar.so(MVM_interp_run+0x114a9)[0x7fdabe19b069]
//home/dan/Source/perl6/rakudo/install/lib/libmoar.so(+0x1749fe)[0x7fdabe1ab9fe]
//home/dan/Source/perl6/rakudo/install/lib/libmoar.so(+0x23ddf7)[0x7fdabe274df7]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x76fa)[0x7fdabd74f6fa]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7fdabdd74b5d]
=== Memory map: 
0040-00402000 r-xp  08:01 6954054
/home/dan/Source/perl6/rakudo/install/bin/moar
00601000-00602000 r--p 1000 08:01 6954054
/home/dan/Source/perl6/rakudo/install/bin/moar
00602000-00603000 rw-p 2000 08:01 6954054
/home/dan/Source/perl6/rakudo/install/bin/moar
00cde000-057bd000 rw-p  00:00 0
[heap]
7fdaa000-7fdaa0021000 rw-p  00:00 0
7fdaa0021000-7fdaa400 ---p  00:00 0
7fdaa71e7000-7fdaa71fd000 r-xp  08:01 4199293
/lib/x86_64-linux-gnu/libgcc_s.so.1
7fdaa71fd000-7fdaa73fc000 ---p 00016000 08:01 4199293
/lib/x86_64-linux-gnu/libgcc_s.so.1
7fdaa73fc000-7fdaa73fd000 rw-p 00015000 08:01 4199293
/lib/x86_64-linux-gnu/libgcc_s.so.1
7fdaa73fd000-7fdaa800 rw-p  00:00 0
7fdaa800-7fdaa8444000 rw-p  00:00 0
7fdaa8444000-7fdaac00 ---p  00:00 0
7fdaac00-7fdaac4ad000 rw-p  00:00 0
7fdaac4ad000-7fdab000 ---p  00:00 0
7fdab000-7fdab04da000 rw-p  00:00 0
7fdab04da000-7fdab400 ---p  00:00 0
7fdab400-7fdab4567000 rw-p  00:00 0
7fdab4567000-7fdab800 ---p  00:00 0
7fdab81a8000-7fdab8239000 rw-p  00:00 0
7fdab8271000-7fdab8272000 rw-p  00:00 0
7fdab8272000-7fdab8283000 r-xp  00:00 0
7fdab8283000-7fdab8a85000 rw-p  00:00 0
7fdab8a85000-7fdab8ab6000 r-xp  00:00 0
7fdab8ab6000-7fdab8ab7000 ---p  00:00 0
7fdab8ab7000-7fdab92b7000 rwxp  00:00 0
7fdab92b7000-7fdab96b8000 rw-p  00:00 0
7fdab96b8000-7fdab96b9000 ---p  00:00 0
7fdab96b9000-7fdab9eb9000 rwxp  00:00 0
7fdab9eb9000-7fdaba2ba000 rw-p  00:00 0
7fdaba2ba000-7fdaba2bb000 ---p  00:00 0
7fdaba2bb000-7fdabaabb000 rwxp  00:00 0
7fdabaabb000-7fdabaebc000 rw-p  00:00 0
7fdabaebc000-7fdabaebd000 ---p  00:00 0
7fdabaebd000-7fdabb6bd000 rwxp  00:00 0
7fdabb6bd000-7fdabbabe000 rw-p  00:00 0
7fdabbabe000-7fdabbaf r-xp  00:00 0
7fdabbaf-7fdabbc4b000 rw-p  00:00 0
7fdabbc4b000-7fdabbc92000 r--p  08:01 6816489
/home/dan/Source/perl6/rakudo/blib/Perl6/Metamodel.moarvm
7fdabbc92000-7fdabbcbe000 r--p  08:01 6816491
/home/dan/Source/perl6/rakudo/blib/Perl6/BOOTSTRAP.moarvm
7fdabbcbe000-7fdabbce9000 rw-p  00:00 0
7fdabbce9000-7fdabc774000 r--p  08:01 6684906
/home/dan/Source/perl6/rakudo/CORE.setting.moarvm
7fdabc774000-7fdabc77b000 r-xp  08:01 6816481
/home/dan/Source/perl6/rakudo/dynext/libperl6_ops_moar.so
7fdabc77b000-7fdabc97a000 ---p 7000 08:01 6816481
/home/dan/Source/perl6/rakudo/dynext/libperl6_ops_moar.so
7fdabc97a000-7fdabc97b000 r--p 6000 08:01 6816481
/home/dan/Source/perl6/rakudo/dynext/libperl6_ops_moar.so
7fdabc97b000-7fdabc97c000 rw-p 7000 08:01 6816481
/home/dan/Source/perl6/rakudo/dynext/libperl6_ops_moar.so
7fdabc97c000-7fdabc9a3000 r--p  08:01 6816486

Re: [perl #128280] core dump while profiling with a '.race'

2016-06-16 Thread Daniel Green 
Also, running it ~30 times without profiling never saw a crash.

On Wed, Jun 15, 2016 at 12:04 AM, Daniel Green <ddgr...@gmail.com> wrote:

> Also, the Kubuntu system Rakudo was built with --gen-moar, on the Arch
> Linux system MoarMV, NQP, and Rakudo were all built separately with the
> same --prefix.
>
> On Wed, Jun 15, 2016 at 12:01 AM, Daniel Green <ddgr...@gmail.com> wrote:
>
>> Doesn't happen every time, seem to be about 1 in 5. Here are the results
>> for two different system.
>>
>> This is an up-to-date Arch Linux
>>
>> uname -a
>> Linux  4.5.3-1-ARCH #1 SMP PREEMPT Sat May 7 20:43:57 CEST 2016
>> x86_64 GNU/Linux
>>
>> p6 --version
>> This is Rakudo version 2016.05-145-gac0dcdd built on MoarVM version
>> 2016.05-34-gfbe9e24
>> implementing Perl 6.c.
>>
>> p6 --profile --profile-filename=race1.json -e 'say
>> (^10).race(batch=>1, degree=>4).map({$_}).grep(* > 12345).elems'
>> Segmentation fault (core dumped)
>>
>>
>> This is Kubuntu 16.04, on an Intel(R) Core(TM) i5-4200U
>>
>> uname -a
>> Linux  4.4.0-22-generic #40-Ubuntu SMP Thu May 12 22:03:46 UTC
>> 2016 x86_64 x86_64 x86_64 GNU/Linux
>>
>> ./perl6 --version
>> This is Rakudo version 2016.05-145-gac0dcdd built on MoarVM version
>> 2016.05-17-g6075599
>> implementing Perl 6.c.
>>
>> ./perl6 --profile --profile-filename=race1.json -e 'say
>> (^10).race(batch=>1, degree=>4).map({$_}).grep(* > 12345).elems'
>> *** Error in `/home/dan/Source/perl6/rakudo/install/bin/moar': double
>> free or corruption (fasttop): 0x7fdaa8328e90 ***
>> === Backtrace: =
>> /lib/x86_64-linux-gnu/libc.so.6(+0x77725)[0x7fdabdce5725]
>> /lib/x86_64-linux-gnu/libc.so.6(+0x7ff4a)[0x7fdabdcedf4a]
>> /lib/x86_64-linux-gnu/libc.so.6(cfree+0x4c)[0x7fdabdcf1abc]
>>
>> //home/dan/Source/perl6/rakudo/install/lib/libmoar.so(MVM_spesh_graph_destroy+0x5f)[0x7fdabe213f1f]
>>
>> //home/dan/Source/perl6/rakudo/install/lib/libmoar.so(MVM_profile_instrument+0x2e3)[0x7fdabe24fb23]
>>
>> //home/dan/Source/perl6/rakudo/install/lib/libmoar.so(MVM_frame_invoke+0xdc)[0x7fdabe1a2fbc]
>>
>> //home/dan/Source/perl6/rakudo/install/lib/libmoar.so(+0x1ad3f3)[0x7fdabe1e43f3]
>>
>> //home/dan/Source/perl6/rakudo/install/lib/libmoar.so(MVM_interp_run+0x114a9)[0x7fdabe19b069]
>>
>> //home/dan/Source/perl6/rakudo/install/lib/libmoar.so(+0x1749fe)[0x7fdabe1ab9fe]
>>
>> //home/dan/Source/perl6/rakudo/install/lib/libmoar.so(+0x23ddf7)[0x7fdabe274df7]
>> /lib/x86_64-linux-gnu/libpthread.so.0(+0x76fa)[0x7fdabd74f6fa]
>> /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7fdabdd74b5d]
>> === Memory map: 
>> 0040-00402000 r-xp  08:01 6954054
>> /home/dan/Source/perl6/rakudo/install/bin/moar
>> 00601000-00602000 r--p 1000 08:01 6954054
>> /home/dan/Source/perl6/rakudo/install/bin/moar
>> 00602000-00603000 rw-p 2000 08:01 6954054
>> /home/dan/Source/perl6/rakudo/install/bin/moar
>> 00cde000-057bd000 rw-p  00:00 0
>> [heap]
>> 7fdaa000-7fdaa0021000 rw-p  00:00 0
>> 7fdaa0021000-7fdaa400 ---p  00:00 0
>> 7fdaa71e7000-7fdaa71fd000 r-xp  08:01 4199293
>> /lib/x86_64-linux-gnu/libgcc_s.so.1
>> 7fdaa71fd000-7fdaa73fc000 ---p 00016000 08:01 4199293
>> /lib/x86_64-linux-gnu/libgcc_s.so.1
>> 7fdaa73fc000-7fdaa73fd000 rw-p 00015000 08:01 4199293
>> /lib/x86_64-linux-gnu/libgcc_s.so.1
>> 7fdaa73fd000-7fdaa800 rw-p  00:00 0
>> 7fdaa800-7fdaa8444000 rw-p  00:00 0
>> 7fdaa8444000-7fdaac00 ---p  00:00 0
>> 7fdaac00-7fdaac4ad000 rw-p  00:00 0
>> 7fdaac4ad000-7fdab000 ---p  00:00 0
>> 7fdab000-7fdab04da000 rw-p  00:00 0
>> 7fdab04da000-7fdab400 ---p  00:00 0
>> 7fdab400-7fdab4567000 rw-p  00:00 0
>> 7fdab4567000-7fdab800 ---p  00:00 0
>> 7fdab81a8000-7fdab8239000 rw-p  00:00 0
>> 7fdab8271000-7fdab8272000 rw-p  00:00 0
>> 7fdab8272000-7fdab8283000 r-xp  00:00 0
>> 7fdab8283000-7fdab8a85000 rw-p  00:00 0
>> 7fdab8a85000-7fdab8ab6000 r-xp  00:00 0
>> 7fdab8ab6000-7fdab8ab7000 ---p  00:00 0
>> 7fdab8ab7000-7fdab92b7000 rwxp  00:00 0
>> 7fdab92b7000-7fdab96b8000 rw-p  00:00 0
>> 7fdab96b8000-7fdab96b9000 ---p  00:00 0
>> 7fdab96b9000-7fdab9eb9000 rwxp  00:00 0
>> 7fdab9eb9000-7fdaba2ba000 rw-p  00:00 0
>> 7fdaba2ba000-7fdaba2bb000 ---p  00:00 0
>>

[perl #128306]

2016-06-12 Thread Daniel Green 
Fixed in Rakudo PR #785 (https://github.com/rakudo/rakudo/pull/785).

[perl #128210]

2016-06-01 Thread Daniel Green 
I've been looking into this and just got some clarification from TimToady
on expected behaviour for adverbs and chains in general (
http://irclog.perlgeek.de/perl6/2016-06-02#i_12589974). The gist is that
adverbs should be placed at the end of a chain and then distributed to all
the operators in the chain, which will of course make the example in this
ticket "just work".

Dan

[perl #128214]

2016-06-01 Thread Daniel Green 
Even if there are no other changes to existing behaviour, I would still
suggest 'warn'ing or 'note'ing when a non-existent part is hit and
resolving is stopped. Or at least changing the documentation, because the
current behaviour is definitely a bit surprising (at least in my opinion).

Dan

Re: [perl #127881] [BUG] slow array slicing

2016-04-13 Thread Daniel Green 
Where in Rakudo is the slowdown? I'm by no means a compiler developer, but
I enjoy tinkering.

Dan

On Wed, Apr 13, 2016 at 8:04 AM, Elizabeth Mattijsen via RT <
perl6-bugs-follo...@perl.org> wrote:

> > On 12 Apr 2016, at 04:40, Daniel Green (via RT) <
> perl6-bugs-follo...@perl.org> wrote:
> >
> > # New Ticket Created by  Daniel Green
> > # Please include the string:  [perl #127881]
> > # in the subject line of all future correspondence about this issue.
> > # https://rt.perl.org/Ticket/Display.html?id=127881 >
> >
> >
> > '@array[0, 3, 7]' is much slower than '(@array[0], @array[3], @array[7])'
> >
> >
> > time perl6 -e 'my @a = ^500;my @f;my $s = @a.elems;loop (my $i1 = 0; $i1
> <
> > $s-1; $i1++) { loop (my $i2 = $i1+1; $i2 < $s; $i2++) { @f.push(@a[$i1,
> > $i2]) } };'
> >
> > real0m14.974s
> > user0m14.947s
> > sys 0m0.017s
> >
> >
> > time perl6 -e 'my @a = ^500;my @f;my $s = @a.elems;loop (my $i1 = 0; $i1
> <
> > $s-1; $i1++) { loop (my $i2 = $i1+1; $i2 < $s; $i2++) { @f.push((@a[$i1],
> > @a[$i2])) } };'
> >
> > real0m0.897s
> > user0m0.877s
> > sys 0m0.017s
> >
> >
> > With Rakudo version 2016.03 built on MoarVM version 2016.03
>
> This is a known issue.  Anytime you use lists, the optimization paths are
> not that well developed yet.  To give you another example:
>
> $ 6 'for ^10 { my ($a,$b) = 42,666 }'
> real0m1.628s
> user0m1.582s
> sys 0m0.041s
>
> $ 6 'for ^10 { my $a = 42; my $b = 666 }'
> real0m0.180s
> user0m0.152s
> sys 0m0.026s
>
> $ 6 'for ^10 { my $a; my $b }'
> real0m0.170s
> user0m0.144s
> sys 0m0.025s
>
> $ 6 'say (1628 - 170) / (180 - 170)’
> 145.8
>
>
> Liz
>
>