00:02 sena_kun joined 00:04 Altai-man_ left 01:07 stoned75 joined 02:01 Altai-man_ joined 02:04 sena_kun left 03:04 softmoth joined 04:02 sena_kun joined 04:04 Altai-man_ left 05:54 softmoth left 06:01 Altai-man_ joined 06:04 sena_kun left
nine timotimo++ # title worked :D 06:25
lizmat github.com/Michael-S/raku_trivial_io_benchmark 06:47
looks like 25+% is spent in Mu.new, the prototype, with bootstrap's find_best_dispatchee taking about 8% 06:48
also, Mu.new stays red in the profile
I wonder what's going on here
looks like buf8.new is causing this 06:50
try profiling buf8.new for ^1000000 06:51
m: use nqp; dd nqp::create(buf8) 06:56
camelia You cannot create an instance of this type ()
in block <unit> at <tmp> line 1
lizmat que?
m: use nqp; dd nqp::create(buf8.^pun) 06:57
camelia Buf[uint8].new()
06:58 JJMerelo joined
Geth rakudo: 2946ed6423 | (Elizabeth Mattijsen)++ | src/core.c/IO/Handle.pm6
Make IO::Handle.read(1) about 3x as fast

Inspired by github.com/Michael-S/raku_trivial_io_benchmark .
Turned out that `buf8.new` for some reason is *not* getting optimized
  *at all*. Replaced occurrences of `buf8.new` in IO::Handle with
  `nqp::create(buf8.^pun)`, and this makes everything optimize nicely.		 07:30
rakudo: 252b9349c0 | (Elizabeth Mattijsen)++ | src/core.c/IO/Handle.pm6
Bypass .READ abstraction if we can

If the object is a real, unadulterated IO::Handl, we can bypass the
  .READ abstraction layers. Makes IO::Handle.read(1) about 15% faster
and much more memory friendly.		 08:00
08:03 sena_kun joined 08:04 Altai-man_ left
Geth rakudo: ed936c1435 | (Elizabeth Mattijsen)++ | 7 files
Apply the same buf8.new change to the rest of the core

Not sure how much of this will be noticeable, but it will definitely help a little bit. And every little bit helps.		 08:26
rakudo/match-refactor: 28 commits pushed by (Elizabeth Mattijsen)++
review: github.com/rakudo/rakudo/compare/f...b94b55ab84		 08:30
08:54 JJMerelo left
[Tux] Rakudo version 2020.06-10-g9f546ef6f - MoarVM version 2020.06-14-g5832b2628
csv-ip5xs0.880 - 0.909
csv-ip5xs-208.388 - 8.400
csv-parser25.098 - 29.500
csv-test-xs-200.394 - 0.406
test8.321 - 9.125
test-t1.990 - 2.096
test-t --race0.878 - 0.901
test-t-2035.505 - 37.587
test-t-20 --race9.594 - 10.803
 08:55
09:08 [Tux] joined
Geth rakudo/match-refactor: 5a7cd41a07 | (Elizabeth Mattijsen)++ | src/core.c/Match.pm6
Repurpose $!match flag as capture hash storage location

  - lose one attribute for each Cursor/Match object
  - if the cursor resets $!match, that's fine, will cause re-vivification
  - is nqp::ishash($!match) is true, it has captures in it		 09:08
