| Geth | rakudo/fix-negated-junctions: cf867f8da0 | ab5tract++ | src/core.c/OperatorProperties.rakumod Whitespace |
00:42 | |
| rakudo/fix-negated-junctions: bc518ee0b8 | ab5tract++ | 8 files Revision gating is not working with `&infix:<ne>` I've tried all sorts of things, including moving all the sub declarations into `core_epilogue.rakumod` ... with some approaches the CORE.setting fails due to things happening too early or (as is the case with the current commented out code) using `ne` just causes an infinite hang. ... (7 more lines) |
|||
|
03:15
japhb left
03:17
japhb joined
03:30
librasteve_ left
03:33
japhb left
03:37
japhb joined
|
|||
| Geth | rakudo: usev6++ created pull request #5692: [JVM] Remove workarounds for broken deserialization of nqp::null |
07:31 | |
| bartolin_ | m: my $m = "foobar" ~~ /oo/; say $m.gist | 08:54 | |
| camelia | ｢oo｣ | ||
| bartolin_ | This fails on the JVM backend with "Cannot dispatch to method chomp on Match because it is not inherited or done by Str" | ||
| The backtrace points to github.com/rakudo/rakudo/blob/3f0f...kumod#L397 | 08:55 | ||
| m: "foo".Match::chomp ## same error | |||
| camelia | Cannot dispatch to method chomp on Match because it is not inherited or done by Str in block <unit> at <tmp> line 1 |
||
| bartolin_ | But now I wonder, why/how this works on Moar. Does it take a different code path and never reaches that line? | 08:56 | |
|
09:00
bartolin_ left,
bartolin joined
09:48
sena_kun joined
|
|||
| ab5tract | the entire dispatch pipeline differs between the two now. I suspect this is a side effect of this | 10:55 | |
| Geth | rakudo/main: 3470f83867 | (Christian Bartolomäus)++ (committed using GitHub Web editor) | 2 files [JVM] Remove workarounds for broken deserialization of nqp::null This reverts commit 9f41d2c61a14ce468128c17334ca663ef8765c98. The bandaid is no longer needed, because now nqp::null gets deserialized correctly: github.com/Raku/nqp/pull/829 This reverts commit 555f4b0049c58bf89301bdc06d9cbce0dbff1958. The bandaid is no longer needed, because now nqp::null gets deserialized correctly: github.com/Raku/nqp/pull/829 |
11:06 | |
| nqp/main: 033ffd3a08 | ab5tract++ (committed using GitHub Web editor) | src/HLL/Compiler.nqp Add is-interactive to HLL::Compiler (#827) This commit nukes the hard-to-grok distinction of `interactive` vs `non-interactive` repl-modes and replaces it with the following options: - `tty` ... (21 more lines) |
11:49 | ||
| rakudo/main: 167d1dd9a8 | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION Bump NQP to get new REPL mode settings ab5tract++ |
12:03 | ||
| rakudo/fail-gracefully-outside-of-supported-terminal-emulator: 3470f83867 | (Christian Bartolomäus)++ (committed using GitHub Web editor) | 2 files [JVM] Remove workarounds for broken deserialization of nqp::null This reverts commit 9f41d2c61a14ce468128c17334ca663ef8765c98. The bandaid is no longer needed, because now nqp::null gets deserialized correctly: github.com/Raku/nqp/pull/829 This reverts commit 555f4b0049c58bf89301bdc06d9cbce0dbff1958. The bandaid is no longer needed, because now nqp::null gets deserialized correctly: github.com/Raku/nqp/pull/829 |
12:04 | ||
| rakudo/fail-gracefully-outside-of-supported-terminal-emulator: 167d1dd9a8 | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION Bump NQP to get new REPL mode settings ab5tract++ |
|||
| rakudo/fail-gracefully-outside-of-supported-terminal-emulator: 03394c72d8 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | 3 files Merge branch 'main' into fail-gracefully-outside-of-supported-terminal-emulator |
|||
| rakudo/main: 6c088c8cfc | ab5tract++ (committed using GitHub Web editor) | 5 files Fail gracefully when REPL is initialized without TTY This patch was originally intended to address R#4378 (#4378)[^1], but that problem is actually unresolvable as long as starting `raku` outside of a TTY automatically engages the wait-until-EOF mode (the same behavior as calling `perl` without `-e`). ... (11 more lines) |
12:05 | ||
| linkable6 | R#4378 [closed]: github.com/rakudo/rakudo/issues/4378 [Windows] `Git for Bash` has no TTY, so raku opens in "non-interactive" mode | ||
| bartolin | lizmat: Could you maybe shed some light on my earlier question regarding the usage of "Match::chomp" in github.com/rakudo/rakudo/blob/3f0f...umod#L397? I'd like to understand how that works with Moar. | 12:28 | |
| lizmat | normally, method lookup starts with the class of the invocant | 12:29 | |
| bartolin | This would be Str in this case, right? | 12:30 | |
| lizmat | with a fully qualified method call, you're letting the method lookup start with the given class | ||
| yeah, looks like | 12:31 | ||
| bartolin | ok, that's what I thought as well. But why doesn't it blow up? | ||
| m: "foo".Match::chomp | |||
| camelia | Cannot dispatch to method chomp on Match because it is not inherited or done by Str in block <unit> at <tmp> line 1 |
||
| lizmat | because .chomp is Cool ? | ||
|
12:32
donaldh_ joined
|
|||
| lizmat | and Match is as well ? | 12:32 | |
| bartolin | So it takes the implementation from Cool::chomp? That makes some sense to me. | ||
| But why doesn't it do the for the above evaluation? | 12:33 | ||
| lizmat | the proto for .chomp lives in Cool | ||
| m: say 42.chomp | 12:34 | ||
| camelia | 42 | ||
| lizmat | m: say 42.Match::chomp | ||
| camelia | Cannot dispatch to method chomp on Match because it is not inherited or done by Int in block <unit> at <tmp> line 1 |
||
| lizmat | hmmm | ||
| m: "foo" ~~ / foo /; dd $/.Match::chomp | 12:35 | ||
| camelia | "foo" | ||
|
12:35
donaldh left
|
|||
| lizmat | m: "foo" ~~ / foo /; dd $/.chomp | 12:35 | |
| camelia | "foo" | ||
| lizmat | m: "foo\n" ~~ / .* /; dd $/.chomp | 12:36 | |
| camelia | "foo" | ||
| lizmat | m: "foo\n" ~~ / .* /; dd $/.Match::chomp | ||
| camelia | "foo" | ||
| lizmat | ok, I have no idea why the Match:: is there | ||
| bartolin | It first came in with github.com/rakudo/rakudo/commit/f2c394120f where you qualified a lot of methods. Maybe it was just an oversight that in this case the invocant was not of type Match? | 12:38 | |
| bartolin is still puzzled why it "just works" there, but not if one does "foo".Match::chomp | 12:39 | ||
| lizmat is now also confuse | 12:40 | ||
| d | |||
| apparently in b64e683 I once tried to clean up that mess... but it broke stuff | |||
| please feel free to remove the Match:: there | |||
| and see if that fixes / breaks things | 12:41 | ||
| bartolin | ok, I'll try that out. Thanks for looking | 12:42 | |
| lizmat | maybe in MoarVM the type hierarchy is subtly different.. dunno | 12:43 | |
|
12:50
sena_kun left
|
|||
| ab5tract | It could be something subtle that happens in the dispatcher too | 13:13 | |
| bartolin | I'll take a look there as well. but first my spectest for the JVM needs to finish ;) | 13:17 | |
| Geth | rakudo/main: 238e313ebf | (Elizabeth Mattijsen)++ | src/Perl6/Compiler.nqp Fix typo in help |
13:40 | |
| rakudo: usev6++ created pull request #5693: Don't use Match::chomp on string |
16:16 | ||
| ab5tract | I think I've been overthinking the necessary changes for revising &METAOP_NEGATE | 17:58 | |
| I've been doing `$op.($op.(|c), False)` | 17:59 | ||
| but I don't think there's any actual cases where `$op.(|c) == False` wouldn't work | 18:00 | ||
|
18:00
librasteve_ joined
18:07
sena_kun joined
18:13
Geth left,
Geth joined
|
|||
| Geth | nqp/main: 5a04b6411a | (Christian Bartolomäus)++ (committed using GitHub Web editor) | 2 files [JVM] Fix nqp::attrinited for attribute set to null It was wrong to use nqp::isnull for this check with ba4dc47799. An attribute that has been set to nqp::null is still initialized. |
18:14 | |
| rakudo/main: b1f741f308 | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION [JVM] Bump NQP to get bartolin++ attrinited fixes |
18:34 | ||
| ab5tract | The most major open question is whether `ne` can be adjusted in base, because revision gating is not working for it | 18:51 | |
| m: say do if 1 ne 1|3|4 { 0 } else { 1 } | 18:56 | ||
| camelia | 1 | ||
| ab5tract | I'll have to dig into how discussions evolved into deciding that this was the behavior to go with | 18:58 | |
| lizmat | there have been many | 19:00 | |
| have at least 1 closed PR that tried to address this | 19:01 | ||
| ab5tract | I'm hoping that revision gating in general will make it more palatable | 19:09 | |
| FWIW, I personally do not think that `unless $foo eq $bar` --> `if $foo ne $bar` is more valuable than having `ne` DWIM for junctions, but this is obviously a controversial topic | 19:31 | ||
| Geth | roast: 3c50d427e4 | (Christian Bartolomäus)++ | 13 files [JVM] Fudge some failing tests Hopefully we can get back these tests. But for now it's better to fudge them, so that regressions can be noticed. Unfortunately there are more failing tests, but those look harder to fudge from a first glance. I'll try to further look into them. |
19:37 | |
| lizmat | bisectable6: $/ = 42; say "cow cow">>.match(:global, /co(.)/); say $/ | 20:01 | |
| bisectable6 | lizmat, Will bisect the whole range automagically because no endpoints were provided, hang tight | ||
| lizmat, ¦6c (85 commits): «((｢cow｣ 0 => ｢w｣ ｢cow｣ 0 => ｢w｣))42» | 20:02 | ||
| lizmat, Nothing to bisect! | |||
| lizmat | bisectable6: old=2023.04 $/ = 42; say "cow cow">>.match(:global, /co(.)/); say $/ | 20:10 | |
| bisectable6 | lizmat, On both starting points (old=2023.04 new=b1f741f) the exit code is 0 and the output is identical as well | ||
| lizmat, Output on both points: «((｢cow｣ 0 => ｢w｣ ｢cow｣ 0 => ｢w｣))42» | |||
| lizmat | bisectable6: old=2020.01 $/ = 42; say "cow cow">>.match(:global, /co(.)/); say $/ | 20:11 | |
| bisectable6 | lizmat, On both starting points (old=2020.01 new=b1f741f) the exit code is 0 and the output is identical as well | ||
| lizmat, Output on both points: «((｢cow｣ 0 => ｢w｣ ｢cow｣ 0 => ｢w｣))42» | |||
| Geth | nqp: usev6++ created pull request #831: [JVM] Restore size of curlonglit array |
20:13 | |
| rakudo: usev6++ created pull request #5695: [JVM] Unbreak usage of "hash" with named args |
20:42 | ||
| rakudo/main: d3d08962a0 | (Christian Bartolomäus)++ (committed using GitHub Web editor) | src/core.c/Hash.rakumod [JVM] Unbreak usage of "hash" with named args A couple of spectests were failing when "hash" was used with named arguments, like so: $ ./rakudo-j -e 'say hash(a => 1)' Unexpected named argument 'a' passed ... (5 more lines) |
20:46 | ||
| nqp/main: c4b44e979a | (Christian Bartolomäus)++ | src/vm/jvm/runtime/org/raku/nqp/runtime/ThreadContext.java [JVM] Restore size of curlonglit array This was reduced in github.com/Raku/nqp/commit/f02dbe4c9b, but I'm now seeing ArrayIndexOutOfBoundsExceptions in a variety of spectests. One evaluation that died with this error was the following (from roast's ... (7 more lines) |
21:07 | ||
| roast: 298aaac4d4 | (Christian Bartolomäus)++ | 2 files [JVM] Unfudge tests for "hash" with named arg This works again (faster than I thought). Fixed with github.com/rakudo/rakudo/commit/d3d08962a0 |
21:19 | ||
| bartolin | Hh, I just noticed github.com/rakudo/rakudo/commit/aca5e4c129. So ab5tract++ already digged into that, nice. I'm seeing test failures in that direction, but the commit should give me a good start. (But not today.) | 21:38 | |
|
22:47
sena_kun left
|
|||