[Tux] This is Rakudo version 2016.12-248-gf6303d7be built on MoarVM version 2016.12-71-g331a6b43 10:17
csv-ip5xs 3.138
test 12.974
test-t 5.327
csv-parser 13.893
bartolin bisectable6: my $attempts = 0; say (1..5).grep({if $_ == 3 {$attempts++; redo unless $attempts == 10}; $_}).join("|"); say "looked $attempts times for element 3" 11:19
bisectable6 bartolin, Bisecting by output (old=2015.12 new=f6303d7) because on both starting points the exit code is 0
bartolin, bisect log: gist.github.com/2b11fafe62e22fa422...803fba4be2
bartolin, (2017-01-06) github.com/rakudo/rakudo/commit/3c...320fa7bc61
bartolin m: my $attempts = 0; say (1..5).grep({if $_ == 3 {$attempts++; redo unless $attempts == 10}; $_}).join("|"); say "looked $attempts times for element 3" 11:21
camelia rakudo-moar f6303d: OUTPUT«1|2|4|5␤looked 1 times for element 3␤»
bartolin star-m: my $attempts = 0; say (1..5).grep({if $_ == 3 {$attempts++; redo unless $attempts == 10}; $_}).join("|"); say "looked $attempts times for element 3"
camelia star-m 2016.10: OUTPUT«1|2|3|4|5␤looked 10 times for element 3␤»
bartolin looks like a regression, doesn't it? I'll rakudobug it 11:22
j: 'my $attempts = 0; say (1..5).grep({if $_ == 3 {$attempts++; redo unless $attempts == 10}; $_}).join("|"); say "looked $attempts times for element 3"' 11:24
camelia rakudo-jvm fb4f16: OUTPUT«WARNINGS for <tmp>:␤Useless use of constant string "my $attempts = 0; say (1..5).grep({if $_ == 3 {$attempts++; redo unless $attempts == 10}; $_}).join(\"|\"); say \"looked $attempts times for element 3\"" in sink context (line 1)␤»
bartolin j: my $attempts = 0; say (1..5).grep({if $_ == 3 {$attempts++; redo unless $attempts == 10}; $_}).join("|"); say "looked $attempts times for element 3"
camelia rakudo-jvm fb4f16: OUTPUT«1|2|3|4|5␤looked 10 times for element 3␤»
bartolin on latest r-j this dies with 'redo without loop construct'
lizmat bartolin: please rakudobug it, and add tests for it and then we revert the patch if we can't find out why 12:02
on first sight, I have no idea why this fails: it's just getting the iterator and working off off that
there shouldn't be anything else important code using an iterator should know about, right ? 12:03
bartolin lizmat: I think it happens, because NEXT and REDO are not handled in grep-callable: github.com/rakudo/rakudo/blob/f630...ds.pm#L930 12:18
lizmat but, but, why didn't we see this before then ?
bartolin lizmat: .. and this surfaces only now
bartolin didn't fully understand, yet 12:19
in IterateOneWithPhasers we do more work with regard to LAST, NEXT and REDO: github.com/rakudo/rakudo/blob/f630...ds.pm#L104 12:22
anyway, I'm writing a bug report now 12:23
lizmat star-m: my $attempts = 0; say (1..5).grep({if $_ == 3 {$attempts++; redo unless $attempts == 10}; $_}) # broken longer ago
camelia star-m 2016.10: OUTPUT«(1 2 4 5)␤»
lizmat BTW: what does "redo" in a grep mean anyway ?
bartolin yeah, I wondered about that, too 12:25
in S32-list/grep.t we have tests for 'last' and 'next' in grep -- with a comment "grep with last, next etc."
also, 7021861705 might be related to this. do you remember which hyper/race tests passed back then, perhaps? 12:28
lizmat no
AlexDaniel well, try the same element again? 12:31
I wonder why would anybody need this ever…
even ｢last｣ in grep is not that common given that it was broken for almost a year and nobody noticed 12:32
bartolin I don't see a use case for 'redo'. Actually I stumbled about this, because a test for 'next' in grep from S32-list/grep.t dies on rakudo-j -- and it seems to happen for the same reason, that 'redo' is failing on MoarVM 12:35
r: say (1..12).grep({next if $_ % 5 == 0; $_ % 2 == 0}).join('|')
camelia rakudo-moar f6303d, rakudo-jvm fb4f16: OUTPUT«2|4|6|8|12␤»
bartolin ^^ that one dies now with 'next without loop construct' on rakudo-j 12:36
AlexDaniel by the way… 12:37
j: say (1..12).grep({next if $_ % 5 == 0; $_ % 2 == 0}).join('|')
camelia rakudo-jvm fb4f16: OUTPUT«2|4|6|8|12␤»
AlexDaniel oh, that's not very old!
bartolin no, but it is before 3c52aa096c 12:38
AlexDaniel how much space does r-j take when installed, by the way?
and how long does it take to build it?
bartolin hmm, I have no numbers, but can take a look 12:41
AlexDaniel well, would be nice to know before I jump into it head first :) 12:42
bartolin my install dir has a size of 11 M
lizmat well, the simple thing could be to just die on a redo in a grep
AlexDaniel wow, 11 12:43
bartolin and it's definitely not fast. stage parse takes about 140 s on my server
AlexDaniel but generally under 10 minutes I guess?
bartolin yes, I'd say less than 10 min, but not much less 12:44
lizmat otoh, if the code block has a phaser, it goes through the slow .map path, and then redo *is* supported
so I guess we have no choice :-(
bartolin builds r-j 12:47
AlexDaniel so if I am going to do the same thing bisectable does now for r-moar but for r-j, do I need to know anything? In terms of building it? Running it is a bit different story…
moritz you need to know that you'll need patience 12:48
bartolin AlexDaniel: Hmm, there where a lot of commits where r-j did not build at all
AlexDaniel that is, ≈5500 builds or something. I guess most of them will fail, yea
moritz: you overestimate the amount of patience required 12:49
moritz AlexDaniel: tell me after you've done it :-)
AlexDaniel I've already done it for moar
it was like 3 or 4 days to do it from scratch
a good estimate for moar was 1 minute per build (it takes about 7, but there are 7 in parallel) 12:52
soo
m: say 5500 ÷ 60 ÷ 24
camelia rakudo-moar f6303d: OUTPUT«3.819444␤»
AlexDaniel yea
.oO( it takes more procrastination than patience )
 12:53
moritz the JVM needs more memory, so fewer builds in parallel 12:54
and it's slower
OTOH, more builds will abort early
AlexDaniel memory! Good point. I won't be surprised if it goes over 16 GB 12:55
bartolin I'm running my daily builds on a virtual machine with 8 GB and 2 cores 12:56
and I think 6 GB would be enough 12:57
moritz maybe 4
lizmat ok, so I have a fix for redo in grep, but it makes it 1.7x slower :-(
bartolin: ^^ 12:58
bartolin on that machine a complete build (with nqp-j) just tooka bit about 12 min :-/
lizmat: :-( that's a lot, esp. since noone needs 'redo' in grep 13:00
lizmat yeah... :(
in fact, just using map would only make it 1.5x slower, because we then don't need to check for phasers 13:01
bartolin lizmat: how does your fix look like? (could you gist it?) 13:04
lizmat basically add the redo support from sequential-map
bartolin I see 13:05
lizmat gist.github.com/lizmat/819e753b785...4beac36f89
bartolin bug report (without this discussion, yet): RT #130529 13:12
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=130529
lizmat hmmm... it just occurred to me that returning an empty Slip from a map, starts up a SlippyIterator and then doesn't find anything in it 13:17
perhaps we need an EmptySlip sentinel just like IterationEnd to indicate nothing got returned 13:18
an eqaddr for that should be really fast
jnthn moritz notviki opinions ? ^^ 13:19
moritz can't really comment
jnthn m: say Empty.^name 13:21
camelia rakudo-moar f6303d: OUTPUT«Slip␤»
jnthn Already exists, no? :)
And yes, we can past-path Empty
*fast-path 13:22
lizmat hmmm... 13:25
ok, will do 13:26
bartolin lizmat: there is anothere inconsistency with the command above: it works as expected when I use .perl instead of .join 13:30
m: my $attempts = 0; say (1..5).grep({if $_ == 3 {$attempts++; redo unless $attempts == 10}; $_}).perl; say "looked $attempts times for element 3" 13:31
camelia rakudo-moar f6303d: OUTPUT«(1, 2, 3, 4, 5).Seq␤looked 10 times for element 3␤»
lizmat yeah, that inconsistency will go after I push my fix
will make grep about 1.4x slower
I guess you can't have your cake and eat it as well
bartolin so, you think the problem really is in grep-callable and only surfaces with the new join for Seq? 13:32
lizmat yeah, pretty sure of that
it will also fix the problem on the JVM 13:33
I guess we were cutting corners a bit too much there -(
bartolin ok. what do you think about adding: 'NEXT', $_,
lizmat: to the nqp::handle part
lizmat the expensive part is the REDO part 13:34
bartolin (I think only that will make r-j happy there=
lizmat you need to build an entire loop construct for that
bartolin *nod*
lizmat and since redo is dynamic (afaik), we can't determine at compile time whether a block will execute a redo or not 13:35
dalek kudo/nom: 362f674 | lizmat++ | src/core/Any-iterable-methods.pm:
Fix for RT #130529

  - remove the special case "fast" grep loop because it didn't support redo
  - make general case a bit faster by rewriting as nqp ops
  - also directly go to sequential-map, instead of calling self.map
  - this makes the slow path about 10% faster
  - this makes the fast path about 1.4x slower :-(		 13:38
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=130529
bartolin feels a bit sorry for bringing this up ... 13:40
but lizmat++ 13:41
lizmat yeah, sometimes you have a kobayashi maru situation
jnthn I suspect the redo handling will get cheaper once we have a goto 13:57
dalek kudo/nom: 9052427 | lizmat++ | src/core/Str.pm:
Use Empty for an empty Slip

So we can test for it better later.		 14:09
b2gills I wonder if ｢|()｣ could return ｢Empty｣ rather than a new Slip every time. 16:21
notviki 0.o it returns a slip? 16:22
Ah ok
b2gills m: say Empty.perl; say (|()).perl
camelia rakudo-moar 905242: OUTPUT«slip()␤slip()␤»
notviki s: &prefix:<|> 16:23
SourceBaby notviki, Sauce is at github.com/rakudo/rakudo/blob/9052...t.pm#L1464
b2gills m: my \a = |(); my \b = |(); say Empty =:= a; say a =:= b # currently |() returns a new Slip every time 16:25
camelia rakudo-moar 905242: OUTPUT«False␤False␤»
notviki m: say Empty =:= Empty 16:27
camelia rakudo-moar 905242: OUTPUT«True␤»
notviki Prolly just need a new candidate that doesn't take args?
m: my \a = ().Slip; my \b = ().Slip; say Empty =:= a; say a =:= b 16:28
camelia rakudo-moar 905242: OUTPUT«False␤False␤»
RabidGravy for discussion github.com/perl6/DBIish/issues/84 16:49
lizmat m: dd { 42 if 0 }() # how about that would actually spell Empty ? 20:22
camelia rakudo-moar 905242: OUTPUT«slip()␤»
notviki m: dd Empty 20:23
camelia rakudo-moar 905242: OUTPUT«slip()␤»
moritz doesn't care much either way
lizmat m: dd { 42 if 0 }().perl.EVAL # and this would also say Empty
camelia rakudo-moar 905242: OUTPUT«slip()␤»
lizmat it would make debugging a bit easier for me :-) 20:24
but it breaks 2 spectests that specifically test for "slip()"
as the output of .perl
FWIW, it would also be faster :-) for the Empty case, at the expense of one more nqp::eqaddr when it isn't 20:25
masak I feel these types for listish and other emptiness keep floating around over the years, slowly, like oil on water
I'm sorry, that came out very grumpy :)
lizmat well, Empty is post-GLR 20:26
so it's only been around for 1.5 year at the most
masak but if the above proposal is a simplification in that it makes things more consistent without any obvious drawback, I'm all for it, I guess
moritz I don't really understand what Nil is used for these days
except for resetting something to its default value
geekosaur emptiness is surprisingly hard to pin down :) 20:27
lizmat Nil signifies the absence of a value where there should be one
moritz but that could be a function too; doesn't need to be a separate type
lizmat: but don't we have type objects already to do that?
masak moritz: the magic behavior of assigning to Nil is such an obvious antipattern anyway -- let's get rid of it
lizmat m: dd (Nil,)
camelia rakudo-moar 905242: OUTPUT«(Nil,)␤»
lizmat m: dd (Empty,)
camelia rakudo-moar 905242: OUTPUT«()␤»
moritz like, use Str when no instance of Str can be found?
lizmat masak: assigning to Nil ?? 20:28
masak moritz: it's non-obvious *and* it slows down assignment in general
moritz masak: +1
masak m: my Int $x = 42; $x = Nil; say $x
camelia rakudo-moar 905242: OUTPUT«(Int)␤»
masak lizmat: that.
lizmat masak: how does it slow down assignment in general ??
masak lizmat: because you need to check, is it Nil, and then run special code 20:29
lizmat ok, so you rather have something like undefine() ?
masak frankly, I'd rather just set it to Int in the above case
with arrays, I'd rather just set it to ()
etc 20:30
lizmat masak: and what should .first return when it doesn't find anything ?
masak I'm not proposing getting rid of Nil, fwiw
just that it lose that magic assignment behavior
I'm all for having some value that means "there wasn't anything here, sorry"
moritz lizmat: it could also fail 20:31
lizmat well, that's how it worked before, if I recall correctly
moritz fail('nothing here, move along')
masak yeah, I'd be fine with it throwing an exception, even
lizmat just like .pop fails atm instead of returning Nil
moritz IterationEnd :-)
lizmat but all of this discussion strayed from my original question, which I consider answered now 20:32
masak +1 20:34
jnthn I did fear Nil would slow down every assignment, but it turns out you need to do a type check anyway on assignment, and you can put the Nil magic on the failure path. 20:40
The Nil assignment magic is so you can write stuff like `my ExpectedType $foo = @bar.first(&predicate)` 20:41
Without it, what could `first` return? 20:42
moritz a Failure
masak I'm not opposed to a type that means "you expected there to be something here but there wasn't anything" 20:43
moritz or you could give first, pop et al an optional argument for the fallback
jnthn Right, 'cus specifying things twice aids refactorability. :)
masak .oO( poor man's Maybe )
jnthn m: say Failure ~~ Nil 20:44
camelia rakudo-moar 905242: OUTPUT«True␤»
jnthn And Failure is a Nil, which just happens to carry an exception because there's something useful to convey beyond "there wasn't a value"
japhb jnthn: To be clear, you're saying that Nil handling does not slow down assignments that would have worked normally *at all*? 20:45
moritz does that mean Failure also have the semantics of resetting stuff to the default value?
my Int $x is default(5); sub f() { fail 'fast' }; $x = 42; $x = f(); say $x
m: my Int $x is default(5); sub f() { fail 'fast' }; $x = 42; $x = f(); say $x 20:46
camelia rakudo-moar 905242: OUTPUT«Earlier failure:␤ fast␤ in sub f at <tmp> line 1␤ in block <unit> at <tmp> line 1␤␤Final error:␤ Type check failed in assignment to $x; expected Int but got Failure (Failure.new(exception...)␤ in block <unit> at <tmp> line 1␤␤»
masak m: my Int $x = 42; $x = Failure; say $x
camelia rakudo-moar 905242: OUTPUT«Type check failed in assignment to $x; expected Int but got Failure (Failure)␤ in block <unit> at <tmp> line 1␤␤»
moritz
.oO( Liskov? )
I don't think I'd like it the other way though
masak no please no
not more of it
moritz masak: not more what? Liskov violation? or magic? 20:47
masak magic
jnthn japhb: I'd have to go code-digging, but I believe it's on the failover path. 20:48
japhb jnthn: But it doesn't prevent optimizations that you'd otherwise be able to do?
jnthn japhb: Those type checks don't spesh away yet, but once we get *that* done too then the Nil case is essentially free.
japhb oh cool 20:49
jnthn The far costlier thing going on in assignment is the WHENCE callback stuff, fwiw.
dalek kudo/nom: ebe9147 | lizmat++ | src/core/SlippyIterator.pm:
Make Empty work faster with the SlippyIterator

  - check for Empty directly at startup
  - check for first value pulled, don't start if IterationEnd:
   this should handle the slip() cases faster
  - rewrite method in nqp entirely
  - 5% faster in my @a = ^1000; for ^1000 { my @b = @a.grep({ 0 }) }
rakudo/nom: ec0258a | lizmat++ | src/core/Slip.pm:
rakudo/nom: Give Empty its own .perl output
rakudo/nom:
rakudo/nom: - for easier debugging
rakudo/nom: - for faster .perl output for Empty
jnthn Which I didn't yet hit on a good strategy for getting rid of. 20:50
lizmat - and yes, it roundtrips ok
This breaks two spectests that were specifically checking for .perl
returning "slip()". I consider those tests to be sub-optimal :-)
japhb I'm not familiar with that bit, what is the WHENCE callback?
lizmat review: github.com/rakudo/rakudo/commit/ec0258a 20:51
jnthn m: my %h; if %h<a> { }; say %h.keys # we never vivify a hash entry
camelia rakudo-moar 905242: OUTPUT«()␤»
jnthn m: my %h; if %h<a> -> \entry { entry = 42 }; say %h.keys # we never vivify a hash entry
camelia rakudo-moar 905242: OUTPUT«()␤»
lizmat japhb: it's the bit that makes:
jnthn duh
lizmat m: my %h; my $b := %h<a>; dd %h; $b = 42; dd %h
camelia rakudo-moar 905242: OUTPUT«Hash %h = {}␤Hash %h = {:a(42)}␤» 20:52
lizmat work
jnthn m: my %h; %h<a> = 42; say %h.keys
camelia rakudo-moar 905242: OUTPUT«(a)␤»
jnthn Right, that :)
Same on arrays etc.
It's a 1-shot callback-on-assign
m: my %h; %h<a b c> |= 1..3; say %h 20:53
camelia rakudo-moar 905242: OUTPUT«Cannot assign to an immutable value␤ in block <unit> at <tmp> line 1␤␤»
jnthn d'oh
japhb Oh gah, that case that lizmat showed is ... ew, yeah
jnthn m: my %h; %h<a b c> Z= 1..3; say %h
camelia rakudo-moar 905242: OUTPUT«{a => 1, b => 2, c => 3}␤»
jnthn Also since meta-ops like Z= can happen then it can happen somewhat "at a distance"
japhb nods ruefully
jnthn First-class l-values are both powerful and a performance headache.
japhb Totally get that. 20:54
And it's not just that they're first-class l-values, it's also that they can vivify
jnthn Aye
Thankfully, we did make assignment something that the VM can understand.
dalek ast: ce75103 | lizmat++ | S03-metaops/reduce.t:
Fix two sub-optimal tests that broke with ec0258a
 20:55
jnthn Spesh skates on extremely thin ice at the moment in that regard, though.
japhb I bet. That whole problem space just feels like running through a locust swarm and trying not to hit any bugs 20:56
jnthn We'll need proper alias analysis before long, but that gets us a good way towards escape analysis too...
...which we'd probably want anyway.
japhb nodnod
jnthn wonders if we'll manage EA during the year :) 20:57
notviki My dalek replacement is ready. Anyone got keys to rakudo/rakudo, rakudo/star, and moarvm/moarvm and can go into Settings -> Web Hooks and swap out dalek for: geth.perl6.party/?chan=#perl6-dev (or #moarvm for moarvm), Content-type: application/json and "Send me everything." for which events? 21:00
dalek ast/6.c-errata: deba56e | lizmat++ | S03-metaops/reduce.t:
Fix two tests that broke with ec0258a
notviki (though currently only "Pull Request", "Create", and "Push" events have handlers)
moritz notviki: I can do that for rakudo/{rakudo,star}, iirc 21:01
notviki cool
jnthn Maybe let's do a couple of repos first, see how it is, then do the rest? :) 21:02
notviki Sounds good
done doc and roast so far.
jnthn OK
AlexDaniel done for whateverable
:)
jnthn I'll do MoarVM tomorrow unless a showstopper stops the show :)
notviki++
moritz notviki: doen for rakudo/{rakudo,star}
*done
AlexDaniel .tell dalek We like dogfood. Change the webhook to geth.perl6.party/?chan=#perl6-dev (or #moarvm for moarvm), Content-type: application/json and "Send me everything." 21:04
yoleaux2 AlexDaniel: I'll pass your message to dalek.
Geth ast/zoffixznet-patch-1: 7bd88e48f1 | (Zoffix Znet)++ | README.md
s/Environment/Environmental/

also bot test		 21:06
ast: zoffixznet++ created pull request #220:
s/Environment/Environmental/
ast: c7904f7da9 | (Zoffix Znet)++ | README.md
s/Environment/Environmental/ (#220)

also bot test
notviki k
so far so good :P 21:07
timotimo i like its initial capital letter
also its color is nice
oh, create pull request, eh?
notviki Yeah, unlike dalek this one will also say when people create pull requests 21:08
(I noticed on doc repo some seem to be unreviewed for days)
timotimo does it also receive comments and such on pull requests? so we could theoretically check that nothing got done in a pull request? 21:09
notviki Yeah, there's a web hook for comments too. These are all the available events we could do something for: blob:imgur.com/42205f88-d5d1-4ad3-8fe4-02c3257c938a 21:10
i.imgur.com/xwdjIGJ.png
diakopter notviki: cool 21:11
notviki: did you try some very long messages to see if it throttles messages enough to get past freenode's spam detection? 21:12
notviki diakopter: it does something smarter for when the push has multiple commits: irclog.perlgeek.de/perl6/2017-01-08#i_13880268 21:13
diakopter: for long commit messages it abridges them (saying $X more lines) and still gives review URL
Though now I realize it doesn't currently do anything for very long single lines 21:14
diakopter neat
well presumably they'd just be truncated by the irc server 21:15
timotimo make sure to abbreviate extremely long branch names ;) 21:18
notviki good idea.
Geth: source
Geth notviki, Source at github.com/zoffixznet/geth To add repo, add an 'application/json' webhook on GitHub pointing it to geth.perl6.party/?chan=#perl6
timotimo "well volunteered"? ;) 21:19
notviki Well, I just created two Issues on it :)
timotimo cool :) 21:20
Geth kudo: fbbe446c64 | (Elizabeth Mattijsen)++ | src/core/Rakudo/Internals.pm
Introducing R:I.ZipIterablesMapIterator

