github.com/moarvm/moarvm | IRC logs at irclog.perlgeek.de/moarvm/today
Set by moderator on 8 October 2013.
01:15 benabik joined 01:22 jnap joined
JimmyZ .tell not_gerd with --shared I got "./libmoar.so: undefined reference to `CPU_COUNT'" 03:05
yoleaux JimmyZ: I'll pass your message to not_gerd.
03:07 ggoebel5 joined 03:13 d4l3k_ joined 03:17 larks_ joined 03:27 eternaleye joined
JimmyZ FYI: the error of 'moar nqp.moarvm repl' you got is that because I don't know how to tell tty in libuv :( 03:42
diakopter not_gerd: ping 06:18
06:20 jnthn joined 06:29 not_gerd joined
not_gerd o/ 06:29
yoleaux 8 Oct 2013 22:27Z <diakopter> not_gerd: I saw this, which led me to notice that TCC is almost done switching its license from lgpl to mit-style...! easy assembler! blogs.perl.org/users/david_mertens/...-perl.html
03:05Z <JimmyZ> not_gerd: with --shared I got "./libmoar.so: undefined reference to `CPU_COUNT'"
not_gerd JimmyZ: os/compiler? does it only happen with --shared?
diakopter: pong 06:30
JimmyZ not_gerd: on linux, gcc 06:34
not_gerd: yes
not_gerd JimmyZ: the glibc version check is wrong, but I dont think that's it 06:35
dalek arVM: 9d142ab | (Gerhard R)++ | src/platform/posix/sys.c:
Make glibc version check forward compatible
 06:38
