00:10 benabik joined
timotimo i don't know how to do the roots thing, so i'll just leave it out for now and someone else can fix it :) 00:14
00:17 lizmat_ joined
timotimo requested a pull 00:20
diakopter timotimo: :) 00:21
need to root the first one around the next two statements
timotimo you mean i need to temp_root first_part and then pop it before returning the result? 00:22
diakopter timotimo: substring allocates
yes
bbl 00:23
timotimo pop without _n takes only tc, right?
Error while compiling op newexception: MoarVM op 'newexception' is unknown as a core or extension op 00:24
probably not as simple to implement
so i'll go to bed instead :)
huh, it actually looks really simple in java 00:26
well. maybe tomorrow. 00:33
01:13 jnap joined 01:15 Ben_Goldberg joined 01:21 BenGoldberg joined 01:43 jnap joined 01:44 dalek joined 01:45 BenGoldberg joined 04:13 jnap joined 04:27 benabik joined 06:15 jnap joined 07:24 benabik joined 07:55 FROGGS joined 08:17 jnap joined 08:47 ssutch joined 09:38 benabik joined 10:18 jnap joined 10:51 tgt joined
nwc10 jnthn: current rakudo-moar SEGVs for me on Linux 11:02
been running valgrind for a while; no answer yet 11:03
my NQP is cursor-mem-opts, or whateever it's called.
FROGGS nwc10: that even might be the problem I have/had using an optimized moar
nwc10: you can use master now again, since I merged that branch in
timotimo: if line 410 allocates, your MVMString *replacement might be borken 11:20
timotimo even in the newest commit? 11:21
FROGGS e180e3b
timotimo yeah 11:22
i don't understand :)
FROGGS you need to protect the objects that a) might get moved due to some allocation that b) will get used later on 11:23
timotimo oh, so before i do first_part, i need to push replacement as a temporary root? 11:24
FROGGS so, you need to protect first_part, because 413 might allocate and you use it in 416
correct
timotimo okay. and i don't need to protect original, because i only use it once at the start 11:25
FROGGS either you protect replacement there, or in the code that calls MVM_string_replace
timotimo is the rest_part temp push correct there?
FROGGS right, and there is no allocation before the only usage of original 11:26
yes
(I am glad that I finally understand it) 11:29
timotimo that new commit should do it finally 11:32
nope. 11:34
JimmyZ: thank you for your comments :) 11:36
FROGGS timotimo: err, you are pushing twice and popping 3 11:40
timotimo GOD DAMNIT 11:41
i'm going to squish all those commits now :)
FROGGS +1 11:43
:o)
nwc10 Normal: Stage parse : 396.823 11:45
Valgrind: Stage parse : 6522.205
timotimo hah
yeah :|
nwc10 expect next output to be the cause of the SEGV. 11:46
OK, how does this get mangled: 11:50
==27229== Invalid read of size 2
==27229== at 0x4F00883: MVM_interp_run (interp.c:2093)
==27229== by 0x4F8928F: MVM_vm_run_file (moar.c:150)
==27229== by 0x400C9D: main (main.c:137)
==27229== Address 0x4 is not stack'd, malloc'd or (recently) free'd
now running with gdb, as I'm guessing that's a structure access on a NULL pointer 11:51
arnsholt Yeah, that sounds plausible 11:52
timotimo that's not exactly helpful. it's just the same as gdb would tell us 11:53
we're doing an atpos_o on a null object
IS_CONCRETE(obj) blows up because it's a null pointer
nwc10 timotimo: except that it does tell us that there was no undefined behaviour prior to the thing that gdb says 11:55
timotimo oh!
good
when i'm in gdb at such a point, how do i find out where in the source code i am? can i easily get at the last line annotation?
nwc10 I think `where` might be the answer you're looking for 11:57
and yes, "IS_CONCRETE(obj) blows up because it's a null pointer" 11:58
nwc10 is now out to lunch
arnsholt timotimo: As long as you've got stuff compiled with -g, backtrace gives you the backtrace to where you're at 12:05
timotimo but not an nqp-level backtrace :) 12:06
arnsholt Oh, that kind of backtrace
Not AFAIK. jnthn would know, but probably not
timotimo jnthn is teaching right now, right? 12:07
maybe he'll get some insight in the evening
FROGGS timotimo: you use original twice now... was it like that before too? 12:35
timotimo yeah 12:36
i have to cut it up into two pieces
one goes before the replacement, one goes after
FROGGS I'm sorry, but I think you need to temp_push it then 12:37
timotimo JimmyZ: told me i don't :)
oh, wait. that was for something else
FROGGS that was for rest_part 12:38
timotimo there's the commit that fixes it
dalek arVM: b2da0b7 | (Timo Paulssen)++ | / (8 files):
naively implement nqp::replace
 12:44
