sjn just read about Jeff :-( :-( 00:28
MasterDuke pmurias: since github.com/rakudo/rakudo/pull/3533 helps some circumstances, but was reverted because it slowed down a spectest, maybe just updating the type (and also hopefully method) cache instead of publishing an entire new one would better 08:24
pmurias: unless of course there's a better way to publish those caches in the first place that helps that example code 08:25
or republish in a better way than my PR 08:30
[Tux] MasterDuke, 10_000 lines with 5 fields each 10:16
lizmat MasterDuke: it didn't slow down a specific spectest, it slowed down "make spectest" by almost 10%
MasterDuke: if it had been a single spectest, we would have a target to look at and I wouldn't have reverted 10:17
Files=1305, Tests=111216, 205 wallclock secs (27.96 usr 8.26 sys + 2890.06 cusr 269.86 csys = 3196.14 CPU)
feels like this 1 wallclock less is a fluke, as the CPU is nearly unchanged
nine MasterDuke: it's not entirely clear that updating a type cache would be faster than publishing an entirely new one. Replacing the type cache can be done by a simple pointer assignment which is thread safe. If the cache can be updated in place, making it thread safe without locking is much harder 10:24
[Tux] Rakudo version 2020.02.1-183-g70ac9b72e - MoarVM version 2020.02.1-45-g2252a95df
csv-ip5xs0.696 - 0.701
csv-ip5xs-205.907 - 6.079
csv-parser23.977 - 24.604
csv-test-xs-200.371 - 0.372
test8.228 - 8.285
test-t1.912 - 1.927
test-t --race0.948 - 0.977
test-t-2031.881 - 31.940
test-t-20 --race9.514 - 9.902
 10:28
MasterDuke lizmat: yeah, that's what i meant (and assumed you meant), just wasn't very precise in what i said 10:34
lizmat ok... just wanted to make sure we're on the same page :)
MasterDuke nine: true. i guess it keeps coming back to finding the right time/place to (re)publish. i just haven't figured out that where/when yet 10:35
lizmat: no worries, if i had noticed that slowdown myself it would have given me pause 10:36
Geth rakudo: f9ecf6e8a4 | (Elizabeth Mattijsen)++ | src/core.c/Dateish.pm6
Save upto 2 allocations per Date/DateTime.yyyy-mm-dd

  - and dd-mm-yyyy and mm-dd-yyyy friends
  - 1 Int allocation if month > 9
  - 1 Int allocation if day > 9
For some reason, *in the core setting*, having a native int attribute ... (6 more lines)		 10:41
MasterDuke lizmat: if it is actually a native int you have, why not nqp::coerce_is? i would think that'd be faster than nqp::tostr_I 10:48
lizmat hmmm 10:49
MasterDuke tostr_I is just coerce_Is 10:50
Geth rakudo: 6d146b564a | (Elizabeth Mattijsen)++ | src/core.c/Buf.pm6
Make Blob.list non-lazy

Since apparently the Blob.list *must* be a list to not explode in hypers, there is little point in adding Seq overhead masked in a
  .cache. So just build the list at once, and return that. This
could have some (positive) performance impact.		 11:44
lizmat jnthn: I wonder if it would make sense to have an nqp::op that converts a nqp::list_i to a nqp::list 11:46
*or* that we should allow a list_i to be the reified of a List 11:47
in which case the above code turned into a simple nqp::p6bindattrvinres
sena_kun .tell rba hi! Can you please install perl-dev (or how is it called) to the blin server, so -lperl flag was supported to build Inline::Perl5 there? 11:52
tellable6 sena_kun, I'll pass your message to rba
Geth rakudo: aed658d6f2 | (Elizabeth Mattijsen)++ | src/core.c/Buf.pm6
Remove unneccesary Blob:U.elems candidate

This is already handled by Any:U.elems		 12:21
lizmat m: dd Hash.^methods.grep( *.name eq "STORE") # this surprises me a bit, since the Hash proto should mask the Map proto? 13:18
camelia (proto method STORE (Hash: |) {*}, proto method STORE (Map:D: |) {*}).Seq
jnthn lizmat: But .^methods asks for all of the methods up the hierarchy 13:24
So you see overridden ones too
lizmat m: dd Hash.^methods(:!all).grep( *.name eq "STORE") # this surprises me a bit, since the Hash proto should mask the Map proto?
camelia (proto method STORE (Hash: |) {*}, proto method STORE (Map:D: |) {*}).Seq
lizmat m: dd Hash.^methods(:local).grep( *.name eq "STORE") 13:25
camelia (proto method STORE (Hash: |) {*},).Seq
lizmat ah, ok, I misgrokked the meaning of the :$all parameter I guess 13:26
m: dd CORE::.keys.grep( { /^"&"<[A..Z]>/ } ).elems # number of user visible / callable subs in *any* program that are an implementation detail 13:27
camelia 71
Geth rakudo: e152aa6af0 | (Elizabeth Mattijsen)++ | 7 files
Remove unnecessary implementation detail

  &CMP-SLOW somehow lived in the SETTING:: but didn't need to. Move
it inside the infix:<cmp> that needs it and adapt the keys tests accordingly.		 14:27
MasterDuke vrurg_: could github.com/MasterDuke17/rakudo/blo...#L700-L712 be adapted to also work on takenextdispatcher? 16:00
Geth rakudo: b639221dd7 | (Elizabeth Mattijsen)++ | 8 files
Remove unnecessary implementation detail

  &GENERATE-ROLE-FROM-VALUE somehow lived in the SETTING:: but
didn't need to. Move it to Rakudo::Internals and adapt the code and the keys tests accordingly.		 16:24
stoned75 hi! 18:23
is it me or something is broken between raku/doc github repo and circleci ? 18:24
from github.com/Raku/doc/pull/3267 the link circleci.com/gh/Raku/doc/434?utm_c...build-link gives a 404 error 18:25
Geth rakudo: 86bc3b3d29 | (Elizabeth Mattijsen)++ | 7 files
Remove unnecessary implementation detail

  &INITIALIZE-A-DISTRO-NOW somehow lived in the SETTING:: but
didn't need to. Move it to inside the $*DISTRO initialization logic and adapt the keys tests accordingly.		 18:58
vrurg MasterDuke: it already takes care of takenextdispatcher. 19:04
Geth rakudo: 75f34c52c5 | (Elizabeth Mattijsen)++ | 7 files
Remove unnecessary implementation detail

  &MD-HASH-SLICE-ONE-POSITION somehow lived in the SETTING:: but
didn't need to. Move it to inside the &postcircumfix:<{; }> logic and adapt the keys tests accordingly.		 19:20
leont Funny how I could guess who wrote those commits from the title alone :-p 19:21
MasterDuke vrurg: ah, i didn't look closely enough, nice 19:37
vrurg MasterDuke: register_takedispatcher is involved. 19:38
leont Being a cleaner is a calling :-)
sena_kun raku --target=parse -e 'use v6;' gives me `- statementlist: ;` 19:58
that's... odd?
while e.g. raku --target=parse -e 'use MONKEY-SEE-NO-EVAL;' is cool, `statementlist: use MONKEY-SEE-NO-EVAL;` 19:59
I understand there is a special treatment for language version at the beginning
what I don't understand is this odd `;` statementlist after one
vrurg sena_kun: it doesn't result in anu QAST. 20:00
*any
sena_kun vrurg, hmm, so lang-version is "saved" separately from the AST and AST is like "nothing-nothing semicolon"? 20:01
sigh, that's troublesome 20:02
vrurg sena_kun: I'm not sure what exactly parse target returns (sorry), but lang-version token doesn't produce a statement. It only prepares compiler and sets the outer core. 20:03
Related locations in the source: token lang-version in Grammar, method lang-version in Actions, comp_unit_stage0/1 in World. 20:04
sena_kun yeah, looking there, thanks for points!
vrurg My wild guess would be that parse target returns what you get from statementlist token which follows lang-version in comp_unit. 20:05
MasterDuke jnthn: how can we know whether a block with a param is actually safe to inline? or, what needs to be done to the block/param to make it so? 20:17
jnthn MasterDuke: Dunno, it's all a bit tricky, 'cus the QAST::Var param will have to be transformed into something else, and then there's the whole "what about the type checks" question... 20:22
(Of course, we can start off restricting it to untyped)
MasterDuke ah. sounds like maybe i just punt... 20:23
jnthn I'm not sure, off the top of my head, how best to do it...
Or whether code-gen (at the QAST compiler level) changes could make it a lot easier, or if there's a good way without that 20:24
MasterDuke heh, i thought maybe it'd be a quick diversion, but it's not looking so promising now 20:25
but backing up to yesterday and type/method caches, do you have a suggestions as to where to look for better (re?)publishing them? 20:26
jnthn I'm still not clear why compose isn't the right place. 20:27
Or rather, why the publishing of them in compose ain't happening
I'll try and have a dig into it tomorrow. I've had a glance at if it's anything obvious but it ain't.
Well, not to me... :)
MasterDuke cool 20:28
thanks
Geth rakudo: ffad102453 | (Patrick Böker)++ | 3 files
Move RUN_CLEAN_TARGET_FILES to separate script

And clean up the logic a lot. The way it looked before it was probably broken in multiple ways:
  - PERL6 and PERL6_DEBUG were never deleted, the line was missing a folder.
  - The 'verbose' logic didn't work. There is no 'verbose' variable specified
   anywhere.		 22:24
rakudo: 8ae2106f15 | (Vadim Belman)++ (committed using GitHub Web editor) | 3 files
Merge pull request #3536 from patrickbkr/run-clean-target-files-script2

Move RUN_CLEAN_TARGET_FILES to separate script
patrickb .tell rba I uploaded rakubrew v6 (patszim.volans.uberspace.de/patclo...LQDZcjbf). Upload at your convenience. :-) 23:42
tellable6 patrickb, I'll pass your message to rba
patrickb .tell rba Also I have a new version of the rakubrew.org website. Can you bump that? 23:43
tellable6 patrickb, I'll pass your message to rba

Powered by Cro and the Raku® Programming Language.

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

Thank you!