AlexDaniel heh… 00:01
Zoffix Well, I was planning to use last night's NQP fix to parse Rakudo's nums... to see if it's faster. I guess I'm going to be doing that sooner than I thought 00:02
Hehe, I feel slightly better that offending commit doesn't have *just* my name on it :P 00:05
:o the fix worked the first time 00:14
ZOFFLOP: t/08-performance/02-qast-rewrites.t 00:23
weird that THAT would flop :S
Ah, it was a segv ok
AlexDaniel like if that's much better :D 00:26
Zoffix :)
AlexDaniel anyway, see you tomorrow
Zoffix \o 00:28
holy shit 00:29
that was caused by `nqp: say(04864.357230107115212e249)` aPPARENTly
m: say(4.864357230107115468e+252 == 04864.357230107115212e249) 00:50
camelia False
Zoffix turns out this type of precision bug hasn't been rooted out in rakudo
j: say 4.864357230107115468e+252 == 04864.357230107115212e249 00:51
camelia True
Zoffix .... ow it's in nqp::div_I :'(
ugggh 02:45
I'm stuck
pmurias, are you around? How are you doing nqp::div_In bigint division on JS? Are you doing some rounding stuff? I'm doing bigints, but still hitting pockets where not the closest representable num gets produced 03:07
.oO( I guess I can just look myself )
I see 03:11
god strtod's sauce is huge. 03:32
k Plan B: sweep the problem under the rug and take care of it as part of CaR Grant. 03:33
"the problem" == degeneration of Rat to Num doesn't choose closest representable num
m: use nqp; nqp::stringify('22e0') 03:36
camelia ===SORRY!===
No registered operation handler for 'stringify'
Zoffix dammit
`src/vm/moar/NQP/Ops.nqp:95:$ops.add_hll_op('nqp', 'stringify', -> $qastcomp, $op {`
Any way to get to it from HLL land?
I don't know what I'm doing 03:38
ZofBot: haaaallp 03:39
$ ./perl6 -e 'say 1e100000000000' 05:54
P6opaque: get_boxed_ref could not unbox for the representation 'P6bigint' of type Num
gaddamit 05:55
j: say 1e100000000000 05:56
camelia 1
Zoffix hahaha. We'll, I'll take a crash over that :P
c: 2018.03 say 1e100000000000
committable6 Zoffix, ¦2018.03: «Inf␤»
Zoffix c: 2018.03 say 1e1000000000000000000000000000000000000000000000000000 05:57
committable6 Zoffix, ¦2018.03: «Inf␤»
Zoffix nqp: say(1e1000000000000000000000000000000000000000000000000000)
camelia Inf
Zoffix Got all the right bits to fix the parsing perf loss: 06:37
Just need to use that nqp::p6stringifyasnqp inside &val's num parser.
And we'll then still have the issue with Rat->Num degration not choosing closest num, but that can easily be left for the RaT grant and I don't believe there are any committed tests that cover it 06:38
Geth roast/car-grant-num-precision-tests: b99720b985 | (Zoffix Znet)++ | S02-types/num.t
[CaR Grant] Test Num/Rat->Num picks closest representable num
Zoffix Those ones; particularly the last one in that group. And I'll have more to add too, but that's not the concern of the current release. 06:40
Dropping to bed now and then need to work from morning to afternoon, so gonna be unavailable for the next ~15 hours, but if anyone wants to apply that fix in that diff then the release could go on. The &val changes needed is basically grab or construct a num to parse as a string and give it to nqp::p6stringifyasnqp op and that'll stringify it right 06:42
Zoffix drops to bed
.tell AlexDaniel`
yoleaux Zoffix: I'll pass your message to AlexDaniel`.
Zoffix Forgot to say: no idea what the situation on JVM is; would need to #ifjvm or something around that op or implement it (JVM probably can stringify the nums just fine) 06:46
Or we could just leave it all as is and go with original plan of point-releasing fudged tests only and send a p6lert that in this release nums with hugely-huge powers are super slow to parse 06:47
Oh, and I just realized I totally mis-named that op. It should be something like, nqp::smartnumify instead of stringifying >_< 06:50
Kaiepi aight got spectest to stop making the bot disconnect now i think 06:56
BeastieBot, stresstest
BeastieBot [freebsd] Running Roast's stress test suite (this will take a while)...
[freebsd] Failed Roast stress test suite... See the output at
Kaiepi lol
BeastieBot, all 07:00
BeastieBot [freebsd] Running complete Rakudo build and tests (this will take a while)...
Kaiepi i swear i'll get this to finish running
lizmat Files=1239, Tests=76292, 318 wallclock secs (15.87 usr 5.62 sys + 2190.61 cusr 219.84 csys = 2431.94 CPU) 07:34
BeastieBot [freebsd] Failed to build Rakudo and run all tests... See the output at 07:35
Kaiepi finally, rakudo bot's in working order 07:39
AlexDaniel` . 07:43
yoleaux 06:42Z <Zoffix> AlexDaniel`:
AlexDaniel` "super slow to parse" sounds a bit misleading I think 08:00
c: 2018.03,2018.04 my $x = "1e10000000"; say +$x 08:01
committable6 AlexDaniel`, ¦2018.03: «Inf␤» ¦2018.04: ««timed out after 10 seconds» «exit signal = SIGHUP (1)»»
[Tux] Rakudo version 2018.04-21-g24a907747 - MoarVM version 2018.04-34-g25f165ad7
csv-ip5xs0.904 - 0.944
csv-ip5xs-209.040 - 9.134
csv-parser38.099 - 38.348
csv-test-xs-200.452 - 0.462
test9.501 - 9.609
test-t2.546 - 2.546
test-t --race1.037 - 1.050
test-t-2044.639 - 45.688
test-t-20 --race14.877 - 15.765
AlexDaniel` so technically that's parsing, sure, but it's very run time :) 08:02
I'll be away for a few hours, but to me that feels like something we want to fix for the point release 08:03
lizmat m: multi sub a() { dd callframe(2).my }; a; a # WAT ? 10:32
camelia {"!UNIT_MARKER" => !UNIT_MARKER, "\$!" => Nil, "\$/" => Nil, "\$=finish" => Mu, "\$=pod" => [], "\$?PACKAGE" => GLOBAL, "\$_" => Any, "\$¢" => Nil, "\&a" => sub a (;; Mu | is raw) { #`(Sub|58941856) ... }, "::?PACKAGE" => GLOBAL, :EXPORT(EXPORT), :GL…
lizmat m: multi sub a() { dd callframe(2).my.elems }; a; a # WAT ?
camelia 12
lizmat something is getting lost here?
Geth rakudo: 0d216befba | (Jonathan Worthington)++ | 2 files
Make CallFrame skip over thunk-like things

