08:04 FROGGS[mobile] joined 08:08 cognominal joined 09:08 cognominal joined 11:08 ssutch_ joined 11:36 woolfy1 joined, lizmat_ joined 12:06 tgt joined 12:24 lue joined 13:20 lizmat_ joined 13:21 woolfy joined 13:33 woolfy1 joined
jnthn I think savecapture may be mishandling flattening... 14:09
FROGGS in interp.c or in MVM_args_proc_init? 14:16
jnthn Probably in interp.c
yeah, I think it's wrong. 14:18
It is. It pairs the flattened args with an unflattened call site. 14:20
FROGGS hmmm, I can only scratch my head when looking at that code :o) 14:23
jnthn bah, my first attempt to fix it was wrong too :) 14:26
FROGGS O.o 14:29
jnthn: is that you?
jnthn D'oh, invokewithcapture is also wrong :)
Thing is, flatten_args does a mixture of mutable and immutable things. 14:30
FROGGS /o\ we are lost /o\ 14:31
jnthn Yeah. This is a bit icky. 14:32
callsite points off to the original callsite,, so we still have that. But we no longer have the original args.
'cus we flattened those in place.
FROGGS ahh, in place 14:33
sounds like either super optimised or a bad idea :o) 14:34
jnthn And there's no MVMCallSite that represents the result of the flattening.
Well, we don't really wan to re-flatten...
*want
So we may as well re-use the work
Though the Easy Fix is to not do so... 14:35
An MVMCallSite has an arg_count, num_pos, and a set of flags 14:36
And a MVMCallSite does also...
oops, and an arg proc context does 14:37
dalek arVM: 98a32f0 | jnthn++ | src/ (3 files):
Fix capture objects / flattening interaction.

