Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-06-04

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

All times shown according to UTC.

Time Nick Message
02:48 hoelzro joined #moarvm
03:55 harrow joined #moarvm
04:02 flussence joined #moarvm
06:18 oetiker joined #moarvm
06:20 FROGGS joined #moarvm
06:25 FROGGS jnthn: okay, so I return an array then in case it has to return more than one filehandle
06:25 brrt joined #moarvm
06:25 brrt FROGGS: I'm not sure what perl6 does. but can't you return an object?
06:26 brrt a pipe has at least two components; a PID and a stream
06:26 brrt possibly two streams, possibly three
06:26 brrt (possibly as many as you like. but three map to stdin/stdout/stderr)
06:28 FROGGS brrt: we return this one: MoarVM/src/6model/reprs/MVMOSHandle.h:13:struct MVMOSHandle
06:28 FROGGS currently the openpipe op only allows you to spawn a process, and read its stdout
06:29 FROGGS so I want to make it allow you to read both stdin and stdout, and also write to its stdin
06:31 FROGGS what also might work is to to create an MVMOSHandle in P6, and pass that to the openpipe op to attach it to the child process
06:31 brrt hmmmmm
06:32 brrt don't we have a struct specific for a pipe
06:32 brrt we  should, i'd think
06:32 FROGGS we dont
06:33 FROGGS we only have something for one end of a pipe
06:33 brrt well, i'd think having all the details together would be awesome
06:35 FROGGS ohh, in case the MVMOSHandle is for a pipe, we shove a MVMIOSyncPipeData into it, but that also just has a single MVMIOSyncStreamData
06:36 FROGGS maybe we should tripple that up
06:36 FROGGS though the our ops like setencoding($filehandle, $encoding) wont work anymore
06:37 FROGGS then*
06:37 brrt no, indeed
06:37 FROGGS so I guess we should keep having one filehandle per MVMOSHandle
06:38 brrt yes
06:38 FROGGS I'll play with it a little bit more today
06:38 brrt definitely
06:38 brrt but openpipe should return a suitable pipe object
06:38 brrt with pid
06:38 brrt imho :-)
06:38 FROGGS I wont push to master until it all looks sane, dont worry :o)
06:38 * brrt is not worrying
06:38 brrt :-)
06:38 FROGGS the returned filehandle knows the pid at least
06:39 brrt oh really?
06:39 brrt hmmm
06:39 FROGGS but making it: my $in=...; my $out=...; my $err=...; my $pid = nqp::openpipe($cmd, $env, $cwd, $in, $out, $err) would also look nice
06:40 FROGGS yes, MVMOSHandle->body->ss->process or so
06:40 brrt aha
06:40 FROGGS we dont expose that yet though
06:40 FROGGS (to P6)
06:41 * brrt doesn't really get the difference between syncfile and syncstream
06:41 FROGGS why I like my $pid = nqp::openpipe($cmd, $env, $cwd, $in, $out, $err) is, because this let's you pass in already oepened filehandles of some kind
06:41 FROGGS which might be awesome if it works, but not so if it doesnt
06:41 brrt how would that work
06:42 FROGGS I dunno
06:45 brrt hmm
06:45 brrt i do
06:45 brrt the issue is that we've ambiguated around the OS level concept of a pipe
06:46 FROGGS brrt: about sync{file,stream}... one is lockable, uses uv_fs_* functions etc
06:46 brrt a pipe is a combination of file descriptors, where the OS guarantees that one part can read to another
06:46 brrt a subprocess-connected-via-a-pipe is what openpipe does
06:46 FROGGS brrt: though it is not "a-pipe"
06:47 FROGGS it is "pipes"
06:47 brrt if you *do* want to do nqp::openpipe($cmd, $env, $cwd, $in, $out, $err) then you should be able to differentiate between the piping and the subprocess-opening
06:47 brrt but yes, that is precisely what you want ot achieve, so it is pipe
06:47 brrt s
06:54 zakharyas joined #moarvm
07:00 oetiker joined #moarvm
07:07 Ven joined #moarvm
07:16 Ven_ joined #moarvm
08:38 brrt ok, i guess my main 'problem' is very simply this; i can have descriptor() either return an uv_file (always an int) or a uv_os_fd_t (either an int or an opaque HANDLE); but my suspicion is rather strong that on windows a HANDLE behaves quite differently from a file descriptor int
08:42 brrt and so i'm not willing to 'mix' them just hy
08:42 brrt yet
09:22 Ven joined #moarvm
11:36 Ven joined #moarvm
11:52 timotimo i'd like to see "nan" be implemented in the jit
11:53 lizmat .oO( also likes to see indian bread to be here just in time )
11:56 FROGGS batura++
12:20 timotimo :)
12:23 timotimo nan is now the op that prevents the biggest frame (as in: invoked the mont number of times) from being jitted
12:26 lizmat do you mean NaN ?
12:28 FROGGS the op is called nan
12:28 FROGGS nqp-m: say(nqp::nan())
12:28 camelia nqp-moarvm: OUTPUT«NaN␤»
12:29 timotimo yup
12:29 timotimo the first thing the frame does is assign nan to all the lexicals
12:29 timotimo i suppose i could make it compile by initializing the lexicals with 0 explicitly
12:54 jnthn nan shouldn't be hard to implement, no?
12:54 jnthn (In the JIT I mean)
12:54 jnthn I presume we already JIT iconst_n64
12:55 timotimo hm, i suppose?
12:55 timotimo i have to cast the num64 into a char* and then into an int64?
12:55 jnthn I can look at it; just one more short errand and then I'm free of omg-I-just-moved-to-a-new-country tasks :)
12:55 timotimo no, you don't look at such a trivial thing! :P
12:56 FROGGS jnthn: do the hard things!
12:56 FROGGS :P
12:56 timotimo how do you nan in C?
12:56 timotimo "nan"? "NaN"?
12:56 timotimo NAN apparently
12:56 jnthn See how we interp it :P
12:57 jnthn MVM_num_nan(tc)
12:57 jnthn That presumably does something portable/correct, so use it.
12:58 jnthn I suggest just MVMRegister tmp; tmp.n64 = MVM_num_nan(tc);
12:58 jnthn And then use tmp.i64 as the valbytes
12:58 timotimo ah
12:58 timotimo that's good
13:00 timotimo well, it doesn't bail any more ...
13:00 timotimo i'll push i suppose
13:00 dalek MoarVM: c43217e | timotimo++ | src/jit/graph.c:
13:00 dalek MoarVM: jit getattrref_* and getattrsref_*
13:00 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/c43217ec35
13:00 dalek MoarVM: 2924b2c | timotimo++ | src/jit/ (2 files):
13:00 dalek MoarVM: jit nqp::nan
13:00 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/2924b2c385
13:04 jnthn timotimo: Could to inf and neginf while you're at it ;)
13:04 timotimo sure, but right now i'm on the move
13:38 Ven joined #moarvm
13:54 Ven joined #moarvm
14:11 timotimo i'm at the GPN now, but i'll be walking around a lot :)
14:19 FROGGS timotimo: have fun!
14:21 jnthn And eat a gulasch for me! :P
14:29 Ven joined #moarvm
14:31 colomon joined #moarvm
14:35 brrt joined #moarvm
14:37 brrt \o kids
14:38 jnthn hello daddy!
14:38 brrt you can implement is_nan quite a bit more efficient than mvm_tc_is_nan iirc
14:38 brrt :-P
14:38 jnthn Go for it :P
14:39 brrt yes yes yes, will try
14:40 brrt oh, we're not checking for nan, but setting nan
14:40 brrt hmm
14:42 brrt oh nm, timotimo++'s patch is as nice as i would want it
14:48 brrt anyway... we have plenty open pull requests standing
14:48 brrt i'd like to merge some of them if that's ok with you
14:49 jnthn brrt: Which ones?
14:50 * jnthn is happy to glance any brrt++ approves of
14:50 brrt https://github.com/cygx/MoarVM/commit/08be9066cf2575ac65692a403e819a7e04e1cb52 i like this one
14:51 brrt https://github.com/MoarVM/MoarVM/pull/206/files this one is also clearly correct
14:54 brrt https://github.com/MoarVM/MoarVM/pull/212/files and this one, too
14:55 jnthn resolve_open_mode can do an out-of-bounds memory access 'cus it fails to check the strlen of cp
14:55 jnthn oh, hang on
14:55 jnthn no, it does handle it
14:55 jnthn I misread :)
14:55 jnthn OK, +1 to the first one
14:56 jnthn 206 is just leaving some code there that we should probably reinstate when we work out why it doesn't work
14:57 jnthn So -1 to that, we should find/fix the real issue
14:57 jnthn +1 to https://github.com/MoarVM/MoarVM/pull/212/files
14:58 dalek MoarVM: 08be906 | cygx++ | src/io/syncfile.c:
14:58 dalek MoarVM: support opening files in modes besides r, w, wa
14:58 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/08be9066cf
14:58 dalek MoarVM: 66b7db4 | cygx++ | src/io/syncfile.c:
14:58 dalek MoarVM: add missing define
14:58 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/66b7db4a2e
14:58 dalek MoarVM: 5a31c9d | brrt++ | src/io/syncfile.c:
14:58 dalek MoarVM: Merge pull request #215 from cygx/open-mode
14:58 dalek MoarVM:
14:58 dalek MoarVM: Interesting patch, looks good.
14:58 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/5a31c9d9a8
14:58 brrt ok, i'll leave 206 as it is, then
14:59 dalek MoarVM: ba700a7 | paultcochrane++ | src/io/procops.c:
14:59 dalek MoarVM: Destroy correct string decodestream
14:59 dalek MoarVM:
14:59 dalek MoarVM: In spawn_gc_free() a branch which looks like it is supposed to destroy the
14:59 dalek MoarVM: stderr stream was actually destroying the stdout stream (which was happening
14:59 dalek MoarVM: in another code path) and thus is possibly a copy-paste error.
14:59 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/ba700a7283
14:59 dalek MoarVM: d931587 | brrt++ | src/io/procops.c:
14:59 dalek MoarVM: Merge pull request #212 from paultcochrane/pr/smoke-me/fix-possible-copy-paste-error
14:59 dalek MoarVM:
14:59 dalek MoarVM: Destroy correct string decodestream
14:59 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/d9315873d3
15:00 brrt the endian correction thingies, I can't really judge
15:01 brrt oh, waitaminute
15:04 brrt what do you think of https://github.com/MoarVM/MoarVM/pull/216/files ? looks reasonably innocent to me
15:06 hoelzro is there a opcode-level profiler for MoarVM? I'm curious how much time my program is spending on each opcode
15:07 jnthn No
15:07 hoelzro ok
15:07 hoelzro shouldn't be that hard to hack into interp.c =)
15:08 FROGGS 216 looks good
15:08 FROGGS this check can go entirely, right? https://github.com/bubaflub/MoarVM/blob/fix_warnings/src/strings/unicode_ops.c#L29
15:09 brrt hoelzro: compile time, yeah, ok, but at runtime even optional profiling would incur significant cost
15:09 FROGGS ohh no: MoarVM/src/strings/unicode.c:45288:static MVMint32 MVM_codepoint_to_row_index(MVMThreadContext *tc, MVMint32 codepoint) {
15:10 FROGGS so codepoint_row shall be declared signed
15:10 hoelzro brrt: right, I figured as much
15:11 hoelzro I figured it would be similar to how tracing is done, with a conditional compilation define
15:11 brrt otherwise you can look at the NEXT macro
15:11 brrt aye
15:48 dalek MoarVM: db72ab9 | jnthn++ | src/strings/utf8.c:
15:48 dalek MoarVM: Non-characters are valid for UTF-8 encoding.
15:48 dalek MoarVM:
15:48 dalek MoarVM: See Unicode Corrigendum 9 for more information.
15:48 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/db72ab94fb
16:22 [Coke] isatty/uv - uv_guess_handle() and test for UV_TTY ?
16:24 Ven joined #moarvm
16:27 colomon joined #moarvm
16:42 brrt joined #moarvm
17:01 Ven joined #moarvm
17:57 FROGGS joined #moarvm
19:16 FROGGS my openpipe changes seem to work out
19:33 japhb Excellent, more pipe sanity.
19:51 mj41 joined #moarvm
19:51 FROGGS Super Mario would be glad :o)
19:52 japhb Great, now I've got the theme music going through my head.
19:56 FROGGS hehe
20:03 timotimo fantastic. thanks for the triage, brrt
20:04 vendethiel joined #moarvm
20:04 hoelzro FROGGS: is that up in a branch somewhere?
20:05 FROGGS hoelzro: not yet
20:05 hoelzro what kind of stuff did you do?
20:06 FROGGS allowing to read from stdout and stderr and write to the children's stdout at the same time
20:06 nwc10 endian correction thingies are where?
20:07 nwc10 was going to say - some spectests are bust on Power64
20:07 nwc10 hadn't got further than attaching gdb and finding that the SEGV was attemping to dereference a pointer with a value of (something like) 0xA
20:10 hoelzro FROGGS: nice! I was thinking about doing that with a module
20:11 jnthn Suspect pointer is suspect.
20:11 nwc10 oh yes.
20:11 nwc10 most suspect
20:12 hoelzro FROGGS: I feel like you often beat me to things I want to do =)
20:12 FROGGS hoelzro: I hope that's okay ó.ò
20:12 hoelzro absolutely =)
20:12 FROGGS good :o)
20:12 hoelzro it just makes me feel a little lazy ;)
20:15 nwc10 jnthn: you realise, that one of the hidden downsides of MoarVM's super-fast build times, is that I can't actually pour a beer
20:16 nwc10 because every time I'm about to start, it's already finished, so I can go to the next step
20:16 jnthn nwc10: Switch to clang? P
20:16 jnthn :P
20:17 jnthn nwc10: Or get a beer tap installed next to where you work.
20:19 nwc10 I'm sitting next to the beer
20:20 nwc10 but a build of under 5 seconds isn't slow enough
20:20 jnthn oh...
20:20 nwc10 er, actually, strictly 12 according to time
20:20 nwc10 including install
20:20 jnthn Smaller glass?
20:20 nwc10 which is single threaded
20:20 jnthn Kölsch style? :)
20:20 nwc10 :-)
20:21 hoelzro how does Windows handle the case where process A has a file open, and process B deletes it?
20:21 hoelzro I'm wondering if it's similar to to Unix "A can still access the file's contents" semantics
20:22 jnthn hoelzro: It tells process B "no, that's an access violation", I think :P
20:22 hoelzro ah ha
20:23 FROGGS hoelzro: I'll push to moarvm and nqp in a minute
20:24 timotimo my network connection here is a bit thin, i have no idea why :(
20:24 jnthn It's hungry. Feed it more gulash!
20:24 jnthn .oO( or hungary... )
20:24 timotimo :)
20:25 hoelzro FROGGS++
20:26 timotimo now that i'm back at my computer ... what was i about to do?
20:26 timotimo perl6/moarvm related things i mean
20:26 timotimo i was working on that benchmark ...
20:26 timotimo blergh, i had my scripts in /tmp and rebooted in order to try the network thing to be better
20:26 jnthn timotimo: inf and neginf JIT?
20:28 timotimo already done :)
20:28 dalek MoarVM/openpipe3: a75be48 | FROGGS++ | / (11 files):
20:28 dalek MoarVM/openpipe3: improve openpipe to allow to read from out/err and write to in
20:28 dalek MoarVM/openpipe3:
20:28 dalek MoarVM/openpipe3: In the past were were only able to open a pipe to a process and read its
20:28 dalek MoarVM/openpipe3: stdout. There was no way to write to its stdin or read in its stderr without
20:28 dalek MoarVM/openpipe3: merging in into stdout via shell output redirection. Now we can do all this.
20:28 dalek MoarVM/openpipe3: review: https://github.com/MoarVM/MoarVM/commit/a75be48520
20:28 timotimo \o/
20:29 Peter_R joined #moarvm
20:30 FROGGS hoelzro: also look at the nqp test change I just pushed
20:32 hoelzro FROGGS: can you check >1 pipe at a time for new data?
20:33 timotimo something like select, yeah?
20:33 hoelzro right
20:33 FROGGS hmm?
20:33 hoelzro otherwise you could have a deadlock
20:34 hoelzro granted, you could probably use threads for this, yeah?
20:34 hoelzro FROGGS: I'll give this greater scrunity after $work
20:34 timotimo well, yeah, but that's not terribly efficient
20:34 timotimo because you'll block a whole thread for that purpose
20:35 hoelzro yeah
20:36 hoelzro but efficient > working > not working, right? =)
20:37 FROGGS aye
20:37 Ven joined #moarvm
20:38 timotimo hmm
20:38 timotimo i want us to have something like select
20:38 timotimo well, if you can get the underlying fd, you can nativecall into select of course :)
20:57 hoelzro hehe
20:57 dalek MoarVM/openpipe3: cc3c646 | FROGGS++ | src/io/procops.c:
20:57 dalek MoarVM/openpipe3: only check handle if we are meant to use it
20:57 dalek MoarVM/openpipe3: review: https://github.com/MoarVM/MoarVM/commit/cc3c646671
21:00 Ven joined #moarvm
21:37 ggoebel2 joined #moarvm
21:46 ggoebel joined #moarvm
22:04 ggoebel2 joined #moarvm
22:24 colomon joined #moarvm
22:26 ggoebel joined #moarvm
22:29 ggoebel2 joined #moarvm
22:33 ggoebel joined #moarvm
22:40 ggoebel2 joined #moarvm
22:58 ggoebel joined #moarvm
23:15 ggoebel2 joined #moarvm
23:22 ggoebel joined #moarvm
23:31 ggoebel joined #moarvm
23:44 ggoebel joined #moarvm

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