00:14 hohoho joined 00:36 tokuhirom joined 01:34 vendethiel joined 01:45 tokuhirom joined 02:25 colomon joined 02:43 colomon joined 03:43 tokuhirom joined 05:02 FROGGS[mobile] joined 05:45 tokuhirom joined 06:18 FROGGS[mobile]2 joined 06:37 FROGGS joined 06:46 tokuhirom joined 07:34 leont joined 08:01 zakharyas joined 08:02 FROGGS joined 08:37 sivoais joined 08:47 sivoais joined, tokuhirom joined
nwc10 good *, #moarvm 08:57
08:57 sivoais joined 09:07 sivoais joined 09:13 brrt joined
brrt good * #moarvm 09:13
joining you from germany today :-)
09:18 sivoais joined
brrt i may have something that i want your advice on, again 09:20
the 'your' here is plurl 09:21
plural 09:22
i'm still at a loss with regards to the new jits' 'elemsbug' 09:23
but what i want to do, as i said before, is 'linearize' the jit output
eh, tiler output 09:24
so rather than have the result be a tree with tiles attached to it, make a linear list (array) with tiles that (often) refers to the tree
seems simple enough i think, but there are some complicated consequences 09:25
first of all, this linearization happens, by default, in postorder sequence 09:26
which is the same order as the compilation order itself
but some things happen in preorder or in inorder 09:28
09:28 sivoais joined
brrt i.e. labelling 09:28
and spilling
so what i think has to happen is that i should insert 'markers' into the tile sequence that tell the register allocator that the following N items are conditional 09:29
09:29 rarara joined 09:31 tadzik joined
brrt or... something like that 09:31
pff
i'm also not sure exactly when is should be using labels or not 09:33
i think we can assign labels pretty early in the process
during analysis phase, just relative to the tree itself
any optimization that changes this is then responsible for it's own relabelling
does that make sense at all?
damn, now i wonder whether i installed asan after my fedora reinstall 09:36
clearly, i also need to merge the jit sequence number thingy asap
09:37 tokuhirom joined 09:38 sivoais joined 09:49 sivoais joined 09:59 sivoais joined 10:09 sivoais joined 10:14 hohoho joined 10:20 sivoais joined 10:30 sivoais joined 10:40 sivoais joined 10:42 tokuhirom joined 10:49 sivoais joined 11:00 sivoais joined 11:32 ggoebel2 joined 11:33 hohoho joined
timotimo sorry for not feeding anything back, but this is going a bit over my head :S 12:04
and my head is flu-ridden at the moment anyway
12:18 hohoho joined 12:44 tokuhirom joined 13:00 brrt joined
brrt \o 13:04
np timotimo :-) get well soon
timotimo trying my best :) 13:05
i'll go lie down for a bit again
brrt :-)
rarara I was looking into making the perl6 command to behave like python: that if you do perl6 <<< 'code'; it does print the command prompt. But as it was prospectable i've been overwhelmend 13:06
it turns out that isatty is not implemented in nqp
and implementing it would mean to implement for all different backends, what do you do in those cases? 13:07
also, do you plan to keep src/io/syncfile.c use libuv, or will you switch at some point to multiple OS dependent files? 13:08
jnthn rarara: It'll change sometime next month to not use libuv, I expect. 13:09
Oh wait 13:10
syncfile I dunno 'cus we already use the sync bit
syncstream otoh will almost certainly change
13:14 cognominal joined
brrt rarara: that's true, i've looked at implementing isatty, and found that it was an concept alien to the libuv framework 13:22
you can totally make it work, but it was just a bit too complex and i dropped it 13:23
arnsholt I guess the problem is that TTY file handles don't exist on all platforms? 13:35
rarara uv_guess_handle tells you if it is tty, moar uses it in MVM_file_get_stdstream then forgets about it. I don't know the internals but it seems possibile to add a flag to the streams or to make a new stream class just for this 13:39
brrt arnsholt: if we define 'all platforms' to be 'linux, mac os x and windows', then isatty is actually defined for all of them 13:43
it is not defined for all sorts of file handles
and more importantly, libuv filehandles are not filehandles
they are an objectish buffered multiplexed interface to IO 13:44
so my suggestion would be to wait until the dust has settled on our sync io story 13:45
because it's been known for some time that libuv for synchronous IO is problematic
and this is just one example of it 13:46
arnsholt Ah, right. Sounds like a reasonable plan 13:48
And for our purposes Windows and Unix is probably a reasonable definition of all platforms for a while
brrt there are of course other fun platforms 13:51
[Coke] OS X 13:52
arnsholt OS X is Unix enough though
brrt: Looking forward to implementing the JIT on VMS? =D 13:53
brrt well, does VMS run on x64? :-P 13:57
brrt is planning to write porting documentation describing what would be needed for a port 13:58
but in fairness, the main concerns with regards to porting are a): cpu architecture b): platform api
s/api/abi 13:59
or, to put it shortly, other than 'which registers are free' and 'how to call c functions' there isn't much difference between platforms
cpu's mostly don't care about windows vs unix
arnsholt That's very true 14:08
14:45 tokuhirom joined 14:46 ShimmerFairy joined
brrt afk 14:53
15:07 hohoho joined 15:46 tokuhirom joined 15:51 Ven joined 16:08 hohoho joined 16:12 Ven joined 16:33 Ven joined 16:40 btyler_ joined 16:47 Ven joined 16:59 Util joined, leedo joined, ingy joined 17:07 colomon joined 17:10 Util joined, leedo joined, ingy joined 17:12 avar joined 17:14 FROGGS joined 17:25 Peter_R joined
dalek arVM: fe87f7b | brrt++ | src/ (5 files):
Add a JIT frame sequence number

