00:24 btyler joined 00:30 btyler joined
[Coke] m: say Order::Decrease 00:54
camelia rakudo-moar fc4943: OUTPUT«Could not find symbol '&Decrease'␤ in method <anon> at src/gen/m-CORE.setting:12877␤ in any find_method_fallback at src/gen/m-Metamodel.nqp:2604␤ in any find_method at src/gen/m-Metamodel.nqp:934␤ in block at /tmp/7egrdnNexb:1␤␤»
[Coke] we have tests for Order::Decrease in roast. Anyone object to me removing them? 00:55
TimToady well, they're deprecation tests, but perhaps Decrease has been sufficiently deprecated 01:36
n: say 23 cmp 22 01:38
camelia niecza v24-109-g48a8de3: OUTPUT«More␤»
[Coke] the spec tests shouldn't be testing things we had once but have since removed. 01:49
they should be testing the spec. 01:50
02:03 FROGGS joined
nwc10 good *, * 06:29
sergot o/ 06:45
06:57 FROGGS joined
FROGGS uff: moar: double free or corruption 07:01
github.com/coke/perl6-roast-data/b....out#L1766 07:02
nwc10 ASAN already found that one, and jnthn knows about it 07:03
paste.scsys.co.uk/406590 07:04
I don't know how to fix it
FROGGS ahh, nice :o)
nwc10 but it's an out of bound write
FROGGS oob write... interesting O.o
dalek MoarVM/nativecast: a4cdc2d | jnthn++ | src/spesh/inline.c: 07:09
MoarVM/nativecast: Fix merging of inline table entries.
MoarVM/nativecast:
MoarVM/nativecast: Need to add offsets to return address deopt location, locals, and
MoarVM/nativecast: lexicals.
07:10 dalek joined
FROGGS nwc10: is such a union inlined in the struct? github.com/MoarVM/MoarVM/blob/mast...del.h#L143 07:31
nwc10 in which struct? I'm a bit confused. That union is within the header common to every GC'able 07:36
FROGGS I'm just asking how such a struct like MVMCollectable lives in memory... 07:39
is sizeof(MVMCollectable) == sizeof(uint32 + uint16 + uint16 + void*)? 07:40
nwc10 the union is there, so it's sizeof(uint32 + uint16 + uint16 + 07:41
void * + void *)
FROGGS or: sizeof(MVMCollectable) == sizeof(uint32 + uint16 + uint16 + sizeof(sc_forward_u))?
nwc10 you're missing the MVMStable* at the end
oh, no I'm confused
you're right
it's what you said
and I *thought* I had enough coffee
FROGGS okay, so such a union in a struct is represented as a pointer... k 07:42
thank you :o)
nwc10 no. wait
the struct *is* inline. But it's carefully chosen so that all the parts of it aren't larger than a pointer
FROGGS hmmmm 07:43
nwc10 struct MVMSerializationIndex *sci; is a pointer to a struct 07:44
struct { MVMuint16 sc_idx; MVMuint16 idx; } sc;
is a struct
which, "oh dear" is the same size as a pointer
FROGGS aha
nwc10 (32 bit systems)
FROGGS I love Perl 6: gist.github.com/FROGGS/79fe3fcf799724fa6106 07:50
vendethiel (people making us love Perl 6)++ 07:51
jnthn morning o/ 08:23
FROGGS: That's evil! :P
I had hoped one of my earlier fixes had nailed paste.scsys.co.uk/406590 but apparently not... 08:25
FROGGS jnthn: no, that's awesome :o) 08:30
jnthn The two aren't mutually exclusive :)
FROGGS that means that you can work around gc bugs by fiddling with the memory directly :P 08:31
(from within perl)
jnthn o.O 08:33
FROGGS *g*
I guess it would be impressive to draw a memory map (using svg) of an object in the same program and show that at a conference... 08:35
jnthn True 08:39
Only problem is if it moves :P
FROGGS yeah, you have to be quick *g* 08:40
jnthn: by the way, I going to merge nativecast in MoarVM/nqp/zavolaj today in case there is no intervention from your side :o)
jnthn FROGGS: OK; going to be busy for the day on a $dayjob project. 08:41
sergot Can I use us__stream_fd somehow in moar? 09:52
uv__stream_fd() *
jnthn The double-underscore means it's private to libuv, no? 09:56
09:57 teodozjan joined
sergot jnthn: sounds reasonable, I don't know libuv well. 10:02
yet :) 10:03
jnthn So, it's preferable not to use those things, because as soon as we update libuv...it could break.
sergot jnthn: I really need to get IO::Socket's fd somewhere, any ideas how can I do this? 10:06
It's easy for syncfile, but what about syncsocket? 10:07
jnthn What do you need it for? 10:10
sergot For my openssl gsoc stuff, there is an openssl function SSL_set_fd($ssl, $fd), and.. I need to pass a $fd here 10:12
So, moritz suggested to write nqp op nqp::getfdfromfh or something and I'm struggling with it now 10:13
anyway, for now I just want to printf a fd of my socket on creating it 10:14
I tried getting fd from $!PIO (which is MVMOSHandle) but it's not so easy for sockets (it's much easier for files)
vendethiel is watching www.youtube.com/watch?v=FGgFMZhnXvU ... interesting jit stuff 10:16
jnthn sergot: The library is going to want to read/write using the fd, I guess? 10:23
sergot jnthn: yes 10:24
timotimo the lower parts of jnthns benchmark run are quite interesting, i find 10:25
jnthn I'm a little concerned how both libuv and openssl thinking they own the same fd will work out...
Also whether we have any hope of obtaining the underlying fd on, say, the JVM...
timotimo we're quite faster than perl5 at rational numbers, that's good 10:26
jnthn And whether using the BIO API described in www.ibm.com/developerworks/opensour...index.html and letting OpenSSL manage the whole thing, if we're using it, could be wise...
timotimo and apparently we're faster than perl5 with rational numbers, too?
er, imaginary numbers 10:27
sergot jnthn: you're right 10:31
hmm
FROGGS: what do you think?
FROGGS sergot: I think we should perhaps let openssl manage the connection if we can't obtain the fd easily 10:33
jnthn It's not just about obtaining the fd
FROGGS and then we provide a subclass of IO::Socket::INET
jnthn: yes, true
jnthn It's that libuv will likely have set it up expecting to do async IO stuff with it. 10:34
It may work out, it just feels rather fragile. 10:35
FROGGS yeah, I guess you are right...
sergot: I think I'd make the bindings to openssl, and then expose tls ops like tls_readfh and tls_socket that take the same arguments as the non tls ops that nqp provides atm 10:38
sergot: the you can easily port IO::Socket::INET to use these ops
timotimo why can't we just be doing async io on openssl sockets? :3
FROGGS sergot: the benefit of implementing ops like tls_readfh is that you know in detail what it gets and what it should do 10:40
jnthn timotimo: Looks like openssl can do non-blocking too
timotimo oh, neat 10:41
jnthn But it seems it wants to "own" the connection
timotimo understandably
well, how do the node.js people do ssl?
sergot FROGGS: ok 10:42
jnthn ooh, good question
FROGGS sergot: unless jnthn can propose a better way of doing it...
jnthn Well, seeing how nodejs.org/api/tls.html is done may be interesting 10:43
FROGGS I guess I have to play with openssl before I can say more on this topic
that document is indeed very informative 10:45
jnthn github.com/joyent/node/blob/master...ls_wrap.js may also be worth a look 10:49
dalek arVM: 0054a6a | sergot++ | / (8 files):
MVM_nativecall_cast added

