13:29 ilbot3 joined
moritz aye 13:29
done 13:30
also timotimo
13:31 timotimo joined
timotimo o/ 13:31
moritz oh hai
I've invited all Rakudo contributors from this month
timotimo has the time come where signal-to-noise in #perl6 has become too bad?
moritz dev signal, at least 13:32
user signal is still pretty high
timotimo ah, yes 13:33
jnthn Yeah...I gave up backlogging #perl6, but suspect I'm missing stuff.
moritz I've reconfigured rakudo and nqp to report their commits here, not in #perl6 anymore 13:34
guess I should do the same in roast
timotimo hmm. roast may want more feedback from users compared to rakudo and nqp perhaps?
perlpilot moritz++
moritz timotimo: don't think so
masak moritz++ 13:35
13:36 camelia joined
timotimo OK 13:36
perlpilot m: say "yay!"
timotimo carry on :)
perlpilot hmm
moritz the first answer after a fresh restart always needs ages 13:37
due to Bot::BasicBot's rate limiting
camelia rakudo-moar b243a9: OUTPUTĀ«yay!ā¤Ā»
13:42 RabidGravy joined
RabidGravy erp 13:42
moritz Gesundheit 13:44
13:44 Woodi joined 13:48 llfourn joined 13:57 Skarsnik joined 14:39 YvargDibar joined 14:43 SauceRageuse joined 14:53 hoelzro joined
hoelzro o/ #p6dev 14:53
jnthn o/ hoelzro 14:54
15:06 RabidGravy joined
jnthn So, time for some Perl 6 hackin' 15:19
RabidGravy eeeek! 15:22
timotimo poor mister gravy
jnthn So I'm looking at these compilation unit unique IDs we have 15:27
And realizing we use them for rather little down inside the VM 15:28
But also that we should be able to get away with making them way shorter 15:30
timotimo +1 on making them shorter :)
jnthn makes them just a stringified integer 15:33
I think their needing to be so very unique dates back to the Parrot days 15:34
timotimo "an integer"? does that mean something like "starting at 0"?
jnthn yeah 15:35
I think we might actually try and make them real integers in the future but it's...fiddly
(Bytecode back-compat)
timotimo right 15:36
we'll have a pretty significant saving none-the-less
what were cuuids before? like 32 characters?
jnthn cuid_NNN_timestamp before 15:37
now just NNN
15:37 nine joined
jnthn Yeah, in Rakudo it saves 1.4MB off the empty loop program 15:37
nine So this is like the core developers channel?
jnthn nine: Yeah. Rakudo/NQP guts, hopefully at a traffic level that folks like me might be able to backlog again :) 15:38
nine nice
timotimo oh, wow.
jnthn: have you considered that for immutable strings (like the new cuuids), we can just use the fixed size allocator + strlen? 15:41
jnthn Well, I was just looking at them now and wondering, since we use them so rarely, whether to just look them up on-demand. 15:42
Not make an MVMString out of them at all
Damn, forgot to measure Rakudo's CORE.setting before the chance
*change
If anybody does get a number before/after feel free to pass it along, and it'll make it into the weekly report :) 15:43
timotimo i can do that 15:44
waiting for you to push the patch now
jnthn I did? 15:46
Where's dalek? :)
timotimo ah, there it is 15:47
(the patch)
i pulled rakudo and moar, but not nqp :D
jnthn ah, it was an NQP match
*patch
15:47 [Coke] joined
timotimo yeah, that's what i saw :) 15:48
m: say 100 * 11246944 / 11531000 15:50
camelia rakudo-moar b243a9: OUTPUTĀ«97.536588ā¤Ā»
timotimo m: say (11246944 R- 11531000) / 1024
camelia rakudo-moar b243a9: OUTPUTĀ«277.398438ā¤Ā»
timotimo not too shabby
even with the shorter cuuids, regenerating the stage0 files now still makes them a little bit bigger 15:55
16:04 dalek joined
jnthn And just shaved another 316KB off NQP's base memory for the empty loop program, and anther 1MB for Rakudo, in latest MoarVM commit :) 16:06
m: say 1088 + 1424
camelia rakudo-moar b243a9: OUTPUTĀ«2512ā¤Ā»
timotimo *neat* 16:07
jnthn So, Rakudo got at least 2.5MB lighter today, and these are also wins for each module you load
m: say 18228 / 46116 16:09
camelia rakudo-moar b243a9: OUTPUTĀ«0.395264ā¤Ā»
jnthn We're still a lot heavier than Perl 5 with Moose loaded, alas.
Skarsnik I just tested this gist.github.com/Skarsnik/03b970d2a4b827ba1e1d with today rakduo. It still leak but in different way, like sometime it keep a constant size between 2 iteration 16:10
perlpilot how much heavier? (order of magnitude wise)
jnthn perlpilot: See the calc I just did above 16:11
timotimo Skarsnik: are you running that valgrind piece with --full-cleanup, btw?
jnthn Left is Perl 5 with Moose, right is Rakudo
perlpilot oh
jnthn++
timotimo so less than 3x heavier
Skarsnik Yes the valgrind trace is with full-cleanup
it's weird that it stopped leaking then just some commit later it leaked again 16:12
but I should save the webpage locally, to see the size changes
jnthn Skarsnik: Yeah, that looks from the Valgrind trace like it's not a leak in the sense of "losing memory and not clearning it up" 16:13
But a "something stays referenced and can't be GC'd" one
Skarsnik Today trace is weird pastebin.com/rWCh5Gth 16:15
timotimo could be individual pages in the gen2, perhaps?
Skarsnik I need to restart my bot because of that :( 8032.875000 Mb /opt/bin/moar 16:17
I can run a profile later if you want (I am finishing fixing something else) 16:20
timotimo in general, you can build more robust systems if you make failing a central part of operations 16:23
if "i had to restart the bot because the process that does the xml parsing leaks like stupid" is a problem, i'd say separate the xml parsing from the bot itself
then you can eagerly restart the leaky process without impacting the bot much
Skarsnik Well, I am not sure how to do that without fork 16:24
I tried fork with NC but it make Gumbo (the C lib that parse the html) segfault 16:25
timotimo you don't know how to launch processes from perl6? 16:27
nine Which one will be easier to investigate? "Serialization Error: missing static code ref for closure '<unit>'" or "QAST::Block with cuid cuid_4_1458059076.06615 has not appeared"? 16:29
jnthn o.O 16:30
They're both horrible /o\
Skarsnik timotimo, well it make me write more stuff to share data x)
nine One is the result of re-using a SC for $*W in EVAL and the other from re-using $*W itself
jnthn Re-using $*W probably won't go that well... 16:31
Hm
nine Probably I shouldn't nqp::pushcompsc an SC that has already been pushed... 16:33
jnthn Probably not 16:34
Though I'm not sure that'd lead to the error in question
nine No it doesn't. 16:36
What does that error actually mean?
jnthn The first one is really weird 'cus it suggests we had a closure clone of the mainline (maybe of the EVAL'd code) and tried to serialize it 16:37
m: say 1088 + 1424 + 1036 16:38
camelia rakudo-moar b243a9: OUTPUTĀ«3548ā¤Ā»
jnthn That's today's savings off Rakudo with the latest MoarVM commit :) 16:39
timotimo them's good savings
jnthn Aye 16:42
There'll be more to be had, but that's enough memory reduction work for today ;)
nine Maybe it's looking in the wrong SC for the static code ref 16:57
jnthn RabidGravy: github.com/MoarVM/MoarVM/commit/99bf383cb1 17:01
RabidGravy jnthn++ nice one 17:02
only another 50% to go off that one and we're cooking 17:04
;-)
timotimo can i has that code, RabidGravy?
RabidGravy 'ang on 17:05
jnthn timotimo: gist.github.com/jonathanstowe/5e43...82c2166a52
RabidGravy gist.github.com/jonathanstowe/5e43...82c2166a52
timotimo jnthn was 50% faster :P
RabidGravy possibly not a canonical way of generation but I'm a bear of very little brane 17:06
timotimo we don't optimize that kind of gather/take to a simple list push?
i'd almost say "use lazy loop" instead
and slip the inner values
jnthn You know 17:07
That first sub cna be writtne as
sub gen-sin(Int $sample-rate, Int $frequency) { (0 .. ($samplerate/$frequency)).map({ sin(($_/($samplerate/$frequency)) * (2 * pi))})
}
gah, whitespace fail
But you can just return the list directly there, no? 17:08
timotimo i don't see how that would make it an infinite list?
jnthn oh wait
duh :)
RabidGravy rewrites welcome, it has to generate the CArray in say 256/44100 seconds
jnthn Yeah, and xx * isn't any faster than the gather/take it seems 17:09
m: say 256/44100
camelia rakudo-moar b243a9: OUTPUTĀ«0.005805ā¤Ā»
RabidGravy yeah the reason it does it like that is because the buffer is fixed and not an easy factor of the samples in a full cycle 17:10
timotimo turns out "lazy loop" doesn't lazy in this case 17:15
RabidGravy but yes, one could precompute the wave and keep feeding that. It's more of a proxy for "create some audio sample data" 17:16
timotimo yeah 17:17
i assumed so
would rotor break the lazyness somehow? :\ 17:18
my sub with the "lazy loop" never returns :( 17:20
i thought we totally had that. i wonder what i'm doing wrong
jnthn Did you put the loop in parens, or write lazy on it? 17:21
So about why sink allocates so often: it's a megamorphic issue 17:22
Spesh won't produce so many candidates 17:23
For every type we sink
And we don't spesh/JIT at all in that case
(Long-standing spesh design issue I want to take on)
timotimo i wrote lazy on it 17:24
lazy for * does it, though
er, that doesn't seem to do "forever", though 17:25
i can't seem to get it to lazy at all. 17:26
oh 17:27
m: my $res = do loop { 1 }; say $res[10] 17:28
camelia rakudo-moar b243a9: OUTPUTĀ«1ā¤Ā»
timotimo m: my $res = do lazy loop { 1 }; say $res[10]
camelia rakudo-moar b243a9: OUTPUTĀ«(timeout)Ā»
timotimo ^- do explain this? :P 17:29
so with just "do loop" it works lazily 17:30
what time-number do i have to hit? 0,0058, yeah? 17:31
RabidGravy yeah, I think that's the budget for a buffer that size 17:33
timotimo i'm closing in
about 0.007 here 17:34
RabidGravy (I can cheat with ALSA as you can adjust the buffer size to suit the application,) some more "real-time" audio APIs require a fixed buffer size
and I'm getting bored with typing that in this documentation ;-) 17:35
timotimo have you considered copy&paste? 17:36
RabidGravy it's always a slightly different context
maybe I should work up some "pod entity definition" thing
&<buff-size-spiel> 17:37
timotimo urgh :)
gist.github.com/timo/d97a284b884274e9e375 17:39
of course every time the gc sets in, it gets far worse 17:40
but in between gc runs i get consistently better results than 0.0075
m: say 0.0075 * 100 / 0.005805
camelia rakudo-moar b243a9: OUTPUTĀ«129.198966ā¤Ā»
RabidGravy I'll give it a try in a bit 17:42
timotimo places 3, 4, 5 and 6 in the routines-by-exclusive-time aren't jitted
12.37% of time spent in GC is a lot 17:43
17:43 TimToady joined
timotimo hm. if we had a STORE for CArray, i could have a single CArray kept around that soaks up the values every iteration 17:44
RabidGravy I'm going to look at the CArray constructor when I'm done with this other thing, tests indicate it could be around 4x faster with an array if it just goes straight to the NQP rather than populating "nicely" 17:48
timotimo i have a much faster version that lets the $_ go from 0 to infinity 17:49
that's at 0.002-0.003 s/iteration
but it may not make sense for other instances of "generate some actual sound"
gather/take is actually faster than do loop { slip ... } 17:55
i bet there's a big opportunity for improvement in case we slip something big-ish
BBIAB
jnthn bah, I left rt.perl.org/Ticket/Display.html?id=127700 running under valgrind while I had dinner to see if it'd SEGV. It didn't even finish yet :) 18:58
RabidGravy well, if it doesn't segv it won't finish 19:08
I could make it do it consistently
jnthn oh 19:09
OK, then I'll just leave it
Got it running under gdb too
Guess it'll blow up eventually 19:10
RabidGravy never ran it with valgrind
jnthn Well, if it's a concurrency bug valgrind can end up hiding it 19:11
timotimo i wonder if it's important whether the sleep will be faster or slower than getting the data out 19:23
i.e. will the channel's buffer fill up or not?
jnthn Not sure 19:25
Anyway, can leave it to run for some time :)
19:28 bartolin joined 19:36 dalek joined
nine How on earth can dalek excess flood when it did not say anything? 19:57
19:58 saaki joined
dalek kudo/nom: ec573e1 | (Andy Weidenbaum)++ | src/core/Numeric.pm:
fix Numeric eqv

  irclog.perlgeek.de/perl6/2016-03-15#i_12186016		 19:58
