🦋 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.
00:00 reportable6 left 00:01 reportable6 joined 00:46 kjp left 00:49 kjp joined 01:08 Voldenet left 01:51 MasterDuke joined 01:52 Voldenet joined 03:31 evalable6 left, linkable6 left, evalable6 joined 03:33 linkable6 joined
Geth nqp/main: 1cdfa799ba | (Daniel Green)++ | tools/templates/MOAR_REVISION
Bump MoarVM for new stat repr and syscalls
rakudo/main: 9 commits pushed by (Daniel Green)++, MasterDuke17++ 04:58
06:00 reportable6 left 06:02 reportable6 joined 06:37 jdv_ joined 06:39 jdv left 08:10 discord-raku-bot left, discord-raku-bot joined 08:36 sena_kun joined 09:56 Voldenet left 10:03 Voldenet joined 10:32 Voldenet left 10:49 Voldenet joined 12:00 reportable6 left 12:03 reportable6 joined 13:03 bisectable6 left, shareable6 left, greppable6 left, reportable6 left, releasable6 left, squashable6 left, coverable6 left, benchable6 left, notable6 left, linkable6 left, tellable6 left, quotable6 left, evalable6 left, unicodable6 left, bloatable6 left, sourceable6 left, committable6 left, nativecallable6 left, greppable6 joined, tellable6 joined, shareable6 joined, quotable6 joined 13:04 reportable6 joined, benchable6 joined, unicodable6 joined, coverable6 joined, bloatable6 joined, squashable6 joined, evalable6 joined, nativecallable6 joined 13:05 releasable6 joined, notable6 joined, bisectable6 joined, committable6 joined, sourceable6 joined, linkable6 joined
Geth rakudo/main: 402bcb8e6c | (Vadim Belman)++ | src/vm/moar/runner/main.c
Provide a workaround for macOS Security Integrity Protection

A common complain about 'raku is loading libsomething in an unsafe way' doesn't have a single universal solution. Here I try to provide a workaround to it by enforcing DYLD_LIBRARY_PATH variable from a Rakudo-specific RAKUDO_DYLD_LIBRARY_PATH. This, for example, provides a fix for installing OpenSSL module.
rakudo/main: 64a175ad11 | (Vadim Belman)++ (committed using GitHub Web editor) | src/vm/moar/runner/main.c
Merge pull request #5350 from vrurg/workaround-macos-dyld-security

Provide a workaround for macOS Security Integrity Protection
vrurg lizmat: speaking of PseudoStashes and what my PR would bring, I recovered about one important chage: DYNAMIC would now pick up everything or almost everything visible via $* resolution. I.e. it includes GLOBAL, PROCESS, and $*PROMISE chain. 13:44
lizmat it didn't before ? 13:45
vrurg m: PROCESS::<$AA> = "foo"; say $*AA; say DYNAMIC::<$*AA>
camelia foo
vrurg Also, if memory serves me right, bindings should start working where they don't currently work. 13:47
lizmat such as ?
vrurg That I need to recover too. :) 13:48
2 years is a long term.
lizmat yeah... I know :-)
vrurg Nah, the binding was planned but I never got there because was waiting for PRs approval. 14:04
Geth rakudo/main: 76308eb5b2 | (Elizabeth Mattijsen)++ | src/Raku/ast/operator-properties.rakumod
RakuAST: add OperatorProperties.dottyopish|nulltermish

These used to be values of "next-term" but no more.
rakudo/main: 8 commits pushed by (Vadim Belman)++ 14:09
vrurg Oh, a funny one. Currently DYNAMIC::<$*FOO> wouldn't work for `my $*FOO := 42` because a scalar is required. 14:10
lizmat ??
vrurg Legacy DYNAMIC implementation was looking into .dynamic attribute of a Scalar. 14:12
lizmat aaah.. ok, gotcha
missed the : in := :-)
I'm starting to wonder whether we still need .dynamic on Scalars in the (near) future 14:13
vrurg No, it's not needed anymore.
Though it's still respected by PseudoStash 14:15
Geth rakudo/main: 66414c0498 | (Elizabeth Mattijsen)++ | 2 files
RakuAST: OperatorProperties.comma is never fiddly
14:48 ab5tract joined 15:02 Voldenet left
Geth rakudo/main: ad4c580d5a | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp
RakuAST: OperatoriProperties.thight-and is always iffy
rakudo/main: cefa085c94 | (Elizabeth Mattijsen)++ | src/Raku/ast/operator-properties.rakumod
RakuAST: OperatorProperties.tight cleanup

  - tight-or is always left associative
  - renamed tight-or-defor -> tight-defor
  - renamed tight-or-xor -> tight-xor
