samcv jnthn, you should find one of your modules and add a license to meta 03:27
we're at exactly 50% things with/without licenses. you could win points if you get us over 50% 03:28
or anybody here!
lizmat Files=1192, Tests=56873, 210 wallclock secs (12.46 usr 4.80 sys + 1233.36 cusr 123.08 csys = 1373.70 CPU) 07:32
lizmat gave an answer to stackoverflow.com/questions/4370157...5#43704475 08:34
[Tux] This is Rakudo version 2017.04.3-112-g1ed76a903 built on MoarVM version 2017.04-44-gf0db8822 08:54
csv-ip5xs 3.230
test 13.036
test-t 5.347 - 5.379
csv-parser 13.109
and my computer was not busy doing other stuff
lizmat [Tux] could it be that you have a large .precomp dir ? 09:08
nine lizmat: would that make any difference? 09:09
lizmat well, in most OS's dir searches are still lineair
I should say, filesystems 09:10
if you have 1000's of .precomp entries
that does make a difference
[Tux] 290M .precomp/
rm -rf .precomp/ .panda-work/ 09:11
This is Rakudo version 2017.04.3-112-g1ed76a903 built on MoarVM version 2017.04-44-gf0db8822 09:14
csv-ip5xs 3.034
test 13.046
test-t 5.107
csv-parser 14.313
lizmat so looks like it made a difference :-) 09:15
[Tux] but still not way below 5.000 :/ 09:27
lizmat [Tux]: true :-( 09:39
Geth rakudo/nom: c41a200ade | (Elizabeth Mattijsen)++ | 3 files
Make Set.SET-SELF return set() for empty Sets

As Sets are immutable, there should only one empty set around.
09:46
rakudo/nom: 3d99321f19 | (Elizabeth Mattijsen)++ | src/core/set_operators.pm
All other types on (.) and (+) need Bag coercion

This fixes an uncaught error on Iterable (+) Iterable if the Iterable contained Pairs. And it improves the speed of Iterable (.) Iterable by a factor of 2.5.
rakudo/nom: 6d12cecc95 | (Elizabeth Mattijsen)++ | 9 files
Remove trailing whitespace
09:55
rakudo/nom: bdb5391b94 | (Elizabeth Mattijsen)++ | src/core/set_operators.pm
Simplify Set creation in several set operators

Now that Set.SET-SELF is smart enough to return set() for empty Sets
10:04
pmurias Unhandled exception: Missing or wrong version of dependency '../MoarVM/install/bin/../share/nqp/lib/MAST/Nodes.nqp' (from 'src/Perl6/Pod.nqp') 10:08
what could be causing that while trying to make rakudo?
nine Have you tried make clean? 10:09
I usually need to do that after updating nqp 10:10
pmurias I hate Makefiles-- so much :( 10:11
timotimo cross-project makefiles, not much fun 10:14
jnthn samcv: Discovered github.com/jnthn/p6-app-moarvm-heapanalyzer was still without one, so there we go... :-) 10:59
samcv yay! 11:21
you win!
party time
jnthn :-)
samcv now we can say that *most* modules have license tags
timotimo cool 11:23
"your chance of a module having a license tag is better than 50/50!"
samcv that is unproven. 11:25
though
but if you randomly install all modules then yes
dogbert17 does anyone know if slangs have a large overhead? 12:10
timotimo i've never measured, but it shouldn't be terribly big 12:11
and it's only compile-time overhead of course
dogbert17 I was looking at [Tux] csv code again, i.e. github.com/Tux/CSV/blob/master/test-t.pl 12:12
if you put an 'exit 0' at line 8 and then time the script I get 1.3 seconds
timotimo and if you rewrite it to be untuxic? 12:13
dogbert17 I'd say one second faster
i.e. I removed the compilation errors I get when I remove the slang 12:14
timotimo interesting
wanna --profile-compile that? 12:15
dogbert17 is there a --profile-compile switch?
or do you mean perl6 -c --profile test-t ? 12:16
lizmat m: Bag.new.roll # hmmmm
camelia Cannot iterate object with P6opaque representation (Scalar)
in block <unit> at <tmp> line 1
Zoffix s: Bag.new, 'roll', \()
SourceBaby Zoffix, Sauce is at github.com/rakudo/rakudo/blob/bdb5...gy.pm#L498 12:17
timotimo there is a --profile-compile switch
dogbert17 cool, didn't know that
lizmat Zoffix: working on that
timotimo :)
dogbert17 hmm, wrote perl6 --profile-compile test-t.pl and now it hangs, maybe it's slow 12:18
timotimo it's likely quite slow
dogbert17 I'll wait then :) 12:19
pmurias is a raw » allowed in the comments and literals in the MoarVM source
timotimo hopefully it won't blow up in memory usage and asplodes :)
pmurias: i know nothing about the other C compilers we target :)
but isn't » in latin1?
m: say "»".ord 12:20
camelia 187
timotimo that should totally be fine
pmurias timotimo: gcc handles that fine, I don't know what else are we using to compile on other despicable platforms 12:21
timotimo hmm 12:22
well, you know, we're using {} and other kinds of parenthesis without using trigraphs
i think a latin1 character should be fine
Zoffix kinda weird $*SPEC.curupdir is a `none`, rather than `any` Junction; considering .curdir and .updir are strings ' 12:25
'.' and '..'
timotimo right, that must be because it was originally used as the test for dir? 12:28
which of course could also have used none(any(...)) rather than just the any from curupdir
or, you know, none(|$*SPEC.curupdir)
dogbert17 timotimo: the routines with the largest exclusive times are: mergesubstates (17.99), mergesubrule (14.85) and addedge (14.52) 12:33
these are percentages btw
timotimo oh, yikes, why isn't the result of that precompiled? 12:34
MasterDuke_ dogbert17: was that for a clean (i.e, hadn't been compiled before) run?
timotimo or is Slang::Tuxic exporting a "no precompilation" thing? 12:35
dogbert17 I had run it before but I could try again
github.com/FROGGS/p6-Slang-Tuxic/b...g/Tuxic.pm
timotimo i'unno 12:36
dogbert17 runs again with --profile-compile 12:39
1.3 secs to get the code running is quite much, perhaps it's different on 64 bit systems 12:40
timotimo well, we have the jit there, so that's something 12:41
lizmat feels to me the 1.3 is mostly Slang::Tuxic causing a redo of the grammar
timotimo hm. i wonder if a manual call to precompute_nfas would help 12:42
it's a private method on a Grammar
perhaps that could go into define_slang 12:43
dogbert17 lizmat: but if it takes the same time on [Tux] machine then that's 20 % of the total execution time 12:44
lizmat dogbert17: have you tried removing Slang::Tuxic from test-t.pl ? 12:45
looks like it doesn't need it 12:46
dogbert17 I do get compilation errors if I remove it
lizmat you do ?
hmmm
Zoffix I wanna add a mode argument to nqp::open(). Right now we have no core way to securely create files. 12:47
And add a :chmode arg to IO::Handle.open.... :mode would be nice, but it's already taken up :/
I mean :chmod 12:48
timotimo opening and at the same time (?) changing the permission flags?
dogbert17 lizmat: two terms in a row on e.g. $sum = [+] $csv.getline_all ($*IN)».map(*.elems);
Zoffix timotimo: just giving different mode to libuv than DEFAULT_MODE 12:49
lizmat yeah... seeing now too, wonder what happened before
timotimo mhm
Zoffix timotimo: I'd hope there's no "changing" but rather the file is created in the given permissions from the start
timotimo ah
Zoffix Otherwise there's still a security issue
lizmat dogbert17: rewriting test-t.pl to plain Perl 6 saves me 13% (3877 -> 3406 msecs) 12:51
dogbert17 that's quite a savings
lizmat it *would* bring it below 5 seconds again :-) 12:52
dogbert17 but I seem to remember that [Tux] wanted his slang
[Tux] correct. no slang = no Text::CSV (at least not by me)
lizmat yeah, but one could argue that's not needed in the test file
[Tux]: I mean, test-t.pl is like a user file, and a user would most likely *not* use Slang::Tuxic 12:53
[Tux] lizmat, I agree: but if it surfaces additional problems, the canary lives happily everafter
lizmat so I think it would be fair to remove Slang::Tuxic from test-t
[Tux] lizmat, unless the user is me :)
lizmat well, we could make a test-tuxic.pl :-) 12:54
timotimo [Tux]: how many lines is hello.csv supposed to have so i get the same workload as you?
jnthn Or try to figure out why Slang::Tuxic requires `no precompilation`, if that's the issue? :)
Zoffix huggable: bench csv
huggable Zoffix, export PATH=`pwd`/install/bin:$PATH; cd CSV; for i in $(seq 1 10000); do echo 'hello,","," ",world,"!"'; done > /tmp/hello.csv; time perl6 -Ilib -MText::CSV test-t.pl </tmp/hello.csv
Zoffix timotimo: ^
timotimo it doesn't have "no precompilation", though
Zoffix (ignore the export part)
timotimo ah
dogbert17 on my system I get (test-t) real 0m8.859s, (test-no-tuxic) real 0m7.871s # this is a crappy i5 660 12:56
jnthn Ah, OK 12:58
lizmat m: say 8859 / 7871
camelia 1.125524
lizmat yeah, that's about what I saw
timotimo hm. i added precompute_nfas to define_slang but it didn't make mergesubstates/optimize/mergesubrule/addedge disappear from the top of the routines tab
it does have precompute_nfas in it, at the 5th spot, and it takes 73% of total run time
er, total compile time 12:59
dogbert17 is now grammar expert so github.com/FROGGS/p6-Slang-Tuxic/b...g/Tuxic.pm does not give me any clues 13:00
s/now/no/ :)
timotimo dogbert17: It is like a finger pointing away to the moon. Don't concentrate on the finger or you will miss all that heavenly glory. 13:02
(the finger is Slang::Tuxic, the moon is rakudo's and nqp's innards) 13:03
dogbert17 ah
so IS Slang::Tuxic precompiled? 13:08
lizmat yes 13:10
afaik
and Text::CSV as well
afaik
dogbert17 so it might be the 'redoing of the grammar' which takes up the time then, like you wrote earlier 13:12
lizmat m: say now - BEGIN now; sub postfix:<!>(\a) { a } # the cost of rewriting the grammar 13:14
camelia 0.28916266
lizmat m: say now - BEGIN now; sub prefix:<!>(\a) { a } 13:15
camelia 0.0146918
lizmat prefix:<!> exists in core, postfix:<!> doesn't
pmurias jnthn: I made a pull request to fix the str to num conversion
jnthn: :16[1,1] is not implemented yet
jnthn: paste.scsys.co.uk/559078 13:16
dogbert17 so the thing that didn't exist tool ~0.3 secs to compile then
pmurias jnthn: that the test file for that PR
Geth roast: d543e756ad | (Zoffix Znet)++ | S32-io/io-handle.t
[io grant] Test IO::Handle.DESTROY closes the handle
13:20
timotimo i don't konw how grammar::tracer fails to invoke the original $meth 13:21
oh, it could very well be it's deeper inside than i thought 13:22
we really are calling invoke_o on VMNull 13:25
lizmat Zoffix: s/It's worth nothing/It's worth noting/ ? 13:27
Geth rakudo/nom: 9e7d0b36cb | (Elizabeth Mattijsen)++ | src/core/Baggy.pm
Make Baggy.roll about 15% faster

