MasterDuke jnthn: am i interpreting your comment on github.com/rakudo/rakudo/pull/867 correctly? 00:02
if i just send the given count directly into nqp::x, either unbox_i'ed or decont'ed, it can be negative
ahh, missed his sleep & 00:07
Zoffix wooohooo \o/ 00:54
perl6 bin/release/cli-runner.p6
* leave to play Far Cry 4 for 40 minutes; then come back*
"NeuralAnomaly RELEASE STATUS: Rakudo release DONE"
:) nqp and rakudo in forks got released automatically. 00:55
japhb Zoffix++ # That is so many kinds of good 01:55
Zoffix: On a completely unrelated note, IRC::Client: Is there a best practice for making IRC::Client::Plugin classes maximally testable? (Also, PLZ CAN HAZ SSL? :-) ) 01:56
MasterDuke how do i add an option to the perl6 binary? i added it to github.com/perl6/nqp/blob/master/s...r.nqp#L26, but it still complains if i try to use it 02:03
[Tux] This is Rakudo version 2016.08.1-123-gef98f8f built on MoarVM version 2016.08-35-g5108035 06:06
csv-ip5xs 9.626
test 15.430
test-t 7.169
csv-parser 17.058
lizmat Files=1135, Tests=52708, 224 wallclock secs (13.18 usr 3.81 sys + 1384.93 cusr 126.68 csys = 1528.60 CPU) 06:21
20 wallclock seconds less than yesterday, 120 CPU secs less than yesterday :-) 06:22
nine wow :)
lizmat moritz: if I search for "wallclock secs" (with quotes) on perl6-dev, the last one it finds is from 2016-08-19 06:23
moritz: ah, it actually says: "Searching this channel includes data up to 2016-08-22 00:42 H." 06:24
something seems stuck
nine: oddly enough, bare startup seems to have crawled up to .120 :-( 06:28
nine lizmat: indeed :/ No idea how that came to be. All my work should have strictly affected only programs that load modules. 06:30
lizmat: startup time stayed the same at least since f0df496 Sunday morning 06:34
lizmat running --profile-compile with '' shows that 92.7% is taken by: parse gen/moar/stage2/NQPHLL.nqp:1709 06:35
I guess we could make the case of "' faster by not calling parse on an empty string :-) 06:36
nine What exactly do we try to parse anyway?
lizmat the empty string in that case ?
nine But why?
lizmat to find out the bare startup time ? 06:37
nine Ooooh...the -e code
Sorry, coffee still needs to kick in :)
ShimmerFairy what's the P6 equivalent of nqp::getlexdyn, again? (That is, the P6 version of something like my $*THING := nqp::getlexdyn('$*THING') ) 06:50
moritz lizmat: it seems the IR clog search index rebuild is b0rked 06:55
lizmat ShimmerFairy: there's an internal sub called DYNAMIC, if that's what you mean? 06:56
it lives in stubs
ShimmerFairy lizmat: I may not need it in the first place, but I'm just wondering how to "lexicalize" the dynamic while retaining its value, which IIRC getlexdyn does in NQP land. 06:57
lizmat my $*FOO ?
my $*FOO = $*FOO ?
ShimmerFairy I thought that was disallowed, but maybe just for non-dynamics 06:58
neither work in retaining the value, just checked
lizmat yeah :-( 06:59
breakfast& 07:01
timotimo do we only have "temp $*FOO"? 07:08
lizmat m: temp $*FOO # no 08:13
camelia rakudo-moar ef98f8: OUTPUT«Can only use 'temp' on a container␤ in block <unit> at <tmp> line 1␤␤»
timotimo OK 08:16
jnthn morning, #moarvm 09:09
uh, no 09:10
coffee first
morning, #perl6-dev
nine Good morning, jnthn! I get the impression that your daily cycle is slowly moving? IIRC you used to /join around 10 ;) 09:14
jnthn Normally 10:30ish. :)
Bit later today...distracted by a new kitchen toy getting delivered :) 09:15
timotimo thermomix? :) 09:16
jnthn hah, I didn't know that existed :P 09:18
Just a blender, though. :)
Winter is coming. Time to make warming soups. :P 09:19
timotimo my mom used to work for Vorwerk to demonstrate it to people so they would decide to buy it
i think that was when me and my sis were keeping her from her full-time-job, so about 25 years ago
jnthn :)
timotimo they are cool devices. i got a used one from my grandma :3 09:20
(also, they are hot devices)
jnthn ShimmerFairy: `my $*FOO = CALLERS::<$*FOO>` or so may do it 09:21
timotimo thermomix isn't a topic for #perl6-dev, though :) 09:22
jnthn .tell lizmat -e '' spends a lot of time in parse not for parsing, but because that's where we load CORE.setting, so it's a decent measure of that...not really inclined to special-case it... :)
yoleaux2 jnthn: I'll pass your message to lizmat.
timotimo "special-case" it? like give us an additional stage that measures only loading the core setting? 09:23
jnthn timotimo: No, I thought the discussion was about some kind of trick to make -e '' super-fast by avoiding the call to .parse or something :) 09:24
timotimo ah, hehe.
well, it's gone up to 0.2s on my machine, too. i think it used to sit at about 0.11s?
jnthn Righty, I'll start out with [Coke]'s woes today, I think.
timotimo sounds godo
good*
a tummy ache is pulling me back to bed :| 09:25
jnthn ugh
Get well
timotimo i hope so! 09:26
i expect once the food i put in yesterday gets out, things will normalize quickly
nine Seems like this is an instant memory explosion: sub bar() { $*FOO = 'bar'; }; sub foo() { my $*FOO = CALLERS::<$*FOO>; bar; }; my $*FOO = 'foo'; foo; say $*FOO;
Alt+SysRq+f is your friend there... 09:27
Golfed it to: sub bar() { $*FOO = 'bar'; }; sub foo() { my $*FOO = CALLERS::<$*FOO>; bar; }; foo 09:28
jnthn o.O 09:33
nine LOL 09:57
Why is this an endless recursion? Because the full invocation was:
perl6 -e 'sub bar() { $*FOO = 'bar'; }; sub foo() { my $*FOO = CALLERS::<$*FOO>; bar; }; foo'
So the shell makes "sub bar() { $*FOO = bar; }" out of that 09:58
jnthn lol!
nine Maybe it's time for me to finally move my one linering to the REPL... 09:59
Zoffix Or use ’‘ instead of '' :) 10:01
jnthn One less bug for me to investigate, anyway :) 10:02
Talking of which...
Zoffix japhb, no, I've not figured out a good way to do testing other than firing up Perl 5's IRC server module (see the dismal test suite of IRC::Client). For SSL: I know nothing about it and too busy with other stuff to jump in and learn. Also, I think I recall someone's attempt to make SSL version of IO::Socket::Async was ridiculously slow 10:04
lol, someone posted my junctions post into /r/compsci and the comments make no sense to me :) www.reddit.com/r/compsci/comments/...junctions/ 10:06
At least there's no hate :D
dalek ast: 7e3eed5 | jnthn++ | S32-io/socket-accept-and-working-threads.t:
Add test for sync socket + working threads bug.
jnthn That's a test covering the [Coke]++ bug report 10:07
dalek p: 65e7981 | jnthn++ | tools/build/MOAR_REVISION:
Bump MOAR_REVISION for socket accept fix.
 10:09
