02:48 hoelzro joined 03:55 harrow joined 04:02 flussence joined 06:18 oetiker joined 06:20 FROGGS joined
FROGGS jnthn: okay, so I return an array then in case it has to return more than one filehandle 06:25
06:25 brrt joined
brrt FROGGS: I'm not sure what perl6 does. but can't you return an object? 06:25
a pipe has at least two components; a PID and a stream 06:26
possibly two streams, possibly three
(possibly as many as you like. but three map to stdin/stdout/stderr)
FROGGS brrt: we return this one: MoarVM/src/6model/reprs/MVMOSHandle.h:13:struct MVMOSHandle 06:28
currently the openpipe op only allows you to spawn a process, and read its stdout
so I want to make it allow you to read both stdin and stdout, and also write to its stdin 06:29
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
don't we have a struct specific for a pipe 06:32
we should, i'd think
FROGGS we dont
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
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:35
maybe we should tripple that up 06:36
though the our ops like setencoding($filehandle, $encoding) wont work anymore
then* 06:37
brrt no, indeed
FROGGS so I guess we should keep having one filehandle per MVMOSHandle
brrt yes 06:38
FROGGS I'll play with it a little bit more today
brrt definitely
but openpipe should return a suitable pipe object
with pid
imho :-)
FROGGS I wont push to master until it all looks sane, dont worry :o)
brrt is not worrying
:-)
FROGGS the returned filehandle knows the pid at least
brrt oh really? 06:39
hmmm
FROGGS but making it: my $in=...; my $out=...; my $err=...; my $pid = nqp::openpipe($cmd, $env, $cwd, $in, $out, $err) would also look nice
yes, MVMOSHandle->body->ss->process or so 06:40
brrt aha
FROGGS we dont expose that yet though
(to P6)
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
which might be awesome if it works, but not so if it doesnt
brrt how would that work
FROGGS I dunno 06:42
brrt hmm 06:45
i do
the issue is that we've ambiguated around the OS level concept of a pipe
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
a subprocess-connected-via-a-pipe is what openpipe does
FROGGS brrt: though it is not "a-pipe"
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
but yes, that is precisely what you want ot achieve, so it is pipe
s
06:54 zakharyas joined 07:00 oetiker joined 07:07 Ven joined 07:16 Ven_ joined
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:38
and so i'm not willing to 'mix' them just hy 08:42
yet
09:22 Ven joined 11:36 Ven joined
timotimo i'd like to see "nan" be implemented in the jit 11:52
lizmat
.oO( also likes to see indian bread to be here just in time )
 11:53
