01:03 vendethiel joined 01:52 colomon joined, vendethiel joined 02:03 colomon joined 02:53 colomon joined 03:42 harrow joined 03:45 vendethiel joined 04:23 ggoebel2 joined 04:25 vendethiel joined 04:56 vendethiel joined 05:45 vendethiel joined 06:12 vendethiel joined 06:21 TimToady joined 06:24 rurban joined 06:26 FROGGS joined 06:35 vendethiel joined 07:13 brrt joined 07:40 vendethiel joined 08:06 vendethiel joined 08:12 zakharyas joined
brrt \o 08:16
08:23 sivoais joined
dalek arVM/even-moar-jit: 9ff4af0 | brrt++ | src/ (3 files):
Tree traversal is now generic
 08:37
arVM/even-moar-jit: e66ef49 | brrt++ | / (7 files):
Moved expr tree dump to jit logging

expr.h is now a 'common' header, shared by all.		 08:45
brrt mumblemumble 08:49
what shall i do first
a): a non-final code generator
b): CSE
pros and cons 08:51
i know how to do CSE
pretty much
cons: it is yet another potential source of bugs
code generator pro: it proves the concept
and gives a frame on which we can then improve 08:52
con: i'm not as 100% sure on how to do it yet as i am for CSE
08:57 vendethiel joined
brrt bbiab 09:09
FROGGS brrt: if b) is the potential source of bugs I'd vote for a) 10:27
jnthn Also good to work on the less certain bits sooner, so allow more time to get certainer :) 10:35
FROGGS aye, also the 'proves the concept' bit seems important me thinks 10:49
jnthn: btw, I need a Perl 6 task :/ 10:50
FROGGS looks at ROADMAP and does not know what to pick 10:53
jnthn RT has > 1000 ideas ;) 10:59
Did your C++ NativeCall work ever get merged?
Yowser, ROADMAP is quite out of date 11:03
2 *** packed arrays (jnthn)
We pretty much have those
FROGGS: Don't know if getting the logical cascade operators straightened out would be interesting 11:04
FROGGS jnthn: logical cascade ops? 11:17
and yeah, C++ might be good to get in a state where it is mergable
jnthn FROGGS: orelse/andthen 11:18
FROGGS ahh, these
hmmm, I can try to tackle them
11:42 brrt joined 11:43 rurban joined 12:10 brrt joined
timotimo yesterday i already wondered how far mvm's even-moar-jit makes it from an actual piece of spesh'd bytecode towards a piece of assembly code that got through the new expr compiler 12:19
seems like when a) is done we'll have a preliminary implementation of "the whole way" 12:20
12:25 zakharyas1 joined
brrt working on it :-) 12:26
timotimo sounds great to me :) 12:29
i'm idly wondering what kind of performance difference we'd see if we moved away from libuv for synchronous I/O 12:30
12:46 vendethiel joined
brrt i'm.... wondering if we all still feel like libuv was a great idea 12:52
maybe some year in the future we'll see something like 6io
jnthn It was in so far as we're further ahead now than if we'd tried to build all the platform abstractions ourselves.
We don't even have regular access to the some of the platforms libuv supports... 12:53
I suspect for async I/O we want to keep it
brrt that is true enough :-)
jnthn For sync...I think we will want to lose it
brrt hmm 12:54
jnthn I'm just wondering how long I can put that off :)
brrt i concur
jnthn 'cus if long enough, we'll have awesome JITted machine code calls and we'll write the whole I/O stack in NQP
brrt but, replace it with 'just' stdio?
hah
it annoys me a bit that this is one of the things that is actually possible, but the road to it is so long 12:55
jnthn Well, yeah, that's going to be one of the points of my talk on VM engineering at YAPC
You have to pick your priorities and accept that some things just can't happen near-term.
brrt ok, good to know, i'll leave that out then :-) 12:57
13:09 vendethiel joined
[Coke] we should absolutely be using other people's stuff and not rolling our own to start with. Let our limited resources focus on the cool new stuff. 13:21
FROGGS aye 13:23
though at some point... when you are done and have plenty of time... :o) 13:24
JimmyZ ideally :P
brrt [Coke]: fair point; but other peoples stuff should not be in conflict with our goals 13:26
FROGGS of course we have to pick deps that fit our needs 13:27
though, our needs change over time
[Coke] brrt: is that the case now? 13:29
brrt hmm... for sync file access, i think that it would be reasonable to say so, yes 13:30
libuv is really not meant for that
timotimo well, we're doing a very curious dance with that 13:55
add a "please read/write this file" task to the event loop, start the event loop, wait for the tasks "finished" callback to be called, terminate the loop from there, return from the read/write op 13:56
when compared to "result = fread(fh, 1024)" or what have you ... yeah, that's ... different :) 14:10
brrt nods 14:13
and bbiab 14:14
or actually
bbl
nwc10 however, I think that it's a reasonable plan to hold of redoing *sync* IO until we're confident that we can do it in NQP 14:15
ie the call we'd be making is read(...) not fread()
(or the Win32 API equivalent)
brrt hmm. and how would you propose we do that? add a syscall interface to nqp? 14:16
hell, that's not even a bad idea...
nwc10 You expected me to have a plan? :-)
brrt of course :-P
nwc10 at least on everything POSIX, I thought that read() etc appeared as C libraries
er, C functions
timotimo right, i frogot fread is the kernel function or system call or whatever :)
brrt but again, i'll be back much later, if at all, today
nwc10 (I'd hope rather thin C functions that map into syscalls)
brrt actually fread is the libc function
read is the syscall
timotimo we'll turn nqp into a super awesome systems programming language ... maybe not
nwc10 fread() is stio 14:17
stdio
timotimo oh lord, what do i know :)
nwc10 which is a(nother) layer of buffering
timotimo at least i know i ought to read the man pages for those c functions before i use them
nwc10 and possibly bugs, but certainly possible platform differences
and no good way to deal with non-blocking IO
timotimo that could be called wise, no?
brrt nods 14:18
manpages are awesome
nwc10 that last part probably being its biggest deficieny to us these days
brrt but now i'm really really really off
nwc10 have fun
brrt :-)
timotimo you're talking about cstdio in that case, yeah?
i mainly know "#include <stdio>" for "i want printf, give me printf!" :) 14:19
nwc10 C's stdio, me yes
timotimo it'd be kinda surprising to me if we'd somehow manage to stumble over bugs in c's stdio after all those years
especially since jnthn encourages the code base to be C89 :-)
nwc10 well, Solaris stdio was not quite ANSI C conformant for at least a decade 14:20
fflush(NULL) didn't do the right thing
no idea if they actually fixed that
it's quite possible that they decided that they prefered compatiblity to correctness, and didn't 14:21
timotimo oh!
timotimo learns about unlocked_stdio
"you can use these if you desire to fuck up your files" 14:22
if we build our own locking, maybe we should use these functions so that we don't double-lock? or is that a different kind of lock?
nwc10 I don't know answers to the last part 14:23
but I'd more view it "if we build our own locking", we can do our buffering and line ending detection, and deal with the unbuffered OS calls directly 14:24
jnthn We already do buffering in MoarVM 14:27
And already have multiple buffers. 14:28
One for bytes => codes, another for codes => graphs
Granted the second one works hard to stay as tiny as possible. :)
14:29 Ven joined
nwc10 this was my guess. 14:29
and I'm also aware of how much C code there is in Perl 5 (dating from Perl 1) to attempt to outsmart stdio
jnthn I think we first get the GLR done to see how much of our IO slow is about that 14:30
Then we profile and see where the rest is
And then we decide if IO perf is good enough for Christmas.
nwc10 because really what you (the language runtime) wants is "give me as much as you've got, but don't actually block if we found my desired line terminator in there" 14:31
yes, agree
IO perf was IIRC one of the two big stinkers in Python 3.0, fixed in Python 3.1
jnthn Yeah, I'd rather we stink in our own ways :)
nwc10 but definately "make it work" needs to be finished before "make it fast" 14:32
they had a direct comparison with Python 2.6, and 2.6 was much faster.
er, s/direct/close/
timotimo don't forget that some people (me, for example) have a hard time focusing on tasks and may meander quite a bit 14:33
nwc10 I'm working here from the assumption that the difference is "Python 3 lets you do what Python 2 does, but better", whereas "Perl 6 lets you do things you simply can't do in Perl 5"
timotimo the UDP support in moarvm is suffering from that, and has done so for at least a month so far
nwc10 (both statements are oversimplificaitons)
but you don't get NFG or sane performant concurrency in Perl 5
15:11 FROGGS joined
hoelzro is anyone opposed to the idea of having more exception categories (ex. a type for failure to perform an IO operation like open a file, a type for failure to assign to a readonly variable, etc)? 15:52
I was thinking about it primarily for better handling of IO errors, but RT #125590 made me think it could be used to add information to exceptions bubbling up from MoarVM land 15:53
jnthn hoelzro: I'm not sure I'd do it by category, but yeah, I've been pondering a way to configure VM exceptions to map to some kind of typed thing. 15:54
hoelzro jnthn: sorry, category was a poor choice of words. So either add some sort of "kind" field to MVMExceptionBody, or stick the information in the payload
or perhaps have category with the MSB set mean non-control exceptions 15:55
that's up to you =)
jnthn hoelzro: The other option is to hang it off the existing hll config mechanism. 15:56
hoelzro: So we first look there
hoelzro jnthn: the one set up in BOOTSTRAP.nqp?
jnthn Right, though we can add to it in CORE.setting too
This means that we can also map it to do a "fail" also 15:57
For things that should be Failure-like instead of exception-like
hoelzro ah ha
I see 15:58
jnthn Been pondering it 'cus I think we need to find an efficient way for the dimensioned arrays to give Failure on out-of-bounds access
hoelzro this is why I ask here instead of setting out on my own =P 15:59
jnthn And I don't want to do it by catching a VM exception and then mapping it to a Failure
hoelzro that makes a lot of sense, especially since for example, open() problems should result in a Failure
jnthn 'cus it horribly bloats the op bodies and probably shoves them firmly over the inline limit or something
Yeah, I figure there's other cases :) 16:00
hoelzro alright, good to know you're thinking about it =) 16:01
jnthn Feel free to explore in that direction, anyways. I suspect you'll need to take a bit of care over VM state 16:04
Since we need to set up a new VM-level call, then unwind the C stack back to the interpreter 16:05
(which may immediately fall back into the JIT, but you don't have to care about that bit)
16:12 cognominal joined 16:19 TEttinger joined
japhb FROGGS: +100 to getting C++ to merged status 16:35
17:37 vendethiel joined 18:03 vendethiel joined 18:27 brrt joined
brrt \o 18:27
dalek arVM/even-moar-jit: f90d417 | brrt++ | src/jit/ (4 files):
Simple, broken, compilation algorithm

Because it is broken, I dump it as a string to the jit log, rather than try and create real code with it. Real code is much more difficult to debug.
brrt i present to you: the brokenest compilation algorithm ever :-)
nwc10 bogo-compile? "Throw all the nodes up in the air, and if they land in a usuable order, go with that. Else throw again" ? 18:29
brrt hmm. .that presumes you can find if a order is usable 18:30
and if you can find it, why not make it in the first place
nwc10 yes, I realised that that was rather a hole in my plan
brrt no, what is broken about it, is that it doesn't spill nodes correctly
and it doesn't load them after spilling 18:31
nwc10 you can't exactly know if something is usuable without already having a copy of the right answer
brrt and and and and
or a way to compute it
nwc10 but it's really fast for certain benchmarks? :-)
brrt no, it dumps to the log stream
rather than the bytecode
figured that it'd be much easier to debug that way
hmmm 18:33
and it 'worked', for its purpose, because i find that there are a lot of things i hadn't properly considered yet
which was what i was aiming for
hmm 18:41
i'm going to think about it a bit
why didn't i bring my notebook :-( 18:42
brrt afk 18:43
18:43 brrt left 19:57 vendethiel joined
jnthn You could use the result the interpreter comes up with to decide if it's correct :P 20:17
20:32 vendethiel joined 21:06 vendethiel joined 21:42 vendethiel joined 23:10 vendethiel joined 23:47 TEttinger joined 23:55 vendethiel 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!