🦋 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.
02:20 MasterDuke left
nine MasterDuke: I was thinking let's just keep that name as it is :D 06:07
tellable6 nine, I'll pass your message to MasterDuke
nine m: subset Even of Int where * %% 2; EVAL q[my Even $i = 3]; CATCH { default { note $_.^name } } 07:43
camelia X::TypeCheck::Assignment
Geth rakudo/is-item: bf6eb621ae | ab5tract++ | 4 files
Initial integration of 'is-item'
 07:44
nine I hate these situation. This test fails in RakuAST because we throw a X::Syntax::Number::LiteralType instead which is actually more targeted. We do so because our implementation of detecting these situations is just different.
ab5tract nine: could we fudge it for now by having X::Syntax::Number::LiteralType inherit from the less targeted exception? 07:48
depends on the way the test checks the exception type, though 07:49
anyway, that's a pre-coffee thought so apologies if it's half baked :) 07:50
lizmat nine: I'd say: change the test to be more generic 07:55
nine Actually I really like ab5tract++'s suggestion. X::Syntax::Number::LiteralType really *is* about failing type checks in assignments. The exception's message says "Cannot assign a literal of type $.valuetype ($value) to a { "native" if $.native } variable of type $vartype". I think it was really a mistake to make this exception type an X::Syntax in the first place. There's nothing wrong with the syntax here. 08:01
The change passes test and spectest. lizmat do you agree with my reasoning? 08:04
lizmat agree there's nothing wrong with the syntax 08:06
but it does feel like this should be caught at compile time, though ? 08:07
nine It does. At least in the covered cases. 08:08
lizmat then ++
08:11 sena_kun joined
Geth rakudo/main: 5b7cf94c47 | (Stefan Seifert)++ | src/core.c/Exception.rakumod
Make X::Syntax::Number::LiteralType a subclass of X::TypeCheck::Assignment

X::Syntax::Number::LiteralType gets thrown when we detect at compile time that an assignment of a literal number will fail due to a type mismatch. That's exactly the situation X::TypeCheck::Assignment is meant for. The LiteralType exception just covers a more specific scenario and will give a hopefully better error message. Thus it seems appropriate to ... (11 more lines)		 08:15
rakudo/main: 1b5c082040 | (Elizabeth Mattijsen)++ | src/Perl6/Metamodel/Concretization.nqp
Streamline Metamodel::Concretization (Part 3/3)
 08:17
lizmat vrurg: having slept a night over it, I think a class changing from non-generic to generic, is a. a case of DIHWIDT, and b. should probably not be allowed, just like not being allowed to change the REPR of a class 08:24
I mean: a generic can produce a non-generic with a new HOW, but not the other way around 08:26
to me, it feels at the same level of being able to make a variable out of a constant
you can make a constant out of a variable, but not the other way around
Geth rakudo/main: 039dbe495b | (Elizabeth Mattijsen)++ | src/Perl6/Metamodel/ArrayType.nqp
Streamline Metamodel::ArrayType

  - use nullness as flag of type being set, instead of a separate attribute		 08:49
rakudo/main: c48fc1e3f1 | (Elizabeth Mattijsen)++ | src/Perl6/Metamodel/BaseType.nqp
Streamline Metamodel::BaseType

  - use nullness as flag of type being set, instead of a separate attribute
  - use clone and unshift instead of for loop to create mro / parents
One final note: it feels incorrect that the first call to .mro with any given set of named arguments, should determine any future returns. Yet if we remove the @!mro attribute and create the @mro each call on the fly we get spectest failures in t/spec/integration/advent2012-day13.t. Go figure!		 09:35
rakudo/main: 9ecfb483e6 | (Elizabeth Mattijsen)++ | src/Perl6/Metamodel/C3MRO.nqp
Don't need to set defaults for optional named args
 09:53
rakudo/main: 54a4c8cf92 | (Elizabeth Mattijsen)++ | src/Perl6/Metamodel/ContainerSpecProtocol.nqp
Streamline Metamodel::ContainerSpecProtocol
 10:12
