Re: [perl #127020] [PERF] pod parsing memory is never freed
Probably one of a number of things that would be easy if we made pod another language on the braid :) On Mon, Nov 27, 2017 at 11:59 AM Timo Paulssen via RT < perl6-bugs-follo...@perl.org> wrote: > a look at a profile makes me suspect the problem is having > pod_string_character match a single character at a time, causing rather > large numbers of match objects for comparatively short strings. > > It's probably worthwhile to steal a piece of implementation from > "nibbling", aka parsing strings. a very short glance points do_nibbling out > as interesting. >
Re: [perl #127020] [PERF] pod parsing memory is never freed
Probably one of a number of things that would be easy if we made pod another language on the braid :) On Mon, Nov 27, 2017 at 11:59 AM Timo Paulssen via RT < perl6-bugs-follo...@perl.org> wrote: > a look at a profile makes me suspect the problem is having > pod_string_character match a single character at a time, causing rather > large numbers of match objects for comparatively short strings. > > It's probably worthwhile to steal a piece of implementation from > "nibbling", aka parsing strings. a very short glance points do_nibbling out > as interesting. >
[perl #128090] [RFC] Easy Way to Export Only Specific Symbols At Compile Time
On Thu, 30 Jun 2016 05:12:09 -0700, c...@zoffix.com wrote: > There was a comment on IRC from someone who doesn't have an account > (http://irclog.perlgeek.de/perl6/2016-06-30#i_12762654 ): > > use Module :ONLY; > > I do like :ONLY more than my original :SYM Just got bitten by this in real-life code: https://github.com/zostay/p6-DOM-Tiny/issues/5 A module was overly lavish with its exports, exporting symbol `Text` (something I've no use for), which conflicted with `Text` namespace from another module I was trying to load. Not having a way to prevent those exports, I had to wrap the module into another module of my own making.
[perl #128090] [RFC] Easy Way to Export Only Specific Symbols At Compile Time
On Thu, 30 Jun 2016 05:12:09 -0700, c...@zoffix.com wrote: > There was a comment on IRC from someone who doesn't have an account > (http://irclog.perlgeek.de/perl6/2016-06-30#i_12762654 ): > > use Module :ONLY; > > I do like :ONLY more than my original :SYM Just got bitten by this in real-life code: https://github.com/zostay/p6-DOM-Tiny/issues/5 A module was overly lavish with its exports, exporting symbol `Text` (something I've no use for), which conflicted with `Text` namespace from another module I was trying to load. Not having a way to prevent those exports, I had to wrap the module into another module of my own making.
[perl #132510] "problem while trying to set up Linenoise"
# New Ticket Created by "brian d foy" # Please include the string: [perl #132510] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=132510 > I did a fresh install of 2017.10 on macOS High Sierra. Immediately started the REPL and got this message: --- I ran into a problem while trying to set up Linenoise: '/Applications/Rakudo/share/perl6/site/short/0008C6C3077BB1943C736587EB1404E59CD84E70' is a directory, cannot do '.open' on a directory Continuing without tab completions or line editor You may want to consider using rlwrap for simple line editor functionality To exit type 'exit' or '^D' > $*VM moar (2017.10)
[perl #132511] Binary assignment Z+= fails if it's the last thing in for loop
# New Ticket Created by "brian d foy"
# Please include the string: [perl #132511]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=132511 >
I previously asked about this unexpected Z behavior on Stackoverflow
( https://stackoverflow.com/q/45001820/2766176 ).
I expected this to change several hash keys at once. It changes no keys:
my $hash = %(
wallet => 100,
gave => 0,
received => 0,
);
for ^1 { $hash Z+= <-1 1> }
dd $hash;
I get:
Hash $hash = ${:gave(0), :received(0), :wallet(100)}
If I change that to add another statement it works:
for ^1 { $hash Z+= <-1 1>; True }
It also works if I take out the binary assignment:
for ^1 { $hash = $hash Z+ <-1 1> }
Re: [perl #132511] Binary assignment Z+= fails if it's the last thing in for loop
Curious sidenote: when you use [Z+]= it will complain about "useless use of [Z+]= in sink context" and the modifications actually go through. With Z[+=] - which is probably the default parsing of this - it will not complain about useless use, but it also won't Do The Thing.
Re: [perl #132511] Binary assignment Z+= fails if it's the last thing in for loop
Curious sidenote: when you use [Z+]= it will complain about "useless use of [Z+]= in sink context" and the modifications actually go through. With Z[+=] - which is probably the default parsing of this - it will not complain about useless use, but it also won't Do The Thing.
[perl #132512] [REGRESSION] make in regex on uncomposed type results in Nil
# New Ticket Created by Lloyd Fournier
# Please include the string: [perl #132512]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=132512 >
Just got around to investigating: https://rt.perl.org/Ticket/Dis
play.html?id=132085
It turns out to be a regression.
my $new_type := Metamodel::ClassHOW.new_type(:name);
my $r = / . { make $new_type } /;
my $m = "a" ~~ $r;
note $m.ast; #-> Nil
making an uncomposed type somehow results in Nil now. It used to work. In
my compiler I can't really get around needing this to work.
LL
[perl #132512] [REGRESSION] make in regex on uncomposed type results in Nil
What do you mean exactly by “used to work”? Here's the output on all 6c
releases: https://gist.github.com/efee7716c35d36c6f793465c2f0b6035
Which behavior is right? Or what's would be the right snippet to reproduce it?
On 2017-11-27 18:48:07, lloyd.fo...@gmail.com wrote:
> Just got around to investigating: https://rt.perl.org/Ticket/Dis
> play.html?id=132085
>
> It turns out to be a regression.
>
> my $new_type := Metamodel::ClassHOW.new_type(:name);
> my $r = / . { make $new_type } /;
> my $m = "a" ~~ $r;
> note $m.ast; #-> Nil
>
> making an uncomposed type somehow results in Nil now. It used to work. In
> my compiler I can't really get around needing this to work.
>
> LL
Re: [perl #132512] [REGRESSION] make in regex on uncomposed type results in Nil
Good point. Here "No such method 'gist' for invocant of type 'Foo'
in block at /tmp/aR11azfzlJ line 1" is the right one.
This will give True/False indicating correct/incorrect:
my $new_type := Metamodel::ClassHOW.new_type(:name);
my $r = / . { $/.make($new_type) } /;
my $m = "a" ~~ $r;
note $m.ast.^name eq "Foo";
Thanks for bisecting magic!
On Tue, Nov 28, 2017 at 1:54 PM Aleks-Daniel Jakimenko-Aleksejev via RT <
perl6-bugs-follo...@perl.org> wrote:
> What do you mean exactly by “used to work”? Here's the output on all 6c
> releases: https://gist.github.com/efee7716c35d36c6f793465c2f0b6035
>
> Which behavior is right? Or what's would be the right snippet to reproduce
> it?
>
> On 2017-11-27 18:48:07, lloyd.fo...@gmail.com wrote:
> > Just got around to investigating: https://rt.perl.org/Ticket/Dis
> > play.html?id=132085
> >
> > It turns out to be a regression.
> >
> > my $new_type := Metamodel::ClassHOW.new_type(:name);
> > my $r = / . { make $new_type } /;
> > my $m = "a" ~~ $r;
> > note $m.ast; #-> Nil
> >
> > making an uncomposed type somehow results in Nil now. It used to work. In
> > my compiler I can't really get around needing this to work.
> >
> > LL
>
>
Re: [perl #132512] [REGRESSION] make in regex on uncomposed type results in Nil
Good point. Here "No such method 'gist' for invocant of type 'Foo'
in block at /tmp/aR11azfzlJ line 1" is the right one.
This will give True/False indicating correct/incorrect:
my $new_type := Metamodel::ClassHOW.new_type(:name);
my $r = / . { $/.make($new_type) } /;
my $m = "a" ~~ $r;
note $m.ast.^name eq "Foo";
Thanks for bisecting magic!
On Tue, Nov 28, 2017 at 1:54 PM Aleks-Daniel Jakimenko-Aleksejev via RT <
perl6-bugs-follo...@perl.org> wrote:
> What do you mean exactly by “used to work”? Here's the output on all 6c
> releases: https://gist.github.com/efee7716c35d36c6f793465c2f0b6035
>
> Which behavior is right? Or what's would be the right snippet to reproduce
> it?
>
> On 2017-11-27 18:48:07, lloyd.fo...@gmail.com wrote:
> > Just got around to investigating: https://rt.perl.org/Ticket/Dis
> > play.html?id=132085
> >
> > It turns out to be a regression.
> >
> > my $new_type := Metamodel::ClassHOW.new_type(:name);
> > my $r = / . { make $new_type } /;
> > my $m = "a" ~~ $r;
> > note $m.ast; #-> Nil
> >
> > making an uncomposed type somehow results in Nil now. It used to work. In
> > my compiler I can't really get around needing this to work.
> >
> > LL
>
>
[perl #132512] [REGRESSION] make in regex on uncomposed type results in Nil
OK, the change from True to False happened here: (2017-08-21)
https://github.com/rakudo/rakudo/commit/5db5b1dbfa0b625130573574e2409972387e9f75
I'm not entirely convinced that the current behavior is incorrect, but then
again I'm sleep deprived. Maybe someone else will have a better idea.
On 2017-11-27 19:00:45, lloyd.fo...@gmail.com wrote:
> Good point. Here "No such method 'gist' for invocant of type 'Foo'
> in block at /tmp/aR11azfzlJ line 1" is the right one.
>
> This will give True/False indicating correct/incorrect:
>
> my $new_type := Metamodel::ClassHOW.new_type(:name);
> my $r = / . { $/.make($new_type) } /;
> my $m = "a" ~~ $r;
> note $m.ast.^name eq "Foo";
>
> Thanks for bisecting magic!
>
> On Tue, Nov 28, 2017 at 1:54 PM Aleks-Daniel Jakimenko-Aleksejev via
> RT <
> perl6-bugs-follo...@perl.org> wrote:
>
> > What do you mean exactly by “used to work”? Here's the output on all
> > 6c
> > releases: https://gist.github.com/efee7716c35d36c6f793465c2f0b6035
> >
> > Which behavior is right? Or what's would be the right snippet to
> > reproduce
> > it?
> >
> > On 2017-11-27 18:48:07, lloyd.fo...@gmail.com wrote:
> > > Just got around to investigating: https://rt.perl.org/Ticket/Dis
> > > play.html?id=132085
> > >
> > > It turns out to be a regression.
> > >
> > > my $new_type := Metamodel::ClassHOW.new_type(:name);
> > > my $r = / . { make $new_type } /;
> > > my $m = "a" ~~ $r;
> > > note $m.ast; #-> Nil
> > >
> > > making an uncomposed type somehow results in Nil now. It used to
> > > work. In
> > > my compiler I can't really get around needing this to work.
> > >
> > > LL
> >
> >
Re: [perl #132512] [REGRESSION] make in regex on uncomposed type results in Nil
Changing uncomposed type objects to Nil for the specific case of .ast/.made
is definitely incorrect IMO.
It happens for the exact reason lizmat said in her commit: "Wish there was
a better way to test for NQPMu
though, as this will prevent type objects being properly propagated"
Although it looks like this has been fixed for composed type objects in a
following patch. It now looks like:
method ast() { nqp::if(nqp::istype($!made, Mu),$!made,Nil) }
But since uncomposed type objects don't inherit from Mu we have the bug.
On Tue, Nov 28, 2017 at 3:26 PM Aleks-Daniel Jakimenko-Aleksejev via RT <
perl6-bugs-follo...@perl.org> wrote:
> OK, the change from True to False happened here: (2017-08-21)
>
> https://github.com/rakudo/rakudo/commit/5db5b1dbfa0b625130573574e2409972387e9f75
>
> I'm not entirely convinced that the current behavior is incorrect, but then
> again I'm sleep deprived. Maybe someone else will have a better idea.
>
> On 2017-11-27 19:00:45, lloyd.fo...@gmail.com wrote:
> > Good point. Here "No such method 'gist' for invocant of type 'Foo'
> > in block at /tmp/aR11azfzlJ line 1" is the right one.
> >
> > This will give True/False indicating correct/incorrect:
> >
> > my $new_type := Metamodel::ClassHOW.new_type(:name);
> > my $r = / . { $/.make($new_type) } /;
> > my $m = "a" ~~ $r;
> > note $m.ast.^name eq "Foo";
> >
> > Thanks for bisecting magic!
> >
> > On Tue, Nov 28, 2017 at 1:54 PM Aleks-Daniel Jakimenko-Aleksejev via
> > RT <
> > perl6-bugs-follo...@perl.org> wrote:
> >
> > > What do you mean exactly by “used to work”? Here's the output on all
> > > 6c
> > > releases: https://gist.github.com/efee7716c35d36c6f793465c2f0b6035
> > >
> > > Which behavior is right? Or what's would be the right snippet to
> > > reproduce
> > > it?
> > >
> > > On 2017-11-27 18:48:07, lloyd.fo...@gmail.com wrote:
> > > > Just got around to investigating: https://rt.perl.org/Ticket/Dis
> > > > play.html?id=132085
> > > >
> > > > It turns out to be a regression.
> > > >
> > > > my $new_type := Metamodel::ClassHOW.new_type(:name);
> > > > my $r = / . { make $new_type } /;
> > > > my $m = "a" ~~ $r;
> > > > note $m.ast; #-> Nil
> > > >
> > > > making an uncomposed type somehow results in Nil now. It used to
> > > > work. In
> > > > my compiler I can't really get around needing this to work.
> > > >
> > > > LL
> > >
> > >
>
>
Re: [perl #132512] [REGRESSION] make in regex on uncomposed type results in Nil
Changing uncomposed type objects to Nil for the specific case of .ast/.made
is definitely incorrect IMO.
It happens for the exact reason lizmat said in her commit: "Wish there was
a better way to test for NQPMu
though, as this will prevent type objects being properly propagated"
Although it looks like this has been fixed for composed type objects in a
following patch. It now looks like:
method ast() { nqp::if(nqp::istype($!made, Mu),$!made,Nil) }
But since uncomposed type objects don't inherit from Mu we have the bug.
On Tue, Nov 28, 2017 at 3:26 PM Aleks-Daniel Jakimenko-Aleksejev via RT <
perl6-bugs-follo...@perl.org> wrote:
> OK, the change from True to False happened here: (2017-08-21)
>
> https://github.com/rakudo/rakudo/commit/5db5b1dbfa0b625130573574e2409972387e9f75
>
> I'm not entirely convinced that the current behavior is incorrect, but then
> again I'm sleep deprived. Maybe someone else will have a better idea.
>
> On 2017-11-27 19:00:45, lloyd.fo...@gmail.com wrote:
> > Good point. Here "No such method 'gist' for invocant of type 'Foo'
> > in block at /tmp/aR11azfzlJ line 1" is the right one.
> >
> > This will give True/False indicating correct/incorrect:
> >
> > my $new_type := Metamodel::ClassHOW.new_type(:name);
> > my $r = / . { $/.make($new_type) } /;
> > my $m = "a" ~~ $r;
> > note $m.ast.^name eq "Foo";
> >
> > Thanks for bisecting magic!
> >
> > On Tue, Nov 28, 2017 at 1:54 PM Aleks-Daniel Jakimenko-Aleksejev via
> > RT <
> > perl6-bugs-follo...@perl.org> wrote:
> >
> > > What do you mean exactly by “used to work”? Here's the output on all
> > > 6c
> > > releases: https://gist.github.com/efee7716c35d36c6f793465c2f0b6035
> > >
> > > Which behavior is right? Or what's would be the right snippet to
> > > reproduce
> > > it?
> > >
> > > On 2017-11-27 18:48:07, lloyd.fo...@gmail.com wrote:
> > > > Just got around to investigating: https://rt.perl.org/Ticket/Dis
> > > > play.html?id=132085
> > > >
> > > > It turns out to be a regression.
> > > >
> > > > my $new_type := Metamodel::ClassHOW.new_type(:name);
> > > > my $r = / . { make $new_type } /;
> > > > my $m = "a" ~~ $r;
> > > > note $m.ast; #-> Nil
> > > >
> > > > making an uncomposed type somehow results in Nil now. It used to
> > > > work. In
> > > > my compiler I can't really get around needing this to work.
> > > >
> > > > LL
> > >
> > >
>
>
