github.com/moarvm/moarvm | IRC logs at irclog.perlgeek.de/moarvm/today
Set by moderator on 8 October 2013.
JimmyZ diakopter: llir? 01:06
yoleaux 9 Oct 2013 17:37Z <diakopter> JimmyZ: how hard woudld it be to add uint_ptr-sized atomic loads/stores to TCG?
JimmyZ .tell diakopter '--dump nqp.moarvm' doesn't work looks like because of an gc bug 01:21
yoleaux JimmyZ: I'll pass your message to diakopter.
diakopter JimmyZ: .ll (llvm's IR) 01:52
yoleaux 01:21Z <JimmyZ> diakopter: '--dump nqp.moarvm' doesn't work looks like because of an gc bug
JimmyZ diakopter: I think llir is much rich(or plentiful) 02:08
but I like the tcg one
llir has float and vector support and tcg doesn't 02:09
Optimizing directt hreaded code by selective inlining: citeseerx.ist.psu.edu/viewdoc/down...p;type=pdf 02:20
^^ this may be useful for the CGOTO core
s/directt hreaded/direct threaded/ 02:24
jnthn why does --dump trigger GC? 06:58
JimmyZ MVMString gc_free 07:00
which is called by collect.c ...
jnthn yes, why are we in collect.c? 07:03
I don't see why --dump should need to allocate 07:04
JimmyZ MVM_string_utf8_decode?
it allocates MVMString 07:05
jnthn yes, why are we doing that? 07:06
But anyway, easy fix is just to force gen2 allocation which never fills the nursery and so never runs GC
Which is what other sensitie-to-movement things do 07:07
07:15 FROGGS joined 07:17 odc joined
FROGGS .tell jnthn linux, I tried to check/debug that on linux but failed to get a connection to github with my virtualbox 07:43
yoleaux 9 Oct 2013 16:47Z <jnthn> FROGGS: what platform do you see the heisenbugs on?
FROGGS: I'll pass your message to jnthn.
07:52 cognominal joined
FROGGS .tell jnthn current state on my box :o( gist.github.com/FROGGS/ee72300abe8a460a1fcb 08:04
yoleaux FROGGS: I'll pass your message to jnthn.
jnthn FROGGS: yes, you'er meant to tell me ABOUT YOUR BOX... 08:41
yoleaux 07:44Z <FROGGS> jnthn: linux, I tried to check/debug that on linux but failed to get a connection to github with my virtualbox
08:04Z <FROGGS> jnthn: current state on my box :o( gist.github.com/FROGGS/ee72300abe8a460a1fcb
jnthn oh, you did :)
At least it now segfaults rather than just giving wrong answers... 08:42
FROGGS :o( 08:47
jnthn: I made a fresh stage0 but it still fails like in the gist
jnthn wish it said which lline in MVM_gc_root_add_tc_roots_to_worklist () 08:56
FROGGS yeah 09:03
jnthn debug build? 09:05
FROGGS you mean GCDEBUG? 09:07
jnthn no, I mean with --optimize 09:08
so gdb gives you line numbers too?
uh *without*
FROGGS hmm, I don't think it was built with --optimize
lemme check
jnthn oh...
:S
gdb-- then :)
jnthn hugely prefers the VS debugger
arnsholt gdb normally tells you which line when the information is available 09:17
gdb is a bit pants, I agree, but it's not *that* bad =)
JimmyZ .oOo. 09:35
yoleaux JimmyZ: Sorry: that command is a web-service, but it didn't respond in plain text.
tadzik hah 09:36
masak kids and bots: unintentionally funny. 09:44
FROGGS jnthn: CONFIG = --prefix=../nqp/install --optimize 10:59
:P
gdb++
jnthn bah :P 11:12
Most problems are between the chair and keyboard :P
So do you know where in that functin it blows up now? :) 11:13
FROGGS jnthn: compiling nqp atm
diakopter visual studio can include --debug when --optimize 11:14
it's nice.
tadzik in a laptop, CPU is between chair and keyboard
FROGGS aww, it takes soo long when it is not optimized :o(
soooo long 11:15
JimmyZ it takes about 1.5G memory to compile QAST.nqp on linux x64
with --optimize 11:16
FROGGS jnthn: updated gist.github.com/FROGGS/ee72300abe8a460a1fcb 11:17
src/gc/worklist.c:21
and I see MVMIter.c:153 down there
jnthn MVM_gc_root_add_tc_roots_to_worklist (tc=0x82a310, worklist=0x24a9db0) at src/gc/roots.c:68 11:19
is, if the code you have matches github
Any active exception handlers.
diakopter JimmyZ: wow
jnthn hmmm :)
FROGGS lunch & 11:20
jnthn um, that code is really wrong... 11:26
Which idiot wrote this... :)
diakopter erm
11:27 woolfy joined
jnthn If it didn't SEGV it'd be an infinite loop o.O 11:27
diakopter woolfy: hi
11:27 lizmat joined
diakopter lizmat: hi 11:28
jnthn oh, I get it noms memory and then malloc fails
*bet
woolfy \\o/
jnthn no, malloc failing is not \\o/ :P
Can't fix it right now...teaching git :) 11:29
woolfy sorry, I meant: diakopter: \\o/
jnthn will look later
diakopter jnthn: what line
jnthn: what are you looking at
woolfy you teach the git, go ahead
jnthn oop at 68
loop
diakopter what file?
jnthn woolfy: Well, just supervising practical session at the moment which is why I have a moment
diakopter: roots.c
diakopter: Where it walks the active exception handler list. 11:30
apart from it doesn't walk :)
diakopter whaaa 11:31
dalek arVM: 06c6ae7 | diakopter++ | src/gc/roots.c:
walk
 11:32
