Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-07-10

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
01:03 vendethiel joined #moarvm
01:52 colomon joined #moarvm
01:52 vendethiel joined #moarvm
02:03 colomon joined #moarvm
02:53 colomon joined #moarvm
03:42 harrow joined #moarvm
03:45 vendethiel joined #moarvm
04:23 ggoebel2 joined #moarvm
04:25 vendethiel joined #moarvm
04:56 vendethiel joined #moarvm
05:45 vendethiel joined #moarvm
06:12 vendethiel joined #moarvm
06:21 TimToady joined #moarvm
06:24 rurban joined #moarvm
06:26 FROGGS joined #moarvm
06:35 vendethiel joined #moarvm
07:13 brrt joined #moarvm
07:40 vendethiel joined #moarvm
08:06 vendethiel joined #moarvm
08:12 zakharyas joined #moarvm
08:16 brrt \o
08:23 sivoais joined #moarvm
08:37 dalek MoarVM/even-moar-jit: 9ff4af0 | brrt++ | src/ (3 files):
08:37 dalek MoarVM/even-moar-jit: Tree traversal is now generic
08:37 dalek MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/9ff4af07db
08:45 dalek MoarVM/even-moar-jit: e66ef49 | brrt++ | / (7 files):
08:45 dalek MoarVM/even-moar-jit: Moved expr tree dump to jit logging
08:45 dalek MoarVM/even-moar-jit:
08:45 dalek MoarVM/even-moar-jit: expr.h is now a 'common' header, shared by all.
08:45 dalek MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/e66ef495b8
08:49 brrt mumblemumble
08:49 brrt what shall i do first
08:49 brrt a): a non-final code generator
08:49 brrt b): CSE
08:51 brrt pros and cons
08:51 brrt i know how to do CSE
08:51 brrt pretty much
08:51 brrt cons: it is yet another potential source of bugs
08:51 brrt code generator pro: it proves the concept
08:52 brrt and gives a frame on which we can then improve
08:52 brrt con: i'm not as 100% sure on how to do it yet as i am for CSE
08:57 vendethiel joined #moarvm
09:09 brrt bbiab
10:27 FROGGS brrt: if b) is the potential source of bugs I'd vote for a)
10:35 jnthn Also good to work on the less certain bits sooner, so allow more time to get certainer :)
10:49 FROGGS aye, also the 'proves the concept' bit seems important me thinks
10:50 FROGGS jnthn: btw, I need a Perl 6 task :/
10:53 * FROGGS looks at ROADMAP and does not know what to pick
10:59 jnthn RT has > 1000 ideas ;)
10:59 jnthn Did your C++ NativeCall work ever get merged?
11:03 jnthn Yowser, ROADMAP is quite out of date
11:03 jnthn 2 ***   packed arrays (jnthn)
11:03 jnthn We pretty much have those
11:04 jnthn FROGGS: Don't know if getting the logical cascade operators straightened out would be interesting
11:17 FROGGS jnthn: logical cascade ops?
11:17 FROGGS and yeah, C++ might be good to get in a state where it is mergable
11:18 jnthn FROGGS: orelse/andthen
11:18 FROGGS ahh, these
11:18 FROGGS hmmm, I can try to tackle them
11:42 brrt joined #moarvm
11:43 rurban joined #moarvm
12:10 brrt joined #moarvm
12:19 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:20 timotimo seems like when a) is done we'll have a preliminary implementation of "the whole way"
12:25 zakharyas1 joined #moarvm
12:26 brrt working on it :-)
12:29 timotimo sounds great to me :)
12:30 timotimo i'm idly wondering what kind of performance difference we'd see if we moved away from libuv for synchronous I/O
12:46 vendethiel joined #moarvm
12:52 brrt i'm.... wondering if we all still feel like libuv was a great idea
12:52 brrt maybe some year in the future we'll see something like 6io
12:52 jnthn It was in so far as we're further ahead now than if we'd tried to build all the platform abstractions ourselves.
12:53 jnthn We don't even have regular access to the some of the platforms libuv supports...
12:53 jnthn I suspect for async I/O we want to keep it
12:53 brrt that is true enough :-)
12:53 jnthn For sync...I think we will want to lose it
12:54 brrt hmm
12:54 jnthn I'm just wondering how long I can put that off :)
12:54 brrt i concur
12:54 jnthn 'cus if long enough, we'll have awesome JITted machine code calls and we'll write the whole I/O stack in NQP
12:54 brrt but, replace it with 'just' stdio?
12:54 brrt hah
12:55 brrt 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
12:55 jnthn You have to pick your priorities and accept that some things just can't happen near-term.
12:57 brrt ok, good to know, i'll leave that out then :-)
13:09 vendethiel joined #moarvm
13:21 [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:23 FROGGS aye
13:24 FROGGS though at some point... when you are done and have plenty of time... :o)
13:24 JimmyZ ideally :P
13:26 brrt [Coke]: fair point; but other peoples stuff should not be in conflict with our goals
13:27 FROGGS of course we have to pick deps that fit our needs
13:27 FROGGS though, our needs change over time
13:29 [Coke] brrt: is that the case now?
13:30 brrt hmm... for sync file access, i think that it would be reasonable to say so, yes
13:30 brrt libuv is really not meant for that
13:55 timotimo well, we're doing a very curious dance with that
13:56 timotimo 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
14:10 timotimo when compared to "result = fread(fh, 1024)" or what have you ... yeah, that's ... different :)
14:13 * brrt nods
14:14 brrt and bbiab
14:14 brrt or actually
14:14 brrt bbl
14:15 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 nwc10 ie the call we'd be making is read(...) not fread()
14:15 nwc10 (or the Win32 API equivalent)
14:16 brrt hmm. and how would you propose we do that? add a syscall interface to nqp?
14:16 brrt hell, that's not even a bad idea...
14:16 nwc10 You expected me to have a plan? :-)
14:16 brrt of course :-P
14:16 nwc10 at least on everything POSIX, I thought that read() etc appeared as C libraries
14:16 nwc10 er, C functions
14:16 timotimo right, i frogot fread is the kernel function or system call or whatever :)
14:16 brrt but again, i'll be back much later, if at all, today
14:16 nwc10 (I'd hope rather thin C functions that map into syscalls)
14:16 brrt actually fread is the libc function
14:16 brrt read is the syscall
14:16 timotimo we'll turn nqp into a super awesome systems programming language ... maybe not
14:17 nwc10 fread() is stio
14:17 nwc10 stdio
14:17 timotimo oh lord, what do i know :)
14:17 nwc10 which is a(nother) layer of buffering
14:17 timotimo at least i know i ought to read the man pages for those c functions before i use them
14:17 nwc10 and possibly bugs, but certainly possible platform differences
14:17 nwc10 and no good way to deal with non-blocking IO
14:17 timotimo that could be called wise, no?
14:18 * brrt nods
14:18 brrt manpages are awesome
14:18 nwc10 that last part probably being its biggest deficieny to us these days
14:18 brrt but now i'm really really really off
14:18 nwc10 have fun
14:18 brrt :-)
14:18 timotimo you're talking about cstdio in that case, yeah?
14:19 timotimo i mainly know "#include <stdio>" for "i want printf, give me printf!" :)
14:19 nwc10 C's stdio, me yes
14:19 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
14:19 timotimo especially since jnthn encourages the code base to be C89 :-)
14:20 nwc10 well, Solaris stdio was not quite ANSI C conformant for at least a decade
14:20 nwc10 fflush(NULL) didn't do the right thing
14:20 nwc10 no idea if they actually fixed that
14:21 nwc10 it's quite possible that they decided that they prefered compatiblity to correctness, and didn't
14:21 timotimo oh!
14:21 * timotimo learns about unlocked_stdio
14:22 timotimo "you can use these if you desire to fuck up your files"
14:22 timotimo 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?
14:23 nwc10 I don't know answers to the last part
14:24 nwc10 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:27 jnthn We already do buffering in MoarVM
14:28 jnthn And already have multiple buffers.
14:28 jnthn One for bytes => codes, another for codes => graphs
14:28 jnthn Granted the second one works hard to stay as tiny as possible. :)
14:29 Ven joined #moarvm
14:29 nwc10 this was my guess.
14:29 nwc10 and I'm also aware of how much C code there is in Perl 5 (dating from Perl 1) to attempt to outsmart stdio
14:30 jnthn I think we first get the GLR done to see how much of our IO slow is about that
14:30 jnthn Then we profile and see where the rest is
14:30 jnthn And then we decide if IO perf is good enough for Christmas.
14:31 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 nwc10 yes, agree
14:31 nwc10 IO perf was IIRC one of the two big stinkers in Python 3.0, fixed in Python 3.1
14:31 jnthn Yeah, I'd rather we stink in our own ways :)
14:32 nwc10 but definately "make it work" needs to be finished before "make it fast"
14:32 nwc10 they had a direct comparison with Python 2.6, and 2.6 was much faster.
14:32 nwc10 er, s/direct/close/
14:33 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"
14:33 timotimo the UDP support in moarvm is suffering from that, and has done so for at least a month so far
14:33 nwc10 (both statements are oversimplificaitons)
14:33 nwc10 but you don't get NFG or sane performant concurrency in Perl 5
15:11 FROGGS joined #moarvm
15:52 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:53 hoelzro 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:54 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
15:55 hoelzro or perhaps have category with the MSB set mean non-control exceptions
15:55 hoelzro that's up to you =)
15:56 jnthn hoelzro: The other option is to hang it off the existing hll config mechanism.
15:56 jnthn hoelzro: So we first look there
15:56 hoelzro jnthn: the one set up in BOOTSTRAP.nqp?
15:56 jnthn Right, though we can add to it in CORE.setting too
15:57 jnthn This means that we can also map it to do a "fail" also
15:57 jnthn For things that should be Failure-like instead of exception-like
15:57 hoelzro ah ha
15:58 hoelzro 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
15:59 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
15:59 hoelzro that makes a lot of sense, especially since for example, open() problems should result in a Failure
15:59 jnthn 'cus it horribly bloats the op bodies and probably shoves them firmly over the inline limit or something
16:00 jnthn Yeah, I figure there's other cases :)
16:01 hoelzro alright, good to know you're thinking about it =)
16:04 jnthn Feel free to explore in that direction, anyways. I suspect you'll need to take a bit of care over VM state
16:05 jnthn Since we need to set up a new VM-level call, then unwind the C stack back to the interpreter
16:05 jnthn (which may immediately fall back into the JIT, but you don't have to care about that bit)
16:12 cognominal joined #moarvm
16:19 TEttinger joined #moarvm
16:35 japhb FROGGS: +100 to getting C++ to merged status
17:37 vendethiel joined #moarvm
18:03 vendethiel joined #moarvm
18:27 brrt joined #moarvm
18:27 brrt \o
18:27 dalek MoarVM/even-moar-jit: f90d417 | brrt++ | src/jit/ (4 files):
18:27 dalek MoarVM/even-moar-jit: Simple, broken, compilation algorithm
18:27 dalek MoarVM/even-moar-jit:
18:27 dalek MoarVM/even-moar-jit: Because it is broken, I dump it as a string to the jit log,
18:27 dalek MoarVM/even-moar-jit: rather than try and create real code with it. Real code is
18:27 dalek MoarVM/even-moar-jit: much more difficult to debug.
18:27 dalek MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/f90d417874
18:27 brrt i present to you: the brokenest compilation algorithm ever :-)
18:29 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:30 brrt hmm. .that presumes you can find if a order is usable
18:30 brrt and if you can find it, why not make it in the first place
18:30 nwc10 yes, I realised that that was rather a hole in my plan
18:30 brrt no, what is broken about it, is that it doesn't spill nodes correctly
18:31 brrt 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
18:31 brrt and and and and
18:31 brrt or a way to compute it
18:31 nwc10 but it's really fast for certain benchmarks? :-)
18:31 brrt no, it dumps to the log stream
18:31 brrt rather than the bytecode
18:31 brrt figured that it'd be much easier to debug that way
18:33 brrt hmmm
18:33 brrt and it 'worked', for its purpose, because i find that there are a lot of things i hadn't properly considered yet
18:33 brrt which was what i was aiming for
18:41 brrt hmm
18:41 brrt i'm going to think about it a bit
18:42 brrt why didn't i bring my notebook :-(
18:43 * brrt afk
18:43 brrt left #moarvm
19:57 vendethiel joined #moarvm
20:17 jnthn You could use the result the interpreter comes up with to decide if it's correct :P
20:32 vendethiel joined #moarvm
21:06 vendethiel joined #moarvm
21:42 vendethiel joined #moarvm
23:10 vendethiel joined #moarvm
23:47 TEttinger joined #moarvm
23:55 vendethiel joined #moarvm

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary