#perl6-dev on 28 April 2018 - Raku Programming Language Log

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 github.com/rakudo/rakudo/commit/84...ce5140e76b

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

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 )

03:09

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

===SORRY!===

P6opaque: get_boxed_ref could not unbox for the representation 'P6bigint' of type Num

gaddamit

05:55

j: say 1e100000000000

05:56

camelia

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: temp.perl6.party/num-speed-fix-diff.diff

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

06:39

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` irclog.perlgeek.de/perl6-dev/2018-...i_16105470

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 fpaste.scsys.co.uk/577323

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 fpaste.scsys.co.uk/577329

07:35

Kaiepi

finally, rakudo bot's in working order

07:39

AlexDaniel`

07:43

yoleaux

06:42Z <Zoffix> AlexDaniel`: irclog.perlgeek.de/perl6-dev/2018-...i_16105470

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-ip5xs	0.904	-	0.944
csv-ip5xs-20	9.040	-	9.134
csv-parser	38.099	-	38.348
csv-test-xs-20	0.452	-	0.462
test	9.501	-	9.609
test-t	2.546	-	2.546
test-t --race	1.037	-	1.050
test-t-20	44.639	-	45.688
test-t-20 --race	14.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
0

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.

12:03

synopsebot

RAKUDO#1781 [open]: github.com/rakudo/rakudo/issues/1781 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

dogbert17

hmmm

m: say [-] 10 # wasn't this the example fixed by timtoady some time ago, used to return -10

camelia

timotimo

m: say &infix:<->(10)

12:33

camelia

timotimo

so we need to call &infix:<->(&infix:<->(), $first-value), eh?

dogbert17

this specific example can be found in the docs docs.perl6.org/routine/reduce

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: gist.github.com/dogbert17/782a4be7...8f882b71ce

13:57

MasterDuke

my 64 bit system also gives the same complaint in valgrind

14:27

fwiw, gist.github.com/MasterDuke17/b4843...4f03e02aa5

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? github.com/perl6/nqp/issues/437

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 github.com/perl6/nqp

I added you to the list of people who can see these messages

Does it show up?

pmurias

where?

15:09

Zoffix

pmurias: i.imgur.com/5d0OcSy.png

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: github.com/perl6/nqp/blob/master/t...115-nums.t

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: gist.github.com/dogbert17/52e81990...8affe64b72

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

16:06

nqp: version bump brought these changes: github.com/MoarVM/MoarVM/compare/2...g28f7fe711
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

16:25

¦ rakudo: version bump brought these changes: github.com/perl6/nqp/compare/2018....gadc3bf6c9

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.

16:26

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

Geth

roast: 67f9d5a43b | pmurias++ | S02-types/native.t
Fix and unfuge test for .WHAT on a native variable

16:36

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.

17:35

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

*denormals

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

Zoffix

huh... upgraded to latest rakudo/JSON::Fast and now my ZScript is dying with ===SORRY!===

17:42

Invalid JSON: [

"/home/cpan/zscript/bin/../lib/RDev.pm6"

]

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: irclog.perlgeek.de/perl6-dev/2018-...i_16107270 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 github.com/rakudo/rakudo/commit/9b...116d33ac2f

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: github.com/MoarVM/MoarVM/compare/2...6-g28f7fe7

¦ nqp: version bump brought these changes: github.com/MoarVM/MoarVM/compare/2...6-g28f7fe7

rakudo: 086980d405 | (Zoffix Znet)++ | tools/build/NQP_REVISION
[NQP Bump] Brings 2 commits

NQP bump brought: github.com/perl6/nqp/compare/2018....5-g62550f3 62550f3 [MoarVM Bump] Brings 0 commit 133e85d Implement nqp::numify op
MoarVM bump brought: github.com/MoarVM/MoarVM/compare/2...6-g28f7fe7

Zoffix

"Brings 0 commit" :S

rakudo: version bump brought these changes: github.com/perl6/nqp/compare/2018....5-g62550f3
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 Version.new("2018.04-36-g28f7fe711") before Version.new("2018.04-36-g28f7fe7")

camelia

False

Zoffix

m: say Version.new("2018.04-36-g28f7fe711") after Version.new("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

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 github.com/rakudo/rakudo/issues/1782

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): gist.github.com/zoffixznet/43e5db7...237262b856

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): gist.github.com/zoffixznet/43e5db7...237262b856

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

NumStr.new(Inf, "Inf")

timotimo

that's not really necessary, eh?

Zoffix

m: dd <Inf>

camelia

NumStr.new(Inf, "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: irclog.perlgeek.de/perl6-dev/2018-...i_16103228

27 Apr 2018 17:55Z <nine> brrt: csv-ip5xs.pl 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

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: gist.github.com/zoffixznet/8ff7fe9...bbc2eacac3

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: irclog.perlgeek.de/perl6-dev/2018-...i_16107270 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 github.com/rakudo/rakudo/commit/9b...116d33ac2f

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): gist.github.com/zoffixznet/43e5db7...237262b856

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: github.com/zoffixznet/z/blob/maste...#L219-L224

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: github.com/rakudo/rakudo/commit/40d887c8e1

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

dat bump tho github.com/perl6/nqp/commit/62550f...e9c30fa5dd

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 github.com/perl6/nqp/commit/133e85...2d417a3d6d and github.com/rakudo/rakudo/commit/40...2c5efe868c , 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 github.com/MoarVM/MoarVM/pull/850

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?

Zoffix

.oO( I hope it's not related to numification )

samcv

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 github.com/MoarVM/MoarVM/pull/850

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

uh...

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/install-jvm-runner.pl ...

19:19

Can't exec "/home/cpan/J/install/bin/moar": No such file or directory at tools/lib/NQP/Configure.pm 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

xkcd.com/1319/

samcv

AlexDaniel: see if this works github.com/MoarVM/MoarVM/tree/2018.04.1

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 "$rd.build-rakudo :$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)

Zoffix

yeah. Oh well.

$ ./perl6-j -v

19:47

This is Rakudo version 2018.04-25-g40d887c built on JVM

finally. Yeah, it still builds

and S32-num/stress.t passes

19:48

(tried to repro precomp issue by installing 2018.03 from scratch, then upgrading to master; but no issue occured)

20:14

At least if it happens to the user, we can just tell them to blow precomp, so it's not that important to find and fix it before release.

lizmat

Zoffix: seems HEAD currently has borked mi6 again

20:17

Zoffix

lizmat: what's the failure?

20:18

lizmat

hmmm...lemme double check

Zoffix

And how to reproduce it (I see the module got no tests)

20:19

lizmat

it was probably because a previous "mi6 new" failed because of .. dunno

but then I saw fresh commits in rakudo, pulled, built then did the mi6 new again

20:20

and that failed.

nuked the dir, tried again, success

Zoffix

===> Building [FAIL]: HTTP::Tinyish:ver<0.1.0>

20:21

Aborting due to build failure: HTTP::Tinyish:ver<0.1.0> (use --force-build to override)

lizmat

FWIW, the previous setting build failed in make install with: No such method 'install' for invocant of type 'ValueObjAt'

Zoffix

full output: gist.github.com/zoffixznet/b64e2e5...436c6f3e88

lizmat

in block <unit> at tools/build/install-core-dist.pl line 28

Zoffix: could you locally revert 0d216befba336b1cd7a0b424 and see if that makes a difference ?

20:22

Zoffix

lizmat: nope, fails the same

20:26

lizmat

:-( then I have no idea

20:27

Zoffix

I think it's the legacy build system that fails. In the output I see this:

Building with plugin: Zef::Service::Shell::LegacyBuild+{<anon|1>}

Command: /home/cpan/rakudo/install/bin/perl6 -Ilib -e require '/tmp/tmp.gVZtZYofKl/Build.pm'; ::('Build').new.build('/tmp/tmp.gVZtZYofKl') ?? exit(0) !! exit(1);

brrt

lizmat: have you tried the jit-stack-walker branch yet? I know you're on macOS so i'm keen to know if stuff builds correctly

Zoffix

And Build.pm script is this: gist.github.com/zoffixznet/4d8baa0...77560906d4

20:28

It never returns a successful status

Filed as github.com/ugexe/zef/issues/247

20:31

And if I edit Build.pm6 to return true and install HTTP::Tinyish and then install App::Mi6, it seems to work fine. `mi6 new Meows` doesn't crash or anything

20:33

FWIW that's still on the build with 0d216befba336b1cd7a0b424 reverted

20:35

Zoffix unreverts and tries again

20:36

shit exploded

20:38

No such method 'install' for invocant of type 'Str'

in block <unit> at tools/build/install-core-dist.pl line 28

And tons of maketest failures: gist.github.com/zoffixznet/916d83f...3258bd2a19

Second run failed too: gist.github.com/zoffixznet/66168f8...b54b737baa

20:43

Zoffix nukes .precomp dirs and bets it'll build now

yup

20:46

Geth

nqp/release/2018.04.1+: 5 commits pushed by (Aleks-Daniel Jakimenko-Aleksejev)++, (Zoffix Znet)++

20:48

rakudo/release/2018.04.1+: cc93bc9ad3 | (Aleks-Daniel Jakimenko-Aleksejev)++ | tools/build/NQP_REVISION
[NQP Bump] Brings 5 commits

NQP bump brought: github.com/perl6/nqp/compare/2018....g04918ab66 04918ab Implement nqp::numify op 9e4edf9 Test we can handle fancy unicode nums 619bf68 Use original string num in test desc 8d16807 Cover denormals and num value drift bugs ... (5 more lines)

20:49

rakudo/release/2018.04.1+: 4e38bc1f84 | (Zoffix Znet)++ (committed by Aleks-Daniel Jakimenko-Aleksejev) | 2 files
Use new nqp::numify op for Num parsing

  - 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

lizmat

Zoffix: that smells like the problem I saw, but I didn't need to nuke install, just get a fresh pull

samcv

i gotta go to bed right now. will be back in the morning CEST time

20:50

Zoffix

20:51

lizmat: and the pull brought fresh commits?

AlexDaniel

samcv: rest well

20:52

lizmat

Zoffix: yes

required a reconfigure, so that may have had something to do with it as well

Zoffix

Filed what I know about the issue so far R#1783

20:53

synopsebot

R#1783 [open]: github.com/rakudo/rakudo/issues/1783 New sporatic explosions likely related to precomp

AlexDaniel

+1 for creating a ticket

20:55

Zoffix

Oh, awesome. Reproed

21:01

Zoffix tries repro a 3rd time to make sure it's not a fluke

21:02

El_Che

it looks it's gonna be a nice dot release :)

21:08

Zoffix

nice? It's just fixing a bug

21:09

ZofBot: dot releases aren't nice

Zoffix misses zofbot

AlexDaniel

well, point releases are certainly better than main ones :)

21:14

maybe except for 2017.04.* ones

Zoffix

Wow it's been a year already

time flies

AlexDaniel

indeed

21:15

Zoffix

Got the steps to repro the precomp issue, if anyone's able to verify: github.com/rakudo/rakudo/issues/17...-385205863

(kinda lengthy; need to sit throuigh 3 build cycles)

lizmat

Zoffix: trying to repro

21:17

MasterDuke

same here

21:19

Zoffix

Got "No such method 'install' for invocant of type 'ValueObjAt'" as a failure this time

21:23

lizmat

yeah, I've seen that one as well

21:24

Zoffix

.tell nine the problem I mentioned in earlier bot message now has an Issue with repro instructions for it: github.com/rakudo/rakudo/issues/17...-385205863

21:25

yoleaux

Zoffix: I'll pass your message to nine.

MasterDuke

final build had lots of test failures, and `make install` died with `Too few positionals passed; expected 2 arguments but got 1 in block <unit> at tools/build/install-core-dist.pl line 17`

21:34

lizmat

Zoffix: confirmed, my error is: No such method 'install' for invocant of type 'Str'

21:35

in block <unit> at tools/build/install-core-dist.pl line 28

and many make test errors

Zoffix

Awesome \o/

21:37

MasterDuke

www.innoq.com/en/blog/native-cloju...d-graalvm/ interesting article re Graal and the JVM

21:55

Kaiepi

what the fuck my os couldn't clear /tmp on boot because running make html with perl 6's docs left over 100k files in /tmp

22:40

perl6 -e 'unlink $*CWD.dir.grep(/ \/tmp\/ \w ** 10 /)>>.Str' did the job nicely though

22:46

is this intended or should i make an issue about it?

22:47

El_Che

Kaiepi: why are you writing in /tmp?

Kaiepi

what do you mean?

22:48

they were temp files from running make html in doc

El_Che

on some oses /tmp is ram

on some disk

so not very portable

22:49

Kaiepi

htmlify.p6 uses it by default since it doens't specify a dir to put the files in

22:50

AlexDaniel

El_Che: alright, so there's a prerelease tar

22:51

El_Che

it should be /vat/tmp then (although that would doesn't get cleaned)

Kaiepi

m: say $*TMPDIR

camelia

"/tmp".IO

El_Che

dilemmas :)

AlexDaniel++

AlexDaniel

El_Che: do I just click restart for all targets in the canary repo?

22:52

in travis I mean

El_Che

yes

AlexDaniel: the images are in the docker hub registry, so runs will be faster (I'll change the .travis.yml tomorrow)

22:54

it's the LOCAL_BUILD var that must be empty

AlexDaniel

aaaah I did it a bit wrong

22:55

I forgot

okay

AlexDaniel restarts his thing

alright, I'll run toaster too

22:58

ooh… oops, ok

23:00

Kaiepi

what about making a tmp dir in the same dir as htmlify.p6?

idk if it sent or not but /var/tmp and /tmp aren't compatible with windows

23:01

Geth

rakudo/release/2018.04.1+: c317d22e72 | (Aleks-Daniel Jakimenko-Aleksejev)++ | tools/build/NQP_REVISION
Fix nqp version

Oops, rebasing too much.

23:03

Kaiepi

anyway i'll make an issue about this once i figure out whether make html always does this or if it's just when it gets killed

23:04

lizmat gets some sleep

23:06

Kaiepi

night

23:07

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

Thank you!