Perl 6 language and compiler development 2.0 | Logs at irclog.perlgeek.de/perl6-dev/today | For toolchain/installation stuff see #perl6-toolchain | For MoarVM see #moarvm
Set by moderator on 3 May 2018.
00:30 softmoth joined 00:32 softmoth joined 01:58 ilbot3 joined
moderator Perl 6 language and compiler development 2.0 | Logs at irclog.perlgeek.de/perl6-dev/today | For toolchain/installation stuff see #perl6-toolchain | For MoarVM see #moarvm
02:42 softmoth joined 04:02 llfourn joined 04:37 softmoth joined 04:57 softmoth joined 05:07 softmoth joined 05:08 softmoth joined 05:12 softmoth joined 05:13 cog_ joined 05:15 zostay joined 05:18 unicodable6 joined, statisfiable6 joined, greppable6 joined, nativecallable6 joined, quotable6 joined, committable6 joined, undersightable6 joined
bartolin .tell Zoffix You made some commits recently to the effect that nqp::numify is used heavier. This op isn't very sophisticated on the jvm backend, so there are some failing spectests now. Will the design stay that way? If so, I'll look into improving nqp::numify for the jvm backend (unless someone beats me to it). 05:59
yoleaux bartolin: I'll pass your message to Zoffix.
23 Apr 2018 23:02Z <MasterDuke> bartolin: i don't have before/after timings either, but it was pretty slow before that commit anyway
06:22 dct joined 06:24 Zoffix joined
Zoffix .tell bartolin Yeah, we now use the same code path for parsing num in Rakudo as we do in NQP. Is it precision/roundtrippage tests that fail? IIRC JVM's nqp::div_In implementation gets those right, so maybe numify's parsing can be just done with bigints 06:26
yoleaux Zoffix: I'll pass your message to bartolin.
06:26 Zoffix left 06:37 AlexDaniel joined
bartolin .tell Zoffix If I'm not mistaken there are other problems (as well?). e.g. some strings are not recognized as numbers at all or unicode minus sign is not recognised 06:50
yoleaux 06:26Z <Zoffix> bartolin: Yeah, we now use the same code path for parsing num in Rakudo as we do in NQP. Is it precision/roundtrippage tests that fail? IIRC JVM's nqp::div_In implementation gets those right, so maybe numify's parsing can be just done with bigints
bartolin: I'll pass your message to Zoffix.
bartolin nqp-m: say(nqp::numify(nqp::unbox_s("4/3")))
camelia 1.3333333333333333
bartolin nqp-j: say(nqp::numify(nqp::unbox_s("4/3")))
hmm, well, that returns 0 locally 06:51
^^ I've got a patch that fixes this example, but I didn't test it thoroughly, yet 06:54
07:15 robertle joined
AlexDaniel squashable6: next 07:22
squashable6 AlexDaniel, āš šŸ• Next SQUASHathon in ā‰ˆ2 hours (2018-05-05 UTC-12āŒUTC+14). See github.com/rakudo/rakudo/wiki/Mont...Squash-Day
Geth nqp: 199c12780f | pmurias++ | src/vm/js/nqp-runtime/nfa.js
[js] Fix longest literal nfa matching
 07:37
07:37 pmurias joined
pmurias jnthn: I found the nfa bug... it turned out to be a missing + 1 in literal length calculation 07:38
bartolin: Zoffix stated that his plan was to move towards using nqp::numify more 08:09
08:33 cog_ joined 08:41 ufobat joined
Geth nqp: 0e5fde48fc | (Paweł Murias)++ | src/vm/jvm/runtime/org/perl6/nqp/runtime/Ops.java
[jvm] In NFA matching fix longest literal ordering for literals of length 1
 08:43
