timotimo 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
where did i put the fixed version of json_xs? :\ 00:06
i don't *really* understand what the heap snapshot exactly contains here 00:07
but i'm now getting output, so that's good 00:08
i wonder if i should already turn references into the string heap into strings at json-dump-time 00:10
i kind of fear i b0rked the to-json-ification somehow 00:13
nope, at least the regular timing/allocation profiler is still fine 00:16
i can probably get away with replacing ; and , with the right kind of stuff to get a more structure-y thing 00:18
it's probably enough to change ; into "," and it'll be cooler 00:23
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:32
nqp is making my life difficult right nw 00:53
oh!
i'm being dumb, subst always wants a regex, but i gave it a string instead
00:54 colomon joined
timotimo this is *so* slow :| 01:12
01:13 colomon joined
timotimo i should probably just leave this change out and start work on a front-end 01:16
01:21 colomon joined
dalek kudo/repl6: 37af979 | hoelzro++ | src/core/REPL.pm:
REPL6: Return full list of completions if given no input

Fixes a slew of warnings, plus saves us a lot of work		 01:35
timotimo ohai hoelzro :) 01:36
hoelzro hi timo! 01:37
still up, are you?
it's got to be quite late there!
timotimo 0230
hoelzro oh, that's not terrible
timotimo i had kind of a bad day, in the sense that i got out of bed at about 2100 or so
hoelzro ah, DST hasn't hit for you yet, has it? 01:38
timotimo 2145 actually
i don't think so
hoelzro wow, what happened? not feeling well?
timotimo yeah
hoelzro =(
timotimo well, i'm feeling better now :)
hoelzro oh, good!
timotimo just now digging into jnthn's heap profiler stuff 01:39
hoelzro I should probably dive into the heap at sometime as well =)
timotimo hah, what? :) 01:40
hoelzro heh, bad pun =)
jnthn's work looks pretty handy
timotimo i feel quite a bit relieved that we have #p6dev now; i can get away with not backlogging all of #perl6 now
hoelzro tell me about it!
timotimo i didn't expect i'd feel so good about the split so soon already
hoelzro it's surprising 01:41
well, not entirely, I suppose
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
timotimo ah 01:43
i didn't feel bad about making dalek output lots of stuff in the past
i thought everybody appreciates a slew of commit reports by dalek
y'know
hoelzro pushed a bunch of commits, and there was much rejoicing
hoelzro it's nice to know that people are working, and what they're working on =) 01:44
timotimo :)
the description of the "references" part of the snapshot isn't entirely clear to me :\ 01:52
it only makes sense to me if it only tracks how a thing gets referenced, but not by what 01:59
so my first idea of making one graphviz image that shows all interconnections won't fly, apparently? 02:00
oh!
every collectable in the "collectables" has a pointer into the "references" list and a "length"
02:25 dalek joined
dalek ast: d386ad8 | skids++ | S0 (2 files):
Start to rehabilitate Range Iterator test file post-GLR

   (It will need some review before being put back in spectest.data)
   Also, add a couple extra immutability tests on Range		 02:29
ast: 4647043 | skids++ | S0 (2 files):
Merge pull request #109 from skids/master

