| IRC logs at
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
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
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. 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 19:17
jnthn ooh, hmm 19:24
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