timotimo it seems like IO::Socket::Async explodes violently when you try to send data on an unopened socket 00:05
i'm trying to put in a check at the C level rather than introduce a $!closed or something 00:06
and i'm not quite getting it ...
hum ... 00:08
it's crashing, but it doesn't seem to happen the same way
and i can't find anything that'd be obvious to look at 00:09
my debuginfo packages all seem to be broken :\ 00:12
not matching what i have installed any more
04:03 FROGGS_ joined 04:32 vendethiel joined 04:58 ShimmerFairy joined 05:52 vendethiel joined 06:44 vendethiel joined 07:18 vendethiel joined 08:16 vendethiel joined 09:15 vendethiel joined
jnthn hah, DST...that's why I thought I slept unusually long :) 10:25
timotimo: The idle handler is looking for new work. There should be a better way to handle this.
10:28 JimmyZ joined 10:30 JimmyZ joined
dalek arVM: 788d64f | jnthn++ | src/6model/sc.c:
Improve "No foo at index 123" errors.

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