MVM_nativecall_cast has been added which provides casting an OpaquePointer to any type we want. It makes us able to unpack things conditionally.		 10:54
arVM: 6fda5ad | (Tobias Leich)++ | src/core/nativecall.c:
fix bogus declaration (copy&pasto)
MoarVM: 55187a1 | (Tobias Leich)++ | / (6 files):
MoarVM: add box target parameter to nativecallcast
MoarVM:
MoarVM: This op now gets a param that says something about the bit size we are
tadzik \o/ 10:55
10:58 dalek joined 11:31 brrt joined
brrt \o moarning 11:31
jnthn good (UGT :)) moarning, brrt o/ 11:32
brrt :-)
jnthn whoa, that's some heavy rain...
FROGGS hi brrt
jnthn: here too
brrt here yesterday
FROGGS at least it is starting to get heavy
jnthn Had some thunder too 11:33
brrt i figured that - for now - we'd be in trouble if the last instruction in the graph was an invoke instruction (i.e., a tail call without return) 11:34
jnthn I think by contract code must end with a return. 11:35
brrt and that i'd compile this somewhat differently from a 'regular' invoke, even if the next instruction is a return, because in that case there is at least a label to jump to
jnthn To the degree the bytecode assembler inserts one if it's missing
And presumably the validator whines if it's missing.
brrt ok, very well
anyway, i could suppose that in some cases we might optimize it to a tail call directly, but in that case that will likely be a spesh op, so i'll handle that separately 11:36
i.e. if you know you can tail call then i suppose you can also compile a jump 11:39
jnthn *nod* 11:43
That's an opt for later, though :)
FROGGS I wonder what normal ppl think what a tail call optimization is... 11:45
jnthn I'm not sure normal people think about things like that... :P 11:46
FROGGS hehe 11:47
that might be totaily true :P 11:48
brrt yes, it is, lets not get ahead with the moving targets just yet
jnthn Yeah. It'd be rather nice if the JIT could, for example, do its magic on some of the benchmarks. And we need invoke support and OSR for that. :) 11:49
brrt :-) benchmarks are important 11:50
timotimo is there much left for OSR in the jit part? i thought it'd be only a tiny bit of work on top of the spesh OSR? 12:06
brrt i don't know about that... i'm not sure how OSR works in moar
12:08 cognominal joined
brrt bbiab 12:10
12:22 jnap joined 12:31 nwc10_ joined, _sri joined 12:34 brrt joined
[Coke] (order decrease, whoops I was in the wrong channel when I started that convo) 12:59
13:20 woolfy joined 13:32 lizmat joined 13:33 btyler joined 13:42 zakharyas joined
brrt vendethiel - thanks for that link 14:33
vendethiel++ :-)
cognominal vendethiel++ # itou 14:40
dalek arVM/moar-jit: e528d54 | (Bart Wiegmans)++ | / (3 files):
Add sp_getspeshslot
 15:15
