00:47 Xliff joined
Xliff . 00:47
00:57 Kaeipi joined, Kaiepi left
releasable6 Next release in ≈1 day and ≈15 hours. 1 blocker. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 03:00
Geth rakudo: vrurg++ created pull request #3977:
Fix a problem with multi submethods been treated as method		 03:03
roast: vrurg++ created pull request #691:
Add and fix tests for multi-dispatching methods		 03:06
03:23 Xliff left 03:26 Xliff joined 04:32 committable6 left, unicodable6 left, statisfiable6 left, releasable6 left, quotable6 left, sourceable6 left, coverable6 left, linkable6 left, evalable6 left, tellable6 left, squashable6 left, shareable6 left, nativecallable6 left, bisectable6 left, notable6 left, bloatable6 left, benchable6 left, greppable6 left 04:33 sourceable6 joined, committable6 joined, shareable6 joined, bloatable6 joined, tellable6 joined 04:34 releasable6 joined, unicodable6 joined, squashable6 joined, notable6 joined, linkable6 joined, bisectable6 joined 04:35 statisfiable6 joined, coverable6 joined, nativecallable6 joined, evalable6 joined, benchable6 joined, greppable6 joined, quotable6 joined 04:52 MasterDuke left
Xliff timotimo lizmat vrurg jnthn: repl.it/@Xliff/RoleAttributeWeirdness 05:42
timotimo: I think this golfs what I've been having a problem with.
Note the duplicated attributes.
06:41 patrickb joined 06:59 sena_kun joined 07:03 samcv left 07:34 frost-lab joined
Kaeipi releasable6, status 07:49
releasable6 Kaeipi, Next release in ≈1 day and ≈11 hours. 1 blocker. 17 out of 83 commits logged
Kaeipi, Details: gist.github.com/0dbe51fa3338b224d0...72634b143c
lizmat m: class A { has $!a }; class B is A { has $!a }; .say for B.^attributes.map( { .package.^name ~ "::" ~ .name } ) # Xliff 09:42
camelia B::$!a
A::$!a
lizmat seems a normal consequence of the way you've set up things? 09:43
this is also why in an nqp::getattr you *must* specify the class to which an attribute in an object belongs
10:24 AlexDaniel` left, unclechu left 10:31 AlexDaniel` joined 10:42 unclechu joined
Geth rakudo: 240bc9eb13 | (Elizabeth Mattijsen)++ | 2 files
Make .grep/.first on native arrays about 3.5x as fast

  - searching for Str:D on a native str array
  - searching for Int:D on a native int array
  - searching for Num:D on a native num array		 12:16