This is useful to disambiguate between different spesh candidates of the same frame.		 17:41
arVM: 87729c2 | brrt++ | src/ (3 files):
Log JIT code using sequence numbers and map file

Trying to add a lot of information into the bytecode filename did not really work out. So now we just use the sequence number for the bytecode. This will conflict in case you have multiple running processes, but this is debugging output so there is no reason to care.
17:48 tokuhirom joined
nwc10 if (isntance->jit_bytecode_map) 17:57
^
oops, missed
anyway, if brrt would be so kind as to fire up his IRC client 17:58
18:09 travis-ci joined
travis-ci MoarVM build failed. Bart Wiegmans 'Log JIT code using sequence numbers and map file 18:09
travis-ci.org/MoarVM/MoarVM/builds/85378094 github.com/MoarVM/MoarVM/compare/4...729c2728c3
18:09 travis-ci left
FROGGS nwc10: maybe you have to say his name three times in a row? 18:15
dalek arVM: cfa7e25 | FROGGS++ | src/moar.c:
fix typo that broke the build, nwc10++
18:18 vendethiel joined 18:20 leont joined
vendethiel brrt: as much as I love your blog posts (and reading them with some new ASM insights!), I feel like the blog post about v8 being faster than gcc is pretty unfair (as it relies on disabled optimizations + adds in compilation time..) 18:22
18:29 travis-ci joined
travis-ci MoarVM build failed. Tobias Leich 'fix typo that broke the build, nwc10++' 18:29
travis-ci.org/MoarVM/MoarVM/builds/85383293 github.com/MoarVM/MoarVM/compare/8...a7e25f87e4
18:29 travis-ci left
FROGGS hmpf 18:34
pushing in a sec 18:35
such typo!
dalek arVM: 3a00a08 | FROGGS++ | src/moar.c:
fix another typo
 18:36
18:56 travis-ci joined
travis-ci MoarVM build passed. Tobias Leich 'fix another typo' 18:56
travis-ci.org/MoarVM/MoarVM/builds/85386813 github.com/MoarVM/MoarVM/compare/c...00a089be59
18:56 travis-ci left
FROGGS pheew 18:57
vendethiel FROGGS++ 19:08
FROGGS :o)
19:49 tokuhirom joined 20:08 hohoho joined 20:34 colomon joined 21:37 colomon joined 21:47 ggoebel joined 21:51 tokuhirom joined 21:54 hohoho joined 22:52 tokuhirom joined 23:05 cognominal joined 23:46 tokuhirom 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!