Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2017-05-29

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
01:48 ilbot3 joined #moarvm
01:48 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
02:18 Zoffix zostay: what version are you on?
02:18 zostay whatever rakudobrew installed for me a couple hours ago
02:20 Zoffix Which is what? perl6 -v
02:20 zostay 2017.05-25-g62bc54
02:20 zostay er
02:20 zostay 2017.05-25-g62bc54e
02:21 Zoffix zostay: I mean perl6 compiler version
02:21 zostay This is Rakudo version 2017.05-286-ga47a78f built on MoarVM version 2017.05-25-g62bc54e
02:23 * Zoffix upgrades to check if the problem is there.
02:28 Zoffix zostay: what did you run to cause that error?
02:29 Zoffix zef look HTTP::UserAgent; NETWORK_TESTING=1 prove6; passes all tests for me
02:29 Zoffix On 2017.05-286-ga47a78f built on MoarVM version 2017.05-25-g62bc54e
02:31 zostay ok, i believe it's the installation of HTTP::UserAgent followed by URI from my branch (https://github.com/zostay/uri/tree/mutators) and then zef install HTTP::UserAgent chokes... let me make sure that alone is enough because i installed a bunch of other deps as well which might also be involved somehow
02:40 Zoffix Reproed. "Probable version skew in pre-compiled '/home/zoffix/.zef/store/http-useragent.git/4742f91fcd30c511e5063ddc934d02ddc493c2c4/lib/HTTP/MediaType.pm6 (HTTP::MediaType)' (cause: no object at index 4850)"
02:42 Zoffix rm -fr ~/.zef; rm -fr ~/.perl6; rm -fr ~/.rakudobrew/; git clone https://github.com/tadzik/rakudobrew ~/.rakudobrew; rakudobrew build moar; rakudobrew build zef; zef look HTTP::UserAgent; zef --depsonly install .; NETWORK_TESTING=1 prove -e "perl6 -Ilib" -vr; zef install https://github.com/zostay/uri/archive/mutators.zip; NETWORK_TESTING=1 prove -e "perl6 -Ilib" -vr;
02:44 Zoffix interesting... `zef uninstall URI; zef install https://github.com/zostay/uri/archive/mutators.zip` and now its install fails for unknown reason: https://gist.github.com/zoffixznet/cf273ec2732d1cee8c8382a0fb0c8225
02:45 zostay awesome... thx for the confirmation
02:46 Zoffix nine: any ideas? ^ :)
02:47 * Zoffix builds 2017.05 to see if issue exists there
03:00 Zoffix Yup.
04:34 Geth ¦ MoarVM/fix_leak: 6ca991ab82 | (Jimmy Zhuo)++ | 2 files
04:34 Geth ¦ MoarVM/fix_leak: fixed some memory leak
04:34 Geth ¦ MoarVM/fix_leak: review: https://github.com/MoarVM/MoarVM/commit/6ca991ab82
04:35 Geth ¦ MoarVM: zhuomingliang++ created pull request #605: fixed some memory leaks
04:35 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/605
04:36 JimmyZ brrt: maybe this helps
04:37 committable6 joined #moarvm
06:23 domidumont joined #moarvm
06:27 domidumont joined #moarvm
06:50 nebuchadnezzar joined #moarvm
06:59 Geth ¦ MoarVM/fix_leak: a38cc9610d | (Jimmy Zhuo)++ | src/io/syncpipe.c
06:59 Geth ¦ MoarVM/fix_leak: fixed a memory leak
06:59 Geth ¦ MoarVM/fix_leak: review: https://github.com/MoarVM/MoarVM/commit/a38cc9610d
07:09 domidumont joined #moarvm
08:12 Geth ¦ MoarVM/fix_leak: 239c615311 | (Jimmy Zhuo)++ | 2 files
08:12 Geth ¦ MoarVM/fix_leak: fixed a memory leak
08:12 Geth ¦ MoarVM/fix_leak: review: https://github.com/MoarVM/MoarVM/commit/239c615311
08:17 brrt joined #moarvm
08:17 brrt good * #moarvm
08:18 brrt i've uncovered that there's some more code difference than I saw in the sp_fastcreate bit, especially, the subsequent sp_p6obind_o looks a bit weird
08:18 brrt i've been thinking of two possible solutions, and i'm not sure which of these i like best
08:19 brrt well, that's not true
08:19 brrt i do know which one  i like the best
08:20 brrt so I know that there is a problem with stashing pointers to objects on 'unwalked' locations on the local variable buffer
08:20 brrt (i allocate extra memory, but don't mark the values as object pointers, so they aren't walked by the GC)
08:20 brrt there are basically two solutions and a hybrid
08:46 jnthn Is that for when you have to spill?
08:51 brrt yes
08:51 brrt solution A): when some template code might cause an allocation, we flush the variables that are generated at template generation time, this ensure that there are no cross-template references to old pointers
08:51 brrt the problem is that there may well be intra-template references to old pointers, so all is not great
08:51 Geth ¦ MoarVM: 239c615311 | (Jimmy Zhuo)++ | 2 files
08:51 Geth ¦ MoarVM: fixed a memory leak
08:51 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/239c615311
08:51 Geth ¦ MoarVM: 6d9de8d217 | (Jonathan Worthington)++ (committed using GitHub Web editor) | 2 files
08:51 Geth ¦ MoarVM: Merge pull request #605 from MoarVM/fix_leak
08:51 Geth ¦ MoarVM:
08:51 Geth ¦ MoarVM: fixed some memory leaks
08:51 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/6d9de8d217
08:52 jnthn brrt: Probably easier to just tell the GC where they are...
08:52 jnthn I'd hope spilling is relatively rare
08:53 brrt i was coming to that, as a matter of fact :-)
08:55 brrt solution B): track which values are object pointers and use the (relatively new) spesh temporary register allocation code to find spill space (rather than just increment the top thing as I do now)
08:55 brrt that is a much better solution, but it requires tracking which values are object values… that is only partially obvious
08:56 brrt part of solution A is still necessary, fwiw
08:56 brrt which brings me to the hybrid solution
08:57 brrt *currently* whenever I need to spill something to memory, I take no heed whatsoever if that value is 'backed' by a previously existing register
08:58 brrt I kind of need to figure that out anyway
08:58 brrt if it is already 'backed' by that (moarvm) register / 'local frame variable', surely it is just as well to insert a load back from that register
08:58 brrt that would take care of most issues automatically
08:58 jnthn Yeah, that'd be cheaper
08:58 jnthn You could use that tracking to not spill constants too, presumably?
08:59 brrt i think so, yes
08:59 brrt i was originally thinking of making that part of the optimizer
09:00 brrt we can also do it in the register allocator, i.e. detect if something comes from a const, and if so, just 'copy' the tile rather than insert a load-and-spill
09:00 brrt that one is presumably easier to do
09:00 jnthn Wouldn't doing it at allocation time perhaps eliminate needing to spill altogether in some cases?
09:06 brrt hang on, allocation of registers you mean?
09:06 brrt i'm actually not 100% sure what will be involved with that
09:07 brrt having said that
09:07 brrt tracking which things are objects and which are not, that's something is that i'm fairly sure we'll need anyway
09:08 lizmat .oO( isn't everything an object)
09:09 jnthn I meant knowing that's a constant
09:09 nine lizmat: native ints and floats are not
09:09 yoleaux 28 May 2017 18:48Z <Zoffix> nine: getting weird Failures about symbols in GTK::Simpler checkout. Seem to occur only when .new on looked up symbol is given args. Does it look like an issue with Rakudo? https://irclog.perlgeek.de/perl6/2017-05-28#i_14649906
09:09 jnthn If it's a constant you don't even have to spill it at all, and can consider the register vacant
09:09 * brrt nods
09:10 brrt at register allocation time, that's probably the most robust way to do it
09:10 nine CPointers aren't either
09:11 brrt go ahead nine, unmake my day :-P
09:11 nine what? who? why?
09:11 brrt CPointers are not object pointers, indeed
09:12 brrt so now the job of tracking 'is this an object pointer' has become more hard
09:13 brrt but in a slightly whimsical way, of course a native integer is an object
09:13 brrt it's just one with a radically different protocol than other objects
09:23 brrt so yeah, i've got my work cut out for me again :-)
09:40 zakharyas joined #moarvm
10:11 jnthn joined #moarvm
10:30 Geth ¦ MoarVM: 7fd9a82128 | (Jimmy Zhuo)++ | 5 files
10:30 Geth ¦ MoarVM: remove unused args
10:30 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/7fd9a82128
10:30 Geth ¦ MoarVM: f53265f27a | (Jimmy Zhuo)++ | 5 files
10:30 Geth ¦ MoarVM: Merge branch 'remove_unsed_args'
10:30 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/f53265f27a
10:51 travis-ci joined #moarvm
10:51 travis-ci MoarVM build errored. Jimmy Zhuo 'Merge branch 'remove_unsed_args''
10:51 travis-ci https://travis-ci.org/MoarVM/MoarVM/builds/237117629 https://github.com/MoarVM/MoarVM/compare/6d9de8d2177b...f53265f27a47
10:51 travis-ci left #moarvm
11:04 timotimo we did it
11:04 timotimo we reached 10 minutes of compile time for interp.c on clang
11:07 brrt wth
11:08 timotimo actually, it's most probably not that
11:08 timotimo since other clang builds took only like 12 minutes for moar + nqp
11:10 timotimo it's still amusing
11:10 timotimo i don't know what made it hang. probably just a fluke
11:11 brrt istr ESR making noise about 'clang being better than GCC in every relevant way'
11:11 brrt thereby demonstrating the seriousness of ESR's technical judgements
11:11 timotimo pff, compile times are irrelevant
11:11 timotimo also, we're using a clang version that's pretty much ancient
11:14 brrt compile times are so not irrelevant, ask any scala developer, or any go developer
11:18 timotimo or the perl6 devs
11:21 timotimo *cough* core setting *cough*
11:23 nwc10 but how often do people compile the core set... oh, wait, wrong channel
11:23 nwc10 (at two levels)
11:28 domidumont joined #moarvm
11:28 timotimo i hate when it's hard to go from a project name + version number to "when was it released"
11:30 brrt joined #moarvm
11:30 brrt joined #moarvm
12:18 domidumont joined #moarvm
12:53 brrt joined #moarvm
13:58 brrt joined #moarvm
15:10 brrt joined #moarvm
15:40 brrt okay, my 'there is a gc run inbetween' theory is clearly disproved
15:48 brrt my new theory
15:49 brrt '$rdx contains something funky, what's up with that'
15:49 AlexDaniel joined #moarvm
15:53 brrt hmm
15:53 brrt $rdx seems to contain a legit value...
15:59 brrt okay,
15:59 brrt the replaced bit is set to a the STable value
16:00 brrt that's odd..
16:00 brrt almost as if the problem is really with sp_p6obind_o...
16:38 dalek joined #moarvm
16:42 brrt joined #moarvm
16:44 SourceBaby joined #moarvm
17:45 timotimo are you following the p6o_real_body and accidentally pretending that's a gc managed pointer?
18:45 greppable6 joined #moarvm
19:13 domidumont joined #moarvm
19:56 lizmat and another Perl 6 Weekly hits the Net: https://p6weekly.wordpress.com/2017/05/29/2017-22-up-handle-encoding/
19:59 robertle joined #moarvm
20:26 jnthn lizmat++ # weekly
21:38 AlexDaniel joined #moarvm
21:59 greppable6 joined #moarvm
22:11 timotimo "suffering from buffering" <3
22:18 Util joined #moarvm

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary