dalek arVM/native-ref: e25acbc | jnthn++ | src/core/args.c:
Fix arg passing unbox SEGV found by TimToady++.
 00:25
01:08 vendethiel joined 02:06 vendethiel joined 02:58 vendethiel joined 03:15 colomon joined 03:18 colomon_ joined 03:21 vendethiel joined 03:49 colomon joined 04:20 vendethiel joined 04:43 camelia joined 05:11 vendethiel joined 05:40 vendethiel joined 06:17 vendethiel joined 06:43 vendethiel joined 07:12 vendethiel joined 07:42 brrt joined 07:47 vendethiel joined 07:54 FROGGS joined
FROGGS o/ 07:54
brrt \o 08:21
JimmyZ \o/ 08:26
FROGGS ╰☻╯ # such unicode 08:27
tadzik :O
FROGGS sad that there is a white and black smiling face but no red haired smiling face 08:29
JimmyZ FROGGS: encrypted-tbn0.gstatic.com/images?...zDV0pBu6fw 08:30
08:30 vendethiel joined
FROGGS JimmyZ: :D 08:30
:), even
08:33 zakharyas joined 08:37 colomon joined 09:35 vendethiel joined
dalek arVM/native-ref: de2e72c | jnthn++ | src/6model/containers.c:
Use containers HLL to locate auto-box type.

Important for maintaining native/non-native transparency.		 10:44
10:55 vendethiel joined
jnthn Ewww. 10:58
Heap corruption detected: pointer 0000000000C5B448 to past fromspace
And the infamous
Internal error: zeroed target thread ID in work pass
oh duh, I fail it 11:01
FROGGS :o( 11:02
dalek arVM/native-ref: 0992e50 | jnthn++ | src/6model/reprs/NativeRef.c:
Mark frame of a NativeRef to a lexical.
 11:05
jnthn OK, with that I seem to be down to one native-ref regression. Which is...a hang. Ugh. 11:09
oh, or is it just slow 11:10
nwc10 runs ASAN on it 11:13
11:29 ilbot3 joined
nwc10 /spec/S02-types/num.t ........................................ Dubious, test returned 1 (wstat 256, 0x100) 11:33
t/spec/S04-declarations/my.rakudo.moar ........................ Dubious, test returned 2 (wstat 512, 0x200)
jnthn Oh? I thought I had my.t clean here...
nwc10 t/spec/S32-list/pick.rakudo.moar hanging
jnthn oh, hang on
nwc10 that's current roast
jnthn oh no, all pushed 11:34
Yeah, the hang is what I'm looking at now.
nwc10 I should just kill that one to get the final results?
jnthn Yeah
It'll probably run out of RAM before finishing.
Since it's trying to make a list of length 10 ** 10000 11:35
nwc10 not ok 65 - 0xFFFFFFFFFFFFFFFF is not -1
how much RAM would that need?
jnthn I suspect that one may be related to what I'm currently looking at.
A lot :)
See the size of the integer posted on #perl6 :P
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.
nwc10 # Failed test 'Types in declarator sig 2/2 constrain' 11:37
# at t/spec/S04-declarations/my.rakudo.moar line 233
not ok 65 - native outside declarator sig 1
# Failed test 'native outside declarator sig 1'
# at t/spec/S04-declarations/my.rakudo.moar line 221
# Error: Cannot unbox a type object
not ok 66 - native outside declarator sig 2
those are all the erros that I got that you didn't expect
dalek arVM/native-ref: d4b00a8 | jnthn++ | src/6model/reprs/MVMMultiCache.c:
Make multi-cache aware of native containers.