kudo/nom: 26fabdf | jnthn++ | tools/build/NQP_REVISION:
Bump NQP_REVISION for Moar socket accept fix.
 10:17
kudo/nom: c082855 | jnthn++ | t/spectest.data:
Add test covering socket accept + threads bug.
kudo/async-socket-str-fixes: 1beae10 | jnthn++ | src/core/IO/Socket/Async.pm:
First steps on fixing string async socket reads.

This uses the new VM-backed streaming decode API, which will allow for much better error handling, choosing the encoding, and in the future provide support for userspace decoders to be plugged in. This nearly works, with a caveat: we run into a phaser scoping bug with the LAST block that will need some attention. (Also, the streaming decode stuff is not yet available for the JVM backend.)		 10:27
rakudo/async-socket-str-fixes: 494c25f | jnthn++ | src/core/IO/Socket/Async.pm:
rakudo/async-socket-str-fixes: Cope with empty socket reads.
rakudo/async-socket-str-fixes:
rakudo/async-socket-str-fixes: There's a problem with LAST/QUIT phasers in the case that an iteration
jnthn (Just a rebase) 10:28
So, nobody took the JVM decode stream bait... :) 10:30
nine So much to do...so little time :/ 10:33
jnthn Well, I have time today, so will do the amount of it I need :) 10:36
(Which is the amount needed to not have to put #?if jvm thingies into IO::Socket::Async to fix its issues :))
TheLemonMan moinmoin 10:49
jnthn o/ :) 10:50
TheLemonMan Zoffix, gotta try again running the spectest then
Zoffix TheLemonMan, what OS are you on? 10:51
I recall there was one test (now fudged) that was passing for me, but failing on OSX 10:52
TheLemonMan Linux; but it's the first time I see this test fail :\
Zoffix w00t Canuck gov is offering $93mil for deep learning research. www.cfref-apogee.gc.ca/results-resu...ng.aspx#a6 10:53
Zoffix quits job. Starts cracking 10:54
timotimo good luck!
DrForr I'd love to get p6 into that space, but too many projects :)
TheLemonMan and while rakudo builds... does anybody have any idea for #865? I'm more and more convinced that throwing an exception is the best way to handle the possible error case 10:59
dalek p: 55b0dac | jnthn++ | src/vm/jvm/runtime/org/perl6/nqp/sixmodel/ (3 files):
Stub in Decoder REPR on JVM.
 11:09