diakopter JimmyZ: does it still use 1.5GB memory? 11:33
jnthn FROGGS: Hopefully what diakopter++ just committed helped 11:42
diakopter NQPHLL.pm takes 1GB
QAST.pm takes 2.0GB 11:43
NQP.pm takes 1.7GB 11:44
QRegex.pm takes 800MB
nwc10: I don't think the Pi could do this ^ 11:46
jnthn diakopter: Will be interesting to see what we can get it down to :) 12:39
FROGGS jnthn: it seems to work now btw
unoptimized + optimized build
diakopter++ :o) 12:40
and jnthn++ because I think the starter/stopper patch helped too to resolve this
jnthn yay 12:44
FROGGS: Do you need the heisenbug comments still?
FROGGS jnthn: no, I'm going to strip them now
stats: gist.github.com/FROGGS/e68b078d959b72262d3b
jnthn strip! strip! 12:45
I have 2 more failuers than that on Windows, from IO tests 12:46
FROGGS yeah, Windows is not that good for IO stuff in general 12:47
:P
jnthn :P
moritz does moarvm's Configure.pl dump its %config hash anywhere? 12:51
jnthn not afaik 12:52
moritz ah, wrong approach
FROGGS no, don't think so
moritz I suppose I can just give Configure.pl an option --install
which runs $config{make} install for me
that makes it easier for nqp's Configure to get a --gen-moar option 12:53
jnthn I think NQP calls it --make-install or so... 12:54
Or Rakudo maybe...I forget :)
moritz nqp does allright
dalek arVM: c87e935 | moritz++ | Configure.pl:
Configure.pl --make-install

