nwc10 good *, #moarvm 08:57
brrt good * #moarvm 09:13
joining you from germany today :-)
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
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
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
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
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
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
brrt afk 14:53
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.
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
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
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++
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
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
FROGGS hmpf 18:34
pushing in a sec 18:35
such typo!
dalek arVM: 3a00a08 | FROGGS++ | src/moar.c:
fix another typo
 18:36
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
FROGGS pheew 18:57
vendethiel FROGGS++ 19:08
FROGGS :o)

Powered by Cro and the Raku® Programming Language.

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

Thank you!