FROGGS batura++ 11:56
timotimo :) 12:20
nan is now the op that prevents the biggest frame (as in: invoked the mont number of times) from being jitted 12:23
lizmat do you mean NaN ? 12:26
FROGGS the op is called nan 12:28
nqp-m: say(nqp::nan())
camelia nqp-moarvm: OUTPUTĀ«NaNā¤Ā»
timotimo yup 12:29
the first thing the frame does is assign nan to all the lexicals
i suppose i could make it compile by initializing the lexicals with 0 explicitly
jnthn nan shouldn't be hard to implement, no? 12:54
(In the JIT I mean)
I presume we already JIT iconst_n64
timotimo hm, i suppose? 12:55
i have to cast the num64 into a char* and then into an int64?
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 :)
timotimo no, you don't look at such a trivial thing! :P
FROGGS jnthn: do the hard things! 12:56
:P
timotimo how do you nan in C?
"nan"? "NaN"?
NAN apparently
jnthn See how we interp it :P
MVM_num_nan(tc) 12:57
That presumably does something portable/correct, so use it.
I suggest just MVMRegister tmp; tmp.n64 = MVM_num_nan(tc); 12:58
And then use tmp.i64 as the valbytes
timotimo ah
that's good
well, it doesn't bail any more ... 13:00
i'll push i suppose
dalek arVM: c43217e | timotimo++ | src/jit/graph.c:
jit getattrref_* and getattrsref_*
arVM: 2924b2c | timotimo++ | src/jit/ (2 files):
jit nqp::nan
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 13:54 Ven joined
timotimo i'm at the GPN now, but i'll be walking around a lot :) 14:11
FROGGS timotimo: have fun! 14:19
jnthn And eat a gulasch for me! :P 14:21
14:29 Ven joined 14:31 colomon joined 14:35 brrt joined
brrt \o kids 14:37
jnthn hello daddy! 14:38
brrt you can implement is_nan quite a bit more efficient than mvm_tc_is_nan iirc
:-P
jnthn Go for it :P
brrt yes yes yes, will try 14:39
oh, we're not checking for nan, but setting nan 14:40
hmm
oh nm, timotimo++'s patch is as nice as i would want it 14:42
anyway... we have plenty open pull requests standing 14:48
i'd like to merge some of them if that's ok with you
jnthn brrt: Which ones? 14:49
jnthn is happy to glance any brrt++ approves of 14:50
brrt github.com/cygx/MoarVM/commit/08be...7e04e1cb52 i like this one
github.com/MoarVM/MoarVM/pull/206/files this one is also clearly correct 14:51
github.com/MoarVM/MoarVM/pull/212/files and this one, too 14:54
jnthn resolve_open_mode can do an out-of-bounds memory access 'cus it fails to check the strlen of cp 14:55
oh, hang on
no, it does handle it
I misread :)
OK, +1 to the first one
206 is just leaving some code there that we should probably reinstate when we work out why it doesn't work 14:56
So -1 to that, we should find/fix the real issue 14:57
+1 to github.com/MoarVM/MoarVM/pull/212/files
dalek arVM: 08be906 | cygx++ | src/io/syncfile.c:
support opening files in modes besides r, w, wa
 14:58
arVM: 66b7db4 | cygx++ | src/io/syncfile.c:
add missing define
arVM: 5a31c9d | brrt++ | src/io/syncfile.c:
Merge pull request #215 from cygx/open-mode

Interesting patch, looks good.
brrt ok, i'll leave 206 as it is, then
dalek arVM: ba700a7 | paultcochrane++ | src/io/procops.c:
Destroy correct string decodestream

In spawn_gc_free() a branch which looks like it is supposed to destroy the stderr stream was actually destroying the stdout stream (which was happening in another code path) and thus is possibly a copy-paste error.		 14:59
arVM: d931587 | brrt++ | src/io/procops.c:
Merge pull request #212 from paultcochrane/pr/smoke-me/fix-possible-copy-paste-error

