|
🦋 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
|
|||