🦋 Welcome to the IRC channel of the core developers of the Raku Programming Language (raku.org #rakulang). This channel is logged for the purpose of history keeping about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | Logs available at irclogs.raku.org/raku-dev/live.html | For MoarVM see #moarvm Set by lizmat on 8 June 2022. |
|||
00:00
reportable6 left,
reportable6 joined
00:05
kjp left
00:37
kjp joined
04:00
notable6 left,
unicodable6 left,
squashable6 left,
tellable6 left,
coverable6 left,
linkable6 left,
sourceable6 left,
evalable6 left,
bisectable6 left,
reportable6 left,
nativecallable6 left,
shareable6 left,
releasable6 left,
benchable6 left,
quotable6 left,
greppable6 left,
statisfiable6 left,
bloatable6 left,
committable6 left,
statisfiable6 joined
04:01
bisectable6 joined,
tellable6 joined,
shareable6 joined,
sourceable6 joined,
evalable6 joined,
committable6 joined,
notable6 joined
04:02
coverable6 joined,
reportable6 joined,
greppable6 joined,
nativecallable6 joined,
bloatable6 joined,
quotable6 joined,
squashable6 joined,
unicodable6 joined
04:03
releasable6 joined,
linkable6 joined,
benchable6 joined
05:41
Xliff left
06:00
reportable6 left
06:01
reportable6 joined
|
|||
bartolin | btw, it looks like this would unbreak the JVM build: gist.github.com/usev6/020176b7f817...01e7f4b917 | 06:21 | |
It seems to have worked fine in the past and I didn't see yet when/why the old code started to fail. | 06:22 | ||
anyway, off to $dayjob now & | |||
07:25
squashable6 left
07:26
squashable6 joined
07:28
ab5tract joined
08:29
sena_kun joined
09:49
squashable6 left,
bisectable6 left,
bloatable6 left,
evalable6 left,
statisfiable6 left,
releasable6 left,
benchable6 left,
greppable6 left,
reportable6 left,
nativecallable6 left,
linkable6 left,
quotable6 left,
sourceable6 left,
coverable6 left,
shareable6 left,
unicodable6 left,
tellable6 left,
committable6 left,
notable6 left
09:50
unicodable6 joined,
squashable6 joined,
sourceable6 joined,
statisfiable6 joined,
linkable6 joined,
quotable6 joined,
shareable6 joined,
notable6 joined
09:51
tellable6 joined,
coverable6 joined,
evalable6 joined,
releasable6 joined,
bisectable6 joined,
bloatable6 joined
09:52
greppable6 joined,
nativecallable6 joined,
committable6 joined,
reportable6 joined,
benchable6 joined
09:57
Altai-man joined
09:59
sena_kun left
|
|||
lizmat | m: dd "AA".parse-base(16) | 09:59 | |
camelia | 170 | ||
lizmat | m: say "A".uniname # TIL you can also use full-width letters for hex numbers ? | ||
camelia | FULLWIDTH LATIN CAPITAL LETTER A | ||
ab5tract | I'm starting to understand why qualified method calls are NYI | 10:28 | |
talk about torturing the implementor... | 10:30 | ||
lizmat | hehe :-) ++ab5tract | 10:33 | |
ab5tract | I've got a situation where I need a type object in order to fill in a QAST::WVal, but if I use implicit-lookups and .resolution.compile-time-value, it will fail if the type doesn't exist. | 10:42 | |
I also don't have a resolver object in scope for this method | 10:43 | ||
Geth | rakudo/main: d3b53807ea | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp RakuAST: moved some elements of HLL::Grammar to Raku::Grammar As a start to completely lose NQP's HLL::Grammar as a base class, which is needed to be able to use OperatorProperties properly during parsing and be able to get rid of the operator info hashes. Also added some documentation markers for better readability |
11:05 | |
lizmat | ab5tract: I think in some cases his is fixed by adding an attribute, and putting the type object in it at resolve timer | 11:06 | |
*time | |||
*this | |||
ab5tract | ack, thanks | 11:08 | |
lizmat: is there any way to "create" a type object (just the object, no installation or anything) without resolution? | 11:37 | ||
lizmat | does it exist in the setting? | ||
ah, no, you'd need a resolver object for that as well | 11:38 | ||
ab5tract | it's a user-defined (or not) type | 11:51 | |
lizmat | I don't know of a way without a resolver | 11:53 | |
ab5tract | m: role A { method m() { self.x } }; class B does A { has $.x = 42; method m() { self.D::m() } } | ||
camelia | ( no output ) | ||
ab5tract | m: role A { method m() { self.x } }; class B does A { has $.x = 42; method m() { self.D::m() } }; B.new.m | 11:54 | |
camelia | Cannot dispatch to method m on Failure because it is not inherited or done by B in method m at <tmp> line 1 in block <unit> at <tmp> line 1 |
||
ab5tract | ^^ the above doesn't check whether the type is defined or not | ||
but that actually seems to make sense according to the base compiler (it doesn't complain about not finding D until run-time) | 11:55 | ||
12:00
reportable6 left,
reportable6 joined
|
|||
lizmat | yeah, method call lookup is runtime, whether fully qualified or not | 12:00 | |
m: class A { }; A.B::foo() | 12:01 | ||
camelia | Cannot dispatch to method foo on Failure because it is not inherited or done by A in block <unit> at <tmp> line 1 |
||
lizmat | that's actually an LTA error | ||
looking at the QAST in the legacy grammar | 12:02 | ||
it appears to be doing a nqp::who($?PACKAGE).AT-KEY("B").foo | 12:04 | ||
Geth | rakudo/ugexe/bartolin-fix-jvm-maybe: 3c3c40cca4 | (Nick Logan)++ | src/Perl6/Actions.nqp Fix JVM build |
12:07 | |
rakudo: ugexe++ created pull request #5365: Fix JVM build |
12:08 | ||
rakudo/ugexe/bartolin-fix-jvm-maybe: 1227b40723 | (Nick Logan)++ | src/Perl6/Actions.nqp Fix JVM build |
12:10 | ||
ab5tract | well, my half-baked fix does bring +3 spectests into the fold | 12:11 | |
lizmat | so why is it half-baked then? | 12:16 | |
ab5tract | it behaves differently from base in that it dies when the qualified package is not found | 12:22 | |
I have a chicken-egg situation with constructing the call to dispatch:<::> -- it wants a type object, but if the qualified package is not resolvable... | 12:23 | ||
let me push, maybe that will make things clearer | |||
Geth | rakudo: ab5tract++ created pull request #5366: RakuAST: Fix t/spec/S14-roles/basic.t |
12:26 | |
ab5tract | lizmat ^^ | 12:28 | |
lizmat | ab5tract some nits and questions | 12:30 | |
otherwise looks good :-) | |||
ab5tract | nits and questions should now be addressed | 13:10 | |
&& shortcircuits in NQP and it's RakuAST variant, right? | 13:17 | ||
lizmat | yes, && shortcircuits everywhere | 13:22 | |
afaik :-) | |||
Geth | rakudo/main: fc9debac98 | (Elizabeth Mattijsen)++ | 2 files RakuAST: Streamline integer handling a bit - make these tokens better readable - don't capture what doesn't need capturing - copy "integer" action from HLL::Actions to reduce dependency |
14:11 | |
rakudo/main: a369b57fbe | (Elizabeth Mattijsen)++ | 2 files Make X::Worry::P5::LeadingZero exception more readable And adapt test that was a little too keen on specific format |
|||
rakudo/main: 1227b40723 | (Nick Logan)++ | src/Perl6/Actions.nqp Fix JVM build |
14:16 | ||
rakudo/main: c12f478a1c | (Nick Logan)++ (committed using GitHub Web editor) | src/Perl6/Actions.nqp Merge pull request #5365 from rakudo/ugexe/bartolin-fix-jvm-maybe Fix JVM build |
|||
ugexe | indeed, that fixed the JVM ci tests | ||
bartolin++ | |||
hmm actually there was a linux and mac test failure that look like they are unrelated, but maybe they werent | 14:18 | ||
Lin_MVM_reloc passed but Lin_MVM failed a test, and Mac_MVM_reloc failed a test but Mac_MVM passed | 14:19 | ||
14:22
evalable6 left,
linkable6 left,
evalable6 joined,
linkable6 joined
15:22
committable6 left,
linkable6 left,
reportable6 left,
statisfiable6 left,
unicodable6 left,
nativecallable6 left,
bisectable6 left,
tellable6 left,
benchable6 left,
releasable6 left,
coverable6 left,
evalable6 left,
shareable6 left,
sourceable6 left,
greppable6 left,
quotable6 left,
squashable6 left,
notable6 left,
bloatable6 left
15:23
greppable6 joined,
releasable6 joined,
notable6 joined,
sourceable6 joined,
bisectable6 joined
15:24
linkable6 joined,
unicodable6 joined,
benchable6 joined,
reportable6 joined,
shareable6 joined,
nativecallable6 joined,
statisfiable6 joined,
committable6 joined,
bloatable6 joined,
coverable6 joined
15:25
squashable6 joined,
quotable6 joined,
tellable6 joined,
evalable6 joined
|
|||
ab5tract | hmm, so the regressions in my branch are both related to assigning Inf/Nan to Int | 15:45 | |
Geth | rakudo/main: c4674f7000 | (Elizabeth Mattijsen)++ | src/Raku/ast/operator-properties.rakumod Add OperatorProprties support for allowable openers/closers For custom (post)circumfix operators. Adds the following class methods: - bracket-openers returns all ok openers as a single string - bracket-closers returns all ok closers as a single string - bracket-closer-for-opener return closer for given opener, if any - bracket-opener-for-closer return opener for given closer, if any |
15:48 | |
lizmat | ab5tract: that feels.... odd? | ||
ab5tract | It goes from a sorry t(with slightly misleading instructions that suggest coercing Inf.Int or Int(Inf)) to a runtime assignment failure (Type check failed in assignment to $f; expected Int but got Num (Inf)) | ||
yeah, I mean I fiddled with the logic that controls dispatching to that sorry, but I can't see where the current code would let NaN and Inf slip through | 15:51 | ||
"not ok 22 - trying to assign NaN to Int gives a helpful error" | |||
technically the new behavior still fulfills the spirit of the test | 15:52 | ||
lizmat | except maybe now it's a runtime rather than a compile time error ? | ||
ab5tract | well, that's why it's failing the reality of the test :) | 15:53 | |
lizmat | m: my Int $a = Inf | ||
camelia | ===SORRY!=== Error while compiling <tmp> Cannot assign a literal of type Num (Inf) to a variable of type Int. You can declare the variable to be of type Real, or try to coerce the value with Inf.Int or Int(Inf). at <tmp>:1 ------> m… |
||
lizmat | m: my Int $a = val("Inf").Num | 15:54 | |
camelia | Type check failed in assignment to $a; expected Int but got Num (Inf) in block <unit> at <tmp> line 1 |
||
lizmat | so the sorry is not creating a panic? | ||
ab5tract | yup, that's the distinction there | ||
nope, the sorry is just never thrown and it is caught later on | 15:55 | ||
lizmat | ah... hmm | ||
ab5tract | and the tests are checking the specific syntax error class, so those fail | 15:58 | |
something about github.com/ab5tract/rakudo/blob/2d...kumod#L736 | 16:00 | ||
but.. | |||
m: dd NaN ~~ Numeric | |||
camelia | Bool::True | ||
ab5tract | actually, $vartype there should be set to Int, IIUC | 16:15 | |
ugexe | main indeed has a green CI again | 17:18 | |
lizmat | ah, looks like Github is not delivering webhooks atm | 17:52 | |
18:00
reportable6 left,
reportable6 joined
|
|||
ab5tract | lizmat: my PR is fixed. now +4 to spectest :) | 18:05 | |
lizmat | whee! | ||
ab5tract++ | |||
so ready to merge ? | |||
18:06
Geth left,
Geth joined
|
|||
Geth | rakudo/main: c21f4b6b40 | (Elizabeth Mattijsen)++ | src/Raku/ast/operator-properties.rakumod Add reserved operator knowledge to OperatotProperties - is-reserved-operator return whether given op name is reserved - reserved-operator-hint return hint for reserved operator name |
18:20 | |
rakudo/main: ceb3d4078c | (Elizabeth Mattijsen)++ | src/Raku/Actions.nqp RakuAST: add ::Action.OperatorProperties to be able to access the OperatorProperties class in the grammar. At least for now, until we have a better solution |
|||
lizmat | wow, about 30 minutes delay | ||
ab5tract | yeah, it should be ready to merge | 18:28 | |
I assume nine is okay with the use of the resolver to grab Numeric | 18:30 | ||
lizmat | yeah, that should be ok: if you have a resolver handy, why not use it? | 18:31 | |
I've merged, but it seems Github has a 30 minute delay in delivering webhooks atm | |||
so it will be a while before you see it here | |||
on Twitter: "We’ve mitigated the issue causing Webhooks latency and are monitoring processing of the backlog of queued requests." | 18:33 | ||
942 +4 :-) | 18:40 | ||
Geth | rakudo/main: 978e2d7898 | ab5tract++ (committed using GitHub Web editor) | 4 files RakuAST: Fix various Role issues This allows statements like `role R {}; my R $r = 42` to fail at run-time, as expected. Fixes the following code: role R { has $.n } class C does R { has R $.r .= new(:$!n) } my C $c .= new(:n(1)); dd $c.r.n |
18:46 | |
lizmat | only 15 minutes delay :-) | ||
ab5tract | it seems you squash merged it. I was being very careful with the commits, as there were things like adding :ver<>:auth<>:api<> along the way | 18:55 | |
stuff that was mostly orthogonal to roles in the specific case | 18:56 | ||
lizmat | sorry want me to revert and merge again? | ||
ab5tract | no big deal | 18:57 | |
lizmat | sorry again :-( | 18:58 | |
ab5tract | I don't know if it's worth rewriting history over :) | ||
it's all good. next time! | |||
lizmat | ok, will keep in mind (hopefully) | 18:59 | |
ab5tract | I'll try to remember to mention it, as well | ||
well, on second thought.. how big a deal would it be to revert and merge again? | 19:00 | ||
lizmat | not very | ||
ab5tract | if it's not a mega hassle, I think future code writers might appreciate it | ||
Geth | rakudo/revert-5366-fix-roles-basic: 96b84ac43b | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | 4 files Revert "RakuAST: Fix various Role issues" This reverts commit 978e2d789870885b8b37ec4da4f6808fe900be7a. |
||
rakudo: lizmat++ created pull request #5367: Revert "RakuAST: Fix t/spec/S14-roles/basic.t " |
19:01 | ||
lizmat | hmmm.. that was not what I was going for :-( | ||
ok, much more complicated than I thought :-( | 19:02 | ||
ab5tract | then: next time :) | 19:03 | |
19:06
linkable6 left,
evalable6 left
19:08
linkable6 joined
19:09
evalable6 joined
19:22
melezhik joined
|
|||
gfldex | m: &fail andthen :continue; | 19:25 | |
camelia | WARNINGS for <tmp>: Useless use of ":continue" in sink context (line 1) |
||
gfldex | m: quietly &fail andthen :continue; | ||
camelia | WARNINGS for <tmp>: Useless use of ":continue" in sink context (line 1) |
||
19:28
melezhik left
|
|||
ab5tract | gfldex: it doesn't give that warning with RAKUDO_RAKUAST=1 .. bug or feature? | 19:32 | |
gfldex | I would say that is a bug. | 19:33 | |
We got those sink context warnings for a reason. | |||
ab5tract | indeed | ||
but atm it doesn't have a single complaint about your poetry | 19:34 | ||
gfldex | As I understand it, those sink context warnings where put into place to indicate precedence mistakes with chaind infix operators. | 19:38 | |
So they also may be LTA. | 19:39 | ||
vrurg | ugexe: do we have a semi-legal way of pulling out particular dependencies from a precompilation? | 20:00 | |
ugexe | i dont believe so. i'm not sure it could even know its dependencies since they could potentially not even come about until runtime | 20:08 | |
i guess if it was possible to get at its $?DISTRIBUTION object you could sort of do it that way, but i don't think thats quite what you're looking for | 20:10 | ||
vrurg | Nah... I would be happy to get just those which are known at the compile time. | 20:15 | |
After all, the bytecode loaders knows them anyway. | |||
ugexe | if they know it would be because the sha1 is known, but sha1 is only one direction | 20:16 | |
so im not sure it can be determined | |||
vrurg | Makes sense. OK then. | 20:17 | |
It was my last hope to try optimizing app compilation time. Full precomp with all the dependencies takes ~16mins. | 20:18 | ||
ugexe | oh maybe they can be, although i dunno if its legal | 20:19 | |
D2351607845CB3DBE195C57B659CE263038AECDEsite#sources/D2351607845CB3DBE195C57B659CE263038AECDE15C262EC5123519E9ADFF092316637FAFBDD9744CompUnit::DependencySpecification.new(:short-name<Zef::Identity>,:version-matcher<0.19.0>,:auth-matcher<github:ugexe>,:api-matcher<0>) | |||
stuff like that is in the repo files | |||
so maybe just naively parse out the CompUnit::DependencySpecification | 20:20 | ||
i think the parts are \0 separated | |||
vrurg | They are. Hm, at first I hoped to avoid that, but why not, after all? | 20:22 | |
Thanks! | 20:23 | ||
ugexe | i wonder if it makes sense to have some sort of api to do it | 20:24 | |
vrurg | I think it does. Xliff would most certainly be happy about it. It seems like me too now. ;) | 20:26 | |
ugexe | for instance with RakuAST i wonder if the same functionality could be done on source code | ||
so then all Repository objects could have some dependencies-for-spec(...) or some such | 20:27 | ||
the precomp repository objects would have the same method, except it would determine them by e.g. reading and parsing that file | |||
that should hide most implementation details | 20:28 | ||
vrurg | Sounds like a plan to me. RakuAST may not know all the compile-time dependecies because some might occur in BEGIN phasers via, say, `require`. But then they are available before precomp is produced. | 20:33 | |
ugexe | m: say CompUnit::PrecompilationDependency::File.deserialize("BF820EA236973A1CB5A7F26B2F7AA2FAA9F9BA0A\0site#sources/BF820EA236973A1CB5A7F26B2F7AA2FAA9F9BA0A\0837991E401FD609CA0F33912991916EF0B2FF465\0CompUnit::DependencySpecification.new(:short-name<XXX>,:version-matcher<0.1.0>,:auth-matcher<github:ugexe>,:api-matcher<0>)").spec | 20:41 | |
camelia | CompUnit::DependencySpecification.new(:short-name<XXX>,:version-matcher<0.1.0>,:auth-matcher<github:ugexe>,:api-matcher<0>) | ||
ugexe | so that method can parse the precomp dependency lines | 20:42 | |
its still doing an EVAL though :/ | |||
vrurg | And this is what I call 'semi-legal'. :) It would be preferable to have just keys alone in the precomp. I was even considering using JSON at some point. But that's too much for the task. | 20:45 | |
22:23
statisfiable6 left,
evalable6 left,
tellable6 left,
nativecallable6 left,
greppable6 left,
reportable6 left,
sourceable6 left,
committable6 left,
shareable6 left,
releasable6 left,
coverable6 left,
bisectable6 left,
squashable6 left,
unicodable6 left,
benchable6 left,
linkable6 left,
notable6 left,
bloatable6 left,
quotable6 left
22:24
linkable6 joined,
bisectable6 joined,
squashable6 joined,
shareable6 joined,
evalable6 joined,
unicodable6 joined
22:25
coverable6 joined,
reportable6 joined,
quotable6 joined,
notable6 joined,
committable6 joined,
greppable6 joined,
sourceable6 joined
22:26
nativecallable6 joined,
bloatable6 joined,
benchable6 joined,
statisfiable6 joined,
releasable6 joined
22:27
tellable6 joined
22:53
Altai-man left
23:55
japhb left
|