p: 5bdc324 | jnthn++ | src/vm/jvm/QAST/Compiler.nqp:
Map decoder ops for JVM (none implemented yet).
nine
.oO(I'd love to get Perl 6 into Space)
 11:10
DrForr www.sciencealert.com/the-impossible...d-in-space 11:13
jnthn lunch & 11:16
TheLemonMan uhh, now some more tests are failing, even with nom 11:31
and if I unset PERL6_TEST_DIE_ON_FAIL then some test silently die and fudgeandrun finishes saying 'All tests successful.' 11:34
timotimo hmm, does DIE_ON_FAIL handle #TODO properly? 11:35
TheLemonMan Zoffix, ^ 11:36
timotimo it should 11:37
i mean how else would it ever have succeeded in a spec test?
ha 11:39
i was running a moar with --optimize=0
ZoffixMobile TheLemonMan, what does t/rakudo/ something something die-on-fail test give you? does it pass? can you pastebin full output?
timotimo no wonder startup was slow
ZoffixMobile full output of fudgerun that is 11:42
that's failing
oh wait, that's not where the die on fail test is, I think it's in spec.... tree -f | grep testing 11:43
TheLemonMan ZoffixMobile, w/o DIE_ON_FAIL ptpb.pw/nZ9J W/ DIE_ON_FAIL ptpb.pw/9hZw
ZoffixMobile k, I'll take a look in about 10m when I'm at a proper computer 11:45
moritz ok, travis confuses the heck out of me 12:04
yesterday night I tried to fix this problem: Type check failed in binding to $id; expected CompUnit::PrecompilationId but got Str ("4CDC84469EF12631D41D...) 12:05
uncovered by travis
by the perl6/doc builds
and after I pushed my commit, there have been quite a few successful builds
and now travis-ci.org/perl6/doc/builds/158127574 again (from 2 hours ago) 12:06
which shows the same problem as before my fix
MetaZoffix Hmm 12:20
TheLemonMan: PERL6_TEST_DIE_ON_FAIL bails out when a test fails inside a todo'ed subtest 12:21
MetaZoffix is testing a fix 12:23
And it's not silently failing without the env var set. It's failing inside the subtest and the subtest counts as one test in the parent test suite, so if it's TODOed, the entire subtest will count as "passing", regardless of how many failures are in it 12:31
nine I see there's a rakudobrew involved 12:35
dalek p: 0dd01d8 | jnthn++ | src/vm/jvm/runtime/org/perl6/nqp/runtime/Ops.java:
Factor out encoding name mangling.
 12:37
p: a3deb79 | jnthn++ | src/vm/jvm/runtime/org/perl6/nqp/ (2 files):
Implement decoderconfigure op for JVM.
kudo/nom: ffb5789 | (Zoffix Znet)++ | lib/Test.pm6:
Do not PERL6_TEST_DIE_ON_FAIL inside subtests as they may be TODOed

Spotted by TheLemonMan++		 12:39
ast: b0c5ee2 | (Zoffix Znet)++ | S24-testing/8-die_on_fail.t:
PERL6_TEST_DIE_ON_FAIL does not exit in subtests that may be TODOed
ast: 1bf7e2c | (Zoffix Znet)++ | S24-testing/8-die_on_fail.t:
Explicitly set PERL6_TEST_DIE_ON_FAIL=0 when test expects it to be that
 12:40
MetaZoffix TheLemonMan: ^ that should do it
nine moritz: I can actually reproduce that failure locally
moritz: it's not a call to .precompile but to .load 12:41
moritz nine: oh
nine: is the fix needed in both places, or just in .load? 12:42
nine in both 12:43
testing now
dalek ast: d6bcadc | (Zoffix Znet)++ | S24-testing/8-die_on_fail.t:
Simplify switch for PERL6_TEST_DIE_ON_FAIL in its tests
 12:47
kudo/nom: f0bb581 | niner++ | src/core/CompUnit/PrecompilationRepository.pm:
Provide a backwards compatible load method in PrecompilationRepository

Fixes pod2onepage which still passes Str ids.		 12:48
p: 2e71d57 | jnthn++ | src/core/NativeTypes.nqp:
Provide sized int types to NQP on JVM.

I suspect this needed a rebootstrap at the time they were put in. That apparently has happened, and they work fine, so remove the
  `#?if moar` markers.		 12:52
p: dace35f | jnthn++ | src/vm/jvm/runtime/org/perl6/nqp/runtime/Buffers.java:
Support encoding into unsinged buffers.
 12:53
TheLemonMan ehh, the repl.t test is still failing, but only when run trough the spectest 14:37
dalek p: d6078f1 | jnthn++ | src/vm/jvm/runtime/org/perl6/nqp/ (2 files):
Implement basic streaming decode ops.

So far as we need them for using them in async sockets in Rakudo. This will need further changes upon NFG being implemented for the JVM backend, but it at least is factored somewhat in a direction that will make that a bit easier.		 14:39
jnthn That wasn't fun :P 14:42
timotimo also at fault for not taking the bait
jnthn :P
Well, now I've got it started, maybe making the rest of the tests pass will be a little more of a fun task :) 14:43
I don't need the rest for now, though :) 14:46
dalek p: 2886979 | jnthn++ | t/jvm/05-decoder.t:
Add decoder tests for JVM backend.

Commented out those that are not yet implemented. Takers welcome.		 14:47
MetaZoffix TheLemonMan: got any output to share? Which test is failing? 14:51
dalek ast: 5390fc7 | jnthn++ | S32-io/IO-Socket-Async.t:
Send \n and end of chars echo server message.

The \n serves as a normalization terminator - that is, it means we know that even if a combining char comes next, it will end up as an isolate rather than forming a grapheme with the \n. A `z` could be followed by a combiner in the next packet, so after upcoming fixes to async socket decoding we'll now not hand such a character on until the next packet arrives and we see there is no combiner. This would break the test, which did not account for such NFG behavior.		 14:52
ast/6.c-errata: fd46151 | jnthn++ | S32-io/IO-Socket-Async.t:
Send \n and end of chars echo server message.

The \n serves as a normalization terminator - that is, it means we know that even if a combining char comes next, it will end up as an isolate rather than forming a grapheme with the \n. A `z` could be followed by a combiner in the next packet, so after upcoming fixes to async socket decoding we'll now not hand such a character on until the next packet arrives and we see there is no combiner. This would break the test, which did not account for such NFG behavior.		 14:53
MetaZoffix TheLemonMan: also, are you running with or without die-on-fail? (and if with... do you have my fix merged into your branch?) 14:57
[Coke] Zoffix: you see my note on the missing ops docs? 15:04
MetaZoffix [Coke]: I guess. The one about there being a test, right.
[Coke] yup. doesn't help write the docs, but at least finds the ones missing... 15:05
.ask pmurias - hey do we need to update nqp's t/docs/opcodes.t to start looking at the JS backend? 15:06
yoleaux2 [Coke]: I'll pass your message to pmurias.
travis-ci Rakudo build failed. Zoffix Znet 'Do not PERL6_TEST_DIE_ON_FAIL inside subtests as they may be TODOed
travis-ci.org/rakudo/rakudo/builds/158162393 github.com/rakudo/rakudo/compare/c...b5789f7eef
buggable [travis build above] ☠ Did not recognize some failures. Check results manually
MetaZoffix :o
japhb nine: Is it expected that after yesterday's performance improvements, a from-scratch reinstall of Rakudo + modules would take *two* runs of a test program to "warm up" to full speed? Before my rebuild, my test script was running consistently in .509s to .512s; after the rebuild, the first run was 1.860s, the second was .518s, and then the third and following were .343s to .360s. 15:07
MetaZoffix just an undettected git error
japhb nine: (And thanks for that speed boost, BTW!) 15:08
jdv79 that sounds like some nice perf gains
MetaZoffix travis-ci.org/rakudo/rakudo/builds/158162393 15:11
buggable [travis build above] ✓ All failures are due to timeout (0), missing build log (0), or GitHub connectivity (1)
japhb jdv79: Yeah, he managed to get ~2 orders of magnitude speedup in loading GTK::Simple (which is effectively a stress test for module loading). But that speedup shows up even in much less heavy tests like mine. 15:12
TheLemonMan MetaZoffix, each run I get different errors in different tests :D 15:13
DrForr I had a serious issue with loading a bunch of tiny classes, ~200.
TheLemonMan some are failing with 'P6M Merging GLOBAL symbols failed: duplicate definition of symbol Test' 15:15
MetaZoffix Are you sure you branch has all the latest and greatest rakudo nom commits?
TheLemonMan absolutely, let me retry once again 15:16
dalek kudo/async-socket-str-fixes: 4015d5e | jnthn++ | tools/build/NQP_REVISION:
Bump NQP_REVISION for JVM decoder REPR/ops.
 15:18
nine japhb: the first run after installing a module is always a bit slower as it re-checks dependencies (installation changes the repo which triggers a re-check). But that wouldn't explain those numbers you got 15:19
MetaZoffix m: my ($m, $h); given DateTime.now { $h = .hour; $h -= 12 if $h >= 12; $m = .minute; $m = $m > 15 && $m >= 45 ?? 12 !! 0; }; <🕐🕑🕒🕓🕔🕕🕖🕗🕘🕙🕚🕛🕜🕝🕞🕟🕠🕡🕢🕣🕤🕥🕦🕧>.comb[$h+$m].say 15:20
camelia rakudo-moar f0bb58: OUTPUT«🕕␤»
MetaZoffix wooo, Unicode clock. That may or may not work right for any other times :)
m: DateTime.now.say
camelia rakudo-moar f0bb58: OUTPUT«2016-09-07T17:20:38.933590+02:00␤»
MetaZoffix hm
never mind :}
[Coke] not ok 1390 - documented op 'ln_n' exists in moar 15:22
looks like we maybe removed that op from nqp entirely?
dalek p: de3c2d0 | coke++ | t/docs/opcodes.t:
Find more opcodes
jnthn Time for a break, but expect I'll merge that async socket fix branch later today. It works on JVM and Moar, just need to write some more tests to ensure it fixes all I want it to :)
dalek p: 61a5556 | coke++ | docs/ops.markdown:
fix formatting typo
 15:24
