01:03 squashable6 left 01:05 squashable6 joined 01:07 pmurias left 01:12 squashable6 left 01:14 squashable6 joined 01:36 vrurg joined
Geth roast: mienaikage++ created pull request #596:
Add test to check UInt on non-numeric Str returns a Failure		 02:49
03:41 Xliff left 04:41 statisfiable6 left, bloatable6 left, unicodable6 left, releasable6 left, reportable6 left, benchable6 left, quotable6 left, greppable6 left, committable6 left, squashable6 left, coverable6 left, nativecallable6 left, shareable6 left, notable6 left 04:42 notable6 joined, committable6 joined, reportable6 joined 04:43 evalable6 joined, tellable6 joined, releasable6 joined, unicodable6 joined, greppable6 joined, quotable6 joined, nativecallable6 joined 04:44 benchable6 joined, shareable6 joined, squashable6 joined, statisfiable6 joined, coverable6 joined, bloatable6 joined 05:15 entonian joined 05:17 entonian left 07:06 sena_kun joined 07:22 ufobat joined 09:07 Altai-man_ joined 09:09 sena_kun left 10:06 patrickb joined
Geth roast: 0a0fa6d574 | (Daniel Mita)++ | S32-str/numeric.t
Add test to check UInt on non-numeric Str returns a Failure
 10:29
roast: 0a0835a209 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | S32-str/numeric.t
Merge pull request #596 from mienaikage/uint-failure-test

Add test to check UInt on non-numeric Str returns a Failure
rakudo: a9cd6404de | (Elizabeth Mattijsen)++ | src/core.c/Cool.pm6
Remove support for :match from comb() if not needed

After a night's sleep, I realized that the :match named variable only makes sense if you specify a Regex. So remove the support for :match for the other candidates for now, as to prevent confusing people even more when specifying
  :match in those cases, wouldn't actually produce Match object results.		 10:34
|Tux| Rakudo version 2019.07.1-470-gdd2f072d6 - MoarVM version 2019.07.1-315-gf10a31b43
csv-ip5xs0.706 - 0.722
csv-ip5xs-206.297 - 6.507
csv-parser21.186 - 21.699
csv-test-xs-200.417 - 0.424
test5.811 - 7.043
test-t1.731 - 1.851
test-t --race0.827 - 0.844
test-t-2028.559 - 29.052
test-t-20 --race9.342 - 10.039
 10:41
11:08 sena_kun joined 11:10 Altai-man_ left
lizmat so, what does this error actually mean? 11:19
Deprecated use of %*LANG<dynamic-scope> assignment detected in use; module should export syntax using $*LANG.define_slang("dynamic-scope",<grammar>,<actions>) instead
(value in braid: BOOTCode, value in %*LANG: BOOTCode)
it seems to occur when a some of my P5 modules are used inside a pre-compiled module, aka P5built-ins 11:20
specifically P5getservbyname, P5math and P5-X 11:21
jnthn Do they make use of slangs somehow? 11:22
Ah, though looking at the name...I wonder if it's about the dynamic $_ mechanism 11:29
Geth rakudo: 7f15a57c38 | Altai-man++ | t/05-messages/10-warnings.t
Test rakudo-specific warning for shape specifier

A simple test that runs code and checks if a warning is issued. Closes github.com/rakudo/rakudo/issues/2545		 11:33
rakudo: d36c2e5a44 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | t/05-messages/10-warnings.t
Merge pull request #3245 from Altai-man/test-warning