Also fix issue for Bag.new.roll, which used to fail.
13:30
Zoffix lizmat++ thanks fixed. 13:31
timotimo jnthn: could the fact that match objects and cursors are now the same thing (and derived from the grammar if i understand correctly?) have some bearing on why grammar::tracer's wrapcache explodes? 13:34
the last thing it prints from my debugspam before exploding is that it's just made an unwrapped version of !alt 13:37
huh, *weird* 13:39
say "something" gives an "unable to invoke this object (REPR: Null, VMNull)"
evalable6 timotimo, Full output: gist.github.com/9a2cf767c4a6bcb4a8...1f30c40286
(exit code 1) 04===SORRY!04=== Error while compiling /tmp/LApikm2HtN
Two ter…
timotimo but nqp::say("something") works
thank you, evalable6
dogbert17 timotimo: so we have a couple of broken modules as well 13:44
timotimo what the flying fuck. 13:45
even $indent++ or $indent = $indent + 1 breaks
jnthn: could it be that the created wrapper function somehow isn't correctly closing over the perl6 core setting? 13:47
timotimo pretty stumped 13:49
[Tux] re-runs after lizmat's commit 14:00
note that this did neither change Text::CSV not perl6 (rakude/nqp), but *just* the invoking script 14:01
s/not/nor/ 14:02
4.436
lizmat whee! :-)
[Tux] I still think this time change isn't fair 14:03
lizmat [Tux]: I think it would only be unfair if you were the only user of Text::CSV, which I sincerely hope is *not* the case 14:04
afaik, test-t is about testing Text::CSV performance, not Slang::Tuxic performance 14:05
Geth rakudo/nom: aeecfc445d | (Elizabeth Mattijsen)++ | 5 files
Move QuantHash helper methods to Rakudo::QuantHash

