00:02 reportable6 left 00:35 Xliff joined 00:55 frost joined 01:04 reportable6 joined 01:12 rakuUser left 02:12 bloatable6 left, squashable6 left, sourceable6 left, coverable6 left, reportable6 left, quotable6 left, nativecallable6 left, greppable6 left, benchable6 left, linkable6 left, notable6 left, statisfiable6 left, committable6 left, tellable6 left, bisectable6 left, shareable6 left, releasable6 left, unicodable6 left, evalable6 left, committable6 joined 02:13 nativecallable6 joined, greppable6 joined, quotable6 joined, tellable6 joined, benchable6 joined 02:14 linkable6 joined, squashable6 joined, notable6 joined, evalable6 joined 03:14 bisectable6 joined, shareable6 joined, coverable6 joined 03:15 reportable6 joined, sourceable6 joined 04:03 discord-raku-bot left 04:04 discord-raku-bot joined 04:15 unicodable6 joined, bloatable6 joined 05:13 Xliff_ joined, statisfiable6 joined 05:17 Xliff left 06:02 reportable6 left 06:03 reportable6 joined 06:13 releasable6 joined 08:05 linkable6 left, evalable6 left 08:28 patrickb joined
patrickb o/ 08:28
Can someone remove the Raku Con banner from raku.org? 08:29
09:20 lizmat_ joined, lizmat_ left, lizmat_ joined 09:23 lizmat left, TempIRCLogger left 09:24 lizmat_ left 09:28 lizmat joined 09:29 TempIRCLogger joined 10:07 linkable6 joined 10:08 evalable6 joined
nine Oh darn. Setting RAKUDO_MAX_THREADS to anything doesn't have any effect. Why? Because we create the ThreadPoolScheduler object during the settings compilation. 10:13
MasterDuke doh! 10:16
lizmat ?? I think it is set during execution ?
are you saying it gets serialized ?
nine Apparently so. As can be seen by the absence of any "Created scheduler" message, when run with RAKUDO_SCHEDULER_DEBUG=1 10:22
lizmat wow
that's bad, I'd say?
but but the settings compilation doesn't do any shelling or start or anything async that I know of? 10:23
nine Indeed. github.com/rakudo/rakudo/blob/mast...ue.pm6#L82 10:24
lizmat WOT 10:28
nine One can work around this somewhat with PROCESS::<$SCHEDULER> = my $*SCHEDULER = ThreadPoolScheduler.new(:max-threads(4)); 10:30
lizmat but, that's execution, is it not ?
nine The documented way of just setting $*SCHEDULER is not enough
But I still get the impression that 2 schedulers are active
yes, I put that line into our service.pl6 10:31
MasterDuke greppable6: ThreadPoolScheduler
greppable6 MasterDuke, 16 lines, 7 modules: gist.github.com/0733e291bae1725288...c9d3dca659
MasterDuke greppable6: SCHEDULER
greppable6 MasterDuke, 192 lines, 18 modules: gist.github.com/482740f5bdbb598506...9297e17f86
10:56 squashable6 left 11:06 sena_kun joined 11:49 lizmat left 11:50 lizmat joined, lizmat left 11:51 lizmat joined 11:53 TempIRCLogger left 11:54 lizmat left, lizmat joined 11:55 TempIRCLogger joined 12:03 reportable6 left, reportable6 joined
Geth rakudo: b14d404a19 | (Elizabeth Mattijsen)++ | 2 files
Make the default scheduler see RAKUDO_MAX_THREADS

Not sure why it wouldn't see this otherwise, as the other settings
  *are* apparently seen correctly. Assume it is some weird bootstrap
issue at process startup.
12:21
MasterDuke looks like a space was accidentally moved from github.com/rakudo/rakudo/commit/b1...630bc7L807 to github.com/rakudo/rakudo/commit/b1...b10bd252R1 12:25
12:29 patrickb left 12:39 patrickb joined 12:42 AlexDaniel left 12:45 AlexDaniel joined
MasterDuke given that coercion parameters are so slow, should they be used in the core setting? 12:59
e.g., github.com/rakudo/rakudo/blob/mast...tr.pm6#L52 13:00
m: use nqp; class A { has str $!value; submethod BUILD(Str() :$value = "" --> Nil) { nqp::bindattr_s(self, A, q|$!value|, nqp::unbox_s($value)) }; method Str(A:D:) { self }; }; my $a; $a := A.new(:value($_)) for ^1_000_000; say now - INIT now; say $a
camelia 1.684516707
A.new
MasterDuke m: use nqp; class A { has str $!value; submethod BUILD(:$value = "" --> Nil) { nqp::bindattr_s(self, A, q|$!value|, nqp::unbox_s($value.Str)) }; method Str(A:D:) { self }; }; my $a; $a := A.new(:value($_)) for ^1_000_000; say now - INIT now; say $a 13:01
camelia 1.033107545
A.new
13:06 rakuUser joined 13:19 Xliff_ left 13:29 Xliff joined 13:37 frost left
lizmat MasterDuke: that would only apply to someone doing Str.new 13:45
which not many people are ?
but yeah
going afk now&
MasterDuke yeah, github.com/rakudo/rakudo/blob/mast....nqp#L1345 is the only place i found so far 13:46
but that was really just one specific example 13:47
greppable6: Str.new 13:54
greppable6 MasterDuke, 88 lines, 13 modules: gist.github.com/5aa8d642fb3eaa0db5...9679366c5c
14:15 b2gills left, b2gills joined
Geth nqp/new-disp: 65d7bb8592 | (Jonathan Worthington)++ | 2 files
Add nqp-istype dispatcher

Which will be used when we can't resolve an istype using the type check cache. This follows the current semantics of nqp::istype(...), although we may want to revisit this in the future.
14:17
rakudo/new-disp: 5d6a45cec8 | (Jonathan Worthington)++ | src/Perl6/bootstrap.c/BOOTSTRAP.nqp
Register nqp-istype dispatcher for Raku also

