01:21 krunen joined 01:49 FROGGS joined 05:06 bcode joined 05:21 Util joined, lee_ joined 05:26 rurban_ joined, lue joined, oetiker_ joined, harrow joined, timotimo joined, flussence joined, tokuhirom joined, TimToady joined, retupmoca joined, hoelzro joined, vendethiel joined, japhb_ joined 05:33 rurban_ joined, lue joined, oetiker_ joined, harrow joined, japhb_ joined, vendethiel joined, hoelzro joined, retupmoca joined, timotimo joined, flussence joined, tokuhirom joined, TimToady joined 06:06 oetiker joined 06:51 FROGGS joined 07:03 zakharyas joined
nwc10 jnthn: origin/inline builds OK with ASAN, seems that t/spec/S32-io/IO-Socket-Async.t failure was transient 08:35
otherwise no difference from master, just t/spec/S17-lowlevel/lock.rakudo.moar fails these days 08:36
jnthn fails ASAN? 08:47
Yeah, I think I have the traces from that sitting around in a browser tab still :)
nwc10 heap-use-after-free, seems to be 3 threads involved, 28 bytes inside of 48-byte region 08:54
I think that it's the same one
09:01 donaldh joined
lizmat that feels low level enough to be the reason for all sorts of crashes that we've seen under load, no? 09:20
and good morning! :-)
jnthn lizmat: Could quite easily be a factor 09:21
Hard to know how significant.
Well, other than fixing it and seeing how things look :)
lizmat :-)
timotimo good morning lizmat :) 09:25
and jnthn and nwc10
dalek arVM: 145d5a1 | sergot++ | src/spesh/dump.c:
keep the style

bracket should be after "case * :" in the same line		 12:35
arVM: 7933236 | sergot++ | src/gc/orchestrate.c:
warning cleaned

