[00:05] yay, i have a bit of output [00:05] 5540083 6.7M -rw-r--r--. 1 timo timo 6.7M Mar 17 01:04 heap-1458173085.41926.json [00:06] where did i put the fixed version of json_xs? :\ [00:07] i don't *really* understand what the heap snapshot exactly contains here [00:08] but i'm now getting output, so that's good [00:10] i wonder if i should already turn references into the string heap into strings at json-dump-time [00:13] i kind of fear i b0rked the to-json-ification somehow [00:16] nope, at least the regular timing/allocation profiler is still fine [00:18] i can probably get away with replacing ; and , with the right kind of stuff to get a more structure-y thing [00:23] it's probably enough to change ; into "," and it'll be cooler [00:32] splitting the string by ";" takes a very long time. i'm considering implementing a role that i can plop on the string to tell the json dumper that it's supposed to be included verbatim without escaping in the final json output and just use subst there [00:53] nqp is making my life difficult right nw [00:53] oh! [00:53] i'm being dumb, subst always wants a regex, but i gave it a string instead [00:54] *** colomon joined [01:12] this is *so* slow :| [01:13] *** colomon joined [01:16] i should probably just leave this change out and start work on a front-end [01:21] *** colomon joined [01:35] rakudo/repl6: 37af979 | hoelzro++ | src/core/REPL.pm: [01:35] rakudo/repl6: REPL6: Return full list of completions if given no input [01:35] rakudo/repl6: [01:35] rakudo/repl6: Fixes a slew of warnings, plus saves us a lot of work [01:35] rakudo/repl6: review: https://github.com/rakudo/rakudo/commit/37af979515 [01:36] ohai hoelzro :) [01:37] hi timo! [01:37] still up, are you? [01:37] it's got to be quite late there! [01:37] 0230 [01:37] oh, that's not terrible [01:37] i had kind of a bad day, in the sense that i got out of bed at about 2100 or so [01:38] ah, DST hasn't hit for you yet, has it? [01:38] 2145 actually [01:38] i don't think so [01:38] wow, what happened? not feeling well? [01:38] yeah [01:38] =( [01:38] well, i'm feeling better now :) [01:38] oh, good! [01:39] just now digging into jnthn's heap profiler stuff [01:39] I should probably dive into the heap at sometime as well =) [01:40] hah, what? :) [01:40] heh, bad pun =) [01:40] jnthn's work looks pretty handy [01:40] i feel quite a bit relieved that we have #p6dev now; i can get away with not backlogging all of #perl6 now [01:40] tell me about it! [01:40] i didn't expect i'd feel so good about the split so soon already [01:41] it's surprising [01:41] well, not entirely, I suppose [01:42] it makes me feel a ton better when I push a lot of commits =) [01:42] 'caus now dalek doesn't dump them in #perl6 [01:43] ah [01:43] i didn't feel bad about making dalek output lots of stuff in the past [01:43] i thought everybody appreciates a slew of commit reports by dalek [01:43] y'know [01:43] hoelzro pushed a bunch of commits, and there was much rejoicing [01:44] it's nice to know that people are working, and what they're working on =) [01:44] :) [01:52] the description of the "references" part of the snapshot isn't entirely clear to me :\ [01:59] it only makes sense to me if it only tracks how a thing gets referenced, but not by what [02:00] so my first idea of making one graphviz image that shows all interconnections won't fly, apparently? [02:00] oh! [02:00] every collectable in the "collectables" has a pointer into the "references" list and a "length" [02:25] *** dalek joined [02:29] roast: d386ad8 | skids++ | S0 (2 files): [02:29] roast: Start to rehabilitate Range Iterator test file post-GLR [02:29] roast: [02:29] roast: (It will need some review before being put back in spectest.data) [02:29] roast: Also, add a couple extra immutability tests on Range [02:29] roast: review: https://github.com/perl6/roast/commit/d386ad8c7e [02:29] roast: 4647043 | skids++ | S0 (2 files): [02:29] roast: Merge pull request #109 from skids/master [02:29] roast: [02:29] roast: Start to rehabilitate Range Iterator test file post-GLR [02:29] roast: review: https://github.com/perl6/roast/commit/4647043430 [02:38] okay, i have a little perl6 script that extracts the heap profiler output into a bunch of objects that we can use for introspecting stuff [02:38] i'm not yet hooking up the Reference with its actual target object. i wonder if i should [02:39] hoelzro: are you interested in that? i can upload it along with an example heap [02:40] timotimo: I'm afraid I won't get around to it tonight =/ [02:40] you could already download it and see what it's like, tell me if it's any good or something? :) [02:41] i'll post it in #perl6 [02:42] timotimo: I guess it wouldn't hurt to share the link ;) [02:46] there we go :) [02:46] timotimo++ [03:22] *** sortiz joined [07:44] <[Tux]> test 21.488 [07:44] <[Tux]> test-t 14.080 [07:44] <[Tux]> csv-parser 50.807 [07:48] up and to the right... [07:56] *** nwc10 left [07:58] *** RabidGravy joined [08:33] good *, #p6dev :-) [08:33] \o [08:33] * moritz doesn't need to run around with drawn arms [08:33] looking at [Tux] test-t timings, I cannot help but wonder what I did yesterday that caused the slowdown :-( [08:34] because none of that work had anything todo with CSV afaik [08:34] <[Tux]> 13.8 -> 14.0 isn't that much of a slowdown, is it? [08:34] except maybe make the core bigger ? [08:34] it's a small increment (yet again) [08:35] <[Tux]> http://www.xs4all.nl/~hmbrand/speed.log <= the complete log [08:35] <[Tux]> (used for the graphs) [08:36] * [Tux] => $work - bbl [08:56] how can I find why something is segfaulting in moar/reprs/CStruct.get_int [09:02] I dare say that .2s is within the margin of error, so I wouldn't worry about it that much. I'm more concerned with the 11.828 -> 14.080 slowdown within the last 3 weeks [09:04] 2.2s between March 5th and March 12th [09:06] $ 6 'my str @a = "a","b"; dd @a' [09:06] array[str].new("a", "b") [09:06] wheeee [09:07] only add to add 2 lines to native_array, and adapt the parameterize to allow str [09:07] nice one [09:07] *need [09:07] however, the question is really, can we do this in 6.c? [09:07] should this be 6.c.1 or 6.d ? [09:08] it *is* something new (although it was always planned) [09:14] rakudo/nom: eed4ebb | lizmat++ | src/core/native_array.pm: [09:14] rakudo/nom: Add support for native str arrays [09:14] rakudo/nom: [09:14] rakudo/nom: Turns out it was trivial to add once the role generation code was in [09:14] rakudo/nom: place. [09:14] rakudo/nom: [09:14] rakudo/nom: Please note that this is for review only: one could consider this [09:14] rakudo/nom: having to be part of 6.d, or at least a 6.c.1. [09:14] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/eed4ebb0c0 [09:37] afk for a few hours& [12:22] rakudo/nom: 2a20197 | lizmat++ | src/core/native_array.pm: [12:22] rakudo/nom: Add str|intarray.join, opt intarray.STORE(Range) [12:22] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/2a20197e8f [12:28] .tell jnthn it looks like I can have a "multi foo" in a role in the settings without having to specify a proto (see 2a20197) [12:29] .tell jnthn it works, I'm just surprised that it can and if it points to some kind of bug lurking somewhere [12:29] i think that's a known limitation of the core setting [12:29] oh [12:29] yes, I know you must [12:29] well, it could be that if the role is applied after the core setting is through, it's fine? [12:29] it's just that I forgot, and it didn't complain [12:30] ah, perhaps that's it... I thought I'd mention it just in case :-) [12:30] how big is the optimization in the intarray.STORE(Range) case? [12:30] i'm so used to your commit messages having those numbers in them [12:31] the intarray.STORE case was about 30% [12:31] the strarray.join was about 10x faster, the intarray.join about 5x faster [12:32] awesome :) [12:33] rakudo/nom: 2627232 | lizmat++ | src/core/native_array.pm: [12:33] rakudo/nom: Apparently we don't need no multi's here [12:33] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/2627232853 [12:34] m: say Buf.new(1,2,3).WHICH [12:34] rakudo-moar 2a2019: OUTPUT«Buf|57312608␤» [12:34] m: say Blob.new(1,2,3).WHICH [12:34] rakudo-moar 2a2019: OUTPUT«Blob|58573488␤» [12:34] ah, blobs could become value types, eh? [12:35] feels to me since Blob's are immutable, it should be a value type, indeed :-) [12:44] o/ #p6dev [12:44] timotimo: have you thought about making that code you wrote last night into a proper module? [12:45] yeah [12:46] i'm also thinking to make it not json [12:46] because it's really not structured at all [12:46] if it was just lines with a keyword in front, that'd be a lot faster to parse, and would easily allow "parallelization" [13:02] timotimo: Blob is a role, and mutable objects to the Blob role [13:02] and blob happens to pun into a class as well [13:02] oh [13:03] well, we can surely detect self.WHAT eqv Blob, no? [13:03] well, i suppose Blob.^make_pun? or Blob.^pun? which one is the one i mean? [13:04] or we could give Blob a WHICH method, and then override it again in Buf [13:04] which sounds cleaner than messing with make_pun [13:14] hoelzro: the module might land in moarvm/tools or so [13:15] moritz timotimo: that was the line of thought I was going for [13:16] rakudo/nom: 2494cba | lizmat++ | src/core/Buf.pm: [13:16] rakudo/nom: Make Blob.join|perl 2x as fast [13:16] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/2494cba606 [13:20] jnthn: do you think a SHA1 of a Blob would be sufficiently unique for a .WHICH ? [13:23] Hm, is Blob listed as a value type? :) [13:23] It's a...bit risky :) [13:23] jnthn: well, it *is* supposed to be immutable ? [13:23] Buf.WHICH would not change [13:23] from the current behaviour [13:23] m: Buf.new(1,2,3).WHICH.say [13:23] rakudo-moar 262723: OUTPUT«Buf|54105792␤» [13:24] lizmat: We'll break things for anyone who was putting blobs in object hashes if we change it...though that may be "not man" [13:24] lizmat: I more meant does S02 list it as a value type though [13:24] ah, lemme check [13:25] it would break things? i think i'm confused [13:26] timotimo: If you put them in relying on reference identity, then suddenly those that had value identity started being the same key... [13:26] ah [13:26] indeed [13:26] so a 6.d thing potentially [13:27] with the upgrade path of using Buf where Blob was currently used for that [13:27] jnthn: Blob is not listed as a mutable [13:28] well, not mutable has got to be the case, but does it mention "value type" anywhere? [13:28] that'd be what tips the user off to reference vs value identity, as jnthn just explained to me [13:28] Blob is in the list after S02:1415 [13:28] "Objects with these types behave like values" [13:29] ah! fantastic [13:29] perlpilot++ [13:29] so giving Blob the WHICH would be a fix, not a change :) [13:29] eh, yeah, that was my thought :-) [13:29] OK, then +1 [13:30] I was pretty sure S02 made a call on it :) [13:30] And I mostly prefer to delegate to TimToady's thinking there rather than doing my own ;) [13:33] *** synopsebot6 joined [13:34] S02:1415 [13:34] Link: http://design.perl6.org/S02.html#line_1415 [13:34] that list also has Enum, EnumMap, and LoL [13:34] that may want to be updated ... at some point [13:35] lol... [13:35] Yeah [13:35] There is no LoL [13:36] yeah, no project euler, either [13:36] :D [13:55] rakudo/nom: 5958903 | lizmat++ | src/core/Buf.pm: [13:55] rakudo/nom: Give Blob a .WHICH fitting for a value type [13:55] rakudo/nom: [13:55] rakudo/nom: While Buf.WHICH remains the same, since that is a mutable type. [13:55] rakudo/nom: [13:55] rakudo/nom: Please note that it was not an option to have a .WHICH attribute [13:55] rakudo/nom: frozen in a $!which, as array type REPR's don't allow attributes. [13:55] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/5958903edb [13:55] $ 6 'Blob.new(1,2,3,4).WHICH.say' [13:55] Blob|4697A8195A0E8EF4E1EE3119268337C8E0AFABFC [13:55] $ 6 'Buf.new(1,2,3,4).WHICH.say' [13:55] Buf|140461630105216 [13:56] we could probably implement a version of nqp::sha1 that operates on lists of integers [13:56] so there'd not be a need for a join there [13:57] timotimo: that would be excellent [13:57] timotimo was reading my mind [13:57] at least the Blob.join got 2x faster recently :-) [13:58] it'd have to be clever in order to be easily equal-able [13:58] it's possible that we wouldn't actually gain very much over what self.join already does [13:59] sometimes however, I think we need to get rid of .WHICH as a string [13:59] but instead have something like .ACCEPTS (.EQUIV ?) that would allow being smarter about equivalence checking [13:59] ObjAt needs to become something smarter, I guess [13:59] timotimo: shouldn't blobs be well blobs of memory, IOW perfectly useable as input for SHA1 already? [13:59] It being a string is very much a stop-gab [14:00] *gap [14:00] nine: yeah, it'd be possible to run it directly on the blob [14:00] we don't have to support WHICH being equal across runs of perl6, right? [14:00] m: use nqp; nqp::shaq(nqp::list_s("a","b")) [14:00] rakudo-moar 2494cb: OUTPUT«===SORRY!===␤No registered operation handler for 'shaq'␤» [14:00] so changing the implementation shouldn't be a problem [14:00] m: use nqp; nqp::sha1(nqp::list_s("a","b")) [14:00] rakudo-moar 2494cb: OUTPUT«This representation (VMArray) cannot unbox to a native string␤ in block at /tmp/doUB7udTRH line 1␤␤» [14:01] timotimo: no, only during the run [14:01] and possibly only also in a given process [14:02] m: use nqp; nqp::sha1(nqp::list_i(1, 2, 3, 4)) [14:02] rakudo-moar 2494cb: OUTPUT«This representation (VMArray) cannot unbox to a native string␤ in block at /tmp/LJrvh7ASwQ line 1␤␤» [14:02] fair enough; it could just grow a little if-else for a VMArray that doesn't try to unbox_s [14:05] commute to NRP meeting& [14:07] *** RabidGravy joined [14:13] i'm in dire need of a nap [14:35] SIGNAP [14:46] Is this sort of thing known to fail ? https://gist.github.com/jonathanstowe/4b7d8b4dee4b374366e2 [14:47] it segfaults in get_int when printing the struct [14:48] however if I change the native sub to take a CArray[int64] instead it gives the "correct" result [14:58] the case of "populating an array of structs allocated by the caller" isn't tested for in the NC tests [14:59] timotimo: make sense [15:19] slightly warnocked on the above ^ I'll RT it as a bug with the backtrace because it's blocking me at the moment [15:44] https://rt.perl.org/Ticket/Display.html?id=127730 if anyone is bored [16:27] nqp: 556af98 | (Pawel Murias)++ | src/vm/js/ (5 files): [16:27] nqp: [js] Support compiling and running the stuff inside a role Foo {...} during compile time. [16:27] nqp: [16:27] nqp: Implement nqp::iscompunit, nqp::compunitmainline, nqp::compunitcodes ops needed for that. [16:27] nqp: review: https://github.com/perl6/nqp/commit/556af98ad0 [16:46] <[Coke]> (things for review should probably not go in nom, but in a branch) [18:02] RabidGravy, Can I PM? [18:03] er [18:03] sure [18:03] sortiz is prime minister? [18:15] jnthn: are we supposed to throw exceptions via "await" from broken promises that show the original location the exception was thrown at? like a failure would, for example? [18:15] because i have a situation locally where i get the location of the await, but no further information about the problem source [19:06] *** lizmat joined [19:13] *** lucs joined [19:17] *** FROGGS joined [19:24] timotimo: We want the original location really [19:24] did that work at some point? i seem to recall it did [19:24] Maybe :) [19:55] <[Coke]> "tests or it didn't happen" [20:06] *** b2gills joined [20:19] *** lizmat joined [20:22] Oh compilation_mode == is_precompilation_mode. I missed that connection. [20:44] Is there a way to bind an int attribute to another object's int attribute? [20:45] [Coke]: I want that on a sign outside my office. :-) [20:46] "int" attributes are just a tiny slot inside the object, where the int value lives [20:46] there isn't an indirection there [20:46] <[Coke]> japhb: :) [20:47] nine: I really think we'd be better of pulling out the stuff to share between the worlds into a separate object, rather than binding things... There's not a way to do it in NQP with binding [20:49] Yep. At least I now know that the binding was causing the segfault. [20:50] And I'm understanding a lot more about the code structure now. [20:50] :) [20:50] nine++ # digging into perhaps the scariest bit of the Rakudo codebase [21:14] *** psch joined [22:09] Can someone look into PR#686 which fixes `permuations(1)` and `permutations(0).elems == 1` jnthn has already stated that it shouldn't conflict with v6.c. There is also an associated ROAST PR to test it.