rakudo/main: 168a67ffc0 | (Elizabeth Mattijsen)++ | 2 files
RakuAST: OperatorProperties.loose-andthen is always list associative
rakudo/main: e6fdb8536c | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp
RakuAST: OperatorProperties.loose_or is always iffy
rakudo/main: ba9f4050e0 | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp
RakuAST: OperatorProperties.loose_or's assoc defaults to left
rakudo/main: 1380fa3b27 | (Elizabeth Mattijsen)++ | src/Raku/ast/operator-properties.rakumod
RakuAST: rename OperatorProperties.loose-or-xor to loose-xor

For naming consistency
rakudo/main: e0b7e83173 | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp
RakuAST: OperatorProperties.loose_orelse is already :assoc<list>
rakudo/main: 5aeeb39ddf | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp
RakuAST: pasttype is a thing of the distant past
rakudo/main: eec42c773d | (Elizabeth Mattijsen)++ | 2 files
RakuAST: OperatorProperties.loose-and is always iffy
nemokosch what does "iffy" mean? 16:17
Geth rakudo/main: be6428ba7a | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp
RakuAST: all infix tokens now use a hash only for O<>

And not change settings "ad-hoc"
jdv_ patrickb: aye aye capt. thanks. 16:42
16:43 jdv_ is now known as jdv
lizmat nemokosch: I don't fully grok what "iffy" means, but it is used in the parser as a condition to handle expressions with infix operators 16:59
Geth rakudo/main: 042e1e4d7d | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp
RakuAST: oops, missed loose_xor

Now all infix tokens use a hash only for O<>
rakudo/main: ce29ccdae8 | (Elizabeth Mattijsen)++ | src/Raku/ast/operator-properties.rakumod
RakuAST: OperatorProperties; reorganizing attributes

For better overview
rakudo/main: c509e758b5 | (Elizabeth Mattijsen)++ | src/Raku/ast/operator-properties.rakumod
RakuAST: Fix OperatorProperties.prec handling of "nextterm"
ugexe there seem to be precompilation issues on windows outside of path length limitations now, particularly on GitHub actions 17:55
sometimes it occurs when calling CURI.install(...) (which means it tries to precompile modules one-by-one) and sometimes it occurs when doing e.g. `raku -I. -e 'use Some::Zef::Module` (which means its using CURFS and potentially precompiling in parallel) 17:57
i kind of wonder if it isn't an issue with renaming things
either other file operations in PrecompilationRepository need to retry, or the existing retry logic has become broken/flakey sometime in the last 1.5 years 17:58
unfortunately in GitHub actions these errors happen regularly and never include any additional information than an occasional stack trace showing its precompilation 17:59
setting RAKUDO_MODULE_DEBUG=1 seems to avoid the issue the few times i've tried, which hints that the additional overhead/slowdown of using it could be helping to avoid the aforementioned issue 18:00
18:00 reportable6 left 18:02 reportable6 joined
ugexe all this same code works fine running on appveyor 18:03
19:26 nine left, nine joined 19:48 sena_kun left, sena_kun joined 20:51 hythm76 joined, hythm left 21:37 Voldenet joined
ugexe hmm, at least one of the precompilation errors is a stack overflow 22:36
22:36 sena_kun left
ugexe github.com/ugexe/zef/actions/runs/...ep:11:3084 22:36
Geth LWP-Simple: 7138dbe75b | (David Warring)++ (committed using GitHub Web editor) | META6.json
Update META6.json

Reset `auth` to `zef:raku-community-modules`
Changed this temporarily, to get the module released.
23:49 linkable6 left, evalable6 left 23:51 evalable6 joined 23:52 linkable6 joined