japhb Oh, very nice, unmatched} ! 00:05
unmatched} s: &say, \('yes, I think so')
SourceBaby unmatched}, Sauce is at github.com/rakudo/rakudo/blob/c322...ors.pm#L22
unmatched} :D
japhb Can you make it handle the slight sugar of "Date.new('2016-06-06')" where it handles exactly the syntax "Type.method(args...)"? 00:06
Or "sub(args...)"? 00:07
unmatched} maybe, I'll think about it. 00:08
Right now it just puts the given stuff as args to sourcery sub from CoreHackers::Sourcery
s: "/tmp".IO.dir, "uc" 00:11
SourceBaby unmatched}, Sauce is at github.com/rakudo/rakudo/blob/c322...ool.pm#L80
dalek kudo/nom: 9bfbab9 | (Zoffix Znet)++ | src/core/Dateish.pm:
Improve no-arg .new on Dateish error message

Dateish objects can be created via .new, if acceptable arguments are given. The current error for argument-less calls of .new is misleadidng, as it claims .new cannot be called at all.		 00:29
travis-ci Rakudo build errored. Elizabeth Mattijsen '.squish|.unique|.repeated now pass on is-lazy 03:41
travis-ci.org/rakudo/rakudo/builds/151333658 github.com/rakudo/rakudo/compare/5...50e279ba98
buggable ☢ [travis build above] Build log missing from at least one job. Check results manually.
[Tux] This is Rakudo version 2016.07.1-155-g9bfbab9 built on MoarVM version 2016.07-18-g2f269d8 06:18
test 15.208
test-t 7.472
csv-parser 16.391
I re-enabled Inline::Perl5 timing tests by forcing perl6 to use system perl when dealing with Inline::Perl5 until longdouble support is available 07:38
I am happy to see that by now native perl6 is *faster* than Inline::Perl5 with XS
timotimo NativeCall is too slow in general 07:39
[Tux] tux.nl/Talks/CSV6/speed5.html
DrForr +1 07:41
timotimo how is the runtime measured vs time? there's a noticable difference for the first XS case, but not for the others
[Tux] sloppy: it runs -e1 and the CSV test with an empty csv file twice. takes the avarage of those three and subtracts that from the full time of the real test 07:42
timotimo huh
[Tux] perl6 -MText::CSV -e1 07:43
that should tell me the startup/load time of the process without processing a single line of data
perl6 -MText::CSV test-t.pl </tmp/hello.csv
is the full test
timotimo OK, so the startup time alone is a gigantic chunk of what the XS test does 07:44
[Tux] subtract the time used for the first from the second and you get the processing time
timotimo but the other XS test has much less overhead
[Tux] that is why I say sloppy. It is not really reliable
timotimo OK 07:45
[Tux] feel free to suggest improvements on github.com/Tux/CSV/blob/master/time.pl 07:47
nine [Tux]: maybe I should have a look at how to speed up Inline::Perl5 then :) 07:48
[Tux] if you do, you'll have to tell me, as it won't update automagically as I need to alter $PATH for it to install
nine And maybe I can find a workaround for the missing longdouble support. Like casting those to double when passing back to rakudo. It's just so darn easy to break non-x86_64 architectures when fiddling around with that. 08:00
[Tux] :) 08:01
[Tux] => $work
ShimmerFairy I just discovered that you can return a rw slice that DWIMs in terms of assignment, that's pretty awesome :) 09:12
lizmat m: my @a; @a[1,3,5] = ^3; dd @a # ShimmerFairy: this what you mean? 10:44
camelia rakudo-moar 9bfbab: OUTPUT«Array @a = [Any, 0, Any, 1, Any, 2]␤»
jnthn m: sub foo(@a) { @a[1,3,5] }; my @b; foo(@b) = ^3; say @b 10:51
camelia rakudo-moar 9bfbab: OUTPUT«[(Any) 0 (Any) 1 (Any) 2]␤»
jnthn I think that'd be a better illustration of what was meant :)
One of the things that works because l-values are first class.
(Which is also one of the reasons Perl 6 is so hard to optimize :P)
timotimo those are some first-class lvalues 10:56
ShimmerFairy jnthn: it even works when you .rotor the return array, which is a pleasant surprise :) 11:06
dalek p: a2f4026 | (Pawel Murias)++ | src/vm/js/nqp-runtime/reprs.js:
[js] Get rid of a no longer needed hack.
 11:17
