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