|
01:13
MasterDuke left
|
|||
| Geth | rakudo/main: 9b377fcd72 | (Stefan Seifert)++ | src/Raku/Actions.nqp RakuAST: fix assignment to hash/array slots not getting optimized We accidentally checked the Match object instead of the AST node. |
08:23 | |
| nine | 1022 | ||
| Geth | rakudo/main: e75c4168fb | (Stefan Seifert)++ | src/Raku/ast/expressions.rakumod RakuAST: also detect negative subscript range at compile time |
09:13 | |
| nine | and one more | 09:14 | |
| ab5tract | nine++ | 09:33 | |
| lizmat | broke one test in "make test" though, but I will fix that | 09:37 | |
| ab5tract | m: dd my Str(Match) @g = “11 22” ~~ /(\d\d)\s(\d\d)/ | 09:39 | |
| camelia | Str(Match) @g = Array[Str(Match)].new("11 22") | ||
| ab5tract | that seems broken, right? | ||
| Geth | rakudo/main: 1ccb95d45c | (Stefan Seifert)++ | src/Raku/ast/statements.rakumod RakuAST: fix inadvertent sinking of a semi-lists elements Since SemiList is derived from StatementList, we sank all it's elements except for the last one. But a SemiList is used for constructing a list, so we need to retain all its elements. |
09:40 | |
| nine | And that makes it 1025 | ||
| lizmat is trying to keep up | |||
| 1K+ :-) | |||
| ab5tract | ah, nevermind, it's converting the match object as expected, sorry | 09:42 | |
| s/as expected/as defined/ | 09:43 | ||
| lizmat: out of curiosity, why hasn't R#5513 been merged yet? | 10:09 | ||
| linkable6 | R#5513 [open]: github.com/rakudo/rakudo/pull/5513 Add Mu.Callable($method) "coercer" | ||
| lizmat | not sure | 10:11 | |
| I guess because of jnthn's argument that the current MOP is a de-facto standard | 10:12 | ||
| nine: what is the point of adding a RakuAST::Role::ResolveInstantiations instance if there are no lexicals to resolve? | 10:22 | ||
| ab5tract | ah, I see, thanks | 10:23 | |
| Geth | rakudo/main: c9b75d737a | (Stefan Seifert)++ | src/Raku/ast/scoping.rakumod RakuAST: fix order of declarations in generated code We need to ensure that a block topic is declared lexically before we may want to access it. While normal statements will always come after declarations are processed, if the block topic is used in an initializer we may get the wrong value. Fixes $_ = 5; for 1..1 { my @md[1..$_] } |
10:47 | |
| nine | 1026 | ||
| lizmat: at the point where we have to add it to the tree, we don't know yet whether we're gonna need it | |||
| lizmat | nine: from the aspect of building an AST manually, it feels wrong to have to add a statement of which the function is not directly related to a source aspect | 10:49 | |
| nine | Well this is something that you wouldn't do manually anyway. It's basically an implementation detail of RakuAST::Role. | 10:51 | |
| lizmat | so why isn't it part of the RakuAST::Role class then? | 10:53 | |
| nine | Well it _is_ RakuAST::**Role**::ResolveInstantiations | ||
| lizmat | but why isn't it RakuAST::Role.resolve_instantiations ? | 10:55 | |
| nine | Because the point of it is that I need an AST node which will generate the right QAST inside the role's body sub | 10:56 | |
| lizmat | well, I think we have prior knowledge about that, e.g. in the handling of some of the phasers (KEEP or UNDO, I forget) | 10:57 | |
| well, of injecting a RakuAST tree into an existing RakuAST tree, and generating the QAST from that | 11:00 | ||
|
11:19
lizmat left
|
|||
| Geth | rakudo/main: ea0b0d1575 | (Elizabeth Mattijsen)++ | 2 files RakuAST: initial stab at adding DEPARSE / raku support for RakuAST::Role::ResolveInstantiations. Sadly the effect of having a RakuAST class without clear source interpretation, makes it a lot harder to create a sensible source representation that does not have visual side-effects depending on whether or not there are other statements in a statement list :-( At least .raku and .DEPARSE now do not die with "unimplemented" errors anymore. |
11:21 | |
|
11:22
lizmat joined
|
|||
| nine | A twigil cannot possible come before a digit, right? | 11:32 | |
| lizmat++ # thanks for the fix! | |||
| Raku beginner question: how do I get a \w without digits in a regex? | 11:35 | ||
| lizmat | m: say "abc456" ~~ / <[\w]-[\d]>* / | 11:36 | |
| camelia | ｢abc｣ | ||
| lizmat | basically, you can add and substract character classes | 11:37 | |
| m: say "ABC456" ~~ / <[A..Z]+[\d]>* / | |||
| camelia | ｢ABC456｣ | ||
| lizmat | m: say "abc456" ~~ / <[A..Z]+[\d]>* / | 11:38 | |
| camelia | ｢｣ | ||
| lizmat | hmmm sorta expected ｢456｣ there? | ||
| ab5tract | yeah.. | 11:40 | |
| lizmat | I guess the * isn't greedy enough | 11:41 | |
| m: say "abc456" ~~ / <[A..Z]+[\d]>+ / | 11:42 | ||
| camelia | ｢456｣ | ||
| ab5tract | feels kind of like a bug though, no? | ||
| lizmat | not sure... | ||
| I mean, you *are* asking for: match this, 0 or more times | 11:44 | ||
| it encounters a char that doesn't match, and thinks: we're done! | 11:45 | ||
| a match of 0 characters | |||
| ab5tract | yeah, hmm... | 11:49 | |
| m: say "a1" ~~ /\d*/ | |||
| camelia | ｢｣ | ||
| ab5tract | yeah, so not a bug | 11:50 | |
| or at least consistent ;) | 11:51 | ||
| lizmat | afk for a few hours& | 12:18 | |
| ab5tract | m: multi s(@a) { dd @a }; multi s(@a, :$h = "duh") { say $h }; s [1]; s [1], :h<vv> | 14:42 | |
| camelia | duh vv |
||
| ab5tract | I'm a bit shocked that this isn't an ambiguous dispatch | ||
| So otherwise equivalent candidates with named args always supersede narrower candidates? | 14:55 | ||
| m: multi s(@a) { dd @a }; multi s(@a, :$h = "duh") { say "blah " ~ $h }; multi s(@a, :$h!) { say "meh " ~ $h.raku }; s [1]; s [1], :h<vv> | 15:01 | ||
| camelia | blah duh blah vv |
||
| ab5tract | my brain hurts :( | 15:02 | |
| why do allow the compiler to accept nonsensical multis? | 15:05 | ||
| seems like it would be more polite to say "only one of these candidates will ever see a dispatch" | 15:06 | ||
| lizmat | m: multi s(@a) { dd }; multi s(@a, :$h = "duh") { dd }; multi s(@a, :$h!) { dd }; s [1]; s [1], :h<vv> | 15:58 | |
| camelia | sub s(@a, :$h = "duh") sub s(@a, :$h = "duh") |
||
| ab5tract | similar to what we went over a few days ago regarding the ordering of named args in multi sigs.. | 16:56 | |
| lizmat | fwiw, I think the first call: s [1] should have been handled by the first candidate | 17:02 | |
| on account of absence of *%_ in the case of multi subs | |||
| for methods, I'm less sure | |||
| Geth | rakudo/main: aeccbb4000 | (Elizabeth Mattijsen)++ | 2 files Better fix for additional statements in roles as done in ea0b0d15753862ad7. Take the approach of hiding the additional statements from view, rather than actually provoding .DEPARSE and .raku support for them. This is really a temporary measure, as this will be one of the cases where one can **NOT** use the .AST of a role as a template for building roles programmatically. So this *will* need some additional thinking before this can be unleashed onto the world in a official language version release. |
17:11 | |
|
18:21
gfldex left
18:25
gfldex joined
|
|||
| Geth | rakudo/main: 2d76783a6d | (Daniel Green)++ | tools/templates/jvm/Makefile.in Increase JVM max heap After either c6fb210 or 1d609da the JVM backend started failing with `java.lang.OutOfMemoryError: Java heap space` when it gets to compiling CORE.c. |
19:17 | |
| lizmat | meh looks like I borked Inline::Perl5 tests already with 9f0b8689dc16718e9b5021 | 19:27 | |
| linkable6 | (2024-04-05) github.com/rakudo/rakudo/commit/9f0b8689dc Streamline Metamodel::RoleToRoleApplier (Part 2/N) | ||
| lizmat | will look at that tomorrow *after* the weekly | 19:34 | |
|
20:54
MasterDuke joined
23:28
coleman left
23:30
coleman joined
|
|||