p: e7a2297 | (Pawel Murias)++ | src/vm/js/Operations.nqp:
[js] nqp::isnull shouldn't no longer be passed a js undefined value so it doesn't need to handle it anymore.
p: a2312e6 | (Pawel Murias)++ | src/vm/js/nqp-runtime/reprs.js:
[js] Remove a HACK comment as we now handle STable flattening in a much more correct and sane manner.
p: aa4a9e9 | (Pawel Murias)++ | src/vm/js/Operations.nqp:
[js] Remove comment about portability with JScript, we are targeting EcmaScript6 now.

If it's a problem the test suit on a browser we care about the test suit should catch it.
timotimo pmurias: did you see one of your commits - regarding $cursor_type or something - caused --profile to no longer work? 11:18
pmurias timotimo: no, I'll backlog 11:31
timotimo just last night we found out about it 11:32
pmurias when do 'SC not yet resolved' exceptions happen? 11:40
timotimo didn't dig deeper for that yet
lizmat pmurias: perl6 --profile -e '' 11:41
timotimo oh, i thought he was asking about the internal mechanism that gives that message
lizmat ah, dunno :-) 11:42
pmurias ./nqp-m --profile-compile -e 1 reproduces the error without involving Rakudo 11:43
timotimo yup
ShimmerFairy I do wish "Partially dimensioned views of arrays" were implemented. I'm wondering if I could implement it, but I suspect there's a reason the shaped array authors didn't get to it the first time :P
timotimo the author was jnthn, and time was short 11:44
that's mostly why it didn't make it in yet :)
ShimmerFairy Would it have to be a 6.d thing, or is it something that would be allowed to sneak into 6.c? (I personally would lean towards 6.d myself) 11:45
timotimo there's probably already tests in 6.c for it? perhaps? 11:47
pmurias I'll try to figure out why the --profile thing fails, but it seems very weird
timotimo did you see the commit i golfed it to? 11:48
ShimmerFairy timotimo: I suppose if there are fudged tests, then it'd obviously be fine :) . But otherwise I'd rather not confuse what 6.c actually is. 11:49
timotimo *shrug*, it could go into 6.c.1 :)
pmurias timotimo: golfed you mean the one setting cursor_type?
timotimo yup 11:50
ShimmerFairy Of course, my only concern is not having the specific version number "6.c" be overloaded to slightly different feature sets.
timotimo people further up the food chain than me will make those decisions :) :) 11:53
dalek kudo/nom: d30806b | lizmat++ | src/core/Any-iterable-methods.pm:
Introduce Any.quickmap(&block)

This is a 30%+ faster alternative to Any.map. But it can only be used
  - if the block takes 1 parameter
  - if the block *always* returns 1 value that isn't a Slip
  - if the block does not contain "last", "next", "redo"
  - if the block does not contain any phasers
Examples:
   self.match(:g, :$x, $pat).quickmap: *.Str # converting matches to strings
   self.quickmap(*.perl).join(', ') # creating a .perl presentation
