github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
timotimo not a single spectest trips the oops 00:54
00:55 Kaiepi left
Geth MoarVM: MasterDuke17++ created pull request #1038:
Add smrt intify op		 01:27
MasterDuke that one wasn't too bad. rakudo won't be terrible either, but nqp... 01:46
02:18 Kaiepi joined 02:26 Kaiepi left 02:44 AlexDani` joined 02:45 AlexDaniel left 03:14 Kaiepi joined 03:18 lizmat left 03:50 ufobat_ joined 03:54 ufobat left 04:08 AlexDani` is now known as AlexDaniel 04:14 Kaiepi left 04:17 Kaiepi joined 04:43 Kaiepi left 04:44 Kaiepi joined 06:51 domidumont joined 07:27 domidumont1 joined 07:31 domidumont left 07:54 patrickb joined 07:59 patrickb left 08:57 scovit joined
scovit Hello, how do you free a MVMObject in MoarVM? Or hint it to be GCed? 08:58
09:00 lizmat joined 09:21 zakharyas joined 09:42 robertle joined
jnthn scovit: You don't explicitly free them 10:06
scovit: The GC does a reachability analysis each time it runs, and anything not reachable is freed
The only way to make that happen sooner is to trigger GC; there's an op for that 10:07
lizmat jnthn: can you explain the difference between these two: 10:39
m: dd Array.HOW; Array.^compose; dd Array.HOW
camelia (Perl6::Metamodel::ClassHOW+{<anon>} without .perl method)
Perl6::Metamodel::ClassHOW+{<anon>}+{<anon>}.new
lizmat it looks like .^compose is mixing in yet another role ?
is Array not composed then ?? 10:40
jnthn Hmm, interesting 10:42
No, though I wonder if Array has any metamethods?
(method ^foo() { })
lizmat it has a ^parameterize
jnthn If I remember correctly, those get mixed in at compose time
lizmat this is about R#2640
synopsebot R#2640 [open]: github.com/rakudo/rakudo/issues/2640 [⚠ blocker ⚠] Some sort of regression in Red module
jnthn And it's possible it does it repeatedly 10:43
As in, once per .^compose call
lizmat m: Array.^compose for ^10; dd Array.HOW # looks like it 10:44
camelia Perl6::Metamodel::ClassHOW+{<anon>}+{<anon>}+{<anon>}+{<anon>}+{<anon>}+{<anon>}+{<anon>}+{<anon>}+{<anon>}+{<anon>}+{<anon>}.new
jnthn lol
Nice
Yeah, probably we want to somehow drain those at compose time
lizmat this seems to fix R#2640 10:45
synopsebot R#2640 [open]: github.com/rakudo/rakudo/issues/2640 [⚠ blocker ⚠] Some sort of regression in Red module
lizmat # temporary fix for R#2640
+BEGIN .^compose for Set,SetHash,Bag,BagHash,Mix,MixHash;
in core_epilogue 10:46
but that feels like a bandaid
jnthn: the only reason to allow multiple ^compose calls, is augment right ? 10:51
perhaps augment should reset the $!composed flag, and have ^compose be a noop if the $!composed flag is set ?
:q 10:52
jnthn I'm not sure what would be recomposing it 10:54
Certainly all of .^compose should not be a no-op 11:10
lizmat datapoint: not doing anything in compose if the class is already composed, breaks the setting 11:11
jnthn That's no surprise
It means it would totally ignore every augmented in method, and the setting is built out of augments
lizmat then what use is composing an already composed class ?
ok
but shouldn't an augment then not reset the $!composed flag ? 11:12
and *then* do nothing if already composed ?
jnthn There's nothing in the MOP API for that, not to mention that there's already lots of code that just calls things like .^add_method followed by .^compose in the wild 11:13
I'd just look for where it applies the meta-methods and see if we can discard them at compose time after mixing them in, so we won't repeat it next time around 11:14
lizmat well, I guess add_method should reset the flag as well then ?
jnthn No, because then you have to do this in numerous methods
lizmat and what would be against that ? 11:15
jnthn I don't know why you're trying to change the entire way the API works when there's a single specific problem to solve
lizmat I'm not sure either... I thought I found an LTA situation that could be fixed 11:16
jnthn Sure, it can be, by doing what I'm suggesting.
See Perl6::Metamodel::MetaMethodsContainer 11:17
lizmat ok, thanks for the hints 11:18
jnthn I suggest adding a %!uncomposed_meta_methods hash, have add_meta_method poke them in to that, and then have compose_meta_methods read from that
Alternatively, we can just have a flag and not allow one to augment in further metamethods 11:19
lizmat nah, the first suggestion seems better and more flexible
11:33 MasterDuke left 11:55 brrt joined
scovit jnthn: thanks, I am looking at the object res.o in static char callback_handler, for how long it's content will be reachable? 12:01
in other words, what holds its reference? 12:07
jnthn Well, we're invoking user code there, so in general we can't know if that code stashes a reference somewhere that keeps it alive. But if it's just a return value, then it doesn't look like the code in callback_handler references it any further 12:08
Also it doesn't root it in callback_handler, and just relies on the code not itself triggering GC :) 12:09
So technically it could be unreachable after MVM_interp_run, and we just rely on nothing else that follows entering GC 12:10
scovit then I wonder if also the C function that get the return value might get invalid pointers if the object got GCd? 12:20
for instance when we pass it the pointer of a vmarray in MVM_nativecall_unmarshal_vmarray 12:21
jnthn If another thread was to trigger GC while that C code was running, then yes
scovit is it a bug?
jnthn Well, what can we do about it?
scovit copy all the objects 12:22
jnthn That sounds rather costly
scovit also it might be a leak
jnthn Right
That too
I don't think it's reasonable to expect to write C bindings without at least some knowledge of memory management 12:23
In this case, I'd probably make sure that whatever I return remains referenced for long enough.
But we can't in general know what "long enough" means
Sometimes copy might be a good behavior, and we could offer it too
scovit I am playing with the idea of a is copy trait, but I was doing it for CStruct passed and received by value. 12:24
jnthn Yeah, I guess it'd be applying to the callback's return value here 12:25
lunch, bbiab 12:26
scovit that would make it become a more general concept, in that case "is copy" alone would not be enough for the "passing by value" stuff
ok, good lunch!
lizmat m: class A { method ^a() {} } # looks like this isn't actually calling ^compose anywhere 12:36
camelia ( no output )
lizmat hmmm... or? 12:37
12:44 zakharyas left 12:49 brrt left 12:59 domidumont joined 13:02 domidumont1 left
jnthn At compile time on the closing } it would 13:18
13:23 brrt joined 13:28 lucasb joined 14:18 zakharyas joined
brrt \o 15:02
nwc10 o/ 15:09
jnthn o/ 15:12
brrt of all pieces of the JIT, I'm by far least fond of the register allocator 15:32
timotimo can we just have it all done by the google cloud or something 15:33
brrt hehe
POST cloud.google.com/simple-register-a...rch=x86-64
jnthn RAaaS 15:34
brrt funny how we never call things 'enterprise' anymore
jnthn I'm sure we can get funded
:P
brrt ..oO( Machine Learning optimized register allocation. On the blockchain! ) 15:35
jnthn I'm sure some things still do get called "enterprise", but I think the "enterprisey means it's crap" meme kinda killed it off. :)
brrt hehe
speaking of which, I had a half-assed plan to write a testing tool for MoarVM that'd directly build spesh graphs from a description. With s-expressions of course. 15:36
So the name of this tool should be 'meme'
timotimo excuse me, why would it be "meme"? 15:37
brrt moarvm scheme
timotimo ooh
jnthn haha 15:38
Nice 15:39
timotimo what makes it more interesting to create spesh graphs than to simply create moar bytecode and have it turned to a spesh graph by the usual method? 15:40
easier to connect BBs and place handlers maybe?
than to work with labels?
brrt I want to circumvent the whole usual process, is the thing. That's why it'd be a testing tool 15:41
timotimo OK
brrt Maybe add a way to specify facts 15:42
timotimo ooh, to go *that* deep into the internals
brrt pretty much
is this a decent GSoC project, or is it too small?
(I don't care that much about the s-expr syntax, so a student could choose something else) 15:43
timotimo all i know is projects are always bigger than you expect ;)
15:43 domidumont1 joined
brrt this is true 15:46
15:46 domidumont left
jnthn I think being able to write unit tests for spesh and JIT would be very helpful 15:48
Of course we cover a huge amount with the NQP and Perl 6 test suite 15:49
brrt this is true. The problem is more that I never quite know which parts are tested 15:53
I kind of just hope for the best
jnthn The whole approach of spesh is to record stats and hpoe for the best :P 15:55
timotimo true
jnthn But yeah, it's true
Probably there's coverage tools that can tell us a bit more
timotimo with more specific tests we can check not only "it doesn't blow up" and "it doesn't misbehave", but also "it does the optimization i was hoping for"
which will also allow us to see what effects a new optimization has, for example to prevent other kinds 15:56
though it needs more context for that purpose
for those tests i suppose it'd be enough to run it through spesh and not code-gen and run the code
which lets us have much more self-contained pieces of code
hm. it's the old unit test vs integration test thing again 15:57
brrt yeah. We solely do integration tests, from the perspective of spesh
timotimo right. but only the first two kinds i've mentioned earlier 15:58
brrt jnthn: is our GC concurrent, or is it parallel?
or is it both...
jnthn Parallel 15:59
timotimo concurrent GC would be a *great* GSoC project!! 16:00
jnthn Ouch :)
brrt heheeh 16:05
nwc10 for some value of summer, possibly Neptune's
brrt I'm not sure if neptune has a an orbital inclination 16:07
timotimo right, i think there's only a small number of planets in our solar system that do
brrt inclination is actually not the word I'm looking for 16:08
16:16 robertle left
nwc10 I checked. 30 degrees, apparently 16:17
16:41 domidumont1 left 16:42 zakharyas left
AlexDaniel nwc10: haha 17:23
17:45 robertle joined
robertle ls 17:57
sorry
18:09 Kaiepi left 18:13 Kaiepi joined 18:16 brrt left, brrt joined 18:28 Kaiepi left 18:29 Kaiepi joined 19:09 Kaiepi left, Kaiepi joined 19:15 Kaiepi left 19:22 Kaiepi joined
AlexDaniel robertle: a directory with just one file named “sorry”? :) 19:27
19:28 Kaiepi left 19:29 Kaiepi joined 19:35 lizmat left 19:46 brrt left 20:12 brrt joined 20:21 AlexDani` joined 20:23 AlexDaniel left 20:29 lizmat joined 20:52 AlexDani` left 20:53 AlexDani` joined 21:13 AlexDani` is now known as AlexDaniel 21:17 brrt left 21:58 lucasb left 22:02 sivoais 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!