00:58 colomon joined 01:53 TimToady joined 05:54 FROGGS joined
arnsholt timotimo: I suspect the static analyzer doesn't cope very well with the expression used to compute alignof. It's a bit hairy 06:21
And yeah, it doesn't cope terribly well with macros, in general
06:22 JimmyZ_ joined 06:35 JimmyZ_ joined 07:02 Ven joined 07:29 colomon joined 07:33 JimmyZ_ joined 07:40 zakharyas joined, Ven joined
jnthn moarning o/ 08:35
timotimo \o 08:40
FROGGS o/ 08:45
jnthn We've quite a lot of branches hanging around on GitHub; if folks could take a moment to clear up their unused ones, it'd be nice :) 08:47
FROGGS jnthn: I already cleaned up my branches in the last weeks/days 08:49
and I tend to delete my branches right after merging them
timotimo ah, a git pull --prune makes my local branch -a output so much smaller 08:50
the "inline-exception-fix" branch seems to stick around even though it has been cherry-picked or rebased onto master already 08:51
JimmyZ_ don't have unused one
timotimo inlining-exception-fix* 08:52
jnthn timotimo: Yes, I already pruned
arnsholt: Patches reviewed and accepted; rebasing onto master and will push :) 08:53
timotimo jnthn: anything we'll do with frame-gc-opts? 08:54
jnthn Maybe
Leave that one for now
timotimo i hoped so :)
jnthn I'm mostly after "clean up obvious ones you know are dead that are yours" :)
timotimo mhm 08:55
maybe i ought to look at merge_facts_at_phi again
dalek arVM: 7731ead | arnsholt++ | src/core/args.c:
Avoid memcpy() into a NULL pointer.
arVM: f08aa2b | arnsholt++ | src/strings/nfg.c:
Set a (previously unused) variable correctly, and use it.
arVM: 3229055 | arnsholt++ | src/core/exceptions.c:
Initialize a variable.

Previously, if `search` was NULL, f would contain garbage.
arVM: fe3657c | arnsholt++ | src/core/nativecall.c:
Initialize a variable.

If `base64_decode()` were to be sent a zero-length string (unlikely, admittedly), the length computation at the end of the function would read garbage data from the `n` array.
FROGGS timotimo: or look into udp :o)
FROGGS (you'll have a user/tester)
timotimo right 08:56
jnthn: native-ref seems to be merged, but lingers on github 08:59
08:59 kjs_ joined
dalek arVM: 73ef687 | cygx++ | src/core/exceptions. (2 files):
provide MVM_exception_throw_adhoc variants that take char pointers to free
 09:05
arVM: b777fee | jnthn++ | src/core/exceptions. (2 files):
Merge pull request #219 from cygx/cleanup-adhoc

Add mechanism to avoid leaking of C strings in MVM_exception_throw_adhoc
arnsholt jnthn: Spiffy! I'll keep digging in the reports when I have some time to spare 09:06
jnthn timotimo: I got rid of native-ref just some moments ago 09:07
Having merged #219, I opened github.com/MoarVM/MoarVM/issues/223
Which is some LHF for anybody who fancies it 09:08
dalek arVM: 989a8fa | jnthn++ | src/core/frame.c:
Avoid an (unlikely) NULL-pointer dereference.

Fixes #220.		 09:15
arnsholt timotimo: I've submitted a clang-analyzer bug for the ALIGNOF() divide by zero false positive (in case you were thinking of doing it too) 09:52
timotimo ah, good :) 09:53
11:33 Ven joined
jnthn Well, that was the dumbest thing I've done this week... 13:27
ProTip: if you're not meant to free the memory until a safe point, you can't use the memory to chain a linked list through to remember it until said safe point... :P 13:28
dalek arVM: 986a8e3 | jnthn++ | src/ (4 files):
Implement "free at next safepoint" mechanism.