I'm not too happy with the name. Considered "rawmap" and "translate" eea786e | lizmat++ | src/core/ (31 files): Use Any.quickmap in the setting where appropriate		 11:56
lizmat Review: github.com/rakudo/rakudo/commit/d30806b 11:57
pmurias timotimo: it seems that the serialization context containing NQPCursor is not yet loaded while executing run_profiled
brrt how would last, next, redo work with *.map anyway 11:58
that would be weird
lizmat eh, parts of the core depend on it
map is basically a for and vice versa
brrt hmmm
oh yes, control exceptions 11:59
lizmat for @a { } is basically @a.map: { }
unmatched} .amap() ... almost .map() :) 12:05
lizmat I put this in the commit message: I was also thinking about "xlate"
unmatched} I like it 12:06
lizmat anyways, now we only need to build some logic in the optimizer to make it an automatic "quickmap"
or "xlate"
jnthn argh no quickmap *sigh* 12:11
unmatched} :)
jnthn Was that even discussed? :S 12:12
pmurias jnthn: it seems in src/vm/moar/HLL/Backend.nqp we are using regexes while compiling it with --no-regex-lib 12:13
jnthn We can already fast-path map for blocks without phasers and with one parameter, so that isn't making much need for it. Having the last/next/redo handlers is pretty much free if they're not invoked 'cus there is no runtime setup work for them. And we could (but I think do not yet) look at the declared return type of the map block, and nqp::istype(that-type, Slip) to know it can never return a slip. 12:15
ShimmerFairy Are the speed improvements in quickmap at least partially due to not having to check for those simplifications, whereas map presumably does? 12:16
dalek kudo/nom: 76be77c | lizmat++ | src/core/ (32 files):
Exit Any.quickmap
 12:17
jnthn Oh, and you can't really static-analyze for whether last/next/redo are there or not since they can work with dynamic scoping, so it's not so easy to take advantage of that bit either. 12:18
I'm all for looking at ways to make things faster, but I don't think this one will fly from a lang design perspective, and the main benefit (not checking for Slip) we can have in a safer way that will actually tell the user if they did accidentally return a Slip (and we'd be able to optimize that type check out in spesh in a bunch of cases if it's in the map block) 12:19
lizmat jnthn: the 30% speed increase was already against the optimised 1 arg no phasers version 12:37
the most expensive part is all of the "redo" handling
anyways, I started thinking about this out loud yesterday late: 12:41
jnthn 30% on a small volume of data or a large volume?
If redo is to blame then I'd say let's look if we can't speed up how that is handled to make it cheaper 12:42
lizmat 1my @a = ^1000; for ^100000 { @a.quickmap: *.chr }
*1
jnthn OK, so quite a bit
(Was wondering if the lack of checking a couple of things at iteration start was where some of the win came, but on 1000 items then "no") 12:43
dalek p: 9958b2f | (Pawel Murias)++ | src/vm/moar/HLL/Backend.nqp:
Avoid using regexes when the regex library is not yet loaded. This unbreaks --profile.
 12:55
