Perl 6 language and compiler development | Logs at colabti.org/irclogger/irclogger_log/perl6-dev | For toolchain/installation stuff see #perl6-toolchain | For MoarVM see #moarvm
Set by Zoffix on 27 July 2018.
00:51 Kaiepi left 00:52 Kaiepi joined 01:07 Kaiepi left 01:08 Kaiepi joined 01:14 Kaypie joined 01:15 Kaiepi left 01:20 Kaypie left 01:22 Kaiepi joined 06:38 Geth left 06:39 Geth joined 09:19 camelia joined 09:20 ChanServ sets mode: +v camelia 09:39 [Tux] left 09:41 hankache joined 09:50 [Tux] joined
nine Shouldn't it be - in theory - possible to run compiler stages in parallel? I'd guess that we could run optimization for frames as soon as we finish parsing and code generation on them without actually having to wait for future frames. And we could generate bytecode for the frames as soon as they are optimized. 10:06
Doing this would also probably mean quite a bit of memory saving, as we wouldn't keep the whole QAST around. 10:07
timotimo optimization sometimes goes a little back-and-forth, but i'm not sure if it ever does across frames 10:11
nine The optimizer already works in tree order which I guess would make it fit well with into Action's control flow. 10:18
timotimo by "in parallel" you mean more "interleaved" than "multithreaded", right? 10:25
that'll make --output=ast and --output=optimize a little more difficult to handle
10:30 lizmat left 10:33 lizmat joined
[Tux] Rakudo version 2019.03.1-279-g650bbc1d2 - MoarVM version 2019.03-108-gc036a8f7b
csv-ip5xs0.724 - 0.731
csv-ip5xs-205.974 - 6.072
csv-parser21.792 - 22.355
csv-test-xs-200.429 - 0.431
test7.029 - 7.566
test-t1.663 - 1.762
test-t --race0.795 - 0.811
test-t-2028.521 - 28.561
test-t-20 --race9.426 - 9.463
 10:35
nine timotimo: no I actually mean multithreaded. Interleaving would just be a natural first step. 10:49
10:58 vrurg left 10:59 vrurg joined
lizmat m: my %b is BagHash = <a a b c c>; %b (&)= <a a b c a>; say %b # this feels wron 11:37
camelia BagHash(BagHash(a(2), b, c))
lizmat or am I missing something ? 11:38
timotimo yeah seems odd to have a baghash inside a baghash 11:41
12:51 Geth left 12:52 Geth joined 12:53 AlexDaniel left, AlexDaniel joined 13:02 hankache left 13:12 andreios joined
andreios it seems that nqp-j doesn't use jline for interactive repl 13:38
it uses byte buffer when receiving command from console, and unables to detect CR 13:40
the problem propogates to perl6-j as well
AlexDaniel kawaii: so, one thing that you can also test is rakudo-pkg-canary 14:29
kawaii: with the sakefile, it'll go like this: 14:30
kawaii: VERSION=2018.10 VERSION_MOAR=2018.10 VERSION_NQP=2018.09-68-g16f0f458f sake all 14:31
kawaii: but with different versions, of course
kawaii: here the nqp version is set directly because publicly there's no nqp release yet
it has to be, otherwise things are not going to work :) 14:32
but this is just for the canary
kawaii: when done, `sake human-canary-upload` will upload the generated tarball
kawaii: after that you go to github.com/perl6/rakudo-pkg-canary...its/master and restart tests
kawaii: it will then run on several different distros, including some 32-bit images 14:33
which is important because we had some 32-bit bugs slip in
releasable6: status 14:35
releasable6 AlexDaniel, Next release in ≈4 hours. 1 blocker. 132 out of 280 commits logged (⚠ 2 warnings)
AlexDaniel, Details: gist.github.com/8f55749f63b8ee2fd6...2ed2ac507f
andreios it seems i've managed to fix REPL, but I'm not sure about how jline should come into play 14:54
i guess the intent was to use jline, but later the common nqp functionality have been utilized for that, thus leaving java's implementation dead 14:56
15:11 vrurg left 15:28 andreios left 15:58 pmurias joined 16:34 andreios joined 16:35 andreios left 17:59 vrurg joined 18:51 pmurias left 19:13 pmurias joined
bartolin_ .tell andreios You asked about the usage of deprecated sun.misc.Unsafe in nqp-j yesterday. If I'm not mistaken that code is used by rakudo-j only (and not tested by nqp's tests). 19:23
yoleaux bartolin_: I'll pass your message to andreios.
bartolin_ also, I'm very much in favor of leaving jdk8 (and jdk9 and jdk10) behind and switching to jdk11. If I find some time next week, I'll look at github.com/perl6/nqp/pull/442 (again) and see how it works with openjdk11. 19:28
nine So....should I automatically close the precomp store's lock file after lock? Chances are that we need the file again soon to compile some other module. Only reason for closing it is to fix reproducible_builds.t on Windows. 19:30
lizmat only close it on Windows then ? 19:31
otoh, how much performance loss would we see if we always closed it?
most OS's nowadays are pretty smart about opening recently closed files nowadays ? 19:32
nine One could argue that as soon as we need to compile, the game is already over and opening one more file doesn't matter
lizmat indeed
nine Finally AppVeyor is happy, too! 19:55
ugexe praise be windows IOCP 19:58
20:08 ufobat__ joined 20:11 ufobat_ left 20:32 vrurg left 20:33 vrurg joined 20:49 MasterDuke left 20:50 Geth left 20:51 Geth joined 21:36 Kaiepi left 21:37 Kaiepi joined 21:50 robertle left 22:21 Kaiepi left 22:37 Kaiepi joined 22:39 Kaiepi left 22:40 Kaiepi joined 23:23 pmurias left 23:38 MasterDuke joined, MasterDuke left, MasterDuke 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!