The fixed size allocator provides a mechanism to free memory, with the caveat that it is only safe to do so at the next "safe point". A safe point in MoarVM is currently defined to be a point at which all threads agree they could now GC, meaning they're certainly not in the middle of reading a block of memory that another thread is going to make unreachable to new readers from this point forward.		 14:13
arVM: 7131eab | jnthn++ | src/core/fixedsizealloc.c:
Comment placement tweak.
 14:17
nwc10 jnthn: ASAN is still your friend. 14:43
but hates everyone if I export MVM_SPESH_NODELAY=1
JimmyZ_ re 986a8e, looks like line 198 and 230 is the same code? 14:44
jnthn JimmyZ_: No 14:54
198 adds to overflows, 230 to a particular bin
JimmyZ_ ah, I didn't see the last one in my phone 14:55
jnthn You could potentially factor it out a bit further 14:56
But I can just as easily imagine a future where the two diverge further as where they don't. 14:57
And premature re-use is another of those roots of all evil :)
15:05 njmurphy joined 15:17 Ven_ joined
jnthn finally digs himself into the long-needed arrays work 15:21
(Making MVMArray memory safe so you can't SEGV the VM even if you mis-use it from many threads, fixing various encapsulation breakage, sorting out sub-byte arrays, then adding a REPR for fixed size/multi-dimensional arrays...) 15:22
JimmyZ_ jnthn++
FROGGS jnthn: that sounds like fun after all :o) 15:24
JimmyZ_ someone wants to do CArray <=> MVMAarray without copy 15:26
FROGGS sure, but how shall that work? 15:27
jnthn Those are different types, you'll always need a copy there.
We can make the copy cheap (memcpy)
But maybe more deeply we should work out why people want to do said copy
Well, said non-copy... :) 15:28
FROGGS though it would be nice to return an mvmarray from nativecall if a) the array has a certain size and b) the memcpy is done in nativecall code
15:31 FROGGS[mobile] joined
JimmyZ_ well, at least they dont want to copy it in perl6 by loops 15:31
FROGGS jnthn: I think they want to easily pun a CArray + length into an Array I think
jnthn *nod*
FROGGS JimmyZ: exactly
jnthn Yeah, I've been pondering some memcpy-ish op
JimmyZ_ that would be nice. 15:32
jnthn: the rt you looked the last one is about copy by loops 😊 15:36
japhb jnthn: While you're thinking about such things, being able to use a block of native mem as directly writeable array memory would be *really* useful. Some APIs want you to request a big buffer space from the OS (or from the API), scribble over it, "hand off" the buffer to the API with no copies, and then later get control of the buffer back to read back results or to do more scribbling for another cycle. 15:42
One of the key insights of PDL was that once you've separated a matrix into a complex header and a block of RAM, you can interface to native APIs really nicely by just sharing pointer&size with the API. 15:43
(Oh, I should note that for the APIs I mentioned earlier, the RAM in question may be on e.g. a GPU card, not system RAM.) 15:46
15:49 FROGGS[mobile] joined
JimmyZ_ ...oO(a VM run on GPU) 15:58
FROGGS[mobile] I want to dig into libffi :S 16:06
nebuchadnezzar hi 16:15
jnthn o/ nebuchadnezzar
japhb: Complex header and block of RAM is very much how we've structured things so far 16:23
dinner &
17:03 FROGGS joined
japhb jnthn: \o/ 17:55
18:04 nebuchadnezzar joined
dalek arVM/openpipe3: 12245d5 | FROGGS++ | / (8 files):
remove openpipe (this op is no more)
 19:49
arVM: 46e941c | jnthn++ | lib/MAST/Nodes.nqp:
Fix precedence fail, so the code is valid Perl 6.

Well, valid NQP, in fact. An NQP bug meant we got away with this up until now.		 20:24
21:11 dalek joined 21:39 vendethiel joined
timotimo how come we have a "void *former_interactive" in our MVMIOOps? because nobody wanted to update "all the" instances where we fill that struct with stuff? 22:19
because AFAIK we don't have any ABI compatibility constraints
FROGGS timotimo: it is gone in openpipe3 22:28
&
timotimo OK 22:30
three branches with different views of what MVMIOOps is supposed to look like %)

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!