unmatched} \o/ pmurias++
lizmat weee.... 12:57
confirm we can do profiles again 13:02
will bump NQP_REVISION after running a final spectest
[Coke] pmurias++ nice 13:04
lizmat++ danke
lizmat apart from a flapper on t/spec/S17-promise/start.t that I haven't had in a *long* time now, it seems ok 13:08
jnthn ...oh admmit :( 13:09
dalek kudo/nom: 3878066 | lizmat++ | tools/build/NQP_REVISION:
Bump NQP to fix RT #128892, pmurias++
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128892
jnthn That's going to be a darn nightmare to find if it still flaps because it didn't fail in 100 runs yesterday.
lizmat runs it again
jnthn: You planned 47 tests but ran 17 so it actually crashed 13:11
Cannot invoke this object (REPR: Null; VMNull) 13:12
in block <unit> at t/spec/S17-promise/start.t line 70
gist.github.com/lizmat/6ae3ea26c4a...968fcaf3dd # full stack trace 13:14
jnthn: ^^^
jnthn hmm... Thanks. 13:16
lizmat m: say await start $/ # perhaps related ? 13:18
camelia rakudo-moar 76be77: OUTPUT«WARNINGS for <tmp>:␤Useless use of $/ in sink context (line 1)␤Nil␤»
jnthn TimToady: ^^ ;) 13:19
lizmat jnthn: looks like "my @got = await do for 1..5 { start { buf8.new } }" is where it goes wrong, if it goes wrong 13:21
[Coke] lizmat++ # thursday. 13:23
lizmat ?? :-)
jnthn: datapoint: removing the warnings still makes it crash occasionally ( I would say 1/30 with a fully loaded machine) 13:25
jnthn lizmat: And the above in a loop does it? :) 13:27
lizmat jnthn: another datapoint: if the start uses a thunk, instead of a block, it also crashes 1/30
jnthn: I was running the test-file in a loop
I'll try running that piece of code in a loop now
jnthn ah, OK. Guess I got lucky 100 times :S
lizmat or OSX is more picky or something 13:28
jnthn OSX is good at shaking these things out, yes 13:29
lizmat for ^100000 { my @got = await do for 1..5 { start { buf8.new } } } # doesn't crash, runs for 33 secs
so it feels like some test before it is messing things up
jnthn: not so nice datapoint: removing all the tests before the one that crashees every now and then 13:36
makes it *still* crash, but it feels like the chance of it is a lot smaller
more like 1/60 or so 13:37
jnthn: can no longer make it crash when changing the "buf8.new" to "42" 13:41
jnthn: so it feels like some buf8.new / start interaction
ShimmerFairy lizmat: just thought of this: what about Buf instead of buf8? 13:44
lizmat ShimmerFairy: actually,it seems related to the auto-punning of the buf8 role 13:45
jdv79 if suspected that a variable was being shared between threads when it shouldn't where would be a good place to look?
ShimmerFairy ah
lizmat jnthn: if I put back the "buf8.new", and add another "my $b = buf8.new" before it, I can't get it to crash
jnthn: so it feels like punning a role into a class from a different thread, is not quite ok 13:46
jnthn lizmat: I thought that'd been fixed, but yeah, it's quite an involved process so worth a look 13:48
jdv79: You can try setting MVM_CROSS_THREAD_WRITE_LOG=1 in the environment, and see if there are any surprises
jdv79: Though some things it turns up are benighn
uh, sp :)
jdv79 ok 13:49
lizmat
.oO( benightgown )
jnthn: should I rakudobug this conversation ? 13:51
jnthn lizmat: Please. I suspect I'll be writing a mildly boring document the rest of today, and I'm meant to take tomorrow off-ish to relax :) 13:53
lizmat jnthn: okidoki, long weekends are good :-) 13:54
jnthn: RT #128896 14:00
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128896
jnthn Thanks
lizmat you're welcome: I hope this helped
jnthn Well, having ideas of what tickles/doesn't tickle the bug can help, though at the end of the day the solutions tend to come from hours sat in debuggers, looking at output logs, doing experiments, reading generated code, etc. 14:02
Fixing concurrency bugs is mostly an exercise in patience, it seems. :) 14:03
jdv79 why is there no path in "from site#sources/9C152F2320E9F47891023366BF40420AE8E7F235 (XML::Element):469"?
nine jdv79: where's that from? 14:04
jdv79 everything else seem to have a path even if its rel
the log from MVM_CROSS_THREAD_WRITE_LOG=1
where is this "site#" then? 14:05
nine Ah. It's the site repo. install/share/perl6/site
lizmat what nine said :-)
jdv79 thanks 14:06
nine This relative reference is decoded by BackTrace::AT-POS but of course MoarVM doesn't know about that.
jdv79 ok 14:09
lizmat jnthn: would you have something against breaking out Seqs in sequential map into separate source files ?
jnthn Seqs in sequential map? 14:10
lizmat it's now a 600+ line sub
jnthn looks confused
Oh, the iterator classes?
lizmat yup
jnthn Yeah, though if the sub is just too long then moving them above/below it would also maybe do? 14:11
When to go in separate files it's harder to not leak them...well, of course they can go under Rakudo::Internals too I guess :)
lizmat ok, I'll start with moving up the iterators 14:12
will make it easier if we do want to split it out later
stmuk_ wow perl6-j works a lot better than last time I looked (admittedly a while back) 14:13
dalek kudo/nom: ef04e1e | lizmat++ | src/core/Any-iterable-methods.pm:
Move sequential-map Iterator classes up