patrickb Is it possible to create numbered lists in the docs at the moment? 12:42
I'm still pondering on the lengthy explanation in docs.raku.org/routine/bless saying one shouldn't usually create a custom `new`. 13:12
Both examples given work fine when stripping out the complexity given as reason for not writing custom `new`s. 13:13
These are my simplified examples: docs.raku.org/routine/bless 13:15
vrurg .tell Xliff it's not a bug. You have two instances of attribute per class and this is how roles work. A method on parent class can't have access to attributes of a child class anyway. 13:16
tellable6 vrurg, I'll pass your message to Xliff
patrickb Can anyone enlighten me what's wrong with those?
I'm inclinded to remove those examples should there actually be no point to them. (Have they been added at a point in the past where Rakudo was not as capable enough for the more obvious ways?) 13:23
13:27 Merfont joined 13:28 Kaeipi left
patrickb Now looking at the blame of the file. Seems there was some discussion about this in the past in github.com/Raku/doc/issues/2077 13:29
13:29 patrickb left 13:30 patrickb joined, frost-lab left 14:02 MitarashiDango[m joined
Geth roast: f0e096c092 | (Elizabeth Mattijsen)++ | 3 files
Add tests for native array .grep/.first
 14:03
rakudo: cf2394772c | (Elizabeth Mattijsen)++ | 2 files
Fix errors in :k, :kv, :p handling

Spotted *after* writing tests for these cases. :-(		 14:05
Xliff vrurg: Hi. Thanks for the response. 14:06
tellable6 2020-10-23T13:16:01Z #raku-dev <vrurg> Xliff it's not a bug. You have two instances of attribute per class and this is how roles work. A method on parent class can't have access to attributes of a child class anyway.
Xliff So why does the example not set $!origin properly?
timotimo i would assume you're setting one $!origin and checking the other 14:10
didn't look close enough yet
MitarashiDango[m Hello, I want to add a flag to IO::Path's symlink method (something like :literal or :exact), so that a symlink can be created without calling .absolute on the intended link. Would there be any issue with adding that in? 14:14
lizmat MitarashiDango[m why is calling .absolute a problem? what is the use case? 14:16
timotimo to create a relative symlink probably
MitarashiDango[m ^ Yup, if I create one in a directory, and the directory moves, that symlink breaks because its not relative 14:17
lizmat ok, so it's a shortcoming of the current implementation
ugexe :literal is one less character than .absolute
tellable6 2020-10-15T23:22:17Z #raku <tbrowder> ugexe how long should it take before zef finds just-upgraded modules on cpan?
2020-10-15T23:23:07Z #raku <tbrowder> ugexe and modules.raku.org already shows the upgraded module
2020-10-16T00:28:19Z #raku <gfldex> ugexe p6bot has stopped updating the ecosystem files about 14 hours ago
vrurg Xliff: because you set $!origin on Base, not $!origin on A. 14:18
Xliff: and when you invoke Origin method you invoke the one which is installed into A. 14:20
14:33 patrickb left 14:40 sena_kun left
[Tux] With teams and Opera killed: 14:44
Rakudo v2020.09-85-gcf2394772 (v6.d) on MoarVM 2020.09-17-ga989f7b55
csv-ip5xs0.830 - 0.853
csv-ip5xs-207.968 - 8.074
csv-parser25.953 - 27.448
csv-test-xs-200.387 - 0.389
test7.737 - 7.775
test-t1.908 - 1.930
test-t --race0.861 - 0.871
test-t-2033.220 - 35.627
test-t-20 --race9.318 - 9.641
Xliff vrurg: OK, this breaks with my understanding of how Object Oriented programming works. 14:57
For one thing, there is only ever supposed to be One Attribute With A Given Name 14:58
How can I accomplish that with the given example?
vrurg Xliff: no if you do understand the model of role Raku embraced. Roles are flattened down into the consuming class. Inheritance keeps classes separate entities. 14:59
In your example setOrigin must be defined in the role the attribute defined in.
Xliff OK. So let's move that and see if I can reproduce the error. 15:00
vrurg Xliff: basically, you break the rule of attribute handling to be done where the attribute belongs. 15:01
Xliff OK
OK. If I do that, it's working. 15:02
So I think, for my purposes, I will need a way to reference the Base version of an attribute. 15:03
And I really shouldn't even need to think about that when working with Objects and Roles.
However, thanks fort the explanation.
A.new(origin => 42, origin-attribute2 => Any, origin => 99, origin-attribute2 => Any) 15:07
So... how to distinguish $!origin?
vrurg Xliff: when you deal with ! twigil – you have to think of these things. But if you reference an autogen accessor – everything will work as expected.
Xliff OK, but in this case, I always want to deal with the $!origin found in Base. 15:08
How would that be expressed?
vrurg No way to distinguish externally without low-level magic. 15:09
The only good solution is to split up the roles.
Xliff Not even something like $!self::Base::origin?
vrurg No because A doesn't have access to privates of Base. 15:10
Again, consider better encapsulation approach. Instead, you're trying to break it.
Xliff So in this situation, I should remove "does Origin" from Inherits from Origin?
vrurg Likely so. Besides, 'InheritsFrom' is generally bad name as roles do not inherit. :) 15:11
Xliff Yeah. That seems to do the trick.
However, what happens when the intent from InheritsFromOrigin is needed/ 15:12
As in, I need InheritsFromOrigin to access a method from Origin?
Do I just expect the composing class to do the right role and regerence that method anyway? 15:13
vrurg First of all, it looks like your mistake here is that you consider roles in terms of inheritance. But, in fact, they're consumed.
As to accessing a method – make the other role require a method it needs.
This way you'd guarantee compile-time check of the method existance. Then it's up to the consuming class to provide the method no matter which means are used for this. 15:14
Xliff OK. I think I see how this is intended to work. 15:16
I still think that composing two attributes of the same name in a single object inheritance chain is a Bad Idea and also LTA 15:17
vrurg Xliff: no. Do you care about internal structure of a 3rd-party class when you inherit from it? Do you care if they have $!state if you define same attribute in your class? 15:18
Geth rakudo: Kaiepi++ created pull request #3978:
Add a Mu ACCEPTS candidate for Mu:D		 15:19
vrurg And roles are symbiotic to the class consuming them. The only thing they don't share are submethods.
Xliff vrurg: I have no problem of the internal state of a third party object, but I should be able to note if I happen to name an attribute the same as someoen elses! 15:20
Preserving internal state here is irrelevant.
15:20 Merfont is now known as Kaiepi
Xliff If there is an attribute naming convention, it is more fair to throw an error and let the consuming class handle the conflict. 15:20
vrurg Xliff: a private one you have no access to? Remember, attributes are not part of the published API, only accessors are.
Xliff Masking the error and then leaving the consuming class in a broken state doesn't make sense! 15:21
vrurg: I don't see the utility to allow for attribute collision in an inheritance chain. 15:22
It just leads to confusion.
Geth roast: Kaiepi++ created pull request #692:
Add tests for Mu smartmatching
Xliff Whether you have access to it programatically or not. 15:23
If you are browsing the source code, you have expectations.
if you see an attribute named one way, you expect that attribute to be the same across the entire codebase.
If you are saying you want that expectation to change, then that's fine.
But it is not me that's fighting DECADES of OOP.
It's you.
If this is the expectation, then maybe a warning? 15:24
vrurg Xliff: I have to ran, don't have time. But your mistake is in mixing up accessors and private attributes. 15:25
Xliff Acually, my mistake is not understanding how "does" works. 15:28
I thought if we had a role R that "does A" then the it would be the equivalent of "class A does R does A" on the composing class 15:29
What you are describing is not that at all.
At any rate, thanks for the discussion. I will now have to see how to rework everything.
vrurg Xliff: I was delayed, so last note: it do 'does+does' eventually. But it only applies directly to the class consuming R. The one which inherits has it's own separate namespace. So, think of A injecting into the consuming class. And what's injected belongs only to the consuming class. Publics are available through MRO, but privates remain privates. 15:33
15:36 travis-ci joined
travis-ci Rakudo build failed. Elizabeth Mattijsen 'Fix errors in :k, :kv, :p handling 15:36
travis-ci.org/rakudo/rakudo/builds/738317107 github.com/rakudo/rakudo/compare/2...2394772c72
15:36 travis-ci left
Xliff OK. So the fix seems to be to move the equivalent of "does Base" from the role to the consuming objects. 15:38
I was hoping to save that step, but no matter.
dogbert17 I see some native array related spectest fails. Am I seeing WIP? 16:26
16:50 zostay_ joined, ugexe left 16:55 Xliff left 16:57 zostay left, zostay_ is now known as zostay 17:18 patrickb joined 17:26 ugexe joined 17:30 domidumont joined
patrickb Numbered lists in docs aren't possible, right? Is there any workaround? 17:39
Geth rakudo: mid1221213++ created pull request #3979:
Fix ecaf334 that partly caused #3966		 18:15
linkable6 RAKUDO#3966 [open]: github.com/rakudo/rakudo/issues/3966 [BLOCKER][blin][regression] Blin 2020.10, round 1
Geth rakudo: f3ffb702cc | (Alexandre Jousset)++ | lib/NativeCall.rakumod
Fix ecaf334 that partly caused #3966

The test of installation of Compress::Bzip2 failed after ecaf334. There was a change from isconcrete to isconcrete_nd in excess.		 18:27
rakudo: cb023b2120 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | lib/NativeCall.rakumod
Merge pull request #3979 from mid1221213/fix-ecaf334

Fix ecaf334 that partly caused #3966
linkable6 RAKUDO#3966 [open]: github.com/rakudo/rakudo/issues/3966 [BLOCKER][blin][regression] Blin 2020.10, round 1
tbrowder hi, raku ppl, i would like to propose a community project to help increase interest among young ppl. 18:59
vrurg patrickb: ping? 19:00
patrickb vrurg: pong
vrurg patrickb: have you tried build jvm backend on a linux recently? NQP fails on linux mint for me. 19:02
tbrowder my idea is to have something like small scholarship awards, sponsored overall by the perl foundation, and claimed by individual sponsors.
vrurg patrickb: "Missing or wrong version of dependency 'gen/jvm/stage2/NQPCORE.setting'"
Geth rakudo: mienaikage++ created pull request #3980:
Add flag for creating symlinks without absolute path
tbrowder the scholarships would be for somthing like a smaller scale version of the google summer of code. 19:03
19:03 Xliff joined
patrickb vrurg: I didn't. (Actually I'm not sure whether I ever managed to build JVM locally. I mostly tested via CI so far...) 19:04
vrurg: Does the NQP build fails or Rakudo?
tbrowder we could do something like beef up the module most wanted list...
vrurg NQP.
patrickb Do you know whether its 19:05
tbrowder oops, wrong channel
patrickb missing or stale?
vrurg patrickb: it's definitely not missing. I can't be stale because it's a fresh build. 19:06
Xliff vrurg: Another aside to the role thing. It makes code maintenance harder, because I can't place the Base object behind a proxy role. 19:08
patrickb Hm. My experience with this failure is that it always ended up being right about the version mismatch. Is there a previous installation in some other folder maybe?
Xliff Any consuming objects now have to "does Base does SoemthingElseUsingBase" 19:09
It makes maintenance harder.
vrurg patrickb: not for JVM.
Xliff: I think you have a design issue. If the problematic attribute should be a sole property of Base then make it so! Move everything related to it either into Base or into a separate role. 19:12
patrickb Hm. I'll see if I manage to build a JVM locally.
I'm away for a bit...
Xliff vrurg: I'm using GLib's design. 19:13
Trying to make Role serve the place of Interface, which it closely maps.
vrurg patrickb: there is no big deal about it usually. Just install openjdk and that's all you need. 19:14
Xliff: why you say "does Base does SomethingElse"? "is Base"? And what's SomethingElse? 19:17
Xliff vrurg: Ideally though Base should be an object, not a role. So that might be the problem, right there.
vrurg Xliff: based on your example, Base is a class. Thus, "is Base". Otherwise I'm lost in what you're trying to achieve. Your code snippet now looks about right to me. 19:21
Xliff vrurg: Yes. Base needs to become an object. It's always been a role and I haven't had time to make it an object. that's been on the software map for a long time. Just never had the chance to fix the implementation 19:22
Geth rakudo: c37ffe71bd | (Elizabeth Mattijsen)++ | 2 files
Make .unique/.repeated/.squish on native arrays faster

  - .unique between 1.6x and 7.6x as fast
  - .repeated between 2.0x and 2.5x as fast
  - .squish between 1.8x and 6.8x as fast
Also add a dedicated native array .Seq method.		 19:35
roast: 5d93b6803c | (Elizabeth Mattijsen)++ | 3 files
Add tests for native array .unique/repeated/squish
 19:36
19:47 samcv joined
lizmat suddenly realizes that "my @a = ^100; say @a.Seq[99]" *will* actually copy the @a array into a cache, whereas it could well just access the array underlying the Seq 19:48
19:59 finsternis left
lizmat invites thoughts about github.com/rakudo/rakudo/pull/3980 20:05
20:05 nwc10 joined
nwc10 fatal: Not a git repository: '/home/nick/Perl/rakudo/t/spec/.git' 20:05
That means my checkout is a little bit old? 20:06
lizmat does it have a config in it ?
nwc10 :-)
lizmat eh.. the git repo would be "/home/nick/Perl/rakudo/t/spec", no ? 20:07
nwc10 seems that I didn't build Rakudo on that machine. nqp says
This is nqp version 2015.03-125-g53d43e8 built on MoarVM version 2015.03-148-g8bb5da8
lizmat ah, wow
nwc10 anyway, woohoo, it has valgrind
ho, it's not as crazy as I thought 20:08
it doesn't actually have a spectest checkout
it's not simply that it dates from 2105
20:10 finsternis joined
nwc10 oh pants. its Fedora. no IPC::Cmd 20:12
vrurg wonder when was it the last time anybody needed JVM backend? 20:20
*wonders
Xliff Windows users want raku to target .exe 20:21
Until that happens, JVM backend is the closest they can get since they can target JAR
vrurg Does it build on Windows? 20:24
Xliff It used to.
It used to build under Cygwin, but I couldn't get it to work, last night.
I know Star is on Windows.
Would be interested to know how they build rakudo so I can do so, myself. 20:25
vrurg I always had problems building JVM on Win and never on Mac. Now it turns out JVM is broken altogether.
20:35 Geth left 20:36 Geth joined 20:37 dogbert17 left, dogbert17 joined 20:38 raku-bridge left
nwc10 fixed that. next problem - branch `nom` is just a little out of date 20:43
patrickb vrurg: I managed to reproduce the problem locally. 20:56
vrurg patrickb: I'm trying to locate the guilty commit. 2020.02.1 release is the last working one. 2020.05 is broken. 20:57
And I probably found the last working commit right now... Just waiting for build to finish to make sure. 20:58
patrickb: b0ddeda683a1b90399f92d9845f1499c3ea68f2f still compiles. The likely suspect is 3d69dc107b73d9127235297219c21418148a85e0. 21:01
patrickb Maybe the `#.NOTPARALLEL`? 21:04
vrurg patrickb: It worked well and it should work. 21:05
But I'm testing it now. 21:07
patrickb :-) me too
vrurg And it seemingly works. Heh... :( 21:09
patrickb That means, that some dependency is not stated correctly. Right? 21:10
I think it should compile NQPCORE.setting before nqpmo. (The original error being nqpmo failing with being unable to find NQPCORE.setting, which at that point actually wasn't compiled (NQPCORE.setting.jar didn't exist).) 21:12
vrurg patrickb: I'm trying it. 21:16
patrickb I need to reboot. Back in a bit. 21:17
vrurg Oops, CORE_SETTING depend on nqp_mo
21:17 patrickb left 21:26 patrickb joined
patrickb vrurg: Can't we deduce a working build order when looking at a `.NOTPARALLEL` build? 21:46
vrurg patrickb: possibly. But I go other way around. JASTNodes currently fails and when it does there is no .jar for NQPCORE. And JASTNodes doesn't actually depend on NQPCORE. 21:48
But somehow when I add dependency in the template it is not propagated into Makefile. I likely to forget something... 21:50
vrurg was editing in a directory different from the one where he was compiling. This evil directory name shortening in CLI prompt... 21:56
patrickb: ok, that was it. A missing dependency on NQPCORE. 22:01
Geth nqp: 688019c375 | (Vadim Belman)++ | tools/templates/Makefile-backend-common.in
Add a missing dependency

Fixes parallel build.		 22:03
patrickb yay! 22:11
releasable6 Next release in ≈19 hours. 1 blocker. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 23:00
Geth rakudo: 219978e12e | (Elizabeth Mattijsen)++ | src/core.c/core_epilogue.pm6
Fix JVM build

The JVM doesn't know about Uni yet, spotted by vrurg++		 23:04
vrurg lizmat: didn't expect you to be awake and tried to find a better solution to the problem. 23:06

Powered by Cro and the Raku® Programming Language.

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

Thank you!