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:26 anatofuz left 00:29 anatofuz joined 00:33 anatofuz left 00:37 reportable6 left, reportable6 joined 00:49 anatofuz joined 00:59 Kaiepi left 01:03 Kaiepi joined 01:05 softmoth_ joined 01:06 MasterDuke left, Kaiepi left 01:07 Kaiepi joined, softmoth left 01:23 anatofuz left 01:25 anatofuz joined 01:29 anatofuz left, anatofuz joined 01:43 anatofuz left 01:47 anatofuz joined 01:50 anatofuz left 02:05 anatofuz joined 02:18 anatofuz left, anatofuz joined 02:20 anatofuz_ joined 02:23 anatofuz left 02:29 squashable6 left 02:31 lucasb left 02:35 squashable6 joined 03:29 anatofuz_ left 03:30 anatofuz joined, anatofuz left, anatofuz joined 03:50 anatofuz_ joined 03:53 anatofuz left 03:54 anatofuz_ left 03:58 anatofuz joined 04:02 softmoth_ is now known as softmoth 04:08 anatofuz left 04:09 anatofuz joined 04:34 anatofuz left 04:36 anatofuz joined 05:06 anatofuz_ joined 05:09 anatofuz left 05:25 anatofuz_ left 05:26 anatofuz joined 05:29 softmoth left 05:31 anatofuz left 05:36 anatofuz joined 05:42 anatofuz left 05:43 anatofuz joined, anatofuz left 05:53 anatofuz joined 06:06 anatofuz left 06:10 hankache joined 06:12 anatofuz joined 06:14 hankache left 06:21 anatofuz left 06:22 squashable6 left 06:28 squashable6 joined 07:27 anatofuz joined 08:09 anatofuz left 08:17 anatofuz joined 08:20 anatofuz left 08:21 anatofuz joined 08:27 anatofuz left 08:28 anatofuz joined 08:31 anatofuz left
|Tux| Rakudo version 2019.07.1-386-g7e76762c5 - MoarVM version 2019.07.1-257-g39f577438
csv-ip5xs0.759 - 0.796
csv-ip5xs-206.397 - 6.477
csv-parser21.470 - 21.527
csv-test-xs-200.427 - 0.428
test7.156 - 7.314
test-t1.707 - 1.751
test-t --race0.779 - 0.780
test-t-2029.198 - 29.410
test-t-20 --race8.900 - 9.128
08:36
08:55 anatofuz joined, anatofuz left 09:01 anatofuz joined 09:05 anatofuz left 09:14 anatofuz joined 09:54 anatofuz left 09:57 anatofuz joined 10:19 softmoth joined
lizmat Files=1274, Tests=109493, 205 wallclock secs (27.81 usr 7.71 sys + 2881.89 cusr 259.44 csys = 3176.85 CPU) 10:58
12:38 Guest3346 left 12:52 anatofuz_ joined 12:55 anatofuz left 12:56 anatofuz_ left 13:16 anatofuz joined 13:22 anatofuz left 13:28 Guest3346 joined 13:31 lucasb joined 13:40 anatofuz joined
[Coke] anyone here used the rakudo.js backend? I tried out the online version, but don't remember the last time I tried to compile it. 14:24
14:25 softmoth left 14:30 softmoth joined
[Coke] (looks like it's easiest to get via an npm install) 14:32
14:41 anatofuz left 14:42 anatofuz joined 14:46 anatofuz left
SmokeMachine [Coke]: I've being playing with it for a while... it's very cool! This was one of my first tries: fco.github.io/MemoizedDOM/todo6.html 14:56
[Coke]: github.com/FCO/MemoizedDOM
15:00 |Tux| left 15:05 |Tux| joined 15:16 anatofuz joined 15:20 anatofuz left 15:54 Kaiepi left 15:57 patrickb joined 16:12 squashable6 left 16:15 squashable6 joined 17:33 Kaiepi joined
vrurg Anyone with good knwoledge of serialization/precompilation. 17:46
timotimo: ping? 17:47
timotimo i wish 18:00
tellable6 2019-10-06T23:38:52Z #perl6 <AlexDaniel> timotimo test 18:01
timotimo what's wrong?
vrurg timotimo: anyway. Remember the question about objectids? 18:07
I used them to build a lookup table on MOP. The table survives serialization. Obviously, with different objectids in it each time. 18:08
Break reproducible builds test. 18:09
I would happily prevent the table from being serialized as I have to rebuild it on each startup anyway. But no idea if this is possible.
timotimo you can usually turn off the scwb before changing stuff inside it 18:15
that will prevent the objects you put in from becoming part of the serialization context you're compiling stuff into
or something like that
i haven't had to do this so far
vrurg timotimo: can it work for an attribute on a MOP class? 18:16
timotimo i know that attribute writes will trigger the SCWB, and putting stuff into object arrays and hashes will as well 18:17
so if it's not hit, not sure what that causes exactly
vrurg timotimo: thanks! I'll try this. 18:18
timotimo good luck! 18:21
vrurg timotimo: It works! When I'm done with roles, it'd be good time to get into serialization.
timotimo cool 18:22
i wonder if this could also be The Way to make NFAs only serialize themselves, not the arrays-of-arrays versions of their data
and if the stuff is missing, reconstruct it when needed
because that is a major source of duplicate data in serialized blobs as well as ram usage of the "empty" program 18:23
vrurg I'm slow. What's NFA in this context?
timotimo nondeterministic finite automaton
it has a repr and a couple of ops
vrurg timotimo: is it so hard to give it a try? :) 18:25
timotimo not sure 18:26
18:39 Kaiepi left
nine is sooo glad to have written those reproducibility tests 18:43
timotimo +1 18:44
18:59 patrickb left
vrurg nine++ :) 19:07
R#3199 is seemingly ready to merge. Only the final approval for .?-, .?+ ops is needed. 19:12
synopsebot R#3199 [open]: github.com/rakudo/rakudo/pull/3199 [WIP][roles] [WIP] Implement perl6/problem-solving#103
TreyHarris Where (if anywhere) is discussion on the renaming wrt the Perl6 org on GitHub? I'm starting to look at the issues with renaming the Emacs mode (or, more precisely, dealing with both names and having a transition path to a new name) and it's a bit daunting; I don't want permission issues on the repo making it even more difficult. 19:27
19:28 squashable6 left 19:31 squashable6 joined
TreyHarris As far as I can tell, no published Emacs mode has ever had its language change names; figuring out how to do it with minimal user impact isn't trivial. 19:39
[Coke] is the easiest solution to release one with a new name? 19:40
(for you, not the users)
TreyHarris And since Emacs uses Lisp for configuration--meaning it's both Turing-complete and puts heavy reliance on supposedly immutable symbol names--it's going to be a much heavier lift than for most editors.
[Coke]:Unfortunately not--Emacs packages can express dependencies, but not "anti-dependencies"(?) and there will be name collisions if both are loaded simultaneously. With NQP if nothing else 19:41
And I'd very much like users key bindings, hooks, configurations, snippets, etc., to carry over if at all possible. I can do that by making raku-mode a "derived" mode based on perl6-mode, but then we can never get rid of perl6-mode 19:42
If we have a long enough sunset period (I'd say 16 months minimum), I could stick raku-mode (the library) into perl6-mode (the Emacs package), move most of the code with appropriate renamings into raku-mode.el, and make _perl6-mode_ (the mode defined in the library included in the package) derived from raku-mode (the mode defined in the library) instead of the other way around. Then there could be 19:47
compatibility code that would allow for eventual removal, at which point the perl6-mode's last release can formally deprecate everything and the package can be renamed
Although a couple of Emacs package managers (yes, here's not just one, though thankfully they're all based on a low-level one that ships with Emacs) can auto-update, almost no one actually enables that, so I can't depend on a userbase following us through a deprecation schedule 19:48
vrurg TreyHarris: the trasition won't be immediate, no way for this. Some aspects are planned for deprecation in 6.f language version which is as far as ~3 years from today. 19:49
TreyHarris Am I right that nobody's yet talking about renaming NQP to NQR? 19:50
vrurg Even if accept the fact that 6.f.PREVIEW would start the process, it's still no less than 14months.
TreyHarris: no, NQP will remain NQP. I think you need to read through problem-solving #89 19:51
TreyHarris vrurg: hm... the half-life of users continuing to use old versions of Emacs packages after updates is overall about 6 months, so if we're similar, I can probably work with that if I can get the transition in three or fewer stages
vrurg TreyHarris: and I mean the fils to be merged – github.com/perl6/problem-solving/pull/89/files 19:52
TreyHarris vrurg:oh, I have, but you may not have noticed--it's very, very long :-)
vrurg TreyHarris: but all you actually need is terms. So, look for deprecations and removals, that would provide you with the timeframes.
For you to better understand them, language release cycle is expected to be 2yrs. 19:53
TreyHarris Ah, d'oh, I didn't think to look at the actual current state of the Markdown, as I've been followig the commits and I didn't remember NQP being muntioned.
So I missed "The acronym for NQP is Not Quite Perl. It stays that way, so no changes."
vrurg:sorry, define "terms" in that message? 19:54
vrurg github.com/perl6/problem-solving/p...32017cfR73 19:55
TreyHarris: term as 'definition', 'word'
TreyHarris vrurg:yes, that's what I just quoted. Sorry I missed it
vrurg Ah, right. I was looking for that section and overlooked your message. :) 19:56
TreyHarris vrurg:But "[a]ll [I] actually need is terms"... I don't understand
vrurg I meant looking for words 'deprecation' and 'removal' should provide you with sections of the most interest for you. 19:57
TreyHarris vrurg:Oh, I see. Yes, skimming the full current state of the Markdown, I think I have fully assimilated that much (having missed the NQP bit). But the transition from perl6-mode to raku-mode is more a problem on the Emacs side, not in figuring out what file extensions, recognizer patterns, and such need to change 19:58
vrurg TreyHarris: you were asking if we have 16 months for the transition, so... :) 19:59
Ok, lunch time. bbl
TreyHarris When Emacs gained its new Perl (5) mode, it was named differently (cperl-mode) so they didn't have to deal with the transition; folks wedded to the old mode could just stick with it for over a decade before it was removed and cperl-mode was made an alias to perl-mode. 20:00
20:01 MasterDuke joined
TreyHarris But yes, I think 16 months gives time for three releases of perl6-mode prior to a cutover to raku-mode. One to start recognizing Raku nomenclature, one to shift around the dependencies so that perl6-mode becomes "legacy", and a final one to actually mark the functions formally deprecated and point people at the new mode. Lacking other action on my part, will github.com/perl6/perl6-mode continue to 20:03
work indefinitely? Because if there's a date certain (or one that becomes certain) when the perl6 GitHub Org goes away, I need to work backwards at least from that. Is that in the 3-year window?
[Coke] (NPR) no need for that rename, I don't think. 20:08
I haven't seen anyone seriously propose it.
TreyHarris Wait, hold the phone for one second: "Even if accept the fact that 6.f.PREVIEW would start the process, it's still no less than 14months." Does that mean that even if it's full steam ahead for Raku, it won't be possible to use a raku shebang or '.rakumod', '.rakudoc', etc. until then without an unauthorized rakudo patch? 20:09
That changes the timeline considerations significantly--I can mod perl6-mode just to refactor it into something that can be migrated without having to deal with any new functionality or recognition patterns 20:11
Are we sure that '#!...楽', .楽, .楽mod, etc. won't be included? :-) 20:17
AlexDaniel TreyHarris: what about making perl6-mode depend on raku-mode or vice versa? 20:22
TreyHarris AlexDaniel: yes, I mentioned that above and in the GitHub issues both in perl6/perl6-mode and in melpa/melpa (the Emacs package repo) 20:23
If we have 14 months before the Raku names even become valid for anyone not running experimental code, that approach seems to work better 20:24
AlexDaniel TreyHarris: as for the github repo, that's relatively easy (we can just transfer it to the new github org and things should just work)
TreyHarris: no, there are no months before raku names become valid, really
that is, the change is immediate
20:24 softmoth left
AlexDaniel language aspects like methods names etc. will have their deprecation cycle and stuff 20:25
TreyHarris AlexDaniel:if the are one-for-one redirects for URL's, yes, but MELPA will expect raw.github.com/perl6/perl6-mode/... to work
AlexDaniel but the name itself won't
TreyHarris: I'm pretty sure raw. links will also work after the transfer
TreyHarris: I hope melpa is able to follow a simple redirect
TreyHarris: here's the thing, we can transfer perl6-mode, check if stuff still works, and if it doesn't we can transfer it back 20:26
so either it works perfectly or we revert the transfer and think again :)
TreyHarris AlexDaniel:sounds good. It will follow one redirect, yes, but not multiple to prevent domain attacks from gaining control of people's editors. Well, that answers one question then--we'll want to create a raku-mode sister repo rather than renaming perl6-mode's repo to raku-mode 20:27
AlexDaniel TreyHarris: sorry, I'm not following how you got that answer…
TreyHarris I need to do some prototyping code now to be sure this approach will work, but I think I can do it with little impact except to folks who hardcoded everything into their configs
AlexDaniel TreyHarris: I'm saying that the repo transfer is the best way to do it
oh… I think I get it now 20:28
you're talking about emacs modes
sure, then… uh… yeah, maybe two repos…
TreyHarris AlexDaniel: correct. sorry, I thought I said that in my first message, but I may not have, and if so apologies for leaving out the context 20:29
AlexDaniel TreyHarris: thanks for taking care of it, btw, I use it every day
TreyHarris AlexDaniel: I'd be curious if 'perl6' appears in your init file(s) and if so, how. I should probably put out a call for that so I can examine cases of what we need to deal with 20:30
AlexDaniel TreyHarris: it doesn't
there's nothing that annoyed me, I'm fine with the defaults 20:31
TreyHarris AlexDaniel:unfortunately the original author only used Easy Customization for one out of about two dozen customizations, and so for all the others we have to get clever for people who have changed them
AlexDaniel TreyHarris: as for file extensions, you're correct, the PR even recommends people *not* to change file extensions yet. It will take some time for tools to start recognizing new extensions (it's not just rakudo, it's zef, prove6, etc.) 20:32
TreyHarris I suspect that Emacs old-timers probably don't even bother with that customization and just do `(setq perl6-indentation-offset 3)` 20:33
AlexDaniel TreyHarris: btw I just gave you the rights to comment on github.com/perl6/problem-solving/pull/89
TreyHarris: feel free to ask some questions there before it's merged :)
TreyHarris: wait, uh… there's… some other way?? 20:34
TreyHarris If 20 out of 22 customizations were Easy Customizations, I'd feel comfortable just using the built-in deprecation path. But since it's 1 out of 22, I've kinda got to deal with it for all of them
AlexDaniel:Yes. If you do `C-h v` and look up a configuration variable, you'll see the word "customize" is a link. 20:35
AlexDaniel:I actually have been writing a blog post called `setq considered harmful` about this, when I'm done I'll send you the link
20:36 Kaiepi joined
TreyHarris (if you use a single .emacs file rather than .emacs.d, I'd recommend you convert to the init directory before doing customizations, since otherwise it writes comment-fenced blocks directly to your .emacs--with directory init, is writes it in a nice custom.el file you can track separately.) 20:37
AlexDaniel oh, that GUI-ish thingie
TreyHarris Yes, but it works fine in text mode (I don't personally use GUI Emacs much) 20:38
In any case, taking just perl6-indentation-offset as an example, it's quite trivial to deprecate it with a pointer to its new name of raku-indentation-offset such that for users using it through the customize interface, they never have to touch a thing even if they modified it once 20:39
but since the other 20 configurations aren't using `defcustom`, that won`t work for them any more than it would work for someone who modifies perl6-indentation-offset with setq 20:40
AlexDaniel TreyHarris: I see, thanks for sharing these thoughts btw
TreyHarris AlexDaniel: no worries, thank you for clarifying some things. (And giving me access to that ticket, though I'm not sure I have anything to say except to link the other two tickets for reference.) 20:41
AlexDaniel: I should probably have the perl6/raku-mode repo created as soon as 89 is merged 20:42
If nothing else, to ensure a well-meaning future person who doesn't know the details renaming the perl6-mode repo
AlexDaniel TreyHarris: maybe wait just a little bit before creating a new repo, we'll have a new github organization it seems 20:46
TreyHarris: this was discussed a bit earlier, but from what I recall renaming an organization is more painful than transferring repos
TreyHarris: which is also a good opportunity to organize our repos a bit better (there are a bunch of community modules in perl6 org, maybe these should be in github.com/perl6-community-modules/) 20:47
or, well, raku-community-modules
I'm already squatting on github.com/rakulang and github.com/raku-lang 20:48
TreyHarris AlexDaniel: And I'm squatting on perl6-contrib 20:49
AlexDaniel TreyHarris: that's a cool logo
TreyHarris: you might want to rename that to raku-contrib :)
TreyHarris AlexDaniel:thank you, I figured for "contrib" Camelia should be a little more rough-and-ready looking :-)
AlexDaniel TreyHarris: as for deprecating all these emacs vars… how many users are there, really? 20:51
maybe just convert them to the new style?
TreyHarris AlexDaniel:unless, given the issue with renaming you just mentioned, there should be a perl6-contrib _and_ a raku-contrib. But That presumes there's a need for '-contrib' at all; I created it when -community-modules was created for things like this that aren't "modules"
AlexDaniel TreyHarris: just for clarification, perl6 organization won't be a thing on github. We'll keep it just for the repo redirects 20:53
so if there's nothing in perl6-contrib now, no need to have it all, right?
or am I misunderstanding something?
TreyHarris I squatted on it in case it was felt that -community-modules was for "modules" so there would be a third place for non-module toolchain stuff--such as editor support. I didn't think that _should_ be true, I just wanted to hang on to the name in case it became useful 20:54
AlexDaniel TreyHarris: that's a good question, actually 20:57
it's weird, I look at whateverable, for example, and it doesn't feel like it belongs there
in perl6 org that is
TreyHarris But based on what github.com/perl6/user-experience/issues/19 considers "good editor support", if we want a (more mature!) mode to be eventually included in Emacs, we should keep it in the perl6 org until i becomes the raku org, as that makes it more likely to be accepted by Emacs maintainers as "official"
AlexDaniel but it's not really a module…
even though it now is
TreyHarris: Hmm. I don't understand 20:58
ahh, now I do
you mean in the new raku org, I guess
TreyHarris AlexDaniel:Well, it's Emacs politics...like, there are a bunch of really awful cases where the official toolchain for a language included some 20-minute-hack Emacs mode that nobody in the language's community uses because that was the "official" one
AlexDaniel I see 20:59
OK
pretty sure we'll have to iron out the details of all that soon 21:00
TreyHarris Sure. But 2.5-3 years is plenty of time to get a module positioned so that, as soon as practicable after the Raku name takes hold, there could be a mature mode included in Emacs core 21:01
gack! s/module/Emacs mode package/
AlexDaniel TreyHarris: but! it's not exactly 2.5-3 years. It is for language changes (things like ‘foo’.perl changing into ‘foo’.raku), as well as filename extensions 21:02
but the name itself will be changed much faster
so “perl6-mode” will likely not make much sense in a month or two from now
basically, all mentions of “perl 6” will be changed *really* soon 21:03
TreyHarris AlexDaniel: I understand, but there's no rush to get a mode included in core. And there can't be, because for a mode to be included in core, it needs to be stable enough that a snapshotting on the order of years is okay (where power users can opt to use the MELPA version)
AlexDaniel I see 21:04
TreyHarris But I can get a raku-mode aliased to perl6-mode on MELPA in the meantime. 21:05
Though for that I would need a raku-mode repo. I ccould use treyharris/raku-mode though if you're uncomfortable with it being in the org 21:06
AlexDaniel A-ha! OK
well, maybe just wait till the next week then
TreyHarris Sure. 21:07
lizmat yes, it ain't over until the fat lady sings
TreyHarris AlexDaniel: Thanks! I'm feeling much better about this now
I'm not an Elisp whiz, so this was going to be not-easy anyway. 21:08
er, I think I meant "wiz" there. *blush*
21:32 anatofuz joined 21:37 anatofuz left, anatofuz joined 21:42 anatofuz left 22:02 anatofuz joined
vrurg greppable6: \.\+\w 22:04
greppable6 vrurg, No! It wasn't me! It was the one-armed man! Backtrace: gist.github.com/d7b6dbe9be72917f5e...eae5a3e906
AlexDaniel uhh
it is matching stuff in pdf files… 22:05
I think… or what's going on there?
MasterDuke unicodable6: 9ۨ 22:06
unicodable6 MasterDuke, U+0039 DIGIT NINE [Nd] (9)
MasterDuke, U+06E8 ARABIC SMALL HIGH NOON [Mn] ( ۨ)
22:07 anatofuz left
TreyHarris Does the language accept "\uxxxx" forms? 22:08
MasterDuke timotimo: you might find morepypy.blogspot.com/2019/10/pypy...arser.html interesting
22:09 anatofuz joined
TreyHarris m: "\u2208" 22:12
camelia 5===SORRY!5=== Error while compiling <tmp>
Unrecognized backslash sequence: '\u'
at <tmp>:1
------> 3"\7⏏5u2208"
expecting any of:
double quotes
statement list
term
MasterDuke m: "\x2208" 22:17
camelia WARNINGS for <tmp>:
Useless use of constant string "∈" in sink context (line 1)
MasterDuke m: say "\x2208"
camelia
MasterDuke unicodable6: ∈
unicodable6 MasterDuke, U+2208 ELEMENT OF [Sm] (∈)
TreyHarris That gist output is coming from a different language, then, I take it? 22:18
MasterDuke don't think so. github.com/rakudo/rakudo/blob/mast...N.pm6#L471 22:20
AlexDaniel why is it using the internal parser then? 22:21
MasterDuke well, i guess it could be a different language, is \u how json does it? 22:22
AlexDaniel modules.perl6.org/dist/JSON::Fast:...t.pm6#L488
MasterDuke right, that code was copied into rakudo a little while ago 22:23
AlexDaniel MasterDuke: I'm pretty sure that \u escape itself is fine but the combiner after it is misparsed 22:24
TreyHarris So the output format just doesn't match the input then. "\u1234" is on output, "\x1234" on input?
AlexDaniel see colabti.org/irclogger/irclogger_lo...10-06#l401
basically, JSON::Fast is unable to roundtrip in this case
and it could be that we're seeing something similar here too 22:25
because IIRC after you send stuff to github you somehow get it back too
or at least that's what happens in case of Pastebin::Gist, or something
timotimo: so… ping again?
TreyHarris AlexDaniel: yes, all the gist modules seem to do that, I guess GitHub returns the input for... reasons? 22:26
AlexDaniel timotimo: github.com/timo/json_fast/issues/62 22:27
TreyHarris: that's good, at least we'll fix JSON::Fast :) 22:28
timotimo ah 22:29
when outputting something as a unicode sequence, the code will have to be extra sure that the character following isn't a combining character?
TreyHarris If it normalizes the raw blob input (as we see here) it makes a certain amount of sense to return the normalized input; you can compare it to the raw input or display it instead of the local input
timotimo or maybe just allow Ä as the last hex digit of a unicode sequence and taking the combining diaeresis and putting it on the resulting character 22:30
AlexDaniel timotimo: it's not just that, to me it looks like it's not escaping some characters at all when it should 22:31
what happens when you encounter a grapheme? 22:32
that is, a multi code point char
timotimo a lot of code happens
22:33 anatofuz left
timotimo past 0x10000 it creates suggorage pairs 22:33
AlexDaniel well, maybe a whitelist-like approach shoulld be used? By default just escape everything, and then maybe define which particular cases are ok
timotimo (you know, because json is js-damaged)
github.com/timo/json_fast/issues/56 22:34
AlexDaniel well!
22:34 anatofuz joined
AlexDaniel correct > pretty 22:34
timotimo except the actual thing is that you only need to use surrogate pairs if you're making \u escape sequences of stuff above 0x1000 22:35
vrurg m: role R { has $.a; submethod foo { $.a } } 22:48
camelia 5===SORRY!5=== Error while compiling <tmp>
Virtual method call $.a may not be used on partially constructed object (maybe you mean $!a for direct attribute access here?)
at <tmp>:1
------> 3role R { has $.a; submethod foo { $.a7⏏5 } }…
vrurg ^ bug, I guess?
m: role R { has $.a; method foo { $.a } } 22:51
camelia ( no output )
vrurg Hm...
22:52 softmoth joined 23:09 anatofuz left 23:10 anatofuz joined, anatofuz left, anatofuz joined 23:12 anatofuz left, anatofuz joined 23:13 anatofuz left, anatofuz joined
jnthn vrurg: That's correct, no? 23:23
tellable6 2019-10-08T23:16:02Z #perl6 <vrurg> jnthn I'd like to merge R#3199 if you don't mind of .-, .?+, and .?- operators.
synopsebot R#3199 [open]: github.com/rakudo/rakudo/pull/3199 [WIP][roles] [WIP] Implement perl6/problem-solving#103
jnthn vrurg: I'm still a bit unsure about those operators...will try and take a look
vrurg jnthn: respective PR on roast has tests for them.
jnthn OK, thanks. 23:24
vrurg spectests are passing.
23:29 anatofuz left 23:30 anatofuz joined 23:34 anatofuz left
Geth_ ¦ rakudo: vrurg self-assigned Attributes can't be used in submethods with $. github.com/rakudo/rakudo/issues/3222 23:36
vrurg m: role R { has $.a; method foo { $.a } }; R.foo 23:52
camelia Invocant of method 'a' must be an object instance of type 'Mu', not a type object of type 'R'. Did you forget a '.new'?
in method foo at <tmp> line 1
in block <unit> at <tmp> line 1
vrurg jnthn: ^
23:54 Kaiepi left 23:56 anatofuz joined
jnthn vrurg: That's a method, not a submethod 23:59
(And I don't see how it's relevant to the question in the issue.)