This is for better readability and maintainability of these rather involved Iterator classes. No functional change is involved here.		 14:44
unmatched} finished Day 1 of Internals Course. 15:28
Took me a month, but I stuck with it :P 15:29
jnthn Congrats :)
Hope it was useful :)
unmatched} Yeah, I learned a lot.
jnthn++
perlpilot Isn't that a 2 day course? you're half way done! 15:31
jnthn Thanks also go to those who funded the course development. There's no way I coulda found time to do it without that. :-) 15:32
jdv79 the edument nqp course thing? 15:48
unmatched} yeah
[Coke] jnthn++
jdv79 yeah, it was neat. i don't remember it being 2 days.
timotimo i do remember sleeping in between sessions 15:49
jdv79 is that the one that jnthn did at spw?
[Coke] I remember stroopwafel
jdv79 i just did it online since that room was jammed by the time i got there
timotimo stroopwafel! yes!
[Coke] jdv79: nope. a year prior
jdv79 oh. i guess i'm misremembering again. 15:50
what was last year then? was that a p6 intro?
[Coke] big thanks again to everyone who sponsored SPW last year! 15:51
(And the internals course!)
jnthn Yeah, at spw I did a Perl 6 intro day :) 16:01
[Coke] RT: 1332; @LARRY: 14; CONC: 25; GLR: 6; JVM: 66; LTA: 114; NEW: 859; NYI: 82; OSX: 5; PERF: 22; POD: 17; PRECOMP: 10; RFC: 31; SEGV: 32; STAR: 5; TESTNEEDED: 15; TODO: 10; UNI: 28; UNTAGGED: 496; WEIRD: 3 16:15
buggable: rt GLR 16:16
buggable [Coke], Found 4 tickets tagged with GLR. Details: bug.perl6.party/1470932219.html 16:17
[Coke] .tell TimToady #123072 has a sink in it. 16:21
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=123072
yoleaux2 [Coke]: I'll pass your message to TimToady.
unmatched} buggable: rt 16:23
buggable unmatched}, TOTAL: 1361, UNTAGGED: 556, BUG: 421, LTA: 107, JVM: 62, NYI: 35, RFC: 31, SEGV: 31, UNI: 27, CONC: 25, PERF: 22, POD: 14, @LARRY: 14, PRECOMP: 10, TODO: 10, BUILD: 7, GLR: 6, STAR: 5, NATIVECALL: 4, WEIRD: 3, BOOTSTRAP: 3, MOARVM: 2, OSX: 2, WEB: 1, SPESH: 1, DOCS: 1, MATH: 1 Details: bug.perl6.party/1470932633.html
[Coke] buggable: rt GLR 16:24
buggable [Coke], Found 4 tickets tagged with GLR. Details: bug.perl6.party/1470932707.html 16:25
unmatched} I recall there was a bug for for { .map ... } not being sunk. Looks like related to #123072 . Don't see it in the list now; not sure if it was fixed
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=123072
unmatched} m: for ^5 { ^5 .map: *.say } 16:26
camelia rakudo-moar ef04e1: OUTPUT«0␤1␤2␤3␤4␤0␤1␤2␤3␤4␤0␤1␤2␤3␤4␤0␤1␤2␤3␤4␤0␤1␤2␤3␤4␤»
unmatched} Oh, tis fixed
b2gills
.oO( Rakudo::Internals::&DUMB_MAP )
 16:29
