Perl 6 language and compiler development | Logs at colabti.org/irclogger/irclogger_log/perl6-dev | For toolchain/installation stuff see #perl6-toolchain | For MoarVM see #moarvm
Set by Zoffix on 27 July 2018.
00:27 AlexDaniel left 00:29 lucasb left 00:31 cinch joined 03:02 evalable6 left 03:07 evalable6 joined
Geth_ rakudo: RayMPerry++ created pull request #3204:
Issue #2092 | Clarify detached method error messaging.		 03:29
synopsebot RAKUDO#2092 [open]: github.com/rakudo/rakudo/issues/2092 [Hacktoberfest][LTA][easy to resolve][good first issue] "only alpha methods may be detached" message could be a bit clearer/accurater
04:10 cinch_ joined 04:12 cinch left 05:20 robertle left 06:36 Kaiepi left 06:43 ufobat joined
nine lizmat: just that no _known_ non-Str Cool object can contain whitespace or newlines, that doesn't mean that there never will be one. Nothing's preventing the user from declaring class Foo is Cool { method Str() {} } 07:12
m: say ["foo bar", "baz qux"].words # this actually does make some sense 07:13
camelia (foo bar baz qux)
08:53 ufobat_ joined 08:56 ufobat left
|Tux| Rakudo version 2019.07.1-368-g1e2b0ec59 - MoarVM version 2019.07.1-243-g1546c8c4d
csv-ip5xs0.777 - 0.788
csv-ip5xs-206.391 - 6.552
csv-parser22.646 - 25.016
csv-test-xs-200.423 - 0.455
test6.889 - 7.371
test-t1.714 - 1.736
test-t --race0.785 - 0.807
test-t-2029.530 - 29.537
test-t-20 --race9.167 - 9.264
 09:49
10:08 anatofuz joined
lizmat nine: yeah, I came to that conclusion as soon as I realized that Match is also Cool 10:10
Files=1274, Tests=109505, 205 wallclock secs (26.74 usr 7.78 sys + 2887.25 cusr 259.47 csys = 3181.24 CPU) 10:11
10:57 anatofuz left, anatofuz joined 11:01 anatofuz_ joined 11:04 Kaiepi joined, anatofuz left 11:15 Kaiepi left 11:19 Kaiepi joined 12:06 lizmat left 12:14 squashable6 left, squashable6 joined, ChanServ sets mode: +v squashable6, squashable6 left 12:16 squashable6 joined 12:22 anatofuz_ left 13:04 anatofuz joined 13:15 softmoth joined 13:18 softmoth left, softmoth joined 13:22 anatofuz left 13:40 anatofuz joined 13:50 anatofuz left 13:52 anatofuz joined 13:56 anatofuz left 13:57 lucasb joined
Geth_ nqp: 89a912193c | (Paweł Murias)++ | src/vm/js/nqp-runtime/package.json
[js] Specify version of dependency better to satisfy yarn
 14:23
nqp: eddfe9739d | (Paweł Murias)++ | src/vm/js/nqp-runtime/core.js
[js] Decont when passing p6 objects to js land
nqp: 498b64a4e2 | (Paweł Murias)++ | src/vm/js/nqp-runtime/reprs.js
[js] When wrapping js objects fill expose some methods that Perl6

code expects
14:25 Kaiepi left 14:28 Kaiepi joined 14:49 squashable6 left 14:53 squashable6 joined 15:03 MasterDuke left 15:09 MasterDuke joined 15:35 AlexDaniel joined 15:48 liztormato joined 15:52 liztormato left 16:16 lizmat joined 16:17 scovit_ left 17:22 cognomin_ joined 17:25 cognominal left 17:28 Ven`` joined
vrurg What would be the most efficient way to distinguish NQP role from Perl6 one? 18:26
timotimo comparing its .HOW against a known nqp role's how possibly? 18:33
vrurg timotimo: ineffective because NQPParametricRoleHOW, NQPConcreteRoleHOW, ... 18:37
timotimo do they all do a common role perhaps?
hm
roles having roles, eh?
vrurg The best I came up with is nqp::istype($role.HOW.HOW, KnownHOW)
m: role R does Metamodel::DefaultParent { }; class C does R { } 18:38
camelia 5===SORRY!5=== Error while compiling <tmp>
Cannot find method 'role_typecheck_list' on object of type NQPParametricRoleHOW
at <tmp>:1
vrurg m: class C does Metamodel::DefaultParent { }
camelia ( no output )
vrurg Common role on HOW would possible be Metamodel::Naming. 18:40
18:40 softmoth left 18:56 softmoth joined 19:12 softmoth left 19:49 lizmat left 19:52 lizmat joined 19:59 lizmat left 20:37 softmoth joined 20:49 softmoth left 21:20 softmoth joined 21:22 squashable6 left 21:24 squashable6 joined, ChanServ sets mode: +v squashable6 21:25 softmoth_ joined, softmoth left 21:53 Kaiepi left 21:54 Kaiepi joined 21:59 softmoth_ is now known as softmoth 22:30 anatofuz joined 22:31 Ven`` left 22:32 Ven`` joined, Ven`` left 22:33 lizmat joined 22:35 anatofuz left 22:36 lucasb left 22:40 anatofuz joined
jnthn vrurg: Why do you need to know that, ooc? 22:41
(Generally, we'd try to avoid that...)
(And find some solution where things fall naturally out of dispatch/polymorphism/whatever)
vrurg jnthn: R#3199, implementing github.com/perl6/problem-solving/issues/103. Perl6 class can consume an NQP role but they're not fully compatible by method parameters. 22:42
synopsebot R#3199 [open]: github.com/rakudo/rakudo/pull/3199 [WIP][roles] [WIP] Implement perl6/problem-solving#103
22:42 anatofuz left
vrurg By 'they' I meant Perl6 and NQP RoleHOWs 22:47
jnthn vrurg: Specifics? Maybe just make the NQP one compatible? 22:49
vrurg jnthn: I didn't want to mess up with NQP. Besides, NQP doesn't have submethods and I didn't want method `BUILD` to be handled same way as submethod. 22:51
But even if I wanted to, roles doesn't have `find_method`. So, I have to deal directly with method tables. 22:53
jnthn Hm, but you probably should anyway, 'cus find_method on a Perl 6 role will pun the role and give you the instantiated method from the class :)
vrurg Precisely. I forgot that I already had this experience yesterday.... :D 22:54
jnthn The typical way we deal with things like "doesn't ahve submethods" is `nqp::can($the-how, 'submethod_table') or some such.
e.g. check if the thing has the method in question
vrurg Ah, really... At some point I'm stuck at some narrow field of view... 22:55
Thanks!
jnthn: There is still a controversy about calling submethods. I'm still opposed to call them as if with .*/.+. Besides, it breaks current behavior too much. I'd rather propose operators .- or .<<, or alike, which would reverse MRO and call methods/submethods in this order. 22:57
jnthn vrurg: Yeah, I read that (didn't have chance to reply yet, sorry :() and have been pondering it a bit 22:58
vrurg I could be just .- which would return failures for typeobjects where the method is not found.
So, it could be like (42, 0, Failure, 1) 22:59
jnthn Don't have any good answers yet, except maybe to borrow the idea that regexes modify quantifiers, e.g. *? and *: for minimal matching and ratchet
So it'd be .+ and .* plus something
I'm not sure what looks like a down arrow :)
vrurg My point is to avoid line noise. And yes, no good non-unicode symbol comes to mind anyway. 23:01
To my view, .+ and .* are overkill already. The approach with failures looks much cleaner and could have resulted in exactly one op for the purpose.
Then I'd be a perferct pair of .+ for forward-call and .- for reverse call. 23:02
*call order
Gibberish: $obj.?+method(); $obj.?-method(); 23:07
23:17 anatofuz joined
jnthn Poor punctuation. It dutifully goes about making different things look different, and just gets sniped at for its efforts. 23:18
vrurg jnthn: but it makes .* obsolete. Deprecation? 23:19
timotimo i didn't encounter a use case for .* and .+ so far, or maybe i didn't think to use either of them when it would have been good 23:20
23:20 softmoth left
vrurg timotimo: I used the contra-functionality: was manually iterating classes+roles in reverse-MRO order. .- would make a lot of sense for me at that point. 23:21
timotimo maybe what we need is something separate from method and submethod. like a hypermethod or a sidewaysmethod or an allmethod 23:22
and BUILD would become that
i think "aspect" is kind of what this is called in other circumstances?
i mean, aspect oriented programming has a similar taste
on the other hand, BUILD is a thing you encounter relatively early in your perl6 learning journey 23:24
and if that has some very funky keyword to go along with it, that'd potentially just confuse 23:25
or would only the ones in roles get that keyword?
"parasitic method BUILD"
vrurg Besides, the change itself is too radical. If we ever consider something like this, it would need big planning beforehand.
parasitic? 'alien method BUILD' 23:26
timotimo "also method BUILD" :) 23:27
if only the part in BUILD has to be changed, then we'd be in the clear as far as backwards compat goes, i believe
so far there has not been a way to get BUILD from orles contribute to (rather than replace) implementations of classes
so either you have a BUILD in your role now and it probably does what you don't want, or you have come up with a manual method
either way, as long as the role doesn't have the extra keyword in it, it wouldn't change how things happen 23:28
i'm not entirely sure if i'm making sense with this
vrurg timotimo: I'm currently working on BUILD/TWEK/DESTROY to be executed on per-role basis. Isn't it a solution? 23:29
timotimo it probably is
will that be language-version-gated?
vrurg Basically, github.com/perl6/problem-solving/issues/103 has my view on how roles and submethods must interact with classes. 23:30
timotimo: Yes, it is already.
I had to implement version revision recording for all type objects (including role variations).
It makes it impossible for pre-6.e classes to consume 6.e+ roles though. But I think it should be ok. 23:31
timotimo i'm not sure i have the sufficient brainspace to absorb all of this properly 23:33
but i think making submethods automatically multi-call by themselves could be a bad approach, just as you suggest 23:34
vrurg I had har time convincing Jonathan about this. Especially when he was backed by TimToady ;)
s/har/hard/ 23:35
23:40 anatofuz left 23:59 go|dfish 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!