cast from size_t to int added
MoarVM: f1ac8e2 | (Tobias Leich)++ | src/ (2 files):
MoarVM: Merge pull request #101 from sergot/master
MoarVM:
MoarVM: warning cleaned, style correction
13:41 jnap joined 14:05 btyler joined 14:16 FROGGS joined 16:37 LLamaRider joined 17:37 jnap joined 18:18 vendethiel joined 20:02 vendethiel joined
lizmat hopes brrt didn't get mugged at the station 20:08
jnthn Are Netherlands stations well known for muggery?
lizmat well, it was Eindhoven... what can I say :-) 20:15
20:16 brrt joined
brrt \o #moarvm 20:16
jnthn hi brrt :)
brrt hi jnthn :-) 20:17
i don't know if you've heard, but lizmat++ and woolfy++ have kindly sponsored a new machine
so that i could work faster
and its amazingly fast 20:18
so, thanks again :-)
lizmat you're welcome
did you install the SSD yet ?
brrt not yet
lizmat ah, then building will become much faster still :-) 20:19
brrt yes
FROGGS brrt: is it so fast that you don't consider doing the JIT anymore? O.o
brrt not so fast, no
:-)
FROGGS good :o)
brrt i'm going to try and see if fedora works
jnthn :) 20:20
jnthn hopes it means we get a JIT faster ;)
lizmat hopes that as well :-)
brrt i'm thinking that was the plan :-)
lets not get ahead of time - ha ha pun :-p 20:21
brb :-)
jnthn :P
.oO( You know it's a bad pun when you have to point it out :P )
brrt true 20:22
jnthn d'oh, my first Moar patch of the evening makes a segv
oh, duh 20:24
20:24 lee__ joined 20:25 krunen_ joined 20:29 Util joined
dalek arVM/inline: 9496c79 | jnthn++ | src/spesh/graph. (2 files):
Start tracking local/lexical counts in graph.

We'll need to modify these as we inline.		 20:41
arVM/inline: e304fc3 | jnthn++ | src/spesh/inline. (2 files):
Start merging of inlinee into inliner spesh graph.

This adds basic graph merging (some bits missing yet) and sketches out the next bits of the inline algorithm.		 21:43
jnthn m: say 0x265 21:44
camelia rakudo-moar 28d672: OUTPUTĀ«613ā¤Ā»
21:46 jnap joined 21:52 vendethiel joined
jnthn d'oh, first run of that code exploded...turns out not because the code is wrong so far, but because it tried to do multi-level inlines. :) 21:55
(did the initial bits of work to inline capture_prune into prune, then wanted to inline prune into term:sym<value>...) 21:57
(which given both are tiny isn't such a weird thing to want to do) 21:58
22:03 donaldh joined 22:05 nebuchadnezzar joined
nebuchadnezzar hello 22:05
jnthn hi 22:08
m: say 15 +< 3
camelia rakudo-moar 28d672: OUTPUTĀ«120ā¤Ā»
jnthn m: say 16 +< 3 22:09
camelia rakudo-moar 28d672: OUTPUTĀ«128ā¤Ā»
donaldh Coke: I don't like the hardcoded port 5000 either. I plan to extract the port finding code from IO-Socket-INET.t into a separate package and use that. 22:10
22:14 vendethiel joined
donaldh .tell Coke: re irclog.perlgeek.de/perl6/2014-06-06#i_8834904 I don't like the hardcoded port 5000 either. I plan to extract the port finding code from IO-Socket-INET.t into a separate package and use that. 22:17
oh, not .tell ? 22:18
.tell Coke re irclog.perlgeek.de/perl6/2014-06-06#i_8834904 I don't like the hardcoded port 5000 either. I plan to extract the port finding code from IO-Socket-INET.t into a separate package and use that.
TimToady ENOYOLEAUX
donaldh Oh my. Wrong channel anyway. 22:19
donaldh crawls away
dalek arVM/inline: d0369eb | jnthn++ | / (5 files):
Note which operands are spesh slots.

Need to fix these up during inlining, and should do it programatically rather than hard-coding instructions.
nebuchadnezzar I'm plannig to open an Intent To Package of MoarVM on Debian and I'm wondering a quite basic question, is it normal to include 3party headers directly in moar.h? Shouldn't they be moved in some private use header file? 22:28
I manage to build deb packages for moarvm and nqp-m but rakudo fails at includes of moar.h since it does not find dyncall.h
jnthn Hmm 22:29
I guess Rakudo's C extension doesn't direclty need those
nebuchadnezzar I find these includes paste.debian.net/103800/ 22:30
jnthn Yes, it needs a bunch of the MoarVM stuff
Oh...hmm
And various data structures it imports will end up pointing to 3rdparty things pretty quickly. 22:31
Including needed ones.
So yeah, it needs to be that way.
22:32 vendethiel joined
jnthn At least, it's certainly not a trivial thing to make it not be that way. 22:32
nebuchadnezzar aren't they access through moarvm API ?
hmm ok 22:33
jnthn Well, it's more that we expose types of MVMThreadContext, which inside of it has, e.g., uv_mutex
No, we don't monkey with them directly.
But since they're sat there in the struct...
Anyway, is this an absolute blocker? 22:34
nebuchadnezzar got it
jnthn is hoping not; the Fedora packaging didn't run into it, afaik
nebuchadnezzar rakudo-moar will need some updated libuv at least
jnthn I think we're tracking that quite closely; there was some recentish bug fix we depend on, iirc. 22:35
nebuchadnezzar according to 3party/README.md, libatomic_ops "are NOT included in any built binaries", this one could be moved somewhere else, don't it? 22:37
jnthn "moved somewhere else"?
jnthn also wonders how true that remark is 22:38
I know it's true on Windows where libatomic_ops is purely a header include
nebuchadnezzar sorry, this one was not an issue since the debian package is the same version as 3party lib
well, I will start by building moarvm and nqp-m, will see rakudo later with Debian rakudo team 22:39
jnthn OK, thanks.
nebuchadnezzar thanks for your time and your advices 22:40
jnthn Lemme know if there's some blocker.
<-- Windows background, not good at knowing the needs of Linux packagers
nebuchadnezzar I admit I have no clue about non Linux OS ;-) 22:41
jnthn :)
Sure; anyway, I'm willing to look into stuff that helps us get packaged on Linux, as it matters.
nebuchadnezzar such things tend to make headers quite cumbersome 22:42
hmm, cumbersome may not be the right word I was looking for
to tired to write english correctly, sorry: Time To Sleep 22:43
jnthn Sleep well :) 22:47
22:48 donaldh joined
dalek arVM/inline: 3557ed8 | jnthn++ | src/spesh/inline.c:
Spesh slot fixups in inline graph merge.
 22:50
jnthn OK, enough for today :) 22:51
'night, all

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!