[Coke] jnthn: does that address part of my issue? (and will bailador or HTTP::Easy need to change to take advantage?)
timotimo [Coke]: the hang when accepting a socket already landed earlier and it should have gotten you further 15:28
have you tried that yet?
dalek p: a4d93fd | coke++ | docs/ops.markdown:
Relocate substr2/3

These are JVM specific internal opcodes; we need to mark them as `JVM` to avoid documentation test failures.		 15:29
[Coke] timotimo: on nom? nope, just got out of morning meetings, must have missed that. 15:30
will check early afternoon. Thanks.
timotimo the one you said "looks promising"
it was a fix in moarvm
[Coke] oh, on moar. roger.
dalek p: c986221 | coke++ | t/docs/opcodes.t:
find more opcodes
 15:33
p: 501efa6 | coke++ | docs/ops.markdown:
note jvm-specific opcode
 15:34
[Coke] t/docs/opcodes.t down to 277 failures (some of them are that the search for opcodes hasn't been kept up to date, others are things that are vm specific, others are opcodes that have been removed). (plus also just missing docs) 15:37
^^ in nqp
dalek p: b50642b | coke++ | t/docs/opcodes.t:
add initial support for js ops
 15:41
[Coke] ... and back up to 456 failures, but now we're also carping about the js backend.
dalek p: a112f96 | coke++ | t/docs/opcodes.t:
find more js ops
 15:44
TheLemonMan so, I nuked everything and started with a fresh build, repl.rakudo.moar keeps failing (along with socket-accept-and-working-thread) when run from the spectest. If I run the file by hand it fails with 'P6M Merging GLOBAL symbols failed: duplicate definition of symbol Test' 15:46
nine TheLemonMan: have you tried running with RAKUDO_MODULE_DEBUG=1? 15:50
TheLemonMan: might give you a hint
TheLemonMan what the fuck, now repl.t doesn't fail anymore 16:02
nine, ptpb.pw/76jZ 16:09
jnthn [Coke]: Was a fix in Moar; I already bumped revisions and added a spectest :) 16:19
MetaZoffix TheLemonMan: stupid question, but did you build and make install that rakudo build? It's really weird that it's using your, what I assume system perl6's Test.pm6, rather than the one in the build 16:26
Hm, was gonna see what I get, but I can't build rakudo at all 16:27
"Too few positionals passed; expected 2 or 3 arguments but got 1 at gen/moar/stage2/NQPHLL.nqp:615"
never mind. Nuking my build dir and building from scratch doesn't have any issues 16:34
TheLemonMan I'm running out of ideas 16:35
nine TheLemonMan: your prefix is ~/.local? 16:40
TheLemonMan nine, yep
MetaZoffix Here's my output, FWIW... That's from nom: gist.github.com/zoffixznet/f5d39af...a8f401902f 16:41
travis-ci Rakudo build errored. Stefan Seifert 'Provide a backwards compatible load method in PrecompilationRepository 16:44
travis-ci.org/rakudo/rakudo/builds/158164378 github.com/rakudo/rakudo/compare/f...bb581ffbd9
buggable [travis build above] ✓ All failures are due to timeout (1), missing build log (0), or GitHub connectivity (0)
MetaZoffix God people are idiots... Right now I'm getting shit for my work just because some customer is too stupid to figure out that a text field on the website is pre-filled for convenience and they CAN EDIT IT!! grrr 16:46
nine TheLemonMan: what system are you on?
TheLemonMan nine, a pretty boring x64 linux box 16:47
nine Very strange. It properly detects that the precompiled Test::Util is outdated, precompiles it again but then seems to load the old file. 16:50
That could be a caching issue!
TheLemonMan: can you confirm that rakudo commit f0df49669652359e2766366be940efb76be54db4 still works? 16:51
TheLemonMan: and could you bisect it in that case? May just be one of my optimizations
jdv79 nine: impressive work 16:52
nine commit 5fee7a1225118f6a4a7a8a3316dfe8d44dd903c0 looks like a likely candidate 16:53
TheLemonMan: you may as well try reverting 5fee7a1225118f6a4a7a8a3316dfe8d44dd903c0 16:54
Possible fix is then adding the following after src/core/CompUnit/PrecompilationStore/File.pm:177 16:56
%!loaded{$precomp-id} //= $unit;
Have to leave now 16:57
timotimo see ya nine
really glad about all those improvements
TheLemonMan nine, (sorry for the delay but recompilations on this box take ~2m :( ) the fix your proposed seems to work 17:21
dalek ast: 92951b3 | (Zoffix Znet)++ | S17-supply/interval.t:
Unfudge now-passing test

RT#128469		 17:39
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128469
TheLemonMan ffs, repl.t is still failing heh 17:54
MetaZoffix TheLemonMan: did you say you're running it on a slow box?
TheLemonMan: which tests fail? 17:55
TheLemonMan MetaZoffix, it's not that slow, it just...takes its time
MetaZoffix, I get a green when run with prove, and an error when run with spectest 17:56
MetaZoffix Try passing :5wait to all of the doesn't-hang calls. The default wait is 1.5s which may be not enough for it to complete the test normally
TheLemonMan: well, the spectest tells you which tests fail at the end. Which ones? It gives numbers 17:57
TheLemonMan MetaZoffix, 'no subtests run' is all it says 17:58
and if I 'rm t/spec/S19-command-line/repl.rakudo.moar' and run the spectest again...it succeeds!
MetaZoffix :S
lizmat waves from Munich 18:00
yoleaux2 09:22Z <jnthn> lizmat: -e '' spends a lot of time in parse not for parsing, but because that's where we load CORE.setting, so it's a decent measure of that...not really inclined to special-case it... :)
MetaZoffix waves from the opposite side of the planet.
lizmat MetaZoffix o/ 18:01
MetaZoffix TheLemonMan: and that's with LemonBoy:iterable-item-containerization branch right? 18:04
TheLemonMan MetaZoffix, nope, with vanilla nom 18:05
MetaZoffix :o
lizmat afk again, back later tonight&
MetaZoffix TheLemonMan: well, try to figure out which test is failing and then fudge it, I guess :) 18:10
I'm running it in a loop right now while 2 spectests are running at the same time, and no failures :/
nine TheLemonMan: so I'm confused. Did my patch actually help or not? 18:12
MetaZoffix "green when run with prove" .... You can run individual tests with make t/spec/S19-command-line/repl.t that'll auto-fudge them for you 18:13
TheLemonMan I honestly don't know anymore, getting new different failures each try 18:20
MetaZoffix Just in repl.t or in other tests too? 18:28
t/spec/S32-io/socket-accept-and-working-threads.t is failing on my box with "Connection refused" 18:44
TheLemonMan now repl is failing test 8, and interval.t is failing test 5-7 18:50
MetaZoffix my repl.t was running in a loop all of this time and hasn't failed once 18:51
8th is the doesn' 18:52
8th is the doesn't-hang test
And so is the 5-7 18:53
t/spec/S32-io/socket-accept-and-working-threads.t fails only on my server that probably has very restrictive firewall. Test works fine on my dev box 18:56
dalek ast: b0b4e14 | (Zoffix Znet)++ | / (2 files):
Add ROAST_TIMING_SCALE env var