[Coke] is tagging tickets that SIGABORT with [SEGV] ok? 16:30
hoelzro hmm...they're similar 16:31
from what I've seen, SIGABRT is usually a libuv problem
[Coke] yup, here as well. :) 16:32
well I did it, someone can come up with a better tag if needed. :)
hoelzro I mean, both of them require looking at core dumps, both of them are in MoarVM...
so the skillset for fixing them is roughly the same
hoelzro doesn't see a problem with [SEGV] 16:33
[Coke] buggable: rt untagged
buggable [Coke], Found 556 untagged tickets. Details: bug.perl6.party/1470933204.html
hoelzro unless we want an umbrella term like [SIGNAL] or [TERMINATED]
[Coke] right, same with [CONC] that's really [ASYNC]; was just going for the 4-char tag. :)
hoelzro ahh, I see 16:34
I agree with "[SEGV] until something better presents itself" =)
TimToady Imma kinda surprised it didn't fix #123072 too 16:35
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=123072
yoleaux2 16:21Z <[Coke]> TimToady: #123072 has a sink in it.
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=123072
TimToady will look at it later twoday 16:36
lizmat ,oO( TimTwoday :-) 16:38
[Coke] TimToady++
TimToady: didn't you just rule on something very similar to RT #125398 ? 16:42
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=125398
lizmat So I'm looking at creating a version of sequential-map that will be faster if the Block indicates it returns something that cannot be a Slip 16:51
so that changing [email@hidden.address] { .Str }" to [email@hidden.address] --> Str { .Str }" would give you the optimization 16:52
however, that's illegal syntax:
m: my $b = --> Str { .Str }
camelia rakudo-moar ef04e1: OUTPUT«===SORRY!=== Error while compiling <tmp>␤Prefix -- requires an argument, but no valid term found␤at <tmp>:1␤------> my $b = --⏏> Str { .Str }␤ expecting any of:␤ prefix␤»
lizmat m: my $b = -> $_ --> Str { .Str } # this works
camelia ( no output )
jnthn m: my $b = -> --> Str { .Str }
camelia ( no output )
lizmat aha... ok
jnthn Well, or that
m: my $b = { also returns Str; .Str } 16:53
camelia rakudo-moar ef04e1: OUTPUT«===SORRY!=== Error while compiling <tmp>␤Cannot resolve caller trait_mod:<returns>(Block, Str); none of these signatures match:␤ (Routine:D $target, Mu:U $type)␤at <tmp>:1␤»
jnthn Aww
Arguably that should work too :)
lizmat also: -> --> indicates *no* parameters
jnthn Yeah
lizmat -> $_ --> Str
that works, but allocates an extra Scalar for every iteration :-( 16:54
jnthn It does? Hmm
What about -> Int $_ --> Str { } out of curiosity?
(or other appropraite type for your example) 16:55
lizmat yeah, that works, jnthn++
TimToady [Coke]: yes, but that seems like a separate bug, prolly
unmatched} m: for ^3 { .map: *.say }; 16:56
camelia ( no output )
unmatched} TimToady: ^ seems closely related
TimToady to the prior bug, yes
lizmat jnthn: this gives about a 10% improvement, rather than the 30% of quickmap 16:58
jnthn lizmat: Right, but we didn't figure out anything about the redo thing, which you mentioned was a big part of the issue?
lizmat well, basically the difference between the approach in quickmap and the approach I'm taking in this new "IterateOneNotSlippingWithoutPhasers" class 17:00
dalek rakudo/nom: c587b9d | lizmat++ | src/core/Any-iterable-methods.pm: 17:07
rakudo/nom: Add IterateOneNotSlippingWithoutPhasers class
rakudo/nom:
rakudo/nom: This Iterator class will be used whenever you're mapping /foring
rakudo/nom: any block that has a return signature that excludes Slips.
rakudo/nom:
rakudo/nom: Benchmarking indicates about a 10% improvement. Please note that
rakudo/nom: you will still have to jump through some hoops to get the right
rakudo/nom: signature, and a signature that will actually help:
rakudo/nom:
rakudo/nom: my @a = ^1000; @a.map: -> $_ --> Str { .Str } # wrong, extra Scalar/iter
rakudo/nom: my @a = ^1000; @a.map: -> Int $_ --> Str { .Str } # correct, 10% faster
rakudo/nom:
rakudo/nom: It would be nice if the signature gotcha would be less easy to fall into.
lizmat review: github.com/rakudo/rakudo/commit/c587b9d 17:08
TimToady Anything with that many negatives in its name has got to be wrong somehow... :) 17:12
lizmat and I don;t disagree, "quickmap" or "xlate" would be much better :-) 17:15
unmatched} m: my @a = ^1000; say @a.map: sub { also returns Str; $^a.Str }
camelia rakudo-moar c587b9: OUTPUT«===SORRY!=== Error while compiling <tmp>␤Method 'has_returns' not found for invocant of class 'Mu'␤at <tmp>:1␤»
unmatched} [Coke]: I wonder what value there is in keeping those tickets open in the first place. 17:23
*stalled tickets
They seem to be all about macros that are entirely broken and entirely experimental. 17:24
[Coke] If we remove the feature, we can remove the bug reports. 17:37
otherwise, we'll end up having to re-discover all that stuff anyway.
unmatched} fair enough
gfldex has it been considered to have the unicode variants ¬ ∧ ∨ ⊻ for binary ops? 19:48
travis-ci Rakudo build errored. Elizabeth Mattijsen 'Bump NQP to fix RT #128892, pmurias++' 20:41
travis-ci.org/rakudo/rakudo/builds/151503212 github.com/rakudo/rakudo/compare/7...78066a9531
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128892
buggable ☢ [travis build above] Build log missing from at least one job. Check results manually.
jnthn m: my @a; @a.grep({ .value andthen $_ eq 'foo' }) 22:43
camelia rakudo-moar c587b9: OUTPUT«WARNINGS for <tmp>:␤Useless use of "eq" in expression "$_ eq 'foo'" in sink context (line 1)␤»
jnthn TimToady: le bogus sink warning &&
oops ^^
:)
.u ☢ 22:52
yoleaux2 U+2622 RADIOACTIVE SIGN [So] (☢)
jnthn heh, in my crappy font it looks like it could be a chess piece :P
TimToady is currently fighting with sinking methods that are hiding inside hllize and don't have an available sink 22:53
jnthn urgh
Though...nearly all method calls are hidden inside one of those, aren't they? 22:54
TimToady certainly true of the map inside: for ^3 { .map: *.say };
but I can't just transit inside and slap a .sink on things, so maybe just peek inside to see if the top thing inside is a method, and sink outside the hllize, is my current thought 22:55
tried adding a sink method in NQPMu, but that doesn't fly... 22:56
jnthn If you sink outside the hllize you'll likely be safer
Arguably we shouldn't be letting NQPMu escape into Perl 6 code
TimToady not sure it's NQPMu itself
not very informative on that score: Cannot find method 'sink': no method cache and no .^find_method 22:57
gfldex m: say Bool.package 23:00
camelia rakudo-moar c587b9: OUTPUT«Method 'package' not found for invocant of class 'Bool'␤ in block <unit> at <tmp> line 1␤␤»
gfldex how do I introspect if something is an enum (beside cheating by looking for method called "enums")? 23:03
TimToady m: say Bool.?enums 23:04
camelia rakudo-moar c587b9: OUTPUT«{False => 0, True => 1}␤»
jnthn m: say Bool.HOW
camelia rakudo-moar c587b9: OUTPUT«Perl6::Metamodel::EnumHOW.new␤»
jnthn m: say Bool.HOW ~~ Perl6::Metamodel::EnumHOW
camelia rakudo-moar c587b9: OUTPUT«Could not find symbol '&EnumHOW'␤ in block <unit> at <tmp> line 1␤␤Actually thrown at:␤ in block <unit> at <tmp> line 1␤␤»
jnthn m: say Bool.HOW ~~ Metamodel::EnumHOW
camelia rakudo-moar c587b9: OUTPUT«True␤»
jnthn Like that
gfldex thanks 23:05
jnthn wonders what gfldex is hacking on :)
jnthn also wonders whether to grab another beer, write a huffman encoder to finish his module and sleep...or to skip straight to sleep. :)
gfldex jnthn: i'm trying to match methods we already have in the docs with the methods available in .^methods. The lack of .package in some of the gutty things is slowing me down quite a bit. 23:07
jnthn ah
gfldex I can just CATCH things but I would like to produce a warning for the methods that are hard to introspect.
And on the stuff where the introspection is quite hard, it's quite hard to introspect the method name. :) 23:09
a strategicly placed CATCH did solve my problems and I'm still able to warn properly. 23:20
already found a missing method :D 23:21
jnthn Already finished my Huffman coder. 23:22
I was told I should sleep soon, so I did whisky instead of beer and hacked quicker. :)
Docs and a META6.json tomorrow and I'll have my first module for the ecosystem in a while. :) 23:26
TimToady that would be a Balmer matterhorn
jnthn ;)
github.com/jnthn/p6-http-hpack
github.com/jnthn/p6-http-hpack/blo...K.pm6#L259 is where I tripped over the sink error, fwiw
Will be fun to see what the JIT spits out for that module, also... It's full of natives. 23:28
Sleep time; 'night 23:33
timotimo gnite jnthn 23:37

Powered by Cro and the Raku® Programming Language.

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

Thank you!