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