Re: [perl #127020] [PERF] pod parsing memory is never freed

2017-11-27 Thread Lloyd Fournier
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 cha

Re: [perl #127020] [PERF] pod parsing memory is never freed

2017-11-27 Thread Lloyd Fournier via RT
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 cha

[perl #128090] [RFC] Easy Way to Export Only Specific Symbols At Compile Time

2017-11-27 Thread Zoffix Znet via RT
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

[perl #128090] [RFC] Easy Way to Export Only Specific Symbols At Compile Time

2017-11-27 Thread Zoffix Znet via RT
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

[perl #132510] "problem while trying to set up Linenoise"

2017-11-27 Thread brian d foy
# 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

[perl #132511] Binary assignment Z+= fails if it's the last thing in for loop

2017-11-27 Thread brian d foy
# 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://stackover

Re: [perl #132511] Binary assignment Z+= fails if it's the last thing in for loop

2017-11-27 Thread Timo Paulssen
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

2017-11-27 Thread Timo Paulssen via RT
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

2017-11-27 Thread via RT
# 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 I

[perl #132512] [REGRESSION] make in regex on uncomposed type results in Nil

2017-11-27 Thread Aleks-Daniel Jakimenko-Aleksejev via RT
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 inves

Re: [perl #132512] [REGRESSION] make in regex on uncomposed type results in Nil

2017-11-27 Thread Lloyd Fournier
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

Re: [perl #132512] [REGRESSION] make in regex on uncomposed type results in Nil

2017-11-27 Thread Lloyd Fournier via RT
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

[perl #132512] [REGRESSION] make in regex on uncomposed type results in Nil

2017-11-27 Thread Aleks-Daniel Jakimenko-Aleksejev via RT
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-

Re: [perl #132512] [REGRESSION] make in regex on uncomposed type results in Nil

2017-11-27 Thread Lloyd Fournier via RT
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

Re: [perl #132512] [REGRESSION] make in regex on uncomposed type results in Nil

2017-11-27 Thread Lloyd Fournier
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