This will control time-sentitive test scaling. Currently, this affects the scaling of how long doesn't-hang() test will wait before assuming the process hung		 19:00
MetaZoffix TheLemonMan: ^ try setting ROAST_TIMING_SCALE=2 or something larger.
Oh god, I'm div... Testing the changes first would help, no? :) 19:05
huh 19:06
m: say $*ENV<ROAST_TIMING_SCALE>//1
camelia rakudo-moar f0bb58: OUTPUT«1␤»
MetaZoffix could argue this should warn
dalek ast: ad3ea69 | (Zoffix Znet)++ | packages/Test/Util.pm:
Fix incorrect variable name
 19:07
TheLemonMan MetaZoffix, sorry for the delay, I was having something to eat in the meanwhile 19:09
indeed most of the failures were due to a timeout heh
MetaZoffix And to clarify my "should warn" comment. I meant the $ Perl5-ism for %*ENV; not the // on dynamic var 19:13
TheLemonMan m: say $*ENV; say $*ENV // 1; 19:15
camelia rakudo-moar f0bb58: OUTPUT«Dynamic variable $*ENV not found␤ in block <unit> at <tmp> line 1␤␤Actually thrown at:␤ in block <unit> at <tmp> line 1␤␤»
TheLemonMan looks like a bug 19:16
MetaZoffix nope
m: my $*ENV = 42; say $*ENV // 1;
camelia rakudo-moar f0bb58: OUTPUT«42␤»
MetaZoffix m: dd %*ENV
camelia rakudo-moar f0bb58: OUTPUT«Hash %ENV = {:HOME("/home/camelia"), :LANG("POSIX"), :LC_CTYPE("en_US.UTF-8"), :LOGNAME("camelia"), :MANPATH("/home/camelia/perl5/perlbrew/perls/perl-5.20.1/man:"), :ME("MetaZoffix"), :PATH("/home/camelia/perl5/perlbrew/bin:/home/camelia/perl5/perlbrew/per…»
MetaZoffix $*ENV is a dynamic variable has has no relation to %*ENV dynamic variable that has the env vars 19:17
And in perl 5 it's $ENV ... And personally I frequently mess up the sigil :)
TheLemonMan the $*ENV should just throw when the lhs of // is evaluated imo
MetaZoffix But then you make it mandatory
TheLemonMan maybe only for known dynamic variables... 19:18
MetaZoffix maybe 19:19
TheLemonMan m: use nqp; nqp::say("ü" ~~ /:m u/) 20:44
camelia rakudo-moar f0bb58: OUTPUT«This type cannot unbox to a native string: P6opaque, Match␤ in block <unit> at <tmp> line 1␤␤»
arnsholt m: use nqp; nqp::say(~("ü" ~~ /:m u/)) # Here you go 20:49
camelia rakudo-moar f0bb58: OUTPUT«ü␤»
TheLemonMan m: use nqp; nqp::say(~("ü" ~~ /:!m u/)) 20:50
camelia rakudo-moar f0bb58: OUTPUT«Use of Nil in string context␤ in block <unit> at <tmp> line 1␤␤»
TheLemonMan eh, take a look at the nqp level and you'll see that a NQPMatch $!to is set to -3, making the Str method fail 20:51
jnthn Hm, didn't we harden NQPMatch.Str against that at some point? Mebbe not... 21:08
jnthn got a nasty headache, so more tests for the async socket fixes and merging that will have to wait until tomorrow. 21:09
NeuralAnomaly: When is the release?
Aww :)
geekosaur NeuralAnomaly, stats 21:10
NeuralAnomaly geekosaur, [✘] Next release will be in 1 week and 2 days. Since last release, there are 40 new still-open tickets (4 unreviewed and 0 blockers) and 15 unreviewed commits. See perl6.fail/release/stats for details
jnthn Nice :)
Plenty of time :) 21:11
MasterDuke i was just going to ask you about my infix<x> PR, but don't want to exacerbate the headache 21:13
feel free to punt
jnthn Yeah, not sure I'll have too many sensible answers 21:14
TPF are looking for feedback on funding me to continue doing Perl 6 stuffs. Comments can be left at news.perlfoundation.org/2016/09/per...abi-2.html 21:42
uh, "continuing to fund me doing Perl 6 stuffs" woulda been a better phrasing :)
Zoffix wonders if a lot of people would be upset if the names list on the credits on release announcement would be in alphabetical order rather by number of commits. 21:43
jnthn Though I'd have an amount less time for it without funding, so I guess both kinda work :P
Zoffix: Dunno. Depends how much folks are motivated by gamifying how many commits they make I guess. :) 21:45
dalek ast: 456bb43 | lizmat++ | S32-io/socket-accept-and-working-threads.t:
:host<localhost> doesn't work on OS X ?

  :host<127.0.0.1> does. Assuming 127.0.0.1 works everywhere, this