Since I will probably add a few more in the near future, and I don't want to make Rakudo::Internals even more behemothy than it already is.
14:07
dogbert17 lizmat++, [Tux]++ 14:08
at least we now have an idea as to the current compile/execution overhead wrt Slang::Tuxic 14:09
lizmat $ 6 '' 14:10
real0m0.120s
$ 6 'use Slang::Tuxic'
real0m0.557s
[Tux] lizmat, I mean that it now *looks* like the speed improved, but nothing changed
and there still remains the undelying performance loss of using a slang in two layers 14:11
lizmat [Tux]: two layers ?
there is only a compile time performance issue
since we don't pre-compile the script, we see that in every run 14:12
[Tux] Text::CSV already uses Slang::Tuxic, so I see no reason why having the calling script also using Slang::Tuxic causes that much overhead
ah, oké, that explains
lizmat because the precomped version of Text::CSV doesn't need It anymore
[Tux] right
timotimo right, removing Slang::Tuxic from the rest of Text::CSV will not have a performance impact on test-t performance 14:17
anyway, ideally we'd be able to just re-use the precompiled result of Perl6::Grammar + Slang::Tuxic::Grammar and then the performance hit on test-t would be gone regardless of using Slang::Tuxic or not 14:18
lizmat timotimo: I'm not seeing how you could merge the precomped Grammars 14:23
timotimo hm. because the EXPORT is run every time the user script is run? 14:24
you're right, there's nothing we could really do about that :\ 14:25
lizmat would have loved to be proved wrong
timotimo a little spark of hope was to check if what we're being passed is the pristine Perl6::Grammar and just return a pre-made one from a module we've precomped 14:26
but i don't think we can just change the type from underneath the instance?
i mean, we do have a type change thing that exists. not sure if that'd work here
lizmat neither :-) 14:27
timotimo of course, test-t could become a module that just gets used and it'd do its thing in the mainline :) 14:29
lizmat yes, but *that* feels like cheating, as we lose the compile overhead of test-t altogether then 14:32
timotimo yes
lizmat Text::CSV is typically used in one/few-off situations
timotimo it'll give an unexplained change in all timings
lizmat if anything, perhaps we should deduct .3 from all measurements so far 14:33
timotimo mayhaps
anyway, the whole mergesubrules and stuff business can become faster from a thing TT has been pondering
so maybe we'll get to chop a few second-parts from compile time there 14:34
lizmat that would be brill :-)
dogbert17 as far as the rest of the code I remember [Tux] pointing to the slowness of the NEXT phasers 14:37
Geth rakudo/nom: 94390ae9ca | (Elizabeth Mattijsen)++ | src/core/Baggy.pm
Use the more ideomatic .raw_hash instead of nqp
14:40
rakudo/nom: 2bd1d9ec77 | (Elizabeth Mattijsen)++ | 3 files
Move R:I:WeightedRole to R:QuantHash

