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

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 exec

[perl #131493] changed type of variable

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

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

“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

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

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 #125813] [UNI] Malformed UTF-8 (string out of bounds) with “say ('a' x 10000).IO.open”

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/0727db8b69

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

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. O

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

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

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

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 readi

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

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,

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

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

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

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 be

[perl #131241] (Bag|Mix)Hash.values doesn't check validity of assigned values

The fix for this ticket also fixed https://rt.perl.org/Public/Bug/Display.html?id=130366 However, we couldn't find any tests… are there any? If they, perhaps they also cover 130366. On 2017-05-01 14:31:19, elizabeth wrote: > Fixed for the .values case with c1bd844e2752799af8e and > 0e0ac2fb8c51a8

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

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

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

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

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

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 wr

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

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 #125656] [CONC] Creating too many Proc::Async objects fills the file descriptor table, which causes libuv to abort()

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 co

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

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/6c76ed0abe352316eb58283fa6ce6

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

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,

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

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

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

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/mar

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

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-gcc1

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

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

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

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 > somewh

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

igint 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) > > w

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

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

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

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,

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

t; > 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 e

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

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-Dan

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

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 examp

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

estion. 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, b

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

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 valu

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

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 alre

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

".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

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

cally 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... > > >

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

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 cra

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

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 err

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

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:

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

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,

[perl #131881] [REGRESSION] JSON::Tiny tests output bad text on latest build

It was bisected to https://github.com/rakudo/rakudo/commit/f590863e1736c75207c9ce0335ea646e3529060e Example (before and after): https://gist.github.com/Whateverable/2a9088ddcff37fd6f748b77ba3339af2 On 2017-08-10 14:54:24, jdv79 wrote: > I updated to: > > > [jdv@localhost ~]$ perl6 -v > This is Ra

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

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.or

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

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

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

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 co

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

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 > '

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

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

[perl #131898] Issue Installing DBIish

Bisected: bisect: old=HEAD~300 https://gist.githubusercontent.com/AlexDaniel/1e2c456f006687ea7100a35b2931af41/raw/9aad30ec83728b43b5d1d134a4c0701354e2c8c5/nativehelpers-test.p6 AlexDaniel, Successfully fetched the code from the provided URL. AlexDaniel, Bisecting by exit code (old=HEAD~300 new=

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

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

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

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/s

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

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 wr

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

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/67

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

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

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

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 an

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

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'

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

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 roas

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

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, bu

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

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-L4

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

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 l

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

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

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

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 ca

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

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:

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

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

[perl #129845] [TESTNEEDED] [CONC] `.dir` returns corrupted `IO::Path`s under concurrent load

It is more or less reliable actually. I think writing a stresstest will do. On 2017-08-26 05:33:17, sml...@gmail.com wrote: > Both the demo script (from the top post) and the one-line test case > (2nd post) now pass without error! > > Bisectable identifies a commit from last week as the fix: > > ht

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

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

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

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 > >

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

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 sup

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

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

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

Still not 77. On 2012-12-07 02:55:44, masak wrote: > rn: sub postfix:<+>($a) is looser(&infix:<+>) { $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

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

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 cau

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

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 #122004] Spooky capture with native int

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 Mattijs

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

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

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

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

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

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]

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

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

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

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

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

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

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

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

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

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

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

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

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

[perl #122004] Spooky capture with native int

Well, it was clearly wrong to say that we don't care about it, sorry about that. Maybe it's not the top priority thing (for example, there is a module to do this: https://github.com/azawawi/perl6-memoize), but there are still plans to get it done eventually. I'll change the title a little bit so t

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

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) > > Comman

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

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.j

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

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/comm

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

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, ale

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

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 m

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

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

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

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...@

[perl #132029] Floppage of atomic tests

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: >

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

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 wr

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

“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). Th

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

“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”

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

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

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

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]

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

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 3c9cfdba88287e23e0ced

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

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..

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

lf 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: [pe

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

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: > h

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

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:/

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

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. > > s

<    3   4   5   6   7   8   9   10   11   12   >