00:13 sena_kun left 00:27 Kaeipi left, sena_kun joined 00:28 Kaeipi joined
vrurg_ .seen altai-men 01:41
tellable6 vrurg_, I haven't seen altai-men around, did you mean Altai-man_?
vrurg_ .seen Altai-man
tellable6 vrurg_, I saw Altai-man 2019-12-23T13:21:08Z in #raku-dev: <Altai-man_> ok, now $dayjob
01:41 vrurg_ is now known as vrurg
vrurg .tell Altai-man I made #3311 a blocker. Even though it's macos specific but it's a cornerstone feature which is broken. 01:43
tellable6 vrurg, I'll pass your message to Altai-man_
Xliff vrurg: o/ 01:57
vrurg Xliff: o/ :)
Xliff vrurg: Are you going to be around this weekend?
vrurg Likely. But can't promise. 01:58
Xliff Can you tell me why this method isn't executing: github.com/Xliff/Method-Also/blob/...so.pm6#L38
Do I have the method name wrong? 01:59
AliasableClassHOW to be punned to ClassHOW
vrurg Yes, you have. 02:00
Xliff Argh!
Thanks!
vrurg Xliff: You can't do proper MOP without introspecting rakudo sources.
Xliff Heh. Yeah. Was doing that. 02:01
Bad brain.
vrurg Xliff: BTW, what do you need specialize_with for? I mean, I saw you take typeenv, but what for?
Xliff Need that for .^add_multi_method() 02:02
vrurg The problem is that specialize_with is a backend kind of method. I would rather have it private for that matter.
Xliff Rather. I need it for .code.instantiate_generic()
If I don't need .instantiate_generic() I can remove the need for .specialize_with() altogether. 02:03
vrurg Xliff: There must be a way. I hope it is somewhere. 02:04
Xliff vrurg: OK. I will see if I can work around that, but I used existing code sources to build that bit. 02:05
vrurg Xliff: the point is your installed methods are better be instantiated by the core MOP. So, best if you get them installed prior to role specialization. 02:06
Xliff Not if it's a proto.... 02:07
It's that same issue.... 02:08
Would this be better done in compose?
vrurg Errr, right... protos... 02:09
compose should be ok, but I'm too sucked out for today to consider all possible side effects. 02:10
Xliff: BTW, Vikna turn out to be way more complicated task than I initially expected. 02:11
Xliff vrurg: Will try compose, then.
So I should just use .^add_method rather than .^add_multi_method, you think? 02:12
vrurg Xliff: I think it still has to be add_multi_method. Best if you look into RoleToClassApplier. 02:13
02:14 sena_kun left
Xliff Ah! Thanks for the tip! 02:14
vrurg What's good about that is apply method receives concretized roles as its input. Thus, you get all parameterizations and closures done. 02:15
Xliff OK. 02:16
Geth_ rakudo: vrurg++ created pull request #3385:
Try matching parameters by their addresses		 02:20
02:30 sena_kun joined
Geth_ roast: vrurg++ created pull request #607:
Add tests for smarmatching of parameterized Array against Positional		 02:37
vrurg Xliff: it was a great advise on my side except that you can't use it. It just've crossed my mind that RoleClassApplier is never getting instantiated. There is no way to intercept a method of it... :( 02:40
Xliff :( 02:41
Is that a bug?
vrurg No, it's implementation specific. It's used as a kind of a module, only contains methods.
Xliff Ahhh... 02:42
Even so, those can still be overridden, correct?
vrurg Xliff: but in either case you could try with add_concretization which is anyway invoked for each concrete role.
Xliff OK.
vrurg Xliff: it can but what's the point? ClassHOW compose invokes it as `RoleToClassApplier.apply(...)`
Ah!!!! 02:43
Kill me!
Xliff I'd rather not.
vrurg Ok, a good sleep would do too. :D Can't get it if `does` would do the trick in this case or not? I would rather say it won't because ClassHOW has the pure RoleToClassApplier type object compiled into. 02:44
Xliff Good idea. 02:45
vrurg is getting back to what he is capable of at this moment...
Xliff I'll be around. Just .tell me something if necessary. ;)
Thanks for the help!
vrurg yep!
vrurg is leaving murmuring... 02:46
Xliff: welcome!
Geth_ rakudo: fb55ae295a | (Vadim Belman)++ | src/Perl6/Metamodel/CurriedRoleHOW.nqp
Try matching parameters by their addresses

Thus we can match a definite to itself and have R[T:D] ~~ R[T:D] in cases where lhs comes from a class as a consumed role and has different object id from rhs. For example, this solves `Array[Str:D] ~~
  `Positional[Str:D]`.		 03:41
rakudo: 8d47f64cdd | (Vadim Belman)++ (committed using GitHub Web editor) | src/Perl6/Metamodel/CurriedRoleHOW.nqp
Merge pull request #3385 from vrurg/rakudo_3383

Try matching parameterization parameters by their addresses
roast: eee0c322ae | (Vadim Belman)++ | S03-smartmatch/any-type.t
Add tests for smarmatching of parameterized Array against Positional

Also structurize tests using `subtest` routine.
roast: e7d4dea402 | (Vadim Belman)++ (committed using GitHub Web editor) | S03-smartmatch/any-type.t
Merge pull request #607 from vrurg/rakudo_3383

Add tests for smarmatching of parameterized Array against Positional		 03:42
04:15 sena_kun left 04:30 sena_kun joined 04:56 Kaeipi left 04:57 Kaeipi joined, Kaeipi left 04:58 Kaeipi joined
Xliff m: my $p = Promise.new; $p.break; 05:20
camelia ( no output )
Xliff m: say while False; 05:30
camelia 5===SORRY!5=== Error while compiling <tmp>
Unsupported use of bare "say"; in Perl 6 please use .say if you meant to call it as a method on $_, or use an explicit invocant or argument, or use &say to refer to the function as a noun
at <tmp>:1…
Xliff m: say '' while False;
camelia ( no output )
06:14 sena_kun left 06:28 cognomin_ joined 06:30 sena_kun joined 06:31 cognominal left 07:31 sourceable6 left, nativecallable6 left, greppable6 left, notable6 left, releasable6 left, quotable6 left, benchable6 left, coverable6 left, tellable6 left, reportable6 left, bisectable6 left, bloatable6 left, statisfiable6 left, squashable6 left, shareable6 left, evalable6 left, committable6 left, unicodable6 left 07:32 statisfiable6 joined, unicodable6 joined, shareable6 joined, benchable6 joined, nativecallable6 joined, quotable6 joined 07:33 sourceable6 joined, notable6 joined, greppable6 joined, committable6 joined, releasable6 joined, coverable6 joined, squashable6 joined, evalable6 joined 07:34 bisectable6 joined, reportable6 joined, tellable6 joined, bloatable6 joined
Xliff .tell vrurg Hmmm... If I am already overriding ClassHOW.compose, doesn't that mean I can use my own RoleToClassApplier? 07:42
tellable6 Xliff, I'll pass your message to vrurg
07:50 Xliff left 08:14 sena_kun left 08:28 sena_kun joined
sena_kun 09:06
lizmat Files=1294, Tests=109635, 211 wallclock secs (28.31 usr 7.81 sys + 2966.28 cusr 267.88 csys = 3270.28 CPU) 09:12
09:15 Voldenet left
sena_kun vrurg: I don't mind the new blocker, and we probably won't make a release anyway, too close to holidays. Yet I'll patch Blin considering my ideas and findings, hope it'll make checking things much more easier. 09:19
.oO ( first release and such a failure already, me is pathetic ) 09:21
10:14 sena_kun left 10:28 sena_kun joined
AlexDaniel sena_kun: it's alright. Releasing in late December isn't the best plan anyway 11:02
robertle: what's the situation with debian? 11:03
robertle: I see that rakudo was yeeted from testing
at the same time unstable seems to be up to date 11:04
lizmat grr... benchmarking my new val code shows that it is only 2x as fast for a very simple case, and 2-3% slower for most other cases 11:21
on the brighter side, the new code does pass all of the new val tests, whereas the old code fails 254 / 1856 tests 11:22
and the new code has about 60% of the allocations of the old code 11:23
but still :-(
seems I need to go back to the drawing board
at least there's more test coverage now
nine Yeah, more correct and only twice as fast in common cases? I'd be disappointed, too :) 11:46
Or maybe not ;)
lizmat well, I'm not happy with it yet... 12:00
my goal was to make it faster overall 12:01
and I'm not happy with the maintainability of the new code either :-(
nine Well, still sounds like you made a pretty good first step :) 12:12
lizmat doesn't feel like it, after 2 weeks or so :-( 12:13
12:14 sena_kun left
lizmat meanwhile, I'm finding bugs: github.com/rakudo/rakudo/issues/3386 12:16
also: github.com/rakudo/rakudo/issues/3382 12:17
12:29 sena_kun joined 12:40 Voldenet joined, Voldenet left, Voldenet joined 13:40 evalable6 left, evalable6 joined 14:13 sena_kun left 14:29 sena_kun joined
Geth_ rakudo: 5c65a126c4 | (Stefan Seifert)++ | 2 files
Fix race condition in NativeCall setup

Since commit 9ef7a7e9dd0a6baecc811faa42c1b042d8bc5452 a NativeCall site is marked as set up as soon as the nqp::buildnativecall op is run. At that point however a few attributes had not been initialized yet. Fix this by moving their initialization to before nqp::buildnativecall. Replacing the native sub's body with the optimized version may wait for initialization as worst case we're ... (6 more lines)		 15:50
16:14 sena_kun left 16:29 sena_kun joined 18:13 sena_kun left 18:28 sena_kun joined 19:11 Xliff joined
Xliff . 19:11
sena_kun lizmat: ping? 19:21
lizmat pong 19:39
sena_kun: pretty sure the precomp issues with constant &a has been around for a loooong time 19:40
sena_kun lizmat: ah, okay, then no need to check it by hands 19:44
though that'd be odd, I mean, we do have different modules with constants and they are, hmm, precompiled 19:45
lizmat yeah, but no *code* constants
I don't think ?
sena_kun but what I was going to ask is how do you run it, because I am actually getting `Could not find A at line 1 in:`. : O
which is odd
or maybe not 19:46
oh, I am dumb
ok, confirmed
lizmat I put the file in "lib" and run it with -Ilib, not -I.
ok :-)
sena_kun `-I.` instead of `-Ilib` helped me. :)
20:14 sena_kun left 20:20 Xliff left 20:30 sena_kun joined 21:26 |Tux| left 21:55 Kaeipi left 21:56 Kaeipi joined 22:14 sena_kun left 22:19 |Tux| joined 22:28 sena_kun joined 23:28 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!