github.com/moarvm/moarvm | IRC logs at irclog.perlgeek.de/moarvm/today
Set by moderator on 7 June 2013.
00:19 rurban joined 00:46 benabik joined 01:44 JimmyZ joined 04:04 labster joined 04:15 rurban joined 04:32 mrallen1 joined 05:22 cognominal joined
dalek arVM: b532b8a | jimmy++ | / (8 files):
Implement and map nqp::radix.
 05:31
arVM: 56f77a4 | jimmy++ | nqp-cc/nqp-src/NQPHLL.nqp:
Uncomment more of NQPHLL.
arVM: bc827a2 | jimmy++ | / (4 files):
Merge branch 'master' of github.com/MoarVM/MoarVM into zhuomingliang/patch-2
arVM: 94da839 | jimmy++ | / (4 files):
swtich radix op back to use int64 since int16 is NYI
arVM: 68e0fbf | (Matthew Wilson)++ | / (10 files):
Merge pull request #14 from zhuomingliang/patch-2

Implement nqp::setencoding
diakopter JimmyZ++
JimmyZ: whatcha working on next? ;) 05:32
JimmyZ I just want to close the pull request because the Merge branch 'master' commit :)
diakopter oh, oops 05:34
meh
JimmyZ diakopter: I'm still looking
;)
diakopter how is int16 not supported? 05:35
the qast->mast compiler should auto-narrow
JimmyZ diakopter: nope
diakopter: coercion is not supported 05:36
sorear whee! progress!
diakopter jnthn: explain what coercion would do, and I'll do it :P 05:37
gah
JimmyZ: ^
oh, jnthn should be landed by now... o_O
JimmyZ I'm not understand what's the different coercion method in QASTCompilerMAST.nqp line 269 and unbox in QASTOperationsMAST.nqp line 334 05:39
s/different/different between/g
diakopter oh 05:41
I just mean
did you try it with it set to int16? ;)
JimmyZ yes
diakopter: see QASTOperationsMAST.nqp line 1181, there is no $MVM_reg_int16 05:42
diakopter: ;)
diakopter what happened when you tried it? 05:43
JimmyZ diakopter: a lot things happend, first in QASTOperationsMAST.nqp, then in QASTCompilerMAST.nqp, and I see the code in interp.c, there is no support for int16 too. 05:45
diakopter github.com/MoarVM/MoarVM/blob/mast...T.nqp#L181
is supposed to fudge that
JimmyZ diakopter: #L1181
05:46 rurban joined
diakopter what do you want me to see about that line 05:48
I mean, I see it only unboxes to int64 05:49
JimmyZ diakopter: I mean I can't use int16 because it can't box ot int16 05:50
hehe
so I switch back to int64
diakopter JimmyZ: because of L181 (I pointed to), you should just need to add the $desired == $MVM_reg_int16 case to the L292 branch of method coercion in Compiler 05:53
JimmyZ diakopter: oh
diakopter JimmyZ: (well, also int32 and int8) 05:54
I put that L181 thing in there so it would automagically narrow once those cases existed 05:55
sorear diakopter: let's assume major jet lag
diakopter yes. :D jnthn will be a long while recovering 05:56
JimmyZ diakopter: I had tried add $desired == $MVM_reg_int16 case to L292, I gave up to do it because other problems 05:57
diakopter JimmyZ: what other problems? I'm glad to help
(now is the right time to fix that) 05:59
JimmyZ diakopter: compile.c complained
diakopter what was its complaint :P 06:01
JimmyZ I can try reprodcue it 06:03
diakopter sorear: flightaware.com/live/flight/SAS926
JimmyZ wait a moment
diakopter ok
I don't like that the "Merge pull request" button on the web still works if commits have been added/modified to the pull request after the webpage describing the pull request was generated 06:09
nwc10 oh, interesting 06:11
I don't like the "merge pull request" button simply because it does a merge commit
sorear diakopter: appears to have arrived?
nwc10 which makes things more messy than they could be
oh, and it doesn't run tests for you
JimmyZ well, it can run tests for you, if you use travis-ci 06:12
diakopter dukeleto volunteered to set that up for us
JimmyZ diakopter: At Frame 79, Instruction 16, op 'radix', operand 1, MAST::Local of wrong type (4) specified; expected 2 06:31
nwc10 in MoarVM, does "precise GC" mean that there is no need for C stack walking? 06:34
jnthn nwc10: yes
nwc10 cool 06:35
jnthn nwc10: You can't just go guessing if things are pointers if you're going to move objects. :)
JimmyZ diakopter: maybe nqp needs my native int16 is repr('P6int') is nativesize(16) { }
nwc10 gah, yes, true, not thought of that :-)
sorear are we planning to (eventually) support pinning? 06:36
sorear wonders if there will be anything left to do on moarvm after he finishes rakudo/jvm stuff :D 06:37
diakopter probably implemented by "promote to gen2 and immediately run gc" or something
sorear the mono native GC supports pinning objects in the nursery
diakopter *smile* well alrighty then :) 06:38
nwc10 hangon, is the MoarVM nursery a semi-space copying thing? 06:39
jnthn yeah 06:40
nwc10 so you can't pin in there?
jnthn Well, the current NativeCall reprs hold the O(1) marshalled C memory at a level of indirection
And that is unmanaged by the GC
So if that's good enough we can punt on pinning. I can't think of another place that'll make us need it.
If we for some reason do, there's GC textbooks... ;) 06:41
nwc10 is that like "if all else fails, read the instructions" ?
jnthn Vaguely ;)
diakopter the only other place I can think of possibly needing it would be some repr that wants to enter some long-running op that doesn't block GC but needs to dig in objects 06:42
[of its own repr]
06:42 tomyan joined
jnthn diakopter: That sounds...undesirable anyway ;) 06:43
Back after a nap...will backlog here properly then.
06:46 rurban joined 07:08 JimmyZ joined 07:20 tomyan_ joined 07:25 JimmyZ joined 07:35 Tene_ joined 07:36 __sri joined 07:49 rurban joined 07:54 JimmyZ joined 08:21 tomyan joined 08:27 flaviusb joined 08:47 flaviusb joined 08:54 rurban joined 09:06 flaviusb joined 09:26 flaviusb joined 09:44 cognominal joined 09:55 rurban joined 10:12 woosley left 10:57 rurban joined 11:24 tgt joined 12:02 rurban joined
JimmyZ jnthn: ping 12:17
jnthn: Does setencoding second arg intends to be int in oplist? or should I chane it to str? 12:20
jnthn JimmyZ: pong 12:22
JimmyZ: It needs to be str if it's going to be used to directly implement the relevant nqp:: op
Also, getstdin and friends can't be nqp:: mapped yet as they have the wrong op signature. There's a reason I didn't put those in.
JimmyZ jnthn: thanks
jnthn Also: 12:23
+# XXX: should be
+# 0x83 attrinited w(int16) r(obj) r(obj) r(str)
No, it should not be. That'd be contradictory with the entire rest of the op set... :)
JimmyZ jnthn: ok, thanks :) 12:24
jnthn The general principle is that operations are done at full width
JimmyZ so no int16? should to be int64?
jnthn The other sizes are there for storage primarily.
In that op, yes.
JimmyZ jnthn: so is in radix op? 12:25
jnthn yeah, the comment should go away there... 12:26
I musta missed that when reviewing the PR 12:27
The extend/trunc ops near the top of oplist are used to go between the sizes. 12:28
JimmyZ jnthn: thanks
jnthn But they really are intended for implementing e.g. my int16 $x; style things. 12:29
JimmyZ jnthn: gist.github.com/zhuomingliang/5743364 Does this make sense? 12:33
12:36 birdwindupbird joined
jnthn if(!encoding_name_init) { 12:36
encoding_name_init = 1;
Should set the flag *after* doing the initialization work or it's certainly a race condition if two threads hit this code.
Also, space between if and ( :) 12:37
JimmyZ jnthn: updated, plz take a look again 12:38
jnthn For bonus points, include the incorrect encoding name in the error message :) 12:39
JimmyZ jnthn: updated ;) 12:47
jnthn yay 12:51
JimmyZ could you merge my pull request so I can push a new request easily? :) 12:52
jnthn Which one? 12:53
diakopter jnthn: you didn't miss the comment, and neither did I before I merged it
it was inserted into the pull request between when it was rendered in my browser and when I clicked merge 12:54
jnthn diakopter: oh...
JimmyZ jnthn: two, so I can revert something and push a new request easily without merge branch commits 12:56
jnthn JimmyZ: Well, but github.com/zhuomingliang/MoarVM/co...fa1fb5a39f maps some ops it should not, so I don't really want to merge that. 12:57
JimmyZ jnthn: oh, I can close this one 12:58
jnthn And P6opaque doesn't actually have an attribute_initialized implementation yet, meaning that if hit, the codepath using it will explode. I can look at that... 12:59
13:02 rurban joined
JimmyZ yay, a new pull request 13:11
jnthn That looks better. 13:14
JimmyZ++
arVM: 308e290 | jimmy++ | / (9 files):
some fixes to setencoding
arVM: 4190ebc | jonathan++ | / (9 files):
Merge pull request #17 from zhuomingliang/patch-3