It should not just go decontainerizing them as if all containers are objects, otherwise it'll end up with false equivalences.		 12:11
jnthn That deals with num.t and pick.rakudo.moar
nwc10 confirmed 12:36
12:41 vendethiel joined 13:28 vendethiel joined
jnthn Rakudo nom currently does 67,284,727 instructions on startup 16:36
Wait, that can't be right...
no, it's not. grr 16:37
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:41
FROGGS that sounds like still a lot... 16:42
like how-the-heck-can-that-even-be-fast much 16:43
jnthn It's not fast :P
FROGGS ahh, that explains it :o) 16:52
japhb <relentlessly optimistic> Well, it's less than a billion! That's good, right? 17:08
jnthn: Are those machine (CPU) instructions? 17:09
17:13 FROGGS[mobile] joined
jnthn japhb: Yeah, measured by callgrind 17:16
m: say 44 / 742 17:17
camelia rakudo-moar f53a94: OUTPUT«0.059299␤»
jnthn Geez. 6% of time in bind_key.
m: say 36.5 / 742
camelia rakudo-moar f53a94: OUTPUT«0.049191␤»
jnthn 5% in malloc
japhb <optimistic still> Target rich environment! 17:30
jnthn Well, we need to re-enable the lazy deserialization stuff yet too 17:33
It just needs doing at a time when I can jump on pre-comp bugs.
And for now it's more strategic that I spend my tuits hammering out implementations of the native stuff and NFG 17:34
moritz jnthn: would prototyping some NFG code in, let's say, perl 5, help you? 17:36
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:42
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 ?
jnthn lizmat: I think it's ours to free; note there's nowhere we give libuv any chance to free it. 17:45
(req is stackalloc'd) 17:46
lizmat ok, just wanted to understand why that was happening
jnthn I did do a double-take on that line when I code-reviewed the patch also. :) 17:47
But I think FROGGS++ got it right.
moritz then maybe add a comment?
lizmat actually, it was e98ea2506c3ef5492ead066dc5f93973532381c5 17:48
*argh* copy pasto
actually, it was Jimmy Zhuo
jnthn didn't look at the commit, just remembered the code in question ;)
Oh. :)
lizmat maybe you should look at the commit then ?
just to be sure ?
jnthn can
I don't tend to pay a huge amount of attention to who did the patch when reviewing. :) 17:49
lizmat the libuv doc states "Stores the result of uv_fs_readlink() and serves as an alias to statbuf." 17:50
I don't think we need to free statbuf ?
jnthn So, e98ea2506c3 was the original that lacked the free 17:51
And 4e79d840405 adds the free
lizmat yes
jnthn uv_fs_t req;
That's just living on the local stack 17:52
req.ptr is presumably a result we're returned from libuv
lizmat yes
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...
lizmat well, if you put it like that 17:53
it's just that I don't see any free's for statbuf in the code either
jnthn I'm a little curious about the "alias to statbuf" thing... 17:54
lizmat well, that piqued my interest
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
lizmat ah, ok 17:56
jnthn Just reading libuv source
static ssize_t uv__fs_readlink(uv_fs_t* req) {
That's the impl for on posix-y places 17:57
In there it does...
buf = malloc(len + 1);
Later
len = readlink(req->path, buf, len);
Then
req->ptr = buf;
So, libuv is allocating that memory and returning it to us 17:58
So yeah, we're right to free it.
Was worth checking. :)
lizmat++
lizmat ok, *phew* :-)
just so I understand: MVM_free is an alias for free 18:00
but with the intent that it can be something else for debugging, right?
jnthn Yes.
MVM_malloc is the more interesting one
It delegates to malloc 18:01
But then does a NULL check
So we don't have to do that everywhere else.
lizmat shouldn't this then not be a "free" rather than an MVM_free ?
otherwise you might get unmatching MVM_alloc / MVM_free ?
jnthn lizmat: Yes, that'd be reasonable enough. 18:02
We don't have a particularly strong policy there yet, though, I'm afraid.
lizmat hmmm... ok, so I should leave it ?
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
lizmat: Maybe it's best until we figure out some clearer policy on it.
lizmat ah, so there could be more MVM_free's that should really just be free()
ok
jnthn lizmat: If we do decide we really want that then there'll be a bunch of places to change.
lizmat ok
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
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:09
18:40 FROGGS joined
lizmat hmmm... could there be a leak in file ops on Moar? 18:44
the file ops, like .d, use MVM_file_stat
the check for IS_DIR is done by calling file_info()
file_info returns req.statbuf 18:45
which is used directly in MVM_file_stat thus:
case MVM_STAT_ISDIR: r = (file_info(tc, filename).st_mode & S_IFMT) == S_IFDIR; break;
shouldn't we then free the return value of file_info() ??
jnthn FROGGS JimmyZ ^^^ opinions? 18:47
jnthn lizmat: req.statbuf.st_size 18:57
Note it's all ., not ->
lizmat but file_info returns req.statbuf 18:58
ah, by value
jnthn Yeah 18:59
lizmat ok, *phew*
jnthn And we do . to access it too
So by value
So looks good to me
lizmat ok
bit rusty on my C, but getting there :-)
hmm... I just realized that the current nqp::start, should really be called nqp::lstat 19:00
*nqp::stat
jnthn Does it call lstat underneath?
lizmat because file_info does a uv_fs_lstat
rather than a uv_fs_stat
yup
jnthn ah
lizmat I guess I could throw in an extra parameter to indicate stat vs lstat ? 19:01
jnthn I'd rather go with two ops 19:02
lizmat two ops at the nqp level
jnthn Yeah
lizmat which would mean basically copy file_info and MVM_file_stat
jnthn But inside of Moar we can do it as a flag if it saves copy-paste code :) 19:03
lizmat ok
that looks like a plan then... :-)
will probably cause some spectest breakage 19:04
because "stat" will become the uv_fs_stat case
what is the preferred way of passing a bool in Moar?
jnthn Well, unless we decide to lstat in some places we currently stat in Rakudo of course
Just use an integer 19:05
MVMint32 is fine enough
FROGGS lizmat: rurban++ also said that the stat we expose is actually lstat, so you agree 19:06
lizmat yeah :-) 19:07
19:40 btyler joined 19:55 zakharyas joined 20:01 zakharyas1 joined 20:58 tgt joined
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
would that imply an obsolete op?
jnthn lizmat: Sounds like 21:22
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?
lizmat ok, will do
once I'm done with my lstat/stat refactor :-)
jnthn Thanks :)
lizmat Set of changes to MoarVM: gist.github.com/lizmat/47b01056f84d40539df2 21:33
21:34 colomon joined
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
lizmat jnthn: lemme check 21:37
jnthn FROGGS: I didn't see that happen anywhere?
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
FROGGS jnthn: ohh, good point then :o) 21:39
jnthn So that bit's fine.
FROGGS lizmat: btw, you are reformatting my nicely formatted code there :P
yeah
lizmat well, I was reading Joel on Software lately :-)
www.joelonsoftware.com/articles/Wrong.html 21:40
jnthn Yes, a case that doesn't declare any variables doesn't really need the curlies
At least, that's how we have it in most places :)
lizmat ok, so you want me to change that back?
fine by me...
I felt it became more readable 21:41
jnthn Well, I'd be fine with a line break after the case ...:
And the break on a line of its own
lizmat ok
jnthn But don't need loads of whitespace and braces all over, imho :)
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
hadn't thought of that :-(
should have :-(
jnthn Don't worry, I'm not going to reject the patch 'cus of it :P
A little consistency across a codebase can ease reading, though. 21:43
Anyway, it looks good overall 21:44
lizmat updated the gist for the {} removal 21:48
hmmm... I have trouble building nqp with the locally changed moar 21:49
using --with-moar, should I point to the moar executable ?
jnthn I think that should do it 21:50
lizmat hmm.... the freshly compiled moar states it is 2015.01-23-ga7b842c 21:52
while git describe says
2015.01-31-g79171dc
jnthn I think we call git describe during Configure, not in each make.
lizmat ah
that could be it :-)
ok, clean test on nqp 21:56
ok for me to bump Moar / NQP revision ? 21:57
jnthn lizmat: Sure, if Rakudo builds on it :)
lizmat not sure how I can build rakudo with a local NQP 21:59
--with-nqp doesn't work :-) 22:00
jnthn I always just --prefix=...path to install dir...
lizmat thanks :-) 22:01
22:04 FROGGS_ joined
lizmat rakudo spectest clean (except for 2 known flappers) so going to bump 22:06
dalek arVM: 0ee65f4 | lizmat++ | src/ (3 files):
Add flag to switch between stat/lstat

Many file ops now use stat, rather than lstat as before. This in preparation for an nqp::lstat op to be added in the near future.		 22:08
lizmat hmmm.... seems my change broke .IO.l (always false at the moment) 22:27
will sleep on this and provide a fix somehow tomorrow
(which was actually not caught by nqp tests (on my machine) or rakudo spec tests :-( 22:28
good night, #moarvm :-)
TimToady sweet dreams
jnthn 'night, lizmat 22:32
22:39 colomon joined 23:05 vendethiel 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!