arVM/moar-jit: 2b2fd45 | (Bart Wiegmans)++ | src/ (6 files):
Refactor addresses to call args

The JIT never used addresses as addresses and only ever as call args. Call arguments have quite different features from addresses; importantly, they care about the difference between floating point and integer numbers.
brrt long story short, invocation is invovled
FROGGS what does that mean? 15:18
15:21 ssutch joined
brrt there are a /lot/ of unimplemented ops that have to be done before i can get to invocation proper 15:21
FROGGS ahh, okay :o) 15:22
brrt one of which is, for example, smart numify, which needed the address of a register as an argument
i hadn't done that yet, but now i have
another is current callsite
i.e. prepargs
FROGGS does that mean that you can jit partial stuff atm, but when something gets invoked this branch will not be jitted? 15:23
I have problems imagining how that works... 15:24
brrt no, i can't JIT partial frames, and won't be able to :-) 15:25
i try to construct a JIT graph partially, and if i encounter something that doesn't work, i bail out
FROGGS okay, so when a frame contains an invocation, the frame won't be jitted 15:27
brrt exactly
FROGGS okay, understand
brrt now the invocation itself is already pretty complex
but it's doable, right? 15:28
but there are so many things that come before it
FROGGS hehe, I have no idea :o)
brrt well, it's bascially setting pointers and calling MVM_frame_invoke 15:29
FROGGS that sounds indeed doable :o)
brrt it's doable but complex
FROGGS bbi15
brrt ok, see you then 15:30
jnthn brrt: I'd put smart numify off until *after* invocation, as it may invoke. 15:33
brrt oh... really?
hmmm
that
jnthn Yeah. There are a few things like this.
brrt is annoying 15:34
:-)
ok, i'll disable smart numify for now then
jnthn But really a call consists of prepargs, arg* ops (which are just stores), and an invoke of some kind at the end.
brrt uhuh 15:35
i'm thinking i probably should put cur_callsite into a non-volatile register 15:36
that, or collapse the whole of prepargs, arg*, invoke into a single node
hmm
i'm not against that idea at all, now that i think of it
how about you? 15:37
or does it often happen that there are conditionals between the arg* staments?
jnthn I don't think that's allowed 15:39
As in, think the validator refuses it at the moment.
I'm almost certain we never emit it
The call code-gen just does prepargs arg*,
brrt ok, i can always bail compilation in the worst case 15:40
and in the best case, i can actually represent the conditionals in the tree - but that's far from now
jnthn Also note that there's 7 arg instructiosn only. 4 of them (reg to arg) are probably identical at assembly level. 15:41
argconst_s is the only slightly more intresting one. 15:42
15:42 FROGGS joined
brrt yes, i see 15:43
jnthn You may want to factor what prepargs does out into a function, fwiw
which returns the callsite
brrt nods 15:44
but i'm going to make dinner now
jnthn (and have interp.c call that too)
brrt nods again :-)
jnthn The piece that'll need more work is the invoke itself.
brrt fastinvoke isn't very complex 15:45
but i suppose not very common, either
jnthn It has the same structural issue as any invoke.
Which is, invoke today assumes interpreter semantics.
brrt as in, we need to jump out of jit to the interpreter? 15:46
jnthn No
Just that we need to refactor how invoke works to know about JIT
At present it returns nothing
brrt uhuh
what would you like it to return, then? i'm not totally following i think 15:47
jnthn When called from JIT land it needs to (a) know it doesn't need to do the setting up of the JIT thunk, and (b) return to the JIT the address of the JITted code to jump to
That's when it's a JIT -> JIT call
brrt oh, i see 15:48
jnthn The other case is JIT -> interpreter, which I guess could be signaled with a NULL being returned.
brrt or, we could ignore that case for now, and live with the fact that this isn't ideal in terms of speedup
jnthn And then the thing you already have - the mechanism for the JIT to return to the interpreter but say "don't actually call the return thing" - comes into play.
Oh, and always fall back to the interpreter, and then re-enter the JIT?
brrt yes 15:49
jnthn Oh.
brrt ugly, i agree
jnthn Yeah, that actually does work for a first cut.
brrt but i see what you mean wrt to jit->jit calls
how we can speed that up
jnthn Yeah. Feel free to skip the smart thing initially.
But it's an "obvious" optimization.
brrt in a way, the frame_invoke 'knows' the current frame is in JIT by the virtue of there being jit code and a 'jit continuation 15:50
i'll note it and write it down :-)
jnthn Especially as for hot call paths the jump from JITted code should get branch prediction love. :)
brrt i'd hope so :-) 15:51
see you in a few hours :-) 15:52
jnthn Happy cooking/nomming :) o/
15:52 brrt left 15:59 carlin joined 16:10 btyler_ joined
vendethiel typo here : github.com/MoarVM/MoarVM/commit/2b...2a5090bd9f "arugments" 16:14
timotimo oooh jitted invocations ♥ 16:46
tadzik aww yiss 17:05
timotimo well, they're not here yet
but at least we have someone who knows how it can be implemented later 17:06
17:52 lue joined
vendethiel (people knowing)++ 18:05
dalek arVM/moar-jit: 148bde3 | (Bart Wiegmans)++ | src/jit/graph.c:
Remove smart_numify support because it might invoke
 19:05