jnthn lizmat: Looking at ed936c1435, I think new-disp will allow us to do better on dispatch to a pun generally :) 09:21
lizmat I hope so too 09:22
jnthn So we'll be able to make all userspace code doing the same thing faster also (and revert this uglification)
I'd actually thought of it before now, and wondered if it'd be worth it. Guess now I know the answer... :)
lizmat yeah :-)
jnthn Also, even without that, I think it's poorly optimized 'cus of flattening happening in the punning process 09:23
And that suppressing specialization
Which is also not a problem in new-disp
lizmat looking forward to reverting these commits (except maybe 252b9349c0
linkable6 (2020-07-02) github.com/rakudo/rakudo/commit/252b9349c0 Bypass .READ abstraction if we can
jnthn (Because now we pre-flatten)
lizmat I wonder if making a single buf8.^pun and cloning off of it, would even be faster ? 09:24
jnthn We *do* make a single one; it's cached in the meta-object
lizmat yeah, but the ^pun call takes about 1% in the profile of that benchmark now :-) 09:25
jnthn Well, there's the initial cost of making the pun
lizmat actually 2.3%
jnthn And it'll be spread over the rest of the calls, which just check if we have one and return it if so
lizmat yeah, but that'd be a hash lookup, no? 09:26
jnthn I thought it was just an attribute?
$!pun or some such
lizmat ah, ok, cached in that way :-)
jnthn Anyway, in new-disp we could cache the pun in the dispatch program and just have it rewrite the arg list.
lizmat ok, won't touch this anymore then :-) 09:27
jnthn Which is quite neat :)
Anyways, today is for RakuAST... :)
09:30 lichtkind joined 10:02 Altai-man_ joined 10:04 sena_kun left 10:13 travis-ci joined
travis-ci Rakudo build failed. Elizabeth Mattijsen 'Apply the same buf8.new change to the rest of the core 10:13
travis-ci.org/rakudo/rakudo/builds/704237236 github.com/rakudo/rakudo/compare/2...936c1435d6
10:13 travis-ci left
lizmat t/01-sanity/55-use-trace.t fails, cannot reproduce it myself 10:26
Altai-man_ >push_o requires a concrete object (got a ThreadPoolScheduler::Queue type object instead) 10:38
Sounds like a bug. :S
lizmat Altai-man_: how did you get that ?
Altai-man_ lizmat, copied from travis log? 10:39
lizmat ah, ok, I thought you could repro
jnthn Hm, from the messages, could it be a race in thread pool setup somehow? 10:40
lizmat a rare one then, but yes 10:41
Altai-man_ Sounds like something of this level.
If it's rare it doesn't mean there is no bug.
11:02 squashable6 joined
jnthn Uff, quotewords are tricky... 11:03
Might put those off a bit :)
Geth rakudo/rakuast: e1d5734fa2 | (Jonathan Worthington)++ | 4 files
Implement most of post-processing string options

The exception being quotewords, which we can compile into a RakuAST tree, but it doesn't yet know how to compile it to QAST. Also, some of the optimizations are still to come. This is plenty to get us through the 08-var-array.t sanity test, however.		 11:10
jnthn Right, lunch, bbiab
lizmat is confused by: 11:26
Unhandled exception: P6opaque: invalid native bind to attribute '$!pos' in type Match for kind int64
apparently I should use a nqp::bindattr instead of an nqp::bindattr_i ? 11:27
Altai-man_ lizmat, gist.github.com/Altai-man/cecc36d5...bfc4e5806f <- blin 11:33
lizmat Altai-man_++
Geth nqp: 4a62559a68 | (Elizabeth Mattijsen)++ | src/QRegex/Cursor.nqp
Introduce / use !cursor_pass_quick

  - strip out unnecessary functinality
  - use where appropriate		 11:38
rakudo: 6536f8018b | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION
Bump NQP to get the cursor_pass_quick optimization
 11:51
nqp: db0c1088fc | (Elizabeth Mattijsen)++ | src/QRegex/Cursor.nqp
Make sure cursor_pass_quick also reset bstack

Forgot to add that. Was not picked up by any test in NQP or in Rakudo :-( Not sure how to invoke that situation.		 11:57
jnthn lizmat: I don't think it results in wrong behavior, it just increases memory usage. 12:02
So I'd not expect a spectest regression out of forgetting to clear bstack
12:03 sena_kun joined
lizmat but how much extra memory are we talking about then? just for the duration of the parse, I'd hope ? 12:03
12:04 Altai-man_ left
jnthn For the duration of the parse, yes, but if you're parsing a lot and hold on to an extra array that you don't need to for every cursor, it could add up 12:04
Though the secondary effects are also important here 12:05
Longer lifetime = promotion to gen2, where it will also hang around for rather longer
lizmat right, that would match my mental image :-)
Geth rakudo: 682a79646b | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION
Bump NQP again to get proper cursor_pass_quick

