🦋 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.
Geth roast: 033efe81bd | (Jimmy Zhuo)++ | S04-declarations/will-complain.t
change block code to string code to test compiling error.
 01:26
roast: 33a4cb3699 | (Jimmy Zhuo)++ | 6.c/S14-roles/mixin-6c.t
Merge branch 'master' of github.com:raku/roast
releasable6 Next release in ≈6 days and ≈15 hours. There are no known blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 03:00
nine lizmat: add-worry only exists on RakuAST::Resolver::Compile 07:54
It wouldn't make sense to have it on RakuAST::Resolver::EVAL. That one always operates with a fully formed tree, so we can simply collect sorries and worries at check time (which is what we do). 07:55
Geth rakudo/main: c13e18b965 | (Stefan Seifert)++ | src/Raku/ast/type.rakumod
RakuAST: always look up GLOBAL at runtime.

We must always look up GLOBAL at runtime. Otherwise we'd e.g. use the setting's GLOBAL in EVAL.
Fixes: EVAL q[our sub eval_born { 5 }]; &OUR::eval_born();		 08:40
nine That's 1121 fully bootstrapped :)
That's as many as we passed back in August 08:42
lizmat nine: that's not true if the tree is created manually 09:38
nine Why not? 09:41
Tree is created, then you run check
It's not like with the parser that only knows that it'll succeed when it has finished and may need to report errors earlier. 09:42
finanalyst lizmat: is it possible to generate the AST of a file, cache it (say as a string), then pull it back? 10:52
I'm thinking of generating and caching the AST of the Raku doc sources. 10:54
lizmat spurt "file.AST", "file".IO.slurp.AST.raku
off of the top of my head :-)
finanalyst is there any hidden problem, say with the serialisation of closures?
nine The better question would be: is there any advantage of doing this? 10:55
lizmat yeah.... I was wondering about that as well :-)
finanalyst I'm wondering about that.
nine There is a serialization format especially made for RakuAST. It's called Raku 10:57
lizmat or RakuDoc :) 10:59
nine Which is part of Raku isn't it?
finanalyst So, the rakudoc sources need parsing to get the AST. But in order to attach information about when a section was last changed, I need to add information. I was thinking to do this on the AST
nine To keep this AST up to date, you'd then have to somehow match the AST nodes generated from parsing the original source again to the nodes you already have. Without stable identifiers, that's gonna be quite hard. 11:01
finanalyst Suppose there is a translated version of a source, which is synchronised to the English original. The original changes, but the translated version hasnt 11:02
nine Instead, I'd just write out the AST back to RAku and attach this information to the generated source code by way of comments or so.
Or special RakuDOC directives that get attached to the things they are covering. 11:03
finanalyst problem is that then the Raku documentation files are 'tainted' with information that is only relevant to rendering them
no need for special directives - meta data can be attached to each block, and that iss sufficient 11:04
nine Well taking a step back, I'd just identify the original English text by the text itself. Either you have a translation for that exact text or you don't. After all, even if there's just a small change in one sentence, translators will have to check whether the meaning is still the same.
That's also how other tools like GNU gettext work. They use the original text as key to look up the translation. 11:05
finanalyst that is true. but when there are hundreds of files, and thousands of sections, it is difficult to identify when a translation needs to be made
nine Why? Either you have a translation for some text or you don't. gettext is used for practically everything in a Linux distro. That's probably millions of text snippets. 11:06
finanalyst problem with original text as key, is that some languages - eg Japanese - do not use English paragraph structure. Mapping is section by section, not sentence by sentence or para by para 11:07
nine In fact, if I wanted to facilitate translation of Raku documentation, I'd just generate the appropriate gettext files. This way translators can use all of those nice tools that are written around that.
finanalyst but gettext is not general enough. 11:08
nine Again, translation of program text and docs is a solved problem. I don't think there's a need to re-invent anything here.
finanalyst nine: I beg to differ 11:09
I may be wrong, but its the corner cases that always cause the problems 11:11
however, the question I asked does seem answered: it is probably not best to cache AST 11:12
nine: a long standing problem with pod/Rakudoc is that there is no Line information in the AST of RakuDoc (parsed version of pod) 11:22
It would help with error reporting to have a line in the source to point to. 11:23
I'd be willing to try to help if I knew where to start
lizmat finanalyst: did you make an issue for that ? 11:26
nine Is that still the case with RakuAST? 11:27
finanalyst Long time ago!!! for Pod and for RakuDoc
nine: yes
recently raised a new issue. If the end of a block is misspelt, the parser gives a NYI error 11:28
But not indication about where it happens
nine Well the obvious fix for that particular problem is to implement that NYI 11:30
finanalyst No need for more granulation than on block start. Since all blocks start with `=BLOCKNAME`, an addition to the AST for a block/directive with something like `line: 200` would be goov 11:31
good
no need to add line data to Markup 11:32
nine AFICT doc-blocks *do* get their origin set.
finanalyst nine: good to know. How to extract that data? 11:33
nine It's just that a plain nqp::die('NYI') doesn't print that information.
Again, the best way to fix this is to get rid of the NYI by just implementing what's missing.
finanalyst What I am seeking is the line when the AST is valid as well 11:34
Geth rakudo/main: c974c64637 | (Stefan Seifert)++ | src/Raku/ast/statements.rakumod
RakuAST: fix while/loop statements when we skip CHECK time