rakudo/main: 4d33d371cd | (Elizabeth Mattijsen)++ | src/Perl6/Metamodel/LanguageRevision.nqp
Streamline Metamodel::LanguageRevision

  - simplify set_language_revision: an "int" argument is always
   concrete, even if it were optional (which it isn't in this case)
  - move error handling of "check-type-compat" to seperate method to
   reduce bytecode size for the (correct) fast path to allow for
   easier inlining
  - some more internal comments		 11:14
lizmat this appears to nibble another 4 CPU seconds off of make spectest (1220 -> 1216) 11:15
Geth nqp/main: 54a798be0d | (Elizabeth Mattijsen)++ | src/how/NQPClassHOW.nqp
Eradicate .publish_method_cache from MoarVM backend

  - don't compile the method on MoarVM
  - don't call the method on MoarVM		 11:26
rakudo/main: 67ed16b350 | (Elizabeth Mattijsen)++ | 8 files
Eradicate .publish_method_cache from MoarVM backend

  - don't compile the method on MoarVM
  - don't call the method on MoarVM		 11:50
rakudo/main: 7ce8b6e5bb | (Stefan Seifert)++ | 2 files
RakuAST: fix throwing of NYI BUILDPLAN errors
 12:19
rakudo/main: 0d1095a0a5 | (Stefan Seifert)++ | src/Raku/ast/variable-declaration.rakumod
RakuAST: fix NYI BUILDPLAN error on typed hash attributes with defaults

A shape on an attribute should only lead to creation of an initializer thunk for array attributes as there the shape directly influences the values. On hash attributes we require a value type for generating an initializer.
Fixes "Defaults on compound attribute types not yet implemented" on class TypedKeyHash { has %.b{Str} is rw = o => 768; }
rakudo/main: 45dfb1bd46 | (Elizabeth Mattijsen)++ | src/Perl6/Metamodel/Mixins.nqp
Abstract error handling into helper method

For smaller local bytecode size and better readability		 12:28
12:50 vrurg left, vrurg joined
vrurg lizmat: you miss the case where an instance contains generic class which needs to be instantiated. For the generic instantiation process to handle this situation it needs to now the status of the instance. Think of ContainerDescriptors, for example. In case of JSON::Class its descriptors of attributes, 13:12
Besides, a class can't know if its instances will or won't contain generics. Especially at the composition time. 13:14
nine Wow....I just learned the important difference between self.foo and $.foo 13:21
Geth rakudo/main: b61de7a9c3 | (Stefan Seifert)++ | src/core.c/Exception.rakumod
Fix "No exception handler located for catch" trying to report method-not-found

  $.invocant is not just calling the invocant method but implicitly also
calls .item on the return value. This can fail if $!invocant does not have that method (e.g. when it's a generic type object) which leads to a method-not-found error trying to report the method-not-found error only that there is no more exception handler to deal with it.
Since this code is already the fallback for when we failed to construct a more elaborate error message, try to make it as safe as possible by accessing the attributes directly instead of going through accessors.		 13:23
vrurg nine: Aha, it struck me in the past once. :)
nine Let's hope this finally gives us helpful method-not-found messages in all cases.
vrurg lizmat: BTW, removal of the generic instances feature effectively breaks WWW::GCloud (through JSON::Class not being able to properly deserialize paginating responses) and, consequently, my work project. 13:31
nine vrurg: can I convince you to follow up on your commit 20c0c5e0f6426d80cb719e09b8d72e3825e0037e with RakuAST support? 14:08
linkable6 (2023-11-28) github.com/rakudo/rakudo/commit/20c0c5e0f6 Instantiate attribute `is default` value
vrurg nine: in which way? 14:10
nine > ./rakudo-m -Ilib -e 'my role R[::T] { has $.v is default(T); }; my class C does R[Str:D] {}; say C.new.v.^name' 14:12
Str:D
nine@sphinx:~/rakudo (main =)> RAKUDO_RAKUAST=1 ./rakudo-m -Ilib -e 'my role R[::T] { has $.v is default(T); }; my class C does R[Str:D] {}; say C.new.v.^name'
T
vrurg Oh, time sharing between few tasks doesn't work well for me. RakuAST... 14:16
I'm afraid, it won't be possible for me for at least another couple of months. :(
But it should be just a matter of inserting instantiate_generic calls in a couple of locations. Perhaps, the legacy compiler can help with hints as there are only three locations where the call is generated. 14:20
nine None of them seems to apply to attributes? 14:22
vrurg Attributes are processed by BOOTSTRAP code. 14:27
Up to my memory, at least. 14:28
Or, maybe no... I'm certainly having memory leaks! 14:32
OK, here it is. Attributes are instantiated by role specialization. ParametricRoleHOW.nqp:237 14:34
nine Looking at the QAST generated by the old frontend I think the solution is really to defer application of attribute traits in roles to compose time 14:35
vrurg You mean, so they are applied to instantiated attributes? 14:38
But then what if a trait wants to interfere with instantiation itself? 14:39
nine Yes: │ │ │ - QAST::Block(:name() :cuid(1)) :statement_id<2> :outer<?> :in_stmt_mod<?> :code_object<?> :DYNAMICALLY_COMPILED<?>
│ │ │ │ - QAST::Stmts is default(T)
│ │ │ │ - QAST::Stmts <wanted> T
│ │ │ │ - QAST::Var+{QAST::CompileTimeValue}(lexical T :returns(T)) <wanted> :statement_id<3> :pure-generic-lexical<?> T
So maybe commit 510c31560b516ba3a58092243ec26253a1e56974 is really what I should ask a follow-up of :D 14:42
linkable6 (2023-12-12) github.com/rakudo/rakudo/commit/510c31560b Make sure generics are available at compile-time
vrurg nine: Oh, that could be the thing. But, as I said, I wouldn't be able to do any Rakudo stuff for a while. :( 14:46
Especially with RakuAST which I looked into just so much long ago. 14:47
vrurg is afk&
15:16 Voldenet left, Voldenet joined
ab5tract while poking around at implementing `@a is item`, I'm struck by how difficult it is to understand just where it is exactly that a Parameter trait matters 15:29
I was expecting to be able to hook in at the Binder layer, but nope, this is barely run (at least on moar) unless the optimizer is off 15:30
so guess I need to implement the actual checks in the dispatcher code, but `raku-call` and `raku-invoke` do barely nothing related to parameters, so that 15:32
s/so guess/so maybe/; "so that " ... doesn't feel right at all 15:33
I mean, wouldn't $signature.ACCEPTS($capture) be a reasonable way to determine if a set of arguments are callable? 15:39
nine It would. It would also be super slow 16:02
ab5tract fair :) 16:08
still seems like it could delegate to the relevant fast path instead of ... however it is that the code ends up in dispatchers.nqp 16:10
but it's a pretty small issue, in the long run 16:12
Geth rakudo/main: 7f66404437 | (Elizabeth Mattijsen)++ | 2 files
Revert "Streamline Metamodel::ClassHOW (Part 2/N)"

This reverts commit ffc663d52f02a5844421a9b553e30563b4f79003.
We will need another way to deal with this.		 16:32
lizmat vrurg ^^
the more I think about this, it feels that making .generic part of the archetypes, is a design error 16:36
I mean, *any* class that has an attribute that stores a non-core class, can be generic because that class can be generic 16:37
whether a type is generic, is a property of the type, not of its HOW 16:41
Geth rakudo/main: ab1784b816 | (Elizabeth Mattijsen)++ | 2 files
(Package|Module)HOW don't need .new

As the new_type method does a nqp::create(self)		 17:03
vrurg lizmat: Class itself cannot be generic. It remains unchanged and must not change. Instances are different case. is_generic method on ContainerDescriptor was the first step into this direction but it wasn't thought out throughly and ended up as incomplete solution which, eventually, caused a lot of WAT. 18:19
Otherwise, it is part of HOW and part of archetypes because other types can be generic. We can't take it away from the metamodel because a type (in theory) may not be OK with having methods at all. In case of roles, we just can't call methods on them without punning. Thus, the only correct solution is HOW. And archetyping fits this task the best. 18:22
(in the part about class, "It" had to be "This"; it's not the class which is unchanged, it's the behavior of HOW). 18:24
ab5tract okay, so am I crazy or does the success case for dispatch not involve any Raku-level checks? 20:52
or NQP-level, for that matter 21:10
lizmat ab5tract: yeah, it's all in the VM 22:41
if I understand your question correctly
22:47 sena_kun left

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!