|Tux| This is Rakudo version 2016.11-102-gabc64393d built on MoarVM version 2016.11-27-g3171dbbe 09:01
csv-ip5xs 3.158
test 13.951
test-t 6.480
csv-parser 14.019
|Tux| just finished s thriller that had a character called Froggs. He was evil :) 09:03
Reliquary, by Preston & Child 09:08
psch feh, findmethod is wonky /o\ 09:14
as in, after patching it to throw when we have an authorative method cache i can't compile nqp anymore, because it cannot find handle-exception on NQP::Compiler
the weird thing is that there's an nqp::can call that looks for handle-exception, and even if i change nqp::can to catch exceptions from findmethod it *still* dies 09:15
so it probably doesn't findmethod but methcall_* directly via indy, which i don't quite understand why it would do that
gfldex i put a link to perl6.org and and the webchat #perl6 in the about page of the advent blog 09:58
Ulti if anyone's interested the slowest operation by far in my bioinformatics code still is postcircumfix:<{ }> src/core/hash_slice.pm:51 and its pull-one src/core/Any-iterable-methods.pm:703 within there that takes up most of that time 10:23
like thats nearly all of the codes time 10:24
75% of its time
all other operations are relative to that lightning fast
s/75/50/ mattoates.co.uk/files/perl6/bioinfo...12-02.html 10:32
still considerable
timotimo i wonder if that already has the newer angular versions that are supposed to be a bit faster 10:53
Ulti timotimo that profile was taken from head at 10:30 GMT today 13:05
timotimo right, but did head do an nqp bump since the profile html template was updated? 13:07
anyway, i can just replace the paths to the angular scripts and it'll be enough
it kind of seems b0rked in the call graph view 13:08
it shows stuff that belongs to another tab entirely
in general, that profile is rather short 13:09
i.e. the code didn't run for too long
so i think the instance of postcircumfix:<{ }> refers to the line in Nucleic's translate method that maps over the sequence 13:11
i have a suggestion for you
instead of map *~*~*, $.sequence.uc.comb
please try $.sequence.uc.comb(3)
see if that helps 13:12
Ulti: ^ 13:13
Ulti helps with what? 13:21
timotimo: I'm not trying to make my code faster
I'm trying to point out things that are slow and how dumb first pass code works
but yeah the tests take about 1s to run now down from 35s so its not much time to see 13:22
timotimo OK, but could you have a look if it makes things very fast?
Ulti sure
timotimo cool 13:23
Ulti yup good chunk faster 13:26
1.01s to 0.89s
timotimo cool 13:28
arnsholt Array and dictionary are a known weak spot, IIRC
timotimo how's the percentage of postcircumfix:<{ }> inclusive now?
arnsholt There are some tricks you can do to make it faster, like replacing simple dereferences with AT-POS/AT-KEY I think
Ulti timotimo: mattoates.co.uk/files/perl6/comb3_profile.html 13:29
timotimo: yeah a lot smaller
weird thats coming up as hash slice :S
I guess its on that call you have the expression being evaluated 13:30
timotimo of course it's a hash slice?
you have a list inside the { }
so it gets passed an iterator, and it eagerly evaluates all the values 13:31
Ulti yeah but its the list generation thats slower not the hash slice
timotimo right, but inclusive is inclusive
Ulti k k
so its the pull one on that iterator thats slow
arnsholt Kinda weird that postcircumfix:<{ }> gets *interpreted* though, isn't it?
Ulti I imagine the comb itself is about the same cost
arnsholt Not even speshed? 13:32
timotimo the first thing i do is usually sort by exclusive time
that shows push-all is very expensive, 2004 entries, but 7.18% exclusive time
arnsholt Not hot enough, perhaps?
timotimo pull-one has 20k entries and 3.73% time
of course push-all has an OSR flair on it, which means there's a loop inside that does a bunch of work 13:33
i expect push-all just calls pull-one over and over?
arnsholt: you're looking at which profile there? in comb3 the postcircumfixis speshed 14:05
in the other profile it's speshed, too
Ulti: would you like to give us spesh- and jitlogs for both pieces of code to see what's what? 14:06
arnsholt timotimo: My bad, probably 14:07
timotimo arnsholt: okay
the most common cases of "we can't jit this" is the unsupported kinds of parameter grabbing
Ulti timotimo: sure 14:09
do you want them in isolation though?
arnsholt I guess ideally we'd like to inline common operations like indexing?
Ulti as in golf the code to just that expression?
timotimo i'd prefer each to be its own file
no, the full files are fine
Ulti k
timotimo compress them, though. they can become quite big
but they ought to compress really well
[Coke] anyone see the patch interaction on perl6-language? Is there a way for me to phrase that more clearly? 14:10
like, the hardcore thing is, "our time is valuable. if you really want to help us, make it EASY for us to take your help"
but I'm trying to phrase it more nicely. I think I failed there. 14:11
timotimo but it isn't terribly difficult
done 14:12
Ulti timotimo ok how do I actually get those dumped out? 14:14
I can only see an option for the heap dump
;_; 14:15
timotimo oh, it's the environment variables
they are documented near the bottom of moar --help
Ulti k k thanks 14:17
[Coke] we've been talking in #perl6 about getting people to volunteer to write advent articles over the past few weeks. Anyone in here who is on the fence? we still have half a dozen slots open. 15:59
docs.perl6.org/routine/install_method_cache - should that be kebab cased? 16:01
)(looks like a lot of the Metamodel::* stuff has _'s
babydrop Yeah, the advancish stuff is snake_cased on purpose. 16:02
timotimo i think i have an idea for a post
i'll call it ...
"shocking: perl6 mascot 'camelia' blown to smithereens in this gruesome blog post" 16:03
(suggestions welcome)
babydrop :o
I'd read it :)
timotimo "you won't believe what happened next!"
babydrop "Last one will blow your mind!"
moritz reddit/r/SavedYouAClick comes to mind :-) 16:11
japhb [Coke]: I am one of the "still on the fence" people. In case you're wondering why someone would be: I have an idea, but the code behind it needs to get in a better state before I can write about it. Thus I won't sign up unless I get the code to "won't be embarassed by it" levels, and there's currently about a 70% chance that won't happen this year. 16:22
TimToady is always on the fence 16:25
TimToady is usually on several fences simultaneously...
timotimo tim minchin has some good words about the fence 16:26
Ulti: do you still have a bit of time left over? :) 17:11
Ulti: because i just pushed two moarvm commits that have the potential of removing up to 25 bailed frames 17:12
but knowing the jit, those frames all just have something else unimplemented following that :D
perlpilot japhb: that's where I'm at too. 17:43
gfldex m: class C {}; role R {}; sub postfix:<.>(C:D $c){ $c but R }; my $c = C.new; $c. 19:08
camelia rakudo-moar abc643: OUTPUTĀ«===SORRY!===ā¤Cannot find method 'ast' on object of type NQPMuā¤Ā»
gfldex I know what I'm doing is silly but is this still a bug?
(because it leaks NQPMu)
psch i think it's a parsing bug, yes 19:09
babydrop It's at the very least an LTA error, 'cause it doesn't show where the problem is.
psch as in, dottyop/methodop shouldn't match if there's nothing afterwards
so it should hit the postfix and just work
babydrop ohh 19:10
psch i'm not sure LTM allows that though :)
m: class C {}; role R {}; sub postfix:<.>(C:D $c){ $c but R }; my $c = C.new; $c.;
camelia rakudo-moar abc643: OUTPUTĀ«===SORRY!===ā¤Cannot find method 'ast' on object of type NQPMuā¤Ā»
psch note though that explicit statement end doesn't help
m: 1.; 19:11
camelia rakudo-moar abc643: OUTPUTĀ«===SORRY!===ā¤Decimal point must be followed by digitā¤at <tmp>:1ā¤------> 1.ā;ā¤Malformed postfix callā¤at <tmp>:1ā¤------> 1.ā;ā¤ā¤Ā»
psch m: "foo".;
camelia rakudo-moar abc643: OUTPUTĀ«===SORRY!=== Error while compiling <tmp>ā¤Malformed postfix callā¤at <tmp>:1ā¤------> "foo".ā;ā¤Ā»
psch the added postfix:<.> gets us out of somewhere where we would call the latter error message
but we apparently still do the wrong action afterwards
m: "foo" . uc 19:12
camelia ( no output )
psch i suspect the fact that that one works plays a role there :)
gfldex i shall rakudobug 19:13
babydrop m: sub postfix:<.>($){ }; 1. 19:14
camelia rakudo-moar abc643: OUTPUTĀ«===SORRY!===ā¤Cannot find method 'ast' on object of type NQPMuā¤Ā»
babydrop m: sub prefix:<.>($){}; . 1 19:16
camelia rakudo-moar abc643: OUTPUTĀ«===SORRY!===ā¤Cannot find method 'ast' on object of type NQPMuā¤Ā»
psch m: sub postfix:<.>($) { }; 1..1 # oh geez 19:19
camelia rakudo-moar abc643: OUTPUTĀ«===SORRY!===ā¤Cannot find method 'ast' on object of type NQPMuā¤Ā»
psch yeah, that's gonna be a lot of fun to untangle 19:20
maybe the sanest thing is to bail on every foofix that consists of only a single dot :)
m: sub infix:<.>($, $) { }; 1 . 1
camelia rakudo-moar abc643: OUTPUTĀ«===SORRY!=== Error while compiling <tmp>ā¤Unsupported use of . to concatenate strings; in Perl 6 please use ~ā¤at <tmp>:1ā¤------> sub infix:<.>($, $) { }; 1 .ā 1ā¤Ā»
gfldex i c/p the wrong line into the bugreport :-/ 19:21
i was in a hurry!
psch m: sub postcircumfix:<. .>($,$) { }; "foo".1.
camelia rakudo-moar abc643: OUTPUTĀ«===SORRY!===ā¤Decimal point must be followed by digitā¤at <tmp>:1ā¤------> b postcircumfix:<. .>($,$) { }; "foo".1.ā<EOL>ā¤Malformed postfix callā¤at <tmp>:1ā¤------> b postcircumfix:<. .>($,$) { }; "foo".1.ā<EOL>ā¤ā¤Ā»
gfldex filed as #130245 19:24
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=130245
babydrop bartolin: FWIW, you already have a commit bit to perl6/nqp... 19:38
bartolin babydrop: yeah, I know. and since forgiveness > permission I should probably just commit stuff, even if I'm not 100% sure 20:03
psch ++bartolin :) 20:04
dalek p: 94b38a3 | usev6++ | src/vm/jvm/runtime/org/perl6/nqp/runtime/ExceptionHandling.java:
[JVM] Add null check in backtrace generation
 20:06
