Perl 6 - the future is here, just unevenly distributed

IRC log for #p6dev, 2016-03-15

| Channels | #p6dev index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
13:29 ilbot3 joined #p6dev
13:29 Topic for #p6dev is now Perl 6 language and compiler development
13:29 moritz aye
13:30 moritz done
13:30 moritz also timotimo
13:31 timotimo joined #p6dev
13:31 timotimo o/
13:31 moritz oh hai
13:31 moritz I've invited all Rakudo contributors from this month
13:31 timotimo has the time come where signal-to-noise in #perl6 has become too bad?
13:32 moritz dev signal, at least
13:32 moritz user signal is still pretty high
13:33 timotimo ah, yes
13:33 jnthn Yeah...I gave up backlogging #perl6, but suspect I'm missing stuff.
13:34 moritz I've reconfigured rakudo and nqp to report their commits here, not in #perl6 anymore
13:34 moritz guess I should do the same in roast
13:34 timotimo hmm. roast may want more feedback from users compared to rakudo and nqp perhaps?
13:34 perlpilot moritz++
13:34 moritz timotimo: don't think so
13:35 masak moritz++
13:36 camelia joined #p6dev
13:36 timotimo OK
13:36 perlpilot m: say "yay!"
13:36 timotimo carry on :)
13:36 perlpilot hmm
13:37 moritz the first answer after a fresh restart always needs ages
13:37 moritz due to Bot::BasicBot's rate limiting
13:37 camelia rakudo-moar b243a9: OUTPUT«yay!␤»
13:42 RabidGravy joined #p6dev
13:42 RabidGravy erp
13:44 moritz Gesundheit
13:44 Woodi joined #p6dev
13:48 llfourn joined #p6dev
13:57 Skarsnik joined #p6dev
14:39 YvargDibar joined #p6dev
14:43 SauceRageuse joined #p6dev
14:53 hoelzro joined #p6dev
14:53 hoelzro o/ #p6dev
14:54 jnthn o/ hoelzro
15:06 RabidGravy joined #p6dev
15:19 jnthn So, time for some Perl 6 hackin'
15:22 RabidGravy eeeek!
15:22 timotimo poor mister gravy
15:27 jnthn So I'm looking at these compilation unit unique IDs we have
15:28 jnthn And realizing we use them for rather little down inside the VM
15:30 jnthn But also that we should be able to get away with making them way shorter
15:30 timotimo +1 on making them shorter :)
15:33 * jnthn makes them just a stringified integer
15:34 jnthn 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"?
15:35 jnthn yeah
15:35 jnthn I think we might actually try and make them real integers in the future but it's...fiddly
15:35 jnthn (Bytecode back-compat)
15:36 timotimo right
15:36 timotimo we'll have a pretty significant saving none-the-less
15:36 timotimo what were cuuids before? like 32 characters?
15:37 jnthn cuid_NNN_timestamp before
15:37 jnthn now just NNN
15:37 nine joined #p6dev
15:37 jnthn Yeah, in Rakudo it saves 1.4MB off the empty loop program
15:37 nine So this is like the core developers channel?
15:38 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
15:38 timotimo oh, wow.
15:41 timotimo jnthn: have you considered that for immutable strings (like the new cuuids), we can just use the fixed size allocator + strlen?
15:42 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 jnthn Not make an MVMString out of them at all
15:42 jnthn Damn, forgot to measure Rakudo's CORE.setting before the chance
15:42 jnthn *change
15:43 jnthn If anybody does get a number before/after feel free to pass it along, and it'll make it into the weekly report :)
15:44 timotimo i can do that
15:44 timotimo waiting for you to push the patch now
15:46 jnthn I did?
15:46 jnthn Where's dalek? :)
15:47 timotimo ah, there it is
15:47 timotimo (the patch)
15:47 timotimo i pulled rakudo and moar, but not nqp :D
15:47 jnthn ah, it was an NQP match
15:47 jnthn *patch
15:47 [Coke] joined #p6dev
15:48 timotimo yeah, that's what i saw :)
15:50 timotimo m: say 100 * 11246944 / 11531000
15:50 camelia rakudo-moar b243a9: OUTPUT«97.536588␤»
15:50 timotimo m: say (11246944 R- 11531000) / 1024
15:50 camelia rakudo-moar b243a9: OUTPUT«277.398438␤»
15:50 timotimo not too shabby
15:55 timotimo even with the shorter cuuids, regenerating the stage0 files now still makes them a little bit bigger
16:04 dalek joined #p6dev
16:06 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 jnthn m: say 1088 + 1424
16:06 camelia rakudo-moar b243a9: OUTPUT«2512␤»
16:07 timotimo *neat*
16:07 jnthn So, Rakudo got at least 2.5MB lighter today, and these are also wins for each module you load
16:09 jnthn m: say 18228 / 46116
16:09 camelia rakudo-moar b243a9: OUTPUT«0.395264␤»
16:09 jnthn We're still a lot heavier than Perl 5 with Moose loaded, alas.
16:10 Skarsnik I just tested this https://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)
16:11 jnthn perlpilot: See the calc I just did above
16:11 timotimo Skarsnik: are you running that valgrind piece with --full-cleanup, btw?
16:11 jnthn Left is Perl 5 with Moose, right is Rakudo
16:11 perlpilot oh
16:11 perlpilot jnthn++
16:11 timotimo so less than 3x heavier
16:11 Skarsnik Yes the valgrind trace is with full-cleanup
16:12 Skarsnik it's weird that it stopped leaking then just some commit later it leaked again
16:12 Skarsnik but I should save the webpage locally, to see the size changes
16:13 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 jnthn But a "something stays referenced and can't be GC'd" one
16:15 Skarsnik Today trace is weird http://pastebin.com/rWCh5Gth
16:15 timotimo could be individual pages in the gen2, perhaps?
16:17 Skarsnik I need to restart my bot because of that :( 8032.875000 Mb /opt/bin/moar
16:20 Skarsnik I can run a profile later if you want (I am finishing fixing something else)
16:23 timotimo in general, you can build more robust systems if you make failing a central part of operations
16:23 timotimo 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
16:23 timotimo then you can eagerly restart the leaky process without impacting the bot much
16:24 Skarsnik Well, I am not sure how to do that without fork
16:25 Skarsnik I tried fork with NC but it make Gumbo (the C lib that parse the html) segfault
16:27 timotimo you don't know how to launch processes from perl6?
16:29 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:30 jnthn o.O
16:30 jnthn They're both horrible /o\
16:30 Skarsnik timotimo, well it make me write more stuff to share data x)
16:30 nine One is the result of re-using a SC for $*W in EVAL and the other from re-using $*W itself
16:31 jnthn Re-using $*W probably won't go that well...
16:31 jnthn Hm
16:33 nine Probably I shouldn't nqp::pushcompsc an SC that has already been pushed...
16:34 jnthn Probably not
16:34 jnthn Though I'm not sure that'd lead to the error in question
16:36 nine No it doesn't.
16:36 nine What does that error actually mean?
16:37 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:38 jnthn m: say 1088 + 1424 + 1036
16:38 camelia rakudo-moar b243a9: OUTPUT«3548␤»
16:39 jnthn That's today's savings off Rakudo with the latest MoarVM commit :)
16:39 timotimo them's good savings
16:42 jnthn Aye
16:42 jnthn There'll be more to be had, but that's enough memory reduction work for today ;)
16:57 nine Maybe it's looking in the wrong SC for the static code ref
17:01 jnthn RabidGravy: https://github.com/MoarVM/MoarVM/commit/99bf383cb1
17:02 RabidGravy jnthn++ nice one
17:04 RabidGravy only another 50% to go off that one and we're cooking
17:04 RabidGravy ;-)
17:04 timotimo can i has that code, RabidGravy?
17:05 RabidGravy 'ang on
17:05 jnthn timotimo: https://gist.github.com/jonathanstowe/5e430da80882c2166a52
17:05 RabidGravy https://gist.github.com/jonathanstowe/5e430da80882c2166a52
17:05 timotimo jnthn was 50% faster :P
17:06 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?
17:06 timotimo i'd almost say "use lazy loop" instead
17:06 timotimo and slip the inner values
17:07 jnthn You know
17:07 jnthn That first sub cna be writtne as
17:07 jnthn sub gen-sin(Int $sample-rate, Int $frequency) { (0 .. ($samplerate/$frequency)).map({ sin(($_/($samplerate/$frequency)) * (2 * pi))})
17:07 jnthn }
17:07 jnthn gah, whitespace fail
17:08 jnthn 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?
17:08 jnthn oh wait
17:08 jnthn duh :)
17:08 RabidGravy rewrites welcome, it has to generate the CArray in say 256/44100 seconds
17:09 jnthn Yeah, and xx * isn't any faster than the gather/take it seems
17:09 jnthn m: say 256/44100
17:09 camelia rakudo-moar b243a9: OUTPUT«0.005805␤»
17:10 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:15 timotimo turns out "lazy loop" doesn't lazy in this case
17:16 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:17 timotimo yeah
17:17 timotimo i assumed so
17:18 timotimo would rotor break the lazyness somehow? :\
17:20 timotimo my sub with the "lazy loop" never returns :(
17:20 timotimo i thought we totally had that. i wonder what i'm doing wrong
17:21 jnthn Did you put the loop in parens, or write lazy on it?
17:22 jnthn So about why sink allocates so often: it's a megamorphic issue
17:23 jnthn Spesh won't produce so many candidates
17:23 jnthn For every type we sink
17:23 jnthn And we don't spesh/JIT at all in that case
17:23 jnthn (Long-standing spesh design issue I want to take on)
17:24 timotimo i wrote lazy on it
17:24 timotimo lazy for * does it, though
17:25 timotimo er, that doesn't seem to do "forever", though
17:26 timotimo i can't seem to get it to lazy at all.
17:27 timotimo oh
17:28 timotimo m: my $res = do loop { 1 }; say $res[10]
17:28 camelia rakudo-moar b243a9: OUTPUT«1␤»
17:28 timotimo m: my $res = do lazy loop { 1 }; say $res[10]
17:28 camelia rakudo-moar b243a9: OUTPUT«(timeout)»
17:29 timotimo ^- do explain this? :P
17:30 timotimo so with just "do loop" it works lazily
17:31 timotimo what time-number do i have to hit? 0,0058, yeah?
17:33 RabidGravy yeah, I think that's the budget for a buffer that size
17:33 timotimo i'm closing in
17:34 timotimo 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
17:35 RabidGravy and I'm getting bored with typing that in this documentation ;-)
17:36 timotimo have you considered copy&paste?
17:36 RabidGravy it's always a slightly different context
17:36 RabidGravy maybe I should work up some "pod entity definition" thing
17:37 RabidGravy &<buff-size-spiel>
17:37 timotimo urgh :)
17:39 timotimo https://gist.github.com/timo/d97a284b884274e9e375
17:40 timotimo of course every time the gc sets in, it gets far worse
17:40 timotimo but in between gc runs i get consistently better results than 0.0075
17:40 timotimo m: say 0.0075 * 100 / 0.005805
17:40 camelia rakudo-moar b243a9: OUTPUT«129.198966␤»
17:42 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
17:43 timotimo 12.37% of time spent in GC is a lot
17:43 TimToady joined #p6dev
17:44 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:48 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:49 timotimo i have a much faster version that lets the $_ go from 0 to infinity
17:49 timotimo that's at 0.002-0.003 s/iteration
17:49 timotimo but it may not make sense for other instances of "generate some actual sound"
17:55 timotimo gather/take is actually faster than do loop { slip ... }
17:55 timotimo i bet there's a big opportunity for improvement in case we slip something big-ish
17:55 timotimo BBIAB
18:58 jnthn bah, I left https://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 :)
19:08 RabidGravy well, if it doesn't segv it won't finish
19:08 RabidGravy I could make it do it consistently
19:09 jnthn oh
19:09 jnthn OK, then I'll just leave it
19:09 jnthn Got it running under gdb too
19:10 jnthn Guess it'll blow up eventually
19:10 RabidGravy never ran it with valgrind
19:11 jnthn Well, if it's a concurrency bug valgrind can end up hiding it
19:23 timotimo i wonder if it's important whether the sleep will be faster or slower than getting the data out
19:23 timotimo i.e. will the channel's buffer fill up or not?
19:25 jnthn Not sure
19:25 jnthn Anyway, can leave it to run for some time :)
19:28 bartolin joined #p6dev
19:36 dalek joined #p6dev
19:57 nine How on earth can dalek excess flood when it did not say anything?
19:58 saaki joined #p6dev
19:58 dalek rakudo/nom: ec573e1 | (Andy Weidenbaum)++ | src/core/Numeric.pm:
19:58 dalek rakudo/nom: fix Numeric eqv
19:58 dalek rakudo/nom:
19:58 dalek rakudo/nom: http://irclog.perlgeek.de/perl6/2016-03-15#i_12186016
19:58 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/ec573e1d47
19:58 dalek rakudo/nom: ba52706 | lizmat++ | src/core/Numeric.pm:
19:58 dalek rakudo/nom: Merge pull request #723 from atweiden/numeric-eqv
19:58 dalek rakudo/nom:
19:58 dalek rakudo/nom: fix Numeric eqv
19:58 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/ba52706ba4
19:59 timotimo it is a part of many channels
19:59 timotimo that's how :)
20:01 lizmat joined #p6dev
20:01 nine ooh...that also explains why it's so unpredictable when it gets kicked and when not
20:02 nine Hi lizmat!
20:03 sortiz joined #p6dev
20:03 lizmat moritz: I wonder how you invited me, because I missed it somehow
20:04 MadcapJake` joined #p6dev
20:06 colomon joined #p6dev
20:09 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
20:10 RabidGravy but nonetheless still quicker
20:10 timotimo especially the GC stuff
20:11 timotimo 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 ?
20:11 camelia rakudo-moar ba5270: OUTPUT«"BOOTArray"␤"BOOTStrArray"␤»
20:11 RabidGravy once I've got v1 of the module out I'll give some more smacking around
20:13 RabidGravy 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 :|
20:13 RabidGravy if there's headroom it can cope with the GC
20:13 lizmat m: use nqp; dd nqp::list.^name, nqp::list_s.^name   # jnthn timotimo is there a better way to differentiate between these two ?
20:13 camelia rakudo-moar ba5270: OUTPUT«"BOOTArray"␤"BOOTStrArray"␤»
20:14 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
20:14 camelia rakudo-moar ba5270: OUTPUT«===SORRY!=== Error while compiling /tmp/x6kTq61p6M␤Confused␤at /tmp/x6kTq61p6M:1␤------> use nqp⏏: nqp::list_s.WHAT␤»
20:14 lizmat m: use nqp; nqp::list_s.WHAT
20:14 camelia rakudo-moar ba5270: ( no output )
20:14 lizmat m: use nqp; say nqp::list_s.WHAT
20:14 camelia rakudo-moar ba5270: OUTPUT«Cannot find method 'gist': no method cache and no .^find_method␤  in block <unit> at /tmp/9JP98Bfd8K line 1␤␤»
20:14 timotimo m: my Mu $slist := nqp::list_s(); say nqp::list_s("a").WHAT =:= $slist.WHAT
20:14 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␤»
20:14 timotimo m: use nqp; my Mu $slist := nqp::list_s(); say nqp::list_s("a").WHAT =:= $slist.WHAT
20:14 camelia rakudo-moar ba5270: OUTPUT«True␤»
20:16 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?
20:16 lizmat ah, ok, gotcha now
20:16 timotimo i expect going via .WHAT has very much better performance characteristics
20:16 lizmat m: use nqp; dd nqp::list_s.WHAT =:= nqp::list_s.WHAT
20:16 camelia rakudo-moar ba5270: OUTPUT«Bool::True␤»
20:16 lizmat gotcha  :-)
20:17 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 :-)
20:17 timotimo m: use nqp; say BOOTStrArray
20:17 camelia rakudo-moar ba5270: OUTPUT«===SORRY!=== Error while compiling /tmp/nukWGC9EAC␤Undeclared name:␤    BOOTStrArray used at line 1␤␤»
20:17 timotimo because we don't have that available as a name anywhere it seems
20:18 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
20:18 nine moritz: seems like irssi doesn't even highlight the tab where the /invite is posted. I didn't see it either.
20:25 moritz nine: my irssi shows it at as a notification in window 1 (where all the server messages also land)
20:27 hoelzro that's what happened for me; window #1
20:28 nine But it doesn't highlight window 1 in any way other than that there are new messages which is not unusual.
20:36 dalek rakudo/nom: 93d597f | lizmat++ | src/core/List.pm:
20:36 dalek rakudo/nom: Don't bother creating native str array if possible
20:36 dalek rakudo/nom:
20:36 dalek rakudo/nom: The .join method doesn't need to create a native str array if $!reified
20:36 dalek rakudo/nom: already is a native str array.
20:36 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/93d597f407
20:37 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:38 lizmat and then, in List!ensure-allocated, if not initialized yet, initialize with IterationBufferStr if self.of ~~ Str
20:39 lizmat 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
20:39 timotimo would we be putting boxed strings into the regular list in that case?
20:39 lizmat I think so
20:39 timotimo hm, ok
20:40 timotimo 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
20:41 timotimo ah
20:41 timotimo well, the check'll be very cheap once things are speshed
20:41 lizmat yes
20:42 timotimo actually, i wonder ... i know we optimize "istype", but do we optimize "what"?
20:45 timotimo istype is a bit simpler, since it also does subtypes fine
20:46 * timotimo not so sure
20:46 timotimo we'd have to look at the output of spesh for that in particular
20:49 lizmat hmmm.. I guess it makes more sense to implement "my str @a"
20:50 lizmat m: my str @a
20:50 camelia rakudo-moar ba5270: OUTPUT«===SORRY!===␤native string arrays not yet implemented. Sorry. ␤»
20:50 lizmat isn't this just a list_s underneath ?
20:51 timotimo we probably want it to provide more methods, and also be written in perl6 so that it doesn't incur hllize everywhere
21:12 dalek rakudo/nom: 7d36a51 | lizmat++ | src/core/native_array.pm:
21:12 dalek rakudo/nom: Fix signatures + 1 error message
21:12 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/7d36a51a40
21:15 jnthn lizmat: Hmm...is that something we'd keep internal?
21:15 jnthn lizmat: But yeah, I'd rather we implement my str @a
21:15 jnthn lizmat: It shouldn't be much work
21:15 jnthn lizmat: Just another case for array.pm to handle
21:15 lizmat jnthn: I'm looking at it and it looks like a cat license job ?
21:16 jnthn IterationBufferStr sounds odd :)
21:16 jnthn lizmat: Yeah, should be little more than that :)
21:16 lizmat jnthn: yeah, I realize that now
21:16 lizmat ah, but could it all be done in P6 ?
21:17 jnthn lizmat: my str @arr will be, storage wise, just as efficient as nqp::list_s
21:17 jnthn lizmat: And has the same represntation, so join will happily take it
21:17 lizmat indeed...
21:17 jnthn nqp::join, that is :)
21:17 lizmat ok, let me try to make that happen then
21:18 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
21:19 jnthn nine: Hmm. :) And vice versa after the EVAL?
21:19 jnthn nine: We may want to steal a few bits of state
21:19 jnthn lizmat: Arrgh, not code-gen! :P
21:20 nine Vice versa? It's bound so, so it's the same variable anyway
21:20 jnthn nine: Ah.. :)
21:20 lizmat jnthn: so we rather copy-n-paste ??
21:20 jnthn lizmat: When it's only 3 cases, yes
21:20 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.
21:21 lizmat jnthn: I'm more worried about the maintenance cost of 3 roles being maintained by hand
21:21 lizmat if the only difference is int/num/str _i/_n/_s
21:21 jnthn lizmat: Which change very rarely...
21:22 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...
21:22 lizmat and which I'm about to optimize, which I'd rather do once than 3 times with all of the possible mixups :-(
21:23 lizmat jnthn: so you have a problem with src/core/SLICE.pm as well?
21:23 lizmat (which is only 2 alternatives)
21:23 jnthn lizmat: I put up with it more than I like it :)
21:24 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...
21:25 jnthn lizmat: But now it's there I don't think it's worth undoing it or anything
21:26 lizmat jnthn: to be honest, I don't really understand your apprehension
21:26 lizmat I think it's one of best examples of DRY
21:27 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?
21:27 perlpilot s/auto-make/auto-run/
21:27 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 :)
21:27 lizmat perlpilot: makeSLICE is supposed to be run by hand
21:28 lizmat atm anyway, I guess some makefile magic could be added
21:42 dalek rakudo/nom: d56b686 | lizmat++ | src/core/ (2 files):
21:42 dalek rakudo/nom: Move permutations() to operators
21:42 dalek rakudo/nom:
21:42 dalek rakudo/nom: It doesn't belong in native_array: it was only there because it needed
21:42 dalek rakudo/nom: native arrays, and putting it in the file made sure of that.  However,
21:42 dalek rakudo/nom: now that I'm focusing on native arrays, it felt better to move this
21:42 dalek rakudo/nom: "corpus librum" to a better place, later in the CORE setting.
21:42 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/d56b686b06
21:47 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:50 jnthn nine: Yeah...well, there always has been to date...
21:51 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... :(
21:51 nine Could even be that sharing the world may be the better approach after all. But we'll see.
21:52 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:53 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.
22:00 japhb joined #p6dev
22:05 jnthn nine: oh...because it's in pre-comp mode...hmmm
22:05 jnthn nine: Maybe we should tell EVAL'd ones that they're actually not in precomp mode...
22:05 jnthn nine: So they won't try to do that
22:08 jnthn Sleep time here...'night
22:20 timotimo gnite jnthn
22:22 RabidGravy jnthn, yep the *first* example in #127700 segv'd for me after 311 iterations (and taking the sleep out)
22:22 RabidGravy the second one didn't however so something may have changed
22:23 RabidGravy let me run that with valgrind and/or gdb to see where it gets us
22:24 RabidGravy and lawks valgrind is sloooooooow
22:25 timotimo yeah
22:28 RabidGravy but with gdb it segvs quite promptly and it is the same backtrace as before
22:32 timotimo interesting
22:37 RabidGravy actually let me update the other machine and test it there, because it so could be a weird pthread bug or something
22:57 RabidGravy yep it segfaults quicker on the other machine (which may just be "less memory")
22:59 RabidGravy fc23 vs fc22 on the laptop
23:00 RabidGravy so no close ticket
23:23 dalek rakudo/nom: 8cbb1ef | lizmat++ | tools/build/makeNATIVE_ARRAY.pl6:
23:23 dalek rakudo/nom: Native array role builder (WIP)
23:23 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/8cbb1efd1d
23:23 lizmat good night, #p6dev  :-)
23:25 RabidGravy toodles

| Channels | #p6dev index | Today | | Search | Google Search | Plain-Text | summary