Destroy correct string decodestream
brrt the endian correction thingies, I can't really judge 15:00
oh, waitaminute 15:01
what do you think of github.com/MoarVM/MoarVM/pull/216/files ? looks reasonably innocent to me 15:04
hoelzro is there a opcode-level profiler for MoarVM? I'm curious how much time my program is spending on each opcode 15:06
jnthn No 15:07
hoelzro ok
shouldn't be that hard to hack into interp.c =)
FROGGS 216 looks good 15:08
this check can go entirely, right? github.com/bubaflub/MoarVM/blob/fi..._ops.c#L29
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) {
so codepoint_row shall be declared signed 15:10
hoelzro brrt: right, I figured as much
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
aye
dalek arVM: db72ab9 | jnthn++ | src/strings/utf8.c:
Non-characters are valid for UTF-8 encoding.

  See Unicode Corrigendum 9 for more information.		 15:48
[Coke] isatty/uv - uv_guess_handle() and test for UV_TTY ? 16:22
16:24 Ven joined 16:27 colomon joined 16:42 brrt joined 17:01 Ven joined 17:57 FROGGS joined
FROGGS my openpipe changes seem to work out 19:16
japhb Excellent, more pipe sanity. 19:33
19:51 mj41 joined
FROGGS Super Mario would be glad :o) 19:51
japhb Great, now I've got the theme music going through my head. 19:52
FROGGS hehe 19:56
timotimo fantastic. thanks for the triage, brrt 20:03
20:04 vendethiel joined
hoelzro FROGGS: is that up in a branch somewhere? 20:04
FROGGS hoelzro: not yet 20:05
hoelzro what kind of stuff did you do?
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?
was going to say - some spectests are bust on Power64 20:07
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
hoelzro FROGGS: nice! I was thinking about doing that with a module 20:10
jnthn Suspect pointer is suspect. 20:11
nwc10 oh yes.
most suspect
hoelzro FROGGS: I feel like you often beat me to things I want to do =) 20:12
FROGGS hoelzro: I hope that's okay Ć³.Ć²
hoelzro absolutely =)
FROGGS good :o)
hoelzro it just makes me feel a little lazy ;)
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:15
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
:P
nwc10: Or get a beer tap installed next to where you work. 20:17
nwc10 I'm sitting next to the beer 20:19
but a build of under 5 seconds isn't slow enough 20:20
jnthn oh...
nwc10 er, actually, strictly 12 according to time
including install
jnthn Smaller glass?
nwc10 which is single threaded
jnthn Kƶlsch style? :)
nwc10 :-)
hoelzro how does Windows handle the case where process A has a file open, and process B deletes it? 20:21
I'm wondering if it's similar to to Unix "A can still access the file's contents" semantics
jnthn hoelzro: It tells process B "no, that's an access violation", I think :P 20:22
hoelzro ah ha
FROGGS hoelzro: I'll push to moarvm and nqp in a minute 20:23
timotimo my network connection here is a bit thin, i have no idea why :( 20:24
jnthn It's hungry. Feed it more gulash!
.oO( or hungary... )
timotimo :)
hoelzro FROGGS++ 20:25
timotimo now that i'm back at my computer ... what was i about to do? 20:26
perl6/moarvm related things i mean
i was working on that benchmark ...
blergh, i had my scripts in /tmp and rebooted in order to try the network thing to be better
jnthn timotimo: inf and neginf JIT?
timotimo already done :) 20:28
dalek arVM/openpipe3: a75be48 | FROGGS++ | / (11 files):
improve openpipe to allow to read from out/err and write to in

In the past were were only able to open a pipe to a process and read its stdout. There was no way to write to its stdin or read in its stderr without merging in into stdout via shell output redirection. Now we can do all this.
timotimo \o/
20:29 Peter_R joined
FROGGS hoelzro: also look at the nqp test change I just pushed 20:30
hoelzro FROGGS: can you check >1 pipe at a time for new data? 20:32
timotimo something like select, yeah? 20:33
hoelzro right
FROGGS hmm?
hoelzro otherwise you could have a deadlock
granted, you could probably use threads for this, yeah? 20:34
FROGGS: I'll give this greater scrunity after $work
timotimo well, yeah, but that's not terribly efficient
because you'll block a whole thread for that purpose
hoelzro yeah 20:35
but efficient > working > not working, right? =) 20:36
FROGGS aye 20:37
20:37 Ven joined
timotimo hmm 20:38
i want us to have something like select
well, if you can get the underlying fd, you can nativecall into select of course :)
hoelzro hehe 20:57
dalek arVM/openpipe3: cc3c646 | FROGGS++ | src/io/procops.c:
only check handle if we are meant to use it
21:00 Ven joined 21:37 ggoebel2 joined 21:46 ggoebel joined 22:04 ggoebel2 joined 22:24 colomon joined 22:26 ggoebel joined 22:29 ggoebel2 joined 22:33 ggoebel joined 22:40 ggoebel2 joined 22:58 ggoebel joined 23:15 ggoebel2 joined 23:22 ggoebel joined 23:31 ggoebel joined 23:44 ggoebel 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!