🦋 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. |
|||
timo | slightly surprised that the naive-word-wrapper puts double space after any period apparently? | 00:18 | |
hm. maybe not after all of them? | 00:19 | ||
m: say "hello there. how are you?".naive-word-wrapper(:50max).raku | 00:20 | ||
camelia | "hello there. how are you?" | ||
[Coke] | -1 from me on that | 00:29 | |
timo | m: $_ = "Hello!"; with 99 -> $sth { say "dollar underscore is $_.raku()"; } else { say "dollar underscore is $_.raku()" } | 00:45 | |
camelia | dollar underscore is "Hello!" | ||
timo | m: $_ = "Hello!"; with Int -> $sth { say "dollar underscore is $_.raku()"; } else { say "dollar underscore is $_.raku()" } | ||
camelia | dollar underscore is Int | ||
timo | m: $_ = "Hello!"; with Int -> $sth { say "dollar underscore is $_.raku()"; } else -> $noth { say "dollar underscore is $_.raku()" } | 00:46 | |
camelia | dollar underscore is "Hello!" | ||
Geth | rakudo/coke/doublespace: 675beed75d | (Will Coleda)++ | src/core.c/Str.rakumod Don't use two spaces after . or ? Per www.chicagomanualofstyle.org/qanda...orTwo.html et al. |
||
rakudo: coke++ created pull request #5913: Don't use two spaces after . or ? |
00:47 | ||
[Coke] | timo++ | ||
timo | Text::Wrap also doesn't support ansi escape codes (i.e. treats them as having a width based on the number of characters in them) | 02:19 | |
japhb | timo: Text::MiscUtils::Layout does this a bit better, methinks. There are a couple different text wrapping algorithms in there, both of which use duospace-width() under the covers, which strips ANSI codes and respects Unicode TR11 width standards. | 03:00 | |
timo | nice. | ||
ooh i like the columns one | 03:02 | ||
lizmat | note it's a "naive" word wrapper, intended to make error messages with variable widths more readable | 07:47 | |
[Coke]: should we merge github.com/MoarVM/MoarVM/pull/1948 before or post 2025.06 release ? | 07:48 | ||
Geth | rakudo/main: 5d9f489dc5 | (Will Coleda)++ (committed using GitHub Web editor) | src/core.c/Str.rakumod Don't use two spaces after . or ? (#5913) Per www.chicagomanualofstyle.org/qanda...orTwo.html et al. |
07:53 | |
lizmat | weekly: wakelift.de/2025/06/20/can-you-say...hat-again/ | 08:04 | |
notable6 | lizmat, Noted! (weekly) | ||
lizmat | timo: .subst(/\W+/, :g).fc # faster cleanup | 08:09 | |
Geth | rakudo/main: 72cdcde409 | (Elizabeth Mattijsen)++ | src/Raku/Actions.nqp RakuAST: ignore RAKU_LANGUAGE_VERSION in EVAL The default of an EVAL should be the current language version, *not* whatever is specified with the RAKU_LANGUAGE_VERSION environment variable. This should now make RAKU_LANGUAGE_VERSION fully functional. |
09:55 | |
rakudo/main: 4768ab5877 | (Elizabeth Mattijsen)++ | src/core.c/Num.rakumod Remove return constraint from atanh/acotanh num sub candidates In 6.e, these may return Complex values when given a negative values, rather than NaN (which is acceptable as a num) |
|||
lizmat | m: use v6.*; say sqrt(my num $x = -1e0) # double checking | 10:06 | |
camelia | NaN | ||
lizmat | that'd be incorrect :- | ||
) | 10:07 | ||
Geth | rakudo/main: f6a3472c0d | (Elizabeth Mattijsen)++ | src/core.c/Num.rakumod Make sure sub sqrt num candidate works correctly on 6.e It was set up to directly use nqp::sqrt_n(), but that produces NaN for negative values. So if the value given is negative, use the method interface instead, which *will* produce a Complex value in 6.e. Also, remove the return constraint because of that. |
10:12 | |
roast: 2c910bdb78 | (Elizabeth Mattijsen)++ | 3 files Adjust atanh() tests for 6.e behaviour Add a 6.d specific file for the 6.d behaviour, and rework the existing atanh() tests to produce Complex values where appropriate (but TODOd for now) |
10:52 | ||
ab5tract | On the one hand, it’s somewhat refreshing to be reminded that Raku blocks can return whatever they please | 11:22 | |
On the other hand, working in statically typed languages has made me more uncomfortable with that very thing :) | 11:23 | ||
This is probably an example with very few (if any) downsides, though. Still makes me wonder if there shouldn’t be a dummy role called Mathy or MathValue or something that bridges across all of these classes | 11:25 | ||
lizmat | I guess there is: Numeric | 11:26 | |
but since none of the other candidates had any return constraint either, I thought I'd bring them in line with that | 11:27 | ||
the absence is probably because of performance | |||
but in the new-disp era, that may not apply | |||
not willing to spend tuits on that atm though | 11:28 | ||
ab5tract | Yeah no worries about that. It was less about the constraint and more about the caller’s requirements | ||
(potential requirements) | 11:29 | ||
Which is to say, as long as they can use a single type constraint to cover all potential return values from a routine, my point is pointless :) | 11:39 | ||
Geth | roast: f3494505eb | (Elizabeth Mattijsen)++ | 3 files Adjust grammar.(sub)parse(file) tests for 6.e behaviour Add 6.e specific file for the 6.d behaviour (in which these methods *do* set $/ in the callers context), and correct the existing tests for the 6.e behaviour to be (which is *not* setting $/). TODO these tests to prevent roast breakage |
12:05 | |
lizmat | grr 6.d specific file :( | ||
Geth | roast: 2ff72620f5 | (Elizabeth Mattijsen)++ | S05-capture/named.t Adjust grammar.parse test for 6.e behaviour Since the test was really about the content of the parse result, just set $/ manually, which works in 6.d as well as in 6.e. |
12:10 | |
[Coke] | lizmat: let's get it now and tested. rather go forward than back | 12:18 | |
lizmat | ok, will do a bump now | 12:19 | |
[Coke] | and we need to get it tested on thoser alpine boxes again also. | 12:20 | |
Geth | nqp/main: cb2c427a33 | (Elizabeth Mattijsen)++ | tools/templates/MOAR_REVISION Bump MoarVM to get latest mimalloc version, MasterDuke++ Also get all of japhb's work on unicode, but that's helper scripts |
12:23 | |
rakudo/main: 25b1a3b124 | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION Bump NQP for MoarVM's mimalloc bump, MasterDuke++ |
12:30 | ||
lizmat | [Coke] ^^ | ||
m: say grammar { token TOP { <.return> }; token return { .+ } }.parse("foo") | |||
camelia | 「foo」 | ||
lizmat | m: use v6.*; say grammar { token TOP { <.return> }; token return { .+ } }.parse("foo") # meh | ||
camelia | Attempt to return outside of any Routine in regex return at <tmp> line 1 in regex TOP at <tmp> line 1 in block <unit> at <tmp> line 1 |
||
[Coke] | lizmat++ | 12:38 | |
ab5tract | lizmat: would it be useful to have an ‘is shaped’ trait for signatures that would match for shaped arrays? | 16:31 | |
Meaning, would that allow us to modify the behavior for :k in the specific case of shaped arrays? | 16:32 | ||
lizmat | as I said in #5907, I think we cannot change the meaning of :k | 16:38 | |
but we could introduce a :c named arg that would be the same as :k for unshaped, but would create coordinate lists for shaped arrays with more than 1 dimension | 16:39 | ||
Geth | rakudo/main: be9b0742ee | (Elizabeth Mattijsen)++ | 2 files (Implicitely) specifying Mu for actions means: no actions when parsing a grammar. Rather then execute any methods that happen to exist on Mu. Fixes .subparse in 6.d, as well as .parse and .subparse in 6.e |
16:59 | |
ab5tract | I wasn’t clear on why we can’t change the behavior of :k, sorry | 17:03 | |
I was therefore contemplating technical solutions | 17:04 | ||
lizmat | well, it feels very deeply entrenched | ||
if would at least require a language version bump | |||
and then we would take away the (faster) "flat" semantics of :k on shaped arrays | 17:05 | ||
hmmm... or course the latter would be less than useful.... hmmm | 17:06 | ||
Geth | roast: d3524ea736 | (Elizabeth Mattijsen)++ | S05-grammar/protoregex.t Remove test for grammar.subparse setting $/ We already have specific tests for 6.d that $/ is getting set, and specific tests for 6.e that $/ is *not* being set. Removin that test makes the test file ready for language bump to 6.e |
17:08 | |
roast: a37a53ffc3 | (Elizabeth Mattijsen)++ | S05-metasyntax/longest-alternative.t Adjust grammar.parse test for 6.e behaviour Since the test was really about the content of the parse result, just set $/ manually, which works in 6.d as well as in 6.e. |
17:11 | ||
roast: 6696213828 | (Elizabeth Mattijsen)++ | 3 files Adjust shaped array:delete tests for 6.e behaviour Add 6.d specific file for the 6.d behaviour (in which an out of bounds :delete throws because the indices are out of range), and correct the existing tests to check for the default value of the array, just like out-of-bounds :delete for unshaped arrays). TODO these tests to prevent roast breakage |
17:35 | ||
ab5tract | lizmat: I might take a stab and see if revision gating works properly there | 17:46 | |
Geth | roast: a44e04e829 | (Elizabeth Mattijsen)++ | 4 files Make role versioning tests 6.e proof Adding a file with 6.d logic, and treat it as any other language level in the tests. Just need to make sure that each role has a different signature to prevent dispatch issues |
18:15 | |
roast: 8c20f6926a | (Elizabeth Mattijsen)++ | integration/99problems-41-to-50.t Adjust truth table test for 6.e behaviour Since the test was really about the content of the parse result, just set $/ manually, which works in 6.d as well as in 6.e. |
18:23 | ||
roast: 1d298bb0dc | (Elizabeth Mattijsen)++ | integration/advent2009-day10.t Adjust inventory test for 6.e behaviour Since the test was really about the content of the parse result, just set $/ manually, which works in 6.d as well as in 6.e. |
18:25 | ||
lizmat | and that concludes my hacking for today | ||
18:45
MasterDuke joined
|
|||
MasterDuke | . | 19:03 | |
tellable6 | 2025-06-18T09:13:48Z #raku-dev <nine> MasterDuke: any progress on the RakuAST fix? | ||
MasterDuke | nine: making slow progress. github.com/MasterDuke17/rakudo/tre..._installed has what i've done so far (aside from roast changes) | 19:23 | |
gist.github.com/MasterDuke17/75444...85f72ba1a1 has the roast changes so far | 19:31 | ||
20:10
melezhik joined
20:11
melezhik left
|
|||
MasterDuke | gist.github.com/MasterDuke17/06fc1...00379698af is what the result of a spectest looks like now | 20:12 | |
m: q|role R { my class C { method C-hi() { say "hi" } }; method R-hi { C.C-hi } }|.AST | 20:15 | ||
camelia | ( no output ) | ||
MasterDuke | hm. locally that's a golf of the failure in t/spec/S12-methods/qualified.t | ||
where i get `Undeclared routine: C used at line 1. Did you mean ''?` | 20:16 | ||
m: q|role R { my class C { method C-hi() { say "hi" } }; method R-hi { C.C-hi } }|.AST.EVAL | |||
camelia | ( no output ) | ||
MasterDuke | yeah, guess it really is a local change that's causing it | 20:17 | |
change the test and it passes, success | 20:21 | ||
afk, but in case anybody has any suggestions, the current error for t/spec/S12-class/magical-vars.t is `===SORRY!=== Error while compiling EVAL_2 | 20:26 | ||
Undeclared routine: evo used at line 1` | |||
20:31
MasterDuke left
|
|||
[Coke] yawns. | 20:52 |