github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm Set by AlexDaniel on 12 June 2018. |
|||
00:17
squashable6 left
00:19
squashable6 joined
00:47
lizmat joined
01:55
ggoebel_ left
01:57
dogbert2 joined,
MasterDuke left
02:17
ggoebel_ joined
05:47
japhb left
07:58
vesper11 joined
|
|||
El_Che | when packaging there are precomp files here: opt/rakudo-pkg/share/perl6/core/precomp/* | 08:07 | |
I can get read of those | |||
but I also see precomp files in opt/rakudo-pkg/share/perl6/core/short/* | |||
and in ./share/perl6/core/sources/* | 08:08 | ||
08:30
vesper11 left
08:37
patrickb joined
08:38
domidumont joined
|
|||
nine | El_Che: what's that about? | 09:41 | |
jnthn | morning o/ | 10:38 | |
nwc10 | \o | ||
nine | \o/ | 10:40 | |
jnthn | So...let's have a go at the method dispatch resume stuff | 10:50 | |
El_Che | jnthn: are the files in share/perl6/core/sources/* used or are they precomp as well and can they safely be deleted? | 11:16 | |
nine | They are used | ||
And why do you think precomp stuff can be deleted? | |||
El_Che | because for modules they are regenerated | ||
nine | Why regenerate when they are already generated? | 11:17 | |
El_Che | it's for a package | 11:18 | |
nine | so? | ||
El_Che | smaller pkg size | ||
I am ok to living them there, just wondering | 11:19 | ||
nine | As a user of packges I certainly appreciate not having to wait for minutes to compile stuff. That's why I use packages in the first place | ||
El_Che | good point | ||
nine | The whole way how these repositories are structured is to facilitate packaging | 11:20 | |
jnthn | I'm pretty sure they've changed enough to facilitate packaging that anything I might have known about them is now outdated. :) | 11:22 | |
nine | Well, some has, some has not. In any case it was a very interesting exercise to essentially create a database index that does not require modifying existing files :) | 11:27 | |
jnthn | Ooh, yes. | 11:34 | |
Because packages should ideally only add files. | |||
Not tweak existing ones | |||
nine | exactly | ||
jnthn | I'm really glad you took over working on this stuff; packaging is absolutely not me strong point :) | 11:35 | |
*my | |||
nine | But, but, you missed all the fun :D | 11:36 | |
But yes, packaging is quite important to me (because I just got fed up waiting for hours to install CPAN packages on any new machine or after server upgrades). Nice how different interests complement each other :) | 11:37 | ||
jnthn | Tssk, looks like I have another (probably silly) buglet to track down... | 11:44 | |
"Literal object of type Exhausted"...the most Friday bit of debug output | 11:46 | ||
It was silly and easy to find. Yay, one-level deferral works. | 11:50 | ||
Yay, now n-level also :) | 11:58 | ||
nine | that was fast | 12:00 | |
nwc10 | he must be hungry | 12:01 | |
that, or there's something particularly good waiting in the beer fridge | 12:02 | ||
jnthn | I'd already written a test case in the dispatcher test suite that showed it should work in theory, so the question was whether there'd be any surprises once I used that approach on the Rakudo dispatcher implementations. | ||
Thankfully, there weren't. | |||
And yes, I am hungry; thankfully I can hear soup being blended :) | 12:04 | ||
There already is some pretty nice things in the beer fridge, but later this afternoon I'll make the short walk to the Belgian beer bar, where some further nice things are waiting for me to collect. | 12:05 | ||
I'm hopeful that if enough folks order/collect stuff from them, they'll manage to survive. | |||
lunch, bbiab | 12:07 | ||
Spesh doesn't really know that much about new-disp yet. Despite that: | 13:13 | ||
gist.github.com/jnthn/742ffa9d1dce...4dce31436f | |||
patrickb | Wow! That's a factor 7 faster! | 13:36 | |
Altai-man_ | jnthn++ | 13:40 | |
nine | Woah! | 13:45 | |
jnthn | OK, nextcallee and lastcall were about as easy as hoped. | 14:21 | |
callwith and nextwith need quite a bit more thought | 14:22 | ||
Though next I'll do either multi dispatch resumption or, given it's Friday, probably wrap since it's rather easier | |||
walk, bbs | |||
jnthn back | 15:30 | ||
16:36
ggoebel__ joined,
ggoebel_ left
17:00
patrickb left
17:05
patrickb joined
18:03
domidumont left
18:08
MasterDuke joined
|
|||
jnthn | OK, wrap/unwrap successfully implemented in terms of new-disp | 18:19 | |
Speedup is bigger on this one than the method one. gist.github.com/jnthn/1bf4fda2eaea...d5d89c4deb | 18:25 | ||
Oh, no, it's not quite fair | |||
Because it's only doing two levels of callsame, not 4 | |||
And quite a bit of the win is in re-using setup work | 18:26 | ||
otoh, using multiple wrappers is unusual | |||
So maybe this is quite representative | |||
[Coke] | has to feel nice seeing the payoffs | 19:00 | |
jnthn | Yes, finally! :) | ||
nwc10 | if theese numbers hold out, it's going to make the speedups from the hashes look extremeley "meh, whatever" | 19:03 | |
vrurg | Where is the "like" button on IRC? :) | ||
nwc10 | it's very impressive | 19:04 | |
patrickb | The big question is what new-disp will do to the most common "normal" sub and method calls. | 19:05 | |
jnthn | Yes, indeed. There's quite a lot of things at play there. | 19:06 | |
nwc10 | jnthn: t/04-nativecall/18-routine-sig-sanity.t passes all 33 tests but ends with | ||
MoarVM panic: Invalid owner in item added to GC worklist | |||
jnthn | Joy! | ||
nwc10 | I guess that's +#define MVM_GC_DEBUG 1 | ||
ASAN expresses the usual disdain. Long may this continue | 19:07 | ||
jnthn | Yeah. I managed to get a one-off SEGV earlier too, so I know I've got something to hunt | ||
I'm glad of ASAN being content with it :) | |||
nwc10 | did you walk result in interesting provisions from the Belgium bar? | 19:09 | |
jnthn | Yes. | 19:10 | |
nwc10 | Excellent. | ||
jnthn | Which have been cooling for some hours now | ||
Conveniently, that place is about 2 minutes away from the model railway store, where I also had an order to collect. So I've got some afk things to play with this weekend as well. :) | 19:13 | ||
nwc10 | oh well, actually ASAN is still excited by t/02-rakudo/15-gh_1202.t but that's not news | 19:15 | |
oooh, maybe | |||
paste.scsys.co.uk/594534 | 19:17 | ||
jnthn | ooh, hmm | 19:24 | |
Thanks | |||
Will look later; dinner now | |||
nwc10 | I think that there might have been a second fly past. I'd not surpressed the leak checks, and they were making a lot of (black and white) noise | 19:25 | |
enjoy dinner | |||
19:35
evalable6 left,
linkable6 left
19:38
linkable6 joined,
evalable6 joined
19:40
MasterDuke left
19:41
MasterDuke joined
|
|||
nine | Regarding the leak checks: I wonder if we should enable --full-cleanup for processes used in the build (including the local rakudo-m runniner for use by uninstalled rakudo). There are quite a few places where one needs to enable it in various ways to get useful asan output. | 20:25 | |
I figure, it won't hurt to have it on all the time when it's just for build and test and it would give this more involved code path much more exercise | |||
MasterDuke | seems to make sense | 21:39 | |
i just compiled with --ubsan to see if it showed anything that would help me with this panic/segv. it found two unrelated things (and one maybe related, looking at that one now): | 21:45 | ||
src/6model/serialization.c:1704:21: runtime error: left shift of 4239 by 52 places cannot be represented in type 'long int' | |||
src/6model/reprs/MVMMultiCache.c:290:5: runtime error: null pointer passed as argument 2, which is declared to never be null | |||
that's just from running one file of the nqp build | 21:46 | ||
m: say 4239 +< 52 | 21:52 | ||
evalable6 | 19090758820423532544 | ||
MasterDuke | m: say (4239 +< 52) - 2**64 | 21:53 | |
evalable6 | 644014746713980928 | ||
MasterDuke | wow, ubsan really doesn't like how we access a lot of structs/unions. tons of `runtime error: member access within misaligned address 0x562299711ae4 for type 'union MVMRegister', which requires 8 byte alignment` and also for various structs | 22:18 | |
22:45
MasterDuke left,
MasterDuke joined
|