So that we get consistent results in a `multi` with an onlystar
  `proto`. Addresses #1781.
synopsebot RAKUDO#1781 [open]: callframe info changes inside multi sub
dogbert17 m: say [-] 10 # wasn't this the example fixed by timtoady some time ago, used to return -10 12:30
camelia MoarVM panic: Could not spawn thread: errorcode -11
dogbert17 WAT
m: say [-] 10 # tries again 12:31
camelia 10
dogbert17 hmmm
m: say [-] 10 # wasn't this the example fixed by timtoady some time ago, used to return -10
camelia 10
timotimo m: say &infix:<->(10) 12:33
camelia 10
timotimo so we need to call &infix:<->(&infix:<->(), $first-value), eh?
dogbert17 this specific example can be found in the docs 12:37
I just patched it though
timotimo: what was the deal with messages like this, I have forgotten: Unhandled exception: const_iX NYI 13:25
happened when running: MVM_SPESH_DISABLE=1 ./perl6 --profile -e '(^∞).hyper.grep(*.is-prime)[10_000].say; say now - ENTER now' 13:26
timotimo anything that executes bogus bytecode
memory corruption, wrong jumps, no clue what can usually cause this
dogbert17 at least we have an example :)
timotimo huh, i wonder if removing instrumentation can cause executing code to start running in already-freed memory 13:27
dogbert17 that would be quite bad 13:29
timotimo but valgrind would have complained, wouldn't it? 13:31
dogbert17 and it doesn't 13:37
MasterDuke because it forces everything to one thread? 13:48
dogbert17 on my 32 bit system valgrind does complain, usually with: ==5302== Invalid read of size 4 at 0x41201E3: MVM_hll_map (hll.c:178) 13:50
timotimo, MasterDuke: it can look like this when it SEGV's: 13:57
MasterDuke my 64 bit system also gives the same complaint in valgrind 14:27
fwiw, 14:28
dogbert17: have you tried ASAN? 14:29
timotimo i wonder if we have a problem with deopt + removal of instrumentation perhaps?
but this is all wild speculation
MasterDuke why would there be a deopt? with spesh disabled, wouldn't there not be any opts to de? 14:30
timotimo oh, that's with spesh disabled, ok
pmurias re rakudo failing tests on i386 do we have an evalbot for that? 15:06
yoleaux 27 Apr 2018 11:56Z <Zoffix> pmurias: I think package-lock.json is something with JS backend innit? Would you know how to fix this Issue?
pmurias .tell Zoffix I'll look into it
yoleaux pmurias: I'll pass your message to Zoffix.
pmurias .tell how do I see that the vurlnerable dependency is? 15:07
yoleaux pmurias: I'll pass your message to how.
pmurias .tell Zoffix vulnerable 15:08
yoleaux pmurias: I'll pass your message to Zoffix.
Zoffix pmurias: try going to
I added you to the list of people who can see these messages
Does it show up?
pmurias where? 15:09
Zoffix pmurias: 15:10
Or are you asking about something else?
"rakudo failing tests on i386" <-- it was nqp failing them and it's already fixed on MoarVM and I don't think JVM was affected. 15:11
pmurias Zoffix: I can see the alert I'll read up on package-lock.json and get rid of it 15:12
Zoffix And this is an all-platform test file that covers the bug, so if JS is passing it, then it's not affected:
pmurias: also, the parsing nums with nqp::div_In is buggy. I'm gonna replace it with nqp::numify op soon-ish 15:13
m: 1e10000000000000
camelia ===SORRY!===
P6opaque: get_boxed_ref could not unbox for the representation 'P6bigint' of type Num
Zoffix That's one
m: 1e10000000
(hangs). That's the other
camelia (timeout) 15:14
pmurias Zoffix: you have found how div_In is implemented on the js backend? 15:15
Zoffix: it's slow btw so avoiding it seems like a good idea
Zoffix Yeah, I found it. 15:17
dogbert17 MasteDuke, timotimo: ASAN output here: 15:40
MasterDuke dogbert17: you have GC_DEBUG set to 2? do you get the same error with it off? 15:48
dogbert17 MasterDuke: yes I set it in order to see if something different showed up 15:51
without the flag set ASAN is silent 15:54
I was too quick, it does trigger from time to time with the usual - #0 0xb53daf2c in MVM_hll_map /home/dogbert/repos/rakudo/nqp/MoarVM/src/core/hll.c:178 15:55
timotimo it could very well be that hll_map is just the first op that gets run after some kind of change happens 15:57
Geth nqp: e5389cb6da | (Samantha McVey)++ | tools/build/MOAR_REVISION
Bump MoarVM