Start to rehabilitate Range Iterator test file post-GLR
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
i'm not yet hooking up the Reference with its actual target object. i wonder if i should
hoelzro: are you interested in that? i can upload it along with an example heap 02:39
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? :)
i'll post it in #perl6 02:41
hoelzro timotimo: I guess it wouldn't hurt to share the link ;) 02:42
timotimo there we go :) 02:46
hoelzro timotimo++
03:22 sortiz joined
[Tux] test 21.488 07:44
test-t 14.080
csv-parser 50.807
nine up and to the right... 07:48
07:56 nwc10 left 07:58 RabidGravy joined
lizmat good *, #p6dev :-) 08:33
moritz \o
moritz doesn't need to run around with drawn arms
lizmat looking at [Tux] test-t timings, I cannot help but wonder what I did yesterday that caused the slowdown :-(
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?
lizmat except maybe make the core bigger ?
it's a small increment (yet again)
[Tux] www.xs4all.nl/~hmbrand/speed.log <= the complete log 08:35
(used for the graphs)
[Tux] => $work - bbl 08:36
RabidGravy how can I find why something is segfaulting in moar/reprs/CStruct.get_int 08:56
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:02
2.2s between March 5th and March 12th 09:04
lizmat $ 6 'my str @a = "a","b"; dd @a' 09:06
array[str].new("a", "b")
wheeee
only add to add 2 lines to native_array, and adapt the parameterize to allow str 09:07
nine nice one
lizmat *need
however, the question is really, can we do this in 6.c?
should this be 6.c.1 or 6.d ?
it *is* something new (although it was always planned) 09:08
dalek kudo/nom: eed4ebb | lizmat++ | src/core/native_array.pm:
Add support for native str arrays

Turns out it was trivial to add once the role generation code was in place.
Please note that this is for review only: one could consider this having to be part of 6.d, or at least a 6.c.1.		 09:14
lizmat afk for a few hours& 09:37
dalek kudo/nom: 2a20197 | lizmat++ | src/core/native_array.pm:
Add str|intarray.join, opt intarray.STORE(Range)
 12:22
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:28
.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
oh
lizmat yes, I know you must
timotimo well, it could be that if the role is applied after the core setting is through, it's fine?
lizmat it's just that I forgot, and it didn't complain
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?
i'm so used to your commit messages having those numbers in them
lizmat the intarray.STORE case was about 30% 12:31
the strarray.join was about 10x faster, the intarray.join about 5x faster
timotimo awesome :) 12:32
dalek kudo/nom: 2627232 | lizmat++ | src/core/native_array.pm:
Apparently we don't need no multi's here
 12:33
lizmat m: say Buf.new(1,2,3).WHICH 12:34
camelia rakudo-moar 2a2019: OUTPUTĀ«Buf|57312608ā¤Ā»
lizmat m: say Blob.new(1,2,3).WHICH
camelia rakudo-moar 2a2019: OUTPUTĀ«Blob|58573488ā¤Ā»
timotimo ah, blobs could become value types, eh?
lizmat feels to me since Blob's are immutable, it should be a value type, indeed :-) 12:35
hoelzro o/ #p6dev 12:44
timotimo: have you thought about making that code you wrote last night into a proper module?
timotimo yeah 12:45
i'm also thinking to make it not json 12:46
because it's really not structured at all
if it was just lines with a keyword in front, that'd be a lot faster to parse, and would easily allow "parallelization"
moritz timotimo: Blob is a role, and mutable objects to the Blob role 13:02
and blob happens to pun into a class as well
timotimo oh
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?
moritz 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
timotimo hoelzro: the module might land in moarvm/tools or so 13:14
lizmat moritz timotimo: that was the line of thought I was going for 13:15
dalek kudo/nom: 2494cba | lizmat++ | src/core/Buf.pm:
Make Blob.join|perl 2x as fast
 13:16
lizmat jnthn: do you think a SHA1 of a Blob would be sufficiently unique for a .WHICH ? 13:20
jnthn Hm, is Blob listed as a value type? :) 13:23
It's a...bit risky :)
lizmat jnthn: well, it *is* supposed to be immutable ?
Buf.WHICH would not change
from the current behaviour
m: Buf.new(1,2,3).WHICH.say
camelia rakudo-moar 262723: OUTPUTĀ«Buf|54105792ā¤Ā»
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
lizmat: I more meant does S02 list it as a value type though
lizmat ah, lemme check
timotimo it would break things? i think i'm confused 13:25
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
indeed
so a 6.d thing potentially
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
timotimo 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
perlpilot Blob is in the list after S02:1415
"Objects with these types behave like values"
timotimo ah! fantastic 13:29
lizmat perlpilot++
timotimo so giving Blob the WHICH would be a fix, not a change :)
lizmat eh, yeah, that was my thought :-)
jnthn OK, then +1
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
timotimo S02:1415 13:34
synopsebot6 Link: design.perl6.org/S02.html#line_1415
timotimo that list also has Enum, EnumMap, and LoL
that may want to be updated ... at some point
jnthn lol... 13:35
Yeah
There is no LoL
timotimo yeah, no project euler, either 13:36
jnthn :D
dalek kudo/nom: 5958903 | lizmat++ | src/core/Buf.pm:
Give Blob a .WHICH fitting for a value type

