[perl #131858] [REGRESSION] default $.nl-in on IO::Handle does not correctly work in subclasses
There's now a regression test in
https://github.com/perl6/roast/commit/a7af87465e0dc593f4e008d6dcfe077f1bbff0f1
Closing (but please take a look at that roast commit)
On 2018-03-11 13:11:21, jan-olof.hen...@bredband.net wrote:
> On Tue, 08 Aug 2017 04:19:24 -0700, elizabeth wrote:
> > reverted c63c57e9a823303e74c06 for now
> >
> > > On 8 Aug 2017, at 12:21, Zoffix Znet (via RT) > > follo...@perl.org> wrote:
> > >
> > > # New Ticket Created by Zoffix Znet
> > > # Please include the string: [perl #131858]
> > > # in the subject line of all future correspondence about this
> > > issue.
> > > # https://rt.perl.org/Ticket/Display.html?id=131858 >
> > >
> > >
> > > Currently, this causes breakage in IO::String
> > >
> > > zoffix@VirtualBox~$ perl6 -e 'class Z is IO::Handle { method x { dd
> > > $.nl-in } }.new.x;'
> > > $["\n"]
> > >
> > > zoffix@VirtualBox~$ perl6 -v
> > > This is Rakudo version 2017.07-138-ga91ad2d built on MoarVM version
> > > 2017.07-318-g604da4d
> > >
> > > Above, it should give the two-element array, with "\r\n" as another
> > > element.
> > >
> > > AlexDaniel bisected my original code[^1] to point to
> > > https://gist.github.com/Whateverable/b26f4103f5da0809e11749b50fdbabb4
> > > ¦c63c57e9a823^: «"hello,"» ¦c63c57e: «"hello,\r\nworld!\r\n"»
> > >
> > > I tried to golf it further, by taking all the relevant bits from
> > > IO::Handle into a custom class, but failed to reproduce the issue
> > > then.
> > >
> > > [1]
> > > https://gist.github.com/zoffixznet/0c2cbd7acaaf0d3b27d245ad2e2bc737
>
> It seems as if everything is still good after the revert
> ((2017-08-08)
>
https://github.com/rakudo/rakudo/commit/67455170ca50bb908f309b77e5ca579eaa21605c
> ),
> tests needed,
[perl #131623] [BUG] Range + detached method + map with = "Cannot find method 'count' on object of type NQPMu"
A test for this issue was already added in https://github.com/rakudo/rakudo/commit/f3efe5e6b4a9ee5#diff-2aaee6bee3c5525182362ffdcbea1f2cR14 Closing. On 2018-03-10 16:40:40, jan-olof.hen...@bredband.net wrote: > On Thu, 22 Jun 2017 05:25:08 -0700, c...@zoffix.com wrote: > > A WhateverCode detached map or a undetached map works fine: > > m: ^2 .map: *.say > > rakudo-moar 86e7b2: OUTPUT: «01» > > m: (^2).map: > > rakudo-moar 86e7b2: OUTPUT: «01» > > > > But explodes if you try to both detache and use the map: > > m: ^2 .map: > > rakudo-moar 86e7b2: OUTPUT: «===SORRY!===Cannot find method > > 'count' on object of type NQPMu» > > Fixed with commit > https://github.com/rakudo/rakudo/commit/f3efe5e6b4a9ee59f71ca11cb90ef78539be45e3
[SPAM:##] [perl #126014] Too many repetitions with xx operator causes out of memory; should it work lazily?
Tests in https://github.com/perl6/roast/commit/b320464868d3b8da98c090ddc4b0d57604683e13 Closing On 2018-03-10 11:25:06, jan-olof.hen...@bredband.net wrote: > On Wed, 22 Feb 2017 03:59:05 -0800, elizabeth wrote: > > > On 22 Feb 2017, at 12:41, jn...@jnthn.net via RT > > follo...@perl.org> wrote: > > > On Sat, 30 Apr 2016 03:42:00 -0700, alex.jakime...@gmail.com wrote: > > >> OK, I said that it only segfaults on 32-bit systems, but I was > > >> wrong. > > >> > > >> Code: > > >> 42 xx (2 ** 62) > > >> > > >> Result: > > >> Segmentation fault > > >> > > > This is patched in MoarVM HEAD just now and no longer SEGVs > > > (reports > > > the array is too long to allocate). So, no longer a SEGV bug. > > > > > > However, I'm a bit surprised that xx does not work lazily, and > > > actually makes such a huge array up-front. Not sure if we want to > > > re- > > > purpose the ticket for that; I'll remove the SEGV from the title, > > > however, since that is resolved. > > > > Ah, yes, I remember we discussed this. I’ll make it a Seq, although > > the question then becomes: should it be lazy or not? If it is not > > lazy, we would just be postponing the exception in some cases. > > > > > > Liz > > Fixed with commit > https://github.com/rakudo/rakudo/commit/1eb7b1f796214870b53c7ed055907cb29076dc78
[perl #126312] [BUG] `for @a` is not creating containers for uninitialized elements
Tests added in https://github.com/perl6/roast/commit/d78f33966cf6a6ec6bc060d98dfc521ad59b6f75 Closing On 2018-02-06 14:12:56, jan-olof.hen...@bredband.net wrote: > On Sat, 07 May 2016 13:26:09 -0700, sml...@gmail.com wrote: > > Confirmed on current Rakudo. > > > > Interestingly, it works if `for @a` is replaced with `for @a[*]`: > > > > ➜ my Int @a; @a[5] = 42; $_ = 100 for @a[*]; say @a; > > [100 100 100 100 100 100] > > Seems to have been fixed with Rakudo commit > 069b789af545dff30d450618fae82ccb82579346. > Tests needed.
[SPAM:##] [perl #132030] [TESTNEEDED] [REGRESSION] Broken Text::CSV tests and possibly other ecosystem fallout (buffering)
Tests added in https://github.com/perl6/roast/commit/40edf6d2c939fe095a848056db3489d7b1482a8a I think we can close this. On 2017-09-16 19:58:20, alex.jakime...@gmail.com wrote: > 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 > > > > > >
[perl #130941] infix: keeps containers around since October, resulting in confusing behaviour
Tests in https://github.com/perl6/roast/commit/1a42efd4ce0fdc695b16bbf64af92ecf0bca1866 On 2018-03-10 10:43:14, alex.jakime...@gmail.com wrote: > This ticket now needs tests, further discussion related issues here: > https://github.com/rakudo/rakudo/issues/1607 > > On 2017-03-08 05:56:13, c...@zoffix.com wrote: > > A temporary fix has been committed in > > > https://github.com/rakudo/rakudo/commit/5b7b7fb5c942a3e74097b5eb94a22be262f74c9f
Re: Using HashBags
Hi,
Don't know if there is a better way, but assuming you don't have control
over the data, you can do this:
my Bag $docents = @rows.map(*.pairup).Bag;
On 2018-04-07 10:10:52 GMT, mimosinnet wrote:
> Hi all,
>
> I do not seem to be able to get this done with the Bag or BagHash
> type:
>
> ---
> dd @rows;
>
>> Output: Array @rows = [["JF", 1], ["JF", 2], ["MM", 2], ["MPu", 2],
>> ["MM", 2], ["FE", 2], ["FV", 2], ["MPu", 2], ["JP", 2], ["JP", 2],
>> ["FV", 2], ["FV", 2], ["JF", 2], ["MM", 2], ["MPu", 2], ["MM", 2],
>> ["FE", 2], ["FV", 2], ["MPu", 2], ["JP", 2], ["JP", 2], ["JF", 4]]
>
> my %docents;
> for @rows -> @row {
> %docents{ @row[0] } += @row[1];
> }
>
> dd %docents;
>
>> Output: Hash %docents = {:FE(4), :FV(8), :JF(9), :JP(8), :MM(8),
>> :MPu(8)}
>
> ---
>
> As I understand it, this would better be achieved with the Bag or
> BagHash type. What would be the easy way?
>
> Thanks!
[perl #129142] [BUG] Parse error when coercing an enum from a coercion of an enum from an int
On Fri, 16 Mar 2018 16:02:15 -0700, jan-olof.hen...@bredband.net wrote: > On Tue, 30 Aug 2016 16:30:24 -0700, allber...@gmail.com wrote: > > I think the problem is that there's already another syntax using that > > sequence: coercion types. FF(FF(2)) is being parsed as a coercion > > type from > > FF to FF(... and then it falls over because it's not expecting nested > > coercion types. > > > > On Tue, Aug 30, 2016 at 7:13 PM, Brian S. Julin < > > perl6-bugs-follo...@perl.org> wrote: > > > > > # New Ticket Created by "Brian S. Julin" > > > # Please include the string: [perl #129142] > > > # in the subject line of all future correspondence about this > > > issue. > > > # https://rt.perl.org/Ticket/Display.html?id=129142 > > > > > > > > > > > > > > > > $ perl6 -e 'enum FF ; FF(2).perl.say' > > > FF::two > > > $ perl6 -e 'enum FF ; FF(FF::two).perl.say' > > > FF::two > > > $ perl6 -e 'enum FF ; FF(two).perl.say' > > > FF::two > > > $ perl6 -e 'enum FF ; FF(abs(-2)).perl.say' > > > FF::two > > > $ perl6 -e 'enum FF ; FF(FF(2)).perl.say' > > > ===SORRY!=== Error while compiling -e > > > Unable to parse expression in typename; couldn't find final ')' > > > at -e:1 > > > --> enum FF ; FF(FF(⏏2)).perl.say > > > > > > > > > # o.O > > > $ perl6 -e 'enum FF ; enum GG > > fum>; > > > FF(foo).perl.say' > > > FF > > > > > > $ perl6 -e 'enum FF ; enum GG > > fum>; > > > FF(GG(foo)).perl.say' > > > FF(GG(GG)) > > > > > > $ perl6 -e 'enum FF ; enum GG > > fum>; > > > FF(GG(2)).perl.say' > > > ===SORRY!=== Error while compiling -e > > > Unable to parse expression in typename; couldn't find final ')' > > > at -e:1 > > > --> hree>; enum GG ; FF(GG(⏏2)).perl.say > > > > > > > > > > > Fixed with commit > https://github.com/rakudo/rakudo/commit/c76d9324a9f67e4075683e38a63a9788161c17cc Test added with commit https://github.com/perl6/roast/commit/3b1e5fb4f10ffb1ef384616013d89d117cc98a31
[perl #126490] [BUG] Control exception handling is inconsistent and broken across backends. (SEGV on moar, CX unrecognized on jvm)
Segfault mentioned above is already tested and the test was unfudged in
https://github.com/perl6/roast/commit/ef7b0da83d#diff-72b101ff62a0582672d4de2788ffa1bbL77
Closing
On 2018-03-12 08:29:49, jan-olof.hen...@bredband.net wrote:
> On Mon, 16 Oct 2017 13:04:48 -0700, barto...@gmx.de wrote:
> > On Sat, 16 Jul 2016 13:18:42 -0700, barto...@gmx.de wrote:
> > > I unfudged one test for this ticket in S04-statements/label.t with
> > > commit https://github.com/perl6/roast/commit/ef7b0da83d
> > >
> > > The code that used to segfault works fine now:
> > >
> > > $ perl6-m -e 'A: for 1 { for 1 { last A }; CONTROL { when CX::Last
> > > {
> > > say "last" }; default { .perl.say } } }'
> > > last
> > >
> > > $ perl6-j -e 'A: for 1 { for 1 { last A }; CONTROL { when CX::Last
> > > {
> > > say "last" }; default { .perl.say } } }'
> > > last
> > >
> > > The mentioned failing tests for rakudo-j are still a thing, tough.
> >
> > The remaining tests fudged with this ticket are passing with rakudo-j
> > now. I unfudged them with commit
> > https://github.com/perl6/roast/commit/07517a0006
>
> Fixed with commit
>
https://github.com/rakudo/rakudo/commit/1fbb8b4053cba722567b1e376c4a3f655b55e42b
> at least on MoarVM.
[SPAM:##] [perl #130505] [LTA] double SORRY (BEGIN (1, 2)[*-1])
Tests in https://github.com/perl6/roast/commit/79dff96fc9f383616dd192ef016725395323887b and https://github.com/perl6/roast/commit/82d3a883a52af23c8a67e46b88b313b3cf20b18d On 2018-03-10 06:26:00, jan-olof.hen...@bredband.net wrote: > On Wed, 04 Jan 2017 15:02:45 -0800, alex.jakime...@gmail.com wrote: > > Code: > > BEGIN (1, 2)[*-1] > > > > Result: > > ===SORRY!=== Error while compiling > > An exception occurred while evaluating a BEGIN > > at :1 > > Exception details: > > ===SORRY!=== Error while compiling > > Cannot invoke this object (REPR: Null; VMNull) > > at : > > > > > > Once is enough, especially given that it says “at : ” which is not > > useful. > > > Fixed with commit > https://github.com/rakudo/rakudo/commit/7c1f0b416d37415bb25a3a6974aaa3635f5d1225
Re: Using HashBags
Hi,
I'm not sure that I've understood what you need.
If you get that array of arrays from a another process @rows and you wish
to convert it into a Bag you can do this:
my @rows = [["JF", 1], ["JF", 2], ["MM", 2], ["MPu", 2], ["MM", 2], ["FE",
2], ["FV", 2], ["MPu", 2], ["JP", 2], ["JP", 2], ["FV", 2], ["FV", 2],
["JF", 2], ["MM", 2], ["MPu", 2], ["MM", 2], ["FE", 2], ["FV", 2], ["MPu",
2], ["JP", 2], ["JP", 2], ["JF", 4]];
my Bag $docents = bag @rows.map: -> @row {@row[0] xx @row[1]};
dd $docents;
# Bag $docents = ("JP"=>8,"FV"=>8,"FE"=>4,"MPu"=>8,"MM"=>8,"JF"=>9).Bag
Otherwise you can start collecting those pairs into a Bag from the start,
but we would need more details then.
HTH
On Sat, Apr 7, 2018 at 12:10 PM, mimosinnet wrote:
> Hi all,
>
> I do not seem to be able to get this done with the Bag or BagHash type:
>
> ---
> dd @rows;
>
> Output: Array @rows = [["JF", 1], ["JF", 2], ["MM", 2], ["MPu", 2], ["MM",
>> 2], ["FE", 2], ["FV", 2], ["MPu", 2], ["JP", 2], ["JP", 2], ["FV", 2],
>> ["FV", 2], ["JF", 2], ["MM", 2], ["MPu", 2], ["MM", 2], ["FE", 2], ["FV",
>> 2], ["MPu", 2], ["JP", 2], ["JP", 2], ["JF", 4]]
>>
>
> my %docents;
> for @rows -> @row {
> %docents{ @row[0] } += @row[1];
> }
>
> dd %docents;
>
> Output: Hash %docents = {:FE(4), :FV(8), :JF(9), :JP(8), :MM(8), :MPu(8)}
>>
>
> ---
>
> As I understand it, this would better be achieved with the Bag or BagHash
> type. What would be the easy way?
>
> Thanks!
> --
> (≧∇≦) Mimosinnet (Linux User: #463211)
>
--
Fernando Santagata
[perl #126318] [BUG] trait 'is default' on attributes has no effect
Tests in
https://github.com/perl6/roast/commit/ce1a5a2e6b5b199c0df69a83cf66f1b830ee47e8
and
https://github.com/perl6/roast/commit/38c9dc5fd5339ed434438eb58bae07e7fdd31a1d
Closing.
On 2018-03-12 06:59:31, jan-olof.hen...@bredband.net wrote:
> On Wed, 13 Sep 2017 19:17:16 -0700, b...@abrij.org wrote:
> > On Wed, 13 Sep 2017 19:15:36 -0700, b...@abrij.org wrote:
> > > On Fri, 16 Oct 2015 00:54:21 -0700, larry wrote:
> > > > On Sat Oct 10 08:33:13 2015, FROGGS.de wrote:
> > > > > say class { has Int $.foo is default(0) }.new.foo
> > > > > rakudo-moar 025ec1: OUTPUT«(Int)»
> > > > >
> > > > > class Foo { has Int $.foo is default(0) }; say Foo.new.foo
> > > > > rakudo-moar 025ec1: OUTPUT«(Int)»
> > > > >
> > > > > I would expect that foo is zero in both cases.
> > > >
> > > > Even less sensical, it violates its own :D here:
> > > > > p6 'say class { has Int:D $.foo is default(0) }.new.foo'
> > > > (Int:D)
> > >
> > > The first case was resolved with RT#131387
> > >
> > > The second case seems fixed.
> > >
> > > Tests specifically for the second case still needed.
> > >
> > >
> > >
> > >
> > > So maybe combine this with the latter and make a ruling on
> >
> >
> > Ignore that last sentence, I was going to suggest RT#126296 but...
>
> Second case fixed with commit
>
https://github.com/rakudo/rakudo/commit/148ba7f2e4de8f33e8436267a4b0c9042a171d82
> Testneeded
[perl #133082] LTA: precedence error !%foo:exists
# New Ticket Created by Martin Barth # Please include the string: [perl #133082] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=133082 > Hello, IMHO the error could be better: perl6 -e 'my %foo = ; say !%foo:exists' Unexpected named argument 'exists' passed in block at -e line 1
Using HashBags
Hi all,
I do not seem to be able to get this done with the Bag or BagHash
type:
---
dd @rows;
Output:
Array @rows = [["JF", 1], ["JF", 2], ["MM", 2], ["MPu", 2], ["MM", 2],
["FE", 2], ["FV", 2], ["MPu", 2], ["JP", 2], ["JP", 2], ["FV", 2],
["FV", 2], ["JF", 2], ["MM", 2], ["MPu", 2], ["MM", 2], ["FE", 2],
["FV", 2], ["MPu", 2], ["JP", 2], ["JP", 2], ["JF", 4]]
my %docents;
for @rows -> @row {
%docents{ @row[0] } += @row[1];
}
dd %docents;
Output:
Hash %docents = {:FE(4), :FV(8), :JF(9), :JP(8), :MM(8), :MPu(8)}
---
As I understand it, this would better be achieved with the Bag or
BagHash type. What would be the easy way?
Thanks!
--
(≧∇≦) Mimosinnet (Linux User: #463211)
