|
🦋 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. |
|||
|
04:02
guifa left
|
|||
| timo | github.com/rakudo/rakudo/issues/5762 did anyone look further into this btw? | 07:44 | |
| linkable6: R#5762 | |||
| linkable6 | R#5762 [open]: github.com/rakudo/rakudo/issues/5762 Basic ACCEPTS regression since 2024.01 | ||
| lizmat | don't think so :-( | 07:49 | |
| timo | OK. i still had it open in a browser tab, that's all | 07:53 | |
| lizmat | I think post RakuAST merge, the generics / archetypes system needs an overhaul | 07:57 | |
| timo | interesting. i wouldn't know what needs to be changed about it, but i haven't looked terribly much at that stuff | 08:03 | |
| lizmat | there's the constant checking: can it do generics, does it need to, and then instantiate the generic | 08:10 | |
|
08:11
sena_kun joined
|
|||
| lizmat | I think that can be simplified by just having each meta class have an instantiate method, that is usually a noop | 08:11 | |
| simplify all the call sites | |||
| roughly from memory :-) | 08:12 | ||
| it's been a year since I dove into that | |||
| Geth | rakudo/main: 1f883a2ffc | (Elizabeth Mattijsen)++ | src/Raku/ast/term.rakumod RakuAST: fix error message type ::OUTER := foo requires an X::Bind error, not a X::Bind::Rebind error, according to t/02-rakudo/13-exceptions.t |
08:39 | |
| lizmat | +1 in make test | ||
|
08:46
finanalyst joined
|
|||
| lizmat | hmm... t/04-nativecall/02-simple-args.t crashes for me also in the legacy grammar | 08:51 | |
| Geth | rakudo/main: 1451385e14 | (Elizabeth Mattijsen)++ | t/12-rakuast/highlight.rakutest RakuAST: remove test for declarator docs on variables As these are not supported anymore since 8bdbc9f8d995c1586 |
08:57 | |
| lizmat | +1 in make test | ||
|
09:07
sena_kun left
|
|||
| Geth | rakudo/main: b38daee87f | (Stefan Seifert)++ | 2 files Add $?CONCRETIZATION to role bodies Don't know what it does exactly. Code taken from the old compiler frontend. |
10:17 | |
| nine | This actually fixed t/spec/S12-methods/qualified.t | 10:18 | |
| Takes us to 1147. Sadly that's the only thing about the generics stuff that I knew I could try | 10:19 | ||
| lizmat | m: Q|my class IO::Path { ||.AST | 10:36 | |
| camelia | WARNINGS for <tmp>: Useless use of "|" in expression "Q|my class IO::Path { ||.AST" in sink context (line 1) No such method 'AST' for invocant of type 'Any' in block <unit> at <tmp> line 1 |
||
| lizmat | m: Q|my class IO::Path {|.AST | ||
| camelia | ===SORRY!=== Redeclaration of symbol 'IO::Path'. at line Missing block at /home/camelia/EVAL_0:1 ------> my class IO::Path {<HERE><EOL> |
||
| lizmat | m: Q|my class IO::Path {}|.AST # grrr | ||
| camelia | ===SORRY!=== Error while compiling Redeclaration of symbol 'IO::Path'. at line |
||
| lizmat | so, the reason is that in scoping, we do: | 10:37 | |
| $scope := 'our'; # Ensure we install the package into the generated stub | |||
| nine | lizmat: rakudo commit b0b6c6ae24328f6887f687488e0a52024a09562a | 10:38 | |
| lizmat | ok, so in case if a forced "our" we should not throw the error in ast/scoping ? | 10:39 | |
| *of | |||
| nine | I mean, that's already fixed. It's just that the fix is on the bootstrap branch | 10:40 | |
| lizmat | mind if I cherry pick that? it would fix a make test test | ||
| nine | not at all | ||
| lizmat | I'm a bit puzzled about this part of the commit message: to create a lexically scoped proxy version of the parent package that knows about the new package | 10:48 | |
| m: my class ZIO::Path { }; dd MY::<ZIO>.WHO<Path | |||
| camelia | ===SORRY!=== Error while compiling <tmp> Unable to parse quote-words subscript; couldn't find '>' (corresponding '<' was at line 1) at <tmp>:1 ------> ass ZIO::Path { }; dd MY::<ZIO>.WHO<Path<HERE><EOL> expecting any of: method a… |
||
| lizmat | m: my class ZIO::Path { }; dd MY::<ZIO>.WHO<Path> | ||
| camelia | ZIO::Path | ||
|
10:48
finanalyst left
10:49
finanalyst joined
|
|||
| lizmat | so: we have the logic to install the stashes in MY:: already, why not just apply that for ones that match stashes in setting ? | 10:49 | |
| what would that break ? | |||
| I mean, we already do that for non-multipart names ? | 10:50 | ||
| m: my class IO { }; dd MY::<IO> | |||
| camelia | IO | ||
| lizmat | m: my class IO { }; my class IO::Path { }; dd MY::<IO>.WHO<Path>; dd IO::Path::Parts # aha, I guess that would be the probkem | 10:54 | |
| camelia | IO::Path Could not find symbol '&Parts' in 'IO::Path' in block <unit> at <tmp> line 1 |
||
| nine | m: my clasS IO { }; dd IO::.keys | ||
| camelia | ===SORRY!=== Type 'clasS' is not declared at <tmp>:1 ------> my clasS<HERE> IO { }; dd IO::.keys Malformed my at <tmp>:1 ------> my<HERE> clasS IO { }; dd IO::.keys |
||
| lizmat | we would need to re-do that search from the setting / OUR:: ? | ||
| nine | m: my class IO { }; dd IO::.keys | ||
| camelia | ().Seq | ||
| nine | This has nothing to do with the setting. It's about shadowing outer declarations in general | 10:55 | |
|
10:55
guifa joined
|
|||
| nine | So this local IO stash would need to know that there's an outer one as well and include that one's symbols in its own responses | 10:55 | |
| IF we want to keep this weird capability that no other language has or needs. | 10:56 | ||
| lizmat | wouldn't that also fix some import issues ? | ||
| nine | maybe? | 10:57 | |
| This is, this is a lot more complexity just to have this one thing that I don't miss at all when coding in other languages. It's all fun saying "torture the implementors" but the truth is, that unmanagable complexity kills companies, kills projects and certainly can kill languages | 11:00 | ||
| lizmat | ok: let me rephrase the question then: | 11:02 | |
| should RakuAST::Type::Setting.new(RakuAST::Name.from-identifier-parts("IO","Path","Parts")) return the class from the setting? | 11:03 | ||
| regardless of having a lexically defined my class IO::Part::Paths, IO::Part or IO ? | |||
| nine | no | 11:04 | |
| lizmat | what does ::Type::Setting then have over ::Type::Simple ? | ||
| nine | Oh, sorry, Type::Setting does | ||
| lizmat | it doesn't at the moment | ||
| nine | I think there's even a TODO comment to that effect | 11:05 | |
| lizmat | todo "no actual lookup in SETTING only yet"; | ||
| indeed | |||
| so you're saying it is indeed correct that that doesn't work yet, or that it will not work ever ? | |||
| nine | Shows how I've spent waaaaaay too much time in this code base :D | ||
| it's still todo | 11:06 | ||
| Geth | rakudo/main: 7f0474c371 | (Stefan Seifert)++ (committed by Elizabeth Mattijsen) | src/Raku/ast/scoping.rakumod RakuAST: fix unwanted redeclaration error on my scoped multi-part-name packages A my-scoped package with a multi-part name like X::Await::Died pus into a bit of a conundrum. On the one hand it should only be visible in the lexical scope it was declared in, as the my-scope requests. On the other hand packages for a namespace hierarchy and the "Died" class we declare should be available in X::Await's stash. Thus if the root package ... (15 more lines) |
11:07 | |
| lizmat | ack, ok then I'll leave that for now and push the cherry-pick :-) | ||
| nine | What do we do about label.t? | 11:17 | |
| lizmat | so, looks like "@ = (...) doesn't sink in RakuAST ? | 11:23 | |
| nine | irclogs.raku.org/raku-dev/2025-04-05.html#09:53 | 11:24 | |
| Geth | roast: 195fa6a8b0 | (Elizabeth Mattijsen)++ | S04-statements/label.t Make test clearer as to what fails if something fails And mark the test as "todo" if we're in RakuAST. See irclogs.raku.org/raku-dev/2025-04-05.html#09:53 |
11:28 | |
| nine | Well my argument was more that it's broken in main, rather than RakuAST. The latter does have the more consistent behavior. Also that environment variable won't be there for much longer. As soon as RakuAST becomes the default, we won't set it anymore and that test will fail again. | 11:29 | |
| lizmat | and will draw our attention then again | 11:30 | |
| ok, github.com/rakudo/rakudo/issues/3622 was about the structure crashing | 11:33 | ||
| so all three of those cases should just be in a lives-ok ? | 11:34 | ||
| Geth | roast: 8bb5bf54fd | (Elizabeth Mattijsen)++ | S04-statements/label.t Make label tests about whether they don't crash rather than enshrine particular behaviour in a very strange setup. As originally mentioned in github.com/rakudo/rakudo/issues/3622 |
11:41 | |
| lizmat | afk for a few hours& | 11:42 | |
|
11:59
guifa left
|
|||
| Geth | roast: 561cfdb285 | (Stefan Seifert)++ | S14-roles/versioning.t Fix test failing for unrelated reasons The versioning test is not about whether we generate a POPULATE method (that would be an implementation detail). The expectation of there being a POPULATE method is just to accomodate that the compiler may generate one. The way the test was written though would fail if the compiler didn't. Change the test to cope with a generated constructor being present but also not fail if it isn't. |
12:02 | |
| nine | vrurg: if you take care of t/spec/S02-types/generics.t t/spec/S02-types/is-type.t and t/spec/S02-types/nominalizables.t we have a fully passing spectest with RakuAST :) | 12:05 | |
|
13:16
JimmyZhuo joined
|
|||
| JimmyZhuo | lizmat: about assuming: The current implementation of assuming – used to curry or otherwise prime arguments for a routine – is not ideal, and an implementation that takes advantage of the argument rewriting capabilities of the new dispatcher would likely perform a great deal better. from: | 13:17 | |
| 6guts.wordpress.com/2021/03/15/tow...new-genera | |||
| l-dispatch-mechanism-in-moarvm/ | |||
| timo | hm. there could be a dispatcher that takes something like an "instruction list" for how the arguments should be manipulated, and then just like usual invoke dispatchers, the target to be invoked and then the arguments that were passed to the assumed sub? | 13:23 | |
| might still require code to be genned so that when the assumed version of the code is invoked spesh will see that there's few enough relevant candidate dispatch programs / recordings? | 13:25 | ||
| vrurg | nine: wow, that's quite an achievement! | ||
| timo | so that in a big program with lots of usage of assuming and/or assumed routines we don't end up having to go through 500 candidates every time we come across one. like, if there's a single sub that's closure-cloned into all "candidates" | 13:26 | |
| JimmyZhuo | my $target := -> $x, $y { $x ~ $y } | 13:27 | |
| nqp::register('insert-world', -> $capture { | |||
| my $capture-derived := nqp::dispatch('boot-syscall', | |||
| 'dispatcher-insert-arg-literal-str', $capture, 2, 'world'); | |||
| nqp::syscall('dispatcher-delegate', | |||
| 'boot-code-constant', $capture-derived); | |||
| }); | |||
| sub insert() { nqp::dispatch('insert-world', $target, 'hello ') } | |||
| insert a arg? | |||
| timo | thinking something like 'swizzle-params', -> $cap { my $program = nqp::atpos($cap, 0); for $program { my $op = $_[0]; if $op eq "insert" { ... } elif $op eq "insert_named" { ... } ... } } | 13:30 | |
| it may have to be a bit more "intelligent" than just "insert", "drop", etc | 13:31 | ||
| lizmat | .assuming also handles named arguments, fwiw | 13:40 | |
| and generics | |||
| timo | what do you mean by generics? | ||
| lizmat | m: sub a(::T $a, T $b) { }. my &b = &a.assuming(42) would codegen an Int $b in the generated sub | 13:42 | |
| camelia | ===SORRY!=== Error while compiling <tmp> Preceding context expects a term, but found infix = instead. Did you make a mistake in Pod syntax? at <tmp>:1 ------> sub a(::T $a, T $b) { }. my &b =<HERE> &a.assuming(42) would codegen an In |
||
| lizmat | m: sub a(::T $a, T $b) { }. my &b = &a.assuming(42) # would codegen an Int $b in the generated sub | ||
| camelia | ===SORRY!=== Error while compiling <tmp> Preceding context expects a term, but found infix = instead. Did you make a mistake in Pod syntax? at <tmp>:1 ------> sub a(::T $a, T $b) { }. my &b =<HERE> &a.assuming(42) # would codegen an |
||
| lizmat | m: sub a(::T $a, T $b) { }; my &b = &a.assuming(42) # would codegen an Int $b in the generated sub | ||
| camelia | ( no output ) | ||
| timo | nice. but that's probably more about the signature, less about the code that does the actual invocation? | ||
| ah, in order to actually install a proper signature, we'll probably have to have a new code object in any case? or can there be many Routine objects that get one signature but re-use the same underlying code object? | 13:43 | ||
| lizmat | in the RakuAST implementation I did generate a new underlying code object without any caching | 13:44 | |
| nine | You can't share the code object as that's what's holding the name | 13:46 | |
| Geth | rakudo/main: 06c9693436 | (Stefan Seifert)++ | t/02-rakudo/08-inline-native-arith.t RakuAST: todo an optimizer related test |
13:47 | |
| rakudo/main: f99300212f | (Stefan Seifert)++ | 2 files RakuAST: support $?LANG |
|||
| nine | Turns out, $?LANG was all that was missing for that slang test. | ||
| timo | not sure what you mean by name. do we give anonymous code an autogenerated name? | ||
| lizmat | the code object gets the same name as the original code object, afaik | 13:49 | |
| nine | Code.name is implemented via nqp::getcodename on the $!do | ||
| timo | m: say &say.name | ||
| camelia | say | ||
| nine | So what broke those 3 NativeCall tests even on main without RakuAST? | ||
| lizmat | bisectable6 should be able to give us an idea, maybe ? | 13:50 | |
| if we can golf to something it can run ? | |||
|
13:50
JimmyZhuo left
|
|||
| timo | Two terms in a row - DLLEXPORT int⏏ NCstrlen(const char *x) | 13:52 | |
| haha i'm dumb never mind | 13:53 | ||
| nine | It's 4d4ac9fce3103821d25d1678154b6a29018ad7a7 in nqp | 13:58 | |
| linkable6 | (2025-04-06) github.com/Raku/nqp/commit/4d4ac9fce3 Use correct typed accessors where able | ||
| Geth | nqp/main: 703149cbb3 | (Stefan Seifert)++ | 2 files Revert "Use correct typed accessors where able" This reverts commit 4d4ac9fce3103821d25d1678154b6a29018ad7a7. |
||
| lizmat | nine: wow I didn't see that coming | 13:59 | |
| [Coke] | github.com/rakudo/rakudo/issues/5843 | ||
| lizmat | nine: wouldn't that just indicate that NativeCall is (incorrectly) depending on the HLLization ? | ||
| nine | Too little information to speculate about anything | 14:01 | |
| [Coke] | it did break 4 blin tests. | ||
| timo | Geth: 4d4ac9fce3103821d25d1678154b6a29018ad7a7 | 14:02 | |
| i seem to recall one of our bots can take a sha1 that's a bump and give links to the commits from the target repo | |||
| [Coke] | (blin also complained about the merge commit for the last release on Text::Markdown::Discount –, which makes no sense. | ||
| timo | releasable6: bump 4d4ac9fce3103821d25d1678154b6a29018ad7a7 | ||
| releasable6 | timo, I cannot recognize this command. See wiki for some examples: github.com/Raku/whateverable/wiki/Releasable | ||
| timo | ah, it is geth. it wants "ver" as the command | 14:03 | |
| Geth: ver 4d4ac9fce3103821d25d1678154b6a29018ad7a7 | |||
| probably wants a full github link though | |||
| Geth: ver github.com/Raku/nqp/commit/4d4ac9f...29018ad7a7 | 14:04 | ||
| Geth | timo, version bump brought in these changes: github.com/MoarVM/MoarVM/compare/ | ||
| nine | What are you looking for? | ||
| timo | ah, it's not a moar bump haha | ||
| nine | Why would I revert a bump? That wouldn't do anything | ||
| timo | that's als otrue | 14:05 | |
| nine | ab5tract: can you please take care of t/02-rakudo/12-multi-revision-gated.t? It's broken by the warning you added to RakuAST in commit d47c8febdd817089f75602617051f40d296731c7 | 14:15 | |
| linkable6 | (2023-11-05) github.com/rakudo/rakudo/commit/d47c8febdd RakuAST: Make multi subs check for re-declaration of signatures | ||
| ab5tract | Will look into it | 14:20 | |
| [Coke] | If someone can re-bump nqp so rakudo isn't depending on that reverted commit, thanks. | 14:25 | |
| lizmat | will do | 14:26 | |
| [Coke] | "Takes us to 1147". 1347? | 14:28 | |
| nine | Yes, 1347 | 14:30 | |
| lizmat | i'm at 1348 ? | 14:37 | |
| Geth | rakudo/main: f140ce2cc0 | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION Bump NQP to revert nqp getattrr micro opt Which was causing NativeCall / Blin fallout |
14:38 | |
| [Coke] | manual test of Red on the blin machine @f140ce2cc0 is clean | 16:21 | |
| lizmat | 1349 now | 16:23 | |
|
16:33
finanalyst left
16:35
finanalyst joined
|
|||
| [Coke] | which file is left? | 16:36 | |
|
17:16
finanalyst left
|
|||
| timo | github.com/microsoft/mimalloc/issues/1068 | 17:18 | |
| [Coke] | 18 failures in 'make test', so up to 148/166 | 17:34 | |
| (with AST) | |||
| gist.github.com/coke/baec4771116a5...519ba9adcd | 17:35 | ||
| 6 of those are explicitly macros, one is t/12-rakuast/xx-fixed-in-rakuast.rakutest | 17:36 | ||
| (on non-ast, several macros failures and the xx-fixed in has a 2 TODO passes) | 17:45 | ||
| nine | [Coke]: the 3 I mentioned to vrurg | 18:05 | |
| [Coke] | ok - sounds like your numbers and liz's aren't quite matching, as I think she was down to a single file. | 18:20 | |
| no worries. | |||
| nine | I just stopped counting passes when I knew all remaining failing ones by name | 18:22 | |
| [Coke] | :) | 18:33 | |
| japhb | .oO( "You think you're safe? I KNOW YOU." ) |
18:52 | |
| SmokeMachine | [Coke]: \o/ thanks! | 19:08 | |
| [Coke] | SmokeMachine: of course, happy to - easier than fixing blin at the moment. :) | 19:32 | |
| should passing TODO tests in the errata roast branches be untodo'd? | 20:07 | ||
| (and master) | 20:11 | ||
| nine | Mystery of the day: how on earth does %BLOCKS_DONE end up in Raku precomp files? And how does a RakuAST::Block end up in that hash? | 20:13 | |
| For the latter I presume because it's in $*BLOCK, but QASTCompilerMAST which uses a %*BLOCKS_DONE declares its own $*BLOCK, so that should not matter. | 20:14 | ||
| I can say that %BLOCKS_DONE gets imported in a use QAST:from<NQP>; but no idea how it ends up getting exported from that | 20:15 | ||
| Ok, one more piece: QAST gets generated from gen/moar/stage2/QAST.nqp which is all QAST stuff combined including QASTCompilerMAST | 20:16 | ||
| Huh...the two mysteries may actually be connected. Dynamic variables in NQP have a GLOBAL fallback. So if they are not declared explicitly, they do get up declared in GLOBAL with a default value. So for both variables we seem to somehow miss their declaration in the call stack. | 20:23 | ||
| And the answer is: ProxyReaderFactory!produce-reader! | 20:29 | ||
| That's part of the dispatchers used for dispatch to multis with an argument that is a Proxy. It compiles a little code block that reads the value from the proxy, but it doesn't wrap this block in a compunit. Thus we never declare those dynamic variables, as that's done when we encounter the QAST::CompUnit node | 20:32 | ||
|
20:46
finanalyst joined
20:57
guifa joined
21:40
finanalyst left
22:13
sena_kun joined
|
|||
| [Coke] | S32-io/IO-Socket-Async.t has a hardcoded port (5000) - I think this is why it's considered a flapper (github.com/Raku/roast/issues/868) - Any thoughts on randomly picking a port so it's at least more likely to pass? | 22:43 | |
| Geth | roast: 4842c11085 | (Will Coleda)++ | S32-io/IO-Socket-Async.t Don't use hardcoded port known to fail on OS X Workaround for #868 |
22:46 | |
| linkable6 | ROAST#868 [open]: github.com/Raku/roast/issues/868 S32-io/IO-Socket-Async.t fails on my mac | ||
|
22:52
sena_kun left
|
|||
| ugexe | setting the port to 0 has the OS pick the port | 23:06 | |
| although you still have to get the port for the connection socket (presumably this can be obtained from the server socket object) | 23:07 | ||
| yeah, see the commit message for github.com/rakudo/rakudo/commit/cb...5957cb1159 | 23:08 | ||