Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-03-29

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

All times shown according to UTC.

Time Nick Message
00:05 timotimo it seems like IO::Socket::Async explodes violently when you try to send data on an unopened socket
00:06 timotimo i'm trying to put in a check at the C level rather than introduce a $!closed or something
00:06 timotimo and i'm not quite getting it ...
00:08 timotimo hum ...
00:08 timotimo it's crashing, but it doesn't seem to happen the same way
00:09 timotimo and i can't find anything that'd be obvious to look at
00:12 timotimo my debuginfo packages all seem to be broken :\
00:12 timotimo not matching what i have installed any more
04:03 FROGGS_ joined #moarvm
04:32 vendethiel joined #moarvm
04:58 ShimmerFairy joined #moarvm
05:52 vendethiel joined #moarvm
06:44 vendethiel joined #moarvm
07:18 vendethiel joined #moarvm
08:16 vendethiel joined #moarvm
09:15 vendethiel joined #moarvm
10:25 jnthn hah, DST...that's why I thought I slept unusually long :)
10:25 jnthn timotimo: The idle handler is looking for new work. There should be a better way to handle this.
10:28 JimmyZ joined #moarvm
10:30 JimmyZ joined #moarvm
10:49 dalek MoarVM: 788d64f | jnthn++ | src/6model/sc.c:
10:49 dalek MoarVM: Improve "No foo at index 123" errors.
10:49 dalek MoarVM:
10:49 dalek MoarVM: Indicate the compilation unit that was involved in the version skew.
10:49 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/788d64fc70
11:50 vendethiel joined #moarvm
12:47 vendethiel joined #moarvm
13:00 colomon joined #moarvm
13:53 zakharyas joined #moarvm
14:09 colomon joined #moarvm
14:09 rurban_ joined #moarvm
14:09 FROGGS Probable version skew in pre-compiled '/home/froggs/dev/panda/ext/File__Find/lib/File/Find.pm' (cause: no object at index 296)
14:10 FROGGS https://gist.github.com/FROGGS/60d3852e84a16f496955
14:11 brrt joined #moarvm
14:17 kjs_ joined #moarvm
14:26 jnthn FROGGS: Yes, that's the improved reporting :)
14:27 FROGGS yeah, though I don't have a clue what goes wrong offhand :o)
14:27 FROGGS the only thing that looks weird is that it talks about a precomp thing and reports Find.pm
14:28 FROGGS and not Find.pm.moarvm
14:29 jnthn It pulls the description out of the SC
14:29 jnthn Which is the source file name
14:29 jnthn This could maybe happen if you pre-compile the Shell::Command module against a pre-comp'd File::Find
14:30 jnthn But then come load time it fails to find the pre-comp'd File::Find and goes for the source one instead and thus re-compiles it
14:31 FROGGS hmmm
14:31 jnthn Dunno if the env var you can set to debug module loads helps here.
14:34 FROGGS RAKUDO_MODULE_DEBUG
14:35 FROGGS jnthn: btw, I cannot reproduce your panda/panda-m issue on windows...
14:35 jnthn Aww
14:35 jnthn OK, I'll toss my install dir again on latest, later on
14:36 FROGGS or was that just about passing --ver before gen-meta?
14:36 jnthn No, panda vs panda-m was the issue
14:36 FROGGS hmmm
14:36 FROGGS weee-uhd
14:36 jnthn Were any of the PRs you sent for provides sections on my modules? :)
14:36 * jnthn sees no emails and guesses not
14:36 FROGGS https://github.com/jnthn/grammar-debugger
14:36 jnthn hmm
14:37 jnthn github, y u no email me
14:38 jnthn Merged that one, anyways..
14:38 FROGGS k
14:38 FROGGS :o)
14:38 jnthn I'm going to go through mine for what needs "use nqp" also :)
14:40 jnthn but, later :) &
14:41 FROGGS ahh grrr, I know why
14:42 FROGGS the File/Find.moarvm is installed as the first file, so it is just called '0'... which is falseish -.-
14:42 * FROGGS facepalms
14:50 dalek joined #moarvm
14:55 FROGGS no, it might not be that simple :/
15:04 colomon joined #moarvm
15:07 colomon joined #moarvm
15:15 vendethiel joined #moarvm
15:18 colomon joined #moarvm
15:24 brrt joined #moarvm
15:24 FROGGS okay, I know what heppens
15:24 FROGGS happens, even
15:46 colomon joined #moarvm
16:07 brrt joined #moarvm
16:56 mj41 joined #moarvm
17:20 colomon joined #moarvm
17:33 vendethiel joined #moarvm
17:36 colomon joined #moarvm
17:50 colomon joined #moarvm
18:06 colomon joined #moarvm
18:20 colomon joined #moarvm
18:23 colomon joined #moarvm
18:39 colomon joined #moarvm
18:59 colomon joined #moarvm
19:06 kjs_ joined #moarvm
19:18 kjs_ joined #moarvm
19:39 zakharyas joined #moarvm
20:01 psch joined #moarvm
20:01 psch \o
20:02 jnthn o/
20:02 psch jnthn: both calls to MVM_string_decode have MVM_encoding_type_utf8
20:02 psch i think default Configure.pl builds with linenoise and not readline?
20:03 jnthn Yes, default is linenoise
20:03 jnthn I was more curious about the other argument, as in what does linenoise give back in the ^D case?
20:07 psch hm, setting a bp in fileops.c:352 still straight SEGVs
20:07 psch i might be doing it wrong :)
20:12 psch well, neither MVM_file_readline_interactive_fh nor fileops.c:352 as breakpoint let me look at the return value of linenoise - both rather just SEGV
20:12 psch i don't think i can easily put my usual debug-prints there...
20:12 psch not to mention those usually are a bit less meaningful in C code
20:13 FROGGS jnthn: I try to make `num32 is rw` in signatures work... but the variable in P6 does not get updated...
20:13 FROGGS https://gist.github.com/FROGGS/7a95f8fd17b66fa51965#file-num32_is_rw-diff-L108
20:13 jnthn MVM_repr_set_num is surely wrong
20:13 FROGGS I correctly get the value back after the all, but set_num does ...
20:13 FROGGS ohh
20:13 jnthn In fact, you should probably never call that ever :)
20:13 jnthn It's changing the boxed value in a presumably immutable Int
20:13 FROGGS hmm, it felt sane :o)
20:13 FROGGS ups
20:14 jnthn For "is rw" we need to deal with the native ref stuff
20:14 jnthn psch: I wonder a bit if linenoise gives us back a NULL in the ^D case, and then we mis-handle that...
20:14 FROGGS hmm, I have no idea (yet) what exactly that means
20:14 jnthn FROGGS: Unfortunately, there's another problem... :(
20:15 jnthn FROGGS: When we code-gen native calls, we go and de-containerize all the arguments at the moment
20:15 jnthn FROGGS: Meaning the native ref never makes it to us
20:15 FROGGS hmmm
20:15 jnthn FROGGS: Well, it means you're wanting to do something like the assign_n op does.
20:16 jnthn But unfortunately, the other problem is going to block this bit.
20:17 jnthn +    void      **free_rws  = NULL;
20:17 jnthn That part of your approach is exactly what I'd have done, fwiw :)
20:17 FROGGS \o/
20:17 jnthn MVM_6model_container_assign_n is more like what you're looking for, anyways.
20:18 FROGGS yeah, as you said the assign_n results in 'Cannot assign to an immutable value'
20:18 jnthn Yeah, 'cus we strip :(
20:18 FROGGS but... just getting rid of the decontainerizing in nqp is also not enough, right?
20:19 jnthn Well, then we'd get a different problem
20:19 FROGGS do we have to conditionally decontainerize?
20:19 jnthn (Scalar containers around stuff)
20:19 psch "if (count == -1) return NULL;" says linenoise.c:405
20:19 psch and we init return_str = NULL
20:19 FROGGS (if that would be easily possible, which I think is not true)
20:20 psch and if(line) { ... } else { data->eof } ... return return_str;
20:20 psch jnthn: i think those might should mean you're right.  we're getting NULL from linenoise and return our initialization NULL
20:20 jnthn Yeah...that bit should be OKish
20:20 psch s/those/those bits/
20:21 psch (and minus one of should | might)
20:24 jnthn psch: Anyway, it seems like concatenate isn't being sufficiently careful about NULL inputs
20:25 psch jnthn: neither is say.  concatenate is where i found it because i concat for moreinput, but my golf SEGVs in say
20:26 jnthn *nod*
20:26 jnthn Yeah, looks like not much is.
20:26 jnthn Question is why we got away with this before now...
20:26 FROGGS ohh, we already had NULLs in concat
20:26 FROGGS but we usually solved what put the NULLs in there :o)
20:27 psch yeah, that's what i'm wondering
20:27 FROGGS making it more robust would "solve" a spesh bug Tux was hitting in Text::CSV
20:27 psch i mean, whether it's more sensible to not let any NULLs in or take care everything can deal if they come from somewhere even though they probably shouldn't anyway
20:28 jnthn my $newcode := nqp::readlineintfh($stdin, ~$prompt);
20:28 jnthn if nqp::isnull($newcode) || !nqp::defined($newcode) {
20:28 jnthn That's the code from HLL::Compiler
20:28 psch mostly from an tuit-efficiency perspective
20:28 jnthn psch: Well, I'd rather put guards for them into string ops.c tbh
20:29 jnthn nqp-m: my $x := nqp::null_s(); say(nqp::isnull($x))
20:29 camelia nqp-moarvm: OUTPUT«0␤»
20:29 jnthn nqp-m: my $x := nqp::null_s(); say(nqp::defined($x))
20:29 camelia nqp-moarvm: OUTPUT«1␤»
20:29 jnthn There the null string is boxed
20:30 jnthn And we test the box, which will never be null and always be defined
20:31 psch so readlineintfh should return a boxed NULL on EOF?
20:32 jnthn No
20:32 jnthn Ops that have native things to hand back never box stuff, by design
20:32 jnthn It's for the compiler to emit a "box this" op
20:33 jnthn The question is what we should do if asked to box a NULL string
20:35 jnthn We could return a null object (tc->instance->VMNull)
20:35 jnthn Which would make the code in HLL::Compiler actually work
20:45 brrt joined #moarvm
20:59 psch jnthn: i don't get it.  my golf dies in MVM_string_say in < if (!IS_CONCRETE((MVMObject *)a)) >, with a = 0x0
20:59 psch jnthn: i assume that means that whatever came from readlineintfh is NULL
20:59 psch jnthn: the golf itself doesn't box
21:05 jnthn psch: Yes, the problem is there's no !a || at the start of that if
21:06 jnthn IS_CONCRETE isn't a NULL check, it's a concreteness check assuming we have an object
21:06 psch ah, okay.  that's one of the spots that should be guarded then
21:06 psch similarly for concatenate i guess
21:06 jnthn yeah
21:06 jnthn I'm still pondering on the box null string question, though
21:06 jnthn We could just throw
21:10 kjs_ joined #moarvm
21:11 psch i think readlineintfh shouldn't return NULL, actually.  guarding in the say if throws on ^D, which isn't really useful behavior
21:13 jnthn Well, what should it return?
21:14 psch ...right.  a str is what's in memory, isn't it
21:14 jnthn ?
21:14 jnthn An MVMString * goes in an s register
21:15 jnthn That's the "str" type in Perl 6.
21:15 jnthn (And NQP)
21:16 jnthn I think the NULL is reasonable enough, it's just that boxing it into an object giving an object containing a NULL MVMString on it kicks the problem a long way too far down the road.
21:17 jnthn For now, I'd my str $newcode := ... in HLL::Compiler, and nqp::isnull_s
21:17 jnthn (and toss the !nqp::defined bit)
21:17 jnthn That'll work whichever option we pick for sanifying the "box a NULL"
21:17 jnthn And is probably what was intended anyway
21:18 psch i'm not seeing any trouble in HLL::Compiler, i found the SEGV in the moreinput branch with:
21:18 psch $more := nqp::readlineintfh(nqp::getstdin, '* ');
21:18 psch $cursor."!APPEND_TO_ORIG"($more);
21:18 psch but the same advice probably fits there as well
21:19 jnthn Yes, make $more a str
21:19 jnthn And do the check
21:19 jnthn Think I'll sleep on whether to throw or magically produce a null object
21:19 jnthn The fact I used "magically" to describe it probably means it's a bad idea :)
21:20 psch i'll sleep too, i think
21:20 psch understanding seems a bit hard right now
21:21 psch g'night \o
21:22 jnthn 'night o/
21:33 rudi_s joined #moarvm
21:34 kjs_ joined #moarvm
22:26 colomon joined #moarvm
22:36 colomon joined #moarvm
23:01 colomon joined #moarvm

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