Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-06-19

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

All times shown according to UTC.

Time Nick Message
00:58 colomon joined #moarvm
01:53 TimToady joined #moarvm
05:54 FROGGS joined #moarvm
06:21 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 arnsholt And yeah, it doesn't cope terribly well with macros, in general
06:22 JimmyZ_ joined #moarvm
06:35 JimmyZ_ joined #moarvm
07:02 Ven joined #moarvm
07:29 colomon joined #moarvm
07:33 JimmyZ_ joined #moarvm
07:40 zakharyas joined #moarvm
07:40 Ven joined #moarvm
08:35 jnthn moarning o/
08:40 timotimo \o
08:45 FROGGS o/
08:47 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:49 FROGGS jnthn: I already cleaned up my branches in the last weeks/days
08:49 FROGGS and I tend to delete my branches right after merging them
08:50 timotimo ah, a git pull --prune makes my local branch -a output so much smaller
08:51 timotimo 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
08:52 timotimo inlining-exception-fix*
08:52 jnthn timotimo: Yes, I already pruned
08:53 jnthn arnsholt: Patches reviewed and accepted; rebasing onto master and will push :)
08:54 timotimo jnthn: anything we'll do with frame-gc-opts?
08:54 jnthn Maybe
08:54 jnthn Leave that one for now
08:54 timotimo i hoped so :)
08:54 jnthn I'm mostly after "clean up obvious ones you know are dead that are yours" :)
08:55 timotimo mhm
08:55 timotimo maybe i ought to look at merge_facts_at_phi again
08:55 dalek MoarVM: 7731ead | arnsholt++ | src/core/args.c:
08:55 dalek MoarVM: Avoid memcpy() into a NULL pointer.
08:55 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/7731ead5b4
08:55 dalek MoarVM: f08aa2b | arnsholt++ | src/strings/nfg.c:
08:55 dalek MoarVM: Set a (previously unused) variable correctly, and use it.
08:55 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/f08aa2ba29
08:55 dalek MoarVM: 3229055 | arnsholt++ | src/core/exceptions.c:
08:55 dalek MoarVM: Initialize a variable.
08:55 dalek MoarVM:
08:55 dalek MoarVM: Previously, if `search` was NULL, f would contain garbage.
08:55 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/3229055df9
08:55 dalek MoarVM: fe3657c | arnsholt++ | src/core/nativecall.c:
08:55 dalek MoarVM: Initialize a variable.
08:55 dalek MoarVM:
08:55 FROGGS timotimo: or look into udp :o)
08:55 dalek MoarVM: If `base64_decode()` were to be sent a zero-length string (unlikely,
08:55 dalek MoarVM: admittedly), the length computation at the end of the function would read
08:55 dalek MoarVM: garbage data from the `n` array.
08:55 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/26f0f7db4b
08:55 FROGGS (you'll have a user/tester)
08:56 timotimo right
08:59 timotimo jnthn: native-ref seems to be merged, but lingers on github
08:59 kjs_ joined #moarvm
09:05 dalek MoarVM: 73ef687 | cygx++ | src/core/exceptions. (2 files):
09:05 dalek MoarVM: provide MVM_exception_throw_adhoc variants that take char pointers to free
09:05 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/73ef687fc2
09:05 dalek MoarVM: b777fee | jnthn++ | src/core/exceptions. (2 files):
09:05 dalek MoarVM: Merge pull request #219 from cygx/cleanup-adhoc
09:05 dalek MoarVM:
09:05 dalek MoarVM: Add mechanism to avoid leaking of C strings in MVM_exception_throw_adhoc
09:05 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/b777fee2e0
09:06 arnsholt jnthn: Spiffy! I'll keep digging in the reports when I have some time to spare
09:07 jnthn timotimo: I got rid of native-ref just some moments ago
09:07 jnthn Having merged #219, I opened https://github.com/MoarVM/MoarVM/issues/223
09:08 jnthn Which is some LHF for anybody who fancies it
09:15 dalek MoarVM: 989a8fa | jnthn++ | src/core/frame.c:
09:15 dalek MoarVM: Avoid an (unlikely) NULL-pointer dereference.
09:15 dalek MoarVM:
09:15 dalek MoarVM: Fixes #220.
09:15 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/989a8fad1a
09:52 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:53 timotimo ah, good :)
11:33 Ven joined #moarvm
13:27 jnthn Well, that was the dumbest thing I've done this week...
13:28 jnthn 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
14:13 dalek MoarVM: 986a8e3 | jnthn++ | src/ (4 files):
14:13 dalek MoarVM: Implement "free at next safepoint" mechanism.
14:13 dalek MoarVM:
14:13 dalek MoarVM: The fixed size allocator provides a mechanism to free memory, with
14:13 dalek MoarVM: the caveat that it is only safe to do so at the next "safe point". A
14:13 dalek MoarVM: safe point in MoarVM is currently defined to be a point at which all
14:13 dalek MoarVM: threads agree they could now GC, meaning they're certainly not in the
14:13 dalek MoarVM: middle of reading a block of memory that another thread is going to
14:13 dalek MoarVM: make unreachable to new readers from this point forward.
14:13 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/986a8e3ef8
14:17 dalek MoarVM: 7131eab | jnthn++ | src/core/fixedsizealloc.c:
14:17 dalek MoarVM: Comment placement tweak.
14:17 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/7131eab520
14:43 nwc10 jnthn: ASAN is still your friend.
14:43 nwc10 but hates everyone if I export MVM_SPESH_NODELAY=1
14:44 JimmyZ_ re 986a8e, looks like line 198 and 230 is the same code?
14:54 jnthn JimmyZ_: No
14:54 jnthn 198 adds to overflows, 230 to a particular bin
14:55 JimmyZ_ ah, I didn't see the last one in my phone
14:56 jnthn You could potentially factor it out a bit further
14:57 jnthn But I can just as easily imagine a future where the two diverge further as where they don't.
14:57 jnthn And premature re-use is another of those roots of all evil :)
15:05 njmurphy joined #moarvm
15:17 Ven_ joined #moarvm
15:21 * jnthn finally digs himself into the long-needed arrays work
15:22 jnthn (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++
15:24 FROGGS jnthn: that sounds like fun after all :o)
15:26 JimmyZ_ someone wants to  do CArray <=> MVMAarray without copy
15:27 FROGGS sure, but how shall that work?
15:27 jnthn Those are different types, you'll always need a copy there.
15:27 jnthn We can make the copy cheap (memcpy)
15:27 jnthn But maybe more deeply we should work out why people want to do said copy
15:28 jnthn 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 #moarvm
15:31 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
15:31 jnthn *nod*
15:31 FROGGS JimmyZ: exactly
15:31 jnthn Yeah, I've been pondering some memcpy-ish op
15:32 JimmyZ_ that would be nice.
15:36 JimmyZ_ jnthn: the rt you looked the last one is about copy by loops 😊
15:42 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:43 japhb 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:46 japhb (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:49 FROGGS[mobile] joined #moarvm
15:58 JimmyZ_ ...oO(a VM run on GPU)
16:06 FROGGS[mobile] I want to dig into libffi :S
16:15 nebuchadnezzar hi
16:15 jnthn o/ nebuchadnezzar
16:23 jnthn japhb: Complex header and block of RAM is very much how we've structured things so far
16:23 jnthn dinner &
17:03 FROGGS joined #moarvm
17:55 japhb jnthn: \o/
18:04 nebuchadnezzar joined #moarvm
19:49 dalek MoarVM/openpipe3: 12245d5 | FROGGS++ | / (8 files):
19:49 dalek MoarVM/openpipe3: remove openpipe (this op is no more)
19:49 dalek MoarVM/openpipe3: review: https://github.com/MoarVM/MoarVM/commit/12245d5570
20:24 dalek MoarVM: 46e941c | jnthn++ | lib/MAST/Nodes.nqp:
20:24 dalek MoarVM: Fix precedence fail, so the code is valid Perl 6.
20:24 dalek MoarVM:
20:24 dalek MoarVM: Well, valid NQP, in fact. An NQP bug meant we got away with this up
20:24 dalek MoarVM: until now.
20:24 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/46e941c097
21:11 dalek joined #moarvm
21:39 vendethiel joined #moarvm
22:19 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 timotimo because AFAIK we don't have any ABI compatibility constraints
22:28 FROGGS timotimo: it is gone in openpipe3
22:28 FROGGS &
22:30 timotimo OK
22:30 timotimo three branches with different views of what MVMIOOps is supposed to look like %)

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