this makes it easier for the nqp ConfigureMoar.pl to build moar		 13:01
jnthn :)
tadzik nice 13:03
moritz is it normal that the JVM takes about about 3 cores while compiling the setting? 13:06
ugh, www
*ww
masak .oO( to be fair, "ugh" is how I feel sometimes about the world wide web ) 13:19
FROGGS Use of undeclared variable '$node' at line 4068, near ".list, $*B" 13:20
:o(
masak FROGGS: where/what is this? 13:34
moritz fwiw if we start to require specific versions of moar for nqp, we should start tagging, so that 'git describe' works 13:38
FROGGS masak: that happens when I add a say() statement to Nodes.nqp to debug something 13:40
masak: which is what I called the "heisenbug" the last days, which seems to just have changed its behaviour but has not disappeared as I hoped 13:41
masak moritz: as soon as we need it, we can always tag something retroactively, I guess. 13:53
moritz: like, the commit closest to The Reveal could be tagged v0.1 or something. 13:54
or something with more personal flair, even.
JimmyZ make: *** [src/stage1/ModuleLoader.moarvm] Segmentation fault (core dumped) 13:55
jnthn JimmyZ: Patches welcome :P 13:57
JimmyZ: I assume you're running latest? 13:58
JimmyZ I think so
jnthn ok, we patched a SEGV earlier is all
JimmyZ no
I forgot git pull nqp 13:59
jnthn ah
JimmyZ though I can't build nqp.moarvm because of not enough memory or the x86 bug 14:33
diakopter :( 14:34
FROGGS :/ 14:36
I guess the x86 didn't went away just like that
x86-bug*
jnthn time to decommute 14:49
15:04 benabik joined 15:08 jnap joined 15:29 jnap joined 16:13 JimmyZ joined 16:21 FROGGS joined 16:55 colomon joined 17:37 jnap joined 17:54 ssutch joined 18:28 grondilu joined
FROGGS nqp-m: say( -> $a, $b, $c { $c }(40, 41, 42) ) 19:04
camelia nqp-moarvm: OUTPUTĀ«42ā¤Ā»
FROGGS why does the qast test fail? it is almost the same
nqp-m: say( -> $a, $b, $c { $c }( |nqp::list_i(40, 41, 42) ) ) 19:05
camelia nqp-moarvm: OUTPUTĀ«MVMArray: atpos expected int registerā¤ at <unknown>:1 (<ephemeral file>:frame_name_3:4294967295)ā¤ from /tmp/Rs4k0sES75:2 (<ephemeral file>:frame_name_0:49)ā¤ from nqp-src/NQPHLL.nqp:1084 (./NQPHLLMoar.moarvm:frame_name_671:97)ā¤ from nqp-src/NQPHLL.nqp:ā€¦Ā»
FROGGS nqp-m: my @a := nqp::list_i(40, 41, 42); say( -> $a, $b, $c { $c }( |@a ) )
camelia nqp-moarvm: OUTPUTĀ«MVMArray: atpos expected int registerā¤ at <unknown>:1 (<ephemeral file>:frame_name_3:4294967295)ā¤ from /tmp/rEUMDUaEoq:2 (<ephemeral file>:frame_name_0:54)ā¤ from nqp-src/NQPHLL.nqp:1084 (./NQPHLLMoar.moarvm:frame_name_671:97)ā¤ from nqp-src/NQPHLL.nqp:ā€¦Ā»
FROGGS nqp: my @a := nqp::list_i(40, 41, 42); say( -> $a, $b, $c { $c }( |@a ) )
camelia nqp: OUTPUTĀ«42ā¤Ā»
FROGGS nqp-m: my @a := nqp::list(40, 41, 42); say( -> $a, $b, $c { $c }( |@a ) )
camelia nqp-moarvm: OUTPUTĀ«42ā¤Ā»
jnthn oh...probably 'cus the flatterer doesn't know about int lists...
FROGGS damn, it is really about list_i 19:06
yeah
works with list
where is the flatterner ooc?
jnthn args.c
uh, flattener :PP
FROGGS k 19:07
jnthn I think the fileops.t tests that fail on Windwos on Moar look like they also will on other VMs 19:17
FROGGS which one fails? 19:18
jnthn But don't have any of the other backends built on my laptop yet :) 19:19
FROGGS shame on you :o) 19:20
jnthn 8/10
by assuming \\n not \\r\\n
uh, 9/10 19:21
Well, new laptop...teaching distractions... :)
FROGGS ahh, so the CREDITS gets modified when checking it out? 19:22
yeah, that would break everywhere :o) 19:23
jnthn yeah
Git on Windows will happily throw in the \\r on checkout, and toss it on commit
FROGGS well, you've chosen your fate explicitly when installing git 19:24
jnthn aye :)
but if I chose that fate, others will doo ;)
*too
Anyway, easy fix.
So, that leaves us 9 test cases 19:25
I guess you're working on the qast.t one at the moment?
FROGGS btw, that is one reason I added the test file which has different newlines, which should not get mangled by git
sort of, yes
"The bytecode loader verifies it's a MVM_CALLSITE_ARG_OBJ" - that is not what we want for list_*, right? 19:27
jnthn No, it's still an obj
Just an obj with native ints within it.
FROGGS ahh, yeah
MVM_repr_at_pos_o 19:28
jnthn: I guess the :want in the list_i op should help me to identify it as an in array? 19:53
[Coke] has the moar bootstrap branch been updated with master recently? 19:57
[Coke] just wants to poke at the doc testing a bit once that happens, but it's no big deal.
FROGGS [Coke]: I don't think so 20:03
jnthn: I don't get it :o( 20:06
jnthn FROGGS: huh, :want?
This needs to be handled in the flattener in args.c
Not something static
FROGGS hmmm, I don't know how to query the list/items if they are ints
jnthn See get_elem_storage_spec 20:07
FROGGS I did that
and got the spe of the things in the list
jnthn Right
FROGGS like: if (REPR(o)->get_storage_spec(tc, STABLE(o)).can_box == MVM_STORAGE_SPEC_CAN_BOX_INT) {
jnthn That's what you need, no?
FROGGS and before I tried .boxed_primitive 20:08
jnthn No, you want the oneobjprimspec looks at
yes, that one
FROGGS but that condition is never true
jnthn It won't be if you compare it to CAN_BOX_INT :P
FROGGS if (REPR(o)->get_storage_spec(tc, STABLE(o)).boxed_primitive == MVM_STORAGE_SPEC_BP_INT) {
printf("MVM_STORAGE_SPEC_BP_INT\\n");
jnthn MVM_STORAGE_SPEC_BP_INT is the one... 20:09
oh...but
get_elem_storage_spec in VMArray loosk wrong :(
FROGGS ahh
jnthn Should be done in terms of repr_datea->slot_teype 20:10
FROGGS it has the same as Iter
so, if slot_type is MVM_ARRAY_I64 it should state that when querying the spec? 20:12
jnthn Should set boxed_primtivie to INT, yeah
Same for any of the _I*
FROGGS and N* and so on 20:13
jnthn yeah, but _NUM for those :)
FROGGS I not taht :o)
know*
-.-
jnthn
.oO( but do you not how to type? )
FROGGS that is just because I am tired :o) (I usually type without any arrows) 20:16
jnthn detrain & 20:42
jnthn home 21:11
diakopter hi 21:38
jnthn Pushed Windows fixes to 19- so I'm down to 9 failures too now :) 22:00
Is MVM_string_flatten meant to always give back 32-wide? 23:58

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!