In the case flattening took place, we want to re-use the work, but we must have an MVMCallsite that describes the work. Otherwise, we use an out-of-date one, which confuses anything on receiving end of being invoked with the capture. Future simplifications are likely possible, but this moves things forward a step in getting Rakudo working.		 15:10
FROGGS extension op 'p6isbindable' not registered # \o/ 15:13
jnthn++ # :o)
ohh 15:39
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff79df4a6 in MVM_gc_root_add_gen2s_to_worklist (tc=0x6033c0, worklist=0x47ab900) at src/gc/roots.c:193
193 if (*cur_item_ptr && !((*cur_item_ptr)->flags & MVM_CF_SECOND_GEN)) {
:o(
#8 0x00007ffff799997a in MVM_args_slurpy_positional (tc=0x6033c0, ctx=0x4816988, pos=1) at src/core/args.c:400 15:40
jnthn How'd you get that?
FROGGS gist.github.com/FROGGS/365ffb89aa33b12ac65a 15:41
jnthn Weird 15:43
FROGGS jnthn: I'll reconfigure/reinstall moar/nqp/rakudo
jnthn: still the same 15:57
I guess we are missing an MVMROOT at src/core/args.c:400 15:58
Positional parameter binding NYI 16:05
\o/
jnthn \o/
That's the one I'm working on at the moment :)
FROGGS jnthn: I guess this is sane then? gist.github.com/FROGGS/83d27ce3d9c3b67f7753
nwc10 doesn't work on "my" machine - Rakudo build fails with: 16:06
gcc: dynext/perl6_ops.o: No such file or directory
command line is: 16:07
gcc -c -fPIC -g -D_REENTRANT -D_FILE_OFFSET_BITS=64 -fPIC -O3 -I/home/nicholas/Sandpit/moar-g/include/libatomic_ops \ -I/home/nicholas/Sandpit/moar-g/include/dyncall -I/home/nicholas/Sandpit/moar-g/include/linenoise -I/home/nicholas/Sandpit/moar-g/include/moar \
jnthn FROGGS: I assume we use type later on, after the allocate?
nwc10 -I/home/nicholas/Sandpit/moar-g/iclude/sha1 -I/home/nicholas/Sandpit/moar-g/include/tinymt -I/home/nicholas/Sandpit/moar-g/include/liabtommath \ -I/home/nicholas/Sandpit/moar-g/include/libuv -I/home/nicholas/Sandpit/moar-g/include dynext/perl6_ops.o src/vm/moar/ops/perl6_ops.c
I think that that command line is missing an -o
FROGGS jnthn: yes, it is passes to box_slurpy 16:09
hmmm
nqp-m --show-config | grep "\-o" 16:10
moar::ldout=-o
nwc10: ^^ can you run that?
nqp-m: say(nqp::backendconfig<ldout>)
camelia nqp-moarvm: OUTPUTĀ«-o ā¤Ā»
FROGGS or that 16:11
jnthn FROGGS: Then, needed.
FROGGS++
FROGGS yay!
:o)
timotimo \o/ 16:12
always happy to see moarvm progress
nwc10 moar::ldout=-o
dalek arVM: 54ebe1d | (Tobias Leich)++ | src/core/args.c:
gc_root type
FROGGS hmmm
rakudo$ grep ldout tools/build/Makefile-Moar.in 16:13
$(LD) @moar::ldswitch@ @moar::ldshared@ $(LDFLAGS) @moar::ldout@$(M_PERL6_OPS_DLL) $(M_PERL6_OPS_OBJ) $(M_PERL6_CONT_OBJ) @moarimplib@
that is there too?
if that is positive too, then you must have an outdated nqp or so 16:14
nqp-m --version
This is nqp version 2013.10-241-gfd308ad built on MoarVM version 2013.10-130-g98a32f0
nwc10 $(LD) @moar::ldswitch@ @moar::ldshared@ $(LDFLAGS) @moar::ldout@$(M_PERL6_OPS_DLL) $(M_PERL6_OPS_OBJ) $(M_PERL6_CONT_OBJ) @moarimplib@
FROGGS that is sort of HEAD
nwc10 $ ~/Sandpit/moar-g/bin/nqp-m --version 16:15
This is nqp version 2013.10-241-gfd308ad built on MoarVM version 2013.10-130-g98a32f0
Segmentation fault
FROGGS yeah, ignore the segfault...
but
hmmm
is the -o in the Makefile ?
I mean, can't be
wait wait wait 16:17
-I/home/froggs/dev/rakudo/../nqp/install/include/libuv -I/home/froggs/dev/rakudo/../nqp/install/include dynext/perl6_ops.o src/vm/moar/ops/perl6_ops.c
gcc: warning: dynext/perl6_ops.o: linker input file unused because linking not done
nwc10 and if you remove that file? :-) I think that your build will then fail
FROGGS I think it has a problem with the missing space?
jnthn had stripped the space to make it work on windows... 16:18
but.... that wouldn't work either
nwc10 there are two lines after this line: 16:20
$(M_PERL6_OPS_DLL): $(M_PERL6_OPS_SRC) $(M_PERL6_CONT_SRC) Makefile
the first has no -o anywhere. The second does
er, two command lines to invoke gcc
FROGGS I see it
the first two stmts, which produce the .o use @moar::ccout@ 16:21
the third stmt actually creates a dll
but only one, where we need two
so, two errors 16:22
nqp-m: say(nqp::backendconfig<ccout>)
camelia nqp-moarvm: OUTPUTĀ«-o ā¤Ā»
FROGGS the %config's in Configure.pl do *not* contain ccout 16:26
only ldout
16:36 lizmat joined, woolfy joined
FROGGS nwc10: it looks like nqp-m --show-config hides ccout 16:37
<FROGGS> yeah, ignore the segfault... </HEADDESK> 16:42
wow 16:46
nqp-m --show-config | grep ar
moar::ar=ar
moar::cco
there is something in that string...
at least when printing it 16:47
apparently not when accessing it via backendconfig
jnthn Turns out we never brought the associative API in line with the positional one 17:02
jnthn is working on clearing that up now 17:03
jnthn looks at box_slurpy in args.c and cries 17:26
This is EXACTLY the wrong use of abstraction :/
Making future changes a complete pain in the arse.
What should be a 2 minute code tweak will now take 10 minutes of understanding this shit...
...and another couple of minutes wasted ranting on IRC about it... :) 17:27
TimToady well, at least the ranting part is fun... 17:35
FROGGS (good that I did not wrote this) 17:45
jnthn FROGGS: If you're ever tempted to put in a macro taking ~15 arguments, resist it :) 17:49
FROGGS err, yes 17:50
:o)
moritz erm, wat? 17:55
dalek arVM: 3657daa | jnthn++ | src/ (15 files):
REPR at_key_[boxed|ref] become at_key.

We pass the result register and also the kind down. This brings at_key in line with at_pos. Some cleanups along the way, and MVMContext gets to start working with natives as a side-effect.		 17:58
arVM: 384ae2c | jnthn++ | src/6model/ (6 files):
Toss bind_key_ref.

