github.com/moarvm/moarvm | IRC logs at irclog.perlgeek.de/moarvm/today
Set by moderator on 25 August 2013.
00:02 benabik joined 00:09 jnap joined 00:21 jnap joined 00:51 FROGGS joined
dalek arVM: f3ceedd | jimmy++ | build/setup.pm:
Add -lkvm on OpenBSD NetBSD
 01:15
01:38 FROGGS joined 02:01 cognominal joined
dalek arVM: 1b7507f | jimmy++ | / (2 files):
[build] remove CoreFoundation dependency
 02:15
arVM: b391438 | jimmy++ | build/setup.pm:
fixed darwin build
 02:19
arVM: 64d89c5 | diakopter++ | nqp-cc/t/moar/ (3 files):
kill broken tests "fernau"
 02:35
arVM: c9b0ea8 | diakopter++ | / (2 files):
Merge branch 'master' of github.com/MoarVM/MoarVM
arVM: a5e9118 | diakopter++ | src/core/exceptions.c:
note todo
 02:56
arVM: 36b1491 | diakopter++ | src/core/exceptions.c:
note todo better
 02:58
03:04 FROGGS joined
JimmyZ diakopter: why needs cache? Isn't MVM_exception_backtrace_line called before exit()? 03:10
diakopter tracing is slow
could be much faster
me likey tracing
JimmyZ oh 03:11
yes, tracing need it
diakopter: do you know why the top trace is always unkonw? 03:12
diakopter I'm looking at that now
JimmyZ *unkown
great
so it could be nice to cache it only when make TRACING=1 03:14
diakopter .tell not_gerd if you didn't build with TRACING=1 but then you do, it doesn't rebuild something so --tracing option doesn't appear in the help and doesn't work
yoleaux diakopter: I'll pass your message to not_gerd.
diakopter JimmyZ: heh, okay
it's hard to debug tracing using tracing 03:18
JimmyZ :)
add a printf("==== start =====\\n") in interp.c before after call MVM_exception_backtrace_line helps 03:20
diakopter sweet... Your Amazon.com order of "Microsoft Sculpt Ergonomic Desktop (L5V-00001)" has shipped! 03:23
awesome
JimmyZ that's nice 03:25
Did you have a cherry keyborad? 03:28
diakopter I have the non-wireless predecessor
at work and home
7000
03:30 Tene joined
JimmyZ e 03:31
04:31 cognominal joined 05:04 FROGGS joined 05:14 ggoebel2 joined 05:37 cognominal joined 06:30 FROGGS joined 07:54 odc joined 08:45 foo_bar_baz joined 08:57 donaldh joined 09:37 dalek joined 12:24 jnap joined 12:27 grondilu joined 12:55 jnap joined 13:05 not_gerd joined
not_gerd O/ 13:05
yoleaux 03:14Z <diakopter> not_gerd: if you didn't build with TRACING=1 but then you do, it doesn't rebuild something so --tracing option doesn't appear in the help and doesn't work
not_gerd .tell diakopter `make tracing` and `make no-tracing` should take care of deleting main.o and core/interp.o 13:06
yoleaux not_gerd: I'll pass your message to diakopter.
not_gerd gist.github.com/gerdr/30f83aabd3c323249f08 13:09
is a 20% gcc-only performance improvement to fib(35) worth the effort of adding a goto-based runloop? 13:10
jnthn not_gerd: Depends on the development overhead to maintain it... 13:11
JimmyZ not_gerd: did you see extops.markdown? 13:12
not_gerd jnthn: computed gotos are mostly drop-in (ie could be handled via #ifdefs) 13:13
JimmyZ It is
not known whether the various C compilers compile these any more efficiently
than a flat switch/case of all 65536 potential opcodes with all cases
enumerated (in order).
jnthn not_gerd: *nod*
JimmyZ in extops :)
jnthn not_gerd: I think we want it eventually. I mean, it's a notable win.
JimmyZ that is: remove bank 13:14
jnthn not_gerd: For now perhaps development velocity is more important and so the current simplicity is worth holding onto for a bit.
JimmyZ: The op bank thing's utility was greatly diminished when the ext-ops spec didn't decide to do loading at bank granularity, which was the original plan...
dalek arVM/cgoto: 7ccd7f1 | (Gerhard R)++ | src/core/interp.c:
Implement runloop using computed gotos
 13:15