We'll write a Raku-specific one at some point since we can likely rewrite some type checks (for example, on definedness types) into simple dispatch programs. For now, this will keep things working as MoarVM moves istype over to using a dispatcher for the fallback cache-mess case.
14:18
rakudo/new-disp: 8c8c91cc71 | (Jonathan Worthington)++ | src/Perl6/Metamodel/MROBasedMethodDispatch.nqp
Cease publishing legacy method cache on MoarVM
14:36
nqp/new-disp: 2470be00cc | (Jonathan Worthington)++ | 4 files
Cease publishing legacy method cache on MoarVM
14:42
MasterDuke this wasn't a completely rigorous benchmark, but changing github.com/rakudo/rakudo/blob/mast...m6#L52-L54 from `submethod BUILD(Str() :$value = '' --> Nil) { nqp::bindattr_s(self, Str, '$!value', nqp::unbox_s($value)) }` to `submethod BUILD(:$value = '' --> Nil) { nqp::bindattr_s(self, Str, '$!value', 14:49
nqp::unbox_s($value.Str)) }` seemed to bring stage parse from ~42.5s to ~42.0s
Geth nqp/new-disp: f46dae9f6c | (Jonathan Worthington)++ | src/core/dispatchers.nqp
Fix a typo
14:52
Kaiepi MasterDuke, is the read of @!concretizations relevant to the lock in Metamodel::Concretization.'!maybe_rebuild_table'? 15:03
MasterDuke not sure what you mean. which read? 15:11
Kaiepi if nqp::elems(%new_conc_table) < nqp::elems(@!concretizations) 15:13
i think there's a way to make it more sparing with the nqp::objectid calls, just how it would be done depends on where that condition needs to be 15:15
vrurg Kaiepi: it is now me missing the point. How could objectid replace number of elements? 15:19
MasterDuke: a side note. There is another potential race we've missed in Concretization.add_concretization method. Resetting of %!conc_table is not protected. This may result in delayed cache update if %new_conc_table gets assigned too early. I'll try to remember to take care of this when done with pseudos. 15:26
Kaiepi because %new_conc_table is a clone of %!conc_table, it already has each of the concretizations that existed in the prior call to !maybe_rebuild_table. with the size of the clone, you get the starting position of any newly added concretizations in @!concretizations, since those can only be appended 15:28
the resetting of %!conc_table can go that way 15:29
Geth rakudo/new-disp: d15098d850 | (Jonathan Worthington)++ | 2 files
Remove meth cache auth op uses on MoarVM
15:30
nqp/new-disp: 9c64b44e04 | (Jonathan Worthington)++ | 2 files
Remove method-cache related ops on MoarVM
Kaiepi if that condition doesn't need to be protected, then the lock can be skipped when no update is needed
resetting from add_concretization, i mean 15:33
15:36 patrickb left
Geth rakudo/new-disp: 080c43425a | (Jonathan Worthington)++ | 2 files
Update p6invokeunder to use MVM_frame_dispatch

Its ultimate destiny is to go away, as it's a quite terrible hack; that can happen when we make the final push to eliminate the extops as a whole.
15:52
16:57 squashable6 joined 17:22 rakuUser left 17:32 rakuUser joined
Geth rakudo/new-disp: e109bf0e06 | (Jonathan Worthington)++ | 3 files
Replace p6getouterctx with dispatcher + syscall
18:00
18:02 reportable6 left 18:36 sena_kun left 18:38 SmokeMachine__ left, SmokeMachine__ joined
Geth rakudo: 94462dfab8 | (Elizabeth Mattijsen)++ | src/Perl6/Grammar.nqp
Remove use of Str.new from grammar

  FROGGS added this in 2014, when perhaps this was needed because of
Parrot. Removing it completely and just using whatever self.orig gives us, does not break any spectest, nor does it inhibit installing slangs like Slang::Tuxic or Slang::Piersing.
So I assume this was really an old wart, which is now gone. Should a blin run show that this *did* break something, then just revert this.
19:10
lizmat MasterDuke ^^ 19:11
MasterDuke ha, nice 19:16
huh. inspired by ^^^ to try and make $!orig here github.com/Raku/nqp/blob/master/sr...sor.nqp#L4 a str, but it turns out it's specced to not always be a string github.com/Raku/roast/blob/master/...ject.t#L89 19:55
vrurg Kaiepi: it was a hash-updating algorithm initially. But there was something broken about it and I had to switch to run-time update with resetting. Though a lot has changed in moar since then, perhaps it would make sense to try it again.
lizmat MasterDuke: when is it not a string? 19:57
MasterDuke m: say 12345 ~~ /2../ 19:58
camelia 「234」
MasterDuke it's an Int there
lizmat isn't that a string that can be an Int ? 20:01
MasterDuke i'd say it's an Int that can be a string
12345 by itself is an Int 20:02
lizmat yeah, but the smartmatch works on "12345"
it can not work on the Int
MasterDuke m: say "src/Perl6".IO ~~ /6/; say $/.orig.WHAT 20:03
camelia 「6」
(Path)
MasterDuke after my change the .WHAT is `(Str)`
20:04 reportable6 joined
MasterDuke m: Str.can('split') ~~ /split/ # another breaking change (so far, haven't tried to fix yet), i get 'This type cannot unbox to a native string: P6opaque, Method' 20:07
camelia Method object coerced to string (please use .gist or .raku to do that)
in block <unit> at <tmp> line 1
MasterDuke m: use Test; ok Str.can('split') ~~ /split/ 20:08
camelia Method object coerced to string (please use .gist or .raku to do that)
in block <unit> at <tmp> line 1
ok 1 -
Geth rakudo: 3aba97077b | (Elizabeth Mattijsen)++ | src/core.c/Promise.pm6
Save 2 Scalar containers per Promise.new

GC runs from 18 -> 14 for Promise.new for ^50000
No change for subclasses of Promise
20:18
MasterDuke that can probably be fixed relatively easily, but the Str vs whatever-type-the-object-actually-is case is a change in spec
lizmat yeah, reminds me of my Match refactor work :-(
[Coke] does t/02-rakudo/18-pseudostash.t fail everywhere or just on my machines? 20:24
(windows, os x)
lizmat does not for me on master 20:26
MacOS
MasterDuke nor for me on master/linux 20:40
Geth rakudo/new-disp: bade712274 | (Jonathan Worthington)++ | 3 files
Unwrap Code outside of p6setfirstflag

So that it doesn't need to do it inside of the op, removing one more place that we rely on the legacy invoke spec.
20:45
rakudo: 3c1c709cea | (Elizabeth Mattijsen)++ | src/core.c/Promise.pm6
Make allocations of Promise.thens list lazy

Saves one BOOTArray allocation for each Promise.new that doesn't do any .then.
20:47
japhb Loving the Promise improvements, lizmat++. What triggered this? And are you planning to attack any of the other concurrency classes? :-) 20:53
gfldex lizmat: that improvement might pay of later :->
Xliff japhb: How many Promise improvements (actually, this might be better for lizmat) 20:54
Hmm... git log --grep=Promise?
lizmat: Actually....after reading, I definitely agree with japhb!\ 20:57
japhb Xliff: She's done optimization passes of the scheduler and such in the past, but when I saw the drop in GC runs from Promise building earlier today, I got excited. :-)
Xliff I've just started using Promises in earnest, so I'm happy to see these. 20:58
m: my $p = Promise.new; Promise.in(5).then: { $p.keep }; react { whenever $p { done } } 20:59
camelia ( no output )
Xliff Basic react with a time limit.
MasterDuke Xliff: btw, istr that nine++ made a bunch of moarvm improvements on master recently that might help your usecase (i.e., large projects with lots of dependencies). have you noticed any changes? 21:04
japhb m: react whenever Promise.in(5) { say "done!"; done }
camelia done!
japhb Xliff: ^^ Simplified
Xliff MasterDuke: You mentioned that, before. Is that for precompilation or recompilation. 21:11
I have not been noticing much in the way of precompilation improvements? If there have been any, they've been eaten up by other things. 21:12
MasterDuke whoops, forgot i'd mentioned it. i'm not 100% certain, but i think mainly (re)compilation
Xliff Please see recent timings: github.com/Xliff/p6-GLib/blob/mast...ounts.xlsx 21:13
Check the "Regular Timings" tab
MasterDuke: Yeah, I don't have any baseline to test (re)compilations against./
Although I might want to have both of you check out the slowness of github.com/Xliff/p6-X11 21:14
Particularly Display.pm6
It's slow. It acts as if "no precopilation" has been issued.
MasterDuke i think it's a little late for nine to be online, but i'll mention it next time i see him in a channel 21:17
just clone and run build.sh?
no meta6.json?
21:29 rakuUser left 21:43 MasterDuke left
[Coke] rebuilt, still getting the error on t/05-messages/02-errors.t 21:44
japhb When your own code doesn't even appear on the first *page* of exclusive-sorted profile output, sorting by entries (total call count) puts the bootstrap and setting in the top slots, and inclusive time shows nothing but concurrency code ... >.< 21:46
[Coke] ww 21:47
japhb Even on a per-call basis, a naive reading would indicate that *by far* the slowest routines are in the scheduler. Which I'm guessing most likely means that's an area that the profiler doesn't have enough visibility into. :-( 21:52
japhb rages against his machine for a bit 21:53
Is there a way to "name" an anon block so that it appears as such in the profile data, but without causing a performance difference? I finally found a view on the SQL profile that was actually showing me heavy bits of my own code, and it was mostly anon blocks. 21:58
Also, is there any way to see when a Raku problem is suffering lock or queue contention? 21:59
*program
22:15 rakuUser joined 22:19 rakuUser left, rakuUser joined 22:49 MasterDuke joined
MasterDuke japhb: perf maybe? 22:49
japhb MasterDuke: Hmmmm. Any guidelines on using that with Rakudo? 22:54
MasterDuke i use `MVM_JIT_PERF_MAP=1 perf record -z -g --call-graph dwarf raku <...>` 23:22
and then `perf report --call-graph=none --no-children` 23:32
japhb Why use --call-graph on the record and --call-graph=none on the report? 23:49