Geth rakudo: ugexe++ created pull request #6283:
RakuAST: Don't warn that a sunk {*} is a useless use		 00:05
rakudo: ugexe++ created pull request #6283:
RakuAST: Don't warn that a sunk {*} is a useless use
00:26 [Coke]_ joined
ugexe ➜ ~ raku -e 'my %TO=(a=>0,b=>1); say all("a","b") ~~ %TO;' 00:26
True
➜ ~ raku --optimize=off -e 'my %TO=(a=>0,b=>1); say all("a","b") ~~ %TO;'
False
the above has nothing to do with RakuAST
but RakuAST will presumably only want to do one of those 00:27
00:29 RakuIRCLogger left, [Coke] left
[Coke]_ up to 120 files. 00:44
00:44 [Coke]_ is now known as [Coke]
[Coke] really sticking to about 10% - 120/1128/2462 00:46
Geth rakudo: ugexe++ created pull request #6284:
RakuAST: Allow adverbs on user-defined terms		 01:59
ugexe m: run $*EXECUTABLE, q|-e|, q|given 99 { say 14 ~~ $_ }|; BEGIN %*ENV<RAKUDO_RAKUAST> = 1; 03:12
camelia True
ugexe m: run $*EXECUTABLE, q|-e|, q|given 99 { say 14 ~~ $_ }|;
camelia False
ugexe caused by github.com/rakudo/rakudo/commit/790c7ac94 and breaks JSON::Schema
Geth rakudo: ugexe++ created pull request #6285:
RakuAST: Register a Label's meta-object in the SC at declaration		 03:39
rakudo: ugexe++ created pull request #6286:
RakuAST: Also declare ::?PACKAGE at the compunit mainline		 03:55
ugexe [DAWG] # Failed test 'Memory-mapped load is very fast (<100ms, actual: 247.26ms)' 04:00
:/
Geth rakudo: ugexe++ created pull request #6287:
RakuAST: Allow an anonymous package inside a role		 04:11
06:05 finanalyst joined 08:25 jdv left 08:26 jdv joined
timo ugexe: it sounds like the behaviour of rakuast is correct there? that's at least what the commit you linked to seems to suggest, or i'm reading it wrong 09:15
10:17 finanalyst left 11:20 apogee_ntv joined
ugexe I’m not weighing in on if it’s correct or not. If it is correct though json schema needs to be fixed (in a way that works on both frontends) 12:59
13:01 vrurg_ joined 13:03 vrurg left
[Coke] up to 290 fails, repo updated. 15:12
we're at ⏳ 2142 out of 2462 modules processed (87%) 15:13
up to 13.5% failures.
ugexe if it cant install a dependency for something does it count as a failure? 16:42
[Coke] Yes. 16:49
so the actual number of *issues* may be much lower.
happy to do another blin ast run once we have some of those PRs merged. 16:50
(can also do a limited run if we want to check a few that we know were impacted by a fix) 16:52
🥞🥞🥞 Testing Humming-Bird for flappiness 17:54
:sensible chuckle:
timo who wants to have a look at a profile with GC orchestration related events as markers and CPU samples otherwise? share.firefox.dev/4xAUUyb
I'm thinking something like this could show situations like few threads having to do boatloads of GC work while a whole bunch of threads are sleeping/waiting 17:56
the `add_work` marker happens when a thread steals work from another thread 17:57
but a thread always also calls it on itself 17:58
I find it interesting to see the supervisor thread from the thread pool, it's marker chart is full of marking the thread blocked and unblocked, which are the sleeps, but sometimes there are holes, which presumably is having to wait for GC to finish after waking up from the sleep 18:01
Geth rakudo/lizmat-21: 06ac28c1e7 | (Elizabeth Mattijsen)++ | src/core.c/Dateish.rakumod
Also add a Date/Datetime.mm-dd method

This is about 3x as fast as the equivalent .yyyy-mm-dd.substr(5)		 18:06
[Coke] What's the purpose of these? Are these common enough to warrant a fast method in core? 18:08
timo hum. do we ever have any not-the-coordinator threads steal work from blocked threads? 18:12
lizmat [Coke]: for any large set of data you may want to classify / categorize by yyyy-mm or mm-dd 18:17
timo looking at one spot that looks like a major collection and it really does look like only one thread is actually doing anything for the vast majority of the time
lizmat timo: my experience with ParaSeq taught me it's sometimes pretty hard to engage more than a single thread 18:18
timo then a bunch of threads join in to do `finish_gc` to do "free unmarked" and such, and the coordinator thread spends a lot more time doing basically that
lizmat: you mean just as a general observation of multi-processing? 18:19
lizmat as a general observation of ThreadPool behaviour from my POV 18:20
timo because yeah, that's a valid observation for almost everything
lizmat what's happening under that, is usually above my paygrade :-)
timo do you happen to know how much time tends to be spent stopped in GC for those workloads? 18:23
the good thing is, when you have a whole bunch of threads actually actively doing work, they can also join in on GC, so no need for the coordinator thread to steal all these threads' work 18:24
[Coke] ugexe: the overview file has information about AlwaysFail, OK, MissingDependency, etc. 18:27
there are 191 "Unknown" so far which don't have any output files to review. 18:28
I didn't save a copy from the last blin run to compare numbers with, whoops
20:48 RakuIRCLogger joined
Geth rakudo/main: 48ccbea733 | (Elizabeth Mattijsen)++ | src/core.c/Rakudo/Internals/JSON.rakumod
Remove some stray .perl method calls
 21:37
rakudo: ugexe++ created pull request #6289:
RakuAST: Allow a nested-scope constant to shadow an outer one		 22:03
rakudo: ugexe++ created pull request #6290:
RakuAST: Keep every post-constraint on a parameter
rakudo: ugexe++ created pull request #6291:
RakuAST: Don't compose a class whose body fails to begin		 22:04
[Coke] ugexe: are all these coming from blin related findings? 22:07
or were some in the queue already?
ugexe yeah they are all from blin stuff 22:08
[Coke] \o/ 22:10
ugexe i've admittedly been cherry picking ones i can tell will be trivial 22:11
[Coke] hey, number go up 22:20
Geth rakudo: ugexe++ created pull request #6292:
RakuAST: Compile a package-qualified compile-time variable		 23:10

Powered by Cro and the Raku® Programming Language.

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

Thank you!