not_gerd ^ if anyone wants to play with it
JimmyZ jnthn: and in core? 13:16
jnthn JimmyZ: There it was largely organizational. 13:17
nwc10 IIRC Sun's compiler also did computed goto
but no which generation of Sun's compiler, as they bought at least one exernal compiler vendor
not_gerd but MSVC doesn't
nwc10 however, I think stick with simplicity for now
not_gerd and with the removal of inline asm, you can't even hack around it
nwc10 at least until Panda works
JimmyZ not_gerd: how about clang?
not_gerd JimmyZ: clang should do it 13:18
nwc10 one of the classic Parrot mistakes was to re-re-redo working code
JimmyZ not_gerd: that's enough
nwc10 instead of actually finishing the missing parts
and getting to the big picture
it would be a shame to repeat that
jnthn nwc10: Yes, exactly. 13:19
JimmyZ jnthn: I have some problems to follow you. Could you tell me the bank will be removed or not, or how to be diminished? 13:21
not_gerd the nice thing about computed gotos is that if you don't do anything fancy, the structure of the switch loop is reproduced
get rid of switch() and default, replace case by labels and break by continue and you're good to go
JimmyZ has to improve his english knowledge
jnthn JimmyZ: I didn't decide if it will be removed yet. I just meant that it is now not as useful as I had expected. 13:22
JimmyZ jnthn: oh, thanks
jnthn JimmyZ: My original idea was that dynamic ops would just get a bank ID.
JimmyZ that's much clearer to me
jnthn JimmyZ: But we didn't end up designing it that way. 13:23
JimmyZ: So now there's not a very strong reason to keep the banks.
JimmyZ jnthn: aye
jnthn At some point we need to go and do an ops cleanup anyway.
The numbers need to become stable at some point. 13:24
JimmyZ I guess just needs re-order ops after running rakudo
jnthn We may want it sooner.
JimmyZ oh
jnthn NQP bootstrap is what will force the issue.
Once we are storing the stage0 bytecode, we have no choice but to retain at least some bytecode back-compat.
JimmyZ oh, that's right
jnthn It's good dogfooding. Anybody who breaks back-compat won't be able to build an NQP. :D 13:25
JimmyZ fair enough
not_gerd: this branch doesn't work for msvc? 13:30
jnthn MSVC doesn't do computed goto, so no, it won't work
not_gerd JimmyZ: right now, no
you'd have to add some macros to abstract away the differences between switch and goto 13:31
JimmyZ I'd like +1 to merge cgoto if it doesn't break msvc :P 13:36
not_gerd +/- 0 13:37
can easily wait until a more appropriate time
nwc10 I don't think that it is yet an appropriate time.
not_gerd did someone fix moar/threads.t? 13:45
or did it magically fic itself?
*fix
JimmyZ not_gerd: it exits before hangs
diakopter++ added an exits there 13:46
jnthn It's a memory corruption issue at its heart, so sometimes you Get Lucky... 13:47
dalek arVM/warnings: f3a8cc1 | (Gerhard R)++ | build/setup.pm:
Add -lkvm on FreeBSD
 13:48
