🦋 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:17 kjp joined 00:21 kjp left, kjp joined 07:46 sourceable6 left, sourceable6 joined
lizmat notable6: weekly 09:38
meh
09:54 notable6 left, notable6 joined
lizmat notable6: weekly 09:54
meh 10:05
10:44 rakkable joined 10:53 coverable6 left, coverable6 joined
lizmat nine: question: in RakuAST: if we create an AST of the Raku source (e.g. from a module file), should an .EVAL on that AST always work and produce the same result as compiling the source? 11:18
notable6: weekly 11:21
nine So it would be source -parse-> AST -EVAL-> result? 11:23
lizmat basically: raku lib/Foo.rakumod and raku -e '"lib/Foo.rakumod".IO.slurp.AST.EVAL' 11:25
or perhaps better: 11:26
basically: raku lib/Foo.rakumod and raku -e '"lib/Foo.rakumod".IO.slurp.AST.raku.EVAL.EVAL'
to more simulate building an AST synthetically
nine Well presumably .AST just runs the normal compiler with --target=ast while EVAL takes that ast and runs the compiler with --from=ast, so really it's just an interruption of the normal compilation process 11:27
lizmat I was more thinking along CHECK { say $*CU; exit } as the --target 11:28
but yeah
it feels to me we should be able to guarantee that, otherwise macro handling will become very error prone indeed ? 11:31
nine You mean serializing the AST as Raku source code? 11:36
lizmat the AST.raku creates a string representation of the AST, EVALling that would create the RakuAST tree synthetically, and the subsequent EVAL would turn it into bytecode 11:37
well, something executable
nine How is that related to macros? 11:38
lizmat it's related in the sense that a macro could create a RakuAST tree synthetically, which would then get inserted into the outer RakuAST 11:39
nine That usually doesn't involve serializing any AST
lizmat however, as we've seen yesterday, a synthetically created role would probably not work :-(
nine not right now 11:40
lizmat so my question would be: do we agree it should ?
because I was not clear on that yesterday
*your position on that
nine I think it would be useful to create role ASTs synthetically.
No serialization needed for that :) 11:41
useful to be a able to create
lizmat but not to serialize, is what you're saying?
fwiw, the L10N logic depends on that atm 11:42
nine No, I'm saying that I have no idea what serialization has to do with it. It's completely orthogonal
lizmat so you're saying that the current approach to synthetically create a role in the L10N logic (to create a L10N::NL module e.g.) should work 11:43
nine I have not reviewed that logic 11:45
lizmat well, that's why I asked the question more generally, so you wouldn't have to :-)
notable6: weekly 12:39
And yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2025/06/16/2025-...-codified/ 12:53
13:24 [Coke] joined
[Coke] 's mac mini apparently just needed to be rebooted a few times 13:26
I have it plugged into the UPS, AND we have a generator. It never should have been impacted by the (&#@$ power outage.)
lizmat [Coke]: welcome back! 13:29
Geth rakudo/main: 1d69f5a70b | (Elizabeth Mattijsen)++ | lib/RakuAST/L10N.rakumod
RakuAST: fix bitrotted L10N support

Roles need to be created with RoleBody objects, at least atm		 14:17
14:26 notable6 left 14:29 releasable6 left, releasable6 joined
[Coke] I am late on this because of my power outage, but, following up on a joke from a week ago saturday... "hey, nine: How are you feeling?" 14:36
(setup was nine saying "ask me in a week")
timo well, i'm coughing. i think i'm carrying forward nine's feeling in spirit 14:41
nine Unfortunately that sounds very much like it 15:03
Pro tip: keep it at one infection. That will at least go away in a reasonable time frame
Though I'm happy to report that yesterday I switched from minute long coughing fits to "just" coughing. A welcome improvement. 15:04
lizmat: I guess a check in RakuAST::Role would be nice to ensure that $.body is a RakuAST::RoleBody. That would defuse this trap. 15:10
[Coke] Thankfully I don't seem to have that, only a very mild case of pollen allergies. 15:31
(and I was around a few hundred unmasked people saturday)
timo > next. core summit? out of the door, line on the left. one infection each. next. core summit? 17:25
m: my @foo[2;2] = [[1,2],[3,4]]; my @bar = @foo >>+>> 0; say @bar.raku 17:29
camelia Ignoring [Any] as shape specification, did you mean 'my Any @foo' ?
[1, 2, 3, 4]
in block <unit> at <tmp> line 1
17:37 linkable6 left, linkable6 joined 17:59 shareable6 left, shareable6 joined
ab5tract That’s curious… 19:11
Geth rakudo/main: c59b4eeb3a | (Elizabeth Mattijsen)++ | lib/RakuAST/L10N.rakumod
RakuAST: update L10N generation logic

  - create constant mappings, instead of lookups that need to be
   created at runtime
  - add support for translation of "temp" core element
  - add support for these enums (treated as "term" in the logic):
   True False Less Same More Broken Planned Kept		 19:13
lizmat nine: re "ensure that $.body is a RakuAST::RoleBody" noted 19:15
19:26 coverable6 left, coverable6 joined
Geth L10N/main: 5068e9aa2a | (Elizabeth Mattijsen)++ | 14 files
CI test prior to release
 19:26
L10N/main: bd60d535c2 | (Elizabeth Mattijsen)++ | 5 files
Remove non-sensical CI stuff

We need proper git submodules for that		 19:37
lizmat hmmm... it feels like the current setup of raku/L10N is less easy in practice 19:49
either it should have submodules (meh) 19:50
or just a separate repo for each language, but then access management becomes... unwieldy ?
[Coke] put the access rights in a group? 19:52
lizmat it's just that the global access management of the raku org is very lenient
and that would take precedence, no ?
[Coke] Looks like it's already locked down to l10n maintainers? 19:56
lizmat hmm... I guess not
[Coke] with no access from the org?
lizmat could you check whether you can make changes to the raku/L10N repo ? 19:57
Geth L10N/coke/test: 2bc8ef0341 | (Will Coleda)++ | README.md
WIP
 20:05
[Coke] huh
lizmat that's in a branch ?
[Coke] based on what github.com/Raku/L10N/settings/access is showing me, that seems a bug 20:06
Yes.
lizmat ok, I'm less worried about that
[Coke] no branch protections in place anyway
want me to try main?
lizmat yes, please
Geth L10N/main: 95b266f3b4 | (Will Coleda)++ | README.md
whitespace
 20:07
lizmat yup, that's what I mean :)
ok, will sleep on it... 20:08
[Coke] ah.
Probably need to set base permissions?
ah, no base is at the org level, not the repo level. 20:09
lizmat perhaps Projects base permissions ? 20:10
meh... that's why I'm thinking a new org 20:11
anyways, will sleep on it... thanks for trying!
&
[Coke] maybe add raku/everyone with "read" only? 20:12
22:16 tellable6 left 22:36 benchable6 left, benchable6 joined 23:15 shareable6 left, greppable6 left, linkable6 left, coverable6 left, unicodable6 left, committable6 left, evalable6 left, bisectable6 left, bloatable6 left, nativecallable6 left, quotable6 left, sourceable6 left, benchable6 left, releasable6 left 23:18 evalable6 joined, unicodable6 joined, coverable6 joined, greppable6 joined, sourceable6 joined, shareable6 joined 23:19 nativecallable6 joined, linkable6 joined, notable6 joined, bisectable6 joined 23:20 bloatable6 joined, benchable6 joined, releasable6 joined, quotable6 joined, committable6 joined 23:21 tellable6 joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!