github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
nwc10 good *, #moarvm 06:38
MasterDuke huh. my libmoar.so is linked against /usr/lib/libgmp. no wonder it wasn't picking up my changes to gmp when i was doing that 13:26
i have `-L./3rdparty/gmp -lgmp`, why isn't it picking up the libgmp.so there? 13:28
timotimo could be the wrong order 13:40
that's sometimes a problem
lizmat is there a reason to not bump MoarVM at this time? getting nwc10's hash fixes / improvements ? 13:48
nwc10 well, you won't get much, as most things aren't in master yet 13:49
lizmat well, at least it will get a bit of a workout ? but if you think it's too early really, then I'll leave it :-) 13:50
nwc10 oh wait, I'm confused. 13:51
there are *some* things in master
yes, they'd be useful
lizmat ok, will bump then 13:52
MasterDuke ok, if i add an additional -rpath argument to point to ./3rdparty/gmp then my MoarVM/libmoar.so points there. but the one in my --prefix which rakudo uses still points to the system gmp 13:53
timotimo i assume you already put the installation piece in? 13:54
LD_DEBUG=file (or so) may help figure this out
nwc10: so where are we at with the hash; is the whole hash storage now one allocation? are a few bits of the hash now in the metadata place? 13:55
nwc10 the former 13:56
(one allocation. cachegrind does seem to like it)
MasterDuke find library=libgmp.so.10 [0]; searching
nwc10 the latter is not ready for prime time
MasterDuke search cache=/etc/ld.so.cache
trying file=/usr/lib/libgmp.so.10
timotimo cachegrind is only for performance, tho?
or do you mean that it's better? 13:57
nwc10 yes. correctness is there. performance makes no sense.
but I'd not realised that I need to disable spesh
timotimo disable or NODELAY and BLOCKING
otherwise performance will be very wobbly
nwc10 I know this *now*. I didn't 24 hours ago :-) 13:58
timotimo d'oh
nwc10 actually, make that 6 hours ago. not 24.
timotimo what can possibly be difficult about the hash-bits-in-metadata change? ;) 13:59
nwc10 a lot more than I expected. 14:00
MasterDuke timotimo: what installation piece did you mean? 14:04
timotimo that it gets copied over to where-ever we expect it to be at runtime 14:07
nwc10: so is there a place where i could look at the WIP? 14:14
MasterDuke hm. i guess that's why changing the references to .so in the makefile worked, i just picked up the system ones? because we don't copy the other .a's we build anywhere 14:29
nwc10 not yet 14:39
timotimo not sure if i can actually look at it if it were there, i'm rapidly tireder 14:45
nwc10 timotimo: I realised that actually my answer was 50% inaccurate. single block allocation is in a branch, with an open PR 15:33
you're welcome to look at that. I'd love you to look at that (or anyone who is not me and feels competant)
[Coke] I am at least not you, but that's all I have here. 15:36
nwc10 :-) 15:37
timotimo … MVM_oops(tc, "MVM_itereky_s called … 16:41
the diff is big :o 16:43

Powered by Cro and the Raku® Programming Language.

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

Thank you!