🦋 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
MasterDuke what's the best way to pass information from parse time (i.e., Grammar.nqp) to AST time? 00:41
vrurg MasterDuke: Into Actions? 00:56
MasterDuke into src/Raku/ast/*.rakumod
dynamic variable seems like it might work, testing that now 00:57
vrurg MasterDuke: mostly it's about dynamics, yes. 00:58
01:30 nine left, nine joined 01:53 frost joined 01:54 frost left 01:57 frost joined 02:17 frost left 06:00 reportable6 left 06:01 reportable6 joined
releasable6 Next release in ≈2 days and ≈11 hours. 1 blocker. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 07:00
07:00 samcv left 07:35 RakuIRCLogger joined
Nemokosch perhaps it would be time for a RakuAST label in the Rakudo repo, or even two 07:37
for things that are meant to be fixed there, and for things that are fixed there
Geth rakudo/main: 5d1d02d958 | (Stefan Seifert)++ | 8 files
RakuAST: adapt tests for new VarDeclaration::Simple.new signature
lizmat nine: why not add a "name" argument to VarDeclaration::Simple of which parts could serve as the defaults for sigil twigil desigilname ? 08:27
Nemokosch that's the way that has been changed
nine I thought about that. But we don't do that anywhere else either.
The way it's now, we no longer need to parse something that has already been parsed and then stitched back together 08:28
lizmat true, but it makes it the interface harder for manual building 08:29
and adding a :$name and checking whether it is defined, and then only do extra stuff, doesn't feel like a lot of extra effort 08:30
so I feel very much like reverting the test changes, and adding a :$name argument
and "name" method
unless you are vehemently against it 08:31
Nemokosch there are already a RakuAST class development and RAKUDO_RAKUAST=1 label 08:35
nine Not sure about vehemently, but I don't like it. If it had been like it's now from the start we wouldn't have this discussion. It's just that the patch for adjusting the tests shows that there's an alternative that saves some typing. Honestly, I don't think it's worth it.
lizmat not worth me spending time on it, or not worth it from an API point of view ? 08:36
nine Not worth the complication. Consider the reason for the change in the first place: we need an actual RakuAST::Name for desigilname because it can have multiple parts.
If you do what you suggested and just parse $name into the three parts and do it naively, you'd use RakuAST::Name.from-identifier as we now do in the tests. But that would be wrong! 08:37
Geth nqp/main: a124861a37 | (Jonathan Worthington)++ (committed using GitHub Web editor) | src/QRegex/Cursor.nqp
Fix back-references when there are aliases

Aliases are named-mangled on the capture name into a string of the form
  `foo=bar`. This is handled in the match object construction, but was not
handled in the back-reference code.
lizmat ah, ok, good point
nine Someone could call the constructor with :name<$A::B::c> and you'd get the wrong desigilname
Nemokosch not sure we mean the same thing. I'm thinking of labeling the issues like "this has been already fixed with the RakuAST frontend" or "this should be addressed with the RakuAST frontend only"
lizmat nine: understood, I withdraw my objections :-) 08:40
Geth nqp/main: 30bb2a1aeb | (Elizabeth Mattijsen)++ | tools/templates/MOAR_REVISION
Bump MoarVM

To get better error handling on some Linux distributions
rakudo/main: 8826b839c3 | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION
Bump NQP

  - get better error reporting on some Linux distributions
  - get back-reference check in regexes
Nemokosch oh, one more thing: most ("old") Rakudo PR's point to master. That may cause trouble later on 09:24
lizmat fortunately Github has a way of rebasing them, although I would have to look up again to find out how 09:37
Geth rakudo/main: 7b4b680e3e | (Elizabeth Mattijsen)++ | 3 files
RakuAST: deparse/.raku/test for RakuAST::Statement::Import
roast: 7fad7bed8f | (Elizabeth Mattijsen)++ | S05-metasyntax/regex.t
Add tests for #5248
10:01 evalable6 left 10:04 evalable6 joined 10:16 frost joined 10:32 frost left 11:32 statisfiable6 left, sourceable6 left, greppable6 left, bisectable6 left, releasable6 left, nativecallable6 left, bloatable6 left, unicodable6 left, benchable6 left, committable6 left, shareable6 left, quotable6 left, coverable6 left, reportable6 left, notable6 left, tellable6 left, evalable6 left, squashable6 left, linkable6 left 11:33 tellable6 joined, nativecallable6 joined, nine left, nine joined, unicodable6 joined, greppable6 joined, committable6 joined 11:34 linkable6 joined, quotable6 joined, benchable6 joined, notable6 joined, squashable6 joined, statisfiable6 joined 11:35 sourceable6 joined, coverable6 joined, shareable6 joined, bloatable6 joined, releasable6 joined, bisectable6 joined, reportable6 joined, evalable6 joined 12:00 reportable6 left 12:01 reportable6 joined 12:23 nebuchadnezzar joined
[Coke] (main vs. master) there is an option to do that when you do the cutover, which I did for the docs repos. 13:01
I don't see an option in the settings for rakudo/rakudo to do anything with the current PRs. 13:02
Nor do I see a button on, e.g. github.com/rakudo/rakudo/pull/2680 13:03
but worst case, these can be merged via the command line 13:04
OH. Click edit, and it's just the title but also the target branch is editable. 13:05
so, only 64 PRs to edit, I can do that. 13:06
(not right this second)
*not* just the title.. 13:08
lizmat I would skip the ones marked "Draft" 13:09
and the ones that already have conflicts 13:10
[Coke] ok. It's 3easy enough to do, and we'll never want to merge them to master, so I may just do them anyway if there's no harm. 13:11
(can't search by conflicted, but can add "draft:false") 13:12
(similar setup on raku/nqp) 13:14
jdv: when master->main happens on moarvm, do you want that just before or after the release? 13:22
nqp PRs all updated. 13:42
lizmat [Coke]++ 13:48
14:09 japhb left 14:11 japhb joined 14:13 ab5tract joined
Geth rakudo/main: 3b838eafb9 | (Elizabeth Mattijsen)++ | 3 files
RakuST: fixup some deparsing / tests for Doc::Formatted
[Coke] is surprised to find an old PR submitted by... himself 15:31
lizmat: github.com/rakudo/rakudo/pull/1016 - you said you were closing it, but didn't. 15:39
jdv after is probably easier 16:05
16:22 japhb left 16:26 japhb joined
[Coke] let's pick a day now after the release and the weekly, announce it's coming on the weekly, and we can press the button then. 16:28
Folks: Going through all the PRs just now to make sure they were pointing at main, I saw a lot of proposals from over a year ago that didn't get any traction: if you have something submitted that you don't want any more, consider withdrawing it or pinging here for next steps. 16:33
I have one for a new env var that hides line numbers in test output, and honestly, I don't remember why I thought I needed it, so I'll probably drop that one, for example.
github.com/rakudo/rakudo/pull/3989 16:35
jdv what are you changing? 16:37
[Coke] in that PR, or in moarvm's repo? 16:50
I updated the PRs in npq & rakudo so that if they're merged, they go to main, not the old master. 16:51
in that last PR, it's stale, closing it.
in moarvm, we'll do the cutover from master to main, finally
jdv in terms of branch changes 16:53
[Coke] just that last one, then 16:55
same change already done to nqp & rakudo
jdv ok 16:56
[Coke] ugexe, masterduke, anything I can do to help test or move github.com/MoarVM/MoarVM/pull/1745 forward? 16:59
nine If there is one thing in Raku that I would remove immediately given the chance, it's the global stash hierarchy. 17:03
17:13 ab5tract left 18:00 reportable6 left 18:03 reportable6 joined 18:30 sena_kun left 18:31 sena_kun joined 19:27 ab5tract joined
ugexe [Coke]: i'm not quite sure the best way to move forward there. on one hand Raku needs to properly parse (so it can create proper paths for .relative, .absolute, etc) the UNC and device path types ( like gist.github.com/ugexe/cadebd4e3e47...ku-L60-L66 ). then raku needs an implementation detail method for turning a path with e.g. path part longer than 255 19:53
into the device path format (like \\.\C:\my\foo\bar). internally raku should use that routine to convert paths internally (at first anyway, later it could apply to all path operations but would need performance considerations) before passing them to moarvm
moarvm would need some minor changes, but I think for most things the rakudo changes should be sufficient
19:54 ab5tract left
[Coke] Do we want Raku to be aware of the \\path or is that an implementation detail for moarvm? 19:57
ugexe yeah Raku needs to parse it correctly. right now it doesn't 20:01
if it can't parse it correctly then it can't determine how to put it back together in a different path format 20:02
or if it needs to be a different format at all
for instance: `say q|\\\\.\\C:\\foo\\bar\\baz.txt|.IO.absolute` will output something like C:\C:\foo\bar\baz.txt which is wrong because A) its not using the original device path style \\.\ and B) it adds the volume twice 20:16
[Coke] ... ah, bother. OK 20:22
20:50 japhb left 20:54 japhb joined
Geth rakudo/main: 62d263fcc2 | (Stefan Seifert)++ | src/Raku/ast/scoping.rakumod
RakuAST: throw an error when trying to redeclare an our scoped package
vrurg nine: If I get you right then you have my full support on this. 21:28
nine vrurg: I wonder how realistic that dream actually is :) 21:34
I mean, all the setting classes are visible lexically anyway. When you use a module, the symbols are imported lexically as well as far as that global stash hierarchy allows. 21:35
vrurg The first problem I see is run time `require`. Where should it install symbols not known at compile time? 21:36
nine That problem actually exists already. It stores them in a hash in the current scope.
vrurg (facepalm) Of course! 21:37
Perhaps we can target this in 6.f.
nine It would mean that this would break:
m: { my class Int::Special { } }; Int::Special.new
camelia ( no output )
nine And rightfully so, I dare say :D 21:38
vrurg In my current project I had to switch to using `role Foo {}; my class Foo::Something does Foo {}` due to this stupidity.
So, it has to break. 21:39
21:39 sena_kun left
ugexe [Coke]: i think most of the parsing work can be done by the grammar in my gist. it just needs to be integrated into IO::Spec::Win32 (and ideally changed to not use a grammar, but other parts of IO::Spec use a grammar so maybe not that bad) 21:56