[perl #132273] [SEGV] while running t/spec/S17-supply/supplier-preserving.t

2017-10-11 Thread via RT
# New Ticket Created by Zoffix Znet # Please include the string: [perl #132273] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=132273 > Running it in a loop produces a SEGV once in a while: while t/fudgeandrun t/spec/S17-

[perl #124785] [IO] S32-io/dir.t line:16 reason: 'entries are still IO::Path'

2017-10-11 Thread Zoffix Znet via RT
Rejected in https://github.com/perl6/roast/commit/73cb9e7ace

[perl #124786] [IO] S32-io/dir.t line:18 reason: 'dirname is not yet absolute'

2017-10-11 Thread Zoffix Znet via RT
Rejected in https://github.com/perl6/roast/commit/66fb7a1a3b

[perl #128520] [META][RT][RFC] Consider migrating from RT

2017-10-11 Thread Aleks-Daniel Jakimenko-Aleksejev via RT
Oh, and if rakudo/issues is opened, then for me all issues raised in this ticket will be resolved. On 2017-10-11 13:21:41, alex.jakime...@gmail.com wrote: > There was some fresh discussion on this topic recently. See > https://irclog.perlgeek.de/perl6-dev/2017-10-11#i_15289848 and the > start of t

[perl #128520] [META][RT][RFC] Consider migrating from RT

2017-10-11 Thread Aleks-Daniel Jakimenko-Aleksejev via RT
There was some fresh discussion on this topic recently. See https://irclog.perlgeek.de/perl6-dev/2017-10-11#i_15289848 and the start of the discussion on https://irclog.perlgeek.de/perl6-dev/2017-10-11#i_15289680 The idea is that instead of doing a full migration we can just start using another tr

[perl #132269] [BUG] JIT removing loop construct and confusing last()

2017-10-11 Thread via RT
# New Ticket Created by ugexe # Please include the string: [perl #132269] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=132269 > Discovered by failing tests in Net::HTTP xt/* on rakudo/nqp/moar master, the following output s

[perl #132268] Floating point anomalies

2017-10-11 Thread Sisyphus
# New Ticket Created by "Sisyphus" # Please include the string: [perl #132268] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=132268 > Hi, Some anomalous rounding behaviour on Ubuntu-16.04 was noted at http://www.perlmonks.or

Re: [perl #127330] [SLOW] 10_000 lines with 「say ‘a’;」 take 16 seconds to run

2017-10-11 Thread zof...@zoffix.com via RT
Quoting Parrot Raiser <1parr...@gmail.com>: > Round trips to the OS, like repeated "says", have been slow relative > to internal processes since the dawn of time. In this case, there are no trips. It's the *parsing* time that's slow. In fact, if you change it to `$ = ‘a’;` it's equally slow.

[perl #131924] [REGRESSION] \n\r and string concatenation improvements

2017-10-11 Thread Zoffix Znet via RT
Tests in https://github.com/perl6/roast/commit/28481cea18

[perl #131924] [REGRESSION] \n\r and string concatenation improvements

2017-10-11 Thread Aleks-Daniel Jakimenko-Aleksejev via RT
OK, so the test for this goes like this: Create a file Simple.pm6 with this content: unit class Simple; sub buggy-str is export { “: {‘’}\n\r” ~ “\n\r” } Then run something like this: use lib ‘sandbox’; # or whatever the path is for your Simple.pm6 use Simple; say buggy-str() eq “: \n\r\n\r” O

[perl #127330] [SLOW] 10_000 lines with 「say ‘a’;」 take 16 seconds to run

2017-10-11 Thread Zoffix Znet via RT
On Wed, 11 Oct 2017 10:29:41 -0700, zof...@zoffix.com wrote: > Looking at this now, with an extra year of knowledge, it makes perfect > sense for this to be unusually slower: each line switches back and > forth from Main language braid, to Quote language braid, and then back > to Main. I was

[perl #127330] [SLOW] 10_000 lines with 「say ‘a’;」 take 16 seconds to run

2017-10-11 Thread Zoffix Znet via RT
On Wed, 11 Oct 2017 10:29:41 -0700, zof...@zoffix.com wrote: > Looking at this now, with an extra year of knowledge, it makes perfect > sense for this to be unusually slower: each line switches back and > forth from Main language braid, to Quote language braid, and then back > to Main. I was

[perl #128000] [NativeCall] Feature Request: Pointer Arithmetic

2017-10-11 Thread David Warring via RT
Thanks Salvador, Now in Rakudo core https://github.com/rakudo/rakudo/commit/3ca6554fdd8ff91da5423e85d4a2b7d309949531 On Tue, 03 Oct 2017 10:41:41 -0700, david.warring wrote: > On Tue, 26 Apr 2016 15:24:57 -0700, sortiz wrote: > > Hi David, > > > > Can you give a try to NativeHelpers::Pointer, pa

Re: [perl #127330] [SLOW] 10_000 lines with 「say ‘a’;」 take 16 seconds to run

2017-10-11 Thread zoffix
Quoting Parrot Raiser <1parr...@gmail.com>: Round trips to the OS, like repeated "says", have been slow relative to internal processes since the dawn of time. In this case, there are no trips. It's the *parsing* time that's slow. In fact, if you change it to `$ = ‘a’;` it's equally slow.

Re: [perl #127330] [SLOW] 10_000 lines with 「say ‘a’;」 take 16 seconds to run

2017-10-11 Thread Aleks-Daniel Jakimenko-Aleksejev
Your comment makes no sense because almost all of that time is spent on the compilation. Have you tried --stagestats like suggested above? On Wed, Oct 11, 2017 at 7:43 PM, Parrot Raiser <1parr...@gmail.com> wrote: > Round trips to the OS, like repeated "says", have been slow relative > to interna

Re: [perl #127330] [SLOW] 10_000 lines with 「say ‘a’;」 take 16 seconds to run

2017-10-11 Thread Parrot Raiser
Round trips to the OS, like repeated "says", have been slow relative to internal processes since the dawn of time.

[perl #132268] Floating point anomalies

2017-10-11 Thread Zoffix Znet via RT
On Wed, 11 Oct 2017 04:25:32 -0700, sisyphus wrote: > > Is it the intention of the perl6 developers that such discrepancies will be > addressed ? Eventually, yes. A bit lower on the priorities list at the moment, though. What you describe looks to be similar to the other issue I have in my priv

[perl #132268] Floating point anomalies

2017-10-11 Thread Zoffix Znet via RT
On Wed, 11 Oct 2017 04:25:32 -0700, sisyphus wrote: > > Is it the intention of the perl6 developers that such discrepancies will be > addressed ? Eventually, yes. A bit lower on the priorities list at the moment, though. What you describe looks to be similar to the other issue I have in my priv