|
🦋 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
00:02
reportable6 joined
00:33
epony left
01:21
epony joined
05:15
squashable6 left
05:17
squashable6 joined
06:00
reportable6 left
06:01
reportable6 joined
08:37
greppable6 left,
unicodable6 left,
notable6 left,
nativecallable6 left,
linkable6 left,
evalable6 left,
coverable6 left,
squashable6 left,
statisfiable6 left,
tellable6 left,
releasable6 left,
bloatable6 left,
quotable6 left,
sourceable6 left,
shareable6 left,
reportable6 left,
committable6 left,
bisectable6 left,
benchable6 left,
coverable6 joined,
notable6 joined
08:38
unicodable6 joined,
evalable6 joined,
sourceable6 joined
08:39
nativecallable6 joined,
committable6 joined,
shareable6 joined,
benchable6 joined
08:40
releasable6 joined,
bisectable6 joined,
quotable6 joined,
linkable6 joined,
bloatable6 joined,
greppable6 joined,
reportable6 joined,
statisfiable6 joined,
tellable6 joined,
squashable6 joined
08:58
sena_kun joined
|
|||
| Geth | rakudo/main: dc452c57c0 | (Elizabeth Mattijsen)++ | src/Raku/ast/call.rakumod Remove RakuAST::Call::Method.shortname Replace by .canonicalize, as per nine++ suggestion |
10:04 | |
|
10:16
sena_kun left
10:55
sena_kun joined
|
|||
| Geth | rakudo/main: 0354c47892 | (Elizabeth Mattijsen)++ | src/core.c/RakuAST/Deparse.pm6 Simplify circumfixing in deparsing Also add a missing () in an error message |
11:10 | |
|
11:52
epony left
|
|||
| lizmat | nine: should semilists be deparsed with ; as delimiter, or as , ? | 11:58 | |
| nine | I'm not sure I understand Raku well enough to answer that :D | 11:59 | |
|
12:00
reportable6 left,
reportable6 joined
|
|||
| lizmat | basically the difference between: | 12:04 | |
| m: my @a = <a b c d>; say Q/@a[0,1]/.AST.dump | |||
| camelia | CompUnit 𝄞 /home/camelia/EVAL_0:1 ⎡@a[0,1]⎤ StatementList 𝄞 /home/camelia/EVAL_0:1 ⎡@a[0,1]⎤ Statement::Expression ▪𝄞 /home/camelia/EVAL_0:1 ⎡@a[0,1]⎤ ApplyPostfix ⎡[0,1]⎤ Var::Lexical ⎡@a⎤… |
||
| lizmat | and: | ||
| my @a = <a b c d>; say Q/@a[0;1]/.AST.dump | |||
| m: my @a = <a b c d>; say Q/@a[0;1]/.AST.dumpa | |||
| camelia | No such method 'dumpa' for invocant of type 'RakuAST::CompUnit'. Did you mean any of these: 'DUMP', 'dump'? in block <unit> at <tmp> line 1 |
||
| lizmat | m: my @a = <a b c d>; say Q/@a[0;1]/.AST.dump | ||
| camelia | CompUnit 𝄞 /home/camelia/EVAL_0:1 ⎡@a[0;1]⎤ StatementList 𝄞 /home/camelia/EVAL_0:1 ⎡@a[0;1]⎤ Statement::Expression ▪𝄞 /home/camelia/EVAL_0:1 ⎡@a[0;1]⎤ ApplyPostfix ⎡[0;1]⎤ Var::Lexical ⎡@a⎤… |
||
| lizmat | I think one of the tests is set up incorrectly... | 12:06 | |
| glad I have the .AST method now... :-) | |||
| Nemokosch | what does it do? | 12:33 | |
| lizmat | it parses the given string using the new Raku grammar, and returns the produced RakuAST nodes | 12:36 | |
| Nemokosch | oh, and deparse takes this a step further by providing a Raku source code representation? | 12:38 | |
|
12:38
Altai-man joined
|
|||
| lizmat | yes | 12:38 | |
| m: say Q/my $a = 42/.AST.deparse | 12:39 | ||
| camelia | No such method 'deparse' for invocant of type 'RakuAST::CompUnit'. Did you mean 'DEPARSE'? in block <unit> at <tmp> line 1 |
||
| lizmat | m: say Q/my $a = 42/.AST.DEPARSE | ||
| camelia | my $a = 42 |
||
| lizmat | the leading spaces are a bug | ||
| in the deparsing | |||
| m: say Q/my $a = 42/.AST.dumo | |||
| camelia | No such method 'dumo' for invocant of type 'RakuAST::CompUnit'. Did you mean any of these: 'DUMP', 'dump', 'sum'? in block <unit> at <tmp> line 1 |
||
| lizmat | m: say Q/my $a = 42/.AST.dump | ||
| camelia | CompUnit 𝄞 /home/camelia/EVAL_0:1 ⎡my $a = 42⎤ StatementList 𝄞 /home/camelia/EVAL_0:1 ⎡my $a = 42⎤ Statement::Expression ▪𝄞 /home/camelia/EVAL_0:1 ⎡my $a = 42⎤ VarDeclaration::Simple ⎡$a = … |
||
|
12:42
sena_kun left
13:19
Altai-man left
|
|||
| lizmat | nine: something like "(3,4)" codegens into a SemiList(Statement::Expression(ApplyListInfix(...))) | 13:29 | |
| however, all seems to work without the Statement::Expression step | |||
| aka: SemiList(ApplyListInfix(...)) | |||
| is this an optimization not yet performed on the codegen side, or should I adapt deparsing tests accordingly ? | 13:30 | ||
| nine | No! That's plain wrong. SemiList is a StatementList and the contained statements are required to be RakuAST::Statement subclasses. I have only just fixed a bug where we didn't stick to this rule in commit 8b9fb402b9cbcfaf9762b49e90a74840c06621ef. Let's not introduce more problems like that. | 13:37 | |
| lizmat | ok, so I guess I'll need to fix a few tests :-) | 13:38 | |
| nine I assume an empty SemiList can live without a Statement::Expression in it | 13:45 | ||
| nine | Sure. An empty list is an empty list. It's just that if there is something in it, it must be statements. | 13:46 | |
| lizmat | ack | 13:49 | |
| Geth | rakudo/main: 9aea72f59c | (Elizabeth Mattijsen)++ | 3 files Fix deparsing of SemiLists And adapt tests to use AppltListInfix where applicable |
14:15 | |
| rakudo/main: 8ee5e99bd5 | (Elizabeth Mattijsen)++ | t/12-rakuast/call.rakutest Some more explanations in TAP output |
14:27 | ||
|
14:29
Kaipei left
|
|||
| Geth | rakudo/main: d0916e9a51 | (Stefan Seifert)++ | src/Raku/ast/name.rakumod Implement canonicalization of expression parts in names The canonical form of arbitrary Raku expressions is obviously the deparsed string as parsing+deparsing takes all the possible forms one can spell a Raku expression and turns them into one canonical form. |
15:16 | |
| rakudo/main: dcff39f62d | (Stefan Seifert)++ | src/Raku/Actions.nqp RakuAST: fix failure to resolve &infix:<<whatever>> variables We need to turn such a name into its canonical form before looking it up in surrounding scopes as it will be registered under the canonical name. |
|||
| nine | 89 passing test and 605 passing spectest files | ||
| Nemokosch | nine: is all this something that you just know by heart or is any of this written down anywhere? | 15:42 | |
| nine | Nemokosch: it's just good old fashioned debugging and reasoning. What else but the deparse result could be a canonical form of an expression? And with many different ways to spell the same name, we must standardize on one form if we want to find it in a lookup hash (which is what resolving a name really does) | 15:46 | |
| tellable6 | nine, I'll pass your message to Nemokosch | ||
|
15:52
Kaipei joined
|
|||
| Nemokosch | no, I mean, what a certain source code should correspond to in AST form | 16:04 | |
| because that has been the biggest burden for me for one; not knowing what even is the right interpretation | 16:05 | ||
|
16:23
epony joined
17:04
ab5tract joined
|
|||
| lizmat | nine: wouldn't these references to .DEPARSE fail once we try to build the setting with the Raku grammar ? | 17:08 | |
| ugexe | fyi there appears to have been a regression re: windows and module installation -- github.com/ugexe/zef/issues/491 | 17:59 | |
|
18:00
reportable6 left
18:02
reportable6 joined
|
|||
| ugexe | i dont think this is specific to TAP either. Other people have noted similar issues with their windows github actions that appear to be precomp related | 18:03 | |
| timeline wise the only thing that sticks out is github.com/rakudo/rakudo/commit/71...0453f618b6 but I'm not sure how that change would fail most of the time but succeed rarely | 18:05 | ||
| unless its a race condition with CALLERS.EXISTS-KEY | |||
| it looks like that wasn't in the 2022.12 release though | 18:07 | ||
|
18:35
sena_kun joined
|
|||
| vrurg | The race condition doesn't look as an unlikely cause. | 19:35 | |
| Geth | rakudo/lizmat-unicode-version: 0be7a68d37 | (Elizabeth Mattijsen)++ | 4 files Introduce $?UNICODE-VERSION in 6.e Instead of doing difficult things in MoarVM or JVM, just set the constant in the setting code. Whenever a Unicode update is to be done, updating this constant should be part of the Pull Request. |
19:36 | |
| rakudo: lizmat++ created pull request #5153: Introduce `$?UNICODE-VERSION` in 6.e |
|||
| ugexe | does the jvm even support unicode 15? | 19:52 | |
| 13 rather | |||
| similarly the other backends | 19:53 | ||
| lizmat | well, I don't know... but that could be easily handled by #?if jvm etc | 20:02 | |
|
20:04
sena_kun left,
sena_kun joined,
sena_kun left
20:05
sena_kun joined
|
|||
| Geth | rakudo/lizmat-unicode-version: 484eed9544 | (Elizabeth Mattijsen)++ | src/core.e/core_prologue.pm6 Make $?UNICODE-VERSION check the unicode database As suggested by Stephen Schulze |
20:12 | |
| ugexe | sure, but i was questioning what was there | 20:21 | |
|
20:34
ab5tract left,
ab5tract joined
|
|||
| ugexe | actually im not sure #?if jvm would help for e.g. jvm since it would need to be more like #?if jvm:ver<...> | 20:39 | |
| however, that runtime code looks like it should solve all those problems | 20:40 | ||
|
20:59
epony left
21:00
epony joined
22:18
sena_kun left
22:21
sena_kun joined
|
|||
| nine | lizmat: could be come a problem. But that's then. We'll deal with it somehow. It may just be that the settings code never reaches this case. | 22:27 | |
| lizmat | one can hope :-) | 23:27 | |