Similar to commit 4a8ee5d22d9745153780bd895dd7125cf034872b
While/until loops need to thunk their expression/inrement, but crucially only if they're not a block statement and they-re not sunk. The problem is that at BEGIN time we don't know that yet. ... (5 more lines)
rakudo/main: 668ee6c188 | (Stefan Seifert)++ | 2 files
RakuAST: ensure role bodies have calculated sink
nine And we're at 1163.
finanalyst nine "now we're at 1163". Qudos! 11:36
nine (which is as many as February this year)
lizmat m: class A { has $!a is required }; dd A.new(:42a) 12:38
camelia The attribute '$!a' is required, but you did not provide a value for it.
in block <unit> at <tmp> line 1
lizmat I'd say that "is required" implies "is built" ? 12:39
m: class A { has $!a is built is required }; dd A.new(:42a)
camelia A.new(a => 42)
Geth rakudo: zhuomingliang++ created pull request #5818:
throw X::Parameter::TypedSlurpy exception		 13:27
[Coke] (ast in docs) - pretty sure we're already doing that in the tests, finanalyst. 15:12
github.com/Raku/doc/blob/875ded7c4...t#L99-L105 ? 15:16
Geth rakudo/main: 518596b47e | (Jimmy Zhuo)++ (committed using GitHub Web editor) | src/Raku/ast/signature.rakumod
throw X::Parameter::TypedSlurpy exception, pass two test in t/spec/S06-signature/slurpy-params.t (#5818)
 16:20
rakudo/main: 242f69bfaa | (Elizabeth Mattijsen)++ | src/Raku/ast/scoping.rakumod
RakuAST: make unresolved error a bit more informative

If it's about types not yet having been resolved		 16:50
rakudo/main: 7566dd3b6d | (Stefan Seifert)++ | src/Raku/ast/call.rakumod
RakuAST: complain about unqualified private method calls outside classes/roles
 17:01
rakudo/main: a7717ce987 | (Stefan Seifert)++ | src/Raku/ast/call.rakumod
RakuAST: use dispatcher for non-compile-time-resolved private method calls
nine 1164 17:03
A bit of a disappointment after those large strides
lizmat only 115 to go to achieve parity with non-bootstrapped, I'd say that's pretty good! 17:04
nine And despite that one it's probably not that many fixes required 17:05
And they are not as hard to find as I had feared
Geth rakudo/main: 51d403a518 | (Elizabeth Mattijsen)++ | src/core.c/RakuAST/Deparse.rakumod
RakuAST: fix deparsing of traits with arguments
 17:17
Geth rakudo/main: 004c6521a7 | (Stefan Seifert)++ | src/Raku/ast/code.rakumod
RakuAST: fix implicit %_ getting shadowed in nested blocks in methods

Fixes: my method foo() { if True { dd %_ } }(Any, :a)		 18:21
nine 1172 fully bootstrapped
nine m: Hash.^parameterize(Mu, 1) 21:00
camelia Can not parameterize Hash with 1
in block <unit> at <tmp> line 1
nine but:
m: Hash.^parameterize(1, Mu)
camelia ( no output )
nine m: say Hash.^parameterize(1, Mu)
camelia Can not parameterize Hash with 1
nine Someone forgot a die :)
Ah, I should have posted: 21:01
m: say Hash.^parameterize(1, Mu).^name
camelia Str
Geth rakudo/main: 49c110f45a | (Stefan Seifert)++ | src/Raku/ast/package.rakumod
RakuAST: fix stubbed role groups with multi part names not re-used

Fixes: use nqp; role Foo::Bar { ... }; sub is-foo(\x) { say nqp::istype(x, Foo::Bar); }; role Foo::Bar { }; is-foo(1 but Foo::Bar)		 22:17
nine Up to 1185
I'm quite surprised this has stayed hidden for so long 22:18
releasable6 Next release in ≈5 days and ≈19 hours. There are no known blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 23:00

Powered by Cro and the Raku® Programming Language.

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

Thank you!