nqp: d2cb487604 | (Paweł Murias)++ | t/nqp/074-nfa.t
Test longest literals in NFAs for literals of length 1
lizmat Files=1239, Tests=76313, 315 wallclock secs (15.82 usr 5.52 sys + 2175.61 cusr 219.55 csys = 2416.50 CPU) 09:22
09:25 brrt joined 09:40 Ulti joined 09:59 robertle joined
jnthn pmurias: Ah, good find :) 10:03
samcv [Tux]: do you have that test file that caused the utf8-c8 issue on CSV? 10:17
10:18 dct joined 11:13 |Tux| joined
samcv jnthn: the first release of perl6 rakudo only supported moarvm and jvm yes? 11:15
that could help the notability page of moarvm on wiki 11:16
AlexDaniel samcv: I wasn't there, but AFAIK it also supported parrot, and support for parrot was dropped somewhere in 2015 (I guess 2015.02 was the last release with parrot support?) 11:24
in fact, 2014.01 was the first release of rakudo on moar
and rakudo existed for much-much longer 11:25
11:26 brrt joined
samcv 2015.12 seems to be the first stable release 11:27
so if that's true then parrot wasn't really supported?
this posting also seems to indicate that parrot woasn't supported perl6advent.wordpress.com/2015/12/...s-is-here/ 11:29
brrt correct 11:52
samcv well i added two more citations to the moar wiki page
brrt I'm not sure anyone has built rakudo-on-parrot for a few years
we should probably say something more intelligent about the fastest VM 11:53
11:53 cog_ joined
brrt (moarvm being the fastest VM in march 2014; that was pre-spesh, pre-jit, pre-expr-jit, pre all of your own work on unicode/string support 11:53
lizmat rakudo won't build on parrot anymore because we have removed all parrot specific code from the repo
11:55 [TuxCM] joined
|Tux| samcv, it is on git now: github.com/Tux/CSV/blob/master/43-1.t 11:57
11:57 AlexDaniel joined
AlexDaniel samcv: 2015.12 was when perl6 language v6.c was released, and rakudo 2015.12 supported that 11:58
samcv: arguably all releases of rakudo were stableā€¦
samcv language stable release? 11:59
AlexDaniel yea
samcv well. that sounds like the same thing to most people ĀÆ\\_(惄)_/ĀÆ
AlexDaniel c: 6.b say $*PERL.compiler.version 12:00
committable6 AlexDaniel, Ā¦6.b: Ā«Cannot find this revision (did you mean ā€œv6.bā€?)Ā»
samcv but you could argue one way or the other
AlexDaniel c: v6.b say $*PERL.compiler.version
committable6 AlexDaniel, Ā¦v6.b: Ā«v2015.10ā¤Ā»
AlexDaniel c: v6.a say $*PERL.compiler.version
committable6 AlexDaniel, Ā¦v6.a: Ā«Cannot find this revision (did you mean ā€œv6.cā€?)Ā»
AlexDaniel c: 2015.09 say $*PERL.compiler.version 12:01
committable6 AlexDaniel, Ā¦2015.09: Ā«v2015.9ā¤Ā»
AlexDaniel c: 2015.09 say $*PERL 12:02
committable6 AlexDaniel, Ā¦2015.09: Ā«Perl 6 (6.Advent)ā¤Ā»
AlexDaniel c: all say $*PERL
committable6 AlexDaniel, gist.github.com/8dc291ca1db308f8f0...605c913845
|Tux| Rakudo version 2018.04.1-37-g1447f41e6 - MoarVM version 2018.04.1-53-g1ef4aaf73
csv-ip5xs0.860 - 0.868
csv-ip5xs-208.556 - 8.701
csv-parser37.292 - 37.503
csv-test-xs-200.427 - 0.449
test8.977 - 9.033
test-t2.419 - 2.459
test-t --race0.984 - 1.071
test-t-2042.586 - 43.322
test-t-20 --race15.050 - 15.417
 12:15
lizmat perhaps interesting in the light of utf8-c8: beets.io/blog/paths.html 13:10
13:44 AlexDaniel joined 13:59 brrt joined 14:28 skids joined
Geth nqp/make_builds_reproducible_again: 2df603964d | (Stefan Seifert)++ | src/vm/moar/QAST/QASTCompilerMAST.nqp
Always generate closure taking code in the same order

Fixes one source of reproducible build issues.		 14:29
15:13 cog_ joined
nine A rebootstrap of nqp should just be a make m-bootstrap-files, shouldn't it? Because if I do that and follow by make clean && make install, I get a "Code ref 'BUILD' does not exist in serialization context" trying to compile gen/moar/stage1/nqpmo.nqp 15:26
jnthn Yeah, which in turn should just involve a copy of the files to the src/vm/moar/stage0/ directory or similar 15:27
nine jnthn: it does and it fails the make clean && make afterwards. That's on an unchanged master btw 15:29
jnthn Urgh. I guess that means we'd have to go back to the last bootstrap and bisect the commits between to see that broke it :S 15:34
Geth nqp/make_builds_reproducible_again: 7 commits pushed by (Stefan Seifert)++
nine bisecting 15:36
Woah make: *** [Makefile:279: gen/moar/stage1/QRegex.moarvm] Segmentation fault (core dumped) 15:38
Not sure if this is git bisect bad or good 15:39
brrt looks not terribly good 15:40
nine The first bad commit could be any of: 15:42
a2f66567052e827a39cfda6d8908f62532ef3b12
68164ca223058ca71f923e5a9de876d9c3ceb179
So it's a2f66567052e827a39cfda6d8908f62532ef3b12, because the other one's fixing a test.
github.com/perl6/nqp/commit/a2f665...2532ef3b12 15:43
Kinda ironic...
Now if someone has some idea of how this could break the rebootstrap while not showing any issue whatsoever anywhere else, I'd very much like to hear it. 15:44
jnthn uhhh...
Yes, that will really mess things up 15:45
Since it probably means that multiple stages now work against the same SC 15:46
So the compiler that's running will end up overwriting its own SC entries with the compiler it's compiling :)
nine Ok, but that's an issue very specific to the bootstrap. Thus fixable e.g. by providing an additional identifier from the outside, i.e. the build system. 15:47
jnthn Probably Right :) 15:48
s/Probably//
nine How nice that there's already the so far completely unused stable-sc mechanism there 15:49
jnthn I'm pretty sure it was used at some point :-) 15:50
nine Many moons ago ;) 15:51
groceries 15:55
&
16:16 stmuk_ joined 16:34 brrt joined 16:38 Ven`` joined
timotimo hmm. before i push the fix for ^ and $ and friends in assertions, maybe it'd be good to see if it triggers in any tools we've made ourselves .. 16:46
how can i make sure that a "note" reaches the screen even when i'm running "make test" or "make spectest"? 16:51
maybe i should instead write stuff to a file on disk
eh, it'll be fine, long time until release 16:59
Geth nqp: 075ff765f5 | (Timo Paulssen)++ | src/QRegex/P6Regex/Actions.nqp
switch around a few anchor types inside <after>

