[00:00] *** reportable6 left [00:01] *** reportable6 joined [01:16] *** Xliff left [01:37] *** NemokoschKiwi joined [01:39] *** NemokoschKiwi left [01:44] *** AlexDaniel joined [03:27] *** AlexDaniel left [03:50] *** epony left [04:51] *** epony joined [05:51] *** evalable6 left [05:51] *** linkable6 left [05:52] *** linkable6 joined [05:54] *** evalable6 joined [06:00] *** reportable6 left [06:01] *** reportable6 joined [07:01] *** benchable6 left [07:01] *** sourceable6 left [07:01] *** nativecallable6 left [07:01] *** quotable6 left [07:01] *** unicodable6 left [07:01] *** bloatable6 left [07:01] *** reportable6 left [07:01] *** greppable6 left [07:01] *** coverable6 left [07:01] *** tellable6 left [07:01] *** shareable6 left [07:01] *** notable6 left [07:01] *** bisectable6 left [07:01] *** releasable6 left [07:01] *** evalable6 left [07:01] *** committable6 left [07:01] *** notable6 joined [07:02] *** shareable6 joined [07:02] *** evalable6 joined [07:02] *** committable6 joined [07:02] *** coverable6 joined [07:02] *** unicodable6 joined [07:02] *** nativecallable6 joined [07:02] *** bisectable6 joined [07:03] *** reportable6 joined [07:03] *** tellable6 joined [07:03] *** benchable6 joined [07:03] *** bloatable6 joined [07:03] *** greppable6 joined [07:04] *** quotable6 joined [07:04] *** releasable6 joined [07:04] *** sourceable6 joined [07:39] ¦ rakudo/main: 48e61f8a18 | (Stefan Seifert)++ | 3 files [07:39] ¦ rakudo/main: RakuAST Fix stub packages preventing declaration of the real package [07:39] ¦ rakudo/main: [07:39] ¦ rakudo/main: This is not yet 100 % there as we still run the BEGIN handler on the [07:39] ¦ rakudo/main: stub package. It's hard not to, because that's run before we even parse [07:39] ¦ rakudo/main: the package body, so we cannot know yet that it's just a stub. [07:39] ¦ rakudo/main: review: https://github.com/rakudo/rakudo/commit/48e61f8a18 [08:20] ¦ rakudo/main: b4fe21c260 | (Stefan Seifert)++ | src/Raku/ast/pair.rakumod [08:20] ¦ rakudo/main: RakuAST: fix canonicalization for non-literal colonpair values [08:20] ¦ rakudo/main: [08:20] ¦ rakudo/main: If a name part doesn't have a simple compile time value, all we can do [08:20] ¦ rakudo/main: is deparse for canonicalization. Needed for e.g. Int:D(Cool) [08:20] ¦ rakudo/main: review: https://github.com/rakudo/rakudo/commit/b4fe21c260 [08:23] *** Geth left [08:23] *** Geth joined [08:24] m: use MONKEY-SEE-NO-EVAL; EVAL Q[my Int:D(Cool) $i = "1"].AST [08:24] rakudo-moar 48e61f8a1: OUTPUT: «Use of Nil in string context␤ in block at line 1␤Use of Nil in string context␤ in any IMPL-QUOTE-VALUE at src/Raku/ast/pair.rakumod line 55␤Type check failed in assignment to $i; expected Int:D but got Str ("1")␤ in block Finally found a test that breaks because derived types don't stack yet [09:31] but: isn't my Int:D(Cool) wrong? Shouldn't it be Int(Cool) ? [09:31] I mean, we can only coerce instantiated values, no? [09:34] *** ab5tract joined [09:39] nine: Is it possible to convert a `RakuAST::Declaration::External::Constant` into an actualy type object? I ask because the refinee of a SubsetHOW is a type object. I don't see any mention of the refinee in either base or ast QAST. [09:47] lizmat: that's from a spectest [09:48] ab5tract: .compile-time-value [09:48] Yeah, you will only find such details in the meta object itself, not in the QAST [09:49] *** sena_kun joined [09:50] nine: thanks! [09:53] In general: from within the node (e.g. I need the code object this RakuAST::Routine represents) it's .meta-object and from outside it's .compile-time-value [10:05] Very helpful, thanks! [10:05] Well, I've got it doing just about everything! ... except actually working [10:06] err...wat? [10:26] err...wat? [10:29] ~. [11:04] :) [11:05] I mean, it compiles, the QAST looks mostly good. It works when the subset is declared in packages. It just always fails the type check [11:07] Does it run the where expression? [11:09] From what I can see, no. [11:11] no, it does not (according to my uber-sophisticated debug logging of inserting a 'say' into the where block) [11:20] lol [11:23] it was a matter of passing the `$!where` to the SubsetHOW.new_type generator before `$!where` was defined. Moved the assignment from PRODUCE-STUBBED-META-OBJECT to PRODUCE-META-OBJECT via a new method `set_where` on SubsetHOW and voila! [11:24] There's some copy-pasta in there that might appreciate some guru-level inspection, but otherwise this is looking good [11:24] ab5tract: please don't forget to add deparsing and tests :-) [11:24] or tell me to do it :-) [11:31] yeah, that might be a bit tricky... so I take it tests are separate from the current test suite? [11:32] It's just tests in t/12-rakuast i.e. tests that create RakuAST nodes manually and check if they do the same as the parsed AST. [11:34] Okay, interesting. [11:34] and deparsing? [11:37] damn, there's something broken about using WhateverCode with where [11:38] and setting a parameter to a subset type doesn't seem to do the check either [11:39] That's basically included in those tests. [11:40] I'd try it first with an explicit block. Then when that works move on to thunking [11:47] yeah, using an explicit block doesn't do anything WRT parameter type checking [11:47] I do see in the source "# Do type checks.\n # TODO really more involved than this" [11:48] for `RakuAST::Parameter` [11:51] *** raschip joined [11:53] It already is much more involved than when that was written :) But anyway, what about my subset Foo where { $_ > 5 }; my Foo $i = 10; [11:57] yeah, that works fine [11:58] as does `my subset Foo where 5; my Foo = 4` [11:58] Including running the where block? [11:59] yes, the where block runs, according to any `say` implanted there [12:00] *** reportable6 left [12:01] *** reportable6 joined [12:04] branch is now fully up to date [12:05] ab5tract: if you feel up to writing tests, please do [12:06] if you'd rather attack another piece of RakuAST, lemme take care of the tests and deparsing then, for efficiency's sake :-) [12:07] Well first that thing has to work anyway :) [12:07] okay, sound good. [12:07] yeah, there's that lol [12:08] it also fails with confused when running: `'my subset Foo where { $_ > 5 }; my Foo $i where { $_ < 15 } = 10; say $i' [12:08] TIL you could double constrain like this [12:09] *** kjp left [12:10] *** kjp joined [12:20] The add-trait loop should be in actions. It's like that for all other trait holders [12:21] ¦ rakudo/main: f98f316c19 | (Elizabeth Mattijsen)++ | src/Raku/ast/statements.rakumod [12:21] ¦ rakudo/main: RakuAST: Add support for "use MONKEY" [12:21] ¦ rakudo/main: [12:21] ¦ rakudo/main: The other MONKEY-... were already supported [12:21] ¦ rakudo/main: review: https://github.com/rakudo/rakudo/commit/f98f316c19 [12:23] Determining the current-package must be done in attach, not PERFORM-BEGIN. You don't know where we actually are when BEGIN is triggered. In attach you're guaranteed to get the right answer. [12:24] ok, will make that change [12:24] ¦ rakudo/main: 886a00d1cc | (Elizabeth Mattijsen)++ | 6 files [12:24] ¦ rakudo/main: RakuAST: Add Nqp and Nqp::const classes [12:24] ¦ rakudo/main: [12:24] ¦ rakudo/main: - create new source and test file [12:24] ¦ rakudo/main: - move nqp logic from Call::Name to Nqp [12:24] ¦ rakudo/main: - add direct support for nqp::const in grammar [12:24] ¦ rakudo/main: - add deparsing [12:24] ¦ rakudo/main: - add tests [12:24] ¦ rakudo/main: review: https://github.com/rakudo/rakudo/commit/886a00d1cc [12:25] it looks like the ast fails for `my $i where { $_ < 10 } = 5`, so it's not specific to subsets [12:25] s/the ast/RakuAST/ [12:26] What does RakuAST::VarDeclaration::Implicit::Constant have to do with the traits in Subset? [12:27] Nothing, that was just a thinko [12:27] You're referring to the comment about it maybe not being necessary? [12:28] yes [12:31] Yeah, that's just a brain fart. Please ignore [12:45] Moving all current-package related stuff to `attach` results in "Lexical 'Foo' already declared" for 'my subset Foo of Int where { $_ > 5 }; my Foo $i = "6"; say $i.raku' [12:48] Err..."all current-package related stuff" what does that mean exactly? I said "determining the current-package". That's precisely what I meant ;) [12:51] (^_^) [12:53] Does your PRODUCE_META actually get called when you try it on a parameter? [13:05] checking [13:08] yes, it does [13:10] *** evalable6 left [13:13] *** evalable6 joined [13:14] okay, this is interesting... 'module M { module N { subset F where { say "in where!"; $_ == 5 } } }; -> M::N::F $w { say $w }("w")' --> prints 'w' [13:15] adding 'of Int' a la 'module M { module N { subset F of Int where { say "in where!"; $_ == 5 } } }; -> M::N::F $w { say $w }("w")' --> dies with exception in binding parameter [13:17] but the exception mentions `Int`, not `M::N::F` as in base [13:18] Yes, that exception is due to failure to match the nominal type [13:19] The old frontend does generate QAST for doing that subset match: [13:19] │ │ │ - QAST::ParamTypeCheck [13:19] │ │ │ - QAST::Op(istrue) [13:19] │ │ │ - QAST::Op(callmethod ACCEPTS) [13:19] │ │ │ - QAST::WVal(Foo) [13:19] │ │ │ - QAST::Var(local __lowered_param__2) [13:20] so, it's interacting with the subset to some degree, to get that nominal type? just not enough to actually run the where block.. [13:22] also: how does one generate a QAST::Var of "local __lowered_param_2" from code? [13:24] I think src/Perl/Actions.nqp:5956 is responsible for that. It adds the type as post constraint if its nominalizable [13:26] Oh, don't worry about that. That's the result of $get-decont-var() which you can just use as is. See related code in RakuAST::Parameter::IMPL-TO-QAST [13:27] ok, nice! [13:28] ab5tract++ [13:38] does `nqp::istype()` include all of the `is` classes in its lookup? I noticed this returned false for a `RakuAST::Trait::Of` when checking against `RakuAST::Trait` [13:39] erm, sorry. that might be a bit confusing: `nqp::istype($object, RakuAST::Trait)` returned false when $object was a `RakuAST::Trait::Of` [13:41] I'm wondering if something similar is happening when a `CurryThunk` is used as a where clause when it checks whether the type is `RakuAST::Code` [13:41] Hm....may be a good time to point a serious gotcha when working in NQP: it doesn't care if a multi part name actually exists. So it will happily accept I::Dont::Exist and just evaluate it to NQPMu [13:42] that's very good to know [13:45] not sure if it applies here though? I tried using `set-traits($traits)`. That code checks whether every element in the list is of type `RakuAST::Trait` but failed when a `RakuAST::Trait::Of` element was found. [13:45] Rather than hacking that, I just unwrap the list and add the trait manually [13:47] but yeah, if `nqp::istype($thing, RakuAST::Code)` fails for a `RakuAST::CurryThunk`, it might explain what's going on with wheres and whatever codes at the moment. [13:48] Sorry, I'm jumping around between problems and questions that have come up while hacking on this [13:48] So it could be that OAOB [13:48] hmm, my font is missing some crucial characters for rendering that line [13:48] Oops...sorry, very spotty connection on this train [13:49] It could be that you need some forward declarations for these types. [13:50] type.rakumod comes before code.rakumod in tools/templates/raku_ast_sources [13:52] will plain old stubbing do? or do I need to do some fancy nqp magic [13:56] strangely enough, it does DWIM when I pass it an honest `RakuAST::Code` [13:57] a la `subset F where { $_ == 5 }` [13:59] FWIW, '-> Str $w where *.comb == 1 { say $w }("w")'' fails with the new frontend: 'This type cannot unbox to a native integer: P6opaque, WhateverCode' [14:00] okay, well I'm pretty stoked to have gotten subsets semi-working :D [14:00] current issues: [14:00] 1) WhateverCode doesn't work [14:00] 2) It doesn't work with parameters [14:12] Ok, disrecard the subbing thing. The RakuAST compiler does that already [14:12] And other classes like BeginTime refer to RakuAST::Code without doing anything special [14:16] [14:16] ~,~. [14:17] ah! `* ~~ 5` is not a RakuAST::Code, its a RakuAST::ApplyInfix [14:19] very fortunate; it would make typegenning for s/// and m// smartmatches to something other than ACCEPTS [14:20] Nemokosch: I don't totally understand what you mean [14:20] ab5tract, I'll pass your message to Nemokosch [14:23] sorry, this was somewhat off-topic [14:24] simply put, I'm very unhappy with the way 'foo' ~~ m/o/ and the likes work. Not the outcome per se but the technical implications of it [14:25] and the way RakuAST is designed could help saving the end-user behavior without the bizarre implications [14:27] Pro tip: when connected to the Wifi on a German train, set wireguard MTU to something smaller! [14:28] ab5tract: * ~~ 5 needs to be thunked [14:29] "thunking" basically means wrapping it in a block, so it becomes a code object [14:29] But then I see you already have code that should do that [14:36] Btw. your visit-children is incomplete. It's missing 2 children. All RakuAST nodes stored in your node must be visited [14:44] good to know! [14:45] nine: something is broken with the current thunking WRT to WhateverCodes. The place I lifted my "thunking" from (signature's handling of where) is also broken for whatevercodes [14:46] shouldn't I be able to simply call $!expr.IMPL-CURRY ? [14:47] I am less than surprised :D [14:47] Currying should be done automatically by BEGIN handlers. [14:50] It's quite possible that we don't curry everything yet. Only infixes and postcircumfixes AFAIK [15:11] infixes should cover Applyinfix, or is it just regular infixes at the moment? [15:12] nvm, I can look into the source :) [15:30] I can't see why this little thunk-wrapper isn't working as expected :/ [15:31] Of course it's always possible that the expectation is wrong [15:33] how do you mean? [15:38] Maybe nothing. What t^Hdoes the QAST look like? [15:41] I see a big difference between the result of * == 5 and * ~~ 5 [15:47] indeed. There's a WVal(Regex) in the smartmatch [15:48] And both base and * == 5 include a 'QAST::Op(chain &infix:<~~>)' [15:49] (* == 5 includes 'QAST::Op(chain &infix:<==>) ', of course [15:50] *** AlexDaniel joined [16:10] Subset must not handle ApplyInfix any differently. If it needs to we have problems elsewhere [16:23] *** melezhik joined [16:30] *** melezhik left [16:31] nine++ [16:33] *** melezhik joined [16:36] *** melezhik left [17:15] m: say 42 [17:15] rakudo-moar 886a00d1c: OUTPUT: «42␤» [17:15] e: say 42 [17:16] c: HEAD say 42 [17:16] AlexDaniel, ¦HEAD(d52342e): «42␤» [17:16] AlexDaniel, rakudo-moar d52342eb0: OUTPUT: «42␤» [17:16] uhhhhhh what's going on [17:17] that's 2 months old?? [17:17] shareable6: HEAD [17:17] AlexDaniel, https://whateverable.6lang.org/HEAD [17:19] c: 886a00d1cca211051421b466cb11fb2b14604663 say 42 [17:19] AlexDaniel, ¦886a00d: «42␤» [17:20] hm I don't get it [17:20] oh. You changed the main branch [17:21] yeah, shortly after 2022.12 [17:21] it's got RakuAST in it now [17:21] and it works and it's the default? [17:22] please fix anything here if it needs fixing: https://github.com/Raku/whateverable/search?q=master [17:22] I'll try to unstuck the repository [17:25] you need to activate it with "use experimental :rakuast" [17:25] a ok then [17:25] and the new Raku grammar only passes about 50% of spectests [17:25] c: HEAD say 42 [17:25] AlexDaniel, ¦HEAD(886a00d): «42␤» [17:25] m: say 42 [17:25] rakudo-moar 886a00d1c: OUTPUT: «42␤» [17:25] that looks ok now :-) [17:25] ok that was easier than I thought. Just removed the repos and let whateverable to clone them again [17:26] and it didn't need to build all the commits since 2022.12 because it keeps building commits on all branches anyway, even if it's not the main branch [17:28] <[Coke]> AlexDaniel++ [17:41] nine: Could the issue be that typename in Actions isn't attaching a RakuAST::Type::Subset? [17:43] unlike all the other type options, there is nothing from syntactically that we can use to distinguish whether the parameter type is a subset [17:44] eg, it checks for colonpairs and then creates types that care about definedness, coercive when there is $, etc [17:46] But you already verified that Subset's PERFORM-BEGIN gets called even for a parameter, didn't you? [17:47] Ah, wait, that made no sense. Declaration vs. use [17:47] right, was just realizing that [17:47] When the name is resolved, you know that you got a Subset type [17:47] the where block definitely doesn't get called for parameter [17:48] Do you mean nominal types won't resolve? Or am I misunderstanding you [17:49] ie, are you proposing a way to know whether to create a Subset vs creating a Simple? [17:54] subset Foo where * == 5; sub foo(Foo $i) { } [17:56] When we parse the definition of foo, we encounter parameter $i and its type. We then resolve the name "Foo" and get a RakuAST::Term::Name that is resolved to the RakuAST::Type::Subset [17:57] I.e. in RakuAST::Parameter $!type.resolution gives you that Subset node. And $!type.meta-object gives you a SubsetHOW object [18:00] In RakuAST::Parameter::IMPL-TO-QAST we already check whether a type is archetype definite or archetype generic. Maybe we need to be even smarter there [18:00] *** reportable6 left [18:00] *** evalable6 left [18:01] *** evalable6 joined [18:03] *** reportable6 joined [18:15] *** AlexDaniel left [18:16] *** AlexDaniel left [18:16] ab5tract: in the old frontend I see something about nominalizable types getting pushed as post constraint on parameters [18:17] src/Perl6/Actions.nqp:5956 [18:18] And in :10073 we generate an ACCEPTS call for each post constraint that isn't just a literal [18:19] While in the current RakuAST implementation only $!where gets that treatment [18:40] ¦ rakudo/main: 97ecc4d713 | (Elizabeth Mattijsen)++ | 5 files [18:40] ¦ rakudo/main: RakuAST: further refine handling of nqp::ops [18:40] ¦ rakudo/main: [18:40] ¦ rakudo/main: - Classes should inherit from RakuAST::Expression [18:40] ¦ rakudo/main: - Allow passing of List or RakuAST::ArgList as only argument [18:40] ¦ rakudo/main: - Convert Str|Int args on the fly to Str|IntLiteral [18:40] ¦ rakudo/main: - Remove unneeded methods now that we inherit from RakuAST::Expression [18:40] ¦ rakudo/main: - Add more tests [18:40] ¦ rakudo/main: review: https://github.com/rakudo/rakudo/commit/97ecc4d713 [18:40] brings us to 128/140 for make test [18:46] Oooh...which one did it fix? [18:46] By now there are so few failing ones that I know them by name :) [18:46] not sure, actually... do you want me to figure out? [18:46] Only if you're curious, too [18:46] not really :-) [18:47] not enough [18:49] I am 🙊 [18:49] then go back one commit, run the tests and remember the files that passed and see what the difference is [18:50] Okay, also not enough, to be honest xd [18:52] nine: trying that now [19:10] nine: considering creating classes for pragmas, isms and repository (aka "use lib") [19:10] and plugging those in at the right place, eventually in the grammar [19:10] opinions? [19:11] ¦ rakudo: usev6++ created pull request #5179: Fix test description for unknown modifier [19:11] ¦ rakudo: review: https://github.com/rakudo/rakudo/pull/5179 [19:14] ¦ rakudo/main: 69f1aa1f4f | (Christian Bartolomäus)++ (committed using GitHub Web editor) | t/02-rakudo/14-revisions.t [19:14] ¦ rakudo/main: Fix test description for unknown modifier (#5179) [19:14] ¦ rakudo/main: [19:14] ¦ rakudo/main: It looks like the test description has been copied from the previous [19:14] ¦ rakudo/main: sub-test in commit 3f25ba9212 (which added these tests). [19:14] ¦ rakudo/main: review: https://github.com/rakudo/rakudo/commit/69f1aa1f4f [19:15] ¦ rakudo/main: c88f50d5e8 | (Christian Bartolomäus)++ | 2 files [19:15] ¦ rakudo/main: [JVM] Fix breakage with "use v6.e.PREVIEW" [19:15] ¦ rakudo/main: [19:15] ¦ rakudo/main: After a recent rework of language versioning (merge commit a815b5ca12) [19:15] ¦ rakudo/main: the JVM backend started to throw an error when it encountered [19:15] ¦ rakudo/main: [19:15] ¦ rakudo/main: use v6.e.PREVIEW; [19:15] ¦ rakudo/main: [19:15] ¦ rakudo/main: <…commit message has 8 more lines…> [19:15] ¦ rakudo/main: review: https://github.com/rakudo/rakudo/commit/c88f50d5e8 [19:41] ¦ rakudo/complex-sign: 8bd5eef1db | (Will Coleda)++ | 2 files [19:41] ¦ rakudo/complex-sign: Add Complex.sign to v6.e [19:41] ¦ rakudo/complex-sign: review: https://github.com/rakudo/rakudo/commit/8bd5eef1db [19:41] ¦ rakudo: coke++ created pull request #5181: Add Complex.sign to v6.e [19:41] ¦ rakudo: review: https://github.com/rakudo/rakudo/pull/5181 [19:51] ¦ rakudo/main: 37f5259958 | (Elizabeth Mattijsen)++ | 2 files [19:51] ¦ rakudo/main: RakuAST: add deparsing for Statement::No [19:51] ¦ rakudo/main: [19:51] ¦ rakudo/main: And some tests [19:51] ¦ rakudo/main: review: https://github.com/rakudo/rakudo/commit/37f5259958 [19:52] it's great to see [Coke] around with code as well 🙂 [21:00] *** raschip left [21:27] *** NemokoschKiwi joined [21:27] nine: I've got parameters working with subset types. But it throws a different exception than what we would expect: 'Internal error: inconsistent bind result' [21:52] WhateverCodes still not loving it [21:59] *** ab5tract left [22:11] *** sena_kun left [22:32] *** NemokoschKiwi left [23:00] *** ab5tract joined [23:09] *** shmup joined [23:11] lizmat: not sure it's worth it. But then I said the same about Stubs and you proved me wrong :) [23:12] ab5tract: inconsistent bind result appears when meta data (i.e. the Signature object) suggests a bind will be successful, but when we do the call, the parameter check fails [23:15] fyi I'm working on a fix for the map store breakage; for now it will probably be a quick-and-dirty solution, like moving the method declaration to Map might be enough [23:16] it would be good have systematic test cases for all possible storage scenarios which, if I can count, matches the nick of our beloved RakuAST expert [23:17] .oO(how many cases are a jnthn full?) [23:18] 🤣 [23:20] tbh it could be organized into not more than three individual tests probably [23:20] ab5tract: so if I understood you correctly, it accepts an acceptable argument and refuses an unacceptable one but when refusing does so with an inconsistent bind result. Then the Parameter meta-object needs adjusting so it's clear the bind will not be successful. [23:20] storing a list with a Map, a Hash and a Hash::Object into a) a Map b) a Hash c) a Hash::Object [23:26] nine: You've got it right. I was just coming to the realization and (hopefully a fix) right now [23:29] \o/ [23:39] [0] > my %map is Map = :foo Map.new((foo => True)) [1] > my %hash = :bar {bar => True} [2] > my %hash-object{Any} = :baz {baz => True} [3] > (%map, %hash, %hash-object).hash {bar => True, baz => True, foo => True} [23:39] hm, seems about right [23:45] one more subtest is successful [23:56] *** epony left