While Buf.WHICH remains the same, since that is a mutable type.
Please note that it was not an option to have a .WHICH attribute frozen in a $!which, as array type REPR's don't allow attributes.		 13:55
lizmat $ 6 'Blob.new(1,2,3,4).WHICH.say'
Blob|4697A8195A0E8EF4E1EE3119268337C8E0AFABFC
$ 6 'Buf.new(1,2,3,4).WHICH.say'
Buf|140461630105216
timotimo 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
lizmat timotimo: that would be excellent 13:57
perlpilot timotimo was reading my mind
lizmat at least the Blob.join got 2x faster recently :-)
timotimo 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
lizmat 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
jnthn ObjAt needs to become something smarter, I guess
nine timotimo: shouldn't blobs be well blobs of memory, IOW perfectly useable as input for SHA1 already?
jnthn It being a string is very much a stop-gab
*gap 14:00
timotimo nine: yeah, it'd be possible to run it directly on the blob
we don't have to support WHICH being equal across runs of perl6, right?
lizmat m: use nqp; nqp::shaq(nqp::list_s("a","b"))
camelia rakudo-moar 2494cb: OUTPUTĀ«===SORRY!===ā¤No registered operation handler for 'shaq'ā¤Ā»
timotimo so changing the implementation shouldn't be a problem
lizmat m: use nqp; nqp::sha1(nqp::list_s("a","b"))
camelia rakudo-moar 2494cb: OUTPUTĀ«This representation (VMArray) cannot unbox to a native stringā¤ in block <unit> at /tmp/doUB7udTRH line 1ā¤ā¤Ā»
lizmat timotimo: no, only during the run 14:01
and possibly only also in a given process
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ā¤ā¤Ā»
timotimo fair enough; it could just grow a little if-else for a VMArray that doesn't try to unbox_s
lizmat commute to NRP meeting& 14:05
14:07 RabidGravy joined
timotimo i'm in dire need of a nap 14:13
moritz SIGNAP 14:35
RabidGravy Is this sort of thing known to fail ? gist.github.com/jonathanstowe/4b7d...4b374366e2 14:46
it segfaults in get_int when printing the struct 14:47
however if I change the native sub to take a CArray[int64] instead it gives the "correct" result 14:48
the case of "populating an array of structs allocated by the caller" isn't tested for in the NC tests 14:58
hoelzro timotimo: make sense 14:59
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:19
rt.perl.org/Ticket/Display.html?id=127730 if anyone is bored 15:44
dalek p: 556af98 | (Pawel Murias)++ | src/vm/js/ (5 files):
[js] Support compiling and running the stuff inside a role Foo {...} during compile time.

Implement nqp::iscompunit, nqp::compunitmainline, nqp::compunitcodes ops needed for that.		 16:27
[Coke] (things for review should probably not go in nom, but in a branch) 16:46
sortiz RabidGravy, Can I PM? 18:02
RabidGravy er 18:03
sure
timotimo sortiz is prime minister?
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
jnthn timotimo: We want the original location really 19:24
timotimo did that work at some point? i seem to recall it did
jnthn Maybe :)
[Coke] "tests or it didn't happen" 19:55
20:06 b2gills joined 20:19 lizmat joined
nine Oh compilation_mode == is_precompilation_mode. I missed that connection. 20:22
Is there a way to bind an int attribute to another object's int attribute? 20:44
japhb [Coke]: I want that on a sign outside my office. :-) 20:45
timotimo "int" attributes are just a tiny slot inside the object, where the int value lives 20:46
there isn't an indirection there
[Coke] japhb: :)
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:47
nine Yep. At least I now know that the binding was causing the segfault. 20:49
And I'm understanding a lot more about the code structure now. 20:50
jnthn :)
nine++ # digging into perhaps the scariest bit of the Rakudo codebase
21:14 psch joined
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. 22:09

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!