kudo/nom: ba52706 | lizmat++ | src/core/Numeric.pm:
Merge pull request #723 from atweiden/numeric-eqv

fix Numeric eqv
timotimo it is a part of many channels 19:59
that's how :)
20:01 lizmat joined
nine ooh...that also explains why it's so unpredictable when it gets kicked and when not 20:01
Hi lizmat! 20:02
20:03 sortiz joined
lizmat moritz: I wonder how you invited me, because I missed it somehow 20:03
20:04 MadcapJake` joined 20:06 colomon joined
RabidGravy timotimo, that enhanced sine-generator is still not quite fast enough, It runs out of buffer after three iterations 20:09
timotimo i know
RabidGravy but nonetheless still quicker 20:10
timotimo especially the GC stuff
it really kicks the performance down 20:11
lizmat m: use nqp; dd nqp::list.^name, nqp::list_s.^name # is there a better way to differentiate between these two ?
camelia rakudo-moar ba5270: OUTPUTĀ«"BOOTArray"ā¤"BOOTStrArray"ā¤Ā»
RabidGravy once I've got v1 of the module out I'll give some more smacking around
a faster CArray constructor (which I know how to do) and a faster rotor (which I don't) would probably swing it 20:13
timotimo well, we're definitely allocating quite a bit more than we should be :|
RabidGravy if there's headroom it can cope with the GC
lizmat m: use nqp; dd nqp::list.^name, nqp::list_s.^name # jnthn timotimo is there a better way to differentiate between these two ?
camelia rakudo-moar ba5270: OUTPUTĀ«"BOOTArray"ā¤"BOOTStrArray"ā¤Ā»
timotimo lizmat: well, you can compare the WHAT with a single instance of list and list_s 20:14
lizmat m: use nqp: nqp::list_s.WHAT
camelia rakudo-moar ba5270: OUTPUTĀ«===SORRY!=== Error while compiling /tmp/x6kTq61p6Mā¤Confusedā¤at /tmp/x6kTq61p6M:1ā¤------> use nqpā: nqp::list_s.WHATā¤Ā»
lizmat m: use nqp; nqp::list_s.WHAT
camelia ( no output )
lizmat m: use nqp; say nqp::list_s.WHAT
camelia rakudo-moar ba5270: OUTPUTĀ«Cannot find method 'gist': no method cache and no .^find_methodā¤ in block <unit> at /tmp/9JP98Bfd8K line 1ā¤ā¤Ā»
timotimo m: my Mu $slist := nqp::list_s(); say nqp::list_s("a").WHAT =:= $slist.WHAT
camelia rakudo-moar ba5270: OUTPUTĀ«===SORRY!=== Error while compiling /tmp/wXl0O1eJWbā¤Could not find nqp::list_s, did you forget 'use nqp;' ?ā¤at /tmp/wXl0O1eJWb:1ā¤------> my Mu $slist := nqp::list_s()ā; say nqp::list_s("a").WHAT =:= $slist.Wā¤Ā»
timotimo m: use nqp; my Mu $slist := nqp::list_s(); say nqp::list_s("a").WHAT =:= $slist.WHAT
camelia rakudo-moar ba5270: OUTPUTĀ«Trueā¤Ā»
lizmat I think I'll stick to the .^name, because I may not have elements in the list to be compared 20:16
timotimo er, huh?
lizmat ah, ok, gotcha now
timotimo i expect going via .WHAT has very much better performance characteristics
lizmat m: use nqp; dd nqp::list_s.WHAT =:= nqp::list_s.WHAT
camelia rakudo-moar ba5270: OUTPUTĀ«Bool::Trueā¤Ā»
lizmat gotcha :-)
timotimo of course you can put the .WHAT of nqp::list_s into that variable 20:17
moritz lizmat: I invited you with a bog-standard /invite lizmat :-)
timotimo m: use nqp; say BOOTStrArray
camelia rakudo-moar ba5270: OUTPUTĀ«===SORRY!=== Error while compiling /tmp/nukWGC9EACā¤Undeclared name:ā¤ BOOTStrArray used at line 1ā¤ā¤Ā»
timotimo because we don't have that available as a name anywhere it seems
lizmat moritz: I guess my irc client doesn't support that then... 20:18
timotimo you can probably "use" something to get at it, but that could just be overkill
nine moritz: seems like irssi doesn't even highlight the tab where the /invite is posted. I didn't see it either.
moritz nine: my irssi shows it at as a notification in window 1 (where all the server messages also land) 20:25
hoelzro that's what happened for me; window #1 20:27
nine But it doesn't highlight window 1 in any way other than that there are new messages which is not unusual. 20:28
dalek kudo/nom: 93d597f | lizmat++ | src/core/List.pm:
Don't bother creating native str array if possible

The .join method doesn't need to create a native str array if $!reified already is a native str array.		 20:36
lizmat jnthn: I'm considering creating an IterationBufferStr class, which would be the same as IterationBuffer, but with the _s nqp equivalents of push, atpos/ bindpos 20:37
and then, in List!ensure-allocated, if not initialized yet, initialize with IterationBufferStr if self.of ~~ Str 20:38
that should give an immediate benefit on any Str arrays / Lists, specifically wrt to things like join 20:39
timotimo hm, i'm not so sure how much we win from a list_s over a regular list
would we be putting boxed strings into the regular list in that case?
lizmat I think so
timotimo hm, ok
when do we actually end up with a $!reified that is a list_s? 20:40
lizmat timotimo: not many cases yet, it happens when we return a list_s directly from a method, e.g. Parameter.named_names
timotimo ah 20:41
well, the check'll be very cheap once things are speshed
lizmat yes
timotimo actually, i wonder ... i know we optimize "istype", but do we optimize "what"? 20:42
istype is a bit simpler, since it also does subtypes fine 20:45
timotimo not so sure 20:46
we'd have to look at the output of spesh for that in particular
lizmat hmmm.. I guess it makes more sense to implement "my str @a" 20:49
m: my str @a 20:50
camelia rakudo-moar ba5270: OUTPUTĀ«===SORRY!===ā¤native string arrays not yet implemented. Sorry. ā¤Ā»
lizmat isn't this just a list_s underneath ?
timotimo we probably want it to provide more methods, and also be written in perl6 so that it doesn't incur hllize everywhere 20:51
dalek kudo/nom: 7d36a51 | lizmat++ | src/core/native_array.pm:
Fix signatures + 1 error message
 21:12
jnthn lizmat: Hmm...is that something we'd keep internal? 21:15
lizmat: But yeah, I'd rather we implement my str @a
lizmat: It shouldn't be much work
lizmat: Just another case for array.pm to handle
lizmat jnthn: I'm looking at it and it looks like a cat license job ?
jnthn IterationBufferStr sounds odd :) 21:16
lizmat: Yeah, should be little more than that :)
lizmat jnthn: yeah, I realize that now
ah, but could it all be done in P6 ?
jnthn lizmat: my str @arr will be, storage wise, just as efficient as nqp::list_s 21:17
lizmat: And has the same represntation, so join will happily take it
lizmat indeed...
jnthn nqp::join, that is :)
lizmat ok, let me try to make that happen then
nine jnthn: I've made some progress...or at least a difference by binding the EVAL world's $!num_code_refs to the outer world's. 21:18
lizmat and possibly generate the inarray/numarray/strarray roles from a common source
jnthn nine: Hmm. :) And vice versa after the EVAL? 21:19
nine: We may want to steal a few bits of state
lizmat: Arrgh, not code-gen! :P
nine Vice versa? It's bound so, so it's the same variable anyway 21:20
jnthn nine: Ah.. :)
lizmat jnthn: so we rather copy-n-paste ??
jnthn lizmat: When it's only 3 cases, yes
nine jnthn: trouble is that the new behavior is a segfault. But at least it tells me that I'm looking in the right part of the code.
lizmat jnthn: I'm more worried about the maintenance cost of 3 roles being maintained by hand 21:21
if the only difference is int/num/str _i/_n/_s
jnthn lizmat: Which change very rarely...
perlpilot lizmat: whenever we get macros, the maintenance burden will decrease :) 21:22
jnthn RabidGravy: 'fraid that thing didn't explode under valgrind or gdb on my Linux VM after a couple of hours running...
lizmat and which I'm about to optimize, which I'd rather do once than 3 times with all of the possible mixups :-(
jnthn: so you have a problem with src/core/SLICE.pm as well? 21:23
(which is only 2 alternatives)
jnthn lizmat: I put up with it more than I like it :)
RabidGravy jnthn, maybe it got fixed "accidentally" as a result of some other change, I'll upgrade the rakudo and try again, if I can't reproduce with a newer version I'll close 21:24
jnthn RabidGravy: OK...I can quite imagine there is something there...
lizmat: But now it's there I don't think it's worth undoing it or anything 21:25
lizmat jnthn: to be honest, I don't really understand your apprehension 21:26
I think it's one of best examples of DRY
jnthn Aye, and I tend to find our industry over-addicted to DRY :) 21:27
perlpilot is makeSLICE run by hand? Or is there something that notices tools/build/makeSLICE.pl6 is newer than src/core/SLICE.pm and auto-makes it?
s/auto-make/auto-run/
jnthn Anyway, I won't scream if you decide to do some code-gen for array.pm, given you're likely going to do more with it in the near future than I am :)
lizmat perlpilot: makeSLICE is supposed to be run by hand
atm anyway, I guess some makefile magic could be added 21:28
dalek kudo/nom: d56b686 | lizmat++ | src/core/ (2 files):
Move permutations() to operators

It doesn't belong in native_array: it was only there because it needed native arrays, and putting it in the file made sure of that. However, now that I'm focusing on native arrays, it felt better to move this
  "corpus librum" to a better place, later in the CORE setting.		 21:42
nine It really looks like there is a strong expectation of a 1:1:1 relationship of comp_unit, world and sc in the compiler's code. 21:47
jnthn nine: Yeah...well, there always has been to date... 21:50
nine IOW this may take a while after all. 21:51
jnthn nine: Yeah, sounds like it goes a bit deeper than I first thought... :(
nine Could even be that sharing the world may be the better approach after all. But we'll see.
jnthn I wonder if we'll be able to split off the piece to share onto a separate object that $*W in turn references. 21:52
nine Could be. Right now the source of trouble seems to be that after finishing a comp_unit the compiler really wants to serialize the SC which won't work all that well when there's another world still holding on to that. 21:53
22:00 japhb joined
jnthn nine: oh...because it's in pre-comp mode...hmmm 22:05
nine: Maybe we should tell EVAL'd ones that they're actually not in precomp mode...
nine: So they won't try to do that
Sleep time here...'night 22:08
timotimo gnite jnthn 22:20
RabidGravy jnthn, yep the *first* example in #127700 segv'd for me after 311 iterations (and taking the sleep out) 22:22
the second one didn't however so something may have changed
let me run that with valgrind and/or gdb to see where it gets us 22:23
and lawks valgrind is sloooooooow 22:24
timotimo yeah 22:25
RabidGravy but with gdb it segvs quite promptly and it is the same backtrace as before 22:28
timotimo interesting 22:32
RabidGravy actually let me update the other machine and test it there, because it so could be a weird pthread bug or something 22:37
yep it segfaults quicker on the other machine (which may just be "less memory") 22:57
fc23 vs fc22 on the laptop 22:59
so no close ticket 23:00
dalek kudo/nom: 8cbb1ef | lizmat++ | tools/build/makeNATIVE_ARRAY.pl6:
Native array role builder (WIP)
 23:23
lizmat good night, #p6dev :-)
RabidGravy toodles 23:25

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!