Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-02-18

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

All times shown according to UTC.

Time Nick Message
01:54 crab2313 joined #moarvm
04:10 FROGGS[mobile]2 joined #moarvm
05:32 woosley joined #moarvm
07:10 FROGGS[mobile] joined #moarvm
07:18 FROGGS joined #moarvm
08:21 nwc10 good *, MoarVM
08:25 woosley joined #moarvm
08:30 timotimo hi there
08:31 FROGGS[mobile] joined #moarvm
08:37 odc joined #moarvm
08:38 woosley joined #moarvm
08:45 jnthn o/
08:47 timotimo i don't seem to have a very clear design yet for making the inlining cascade to cause previously marked-as-poisoned things that were inlined non-poisoned again :\
08:47 nwc10 $ head -2 3rdparty/libatomic_ops/src/atomic_ops/sysdeps/ibmc/powerpc.h
08:47 nwc10 /* FIXME.  This is only a placeholder for the AIX compiler.             */
08:47 nwc10 /* It doesn't work.  Please send a patch.                               */
08:48 nwc10 so, that's no MoarVM on AIX either
08:49 timotimo aaw, shucks!
08:54 nwc10 at least, not without either a PPC assembler hacker, or a serious hack that provides a (much slower) implementation of the used subset of the atomic ops emualted using pthread primitives
08:55 timotimo oh yikes
09:01 jnthn It...has no atomic primitives?
09:01 jnthn nwc10: I think the library does know how to do it in terms of pthreads.
09:01 nwc10 no, I think it means "no-one has done it yet"
09:03 nwc10 yes, seems to
09:07 nwc10 libuv doesn't yet work on HP/UX, but there seems to be an open pull request: https://github.com/joyent/libuv/pull/1069
09:08 nwc10 also, github's https certificate is rejected by both the AIX and HP/UX machines I have access to
09:08 nwc10 meaning a manual hack of config to force the submodules over to git://
09:08 nwc10 which is a pain
09:08 nwc10 you can't win
09:08 timotimo i don't have permission to push to the moarvm.org repo
09:20 nwc10 dyncall-- # No, using BSD/GNU make syntax does *not* make your makefile Generic. FAIL.
09:20 nwc10 time to drop some classic hardware on the weenies.
09:21 nwc10 "that should learn 'em"
09:21 nwc10 fortunately I have a gmake. Unfortunately I'm going to have to hack something else to make it use that
09:21 nwc10 but, gah, portability. All the world is not a VAX.
09:21 timotimo heh.
09:21 timotimo yeah, portability is fucking hard.
09:22 nwc10 yes. But it's not helped if you start on an x86 GNU/Linux system with ELF
09:22 timotimo right.
09:22 nwc10 at least x86_64 got a bit more exacting with Position Independant Code
09:22 nwc10 but the rest are utterly forgiving :-(
09:22 timotimo the web devs have the right idea with their "mobile first" ideology
09:23 nwc10 because the mobile browsers are the most unforgiving? small resources, and lacking features?
09:23 timotimo small screens, no mouse/keyboard
09:23 timotimo all that, yes
09:25 nwc10 nope, you're not going to get MoarVM on AIX because dyncall doesn't support it
09:25 nwc10 ffi does
09:25 timotimo :\
09:27 jnthn On the one hand, argh dependencies. On the other - if we'd built it all ourselves, we'd (a) be further behind, and (b) stand a chance of working on even less platforms.
09:31 nwc10 yes, looks like libuv HP/UX will arrive soon
09:31 nwc10 is dyncall significantly better than ffi?
09:31 nwc10 libffi, that is
09:34 nwc10 anyway, Yaks. Yaks, all the way down
09:38 JimmyZ dyncall supports PS2 and libffi doesn't?
09:41 timotimo it's like someone should build a proper, portable dynamic stuff-calling library or something
09:42 jnthn nwc10: Well, dyncall had (imho) the nicer API and was a bunch easier to make work on Windows...
09:42 moritz or preferably patch the existing ones :-)
10:06 nwc10 jnthn: I'm suspicious that the answer is ultimately going to have to be to support both, got get AIX
10:07 jnthn "to get"?
10:08 nwc10 to get MoarVM to work on AIX
10:08 jnthn ah
10:08 nwc10 uthash-- # no, __typeof() isn't portable enough
10:08 nwc10 that one might sink HP/UX
10:10 jnthn nwc10: There's also one dyncall aptch from Andy for Solaris yet to go in.
10:10 jnthn *patch
10:10 jnthn I meant to get it in before, then bumped to latest dyncall to apply it on top and got issues...
10:11 jnthn And didn't get around to tracking them down yet.
10:11 nwc10 yay, bodged round that one
10:12 jnthn nwc10++ # porting
10:12 nwc10 this is just yak shaving to get a non-gcc non-clang compiler
10:18 jnthn (and non-MSVC too :))
10:23 tadzik joined #moarvm
10:23 nwc10 right, but I don't have a gmake on HP/UX
10:23 nwc10 so that Yak is going to have to be nuked
10:50 nwc10 oh, I did.
10:50 nwc10 but dyncall doesn't support HPPA or Itanium either. So that's, er, useless.
10:50 nwc10 anyway, I might have enough Yaks shaved to actually do the other thing.
10:57 nwc10 why do both MoarVM and nqp have dyncall bundled?
10:58 jnthn nwc10: nqp has it bundled because that's where the Parrot interop was built.
10:59 nwc10 ah OK
12:51 crab2313 joined #moarvm
13:11 timotimo jnthn: can has moarvm.org commitbit?
13:12 FROGGS timotimo: you wanna optimize it? :P
13:12 jnthn timotimo: sure, moment
13:12 jnthn probably for less jnthn typos :P
13:13 jnthn bah, I typed githug instead of github...
13:14 timotimo :)
13:14 moritz -)
13:14 moritz s/^/:/
13:15 jnthn timotimo: should be done
13:21 timotimo yup
13:21 jnthn Do we want a commit hook for reporting here, or not care
13:21 jnthn ?
13:22 timotimo it'd probably be pretty non-noisy, so if it's not much work, go for it
13:33 jnthn Should be set up now
13:34 jnthn Guess we find out next time there's a push :)
13:35 nwc10 jnthn: "bother". I can't see a clean way to set a #define that has a space in it, other than create something like a config.h file
13:35 nwc10 in that, CFLAGS are passed down to the configure script of 3rdparty/libatomic_ops and *it* is choking on stuff with spaces
13:35 nwc10 well, it's that or CFLAGS and "the other CFLAGS" in Makefile.in
13:39 jnthn urgh
13:40 nwc10 yes. that's roughly what I thought
13:40 * jnthn sometimes forgets that libatomic_ops actually has a .c to build on some platforms.
13:41 nwc10 hey, that's still better than the platforms where it's #error
13:41 jnthn On Windows, there's a sufficiently sane interface to all this stuff that it can provide nice mappings to all the things with #define...
13:41 jnthn True :)
13:41 nwc10 anyway, at least one of the third party configure scripts is going to choke, even if that one is "fixed"
13:42 nwc10 anyway, apart from that, I have static inline probing working
13:42 nwc10 and building the C files
13:42 jnthn ooh! :)
13:42 nwc10 yes.
13:42 jnthn nwc10++
13:42 nwc10 $deity knows if it will work first time on Win32, but it does work with IBM and HP's compilers
13:42 jnthn Does this mean I have to stop writing macros? ;)
13:42 nwc10 even though the libraries don't
13:43 nwc10 not *quite*
13:43 nwc10 also, there's going to be some fun with header file ordering
13:43 jnthn Oh. :(
13:43 nwc10 because macros that contain macros don't get confused if the definition order is "wrong"
13:44 nwc10 and macros that are actually doing "macro" things can't go
13:44 nwc10 but most aren't
13:45 timotimo jnthn: you didn't re-upload my moarvm.org changes :P
13:47 jnthn l8r :P
13:47 timotimo k
13:47 jnthn I'll just set up an auto-pull thing
13:47 jnthn So then I can forget it.
13:47 timotimo it's just the footer padding change anyway
14:21 nwc10 parallel make appears to be bust on FreeBSD :-(
14:27 timotimo 0.19user 0.03system 0:00.23elapsed 99%CPU (0avgtext+0avgdata 89000maxresident)k
14:27 timotimo i wonder if this is the result of my partial inlining work?
14:29 timotimo i don't think i've seen a memory usage for say 1 this low yet
14:31 timotimo 19584maxresident - nqp-m -e 'say(1)' with partially inlined stuff
14:32 timotimo 20200maxresident - without
14:32 timotimo that's not bad, and it's going to get even better
14:34 timotimo also, it dips below 0.04 elapsed more often with the branch than without :3
14:37 timotimo oh, i was supposed to replace the block with Stmt, not Stmts
14:40 timotimo interestingly, that change made say(1) use *more* ram
14:43 jnthn A lot more, or a little more?
14:43 timotimo 19816maxresident
14:44 jnthn Stmt in theory, when applied correct, produces better code, but does a little more bookkeeping
14:44 timotimo ah, i didn't know about the bookkeeping parts
14:44 timotimo well, it'll all change massively again once i figure out how to make poisoning cascade properly :\
14:44 jnthn Well, it has to know what locals it should toss
14:45 jnthn Just a question: you are applying the lowering to param decls as well, yes?
14:45 timotimo shouldn't that info be flattened into the bytecode pretty well, though?
14:45 timotimo no, i bail out if i see params
14:45 timotimo how do i handle params properly?
14:45 jnthn Oh!!
14:45 jnthn In NQP, you can :scope('local') a param just fine.
14:45 timotimo oh!
14:46 jnthn The code-gen does pretty much exactly the same up to the final store.
14:46 timotimo good news :)
14:46 timotimo this shall probably hit for loops pretty hard, then
14:46 timotimo oh
14:46 jnthn uh, those ain't so simple.
14:46 timotimo except if it uses $_, which is dynamic, so i bail out
14:47 jnthn Yeah, and also you need to treat for's block as a declaration, really.
14:47 timotimo oh, because they have values, aye?
14:47 jnthn Just because of how we code-gen 'em really...
14:48 jnthn The code-gen expects to invoke.
14:48 timotimo OK
14:48 jnthn We can flatten them but it won't fall out of what you're dong.
14:48 jnthn doing
14:48 jnthn It needs a little more anayslyis.s
14:48 jnthn argh
14:48 jnthn analysis.
14:49 timotimo - QAST::Op(decont)Error while compiling op for (source text: "@collisions -> $name {\n            unless has_method($target, $name, 1) {\n                nqp::die..."): Operation 'for' expects a block as its second operand
14:49 timotimo yup :)
14:49 jnthn At least it's smart enough to say so :)
14:49 timotimo i'm not exactly sure how to figure out in what case i'm touching the block that expects to be the block for a for
14:49 timotimo except with a contextual
15:15 nwc10 jnthn: I mailed the compiler list some patches
15:16 jnthn nwc10: ok, I'll look this evening.
15:16 jnthn Thanks.
15:16 nwc10 cool. There's technically "no urgency" as I think we ought to wait for Andy D's go-ahead before "stealing" his code verbatim
15:17 nwc10 (the first patch)
15:17 nwc10 but he's been awake and mailing in the past hour, so that might not take long
15:18 timotimo he has no reason to not allow us to use the code, no?
15:19 jnthn negate much? :P
15:19 nwc10 he's contributed patches before. I fully expect him to say yes.
15:19 nwc10 but it's a complete blatant copy, so I thought it polite and appropriate to ask permission
15:20 timotimo yeah, that was absolutely right
15:25 jnthn Indeed
16:11 crab2313 joined #moarvm
16:17 timotimo At Frame 2, Instruction 11, op 'param_rp_o', operand 0, expected MAST::Local, but didn't get one -- not quite sure how i did that :D
16:19 jnthn Congrats :P
16:20 woolfy left #moarvm
16:31 timotimo sometimes i get too easily discouraged, i find.
16:32 jnthn Well, some things we do here are genuinely tricky.
16:33 jnthn I certainly don't nail everything first time, and I certainly do run into bugs that get in the way and need fixing.
16:33 timotimo heh.
16:33 timotimo yeah, in this case it's just that i'd have to rethink the way i store the information for both poisoning and transformation in the case of not poisoned lexicals
16:34 timotimo at the moment i have a stack of hashes that go from name of lexical to a list of QAST::Var instances that need to be changed
16:34 timotimo and whenever i find a lexical be used deeper down than it ought to, i delete that key out of the hash
16:35 timotimo i might have to carry around a second hash that goes from name of lexical to deepest nested use and decrement all the values for all the used lexicals whenever i inline
16:35 FROGGS I've not hit a single bug when working on v5 :P
16:35 timotimo i bet you didn't :)
17:54 frodwith joined #moarvm
18:02 tgt joined #moarvm
18:36 jnap joined #moarvm
18:40 benabik joined #moarvm
19:03 FROGGS joined #moarvm
19:50 benabik joined #moarvm
19:51 lizmat joined #moarvm
19:57 woolfy joined #moarvm
21:38 eternaleye joined #moarvm
21:51 woolfy left #moarvm
22:08 cognominal joined #moarvm
22:09 eternaleye joined #moarvm
22:50 ashleydev joined #moarvm
23:05 eternaleye joined #moarvm
23:09 d4l3k_ joined #moarvm
23:14 jnap joined #moarvm

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