Camelia, the Perl 6 bug

IRC log for #moarvm, 2013-07-13

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:01 timotimo i suppose i'll have to wait a bit longer before starting to benchmark moarvm gets sensible
00:02 timotimo while_empty, while_empty_native and while_bind all end up a tiny bit faster than nqp-parrot at the biggest workloads
00:04 timotimo 10/42: Testing while_push ...
00:04 timotimo Segmentation fault (core dumped)
00:07 timotimo moarvm is almost at the same speed as nqp-parrot in the while_hash_set benchmark, except at the end it gets slower than nqp-parrot
00:09 timotimo while_array_set coredumps as well
00:18 timotimo i have no idea where the "cut" is where nqp-parrot ends and moarvm starts or where the moarvm is invoked, so i have no idea where i'd have to look to make exit codes be passed outwards properly :(
00:24 timotimo congratulations, moarvm is a bit faster than nqp-parrot in the postwhile_nil_native benchmark!
00:32 benabik joined #moarvm
00:50 diakopter timotimo: okay.
00:51 diakopter timotimo: probably those errors won't occur if you don't use --optimize
00:51 diakopter there are a couple things there that have been known for many months
00:52 diakopter timotimo: re "bit faster", *sigh*
00:54 timotimo are you sighg because i concentrate on performance or because the benchmarks are meaningless?
01:48 FROGGS_ joined #moarvm
02:47 diakopter timotimo: no :)
02:47 timotimo please elaborate?
02:52 timotimo welp, i better get to bed
02:52 diakopter bbiab
05:26 benabik joined #moarvm
05:58 itz joined #moarvm
07:22 FROGGS joined #moarvm
08:43 _ilbot joined #moarvm
08:43 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
13:59 jlaire joined #moarvm
14:06 birdwindupbird joined #moarvm
14:07 dalek MoarVM: 36e3254 | (Tobias Leich)++ | / (8 files):
14:07 dalek MoarVM: added and mapped noninteractive nqp::readlinefh
14:07 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/36e325457a
14:22 FROGGS jnthn: should I commit src/NQPHLL.nqp with everything commented it that is compilable? it is quit a lot
15:03 FROGGS I guess the next thing I do might be sprintf... or is there something more important?
15:07 FROGGS ahh, nqp::stat first
15:34 FROGGS joined #moarvm
16:15 JimmyZ_ joined #moarvm
16:16 JimmyZ_ Hello FROGGS
16:16 FROGGS hi JimmyZ
16:18 FROGGS gah, libapr cant tell one if a file exists... (or I am just stupid and cant find it)
16:28 JimmyZ_ FROGGS++, for adding new ops
16:30 TimToady can't one just see if a getfileinfo call fails?
16:31 TimToady a google search seems to refer to both stat and lstat variants of that
16:34 FROGGS TimToady: I'm currently reading that stat cant handle files > 2GB reliable...
16:34 FROGGS so I am reading a bit before deciding what to do
16:34 TimToady surely it can tell whether the file is there or not, regardless of whether it mishandles the size
16:34 TimToady you were looking for an existence test, right?
16:35 FROGGS the third one says that: http://stackoverflow.com/questions/2​30062/whats-the-best-way-to-check-if​-a-file-exists-in-c-cross-platform
16:36 FROGGS TimToady: yes, only for existence, I can do the rest using libapr
16:37 benabik joined #moarvm
16:40 FROGGS I think I'm going to use access()
16:42 TimToady that seems okay for existence, as long as you don't try to check for any other bits at the same time
16:43 TimToady for most other purposes, access is wrong, and you want something like eaccess
16:44 FROGGS it is really just about existence
16:44 FROGGS cool
16:46 TimToady I guess stat would work if you trapped EOVERFLOW, since you can't get that unless the file exists, but access does seem simpler
16:47 TimToady but who'd be stupid enought to compile with 32-bit off_t these days anyway?
16:48 TimToady most people would like to be able to handle DVDs
17:50 FROGGS hint: a line like "#define MVM_stat_exists = 0" is not what you want
17:50 FROGGS -.-
18:46 colomon joined #moarvm
18:57 sorear :)
19:39 diakopter :D
19:49 diakopter FROGGS: sometime we need to talk about setting the thread's "I'm in external code" flag when calling things that could call things that aren't statically linked or could do IO
19:50 FROGGS okay
19:51 diakopter I'm not 100% certain jnthn intends/agrees that needs to be set during all the system calls, but I suspect he does
20:05 dalek MoarVM: 4e2bc25 | (Tobias Leich)++ | / (9 files):
20:05 dalek MoarVM: added and mapped nqp::stat
20:05 dalek MoarVM:
20:05 dalek MoarVM: This replaces the duplicate eof moar-op, too.
20:05 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/4e2bc25a0b
20:06 diakopter FROGGS: those ops in interp.c don't look like the same order as in oplist
20:07 FROGGS ohh, does that matter?
20:07 diakopter they should be in order of their constant to help it make a jump table, I'd think
20:07 diakopter (I mean, theoretically it can figure out they're independent and put them in order)
20:08 FROGGS okay, will reorder it in a bit
20:08 diakopter it's not a big deal though because they'll all be rearranged at some point this year, I'd expect
20:09 jnthn Yeah, we'll do an op list cleanup at some point.
20:10 diakopter jnthn: see speculation 21 min ago
20:10 jnthn FROGGS: I think there already is an nqp-src/NQPHLL.nqp or so
20:11 jnthn Yes, any system call that can block at least.
20:12 FROGGS jnthn: I know about nqp-src/NQPHLL.nqp, the question is: if it compiles when commenting in stuff, should I commit that?
20:12 diakopter FROGGS: you mean when uncommenting new/pasted stuff?
20:12 FROGGS no
20:13 FROGGS stuff that is there, but was commented out because the io ops where missing
20:13 jnthn FROGGS: You can uncomment the commented stuff if it still builds
20:13 diakopter okay, so *un*commenting stuf
20:13 jnthn FROGGS: That's the idea...
20:13 jnthn FROGGS: Uncomment what works, so we can see what's left
20:13 FROGGS err, yes
20:13 jnthn That's how everything so far as happened ;)
20:13 FROGGS yeah
20:13 diakopter FROGGS: I was confused because you said "commenting" :D
20:14 FROGGS diakopter: yeah, sorry :/
20:14 FROGGS "commenting in" might be a bit too germish
20:15 FROGGS jnthn: I guess the next thing (not for me) could be exceptions+try/catch
20:15 jnthn Yes, that's on my todo list. I already did a bunch of the groundwork
20:15 FROGGS cool
20:16 FROGGS (just so that the moarvm backend can be in this-months compiler release :P)
20:17 FROGGS btw, the startup of nqp nqp-moar-cc.nqp -e '1' is still effected by parrot, right?
20:17 FROGGS I mean, it must be, no?
20:19 jnthn Right, it's a cross-compiler
20:19 FROGGS right
20:19 jnthn No, moarvm backend will be a bit further off
20:19 FROGGS is the runtime effected too? I guess not
20:20 jnthn It spits out moarvm bytecode, then runs moarvm
20:20 FROGGS k, thanks
20:20 jnthn MoarVM's execution time is more likely affected by various other things :)
20:21 FROGGS for example? I'd think libapr has the most impact
20:22 jnthn Well, partly by GC needing some work ;)
20:23 FROGGS ahh, yes, of course
20:23 jnthn And other bits. The difference between an optimized and unoptimized build is fairly notable too, and the default is unoptimized
20:24 FROGGS one cool thing atm is that you can add ops, and after 3 seconds you got it compiled and you see the test out... that is pretty nice
20:25 FROGGS not waiting for ten minutes or moar
20:26 jnthn yes, this kinda dev turnaround time is fairly deliberate ;)
20:31 FROGGS btw, have you an opinion to an interactive readline library?
20:31 FROGGS linenoise was mentioned but I have no idea if that will work on windows
20:34 * sorear looks into MoarVM for the first time
20:34 sorear this mast/compiler.c thing looks pretty parrot-specific
20:36 jnthn sorear: It's all very macro'd
20:36 jnthn So replacing node_parrot.h or so will mean it's about Moar'd
20:39 jnthn FROGGS: No opinion on the readline thing without looking into it more...
20:40 diakopter sorear: there's one or two things labeled "parrot" "hack" that are there
20:41 jnthn I guess that libreadline is the most common option
20:44 dalek MoarVM: ce83acc | (Tobias Leich)++ | src/core/interp.c:
20:44 dalek MoarVM: use the same ordering like in core/oplist
20:44 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/ce83acca7b
20:50 dalek MoarVM: ef23f5d | (Tobias Leich)++ | nqp-cc/nqp-src/ (2 files):
20:50 dalek MoarVM: uncomment bits that are now available
20:50 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/ef23f5d6f3
21:30 benabik diakopter: ...  Jump tables don't need to have their destinations in order.
21:32 diakopter ... they do if it wants to translate the value to an index/offset
21:32 benabik In assembly, it ends up being jump to offset from here, followed by a huge pile of jump instructions.
21:33 benabik jump 0+(index); jump label1; jump label3; jump label2
21:33 diakopter I do not see how you could conclude I didn't know that...
21:34 benabik The indexing goes to a jump that can be anywhere, so it doesn't matter if the switch statement is in order.
21:35 diakopter yes ok
21:36 benabik Now, having them in the same order as the original list can certainly help the programmer.  :-D
22:08 dalek MoarVM: 434fd28 | (Tobias Leich)++ | src/io/fileops.c:
22:08 dalek MoarVM: remove unneeded include which was accidentally added
22:08 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/434fd280d6
23:06 colomon joined #moarvm

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary