Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-02-11

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

All times shown according to UTC.

Time Nick Message
00:25 dalek MoarVM/native-ref: e25acbc | jnthn++ | src/core/args.c:
00:25 dalek MoarVM/native-ref: Fix arg passing unbox SEGV found by TimToady++.
00:25 dalek MoarVM/native-ref: review: https://github.com/MoarVM/MoarVM/commit/e25acbcf1a
01:08 vendethiel joined #moarvm
02:06 vendethiel joined #moarvm
02:58 vendethiel joined #moarvm
03:15 colomon joined #moarvm
03:18 colomon_ joined #moarvm
03:21 vendethiel joined #moarvm
03:49 colomon joined #moarvm
04:20 vendethiel joined #moarvm
04:43 camelia joined #moarvm
05:11 vendethiel joined #moarvm
05:40 vendethiel joined #moarvm
06:17 vendethiel joined #moarvm
06:43 vendethiel joined #moarvm
07:12 vendethiel joined #moarvm
07:42 brrt joined #moarvm
07:47 vendethiel joined #moarvm
07:54 FROGGS joined #moarvm
07:54 FROGGS o/
08:21 brrt \o
08:26 JimmyZ \o/
08:27 FROGGS ╰☻╯ # such unicode
08:27 tadzik :O
08:29 FROGGS sad that there is a white and black smiling face but no red haired smiling face
08:30 JimmyZ FROGGS: https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcQaFve9uT6iy7pn0owbkb5a7YQIqr6yzIR8V5ohOOzDV0pBu6fw
08:30 vendethiel joined #moarvm
08:30 FROGGS JimmyZ: :D
08:30 FROGGS :), even
08:33 zakharyas joined #moarvm
08:37 colomon joined #moarvm
09:35 vendethiel joined #moarvm
10:44 dalek MoarVM/native-ref: de2e72c | jnthn++ | src/6model/containers.c:
10:44 dalek MoarVM/native-ref: Use containers HLL to locate auto-box type.
10:44 dalek MoarVM/native-ref:
10:44 dalek MoarVM/native-ref: Important for maintaining native/non-native transparency.
10:44 dalek MoarVM/native-ref: review: https://github.com/MoarVM/MoarVM/commit/de2e72c204
10:55 vendethiel joined #moarvm
10:58 jnthn Ewww.
10:58 jnthn Heap corruption detected: pointer 0000000000C5B448 to past fromspace
10:58 jnthn And the infamous
10:58 jnthn Internal error: zeroed target thread ID in work pass
11:01 jnthn oh duh, I fail it
11:02 FROGGS :o(
11:05 dalek MoarVM/native-ref: 0992e50 | jnthn++ | src/6model/reprs/NativeRef.c:
11:05 dalek MoarVM/native-ref: Mark frame of a NativeRef to a lexical.
11:05 dalek MoarVM/native-ref: review: https://github.com/MoarVM/MoarVM/commit/0992e503b2
11:09 jnthn OK, with that I seem to be down to one native-ref regression. Which is...a hang. Ugh.
11:10 jnthn oh, or is it just slow
11:13 * nwc10 runs ASAN on it
11:29 ilbot3 joined #moarvm
11:29 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
11:33 nwc10 /spec/S02-types/num.t ........................................ Dubious, test returned 1 (wstat 256, 0x100)
11:33 nwc10 t/spec/S04-declarations/my.rakudo.moar ........................ Dubious, test returned 2 (wstat 512, 0x200)
11:33 jnthn Oh? I thought I had my.t clean here...
11:33 nwc10 t/spec/S32-list/pick.rakudo.moar hanging
11:33 jnthn oh, hang on
11:33 nwc10 that's current roast
11:34 jnthn oh no, all pushed
11:34 jnthn Yeah, the hang is what I'm looking at now.
11:34 nwc10 I should just kill that one to get the final results?
11:34 jnthn Yeah
11:34 jnthn It'll probably run out of RAM before finishing.
11:35 jnthn Since it's trying to make a list of length 10 ** 10000
11:35 nwc10 not ok 65 - 0xFFFFFFFFFFFFFFFF is not -1
11:35 nwc10 how much RAM would that need?
11:35 jnthn I suspect that one may be related to what I'm currently looking at.
11:35 jnthn A lot :)
11:35 jnthn See the size of the integer posted on #perl6 :P
11:36 nwc10 aha, I don't think that even the new virtualisation host currently under test here in the office has that much RAM
11:36 jnthn Yeah, it seems it ends up picking a native multi candidate when it should not.
11:37 nwc10 # Failed test 'Types in declarator sig 2/2 constrain'
11:37 nwc10 # at t/spec/S04-declarations/my.rakudo.moar line 233
11:37 nwc10 not ok 65 - native outside declarator sig 1
11:37 nwc10 # Failed test 'native outside declarator sig 1'
11:37 nwc10 # at t/spec/S04-declarations/my.rakudo.moar line 221
11:37 nwc10 # Error: Cannot unbox a type object
11:37 nwc10 not ok 66 - native outside declarator sig 2
11:37 nwc10 those are all the erros that I got that you didn't expect
12:11 dalek MoarVM/native-ref: d4b00a8 | jnthn++ | src/6model/reprs/MVMMultiCache.c:
12:11 dalek MoarVM/native-ref: Make multi-cache aware of native containers.
12:11 dalek MoarVM/native-ref:
12:11 dalek MoarVM/native-ref: It should not just go decontainerizing them as if all containers are
12:11 dalek MoarVM/native-ref: objects, otherwise it'll end up with false equivalences.
12:11 dalek MoarVM/native-ref: review: https://github.com/MoarVM/MoarVM/commit/d4b00a8b33
12:11 jnthn That deals with num.t and pick.rakudo.moar
12:36 nwc10 confirmed
12:41 vendethiel joined #moarvm
13:28 vendethiel joined #moarvm
16:36 jnthn Rakudo nom currently does 67,284,727 instructions on startup
16:36 jnthn Wait, that can't be right...
16:37 jnthn no, it's not. grr
16:41 jnthn 742,971,696 is correct number. Down from 760,773,418 last I measured, probably thanks to less to deserialize due to the mixin cache and the donaldh++ fix
16:42 FROGGS that sounds like still a lot...
16:43 FROGGS like how-the-heck-can-that-even-be-fast much
16:43 jnthn It's not fast :P
16:52 FROGGS ahh, that explains it :o)
17:08 japhb <relentlessly optimistic> Well, it's less than a billion!  That's good, right?
17:09 japhb jnthn: Are those machine (CPU) instructions?
17:13 FROGGS[mobile] joined #moarvm
17:16 jnthn japhb: Yeah, measured by callgrind
17:17 jnthn m: say 44 / 742
17:17 camelia rakudo-moar f53a94: OUTPUT«0.059299␤»
17:17 jnthn Geez. 6% of time in bind_key.
17:17 jnthn m: say 36.5 / 742
17:17 camelia rakudo-moar f53a94: OUTPUT«0.049191␤»
17:17 jnthn 5% in malloc
17:30 japhb <optimistic still> Target rich environment!
17:33 jnthn Well, we need to re-enable the lazy deserialization stuff yet too
17:33 jnthn It just needs doing at a time when I can jump on pre-comp bugs.
17:34 jnthn And for now it's more strategic that I spend my tuits hammering out implementations of the native stuff and NFG
17:36 moritz jnthn: would prototyping some NFG code in, let's say, perl 5, help you?
17:42 jnthn moritz: Not sure, perhaps so. Exploring the behavior of various operations on strings that perhaps aren't immediately obvious in behavior in an NFG context might be interesting.
17:43 jnthn moritz: Data structure design wise, the options in C and Perl 5 differ quite a bit, so I'm not sure that'd be quite so informative.
17:43 lizmat re : 4e79d840405dd2  are we sure we need to MVM_free req.ptr ?  I thought that was owned by libuv ?
17:45 jnthn lizmat: I think it's ours to free; note there's nowhere we give libuv any chance to free it.
17:46 jnthn (req is stackalloc'd)
17:46 lizmat ok, just wanted to understand why that was happening
17:47 jnthn I did do a double-take on that line when I code-reviewed the patch also. :)
17:47 jnthn But I think FROGGS++ got it right.
17:47 moritz then maybe add a comment?
17:48 lizmat actually, it was e98ea2506c3ef5492ead066dc5f93973532381c5
17:48 lizmat *argh* copy pasto
17:48 lizmat actually, it was Jimmy Zhuo
17:48 * jnthn didn't look at the commit, just remembered the code in question ;)
17:48 jnthn Oh. :)
17:48 lizmat maybe you should look at the commit then ?
17:48 lizmat just to be sure ?
17:48 * jnthn can
17:49 jnthn I don't tend to pay a huge amount of attention to who did the patch when reviewing. :)
17:50 lizmat the libuv doc states "Stores the result of uv_fs_readlink() and serves as an alias to statbuf."
17:50 lizmat I don't think we need to free statbuf ?
17:51 jnthn So, e98ea2506c3 was the original that lacked the free
17:51 jnthn And 4e79d840405 adds the free
17:51 lizmat yes
17:51 jnthn uv_fs_t req;
17:52 jnthn That's just living on the local stack
17:52 jnthn req.ptr is presumably a result we're returned from libuv
17:52 lizmat yes
17:52 jnthn So if we don't free it, and then req goes out of scope, then I'd expect we'd simply lose the pointer to it and so leak it...
17:53 lizmat well, if you put it like that
17:53 lizmat it's just that I don't see any free's for statbuf in the code either
17:54 jnthn I'm a little curious about the "alias to statbuf" thing...
17:54 lizmat well, that piqued my interest
17:55 lizmat but if it would not be allocated by MVM, would the free not fail ?
17:55 jnthn No, MVM_free is just an alias for free
17:56 lizmat ah, ok
17:56 jnthn Just reading libuv source
17:56 jnthn static ssize_t uv__fs_readlink(uv_fs_t* req) {
17:57 jnthn That's the impl for on posix-y places
17:57 jnthn In there it does...
17:57 jnthn buf = malloc(len + 1);
17:57 jnthn Later
17:57 jnthn len = readlink(req->path, buf, len);
17:57 jnthn Then
17:57 jnthn req->ptr = buf;
17:58 jnthn So, libuv is allocating that memory and returning it to us
17:58 jnthn So yeah, we're right to free it.
17:58 jnthn Was worth checking. :)
17:58 jnthn lizmat++
17:58 lizmat ok, *phew*  :-)
18:00 lizmat just so I understand: MVM_free is an alias for free
18:00 lizmat but with the intent that it can be something else for debugging, right?
18:00 jnthn Yes.
18:00 jnthn MVM_malloc is the more interesting one
18:01 jnthn It delegates to malloc
18:01 jnthn But then does a NULL check
18:01 jnthn So we don't have to do that everywhere else.
18:01 lizmat shouldn't this then not be a "free" rather than an MVM_free ?
18:01 lizmat otherwise you might get unmatching MVM_alloc / MVM_free ?
18:02 jnthn lizmat: Yes, that'd be reasonable enough.
18:02 jnthn We don't have a particularly strong policy there yet, though, I'm afraid.
18:02 lizmat hmmm... ok, so I should leave it ?
18:03 jnthn When MVM_malloc/MVM_realloc came (which do check for NULL), MVM_free came along with them, and we got s/free/MVM_free/
18:03 jnthn lizmat: Maybe it's best until we figure out some clearer policy on it.
18:03 lizmat ah, so there could be more MVM_free's that should really just be free()
18:03 lizmat ok
18:03 jnthn lizmat: If we do decide we really want that then there'll be a bunch of places to change.
18:03 lizmat ok
18:08 jnthn The other thing is that while *in theory* you might want to use it to hook in debugging stuff, these days it feels unlikely.
18:08 lizmat ok
18:09 jnthn On Linux there's easy access to ASAN and Valgrind, which dynamically replace malloc. On OSX you inject their debug malloc in lldb by setting an env var. Similar story with the MSVC toolchain.
18:40 FROGGS joined #moarvm
18:44 lizmat hmmm... could there be a leak in file ops on Moar?
18:44 lizmat the file ops, like .d, use MVM_file_stat
18:44 lizmat the check for IS_DIR is done by calling file_info()
18:45 lizmat file_info returns req.statbuf
18:45 lizmat which is used directly in MVM_file_stat thus:
18:45 lizmat case MVM_STAT_ISDIR:              r = (file_info(tc, filename).st_mode & S_IFMT) == S_IFDIR; break;
18:45 lizmat shouldn't we then free the return value of file_info() ??
18:47 lizmat jnthn FROGGS JimmyZ ^^^  opinions?
18:57 jnthn lizmat: req.statbuf.st_size
18:57 jnthn Note it's all ., not ->
18:58 lizmat but file_info returns req.statbuf
18:58 lizmat ah, by value
18:59 jnthn Yeah
18:59 lizmat ok, *phew*
18:59 jnthn And we do . to access it too
18:59 jnthn So by value
18:59 jnthn So looks good to me
18:59 lizmat ok
18:59 lizmat bit rusty on my C, but getting there  :-)
19:00 lizmat hmm... I just realized that the current nqp::start, should really be called nqp::lstat
19:00 lizmat *nqp::stat
19:00 jnthn Does it call lstat underneath?
19:00 lizmat because file_info does a uv_fs_lstat
19:00 lizmat rather than a uv_fs_stat
19:00 lizmat yup
19:00 jnthn ah
19:01 lizmat I guess I could throw in an extra parameter to indicate stat vs lstat ?
19:02 jnthn I'd rather go with two ops
19:02 lizmat two ops at the nqp level
19:02 jnthn Yeah
19:02 lizmat which would mean basically copy file_info and MVM_file_stat
19:03 jnthn But inside of Moar we can do it as a flag if it saves copy-paste code :)
19:03 lizmat ok
19:03 lizmat that looks like a plan then...  :-)
19:04 lizmat will probably cause some spectest breakage
19:04 lizmat because "stat" will become the uv_fs_stat case
19:04 lizmat what is the preferred way of passing a bool in Moar?
19:04 jnthn Well, unless we decide to lstat in some places we currently stat in Rakudo of course
19:05 jnthn Just use an integer
19:05 jnthn MVMint32 is fine enough
19:06 FROGGS lizmat: rurban++ also said that the stat we expose is actually lstat, so you agree
19:07 lizmat yeah  :-)
19:40 btyler joined #moarvm
19:55 zakharyas joined #moarvm
20:01 zakharyas1 joined #moarvm
20:58 tgt joined #moarvm
21:20 lizmat jnthn: what does it mean if I find e.g. an "exists_f" op in the src/core/oplist, but no associated nqp::exists_f op in nqp ?
21:20 lizmat would that imply an obsolete op?
21:22 jnthn lizmat: Sounds like
21:23 lizmat ok, so I just leave it for now?
21:23 jnthn lizmat: I'm in the middle of some...fun...refactors, mebbe you could file a MoarVM issue on github?
21:23 lizmat ok, will do
21:23 lizmat once I'm done with my lstat/stat refactor  :-)
21:23 jnthn Thanks :)
21:33 lizmat Set of changes to MoarVM: https://gist.github.com/lizmat/47b01056f84d40539df2
21:34 colomon joined #moarvm
21:36 jnthn lizmat: Hmm...are isreadable/iswritable/isexecutable used? Seems they are just cases stat/lstat can cover too?
21:36 FROGGS lizmat: hint: you can only change the signature of an op if it is *not* used in nqp's stage1
21:37 lizmat jnthn: lemme check
21:37 jnthn FROGGS: I didn't see that happen anywhere?
21:38 jnthn FROGGS: The changes in interp.c just pass something extra to the implementation of the op...
21:38 lizmat yes, to keep the current behaviour
21:39 FROGGS jnthn: ohh, good point then :o)
21:39 jnthn So that bit's fine.
21:39 FROGGS lizmat: btw, you are reformatting my nicely formatted code there :P
21:39 FROGGS yeah
21:39 lizmat well, I was reading Joel on Software lately  :-)
21:40 lizmat http://www.joelonsoftware.com/articles/Wrong.html
21:40 jnthn Yes, a case that doesn't declare any variables doesn't really need the curlies
21:40 jnthn At least, that's how we have it in most places :)
21:40 lizmat ok, so you want me to change that back?
21:40 lizmat fine by me...
21:41 lizmat I felt it became more readable
21:41 jnthn Well, I'd be fine with a line break after the case ...:
21:41 jnthn And the break on a line of its own
21:41 lizmat ok
21:41 jnthn But don't need loads of whitespace and braces all over, imho :)
21:42 * jnthn notes that he has to work with a larger font than many folks, so is a tad more sensitive on vertical spreading than most :)
21:42 lizmat ok, fair enough
21:42 lizmat hadn't thought of that  :-(
21:42 lizmat should have  :-(
21:42 jnthn Don't worry, I'm not going to reject the patch 'cus of it :P
21:43 jnthn A little consistency across a codebase can ease reading, though.
21:44 jnthn Anyway, it looks good overall
21:48 lizmat updated the gist for the {} removal
21:49 lizmat hmmm... I have trouble building nqp with the locally changed moar
21:49 lizmat using --with-moar, should I point to the moar executable ?
21:50 jnthn I think that should do it
21:52 lizmat hmm.... the freshly compiled moar states it is 2015.01-23-ga7b842c
21:52 lizmat while git describe says
21:52 lizmat 2015.01-31-g79171dc
21:52 jnthn I think we call git describe during Configure, not in each make.
21:52 lizmat ah
21:52 lizmat that could be it  :-)
21:56 lizmat ok, clean test on nqp
21:57 lizmat ok for me to bump Moar / NQP revision ?
21:57 jnthn lizmat: Sure, if Rakudo builds on it :)
21:59 lizmat not sure how I can build rakudo with a local NQP
22:00 lizmat --with-nqp doesn't work  :-)
22:00 jnthn I always just --prefix=...path to install dir...
22:01 lizmat thanks  :-)
22:04 FROGGS_ joined #moarvm
22:06 lizmat rakudo spectest clean (except for 2 known flappers) so going to bump
22:08 dalek MoarVM: 0ee65f4 | lizmat++ | src/ (3 files):
22:08 dalek MoarVM: Add flag to switch between stat/lstat
22:08 dalek MoarVM:
22:08 dalek MoarVM: Many file ops now use stat, rather than lstat as before.  This in preparation
22:08 dalek MoarVM: for an nqp::lstat op to be added in the near future.
22:08 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/0ee65f40a7
22:27 lizmat hmmm.... seems my change broke .IO.l (always false at the moment)
22:27 lizmat will sleep on this and provide a fix somehow tomorrow
22:28 lizmat (which was actually not caught by nqp tests (on my machine) or rakudo spec tests :-(
22:28 lizmat good night, #moarvm  :-)
22:28 TimToady sweet dreams
22:32 jnthn 'night, lizmat
22:39 colomon joined #moarvm
23:05 vendethiel joined #moarvm

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