Test rakudo-specific warning for shape specifier
lizmat jnthn: yeah, but it only complains about those 3 modules 11:35
and many modules make use of the $_ mechanism
it feels to me, it is some kind of corruption going on 11:36
lizmat tries to change the order of module loading to see if that makes a difference
jnthn Doubt it, I suspect just some of them hit the path that triggers the deprecation check
lizmat well, P5getservbyname and P5getnetbyname are basically the same, but call differen libc functions 11:38
yet P5getservbyname complains, and P5getnetbyname doesn't
also, just loading the module separately, does not make that message appear 11:40
only if that module is used *inside* of another module being precomped
oops... user error, it wasn't P5getservbyname 11:41
P5print is the one, which support your $_ theory, jnthn 11:42
ok, looks like "my sub term:<> is export" is the cause in that case 11:44
jnthn Ah, and that is a language tweak (adding a new term) so would feasibly trigger the deprecation check too 11:45
lizmat yeah, so it looks like exporting a term into a precomped module is not doing it right
ah, and P5-X is doing sub prefix:<> is export 11:46
ah, and P5seek is also doing a sub term:<> is export 11:47
ok, so they all share the same issue
jnthn: now where in the bowels, would I find this ? 11:48
any hints?
jnthn grep for dynamic-scope as a starting point
lizmat oki
Geth rakudo/master: 4 commits pushed by (Christian Bartolomäus)++, (Elizabeth Mattijsen)++
11:51 travis-ci joined
travis-ci Rakudo build failed. Elizabeth Mattijsen 'Remove support for :match from comb() if not needed 11:51
travis-ci.org/rakudo/rakudo/builds/610793859 github.com/rakudo/rakudo/compare/d...cd6404de26
11:51 travis-ci left
lizmat restarted the one failing job 11:51
jnthn: so it looks like it is doing a: $*LANG.set_pragma('dynamic-scope' 11:53
but it is not actually setting %*LANG<dynamic-scope> there
so I guess it's inside .set_pragme
*set_pragma
jnthn Hmm, curious... 11:54
lizmat but that's an NQP thing, no?
can't seem to find any method by that name in src/Perl6
moritz lizmat: it's in NQP, QRegex/Cursor.nqp 11:55
lizmat right... so this would indicate an NQP issue, rather than a Rakudo one ? 11:56
moritz can't say 12:09
lizmat hmmm... does not appear to be easily reproducable 12:33
12:39 AlexDaniel` left, rba[m] left, timotimo[m] left
lizmat afk for most of the rest of the day& 12:43
13:07 Altai-man_ joined 13:09 sena_kun left 13:24 tyil[m] joined, Demos[m] joined, AlexDaniel` joined, rba[m] joined, timotimo[m] joined 13:26 robertle_ joined 14:11 lucasb joined 15:08 sena_kun joined 15:09 Altai-man_ left 16:05 robertle_ left 16:38 patrickb left 17:07 Altai-man_ joined 17:09 sena_kun left 17:44 MasterDuke left 18:06 Altai-man_ left 18:10 sena_kun joined 18:11 sena_kun left 18:14 patrickb joined 18:29 sena_kun joined 18:31 sena_kun left 18:35 sena_kun joined 18:36 sena_kun left 18:43 vrurg left 18:44 vrurg joined 18:58 vrurg left, vrurg joined 19:23 squashable6 left 19:25 squashable6 joined 19:48 entonian joined 19:50 entonian left 19:51 entonian joined 19:54 entonian left 20:14 ufobat_ joined 20:18 ufobat left 20:27 brrt joined
TreyHarris tbrowder: I've had a go at responding to github.com/rakudo/rakudo/issues/3296 we discussed yesterday. 20:32
20:42 MasterDuke joined
tbrowder Trey Harris: sounds excellent to me. i hope todd will consider it carefully (maybe with a lawyer present) 21:33
21:38 patrickb left
[Coke] wonders why make install has one step in ALL CAPS. 21:40
+++ MOAR BACKEND INSTALLED
22:24 Kaiepi left, Kaeipi joined
vrurg [Coke]: I'm now asking myself - why. No good answer comes into mind. ;) 23:07
23:09 brrt left
vrurg greppable6: find_method_qualified 23:13
greppable6 vrurg, 2 lines, 1 module: gist.github.com/a64d6fe4ffa2c42ae6...efd8fad24d
jnthn 'CUS IT'S EXCITING! ;) 23:38
[Coke] jnthn: :P 23:41
vrurg is blush 23:44
jnthn: BTW, would would you say if I make find_method_qualified method return not only method itself but the concrete type object it was found on? 23:45
*what would 23:46
jnthn Hm, why?
It feels odd to me
Can't you query that by doing .package on the returned method?
vrurg jnthn: .package would return non-concrete, AFAIR. 23:47
I'm trying to get a proper fix for qualified calls. They're currently flawed as they might pick up incorrect role. 23:48
jnthn Hm, what do you mean specifically by "concrete type object"?
m: role R { method m() { } }; class C does R { }; C.^lookup('m').package.say
camelia (R)
jnthn Ah, right, that's a declarative property 23:49
m: role R { method m() { } }; class C does R { }; C.^lookup('m').signature.params[0].type.say
camelia (C)
vrurg It could be either role conretization or $qtype itself, depending if concretization is possible.
jnthn That's...hacky though :)
I think it'd want some kind of new API rather than changing the return value of the existing one, anyway. 23:50
Though I do wonder if there's a way to pass something as an option to find_method_qualified so *it* can do the check and just not return the method if it doesn't match up to that?
23:51 lucasb left
vrurg jnthn: The problem is a bit more complex than that. Let me find the gist which demoes part of the problem. 23:51
gist.github.com/vrurg/1063b8a62260...405edb9f5d 23:52
m: gist.github.com/vrurg/1063b8a62260...405edb9f5d
camelia --- Foo::foo
Foo a==1
Foo!a: 1
R::info ::?CLASS: (Foo)
--- Bar::foo
1. Bar a==1
Foo a==2
Foo!a: 0
R::info ::?CLASS: (Bar)
2. Bar a==2
vrurg This is just one issue: parent class referring same role as it's child gets qualification pointing at child's concretization.
jnthn Ah 23:53
Um, I'm surprised that `self.Foo::R::info` even works
vrurg Worse happens if class consumes a parameterized role and another role which consumes another parameterization of the same role. 23:54
jnthn Yeah, that's an interesting problem...
Wonder if it's solvable by giving find_method_qualified a :from, and we pass the enclosing package. 23:55
vrurg So, dispatch of :: must preserve the concrete type object it used to resolve a method in order for any subsequent dispatch to know where to look.
jnthn: find_method_qualified doesn't need it. 23:56
jnthn So...what does? 23:57
The thing that finds concretizations?
vrurg dispatch:<::>. I provide it with ::?CALLER-TYPE from upstream in Actions and it kinda works.
Right, I currently see no other option but to replace it with a dynamic $*CALLER-TYPE or alike and upstream dispatcher would set it to the concretization. 23:58
Compile-time is obviously faster, but, unfortunately, only run-time knows the correct answer. :( 23:59

Powered by Cro and the Raku® Programming Language.

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

Thank you!