🦋 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.
[Coke] jdv: I think it was much smoother, yes 01:28
02:23 guifa left
jdv [Coke]: coolio 03:52
04:50 guifa joined 05:54 dev2 joined
dev2 happer Easter 05:55
05:57 guifa left
dev2 as I understand, the grammar parser is implemented using continuations, so if you want to backtrack from the method EXPR(), is there a special method to call on the self object? 05:57
07:23 bartolin left 07:35 finanalyst joined
nine dev2: you know, looking through git log, you might be right about the history. The parsing behavior was indeed there before that message 08:00
dev2 music to my ears :P 08:08
in Perl6/Grammar.nqp, in token infix:sym<?? !!> EXPR is called with <EXPR('i=')> 08:10
I wonder why someone felt the need to put a precedence limit here. It's useful when we want to parse lists or argument list using the recursive descent parser, 08:13
for handling things like trailing commas, but in the ternary it's gratuitous, unless the point is to make Raku behaves like Perl, for no real good reason. 08:14
nine When faced with such questions, I often just change the code, build and run spectests and see what breaks. That usually gives me the answer :) 08:27
dev2 logging off. i'm going to try later to remove 'i=' and hope it works.. 09:20
09:20 dev2 left 09:27 finanalyst left
patrickb I have just uploaded the compiled release files for 2025.04. 10:08
10:13 finanalyst joined 11:02 JimmyZhuo joined 11:18 finanalyst left 11:20 JimmyZhuo left
ab5tract "unless the point is to make Raku behaves like Perl, for no real good reason." -- There's a few corners of Raku where this is indeed the reason for things being as they are 11:29
11:38 finanalyst joined
ab5tract dev2: at first glance this does seem to work as expected. There are some 6 spectest files failing though 11:53
tellable6 ab5tract, I'll pass your message to dev2
ab5tract wait... four of those files are marked failures because of TODOs passing :) 11:55
anyway, not sure what is going on with most of those, as they appear unrelated 12:06
one side effect of going with this approach is that now adverbs can be used in the ternary's sub-expressions without issue or parentheses 12:07
which is what 2 out of 3 tests in `t/spec/S03-operators/ternary.t`were checking for (that adverbs would explode) 12:09
ab5tract switches over to poking at RakuAST tickets 12:16
nine: regarding R#5853, is the solution to just add a $_ in the outermost scope of the QAST "preamble" (not sure what we call that) 12:20
linkable6 R#5853 [open]: github.com/rakudo/rakudo/issues/5853 [RAKUDO_RAKUAST=1] EVAL in a constant stumbling over missing outer $_
13:16 dev2 joined
dev2 ab5tract: that's a bit unfortunate... outside of ternary.t, what specs are failing? 13:23
tellable6 2025-04-20T11:53:48Z #raku-dev <ab5tract> dev2: at first glance this does seem to work as expected. There are some 6 spectest files failing though
dev2 here comes that sauce
I made the change <EXPR('i=')> to <EXPR> in Perl6/Grammar.nqp and Raku/Grammar.nqp, Idk which one is actually runs. make test didn't report any error. I ran specifically t/spec/S03-operators/ternary.t and got 3 errors. All of them are bullshit tests.
the 1st one is directly verifying that you can't put a low precedence operator in the ternary. the 2nd and 3rd verify the same thing but with an adverb
RT66840 (comment on 1st failing test) contains a little discussion about this ternary issue. the S03 spec is mentioned and the spec itself says that you can't put a low precedence in the ternary. But this statement is bullshit It only means that someone did his homework, did precedence tests, found this edge case, had 0 critical thoughts and perpetrated Perl5's mistake. mindless parrotting.
in the issue thread some dude agrees that it's stupid and that the middle of the ternary should be treated like parentheses, but he says that the only way to make this happen is to give the lowest precedence to that ternary. he's wrong about this, you don't need to change the precedence to parse it correctly 13:24
ab5tract the other relevant failures are in S03-operators/precedence.t 13:25
Haven't looked closely
I personally agree with making this change, but I find your assessment of the history of this behavior is unnecessarily uncharitable 13:26
"Keeping the same behavior as Perl 5" doesn't equal braindead parroting 13:27
Keep in mind also that what Raku can do now is often a great deal more than what it could do historically, depending on how far back in the timeline we go 13:30
13:43 guifa joined 13:55 finanalyst left
dev2 well, ummm.. You are entirely right I am. The thing is programming language matters *immensely* and I'm absolutely sick of seeing bad decisions everywhere that affect so much, and that must not be improved. I mean, I knew that I sounded like an asshole, but if we're not honnest, self-censore ourselves and don't try to improve things, what's the point... 14:08
*programming languageS in general 14:09
ab5tract I'm pretty sure everyone so far has been on board with exploring changing the handling of ternaries, so at least the "must not be improved" isn't happening here 14:15
I agree with what you've said, except: being polite and communicating with minimal aggression don't count as self-censorship in my book. 14:17
I'm not innocent when it comes to this either, mind you. 14:18
nine: Where does the RakuAST bootstrap get, erm, strapped? 14:45
dev2 nice to hear it, raku is supposed to take extreme care in its operators... 15:05
15:23 guifa left
jdv patrickb: thanks 15:35
15:41 dev2 left 16:13 [Coke] left 16:53 finanalyst joined 17:55 finanalyst left 18:08 [Coke] joined
[Coke] I assume we don't need a point release of all three, just for MoarVM? 18:13
If we need to rollback mimalloc, I created a 2025.04.1 branch for that in MoarVM 18:20
timo oh shit what's wrong with mimalloc? 18:30
i see it now 18:31
we don't have to rollback mimalloc, since we're distributing a copy of it ourselves anyway, we can patch it to resolve the build issue and still have a newer mimalloc 18:53
[Coke] ok. 18:59
if you do so on main I can cherry pick 19:00
timo submodules make it a little trickier of course 19:04
oh we don't have a fork of our own, huh. 19:05
[Coke] (or on the branch is fine) 19:10
timo we would first have to push a new repository onto github for this if we wanted to just "add" a change 19:11
i don't seem to have the permissions to fork mimalloc into the moarvm org, but it doesn't have to be under moarvm/ technically, it could go under raku as well 19:12
how does that sound to you? maybe just for the release ... 19:15
20:11 guifa joined
timo it's always annoying to switch forks in a submodule, but i think Configure.pl makes sure the submodules are synced, so let's hope it's not so bad 20:27
i'll do all this in a branch of course
[Coke] thanks 20:32
timo there may be a viable commit that we can just take from the original repo, it's just in the dev branch and not main 20:39
20:39 finanalyst joined 20:42 guifa left
timo this submodule is feeling super weird 20:45
oh, was it the rename of the master branch to main that did something odd?
20:45 guifa joined
timo [Coke]: there's a branch in moarvm's repo that should fix the issue 20:59
nine ab5tract: what do you mean with RakuAST bootstrap? 21:00
ab5tract > This comes from trying to find the outer scope's $_ which doesn't exist in the RakuAST code in the bootstrap:
nine Ah. The RakuAST code lives in the bootstrap 21:01
ab5tract ahhh 21:02
nine See gen/moar/BOOTSTRAP/v6c.nqp
ab5tract right, got it
nine The bad news is that I have already tried the simple thing of just adding a my $_; to the method that calls EVAL. That was after all less work than writing an issue 21:03
[Coke] timo: thanks. will do the (moarvm only) point release by EOD 21:05
timo a user who is hit by that bug could also compile their moarvm with --has-mimalloc and use a system-provided one, of course
but as i mention in the commit message, as more distros go past the version of the linux headers that have this change, they will also become unable to compile this verson of moarvm without that flag 21:06
not sure if the version of mimalloc we had before just didn't use prctl.h at all?
21:32 finanalyst left
[Coke] I'll hold off until el_che confirms this fixes their issue 23:31

Powered by Cro and the Raku® Programming Language.

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

Thank you!