To make Rakudo::Internals less behemothy still
lizmat afk& 14:54
[Tux] dogbert17, that is because return/next/last is handled as exception (as jnthn explained), so only an optimizer can be used to boost the use of next 15:38
where a relatively simple looking loop using next and last to jump out of it can be re-written to be a huge if/else tree 15:39
Geth rakudo/nom: d672424efc | (Elizabeth Mattijsen)++ | src/core/Rakudo/QuantHash.pm
Reorder methods into logical sections

Purely to make maint easier
18:40
rakudo/nom: 07feca6747 | (Elizabeth Mattijsen)++ | 3 files
Add R:Q.BAG-TOTAL, make BagHash.roll 1.7x as fast

Optimize the adding up of values in a Bag/BagHash. Is not as important for Bag's as is it cached there upon first usage. But since BagHashes
  are mutable, the total is currently calculated each call.
MasterDuke_ s: &infix:<%%>, \(4, 2) 19:22
SourceBaby MasterDuke_, Sauce is at github.com/rakudo/rakudo/blob/07fe...ic.pm#L221
Geth rakudo/nom: 5e459bce12 | (Elizabeth Mattijsen)++ | 4 files
Add R:Q.MIX-TOTAL, make MixHash.total 1.4x faster

Optimize the adding up of values in a Mix/MixHash. Is not as important for Mixes as is it cached there upon first usage. But since MixHashes
  are mutable, the total is currently calculated each call.
