00:34 dalek joined 01:48 FROGGS_ joined 02:21 raiph joined
raiph maybe of interest in years to come: "deterministic garbage collection algorithm that supports RAII (initialism) directly, evenin the case of recursive graphs of objects" www.reddit.com/r/ProgrammingLangua...ollection/ 02:27
06:29 rurban_ joined 07:03 zakharyas joined
jnthn wonders what trade-offs it makes to do that :) 08:28
konobi there was that memory allocation and gc paper from a while back 08:35
nine The programming language uses atomic reference counts along with an algorithm that detects and identifies the unique set of objects in a recursive graph of objects by performing graph scans in real-time, and then, when the last reference from an object outside the graph is removed (meaning that there are only references from objects that participate in the graph), the object being dereferenced is then destroyed, which causes a chain reaction which causes all obj 09:20
from the paper's announcement
jnthn heh, atomic reference counts :)
We ripped those out of MoarVM last month :)
Interesting idea, though. 09:21
(The real-time graph scans, I mean) 09:22
10:43 retupmoca joined 10:59 colomon joined 11:06 cognominal joined 11:35 rurban_ joined
lizmat jnthn: is there a reason we don't have any nqp::inc_i($a) / nqp::dec_i($b) ops ? 11:49
(basically providing prefix ++ and --_ 11:50
)
I was just wondering
jnthn Various reasons, among them working out what they should actually do :) 11:58
Note that they'd want to update their arg, but the way you want the do that in NQP vs Perl 6 aren't the same
Then it's not clear if pre or post inc/dec semantics are wanted 11:59
lizmat to me, pre inc semantics are clear :-) 12:05
jnthn That's 'cus it's what you want at the moment :P
lizmat true 12:06
jnthn The "how should they even work2 is the bigger issue though.
lizmat ok, I got an answer :-)
it just felt like such an omission to me
and having them (in whatever way) would prove to be an easier optimization target, no ?
jnthn "It's complicated" :) 12:07
Note that it'd need to care about, say, attributes too 12:08
Where you need to compile it into a read/add/write
So it'd need case analysis to compile
lizmat ok, in my limited view, nqp::inc_i() would ever only take native ints
jnthn What's a native int? :) 12:09
lizmat ok, gotcha :-)
jnthn Or more to the point: if it only *takes*, then it can't update :)
That's why it gets tricky
lizmat I guess I was just thinking it essentially takes a pointer and does an inc there :-)
jnthn Well, it "could" by demanding an Int*Ref 12:10
Then we'd not like that and so end up trying to special-case it in various cases :)
lizmat ok, I get the "it's complicated" :-) 12:11
jnthn I guess the kicker really being that, after all that work, it's not entirely clear that post-JIT we'd have better code anyway. :-) 12:12
nwc10 or even post-spesh?
jnthn Or possibly that
13:05 domidumont joined 13:10 cognominal joined
dalek arVM: 27fccc1 | (Will Coleda)++ | build/ (2 files):
Smoke me/spaceybuild (#375)

Make build in dir containing space work		 13:21
nwc10 [Coke]: sorry, no, I didn't test that earlier. I slack 13:26
I have now. It works.
Thanks
[Coke] no worries. 13:31
13:35 colomon joined 14:12 cognominal joined
timotimo this is an interesting crash 14:56
0x00007ffff7959557 in MVM_spesh_osr (tc=0x6037c0) at src/spesh/osr.c:46
46 if (!tc->cur_frame->params.callsite->is_interned)
(gdb) print tc->cur_frame->params 14:57
$3 = {callsite = 0x0, arg_flags = 0x0, args = 0x0, named_used = 0x0, named_used_size = 0, arg_count = 0,
num_pos = 0, flag_count = 0}
i can easily put a null check in there, but what's the actual meaning of .params being completely nulled out?
jnthn Sounds rather busted
Outdated pointer maybe?
timotimo (gdb) print MVM_dump_backtrace(tc) 14:58
at <unknown>:1 (/home/timo/perl6/install/share/perl6/runtime/CORE.setting.moarvm:count-only)
from gen/moar/m-CORE.setting:13144 (/home/timo/perl6/install/share/perl6/runtime/CORE.setting.moarvm:elems)
from triangle-numbers.p6:9 (<ephemeral file>:)
i can try running it in valgrind to see if it messes with some data
that'll take forever, of course. 14:59
jnthn yeah
That should probably never be NULL for something on the call stack...
timotimo valgrind only reports the invalid read that also triggers the segfault, it seems like 15:36
15:51 domidumont joined 16:14 rurban_ joined 17:34 patrickz joined 17:38 raiph joined 18:00 cognominal joined 19:16 FROGGS joined 20:01 zakharyas joined 20:57 raiph left
timotimo www.youtube.com/watch?v=P3AyI_u66Bw - "removing the python GIL"; someone's working on a project called "gilectomy" (used to be "Confuse-A-Cat"), and it looks interesting 21:41
it seems like that approach adds one user-space lock per list, and per dict, and so on 21:44
ouch. atomic incr and decr on every single object 21:53
makes it incredibly slow compared to cpython with the gil
arnsholt timotimo: Yeah, that's the problem with removing the GIL 22:38
The CPython team look pretty committed to refcounting for the GC, both since having the implementation internals being simple is a goal for them as well as the fact that breaking *all* of the C extensions would be pretty crap 22:39
timotimo that's also explained in that very talk :) 22:46
arnsholt Yeah, he covers it very well 22:55
It'll be interesting to see what they come up with to kill off the GIL
timotimo yup 22:56
arnsholt I think they'll probably figure it out eventually, but I am pretty curious how they're going to do it
timotimo yeah 23:05
i wish pypy's STM effort would have gotten further by now
or even by last year. or two years ago.
before i came over to perl6 i was quite the pypy fanboy :) 23:06
and i still think their project is just absolutely awesome
i do find rakudo a bit simpler to develop for, though
at least by now :D
rpython had some really difficult to figure out failure modes 23:07
or maybe i was just an expert at messing up in all different kinds of ways
arnsholt PyPy is awesome 23:15
It saved my skin on some Python code a while back
Actually, one of the PyPy devs dropped by #perl6 at some point, trying to convince us that Rakudo should've targetted rpython rather than JVM/Moar 23:16
timotimo well, i kind of asked him about advice
arnsholt Ah, right 23:18

Powered by Cro and the Raku® Programming Language.

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

Thank you!