[perl #132111] Make it possible to change the buffer size on a handle (.set-buffer?)

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Once this is implemented, replace nqp::setbuffersizefh with it in Test.pm6.

On 2017-09-17 08:38:34, alex.jakime...@gmail.com wrote:
> Using nqp, one can do something like:
>
> nqp::setbuffersizefh(nqp::getstdout(), 0);
>
> But it would be nice if it was available from Perl 6 level.
>
>
> See also: https://github.com/rakudo/rakudo/pull/1160

[perl #132030] [TESTNEEDED] [REGRESSION] Broken Text::CSV tests and possibly other ecosystem fallout (buffering)

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Two of the mentioned modules have pending pull requests that add missing .close
calls in tests. NCurses module is trickier, but arguably the failing test is a
little bit wrong. See this discussion for more info:
https://github.com/azawawi/perl6-ncurses/issues/16

In other words, the ecosystem is fine. I'm still seeing some weirdness when
running ｢prove｣, but hopefully that is unrelated.
On 2017-09-13 23:06:58, alex.jakime...@gmail.com wrote:
> CSS::Specification and CSS::Module:
> https://github.com/p6-css/CSS-Specification-p6/issues/2
>
> That's basically it. We won't see any other affected modules from
> toaster data.
> On 2017-09-13 18:54:42, alex.jakime...@gmail.com wrote:
> > NCurses, Term::Choose, Term::Choose::Util, and Term::TablePrint:
> > https://github.com/azawawi/perl6-ncurses/issues/16
> >
> > This one is weird because it seems to be working unless you run it
> > under prove.
> > Perhaps the module is alright but it's the test that is broken.
> >
> > On 2017-09-13 18:16:56, alex.jakime...@gmail.com wrote:
> > > FWIW there is still some ecosystem fallout (possibly very minor).
> > > I'll be
> > > linking issues here so that we have all things in one place.
> > >
> > > IO::MiddleMan and Lumberjack:
> > > https://github.com/zoffixznet/perl6-IO-MiddleMan/issues/5
> > > On 2017-09-11 04:18:39, elizabeth wrote:
> > > > Fixed with 3c9cfdba88287e23e0ced8 (and further refined by later
> > > > commits), tests needed.
> > > >
> > > > > On 6 Sep 2017, at 15:38, jn...@jnthn.net via RT  > > > > follo...@perl.org> wrote:
> > > > >
> > > > > On Tue, 05 Sep 2017 09:11:19 -0700, allber...@gmail.com wrote:
> > > > >> On Tue, Sep 5, 2017 at 5:40 AM, jn...@jnthn.net via RT <
> > > > >> perl6-bugs-follo...@perl.org> wrote:
> > > > >>
> > > > >>> Failing to close output handles has been clearly documented
> > > > >>> (and
> > > > >>> yes,
> > > > >>> documented well before the recent buffering change) as
> > > > >>> something
> > > > >>> that can
> > > > >>> cause data loss. Default output buffering just makes it quite
> > > > >>> a
> > > > >>> lot
> > > > >>> more
> > > > >>> likely to show up.
> > > > >>>
> > > > >>> While there will be some ecosystem fallout like this,
> > > > >>> unfortunately
> > > > >>> I
> > > > >>> don't think it's avoidable. If we whip out the patch that
> > > > >>> turns
> > > > >>> output
> > > > >>> buffering on by default for non-TTYs for this release, then
> > > > >>> when
> > > > >>> will we
> > > > >>> include it? The longer we leave it, the more painful it will
> > > > >>> be,
> > > > >>> because
> > > > >>> more code will be written that is careless with handles.
> > > > >>>
> > > > >>> I don't think "leave it off by default" is a good option
> > > > >>> either,
> > > > >>> otherwise
> > > > >>> we get to spend the next decade hearing "Perl 6 I/O is slow"
> > > > >>> because it'd
> > > > >>> be one of the only languages that doesn't buffer its output
> > > > >>> without
> > > > >>> an
> > > > >>> explicit flag being passed to enable that (which nearly
> > > > >>> nobody
> > > > >>> doing quick
> > > > >>> benchmarks will know to use).
> > > > >>>
> > > > >>
> > > > >> Are we missing something to flush/close handles at exit?
> > > > >> Leaving
> > > > >> it
> > > > >> to a GC
> > > > >> that may not finalize before exit is not really an option.
> > > > >>
> > > > > To recap the IRC discussion yesterday: no, we haven't had this
> > > > > so
> > > > > far
> > > > > (except for stdout/stderr), and have gotten away with it due to
> > > > > the
> > > > > lack of output buffering. At present, we can either choose
> > > > > between:
> > > > >
> > > > > 1) Start keeping a list of open files, and at exit close them
> > > > > (flushing is already part of closing). This can be done at Perl
> > > > > 6
> > > > > level, in the same place we make sure to run END blocks.
> > > > >
> > > > > 2) Having unclosed handles possible to GC, and closing them
> > > > > if/when
> > > > > they get GC'd.
> > > > >
> > > > > Today we are doing #2. We could switch to doing #1. We can't
> > > > > currently do both, because the moment we start keeping a list
> > > > > of
> > > > > open
> > > > > handles then they can't be GC'd, and so #2 can't happen.
> > > > >
> > > > > My initial inclination was to preserve behavior #2, though
> > > > > others
> > > > > have pointed out that behavior #1 is more useful for debugging
> > > > > in
> > > > > that it ensures log files, for example, will be written in the
> > > > > event
> > > > > of a crash, and a program relying on behavior #2 could already
> > > > > run
> > > > > out of handles today anyway if it were less lucky with GC
> > > > > timing.
> > > > > This is a fair argument, and the automatic close at exit might
> > > > > be
> > > > > softer on the ecosystem too (but would have done nothing for
> > > > > the
> > > > > Text::CSV case, which is the original subject of this ticket,
> > > > > because
> > > > > it wrote a file, didn't close it, then separately opened it 

[perl #132083] [REGRESSION] Broken math (-2147483648 != -2147483648)

[Aleks-Daniel Jakimenko-Aleksejev via RT]

The issue seems to be resolved in
https://github.com/MoarVM/MoarVM/commit/9c5fed708f35edb28f1adf91e9c141372882815f

Tests needed.

When adding tests for this, please cover this case also:
say (-0x7FFF - 1).base(16) # should probably be -8000 but it
erroneously gives -8000

On 2017-09-16 10:46:51, alex.jakime...@gmail.com wrote:
> This is definitely an issue in MoarVM, and it existed since 2014.02
> but for
> some reason it was unnoticeable before recent changes.
>
> Code:
> my $value = -0x7FFF - 1;
> say $value;
> say -2147483648;
> say $value == -2147483648;
>
> Result (MoarVM):
> -2147483648
> -2147483648
> False
>
> Result (JVM):
> -2147483648
> -2147483648
> True
>
>
>
> Maybe this can help:
> Code:
> my $value = -0x7FFF - 1;
> say $value;
> say $value == -18446744071562067968
>
> Result (MoarVM):
> -2147483648
> True
>
> On 2017-09-13 19:49:24, alex.jakime...@gmail.com wrote:
> > Two tests in Data::MessagePack started to fail:
> >
> > Test Summary Report
> > ---
> > t/202-unpack-int.t (Wstat: 256 Tests: 40 Failed: 1)
> > Failed test: 35
> > Non-zero exit status: 1
> > t/302-stream-unpack-int.t (Wstat: 256 Tests: 23 Failed: 1)
> > Failed test: 21
> > Non-zero exit status: 1
> >
> > MessagePack::Class depends on Data::MessagePack and therefore is not
> > installable also.
> >
> > Committable output for 202-unpack-int.t on 2017.08 and HEAD:
> > https://gist.github.com/50eab41e808e812c7d555f45272dc2a5
> >
> > Bisectable points at
> >
>
https://github.com/rakudo/rakudo/commit/9b42484a5d0ca6b5d340620cc5d8dd88e2eb331f
> >
> > Module repo: https://github.com/pierre-vigier/Perl6-Data-MessagePack
> >
> >
> > It could very well be that it is not a regression, but that the
> > module
> > was relying on buggy behavior. I think having a ticket is reasonable
> > until we get a better answer. Any info is welcome.

[perl #132083] [REGRESSION] Possible regression with native ints

[Aleks-Daniel Jakimenko-Aleksejev via RT]

This is definitely an issue in MoarVM, and it existed since 2014.02 but for
some reason it was unnoticeable before recent changes.

Code:
my $value = -0x7FFF - 1;
say $value;
say -2147483648;
say $value == -2147483648;

Result (MoarVM):
-2147483648
-2147483648
False

Result (JVM):
-2147483648
-2147483648
True



Maybe this can help:
Code:
my $value = -0x7FFF - 1;
say $value;
say $value == -18446744071562067968

Result (MoarVM):
-2147483648
True

On 2017-09-13 19:49:24, alex.jakime...@gmail.com wrote:
> Two tests in Data::MessagePack started to fail:
>
> Test Summary Report
> ---
> t/202-unpack-int.t (Wstat: 256 Tests: 40 Failed: 1)
> Failed test: 35
> Non-zero exit status: 1
> t/302-stream-unpack-int.t (Wstat: 256 Tests: 23 Failed: 1)
> Failed test: 21
> Non-zero exit status: 1
>
> MessagePack::Class depends on Data::MessagePack and therefore is not
> installable also.
>
> Committable output for 202-unpack-int.t on 2017.08 and HEAD:
> https://gist.github.com/50eab41e808e812c7d555f45272dc2a5
>
> Bisectable points at
>
https://github.com/rakudo/rakudo/commit/9b42484a5d0ca6b5d340620cc5d8dd88e2eb331f
>
> Module repo: https://github.com/pierre-vigier/Perl6-Data-MessagePack
>
>
> It could very well be that it is not a regression, but that the module
> was relying on buggy behavior. I think having a ticket is reasonable
> until we get a better answer. Any info is welcome.

[perl #132073] [BUG] isa method errors when called on a subset type object

[Aleks-Daniel Jakimenko-Aleksejev via RT]

What about this commit?
https://github.com/rakudo/rakudo/commit/0704cd97226e6300194342c88cef1c5fe711

On 2017-09-12 13:55:51, david.warring wrote:
> current behavior of isa method on a subset:
>
> % perl6 -v
> This is Rakudo version 2017.08-110-g5f3350656 built on MoarVM version
> 2017.08.1-156-g4
> 9b90b99
> implementing Perl 6.c.
> % perl6 -e'subset S of Int; say S.isa(Int)'
> Cannot resolve caller isa(Perl6::Metamodel::SubsetHOW: S, Int); none of
> these signatur
> es match:
> (Mu \SELF: Mu $type, *%_)
> (Mu \SELF: Str:D $name, *%_)
> in block  at -e line 1
>
> The documentation https://docs.perl6.org/routine/isa implies this should
> return True.

[perl #132093] Enum.succ and Enum.pred are O(n)

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Well, the title says “Enum.succ and Enum.pred are O(n)” and the issue is still
there, so this ticket is definitely not resolved. If anything, it was rejected.

However, the reasoning for keeping O(n) kinda contradicts itself. If we're
trading RAM for performance, and the amount of elements in enums is small, it
shouldn't really matter which way we go. However, as mentioned on the PR
already, .succ-ing repeatedly gives us O(n²), and it's a good idea to avoid
that.

Looking at https://github.com/rakudo/rakudo/commit/55aa7f28d3 , I'm kinda
appreciating the point about premature optimization. However, 8.4x speedup does
not resolve the issue with algorithmic complexity of O(n²) in user code.

As for how huge an enum can be, here are some examples from the ecosystem
(these are just the ones that jumped at me, there are probably more):
*
https://github.com/azawawi/perl6-net-curl/blob/6058c370112a2477b71608ee273231cde1d8f4ae/lib/Net/Curl/NativeCall.pm6#L250-L457
*
https://github.com/perl6/DBIish/blob/2059b722fd2efea25513eb7250ddfe4d1b42ec41/lib/DBDish/Pg/Native.pm6#L152-L308
*
https://github.com/andydude/p6-c-parser/blob/d1deface417808b66b6d57c04e35a801d537dbae/lib/C/AST/Ops.pm6#L4-L90
*
https://github.com/CurtTilmes/perl6-libcurl/blob/95f975fd4ac69c4a561de86dd03e03958e9983c9/lib/LibCurl/EasyHandle.pm6#L98-L189

Sure, not in thousands, but very fucking close.


On 2017-09-15 08:04:30, c...@zoffix.com wrote:
> On Thu, 14 Sep 2017 18:03:16 -0700, alex.jakime...@gmail.com wrote:
> > Actually, another direct implication of using .first is this:
> >
> > Code:
> > enum Animal (Cat => 0, Dog => 0, Human => 42);
> > say Dog.succ
> >
> > Result:
> > Dog
> >
> >
> > So it's not just the algorithmic complexity, and we need a test for
> > that.
> >
> > On 2017-09-14 17:47:59, alex.jakime...@gmail.com wrote:
> > > Source code:
> > > https://github.com/rakudo/rakudo/blob/nom/src/core/Enumeration.pm#L36-
> > > L45
> > >
> > > The problem is with this line:
> > > my $index = @values.first( self, :k );
> > >
> > > Basically, .first will iterate through the elements, but I guess it
> > > is
> > > possible to store the index of the current enum value and simply
> > > increment/decrement it when needed.
> > >
> > > Some discussion here:
> > > https://github.com/rakudo/rakudo/pull/1156#issuecomment-329640201
> > >
> > > I think this ticket is closable without tests once the change is
> > > implemented.
>
>
> The wrong Enumeration:D being returned is now fixed[^1][^2] and
> tested[^3].
>
> For the performance issue: I made[^4] .pred 8.4x faster and .succ 6x
> faster, while keeping the same O(). I hope that's sufficient
> compromise to close this ticket, given that the huge majority of
> Enumerations would have just a few elements, not thousands.
>
> [1] https://github.com/rakudo/rakudo/commit/69dae1f3be
> [2] https://github.com/rakudo/rakudo/commit/8d938461a9
> [3] https://github.com/perl6/roast/commit/dfbbd70d46
> [4] https://github.com/rakudo/rakudo/commit/55aa7f28d3

[perl #132088] [REGRESSION][NATIVECALL] code broken by latest build

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Bisected to
https://github.com/rakudo/rakudo/commit/cd7dc4ce934003b9da1e540e638ee6dbe1f44b1b

Committable output
https://gist.github.com/Whateverable/ee36fb271f2700f1684e1290a966e709

On 2017-09-14 08:16:43, ash.gabr...@gmail.com wrote:
> Hello,
>
> I've written a module with release 2017-07.
>
> source here: https://github.com/gabrielash/perl6-zmq
>
> It fails travis ci test with 'latest' release, but passes with '2017-07'.
>
> This is the error
>
> ./t/11.t . Too few positionals passed; expected 5 arguments but got 3
>
> in method send at
> /home/travis/build/gabrielash/perl6-zmq/lib/Net/ZMQ/Message.pm
> (Net::ZMQ::Message) line 244
>
> in block  at ./t/11.t line 55
>
> I am not sure what is wrong and whether it is a bug or my mistake.
>
> I tried to isolate the problem with the following test, but that test,
> in isolation, does work on the latest build.
>
> So there is something in the module interacting badly with this
> nativecall, but only on the latest release.
>
> class zmq_msg_t is repr('CStruct') {
> has int64 $._;
> has int64 $._1;
> has int64 $._2;
> has int64 $._3;
> has int64 $._4;
> has int64 $._5;
> has int64 $._6;
> has int64 $._7;
> }
>
> sub zmq_msg_init_data(zmq_msg_t
> ,Pointer
> ,size_t
> ,Pointer = nativecast( Pointer, 0)
> ,Pointer = nativecast( Pointer, 0)
> ) is native('zmq', v5)
> returns int32 is export { * }
>
> my buf8 $b .= new(0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0);
> my Pointer $p = nativecast(Pointer, $b);
> my zmq_msg_t $m .= new ;
>
> lives-ok {zmq_msg_init_data($m, $p , 10 )}, "native call ok ";
>
> Hoping you can help.
>
> Gabriel Ash
>
>
>

[perl #132093] Enum.succ and Enum.pred are O(n)

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Actually, another direct implication of using .first is this:

Code:
enum Animal (Cat => 0, Dog => 0, Human => 42);
say Dog.succ

Result:
Dog


So it's not just the algorithmic complexity, and we need a test for that.

On 2017-09-14 17:47:59, alex.jakime...@gmail.com wrote:
> Source code:
> https://github.com/rakudo/rakudo/blob/nom/src/core/Enumeration.pm#L36-
> L45
>
> The problem is with this line:
> my $index = @values.first( self, :k );
>
> Basically, .first will iterate through the elements, but I guess it is
> possible to store the index of the current enum value and simply
> increment/decrement it when needed.
>
> Some discussion here:
> https://github.com/rakudo/rakudo/pull/1156#issuecomment-329640201
>
> I think this ticket is closable without tests once the change is
> implemented.

[perl #132085] [REGRESSION] Possible regression after Match.(made|ast) changes

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Thanks!

On 2017-09-13 21:02:09, lloyd.fo...@gmail.com wrote:
> I think we can close this. It's most likely an internals change
> because I
> call nqp::setparameterizer() directly. I'll figure out what the
> problem is
> eventually and if I can't fix it myself I'll open a more concise RT.
>
> Cheers
>
> LL
>
> On Thu, Sep 14, 2017 at 1:27 PM Aleks-Daniel Jakimenko-Aleksejev <
> perl6-bugs-follo...@perl.org> wrote:
>
> > # New Ticket Created by Aleks-Daniel Jakimenko-Aleksejev
> > # Please include the string: [perl #132085]
> > # in the subject line of all future correspondence about this issue.
> > # https://rt.perl.org/Ticket/Display.html?id=132085 >
> >
> >
> > Spit tests are failing on HEAD (https://github.com/spitsh/spitsh).
> >
> > Example output from committable:
> > https://gist.github.com/9f5f6ab318e16a29057748876d8af883
> >
> > Bisectable points at
> >
https://github.com/rakudo/rakudo/commit/5db5b1dbfa0b625130573574e2409972387e9f75
> >
> > I don't know if it is truly a regression or if the module was relying
> > on
> > some buggy behavior. Any info is appreciated.
> >

[perl #132030] [TESTNEEDED] [REGRESSION] Broken Text::CSV tests and possibly other ecosystem fallout

[Aleks-Daniel Jakimenko-Aleksejev via RT]

NCurses, Term::Choose, Term::Choose::Util, and Term::TablePrint:
https://github.com/azawawi/perl6-ncurses/issues/16

This one is weird because it seems to be working unless you run it under prove.
Perhaps the module is alright but it's the test that is broken.

On 2017-09-13 18:16:56, alex.jakime...@gmail.com wrote:
> FWIW there is still some ecosystem fallout (possibly very minor). I'll be
> linking issues here so that we have all things in one place.
>
> IO::MiddleMan and Lumberjack:
> https://github.com/zoffixznet/perl6-IO-MiddleMan/issues/5
> On 2017-09-11 04:18:39, elizabeth wrote:
> > Fixed with 3c9cfdba88287e23e0ced8 (and further refined by later
> > commits), tests needed.
> >
> > > On 6 Sep 2017, at 15:38, jn...@jnthn.net via RT  > > follo...@perl.org> wrote:
> > >
> > > On Tue, 05 Sep 2017 09:11:19 -0700, allber...@gmail.com wrote:
> > >> On Tue, Sep 5, 2017 at 5:40 AM, jn...@jnthn.net via RT <
> > >> perl6-bugs-follo...@perl.org> wrote:
> > >>
> > >>> Failing to close output handles has been clearly documented (and
> > >>> yes,
> > >>> documented well before the recent buffering change) as something
> > >>> that can
> > >>> cause data loss. Default output buffering just makes it quite a lot
> > >>> more
> > >>> likely to show up.
> > >>>
> > >>> While there will be some ecosystem fallout like this, unfortunately
> > >>> I
> > >>> don't think it's avoidable. If we whip out the patch that turns
> > >>> output
> > >>> buffering on by default for non-TTYs for this release, then when
> > >>> will we
> > >>> include it? The longer we leave it, the more painful it will be,
> > >>> because
> > >>> more code will be written that is careless with handles.
> > >>>
> > >>> I don't think "leave it off by default" is a good option either,
> > >>> otherwise
> > >>> we get to spend the next decade hearing "Perl 6 I/O is slow"
> > >>> because it'd
> > >>> be one of the only languages that doesn't buffer its output without
> > >>> an
> > >>> explicit flag being passed to enable that (which nearly nobody
> > >>> doing quick
> > >>> benchmarks will know to use).
> > >>>
> > >>
> > >> Are we missing something to flush/close handles at exit? Leaving it
> > >> to a GC
> > >> that may not finalize before exit is not really an option.
> > >>
> > > To recap the IRC discussion yesterday: no, we haven't had this so far
> > > (except for stdout/stderr), and have gotten away with it due to the
> > > lack of output buffering. At present, we can either choose between:
> > >
> > > 1) Start keeping a list of open files, and at exit close them
> > > (flushing is already part of closing). This can be done at Perl 6
> > > level, in the same place we make sure to run END blocks.
> > >
> > > 2) Having unclosed handles possible to GC, and closing them if/when
> > > they get GC'd.
> > >
> > > Today we are doing #2. We could switch to doing #1. We can't
> > > currently do both, because the moment we start keeping a list of open
> > > handles then they can't be GC'd, and so #2 can't happen.
> > >
> > > My initial inclination was to preserve behavior #2, though others
> > > have pointed out that behavior #1 is more useful for debugging in
> > > that it ensures log files, for example, will be written in the event
> > > of a crash, and a program relying on behavior #2 could already run
> > > out of handles today anyway if it were less lucky with GC timing.
> > > This is a fair argument, and the automatic close at exit might be
> > > softer on the ecosystem too (but would have done nothing for the
> > > Text::CSV case, which is the original subject of this ticket, because
> > > it wrote a file, didn't close it, then separately opened it for
> > > reading).
> > >
> > > There's probably enough consensus to switch to option #1, and
> > > lizmat++ mentioned maybe looking into a patch to do that.
> > >
> > > In the longer run, we can have both, but it depends on implementing
> > > weak references. In terms of backend support, the JVM does have them,
> > > and it seems there's an npm package [1] exposing v8 weak refs so a
> > > Node.js backend could support that also. I'm OK with adding them to
> > > MoarVM in the future, but both doing that and exposing weak
> > > references at Perl 6 level would be a non-small, and certainly non-
> > > trivial, task.

[perl #132016] [TESTNEEDED] Supply.merge and signals ( signal(SIGTERM).merge(signal(SIGINT)) )

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Sorry, it was marked as “resolved”, but I don't see any mention of tests.

On 2014-09-16 07:51:34, elizabeth wrote:
> 16:48:20]  jnthn: sanity check: we should allow more than
> one signal to be tapped at a time, right ?
> [16:49:10]  lizmat: aye
> [16:49:32]  putting this in a file:
> [16:49:34]  signal(SIGHUP).act: -> { };
> signal(SIGINT).act: -> { }; sleep 5;
> [16:49:50]  running it and pressing CTRL-c gives a very
> strange backtrace
> [16:50:03]  Unhandled exception in code scheduled on
> thread 4527849472
> [16:50:03]  Cannot call 'postcircumfix:<[ ]>'; none of
> these signatures match:
> [16:50:22]  no line numbers, not even with --ll-exception
> [16:51:13]  Odd
> [16:52:06]  rakudobug it?
> [16:54:14]  yeah

[perl #132053] [BUG] Autovivification on element with [] or {} as default causes "secret" keys

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Heh.

FWIW we had this since forever:
https://gist.github.com/Whateverable/78168042a011e01fc768c042b0d91898

On 2017-09-09 19:53:53, tomentiru...@gmail.com wrote:
> > my @h is default([])
> []
> > @h[0].push: 3
> [3]
> > @h
> []
> > @h[0]
> [3]
>
> > my %h is default({})
> {}
> > %h = 3
> 3
> > %h
> {}
> > %h
> {b => 3}
>
> The array/hash variable's default is an empty array/hash literal. If
> an element is autovivified, it can be accessed directly, but isn’t
> findable from the variable.

[perl #132044] returning inside whenever block causes MoarVM panic

[Aleks-Daniel Jakimenko-Aleksejev via RT]

“almost always” indeed. It does work sometimes. Interesting.

On 2017-09-07 13:33:30, nlo...@gmail.com wrote:
> The code below almost always results in "MoarVM panic: Internal error:
> Unwound entire stack and missed handler"
> ```
> sub ran-ok() {
> react {
> my $proc = Proc::Async.new("echo", "1”);
> whenever $proc.start { return 1; }
> }
> }
> ran-ok()
> ```

[perl #132030] [REGRESSION] Broken Text::CSV tests and possibly other ecosystem fallout

[Aleks-Daniel Jakimenko-Aleksejev via RT]

“Will leave this ticket open a little longer for further comments/discussion,
but my intention is to reject it.”

Nope, that's not exactly a good sounding plan.

We'll run toaster and fix all modules that require fixing (or create
appropriate issues if fixing something turns out to be too hard). This is
exactly what I did for Grammar.parse change before the previous release (even
though we reverted it anyway). And this is what I'm planning to do for this
change also.

You are 100% right about the change, but flipping the ecosystem upside down is
not exactly a good strategy even if you're right.

On 2017-09-05 09:11:19, allber...@gmail.com wrote:
> On Tue, Sep 5, 2017 at 5:40 AM, jn...@jnthn.net via RT <
> perl6-bugs-follo...@perl.org> wrote:
>
> > Failing to close output handles has been clearly documented (and yes,
> > documented well before the recent buffering change) as something that can
> > cause data loss. Default output buffering just makes it quite a lot more
> > likely to show up.
> >
> > While there will be some ecosystem fallout like this, unfortunately I
> > don't think it's avoidable. If we whip out the patch that turns output
> > buffering on by default for non-TTYs for this release, then when will we
> > include it? The longer we leave it, the more painful it will be, because
> > more code will be written that is careless with handles.
> >
> > I don't think "leave it off by default" is a good option either, otherwise
> > we get to spend the next decade hearing "Perl 6 I/O is slow" because it'd
> > be one of the only languages that doesn't buffer its output without an
> > explicit flag being passed to enable that (which nearly nobody doing quick
> > benchmarks will know to use).
> >
>
> Are we missing something to flush/close handles at exit? Leaving it to a GC
> that may not finalize before exit is not really an option.
>

[perl #132030] [REGRESSION] Broken Text::CSV tests and possibly other ecosystem fallout

[Aleks-Daniel Jakimenko-Aleksejev via RT]

The issue is likely in Text::CSV so it's not fully a rakudo bug.

However, we probably have a bunch of broken modules in the ecosystem because of
this. I guess we need a Toaster report and a bunch of PRs for missing .close
calls to fix everything…
On 2017-09-05 00:54:27, alex.jakime...@gmail.com wrote:
> <[Tux]> CSV tests started to fail
> <[Tux]> # at t/90_csv.t line 260
> <[Tux]> # expected: $[["1", "2", "3"], ["2", "a b", ""]]
> <[Tux]> # got: $[["1", "2", "3"],]
> <[Tux]> # Failed test 'AOH parse out'
>
>
> Bisectable points to
>
https://github.com/rakudo/rakudo/commit/4b02b8aadcb47072bc87fb8be8069177b74cd59d
>
> bisect log: https://gist.github.com/62a876b09bfecc9aa305061e384f43ce
> double-check with committable:
> https://gist.github.com/50bd16934e6bc93ad49a1659cf31bf06
>
>
> I'm suspecting that Whateverable issues that I'm seeing right now are
> also associated with this.

[perl #132029] Floppage of atomic tests

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Oh. A crude way to reproduce it is:

while :; do clear; PERL6LIB=lib ./perl6-m t/spec/S17-lowlevel/atomic-ops.t ||
break; done

And just leave it running, it'll fail at some point. Get your system busy with
something and it'll fail faster.

On 2017-09-05 00:14:11, alex.jakime...@gmail.com wrote:
> Here's the output when it fails:
>
> ok 1 - Can do an atomic fetch from a Scalar container
> ok 2 - Can do an atomic assign to a Scalar container; returns new
> value
> ok 3 - Atomic fetch after atomic assign shows latest value
> ok 4 - Updated value seen by non-atomic too
> 1..2
> ok 1 - code dies
> ok 2 - right exception type (X::TypeCheck::Assignment)
> ok 5 - Cannot atomic assign value of the wrong type
> ok 6 - No hang due to incorrect lifting of atomic fetch out of loop
> ok 7 - Can do an atomic fetch from an int container
> ok 8 - Can do an atomic assign to an int container; returns new value
> ok 9 - Atomic int fetch after atomic int assign shows latest value
> ok 10 - Updated value seen by non-atomic too
> A IntLexRef container does not know how to do an atomic load
> in block  at t/spec/S17-lowlevel/atomic-ops.t line 41
>
> # Looks like you planned 28 tests, but ran 10
>
>
> I noticed that it fails more often when the system is under load (e.g.
> when running the spectest). Other than that I don't have any info.

[perl #132025] [BUG] do statement is not fully considered to be a loop

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Thanks. Done.

Unfortunately, RT does not save titles of merged tickets, so I think we lost a
little bit of information after the merge. But fear not, these ticket IDs are
referenced in S04-statements/do.t, so once this ticket is resolved please also
unskip the tests.

On 2017-09-03 19:01:48, b...@abrij.org wrote:
>
> Please combine RT#124573, RT#124274, RT#124275, and RT#124276 into
> this ticket.
>
> The tests referenced in those auto-generated tickets all currently
> fail due to
> the fact that "do" statements are not fully considered to be loops by
> rakudo's
> in-loop control statements.
>
> That it should be a loop is in S04/"The do-once loop."
>
> In the case of RT#124274 the initial failure mode has since changed.
> Originally
> it had problems with the label, but since then the failure is now an
> X::ControlFlow
> as in cases without the label.

[perl #132016] Supply.merge and signals ( signal(SIGTERM).merge(signal(SIGINT)) )

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Revert this commit when the ticket is resolved:
https://github.com/perl6/doc/commit/70084290cf881af88546d507fc2ba4448bfa7aaf

(possibly with a note that it only works since rakudo 20XX.XX)

On 2017-09-01 20:15:07, alex.jakime...@gmail.com wrote:
> Command:
> # run it and then send SIGINT (e.g. with Ctrl+C)
> perl6 -e 'react whenever signal(SIGINT).merge(signal(SIGTERM)) { say
> ‘hey!’; exit 0 }'
>
> Result:
> hey!
>
>
> Command:
> # run it and then send SIGINT (e.g. with Ctrl+C)
> perl6 -e 'react whenever signal(SIGTERM).merge(signal(SIGINT)) { say
> ‘hey!’; exit 0 }'
>
> Result:
> Unhandled exception in code scheduled on thread 10
> Cannot resolve caller postcircumfix:<[ ]>(Mu, Int); none of these
> signatures match:
> (\SELF, Any:U $type, |c is raw)
> (\SELF, int $pos)
> (\SELF, int $pos, Mu \assignee)
> (\SELF, int $pos, Mu :$BIND! is raw)
> (\SELF, int $pos, :$delete!, *%other)
> (\SELF, int $pos, :$exists!, *%other)
> (\SELF, int $pos, :$kv!, *%other)
> (\SELF, int $pos, :$p!, *%other)
> (\SELF, int $pos, :$k!, *%other)
> (\SELF, int $pos, :$v!, *%other)
> (\SELF, Int:D $pos)
> (\SELF, Int:D $pos, Mu \assignee)
> (\SELF, Int:D $pos, Mu :$BIND! is raw)
> (\SELF, Int:D $pos, :$delete!, *%other)
> (\SELF, Int:D $pos, :$exists!, *%other)
> (\SELF, Int:D $pos, :$kv!, *%other)
> (\SELF, Int:D $pos, :$p!, *%other)
> (\SELF, Int:D $pos, :$k!, *%other)
> (\SELF, Int:D $pos, :$v!, *%other)
> (\SELF, Any:D \pos)
> (\SELF, Any:D \pos, Mu \assignee)
> (\SELF, Any:D \pos, Mu :$BIND! is raw)
> (\SELF, Any:D \pos, :$delete!, *%other)
> (\SELF, Any:D \pos, :$exists!, *%other)
> (\SELF, Any:D \pos, :$kv!, *%other)
> (\SELF, Any:D \pos, :$p!, *%other)
> (\SELF, Any:D \pos, :$k!, *%other)
> (\SELF, Any:D \pos, :$v!, *%other)
> (\SELF, Iterable:D \pos)
> (\SELF, Iterable:D \pos, Mu \val)
> (\SELF, Iterable:D \pos, :$BIND!)
> (\SELF, Iterable:D \pos, :$delete!, *%other)
> (\SELF, Iterable:D \pos, :$exists!, *%other)
> (\SELF, Iterable:D \pos, :$kv!, *%other)
> (\SELF, Iterable:D \pos, :$p!, *%other)
> (\SELF, Iterable:D \pos, :$k!, *%other)
> (\SELF, Iterable:D \pos, :$v!, *%other)
> (\SELF, Callable:D $block)
> (\SELF, Callable:D $block, Mu \assignee)
> (\SELF, Callable:D $block, :$BIND!)
> (\SELF, Callable:D $block, :$delete!, *%other)
> (\SELF, Callable:D $block, :$exists!, *%other)
> (\SELF, Callable:D $block, :$kv!, *%other)
> (\SELF, Callable:D $block, :$p!, *%other)
> (\SELF, Callable:D $block, :$k!, *%other)
> (\SELF, Callable:D $block, :$v!, *%other)
> (\SELF, Whatever:D)
> (\SELF, Whatever:D, Mu \assignee)
> (\SELF, Whatever:D, :$BIND!)
> (\SELF, Whatever:D, :$delete!, *%other)
> (\SELF, Whatever:D, :$exists!, *%other)
> (\SELF, Whatever:D, :$kv!, *%other)
> (\SELF, Whatever:D, :$p!, *%other)
> (\SELF, Whatever:D, :$k!, *%other)
> (\SELF, Whatever:D, :$v!, *%other)
> (\SELF, HyperWhatever:D, *%adv)
> (\SELF, HyperWhatever:D, Mu \assignee)
> (\SELF, :$BIND!)
> (\SELF, :$delete!, *%other)
> (\SELF, :$exists!, *%other)
> (\SELF, :$kv!, *%other)
> (\SELF, :$p!, *%other)
> (\SELF, :$k!, *%other)
> (\SELF, :$v!, *%other)
> (\SELF, *%other)
>
>
>
> I think there's something wrong.

[perl #130520] [RFC] Deprecate `flatmap`

[Aleks-Daniel Jakimenko-Aleksejev via RT]

A lot of discussion drifted to this ticket for some reason:
https://github.com/perl6/doc/issues/1428

Let's get ourselves back here.

On 2017-07-31 14:40:50, c...@zoffix.com wrote:
> > But do you really think I'm wrong
>
> Nope. I agree it should be tossed.
>
> There's one test in 6.c-errata that merely tests its nodality.
>
> I'd say deprecate it in 6.d and toss it in 6.e. I listed that on the
> 6.d's TODO: https://github.com/perl6/6.d-
> prep/commit/2cc614bde4bc5c69884a63c3ba972dfa680b312c

[perl #132012] Numeric values of signals are wrong (say +SIGUSR1)

[Aleks-Daniel Jakimenko-Aleksejev via RT]

We now have a note in the docs about this. When fixed, change the docs
accordingly (*maybe* saying that versions before X are known to have a bug).

https://github.com/perl6/doc/commit/39e3efc08d

See IRC discussion: https://irclog.perlgeek.de/perl6/2017-09-01#i_15103501
On 2017-09-01 03:33:34, alex.jakime...@gmail.com wrote:
> Code:
> say +SIGUSR1
>
> Result:
> 30
>
>
> However, on my system SIGUSR1 is *not* 30 (it is 10). I guess rakudo
> should try harder to find proper values of the system it runs on.
>
> See this doc issue: https://github.com/perl6/doc/issues/1474

[perl #131003] [SEGV] Heap corruption when using Gumbo

[Aleks-Daniel Jakimenko-Aleksejev via RT]

https://irclog.perlgeek.de/perl6-dev/2017-09-01#i_15102810

On 2017-07-31 08:27:09, alex.jakime...@gmail.com wrote:
> FWIW, still happens after all changes during this month.
>
> On 2017-07-22 16:21:30, alex.jakime...@gmail.com wrote:
> > I bisected it to
> >
>
https://github.com/rakudo/rakudo/commit/40a953f5d9f5c661d8cf9b043643002d348a2000
> >
> > On earlier rakudo versions it seems to be working fine. I haven't
> > seen
> > it crash
> > once on anything earlier, but it is *very* slow on rakudos that old,
> > so it's
> > hard to tell.
> >
> > nqp changes:
> >
> > https://github.com/perl6/nqp/compare/2016.03-50-g512c9a1...2016.03-
> > 57-
> > gbdb13a2
> >
> > moar changes:
> > https://github.com/MoarVM/MoarVM/compare/2016.03-84-
> > g4afd7b6...2016.03-104-g10d3971
> >
> > On 2017-05-13 17:00:08, alex.jakime...@gmail.com wrote:
> > > FWIW the problem is still there and is reproducible with the
> > > provided
> > > snippet
> > > (just in case somebody is wondering if the issue went away by
> > > itself
> > > after
> > > these months).
> > >
> > > On 2017-04-04 06:46:20, scoli...@gmail.com wrote:
> > > > Le Wed, 15 Mar 2017 17:12:00 -0700, alex.jakime...@gmail.com a
> > > > écrit
> > > > :
> > > > > I am getting errors like:
> > > > > MoarVM panic: Heap corruption detected: pointer 0x7f9a96a5e588
> > > > > to
> > > > > past
> > > > > fromspace
> > > > > MoarVM panic: Internal error: zeroed target thread ID in work
> > > > > pass
> > > > >
> > > > > Even though it happens when I'm using Gumbo module, my best
> > > > > guess
> > > > > is
> > > > > that it is not its fault.
> > > > >
> > > > > Does not crash that fast with ｢perl6 --optimize=0 …｣, but
> > > > > crashes
> > > > > anyway (you may want to bump up “^100” a little bit for this).
> > > > >
> > > > > Anyway, the code to replicate the issue is shown below. If it
> > > > > gets
> > > > > mangled for some reason, here is a mirror:
> > > > > https://gist.github.com/AlexDaniel/ac7a4d4c49ec8d23e546529976dda67f
> > > > >
> > > > > #!/usr/bin/env perl6
> > > > >
> > > > > use Gumbo;
> > > > > constant URL = ‘https://perl6.org/community/’;
> > > > >
> > > > > my $response = run(:out, ‘curl’, ‘-s’, URL).out.slurp-rest;
> > > > > for ^100 {
> > > > > .say for parse-html($response).root.elements(:TAG,
> > > > > :RECURSE);
> > > > > }
> > > > >
> > > > > say ‘should've crashed before reaching this’;
> > > >
> > > > I was not able to reproduce it on a 32bit Virtual Machine (debian
> > > > stable)
> > > > Using 2016.11 rakudo and the latest from git.
> > > > Maybe it can be related to how struct size are determined by
> > > > MoarVM.
> > > >

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

[Aleks-Daniel Jakimenko-Aleksejev via RT]

I bisected moarvm manually to
https://github.com/MoarVM/MoarVM/commit/a6abd3c6654413d2230470dbaa82b7b3a2b05762

On 2017-08-30 19:09:18, alex.jakime...@gmail.com wrote:
> Bisected to
>
https://github.com/rakudo/rakudo/commit/51b63bf9f0d0594687908f0756774f29cde39c1f
>
> On 2017-08-25 18:56:37, 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

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

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Bisected to
https://github.com/rakudo/rakudo/commit/51b63bf9f0d0594687908f0756774f29cde39c1f

On 2017-08-25 18:56:37, 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

[perl #124489] Roast rakudo skip/todo test:./S02-types/set.t line:372 reason: 'we have not secured .WHICH creation yet'

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Untodoed in
https://github.com/perl6/roast/commit/03e5a5120465622d9e13451b43cdeb03fd2354a7

[perl #125081] [JVM] Roast rakudo skip/todo test:./S16-filehandles/io.t line:292 reason: 'will fail due to above failures'

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Untodoed in
https://github.com/perl6/roast/commit/b60cef93e356908eadc7855f816ec8f77bd03e01#diff-4a0037e48f821303bb0939ba43d6e6cfL291

[perl #125075] [JVM] Roast rakudo skip/todo test:./S16-filehandles/io.t line:262 reason: 'java.nio.charset.UnmappableCharacterException'

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Untodoed in
https://github.com/perl6/roast/commit/b60cef93e356908eadc7855f816ec8f77bd03e01#diff-4a0037e48f821303bb0939ba43d6e6cfL264

[perl #125017] Roast rakudo skip/todo test:./S12-introspection/meta-class.t line:35 reason: '.version, version number parsing'

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Unskipped in
https://github.com/perl6/roast/commit/e7252a2a1281f666f362b621c030f7b75db513ae

[perl #124987] Roast rakudo skip/todo test:./S06-operator-overloading/sub.t line:268 reason: 'assoc(non)'

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Unskipped in
https://github.com/perl6/roast/commit/5425477851ee07c5489d4647920797fe7ae01e19

[perl #124496] Roast rakudo skip/todo test:./S02-types/mix.t line:418 reason: 'we have not secured .WHICH creation yet'

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Untodoed in
https://github.com/perl6/roast/commit/e9f0893dc39450be68a0550c451ad1eca7e6f3ab

[perl #124555] Roast rakudo skip/todo test:./S02-literals/quoting.t line:246 reason: comments inside qq:ww [NYI]

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Untodoed in
https://github.com/perl6/roast/commit/100f141a2103f8c3194520bea7312ac3dad123c2

[perl #124454] Roast rakudo skip/todo test:./S02-types/bag.t line:462 reason: 'we have not secured .WHICH creation yet'

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Untodoed in
https://github.com/perl6/roast/commit/e9f0893dc39450be68a0550c451ad1eca7e6f3ab

[perl #124690] Roast rakudo skip/todo test:./S32-str/numeric.t line:85 reason: 'Failure'

[Aleks-Daniel Jakimenko-Aleksejev via RT]

This was untodo-ed in
https://github.com/perl6/roast/commit/e180d46b926aaa0b781b1fe5d1ee66d32a666d23

[perl #124691] Roast rakudo skip/todo test:./S32-str/numeric.t line:151 reason: complex Str.Numeric

[Aleks-Daniel Jakimenko-Aleksejev via RT]

This was untodo-ed in
https://github.com/perl6/roast/commit/e180d46b926aaa0b781b1fe5d1ee66d32a666d23

[perl #122004] Spooky capture with native int

[Aleks-Daniel Jakimenko-Aleksejev via RT]

We no longer seem to care about “is cached”, so… I don't think we should reject
this (because it may be a nice test case once we start supporting cached
trait), but at the same time this ticket is kinda useless.

On 2014-06-01 03:12:32, elizabeth wrote:
> On 01 Jun 2014, at 12:07, Elizabeth Mattijsen  wrote:
> > On 01 Jun 2014, at 12:05, perl6 via RT 
> > wrote:
> >> Greetings,
> >>
> >> This message has been automatically generated in response to the
> >> creation of a trouble ticket regarding:
> >> "Spooky capture with native int",
> >> 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 #122004].
> >>
> >> Please include the string:
> >>
> >> [perl #122004]
> >>
> >> 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
> >>
> >> -
> >> [07:39:51]  m: sub a(int $i) is cached { return unless $i;
> >> a($i-1) }; say a(4);
> >> [07:39:53] <+camelia> rakudo-moar ce6acf: OUTPUT«Cannot find
> >> method 'gist': no method cache and no .^find_method␤ in method gist
> >> at src/gen/m-CORE.setting:7121␤ in block at src/gen/m-
> >> CORE.setting:3357␤ in any enter at src/gen/m-Metamodel.nqp:3089␤
> >> in method postcircumfix:<( )> at src/gen/m-C…»
> >> [11:52:00]  Timbus: seems there is some confusion as to
> >> what gets passed to the sub
> >> [11:52:13]  is cached uses the gist of the signature to
> >> creata a key
> >> [11:52:22]  for caching the return value
> >> [11:52:34]  m: sub a(int $i) is cached { return unless $i;
> >> a(($i-1).Int) }; say a(4)
> >> [11:52:35] <+camelia> rakudo-moar ce6acf: OUTPUT«(Any)␤»
> >> [11:53:00]  either defining $i as an Int, or making sure
> >> we pass an Int, is a workaround for now
> >> [11:56:39]  yeah. just thought it was an odd one
> >>
> >> Feels like the Capture is not set up at all with a recursive call.
> >> Any direct calls seem to work ok.
> >
> > As a further datapoint: it only happens on Moar and JVM, not on
> > parrot.
>
> [12:09:15]  its an optimizer thing
> [12:11:23]  Timbus: ah, indeed, with MVM_SPESH_DISABLE=1
> no problems

[perl #101558] [RFC] Using a Pager for POD6

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Yea, it is a feature request. And I'd say a very reasonable one.

On 2012-08-07 14:43:12, moritz wrote:
> I'm a bit confused about what to do with an RFC bug. Close it, because
> no patch was forthcoming? Regard it as a feature request?

[perl #112986] error 'Use of uninitialized $_ of type Any in numeric context" throws extra errors

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Currently it says this:
Use of uninitialized value of type Any in numeric context
in block  at  line 1

As well as complains about sink context in non-repl:
Useless use of "**" in expression "$_**2" in sink context (line 1)

I see no problem with it. Except that it no longer says which variable caused
the trouble. I guess it is less than awesome, but this part changed before
2014.01. I can't bisect there and it is irrelevant to this ticket.

I'll mark this as ｢testneeded｣ in case someone can come up with a test for
this, but otherwise it is a resolved ticket.
On 2012-11-21 09:53:41, FROGGS.de wrote:
> thats the expected behaviour, right?
>
> rakudo-2012-11$ install/bin/perl6
> > $_**2;
> use of uninitialized variable $_ of type Any in numeric context
> 0
> >
>
>

[perl #116010] [BUG] something goes wrong with loose postfixes in Rakudo

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Still not 77.
On 2012-12-07 02:55:44, masak wrote:
>  rn: sub postfix:<+>($a) is looser(:<+>) { $a; 77 }; say
> +6+ +8+
>  rakudo 53daef: OUTPUT«83␤»
>  ..niecza v24-5-g599cbcb: OUTPUT«77␤»
>  hah!
>  :D
>  masak wins
> * masak submits rakudobug
>  should be 77
>  then Niecza is right.
>  in case of no spaces, postfix wins over infix
>  6+ trigers the postfix
>  so does 8+
>  So we get 77
>  oh, I see what you mean.
>  We look for an infix next
>  grr, this is hard to think about :P
> * moritz still isn't convinced
>  how is this beast parsed?
> * masak grins
>  Well, I can see what's going on easy enough up to the final
> postfix.
>  ((+6)+ + (+8))+
>  that's how I'd expect it
>  and I guess that niecza does it that way
>  right.
>  and gets 77.
>  since the final postfix is looser than the infix, I'd argue
> that's correct
>  I can get behind that.
>  so, rakudobug.
>  moritz: no, (((+6)+) + 8)+
>  there are only two pluses between the 6 and the 8.
>  so the second one must be an infix.
>  right
>  but still,the result should be 77
>  aye.

[perl #131923] Proc::Async.stdout and zero-separated input ($proc.stdout.split(“\0”) … )

[Aleks-Daniel Jakimenko-Aleksejev via RT]

I meant $proc.stdout.lines of course.

On 2017-08-27 07:32:35, alex.jakime...@gmail.com wrote:
> See https://github.com/perl6/doc/issues/1472
>
> Turns out that $proc.lines does the wrong thing, which is probably a
> bug. We do
> need nl-in for Proc::Async, and this nl-in should also be the same as
> in
> IO::Handle.
> On 2017-08-18 08:54:36, alex.jakime...@gmail.com wrote:
> > Another way to do it is to support custom nl (similarly to how we do
> > ｢$*IN.nl-in = 0.chr｣ now). Split may be an overkill.
> >
> > On 2017-08-18 08:40:32, c...@zoffix.com wrote:
> > > On Fri, 18 Aug 2017 08:35:18 -0700, alex.jakime...@gmail.com wrote:
> > > > Most command line tools support zero-separated input and output
> > > > (grep
> > > > -z, find -print0, perl -0, sort -z, xargs -0, sed -z).
> > > >
> > > > And while you can use .stdout.lines to work on things line-by-
> > > > line,
> > > > doing the same thing with null-byte separators is significantly
> > > > harder.
> > > >
> > > >  Anyway, it's pretty easy to write yourself
> > > >  Something like
> > > >  supply { my $buffer = ''; whenever $stdout { $buffer ~=
> > > > $_;
> > > > while $buffer.index("\0") -> $idx { emit $buffer.substr(0, $idx);
> > > > $buffer .= substr($idx + 1); } LAST emit $buffer } }
> > > >
> > > > I agree that it is not too hard, but it should be built in.
> > > >
> > > > One could argue that it should be *easier* to do this than to
> > > > work on
> > > > stuff line-by-line. People usually don't expect newlines in
> > > > filenames,
> > > > but it is legal and therefore any code that expects non-null
> > > > separated
> > > > paths is broken. Not sure if we should go so far in trying to get
> > > > the
> > > > huffman coding right, but a built-in way to work with data like
> > > > this
> > > > would be a great step.
> > >
> > >
> > > That'd only work for strings, while .split can also split on
> > > regexes.
> > > I'd say we defer this until Cat (lazy strings) is implemented and
> > > then
> > > do the full-featured .split and .comb on it.
> > >
> > > The exact same issue exists in IO::Handle, which currently
> > > implements
> > > it by slurping the entire file first.

[perl #131923] Proc::Async.stdout and zero-separated input ($proc.stdout.split(“\0”) … )

[Aleks-Daniel Jakimenko-Aleksejev via RT]

See https://github.com/perl6/doc/issues/1472

Turns out that $proc.lines does the wrong thing, which is probably a bug. We do
need nl-in for Proc::Async, and this nl-in should also be the same as in
IO::Handle.
On 2017-08-18 08:54:36, alex.jakime...@gmail.com wrote:
> Another way to do it is to support custom nl (similarly to how we do
> ｢$*IN.nl-in = 0.chr｣ now). Split may be an overkill.
>
> On 2017-08-18 08:40:32, c...@zoffix.com wrote:
> > On Fri, 18 Aug 2017 08:35:18 -0700, alex.jakime...@gmail.com wrote:
> > > Most command line tools support zero-separated input and output (grep
> > > -z, find -print0, perl -0, sort -z, xargs -0, sed -z).
> > >
> > > And while you can use .stdout.lines to work on things line-by-line,
> > > doing the same thing with null-byte separators is significantly
> > > harder.
> > >
> > >  Anyway, it's pretty easy to write yourself
> > >  Something like
> > >  supply { my $buffer = ''; whenever $stdout { $buffer ~= $_;
> > > while $buffer.index("\0") -> $idx { emit $buffer.substr(0, $idx);
> > > $buffer .= substr($idx + 1); } LAST emit $buffer } }
> > >
> > > I agree that it is not too hard, but it should be built in.
> > >
> > > One could argue that it should be *easier* to do this than to work on
> > > stuff line-by-line. People usually don't expect newlines in
> > > filenames,
> > > but it is legal and therefore any code that expects non-null
> > > separated
> > > paths is broken. Not sure if we should go so far in trying to get the
> > > huffman coding right, but a built-in way to work with data like this
> > > would be a great step.
> >
> >
> > That'd only work for strings, while .split can also split on regexes.
> > I'd say we defer this until Cat (lazy strings) is implemented and then
> > do the full-featured .split and .comb on it.
> >
> > The exact same issue exists in IO::Handle, which currently implements
> > it by slurping the entire file first.

[perl #131965] Shaped arrays can't have zero size

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Well, what do you mean? Of course you can't put anything into it, and any
attempt to index it will throw. It may seem useless, however, if you can have
an empty array, why can't you have a shaped empty array?
On 2017-08-26 17:13:02, allber...@gmail.com wrote:
> How exactly do you index such an array?
>
> On Sat, Aug 26, 2017 at 8:11 PM, Aleks-Daniel Jakimenko-Aleksejev via RT <
> perl6-bugs-follo...@perl.org> wrote:
>
> > Indeed. The limit was introduced as a response to this ticket:
> > https://rt.perl.org/Ticket/Display.html?id=126800
> > The check is probably too aggressive, and indeed, maybe there's nothing
> > wrong
> > with 0 sized arrays. I wonder what was the justification for making the
> > check
> > inclusive.
> > On 2017-08-26 16:15:33, david.warring wrote:
> > > This is OK:
> > >
> > > % perl6 -e'my $size = 2; my @xref[$size,3] = ([1,2,3], [4,5,6]); say
> > @xref'
> > >
> > > [[1 2 3] [4 5 6]]
> > >
> > > But this isn't:
> > >
> > > % perl6 -e'my $size = 0; my @xref[$size,3] = (); say @xref'
> > >
> > > Illegal dimension in shape: 0. All dimensions must be integers bigger
> > than
> > > 0
> > > in block  at -e line 1
> > >
> > > % perl6 -v
> > > This is Rakudo version 2017.08 built on MoarVM version 2017.08.1
> > > implementing Perl 6.c.
> > >
> > > Just seems an unreasonable restriction that the major shape size of an
> > > array can't be zero.
> >
> >
>
>

[perl #131965] Shaped arrays can't have zero size

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Indeed. The limit was introduced as a response to this ticket:
https://rt.perl.org/Ticket/Display.html?id=126800
The check is probably too aggressive, and indeed, maybe there's nothing wrong
with 0 sized arrays. I wonder what was the justification for making the check
inclusive.
On 2017-08-26 16:15:33, david.warring wrote:
> This is OK:
>
> % perl6 -e'my $size = 2; my @xref[$size,3] = ([1,2,3], [4,5,6]); say @xref'
>
> [[1 2 3] [4 5 6]]
>
> But this isn't:
>
> % perl6 -e'my $size = 0; my @xref[$size,3] = (); say @xref'
>
> Illegal dimension in shape: 0. All dimensions must be integers bigger than
> 0
> in block  at -e line 1
>
> % perl6 -v
> This is Rakudo version 2017.08 built on MoarVM version 2017.08.1
> implementing Perl 6.c.
>
> Just seems an unreasonable restriction that the major shape size of an
> array can't be zero.

[perl #130604] [PARSER] Weirdness when mixing `..` and `...` without parens

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Indeed, I'm not sure what I was smoking.
On 2017-01-20 21:27:50, sml...@gmail.com wrote:
> > It numifies ranges so that the number of elements is used. In other
> > words, 1..2
> > works like 2 and 1..1 works like 1.
>
> No, if it worked like that then the first two examples would throw the
> same error as the third, instead of exhibiting behaviors that are both
> different from that and from each other.
>
> Here are two more examples, showing the difference in case of an
> actual arithmetic series:
>
> ➜ say 1..1, 3 ... 7;
> (1..1 3 4 5 6 7)
>
> ➜ say 1, 3 ... 7;
> (1 3 5 7)

[perl #131801] Stranded strings with combiners or ZWJ on borders break my NFG expectations ( (“\x[0305]a” x 2).chars.say )

[Aleks-Daniel Jakimenko-Aleksejev via RT]

This is the same issue, but it is interesting nonetheless:

 m: dd (0x0F75.chr x 2).uninames
 rakudo-moar 636a3c: OUTPUT: «("TIBETAN VOWEL SIGN AA", "TIBETAN VOWEL
SIGN U", "TIBETAN VOWEL SIGN AA", "TIBETAN VOWEL SIGN U").Seq␤»
 m: dd (0x0F75.chr ~ 0x0F75.chr).uninames
 rakudo-moar 636a3c: OUTPUT: «("TIBETAN VOWEL SIGN AA", "TIBETAN VOWEL
SIGN AA", "TIBETAN VOWEL SIGN U", "TIBETAN VOWEL SIGN U").Seq␤»

Note that the order should be normalized.
On 2017-07-26 03:36:32, alex.jakime...@gmail.com wrote:
> Code:
> say (“\c[COMBINING OVERLINE]a” x 2).chars
>
> Result:
> 4
>
>
> Code:
> say (“\c[COMBINING OVERLINE]a” ~ “\c[COMBINING OVERLINE]a”).chars
>
> Result:
> 3
>
>
>
> Both should produce the same result (3). What happens here is “a” on
> one side is not being squished into one grapheme with a combiner on
> another side.
>
> Please note that combiners are not the only thing can cause this. Here
> is the same thing with ZWJ:
>
> Code:
> my $x = “\x[2695]\x[FE0F]a\x[1F468]\x[200D]”;
> say ($x ~ $x).chars;
> say ($x x 2).chars
>
>
> Result:
> 5
> 6
>
>
>
>
> I have a feeling that this is a known issue, and that there might be a
> ticket for this already. However, I couldn't find it.

[perl #126558] [BUG] Grammar parse failure should probably return Nil not Any

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Is this ticket relevant today?

Note that we also have this: https://rt.perl.org/Ticket/Display.html?id=131919
On 2016-12-19 08:41:33, ronaldxs wrote:
> On Tue, 03 Nov 2015 14:26:06 -0800, ronaldxs wrote:
> > 18:07 mr_ron m: grammar G { token TOP { a+ } }; my Nil $x =
> > G.parse("zz")
> > 18:07 camelia rakudo-moar 273e89: OUTPUT«Type check failed in
> > assignment to $x; expected Nil but got Any␤ in block  at
> > /tmp/HMNfyPJjvI:1␤␤»
> >
> > 17:56 mr_ron m: grammar G { token TOP { a+ |  }; token bs { b+ }
> > }; say G.parse("zz").WHAT; say G.parse("aa").WHAT
> > 17:56 camelia rakudo-moar 273e89: OUTPUT«(Any)␤Nil␤»
>
> Reran test cases and they now run as expected. Might be of interest
> to add test case(s?) to roast/S05-match/non-capturing.t?

[perl #131919] [RFC] Returning Failure from failed P6-level .parse

[Aleks-Daniel Jakimenko-Aleksejev via RT]

It was removed completely for 2017.08 release.

Rakudo commit:
https://github.com/rakudo/rakudo/commit/465d91abdfda038cb7feda35f7966be4ec39acf3
Discussion: https://irclog.perlgeek.de/perl6-dev/2017-08-21#i_15048995
On 2017-08-19 15:31:01, alex.jakime...@gmail.com wrote:
> I had to revert one of the nqp commits related to .parse:
> https://github.com/perl6/nqp/commit/d4d77b66c46c57de800b147df61fe486b4486acd
>
> Here's a ticket for the module that was affected by the change:
> https://github.com/p6-css/CSS-Module-p6/issues/10
>
> Most certainly we want this change back ASAP, but it had to be
> reverted for the
> release.
>
> ♥
>
> On 2017-08-19 05:36:36, alex.jakime...@gmail.com wrote:
> > The change was moved to v6.d in this commit:
> >
>
https://github.com/rakudo/rakudo/commit/d2278b471cb0bd691dc7a1235fbcb9318ff5d61f
> >
> > On 2017-08-17 08:50:48, alex.jakime...@gmail.com wrote:
> > > See this commit:
> > >
> >
>
https://github.com/rakudo/rakudo/commit/9501edae4f73a970e3270e3b0336a7b3045d3329
> > >
> > > These roast commits:
> > > *
> > >
> >
>
https://github.com/perl6/roast/commit/1fb68c4b7a7c975f26fc81ad79f000958d1b4afd
> > > *
> > >
> >
>
https://github.com/perl6/roast/commit/b53616f8e67f9b19366008b3abf55400a3d6cd2b
> > >
> > > And this justification:
> > > * https://irclog.perlgeek.de/perl6-dev/2017-08-16#i_15021994
> > >
> > > This blog post noticing the breakage due to the change:
> > > * https://gfldex.wordpress.com/2017/08/17/parsing-nothing/
> > >
> > > And these thoughts about postponing it to v6.d:
> > > * https://irclog.perlgeek.de/perl6-dev/2017-08-17#i_15032160
> > >
> > >
> > > I am confident that we will not be able to process this change and
> > > all
> > > potential breakage associated with it in ≈3 days before the
> > > release,
> > > so the revert is coming.
> > >
> > > Personally, I don't mind rereverting it afterwards for inclusion in
> > > 2017.09, assuming we make sure to fix all modules that were relying
> > > on
> > > Nils being returned. However, I do see the point for postponing it
> > > till v6.d.
> > >
> > >
> > > So should we feel adventurous and push this change as early as we
> > > can
> > > (in 2017.09, aftear at least one month)? Or is it better to be safe
> > > and wait for v6.d? Please discuss.

[perl #131935] Spesh issue with errata tests: complex.t, unpolar.t, rat.t, fatrat.t

[Aleks-Daniel Jakimenko-Aleksejev via RT]

A workaround for it was added in
https://github.com/rakudo/rakudo/commit/1d69ebb9c2514fe5ae156998f71e4a112801b603

Without MVM_SPESH_DISABLE=1 it can give this kind of warning:

Block  (from unknown) seen at:
/tmp/21S1e2RPQr, lines 107,115,122,69
Please use is-approx instead.


This is LTA but at least no longer critical.

On 2017-08-20 07:06:50, alex.jakime...@gmail.com wrote:
> See IRC log: https://irclog.perlgeek.de/perl6-dev/2017-08-
> 20#i_15045830
>
> Some highlights from the log:
>
> Error:
> Unable to call postcircumfix $bt[ (Any) ] with a type object
> Indexing requires a defined object
> in sub is_approx at /tmp/whateverable/rakudo-
>
moar/10df9a95b3f5b4940fc7ce6b8ecf49fed0aea2f5/share/perl6/sources/C712FE6969F786C9380D643DF17E85D06868219E
> (Test) line 266
> in block  at /tmp/JRV8fruTHd line 87
>
>
> Bisected to
>
https://github.com/rakudo/rakudo/commit/f590863e1736c75207c9ce0335ea646e3529060e
>
> No issue with MVM_SPESH_DISABLE=1

[perl #131934] Errata test fail S17-promise/allof.t

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Nevermind, the test was wrong.
https://github.com/perl6/roast/commit/66792f989db6eb0832b134b2b327135f785e7974

On 2017-08-20 05:12:56, alex.jakime...@gmail.com wrote:
> This test is failing:
>
https://github.com/perl6/roast/blob/b0044b0751fc13f97abca1ac4f76ccc5bb109112/S17-
> promise/allof.t#L32-L45
>
> Committable output on 2017.07 and HEAD:
> https://gist.github.com/07f20d12106814b88c54905bad7d61e6
>
> Bisectable gives this result (not super helpful to me):
> https://gist.github.com/567e7a840110c1002d53c0c67eadaa2e
>
> It is something about the merge of atomic and other stuff.

[perl #131919] [RFC] Returning Failure from failed P6-level .parse

[Aleks-Daniel Jakimenko-Aleksejev via RT]

I had to revert one of the nqp commits related to .parse:
https://github.com/perl6/nqp/commit/d4d77b66c46c57de800b147df61fe486b4486acd

Here's a ticket for the module that was affected by the change:
https://github.com/p6-css/CSS-Module-p6/issues/10

Most certainly we want this change back ASAP, but it had to be reverted for the
release.

♥

On 2017-08-19 05:36:36, alex.jakime...@gmail.com wrote:
> The change was moved to v6.d in this commit:
>
https://github.com/rakudo/rakudo/commit/d2278b471cb0bd691dc7a1235fbcb9318ff5d61f
>
> On 2017-08-17 08:50:48, alex.jakime...@gmail.com wrote:
> > See this commit:
> >
>
https://github.com/rakudo/rakudo/commit/9501edae4f73a970e3270e3b0336a7b3045d3329
> >
> > These roast commits:
> > *
> >
>
https://github.com/perl6/roast/commit/1fb68c4b7a7c975f26fc81ad79f000958d1b4afd
> > *
> >
>
https://github.com/perl6/roast/commit/b53616f8e67f9b19366008b3abf55400a3d6cd2b
> >
> > And this justification:
> > * https://irclog.perlgeek.de/perl6-dev/2017-08-16#i_15021994
> >
> > This blog post noticing the breakage due to the change:
> > * https://gfldex.wordpress.com/2017/08/17/parsing-nothing/
> >
> > And these thoughts about postponing it to v6.d:
> > * https://irclog.perlgeek.de/perl6-dev/2017-08-17#i_15032160
> >
> >
> > I am confident that we will not be able to process this change and
> > all
> > potential breakage associated with it in ≈3 days before the release,
> > so the revert is coming.
> >
> > Personally, I don't mind rereverting it afterwards for inclusion in
> > 2017.09, assuming we make sure to fix all modules that were relying
> > on
> > Nils being returned. However, I do see the point for postponing it
> > till v6.d.
> >
> >
> > So should we feel adventurous and push this change as early as we can
> > (in 2017.09, aftear at least one month)? Or is it better to be safe
> > and wait for v6.d? Please discuss.

[perl #131919] [RFC] Returning Failure from failed P6-level .parse

[Aleks-Daniel Jakimenko-Aleksejev via RT]

The change was moved to v6.d in this commit:
https://github.com/rakudo/rakudo/commit/d2278b471cb0bd691dc7a1235fbcb9318ff5d61f

On 2017-08-17 08:50:48, alex.jakime...@gmail.com wrote:
> See this commit:
>
https://github.com/rakudo/rakudo/commit/9501edae4f73a970e3270e3b0336a7b3045d3329
>
> These roast commits:
> *
>
https://github.com/perl6/roast/commit/1fb68c4b7a7c975f26fc81ad79f000958d1b4afd
> *
>
https://github.com/perl6/roast/commit/b53616f8e67f9b19366008b3abf55400a3d6cd2b
>
> And this justification:
> * https://irclog.perlgeek.de/perl6-dev/2017-08-16#i_15021994
>
> This blog post noticing the breakage due to the change:
> * https://gfldex.wordpress.com/2017/08/17/parsing-nothing/
>
> And these thoughts about postponing it to v6.d:
> * https://irclog.perlgeek.de/perl6-dev/2017-08-17#i_15032160
>
>
> I am confident that we will not be able to process this change and all
> potential breakage associated with it in ≈3 days before the release,
> so the revert is coming.
>
> Personally, I don't mind rereverting it afterwards for inclusion in
> 2017.09, assuming we make sure to fix all modules that were relying on
> Nils being returned. However, I do see the point for postponing it
> till v6.d.
>
>
> So should we feel adventurous and push this change as early as we can
> (in 2017.09, aftear at least one month)? Or is it better to be safe
> and wait for v6.d? Please discuss.

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

[Aleks-Daniel Jakimenko-Aleksejev via RT]

It was fixed in this commit:
https://github.com/MoarVM/MoarVM/commit/5363a0742d9ea7183200a747c2d7531e82bc5c71

samcv++

Tests needed.
On 2017-08-18 12:48:20, alex.jakime...@gmail.com wrote:
> The issue happens in Email::Simple (one of its tests is now failing,
> but it was ok in 2017.07).
>
> Here's the code:
>
> use v6;
> use Test;
> use Email::Simple;
> my $nr = "\x0a\x0d";
> my $nasty = "Subject: test{$nr}To: foo{$nr}{$nr}foo{$nr}";
> my $mail = Email::Simple.new($nasty);
> is $mail.crlf, "{$nr}", "got correct line terminator";
> is $mail.body, "foo{$nr}", "got correct body";
> is ~$mail, $nasty, "Round trip nasty";
>
>
> Result:
> ok 1 - got correct line terminator
> ok 2 - got correct body
> not ok 3 - Round trip nasty
>
> # Failed test 'Round trip nasty'
> # at t/basic.t line 9
> # expected: "Subject: test\n\rTo: foo\n\r\n\rfoo\n\r"
> # got: "Subject: test\n\rTo: foo\n\r\n\rfoo\n\r"
>
>
> Yes, it displays two strings that look identical, but (~$mail eq
> $nasty) is actually False.
>
>
> Bisected:
>
>  bisect: old=2017.07
>
https://gist.githubusercontent.com/AlexDaniel/64032cb24876d9a1cfac44a752921d20/raw/2d242fa49eef2b74da1b6626e337631463471182/basic.t
>  AlexDaniel, Successfully fetched the code from the
> provided URL.
>  AlexDaniel, Bisecting by exit code (old=2017.07
> new=1599873). Old exit code: 0
>  AlexDaniel, bisect log:
> https://gist.github.com/d16b49e55a1102e25b95be5df7bbf902
>  AlexDaniel, (2017-07-20)
>
https://github.com/rakudo/rakudo/commit/b81597bd867a0072cea6453529da89a13ede808c
>
>
> So it is due to “String concatenation improvements”, or so it seems.

[perl #131923] Proc::Async.stdout and zero-separated input ($proc.stdout.split(“\0”) … )

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Another way to do it is to support custom nl (similarly to how we do
｢$*IN.nl-in = 0.chr｣ now). Split may be an overkill.

On 2017-08-18 08:40:32, c...@zoffix.com wrote:
> On Fri, 18 Aug 2017 08:35:18 -0700, alex.jakime...@gmail.com wrote:
> > Most command line tools support zero-separated input and output (grep
> > -z, find -print0, perl -0, sort -z, xargs -0, sed -z).
> >
> > And while you can use .stdout.lines to work on things line-by-line,
> > doing the same thing with null-byte separators is significantly
> > harder.
> >
> >  Anyway, it's pretty easy to write yourself
> >  Something like
> >  supply { my $buffer = ''; whenever $stdout { $buffer ~= $_;
> > while $buffer.index("\0") -> $idx { emit $buffer.substr(0, $idx);
> > $buffer .= substr($idx + 1); } LAST emit $buffer } }
> >
> > I agree that it is not too hard, but it should be built in.
> >
> > One could argue that it should be *easier* to do this than to work on
> > stuff line-by-line. People usually don't expect newlines in
> > filenames,
> > but it is legal and therefore any code that expects non-null
> > separated
> > paths is broken. Not sure if we should go so far in trying to get the
> > huffman coding right, but a built-in way to work with data like this
> > would be a great step.
>
>
> That'd only work for strings, while .split can also split on regexes.
> I'd say we defer this until Cat (lazy strings) is implemented and then
> do the full-featured .split and .comb on it.
>
> The exact same issue exists in IO::Handle, which currently implements
> it by slurping the entire file first.

[perl #131922] [LTA] "Variadic" or "slurpy"?

[Aleks-Daniel Jakimenko-Aleksejev via RT]

This could've been a LHF, except for these tests:
https://github.com/perl6/roast/blob/4bfd6d2374cb4ea1b8fa057a5f294b988e4dec44/S32-exceptions/misc.t#L180-L185

¯\_(ツ)_/¯

But yes, I think it should say “slurpy” everywhere.

On 2017-08-18 07:10:52, comdog wrote:
> Consider this program which I don't expect to work (and it doesn't compile):
>
> sub show-the-arguments ( *@args, $i ) {
> put "The arguments are @args[]";
> }
>
> show-the-arguments( 1, 3, 7 );
>
> The error message says "variadic":
>
> Cannot put required parameter $i after variadic parameters
>
> But another sort of error uses a different term:
>
> sub show-the-arguments ( *@args, $i ) {
> put "The arguments are @args[]";
> }
>
> This time the error messages say "slurpy":
>
> Only one slurpy positional allowed
>
> The docs almost almost always say "slurpy" and the uses of "variadic"
> only appear as synonyms next to "slurpy":
>
> * https://github.com/perl6/doc/search?utf8=✓=variadic=
>
> * https://github.com/perl6/doc/search?utf8=✓=slurpy=

[perl #131915] [REGRESSION] Proc using more memory since being a Proc::Async

[Aleks-Daniel Jakimenko-Aleksejev via RT]

https://irclog.perlgeek.de/perl6-dev/2017-08-17#i_15032963

On 2017-08-16 14:30:42, alex.jakime...@gmail.com wrote:
> TL;DR it went from 59820 to 215976 after this commit:
>
https://github.com/rakudo/rakudo/commit/92bd7e4f54a92fa660f99b4d056d33a08fb98bd2
>
> Bisect log:
> https://gist.github.com/678ce88a13272eab454a22568f3bddc7
>
> On 2017-08-16 14:24:48, scoli...@gmail.com wrote:
> > Similar to https://rt.perl.org/m/ticket/show?id=131914 it was noticed
> > that there is a huge increase of memory usage after running a simple
> > echo command.
> > Result are in Kbytes.
> >
> >  commit:
> > 92bd7e4f54a9^,92bd7e4f54a9,9658dd98c9dd8ec^^,9658dd98c9dd8ec sub mem
> > {
> > "/proc/$*PID/statm".IO.lines[0].split(/\s/)[5] * 4096 / 1024 }; say
> > mem(); run 'echo'; say mem()
> >  AlexDaniel, ¦92bd7e4f54a9^: «56444␤␤59820»
> > ¦92bd7e4: «56568␤␤215976» ¦9658dd98c9dd8ec^^: «59212␤␤216660»
> > ¦9658dd9: «139024␤␤305320»

[perl #131914] [REGRESSION] Rakudo/Moar taking more memory at launch.

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Also, it's not any different on HEAD:

 committable6test: 9658dd98c9dd8ec^^,9658dd98c9dd8ec,HEAD say
"/proc/$*PID/statm".IO.lines[0].split(/\s/)[5] * 4096 / 1024
 AlexDaniel, ¦9658dd98c9dd8ec^^: «58628» ¦9658dd9: «138220»
¦HEAD(3e70d44): «136436»

On 2017-08-16 14:27:37, alex.jakime...@gmail.com wrote:
> Note that the tests on 92bd7e4^ and 92bd7e4 are not very related to
> this
> particular issue.
>
> To put simply: it went from 58628 to 138220 because of changes related
> to this
> commit (or maybe one or two commits before it):
>
https://github.com/rakudo/rakudo/commit/9658dd98c9dd8ecbefc606a08357e59718e328c2
>
> For Proc → Proc::Async issue see this ticket:
> https://rt.perl.org/m/ticket/show?id=131915
>
> Bisect logs:
> https://gist.github.com/6a7a6bfbc157bac3d06e9d2d58306846
> https://gist.github.com/5cf477671560bad21251207895708d94
>
>
> On 2017-08-16 14:21:25, scoli...@gmail.com wrote:
> > After some test against various release of rakudo it appear that
> > there
> > is a huge step in the memory taken by rakudo/moar at launch. (after
> > 2017.05)
> > It's like up to 55Mb to 120Mb+
> >
> > It was tested by reading the memory info in /proc/pid/statm (the
> > number is in Kbytes)
> >
> >  committable6test:
> > 92bd7e4f54a9^,92bd7e4f54a9,9658dd98c9dd8ec^^,9658dd98c9dd8ec say
> > "/proc/$*PID/statm".IO.lines[0].split(/\s/)[5] * 4096 / 1024
> >  AlexDaniel, ¦92bd7e4f54a9^: «55752» ¦92bd7e4:
> > «55896» ¦9658dd98c9dd8ec^^: «58628» ¦9658dd9: «138220»

[perl #131915] [REGRESSION] Proc using more memory since being a Proc::Async

[Aleks-Daniel Jakimenko-Aleksejev via RT]

TL;DR it went from 59820 to 215976 after this commit:
https://github.com/rakudo/rakudo/commit/92bd7e4f54a92fa660f99b4d056d33a08fb98bd2

Bisect log:
https://gist.github.com/678ce88a13272eab454a22568f3bddc7

On 2017-08-16 14:24:48, scoli...@gmail.com wrote:
> Similar to https://rt.perl.org/m/ticket/show?id=131914 it was noticed
> that there is a huge increase of memory usage after running a simple
> echo command.
> Result are in Kbytes.
>
>  commit:
> 92bd7e4f54a9^,92bd7e4f54a9,9658dd98c9dd8ec^^,9658dd98c9dd8ec sub mem {
> "/proc/$*PID/statm".IO.lines[0].split(/\s/)[5] * 4096 / 1024 }; say
> mem(); run 'echo'; say mem()
>  AlexDaniel, ¦92bd7e4f54a9^: «56444␤␤59820»
> ¦92bd7e4: «56568␤␤215976» ¦9658dd98c9dd8ec^^: «59212␤␤216660»
> ¦9658dd9: «139024␤␤305320»

[perl #131914] [Regression] Rakudo/Moar taking more memory at launch.

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Note that the tests on 92bd7e4^ and 92bd7e4 are not very related to this
particular issue.

To put simply: it went from 58628 to 138220 because of changes related to this
commit (or maybe one or two commits before it):
https://github.com/rakudo/rakudo/commit/9658dd98c9dd8ecbefc606a08357e59718e328c2

For Proc → Proc::Async issue see this ticket:
https://rt.perl.org/m/ticket/show?id=131915

Bisect logs:
https://gist.github.com/6a7a6bfbc157bac3d06e9d2d58306846
https://gist.github.com/5cf477671560bad21251207895708d94


On 2017-08-16 14:21:25, scoli...@gmail.com wrote:
> After some test against various release of rakudo it appear that there
> is a huge step in the memory taken by rakudo/moar at launch. (after
> 2017.05)
> It's like up to 55Mb to 120Mb+
>
> It was tested by reading the memory info in /proc/pid/statm (the
> number is in Kbytes)
>
>  committable6test:
> 92bd7e4f54a9^,92bd7e4f54a9,9658dd98c9dd8ec^^,9658dd98c9dd8ec say
> "/proc/$*PID/statm".IO.lines[0].split(/\s/)[5] * 4096 / 1024
>  AlexDaniel, ¦92bd7e4f54a9^: «55752» ¦92bd7e4:
> «55896» ¦9658dd98c9dd8ec^^: «58628» ¦9658dd9: «138220»

[perl #131879] [REGRESSION] Memory “leak”

[Aleks-Daniel Jakimenko-Aleksejev via RT]

OK, this is still not resolved, but it got noticeably better.

The issue is reproducible with the snippet provided in the original report.
On 2017-08-11 10:01:42, alex.jakime...@gmail.com wrote:
> There was some progress on this. jnthn++
>
> I guess the most promising commit regarding this issue is
>
https://github.com/MoarVM/MoarVM/commit/0d2e5f8cc0264eb495ea4f20f3a0c90d05d55710
> , but there's at least one other commit that could've improved the
> situation (
>
https://github.com/rakudo/rakudo/commit/c59b986785fe17f53e1664af1aa60e785ff31624
> ).
>
> I will test this again after we have MoarVM bumped (or sooner if I
> have time).
>
> On 2017-08-10 10:43:42, alex.jakime...@gmail.com wrote:
> > After recent rakudo updates whateverables started having some
> > problems. At first I thought that they simply became slower, but upon
> > further investigation it turned out that their memory usage was
> > increasing during the operation (which is most likely the reason for
> > them to slow down during the execution).
> >
> > MasterDuke++ did a lot of investigation and measurements, so I'm
> > hoping to see his comments here. I don't have much to say, so I'll
> > just give a bunch of links. Please bear with me.
> >
> > Initial conversation and relatively golfed down code:
> > https://irclog.perlgeek.de/moarvm/2017-08-05#i_14973432
> > https://gist.github.com/MasterDuke17/685b627a6a2749483dc5ec09c6a777a4
> >
> > dogbert11++ reproducing the issue
> > https://irclog.perlgeek.de/moarvm/2017-08-06#i_14976177
> >
> > (note that it seems like there's no memory leak, but the memory usage
> > is growing)
> >
> > More: https://irclog.perlgeek.de/perl6/2017-08-08#i_14987204
> >
> >
> > I don't know if this affects anybody else, but jdv79++ was talking
> > about some memory issues recently: https://irclog.perlgeek.de/perl6-
> > dev/2017-08-05#i_14973488

[perl #131857] [REGRESSION] Aliased named parameters broke in a recent MoarVM commit

[Aleks-Daniel Jakimenko-Aleksejev via RT]

No bug with MVM_SPESH_DISABLE=1.

On 2017-08-07 19:48:36, ddgr...@gmail.com wrote:
> [22:44]  m: sub foo(:color(:$colour)) { $colour + 1 }; my
> $s;
> for ^100 { $s += foo(:color($_)) }; say $s; say now - INIT now
> [22:44] <+camelia> rakudo-moar a91ad2: OUTPUT: «Unexpected named
> argument
> 'color' passed␤ in sub foo at  line 1␤ in block  at 
> line
> 1␤␤»
> [22:44]  bisectable6: sub foo(:color(:$colour)) { $colour
> + 1
> }; my $s; for ^100 { $s += foo(:color($_)) }; say $s;
> [22:44] <+bisectable6> MasterDuke, Bisecting by exit code (old=2015.12
> new=a91ad2d). Old exit code: 0
> [22:44] <+bisectable6> MasterDuke, bisect log:
> https://gist.github.com/651d00f77245537de7326c9316f4513e
> [22:44] <+bisectable6> MasterDuke, (2017-08-04)
>
https://github.com/rakudo/rakudo/commit/8bed4a67b44acb6c0e9f057d11a2ab2f0ea5d8cd
> [22:45]  haw
> [22:45]  c: 2017.07 sub foo(:color(:$colour)) { $colour +
> 1 };
> my $s; for ^100 { $s += foo(:color($_)) }; say $s; say now - INIT
> now
> [22:45] <+committable6> MasterDuke, ¦2017.07: «5050␤1.4953885»

[perl #131888] No such method 'cache' for invocant of type 'NQPMu'

[Aleks-Daniel Jakimenko-Aleksejev via RT]

I think things would go faster with this one if it was golfed down.

Given the previous warnings saying “Use of uninitialized value $key of type Any
in string context.”, the issue is quite possibly in Uzu itself (or maybe even
Mustache). The ticket is of course valid because the error should not complain
about NQPMu's, and maybe there's some deeper issue with this.


On 2017-08-13 05:13:40, emmil...@gmail.com wrote:
> None of the provided environmental variables reliably fixed the issue.
> MVM_SPESH_INLINE_DISABLE=1 seemed to provide slightly better results
> overall, but that may have been due to random chance, and the original
> error still sometimes appeared.

[perl #131879] [REGRESSION] Memory “leak”

[Aleks-Daniel Jakimenko-Aleksejev via RT]

There was some progress on this. jnthn++

I guess the most promising commit regarding this issue is
https://github.com/MoarVM/MoarVM/commit/0d2e5f8cc0264eb495ea4f20f3a0c90d05d55710
, but there's at least one other commit that could've improved the situation (
https://github.com/rakudo/rakudo/commit/c59b986785fe17f53e1664af1aa60e785ff31624
).

I will test this again after we have MoarVM bumped (or sooner if I have time).

On 2017-08-10 10:43:42, alex.jakime...@gmail.com wrote:
> After recent rakudo updates whateverables started having some
> problems. At first I thought that they simply became slower, but upon
> further investigation it turned out that their memory usage was
> increasing during the operation (which is most likely the reason for
> them to slow down during the execution).
>
> MasterDuke++ did a lot of investigation and measurements, so I'm
> hoping to see his comments here. I don't have much to say, so I'll
> just give a bunch of links. Please bear with me.
>
> Initial conversation and relatively golfed down code:
> https://irclog.perlgeek.de/moarvm/2017-08-05#i_14973432
> https://gist.github.com/MasterDuke17/685b627a6a2749483dc5ec09c6a777a4
>
> dogbert11++ reproducing the issue
> https://irclog.perlgeek.de/moarvm/2017-08-06#i_14976177
>
> (note that it seems like there's no memory leak, but the memory usage
> is growing)
>
> More: https://irclog.perlgeek.de/perl6/2017-08-08#i_14987204
>
>
> I don't know if this affects anybody else, but jdv79++ was talking
> about some memory issues recently: https://irclog.perlgeek.de/perl6-
> dev/2017-08-05#i_14973488

[perl #131785] [BUG] - runtime looping.

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Great analysis!

The first issue seems to be already mentioned in RT #126112 (and I vaguely
recall one more ticket, but I'm failing to find it now).

This ticket seems to be getting a bit unmanageable, please file smaller tickets
for every issue you discover.


On 2017-08-10 21:36:34, b...@abrij.org wrote:
>
> Analysis... you've run into a nest of LTA/bugs.
>
> 1) First off, this will loop:
>
> perl6 -e 'class A does Numeric { }; say A.new + A.new'
>
> The reason it loops is because the default infix:<+> (provided by
> Numeric) does this:
>
> multi sub infix:<+>(\a, \b) { a.Numeric + b.Numeric }
>
> ...and the default .Numeric, also provided by Numeric, is just { self
> }
>
> This is where the loop comes from.
>
> The problem would be avoided if the proper infix:<+> candidate were
> being
> called, but the sanity of Numeric might be improved with something
> which
> breaks that loop and throws some reasonable exception telling you that
> you really need to define a specific candidate... how to implement
> that
> efficiently might be a challenge.
>
> 2) A simple explanation would have been that the EXPORT::DEFAULT needs
> to contain an :<+>
> symbol, and the multis in this package do not provide that symbol. If
> you add this
> to the EXPORT::DEFAULT package:
>
> my constant :<+> = :<+>;
>
> ...then the multis will show up in
> :<+>.candidates>>.signature.say
>
> Whether the presence of those multis should add the Stash key
> automatically
> when in an EXPORT package is arguably an LTA... probably they see the
> Setting's
> prototype and do not because a generic package shouldn't.
>
> 3) But it was not that simple... I know the docs say to, but I'm not
> sure
> what us gong on with using EXPORT::DEFAULT and "unit module" together.
> I know
> the intention was to make it work but maybe NYI? The first
> questionable thing
> to notice is that after a "use test1" an EXPORT::DEFAULT Stash is in
> your namespace:
>
> $ PERL6LIB="/tmp/" perl6 -e 'use v6.c; use test1;
> EXPORT::DEFAULT::.keys.say;'
> (Fpa )
>
> ... I don't think this is supposed to happen; you should get
> test1::EXPORT::DEFAULT
> instead. That Stash is empty:
>
> $ PERL6LIB="/tmp/" perl6 -e 'use v6.c; use test1;
> test1::EXPORT::DEFAULT::.keys.say;'
>
> Could not find symbol ''
> in block  at -e line 1
>
> But, despite this, the Fpa class does seem to be available and the
> multis seem to be
> added with this formulation, albeit with ugly test1::EXPORT::DEFAULT
> prefixes due to
> the location of the class definition.
>
> Now I'll assume you are using EXPORT::DEFAULT rather than just marking
> things as
> "is export" for a good reason, so we'll humor that and see whether we
> can
> find a formulation that works... because it should be possible to do
> things
> with this form if you really want to.
>
> 4) I found that even with the candidates in your module available,
> Numeric's infix:<+>
> was still being called. However, if you jam any additional random
> multi candidate into
> infix:<+> in your mainline, this seems to jog things into finding the
> candidates:
>
> ...but without that extra candidate it still ends up in
> Numeric::infix<+>(\a, \b).
>
> $ PERL6LIB="/tmp/" perl6 --ll-exception -e 'use v6.c; use test1;
> EXPORT::DEFAULT::.keys.say; my Fpa $x = Fpa.new(); my Fpa $y =
> Fpa.new(); $y.var = 5; $x.var = 1; say $x.perl, $y.perl; say
> :<+>.candidates>>.signature; class foobar { }; multi sub
> infix:<+> (foobar $, foobar $) { }; say ($x + $y).perl'
> (Fpa )
> test1::EXPORT::DEFAULT::Fpa.new(var =>
> 1)test1::EXPORT::DEFAULT::Fpa.new(var => 5)
> (($x = 0) (\a, \b) (Real \a, Real \b) (Int:D \a, Int:D \b --> Int:D)
> (int $a, int $b --> int) (Num:D \a, Num:D \b) (num $a, num $b --> num)
> (Range:D \a, Real:D \b) (Real:D \a, Range:D \b) (Rational \a, Rational
> \b) (Rational \a, Int \b) (Int \a, Rational \b) (Complex:D \a,
> Complex:D \b --> Complex:D) (Complex:D \a, Real \b --> Complex:D)
> (Real \a, Complex:D \b --> Complex:D) (Instant:D $a, Real:D $b)
> (Real:D $a, Instant:D $b) (Instant:D $a, Duration:D $b) (Duration:D
> $a, Instant:D $b) (Duration:D $a, Real $b) (Real $a, Duration:D $b)
> (Duration:D $a, Duration:D $b) (DateTime:D \a, Duration:D \b)
> (Duration:D \a, DateTime:D \b) (Date:D $d, Int:D $x) (Int:D $x, Date:D
> $d) (test1::EXPORT::DEFAULT::Fpa:D $left,
> test1::EXPORT::DEFAULT::Fpa:D $right --> test1::EXPORT::DEFAULT::Fpa)
> (Any:D $left, test1::EXPORT::DEFAULT::Fpa:D $right -->
> test1::EXPORT::DEFAULT::Fpa) (test1::EXPORT::DEFAULT::Fpa:D $left,
> Any:D $right --> test1::EXPORT::DEFAULT::Fpa) (foobar, foobar))
> here 1!
> In fpaAdd
> test1::EXPORT::DEFAULT::Fpa.new(var => 6)
>
> ...this, however, might be a consequence of the value of the
> 'infix:<+>' constant
> I installed earlier to fix #2 above... may somehow have gotten glued
> to a too-specific
> compiler construct (fold/spesh/opt)
>
> Do note that the (Any:D $, Fpa:D $) and (Fpa:D $, Any:D $) will fail
> as written
> since they don't convert the non-Fpa parameter or 

[perl #131865] [REGRESSION] Looping over a HyperSeq in sink context does nothing (for .hyper { say 2 })

[Aleks-Daniel Jakimenko-Aleksejev via RT]

IRC discussion: https://irclog.perlgeek.de/perl6/2017-08-09#i_14989886

Turns out that .hyper/.race never worked reliably anyway, so this ticket is
less important than it looks.

Maybe we should have a meta ticket that tracks all .hyper/.race issues. Another
option would be to just close them all, but this will leave us without a good
list of tests that should be written.

On 2017-08-08 18:40:48, alex.jakime...@gmail.com wrote:
> Code:
> for .hyper { say 2 }
>
> Result (2015.09-2015.06):
> 2
> 2
> 2
>
> Result (9b0b9effe5,2017.07,HEAD(6745517)):
> (no output)
>
>
> There seems to be nothing wrong with using a for loop on .hyper or
> .race, so it should work. It starts working if you somehow use the
> value, for example:
>
> Code:
> do for .hyper { say 2 }
>
> Result (9b0b9effe5,2017.07,HEAD(6745517)):
> 2
> 2
> 2
>
>
> Bisectable points to
>
https://github.com/rakudo/rakudo/commit/9b0b9effe5fee1f35497cf97a5e7bda9bb083507

[perl #131877] [LTA] better error message for exit("hello")

[Aleks-Daniel Jakimenko-Aleksejev via RT]

There's a little problem with it. You see, right now this works:

exit "1"

So we simply cannot force it to do something else with Strs because that can
break existing (perfectly valid) code. We can go through a long deprecation
cycle but it's not worth it (IMO).

But it may be possible to catch X::Str::Numeric exception and print better
message for this situation… ¯\_(ツ)_/¯

On 2017-08-10 02:09:30, szab...@gmail.com wrote:
> In Python one can pass a string to the exit() function that will be
> displayed and the program exited.
>
>
> In Perl 6 I get:
>
> $ perl6
> To exit type 'exit' or '^D'
> > exit("hello")
> Cannot convert string to number: base-10 number must begin with valid
> digits or '.' in '⏏hello' (indicated by ⏏)
> in block  at  line 1
>
> Would it be possible to special case when someone passes a string to
> exit and give a better error message telling how to write that?
>
> Better yet, could exit accept a string?

[perl #131845] Binding a Seq to a `@` variable tries to consume it first

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Not sure if this info is relevant now, but the hang was introduced in
(2016-02-18)
https://github.com/rakudo/rakudo/commit/9983c2c8434ed81c532a5706996f284283b48d0a

On 2017-08-05 06:33:14, c...@zoffix.com wrote:
> Since Seq is not a Positional type, *binding* it to a `@` variable is
> typecheck error:
>
> 13:26 m: my @a := Seq.new: class :: does Iterator {method
> pull-one {IterationEnd}}.new;
> 13:26 camelia rakudo-moar abf1cf: OUTPUT: «Type check failed in
> binding; expected Positional but got Seq ($(().Seq))? in block 
> at  line 1??»
>
> However, it appears the code is trying to consume the entire Seq,
> before generating the error:
>
> 13:26 Zoffix m: my @a := Seq.new: class :: does Iterator {method
> pull-one {42}}.new; # hang
> 13:27 camelia rakudo-moar abf1cf: OUTPUT: «(timeout)»
> 13:31 Zoffix m: my @a := 1…?; # but this one has `is-lazy` set
> 13:31 camelia rakudo-moar abf1cf: OUTPUT: «Type check failed in
> binding; expected Positional but got Seq (?)? in block  at
>  line 1??»
>
>
> Perhaps it thinks it's gonna do assignment and consumes non-lazy Seqs
> in preparation for it, but then the binding happens and then it
> throws?

[perl #131003] [SEGV] Heap corruption when using Gumbo

[Aleks-Daniel Jakimenko-Aleksejev via RT]

FWIW, still happens after all changes during this month.

On 2017-07-22 16:21:30, alex.jakime...@gmail.com wrote:
> I bisected it to
>
https://github.com/rakudo/rakudo/commit/40a953f5d9f5c661d8cf9b043643002d348a2000
>
> On earlier rakudo versions it seems to be working fine. I haven't seen
> it crash
> once on anything earlier, but it is *very* slow on rakudos that old,
> so it's
> hard to tell.
>
> nqp changes:
>
> https://github.com/perl6/nqp/compare/2016.03-50-g512c9a1...2016.03-57-
> gbdb13a2
>
> moar changes:
> https://github.com/MoarVM/MoarVM/compare/2016.03-84-
> g4afd7b6...2016.03-104-g10d3971
>
> On 2017-05-13 17:00:08, alex.jakime...@gmail.com wrote:
> > FWIW the problem is still there and is reproducible with the provided
> > snippet
> > (just in case somebody is wondering if the issue went away by itself
> > after
> > these months).
> >
> > On 2017-04-04 06:46:20, scoli...@gmail.com wrote:
> > > Le Wed, 15 Mar 2017 17:12:00 -0700, alex.jakime...@gmail.com a
> > > écrit
> > > :
> > > > I am getting errors like:
> > > > MoarVM panic: Heap corruption detected: pointer 0x7f9a96a5e588 to
> > > > past
> > > > fromspace
> > > > MoarVM panic: Internal error: zeroed target thread ID in work
> > > > pass
> > > >
> > > > Even though it happens when I'm using Gumbo module, my best guess
> > > > is
> > > > that it is not its fault.
> > > >
> > > > Does not crash that fast with ｢perl6 --optimize=0 …｣, but crashes
> > > > anyway (you may want to bump up “^100” a little bit for this).
> > > >
> > > > Anyway, the code to replicate the issue is shown below. If it
> > > > gets
> > > > mangled for some reason, here is a mirror:
> > > > https://gist.github.com/AlexDaniel/ac7a4d4c49ec8d23e546529976dda67f
> > > >
> > > > #!/usr/bin/env perl6
> > > >
> > > > use Gumbo;
> > > > constant URL = ‘https://perl6.org/community/’;
> > > >
> > > > my $response = run(:out, ‘curl’, ‘-s’, URL).out.slurp-rest;
> > > > for ^100 {
> > > > .say for parse-html($response).root.elements(:TAG, :RECURSE);
> > > > }
> > > >
> > > > say ‘should've crashed before reaching this’;
> > >
> > > I was not able to reproduce it on a 32bit Virtual Machine (debian
> > > stable)
> > > Using 2016.11 rakudo and the latest from git.
> > > Maybe it can be related to how struct size are determined by
> > > MoarVM.
> > >

[perl #131805] [REGRESSION] [PERF] .grep-ing with a code block is now almost twice slower ( .grep({/foo/}) )

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Oh! You're totally right!

Then, it's not as bad as it looks.

In fact, this commit actually *improved* the case when it has to match Str-s
(more than 2x speedup).

So perhaps the slowdown is not so critical. After all, how often do people
match thousands of Ints…

On 2017-07-26 23:55:21, elizabeth wrote:
> Looking at the profile of
>
> (^1).grep({!/1/}).elems.say
>
> the first 5 entries (responsible for 70% of CPU in that example) have
> nothing to do with matching, but everything with trying to find the
> right dispatchee. And it looks like this is basically caused by:
>
> $_ = 1; /1/
>
> Because $_ contains an Int, this becomes a very slow path. Compare
> this with:
>
> (^1)>>.Str.grep({!/1/}).elems.say
>
> which is 3x faster, even when using a sub-optimal hyper.
>
> Investigating further...
>
> > On 27 Jul 2017, at 04:06, Aleks-Daniel Jakimenko-Aleksejev (via RT)
> > <perl6-bugs-follo...@perl.org> wrote:
> >
> > # New Ticket Created by Aleks-Daniel Jakimenko-Aleksejev
> > # Please include the string: [perl #131805]
> > # in the subject line of all future correspondence about this issue.
> > # https://rt.perl.org/Ticket/Display.html?id=131805 >
> >
> >
> > See this benchable6 output:
> > https://gist.github.com/Whateverable/6001c5744e3c877d76928d465de31e46
> >
> > If you look closely, benchable has not only built the graph across
> > all releases, but it also bisected the performance drop to the exact
> > commit. Here is that commit:
> >
https://github.com/rakudo/rakudo/commit/b7201a8f22338a906f2d8027a21387e8f5c77f41
> >
> > This was double-checked with committable6:
> >  c: b7201a8^,b7201a8 (^9).grep({!/1/}).elems.say; say
> > now - BEGIN now
> >  AlexDaniel, ¦b7201a8^: «59048␤5.0481256» ¦b7201a8:
> > «59048␤9.0262629»
> >
> > So it is ≈5 seconds before vs ≈9 seconds after. A significant
> > performance drop even if we assume possible bench noise.
> >
> > This was noticed because of this ticket:
> > https://github.com/perl6/doc/issues/1425
> >
> > See also IRC discussion: https://irclog.perlgeek.de/perl6/2017-07-
> > 27#i_14927626
> >
> > And maybe coverable output on HEAD if it may help you:
> > https://gist.github.com/Whateverable/f3db9e924cebe9b96a71a2b4cd67ae9c
> >
> > Note that whether it's {!/1/} or {/1/} doesn't really matter:
> > https://irclog.perlgeek.de/perl6/2017-07-27#i_14927789

[perl #131797] “expected:” and “got:” messages in test output .Str-ify data, that's not entirely right (cmp-ok ‘a’, ‘~~’, /b/)

[Aleks-Daniel Jakimenko-Aleksejev via RT]

".gist" is probably the wrong answer in this case.

my @got = ‘one’, ‘two three’; say @got # OUTPUT: [one two three]

↑ Not very useful

On 2017-07-25 12:52:25, alex.jakime...@gmail.com wrote:
> Sometimes it is useful to test the input against regexes. Let's try:
>
> Code:
> use Test;
> cmp-ok ‘foo’, ‘~~’, /bar/, ‘Lorem ipsum.’
>
> Result:
> not ok 1 - Lorem ipsum.
>
> # Failed test 'Lorem ipsum.'
> # at -e line 2
> Regex object coerced to string (please use .gist or .perl to do that)
> in sub cmp-ok at /home/…/…/C712FE6969F786C9380D643DF17E85D06868219E
> (Test) line 243
> # expected: ''
> # matcher: 'infix:<~~>'
> # got: 'foo'
>
>
> It “works”, but it attempts to turn a regex into a Str.
>
> The problem is here:
>
https://github.com/rakudo/rakudo/blob/90a0f2e09ef7a74bfb5a8295fa2737f22bd4e07f/lib/Test.pm6#L245-
> L247
>
> “.gist” should work better in this case, but I'm not sure if it will
> affect the output significantly in other cases…
>
>
> IRC discussion: https://irclog.perlgeek.de/perl6/2017-07-25#i_14920983
>
>
> I'm using regexes a lot for whateverable tests (e.g.
>
https://github.com/perl6/whateverable/blob/0301ef4bd2e88536b775db219d19084c092e24ca/t/evalable.t#L84-
> L88 ). Currently it is doing something completely different underneath
> (due to now-fixed RT #129192), I wanted to change it to regular cmp-
> ok.

[perl #131781] :?smth should construct a truthy pair (say (:?foo))

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Another interesting thing is that if this is implemented, then it will make it
possible to use ? in other places where  is used. For example, it
will allow %h:?exists . It seems that it will also affect character classes
(e.g. <:?Ll>). Some of these totally make sense, some not so much. But we
already have :!delete and nobody seems to be complaining :)

There's also  which has very similar logic, it does support ! but
does not support ? (e.g. m:!i/ … / but no m:?i/ … /). I wonder, if 
is ever touched, should the same thing be done with  also?

On 2017-07-22 23:40:53, alex.jakime...@gmail.com wrote:
> For those who don't agree that there is a connection between ? and !…
> Actually,
> there are some other places where ?↔! connection is implied. In fact,
> I will
> probably never list all of them.
>
> In regexes:
> *  always succeeds,  always fails (and no question implied)
> *   tests for truthy and falsey values. Note that <{}>
> does
> something completely different.
> * a+? is for non-greedy, a+! for greedy (again no question implied)
> * , ,  (note that all three are supported,
> same goes
> for )
>
>
>
> I would also do the job for the other side and provide some counter
> examples:
> * There is a ! metaop but no ? metaop (e.g. !== but no ?==). If there
> was one,
> it would practically be a noop because you wouldn't be able to use it
> on
> anything non-iffy anyway. That said, it's still a weird case.
> * There is [foo]? in regexes but no [foo]! . At first I thought that
> this is
> intentional, given that ! may be needed for something else eventually,
> but
> knowing that a+! works I'm no longer sure.
>
> This raises a question: well… should we implement these too? Maybe
> this: “If
> you’re gonna generalize, do it harder, but not too hard.”[^1] is
> relevant here,
> but maybe not.
>
> Bonus:
> * In some cases the use of ? or ! is not related to this issue at all.
> e.g.
> private methods (if we allow some things to have no opposites, why
> bother at
> all?)
>
>
> Anyway, that's some good food for thought I think.
>
> [1] https://perl6advent.wordpress.com/2014/12/24/day-24-seeing-wrong-
> right/

[perl #131781] :?smth should construct a truthy pair (say (:?foo))

[Aleks-Daniel Jakimenko-Aleksejev via RT]

For those who don't agree that there is a connection between ? and !… Actually,
there are some other places where ?↔! connection is implied. In fact, I will
probably never list all of them.

In regexes:
*  always succeeds,  always fails (and no question implied)
*   tests for truthy and falsey values. Note that <{}> does
something completely different.
* a+? is for non-greedy, a+! for greedy (again no question implied)
* , ,  (note that all three are supported, same goes
for )



I would also do the job for the other side and provide some counter examples:
* There is a ! metaop but no ? metaop (e.g. !== but no ?==). If there was one,
it would practically be a noop because you wouldn't be able to use it on
anything non-iffy anyway. That said, it's still a weird case.
* There is [foo]? in regexes but no [foo]! . At first I thought that this is
intentional, given that ! may be needed for something else eventually, but
knowing that a+! works I'm no longer sure.

This raises a question: well… should we implement these too? Maybe this: “If
you’re gonna generalize, do it harder, but not too hard.”[^1] is relevant here,
but maybe not.

Bonus:
* In some cases the use of ? or ! is not related to this issue at all. e.g.
private methods (if we allow some things to have no opposites, why bother at
all?)


Anyway, that's some good food for thought I think.

[1] https://perl6advent.wordpress.com/2014/12/24/day-24-seeing-wrong-right/

[perl #131781] :?smth should construct a truthy pair (say (:?foo))

[Aleks-Daniel Jakimenko-Aleksejev via RT]

“? doesn't imply truth it implies a question”

This is an interesting point actually. pmurias++ expressed the same idea.

I find it hard to understand this fully, but I guess I'll have to accept that
there are different ways to think about it :)

For example:
“The ? prefix asks an expression whether it's True or False”
If “?” asks a question, then what about “!” ? Well, let's say it aggressively
disagrees. Then we have optional and required parameters. ? is doubt and ! is a
demand? Ok. And then we have:
“‘:foo’ sets foo to True. ‘:!foo’ sets it to False”
Well, these are kinda arbitrary, and ! doesn't really follow the ideas
mentioned above.

And then we also have ?? !!, where again we have ? as kinda an opposite of !.

I think no matter which way you think about it, the emerging pattern seems to
be rather clear. And it does help to learn the language, at least it does help
me.

I mean, previously I said that we have only two precedents of ?↔!, but now
looking at ?? !! I think it follows the same pattern. Note, however, that I am
not saying that ? should be replaceable by ! anywhere, which the first answer
here implied for some reason. I'm mainly just saying that there is pattern and
the lack of :?foo syntax is an exception rather than a rule. From this many
other benefits can be derived, if needed.

I hope this clarifies it a bit.

On 2017-07-22 20:11:35, lloyd.fo...@gmail.com wrote:
> 2¢:
> ? doesn't imply truth it implies a question. The ? prefix asks an
> expression whether it's True or False. When used as a sigil like
> $?FILE
> it's asking the compiler about something.
>
> ‘:foo’ sets foo to True. ‘:!foo’ sets it to False. ‘:?foo’ looks like
> it's
> trying to ask something a question, but I'm not sure about what.
>
> On Sun, Jul 23, 2017 at 12:41 PM Aleks-Daniel Jakimenko-Aleksejev via
> RT <
> perl6-bugs-follo...@perl.org> wrote:

[perl #131781] :?smth should construct a truthy pair (say (:?foo))

[Aleks-Daniel Jakimenko-Aleksejev via RT]

For those reading this on RT, here's the previous comment in a readable way:

I wouldn't be so eager to judge the proposal based on the original post.
Sometimes I submit tickets fast, and sometimes ideas are not conveyed as
clearly as I assumed.

“How are those things related?”
These were the examples of the pair syntax (what works and what doesn't). Now,
?↔! pattern is strangely established by at least two precedents:
* ? and ! prefix ops (e.g. !42 or ?42)
* Optional and required parameters (e.g. $foo?, $bar!, :$baz?, :$cat!)

Check out irc logs for more discussion.

[perl #131781] :?smth should construct a truthy pair (say (:?foo))

[Aleks-Daniel Jakimenko-Aleksejev via RT]

I wouldn't be so eager to judge the proposal based on the original post.
Sometimes I submit tickets fast, and sometimes ideas are not conveyed as
clearly as I assumed.

“How are those things related?”
These were the examples of the pair syntax (what works and what doesn't). Now,
?↔! pattern is strangely established by at least two precedents:
* ? and ! prefix ops (e.g. !42 or ?42)
* Optional and required parameters (e.g. $foo?, $bar!, :$baz?, :$cat!)

Check out irc logs for more discussion.

On 2017-07-22 21:50:58, duff wrote:
> The OP said :?foo should work because :foo and :!foo work. I don't
> follow
> the logic. How are those things related? Why should :foo and :!foo
> imply
> :?foo? (In my head it makes as much sense as ":foo and :!foo implies
> :*foo", which is to say, none.)
>
> I don't see any benefit to adding a :?foo syntax that means exactly
> the
> same thing as :foo. I also don't see how it increases or improves
> consistency (strangely or otherwise). That it could be implemented
> quickly
> or easily is irrelevant.
>
> So ... -1 for me too.
>
> -Scott
>
>
> On Sat, Jul 22, 2017 at 10:11 PM, Lloyd Fournier via RT <
> perl6-bugs-follo...@perl.org> wrote:
>
> > 2¢:
> > ? doesn't imply truth it implies a question. The ? prefix asks an
> > expression whether it's True or False. When used as a sigil like
> > $?FILE
> > it's asking the compiler about something.
> >
> > ‘:foo’ sets foo to True. ‘:!foo’ sets it to False. ‘:?foo’ looks like
> > it's
> > trying to ask something a question, but I'm not sure about what.
> >
> > On Sun, Jul 23, 2017 at 12:41 PM Aleks-Daniel Jakimenko-Aleksejev via
> > RT <
> > perl6-bugs-follo...@perl.org> wrote:
> >
> > > Yes, I should have been more clear.
> > >
> > > Basically, it should work like (:foo) does, which is construct foo
> > > =>
> > True
> > > pair.
> > >
> > > On 2017-07-22 19:25:19, lloyd.fo...@gmail.com wrote:
> > > > Sorry for being think but what is
> > > > say (:?foo);
> > > > meant to do? The OP just says it should "work".
> > > >
> > > > On Sun, Jul 23, 2017 at 6:05 AM Aleks-Daniel Jakimenko-Aleksejev
> > > > via
> > > > RT <
> > > > perl6-bugs-follo...@perl.org> wrote:
> > > >
> > > > > sub foo($bar!) { say $bar }; foo(42)
> > > > >
> > > > > On 2017-07-22 11:19:41, alex.jakime...@gmail.com wrote:
> > > > > > Eh. The effort required to implement the feature is much less
> > > > > > than
> > > > > > having
> > > > > > discussions *like this*. I'll try to be quick.
> > > > > >
> > > > > > “there's large possibility of introducing some unwanted
> > > > > > ambiguity
> > > > > > somewhere”
> > > > > >
> > > > > > A good thing to keep in mind indeed.
> > > > > >
> > > > > > I don't really like these discussions before actual PRs, but
> > > > > > if we
> > > > > > think about
> > > > > > it a little bit…
> > > > > >
> > > > > >  panics if it finds :! but then fails to find
> > > > > > 
> > > > > > (
> > > > > >
> > > > >
> > > > >
> > >
> > > https://github.com/rakudo/rakudo/blob/fb7ecb60f006b5738bfe7a234535e0
> > 7344268b31/src/Perl6/Grammar.nqp#L1892
> > > > > > ), so if there is any ambiguity introduced, then it's not
> > > > > > bigger
> > > > > > than
> > > > > > what we
> > > > > > have with :! already.
> > > > > >
> > > > > > I've tried ::!CLASS and it complains about private method
> > > > > > !CLASS.
> > > > > >
> > > > > > :?foo itself says “Confused … expecting any of: colon pair”,
> > > > > > so it
> > > > > > expects a
> > > > > > colon pair anyway.
> > > > > >
> > > > > > Maybe you have some good examples, but *so far* looks ok.
> > > > > >
> > > > > >
> > > > > > “complex syntax feature”
> > > > > >
> > > > > > Let's make this complex feature strangely consistent.
> > > > > >
> > > > > >
> > > >

[perl #131781] :?smth should construct a truthy pair (say (:?foo))

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Yes, I should have been more clear.

Basically, it should work like (:foo) does, which is construct foo => True
pair.

On 2017-07-22 19:25:19, lloyd.fo...@gmail.com wrote:
> Sorry for being think but what is
> say (:?foo);
> meant to do? The OP just says it should "work".
>
> On Sun, Jul 23, 2017 at 6:05 AM Aleks-Daniel Jakimenko-Aleksejev via
> RT <
> perl6-bugs-follo...@perl.org> wrote:
>
> > sub foo($bar!) { say $bar }; foo(42)
> >
> > On 2017-07-22 11:19:41, alex.jakime...@gmail.com wrote:
> > > Eh. The effort required to implement the feature is much less than
> > > having
> > > discussions *like this*. I'll try to be quick.
> > >
> > > “there's large possibility of introducing some unwanted ambiguity
> > > somewhere”
> > >
> > > A good thing to keep in mind indeed.
> > >
> > > I don't really like these discussions before actual PRs, but if we
> > > think about
> > > it a little bit…
> > >
> > >  panics if it finds :! but then fails to find
> > > 
> > > (
> > >
> >
> >
https://github.com/rakudo/rakudo/blob/fb7ecb60f006b5738bfe7a234535e07344268b31/src/Perl6/Grammar.nqp#L1892
> > > ), so if there is any ambiguity introduced, then it's not bigger
> > > than
> > > what we
> > > have with :! already.
> > >
> > > I've tried ::!CLASS and it complains about private method !CLASS.
> > >
> > > :?foo itself says “Confused … expecting any of: colon pair”, so it
> > > expects a
> > > colon pair anyway.
> > >
> > > Maybe you have some good examples, but *so far* looks ok.
> > >
> > >
> > > “complex syntax feature”
> > >
> > > Let's make this complex feature strangely consistent.
> > >
> > >
> > > “OP came up[^1] with this idea while trying to think of more cases
> > > to
> > > add to
> > > the catalog of colon uses in Rakudo”
> > >
> > > Why does this sound so bad? :) Does it really matter at what point
> > > I
> > > noticed
> > > that the feature that I always thought was implemented actually
> > > isn't?
> > > I don't
> > > use colonpairs as often, truthy or falsy, so never noticed before.
> > >
> > > However, even the fact that :!foo does not align vertically with
> > > :bar
> > > is enough
> > > to convince me regarding the usefulness of the proposed feature.
> > >
> > >
> > > “But if we follow that logic, it'd mean:”
> > >
> > > What I meant was that we can make it strangely consistent in a
> > > useful
> > > way. Then
> > > you extrapolated it to unbelievable extents.
> > >
> > > Then there are examples that are totally unrelated to the ticket.
> > > Even
> > > ?? !! is
> > > not in any way strangely consistent (you can't write else { } if {
> > > }).
> > >
> > >
> > > I like this definition a lot:
> > >
> > >  "strangely consistent" is all about using loose connections
> > > people have
> > > in their brains, so that a feature feels syntactically vaguely
> > > right
> > > for
> > > various reasons.
> > >
> > >
> > > This ticket is not about making colonpairs accept prefix operators.
> > > It
> > > is also
> > > not about being able to syntactically put ? anywhere you can put !.
> > > And let's
> > > also not bring unrelated stuff here (like colonpairs only accepting
> > > natural
> > > numbers with *no sign* whatsoever). What kind of derailing kung fu
> > > is
> > > this
> > > anyway?
> > >
> > >
> > > On 2017-07-22 09:12:31, c...@zoffix.com wrote:
> > > > On Sat, 22 Jul 2017 07:53:26 -0700, alex.jakime...@gmail.com
> > > > wrote:
> > > > > This should work:
> > > > >
> > > > > Code:
> > > > > say (:?foo);
> > > > >
> > > > > Result:
> > > > > ===SORRY!=== Error while compiling -e
> > > > > Bogus statement
> > > > > at -e:1
> > > > > --> say (:⏏?foo);
> > > > > expecting any of:
> > > > > colon pair
> > > > >
> > > > >
> > > > > Because these work:
> > > > >
> > > > > Code:
> > > > > say (:foo);
>

[perl #131783] [LTA] :delete holes in Arrays get turned to Mus when coercing to List or Slip

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Perhaps also worth noting that this applies to other holes as well, e.g. those
created by extending an array:

my @a = 42; @a[5] = 49; say |@a # 42(Mu)(Mu)(Mu)(Mu)49

In fact, this the actual problem the user had.

On 2017-07-22 18:52:03, c...@zoffix.com wrote:
> On Sat, 22 Jul 2017 18:48:38 -0700, c...@zoffix.com wrote:
> > The current behaviour kinda makes sense when you squint at it, but
> > today we had a user[^1]who was surprised by it, so I'm filing it as a
> > ticket, if maybe there's some Better Way this can be done with.
> >
> > When you :delete an element from the Array, you get nqp::null stuffed
> > into the position, which gets converted to `is default` value when
> > you
> > look it up again:
> >
> >  m: use nqp; my @a is default(42) = ; @a[1]:delete;
> > dd @a
> >  rakudo-moar b14721: OUTPUT: «Array @a = ["a", 42, "c"]␤»
> >
> > However, if you now convert that Array to a Slip or a List, the hole
> > is left as a bare Mu and doesn't get turned into a default value,
> > which is lost:
> >
> >  m: use nqp; my @a is default(42) = ; @a[1]:delete;
> > dd @a.Slip
> >  rakudo-moar b14721: OUTPUT: «slip("a", Mu, "c")␤»
> >
> >  m: use nqp; my @a is default(42) = ; @a[1]:delete;
> > dd @a.List
> >  rakudo-moar b14721: OUTPUT: «("a", Mu, "c")␤»
> >
> > So it makes sense that without `is default` you don't get an `is
> > default` value, but at the same time, Mu is not a great value to deal
> > with...
> >
> > [1] https://irclog.perlgeek.de/perl6/2017-07-22#i_14908846
>
>
> And actually both .flat and .Seq do get `is default` value instead of
> Mu, so at the very least there's some inconsistency here:
>
>  m: use nqp; my @a is default(42) = ; @a[1]:delete;
> dd @a.flat
>  rakudo-moar b14721: OUTPUT: «("a", 42, "c").Seq␤»
>  m: use nqp; my @a is default(42) = ; @a[1]:delete;
> dd @a.Seq
>  rakudo-moar b14721: OUTPUT: «("a", 42, "c").Seq␤»

[perl #131003] [SEGV] Heap corruption when using Gumbo

[Aleks-Daniel Jakimenko-Aleksejev via RT]

I bisected it to
https://github.com/rakudo/rakudo/commit/40a953f5d9f5c661d8cf9b043643002d348a2000

On earlier rakudo versions it seems to be working fine. I haven't seen it crash
once on anything earlier, but it is *very* slow on rakudos that old, so it's
hard to tell.

nqp changes:

https://github.com/perl6/nqp/compare/2016.03-50-g512c9a1...2016.03-57-gbdb13a2

moar changes:
https://github.com/MoarVM/MoarVM/compare/2016.03-84-g4afd7b6...2016.03-104-g10d3971

On 2017-05-13 17:00:08, alex.jakime...@gmail.com wrote:
> FWIW the problem is still there and is reproducible with the provided
> snippet
> (just in case somebody is wondering if the issue went away by itself
> after
> these months).
>
> On 2017-04-04 06:46:20, scoli...@gmail.com wrote:
> > Le Wed, 15 Mar 2017 17:12:00 -0700, alex.jakime...@gmail.com a écrit
> > :
> > > I am getting errors like:
> > > MoarVM panic: Heap corruption detected: pointer 0x7f9a96a5e588 to
> > > past
> > > fromspace
> > > MoarVM panic: Internal error: zeroed target thread ID in work pass
> > >
> > > Even though it happens when I'm using Gumbo module, my best guess
> > > is
> > > that it is not its fault.
> > >
> > > Does not crash that fast with ｢perl6 --optimize=0 …｣, but crashes
> > > anyway (you may want to bump up “^100” a little bit for this).
> > >
> > > Anyway, the code to replicate the issue is shown below. If it gets
> > > mangled for some reason, here is a mirror:
> > > https://gist.github.com/AlexDaniel/ac7a4d4c49ec8d23e546529976dda67f
> > >
> > > #!/usr/bin/env perl6
> > >
> > > use Gumbo;
> > > constant URL = ‘https://perl6.org/community/’;
> > >
> > > my $response = run(:out, ‘curl’, ‘-s’, URL).out.slurp-rest;
> > > for ^100 {
> > > .say for parse-html($response).root.elements(:TAG, :RECURSE);
> > > }
> > >
> > > say ‘should've crashed before reaching this’;
> >
> > I was not able to reproduce it on a 32bit Virtual Machine (debian
> > stable)
> > Using 2016.11 rakudo and the latest from git.
> > Maybe it can be related to how struct size are determined by MoarVM.
> >

[perl #130285] [REGRESSION] Unhealthy overflow in .head and .tail with huge negative numbers ( (4,5,6).tail(-9999999999999999999) )

[Aleks-Daniel Jakimenko-Aleksejev via RT]

I'm not sure if this is closable. The regression is no longer there, so I'll
remove the tag, but here's a problem:

Code:
say (4,5,6).tail(-2**63+4)

Result:
()


Code:
say (4,5,6,7).tail(-2**63+4)

Result:
Cannot unbox 64 bit wide bigint into native integer
in block  at -e line 1


It feels like something is wrong? I am not sure.


On 2017-07-22 12:44:53, elizabeth wrote:
> I’m inclined to WONTFIX, as other, much more common, indexing
> operation suffer from the same issue:
>
> $ 6 'my @a; say @a[999]'
> Cannot unbox 64 bit wide bigint into native integer
>
> $ 6 'my @a[999]'
> Illegal dimension in shape: 999. All dimensions must
> be integers bigger than 0
>
> etc etc etc.
>
> > On 7 Dec 2016, at 01:37, Aleks-Daniel Jakimenko-Aleksejev (via RT)
> > <perl6-bugs-follo...@perl.org> wrote:
> >
> > # New Ticket Created by Aleks-Daniel Jakimenko-Aleksejev
> > # Please include the string: [perl #130285]
> > # in the subject line of all future correspondence about this issue.
> > # https://rt.perl.org/Ticket/Display.html?id=130285 >
> >
> >
> > Code:
> > say (4,5,6).tail(-999)
> >
> > Result HEAD:
> > MoarVM panic: Memory allocation failed; could not allocate
> > 12233720368547758088 bytes
> >
> > Result (2016.09):
> > ()
> >
> >
> > Code:
> > say (4,5,6).head(-999)
> >
> > Result HEAD:
> > (4 5 6)
> >
> > Result (2016.09):
> > ()
> >
> >
> > Bisectable points to these commits:
> > *
> >
https://github.com/rakudo/rakudo/commit/a3406cba841cd9ecdd3bda49b9a415381615961c
> > *
> >
https://github.com/rakudo/rakudo/commit/6996512e3c994fafa2d34e8c5c9bf9d25f0a0810

[perl #131781] :?smth should construct a truthy pair (say (:?foo))

[Aleks-Daniel Jakimenko-Aleksejev via RT]

sub foo($bar!) { say $bar }; foo(42)

On 2017-07-22 11:19:41, alex.jakime...@gmail.com wrote:
> Eh. The effort required to implement the feature is much less than
> having
> discussions *like this*. I'll try to be quick.
>
> “there's large possibility of introducing some unwanted ambiguity
> somewhere”
>
> A good thing to keep in mind indeed.
>
> I don't really like these discussions before actual PRs, but if we
> think about
> it a little bit…
>
>  panics if it finds :! but then fails to find 
> (
>
https://github.com/rakudo/rakudo/blob/fb7ecb60f006b5738bfe7a234535e07344268b31/src/Perl6/Grammar.nqp#L1892
> ), so if there is any ambiguity introduced, then it's not bigger than
> what we
> have with :! already.
>
> I've tried ::!CLASS and it complains about private method !CLASS.
>
> :?foo itself says “Confused … expecting any of: colon pair”, so it
> expects a
> colon pair anyway.
>
> Maybe you have some good examples, but *so far* looks ok.
>
>
> “complex syntax feature”
>
> Let's make this complex feature strangely consistent.
>
>
> “OP came up[^1] with this idea while trying to think of more cases to
> add to
> the catalog of colon uses in Rakudo”
>
> Why does this sound so bad? :) Does it really matter at what point I
> noticed
> that the feature that I always thought was implemented actually isn't?
> I don't
> use colonpairs as often, truthy or falsy, so never noticed before.
>
> However, even the fact that :!foo does not align vertically with :bar
> is enough
> to convince me regarding the usefulness of the proposed feature.
>
>
> “But if we follow that logic, it'd mean:”
>
> What I meant was that we can make it strangely consistent in a useful
> way. Then
> you extrapolated it to unbelievable extents.
>
> Then there are examples that are totally unrelated to the ticket. Even
> ?? !! is
> not in any way strangely consistent (you can't write else { } if { }).
>
>
> I like this definition a lot:
>
>  "strangely consistent" is all about using loose connections
> people have
> in their brains, so that a feature feels syntactically vaguely right
> for
> various reasons.
>
>
> This ticket is not about making colonpairs accept prefix operators. It
> is also
> not about being able to syntactically put ? anywhere you can put !.
> And let's
> also not bring unrelated stuff here (like colonpairs only accepting
> natural
> numbers with *no sign* whatsoever). What kind of derailing kung fu is
> this
> anyway?
>
>
> On 2017-07-22 09:12:31, c...@zoffix.com wrote:
> > On Sat, 22 Jul 2017 07:53:26 -0700, alex.jakime...@gmail.com wrote:
> > > This should work:
> > >
> > > Code:
> > > say (:?foo);
> > >
> > > Result:
> > > ===SORRY!=== Error while compiling -e
> > > Bogus statement
> > > at -e:1
> > > --> say (:⏏?foo);
> > > expecting any of:
> > > colon pair
> > >
> > >
> > > Because these work:
> > >
> > > Code:
> > > say (:foo);
> > > say (:!foo);
> > >
> > > Result:
> > > foo => True
> > > foo => False
> >
> >
> > -1 from me:
> >
> > 1) Colonpairs are ubiquitous in the language, so there's large
> > possibility of introducing some unwanted ambiguity somewhere and it's
> > hard to predict where it might occur
> > 2) Colonpairs are already one of the most complex syntax feature of
> > the language, requiring beginners to learn a wealth of syntax to
> > understand most of the common code.
> > 3) Given (1) and (2), I'd expect any changes to extend their syntax
> > to
> > carry large benefits, however, the proposal offers literally zero
> > practical use and the OP came up[^1] with this idea while trying to
> > think of more cases to add to the catalog of colon uses in Rakudo.
> > The
> > `?` prefix op at least coerces the already-true arg to Bool (e.g.
> > `?"foo" === True`) but in the case of the colonpair, there's nothing
> > to coerce, so there's absolutely no point in typing the extra `?` and
> > it's unlikely anyone would want to type it.
> > 4) The OP makes the case that this syntax should exist solely for the
> > sake of consistency, by interpreting the `!` in `:!foo` syntax to
> > mean
> > the `!` op, and there exists the `?` op. But if we follow that logic,
> > it'd mean:
> > *) `!! ??` should be allowed too, to mean reverse ternary
> > *) `::!CLASS` should mean `anything but ::?CLASS`
> > *) `has $?foo` should be an alternative to `has $!foo`
> > *) `self?foo` should be an alternative to `self!foo`
> > *) `:-42foo` should parse just as `:42foo` parses
> > The point being that the current syntax is `":"` vs `":!"` not `":"`
> > vs `":" + some op`. And things that have "!" in them do not
> > necessarily need to have a "?" alternative.
> >
> > In summation, there's no practical use of this feature and it is
> > unlikely it'll ever be used in real programs. The colonpair syntax is
> > used across the entire language and any changes to it have large
> > impact. It's very hard to anticipate any problematic ambiguity cases
> > introduction of `?` into colon syntax might have. And given lack of
> > technical 

[perl #131781] :?smth should construct a truthy pair (say (:?foo))

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Eh. The effort required to implement the feature is much less than having
discussions *like this*. I'll try to be quick.

“there's large possibility of introducing some unwanted ambiguity somewhere”

A good thing to keep in mind indeed.

I don't really like these discussions before actual PRs, but if we think about
it a little bit…

 panics if it finds :! but then fails to find  (
https://github.com/rakudo/rakudo/blob/fb7ecb60f006b5738bfe7a234535e07344268b31/src/Perl6/Grammar.nqp#L1892
), so if there is any ambiguity introduced, then it's not bigger than what we
have with :! already.

I've tried ::!CLASS and it complains about private method !CLASS.

:?foo itself says “Confused … expecting any of: colon pair”, so it expects a
colon pair anyway.

Maybe you have some good examples, but *so far* looks ok.


“complex syntax feature”

Let's make this complex feature strangely consistent.


“OP came up[^1] with this idea while trying to think of more cases to add to
the catalog of colon uses in Rakudo”

Why does this sound so bad? :) Does it really matter at what point I noticed
that the feature that I always thought was implemented actually isn't? I don't
use colonpairs as often, truthy or falsy, so never noticed before.

However, even the fact that :!foo does not align vertically with :bar is enough
to convince me regarding the usefulness of the proposed feature.


“But if we follow that logic, it'd mean:”

What I meant was that we can make it strangely consistent in a useful way. Then
you extrapolated it to unbelievable extents.

Then there are examples that are totally unrelated to the ticket. Even ?? !! is
not in any way strangely consistent (you can't write else { } if { }).


I like this definition a lot:

 "strangely consistent" is all about using loose connections people have
in their brains, so that a feature feels syntactically vaguely right for
various reasons.


This ticket is not about making colonpairs accept prefix operators. It is also
not about being able to syntactically put ? anywhere you can put !. And let's
also not bring unrelated stuff here (like colonpairs only accepting natural
numbers with *no sign* whatsoever). What kind of derailing kung fu is this
anyway?


On 2017-07-22 09:12:31, c...@zoffix.com wrote:
> On Sat, 22 Jul 2017 07:53:26 -0700, alex.jakime...@gmail.com wrote:
> > This should work:
> >
> > Code:
> > say (:?foo);
> >
> > Result:
> > ===SORRY!=== Error while compiling -e
> > Bogus statement
> > at -e:1
> > --> say (:⏏?foo);
> > expecting any of:
> > colon pair
> >
> >
> > Because these work:
> >
> > Code:
> > say (:foo);
> > say (:!foo);
> >
> > Result:
> > foo => True
> > foo => False
>
>
> -1 from me:
>
> 1) Colonpairs are ubiquitous in the language, so there's large
> possibility of introducing some unwanted ambiguity somewhere and it's
> hard to predict where it might occur
> 2) Colonpairs are already one of the most complex syntax feature of
> the language, requiring beginners to learn a wealth of syntax to
> understand most of the common code.
> 3) Given (1) and (2), I'd expect any changes to extend their syntax to
> carry large benefits, however, the proposal offers literally zero
> practical use and the OP came up[^1] with this idea while trying to
> think of more cases to add to the catalog of colon uses in Rakudo. The
> `?` prefix op at least coerces the already-true arg to Bool (e.g.
> `?"foo" === True`) but in the case of the colonpair, there's nothing
> to coerce, so there's absolutely no point in typing the extra `?` and
> it's unlikely anyone would want to type it.
> 4) The OP makes the case that this syntax should exist solely for the
> sake of consistency, by interpreting the `!` in `:!foo` syntax to mean
> the `!` op, and there exists the `?` op. But if we follow that logic,
> it'd mean:
> *) `!! ??` should be allowed too, to mean reverse ternary
> *) `::!CLASS` should mean `anything but ::?CLASS`
> *) `has $?foo` should be an alternative to `has $!foo`
> *) `self?foo` should be an alternative to `self!foo`
> *) `:-42foo` should parse just as `:42foo` parses
> The point being that the current syntax is `":"` vs `":!"` not `":"`
> vs `":" + some op`. And things that have "!" in them do not
> necessarily need to have a "?" alternative.
>
> In summation, there's no practical use of this feature and it is
> unlikely it'll ever be used in real programs. The colonpair syntax is
> used across the entire language and any changes to it have large
> impact. It's very hard to anticipate any problematic ambiguity cases
> introduction of `?` into colon syntax might have. And given lack of
> technical benefits of this feature, I do not think we should accept
> the risks.
>
>
> [1] https://irclog.perlgeek.de/perl6/2017-07-22#i_14907647

[perl #126642] [BUG] UInt:D parameter fails in a multi

[Aleks-Daniel Jakimenko-Aleksejev via RT]

A test was added in
https://github.com/perl6/roast/commit/84e5309567a5f3ee0d1d7450e08225119b08f3af

dogbert17++
On 2017-07-21 12:46:12, jan-olof.hen...@bredband.net wrote:
> On Sat, 14 Nov 2015 14:06:52 -0800, grond...@yahoo.fr wrote:
> > $ perl6 --version
> > This is perl6 version 2015.10-294-gcc1ba30 built on MoarVM version
> > 2015.10-92-g0181385
> >
> > $ perl6 -e 'multi f(UInt:D $) { say "ok" }; f(1);'
> > ===SORRY!===
> > Invocant requires an instance of type Int, but a type object was
> > passed.
> > Did you forget a .new?
> >
> > See also IRC log for this day.
>
> This was fixed with
>
https://github.com/rakudo/rakudo/commit/68afa3f1e77862e4b61f9946103047103fff3c2c.
> I'm not sure if the tests in S12-subset/subtypes.t covers this, if
> they do then this issue should be
> closed.

[perl #131780] [Double Free] Crash while running test

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Is there any code snippet to reproduce it?

The backtrace mentions mongo-perl6-driver…

On 2017-07-22 02:38:03, mt1...@gmail.com wrote:
> Test code erred in perl6 version 2017.07-31-g895bdc8 built on MoarVM
> version 2017.07.
>
> Regards,
> Marcel
>
>
> The crash dump;
>
>
> *** Error in `/home/marcel/Software/perl6/rakudo/install/bin/moar':
> double free or corruption (out): 0x7f84b8453a90 ***
> === Backtrace: =
> /lib64/libc.so.6(+0x7570b)[0x7f84ef7c570b]
> /lib64/libc.so.6(+0x7deaa)[0x7f84ef7cdeaa]
> /lib64/libc.so.6(cfree+0x4c)[0x7f84ef7d140c]
>
//home/marcel/Software/perl6/rakudo/install/lib/libmoar.so(MVM_frame_destroy+0x3d)[0x7f84efc9f38d]
>
//home/marcel/Software/perl6/rakudo/install/lib/libmoar.so(MVM_gc_collect_free_nursery_uncopied+0x9b)[0x7f84efcbbeeb]
>
//home/marcel/Software/perl6/rakudo/install/lib/libmoar.so(+0x1a5d4f)[0x7f84efcb7d4f]
>
//home/marcel/Software/perl6/rakudo/install/lib/libmoar.so(MVM_gc_enter_from_allocator+0x341)[0x7f84efcb85e1]
>
//home/marcel/Software/perl6/rakudo/install/lib/libmoar.so(MVM_gc_allocate_nursery+0x38)[0x7f84efcb87d8]
>
//home/marcel/Software/perl6/rakudo/install/lib/libmoar.so(MVM_gc_allocate_frame+0xe)[0x7f84efcb8a9e]
>
//home/marcel/Software/perl6/rakudo/install/lib/libmoar.so(MVM_frame_force_to_heap+0xd0)[0x7f84efc9f650]
>
//home/marcel/Software/perl6/rakudo/install/lib/libmoar.so(MVM_nativeref_lex_i+0x20)[0x7f84efced7d0]
>
//home/marcel/Software/perl6/rakudo/install/lib/libmoar.so(MVM_interp_run+0x5566)[0x7f84efc8be56]
>
//home/marcel/Software/perl6/rakudo/install/lib/libmoar.so(MVM_vm_run_file+0xa9)[0x7f84efd511c9]
> /home/marcel/Software/perl6/rakudo/install/bin/moar[0x4010af]
> /lib64/libc.so.6(__libc_start_main+0xf1)[0x7f84ef770731]
> /home/marcel/Software/perl6/rakudo/install/bin/moar[0x401119]
> === Memory map: 
> 0040-00402000 r-xp  08:09 41291465
> /home/marcel/Software/perl6/rakudo/install/bin/moar
> 00601000-00602000 r--p 1000 08:09 41291465
> /home/marcel/Software/perl6/rakudo/install/bin/moar
> 00602000-00603000 rw-p 2000 08:09 41291465
> /home/marcel/Software/perl6/rakudo/install/bin/moar
> 006c9000-0dc68000 rw-p  00:00
> 0
> [heap]
> 7f849400-7f849409b000 rw-p  00:00 0
> 7f849409b000-7f849800 ---p  00:00 0
> 7f849800-7f8498021000 rw-p  00:00 0
> 7f8498021000-7f849c00 ---p  00:00 0
> 7f849c00-7f849c117000 rw-p  00:00 0
> 7f849c117000-7f84a000 ---p  00:00 0
> 7f84a11e-7f84a11f6000 r-xp  08:08 1313028
> /usr/lib64/libgcc_s-6.3.1-20161221.so.1
> 7f84a11f6000-7f84a13f5000 ---p 00016000 08:08 1313028
> /usr/lib64/libgcc_s-6.3.1-20161221.so.1
> 7f84a13f5000-7f84a13f6000 r--p 00015000 08:08 1313028
> /usr/lib64/libgcc_s-6.3.1-20161221.so.1
> 7f84a13f6000-7f84a13f7000 rw-p 00016000 08:08 1313028
> /usr/lib64/libgcc_s-6.3.1-20161221.so.1
> 7f84a13f7000-7f84a13f8000 ---p  00:00 0
> 7f84a13f8000-7f84a1bf8000 rwxp  00:00 0
> 7f84a1bf8000-7f84a1bf9000 ---p  00:00 0
> 7f84a1bf9000-7f84a23f9000 rwxp  00:00 0
> 7f84a23f9000-7f84a400 rw-p  00:00 0
> 7f84a400-7f84a41dc000 rw-p  00:00 0
> 7f84a41dc000-7f84a800 ---p  00:00 0
> 7f84a800-7f84a80c2000 rw-p  00:00 0
> 7f84a80c2000-7f84ac00 ---p  00:00 0
> 7f84ac00-7f84ac0f3000 rw-p  00:00 0
> 7f84ac0f3000-7f84b000 ---p  00:00 0
> 7f84b000-7f84b0087000 rw-p  00:00 0
> 7f84b0087000-7f84b400 ---p  00:00 0
> 7f84b41ac000-7f84b41ad000 rw-p  00:00 0
> 7f84b41ad000-7f84b41e2000 r-xp  00:00 0
> 7f84b41e2000-7f84b41ed000 r-xp  08:08
> 1339569
> /usr/lib64/libnss_files-2.23.so
> 7f84b41ed000-7f84b43ec000 ---p b000 08:08
> 1339569
> /usr/lib64/libnss_files-2.23.so
> 7f84b43ec000-7f84b43ed000 r--p a000 08:08
> 1339569
> /usr/lib64/libnss_files-2.23.so
> 7f84b43ed000-7f84b43ee000 rw-p b000 08:08
> 1339569
> /usr/lib64/libnss_files-2.23.so
> 7f84b43ee000-7f84b5bfa000 rw-p  00:00 0
> 7f84b5bfa000-7f84b5bfb000 ---p  00:00 0
> 7f84b5bfb000-7f84b63fb000 rwxp  00:00 0
> 7f84b63fb000-7f84b67fc000 rw-p  00:00 0
> 7f84b67fc000-7f84b67fd000 ---p  00:00 0
> 7f84b67fd000-7f84b6ffd000 rwxp  00:00 0
> 7f84b6ffd000-7f84b73fe000 rw-p  00:00 0
> 7f84b73fe000-7f84b73ff000 ---p  00:00 0
> 7f84b73ff000-7f84b7bff000 rwxp  00:00 0
> 7f84b7bff000-7f84b800 rw-p  00:00 0
> 7f84b800-7f84b849d000 rw-p  00:00 0
> 7f84b849d000-7f84bc00 ---p  00:00 0
> 7f84bc00-7f84bc0bc000 rw-p  00:00 0
> 7f84bc0bc000-7f84c000 ---p  00:00 0
> 7f84c000-7f84c00c8000 rw-p  00:00 0
> 7f84c00c8000-7f84c400 ---p  00:00 0
> 7f84c400-7f84c46ea000 rw-p  00:00 0
> 7f84c46ea000-7f84c800 ---p  00:00 0
> 7f84c800-7f84c810 rw-p  00:00 0
> 7f84c810-7f84cc00 ---p  00:00 

[perl #131764] Passing stdin to Proc::Async mostly does not work ($proc.print: …; $proc.close-stdin)

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Alright, it seems that rakudo is not entirely incorrect here. See this
discussion: https://irclog.perlgeek.de/perl6-dev/2017-07-18#i_14885863

TL;DR, one should use something like this:

whenever $proc.print(“one\ntwo\nthree\nfour”) { $proc.close-stdin }

So it seems that it's not a bug, but a trap maybe?

I'll leave this for somebody else to close.

On 2017-07-17 22:45:01, alex.jakime...@gmail.com wrote:
> Code:
>
> sub get-output() {
> my $proc = Proc::Async.new: :w, ‘head’, ‘-n’, ‘1’;
> my $success;
> react {
> whenever $proc.stdout { $success = True }
> whenever $proc.start { die ‘FAIL!’ unless $success }
>
> $proc.print: “one\ntwo\nthree\nfour”;
> $proc.close-stdin;
> }
> say $++;
> }
>
> loop { get-output }
>
>
> Again, the result depends on your luck. Ideally it should not “die”
> ever, because there should always be one line in the output and
> therefore $success will be set to true. However, sometimes its stdout
> is empty and therefore it fails. It may fail after 20+ executions, and
> sometimes it fails almost immediately.
>
> Related ticket: https://rt.perl.org/Ticket/Display.html?id=131763

[perl #131757] Untodoed evil hack in Backtrace.pm

[Aleks-Daniel Jakimenko-Aleksejev via RT]

I think the purpose of the ticket was stated clearly in the first message.

Feel free to change the comment in the source code to “This is a hack but
there's no point to improve it” and close the ticket.

To me it felt like the intention was to improve this part later, but no TODO
comment was left, so we have this ticket. If I am being wrong, then yeah.

On 2017-07-17 09:18:29, c...@zoffix.com wrote:
> On Mon, 17 Jul 2017 08:33:12 -0700, alex.jakime...@gmail.com wrote:
> > I don't think this ticket needs so much discussion… It's basically
> > about
> > implementing the damn thing properly (and coming up with a way to do
> > it along
> > the way).
>
> What problems does the current implementation have? What problem is
> the ticket wishes to be solved?

[perl #131757] Untodoed evil hack in Backtrace.pm

[Aleks-Daniel Jakimenko-Aleksejev via RT]

I don't think this ticket needs so much discussion… It's basically about
implementing the damn thing properly (and coming up with a way to do it along
the way).

On 2017-07-16 21:17:22, alex.jakime...@gmail.com wrote:
> See this:
>
https://github.com/rakudo/rakudo/blob/6c76ed0abe352316eb58283fa6ce6b8150fc6830/src/core/Backtrace.pm#L144
>
> It goes like this:
>
> # now *that's* an evil hack
> next if $file.ends-with('BOOTSTRAP.nqp')
> || $file.ends-with('QRegex.nqp')
> || $file.ends-with('Perl6/Ops.nqp');
>
>
> Creating a ticket so that it does not fall through the cracks.

[perl #125656] [CONC] Creating too many Proc::Async objects fills the file descriptor table, which causes libuv to abort()

[Aleks-Daniel Jakimenko-Aleksejev via RT]

On 2017-07-13 08:18:20, alex.jakime...@gmail.com wrote:
> On 2017-07-12 22:49:43, ug...@cpan.org wrote:
> > This only applies if you call .stdout or .stderr *and* never close
> > them.
>
> Hm, isn't it fixed now? Similarly to
> https://github.com/perl6/doc/issues/1304 ?

Ah, no, it's not. It's a completely different issue. Here we are intentionally
running out of handles. nvm

[perl #125656] [CONC] Creating too many Proc::Async objects fills the file descriptor table, which causes libuv to abort()

[Aleks-Daniel Jakimenko-Aleksejev via RT]

On 2017-07-12 22:49:43, ug...@cpan.org wrote:
> This only applies if you call .stdout or .stderr *and* never close them.

Hm, isn't it fixed now? Similarly to https://github.com/perl6/doc/issues/1304 ?

[perl #129882] [CONC] [IO] Proc with `.in.close` and `.out.slurp-rest` in different threads, hangs

[Aleks-Daniel Jakimenko-Aleksejev via RT]

That's pretty good. But issues are not closed without tests, unless there's a
good reason not to add a test. No reason was mentioned, therefore reopening
this with “testneeded” tag.

On 2017-07-09 15:49:46, jan-olof.hen...@bredband.net wrote:
> On Wed, 19 Oct 2016 05:57:04 -0700, jn...@jnthn.net wrote:
> > On Fri Oct 14 16:40:27 2016, sml...@gmail.com wrote:
> > > The following code attempts to pipe a large Blob (larger than a
> > > pipe's
> > > buffer size) through an external command.
> > > However, it hangs on the `.in.close` line and never finishes:
> > >
> > > my $proc = run «cat -», :in, :out, :bin;
> > > my $input = ("a" x 100).encode;
> > > my $promise = start {
> > > $proc.in.write: $input;
> > > $proc.in.close;
> > > }
> > > say $proc.out.slurp-rest(:close, :bin).bytes;
> > > await $promise;
> > >
> > For now, if using threads, stick with Proc::Async (in the future,
> > we'll probably re-implement Proc/run etc. in terms of Proc::Async).
> >
> > /jnthn
>
> jnthn recently made the above mentioned re-implementation so the code
> shown in the report now works.
>
> Closing issue

[perl #128718] [CONC] Strange error when attempting to redo a supply block

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Since when are we rejecting tickets like that? :)

The title says “Strange error”. Current error message is:
===SORRY!===
redo without loop construct

Two things:
1) No line number
2) Even if the line number was there, we don't want the behavior of this to be
changing like crazy. See output on all releases:
https://gist.github.com/Whateverable/e6e0d116d73ef3b467b55a779ee657cd . The
fact that it was changing like this means that it may be a good idea to add a
test (for the error message), even if the original code is not supposed to
work.

I'm not against repurposing this ticket as [LTA], but rejecting? I don't think
it's a good idea…

On 2017-07-09 16:16:51, jan-olof.hen...@bredband.net wrote:
> On Thu, 25 Aug 2016 07:14:03 -0700, coke wrote:
> > On Sat Jul 23 20:47:04 2016, c...@zoffix.com wrote:
> > > Not even sure what causes that, but removing the `redo` avoids the
> > > error.
> > >
> > > $ perl6 -e 'react { whenever supply { emit 42; redo } { .say } }'
> > > 42
> > > No such method 'CALL-ME' for invocant of type 'Bool'
> > > in block  at -e line 1
> > >
> > >
> >
> > Behavior has changed:
> >
> > $ perl6 -e 'react { whenever supply { emit 42; redo } { .say } }'
> > 42
> > Access denied to keep/break this Promise; already vowed
> > in any at /Users/coke/.rakudobrew/moar-
> > 2016.08.1/install/share/perl6/runtime/CORE.setting.moarvm line 1
> > in block  at -e line 1
>
> Running it with a recent version gives the following result
>
> dogbert@dogbert-VirtualBox ~ $ perl6 -e 'react { whenever supply {
> emit 42; redo } { .say } }'
> 42
> ===SORRY!===
> redo without loop construct
>
> If this message is correct then the original code snippet should never
> have worked in the first place.
> Rejecting issue. Reopen if you think this is a mistake.

[perl #130366] BagHash/MixHash values don't check for zeroness

[Aleks-Daniel Jakimenko-Aleksejev via RT]

This was resolved together with
https://rt.perl.org/Ticket/Display.html?id=131241

Tests needed, maybe. See other ticket for info on this.
On 2016-12-17 01:42:04, elizabeth wrote:
> $ 6 'my $b = .BagHash; $_-- for $b.values; dd $b'
> BagHash $b = ("a"=>0,"c"=>0,"b"=>1,"e"=>0,"f"=>0,"d"=>0).BagHash
> *SHOULD* be BagHash $b = ("b"=>1).BagHash
>
>
> $ 6 'my $b = .BagHash; .value-- for $b.pairs; dd $b'
> BagHash $b = ("a"=>0,"c"=>0,"b"=>1,"e"=>0,"f"=>0,"d"=>0).BagHash
> *SHOULD* be BagHash $b = ("b"=>1).BagHash
>
>
> $ 6 'my $b = .BagHash; $_ = 0 for $b.values; dd $b'
> BagHash $b = ("a"=>0,"c"=>0,"b"=>0,"e"=>0,"f"=>0,"d"=>0).BagHash
> *SHOULD* be BagHash $b = ("b"=>1).BagHash
>
>
> Same for MixHash. Baggy/Mixy need to have the equivalent logic to
> ISINSET from SetHash.
>
>
> RTing this so it won’t fall through the cracks.

[perl #131699] [LTA] Errors indexing past the end of a List

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Hm. Wouldn't that make behavior of Lists and Arrays different?

On 2017-07-04 05:29:20, comdog wrote:
> Accessing a List element beyond the end of the List returns Nil,
> although accessing an element before the beginning returns an out of
> bounds failure. I think there's two things that can be better here
> since we know the size of the List.
>
> my $list = < a b c >;
> put "I have a {$list.^name}";
>
> First, in the "before" case, we have more information than the error
> message lets on. The index should be from 0 to 2:
>
> {
> my $i = -1;
> $list[$i]; # Index out of range. Is: -1, should be in 0..^Inf
> }
>
> But this requires the change I think is more helpful. Since the List
> size won't change, we can have the same out-of-bounds error on
> accesses past the end. At the moment it's no warning:
>
> {
> my $i = $list.end + 1;
> $list[$i]; # No warning
> }
>
> This would then be the error for assigning into a position beyond the
> end. The existing error doesn't say what went wrong even though Perl 6
> has enough information to figure that out:
>
> {
> my $i = $list.end + 1;
> $list[$i] = 5; # Cannot modify an immutable Nil
> }

[perl #129131] [RFC] Make .. a numeric operator, please (.say for ‘42’..‘51’)

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Case in point: https://stackoverflow.com/questions/44835476


On 2016-08-29 19:28:10, alex.jakime...@gmail.com wrote:
> First of all, take a look at this:
> https://docs.perl6.org/language/traps#String_Ranges/Sequences
>
> The question is: why do we keep this trap?
>
> We all know that the idea of + being numeric-only has worked very
> well. Now,
> how did .. operator slip in?
>
> I've just seen somebody stumbling upon this confusing and unexpected
> behavior:
> http://irclog.perlgeek.de/perl6/2016-08-30#i_13114494
>
> I am not even sure if current stringy behavior is useful at all. Well,
> maybe it
> is, has anybody seen it being used in some module or something? It
> looks way
> more “WAT?” than “OK, I will probably need this in the future” to me,
> but I'd
> love to be proven wrong.
>
> Anyway, ~.. is probably a good way to keep stringy behavior for those
> who need
> it?

[perl #131695] Confusion in precedence with <<$foo>>[0]

[Aleks-Daniel Jakimenko-Aleksejev via RT]

I don't really want to start another ticket for what I'm about to suggest,
therefore I'll reopen this one.

Not so long ago I filed this ticket:
https://rt.perl.org/Ticket/Display.html?id=131640

The underlying issue is exactly the same. And it has actually happened during
whateverable development, so it is not some kind of a thought exercise.

Therefore, I think that we should actually try to improve the error message
somehow. And here's my idea. What if the error message said something like
this:

===SORRY!=== Error while compiling -e
Cannot use variable $number in declaration to initialize itself
(while parsing shell-quote words started at line 2)
at -e:3
--> put "Type: " ~ $⏏number;
expecting any of:
double quotes
statement end
statement modifier
statement modifier loop
term

Please suggest a better way to put it, but the idea is quite simple: if we are
inside another language that was started on a different line, why not say where
exactly it was started? There may be cases when this additional line will not
give anything useful, but generally it will make the error message Truly
Awesome™.


On 2017-07-03 10:59:54, allber...@gmail.com wrote:
> Perhaps this example should be provided somewhere as a 'gotcha'.
>
> On Mon, Jul 3, 2017 at 11:09 AM, jn...@jnthn.net via RT <
> perl6-bugs-follo...@perl.org> wrote:
>
> > On Mon, 03 Jul 2017 05:46:46 -0700, comdog wrote:
> > > It seems that term precedence with << >> gets confused.
> > >
> > The << >> quoting construct interpolates. The rule for interpolation
> > of
> > method calls, indexing, etc. after a scalar is that there may be one,
> > but
> > it may only end with a ], ), } or >.
> >
> > > {
> > > my $number = <<$string>>[0];
> >
> > When the variable is encountered inside of the interpolating quoting
> > construct, which is being parsed by the quoting parser, it calls back
> > into
> > the Perl 6 main language parser. This parses a variable and
> > optionally a
> > postfix. The >>[0] is a valid postfix, where >> is the hyper-operator
> > and
> > [0] is the indexer. Therefore the $string>>[0] is taken as the thing
> > to
> > interpolate. It then hands back control to the quoting parser.
> >
> > > put "Type: " ~ $number;
> > > #`(
> > > ===SORRY!=== Error while compiling ...
> > > Cannot use variable $number in declaration to initialize itself
> > > --> put "Type: " ~ $⏏number;
> >
> > This is complaining that $number was used before its declaration was
> > complete, which is indeed the case because at we are still inside of
> > the
> > quoting construct.
> >
> > I can see the potential for a human reader to be confused, but the
> > Perl 6
> > parser is not in the least bit confused. There isn't any question as
> > to
> > what will parse the >>: if the main language parser understands it
> > and
> > wants it, then it gets it, because the quoting parser doesn't get a
> > say
> > again until the main language parser has done its bit. This is the
> > same
> > reason that you can do stuff like:
> >
> > say "Foos: @foo.join("bar")"
> >
> > And there isn't a bit of confusion so far as Perl 6 is concerned that
> > the
> > inner " is opening a new string, not closing the one we were already
> > in.
> > Granted it's maybe kinder to the reader to write it with single
> > quotes
> > inside of the string. But nestings of main language => quote parser
> > => main
> > language => quote parser will Just Work, each eating as much as it
> > understands (or until seeing its terminator) before giving up
> > control.
> >
> > /jnthn
> >
> >

[perl #131686] [BUG] [X] @list-of-lists misbehaves with list of one list

[Aleks-Daniel Jakimenko-Aleksejev via RT]

I'd agree that it is a bug, yes. Well, the reason why it happens might be
justified, but this is probably one of the fattest traps I've seen so far. I
really think we should come up with a way to eliminate this trap somehow. Not
sure how, but there must be a way and I really recommend anybody reading this
to think in this direction (instead of writing a lot of text to come up with
excuses to reject this ticket). Maybe it's something we can fix in v6.d, or
maybe we can add some kind of warning right now. I don't know, but I truly hope
that there is a solution.

On 2017-07-01 13:17:58, pe...@mscha.org wrote:
> That may indeed explain why it works the way it does, but that doesn't
> mean it isn't a bug. IMO it certainly is; [X] and [X*] don't work as
> advertised.
>
> Let me explain how I found this bug.
> I'm generating a list of divisors for a number. I already have the
> prime factorization of that number, and a list of all the "prime powers".
> Examples:
> 24 = 2³×3¹: ((1, 2, 4, 8), (1, 3))
> 42 = 2¹×3¹×7: ((1, 2), (1, 3), (1, 7))
> 64 = 2⁶: ((1, 2, 4, 8, 16, 32, 64),)
> Now it's easy to generate the divisors:
>
> > say [X*] ((1, 2, 4, 8), (1, 3));
> (1 3 2 6 4 12 8 24)
>
> > say [X*] ((1, 2), (1, 3), (1, 7));
> (1 7 3 21 2 14 6 42)
>
> > say [X*] ((1, 2, 4, 8, 16, 32, 64),)
> (2097152)
> Oops...

[perl #131686] [BUG] [X] @list-of-lists misbehaves with list of one list

[Aleks-Daniel Jakimenko-Aleksejev via RT]

I think this is related: https://github.com/perl6/doc/issues/1400

On 2017-07-01 12:25:39, pe...@mscha.org wrote:
> This is OK:
>
> > say [X] ((1,2,3), (4,5,6));
> ((1 4) (1 5) (1 6) (2 4) (2 5) (2 6) (3 4) (3 5) (3 6))
> > say [X*] ((1,2,3), (4,5,6));
> (4 5 6 8 10 12 12 15 18)
>
> ... but this is incorrect:
>
> > say [X] ((1,2,3),);
> ((1 2 3))
> > say [X*] ((1,2,3),);
> (6)
>
> Expected output is:
> ((1) (2) (3))
> and
> ((1) (2) (3))
>
>
> Note that [*] behaves as expected:
>
> > say [*] ((1,2,3),(4,5,6));
> 9
> > say [*] ((1,2,3),);
> 3
>
> ... since this is equivalent to:
>
> > say [*] (3, 3);
> 9
> > say [*] (3,);
> 3

[perl #131626] [PERF] ≥ and ≤ are 36x slower than Texas version; ≠ is 15x slower

[Aleks-Daniel Jakimenko-Aleksejev via RT]

This was discussed in
https://github.com/rakudo/rakudo/pull/1032#issuecomment-284217342

In theory, this ticket should apply for other ops as well.

Note that I said that I will change the way unicode ops are implemented, but I
didn't have much time since then. Hoping to get to it at some point.

On 2017-06-22 10:29:59, c...@zoffix.com wrote:
> I'd expect the fancy Unicode versions of <=, >=, and != to perform
> equally well, instead the
> ≥ and ≤ are 36x slower than their Texas companions and ≠ is 15x
> slower.
>
> Here's the timings for >= vs ≥:
>
> m: my $x = rand; for ^1000_000 { $ = $x >= 1_000_000_000_000 }; say
> now - INIT now;
> rakudo-moar 43c176: OUTPUT: «0.74663187␤»
> m: my $x = rand; for ^1000_000 { $ = $x ≥ 1_000_000_000_000 }; say now
> - INIT now;
> rakudo-moar 43c176: OUTPUT: «(timeout)»
> m: my $x = rand; for ^1000_0 { $ = $x ≥ 1_000_000_000_000 }; say now -
> INIT now;
> rakudo-moar 43c176: OUTPUT: «0.2661272␤»
> m: say 0.2661272*100 / 0.729002
> rakudo-moar 43c176: OUTPUT: «36.505689␤»

[perl #125813] [UNI] Malformed UTF-8 (string out of bounds) with “say ('a' x 10000).IO.open”

[Aleks-Daniel Jakimenko-Aleksejev via RT]

An important line from bisectable output was omitted :)

 samcv, The result looks a bit unrealistic, doesn't it? Most
probably the output is different on every commit (e.g. ｢bisect: say rand｣)


We can try this:

 c: releases say ('a' x 1).IO.open
 AlexDaniel,
https://gist.github.com/0727db8b695fbed572cf4b9cd9fa6edc

Looking at the output, we can see that it was changed somewhere between 2017.03
and 2017.04.3, so actually it is a fairly recent fix.

I tried to narrow it down with a bot, but couldn't. Not that it matters much,
just wanted to note that it is not as new.

On 2017-06-08 21:11:51, samant...@posteo.net wrote:
> I don't get the UTF-8 malformed error. Bisectable output:
>
>  bisectable6, say ('a' x 1).IO.open;
>  samcv, Bisecting by output (old=2015.12 new=f0c3bf7)
> because on both starting points the exit code is 1
>  samcv, bisect log:
> https://gist.github.com/da75432d7785e4bdc0c0a74e6084b49c
>  samcv, (2015-12-25)
>
https://github.com/rakudo/rakudo/commit/07fecb52eb1fd07397659f19a5cf36dc61f84053
>
> Seems to show it has been fixed for a while.
>
> Maybe this should change to a LTA due to the error message?

[perl #131529] byte.Range should be 0..255 and not -∞^..^∞ (say byte.Range)

[Aleks-Daniel Jakimenko-Aleksejev via RT]

See also this discussion:
https://irclog.perlgeek.de/perl6-dev/2017-06-07#i_14699799

In other words, if you fix this, please also fix the dead code issue in
“default {}”.

On 2017-06-07 09:35:49, alex.jakime...@gmail.com wrote:
> Code:
> say byte.Range
>
> Result:
> -Inf^..^Inf
>

[perl #126732] [RFC] Problem with superscripts when there is no number in front of it (³² == 9)

[Aleks-Daniel Jakimenko-Aleksejev via RT]

“The only people I see complaining about it are those who just type it up
randomly to see what it'd do”

We had a bunch of segfaults and overflows that could only be caused by people
throwing random stuff into the compiler. And yes, very often we had to go
through this “wait, but normal people will not see this” idea, and in every
case it was fixed in rakudo instead (for example, because this kind of stuff
makes the language look fragile).

Let's resolve the issue by adding an error message and not by closing our eyes
on this.

On 2017-06-05 03:19:58, c...@zoffix.com wrote:
> FWIW, I rescind all of my previous comments on the matter and now
> think no special casing should be done to error out on ³² or anything
> like that.
>
> The only people I see complaining about it are those who just type it
> up randomly to see what it'd do; i.e. not an issue in real programs. I
> see no sufficient argument to add special casing in code,
> documentation, and tests, without solving any real problems.

[perl #131493] changed type of variable

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Well,

say IntStr ~~ Str # True

In other words, IntStr *is* a Str.

What I find interesting, however, is this difference:

sub s (Str() :$str) {say $str.WHAT}; s(:str<1>) # IntStr
sub s (Str :$str) {say $str.Str.WHAT}; s(:str<1>) # Str

I would have expected the same output in both cases.

On 2017-06-03 02:05:49, mt1...@gmail.com wrote:
> Hi,
>
> In Rakudo version 2017.05-338-gaca1929 built on MoarVM version
> 2017.05-25-g62bc54e
> implementing Perl 6.c I saw that a type could be changed through an
> assignment which It should not do. In REPL;
>
>
> > my Str $s = IntStr.new(12,'12');
> 12
> > $s.WHAT
> (IntStr)
> >
>
> The type IntStr should be coerced into Str. A second example happened in
> my code and golfed in REPL
>
>
>
> > sub s (Str :$str) {say $str.WHAT}
> sub s (Str :$str) { #`(Sub|89412592) ... }
> > s(:str<1>)
> (IntStr)
> > s(:str)
> (Str)
>
>
> The type should stay as it was defined I think.
> Marcel

[perl #131398] Feature Request: trait for unimplemented subs/methods

[Aleks-Daniel Jakimenko-Aleksejev via RT]

But we already have ..., !!! and ???. Isn't it what you want?

 m: sub foo() { … }; foo
 rakudo-moar 608e88: OUTPUT: «Stub code executed␤ in sub foo at 
line 1␤ in block  at  line 1␤␤Actually thrown at:␤ in block 
at  line 1␤␤»
 m: sub foo() { !!! }; foo
 rakudo-moar 608e88: OUTPUT: «Stub code executed␤ in sub foo at 
line 1␤ in block  at  line 1␤␤»
 m: sub foo() { ??? }; foo
 rakudo-moar 608e88: OUTPUT: «Stub code executed␤ in sub foo at 
line 1␤»

On 2017-05-29 16:03:29, ben-goldb...@hotmail.com wrote:
> There should be a trait, called either nyi or unimplemented (choose your
> favorite name and capitalization) which changes the subroutine or method
> it's applied to so that, when it's called, it dies or fails with an X::NYI
> exception.
>
> Alternatively, a slightly more generic solution might be more useful:
>
> role AutoDie[$class, $message?] {
> method CALL-ME(*@_, *%_)) {
> die $class.new: $message // |();
> }
> };
> role AutoFail[$class, $message?] {
> method CALL-ME(*@_, *%_) {
> fail $class.new: $message // |();
> }
> }
>
> sub foo does AutoFail[X::NYI, "Sorry, we haven't gotten to foo yet!"] {...}

[perl #131376] [IO][REGRESSION] read on IO handle following SeekFromCurrent

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Bisectable failed in the provided log, here is the right result:


 AlexDaniel, Bisecting by output (old=2015.12 new=95b4e5d) because
on both starting points the exit code is 0
 AlexDaniel, bisect log:
https://gist.github.com/1b6f1bdabefa1cb13338451abceea153
 AlexDaniel, (2017-05-25)
https://github.com/rakudo/rakudo/commit/93f46451c9d5e44063b05b5597b8678133f8f22e

On 2017-05-26 12:14:13, david.warring wrote:
> 3 more elements. Show/hide.
> 19:01 
> dwarring p6:
> "tst.txt".IO.spurt([~] 'a' .. 'z'); my $ioh = "tst.txt".IO.open(:r);
> say
> $ioh.read(4); $ioh.seek(1, SeekFromCurrent); say $ioh.read(4);
> 19:01  camelia
> rakudo-moar
> 95b4e5: OUTPUT: «Blob[uint8]:0x<61 62 63 64>␤Blob[uint8]:0x<>␤»
> 19:02 
> dwarring bisect:
> "tst.txt".IO.spurt([~] 'a' .. 'z'); my $ioh = "tst.txt".IO.open(:r);
> say
> $ioh.read(4); $ioh.seek(1, SeekFromCurrent); say $ioh.read(4);
> 19:02 
> bisectable6 dwarring,
> Bisecting by output (old=2015.12 new=95b4e5d) because on both starting
> points the exit code is 0
> 19:06 
> MasterDuke AlexDaniel:
> ^^^
> 19:08 
> dwarring anyway,
> nothing returned from second read after seekFromCurrent
> 19:08  Recent
> regression. I'll put in an RT