since <after> is implemented as "flipping" the AST of the regex and matching it against a flipped version of the target string, a "right word boundary" has to become a "left word boundary", same for ^^/$$ and ^/$
timotimo ^- please test this 17:00
once we bump for this, there's a TODO we can remove in S05-mass/rx.t 17:01
Geth nqp: 256cd26919 | (Stefan Seifert)++ | 14 files
Fix rebootstrap broken by SC name collision

Since serialization context IDs are derived from the source code, the compiler ended up overwriting its own SC entries whith the compiler it's compiling. Break the circularity by extending the SC ID for compilation of stage 1. This way stage 0 is different from stage 1 which is different from stage 2 which ends up as stage 0 on a rebootstrap.		 17:07
nine At least fixing bootstrap payed off. The rebootstrap fixed a couple more reproducibility issues 17:13
Geth nqp/make_builds_reproducible_again: 8 commits pushed by (Stefan Seifert)++ 17:24
nine Would be nice if someone who is affected could test MoarVM's and NQP's make_builds_reproducible_again branches
18:08 [TuxCM] joined 18:33 cog_ joined 19:20 FROGGS joined 19:22 brrt joined 19:31 robertle joined
Geth nqp/make_builds_reproducible_again: 7084c98a3b | (Stefan Seifert)++ | 2 files
Reproducible order of methods in roles
 20:00
nqp/make_builds_reproducible_again: 42c8695383 | (Stefan Seifert)++ | 10 files
Rebootstrap to get the reproducibility fixes for NQP itself
nqp/make_builds_reproducible_again: 5caecb9df5 | (Stefan Seifert)++ | src/how/NQPParametricRoleHOW.nqp
Reproducible order of methods in roles
 20:06
nqp/make_builds_reproducible_again: 1b1c0b8782 | (Stefan Seifert)++ | 10 files
Rebootstrap to get the reproducibility fixes for NQP itself
nine Getting methods of roles added in a predictable order is kinda harder since the sorted_keys sub does not seem to be available in the knowhow classes 20:09
But the remaining reproducibility issues are relatively tiny and maybe do not actually cause any harm.
Geth nqp: 154e20c7cb | usev6++ | src/vm/jvm/runtime/org/perl6/nqp/runtime/Ops.java
[JVM] Handle underscores in coercing to nums

This restores pi for rakudo-jvm.		 20:13
nqp: 29aab19edb | usev6++ | t/nqp/109-coercions.t
Test numifying string with underscore
20:20 Kaiepi joined
Geth rakudo: flussence++ created pull request #1796:
Add a CACHEDIR.TAG to precomp dirs		 20:39
nqp: 63dc792cda | usev6++ | src/vm/jvm/runtime/org/perl6/nqp/runtime/Ops.java
[JVM] Handle unicode minus in coercing to nums
 20:44
nqp: 41f21a1471 | usev6++ | t/nqp/109-coercions.t
Test numifying string with unicode minus sign
20:52 Kaypie joined 21:22 MasterDuke joined 21:53 cog_ joined 22:21 Ven`` joined 22:29 skids joined

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!