Implement nqp::setencoding
arVM: 51dcc44 | jimmy++ | src/io/socketops.c:
error msg improvement to socketops
 13:17
arVM: 4da8e37 | jonathan++ | src/io/socketops.c:
Merge pull request #18 from zhuomingliang/patch-3

error msg improvement to socketops
JimmyZ jnthn: if the op are using int64, should the function args also should be int64? for example: flag args in MVM_radix 13:19
jnthn JimmyZ: That probably saves us some casts. 13:20
JimmyZ jnthn: ok, thanks, I will keep it in mind 13:21
;)
13:37 vm joined
diakopter I suspect my setencoding preceded nqp's 13:42
jnthn yes 13:43
A bunch of the IO bits preceded the nqp:: ops, so there's some alignment work to do. 13:44
diakopter so I won't feel too badly about it beint wront ;)
being wrong
jnthn No, not being able to see into the future is a common limitation ;) 13:46
diakopter gah 13:53
Also, I wasn't even trying to do that, merely make standins 13:54
13:59 lizmat joined 14:03 rurban joined 14:08 rurban joined
dalek arVM: 535a9a2 | jimmy++ | src/io/fileops. (2 files):
change return type of MVM_file_set_oshandle_encoding to void
 15:41
arVM: 03bee22 | jonathan++ | src/io/fileops. (2 files):
Merge pull request #19 from zhuomingliang/patch-1

change return type of MVM_file_set_oshandle_encoding to void
16:02 rurban joined 16:04 tomyan joined 16:05 rurban joined 16:57 rurban joined 17:13 tgt joined 17:23 rurban joined 17:51 tgt joined 18:23 rurban joined 18:25 rurban1 joined 18:54 benabik joined 19:05 Guest1337 joined 19:24 tomyan joined 20:05 mrallen1 joined 20:10 tomyan joined
dalek arVM: eb18d8e | jnthn++ | src/6model/reprs/MVMIter.c:
Fix copy-pasto.
 20:38
21:10 Guest1337 joined 21:18 lizmat joined 22:08 tgt joined 22:12 rurban joined 22:57 tomyan joined
dalek MoarVM: 88f5ea1 | (Chris 'BinGOs' Williams)++ | build/Config/BuildEnvironment.pm: 22:59
MoarVM: Add build environment for FreeBSD
MoarVM:
MoarVM: Tested on FreeBSD 9.1 (i386) with both clang and gcc
MoarVM:
23:00 dalek joined 23:03 tomyan joined
diakopter aww, poor dalek killed'd itself 23:03
23:34 rurban joined 23:38 rurban 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!