ast: a151379 | bartolin++ | integration/error-reporting.t:
Make test for output of backtrace less specific

After the recent changes to backtrace handling this test started to fail on rakudo-j. There are references to lines in gen/jvm/CORE.setting which are causing the test to fail
  because of the 's' in 'setting'.
Allowing additional lines in the backtrace still fits the test description 'Thrown Failure outputs dual backtraces'.		 20:16
roast: bdd5db7 | bartolin++ | integration/error-reporting.t:
bartolin iiuc that commit to roast (a151379e39) should also go into 6.c-errata. how do I do that? I used cherry picking only once or twice, but that's the way to do it? 20:22
timotimo yeah, checkout the 6.c-errata branch and just cherry-pick, but make sure to pull in there first 20:23
babydrop The handful of times I've done it, I just did it manually on 6.c-errata :(
dalek ast/6.c-errata: cce58c2 | bartolin++ | integration/error-reporting.t:
Make test for output of backtrace less specific

After the recent changes to backtrace handling this test started to fail on rakudo-j. There are references to lines in gen/jvm/CORE.setting which are causing the test to fail
  because of the 's' in 'setting'.
Allowing additional lines in the backtrace still fits the test description 'Thrown Failure outputs dual backtraces'.		 20:25
bartolin hopes that was correct 20:26
hmm, shouldn't it have the same commit id in both branches? 20:28
bartolin goes and reads some more about cherry-picking
timotimo no, can't 20:29
IDs are cryptographic hashes of the commit including the parent commit hash, among other things
since the branch has different commits in it (and the files also differ), it'll better have a different hash
bartolin aha! I didn't know about the parent commit thing (et al.). thanks! 20:30
masak timotimo: was gonna correct you on the term "cryptographic hashes", but Wikipedia agrees with you ;) 21:03
timotimo another important term that you should definitely look up is "content-addressed storage"
masak reminds me of the winner of the "unorthodox uses of Git" contest (or whatever it was called): someone checked if his photos were duplicates by doing `git add` on them one by one, and checking whether a new blob was added to .git/objects 21:05
timotimo ugh :) 21:08
jnthn It may be unorthodox, but it's O(n) :P 21:41
masak yes, I thought it was pretty creative and cute 21:45
japhb jnthn: Under the assumption that calculating the hash is much faster than checking whether that hash already exists in the object pile, at least ...
*much slower
And that writing a new object to the backing store is O(1) 21:46
japhb remembers the days that "You have >1000 files in one directory? Well, there's your performance problem!" was actually a thing 21:47
jnthn wonders where the "no, that's too many" threshold is today... :) 21:48
masak that's why .git/objects does the .git/objects/hh/ subdirectories thing, is it not? 21:49
jnthn I always figured so
Though I've no good intuition if that's for the sake of non-modern filesystems :)
Or for modern ones too
[Coke] japhb: I ran into that in the last 5 years here. (though it was a bigger number) 21:50
japhb [Coke]: I'm not too surprised. Eventually anything above O(1) will grow to be big enough to notice. And if it's well above O(1), it will be noticed rather quickly. :-) 21:52
Although I still get a kick out of inverse-Ackerman being so slow growing that it is bounded by a small constant within the physical universe. 21:53
geekosaur jnthn, same place unless you're using ext4 btree dirs, zfs, or (if you can find a quasi-stable version) btrfs 22:06
and ext4 still has problems, and large dirs still have some problems even with btrees --- they solve the namei() performance issue but not others 22:07
jnthn Good to know; thanks 22:08
jfhek md5sum *.jpg | cut -d ' ' -f 1 | sort | uniq -c | sort # O(n) + smallcoeff * O(n log n) 22:10
if you need filenames, you need to do what perl groupies call Shwartzian transformation lol 22:15
MasterDuke timotimo: what sort of rakudo-level operations would be sped up by those ops you implemented on the JIT earlier today? 22:40
timotimo MasterDuke: some kinds of returns and gotos/break/whatever 22:46
MasterDuke: try "moar --dump CORE.setting.moarvm > coresettingdump.txt; grep throwpayloadlex coresettingdump.txt" 22:47

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!