One that resets bstack when it can.		 12:07
jnthn decides to get back to package scoping, and to do the remaining quote language bits of RakuAST later 12:10
Currently left with 11 failing sanity tests
Though it turns out that Test.rakumod has evolved quite a bit from the days when "we pass sanity tests" was enough to compile it :) 12:12
Geth rakudo/match-refactor: 30 commits pushed by (Elizabeth Mattijsen)++
review: github.com/rakudo/rakudo/compare/5...66585d6eb5		 12:21
lizmat hmmm... looks like the check for $!bstack is wrong: looks like it is defined just about always, as in an empty BOOTIntArray ? 12:27
jnthn ^^
perhaps it should check if it has any elements ? 12:30
even a regex such as /a/ sets up a bstack of (1,0,0,0) 12:31
jnthn There will always be one, I think 12:33
Unless it's a cursor created by a built-in or something
Which check do you mean, though? 12:34
I mean, you're just nulling it in !cursor_pass_quick, which looks right to me 12:35
lizmat the check in MATCH 12:40
MATCH-CAPTURES actually
github.com/rakudo/rakudo/blob/mast...h.pm6#L142 12:41
so, even on a simple regex such as: 12:42
/a/, the bstack will never be not defined, and thus the cstack and regexsub are being kept around 12:43
jnthn Hm, that's now how I read it 12:45
unless we have a bstack, null cstack and regexsub
nqp::defined could be read nqp::isconcrete
Which is false for null
lizmat I wonder if the cursor_pass logic should do a nqp::setelems($!bstack,0) 12:46
instead of binding it to nqp::null
jnthn No
That is much worse
It doesn't free any memory at all 12:47
s/now/not/ above
It looks correct to me
lizmat if the bstack is *empty*, is it then safe to reset cstack and regexsub ?
jnthn Perhaps not
The logic is: if we threw away the bstack, we know we'll never backtrack into the cursor, so we can also throw away the cstack and regexsub 12:49
If there's a bstack still in place, it was backtrackable, so we should leave the other things in place too, so that backtracking into it would work out
lizmat but why then is there still a $!bstack in the Match object for /a/ ? After it's done matching ? 12:50
and a $!cstack and $!regexsub by consequence ? 12:51
jnthn Because a /.../ form of regex is backtrackable
Granted in this case it's not going to produce anything more if we try
lizmat but a /a/ isn't ?
jnthn No, but we don't analyze it down to that level 12:52
12:52 travis-ci joined
travis-ci Rakudo build passed. Elizabeth Mattijsen 'Bump NQP to get the cursor_pass_quick optimization' 12:52
travis-ci.org/rakudo/rakudo/builds/704286987 github.com/rakudo/rakudo/compare/e...36f8018b2b
12:52 travis-ci left
lizmat ah, but again, that's because we've conflated Cursor and Match :-( 12:52
jnthn rx:r/a/ would know it can throw away the bstack
It ain't, it's because the decision is based on whether the thing being compiled as :r set on it overall, iirc. 12:53
Thus token and rule will always throw it away
Presumably rx:r/.../ also would
lizmat Pro Tip: make your matches less memory hungry by adding rx:r ? 12:54
jnthn Uh, maybe, but how long do you expect to keep the match object around for a simple regex like /a/ ? :)
lizmat well, your concern about filling up the nursery, basically 12:55
jnthn No more than the lifetime of the enclosing routine
That said, I expect that we'll at some point start compiling things as simple as /a/ a bit differently, so they don't pay the whole regex engine setup
Along with various other "easy" cases that have no backtracing
lizmat ack 12:56
brb
jnthn (It's not worth doing that now, though, given the compiler frontend is currently being reworked.)
(And I think it will be easier and cheaper to do these in the RakuAST one.)
12:59 AlexDani` left
nine I get that "push_o requires a concrete object" quite frequently on the OBS and mentioned it on the channel a few times already... 13:10
timotimo and now you've found what causes it? :) 13:13
nine if only :) 13:20
Geth rakudo/match-refactor: ce59121c0e | (Elizabeth Mattijsen)++ | src/core.c/Match.pm6
Add in cstack / regexsub clearing again

  - seems only to occur with ratchet operations
  - according to jnthn, an optimization still worth having		 13:25
timotimo nine: does the error message give you enough information or could something be added? 13:27
lizmat afk for a few hours& 13:28
13:39 travis-ci joined
travis-ci Rakudo build passed. Elizabeth Mattijsen 'Bump NQP again to get proper cursor_pass_quick 13:39
travis-ci.org/rakudo/rakudo/builds/704290727 github.com/rakudo/rakudo/compare/6...2a79646baf
13:39 travis-ci left
nine timotimo: I think --ll-exception would help the most. And after thinking about this for 10 times or so, I've finally done it for all modules in build.opensuse.org/project/show/ho...rakudo-git 13:51
timotimo probably a good idea %)
nine And discovered that I can actually do a single commit from the project directory that covers all individual packages, so I don't even have to commit them individually. Very nice
14:01 Altai-man_ joined 14:04 sena_kun left 14:20 stoned75 left
moritz reminds me of the good[cough] old days of SVN 14:21
14:21 stoned75 joined
timotimo or git superrepo (omnirepo?) 14:27
14:45 AlexDani` joined, AlexDani` is now known as AlexDaniel 14:46 AlexDaniel left, AlexDaniel joined 15:09 dogbert17 left 15:10 Kaeipi joined, patrickb joined
Geth rakudo/rakuast: 48e7886ade | (Jonathan Worthington)++ | src/Raku/ast/base.rakumod
Fix a thinko in check

It failed to pass along the resolve-only flag correctly.		 15:11
rakudo/rakuast: 2c61bd3dde | (Jonathan Worthington)++ | 2 files
Fix implicit declarations handling

We need a non-strict `visit` as well as a strict one to cover the various use cases we have. Also, unwrap a list.
rakudo/rakuast: c36baf5911 | (Jonathan Worthington)++ | 2 files
Be consistent about RakuAST::CompileTimeValue
15:14 [Coke]_ joined, [Coke]_ left, [Coke]_ joined, dogbert17 joined
Geth rakudo/rakuast: 0045d95ca6 | (Jonathan Worthington)++ | 5 files
RakuAST setup of GLOBAL and unit $?PACKAGE

Which means we're now able to have working `our`-scoped variables in a non-EVAL context, at least via the AST.		 15:14
rakudo/rakuast: 86776ae769 | (Jonathan Worthington)++ | 3 files
Do GLOBAL setup in RakuAST-based compiler

Plus prepare the way for some other implicitly declared things.
jnthn Phew.
15:15 tyilanmenyn joined
jnthn Almost passing 05-var.t, but seems there's a silly bug to find yet 15:15
15:15 tyil left
jnthn Ah yes, apparently with statement level block marking 15:16
patrickb nine: Did you see my question here? github.com/Raku/problem-solving/is...-650794395 15:33
Geth rakudo/rakuast: bd6c39d6d3 | (Jonathan Worthington)++ | 2 files
Fill out some more sink/statement marking

Which was why we failed to execute one of the tests in 08-var.t, which now fully passes.		 15:45
15:49 nebuchadnezzar joined
jnthn So...what next... :) 15:56
16:03 sena_kun joined 16:04 Altai-man_ left 16:12 tyilanmenyn is now known as tyil 17:10 softmoth joined
Geth ¦ problem-solving: landyacht assigned to jnthn Issue Exponentiation with Rat or FatRat exponent results in Num github.com/Raku/problem-solving/issues/209 17:21
¦ problem-solving: lizmat unassigned from jnthn Issue Exponentiation with Rat or FatRat exponent results in Num github.com/Raku/problem-solving/issues/209 17:30
17:37 patrickb left 17:40 patrickb joined
Geth rakudo/rakuast: 90ef16e28e | (Jonathan Worthington)++ | 6 files
Foundations for supporting methods (and more)

We want to be able to express RakuAST much like a document - that is to say, a class has methods within it. However, these are not directly held
  (and need not be directly held). Thus there's a need to have them
attached to the appropriate package node ahead of the point we go making the meta-object. A related problem is placeholder parameters, which can ... (13 more lines)		 17:45
lizmat "(The current compiler is broken in this regard, and can go wrong when a 17:50
natively typed attribute comes from a role.)"
Whee!
18:01 Altai-man_ joined
Geth rakudo/match-refactor: 8d10035517 | (Elizabeth Mattijsen)++ | src/core.c/Match.pm6
Make sure that .hash returns a Map, rather than a Hash

This unbreaks Data::Dump, which is expecting .hash to return a Map		 18:04
18:05 sena_kun left 18:56 Merfont joined 18:57 Kaeipi left 19:29 MasterDuke joined
MasterDuke timotimo: i think monorepo is the usual term 19:29
19:30 [Coke]_ is now known as [Coke]
lizmat ok, I believe the final breakage of the match-refactor branch is somehow related of how s/foo/bar/ is codegenned 19:39
what is the reason again that this isn't codegenned as a call to .subst? or have it call a special method that does the matching as well ? 19:41
dogbert17 lizmat: perl6-grammar-prettyerrors fails on both master and your branch so its problems are doesn't seem connected to your branch 19:51
tellable6 2020-06-29T13:28:21Z #raku-dev <tbrowder> dogbert17: thnx
dogbert17 s/are// 19:52
lizmat dogbert17: thanks for the headsup 19:59
dogbert17 I just wanted to check that the commit blin is complaining about wasn't mistakenly commited to master instead of your branch :) 20:00
20:02 sena_kun joined
lizmat dogbert17: could you check that reverting github.com/rakudo/rakudo/commit/01...fe14cd22b0 would solve it ? 20:03
dogbert17 sure
20:05 Altai-man_ left
dogbert17 lizmat: I must have messed something up, it does work on master 20:16
lizmat interesting 20:17
dogbert17 yes, I'm a bit confused now 20:18
I mean if it works why does blin point at a commit which is in master
lizmat i haz no idea
dogbert17 tinkers ... 20:21
lizmat: I seems to me that github.com/rakudo/rakudo/commit/01...fe14cd22b0 is indeed the culprit. 20:26
unless my install is totally busted 20:27
lizmat then I shall revert it and double check
confirm revert fixes it 20:32
dogbert17 cool
Geth rakudo/rakuast: cd90d3b5e5 | (Jonathan Worthington)++ | 7 files
Foundations for supporting methods (and more)

We want to be able to express RakuAST much like a document - that is to say, a class has methods within it. However, these are not directly held
  (and need not be directly held). Thus there's a need to have them
attached to the appropriate package node ahead of the point we go making the meta-object. A related problem is placeholder parameters, which can ... (13 more lines)		 20:42
jnthn (an amend 'cus I forgot a file, probably 'cus I was rushing off to cook dinner... :)) 20:46
Geth rakudo: c7c18c2141 | (Elizabeth Mattijsen)++ | src/core.c/Grammar.pm6
Revert "Give Grammar its own .new"

This reverts commit 0144905fb0e1de372ffbf6c8a01d3efe14cd22b0.
This seems to cause more issues than it is fixing.		 20:51
lizmat dogbert17: Grammar::PrettyError still borked on the match-refactor branch 20:55
but differently 20:57
21:00 MasterDuke left
dogbert17 lizmat: interesting 21:25
I believe that DOM::Tiny also has problems 21:26
lizmat ok, looks like the revert is related to what I'm seeing now
looks like a grammar with its own attributes *and* defaults, is not getting its attributes default values set 21:27
I will mull over that tonight, and look again with a fresh mind tomorrow
sleep&
dogbert17 sounds like a plan
lizmat :-) 21:28
21:56 lichtkind left 21:57 [Coke] left 22:01 Altai-man_ joined 22:05 sena_kun left 22:34 [Coke] joined, [Coke] left, [Coke] joined 22:37 squashable6 left 22:41 squashable6 joined 23:12 patrickb left 23:30 AlexDaniel left 23:51 AlexDaniel joined, AlexDaniel left, AlexDaniel joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!