Geth rakudo/main: 06a427938d | (Nick Logan)++ (committed using GitHub Web editor) | 5 files
RakuAST: let BEGIN-time code in an EVAL see the context around the EVAL (#6800)

Previously code run at BEGIN time of an EVAL, or of a REPL line, could only see the lexicals around that EVAL which it named itself. Such code runs in a frame whose outer is the setting, so a nested `EVAL q{Foo}` or a `::('Foo')` there failed for a `Foo` declared around the EVAL. The legacy frontend finds it. ... (16 more lines)		 00:04
rakudo: ugexe++ created pull request #6803:
RakuAST: share the EXPORT package of the code an EVAL is compiled in		 00:08
rakudo/main: dd4af839dc | (Nick Logan)++ | 4 files
RakuAST: let an EVAL run during another compilation export

Previously `is export` died with "No such method 'stubbed-meta-object'" in an EVAL compiled while another compilation runs, as a `BEGIN EVAL` does. The package such an EVAL takes from its context went onto the resolver's package stack as a plain constant declaration, and exporting asks every package there for its meta-object. ... (6 more lines)		 01:00
rakudo/main: 8aa1b7d190 | (Nick Logan)++ | 8 files
RakuAST: share the EXPORT package of the code an EVAL is compiled in

Previously every EVAL, and every REPL line, started a fresh EXPORT package. A `sub foo is export` in an EVAL was exported into a package that nothing around the EVAL could see. A bare `EXPORT` in the EVAL found the EXPORT package of the code around it, while
  `EXPORT::DEFAULT::<&foo>`, `::('EXPORT')` in its BEGIN-time code, and
... (14 more lines)
rakudo/main: aa607786bb | (Nick Logan)++ (committed using GitHub Web editor) | 11 files
Merge pull request #6803 from ugexe/ugexe/rakuast-eval-shared-export

RakuAST: share the EXPORT package of the code an EVAL is compiled in
[Coke] 88626a3 is clear except for Injector. 01:25
pushed latest output to repo 01:26
05:30 hurufu joined 06:32 hurufu left 06:54 hurufu joined 06:57 hurufu left 06:58 hurufu joined 07:09 hurufu left
Geth nqp/main: 071e6bc466 | (Elizabeth Mattijsen)++ | tools/templates/MOAR_REVISION
Bump MoarVM for lexprimspec JIT fix, ugexe++
 07:27
07:41 hurufu joined
Geth rakudo/main: 3172ab0a33 | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION
Bump NQP for lexprimspec JIT fix, ugexe++
 08:26
09:14 hurufu left 09:47 finanalyst joined
Geth rakudo/lizmat-57: 120ed08bd7 | (Elizabeth Mattijsen)++ | 17 files
RakuAST: make .resolution.compile-time-value DRYer

This particular chained method call occurred a *lot*, so it feels like a good idea to make this DRYer.
This adds a ::Lookup.resolved-value method, and uses that method instead of any .resolution.compile-time-value call. Should improve readability and overall bytecode size.		 10:15
rakudo: lizmat++ created pull request #6804:
RakuAST: make .resolution.compile-time-value DRYer
10:23 camelia left 10:36 finanalyst left, finanalyst joined 10:55 hurufu joined
lizmat weekly: dev.to/2colours/is-generative-ai-k...-raku-37ai 11:26
notable6__ lizmat, Noted! (weekly)
12:10 hurufu left 12:15 hurufu joined
Geth rakudo/lizmat-58: 401be4109d | (Elizabeth Mattijsen)++ | src/Raku/ast/resolver.rakumod
RakuAST: streamline ::Resolver.(EVAL|Compile).resolve-lexical

  - rewrite so no return statements are needed anymore
  - tighten up scope walkers		 13:05
rakudo: lizmat++ created pull request #6805:
RakuAST: streamline ::Resolver.(EVAL|Compile).resolve-lexical
lizmat hmmm... seems like MacOS has gotten more picky 13:09
raku -e 'use OpenSSL' 13:10
WARNING: ../rakudo/install/bin/rakudo-m is loading libcrypto in an unsafe way
3x and then
zsh: abort raku -e 'use OpenSSL' 13:11
[Coke] c: 3172ab0a33 e 13:20
committable6 [Coke], ¦3172ab0: «»
[Coke] doing a run through ^
13:44 Guest81 joined
Guest81 Is it legal to define an our-scoped method in a bare package file? 13:46
e.g., in file P.rakumod: 13:47
our method om { }
lizmat m: package Foo { method bar { } } 13:48
evalable6 Potential difficulties:
Useless declaration of a has-scoped method in a package. Did you mean
'my method bar'?
at /tmp/A3wgY6XExb:1
------> package Foo { method <HERE>bar { } }
lizmat guess not ?
Guest81 Okay.  The package file compiles fine itself, but it's caught when trying to import with: 13:49
Cannot look up attributes in a RakuAST::Package type object. Did you forget a '.new'?
lizmat afk& 13:50
Geth rakudo: ugexe++ created pull request #6806:
Implement multidimensional shaped hashes		 14:16
ugexe gist.github.com/ugexe/70fe0e883bff...b2fd68c1ec - some benchmarks on an M2 using a MoarVM on a branch that adds arm JIT 14:21
14:23 yjh joined
ugexe just the lego jit, no expr jit 14:23
14:34 yjh_ joined 14:37 yjh left, yjh_ is now known as yjh 14:51 yjh_ joined, yjh left 14:52 yjh_ is now known as yjh 15:45 Guest81 left 16:35 hurufu left 16:40 hurufu joined 17:03 [Tux] left, [Tux] joined 17:05 hurufu left 17:07 hurufu joined 17:20 hurufu left 18:17 rnddim is now known as ShimmerFairy 18:24 yjh left 18:57 Guest53 joined 19:06 Guest53 left
ugexe it looks like we might be able to switch to upstream dynasm 2.1 19:06
instead of maintaining our own outdated fork 19:07
japhb It's kinda funny that the actual time to run our code jitted to arm64 versus jitted to amd64 and translated to arm64 are about the same. Something about that pleases me. :-) 19:13
ugexe er, "just the lego jit, no expr jit" -> "just the expr jit, no lego jit" 19:18
[Coke] 3172ab0a33 is clear except for Injector 21:10
linkable6 (2026-10-06) github.com/rakudo/rakudo/commit/3172ab0a33 Bump NQP for lexprimspec JIT fix, ugexe++
21:14 finanalyst left
ugexe Injector fix: github.com/FCO/Injector/pull/7 21:34
[Coke] ShimmerFairy: do you have a branch for all(moarm,nqp,rakudo)? 22:00
want to see if I can do a blin run 22:01
ugexe i'd be interested to see a run for github.com/MoarVM/MoarVM/pull/2053 but i'm not sure that i can create a branch in the upstream moarvm repo to have nqp target 23:17

Powered by Cro and the Raku® Programming Language.

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

Thank you!