MoarVM/warnings: 15fedd9 | jnthn++ | nqp-cc/t/qast/qast_core.t:
MoarVM/warnings: Add qast_core.t tests, from nqp-jvm-prep.
13:49 dalek joined 13:50 dalek joined
not_gerd ^ branch maintenance 13:50
I'll keep those alive until someone merges them in ot tells me to stop bothering ;)
*or
JimmyZ I wouldn't mind merge it 13:51
diakopter . 14:13
yoleaux 13:06Z <not_gerd> diakopter: `make tracing` and `make no-tracing` should take care of deleting main.o and core/interp.o
14:19 FROGGS joined
JimmyZ thread.t hangs in MVM_gc_enter_from_interrupt 14:25
14:50 FROGGS joined 15:05 benabik joined 15:07 FROGGS joined 17:08 FROGGS joined 17:18 yoleaux joined 18:11 yoleaux joined
nwc10 If I try the code example in the README, I get: 18:17
$ ../moarvm nqp.moarvm -e 'say("Alive!")'
Not enough positional arguments; needed 1, got 0 line 1 in <unknown> (op <unknown>, instr 0<unknown>, frame frame_name_3158, compunit nqp.moarvm)
...
and a lot of backtrace
this is current HEAD 18:18
FROGGS $ ../moarvm nqp.moarvm -e '1' # same for this?
nwc10 yes
FROGGS then it is (still) about nqp's MAIN
nwc10 OK
FROGGS jnthn++ said something about it
18:26 donaldh joined
diakopter nwc10: the code example that says "Very soon, you will be able to run some NQP code by doing"? 18:27
:P 18:28
that's under the VAPORWARE section
nwc10 that would be the problem. :-)
nqp nqp-moar-cc.nqp -e "say('Hello, MoarVM')"
works
FROGGS diakopter: is there something I can do?
diakopter FROGGS: yes :)
FROGGS tell me 18:29
diakopter see the irclogs for 2 days ago
jnthn The next blocker is in code-gen
if foo() -> $x { }
doesn't yet pass
nwc10 use more 'condensers';
FROGGS hmmm
diakopter FROGGS: I was going to suggest working on the NativeCall stuff actually
instead of immediate blockers
FROGGS jnthn: that does not sound like a LHF :o)
jnthn FROGGS: Just needs a little hacking on the code-gen :P 18:30
FROGGS *g*
diakopter the NativeCall reprs and opcodes are much more immediately straightforward... well, sort of.
jnthn :)
FROGGS diakopter: I'm not sure I am capable of doing that
diakopter well you could definitely stub them all out
FROGGS I will look into the codegen thing in a bit 18:31
diakopter with empty function bodies
that'll save someone 30 min or so
jnthn will have tuits for the code-gen thing later today also :)
nwc10 jnthn: I hate to trouble you, but there isn't that much left of today 18:32
jnthn nwc10: It should only be a 15 line diff or so...
diakopter monkeys could do that in a decade or so 18:33
if they started now
I wish we could be like the browser manufacturers and have major releases every month or two 18:35
tadzik: work on that for me. kthxbai
18:49 donaldh joined
jnthn bah, I writed enough slajds, I'm gonna fix that code-gen bug 19:03
FROGGS hehe 19:04
jnthn++
when reading about ubuntu yesterday I though it must be ultracool to work for your open source project of choice at work 19:05
so, when MoarVM Inc is hiring: dont forget me :o) 19:06
jnthn Inc? That sounds so US :P
FROGGS MoarVM Ltd. 19:07
better?
dalek arVM: f408efb | jnthn++ | nqp-cc/src/QASTOperationsMAST.nqp:
Fix another named/positional confusion.
FROGGS :o)
diakopter jnthn: how in the world did that previously work 19:08
jnthn diakopter: Parrot bug.
FROGGS: That sounds so UK :P
OK, now for the bug I was going to fix... 19:09
nwc10 MoarVM Gmbh?
FROGGS jnthn: bah
GmbH
jnthn That almost looks like grmbl :) 19:10
At least it looks central-Europe-er :)
nwc10: Is it that in Austria too, ooc?
nwc10 I think so 19:11
FROGGS Ges. mbH or so in Austria
jnthn Wien is nice :) 19:16
FROGGS hmmm, I was only in Graz, Innsbruck and Salzburg...
nwc10 Come to Salzburg. 2nd & 3rd November 19:17
jnthn It's confirmed yet?
nwc10 well, this is public: mail.pm.org/pipermail/vienna-pm/201...03298.html 19:19
jnthn Cool
FROGGS ohh, and I was in Nüziders a few times... 19:20
:o)
jnthn What an awesome place name 19:21
FROGGS well, I'd say the only reason to drive to Nüziders is to throw the ring into the fire 19:23
but the rest of Austria is nice :o) 19:24
(I was a technician from 2004 to 2007/8, and I was forced to drive through Austria and Bavaria mostly)
dalek arVM: 1b4f79d | jnthn++ | nqp-cc/src/QASTOperationsMAST.nqp:
Implement arg-taking if/unless.
 20:00