Changes: 2018.04-34-g25f165a..2018.04-36-g28f7fe711 28f7fe711 Fix getrandom Linux syscall by removing debug code e5d028ce2 Use all uppercase for Hangul Syllable names
nqp: version bump brought these changes:
adc3bf6c98 | (Samantha McVey)++ | t/nqp/106-unicodenames.t
rakudo: 305c1d6c86 | (Samantha McVey)++ | tools/build/NQP_REVISION
Bump MoarVM/NQP

NQP Changes: 2018.04-10-g4d85039..2018.04-13-gadc3bf6c9 adc3bf6c9 Add test for Hangul syllables's unicode name e5389cb6d Bump MoarVM d36869cc2 Fudge newly-added Unicodey tests on JVM
¦ rakudo: version bump brought these changes:
roast: 8afc5a23a6 | (Samantha McVey)++ | S15-unicode-information/uniname.t
Correct Hangul Syllable Unicode name test

Update it to be all uppercase like the rest of the Unicode codepoint names.
pmurias Zoffix: re 32bit evalbot I'm concerned if a test is failing because int is 32bit on the js backend or because the js backend is buggy 16:35
Zoffix: if I had a 32bit rakudo.moar I could check that directly
Zoffix Ah
Geth roast: 67f9d5a43b | pmurias++ | S02-types/native.t
Fix and unfuge test for .WHAT on a native variable
Zoffix ZOFFLOP: t/spec/S07-hyperrace/stress.t 16:43
ZOFVM: Files=1294, Tests=153324, 151 wallclock secs (21.10 usr 3.09 sys + 3188.27 cusr 159.92 csys = 3372.38 CPU) 17:14
Geth nqp: 133e85df43 | (Zoffix Znet)++ | 3 files
Implement nqp::numify op

