Perl 6 - the future is here, just unevenly distributed

IRC log for #p6dev, 2016-03-17

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

All times shown according to UTC.

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

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