seems like a good fix. Should this only work this way on OS X, then we need to make the :host specification conditional on the OS
Zoffix That's a good point. Better leave it as is then
jnthn lizmat: hm, curious...but 127.0.0.1 seems safer generally 21:46
lizmat all tests failed, output was "Failed to connect: connection refused" 21:47
jnthn o.O
odd
Zoffix Ohhh.. lizmat++ that fixed the test on my debian server too
lizmat Zoffix: I could very well live with an alphabetical order of contributors
Zoffix I was getting the same failed to connect: connection refused, but I assumed it was just my restrictive firewall
jnthn Odd, worked fine on my Ubuntu 21:48
Zoffix (it worked fine on my debian dev box :))
¯\_(ツ)_/¯
jnthn Confirm it still works in my Ubuntu VM
So, all's good I guess :) 21:49
lizmat jnthn: it fails on nqp::connect($PIO, nqp::unbox_s($.host), nqp::unbox_i($.port));
so in the bowels of nqp / Moar
jnthn oh, duh
lizmat I wonder where the resolution of localhost is done?
jnthn Notice in the listen it doesn't mention localhst 21:50
lizmat ah....
jnthn Though that's maybe worth a Perl 6 docs ticket
Because I stole the basic listen/connect example from there :) 21:51
'cus I was too lazy to type them out :)
Zoffix :o
lizmat so how would one specify that with listen ?
Zoffix we discovered jnthn's secret :)
lizmat listen<localhost> ?
or an additional :host<localhost>
neither of them seem to fix the pb, fwiw
Zoffix ditto here 21:52
Ah. :localhost<> 21:53
timotimo how well do we do with regards to ipv6 btw? 21:54
jnthn Doc issue at github.com/perl6/doc/issues/898 anyways 21:55
And lizmat++ for the test fix
TheLemonMan does travis also run the spectest ? 22:00
Zoffix Well, I left the comment. It said "held for moderator" news.perlfoundation.org/2016/09/per...abi-2.html
TheLemonMan, nope
jnthn Zoffix: Yeah...they moderate 'em in a day or so :) 22:01
Zoffix \o/
(it was a "definitely extend...." type of comment FWIW :))
jnthn phew :)
dalek kudo/nom: 377d236 | LemonBoy++ | src/Perl6/Grammar.nqp:
Name the <sym> token when parsing a ternary operator.

