🦋 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:02 reportable6 joined 06:00 reportable6 left 06:01 reportable6 joined 08:02 sena_kun joined 08:46 sena_kun left
Geth rakudo/main: 10ee220a79 | (Elizabeth Mattijsen)++ | src/core.c/Any.rakumod
Make dd more lenient towards non-of classes
 09:06
ab5tract [Coke]: I just realized that my commits changing uniprop -> 0 to uniprop -> '' will actually just make the documentation more complicated, as both have to be mentioned 10:36
I will revert those commits later today and wait to address it more comprehensively pending a problem-solving discussion 10:37
For now: "`uniprop` will return 0 if the provided property is unknown. Note that some properties may be returned from `uniprop` with space separators between words. These will not roundtrip and instead must be specified with `_` separators when passed to `uniprop`" (see my example with "e".uniprop("e".uniprop("Block"))' 10:40
m: "e".uniprop("e".uniprop("Block")) ==> say()
camelia
patrickb nine: Unsure if it's necessary for a grant to work, but there is no amount specified in the grant text. 11:38
lizmat that's... odd? there was an amount in the version of the proposal that I've seen 11:39
patrickb Maybe I missed it... 11:43
Still can't find it... 11:44
12:00 reportable6 left 12:02 reportable6 joined
[Coke] might have been a cut-and-pasto when Saif made it into an article. 13:33
Geth rakudo/main: cdf127b15d | ab5tract++ | src/core.c/unicodey.rakumod
Revert "Actually return '' (not Nil) from uniprop"

Avoid changing this return value until a more comprehensive approach to missing uniprops has been proposed, accepted, and implemented.
This reverts commit 05dcd08151bd36e9f7c1dfaeb5d398409749d278.		 13:49
rakudo/main: 741e6eaf99 | ab5tract++ | src/core.c/unicodey.rakumod
Revert "Return '' instead of 0 when a uniprop is not found"

This reverts commit aee3d2599a93ca52d90d4666f554781e28b695c9.
Avoid changing this return value until a more comprehensive approach to missing uniprops has been proposed, accepted, and implemented.
[Coke] ab5tract: do we think that uniprop will eventually round trip? 13:59
ab5tract I would prefer it to, for sure
though I'm leaning towards proposing a single `unicode` method that would use named args to provide all of the use cases currently served by the various uni* methods, which would then be deprecated 14:01
[Coke] Having a clear path forward in 6e would be nice. 14:04
14:06 sena_kun joined
ab5tract indeed. it should be straightforward to even turn an unknown property into a compile-time error 14:20
jdv: so I finally got a hand-rolled Blin container working, only to get: `Attempting to fetch 05dcd08151bd36e9f7c1dfaeb5d398409749d278…` 14:32
we know that this commit was built because I saw the new return value returning from uniprop. I'm specifying it as `old` and `new` 14:35
jdv you'd likely have to talk to alexdaniel 14:38
ab5tract it's potentially an architecture issue... 14:53
now I've circled 360 degrees back to just wanting blin to be able to compile a single checkout and test against it.. 14:54
Geth nqp/main: 3b9f3acd7d | ab5tract++ | src/QRegex/Cursor.nqp
Add dispatching logic for an HLL override

NQPMatchRole's `!DELEGATE_ACCEPTS` is not robust enough to handle the complexity of inputs that Raku gives it. So, offer the opportunity to override the behavior via a `DELEGATE-ACCEPTS` method defined in a consuming class/role.
This is part of addressing Rakudo Issues #5486 and #5372
rakudo/main: 22492982c5 | ab5tract++ | src/core.c/Match.rakumod
Add lookup for translating General_Category longnames

Also fix broken shortnames "L", "M", "N", "P", "S", "Z", and "C".
This fixes #5486 and #5372.
The problem this addresses is three-fold: ... (23 more lines)
patrickb lizmat, nine: Can you have a look at: github.com/Raku/problem-solving/is...1984532814 15:44
lizmat ab5tract: isn't the NQP commit necessary for the Rakudo commit? 16:22
ab5tract Yes, was going to push a bump shortly 16:24
it’s a soft dependency
lizmat ack
*phew* 16:25
ab5tract lizmat: there seem to be some array-related spectests failing 17:06
lizmat runs a spectest 17:07
I don't see anny failures 17:11
*any
ab5tract bizarre. I don't see how they could be related to my merged PRs either.. 17:12
reverting `10ee220a796ddabd9185d2ee84cfe95418e93d8c` fixed the failures for me 17:16
Geth rakudo/main: f2a7e7d47c | ab5tract++ | tools/templates/NQP_REVISION
Bump MQP_REVISION

This enables the NQPMatchRole!DELEGATE_ACCEPTS -> Match.DELEGATE-ACCEPTS delegation.		 17:17
ab5tract gah, of course I don't see the typo until its too late.. 17:19
lizmat it *is* one step back from N :-)
Geth rakudo/main: 48ef5c3efe | (Elizabeth Mattijsen)++ | src/core.c/Any.rakumod
Revert "Make dd more lenient towards non-of classes"

This reverts commit 10ee220a796ddabd9185d2ee84cfe95418e93d8c.
ab5tract imdeed ;) 17:21
18:00 reportable6 left 18:02 reportable6 joined
nine Maybe they don't post the amounts publicly? 19:32
patrickb nine: They did in the past. But if you communicated an amount, I'm fine with that. I just wanted to make sure this won't be a issue later on. 19:34
Geth rakudo/supply-exit-status-for-usage: a2af93feae | ab5tract++ | src/core.c/Main.rakumod
Provide conditional exit status for USAGE

Even though it's an older approach, it is trivial to provide `USAGE` the same exit code logic as for
  `GENERATE-USAGE`:
   If a `--help` is part of the invocation, exit 0.
   Otherwise, exit 2.
Addresses R#5514 (#5514).		 22:47
linkable6 R#5514 [open]: github.com/rakudo/rakudo/issues/5514 [CLI] Bug: Command-line interface generator exits with success code 0 even when you pass random jibberish in the arguments
Geth rakudo: ab5tract++ created pull request #5558:
Provide conditional exit status for `USAGE`
22:48 linkable6_ left 22:49 linkable6_ joined 23:59 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!