[perl #127452] [CONC] hyper is very broken, *sometimes* it returns nothing

On Mon, 01 Feb 2016 21:59:33 -0800, alex.jakime...@gmail.com wrote: > Let's try running the same code twice: > > m: my @x = ^10; my @y = @x.hyper(:3batch, :5degree).map: { > sleep rand / 10; $_ + 1 }; say @y > rakudo-moar a5fe34: OUTPUT«[]␤» > m: my @x = ^10; my @y = @x.hyper(:3batch, :5deg

[perl #127452] [CONC] hyper is very broken, *sometimes* it returns nothing

On Mon, 01 Feb 2016 21:59:33 -0800, alex.jakime...@gmail.com wrote: > Let's try running the same code twice: > > m: my @x = ^10; my @y = @x.hyper(:3batch, :5degree).map: { > sleep rand / 10; $_ + 1 }; say @y > rakudo-moar a5fe34: OUTPUT«[]␤» > m: my @x = ^10; my @y = @x.hyper(:3batch, :5deg

[perl #130576] [CONC] .race & .hyper break [+] (1..100)

On Tue, 17 Jan 2017 10:10:44 -0800, coke wrote: > The presence of a hyper or race causes incorrect output in some cases. > Originally found with the .grep in the pipeline, but seems to impact > even the simple case. > > $ perl6 -e 'say [+] (1..100)' > 5050 > > $ perl6 -e 'say [+] (1..100).race' >

[perl #126597] [CONC][BUG] .race.grep(...) and .hyper.grep(...) produce an empty sequence

On Mon, 09 Nov 2015 06:36:49 -0800, matt.oa...@congenica.com wrote: > The following has an empty result when using race or hyper in perl6 > version 2015.10-233-gac750a9 built on MoarVM version 2015.10-61- > g624d504 > > $ perl6 > > (1..10).grep(* > 3) > (4 5 6 7 8 9 10) > > (1..10).race().grep(* >

[perl #126597] [CONC][BUG] .race.grep(...) and .hyper.grep(...) produce an empty sequence

On Mon, 09 Nov 2015 06:36:49 -0800, matt.oa...@congenica.com wrote: > The following has an empty result when using race or hyper in perl6 > version 2015.10-233-gac750a9 built on MoarVM version 2015.10-61- > g624d504 > > $ perl6 > > (1..10).grep(* > 3) > (4 5 6 7 8 9 10) > > (1..10).race().grep(* >

[perl #130576] [CONC] .race & .hyper break [+] (1..100)

On Tue, 17 Jan 2017 10:10:44 -0800, coke wrote: > The presence of a hyper or race causes incorrect output in some cases. > Originally found with the .grep in the pipeline, but seems to impact > even the simple case. > > $ perl6 -e 'say [+] (1..100)' > 5050 > > $ perl6 -e 'say [+] (1..100).race' >

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

On Tue, 08 Aug 2017 18:40:48 -0700, 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 shoul

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

On Tue, 08 Aug 2017 18:40:48 -0700, 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 shoul

[perl #128084] [CONC][BUG] `.hyper/.race.map(&f)` produces an empty sequence if `&f` is a multi-sub

On Fri, 06 May 2016 08:37:20 -0700, sml...@gmail.com wrote: > ➜ sub f ($a) { $a**2 }; say (^10).hyper.map(&f).list; > (0 1 4 9 16 25 36 49 64 81) > > ➜ multi f ($a) { $a**2 }; say (^10).hyper.map(&f).list; > () > > The expected behavior would be for both examples to produce the same > (non-em

[perl #129234] [CONC] `.hyper` and `.race` resume after exceptions

On Thu, 08 Sep 2016 12:55:10 -0700, sml...@gmail.com wrote: > If you `die` inside a `map/for` that is being `hyper/race`d... > > for (1..1).hyper { die }; sleep 1; say "Alive"; > > ...it prints the exception's backtrace, but then resumes the program > as if nothing had happened: > > Died > i

[perl #128084] [CONC][BUG] `.hyper/.race.map(&f)` produces an empty sequence if `&f` is a multi-sub

On Fri, 06 May 2016 08:37:20 -0700, sml...@gmail.com wrote: > ➜ sub f ($a) { $a**2 }; say (^10).hyper.map(&f).list; > (0 1 4 9 16 25 36 49 64 81) > > ➜ multi f ($a) { $a**2 }; say (^10).hyper.map(&f).list; > () > > The expected behavior would be for both examples to produce the same > (non-em

[perl #129234] [CONC] `.hyper` and `.race` resume after exceptions

On Thu, 08 Sep 2016 12:55:10 -0700, sml...@gmail.com wrote: > If you `die` inside a `map/for` that is being `hyper/race`d... > > for (1..1).hyper { die }; sleep 1; say "Alive"; > > ...it prints the exception's backtrace, but then resumes the program > as if nothing had happened: > > Died > i

[perl #132287] [REGRESSION][CONC] stall/block in async heavy code

On Fri, 13 Oct 2017 10:13:36 -0700, jdv79 wrote: > The symptom is that sometimes (90%+ on my box and ungolfed) the program > seems to stall out on the qqx line. The last thing that is printed is > "before". But on earlier commits (that actually build) no such > stallage > happened for a couple m

[perl #132287] [REGRESSION][CONC] stall/block in async heavy code

On Fri, 13 Oct 2017 10:13:36 -0700, jdv79 wrote: > The symptom is that sometimes (90%+ on my box and ungolfed) the program > seems to stall out on the qqx line. The last thing that is printed is > "before". But on earlier commits (that actually build) no such > stallage > happened for a couple m

[perl #132292] [REGRESSION] Recursively .emit-ing from the tap of the same supply bails out

On Mon, 16 Oct 2017 07:42:06 -0700, jn...@jnthn.net wrote: > So the question is if we can find a way to have 2 and 4, while > retaining 1 and 3, and at what cost. Also noting that in order to preserve 3, then in a situation like: * "Thread" 1 sends message A * Handler for message A starts running

[perl #132292] [REGRESSION] Recursively .emit-ing from the tap of the same supply bails out

On Fri, 13 Oct 2017 20:43:42 -0700, alex.jakime...@gmail.com wrote: > Code: > my $s1 = Supplier.new; $s1.Supply.tap: { say $_; $s1.emit(2) if $++ < > 5; say "here" }; $s1.emit(1) > > > ¦2017.06: > 1 > 2 > 2 > 2 > 2 > 2 > here > here > here > here > here > here > > ¦HEAD(012c80f): > 1 > here > 2

[perl #132292] [REGRESSION] Recursively .emit-ing from the tap of the same supply bails out

On Fri, 13 Oct 2017 20:43:42 -0700, alex.jakime...@gmail.com wrote: > Code: > my $s1 = Supplier.new; $s1.Supply.tap: { say $_; $s1.emit(2) if $++ < > 5; say "here" }; $s1.emit(1) > > > ¦2017.06: > 1 > 2 > 2 > 2 > 2 > 2 > here > here > here > here > here > here > > ¦HEAD(012c80f): > 1 > here > 2

[perl #132248] Z Metaoperator bug

On Sun, 08 Oct 2017 19:13:34 -0700, ipatrol6...@yahoo.com wrote: > As per a discussion on the IRC channel, I am requesting that a > regression bug be filed regarding the incorrect handling of variables > referenced to packages by the Z and X meta-operators. > > The behavior over time is detailed h

[perl #132248] Z Metaoperator bug

On Sun, 08 Oct 2017 19:13:34 -0700, ipatrol6...@yahoo.com wrote: > As per a discussion on the IRC channel, I am requesting that a > regression bug be filed regarding the incorrect handling of variables > referenced to packages by the Z and X meta-operators. > > The behavior over time is detailed h

[perl #132242] [BUG] Proc::Async running with yes command returns superfluous output and hangs

On Sat, 07 Oct 2017 19:33:40 -0700, allber...@gmail.com wrote: > On Sat, Oct 7, 2017 at 10:21 PM, Itsuki Toyota > wrote: > > > See the following result: > > > > $ perl6 -e 'my $proc = Proc::Async.new("yes"); > > $proc.stdout.head(1).tap(&say); await $proc.start;' > > > > y > > y > > y > > y > > y

[perl #132242] [BUG] Proc::Async running with yes command returns superfluous output and hangs

On Sat, 07 Oct 2017 19:33:40 -0700, allber...@gmail.com wrote: > On Sat, Oct 7, 2017 at 10:21 PM, Itsuki Toyota > wrote: > > > See the following result: > > > > $ perl6 -e 'my $proc = Proc::Async.new("yes"); > > $proc.stdout.head(1).tap(&say); await $proc.start;' > > > > y > > y > > y > > y > > y

[perl #130370] [CONC] Tapping on a very active .out of Proc::Async wrecks the work queue

On Tue, 20 Dec 2016 05:07:57 -0800, jn...@jnthn.net wrote: > On Sun, 18 Dec 2016 06:24:38 -0800, alex.jakime...@gmail.com wrote: > > This is probably best demonstrated by a code snippet. > > > > Code: > > > > my $out = Channel.new; > > #my $proc = Proc::Async.new(‘perl6’, ‘-e’, ‘sleep ∞’); # ← this

[perl #130370] [CONC] Tapping on a very active .out of Proc::Async wrecks the work queue

On Tue, 20 Dec 2016 05:07:57 -0800, jn...@jnthn.net wrote: > On Sun, 18 Dec 2016 06:24:38 -0800, alex.jakime...@gmail.com wrote: > > This is probably best demonstrated by a code snippet. > > > > Code: > > > > my $out = Channel.new; > > #my $proc = Proc::Async.new(‘perl6’, ‘-e’, ‘sleep ∞’); # ← this

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

On Wed, 16 Aug 2017 14:24:48 -0700, 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,9658dd98c9d

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

On Wed, 16 Aug 2017 14:24:48 -0700, 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,9658dd98c9d

[perl #125523] [LTA] num64 not properly defaulting

On Mon, 02 Oct 2017 18:09:45 -0700, alex.jakime...@gmail.com wrote: > Right, because it's a Rat. > > sub foo(num64 $scale = 1.0) {}; say foo # This type cannot unbox to a > native > number: P6opaque, Rat > sub foo(num64 $scale = 1.0.Num) {}; say foo # Nil > No need for .Num, just write it as 1e0

[perl #125523] [LTA] num64 not properly defaulting

On Mon, 02 Oct 2017 18:09:45 -0700, alex.jakime...@gmail.com wrote: > Right, because it's a Rat. > > sub foo(num64 $scale = 1.0) {}; say foo # This type cannot unbox to a > native > number: P6opaque, Rat > sub foo(num64 $scale = 1.0.Num) {}; say foo # Nil > No need for .Num, just write it as 1e0

[perl #122709] [CONC][BUG] `await`ing a Promise in a different thread sometimes hangs

On Wed, 03 Aug 2016 12:23:32 -0700, jn...@jnthn.net wrote: > I can still reproduce it too; seems that occasionally the scheduler > starts too few threads (in fact, only one, and that is tied up with > the await, and so nothing processes the incoming message saying the > process ended). The new sch

[perl #122709] [CONC][BUG] `await`ing a Promise in a different thread sometimes hangs

On Wed, 03 Aug 2016 12:23:32 -0700, jn...@jnthn.net wrote: > I can still reproduce it too; seems that occasionally the scheduler > starts too few threads (in fact, only one, and that is tied up with > the await, and so nothing processes the incoming message saying the > process ended). The new sch

[perl #132148] [RFC] native 'str' type unspecced, undocumented, and ill-defined

On Fri, 22 Sep 2017 16:40:35 -0700, b...@abrij.org wrote: > > We've had a native 'str' type for a while, and still have one even > though NativeCall decided to go with Str and 'is encoded'. > It's not native in the sense of same sense that NativeCall uses the word. > Currently it seems to just b

[perl #132148] [RFC] native 'str' type unspecced, undocumented, and ill-defined

On Fri, 22 Sep 2017 16:40:35 -0700, b...@abrij.org wrote: > > We've had a native 'str' type for a while, and still have one even > though NativeCall decided to go with Str and 'is encoded'. > It's not native in the sense of same sense that NativeCall uses the word. > Currently it seems to just b

[perl #132170] fork + react + IO::Socket::Async issue

On Tue, 26 Sep 2017 12:33:21 -0700, bdug...@matatu.org wrote: > When I export a function that does a fork() and then > a react + whenever + IO::Socket::Async.listen in the > child process, the process only seems to be listening > on the socket the second time I run the code, i.e. only > after .prec

[perl #132170] fork + react + IO::Socket::Async issue

On Tue, 26 Sep 2017 12:33:21 -0700, bdug...@matatu.org wrote: > When I export a function that does a fork() and then > a react + whenever + IO::Socket::Async.listen in the > child process, the process only seems to be listening > on the socket the second time I run the code, i.e. only > after .prec

[perl #130716] [CONC] unbounded supply {} + react {} = pseudo-hang

On Wed, 15 Feb 2017 08:35:09 -0800, jn...@jnthn.net wrote: > Hope this helps, and I'll keep the issue under consideration. So the time came to tackle getting supply/react/whenever syntax capable of playing nice with non-blocking await, and I decided as part of those changes to look at both this

[perl #130716] [CONC] unbounded supply {} + react {} = pseudo-hang

On Wed, 15 Feb 2017 08:35:09 -0800, jn...@jnthn.net wrote: > Hope this helps, and I'll keep the issue under consideration. So the time came to tackle getting supply/react/whenever syntax capable of playing nice with non-blocking await, and I decided as part of those changes to look at both this

[perl #132114] [ANNOYING] t\04-nativecall\21-callback-other-thread.t is flapping on appveyor and travis

On Sun, 17 Sep 2017 14:04:02 -0700, alex.jakime...@gmail.com wrote: > It happens often and that's why we sometimes get false-red CI status. > See > https://ci.appveyor.com/project/rakudo/rakudo/build/1.0.130/job/yqmgs4uo0yim1bxx Fixed the MoarVM bug that caused this, and the revision bump took pla

[perl #132114] [ANNOYING] t\04-nativecall\21-callback-other-thread.t is flapping on appveyor and travis

On Sun, 17 Sep 2017 14:04:02 -0700, alex.jakime...@gmail.com wrote: > It happens often and that's why we sometimes get false-red CI status. > See > https://ci.appveyor.com/project/rakudo/rakudo/build/1.0.130/job/yqmgs4uo0yim1bxx Fixed the MoarVM bug that caused this, and the revision bump took pla

[perl #128717] [LTA] react whenever throws a cryptic error

On Sat, 23 Jul 2016 20:36:59 -0700, c...@zoffix.com wrote: > Blockless `react` seems to be unsupported and the error message it > throws is cryptic and unrelated to the actual issue. Best would be if > it actually worked, but at least the error message should be improved. > > $ perl6 -e 'react whe

[perl #128717] [LTA] react whenever throws a cryptic error

On Sat, 23 Jul 2016 20:36:59 -0700, c...@zoffix.com wrote: > Blockless `react` seems to be unsupported and the error message it > throws is cryptic and unrelated to the actual issue. Best would be if > it actually worked, but at least the error message should be improved. > > $ perl6 -e 'react whe

[perl #126842] [BUG] New react + chain syntax locks sometimes

On Tue, 08 Dec 2015 05:40:29 -0800, pub.clau...@gmail.com wrote: > The replacement of the 'whatever' syntax as sugar for consuming Channels > through 'react' locks very often (5-10% of the time). The thread seems to > be stuck on 'shift', probably from the Channel). When rewriting the exact > same

[perl #126842] [BUG] New react + chain syntax locks sometimes

On Tue, 08 Dec 2015 05:40:29 -0800, pub.clau...@gmail.com wrote: > The replacement of the 'whatever' syntax as sugar for consuming Channels > through 'react' locks very often (5-10% of the time). The thread seems to > be stuck on 'shift', probably from the Channel). When rewriting the exact > same

[perl #132091] await handles Slip differently between v6.c and v6.d.PREVIEW

On Thu, 14 Sep 2017 13:30:46 -0700, timo wrote: > I'm using two start blocks that return Slips to generate a long list in > parallel, then i iterate over the result in the Moar Heap Analyzer. > > Trying to take advantage of v6.d's nonblocking await gives me a change > in semantics, though: > >   

[perl #132091] await handles Slip differently between v6.c and v6.d.PREVIEW

On Thu, 14 Sep 2017 13:30:46 -0700, timo wrote: > I'm using two start blocks that return Slips to generate a long list in > parallel, then i iterate over the result in the Moar Heap Analyzer. > > Trying to take advantage of v6.d's nonblocking await gives me a change > in semantics, though: > >   

[perl #130692] [BUG] IO::Socket::Async broken in 6.d.PREVIEW

On Wed, 01 Feb 2017 13:11:21 -0800, j...@gellyfish.co.uk wrote: > With 6.d.PREVIEW the simplest code for IO::Socket::Async mis-behaves: > > use v6.d.PREVIEW; > > react { > whenever IO::Socket::Async.listen('localhost', ) -> $conn { > whenever $conn.Supply(:bin) ->

[perl #130692] [BUG] IO::Socket::Async broken in 6.d.PREVIEW

On Wed, 01 Feb 2017 13:11:21 -0800, j...@gellyfish.co.uk wrote: > With 6.d.PREVIEW the simplest code for IO::Socket::Async mis-behaves: > > use v6.d.PREVIEW; > > react { > whenever IO::Socket::Async.listen('localhost', ) -> $conn { > whenever $conn.Supply(:bin) ->

[perl #122790] [CONC] Tapping multiple signals fails strangely

On Tue, 16 Sep 2014 07:51:34 -0700, 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(SIGIN

[perl #122790] [CONC] Tapping multiple signals fails strangely

On Tue, 16 Sep 2014 07:51:34 -0700, 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(SIGIN

[perl #124005] [CONC] Cannot read from STDIN in a thread on windows console

On Fri, 19 Aug 2016 12:04:15 -0700, c...@zoffix.com wrote: > Tests appear to exist in t/spec/S16-io/handles-between-threads.t And have been fully passing since earlier this year when the issue of handles between threads was addressed; resolving.

[perl #124005] [CONC] Cannot read from STDIN in a thread on windows console

On Fri, 19 Aug 2016 12:04:15 -0700, c...@zoffix.com wrote: > Tests appear to exist in t/spec/S16-io/handles-between-threads.t And have been fully passing since earlier this year when the issue of handles between threads was addressed; resolving.

[perl #125230] [BUG] Reading from $*IN in a sub process' start {} hangs

On Thu, 21 May 2015 12:50:18 -0700, tony.od...@live.com wrote: > Encountered the following problem implementing Event::Emitter between > processes. This code will run forever as .read(1) forever reads > nothing from $*IN > > > #!/usr/bin/env perl6 > > > > > my $p = Proc::Async.new('perl6', '

[perl #125230] [BUG] Reading from $*IN in a sub process' start {} hangs

On Thu, 21 May 2015 12:50:18 -0700, tony.od...@live.com wrote: > Encountered the following problem implementing Event::Emitter between > processes. This code will run forever as .read(1) forever reads > nothing from $*IN > > > #!/usr/bin/env perl6 > > > > > my $p = Proc::Async.new('perl6', '

[perl #126692] [RFC] wrong line number in error message using Promise

On Fri, 20 Nov 2015 08:19:56 -0800, mt1...@gmail.com wrote: > Hi, > > When using 'my $p = Promise.start($code)' and die in that code for some > reason, I will get the die error message but the line number is of the > 'await $p' line. It would be more helpful to have the line number of the > ori

[perl #126692] [RFC] wrong line number in error message using Promise

On Fri, 20 Nov 2015 08:19:56 -0800, mt1...@gmail.com wrote: > Hi, > > When using 'my $p = Promise.start($code)' and die in that code for some > reason, I will get the die error message but the line number is of the > 'await $p' line. It would be more helpful to have the line number of the > ori

[perl #129941] [PERF] [IO] Perl 6 text file line read is much slower than Perl 5

On Mon, 24 Oct 2016 03:27:55 -0700, tbrowder wrote: > On Sat Oct 22 04:24:15 2016, tbrowder wrote: > > See for a suite > > of tests that show the differences. > > Suite has been updated considerably. In a benchmark on my local machine, after ma

[perl #129941] [PERF] [IO] Perl 6 text file line read is much slower than Perl 5

On Mon, 24 Oct 2016 03:27:55 -0700, tbrowder wrote: > On Sat Oct 22 04:24:15 2016, tbrowder wrote: > > See for a suite > > of tests that show the differences. > > Suite has been updated considerably. In a benchmark on my local machine, after ma

[perl #130417] [CONC] Take care of cas

On Tue, 27 Dec 2016 12:32:50 -0800, alex.jakime...@gmail.com wrote: > https://github.com/rakudo/rakudo/blob/9594a3ece38ca212023cf3ece7405d955303db13/src/core/asyncops.pm#L50 > > I thought I killed that off once > I did in 539b5f44ef3f pre-xmas > Because I thought it was pretty ridiculous having

[perl #130417] [CONC] Take care of cas

On Tue, 27 Dec 2016 12:32:50 -0800, alex.jakime...@gmail.com wrote: > https://github.com/rakudo/rakudo/blob/9594a3ece38ca212023cf3ece7405d955303db13/src/core/asyncops.pm#L50 > > I thought I killed that off once > I did in 539b5f44ef3f pre-xmas > Because I thought it was pretty ridiculous having

[perl #131387] `is default` value not applied to attributes by default

On Sat, 27 May 2017 19:35:53 -0700, c...@zoffix.com wrote: > $z is `Nil` without my having to assign anything, while `$!z` is Any. > To make `$!z` Nil I also have to assign Nil to it: > > m: my $z is default(Nil); dd $z;class Foo { has $!z is > default(Nil); method x { dd $!z } }.new.x > rak

[perl #131387] `is default` value not applied to attributes by default

On Sat, 27 May 2017 19:35:53 -0700, c...@zoffix.com wrote: > $z is `Nil` without my having to assign anything, while `$!z` is Any. > To make `$!z` Nil I also have to assign Nil to it: > > m: my $z is default(Nil); dd $z;class Foo { has $!z is > default(Nil); method x { dd $!z } }.new.x > rak

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

On Sat, 09 Sep 2017 19:53:53 -0700, 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

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

On Sat, 09 Sep 2017 19:53:53 -0700, 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

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

On Thu, 07 Sep 2017 13:33:30 -0700, 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

[perl #132045] [BUG] Cannot use [] to parameterize a role unless it's known at compile time and it's a bareword.

On Thu, 07 Sep 2017 14:53:44 -0700, ben-goldb...@hotmail.com wrote: > The following code samples work as expected: > > m: use MONKEY; my $m = 'foo'; my $p = EVAL qq!role :: > [\$value] \{ method $m \{ \$value } }!; say $p.^parameterize(42).foo; > <+camelia> rakudo-moar e7a588: OUTPUT: «42␤» > >

[perl #132045] [BUG] Cannot use [] to parameterize a role unless it's known at compile time and it's a bareword.

On Thu, 07 Sep 2017 14:53:44 -0700, ben-goldb...@hotmail.com wrote: > The following code samples work as expected: > > m: use MONKEY; my $m = 'foo'; my $p = EVAL qq!role :: > [\$value] \{ method $m \{ \$value } }!; say $p.^parameterize(42).foo; > <+camelia> rakudo-moar e7a588: OUTPUT: «42␤» > >

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

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

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

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

[perl #132035] [LTA] temp on an undeclared dynamic variable produces a not very helpful error

On Tue, 05 Sep 2017 11:02:59 -0700, allber...@gmail.com wrote: > Or maybe it's not that tricky after all; seems the Failure is actually a > useful one (X::Dynamic:NotFound), so introspection of the Failure would > reveal the issue. > Indeed. I added code to check if the thing we were trying to tem

[perl #132035] [LTA] temp on an undeclared dynamic variable produces a not very helpful error

On Tue, 05 Sep 2017 11:02:59 -0700, allber...@gmail.com wrote: > Or maybe it's not that tricky after all; seems the Failure is actually a > useful one (X::Dynamic:NotFound), so introspection of the Failure would > reveal the issue. > Indeed. I added code to check if the thing we were trying to tem

[perl #130855] [SPESH][OPTIMIZER] glitch with anon vars causes incorrect `Cannot assign to an immutable value` error

On Fri, 24 Feb 2017 15:02:23 -0800, c...@zoffix.com wrote: > Expected no errors, but in the first case it complains about > assignment to immutable value even though none exist in the code. > > zoffix@VirtualBox:~$ perl6 -e 'm: sub foo () {$ = 42}; for ^200 { > $ = foo }; say now - INIT now' >

[perl #130855] [SPESH][OPTIMIZER] glitch with anon vars causes incorrect `Cannot assign to an immutable value` error

On Fri, 24 Feb 2017 15:02:23 -0800, c...@zoffix.com wrote: > Expected no errors, but in the first case it complains about > assignment to immutable value even though none exist in the code. > > zoffix@VirtualBox:~$ perl6 -e 'm: sub foo () {$ = 42}; for ^200 { > $ = foo }; say now - INIT now' >

[perl #131985] [CONC] Curly-brace string interpolation is not thread safe

On Mon, 28 Aug 2017 17:59:39 -0700, j.david.l...@apple.com wrote: > This short program behaves strangely on my system: > > ``` > #!/usr/bin/env perl6 > > use v6.c; > > await((1 .. 5).map: -> $tid { >start { > for (1 .. 100) -> $index { > my $s-tid = "{$tid}"; > my $

[perl #131985] [CONC] Curly-brace string interpolation is not thread safe

On Mon, 28 Aug 2017 17:59:39 -0700, j.david.l...@apple.com wrote: > This short program behaves strangely on my system: > > ``` > #!/usr/bin/env perl6 > > use v6.c; > > await((1 .. 5).map: -> $tid { >start { > for (1 .. 100) -> $index { > my $s-tid = "{$tid}"; > my $

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

On Tue, 05 Sep 2017 05:29:00 -0700, 1parr...@gmail.com wrote: > Perl 5 programmers are used to being casual about closing file > handles. Obviously, 6 requires a change of habits. A cultural shift, > if that's not too pretentious a term. Perhaps it needs to be mentioned > in large, friendly letters

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

On Tue, 05 Sep 2017 05:29:00 -0700, 1parr...@gmail.com wrote: > Perl 5 programmers are used to being casual about closing file > handles. Obviously, 6 requires a change of habits. A cultural shift, > if that's not too pretentious a term. Perhaps it needs to be mentioned > in large, friendly letters

[perl #132029] Floppage of atomic tests

On Tue, 05 Sep 2017 00:36:34 -0700, n...@detonation.org wrote: > A golfed version that reliably fails: > > { > my Int $test-cont = 42; > ⚛$test-cont; > } > { > my atomicint $set = 0; > start { sleep 1; $set ⚛= 1 }; > until ⚛$set { } > } > > The important bit is the Int being r

[perl #132029] Floppage of atomic tests

On Tue, 05 Sep 2017 00:36:34 -0700, n...@detonation.org wrote: > A golfed version that reliably fails: > > { > my Int $test-cont = 42; > ⚛$test-cont; > } > { > my atomicint $set = 0; > start { sleep 1; $set ⚛= 1 }; > until ⚛$set { } > } > > The important bit is the Int being r

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

On Tue, 05 Sep 2017 00:54:27 -0700, 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

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

On Tue, 05 Sep 2017 00:54:27 -0700, 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

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

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

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

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

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

On Fri, 01 Sep 2017 20:15:07 -0700, 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. wit

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

On Fri, 01 Sep 2017 20:15:07 -0700, 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. wit

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

On Mon, 07 Aug 2017 19:48:36 -0700, 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

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

On Mon, 07 Aug 2017 19:48:36 -0700, 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

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

On Wed, 16 Aug 2017 14:53:05 -0700, alex.jakime...@gmail.com wrote: > 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: > «138

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

On Wed, 16 Aug 2017 14:53:05 -0700, alex.jakime...@gmail.com wrote: > 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: > «138

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

On Sun, 16 Jul 2017 23:49:55 -0700, j...@durchholz.org wrote: > 6) If somebody writes his own module in a different location but with > a > matching name (e.g. they might be writing a wrapper, or an emulator), > then these files will be filtered as well. > The filenames end in .nqp. A Perl 6 use

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

On Sun, 16 Jul 2017 23:49:55 -0700, j...@durchholz.org wrote: > 6) If somebody writes his own module in a different location but with > a > matching name (e.g. they might be writing a wrapper, or an emulator), > then these files will be filtered as well. > The filenames end in .nqp. A Perl 6 use

[perl #131755] Weird 'Reading from filehandle failed: Bad file descriptor' Error Affected by Comments in Code

On Sat, 15 Jul 2017 12:07:19 -0700, c...@zoffix.com wrote: > The original failure was in t/spec/S32-io/open.t test that I golfed > down to the following: > > ---8<- > $*IN = IO::Handle.new: :path('-'.IO); > $*IN.open; > $*OUT.open: :w; > > my $w

[perl #131755] Weird 'Reading from filehandle failed: Bad file descriptor' Error Affected by Comments in Code

On Sat, 15 Jul 2017 12:07:19 -0700, c...@zoffix.com wrote: > The original failure was in t/spec/S32-io/open.t test that I golfed > down to the following: > > ---8<- > $*IN = IO::Handle.new: :path('-'.IO); > $*IN.open; > $*OUT.open: :w; > > my $w

[perl #130760] Rakudo's usage message in the case of illegal options is printed to STDOUT, not STDERR

On Fri, 14 Jul 2017 09:15:59 -0700, jn...@jnthn.net wrote: > On Sat, 11 Feb 2017 00:42:38 -0800, moritz wrote: > > $ perl6 --type=foo examples/dirstat.p6 > /dev/null > > $ > > This is Rakudo version 2017.01-170-gc0a907f built on MoarVM version > > 2017.01-31-g20dfa6b > > implementing Perl 6.c. > >

[perl #130760] Rakudo's usage message in the case of illegal options is printed to STDOUT, not STDERR

On Fri, 14 Jul 2017 09:15:59 -0700, jn...@jnthn.net wrote: > On Sat, 11 Feb 2017 00:42:38 -0800, moritz wrote: > > $ perl6 --type=foo examples/dirstat.p6 > /dev/null > > $ > > This is Rakudo version 2017.01-170-gc0a907f built on MoarVM version > > 2017.01-31-g20dfa6b > > implementing Perl 6.c. > >

[perl #130760] Rakudo's usage message in the case of illegal options is printed to STDOUT, not STDERR

On Sat, 11 Feb 2017 00:42:38 -0800, moritz wrote: > $ perl6 --type=foo examples/dirstat.p6 > /dev/null > $ > This is Rakudo version 2017.01-170-gc0a907f built on MoarVM version > 2017.01-31-g20dfa6b > implementing Perl 6.c. > > Error messages should go to STDERR, so that pipes and redirects work a

[perl #130760] Rakudo's usage message in the case of illegal options is printed to STDOUT, not STDERR

On Sat, 11 Feb 2017 00:42:38 -0800, moritz wrote: > $ perl6 --type=foo examples/dirstat.p6 > /dev/null > $ > This is Rakudo version 2017.01-170-gc0a907f built on MoarVM version > 2017.01-31-g20dfa6b > implementing Perl 6.c. > > Error messages should go to STDERR, so that pipes and redirects work a

[perl #131673] `is rw` on anon parameter causes "inconsistent bind result" error

On Wed, 28 Jun 2017 16:05:50 -0700, c...@zoffix.com wrote: > Works as expected: > 23:03 m: sub ($x is rw) {}(42) > camelia rakudo-moar 2a8d1e: OUTPUT: «Parameter '$x' expected > a writable container, but got Int value␤ in sub at line 1␤ > in block at line 1␤␤

[perl #131673] `is rw` on anon parameter causes "inconsistent bind result" error

On Wed, 28 Jun 2017 16:05:50 -0700, c...@zoffix.com wrote: > Works as expected: > 23:03 m: sub ($x is rw) {}(42) > camelia rakudo-moar 2a8d1e: OUTPUT: «Parameter '$x' expected > a writable container, but got Int value␤ in sub at line 1␤ > in block at line 1␤␤

[perl #131488] [BUG] .map as return value of sunk Promise doesn't get sunk

On Fri, 02 Jun 2017 15:43:07 -0700, c...@zoffix.com wrote: > Normally, if you sink a .map, it gets eagerly evaluated: > > m: .map: &say > rakudo-moar ef9872: OUTPUT: «a␤b␤c␤» > m: for ^1 { .map: &say; $ = 42 } > rakudo-moar ef9872: OUTPUT: «a␤b␤c␤» > > However, this doesn't ha

[perl #131488] [BUG] .map as return value of sunk Promise doesn't get sunk

On Fri, 02 Jun 2017 15:43:07 -0700, c...@zoffix.com wrote: > Normally, if you sink a .map, it gets eagerly evaluated: > > m: .map: &say > rakudo-moar ef9872: OUTPUT: «a␤b␤c␤» > m: for ^1 { .map: &say; $ = 42 } > rakudo-moar ef9872: OUTPUT: «a␤b␤c␤» > > However, this doesn't ha

[perl #131365] [IO] IO::Handle.getc returns too-many chars at the end of file

On Thu, 25 May 2017 08:26:18 -0700, c...@zoffix.com wrote: > IRC: https://irclog.perlgeek.de/perl6-dev/2017-05-25#i_14636375 > > Note how the last item in the returned list contains a string with > more than on character: > > 15:17 Zoffix m: with '/tmp/foo70'.IO { .spurt: "a♥c"; with .open { >

[perl #131383] [IO][MOAR][REGRESSION] .readchars($size) sometimes returns $size+1 chars

On Sat, 27 May 2017 07:06:59 -0700, c...@zoffix.com wrote: > Seems something with decoding actually, since using char of different > size or adding another char after the heart avoids the issue: > > m: my $f1 = "/tmp/foo121212".IO; $f1.spurt: "fo♥"; > $f1.open.readchars(2).say > rakudo-moar 0c5f

  1   2   3   4   5   6   7   8   >