not_gerd that probably won't help 06:39
JimmyZ yeah, same eror 06:45
not_gerd workaround would be to add www.redhat.com/archives/libvir-list...01515.html to platform/posix/sys.c right before MVM_platform_cpu_count() 06:47
that shouldn't be necessary, though
JimmyZ: could you add gist.github.com/gerdr/2999fc4d064e3f637cbd before MVM_platform_cpu_count() and see if it gets triggered on both static or shared builds or just the shared one? 06:51
JimmyZ it gets triigered on both 06:53
not_gerd that makes ense, at least 06:55
*sense
the question is, did I mess up or is your glibc broken? 07:00
according to the man pages, the code should work, imo
JimmyZ # uname -a 07:01
Linux li618-176 3.9.3-x86_64-linode33
# cat /etc/issue
CentOS release 6.2 (Final)
07:01 FROGGS joined
JimmyZ gcc version 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC) 07:02
ldd (GNU libc) 2.12 07:04
FROGGS hi
not_gerd JimmyZ: that's the important part
anything >= 2.6 *should* work
FROGGS: good morning 07:06
JimmyZ weird, then why MVM_platform_cpu_count is compiled
not_gerd because it just assumes CPU_COUNT is a function with default signature 07:07
that's only an error since C99
in the static case, the linker is smart enough to figure out the code never gets called and thus doesn't fail on the undefined symbol 07:08
JimmyZ not_gerd: since libc < 2.6, the MVM_platform_cpu_count with CPU_COUNT function should not be compiled, I think 07:09
not_gerd: as per #if __GLIBC__ > 2 || (__GLIBC__ == 2 && __GLIBC_MINOR__ >= 6) 07:10
FROGGS that doesn't make much sense 07:11
it would be true for __GLIBC__ > 2 already
err, no
nvm
(I've seen a >= there) 07:12
nqp-m: say("baaabbbb" ~~ /a**4..4/) 07:28
camelia nqp-moarvm: OUTPUTĀ«aaaā¤Ā»
FROGGS :o(
nqp-m: say("baaabbbb" ~~ /a**4..5/) 07:29
camelia nqp-moarvm: OUTPUTĀ«aaaā¤Ā»
timotimo nqp: say("baaabbbb" ~~ /a**4..5/)
camelia nqp: OUTPUTĀ«ā¤Ā»
timotimo yeah, that's not quite perfect
FROGGS timotimo: btw, I know why the 2..4 failed, I made the return value of index(n)at -1 for not found and -2 for `offset outside of string` 07:30
and this return value seems to be used, not only for checking if it is >= 0
timotimo oops 07:31
yeah, seems like most of these negative values have some kind of meaning
it should have been -3 instead?
FROGGS do you think so? I've seen the -3 some time ago.. 07:32
I'll grep for it in vm/parrot
hmmmm, a failed cursor gets the -3, I don't think that I am there yet 07:36
not_gerd oh... 07:43
I now why CPU_COUNT can't be found
_GNU_SOURCE must be defined before including any GNU headers
and moar.h pulls in some of those
timotimo FROGGS: does it fix the match tests? 07:45
FROGGS still compiled 07:46
compiles*
damn, 2**4 fails now again 07:47
dalek arVM: 386c0f7 | (Gerhard R)++ | src/platform/posix/sys.c:
Move definition of _GNU_SOURCE before inclusion of any libc headers
 07:48
not_gerd JimmyZ: ^^
timotimo bleh :( 07:49
JimmyZ not_gerd++ # it fixed! 07:54
08:08 woolfy joined
not_gerd bye, #moarvm 08:13
08:13 not_gerd left
JimmyZ bye, not_gerd 08:14
08:23 woolfy left 09:01 donaldh joined
dalek arVM: 268332b | (Tobias Leich)++ | / (8 files):
fix negated enumcharlist evaluation

We got false positives when the to be checked offset was out of bounds.		 09:05
timotimo FROGGS: fixes everything? :) 09:06
JimmyZ Is it finished? 09:08
FROGGS no, look at #perl 09:09
I just commited what is working, so it uncovers the actual problems
.tell diakopter the indexnat op is now in master/moarboot, if you want to uncover the gc-bug just strip the "# heisenbug!!!" comments 09:13
yoleaux FROGGS: I'll pass your message to diakopter.
FROGGS .tell jnthn the indexnat op is now in master/moarboot, if you want to uncover the gc-bug just strip the "# heisenbug!!!" comments 09:14
yoleaux FROGGS: I'll pass your message to jnthn.
FROGGS I hope that my stage0 does not break something, it works on my box at least
09:45 grondilu joined 10:17 woosley joined 10:30 FROGGS joined 11:06 ggoebel6 joined 11:25 FROGGS joined 12:55 lizmat joined 12:57 benabik joined 13:51 not_gerd joined
not_gerd o/ 13:51
jnthn o/ 13:52
not_gerd jnthn: I converted my ramblings re extop operand staging into code
usage would look like gist.github.com/gerdr/05a30cde96d007e60b66
dispatch is at github.com/MoarVM/MoarVM/blob/ext-...rp.c#L3550 13:53
macro definitions at github.com/MoarVM/MoarVM/blob/ext-...terp.c#L29
diakopter not_gerd: did you see the msg about TCC license? 14:20
not_gerd diakopter: yes
not_gerd actually reads tinycc-devel from time to time
diakopter I think using its assemblers (one way or another) would be a very nice first attempt for the jit 14:21
not_gerd or QEMU's TCG, which IIRC is also based on the TCC assembler 14:27
they diverged since then
diakopter well, as long as qemu's tcg is also mit license 14:28
not_gerd "All the files in this directory and subdirectories are released under a BSD like license (see header in each file). No other license is accepted." 14:29
diakopter cool :)
14:43 benabik joined
TimToady "No other license is accepted." What in the world does that mean? 14:45
diakopter for contributions
14:45 jnap joined
diakopter I assume 14:47
TimToady could be 14:48
JimmyZ hmm, Does tinycc have optimize.c? I saw there is one in tcg 15:14
15:19 benabik joined 15:20 jnap joined
JimmyZ not_gerd: tcg looks like really better than tinycc's one 15:26
much clearer api 15:27
diakopter JimmyZ: can you get at the AST creation through tcg or does it not expose that? 15:31
15:31 jnap joined
not_gerd floating point ops are apparently still not supported :( 15:35
I hoped someone would have taken care of that till now...
JimmyZ not_gerd: I saw it in TODO though 15:36
diakopter: AST creation? 15:37
diakopter JimmyZ: or operations lists? 15:39
JimmyZ: what's its interface to emit instructions?
not_gerd diakopter: wiki.qemu.org/Documentation/TCG/frontend-ops
15:40 jnap joined
JimmyZ I saw tci use TCGContext *s 15:41
hmm, it's an Interpreter 15:42
not_gerd JimmyZ: there's both, I think 15:43
not_gerd is afk
JimmyZ oh, the Interpreter is tci.c 15:46
15:46 jnap joined 15:51 jnap joined
JimmyZ anyway, I like it 15:53
15:58 jnap joined
diakopter at least 95% of the potential optimum gains from optimization will be above the assembler level, so I'm not worried about squeezing the last 5% of performance [average] for years... 15:59
TimToady but we have to compete with hand-coded assembly...oh wait, that was Fortran... 16:00
we just have to compete with C
16:05 jnap joined 16:11 jnap joined
jnthn finally has a build environment and a Moar build on his new lapotp :) 16:19
16:21 jnap joined
jnthn so...this # heisenbug!!! comment... 16:26
16:27 jnap1 joined
jnthn Removing the one in qregex makes no difference for me 16:27
nqp-m: /xa**0/ 16:29
camelia nqp-moarvm: OUTPUTĀ«Frame has unresolved labelsā¤ at nqp-src/QASTMoar.nqp:7955 (./QASTMoar.moarvm:assemble_and_load:15)ā¤ from nqp-src/NQPHLL.nqp:914 (./NQPHLLMoar.moarvm:mbc:70)ā¤ from nqp-src/NQPHLL.nqp:1322 (./NQPHLLMoar.moarvm:frame_name_779:87)ā¤ from nqp-src/NQPHLL.nqpā€¦Ā»
jnthn That's not heisen... :)
nqp-m: /a**0/
camelia nqp-moarvm: OUTPUTĀ«Frame has unresolved labelsā¤ at nqp-src/QASTMoar.nqp:7955 (./QASTMoar.moarvm:assemble_and_load:15)ā¤ from nqp-src/NQPHLL.nqp:914 (./NQPHLLMoar.moarvm:mbc:70)ā¤ from nqp-src/NQPHLL.nqp:1322 (./NQPHLLMoar.moarvm:frame_name_779:87)ā¤ from nqp-src/NQPHLL.nqpā€¦Ā»
jnthn nqp-m: /a**1/
camelia ( no output )
jnthn nqp-j: /a**0/ 16:30
nqp: /a**0/
camelia ( no output )
jnthn nqp-jvm: /a**0/
camelia ( no output )
jnthn ah, I see it... 16:32
16:32 jnap joined
diakopter jnap: you have to remove them all I think 16:33
r
er
jnthn: you have to remove them all I think
jnap: sry 16:34
commutastrarinessificationily 16:35
&
jnthn ah, k
diakopter well, that wouldn't make sense 16:36
try superdupercleaning 16:37
&
16:37 jnap joined 16:46 jnap joined
jnthn Darn, no, even removing them all doesn't help 16:46
.ask FROGGS what platform do you see the heisenbugs on? 16:47
yoleaux jnthn: I'll pass your message to FROGGS.
jnthn timotimo: Do you have the heisenbug also? If so, what platform?
16:51 ssutch joined
jnthn t/qregex and t/p5regex now seem to hit the exact same issue 16:52
16:54 jnap joined 17:05 jnap joined
dalek arVM: d5bb4e0 | jonathan++ | src/strings/ops.c:
iscclass should bounds check, not blow up.
 17:06
17:10 jnap joined
jnthn nqp-m: say(nqp::isnull($*STOPPER)) 17:14
camelia nqp-moarvm: OUTPUTĀ«0ā¤Ā»
jnthn nqp-jvm: say(nqp::isnull($*STOPPER))
camelia nqp-jvm: OUTPUTĀ«0ā¤Ā»
jnthn nqp-jvm: sub x(str $y) { }; x($*STOPPER) 17:15
camelia nqp-jvm: OUTPUTĀ«Cannot unbox a type objectā¤ in x (/tmp/zEa7wrj3y6)ā¤ in (/tmp/zEa7wrj3y6:1)ā¤ in (src/stage2/gen/NQPHLL.nqp:1098)ā¤ in eval (src/stage2/gen/NQPHLL.nqp:1084)ā¤ in evalfiles (src/stage2/gen/NQPHLL.nqp:1290)ā¤ in command_eval (src/stage2/gen/NQPHLL.nqp:11ā€¦Ā»
jnthn nqp-m: sub x(str $y) { }; x($*STOPPER)
camelia nqp-moarvm: OUTPUTĀ«At Frame 1, Instruction 1, op 'param_rp_o', operand 0, MAST::Local of wrong type (7) specified; expected 8ā¤ at nqp-src/QASTMoar.nqp:7955 (./QASTMoar.moarvm:assemble_and_load:15)ā¤ from nqp-src/NQPHLL.nqp:914 (./NQPHLLMoar.moarvm:mbc:70)ā¤ from nqp-src/NQPHā€¦Ā»
jnthn hm, I think nqp-m is from before that fix... :)
17:16 jnap joined 17:24 jnap joined
diakopter erm, *grumble* 17:28
jnthn ok, t/qregex and t/p5regex now both run to completion here 17:29
t/qregex fails 1 test, t/p5regex fails 4.
(meaning they pass 743 and 176 respectively, which ain't at all bad) 17:30
uh, 747 I meant
diakopter *grumble* at errors. we're not supposed to have errors. 17:31
JimmyZ: or not_gerd: how does tgc opset compare to llir's
17:33 jnap joined
diakopter do we have a --gen-moar option to ConfigureMoar.pl ? 17:34
jnthn not yet
Leaving that as an LHF :)
diakopter ARGH
that's what I was going to see if moritz wanted to do 17:35
moritz: ^ :D
.ask JimmyZ how hard woudld it be to add uint_ptr-sized atomic loads/stores to TCG? 17:37
yoleaux diakopter: I'll pass your message to JimmyZ.
diakopter .ask not_gerd how hard woudld it be to add uint_ptr-sized atomic loads/stores to TCG?
yoleaux diakopter: I'll pass your message to not_gerd.
17:37 jnap joined 17:44 jnap joined 17:51 jnap joined 17:55 jnap joined
moritz diakopter: I might, though no estimations on when 17:59
18:03 jnap joined 18:06 not_gerd joined
diakopter not_gerd: hi 18:07
(where by atomic loads/stores, I also mean ones that inject fences where necessary) 18:08
18:13 jnap joined
diakopter jnthn: I'm still kindof... flabbergasted that the whole regex compiler essentially worked [modulo a few hours of you debugging] without any testing at all while being written 18:13
especially the jumplist generation
*boggle* 18:14
I've still never actually seen any regex-generated code in moarvm --dump
now I'm curious....
JimmyZ: would you like to debug what is breaking moar --dump nqp.moarvm 18:15
18:23 jnap joined 18:27 jnap joined 18:36 jnap joined 19:02 jnap joined 19:06 jnap joined 19:07 lizmat joined 19:14 jnap joined 19:23 jnap joined 19:29 jnap joined 19:39 jnap joined 19:44 jnap joined 19:49 jnap joined 19:53 jnap joined
dalek arVM: 1f3f004 | jonathan++ | src/core/args.c:
Only free args buffer if we already flattened.

Otherwise, we're calling free on something inside a register frame.		 20:41
arVM: 8d853d3 | jonathan++ | src/ (6 files):
Make exceptions thrown from C catchable.

Previously, they always would panic and exit the VM. Now they can be caught.
diakopter jnthn: I swear 1f3f004 was already that way ... at least how I did it 20:49
or.. maybe in some branch :(
well anyway those two should use MVM_checked_free_null
er maybe I did that in the gcorch branch
argh
jnthn diakopter: MVM_checked_free_null is actually harder for me to read than pattern-matching what it does, fwiw :) 20:52
diakopter eh?
harder to read in its definition? 20:54
20:56 not_gerd joined
not_gerd o/ 20:56
yoleaux 17:37Z <diakopter> not_gerd: how hard woudld it be to add uint_ptr-sized atomic loads/stores to TCG?
jnthn diakopter: No, it's just that I'm so used to reading the 3 lines I read them as one chunk, whereas with this I actually have to read the function name :P
diakopter oh, heh.
I mean, oh
not_gerd jnthn: note that making adhoc exception catchable means we should also figure out a way to avoid leaking the memory for C strings we allocate for the error message 20:57
or does the code already do that? 20:58
not_gerd goes reading the diff
diakopter not_gerd: I had a plan for how to do that 21:00
I was going to pass a list of pointers to free with the exception
not_gerd or we could parse the format string ourselves, looking for %s 21:01
which of course means bad things will happen if you pass a non-allocated string
so probably not an option
jnthn not_gerd: Yeah, we'll leak at the moment 21:03
not_gerd: Needs addressing, but better than not being able to catch them at all :)
diakopter jnthn: you didn't like my plan? 21:06
jnthn diakopter: I think I prefer it to parsing the format string ;)
s/think/know/ :D 21:07
diakopter { ptr1, ptr2, ptr3, 0xB0054ED5 } 21:08
jnthn wtf are boo saeds? 21:09
not_gerd parsing the format string would be doable - va_copy the va_list and make sure we strdup() any strings we pass in 21:10
+1 for doing something else, though ;)
diakopter also doable is simply pushing the pointers to a list on the threadcontext
SIMPLY SIMPLY SIMPLY 21:11
not_gerd MVM_string_utf8_encode_C_exception_string()
diakopter where's TimToady to gently tell not_gerd to stop perseverating 21:12
jnthn MVM_longest_function_name_ever :P
btw, we're down to 11 failing tests now 21:13
not_gerd \\o/
jnthn thta's tests, not tst files, to be clear
uh, wow, that was clear :P
not_gerd jnthn: should I look into how to emit the extop bytecode, or will you do that? 21:15
(ie how to get the relevant information to mast/compiler.c)
diakopter jnthn: does the exception builder need to empty the temp roots?
jnthn diakopter: "exception builder"? 21:16
diakopter not_gerd: that wasn't clear from the design doc? 21:17
jnthn: the thing you just committed
jnthn diakopter: Yes, because we might throw from within a MVM_ROOT(tc, ...)
diakopter jnthn: oh. :) you did it.
yea I didn't see that you did it
jnthn oh, I thought you were asking if we really needed to ;)
diakopter (diakopter-helpfulness)-- 21:18
not_gerd: I bet you can figure it out
ask me if you have a question
not_gerd diakopter: I'm pretty sure I can
but I woud need to figure it out
diakopter just throw it in there somewhere :) 21:19
jnthn: how's the bootstrapping gonna keep the bytecode versions straight 21:23
jnthn diakopter: bytecode file has a version number 21:24
diakopter I know this.
jnthn diakopter: We always have to support at least one version back.
I'm not planning to close the loop for a little time yet, though.
So we can have ourselves a little freedom from that for a bit longer :)
diakopter so how shoudl not_gerd add in the new things to the bytecode format
jnthn Just Do It right now. 21:25
And then use nqp-cc to make a new stage0
And commit it to the nqp repo
In the future, adding new things will need a mechanism like the serialization stuff does
So you can do stuff conditionally on version.
diakopter why not just have a clone of an old checkout under nqp-cc
or something 21:26
jnthn nqp-cc will go away in a month or so
But I think we need a little more time to make bytecode format changes more easily.
Get the op numbering as we want it, make sure sizes of things are as we want, etc.
Longer term, I'd like us to continue supporting some time period worth of bytecode versions back. 21:27
diakopter how?
jnthn Same way we do with serialization versioning 21:28
diakopter how does it do that?
jnthn if (reader->version > 4) ...we have this thing... else ...some sane defualt if needed...;
uh, >= normally
diakopter oh, 21:29
jnthn Nothing more clever than that. It's been Good Enough. :)
not_gerd good night o/ 21:52
21:54 not_gerd left 22:11 ssutch joined
jnthn sleep & 22:26
diakopter o/ 22:27
23:23 cognominal 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!