arVM: 4a3df63 | jnthn++ | nqp-cc/src/QASTOperationsMAST.nqp:
Fix some MAST::Label constructions.
FROGGS jnthn: there are more labels missing the :name, I fix these, k? 20:07
jnthn: nvm, it was a generated file that wasn't updated yet :o( 20:09
dalek arVM: a28cbd7 | jnthn++ | src/6model/reprs/MVMCallCapture.c:
Oversight in gc_mark for CallCapture.
 20:16
arVM: 5b01aba | jnthn++ | src/core/interp.c:
Make atkey and atpos handle type objects better.

They now return NULL instead of trying to do the associative access and blowing up. This is in line with semantics on other backends, and enables QAST::VarWithFallback's generated code to work correctly.
jnthn Darn, now a SEGV in MVM_gc_collect_free_nursery_uncopied 20:17
diakopter oopsie
FROGGS they say an engine of a car goes better directly before blowing up... maybe it is here there other way around? 20:21
jnthn It's nothing immediately obvious either 20:29
20:35 donaldh joined
diakopter jnthn: it appeared just after the last commit? 20:37
jnthn: how much more bytecode is it running since then 20:38
also, how in the world are we getting a gc run already
sorry if these aren't helpful questions :) 20:43
jnthn diakopter: Oh, I think we already survive some GC runs :) 20:48
Just not this one.
diakopter ... in how many milliseconds..
jnthn diakopter: It appeared after the last commit because we got further than before.
diakopter: The last two actually were out of discovery order... 20:49
diakopter: So, I fixed the marking one a moment ago 20:51
diakopter: The issue now is in the post-GC scan through the old nursery.
It's in the second GC run, anyways. 20:56
dalek arVM/nativecall: d27ef12 | (Gerhard R)++ | / (13 files):
Import NativeCall-related Parrot code and do some basic translation
 21:01
