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