Zips iterables, each zip passed as an IterationBuffer to the mapper. The new workhorse for Zop		 21:59
camelia rakudo-moar ec0258: OUTPUT«===SORRY!=== Error while compiling <tmp>␤Undeclared names:␤ Elizabeth used at line 1␤ Internals used at line 1␤ Mattijsen used at line 1␤Undeclared routines:␤ core used at line 1␤ fbbe446c64 used at line 1␤ src used …»
rakudo-moar ec0258: OUTPUT«===SORRY!=== Error while compiling <tmp>␤Bogus postfix␤at <tmp>:1␤------> Introducing R:I.ZipIterablesMapIterator⏏␤ expecting any of:␤ infix␤ infix stopper␤ postfix␤ statement end␤ sta…»
rakudo-moar ec0258: OUTPUT«===SORRY!=== Error while compiling <tmp>␤Two terms in a row␤at <tmp>:1␤------> s, each zip passed as an IterationBuffer⏏ to the mapper.␤ expecting any of:␤ infix␤ infix stopper␤ postfix␤ stateme…»
rakudo-moar ec0258: OUTPUT«===SORRY!=== Error while compiling <tmp>␤Unsupported use of C++ constructor syntax; in Perl 6 please use method call syntax␤at <tmp>:1␤------> The new workhorse ⏏for Zop␤»
rakudo-moar ec0258: OUTPUT«===SORRY!=== Error while compiling <tmp>␤Confused␤at <tmp>:1␤------> review: https:⏏//github.com/rakudo/rakudo/commit/fbbe44␤ expecting any of:␤ colon pair␤» 22:00
lizmat que ?
notviki: it's trying to run my commit message as code ? 22:01
timotimo oh jesus
rakudo: say "hi"
camelia rakudo-moar ec0258: OUTPUT«hi␤»
notviki lol
geekosaur guessing camelia has a special case to not accept commands from dalek when the repo name matches a program
timotimo yeah, it must have had that so far %)
notviki Well, that's easy to rectify
timotimo that's amazing
notviki No, it didn't dalek reported it as "rakudo/nom"
timotimo yeah, just put a ü instead of u or something
notviki But I taught geth to treat nom as master
geekosaur er s/when/, for when/
timotimo or an extra space
geekosaur ah 22:02
timotimo quite frankly, that is hilarious :)
diakopter uh huh, botwars 22:03
notviki There. Fixed forever :}
geekosaur batty bots
lizmat m: use nqp; BEGIN my $h := nqp::hash("a",42); dd $h # huh? Am I missing something ? 22:23
camelia rakudo-moar fbbe44: OUTPUT«Mu␤»
lizmat m: use nqp; my $h; BEGIN $h := nqp::hash("a",42); dd $h # even weirder ?
camelia rakudo-moar fbbe44: OUTPUT«Any $h = Any␤»
lizmat m: use nqp; my $h; BEGIN { $h := nqp::hash("a",42) }; dd $h # are we not allowed to run nqp code in a BEGIN block ? 22:24
camelia rakudo-moar fbbe44: OUTPUT«Any $h = Any␤»
b2gills m: use nqp; INIT my $h := nqp::hash("a",42); dd $h
camelia rakudo-moar fbbe44: OUTPUT«{:a(42)}␤»
b2gills m: use nqp; my $h := BEGIN nqp::hash("a",42); dd $h 22:25
camelia rakudo-moar fbbe44: OUTPUT«{:a(42)}␤»
lizmat b2gills: wow,
wonder what's going on there
diakopter m: use nqp; BEGIN my $h = nqp::hash("a",42); dd $h 22:27
camelia rakudo-moar fbbe44: OUTPUT«Cannot find method 'dispatch:<.?>': no method cache and no .^find_method␤ in block <unit> at <tmp> line 1␤␤»
diakopter wheh 22:28
b2gills m: use nqp; BEGIN my $h = nqp::hash("a",42); put $h.^name
camelia rakudo-moar fbbe44: OUTPUT«BOOTHash␤»
diakopter m: use nqp; BEGIN our $h := nqp::hash("a",42); dd $h # lizmat <- 22:34
camelia rakudo-moar fbbe44: OUTPUT«Any $h = Any␤»
lizmat diakopter: I'd rather not pollute namespaces 22:35
diakopter ok, I wasn't suggesting doing that; just showing more evidence of what might be going on 22:36
timotimo m: use nqp; BEGIN my Mu $h := nqp::hash("a",42); dd $h 22:42
camelia rakudo-moar fbbe44: OUTPUT«Mu␤»
Geth ast: 876785a94f | MasterDuke17++ | S05-mass/rx.t
Add a test for Nd digits in regex quantifiers
 22:54

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!