Re: [perl #127682] [OSX] writing more than 8192 bytes to IO::Handle causes it to hang forever
When I filed this ticket I kinda expected that somehow rakudo or libuv
would handle this for me under the hood. But what Timo and Brandon say
makes sense. The process is still running when you slurp-rest. slurp-rest
neds EOF before it stops blocking. It will never get it because the writing
process is keeping itself alive until it can finish writing to ERR. But it
will never finish because it's still needs to write the 8193rd byte.
Consider:
$ perl6 -e 'my $proc = run($*EXECUTABLE, "-e", q| $*OUT.print("win\n");
$*ERR.print("8" x 8193);|,:out,:err); say $proc.out.get'
win
Using .get instead of slurp-rest works fine. This suggested to me that
waiting for the process to finish before .slurp-rest would work. And it did
perl6 -e 'my $proc = run($*EXECUTABLE, "-e", q| $*OUT.print("win\n");
$*ERR.print("8" x 8193);|,:out,:err); $proc.exitcode; say
$proc.out.slurp-rest'
win
But for some reason, just sleeping didn't:
perl6 -e 'my $proc = run($*EXECUTABLE, "-e", q| $*OUT.print("win\n");
$*ERR.print("8" x 8193);|,:out,:err); sleep 1; say $proc.out.slurp-rest' #
hangs forever
I'd say this is closable. The solution is to wait for the process to exit
before reading or to use Proc::Async.
Thanks!
On Thu, Mar 8, 2018 at 2:51 PM Brandon Allbery via RT <
perl6-bugs-follo...@perl.org> wrote:
> And in the cases where it "works", the buffer is larger. Which runs the
> risk of consuming all available memory in the worst case, if someone tries
> to "make it work" with an expanding buffer. The fundamental deadlock
> between processes blocked on I/O is not solved by buffering. Something
> needs to actually consume data instead of blocking, to break the deadlock.
>
> Perl 5 and Python both call this the open3 problem.
>
> On Wed, Mar 7, 2018 at 6:42 PM, Timo Paulssen wrote:
>
> > This is a well-known problem in IPC. If you don't do it async, you risk
> > the buffer you're not currently reading from filling up completely. Now
> > your client program is trying to write to stderr, but can't because it's
> > full. Your parent program is hoping to read from stdin, but nothing is
> > arriving, and it never reads from stderr, so it's a deadlock.
> >
> > Wouldn't call this a rakudo bug.
> >
> >
> > On 07/03/18 23:04, Christian Bartolomaeus via RT wrote:
> > > On Fri, 10 Feb 2017 23:48:54 -0800, barto...@gmx.de wrote:
> > >> FWIW that hangs on FreeBSD as well (maybe not too much a surprise,
> > >> given the relationship of the OSes).
> > > Hmm, looks like it hangs on Linux too -- with more than 224000 bytes on
> > my machine:
> > >
> > > $ perl6 -e 'my $proc = run($*EXECUTABLE, "-e", q| $*ERR.print("8" x
> > 224001);|,:out,:err); say $proc.out.slurp' ## hangs
> > > ^C
> > > $ perl6 --version
> > > This is Rakudo Star version 2017.10 built on MoarVM version 2017.10
> > > implementing Perl 6.c.
> > > $ uname -a
> > > Linux p6 3.2.0-4-amd64 #1 SMP Debian 3.2.96-2 x86_64 GNU/Linux
> >
>
>
>
> --
> brandon s allbery kf8nh sine nomine
> associates
> allber...@gmail.com
> ballb...@sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>
>
Re: [perl #132512] [REGRESSION] make in regex on uncomposed type results in Nil
Changing uncomposed type objects to Nil for the specific case of .ast/.made
is definitely incorrect IMO.
It happens for the exact reason lizmat said in her commit: "Wish there was
a better way to test for NQPMu
though, as this will prevent type objects being properly propagated"
Although it looks like this has been fixed for composed type objects in a
following patch. It now looks like:
method ast() { nqp::if(nqp::istype($!made, Mu),$!made,Nil) }
But since uncomposed type objects don't inherit from Mu we have the bug.
On Tue, Nov 28, 2017 at 3:26 PM Aleks-Daniel Jakimenko-Aleksejev via RT <
perl6-bugs-follo...@perl.org> wrote:
> OK, the change from True to False happened here: (2017-08-21)
>
> https://github.com/rakudo/rakudo/commit/5db5b1dbfa0b625130573574e2409972387e9f75
>
> I'm not entirely convinced that the current behavior is incorrect, but then
> again I'm sleep deprived. Maybe someone else will have a better idea.
>
> On 2017-11-27 19:00:45, lloyd.fo...@gmail.com wrote:
> > Good point. Here "No such method 'gist' for invocant of type 'Foo'
> > in block at /tmp/aR11azfzlJ line 1" is the right one.
> >
> > This will give True/False indicating correct/incorrect:
> >
> > my $new_type := Metamodel::ClassHOW.new_type(:name);
> > my $r = / . { $/.make($new_type) } /;
> > my $m = "a" ~~ $r;
> > note $m.ast.^name eq "Foo";
> >
> > Thanks for bisecting magic!
> >
> > On Tue, Nov 28, 2017 at 1:54 PM Aleks-Daniel Jakimenko-Aleksejev via
> > RT <
> > perl6-bugs-follo...@perl.org> wrote:
> >
> > > What do you mean exactly by “used to work”? Here's the output on all
> > > 6c
> > > releases: https://gist.github.com/efee7716c35d36c6f793465c2f0b6035
> > >
> > > Which behavior is right? Or what's would be the right snippet to
> > > reproduce
> > > it?
> > >
> > > On 2017-11-27 18:48:07, lloyd.fo...@gmail.com wrote:
> > > > Just got around to investigating: https://rt.perl.org/Ticket/Dis
> > > > play.html?id=132085
> > > >
> > > > It turns out to be a regression.
> > > >
> > > > my $new_type := Metamodel::ClassHOW.new_type(:name);
> > > > my $r = / . { make $new_type } /;
> > > > my $m = "a" ~~ $r;
> > > > note $m.ast; #-> Nil
> > > >
> > > > making an uncomposed type somehow results in Nil now. It used to
> > > > work. In
> > > > my compiler I can't really get around needing this to work.
> > > >
> > > > LL
> > >
> > >
>
>
Re: [perl #132512] [REGRESSION] make in regex on uncomposed type results in Nil
Good point. Here "No such method 'gist' for invocant of type 'Foo'
in block at /tmp/aR11azfzlJ line 1" is the right one.
This will give True/False indicating correct/incorrect:
my $new_type := Metamodel::ClassHOW.new_type(:name);
my $r = / . { $/.make($new_type) } /;
my $m = "a" ~~ $r;
note $m.ast.^name eq "Foo";
Thanks for bisecting magic!
On Tue, Nov 28, 2017 at 1:54 PM Aleks-Daniel Jakimenko-Aleksejev via RT <
perl6-bugs-follo...@perl.org> wrote:
> What do you mean exactly by “used to work”? Here's the output on all 6c
> releases: https://gist.github.com/efee7716c35d36c6f793465c2f0b6035
>
> Which behavior is right? Or what's would be the right snippet to reproduce
> it?
>
> On 2017-11-27 18:48:07, lloyd.fo...@gmail.com wrote:
> > Just got around to investigating: https://rt.perl.org/Ticket/Dis
> > play.html?id=132085
> >
> > It turns out to be a regression.
> >
> > my $new_type := Metamodel::ClassHOW.new_type(:name);
> > my $r = / . { make $new_type } /;
> > my $m = "a" ~~ $r;
> > note $m.ast; #-> Nil
> >
> > making an uncomposed type somehow results in Nil now. It used to work. In
> > my compiler I can't really get around needing this to work.
> >
> > LL
>
>
Re: [perl #127020] [PERF] pod parsing memory is never freed
Probably one of a number of things that would be easy if we made pod another language on the braid :) On Mon, Nov 27, 2017 at 11:59 AM Timo Paulssen via RT < perl6-bugs-follo...@perl.org> wrote: > a look at a profile makes me suspect the problem is having > pod_string_character match a single character at a time, causing rather > large numbers of match objects for comparatively short strings. > > It's probably worthwhile to steal a piece of implementation from > "nibbling", aka parsing strings. a very short glance points do_nibbling out > as interesting. >
Re: [perl #130982] [PERF] "for $a..$b -> $i { ... }" loops are sometimes much slower than c-style loops
For comparison to march on the same comp: bash-3.2$ perl6 perf.p6 perl6-loop: 63.0037058 c-loop: 76.86853305 (0.82 times faster) native-loop: 0.2170930 (354.08 times faster) perl6 loops are faster. c style loops are slower. Native loops are even faster relative to the others (for me). We can probably close this RT. Seeing as the issue in the title has been addressed kinda :P LL On Sun, Nov 19, 2017 at 1:05 PM Daniel Green via RT < perl6-bugs-follo...@perl.org> wrote: > On Sun, 12 Mar 2017 07:27:37 -0700, allber...@gmail.com wrote: > > On Sun, Mar 12, 2017 at 12:48 AM, Lloyd Fournier > > wrote: > > > > > perl6-loop: 84.8739988 > > > c-loop: 67.65849241 (1.25 times faster) > > > native-loop: 0.4981954 (135.81 times faster) > > > > > > > Still quite a lot of optimization to be done on that front. WRT native > int, > > one of the issues is needing to track when boxing is/isn't needed, > > otherwise nativizing can be a pessimization because of constant reboxing. > > The optimizer isn't up to tracking boxing like that yet. > > > > FWIW. > > $ perl6 native-int-perf.p6 > perl6-loop: 117.55178620 > c-loop: 156.7308145 (0.75 times faster) > native-loop: 1.2542871 (124.96 times faster) > > $ perl6 --version > This is Rakudo version 2017.10-211-g2f0da94c3 built on MoarVM version > 2017.10-82-ge876f1484 >
Re: [perl #132085] [REGRESSION] Possible regression after Match.(made|ast) changes
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. >
Re: [perl #127858] [BUG] "Cannot invoke this object" error while importing an array constant
Fix reverted:
https://github.com/rakudo/rakudo/commit/50d38a1f368f0addb601e857232642f3a8de3aa2
should be re-opened :)
On Tue, Jul 25, 2017 at 11:45 PM Lloyd Fournier via RT <
perl6-bugs-follo...@perl.org> wrote:
> merged patch: https://github.com/rakudo/rakudo/pull/
> tests: https://github.com/perl6/roast/pull/291/files
> can be closed
>
> On Fri, Apr 8, 2016 at 7:16 PM grond...@yahoo.fr <
> perl6-bugs-follo...@perl.org> wrote:
>
> > # New Ticket Created by grond...@yahoo.fr
> > # Please include the string: [perl #127858]
> > # in the subject line of all future correspondence about this issue.
> > # https://rt.perl.org/Ticket/Display.html?id=127858 >
> >
> >
> > $ cat > A.pm6
> > unit module A;
> >
> > constant @a is export = map { (1 +< $_) => 1 }, ^3;
> >
> > $ PERL6LIB=. perl6 -e 'use A; say @a[1];'
> > Cannot invoke this object
> > in block at /home/grondilu/A.pm6 (A) line 3
> > in block at -e line 1
> >
> > $ perl6 -e 'module A { constant @a is export = map { (1 +< $_) => 1 },
> ^3;
> > }; import A; say @a[1];'
> > 2 => 1
> >
> > $ perl6 --version
> > This is Rakudo version 2016.03-88-g600eb53 built on MoarVM version
> > 2016.03-84-g4afd7b6
> > implementing Perl 6.c.
> >
>
Re: [perl #131705] constant Regex: getlex: outer index out of range
Fix reverted:
https://github.com/rakudo/rakudo/commit/50d38a1f368f0addb601e857232642f3a8de3aa2
should be re-opened :)
On Tue, Jul 25, 2017 at 11:42 PM Lloyd Fournier via RT <
perl6-bugs-follo...@perl.org> wrote:
> merged patch: https://github.com/rakudo/rakudo/pull/
> tests: https://github.com/perl6/roast/pull/291/files
> can be closed
>
> On Wed, Jul 5, 2017 at 3:42 PM Lloyd Fournier <
> perl6-bugs-follo...@perl.org>
> wrote:
>
> > # New Ticket Created by Lloyd Fournier
> > # Please include the string: [perl #131705]
> > # in the subject line of all future correspondence about this issue.
> > # https://rt.perl.org/Ticket/Display.html?id=131705 >
> >
> >
> > echo 'constant @foo is export = /{ say "hello" } ./, > Foo.pm6
> >
> > perl6 -I. -e 'use Foo; "foo" ~~ @foo[0];
> >
> > # getlex: outer index out of range
> >
> > This is another compile time outer lexical scope bug. Note: the array is
> > superfluous, just there to avoid triggering RT #131704.
> >
>
Re: [perl #127858] [BUG] "Cannot invoke this object" error while importing an array constant
merged patch: https://github.com/rakudo/rakudo/pull/
tests: https://github.com/perl6/roast/pull/291/files
can be closed
On Fri, Apr 8, 2016 at 7:16 PM grond...@yahoo.fr <
perl6-bugs-follo...@perl.org> wrote:
> # New Ticket Created by grond...@yahoo.fr
> # Please include the string: [perl #127858]
> # in the subject line of all future correspondence about this issue.
> # https://rt.perl.org/Ticket/Display.html?id=127858 >
>
>
> $ cat > A.pm6
> unit module A;
>
> constant @a is export = map { (1 +< $_) => 1 }, ^3;
>
> $ PERL6LIB=. perl6 -e 'use A; say @a[1];'
> Cannot invoke this object
> in block at /home/grondilu/A.pm6 (A) line 3
> in block at -e line 1
>
> $ perl6 -e 'module A { constant @a is export = map { (1 +< $_) => 1 }, ^3;
> }; import A; say @a[1];'
> 2 => 1
>
> $ perl6 --version
> This is Rakudo version 2016.03-88-g600eb53 built on MoarVM version
> 2016.03-84-g4afd7b6
> implementing Perl 6.c.
>
Re: [perl #131705] constant Regex: getlex: outer index out of range
merged patch: https://github.com/rakudo/rakudo/pull/
tests: https://github.com/perl6/roast/pull/291/files
can be closed
On Wed, Jul 5, 2017 at 3:42 PM Lloyd Fournier
wrote:
> # New Ticket Created by Lloyd Fournier
> # Please include the string: [perl #131705]
> # in the subject line of all future correspondence about this issue.
> # https://rt.perl.org/Ticket/Display.html?id=131705 >
>
>
> echo 'constant @foo is export = /{ say "hello" } ./, > Foo.pm6
>
> perl6 -I. -e 'use Foo; "foo" ~~ @foo[0];
>
> # getlex: outer index out of range
>
> This is another compile time outer lexical scope bug. Note: the array is
> superfluous, just there to avoid triggering RT #131704.
>
Re: [perl #131781] :?smth should construct a truthy pair (say (:?foo))
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/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
Re: [perl #131781] :?smth should construct a truthy pair (say (:?foo))
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);
> > > > 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 `":"`
> >
Re: [perl #131774] [PERF] Simple, if artificial, string concatenation example hogs memory and time
I did an experiment a while ago and found that string concatenation in a
loop was Ο(n²) in rakudo. I asked about it on irc and jnthn explained to me
that this was expected because strings are immutable (and therefore wasn't
worth RTing):
https://irclog.perlgeek.de/perl6/2015-12-15#i_11720228
(some encoding issue causes Ο(n²) to have a bunch of Ãs in it)
On Fri, Jul 21, 2017 at 6:39 AM Ron Schmidt
wrote:
> # New Ticket Created by Ron Schmidt
> # Please include the string: [perl #131774]
> # in the subject line of all future correspondence about this issue.
> # https://rt.perl.org/Ticket/Display.html?id=131774 >
>
>
> From IRC:
>
> https://irclog.perlgeek.de/perl6-dev/2017-07-19#i_14893012
>
> https://irclog.perlgeek.de/perl6/2017-07-20#i_14899215
>
> Code example:
>
> for (50_000, 75_000) -> $limit {my $x; my $y = "x" x 100; $x ~= $y for
> (1..$limit); say "$limit: ", now - ENTER now}
>
> Gets a MoarVM memory panic from the eval bot for 75_000 constructing a
> 7.5 Meg string. According to valgrind 50_000 was allocating 10GB of
> memory. At a concat count of 150_000 Perl 5 finishes in hundredths of a
> second where p6 takes around a minute and the growth in time with p6 is
> clearly worse than linear. "blead" updates as of July 20 include some
> improvements and timotimo on IRC mentioned that he is working on others.
>
Re: [perl #131681] default values in subsignitures don't work
That makes sense.
Thank you!
On Mon, Jul 3, 2017 at 8:09 PM jn...@jnthn.net via RT <
perl6-bugs-follo...@perl.org> wrote:
> On Fri, 30 Jun 2017 06:41:35 -0700, lloyd.fo...@gmail.com wrote:
> > sub foo( %h ( :$foo = "bar", :$baz) ) {
> > %h;
> > }
> >
> > note foo( { :baz } ); #-> {baz => True}
> >
> > If it's not an easy fix it might warrant a "not yet implemented"
> exception.
>
> It works correctly. Doing:
>
> sub foo( %h ( :$foo = "bar", :$baz) ) {
> say $foo
> }
> foo({ foo => "baz" });
> foo({ baz => 42 });
>
> Gives the output:
>
> baz
> bar
>
> So, $foo is correctly set to the default when the hash is missing that
> key. You seem to be expecting that it would modify the original hash that
> was passed in. That is (very intentionally) not the case.
>
> /jnthn
>
Re: [perl #131584] [REGERSSION] EXPORTHOW SUPERSEDE/DECLARE Cannot invoke this object
Ohh and now we have toast:
https://toast.perl6.party/
Which shows maybe it was: 2017.05-394-g56e71d5
On Fri, Jun 16, 2017 at 10:13 PM Lloyd Fournier <
perl6-bugs-follo...@perl.org> wrote:
> # New Ticket Created by Lloyd Fournier
> # Please include the string: [perl #131584]
> # in the subject line of all future correspondence about this issue.
> # https://rt.perl.org/Ticket/Display.html?id=131584 >
>
>
> cat >A.pm6 <<'END'
> my package EXPORTHOW {
> package DECLARE {
> constant pokemon = Metamodel::ClassHOW;
> }
> package SUPERSEDE {
> constant grammar = Metamodel::ClassHOW
> }
> }
> END
> perl6 -I. -e 'use A;'
>
> ===SORRY!===
> Cannot invoke this object (REPR: Null; VMNull)
>
> This is Rakudo version 2017.05-454-g5facb26 built on MoarVM version
> 2017.05-85-g21ee1a5
> implementing Perl 6.c.
>
Re: [perl #131583] [BUG] Sort content of ^methods
Str.^methods.sort(*.name) Is easy enough once you know to do it :) I don't think we should specify a particular order for the returned methods and alphabetic sorting is kinda arbitrary. Why not sorted by class inheritance for example? On Fri, Jun 16, 2017 at 2:09 PM Gabor Szabo wrote: > # New Ticket Created by Gabor Szabo > # Please include the string: [perl #131583] > # in the subject line of all future correspondence about this issue. > # https://rt.perl.org/Ticket/Display.html?id=131583 > > > > I think it would be better to have the list returned by ^methods > sorted in abc order. >
Re: [perl #131528] [PRECOMP] Issues when sub itself instead of its "dispatcher" used in sub EXPORT
I think this is just another example of the compile time closures problem
since EXPORT runs at compile time in during the loading module's
compilation.
https://rt.perl.org/Public/Bug/Display.html?id=128636
For an example in my own code:
https://github.com/spitsh/spitsh/blob/master/lib/Spit/Constants.pm6
I can't put that sub definition in the constant assignment because it runs
at compile time.
On Thu, Jun 8, 2017 at 2:31 AM Zoffix Znet
wrote:
> # New Ticket Created by Zoffix Znet
> # Please include the string: [perl #131528]
> # in the subject line of all future correspondence about this issue.
> # https://rt.perl.org/Ticket/Display.html?id=131528 >
>
>
> From what I understand subs—even `only` subs—have another Sub playing the
> role of a dispatcher or whatever:
>
> m: sub foo {}.WHERE.say; &foo.WHERE.say
> rakudo-moar dbd0f8: OUTPUT: «139686084622776139686084191728»
>
> And it seems when the sub itself, instead of this "dispatcher", is used in
> sub EXPORT in a precompiled
> module that's used by another precompiled module, some wires get crossed
> over and the sub cannot be called:
>
> m: sub foo {}.WHERE.say; &foo.WHERE.say
> rakudo-moar dbd0f8: OUTPUT: «139686084622776139686084191728»
>
>
> $ cat Foo.pm6
> sub EXPORT {
> Map.new: '&foo' => sub foo { say 42 }
> }
>
> $ cat Bar.pm6
> use Foo;
> foo
>
> $ perl6 -I. -MFoo -e 'foo'
> 42
>
> $ perl6 -I. -MBar -e ''
> ===SORRY!===
> Cannot invoke this object (REPR: Null; VMNull)
> $
>
> Doing any of the following fixes the above bug:
>
> - adding `no precompilation` to Foo.pm6
> - adding `no precompilation` to Bar.pm6
> - instead of using the sub directly, defining it separately and using
> `&foo` as value in the Map
>
Re: [perl #131324] Inheriting from lexical classes seems borked
FWIW theoretically you get at any 'my' symbol in another module through the
compunit interface by getting the CompUnit::Handle and using the '.unit'
method to get the top lexpad of the loaded module.
On Fri, May 19, 2017 at 8:20 AM Zoffix Znet via RT <
perl6-bugs-follo...@perl.org> wrote:
> To the best of my knowledge:
>
> On Thu, 18 May 2017 03:52:42 -0700, elizabeth wrote:
> > Should this work? If not, why not?
>
> No, because the symbol is lexical to the compunit. It's the same as how
> you won't be able
> to access subs or `my` constants or variables, unless you make them `our`
> or export them.
>
> > What would be the way to inherit from lexical classes in other compunits?
>
> One way would be to export them:
>
> ./A.pm6:
> my class A is export {}
>
> ./B.pm6:
> my class B {
> use A;
> also is A;
> }
> say B.^mro;
>
> $ ./perl6 -I. -MB -e ''
> ((B) (A) (Any) (Mu))
>
>
> You can also use export sub:
> ./A.pm6:
> sub EXPORT {
> Map.new: 'A' => my class A {}
> }
>
> Or (I'm unsure what the end goal here is), take a special export arg and
> only export the class if it's present:
>
> ./A.pm6:
> sub EXPORT ($secret-password?) {
> Map.new: (
> 'A' => my class A {
> } if $secret-password ~~ 42
> )
> }
>
> ./B.pm6:
> my class B {
> use A;
> also is A;
> }
> say B.^mro;
>
> $ ./perl6 -I. -MB -e ''
> ===SORRY!=== Error while compiling /home/zoffix/CPANPRC/rakudo/B.pm6 (B)
> 'B' cannot inherit from 'A' because it is unknown.
> at /home/zoffix/CPANPRC/rakudo/B.pm6 (B):3
>
>
> Now change ./B.pm6 to:
> my class B {
> use A 42;
> also is A;
> }
> say B.^mro;
>
> $ ./perl6 -I. -MB -e ''
> ((B) (A) (Any) (Mu))
>
Re: [perl #129346] [BUG] Whatever being called on where-blocked subroutine cannot handle the sigilless values correctly
I think this is because .WHAT is a special case. It's not really a method
which is what you need to make *.method work. *.WHAT will always return
(Whatever) immediately.
There is an odd what of working around this:
perl6 -e 'sub foo(\a where *.&WHAT === Int ) { say "Hello"; }; foo(10); #
works
using the &WHAT sub with postfix syntax you get around the special casing.
I'm not sure if .WHAT special casing is considered a bug. I haven't been
able to find a pre-existing ticket wrt to it.
On Sat, Sep 24, 2016 at 4:42 PM Itsuki Toyota
wrote:
> # New Ticket Created by Itsuki Toyota
> # Please include the string: [perl #129346]
> # in the subject line of all future correspondence about this issue.
> # https://rt.perl.org/Ticket/Display.html?id=129346 >
>
>
> See the following results
>
> $ perl6 -e 'sub foo(\a where { *.WHAT === Int } ) { say "Hello"; };
> foo(10);'
> Constraint type check failed for parameter 'a'
> in sub foo at -e line 1
> in block at -e line 1
>
> $ perl6 -e 'sub foo(\a where -> \e { \e.WHAT === Int } ) { say "Hello"; };
> foo(10);'
> Constraint type check failed for parameter 'a'
> in sub foo at -e line 1
> in block at -e line 1
>
> $ perl6 -e 'sub foo(\a where -> \e { e.WHAT === Int } ) { say "Hello"; };
> foo(10);'
> Hello
>
> It seems that "Whatever *" cannot handle sigilless values correctly.
> I think that the 1st example should return the same result as the 3rd
> example.
>
>
>
> $ perl6 --version
> This is Rakudo version 2016.08.1-202-g78393dd built on MoarVM version
> 2016.08-47-g2eedba8
> implementing Perl 6.c.
>
Re: [perl #128553] multi method cache causes Base64 regression
I've been getting segfaults in this area recently. The trace is a bit
different but I guess it's related. It seems that flag_map in gc_mark is no
longer allocated so I get segfault.
(lldb) r
There is a running process, kill it and restart?: [Y/n] y
Process 75673 exited with status = 9 (0x0009)
Process 75691 launched: '/Users/llfourn/src/rakudo/install/bin/moar'
(x86_64)
Process 75691 stopped
* thread #1: tid = 0x23cfc68, 0x000100063ca4
libmoar.dylib`gc_mark(tc=0x000100500290, st=0x000101004f40,
data=, worklist=0x00010d27c1a0) + 84 at
MVMCallCapture.c:55, queue = 'com.apple.main-thread', stop reason =
EXC_BAD_ACCESS (code=1, address=0x10a72533)
frame #0: 0x000100063ca4
libmoar.dylib`gc_mark(tc=0x000100500290, st=0x000101004f40,
data=, worklist=0x00010d27c1a0) + 84 at MVMCallCapture.c:55
52 MVMuint16 count = ctx->arg_count;
53 MVMuint16 i, flag;
54 for (i = 0, flag = 0; i < count; i++, flag++) {
-> 55 if (flag_map[flag] & MVM_CALLSITE_ARG_NAMED) {
56 /* Current position is name, then next is value. */
57 MVM_gc_worklist_add(tc, worklist, &ctx->args[i].s);
58 i++;
(lldb) bt
* thread #1: tid = 0x23cfc68, 0x000100063ca4
libmoar.dylib`gc_mark(tc=0x000100500290, st=0x000101004f40,
data=, worklist=0x00010d27c1a0) + 84 at
MVMCallCapture.c:55, queue = 'com.apple.main-thread', stop reason =
EXC_BAD_ACCESS (code=1, address=0x10a72533)
* frame #0: 0x000100063ca4
libmoar.dylib`gc_mark(tc=0x000100500290, st=0x000101004f40,
data=, worklist=0x00010d27c1a0) + 84 at MVMCallCapture.c:55
frame #1: 0x00010003f002
libmoar.dylib`MVM_gc_mark_collectable(tc=,
worklist=, new_addr=) + 1714 at collect.c:399
frame #2: 0x00010003e883
libmoar.dylib`process_worklist(tc=0x000100500290,
worklist=0x00010d27c1a0, wtp=0x7fff5fbff468, gen='\0') + 899 at
collect.c:313
frame #3: 0x00010003e324
libmoar.dylib`MVM_gc_collect(tc=0x000100500290,
what_to_do=, gen=) + 820 at collect.c:129
frame #4: 0x00010003b703
libmoar.dylib`run_gc(tc=0x000100500290, what_to_do='\0') + 131 at
orchestrate.c:304
frame #5: 0x00010003b4c8
libmoar.dylib`MVM_gc_enter_from_allocator(tc=0x000100500290) + 984 at
orchestrate.c:438
frame #6: 0x00010003bca8 libmoar.dylib`MVM_gc_allocate_zeroed
[inlined] MVM_gc_allocate_nursery(tc=, size=) +
52 at allocation.c:32
frame #7: 0x00010003bc74 libmoar.dylib`MVM_gc_allocate_zeroed
[inlined] MVM_gc_allocate(tc=) + 23 at allocation.h:13
frame #8: 0x00010003bc5d
libmoar.dylib`MVM_gc_allocate_zeroed(tc=0x000100500290, size=40) + 13
at allocation.c:49
frame #9: 0x00010003bf44
libmoar.dylib`MVM_gc_allocate_object(tc=0x000100500290,
st=) + 84 at allocation.c:86
frame #10: 0x00010005813f libmoar.dylib`allocate(tc=,
st=) + 15 at P6opaque.c:60
frame #11: 0x000100050d27 libmoar.dylib`MVM_repr_box_str [inlined]
MVM_repr_alloc_init(tc=0x000100500290, type=0x000101626fc0) + 14 at
reprconv.c:13
frame #12: 0x000100050d19
libmoar.dylib`MVM_repr_box_str(tc=0x000100500290,
type=0x000101626fc0, val=) + 73 at reprconv.c:586
frame #13: 0x00019c07
libmoar.dylib`MVM_exception_backtrace(tc=0x000100500290,
ex_obj=) + at exceptions.c:407
frame #14: 0x000100017488
libmoar.dylib`MVM_interp_run(tc=0x000100500290,
initial_invoke=, invoke_data=) + 47320 at
interp.c:3830
frame #15: 0x0001000c8305
libmoar.dylib`MVM_vm_run_file(instance=,
filename=) + 181 at moar.c:304
frame #16: 0x0001170a moar`main(argc=,
argv=0x7fff5fbff8e8) + 666 at main.c:191
frame #17: 0x7fff900c05ad libdyld.dylib`start + 1
frame #18: 0x7fff900c05ad libdyld.dylib`start + 1
(lldb) fr v
(MVMThreadContext *) tc = 0x000100500290
(MVMSTable *) st = 0x000101004f40
(void *) data =
(MVMGCWorklist *) worklist = 0x00010d27c1a0
(MVMCallCaptureBody *) body =
(MVMArgProcContext *) ctx = 0x00010a6f3c00
(MVMuint16) flag = 0
(MVMuint16) i = 0
(MVMuint16) count =
(MVMuint8 *) flag_map = 0x10a72533 ""
(lldb) p flag_map
(MVMuint8 *) $6 = 0x10a72533 ""
(lldb) p flag_map[0]
error: Couldn't apply expression side effects : Couldn't dematerialize a
result variable: couldn't read its memory
On Sun, Jul 10, 2016 at 12:19 AM jn...@jnthn.net via RT <
perl6-bugs-follo...@perl.org> wrote:
> On Tue Jul 05 17:51:46 2016, ug...@cpan.org wrote:
> > Note that the final decode-base64 candidate shows the correct results
> > when debugging statements are added
> >
> > This gist also shows a small change that makes it produce the correct
> > values but it still segfaults more often than not
> > https://gist.github.com/ugexe/baa168a641894a0731595c812724f76d
>
> Having dug into it a little, I'm not sure that the new multi-caching stuff
> has caused this, so much as uncovered it (perhaps by moving GC colle
Re: [perl #128553] multi method cache causes Base64 regression
By flag_map I mean ctx->callsite->arg_flags:
(lldb) p ctx->arg_flags
(MVMCallsiteEntry *) $8 = 0x
(lldb) p ctx->callsite->arg_flags
(MVMCallsiteEntry *) $9 = 0x10a72533 ""
On Mon, Jul 11, 2016 at 3:59 AM Lloyd Fournier
wrote:
> I've been getting segfaults in this area recently. The trace is a bit
> different but I guess it's related. It seems that flag_map in gc_mark is no
> longer allocated so I get segfault.
>
> (lldb) r
> There is a running process, kill it and restart?: [Y/n] y
> Process 75673 exited with status = 9 (0x0009)
> Process 75691 launched: '/Users/llfourn/src/rakudo/install/bin/moar'
> (x86_64)
> Process 75691 stopped
> * thread #1: tid = 0x23cfc68, 0x000100063ca4
> libmoar.dylib`gc_mark(tc=0x000100500290, st=0x000101004f40,
> data=, worklist=0x00010d27c1a0) + 84 at
> MVMCallCapture.c:55, queue = 'com.apple.main-thread', stop reason =
> EXC_BAD_ACCESS (code=1, address=0x10a72533)
> frame #0: 0x000100063ca4
> libmoar.dylib`gc_mark(tc=0x000100500290, st=0x000101004f40,
> data=, worklist=0x00010d27c1a0) + 84 at MVMCallCapture.c:55
>52 MVMuint16 count = ctx->arg_count;
>53 MVMuint16 i, flag;
>54 for (i = 0, flag = 0; i < count; i++, flag++) {
> -> 55 if (flag_map[flag] & MVM_CALLSITE_ARG_NAMED) {
>56 /* Current position is name, then next is value. */
>57 MVM_gc_worklist_add(tc, worklist, &ctx->args[i].s);
>58 i++;
> (lldb) bt
> * thread #1: tid = 0x23cfc68, 0x000100063ca4
> libmoar.dylib`gc_mark(tc=0x000100500290, st=0x000101004f40,
> data=, worklist=0x00010d27c1a0) + 84 at
> MVMCallCapture.c:55, queue = 'com.apple.main-thread', stop reason =
> EXC_BAD_ACCESS (code=1, address=0x10a72533)
> * frame #0: 0x000100063ca4
> libmoar.dylib`gc_mark(tc=0x000100500290, st=0x000101004f40,
> data=, worklist=0x00010d27c1a0) + 84 at MVMCallCapture.c:55
> frame #1: 0x00010003f002
> libmoar.dylib`MVM_gc_mark_collectable(tc=,
> worklist=, new_addr=) + 1714 at collect.c:399
> frame #2: 0x00010003e883
> libmoar.dylib`process_worklist(tc=0x000100500290,
> worklist=0x00010d27c1a0, wtp=0x7fff5fbff468, gen='\0') + 899 at
> collect.c:313
> frame #3: 0x00010003e324
> libmoar.dylib`MVM_gc_collect(tc=0x000100500290,
> what_to_do=, gen=) + 820 at collect.c:129
> frame #4: 0x00010003b703
> libmoar.dylib`run_gc(tc=0x000100500290, what_to_do='\0') + 131 at
> orchestrate.c:304
> frame #5: 0x00010003b4c8
> libmoar.dylib`MVM_gc_enter_from_allocator(tc=0x000100500290) + 984 at
> orchestrate.c:438
> frame #6: 0x00010003bca8 libmoar.dylib`MVM_gc_allocate_zeroed
> [inlined] MVM_gc_allocate_nursery(tc=, size=) +
> 52 at allocation.c:32
> frame #7: 0x00010003bc74 libmoar.dylib`MVM_gc_allocate_zeroed
> [inlined] MVM_gc_allocate(tc=) + 23 at allocation.h:13
> frame #8: 0x00010003bc5d
> libmoar.dylib`MVM_gc_allocate_zeroed(tc=0x000100500290, size=40) + 13
> at allocation.c:49
> frame #9: 0x00010003bf44
> libmoar.dylib`MVM_gc_allocate_object(tc=0x000100500290,
> st=) + 84 at allocation.c:86
> frame #10: 0x00010005813f libmoar.dylib`allocate(tc=,
> st=) + 15 at P6opaque.c:60
> frame #11: 0x000100050d27 libmoar.dylib`MVM_repr_box_str [inlined]
> MVM_repr_alloc_init(tc=0x000100500290, type=0x000101626fc0) + 14 at
> reprconv.c:13
> frame #12: 0x000100050d19
> libmoar.dylib`MVM_repr_box_str(tc=0x000100500290,
> type=0x000101626fc0, val=) + 73 at reprconv.c:586
> frame #13: 0x00019c07
> libmoar.dylib`MVM_exception_backtrace(tc=0x000100500290,
> ex_obj=) + at exceptions.c:407
> frame #14: 0x000100017488
> libmoar.dylib`MVM_interp_run(tc=0x000100500290,
> initial_invoke=, invoke_data=) + 47320 at
> interp.c:3830
> frame #15: 0x0001000c8305
> libmoar.dylib`MVM_vm_run_file(instance=,
> filename=) + 181 at moar.c:304
> frame #16: 0x0001170a moar`main(argc=,
> argv=0x7fff5fbff8e8) + 666 at main.c:191
> frame #17: 0x7fff900c05ad libdyld.dylib`start + 1
> frame #18: 0x7fff900c05ad libdyld.dylib`start + 1
> (lldb) fr v
> (MVMThreadContext *) tc = 0x000100500290
> (MVMSTable *) st = 0x000101004f40
> (void *) data =
>
> (MVMGCWorklist *) worklist = 0x00010d27c1a0
> (MVMCallCaptureBody *) body = out>
>
> (MVMArgProcContext *) ctx = 0x00010a6f3c00
> (MVMuint16) flag = 0
> (MVMuint16) i = 0
> (MVMuint16) count =
>
> (MVMuint8 *) flag_map = 0x10a72533 ""
> (lldb) p flag_map
> (MVMuint8 *) $6 = 0x10a72533 ""
> (lldb) p flag_map[0]
> error: Couldn't apply expression side effects : Couldn't dematerialize a
> result variable: couldn't read its memory
>
> On Sun, Jul 10, 2016 at 12:19 AM jn...@jnthn.net via RT <
> perl6-bugs-follo...@perl.org> wrote:
>
>> On Tue Jul 05 17:51:46 2016, ug...@cpan.org wro