Exposes NQP's numification for use in HLL language. This will let us use NQP's num parser instead of re-inventing our own.
Nothing is added to JS backend, as as far as I can see the NQP-level numify op is already exposed in HLL language.
Zoffix m: use nqp; my $n = ~1e200.rand; my int $i; {nqp::while($i++ < 30_000_0, nqp::stmts(+$n,nqp::null)); say now - ENTER now} 17:37
camelia 6.52349021
Zoffix So with the fix, this is now 80% faster than current master
m: say 4.26387271 / 4.024373 17:38
camelia 1.0595123042
Zoffix But is still 6% slower than 2018.03 (the cost of fixed precision)
And fixed denomarls 17:39
And we kinda double-parse it: first we figure out the size of the substring the number is in using nqp::radix twice and then we parse it with nqp::numify to actually get the right number. I'd guess there's an optimization opportunity to avoid the radix stuff and just find the substring size with some faster method 17:41
samcv j: 85679.uniname.say
camelia <unassigned>
Zoffix huh... upgraded to latest rakudo/JSON::Fast and now my ZScript is dying with ===SORRY!=== 17:42
Invalid JSON: [
And blowing away lib/.precomp fixed it 17:46
samcv i want to add a call which checks what version of unicode the VM supports 17:47
Zoffix .tell AlexDaniel` I noticed one or two people having issues after upgrading rakudo and then nuking lib/.precomp fixed the problem. I just had the same myself: Looks like some recent commits broke precomp-renewal-detector or whatever. IIRC before upgrade I was on 2018.03-63 or -68 something in the 60s 17:48
yoleaux Zoffix: I'll pass your message to AlexDaniel`.
samcv should help with testing if we can implement it across VM's. then we won't have to special code for each VM having support for certain characters and can do it by unicode version. as well should also be useful for programmers
Zoffix: which thing would we want to hang that off of
Zoffix shrugs 17:49
.tell AlexDaniel` the only commit I see in src/core/CompUnit in that range is this :S 17:51
yoleaux Zoffix: I'll pass your message to AlexDaniel`.
pmurias Zoffix: when adding nqp:: ops tests are super welcome ;) 17:53
samcv Zoffix: do you know about the failures on toaster, if any of them are related to hash randomization or should i invistigate the ones i see? 17:54
Zoffix samcv: I'm not aware of any toaster results that were run recent enough to test hash randomization
samcv i seem to be getting compilation failure on rakudo-j 17:55
Invocant of method 'path-spec' must be an object instance of type 'CompUnit::Repository::Locally', not a type object of type 'CompUnit::Repository::Staging'. Did you forget a '.new'
Zoffix pmurias: well, there are tests in rakudo. I don't know how to test that op in nqp's test suite
ZOFFLOP: t/spec/S17-supply/batch.t 17:56
Geth nqp: 62550f34de | (Zoffix Znet)++ | tools/build/MOAR_REVISION
[MoarVM Bump] Brings 0 commit

MoarVM bump brought:
¦ nqp: version bump brought these changes:
rakudo: 086980d405 | (Zoffix Znet)++ | tools/build/NQP_REVISION
[NQP Bump] Brings 2 commits

NQP bump brought: 62550f3 [MoarVM Bump] Brings 0 commit 133e85d Implement nqp::numify op
MoarVM bump brought:
Zoffix "Brings 0 commit" :S
rakudo: version bump brought these changes:
40d887c8e1 | (Zoffix Znet)++ | 2 files

  - Fixes hang in parsing of nums with huge exponens
  - Makes parsing of nums 80%
  - Used for parsing Num literals
  - Used in &val which is also used by Str.Numeric
