02:38 librasteve_ left 08:57 sena_kun joined
timo has anyone used Grammar::Debugger or Grammar::Tracer recently? 10:33
lizmat about a year ago, when I started the =rakudoc handling, why ? 10:47
did it bitrot?
notable6: weekly 10:48
notable6 lizmat, 1 note: 2024-12-10T12:59:58Z <antononcube>: rakuforprediction.wordpress.com/20...aku-set-3/
lizmat notable6: weekly reset
notable6 lizmat, Moved existing notes to “weekly_2024-12-23T10:48:43Z”
timo i'm not entirely sure. i seemed to recall it didn't work when i last tried it? two months ago or so maybe 10:49
lizmat It's a Raku Community module now 10:52
so go for it :-)
I can give you a zef upload bit if necessary 10:54
timo i kind of wish we had a common standard way for module authors to put benchmarks in their distros, maybe in xt/, for the purposes of measuring long-time changes in rakudo and moarvm performance 11:04
so we could do something similar to a blin run, but for benchmarks found in ecosystem modules 11:05
lizmat bt/ ? 11:06
timo .o( backtraces ) 11:07
lizmat I was thinking "benchmark tests" 11:12
timo what i'd like to see at the very least is standardised ways to handle setup and teardown, and a way to specify size of the "workload" to check how scaling behaves, and maybe a rough guideline to create essentially an estimation for what workload size corresponds to what run time. also it'd be important to consider multithreading and multi-processing in this, as well as necessary external
components. say, a postgres database has to be running in order to sensibly benchmark a postgres client library, i imagine
and we probably want to measure some performance counters instead of wallclock time, since other activity on the system that runs the benchmark can easily make timing data become worthless :) 11:31
lizmat in that respect I would love to see cpu time / thread metrics 11:33
timo most performance counters can be impacted by other stuff on the system; i think if there's more load, the program may be context-switched away more often, CPU caches evicted causing an increase in cache misses, stuff like that :| 11:35
i guess if we have to ensure whatever the "benchmark runner" is doesn't get distracted :) 11:36
then we can also use cpu time for measurement
lizmat and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2024/12/23/2024-...-the-dots/ 11:57
patrickb I've used Grammar::Tracer recently when creating Rainbow. worked like a charm. 13:06
timo oh, ok that's good! 13:07
lizmat ab5tract: I wonder whether we should allow "is revision-gated" as well, indicating the lowest language level being supported 16:04
ab5tract That’s how I originally implemented it but nine didn’t like that 16:08
lizmat ah, ok :-)
timo it was denined 18:07
lizmat aaw! 18:31
timo lizmat: do you know how to trigger the "exception doesn't have a serialization function" error?
lizmat I do not
Ah, I do 18:34
timo i've been trying a few things with no luck
lizmat put this in a module, and use that module: 18:35
my constant $a = do { my $e; CATCH { $e := $_; .resume } die; $e }
my constant $a = do { my $e; CATCH { $e := $_; .resume }; die; $e }
timo my code also dies when the exception has no message so i'd want to put `die "argh!";` 18:40
(but i'm also fixing that problem)
lizmat golf: my constant $a = do { try die; $! } 18:41
timo hm, i get "no message" even with `die "blergh!"` i wonder why that is 18:45
ok, cool. give my moar branch a shot, will you? :) 19:00
Geth rakudo/ugexe/deprecate-multi-file-operations: 1d2a5670d6 | (Nick Logan)++ | 3 files
Deprecate IO subs that operate on multiple paths in 6.e

While convienient, being able to pass multiple paths to e.g. &rmdir is problematic because there isn't a blessed way to handle what to do when an exception or failure occurs, i.e. should it try to rmdir every entry even if some things fail, or stop on the first failure?
... (10 more lines)		 19:21
lizmat bisectable6: old=2023.10 dd <42>.narrow 19:24
bisectable6 lizmat, Bisecting by output (old=2023.10 new=bcd7bea) because on both starting points the exit code is 0
19:28 bisectable6 left
lizmat awww I killed bisectable6 ? 19:29
ugexe did we intentionally stop running a spectest CI? 19:31
lizmat not to my knowledge?
ugexe or did we just forget to re-add it during the CI reworking 19:32
lizmat patrickb might know
19:32 bisectable6 joined
ugexe maybe it is just named something else now as well 19:36
patrickb I seem to recall having seen a spectest in the reworked CI. I'm pretty sure it's not been left out intentionally. 19:55
I think it's behind Lin_Spesh_Nodelay 19:58
timo wow, a spec test run with nodelay? i guess that'll be good to tickle out specializer bugs? 20:03
Geth rakudo/ugexe/readd-original-protect-block: 4919b64780 | (Nick Logan)++ | src/core.c/CompUnit/PrecompilationRepository.rakumod
Prevent concurrent hash access

Currently two threads can read null from the $resolved hash and both end up trying to resolve the same thing. This restores the original lock protect scope from before 95fb926 to ensure read and write don't have a race condition.		 20:45
rakudo/ugexe/readd-original-protect-block: b6242f4bf4 | (Nick Logan)++ | src/core.c/CompUnit/PrecompilationRepository.rakumod
Give each hash their own lock

There should be no need for the loading mechanism to always block the resolve mechanism. This gives the $resolved hash its own lock instead of using the lock for the $loaded hash.
rakudo/ugexe/disable-default-curis: f8a78ce7e7 | (Nick Logan)++ | src/core.c/CompUnit/RepositoryRegistry.rakumod
Allow default CURIs to be disabled

Previously there was no convenient way to disable the e.g. site, vendor, and core repositories. But when developing with application specific module install locations one might not want for modules to be used outside of that location. This add a new environment variables, RAKU_DISABLE_DEFAULT_CURIS, which can be set to anything to prevent the default repositories from being added to the repo chain itself. Note that it does still register those repositories with the registry.		 20:48
rakudo/main: 4919b64780 | (Nick Logan)++ | src/core.c/CompUnit/PrecompilationRepository.rakumod
Prevent concurrent hash access

Currently two threads can read null from the $resolved hash and both end up trying to resolve the same thing. This restores the original lock protect scope from before 95fb926 to ensure read and write don't have a race condition.		 21:08
rakudo/main: b6242f4bf4 | (Nick Logan)++ | src/core.c/CompUnit/PrecompilationRepository.rakumod
Give each hash their own lock

There should be no need for the loading mechanism to always block the resolve mechanism. This gives the $resolved hash its own lock instead of using the lock for the $loaded hash.
rakudo/main: f58bed9f61 | (Nick Logan)++ (committed using GitHub Web editor) | src/core.c/CompUnit/PrecompilationRepository.rakumod
Merge pull request #5299 from rakudo/ugexe/readd-original-protect-block

Fix potential concurrent hash access race condition
23:13 sena_kun left

Powered by Cro and the Raku® Programming Language.

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

Thank you!