š¦ Welcome to the IRC channel of the core developers of the Raku Programming Language (raku.org #rakulang). This channel is logged for the purpose of history keeping about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | Logs available at irclogs.raku.org/raku-dev/live.html | For MoarVM see #moarvm Set by lizmat on 8 June 2022. |
|||||||||||||||||||||||||||||||||||||||
Geth | rakudo/main: 6 commits pushed by (Vadim Belman)++
|
00:19 | |||||||||||||||||||||||||||||||||||||
roast: 51486a74b8 | (Vadim Belman)++ | S02-names/is_default.t Extend `is default` tests for hashes Cover all variations of parameterization over key and value. |
|||||||||||||||||||||||||||||||||||||||
roast: 4fe0e7455f | (Vadim Belman)++ | S02-names/is_default.t Expect `X::TypeCheck::Attribute::Default` It makes more sense with wrong type of value in `is default` for attributes. |
|||||||||||||||||||||||||||||||||||||||
roast: f1dd68cf67 | (Vadim Belman)++ (committed using GitHub Web editor) | S02-names/is_default.t Merge pull request #848 from vrurg/some-about-is-default Improvements to `is default` tests for hashes |
|||||||||||||||||||||||||||||||||||||||
tbrowder__ | m: echo $RAKUDO_MAX_THREADS | 00:50 | |||||||||||||||||||||||||||||||||||||
camelia | ===SORRY!=== Error while compiling <tmp> Variable '$RAKUDO_MAX_THREADS' is not declared. Perhaps you forgot a 'sub' if this was intended to be part of a signature? at <tmp>:1 ------> echo ā$RAKUDO_MAX_THREADS |
||||||||||||||||||||||||||||||||||||||
tbrowder__ | m: ls | ||||||||||||||||||||||||||||||||||||||
camelia | ===SORRY!=== Error while compiling <tmp> Undeclared routine: ls used at line 1. Did you mean 'lc'? |
||||||||||||||||||||||||||||||||||||||
tbrowder__ | m: say %*ENV<RAKUDO_MAX_THREADS> | 00:51 | |||||||||||||||||||||||||||||||||||||
camelia | (Any) | ||||||||||||||||||||||||||||||||||||||
tbrowder__ | m: say $*CPU | 00:52 | |||||||||||||||||||||||||||||||||||||
camelia | Dynamic variable $*CPU not found in block <unit> at <tmp> line 1 |
||||||||||||||||||||||||||||||||||||||
tbrowder__ | m: say $*KERNEL | 00:55 | |||||||||||||||||||||||||||||||||||||
camelia | linux | ||||||||||||||||||||||||||||||||||||||
tbrowder__ | say %*ENV | 00:56 | |||||||||||||||||||||||||||||||||||||
m: say %*ENV | |||||||||||||||||||||||||||||||||||||||
camelia | {HOME => /home/camelia, INVOCATION_ID => b9079b9b59434c248895ea8fb3ed6faa, JOURNAL_STREAM => 8:9828585, LC_CTYPE => en_US.UTF-8, LOGNAME => camelia, ME => tbrowder__, PATH => /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin, PERL5LIB => /hā¦ | ||||||||||||||||||||||||||||||||||||||
Geth | rakudo/main: f29cecfad1 | (Vadim Belman)++ | src/core.c/Exception.rakumod Fix X::Hash::Store::OddNumber message with undefined last element First of all, the last element can be an undefined value and we better report it for ease of debugging. The current fix is incomplete with regard to `Mu` which is no less valid as an element than any other type object. But for now let's pretend that it's the least probable value to appear in this role. ... (7 more lines) |
01:03 | |||||||||||||||||||||||||||||||||||||
tbrowder__ | i may have found a Raku bug while testing vrurgs Test::Async. when RAKUDO_MAX_THREADS=16, test 150 hangs, regardless of number of cores = 8 or 16. i have not tested greater or lesser real cores yet. | 01:10 | |||||||||||||||||||||||||||||||||||||
*test 160 | |||||||||||||||||||||||||||||||||||||||
vrurg | tbrowder__: this is not necessarily a Rakudo bug. More likely to be a Test::Async not expecting that few threads being available. | 01:11 | |||||||||||||||||||||||||||||||||||||
tellable6 | 2023-11-16T16:46:54Z #raku-dev <tbrowder__> vrurg ^^^ | ||||||||||||||||||||||||||||||||||||||
vrurg | It's even more likely to be Test::Async. | 01:12 | |||||||||||||||||||||||||||||||||||||
tbrowder__ | well having the number < or > 16 did not hang the test | ||||||||||||||||||||||||||||||||||||||
the RAKUDO_MAX_THREADS | 01:13 | ||||||||||||||||||||||||||||||||||||||
on both hosts, cores 8 and 16 | 01:14 | ||||||||||||||||||||||||||||||||||||||
vrurg | 8 did the trick on my side. It may depend on the number of CPU cores because when there is no TEST_JOBS in the environment Test::Async sets the number of jobs to cpu-cores - 2. | 01:27 | |||||||||||||||||||||||||||||||||||||
And, BTW, using TEST_JOBS is generally a bad idea on my side... | |||||||||||||||||||||||||||||||||||||||
tbrowder__ | setting max to 8 hangs on mine too | 02:03 | |||||||||||||||||||||||||||||||||||||
but max=24? | 02:04 | ||||||||||||||||||||||||||||||||||||||
no prob w/ 24 | 02:06 | ||||||||||||||||||||||||||||||||||||||
weird | |||||||||||||||||||||||||||||||||||||||
vrurg | tbrowder__: no, there is nothing weird here. It only means that there are not enough tasks to exhaust the thread pool. | 02:16 | |||||||||||||||||||||||||||||||||||||
02:16
sourceable6 left
|
|||||||||||||||||||||||||||||||||||||||
tbrowder__ | well, anyhow, i got yr JSON::Class installed ok. | 02:29 | |||||||||||||||||||||||||||||||||||||
so, nothing to bug report about? | 02:30 | ||||||||||||||||||||||||||||||||||||||
vrurg | A new version is to be published today. Finishing some, hopefully, last touches. | ||||||||||||||||||||||||||||||||||||||
tbrowder__ | ok, just another fun day in Rakuland! | 02:31 | |||||||||||||||||||||||||||||||||||||
vrurg | No, there is really no bug. I'm not sure if it worth spending time on a workaround for the problem as it would be another performance penalty applied. | 02:32 | |||||||||||||||||||||||||||||||||||||
But enforcing the minimum pool size for this particular test definitely makes sense. | 02:34 | ||||||||||||||||||||||||||||||||||||||
03:57
tonyo left
03:58
tonyo joined
04:16
codesections left,
codesections joined
04:28
hythm joined
05:52
hythm left
06:29
djinni` left
06:39
djinni` joined
08:23
[Tux] left
09:12
japhb left,
japhb joined
09:28
[Tux] joined
09:52
sena_kun joined
|
|||||||||||||||||||||||||||||||||||||||
[Tux] waves from new workstation. All upcoming timings should be based on the one I recently posted | 10:04 | ||||||||||||||||||||||||||||||||||||||
|
11:02 | ||||||||||||||||||||||||||||||||||||||
12:08
sena_kun left
|
|||||||||||||||||||||||||||||||||||||||
tbrowder__ | ref Test::Async and max threads of 8 and 16 | 12:30 | |||||||||||||||||||||||||||||||||||||
i tried inst on two other hosts, one with 24 cores and one with 32 cores. both had max threads seg at 16. when "zef install" started, zef fairly quickly reported "Testing [OK]..." for more than one of the 3 mods involved and then hung. | 12:35 | ||||||||||||||||||||||||||||||||||||||
after i removed the thread limit and retried installing, zef reported, serially, "Testing [OK]..." each dep and the JSON::Class. i'm not smart enough to understand the interplay here (concurrency hurts my brain), but this total behavior doesn't seem rational. why are 8 and 16 thread max magic? | 12:39 | ||||||||||||||||||||||||||||||||||||||
i took a brief look at raku core.c and saw "maxthreads // RAKUDO,. | 12:40 | ||||||||||||||||||||||||||||||||||||||
several places. wonder if core count is being interpreted correctly | 12:41 | ||||||||||||||||||||||||||||||||||||||
does zef react to | 12:44 | ||||||||||||||||||||||||||||||||||||||
does zef consider max threads? | 12:45 | ||||||||||||||||||||||||||||||||||||||
13:02
lucs left
13:03
lucs joined
|
|||||||||||||||||||||||||||||||||||||||
tbrowder__ | maybe there ought to be some internal raku bounds on value of RAKUDO_MAX_THREADS based on /proc/cpuinfo | 13:08 | |||||||||||||||||||||||||||||||||||||
lizmat | tbrowder__: I think we consciously decided to not limit the value you specify with RAKUDO_MAX_THREADS: there may be reasons to have the value exceed available cores | 13:13 | |||||||||||||||||||||||||||||||||||||
e.g. when a lot of waiting is done for (external) resources | 13:14 | ||||||||||||||||||||||||||||||||||||||
m: sub a(\self) { say self }; a 42 | |||||||||||||||||||||||||||||||||||||||
camelia | ===SORRY!=== Error while compiling <tmp> 'self' used where no object is available at <tmp>:1 ------> sub a(\self) { say āself }; a 42 expecting any of: argument list term |
||||||||||||||||||||||||||||||||||||||
lizmat | m: say Q|sub a(\self) { say self }; a 42|.AST.EVAL | ||||||||||||||||||||||||||||||||||||||
camelia | 42 True |
||||||||||||||||||||||||||||||||||||||
lizmat | so, is this a bug we fixed in RakuAST? Or is it NYI for the compilation error? | 13:15 | |||||||||||||||||||||||||||||||||||||
ugexe | there might be problems with testing and/or installing in parallel | 13:21 | |||||||||||||||||||||||||||||||||||||
like if your test ends up loading multiple modules in parallel then it can potentially hit the 'module loading is not thread safe' issue | 13:22 | ||||||||||||||||||||||||||||||||||||||
when that manifests I usually see it as a segfault though. however sometimes i've seen it freeze | 13:23 | ||||||||||||||||||||||||||||||||||||||
tbrowder__ | lizmat: i was thinking more of some lower bound, 8 cores, no lower than, say, 16. but 16 and 8 are bad for some reason | 13:25 | |||||||||||||||||||||||||||||||||||||
lizmat | forcing a lower bound might cause more resource usage than the runner of the program wants? | 13:26 | |||||||||||||||||||||||||||||||||||||
tbrowder__ | and maybe it should be an odd number. | ||||||||||||||||||||||||||||||||||||||
i dunno, but something doesnāt smell right. | 13:28 | ||||||||||||||||||||||||||||||||||||||
ugexe | i would doubt a minimum number or even number of threads is the cause of an issue | 13:29 | |||||||||||||||||||||||||||||||||||||
github.com/rakudo/rakudo/blob/f29c...od#L18-L21 | 13:31 | ||||||||||||||||||||||||||||||||||||||
looks like you can set one of those two ENV variables to get more information about what is happening with threads | |||||||||||||||||||||||||||||||||||||||
tbrowder__ | ok, thnx | ||||||||||||||||||||||||||||||||||||||
did you see my ? on resources? | 13:35 | ||||||||||||||||||||||||||||||||||||||
using META to get list of resources in a distro? | 13:41 | ||||||||||||||||||||||||||||||||||||||
otherwise iām investigating Build to create a data module to provide that list. | 13:42 | ||||||||||||||||||||||||||||||||||||||
i want easy access to a distro payload | 13:43 | ||||||||||||||||||||||||||||||||||||||
ugexe | getting the list is easy in a Build.pm type file: Distribution::Path.new($dir-passed-to-build).meta<resources> | ||||||||||||||||||||||||||||||||||||||
i'm not sure why a check/validation would occur on META6.json at build time though. that should happen whenever any other meta6.json validation happens. i'm not sure when/what mi6 does in regards to that | 13:44 | ||||||||||||||||||||||||||||||||||||||
note though that in theory it seems a bit dirty to use the parent Distribution in its own Build step/module | 13:45 | ||||||||||||||||||||||||||||||||||||||
because that Distribution isn't supposed to even be built, yet its trying to be used to build itself! | 13:46 | ||||||||||||||||||||||||||||||||||||||
vrurg | tbrowder__: one thing you get totally wrong from the start. zef has nothing to do with the max threads setting. It's a flaw in Test::Async internal design which makes it vulnerable to the exhausting of thread pool. | 14:20 | |||||||||||||||||||||||||||||||||||||
14:44
vrurg left
14:45
vrurg joined
|
|||||||||||||||||||||||||||||||||||||||
tbrowder__ | i know but i was wondering if it considered the env var, zef i think uses threads too | 14:59 | |||||||||||||||||||||||||||||||||||||
releasable6 | Next release in ā4 days and ā3 hours. There are no known blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft | 15:00 | |||||||||||||||||||||||||||||||||||||
tbrowder__ | ugexe: didnāt you consider a few days ago adding to zef access to META<resources>? | 15:02 | |||||||||||||||||||||||||||||||||||||
ugexe | i'm not sure what you're referring to | ||||||||||||||||||||||||||||||||||||||
tbrowder__ | talking about an installed DISTRIBUTION where currently one needs to know paths in resources a priori to get access to content | 15:05 | |||||||||||||||||||||||||||||||||||||
i thought you said you might do that | 15:06 | ||||||||||||||||||||||||||||||||||||||
ugexe | afaik everything you wanted to do is already possible | ||||||||||||||||||||||||||||||||||||||
tbrowder__ | that would be very cool, esp if App::Mi6 would keep META resources in sync with module repo resources | 15:08 | |||||||||||||||||||||||||||||||||||||
a feature request has been filed for that | 15:09 | ||||||||||||||||||||||||||||||||||||||
15:16
vrurg_ joined
15:17
vrurg left
|
|||||||||||||||||||||||||||||||||||||||
tbrowder__ | ok, in an installed distro, how do i get a list of the paths in ./resources? | 15:18 | |||||||||||||||||||||||||||||||||||||
iāll try it in my Demo module (after adding it and reinstalling it)? | 15:21 | ||||||||||||||||||||||||||||||||||||||
ugexe | the relative paths you would give to .content? | ||||||||||||||||||||||||||||||||||||||
$*DISTRIBUTION.meta<resources>.map({ "resources/$_" }) or some such | |||||||||||||||||||||||||||||||||||||||
say $*DISTRIBUTION.content($_) for $*DISTRIBUTION.meta<resources>.map({ "resources/$_" }) | 15:23 | ||||||||||||||||||||||||||||||||||||||
tbrowder__ | okay, iāll give that a try, thanks! | 15:24 | |||||||||||||||||||||||||||||||||||||
Geth | Digest-PSHA1/main: 4773f4e52b | (MƔrton PolgƔr)++ (committed using GitHub Web editor) | META6.json Fix source URL |
15:41 | |||||||||||||||||||||||||||||||||||||
tbrowder__ | ugexe: looking good (with subst of ? for *) | 16:33 | |||||||||||||||||||||||||||||||||||||
++ugexe šš» | 16:40 | ||||||||||||||||||||||||||||||||||||||
eggcellent! | |||||||||||||||||||||||||||||||||||||||
iām gonna pub the module, but i need a better name. my use case is to show authors a tested way to provide their users with any module payload they want available. | 17:00 | ||||||||||||||||||||||||||||||||||||||
tonyo | i think tbrowder__ is a fine name | 17:01 | |||||||||||||||||||||||||||||||||||||
tellable6 | 2023-11-17T10:09:22Z #raku <melezhik> tonyo: - Ā build succeeded on the latest fez version taken from git - ci.sparrowhub.io/report/3814 | ||||||||||||||||||||||||||||||||||||||
2023-11-17T10:09:55Z #raku <melezhik> tonyo: - Ā I am still not sure what was the cause, cause I have not changed my fez token | |||||||||||||||||||||||||||||||||||||||
tonyo | bless | 17:02 | |||||||||||||||||||||||||||||||||||||
tbrowder__ | current module is at github/tbrowder/Demo | 17:03 | |||||||||||||||||||||||||||||||||||||
with the underscore? š | 17:12 | ||||||||||||||||||||||||||||||||||||||
š | |||||||||||||||||||||||||||||||||||||||
17:25
timo left,
timo joined
|
|||||||||||||||||||||||||||||||||||||||
tonyo | it underscores the author | 17:46 | |||||||||||||||||||||||||||||||||||||
Geth | rakudo/main: b64e683c04 | (Elizabeth Mattijsen)++ | src/core.c/Match.rakumod Pretty big refactor of Match class internals - wrap all nqp ops into local subroutines - de-nqpify where possible, increases readability - refactor common idioms into a sub - add more documentation - made some subs "our" because they need to be accessible outside ... (5 more lines) |
19:33 | |||||||||||||||||||||||||||||||||||||
19:56
MasterDuke joined
22:09
sena_kun joined
|
|||||||||||||||||||||||||||||||||||||||
tbrowder__ | well i picked a new name: HowToUseModuleResources (no underscores) | 22:35 | |||||||||||||||||||||||||||||||||||||
already in zef/fez, PRs welcome | 22:36 | ||||||||||||||||||||||||||||||||||||||
23:50
sena_kun left
|