Passing on Fates [was: Re: Teaching Rakudo the tricks of Perl 5's regex optimiser]

On 13/08/2019 16:32, Brad Gilbert wrote: > Perhaps the biggest one may be the one about passing around “fates”. > (I barely understand the basics of this.) The optimization opportunity Brad is refering to here is relevant mostly to grammars with deeply nested multi-tokens:

Re: Teaching Rakudo the tricks of Perl 5's regex optimiser

Here's some stuff that anybody who wants to work on regex optimization in perl6 will want to know: You can get a print-out of rakudo's internal AST that is generated for the regex by passing --target=ast or --target=optimize to the perl6 commandline. I recommend grep -C5 Regex to skip some of the

Re: Teaching Rakudo the tricks of Perl 5's regex optimiser

>     use v6; >     'abcd' ~~ / . <.before( /c/ )> .  / # "bc" >     'abcd' ~~ / . <.before   c   > .  / # "bc" # (exactly identical) > > A person could change the code in the `before` method to have it do > something different At least at the moment, that's not 100% accurate (only by virtue

Re: [perl #133791] perl 6 parser bugging out on a comment thinking it is a real var

I believe the problem comes from `"{"` which actually starts an interpolated code block containing a string immediately. That's also why it doesn't complain about the "else" being in an odd place; it's also inside the string! So here's an equivalent piece of code that shows what's wrong: if

Re: [perl #133791] perl 6 parser bugging out on a comment thinking it is a real var

I believe the problem comes from `"{"` which actually starts an interpolated code block containing a string immediately. That's also why it doesn't complain about the "else" being in an odd place; it's also inside the string! So here's an equivalent piece of code that shows what's wrong: if

Re: [perl #127682] [OSX] writing more than 8192 bytes to IO::Handle causes it to hang forever

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,

Re: [perl #127682] [OSX] writing more than 8192 bytes to IO::Handle causes it to hang forever

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,

Re: [perl #132511] Binary assignment Z+= fails if it's the last thing in for loop

Curious sidenote: when you use [Z+]= it will complain about "useless use of [Z+]= in sink context" and the modifications actually go through. With Z[+=] - which is probably the default parsing of this - it will not complain about useless use, but it also won't Do The Thing.

Re: [perl #132511] Binary assignment Z+= fails if it's the last thing in for loop

Curious sidenote: when you use [Z+]= it will complain about "useless use of [Z+]= in sink context" and the modifications actually go through. With Z[+=] - which is probably the default parsing of this - it will not complain about useless use, but it also won't Do The Thing.

[perl #127020] [PERF] pod parsing memory is never freed

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

[perl #130982] [PERF] "for $a..$b -> $i { ... }" loops are sometimes much slower than c-style loops

On Mon, 20 Nov 2017 12:13:47 -0800, ronaldxs wrote: > What about a native perl6 range loop? Couldn't there be some way for > Perl 6 / Rakudo to generate code competitive on a small range with the > "native-loop" example? > > perl6 -e ' > { > my int ($a, $one, $three) = (42, 1, 3); >

Re: [perl #132225] AutoReply: segmentation fault while concurrently updating SetHash

I already figured out that it's about sinking the result of assigning to the SetHash. When you access it you get a proxy, that is the return value of the lock-protected block, and the proxy gets sunk outside of it, thus causing concurrent access to the SetHash. On 14/11/17 16:03, Elizabeth

Re: [perl #132225] AutoReply: segmentation fault while concurrently updating SetHash

I already figured out that it's about sinking the result of assigning to the SetHash. When you access it you get a proxy, that is the return value of the lock-protected block, and the proxy gets sunk outside of it, thus causing concurrent access to the SetHash. On 14/11/17 16:03, Elizabeth

Re: [perl #132349] $*IN.getc not blocking on macOS

can you get us strace output for this?

Re: [perl #132349] $*IN.getc not blocking on macOS

can you get us strace output for this?

Re: [perl #132316] [Double Free] Crash while running program

if you can, please re-compile MoarVM passing the same options that were used before (you can find them on the first screenfuls of the Makefile inside moarvm's source folder) to Configure.pl but also include --debug=3 and --optimize=0. This is an optional step. After that, please run

Re: [perl #132316] [Double Free] Crash while running program

if you can, please re-compile MoarVM passing the same options that were used before (you can find them on the first screenfuls of the Makefile inside moarvm's source folder) to Configure.pl but also include --debug=3 and --optimize=0. This is an optional step. After that, please run

Re: [perl #132300] [SEGV] say nqp::getlexdyn('')

fixed in moarvm commits a9267cb, 650e797, and 676723d. Needs a bump, as well as tests. On 17/10/17 19:22, Aleks-Daniel Jakimenko-Aleksejev via RT wrote: > Bisected: (2016-06-29) > https://github.com/rakudo/rakudo/commit/d5c750f74cd4cdbc4746da8bf32d42fc37032b78 > > On 2017-10-14 06:33:04,

Re: [perl #132300] [SEGV] say nqp::getlexdyn('')

fixed in moarvm commits a9267cb, 650e797, and 676723d. Needs a bump, as well as tests. On 17/10/17 19:22, Aleks-Daniel Jakimenko-Aleksejev via RT wrote: > Bisected: (2016-06-29) > https://github.com/rakudo/rakudo/commit/d5c750f74cd4cdbc4746da8bf32d42fc37032b78 > > On 2017-10-14 06:33:04,

Re: [perl #132284] [REGRESSION] .gist of a Map was arguably better in the past (say Map.new(‘a’ => ‘b’))

fixed in moarvm commits a9267cb, 650e797, and 676723d. Needs a bump, as well as tests. On 17/10/17 19:28, Zoffix Znet via RT wrote: > On Thu, 12 Oct 2017 22:59:36 -0700, alex.jakime...@gmail.com wrote: >> Code: >> my @a = [1,2,3,4]; my %h = 'a'=>'b','c'=>'d','101'=>'102'; my $c = >> \(|@a,

Re: [perl #132225] segmentation fault while concurrently updating SetHash

n the hash is resized) this will probably just get inconsistent results in whether it'll sink a true or a false. On 11/10/17 08:06, Timo Paulssen via RT wrote: > This runs reliably when you let the lock-protected block return > something unrelated to the hash: > >     #!/usr/bin/env perl6 > &

Re: [perl #132225] segmentation fault while concurrently updating SetHash

n the hash is resized) this will probably just get inconsistent results in whether it'll sink a true or a false. On 11/10/17 08:06, Timo Paulssen via RT wrote: > This runs reliably when you let the lock-protected block return > something unrelated to the hash: > >     #!/usr/bin/env perl6 > &

Re: [perl #132225] segmentation fault while concurrently updating SetHash

This runs reliably when you let the lock-protected block return something unrelated to the hash:     #!/usr/bin/env perl6     use v6.c;     my $lock = Lock.new;     my $set = SetHash.new;     await (^12).map: {     start {     for (^1000) {     $lock.protect: { $set<1> = True }    

Re: [perl #132225] segmentation fault while concurrently updating SetHash

This runs reliably when you let the lock-protected block return something unrelated to the hash:     #!/usr/bin/env perl6     use v6.c;     my $lock = Lock.new;     my $set = SetHash.new;     await (^12).map: {     start {     for (^1000) {     $lock.protect: { $set<1> = True }    

[perl #124455] substr on compact array

Also, the design docs say you get the same kind of buffer back from substr on a buf, but we have subbuf for that now.

[perl #124455] substr on compact array

The tests are bogus just the assumption that a substr of length 8 will give you 8 bits rather than 8 bytes, that's already wildly inconsistent with what substr does otherwise. really this code looks like the desire to have `vec` from perl5 implemented in perl6 by re-using the substr name. I

[perl #131251] Useless use warning triggered on assignment forms of reverse metaops

This also happens with other metaops than R, like [Z+]=, [X+]=, and also [S+]= (which admittedly doesn't do sensible things)

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

I just committed a hotfix so the upcoming release can go through. Hopefully it can be replaced with a proper implementation of optional parameters for the nativecall compiler soon. https://github.com/rakudo/rakudo/commit/1818de980fe39a37b405c0353d088932bd4d034a

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

I just committed a hotfix so the upcoming release can go through. Hopefully it can be replaced with a proper implementation of optional parameters for the nativecall compiler soon. https://github.com/rakudo/rakudo/commit/1818de980fe39a37b405c0353d088932bd4d034a

Re: [perl #131841] AutoReply: [BUG] In a 'unit module', a 'die' along any CATCH block causes a compiler error

Annoyingly, 2017.07 has a bug that makes every --ll-exception print that exact error. Here's what a newer version of rakudo gives you: > Cannot invoke this object (REPR: Null; VMNull) >at SETTING::src/core/Exception.pm:57 >

MoarVM and deny_execmem (was: Verifiable Releases/The Build System is Ridiculous)

I just committed a little change to MoarVM that'll turn off the jit if we notice we're not allowed to turn a page executable. https://github.com/MoarVM/MoarVM/commit/b07acdfd92a88d1e40ad42c1c853922b20f1a056 now it won't crash if deny_execmem is turned on. it'll just be slower. There's

Re: Verifiable Releases/The Build System is Ridiculous

>> The reliance on W^X violating behavior is something I would like >> to see >> removed, > > That behaviour does not exist. The binary blobs aren't created as > part of the normal build process, and even if they were, the code > writes the bytecodes to disk, it does not directly execute them.

Re: [perl #131813] Segfault with --profile

It could be that the commit i just pushed to moarvm fixes this, please verify (the code doesn't crash with the patch)

Re: [perl #131776] perl6-debug-m can't setlang on object of type Perl6::HookGrammar

Already fixed in newer versions

Re: [perl #131776] perl6-debug-m can't setlang on object of type Perl6::HookGrammar

Already fixed in newer versions

Re: [perl #131758] [BUG] running script exit crash after update rakudo

I wrote a fix, could you try downgrading to 2017.06, running the script, applying the patch to your 2017.07, making sure the Makefile itself gets regenerated via Configure.pl, and install, then see if the program still crashes? https://github.com/rakudo/rakudo/commit/02667bd890 the commit

Re: [perl #131758] [BUG] running script exit crash after update rakudo

I wrote a fix, could you try downgrading to 2017.06, running the script, applying the patch to your 2017.07, making sure the Makefile itself gets regenerated via Configure.pl, and install, then see if the program still crashes? https://github.com/rakudo/rakudo/commit/02667bd890 the commit

[perl #131653] [SEGV] segfault when attempting to profile the Rakudo compile

this was caused by instructions coming back from the dead, haunting usage counts by mysteriously dropping them by 1 or more, and then both the dead instruction and the lawful citizens of other blocks of code being executed by the local authorities. fixed with

[perl #131653] [SEGV] segfault when attempting to profile the Rakudo compile

this was caused by instructions coming back from the dead, haunting usage counts by mysteriously dropping them by 1 or more, and then both the dead instruction and the lawful citizens of other blocks of code being executed by the local authorities. fixed with

Re: [perl #131657] rakudobrew build moar fail

the problem here is that we have a flag to ensure gcc explodes at us when we write code on linux that'd immediately explode on windows due to MSVC being somewhat archaic, but that flag is also set for third-party code, and since the arm dyncall stuff only gets tested once every few months at best,

Re: [perl #131657] rakudobrew build moar fail

the problem here is that we have a flag to ensure gcc explodes at us when we write code on linux that'd immediately explode on windows due to MSVC being somewhat archaic, but that flag is also set for third-party code, and since the arm dyncall stuff only gets tested once every few months at best,

[perl #131330] [PERF] for ^N { } got about 2.5x slower in 5401a1a

Fixed it with rakudo commit 46b11f54c0 timotimo │ bench: 46b11f54c0,abfb52be1d for ^10_000_000 { } +benchabl+│ timotimo, starting to benchmark the 2 given commits +benchabl+│ timotimo, ¦46b11f5: «1.6712» ¦abfb52b: «4.4582» timotimo │ m: say 4.4582 / 1.6712 +camelia │

[perl #129779] [CONC] [SPESH] [PERF] Parallelizing code unexpectedly makes it slower

with jnthn's recent patch to give every thread its own free-list for the FSA, the behavior is now much nicer. Here's a paste of a 40-core machine: https://gist.github.com/anonymous/650ff6b00a0f8dc34b9e358992e572b4 here's a 24-core box (some google compute cloud machine zoffix rents) before

Re: [perl #131076] [LTA] Rakudo sees Perl 5 code even if there is none (for $x(42), $x(50) {…})

Of course there should have been a "," between (list) and $othervar.

Re: [perl #131076] [LTA] Rakudo sees Perl 5 code even if there is none (for $x(42), $x(50) {…})

But perl5 won't accept for $var (list) $othervar (anotherlist) { ... } right? So we definitely shouldn't complain, or at least we should point out the workaround of putting a dot between $var and (list) On 30/03/17 03:51, Brandon Allbery wrote: > That *is* Perl 5 syntax, though; it looks

Re: [perl #130965] [LTA] `but role { ... }` interacts strangely with outer lexicals, and doesn't warn about it

On 09/03/17 20:38, jn...@jnthn.net via RT wrote: > On Thu, 09 Mar 2017 07:39:39 -0800, elizabeth wrote: >> But I’ll settle for a warning / exceptione :-) > I think these options are worth consideration. I can't think of a false > positive off hand. class Test { method tester { say "testest" } }

Re: [perl #130886] multi subs with inconsistent where clauses don't work correctly

I'd say this is NOTABUG via the DIHWIDT category. If your where clause has side-effects, you're bound to get in trouble. If you're fine with relying on internals, you can just put True into the one-out-of-ten three times at the end and the program will run through to 100. test 90 90

Re: [perl #130845] Some things that are less than 5 aren't

Actually, I was mistaken. The code i pointed at there already works for this very case. observe: 131338 timotimo │ m: say 4.999 cmp 5.0 131338 +camelia │ rakudo-moar 1811b8: OUTPUT: «Less␤» The real problem is this implementation of :: multi sub infix:(Real:D \a,

Re: [perl #130845] Some things that are less than 5 aren't

This is because the implementation of infix:(Rat:D, Rat:D) is kind of bad: multi sub infix:(Rational:D \a, Rational:D \b) is default { a.Num cmp b.Num } We'll have to do a proper comparison of rats, rather than convert to Num which can give wrong results like this. On 23/02/17

Re: [perl #130793] explicit .resume on Broken promise exception "not resumable", implicit fine

You might be confusing resuming an exception with leaving the CATCH block with the exception marked as "handled". When you leave the block after having matched the exception successfully with a default or when block (or whatever else), the exception is marked as handled, which means it won't get

Re: [perl #130763] [BUG][LTA] Weird error in anonymous class value in Hash

This is caused by the way we differentiate between anonymous blocks and hashes; we just parse it as a block first, and if at the end it turns out it should be a hash instead, we change it around. I suppose at that point the class will already have been defined and its stuff will point at the "not

Re: [perl #130248] [BUG] When do-for idiom called on a lazy-infinite list to do pull-one, it exhausts the given list

I don't think that's what's happening. It looks like you're creating an iterator three times and are trying to get the first element through each iterator. Check out what happens when you call .iterator only once: perl6 -e 'my \a = (gather for ^Inf { take $_ }).iterator; say do for ^3 {

Re: [perl #130248] [BUG] When do-for idiom called on a lazy-infinite list to do pull-one, it exhausts the given list

I don't think that's what's happening. It looks like you're creating an iterator three times and are trying to get the first element through each iterator. Check out what happens when you call .iterator only once: perl6 -e 'my \a = (gather for ^Inf { take $_ }).iterator; say do for ^3 {

Re: [perl #130107] [CONC] unkown system error 0 via Proc::Async

The issue is that libuv will under some circumstances call the read callback with an nread of 0 (deliberately the number 0), which we interpret as an error. The Solution™ is either to not call async_read at all when nread is 0, or to just return early from async_read when nread is 0.

Re: [perl #129884] Strange behaviour on "say".

Actually, I just tested the code and on my machine it always outputs "test". The only difference between uncommenting "say 'run'" is that it'll output "run" once at the end - or not. So now I'm wondering what i did differently from you?!

Re: [perl #129829] .pick on large ranges returns binary-sparse result

Apparently libtommath is known to leave some bits 0 when specific conditions for the defines are met; i haven't looked but i suspect we are hitting exactly this problem: https://github.com/libtom/libtommath/pull/56 not sure why it's been quiet since april.

Re: [perl #129776] [CUR][PERF] Extremely slow performance when running in directory with lots of modules

Sorry, I was running the profile on a 4-weeks-old rakudo. After the optimizations i did to canonpath ~22 days ago the canonpath inclusive time went down to about 18% ... FILETEST-D and FILETEST-F are in spots 3 and 4, but they only take 3594 / 26881 msec and 2749 / 216298 msec per invocation, so

Re: [perl #129776] [CUR][PERF] Extremely slow performance when running in directory with lots of modules

Here's the results from a --profile-compile: 1. match (gen/moar/m-CORE.setting:12064), 12750 entries, 25.66% inclusive time, 8.15% exclusive time 2. (gen/moar/m-BOOTSTRAP.nqp:2081), 111530 entries, 4.59% inclusive time, 4.36% exclusive time 3. (gen/moar/m-CORE.setting:40776), 13148 entries,

Re: [perl #129776] [CUR][PERF] Extremely slow performance when running in directory with lots of modules

On 02/10/16 04:41, Lloyd Fournier wrote: > String concat takes On2 in rakudo I think. Using join in this kind of > situation should be an improvement. (I'm commuting so can't test). MoarVM implements "ropes" which make the performance a whole lot better. join can still be a small improvement, but

Re: unicode

On 17/09/16 13:34, Moritz Lenz wrote:>> Searching further I found the ucd2c.pl program in the Moarvm tools >> directory. This generates the unicode_db.c somewhere else in the >> rakudo tree. I run this program myself on the Unicode 9.0.0 >> database and comparing the generated files shows many

Re: [perl #129088] [BUG] Error message provokes panic

are you aware that that's just the filename? and the whole thing is just the backtrace that shows where things are going wrong? not necessarily a very useful stacktrace; usually we'd want to have the source file name rather than the effective filename of the bytecode loaded. also, no useful line

Re: [perl #129088] [BUG] Error message provokes panic

On 27/08/16 17:45, Parrot Raiser wrote: > Even the reference to the VM seems more confusing than useful to the > > average user. All the message really needs to say is that the printf > mask is wrong, with optional extra awesomeness points if it can > identify where and why. Huh? What do you

Re: [perl #129088] [BUG] Error message provokes panic

we could call the method "parsefail", or maybe just "fail", or "abort". how does that sound?

Re: [perl #129088] [BUG] Error message provokes panic

This sound much more severe than it is. panic is just a convenience method that throws an exception that contains the cursor's location during parsing. it then just uses nqp::die to throw that message, which is as harmless as any other "die".

Re: [perl #128875] [BUG] Ignore mark + Ignore case = Ignores everything but first letter

to be more precise, the way we code-gen "literal" qregex nodes with subtype "ignoremark+ignorecase" will only ever check the ordbaseat of the first character in the literal against the haystack.

Re: [perl #128842] [BUG] := inconsistent semantics

On 08/04/2016 08:47 PM, Zefram wrote: > Timo Paulssen via RT wrote: >> You can only assign to a Scalar. > How? Specifically, in the situation where I have a Scalar as a value, > stored in a variable or as a sub parameter. How do I assign into it? > The usual assignment op

Re: [perl #128842] [BUG] := inconsistent semantics

On 08/04/2016 08:31 PM, Zefram wrote: > Timo Paulssen via RT wrote: >> Aye, you can .<> the value to "decont" it, > Doesn't work as an lvalue: That should be very obvious; I may have communicated less-than-effectively. You can only assign to a Scalar. You just used

Re: [perl #128842] [BUG] := inconsistent semantics

On 04/08/16 20:09, Zefram wrote:> Is there some way I missed to get access to the content of a Scalar? > Something other than exploiting this bug? That's what I was > originally after when I ran into this. > > -zefram Aye, you can .<> the value to "decont" it, which will give you the

Re: [perl #128842] [BUG] := inconsistent semantics

The := operator only has one behaviour/semantics in this example. However, in one of your examples you're actually getting a Scalar inside a Scalar. Check this out: timo@schmand ~> perl6 -e 'my $a = 3; sub ss1(Scalar $s, $nv) { say $s.VAR.DUMP }; ss1($a.VAR, 7)' ▶3 timo@schmand ~> perl6 -e

[perl #128594] [SEGV] attempting to use :merge when run()ning an external command causes a core dump

I've unsuccessfully tried to fix this, but I've come up with an idea how an actual fix might go. When the merge flag (which I added in recent commits) gets passed to MVM_proc_spawn or MVM_proc_shell, we have to first create a new pipe on our own, then set up both stdio 1 and 2 to

Re: [perl #128481] [BUG] *.split returns a BOOTArray

On 25/06/16 12:28, Lloyd Fournier (via RT) wrote: # New Ticket Created by Lloyd Fournier # Please include the string: [perl #128481] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=128481 > 20:26 < llfourn> m: my =

Re: [perl #127908] [NativeCall] spurious warnings for type 'int'

On 04/16/2016 10:08 PM, David Warring (via RT) wrote: > # New Ticket Created by David Warring > # Please include the string: [perl #127908] > # in the subject line of all future correspondence about this issue. > # https://rt.perl.org/Ticket/Display.html?id=127908 > > > > Consider: > > $

Re: [perl #127902] [BUG] segmentation fault when defining multi sub cross

On 04/15/2016 09:36 PM, Nicholas Clark wrote: > multi sub cross() { } Here's a gdb backtrace and a moarvm-level backtrace. Value looks a tiny bit suspicious, though i don't know if there's actually anything wrong with it. Program received signal SIGSEGV, Segmentation fault. 0x778ef0d3 in

Re: [perl #127801] LTA Error when forgetting {} to interpolate range in regex

If you want to use interpolated ranges, you'll have to use {1..$width}. However, the error message is clearly wrong and could definitely be changed to suggest that change. That's why I changed the title of the bug (or at least tried to)

Re: [perl #127707] [BUG] .map() inside a .map()

My expectation is that the map just creates a lazy list that doesn't get evaluated early enough. You can try to use a for loop for the inner (or actually both) map calls, or you could put .eager or .sink at the end of the map calls. Does that help?

Re: [perl #127701] Parsing bug in Rakudo when the match variable and a postfix is followed by a double minus

Defining new postfix: will make "foo" after [0] cause the [0] to be output verbatim rather than having [0] be interpreted as the postcircumfix on $/.

Re: [perl #127342] LTA error message talks about BOOTSTRAPATTR (say Int.^attributes)

Right. You're touching a place where we've had to make things a bit less friendly because rakudo is a bootstrapped compiler. You can work around this problem with code like: say Int.^attributes>>.name

Re: [perl #127190] Perl 6 has 0 elements ( .hyper.grep )

I just kicked out the debug output, but sadly hyper + grep remains broken. sadly, hyper + grep has been broken for a longer time :(

Re: [perl #127099] hyper messes up order of the results (i.e. @result !~~ @result.sort)

I've got a fix in the hyper_tracks_sequence_numbers branch on github, but as the commit message of the first commit on that branch says, the codes wants to be rewritten or at least cleaned up a good bit.

Re: [perl #127091] Newline Before Commas Results in 'Bogus Statement' Error

Isn't this just about "a line ending in } gets a ; for free"?

Re: [perl #127064] Variable interpolation in regex very slow

On 12/29/2015 12:46 AM, Jules Field (via RT) wrote: > # New Ticket Created by Jules Field > # Please include the string: [perl #127064] > # in the subject line of all future correspondence about this issue. > # https://rt.perl.org/Ticket/Display.html?id=127064 > > > > Given >my @lines =

Re: [perl #127030] [BUG] await start { qx/../ } doesn't wait

On 12/26/2015 06:08 AM, Lloyd Fournier (via RT) wrote: > perl6 -e 'say await start { qx/echo foo/ }' > > outputs an empty list. Pretty sure that's a bug. I can't reproduce this. Does this code give the same result on your machine as on mine? timo@schmetterling ~> perl6 -e 'say (await start

Re: [perl #126890] [BUG] pair with Nil key deparses incorrectly

I think you might have misread the bug report. This bug is about the .perl method on Pair not being careful enough if the .perl of its .key looks like //. I am reluctant to add a full ~~ // to the .perl, as matching carries quite a big overhead at the moment and that'd make printing a list of

Re: [perl #126757] LTA error message talks about ~ but there is no ~ in my code (33..126 .pick.chr)

This error occurs because 126.pick gives 126, 126.chr is "~". Then the .. operator tries to numify its RHS, which is "~". That goes wrong, of course. So this is just a precedence problem with ranges. Do you have a better suggestion for the error message here? Otherwise i'd close this as

Re: [perl #126263] Problem when reentering the grammar engine from an action

The thing is that G.parse('a') puts (well, tries to put) the parse result into $/. $/ is a part of your method's signature and by default those are read-only. That's why you're being accused of assigning to a readonly variable. what you'll need to do is either call the parameter something

Re: [perl #125271] surprised by {,} in the same list

On 05/29/2015 12:08 AM, Kang-min Liu (via RT) wrote: # New Ticket Created by Kang-min Liu # Please include the string: [perl #125271] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/Ticket/Display.html?id=125271 When there are a pair of

Re: bug in object.^attributes; on the git

On 08/10/14 15:05, Francis (Grizzly) Smit wrote: I have found this bug in the current git version of rakudo: 23:16:34 grizzlysmit@rakbat:~/Projects/perl/perl6/testing0$ perl6 --version This is perl6 version 2014.09-165-g19d2de5 built on MoarVM version 2014.09-14-g0df2d6f 00:01:10

Re: active rakudo ports

Hi Gerd, On 16/09/14 11:10, Gerd Pokorra wrote: the Fedora package is not dead. Only the Feature webpage will not be updated. The moarvm request passed the review: https://bugzilla.redhat.com/show_bug.cgi?id=1071163 Cool! I'm sorry we caused you so much grief and work due to the bundled

Re: [perl #122741] Dead link

Hello Alex, I gave the page an almost complete overhaul to make it more newbie-friendly (because we do want to cater to newcomers, it's just that sometimes we fail to.) Please tell me if there's more I can do to improve it!

Re: [perl #122600] [BUG] Concatenating string and buf8 infiniloops

On 23/08/14 13:44, Tadeusz Sośnierz (via RT) wrote: # New Ticket Created by Tadeusz Sośnierz # Please include the string: [perl #122600] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/Ticket/Display.html?id=122600 Tested on Rakudo 2014.08.

Re: [perl #120993] Strange behavior matching junctions with Number strings

Actually, using ~~ here transforms the junction into a string before attempting to match. Thus, no auto threading is taking place at all. I can't test it right now, but with .match it should work better. Or at least different. -- Sent from my Android phone with K-9 Mail. Please excuse my