Some functions such as 'can_meta' might need this information to print more informative error messages.
RT#129080		 22:02
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=129080
kudo/nom: c98ab93 | (Zoffix Znet)++ | src/Perl6/Grammar.nqp:
Merge pull request #872 from LemonBoy/ternary-sym

Name the <sym> token when parsing a ternary operator.
jnthn Cute fix :) 22:03
TheLemonMan on the flip side I'm running out of interesting bugs to fix heh 22:04
jnthn Bugs turn out to be a renewable resource... :) 22:06
Zoffix is attempting 128304 22:07
RT#128304
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128304
dalek kudo/nom: a62207e | lizmat++ | src/core/REPL.pm:
We don't need no 'use nqp' in the setting :-)
 22:08
jnthn Zoffix: hmmm :)
Zoffix What? :)
jnthn Just wondering if there's a nice way to fix it vs. just adding rules for all the quoters :) 22:09
Rest time; 'night 22:10
Zoffix night
MasterDuke TheLemonMan: #128594 and #129197 are very very interesting 22:12
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128594
Link: rt.perl.org/rt3//Public/Bug/Displa...?id=129197
Zoffix MasterDuke++ :) Yes they are 22:13
japhb .tell jnthn I sent a comment of support for your continued funding as well (pretty much of the "you'd be crazy not to" variety) 22:28
yoleaux2 japhb: I'll pass your message to jnthn.
Zoffix m: say "<>[]()\{}\x[0028]\x[0029]\x[003C]\x[003E]\x[005B]\x[005D]\x[007B]\x[007D]\x[00AB]\x[00BB]\x[0F3A]\x[0F3B]\x[0F3C]\x[0F3D]\x[169B]\x[169C]\x[2018]\x[2019]\x[201A]\x[2019]\x[201B]\x[2019]\x[201C]\x[201D]\x[201E]\x[201D]\x[201F]\x[201D]\x[2039]\x[203A]\x[2045]\x[2046]\x[207D]\x[207E]\x[208D]\x[208E]\x[2208]\x[220B]\x[2209]\x[220C]\x[220A]\x[220D]\x[2215]\x[29F5]\x[223C]\x[223D]\x[2243]\x[22CD]\x[2252]\x[2253]\x[2254]\x[2255]\x[2264]\x[2265]\x[ 22:39
2266]\x[2267]\x[2268]\x[2269]\x[226A]\x[226B]\x[226E]\x[226F]\x[2270]\x[2271]\x[2272]\x[2273]\x[2274]\x[2275]\x[2276]\x[2277]\x[2278]\x[2279]\x[227A]\x[227B]\x[227C]\x[227D]\x[227E]\x[227F]\x[2280]\x[2281]\x[2282]\x[2283]\x[2284]\x[2285]\x[2286]\x[2287]\x[2288]\x[2289]\x[228A]\x[228B]\x[228F]\x[2290]\x[2291]\x[2292]\x[2298]\x[29B8]\x[22A2]\x[22A3]\x[22A6]\x[2ADE]\x[22A8]\x[2AE4]\x[22A9]\x[2AE3]\x[22AB]\x[2AE5]\x[22B0]\x[22B1]\x[22B2]\x[22B3]\x[22B4
camelia rakudo-moar a62207: OUTPUT«===SORRY!===␤Unrecognized backslash sequence: '\x'␤at <tmp>:1␤------> 2253]\x[2254]\x[2255]\x[2264]\x[2265]\x[⏏<EOL>␤Unable to parse expression in double quotes; couldn't find final '"' ␤at <tmp>:1␤------> 2253]\x[2254]\x[225…»
Zoffix ]\x[22B5]\x[22B6]\x[22B7]\x[22C9]\x[22CA]\x[22CB]\x[22CC]\x[22D0]\x[22D1]\x[22D6]\x[22D7]\x[22D8]\x[22D9]\x[22DA]\x[22DB]\x[22DC]\x[22DD]\x[22DE]\x[22DF]\x[22E0]\x[22E1]\x[22E2]\x[22E3]\x[22E4]\x[22E5]\x[22E6]\x[22E7]\x[22E8]\x[22E9]\x[22EA]\x[22EB]\x[22EC]\x[22ED]\x[22F0]\x[22F1]\x[22F2]\x[22FA]\x[22F3]\x[22FB]\x[22F4]\x[22FC]\x[22F6]\x[22FD]\x[22F7]\x[22FE]\x[2308]\x[2309]\x[230A]\x[230B]\x[2329]\x[232A]\x[23B4]\x[23B5]\x[2768]\x[2769]\x[276A]\x[
276B]\x[276C]\x[276D]\x[276E]\x[276F]\x[2770]\x[2771]\x[2772]\x[2773]\x[2774]\x[2775]\x[27C3]\x[27C4]\x[27C5]\x[27C6]\x[27D5]\x[27D6]\x[27DD]\x[27DE]\x[27E2]\x[27E3]\x[27E4]\x[27E5]\x[27E6]\x[27E7]\x[27E8]\x[27E9]\x[27EA]\x[27EB]\x[2983]\x[2984]\x[2985]\x[2986]\x[2987]\x[2988]\x[2989]\x[298A]\x[298B]\x[298C]\x[298D]\x[298E]\x[298F]\x[2990]\x[2991]\x[2992]\x[2993]\x[2994]\x[2995]\x[2996]\x[2997]\x[2998]\x[29C0]\x[29C1]\x[29C4]\x[29C5]\x[29CF]\x[29D0
timotimo wow
are those our "matching braces"? 22:40
Zoffix :) lol, sorry. Underestimated the size of that string
hm. 22:41
m: say q{„”} eq q{„”} 22:42
camelia rakudo-moar a62207: OUTPUT«True␤»
Zoffix mkay, then I don't know why 128304 is present at all. Seems the logic for it is already in there
timotimo, yeah, that was the matching brackets string 22:43
AlexDaniel Zoffix: fwiw, see #126557 22:46
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=126557
AlexDaniel Zoffix: perhaps the fix is going to be similar
lizmat night #perl6-dev! 23:16
dalek ast: fb22ba6 | MasterDuke17++ | S03-operators/repeat.t:
Tests for infix<xx> with -Inf and ±NaN

Final set of tests for RT #125628		 23:36
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=125628
AlexDaniel m: say -NaN 23:39
camelia rakudo-moar a62207: OUTPUT«NaN␤»
AlexDaniel MasterDuke: -NaN? Is it a thing?
MasterDuke figured it couldn't hurt 23:40
AlexDaniel heh 23:41
marked as resolved
MasterDuke there are two other tests with -NaN, so it might have been overkill

Powered by Cro and the Raku® Programming Language.

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

Thank you!