Will use the generalized bind_key in its favor.
jnthn Darn, it missed the third commit...
FROGGS yeah 18:00
MoarVM$ LC_ALL=C make
linking moar
./libmoar.so: undefined reference to `MVM_repr_bind_key_boxed'
jnthn FROGGS: huh...
Missing dependency?
FROGGS config.c uses that 18:01
dalek arVM: 020c732 | jnthn++ | src/6model/reprs/MVMContext.c:
Implement MVMContext.bind_key.
jnthn Hm...how'd I not get the error?
FROGGS dunno
jnthn oh, do you have to make clean to get it?
Or when is config.c generated?
FROGGS maybe you need to reconfigure to hit it 18:02
when configuring
jnthn ah
yeah, that'd do it
yup
fixing 18:03
dalek arVM: 0e9e19a | jnthn++ | build/config.c.in:
Update config.c.in with function name change.
 18:04
FROGGS jnthn+
jnthn++
jnthn Time to shop, cook dinner, etc. 18:10
FROGGS ahhhaha
I know why the ccout is not showing up correctly
a funny thing atually 18:11
actually*
nqp-m --show-config > cfg.out
ll cfg.out
-rw-r--r-- 1 froggs froggs 8192 Nov 16 19:10 cfg.out
and that cfg.out ends with: moar::cco
(2**something)++ 18:12
TimToady hahaha 18:19
TimToady blames the GC for making it impossible to close files automatically :)
do we need an EXIT phaser? 18:21
oh, wait, we have one :)
(called END) 18:22
or maybe it's the language designer's fault for missing an important scoping mechanism somewhere... :) 18:23
we're kinda weak on transactional scopes...
file closing is kind of an autocommit if there has been no rollback transaction 18:24
maybe we just need some official RAII mechanism that requires user intervention to propagate ref-counted objects, and requires everyone with a ref to "close" it. 18:31
well, probably wrong channel for such speculatin' 18:32
but this whole idea of "doneness" seems rather fragmented 18:34
FROGGS the fh closing issue is kinda weird 18:36
TimToady the one you're looking at?
FROGGS because we're opening the std filehandles in the compiler and in the to-be-compiled code... and it is hard to know (for me) when it is safe to close it 18:37
TimToady maybe it's more of an fflush issue?
FROGGS well, I am not sure the "ccout-problem" is related to the std-filehandels-problem
yeah
probably
nqp-m -e 'say(nqp::x("a", 10_000))' | wc 18:40
1 1 10001
hmmm
TimToady that looks rightish
FROGGS it does
nqp-m --show-config | wc 18:41
102 319 8192
:/
TimToady that looks negatively rightish
FROGGS as if it behaves differently in the compiler 18:44
okay, libuv has an output buffer of 8192 19:20
jnthn mebbe something is calling a write function and thinking it will write everything, when it only promises to write some of it: 19:24
?
FROGGS no
I hecked our say op
and it does a fwrite, which writes all it gets 19:25
I printed the the same string to stderr, and it comes out correctly, while the stdout-put is truncated when piping it
jnthn Don't forget to purgatory to print op... 19:26
*the 19:27
FROGGS I wat? 19:32
jnthn Was just punning on your typo :P 19:35
FROGGS which one? :P 19:36
ahh, "which"
no
wat? 19:37
jnthn < FROGGS> I hecked our say op 19:38
FROGGS that bloody c 19:39
err
it seems that my brane is already turned off
jnthn haha
FROGGS feels almost diakopterish :P 19:40
hold on, it can't be libuv 19:45
since we're just using fwrite
Program received signal SIGSEGV, Segmentation fault. 19:48
0x00007ffff7a03cf7 in gc_free (tc=0x6033c0, obj=0x7ffff67e2910) at src/6model/reprs/MVMCallCapture.c:55
55 if (ctx->body.effective_callsite != ctx->body.apc->callsite)
that happens at the end of nqp-m --show-config 19:49
don't think it is related though
jnthn eek 19:51
Can you work out why it SEGVs? Is something null?
FROGGS gist.github.com/FROGGS/49b9270a8e216e05a46a 19:53
not very helpful I guess 19:54
I'll run valgrind
jnthn Hm, isn't it 19:55
p ctx->body.effective_callsite
To see what it is?
and p ctx->body.apc
19:55 woolfy joined
FROGGS gist.github.com/FROGGS/49b9270a8e2...6a#file-vg 19:55
hold on
19:56 lizmat joined
FROGGS 0x00007ffff7a03cf7 in gc_free (tc=0x6033c0, obj=0x7ffff67e2910) at src/6model/reprs/MVMCallCapture.c:55 19:56
55 if (ctx->body.effective_callsite != ctx->body.apc->callsite)
(gdb) p ctx->body.effective_callsite
$1 = (MVMCallsite *) 0x0
p ctx->body.apc
$2 = (MVMArgProcContext *) 0x0
jnthn Hmm.
FROGGS p ctx->body
$3 = {apc = 0x0, effective_callsite = 0x0, mode = 0 '\000'}
jnthn I wonder how it gets like that... 19:57
I mean, we can avoid the segfault by checking ctx->body.apc ain't null.
FROGGS hmm 19:59
20:21 ssutch joined
dalek arVM: c0779bd | jnthn++ | / (6 files):
Provide a capturenamedshash op.

Gets the names in a capture as a hash. Needed for Rakudo binder.		 20:28
arVM: 9e56dc1 | jnthn++ | src/core/frame.c:
Don't uncoditionally trash ->caller on unwind.

If an exception is thrown, ->origin points to the frame we threw from. If we tried to get the backtrace after the unwind happened, the caller chain was already trashed, even though ->origin ref'd the frame. Move clearing up the caller chain to frame ref-count decrement to avoid the problem.		 20:53
FROGGS ummm 21:01
jnthn: that segfault in MVMCallCapture.c does trigger the ccout-issue 21:02
(which is good actually)
jnthn oh...
FROGGS so I don't have to hunt two bugs :o)
jnthn Gimme a moment and I'll try the patch I thought of
FROGGS ohh, okay
jnthn (sorry, I sorta thought you were trying it, but looking back I had no reason to think you were...)
timotimo gcc: error: dynext/perl6_ops.o: No such file or directory 21:03
i'm not sure what's going on?
FROGGS jnthn: trying what? I tried to hunt down both issues
timotimo: lay back, jnthn++ sorts it out :o) 21:04
timotimo dynext is apparently intentionally left blank?
FROGGS yes, because the configure script can't get the moar::ccout config var value
because there is a segfault in gc_free of the callsite repr
*g*
what a weird thing, ehh?
timotimo o_O 21:06
yeah, i agree
dalek arVM: fe8d4bd | jnthn++ | src/core/exceptions.c:
Give backtrace strings useful content.

Line numbers/files, not just the routine name.		 21:29
arVM: 360af6c | jnthn++ | src/core/ (2 files):
Fix corrupt index in first backtrace line.
arVM: b9cbb62 | jnthn++ | src/6model/reprs/MVMCallCapture.c:
Missing null check.
 21:30
jnthn FROGGS: Hopefully ^ makes things better 21:42
FROGGS jnthn++ # it works! \o/ 21:45
timotimo so, er, what works now? can i try to compile again? 21:46
FROGGS yes
rakudo should build again 21:47
timotimo oooh
FROGGS well, "build" :o)
perl6_ops.so should be made
yes! 21:51
-o dynext/perl6_ops.o
nwc10: ^^
WARNING: nominal type check NYI 21:54
I think that means "yay" :o) 21:55
timotimo "make m-install" starts java-related compilations :\ 21:57
i'm not getting it to work, tbh (: 21:58
:(
FROGGS timotimo: do a --backends=moar 21:59
timotimo did that 22:00
FROGGS dunno why it clashes with jvm if you pass that too
timotimo in that case it doesn't any more
but the dynext is still not existing for me. oh well. not that important
jnthn Looks like we're at around line 359 into CORE.setting, fwiw 22:19
FROGGS wow 22:20
I thought we are still at around line 50 :o)
jnthn We crash now in multi trait_mod:<is>(Routine:D $r, :$rw!) { 22:21
Which is first called from the "is rw" on from line 359
Ah, yeah. And...now we get to the point where we start discovering containers :) 22:24
FROGGS hehe, right, we never had them before 22:26
now you need to say that the jvm port was way more painful 22:28
well, it is not really painful for me, I am just feeling totally useless :o) 22:29
jnthn FROGGS: One thing you could look at: I think make clean in Rakudo doesn't clear dynext up... 22:34
FROGGS k 22:35
and I'll look at the thing timotimo reported (--backends=jvm,moar && make m-install will make jvm) 22:36
but I'll do that tomorrow
dalek arVM: fedb647 | jnthn++ | src/core/bytecode.c:
Correct bytecode sanity check.
 23:21
arVM: 69cc214 | jnthn++ | src/core/bytecode.c:
Fix annotations thinko.
arVM: 6b678b1 | jnthn++ | src/ (4 files):
Fix arg_flags lifetime wrt effective callsite.
FROGGS ohh, I get backtrace now instead of a segfault after the NYI 23:23
jnthn :) 23:25
FROGGS I like it :o) 23:26
gnight jnthn o/ 23:37
dalek arVM: ec52026 | jnthn++ | src/core/ (2 files):
Tweak lexical lookup semantics.

This brings them in line with what we need in Rakudo, though we may want to re-visit this across all backends in the future.
jnthn Line 453
'night, FROGGS
timotimo 'night jnthn :) 23:40
er
'night FROGGS 23:41
jnthn Yes, I've some more beer + hack to go :)
timotimo that's nice to hear :)
jnthn Oh darn 23:42
I was wrong above.
It's more like 409
timotimo still a decent step from 359 before 23:45

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!