[Coke] 440 warnings building moar. 20:07
FROGGS [Coke]: using clang?
[Coke] er, scratch that, but many.
FROGGS: aye: Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) 20:08
FROGGS would be a nice LHF for someone you has such a compiler 20:09
who has*
[Coke] here's a chunk of them: gist.github.com/coke/bda800a830e6f653b4fc
added some rakudo build warnings also. 20:20
did a || build on rakudo-moar, saw this:
perl -MExtUtils::Command -e cp perl6-m perl6 20:21
The following step can take a long time, please be patient.
/Users/willcoleda/sandbox/rakudo/install/bin/moar --libpath="/Users/willcoleda/sandbox/rakudo/install/languages/nqp/lib" perl6.moarvm --setting=NULL --ll-exception --optimi
isn't that copy a bit premature?
guessing we're missing some deps.
jnthn manages to keep Moar and Rakudo builds warning-free on MSVC, and would be very happy to see that championed by others for different compilers 20:26
FROGGS jnthn: gcc is warning free also, due to masak++'s latest patch 20:27
jnthn ah, cool
I'd not remember that being noisy either
So, just clang is, well, clanging... :) 20:28
[Coke] I can take a look, but IANACP.
jnthn Me either, by clang's reckoning... 20:31
rurban if the code will pass -fsanitize=undefined we could safely use -O3 then 20:40
parrot already is, but nqp not
22:34 jnap1 joined 22:38 cognominal 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!