arVM: 1522b37 | (Timo Paulssen)++ | src/strings/ops.c:
protect the original string between substring invocations
arVM: 0f2ec72 | (Tobias Leich)++ | / (8 files):
Merge pull request #64 from timo/replace_op

naively implement nqp::replace
FROGGS jnthn: it now builds m-BOOTSTRAP here using an optimized moar 13:09
diakopter timotimo: heh, if you're going to re-use rest_part like that, why need "result"? :)
13:10 cognominal__ joined
diakopter nwc10: right.. moar will crash right now on null pointers because no one's done the retrofitting for the special null-object 13:10
13:12 jnap joined
diakopter (but yes, IS_CONCRETE and friends will unfortunately need null-object checks added as well) 13:12
timotimo because i code without thinking 13:31
lizmat_
.oO( I don't paint, I hit! )
 13:34
13:41 cognominal joined
FROGGS do we actually know where the null pointer comes from? 14:06
14:50 jnap joined
FROGGS gdb++ # "warning: Source file is more recent than executable." 15:00
15:03 benabik joined
jnthn FROGGS: No, but that's easy enough to do: just add a null check at that point that throws an exception and see where we are :) 15:23
(but don't commit it)
FROGGS jnthn: ahh 15:25
okay
I added a breakpoint, but yes, a common nqp-ish die() would be better :o) 15:26
FROGGS adds that to all IS_CONTRET and commits
MUHAHAHAHAA
gah! 15:28
now I am even not typing C correctly on a keyboard where that key actually works >.<
umm 15:34
jnthn: I was meant to add a MVM_panic, right?
looks like I need to pass --ll-exception?
jnthn: can't I just call dump_backtrace(tc) ? 15:36
jnthn MVM_throw_adhoc(tc, "oops"); 15:39
diakopter MVM_exception_throw_adhoc 15:40
jnthn that one :) 15:42
FROGGS src/Perl6/World.nqp:980 (blib/Perl6/World.moarvm:prefix:<+^>:13) 15:45
jnthn wat...
FROGGS WAT 15:46
no 15:49
I think I messed with the backtrace... wait a sec
jnthn Gonna head back to the hotel now, so you can have plenty of secs 15:51
bbi20 or so
diakopter jnthn: I'm sure FROGGS appreciates you giving him more secs 15:52
FROGGS 20s? uhhh
it must explode every second
>.< 15:53
now it did not explode :(
MVM_exception_throw_adhoc seems to be noop-ish 16:03
ohh, I wonder... 16:05
16:16 benabik joined
FROGGS that is the bt I got earlier using backtracestrings(): gist.github.com/FROGGS/221a6f1254a114459581 16:22
MVM_exception_throw_adhoc just does nothing :/
jnthn diakopter: argh :P 16:42
bah, it does nothing 'cus something is catching the exception if it gets thrown... 17:09
17:14 ssutch joined
FROGGS[mobile] jnthn: then my backtracestrings are right-ish 17:47
17:50 dalek joined 18:27 FROGGS joined 18:28 jnap joined
FROGGS ahh, I meant dump_backtrace() btw 18:31
jnthn: btw, it must be something in P6::W line 975-980, when I add a newline before that block, and one after it, it complains about line 981 instead 980 18:39
and it would complain about 982 if it was something after that
I can't really parse the bt though 18:40
from src/Perl6/World.nqp:981 (blib/Perl6/World.moarvm:prefix:<+^>:13)
is it possible that it compiles a ode object about prefix:<+^> ? 18:41
FROGGS comments them out in Int.pm and similar 18:42
jnthn looks 18:43
FROGGS: Oh, it's the stub code, which take sthe name of whatever it's stubbing 18:45
FROGGS jnthn: what stub code? 18:46
jnthn The dynamic comp stubb
But I dunno where the empty/null array comes from 18:47
Or is tht the top line of the backtrace?
FROGGS now it omplains about infix:<~> after commenting out:
/home/froggs/dev/rakudo/src/core/Int.pm:268:multi prefix:<+^>(Int:D \a) {
/home/froggs/dev/rakudo/src/core/Int.pm:271:multi prefix:<+^>(int $a) {
hehe is the bt: gist.github.com/FROGGS/221a6f1254a114459581
jnthn oh... 18:48
my $past := nqp::getattr($_, $code_type, '$!compstuff')[0];
It's that [0]
FROGGS so we just need to check if getattr gives us something? or do we need to fix the part that needs to put something into compstuff? 18:49
18:51 eternaleye joined
jnthn Yeah. Got a patch locally 18:51
No, it's fine compstuff is gone by then I think...
FROGGS: Pushed it. Now we're into the mast phase. 18:58
I get something about replace, but I saw that got worked on earlier...
FROGGS I think timotimo wanted to grab that task, but I think he has not started yet 18:59
jnthn I'll maybe look more after some dinner BUT I also promised somebody to finish their slides...
ah, ok
FROGGS <dalek> MoarVM: b2da0b7 | (Timo Paulssen)++ | / (8 files):
<dalek> MoarVM: naively implement nqp::replace
jnthn Anyways, nice that we now make it to one of the final compilation stages.
FROGGS hold on, that is there
jnthn Oh, I didn't pull anything yet 19:00
FROGGS yes, very nice :o)
FROGGS maps replace now 19:08
right, the next one is newexception 19:16
FROGGS tests 19:23
dalek arVM: 77490b3 | (Tobias Leich)++ | / (6 files):
implemented op newexception
 19:31
FROGGS now: 19:32
Stage optimize : 39.860
Error while compiling op p6routinereturn: No registered operation handler for 'p6routinereturn'
nwc10 Stage optimize : 87.342Error while compiling op newexception: MoarVM op 'newexception' is unknown as a core or extension op 19:37
om nom nom. terminal eats newlines 19:38
FROGGS nwc10: pull moarvm :o)
nwc10 Error while compiling op p6routinereturn: No registered operation handler for 'p6routinereturn' 19:58
FROGGS right 19:59
20:03 cxreg joined
cxreg (taking to the right channel) node.js had a usage bug against libuv, not sure if it's interesting or relevant here 20:03
www.joyent.com/blog/walmart-node-js-memory-leak
github.com/joyent/node/commit/1693...5d636ce693 20:04
i don't grok the API enough to know, but it looks subtle so i thought you'd like to see it
FROGGS reads 20:05
cxreg++ 20:06
that sounds highly relevant
cxreg cool
FROGGS now I can bang my head aginst the handles again :o)
cxreg :)
FROGGS ahh, no... I misread, I thought it actually is about filehandles :o( 20:12
cxreg it's not? i thought so too 20:15
FROGGS it is about callback handles 20:16
p6routinereturn seems doable 20:21
jnthn has forgotten what it even does :) 20:23
FROGGS I would almost guess that this has something to do return from subs through a pointy 20:26
with returning*
FROGGS stubbed p6routinereturn 20:35
p6recont_ro is missing after that 20:42
jnthn Port it or stub it... :) 20:43
FROGGS I'll port p6routinereturn first I think 20:45
jnthn k
FROGGS I think I'll just stub it :o( 21:00
21:00 jnap joined
jnthn ETOOSCARY? 21:02
21:02 woolfy left
FROGGS a bit 21:02
21:04 woolfy joined
FROGGS p6finddispatcher would be next 21:37
jnthn Even stubbing all of these helps 21:38
FROGGS really?
jnthn Yeah.
FROGGS k
jnthn #cus if it's me that needs to write them, I can fill out the stubs without too much trouble
But creating them is tedious :) 21:39
FROGGS sounds good :o)
jnthn If there's any binder ones left, though, don't turn them into ops
They become methods in the Binder class in BOOTSTRAP
FROGGS k 21:40
21:53 BenGoldberg joined
FROGGS maybe I do xor tomorrow when my brane is awake again 22:52
jnthn Sounds like a good xor bad idea... 22:56
FROGGS hehe 23:02
23:23 ssutch joined
FROGGS compiles xor 23:40
it is already tomorrow, isnt it?
timotimo yeah :)
FROGGS p6stateinit would need stubbing then 23:51
timotimo can you tell to which line we get?
FROGGS no, can't tell 23:55

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!