This does not affect Mixy.roll, as that uses another logic.
19:31
rakudo/nom: b1fbd1331d | (Elizabeth Mattijsen)++ | 3 files
Some more uses of .raw_hash

Preparing some more for %!elems -> $!elems shift. Also some logic folding to handle empty (Bag|Mix)Hashes faster.
20:05
nqp: MasterDuke17++ created pull request #356:
Some cleanup to the SQL profile output
20:14
lizmat MasterDuke_: it looks like your PR breaks the JVM build ? 20:38
MasterDuke_ t/qast/01-qast.t failed, but i don't see how i could have effected that at all 20:39
Geth rakudo/nom: 7404c706ff | (Elizabeth Mattijsen)++ | src/core/Rakudo/QuantHash.pm
Add R:Q.A.MIX-TOTAL-POSITIVE

Needed for streamlining Mix.roll
20:42
rakudo/nom: 762fd23906 | (Elizabeth Mattijsen)++ | 5 files
Make Bag|Mix.new return bag()|mix() directly

Without needing to create an intermediate Bag|Mix object. Since new() lived in the role, this shouldn't actually add any new entries to the MMD tables.
japhb .tell nine With a Rakudo built from scratch a few minutes ago, I am unable to install Inline::Perl5 using zef, despite tests passing. Error: ===> Install [FAIL] for Inline::Perl5:ver('0.26'):auth('github:niner'): ===SORRY!=== Could not find Inline::Language::ObjectKeeper at line 4 in: ... 21:04
yoleaux japhb: I'll pass your message to nine.
Geth rakudo/nom: fec547a1ed | (Elizabeth Mattijsen)++ | 2 files
Abstract Baggy.roll() into R:Q.BAG-ROLL

So we can streamline Baggy.roll(x) and Mixy.roll(x). No noticeable performance difference on Baggy.roll.
21:07
lizmat hmmm.... Geth and/or GitHub a little slow 21:50
anyways, I've just committed github.com/rakudo/rakudo/commit/a2...60f746b601 21:51
MasterDuke_ gfldex was mentioning in #perl6 that he was testing github's api today and it was very slow and causing retries
timotimo status.github.com/
you see that?
lizmat yeah, looks all green no? 21:52
timotimo "time to first byte" went up to almost 20 seconds (or is that just 2s?)
lizmat looks like it peaked just below 4 secs
timotimo right, not 20 %) 21:53
lizmat but mean hook delivery time is still < 1 second
so maybe Geth has an issue ?
anyways, looking at Baggy.grab(*) 22:00
currently, that's eager 22:01
I'm thinking of making it lazy, and having it return a Seq
timotimo hmm 22:05
so as you're iterating over the list, the bag slowly gets mutated?
lizmat yeah, so I'm not sure whether that would be a bug or a feature 22:10
I mean, if you want immediate removal, then make it eager :-)
docs don't state anything about laziness
specs also don't say anything about laziness 22:11
timotimo right 22:13
interesting little tidbit 22:14
lizmat I could see uses for a lazy grab
timotimo yeah
kind of
lizmat anyways, I will sleep on it...
enough hacking today...
good night, #perl6-dev!
timotimo gnite lizmat! 22:15
BenGoldberg How can you be going to bed, it's only 6 pm! ;) 22:32
Zoffix "◀▬▬ │ Geth (zofbot-get@perl6.party) has quit (Remote host closed the connection)" 23:42
It wasn't even in the channel when you were discussing it..
And I don't know why it died because I still didn't add any logging to it. Its screen was just not found :/
timotimo oof 23:43
MasterDuke_ fyi, timotimo merged github.com/perl6/nqp/pull/356 while Geth was still away 23:55
Zoffix hm 23:59
m: my @COMMIT-FILTERS where .all ~~ Callable && .all.name = sub foo ($) {}
camelia Sub object coerced to string (please use .gist or .perl to do that)
in block <unit> at <tmp> line 1
Zoffix m: my @COMMIT-FILTERS where {.all ~~ Callable && .all.name} = sub foo ($) {}
camelia ( no output )