diakopter .tell not_gerd make sure to start with CArray
jnthn CPoiner is easier... ;) 21:02
diakopter .tell yoleaux when you come back, please deliver the messages
arnsholt I was about to say the same
diakopter jnthn: you told me CArray was more up-to-date with the right things
arnsholt CPointer is the REPR with the least amount of leg-work
jnthn Bizzarely, the thing we fail on - an MVMObject with a null STable pointer - has a forwarder that points to an MVMSTable... 21:03
arnsholt And CPointer doesn't really have to deal with the whole compose stuff
diakopter jnthn: but how do you know it's an MVMObject if it doesn't have an STable pointer 21:04
sounds like corrupt instead
(I can't think of a way the STable pointer could be null'd and the rest of the object still be reliable data) 21:06
diakopter wonders if jnthn finds the gc debug output helpful
jnthn diakopter: The flags claim it is... 21:08
diakopter: Well, are zero...
diakopter that's what I'm saying
jnthn diakopter: It may well be junk.
diakopter that's what I'm saying
:D
.tell not_gerd hopefully you're reading the irclog... 21:09
.tell not_gerd I don't know why I'm talking to an absent yoleaux
jnthn Indeed, the forwarder pointer points into fromspace, not tospace. 21:10
diakopter O_O
diakopter is having trouble imagining how that could've happened
jnthn Well, I mean, that makes it more likely it's junk. 21:11
diakopter .tell not_gerd at least search the irclogs for CArray
.tell not_gerd you'll see a previous discussion I had with jnthn on it
jnthn: maybe the forwarder pointer wasn't reset from the last time? 21:12
diakopter is grasping at straws
hm, presentation to sr. mgmt in 45 min. should probably prepare a slide or two. 21:13
jnthn diakopter: That should be impossible as we copy, *then* set the pointer 21:14
diakopter hrm 21:15
jnthn: another topic to bug you on
jnthn: nm, I'll get back to you on that 21:19
jnthn ok 21:23
jnthn found a bug, but it didn't help to fix it
(didn't really expect it would...) 21:24
ohhh 21:25
But I think I know what it is ;(
*:(
Darn.
diakopter no?
FROGGS I'd think it is good that you know what it is
diakopter jnthn: what did I do this time? :D
FROGGS except if you dont 21:26
jnthn Yeah but I dunno how on earth to fix it...
FROGGS ohh
diakopter i'm good at those
jnthn diakopter: Nothing...
Well, here's what I think it is.
We store object size in the STable.
Which is OK until we do a mixin.
Which causes an STable switch.
diakopter object size should probably be a repr function
jnthn Now the allocated blob of memory in the nursery is different from the size reported on the st. 21:27
Object size maybe wants to go in the object header... 21:28
Grrr.
diakopter object header or collectable header?
jnthn May as well be collectable
jnthn looks at how that struct looks 21:29
diakopter it looks back at you ;)
jnthn MVMuint32 owner;
MVMuint32 flags;
We're only up to 6 flags so far. 21:30
diakopter we really should make owner a pointer instead of an index
jnthn It's a thread ID, no?
diakopter yeah but that's not useful
anymore
b/c they're not stored in an array
jnthn But they know their ID...
diakopter right, but comparing pointers is faster than a dereference/load 21:31
I guess that's a microoptimization
jnthn Well, but it makes the collectable header bigger
How much we fit in cache is more important, in general, then how many instructions we execute.
'cus a cache miss is an order of magnitude per level... 21:32
diakopter hm oh
jnthn Anyway, we don't need 32 bits for flags
And we won't have anything bigger than 16 bits in size, I guess...
diakopter heh.
jnthn I mean, bigger than a byte size we can store in 16 bits.
diakopter heh.
jnthn That'd be a huge object... :)
tadzik diakopter: what am I, a browser manufacturer or something? ;) 21:33
diakopter yes
jnthn diakopter: It'd involve a P6opaque with over 8000 attributes. :)
Anyway, we could steal 16 of those bits for object size 21:34
diakopter remember we were going to reserve some of them for repr flags
jnthn If we do make thread ID a pointer then we can up the size and flags back to 32 bits...
We still have 10 flags free. 21:35
diakopter 10 in what base? ;)
jnthn in your base :P
um, 10 :)
diakopter 10 in what base? ;)
jnthn We have 16 bits, and we have 6 flags :) 21:36
diakopter sorry, I only understand unary. 00000000000 is decimal 10
FROGGS 10 flags == 10 bits 21:38
diakopter how many of those flags are rainbow
FROGGS just the rainbow one 21:39
jnthn Anyway, will look at that fix tomorrow 21:42
21:42 yoleaux joined
dalek arVM/nativecall: e4c9d7a | (Gerhard R)++ | src/6model/ (2 files):
Make CPointer.c compile (no other guarantees)
 21:52
arVM: e87b8f2 | jnthn++ | src/6model/reprs/P6opaque.c:
Missing real_data calls in P6opaque.
 21:58
23:08 FROGGS joined
diakopter not_gerd: you around? 23:35

Powered by Cro and the Raku® Programming Language.

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

Thank you!