Zoffix hm, I notice `git describe` gives 2 fewer numbers on my system than on whoever bumped before 17:57
m: say v2018.04-36-g28f7fe711 before v2018.04-36-g28f7fe7 17:58
camelia 5===SORRY!5=== Error while compiling <tmp>
Malformed postfix call
at <tmp>:1
------> 3say v2018.7⏏0504-36-g28f7fe711 before v2018.04-36-g28f
Zoffix m: say"2018.04-36-g28f7fe711") before"2018.04-36-g28f7fe7")
camelia False
Zoffix m: say"2018.04-36-g28f7fe711") after"2018.04-36-g28f7fe7")
camelia True
pmurias Zoffix: what the difficulty with testing the op in the nqp test suite?
Zoffix pmurias: because if I use `nqp::numify` I get the NQP's version of it, not the HLL's version of it. 18:03
nqp: use nqp; say(nqp::numify(nqp::unbox_s("42e0")))
camelia 42
Zoffix m: use nqp; say(nqp::numify(nqp::unbox_s("42e0")))
camelia ===SORRY!===
No registered operation handler for 'numify'
Zoffix ^ so I added a "second" numify that makes it available on HLL
s:g/HLL/rakudo's Perl 6 code/; # I've no idea what HLL means in NQP 18:04
dafuq... somehow I lost the num-parser vs nqp::div_In bug 18:16
Geth roast: zoffixznet++ created pull request #422:
[CaR Grant] Test Num/Rat->Num picks closest representable num
roast: b99720b985 | (Zoffix Znet)++ | S02-types/num.t
[CaR Grant] Test Num/Rat->Num picks closest representable num
roast: c930cfcb17 | (Zoffix Znet)++ (committed using GitHub Web editor) | S02-types/num.t
Merge pull request #422 from perl6/car-grant-num-precision-tests

  [CaR Grant] Test Num/Rat->Num picks closest representable num
timotimo Zoffix: HLL can mean different things, one of them is the "hllization" thing that transforms some types into other types at the boundary between perl6 and nqp (so you get an Array rather than a BOOTArray or something) 18:18
the other thing is a few classes/roles that both NQP and rakudo derive from, mostly as a code sharing measure, like HLL::Compiler
Geth ¦ rakudo: zoffixznet self-assigned Rat.Num does not choose the closest representable Num 18:22
Zoffix .tell AlexDaniel` and it's the second time it happens that this massive stresstest fallout (mostly precomp tests) occurs and doesn't go away until you nuke all the .precomp dirs (`declutter` command): 18:24
yoleaux Zoffix: I'll pass your message to AlexDaniel`.
Zoffix There's definitely some precomp bug lurking 18:25
.ask nine do you know if any recent work went in that would cause issues until you blow away .precomp dir? It happened with one of my programs after rakudo upgrade. Here's the second time it happens with my stresstest run where a bunch of tests fail and keep failing until you blow away .precomp dirs (declutter command in the gist): 18:26
yoleaux Zoffix: I'll pass your message to nine.
Zoffix ZOFVM: Files=1294, Tests=153324, 154 wallclock secs (21.41 usr 3.10 sys + 3304.94 cusr 163.14 csys = 3492.59 CPU) 18:28
m: dd <Inf> 18:30
camelia MoarVM panic: Could not spawn thread: errorcode -11
Zoffix e: dd <Inf> 18:31
evalable6, "Inf")
timotimo that's not really necessary, eh?
Zoffix m: dd <Inf>
camelia, "Inf")
Zoffix *phew* I guess it was just a camelia glitch.
brrt . 18:33
yoleaux 27 Apr 2018 16:58Z <Zoffix> brrt: Luke Jit Walker results:
27 Apr 2018 17:55Z <nine> brrt: performance is well within noise.
27 Apr 2018 23:31Z <MasterDuke> brrt: i didn't see any noticeable difference running Tux's test-t and test-t --race scripts on the jit-stack-walker branch
brrt .ask Zoffix what commit of the stack walker were you running? 18:34
yoleaux brrt: I'll pass your message to Zoffix.
brrt i've fixed a bug since
.tell nine that is unfortunate, but after some thought, not unexpected, since I don't think that test exercises the JIT particularly hard
yoleaux brrt: I'll pass your message to nine.
Zoffix good question... IIRC I just ran `git checkout jit-stack-walker`
yoleaux 18:34Z <brrt> Zoffix: what commit of the stack walker were you running?
brrt yeah, and i fixed a bug soon after i asked you all
Zoffix Oh 18:35
Well, then disregard my results :)
brrt so there may have been a race condition. I'm kind of hoping there was
no no, I want to be sure :-)
i had a clean spectest myself, but that proves nothing
Zoffix brrt: can you merge master into it? Latest and greatest MoarVM is needed for some of the new stresstests 18:36
Nm, I think that fix was like from 2 days ago
lemme run and see
brrt i think i've rebased it 18:37
oh, i'm not entirely up-to-date 18:38
Zoffix brrt: can't get past make test: 18:43
brrt let me try that out 18:44
AlexDaniel` . 18:49
yoleaux 17:48Z <Zoffix> AlexDaniel`: I noticed one or two people having issues after upgrading rakudo and then nuking lib/.precomp fixed the problem. I just had the same myself: Looks like some recent commits broke precomp-renewal-detector or whatever. IIRC before upgrade I was on 2018.03-63 or -68 something in the 60s
17:51Z <Zoffix> AlexDaniel`: the only commit I see in src/core/CompUnit in that range is this :S
18:24Z <Zoffix> AlexDaniel`: and it's the second time it happens that this massive stresstest fallout (mostly precomp tests) occurs and doesn't go away until you nuke all the .precomp dirs (`declutter` command):
brrt .ask Zoffix - did you run --reconfig on the jit stack walker branch 18:50
yoleaux brrt: I'll pass your message to Zoffix.
brrt or make reconfig
we need a bunch of different flags for the stack walker to work 18:51
Zoffix brrt: no, I just ran this: 18:52
AlexDaniel yeah I think I had a related problem to this .precomp issue
and I'm pretty sure it appeared after 2018.04, but I could be wrong 18:53
Geth roast: f89f980505 | (Zoffix Znet)++ | S02-types/num.t
Cover hangs in parsing of Nums with huge exponents

Rakudo fix:
AlexDaniel Zoffix: sorry, what's 「declutter」? 18:54
Zoffix $ type declutter
declutter is aliased to `rm -fr **/.precomp'
AlexDaniel right
Zoffix: although… don't you need to also wipe ~/.perl6/precomp ? 18:55
brrt oh, that should've been good enough though 18:56
Zoffix AlexDaniel: don't know 18:57
AlexDaniel: anyway. The num stuff is fixed now.
AlexDaniel oh
dat bump tho
Zoffix yeah, the script relied on not bumping if it can't commit the MOAR_VERSION but this time it could because apparently git describe gives different-length tags 18:58
need to make it detect this stuff better
AlexDaniel Zoffix: alright, so I cherry-pick and , correct? 19:00
Zoffix AlexDaniel: we also gonna need a MoarVM point release 19:01
AlexDaniel oh how wonderful
Zoffix :}
AlexDaniel Zoffix: wait, why? 19:02
AlexDaniel is trying to understand
Zoffix AlexDaniel: this stuff
c: 2018.03 say 5e-324
committable6 Zoffix, ¦2018.03: «0␤»
Zoffix lol
Well, otherwise we gonna lose all the precision/denormals fixes 19:03
AlexDaniel riiiiight
okay I see now
brrt Zoffix: can't replicate :-(
Zoffix And I'm guessing there's by now a ton of stresstests covering those fixes
AlexDaniel samcv: hello, you there? :)
samcv yep
Zoffix brrt: ¯\_(ツ)_/¯ can't replicate then ignore :) It could be just my system 19:04
AlexDaniel samcv: so, some discussion ↑ about the point release
samcv: we'll have to do it, including moarvm point release
samcv ok let me look. pretty jetlagged atm
looking forward to tonight 19:05
Zoffix samcv: FWIW there's also some precomp issue that's showing up; dunno if we're gonna look into it before the point release or not.
samcv ok so is this related to the numification?
AlexDaniel yeah
Zoffix samcv: no, it's something different that just recently got noticed 19:06
samcv ok. then maybe we want to make a new branch of moarvm and then cherry pick the needed moarvm changes to that?
.oO( I hope it's not related to numification )
samcv oh
brrt that's not how i roll though :-) something is broken, it better be fixed
AlexDaniel well, the point release is related to numification… that's what I meant xD
samcv ah ok
i think we should make a moarvm branch to do the point release and only use the commits we need to make the fixes 19:07
AlexDaniel yes
that's correct
same for nqp/rakudo
samcv ok cool :) we both thought similarly
AlexDaniel samcv: here's how I see it. If you make a branch with all needed commits, I'd be able to create a prerelease and test that 19:09
samcv so on moarvm do we just need these commits 19:10
AlexDaniel samcv: so just pause before making the tag and other final steps, so that we just have a branch we required commits that we can work with
samcv okay cool. let me make a branch
AlexDaniel with* 19:12
Zoffix samcv: FWIW you said you had an issue with JVM build earlier. Just built it on my box and it built fine 19:14
don't see a perl6-j or it building jvm rakudo in the log.. 19:15
Zoffix nukes and re-tries 19:16
Creating tools/build/ ... 19:19
Can't exec "/home/cpan/J/install/bin/moar": No such file or directory at tools/lib/NQP/ line 293. 19:20
Do I really have to have moarvm installed to install JVM NQP or is this my build script glitching?
samcv Zoffix: i think i've encountered the same thing. you need moarvm i *think*? 19:22
Zoffix Ah, it's buildscript
(Bool :$moar = True) { ... my $backends = join ',', ('moar' with $moar), ('jvm' with $jvm); } 19:23
(even if I set moar to false it's still defined
samcv AlexDaniel: see if this works 19:24
has those two commits from that Zoffix PR you linked
Zoffix (by buildscript I meant ZScript, not the nqp's build tools)
japhb Are any of the #perl6-dev folk in the Ireland or NYC areas in the next few weeks? I'm going to be travelling to those areas ... 19:26
AlexDaniel samcv: maybe it's not the best idea to name the branch identically to the upcoming tag
but I actually don't know if it affects anything
the branch should be merged back into master anyway, and can be deleted later 19:27
samcv AlexDaniel: well. those commits are already in master right?
but yeah we can delete the branch after tagging if we want
maybe should move the branch to be named differently than the tag
AlexDaniel samcv: yes, but then you'll have some extra commits for VERSION and maybe changelog 19:28
and you'd have to get these back into master anyway, so instead of cherry-picking you can just merge
as a bonus you can then delete the branch without getting a dangling tag :)
El_Che tag and branches are usued as synonyms by a lot of tools 19:29
(including mine)
samcv AlexDaniel: ah i see what you mean. we can merge i suppose after the 2018.04.1 release. (i am guessing that's what you mean?)
AlexDaniel samcv: yes
samcv AlexDaniel: what should we name the branch? is 2018.04.1-branch ok? 19:30
AlexDaniel in rakudo I am actually using release/2018.04.1 19:31
(that's right, with a slash)
but any name will do, it's just a branch
Zoffix But rakudo build now fails... "Unable to read configuration from NQP on MoarVM" 19:37
samcv AlexDaniel: i have pushed to release/2018.04.1 on MoarVM and deleted the previout '2018.04.1' branch 19:38
AlexDaniel 👍
Zoffix oh, it's another bug in ZScript "$ :$test, :$jvm, :$moar;" 19:40
Wonder if this should warn
m: my $o := class Z { method z (:$a, :$b) { dd [$a, $b ] } }.new; $o.z :$a, :$b 19:41
camelia 5===SORRY!5=== Error while compiling <tmp>
Variable '$a' is not declared
at <tmp>:1
------> 3:$a, :$b) { dd [$a, $b ] } }.new; $o.z :7⏏5$a, :$b
Zoffix m: my $o := class Z { method z (:$a, :$b) { dd [$a, $b ] } }.new; $o.z :a, :b
camelia WARNINGS for <tmp>:
Useless use of ":b" in sink context (lines 1, 1)
[Bool::True, Any]
Zoffix Oh it does..
m: sub foo { my $o := class Z { method z (:$a, :$b) { dd [$a, $b ] } }.new; $o.z :a, :b }; foo
camelia [Bool::True, Any]
Zoffix But not in this context
Ah, it's right here. It just ends up returning a list 19:43
m: sub foo { my $o := class Z { method z (:$a, :$b) { dd [$a, $b ] } }.new; $o.z :a, :b }; dd foo
camelia [Bool::True, Any]
(Nil, :b)